AWS Archives | KirkpatrickPrice

Information security regulations and standards often require businesses to perform regular maintenance tasks to ensure compliance. For example, PCI DSS Requirement 6 says merchants must deploy critical patches within a month of release. Failure to complete these tasks on time risks non-compliance.

Unfortunately, many security-related tasks are disruptive—updating a server operating system can take the server offline. Therefore, businesses prefer to carry out patching and other potentially disruptive activities during scheduled maintenance windows. These typically occur during low traffic periods or when redundant infrastructure is available.

AWS System Manager Maintenance Windows is a cloud service that helps businesses manage and automate maintenance windows. In this article, we’ll explore what AWS Systems Manager Maintenance Windows is and how you can use it to automate compliance tasks.

What is AWS Systems Manager Maintenance Windows?

AWS Systems Manager Maintenance Windows is a capability of AWS Systems Manager, a cloud service that allows IT administrators to automate repetitive operations and management tasks. We discussed Systems Manager in-depth in How to Get Started Using AWS Systems Manager, so in this article, we’ll focus exclusively on its Maintenance Windows capability.

The Maintenance Windows service can schedule actions to be carried out at a specified time on a subset of your AWS infrastructure. It can automate actions on AWS services that include S3, EC2 nodes, Amazon DynoDB, and other services that can be used with AWS Resource Groups and Tag Editor.

Each maintenance window consists of:

A schedule that determines when to carry out tasks.
A maximum duration to limit the length of each maintenance window.
Registered targets: the cloud resources that actions will impact.
Registered tasks: the actions the system will take within the scheduled period.

What Actions Does Maintenance Windows Support?

Maintenance Windows supports various task types that are part of other Systems Manager capabilities. These include:

Run Command for executing configuration commands and tasks on managed instances, including EC2 nodes and on-premises servers and VMs.
Workflows from AWS Systems Manager’s Automation capability.
Serverless AWS Lambda functions.
AWS Step Function tasks.

Together, these task types can schedule and automate a wide range of compliance activities, including application updating, OS patching, executing shell scripts, launching serverless functions that carry out further compliance tasks, altering node configurations, and much more.

Setting Up an AWS Maintenance Window

AWS Maintenance Windows is a powerful automation tool with many different options. We can’t cover all of its features here, but to give you an idea of what’s involved in creating a maintenance window, let’s walk through a simple maintenance window set up that updates the SSM Agent installed on an EC2 instance.

Assuming We assume you have already configured Systems Manager to work with your EC2 instance, as described in the Systems Manager documentation, the set up process would be as follows:.

Navigate to AWS Systems Manager and select Maintenance Windows from the sidebar menu.
Click “Create Maintenance Window.” Provide a name and set up a schedule. Maintenance Window provides an intuitive graphical schedule builder, but you can also use rate expressions and the crontab format.
Once the maintenance window is scheduled, select it from the list. You’ll be presented with a tabbed interface where you can register tasks and designate targets.
On the Tasks tab, select Register tasks and choose Register Run Command task from the dropdown menu.
Select AWS-UpdateSSMAgent from the Command Document section and choose your instance in the Targets section.
Click Register Run Command at the bottom of the page.

As you can see, setting up scheduled automations to take care of repetitive compliance tasks is straightforward. We’ve only scratched the surface of what you can do with Maintenance Windows, so be sure to check out the Guidebook for more information.

State Manager vs. Maintenance Windows

AWS Systems Manager also has a capability called State Manager. There is some cross-over in the functionality of State Manager and Maintenance Windows. Both can be used to automate some tasks. However, State Manager may be a better choice for compliance tasks where the goal is to maintain managed node configurations in a consistent state and for compliance reporting. Before choosing a compliance automation service, read Choosing between State Manager and Maintenance Windows.

Learn About AWS Compliance with KirkpatrickPrice

To learn more about AWS compliance, visit our cloud security and compliance resources, which provide expert guidance for cloud audits, regulatory compliance, and information security, or connect with an expert today..

