Has Your Cloud Been Breached!?

Why You Need A Cloud Security Posture Management (CSPM)

Sticking with one cloud provider may be an option for some, but others are discovering, multi-cloud infrastructure may be required. With this comes complications, both with knowledge gaps and integration.

You may not have admins with cross-cloud knowledge and/or your monitoring tools may not cross over to certain aspects. These problems create security risk. This is where CSPMs come in.

What is a CSPM

This video is a nice and quick video that fully explains what a CSPM is:

Whilst your organisation matures, the CSPM can help prioritise certain “holes” that may need attention. CSPMs also offer a layer of malware protection, however, this is nothing compared to an actual threat protection solution such as an EDR or NextGen AV.

Instead, it should be looked at as a way to identify common patterns and areas of focus. For example, if you have a high number of warnings that all relate to open storage, then this is a reflection that you don’t have enforcement policies in place. If you do, they may not be as effective as you would like.

If you start to notice that disks aren’t encrypted, or auditing isn’t enabled, this again may be something you want to look at a high level instead of fixing one by one.

Long Term…

Whilst CSPMs may be expensive, it doesn’t have to be a long game plan. If you have the funds or time for a trial, go there. If you have money in the bank for one year; do it.

The takeaway from implementing the solution is to start to create and enforce policies using native or third-party tools. If your strategy is not to renew the CSPM, obviously opt to create enforce policies outside of the platform. All clouds have native toolings to enforce standards, it just takes time and effort.

For the documentation and processes you define with the findings, look to keep them generic or more aimed at the native cloud, rather than via the CSPM.

Short Term…

The short-term plan should be to fix and document all HIGH and Critical findings. These should come with lessons learnt actions. Companies are getting breaches through open holes due to misconfiguration, so it’s important to spot and then take note. By documenting and implementing “standards” within your written processes and enforced policies, you can bolster you protection for the long game.

Always try to design a policy as a hard block, whilst at the same time, making an easy-to-follow exceptions process. This will reduce friction and put more responsibility on the requester.

Is it worth it?

Yes, but have a plan. You need to free up resources to be able to action items. If you are going into this during a busy period, there is little point. This will only overwhelm your team and have the opposite effect. Whilst you may spot holes, it will become a worry to those sitting at the top, as the org hasn’t taken the time to understand the product. They will just see red lights and start seeing emails.

Those stats will scare anyone, especially when your tool is showing criticals or highs. As with anything in Security, those criticals don’t fully reflect the truth, so you are going to need someone to be able to translate them into fact.

We all have DEV environments or have “exceptions” to security controls (Hopefully recorded in your ticketing system). Be prepared that whatever CSPM you implemented, it’s not going to know about them. IT WILL FLAG THEM.

Again, stay calm and fully understand what the alerts are telling you.

SecOps has this…

Nope. I would stop there. Although CSPM will fall under governance and security, this will need to be a “cloud” process that all cloud admins, including developers, will need to be involved with. Why?

Because it’s going to pick up on things that the SecOps team couldn’t know. A lot of misconfiguration is around data and solutions, so it’s important to understand how they actually work in order to create a resolution.

Will the SecOps people have this? Most likely not. They will have too much on their plate to know everything and anything. Whilst they could most likely figure it out, they shouldn’t have to. Looking at config and logs is a wasted effort if you have someone that could just tell you what’s what.

It will be application owners you need bring in. If you have AppSec leads or even purely application leads, you will get a better outcome. It’s going to be a team effort, and locking down the cloud is going to be hard. It is better if all parties are on the same train.

With this relationship comes shared access. Whilst normally you aim to restrict security portals to only SecOps/Governance, it will benefit you more to bring in other teams. They can then manage and have visibility of the technologies they are using and what configuration/direction they should move towards.

Why is it so hard to lock down the cloud?

In my opinion it’s because the cloud promises a playground of endless possibilities. It’s sort of like going to the park with a child and telling them what they can and cannot do. They may know what they are doing, and will most likely stay safe, however as a parent you can’t help but shout “Noooo” every once in a while.

On-premise was sort of easier as most were built during a time when perimeter security was hot. Everyone was aware they couldn’t do anything they would like, so controls were understood and better accepted.

The sweet spot…

The sweet spot is developing a culture rather than a tool. Sure, you should invest in automation as much as possible and offload manual efforts to encoded policies however the main take away is trying to mould your team into implementing secure resources. A tool can flag something all day, however, if you have a team with the knowledge of implementing secure models and resources, you will become less likely to find misconfiguration.

If you’ve spent your time wisely you will also have defined processes to fix those patterns as I mentioned earlier. Keeping those criticals and highs down will filter down to the mediums and lows. For example, if you secure the network layer, the data security aspect will be less at risk (Even if exposed). unencrypted data, with limited network access, is better than unencrypted data with large network access. Sure you will want to encrypt that data, but you may have other priorities.

If you’ve read that and said “You should just encrypt the data”, you may have missed the point. If you’ve worked with these tools or SecOps/Governance before, you will know you have 1 million things on your plate. Whilst you would like to do the easy stuff, you will most likely have something more important causing you to be on that 6th coffee of the day.

Did I mention cost savings?

It’s not always just the security aspect. Some of it may be identifying drift away from your standards. Identifying them may bring them into alignment and therefore save you cost. You may also spot “tests” that can be removed, or legacy systems they prompt you to move away from.

Most CSPMs have inventory management, so it’s good to spread this out. Knowing what you have against the costings could help the business look to reduce volume. In doing so, there is less to protect and less to pay for = win-win!

If you enjoyed reading my content and want to support it, why not consider signing up and becoming a member. It’s $5 a month, for unlimited access to all stories on Medium. Join now! 🙂

You could also clap, should this provide some help!

Regardless, thanks for reading and take care! 🙂