Cloud Convergence – What Directors Need to Know Part 2

Partnership in Control

In Part One I looked at the need for TOCs to outsource IT and OT services carefully and to recognise it takes two to provide service. This following article places the onus on both the client and the supplier to agree IT and operational security best practice, to implement, maintain, monitor and improve. It looks at specific areas where they need to work together, but from a TOC point of view, what they must demand and expect from such a relationship.

Security Clearance and Operational Security

Where the SaaS provider is responsible for the custody of Train Operating Company information, be it  sensitive operational, maintenance, and business information or PII, its System Administrators and any other personnel able to affect the Confidentiality, Integrity or Availability of that data should be suitably security vetted and cleared. TOC clients must ensure providers produce a list of personnel with access to customer data with relevant clearance details. The SaaS provider must arrange for appropriate security clearance prior to personnel being granted access to customer data. A list of those with access must be forwarded to the TOC client with provision for notifying the client of all changes to the list.

SaaS Procurers must ensure Providers have documented Standard Operating Procedures (SOPs). SOPs must be provided that instruct administrators and users in provisioning, handling of data, backups and emergency or incident management, including when and how the client is to be notified of issues.

The System Owner needs a clearly defined process for enrolling new users and for disabling user accounts when they are no longer needed. The System Owner must agree the documentation detailing a well-constructed process of account management that complies with customer standards.

TOC clients must ensure providers have an acceptable method of establishing identity through Multi-Factor Authentication (MFA) if access to the SaaS application is to be accessible from outside the customers domain (BYOD). MFA should be performed using an authenticator app or through an SMS or email message to the user. This will be supplemented with a complex, machine enforceable, password conforming to customer Access Control policy.

Both the SaaS provider and the SaaS client require service access. But Providers need privileged access for account management and investigation of any breech. SaaS – appropriate levels of privileged access must be based on business need and have authorisation mechanisms (Role Based Access Control (RBAC)) or Attribute Based Access Control (ABAC)) in place to enforce the separation of privileges between different types of account. System Administrators of the SaaS provider should have access to the operating system and audit logs but not the application.

Senior Users of the TOC client should have provisioning access to create / delete / change accounts but not to the operating system or audit logs. Users might require access to different parts of the application depending on their business need (for example, some may be initiators, others could be approvers or auditors etc.). The integrity of separation according to the user role must be proven by the SaaS provider.

Data Recovery

When attackers compromise machines, they often make significant changes to configurations and software. Sometimes attackers also make subtle alterations of data stored on compromised machines, potentially jeopardising organisational effectiveness with polluted information. When the attackers are discovered, it can be extremely difficult for organisations without a trustworthy data recovery capability to remove all aspects of the attacker’s presence on the system.

TOC clients must determine the impact of business disruptions and risks to establish criteria for developing business continuity and operational resilience strategies and capabilities. They must ensure Providers establish backup and recovery procedures that are proportionate to the needs of the SaaS client.

Options of recovery timescales must be provided and agreed contractually with the client, thereby establishing strategies to reduce the impact of business disruptions. The contract must stipulate that the SaaS provider:

• Maintain a disaster response plan to recover from natural and man-made disasters. The plan must be updated at least annually or upon significant changes.
• Ensure that all system data is automatically backed up on a regular basis.
• Test data integrity on backup storage on a regular basis by performing a data restoration process to ensure that the backup is properly working.
• Ensure that backups are properly protected via physical security and encryption when stored or moved across the network. This includes remote backups and third-party cloud services.
• Ensure that all backups have at least one offline (i.e., not accessible via a network connection) backup destination.
• Exercise the disaster response plan annually or upon significant changes, including, if possible, local emergency authorities.

Change Control

Changes to information systems include modifications to hardware, software, or firmware components and configuration settings. These must be agreed between stakeholders to ensure changes are rational and can be supported.  TOC clients must ensure providers have a formal process of change control and extend this to the client so that changes to the service can be managed and formally.  A defined change control, approval, and testing process must be followed for SaaS provider and client-initiated changes, with established baselines, testing, and release standards. A process to proactively roll back changes to a previous known good state in case of errors or security concerns must be in place.

