Resoures & Links used within this Lecture

IAM Course: https://cloudacademy.com/course/overview-of-aws-identity-and-access-management-iam/introduction-81/

AWS Agent Installation: 

Linux Install:

• wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
• curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
• sudo bash install

Windows Install:

• https://d1wk0tztpsntt1.cloudfront.net/windows/installer/latest/AWSAgentInstall.exe 

CVE Rules: https://s3-us-west-2.amazonaws.com/rules-engine/CVEList.txt

Amazon Inspectors CIS Certificates: https://www.cisecurity.org/partner/amazon-web-services/

CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/

Security Best Practices: http://docs.aws.amazon.com/inspector/latest/userguide/inspector_security-best-practices.html

Runtime Behavior Analysis: http://docs.aws.amazon.com/inspector/latest/userguide/inspector_runtime-behavior-analysis.html

------------------------------------------------------------------------------------------------------------------------------------------------------

Transcript

Hello, and welcome to this lecture covering the different components that make up the Amazon Inspector service. I should look at each component and how they link together to make the service function.

There are essentially nine different components and elements of the service. These are: the Amazon Inspector role, assessment targets, AWS agents, assessment templates, rule packages, assessment runs, telemetry, assessment reports, and findings.

Let me break down each of these to see which part they play within the service, starting with the Amazon Inspector role. When you first start using Amazon Inspector, you are required to create or select a role to allow Amazon Inspector to have read-only access to all of your EC2 instances. Without this role, the service would not have the relevant permissions to be able to gather the telemetry data of the instance during any assessment runs.

If you allow Amazon Inspector to create a role, then it will have a policy attached as detailed here. As you can see, this simply allows the role to have read-only access to all EC2 instances within your AWS account. For more information on IAM and IAM roles, please see our existing course here. Assessment Targets.

An Assessment Target is a grouping of AWS EC2 instances that you want to run an assessment against. This grouping of EC2 instances are managed and defined by the tags that are associated to your EC2 instance. Tagging is simply a way of adding metadata to your instances to help with management and organization, consisting of a key value pair.

For example, you might have a key of 'project,' with a value of 'new app. ' Or a key of 'department,' with a value of 'finance. ' The tags help you to create custom metadata of your infrastructure. When creating an assessment target, you are asked to select which keys from your tags that you would like to include within your Assessment Target. You can also refine your selection even further by providing the values for each of those keys, too. So you could have an Assessment Target configured as follows. This Assessment Target would then be associated to any instances which had either the project or department key with the corresponding values.

The EC2 instances are not required to contain both keys to be included within this Assessment Target. Only a match of one key is necessary. AWS Agents.

AWS Agents are essential to Amazon Inspector. These are software agents that must be installed on EC2 instances that you with to monitor and run the assessments on. Without this agent, Amazon Inspector would not be able to perform the analysis that it needs to. Once installed, the agent will be able to track and monitor data across the network file system, and any process activity of the instance. This data is then recorded as telemetry data, and is fed back to the Amazon Inspector service via the public endpoint of the service over a Transport Layer Securityprotected channel.

A regular heartbeat is sent from the agent to Inspector, which the Inspector service will respond to with instructions, such as to perform an assessment at a particular time. As the Agent is software-based, it is necessary from time to time to update the agent with the latest version. These new updates are managed and automatically installed by AWS, and so you don't need to worry about the latest Agent software version.

The auto update of these agents are scheduled outside of any assessments that are due to take place. As this is a key component of Amazon Inspector, I now want to provide a demonstration on how to install these agents for both Linux and Windows operating systems. I will start by installing the agent on a Linux instance, and then a Windows instance.

I shall add all of these commands and links that I use to this lecture's transcript, allowing you to copy and repeat if required.

Okay, so I'm within the AWS Management Console within the EC2 dashboard. And as you can see, I have two instances up and running. One of them is a Linux box, and another is a Windows box.

Now what I want to do is install the Amazon Inspector agents on each of these. So I'll start with the Linux box, and it's a very simple process. So to do this, what we need to do is download an agent installation script using either of these two commands, and then install the agent with this command, here.

