While the way enterprises consume technology continues to evolve, there are two trends that as of late arguably...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
dwarf all others. First, cloud usage continues to proliferate. Second, new data breaches continue to make headlines.
When a breach does occur, it can come as an unfortunate surprise that an enterprise's incident response planning is sometimes ill-suited to the cloud.
These two realities together make many organizations understandably wary about the likelihood of breaches pertaining to their cloud deployments. This fear is compounded because many times, use of the cloud presupposes ceding some portion of control when it comes to security operations. In other words, adopting the cloud -- whether delivered via an internal or external cloud service provider -- means purposefully "abstracting" underlying portions of the application stack.
Note that I'm not implying that cloud is necessarily riskier, less secure or more prone to a data breach than alternate delivery models (at least it's not that way "just because"). To the contrary, some data suggests that the opposite is true. But the fact remains that cloud users still get "the jitters" when it comes to security. Part of this is lack of control: Just like being a passenger on an airplane might be safer (according to the statistics) compared to driving a car, the lack of direct control over the operation makes it scarier.
That said, breaches at cloud service providers (CSPs) can and do happen. When a breach does occur, it could come as an unfortunate surprise if an enterprise's incident response planning is ill-suited to appropriate response by virtue of it being cloud. For example, consider that plans involving specific technical actions (such as disabling a network port to silence a malware-spewing host) become less workable when you have little or no operational control over the technology substrate.
This can be true in any enterprise cloud context -- be it Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS). Unless you've done some planning for this already, chances are good that responding to an incident in the cloud will involve steps your legacy incident response plan doesn't account for. For example, how do you get informed? Who's authorized to make a technical service request from a provider (and are they in the IR loop)? What's the mechanism to make a request? Is it a specific service console or is it a phone call? Do the members of the response team know how to get to that tool and are they provisioned with access?
Just like in a traditional IT environment, the time to figure out how these questions will be answered is not once you're in the thick of things; the time to prepare is now -- before it's too late. In this tip, we'll review how to plan a data breach response for an incident involving a cloud service provider.
Laying the groundwork
The first thing enterprises should do is revisit notification pathways in light of the cloud: meaning, how (and whether) CSPs will report a data breach or other security incident to your organization if it happens. That sounds pretty straightforward until you stop to actually unpack it operationally, namely because different usage and delivery models -- and different service providers -- could change the way in which a customer is notified.
For example, consider a large-scale IaaS deployment such as a virtualized data center. In this scenario, there might be contractually dictated requirements governing how and when breach notifications will occur -- maybe they alert you to specific technical events via a contractually defined channel. By contrast, SaaS business applications might specify notifications contractually but not require sharing of technical details. Others, such as consumer-oriented services like DropBox, might not have a "contract" with you at all (other than the "click-wrap" targeted to individual users), let alone one that's specific about breach notification.
The point is, there's probably not a consistent notification position for all cloud services across the board. So, "How will you know when a breach happens?" is a trick question. Just like usage can't be painted with the same brush, neither can notifications. Instead, enterprises must evaluate CSP relationships, usage and notification options case by case. (Note that this implies that an enterprise knows what its usage is in the first place. If not, it should start there.)
When evaluating each cloud usage case in this way, be sure to look at what the CSP is required to do contractually (or by agreement for an internal provider), the mechanism (if any) for informing you about events, and what your options are for tailoring your interaction with them, as referenced above. Pay particular attention to three things during evaluation: how you're using the service (i.e., type of data stored, business processes supported, etc.), key personnel (on both your side and theirs), and what you're responsible for doing operationally to locate breaches (for example, reports that are on you to evaluate, like intrusion detection or application logs). This data will be important in subsequent planning phases.
Starting with larger deployments like centralized IaaS and PaaS is helpful because they are an easier hill to climb. Applications (like SaaS) are important too, but keep in mind that tracking them all down is a significant undertaking -- recent data from Netskope, for example, suggests that organizations have an average of 397 cloud applications. So analyzing each one independently will likely take a bit of time and effort.
The key point here is to start with what's easy and build off of that. Documenting as you go (for example, using a spreadsheet to list cloud usage/environment, corresponding impact, notification mechanisms and key personnel) is a good idea, given that this inventory may get more complicated over time.
Planning operational response
Once you've gathered the required data, it's time for the second phase of planning: triage and an operational response blueprint. If this sounds a lot like "traditional" (sans cloud) breach response, you're spot-on. In fact, cloud breach response can be best accomplished as an extension of a broader response planning effort. Yes, there will be by-environment differences -- such as the personnel you involve, technical response options and alert/notification pathways -- but keep in mind that most usage will have interaction points between cloud and traditional IT elements. This means that trying to maintain a separate response process for cloud components in isolation will inevitably lead to undesired complexity, lack of clarity (for example, about operational responsibilities) and additional overhead during an incident.
As with traditional disaster recovery and incident response planning, prioritization should be based on impact, which is in turn a function of data type and business criticality. These two factors will also let you know whether or when or how other processes, such as external disclosure procedures, should be brought in. One difference here compared to existing incident response processes is that it can be helpful to customize response personnel based on relationship, because some actions you may wish to take will involve interaction with personnel at the CSP. For example, you may require your CSP to effect technical changes on its side or provide additional information to you. In those cases, you might choose to make note of those with the most experience with that CSP (like relationship managers or technical points of contact) who know the key players at the CSP and can help apply leverage to get tasks done if need be.
The point is: Collect enough information to allow construction of a "response blueprint" for the actual tactical activities you'll need to accomplish. Because the specifics of response will vary by environment, usage and relationship, as well as other variables, you may want to be a bit more specific about technical actions in the artifacts you put together; for example, incident response plans and technical checklists. Why? Because you may wish to customize technical response actions based on what the provider does or does not allow you to do technically, how its service is structured, and so on.
Bearing in mind that there will be differences when it comes to response in the cloud, doing this first wave of detailed planning for how your organization will account for those differences in technical plans is a useful first step.
About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.