Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
7/27/2017
09:00 AM
Raymond Pompon
Raymond Pompon
Partner Perspectives
Connect Directly
Twitter
RSS
50%
50%

Can Your Risk Assessment Stand Up Under Scrutiny?

Weak risk assessments have gotten a pass up until now, but that may be changing.

The foundation of what we do in InfoSec is all based on risk. How we select controls to reduce the likelihood and impact of threats and vulnerabilities stems from our risk assessments. Every compliance standard mandates one form of risk assessment be done as a part of an organization’s security program. But not all risk assessments are done the same way nor do they produce the same results.

There are many risk assessment standards for organizations to choose from, including OCTAVE, FAIR, ISO 27005:2011, FMEA, and NIST SP 800-30. Some are quantitative, based on real numbers and data with results often expressed in potential dollars lost, while others are qualitative, based on expert opinion and expressed in colors or high-medium-low ratings. Some risk assessments are built from hundreds of hours of observations and measurements. Others are constructed from calibrated opinion surveys of subject matter experts. More than a few risk assessments are presented with incomplete results, merely focusing on threats and vulnerabilities while ignoring impacts or likelihoods.

Until recently, auditors and regulators have mostly graded risk assessments on effort, not effectiveness or completeness. The common audit question is "Did you do a risk assessment?" can be satisfactorily answered with a simple affirmative. In 2015, I presented research at the Society of Information Risk Analysts (SIRA) conference that showed that only 29% of organizations assessing the security of third parties asked if there was a risk assessment process in place. Only 13% wanted to know any details on that process.

Weak risk assessments have gotten a pass up until now, but that may be changing. On April 12, 2017, the FTC issued a warning letter to Abbot Labs for a number of security failings in their medical devices. A key cause that was singled out was poor risk assessment. They noted:

"Your firm identified the hardcoded universal unlock code as a risk control measure for emergent communication. However, you failed to identify this risk control also as a hazard. Therefore, you failed to properly estimate and evaluate the risk associated with the hardcoded universal lock code in the design of your High Voltage devices."

As well as:

"Your firm’s updated Cybersecurity Risk Assessments, (b)(4) Cybersecurity Risk Assessment, (b)(4), Revision A, April 2, 2015 and [email protected] Product Security Risk Assessment, (b)(4), Revision B, May 21, 2014 failed to accurately incorporate the third party report’s findings into its security risk ratings, causing your post-mitigation risk estimations to be acceptable, when, according to the report, several risks were not adequately controlled."

What better way to diagnose a failed security program than to point at an inferior assessment of risk? If an organization omits or misjudges a critical risk, then the decisions that flow from that finding will be incorrect.

A problem with standardizing risk assessment is that the measurement of relevant risk is going to vary significantly from organization to organization, with different priorities, trade-offs, and tolerances affecting the analysis. However, the question remains: can your risk assessment withstand outside scrutiny? If you get unlucky and hacked, how is your organization’s risk assessment going to fare when regulators and lawyers scrutinize it page by page?

Your strategy should be to develop a risk assessment that appears reasonable and appropriate to hazards, threats, and potential impacts on your systems. The FTC came down hard on Abbot Labs because they manufacture medical devices, so impacts can include loss of life and breach of medical privacy. A more thorough risk assessment would be expected in this environment than that of an IT office equipment vendor.

A defensible risk assessment should be:

  • Standardized. The method should be as formal as possible so that given the same data, someone could reproduce the same results. The same method should be used for the same type of risk assessment.
  • Relevant. The right risk modeling technique should be chosen for your organization’s industry, possible impacts, and threat environment. It should also be current—the standard is to perform them at least once a year.
  • Explicit. Assumptions, trade-offs, estimates, and conclusions should be clearly documented. An auditor or regulator should be able to trace your line of reasoning in decisions made.

A risk assessment must also be read and used to manage the risk it identifies. A thick, beautifully detailed risk report that sits on the shelf is not only useless, but a clear indicator of negligence. Imagine a regulator asking you, “You knew about this risk, but why didn’t you do anything about it?” Acting on a risk assessment also means verifying that the risk was reduced by an active risk management process. In the same letter to Abbot Labs, the FTC also reprimanded them by saying:

"Your firm conducted a risk assessment and a corrective action outside of your CAPA system. Your firm did not confirm all required corrective and preventive actions were completed, including a full root cause investigation and the identification of actions to correct and prevent recurrence of potential cybersecurity vulnerabilities, as required by your CAPA procedures."

No one wants to have these things said about their security program. I see this as a warning shot across the bow for all organizations: clean up your risk assessment processes and make sure you act on the results.

Get the latest application threat intelligence from F5 Labs.

Raymond Pompon is a Principal Threat Researcher Evangelist with F5 labs. With over 20 years of experience in Internet security, he has worked closely with Federal law enforcement in cyber-crime investigations. He has recently written IT Security Risk Control Management: An ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
edbellis
100%
0%
edbellis,
User Rank: Apprentice
10/30/2017 | 1:12:15 PM
Well said
It's particularly important that organizations are acting on the results of these assessments and feedback loops get incorporated into the process. As Ray mentioned, if it just ends up as a report on a shelf not only is it a waste of time and resources, it can be deemed negligent.
FIGSYS017
50%
50%
FIGSYS017,
User Rank: Apprentice
7/27/2017 | 10:04:58 AM
FDA not FTC
The comments were made by the FDA, some part of the warning letter on April 12 2017 https://www.fda.gov/iceci/enforcementactions/warningletters/2017/ucm552687.htm - not FTC. Different organizations.
5 Reasons the Cybersecurity Labor Shortfall Won't End Soon
Steve Morgan, Founder & CEO, Cybersecurity Ventures,  12/11/2017
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
F5 makes apps go-faster, smarter, and safer. With solutions for the cloud and the data center, F5 technology provides unparalleled visibility and control, allowing customers to secure their users, applications, and data. For more information, visit www.f5.com.
Featured Writers
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Gee, these virtual reality goggles work great!!! 
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
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.