 |
| Modified from the original Wired's image |
Here's another part of the series devoted to cloud incident response.
This time we will talk about incident detection and incident declaration. These topics are closely linked and well developed in classical environments but are still immature in cloud services, so let's begin to explore them.
Phase 1 - Incident Detection
This phase is common to every security incident and, in non-cloud environments, can be performed either by a final user who sees something strange in his/her service or by an operational team that becomes aware of the problem. In the first case, the user can warn the security that performs some checks with the operational teams in order to clear the exact nature of the reported event. In the second case, the activation of the security team is internal and, usually, the investigations will start almost immediately.
This approach is a little bit different in cloud services because the roles of the final user and the operational team are tailored in a different manner and, in some cases, the Cloud Service Provider (CSP) could have only a portion of the essential data. So, taking a closer look at the possibilities, we become immediately aware that the erogation models of the cloud services change the operational scenario. Infact, also in the simplest situation in which the service is erogated directly by only one CSP, the state changes radically if the service is a Software as a Service (saaS), or a Platform as a Service (PaaS), or an Infrastructure as a Service (IaaS).
In the SaaS case, the user has only access to some personal activity log without any access to system information. In this scenario, the CSP has to conduct all the incident detection activities and the Cloud Service Consumer (CSC) is totally dependent on the information items shared by the CSP.
IaaS represents the complementary situation; in this erogation model the CSP directly manages only the network security layer, on the contrary all the information regarding the inner layer, from the OS to the application, are a CSC matter.
PaaS is in the middle between the previous cases with a different involvement of the CSC varying the implementation.
The above reasons imply that, in order to have the right instruments to respond to incidents in cloud environments, the information sharing between CSP and CSC is essential.
Since clauses regulate every aspect of the cloud services, also these matters have to be clearly defined in the contract.
These clauses have to set at least the following features:
- the expected pieces of information that have to be exchanged
- the triggers for the information sharing
- the temporal SLA for the exchange of information
- the confidentiality level of any information shared.
Phase 2 - Declaration
In this phase, after the detection, someone has to declare the incident. This moment is crucial for the effective response of an incident; a bad move in this phase might affect all the following activities, compromising the final outcome. But, who is in charge of this activity? And, which is the best way to approach this critical phase? And finally, which cases have to go public?
These questions are pertaining to every CSP and it's nearly impossible to give indications or best practices...
except this one: "Every CSP has to be well prepared!"
A plan has to be prearranged, officially issued and shared between the operational teams.
Moreover, after every incident a review has to be performed to verify the effectiveness of the plan.
In conclusion, every CSC, while approaching a CSP, should verify the presence and the effectiveness of such a plan checking the compliance of this document with law, regulations and his requirements.
Well, for this post it is enough, in the following parts I'll share with you other thoughts on the Cloud Incident Response, so... stay tuned!
