13-Reference 04- UTA Cybersecurity Requirements for OT Procurements.pdf

Page | 1

Utah Transit Authority Operational Technology

Procurement Requirements

Page | 2

Contents

1 OVERVIEW

2 CYBERSECURITY SuC REQUIREMENTS

3 SuC RISK ASSESSMENT

3.1 SuC DOCUMENTATION

3.2 RISK ASSESSMENT DOCUMENTATION

3.2.1 Initial Risk Assessment

3.2.2 Zones and Conduits Design

3.3 DETAILED CYBER RISK ASSESSMENTS

4 SECURE SYSTEM DEVELOPMENT

5 VULNERABILITY DISCOVERY, REPORTING, AND ASSESSMENT

6 SECURITY PATCHING AND MITIGATION GOVERNANCE

7 OPERATIONAL GOVERNANCE

8 SUC INVENTORY

9 SECURE SYSTEM CONFIGURATION

9.1 HARDWARE CONFIGURATION REQUIREMENTS

9.2 OPERATING SYSTEM SECURITY

9.3 VIRTUALIZATION SECURITY

9.4 SECURING ACTIVE DIRECTORY

9.4.1 Active Directory Security

9.4.2 Securing Active Directory Domain Controllers

10 TIME SYNCHRONIZATION

11 DATA SECURITY

12 IDENTITY AND ACCESS MANAGEMENT SECURITY

12.1 ACCESS CONTROL

12.2 PRIVILEGED IDENTITY AND ACCESS

13 SESSION MANAGEMENT

14 NETWORK SECURITY

14.1 WIRELESS NETWORKS SECURITY

14.2 SEGMENTATION/MICRO SEGMENTATION

14.3 PHYSICAL SECURITY

15 ROLLING STOCK SECURITY REQUIREMENTS

16 FAILURE MODE

Page | 3

17 SYSTEM LIFECYCLE MANAGEMENT

18 SUPPLY CHAIN SECURITY

18.1 SOFTWARE BILL OF MATERIAL (SBOM)

18.2 HARDWARE BILL OF MATERIAL (HBOM)

19 NONPRODUCTION ENVIRONMENT

20 INCIDENT RESPONSE READINESS

20.1 AUDITING

20.2 LOG COLLECTION

20.3 LOG ANALYSIS AND THREAT DETECTION

20.4 TABLETOP EXERCISES

21 USER AWARENESS AND TRAINING

22 INFORMATION SYSTEM RESILIENCE

22.1 HIGH AVAILABILITY

22.2 BACKUP AND RESTORATION

23 SYSTEM ACCEPTANCE

24 SYSTEM RETIREMENT

24.1 MIGRATION OF SYSTEM FUNCTIONALITY

24.2 HARDWARE DISPOSAL

24.3 DATA HANDOVER AND DESTRUCTION

25 THE AUTHORITY RIGHT TO AUDIT

26 EXCEPTION PROCESS

Page | 4

1 OVERVIEW

This document specifies Cybersecurity Operational Technologies (OT) Procurement Requirements as a guideline for the Utah Transit Authority.

It aims at the implementation of a consistent management approach to leverage security protocols across railway infrastructures and provides essential information necessary to navigate the ever-evolving sophisticated threat landscape across the Railway sector.

A consensus on threat landscape between all Stakeholders is crucial to building a centralized cybersecurity strategy that detects, identifies, prevents, circumvents, recovers, and manages the various levels of cybersecurity threats that can jeopardize the railway system.

To counter these threats, all Stakeholders are encouraged to participate in a process—as defined in this document—to agree on a generally accepted threat landscape that is based on recognized and accepted threat libraries and reports.

This document is designed to serve as a baseline for all stakeholders, specifically—railway operators, system integrators, and product suppliers.

It is compliant with industry and government standards that govern cybersecurity processes and controls including ANSI/ISA 62443 and NIST 800-53 current revisions.

2 CYBERSECURITY SuC REQUIREMENTS

This document stipulates Security Contract Terms and Conditions for System(s) Under Consideration (SuC). The cybersecurity requirements stated herein are to be implemented by the Vendor responsible for providing SuCs that will be operated by the Authority or operated by the Vendor.

System under Consideration (SuC) is defined as a collection of Integrated Administration and Control System (IACS) assets, subsystems and components including network infrastructures, that provide complete automated solutions. A SuC consists of one or more zones and related conduits. All assets within a SuC belong to a zone or a conduit.

3 SuC RISK ASSESSMENT

3.1 SuC DOCUMENTATION

The Vendor shall provide documentation defining SuC components as follows:

a) Definition document that defines the scope and boundaries of the SuC.

b) The SuC objective and mission profile comprising SuC functions, boundaries, and interfaces.

c) Description and functionality of each essential function, internal and external dependencies, and subsystems, contributing to each essential function, physical and network interfaces, and the actors interacting or interfacing with the SuC.

d) SuC integration to other railway systems: whether the SuC incorporates other systems, is part of a larger system, or both. The Authority shall provide the Vendor with the necessary information for the Vendor to develop diagrams representing SuC relationships to affiliated/integrated systems.

e) The boundaries and interfaces of the systems, the zones and conduit environments the SuC will operate in.

