Holding public cloud security to account

At one of the last cyber-security events I attended before the Covid-19 enforced lockdowns, I was talking with an IT director about how his organization secures its public cloud deployments. He told me: “We have over 500 separate AWS accounts in use, it helps all our development and cloud teams to manage the workloads they are responsible for without crossover or account bloat, and it also makes it easier to control cloud usage costs: all the accounts are billed centrally, but each account is a separate cost center with a clear owner.”

I asked about security, and he replied that each AWS account had different logins, meaning fewer staff had access to each account, which helped to protect each account.

While it’s true that having hundreds of separate public cloud accounts will help to keep a closer eye on cloud costs, it also creates huge complexity when trying to manage the connectivity and security of applications and workloads.  Especially when making changes to applications that cross different public cloud accounts, or when introducing infrastructure changes that touch many – or even all- accounts.

As I covered in my recent article on public cloud security, securing applications and data in these environments can be challenging. It’s far easier for application teams to spin up cloud resources and move applications to them, than it is for IT and security teams to get visibility and control across their growing cloud estates.

Even if you are using a single public cloud platform like AWS, each account has its own security controls – and many of them. Each VPC in every region within the account has separate security groups and access lists: even if they embody the same policy, you need to write and deploy them individually. Any time you need to make a change, you need to duplicate the work across each of these elements.

Then there’s the question of how security teams get visibility into all these cloud accounts with their different configurations, to ensure they are all properly protected according to the organization’s security policy. It’s almost impossible to do this using manual processes without overlooking – or introducing – potential vulnerabilities.

So how do the teams in charge of those hundreds of accounts manage them effectively? Here are my three key steps:

1. Gain visibility across your networks

The first challenge to address is a lack of visibility into all your AWS cloud accounts, from one vantage point. The security teams need to be able to observe all the security controls, across all account/region/VPC combinations.

2. Manage changes from a single console

The majority of network security policy changes need to touch a mix of the cloud providers’ own security controls as well as other controls, both in the cloud and on-premise. No cloud application is an island that is entire of itself – it needs to access resources in other parts of the organization’s estate. When changes to network security policies in all these diverse security controls are managed from a single system, security policies can be applied consistently, efficiently, and with a full audit trail of every change.

3. Automate security processes

In order to manage multiple public cloud accounts efficiently, automation is essential. Security automation dramatically accelerates change processes, avoids manual processing mistakes and misconfigurations, and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations.

With an automation solution handling these steps, organizations can get holistic, single-console security management across all their public cloud accounts, as well as their private cloud and on-premise deployments – which ensures they can count on robust security across their entire IT estate. 

About the author: Professor Avishai Wool is the CTO and Co-Founder of AlgoSec.

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/3kG1zSq"