I have been using AWS for many years and I have seen first hand the evolution of a number of their services over time. When I first started working with AWS it was very much a complete separation of service between AWS accounts. If you wanted accounts to interact even within the Organisation (when Organisations came to exist) you needed to develop solutions from scratch (using Lambda or other mechanisms to do that). This was also true of Security Governance.
I recently discovered in a long term customer’s environment Config Rules deployed using cloudformation template. This was a series of defined config rules to validate against Center for Internet Security (CIS) Benchmark. We used to be writing a lot of these structures to deliver our compliance as we mandate.
Enter AWS Security Hub
AWS Introduced Security Hub in recent years and Security Hub has benchmark standards for CIS, PCI DSS and AWS Best Practices out of the box. You can enable one or all of them and measure what remediations are required. Security Hub is backed by AWS Config rules which flags whether a particular configuration item in AWS is compliant or not against a check.
But AWS Security initially was a per account measurement tool but that has also evolved over time.
AWS has done a great deal of work in evolving the use of AWS Organisations and this comes to a head with Control Tower (Discussed later in the blog). One of the more recent enhancements that I really love about Security Hub is that it now natively integrates with AWS Organisations.
AWS Organisations has introduced concepts such as Delegated Administrator which allows the Organisation Management account to delegate permission to control certain features to other accounts. You can (and in my opinion should) have an account dedicated to security in your organisation (and if you build a Control Tower environment you will)
By Delegating this Account as master for Security Hub and enabling auto enrollment of Organisation member accounts within an Organisation you can ensure that whenever a new account is created it will automatically be added to Security Hub and monitored for compliance
And finally you need to consider remediation. How do you remediate compliance violations. For this I recommend the AWS Solution AWS Security Hub Automated Response and Remediation which uses Custom Actions in Security Hub to automate the remediation of violations within Security Hub.
In my time I have seen Security Hub go from being an environment where you need to develop your own mechanism to create a master slave relationship for Security Hub to full integration with Organisations. This is just another great example of AWS listening and responding to feedback from their partners who help shape these solutions.
AWS Config Conformance Packs
Moving on from Security Hub I think I should touch on another of the great options available within an Organisation to measure compliance at scale. As I mentioned above Security Hub supports 3 standards but if you need to measure against something else (For us in Australia and New Zealand APRA (Australian Prudential Regulatory Authority) and NZ ISM) are key benchmark standards we need to be aware of. Security Hub doesnt include those standards but the great thing is that AWS Config Conformance Packs do.
How is it different?
To be honest they are fairly similar although AWS Security Hub puts a graphical spin on a number of the settings. And with more recent additions of Organisation Conformance packs then again you can deploy at Scale so that any account within the organisation gets the Conformance pack applied.
Like with Security Hub there is also information on how to automatically remediate config rules within a compliance pack as well. An example of the use of NZ ISM as a conformance pack is shown below on a single account.
Below is an example of an account with compliance status. This is an environment where are currently developing remediation solutions (which I will touch on a bit later). You can create automatic remediation options for this or you can leverage other mechanisms to control it such as Cloudformation Stacksets or Service Control Policies to prevent certain changes.
How you do it at scale though is within the Organisation Management Account. You create an Organisation Conformance Pack, which effectively appliances conformance packs to all accounts within the organisation.
As shown below once you deploy the Organisation Control Pack from the Config Conformance Packs console you will see each account within the organisation and what rules they are failing
And the last thing I think I should mention is auto remediation for Config Conformance Packs. AWS Config Conformance Packs can have remediation rules added in to them which trigger a custom action within the account. In order for that to work the Member account that needs remediation requires appropriate access for the remediation task to run. The task needs access to change the config or service item that requires remediation (ie removing a rule from a Security Group)
Reference on this is here https://aws.amazon.com/blogs/mt/deploying-conformance-packs-across-an-organization-with-automatic-remediation/
Control Tower
I mentioned control Tower and I will probably write a comprehensive article on how to operate it at scale and with some level of automation in coming weeks but there is a place for it in this discussion.
I mentioned that Control Tower sets up a Separate Security Account as part of the Landing Zone deployment. It also sets up an isolated Logging account which is also best security practice.
What is relevant to discuss here is how Control Tower provides its own Guard Rails and supports the use of a Customisations feature to allow more to be deployed
Guard Rails have 3 types (Mandatory, Recommended and Elective) and 2 behaviors (Prevention or Detection). Its pretty self explanatory how each works but suffice to say most of the Mandatory + Prevention Guard Rails are around Control Tower itself and limiting the ability of any user to interfere with Control tower’s operation. This includes ensuring no changes made to Control Tower’s logging or Encryption that might disrupt the functionality of the service.
Most of the Non Mandatory Guard Rails are detection Guard rails so they dont necessarily block change but will flag as a config rule violation if they are not compliant.
Control Tower has limited Programmatic interaction currently but what has been released by AWS which makes it much easier to expand Governance beyond these Guard Rails is the Customisations for AWS Control Tower Solution which provides the ability to deliver programmatically Service Control Policies to the Organisation or Cloudformation Stacksets which combined provide extra organisational management at scale and without the need to implement for new accounts.
Whenever a new account is enrolled it will automatically get the Guard Rails defined by either Control Tower or the additional Governance.
Massive boost to the ability to scale and manage customers as accounts grow from the 10s into the 1000s.
