Skip to content Skip to sidebar Skip to footer

Quantifying and qualifying cyber risk is a longstanding challenge for CISOs. It was already a challenge for on-premise infrastructure when you knew what assets you had and where all the data lived. Cloud migration raises the bar, making it even more challenging to pinpoint cyber risk with a growing digital attack surface composed of distributed infrastructure and independently managed cloud resources used across the company.

To help empower CISOs to more succinctly present their cloud risk and security posture to their board, we asked ourselves, “If a CISO has 15 minutes and one slide to present to the board, how could they communicate their company’s cloud risk?”

This is a big ask for a CISO. The stakes are high in cybersecurity, maybe higher even than compute or internal applications. This in general is the cloud challenge. Based on our experience with customers, there are three models for cloud risk assessments.

How to Assess Cloud Risk

Model 1: A Traditional Approach

Enterprises that are well-established, have been invested in security for a long time, and may even have compliance departments are looking for the traditional frameworks, like from CSA and NIST.

These frameworks offer many advantages. It allows security teams to take the traditional model and framework they have been mapping to and apply it to their cloud infrastructure.

It also allows the CISO to report to the board their NIST or CSA red/yellow/green light assessment. If that is the same framework the board is used to seeing, the assessment already holds meaning and won’t take a lot of explanation.

Many major consulting companies are using these frameworks to offer cloud assessments. There are also some born-in-the-cloud companies offering these assessments, but these firms can only assess cloud infrastructure so they can’t support companies with hybrid infrastructure.

The major challenges of this model are:

  1. It’s not very dynamic (read: slow and misaligned with the speed of cloud development).
  2. It requires a lot of resources, which is a continuous struggle due to the ongoing cybersecurity skills shortage. It also eats up valuable time that overburdened security teams don’t have to spare. Lastly, it’s expensive if using a third-party consultant.

Model 2: DIY Cloud Model

Some companies with very mature cloud infrastructure and processes are taking a DIY approach to cloud risk assessments. This approach is appealing for companies that may lack the resources to effectively manage and monitor all their security technology and critical asset inputs.

In these companies, they are going through the process of discovering all cloud-based critical applications and data. It is a much more personal conversation for the company – a close-up self-assessment – that pulls the CloudOps team together to map everything out. The conversation has to start with discovery, for applications, data and users, and can continue onto assessment based on the company’s digital attack surface.

Some companies are trying to build more cookie cutter versions of this model to sell, which may be appealing for companies who need a cloud-first model but don’t have the people power to build their own.

The major challenges of this model include:

  1. This keeps the CloudOps team separate from any other infrastructure teams, which is not a good long-term approach to risk assessment. The two parts of a hybrid environment can be discovered separately to get started, but it needs to be a short term model to not leave any security gaps.
  2. It is fast to fire something up but requires a lot of developers to actually develop the model and map together the infrastructure. People are already a limited resource for most companies, so this could be the greatest challenge to face.

Model 3: Low Visibility Risk Assessment

For some companies, cloud-based development may be advanced to a point that no central oversight or management is feasibly scalable. In a sense, this is an extension of the first two models, as it may be ideal for very large and distributed enterprises that have very large cloud investments.

This approach is appealing to companies that have limited visibility into what all their developers are doing, or their assets and who’s running them. But regardless, from a security perspective, you still have to discover any new assets being spun up before they can be assessed.

Model 3 accepts that cloud development will continue without central oversight, and puts automation in place to compensate. This automation is critical since all the teams spinning up cloud resources won’t ever be in a room to confirm among managers what they are doing.

These companies have made large investments in the DevOps lifecycle and add a self-register component for cloud risk assessment into the cycle.

The major challenges of this model is self-managed compute. Security leaders must deeply understand the workflows and have all parties agree on a working model for self-registering assets and applications. Someone in dev has to sponsor this idea and drive it across the DevOps organization to ensure everyone buys in and will participate.

Taking it to the Board

Deciding which model is right for your company will depend on answers to several questions. A leading question is whether you are all in on the cloud or early in a migration. It also depends on your internal resources – are financial, people, or organization challenges more acceptable?

No matter the model, going through the initial assessment process will be arduous, but the end result will be rewarding. It will also give you a clear outcome to present to the board.

The main thing the board cares about related to risk is the financial impact, including from compliance lapses, followed by how your risk of a breach is trending over time. And here’s the meta-risk: Boards are very savvy about financial impact and risk.

Calculating financial impact is difficult, but possible:

  1. Don’t only use the doomsday scenario. Have several clearly articulated scenarios with differing impacts. A company-wide ransomware attempt needs to be paired with a ransomware of a small segment of the operations.
  2. Choose your references carefully. Cybersecurity has a long history of truly awful financial impact projections. Base the numbers on your own company financials but choose only meaningful tactical numbers to pair with your own company data. For example, use a specific case study to reference the potential cost of failing to meet compliance regulations. That’s better than a fluffy “average cost of a GDPR fine,” which doesn’t drill down into specific industries, enterprise size, or type of violation. Ask your financial team for assistance: Make them an ally and not a challenger.
  3. Assume you will be asked to justify any assumptions, such as the above time to recover. If you can’t speak fluently on the assumptions and data, don’t include them, or cite them with a notation to note their weakness.
  4. Be real on the potential costs of implementing safeguards. Don’t lowball the potential final costs. Every board member knows that IT projects go overbudget and that security is expensive. It’s better to be straightforward upfront than to go significantly over budget later.
  5. Break out your numbers into the kinds of exposition that board members expect. A single big number is only going to get focused on and leave the real discussion on risk to the wayside. Show your math and break it down over time. Product costs year one, maintenance and support over 5 years, implementation, expansion costs should your business grow, additional modules and upgrades, loaded staff costs (i.e. not just salary), training and certification, and pad it with a healthy percentage for the usual implementation headaches.
  6. Don’t hesitate to include the financial assessment as a set of annexes, but if you do always provide executive summaries.
  7. Don’t include impact to stock price unless you are fully prepared to go down that rabbit hole. Then be prepared to answer why the stock price of company X went up after a major hack.

