As companies race to digitally transform themselves and remain competitive, integrating Industrial Internet of Things (IIoT) connectivity into their business operations has become a de facto standard. Facing the choice of “build versus buy” with respect to IIoT platforms and solutions, some organizations choose to pursue the former course, unwisely deciding that doing so will save money over the latter. The economic pitfalls alone of do-it-yourself (DIY) IIoT projects are already stark, but one aspect which many organizations also fail to take into account is an increasingly critical one: cybersecurity.
The business risk of suffering a digital attack is clear. The case of information technology operations company SolarWinds, which unwittingly served as a vector to contaminate its customers’ software supply chain in 2020, is instructive. The company estimated the direct costs of dealing with the breach to be at least $18 million, not to mention the ensuing brand damage. An even more alarming example is the case of the so-called TRITON malware. In 2017, a probable nation state actor deployed this malicious digital tool in a nearly-successful attempt to physically destroy a petrochemical plant.
In the face of these threats, businesses need to be confident that they are mitigating cybersecurity risk appropriately while at the same time allocating resources effectively and facilitating daily operations. Doing so can be challenging even for companies that build digital solutions as their primary business line, and especially so for those who earn revenue doing things other than building and selling software.
First and foremost, safely developing an in-house IIoT platform requires having the appropriate security experts in place. Ensuring that developers, testers, architects, product managers, and executives understand the cybersecurity implications of design decisions and tradeoffs is often easier said than done. Conceptually and philosophically, you should consider how you will measure and manage cyber risk. What are your risk tolerances? How will you weigh risk mitigation against business goals? Who will make the tough decisions regarding which flaws to resolve and which ones to accept (and be accountable if something goes wrong)?
At the technical level, individual engineers will need to learn how to incorporate security principles into their peer code reviews – assuming your organization is doing these already – and quality assurance staff will need to ensure they are also reviewing the application for security bugs instead of just functional ones. Your organization will need to conduct regular secure development training to keep these skills fresh.
Assuming the necessary personnel are in place – or are sufficiently cross-trained – the next step would be selecting and implementing a secure development framework. Whether choosing the Microsoft Security Development Lifecycle (SDL), the open source Software Assurance Maturity Model (SAMM), or some other paradigm, building a program management component to enforce compliance across your organization will be essential.
If you have made it this far, and want to continue on the DIY path, next you will need to incorporate appropriate automated scanning tools into your development pipeline. In addition to using static analysis to identify programming errors, you should also conduct software composition analysis regularly to review third-party libraries called by your proprietary code. When your application is compiled and ready to move into production, you would be well advised to conduct dynamic analysis against it during runtime to make sure there are no previously unidentified vulnerabilities. Although open source options exist for all of these capabilities, enterprise-grade products that can support modern continuous integration/continuous deployment processes and prevailing compliance requirements often have a hefty price tag.
Once you have made it into production, though, your security responsibilities aren’t over. Regular penetration testing – both by employees and contracted outside experts – is critical to simulating real world attacks and finding gaps before bad guys do. Furthermore, what do you do if a security researcher finds a problem with your new DIY solution? You will need an incident response capability to negotiate and conduct coordinated vulnerability disclosures. Otherwise, you might face an uncoordinated disclosure by a researcher frustrated with your slow process.
Even if you have managed to put all of the above in place, you will still need to maintain your home-brew platform indefinitely, dedicating engineering resources to fixing security bugs, updating libraries, and keeping up with industry standard protocols. In addition to the fixed development costs incurred up front, make sure you budget for these recurring operating expenses for the rest of the lifetime of your DIY project. Industry trends suggest that 30% of development time is spent on code maintenance, and in my experience, about one third of that is solely dedicated to security.
Finally, it is important to consider the reputational “economies of scale” that you will forgo when building your own IIoT platform. As an organization whose primary mission is not building software, you will likely find it challenging to work and communicate effectively with other security experts in both the private and public sectors. Similarly, the lack of a track record in securely building applications will likely impact your cyber insurance premiums.
In the face of these requirements and the intricacies of securing and maintaining your own IIoT platform, attempting to do so can be a herculean undertaking. Given the expense and risk inherent to such an effort, at least one independent security expert advises against doing so. A better bet would be to use a market-leading platform, with pre-built solutions, that already incorporates these security best practices. Doing so will help you manage information security risk in a cost-effective manner while at the same time focusing on what is most important to you: your business.