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.
11/3/2014
01:50 PM
Carric Dooley
Carric Dooley
Partner Perspectives
Connect Directly
Twitter
RSS
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
CarricDooley
50%
50%
CarricDooley,
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.

 

RetiredUser
0%
100%
RetiredUser,
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?  
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-3154
PUBLISHED: 2020-01-27
CRLF injection vulnerability in Zend\Mail (Zend_Mail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
CVE-2019-17190
PUBLISHED: 2020-01-27
A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the...
CVE-2014-8161
PUBLISHED: 2020-01-27
PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.
CVE-2014-9481
PUBLISHED: 2020-01-27
The Scribunto extension for MediaWiki allows remote attackers to obtain the rollback token and possibly other sensitive information via a crafted module, related to unstripping special page HTML.
CVE-2015-0241
PUBLISHED: 2020-01-27
The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric ...