AWS Security Hub

(1)

AWS Security Hub

Partner Integration Guide

(2)

AWS Security Hub: Partner Integration Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

Overview of third-party integration with AWS Security Hub

This guide is intended for AWS Partner Network (APN) Partners who would like to create an integration with AWS Security Hub.

As an APN Partner, you can integrate with Security Hub in one or more of the following ways.

• Send ﬁndings to Security Hub

• Consume ﬁndings from Security Hub

• Both send ﬁndings to and consume ﬁndings from Security Hub

• Use Security Hub as the center of a managed security service provider (MSSP) oﬀering

• Consult with AWS customers on how to deploy and use Security Hub

This onboarding guide primarily focuses on partners that send ﬁndings to Security Hub.

Topics

• Why integrate with AWS Security Hub? (p. 1)

• Preparing to send ﬁndings to AWS Security Hub (p. 1)

• Preparing to receive ﬁndings from AWS Security Hub (p. 2)

• Resources for learning about AWS Security Hub (p. 3)

Why integrate with AWS Security Hub?

AWS Security Hub provides a comprehensive view of high-priority security alerts and security status across Security Hub accounts. Security Hub allows partners like you to send security ﬁndings to Security Hub to provide your customers with insight into the security ﬁndings that you generate.

An integration with Security Hub can add value in the following ways.

• Satisﬁes your customers who have requested a Security Hub integration

• Provides your customers with a single view of their AWS security-related ﬁndings

• Allows new customers to discover your solution when they look for partners who provide ﬁndings related to speciﬁc types of security events

Before you build an integration with Security Hub, examine your reasons for the integration. An integration is more likely to be successful if your customers want a Security Hub integration with your product. You can build an integration purely for marketing reasons or to acquire new customers.

However, if you build the integration without any current customer input and do not consider your customers' needs, the integration might not yield the expected results.

Preparing to send ﬁndings to AWS Security Hub

As an APN Partner, you cannot send information to Security Hub for your customers until the Security Hub team enables you as a ﬁnding provider. To be enabled as a ﬁnding provider, you must complete

(6)

Preparing to receive ﬁndings

the following onboarding steps. Doing so ensures a positive experience Security Hub for you and your customers.

As you complete the onboarding steps, be sure to follow the guidelines in the section called “Tenets for creating and updating ﬁndings” (p. 29), the section called “Guidelines for ASFF mapping” (p. 30), and the section called “Guidelines for using the BatchImportFindings API” (p. 35).

1. Map your security ﬁndings to the AWS Security Finding Format (ASFF).

2. Build your integration architecture to push findings to the correct Regional Security Hub endpoint. To do this, you define whether you will send findings from your own AWS account or from within your customer's accounts.

3. Have your customers subscribe the product to their account. To do this, they can use the console or the EnableImportFindingsForProduct API operation. See Managing product integrations in the AWS Security Hub User Guide.

You can also subscribe the product for them. To do this, you use a cross-account role to access the EnableImportFindingsForProduct API operation on behalf of the customer.

This step establishes the resource policies that are needed to accept ﬁndings from that product for that account.

The following blog posts discuss some of the existing partner integrations with Security Hub.

• Announcing Cloud Custodian Integration with AWS Security Hub

• Use AWS Fargate and Prowler to send security conﬁguration ﬁndings about AWS services to Security Hub

• How to import AWS Conﬁg rules evaluations as ﬁndings in Security Hub

Preparing to receive ﬁndings from AWS Security Hub

To receive ﬁndings from AWS Security Hub, use one of the following options:

• Have your customers automatically send all findings to CloudWatch Events. A customer can create specific CloudWatch event rules to send findings to specific targets, such as a SIEM or an S3 bucket.

• Have your customers select specific findings or groups of findings from within the Security Hub console and then take action on them.

For example, your customers can send findings to an SIEM, a ticketing system, a chat platform, or a remediation workflow. This would be part of an alert triage workflow that a customer performs within Security Hub.

These are called custom actions. When a user takes a custom action, a CloudWatch event is created for those specific findings. As a partner, you can leverage this capability and build CloudWatch event rules or targets for a customer to use as part of a custom action. Note that this capability does not automatically send all findings of a particular type or class to CloudWatch Events. This feature is for a user to take action on specific findings.

The following blog posts outline solutions that use the integration with Security Hub and CloudWatch Events for custom actions.

• How to Integrate AWS Security Hub Custom Actions with PagerDuty

• How to Enable Custom Actions in AWS Security Hub

(7)

Security Hub information resources

• How to import AWS Conﬁg rules evaluations as ﬁndings in Security Hub

Resources for learning about AWS Security Hub

The following materials can help you to better understand the AWS Security Hub solution and how AWS customers can use the service.

• Introduction to AWS Security Hub video

• Security Hub User Guide

• Security Hub API Reference

• Onboarding webinar

We also encourage you to enable Security Hub in one of your AWS accounts and get some hands-on experience with the service.

(8)

Partner prerequisites

Before you can begin an integration with AWS Security Hub, you must meet one of the following criteria:

• You are an AWS Select Tier Partner or above.

• You have joined the AWS ISV Partner Path, and the product that you use for Security Hub integration has completed an AWS Foundational Technical Review (FTR). The product is then granted a "Reviewed by AWS" badge.

You also must have a mutual nondisclosure agreement in place with AWS.

(9)

Partner hosted: ﬁndings sent from partner account

Integration use cases and required permissions

AWS Security Hub allows AWS customers to receive findings from APN Partners. The partner's products might run either inside or outside of the customer's AWS account. The permission configuration in the customer's account differs based on the model that the partner product uses.

In Security Hub, the customer always controls which partners can send ﬁndings to the customer's account. Customers can revoke permissions from a partner at any time.

To enable a partner to send security ﬁndings to their account, the customer ﬁrst subscribes to the partner product in Security Hub. The subscription step is necessary for all of the use cases that are outlined below. For details on how customers manage product integrations, see Managing product integrations in the AWS Security Hub User Guide.

After a customer subscribes to a partner product, Security Hub automatically creates a managed resource policy. The policy grants the partner product permission to use the BatchImportFindings API operation to send ﬁndings to Security Hub for the customer’s account.

Here are the common cases for partner products that integrate with Security Hub. The information includes the additional permissions required for each use case.

Partner hosted: ﬁndings sent from partner account

This use case covers partners who host a product in their own AWS account. To send security ﬁndings for an AWS customer, the partner calls the BatchImportFindings API operation from the partner product account.

