CIOs must reassess cloud concentration risk post-CrowdStrike

The recovery from last week’s defective content update from CrowdStrike that impacted millions of Microsoft Windows endpoints has been a significant undertaking, to say the least.

The outage put enterprises, cloud services providers, and critical infrastructure providers into precarious positions, and has drawn attention to how dominant CrowdStrike’s market share has become, commanding an estimated 24% of the endpoint detection and response (EDR) market.

That leading position and the ongoing push toward platform approaches to securing data are the main drivers for CrowdStrike’s inclusion on CSO’s top 10 most powerful cybersecurity companies list. But the outage has also raised questions about enterprise cloud strategies and resurfaced debate about overly privileged software, as IT leaders look for takeaways from the disastrous event.

It also highlights the downsides of concentration risk.

What is concentration risk?

CrowdStrike is regarded by many in the industry as the “Gold standard” in the EDR and anti-malware protection market. Its Falcon solution employs an agent on each endpoint device to continuously monitor them for and respond to cyber threats such as ransomware and malware. This agent-based approach, along with a flaw in CrowdStrike’s Rapid Response Content validation process, are central to the scope of blue screens of death (BSODs) many enterprises have had to remediate.

As enterprises bring their systems back online, IT leadership teams must certainly face questions about how they were impacted, and what their true exposure to these types of incidents are. Despite efforts to increase resilience in recent years, everyone is going to feel a little more vulnerable than they previously did in the wake of CrowdStrike.

Looking to the future, IT leaders must bring stronger focus on “concentration risk”and how these supply chain risks can be better managed. 

As noted by the Financial Conduct Authority (FCA), concentration risk is defined as: “The risks arising from the strength or extent of a firm’s relationships with, or direct exposure to, a single client or group of connected clients.”

In layman’s terms, it simply means putting all your eggs in one basket. We should expect this simple definition to be applied and for it to receive regulator attention. I say this with reference to a recent meeting I had with fellow CISOs and regulators who expressed increasing concern about concentration risk.

Regulation ahead

Regulators will have observed what is being called the “world largest IT outage,” and they will be under pressure about what steps they can take to help prevent this scenario from occurring again. Once the dust settles, I anticipate the ever-increasing cloud concentration risk to be a significant target.

Most enterprises continue to make progress in their journey to the public cloud, with multiple large institutions adopting a “cloud first” mantra. These transformations typically start with a single cloud provider and gradually introduce additional cloud providers as necessary for specific use cases and to meet data sovereignty requirements.

Cloud concentration risk is now arising when these enterprises rely worryingly on a single cloud service provider (CSP) for all their critical business needs. In effect this has shifted reliance on their own data center to now storing all data, running all applications on a single cloud infrastructure.

Cloud concentration risk is then fully realized when any one incident, like the CrowdStrike outage, can disrupt your entire operation. With enterprises increasingly dependent on the same applications and cloud providers, this can be devastating at scale, as we’ve seen with CrowdStrike. Such a scenario extends to security breaches and other events that can have more systemic impact on countries and industries.

Dr. Matt Ryan from the UNSW Institute for Cyber (IFCYBER) explains that “during a major technology disruption event, large financial institutions will find it very difficult to simply pivot from one cloud service providers to another, as the cost to build this level of resiliency is simply too high for most commercial organizations.”

Still, we must.

Enter multi-cloud

Toavoid the dangers of cloud concentration risk, a multi-cloud strategy,in which business workloads are spread across multiple cloud providers, is vital. With a multi-cloud strategy in place, when one provider has an issue, your operations in the other clouds can keep things running.

The alternate is to adopt a hybrid cloudapproach,combiningprivate and public cloud. This gives you more control over proprietary and sensitive data whilst still having all the benefits of public cloud scalability.

But either of these approaches, multi-cloud or hybrid cloud, will have increased complexities and challenges that could possibly impact resilience if not managed properly. Unfortunately, the complexity of multiple vendors can lead to incidents and new risks. This includes cloud misconfigurations, and difficulties in troubleshooting.

For the CIO, these approaches add vendor complexity, requiring management across different SLAs and support processes. FinOps, which blends financial and cloud operations, will have to be implemented to manage the costs across the various cloud providers in your multi-cloud environment, as well as the contracts. Internally, the CIO must manage their security policies across these cloud vendors, as well as any third partiesthe cloud providers themselves use.

What is your concentration risk tolerance?

Moving forward, understanding your organization’s exact acceptable level of concentration risk will be a key concern. Boards will be wanting management teams to measure this risk so they can define what their tolerances should be.

The Cloud Security Alliance has some good thinking on this topic. It recommends ways to develop processes for transforming risk tolerance assessments, data/asset classifications, and business requirements into company policies, control objectives, and technical controls.

The approach I would recommend is to begin by identifying and documenting all your business-critical operations. Once these have been defined, technology teams can begin identifying all the underlying technology components and suppliers that support those operations. It’s at this stage that organizations can begin testing and identifying single points of failure in the process that may require further treatment or redundancy.