Rail Code of Practice for Security-Informed Safety

1.1.1 Organisations should formulate a policy on security-informed safety that sets out their overall stance and aims with respect to ensuring that security is considered as part of their approach to managing safety risks.

1.1.2 The policy should recognise that the organisation has a responsibility to ensure that security threats do not pose unacceptable risks to safety.

1.1.3 The policy should ensure that the impact of security on safety is addressed by the organisation and its partners and suppliers, throughout all phases of the product and service lifecycle. NOTE: The policy should cover how to manage security incidents that arise during operation. Further guidance on incident management can be found in Section 4.

1.1.4 Organisations should define and implement processes to support their policy on security-informed safety.

NOTE: In general, processes should be flexible rather than prescriptive and organisations should only prescribe particular methods if there is a sound business case for doing so.

Keeping processes flexible makes organisations more agile and able to adapt to emerging best practice. However, in some cases, there may be a compelling reason to adopt a particular method (e.g., regulatory compliance, industry standards).

1.1.5 Policies and processes on security-informed safety should consider technical, procedural and managerial measures for mitigating security threats.

NOTE: Security is not purely a technological problem.

In order to ensure robust protection, it is important to consider procedural and managerial aspects of security as well.

1.1.6 Organisations should take steps to ensure that their policies and processes for ensuring security-informed safety are described, communicated, and implemented effectively.

NOTE: Guidance on developing policies and processes can be found in the NCSC CAF guidance [17], specifically, Objective B.1: Service protection polices and processes.

1.1.7 Organisations should have mechanisms in place to validate the implementation and effectiveness of their policies and processes for ensuring security-informed safety.

NOTE: The Common Safety Method for Monitoring [6] requires organisations to monitor the effectiveness of their safety management systems.

1.1.8 Sufficient documentary evidence should be produced to enable decisions relating to security and safety to be reviewed and justified in the future.

NOTE: An important consideration is the ability, following an incident, to justify the organisation’s approach to security and safety and relevant decisions.

1.1.9 Records of decisions relating to security and safety should be preserved for a sufficient period of time to allow for the occurrence, detection and investigation of safety and security incidents.

NOTE: The retention period might be different for different types of evidence. The organisation might wish to consider the expected lifetime of its products, systems and services to inform this decision.

1.2.1 Accountability for security and safety issues that might affect the organisation’s products and services should be clearly defined, and traceable to board level.

NOTE: The board can delegate responsibility for decisions about security and safety issues but must remain accountable for the organisation’s overall approach to security and safety.

1.2.2 A member of the board or equivalent senior person should be responsible for defining the organisation’s overall programme of work on security-informed safety.

1.2.3 A senior manager should be responsible for implementing the security-informed safety programme in the organisation.

NOTE: Responsibility for implementing particular aspects of the security-informed safety programme can be delegated to clearly identified individuals with specific job descriptions and responsibilities. Individuals can be identified by role or by name.

NOTE: This section is concerned with managing the impact of security threats on safety risks associated with the organisation’s products and services. Typically, organisations consider all risks to their business, including commercial, financial and reputational risks, as well as safety and security risks, but here we focus on safety risk management, specifically the management of safety risks that result from security threats.

1.3.1 Organisations should adopt a formal, holistic, approach to identifying, assessing and managing the impact of security threats on the safety risks associated with their products and services.

NOTE: For some products and services, it may also be appropriate to consider the impact of security threats on reliability and availability, particularly in situations where the reliability or availability of the system may have safety implications.

1.3.2 The safety policy should document the organisation’s overall approach to addressing the impact of security threats on safety risks, setting out its commitment to manage such risks effectively and defining responsibilities accordingly.

1.3.3 The safety policy should articulate the organisation’s appetite towards safety risks caused by security threats, so that decision-makers at all levels of the organisation can make informed decisions about risk acceptance.

NOTE 1: Under the Health and Safety at Work Act [18], organisations must ensure the safety of people affected by their undertaking so far as is reasonably practicable (SFAIRP). Organisations may, voluntarily, reduce risk beyond what is legally required (e.g., for reputational reasons).

NOTE 2: Cyber attack poses a growing threat to the security and therefore the safety of critical infrastructure, including the railway networks. Rail operators have obligations under UK law to protect the safety of their operations. Failure to take reasonable care to do so may make them liable for some of the resulting losses [2].

1.3.4 The safety policy should document the organisation’s approach to resolving conflicts between safety and security, which can occur at any stage of the product/ service lifecycle.

1.3.5 The safety policy should require any conflicts between safety and security that are identified to be recorded, together with the decision and rationale for resolving the conflict. NOTE: Further guidance on managing conflicts between safety and security can be found in Appendix D.

1.3.6 Organisations should identify, assess and understand the impact of any assumptions they make regarding the prevalence, capabilities and motivations of threat agents on their demonstration that risks are tolerable.

1.3.7 The risk management process should consider risks to the safety and security of products, services and activities arising from threats to physical security.

NOTE: Guidance on physical security is available from NPSA [19].

1.3.8 The risk management process should consider risks to the safety and security of products, services and activities arising from threats from people who have access to systems, including contractors and maintenance personnel, as well as the organisation’s own staff.

NOTE: Guidance on personnel security is available from NPSA [20].

1.3.9 The risk management process should consider risks to the safety and security of products, services and activities arising from cyber threats.

NOTE: Guidance on cyber security is available from NCSC [21].

1.3.10 The safety case for products, services and activities should provide assurance that security threats to safety have been adequately managed.

1.4.1 Assets that are used to deliver, maintain or support the security and safety of an organisation’s products and services should be identified and recorded. The information that is recorded should include an indication of the importance of the asset to achieving safety and security.

NOTE: ‘Assets’ includes data, people and systems as well as any supporting infrastructure, and can be tangible or intangible.

1.4.2 This record of assets should be updated whenever such assets are added, removed or changed, and should be periodically reviewed to ensure that it remains up-to-date and relevant.

NOTE: The frequency of review may depend on the nature of the asset and how often its importance to safety and security might be expected to change.

1.5.1 Organisations should assess the impact of security-related risks on the safety of legacy systems and update their risk assessments for legacy systems accordingly.

NOTE: Legacy systems may not have been designed with security in mind and therefore need additional security measures to ensure adequate protection against attack.

1.5.2 The risk assessment of legacy systems should cover their current state through to decommissioning and disposal.

1.6.1 Organisations should assess and manage security risks arising from external dependencies on suppliers, sub-contractors, and service providers.

NOTE 1: This includes ensuring that appropriate measures are employed where third-party services are used.

NOTE 2: ISO 28000 provides a means of implementing a security management system for supply chains.

1.6.2 Organisations should integrate the management of supply chain risks into their lifecycle processes, including specification, design, procurement, implementation and testing.

1.6.3 Organisations should have a process for managing the disclosure of potentially sensitive information to the supply chain in order to mitigate the risk of such information being misused.

NOTE: Section 1.9 discusses the protection of information assets in more detail.

1.6.4 Organisations should assess, and periodically re-assess, the security of their suppliers. The frequency of re-assessment should be determined by the organisation’s security policy.

1.6.5 Organisations should ensure that suppliers have an appropriate policy and programme in place to manage risks to the safety and security of their products and services.

NOTE: Possible means of ensuring this include audits and external accreditation. Consider requiring all suppliers to be accredited to a standard such as Cyber Essentials [22],EN ISO/IEC 27001 [23] or IEC 62443-2-4 [24].

1.6.6 Organisations should include security requirements and requirements for good security engineering practice in procurement contracts with suppliers, and ensure that such requirements are cascaded down the supply chain as necessary.

