CSOs and CISOs may feel more pressure from a new breed of security professional - the chief information risk officer - now that the federal government has made risk management mandatory and spelled out in a new document just how risk ought to be assessed and dealt with.
While it doesn't call for overturning the authority of CSOs and CISOs, the directive from the National Institute of Standards and Technology (NIST) does call for input from higher up the corporate ladder when decisions are made about securing an organization's assets.
This push by the federal government may influence what happens in the private sector, where risk assessment is long overdue as a means to determine how information security dollars get spent, says John Pironti, president of IP Architects, a security consulting firm.
"We should do risk first, security second," Pironti says. "Security is there to meet the needs of risk."
Under the new NIST guidelines, that means creation of a risk-executive function - which may be a person or a committee - but one that takes the risk to an organization's goals into account when it decides how to deploy IT security infrastructure.
"This gives a context for how IT and information systems are deployed vs. a random build-out of the infrastructure," says Ronald Ross, one of the authors of the NIST document "Managing Information Security Risk."
The risk-executive function doesn't necessarily mean ousting people currently holding positions within IT security, it could just mean sharing of information with others within the organization. But traditional CSOs and CISOs may lack some of the skills to do the job alone.
"The "S" in CSO and CISO says it already: CSOs and CISOs are mainly concerned with security or with information security," says Urs Fischer, chairman of the risk-certification program run by ISACA, the international IT and information systems organization that offers certification in risk and information system control.
"IT-related risks actually are a lot more: IT risk is business risk — specifically, the business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise. IT-related risk management covers all IT-related risks, not limited to information security," Fischer says.
The distinction can be unclear, says Pironti, because risk is a term that's often not used precisely. To traditional network security personnel, it often means a security threat - what could happen and the likelihood that it will and the impact if it does.
Risk in the broader sense is the ability of a business to absorb and react to a threat. "Do I need to respond or not?" he says.
For example, if a Windows server is open to attack, a pure security professional might say it's a huge risk - to that server. A risk management professional would assess the impact. Would the server go down? Would all the data on it be stolen? "It may not be a real risk. It's a concern, and part of an assessment," Pironti says.
In large part, people who design disaster recovery and business continuity plans already understand risk, he says. Their task is to figure out what a business's most important assets are and to make them available if their primary source becomes unavailable. Those same assets are likely the ones that should be best protected, he says.
Risk assessments by vendors are often overblown because they don't take into account each business's use of their vulnerable products. For example, a bug in a security product may put data in a business division at risk, but if that division is being phased out or represents an insignificant part of revenue, the bug may not be worth fixing, Pironti says.
A common thread among risk assessment models is culling input from people with a broad range of expertise - business, legal, technical, etc. - and feeding it to a central, decision-making person or body. And it's best to cast a wide net. "It's better to treat risk identification as a brainstorm at first to build as comprehensive a list as possible — there are no wrong answers," according to a report by Forrester called "The Risk Manager's Handbook: How to Identify and Describe Risks". "You can always make a decision later to remove risks that you and your subject matter experts consider irrelevant."
As risk officers become more prevalent, people who have held top level security jobs may need to retrain if they aspire to the top risk job, Pironti says. "They're not extremely common yet. They're still being advocated for."
And the job might absorb the CISO, chief privacy officer and other jobs, a situation that might pose political roadblocks. But the position needs to be board-level in order to be effective because the person filling it needs to grasp the goals of the business in order to properly assess risk, he says.
The profile of a good risk management officer is someone who is aware of technology but not wedded to it. "It's very hard for technologists to understand risk. They think they understand the business when they really don't."
For several years he advocated that aspiring risk officers get MBAs to prepare. Now he advocates that they spend time with product-management teams to better understand business processes, what the most valuable information is and where it might be vulnerable. "The question is, 'Do you add another chief?'" he says. "How many chiefs does it take to run a business?"