Perimeter

8/19/2015
11:45 AM
Mark Clancy
Mark Clancy
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Applying the 80/20 Rule to Cyber Security Practices

How to look holistically across technology and processes and focus resources on threats that create the greatest damage.

The 80/20 rule, or the “Pareto Principle,” states that approximately 80% of effects come from 20% of causes, reinforcing a very powerful point that distributions are rarely equal. In sales, for example, 20% of clients often represent 80% of a firm’s revenues while in the field of software development, a relatively small number of the most-reported bug fixes are likely to create solutions for the overwhelming majority of problems.

For corporate information security officers and others on the front lines in the fight against cybercrime, the key takeaway is that not all threats create the same level of risk and that resources need to be prioritized to fighting those attacks that could do the most damage to your firm or industry.  

Unfortunately, we continue to see too many instances where firms take a one-size-fits-all approach to their cyber defenses, focusing too many resources on lower-level risks, such as wide-scale malware campaigns, and not enough on the most destructive attacks or targeted probing by capable adversaries. In today’s rapidly changing cyber landscape, with threat actors growing in sophistication each and every day, this must change.

As a first step, firms need to assess their end-to-end incident response processes, with an investigation of the discovery, analysis, mitigation and closure phases, and how resources are spent in each area. Typically, firms find significant financial resource drains in many of these areas, which oftentimes can be automated and improved though technology and procedural changes. It is only when firms identify where they spend the most time that they can bring the incident response cycle down and free up resources to target on the most critical issues.

Looking at discovery, this is the phase where firms become aware of an issue. When speaking of a lower risk incident such as non-targeted phishing, many firms manually monitor inbound emails one by one, yet there are solutions to automate the entire inbound email process. Ideally, firms can shorten this discovery phase by building automation that can systematically digest inbound traffic, extract all links and identify issues company wide – promptly alerting security teams to specific threats and machine issues, enabling faster incident detection.

Next is the analysis phase. Security orchestration tools can automatically create help desk tickets, categorizing security event inflows and organizing the entire incident. This is also an area where firms are starting to leverage collaborative industry utilities that share threat information and remediation tactics across institutions and industries in order to speed up incident analysis and resolve issues. 

The call for cyber threat data sharing has been echoed by market participants, regulators and infrastructure providers alike, as firms are increasingly looking to collaborate to prevent and respond to attacks more quickly. Most recently, the US House and Senate took proactive steps to confront the cyber security challenge and are working towards enactment of legislation to improve information sharing to protect critical infrastructure. Collaborative cyber security threat information tools will not only enable firms to identify incidents more quickly, but at their best, should also empower them to either proactively prevent issues or mitigate them quickly.

When it comes to closure, sharing and learning are essential.  Following a plane crash, for example, there is a deep forensic analysis of what happened and discussion around how the aviation industry can prevent a similar occurrence. While this sounds straightforward, it currently does not happen with cybersecurity incidents today. Often firms keep incidents close to their vests out of fear of public disclosure, which has the effect of leaving other firms more vulnerable to that same attack.  We must shift away from this protective thinking to encourage firms to anonymously share details on cyber security incidents using new technologies and solutions. As more firms join in this dialogue, the process of detection and mitigation will become more efficient and the balance of power will shift away from the criminals.

Finally, we must continue to keep a close watch over the infrastructure, avoiding overly complex IT implementations and lack of investment in upgrades and system maintenance that increase our vulnerability.

While there is no easy solution to winning the war against cyber criminals, the Pareto Principle provides sound guidance on how to tackle this challenge. Foremost, we must look holistically across technology and processes to become more efficient and to focus resources on the threats that could create the greatest damage. In other words, we must shift the effort/risk paradigm to 80% effort on the 20% of the most critical incidents if we are to bend the cost and risk curves to our favor. We still have to cover 100%, but we need to close out the 80% of the noise with 20% of our energy.

Stephen Scharf is chief security officer at The Depository Trust & Clearing Corporation (DTCC). In this role he is responsible for centralizing and aligning the firm's global information security, physical security, employee safety, and crisis/incident management functions, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MichaelMoshiri
100%
0%
MichaelMoshiri,
User Rank: Apprentice
8/24/2015 | 5:01:51 PM
Great insights...
Thank you, Mark, for the great article. The 80/20 rule is a great reminder that 100% security is not only unachievable but unnecessary. Your suggestion to take on a risk-based approach to identifying the 20% where the marjority of our energy should be concentrated is spot-on.

Since your article is mostly focused on incident response, where would you say is the sweet spot for Soltra and Soltra Edge to help enterprises to apply the 80/20 rule to their incident response activities?
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Well, at least it isn't Mobby Dick!
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-9923
PUBLISHED: 2019-03-22
pax_decode_header in sparse.c in GNU Tar before 1.32 had a NULL pointer dereference when parsing certain archives that have malformed extended headers.
CVE-2019-9924
PUBLISHED: 2019-03-22
rbash in Bash before 4.4-beta2 did not prevent the shell user from modifying BASH_CMDS, thus allowing the user to execute any command with the permissions of the shell.
CVE-2019-9925
PUBLISHED: 2019-03-22
S-CMS PHP v1.0 has XSS in 4.edu.php via the S_id parameter.
CVE-2019-9927
PUBLISHED: 2019-03-22
Caret before 2019-02-22 allows Remote Code Execution.
CVE-2019-9936
PUBLISHED: 2019-03-22
In SQLite 3.27.2, running fts5 prefix queries inside a transaction could trigger a heap-based buffer over-read in fts5HashEntrySort in sqlite3.c, which may lead to an information leak. This is related to ext/fts5/fts5_hash.c.