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.

1) Have a computer Security Incident Response plan in place before you need it.

The plan includes roles, responsibilities, and stakeholders; addresses compliance with key industry mandates; and addresses key attacks that may disrupt business.

2) Assess current Incident Response competencies.

Identify gaps and take pro-active steps to enhance capabilities.

3) Get full management and executive leadership buy-in on the Incident Response Plan.

Incident Response should reflect information security risk assessments and this should be an extension of the corporate risk assessment.

4) thru 9) Tips Representing Security Best Practices

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.

10) Apply threat intelligence to enhance Incident Response.

Attackers rarely limit their targets. This is an important step in raising preparedness.

Coordinated Response

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.

“CSO talked to industry experts at Black Hat about the ups and downs of Incident Response, and how to develop a plan that’s right for you.”

Steve Ragan, reporting from the Black Hat Conference, published this good article in CSO Online:

Understanding incident response: 5 tips to make IR work for you.

“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.

Know your data.

Understand the types of data on your network, where it lives, and its value. Map all the ways this data can be accessed.

Document plans for various scenarios.

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).

Establish a base of operations.

A command center of sorts, even a conference room, makes it easier to coordinate the incident response activity.

Nominate a single point of contact.

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.

Update and maintain your plan.

Keep information current. Reflect changes to the network, to the data, to the workforce. This should be done at least yearly.

Related Articles

• Forrester – 7 Steps for building an effective incident response program.

Coordinated Response

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 – Damage Potential, Reproducibility, Exploitability, Affected Users, and Discoverability – is used to quantify risk, but it may prove useful for incident impact assessment.

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.

Threat Probabilities:

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).

Threat Impacts:

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).

Risk Measure:

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.

Incident Response and Risk Assessment

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.

(1) Be self-aware.

Know your capabilities and constraints. Avoid overestimating your abilities. An outside perspective may provide clarity.

(2) Technology – understand its benefits and limitations.

Technology spending outweighs investments in incident response programs, but technology does not equal a solution.

(3) Establish realistic reporting metrics.

Time-to-detect, time-to-contain, and time-to-re-mediate are good results-oriented metrics. Think of others. Consider trending and its implications.

(4) Make the program scalable.

Larger organizations have larger challenges addressing incident response. Consider a contingency team as well as internal and external specialists.

(5) Collaborate internally and externally.

Incident response teams should not work in isolation. Involve your vendors and suppliers.

(6) Engage executives.

Align security programs, including incident response, with the business value chain. Connecting the response plan to an enterprise risk assessment is key.

(7) Operate with autonomy.

To avoid micro-management, establish rules of engagement that identify the need for approval balanced against the need to act.

Coordinated Response

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.

Dark Readings identifies 3 Big Mistakes in Incident Response, May 13, 2013.

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:

1. Assuming It’s an APT; don’t confuse expectations with facts.
2. Not Monitoring Traffic; beyond detection, supports investigation.
3. Focusing Only on the Malware; eradication is important, but so investigation.

Assuming It’s an APT

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.

Not Monitoring Traffic

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.

Focusing Only on the Malware

Containment and eradication are important, but determining outcomes – data theft, sabotage, other long-term damage – may be more important.

Avoid Tunnel Vision

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

Coordinated Response can help to broaden your view and t0 improve your incident response plan.

Align your Incident Response plan with your information security risk assessment.

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.

Risk Assessment – Incident Response – Impact Assessment

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?

Impact Areas

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.

Impact Levels

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.

An Incident Response Plan Review

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.

Last week President Obama issued an Executive Order on Improving Critical Infrastructure Cybersecurity and a Presidential Policy Directive — Critical Infrastructure Security and Resilience (PPD 21). Unfortunately, these are a watered down rehash of the previous administrations’ proposals. Without legislation, these are directives to the executive branch and mere suggestions to industry.

What I found interesting was the report, Raising the Bar on Cybersecurity, released by the Center for Strategic and International Studies. The report identified risk reduction measures that reduced the risk from attacks by 85%:

• Whitelisting – only allowing authorized software to run on a computer.
• Very rapid patching for operating systems and programs.
• Limiting administrative privileges to a minimal number of users.

I agree. These measures are effective.  If these controls had been in place at Department of Energy, they may have prevented the intrusion and subsequent loss of data. But, first I would add two additional controls to this list:

• Eliminate outdated hardware and software.
• Perform annual attack & penetration (A&P) testing.

But, there are challenges.

Whitelisting is time consuming and can be difficult to implement. You need locked-down desktops, standards for server builds, and network configuration profiles already in place. Otherwise, whitelisting may be circumvented, especially by determined outside attackers and disgruntled internal users.

Patching is always a good thing, but testing is required before any patch should be applied. This is particularly challenging for industrial control systems associated with critical infrastructure.

Reducing administrative privileges is a good idea that is noted in most InfoSec improvement programs. It is one of the first thing covered by a security auditor’s review. A tool like Unix’s sudo is a good way to assign specific privileges to specific users.  Versions of, or equivalents to, sudo are available for other operating systems

Often outdated software or hardware is the source of vulnerabilities as patches and updates are no longer provided. Unfortunately, some entities do not have the resources to eliminate old software and hardware so they must identify alternate means to provide adequate security.

Finally, annual A&P testing may be expensive, but for organizations at risk  — especially for loss of intellectual property, exposure of personally identifiable information (PII) or at risk of taking a hit to corporate reputation – the expense is well justified.  A&P testing performed by qualified third-parties is a “no-harm, no-foul” way of ensuring networks and systems are properly protected and will show that a modicum of due diligence has been performed which may help forestall or lessen the impact of a law suit following a breach.

So, why doesn’t every organization jump on the A&P testing bandwagon?  Well, in addition to the expense side of the equation, some IT directors are reticent to employ A&P testing because of the risk of exposing poor network design and/or configuration errors to executives or the board of directors.  These folks, however, should be thinking of how they can protect their shareholders’ interests and not their careers.

Implementing these five processes will not only raise the bar with respect to protecting organizational assets, but will also reduce the efforts required to maintain an efficient and effective IT environment.