Following the theme of continuous compliance, we also need to provide our stakeholders with some assurance. This usually comes in various flavors of reporting, whether that be security event reporting, cost trend analysis, or patch currency reports. Reports are, for the most part, a point-in-time snapshot of a particular set of metrics. These metrics are likely to be tracked closely by risk or governance teams, so they must be accurate. It would be great if we could automate this, so we can have the results in a timely manner with minimal input from ourselves.
One of the compliance frameworks your organization might be aligning to and reporting against is the CIS Controls and Benchmarks. This is a standard that encompasses many industry best practices and methodologies for securing IT solutions, including servers. As AWS engineers, if we are running in an environment with hundreds or thousands of servers, how do we make sure we are benchmarking our systems against the controls? How do we do this in a repeatable and automated way by building it into our DevOps practices?
Thankfully, there is a serverless service called Amazon Inspector that does this for us. Inspector can automate the security assessments, identify security issues, and compile a report of the findings. It uses an agent installed on each server to collect the data. You can kick off an assessment through the console, using the CLI, or I suggest running it on a scheduled basis and continuously feed the actionable findings to the responsible teams.
A good idea would be to run Inspector on all newly built AMIs. That way, you can identify if the new build introduces any vulnerabilities so you can address them before creating any instances. You could get your AMI build pipeline to produce the AMIs, then run a Lambda function when done. The function would launch a new instance with restricted network access and then trigger Inspector to run an assessment on that instance.
It might look something like this:
If there were any new findings, an admin could be notified by email. Better still, SNS could post directly into a Slack channel.
This was an overview of some of the auditing and reporting components we might think about when building automation into our environments.