Two common gaps exida encounters when evaluating vendor compliance against the IEC 62443-4-1, IEC 62443-4-2 and IEC 62443-3-3 standards are:

1. Inadequate or unclear Security Guidelines.    
2. A lack of documentation on the security audit records (AKA logs).   

Improving compliance in these areas is also a very cost-effective means of improving security.  Why is this?

Security Guidelines

Many, or depending on whose statistics you believe, most security breaches are due to misconfiguration.   So, providing comprehensive, easy to follow Security Guidelines is the most cost-effective means of improving security.  This is especially important for systems comprised of components from multiple vendors.  If you purchased an automobile would you expect separate manuals for the cruise control system, antilock braking system, navigation system and infotainment system all written by the component vendors using an inconsistent writing style and verbiage?  No you would not.   It isn’t reasonable to expect IACS system customers to review the manuals for each component and understand how to “turn the various knobs and pull the various levers” on each component to secure the system.   

What makes effective Security Guidelines?

1. Clear instructions on how to configure the component or system in a secure manner.
2. A clear definition of the Product Security Context.   As defined by IEC 62443 the Product Security Context is the security expected to be provided to the product or component by the environment in which the product is intended to be used.  In this context Product could mean a component (PLC, I/O module, Ethernet Switch etc.) or an IACS system. For example, if the product is expected to be protected against physical attacks, that expectation needs to be clearly documented.  Likewise if the product is expected to be protected by a firewall that needs to be explicitly documented.
3. Instructions on how to securely dispose of a component or decommission a system.   For example, instructions on how to wipe all configuration data.

Audit Records AKA Logs

To help detect and stop security breaches asset owners need to a) understand what audit records are available and b) what they might mean.  For example, if an audit record indicating user BillBob failed authentication attempt is being produced continuously it likely indicates an attacker is trying to brute force crack user BillBob’s password.   Documentation for audit records should include:

1. A description of the event triggering the audit record
2. Possible security implications of the audit record
3. Recommended on next steps 

Wait?  Isn’t audit record documentation something that belongs in the Security Guidelines?  Yes it does indeed belong there.   It was just called out separately to get the needed attention.

So above are two (or one depending on how you look at it) extremely cost effective means of both improving your IEC 62443 compliance and improving security.   Neither requires writing a single line of code.