How the Secure Development Lifecycle Can Help Protect IIoT Deployments

It’s Not Enough to Assume a Vendor Has Done Its Job When it Comes to Securing IIoT Devices

As the process of digitization accelerates across all sectors, so too does the number of cybersecurity challenges that present themselves. Once perceived primarily as a challenge to engineering, corporate IT and consumers, it’s now a hot topic for all. From the healthcare and automotive sectors, to industrial control systems (ICS), building management or energy distribution, the growing fears that increasing network capabilities will lead to greater risk are very real and justified. More networked devices are finding their way into more systems, and the abilities of attackers are improving by the day.

Over-exposure to cyberattack, however, is a symptom of a more fundamental problem that is common to all product areas, and there’s a solution which is the same for any industrial setting. Security considerations are not being taken into account early enough in the development of new products, leaving potential vulnerabilities to be fixed at a later stage when it is often too late. What is required is strict adherence to the principles and framework of the Secure Development Lifecycle (SDL) process.

SDL is well understood and was first introduced to software engineering almost two decades ago, yet it is still notable by its absence in many new deployments of Industrial Internet of Things (IIoT) technologies, and in more general hardware development. It’s much more than a process, too. Having a mature SDL process is a key tool that vendors can use to demonstrate their products are secure by design. 

To put it another way, SDL is key both to protecting industrial components and networks from cybersecurity risks, and improving the level of trust and confidence that users will ultimately place in them.

What is SDL?

SDL is a mature process for providing cybersecurity assurance. It’s a methodological process to identify and reduce potential threat vectors, based on detailed knowledge and understanding of how and where a product will operate. The latter is a particularly difficult task in the worlds that are opening up to connected devices, such as automotive, medical devices, building management systems and ICS, because they tend to be highly fragmented environments that have been expanded in an ad hoc manner over time. Consequently, it is not always clear at the outset where a product will be operational, and what other systems it will interface with.

At its heart, SDL is simple to understand. It’s a strategic way of ensuring that assets are prepared for an attack, by baking security considerations into the design process at every stage of product development. It starts with a full and documented risk assessment even before an initial design document is produced.

During the design process, a full analysis of the attack surface presented by the product should be conducted, along with threat modelling based on the context in which a device will be used.

SDL means that developers should adhere to strict code guidelines – which means no more easter eggs or humorous comments/hints hidden in programmes. It also means that security testing (e.g. manual/automated code review) should be an intrinsic part of the regular quality assurance process, given the same priority as bug hunting and compatibility checks.

Through careful and constant assessment right up to the point of deployment, SDL should ensure that there are no undocumented backdoors, that network interfaces are properly configured and that access to devices is strictly controlled. Continuous testing throughout the design process should include penetration testing, static analysis and “fuzzing”, a process that involves trying to overload systems with random data to look for weaknesses that might be exploited by hackers.

Post-deployment, SDL should ensure that there are mechanisms in place for securely upgrading firmware, checking device integrity and monitoring for unusual behaviour – and the same continuous testing

Why isn’t SDL universal?

While there has been an improvement in many vendors’ approach to product design in recent years, SDL should incorporate the entire supply chain for a networked solution, and too often elements are left until later in the design pipeline, which leaves security bolted on as an afterthought. In the design of industrial equipment, physical safety has always been of paramount importance; today cybersecurity needs to be treated in the same way.

There are three key reasons that this tends to occur: 

Firstly, the primary motivation for product creators is getting a new technology to market. There’s always a push on the development team to meet certain deadlines, and KPIs are structured around these targets. This means that there is not always enough time to look at the security of what is being built in terms of software and hardware, and devices are pushed out before they are ready.

Secondly, there is a cost factor to SDL. You need assurance reviews, better tooling and processes, specialised software and hardware, all of which has an associated cost. 

And finally, there’s the issue of awareness and shortage of skills when it comes to developing the applications that underpin industrial hardware and the IIoT. A software engineer’s role is to build an application or system to specification. You can be a brilliant developer when it comes to writing code that executes quickly and meets the project requirements, but writing secure code is a skill set which isn’t as widespread. Developers don’t know what they don’t know – it’s difficult to ask for advice to fix potential security holes if they are not aware of the problems they may be creating.

What’s the answer? SDL as competitive advantage

Customers are aware of the risks around deploying new technology on their networks, and SDL should be seen as a key way for suppliers to differentiate their offering. Using the language and processes of SDL to demonstrate mission readiness is a powerful sales tool, and responsible developers will invest in the best possible protection against the potential damage to revenue, reputation and operations that a cyberattack can cause, providing the benefits are clearly communicated.

Likewise, for end customers SDL provides a toolkit for interrogating suppliers. They should look for vendors who can explain their implementation of SDL, and whose design departments are compliant with the ISA/IEC 62443-4-1/2 standards. For the last 12 years, the organization ISASecure has worked to certify ICS equipment that meets these standards and help customers understand what they mean. Likewise, suppliers of IIoT solutions should be familiar with the Industrial Internet Consortium’s (IIC) Internet Security Framework (ISF) document, and the Open Web Application Security Project, a forum for professionals who share information.

And ultimately, customers should realize that it’s not enough to assume a vendor has done its job. Even if messaging is right, corners may have been cut. Customers should have their own resources on hand for regular testing and hardening of solutions over time.

Put all of that in place and SDL becomes a vital tool for improving and communicating about security in IIoT deployments. Without it, we’ll just keep making the same mistakes over and over again.

Learn More About Industrial Security at SecurityWeek’s ICS Cyber Security Conference