Since Oct 7, 2015, we have been using Amazon Inspector in many different situations. We can treat it as our simple pentest tool, though this is an oversimplification. Today we will try to take a look at this specific tool and determine if it is worth considering as a must-have thing in our configuration.
I know that all of us know pretty well what Amazon Inspector is, but let’s recall the main features highlighted by Amazon on the day of publication:
- Configuration scanning and activity monitoring engine – Amazon Inspector provides an agent that analyzes system and resource configuration. It also monitors activity to determine what an assessment target looks like, how it behaves, and its dependent components. The combination of this telemetry provides a complete picture of the target and its potential security or compliance issues.
- Built-in content library – Amazon Inspector includes a built-in library of rules and reports. These include checks against best practices, common compliance standards, and vulnerabilities. The checks include detailed recommended steps for resolving potential security issues.
- Automation through an API – Amazon Inspector can be fully automated through an API. This allows you to incorporate security testing into the development and design process, including selecting, executing, and reporting the results of those tests.
To understand it in a more practical way, we can interpret it as another tool to help us manage our infrastructure in a much more secure way. The main reason why Amazon decided to release such a tool was likely a necessity to increase cloud solution safety. Right now, we are in this position that deploying some virtual machines is as simple as posting new information on your Facebook wall. From our perspective, it is a tremendous step toward future solutions and accessibility for “regular” users, but on the other hand, there is a significant security breach. As human beings, we try to ignore anything that can cause fear and avoid things that might make us uncomfortable. If we want to deploy some simple solutions, we don’t even think about the potential “dark side.” For argument’s sake, let’s say it is covered by the advantages of such solutions as cloud services. As a result, we are deploying our first service or website without implementing any additional security solutions, best practices in design, or anything additional despite our core solution. Clearly this is unwise. Thankfully, Amazon has provided us with the Amazon Inspector tool. To continue our main topic of simplicity, we can consider Inspector in the same class. I’ve just mentioned that deploying virtual machines is simple, and in further sections you will see that taking care of security with Amazon Inspector is also simple. However, we must consider it only as an absolute basic option in security cloud. It is good for beginning, and better than nothing. It will help you avoid elementary mistakes and implement best practices for the safety of your virtual machines, even if you are not overly familiar with them.. We have to understand the cloud is designed to simplify things, not to complicate them further. With this awareness, we will be much more motivated to create new things.
Enough theory: let’s disassemble it to smaller, digesitble parts… Let’s begin with the basic approach. What will the process look like? At the beginning, we have to make a crucial decision what range will be taken to analyze.
AWS prepared two options for us(odniesienie do A simpler way to assess the network exposure of EC2 instances: AWS releases new network reachability assessments in Amazon Inspector https://aws.amazon.com/blogs/security/amazon-inspector-assess-network-exposure-ec2-instances-aws-network-reachability-assessments/):
Network Assessments (Inspector Agent is not required)
- Assessments performed: Network configuration analysis to checks for ports reachable from outside the VPC. Learn more
- Optional Agent: If the Inspector Agent is installed on your EC2 instances, the assessment also finds processes reachable on port. […]
Host Assessments (Inspector Agent is required)
- Assessments performed: Vulnerable software (CVE), host hardening (CIS benchmarks), and security best practices. Learn more
- Agent Deployment: Inspector assessments require an agent to be installed on your EC2 instances. We will automatically install the agent for instances that allow System Manager Run Command. […]
The first option will test our VPC as an external actor who will try to reach our ports in the same way as an attacker of any harmless external user. The big question: did he manage to pass through or not? This is the answer which comes with the first option. We can fill this option with the local agent installed on EC2 machines. Thanks to that, our result will be more valuable because we will also receive data about processes running on particular ports. Such information is valuable for anyone who wants to be safer.
On the other hand, we have secondary options which are slightly more interesting – Host Assessments where we have an EC2 instance our virtual machine that will be hosting our service. We deployed it as a regular EC2 instance with installed any of HTTP services, such as apache for instance, so we have some basics where we can dig deeper. Before we start, let’s assume that our workflow will look like this:
We should start with Assessment Target, which is simply a collection of your AWS resources. It iseasy to determine your targets; You can do it by attaching particular tags to Your EC2 instances. Tags are words for identifying your instances. Amazon Inspector will use them to identify the instances that belong to your target.
The next step is deploying agents, as we know nothing is done by magic, so we have to provide a little help for our Inspector. Unfortunately, this part is a bit technical, so I recommend doing it with a little help of user data, System Manager, or automation. There is an even option to deploy an AMI with a preinstalled Amazon Inspector Agent – it’s your call. The result should be the same: agent must be present on the machine.
We have now completed almost all of the most critical parts. At this point, we have to choose what is important for us and according to which regulations we should be compliant. AWS proposes the possibility to use predefined packages with some essential rules coming from various regulations, and we can freely choose between them. AWS divides the whole assessments into three categories:
- Vulnerable Software (CVE)
- Host Hardening (CIS benchmarks)
- Security best practices
Combined all together provide us possibility to include in our “scan”:
We have to be aware that all of the packages contain a lot of rules, so there is a significant probability that you won’t be familiar with all of them. But this won’t be an obstacle. After executing a scan, you will receive a complex report with description, severity and some other indicators. You will also receive a hint on how to solve the problems detected during scanning. And now you can go smoothly through to the final section, which is the results or findings..
Findings areour main aim in the whole procedure. Here we will receive a big report about the state of our infrastructure. It is represented basically as follows:
In this example we can easily find out that our EC2 instance is reachable from Internet on port 22 which is the default port for ssh communication. This would be like an invitation for attackers.You should rethink if the port range should be changed to make an attack a little bit harder, or at least to mislead an inexperienced attacker.
This is only an example, and as you see this is only one finding.You can imagine how many threats are present these days around our infrastructure if regular reports can point out more than 1000 findings that are not visible upon initial inspection.
That’s why this tool should be used in almost every situation. There are many commercial solutions on the market such as nessus, nmap and much more. However, the out-of-the-box usability and simplicity of the AWS Inspector are major advantages to be considered.
Finally, I must share the biggest disadvantage to this solution. It is true that AWS provides us with a massive database of potential threats, but at the same time it is the full package of what we have and it looks like it won’t change in near future. AWS Inspector has predefined rules and any additional custom rules cannot be defined. Of course, we can use config manager for some additional rules and additional detection, but that is not the point. Situations in security are very dynamic and it will be a nice gesture of AWS if they allow users to adjust the rules packages with some customization at some point in the future.
I wouldn’t recommend this to professionals as the only tool to cover all security areas, but the AWS Inspector is a powerful tool for regular users who want to take care of basics in their design. It is also important to recognize that this type of solution should be implemented in a recursive manner, running tests every week or month depending on individual user needs. Thanks to AWS, we have such an opportunity without editing any complicated policies or rules. It is ready to implement from the start, which is beneficial because the more time that passes means a bigger advantage a potential attacker may have.