NOTE 1: One way to comply with this clause is to require suppliers to comply with all or part of this CoP.

NOTE 2: Further guidance on supply chain security is available from NPSA [25] and NCSC [26].

1.7.1 All personnel should be aware of security issues relevant to their role and should receive training to ensure they have the necessary knowledge and competence.

NOTE 1: The level of training needed will vary depending on the role, but it is likely that all personnel will need at least a basic level of security awareness training.

NOTE 2: The NCSC Certified Training scheme [27] certifies two levels of cyber security skills training:

• Awareness level - giving newcomers a thorough foundation in cyber security
• Application level - in-depth courses for professional development

1.7.2 Personnel that are responsible for the design, development, manufacture, delivery, operation or maintenance of safety-related products and services should have the information, knowledge, and skills they need to perform their roles securely.

1.7.3 Organisations should assess the need for specialist security expertise, and develop or contract such expertise as needed.

NOTE: This might include roles such as security architect, security risk assessor, penetration tester.

1.8.1 Organisations should promote a healthy security culture among those responsible for the safety of their product and services.

1.8.2 Communication channels for security matters relating to the organisation and its services and products should be established.

1.8.3 Where responsibilities for safety and security have been separated within an organisation, the organisation should promote cooperation and collaboration between the two groups.

NOTE: An example of such a measure would be a joint review of a product or service for security-related safety issues at an appropriate point in the design and development process.

1.9.1 Organisations should ensure that the security of information, documentation and data whose compromise could affect the safety of their systems is maintained.

NOTE 1: Unauthorised disclosure of such information can significantly increase safety and security risks, as it can assist in identifying vulnerabilities. For example, detailed information about the security controls in the system design might help an attacker to successfully compromise a system.

NOTE 2: Information in both electronic and physical form should be protected (e.g. laptops, mobile devices, USB sticks, cloud storage, paper copies).

1.9.2 Organisations should formulate a procedure for classifying, labelling and handling security-related information and documents.

NOTE: Guidance on information classification, labelling and handling can be found in clause 8.2 of EN ISO/IEC 27002 [28].

1.9.3 Information with an HMG security classification should be handled in accordance with HMG security policy [29].

1.9.4 Information released to third parties (e.g. contractors, suppliers, maintainers) that could be used to compromise an organisation’s security or the security of its systems should be appropriately classified and labelled, and the receiving party should be required to handle the information in accordance with its security classification.

NOTE: Examples of requirements for information handling could be the length of retention, the process to be followed for release and the measures to be taken to protect the information.

1.9.5 Information and documents received from other organisations should be handled in accordance with any security-related classification or labelling.

2.1.1 For all products and services, each phase of the lifecycle should be analysed to:

1. establish its role in delivering a safe and secure system
2. identify opportunities in the lifecycle to consider the security of the service or product
3. identify opportunities to introduce security measures in the lifecycle

NOTE 1: Some publications offer guidance on incorporating security into a safety lifecycle. For some cases, it may be sufficient to follow the guidance. Examples of such publications include IEC TS 62443-1-1 [31] and BS 10754-1:2018 [16].

NOTE 2: In the railway context, PD CLC/TR 50701 [4] identifies specific cybersecurity activities to be carried out during the lifecycle of a railway application, together with synchronisation points to ensure coordination with other stakeholders.

2.1.2 The lifecycle and supporting processes should be modified as needed to ensure that adequate consideration has been given to security issues and that a set of measures are implemented to ensure that a safe and secure product or service is produced.

NOTE 1: The measures to be deployed will depend on the specific situation. Examples include:

• aligning security and safety activities with project management gateways
• including iterative security assurance activities
• aligning safety and security approval and sign-off activities

NOTE 2: The production of a complicated system such as a railway signalling system requires a number of interlocking and integrated lifecycle processes. ISO/IEC/IEEE 15288 [32] identifies 30 system lifecycle processes, which are divided into four groups:

1. agreement processes,
2. organisational project-enabling processes,
3. technical management processes; and
4. technical processes.

NOTE: PD CLC/TS 50701 describes an approach to cyber security risk assessment and requirements definition based on the IEC 62443 series of standards. More general guidance on risk assessment is given in Appendix A.

2.2.1 A detailed risk assessment should be performed on the proposed architecture of any new product or service (or modifications thereof) to identify any potential vulnerabilities or security risks that might affect the safety of the overall railway system.

NOTE: Established techniques for performing risk assessments can be found in NCSC’s Risk Management Collection [33].

2.2.2 If the product or service depends on components or services procured from third parties, the risk assessment should consider the potential impact of contamination, faults or vulnerabilities in those components or services on the safety and security of the overall product or service.

NOTE: Contamination of computer-based components can take the form of malicious code or unauthorised modification to data, for example changes to configuration and reference data. In both cases, the outcome could be that the component operates in an unsafe manner.

2.2.3 The risk assessment should consider the potential effect of security incidents on the safety of the product or service.

NOTE: Although security incidents can be causal factors leading to hazards, the impact of a security incident on functional safety can be extremely difficult to predict. An alternative approach is to consider security incidents as hazardous events that can lead to multiple outcomes and potentially affect reliability and availability as well as safety.

2.2.4 The risk assessment should consider the risks posed by the following classes of attacks:

1. technical (e.g. hacking)
2. socio-technical (e.g. social engineering)
3. supply chain (e.g. substitution of components)
4. physical attacks (e.g. destruction of equipment)

NOTE: Although security incidents can be causal factors leading to hazards, the impact of a security incident on functional safety can be extremely difficult to predict. An alternative approach is to consider security incidents as hazardous events that can lead to multiple outcomes and potentially affect reliability and availability as well as safety.

2.2.5 The risk assessment should consider interactions, conflicts and trade-offs between security and safety. In general, safety should take precedence over security, unless the risks of an insecure system are considered to be too great.

NOTE 1: Safety is reliant on integrity, so preserving integrity should generally take precedence over preserving availability and confidentiality. Depending on the context, it may also be important to preserve availability.

NOTE 2: Further guidance on trade-offs between safety and security can be found in Appendix D.

2.2.6 The risk assessment should take interdependencies between systems and services into account and consider the potential impact of simultaneous failures and their consequences.

NOTE: This includes the possibility of cascade failures.

2.2.7 The risk assessment should allow for the possibility that changes to network connectivity (whether introduced maliciously or as a side-effect of another activity) could circumvent security measures.

NOTE: Air gaps merit particular attention in this context. An ‘air gap’ is a security measure where a computer system is physically isolated from other systems. The ‘air gap’ can be bypassed if a network connection is added.

2.2.8 To allow for the possibility of unknown network connectivity, the risk assessment should consider the entire system to be accessible to cyber attack unless network isolation can be guaranteed.

NOTE: This implies that the network should be treated as open by default (see Appendix E for more information on network security). Based on experience, network isolation is very difficult to maintain in the long-term, so erring on the side of caution is a sensible strategy.

2.2.9 The risk assessment should include risks posed by malicious actors who aim to cause deliberate harm, as well as risks posed by malicious actors who may incidentally cause harm as an unintended consequence of other activities.

NOTE: Examples of activities that might cause incidental harm as an unintended consequence are espionage, ransomware and cryptocurrency mining.

2.2.10 The risk assessment should include risks posed by non-malicious actors who might inadvertently cause harm as an unintended consequence of their actions.

NOTE: Examples of actions that might inadvertently cause harm include introducing an infected USB drive or choosing a weak password.