For this use case, the customer account only needs the permissions that are established when the customer subscribes to the partner product.

In the partner account, the IAM principal that calls the BatchImportFindings API operation must have an IAM policy that allows the principal to call BatchImportFindings.

Enabling a partner product to send ﬁndings to the customer in Security Hub is a two-step process:

1. The customer creates a subscription to a partner product in Security Hub.

2. Security Hub generates the correct managed resource policy with the customer's conﬁrmation.

To send security ﬁndings related to the customer’s account, the partner product uses their own credentials to call the BatchImportFindings API operation.

Here is an example of an IAM policy that grants the principal in the partner account the necessary Security Hub permissions.

{ "Version": "2012-10-17", "Statement": [

{

"Sid": "VisualEditor0",

(10)

Partner hosted: ﬁndings sent from the customer account

"Effect": "Allow",

"Action": "securityhub:BatchImportFindings",

"Resource": "arn:aws:securityhub:us-west-1:*:product-subscription/company-name/

product-name"

} ] }

Partner hosted: ﬁndings sent from the customer account

This use case covers partners who host a product in their own AWS account, but use a cross-account role to access the customer's account. They call the BatchImportFindings API operation from the customer’s account.

For this use case, to call the BatchImportFindings API operation, the partner account assumes a customer managed IAM role in the customer's account.

This call is made from the customer's account. Therefore, the managed resource policy must allow the product ARN for the partner product's account to be used in the call. The Security Hub managed resource policy grants permission for the partner product account and the partner product ARN. The product ARN is the partner's unique identiﬁer as a provider. Because the call does not come from the partner product account, the customer must explicitly grant permission for the partner product to send ﬁndings to Security Hub.

The best practice for cross-account roles between partner and customer accounts is to use an external identifier that the partner provides. This external identifier is part of the cross-account policy definition in the customer’s account. The partner must provide the identifier when it assumes the role. An external identifier provides an additional layer of security when granting AWS account access to a partner. The unique identifier ensures that the partner uses the correct customer account.

Enabling a partner product to send ﬁndings to the customer in Security Hub with a cross-account role happens in four steps:

1. The customer, or partner using cross-account roles working on behalf of the customer, starts the subscription to a product in Security Hub.

2. Security Hub generates the correct managed resource policy with the customer's conﬁrmation.

3. The customer conﬁgures the cross-account role either manually or using AWS CloudFormation. For information on cross-account roles, see Providing access to AWS accounts owned by third parties in the IAM User Guide.

4. The product securely stores the customer role and external ID.

Next, the product sends ﬁndings to Security Hub:

1. The product calls the AWS Security Token Service (AWS STS) to assume the customer role.

2. The product calls the BatchImportFindings API operation on Security Hub with the assumed role's temporary credentials.

Here is an example of an IAM policy that grants the necessary Security Hub permissions to the partner's cross-account role.

{ "Version": "2012-10-17",

(11)

Customer hosted: ﬁndings sent from customer account

"Statement": [ {

"Sid": "VisualEditor0", "Effect": "Allow",

"Resource": "arn:aws:securityhub:us-west-1:111122223333:product-subscription/

company-name/product-name"

} ] }

The Resource section of the policy identifies the specific product subscription. This ensures that the partner can only send findings for the partner product that the customer is subscribed to.

Customer hosted: ﬁndings sent from customer account

This use case covers partners that have a product that is deployed in the customer’s AWS account. The BatchImportFindings API is called from the solution that runs in the customer’s account.

For this use case, the partner product must be granted additional permissions to call the

BatchImportFindings API. How this permission is granted diﬀers based on the partner solution and how it is conﬁgured in the customer’s account.

An example of this approach is a partner product that runs on an EC2 instance in the customer’s account.

This EC2 instance must have an EC2 instance role attached to it that grants that instance the ability to call the BatchImportFindings API operation. This allows the EC2 instance to send security ﬁndings to the customer’s account.

This use case is functionally equivalent to a scenario where a customer loads ﬁndings into their account for a product that they own.

The customer enables the partner product to send ﬁndings from the customer's account to the customer in Security Hub:

1. The customer deploys the partner product into their AWS account manually using AWS CloudFormation, or another deployment tool.

2. The customer deﬁnes the necessary IAM policy for the partner product to use when it sends ﬁndings to Security Hub.

3. The customer attaches the policy to the necessary components of the partner product, such as an EC2 instance, a container, or a Lambda function.

Now the product can send ﬁndings to Security Hub:

1. The partner product uses the AWS SDK or AWS CLI to call the BatchImportFindings API operation in Security Hub. It makes the call from the component in the customer’s account where the policy is attached.

2. During the API call, the necessary temporary credentials are generated to allow the BatchImportFindings call to succeed.

Here is an example of an IAM policy that grants the necessary Security Hub permissions to the partner product in the customer account.

{

(12)

Customer hosted: ﬁndings sent from customer account

"Version": "2012-10-17", "Statement": [

{

"Sid": "VisualEditor0", "Effect": "Allow",

"Resource": "arn:aws:securityhub:us-west-2:111122223333:product-subscription/

company-name/product-name"

} ] }

(13)

Partner onboarding process

As a partner, you can expect to complete several high-level steps as part of your onboarding process. You must complete these steps before you can send security ﬁndings to AWS Security Hub.

1. You initiate an engagement with the APN Partner team or the Security Hub team and express interest in becoming a partner with Security Hub. You identify the email addresses to add to Security Hub communication channels.

2. AWS gives you the Security Hub partner onboarding materials.

3. You are invited to the Security Hub partner Slack channel, where you can ask questions related to your integration.

4. You provide APN Partner contacts with a draft product integration manifest for review.

The product integration manifest contains information that is used to create the partner product Amazon Resource Name (ARN) for the integration with AWS Security Hub.

It provides the Security Hub team with information that appears on the partner provider page in the Security Hub console. It is also used to propose new managed insights related to the integration to add to the Security Hub insight library.

This initial version of the product integration manifest does not have to have the complete details. But it should at least contain the use case and dataset information.

For details about the manifest and the required information, see Product integration manifest (p. 14).

5. The Security Hub team gives you a product ARN for your product. You use the ARN to send ﬁndings to Security Hub.

6. You build your integration to send ﬁndings to or receive ﬁndings from Security Hub.

Mapping ﬁndings to ASFF

To send ﬁndings to Security Hub, you must map your ﬁndings to the AWS Security Finding Format (ASFF).

