Category: How-to guides

In a July 2016 AWS Blog post, I discussed how to integrate Amazon Inspector with third-party ticketing systems by using Amazon Simple Notification Service (SNS) and AWS Lambda.

This AWS Security Blog post continues in the same vein, describing how to use Amazon Inspector to automate various aspects of security management. In this post, I show you how to install the Amazon Inspector agent automatically through the Amazon EC2 Systems Manager when a new Amazon EC2 instance is launched. In a subsequent post, I will show you how to update EC2 instances automatically that run Linux when Amazon Inspector discovers a missing security patch.

An overview of EC2 Systems Manager and EC2 Simple Systems Manager (SSM)

Amazon EC2 Systems Manager is a set of services that makes it easy to manage your Windows or Linux hosts running on EC2 instances. EC2 Systems Manager does this through an agent called EC2 Simple Systems Manager (SSM), which is installed on your instances. With SSM on your EC2 instances, you can save yourself an SSH or RDP session to the instance to perform management tasks.

With EC2 Systems Manager, you can perform various tasks at scale through a simple API, CLI, or EC2 Run Command. The EC2 Run Command can execute a Unix shell script on Linux instances or a Windows PowerShell script on Windows instances. When you use EC2 Systems Manager to run a script on an EC2 instance, the output is piped to a text file in Amazon S3 for you automatically. Therefore, you can examine the output without visiting the system or inventing your own mechanism for capturing console output. (more…)

Encrypting data at rest is vital for regulatory compliance to ensure that sensitive data saved on disks is not readable by any user or application without a valid key. Some compliance regulations such as PCI DSS and HIPAA require that data at rest be encrypted throughout the data lifecycle. To this end, AWS provides data-at-rest options and key management to support the encryption process. For example, you can encrypt Amazon EBS volumes and configure Amazon S3 buckets for server-side encryption (SSE) using AES-256 encryption. Additionally, Amazon RDS supports Transparent Data Encryption (TDE).

Instance storage provides temporary block-level storage for Amazon EC2 instances. This storage is located on disks attached physically to a host computer. Instance storage is ideal for temporary storage of information that frequently changes, such as buffers, caches, and scratch data. By default, files stored on these disks are not encrypted.

In this blog post, I show a method for encrypting data on Linux EC2 instance stores by using Linux built-in libraries. This method encrypts files transparently, which protects confidential data. As a result, applications that process the data are unaware of the disk-level encryption.

First, though, I will provide some background information required for this solution. (more…)

Amazon S3 Access Control Lists (ACLs) enable you to specify permissions that grant access to S3 buckets and objects. When S3 receives a request for an object, it verifies whether the requester has the necessary access permissions in the associated ACL. For example, you could set up an ACL for an object so that only the users in your account can access it, or you could make an object public so that it can be accessed by anyone.

If the number of objects and users in your AWS account is large, ensuring that you have attached correctly configured ACLs to your objects can be a challenge. For example, what if a user were to call the PutObjectAcl API call on an object that is supposed to be private and make it public? Or, what if a user were to call the PutObject with the optional Acl parameter set to public-read, therefore uploading a confidential file as publicly readable? In this blog post, I show a solution that uses Amazon CloudWatch Events to detect PutObject and PutObjectAcl API calls in near real time and helps ensure that the objects remain private by making automatic PutObjectAcl calls, when necessary.

Note that this process is a reactive approach, a complement to the proactive approach in which you would use the AWS Identity and Access Management (IAM) policy conditions to force your users to put objects with private access (see Specifying Conditions in a Policy for more information). The reactive approach I present in this post is for “just in case” situations in which the change on the ACL is accidental and must be fixed. (more…)

The following 10 posts were the most viewed AWS Security Blog posts that we published during 2016. You can use this list as a guide to catch up on your blog reading or even read a post again that you found particularly useful.

1. How to Set Up DNS Resolution Between On-Premises Networks and AWS Using AWS Directory Service and Amazon Route 53
2. How to Control Access to Your Amazon Elasticsearch Service Domain
3. How to Restrict Amazon S3 Bucket Access to a Specific IAM Role
4. Announcing AWS Organizations: Centrally Manage Multiple AWS Accounts
5. How to Configure Rate-Based Blacklisting with AWS WAF and AWS Lambda
6. How to Use AWS WAF to Block IP Addresses That Generate Bad Requests
7. How to Record SSH Sessions Established Through a Bastion Host
8. How to Manage Secrets for Amazon EC2 Container Service–Based Applications by Using Amazon S3 and Docker
9. Announcing Industry Best Practices for Securing AWS Resources
10. How to Set Up DNS Resolution Between On-Premises Networks and AWS Using AWS Directory Service and Microsoft Active Directory

(more…)

You can use AWS security controls to detect and mitigate risks to your AWS resources. The purpose of each security control is defined by its control objective. For example, the control objective of an Amazon VPC security group is to permit only designated traffic to enter or leave a network interface. Let’s say you have an Internet-facing ecommerce website, and your security administrator has determined that only HTTP (TCP port 80) and HTTPS (TCP 443) traffic should be allowed access to the public subnet. As a result, your administrator configures a security group to meet this control objective.

