DEV Community: George Rolston

Shift-left with GitHub Amazon Q Developer Project Rules

George Rolston — Fri, 09 Jan 2026 15:10:27 +0000

Most would agree that shift-left is the right thing to do, but actually doing it has historically been painful. The not-so-favorably looked upon policy-as-code initiatives often come with new languages, new tools, and new places developers have to remember to look—so it’s no surprise it doesn’t always stick. In this post, I’ll walk through how GitHub Amazon Q Developer Project Rules make shift-left feel natural by bringing policy-as-context directly into pull requests using simple Markdown files, turning security and compliance into something developers engage with instead of work around.

TL;DR: Policy-as-code has always been hard for most organizations, but for a long time it was the only real way to shift-left. With GitHub Amazon Q Developer Project Rules, we can now shift left using policy-as-context instead—and honestly, life is much better.

Note: Amazon Q Developer Project rules is implemented on best-effort basis. While Q strives to deliver accurate and relevant insights, its output is advisory in nature and does not guarantee completeness, correctness, or enforcement. Using Q for policy review should be done as one of many tools in your policy review and enforcement.

What is Shift-Left?

Shift-left is the practice of moving security, compliance, and quality checks earlier in the software development lifecycle—ideally as close to code creation as possible. Instead of discovering issues during late-stage reviews, audits, or post-deployment incidents, teams aim to catch problems during the coding phase.

In theory, this sounds great…in reality, it’s been tough to pull off. Shift-left might be a buzzword, but if security and compliance only show up to review what’s already deployed instead of what’s about to be, teams end up stuck in a loop of rework, delays, and frustratingly slow delivery.

Most organizations that attempt shift-left eventually run into the same obstacles when adopting policy-as-code in their DevSecOps practices:

Steep learning curves with policy as code (CloudFormation Guard, OPA, Rego, custom DSLs, framework-specific tooling)
Fragmented tooling across CI, security, and platform teams
Technical debt for maintaining policies
Limited participation because policies have generally lived outside of the “everything as code” world

Yet, shift-left is still the right answer to modern security and compliance challenges. The problem hasn’t been the goal—it’s been the method of implementation.

That’s where GitHub Amazon Q with Developer Project Rules fundamentally changes the equation.

Enter GitHub Amazon Q Developer

Amazon Q Developer for GitHub integrates generative AI directly into GitHub issues and pull requests. It acts as an AI-powered development and review agent that can:

Perform automated code reviews
Provide contextual feedback directly in PR conversations via comments
Respect project-specific rules defined in your repository
Generate code from issues (additional permissions need to be granted)

We have used Amazon Q Developer at Platformr for all our products for the last six months. It has been a game changer in pull requests and code review. Our development team reviews all feedback from Q and engages via comments on the pull requests. The feedback and code summarization is only for the code changes which saves time and improves code quality.

Don’t get me wrong, it doesn’t replace humans—but it dramatically improves signal, consistency, and speed. Additionally, it will not make a person who has no clue what they are doing suddenly brilliant..they still have no clue what they are doing.

Getting Set Up with GitHub Amazon Q Developer

To get started, install the Amazon Q Developer GitHub App from the GitHub Marketplace and grant access to your GitHub organization or selected repositories within the GitHub organization.

During installation:

Choose which repos Q can access
Approve permissions for issues, pull requests, and comments

You don’t even need an AWS account to get started during the preview. You can register the app with an AWS account later if you want, but it’s totally optional for now. And if you only enable it on a few repositories to start, no worries—you can always jump back into your GitHub org settings and tweak the app’s access as you go.

Once installed, any applicable repository that has a Pull Request opened on it will have Q automatically conduct a code review. Amazon Q Developer works primarily through:

Automatic PR reviews (on new or reopened PRs)
- Any existing PRs can have a review started by just commenting /q review
Slash commands in comments:
- /q review
- /q dev
- /q help
Labels (such as Amazon Q development agent) on issues

When a PR is opened, Q can automatically review the code and leave inline comments—just like a human reviewer would. If you respond back to the inline comments, Q will engage you in dialogue. It is really handy to better understand any recommendation.

At Platformr we identified a best practice is to configure requiring all PR conversations to be resolved before merged. This can be set in the repository Settings>Rulesets Branch Rules section.

Amazon Q Developer comments are part of the PR conversation. Requiring all conversations to be resolved ensures developers must explicitly acknowledge or address Q’s feedback, which turns AI review into a real enforcement mechanism—not just suggestions developers ignore and mash the merge button.

Amazon Q Project Rules: The Missing Link for Shift-Left

Amazon Q Developer becomes truly powerful when combined with custom project rules.

What Are Amazon Q Project Rules?

Project rules are Markdown files stored directly in your repository under:

.amazonq/rules/

These files provide explicit guidance to Amazon Q Developer about:

Coding standards
Security requirements
Compliance constraints
Architectural decisions
Organizational best practices
Basically anything you put in there…

When present, Amazon Q automatically uses these rules as context when:

Reviewing pull requests
Generating code
Suggesting changes

No pipelines.

No custom DSLs.

No external policy engines.

Just Markdown…

Personal Note: I did a lot of work on the Guard Rules registry creating rules for AWS CloudFormation Guard. If I had something like this at the time, I would not have done that work.

Why This Is a Breakthrough for Shift-Left

The policy-as-context approach solves many historical policy-as-code problems:

