30 Jul Incident Response Preparation
Incident Response Preparation
Many of our customers question the best methodology out there to respond to an incident, and most places just need a push in the right direction to create an effective response to the incidents they see every day. There are big data breach responders tackling the huge incidents that span multiple months of identification, containment, and remediation, but most places we deal with just want something in play to remediate the small incidents and keep moving. As a result we’ve come up with a few questions to ask yourself when starting an incident response program:
1) Who owns the technology?
Defining technology ownership will create efficiencies and allow a process framework to be built, and automated. Without these owners or this framework it will be impossible to frame the process and obtain automated incident response scaling. Places to think about include:
- File Server Administrators
- Network Engineers
- Windows Administrators
- Data Owners
- Desktops/User Endpoints
- Email Infrastructure
- Security Infrastructure (IDS/IPS, Firewalls, ATD, etc)
- Data Backup
- Human Resources
2) How do you retain organizational knowledge?
Define how knowledge from previously taken actions is retained to help create efficiencies, and get away from a single point of failure in an organization. This knowledge base would allow an organization to map repeatable processes down from one high end responder and empower other teams in the organization to squash problems before they exhaust valuable personnel time. Many organizations focus on SharePoint sites, and spreadsheets, but both of these solutions scale poorly over time.
3) What is an incident?
Understand what an incident means to your organization, there are many definitions from groups such as FIRST, NIST, or SANS, but each organization needs a custom definition that meets its needs. Examples of incident definitions include:
An event that could result in unwanted access, denial of service, or unauthorized software associated with a company asset.
4) What roles do the organization’s responders play?
Define a few roles associated with incident responders, and make those roles adjustable over time. These roles should be assigned based on function as a large team may handle multiple, concurrent incidents, or may respond to a large, multi-day or week incident requiring handoff based on personal schedules. Examples include:
Lead Responder – Coordinates between different operational, security, or internal teams to coordinate activity and appropriately respond to an incident.
Technical Responder – Performs analysis on logs, signatures, and other metadata associated with the event to form an opinion on the incident.
Operational Responder – Primarily focused on the operations team side, may include network operations, server administrators, or other roles in the organization.
Business Partner – When working with personal data on endpoints, some organizations require HR interaction or knowledge of what is happening.
Executive Leadership – On larger incidents that often turn into data breaches, executives in the organization often become painfully aware of the process and information at risk, and must be notified.
5) What are the “plays”?
Define the most common incident plays or run books within the organization as strong and tight processes. Tightly couple the processes to the knowledge base to further expand efficiencies, and create an effective response requiring less team inputs, and generating historical and statistical data about the incidents to track costs associated with incidents. Have a post mortem or lessons learned process (more on this in another post) to improve your run books over time.
6) What are my data sources?
Understand the underlying technology and incident data sources. Create an integration with a SIEM to all tools to correlate data, assure there’s a process in place to keep IDS/IPS signatures updated, and maintain the health of proactive security technologies to assure they are operating at full effectiveness.
7) What do I do about the cloud?
With the explosive rate of cloud enabled services, many organizations have begun to see issues with cloud service providers. Make sure there are provisions in contracts with service providers to obtain sensitive information. Many organizations move to cloud hosted applications or services, but have no visibility into the audit logs, or activities that occur on those platforms. While big service providers, such as Google, provide APIs and light reporting engines to view the data, most require a ticket or request to get to the information, and some don’t maintain or will not share the audit data. Make sure you have a mechanism to collect and/or obtain audit log information from cloud services when you sign up for them.
Incident response preparation is challenging, many organizations spend time planning, but never encounter a large data breach, but every organization will encounter malicious software, phishing, or some kind of unwanted access attempts. Having the tools in place to create efficiencies on the low hanging fruit can help an organization understand its risk and prevent future attacks by quickly responding.