Upon building a demo platform for a webinar, I previously decided to run a Cloud Security Assessment on that which I had created and found I was in breach of a number of compliance issues. A range of vulnerabilities were documented such as issues with key / authentication methods, I was using defaults for Admin level usernames, my resources were open to the public, etc. Note that these violations aren't solely for AWS, they exist in Azure & GCP too when using default options.

I am not an IaaS expert, I just spun up what I needed, when it was required, and dismantled the infrastructure once done. I understood the surface level vulnerabilities shown during the Cloud Security Assessment based on my prior knowledge of PAM, SASE, etc. but in the output there was a much deeper layer of what was happening behind the scenes within the cloud platform that I myself would never have even known to look for.

Now whenever I build any resource as part of my job, I use a Terraform build script that has configurations hard baked into it that address all of the prior vulnerabilities & compliance issues and to this day when I run an assessment again, I see zero hits.

That is essentially my journey in the IaaS space as a Cloud Engineer.

The above relates to a Dev estate with a maximum of seven servers needed, a mixture of Windows & UNIX and all of which get dismantled on the same day for the session they were used for.

However, what if we scale it up to a Production environment that requires more stringent security protocols?

What if the servers or resources were more permanent?

In my example, I never knew what to look for under the hood in relation to the vulnerabilities I was creating as part of my simplistic build process, so what if said vulnerabilities were also hard baked into Production deployment processes or even on legacy deployed resources?

If build scripts are being used, do they address the compliance vulnerabilities at source?

How would you undertake retrospectively checking a production cloud estate, especially those at Enterprise level?

This is essentially where the Lacework Cloud Security Assessment offering comes into play as it is this that opened my eyes to the problems I was creating.

With this, you essentially allow Lacework access to your Cloud Provider(s), read only, it won't be making any changes, it reviews the logs & configs of your build and reports back on the vulnerabilities & chosen compliance issues it finds.

Now Lacework itself is a much bigger solution and the CSA only relates to a small part of it but to me, it is invaluable to anyone using IaaS these days.

You can choose from a range of compliance standards to choose from, such as: