Dell SecureWorks – 10 Tips to Help You Minimize the Duration and Impact of a Security Breach.
The message from Dell SecureWorks re-enforces the message from other security resources, but the presentation available on BitPipe provides additional insight. The tips start and end with Incident Response.
The plan includes roles, responsibilities, and stakeholders; addresses compliance with key industry mandates; and addresses key attacks that may disrupt business.
Identify gaps and take pro-active steps to enhance capabilities.
Incident Response should reflect information security risk assessments and this should be an extension of the corporate risk assessment.
The additional tips include cybersecurity best practices: (4) assess user privileges and accounts; (5) collect and analyze log data; (6) control traffic flows; (7) monitor network activity; (8) perform filtering for web and email; and (9) monitor DNS activity.
Attackers rarely limit their targets. This is an important step in raising preparedness.
Coordinated Response can help (1) develop an Incident Response Plan, (2) perform an incident response capabilities assessment, and (3) develop the risk assessment to support executive buy-in. Please contact us if we can be of help.
Steve Ragan, reporting from the Black Hat Conference, published this good article in CSO Online:
“Incident response is a plan that evolves over time to keep your organization best prepared against likely threats.” The article is worth reading. The reflections and quotes provide the real insight, but the five tips drive home the message.
Understand the types of data on your network, where it lives, and its value. Map all the ways this data can be accessed.
Not every incident is about a hacker. Plan for internal events, as well. Address incidents stemming from lost or stolen assets and malicious actors from within (including when an outsider compromises an insider’s access).
A command center of sorts, even a conference room, makes it easier to coordinate the incident response activity.
Make sure they have access to the right individuals. Know when to involve Public Relations and Legal. This is what Coordinated Response calls the extended response.
Keep information current. Reflect changes to the network, to the data, to the workforce. This should be done at least yearly.
Coordinated Response can help map your data and your value chain in to a meaningful risk/impact assessment model. We can help you develop or refresh your existing plan. We can help build out your plan for various scenarios. If you are interested, please contact us.
DREAD is a classification scheme for quantifying, comparing, and prioritizing the amount of risk represented by a specific threat. The DREAD scheme is described in Writing Secure Code, 2nd Edition, Howard, M. and LeBlanc, D. Microsoft Press 2003 and is used by Microsoft. DREAD is also promoted by the Open Web Application Security Project (OWASP) on their site: Threat Risk Modeling.
In the diagram above and in the definitions below, the “D”s are reordered to group the elements of DREAD into logical categories: Probabilities and Impacts.
How easy is it to (1) Discover a vulnerability, (2) Exploit a vulnerability, and (3) Reproduce the Exploit? In DREAD these are rated on a scale of 0 (very hard or impossible) to 10 (easy with limited tools or skills).
Affected Users are measured from 0 (none) to 5 (Some users, but not all) to 10 (all users). Damage Potential is measured from 0 (no damage from exploit) to 5 (individual user data is compromised) or 10 (complete system or data destruction or compromise).
Add the 5 metrics and divide by 5. The result is a scale of 0 (not likely with limited impact) to 10 (highly likely with serious impact). Obviously, higher risk requires additional mitigation or avoidance might be required.
It’s worth stressing that the impact component of the risk assessment can and should be used during the Incident Impact Assessment. The Response Team needs to know how many users are affected, how much data or how many systems have been compromised, destroyed or disabled.
With this information the response team makes informed decisions on what resources to apply and what actions to take.
In an Incident postmortem review, the questions about the vulnerability should be reviewed: discoverability, reproducibility, and exploitability (again).
Forrester Senior Analyst Rick Holland identifies the keys to an effective incident response program.
This article, available through TechTarget, is a good tool for communicating with your executive team.
The article references an interesting point. According to the Forrester Forrsights Security Survey, after a breach has occurred, 25% of organizations increase spending on breach prevention technologies, while 23% increase spending on the incident response program itself.
Know your capabilities and constraints. Avoid overestimating your abilities. An outside perspective may provide clarity.
Technology spending outweighs investments in incident response programs, but technology does not equal a solution.
Time-to-detect, time-to-contain, and time-to-re-mediate are good results-oriented metrics. Think of others. Consider trending and its implications.
Larger organizations have larger challenges addressing incident response. Consider a contingency team as well as internal and external specialists.
Incident response teams should not work in isolation. Involve your vendors and suppliers.
Align security programs, including incident response, with the business value chain. Connecting the response plan to an enterprise risk assessment is key.
To avoid micro-management, establish rules of engagement that identify the need for approval balanced against the need to act.
This article provides a good set of principles to apply as you build or enhance your incident response program.
Let us help you with a response plan review that applies and expands on the ideas presented by Forrester.
Revision 1 provided a complex measure for incident impact assessment that might provide insight in hindsight, but one that was not practical, applicable, or useful in the midst of an incident response. The new measures, suggested in the table above, are really quite useful, applicable, and discernible. There are 3 important impact areas with associated metrics:
This measures loss of system functionality. NONE – No loss of functionality. LOW – no loss of functionality, but loss of efficiency. MEDIUM – Critical services lost to a subset of users. HIGH – Critical services lost to all users.
Here NIST stops short of measuring impact – so the above diagram is not colored for this Impact Area except in the case of NONE – no information was exfiltrated, modified, or deleted. An impact measure is needed for each of the three information impact areas. PRIVACY BREACH – personally identifiable information was compromised. PROPRIETARY BREACH – unclassified proprietary data was compromised. INTEGRITY LOSS – sensitive or proprietary information was changed or deleted. A level of impact measure is needed in each of these areas. The loss of a single document or individual’s data is low, but what defines medium or high?
This is an interesting and useful metric: Is the data/system recoverable? If so, what is the level of recovery effort? NOT RECOVERABLE – the data or system cannot be recovered. REGULAR – time-to-recover is predicable with existing resources. SUPPLEMENTED – time-to-recover is predictable, but with additional resources. EXTENDED – time-to-recover is unpredictable and additional resources including outside help are needed.
This new approach agrees with the Coordinated Response Impact Assessment in the Response Management Framework. The table below shows the 5 possible impact areas with associated impact metrics.
Coordinated Response can help you review and improve your Incident Response Plan.
By recognizing and avoiding these common mistakes, Kelly Jackson Higgins provides a quick set of best practices backed by interviews with security experts. The article should be in every Response Teams must-read library. A response plan should identify the practices to avoid these mistakes:
Not all attacks start with an Advanced Persistent Threat. Apply an objective lens to the data. Look for a 2 stage attack: (1) Phishing, (2) Command and Control.
The article makes a good point. Monitoring is not just for protection and detection. When a breach or intrusion is discovered, audit records provide clues as to what happened, when, and what may be ex-filtrated. Not monitoring, even insufficient monitoring increases potential impact.
Containment and eradication are important, but determining outcomes – data theft, sabotage, other long-term damage – may be more important.
This was not called out as a 4th mistake, but the article led with an example of a team that was focused on the malware and missed a shift to control of an administrative tool. The admonition to “avoid tunnel vision” applies more broadly than just “focusing on malware”.
The example also identified a good practice. An outside firm reviewed the outcome of the incident and discovered the control shift – the true intent of the attack.
Coordinated Response can help to broaden your view and t0 improve your incident response plan.
An effective risk assessment, regardless of the technique employed, identifies impact areas and potential impact levels. Then, given the probabilities an attack, risk strategies are defined: avoid the risk; mitigate the risk; share the risk; accept remaining risk.
Ultimately, unless you choose to avoid the risk, some residual risk is accepted. Then, when an unlikely incident occurs, an incident response plan is the last line of defense.
The key to an effective impact assessment rests with two key questions:
• What areas of your business are at risk when an incident occurs?
• How do you measure the impact?
These two questions are first asked during the risk assessment – the theoretical question: what if? When an incident occurs, they are asked again, only it is no longer in theory. What areas of your business are affected? To what level?
While most organizations evaluate the financial impact, the majority view reputational impact as the more important. Other areas to measure include operational impact and legal impact. If your organization is regulated, you might measure legal impact, policy impact, and regulatory impact as separate areas.
For each impact area, it is important to provide metrics or descriptions that differentiate the impact level. Low, medium, and high are not enough as impact measures. Without metrics different people assign different meanings to the terms low, medium, and high.
It’s worth stressing that the impact component of the risk assessment can and should be used during the Incident Impact Assessment. The Response Team measures adverse impact to determine the needed response.
With this information the response team makes informed decisions on what resources to apply and what actions to take. Refer to our Response Management Framework for added insight.
Let us help you with a response plan review that considers your information security risk assessment.
Most SIEM vendors from HP and IBM to LogRythm and LogLogics offer tools that support incident response, but in the words of one research organization the response is IT-focused and tightly coupled to the SIEM. The enterprise is not involved. Artifacts are limited to SIEM records. Incidents derived from outside the SIEM – help desk tickets, third party alerts, etc. – are not tracked at all.
There is a need to manage incidents at an enterprise-level. In addition to IT, there is involvement and support from:
SIEM vendors provide no interface supporting these enterprise actors. The researchers suggest connecting with an enterprise process automation platform, for example, Microsoft (TM) SharePoint, a platform that provides:
Coordinated Response embraces the SIEM response capability, but extends it to the Enterprise level.
The guide puts incident handling activities in the context of the above diagram. The table below provides the first level of detail.
|Preparation||Detection & Analysis||Containment, Eradication, & Recovery||Post-Incident Activity|
The above activities represent a useful checklist for evaluating an incident response plan as well as incident handling in action.
Of course, recognize that the response to an incident is fluid, often with unclear boundaries. Containment may start in the early stages of analysis. Prioritization may change and notification may continue throughout the incident. But, the insight provided by the NIST publication goes beyond Federal agencies.
I attended the CSO Perspectives event in Alexandria, Virginia on March 21st. This event was produced by CSO Magazine and CSO Online. Publisher Bob Bragdon was the host and moderator. During the course of the day, there was an extensive discussion of the Federal Government’s role in Cybersecurity.
Over lunch, with Bob and a number of others, I suggested we need a federated approach to cybersecurity.
Consider highway safety for a moment and all the factors that make it safe to drive:
This federated approach to safety and security is needed on the information highway (now there is a dated term). We expect hardware and software manufacturers to build safer products. But, we need to be trained to use them properly and not to turn off safety features or, in some cases, we need to be trained to turn them on. The network service providers and internet service providers need to build safer “highways”. We still need government regulations and enforcement.
How do we protect against malicious drivers? This is a metaphor worth exploring.