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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
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
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment:   It's a PEN test of our cloud security.
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
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7245
PUBLISHED: 2020-01-23
Incorrect username validation in the registration processes of CTFd through 2.2.2 allows a remote attacker to take over an arbitrary account after initiating a password reset. This is related to register() and reset_password() in auth.py. To exploit the vulnerability, one must register with a userna...
CVE-2019-14885
PUBLISHED: 2020-01-23
A flaw was found in the JBoss EAP Vault system in all versions before 7.2.6.GA. Confidential information of the system property's security attribute value is revealed in the JBoss EAP log file when executing a JBoss CLI 'reload' command. This flaw can lead to the exposure of confidential information...
CVE-2019-17570
PUBLISHED: 2020-01-23
An untrusted deserialization was found in the org.apache.xmlrpc.parser.XmlRpcResponseParser:addResult method of Apache XML-RPC (aka ws-xmlrpc) library. A malicious XML-RPC server could target a XML-RPC client causing it to execute arbitrary code. Apache XML-RPC is no longer maintained and this issue...
CVE-2020-6007
PUBLISHED: 2020-01-23
Philips Hue Bridge model 2.X prior to and including version 1935144020 contains a Heap-based Buffer Overflow when handling a long ZCL string during the commissioning phase, resulting in a remote code execution.
CVE-2012-4606
PUBLISHED: 2020-01-23
Citrix XenServer 4.1, 6.0, 5.6 SP2, 5.6 Feature Pack 1, 5.6 Common Criteria, 5.6, 5.5, 5.0, and 5.0 Update 3 contains a Local Privilege Escalation Vulnerability which could allow local users with access to a guest operating system to gain elevated privileges.