NOTE: This article is not only for organizations that have already been hacked… The IEC 62443 is a generic standard recognized as applicable across critical sectors such as manufacturing, energy, transportation, healthcare, and many others.
This article is the fourth episode of a series of 8, covering some of the best practices to be implemented by any organization aiming to meet the State-of-the-Art in Cyber Security for industrial and automation control systems. Based on a pragmatic approach, this article is focused on the well-known cyber security activities that is called penetration test. This testing method is required by the secure development lifecycle as described by IEC 62443-4-1).
Security verification and validation requirements through IEC 62443-4-1 (section 9 / SVV-X) describe four main type of tests:
- SVV-1 – Security requirements testing: Key words are functional tests, performance and scalability, boundary conditions, stresses, injections…
- SVV-2 – Threat mitigation testing: Key words are effectiveness of mitigation measures, threat model coverage, …
- SVV-3 – Vulnerability testing: Key words are public vulnerability database, fuzzing, known vulnerabilities, security rule violations…
- SVV-4 – Penetration testing: While preceding testing activities allow to identify and characterize known vulnerabilities and system limitations, penetration tests are made to exploit known and unknown security vulnerabilities using exploit tools and techniques. Penetration testing can be used to validate vulnerabilities, and test the effectiveness of countermeasures. The biggest difference for this activity is coverage of feasibility aspects through real vulnerability exploitation.
This last type of test is the main subject of this article and is described more in detailed below.
Penetration testing – Typical process (based on NIST SP 800-115)
Penetration tests are known and performed across almost every application field. The terminology and processes differ a bit from an industry to another but the core approach remains the same and can be briefly described as a 4-step process as follow:
- Planning – Across this first phase, rules are identified, management approval is finalized and documented, and testing goals are set. The planning phase sets the groundwork for a successful penetration test. No actual testing occurs in this phase.
- Discovery – Across this second phase, two sub-activities are described:
- The first part is the start of actual testing, and covers information gathering and scanning. Network port and service identification, and other technics are conducted to identify potential targets
- The second part of the discovery phase is vulnerability analysis, which involves comparing the services, applications, and operating systems of scanned hosts against vulnerability databases (a process that is automatic for vulnerability scanners) and the testers’ own knowledge of vulnerabilities.
- Attack – While the discovery phase aim to check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence. There are different definition of this phase across the literature but we can identify four main sub-activities:
- Gaining Access – Based on data that have been gathered in the discovery phase, the tester attempts to access to target
- Escalating Privileges – if only user-level access was obtained in the last step, the tester will now seek to gain complete control of the system though the elevation to admin/root-level access
- System browsing – the information-gathering process begins again to identify mechanisms to gain access to other systems
- Install Additional Tools – Additional materials are deployed on the target to expand the access and perspective to “infect” the targeted environment
- Reporting – This phase occurs, most usually, simultaneously with the other three phases of the penetration test. In the planning phase, the test plan is developed. In the discovery and attack phases, written logs are usually kept and periodic reports are made to system administrators and/or management. At the conclusion of the test, a report is generally developed to describe identified vulnerabilities, present a risk rating, and give guidance on how to mitigate the discovered weaknesses.
The second and third phases of this process are comparable to typical activities performed by real attackers/hackers. Offensive technics mindsets and skills are key for performing an efficient penetration test.
Independence of testers
And last but not least, Independence of testers is a key topic in ISA 62443-4-1, crystalized through a standardized requirement which define following level of independence per testing activities:
Where
- Independent person – the tester shall not be one of the developers of the product.
- Independent department – the tester shall not report to the same first line manager as any developers of the product. Alternatively, they could be a member of a quality assurance (QA) department.
- Independent organization – the tester shall not be part of the same organization as any developers of the product. An organization can be a separate legal entity, a division of a company or a department of a company that reports to a different executive such as a vice president or similar level.
As a reason why such an independence-related requirement has been defined is that an independent tester can often find out more, other and different defects than a tester working within a programming team – or a tester who is by profession a programmer. Such a tester brings a different set of assumptions to testing and to reviews, which often helps in exposing the hidden defects and problems, in total transparency and honesty.
Conclusion
Unfortunately, most of the time cyber security is not integrated “by-design” which most probably implies that multiple weaknesses and vulnerabilities are present in the environment of a product/system. In that context, many organizations think that performing a penetration test would allow to identify all security gaps to be simply mitigated afterwards and… that’s it. Unfortunately, penetration tests shall not be considered as bullet-proofed solutions.
Of course, penetration tests are always considered as good practices, and even requirement for IEC 62443, to evaluate the feasibility of potential threats against a system but it should definitely not be considered as the only solution for vulnerability identification and characterization. Be proactive rather than reactive regarding your cyber threats.
Even if 62443 compliance is not an ultimate target, security testing should be considered as one of the main activities to be implemented and handled by organization to ensure a certain trust in a given development lifecycle.
If you have any questions about security testing, verification and validation and/or any other certification criteria, please do not hesitate to contact our cyber security specialist: Kilian Marty