The ASFF provides a consistent description of ﬁndings that can be shared among AWS security services, partners, and customer security systems. This reduces integration eﬀorts, encourages a common language, and provides a blueprint for implementers.

ASFF is the required wire protocol format to use to send ﬁndings to AWS Security Hub. Findings are represented as JSON documents that adhere to the ASFF JSON Schema and RFC-7493 The I- JSON Message Format. For details on the ASFF schema, see AWS Security Finding Format (ASFF) in the AWS Security Hub User Guide.

See the section called “Guidelines for ASFF mapping” (p. 30).

Building and testing the integration

You can complete all of the testing for your integration using an AWS account that you own.

Doing so gives you full visibility into how the ﬁndings appear in Security Hub. It also helps you understand the customer's experience with your security ﬁndings.

You use the BatchImportFindings API operation to send new and updated ﬁndings to Security Hub.

Throughout the build of a Security Hub integration, AWS encourages you to keep your APN Partner contacts informed about the progress of your integration. You can also ask your APN Partner contacts for help with integration questions.

(14)

See the section called “Guidelines for using the BatchImportFindings API” (p. 35). 7. You demonstrate the integration to the Security Hub product team. This integration must be

demonstrated using an account that the Security Hub team owns.

If they are comfortable with the integration, the Security Hub team gives approval to move forward to list you as a provider.

8. You provide AWS with a ﬁnal manifest for review.

9. The Security Hub team creates the provider integration in the Security Hub console. Customers can then discover and enable the integration.

10.(Optional) You engage in additional marketing eﬀorts to promote your Security Hub integration. See Go-to-market activities (p. 11).

At a minimum, Security Hub recommends that you provide the following assets.

• A demonstration video (3 minutes at most) of the working integration. The video is used for marketing purposes and is posted to the AWS YouTube channel.

• A one-slide architecture diagram to add to the Security Hub ﬁrst call slide deck.

(15)

Entry on the Security Hub partners page

Go-to-market activities

Partners can also engage in optional marketing activities to help explain and promote their AWS Security Hub integration.

If you want to create your own marketing content related to Security Hub, before you release the content, send a draft to your APN Partner manager for review and approval. This ensures that everyone is aligned on messaging.

AWS Partner Network (APN) Partners can use APN Partner Marketing Central and the Market Development Funds (MDF) program to create campaigns and get funding support. For details about these programs, contact your partner manager.

Entry on the Security Hub partners page

After you are approved as a Security Hub partner, your solution can be displayed on the AWS Security Hub partners page.

To be listed on this page, provide the following details to your APN Partner contacts. This could be your partner development manager (PDM), partner solution architect (PSA), or an email to

<[email protected]>.

• A brief description of your solution, its integration with Security Hub, and the value that the integration with Security Hub provides to customers. This description is limited to 700 characters including spaces.

• The URL to a page that describes your solution. This site should be speciﬁc to your AWS integration and more speciﬁcally your Security Hub integration. It should focus on the customer experience and the value that customers receive when they use the integration.

• A high-resolution copy of your logo that is 600 x 300 pixels. For details on the requirements for this logo, see the section called “Logo for partners page” (p. 17).

Press release

As an approved partner, you can optionally publish a press release on your website and public relations channels. The press release must be approved by AWS.

Before you publish the press release, you must submit it to AWS for review by APN Partner marketing, Security Hub leadership, and AWS External Security Services (ESS). The press release can include a proposed quote for the VP of ESS.

To initiate this process, work with your PDM. We have a Service Level Agreement (SLA) of 10 business days to review press releases.

AWS Partner Network (APN) blog

We can also help you post a blog entry that you author to the APN blog. The blog entry must focus on a customer story and use case. It cannot be positioned solely around being an integration launch partner.

If you are interested, contact your PDM or PSA to begin the process. APN blogs can take 8 weeks or longer for ﬁnal approval and publishing.

(16)

Key things to know about the APN blog

When you create a blog post, keep the following items in mind.

What goes into a blog post?

Partner posts should be educational and provide deep expertise on a topic relevant to AWS customers.

The ideal length is no more than 1,500 words. Readers value deep, educational content that teaches them what is possible on AWS.

The content should be original to the APN blog. Do not repurpose content from sources such as existing blog posts or whitepapers.

What are other limits on posting to the APN blog?

Only Advanced or Premier tier partners can post to the APN blog. There are exceptions for Select partners that have an APN Program Designation such as Service Delivery.

Each partner is limited to three posts per year. With tens of thousands of APN Partners, AWS must be equitable in its coverage.

Each post must have a technical sponsor who can validate the solution or use case.

How long does it take to edit a blog post before it is posted?

After you submit the ﬁrst full-length draft of the blog post, it takes from four to six weeks to edit.

Why write for the APN blog?

An APN blog post can provide the following beneﬁts.

• Credibility – For APN Partners, having a story published by AWS can inﬂuence customers globally.

• Visibility – The APN blog is one of the most-read blogs at AWS with 1.79 million page views in 2019, including inﬂuenced traﬃc.

• Business – APN Partner posts have connect buttons that can generate leads through the APN Customer Engagements (ACE) program.

What type of content is the best ﬁt?

The following types of content are best suited for an APN blog post.

• Technical content is the most popular type of story. This includes solution spotlights and how-to information. Over 75% of readers look at this technical content.

• Customers value 200-level or above stories that demonstrate how something works on AWS or how an APN Partner solved a business problem for customers.

• Posts written by technical experts or subject matter experts perform the best by far.

Slick sheet or marketing sheet

A slick sheet is a one-page document that outlines your product, its integration architecture, and joint customer use cases.

(17)

Whitepaper or ebook

If you create a slick sheet for your integration, send a copy to the Security Hub team. They will add it to the partner page.

Whitepaper or ebook

If you create a whitepaper or ebook outlining your product, its integration architecture, and joint customer use cases, send a copy to the Security Hub team. They will add it to the Security Hub partner page.

Webinar

If you do conduct a webinar about your integration, send a recording of the webinar to the Security Hub team. The team will link to it from the partner page.

The team can also provide a Security Hub subject matter expert to participate in your webinar.

Demo video

For marketing purposes, you can produce a demo video of the working integration. Post such a video on your video platform account, and the Security Hub team will link to it from the partner page.

(18)

Use case and marketing information

Product integration manifest

Every AWS Security Hub integration partner must complete a product integration manifest that provides the required details for the proposed integration.

The Security Hub team uses this information in several ways:

• To create your website listing

• To create the product card for the Security Hub console

