Questions You Should Ask Yourself About Your Cloud Security

Business leaders and security professionals should also take the initiative to learn as much as possible about hackers’ motives and tactics.

Every day, hackers bypass security perimeters, cross arbitrary boundaries, and evade security solutions, ultimately getting the data they want without being detected. Josh Stella, Chief Architect at Snyk and founding CEO of Fugue, a SaaS company specializing in cloud security, explains why leaders should ask their security professionals to give them insight into their operational cloud environment, so they can justify security investments across all teams.

Your adversaries probably aren’t going to write books about their methodologies for you to study easily. So here are nine questions all senior executives (CISOs, IT directors, and CEOs) should ask about their cloud security—and that their cloud security teams should always know the answers to.

1. How noncompliant is our cloud environment?

No enterprise organization operating in the cloud has an environment that is 100% compliant with regulatory requirements and security policies. But those that secure the cloud properly know exactly where their environment is—and isn’t—compliant. They make sure exceptions really are exceptions to the rules, and they have a prioritized plan for bringing everything into compliance. You should always know where your cloud environment stands in terms of security and compliance. Your security team should regularly review the enterprise’s internal security policies to make sure they adequately account for your use cases and new attack vectors.

Learn about the process your team uses to detect noncompliant cloud infrastructure, the remediation process they have in place, and how long it takes to bring the environment into compliance.

2. How many vulnerabilities have we identified and remediated?

Your cloud security posture isn’t static, and it should improve over time as your team gets better at identifying and remediating issues. You should know how many misconfiguration-related vulnerabilities exist in your environment and how many are fixed each day. Since this work typically involves a lot of manual effort, including monitoring tools and ticketing systems, you’ll want to use automation to help your team handle the scale and complexity of modern enterprise cloud environments. Work with cloud security professionals who have domain expertise to understand how serious cloud breaches happen today, and use that knowledge to create policy as code that can automatically check whether the same conditions exist in your organization’s cloud infrastructure.

Policy as code is designed to check other code and running environments for unwanted conditions. This lets all cloud stakeholders work securely, without ambiguity or disagreement about the rules or how they should be applied at either end of the software development lifecycle.

3. How many vulnerabilities have we prevented from being deployed?

Knowing which vulnerabilities your security team detects and remediates in your cloud environment is just one piece of the holistic security puzzle. You also want to know what proactive steps the security team is taking to reduce the frequency of misconfigurations being deployed.

4. Is security built into your team’s continuous integration and continuous delivery (CI/CD) pipelines?

Does your team check infrastructure as code (the programmatic way to create and deploy cloud infrastructure) for misconfigurations and fix them before deployment, when it’s faster, easier, and safer to do so? If the answer here is “no,” perhaps infrastructure as code and CI/CD pipelines haven’t been adopted. But if they are in use, there should at least be a plan to secure these processes.

5. Are we securing the cloud API control plane?

All cloud breaches follow the same pattern: compromising the control plane. Application programming interfaces (APIs) are the primary driver of cloud computing; think of them as “software intermediaries” that let different applications interact with each other. The API control plane is the set of APIs used to configure and operate the cloud.

Hackers look for misconfigurations. Unfortunately, the security industry remains one step behind hackers because many vendors’ solutions don’t protect their customers from attacks targeting the cloud control plane. Frankly, most focus on checkboxes that help senior executives and security teams feel better—until they get breached. It’s security theater, and it’s far too common in our business.

Assessing the risk of any potential breach involving misconfigurations, application vulnerabilities, API keys in source code, and so on requires cloud security architecture expertise to identify and avoid design flaws that attackers exploit every day. Cloud security is about knowledge, and breaches happen when defenders lack complete knowledge of their environment and can’t prevent attackers from finding out what they know.

6. How much does security reduce productivity?

The cloud is about the speed of innovation, and security is the number-one factor limiting how fast teams can work and how successful digital transformation can be. Are application developers waiting for infrastructure they need to deploy? Are DevOps teams waiting for security to review and approve their infrastructure? Are your cloud engineers spending too much time on labor-intensive manual security and compliance tasks when they could be delivering more value to your company and customers? Regularly assessing developer and DevOps throughput will help identify bottlenecks caused by inadequate security processes that hurt productivity and morale.

7. How do we express security policy?

There are two answers to this question: your security policies are written in human language and reviewed by people, or you use policy as code. If the answer is the former, your cloud environments can’t be secure enough. Manually reviewing policies and enforcing them in your environment takes time, while cloud breaches take minutes. And the risks of human error and differences in interpretation are always present. With policy as code, machines interpret policy consistently every time, in real time. That means you can continuously assess far more cloud infrastructure than any army of people could ever hope to. If security policy enforcement needs to change from one deployment to another, you can express those exceptions in code so everything is well documented. When you implement security automation using policy as code, issues can be detected and remediated during development or deployment, before they go live in production.

8. How quickly can we respond to zero-day events?

The Log4j vulnerability earlier this year left security teams everywhere scrambling to respond. These kinds of “zero-day” events require teams to quickly and accurately assess existing vulnerabilities and their severity, so they can prioritize response and remediation efforts. Responding to zero-day exploits like these in applications requires teams to dig deeper than usual, since application vulnerabilities are often used to infiltrate cloud infrastructure environments and ultimately compromise the cloud control plane. Teams must be able not only to identify application vulnerabilities quickly, but also to assess the potential blast radius of each instance of a vulnerability, so they can determine its severity and remediation priority accordingly.

9. Do all teams have what they need to succeed?

There are no silos in modern enterprise security. Securing the enterprise takes an integrated approach that brings teams and cost centers together, and that takes leadership and sponsorship to get right. For example, a shift-left approach to security requires developers and DevOps to take on some responsibility for finding and fixing issues earlier in the software development lifecycle. But if security investments don’t reflect these new priorities, friction will arise and undermine the effort.