Archive

Posts Tagged ‘security’

US Government Guidance on Cyber Risk – and Why Risk Management

July 12, 2021 4 comments

Before addressing new draft guidance from the Federal Government, 2nd Draft NISTIR 8286A Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management (ERM), it is essential to go back to fundamentals.

Why, we should ask, do we need risk management?

The answer is not: “Because we are required by the regulators and others to have it. It’s a compliance activity”.

While that may be true, we should comply while using the least possible effort and resources if this is the only purpose and there is no other value.

The answer should also not be: “We need to create a list of the things that could go wrong and harm us, so we can avoid or at least mitigate that harm”.

While there is some value in a list, focusing on avoiding all harm is the path to failure. To succeed, you need to take the risk of harm – but do so judiciously where it is warranted on business grounds.

Risk practitioners should avoid being labeled, because of their blinkered approach to managing or mitigating risk, as people who get in the way of running the business.

The correct answer is, of course, that only by understanding what is happening and what might happen in the future can we set and then achieve enterprise objectives – and we do that through informed and intelligent tactical and strategic decisions that are made every day.

XX

Business decisions can be complex and require the consideration of multiple factors.

For example, decisions are often needed in response to questions like these:

  • How much should we invest in cybersecurity, given our limited resources and the need to fund new systems, product development, and marketing initiatives?
  • Should we implement this new internet-enabled product on time, early (to gain market advantage), or delay it (to obtain greater assurance that it won’t be hacked)?

As you know, I cover this and much more first in Making Business Sense of Technology Risk (focused on the topic at hand today) and then in Risk Management for Success.

XX

There are some good points in the draft NIST report (they haven’t called it a Standard yet).

But they are focused on developing a cyber risk register that can be added to an enterprise risk register, as if that is all that is required for effective risk management.

A risk register, or a risk profile, or a list of risks in another guise will not help management make the business decisions necessary for success.

XX

Let’s review some of the good content, with comments where appropriate.

  • For federal agencies, the Office of Management and Budget (OMB) Circular A-11 defines risk as “the effect of uncertainty on objectives.” An organization’s mission and business objectives can be impacted by such effects and must be managed at various levels within the organization.

Comment: this is excellent, but the report does not ask those assessing risks (and they focus on harms rather than all the things that might happen) to do so in terms of the potential effect on objectives. It should be noted that in order to do that, it is necessary to specify which enterprise objectives might be affected and by how much. In my books, I recommend considering how they might affect the likelihood of achieving the objectives rather than a simplistic dollar figure.

  • ERM strategy and CSRM strategy are not divergent; CSRM strategy should be a subset of ERM strategy with particular objectives, processes, and reporting.

Comment: this is good, but care should be taken to ensure that any reporting is designed to address the need to enable informed and intelligent decisions. In other words, provide the specific information decision-makers need, when they need it – and that is rarely a list of risks.

  • CSRM, as an important component of ERM, helps assure that cybersecurity risks do not hinder established enterprise mission objectives. CSRM also helps ensure that exposure from cybersecurity risk remains within the limits assigned by enterprise leadership.

Comment: CSRM, or cybersecurity risk management, should be fully integrated with enterprise risk management so that all sources of risk (i.e., both the potential for harm and the potential for reward from things that might happen) are considered together. You need to intelligently aggregate risks from disparate sources, such as compliance and cyber, when making a decision.

  • Risk appetite regarding cybersecurity risks is declared at the Enterprise Level. Risk appetite provides a guidepost to the types and amount of risk, on a broad level, that senior leaders are willing to accept in pursuit of mission objectives and enterprise value. Risk appetite may be qualitative or quantitative. As leaders establish an organizational structure, business processes, and systems to accomplish enterprise mission objectives, the results define the structure and expectations for CSRM at all levels. Based on these expectations, cybersecurity risks are identified, managed, and reported through risk registers and relevant metrics. The register then directly supports the refinement of risk strategy considering mission objectives.