• To inform the product team of your use case.

To evaluate the quality of the proposed integration and the provided information, the Security Hub team uses the the section called “Product readiness checklist” (p. 35). This checklist determines whether your integration is ready to be launched.

All of the technical information that you provide must also be reﬂected in your documentation.

You can download a PDF version of the product integration manifest from the Resources section of the AWS Security Hub partners page. Note that the partners page is not available in the China (Beijing) and China (Ningxia) Regions.

Contents

• Use case and marketing information (p. 14)

• Finding providers and consumers use case (p. 14)

• Consulting Partner (CP) use case (p. 15)

• Datasets (p. 15)

• Architecture (p. 15)

• Conﬁguration (p. 16)

• Average ﬁndings per day per customer (p. 16)

• Latency (p. 16)

• Company and product description (p. 16)

• Partner website assets (p. 16)

• Logo for partners page (p. 17)

• Logos for Security Hub console (p. 17)

• Finding types (p. 17)

• Hotline (p. 17)

• Heartbeat ﬁnding (p. 18)

• AWS Security Hub console information (p. 18)

• Company information (p. 18)

• Product information (p. 19)

Use case and marketing information

The following use cases can help you conﬁgure AWS Security Hub for diﬀerent purposes.

Finding providers and consumers use case

Required for independent software vendors (ISV).

(19)

Consulting Partner (CP) use case

To describe your use case around your integration with AWS Security Hub, answer the following questions. If you do not plan to either send or receive ﬁndings, note that in this section and then complete the next section.

The following information must be reﬂected in your documentation.

• Will you send ﬁndings, receive ﬁndings, or both?

• If you plan to send findings, what types of findings will you send? Will you send all findings or a specific subset of findings?

• If you plan to receive findings, what will you do with those findings? What types of findings will you receive? For example, will you receive all findings, findings of a certain type, or only specific findings that a customer selects?

• Do you plan to update findings? If so, which fields will you update? Security Hub recommends that you update findings instead of always creating new ones. Updating existing findings helps decrease the finding noise for customers.

To update a finding, you send a finding with a finding ID that is assigned to a finding that you already sent.

To get early feedback on your use case and datasets, contact the APN Partner or Security Hub team.

Consulting Partner (CP) use case

Required if you are a Security Hub Consulting Partner.

Provide two customer use cases for your work with Security Hub. These can be private use cases. The Security Hub team does not advertise them anywhere. They should describe either or both of the following actions.

• How do you help customers bootstrap Security Hub? For example, have you helped customers use professional services, a Terraform module, or an AWS CloudFormation template?

• How do you help customers operationalize and extend Security Hub? For example, have you provided response or remediation templates, built custom integrations, or used business intelligence tools to set up an executive dashboard?

Datasets

Required if you send ﬁndings to Security Hub.

For the ﬁndings that you will send to Security Hub, provide the following information.

• The ﬁndings in their native format, such as JSON or XML

• An example of how you will convert the ﬁndings to the AWS Security Finding Format (ASFF)

Let the Security Hub team know if you need any updates to the ASFF to support your integration.

Architecture

Required if you send ﬁndings to or receive ﬁndings from Security Hub.

Describe how you will integrate with Security Hub. This information also must be reﬂected in your documentation.

You must provide architecture diagrams. When preparing your architecture diagrams, consider the following:

(20)

Conﬁguration

• What AWS services, operating system agents, and so on will you use?

• If you will send ﬁndings to Security Hub, will you send ﬁndings from the customer AWS account or from your own AWS account?

• If you will receive ﬁndings, how will you use the CloudWatch Events integration?

• How will you convert ﬁndings to ASFF?

• How will you batch ﬁndings, track the ﬁnding state, and avoid throttling limits?

Conﬁguration

Required if you send ﬁndings to or receive ﬁndings from Security Hub.

Describe how a customer will conﬁgure your integration with Security Hub.

At a minimum, you must use AWS CloudFormation templates or a similar infrastructure such as code templates. Some partners have provided a user interface to support one-click integration.

Conﬁguration should take no more than 15 minutes. Your product documentation must also provide conﬁguration guidance for your integration.

Average ﬁndings per day per customer

How many ﬁnding updates per month (average and maximum) do you expect to send to Security Hub across your customer base? Orders of magnitude estimates are acceptable.

Latency

How quickly will you batch and send ﬁndings to Security Hub? In other words, what is the latency from when the ﬁnding is created in your product to when it is sent to Security Hub?

This information must be reﬂected in your product documentation for your integration. It is a common question from customers.

Company and product description

Required for all integrations with Security Hub.

Brieﬂy describe your company and product, with a speciﬁc emphasis on the nature of your Security Hub integration. We use this on our Security Hub partners page.

If you are integrating multiple products with Security Hub, you can provide a separate description for each product, but we will combine them into a single entry on the partner page.

Each description can be no more than 700 characters with spaces.

Partner website assets

At a minimum, you must provide a URL to use for the Learn More hyperlink on the Security Hub partners page. It should be a marketing landing page that describes the integration between your product and Security Hub.

(21)

Logo for partners page

If you integrate multiple products with Security Hub, you can have a single landing page for them.

Security Hub recommends that this landing page include a link to your conﬁguration instructions.

You can also provide links to other resources such as blogs, webinars, demo videos, or whitepapers.

Security Hub will also link to those from their partners page.

Logo for partners page

Required for all Security Hub integrations.

Provide a URL to a logo to display on the Security Hub partners page. The logo must meet the following criteria:

• Size: 600 x 300 pixels

• Cropping: tight with no padding

• Background: transparent

• Format: PNG

Logos for Security Hub console

Required for all integrations.

Provide URLs to the light mode and dark mode logos to display on the Security Hub console.

The logos must meet the following criteria:

• Format: SVG

• Size: 175 x 40 pixels. If larger, the image should use that ratio.

• Cropping: tight no padding

• Background: transparent

For detailed guidelines for the small logo, see the section called “Guidelines for the console logo” (p. 26).

Finding types

Provide a table that documents the ASFF-formatted finding types that you use and how they align to your native finding types. For details on finding types in ASFF, see Types taxonomy for ASFF in the AWS Security Hub User Guide.

We recommend that you also include this information in your product documentation.

Hotline

Provide an email address and phone number or pager number for a technical point of contact. Security Hub will communicate with this contact regarding any technical issues, such as when an integration no longer works.

Also provide a 24/7 point of contact for high severity technical issues.

(22)

Heartbeat ﬁnding

