How to manage the lifecycle of CSPM policies ?

As a mature cloud organization, you have already implemented a Cloud Security Posture Management (CSPM) with a set of security policies. Your teammates are now familiar with the CSPM, everyone is tracking the same KPIs… but the cloud is evolving: new Cloud Service Provider (CSP) services are being deployed or new security controls exist. Your company may also decide to opt for these new CSP services. But how can all these new services be monitored? How do you manage the lifecycle of all the new policies you are going to implement without breaking the KPI and frustrating your users! We will give you tips on how we did it at Decathlon Technology ;).

This article is the logical continuation of the article “How Decathlon successfully implemented a CSPM” written by Fabien Bloume ; thanks to him for the inspiration!

Why should you add/remove/modify your CSPM policies?

As mentioned in the introduction, there are several reasons to add, remove or modify new CSPM policies in your environment:

1. Looking at your business, risk may also evolve, and you may want to reflect these risks (from the Information Systems Security Policies, for example) in CSPM policies.
2. Cloud providers frequently release new services and new features in existing services that need to be secured and controlled. Example with AWS announcing AWS Lambda support for Attribute-Based Access Control (ABAC) in July 2022 or GCP now supporting the deletion protection flag for Cloud SQL (MySQL, Postgres and SQL Server instances) in August 2022. Services or features may also be removed or deprecated, such as the privateCluster field in the API for calling a GCP GKE cluster (Link) in 2021. This removal or depreciation can have a negative impact on your policies. It may generate false positive alerts … or prevent generating alerts at all ;
3. Your CSPM vendor may publish new APIs that cover these new services. At the same time, it may release new policies that cover the basic security controls of the service in question ;
4. Finally, new techniques may be discovered by external researchers to escalate privileges in the cloud. Depending on the business risks, you may want to cover these techniques. Orca has compiled some of these risks in its Cloud Risk encyclopedia.

All these reasons should be an opportunity for you to develop, adapt or remove policies.

What are the drivers for creating new CSPM policies?

At Decathlon Technology, we have three drivers:

(1) New or updated Cloud Security policy ;

(2) Built-in policies published by the CSPM editor ;

(3) A team/user who wants to develop/adapt a policy based on their usage.

(1) The risks of the company evolve. As a result, the Information System Security Policies (ISSP) are updated or new ISSP on specific topics are created. As risks evolve, your company wants to cover and control them via CSPM policies.

(2) Your CSPM editor should release new policies frequently (at least once a month). These policies should cover new services released by the Cloud provider, but also your editor’s roadmap and integration of services they have decided to cover. Check these new policies with the team in charge of these Cloud provider services.

(3) Finally, new policies or changes may come from your user, especially the one in charge of the Cloud provider service. Let’s imagine that a team in your company is in charge of managing serverless services. They will be more likely to suggest changes to policies (impacting services like AWS Lambda, or GCP Cloud Run) that they know about, than you.

On the other hand, as the cloud security team, you are in the best position to challenge them.

Finally, it’s essential to share all the new rules you want to push with your Security Officers. Information Security Officers are in the most ideal position to challenge these new rules because of their proximity to the business and the tech Ops/Dev.

How do you track changes to your policies?

Very quickly, your CSPM will contain several hundreds of rules in production.

Two questions must be addressed:

1. How do you track changes to your policies?
2. How do you assign policies to the right team/people and make them accountable for their lifecycle?

(1) Monitoring policies can be a real challenge : who changed a specific policy? Why did they do it? Did the person change the query, description or remediation?

It is critical that your CSPM tool provides an audit log to track these changes. In the best case scenario, CSPM includes a history for each policy.

At Decathlon Technology, we first started tracking the changes with a spreadsheet. However, we soon noticed that it was cumbersome and complicated to keep track of everything. Soon, the idea came up to send the audit logs to Splunk to create dashboards and to provide full transparency to our users. Each user would be able to see the last modifications made, the impacted policies, and would have precise details of what was impacted (description, rule, severity, …). The idea is in the pipeline and planned for 2023.

Last but not least, we also plan to use a versioning tool such as Git to track changes to the rules. The constraint is that this could only be done on the “custom” rules because the “built-in” rules are added automatically by our editor during the monthly updates.

(2) As mentioned at the beginning of this article, new policies or changes may come from our users, especially the ones in charge of the Cloud provider services. Also, the team in charge of managing Cloud provider services is more likely to suggest changes to policies.

At Decathlon Technology, we have assigned cloud service keywords to teams.

Below is an example.

Then, the objective is to assign the name of the team responsible for each security policy that contains a specific keyword. For the attribution, we decided to create dedicated labels and to automate this via a script. When our editor releases a new rule, it automatically assigns it to the right team.

Afterwards, on a regular basis (every 6 months), we perform an extraction and review the rules with the team concerned : is the rule still relevant ? Should we modify the description to add context ? Should we change the severity or adjust the policy ?

These solutions allow flexibility and, if the editor does not propose an adequate solution, allow a better tracking of security policy changes “out of the box”.

How we are implementing these new policies ?

As Fabien mentioned in his article “How Decathlon successfully implemented a CSPM”, you may have implemented a notion of compliance score. This compliance score is essential for the company, as it is a critical path to succeed in reaching an ambitious cloud compliance target.

Pushing new policies into production will de facto generate alerts, and therefore reduce compliance scores. This will greatly frustrate your users.

Here are our tips for reducing this frustration:

1. At the beginning of the year, define several fixed dates to push rules into production ;
2. Review all rules and validate their application with the security officers and the product owners of the cloud services ;
3. Push new policies to a pre-production server or pre-production compliance standard first so that teams can see the alerts but without affecting the KPIs ; Try to give teams several weeks to fix misconfigurations ;
4. Properly document your policies and the associated remediation so that the alerts are well understood ; Explain the associated business risk for each policy ;
5. Communicate changes to everyone: either by email or via the change/incident tool ;
6. Push new policies into production on the set date

By using these tips, you will greatly reduce your users’ frustration.

To summarize

Setting up a CSPM is the first step in your cloud journey. It is critical to get your teams onboard and keep them motivated.

The second step, just as complicated as the first part, is to make your product live, while taking into account the evolution of security, new services released by the cloud provider but also your Cloud Security Policies.

It is essential to collaborate and onboard your different key-users in order not to demotivate them from using the product.

As usual, cybersecurity is a long-term thinking process.