2.2.11 The risk assessment should be periodically reviewed throughout the lifetime of the product or service to allow for the potential impact of evolving security threats and the discovery of exploitable vulnerabilities on the safety of the system.

NOTE: The capabilities required for a successful attack are likely to decrease during the lifetime of the system, as attacks that are currently only within the capabilities of nation states become commoditised, so the system or service needs to be able to respond to changes to the threat profile.

2.2.12 The risk assessment should be used to derive appropriate requirements to mitigate the effect of the identified risks on safety and security.

2.2.13 The requirements derived from the risk assessment should include security requirements to mitigate the safety risks posed by threat agents to an acceptable level.

NOTE: See clause 1.3.3 for guidance on how to determine what is acceptable.

2.2.14 When a system (or service) is composed of subsystems (or other services), security requirements should be propagated to the specification of each subsystem (or service).

2.3.1 The product or service should be designed to be fail-safe and secure by default.

2.3.2 The design should address security and safety throughout the lifetime of the product or service.

2.3.3 The design should consider the potential impact of component vulnerabilities on the product or service, and include appropriate mitigations.

NOTE: Further guidance on secure design principles can be found in Section 5.

2.4.1 The product should be manufactured in such a way as to prevent its safety or security being compromised by threats during the manufacturing process. NOTE: Guidance on securing manufacturing systems can be found in PAS 1085 [34].

NOTE: This section provides recommendations for managing risks associated with procuring components from third parties. Recommendations for managing supply chain risks in general can be found in section 1.6.

2.5.1 Reasonable steps should be taken to ensure that all components received from suppliers are authentic and trustworthy.

2.5.2 All new hardware and software should be scanned for malware. NOTE: Cyber security standards in other countries may not be equivalent to those in the UK. Furthermore, some countries may harbour malicious intent towards the UK and its industries. Further advice on supply chain risk is available from NPSA [25] and NCSC [26].

2.5.3 Suppliers should be required to disclose any functionality in their equipment or software that might be capable of compromising the safety or security of the device.

NOTE: Examples of such functionality include the ability for the supplier to transmit or receive data from the device or reprogram the device remotely.

2.5.4 Organisations should decide on a risk basis whether such functionality should be enabled or disabled, and this should be specified as part of the contract.

2.5.5 Suppliers should be contractually obliged to adhere to relevant security standards.

2.5.6 Organisations should include security requirements and requirements for good security engineering practices in procurement contracts and ask for evidence of security features and known vulnerabilities in the procured products.

2.5.7 Organisations should assert the right to audit the development environment and the security of the development, testing, chain of custody and shipping process.

2.5.8 Organisations should ensure that procurement staff are sufficiently knowledgeable in security to be able to articulate requirements correctly.

2.5.9 Organisations that use third-party products and services should ensure that their suppliers check for vulnerabilities and are prepared to issue security patches or updates throughout the lifetime of the product or service, or else state clearly that security patches are no longer provided, in which case the product or service can no longer be considered secure.

2.5.10 Organisations should identify who is responsible for the supply and installation of security patches to third-party products and services that they use in their own products or services.

NOTE: Further guidance on managing product and service updates can be found in clause 3.5.

2.5.11 Organisations should manage risks to the safety and security of their products or services caused by dependencies on third-party products or services that might be discontinued or cease to be maintained.

NOTE 1: If an organisation depends on a third-party product or service that is no longer maintained, there is a risk that future security vulnerabilities discovered in the third-party product or service might provide a means of attacking the organisation’s own products or services.

NOTE 2: Possible steps to mitigate this risk include requiring advance notice of discontinuation, sourcing alternative products and services, and isolating/eliminating the dependency.

2.6.1 Installation of a product in the field should be carried out so that the safety and security of the overall railway system is maintained.

NOTE: It is common for special arrangements to be put in place while installation is carried out, and it is important that these do not offer opportunities to attackers, even if they are temporary in nature.

2.6.2 Equipment suppliers and installation contractors should only be granted access to the system for as long as is contractually necessary.

NOTE: Consider deleting or changing all authentication keys used during installation and acceptance testing before the system is put into operation.

2.7.1 There should be a documented plan for demonstrating that the safety and security of the product or service is adequate, and that security weaknesses do not cause unacceptable risks to the safety of the system.

2.7.2 The product or service should be subject to security analysis and testing, including:

1. system, attacker and threat modelling
2. an analysis for common known weaknesses or vulnerabilities
3. an analysis of whether the proposed security controls are sufficient to mitigate the risk
4. an evaluation of whether the proposed security controls are implemented correctly
5. penetration testing

NOTE: Analysis complements testing – neither can prove security, but both increase confidence.

2.7.3 Where practicable, security analysis and testing should be integrated throughout the development lifecycle.

NOTE: This contrasts with relying on security analysis and testing only after completion of design and development. Continuous or iterative testing allows for potential faults and vulnerabilities to be identified much sooner. 

2.7.4 The product or service should be subject to independent scrutiny to assess whether threats to its security pose unacceptable risks to safety.

NOTE: ‘Independent’ can refer to personnel inside the organisation, but not involved in product or service development, or to personnel from an external organisation.

2.7.5 The degree of security analysis and testing, and the level of independent scrutiny required should be commensurate with risk factors such as the following:

1. the safety criticality of the product or service
2. the level of threat to which the product or service is exposed
3. any known vulnerabilities in the product or service
4. the provenance of the product or service

NOTE: The requirements for independent assessment in safety standards (e.g., EN 50129 [3]) might need to be adjusted accordingly.

2.8.1 For safety-relevant products or services, an assurance case should be produced that justifies that the product or service is adequately safe, despite the presence of security threats.

NOTE: For complete systems, the assurance case will address the safety of the product or service, while for components, the assurance case will address their performance with respect to their specifications.

2.8.2 The assurance case should demonstrate that security threats that could affect safety have been adequately managed and show that the impact of security on safety has been considered throughout the entire lifecycle of the product or service, from initial conception through design, installation, operation and maintenance to decommissioning.

NOTE 1: Further guidance on assurance cases can be found in Appendix B and ISO/IEC 15026 2:2011 [35].

NOTE 2: EN 50129:2018 [3] requires the safety case to ‘describe how IT-Security threats which have the potential to affect safety-related functions have been evaluated and how protection against them has been achieved’.

2.8.3 In cases where a safety-relevant product or service depends on products or services procured from third parties, assurance material should be obtained from the third party and integrated into the overall assurance case.

NOTE 1: It is preferable for the supplier of a component or subsystem to supply their own assurance case, but it is recognised that this might not always be possible for off-the-shelf products.

NOTE 2: Clause 8 of EN 50129:2018 defines the safety acceptance and approval process for safety-related systems, subsystems and equipment. Safety approvals that are granted by one safety authority can be accepted by another safety authority (‘cross-acceptance’), but only generic products and generic applications can be approved in this way. Specific applications always require the full safety acceptance and approval process to be followed.

2.9.1 Railway operators and service providers that are responsible for systems and services that affect the safety of the overall railway system should ensure that those systems and services are operated, maintained, and decommissioned safely and securely.

2.9.2 If responsibility for operation, maintenance, transfer of ownership or decommissioning is delegated to an external organisation, the license or contract should require the external organisation to provide assurance of compliance with all safety and security requirements.

NOTE: The railway operator or service provider remains accountable for the safe operation of the railway.

2.9.3 The operational documentation for the product or service should include security requirements as well as safety requirements in order to ensure that the product or service can be operated safely and securely.

NOTE: This may include operating procedures, constraints on the operating environment, etc.

