Risk Management
How to Present Cloud Risk to the Board
Trend Micro Security Researcher, Erin Sindelar, breaks down three popular types of cloud risk assessments to help CISOs and security leaders better explain cyber risk to the board.
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:
- It’s not very dynamic (read: slow and misaligned with the speed of cloud development).
- 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:
- 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.
- 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 amongst 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 organisation 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 organisation 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- Don’t hesitate to include the financial assessment as a set of annexes, but if you do always provide executive summaries.
- 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 verbalise 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 minimise your risk in the cloud.
To learn more about assessing and managing cyber risk, check out these resources: