Skip to main content

Integrate with Amazon Security Lake using Contrast Assess

Integrate Contrast Assess with Amazon Security Lake to push findings and other relevant security data automatically.

Before you begin

Before you start, you must have:

  • AWS Region

Create a Custom Source in AWS

  1. In AWS, go to Amazon Security Lake.

  2. Select Custom Source.

  3. Click Create New Source.

  4. Enter a Data source name of your choice.

  5. Set the OCSF Event class to Security Finding.

  6. Input the AWS account ID and External ID.

    These IDs are under the Amazon Security Lake section on Contrast's Integrations page. From the user menu in Contrast select Organization settings > Integrations.

  7. Once a custom source is created, retrieve the generated Role ARN and the S3 ARN. You will need these to connect to AWS.

  8. Continue with connecting to Amazon Security Lake.

Connect to Amazon Security Lake

  1. In Contrast, go to the user menu and select Organization settings > Integrations.

  2. Find and select the Amazon Security Lake integration section.

  3. Select Manage Credentials.

    AWSSecurityLake2.png
  4. Enter the generated Role ARN and the S3 ARN from before.

  5. Choose the AWS Region from the list or enter it manually.

  6. Select Save.

  7. Continue by setting up applications in Contrast Assess.

Set up applications in Contrast Assess

Once your credentials are set up, proceed to configure the applications:

  1. In the Amazon Security Lake integration section in Contrast, select Applications.

  2. Select whether to activate the Amazon Security Lake integration for all Assess applications or select specific application names from a list.

  3. Select Save.

Retry mechanism

In case synchronization between Contrast Assess and Amazon Security Lake fails, a retry mechanism ensures data reliability:

  • If an event fails to sync, it will be stored and retried every night at midnight GMT.

  • The retry count will increase by one with a maximum of three retries for up to 72 hours. After the third unsuccessful retry, the event will be discarded.

  • Suppose a vulnerability creation event fails and is stored. Any subsequent update or delete action relating to that failed event will be stored and replayed in chronological order to maintain the correct state.