How do you ask your vendors for security? How do you assess how extensive their security knowledge and practices are? Are they glitz, glamour and commercial glossies or do they really have competent personnel who have the education, skills and experience to provide you with secure products, services and solutions? Does your vendor appreciate the value of security or see it as just a compulsory tax?
Prior to the publication of the ISA/IEC 62443 series of standards, these were challenging questions for vendors to answer in any standard and measurable way.
Now, though, you have a way to specify what you want, how much of it you want and the most critical places where you want it.
The 62443 standard provides requirements for each defense-in-depth layer—components, components integrated into a system and systems-at-end users or asset owners.
These requirements are specific to cybersecurity for industrial control systems: the OT side of the house. Many other well-known and ubiquitous standards apply to the IT side of the house—the NIST Cybersecurity Framework, ISO 27001 and NIST 800-82—but are difficult to apply directly to assessing OT. The IEC 62443 set of requirements was developed to specifically address this gap and need.
For both components and systems, technical cybersecurity controls are critical to securing a component and/or system. These are things like cryptographic algorithms and secure web servers. If components or systems do not include these well-known industry best practices, then the security of the result is in question. The IEC 62443 standard acknowledges that there are different skills, motivations and financial incentives of adversaries, and that these pose different types and levels of risk to components and solutions. 62443 provides a layered approach for technical controls. They are specified as security levels (SL).
It must be recognized mitigating higher level risks posed by sophisticated adversaries comes at component, integration and/or end-user cost. Many security controls are expensive and just not possible to implement at a component level.
The requirements for how a component or system is built and maintained and how issues are handled receives less attention. This can be referred to as a development or lifecycle process.
The 62443 standard specifies requirements for all areas of product or solution lifecycle development, including specifying security requirements, understanding threats, testing to ensure threats targeted were truly addressed and verifying that all required technical security controls were implemented.
The standard also provides requirements for the management of these areas, such as ensuring that employees have the security skills and experience necessary to develop secure components or solutions, that the processes being followed are continuously improved as industry best practices evolve and that reviews of all steps include a security aspect at all times.
Furthermore, these lifecycle process requirements must all be met in some way, and maturity at applying them is the measure. These are called maturity levels (ML).
A vendor cannot know which technical security controls, and the extent of them, are most important to you. These can be communicated in terms of a 62443 security level. For any security level, you can be sure the vendor understands and uses industry best practices in how they have developed a component because these are required for all 62443 component certifications.
Connect With Us