Home » cyber security » Cloud Service Providers: Don’t let Your Response become Your Incident
incident response plan

Cloud Service Providers: Don’t let Your Response become Your Incident

More often than cloud service providers (CSPs) would like to admit, they find themselves creating a new incident with their incident response. The person in charge doesn’t have the proper authority. The incident handling process has insurmountable gaps or overlaps. The organization’s tools are outdated. Or its staff is stretched too thin or not trained properly.

These issues lead to a myriad of problems — from not discovering an incident to loss of revenue and/or reputation. To avoid these pitfalls, FedRAMP has established clear incident management guidance for CSPs. As a CSP, your ability to identify, document, and remediate is under constant scrutiny, which is why it’s important to implement these best practices to ensure your responses don’t become incidents.

Identify a PiC & PoC. First and foremost, establish a person in charge (PiC). While incident response plans usually identify a PiC, this person often lacks the authority to make decisions on behalf of the company, or doesn’t have the technical aptitude to determine the severity of the incident. You should also designate a point of contact (PoC) who can minimize confusion and media leaks, as well as communication and coordinate with with executives, law enforcement, legal personnel, US-CERT, software venders, and staff.

Put a process in place. A clear and current process allows the incident response team to identify and remediate an incident in a timely matter. In the event that a perpetrator is identified, a documented and repeatable process increases the odds that legal action can be taken. You many need to periodically reevaluate your total incident response capability, as well as the process for remediating individual threats, as new technology can make some processes and plans redundant or obsolete.

Ditch outdated tools. Most companies maintain the bare minimum in incident response technology: antivirus, logs, and maybe even an IDS. These tools, especially a properly administered enterprise antivirus solution, can be highly effective. However, depending on your risk posture, advanced tools may be necessary. These include traffic analyzers, advanced debugging and forensic tools, SIEMs, heuristic malware detectors, and automated breach defense. These tools can help identify precursory indicators, correlate log information, uncover hidden malware, flag anomalous behavior, and even automatically remediate issues. Just make sure you have a need for the tools you’re implementing…and a trained IT team that knows how to use them.

Put together a knowledgeable incident response team. Your team’s size should be commensurate with the size of your system because the same individual may not be able to identify anomalous web traffic and forensically analyze malware. Frequently, the problem with an incident response team is a single point of failure. The PiC is relied upon to be the lead investigator, code reader, communicator, and tools expert. Incident response shouldn’t fall on just one person’s shoulders – it needs to be a team effort.

Invest in training for your team. A well-qualified staff can justify the cost of training. Ensuring your staff knows how to identify, counter, and remediate common threats can decrease response time and prevent associated/related incidents from metastasizing or even occurring in the first place. These reductions minimize labor costs, risk exposure, and damages.

Focusing on these best practices can help ensure your organization has a strong Incident response capability. However, these efforts should be coupled with a comprehensive incident response plan that’s regularly revisited based on your incident response plan tests and the lessons learned from them.

One of the common reservations organizations have in adopting the cloud is security concerns — a fear of data loss, disruptions in operation, and inaccessibility. Companies entrust CSPs with their reputations and bottom lines, yet a single incident on the provider’s side can take down multiple organizations.

To assuage these concerns, FedRAMP enforces strong reporting requirements and encourages cooperation between the FedRAMP ISSOs, clients/agencies, and US-CERT. This requirement is constantly reviewed and updated and, as of Oct. 1, 2014, all verified incidents must be reported within an hour to US-CERT. A predefined taxonomy has been established to ensure completeness and consistency. This not only increases trust amongst these organizations through transparency and awareness, it also allows CSPs to leverage US-CERT’s scope, scale, and cross-agency security expertise. This coordinated effort means Incidents can be detected, contained, and resolved faster and more effectively.


About Spence Witten

Spence has somehow survived ten years at start-ups and small businesses without suffering a (major) nervous breakdown. As Lunarline's Director of Federal Sales, Spence actually loves working on proposals. If there were any doubt, this is proof that he is in fact certifiably insane. While his title says "Sales" Lunarline doesn't let him off that easy. We make him do real work, too. Luckily he's a recognized subject matter expert in security policy and loves helping clients navigate their way around tricky security compliance standards. He's also been known to lead a software development initiative or two, though that pretty much always ends poorly for everyone involved. He can be reached at spence.witten@lunarline.com.