SECTION 2.6
Secure Delivery

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#2 Understanding the risks to your connected place

As the detailed design of the smart street system materialises, a low-level threat and risk assessment (TRA) should be carried out. This is because the implementation of specific components within the system design may change the security risk.

The system integrator should pull together security information on each of the components (e.g. products) that will comprise the system. This information should include the vulnerabilities of the product and may also include the security capabilities of the component. Depending on the component supplier, limited security information may be available. Individuals with good knowledgeability and experience of the component should therefore be involved in workshops to produce the low-level TRA.

Considering the high-level TRA (see recommendation C3) and security information about the components, the system integrator should reassess the security risk of the detailed system design. Additional security requirements (and therefore additional controls or policies) may be necessary to mitigate the identified additional risks.

It is suggested to take an iterative approach to the TRA process. Security requirements that come out of the TRA may impact the system design, and equally, as the system design changes, the TRA needs to be updated to analyse the delta.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#13 Managing your connected place throughout its life cycle

Security requirements should be tracked in the same way as any other project requirements. However, where a requirement is not addressed for whatever reason, the TRA should be updated to reflect this, because failure to address a requirement may have an impact on security risk.

As security requirements are addressed or rejected, the TRA should begin to reflect whether risks are accepted, delegated, mitigated or eliminated.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#13 Managing your connected place throughout its life cycle

Security testing is necessary for a wide range of purposes. Security testing helps identify unexpected vulnerabilities, verify the presence of known vulnerabilites, understand the how vulnerabilties could be exploited, verify that security requirements were implemented and validate that the security measures perform appropriately against simulated cyber threats.

The results of security tests should inform progressive updates of the TRA. For example, if an unexpected vulnerability is discovered, the TRA should be reviewed to determine whether new risks should be added. If a security requirement was demonstrated by testing to be unsuccessfully implemented, the risk level should revert to the pre-mitigation level. If you are managing the TRA, you should ensure suppliers keep you informed of test results to keep the TRA up-to-date.

There are several types of security testing, and there is frequently confusion between the different types of test. Understanding the different types of security test relevant to smart streets systems is important to setting and interpreting client requirements, developing test plans and ultimately ensuring the security of the system.

Vulnerability Scanning

Vulnerability scanning is the use of an automated tool to search for predetermined vulnerabilities. This can include source code scanning, software scanning, network scanning and configuration scanning.

• Software Development Use Case – Many code analysis tools offer vulnerability scan functionality. Some tools such as Polyspace Bug Finder will scan code for common coding mistakes that can introduce security vulnerabilities, such as buffer overflow. Other tools such as SCA tools may compare any identified open-source libraries and snippets with a list of known vulnerabilities in open-source software.
• Network Scanning Use Case – Devices on a network may automatically be queried on certain ports that are known to host vulnerable services. If an open port is detected, additional messages automatically may be sent to determine if a vulnerability is present.

Compliance Testing

Compliance testing is very similar to vulnerability scanning. It also uses an automated scan, but tests against a set of policy rules rather than a list of predetermined vulnerabilities.

• Managed Corporate Laptop Use Case – Periodically, the configuration of the laptop is automatically checked to confirm that it conforms with company security policies. For example, if the Windows firewall has been disabled, the laptop may fail the compliance test.

Fuzzing

Fuzzing is an automated test that injects an interface with invalid, malformed or otherwise unexpected input.​ System behaviour is monitored, and unexpected or undesired behaviour is logged and investigated to determine if there is a security vulnerability.​ Fuzzing exists because system design is complex, and it is easy for the designer to miss a possible but unexpected combination of system states.

• Software Fuzzing Use Case – Where software has an input field (e.g. a text box or API), random invalid or unexpected inputs are generated to fill variables and the program is run to determine the outcome.
• Hardware/Network Fuzzing Use Case – Valid network or bus messages are randomly manipulated or corrupted in unexpected ways.

Functional Security Testing

Functional security testing best resembles traditional functional testing. The goal is simply to verify that security controls (functions) present in the component or system work as expected.​ For example, functional security testing may be used to verify that the access control list prevents data flagged as being private to one user cannot be read by another user.​ Unlike penetration testing (see below), the test is prescribed and special creative efforts to circumvent the control are not employed.

• Traffic Management Web Portal Use Case – Functional security testing of a web portal would involve basic functional security requirement verification. For example the tester would confirm that the login page rejects an incorrect password. The tester would also confirm that if an unauthorised user enters the URL of a restricted page, access is denied.

Penetration Testing

Sometimes referred to as ‘ethical hacking’, penetration testing is the most well-known and widely misunderstood security test. A penetration test is a manual test carried out by highly trained specialists using a variety of tools and following a tailored test plan. The aim of a penetration tester is to violate the security goals of a system by finding creative ways to circumvent any security controls that may be in place.

Because penetration testing is relatively expensive, penetration testers are often given a baseline level of ‘insider’ knowledge of and access to the system depending on the type of penetration test (e.g. ‘transparent’ vs ‘black box’). This saves time and money by assuming (rather than demonstrating) that an attacker would eventually be able to gain a certain amount of information or access given the right motivation and capability.

• Traffic Management Web Portal Use Case – In the case of penetration testing, the tester would go above and beyond simply confirming that the basic security functional requirements of the web portal are met. They would consider the security goals, for example that it should not be possible for unauthorised commands to be sent to traffic equipment. Then they would attempt to find system-level vulnerabilities that allow them to violate that security goal. If they cannot send a command via the web portal, they may find a way to take control of the web portal’s server. If the system assumes that commands coming from that server have already been authenticated, then the attacker may be able to send commands without an authorised account.

After penetration testing, regression testing may be required. This is not a full repeat of penetration testing. Instead, only the specific activities that led to the discovery of the hidden vulnerability are repeated.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#11 Managing your connected place’s privileges #13 Managing your connected place throughout its life cycle

During the installation of a smart street system, the installer may need to put temporary user accounts and credentials in place or open vulnerable ports and services that would not be needed in normal service. The commissioning plan should account for this and ensure that these measures are removed/undone before final commissioning.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#2 Understanding the risks to your connected place #4 Understanding your suppliers’ role within your connected place #13 Managing your connected place throughout its life cycle

A documented security case allows the system integrator to demonstrate to the authority that the system has been designed, built, tested and commissioned securely. It shows how all security activities and artefacts are linked and how they support the security goals and claims that make up the security case.

The authority and the system integrator should agree a format in which to present the security case. Usually, a security case can be documented as a series of matrices linking artefacts such as security plans, designs, policy documents and test results to requirements, and requirements to goals and claims.

The authority would usually need to approve the security case and accept any residual risk before a system goes into operation.