security

Importing Custom Findings into AWS Security Hub

Often, organizations have a suite of security products to help maintain their on-premises networks, their cloud networks and to help enforce the best practices they put in place. The AWS Security Hub service was announced at re:Invent 2018 and gives security administrators a centralized view of all of these tools by aggregating their findings in a common format, either within the current account or using a master account.

Though Security Hub is in preview, you can access it in your console now and it comes with out-of-the-box support for AWS services such as GuardDuty, Macie and Inspector as well as from 3rd party providers like Rapid7, Qualys, Splunk, Twistlock and much more.

In addition to the officially supported providers, you can also construct your own providers which will import findings directly into the Security Hub findings dashboard.

Writing a Custom Finding Provider

Troy Hunt created the Have I Been Pwned service which allows you to receive notifications whenever your e-mail address has been detected in a data breach that has been publicly disclosed. In addition to the e-mails, an API is also freely available to query for all breaches a particular identity has been involved in. Here is the template that will regularly poll the API for a number of e-mail addresses and produce findings in the Security Hub findings dashboard: https://github.com/KablamoOSS/Security-Hub-Custom-Provider-Demo

The template creates a Lambda which is triggered periodically by CloudWatch Events. The Lambda then iterates through a list of e-mail addresses and queries the Have I Been Pwned API to determine if any breaches have been detected. If they have, they are included in a batch_import_findings call to import the findings. Findings that are included in subsequent calls which share a common ID, will be updated.

The findings must conform to the AWS Security Findings Format which has optional and mandatory fields, including fields which represent the severity of the finding and finding or resource-specific custom properties. Normally, findings are required to target a specific AWS or 3rd party product, however each account comes with a default product which you can use to import your custom findings with.

Findings shown in the dashboard can be expanded to see the full description and additional detail. Custom Actions can also be created and executed against findings, which triggers a CloudWatch Event so that any supported targets can be executed, such as Lambda or Step Functions.

Once you have findings in the system, you can construct your own Insights which are views give you an overview of findings that match your predefined filters and grouping. The above screenshot shows an overview of the breaches for all Have I Been Pwned findings available.

Gotchas

There are some issues I found when developing for the Security Hub, which are important to note if you plan on developing your own integrations. It should be noted that since the service is still in Preview as of writing this article, these issues may or may not be fixed by the time the service reaches General Availability.

Findings cannot be deleted, but are retained for 90 days

There is currently no functionality to permanently delete a finding, however they have a 90 day retention period after which time the finding will be purged. You can archive findings during this period but unfiltered searches will still return these findings.

Updateable attributes may not update

The AWS Security Findings Format states which attributes can be updated with subsequent import calls, however some of these fields such as “Title” do not seem to update despite successful return codes from the API.

Date formats are sensitive

Though the format specifies any ISO8601-formatted string can be used in its date fields, any value with timezone information is rejected if it is not formatted in Zulu time. Additionally, errors in failed findings are not returned in the response contrary to what the documentation states. You must execute the call with a debugging log level to actually see the error messages.

Fields have undocumented maximum lengths

Also undocumented is that some fields have a maximum length. The “Description” field for example has a maximum length of 1024 characters so you'll need to trim values which are longer than that.

tl;dr

Despite the issues, AWS Security Hub is great offering for organizations looking to build their own SIEM and/or consolidate their findings into a centrally managed account. If you would like to hear more about how your organization might benefit from this new service, get in touch with us to find out more.

Security at the Centre

security image for kablamo.jpeg

The following was adapted from a sit down chat recently with our team.  Security is a big challenge in enterprise. You have legacy security teams that have traditionally worked in a check post type model where we have a six month product plan, and these dates we're going to do penetration tests, and at this date we'll do the security architecture review. That kind of all just flies out the window when you start having safe digital teams that are deployed into production multiple times a day.

We've worked pretty closely with some enterprise security teams in helping change their work flow and disseminate ownership of security back into the teams that are actually deploying these services. So you no longer have this ivory tower on a security team saying, "This is bad." How you should be securing the Cloud is by asking how, not saying no.

You need to enable teams to have ownership of their own, or a significant part of their own security model. It is the only way it can really scale. You can take what was traditionally, say, a security orbit and write automation around that and have compliance checks that are doing what we like to call continuance compliance.  We're running these checks --you can be running them every five minutes if you like--and you have a dashboard of high risk items in your Cloud.

But that only goes so far. You need to start again, instilling teams to think about security when they're designing systems.