Multi-cloud security starts by defining a security baseline

Nixu Blog

September 7, 2020 at 09:00

A cloud environment can become very complex even when it's built on one cloud platform only. Securing it may not be a simple task if you want to ensure that all subscriptions or accounts have the same security baseline, and any deviations are addressed. When you've built a multi-cloud ecosystem encompassing several cloud platforms, securing it all becomes an even more significant effort. How to get the security settings aligned? After all, all cloud platforms have slightly different terminology and features. How to monitor all the assets? How to know that the security requirements were implemented correctly? Teemu Kääriäinen, our leading cloud security specialist, and Matti Suominen discussed multi-cloud security at our Cyber Coffee webinar.

Start with a security baseline

There are many sources for cloud security requirements. Your organization's information security management system (ISMS), such as ISO 27001, introduces requirements that should also be met in the cloud. Or maybe you want to comply with the Cloud Security Alliance's Cloud Control Matrix (CSA CCM) or the Finnish PiTuKri? Then there are best practices specific for each platform, such as AWS Well-Architected. 

The first thing you should do is map out what these requirements mean in terms of settings and features of different cloud platforms. General demands like "multi-factor authentication must be used for administrative users" need to be mapped to specific features and settings in each cloud platform. After that, the requirements become actionable – the corresponding feature is either on or off, and compliance of the environment can be maintained and validated.

When you're starting to secure a multi-cloud setup, the first thing you should do is map out what all your security requirements mean in terms of settings and features of different cloud platforms.
When you're starting to secure a multi-cloud setup, the first thing you should do is map out what all your security requirements mean in terms of settings and features of different cloud platforms. 

Teemu reminds us that if you need to deviate from the requirements, for example, to save costs, you can use parametrization to do that easily. However, there should be sound reasoning behind the difference, especially if you're weakening the security posture. 

Threat modeling should be the basis for choosing when a less secure profile is appropriate. If a threat is not present in a specific situation, it's reasonable to limit controls. Leaving compliance alerts to the list because it was agreed that they don't matter is lousy practice. If the warning is not relevant, make the change in profile and ensure that only relevant findings pop up for any given environment.

How to make sure everything is correct?

It's a whole other thing whether the security requirements are implemented correctly and that the security status stays on the right level. Teemu and Matti emphasize that there may be a disconnect if a separate security team does the security testing, and the development team fixes the findings. Native security tools, such as AWS Security Hub or Microsoft Graph, will remove this disconnect: development teams will already have access to these tools and have the competence to use them. They will get visibility to the findings and use already familiar ways of working.

Security monitoring for the cloud is not so easy

Most Security Operations Centers (SOC) are familiar with monitoring environments consisting of workstations and virtual machines. Monitoring the cloud introduces a few challenges. First of all, agent-based monitoring tools don't follow up with the cloud, since the environments are dynamic and new assets come and go based on need. Secondly, the cloud platforms' native threat detection solutions may pre-process alerts, so they're not exposing all the data to an external SOC. While this is ideal when a human user is directly working with the alerts, it may leave out a lot of the data that SOC needs to correlate events or dig in deeper. Lastly, the SOC staff may not be familiar with all the latest bells and whistles of a particular cloud platform, making it more challenging to interpret the alerts or act on them. Thinking of the cloud only as a different kind of set of servers misses what really makes the cloud valuable.

Did you miss the webinar? Watch the recording!

Teemu and Matti also discussed the importance of threat modeling, how automation helps get the security baseline right, and the balance between securing the platform and securing an application running on it. If you missed the webinar, watch the recording from the video below.

Want to keep track of what's happening in cybersecurity? Sign up for Nixu Newsletter.

Related blogs