SECTION 2.3
Security Concept

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#1 Understanding your connected place and the potential impacts

During the smart street project vision stage, formal project management including project security management has not yet begun. However, it is recommended that a person with a strategic responsibility for cyber security be involved in the development of the project vision. This is because one of the impacts of the transformational change brought about by a smart street will almost certainly be changes to the cyber security risks faced by the organisation. Involving someone with cyber security responsibility will ensure that they have a view of the coming changes and can contribute to early risk identification and management.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#3 Understanding cyber security governance and skills #4 Understanding your suppliers’ role within your connected place

Every smart streets project should have at least one role with clearly defined cyber security responsibility. Smart streets projects vary significantly in size. The following table gives an example of a RACI (responsibility assignment matrix) diagram for a typical smart streets project.

Role	Type	Description
Project Manager	Accountable	The Project Manager is accountable for ensuring the project is carried out in accordance with the organisation’s Security Assurance procedures and that the project has a secure outcome.
Responsible Engineer	Responsible	The Authority’s Responsible Engineer for the project is responsible for creating and executing the Project Security Assurance Plan.
CISO and cyber security professionals in the organisation	Consulted	The organisation’s senior manager responsible for cyber security (and, where applicable, the organisation’s cyber security specialists) will be consulted regarding progress and decisions made around cyber security.
Engineers responsible for other domains with cyber security relevance	Consulted	Engineers involved in the project with responsibility for the delivery of other domains (e.g., networks, traffic signals, etc.) will be consulted to ensure technical alignment.
Asset Owner	Informed	The owner of the smart street system within the authority is informed of the cyber security risks, as they will ultimately determine whether they are acceptable.

Example smart streets project security RACI diagram for the Security Concept phase.

Some authorities or projects have very little in-house engineering capability. In this case, the project manager should hold both accountability and responsibility for cyber security. This responsibility can later be delegated once a supplier is brought onboard. When there is an engineering layer present, accountability and responsibility is best split between the project manager and an appropriate engineer.

For the remainder of this guidance, we will simply refer to the role responsible for security as the Responsible Engineer, regardless of whether the role is filled by a non-engineer.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#1 Understanding your connected place and the potential impacts #4 Understanding your suppliers’ role within your connected place

Part of the “Define Needs” stage of the MfSS lifecycle is to carry out a high-level assessment of existing systems that will need to be affected to achieve the project goals. The Responsible Engineer should review the current state of systems used from a security perspective. The aim should be to address certain questions such as:

• How do we manage the security of the services we currently provide?
• How do we currently ensure our suppliers are resilient against cyber-attack such that local transport services are not disrupted?
• How effective has the cyber security approach been so far? (e.g., Have there been any incidents? How have they been dealt with?)
• Are there concerns/issues with security elements of current systems?

Further questions to consider can be found in principle #1 of the NCSC Connected Places Cyber Security Principles.

The Responsible Engineer should then analyse the problem and high-level solution from a security perspective and identify where cyber security may be needed as an enabler. Identify any cases where:

• Greater connectivity, automation, and data interdependence is required.
• A greater reliance on personal data is required.
• Critical or sensitive data is more exposed.
• New systems have otherwise been introduced.

In these cases, carry out a high-level assessment of the existing systems being impacted. Are the ways you currently manage cyber security fit to handle such transformational change? Do the existing security goals need to be modified or expanded? Expand the problem statement with cyber security considerations based on your high-level assessment and other relevant information gathered in the previous stage.

If your authority has implemented recommendation A4, use this understanding to complete the security questionnaire and determine the security criticality of the project.

Consider the example of a project where a third party is bringing a new mobility-as-a-service (MaaS) app to the region. It requires traffic data and will also provide data about the travel habits of its users. The project team recognises that connectivity with the Traffic Management System is required. The Traffic Management System was originally designed without connections to any third-party services. Given the introduction of greater connectivity, you expand the problem statement to include that the Traffic Management System must be protected from malicious data.

Applicable to:	Owned and managed services

NCSC Connected Places CS Principles:

#1 Understanding your connected place and the potential impacts #3 Understanding cyber security governance and skills #4 Understanding your suppliers’ role within your connected place

With an understanding of the security criticality of the project, the Responsible Engineer should generate a Security Assurance Plan that reiterates the security problem statement and sets out planned high-level security activities and the outputs from those activities (security deliverables). It should be clear how each of those deliverables will come together to support the security case of the system.

This task should not be taxing on the responsible engineer. The authority’s security accreditation framework should make it clear what high-level activities and outputs are. The Responsible Engineer merely needs to define who will be responsible (e.g. authority or supplier).

The split between authority and supplier responsibility will depend on the project. For example, in some cases, authorities design a generic high-level architecture of a system before putting the system out to tender. In this case, the authority may perform the initial high-level security solution architecting themselves. In other cases, the authority may wish for a supplier to architect the solution, in which case those security activities would be the responsibility of the supplier. The same considerations apply for whether the authority or a supplier will be operating the system.

The purpose of this task is that the project can supply the plan as part of the tender specification so that the supplier has a clear understanding of the high-level security activities the authority expects to be carried out.

Authorities should produce a template security plan aligned with their security accreditation framework so that this activity can quickly and easily be completed by the project.