Everyday system management tasks can be time consuming and get in the way of the efficiency of your business operations. These tasks include OS and software patching, script execution, and service maintenance windows. Failure to complete these tasks can lead to non-compliance with information security regulations and standards.

AWS Systems Manager is a cloud service that allows businesses to automate many everyday system management tasks. Automating these tasks is a great way to ensure your organization is remaining secure and compliant without sacrificing extra time.

Using AWS Systems Manager, businesses can:

Automate time-consuming compliance activities.
Improve control over and visibility of IT assets.
Reduce the cost of compliance.
Ensure that compliance tasks are completed on schedule.
Run tasks automatically in response to CloudWatch events and other triggers.

AWS Systems Manager can automate tasks on EC2, AWS’s native cloud server hosting platform, and servers hosted on other cloud platforms and on-premises data centers to save your organization time and help you achieve your compliance goals. Let’s discuss what the AWS System Manager is, how it can help your organization, and how you can start using it today.

What Is the AWS Systems Manager?

AWS Systems Manager provides capabilities that can be configured to carry out actions on remote servers. Capabilities are divided into several categories, including:

Application management
Change management
Node management
Operations management

Each of these categories contains several capabilities. To focus on just one category, node management capabilities include compliance, which can scan nodes for inconsistent configuration; patch manager, which automates security patching and updating; and the “run command” capability, which allows users to automate the execution of scripts on managed nodes.

How Does AWS Systems Manager Work?

AWS Systems Manager is primarily an agent-based service. It depends on a software agent—the AWS Systems Manager Agent (AWS SSM)—which runs on managed nodes, including EC2 systems manager nodes, Internet of Things devices, and on-premises physical servers and virtual machines.

The user configures AWS Systems Manager capabilities via the web interface or AWS CLI. The service then interacts with the AWS SSM Agent installed on each node, which carries out the intended action, whether that is applying OS patches, verifying configurations, or any other capability.

Once an action has been performed, AWS Systems Manager can send operations data to other configured AWS services for logging, monitoring, and alerting, including CloudWatch, S3, EventBridge, and Cloud Trail.

As you can see, AWS Systems Manager can be a valuable compliance tool, allowing AWS users to schedule, automate, and enforce essential compliance tasks that might otherwise be missed. It gives businesses confidence that compliance actions are carried out in line with security and compliance policies, as well as helping them to identify potential compliance gaps and challenges.

Setting Up AWS Systems Manager for Your Cloud Environment

The set-up process for AWS Systems Manager differs depending on the capabilities you would like to use and the resources you would like to manage. However, let’s take a high-level look at setting up AWS Systems Manager for EC2 instances.

Create IAM users and groups for use with Systems Manager. Users and groups with the AmazonSSMFullAccess policy have complete access to Systems Manager capabilities, but you should configure users, groups, and roles to meet the specific needs of your organization. We strongly advise against using the AWS root user or users in the administrator’s group.
Create an IAM instance profile to permit AWS Systems Manager to perform actions on your EC2 instances.
Attach the IAM instance profile to the EC2 instances you would like to manage.
Verify that AWS SSM is installed on your EC2 instance. If you are using Amazon Machine Images (AMIs), SSM Agent is likely installed by default. You may have to manually install AWS SSM for other instances or servers.
Create a VPC endpoint for AWS Systems Manager to use. This is an essential security step, as we explain in Using VPC Endpoints to Access Systems Manager.

Be Sure Your AWS Environment is Secure

Automation is a great tool for increasing efficiency in your organization, but it is also wise to check these automation configurations regularly to ensure they are working like you intended. Let KirkpatrickPrice run a free scan of your AWS environment today so you can be sure it is secure and effective.

You can learn more about configuring and using AWS Systems Manager and SSM Agent from Amazon’s AWS Systems Manager documentation. For more information about using Systems Manager and other AWS services to improve your company’s security and compliance, visit our comprehensive cloud security resources.

