Information Security Compliance can be a tiring and complicated exercise for all parties involved. Making a solution compliant for the set of security standards and controls is a massive effort, especially if the architecting stage did not think about these requirements in the first place.
It’s even more complex when it comes to proving the compliance level of the solution to internal or external auditors. The language InfoSec and Security Auditors speak is vastly different from the language used by engineers.
and I don’t mean that engineers use Python or Terraform. I mean that InfoSec would ask “why wouldn’t you mention the checklist that you used to review a change request when you sign off?” when the engineers ask “why would I ever mention anything other than LGTM when approving a PR?”. The motivations and the contextual understanding these two parties have about the same solution can be vastly different.
This can be painful if the compliance effort is being carried out at the same time as development phase of a project, where it will become a confusing exercise of InfoSec trying to put in process guard rails into day to day development processes.
This blog post is a high level serialisation of a talk I did on the AWS Twitch Stream. The scope of it is to understand better ways of performing compliance workloads on the AWS solutions.
InfoSec Compliance for the Cloud
There are various information security control frameworks, objectives, and activities defined in the industry already. These can be generic such as ISO27001 or business domain specific such as PCI DSS or HIPAA.
These have been around for sometime and Information System auditing has developed to form really specific control activities to check for in a given system. However, in most discussions you would have with InfoSec and auditors, you’ll quickly see a disconnect when it comes to auditing Cloud based solutions. Most of the existing frameworks are built around on-premise thinking patterns (although standards like ISO27017 exist, they too tend to be too general for an auditor to focus on a specific Cloud provider).
Concepts such as Shared Responsibility Model in the Cloud seems to throw auditors off, where they would have a hard time being convinced that IaaS and PaaS services would have different levels of responsibility for the client, and therefore needs a more granular level of evaluation for different controls. Most times, auditors find themselves asking questions that are irrelevent to the Cloud eco-system or even missing critical questions that might actually be important to evaluate the solution that are specific to the Cloud.
On the other side, engineers rarely understand the complexities of InfoSec compliance landscape. They would probably be aware of business domain specific frameworks, however the regulatory requirements may put more checks to be done for a given solution. Almost any country has a spelled out Information Security framework. This can be even more restrictive for government agency related solutions.
In discussions with auditors, the engineers may feel questions as repetitive, and sometimes unnecessary because of how they perceive a system. Project implementation timeline constraints can then jump in and disrupt the whole effort by pushing any kind of additional work that is needed to make the solution and the development process compliant.
Because of these reasons, it is important to understand the gap that exists between modern Cloud solutions and the thinking around typical information security control frameworks. Doing so helps the engineers to build better solutions and spend less time on retrofitting compliance in to the system. Auditors and InfoSec then also understands the nuances in a Cloud solution, how to define control validation activities in a Cloud context, and what to look for in the modern Cloud environment.
In the following sections, I mainly refer to technical controls, as process controls can vary greately outside of the AWS component.
Cloud Security
Although technically the Cloud is “someone else’s computer”, the client that utilises the said computer has a certain responsibility for security as well. Public Cloud Service providers define a Shared Responsibility Model based on this divided responsibility for a solution in the Cloud. A good example of this is the AWS Shared Responsibility Model.
These typically talk about Security OF the Cloud and Security IN the Cloud. The former is part of the cloud service provider’s responsibility, where aspects like data center security, physical hardware management and disposal, tenant paritioning and separation should be (and can only be) done by the service provider. The service provider is usually audited by third party independent auditors for these activities. For AWS, the reports of these audits are available in AWS Artifact. Therefore, any control that tries to validate activities such as above should look for reports available under AWS Artifacts. AWS cannot be audited by a particular solution audit effort, so all you get is AWS Artifacts. As an auditor, you should be able to understand the Shared Responsibility Model and how it applies for these activities to be comfortable enough to accept these independent reports as evidence.
The latter, Security IN the Cloud, is the responsibility of the client. The client should utilise the features available on the Cloud to architect a secure compliant solution, and should provide evidence of the said implementation using the Cloud platform when the auditors come knocking. The type of evidence needed can be different for different services, and the Shared Responsibility matrix tends to be more nuanced in these areas where different services would provide different levels of management features to the users. For an example, a part of the architecture that uses EC2 will have to provide evidence of hardening efforts and vulnerability detection features being used to mitigate risks and adhere to related controls, where as another part that uses an ECS cluster on a Fargate backend will have different applicability levels and different kind of evidence to provide. In my personal experience, this is where auditors find themselves in trouble, where they have to evaluate the compliance level of a solution with having almost zero idea about the Cloud services the solution uses.
AWS Compliance Center can help in the early stages of a project to understand the level of regulatory requirements involved, especially if the solution is centered around the financial industry.
Three-Lines Model of Risk Management
Three-Lines model is a risk based thinking pattern to be utilised during solution architecture work. This orients the architecture decisions around,
- understanding the risks involved in the Cloud solution and implementing baseline controls - Manage Risks
- having a single pane of glass view into the current status of risk management at a given time - Oversee risks
- having the ability to provide assurances of the risk management efforts when requested - Provide Assurance
In an ideal scenario, the risk register of the solution would available in some form at the start of the project. However, in real world, this might not be the case. You would keep identifying new risks as the implementation life cycle progresses. With a structured thinking like the Three-Lines Model, the decision making process on how to mitigate these risks in a way that can be tracked and maintained becomes a lot easier.
For AWS, the architecture and implementation work can be oriented around the Three-Lines model by utilising AWS Config in the solution. AWS Config provides a well established method to implement baseline controls across the solution in a way that tracks the history of the level of compliance. This makes is easy to understand the level of compliance for those controls at a given point in time. Additionally, automated remediation can be implemented for the relevant controls that would free up human intervention needed to maintain the compliance of a solution. This is especially helpful for a Cloud solution because of the speed at which an architecture can evolve enabled by the elasticity and cost efficiency inherent in the Cloud.
AWS Config can also help in adhering to control frameworks by making use of Conformance Packs such as [NZISM Conformance Pack] (https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-nzism.html). AWS also provides extensive documentation on architecting for the specific control frameworks such as NZISM.
Service specific baseline controls can be put in with services such as
- AWS Firewall Manager - manage access policies in resources such as Security Groups and Network Firewalls
- AWS Backup - define a baseline backup strategy for resources across the solution
- CloudFormation and CloudFormation Guard - define Infrastructure as Code standards and policies as code
- AWS Systems Manager Compliance - manage level of compliance across your fleet of instances
- a combination of Service Control Policies, Permission Boundaries, and IAM policies - manage level of access granted to users in the solution
AWS Config can supplement these by keeping track of the said baseline controls and notifying stakeholders when they drift from the intended states.
AWS Security Hub can be used as a single pane of glass view in to the compliance level of the solution. Although AWS Config does provide such a view, it can be oriented around Config Rules alone and could only make sense to the engineers who worked on the solution implementation. AWS Security Hub provides a more generalised view into compliance by Framework level (ex: CSI Benchmark L2) with more information gathered from services such as GuardDuty which can make sense to a stakeholder a bit removed from day to day implementation work.
AWS Audit Manager can use data gathered by AWS Config and AWS Security Hub to provide a report centered around a selected control framework, which can bridge the gap between engineering and auditing a lot. The security control framework library provides almost all major control frameworks out of the box. These can then be used to generate reports that show the level of compliance for the entire solution in a language that auditors and InfoSec speak, which might reduce the need for auditors to understand complex Cloud service nuances to properly evaluate a system.
Recap
To put it simply, in an AWS solution, use
- AWS Compliance Center to understand regulatory and InfoSec context for your solution
- AWS Artifact to provide evidence for Security OF the Cloud
- AWS services to put in baseline controls
- AWS Config to keep track of the baseline controls and get notified when your solution drifts away from compliance
- AWS Security Hub and AWS Audit Manager to consolidate and provide assurance of solution wide compliance
In general, keep the Three Lines model in mind, as it helps you orient the thinking around a risk based approach. These should set you up for success.