Low Learning Curve: Markdown is universal. Anyone can read it. Most can write it.
Policies Live with Code: Rules are versioned, reviewed, and evolved in the same repository as the application.
Organization-Wide Contribution: Security, platform, and application teams can all contribute rules through normal pull requests. Pretty much you just have to be literate to potentially contribute.
Immediate Feedback: Policies are enforced during PR review, not hours after deployment.

This is shift-left without friction. Basically if you can write out the rule in text, it can be applied.

Creating Custom Rules: A Practical Guide

Step 1: Create the Rules Directory

In your repository:

.amazonq/rules/

That’s it. No configuration files or service registration required.

Step 2: Organize Rules by Initiative or Policy Domain

Instead of one massive policy file, break rules into focused Markdown documents:

.amazonq/rules/
├── security-baseline.md
├── cdk-typescript-rules.md
├── roberts-rules.md
├── general-coding-standards.md
└── compliance-soc2.md

This keeps rules:

Easier to review
Easier to maintain
Easier for different teams to own

Step 3: Write Clear, Directive Rules

The example below shows how you can very easily create rules files. The file roberts-rules.md contains a very specific naming convention tag rule stated in a simple sentence (no code needed). There is also a detailed rule for AWS SDK clients which demonstrates the flexibility of the rules context files.

Example: roberts-rules.md

# Roberts Rules

## Purpose

Follow best practices from Robert who has rules of order

### Naming conventions

- All AWS resources should include a tag with key "robert" and value "approved"

### AWS Service Clients

All AWS SDK service clients must be configured with retry settings:

- `maxAttempts: 10` - Set maximum retry attempts to 10
- `retryMode: "standard"` - Use standard retry mode for consistent behavior

Example:
const orgClient = new OrganizationsClient({
  ...clientCreds,
  maxAttempts: 10,
  retryMode: "standard"
});

With these rules added, Amazon Q will now factor these rules into:

PR reviews
Code suggestions
Feature generation

When you open a PR, you will see your policies which you expressed as rules being evaluated and Q commenting on them. It is that simple.

Final Thoughts

Shift-left has always been the right goal—but it’s often failed due to complexity and poor user experience. GitHub Amazon Q Developer Project Rules finally make shift-left practical, approachable, and collaborative. It is bringing the shift-left implementation from policy-as-code to policy-as-context which lowers the barrier of adoption.

By combining:

AI-assisted PR reviews
Repository-native Markdown rules
Enforced PR conversation resolution

You get a lightweight but powerful system for embedding security, compliance, and quality directly into everyday development workflows, which about any person can contribute.

Note: If your teams are apprehensive about markdown, it is only because it is new to them. Reassure them that using the absolute basics of Microsoft Word is much harder than working with markdown.

This is one of the most effective shift-left implementations I’ve seen—and it’s only getting better.

AWS Control Tower 4.0: A New Look at Landing Zones

George Rolston — Tue, 23 Dec 2025 18:02:11 +0000

AWS Control Tower has long been the preferred solution for implementing governance based on AWS best practices, though it can be a controversial topic among SREs and Platform Engineers. With the release of Landing Zone 4.0, Control Tower takes a step forward, giving more flexibility in managing accounts and Organizational Units (OUs). This makes both greenfield and brownfield deployments easier to adopt and operate. Overall, it’s a positive development for AWS Control Tower, even though some challenges and areas for improvement still remain.

Disclaimer: Landing Zone 4.0 requires that you separate your AWS Config and CloudTrail logging buckets across accounts. Previously, both services wrote to a single S3 bucket in the Log Archive account. With Landing Zone 4.0, you will split centralized logging across two S3 buckets in two separate accounts. From my perspective, this change moves away from the intent of centralized logging, and the rationale and technical strategy behind this design decision are not yet clear.

I want to preface this by saying that this blog post focuses on the direction AWS Control Tower is heading, rather than the specifics of the 4.0 release. Ideally, I wish there would have been a longer period where both 3.3 and 4.0 were available for new deployments. From what I understand, AWS Control Tower aims to support deployments via APIs, but the rollout highlighted that a more structured release process isn’t fully in place yet, which caught many users by surprise.

Native OU and Account Management

One of the biggest enhancements in Control Tower 4.0 is the shift from a rigid, Control Tower-managed model to a more native AWS Organizations-centric approach. Previously, setting up Control Tower required specifying the name of the security OU during deployment, and Control Tower would create it and manage all accounts in it.

Now, instead of being forced to have Control Tower create the security OU, you can leverage pre-existing OUs directly into Control Tower. This allows organizations to retain control over their OU structure, integrate existing organizational hierarchies, and better align with their naming conventions and internal governance practices.

This change is particularly advantageous for brownfield deployments, where customers have already implemented multi-account best practices. Existing OUs and accounts can now be seamlessly integrated into Control Tower without the need to restructure everything around the traditional Control Tower manifest and Account Factory model.

Auto-Enrollment: Flexibility Meets Automation

Control Tower 4.0 also takes advantage of the relatively new auto-enrollment capabilities. With auto-enrollment, accounts moved into an OU registered with Control Tower using the Control Tower Baseline are automatically enrolled and provisioned with required resources. By automatically enrolling accounts into Control Tower as they are created or detected within AWS Organizations, teams no longer need to rely on manual workflows or one-off processes to apply guardrails. This ensures that baseline security, logging, and compliance controls are consistently enforced from day one, reducing the risk of configuration drift or unmanaged accounts operating outside of governance boundaries. All that is required is you move an AWS Account into a Control Towered registered OU. To unenroll, simply move the account into an OU that is not registered in AWS Control Tower.

