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
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, no, no! Have a Unix CRON do the pop-up reminders!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.