f) Additional documentation summarizing the SuC’s security features and security-focused instructions on product maintenance, support, and reconfiguration of default settings.

Page | 5

g) Documentation shall include use case operational scenarios that define how the SuC will be used, and constraints by the environment in which the SuC operates.

h) The planned lifetime and therefore, necessary system updates in Hardware and Software.

i) i) Roles and responsibilities for maintaining cybersecurity activities for the SuC.

3.2 RISK ASSESSMENT DOCUMENTATION

The Vendor shall perform the necessary risk assessment activities to deploy the SuC into railroad operations as detailed below.

3.2.1 Initial Risk Assessment

The Vendor shall perform an Initial Risk Assessment (IRA) documenting the protection requirement analysis against cybersecurity threats. The IRA shall consider potential cyberattacks impact on safety functions, forecast worst case potential impact scenarios to railway operations in terms of human health and safety, operational availability, and financial impact, and identify the following:

a) Cybersecurity impact assessment based on the Authority’s risk matrix

b) Likelihood assessment for cybersecurity risks

c) Risk evaluation

The Authority shall approve the Initial Risk Assessment documents.

3.2.2 Zones and Conduits Design

As part of the risk assessment process, Vendor shall complete the initial design of the zones and conduit documents for the SuC. The design shall ensure that the Operational Technologies systems can continue to function safely in the event that an Information Technology system has been compromised. and shall submit for approval the Zones and Conduit design to Authority detailing the following categories:

a) Type of interfaces or connections to other components of the SuC.

b) Physical or logical location(s).

c) Access requirements.

d) Operational function(s).

e) Organizational responsibilities for each asset.

f) Separation of safety systems in dedicated zones.

g) Separation between Operational Technologies Zones and IT Zones.

h) Categorize zones and conduit assets in hierarchical groups wherein all components in a zone with the highest security requirement is enforced as the minimum-security requirement.

3.3 DETAILED CYBER RISK ASSESSMENTS

The Vendor shall perform a Detailed Cyber Risk Assessment (DCRA) in collaboration with the Authority’s cybersecurity, safety, and operational staff according to the Authority’s risk matrix. The DCRA shall take into consideration the zones and conduit design, essential and nonessential functions, and operational requirements of the SuC. Vendor shall deliver a documented DCRA as listed below:

a) Evidence-based assurance that cybersecurity functions shall not negatively impact safety functions or other essential functions.

b) Define threat landscapes, use cases, and potential cybersecurity threats based on the Mitre ATT&CK framework for individual and grouped zones.

c) The applicable security controls and countermeasures to address identified threats.

Page | 6

d) List of all unmitigated cybersecurity risks.

e) Define Security Level Targets for the SuC, subsystems, and components based on ISA-62443- 3-2-2020 Standard for each zone and conduit as determined by the Zone and Conduit Requirement (ZCR).

f) Proof that implementation of the suggested ISA-62443-3-3 Standard Security Level Target measures will result in the required risk reduction; risk shall be reduced to the target risk level as defined by the Authority.

g) Deliver risk evaluation reports after the application of the Security Level Targets and additional compensating controls/countermeasures.

h) Demonstrate the iterative process of risk identification and application of security controls and countermeasures. The design shall demonstrate that the application of security controls and countermeasures shall bring down the residual SuC cybersecurity risk to an acceptable level.

The Vendor may request a risk acceptance for specific risks. The Authority shall grant or deny the request.

The Authority shall review and approve the DCRA prior to proceeding with the SuC implementation. The vendor shall update the DCRA annually once the system is deployed.

4 SECURE SYSTEM DEVELOPMENT

Based on the Detailed Cyber Risk Assessment (DCRA) Reports, the Vendor shall collaborate with the Authority to define the appropriate Security Levels and Security Level Targets (SL-T) that the Vendor shall comply with during the system development process. Vendor shall obtain certification from a recognized certification third-party to demonstrate compliance with agreed-upon Security Level Targets based on ANSI/ISA-62443 4 1 2018 requirements, Security For Industrial Automation And Control Systems Part 4-1: Product Security Development Life-Cycle Requirements and ANSI/ISA 62443 3 3 (99.03.03)-2013 Security for industrial automation and control systems/Part 3-3: System security requirements and security levels.

SuC third-party components and subsystems shall comply with the same security requirements as the Vendor.

5 VULNERABILITY DISCOVERY, REPORTING, AND ASSESSMENT

The Vendor shall implement a vulnerability detection and remediation program that covers the SuC, its subsystems and components. The program shall be consistent with industry standards such as ISO- 27417 and NIST 800-53 current revisions. The Vendor shall develop and implement policies and procedures to address the disclosure and remediation by Vendor for vulnerabilities and material defects related to the products and services provided to the Authority under this document which shall include the following:

a) Prior to the delivery of the procured product or service, Vendor shall provide or direct Authority to available sources that contain a summary of documentation of publicly disclosed vulnerabilities and material defects in the procured product or services, the potential impact of such vulnerabilities and material defects, the status of Vendor’s/ Contractor’s efforts to mitigate those publicly disclosed vulnerabilities and material defects, and Vendor’s/Contractor’s recommended corrective actions, compensating security controls, mitigations, and/or procedural workarounds.

