IT and OT systems are essential to the day-to-day operation of critical services within CNI industries such as the finance sector, telecommunications, defence and energy. Threats to these from well-resourced and funded adversaries are growing, with criminal groups monetising attacks and hostile states exploiting them for espionage, sabotage, and other objectives.

In May 2022, the USA’s Cybersecurity, and Infrastructure Security Agency (CISA) released an advisory report stating that Advanced Persistent Threats (APTs) are developing and using malicious tools targeting OT.

Penetration testing is an effective way to test the security of systems and identify vulnerabilities and configuration errors. However, to defend and detect an attack from a skilled and funded adversary, it must provide a high level of assurance.

Understand the scope of the system being tested

To ensure that all potential risks associated with testing are understood and managed, the scope of the testing must be clearly defined. For highly regulated sectors like energy, a scope that limits testing from touching safety critical assets may be required, for example.

Scoping means establishing:

• What the risks are to the systems?

The systems involved need to be understood, including their vulnerabilities and threats to them. The risks can then be calculated and documented for risk management.

• What are the use cases of the system?

Establishing use cases improves scoping and enables better identification of any potential risks. For example, documenting how a user authenticates and accesses the system when carrying out critical tasks.

• What are the misuse cases of the system?

Misuse cases are scenarios where the system is used improperly either maliciously or accidentally. Documenting these enables known or even unknown vulnerabilities and risks to be established. For example, an administrator opening an aspect of the system to the internet without any protective security controls in place.

• What are the building blocks of the system?

Understanding the critical aspects of a system is essential. During scoping the key technical stakeholders and administrators who work on and/or use the system must be gathered. These are the people who will be able to identify the building blocks of the system and draw out any architectural points relevant for the assurance activities, such as legacy assets and singe points of failure.

• What are the security enforcing functions of the system?

The security enforcing controls within the system need to be documented because part of the assurance activity will be dedicated to testing these controls, as well as identifying if further controls are needed.

Testing types and techniques that provide high assurance.

It is important to know that the most suitable testing activity or technique for one system may not be the best for another. It depends on the system’s design, purpose, environment as well as the assurance aims set out in the scoping phase.

Examples of techniques and tests:

• Compliance and Testing standards

These prove systems meet industry-recognised goals or best practices, such as ISO 27001, NIST 800, GDPR, PCI DSS, etc. Complying with a recognised standard provides assurance that the system meets the required capability of controls and design.

Gaining a ISO 27001 certification provides a degree of assurance. The ISO 27001 standard is a set of guiding principles and governance practices for managing information security. It details requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS).

• Code reviews

These provide assurance that systems are securely developed in accordance with best practice. Code reviews help ensure defence in depth as errors in an application or the technology’s code are not masked by other controls in the system.

A code review can be done before a system or application is live to ensure backdoors have not been embedded into the system by malicious insiders or bad developer practices and lack of internal controls.

• Configuration and build reviews

Configuration build reviews can be done in accordance with vendor guidelines and industry best practice benchmarks such as CIS to ensure infrastructure components are locked down, follow best practice and free from known vulnerabilities. CIS benchmarks provide guidelines on controls and safeguards to minimise cyber risk.

Configuration and build reviews ensure that software components are patched to the most recent release, audit capabilities are implemented in accordance with policy, and a complete and up-to-date asset inventory is held.

• Application security testing

Application security testing helps ensure a secure software development lifecycle. It provides assurance that the application is as secure as possible. There are different approaches that can be taken when conducting an application security test:

• Whitebox review - like a code review, it involves a manual review of the application’s source code to identify any security vulnerabilities.
• Blackbox review - this is similar to a penetration test and involves a security expert conducting a full review of the security controls from the application’s outward facing perimeter and working towards the source code.
• Automated testing – using a security tool to conduct assessments on the application against known vulnerabilities to provide a report on any findings.

The Open Web Application Security Project (OWASP) provide free resources on application security. The OWASP Top 10 detail the most common security risks faced by web applications.

• Fuzz testing

Fuzz testing provides assurance that interfaces and APIs won’t operate in an unexpected or insecure manner when faced with unexpected behaviours and inputs. It can be carried out at various layers of the OSI stack depending on the scope of the areas requiring assurance.