Note: Auto-enrollment is also available in Control Tower Landing Zone 3.3. You do not need to upgrade your Landing Zone to 4.0 to start using. Simply go into the setting of your Control Tower Landing Zone and enable it.

Auto enrollment also helps organizations keep up as their environments grow. Whether adding new accounts through expansion, mergers, or acquisitions, auto enrollment makes it easier to maintain governance without piling on extra administrative work. Platform teams can spend less time managing account lifecycles, and security or compliance teams get better visibility into which accounts meet organizational standards. Overall, it helps make a multi-account AWS environment more consistent and easier to manage, even if it’s not a perfect solution.

Warning: Auto enrollment is an asynchronous process. When moving accounts in the web console give time for Control Tower to successfully process the enrollment/unenrollment of the AWS account. It is not perfect, but it is getting better…be patient.

Account Factory Not Required

These changes mark a continued shift in operational philosophy to account vending. With auto enrollment and ability to register/reregister entire OUs, Control Tower no longer requires for individual AWS accounts to be provisioned through Account Factory. In my opinion this is great as I no longer have to worry about Service Catalog products and all the troubles that can be associated with that.

Note: AWS Config is still required to be created by Control Tower. So if you are moving accounts into AWS Control Tower, you will need to ensure they do not have Config already set up.

Instead Control Tower appears to be embracing a more natural workflow via AWS Organizations:

Accounts can be created natively in AWS Organizations.
They can be moved into the appropriate OUs registered in AWS Control Tower.
Once in the OU, accounts are automatically enrolled and resources are provisioned according to Control Tower guardrails and baselines.

Note: Automation teams still need to consider Service Catalog portfolio access during register/reregistering OUs. Even if Account Factory is not used for the AWS accounts in the OU, Control Tower still does a permission check on the IAM role/user to validate they have access to the Service Catalog portfolio.

This approach lets organizations use CloudFormation StackSets, EventBridge rules, and other services tied to AWS Organizations to deploy and manage resources across multiple accounts. It helps make multi-account setups a bit smoother and easier to keep in check, without all the manual work.

Changes in Control Tower Setup with LZ 4.0

While these enhancements bring greater flexibility, they do introduce some changes to the setup process:

Pre-staging of Organization resources is now required prior to deployment.
Logging architecture has changed: LZ 4.0 uses two separate buckets in the Log Archive account—one for CloudTrail and another for AWS Config. Earlier versions (3.3 and below) used a single bucket. Customers will need to ensure that tools and pipelines referencing logs are updated to account for this split. The original bucket continues to be used for CloudTrail, so existing operations can remain intact.
The role AWSControlTowerCloudTrailRole uses an IAM AWS managed policy now instead of an inline policy. Even if permissions are exactly the same, you will encounter issues with this role if the managed policy isn’t attached.
Control Tower has an updated data structure for the manifest file
- Logging is now broken out into two different objects in the manifest
  - CloudTrail will retain the old bucket in the log archive account if you are upgrading
  - Config will get a new separate bucket in the Audit account. This should be considered heavily before upgrading your landing zone from 3.3 to 4.0.
You no longer give the name of security Organization Unit to create; instead it is assumed that both the log archive and audit accounts will exist in one OU.
AWS Config aggregator is setup and it uses trusted delegation for AWS Organizations
The manifest is optional.
After upgrading from 3.3 to 4.0, you may need to update your baselines. For most baseline versions, the version went from 4.0 to 5.0 which is confusing to say the least.

More details on changes can be found here.

Upgrade Process

Upgrading from Control Tower 3.3 to 4.0 is generally smooth if you consider all the changes from above. Though it can take time as several asynchronous operations complete. Planning for potential delays in provisioning and enrollment tasks is recommended.

The upgrade process is fully supported through API, which can significantly reduce complexity and save time when orchestrating upgrades, enrollment, and provisioning tasks programmatically. However, when using the API to update, you will need to review the Control Tower manifest and remap some of the current configurations to the new structure.

Conclusion

Control Tower 4.0 seems to be heading in a better direction for managing multi-account governance, working more closely with the native features of AWS Organizations. By enabling pre-existing OU imports, auto-enrollment, and a more natural account provisioning workflow, organizations gain:

Greater flexibility in OU and account structure
Easier integration for brownfield deployments
Alignment and enhanced operational and security automation through StackSets, EventBridge, Controls Catalog, and other organization-targeted services

Don’t get me wrong—there were some issues with the rollout and a few bumps still need smoothing out, but overall, Control Tower 4.0 is heading in the right direction.

Configuring Security Services with AWS Organizations – Part 3: AWS Security Hub

George Rolston — Mon, 08 Feb 2021 18:39:09 +0000

Welcome back to the multi-part blog of deploying AWS security services with AWS Organizations. In Part 1 I introduced you to AWS Organizations, its prerequisites, and then configured Organizational CloudFormation StackSets. In Part 2 of our series, we went through integrating AWS GuardDuty with our AWS Organization ensuring all our accounts automatically configure and enroll into our AWS GuardDuty delegated admin account. In Part 3, we will be configuring AWS Security Hub with our AWS Organization automating the configuration and enrollment of all accounts.

Overview

Security Hub is an AWS service that delivers a comprehensive view of your security posture and gives you the ability to report, ingest, and remediate security findings in your AWS account. With it you are given a single dashboard to view the overall security posture of your environment based on many common security frameworks (CIS, PCI, etc.). Security Hub not only enables this centralized dashboard in your account, but it also enables reporting across all your AWS accounts, delivering critical security insight into your environment.

Prerequisites

AWS Security Hub is built off many AWS services for reporting your security relative to industry standards and AWS best practices. Though you do not need to initially ensure these supporting AWS services are deployed, it is recommended to plan to deploy AWS GuardDuty, AWS Inspector, and AWS Config in the near future of your enterprise AWS roll-out.

If you are wondering what is CloudShell, read the first blog post.

The following prerequisites need to be met for this blog post:

Full Features enabled on your AWS Organizations
An AWS account deployed or set aside for specific use of security services
Some basic understanding of AWS CLI

INFO: If you are using AWS Control Tower, you should use the Audit account for you Security Operations functionality. AWS highly recommends this and using the account for this functionality will better enable you to take advantage of new features in the future.

What is a SOC account? A SOC account is merely an AWS account you have set aside to conduct all security operation services (and only security operations).

WARNING: As I mentioned in Part 1 of the series, DO NOT DEPLOY your security services to the Management account if you can avoid it.

Enabling Security Hub - Management Account

The first step is to go into your Management account and enabled AWS Security Hub. If you are wondering if someone already did this you can view the services already enabled by running

aws organizations list-aws-service-access-for-organization

If the output does not have anything about securityhub.amazonaws.com you should enable it by running the following command:

aws organizations enable-aws-service-access --service-principal securityhub.amazonaws.com

INFO: If you noticed that AWS Security Hub was listed as an enabled service, you should check and see if it already is setup as a delegated admin by running aws organizations list-delegated-administrators

You can verify that Security Hub is enabled at the organizational level by re-running aws organizations list-aws-service-access-for-organization. You should see output similar to the following screenshot with Security Hub listed:

Once you have enabled the service and determined it is not already delegated, you quickly delegate to the account of your liking. As stated in Part 2, you should delegate this service to your Security Operations Center (SOC). If you are using AWS Control Tower, this account is the Audit account which is automatically created when you setup Control Tower. To delegate your Security Hub master account run the following command:

## Without specifying a region, the command will delegate the
## master account in the current region of the CloudShell
aws securityhub enable-organization-admin-account --admin-account-id 123456789123

If you need any region outside of the current region you are in, run the following command replacing the --region parameter. Example here would enable Security Hub master account on Account Id 123456789123 in us-west-2

aws securityhub enable-organization-admin-account --admin-account-id 123456789123 --region us-west-2

With delegation enabled you can verify by running aws securityhub list-organization-admin-accounts which should return similar output:

After you delegate the admin account for Security Hub, you should then enable AWS Security Hub in the Management account. You need to manually enable Security Hub within the Management account for it to automatically sync/send findings to your Security Hub administrator account. The reason for this is that the Security Hub administrator account does not have ability to configure services in the Management account. Run the following command in the Management account CloudShell to enable.

aws securityhub enable-security-hub --enable-default-standards

Again, this will enable Security Hub in the current region you have your CloudShell open in. If you are running multiple regions, you need to enable Security Hub in the Management account per region by specifying the --region parameter of the command. Once completed, you are now ready to move to configuring your Security Hub delegated administrator account.

Setting up Security Hub - Delegated Admin Account

With Security Hub administration delegated, you will need to go into the delegated administrative account known as the Security Hub administrator account (this is the account you just delegated to from the Management account). When accessing the Security Hub administrator account, you should ensure your IAM role/user has admin permissions.

INFO: If you are using AWS Control Tower, you should use the Audit account for you Security Operations functionality.

When in the account change to the primary region and open the CloudShell. Within in the CloudShell make certain to first update you have updated your AWS CLI. Easy to do this is via the one-liner I setup a GitHub project I have: AwsCloudShell. With your CloudShell updated you can enable Security Hub

With you CLI updated you can start by enabling Security Hub for the regions you want to enable. This process is identical to the last step we just did in the Management account:

aws securityhub enable-security-hub --enable-default-standards

Now that Security Hub is enabled you can configure the AWS Organizations portion of it by enabling auto-enrollment for all account within your AWS Organizations. What this will do is force all newly created accounts to enable AWS Security Hub in the region and report their findings into the Security Hub administrator account. Run the following command to enable:

## ensure you updated AWS CLI prior to running the command
aws securityhub update-organization-configuration --auto-enable

With auto-enable set, you are ready to secure your environment going forward. But what about if you already have accounts that are either reporting in by invitation or are not yet configured? We will cover that next.

Post Deployment configurations

With AWS Security Hub setup to deploy automatically leveraging AWS Organizations integration, we are all set going forward. However, for accounts deployed prior to the configuration we will need to go back in and manually Add Member similar how AWS GuardDuty worked in Part 2.

NOTE: Security Hub allows accounts to be managed outside of your AWS Organization though Invitation. Only AWS accounts that are part of the Organization can be converted from Invitation to Member accounts.

To view all the accounts for Security Hub you can see their status by going to the Security Hub web console and selecting the Accounts tab in the Settings page. You can see the status as shown below circled in red.