AWS Network Firewall is a flexible managed firewall and intrusion detection service. It allows AWS users to control network access to resources within an AWS Virtual Private Cloud (VPC). We explored AWS Network Firewall and how it complements other AWS firewalls in What is AWS Network Firewall? In this article, we’ll dig a little deeper and show you how to deploy an AWS Network Firewall instance within a VPC hosted on your AWS cloud environment.

At a high level, the process for deploying AWS Network Firewall involves the following four steps:

Create rule groups with networking filtering rules.
Create a firewall policy that includes your rule groups.
Create a firewall that uses your firewall policy.
Configure VPC route tables so the firewall endpoint can process traffic as it moves between an internet gateway and subnets within your VPC.

The details of Step 4 differ depending on how your VPC is configured, so we’ll focus on the first three steps here.

AWS Network Firewall is a highly configurable service, and secure configuration depends on factors unique to your environment, including how your VPC, subnets, and gateways are configured. This article should not be taken as a guide to setting up a secure firewall for your AWS infrastructure.

AWS Network Firewall Prerequisites

To follow the steps outlined here, you will need an AWS VPC with the following characteristics:

At least two subnets, one of which will be used only for the AWS Network Firewall.
An Internet Gateway with routing configured to send incoming traffic to the other subnet, which should be configured to send outgoing traffic through the gateway.

The firewall subnet must have at least one available IP address. Amazon calls this configuration a simple single zone architecture with an internet gateway.

Configure Firewall Security Rules

The first step is to create firewall rules groups to contain your traffic filtering rules. For example, you might want to block incoming SSH traffic to your subnet. To do so, you would create a rule telling the firewall to drop SSH connections.

Open the AWS VPC console and select Network Firewall Rule Groups from the Network Firewall section of the sidebar menu.
Click the Create Network Firewall rule group button and give the group a name.
In the Capacity field, enter a number that represents the number of rules you expect to add to this group. If you’re experimenting, 10 should be sufficient, but be aware that you cannot change this number if you want to add more rules later.
Choose whether to create a stateless or stateful rule group.
Scroll down to the Add Rule section and enter the new rule’s protocol, name, and source and destination IP and port.
Choose whether packets matching the rule are dropped or passed.
Click the Add Rule button.
Add additional rules as required, and then click Create Stateful/Stateless Rule Group at the bottom of the page.

Learn more about how to create security rules from Amazon’s documentation.

Create a Firewall Policy

Now that you have created a rule, you can add it to a Firewall Policy.

Select Firewall Policies from the Network Firewall section of the VPC console.
Click the Create firewall policy button.
Enter a name and optional description before clicking Next.
Scroll down to the Stateless rule group or Stateful rule group forms.
Click the Add Rules Groups button, then Add my own stateful/stateless rule groups.
Choose the rule group you created in the previous step.
Click through the subsequent dialogs and then click Create firewall policy on the Review and create page.

Learn more about firewall policies from Firewall policies in AWS Network Firewall.

Deploy AWS Firewall on Your Virtual Private Cloud

The next step is to create a firewall that uses the firewall policy created in the previous step. Once the firewall is configured, it will be deployed into the firewall subnet of the VPC.

Select Firewalls from the Network Firewall section of the VPC console.
Click the Create Firewall button.
Give the firewall a name and choose your VPC from the drop-down menu.
Select the availability zone that contains your firewall subnet and then the subnet itself.
In the Associated firewall policy section, choose Associate an existing firewall policy and then choose the policy created in the previous section from the dropdown.
At the bottom of the page, click Create Firewall.

AWS will now deploy your firewall into the chosen subnet. However, the firewall does not automatically begin filtering content. To use the firewall, you must configure the VPC’s routing tables so that incoming and outgoing traffic is sent through the firewall’s endpoints. The specifics depend on how your VPC and subnets are configured, but you can learn more about VPC routing tables in Managing route tables for your VPC.

Cloud Security and Compliance with KirkpatrickPrice

KirkpatrickPrice can help your business to secure its cloud infrastructure. Our cloud security audits and remote cloud security configuration assessments ensure your AWS infrastructure is configured for optimal security and compliance. To learn more, contact a cloud security and compliance specialist or visit our cloud security resources.