So let's go ahead and download and install the installation script. So if I go across to my instance, which I'm already connected to here. If I run the command. As you can see it's a very quick install, and now it's downloaded. I actually need to install the agent. So if I just type in this command here, sudo bash install, that will go ahead and install the Amazon Inspector agent for us.

And that's the installation completed for a Linux box. So now if we swap over to our Windows box and install the agent in there. So for the Windows install, we need to go to this URL here to download the agent. So if I'm now to swap over to my Windows box, open up Internet Explorer and paste in that URL.

Click on okay. You may get a security warning about trusted sites, so just add that. . . And then try again. Click on okay. Save the download. Now the download is completed, we can then run the . exe file. And that will go ahead and install the agent. So if we agree to the license terms and conditions, and click on install, you can see the usual progress bar of the installation taking place.

That's now successfully completed. And the agent is now installed. So that's how you install the Amazon Inspector agents for both a Linux and Windows box.

An assessment template defines a specific configuration as to how an assessment is run on your EC2 instances. These configurable items within the template include the following.

Rules packages to be used during the assessment, and I'll explain more on this later in this lecture. The duration of the assessment run, which can be 15 minutes, one hour, which is the recommendation by AWS, eight hours, 12 hours, or 24 hours. Specific SNS topics that Amazon Inspector should be used for any notifications, and these notifications can be when an assessment run starts, when it finishes, when it changes state, or when findings are reported.

Do be aware that you'll need to allow access for Amazon Inspector to publish to the topic to enable these notifications within the topic policy. And any Amazon Inspector-specific attributes that can be assigned to findings generated by the assessment. So essentially, your findings can be tagged with keys and values of your choice. For example, with a key of 'Assign To' with a value of 'Windows Security Team. ' Once your assessment template is created, you are not able to modify it again to make changes. You can, however, tag your assessment templates to help with the organization and management of your assessment runs. Rules Packages.

When Amazon Inspector gathers telemetry during an assessment run, it will then compare this data against specific security rules to ascertain its compliance. And these rules are grouped together in what is known as a rules package. So a rules package contains a number of individual rules that are each checked against the telemetry data back from the EC2 instance.

Each rule will also have an associated severity which will be one of the following. High. Should there be a finding with a rule with a severity of high, then this should be looked at immediately and rectified. This is the highest severity level, and as a result would likely compromise the integrity, confidentiality, and availability of your data and instants if left.

Medium. This is the next level down from high, and so any findings with a medium rule should be attended to in a timely manner. This severity also poses a risk to confidentiality and integrity. Low. Any rules highlighted with a low severity need to be rectified, but the urgency is not as severe as medium or high.

If any findings are returned with a high or medium rule, then these should be resolved as a matter of priority over any with a low severity. Informational. These would describe a particular security configuration within your assessment target, which you could then use to make changes to your environment to improve its effectiveness, or simply make a note for future reference.

The rule packages themselves are split across four different categories, these being: Common Vulnerabilities and Exposures, Center for Internet SecurityBenchmarks, Security Best Practices, and Runtime Behavior Analysis. Let me explain each of these in a bit more detail to understand what each of these rule packages look for during an assessment run.

Common Vulnerabilities and Exposures. The CVE is a publicly-known reference list of security threats that are well-documented. The rules used within this package will check the Assessment Target for exposure to any known security holes that would compromise the integrity, confidentiality, and availability of your EC2 instance.

Should any findings from an assessment be found against a CVE, it's recommended you visit this site and search for specific vulnerability ID to gather additional detailed information to help you resolve and mitigate the issue. To check which CVEs the rules within the rules package are performing an assessment against, you can visit the following link.

As new CVEs are found, they are added to this list by AWS, and the corresponding rules added to the rules package, preventing the need for you to stay up-to-date with the latest known security issues. Center for Internet Security Benchmarks. These benchmarks are continuously refined and used as global standards for best practices for protecting data and IT resources.

AWS is a CIS Benchmarks member company, and Amazon Inspector's associated certifications can be found here. The rules within this rule package help to assess security for the following operating systems as per the certification link. If any findings are made against this rules package, then similarly to the CVE list, you can visit the following link to download the detailed description, explanation, and advice on how to mitigate the security issue found.

