Effectively Managing Security Challenges in Multi-Cloud Deployments
In our last blog we looked at who is responsible for securing the public cloud. This time we are looking at how to tackle the security challenges associated with multi-cloud deployments. Many organisations are either strategically electing to use services from multiple cloud providers or have found themselves needing to as a side-effect of different departments already having procured the services they need in isolation.
Where the die has not already been cast, companies planning their strategic approach to cloud typically focus on one of the three major players: Google, AWS or Azure. Thereafter, the carefully selected ‘provider of choice’ is trained-out internally and learned by staff so they can build the plethora of architectural and security features into their respective operational workflows.
If only life was so simple!
In reality a business unit will pop up (or security teams will discover) a new cloud requirement: “Provider X just launched a new feature which directly addresses our business requirement….can we get access this week?”, and expect the IT and security teams to figure out how everything they’ve purpose built for their primary cloud can be re-purposed for use in the new provider’s infrastructure.
For security teams who are relying on legacy tools or native security features of their primary cloud platform, this is a major challenge. How does AWS GuardDuty or AWS Config help you to secure Google or Azure clouds?
Simple answer? They don’t.
o how should a security team proactively address the multi-cloud security challenge while not getting caught up in the morass of ever-changing individual cloud provider offerings?
Understanding the differences in cloud security requirements is key.
In our conversations with customers there is almost always one universal thread no matter where they are in their cloud journey; how do we enable the business to operate with freedom in the cloud but also put the proper guardrails in place to prevent exposure from unnecessary risks?
As discussed in the last blog Securing the Public Cloud a fundamental understanding of the shared security model is key as this is the main differentiator when compared to legacy on-prem environments. Once this model is understood and clearly documented and agreed in an organisational RACI, we recommend customers conduct a cloud risk assessment for a clearer understanding of how your current security processes and tools you’ve already invested in help manage risks today.
Unfortunately, many organisations skip this step and move directly to design and build phases, which is a fatal mistake. Why? Because it inevitably leads to security teams attempting to rebuild their on-prem security model in the cloud and completely miss the opportunity to transform their security program in the process.
Delivering Effective Security in a Multi-Cloud Environment
Staying secure in a multi-cloud environment can be challenging given the different features available between the different cloud providers. Rather than focus on features therefore, we believe that the best place to start is with a trusted security standard.
Trying to design a standard from scratch is probably the last distraction most cloud-hungry organisations want (though in the longer term many organisations will want to push for their own corporate standards), so we highly recommend starting with the Center for Internet Security’s Benchmarks who have freely available benchmarks for all three of the primary cloud service providers.
While standards may not be the most exciting part of security they have the added benefit of being the precursor to automation. Put simply, you cannot automate what you have not standardised first – once a standard has been agreed you can then begin to measure yourself against it over time and work towards automation…but not without first making things as simple as possible.
Simplifying Your Multi-Cloud Security Strategy
Simplicity is key when it comes to solving most challenges and multi-cloud security is no exception. When it comes to simplifying your multi-cloud security strategy there are three key things to keep in mind:
2. Reducing cloud vendor lock-in
3. Streamlining alerts and tools
While each of the cloud vendors provide well thought-out native security technologies within their platforms, when it comes to anything outside their ecosystem they have little incentive to provide the visibility you need in a multi-cloud strategy. Look for security tools that are provider agnostic and support, at a minimum, Google, AWS and Azure clouds. Given the ‘round-the-clock’ nature of cloud operations, it is also critical that this visibility is constantly reflecting changes in your cloud environments 24x7x365.
Reducing Cloud Vendor Lock-in
A large driver behind the continuous development of new products and services in each cloud provider’s portfolio is to keep you squarely locked into their platform. When it comes to cloud security however, teams must take the long view that while today AWS might be your de facto cloud platform today, it is very likely that GCP and Azure will be a part of your future (and are likely already in your environment already, but that’s a topic for another post). This is why we recommend engaging with security providers who’s best financial interests are not with a single cloud but rather in the most diverse set of providers.
Streamlining Alerts and Tools
Your SOC is already dealing with alert fatigue and if your cloud security strategy is to be successful it is important to avoid adding to their stress. Identifying requirements for security controls and reducing the number of tools your SOC needs to investigating cloud-based incidents is one key way this can be achieved. If your team is relying mainly upon the native cloud provider tools or is attempting to build their own with open source or SIEM tools they will likely spend more time customising these for the near weekly changes cloud providers make rather than focusing on reducing risk and enabling the business to quickly consume new cloud features. Alongside providing a single source of insight across offerings from all cloud providers, tooling should do as much as possible to automate security processes to further allow analysts to focus on the things that demand their intervention.
Even cloud solutions hosted within a single provider can represent a significant challenge to secure. The always-on and constantly changing nature of the cloud provider’s offerings and your own internal usage (DevOps can spin hundreds if not thousands of workloads up and down in a single month) means that automation is most likely your only hope of keeping on top of the way your cloud interests are configured and operated.
When looking to simplify your multi-cloud security strategy it is critical that security executives and their teams maintain visibility into all of the cloud environments in use, prepare for the future by reducing cloud vendor lock-in and streamline tooling to unify visibility and control whilst also harnessing automation to allow analysts to quickly and effectively get on top of security incidents across the organisation’s cloud interests.
This is where cloud agnostic security tools such as the RedLock Cloud 360 Platform from Palo Alto Networks can really help. RedLock provides a single location where security teams can gain visibility across Google, Azure and AWS while freeing these teams from the chains of home-grown, open source or native cloud provider tools.
Speak to Gyrocom today to secure your cloud deployments.
Gyrocom is a network and security company. We support your digital transformation with secure, automated and simple to manage solutions for the data centre, branch office and cloud.