Let’s Get Under the Hood of Imperva Snapshot

A stress-free guide for the prudent cloud operator

With minimal setup, Imperva Snapshot enables you to immediately start your in-depth Amazon Web Services (AWS) RDS database assessment. With no prior training required, cloud operators can use this useful tool to pinpoint deficiencies in their security posture, with zero performance impact on the cloud environment.

This is a fully automated tool and easy to use. Simply select an AWS RDS database, run a scan, and moments later receive a full assessment report to your inbox. Insights in a snap.

Running a new tool in your cloud environment however, might raise concerns at times. This post addresses common concerns to relieve any stress you may be having prior to running the Imperva Snapshot tool.

In this blog you will find in-depth details and descriptions of the entire Imperva Snapshot scanning process. Starting with a high level overview followed by a step by step chronological breakdown. With a full transparency into Imperva Snapshot’s component you will learn:

• Which templates the tool uses. What the created Lambdas functions are.
• What networking configurations are applied on the isolated VPC environment as well as which functions and API’s we use to trigger the restore, scan and report processes.
• Lastly, we finalize with an explicit list of AWS IAM roles requirements for running the tool.

It all starts with a Snapshot

To start a scanning process, Imperva Snapshot restores the latest AWS RDS database snapshot (of the chosen database) into an isolated, temporary Virtual Private Cloud (VPC). This enables it to perform a scan with zero-performance impact, and to maintain the cloud account’s privacy policy. The data contained in the database never leaves the cloud account environment. After Imperva Snapshot completes the scan, the service deletes itself.

×

Apr 25 Upcoming Webinar

Thales + Imperva: Trusted End-to-end Data Security

Register Now

Registration and scan activation

After registration, the user receives an email (Figure 1) asking to insert the database ID in order to begin a scan. To initiate the process, the user must verify they are currently logged in to their AWS account and must select a database that is within the same AWS region into which they are logged in to.

Building blocks – unboxing Imperva Snapshot

The Imperva Snapshot tool consists of multiple components:

• 3 CloudFormation templates
• 4 Lambdas
• 1 isolated VPC
• 4 restricted AWS IAM roles attached to those Lambdas

CloudFormation templates

Firstly, note that all Imperva Snapshot’s CloudFormation templates are publicly available. Those templates trigger and provision Imperva Snapshot setup and scan.

1. Root template
2. Setup template
3. Installer template

The Root template is the first template in the chain and collects the initial key parameters from the user. Stack name, token and RDS instance ID. With those parameters it later activates the Setup and Installer templates.

• Stack Name: An arbitrary name for the AWS CF stack that is created in the process.
  The default is “ImpervaSnapshot”.
• Token: During registration a unique authentication token is generated. Imperva Snapshot uses this token to validate the user.
  Editing this parameter will result in a scan failure.
• RDS Instance ID: Instance DB ID to scan or the Cluster ID when working with RDS Aurora.

Once those parameters are filled and verified, the Root template loads and triggers the next one, the Setup template.

In order to run a successful Imperva Snapshot scan there are a few requirements.
The Setup template’s main goal is to verify an account meets those prerequisites.
The template creates a dedicated Setup Lambda to check the following:

1. RDS ID:
   Verify such ID exists in the stack’s region.
2. Current number of VPCs in use:
   As the tool requires a dedicated VPC, we need to make sure that the user’s AWS region doesn’t reach the VPC quota limitation.
3. Snapshot availability:
   In order to run a scan the database must have an available snapshot. Imperva Snapshot accesses the latest DB’s snapshot

If there is not an available snapshot for the selected DB, simply click “Take snapshot” option from the desired Relational Database Service (RDS) instance and Actions menu (Figure 2 below)
Please note that this adds an additional 20-30 minutes to the process, as Imperva Snapshot can only start the scan after a snapshot is available.

Figure 2

Once all prerequisites are met the last template in the process is activated. The Installer.
This final template creates the stack which builds the isolated environment, lambdas and all configurations:

1. The Sandboxer Lambda
2. AWS IAM roles: Create and attach all roles and permissions to the Lambda functions created in the process: Sandboxer, Scanner and Reported
3. Attach the AWS IAM roles to Lambda functions accordingly
4. Creates a temporary VPC, for hosting the restored DB

Lambdas

To fully understand the activities within the environment we need to know the capabilities and purpose of each lambda function.
The core lambda is the Sandboxer that acts as a DevSecOps expert. It particularly manages and creates the following:

1. All the networking resources required
2. Restoring the selected database into the isolated VPC
3. Scanner and Reporter Lambdas
4. Triggering the Scanner
5. Monitor and track the entire scan
6. Deleting all the created resources upon completion or an error

Networking resources and isolated VPC

Making sure data will not be exfiltrated is critical. Accordingly, the restored RDS instance is accessible only to the created Lambdas; Scanner and Reporter.

The network assets associated with the VPC are created in a way there is no internet access from and to the VPC. Ideally blocking any database connection from outside the isolated VPC.

Below are the network configurations created by the Sandboxer which secure the VPC on its isolated environment.