Depending on the risk assessment model you choose, there may be relative terms used to determine risk. These won’t automatically have meaning to the board – or at least, not every board member will interpret such relative words the same way. But speaking in terms of money will hold the same meaning to everyone in the room.

When conveying the risk assessment results and financial implications of that risk, it is also important to verbalize the “why:” Why this assessment was chosen; why the risk is low, medium or high; etc.

Answering “why” questions will set you up for “What’s Next.” If your risk ends up being higher than acceptable, what next steps will be taken and what do you need to take those steps. Making the current situation clear and concise is the best way to bring everyone in the room along the risk journey with you, ending in the most productive place to minimize your risk in the cloud.

To learn more about assessing and managing cyber risk, check out these resources:

Leave a comment

[mc4wp_form id="491"]

[mc4wp_form id="491"]

ThemeREX © 2022. All rights reserved.

ThemeREX © 2022. All rights reserved.

Read on: 

The Samba Vulnerability: What is CVE-2021-44142 and How to Fix It

An earlier version of an out-of-bounds (OOB) vulnerability in Samba was disclosed via Trend Micro Zero Day Initiative’s (ZDI) Pwn2Own Austin 2021. While we have not seen any active attacks exploiting this vulnerability, CVE-2021-44142 received a CVSS rating of 9.9 out of the three variants reported. If abused, this security gap can be used by remote attackers to execute arbitrary code as root on all affected installations that use the virtual file system (VFS) module vfs fruit.

White House Cybersecurity Official in Europe Warning of Russian Hacks

Russia could use cyberattacks as part of its efforts to destabilize and further invade Ukraine, a White House cyber official visiting her European counterparts said. Anne Neuberger, U.S. deputy national security advisor for cyber and emerging technology, met with European Union and NATO officials in Brussels to discuss the threat of cyber-attacks against Ukraine by Russia.

Conti and LockBit Make Waves with High-Profile Attacks: Ransomware in Q4 2021

Ransomware actors were intent on punctuating 2021 with a wave of high-profile attacks. Trend Micro zeroes in on LockBit and Conti ransomware operators: two groups that worked overtime in the final quarter of 2021, as evidenced by the modern ransomware campaigns that they launched against different organizations in various countries.

Samba ‘Fruit’ Bug Allows RCE, Full Root User Access

Samba is an interoperability suite that allows Windows and Linus/Unix-based hosts to work together and share file and print services with multi-platform devices on a common network, including SMB file-sharing. Gaining the ability to execute remote code as a root user means that an attacker would be able to read, modify or delete any files on the system, enumerate users, install malware (such as cryptominers or ransomware), and pivot to further into a corporate network.

Codex Exposed Helping Hackers in Training

This is the fourth and final installment of Trend Micro’s series analyzing Codex. In this blog, Trend Micro analyzes how useful the Codex code generator is as a potential training tool and what possibilities a coding assistant offers to hackers in training.

Inside Trickbot, Russia’s Notorious Ransomware Gang

Internal messages shed new light on the operators of one of the world’s biggest botnets. The documents include messages between senior members of Trickbot, dated from the summer and autumn of 2020, and expose how the group planned to expand its hacking operations. They lay bare key members’ aliases and show the ruthless attitude of members of the criminal gang.

BlackCat Ransomware Implicated in Attack on German Oil Companies

An internal report from the Federal Office for Information Security (BSI) said the BlackCat ransomware group was behind the recent cyberattack on two German oil companies that is affecting hundreds of gas stations across northern Germany.

$320 Million Stolen from Wormhole, Bridge Linking Solana and Ethereum

Wormhole, one of the most popular bridges linking the Ethereum and Solana blockchains, lost about $320 million in an apparent hack Wednesday afternoon. The two blockchains are popular in the world of DeFi, where programmable contracts can replace lawyers and bankers in some transactions, and NFTs, but few users stick with one blockchain exclusively, so bridges like Wormhole are a necessary go-between.

Cyberattack Hits German Service Station Provider

The company this afternoon confirmed to The Register that Oiltanking GmbH’s terminals – which provide Shell service stations, among others – are “operating with limited capacity” and that Mabanaft GmbH had “declared force majeure for the majority of its inland supply activities in Germany.” Shell has additional providers, however, and said it had “diverted operations to other suppliers to minimise disruption.”

What do you think about the threat of Russian cyberattacks against Ukraine? Share in the comments below or follow me on Twitter to continue the conversation: @JonLClay.