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.

securex-with-meraki

Cisco SecureX Workflows with Meraki MX Firewall

Blocking a destination in MX L3 Security Rules from SecureX Threat Response

The time required to investigate source of threat & then orchestrate policies in the network to block that threat throughout a large Enterprise Network is critical for organizational security. This code leverages the Meraki API's to orchestrate a deny rule in MX Security policies, which can be trigger directly from Threat Response

{{Configuration Steps}

  1. Logged into https://securex.cisco.com/ and navigatte to SecureX orchestration
  2. Define targets by navigating to Targets on the left hand side as show below:

1

  1. Add new target with below settings:
  • Display name: Meraki
  • Account Keys: No Account Keys - True
  • HTTP- Protocol: HTTPS, Host/IP Address: api.meraki.com, port 443, PATH:/api

12

13

  1. Now goto "workflows", choose "atomic" and select import as shown below:

2

  1. Click on import and then paste the code which you have just copied

3

  1. Now Atomic Action has been imported, open the newly imported Atomic Action

4

  1. Now you have to update the two variables " Meraki API Key" & " Network ID". Network ID will be the ID of your Meraki Network. Also you need to update the Target which you have created earlier

5

11

  1. At this stage, you are ready to Run this workflow directly from same window or you can execute this from SecureX Threat Response. Open the threat response page, start any investigation and then from the observable graph, you can righ click on any observable ( IP or Domain ) and select the workflow which you have just imported "Blocking URL/IP in Meraki MX Firewall

6

7

  1. Now go back to orchestration page where atomic action was already open, you can click on "view Runs" to validate whether your workflow was sucessfully executed

8

9

10

You have now seccessfully orchestrate a Layer 3 deny rule while doing threat hunting from SexureX Threat Response

Use Case

Securex Orchestration in Meraki MX L3 Firewall Rules

Cisco SecureX Workflow for blocking an desitnation IP Address in Meraki MX L3 Firewall Security Rules from SecureX Threat Response.

The time required to investigate source of threat & then orchestrate policies in the network to block that threat throughout a large Enterprise Network is critical for organizational security. This code leverages the Meraki API's to orchestrate a deny rule in MX Security policies, which can be trigger directly from Threat Response

Configuration Steps:

  1. Logged into https://securex.cisco.com/ and navigatte to SecureX orchestration
  2. Define targets by navigating to Targets on the left hand side as show below:

1

  1. Add new target with below settings:
  • Display name: Meraki
  • Account Keys: No Account Keys - True
  • HTTP- Protocol: HTTPS, Host/IP Address: api.meraki.com, port 443, PATH:/api

12

13

  1. Now goto "workflows", choose "atomic" and select import as shown below:

2

  1. Click on import and then paste the code which you have copied from this repository and then click import

3

  1. Now Atomic Action has been imported, open the newly imported Atomic Action

4

  1. Now you have to update the two variables " Meraki API Key" & " Network ID". Network ID will be the ID of your Meraki Network. Also you need to update the Target which you have created earlier

5

11

  1. At this stage, you are ready to Run this workflow directly from same window or you can execute this from SecureX Threat Response. Open the threat response page, start any investigation and then from the observable graph, you can righ click on any observable ( IP or Domain ) and select the workflow which you have just imported "Blocking URL/IP in Meraki MX Firewall

6

7

  1. Now go back to orchestration page where atomic action was already open, you can click on "view Runs" to validate whether your workflow was sucessfully executed

8

9

10

You have now seccessfully orchestrate a Layer 3 deny rule while doing threat hunting from SexureX Threat Response

Links to DevNet Learning Labs

SecureX Orchestration

View code on GitHub
  • Owner

  • Contributors

    +1Github contributor
  • Categories

  • Products

    Meraki
  • Programming Languages

  • License

    MIT License

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.