Firewalls are among the most useful information security and compliance tools. Their role is to monitor traffic moving between network borders to determine whether it should be allowed to pass. Among other responsibilities, firewalls prevent unauthorized access to networks on which sensitive data is stored, making them an essential tool for businesses seeking to comply with regulations and standards that include HIPAA, PCI DSS, GDPR, SOC 2, and more.

This article explores the AWS Network Firewall, a firewall available to businesses that host sensitive data on the Amazon Web Services (AWS) platform.

What is the AWS Network Firewall?

AWS Network Firewall is a managed, auto-scaling firewall and intrusion detection and prevention service that protects Amazon Virtual Private Clouds (VPCs). It monitors and filters unwanted and unauthorized traffic into and out of VPCs. AWS Network Firewall is one of several firewalls available on the AWS platform, including Security Groups, Network Access Control Lists, and the AWS Web Application Firewall.

The AWS Network Firewall is designed to be straightforward to use and to require minimal infrastructure management following the initial deployment. As a managed service, it can be deployed quickly. It scales automatically with network traffic, removing the need for businesses to build and operate infrastructure to support essential network traffic monitoring and filtering.

AWS Network Firewall is in scope for a wide range of AWS compliance programs, which means it can be used as part of a secure system that complies with HIPAA, PCI DSS, FedRAMP, and other frameworks. However, it should be emphasized that using AWS Network Firewall is not sufficient to achieve compliance with any framework; compliance is ultimately the responsibility of AWS users.

AWS Network Firewall Features

We’ve already discussed some of AWS Network Firewall’s headline features: it’s a managed service for monitoring and filtering network traffic to and from Amazon VPCs. But there are other features that set it apart from alternative firewall services on the platform.

AWS Network Firewall operates as both a stateless and stateful firewall. Users can configure stateless rule groups that examine packets in isolation or stateful rule groups that consider the packet’s context; for example, is the packet a response to a request from a particular IP address?
It is a high-availability auto-scaling firewall. As a managed service, Amazon handles redundancy and scaling, so users can rely on their firewall’s infrastructure to grow and shrink in line with demand.
AWS Network Firewall includes an intrusion detection and prevention system. It monitors the flow traffic in real-time and can adapt to protect networks against vulnerability exploits and brute force attacks.
AWS Network Firewall integrates with other AWS security services, including the AWS Firewall Manager, allowing users to consistently organize and manage rule groups and policies.
Users can take advantage of managed rule groups, predefined rules that Amazon automatically updates to account for new software vulnerabilities. Managed rule groups significantly reduce the time and effort required to keep rules up-to-date.

We’ve highlighted some of the most attractive features here, but you can see a complete breakdown of AWS Network Firewall features in the service’s documentation.

Is AWS Network Firewall Layer 7?

AWS Network Firewall operates at Layers 3-7. These numbers refer to the OSI Model, which divides network communications into seven layers. Traditional firewalls operate at Layer 3, the network layer. They can inspect and filter packets traveling over the network, but they cannot, for example, identify attacks that exploit vulnerabilities in web applications—they have no insight into protocols that operate at Layer 7, the application layer.

In contrast, AWS Network Firewall can filter VPC network traffic at the network, application, and other layers. It is a flexible network filtering and intrusion detection service that complements AWS’s other firewall services.

What Are AWS Network Firewall Deployment Models?

To understand AWS Network Firewall deployment models, we first need to discuss how the firewall works. In short, network traffic to the VPC is routed to a firewall end-point to be examined before it enters or exits the network. The firewall endpoint is deployed within a subnet of a VPC. Ingress and egress traffic flows through the firewall endpoint subnet and then to other protected subnets containing your cloud infrastructure.

Deployment models influence where the firewall endpoint subnet is deployed. In a typical distributed deployment model, a firewall subnet is deployed into each virtual private cloud—each VPC has its own firewall subnet. This model allows VPCs to have an independently managed firewall with a unique firewall policy. It is typically used to monitor and filter traffic between the internet and a protected subnet, although there are other use cases.