Recommended if you sending ﬁndings to Security Hub.

Can you send Security Hub a "heartbeat" ﬁnding every ﬁve minutes that indicates that your integration with Security Hub is functional?

If you can, then do so using the ﬁnding type Heartbeat.

AWS Security Hub console information

Provide JSON text to the AWS Security Hub team that contains the following information. Security Hub uses this information to create your product ARN, display the providers list in the console, and include your proposed managed insights in the Security Hub insight library.

Product information

This section provides information about your product. Here's an example:

{ "IntegrationTypes": ["SEND_FINDINGS_TO_SECURITY_HUB"], "id": "example-corp-network-defender",

"regionsNotSupported": "us-west-1",

"commercialAccountNumber": "111122223333", "govcloudAccountNumber": "444455556666", "chinaAccountNumber": "777788889999", "name": "Example Corp Product",

"description": "Example Corp Product is a managed threat detection service.", "importType": "BATCH_IMPORT_FINDINGS_FROM_CUSTOMER_ACCOUNT",

"category": "Intrusion Detection Systems (IDS)", "marketplaceUrl": "marketplace_url",

"configurationUrl": "configuration_url"

}

The product information contains the following ﬁelds.

IntegrationType Yes Indicates whether your product sends findings to Security Hub, receives findings from Security Hub, or both sends and receives findings.

If you are a Consulting Partner, leave this ﬁeld blank.

Type: Array of string Valid values:

SEND_FINDINGS_TO_SECURITY_HUB | RECEIVE_FINDINGS_FROM_SECURITY_HUB

id Yes The product's unique identiﬁer. These must be

unique within a company. They do not need to be unique across companies. This is likely the same or similar as name.

Type: String

Minimum length: 5 characters Maximum length: 24 characters

Allowed characters: lowercase letters, numbers, and hyphens

Must begin with a lowercase letter. Must end with a lower case letter or a number.

(24)

Product information

regionsNotSupported Yes Which of the following AWS Regions do you not support? In other words, in which Regions should Security Hub not show you as an option in our partners page in the Security Hub console?

Type: String

Provide the Region code only. For example, us- west-1.

For a list of Regions, see Regional endpoints in the AWS General Reference.

The Region codes for the AWS GovCloud (US) are us-gov-west-1 (for AWS GovCloud (US-West)) and us-gov-east-1 (for AWS GovCloud (US- East)).

The Region codes for China Regions are cn-north-1 (for China (Beijing)) and cn- northwest-1 (for China (Ningxia)).

commercialAccountNumber Yes The primary AWS account number for the product for the AWS Regions.

If you send ﬁndings to Security Hub, then the account you provide is based on where you send the ﬁndings from.

• From your AWS account. In this case, provide the account number that you use to submit ﬁndings.

• From the customer's AWS account. In this case, Security Hub recommends that you provide the primary account number that you use to test the integration.

Ideally you will use the same account for all of your products across all Regions. If this is not possible, contact the Security Hub team.

If you only receive ﬁndings from Security Hub, this account number is not required.

Type: String

(25)

Product information

govcloudAccountNumber No The primary AWS account number for the product for AWS GovCloud (US) Regions (if your product is available in AWS GovCloud (US)).

• From the customer's AWS account. In this case, Security Hub recommends that you provide the primary account number that you use to test the integration.

Ideally you use the same account for all of your products across all AWS GovCloud (US) Regions.

If this is not possible, contact the Security Hub team.

If you only receive ﬁndings from Security Hub, this account number is not required.

Type: String

chinaAccountNumber No The primary AWS account number for the product for China regions (if your product is available in the China regions).

• From the customer's AWS account. In this case, Security Hub recommends that you provide the primary account number that you use to test the product integration.

Ideally you use the same account for all of your products across all China regions. If this is not possible, contact the Security Hub team.

If you only receive ﬁndings from Security Hub, this can be any account that you own in a China region.

Type: String

(26)

Product information

name Yes The name of the provider's product to display on

the Security Hub console.

Type: String

description Yes The description of the provider's product to

display on the Security Hub console.

Type: String

importType Yes The type of resource policy for the partner.

During the partner onboarding process, you can specify one of the following resource policies, or you can specify NEITHER.

• With

BATCH_IMPORT_FINDINGS_FROM_PRODUCT_ACCOUNT, you can only send ﬁndings to Security Hub from the account listed in your product ARN.

• With

BATCH_IMPORT_FINDINGS_FROM_CUSTOMER_ACCOUNT, you can only send ﬁndings from the customer

account that subscribed to you.

Type: String Valid values:

BATCH_IMPORT_FINDINGS_FROM_PRODUCT_ACCOUNT

|

BATCH_IMPORT_FINDINGS_FROM_CUSTOMER_ACCOUNT

|

NEITHER

(27)

Product information

category Yes The categories that deﬁne your product. Your

selections are displayed on the Security Hub console.

Choose up to three categories.

Custom selections are not allowed. If you think your category is missing, contact the Security Hub team.

Type: Array

Available categories:

• API Firewall

• Asset Management

• AV Scanning and Sandboxing

• Backup and Disaster Recovery

• Breach and Attack Simulation

• Bug Bounty Platform

• Certificate Management

• Cloud Access Security Broker

• Cloud Security Posture Management

• Configuration and Patch Management

• Configuration Management Database (CMDB)

• Consulting Partner

• Container Security

• Cyber Range

• Data Access Management

• Data Classification

• Data Loss Prevention

• Data Masking and Tokenization

• Database Activity Monitoring

• DDoS Protection

• Deception

• Device Control

• Dynamic Application Security Testing

• Data Encryption

• Email Gateway

• Encrypted Search

• Endpoint Detection and Response (EDR)

• Endpoint Forensics

• Forensics Toolkit

• Fraud Detection

• Governance, Risk, and Compliance (GRC)

(28)

Product information

• Host-based Intrusion Detection (HIDs)

• Human Resources Information System

• Interactive Application Security Testing (IAST)

• Instant Messaging

• IoT Security

• IT Security Training

• IT Ticketing and Incident Management

• Managed Security Service Provider (MSSP)

• Micro-Segmentation

• Multi-Cloud Management

• Multi-Factor Authentication

• Network Access Control (NAC)

• Network Firewall

• Network Forensics

• Network Intrusion Detection Systems (IDS)

• Network Intrusion Prevention Systems (IPS)

• Phishing Simulation and Training

• Privacy Operations

• Privileged Access Management

• Rogue Device Detection

• Runtime Application Self-Protection (RASP)

• Secure Web Gateway

marketplaceUrl No The URL to your product AWS Marketplace

destination. The URL is displayed in the Security Hub console.

Type: String

This must be an AWS Marketplace URL.

If you do not have an AWS Marketplace listing, leave this ﬁeld blank.

(29)

Product information

configurationUrl Yes The URL to your product documentation about the integration with Security Hub. This content is hosted on your website or on a webpage that you manage, such as a GitHub page.

Type: String

Your documentation should include the following information.

• Conﬁguration instructions

• Links to AWS CloudFormation templates (if necessary)

• Information about your use case for the integration

• Latency

• ASFF mapping

• Types of ﬁndings included

• Architecture

(30)

Guidelines for the console logo

Guidelines and checklists

As you prepare the required materials for your AWS Security Hub integration, use these guidelines.

The readiness checklist is used to conduct a ﬁnal review of the integration before Security Hub makes it available to Security Hub customers.

Topics

• Guidelines for the logo to display on the AWS Security Hub console (p. 26)

• Tenets for creating and updating ﬁndings (p. 29)

• Guidelines for mapping ﬁndings into the AWS Security Finding Format (ASFF) (p. 30)

• Guidelines for using the BatchImportFindings API (p. 35)

• Product readiness checklist (p. 35)

Guidelines for the logo to display on the AWS Security Hub console

For the logo to display on the AWS Security Hub console, follow these guidelines.

Light and dark modes

You must provide both a light mode and a dark mode version of the logo.

Format

SVG ﬁle format Background color

Transparent Size

Ideal ratio is 175 px wide by 40 px high.

Minimum height is 40 px.

Rectangular logos work best.

The following image shows how an ideal logo is displayed on the Security Hub console.

(31)

If your logo does not match these dimensions, Security Hub reduces the size to a maximum height of 40 px and a maximum width of 175 px. This aﬀects how the logo is displayed on the Security Hub console.

The following image compares the display of a logo that used the ideal size to logos that were wider or taller.

(32)

Cropping

Crop the logo image as close as possible. Do not provide extra padding.

The following image shows the diﬀerence between a logo that is cropped closely and a logo that has extra padding.

(33)

Tenets for creating and updating ﬁndings

As you plan how you will create and update ﬁndings in AWS Security Hub, keep the following tenets in mind.

Make ﬁndings speciﬁc so that customers can easily take action on them.

Customers want to automate response and remediation actions and correlate findings with other findings. To support this, findings should have the following characteristics:

• They should generally deal with a single or primary resource.

• They should have a single ﬁnding type.

• They should deal with a single security event.

When a finding contains data for multiple security events, it is more difficult for customers to take action on the finding.

Map all of your ﬁnding ﬁelds to the AWS Security Finding Format (ASFF). Allow customers to rely on Security Hub as a source of truth.

Customers expect that every ﬁeld that is in your native ﬁnding format is also represented in the Security Hub ASFF.

Customers want all data to be present in the Security Hub version of the ﬁnding. Missing data causes them to lose trust in Security Hub as a central source of security information.

Minimize redundancy in ﬁndings. Do not overwhelm customers with ﬁnding volumes.

Security Hub is not a general log management tool. You should send ﬁndings to Security Hub that are highly actionable, and that customers can directly respond to, remediate, or correlate with other ﬁndings.

When there is only a minor change to the finding, update the finding instead of creating a new finding.

When there is a major change to the finding, such as to the severity score or resource identifier, create a new finding.

For example, to create ﬁndings for individual port scans in real time is not highly actionable. Because port scanning can happen continuously, it would produce a large volume of ﬁndings. It is far more

(34)

Guidelines for ASFF mapping

compelling and precise to simply update the last scan time and scan count on a single ﬁnding for a port scan on a MongoDB port from a TOR node.

Allow customers to customize their ﬁndings to make them more meaningful.

Customers want to be able to adjust certain ﬁnding ﬁelds to make them more relevant to their environment or requirements.

For example, customers want to be able to add notes, tags, and adjust severity scores based on the type of account or the type of resource that the ﬁnding is associated with.

Guidelines for mapping ﬁndings into the AWS Security Finding Format (ASFF)

Use the following guidelines to map your ﬁndings to the ASFF. For detailed descriptions of each ASFF ﬁeld and object, see AWS Security Finding Format (ASFF) in the AWS Security Hub User Guide.

Identifying information

SchemaVersion is always 2018-10-08.

ProductArn is the ARN that AWS Security Hub assigns to you.

Id is the value that Security Hub uses to index findings. The finding identifier must be unique, to ensure that other findings are not overwritten. To update a finding, resubmit the finding with the same identifier.

GeneratorId can be the same as Id or can refer to a discrete unit of logic, such as an Amazon GuardDuty detector ID, AWS Conﬁg recorder ID, or IAM Access Analyzer ID.

Title and Description

Title should contain some information about the aﬀected resource. Title is limited to 256 characters, including spaces.

Add longer detailed information to Description. Description is limited to 1024 characters, including spaces. You can consider adding truncation to descriptions. Here's an example:

"Title": "Instance i-12345678901 is vulnerable to CVE-2019-1234",

"Description": "Instance i-12345678901 is vulnerable to CVE-2019-1234. This vulnerability affects version 1.0.1 of widget-1 and earlier, and can lead to buffer overflow when someone sends a ping.",

Finding types

You provide your ﬁnding type information in FindingProviderFields.Types.

Types should match the types taxonomy for ASFF.

If needed, you can specify a custom classiﬁer (the third namespace).

Timestamps

The ASFF format includes a few diﬀerent timestamps.

(35)

Severity

CreatedAt and UpdatedAt

You must submit CreatedAt and UpdatedAt every time you call BatchImportFindings for each ﬁnding.

The values must match the ISO8601 format in Python 3.8.

datetime.datetime.utcnow().replace(tzinfo=datetime.timezone.utc).isoformat()

FirstObservedAt and LastObservedAt

FirstObservedAt and LastObservedAt must match when your system observed the ﬁnding. If you do not record this information, you do not need to submit these timestamps.

The values match the ISO8601 format in Python 3.8.

datetime.datetime.utcnow().replace(tzinfo=datetime.timezone.utc).isoformat()

Severity

You provide severity information in the FindingProviderFields.Severity object, which contains the following ﬁelds.

Original

The severity value from your system. Original can be any string, to accommodate the system that you use.

Label

The required Security Hub indicator of the ﬁnding severity. The allowed values are as follows.