b) The Vendor shall provide or direct Authority to available sources that contain a summary of documentation describing vulnerabilities and material defects in the procured product or services within thirty (30) calendar days after such vulnerabilities and material defects

c) become known to Vendor. The summary documentation shall include a description of each vulnerability and material defect and its potential impact, root cause, recommended corrective actions, compensating security controls, mitigations, and/or procedural workarounds (e.g., monitoring).

Page | 7

d) The Vendor shall disclose the existence of all known methods for bypassing system authentication in the procured product or services, often referred to as backdoors, and provide a written attestation that all such backdoors created by Vendor/Contractor have been permanently remediated.

e) The Vendor shall report to the Authority, all newly discovered vulnerabilities, and provide severity ratings and sufficient details, describing the vulnerabilities to assess potential operational and safety impact on the SuC. The Vendor shall report all vulnerabilities within 14 days of discovery/at or prior to public disclosure, or when reported on the National Vulnerability Database (NVD) site.

Vendor shall provide security patches and implement remediation procedures at the earliest timeframe to the Authority in compliance with requirements stated in Section 6: Security Patching and Mitigation Governance of this document.

f) The Vendor shall disclose vulnerabilities that may impact the safety of critical systems to the Authority within 1 day of discovery. Vendor shall provide a patch or a counter measure within 14 days of discovery.

g) If the Vendor assesses that the discovered vulnerability may have safety impact, the Vendor shall make available, patches or countermeasures for the vulnerability to the Authority prior to public disclosure.

h) The Vendor shall perform vulnerability discovery and enumeration once every 14 days. When feasible, Vendor shall perform authenticated vulnerability discovery procedures.

i) The Authority or a third-party appointed on its behalf, may perform vulnerability scanning testing on the SuC. Testing shall be performed with the coordination of the Vendor and shall be carried out within 30 Days of notifying the Vendor. The Vendor acknowledges that during the testing phases, it may be necessary to circumvent security controls to obtain accurate test results.

Vendor agrees that it owns or controls all the necessary rights, licenses, or permissions to facilitate the testing procedures.

j) The Vendor shall perform risk assessments on all known or discovered vulnerabilities. Vendor shall score vulnerabilities that are not already scored in the National Vulnerability Database (NVD) using the same methodology as NVDs CVSS 3.0 rating system. The scoring shall classify the vulnerabilities with one of the following ratings: Low, Medium, High, and Critical. At the approval of the Authority, the scoring can be modified to reflect the exploitability of the vulnerability. Patching or mitigating the vulnerabilities shall follow requirements stated in Section 6: Security Patching and Mitigation Governance of this document.

6 SECURITY PATCHING AND MITIGATION GOVERNANCE

The Vendor shall establish a patch deployment and compensating control (mitigation or countermeasure) deployment program for the SuC, its subsystems and components. Tooling to facilitate the deployment of patches and mitigations shall be deployed to facilitate the process at the request of the Authority.

Authority may make available tooling to the Vendor in which case the Vendor shall leverage existing tools.

a) In cases where the SuC is distributed across more than three locations, Vendor shall provide documentation on the methods for deploying patches remotely without breaching zone separation logic over Authority provided secure connectivity to the assets.

b) The Vendor shall provide patch deployment plans which minimize the risk of operational disruption to an acceptable level.

c) All patches and mitigation methods shall be tested in nonproduction environment(s). Test results shall be documented. Test results shall be combined into a patch risk analysis and approved by the Authority prior to making any changes in operational systems.

d) The Vendor shall provide detailed documentation and adequate tooling to empower the Authority to patch the SuC(s) (including third-party hardware, software, and firmware). This documentation shall include required resources and technical capabilities to sustain the SUC and related processes.

Page | 8

e) When feasible, all patch deployment in production environments shall be automated to prevent operator errors.

f) The Vendor shall verify and provide documentation for integrated products and sub-products (including third-party hardware, software, firmware, and services) with appropriate updates and patches installed prior to delivery to the Authority, or within 30 days prior to the system going live.

g) Unless otherwise approved by the Authority in writing, the current or supported version of Vendor products and services supplied by Vendor shall not require the use of out-of-date, unsupported, or end-of-life versions of third-party components (e.g., Java, Flash, Web browser, etc.).

h) The Vendor shall make patches and mitigation methodologies available to third-parties authorized by the Authority to receive such items.

i) Vendor shall provide patches that can be rolled back if required.

j) The Vendor shall provide appropriate software and firmware updates to remediate newly discovered vulnerabilities or weaknesses based on the requirements stated in Section 15: System Lifecycle Management of this document.

1) Updates to remediate critical vulnerabilities shall be provided within the period agreed upon during the risk assessment process. If updates cannot be made available by the Vendor within the designated timeframe, the Vendor shall provide mitigations and/or workarounds within the period defined in Section 5: Vulnerability Reporting, Discovery, and Assessment of this document.

2) When the Vendor provides third-party hardware, software, and firmware to the Authority, the Vendor shall provide appropriate hardware, software, and firmware updates to remediate newly discovered vulnerabilities or weaknesses according to the Risk Rating Deadline Patching Schedule. If the third-party updates cannot be made available by the Vendor within the designated timeframe, the Vendor shall provide mitigations and/or workarounds within the scheduled deadlines.

