This is the second post of the “Cloud Incident Response” series and, after the announcement of the CloudSIRT project, I want to begin our journey through this matter starting from the base... the scenario.
Infact, we need to investigate in detail the way in which the services are delivered in the cloud to better comprehend the reasons behind the necessity of a new and efficient approach to the Incident Response process.
Well, the majority of people think the world of cloud services is made by Consumers and Providers, but the reality is much more complicated. At the moment, mature cloud services are not a matter of you and your provider, instead, as the NIST highlights, at least three other major actors are involved in this business. These new actors (for a full definition of these roles see the “NIST Cloud Computing Reference Architecture”) are the following:
- Cloud Broker (the entity that manages the final services and the relationships between providers and consumers)
- Cloud Carrier (the intermediary that provides connectivity and transport of cloud services)
- Cloud Auditor (the independent examiner of cloud service controls to verify compliance).
To complicate matters further, a cloud provider can use subcontractors to deliver some specific features of his services (e.g. storage, computational resources, network, etc.).
So, in the real market, a consumer finds offerings for services that involve a combination of many players and each of these can contribute to the final service with a different weight and role. Finally, a consumer would not be completely aware of all the interactions amongst the providers of the service because, usually, he signs a contract with a front-end provider that, in some cases, could have an interest to hide the complexity behind the proposed service.
You can easily imagine that each of these players have to face general and specific threats (an interesting document on the cloud threats is the “Top Threats to Cloud Computing“ by Cloud Security Alliance) and security risks. The complex supply scenario multiply these threats and security risks combining them in various ways. As result, a security incident in the cloud involves many layers of the service with multiple mutual interactions and each layer involved could be managed by a different actor.
In one word, a mess!
So, incident response in the cloud is an activity that relies mostly on communication and information sharing among the various actors involved. A wise cloud consumer wants to be part of the incident response process but, often, a cautious cloud provider needs to maintain the whole process in his hands. Moreover, the provider has specific needs not to disclose some pieces of information belonging to other customers uninvolved by the incident. So, despite all the difficulties, the solution is to achieve a good balance between these diverging requirements and the only tools that can be used to regulate these information interchanges are contractual clauses and Service Level Agreements (SLA).
Hence, the first step in addressing an efficient incident response process is to set up specific contractual clauses regulating the information flows regarding incidents.
To achieve a good balance of these different needs, these clauses have to set, at least:
- a clear definition of an incident
- the incident declaration procedure
- the needs of cooperation between consumer and provider
- the expected information flows to/from the consumer in every phase of incident response
- the perimeter in which the incident related data can be used and shared
- the procedures and triggers to involve the law enforcement agencies
- all the involved parties along with their roles
In my opinion, this is the only way to lay the foundation stone for an effective incident response process within the cloud.
In the next parts I will focus on the ways to exchange data related to incidents and on the phases of the incident response process in the cloud… so, stay tuned!