Spend on Cloud Security Will Double

As use of the public cloud grows so do investments in protecting those assets. According to Forrester’s report, “Cloud Security Solutions Forecast, 2018- 2023” spend on security will double from $6.3 billion in 2018 to $12.6 billion in 2023.¹ One of the main drivers of Foghorn’s growth in AWS consulting is sharing the best practices that we have gleaned over the past decade of architecting secure solutions in the cloud. In this two part series we will share the specifics behind how Foghorn implements AWS cloud security best practices.

In this section we will cover IAM. Part 2 will cover best practices for securing your cloud infrastructure on AWS.

Identity and Access Management

Protecting AWS Credentials

AWS credentials, if not managed carefully, can put at risk a companies’ entire cloud infrastructure, applications, and data to malicious actors.  One of the key tenets of AWS cloud security is protecting these credentials, as they are effectively the “keys to the kingdom”.

Foghorn recommends the following controls:

Root Credentials

Each AWS account comes with initial account credentials, which are used to bootstrap the account.  These credentials have full access to the account, and require special protections. Foghorn follows the following procedures when creating new accounts.:

• Create New Accounts
• Change Root Password to long, strong password.
• Enable MFA on root account
• Securely store the MFA and credentials offline.

This account is rarely if ever used, and its use should be avoided whenever possible.  We advocate for the use of IAM roles where services and access are provisioned for individual users based on specific AWS APIs. Depending on a company’s preference, they can choose  to set up IAM users directly in their account, or they could be configured for SSO. 

IAM Users

Many of our smaller customers chose this option for its simple, straightforward implementation.  With the IAM User approach we provision a set of groups based on the roles that we have identified in your organization, and then apply least permission policies to those groups.  IAM user accounts are then provisioned for each user. Accounts are configured to require long, strong passwords. Permissions are configured to only allow access to resources once MFA for the account is configured. Finally, a password rotation is enforced.  Once configured everything is automated and there is not a requirement for manual procedures to maintain the security policy for console access.

SSO

If a company choses SSO integration, then their current SSO login will give the correct least permission access to one or more AWS accounts.  This integration ensures that existing user management processes have been extended to a companies’ cloud infrastructure.

Automated Access

For SDK or CLI access to the AWS API, each user that requires access to this functionality is provisioned with an access key and secret key for their account, with assume role privileges.  Foghorn recommends quarterly key rotation, and depending on the engagement model, the client or Foghorn reports on these and/or actively disables keys that are out of compliance.

For all workloads that require access to AWS resources, (for instance the right to read and write to/from an S3 bucket), an IAM instance profile can be created with least permission, and associated with the appropriate AWS resources.

Fine Grained Authorization

It is best practice to ensure that least privilege is implemented in a fine grained manner, down to the resource level. For instance, administrators who need to be able to terminate instances associated with your JIRA implementation need not also have the capability to terminate instances associated with your customer facing web application. Foghorn has created least permission policies and associates these with user groups and roles as appropriate.  In order to make these policies bullet proof and easy to manage, Foghorn recommends partitioning major workloads and environments with separate AWS accounts, with access via cross account roles from either the SSO account or the main IAM user account.

Sandboxes can be transformative tools for DevOps teams, and with the correct IAM policies and safeguards can be entirely secure.

Detective Controls

Log Capture and Analysis

Foghorn enables Cloudtrail in all of our client’s accounts. Cloudtrail logs all API activities.  Foghorn configures Cloudtrail to deliver logs to a security account, where they cannot be tampered with if account credentials are compromised.  We advise that a set of Cloudwatch alerts be enabled that reflect certain Cloudwatch events that are preconfigured in accounts. Alerts are forwarded to a shared Slack channel.  This functionality can easily be extended to system logs or application logs for any of a client’s workloads by integrating those workloads with cloudwatch logs. 

For compliance purposes, we recommend enabling Flowlogs on VPCs that host sensitive workloads.  These logs are available for network and security teams to plug into via IAM permissions.

IAM Audit Notifications

Foghorn understands that cloud environments are dynamic, which requires the ability for devops teams to quickly add and change IAM permissions on various users, groups, and roles.  This however can become a vehicle for vulnerabilities to be introduced into the environment. For this reason, Foghorn recommends configuring cloudwatch events which can be integrated with custom Foghorn alerting code that runs in Lambda.  This code monitors for material changes to IAM permissions where they are shared with our shared client/Foghorn Slack channel. If a devops engineer (either a Foghorn engineer or a client engineer) intentionally makes a change that is required an alert is triggered and an alert will be sent to the slack channel. Alerts that are left unmentioned can be treated as potential security events, and depending on our engagement with the client, either their security team or Foghorn initiates an incident event.

We hope this overview of IAM best practices has been helpful. Stay tuned for Part 2 of our AWS Cloud Security Best Practices. And as always, don’t hesitate to reach out if we can assist with helping to make your cloud more secure.

¹ https://www.eweek.com/security/cloud-security-spending-set-to-grow-forrester-forecasts