Security Best Practices. This rules package looks for weaknesses in common security best practices. However, this only applies to Assessment Targets that are running the Linux operating system. At this stage, it's not possible to run this rules package on any target that has the marks of Windows OS. The following security checks are covered within this rules package.

Disable root login over SSH. This checks to see if the SSH daemon is configured to allow login into your instances root. Support SSH version two only. This checks to see if the instance is configured to run SSH protocol version one. Disable password authentication over SSH. This rule checks to see if password authentication over SSH is configured.

Configure password maximum age. This simply checks to see if a maximum age for a password has been configured on the instance. Configure password minimum length. Similarly to the previous point, this checks to see if a minimum password length has been configured on the instance.

Configure password complexity. This checks to see if the instance is using a password complexity mechanism for passwords.

Enable ASLR. This simply checks to see if address space layout randomization is enabled.

Enable DEP. This rule checks to see if data execution prevention is enabled on the instance.

And finally, configuration permissions for systems directories. This rule checks to ensure that only the root user has right access to system directories. For detailed information on each of these rules, see the AWS documentation found here. 

During the creation of your assessments, you are able to select more than one rules package. And so if supported by your target assessments, you can run all four rules packages for deep security analysis of your resources. However, do be aware that not all the rules packages are available on all operating systems.

For example, and as I have already mentioned, the security best practice rules package is only available for the Linux OS. The table here shows a quick reference guide as to which rules packages are available for which operating systems. So do be aware of this when planning your security targets and templates.

Assessment Run. As assessment run can happen once you have configured your Amazon Inspector role, installed the agents and configured your Assessment Target and Assessment Templates. Once these components are in place, you are then able to run the configured assessment on your assessment targets. This process is known as the assessment run.

During this time, telemetry data will be sent back to Amazon Inspector and S3 to assess the data against the specified rules packages defined within the assessment template. Multiple assessment runs can be run at the same time, but only if the assessment targets do not have any duplicated EC2 instances within them.

During the assessment run, it is possible from within the management console to view the progress of the run in addition to stopping, starting, and deleting the run. Telemetry. I've mentioned telemetry a number of times already, and you are probably now aware of what this is. However, telemetry is a data that is collected from an instance, detailing its configuration, behavior and processes during an assessment run.

Once collected, the data is then sent back to Amazon Inspector in near-real-time over TLS where it is then stored and encrypted on S3 via an ephemeral KMS key. Amazon Inspector then accesses the S3 Bucket, decrypts the data in memory, and analyzes it against any rules packages used for that assessment to generate the findings.

After 30 days, this telemetry data is then deleted using a lifecycle policy attached to the dedicated Amazon Inspector S3 Bucket. Assessment Reports. On completion of an assessment run, it is possible to generate an assessment report which provides details on what was assessed, and the results of that assessment.

As this feature was only released at the end of April 2017, It's only possible to generate these reports for any assessment runs that were completed on or after the 25th of April, 2017. There are two different types of reports that you can generate: a findings report, and a full report. The findings report will only contain a subset of the full report.

This will include a summary of the assessment that took place, a list of the EC2 instances that were within the assessment targets, the rules packages that were used from within the assessment template, and finally a detailed report on any findings that occurred. The full report, and as expected, contains all of the information from the findings report, in addition to a list of rules that were passed successfully for all the instances within the assessment target.

Findings. Findings are generated from the results of an assessment run. A finding is a potential security issue or risk against one of your EC2 instances within the assessment target. For each finding, an explanation of the issue is given, along with guidance on how to remediate the problem. More on findings will be given in a later lecture within this course.

That now brings us to the end of this lecture. And so to quickly recap, we looked at the following components: the Amazon Inspector role and the permissions required, assessment targets and how they use tagging of EC2 instances, AWS Agents and how they are installed on both Linux and Windows instances, assessment templates including configuration and the different rules packages available, when an assessment run can be performed, an understanding of telemetry data, the different types of assessment reports that are available, and lastly, an overview of what findings are.

Coming up in the next lecture, I'm going to demonstrate how to configure Amazon Inspector, which will include a lot of the components that I have mentioned in this lecture.