CISOs are not risk owners

Many organizations have implicitly adopted the mistaken notion that the chief information security officer (CISO) is the de facto risk owner for all identified cyber risk matters.

In a properly run risk management program, risk owners are business unit leaders and department heads who own the business activity where a risk has been identified. For instance, if a risk is identified regarding the long-term storage of full credit card numbers in an e-commerce environment, the risk owner would be the executive who runs the e-commerce function. That executive would decide to mitigate, avoid, transfer, or accept that risk.

The role of the CISO is to operate the risk management program and facilitate discussions and risk treatment decisions, but not make those risk treatment decisions. A CISO can be considered a risk facilitator, but not a risk owner.

Even when embraced and practiced, this concept does not always stop an organization from sacking the CISO should a breach occur. A dismissal might even be appropriate, for example, if the risk management program that the CISO operated was not performing as expected.

— excerpt from CRISC Certified in Risk and Information Systems Control^TM All-In-One Exam Guide, 2nd edition.

Insights into CRISC certification quality

I spent the previous Friday+weekend at ISACA HQ in Chicago at a workshop. The objective: to examine about 360 candidate exam questions for the CRISC (Certified in Risk and Information Systems Control) certification.

There were about 30 of us that worked in three independent groups that consisted of a facilitator (Richard Norman, a security manager in the UK), a scribe (Kim Cohen, the Certification Exam Development Manager at ISACA), and 8 risk management experts from many different organizations including Bank of America, Caterpillar, Premera Blue Cross, and Verizon Business.

We had our work cut out for us. Each group had about 120 exam questions to examine, discuss, edit, and ultimately determine whether it’s a good question based on many different quantitative and qualitative measurements. Oftentimes our discussion of the question became a discussion about how a security or risk management practices (including what companies should be doing and what they are actually doing). Richard, our facilitator, and Kim, our scribe, kept us on task and on pace.

The hard work began long before the three day weekend. Going back to May 2013, we each began our training on writing certification exam questions for ISACA, and over a four or five week period we each wrote a total of twenty exam questions.  Anyone who thinks this is an easy task does not understand the rules and the discipline required for the task. It is quite difficult.

I’ve been trained by two other certification organizations in exam question writing, but ISACA has really upped the game.  The rigor and quality that ISACA puts into certification exam question development is impressive. There are several levels of review, by different teams, on each question, by vetted subject matter experts, before it sees the light of day. And the analysis does not stop after the exam question has been finalized and approved. Analysis on how test takers answer the question continue throughout the life of the exam question.  It is no wonder that CRISC won the Certification of the Year Award from SC Magazine.

ISACA has been in the certification business longer than just about anyone in information technology. ISACA itself started in the 1960s, and the CISA certification began in the 1980s; tens of thousands of security and IS audit professionals have earned the CISA certification, and it remains one of the top IT security certifications today.

Compliance risk, the risk management trump card

Organizations that perform risk management are generally aware of the laws, regulations, and standards they are required to follow. For instance, U.S. based banks, brokerages, and insurance companies are required to comply with GLBA (the Gramm Leach Bliley Act), and organizations that store, process, or transmit credit card numbers are required to comply with PCI-DSS (Payment Card Industry Data Security Standard).

GLBA, PCI-DSS, and other regulations often state in specific terms what controls are required in an organization’s IT systems. This brings to light the matter of compliance risk. Sometimes, the risk associated with a specific control (or lack of a control) may be rated as a low risk, either because the probability of a risk event is low, or because the impact of the event is low. However, if a given law, regulation, or standard requires that the control be enacted anyway, then the organization must consider the compliance risk. The risk of non-compliance may result in fines or other sanctions against the organization, which may (or may not) have consequences greater than the actual risk.

The end result of this is that organizations often implement specific security controls because they are required by laws, regulations, or standards – not because their risk analysis would otherwise compel them to.

Excerpt from CISA All-In-One Study Guide, second edition

IT security spending squeeze? Switch to risk-based spending

Security managers often have a difficult time getting budget money for security controls during times of economic health, but in a downturn that puts financial pressure in some industry sectors, security budgets can literally dry up.  This may be especially true in organizations that were releasing funds for spending on security controls based upon qualitative justification.

If you’re in this situation, maybe it’s time to switch to a risk-based model for making decisions on where to best spend money on security.

This approach requires that an organization adopt a risk management and risk analysis methodology that is used to perform a detailed risk analysis for any given situation.  A risk analysis methodology will enable a security manager to precisely identify threats, vulnerabilities, and risks in specific situations or settings, which can lead to a clearer understanding of specific risks and what can be done to reduce those risks.

In the end, it’s middle or senior management’s job to make spending decisions.  As risk managers, we can help decision-makes to make more informed decisions based upon identified risks and potential remedies to those risks.

Image courtesy Tech Republic

If a decision-maker still says “no”, do not consider this a failure.  It is a risk manager’s job to help management make informed decisions.  As long as the risk manager provides the facts, including the alternatives in a risk situation, then the risk manager has done his or her job.  It is the decision maker’s job to make risk decisions.  Whether we agree with those decisions may be the basis for much professional discussion – if it’s not our decision, it’s not our decision.

The consolation for the risk manager is that risk-based spending at least puts money where it’s needed the most.

Sources for information on risk analysis and risk management:

NIST 800-30, Risk Management Guide for Information Technology Systems
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
FRAP (Facilitated Risk Analysis Process)