Comment: while I accept the need for limits, such as credit limits, the idea of an enterprise level risk appetite statement strikes me as having little logical or practical merit. I know many will disagree, but have yet to hear a persuasive argument in their support.

  • In a footnote, the report states: OMB Circular A-123 states, “Risk must be analyzed in relation to achievement of the strategic objectives established in the Agency strategic plan (see OMB Circular No. A-11, Section 230), as well as risk in relation to appropriate operational objectives. Specific objectives must be identified and documented to facilitate identification of risks to strategic, operations, reporting, and compliance.”

Comment: this footnote states a critical point that is missing from the body of the report.

  • Risk identification represents a critical activity for determining the uncertainty that can impact mission objectives. NISTIR 8286A primarily focuses on negative risks (i.e., threats and vulnerabilities that lead to harmful consequences), but positive risks represent a significant opportunity and should be documented and reviewed as well. Consideration and details regarding positive risks will be addressed in subsequent publications.
  • Practitioners will benefit from identifying and overcoming bias factors in enumerating potential threat sources and the events they might cause. Consideration of these factors will also help reconcile reactionary thinking with analytical reasoning. An intentional approach to enumerate threats without bias helps to avoid complacency before an incident and supports a proactive evaluation based on relevant data, trends, and current events.

Comment: I like the fact that the report includes a table with a few types of bias included.

  • Some industry specialists have indicated that a range of possible values is more helpful and likely more accurate than a single “point estimate.” Additionally, while this example uses the mean values of those ranges to identify the likelihood and potential impact, the ranges themselves are often recorded in the risk register. In this instance, given a possible impact of “between $1.7 million and $2.4 million,” the exposure may have been presented as “$1.02 million to $1.44 million.”

Comment: the report should add that each of the potential effects has a separate likelihood. I also like the inclusion of a discussion of “three-point estimation” and Monte Carlo simulation.

XX

I have not excerpted more from the NIST report because of its focus on developing a list of risks rather than enabling informed and intelligent strategic and tactical decisions.

I also disagree with the static idea of developing objectives and then setting a risk appetite. I do not believe that will be effective for many of the decisions that have to be made every day in running the business, where multiple sources of risk and reward need to be considered.

XX

I welcome your thoughts.

PS: I have sent comments to NIST at nistir8286@nist.gov. I would send them a copy of Making Business Sense of Technology Risk, but they are not allowed to accept gifts.

Advertisement

The business risk that is cyber

February 28, 2021 8 comments

Today, I am returning to this topic and highlighting three different perspectives.

I see them as a progression, each with a marked improvement over the previous piece.

XX

The first is in TechRepublic: Can your organization obtain reasonable cybersecurity? Yes, and here’s how. The author is Michael Kassner, a freelance writer who specializes in business and technology. He has been referred to as a cybersecurity expert; as best I can tell, he has never been a practitioner.

Kassner’s thoughts are based on his review of Cybersecurity Risk: What does a ‘reasonable’ posture entail and who says so? He refers to that work when he says (in these excerpts):

…lawmakers and regulators are responding to the escalating number of cyberattacks by requiring businesses to meet certain cybersecurity standards to achieve reasonable security. However, “Without a defined, coherent standard to use as a reference, companies are left wandering in the wilderness when it comes to compliance with these often ambiguous laws and regulations.”

Since cybersecurity and its regulation are moving targets, companies tend to copy what other organizations are doing to secure digital assets, hoping it will be seen as good enough…. “With data-breach litigation increasing, this practice is nothing short of risky as businesses are allowing a judge or jury to determine the reasonableness of its cybersecurity risk posture after an incident has occurred.”

…a good place to start is determining what would be considered a lack of reasonable security. “This approach makes it easier for an organization to map data-security protection efforts (including privacy and resources) to a known framework.”

A good first step… is to use the Center for Internet Security’s Critical Security Controls as the authoritative source. “One just needs to map the definition of ‘reasonable’ to any of 20 specifications to attest to its validity and utility.”

The Center for Internet Security’s Critical Security Controls is a recommended set of actions for cyber defense that provide specific ways to stop attacks.

Using the Center for Internet Security’s Critical Security Controls also helps simplify the selection of a risk framework needed to assess the company’s IT environment, determine gaps, and propose solutions.