Encryption

The use of data encryption, both in transit and at rest, provides mitigation against data compromise. There must be proper management of the processes and technologies associated with the encryption operations. An example of this is the management of cryptographic keys used by the various algorithms that protect data. The process for generation, use, and destruction of keys should be based on proven processes as defined in standards such as NIST SP 800-57.

Care should also be taken to ensure that products used within an enterprise implement well known and approved cryptographic algorithms, as identified by NIST. Re-evaluation of the algorithms and key sizes used within the enterprise on an annual basis is also recommended to ensure that organisations are not falling behind in the strength of protection applied to their data. For organisations that are moving data to the cloud, it is important to understand the security controls applied to data in the cloud multi-tenant environment and determine the best course of action for application of encryption controls and security of keys. When possible, keys should be stored within secure containers such as Hardware Security Modules (HSMs).

TOC clients must ensure providers implement a clearly defined policy on encryption for client data both at-rest and in-transit. Encryption services must be utilised that follow best practice. This includes having cryptographic, encryption and key management methodologies, defining roles and responsibilities. Cryptographic protection is to be provided for data at-rest and in-transit, using cryptographic libraries certified to approved standards such as AES 256 standard, while VPN traffic should utilise IPsec or TL:S 1.2 (or later). The encryption algorithms used are appropriate for data protection, considering the classification of data, associated risks, and usability of the encryption technology. Processes, procedures, and technical measures must be in place to remove a cryptographic key prior to the end of its established crypto period or if it is compromised.

Data Centre Security

Most SaaS providers utilise the resources of multi-national platform or IaaS providers such as Amazon or Microsoft. These have known certificated physical security attestations. Where this is not the case, the TOC client must be assured of the physical security of the data centre, its location, and connectivity, bearing in mind that multiple locations may be used to provide a single service.

Even where a SaaS supplier uses AWS Cloud Hosting, it might be necessary to further establish where data might reside. TOC clients must ensure providers are able to satisfy the client that the physical security of the data centres used conform to international standards. They need to be sure that services are delivered from Tier 3 Data Centres (or better!) that conform to ISO 27002:2013 and / or to NIST SP 800-53 revision 5. Physical security controls include physical access control devices, physical intrusion and detection alarms, operating procedures for facility security guards, and monitoring or surveillance equipment. Environmental controls include fire suppression and detection devices or systems, sprinkler systems, handheld fire extinguishers, fixed fire hoses, smoke detectors, temperature or humidity, heating, ventilation, air conditioning, and power within the facility.

Data Protection Act 2018

The TOC client must be assured that no breach of the Data Protection Act 2018 is to occur during the SaaS contract and that data that may be required is fully accessible. They must be sure providers agree the contractual obligations as Data Controller and Data Processor. The SaaS provider must:

• Conduct a Data Protection Impact Assessment (DPIA) to evaluate the risks of holding and processing personal data, according to any applicable laws, regulations and industry best practices.
• Ensure any transfer of personal or sensitive data is protected from unauthorised access and only processed within scope as permitted by the respective laws and regulations.
• Enable data subjects to request access to, modification, or deletion of their personal data, according to any applicable laws and regulations.
• Ensure that personal data is processed according to any applicable laws and regulations and for the purposes declared to the data subject.

Virtualisation and Containerisation

The SaaS provider will endeavour to maximise the potential delivery of the platform by applying virtualisation and/or containerisation for the logical separation of clients’ business*. The TOC client needs to be assured that best practice is adhered to, and the integrity of data separation is maintained. SaaS Procurers must ensure Providers maintain policies and procedures for infrastructure and virtualisation security. The SaaS provider must:

• Plan and monitor the availability, quality, and adequate capacity of resources to deliver the required system performance as determined by the business.
• Monitor, encrypt and restrict communications between environments to only authenticated and authorised connections, as justified by the business. Review these configurations at least annually and ensure they have documented justification.
• Harden host and guest operating systems, hypervisor, or infrastructure control plane according to best practices.
• Separate production and non-production environments.
• Use secure and encrypted communication channels when migrating servers, services, applications, or data to cloud environments.
• Identify and document high-risk environments.
• Implement defence-in-depth techniques for protection, detection, and timely response to network-based attacks.

* The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. This contrasts with operating-system-level virtualisation, where all instances (usually called containers) must share a single kernel.

Protective Monitoring

Protective monitoring provides a deterrent as well as a means to detect attacks in real time and to investigate them to learn lessons and to prosecute offenders. However, it can be costly, both in technical resource and manpower, and should be proportionate to the threat.

TOC clients must be sure providers maintain policies and procedures for real-time logging and monitoring that are proportionate to the threat and its potential impact. The SaaS provider must:

• Maintain policies and procedures for logging and monitoring.
• Implement and evaluate processes, procedures, and technical measures to ensure the security and retention of audit logs.
• Identify and monitor security-related events within applications and the underlying infrastructure. Implement a system to generate alerts to stakeholders based on such events and corresponding metrics.
• Restrict audit logs access to authorised personnel and maintain records that provide unique access accountability.
• Monitor security audit logs to detect activity outside of typical or expected patterns. Establish and follow a defined process to review and take appropriate and timely actions on detected anomalies.
• Use a reliable time source across all relevant information processing systems.
• Establish, document, and implement which information system data should be logged. Review and update the scope at least annually or whenever there is a change in the threat environment.
• Generate audit records containing relevant security information.
• Ensure the information system protects audit records from unauthorised access, modification, and deletion.
• Maintain a monitoring and internal reporting capability over the operations of cryptographic, encryption and key management policies, processes, procedures, and controls.
• Monitor and log facility physical access using an auditable access control system.

Incident Management

The TOC client must be assured all incidents are appropriately managed between the SaaS provider and client. They must be sure providers employ an agreed incident reporting, escalation, and management plan with named points of contact. This must reflect relationships between the providers (IaaS, PaaS, SaaS) and the client. The SaaS provider must establish an Incident Handling Plan which must be tested and reviewed annually. The plan shall form part of the contractual SLA with the customer.

Disposal

The TOC client must be assured that any media used during the contract, including storage, back up and storage area network (SAN) do not contain residual MII or PII after the termination of the contract or after the end of use of that media for purposes of the contract.

TOC clients must be sure providers employ appropriate sanitisation mechanisms commensurate with the classification of the information held.The SaaS provider must:

• Apply industry accepted methods for the secure disposal of data from storage media such that data is not recoverable by any forensic means.
• Track, document, and verify media sanitisation and disposal actions.
• Test sanitisation equipment and procedures to ensure that the intended sanitisation is being achieved.
• Apply non-destructive sanitisation techniques to portable storage devices prior to connecting such devices to the system.
• Enforce dual authorisation for the sanitisation of customer media in the custody of the SaaS provider.

Final Thoughts

Once all the complications are sorted, written down and all expectations are managed, worry about lock-in. In fact, worry about lock-in before you make the choice of SaaS provider. Sometimes trying to claim back your data becomes a very costly exercise. Especially as, over time, your reliance grows, the size of data grows, the business impact to your aggregated data grows and the risk you are facing makes the pulse beat faster – good business decisions are made early, carefully.

I hope to write more for Railway-News in the next twelve months. In the meantime, please register with www.transportcyber.com where I and other cyber rail professionals will try to provide news, best practice advice across the transport spectrum with a focus on cyber, the environment and the future.

Note: Joe Ferguson has over 40 years’ experience in IT, starting as a developer and project manager and has run his own consultancy businesses for over twenty years.  He can be contacted on  [email protected], www.linkedin.com/in/joe-ferguson-529842122 or visit www.il7security.com. IL7 is a major sponsor of www.transportcyber.com.

This article was originally published by IL7 Security Consultants.