Industrial Automation Control Systems (IACS) Cybersecurity based on IEC 62443 was created to be compatible with agile development methodology. The standard deliberately talks about processes and not phases, such as those in the waterfall model. The processes defined can be met simultaneously and are, most likely, already being followed as part of your agile process; however, you may not be explicitly calling them out. One of these processes is documentation.

Agile does not mean no documentation; it means useful documentation. To start, documentation helps you and your team review the cybersecurity aspects of your current sprint, and provides evidence for the certification process. It also allows you to understand the impact of any changes, track down security issues and find the root cause, and improve your security design lifecycle. When following the IEC 62443 standard and your security development lifecycle, documentation will not be “sitting on a shelf” but will be used and updated every sprint.

Documenting the architecture—including system, hardware, and software—will help all team members understand how their changes will interact with others. (And you don’t want to have your architect leave and then try to fill the knowledge void after the fact.) The standard recognizes that capturing this architecture information beforehand is best for the project—but it does not say howyou must do the documentation, e.g. “must use semi-formal methods,” just that you need to document.

A key part of cybersecurity and the standard is threat modelling. You most likely will need to add threat modelling analysis as part of your sprints. On each sprint you will need to visit any new or changed interfaces to see if they impact the threat model, and then document any findings. This will let you determine trust boundaries and decide how to mitigate threats that appear at these boundaries. These mitigations may lead to additional development work and/or testing.

You should already be running a static code analysis tool such as PC Lint, and limit or remove unsafe routines such as (in C/C++) strcpy, strcat, etc. You will need to look for code that leads to security violations such as buffer overflow, input injection attacks (e.g., SQL injection attack), privilege level escalation, etc. The results of these code analyses should also be documented.

You also need to document the results of security testing, including fuzz testing. You are most likely doing automated testing as part of a continuous build process, so this should not be a new documentation requirement.

The overhead associated with these and other IEC 62443 cybersecurity-related tasks should be small. They are necessary but quick checks, including updating the existing documents that were already used in the previous sprint and will be used in the next sprint. In addition, the cost is likely to be recaptured by the reduction or elimination of security vulnerabilities. Fixing a vulnerability that has reached the field will cost much more than fixing these same problems during the development lifecycle. 

Once in the habit, following your guidelines and using your documentation will improve your cybersecurity.

To learn more about IEC 62443 cybersecurity certification, go here.