Analytics // Security Monitoring
10/23/2013
09:19 AM
Quick Hits
Quick Hits
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Using Risk Assessment To Prioritize Security Tasks And Processes

Prioritizing security tasks based on real risk measurements can be tough. Here's some advice to get you started

[The following is excerpted from "Using Risk Assessment to Prioritize Security Tasks and Processes," a new report posted this week on Dark Reading's Risk Management Tech Center.]

Information security practitioners are in an increasingly difficult position in most enterprises for several reasons. For one thing, changes in how enterprises adopt, deploy and use technology have raised the complexity bar for the environments that practitioners are charged with defending.

For example, virtualization, cloud and mobile technologies have expanded the footprint of technology in the enterprise -- and along with it the security practitioner's scope of responsibility. At the same time, the number of compromise methods is increasing: Attackers have become more sophisticated, there are more of them, and they espouse a variety of motivations.

Given all of this, it's clear why the remit of security practitioners is more challenging than it used to be. But despite the rise in environmental complexity, spending is relatively stagnant. For example, the most recent Global State of Information Security Survey from PricewaterhouseCoopers shows that fewer than half of the organizations surveyed expect information security budgets to increase. This is why prioritization is so important in a security context -- not only does security investment need to stretch further, there's less room for error when the stretching occurs.

This question of prioritization then becomes one of the key elements (not to mention benefits) of formalized risk management techniques. For organizations that aren't using formalized risk management methods, prioritization is an acutely felt pain point.

But even for organizations that have employed these techniques, technical prioritization often requires further analysis in order for them to be effectively put into practice. In other words, risk management efforts performed at a high level might fail to take into account the specifics of the technical environment, leaving room for interpretation or further prioritization down the line.

In any case, the art of prioritization can help enterprises master the science of security. In this Dark Reading report, we recommend how to adapt elements of risk management that address prioritization in mitigation efforts for use at the technical level. This technique isn't always easy -- and organizations must have some prerequisites in place in order to leverage it fully -- but it is a necessity for security to perform optimally. It's no longer possible to defend everything equally, so focusing on specific, strategic areas of concern is a must.

At a high level, the risk management process can be thought of as iterative, encompassing a number of key steps. These include:

• Identify: The process of determining the possible risks that a given organization might have

• Assess: Determining the degree to which the organization is susceptible

• Mitigate: The process of treating risks -- for example, by avoiding, remediating, transferring or accepting the risk (that is, determining that the risk cannot be practically or practicably offset)

• Monitor: Keeping track of the risk over time to ensure that it doesn't increase, to determine if it's exploited and to inform future decision-making if it's obviated.

To learn more about the process of risk assessment -- and how to translate the results into a prioritized action list -- download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2008-3277
Published: 2014-04-15
Untrusted search path vulnerability in a certain Red Hat build script for the ibmssh executable in ibutils packages before ibutils-1.5.7-2.el6 in Red Hat Enterprise Linux (RHEL) 6 and ibutils-1.2-11.2.el5 in Red Hat Enterprise Linux (RHEL) 5 allows local users to gain privileges via a Trojan Horse p...

CVE-2010-2236
Published: 2014-04-15
The monitoring probe display in spacewalk-java before 2.1.148-1 and Red Hat Network (RHN) Satellite 4.0.0 through 4.2.0 and 5.1.0 through 5.3.0, and Proxy 5.3.0, allows remote authenticated users with permissions to administer monitoring probes to execute arbitrary code via unspecified vectors, rela...

CVE-2011-3628
Published: 2014-04-15
Untrusted search path vulnerability in pam_motd (aka the MOTD module) in libpam-modules before 1.1.3-2ubuntu2.1 on Ubuntu 11.10, before 1.1.2-2ubuntu8.4 on Ubuntu 11.04, before 1.1.1-4ubuntu2.4 on Ubuntu 10.10, before 1.1.1-2ubuntu5.4 on Ubuntu 10.04 LTS, and before 0.99.7.1-5ubuntu6.5 on Ubuntu 8.0...

CVE-2012-0214
Published: 2014-04-15
The pkgAcqMetaClearSig::Failed method in apt-pkg/acquire-item.cc in Advanced Package Tool (APT) 0.8.11 through 0.8.15.10 and 0.8.16 before 0.8.16~exp13, when updating from repositories that use InRelease files, allows man-in-the-middle attackers to install arbitrary packages by preventing a user fro...

CVE-2013-4768
Published: 2014-04-15
The web services APIs in Eucalyptus 2.0 through 3.4.1 allow remote attackers to cause a denial of service via vectors related to the "network connection clean up code" and (1) Cloud Controller (CLC), (2) Walrus, (3) Storage Controller (SC), and (4) VMware Broker (VB).

Best of the Web