Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(SecurityHub): manual deployment guide #257

Merged
merged 7 commits into from
Oct 30, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions .github/wordlist.txt
Original file line number Diff line number Diff line change
Expand Up @@ -407,3 +407,10 @@ IOM
agentless
nslookup
centric
redrive
SSL
runtimes
chmod
githubusercontent
tmp
wget
20 changes: 15 additions & 5 deletions Security-Hub/README.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,11 @@
# AWS Security Hub Integration

## :warning: Transition to a more Simplified AWS Security Hub Integration :warning:

We would like to introduce the [Falcon Integration Gateway](https://github.com/CrowdStrike/falcon-integration-gateway) application as a simplified solution for AWS Security Hub integration. Unlike this project which requires creating multiple AWS resources, the Falcon Integration Gateway streamlines this process, making it easier and more straightforward. We invite you to explore and transition to the Falcon Integration Gateway for your AWS Security Hub integration needs. Documentation and setup instructions can be found [here](https://github.com/CrowdStrike/falcon-integration-gateway/blob/main/docs/aws/manual/README.md).

---

This solution publishes detections identified by CrowdStrike Falcon for instances
residing within Amazon Web Services (AWS) to AWS Security Hub.

Expand All @@ -20,7 +27,7 @@ There are several benefits to this architecture:
+ Easily scalable depending upon need
+ Can be deployed quickly

### Architecture
### Architecture
This solution consists of three primary components
+ Python application running within AWS for ingesting detections from the CrowdStrike API
> This application is sometimes referred to as _fig_, and may contain references to this which reflects the legacy solution name.
Expand All @@ -45,7 +52,7 @@ This solution consists of three primary components
+ [Installing via Terraform](terraform)
+ [Installing manually](manual-install.md)

The service application is intended to be deployed as a service on a Linux instance.
The service application is intended to be deployed as a service on a Linux instance.
The solution can be run stand-alone, but is not recommended for production deployments.

### Required CrowdStrike API access
Expand All @@ -65,15 +72,15 @@ There are six required parameters that must be defined in order for the Falcon I
+ `app_id` - A unique string value that describes the name of the application you are connecting to Falcon. Most string values are supported.
+ `severity_threshold` - An integer representing the threshold for detections you want published to AWS Security Hub.
+ `sqs_queue_name` - Name of the SQS queue to publish detections to. This must reside in the region specified below.
+ `region` - The region we will be publishing to in AWS Security Hub. This will need to match the region the SQS queue resides in. For deployments leveraging SSM, this parameter does not need to be specified.
+ `region` - The region we will be publishing to in AWS Security Hub. This will need to match the region the SQS queue resides in. For deployments leveraging SSM, this parameter does not need to be specified.

The seventh parameter is not required and defaults to __True__.
+ `confirm_provider` [__NOT REQUIRED__] - Should the service application only submit detections that have AWS listed as the service provider?

> Even though detections are published to AWS Security Hub within a single AWS region, they represent detections for instances found within _all_ AWS regions.

#### Using AWS Systems Manager _Parameter Store_
By default, service application configuration parameters are stored within AWS Systems Manager _Parameter Store_ but can be overridden by using a config.json file.
By default, service application configuration parameters are stored within AWS Systems Manager _Parameter Store_ but can be overridden by using a config.json file.

> SSM Parameter Store parameters are _case-sensitive_ and must reside within the same region as the FIG instance you are configuring. Please note the naming convention of the parameters displayed below, as the variable names must match exactly. (All upper case, spaces are underscores, precursed with "**FIG_**").

Expand Down Expand Up @@ -115,6 +122,9 @@ $ sudo systemctl status fig
This should result in a display similar to the following:
![FIG service status](images/fig-service-status-example.png)

> [!NOTE]
> For newer versions of OS's such as Amazon Linux 2023, you may need to restart the `fig` service if it is not started.

### Log files
+ `fig-service.log` - The application service log contains debug information related to the startup of the service and loading of credentials. Review this log for failures related to the starting and stopping of the service application.
+ `{app_id}_{partition_number}.log` - Each stream opened by the application has it's own rotating log that contains details regarding the detections discovered. Review this log to confirm detections are being discovered within the event stream and are properly formatted / meeting severity threshold requirements. This file is named after the value used for the __*app_id*__ parameter and the partition number.
Expand All @@ -125,7 +135,7 @@ Your current position within the event stream is referred to as your _offset_. T
You can read this file to find your position within the event stream. If you wish to reset your positions in the event stream, remove this file.

### Lambda debugging
When your lambda function was created, basic logging was enabled to CloudTrail as a stand-alone log group, named after the name of your lambda function. Successful submissions and regular events are tracked in this log.
When your lambda function was created, basic logging was enabled to CloudTrail as a stand-alone log group, named after the name of your lambda function. Successful submissions and regular events are tracked in this log.

If you wish to increase log verbosity, you may do so by creating the __DEBUG__ environmental variable on your lambda.

Expand Down
Loading