ACM.390 A feature request for CloudFormation when using secrets and parameters to better protect customer data
Part of my series on Automation of cybersecurity measures. AWS Organizations. I AM. Deploy a static website. THE Coded.
Free content on Cybersecurity Jobs | Register at Broadcast list
In the last article I explained the fundamental changes I need to make to every script in my previous codebase to make this series work in my new directory structure inside a container.
This is another spin-off article from starting to do something else and then getting stuck or distracted by another problem.
I’m going to reiterate some of the issues I have with SSM settings and secret values in AWS CloudFormation templates that I hope AWS will fix.
In general, I think AWS Systems Manager could be very useful, but it comes with some security risks. I mentioned C2 channels which can easily be created with document access and script deployment to your EC2 instances and cloud resources.
Sure, go ahead and run any command you want on an instance using this nifty SSM document… Anyone working in the field of penetration testing or the attackers who take advantage of it will thank you very much. Read on Living off the land and configure a C2 channel using Pacu — an AWS penetration testing tool.
But that’s not my immediate problem. Currently I’m having issues with dynamic resolution of parameters in templates and handling secrets in general when using CloudFormation parameters or dynamic resolution.
My first recurring problem is that AWS CloudFormation does not support the creation of (encrypted) SSM Secure String parameters. AWS claims to encrypt everything. Does this include default SSM settings?
This doesn’t seem to be the case based on the FAQs and other materials I’m reading at the time of writing:
