We have covered Insecure By Design issues in ICS repeatedly on this site and at S4, resulting in some challenges to define what would make a PLC Secure By Design. This is a much harder task, but I will present some thoughts in a series of articles beginning here.
The first thought is not all that insightful – a vendor needs to integrate security into the product development lifecycle. Simple, right? Yet we often talk with vendors, as part of the asset owner team, who cannot produce even the security requirements from the definition and design phases of a product development project.
Microsoft’s Security Development Lifecycle (SDL) is the most prominent example of a SDL, and it is documented in books, applications and other resources. If you are considering purchasing a new product or system from a vendor you should include SDL requirements in your RFP. You can see examples in ISASecure’s Software Development Security Assessment, upcoming IEC-62443-2-4, WIB’s Security Requirements for Vendors, and a variety of other locations.
You do not need to be a security or development expert to make the first pass decision on whether the vendor has implemented a SDL.
- Ask the vendor what their SDL is. If they can’t easily provide the documentation of the SDL it doesn’t exist in a practical and effective manner.
- After you see the SDL, find a few key activities and ask for evidence these activities took place for the product or system you are looking to buy. If they can’t easily provide this evidence of these activities, then it took place informally at best.
This does not guarantee that the resulting product is Secure By Design, but the lack of a documented and followed SDL is evidence that it is not Secure By Design.
My personal view of the three most important items in an SDL are:
Threat Model – Every time we have done a threat model there have been a number of unaddressed and obvious threats that have fallen out, and often the fix would have been simple if it had been addressed prior to product release to production. Often these are related to reducing the attack surface, but they can also require additional security functionality to address the threat. Also, how do you know what security controls are required if you have not determined and documented the threats? (Warning – watch out for threat models that say everything is in a secure zone and eliminates most if not all of the threats. More on threat models in future parts of this series.)
Secure Coding Standards – A large percentage of the ICS vulnerabilities that have been identified in the post-Stuxnet era would not have occurred if reasonable secure coding standards had been followed by the vendor. Do the standards exist? How are engineers and developers trained on these standards? How does the vendor verify the standards have been adhered to in QA or elsewhere?
Fuzzing – This is included on the shortlist because Steve Lipner at Microsoft, and co-author of the book on SDL, said it was fuzzing and threat modeling identified the most bugs that could lead to vulnerabilities. The evidence should be more than a checkbox for fuzzing. (Check out a S4x13 session on OSIsoft’s fuzzing program)
You should inspect the SDL prior to awarding a contract, as part of your decision in selecting the winner. We saw this first hand when a RFP was awarded and the SDL audit was part of Factory Acceptance Testing (FAT). Many of the claimed SDL elements had no evidence and were clearly not performed at all, let alone as specified in the RFP response. At FAT the options are limited, particularly related to product or solution development.
There are multiple vendors in the ICS space that have been integrating security into their development process, many following the Microsoft model, for about five years now. It is a significant investment, with many failures in the early years. The training requirements alone so that everyone understands the tasks they need to perform and have a common language to discuss this are substantial. The results are showing in many of the ICS workstation and server applications from these companies.
Next: Part 2 – Praying To False Certifications
Image by Malcolm Craig