2.9.4 The maintenance documentation for the product or service should include security requirements as well as safety requirements in order to ensure that the security and safety of the product or service is not compromised during maintenance activities.

2.9.5 The decommissioning documentation for the product or service should include security requirements as well as safety requirements and ensure that any security-related material related to the product or service (e.g. cryptographic keys) is securely removed and destroyed during decommissioning, or whenever the system is repurposed or transferred to a new owner or operator.

3.1.1 Protective measures should be put in place to reduce the risks posed by known vulnerabilities and weaknesses in legacy systems.

NOTE 1: It may not be feasible to fix a known vulnerability in a legacy system, so the presence of the vulnerability must be tolerated.

NOTE 2: The risk of exploiting a vulnerability is determined by its ease of exploitation and the impact of a successful attack.

NOTE: The Common Safety Method for Monitoring [6] requires rail operators to monitor the effectiveness of their safety management system and risk control measures during operation and maintenance. Since security threats have an impact on safety risks, this includes monitoring the effectiveness of safety controls to protect against cyber attacks.

3.2.1 Railway operators and service providers should implement measures to protect their systems against cyber attack.

3.2.2 Railway operators and service providers should monitor their systems to detect potential cyber attacks; unusual behaviour that might indicate that the system has been compromised should be investigated (see 4.2).

3.2.3 Railway operators and service providers should respond to a confirmed cyber attack on their systems in a timely fashion and aim to minimise its impact (see 4.4).

NOTE 1: It is not sufficient to protect the system against cyber attacks. It is also important to be able to detect attacks that have penetrated the system’s defences and respond in an appropriate manner.

NOTE 2: Timeliness can be judged in terms of exposure to risk. The urgency of response depends on threat intelligence, and the likelihood and consequence of the safety and security of the overall railway system being compromised if the cyber attack is not addressed.

3.3.1 Railway operators and service providers that are responsible for systems and services that affect the safety of the overall railway system should ensure that those systems and services are maintained safely and securely, particularly if temporary special arrangements are put in place for maintenance.

NOTE: It is important to ensure that any special arrangements put in place while maintenance is carried out do not offer opportunities to attackers, even if they are temporary in nature.

3.3.2 Security requirements should be incorporated into maintenance contracts.

NOTE: Security requirements may include provision of a service-level agreement.

3.3.3 Maintenance contractors should only be granted access to the system for as long as is contractually necessary.

NOTE: Before and after maintenance, consider deleting or changing any authentication keys that are needed to access the system.

3.3.4 Any security-sensitive material contained in equipment that needs to be taken out of service for repair should be securely removed and destroyed before the equipment enters the repair cycle.

3.3.5 Any security-sensitive material contained in equipment that is sold, repurposed, or decommissioned should be securely removed and destroyed before the equipment is passed on.

3.4.1 Railway operators and service providers that are responsible for systems and services that affect the safety of the overall railway system should have arrangements in place to maintain essential functions during and after a cyber attack.

3.4.2 Such backup systems should ensure the safety and security of the overall railway system in any degraded mode of operation.

NOTE: EN ISO 22301 [36] and EN ISO 22313 [37] provide guidance on business continuity management systems.

3.5.1 Railway operators and service providers should document and manage all access to systems and functions that support the safe operation of the railway.

NOTE 1: Access rights should be carefully controlled, especially rights that grant access to safety-critical operations. The rights granted to individuals should be periodically reviewed and removed when no longer required.

NOTE 2: Guidance on identity and access management is available from NCSC [38].

3.5.2 Organisations should verify the identity of potential employees and the authenticity of their identity documents as part of their recruitment process.

NOTE 1: It is important to verify a person’s identity before granting them access to your systems. The degree of identity verification required depends on the level of access they will have.

NOTE 2: Guidance on pre-employment screening is available from NPSA [39].

3.5.3 Access to systems or data that are important for the safe operation of the railway should require an appropriate level of authorisation and authentication.

NOTE 1: It may be useful to distinguish between read and write access. For example, train movement data that has been published on a website is readable but not writable, and can therefore be made accessible to a broader set of users.

NOTE 2: In some situations, it may be necessary to allow immediate access to a system without authentication for safety reasons (for example, to invoke an emergency shutdown function without any delay). This is acceptable providing other controls are in place to limit access to the system (for example, physical access controls).

3.5.4 The strength of authentication required should be proportionate to the degree to which the systems or services support the safety or security of the ecosystem.

NOTE 1: Examples of stronger forms of authentication are two-factor and biometric authentication.

NOTE 2: Consider physical access controls as well as technical controls. 

3.5.5 To ensure accountability, each user should have their own identity.

3.5.6 The number of users with privileged access to the system should be strictly limited and periodically reviewed – in particular, the need for privileged access should be reviewed whenever a user’s role or responsibilities change.

NOTE: Ideally, there should be NO need for privileged access to the system, but it is recognised that this is not always practical.

3.5.7 Unauthorised individuals should be prevented from accessing data or services at all points within the system.

3.6.1 Organisations that use products or services supplied by another organisation should make arrangements to receive updates from the supplier of the product or service that they depend on.

3.6.2 Organisations that supply products or services should take steps to inform users of their products or services about updates when they are made available, and should encourage their users to apply updates that improve the safety or security of the product or service.

NOTE: Consider allowing updates to be fetched from a centralised location and applied automatically (‘unattended updates’), subject to appropriate risk control measures (for example, only security updates should be applied automatically, updates should be evaluated and tested before they are released for automatic installation).

3.6.3 Organisations should determine how quickly to distribute updates to their products and services by considering the severity of any safety or security issues addressed by the update.

3.6.4 Access to product and service updates should be restricted to users and authorised maintenance organisations.

NOTE: Potential attackers can reverse-engineer updates to discover vulnerabilities in the original system.

3.6.5 Updates that are accessed remotely should be downloaded from a trusted source via a secure communication channel.

3.6.6 Updates should only be applied if their authenticity and integrity can be verified.

NOTE: Techniques such as digital signatures can be used to verify the origin and integrity of an update.

3.6.7 An initial assessment of the impact of each update on the safety and security of the overall railway system should be performed in a timely fashion.

NOTE: Until the impact of an update on the safety or security of the overall system is understood, the system is exposed to an unknown risk.

3.6.8 An update should only be applied if its impact on the safety and security of the railway system has been assessed and accepted as tolerable or the risk of not applying the update is considered to be intolerable.

NOTE 1: A risk assessment can be used to look at the balance between the risk of modifying the system and the risk of leaving the system unchanged. Factors to consider include whether the update addresses a safety or security vulnerability, the degree of exposure to the threat, and the potential impact of an accident/attack.

NOTE 2: Consider including a Safety-Related Application Condition (SRAC) in the Application Safety Case that establishes the assumptions and conditions under which system updates should be applied so as to mitigate risks and allow continued safe operation of the system (see clause 5.3.13 of EN 50129:2018 [3]).

3.6.9 Updates that improve the safety and security of the overall railway system should be applied in a timely fashion.

NOTE 1: Timeliness can be judged in terms of exposure to risk. The urgency of applying the update depends on the likelihood and consequence of the safety and security of the overall railway system being compromised if the update is not applied.

NOTE 2: If maintenance is delegated or subcontracted to another organisation, the timely installation of updates can be arranged using contractual clauses.

3.6.10 If it is necessary to avoid or delay applying an update, the decision should be documented, justified and approved by a designated person in the organisation, and the risk incurred by the decision should be assessed and mitigated if needed.