“Implementing the CIS CSC will show due care in any conflict venue by demonstrating the organization is practicing cyber due diligence, even without a fully minimized risk posture.”

XX

In pre-pandemic days, McKinsey shared The risk-based approach to cybersecurity. The authors all work for McKinsey in their cyber practice.

They start with this telling difference from the TechRepublic perspective.

The most sophisticated institutions are moving from a “maturity based” to a “risk based” approach for managing cyberrisk.

McKinsey is absolutely right to dismiss the idea that following so-called ‘best practices’ and adopting somebody’s set of recommended controls constitutes adequate protection. It also doesn’t protect you from litigation!

Consider the Heartland Payment Systems breach, described in several articles such as this one from ObserveIT.

As the article explains, the breach was massive and was not detected by the company. It was brought to their attention by Visa and, contrary to what the authors say, the CEO did not believe it at first. He famously said it couldn’t have happened because they had just passed their PCI audit!

McKinsey explains:

This article is advancing a “risk based” approach to cybersecurity, which means that to decrease enterprise risk, leaders must identify and focus on the elements of cyberrisk to target. More specifically, the many components of cyberrisk must be understood and prioritized for enterprise cybersecurity efforts. While this approach to cybersecurity is complex, best practices for achieving it are emerging.

To understand the approach, a few definitions are in order. First, our perspective is that cyberrisk is “only” another kind of operational risk. That is, cyberrisk refers to the potential for business losses of all kinds—financial, reputational, operational, productivity related, and regulatory related—in the digital domain. Cyberrisk can also cause losses in the physical domain, such as damage to operational equipment. But it is important to stress that cyberrisk is a form of business risk.

They continue (see the highlighted portion):

Even today, “maturity based” approaches to managing cyberrisk are still the norm. These approaches focus on achieving a particular level of maturity by building certain capabilities. To achieve the desired level, for example, an organization might build a security operations center (SOC) to improve the maturity of assessing, monitoring, and responding to potential threats to enterprise information systems and applications. Or it might implement multifactor authentication (MFA) across the estate to improve maturity of access control. A maturity-based approach can still be helpful in some situations: for example, to get a program up and running from scratch at an enterprise that is so far behind it has to “build everything.” For institutions that have progressed even a step beyond that, however, a maturity-based approach is inadequate. It can never be more than a proxy for actually measuring, managing, and reducing enterprise risk.

XX

Unfortunately, while McKinsey talks about cyber as just another operational risk and how it needs to be fully integrated into the enterprise risk management program, they don’t join the dots. They are not seeing how it is all about taking the right risks for success.

They continue to manage doom rather than the achievement of enterprise objectives.

XX

The third piece is by Carol Williams. She is a risk management consultant with 9 years’ previous experience as a risk practitioner and 5 years as a regulator.

Carol’s Is technology risk bigger than “cyber” risk? Is an excellent read. Rather than excerpt it here, I suggest you read the entire article. (You will quickly see why I like her post.)

XX

The bottom line is that managing “cyber risk” should not be done in a silo, but within the context of making informed and intelligent business decisions every day.

Sometimes, you need to take that cyber risk!

Will you avoid purchasing an Amazon Alexa or an Apple iPhone simply because of the unmanageable cyber risks, or will you weigh the pros and cons and make a sensible decision?

Will you allow competitors to leap ahead while you remove that last risk, or will you take the risk and the market?

XX

I welcome your thoughts.

Cyber and reputation risk are dominoes

February 18, 2017 12 comments

Anthony Fitzsimmons recently sent me a review copy of his new book, Rethinking Reputation Risk. He says that it “Provides a new perspective on the true nature of reputational risk and damage to organizations and traces its root causes in individual and collective human behavior”.

I am not sure that there is much that is new in the book, but if you want to understand how human behavior can be the root cause (in fact, it is very often the root cause) of problems for any organization, you may find it of interest.

The authors (Fitsimmons and Professor Derek Atkins) describe several case studies where human failures led to serious issues.

Humans as a root cause is also a topic I cover in World-Class Risk Management.

