TIQQE Well-Architected Framework – Security Baseline
Our 6 pillars of TIQQE Security Baseline:
- Multi-account environment
- Security best practices
- Threat Detection
- Protecting data in transit and at rest
- Strong identity foundation
The first pillar of TIQQE Security Baseline is, Multi-account environment. The purpose of the Multi-account environment is to segregate the accounts using AWS Organization and AWS Control Tower. By segregating the environment the accounts will act as containers if a security issue or misconfiguration would occur, then the blast radius will be reduced to a single account.
Control Tower, GuardRails & Organizational Units
Control Tower gives you a prebuilt multi-account framework that helps you set up and govern the multi-account environment, features such as guardrails, centralized logging and monitoring. One of the benefits of Control Tower is that you can govern the different accounts using OUs (Organizational Unit) and apply GuardRails (“Policy”) on the OUs affecting the accounts under that OU.
As seen in the diagram above we separate each account into different OUs according to the purpose of the account. Production accounts will be in a different OU with different GuardRails applied then Test accounts.
With GuardRails you are able to set up preventive and detective controls on the accounts under an OU. Examples of GuardRails could be:
- Detect Whether Encryption is Enabled for Amazon EBS Volumes Attached to Amazon EC2 Instances
- Detect Whether Storage Encryption is Enabled for Amazon RDS Database Instances
- Prevent ROOT activity on the accounts
With TIQQE Security Baseline we apply additional GuardRails on the accounts.
Security best practices
Security Hub is an AWS service that implements security and compliance controls across all of the accounts and collects findings from multiple sources. Security Hub detects when deployed accounts and resources do not align with the security best practices defined by AWS security experts. We aggregate all of the Security Hub findings across the organization into our Audit account which is a privileged account that only a handful people have access to. We check all of our accounts against 2 set of standards:
We present weekly findings to the clients, where we go over what we can do the following week to address what has come up or just work on strengthening the security posture of the environment.
We work with our clients to block regions that are not required in their environment. Before we accomplished this with Service Control Policies (SCP) on the accounts but are today made possible via Control Tower Region deny service.
The third pillar of TIQQE Security Baseline is Threat Detection. To be able to react and monitor the environment we use GuardDuty. GuardDuty uses threat intelligence feeds, such as lists of malicious IPs and domains, and machine learning to identify unexpected and potentially unauthorized and malicious activity within the AWS environment. When activated, GuardDuty creates a Baseline of the accounts “Normal” behavior and will use Machine Learning to trigger alarms. We have integrated GuardDuty with our own internal alarm service, AlertOps, for quick response on alarms.
Protecting data in transit and at rest
AWS Control Tower uses Transport Layer Security (TLS) and client-side encryption for encryption in transit in support of your landing zone. In addition, accessing AWS Control Tower requires using the console, which can only be accessed through an HTTPS endpoint. TIQQE Security Baseline enables encryption by default on EBS and RDS databases on all of the accounts in the organization.
With CloudTrail in place it will log all API calls across the organization in every region into our logging account (Privileged account). All API calls go to the logging bucket with Log file Validation turned on (validates whether a log file was modified, deleted, or unchanged after CloudTrail delivered it) and Server access logging turned on (provides detailed records for the requests that are made to the bucket). The logs are kept for a period of 2 years.
Strong identity foundation
Single Sign On
AWS Single Sign-On is a cloud-based single sign-on service that centrally manages SSO access to all of the AWS accounts and cloud applications in the organization. AWS SSO makes it simple to create and manage users and groups, monitor usage or integrate with Microsoft AD. In TIQQE Security Baseline we are enforcing the use of Single Sign On.
We are enforcing MFA on all the users accessing the environment thru SSO and we try to limit or prevent the use of static access keys and/or IAM users. For all of our ROOT users we require a Hardware MFA that only a specific person can access and is under lock and key.