What if, though, someone were to inadvertently change this security group’s rules and enable FTP or other protocols to access the public subnet from any location on the Internet? That expanded access could weaken the security posture of your assets. Consequently, your administrator might need to monitor the integrity of your company’s security controls so that the controls maintain their desired effectiveness.

In this blog post, I explore two methods for detecting unintended changes to VPC security groups. The two methods address not only control objectives but also control failures. (more…)

As part of the re:Source Mini Con for Security Services at AWS re:Invent 2016, we conducted a workshop focused on Security Assertion Markup Language (SAML) identity federation: Choose Your Own SAML Adventure: A Self-Directed Journey to AWS Identity Federation Mastery. As part of this workshop, attendees were able to submit their own federation-focused questions to a panel of AWS experts. In this post, I share the questions and answers from that workshop because this information can benefit any AWS customer interested in identity federation.

I have also made available the full set of workshop materials, lab guides, and AWS CloudFormation templates. I encourage you to use these materials to enrich your exploration of SAML for use with AWS.

Q: SAML assertions are limited to 50,000 characters. We often hit this limit by being in too many groups. What can AWS do to resolve this size-limit problem?

A: Because the SAML assertion is ultimately part of an API call, an upper bound must be in place for the assertion size.

On the AWS side, your AWS solution architect can log a feature request on your behalf to increase the maximum size of the assertion in a future release. The AWS service teams use these feature requests, in conjunction with other avenues of customer feedback, to plan and prioritize the features they deliver. To facilitate this process you need two things: the proposed higher value to which you’d like to see the maximum size raised, and a short written description that would help us understand what this increased limit would enable you to do. (more…)

Today, AWS launched AWS Organizations: a new way for you to centrally manage all the AWS accounts your organization owns. Now you can arrange your AWS accounts into groups called organizational units (OUs) and apply policies to OUs or directly to accounts. For example, you can organize your accounts by application, environment, team, or any other grouping that makes sense for your business.

Organizations removes the need to manage security policies through separate AWS accounts. Before Organizations, if you had a set of AWS accounts, you had to ensure that users in those AWS accounts had the right level of access to AWS services. You had to either configure security settings on each account individually or write a custom script to iterate through each account. However, any user with administrative permissions in those AWS accounts could have bypassed the defined permissions. Organizations includes the launch of service control policies (SCPs), which give you the ability to configure one policy and have it apply to your entire organization, an OU, or an individual account. In this blog post, I walk through an example of how to use Organizations. (more…)

You can use AWS Identity and Access Management (IAM) roles and AWS Security Token Service (STS) to set up cross-account access between AWS accounts. When you assume an IAM role in another AWS account to obtain cross-account access to services and resources in that account, AWS CloudTrail logs the cross-account activity. Starting today, CloudTrail logs AssumeRole calls in the role-owning account (the account being accessed), including the unique ID of the IAM entity (a user or role) assuming the role in the account being accessed. This additional information helps you identify the entity that requested cross-account access and then trace its subsequent cross-account activity.

In this blog post, I show how you can use the new AssumeRole log file in the role owner’s account to trace unexpected cross-account activity to its origin.

(more…)

Today, we updated the AWS Identity and Access Management (IAM) console to make it easier for you to create and manage your IAM users. These improvements include an updated user creation workflow and new ways to assign and manage permissions. The new user workflow guides you through the process of setting user details, including enabling programmatic access (via access key) and console access (via password). In addition, you can assign permissions by adding users to a group, copying permissions from an existing user, and attaching policies directly to users. We have also updated the tools to view details and manage permissions for existing users. Finally, we’ve added 10 new AWS managed policies for job functions that you can use when assigning permissions.

In this post, I show how to use the updated user creation workflow and introduce changes to the user details pages. If you want to learn more about the new AWS managed policies for job functions, see How to Assign Permissions Using New AWS Managed Policies for Job Functions.

(more…)

Some Active Directory (AD) integrated applications require custom changes to the directory schema. Today, we have added the ability for an administrator to extend the schema of AWS Directory Service for Microsoft Active Directory (Enterprise Edition), also known as Microsoft AD. Specifically, you can modify the AD schema and enable many more applications. This feature also allows you to add new attributes and object classes to your AD that your application requires and that are not present in the core AD classes and attributes. Finally, it allows you to rename and disable attributes you create.

To update your schema, you upload a compatible Lightweight Directory Access Protocol Data Interchange Format (LDIF) file through the Directory Service console or AWS SDK. LDIF is a standard for formatted text designed to exchange data and update schemas for Lightweight Directory Access Protocol (LDAP) servers such as AD. Applications that require elevated permissions, such as Enterprise or Domain Admins, might not be supported.

In this blog post, I explain schema attributes and classes, and I give an overview of LDIF files and formatting. I then walk through a use case, which adds a new attribute to the computer class object that stores the Amazon EC2 instance identifier for my EC2 instances that are joined to my Microsoft AD domain, in three main steps:

1. Create an LDIF file.
2. Import an LDIF file.
3. Validate schema updates.

I also show how to add a value to the new attribute. (more…)