3) The Vendor shall supply the Authority with procedures and processes to validate patching or mitigation results that confirm that the intended goal of remediating the target vulnerability(ies) has been achieved. The application of the patch or mitigation shall reduce the risk to an tolerable risk level.

4) The Vendor shall exercise due care in ensuring that patches do not introduce new vulnerabilities.

5) Patch development shall not change the Security Level Achieved by SuC.

6) Patch deployment shall adhere to the requirements stated in Section 7: Operational Governance of this document.

7) Authority shall dictate the manner and date; the patches or compensating controls will be deployed.

8) Patches and mitigation timeframe shall adhere to the schedule tabulated below.

Risk RaƟng Deadline Patching Schedule

Risk RaƟng Patching/MiƟgaƟon (CompensaƟng Controls) Availability Deadline

Low 180 Days

Medium 60 Days

High 45 Days

CriƟcal 30 Days

The patching or mitigation shall lower the overall risk of the SuC to a Tolerable Risk Level within the deadlines tabulated above.

Page | 9

7 OPERATIONAL GOVERNANCE

The Vendor shall comply with the Authority's Operational Governance procedures. Once the SuC is operational, the Vendor shall adhere to the Authority’s internal control processes including but not limited to: Change Management, Release Management, and Configuration Management. At the Authority’s request, the Vendor shall develop detailed processes for system operations governance. All SuC changes shall maintain the SuC’s Achieved Security Levels (SL-A)—the actual levels of security that are commissioned and in operation.

8 SUC INVENTORY

The Vendor shall establish a program to manage and report on the current systems inventory detailing all hardware and software components with versions including third-party subsystems and components, change registers, and unique identifiers for each component. The Vendor shall provide the following:

a) The Vendor shall integrate the configuration management processes into the Authority’s Configuration Management Database (CMDB). At the request of the Authority, Vendor shall provide a CMDB system in use with the SuC.

b) The Vendor shall maintain a detailed asset inventory of the SUC components. Vendor shall provide the Authority with the inventory at least 30 days prior to the SuC going live. The asset inventory shall include details on all hardware assets, and all required software components. The inventory shall include information about the physical location of the assets, the hierarchical relationship between systems, subsystems and components and the respect OEMs.

c) The Vendor shall update the system inventory upon maintenance or change events. The Vendor shall follow the Authority’s process to maintain an updated system inventory.

d) Assets shall be mapped to the SuC functions documented in Section 3: SuC Risk Assessment of this document. The asset's role in providing the function shall be detailed.

e) Asset inventory shall detail all subsystems and systems components. The Vendor shall provide the Authority with a listing of necessary network connection details and detailed network diagrams.

f) The Vendor shall supply the Authority with a list of all hardcoded accounts in the SuC including hardcoded accounts in subsystems.

g) The Vendor shall supply the Authority with a list of all accounts and roles necessary to operate the SuC.

h) For network segments under the management of the Vendor; Vendor shall utilize asset discovery tools to discover assets on the network at least once every seven days. Vendor shall investigate and document all unknown assets discovered on the network. Vendor shall update the system inventory accordingly.

i) The Vendor shall utilize the updated system inventory to perform vulnerability discovery as detailed in Section 5: Vulnerability Discovery, Reporting, and Assessment of this document.

j) System inventory shall include information describing the criticality of the systems, subsystems and components on safety and role(s) in the railway ecosystem (signaling, safety, rolling stock, communications, comfort, etc.).

k) System inventory shall include all virtualized components.

l) The Vendor shall categorize the SuC, its subsystems and components based on Authority’s systems categorization policy. The Authority shall review and approve the SuC categorization.

9 SECURE SYSTEM CONFIGURATION

9.1 HARDWARE CONFIGURATION REQUIREMENTS

Page | 10

a) The Vendor shall institute and follow systems hardening processes according to the latest Security Technical Implementation Guide (STIG) and Center for Internet Security (CIS) benchmarks.

b) The Vendor shall password protect the BIOS from unauthorized changes unless it is not technically feasible, in which case the Vendor shall document this case and provide mitigation measures.

c) The Vendor shall ensure that the hardware can support encryption according to FIPS 141-3 without impeding the hardware's ability to perform its intended function at required availability and performance levels.

d) The Vendor shall provide physical and cyber security features including, but not limited to, authentication, encryption, access control, event and communication logging, monitoring, and alerting to protect the SuC device and configuration from unauthorized modification or use.

e) The Vendor shall identify the physical and cyber security features and provide the methodology(ies) for maintaining the features including the methods to change settings from Vendor-configured or manufacturer default conditions.

f) The Vendor shall verify that the addition of security features does not adversely affect connectivity, latency, bandwidth, response time, and throughput, including during SAT when connected to existing equipment.

g) The Vendor shall remove or disable all software and hardware components and ports that are not required for the operation and maintenance of the SuC prior to deployment.

h) The Vendor shall provide documentation on components that are removed and/or disabled.

i) The Vendor shall configure the system to allow the system administrators the ability to re-enable devices if the devices are disabled by software and provide documentation of the configuration change process.

j) The Vendor shall deliver all hardware free of backdoor accounts/access methods or security override processes. Hardcoded accounts shall have updated unique password according to the Authority’s password standards. Default passwords shall be changed.

k) The Vendor shall provide, within a pre-negotiated period, appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security.

l) The Vendor shall verify and provide documentation that the Safety Instrumented System (SIS) is certified after incorporating the security devices.

m) The SuC shall be capable of integrating with Authority’s Public Key Infrastructure (PKI) infrastructure and perform certificate-based device authentication.

n) The Vendor shall protect hosts from loading drivers and applications that are not cryptographically signed by an approved software development entity.

o) Hosts shall be configured for secure boot using UEFI Secure Boot. If a TPM chip is available, Vendor shall enable the TPM technology to assert a secure boot.

p) The Vendor shall recommend methods for the Authority to prevent unauthorized changes to the Basic Input/Output System (BIOS) and other firmware.

9.2 OPERATING SYSTEM SECURITY

q) The Vendor shall follow the CIS Security Technical Implementation Guides (STIGs) to configure the operating systems securely for all operating systems installations.

r) The Vendor shall be responsible for maintaining operating systems installation updates according STIG requirements.

s) The Vendor shall deploy the Authority-provided Endpoint Protection Software supporting all instances of the operating system. At the Authority’s request, Vendor may provide and deploy Endpoint Security Protection software. If the Vendor provides the endpoint security software, all alerts and detections generated by the endpoint security package(s) shall be routed to the Authority’s Incident Response Center. The Authority shall review and approve the Endpoint Security Protection software and its configurations.

Page | 11

t) All alerts and detections generated by Endpoint Protection software shall be routed to the Authority’s Security Operations Center.

u) Only required and secure ports and services shall be enabled.

v) All safety critical systems shall enforce software whitelisting rules.

9.3 VIRTUALIZATION SECURITY

If the SuC is an integrated system and requires a virtualized environment, the Vendor shall follow the CIS security benchmarks for the latest cybersecurity recommendations for the virtualization platform. If specific guidance is outdated or unavailable, Vendor shall follow the latest cybersecurity best practices provided by the software vendor and recognized cybersecurity entities to protect the virtualization infrastructure. At a minimum, Vendor shall perform the following actions to secure the installation of hypervisors and related infrastructure components:

a) The Vendor shall adhere to all applicable sections of this document to manage the security of the virtualization environment and its subcomponents.

b) The Vendor shall configure hypervisors to leverage single sign-on for authentication and authorization. Local accounts shall be minimized and used only in emergencies following break-glass procedures.

c) All authentications and authorizations shall follow the requirements stated in Access Control section of this document.

d) Access directly to hypervisor hosts shall be limited to Secure Management Workstations. Access shall be logged and protected as privileged access. Access shall follow the Zones and Conduits security configuration. Vendors shall isolate hypervisor management traffic networks for their specific functions’ networks.

e) The Vendor shall use hypervisor official client to administer hypervisors’ hosts. Direct access shall be limited to emergency scenarios.

f) The Vendor shall only run hypervisor vendor approved software packages.

g) Virtualization environment components shall adhere to the requirements stated in this section of the document.

h) The Vendor shall ensure that hypervisors architecture is fault-tolerant following Authority’s recovery point and time objectives (RTOs and RPOs)

i) The Vendor shall validate and document startup tasks regularly

j) Virtualized networks shall be integrated into the Authority’s network management fabric.

k) All hosted components on the virtualized system shall follow the zone and conduit restrictions.

l) API keys and service accounts passwords should be vaulted in an industry-standard key vault/ key management service.

9.4 SECURING ACTIVE DIRECTORY

If the SuC is an integrated component of a system and requires a dedicated Active Directory installation, the Vendor shall follow the latest cybersecurity recommendations to protect the Active Directory installation. At a minimum, the Vendor shall perform the following actions to secure the installation:

9.4.1 Active Directory Security

The Vendor shall establish a program with related processes and procedures to protect Active Directory installations. The program shall be updated to reflect latest threat intelligence, industry guidance, and Microsoft’s recommendations. Additionally, the Vendor shall implement the following controls:

a) Maintain individual complex passwords for Privileged Accounts on all computers with membership in the domain/forest.

Page | 12

b) Refrain from giving individual users explicit rights on Active Directory Containers.

c) Implement processes to alert if permissions on any Active Directory containers have changed.

d) Enforce GPO not to cash credentials on all domain member computers.

e) Remove downstream clients from the domain.

f) Ensure that PowerShell logs are captured and analyzed by EDR tools.

g) Disable SMB when feasible. At a minimum, disable SMBV1 and SMBV2 protocols.

h) When feasible, disable the ability to run obfuscated scripts.

i) Domain trusts shall be reviewed and validated quarterly. Cross domain authorization shall be minimized.

9.4.2 Securing Active Directory Domain Controllers

The Vendor shall adhere to all applicable sections of this document to protect Active Directory domain controllers. Additionally, the Vendor shall adhere to the following security requirements:

a) Active Directory domain controllers shall be categorized as High in risk assessment rating.

b) Administrative access to domain controllers shall only be permitted from a secure management workstation. All other RDP or remote management protocols and methods shall be denied at the network level.

c) Domain controllers shall be prevented from accessing the Internet with possible exception for EDR tools.

d) Domain controllers shall run a version of the operating system that is supported by Microsoft.

