Managing security and compliance can be a tough job when we have our infrastructure spread over multiple public cloud accounts. In most organizations, there are dedicated cloud accounts for each product line, and each product line can have multiple environments like development, staging, integration, and production. Keeping separate accounts for various environments is a good strategy to stop the lateral movement in case of any compromise, but managing those multiple accounts is hectic. When we talk about security management, it consists of user management, password policies, detection and protection mechanisms, logging and monitoring, regulatory compliance, responding to events/incidents, recovery, and following best practices.
In this blog post, we will talk about achieving centralization in the AWS public cloud using AWS organization. It has provided us with a lot of native tools that we can utilize to centralize compliance, logging, monitoring, and user & access management through multi-accounts in the organizations.
AWS Organization is a service that enables us to manage and govern multiple AWS accounts centrally. It offers several advantages, such as improved cost control, central security, better governance, and operational efficiency for those with complicated AWS infrastructures. It helps us manage and scale the cloud infrastructure by centralizing control and streamlining administration.
There are many advantages of using AWS organization, including:
Organization of accounts is very important as it helps us achieve a structure as per our needs and we can further streamline policy implementation as per the structure defined. We can use multiple approaches to define a structure.
One approach is to categorize accounts of various products into groups like “prod,” “sandbox,” and so on so that we can easily apply SCPs to different types. Here is an example of this approach.
Another approach is to arrange accounts according to projects, and under the projects, we can further use sub-categorization. An example of this approach is shown below:
If we wish to manage all the services from a separate account rather than the master/main account, we can delegate the service administration to another account. For example, as seen above, we can create a dedicated account for security and another for logging and monitoring.
To add a delegated admin, we have to go to ‘settings’ under the ‘organization’ console and check which access level we want to delegate. It can be view access just for learning and understanding for the team or some limited read/write access. We can also add on which resources we want the access to be delegated, it can be all resources, some OU under root, or some particular accounts. Additional details related to the delegation of Organization can be found in the official AWS documentation. Below are screenshots showing the delegation of services and access levels in the AWS Organization.
AWS Organizations -> Settings -> Delegated administrator for AWS Organizations -> Create delegation policy
There are, in total, 32 services that can be managed by the AWS organization at the time we are writing this blog post. In this blog post, we are only interested in services that help us to centrally manage controls related to security, compliance, resource, and access management and are categorized as below:
Note: One has to make sure that trusted access is enabled from the AWS Organization console for the service that we want to manage centrally. AWS offers many other services under security and compliance, but the key focus of the post is to focus on services that can be centralized for multiple accounts.
AWS Organizations -> Services -> Service-name -> Enable trusted access
Below is an example Screenshot for enabling trusted access for AWS Inspector.
It is not mandatory that all the pillars must be covered in the baseline or advanced section. These categories are created as per the service offered by AWS as we are only targeting AWS native services.
There are a few services that we identified as a baseline, but to use them with full potential, we have to integrate those services with others. One such example is Security Hub. It gets data from multiple services, and if we have yet to enable those services, the Security Hub will not work to its fullest potential, but it will still work independently to provide some data.
Here are quick picks that can help you to some extent in service selection as per the organization’s needs.
Security Requirement | AWS Service |
---|---|
Security dashboard | Security Hub |
NIDS | GuardDuty |
Vulnerability scanning | Inspector |
PII data scanning | Macie |
API Logging | CloudTrail |
Patching | Patch manager from System manager |
AWS security posture | Trusted advisor |
Identity federation | IAM identity center |
S3 storage view | S3 storage lens |
Auditing | Config |
These are the services one must consider and enable during the initial stages of setting up an account irrespective of compliance or customer requirements. These services require minimal or no additional cost and can be easily set up and managed.
One of the most important components of security is authentication; it acts as the first line of defense and plays a crucial role in safeguarding digital systems, data, and resources from unauthorized access. When discussing AWS multi-account authentication, we can use the IAM Identity Center, and this will be the initial stage of security, the AWS Identity Center can be very useful as it gives us options to integrate various external identity providers. We have the option to use it with AD (Active Directory), any external identity provider, or we can use the native AWS Identity Center directory for user management and authentication.
We can use a predefined permission set to provide user access or create our custom permission set per our requirements. We have options to define session timeout settings, e.g. for prod, we can set up a session of 1 hour, and for non-prod, it can be 4 hours or as per organization policy. You can visit the docs to learn more about AWS IAM Identity Center. Below is an image showing some of the predefined permission sets we can use with AWS Identity Center.
IAM Identity Center -> Permission sets
AWS CloudTrail is an AWS service that helps you enable operational and risk auditing, governance, and compliance of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail.
By enabling the organization trail, one can centrally manage all the trail logs of all accounts in one place. All the accounts created in the future will be added to this organization trail and all the logs will be collected in the same bucket without any additional effort. You can read the docs to learn more about CloudTrail.
Steps to enable the org-level CloudTrail are:
By default, the KMS encryption and log file validation are disabled for the CloudTrail. We should enable them by editing the CloudTrail to ensure integrity of the logs.
The above CloudTrail setup is good enough for a basic level of org-wide logging, but if someone is looking for more detailed events, they can also enable the insight events in the CloudTrail. Insight events continuously examine CloudTrail management events, and it assists customers in identifying and taking action in response to odd behavior related to API calls and API error rates. CloudTrail Insights examines our typical API request behavior of API volume and API error rates.
CloudTrail -> Insights
GuardDuty is a threat detection service that continuously monitors malicious activity and unauthorized behavior to protect our AWS accounts, workloads, and data stored in Amazon S3. It analyzes events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon VPC Flow Logs, and DNS logs. You can read the docs to explore GuardDuty in detail.
Any account inside the organization may be chosen to serve as the GuardDuty delegated administrator when using GuardDuty with an AWS Organization. Delegated administrators for GuardDuty can only be selected through the organization’s management account. Because GuardDuty is a regional service, we must enable it where we want the threat detection service to be available. We can control security features like S3, Kubernetes, and malware scanning from the delegated admin account. We can also automatically enable new accounts (this will enable newly created accounts to account in the organization to be added to GuardDuty).
To enable trusted access and delegate GuardDuty administrator we have to go to
AWS Organizations > Services > Amazon GuardDuty
When we proceed further, it will take us to the GuardDuty page shown below, define the Central-Security account ID where you want to delegate the service and enable attaching relevant permissions as well. Also, enable the GuardDuty in the central management account (the main account where the Organization is set up).
You can navigate to the GuardDuty console in the Central security account, click on Accounts and turn on “Auto Enable” for service. GuardDuty offers us monitoring for several services including S3 protection, Malware monitoring, EKS audit, RDS login activity, and runtime monitoring, depending on the use case or services. We can enable these services via GuardDuty.
All the alerts can be viewed on the central dashboard. The below image has sample alerts from GuardDuty, and the alerts are categorized based on severity, last findings, most common findings, and so on.
Security Hub offers a comprehensive view of your security alerts and security posture across your AWS accounts. It aggregates, organizes, and prioritizes your security alerts, or findings, from multiple AWS services, such as Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS Identity and Access Management (IAM) Access Analyzer, AWS Systems Manager, AWS Firewall Manager, as well as from AWS Partner Network (APN) solutions.
The Security Hub depends on the aforementioned services to function to its full capacity; if the majority of these services are enabled, it is an advanced service that can work as a single pane of glass for organization-level security. You can read the docs to learn about Security Hub in detail.
As per AWS, before we enable Security Hub standards and controls, we must first allow resource recording in AWS Config. We must allow resource recording for all of the accounts and in all of the Regions where you plan to allow Security Hub standards and controls.
Along with the aggregation of events from various other services, Security Hub allows us to aggregate all the findings from various regions into a single region. In case we are using multiple regions, we can have a single pane of glass for security alerts/events in a single region.
Security Hub -> Settings
Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations. You can read the docs to learn about Config in detail.
We can create an AWS aggregator in the delegated account of the organization and all the accounts in that organization that have AWS Config enabled start sending data to the account. It will collect and display the compliance and resource inventory data centrally on the dashboard.
To enable Config centrally, we can use the predefined templates:
Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for exposure, vulnerabilities, and deviations from best practices. After performing an assessment, Amazon Inspector produces a detailed list of security findings prioritized by level of severity.
Inspector is a regional service, and to assign an administrator and consolidate the Inspector’s vulnerability scan results to a single account, the organization management account must be used. Once enabled, we can use this for scanning EC2 instances and ECR container scanning.
Amazon Inspector supports deep inspection of EC2 instances, which can identify software vulnerabilities in application programming packages, including Python, Java, and Node.js packages in addition to operating system packages.
Amazon Inspector integration is supported with tools like Jenkins and TeamCity for container image assessments. This integration allows developers to assess their container images for software vulnerabilities within their continuous integration and continuous delivery (CI/CD) tools.
Inspector V2 allows you to centrally manage the service via multiple AWS accounts. We can follow simple steps to enable Inspector, on the landing page, we have to select assessment setup based on requirements.
You can read the docs to learn about Inspector in detail.
Once the assessment part is completed, we can proceed with the delegation part and auto-enabling AWS Inspector for new member accounts, we can opt for EC2, ECR, AWS Lambda standard, and Lambda code scanning.
These services should be considered as the product matures while focusing on enhancing security and compliance with a better budget in hand.
AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. This lets you identify unintended access to your resources and data, which is a security risk.
Detective makes it easier to analyze, investigate, and quickly identify the root cause of potential security issues or suspicious activities. It automatically collects log data from your AWS resources and uses machine learning, statistical analysis, and graph theory to build a linked set of data that enables us to easily conduct faster and more efficient security investigations.
It can analyze events from multiple data sources such as Virtual Private Cloud (VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty, and automatically creates a unified, interactive view of our resources, users, and the interactions between them over time.
Detective automatically extracts time-based events such as login attempts, API calls, and network traffic from AWS CloudTrail and VPC Flow Logs. It also ingests findings detected by GuardDuty. You can check the docs to learn more about Detective.
Multiple roles can be assigned to AWS Detective.
Fully managed data security and data privacy service that uses machine learning and pattern matching to discover and protect your sensitive data in AWS. Macie applies machine learning and pattern-matching techniques to the buckets you select to identify and alert you to sensitive data, such as personally identifiable information (PII). You can view the docs to explore Macie.
Using the Systems Manager we can view operational data from multiple AWS services and automate operational tasks across our AWS resources. Systems Manager helps you maintain security and compliance by scanning your managed instances and reporting on (or taking corrective action on) any policy violations it detects.
Important services provided by Systems Manager are:
We can run ad-hoc commands, do one-time patching, or schedule patching with the help of Patch Manager. We can use parameter store to store passwords in an encrypted format.
With the help of the organizational Storage Lens, we can get a clear picture of all the buckets present in various accounts and regions, which storage class the buckets belong to, and what is the status of data protection on buckets. Data protection can tell us about the encryption status of data in buckets (at rest and in-transit).
AWS CloudFormation StackSets extends the capability of stacks by enabling us to create, update, or delete stacks across multiple accounts and AWS Regions with a single operation. Using an administrator account, we define and manage an AWS CloudFormation template and use the template as the basis for provisioning stacks into selected target accounts across specified AWS Regions. It can be beneficial when we have to roll out any tool or policy across the organization. It can also let us know if there are any deviations after the deployment/roll-out.
There are 3 primary stages when we are working with StackSets:
Although a Trusted Advisor is not purely a security service, we can get security recommendations from the service, and we can use it across all accounts under the organization. We can create reports and export those reports in CSV or JSON format.
You can read the docs to learn more about Trusted Advicor.
If you have a multi-account structure, consider centralization of services using AWS native services to better manage security and compliance. In this blog post, we have covered the native security services by AWS that can help us achieve basic security as well as some level of advanced security. The various tools provided by AWS cover many security aspects like logging, monitoring, alerting, patch management, scanning, etc.
I hope you found this blog post informative and engaging. I’d love to hear your thoughts on this post. Let’s connect and start a conversation on LinkedIn. Looking for help with securing your infrastructure or want to outsource DevSecOps to the experts? Learn why so many startups & enterprises consider us as one of the best DevSecOps consulting & services companies.