How the Security Definition phase is carried out will vary depending on the criticality of the project and whether the authority is architecting the solution or going directly to market with a problem statement.

For an authority architecting a high-level solution in-house for a high criticality project:

  • Discover and determine legal requirements.
  • Segment the system architecture into zones and conduits.
  • Conduct a high-level threat and risk assessment of the zone and conduit model.
  • Define security requirements for each zone and conduit in order to mitigate the identified security risks to an acceptable level.
  • Compile a security requirements specification in preparation for procurement.

For other cases:

  • Discover and determine legal requirements.
  • Analyse the proposed system.
  • Consider which security standards and guidance to reference in the security specification.

 Applicable to:  Owned and managed services
NCSC Connected Places CS Principles:
#5 Understanding legal and regulatory requirements

Before it is possible to fully identify all cyber security risks, it is necessary to identify any regulations that impact the project. For a smart streets project, the first resource is usually the legal compliance team. The project team should work with the legal compliance team to identify whether any cyber security regulations such as GDPRor the Network and Information Systems Regulations 2018 (NIS) apply. However, cyber-attacks could also result in breaches of other applicable regulations such as safety or environmental, so these should also be kept in mind when preparing to assess the system.

Some regulations may prescribe the application of certain security measures or assurance activities, so if any such measures are discovered, they should be added to the security requirements specification. The Electric Vehicles (Smart Charge Points) Regulations 2021 is one example.

 Applicable to:  In-house architecture design
NCSC Connected Places CS Principles:
#6 Designing your connected place architecture

Following principle #6 of the NCSC Connected Places Cyber Security Principles, “designs need to take into consideration the logical separation (or ‘zones of trust’) of your connected place network and identify critical security boundaries.“

The standard approach to securing operational systems according to international standards such as IEC 62443is to partition the system into zones and conduits.

A security zone is a group of hosts (i.e. networked devices) that can exchange data with each other without network-based security restrictions. A single set of security requirements and policies apply to a security zone. The security zone is usually realised by a subnetwork (i.e. subnet) or virtual private network (VPN). Hosts may be placed in the same security zone because they have related functions, are located in the same physical location, need to be on the same subnet for technical reasons, or some other reason that is considered appropriate by the system architect and security architect.

A conduit is a logical data path between two security zones. Security controls are placed on a conduit to control communications between the two zones. A conduit is usually realised by a firewall.

The security zone and conduit model is a tool that makes it easier to assess and securely design a system.

Consider where you would place security controls between assets in this simple example model.

Partitioning assets into different zones allows you to identify where you want to place access controls between systems such as firewalls and user authentication. Consider the above example. Assets in the public sphere will naturally go into different security zones than assets back in private control centres and server rooms. They need to connect to other security zones via the internet zone, and so security controls will certainly be required. Some systems may both sit in your own controlled environment, but serve different types and criticalities of data and function. These should also be in separate security zones. For example, while the Fines and Payments Administration system consumes data from the ANPR database, it should not be given unrestricted access, because the ANPR database contains a large amount of personal data that could be accessed if the human-facing administration system was compromised. General IT systems in the Local Authority Enterprise Systems zone have unrestricted access to the public internet. Therefore strict controls should be placed between that zone and more sensitive zones.

NCSC principle #6 has further guidance on security zoning techniques.

 Applicable to:  In-house architecture design
NCSC Connected Places CS Principles:
#2 Understanding the risks to your connected place

One of the most important steps in securing any system is the threat and risk assessment (TRA). It is essential to identifying, and later managing, cyber security risk. The TRA is a living concept that evolves over the lifecycle of the system. The high-level TRA is the first iteration, and is used to develop high-level security requirements.

The process of a high-level TRA involves identifying the:

  • Scope of the system under consideration.
  • Stakeholders that can contribute technical, security and/or operational knowledge.
  • Operational environment of the system including assumptions and constraints.
  • Protection goals (i.e. the data that needs to be protected).
  • Types of attackers considered in the threat model.
  • Likelihood and impact scale definitions.
  • Risk level definitions.

A workshop or series of meetings is usually held to work through the TRA to identify security risks.

Carrying out a TRA is a specialist activity that usually requires a trained moderator. Unless this specialist resource is available within the authority, it is highly recommended that a third-party specialist lead this activity. This could be outsourced as a specific task to a professional security consultant or as part of the outsourcing of the system development to a system integrator.

The IEC 62443-3-2 standard provides further guidance on the TRA process.

Guidance on Protection Goals

The authority should consider why security is important to enable the systems of interest. As a minimum, you should consider the potential impacts on stakeholders if confidentiality integrity or availability of data were compromised. This is known as the CIA model. Data can include operational commands, engineering/configuration data, intellectual property, payment data, personal data or any other relevant information stored in or travelling through the system. It may be necessary to consult with other stakeholders in this process.

Where there is a potential impact that stakeholders feel is relevant, a protection goal should be defined. Some example security goals are given below:

  • Ticketing Payment System – Security Goals
    • Maintain confidentiality of payment details
      • Loss of confidentiality would result in regulatory breaches, financial and reputational loss for stakeholders.
    • Maintain integrity of payment confirmation messages
      • Loss of integrity would lead to revenue loss due to the system to generating tickets without confirming appropriate payment.
    • Maintain availability of ticketing system
      • Loss of availability of ticketing system would lead to service disruption and revenue loss.
  • Traffic Controller – Security Goals
    • [No confidentiality goal]
    • Maintain integrity of engineering/configuration data and control messages.
      • Loss of integrity would result in a safety incident.
    • Maintain availability of traffic controller
      • Loss of availability would lead to traffic disruption with effects cascading to other stakeholders.

The CIA model is referenced by NCSC Connected Places Security Principle #2. However, it is equally common in the industry to find an extended version of this model called the STRIDE. Although more complex, STRIDE explicitly considers a wider range of attacks, which makes it more versatile.

Attack Types Violated Property
Spoofing User/Service Authentication
Tampering Data/Communication Integrity
Repudiation Non-Repudiability of Actions
Information Disclosure Data/Communication Confidentiality
Denial of Service Service Availability
Elevation of Privileges User/Service Authorisation

Table showing how CIA model was expanded to become STRIDE.

Whichever model you or your supplier use, the risk assessment should recognise that the vast majority of cyber damage scenariosPotential impacts if a cyber attack scenario were successfully executed. ultimately come from confidentiality, integrity or availability loss, but that attacks on those properties often comes after an initial attack on authentication or authorisation.

 Applicable to: In-house architecture design
NCSC Connected Places CS Principles:
#6 Designing your connected place architecture
#7 Designing your connected place to reduce exposure
#8 Designing your connected place to protect its data
#9 Designing your connected place to be resilient and scalable
#10 Designing your connected place monitoring

According to the NCSC’s Connected Places secure design principles, “having developed understanding and context for your connected place, the priority should now be to make compromise difficult for any attacker.“

The TRA should be reviewed between the risk owner, responsible engineer and the security specialist. They should agree which risks the project should aim to mitigate and to what extent. The responsible engineer (potentially with the support of the security specialist) should then select security controls from a standard control set such as IEC 62443-3-3.

It may not be possible to mitigate or eliminate certain risks without changing the system architecture. In this case, the TRA should be updated once the architecture has been revised.

Security Concept
Secure Procurement