In the screenshot you see there are three accounts and zero of them are enrolled via Organizations or Invitation. This means I have three accounts in my Organization which could be enrolled in Security Hub and none of them are by Invitation. To add these pre-existing accounts or accounts that are of Type via Invitation you can select their checkboxes and click Add Member from the Actions menu located in the top right of the Accounts page. You will see their status turn from Not a Member to Enabling to Enabled.

With that complete all your accounts are setup and reporting into your centralized Security Hub administration account. New AWS accounts will be automatically configured and enrolled in the future.

Conclusion

As you can see the process was very similar to setting up AWS GuardDuty with Organizations regarding configurations within the Management account and within the delegated administrator account. In total you had to run about five to six commands to make this all work...and you will never need to run those commands again! AWS Security Hub is now setup for automated deployment within your Organization.

What's Next?

In Part IV of the blog series I will go over configuring AWS Config Aggregator with AWS Organizations.

Configuring Security Services with AWS Organizations – Part 2: AWS GuardDuty

George Rolston — Sun, 31 Jan 2021 18:44:50 +0000

Overview

In the previous blog I showed how to setup AWS Organizations in All Features mode and and prepare the AWS environment to run my Security Operations Center (SOC) AWS Account by delegating administrative functions through AWS Organizations. Additionally, we configured AWS Organizations CloudFormation StackSets and demonstrated how the AWS CloudShell can be used and configured to deploy our services. If you have not read the blog post please visit here.

If you are wondering what is CloudShell, read the first blog post.

In this blog post I will go over deploying AWS GuardDuty as an integrated AWS Organization service which will automatically enroll all new accounts reporting GuardDuty findings into the GuardDuty Delegated Administrative account.

What Is AWS GuardDuty

AWS defines GuardDuty as:

Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, workloads, and data stored in Amazon S3.

In other words AWS GuardDuty is a service that monitors network traffic (VPC and S3) and analyzes it for malicious or suspicious behavior. Finding are reported to the AWS GuardDuty web console within the account or reports back to a central account, also know as the Delegated Administrative account. It is best to deploy GuardDuty to every account as you are only billed for utilization (so if not network traffic or S3 activity, no utilization, no noticeable cost).

Why do I need to deploy GuardDuty via Organizations?

This is a great question and many with experience of large implementations can answer it easily: technical debt. Prior to integration with AWS Organizations, AWS GuardDuty worked via Invitations from the central GuardDuty Adminsitrative account to the member account. This was not too bad, but you were stuck running CloudFormation and Lambda functions that would enable the AWS GuardDuty service in a specific region, send out a request invite from the central GuardDuty account then accept GuardDuty invitation from the member account. At the end of the day you were stuck managing that automation. There have been some great solutions, but none as simple as the AWS Organizations integration I am going to show you here. Best way to put this: you will set it once and not worry about it at all going forward.

Prerequisites

If you followed along with Part 1 meeting all the prerequisites and deploying the necessary configurations, then you are doing great. If not please go back and review Configuring Security Services with AWS Organizations: Part 1. For this blog post, the only additional prerequisite here is to have deployed a SOC account.

Note: If you are using AWS Control Tower, you should use the Audit account for you Security Operations functionality. AWS highly recommends this and using the account for this functionality will better enable you to take advantage of new features in the future.

What is a SOC account? A SOC account is merely an AWS account you have set aside to conduct all security operation services (and only security operations).

WARNING: As I mentioned in Part 1 of the series, DO NOT DEPLOY your security services to the Management account if you can avoid it.

Enabling AWS GuardDuty via Organizations

Regardless of you using AWS GuardDuty prior to configuring AWS Organizations integrated GuardDuty, the process is still the same. So starting out in the Management account, we can open the CloudShell and run a few commands to enable.

Info: If you don't know what the CloudShell is and have not read Part 1, please go back and read Part 1 of the blog series.

In the CloudShell we will make a couple of simple one-liner commands to configure AWS GuardDuty for Organizations. To start off let's enable the service for the Organization by running:

aws organizations enable-aws-service-access --service-principal guardduty.amazonaws.com

If you are looking for some status of AWS GuardDuty being configured in the AWS Organizations Settings web console, you will not find this. The AWS Organizations Settings currently only lists services that are enabled and managed out of the management account. It does not show delegated AWS Organization services at this time. To view the status of enabled AWS Organization services you can run aws organizations list-aws-service-access-for-organization. The output should list GuardDuty as enabled:

That command will enable AWS GuardDuty for the Organization. Step one is done and now we can move on to step two, which is delegating the GuardDuty administrative account. This is not really a complex process here and it consists of one or more commands depending on how many regions you need to support.

AWS GuardDuty is a regional service meaning that whatever region you are running your CloudShell in, is the region you will delegate the admin account unless specified otherwise. My recommendation is that you stick with the Audit/SOC account you identified and just enable it for the necessary regions you have workloads in. If concerned about monitoring, simply place an Service Control Policy (SCP) on all accounts restricting the regions they can run in. To enable AWS GuardDuty in the current region you are in run the following command:

aws guardduty enable-organization-admin-account —admin-account-id 123456789

If you need any region outside of the current region you are in, run the following command replacing the --region param. Example here would enable GuardDuty Admin account on Account Id 123456789 in us-west-2

