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.
Google Engineering Lead on Lessons Learned From Chrome's HTTPS Push
Kelly Sheridan, Staff Editor, Dark Reading,  8/8/2018
White Hat to Black Hat: What Motivates the Switch to Cybercrime
Kelly Sheridan, Staff Editor, Dark Reading,  8/8/2018
PGA of America Struck By Ransomware
Dark Reading Staff 8/9/2018
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: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-3937
PUBLISHED: 2018-08-14
An exploitable command injection vulnerability exists in the measurementBitrateExec functionality of Sony IPELA E Series Network Camera G5 firmware 1.87.00. A specially crafted GET request can cause arbitrary commands to be executed. An attacker can send an HTTP request to trigger this vulnerability...
CVE-2018-3938
PUBLISHED: 2018-08-14
An exploitable stack-based buffer overflow vulnerability exists in the 802dot1xclientcert.cgi functionality of Sony IPELA E Series Camera G5 firmware 1.87.00. A specially crafted POST can cause a stack-based buffer overflow, resulting in remote code execution. An attacker can send a malicious POST r...
CVE-2018-12537
PUBLISHED: 2018-08-14
In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response.
CVE-2018-12539
PUBLISHED: 2018-08-14
In Eclipse OpenJ9 version 0.8, users other than the process owner may be able to use Java Attach API to connect to an Eclipse OpenJ9 or IBM JVM on the same machine and use Attach API operations, which includes the ability to execute untrusted native code. Attach API is enabled by default on Windows,...
CVE-2018-3615
PUBLISHED: 2018-08-14
Systems with microprocessors utilizing speculative execution and Intel software guard extensions (Intel SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.