There are two main types:

• Coverage guided testing - this involves probing the source code while the service is live to see how the service interacts and if there are any unexpected results.
• Behavioural testing - this compares expected and desired behaviour against actual behaviour following random inputs to help identify vulnerabilities.

• Functional and non-functional security testing

Functional testing verifies that a service’s features and functions are secure and working properly. Non-functional testing verifies aspects like usability, reliability and other non-functional parts of a service. For example, a functional test includes testing whether the login route of a service is operating within best practice. A non-functional test may be based around ability to recover from a disaster, whether the service has sufficient backups? Does it meet RTO/RPO targets?

• Scenario based testing

This provides assurance that the system is fit for purpose and secure. Scenarios test key security enforcing functions and controls, based on business risks to the system. For example, providing assurance that an attacker who gains privilege rights within one customer tenant cannot pivot to gain access to another customer’s tenant.

Scenarios must be developed with system stakeholders so they meet the business and security teams’ objectives.

• Through life assurance

It is important to assess the through life assurance capabilities of a system or product and ensure the system is secure beyond the point of testing. This could include a review of process and policy and discussions with developers to understand things such as how code is securely stored and how code changes are approved, tested and peer reviewed. The aim is to provide assurance that the system will be secure and fit for purpose throughout its life.

• Testing of audit and alert

Protective monitoring and Security Operation Centre (SOC) capabilities of a system typically form an integral part of the security control set and are the last line of defence. It is essential that is tested as part of the assurance activities. Testers should provide a number of specific test cases to trigger alerts and events, and work with the defenders to review their logs and actions to understand how effective they were. This type of activity is often referred to as ‘Blue Teaming.’

Types of activity:

• Red Teaming – Similar to a penetration test. Ethical hackers mimic real world attack scenarios to attempt to gain access to a target system.
• Blue Teaming – Ethical hackers assist system defenders to defend against real world attack scenarios and develop their defensive capability.
• Purple Teaming – This is a blend of Red and Blue Teaming with both offensive and defence.

Having Assurance in the Organisations Providing the Testing

To achieve a high level of assurance, it is not enough to assess the type of assurance and testing. The organisation providing the testing needs to be assessed to provide assurance they are able and qualified.

There are a number of accreditations that testing providers can gain to evidence their ability to provide assurance activities. An example is CREST, an international not-for-profit body that provides accreditations to organisations and individuals across the globe within vulnerability assessment, penetration testing, threat intelligence and incident response. CREST accreditations help organisations to purchase cyber security services with confidence.

Organisations can also have accreditations such as ISO 27001 to provide assurance that they handle information in a secure way. They may also be able to provide certified ISO 27001 implementors and/or auditors to assist customers in gaining ISO 27001 accreditation themselves.

To gain accreditations the service provider will often be required to have certified testers in their employment. For example, for an organisation to have CREST STAR (Intelligence-led Penetration Testing) accreditation, they must have testers with one of these qualifications: CREST Certified Simulated Attack Specialist (CCSAS), CREST Certified Simulated Attack Manager (CCSAM), CREST Practitioner Threat Intelligence Analyst (CPTIA), CREST Registered Threat Intelligence Analyst (CRTIA) or CREST Certified Threat Intelligence Manager (CCTIM).

Along with certifications, some systems require that the tester is vetted to conduct any tests. For example, systems that exist within the public sector, such as within Defence and/or HM Government. HM Government clearances are BPSS, CTC, SC and DV. Testers will often have either SC or DV to allow them to operate at Secret or Top Secret respectfully.

It is important to check that the testing company has the proper insurance in place for protection in the event of a disaster or mistake.

Testing companies secure customer data in a range of ways. Such as architecting their system to ensure segregation between different customer’s data and also ensuring that any data in rest or transit is secured via encryption.

It is important that testing companies provide a high level of assurance that they will secure and protect customer data. This can be provided via accreditations and certifications, as discussed, and by allowing customers to conduct third party audits on their systems. Third party audits help customers gain assurance that a testing company meets an agreed capability or level of security competence.