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.

Risk

1/30/2017
10:30 AM
Daniel Gordon
Daniel Gordon
Commentary
100%
0%

Why Youre Doing Cybersecurity Risk Measurement Wrong

Measuring risk isn't as simple as some make it out to be, but there are best practices to help you embrace the complexity in a productive way. Here are five.

Broadly speaking, cybersecurity is risk identification and risk mitigation in the cyber domain.  Measuring risk quantitatively is good because it helps security teams measure their capabilities somewhat objectively, which helps everyone make better decisions. For example, when deciding whether to upgrade all your firewalls or invest in organization-wide two-factor authentication, that decision should be based, in part, on what risk exists now and what risk will be after you implement a change. It may surprise you but people are generally pretty bad at this, resulting in things like transportation disasters, major breaches, economic bubbles, wars, and bad movies. 

In the book How to Measure Anything in Cybersecurity Risk by Hubbard & Seiersen, the method for evaluating risk is, and I’m paraphrasing, identifying likelihood using modeling principles, and impact using cost estimation and the CIA (Confidentiality, Integrity and Availability) model. 

Here’s where it gets more complicated: evaluating current and future risk requires accounting for people … and people make everything harder. A good risk analysis should account for risky behaviors by users, administrators, and security personnel, both before and after you make the change. 

There is a bunch of research that shows that when you tell people about safety features, they change their behavior to be more risky. Examples include risk for traffic safety, child-proofed medicine bottles, bicycle helmet use, and mobile phone use while driving. They do it for convenience, out of boredom, and other bad reasons. Here are some hypothetical examples in cybersecurity:

Table 1: Examples of Risk Compensation in Infosec
 Risk   Risk-Mitigating Security Control   Risk Compensation 
Malware in email attachments infecting desktops Purchase and installation of a sandbox appliance Users open attachments and enable macros without concern for malware
SQL injection attack on externally-facing server Implement input validation on the server Security administrators ignore alerts of SQL injection attempts on server
Malware on USB drives infecting desktops Disable autorun settings in Windows to prevent immediate execution Users and administrators do not adhere to policies on scanning or avoiding USB drives from external sources

There’s another group of people who alter their behavior when you implement a risk mitigation - and they’re even tougher to account for. Who is it? No, it’s not furries. It’s miscreants. (OK, they might also be furries.) Risk mitigation should account for how attackers will evolve. If you’re facing a persistent threat with a lot of resources, and one attack is unsuccessful, you should anticipate that the persistent threat will evolve their TTP (Techniques, Tactics and Protocols). If you attempted to mitigate the risk of banking trojans served by botnets but failed to account for the evolution to ransomware, your risk model was probably faulty. 

Getting Risk Management Right: Five Recommendations

1. Gather threat intelligence and data about the behavior of your users.  Threat intelligence should be a description of a series of attacks that can help you understand and predict future attacks. Data could include behavior analytics from logs but might also be information based on defining groups of users and interviewing them to see how they operate.

2. Do not reveal to miscreants how they were detected if you can help it.  If miscreants don’t know that a risk mitigation exists, they will not be able to react to it. If you block/detect them, try to hide your capabilities. For insider threats, the decision on what to communicate may already be determined by your legal department or HR.

3. Be deliberate in how you publicize risk mitigations in your organization. While hiding a risk mitigation in your organization would prevent a change in behavior, it might be unethical or prevent you from getting credit for your work. A better solution is to emphasize to users and decision-makers what risks still exist to help them make informed decisions that reduce risky behaviors.

4. Be deliberate in how you share information externally.  Risk mitigations implemented by other organizations may also change the behavior of miscreants. If you’re selective with whom you share data, or share along with guidance on how it should be handled, there’s less of a chance of others being careless, and causing unexpected miscreant behavior changes. If you share publicly, account for uncertainty created by a likely change in attacker TTP.

5. Don’t spread FUD.  FUD (Fear, Uncertainty and Doubt) is incorrect data that causes improper risk or uncertainty measurement. Some people spread FUD because of sloppy work, some do it unintentionally, and some do it deliberately for business reasons. It’s bad for the cybersecurity community/industry as a whole, it’s bad for decision makers, and it’s counterproductive in the long run.

Related Content:

 

Daniel Gordon, CISSP, is a member of the Lockheed Martin Computer Incident Response Team. He has worked in IT and information security for over 10 years. He holds a BA in political science from St Mary's College of Maryland and a graduate certificate in modeling and ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Look Beyond the 'Big 5' in Cyberattacks
Robert Lemos, Contributing Writer,  11/25/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: We are really excited about our new two tone authentication system!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4126
PUBLISHED: 2020-12-01
HCL iNotes is susceptible to a sensitive cookie exposure vulnerability. This can allow an unauthenticated remote attacker to capture the cookie by intercepting its transmission within an http session. Fixes are available in HCL Domino and iNotes versions 10.0.1 FP6 and 11.0.1 FP2 and later.
CVE-2020-4129
PUBLISHED: 2020-12-01
HCL Domino is susceptible to a lockout policy bypass vulnerability in the LDAP service. An unauthenticated attacker could use this vulnerability to mount a brute force attack against the LDAP service. Fixes are available in HCL Domino versions 9.0.1 FP10 IF6, 10.0.1 FP6 and 11.0.1 FP1 and later.
CVE-2020-9115
PUBLISHED: 2020-12-01
ManageOne versions 6.5.1.1.B010, 6.5.1.1.B020, 6.5.1.1.B030, 6.5.1.1.B040, ,6.5.1.1.B050, 8.0.0 and 8.0.1 have a command injection vulnerability. An attacker with high privileges may exploit this vulnerability through some operations on the plug-in component. Due to insufficient input validation of ...
CVE-2020-9116
PUBLISHED: 2020-12-01
Huawei FusionCompute versions 6.5.1 and 8.0.0 have a command injection vulnerability. An authenticated, remote attacker can craft specific request to exploit this vulnerability. Due to insufficient verification, this could be exploited to cause the attackers to obtain higher privilege.
CVE-2020-14193
PUBLISHED: 2020-11-30
Affected versions of Automation for Jira - Server allowed remote attackers to read and render files as mustache templates in files inside the WEB-INF/classes & <jira-installation>/jira/bin directories via a template injection vulnerability in Jira smart values using mustache partials. The ...