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?  
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5974
PUBLISHED: 2020-07-08
NVIDIA JetPack SDK, version 4.2 and 4.3, contains a vulnerability in its installation scripts in which permissions are incorrectly set on certain directories, which can lead to escalation of privileges.
CVE-2020-15072
PUBLISHED: 2020-07-08
An issue was discovered in phpList through 3.5.4. An error-based SQL Injection vulnerability exists via the Import Administrators section.
CVE-2020-15073
PUBLISHED: 2020-07-08
An issue was discovered in phpList through 3.5.4. An XSS vulnerability occurs within the Import Administrators section via upload of an edited text document. This also affects the Subscriber Lists section.
CVE-2020-2034
PUBLISHED: 2020-07-08
An OS Command Injection vulnerability in the PAN-OS GlobalProtect portal allows an unauthenticated network based attacker to execute arbitrary OS commands with root privileges. An attacker requires some knowledge of the firewall to exploit this issue. This issue can not be exploited if GlobalProtect...
CVE-2019-19415
PUBLISHED: 2020-07-08
The SIP module of some Huawei products have a denial of service (DoS) vulnerability. A remote attacker could exploit these three vulnerabilities by sending the specially crafted messages to the affected device. Due to the insufficient verification of the packets, successful exploit could allow the a...