Security Overview
Start course
1h 16m

This course is an introduction to AWS security. During this course, we will get started on the most important topics by covering the AWS Shared Responsibility model, the AWS Acceptable Use policy, and penetration testing rules. We will then explore each of the services in the security and identity category. Besides the most obvious of those, Identity and Access Management (IAM), we will also learn about AWS Directory Service, the brand new Inspector service (which is still in preview mode), the recently announced Web Application Firewall (WAF) and Microsoft AD, an Enterprise-level domain hosted in the cloud. Also, we will take a quick look at the most basic security best practices that we need to be aware of when working with AWS.

There are no big pre-requisites for this course, you just need to have general IT knowledge and some basic understanding of AWS. If you don't yet feel confident enough on AWS to tackle this, you should take a look at the AWS Fundamentals Learning Path prior to getting started.

After taking this course you should be able to identify who is responsible for what in the AWS cloud and describe all the services in the security and identity category.

If you have thoughts or suggestions for this course, please contact Cloud Academy at


- [Instructor] Hello and welcome to this lecture on the Amazon Inspector Service. Following this lecture, you'll be able to recognize and explain what the Amazon Inspector Service is and how it can be used to help improve the security and compliance of applications you've deployed on AWS. Let's start by better understanding what the Amazon Inspector is and does. The Amazon Inspector is an automated security assessment service that can be set up to run within your AWS account. Once enabled, the Amazon Inspector Service performs security assessments on applications of an EC2 or elastic compute cloud. The benefits of Amazon Inspector is that it can help improve the security posture of applications you've deployed on AWS. The inspector service does this by identifying security vulnerabilities or deviations from security best practices in your applications. The inspector can do this by monitoring before applications are deployed and while they're running in your production environment. As the Amazon Inspector is agent-based, APR driven and debited as a service, it can be included in your Devoxx work flow. This makes it easy to add an automated security assessment into your deployment process. AWS has made a large amount of their in-house security knowledge available for us in the form of the Inspector Service. Inspector is comprised of a knowledge base that maps hundreds of rules to vulnerability definitions and common best practices. These libraries are continually updated making it easier for you to meet and maintain security compliance and best practices. AWS has created a lot of automated tests to run against care resources. The inspector looks for security and compliance problems using these dynamic libraries. With respect to security, it will look for vulnerabilities. With respect to compliance, it will help us to adhere to security best practices. Before we see how this actually works, we need to define a few key concepts. The first concept is the agent. The Inspector agent needs to be installed on the EC2 instances that run your application. The agent is tasked with monitoring your instance and sending the data to the inspector service. Currently, the agent's available for EC2 instances running many versions of Amazon Linux, Ubuntu, Red Hat Enterprise Linux, CentOS and Windows. The application from the inspector's perspective is a collection of resources named an assessment target. An assessment target represents a collection of AWS resources that work together as a unit to help you accomplish your business goals. Amazon Inspector evaluates the security state of the resources that constitute the assessment target. You can create an assessment target by using Amazon EC2 tags and you can define these tagged resources as an assessment target for an assessment run to find by the assessment template. The inspector's assessments are based on a set of rules. You can specify a duration for each assessment. Even though there is an option to stop the assessments, setting the duration as an upper limit is handy in case you neglect to do so. The assessment will not continue after the defined duration. So you can start an assessment and leave it running without fear it will never end. Inspector assessments are integrated with AWS Simple Notification Service, so notifications can be sent out based on assessment results. Each assessment will produce some findings. Basically, findings are the result of an assessment run that reveal potential security issues. Findings include detailed descriptions of the problem along with recommended solutions, so you don't have to be an expert in order to take action. Some findings reveal good news too. For example, in the upcoming demonstration we'll see informational messages to advise us that no security issues were found. Each finding will be displayed relative to a rule. However, we don't have to select and view them rule by rule. AWS has grouped them together in order to improve the user experience. These groups are called rule packages. Rule packages include common vulnerabilities and exposures, CVE. CIS operating system configuration benchmarks and security best practices. Each rule has a severity level associated with it. Severity is intended to help you prioritize your responses to findings. The severity levels are high, medium, low or informational. Telemetry is the metadata about the inspector application data metrics that's been connected by the agent. This is the information the agent sends to the inspector service. Amazon Inspector is priced per agent assessment per month. Amazon does offer a free trial for the inspector service and that is certainly worth looking into. So, now that we've defined all the key concepts, let's take a look to see how it all works together. As mentioned earlier, each EC2 instance that runs your application needs to have the inspector agent installed on it. Tagging EC2 instances that you want to be part of your security assessment is a prerequisite. Inspector requires you to use Amazon EC2 instance tags in order to run an assessment. We'll use tags to aggregate our instances into applications, every instance in our application will be sending telemetry to the inspector service. The inspector service will aggregate the collected data into an assessment. When an assessment finishes, the service will check each of the defined rules. Any rule anomalies good or bad, it will detail in its findings. We can define more than one rule package to be assessed at the same time. All the findings will then be published. There is an AWS Lambda Blueprint available for you to create recurring scheduled events. Once you've created an assessment template for the security assessment you want to run, go to AWS Lambda from the AWS management console. In AWS Lambda, click on create a Lambda function, and select the inspector schedule run blueprint. Let's go through the steps required when working with inspector. First, there is some setup involved. Mostly, that entails setting up an IAM role, tagging all EC2 instances that we've powered to an assessment run, and installing the agent software on those same instances. Preparing for the assessment run involves tapping into the right rule package, such as the publicly available common vulnerabilities and exposures, CVE. The CVE is also part of the key data you must provide your assessment template, along with the test duration. At this point, you're ready to run the assessment, look over the findings and apply recommended fixes, if needed. Let's see what this looks like in the AWS inspector console. First, we'll click on get started. Now, we have to follow these steps in order to use the service. First of all, we need to create an IAM role. We can do that by simply clicking the create role button. Now, just click on allow in this page and we're set. Now we need to tag our instances. In the interest of time, I already launched some instances and tagged them, so I'll skip that here. After that, we need to install the Inspector Agent on the instances. Again, in the interest of time, I've already done that too. If you want to know how to do it, just click the install inspector agent link and follow the steps of the documentation. The setup is very easy. Just a couple of commands and we're set. Back to the wizard, let's now go to the next step. Here we have to define an application name and provide the key value pair for all tags that we'll use to filter our resources. Then click next. Here we're going to create our first assessment. We need to provide a name, select the rule packages we want to use and the duration of this assessment. I'll provide a name, select a couple of rule packages to test and click next. Now it's time to review everything and create and run the assessment. Now that we have our assessment running, we can check its status beneath the assessments page reached from the left window pane. So far, it's collecting data. If we click here and then on show status, we see a general overview of what's going on. I could wait for the assessment to finish, however, I'll click here to stop it and then take a look at the findings. The run has produced several findings. Let's first take a look at this informational finding. We've selected two rule packages. As we can see, for this rule package AWS inspector hasn't found any issues, although there's a finding. It's not a threat, it's just a way to inform me that everything's okay. This is when a finding can mean something positive. AWS has chosen to return informational findings, letting you know that it was checked and everything is alright rather than return nothing. The other findings are related to problems. Here we can see the description of the problem and the recommendation on how to fix it. In this case, the solution is very simple. We just have to update this package. In fact, all the other findings are related to this same issue. Often, fixing one finding will resolve other findings as well. The good news is, is that we're now aware of it. In our example, if we log into the instance and update the appropriate package, then run another assessment with the same rules package, we should not see these findings. That concludes our introduction to the Amazon Inspector Service. Let's summarize what we know. Inspector service is an automated security assessment service that can be set up to run within your AWS account. Inspector can assess security vulnerabilities and compliance issues in applications you've installed on EC2 instances, which collectively are called an assessment target. Inspector requires you to install an agent onto any EC2 instances you want to have included as a target in your monitoring. Instances need to be tagged to be included in an assessment. Assessments are comprised of rules. Assessments create findings. Each finding will be displayed relative to a rule. Each rule has a severity level associated with it. Groups of rules are called rule packages. Rule packages include common vulnerabilities and exposures, CVE. CIS operating system configuration benchmarks and security best practices. Rules packages are comprised of the latest security best practices, threat assessments and known exploits, which are compiled from many sources including AWS security libraries. The inspector service combined with these libraries provides a significant benefit to us as users, as it helps us keep our environment secure and compliant. That brings our Amazon Inspector lecture to a close. Thank you for your attention. Please address any comments or feedback to us at



About the Author
Learning Paths

Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built  70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+  years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.