When it comes to developing secure products, the IEC 62443 series of standards provide a lot of guidance and best practices which can be applied while developing the product.  This is essentially an approach to designing security into the product rather than trying to add it on at the end.  The two main parts of the standard that apply to developing secure products are IEC 62443-4-1 and IEC 62443-4-2.  Specifically, IEC 62443-4-1 includes security requirements that apply to the development process throughout the product development lifecycle.  In addition, the IEC 62443-4-2 standard includes requirements for security capabilities and features required of the product based on the product’s required capability security level and on the component type.  While this is great in theory, most products in the field today were developed before these standards came out in 2018/2019.  Even new systems that are developed often depend on legacy code from previous generations of systems.  As a result, developing products or systems from scratch only occurs rarely, and if we limit the application of IEC 62443 to such products, then we cannot make a real impact in the installed base in the field.

Therefore, in order for IEC 62443 to drive change and improve cybersecurity in the industry, there must be a way to apply the standards to already existing legacy systems.  For IEC 62443-4-1, the challenges are related to how do you apply a development process to a product that has already been developed using a different process that likely had less of a focus on cybersecurity during its development.  For IEC 62443-4-2 the challenges revolve around adding security capabilities to products that are already in the field.  These are really two separate but related issues, so we will look at these separately.  This blog will concentrate on the security development lifecycle challenges related to IEC 62443-4-1.  A future blog will focus on the technical challenges related to IEC 62443-4-2.

The first step in applying IEC 62443-4-1 is to do a gap analysis between the current development process and the existing process.  Once the gaps are identified, the process can be updated to close these gaps.  This will help when developing new products, but it is unclear how this could be applied to legacy products.  Fortunately, the creators of IEC 62443-4-1 were thinking about this very issue when the standard was first developed.  As a matter of fact, early drafts of this standard had some requirements that specifically were only applicable to legacy systems.  However, once this standard was sent out for broad review, the feedback was to simplify the standard and to be less prescriptive.  Rather than having specific requirements that were only applicable to legacy systems, a risk-based approach was chosen for IEC 62443-4-1.  All the requirements from the standard apply to both legacy systems and new systems, but risk analysis can be used to determine how to apply the requirements to already existing systems. 

Taking a risk-based approach is called out in several requirements in the standard including SM-3 (Identification of Applicability), SM-9 (Security Requirements for externally provided components), SM-11 (Assessing and addressing security related issues), SD-2 (Defense in depth design), DM-3 (Assessing Security Related Issues), and DM-4 (Addressing Security Related Issues).  When it comes to applying this concept to a legacy system there are several questions that must be asked:

1.  Was this process followed during the initial development?
2. Can this process effectively be applied to the product as it currently exists?
3. Can the process be effectively applied to future development (for example, new software releases) of the product?
4. When the process is applied to a legacy product, and security issues are identified, which issues must be addressed?

These questions would have to be asked for each process called out in the standard.  In some cases, the answer to question one will be “Yes”, and no further action will be needed.  IEC 62443-4-1 essentially codified best practices that were in existence at the time the standard was written.  As a result, even if a product was developed before this standard was released, the developers might have followed these best practices.  

The process of analyzing the requirements from IEC 62443-4-1 and determining how to apply them to legacy products, is shown in Figure 1.  The flowchart in this figure defines the different approaches that can be taken per requirement, based on the analysis described above.  The different approaches are documented in the process steps and an abbreviation has been assigned to each of these steps.  For example, the step “Apply process retroactively to product” is abbreviated as RA.  Figure 2 then shows which methods make the most sense for each requirement in the standard using these abbreviations.  

There will obviously be many cases where processes were not followed during the initial development of a product even if they were known at the time.  But some processes can be applied to an already existing product as it currently exists.  For example, you could create a threat model (SR-2) for an existing product.  You could run a static source code checker (SI-1) on existing source code.  However, in both cases, the question becomes “What do you do with the results of this analysis”.  Creating a threat model or running static source code analysis is not very useful if the result is simply documented and then filed away and forgotten.  The value of these processes occurs when you identify potential security vulnerabilities in the product and either eliminate them or mitigate the risk to an acceptable level.  And this can be quite a challenge in both cases.  Static source code checkers are most effective when you run them when the code is written and address any potential problems found early in the software development lifecycle.  If you have a large code base and run static source code analysis for the first time, you will likely get thousands or tens of thousands of warnings and errors.  

This can be a daunting prospect to go through and address all these warnings and errors.  However, this is where the risk-based approach can be used.  The threat model could be used to determine which parts of the design are either security related or have the highest security risk.  For legacy code, static analysis could initially be limited to this high-risk code.  In addition, if the results of such analysis are prioritized in order of risk, then the highest risk items can be addressed first.  Each subsequent release would demonstrate continuous improvement by addressing more and more of these issues.   

Naturally, when you do this analysis, you will identify some items that are critical and must be fixed right away.  Others might still be important to fix over time, but immediate fixes are not required, and some will be identified that do not need to be fixed because either they are false positives, or very low risk.  The target security level can also be used to guide when fixes are made.  The ISA Secure SDLA scheme, for example, requires that you fix all critical issues found with the Nessus Vulnerability scanner for products that are SL-1.  For SL-2 products, however, all critical and high issues must be addressed, for SL-3 all critical, high and medium issues must be addressed and for SL-4 all issues must be addressed.  This same concept could be applied to issues found through other methods such as static analysis and threat modeling.  Alternatively, the definition of the security level can be used to set priorities.  If your initial certification is only targeting SL-1, which only covers accidental misuse of the product, then it is not as important to address issues which are only relevant for intentional attacks.  If you are targeting SL-2, you must address issues related to intentional attacks, but only those attacks that require simple means, motivation and resources.  Issues related to more sophisticated attacks would need to be addressed for products that are compliant with SL-3 or SL-4.  

Once the important issues are addressed for the high-risk legacy code, the static analysis could be expanded to include additional legacy code, also prioritized based on risk.  

There are some requirements, but not many, that cannot be easily applied to existing products that were not developed with a compliant process.  For these cases, the only option is to apply these processes going forward on new releases of the product.  One example of this would be code review.  For most projects, it would be very difficult, and most likely not very effective, to go back and review the entire code base.  However, it would be effective to review new code as it is developed and changes to existing code and to identify a subset of the existing code base that is especially important for security and to review that code.  So, in the case of code review the combination of these two steps will satisfy the requirement.  

There are some other requirements in part 4-1 of the standard that don’t apply to the development of the product, but they do apply to handling security issues and vulnerabilities for products.  For example, requirement SUM-1 is related to qualifying security patches on the product.  If the product has been out in the field for 10 years, and security patches were created in a way not compliant with this requirement, that is OK, as long as the process is updated to be compliant for future security patches and it is followed in the creation of these patches.  

Applying IEC 62443 to legacy code certainly has its challenges.  But hopefully you can see from the examples above that there are ways to handle these challenges based on following a risk-based approach.  Doing so will significantly increase the security posture of legacy products and makes a whole lot more sense than doing nothing to improve the security of these products.  Striving for continuous improvement using this approach will steadily improve the security of the product over time and should result in fewer vulnerabilities reaching the field.

Figure 2:  Most likely methods used to apply requirements to legacy systems

Key:

The abbreviations in the most likely methods column come from Figure 1 and are summarized below:

RA – Apply process retroactively to product

DEP – Apply to development environment or process itself going forward (for all future development)

MAS- Apply to maintenance and support of product going forward (for all future maintenance and support)

ALL – Apply process to all software going forward (for all future development)