1. Two subnets: AWS requires the creation of two subnets inside the VPC where we restore the RDS Snapshot to ensure redundancy. The VPC’s IP range is set to 10.0.0.0/16 and the subnets to 10.0.1.0/24 and 10.0.2.0/24.
2. Security Group (SG) and Routing Table (RT): The Sandboxer doesn’t create any SG or RT. Instead, it uses the default SG and RT created on VPC creation. The default SG and RT are configured by default to allow access and forward network from within the VPC created.
   This default configuration and the fact that we do not create any AWS Internet Gateway make the VPC isolated from the internet. No other function outside the VPC can connect to the restored DB from a networking standpoint. (In addition, the restored DB is set with a random password, generated per deployment)
3. VPC endpoints: As the isolated VPC doesn’t have access to the internet, we need a way to make the Scanner Lambda call AWS API (save state in a temporary S3 Bucket, call RDS APIs to scan configurations and so on). To do that, we use AWS VPC endpoints which enable VPCs without internet access to use AWS Services without exiting the AWS networking backbone. All the API calls pass through AWS internal core networking appliances, thus making sure the data doesn’t go through the public internet.

Restoring the selected database

Once the isolated VPC is ready, the Sandboxer uses AWS RDS API to restore into it the latest RDS Snapshot of the selected RDS Instance or Aurora Cluster.

The restoration phase is the longest phase of the process and usually takes 20-40 minutes for all the resources to be up and running.

During that time, the Sandboxer creates two additional functions the Scanner and the Reporter (covered later on) and places them inside the isolated VPC .

The following diagram describes the chronological scan flow. Starting by activating the Sandbox lambda; restoring the DB instance to an isolated VPC and then creating the Scanner and Reporter functions to run the security assessment and generate a report.

Within that process, once the Scanner lambda is created by Sandboxer, it is still being monitored by it through the entire process.

This monitoring process is done mainly by reading the current state of the Scanner Lambda. This lambda constantly updates and writes into a temporary S3 bucket.

The Sandboxer reads the status given by the Scanner and decides whether it can proceed, an error occurred, or the scan has completed.

The Scanner and Reporter

This Lambda manages the entire scanning process as soon as it detects that the restored RDS is ready to open a JDBC connection. It resets the RDS Instance Master Password by a randomly generated string, generated on each new run. That’s the reasoning there is no requirement for the original database credentials.

The scanner now runs a set of vulnerability and misconfiguration tests by using both AWS RDS API, mainly by database queries with a direct database connection. It reads a subset of the data from the restored database and classifies personal and confidential information: emails, credit cards, addresses, names, and passwords. This classification is crucial in order to understand the context and the risk of the misconfigurations and vulnerabilities.

To finalize the scanning process, the Scanner triggers the Reporter lambda which is in charge of creating the actual PDF report. The Reporter fetches the raw information from the temporary bucket, creates the PDF report and finally sends it to an Imperva AWS account to be sent via email to the email address specified in the registration phase.

Delete all resources

Upon a successful or a failed scan, the Sandboxer starts with the deletion process. It instructs the CF to delete itself. This is done by calling a CF API which tells CF to initiate the deletion phase of the Root CF stack. When AWS CF gets this request (which is identical to deleting the Root Stack manually from AWS Console), it starts to delete the 3 CF Stacks from the latest one to the first.

First, it starts deleting the Installer Stack and all the resources created by it, then the Setup Stack with all resources created by it and finally the Root template. The deletion itself might take up to an hour as some resources require more time to be deleted. The report itself however, does not depend on the deletion phase and will arrive in your mailbox shortly after the deleting phase starts.

AWS IAM roles

A major concern while running external lambdas in a cloud environment are their accessibility and role permissions the functions might have.

Now that we have covered the entire flow, let’s scrutinize the AWS IAM role configurations and understand what precautions the tool uses to minimize and restrict the roles permissions. The CF templates files mentioned above contain all the instructions including the IAM roles required to run the tool. Samples of the AWS roles installed can be found in Imperva Snapshot CLI Github project. Specifically, we restrict each AWS role by specifying the precise ARN name of the resource to create/delete or by using built-in CF conditions. This way, we ensure that the tool does not have over-permission to create more than required. Most importantly, roles can’t delete resources that weren’t created during the process.

For example, the “ec2:DeleteVpc” permission only allows to delete the isolated VPC Imperva Snapshot created, but cannot delete any other VPC.

“Statement:

– Effect: Allow
Action:

– “ec2:DeleteVpc”

Resource:

– !Sub

– “arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:vpc/${vpcId}”

– vpcId: !Ref SandboxVpc”

Imperva Snapshot is restricted to delete only components that it originally created during the process. Accordingly all functions and roles created in the process are highly restricted and guarantee a hygiene deployment in the cloud environment. Lastly, although there is no need for Administrator privileges to run the tool (as can be seen from the Roles Samples in the Github project), in some cases it might be challenging to get the roles needed from the InfoSec team. Specifically for that, Imperva Snapshot can be installed with a very small set of permissions. Click here to see how to run Imperva Snapshot with minimum credentials.

Wrap up and next steps

Well done. Imperva Snapshot is ready to be used. By now you should have a full understanding of the entire tool flow and feel confident running it in your environment. If you still have any questions or hesitation, feel free to reach out to the Imperva Snapshot team. We also recommend you read Imperva Snapshot CLI. You can learn about our CLI interface, automate a scheduled scan and make sure you always have visibility to your database’s security posture. Make Imperva Snapshot a trusted advisor for securing your AWS cloud databases.