NOTE 1: Some systems (particularly operational technology) may need to be taken offline in order to be updated and this may take time to organise. In other cases, the organisation may require time to assess, test and approve the update.

NOTE 2: IEC TR 62443-2-3:2015 [40] offers guidance on patching in the context of industrial automation and control systems.

3.6.11 Updates should be tested on a single system before they are rolled out more widely.

3.6.12 Unattended updates should only be applied when the system is in a ‘safe’ state and not currently operational (e.g. locomotives are stationary and have been taken out of service).

3.6.13 If an update is unsuccessful for some reason, the system should be restored to its original state and the risk of allowing the system to continue to operate without the update should be assessed and mitigated if necessary.

NOTE: Innovation covers new, potentially disruptive, uses of technology that can affect the way products or services are used, and undermine the assumptions made during the initial risk assessment. This can open the system to new modes of attack, introduce new vulnerabilities, or change the impact of failure or compromise. An example of innovation in the rail context is the use of data analytics and cloud-based services to predict and avoid reactionary delay.

3.7.1 Organisations should monitor and assess the potential of new technology to reduce or increase security threats to safety-related risks.

NOTE 1: The adoption of new technologies or changes to the use of existing technologies in the rail ecosystem could have an impact on the security of the product or service.

NOTE 2: New technologies might also change the relevance of existing assets to safety and security. See clause 1.4.3. 

3.7.2 Organisations should have a documented strategy for adapting their products and services so that they remain safe and secure in the face of changing technology and use.

3.8.1 Organisations should have a programme in place for handling the discovery of vulnerabilities in their products or services.

3.8.2 The programme should include documented procedures for assessing the safety impact of any alleged or actual vulnerabilities or new attacks on products and services.

3.8.3 The programme should include a documented policy for handling communications from third parties reporting the discovery of vulnerabilities or new attacks on products and services.

3.8.4 The programme should encourage the ethical and/or responsible disclosure of vulnerabilities in products or services.

NOTE: EN ISO/IEC 29147 [41] gives guidelines for the disclosure of potential vulnerabilities in products and online services.

3.8.5 Reports of failures (e.g. from warranty returns/repairs) should be examined for indications of a deliberate or malicious causal factor.

3.8.6 Reports of anomalous system behaviour and security incidents should be analysed for indications of new vulnerabilities or attacks.

NOTE: Data used for anomaly detection might include data with privacy implications.

NOTE: See also Section 4 – Incident Management.

3.9.1 Organisations should take steps to monitor and understand the potential threats to their products, systems and services and maintain an up-to-date threat assessment.

3.9.2 Organisations should subscribe/participate in government-led or industry-adopted schemes for disseminating threat information. 

NOTE: An example is the Cyber Security Information Sharing Partnership (CiSP) hosted by NCSC [42].

NOTE: The Common Safety Method for Monitoring [6] requires rail operators to monitor the effectiveness of their safety management system and risk control measures during operation and maintenance activities, and make any improvements that are necessary.

3.10.1 Organisations should continue to manage the impact of security threats on safety risks.

3.10.2 Assurance cases should be reviewed regularly to ensure that they remain valid.

NOTE: This is particularly relevant in the light of changing threats, knowledge about vulnerabilities, and the evolution of systems and their connectivity.

4.1.1 The organisation should have a documented plan for managing security incidents that indicate a potential risk to the safety of their products and services.

4.1.2 The plan should aim to ensure the continuity of any services that are important to the safe operation of the railway.

4.1.3 The plan should include the handling of security issues as part of a coherent process.

4.1.4 The plan should include mitigation activities designed to contain or limit the impact of an attack or other security incident on the safety of the organisation’s products or services and on the safe operation of the railway system as a whole.

NOTE: Further guidance on security incident management is available from NCSC [44], CREST [45], and ISO 27035 [11]. Organisations may wish to implement an incident detection system compliant with ISO 27035.

4.1.5 The plan should identify an organisational function or role (a ‘point of contact’) with responsibility for coordinating incident response activities.

4.1.6 The plan should identify specific individuals who are responsible for and adequately competent in assessing if an event has a safety dimension.

4.1.7 The plan should identify specific individuals with sufficient authority to authorise any actions needed to preserve the safety and security of the organisation’s products or services.

4.1.8 The plan should define a clear policy for escalation in the event of a serious incident.

4.1.9 The plan should consider the possibility of a security incident so severe as to necessitate withdrawal or recall of the organisation’s products or services.

4.1.10 The plan should be exercised regularly.

NOTE: Some organisations may find it appropriate to perform exercises in conjunction with others.

4.1.11 The infrastructure used to prevent, detect, respond to, and manage incidents should be protected against attack.

NOTE: The incident management infrastructure may be targeted to hamper response efforts and therefore increase the impact of an attack.

4.1.12 All personnel should be made aware of the means for reporting a suspected safety or security-related incident.

4.2.1 Organisations responsible for delivering services that are important to the safe operation of the railway should monitor the security status of their networks and information systems for evidence of both known and previously unknown attacks.

NOTE: Attackers use a variety of techniques to avoid detection via standard security monitoring, so it is important to use proactive security event discovery to detect attacks that evade standard detection and prevention measures. Records of activity should be analysed to detect unusual patterns of activity that might indicate previously unknown attacks.

4.2.2 Organisations that depend on services provided by third parties should ensure that those services are monitored for security incidents, and that they are notified of any relevant incidents in a timely fashion, so that they can manage their risk.

NOTE: According to clause 4.8 of the DfT guidance on the implementation of the NIS regulations in the transport sector [43], the NIS requirements do not apply directly to the supply chains of operators of essential services. Instead, it is the operator’s responsibility ‘to put in place appropriate and proportionate measures, and ensure that their suppliers have in place appropriate measures, to manage risks of their services being disrupted via their supply chain’.

4.2.3 Organisations should subscribe to industry or government-led schemes that provide notifications of relevant security incidents.

4.3.1 Organisations should adopt a scheme for classifying security incidents.

NOTE: An example of an incident categorisation system can be found in the NIST Computer Security Incident Handling Guide [46].

4.3.2 Organisations should assess the impact of security incidents on the safety of their products or services.

4.3.3 Detected events should be assessed as soon as possible, and within 24 hours, to determine if the event should be classified as a safety incident.

NOTE: The fact that a system is under attack might not be clear in the initial stages of the incident, and it might be necessary to reassess as more information becomes available.

4.4.1 Organisations should prepare a set of pre-planned response scenarios that are graded depending on the impact of an incident.

NOTE 1: The response scenarios may be generic, and be tailored to the actual incident as part of the response.

NOTE 2: Pre-planned responses help to ensure an adequate speed of response to security incidents.

4.4.2 The response should include communicating with relevant entities, including:

1. government agencies;
2. suppliers;
3. customers;
4. other industry actors; and
5. end-users.

NOTE 1: Attacks may exploit vulnerabilities that are present in products or services provided by other organisations, and it is essential that such organisations are notified quickly to ensure that they can also respond as needed. It is also important to notify operators of services that may be affected by a degraded state of the organisation’s systems.

NOTE 2: Communication with end-users is necessary to prevent misinformation causing changes in behaviour, which might lead to adverse effects on safety.

4.5.1 Evidence that may provide information about the sequence of events leading to the incident should be preserved and analysed.

NOTE 1: Evidence such as logs are frequently targeted by attackers to obscure the nature and origin of their attack. Measures to prevent the modification or deletion of log entries may need to be deployed to prevent this.

NOTE 2: EN ISO/IEC 27037 [47] contains guidance on the identification and capture of digital evidence, while EN ISO/IEC 27042 [48] contains guidance on its analysis.

