Every ICS environment will sooner or later have to deal with updates, upgrades or additions to the control system environment. Nowadays it is important to include security within such projects, although that is still sometimes forgotten (sad but true). one of the ways to include security is to perform vendor validation and set security requirements for these projects.
The IEC62443-2-4 standard (current version IEC 62443-2-4:2015+AMD1:2017 – https://webstore.iec.ch/publication/61335) specifies such security requirements for scada suppliers, integrators or vendors (which one is implementing the solution(s) for you).
Only specifying security requirements is not enough unfortunately… It is important to have a streamlined procurement process before you can even dream of setting security requirements for all ICS projects being procured. Luckily this is the case for most organizations … however there are some things to consider.
Larger organizations tend to have a decentralized purchasing approach. The big, (very) large projects are very often purchased centrally, smaller projects go through country or region procurement and small or single systems go through local site purchasing processes. This makes setting security requirements for all ICS projects a tedious task to do and sometimes difficult to followup.
If a centralized approach is not possible, feasible or wanted, all procurement processes should be aligned and should include the security requirements within call for tenders that are being sent out.
Having the security requirements within the procurement process and in the outgoing call for tenders is one thing. One should also check what the vendor is proposing and match this against the security requirements to verify whether the proposed solution or product and the vendor, supplier or integrator themselves are compliant to the organizations security view and hence the IEC62443-2-4 if these are used as requirements.
Those same security requirements can hence be used as one of the selection criteria during proposal evaluations.
It doesn’t stop with the proposal evaluations. Once a supplier, vendor or integrator has been chosen, the project phase kicks in. Within the project phase, the agreed security requirements must be thoroughly evaluated. This can (will most likely) include (several) discussions with the selected vendor as to why certain requirements can (or will) not be met and how these will be mitigated within the actual project phase.
Evaluation of those requirements will be partly a “paper-job” in which all possible documentation on the to-be implemented systems or solution must be analyzed and verified. Such documentation will include (but is not limited to) network architecture, used hardening guidelines, implemented security measures and certainly the motivations why certain requirements can not be met and why.
Only doing a paper-job is not enough. What has been claimed to be implemented should (must) be checked during technical security FAT and SAT test cycles. These are not the same as functional FAT and SAT testing phases and should therefore be clearly defined within the project timeline.
The best way of dealing with this, for both the security and functional tests, is that all required security actions should be completed before any FAT testing is done. Discovered issues and noncompliance items should be corrected before entering the SAT or another option is to have a 2nd security FAT to make sure all things are corrected before allowing the systems onsite.
An important step during the (last) security SAT will be determining the residual security risks within the implemented solution and what possible mitigating measures can be taken to reduce the overall risk. It is then up to the project team and asset owner to decide what action will be taken.
The result of the security FAT and SAT tests, more precisely the discovered issues and noncompliance items, should be used as one of the project acceptance criteria. Doing so, the asset owner will have a better guarantee that the systems and solution that is brought into the environment is properly secured.
You have to take care though that security is a living thing and that the requirements could evolve over time which will lead to a evolving improvement of the security of newly introduced parts to the environment. Embedding security within existing parts of the environment can be performed gradually on through these updates, upgrades or additions. As security is a living thing, security testing should be performed regularly and security should also be embedded within the maintenance of the environment.
Now you can question whether all of this is necessary if the ICS vendor solution or products are IEC62443 certified. I do think properly handling security requirements will still be necessary, even with such certifications. Like I also mentioned in Security testing for ICS Owners – Back to Basics …, you should Trust your vendors – but verify what will be or has been implemented.
Feel free to contact me to know more on implementing such Vendor validation process.
1 thought on “using IEC62443-2-4 to reach a more secure ICS – Vendor validation”
[…] using IEC62443-2-4 to reach a more secure ICS – Vendor validation […]
Comments are closed.