FREDERICK, Md.--(BUSINESS WIRE)--In a brief video explainer and commentary, Josh Stella, chief architect at Snyk and founding CEO of Fugue, a developer-first cloud security SaaS company, advises business and security leaders on why relying on “checkbox security” approaches in the cloud leaves them vulnerable to attack.
In order for business leaders and cybersecurity professionals to gain the knowledge they need to thwart the hackers constantly targeting their cloud infrastructure and applications, they need to think like General George S. Patton (or rather like George C. Scott, the actor who won the Best Actor Oscar for his portrayal of the general in the 1970 film “Patton”).
In an early scene, the camera focuses on a book Patton is reading by German General Erwin Rommel. The point is to show how Patton does not rely solely on military intelligence to plan the next battle. He’s being proactive in learning as much as he can about how his adversary thinks and operates. The next scene depicts Patton’s troops launching a devastating attack on German tanks and infantry. Peering through his binoculars, Patton smiles and yells “Rommel, you magnificent (expletive), I read your book!”
So too must business and security leaders be proactive in gaining as much knowledge as they can about hackers’ motivations and tactics. Do not rely only on what your security solutions are telling you because that will only give you a false sense of security. Every day, hackers are sidestepping security perimeters, crossing arbitrary boundaries, and evading security solutions to ultimately get at the data they want without detection.
Your adversaries are probably not going to write books about their methodologies for you to study. So, here are nine questions that all senior executives (CISOs, CIOs, CEOs) need to ask about their cloud security and that their cloud security teams should know the answers to at all times.
1. How out of compliance is our cloud environment?
No enterprise organization operating in the cloud has an environment that’s 100% in compliance with regulatory and security policies. But those that are doing cloud security correctly know exactly where their environment is and isn’t in compliance. They ensure exceptions are just that: exceptions to the rule, and they have a prioritized plan for bringing everything into compliance.
You should know at all times where you stand regarding the security and compliance of your cloud environment. Your security team should regularly review internal enterprise security policies to ensure they’re adequately addressing your use cases and emerging attack vectors. Understand the process your team uses for discovering out-of-compliance cloud infrastructure, the remediation process they have in place, and the time it takes to bring an environment into compliance.
2. How many vulnerabilities did we identify and eliminate?
Your cloud security posture is not static, and it should improve over time as your team gets better at identifying and remediating issues. You should have information on how many misconfiguration vulnerabilities exist in your environment and how many are remediated per day.
Because this effort generally involves a lot of manual work comprising monitoring tools and ticketing systems, you’ll want to leverage automation to help your team address the scale of complexity involved in modern enterprise cloud environments. Work with cloud security professionals with domain expertise to understand how modern major cloud breaches happen and use that knowledge to create policy as code (PaC) that can be used to automatically check whether those same conditions exist in the organization’s cloud infrastructure. PaC is designed to check other code and running environments for unwanted conditions. It empowers all cloud stakeholders to operate securely without ambiguity or disagreement on the rules and how to apply them at both ends of the software development life cycle (SDLC).
3. How many vulnerabilities did we prevent from being deployed?
Knowing which vulnerabilities your security team is discovering and remediating 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 from being deployed. Failing to “shift left” on cloud security ensures that there will be an uninterrupted flow of cloud vulnerabilities into your environment — and a security team playing an endless game of whack-a-mole.
Does your team have security built into continuous integration and continuous delivery (CI/CD) pipelines? Is your team checking infrastructure as code (a means of building and deploying cloud infrastructure programmatically) to find and fix misconfigurations pre-deployment, when doing so is faster, easier and safer? If the answers here are “no,” it may be that infrastructure as code and CI/CD pipelines haven’t been adopted. But if those are in use, there should at least be a plan to build security into these processes.
4. Are we securing the cloud API control plane?
All cloud breaches follow the same pattern: control plane compromise. The control plane is the application programming interfaces (APIs) surface that configures and operates the cloud. APIs are the primary driver of cloud computing; think of them as “software middlemen” that allow different applications to interact with each other. The API control plane is the collection of APIs used to configure and operate the cloud.
Hackers do look for misconfigurations. Unfortunately, the security industry remains a step behind the hackers because many vendor solutions do not protect their customers against attacks that target the cloud control plane. Frankly, most of them focus on the check boxes that make senior executives and security teams feel better — until they’re hacked. It’s security theater that is all too prevalent in our business.
Assessing the blast radius risk of any potential penetration event due to misconfiguration, app vulnerabilities, API keys in source code, etc., requires expertise in cloud security architecture to identify and avoid the design flaws that attackers exploit every day. Cloud security is about knowledge, and breaches occur when defenders lack full knowledge of their environment and fail to deny attackers discovery of that knowledge.
5. How much drag on productivity is security creating?
The cloud is all about innovation velocity, and security is the number one rate limiting factor for how fast teams can go and how successful digital transformation can be. Are application developers waiting around for the infrastructure they need to deploy? Are DevOps teams waiting around for security to review and approve their infrastructure? Are you investing too many cloud engineering hours on time-consuming manual security and compliance tasks when they could be creating more value for your company and customers?
Regularly measuring developer and DevOps throughput will help identify delays due to insufficient security processes that put a drag on productivity — and morale.
6. How are we expressing security policies?
There are two answers to this question: Your security policies are written in human language and reviewed by humans, or you’re using PaC. If the answer is the former, your cloud environments cannot be adequately secure. It takes time to manually review policies and enforce them in your environment at a time when cloud breaches take minutes to execute. And the risk of human error and differences in interpretation is always present.
With PaC, machines will accurately interpret a policy the same way every single time in real time, which means you can continuously evaluate far more cloud infrastructure than any army of humans could ever hope to do. If the application of the security policy needs to change from one deployment to another, you can express these exceptions as code so everything is well documented. When you implement security automation using PaC, problems can be found and fixed in development or deployment, prior to reaching production.
7. How quickly can we respond to zero day events?
The Log4J flaw earlier this year sent security teams everywhere scrambling to respond. These kinds of “zero day” events require teams to quickly and accurately assess where vulnerabilities exist and their severity in order to prioritize your response and remediation effort. The reaction to such application zero day exploits requires teams to go deeper than they typically do because app vulnerabilities are often used to penetrate the cloud infrastructure environment — and ultimately compromise the cloud control plane.
Teams need to not only be able to identify application vulnerabilities quickly but also to assess the potential blast radius that each instance of the vulnerability presents in order to assign severity and prioritize remediation accordingly.
8. Do all teams have what they need to succeed?
There are no silos in modern enterprise security. Security requires an integrated approach that cuts across teams and cost centers, which demands executive leadership and sponsorship to get right. For instance, a shift left approach to security requires developers and DevOps to take on some responsibility to find and fix issues earlier in the software development life cycle. But if security investment doesn’t reflect these new priorities, there will be friction that puts the effort in jeopardy.
Security success hinges on executive sponsorship with adequate investments of both budget and time.
9. What will failure look like?
Beyond CISOs, I see far too few executives really asking themselves this question. It’s not hard to imagine — consider the cloud breach that hit Imperva, a major security product company themselves, which ultimately resulted in the CEO stepping down. Then there’s the Capital One breach, still one of the largest ever to hit a big financial institution. And the Twitch breach earlier this year, which affected not only Twitch but also parent Amazon. Unlike General Patton’s defeat of General Rommel, there won’t be any victories for business leaders, just the constant quest to prevent failure.
Cloud security is an eternal undertaking, like joining a gym and being rigorous about consistently using that membership to get and stay in shape. You need to implement a policy requiring consistent reporting about your organization’s cloud security posture. You don’t want to wrestle with questions about what’s being done to identify and remediate vulnerabilities, how many were eliminated last week or last month, and where you may be exposed to a new vulnerability that’s making news headlines — you want answers.
About Josh Stella
Josh Stella is chief architect at Snyk and a technical authority on cloud security. Josh brings 25 years of IT and security expertise as founding CEO at Fugue, principal solutions architect at Amazon Web Services, and advisor to the U.S. intelligence community. Josh’s personal mission is to help organizations understand how cloud configuration is the new attack surface and how companies need to move from a defensive to a preventive posture to secure their cloud infrastructure. He wrote the first book on “Immutable Infrastructure” (published by O’Reilly), holds numerous cloud security technology patents, and hosts an educational Cloud Security Masterclass series. Connect with Josh on LinkedIn and via Fugue at www.fugue.co.
About Fugue
Fugue (part of Snyk) is a cloud security and compliance SaaS company enabling regulated companies such as AT&T, Red Ventures, and SAP NS2 to ensure continuous cloud security and earn the confidence and trust of customers, business leaders, and regulators. Fugue empowers developer and security teams to automate cloud policy enforcement and move faster in the cloud than ever before. Since 2013, Fugue has pioneered the use of policy-based cloud security automation and earned the patent on policy as code for cloud infrastructure. For more information, connect with Fugue at www.fugue.co, GitHub, LinkedIn and Twitter.
All brand names and product names are trademarks or registered trademarks of their respective companies.
Tags: Fugue, Snyk, cloud security, SaaS, compliance, Josh Stella, policy as code, cybersecurity, cloud, cloud security automation, cloud control plane, network configuration, cloud configuration, cloud misconfiguration, data breach, hackers, application programming interface, API, cloud policy enforcement
