This repository is deprecated; please follow the main search page or use the ‘Related code repos’ widget on the right side of the current page.

Gitter Chat
Travis CI Build Status

AWS VPC Flow Relay

SecureX Relay to identify ingress and egress traffic from an AWS VPC
Intelligence service provider.

CTR Screenshot

The Relay itself is just a simple application written in Python that can be
easily packaged and deployed as an AWS Lambda Function using
Zappa.

Rationale

  1. We need an application that will translate API requests from SecureX Threat Response
    to the third-party integration, and vice versa. This application is provided
    here in the GitHub repository, and we are going to install it in AWS Lambda
    using Zappa.

  2. AWS Lambda allows us to deploy our application without deploying a dedicated
    server or paying for so called "idle" cycles. AWS handles instantiation and
    resource provisioning; all we need to do is define the access rights and upload
    our application.

  3. Zappa is a helper tool that will package our application and publish it to
    AWS as a Lambda function. It abstracts a large amount of manual configuration
    and requires only a very simple configuration file, which we have provided and
    will explain how to customize it during this process.

Step 0: AWS Setup

To get started, you have to set up your AWS environment first by carefully
following the instructions from the AWS HOWTO. In addition, the
document also covers how to configure the Zappa Settings
by explaining the relationships between the values there and your AWS setup.

Step 1: Create AWS Policy and User

In order for the relay to function the API credentials in AWS must have appropriate
permissions applied. The following is a sample policy configuration to allow for the
approriate access on all resources for desired operation. This policy could be modified
to restrict access to only a subset of resources as well if desired.

In AWS Create IAM policy with the following JSON and asign it to your API user

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "iam:GenerateCredentialReport",
        "ec2:DescribeInstances",
        "ec2:DeleteTags",
        "ec2:DescribeTags",
        "ec2:CreateTags",
        "logs:DescribeLogStreams",
        "ec2:DescribeSecurityGroups",
        "s3:ListAllMyBuckets",
        "logs:GetLogEvents",
        "iam:ListUsers",
        "apigateway:GET",
        "ec2:ModifyInstanceAttribute",
        "ec2:DescribeSubnets",
        "iam:GetCredentialReport",
        "iam:ListAccessKeys"
      ],
      "Resource": "*"
    }
  ]
}

Step 2: Requirements Installation

First of all, make sure that you already have Python 3 installed by typing

python3 --version

in your command-line shell.

The application has been implemented and tested using Python 3.7. You may try
to use any higher versions if you wish as they should be backward-compatible.

After that, you have to create a "virtual environment" to isolate the
application-specific requirements from the libraries globally installed to your
system. Here are the steps to follow:

  1. Create a virtual environment named venv:

    python3 -m venv venv

  2. Activate the virtual environment:

    • Linux/Mac: source venv/bin/activate
    • Windows: venv\Scripts\activate.bat
  3. Upgrade PIP (optional):

    pip install --upgrade pip

NOTE. The virtual environment has to be created only once, you just have
to make sure to activate it each time you are working on or playing with the
application (modern IDEs can automatically do that for you). You can deactivate
a previously activated virtual environment by simply typing deactivate in
your command-line shell.

Finally, install the libraries required for the application to function from
the requirements.txt file:

pip install --upgrade --requirement requirements.txt

Step 3: Application Deployment

Scripted Deployment

The process for deploying the python module to AWS Lambda and creating the integration module object
in SecureX leverages the included deploy_relay.py script.

The required arguments and flags are below

  • Operation: deploy, update, or remove
  • Region: -r Example "us-east-1"
  • Project Name: -p Example "AWS_Test_Relay"
  • SecureX Region: -x must be US, EU, or APJC
  • SecureX API Client ID: -i
  • SecureX API Client Secret: -s
  • Lambda Memory: -m Optional im MB, defaults to 4096
  • Lambda Timeout: -t Optional in seconds, defaults to 90 seconds

Deploy Example

deploy_relay.py deploy -r us-east-1 -p AWS_Test_Relay -x US -i client_****** -s secret_****** -m 1024 -t 60

Expected Output
Encryption Secret Generated
Obtained SecureX Auth Token
Zappa configuration file created

100%|██████████| 637k/637k [00:00<00:00, 15.5MB/s] 100%|██████████| 31.1k/31.1k [00:00<00:00, 5.12MB/s] 100%|██████████| 12.3M/12.3M [00:09<00:00, 1.29MB/s] 100%|██████████| 1.68k/1.68k [00:00<00:00, 8.41kB/s] 75%|███████▌ | 3/4 [00:13<00:04, 4.34s/res] App Deploy Complete SecureX Integration Module Created

Process finished with exit code 0

Configure New Integration

From SecureX Available Integration Modules Select AWS

ADD_AWS

Add Configuration Details and Click Save

Configure_AWS

SecureX Will Validate with Health Check, and You are Good To Go

verify_AWS

Use Case

Integrating SecureX with AWS to reduce dwell time and increase efficiency

Cisco SecureX AWS VPC Flow Relay: please read this SecureX and Public Cloud: Amazon Web Services blog post.

Business Case

SecureX is a cloud-native, built-in platform that connects our Cisco Secure portfolio and your infrastructure. It allows you to radically reduce dwell time and human-powered tasks. For SecureX, the Cisco Threat Intelligence Model (CTIM) is a Wikipedia, an abstract model that organizes data and defines data relationships. CTIM is of utmost importance for SecureX because it provides a common representation of threat information, regardless of whether its source is Cisco or a third party. In the following sections, we will dive deeper into CTIM and its components.

Serverless relay modules are the components that enable SecureX integrations with third-party security solutions. They are serverless Python Flask applications that are intended to be deployed into AWS as Lambda applications. Because they are Flask applications, they could basically be deployed into any Python-capable host. The important feature that serverless relay modules can do, is that they can translate back and forth between CTIM, and whatever data model the third-part solution is using.

This entire solution is built for SecureX and AWS:

  • Dashboard tiles in SecureX to view high-level statistics and pivot straight into AWS.
  • Ability to query VPC flow logs from SecureX threat response (both internal and public IP address (NAT)).
  • Ability to isolate EC2 instance from SecureX threat response response API and drop down menu (both internal and public IP address (NAT)).

Please see the serverless relay module installation information here.

White Paper

Please continue your reading in this From Complex to Cohesive white paper.

Currently there is no DevNet sandbox yet, however you can find all options to try out the SecureX sandbox! Also, anyone can create a SecureX account for free.

List of SecureX Learning Labs

Solutions on Ecosystem Exchange

Please check out related solutions on DevNet Ecosystem Exchange.

View code on GitHub
  • Owner

  • Contributors

    +2Github contributors
  • Categories

  • Programming Languages

    Python
  • License

    Other

Code Exchange Community

Get help, share code, and collaborate with other developers in the Code Exchange community.View Community
Disclaimer:
Cisco provides Code Exchange for convenience and informational purposes only, with no support of any kind. This page contains information and links from third-party websites that are governed by their own separate terms. Reference to a project or contributor on this page does not imply any affiliation with or endorsement by Cisco.