e) Application whitelisting shall be enforced on all domain controllers.

f) Full desk encryption shall be enforced on all domain controllers and at all desks.

g) Active Directory databases shall be backed up on all domain controllers. Backups shall be encrypted and classified as the highest sensitivity data classification as per the Authority’s Data Classification Policy. Backups shall be saved to immutable storage backup system.

h) When feasible, domain controllers shall be deployed on a separate virtualization infrastructure.

i) Domain controllers shall be deployed in data centers and locations where physical access is restricted.

j) Access to the LSASS process shall be hardened.

k) Domain controllers shall not be excluded from any Endpoint Protection software or features.

10 TIME SYNCHRONIZATION

If not available through the Authority, Vendor shall use a GPS master station clock as a baseline reference for timestamps used for logs and systems generating logs. If GPS reference is not possible, Vendor shall use NIST authenticated time service. Public, unauthenticated, and unencrypted NTP pools shall only be used as an option of last resort, and only for as long as needed to begin leveraging other options.

The Vendor shall synchronize local time on all SuC components being leveraged at a protocol version with no known medium or high vulnerability.

11 DATA SECURITY

The Vendor shall establish and maintain a Data Management and Protection Program. The program shall be driven by a data classification process to enforce the appropriate controls based on data sensitivity.

Page | 13

a) Vendor shall follow the Authority’s data classification policy in creating an inventory of all data under Vendor’s management.

b) Vendor shall maintain an inventory of datasets, descriptions, classifications, and owners.

c) Vendor shall follow the Authority’s data retention requirements.

d) Vendor shall encrypt data at rest and in motion based on the Authority's classification requirements and in compliance with FIPS 141-3.

e) Vendor shall follow SP 800-57 Part1 Rev. 5 for management of encryption keys.

f) Vendor shall submit a Data Residency Plan detailing where data will be stored on the SuC components. Data residency shall follow the zone design based on zone security level and data classification.

g) Vendor shall implement Data Loss Prevention systems and processes where applicable.

h) Access and modification of data shall be logged based on the data classification requirements.

i) Data shall be disposed of in a secure manner to prevent unauthorize disclosure.

12 IDENTITY AND ACCESS MANAGEMENT SECURITY

12.1 ACCESS CONTROL

The Vendor shall establish and maintain Access Control Program to ensure that only authorized access is allowed to the SuC, its subsystems and components. The program shall ensure that all account changes and access activities are logged in a manner enabling auditing and incident response. All access granted shall follow an authorization process approved by the Authority. The Vendor shall provide the following:

a) The SuC, its subsystems and components shall require authentication and authorization prior to allowing access.

b) The Vendor shall configure the SuC, its subsystems and applicable components with options for integration with Authority’s Single Sign-on System.

c) The Vendor shall configure each component of the product to operate using the principles of "Least Privilege” and “Separation of Duties.” This includes operating system permissions, file access, device access, device user accounts, service accounts, and communications/data transfers.

d) The Vendor shall configure the SuC, its subsystems and applicable components with support for FIDO 2.0 U2Fbased authentication.

e) The Vendor shall configure the SuC, its subsystems and applicable components shall support role-based access and authorization. The role-based configuration shall be approved by the Authority.

f) If the SuC is not connected to the Authority Single Sign-on System, the Vendor shall provide a centralized User Account Management System. User accounts for onboard systems shall be configurable by the Authority.

g) The concept of Least Privilege shall be employed with a user account hierarchy in place.

h) The Vendor shall provide documentation for the user, groups, and role management and define security privileges and permissions.

i) Vendor shall perform account recertification and access reviews at least once every 30 days.

j) When feasible, access revocation and account de-provisioning shall be automated based on rules approved by the Authority.

k) The Vendor shall revoke access to accounts immediately upon termination of employees or change of roles.

l) All access from a less secure zone or network shall be challenged on FIDO 2.0-based authentication specification.

Page | 14

m) Access for processes from a lower security zone to a higher security zone shall be logged and controlled.

n) Where feasible, eliminate the use of shared accounts. If shared account are used, Vendor shall take steps to minimize access to shared accounts. Credentials for shared accounts shall be rotated at least quarterly and when a person of knowledge of the credentials no longer needs to use the shared account.

12.2 PRIVILEGED IDENTITY AND ACCESS

The Vendor shall implement a program to govern privileged identities and access. The program shall include the following requirements:

a) The Vendor shall follow the Least Privilege principle when granting privileged access.

b) All privileged access shall follow the request/evaluation /approval/denial process.

c) All privileged access authorization shall be documented in a manner to allow auditing of all changes with non-repudiation.

d) Privileged access and privileged escalation shall be challenged by Authority-approved MFA methods.

e) Any changes to privileged groups shall be monitored and alerted.

f) Users shall use separate accounts for privileged access and business functions access.

g) When feasible, Privileged Accounts shall be denied access to the Internet.

h) Service Account keys shall be vaulted. Scripts shall not have hardcoded credentials. The credentials will be requested from the vault at runtime.

i) The Vendor shall document procedures that define changing service account credentials according to the Authority’s Password Policy.

j) All privileged activities shall be tracked in system logs or other mechanisms.

k) Systems shall be protected against unauthorized privilege escalation.