aws guardduty enable-organization-admin-account —admin-account-id 123456789 --region us-west-2

Note: You don't need to deploy GuardDuty to every region possible in AWS in an attempt to monitor. Use AWS Service Control Policies to deny/allow regions you choose to operate in, then deploy GuardDuty to those regions.

The command will give AWS GuardDuty Administrative account permission to enroll and automate the configuration of AWS GuardDuty for the region for any account except the management account.

Note: Your Management account can be a member of the AWS GuarDuty Organization, but will require you to enable AWS GuardDuty in the desired region. If not enabled, you will get an error in your GuardDuty Delegated Administrative account when you try to automate the enrollment.

Once you have completed those two simple tasks of enabling and delegating AWS GuardDuty, you are done in the Management account.

The next step is to go to the AWS GuardDuty Delegated Administrative account and begin configuring the GuardDuty service.

Configuring the AWS GuardDuty Administrative Account

After properly delegating the GuardDuty service in the AWS Organization you can login to the account you assigned as the GuardDuty Delegated Administrative account and begin configuring. If this is your first time setting up GuarDuty in the AWS account you can quickly change to the region you wish and run the following command in the CloudShell to enable and create an GuardDuty detector.

aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES

The create-detector command has some key points which I pulled from the AWS documentation: To start using GuardDuty, you must create a detector in each Region where you enable the service. You can have only one detector per account per Region. All data sources are enabled in a new detector by default. Therefore, what we just did was setup AWS GuardDuty in the current region of the account and enabled all data sources.

Next, we need to take note of the output returned from the previous command and copy the detector-id value for our next command. In the following command we update our configuration for GuardDuty to auto-enable. Auto-enable means that any new AWS account created within the Organization will automatically have GuardDuty created in the region and reporting back to the GuardDuty Delegated Administrative account.

aws guardduty update-organization-configuration --detector-id [whatever detector you just created ID] --auto-enable

If you just deployed your AWS Organization and immediately set this all up, your work is limited now. The only cleanup you will have is to go back to the management account and possibly enable GuardDuty as it is not impacted by Organization integrated services.

Post Deployment Actions

If you already have AWS accounts deployed prior to configuring AWS Organization GuardDuty or that you were leveraging AWS GuardDuty by Invitation, you can convert these accounts to be managed by Organization as a Member account.

Note: GuardDuty allows accounts to be managed outside of your AWS Organization though Invitation. Only AWS accounts that are part of the Organization can be converted from Invitation to Member accounts.

To view all the accounts for AWS GuardDuty you can see their status by going to the AWS GuardDuty web console and selecting the Accounts tab in the Settings page. You can see the status as shown below circled in red.

In the screenshot you see there are 7 accounts and 0 of them are enrolled via Organizations or Invitation. This means I have 7 accounts in my Organization which could be enrolled in GuardDuty and none of them are by Invitation. To add these pre-existing accounts or accounts that are of Type via Invitation you can select their checkboxes and click Add Member from the Actions menu located in the top right of the Accounts page.

Once added as member, AWS GuardDuty will be deployed and configured to the region of the pre-existing account if not already done. The only error you may receive is from the management account which requires you to go into the management account and enable GuardDuty prior.

Note: Converting AWS GuardDuty member accounts from Invitation to Organization will have no noticeable impact to the member account. It is a simple conversion.

What's Next

In Part 3 post we will continue configuring AWS Organization integrated security services by deploying AWS Security Hub.

Configuring Security Services with AWS Organizations – Part 1: Getting Started

George Rolston — Sun, 31 Jan 2021 17:10:20 +0000

Introduction

A big part of my work is cloud security automation and when I found out AWS integrated many of the AWS security services with AWS Organizations, I simply could not wait to get started. Yet, I found that there isn’t a dead-simple guide for cloud engineers in how to deploy these security services. There are a lot of references stating you can now automate with AWS Organizations, but no one telling how. Thus, in this multi-part blog post/guide I will focus on giving the reader dead-simple one-liner commands which are to be run from the AWS CloudShell, a new feature of the AWS web console for command line access.

The best part of this guide is that you will not be required to create any IAM users, API keys, nor EC2 roles/instance profiles to run the commands. All you will need to do is copy the commands, update the params and paste into your CloudShell to run (finally no mess deployments). Once configured, you are done and then let the automation take over!

Overview

This is the first part of a series of blog posts focusing on deploying security services through AWS Organizations. In this blog post we will go over AWS Organizations prerequisites and additional configurations of your AWS Organization to enable the security services. Then we will enable AWS CloudFormation StackSets for the AWS Organization. In my opinion if you plan to automate security within your organization, you should be in some way leveraging CloudFormation StackSets as it facilitates enabling/enforcing compliance for current and future accounts. In subsequent blog posts we will deliver AWS services that are integrated with AWS Organizations.

Note: If you are managing multiple AWS Accounts within your environment you should be managing them through AWS Organizations in some faculty. To get started, visit the AWS Documentation Creating an organization

If you are like me, you just want to see a GitHub repo to review the code for reference. You can find the code to deploy these services at https://github.com/grolston/AwsOrganizations. If wanting additional services to be automated, create an issue on the project and I will do my best to document, standardize and automate.

Prerequisites

There are some assumptions here that the reader has knowledge of most of the AWS security services and working knowledge of the AWS CLI (version 2). Additionally, the following technical prerequisites need to be met:

AWS Organization setup with All Features enabled or able to be enabled
A user account/role with Administrative access to your Management account (this is the account you have or will have your AWS Organization deployed in).
An AWS Account deployed in your AWS Organization you have set aside for a Security Operations Center (not a requirement in this blog post, but required in upcoming posts).

Getting Started with CloudShell

All our configurations will done with the AWS CloudShell. As stated in the prerequisites you should already have logged in with an Admin permissions. I am sure if least privileges are a top concern, you could create a permission set to do exactly everything I describe below; however, for brevity and since this is a setup, just ensure the AWS Managed Policy AdministratorAccess is attached to the role/user you are using. Once that is verified, you can access the CloudShell and start your configurations.

Accessing the CloudShell

Within the AWS web console at the top of the page located right of the search menu is the AWS CloudShell account. Click on it to open the CloudShell and give it time to start up. Also, if your first time take note of the great features you get with your CloudShell.

AWS CloudShell comes with many pre-installed tools for you to use immediately. You can leverage AWS CLI v2, python, node.js, and even PowerShell (pwsh) is installed though not mentioned in the Welcome dialog box as referenced below.

Note: With both Python and PowerShell you will need to install the specific AWS tools needed to access the AWS API. The CloudShell session is a regional service so ensure that you are logged into the right region prior to starting your CloudShell session.

This part is important: To avoid the frustration of having your commands not work, I recommend update your CloudShell environment to latest version of AWS CLI v2. By default, CloudShell comes with AWS CLI v2 but from my experience, it was not updated to latest and was missing some of the commands we will be doing our in our setup. To avoid this, I created as simple one-liner pulled in from a github repo I have:

curl -fsS https://raw.githubusercontent.com/grolston/AwsCloudShell/main/update.sh | bash

If you want to view the extremely simple update, you can check out the project or even contribute: https://github.com/grolston/awscloudshell

The missing CLI options were noticed when configuring AWS Security Hub. AWS may have fixed this issue by updating their image they are using for the CloudShell; however, running the update can’t hurt.

When running the update you may see the version change as such:

AWS Organizations CLI

With the CloudShell you don’t need to worry about configuring the AWS CLI v2 setting a profile. It is all set and ready to go for the commands. Try it out by running a read-only command to check your configurations for your AWS Organization:

aws organizations describe-organization

Running the command will output something similar to the following:

In describing your AWS Organization, you should look for FeatureSet: “ALL” being set. AWS Organizations can be configured for Consolidated Billing or All Features. You need to enable All Features on your AWS Organization to allow you to configure the AWS Organization integrated security services we plan to use in this guide.

Important: If you already have accounts in your AWS Organization and All Features is not enabled, you should review each account in your organization. When you enable All Features on an AWS Organization with pre-existing accounts, any account that joined the Organization will receive an email notification asking to approve the All Features. Until all joined accounts approve the All Features, you cannot leverage these services nor add any transferred accounts. Thus it is important when setting up any new AWS Organization, enable All Features immediately. I say this from experience of managing many AWS Organizations over time. If a group within your AWS Organization has concerns about enabling All Features, you may want to migrate them out to a new AWS Organizations so the rest can gain the additional security features we are discussing here.

