ORLANDO, Fla. -- Responding to a security incident in the cloud isn't that much different from a traditional security incident response, with one key exception: An enterprise must know where its cloud provider's responsibilities end and its responsibilities begin.
That was a key theme in a discussion about cloud security incident response Wednesday at the 2013 Cloud Security Alliance Congress. Borrowing her definition in part from IT Infrastructure Library, speaker Kristy Westphal, information security officer with Element Payment Systems Inc., defined a cloud security incident as an unplanned interruption to a cloud service or a reduction in the quality of that service.
Naturally, all organizations want to resolve security incidents quickly, but Westphal said that to do so successfully in the cloud, an enterprise must define and implement its cloud incident response process.
The plan can be highly detailed or as simple as a checklist. As a baseline, Westphal said, an organization must first be able to identify the incident and whether it's indeed security-related. Next, it must define whether the incident involves a cloud provider; if so, the organization must be able to quickly determine the provider's role in the analysis of and response to the incident.
That, Westphal said, requires due diligence well before an incident ever takes place. It starts with the development of an inventory of the cloud provider's processes, and a diagram or other reference listing the systems within the cloud environment.
"Sometimes this is hard with cloud providers," Westphal said, "but you need to have a clear delineation." Though many providers, such as Amazon Web Services, now make cloud system inventorying as easy as an application programming interface call.
Westphal recommended that organizations initiate conversations with their providers about specific incident response roles and responsibilities, such as who is in the best position to be able to define "normal" behavior of cloud systems, who is responsible for maintaining logs of cloud-based systems, who owns critical tasks such as clock synchronization, who can or should run a packet sniffer, and who is ultimately responsible for remediating the problem.
Other important points to discern in advance include the contractual obligations of the cloud provider, how to gain access to a variety of different types of system logs -- IDS/IPS, routers and firewalls, email, server, antimalware, third-party monitoring, proxy -- and the business owner of each cloud instance.
"I can't tell you how many times I've been responding to an incident and I find myself asking, 'Who owns this thing?'" Westphal said. "It's easier to know ahead of time."
From there, the incident response process mimics that of any information security incident: containment, eradication, recovery, analysis and, if necessary, reporting.
Westphal recommended creating a Responsibility Assignment Matrix that lists the cloud incident response stakeholders, including the cloud provider, and the key steps in the incident response process. Per the acronym, the matrix should detail who is on the hook to be responsible, accountable, consulted and informed for each step.
While it may seem like overkill, Westphal shared findings of her informal research into the incident response processes of major enterprise cloud computing providers; none of them had any public documentation dedicated specifically to incident response, and only a few of them even mention incident response in the security best practices information.
Westphal learned this herself during an incident involving one of her organization's cloud providers. Her company had decided to issue its own internal certificates, but a problem with the registration of a new cloud certificate server affected inbound encrypted email messages.
After discovering she didn't have a direct incident response contact at the cloud provider, Westphal found herself calling an 800 number and waiting in a help desk queue. After getting bounced around from phone representative to another, she found an online list of second-level support contacts that soon resolved the issue.
"It did take several tries, and it ultimately was just an outage and not a security incident," Westphal said. "But it was a valuable exercise on how cloud providers might interact with you."
Attendee Shawn Mehaffey, an internal risk assessor with Raytheon Corp., said the advice was sound, but expressed concern that program managers and business analysts -- roles in large enterprises that often approve and oversee cloud computing implementations -- largely aren't aware of the importance of incident response planning and don't have the experience to manage it if they were.
Mehaffey favored the idea of running an incident response test to evaluate where an enterprise's strengths lie and how quickly the provider responds, because if a real incident occurs, a provider may have more than one customer affected.
"If a provider incident affects dozens or hundreds of customers, you have to know if it has the bandwidth to handle it," Mehaffey said.
Posts
0 comments:
Post a Comment