4.5.2 When an incident occurs, steps should be taken to understand its root causes and ensure that appropriate remediating action is taken, including updating the risk assessment and any relevant risk management measures.

4.5.3 The performance of the incident management plan should be reviewed post-incident and the plan should be updated if necessary.

4.5.4 Incidents that potentially have a criminal nature should be reported to the appropriate law enforcement agencies.

4.5.5 Lessons learned from the review of the incident that might be of value to others in the rail sector should be shared via an appropriate mechanism (see clause 8.3 and 8.4).

5.1.1 The measures described in this section should supplement, not replace, any measures that are specified in application-specific standards such as EN 50128 [51] and EN 50657 [52].

5.1.2 Measures whose application is judged to be inappropriate or disproportionate to the security benefit need not be applied, but the rationale for this judgement should be explicitly recorded.

NOTE 1: A balance has to be struck between cost, complexity and risk. Typically, organisations consider all risks to their business, including commercial, financial and reputational risks, as well as safety and security risks.

NOTE 2: A complex system might carry a higher risk of failure and might be harder to justify, which typically motivates making systems as simple as possible, while maintaining the required functionality, performance, reliability and security.

5.2.1 The design should be based on a recognised set of secure design principles.

NOTE: Examples of secure design principles can be found in the SAFECode ‘Fundamental practices for secure software development’ [53] and the OWASP ‘Guide to building secure web applications and web services’ [54], which both reference a set of secure design principles originally proposed by Saltzer and Schroeder [55]:

1. economy of mechanism: keep the design as simple as possible
2. fail-safe defaults: base access decisions on permission rather than exclusion
3. complete mediation: every access to every object must be checked for authority
4. open design: the design should not be secret
5. separation of privilege: two keys are better than one
6. least privilege: every programme and every user of the system should operate using the least set of privileges necessary
7. least common mechanism: minimise the amount of mechanism common to more than one user and depended on by all
8. psychological acceptability: design for ease of use

5.3.1 The underlying hardware and software system platform should be locked down and configured with respect to a secure baseline.

5.3.2 In particular, the following measures should be applied:

1. Any unnecessary functionality or applications should be removed or disabled.
2. Any unnecessary network services should be removed or disabled.
3. Unnecessary peripheral devices and removable media should be removed or disabled.
4. Applications should be configured to run with least privilege.
5. Only authorised software should be allowed to run.

NOTE: Maintaining a list of authorised software (‘whitelisting’) is preferable to trying to identify all harmful software (‘blacklisting’) using anti-virus and malware detection technology.

5.3.3 It should not be possible to alter the system configuration or install or disable any software or services running on the system from a ‘normal’ user account.

5.3.4 Any changes that are made to the system configuration from a ‘privileged’ user account should be monitored and recorded.

5.3.5 Users should not be allowed to access the Internet or email unless such access is required to perform their role and the associated risk is managed.

NOTE: This is to protect against possible compromise via remotely delivered malware.

5.3.6 The impact of any deviations from the baseline system configuration on the overall safety and security of the system should be considered and documented as part of the risk assessment. NOTE: Further guidance on secure configuration and recommended configurations for particular platforms is available from NCSC [56].

5.4.1 The system should include mechanisms to detect component failures or unusual behaviour that might indicate that a component has been compromised as the result of a security failure.

5.4.2 The system should be designed to take a proportionate response to maintain safety if a component failure or suspected compromise is detected.

NOTE: Examples of responses may be an indication for maintenance, fall-back operation or transition to a minimal risk state. For some failures, the system might be able to continue to operate safely.

5.4.3 Consideration should be given to whether the system can continue to deliver a service safely in the event of a component failure.

NOTE: This might include the use of contingency mechanisms such as manual processes to ensure services can continue, providing this can be achieved without compromising safety.

5.4.4 Component failures or suspected compromises of components should be reported to the operator via an appropriate mechanism and recorded for subsequent analysis.

5.4.5 Components that store security-sensitive information in non-volatile memory should ensure that the information is protected against disclosure in the event of a failure.

NOTE: Further guidance on this topic can be found from ICS-CERT [57].

5.5.1 The design of the system should be such that safety does not rely on the correct operation of any single component or subsystem.

NOTE 1: For example, a measurement of train speed may be derived from diverse sources of information.

NOTE 2: For simple systems that are intended for integration into a larger system that contains measures to detect or mitigate failures, application of this clause might be disproportionate.

5.5.2 Computer networks should be appropriately segmented with access controls at the segment boundaries so that the spread of potential attacks is limited.

NOTE 1: The degree of segmentation will depend on the types of connectivity in the network. Segmenting simple networks might be infeasible or disproportionate (see 5.1.1).

NOTE 2: IEC 62443 [31] provides guidance on security zones and conduits for network segmentation.

5.5.3 The compromise of a single non-safety related component should not enable the compromise of a safety-related component.

NOTE: The compromise of a security system that is specifically protecting a safety system could potentially lead to a violation of this clause.

5.5.4 The design of the system should prevent a non-safety-related component inducing a safety-related component to take an unsafe action.

NOTE 1: Possible ways of achieving this are isolating safety-related components/systems from non-safety-related components/systems, or by treating non-safety-related components as untrustworthy and putting appropriate security barriers in place.

NOTE 2: Consider implementing safety-critical functionality on dedicated hardware that is not used for any non-safety function.

NOTE: Cryptography has many applications in maintaining security, including preventing access to information/data (encryption), verifying data integrity, and authentication. More detailed guidance on cryptographic controls can be found in EN ISO/IEC 27002, Section 10 [28].

5.6.1 Only cryptographic algorithms that have been subject to analysis and approval by a competent independent expert group should be used.

5.6.2 Only cryptographic implementations that have been subject to analysis and approval by a competent independent expert group should be used.

NOTE: NCSC provides a list of certified cryptographic products [58].

5.6.3 There should be a secure mechanism for generating, distributing and installing cryptographic keys.

NOTE: EN 50159 [59] requires cryptographic keys to be used for safety-related communication over open networks to guard against masquerade attacks. This means that the safety of the system depends on the security of the cryptographic key.

5.6.4 Cryptographic keys stored by the system should be protected against unauthorised use, disclosure, modification or deletion.

NOTE 1: An attacker could attempt to gain access to the system by adding a false key or deny access to the system by deleting keys.

NOTE 2: Depending on the design of the system, an attacker might be able to make use of a key without needing to know the value of the key.

5.6.5 Cryptographic material stored in non-volatile storage should be protected against disclosure.

NOTE: This is particularly pertinent if the device fails and needs to be taken out of service for repairs. See also clause 3.3.5.

5.6.6 It should not be possible to use any key that might be obtained from a train or a system to access multiple trains or systems.

NOTE: This ensures that any key that might be extracted from a train or system cannot be used to compromise other trains or systems.

5.6.7 Keys with known values that are used for testing purposes should be deleted before the system is put into operation.

NOTE: Test suites used to ensure interoperability between systems may mandate the use of test keys with known values. This requirement prevents an attacker from using such test keys to attack an operational system.

NOTE: The software image is the binary representation of the compiled source code for the system. The software image can also contain static configuration data that is expected to remain constant during run time. The software image must be loaded into memory before it can be executed. An attacker that is able to modify the software image either prior to execution or during execution would be able to override functional safety and make the system behave in arbitrary ways.

5.7.1 Software images should be protected against unauthorised modification. NOTE: A simple checksum is not sufficient to guarantee the integrity of the software image because an attacker can modify the software and the checksum. The use of a cryptographic checksum or digital signature is recommended. Alternatively, the software image could be encrypted.