If you notice that your AWS Organization does not have all features enabled and maybe you just missed it, you can correct this by simply running the enable command (please note my aforementioned warning about enabling all features with an Organization that has pre-existing accounts and reference All Features docs.

aws organizations enable-all-features

If you are reading this and have not even created your AWS Organization, you can save yourself some hassle and just run this command from the CloudShell:

aws organizations create-organization --feature-set ALL

Running the command will produce similar output:

After creation of your AWS Organization make sure to verify your root email address when the organization is created. This one command will create the organization and enable all features. The account which you create the organization in identifies the account as the “Management Account”.

Security and the AWS Management Account

The account which you create your AWS Organization in is known as the management account. This account is also known as the master payer AWS account, payer account, or the root AWS account. The scope of this account has evolved over time from a simple AWS used to organize and consolidate billing into the Management account we know it as today. The account you select as the AWS Management account is important as it can’t be switched unless you remove the AWS Organization and even doing that it is a horrible time. The AWS Management account is the only account that can delegate AWS Organization integrated services, deploy AWS Control Tower, created new AWS accounts (linked accounts), deploy Organizational CloudFormation StackSets, create and enforce policies, deploy AWS org trails, deploy/manage AWS SSO, etc.

The Management account is also unique in the fact that AWS Service Control policies cannot be enforced on it and Organization CloudFormation stack sets cannot be deployed to it even when targeting the root OU. The AWS account is basically set apart from the rest of the organization regarding management and guardrails.

Taking all that into consideration, the AWS account should not have any end-user workloads or even compute workloads deployed to it. You should isolate your AWS Management account as much as possible and delegate every AWS Organization service to a separate account when you can. DO NOT RUN ALL YOUR AWS SECURITY SERVICES FROM THE MANAGEMENT ACCOUNT. ONLY RUN FROM THE MANAGEMENT ACCOUNT WHAT YOU ABSOLUTELY HAVE TO AND FOLLOW STRICT LEAST PRIVILEGE ROLE CREATION.

Organization Service Configuration

With All Features enabled on your AWS Organization it is time to start configuring our security services. What we will be looking at is deploying some of the core security services most enterprises should leverage. I can’t cover all the services; however, I will add additional blog posts as new services come up or requests are made to me (open an issue at the GitHub repo). For the last portion of this blog post I will cover reviewing AWS Organization Services and enabling AWS Organization CloudFormation StackSets.

Reviewing Configured AWS Organization Services

To see what services that are already configured for your AWS Organization you can run the following command in the AWS CloudShell in your Management account.

aws organizations list-aws-service-access-for-organization

Running the command will produce similar output:

As you can see from the screenshot my AWS Organization does not have any AWS Organization services setup yet though we have completed the prerequisite of enabling All Features on the AWS Organization. Let’s change that by enabling AWS Organization CloudFormation StackSets.

AWS Organizations CloudFormation StackSets

Enabling AWS Organization CloudFormation StackSets is not necessarily a security tool; however, in my opinion, you cannot effectively manage your security of a large organization without it. AWS Organizations CloudFormation StackSets enables automated provisioning of CloudFormation templates to OU targeted accounts working across accounts and regions. Even a newly created account within a targeted OU will automatically have the template provisioned to it without any user intervention. Deleted or moved accounts immediately have the CloudFormation stacks removed from their AWS accounts (no user interaction!).

To enable CloudFormation StackSets for AWS Organizations you need to use the AWS CloudFormation StackSet web console and not the AWS CloudShell. You could do this via the AWS Organizations web console under the setting, but again it is recommended by AWS at the time to do it in the AWS CloudFormation StackSet web console ( ref. Integrate Trusted Access CloudFormation ).

Within your Management account after enabling AWS Organizations All Features you will need to go to the CloudFormation web console and then go into the StackSets page.

With the StackSets page open you will see an informational dialog box to click “Enable trusted access”. Note that you have to be in the AWS account which you created the AWS Organization in (aka the Management account). Simply click on the “Enable trusted access” button is the last step and you are greeted with success

If you would like you can even bounce back into the AWS CloudShell and run the aws organizations list-aws-service-access-for-organization command to view if the AWS Organizations Trusted service is deployed:

What’s Next?

In the Part Two we will enable AWS AWS Guard Duty and AWS Security Hub to be automatically deployed to all existing and new AWS Accounts within your Organization. Each account will report their findings into our SOC AWS Account enabling and ensuring all accounts have the security services up and running.

Read the next blog post: Configuring Security Services with AWS Organizations – Part 2 AWS GuardDuty

A Simple GitHub Action for securing CloudFormation

George Rolston — Sat, 02 Jan 2021 04:29:05 +0000

If you've ever wanted to get started with continuous integration (CI) with CloudFormation, it can sometimes appear rather daunting or time consuming. Many solutions are so overly complex you end up not even using them correctly...or sometimes not at all for your projects. You are faced with deploying some solution that you have to maintain or that it is so specific you can only use it in one or two projects, and good luck having your teammates adopt it.

This all-too-common scenario drove me to create a very simple GitHub Action called cfn-security, which uses some standard security analysis/linting tools for AWS CloudFormation. The purpose of the project was to encourage people to implement better security practices in their CloudFormation through CI and get started with GitHub Actions.

The cfn-security GitHub Action does not require an AWS Account, user credentials, or dedicated deployed agents. I am hoping to lower the dependencies/prerequisites to encourage adoption of using such tools to promote cloud security. Additionally, to be kind to the GitHub user, cfn-security action does not conduct a full docker build at launch, which really reduces the minutes burned up for your GitHub Actions.

GitHub Actions is free for a specified amount of minutes a month. Reference About billing for GitHub Actions. Due to this, make sure your actions are as efficient as possible.

Currently cfn-security includes scans leveraging cfn-nag and checkov. The scans run against a specified directory where your CloudFormation templates are stored. There are only two prerequisites:

You need to be developing CloudFormation
You need your templates stored in one directory within your project

...that is it. The stars do not need to align nor do you need to provision a Jenkins server.

The action is published on the GitHub Marketplace and can be found here: https://github.com/marketplace/actions/cfn-security with further details/instructions.

Getting Started

To get started simply add a workflow .yml file (name it whatever you would like) to your .github/workflows/ folder/directory in your root directory of your project. Reference the docs on GitHub Workflow YAML syntax here. Make sure to update the cloudformation_directory variable as this is the location where the scan will look for .yml or .json files to test.

Note: a good practice is to store all your CloudFormation templates in a single directory such as ./cloudformation at the root of your project.

For more examples of cfn-security workflow files check out the project's example workflow templates. If you still do not know where to start, just cut and paste the all-security-scans.yml template which will create two security scan jobs. Just make sure to update the template input variables as necessary.

name: cfn-security Scan

on: [push]

jobs:
  ## cfn-nag security scan
  security-scan-cfn-nag:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: grolston/cfn-security@master
      with:
        cloudformation_directory: "./cloudformation/" # be sure to update as necessary!
        scanner: "cfn-nag"

  ## checkov security scan
  security-scan-checkov:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: grolston/cfn-security@master
      with:
        cloudformation_directory: "./cloudformation/" # be sure to update as necessary!
        scanner: "checkov"

The goal of this is to be as dead simple as possible to encourage adoption and understanding of static code analysis tools for CloudFormation. Security should be built into your DevOps practices at every stage and I hope this helps people get started. There are a lot of other great tools to secure your CloudFormation templates and some awesome IDE extensions that can do this locally.