After a security breach, organisations are often left with egg on their faces, with the public asking why none of the risks were considered. In some instances, someone forgot to follow policy. Other times, there was no policy in the first place.
Does this mean that organisations are bad at following through with setting the risk appetite in the boardroom, or in actually implementing it? To find out, ZDNet spoke with several industry experts with experience of the inner workings of organisations and how they handle risk. Providing their insight are Forrester analysts Masami Kashiwagi and Manatosh Das, Gartner research director Anne Robins, Telsyte senior analyst Rodney Gedda, and Lockstep managing director Stephen Wilson.
Telsyte's Gedda believes that boards are having to learn about security the hard way, but that given the impact of security breaches, they are beginning to learn fast.
"They've got bigger things to fry. Security is one of those areas that thrives on paranoia; it thrives on the incident reaction. It's not something that the board is concerned about — shareholder value, profits — it's less concerned with operational aspect," he said.
"They will learn pretty quickly in the event of an incident. A lot of it will be reactionary. It won't be proactive."
Forrester's Kashiwagi and Das gave boards a little more credit, stating that because the risks of attack come from both internal and external threats, it makes the larger picture a very confusing one.
"This confusion often results in 'security' being ranked as one of the top concerns surrounding cloud, mobile, and BYOD strategies, but no-one seems to be able to clearly analyse the gap and develop a plan of action," they said.
Gartner's Robins said that some industries have more experience in risk management, and therefore produce more organisations that are better informed and equipped, but that not all organisations are created equal.
She said that many of the boards of these organisations adopt a security risk management approach that she considers to be "piecemeal" and only valid at the time it's being considered.
"This can lead to security risk information which is out of date, incomplete, and even misleading."
Sometimes, the information provided to boards is incomplete also. Privacy is one of those areas that, although deeply tied in with security when it comes to protecting customer data, fails to reach the board.
Lockstep's Wilson said that he often sees many boards with a "blind spot" for privacy issues, because sometimes even the C-level executive informing them doesn't realise that they are meant to be paying closer attention.
"The trouble is that CIOs/CTOs tend to think of privacy as a legal issue, and that privacy only touches IT in the area of security and access control," he said, but pointed out that routine IT operations are where privacy risks really are.
Wilson sympathised with the operational side of IT, however, stating that sometimes the risks are "part and parcel" of the business. Companies need to accept that some level of risk tends to compete with the need for privacy, he said, but organisations need to be realistic about what is acceptable.
"Perfect privacy might mean administrators cannot do their jobs. So CIOs/CTOs need to strike a balance."
Das and Kashiwagi said that the ultimate responsibility to keep the board informed lies with the CISO or CSO, but clarified that not all organisations have these roles — whether that's due to the size of their business or to skills shortages in the market.
"Hiring CISOs and information security specialists is still new for many industries and organisations in Asia, except among banking and financial services firms and federal government agencies," they said.
"In the end, if one doesn't have a security team separate from IT, then the responsibility for handling cyberattacks and other external threats affecting IT infrastructure likely goes to the CIO and his team. For issues related to internal threats and compliance, the responsibility may go to the direct business unit, legal, or compliance team."
Robins took a slightly different approach, telling ZDNet that while the CIO or similar C-level executive would have responsibility for reporting on any risks to the business through technology, this technology doesn't simply sit in one area of the business alone.
"In many organisations, there is [sometimes significant] technology and infrastructure deployed elsewhere, such as within lines of business or by sales and marketing departments. Many organisations also have supplier arrangements with service providers [such as cloud or SaaS providers] that may be managed through procurement or vendor management divisions, and these services need to be part of the scope of security risk management," Robins said.
Because of this, Robins argued that operational security risk management could often be divided or shared among several roles in an organisation.
"The distribution of the assessment and management of security risks across an organisation does not necessarily mean that responsibility doesn't converge to a single nominated executive — who may be the CIO, CSO, CFO, or other compliance-focused executive."
A good example of this is demonstrated when it comes to privacy. Wilson said that while a company's privacy officer is the 'official' holder of responsibility, they tend not to have a good grasp of the impact of IT operations.
"We need better day-to-day collaboration between privacy officers and CIO/CTO to surface all the subtle information flows and information collections," he said.
Gedda agreed, stating that if needed, it sometimes comes down to the IT architects and managers on the ground, but that the message these more operational staff are sending is the important factor.
He said that IT needs to become more business-minded, and while an IT manager may be concerned with the technical aspects of a vulnerability or risk to the business, what really matters is how that manager could describe the impact to the business, not the inner workings.
"They don't care so much as to whether customer data was stolen because it was hosted on Amazon or because there was a bug in a MySQL database. That's asking a bit too much of the board," Gedda said.
"IT can be the buffer between technical operations and business outcomes, and if IT says, 'We have these sort of processes in place, this technical ability in place, and this is our exposure and these are the risk factors', then the board can say, 'OK, well, we don't actually concern ourselves with the technical aspect, but we'll accept these risk factors and have a mitigation strategy if anything goes wrong'."
Kashiwagi and Das said that understanding the risks and knowing what to do about them are two different things, and that enterprises tend to be at various stages of each.
The Forrester analysts cited the example of a telecommunications company that Forrester had examined in the past. The company's CISO had taken the precaution of recommending a business continuity and disaster-recovery readiness plan, which was received poorly by the board.
A subsequent fire at a remote switching centre was finally the impetus that forced the board to realise the need to take risk management more seriously, and take action.
"Had the board members considered the on-the-ground realities of threats to IT security, the BCP/DR project would have been approved before disaster struck."
But the pair of analysts also admitted that even setting up the right foundation for security is a challenge for many organisations.
These foundations include formal identity access management policies, data protection and access policies, which they believe need to be implemented if an organisation is to have a chance to tackle security seriously.
Even the process of setting up reporting structures can prove to be difficult, the analysts said, giving the example of one organisation that they had examined in the past.
It had spent years working with a security service provider to find a "best-fit security operation model". In that organisation, the CISO reports to the CIO and, in addition to managing and implementing IT security, has to coordinate and "evangelise" C-level executives at the board level.
Robins believes that the difference between the board's perception of risk versus the organisation's actual exposure comes down to the four areas of timeliness, frequency, accuracy, and completeness.
For timeliness, she believes that organisations that employ static risk assessments, or base them on out-of-date information, contributed to the breakdown.
The frequency of communicating with the board is important because although major data compromises or outages stir action and interest, they don't happen all the time.
"Such adverse events can be triggered by a wide range of threats, which can make it complicated to use scenario planning to model consequences and responses."
Boards are also often not informed in an accurate manner, she said, referring to the use of qualitative rather than quantitative ways of describing consequences and outcomes.
Qualitative risk assessments conducted by operational IT staff may consider a particular risk to be "high" or "extreme", she said, but the board is used to assessing risk in dollar figures.
"To counter this, there is a temptation to indulge in some 'mathemagic' and convert those qualitative assessments into numbers [a consequence of 'high' equals $100,000] and then presenting them as hard data without a sound statistical basis."
Lastly, a lack of completeness is often seen where organisations conduct risk assessments on a per-project or per-technology basis, Robin said, which fails to define risk context in terms of the whole organisation.
Robins suggested that businesses take a programmatic and organisational view of security and risks, rather than considering it to be a stand-alone discipline. This means adopting standards-based methodologies. She said that these enable the business to communicate in "a common language and framework", regardless of the separate disciplines in an organisation.
This whole-of-organisation approach would also help in more widely monitoring risks to the business, and enable it to prioritise its efforts and budgets accordingly.
Rather than holding a single C-level executive responsible, Robins suggested that businesses consider a decentralised approach to managing and assessing security. The advantages of such an approach include increased awareness, shared responsibility, enforced accountability, and the ability to bring security risk and discussions into the mainstream.
For those organisations now seeking to or in the process of implementing a security risk assessment and/or risk analysis methodology, Robins said that they should ask two important questions: "Can I fit this methodology into my existing organisational process, tools, and operations?" and "Are the outputs suitable for the communications I need to make about security risk, particularly to executives and the board?"
Kashiwagi and Das said that continuous efforts to educate and evangelise to internal stakeholders and decision makers is key.
"Ideally, one should have a specialised IT security team separately from the IT organisation and work alongside IT under the leadership of a CISO, as well as directly report to the CEO or head of business to be in the position to coordinate among different stakeholders on the board."
However, structural changes take time. In terms of the smallest, but most immediate, steps that organisations could be taking today, Gedda said that involving people from the wider organisation and communicating with them would be important.
"Communication is always a problem amongst organisations where you have a board, you have senior management, you have middle management, you have operations people," he said.
"Someone at the coalface has a very different perspective to someone at the senior management level, and the risk and expectations vary accordingly."
Bringing these perspectives together doesn't necessarily mean that the IT manager needs to become a strategist, or that board members need to become technical experts, however.
"The board doesn't need to have an intimate knowledge, but it certainly needs to have a general knowledge and a risk mitigation-level knowledge."