SECTION 2.7
Secure Operations

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#12 Managing your connected place’s supply chain #13 Managing your connected place throughout its life cycle

Over time, new vulnerabilities may impact your system. These may be existing vulnerabilities that re-appear in your system for various reasons, or new vulnerabilities that are discovered by specialists, researchers or malicious parties. These vulnerabilities should be detected through a combination of both monitoring vulnerability disclosures and conducting security testing.

Recommendation E3 explained the different types of security testing. Security testing remains relevant during the operation of the system. While a system is in operation, change can occur.

Periodic Vulnerability Scanning and Compliance Testing (Low-Cost)

Change may be introduced, accidentally or intentionally, in the maintenance or modification of the system. Conducting a regular vulnerability scan and/or compliance test is an effective and low-cost way of detecting whether a vulnerability has been introduced in this way.

The vulnerabilities that are being scanned on should be based on a source that is updated from time to time, as new vulnerabilities

Periodic Penetration Testing (High-Cost)

The threat landscape is also continuously changing. New vulnerabilities and new ways of compromising systems are always surfacing. Periodic penetration testing helps identify when such a change may impact your smart street system. However, due to the cost involved, periodic penetration testing is usually reserved for high-risk or critical systems.

Vulnerability Notification and Disclosure

The authority should have an agreement with suppliers around vulnerability notifications and disclosure. System integrators and other vendors following good practice will do this. When vendors become aware of a vulnerability in one of their products, they will provide related information to those product users who have an agreement. The authority may receive these notifications directly and manage them entirely in house, or a system integrator may receive them and prepare their own tailored notification for the authority.

Reacting to a New Vulnerability

How stakeholders react to a newly discovered vulnerability depends on the contractual relationships in place.

Where Service Provider is Responsible

Where the solution is considered software-as-a-service (SaaS; e.g. the ‘cloud’), the operator of that service should update the risk assessment considering the new vulnerability and determine if an action is required. Where the vendor makes a patch available, this may be a matter of deploying that new patch. If a patch is not available, or the risk cannot be addressed by a patch, then new security measures may need to be put in place.

Authorities should be careful to ensure agreements around cloud-based services include details around how vulnerabilities will be managed by the service provider.

Where Authority is Responsible

Where the system is owned by the authority, the authority is generally responsible for assessing the impact of the vulnerability and deciding what action to take. This is why it is important that the security risk assessment is handed owned by the authority while they operate the system. The authority should revisit the risk assessment and consider how it is changed by the vulnerability. Consult with the vendor to determine whether a patch is expected. If the vulnerability cannot be addressed by a patch, new security measures may be needed.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#12 Managing your connected place’s supply chain #13 Managing your connected place throughout its life cycle

Security patches may be released for components that comprise the smart streets system from time to time. These patches are intended to address known vulnerabilities. For more information on vulnerability management, see recommendation F1.

When to Deploy a Patch

When a security patch is released, the vendor may or may not disclose what vulnerabilities are addressed by the patch. This is because some vendors do not wish to advertise this information to attackers. As discussed in F1, the authority may have an agreement in place with the vendor to privately disclose this information.

If the authority is aware of what vulnerabilities are addressed by a patch, they may choose to assess the impact of the vulnerability before deciding to go through the effort (and potential disruption) of patching. If the authority is unaware, then it is usually advisable to plan for deployment.

How to Deploy a Patch

There are often challenges and risks when deploying patches to operational systems like those used for smart streets. For more critical systems, the availability of the system is important. Patching may necessitate taking they system offline. Smart streets systems can be complex, and a new patch may unexpectedly impact system integration due to poorly documented or unassessed changes introduced by the patch. Devices making up a smart street system such as network switches, CCTV cameras, or variable message signs may be geographically distributed. This can make it difficult to deploy the patch.

The best way to address these challenges is to ensure the system is designed with a patching strategy in mind. This may involve plans to have a standby system while patching, to perform integration testing on a patch before deployment, and to be able to remotely deploy patches to various types of hardware.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#10 Designing your connected place monitoring #13 Managing your connected place throughout its life cycle

