This post is also available in: 简体中文 (Chinese (Simplified)) 繁體中文 (Chinese (Traditional)) Nederlands (Dutch) Français (French) Deutsch (German) Italiano (Italian) 日本語 (Japanese) 한국어 (Korean) Español (Spanish)
Whether it’s the rapid pace of cloud provider innovation, the fluid shared responsibility model or the constantly evolving compliance mandates, cloud security seems challenging for many organizations.
But do you know what puts many organizations in harm’s way? (Hint: it’s not a shortage of security tools.) It’s not having a distinct security strategy for public cloud. Based on our work with hundreds of clients, we developed The Big Cloud 5. While not meant to be exhaustive, when resourced appropriately, it will help your team form a holistic cloud security strategy.
Figure 1: The Big Cloud 5
Lacking or inadequate situation awareness has been identified as one of the primary factors in accidents attributed to human error. – Nullmeyer, Stella, Montijo, & Harden, 2005
1. Gain awareness and deep cloud visibility.
The first step in making cloud security and compliance easier is to understand how your developers and business teams are using cloud today. This is where you make shadow IT your friend. Instead of being the bane of your existence, shadow IT becomes the critical insight required to move beyond conjecture to data-driven decision-making. Where’s the best place to look for this information? Firewall and proxy logs. While cloud usage via shadow IT is the first level of required detail, it’s necessary to go deeper. Following the 80/20 rule will allow your team to know which cloud platform to focus on first. However, security teams must understand not only which cloud platforms are in use but also what’s running inside them. This is where cloud provider APIs come to the rescue.
APIs are one of the key technologies that make cloud different from most on-premise environments. This is about getting and maintaining situational awareness of what's happening in your cloud environments. Think about understanding not only what cloud apps your organization is using but leveraging cloud provider APIs to constantly track changes down to the metadata layer. This is not a one-time event but something that should be constantly reviewed and monitored. Awareness becomes intrinsically harder unless your team takes advantage of cloud provider APIs. Think about it: developers are coding to the cloud providers APIs on a daily basis, and yet most security teams do not leverage them. This means there is a major gap in terms of visibility and control. Make sure a central tenet of your cloud security program entails harnessing the cloud provider APIs.
2. Set guardrails to automatically prevent the most serious of cloud misconfigurations.
Ask yourself, what are the configurations (misconfigurations or antipatterns) that should never exist in our environment? Think of these as your dirty dozen. An example would be a database receiving direct traffic from the internet. Despite this being a “worst practice,” Unit 42 threat research has shown this happening in 28% of cloud environments. A great place to start building your list would be Unit 42’s Cloud Security Trends report. Develop your initial list and expand these as your cloud security program matures over time. Two important caveats: any time protections are automated, it is strongly encouraged to start with small experiments to ensure there aren’t unintended consequences (e.g., a self-inflicted denial of service). The other area is working closely with your development teams. Do not attempt to put automated protections in place without gaining buy-in from your development teams. Work with development teams from day one, start small and ramp quickly.
3. Standards are the precursor to automation.
It's extremely difficult to automate what you haven't standardized upon. Don’t start from scratch. The Center for Internet Security, or CIS, has benchmarks for all major cloud platforms. Many teams talk about automation without having a security standard in place. A good goal is to target automating 80% of these over time. As your program settles on standards, the automation part will become more straightforward. Don’t expect to go from no automation to full automation in 90 days unless you are a startup. This process typically takes enterprise organizations at least nine months before they hit their stride. One thing to note: automating your standards is difficult to achieve if you don’t have security engineers who know how to code.
4. Train and hire security engineers who code.
Unlike most traditional data centers, public cloud environments are driven by APIs. Successful risk management in the cloud requires that security teams leverage APIs. APIs are difficult to utilize without having engineers on your security team who know how to code and automate security processes. Standards are great but without automation continuously enforcing them via policy they become one-time checks.
Depending on the size of your organization, start with an assessment of the skills that already exist today. Do you already have team members who know how to code in the likes of Python or Ruby? If so, invest heavily in these team members and align goals to your automation maturity timeline. Don’t already have someone on the team? Then you have several options. Look for those who want to learn and survey your development team for members who have shown an interest in security. Both can be trained; security for the developers and coding for the security engineer, if goals around training are aligned and resourced properly.
If your organization is not strong in coding, this might be a great project for a short-term consultant who has done this in many organizations before. If you choose to go this route, be sure to include knowledge transfer as a key deliverable in the statement of work. You don’t want to be left with scripts your teams don’t know how to modify or use. Once you have this process underway, you’ll be ready to fully embed security in your development pipeline.
5. Embed security in the development pipeline.
This is about mapping out the who, what, when and where of how your organization pushes code into the cloud. Once this is done, your goal should be to locate the least disruptive insertion points for security processes and tools. Getting early buy-in from development teams is critical. Your North Star for this final step is to minimize human interaction over time. This becomes more straightforward as your organization moves to infrastructure as code (IaC). Consider that as you organizationally limit the number of human hands touching what goes into your cloud environment, misconfigurations naturally get minimized.
Wrapping it up
Creating a holistic cloud security strategy doesn’t require throwing every part of your existing cyber strategy out the window. Much of what you do today is still relevant. How you go about it, however, is very different in public cloud. By building a cloud security strategy that is focused on “The Big Cloud 5," security organizations of all sizes will reap the benefits of public cloud that have long been only in the realm of development teams. Start small, ramp quickly.
To learn more about how Prisma™ can help improve your cloud security strategy, visit the Prisma Resource Center.