DEVWKS-2240
Using SecureX orchestration for Automating Public Cloud Incident Response and Remediation
Lab Environment: https://expo.ciscodcloud.com/61f3vnmo3a3mzoh0gzq0wfeb6
Right-click and open in a new INCOGNITO MODE/PRIVATE WINDOW
IaaS API Documentation
AWS: https://docs.aws.amazon.com
GCP: https://cloud.google.com/compute/docs/reference/rest/v1
Azure: https://docs.microsoft.com/en-us/rest/api/azure
SHARED ENVIRONMENT ALERT
Make sure you uniquely name your workflow when creating!
API Reference: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html
Create a new activity that will provide the details of an EC2 instance, following the example presented.
- Create a New Workflow
- From the activities tab, drag the AWS Service --> Generic AWS API Request actiivity to the canvas.
- Name the activity Query EC2 Instance in the activity Display Name and Override the workflow target with: AWS_Target in the activity properties.
- Specify the URL near the bottom of the activity properties with:
https://ec2.us-east-1.amazonaws.com/?Action=DescribeInstances&Filter.1.Name=private-ip-address&Filter.1.Value=YOUR_POD_IP&Version=2016-11-15
Replacing "YOUR_POD_IP" with the IP address associated with your pod in the table below and set the API Method to GET.
Pod 1: 172.31.22.192 | Pod 11: 172.31.4.177 |
Pod 2: 172.31.19.34 | Pod 12: 172.31.9.192 |
Pod 3: 172.31.28.79 | Pod 13: 172.31.2.170 |
Pod 4: 172.31.7.175 | Pod 14: 172.31.6.32 |
Pod 5: 172.31.11.48 | Pod 15: 172.31.11.139 |
Pod 6: 172.31.14.141 | Pod 16: 172.31.5.13 |
Pod 7: 172.31.9.110 | Pod 17: 172.31.2.231 |
Pod 8: 172.31.5.98 | Pod 18: 172.31.4.105 |
Pod 9: 172.31.6.146 | Pod 19: 172.31.0.150 |
Pod 10: 172.31.13.208 | Pod 20: 172.31.7.250 |
- Click on the "Start" element in the workflow and customize the workflow "Display Name" to Pod # - AWS Workflow
- Validate and Run this workflow near the top of the canvas.
After running this activity, you should see the details of the instance that you queried in the output body.
Click Modify to return to the Workflow Editor
Next we will extract some data from the returned XML Response using an XPATH Activity.
- From the Core activites list grab and drag the XPATH Query and drag it to the canvas.
- Rename the activity Extract EC2 Details
- Scroll down on the properties window and find where you will specify Source XML to Query. Click the puzzle piece in the upper-right corner to select a source.
- Choose Activities --> Query EC2 Instance --> Body and choose Save
-
Click the "+" next to XPATH Query. Fill in the following details:
Property Name: Instance ID
XPath Query: //reservationSet/item/instancesSet/item/instanceId
Property Type: StringClick the "+" again to add another variable.
Property Name: Security Group
XPath Query: //reservationSet/item/instancesSet/item/groupSet/item/groupName
Property Type: String
The properties should look like the graphic below.
Next we'll add a simple conditional block to check if one of our variables matches a specific value.
- Click on the Logic tab of the navigation, expand Logic and drag the Condition Block to the canvas.
- Click on each of larger block and rename it Is Instance Isolated? and the smaller block on the left and name it Yes.
- Click on the Activities tab of the navigation, locate the Generic AWS API Request from the AWS Service section and drag it to the canvas into the Yes block.
- Change the activity name to Tag EC2 Instance.
- In the properties of the Tag EC2 Instance, scroll down and supply the following details:
Override Workflow Target to AWS_Target.
Set the AWS API Request URL to the one below and the API Method to GET
https://ec2.amazonaws.com/?Action=CreateTags&ResourceId.1=INSTANCE_ID&Tag.1.Key=Isolated&Tag.1.Value=&Version=2016-11-15
- Highlight the INSTANCE_ID in the URL string and click the puzzle piece in the upper-right of that field.
Choose Activities --> Extract EC2 Details --> XPath Queries --> Instance ID
The resulting URL should show the variable name set as one of the parameters.
- Since we only have one condition, you can delete the other conditional branch. By clicking on it, choosing the three dots, and choosing Delete.
- Click into the Yes conditional branch to set the test condition. Click on the puzzle piece in the Left Operand field.
Choose Activities --> Extract EC2 Details --> XPath Queries --> Security Group
Then specify Isolate_SG as the Right Operand. When completed, it should look like the graphic below.
- Click Validate again at the top of the window and run the workflow again.
When the workflow runs this time you'll be able to see the output of the second activity that parses the XML response from the first activity and extracts the name of the Instance and assigend Security Group for your EC2 instance. You'll notice that the conditional block doesn't trigger since the condition we specified doesn't match.
We will revisit this created workflow later after we initiate our completed incident response workflow.
SHARED ENVIRONMENT ALERT
Make sure you uniquely name your workflow after importing!
- Click back to Workflows and choose the Import button.
- Choose, Import from Git --> DEVWKS-2240 for Git Repository, sxo-aws-ir for File Name, Updated Keys for Git Version, and finally Import as a New Workflow and click Import.
- After importing, it will show up as Copy(1)-AWS Incident Response. Open this newly created workflow.
- Name your workflow Pod X - AWS Incident Response replacing the pod number with yours.
- Replace the variable for 'observable_value' with the IP address for your pod from the table below.
Pod 1: 172.31.22.192 | Pod 11: 172.31.4.177 |
Pod 2: 172.31.19.34 | Pod 12: 172.31.9.192 |
Pod 3: 172.31.28.79 | Pod 13: 172.31.2.170 |
Pod 4: 172.31.7.175 | Pod 14: 172.31.6.32 |
Pod 5: 172.31.11.48 | Pod 15: 172.31.11.139 |
Pod 6: 172.31.14.141 | Pod 16: 172.31.5.13 |
Pod 7: 172.31.9.110 | Pod 17: 172.31.2.231 |
Pod 8: 172.31.5.98 | Pod 18: 172.31.4.105 |
Pod 9: 172.31.6.146 | Pod 19: 172.31.0.150 |
Pod 10: 172.31.13.208 | Pod 20: 172.31.7.250 |
Replace the value for your pod and click save.
Note the activites in this workflow that automate many of the steps outlined in the AWS EC2 Incident Response Guide.
- Enables Termination Protection on the instance
- Sets a restricted Security Group limiting access
- Removes it from any Auto Scaling Groups
- Removes it from any Elastic Load Balancers
- Snapshots connected Elastic Block Storage devices
- Tags the instance with IR details
- Run your imported workflow.
-
Return to your previously created workflow Pod X - AWS Workflow that pulls instance details and run the workflow again.
-
Click on the Extract EC2 Details activty and note that after running the incident response workflow, the Security Group has been changed to move the impacted host to an isolated security group (Isolate_SG) and our condition now matches and the additional tagging activity has been run to identify the host as isolated.
-
Click Dashboard at the top of the SecureX Window to exit out of the Orchestration tool.
-
Expand the Ribbon by clicking the SecureX icon at the bottom-right of the screen to see created casebooks and incidents for this environment.
- Click on the casebooks icon on the top of the window and find the DEVWKS-2240 Casebook Casebook created "By Others" by searching for 'DEVWKS' in the casebook pane.
- Click Investigate in Threat Response located on the right-hand side of the Casebook drawer or on the upper-right of the ribbon.
This will open up a new browser window that contains the results of our investigation into one domain and the AWS internal IP addresses from our lab.
Once the enrichment of the observables is complete, you should see your IP address denoted as a 'target' in the resulting graph.
- Use the drop-down to show the SecureX orchestration response actions that can be ran against this host, including the one you imported and uniquely named.
THANK YOU for attending this DevNet Workshop and learning about SecureX orchestration. I'll be putting some links and code into the Webex space associated with this session following this session! Enjoy your time at Cisco Live!