It is often infeasible to completely design security risk out of systems. Security monitoring helps address this fact.

The IT security team at your authority may already have some security monitoring considerations in place for corporate IT systems. This may involve logging/diagnostic data being forwarded by computers to a Security Information and Event Management (SIEM) server. The SIEM will process the log data and raise alerts according to a ruleset.

SIEM or other security monitoring tools are not useful unless there is a plan to react to a suspected cyber incident. The organisation should have a ‘playbook’ in place for this (see recommendation F4).

For smart streets systems, the authority should consider whether security monitoring would provide significant risk mitigation benefit. If so, the authority should then consider whether smart streets system security monitoring could be integrated with the existing corporate security monitoring solution. This usually depends on the combined criticality and speciality of the service being provided. For example, a traffic control system has a relatively high criticality level, and it also requires some specialist knowledge to understand the wider impacts of taking certain actions in response to a suspected cyber incident.

Whether the existing solution is leveraged or a new solution is found, staff involved in security monitoring and response will need to have some awareness of the smart street service being provided. Likewise, staff involved in smart street operation should have some awareness of cyber security incident handling. This way, both sides will be able to effectively communicate.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#12 Managing your connected place’s supply chain #14 Managing incidents and planning your response and recovery

Another way to address the fact that security risk cannot be completely designed out of systems is to prepare for the eventuality that an attack is launched against your system. An authority can plan to carry out occasional tabletop exercises around a simulated cyber security incident. Such an exercise is intended to test your ‘playbook’, identify how well prepared staff are to react and communicate in a scenario and generate lessons learned to feed back into the security programme.

Authorities may consider engaging their system integrator / service provider and other stakeholders to participate in such an exercise, as the lessons learnt benefit the industry as a whole.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#12 Managing your connected place’s supply chain

An authority should have an expectation of its Tier 1 supplier’s (i.e. primary supplier with which they have a direct relationship, such as a system integrator or service provider) security programme. This may be because the authority set requirements for the security programme based on a standards or because their is an understanding of industry good practice. An authority can and should audit the security programmes of their Tier 1 suppliers to assess the supplier’s compliance with requirements or adherence to good practice.

Define the Scope of the Audit

The authority should identify which smart streets stakeholders are subject to audit and what they will be audited against.

Where there is a Tier 1 contractor, this would generally be the stakeholder directly subject to the audit. The contractors own suppliers would not need to be audited by the authority. Instead, the authority should verify that the Tier 1 is properly managing the security of their supply chain, perhaps with their own audits.

The authority should consider taking a standards-based approach to the audit. That means identifyting standards that are relevant to the service such as IEC 62443, ISO 27001 or PCI DSS, picking out which parts of those standards are relevant to the service and are the responsibility of the supplier, and using those parts as the framework for the audit. Considering the framework, the authority should make a list of assessment criteria.

Review Documentation

The authority should set out the criteria to the supplier and request an explanation of how the supplier addresses the point along with some supporting documentation to demonstrate. The auditor should consider whether their statement fits the assessment criteria and whether the documentation supports the statement.

Conduct On-Site Visit

It may not be possible to verify all statements with documentation (e.g. when auditing physical security measures or staff behaviour-related policies). In such cases, an on-site visit can be carried out by the auditor. Because on-site visits increase costs and may cause operational disruption, the authority should take a risk-based approach to deciding when on-site visits are required.

Evaluate Security Controls

The audit should ask questions about what security controls are in place to protect the security goals. The auditor should consider the effectiveness of these controls. This might involve a paper exercise where a risk assessment is reviewed. However, for critical services, the authority may want to have a penetration test carried out. See section F1 for further information.

Report Findings and Follow Up

Following the review of supplier documentation, the on-site visit (where applicable) and the evaluation of security controls, the auditor should produce a report documenting the findings of the audit, including any areas of non-compliance and recommendations for improvement. The auditor should also include an expectation of the timeline for an issue to be resolved.

The authority should follow up with the supplier to ensure that recommendations are implemented in a timely manner.