In contrast, a centralized deployment model uses a centralized VPC into which one or more firewall subnets are deployed. This model is often used to inspect traffic flowing between VPCs or between a VPC and a business’s on-premises infrastructure. You can read more about deployment models in Deployment models for AWS Network Firewall.

AWS Network Firewall vs. Security Groups and NACLs

AWS Network Firewall is one of several firewall services available on AWS.

Security Groups are stateful firewalls that filter traffic to Elastic Network Interfaces typically used with EC2 instances. Security groups provide granular filtering for individual instances.
Network Access Control Lists (NACLs) are optional stateless firewalls associated with one or more subnets within a virtual private cloud.
Amazon WAF is a web application firewall that filters traffic for web applications and APIs, allowing users to block common attacks such as those included in the OWASP Top Ten.

You might be wondering why AWS needs so many firewalls. They each play a distinct role. AWS Network Firewall protects the perimeter of your virtual private cloud. It controls inbound and outbound traffic for the entire network.

In contrast, security groups are associated with individual EC2 instances and some other services. NACLs are an additional firewall that controls traffic to and from subnets, allowing users to configure rules that apply to multiple groups of instances and control traffic flowing between subnets.

Together, these firewalls give users enormous flexibility in configuring access to instances, subnets, and VPCs. For example, you may want to allow connections of a specific type into your VPC with AWS Network Firewall, but to have Network Access Control Lists that deny similar connections access to particular subnets or instances. Another use case for multiple firewalls is to run production and testing subnets, which should be able to receive requests from external networks but should not be able to communicate directly with each other.

AWS Network Firewall is one component of a layered approach to cloud security. To learn more, visit our extensive cloud security and compliance resources or contact a cloud security specialist to discuss KirkpatrickPrice’s cloud security audit and compliance audit services.

The Amazon Simple Storage Service (Amazon S3) celebrated its 15th birthday in 2021. S3 was conceived as a straightforward scalable object storage system developers could use without concerning themselves with files systems—everything on S3 is an addressable object in a bucket.

S3 quickly rose to dominate the object storage space. Because it is used everywhere, AWS S3 security as well as the privacy and confidentiality of the data businesses store in it are critical. A vulnerability in S3 would inevitably lead to data exposure on an unprecedented scale. Amazon understands this and has built security features into S3 and integrated it with security and privacy services such as AWS Identity and Access Management (IAM).

But, as with all cloud services, security is partially the responsibility of users. If S3 buckets are poorly configured, sensitive data may be exposed. This article explores ten S3 best practices your business can implement to avoid becoming the star of the next big S3 data leak story.

Ensure S3 Buckets are Not Publicly Accessible

Data leaks from S3 buckets often occur because a bucket containing sensitive files is configured to allow public access. This means anyone on the internet who knows where the bucket is can access the files. Bad actors have created tools that make it straightforward to discover buckets with public read permissions.

When buckets are first created, they are not publicly accessible. However, rather than setting up secure Bucket Policies or managing access with IAM identities, users often configure buckets for public access. This is often done for convenience: the user wants a group of people to access the data and doesn’t understand how to provide that access securely.

To check whether your buckets are publicly accessible, log into the S3 Console, click on a bucket, and select the permissions tab. Access permissions are displayed at the top. The prominent “Block public access” setting revokes the bucket’s public access configuration immediately.

You can also use the KirkpatrickPrice AWS Security Scanner to check for insecure S3 bucket permissions and other AWS cloud security vulnerabilities.

Configure Least Privilege Access

Removing public access is an essential step towards better AWS S3 security, but it is only the first step. In addition to ensuring that data can’t be accessed by everyone, you should ensure it can only be accessed by those who need the data. For example, if you want to share data in a bucket with a third party, they may only need read permissions and not write permissions.

There are several ways to configure access permissions on buckets, but you should ordinarily use either bucket policies or IAM identities.

