All organizations depend, at least in part, on their data to carry out day-to-day operations. Yet new, high-profile data breaches are reported every week, and the costs of those breaches continue to rise
The core elements of an incident response program are straightforward and quick to establish. Let’s take a look at the critical processes within an incident response program that may be easily implemented in your organization.
Critical Processes of an Incident Response Program
A structured response assures consistent incident research and action. Responses to security incidents that may involve data loss typically follow a workflow such as this:
- Research the background details of the incident
- Consult with incident response advisory resources
- Develop, communicate and implement a resolution plan
- Follow-up to identify improvements
Of course an Incident Response Program needs to be established before an incident is detected and a response is needed. Let’s start there.
Setting Up an Incident Response Program
Here’s how to quickly establish an incident response program:
- Identify an incident response leader who has good knowledge of your business and who is an effective and responsible problem solver.
- Assemble and empower a team of critical stakeholders, with clearly defined roles and responsibilities.
- Draft your incident response process and establish documentation standards. The key is consistency in how you respond to incidents. There’s no need for a complicated plan. Just make sure it works for your organization’s culture.
- Connect people and tools with the needed capabilities from around your organization. Chances are, much of what you need is already in place.
- Understand the most significant capability gaps relative to your draft incident response process and build a plan to address those gaps. Start with a minimum viable process, and then enhance it over time.
Detection of Events
New incident discovery comes from many different sources:
- Internal users
- Internal monitoring tools
- Internal risk-assessment tools
- External customer
- External entities
- Social media
The best place to start? Employee awareness. Make sure your workforce understands the security risks to the business and what to look for. It’s easy to overlook an anomaly when you believe everything is safe.
Second line of defense – automation. Monitoring tools, including analytics of anomalous traffic or user behavior, are invaluable.
Finally, keep an eye out on social media. Bad news travels fast. You don’t want to be the last to know.
Triage and Containment
The triage process begins as soon as a data incident is detected and it involves research to understand the situation and to determine which actions need to be taken and when. Ask the following questions:
- What is the nature of the event?
- Is the event ongoing?
- Is the event known or likely to be known outside the organization?
- Which systems, applications, products, or services have been affected?
- Is customer, personal, or other sensitive data actually or potentially exposed or compromised?
“Containment” refers to all efforts to stop, contain, and control the incident and data loss. These actions need to be taken as soon as practically possible to prevent further data compromise.
As soon as the necessary steps have been taken to contain and control an incident, document all the actions taken and produce a response plan. Your plan may include:
- Actions to remediate
- Communications, both internal and external
It is important to understand the root cause, nature, and scope of the incident before creating the response plan.
After completing the activities in the response plan, review the status of the incident and summarize the lessons learned. Post-incident actions can improve future data security practices.
It makes sense to select a risk posture when it comes to post-incident action. In some cases, many actions will need to be undertaken, not all of which will provide the same levels of improvement, equivalent increases in security, or relative returns on investment.
The operation of your organization depends on its data.
Build an effective detection and response plan so that you can avoid fines and remediation costs, protect your organization’s reputation and employee morale, and maintain business.
The simplicity of the incident response process can be misleading. We also recommend tabletop exercises as an important step in pressure-testing your program.
For More Information
To learn more, please visit the Trust and Transparency Center.
I am confused about the difference between a “Data Incident Response Team” and a traditional SIRT. The description you offer above looks almost identical, so I’m trying to determine why my company now needs a separate response team just for data issues? Maybe it’s just the terminology that is confusing, but it seems like you are advocating a completely unique team only for response to security incidents involving lost data. Is that correct?
Sorry for the delay in response. Your questions are great and I wanted to make sure we did respond.
There is enough uniqueness in the scope of a SIRT and Data Protection Incident Response (DP IR) team that makes staffing separate functions advantageous. The goal and strategy followed is different enough so that asking one set of management and staff to accomplish both will be an insufficient approach.
A big difference in the SIRT and DP IR incident response reality is the duration of engagement. SIRT teams often focus on time to identify, triage and resolve an incident. The inability to close out a case for extended periods of time would drive a SIRT manager crazy. However a DP IR team is able to work the many long-term phases of a severe incident and accept the extended time it takes to accomplish something which is more politically sensitive than technically risky.
It is not unusual for a DP IR team to lead an incident for months while many time-consuming response steps are executed. Data incidents may also occur outside the organization and within a business partner. Situations like this often require patience as the victim performs their own investigation resulting in long periods of time without status change.
It is common for an incident to require analysis, initial response, investigation, communication, legal consultation, executive escalation, external communication for months due to an incident as simple as malware found in a partner infrastructure.
Combine this with the growing number of US and global data protection regulations, including GDPR which will dictate how immediate and ongoing communication to a Government regulatory body must be maintained and you have made the scope of a good SIRT team too broad.
Allow the SIRT team to focus their energy on the technical response to their constantly evolving threat actors and attacks. Provide for a structured response to data incidents that is equally professional but focused on what could be longer term objectives.
At Cisco, we have the skills of an industry leading SIRT organization that has a highly technical and knowledgeable staff able to bring a security incident to a rapid close. The new DP IR team is growing their skills to respond to data incidents requiring long term engagements, compliance with regulatory or contractual demands and executive level communications. Asking one team to do both, is risking failure everywhere.
Wonderfully articulated a critical capability each enterprise must posses. I think one component that can be added is to model the system and evaluating vulnerable points in the system by stress testing this model on an on-going basis.
Second area that we can add is if an incident is detected how quickly we can isolate the affected system and contain the infected area.
Lastly conducting some mock drills to test the readiness and effectiveness of our emergency response process and procedures on a quarterly basis will be beneficial.
Comments are closed.