5.7.2 Software images should be protected from unauthorised analysis or reverse engineering.

NOTE: Reverse engineering and unauthorised analysis can be made more difficult using techniques such as encryption, obfuscation or stripping the symbol table from the software image. However, techniques that alter the structure of the executable code should be used with caution in safety systems.

5.7.3 The system should check the integrity and authenticity of all software images at load time.

5.7.4 The system should ensure the integrity of the software image in memory during run time.

NOTE: Depending on the system hardware, it may be possible to store the software image in read-only memory, which would prevent it from being modified at run time. Alternatively, the integrity of the image stored in memory could be checked periodically.

5.7.5 The system should include integrity checks on control flow to ensure that the software is not subverted at run time.

NOTE: Depending on the system hardware, it may be possible to store the software image in execute-only memory, which guards against some forms of buffer overflow attack [60] that attempt to overwrite memory with executable code, but not more sophisticated attacks such as Return Oriented Programming [61]. See [62] for more information on techniques to achieve data flow and control flow integrity.

5.8.1 The system should provide a secure interface for diagnosing faults.

NOTE: If the design makes provision for secure fault diagnosis, the motivation for bypassing security controls to diagnose faults is reduced. However, it is permissible for the manufacturer to restrict access to more powerful diagnostic functions, such as the ability to change parameters that could compromise the safety of the system.

5.8.2 Interfaces that are intended for diagnostic purposes should be protected against misuse.

NOTE: Physically hiding access ports is not considered adequate protection. An example of adequate protection might be requiring authentication before allowing access through the interface.

5.8.3 Diagnostic or debugging actions that interact with safety-relevant systems should be restricted in scope so as not to allow them to be abused to create a hazardous situation.

NOTE: For example, the diagnostic action may be restricted to only act when the train is moving at low speed.

5.8.4 Diagnostic equipment should be stored in a physically secure location.

5.8.5 Diagnostic equipment should require authentication before use.

NOTE: To ensure accountability, it might be necessary to require that each user of the equipment has a personal set of authentication credentials that are not shared between users.

5.8.6 All diagnostic and corrective actions performed during maintenance should be recorded in a secure fashion in a log.

5.8.7 The log should include details of the action performed, the time at which it was performed, and the identity of the user who performed the action.

5.8.8 Commands that affect the system’s state or configuration, or cause an action, should be managed using secure protocols, including authentication.

5.9.1 The mechanism for applying patches and updates should be safe and secure.

NOTE: For example, it should only be possible to update the system when it is in a safe state, and the update should be checked for authenticity before it is applied.

5.9.2 The design should facilitate the system being updated without compromising its overall safety and security.

NOTE: For example, the system could be designed in a modular fashion with an architecture that enforced strong separation between components such as a separation kernel [63].

5.9.3 It should be possible to revert an update or restore the system to a known good state if the update process fails or needs to be reversed for any reason.

NOTE: For example, an update might be installed successfully and then discovered to have an adverse effect on safety or performance. See also clause 3.5.

5.9.4 It should be possible for users to identify the revision of software installed on a system or device and determine whether updates are available, without the need for access to restricted information or specialised equipment.

NOTE: Equipment such as cables or interfacing software supplied with a product or device is not considered to be specialised equipment.

NOTE: Appendix E provides further guidance on network security.

5.10.1 Networks used by passengers (e.g. passenger wi-fi) should be isolated from networks used for train control and railway signalling.

NOTE: The network architecture should prevent direct passenger access to a train’s control and command systems. If physical network isolation is considered to be too difficult or expensive to implement, logical network isolation should be implemented using firewalls and routers.

5.10.2 Safety-critical data should only be transmitted over a secure channel to ensure that non-safety-related components cannot interfere with the data.

NOTE: Ideally, safety-critical data should be transmitted over a dedicated link, but if this is not possible, it is acceptable to use virtual channels to separate traffic over a shared link, providing that traffic isolation and adequate bandwidth/quality of service can be guaranteed for the secure channel.

5.10.3 All data received by the system should be checked for integrity and validity.

NOTE: Integrity means that the data has not been corrupted. Validity means that the content of the data satisfies application-specific constraints. Data that passes an integrity check is not necessarily valid. It is also important to check that the data is meaningful and consistent, for example, to check that the values of data fields are within range and are internally consistent.

5.10.4 All data received from an external source should be checked for authenticity.

NOTE: Authenticity means that the origin of the data can be confirmed with some degree of certainty and the data is known not to be a forgery. A simple integrity check is not enough because an attacker with knowledge of the algorithm could forge the data and the integrity check. To ensure authenticity, the use of cryptographic techniques is recommended – further guidance can be found in Appendix E and EN 50159.

5.10.5 Data received from an internal source should also be checked for authenticity unless it can be shown that the internal data link cannot be accessed by an external source or an untrusted internal source.

NOTE: Timing constraints and bandwidth limitations may mean that it is not technically feasible to check the authenticity of data sent over a real-time bus, but this is only acceptable if it can be shown that the internal network cannot be accessed by an attacker.

5.10.6 Data that reveals sensitive information about the system that might facilitate an attack should be encrypted to ensure confidentiality.

5.10.7 Secure communication protocols should be designed to enforce a minimum level of security.

NOTE 1: The strength of a security protocol depends on factors such as key length and choice of cryptographic primitive (encryption algorithm, hash function, etc.). The protocol implementation version may also be significant if certain implementations are known to contain vulnerabilities.

A minimum level of security can be enforced by updating the software at both ends of the communication in lockstep or by using protocol negotiation to agree on these parameters whenever a new communication session is established.

NOTE 2: If the protocol does not enforce a minimum level of security, an attacker could force the protocol to operate with a reduced level of security that was susceptible to attack.

5.10.8 The design and implementation of secure communication protocols should be periodically reviewed and updated if necessary to ensure that the protocol remains secure.

NOTE 1: Flaws in the design or implementation of a protocol can make the protocol insecure and potentially unsafe to use.

NOTE 2: Advice and guidelines on the use of cryptography are available from organisations such as NIST [64] and equivalent national and international organisations.

5.11.1 Configuration data that affects the safe operation of the system should be protected against unauthorised modifications.

NOTE: This includes data used to configure the interlocking or signalling system, for example, data about maximum safe speeds and track geometry.

5.11.2 There should be a mechanism for resetting the system to its default factory state and deleting any security-sensitive information that is required for its operation (e.g., cryptographic keys).

NOTE: This mechanism is intended to be used before transfer of ownership or decommissioning to prevent the inadvertent disclosure of security-sensitive information.

5.12.1 The system should be designed to interact safely and securely with external services and devices.

NOTE: ‘External devices’ are devices that are not permanently integrated with the system.

5.12.2 The integrity, validity, and authenticity of data received from external services and devices should be verified.

5.12.3 The degree to which external data is trusted should depend on the safety-impact of the data and the trustworthiness of the source.

NOTE: For example, data without any impact on safety might be accepted from a potentially untrustworthy source, data with moderate safety relevance might require a trusted source, while safety-critical data might only be accepted from two independent sources.

5.12.4 The system should not make safety-related decisions on the basis of information received from an external source, unless the source is known to be trustworthy, the information can be verified, or the risk from ignoring the information is unacceptable.

NOTE: An example of verification would be corroboration by an independent source.

5.12.5 The system should not rely on the availability of external services to operate safely.

NOTE: For example, even highly-reliable services such as GNSS can be jammed by attackers.

