Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
01:50 PM
Carric Dooley
Carric Dooley
Partner Perspectives
Connect Directly

Drag Your Adolescent Incident-Response Program Into Adulthood

It's not about how many tools you have, but what you can do with them.

We are often the incident response (IR) team called in to put out the fire after the security breaches you see on the news, seemingly every week. We see the facts, flaws, and foibles of these crises, and afterward we help the organization pick up the pieces and assemble a better approach to prevent a next-time. We usually find that fundamentals have been missed. Although the virtual front door was padlocked with an ornate authentication system, the attacker hopped in a virtual back window by stealing legitimate credentials from an insecure application with a basic flaw. Or one phish got away from the anti-spam filter. Or an unmanaged asset missed a patch.

As you watch the dramas unfold, are you wondering how good your own incident response plan is? Are you taking comfort in the range of security technologies you have installed? Are you reassuring yourself and your peers that your organization would not commit the same fundamental errors that seem to be at the root of most of these breaches? But how can you be sure?

Many of the organizations we meet with have IR plans, often expensively developed by third-party consultants. The plans are usually evaluated against theoretical scenarios but not rehearsed and real-world tested. In addition, these companies frequently have an overabundance of security technology but fail to recognize and address the root causes of their vulnerabilities and breaches. In the absence of solid metrics to measure the results of their efforts, it can be difficult to justify the investments required for their security needs, leaving some aspects of the security program underdeveloped because of lack of budget approval.

One of the IR evaluation tools we have been using with customers is a variation on the capability-maturity model concept, which dates back to the 1970s. Maturity does not refer to the age of the model, but to the level of formality and optimization of the procedures. A security architecture or framework can be prescriptive in what processes and technologies you need, but too generic to be a perfect fit for anyone.

A maturity model, instead, defines three or four levels of increasing capabilities and metrics, across different areas of responsibility. In enterprise security, for example, you might call the levels reactive (Level 0), compliant, proactive, and optimized (Level 3), covering areas such as metrics, user awareness, infrastructure, applications, incident response, and strategy.

Using a model like the one above, you evaluate your maturity level in each area and identify the processes and technologies you need to adjust or invest in to get you to the level that matches your organization’s specific acceptable level of risk.

Let’s look at the recent BASH bug discovery, which is a vulnerability in a widely deployed Unix command-line shell. The response to this incident required identifying all of the vulnerable devices, ranking them by level of exposure, getting the appropriate patches, and applying the patches. 

A reactive security group has an ad hoc approach to this. Upon getting the updated threat intelligence (possibly from a general news report), the group works to assemble a team, search for potentially vulnerable systems throughout their network, identify the owners, and then painstakingly assess the software version levels of each, upgrading and patching as they can. However, this leaves the company at risk if they don’t find all of the vulnerable systems.

A compliant security group has an annual asset list to start from, but the list needs to be updated and does not contain sufficient details on the configurations to positively classify the exposure level. So, this group is also going system by system to evaluate and patch and faces the risk of not finding every vulnerable system.

A proactive security group has an asset list that is updated quarterly, with configuration management for each machine. This client is starting to engage in actual risk management. The proactive company would likely miss far fewer systems, and prioritizes its efforts on critical systems first. The IR team quickly ranks the systems by exposure level, remotely patching those they can and scheduling the rest for manual updates.

An optimized security group may be barely affected by the threat. It has current asset information and live vulnerability scanning. Its patch management system updates the most exposed systems as the security patches become available, while the environment is protected by defense-in-depth countermeasures. The IR team is able to continue with its normal work processes of dealing with incidents.

When we begin the conversation about maturity, most companies are unaware of their posture and are often surprised by the assessment results. We’d say the bulk of companies get at best a C grade, with only the exceptional passing with a few A’s in specific areas. C is for Compliant, which is not sufficient for security these days. Companies with high-sensitivity or regulated data should aim to be at least proactive, with a stretch goal of optimized within two to three years.

Carric Dooley has extensive experience leading comprehensive security assessments as well as network and application penetration tests in a wide range of industries across North America, Europe, and Asia. As the Worldwide VP of Foundstone Services at McAfee, part of Intel ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
11/12/2014 | 4:25:47 PM
Re: Deliverables and Checklists vs Actual Living Functions

Mr. Bryant

I'd first like to establish what we are talking about in terms of maturity, audit vs assessment, etc. 

The intent of how we understand a client's maturity is NOT what we would call an audit.  That implies there is a checklist, and then you could pass or fail. An audit also implies the behavior you site of "managing to the audit" versus "becoming more secure" (like the grade inflation we have experienced in US schools).  We are suggesting an assessment(s) of current state against a backdrop of maturity and capability (take another look at the table). 

Maturity is loosely tied to CMMI in a sense that it has been an industry-accepted term/framework for some time.  It is intuitive to think about current state of security maturity and capability in terms of "reactive, compliant, proactive, optimizing", but you could really use any version of this to achieve what we are suggesting.  I have seen other maturity models that reference levels of capability versus state (i.e. No capability, Some capability, etc.).  We are NOT suggesting a CMMI "roll out".

I've expanded on some of these concepts in my recent Dark Reading for Intel Security Perspectives blog - please read "What We Mean by Maturity Models for Security" for additional clarity.


User Rank: Ninja
11/3/2014 | 11:01:28 PM
Deliverables and Checklists vs Actual Living Functions
I appreciate mature models, well-designed processes and formal standards; I swear, I really do.  But after being a part of attempt after attempt at CMMI rollout, eyes on the Level X prize, I kept seeing the same thing happen:  Passing the audit became the deliverable and thus artifacts emerged to satisfy the audits up to a point, then the Level X goal slowly disappeared.  I appreciate Common Criteria and its EALs (Evaluation Assurance Levels) but I've seen via hearsay similar things happen to CC, too - you can only produce artifacts up to a point before you have to have a well-oiled process with demonstrable benefits.

Now, downer attitude aside, there is Agile and Lean.  By no means am I a process-oriented thinker (not that I didn't try).  I believe in taking your skill-set and diving head-first into chaos, greeting it with a combat mentality, and keeping things fresh by changing the game completely the next go-round.  But if there must be maturity and formality to security risk assessment, analysis and continuous lifecycle improvement, maybe there's a middle ground that the businessmen, architects and hackers can meet on.  What you've described here is great and a noble goal, but what would it look like trimmed a tad, and modeled for both hacker and process-geek alike?  
10 Ways to Keep a Rogue RasPi From Wrecking Your Network
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/10/2019
The Security of Cloud Applications
Hillel Solow, CTO and Co-founder, Protego,  7/11/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-07-16
An issue was discovered in python-engineio through 3.8.2. There is a Cross-Site WebSocket Hijacking (CSWSH) vulnerability that allows attackers to make WebSocket connections to a server by using a victim's credentials, because the Origin header is not restricted.
PUBLISHED: 2019-07-15
A Reflected Cross-site Scripting (XSS) vulnerability exists in Apache Roller. Roller's Math Comment Authenticator did not property sanitize user input and could be exploited to perform Reflected Cross Site Scripting (XSS). The mitigation for this vulnerability is to upgrade to the latest version of ...
PUBLISHED: 2019-07-15
A CWE-119 Buffer Errors vulnerability exists in Modicon M580 CPU - BMEP582040, all versions before V2.90, and Modicon Ethernet Module BMENOC0301, all versions before V2.16, which could cause denial of service on the FTP service of the controller or the Ethernet BMENOC module when it receives a FTP C...
PUBLISHED: 2019-07-15
A Use After Free: CWE-416 vulnerability exists in Zelio Soft 2, V5.2 and earlier, which could cause remote code execution when opening a specially crafted Zelio Soft 2 project file.
PUBLISHED: 2019-07-15
A CWE-94: Code Injection vulnerability exists in ProClima (all versions prior to version 8.0.0) which could allow an unauthenticated, remote attacker to execute arbitrary code on the targeted system in all versions of ProClima prior to version 8.0.0.