Cloud Complexity – Procurement Pitfalls for the Director who wants to know

Cloud Complexity – Procurement Pitfalls for the Director who wants to know

 

Train Operating Companies depend on Cloud

The railway industry is increasing cloud dependent.  Cisco estimate that £24 Billion will be spent on Internet of Things projects by the railway industry in the next 5 years. We are using Software as a Service, or SaaS, for applications throughout the delivery spectrum and downsizing our on-premises capability. Not only is it Office 365 for our mail, documents, and Teams for conferencing, it is all those business applications that make everyday life easier. Google and Amazon have joined Microsoft as the tech giants that over the last ten years have revolutionised where we process and how we store our data. It’s not just IT but operational technology that is increasing outsourced to the cloud for monitoring and efficiency. SaaS providers offer combined status information from diverse on-board public assets such as toilets, food chillers and ovens, presented alongside current positional information can improve the customer experience and reduce penalties associated with having these out of service. Cloud offers cost savings, resilience and work anywhere capabilities. But it also places security responsibility outside of ‘our people’ and represents grave danger when it all goes wrong, when those nation state cyber adversaries realise transport is critical to UK business and target rail information and operational systems. The “techies” in the Train Operating Company’s (TOC) IT department know all about cloud, but do senior managers and directors, those responsible for the performance, safety and paying the fines when things go wrong, know the potential for those things to go wrong? Do they recognise the complexity of the responsibility they place of their technical people or those that procure their cloud services? This article seeks to explore and expose these complexities to senior management.

 

Hope and Faith – reliance on outsiders

When we put our faith in planning software, billing software and business applications hosted in the cloud, it must not be blind faith but considered partnership with capable suppliers. Even when we outsource a relatively unimportant facility such as rewards management or collaborative whiteboarding, we are potentially endangering our sensitive and personal information, giving outsiders unnecessary access to data that might allow criminals the means of attack. Ransomware is becoming prevalent and targeting both our information and our operational technology. We must not give attackers the keys to our house. I have advised on cloud services for many years and have provide assurance and policy about SaaS for train companies. I have recently provided policy documents to the Department for Transport the Home Office and the Ministry of Defence.  I have put down the advice I gave them with a specific emphasis on our transport industry as a contribution to Cyber Transport capability and security.

 

The obligation to protect

SaaS delegates to the service provider much of the obligation to protect data. While SaaS is defined as a delivery model for providing licensed software on a subscription basis, it has evolved to the degree where the application and the processing are on the vendors site or more realistically in the cloud, a physical or virtual space rented by the SaaS provider from a host. This host in turn is responsible for providing Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) and the security around these services. There is then a mixture of owned, shared, and delegated security responsibilities and obligations. While the threats to data rincrease, Project Managers and System Owners need to ensure that all parties recognise their responsibilities and fulfil the obligations placed upon them. The objective of this article is to ensure all SaaS procured for consumption by the transport industry are fit for purpose and protect the confidentiality, integrity, and availability of sensitive information (business and commercial) and Personal Identifiable Information (PII).

 

Risk Based SaaS Procurement

Firstly, buying cloud services should be subject to a risk assessment. Many cloud-based services are beneficial to productivity and business, but implementation varies, and they need to be assessed for suitability from a risk perspective. With SaaS the end user gets access to the applications they need, which the provider hosts on infrastructure and platforms in the cloud. 

 

Client-Side Responsibility

TOC Service Owners, Procurers, and Projects, TOC clients, must ensure they examine any inherent risks associated with the service they are provisioning and introduce client-side precautions accordingly. As service procurers, TOC clients should assess whether a service can be accessed from non-company devices over the internet as this adds risk of data leakage. TOC clients must ensure:

 

1. User SyOps are in place which cover confidentiality and acceptable use and reflect the impact of data leakage.
2. Controls are used within the application to enforce identification and authentication of all users. Can these be integrated with company ID and Access Management – Federated Active Directory Services come to mind.
3. Use of non-company devices is subject to policy (Bring Your Own Device).
4. Usage monitoring and recording are used as a deterrent as well as enforcement with appropriate levels of recourse for non-compliance.

SaaS Providers

For SaaS providers to provision security controls that are appropriate and proportionate, they will need to calculate their residual risk based on the value of their assets and the impact of a security breech. TOC clients must ensure providers have a risk management process that includes clearly communicating risks between contributing providers (Infrastructure, Platform, and Software providers) and the client. The SaaS provider must have a formal, documented, and leadership-sponsored Enterprise Risk Management (ERM) program. This ERM is to include policies and procedures for identification, evaluation, ownership, treatment, and acceptance of cloud security and privacy risks. SaaS providers offer themselves as custodians of customer data and must demonstrate a security posture that flows from board-level to the most junior employee. The SaaS provider must have policies and procedures that demonstrate compliance with International Standards

 

Client Responsibilities

The TOC client must have access to a customer interface where they can address performance, extra functionality, and security issues. While in some instances the SaaS providers might appoint a Single Point of Contact (SPOC) the client needs to be able to escalate issues if the SPOC cannot be contacted or satisfaction is not delivered. TOC clients must ensure providers furnish clients with a matrix of service management functions and points of contact.

 

RACI

Roles and responsibilities for planning, implementing, operating, assessing, and improving governance programs must be defined and documented. This matrix or RACI should clearly indicate responsibilities, contacts, deputies, and an escalation path with phone numbers.

 

Security Clearance and Operational Security 

Where the SaaS provider is responsible for the custody of customer 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:

1. 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.
2. Ensure that all system data is automatically backed up on a regular basis.
3. Test data integrity on backup storage on a regular basis by performing a data restoration process to ensure that the backup is properly working.
4. 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.
5. Ensure that all backups have at least one offline (i.e., not accessible via a network connection) backup destination.
6. 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 cryptoperiod 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 service are delivered from Tier 3 Data Centres (or beter!) 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:

 

1. 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.
2. 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.
3. Enable data subjects to request access to, modification, or deletion of their personal data, according to any applicable laws and regulations.
4. 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:

 

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

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:

1. Maintain policies and procedures for logging and monitoring.
2. Implement and evaluate processes, procedures, and technical measures to ensure the security and retention of audit logs.
3. 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.
4. Restrict audit logs access to authorised personnel and maintain records that provide unique access accountability.
5. 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.
6. Use a reliable time source across all relevant information processing systems.
7. 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.
8. Generate audit records containing relevant security information.
9. Ensure the information system protects audit records from unauthorized access, modification, and deletion.
10. Maintain a monitoring and internal reporting capability over the operations of cryptographic, encryption and key management policies, processes, procedures, and controls.
11. 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:

1. Apply industry accepted methods for the secure disposal of data from storage media such that data is not recoverable by any forensic means.
2. Track, document, and verify media sanitisation and disposal actions.
3. Test sanitisation equipment and procedures to ensure that the intended sanitisation is being achieved.
4. Apply non-destructive sanitisation techniques to portable storage devices prior to connecting such devices to the system.
5. 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.