5.12.6 The system should be able to withstand receiving corrupt, invalid or malicious communications on external interfaces, while maintaining safe operation.

NOTE: This includes flooding, denial of service and jamming.

5.13.1 Cables into buildings and cabinets containing systems that are important for safe railway operations should be protected against physical attacks that might facilitate cyber attacks.

NOTE: Guidance on perimeter security is available from NPSA [65].

5.13.2 Appropriate protective security measures should be incorporated into the design of new stations and redevelopments of existing stations.

NOTE: DfT (in conjunction with NPSA and the British Transport Police) published guidance on security in the design of stations (SIDOS) [66].

5.13.3 The vulnerability of CCTV, emergency alarm, and building management systems to cyber attack should be considered.

5.14.1 The system should include mechanisms to record system activities securely to enable forensic examination and aid identification of the cause of a cyber security incident.

NOTE 1: Safety systems often include an event data recorder or ‘black box’ device that can be used to investigate the cause of a safety incident and this device can also be used to investigate the cause of security incidents.

NOTE 2: EN ISO/IEC 27037 [47] contains guidance on the identification and capture of digital evidence.

5.14.2 All records of system activity should be preserved for a sufficient time period to allow for the detection and investigation of security incidents.

NOTE 1: The appropriate time period will be determined by factors such as the criticality and sensitivity of the data, and the amount of time that might be required for the incident to be detected and an investigation instigated. Sophisticated attacks such as advanced persistent threats can take place over a period of 6-12 months, so records should potentially be retained for at least a year.

NOTE 2: Attention is drawn to the possibility that such records might contain personally identifiable data, in which case data protection legislation would be applicable and might impose requirements for how the data is stored and protected.

5.14.3 Where practicable, a component or subsystem that is to be integrated into a larger system should be capable of outputting messages to an external logging device as well as any internal recording facility.

NOTE: This might not be practicable for some low-level components.

5.14.4 The forensic recording facility should be designed so that it is not possible for an attacker to conceal their actions by suppressing logging messages or modifying or deleting logging records.

5.14.5 The forensic recording facility should be designed so that actions are logged as they are performed, or immediately thereafter.

NOTE: If logging is designated as low-priority, there is a risk that some actions may not be logged in time to ensure their preservation, e.g. if power is lost to the unit.

5.14.6 All significant actions and events should be recorded, particularly actions and events that have an impact on the safety or security of the system.

5.14.7 To ensure traceability and guard against component or subsystem failures, the inputs, actions, and outputs of each component or subsystem should be logged independently.

NOTE: If a component or subsystem is responsible for logging its own inputs, actions, and outputs, in the event of a failure or compromise of the component, the log messages are no longer reliable or trustworthy.

5.14.8 Changes made to safety-relevant and security-relevant parameters should be recorded together with the time and the origin of the change.

5.14.9 It should be possible to reconstruct the sequence of events or actions from the forensic record of log messages.

NOTE: For example, all logging messages could be timestamped using a global clock or shared time reference.

5.14.10 It should be possible to reconstruct the sequence of events or actions from the forensic record of log messages.

5.15.1 The possibility for compromised components or systems to affect user behaviour in an unsafe way should be mitigated by the design of the user interface.

NOTE: Examples of ways in which user behaviour can be changed include distraction, presentation of misleading information, or incentives to change or disable safety or security functionality.

5.15.2 The system should be designed so as to permit and promote secure user behaviour.

NOTE: For example, the system might promote the use of strong authentication methods such as two- factor authentication and discourage the use of shared passwords to ensure accountability.

5.15.3 Diagnostics and error messages should not include information that might help a potential attacker.

NOTE: For example, the error message for a failed login attempt should not tell the user whether the username or password were correct. Similarly, diagnostic messages displayed to the user should not include internal details about the software such as file names.

5.16.1 All software should be developed in accordance with secure coding practices.

NOTE: Examples of guidance on secure coding practices are MISRA-C [67], SEI CERT C Coding Standard [68] and SAFECode [53]. Further guidance on safe and secure coding practices can be found in Appendix F.

5.16.2 Each tool used in the development and assurance process should be assessed for its role in mitigating security-related safety risks and its potential role as an attack vector.

NOTE: Tools include specialised tools for development and verification (compilers, debuggers, static analysers, formal verification tools, testing tools), general purpose development tools (build tools, configuration management tools, issue tracking and code review tools), general purpose applications (email, web browser, office applications, document tracking systems), and operating systems (client and server).

5.16.3 The design and development environment and infrastructure should be secured against threats that might manipulate the design and development process or compromise the integrity of the product or service.

NOTE: This includes physical, personnel and information security.

5.17.1 Software images should not be publicly available.

NOTE: Publishing the software image on a web server whose name is not advertised does not provide sufficient protection. There have been instances of security researchers using Google to locate software images on public web servers, downloading the software, and analysing it for security flaws [69].

5.17.2 Software images should only be accessible to authorised users.

NOTE: For example, customers should be required to log on to a secure web site in order to download a copy of the software.

5.17.3 All access to software images should be logged.

5.17.4 Software images should only be generated by authorised staff.

NOTE 1: This is to prevent developers from generating ‘unofficial’ versions of the software image.

NOTE 2: This does not prevent developers from generating test versions of the software image during development, but the system should distinguish between test versions and official versions.

5.17.5 Software images should only be published by authorised staff.

NOTE: This is to prevent unauthorised publication of software images and can be achieved using procedural controls. Consider using ‘separation of duty’ to separate the privileges required to generate and publish an authentic software image.

6.1.1 The organisation should assess and manage risks to:

1. the wider rail system
2. society more generally

These risks might be derived from failure or compromise of its products or services.

NOTE 1: The approach will depend on the nature of the product or service and the regulatory regime that applies.

NOTE 2: Examples of risk to society generally might include the widespread failure of the organisation’s products and services, leading to a reduction in rail transport capacity with a consequential impact on many other activities.

6.2.1 The organisation’s products and services should make use of industry-adopted standards for communication and security, where they can be shown to support adequate levels of safety and security.

6.3.1 Organisations should enable customers to assess the security of their products and services by making sufficient design and assurance information available.

NOTE: To protect intellectual property, confidential information such as detailed design documentation can be made available under an NDA.

6.3.2 The organisation should be able to provide third parties with assurance or certification that the organisation’s processes relevant to the production of a safe product or service are secure.

6.3.3 The organisation should collaborate with relevant organisations to obtain knowledge and understanding of current and relevant threats.

6.3.4 If the organisation becomes aware of vulnerabilities that affect or might affect the products or services of another organisation, they should responsibly disclose such vulnerabilities to those organisations.

NOTE: Vulnerabilities might be identified through post-incident analysis (see Section 4.5), or reported by third parties.

6.3.5 The organisation should support other organisations in the ecosystem to understand and manage security risks arising from the use or abuse of its services or products.

NOTE: Relevant organisations might include governmental organisations (including security agencies), industry umbrella groups and other industry actors.

6.4.1 The organisation should collaborate with relevant organisations to share, develop and foster the adoption of good engineering practices to mitigate current and relevant threats.

NOTE: Relevant organisations might include governmental organisations (including security and law enforcement agencies), industry umbrella groups and other industry actors.

6.4.2 The organisation should define an approach for adopting open design practices and deciding when and how to share designs and source code.

6.5.1 Organisations should consider the implications of working with organisations from other countries throughout their supply chain. Some countries may harbour malicious intent towards the UK.

NOTE: Further guidance on supply chain risk is available from NPSA [34] and NCSC [26].