Five ways to prepare for management questions about cloud security

Imagine you’ve been called into a quarterly Board meeting. They want to know how things are going with the cloud. As you start the meeting, you notice how much more in tune they are with security than in times past. They are really asking some good questions. You had mentally prepared some answers to keep the spotlight off you, but it’s clear they are going to dig in.

How much are you spending on cloud security? How do you know we’re spending the right amount? Are you allocating resources in the right place? Who is watching our infrastructure 24/7? How long will it take you to detect a breach?

The reality is, these days, boards and management are more and more likely to ask this question of you. And, if you are a development team focused on innovation and advancing the product, there is a decent chance there is no one on your team 100% focused on security; or, your team spreads the security load but isn’t sure if they are using best practices. Nor do they have the time to figure them out. Hence, the sweat that appears in your palms at said Board meeting.

We’ve been there

At a company I co-founded in the early 2010s, I got questions like this all the team. We were building a software-as-a-service product in the healthcare tech space, all on AWS. My co-founders were not AWS-savvy (and at the time, I wasn’t either). So, questions routinely came up. Are we ok? What is the price we should put on “insurance” essentially? Being new to the cloud I didn’t know much about what constituted a risk. Do we do penetration testing? Port scanning? Phishing training? Do we buy AlertLogic for $10,000 per month? Do we need a security operations center?

Every question raised more questions. And the problem was, the pressure to turn out features never slowed down.

Turn cloud security into a standard ops, like your code pipeline

Well, there is a solution. While you cannot be 100% secure (the only way to be that, is to do nothing), with the right approach, it very quickly becomes a standard operations problem that any team can implement. All operations problems involve allocating finite resources in the best way, and then measuring performance on that investment.

Generally, spending in cloud security is targeted at ‘risk reduction’ not always cost reduction, or revenue generation. The Board will be thinking about cloud security in terms of risk reduction, and they will be looking for metrics they can hang onto.

Here are five ways to prepare for security questions from management

Nothing here is a big surprise.

1. Pick the most important metrics.

You need to already be measuring results. Believe it or not, there are great security metrics that can be tracked beyond “Did we get hacked? Yes or No”. For a younger team, you might pick a simple metric that just keeps you safe and is easy to see: no public AWS resources (like S3 buckets or EC2 instances). Or, no usage of the root account (the main, all-powerful account credentials). When the team becomes larger, you might start looking more closely at “bigger” metrics, such as mean time to resolution (described below). Once you have picked a few metrics, the team will change their behavior and they will be more top of mind.

2. Know your resolution time, or “Mean Time to Resolution”

The Mean Time to Resolution (MTTR) is how long it takes, on average, to fix a security issue once you find it. This is one of the most powerful metrics available, because it gives the entire company a sense of generally how long it will take to resolve a security issue of any kind. CloudSheriff provides this metric by default because we believe it is so important. It is not enough simply to report problems (or “findings” in cloud security parlance). This metric is powerful for your management to know, because it recognizes that security issues will definitely happen; the question is really, “what will you do about it?” You can set a goal to resolve “medium” severity issues in hours, and “high” severity issues in minutes. Think of this as a metric that tells the whole organization that you are competent and have things under control.

3. Now, tie your lower-level metrics (like MTTR) to higher level business aspirations in simple terms, like a red yellow green / “traffic light” chart.

For example, if your company has a high level initiative to improve your brand’s reputation, which would be tightly correlated to security concerns, you can show a “green light” given that your MTTR is on the order of minutes, which implies that the team is able to resolve any security finding quickly. This keeps it simple and maps your work to the Board’s biggest priorities.

4. Show your cross-functional cooperation.

Don’t just keep security in your development team. Show that your team is engaged cross functionally. Because when there is an incident, you must identify it, and communicate with PR, Communications, operations, and so on. Demonstrate your good working relationship to share the right kind of info, and for it to be trusted. This again will communicate confidence to your management.

5. Finally, show proactivity, NOT reactivity.

The last thing you want your team to be doing is to wait until an incident happens before they spring into action. Ironically, if you don’t have a proactive security posture at all, that means you’re not monitoring anything, and you may never even detect an incident in the first place. According to Bloomberg, 69% of SMBs experienced an attack that got past their intrusion detection system. That is a high number, but the good news is that they had an intrusion detection system in place to begin with. Do you? Your management’s confidence will grow if you can describe your proactive approach to monitoring.

At my last company, we became pretty good at this. Without knowing it, we were building capabilities called “devsecops” - security operations in the middle of development operations. Security became part of our code flow and, importantly, part of the team’s awareness. Since none of us were security experts, we developed overall policies that every developer had to stick with, like “everything must be tagged” and “all data must be encrypted”.

CloudSheriff takes those policies and turns them into code, so they are automatically applied as your team works. If your team violates a policy, they are notified. Then, you have the option for the mistake to be fixed automatically, known as “automated remediation”, or you can have the team study it for training. Contact us if you want to be more confident the next time upper management calls you in!