This document discusses Amazon Inspector findings. It begins by introducing Eric Fitzgerald from Amazon and providing context on what Amazon Inspector is. It then discusses findings in more detail - specifically that findings report potential security issues, provide metadata, and can be used to drive automation. It demonstrates how to examine findings through the console and CLI. It also provides examples of how findings can be automatically exported using SNS and Lambda and how Lambda can be used to automatically remediate findings by triggering actions with other AWS services like SSM.
2. Introduction
Who’s talking?
• Eric Fitzgerald
• Principal Engineer on Inspector team
What is Inspector?
• A security-as-a-service offering in AWS
• Inspector assesses your EC2 instances for configuration or
operational vulnerabilities
• This presentation assumes that you have basic familiarity with
Inspector:
https://www.youtube.com/watch?v=BksbSqA3j9U
3. What is Inspector for?
• Helping our customers with their part of the shared
security model
• Vulnerability analysis without having to deploy & manage
scan infrastructure
• Designed to work in DevOps environments
• Highly composable – integrate Inspector however it makes
sense to you
• Works fine standalone as well
• Agent based
4. Inspector Concepts
Target
• What to assess
• Tags that match against EC2
instances
Rules Package
• Set of rules (security checks) grouped
by security goal
• Security best practices, CIS, CVE,
behavior monitoring
Template
• How to assess
• Pick a target, pick one or more rules
packages, pick a duration
Run
• An instance of a template – i.e. a
“scan”
• You can compare the results from
run to run
Finding
• A potential security issue discovered
by Inspector <-- This is what we’re
going to talk about today
In weekly scan starting 2016-09-08, Instance 1 was
vulnerable to CVE-2016-5678
5. What are Findings?
• Findings are reports of potential security issues with the objects
(assets) that you’re assessing with Inspector
• Assessment metadata: createdAt, service, serviceAttributes
• Security metadata: severity, confidence, IoC
• Describes asset: assetType, assetAttributes
• Describes issue: title, description, recommendation
• Can store bits of user-provided state- tag-like name/value pairs ”user
attributes”
• But findings are more than that – they are a language for
automation to talk about the security state of the things being
protected
• Findings are a core element of AWS security services
6. {
"failedItems": {},
"findings": [
{
"assetType": "ec2-instance",
"confidence": 10,
"numericSeverity": 9.0,
"description": "Unspecified vulnerability in Oracle Java SE 6u115, 7u101, and 8u92; Java SE Embedded 8u91; and JRockit R28.3.10 allows remote
attackers to affect availability via vectors related to JAXP, a different vulnerability than CVE-2016-3500.",
"service": "Inspector",
"title": "Instance i-0044413a449b423e0 is vulnerable to CVE-2016-3508",
"indicatorOfCompromise": false,
"assetAttributes": {
"ipv4Addresses": [],
"agentId": "i-0044413a449b423e0"
},
"userAttributes": [],
"recommendation": "Use your Operating System's update feature to update package java-1.7.0-openjdk, java-1.7.0-openjdk-1:1.7.0.101-
2.6.6.1.67.amzn1. For more information see [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3508](https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-3508)",
"updatedAt": 1474922252.15,
"attributes": [
{
"value": "java-1.7.0-openjdk, java-1.7.0-openjdk-1:1.7.0.101-2.6.6.1.67.amzn1",
"key": "package_name"
},
{
"value": "CVE-2016-3508",
"key": "CVE_ID"
},
{
"value": "i-0044413a449b423e0",
"key": "INSTANCE_ID"
}
],
"serviceAttributes": {
"assessmentRunArn": "arn:aws:inspector:us-west-2:904328719097:target/0-bRdCL0nH/template/0-E38vEeRS/run/0-v71aypKJ",
"rulesPackageArn": "arn:aws:inspector:us-west-2:758058086616:rulespackage/0-9hgA516p"
},
"createdAt": 1474922252.15,
"severity": "High"
}
]
}
7. Aren’t Findings Just Reports
• No
• Findings tell you only that Inspector found a potential security
issue.
• Findings are intended to be a low-effort low-overhead way to
drive automation – think “event-driven security”.
• Reports tell you what was assessed, what was tested for,
pass/fail results for each test, etc.- much more comprehensive
• We don’t have reports now but we have heard this request
from customers. Stay tuned to the AWS blog…
9. Automated Export of Findings
• Remember composability? Inspector can send notifications to an
SNS topic for various operations, including generation of a finding
• The notification only contains the finding ARN, so if you want to
pass the finding along as plain text, you have to do just a little bit of
work – Lambda is good for this
• If you want to forward findings as email (including to Jira
ServiceDesk), then use Lambda to format the finding as an email
and send it via SNS. https://aws.amazon.com/blogs/aws/scale-your-
security-vulnerability-testing-with-amazon-inspector/
• If you have a third party tool like Slack that needs API integration,
then use Lambda to format the finding and make the API call-
there’s a blueprint for that.
11. Automatic Remediation of Findings
• We’ve heard feedback from customers about including
remediation in Inspector. In the meantime…
• Remember composability? Event-driven security?
• You can use SNS to notify a Lambda function of new
findings. Lambda can look at the kind of finding and
take an action.
• In this case, Lambda looks for CVE findings, and then
uses EC2 SSM to tell the system to update itself.
• We’re about to publish a blog on this, but here’s a sneak
peek!
13. Takeaways
• Findings are a core element of AWS security services
that identify potential security issues
• They’re easy to build on… remember “Event-driven
security”
• SSM is a powerful way to take actions in response to
findings
• SNS & Lambda are the glue that connects findings to
actions
Who
Work on internal-facing tools to keep AWS secure, and external-facing security services
Shared security model:
AWS is responsible for security OF the cloud
Customer is responsible for security of their stuff IN the cloud
Inspector aims to reduce customer burden
- pay as you go, only for what you use, no infrastructure to deploy and maintain
DevOps, aka “Continuous Integration/Continuous Deployment” (CI/CD)
AWS uses this kind of process. Inspector was originally conceived for internal use
and fits this model; kick of an assessment during your test phase and make test
passage contingent on no findings that you care about
It agent-based
We know you hate this but the alternative is give us a big pile of credentials.
Target: in the future, more matching options- IP address, hostname, boolean operators, etc., and more object types
Recommendation – ALL FINDINGS ARE ACTIONABLE
Future – integrate once