As I was reading the book, I realized that I have a problem with organizations placing separate attention to reputation risk and its management. It’s simply an element, which should not be overlooked, in how any organization manages risk – or, I should say, how it considers what might happen in its decision-making activities.

The same thing applies to cyber risk and even compliance risk.

They are all dominoes.

dominoes

A case study:

  • There is a possibility that the manager in HR that recruits IT specialists leaves.
  • The position is open for three months before an individual is hired.
  • An open position for an IT specialist who is responsible for patching a number of systems is not filled for three months.
  • A system vulnerability remains open because there is nobody to apply a vendor’s patch.
  • A hacker obtains entry. CYBER RISK
  • The hacker steals personal information on thousands of customers.
  • The information is posted on the Internet.
  • Customers are alarmed. REPUTATION RISK
  • Sales drop.
  • The company fails to meet analyst expectations for earnings.
  • The price for the company’s shares drop 20%.
  • The CEO decides to slash budgets and headcounts by 10% across the board.
  • Individuals in Quality are laid off.
  • Materials are not thoroughly inspected.
  • Defective materials are used in production.
  • Scrap rates rise, but not all defective products are detected and some are shipped to customers.
  • Customers complain, return products and demand compensation. REPUTATION RISK
  • Sales drop, earnings targets are missed again, and …….
  • At the same time as the Quality staff is downsized, the capital expenditure budget is cut.
  • The Information Security Officer’s request for analytics to detect hackers who breach the company’s defenses is turned down.
  • Multiple breaches are not detected. CYBER RISK
  • Hackers steal the company’s trade secrets.
  • Competitors acquire the trade secrets and are able to erode any edge the company may have.
  • The company’s REPUTATION for a technology edge disappears. REPUTATION RISK
  • Sales drop. Earnings targets are not achieved, and……..

It is true that every domino and the source of risk to its stability (what might happen) needs to be addressed.

But, focusing on one or two dominoes in the chain is unlikely to prevent serious issues.

One decision at a low level in the company can have a domino effect.

Consider this slide deck by ERM Strategies, Inc. about the Deep Water Horizon disaster.

I welcome your comments.

Information Security Disconnected from Management?

September 12, 2013 11 comments

The information security software firm, Tripwire, released the interesting results of a “state of risk-based security management” study performed in conjunction with the Ponemon Institute. (The link above is to the press release and summary. The complete study is downloadable in parts – not a good idea, Tripwire – from this location.)

The study has some disturbing comments:

  1. According to the study, not only do two thirds of IT professionals fail to communicate security risks, but 59% filter negative facts before they are disclosed!
  2. About half said that communication between security risk management and business personnel is “poor, nonexistent, or adversarial”.

Tripwire’s CTO is quoted as saying:

“Risk provides the common language that enables a broader business conversation about cybersecurity risks, particularly when dealing with non-technical executives. However, it’s clear from this report that most organizations are missing the majority of opportunities to integrate security risks into day-to-day business decisions. Changing this paradigm will require security professionals to develop new communication skills so they can talk about security risks in terms that are clearly relevant to the top-level business goals.”

In my opinion, Dwayne (the CTO) has this backwards.

These IT professionals need to communicate business risks – the potential effect on the business and its objectives from a potential information security exposure.

Talking about security risks is using a language that the business executives don’t speak naturally, one that does not communicate how their and the organization’s success might be affected.

As my good friend Jay Taylor says, and ISACA in its guidance reiterates, there is no such thing as IT risk – only the business risk created from an IT-related issue. For example, the loss of a server farm is not the risk; the risk is the effect of that loss on the business, such as the inability to support normal business operations such as accounting, sales, etc. which leads to loss of revenue.

Yes, IT professionals need to (as Dwayne says) “develop new communication skills”. They need to learn how to communicate in the language of the business. They need to talk about IT-related business risk, and cut out the techno-babble of “information security risk”.

Let’s not put all the blame for poor communications on IT. The business and especially any risk management personnel need to translate any techno-babble into business risk. They must not accept talk of “IT risk”. In the process, they can help the IT staff learn to speak the language of the business.

Just my opinion. What is yours?