Bucket policies are resource-based IAM policies used to manage bucket access with a list of users and permissions.
IAM identities leverage the Amazon Identity and Access Management service to configure S3 access permissions for users and roles.

Both methods improve Amazon S3 security, but IAM identities are more flexible and granular. As a general rule, it is preferable to use IAM identities as part of a comprehensive identity and access management strategy. A third access control option is Access Control Lists (ACLs); however, Amazon recommends using bucket policies or IAM identities instead.

Implement S3 Encryption At Rest

Data stored in S3 buckets should be encrypted. Encryption ensures the data cannot be read if it is exposed through a vulnerability or misconfiguration. S3 provides three server-side encryption options:

SSE-S3 — encryption with keys managed by the S3 service.
SSE-KMS — encryption using keys stored in AWS Key Management Service.
SSE-C — encryption using keys provided by the customer.

Any of these options significantly improve security compared to storing unencrypted data in S3. However, SSE-KMS gives the user more control over their keys, allowing them to, for example, rotate keys as required.

Implement S3 Encryption in Transit

In addition to encrypting data at rest in Amazon S3, it should be encrypted in transit as it moves over the network. Data is automatically encrypted within the AWS network, but users should consider leveraging SSL/TLS when moving data across external networks, including the internet.

Store S3 Credentials Securely

If your applications access data stored in S3 buckets via the API, they will need to authenticate. To do so, they will use an AWS access key, a long-term credential associated with an IAM user that is used for programmatic authentication.

Improper use of AWS access keys can create security vulnerabilities. One common mistake is to embed access keys in code. Access keys embedded into code and then shared on version control platforms have been the root cause of many data leaks.

AWS access keys should be securely stored in AWS Secrets Manager, as we discussed in depth in How to Keep AWS Access Keys and Other Secrets Safe.

Use IAM Roles for Temporary S3 Access

Roles are IAM identities with a set of permissions. However, roles are not associated with an individual user, although users and other entities can assume a role to take on its permissions. In this context, the main benefit of roles is that they can be used to create temporary credentials which expire after a specified period, in contrast to IAM users’ access keys, which are permanent until deleted.

Enable Multi-Factor Authentication for IAM Users

Multi-factor authentication adds an extra layer of security to the standard username and password authentication. With MFA enabled, users must supply an additional factor of authentication—a one-time code or a hardware security key. Usernames and passwords can leak or be shared inappropriately. TFA ensures that accounts remain secure even if credentials are exposed.

Enable S3 Access Logs

Access logs allow administrators to identify unusual and unexpected access patterns that may indicate a security breach. They are also useful when analyzing security incidents to discover which data has been exposed, information that may be essential to fulfilling regulatory requirements.

S3 does not ordinarily log who has accessed data and which data they have accessed, but users can activate access logs. Amazon will log access requests and store the resulting log files in a different S3 bucket. The log storage bucket should have strict access permissions to ensure bad actors can’t alter the log or use the information it contains to plan an attack.

Classify Data Stored in S3 Buckets

Many regulatory standards govern the secure storage of sensitive data, particularly health data, financial data, and personally identifiable information (PII). S3 is a viable option for storing sensitive data, if correctly configured. But to be compliant, it’s important to know which data you’re storing in the first place—accidentally dumping a database full of PII in a bucket with broad access permissions is likely to result in compliance and audit failures.

Before data is stored in S3, it should be classified and subject to a risk assessment so that businesses are aware of what they are storing and the associated risks. Amazon provides a service that can help businesses to discover sensitive information in S3 buckets. Amazon Macie is a data privacy service that uses machine learning and pattern matching to automatically identify sensitive data and alert users about insecure access permissions.

Verify S3 Bucket Configurations

Our last Amazon S3 security best practice is to check bucket configurations and IAM permissions regularly. Over time, your AWS environment will evolve from its initial conditions.

Partner with KirkpatrickPrice to Improve Your S3 Security

The KirkpatrickPrice AWS Security Scanner and cloud security audits help businesses verify their cloud security and privacy. To learn more, browse our extensive cloud security resources or contact an information security specialist today.