Astrophysicists and information security officers have something in common: The universes they monitor are expanding at an inexorable pace, and turning back time is not an option. We're being bombarded with competing demands around regulatory compliance and the next big thing in security, while the breaches we combat are having a larger impact. Our adversaries have gone from hobbyists to organized criminals, disclosure and privacy laws continue to be passed, the cost to clean up after attacks is rising, and reactive information security has proved ineffective. The stakes are a lot higher on all fronts, and the time for major change is clearly upon us.

It doesn't take a rocket scientist to realize that, in a resource-strapped world, prioritization is the critical component to setting an IT security agenda. Define the organization's most critical systems and data sets. Assess the risks associated with these assets. Decide which risks are acceptable, which are mitigable, and which can be transferred. Build a plan, and allocate resources appropriately.

If only it were that easy.

There's no one-size technology, process or approach to security. But after analyzing successes and failures and talking to industry leaders,

one trend stands out: Organizations are shifting from yesterday's binary, yes/no, good/bad information security thinking to a pragmatic approach of weighing risks and acting accordingly.

We must ensure a risk management approach is integrated into all processes, remain diligent about project selection, move beyond just firefighting, and get smarter with technology investments. For some organizations, this will require a wholesale transformation. Consider these critical factors when making the leap.

NEW WAY OF THINKING
We're all barraged by buzzwords. "Compliance" and "risk management" appear to be mandatory in all security product positioning, with "governance" not far behind. It's debatable how many products actually add to governance, risk management, and compliance as a philosophy, but compliance and risk management are absolutely relevant. We'd argue that the effectiveness of IT organizations of all sizes will soon depend on their ability to master the art of managing risk. If we don't excel here, we'll be flying blind at the expense of the organizations and clients we've been tasked to protect.

So what's the unifying thread? Maturity. Glitzy hacking trend reports and fear-based proposals don't cut it with most of the C-level execs we work with. Without a common language to communicate risks (read: money), most security concerns go unheard.

But slinging the risk management mantra and actively managing risk aren't the same thing. The process and science behind the concept are critical. Areas of risk management vary in maturity, from Lloyd's of London and the domestic insurance industry to evolving IT risk frameworks such as ANZ 4360, NIST 800-30, and Factor Analysis of Information Risk (FAIR). Still, regardless of the depth and background of your understanding or the likelihood that you'll adopt a formal risk management framework in the IT environment, some concepts and necessary adjustments are critical.

For starters, when communicating risk, it's important to understand the audience and scope. "I learned the hard way that loosely throwing around risk terms when it came to IT projects in an insurance company was a bad practice," says Mike Murray, an information security practitioner in the financial services industry. "When the audience is used to looking at actuarial tables, you're going to look pretty stupid, pretty quickly, outside of the IT ranks if you're not careful."

Terminology matters, and historically, IT hasn't done the best job here. For example, to IT the word "asset" may mean anything from a physical item (a USB thumb drive) to a system (order entry) to data sets (technical schematics from R&D). Complicating matters, IT's view of assets (web14, or worse, IP address 10.1.2.3) relative to the business view of an asset (part of the North American order-tracking system) has been disjointed at best. Bridging this gap is crucial for productive discussions about risk. Progressive IT and security teams have done these mappings and--arguably as important--communicated the linkages to relevant business stakeholders. Without these steps, there's little chance of an effective risk conversation, much less effective prioritization.

The terms "vulnerability" and "threat" also are critical to the process, and they're often confused. Loosely defined, a vulnerability is a state or defect of an asset that could be exploited to create loss or harm; a threat is an entity or action that can cause loss or harm. Going into greater detail on the use of these terms in the IT and security contexts probably warrants an article all to itself, but suffice it to say that using language properly and consistently is essential when talking about risk. For a comprehensive discussion of IT risk terminology, check out FAIR's primer.