l) Service accounts shall be assigned to technical and business owners.

m) Services accounts shall be restricted to access only systems the accounts are intended for.

n) Service accounts shall be denied interactive access to systems.

o) Services accounts where passwords have not changed for 6 months shall be flagged to owners with requirements to change the password within 15 days.

13 SESSION MANAGEMENT

The Vendor shall not, unless specifically requested by the Authority, allow multiple concurrent logins using the same authentication credentials, allow applications to retain login information between sessions, provide any auto-fill functionality during login, or allow anonymous logins, unless specifically requested by the Acquirer.

14 NETWORK SECURITY

The Vendor shall develop, maintain, and follow necessary procedures to protect the integrity and confidentiality of the information transmitted on any network as needed for the safe functioning of the SuC. Vendor shall design and implement SuC communication to meet the availability and quality goals set forth by the Authority during the SuC design process. The Vendor shall implement communication security protocols that assume networks may already have unauthorized access. The execution of the SuC network shall follow the Zones and Conduits security design detailed in the DCRA processes. All

Page | 15 network systems and configurations shall adhere to all relevant sections of this document. Additionally, the Vendor shall deploy the following controls:

a) The Vendor shall provide, and document secure network architecture including and not limited to the cases where the higher security zones connect to less secure zones.

b) The Vendor shall provide and document the design for all communication paths between networks of different security zones and through a DMZ.

c) The Vendor shall provide a method for managing the network devices and changing addressing schemes.

d) The Vendor shall verify and provide documentation that the network configuration management interface is secured.

e) The Vendor shall provide ACLs, port security address lists, and enhanced security for the port mirroring.

f) The Vendor shall ensure that security capabilities are not dependent on the network capabilities.

g) The Vendor shall deliver a security design allowing the usage of cable and radio-based networks.

h) The Authority shall define network requirements concerning availability and performance (bandwidth and latency).

i) All devices shall authenticate to the network prior to participation in sending and receiving safety-related communications.

j) Network shall have capabilities to log and audit access from less secure network to secure networks.

k) Network shall have capabilities to perform packet capture as needed (PCAP).

l) Devices participating in safety-critical networks with the ability to support certificate-based authentication, shall support the following:

1) X.509 certificates for identification with 802.1x authentication integrating into Authority-provided PKI infrastructure.

2) Device certificates shall be manageable remotely when feasible.

3) A method to remotely and securely install a signed X.509 certificate on the device is required along with installing the CA certificate.

4) A secure method must be available to programmatically install certificates on each device via automation without physical access to the device, and the Authority may, at its discretion, rotate certificates frequently (e.g., 24 hours).

5) Device certificates shall be manageable from a centralized system that allows updating certificates remotely in a controlled manner.

6) Certificate rotations shall not require outages or operational impacts (e.g., reboots). The device shall receive accurate time as defined in the Time Synchronization clause of this document.

m) The Vendor and Authority shall agree on acceptable encryption protocols and secure communication processes appropriate for each Security Level Target. Encryption keys shall be rotatable and updated remotely without impacting availability.

n) The Vendor shall not deploy deep packet inspection capabilities on safety-critical networks.

o) Where applicable, Vendor shall prioritize safety-critical communications.

p) The SuC, its subsystems and components shall support access control systems that validate the system’s security posture prior to admission into the network.

q) Network perimeter devices shall be configured to deny all access by default.

r) Network perimeter devices configuration shall be reviewed quarterly and reconciled against change management records.

s) Network device configuration shall be monitored for changes. Changes shall be validated immediately.

t) Network device configurations shall be backed up daily to a centralized location.

Page | 16

u) All access to network device configuration shall be treated as Privileged Access.

14.1 WIRELESS NETWORKS SECURITY

a) Authority SSIDs shall not be broadcasted by default and should be pre-configured on wireless clients.

b) Wireless communications with rolling stock shall be encrypted and authenticated.

c) Wireless clients accessing secure zones shall authenticate to wireless controllers using 802.11x and WPA2-Enterprise.

d) Guest wireless networks shall be restricted to accessing the Internet only.

e) Wireless controllers shall be configured to detect rogue access points, and rogue deployment locations and alert the Vendor and Authority on the same.

f) Rate-limiting shall be configured on wireless controllers to prevent Denial of Service failures because of excessively large authentication attempts or volume of traffic.

g) Wireless networks for secure zones shall have signal strength range minimized to required coverage area.

h) Wireless access points wiring to switches shall be concealed.

i) All wireless access points shall be deployed with static IP addresses, on a separate management network, have switchport security enabled and postured, using NAC of the Authority.

14.2 SEGMENTATION/MICRO SEGMENTATION

a) The Vendor shall verify and document that disconnection points are established between the network partitions and provide the methods to isolate subnets to continue limited operations.

b) The Vendor shall provide and document tailored filtering and monitoring rules for all security zones and alert for unexpected or anomalous traffic.

c) The Vendor shall deliver capabilities enabling the Authority to configure its components to limit access to and from specific locations (e.g., security zones, business networks, and demilitarized zones [DMZs]) on the network to which the components are attached, where appropriate, and provide documentation of configuration as delivered.

d) The Vendor shall retain a qualified third-party entity to perform security testing to verify that network separation is enforced.

