From time to time, when striving to implement new ways of operationalizing cloud security, you come across another person who thinks just like you, and it's only then you begin to truly realize your idea.
Working in a team with a common goal is beneficial, even if it's just two parties. In fact, it can be revolutionary – think of Bill and Paul at Microsoft, Larry and Sergey at Google, and of course Steve and Steve at Apple.
For me, working in a team usually means working very closely with architects or engineers from customer and partner organizations. And that's where the magic can happen. When everything works well, we generate new ideas and perspectives. More importantly, the team contributes greater value to everyone's objectives than we each could individually.
Clearly, working in a team can be highly productive. However in security, we have traditionally separated ourselves, largely due to the way we've had to implement visibility and controls.
Historically, when you were implementing and operationalizing cloud security at an organization, it had to be deployed between one thing and another thing, or it had to be deployed onto something or listening to something. An application or software had to be something, it had to be 'living' and probably talking to another thing, or an exploit had to be able to run on it – it had to exist in its final form before security controls could initiate. And that's just the way it was for a long time.
I recall visiting a security convention a few years ago, and security vendors all had the same story. "Let me show you a risk in runtime that you hadn’t seen before, and then conclude by helping you control it."
Now, the ‘shift left’ security trend finally has the industry aligning with the way applications have been developed and deployed for a long time. Sure, there have been recent changes in the way applications are built that make shifting left more feasible. However, the majority of the security industry had been shamelessly ignoring the early parts of the development lifecycle either way, opting instead to focus on the 'living' something.
Thankfully, the industry now truly recognizes that security can be implemented at any phase of the lifecycle. And there are some fantastic techniques and technology out there to help do so.
One recent example of these fantastic techniques comes from an opportunity I had to support a customer with a very clear, and very lofty, objective: achieve a model of operationalized cloud security, at a scale like nothing seen before.
While this customer had been adopting cloud and cloud native technologies at some scale already, they had made a recent decision to fully adopt it across the business. As such, they had placed a huge emphasis on the cloud for all their existing and new applications – which equated to thousands of internal and external services.
Admittedly, this type of transformational journey has been around for years. In fact, these days it's rare that a transformation doesn't happen at this scale; and even in those cases it's typically related to privacy constraints or operational requirements rather than lack of appetite for change.
Using automation to operationalize cloud security like this is not new either. The security industry has spent a lot of time and effort focusing on automated response. We’ve worked out how to manage millions of alerts and events, and how to remediate them easily using SOAR tools. This has allowed us to focus back on defining policies again. However, there is an efficiency limit to manual policy creation.
It wasn't the scale of the project or their decision to bake security into the application lifecycle that made this engagement special. It was the fact that they had the foresight to automate the policy authoring component to enable security guardrails when establishing new application environments, even before the environments were provisioned.
What really stands out from that engagement was the way the customer thought about security like an application.
In creating an application, you start to develop code, allow additions and enhancements as you go, perform testing and quality assurance, define policies for deployment and eventually release to production, then continue to monitor it and make changes as required. Additionally, you also likely deploy your app as a microservice to aid the process of doing this quickly and at scale. Ok, so this is a crude, short description of the application lifecycle, but fundamentally apps are made of policies and code.
You can think of security in the same way. Think of making security policies as development, and your application as the code. For additions and enhancements, you can think of better ways to develop new policies. You can perform testing and quality assurance using security platform API’s or SDK’s.
For the customer in this example, this is now done using a dedicated Terraform Provider, which provides the interface needed to create and orchestrate the testing and deployment of new security policies. The Terraform Provider is then leveraged by a continuous integration (CI) tool to drive the creation, testing and roll out of hundreds of security policies per new application environment.
The value of this 'security development lifecycle' is immense. They are able to develop new policies, review existing ones, test them, and then include them as part of application environments without having to go to a UI or wait for an alert to show up (or not show up if the policy has been created incorrectly).
About the same time I was working on that customer engagement, I also came across a consulting partner that thinks in a similar way – they look at the solution from all perspectives, not just security. They look for parallels in app development and security development. And just like the customer above, the result is pure magic.
Being biased towards the security part, the partner implements controls using Prisma Cloud to check for underlying vulnerabilities in package dependencies across applications. They check that infrastructure-as-code (IaC) templates won't instantiate an insecure application environment, scan Amazon Machine Images (AMIs) for vulnerabilities, and scan container images in CI tools and registries for underlying vulnerabilities or compliance issues.
They also use Prisma Cloud to remediate security issues throughout the entire lifecycle, including when the application is running. All of which is done natively within SCM, IDE’s, CI tools, registries, container clusters, public cloud services and more.
My experience with such progressive customers and partners has provided a helpful peek into working examples that show how security can be baked-in from day zero, in the way we’ve envisioned for a long time. And perhaps more importantly, I've seen that security can indeed be scalable without being a blocker to progress.
The perspectives and ideas gained by working as a (virtual) team with customers and partners allows us all to grow more than we could on our own. And this same idea applies when thinking about ways to operationalize cloud security by wearing your 'developers hat.'
If you are a developer, you're likely striving to continuously streamline the way in which you manage code and define policies. In security, we should strive to think the same by enabling our policies to be built, shipped and run as code.
For more thought leadership on digital transformation projects, please join us virtually on April 27, 2021 for Spectrum by Prisma Cloud. the industry’s only cloud security event that meets you where you are on your cloud journey. We'll provide helpful insights and actionable advice to accelerate your journey across the cloud spectrum.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.