The secure way to the cloud [Part 2]

Do you remember that in the first part of our two-part blog series, we looked at general aspects of cloud providers, models and architectures, as well as the responsibilities involved in using cloud services? In the second article, we will explain what you need to look out for when you are implementing your cloud environment so that business requirements and security receive equal attention.

The “Egregious Eleven” – or the 11 enormous risks associated with the cloud

It would be a fatal error to rely solely on the provider for ensuring data security in the cloud. Companies would be well advised to deal with this issue themselves. The following eleven threats, referred to as “Egregious Eleven" by the Cloud Security Alliance (CSA), generally represent the current risk situation with cloud services:

1. Data breaches: data leaks and thefts intended to enrich the culprit and/or for subsequent publication.
   
   
2. Misconfiguration & inadequate change control: cloud services that are not securely configured or vulnerabilities that result from inappropriately managed changes.
   
   
3. A lack of cloud security architecture & strategy: inaccurate specification of the cloud security architecture required and no (or an inadequate) strategy for using cloud services in companies.
   
   
4. Insufficient identity, credential, access & key management: even operating on-premises within your own company is a challenge. This makes IAM (Identity & Access Management) in the cloud a critical component, especially in terms of managing cryptographic keys.
   
   
5. Account hijacking: hijacking or unauthorised third-party use of user accounts by (external) attackers.
   
   
6. Insider threats: threats posed by insiders at the CSP (cloud service provider) level and within your own company, especially employees and partners (third parties such as subcontractors, suppliers, etc.).
   
   
7. Insecure interfaces & API: insecure interfaces and APIs (application programming interfaces) are generally problematic. The reasons for this include insecure configurations, weak hardening or poor operation.
   
   
8. Weak control plane: cloud services are managed via the “cloud control plane". Correspondingly, the focus must be placed on the security and stability of this layer. If they are not made properly secure, the administrative privileges of the cloud administration consoles could be exploited by attackers.
   
   
9. Metastructure & applistructure failures: inadequate or inappropriate demarcation of responsibilities on the dividing line between different service models (see the first article for more information).
   
   
10. Limited cloud usage visibility: insufficient or inaccurate visibility of the (actual) use of cloud services – the keyword here is “Shadow IT" by business units, departments and teams.
    
    
11. The abuse or nefarious use of cloud services: abuse or inappropriate use of cloud services, which puts the customer and the CSP equally at risk. For instance, this can be where customers do not adhere to the agreed purpose of use and potentially perform illegal functions on the infrastructure of the CSP. This can also have an impact on other customers, for example in the case of an official intervention, such as the seizure of systems at the CSP.

The secure way to the cloud

These are the most common threats to companies using cloud services, so before migrating any service to the cloud, you should consider all of these factors. Subsequent migration requires cooperation between you as a customer and the cloud provider to ensure that maximum security is achieved.

There are various milestones on the secure route to the cloud. Ideally, these milestones will be analysed and defined before the journey starts:

• Identifying and applying legal requirements
  As well as the standard legal requirements, to a large extent made up of the Data Protection Act and the Swiss Code of Obligations/Contract Law (not all international providers' contracts or general terms and conditions are appropriate for Swiss conditions, depending on the contractual relationship), any regulatory requirements must also be clarified. And individual agreements with customers and suppliers, known as “contractual obligations", must also be taken into account. Data may be allowed to be processed in a cloud service from a legal and regulatory point of view, but maybe not based on a specific, individual contractual agreement!
  
  
• Data classification
  Classification is important to determine what data is allowed into the cloud at all and in what form it must be protected – and this needs to happen before it is even sent to the cloud. It is not just the confidentiality, but also the availability and integrity requirements that must be specified and applied to data gathering. Also bear in mind the data lifecycle that we described in the first article because from the creation to the disposal of the data, you are responsible for making it secure! But be warned - classifying unstructured data sets may be pretty time-consuming.
  
  
• Defining cloud (security) architecture
  How are the cloud services going to be used in the future and for what purposes? You should define the architecture you need and the interfaces to internal/on-premises systems and applications at an early stage. Ideally, of course, this should not be done "on the job" or based on an application that is going to be integrated into the cloud services. If not, you run the risk that the cloud architecture will revolve around a single application instead of providing a more generic, practical basis for enterprise-wide cloud deployment.
  
  
• Evaluating potential CSPs
  When making this assessment, there are more providers than just the “usual suspects". There are also plenty of medium-sized and smaller providers besides the giants. These are known as “hyper scalers" and are primarily from the USA with the corresponding effect of the US Patriot Act and the US Cloud Act on the cloud services offered. Carry out a systematic evaluation and do not overlook the security aspects.
  
  
• Do not forget about the central topic “Identity & Access Management” (IAM)
  In addition to the data lifecycle, you must also specify a practical key management system. And remember – even cloud services can fail. This is why a backup strategy is also essential here, to ensure that the data is adequately protected in the event of a failure!
  
  
• Keeping the cloud in check
  Last but not least, an issue that tends to come up “a bit later" – unfortunately often accompanied by disenchantment concerning expectations: Reporting, service-level monitoring, capacity and security monitoring as well as integration into your own or Managed Security Services (SOC, CDC).
  
  Often cloud service providers already offer their dashboards and reports, but do they cover everything you need? Can you access the raw data (events) and the systems themselves for monitoring purposes, or do you just have to be satisfied with what you’re given (including the layout)? Later (manual) integration into enterprise reporting is a complex and costly factor in cloud services that should not be underestimated.
  
  
• And on the same subject: cloud security event/incident management, security/penetration testing and "cloud forensics" must also be structured before the kickoff.

Certifications, standards and frameworks

To improve the lives of cloud managers in the company, there are various certifications and attestations that can be used for guidance. The best known are ISO 27001 – with the characteristic ISO 27017 (Cloud Security) – and ISO 27018 for processing personal data in cloud services especially for CSP.

For the attestations, there are the SOC 2 (Service Operator Controls) reports, with type 1 (Accuracy & Completeness, Suitability of Controls) and type 2 (like type 1, but with additional “Operational Effectiveness Throughout Period"), under the ISAE 3402 or ISAE 3000 standard. With the STAR programme (Security Trust & Assurance Registry), the CSA (Cloud Security Alliance) offers a total of three stages of auditing to demonstrate security and also compliance with data protection requirements.

Cloud security only works collaboratively

Of course, this creates new challenges for you, especially since compliance requirements are becoming more and more stringent, but this is precisely what it can be difficult to prove with a hybrid or multi-cloud. Not only do you need to make sure that on-premises, public cloud and private cloud are compliant; you also have to demonstrate that the opportunities for coordination between the clouds are guaranteed and secure. Multi-cloud environments, therefore, require an approach to security that is platform-independent and standardised. The provider and you, the customer, have shared responsibilities, with the provider responsible for the operation and security of the physical environment and you responsible for the logical environment.

Start with a clear view of your cloud

Using cloud services is a critical factor in success, so don't let the challenges put you off! If you bear in mind the requirements and specifications, hybrid and multi-cloud environments offer great potential that you should be making use of.

Do you know which cloud services are already in use in your company?

Our experience shows that cloud services are often used for specific projects or in some departments, and the IT department has no knowledge of them. Our Cloud Access Audit provides you with full transparency and clearly shows the inherent risks. You can learn more here!