We expand AWS by picking a geographic area (which we call a Region) and then building multiple, isolated Availability Zones in that area. Each Availability Zone (AZ) has multiple Internet connections and power connections to multiple grids.
Today I am happy to announce that we are opening our 50th AWS Availability Zone, with the addition of a third AZ to the EU (London) Region. This will give you additional flexibility to architect highly scalable, fault-tolerant applications that run across multiple AZs in the UK.
Since launching the EU (London) Region, we have seen an ever-growing set of customers, particularly in the public sector and in regulated industries, use AWS for new and innovative applications. Here are a couple of examples, courtesy of my AWS colleagues in the UK:
Enterprise – Some of the UK’s most respected enterprises are using AWS to transform their businesses, including BBC, BT, Deloitte, and Travis Perkins. Travis Perkins is one of the largest suppliers of building materials in the UK and is implementing the biggest systems and business change in its history, including an all-in migration of its data centers to AWS.
Startups – Cross-border payments company Currencycloud has migrated its entire payments production, and demo platform to AWS resulting in a 30% saving on their infrastructure costs. Clearscore, with plans to disrupting the credit score industry, has also chosen to host their entire platform on AWS. UnderwriteMe is using the EU (London) Region to offer an underwriting platform to their customers as a managed service.
Public Sector -The Met Office chose AWS to support the Met Office Weather App, available for iPhone and Android phones. Since the Met Office Weather App went live in January 2016, it has attracted more than half a million users. Using AWS, the Met Office has been able to increase agility, speed, and scalability while reducing costs. The Driver and Vehicle Licensing Agency (DVLA) is using the EU (London) Region for services such as the Strategic Card Payments platform, which helps the agency achieve PCI DSS compliance.
For a complete list of AWS Regions and Services, visit the AWS Global Infrastructure page. As always, pricing for services in the Region can be found on the detail pages; visit our Cloud Products page to get started.
As companies mature in their cloud journey, they implement layered security capabilities and practices in their cloud architectures. One such practice is to continually assess golden Amazon Machine Images (AMIs) for security vulnerabilities. AMIs provide the information required to launch an Amazon EC2 instance, which is a virtual server in the AWS Cloud. A golden AMI is an AMI that contains the latest security patches, software, configuration, and software agents that you need to install for logging, security maintenance, and performance monitoring. You can build and deploy golden AMIs in your environment, but the AMIs quickly become dated as new vulnerabilities are discovered.
A security best practice is to perform routine vulnerability assessments of your golden AMIs to identify if newly found vulnerabilities apply to them. If you identify a vulnerability, you can update your golden AMIs with the appropriate security patches, test the AMIs, and deploy the patched AMIs in your environment. In this blog post, I demonstrate how to use Amazon Inspector to set up such continuous vulnerability assessments to scan your golden AMIs routinely.
Amazon Inspector performs security assessments of Amazon EC2 instances by using AWS managed rules packages such as the Common Vulnerabilities and Exposures (CVEs) package. The solution in this post creates EC2 instances from golden AMIs and then runs an Amazon Inspector security assessment on the created instances. When the assessment results are available, the solution consolidates the findings and advises you about next steps. Furthermore, the solution schedules an Amazon CloudWatch Events rule to run the golden AMI vulnerability assessments on a regular basis.
The following solution diagram illustrates how this solution works.
Here’s how this solution works, as illustrated in the preceding diagram:
A scheduled CloudWatch Events event triggers the StartContinuousAssessmentAWS Lambda function, which starts the security assessment of your golden AMIs.
The StartContinuousAssessment Lambda function performs the following actions:
It reads a JSON parameter stored in the AWS Systems Manager (Systems Manager) Parameter Store. This JSON parameter contains the following metadata for each golden AMI:
InstanceType – A valid instance-type for launching an EC2 instance of the golden AMI.
Later in this blog post, I provide instructions for creating this JSON parameter.
For each AMI specified in the JSON parameter, the Lambda function creates an EC2 instance. When each instance starts, it installs the Amazon Inspector agent by using the user-data script provided in the JSON. The Lambda function then copies each golden AMI’s tags (you will assign custom metadata in the form of tags to each golden AMI when you set up the solution) to the corresponding EC2 instance. The function also adds a tag with the key of continuous-assessment-instance and value as true. This tag identifies EC2 instances that require regular security assessments. The Lambda function copies the AMI’s tags to the instance (and later, to the security findings found for the instance) to help you identify the golden AMIs for each security finding. After you analyze security findings, you can patch your golden AMIs.
The first time the StartContinuousAssessment function runs, it creates:
An Amazon Inspector assessment template: The template contains a reference to the Amazon Inspector assessment target created in the preceding step and the following AWS managed rules packages to evaluate:
For subsequent assessments, the StartContinuousAssessment function reuses the target and the template created during the first run of StartContinuousAssessment function.
Note: Amazon Inspector can start an assessment only after it finds at least one running Amazon Inspector agent. To allow EC2 instances to boot and the Amazon inspector agent to start, the Lambda function waits four minutes. Because the assessment runs for approximately one hour and boot time for EC2 instances typically takes a few minutes, all Amazon Inspector agents start before the assessment ends.
The Lambda function then runs the assessment. The Amazon Inspector agents collect behavior and configuration data, and pass it to Amazon Inspector. Amazon Inspector analyzes the data and generates Amazon Inspector findings, which are possible security findings you may need to address.
After the Lambda function completes the assessment, Amazon Inspector publishes an assessment-completion notification message to an Amazon SNS topic called ContinuousAssessmentCompleteTopic. SNS uses topics, which are communication channels for sending messages and subscribing to notifications.
The notification message published to SNS triggers the AnalyzeInspectorFindings Lambda function, which performs the following actions:
Associates the tags of each EC2 instance with security findings found for that EC2 instance. This enables you to identify the security findings using the app-name tag you specified for your golden AMIs. You can use the information provided in the findings to patch your golden AMIs.
Terminates all instances associated with the continuous-assessment-instance=true tag.
Aggregates the number of findings found for each EC2 instance by severity and then publishes a consolidated result to an SNS topic called ContinuousAssessmentResultsTopic.
How to deploy the solution
To deploy this solution, you must set it up in the AWS Region where you build your golden AMIs. If that AWS Region does not support Amazon Inspector, at the end of your continuous integration pipeline, you can copy your AMIs to an AWS Region where Amazon Inspector assessments are supported. To learn more about continuous integration pipelines, see What is Continuous Integration?
To deploy continuous golden AMI vulnerability assessments in your AWS account, follow these steps:
Tag your golden AMIs – Tagging your golden AMIs lets you search assessment result findings based on tags after Amazon Inspector completes an assessment.
Store your golden AMI metadata in the Systems Manager Parameter Store – Prepare and store the golden AMI metadata in the Systems Manager Parameter Store. The StartContinuousAssessment Lambda function reads golden AMI metadata and starts assessing for vulnerabilities.
Run the supplied AWS CloudFormation template and subscribe to an SNS topic to receive assessment results – Set up the infrastructure required to run vulnerability assessments and subscribe to an SNS topic to receive assessment results via email.
Test golden AMI vulnerability assessments – Ensure you have successfully set up the required resources to run vulnerability assessments.
Set up a CloudWatch Events rule for triggering continuous golden AMI vulnerability assessments – Schedule the execution of vulnerability assessments on a regular basis.
1. Tag your golden AMIs
You can search assessment findings based on golden AMI tags after Amazon Inspector completes an assessment.
To tag a golden AMI by using the AWS Management Console:
Choose your AMI from the list, and then choose Actions > Add/Edit Tags.
Choose Create Tag. In the Key column, type app-name. In the Value column, type your application name. Following the same steps, create the app-version and app-environment tags. Choose Save.
Now that you have tagged your golden AMIs, you need to create golden AMI metadata, which will be read by the StartContinuousAssessment function to initiate vulnerability assessments. You will store the golden AMI metadata in the Systems Manager Parameter Store.
2. Store your golden AMI metadata in the Systems Manager Parameter Store
This solution reads golden AMI metadata from a parameter stored in the Systems Manager Parameter Store. The metadata must be in JSON format and must contain the following information for each golden AMI:
Step A: Find the AMI ID of your golden AMI.
An AMI ID uniquely identifies an AMI in an AWS Region and is a required parameter for launching an EC2 instance from a golden AMI. To find the AMI ID of your golden AMI:
Choose Launch Instance. On the Choose an Amazon Machine Image (AMI) page, choose My AMIs.
Type the AMI ID that you noted in Step A in the Search my AMIs box, and then choose Enter.
The search result will contain your golden AMI. To choose it, choose Select.
Locate any available Instance Type and then note the corresponding value in the Type column.
Note: Amazon Inspector will launch the chosen InstanceType every time the vulnerability assessment runs.
Step C: Create the user-data script to install and start the Amazon Inspector agent.
The user-data script automates the installation of software packages when an EC2 instance launches for the first time. In this step, you create an operating system specific, JSON-compatible user-data script that installs and starts the Amazon Inspector agent.
Identify the command that installs the Amazon Inspector agent
Based on Running Commands on Your Linux Instance at Launch, you make a Linux shell script user-data compatible by prefixing it with a #!/bin/bash. In this step, you add the #!/bin/bash prefix to the script from the preceding step. The following is the user-data compatible version of the script from the preceding step.
The user-data script provided in the JSON metadata must be JSON-compatible, which you will do next.
Make the user-data script JSON compatible
To make the user-data script JSON compatible, you must replace all new-line characters with a \r\n\r\n sequence. The following is the JSON-compatible user-data script that you specify for your Amazon Linux-based golden AMI in Step D.
Repeat Steps A, B, and C to find the Ami Id, InstanceType, and UserData for each of your golden AMIs. When you have this metadata, you can create the JSON document of metadata for all your golden AMIs. The StartContinuousAssessment Lambda function reads this JSON to start golden AMI vulnerability assessments.
Step D: Create a JSON document of metadata of all your golden AMIs.
Use the following template to create a JSON document:
Replace all placeholder values with values corresponding to your first golden AMI. If your golden AMI is Amazon Linux-based, you can specify the userData as the JSON-compatible-user-data-for-Amazon-Linux-AMI from Step C.5. Next, replace the placeholder values for your second golden AMI. You can add more entries to your JSON document, if you have more than two golden AMIs.
Note: The total number of characters in the JSON document must be fewer than or equal to 4,096 characters, and the number of golden AMIs must be fewer than 500. You must verify whether your account has permissions to run one on-demand EC2 instance for each of your golden AMIs. For information about how to verify service limits, see Amazon EC2 Service Limits.
Now that you have created the JSON document of your golden AMIs, you will store the JSON document in a Systems Manager parameter. The StartContinuousAssessment Lambda function will read the metadata from this parameter.
Step E: Store the JSON in a Systems Manager parameter.
Choose Create subscription. In the Topic ARN field, paste the ARN of ContinuousAssessmentResultsTopic that you noted in the previous section.
In the Protocol drop-down, choose Email.
In the Endpoint box, type the email address where you will receive notifications.
Choose Create subscription.
Navigate to your email application and open the message from AWS Notifications. Click the link to confirm your subscription to the SNS topic.
4. Test golden AMI vulnerability assessments
Before you schedule vulnerability assessments, you should test the process by running the StartContinuousAssessment function. In this test, you trigger a security assessment and monitor it. You then receive an email after the assessment has completed, which shows that vulnerability assessments have been successfully set up.
On Dashboard under Recent Assessment Runs, you will see an entry with the status, Collecting Data. This status indicates that Amazon Inspector agents are collecting data from instances running your golden AMIs. The agents collect data for an hour and then Amazon Inspector analyzes the collected data.
After Amazon Inspector completes the assessment, the status in the console changes to Analysis complete. Amazon Inspector then publishes an SNS message that triggers the AnalyzeInspectionReports Lambda function. When AnalyzeInspectionReports publishes results, you will receive an email containing consolidated assessment results. You also will be able to see the findings.
To see the findings in Amazon Inspector’s Findings section:
In the navigation pane, choose Assessment Runs. In the table on the Amazon Inspector – Assessment Runs page, choose the findings of the latest assessment run.
Choose the settings () icon and choose the appropriate tags to see the details of findings, as shown in the following screenshot. The findings also contain information about how you can address each underlying vulnerability.
Having verified that you have successfully set up all components of golden AMI vulnerability assessments, you now will schedule the vulnerability assessments to run on a regular basis to give you continual insight into the health of instances created from your golden AMIs.
5. Set up a CloudWatch Events rule for triggering continuous golden AMI vulnerability assessments
The last step is to create a CloudWatch Events rule to schedule the execution of the vulnerability assessments on a daily or weekly basis.
In the navigation pane, choose Rules > Create rule.
On the Event Source page, choose Schedule. Choose Fixed rate of and specify the interval (for example, 1 day).
For Targets, choose Add target and then choose Lambda function.
For Function, choose the StartContinuousAssessment function.
Choose Configure Input.
Choose Constant (JSON text).
In the box, paste the following JSON code.
Choose Configure details.
For Rule definition, type ContinuousGoldenAMIAssessmentTrigger for the name, and type as the description, This rule triggers the continuous golden AMI vulnerability assessment process.
Choose Create rule.
The vulnerability assessments are executed on the first occurrence of the schedule you chose while setting up the CloudWatch Events rule. After the vulnerability assessment is executed, you will receive an email to indicate that your continuous golden AMI vulnerability assessments are set up.
To get visibility into the security of your EC2 instances created from your golden AMIs, it is important that you perform security assessments of your golden AMIs on a regular basis. In this blog post, I have demonstrated how to set up vulnerability assessments, and the results of these continuous golden AMI vulnerability assessments can help you keep your environment up to date with security patches. To learn how to patch your golden AMIs, see Streamline AMI Maintenance and Patching Using Amazon EC2 Systems Manager.
If you have comments about this blog post, submit them in the “Comments” section below. If you have questions about implementing the solution in this post, start a new thread on the Amazon Inspector forum or contact AWS Support.
AWS is excited to announce that the AWS EU (London) Region has achieved Public Services Network (PSN) assurance. This means that the EU (London) Region can now be connected to the PSN (or PSN customers) by PSN-certified AWS Direct Connect partners. PSN assurance demonstrates to our UK Public Sector customers that the EU (London) Region has met the stringent requirements of PSN and provides an assured platform on which to build UK Public Sector services. Customers are required to ensure that applications and configurations applied to their AWS instances meet the PSN standards, and they must undertake PSN certification for the content, platform, applications, systems, and networks they run on AWS (but no longer need to include AWS infrastructure and products in their certification).
In conjunction with our Standardized Architecture for UK-OFFICIAL, PSN assurance enables UK Public Sector organizations to move their UK-OFFICIAL classified data to the EU (London) Region in a controlled and risk-managed manner. AWS has also created a UK-OFFICIAL on AWS Quick Start, which provisions an environment suitable for UK-OFFICIAL classified data. This Quick Start includes guidance and controls that help public sector organizations manage risks and ensure security when handling UK-OFFICIAL information assets.
On 4 and 5 March 2017, more than 1,800 people got together in Cambridge to celebrate five years of Raspberry Pi and Code Club. We had cake, code, robots, explosions, and unicorn face paint. It was all kinds of awesome.
It’s hard to believe that it was only five years ago that we launched the first Raspberry Pi computer. Back then, our ambitions stretched to maybe a few tens of thousands of units, and our hope was simply that we could inspire more young people to study computer science.
Fast forward to 2017 and the Raspberry Pi is the third most successful computing platform of all time, with more than twelve and a half million units used by makers, educators, scientists, and entrepreneurs all over the world (you can read more about this in our Annual Review).
On 28 February, we announced the latest addition to our family of devices, the Raspberry Pi Zero W, which brings wireless connectivity and Bluetooth to the Pi Zero for an astonishing $10. You seemed to like it: in the four days between the product launch and the first day of the Birthday Party, we sold more than 100,000 units. We absolutely love seeing all the cool things you’re building with them!
Celebrating our community
Low-cost, high-performance computers are a big part of the story, but they’re not the whole story. One of the most remarkable things about Raspberry Pi is the amazing community that has come together around the idea that more people should have the skills and confidence to get creative with technology.
For every person working for the Raspberry Pi Foundation, there are hundreds and thousands of community members outside the organisation who advance that mission every day. They run Raspberry Jams, volunteer at Code Clubs, write educational resources, moderate our forums, and so much more. The Birthday Party is one of the ways that we celebrate what they’ve achieved and say thank you to them for everything they’ve done.
Over the two days of the celebration, there were 57 workshops and talks from community members, including several that were designed and run by young people. I managed to listen to more of the talks this year, and I was really impressed by the breadth of subjects covered and the expertise on display.
Thanks to my panel of @raspberry_pi certified educators – you are all amazing! #piparty https://t.co/0psnTEnfxq
One of the goals for this year’s event was to give everyone the opportunity to get hands-on experience of digital making and, even if you weren’t able to get a place at one of the sold-out workshops, there were heaps of drop-in and ask-the-expert sessions, giving everyone the chance to get involved.
The marketplace was one of this year’s highlights: it featured more than 20 exhibitors including the awesome Pimoroni and Pi Hut, as well as some great maker creations, from the Tech Wishing Well to a game of robot football. It was great to see so many young people inspired by other people’s makes.
Code Club’s celebrations
As I mentioned before, this year’s party was very much a joint celebration, marking five years of both Raspberry Pi and Code Club.
Since its launch in 2012, Code Club has established itself as one of the largest networks of after-school clubs in the world. As well as celebrating the milestone of 5,000 active Code Clubs in the UK, it was a real treat to welcome Code Club’s partners from across the world, including Australia, Bangladesh, Brazil, Canada, Croatia, France, New Zealand, South Korea, and Ukraine.
Representatives of Code Club International, up for a birthday party!
Our amazing team
There are so many people to thank for making our fifth Birthday Party such a massive success. The Cambridge Junction was a fantastic venue with a wonderful team (you can support their work here). Our friends at RealVNC provided generous sponsorship and practical demonstrations. ModMyPi packed hundreds of swag bags with swag donated by all of our exhibitors. Fuzzy Duck Brewery did us proud with another batch of their Irrational Ale.
We’re hugely grateful to Sam Aaron and Fran Scott who provided the amazing finales on Saturday and Sunday. No party is quite the same without an algorave and a lot of explosions.
Most of all, I want to say a massive thank you to all of our volunteers and community members: you really did make the Birthday Party possible, and we couldn’t have done it without you.
One of the things we stand for at Raspberry Pi is making computing and digital making accessible to all. There’s a long way to go before we can claim that we’ve achieved that goal, but it was fantastic to see so much genuine diversity on display.
Probably the most important piece of feedback I heard about the weekend was how welcoming it felt for people who were new to the movement. That is entirely down to the generous, open culture that has been created by our community. Thank you all.
The Amazon Inspector security assessment service can evaluate the operating environments and applications you have deployed on AWS for common and emerging security vulnerabilities automatically. As an AWS-built service, Amazon Inspector is designed to exchange data and interact with other core AWS services not only to identify potential security findings, but also to automate addressing those findings.
In this post’s example, I find a common vulnerability and exposure (CVE) for a missing update and use Lambda to call the Amazon EC2 Systems Manager to update the instance. However, this is just one use case and the underlying logic can be used for multiple cases such as software and application patching, kernel version updates, security permissions and roles changes, and configuration changes.
The solution in this blog post does the following:
Launches a new Amazon EC2 instance, deploying the EC2 Simple Systems Manager (SSM) agent and its role to the instance.
Deploys the Amazon Inspector agent to the instance by using EC2 Systems Manager.
Creates an SNS topic to which Amazon Inspector will publish messages.
Configures an Amazon Inspector assessment template to post finding notifications to the SNS topic.
Creates the Lambda function that is triggered by notifications to the SNS topic and uses EC2 Systems Manager from within the Lambda function to perform automatic remediation on the instance.
1. Launch an EC2 instance with EC2 Systems Manager enabled
In my previous Security Blog post, I discussed the use of EC2 user data to deploy the EC2 SSM agent to a Linux instance. To enable the type of autoremediation we are talking about, it is necessary to have the EC2 Systems Manager installed on your instances. If you already have EC2 Systems Manager installed on your instances, you can move on to Step 2. Otherwise, let’s take a minute to review how the process works:
While launching the instance with the EC2 launch wizard, associate the role you just created with the new instance and provide the appropriate script as user data for your operating system and architecture to install the EC2 Systems Manager agent as the instance is launched. See the process and scripts.
Note: You must change the scripts slightly when copying them from the instructions to the EC2 user data. The word region in the curl command must be replaced with the AWS region code (for example, us-east-1).
2. Deploy the Amazon Inspector agent to the instance by using EC2 Systems Manager
You can deploy the Amazon Inspector agent with EC2 Systems Manager, with EC2 instance user data, or by connecting to an EC2 instance via SSH and running the installation steps manually. Because you just installed the EC2 SSM agent, you will use that method.
To deploy the Amazon Inspector agent:
Navigate to the EC2 console in the desired region. In the navigation pane, choose Command History under Commands near the bottom of the list.
Choose Run a command.
Choose the AWS-RunShellScript command document, and then choose Select instances to specify the instance that you created previously. Note: If you do not see the instance in that list, you probably did not successfully install the EC2 SSM agent. This means you have to start over with the previous section. Common mistakes include failing to associate a role with the instance, failing to associate the correct policy with the role, or providing an incorrect user data script.
3. Create an SNS topic to which Amazon Inspector will publish messages
Amazon SNS uses topics, communication channels for sending messages and subscribing to notifications. You will create an SNS topic for this solution to which Amazon Inspector publishes messages whenever there is a security finding. Later, you will create a Lambda function that subscribes to this topic and receives a notification whenever a new security finding is generated.
Choose Create topic. Type a topic name and a display name, and choose Create topic.
From the list of displayed topics, choose the topic that you just created by selecting the check box to the left of the topic name, and then choose Edit topic policy from the Other topic actions drop-down list.
In the Advanced view tab, find the Principal section of the policy document. In that section, replace the line that says “AWS”: “*” with the following text: “Service”: “inspector.amazonaws.com” (see the following screenshot).
Choose Update policy to save the changes.
Choose Edit topic policy On the Basic view tab, set the topic policy to allow Only me (topic owner) to subscribe to the topic, and choose Update policy to save the changes.
4. Configure an Amazon Inspector assessment template to post finding notifications to the SNS topic
An assessment template is a configuration that tells Amazon Inspector how to construct a specific security evaluation. For example, an assessment template can tell Amazon Inspector which EC2 instances to target and which rules packages to evaluate. You can configure a template to tell Amazon Inspector to generate SNS notifications when findings are identified. In order to enable automatic remediation, you either create a new template or modify an existing template to set up SNS notifications to the SNS topic that you just created.
Choose Assessment templates in the navigation pane.
Choose one of your existing Amazon Inspector assessment templates. If you need to create a new Amazon Inspector template, type a name for the template and choose the Common Vulnerabilities and Exposures rules package. Then go back to the list and select the template.
Expand the template so that you can see all the settings by choosing the right-pointing arrowhead in the row for that template.
Choose the pencil icon next to the SNS topics.
Add the SNS topic that you created in the previous section by choosing it from the Select a new topic to notify of events drop-down list (see the following screenshot).
Choose Save to save your changes.
5. Create the Lambda autoremediation function
Now, create a Lambda function that listens for Amazon Inspector to notify it of new security findings, and then tells the EC2 SSM agent to run the appropriate system update command (apt-get update or yum update) if the finding is for an unpatched CVE vulnerability.
Step 1: Create an IAM role for the Lambda function to send EC2 Systems Manager commands
A Lambda function needs specific permissions to interact with your AWS resources. You provide these permissions in the form of an IAM role, and the role has a policy attached that permits the Lambda function to receive SNS notifications and to send commands to the Amazon Inspector agent via EC2 Systems Manager.
Choose Roles in the navigation pane, and then choose Create new role.
Type a name for the role. You should (but are not required to) use a descriptive name such as Amazon Inspector-agent-autodeploy-lambda. Regardless of the name you choose, remember the name because you will need it in the next section.
Choose the AWS Lambda role type.
Attach the policies AWSLambdaBasicExecutionRole and AmazonSSMFullAccess.
Choose Create the role.
Step 2: Create the Lambda function that will update the host by sending the appropriate commands through EC2 Systems Manager
Now, create the Lambda function. You can download the source code for this function from the .zip file link in the following procedure. Some things to note about the function are:
The function listens for notifications on the configured SNS topic, but only acts on notifications that are from Amazon Inspector that report a finding and are reporting a CVE vulnerability.
The function checks to ensure that the EC2 SSM agent is installed, running, and healthy on the EC2 instance for which the finding was reported.
The function checks the operating system of the EC2 instance and determines if it is a supported Linux distribution (Ubuntu or Amazon Linux).
The function sends the distribution-appropriate package update command (apt-get update or yum update) to the EC2 instance via EC2 Systems Manager.
The function does not reboot the agent. You either have to add that functionality yourself or reboot the agent manually.
Unzip the .zip file, and copy the entire contents of lambda-auto-remediate.py to your clipboard.
Choose Edit code inline under Code entry type in the Lambda function, and replace all the existing text with the text that you just copied from lambda-auto-remediate.py.
Select Choose an existing role from the Role drop-down list, and then in the Existing role box, choose the IAM role that you created in Step 1 of this section.
Choose Next and then Create function to complete the creation of the function.
You now have a working system that monitors Amazon Inspector for CVE findings and will patch affected Ubuntu or Amazon Linux instances automatically. You can view or modify the source code for the function in the Lambda console. Additionally, Lambda and EC2 Systems Manager will generate logs whenever the function causes an agent to patch itself.
Note: If you have multiple CVE findings for an instance, the remediation commands might be executed more than once, but the package managers for Linux handle this efficiently. You still have to reboot the instances yourself, but EC2 Systems Manager includes a feature to do that as well.
If you have comments about this blog post, submit them in the “Comments” section below. If you have questions about implementing the solution in this post, start a new thread on the Amazon Inspector forum.
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.
Step 1: Enable EC2 Systems Manager and install the EC2 SSM agent
Setting up EC2 Systems Manager is relatively straightforward, but you must set up EC2 Systems Manager at the time you launch the instance. This is because the SSM agent will use an instance role to communicate with the EC2 Systems Manager securely. When launched with the appropriately configured IAM role, the EC2 instance is provided with a set of credentials that allows the SSM agent to perform actions on behalf of the account owner. The policy on the IAM role determines the permissions associated with these credentials.
The easiest way I have found to do this is to create the role, and then each time you launch an instance, associate the role with the instance and provide the SSM agent installation script in the instance’s user data in the launch wizard or API. Here’s how:
Create an instance role so that the on-instance SSM agent can communicate with EC2 Systems Manager. If you already need an instance role for some other purpose, use the IAM console to attach the AmazonEC2RoleforSSM managed policy to your existing role.
When launching the instance with the EC2 launch wizard, associate the role you just created with the new instance.
When launching the instance with the EC2 launch wizard, provide the appropriate script as user data for your operating system and architecture to install the SSM agent as the instance is launched. To see this process and scripts in full, see Installing the SSM Agent.
Note: You must change the scripts slightly when copying them from the instructions to the EC2 user data: the word region in the curl command must be replaced with the AWS region code (for example, us-east-1).
When your instance starts, the SSM agent is installed. Having the SSM agent on the instance is the key component to the automated installation of the Amazon Inspector agent on the instance.
Step 2: Automatically install the Amazon Inspector agent when new EC2 instances are launched
Let’s assume that you will install the SSM agent when you first launch your instances. With that assumption in mind, you have two methods for installing the Amazon Inspector agent.
Method 1: Install the Amazon Inspector agent with user data
Just as we did above with the SSM agent, we can use the user data feature of EC2 to execute the Amazon Inspector agent installation script during instance launch. This is useful if you have decided not to install the SSM agent, but it is more work than necessary if you are in the habit of deploying the SSM agent at the launch of an instance.
To install the Amazon Inspector agent with user data on Linux systems, simply add the following commands to the User data box in the instance launch wizard (as shown in the following screenshot). This script works without modification on any Linux distribution that Amazon Inspector supports.
curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
chmod +x /tmp/install
Note: If you are adding these commands to existing user data, be sure that only the first line of user data is #!/bin/bash. You should not have multiple copies of this line.
Method 2: Install the Amazon Inspector agent whenever a new EC2 instance starts
In environments that launch new instances continually, installing the Amazon Inspector agent automatically when an instance starts prevents some additional work. As we discussed in the previous method, you need to modify your instance launch process to include the EC2 SSM agent. This means you need to configure your instances with an EC2 Systems Manager role, as well as run the EC2 SSM agent.
First, create an IAM role that gives your Lambda function the permissions it needs to deploy the Amazon Inspector agent. Then, create the Lambda job that uses the SSM RunShellScript to install the Amazon Inspector agent. Finally, set up Amazon CloudWatch Events to run the Lambda job whenever a new instance enters the Running state.
Here are the details of the three-step process:
Step 1 – Create an IAM role for the Lambda function to use to send commands to EC2 Systems Manager:
Choose Create rule. From the Select event source drop-down list, choose Amazon EC2.
Choose Specific state(s) and Running. This tells CloudWatch to generate an event when an instance enters the Running state.
Under Targets, choose Add target and then Lambda function.
Choose the function that you created in Step 2.
Click Configure details. Type a name and description for the event, and choose Create rule.
You have completed the setup! Now, whenever an EC2 instance enters the Running state (either on initial creation or on reboot), CloudWatch Events triggers an event that invokes the Lambda function that you created. The Lambda function then uses EC2 System Manager to install the Amazon Inspector agent on the instance.
In a subsequent AWS Security Blog post, I will show you how to take your security assessment automation a step further by automatically performing remediations for Amazon Inspector findings by using EC2 System Manager and Lambda.
If you have comments about this blog post, submit them in the “Comments” section below. If you have implementation questions, start a new thread on the Amazon Inspector forum.
Last week we launched our 15th AWS Region and today we are launching our 16th. We have expanded the AWS footprint into the United Kingdom with a new Region in London, our third in Europe. AWS customers can use the new London Region to better serve end-users in the United Kingdom and can also use it to store data in the UK.
From Our Customers Many AWS customers are getting ready to use this new Region. Here’s a very small sample:
Trainline is Europe’s number one independent rail ticket retailer. Every day more than 100,000 people travel using tickets bought from Trainline. Here’s what Mark Holt (CTO of Trainline) shared with us:
We recently completed the migration of 100 percent of our eCommerce infrastructure to AWS and have seen awesome results: improved security, 60 percent less downtime, significant cost savings and incredible improvements in agility. From extensive testing, we know that 0.3s of latency is worth more than 8 million pounds and so, while AWS connectivity is already blazingly fast, we expect that serving our UK customers from UK datacenters should lead to significant top-line benefits.
Kainos Evolve Electronic Medical Records (EMR) automates the creation, capture and handling of medical case notes and operational documents and records, allowing healthcare providers to deliver better patient safety and quality of care for several leading NHS Foundation Trusts and market leading healthcare technology companies.
Travis Perkins, the largest supplier of building materials in the UK, is implementing the biggest systems and business change in its history including the migration of its datacenters to AWS.
Just Eat is the world’s leading marketplace for online food delivery. Using AWS, JustEat has been able to experiment faster and reduce the time to roll out new feature updates.
OakNorth, a new bank focused on lending between £1m-£20m to entrepreneurs and growth businesses, became the UK’s first cloud-based bank in May after several months of working with AWS to drive the development forward with the regulator.
Partners I’m happy to report that we are already working with a wide variety of consulting, technology, managed service, and Direct Connect partners in the United Kingdom. Here’s a partial list:
AWS Premier Consulting Partners – Accenture, Claranet, Cloudreach, CSC, Datapipe, KCOM, Rackspace, and Slalom.
AWS Consulting Partners – Attenda, Contino, Deloitte, KPMG, LayerV, Lemongrass, Perfect Image, and Version 1.
AWS Managed Service Partners – Claranet, Cloudreach, KCOM, and Rackspace.
AWS Direct Connect Partners – AT&T, BT, Hutchison Global Communications, Level 3, Redcentric, and Vodafone.
Here are a few examples of what our partners are working on:
KCOM is a professional services provider offering consultancy, architecture, project delivery and managed service capabilities to large UK-based enterprise businesses. The scalability and flexibility of AWS gives them a significant competitive advantage with their enterprise and public sector customers. The new Region will allow KCOM to build innovative solutions for their public sector clients while meeting local regulatory requirements.
Splunk is a member of the AWS Partner Network and a market leader in analyzing machine data to deliver operational intelligence for security, IT, and the business. They use cloud computing and big data analytics to help their customers to embrace digital transformation and continuous innovation. The new Region will provide even more companies with real-time visibility into the operation of their systems and infrastructure.
Redcentric is a NHS Digital-approved N3 Commercial Aggregator. Their work allows health and care providers such as NHS acute, emergency and mental trusts, clinical commissioning groups (CCGs), and the ISV community to connect securely to AWS. The London Region will allow health and care providers to deliver new digital services and to improve outcomes for citizens and patients.
Compliance & Connectivity Every AWS Region is designed and built to meet rigorous compliance standards including ISO 27001, ISO 9001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC3, PCI DSS Level 1, and many more. Our Cloud Compliance page includes information about these standards, along with those that are specific to the UK, including Cyber Essentials Plus.
The UK Government recognizes that local datacenters from hyper scale public cloud providers can deliver secure solutions for OFFICIAL workloads. In order to meet the special security needs of public sector organizations in the UK with respect to OFFICIAL workloads, we have worked with our Direct Connect Partners to make sure that obligations for connectivity to the Public Services Network (PSN) and N3 can be met.
Use it Today The London Region is open for business now and you can start using it today! If you need additional information about this Region, please feel free to contact our UK team at [email protected].
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.