14.3 PHYSICAL SECURITY

a) Vendor shall design communication networks assuming that physical local manipulation of equipment is possible. The Vendor shall build sufficient redundancy and separation for the network to withstand physical failure of communication paths without causing operational disruption.

b) Vendor shall submit fault tolerance design for the approval of the Authority.

c) Vendor shall ensure that wired networks are concealed and not exposed to the elements or human tampering.

d) Vendor shall restrict access to information related to the locations of critical infrastructure, interconnection and fallback scenario descriptions.

e) Vendor shall employ different redundancy technologies, such as a combination of wired and wireless communication between sites.

f) Vendor shall provision a redundant wired connection, and consider different deployment topologies (such as mesh, ring, etc.).

g) Vendor shall ensure that central services are locally replaceable to avoid overall service interruption by considering different options such as Island Mode deployment.

h) Vendor shall monitor physical equipment for unauthorized access, tampering, and degradation of performance.

Page | 17

i) Vendor shall develop maintenance processes and inventory, to respond to physical network disruptions.

15 ROLLING STOCK SECURITY REQUIREMENTS

The Vendor shall obtain approval from the Authority to establish and maintain up-to-date Cybersecurity Program(s) to protect all onboard SuC’s in a rolling stock. All onboard systems shall adhere to all sections of this document. The Vendor shall update the Detailed Cyber Security Risk Assessment for rolling stock components at least annually, taking into consideration the threat landscape evolution and technological updates.

Additionally, the following controls shall be applied:

a) Penetration tests (on a grey-box basis) shall be conducted on an annual basis, by a provider selected by the Authority. The scope of this test shall include all onboard systems and wayside systems.

b) The concept of Defense in Depth shall be applied to the security design of the system(s), such that failure in a single security mechanism shall not result in a compromise of the system or network.

c) A system for securely collecting, storing, and retrieving log files from onboard systems shall be in place. All log files, including security logs, shall be routed to the Authority log management system. The local log management systems shall be redundant and capable of storing a minimum of 30 days of logs.

d) All onboard networks must be monitored by a threat detection system, providing detections that include but are not limited to, unauthorized hardware, anomalous network traffic, reconnaissance activity, DOS attempts, and endpoint-based attacks. Threat detection alerts shall be routed to the Authority’s Incident Response Center.

e) End devices at particular risk of compromise, due to their function, or level of accessibility, including but not limited to Mobile Communications Gateways/Routers, and PIS controllers (with external access), shall be monitored by a Host Intrusion Detection System.

f) On-board networks shall be segmented and segregated using a firewall according to a Zone and Conduit model developed during an IEC 62443-3-2 Risk Assessment. Firewall rulesets shall be reviewed by the Authority on an annual basis.

g) Separate physical networks shall be established for:

1) Train control and safety critical systems

2) Operational systems

3) passenger-facing systems (such as WiFi, Media)

h) Access to hardware from passenger-accessible areas shall be secured with a unique physical key. Access panels shall not be in concealed locations (e.g., toilets) and must be observable by a video surveillance system.

i) Risk Assessments conducted on onboard systems shall, at a minimum, consider threats from:

1) Passengers (via wireless networks or physical access)

2) Bystanders

3) Authority staff (whether train crew or maintenance staff)

j) 10. Patching, system maintenance, and other system maintenance activities shall be performed from a trusted service laptop. The use of USB devices shall be strictly prohibited.

16 FAILURE MODE

Page | 18

The Vendor shall configure the system failure mode to guarantee safety if the system fails. The failure mode may be open or close, based on the safety case of the SuC and its components. Failure mode shall not impact the integrity of the system. The Vendor shall submit risk assessment for the failure condition per component to the Authority.

17 SYSTEM LIFECYCLE MANAGEMENT

The Vendor shall create a program to manage the SuC, its subsystems and components lifecycle. The program shall ensure that all components of the SuC remain under available support of the Original Equipment Manufacturer(s) (OEM). Throughout the Design Life of the SuC, Vendor shall be responsible for maintaining all components including those provided by second and third-party providers.

Planned obsolescence found in IT components may not extend to SuC components.

a) The SuC, its subsystems and components shall not reside on end-of-life operating systems, or any components, including embedded software that is expected to be deemed end-of-life by the OEM within 24 months from the date of deployment into production.

b) Embedded systems shall run software covered by OEM support for at least 10 years from the date of deployment.

c) SuC shall support the latest versions of operating systems on which Contractor-provided hardware and/or software functions within twenty-four (24) months from the official public release of that operating system version.

d) Digital systems shall have an assumed Design Life of 12 years with plans for a technology refresh over the lifetime of the system. Vendor shall provide documentation, including typical tasks and timelines for a successful technology refresh, while minimizing operational disruption.

e) Vendor shall provide security patches throughout the Design Life.

f) Device configuration shall be verified after maintenance and software patching, as some features may have inadvertently been reenabled or new features installed.

g) Systems or components that become obsolete and unable to be patched shall be replaced with a system with identical or superior functionality, as determined by the Authority.

h) Throughout the System lifecycle, the Vendor shall notify the Authority of any changes in supply chain components.

i) Vendor shall maintain an inventory of critical system components in corresponding nested systems order to supply replacements…