• INFORMATIONAL – No issue was found.

• LOW – The issue does not require action on its own.

• MEDIUM – The issue must be addressed but not urgently.

• HIGH – The issue must be addressed as a priority.

• CRITICAL – The issue must be remediated immediately to prevent further harm.

Findings that are compliant should always have Label set to INFORMATIONAL. Examples of INFORMATIONAL findings are findings from security checks that passed and AWS Firewall Manager findings that are remediated.

Customers often sort ﬁndings by their severity to give their security operations teams a to-do list. Be conservative when setting the ﬁnding severity to HIGH or CRITICAL.

Your integration documentation must include your mapping rationale.

Remediation

Remediation has two elements. These elements are combined on the Security Hub console.

Remediation.Recommendation.Text appears in the Remediation section of the ﬁnding details. It is hyperlinked to the value of Remediation.Recommendation.Url.

Currently, only ﬁndings from Security Hub standards, IAM Access Analyzer, and Firewall Manager display hyperlinks to documentation on how to remediate the ﬁnding.

(36)

SourceUrl

Only use SourceUrl if you can provide a deep-linked URL to your console for that speciﬁc ﬁnding.

Otherwise, omit it from the mapping.

Security Hub does not support hyperlinks from this ﬁeld, but it is exposed on the Security Hub console.

Malware, Network, Process, ThreatIntelIndicators

Where applicable, use Malware, Network, Process, or ThreatIntelIndicators. Each of these objects is exposed in the Security Hub console. Use these objects in the context of the ﬁnding that you are sending.

For example, if you detect malware that makes an outbound connection to a known command and control node, provide the details for the EC2 instance in Resource.Details.AwsEc2Instance.

Provide the relevant Malware, Network, and ThreatIntelIndicator objects for that EC2 instance.

Malware

Malware is a list that accepts up to ﬁve arrays of malware information. Make the malware entries relevant to the resource and the ﬁnding.

Each entry has the following ﬁelds.

Name

The name of the malware. The value is a string of up to 64 characters.

Name should be from a vetted threat intelligence or researcher source.

Path

The path to the malware. The value is a string of up to 512 characters. Path should be a Linux or Windows system ﬁle path, except in the following cases.

• If you scan objects in an S3 bucket or an EFS share against YARA rules, then Path is the S3:// or HTTPS object path.

• If you scan ﬁles in a Git repository, then Path is the Git URL or clone path.

State

The status of the malware. The allowed values are OBSERVED | REMOVAL_FAILED | REMOVED.

In the ﬁnding title and description, make sure that you provide context for what happened with the malware.

For example, if Malware.State is REMOVED, then the ﬁnding title and description should reﬂect that your product removed the malware that is located on the path.

If Malware.State is OBSERVED, then the ﬁnding title and description should reﬂect that your product encountered this malware located on the path.

Type

Indicates the type of malware. The allowed values are ADWARE | BLENDED_THREAT | BOTNET_AGENT

If you need an additional value for Type, contact the Security Hub team.

(37)

Malware, Network, Process, ThreatIntelIndicators

Network

Network is a single object. You cannot add multiple network-related details. When mapping the ﬁelds, use the following guidelines.

Destination and source information

The destination and source are easy to map TCP or VPC Flow Logs or WAF logs. They are more diﬃcult to use when you are describing network information for a ﬁnding about an attack.

Typically, the source is where the attack originated from, but it could have other sources as listed below. You should explain the source in your documentation and also describe it in the ﬁnding title and description.

• For a DDoS attack on an EC2 instance, the source is the attacker, although a real DDoS attack may use millions of hosts. The destination is the public IPv4 address of the EC2 instance. Direction is IN.

• For malware that is observed communicating from an EC2 instance to a known command and control node, the source is the IPV4 address of the EC2 instance. The destination is the command and control node. Direction is OUT. You would also provide Malware and ThreatIntelIndicators.

Protocol

Protocol always maps to an Internet Assigned Numbers Authority (IANA) registered name, unless you can provide a speciﬁc protocol. You should always use this and provide the port information.

Protocol is independent from the source and destination information. Only provide it when it makes sense to do so.

Direction

Direction is always relative to the AWS network boundaries.

• IN means it is entering AWS (VPC, service).

• OUT means it is exiting the AWS network boundaries.

Process

Process is a single object. You cannot add multiple process-related details. When mapping the ﬁelds, use the following guidelines.

Name

Name should match the name of the executable. It accepts up to 64 characters.

Path

Path is the ﬁle system path to the process executable. It accepts up to 512 characters.

Pid, ParentPid

Pid and ParentPid should match the Linux process identifier (PID) or the Windows event ID. To differentiate, use EC2 Amazon Machine Images (AMI) to provide the information. Customers can probably differentiate between Windows and Linux.

Timestamps (LaunchedAt and TerminatedAt)

If you cannot reliably retrieve this information, and it is not accurate to the millisecond, do not provide it.

If a customer relies on timestamps for forensics investigation, then having no timestamp is better than having the wrong timestamp.

(38)

Resources

ThreatIntelIndicators

ThreatIntelIndicators accepts an array of up to ﬁve threat intelligence objects.

Here are some examples of how to map threat intelligence indicators:

• You found a process that you know is associated with Cobalt Strike. You learned this from FireEye’s blog.

Set Type to PROCESS. Also create a Process object for the process.

• Your mail ﬁlter found someone sending a well-known hashed package from a known malicious domain.

Create two ThreatIntelIndicator objects. One object is for the DOMAIN. The other is for the HASH_SHA1.

• You found malware with a Yara rule (Loki, Fenrir, Awss3VirusScan, BinaryAlert).

Create two ThreatIntelIndicator objects. One is for the malware. The other is for the HASH_SHA1.

Resources

For Resources, use our provided resource types and detail ﬁelds whenever possible. Security Hub is constantly adding new resources to the ASFF. To receive a monthly log of the changes to ASFF, contact

<[email protected]>.

If you cannot ﬁt the information in the details ﬁelds for a modeled resource type, map the remaining details to Details.Other.

For a resource that is not modeled in ASFF, set Type to Other. For the detailed information, use Details.Other.

You can also use the Other resource type for non-AWS ﬁndings.

ProductFields

Only use ProductFields if you cannot use another curated ﬁeld for Resources or a descriptive object such as ThreatIntelIndicators, Network, or Malware.

If you do use ProductFields, you must provide a strict rationale for this decision.

Compliance

Only use Compliance if your ﬁndings are related to compliance.

Security Hub uses Compliance for the ﬁndings it generates based on controls.

Firewall Manager uses Compliance for its ﬁndings because they are compliance-related.

Fields that are restricted

These ﬁelds are intended for customers to keep track of their investigation of a ﬁnding.

(39)

Guidelines for using the BatchImportFindings API

Do not map to these ﬁelds or objects.

• Note

• UserDefinedFields

• VerificationState

• Workflow

For these fields, map to the fields that are in the FindingProviderFields object. Do not map to the top-level fields.

• Confidence – Only include a conﬁdence score (0-99) if your service has a similar functionality, or if you stand 100% by your ﬁnding.

• Criticality – The criticality score (0-99) is intended to express the importance of the resource associated with the ﬁnding.

• RelatedFindings – Only provide related findings if you can keep track of findings related to the same resource or finding type. To identify a related finding, you must refer to the finding identifier of a finding that is already in Security Hub.

Guidelines for using the BatchImportFindings API

When using the BatchImportFindings API operation to send ﬁndings to AWS Security Hub, use the following guidelines.

• You must call BatchImportFindings using the account that is associated with the findings. The identifier of the associated account is the value of the AwsAccountId attribute for the finding.

• Send the largest batch that you can. Security Hub accepts up to 100 ﬁndings per batch, up to 240 KB per ﬁnding, and up to 6 MB per batch.

• The throttle rate limit is 10 TPS per account per Region, with a burst of 30 TPS.

• You must implement a mechanism to retain the state of ﬁndings if throttling or network issues exist.

You also need the finding state so that you can submit finding updates as a finding moves in and out of compliance.

• For information about the maximum lengths of strings and other limitations, see AWS Security Finding Format (ASFF) in the AWS Security Hub User Guide.

Product readiness checklist

The AWS Security Hub and APN Partner teams use this checklist to validate that the integration is ready to be launched.

ASFF mapping

These questions are related to the mapping of your ﬁnding to the AWS Security Finding Format (ASFF).

Is all of the partner's ﬁnding data mapped into ASFF?

Map all your ﬁndings to the ASFF in some way.

Use curated ﬁelds such as modeled resource types, Network, Malware, or ThreatIntelIndicators.

(40)

ASFF mapping

Map anything else into Resource.Details.Other or ProductFields as appropriate.

Does the partner use Resource.Details ﬁelds, such as AwsEc2instance, AwsS3Bucket, and Container? Does the partner use Resource.Details.Other to deﬁne resource details that are not modeled in the ASFF?

Whenever possible, use the provided ﬁelds for curated resources such as EC2 instances, S3 buckets, and security groups in your ﬁndings.

Map other information related to resources to Resource.Details.Other only when there is not a direct match.

Does the partner map values to UserDefinedFields?

Do not use UserDefinedFields.

Consider using another curated ﬁeld, such as Resource.Details.Other or ProductFields.

Does the partner map information into ProductFields that could be mapped into other ASFF ﬁelds?

Only use ProductFields for product-specific information such as versioning information, product- specific severity findings, or other information that cannot be mapped into a curated field or Resources.Details.Other.

Does the partner import their own timestamps for FirstObservedAt?

The FirstObservedAt timestamp is intended to record the time when a ﬁnding was observed in the product. Map this ﬁeld if at all possible.

Does the partner provide unique values generated for each finding identifier, except for findings that they want to update?

All findings in Security Hub are indexed on the finding identifier (Id attribute). This value must always be unique to ensure that findings are not updated accidentally.

You should also maintain the finding identifier state for the purpose of updating the findings.

Does the partner provide a value that maps ﬁndings to a generator ID?

GeneratorID should not have the same value as the ﬁnding ID.

GeneratorID should be able to logically link ﬁndings by what generated them.

This can be a subcomponent within a product (Product A - Vulnerability vs Product A - EDR) or something similar.

Does the partner use the required ﬁnding types namespaces in a way that is relevant to their

product? Does the partner use the recommended finding type categories or classifiers in their finding types?

The ﬁnding type taxonomy should closely map to the ﬁndings that the product generates.

The ﬁrst-level namespaces outlined in the AWS Security Finding Format are required.

You can use custom values for the second- and third-level namespaces (Categories or Classiﬁers).

Does the partner capture network ﬂow information in the Network ﬁelds, if they have network data?

If your product captures NetFlow information, map it to the Network ﬁeld.

Does the partner capture process (PID) information in the Process ﬁelds, if they have process data?

If your product captures process information, map it to the Process ﬁeld.

Does the partner capture malware information in the Malware ﬁelds, if they have malware data?

If your product captures malware information, map it to the Malware ﬁeld.

AWS Security Hub

AWS Security Hub

Partner Integration Guide

AWS Security Hub: Partner Integration Guide

Table of Contents

Overview of third-party integration with AWS Security Hub

Why integrate with AWS Security Hub?

Preparing to send ﬁndings to AWS Security Hub

Preparing to receive ﬁndings from AWS Security Hub

Resources for learning about AWS Security Hub

Partner prerequisites

Integration use cases and required permissions

Partner hosted: ﬁndings sent from partner account

Partner hosted: ﬁndings sent from the customer account

Customer hosted: ﬁndings sent from customer account

Partner onboarding process

Go-to-market activities

Entry on the Security Hub partners page

Press release

AWS Partner Network (APN) blog

Key things to know about the APN blog

Why write for the APN blog?

What type of content is the best ﬁt?

Slick sheet or marketing sheet

Whitepaper or ebook

Webinar

Demo video

Product integration manifest

Use case and marketing information

Finding providers and consumers use case

Consulting Partner (CP) use case

Datasets

Architecture

Conﬁguration

Average ﬁndings per day per customer

Latency

Company and product description

Partner website assets

Logo for partners page

Logos for Security Hub console

Finding types

Hotline

Heartbeat ﬁnding

AWS Security Hub console information

Company information

Product information

Guidelines and checklists

Guidelines for the logo to display on the AWS Security Hub console

Tenets for creating and updating ﬁndings

Guidelines for mapping ﬁndings into the AWS Security Finding Format (ASFF)

Identifying information

Title and Description

Finding types

Timestamps

Severity

Remediation

SourceUrl

Malware, Network, Process, ThreatIntelIndicators

Malware

Network

Process

ThreatIntelIndicators

Resources

ProductFields

Compliance

Fields that are restricted

Guidelines for using the BatchImportFindings API

Product readiness checklist

ASFF mapping