Hi I would like to share a tool that I created as my personal hobby project. This tool can help you check about NetFlow support and can provide you with the Configuration to enable NetFlow on your Network Platforms for doing Security Analytics using Stealthwatch. The configurations provided by the tool are "crowd-sourced", that is they are created based on the inputs shared by different users and the database keeps on growing. NOTE that the inputs are not officially endorsed or validated by the tool's author or by any Vendor (including Cisco). DO REMEMBER to check and validate the output from this tool with the Product's Configuration Guide from Vendor's Official Website. Here is the link to the tool - https://configurenetflow.info/ Do remember to share your feedback. Thanks   ... View more

This page provides an overview for different forms of APIs available in all the Cisco Security Products and pointers to their documentation & examples. It is an aggregation of all the Cisco Security Products' API related resources at one place.   NOTE: You may have to scroll to right to view the complete table in some browsers like Google Chrome.   Table of Contents Firepower Management Center (FMC) - REST API Firepower Management Center (FMC) - Host Input API Firepower Management Center (FMC) - eStreamer API Firepower Management Center (FMC) - Remediation API Firepower Device Manager (FDM) / Firepower Threat Defense (FTD) On-Box - REST API ASA - REST API Firepower Chassis Management (FXOS) on 4100 / 9300 - REST API Stealthwatch Enterprise - REST API Stealthwatch Enterprise - SOAP API / Web Services API Stealthwatch Enterprise - Data Exporter (DEX) Stealthwatch Cloud - REST API AMP for Endpoints Public Cloud - REST API AMP for Endpoints Public Cloud - Events Stream AMP for Endpoints Private Cloud - REST API Threat Grid Cloud - REST API Threat Grid Cloud - Feeds Threat Grid Appliance - REST API Umbrella - REST API Cisco Threat Response (CTR) - REST API Cognitive Threat Analytics (CTA) - STIX/TAXII Identity Services Engine - Monitoring REST API Identity Services Engine - External REST (ERS) API Web Security Appliance (WSA) Email Security Appliance (ESA) Security Management Appliance (SMA) Cisco Cloudlock - REST API   Firepower Management Center (FMC) - 1 of 4 - REST API API Type / Purpose Most commonly used REST API for FMC REST API can be used to do most common tasks on your FMC, NGFW and NGIPS. This includes provisioning, configuration, deployment, monitoring and most other day-to-day activities API documentation API Explorer (RECOMMENDED) - https://<FMC-IP>/api/api-explorer/ FMC REST API offline documentation on CCO - https://www.cisco.com/c/en/us/support/security/defense-center/products-programming-reference-guides-list.html Features available in API wrt GUI / CLI As of FMC version 6.2.3, you can do the following: Config Deployment Device Register / Unregister Network/Service Objects/Groups Configuration Configuration of Interfaces, Access Policies, NAT Policies, Static Routes High Availability Configuration CTID Configuration Viewing File, IPS Policies and other Objects/Groups   Note: Check the API Config guide / API explorer for the complete list. Things listed here are summarized due to space constraints. Comments / Notes Read more here - https://blogs.cisco.com/security/how-to-get-started-on-programming-firepower-using-fmc-apis   API Explorer is truly amazing with features like inline documentation, it lets you play with live data in your FMC and it lets you export the API into Perl / Python code ready for use into your scripts   Limited to 120 queries per minute. This may be a limiting factor for large deployments. Sample Codes https://communities.cisco.com/community/technology/security/ngfw-firewalls/blog/2018/03/29/time-based-acls-in-firepower-threat-defense-ftd-v62   In case if someone wants to use an SDK instead of direct native REST API calls, here are some SDKs that I have observed. https://github.com/chetanph/cisco-security-rest-api https://github.com/QuiLoxx/ATS-APIs/tree/master/firepower/neipatel_day0-setup https://pypi.python.org/pypi/fmc-rest-client https://github.com/daxm/fmcapi Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU 2018/07/05 by ndard Return to top   Firepower Management Center (FMC) - 2 of 4 - Host Input API API Type / Purpose Host Input API These are special APIs for importing data from other sources on your network to augment the monitored host information. For example you can import vulnerability information about hosts in your network from a vulnerability scanner like Nessus, into your FMC. This will help FMC provide better signature tuning suggestions. These are powerful legacy APIs available from Sourcefire days.   API documentation FMC Host Input API offline documentation on CCO - https://www.cisco.com/c/en/us/support/security/defense-center/products-programming-reference-guides-list.html Features available in API wrt GUI / CLI This function is available only using API Comments / Notes This is powerful API but not many use it due to lack of awareness Sample Codes https://github.com/QuiLoxx/ATS-APIs/tree/master/firepower/neipatel_securityCenter-HostInput/v1 Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU 2018/07/05 by ndard Return to top   Firepower Management Center (FMC) - 3 of 4 - eStreamer API API Type / Purpose eStreamer API Cisco Event Streamer (aka eStreamer) lets you export event information from FMC into any third party application like SIEM. This is a data-stream instead of a true API.   API documentation FMC eStreamer offline documentation on CCO - https://www.cisco.com/c/en/us/support/security/defense-center/products-programming-reference-guides-list.html Features available in API wrt GUI / CLI This is the best and the recommended way to export events information from FMC Comments / Notes Most common estreamer client is the eNcore for Splunk   A client for Arcsight is also under development. Sample Codes https://splunkbase.splunk.com/app/3662/ Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU 2018/07/05 by ndard Return to top   Firepower Management Center (FMC) - 4 of 4 - Remediation API API Type / Purpose Remediation API   This is a framework that lets you create custom remediation / mitigation actions in FMC, which can be automatically launched when conditions on your network violate the associated correlation policy. API documentation FMC Remediation API offline documentation on CCO - https://www.cisco.com/c/en/us/support/security/defense-center/products-programming-reference-guides-list.html Features available in API wrt GUI / CLI This function is available only using API Comments / Notes This is powerful framework but not many use it due to lack of awareness Sample Codes https://github.com/QuiLoxx/ATS-APIs/tree/master/amp4e/jsanbowe_AMP-RTC Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU 2018/07/05 by ndard Return to top   Firepower Device Manager (FDM) / Firepower Threat Defense (FTD) On-Box - REST API API Type / Purpose REST API can be used to do most common tasks directly on your NGFW starting FTD version 6.2.3. This includes provisioning, configuration, monitoring and most other day-to-day activities API documentation API Explorer (RECOMMENDED) - https://<FTD-IP>/api-explorer/ FTD REST API offline documentation on CCO - https://www.cisco.com/c/en/us/td/docs/security/firepower/ftd-api/guide/ftd-rest-api.html Features available in API wrt GUI / CLI As of FDM / FTD current version 6.2.3, most of the features are available API, except for a couple of them namely SmartCLI and some VPN stuff. Note that this includes only the features that are available directly in FTD; not the ones that are available through FMC. In the FDM / FTD upcoming version 6.3, 100% of the features should be available in API, that can be configured through FDM On-Box. Comments / Notes API Explorer is truly amazing with features like inline documentation, it lets you play with live data in your FTD NGFW and it lets you export the API into Perl / Python code ready for use into your scripts Sample Codes https://learninglabs.cisco.com:8867/lab/fdm-api-101/step/1 Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU 2018/05/16 by divyanai Return to top   ASA - REST API API Type / Purpose REST API can be used to all the tasks on your ASA, which usually includes provisioning, configuration, deployment, monitoring and most other day-to-day activities API documentation API Explorer (RECOMMENDED) - https://<ASA-IP>/api/doc/ ASA REST API overview on CCO - https://www.cisco.com/c/en/us/td/docs/security/asa/api/qsg-asa-api.html Features available in API wrt GUI / CLI 100% of CLI features are available via API Comments / Notes Read more here - https://www.networkworld.com/article/2921386/security0/digging-deeper-into-the-cisco-asa-firewall-rest-api.html  and here - https://maroskukan.wordpress.com/2015/02/11/cisco-asav-firewall-rest-api/   Note that ASA REST API are NOT supported on Firepower 2100 platform .   API Explorer is truly amazing with features like inline documentation, it lets you play with live data in your ASA and it lets you export the API into Perl / Python / Java code ready for use into your scripts   ASA REST APIs are extensively used in NFV and Cloud based deployments like in AWS, Azure Sample Codes https://maroskukan.wordpress.com/2015/02/11/cisco-asav-firewall-rest-api/ Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/17 by hibeumer Return to top   Firepower Chassis Management (FXOS) on 4100 / 9300 - REST API API Type / Purpose REST API for includes both Platform and Services APIs provided by FX-OS. They can be used for both Configuration and Monitoring. API documentation FX-OS API offline documentation on Devnet - https://developer.cisco.com/site/ssp/firepower/ Features available in API wrt GUI / CLI 100% of GUI features are available via API Comments / Notes   Sample Codes   Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU 2018/07/05 by ndard Return to top   Stealthwatch Enterprise - 1 of 3 - REST API API Type / Purpose REST API As of current latest version 6.10.2, the REST API provide Reporting functions only. API documentation Online documentation within the product:- General - https://<SMC-IP>/api-docs Reporting API v1 - https://<SMC-IP>/sw-reporting/v1/docs Reporting API v2 - https://<SMC-IP>/sw-reporting/v2/docs Configuration Management API - https://<SMC-IP>/smc-configuration/rest/v1/docs User Management API - https://<SMC-IP>/smc-users/v1/docs SWE REST API offline documentation on CCO - https://www.cisco.com/web/fw/stealthwatch/Online-Help/Content/Online-Help/enterprise-rest-api.htm Features available in API wrt GUI / CLI As of current latest version 7.0, the REST API provide the following Reporting functions only: Host Reports Flow Reports Interface Reports Security Events and Alarms Top Reports Enhanced Flow Search Query Interfaces Query Devices/Exporters Query Security Events Host Groups Management (Host Groups are called as Tags in the SW API world) User Management Core Policy Management Custom Security Events Management Relationship Policy Management Comments / Notes There is a lot of development going on in the REST APIs. The upcoming versions of the product will have more features, especially configuration features, available through the REST API Sample Codes https://github.com/QuiLoxx/ATS-APIs/tree/master/stealthwatch Content Last Updated Details 2018/12/04 by ankanani - added info about API enhancements in SW 7.0 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/23 by shishanb Return to top   Stealthwatch Enterprise - 2 of 3 - SOAP API / Web Services API API Type / Purpose SOAP API / Web Services API The SOAP API are provide most of the configuration functions and some reporting functions. These are legacy APIs available from Lancope days. API documentation SWE SOAP API offline documentation on CCO - https://www.cisco.com/c/dam/en/us/td/docs/security/stealthwatch/api/SW_6_10_0_SMC_Web_Svs_Prog_DV_1_4.pdf Features available in API wrt GUI / CLI As of current latest version 6.10.2, the SOAP API provide the following functions: Host and Host Group Reports Host Group Configuration Flow Reports Security Events and Alarms Comments / Notes All the old integrations done by AS are done using these API. However no further development will be done on the SOAP API. These will be superseded by REST API in the future. Sample Codes   Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/23 by shishanb Return to top   Stealthwatch Enterprise - 3 of 3 - DEX API Type / Purpose Data Exporter (DEX) This is a sample client that allows users to take flow data from the Stealthwatch system to be processed and stored by their own application. Usually this is used for exporting bi-flows to SIEM. API documentation SWE DEX documentation on Devnet - https://developer.cisco.com/docs/stealthwatch/#stealthwatch-data-exporter Features available in API wrt GUI / CLI This function is available only DEX. Not applicable to GUI Comments / Notes DEX is a reference implementation client for the Stealthwatch Flow Forwarder service that runs on the flow collector.   Most commonly used for extracting stitched, de-duplicated bi-directional flow records from Stealthwatch into Splunk.   Customers can also purchase the Cisco Stealthwatch Flow Export Service instead of using DEX. Sample Codes   Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/23 by shishanb Return to top   Stealthwatch Cloud - REST API API Type / Purpose REST API to help automate the discovery, validation, and resolution of alerts. API documentation Stealthwatch Cloud API documentation is available for SWC customers inside their web GUI at the URL: https://<customer-account-name>.obsrvbl.com/api/docs/swagger/ Features available in API wrt GUI / CLI The features are limited in the API. Currently the following functions are available via the API: alerts observations blacklists roles session data Comments / Notes   Sample Codes https://gist.github.com/bbayles/1ffd1d3ab60427c3cc148430553ab8f4 Content Last Updated Details 2018/05/23 by ankanani - initial draft Content validated by BU On 2018/05/23 by bbayles Return to top   AMP for Endpoints Public Cloud - 1 of 2 - REST API API Type / Purpose REST API for limited configuration and monitoring activities. API documentation AMP for Endpoints REST API Online documentation - https://api-docs.amp.cisco.com/ Features available in API wrt GUI / CLI The following main features are currently available via the API: View Computers and Groups Create Groups and assign computers View Computer Activities (ie items in Device Trajectory) View Events View Policies View and Modify Certain file lists   The major GUI features that are NOT available currently via the API are: Create/Change Policies Create Blocklists/Blacklist/Whitelists Modify Whitelists View Whitelists Anything with Advanced Custom Detectoins Anything with Endpoint IOCs Initiate an Endpoint Scan Comments / Notes The AMP API is rate limited to 3000 API queries per 1 hour window per API client ID. You can see the status of the rate limit in the response headers as shown in the below example. X-RateLimit-Limit: 3000 (queries limit in period of 1 hr window) X-RateLimit-Reset: 3292 (secs out of an hour or 3600 secs) X-RateLimit-Remaining: 2997 (queries left in period) In case if you want to queries events, then instead of using AMP REST API, use the AMP Event Streamer API mentioned below. Sample Codes https://github.com/search?q=topic%3Aamp-for-endpoints+org%3ACiscoSecurity https://github.com/CiscoSecurity/amp-01-basics https://github.com/CiscoSecurity/amp-03-sha256-to-network-connections https://github.com/CiscoSecurity/amp-04-process-name-to-network-connections https://github.com/QuiLoxx/ATS-APIs/tree/master/amp4e Content Last Updated Details 2018/08/13 by ankanani - added further details about API rate limiting 2018/07/09 by ankanani - added more sample codes 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/31 by miauger Return to top   AMP for Endpoints Public Cloud - 2 of 2 - Event Stream API Type / Purpose AMQP - event stream This is a special publish-subscribe mechanism using AMQP protocol to receive live stream of events from AMP for Endpoints API documentation AMP for Endpoints Event Stream Online documentation and example - https://api-docs.amp.cisco.com/api_resources/EventStream?api_host=api.amp.cisco.com&api_version=v1 Features available in API wrt GUI / CLI This function is available only using API Comments / Notes This is mainly used in SIEM integrations. Event the Threat Centric NAC (TC-NAC) functionality in Cisco ISE uses this feature.   Python has a library called Pika which is commonly used for AMQP. Ruby has a library called Bunny for AMQP.   Pika is the most well known Python library there are quit a few others probably the most well maintained is: Py-AMQP: https://pypi.org/project/amqp/ Haigha: https://pypi.org/project/haigha/   Sample Codes https://github.com/CiscoSecurity/amp-03-event-stream-creator https://github.com/QuiLoxx/ATS-APIs/tree/master/amp4e/neipatel_event-stream https://github.com/JeMunos/AMP_API https://splunkbase.splunk.com/app/3670/ https://github.com/Cisco-AMP/amp4e_splunk_events_input Content Last Updated Details 2018/07/19 by ankanani - added jemunos Github link in sample codes list 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/31 by miauger Return to top   AMP for Endpoints Private Cloud - REST API API Type / Purpose REST API for limited configuration and monitoring activities. API documentation The documentation is available online hosted on the AMP Private Cloud console. Here is the URL - https://<amppvtcloud-console-fqdn>/help/FireAMP_API_v2.3.0.pdf Note that the above URL may differ slightly from version to version. It can be located by navigating to Accounts > API Credentials > View API Documentation menu within your AMP Private Cloud Console Features available in API wrt GUI / CLI All of the same limitations as the AMP Public cloud and then even more because it is often 6 months to a year behind the cloud release   Most of the calls available in the API for current version 2.4.3 of AMP Private Cloud are for Reading Data. Note that there is no Event Stream API available in the current version of AMP Private Cloud. Comments / Notes   Sample Codes This is similar to what is available for the Public Cloud version; along with the limitations mentioned above. Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/31 by miauger Return to top   Threat Grid Cloud - REST API API Type / Purpose TG Cloud REST API can be categorized into 4 different functions: TG Data Query - Fetch Sample Analysis Elements (network streams, process names, etc.) and Results (video.webm, network.pcap) TG Accounts Mgmt - Manage Users Sample Submission Submission Search - Search for Observables API documentation Getting Started with Threat Grid APIs - https://panacea.threatgrid.com/doc/main/api-getting-started.html Threat Grid Main API - https://panacea.threatgrid.com/doc/main/api.html Account Management API - https://panacea.threatgrid.com/doc/main/account-management-api.html Submission Search API - https://panacea.threatgrid.com/doc/main/search.html Bulk Sample Submission Guide - https://panacea.threatgrid.com/doc/main/bulk_sample_submission.html Analysis JSON Specification - PDF - https://panacea.threatgrid.com/doc/main/Analysis_JSON_Spec.pdf Features available in API wrt GUI / CLI Nearly 100% of GUI features are available via API   Some of the things that are not in the API include: Changing the submission runtime Resubmitting samples or artifacts Comments / Notes Read more here - https://blogs.cisco.com/security/demystifying-the-api-using-threat-grid-as-an-example https://blogs.cisco.com/developer/explore-the-threat-intelligence-capabilities-in-the-threat-grid-api   Sample Codes https://github.com/search?q=topic%3Athreat-grid+org%3ACiscoSecurity  https://github.com/CiscoSecurity/tg-01-basics  https://github.com/CiscoSecurity/tg-03-bulk-submit https://github.com/threatgrid/integrations https://learninglabs.cisco.com/lab/Introduction%20to%20the%20Cisco%20Threat%20Grid%20API/step/1 Content Last Updated Details 2018/07/09 by ankanani - added more sample codes 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/31 by miauger Return to top   Threat Grid Cloud - Feeds API Type / Purpose TG Cloud provides content feeds that are pre-generated, curated sets of behavioral indicators that are produced in the Threat Grid Cloud infrastructure from sample analysis results. Feeds are used by organizations and partners for targeted threat intelligence, by focusing on the specific types of threats faced by particular industries. Threat Grid Feeds are refreshed on an hourly or daily basis. They are available by subscription on the Cisco Threat Grid Portal via the Web to fetch from the cloud using a simple REST API call. API documentation The documentation is available here: https://panacea.threatgrid.com/doc/main/feeds.html Features available in API wrt GUI / CLI TG Cloud Feeds are available only via API Comments / Notes These feeds are available only via TG Cloud. They are NOT available via TG Appliance. Sample Codes https://panacea.threatgrid.com/doc/main/feeds.html Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/31 by miauger Return to top   Threat Grid Appliance - REST API API Type / Purpose TG Appliance REST API is same as Threat Grid Cloud REST API. They can be categorized into 4 different functions: TG Data Query - Fetch Sample Analysis Elements (network streams, process names, etc.) and Results (video.webm, network.pcap) TG Accounts Mgmt - Manage Users Sample Submission Submission Search - Search for Observables API documentation Look out for the help section within the Threat Grid Appliance Management Console Features available in API wrt GUI / CLI Nearly 100% of GUI features are available via API   Some of the things that are not in the API include: Changing the submission runtime Resubmitting samples or artifacts Comments / Notes In terms of features, the only difference in Threat Grid Cloud API and Threat Grid Appliance API is that, the Threat Grid Appliance API CANNOT pull the Threat Feeds from the cloud. Sample Codes Look for samples given in the Threat Grid Cloud Section. Same will apply here Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/31 by miauger Return to top   Umbrella - Multiple REST API API Type / Purpose Cisco Umbrella has a number of Application Programming Interfaces (APIs) that allow customers to perform a variety of Umbrella-related functions without needing to use the dashboard or console.   Management API — Manage organizations, networks, roaming clients and more. Reporting API — Enables organizations to run several reports. Console Reporting API — Enables MSPs, MSSPs, and Multi-Org Console administrators to view deployment and security summaries. Network Device Management — Enables organizations to register a hardware device with Umbrella, set policies for that device, etc. Legacy Network Devices API — Enables organizations to integrate legacy hardware network devices with Umbrella. Enforcement API — Enables organizations to manage security-related block lists. Investigate API — An API-based version of the Investigate dashboard.   API documentation Management API — https://docs.umbrella.com/management-api Reporting API — https://docs.umbrella.com/umbrella-api/docs/overview Console Reporting API — https://docs.umbrella.com/umbrella-api/docs/about-the-api-for-the-umbrella-console Network Device Management — https://docs.umbrella.com/umbrella-api/docs/network-device-management Legacy Network Devices API — https://docs.umbrella.com/umbrella-api/docs/overview2 Enforcement API — https://docs.umbrella.com/enforcement-api/reference/ Investigate API — https://docs.umbrella.com/investigate-api/docs   Features available in API wrt GUI / CLI ?? Comments / Notes Please note that not all the APIs documented here are available to all customers. APIs are available only to customers who have purchased the correct package; some APIs required a separate purchase, and some APIs are in limited availability as they undergo testing.  Sample Codes   Content Last Updated Details 2018/12/15 by ankanani - complete new API updates based on inputs from jonnoble 2018/05/11 by ankanani - updated features available list and beta API details as per inputs from jonnoble 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/05/11 by jonnoble Return to top   Cisco Threat Response (CTR) - REST API API Type / Purpose CTR API can be broken down as follows: Inspect – pull observables out of formatted or unformatted text Enrich – search for additional information about those observables Response – take actions on observables (eg add to blocklist) Settings – configure CTR Oath – use credentials and get access tokens Global intel – read global threat intelligence Private intel – read and write user-provided threat intelligence   API documentation https://visibility.amp.cisco.com/#/help/integration   Here is the full list of APIs and their associated scopes: inspect - https://visibility.amp.cisco.com/iroh/iroh-inspect enrich - https://visibility.amp.cisco.com/iroh/iroh-enrich response - https://visibility.amp.cisco.com/iroh/iroh-response settings - https://visibility.amp.cisco.com/iroh/iroh-ui-settings oauth - https://visibility.amp.cisco.com/iroh/oauth2-clients global-intel - https://intel.amp.cisco.com/index.html private-intel - https://private.intel.amp.cisco.com/index.html Features available in API wrt GUI / CLI Nearly 100% of GUI features are available via API. Comments / Notes Further documentation updates forthcoming Sample Codes  n/a Content Last Updated Details 2018/12/13 by bgreenba - initial draft   Content validated by BU On 2018/12/13 by bgreenba Return to top   Cognitive Threat Analytics (CTA) - STIX-TAXII API Type / Purpose STIX-TAXII API to export events and localized security intelligence from CTA into STIX format. This can then be used to integrate CTA with SIEMs. API documentation CTA STIX/TAXII Service documentation - https://www.cisco.com/c/en/us/td/docs/security/web_security/scancenter/administrator/guide/b_ScanCenter_Administrator_Guide/b_ScanCenter_Administrator_Guide_chapter_0100011.html Features available in API wrt GUI / CLI Currently, one important piece of information NOT available in STIX from CTA, is the ETA information. Comments / Notes Note that you can query CTA via this mechanism only ONCE in 10 minutes.   Either you can write your own code to fetch and parse STIX data via TAXII from CTA, or you can use the TAXII Log adapter provided by CTA.   TAXII log adapter is a java client that can poll data from CTA, and optionally push it into common SIEM systems like Splunk via JSON or ArcSight, Q1 Radar, LogPoint, and other vendors via Common Event Format (CEF). https://github.com/CiscoCTA/taxii-log-adapter/wiki   Event the Threat Centric NAC (TC-NAC) functionality in Cisco ISE uses this feature. Sample Codes   Content Last Updated Details 2018/05/07 by ankanani - initial draft Content validated by BU On 2018/06/06 by pcernoho Return to top   Identity Services Engine (ISE) - 1 of 2 - Monitoring REST API API Type / Purpose Monitoring REST API   Used for Session Management - Monitoring REST API calls allow you to locate, monitor, and accumulate important real-time, session-based information stored about individual endpoints in a network. API documentation ISE Monitoring REST API documentation on CCO - https://www.cisco.com/c/en/us/td/docs/security/ise/2-2/api_ref_guide/api_ref_book/ise_api_ref_ch1.html List of ISE API documentation on CCO - https://www.cisco.com/c/en/us/support/security/identity-services-engine/products-command-reference-list.html Features available in API wrt GUI / CLI The following Monitoring REST API categories are supported: Session Management Troubleshooting Change of Authorization (CoA) Comments / Notes Monitoring REST APIs are calls directly to the ISE MnT nodes. Sample Codes Samples are given in the documentation itself Content Last Updated Details 2018/07/31 by ankanani - updated the features available section with more specifics 2018/05/07 by ankanani - initial draft Content validated by BU not validated Return to top   Identity Services Engine (ISE) - 2 of 2 - External REST API API Type / Purpose External REST API (ERS)   These can be used to perform CRUD (Create, Read, Update, Delete) operations on all the Cisco ISE resources. API documentation API Explorer (RECOMMENDED) - https://<ISE-ADMIN-NODE-IP>:9060/ers/sdk ISE ERS API documentation on CCO - https://www.cisco.com/c/en/us/td/docs/security/ise/2-2/api_ref_guide/api_ref_book/ise_api_ref_ers1.html List of ISE API documentation on CCO - https://www.cisco.com/c/en/us/support/security/identity-services-engine/products-command-reference-list.html Features available in API wrt GUI / CLI Limited GUI features are available in the ERS API and a lot are being added over time. Check out the Introduction page on the API documentation link above to get the exact list. Since the list of individual components is long, individual components are not listed here. Comments / Notes ERS APIs are calls directly to the ISE Admin nodes. ERS APIs are called from ISE primary admin node for read-write. We may call from ISE secondary admin node for read-only access. Sample Codes https://communities.cisco.com/docs/DOC-66297 Content Last Updated Details 2018/07/31 by ankanani - updated the features available section with more specifics 2018/05/07 by ankanani - initial draft Content validated by BU not validated Return to top   Web Security Appliance (WSA) API Type / Purpose No APIs available currently. In the roadmap API documentation   Features available in API wrt GUI / CLI   Comments / Notes   Sample Codes   Content Last Updated Details 2018/05/07 by ankanani - initial draft based on inputs from aarondek Content validated by BU On 2018/05/11 by aarondek Return to top   Email Security Appliance (ESA) API Type / Purpose REST API for Reporting - mainly to view stats and device health information API documentation There are 2 main API calls - health and stats. The list of calls + their documentation is also available as inline help - http://<ESA-MGMT-IP>:6080/api/v1.0/help http://<ESA-MGMT-IP>:6080/api/v1.0/health/help http://<ESA-MGMT-IP>:6080/api/v1.0/stats/help   APIs are available on HTTP port 6080 and HTTPS port 6443 by default.   Offline help - https://www.cisco.com/c/en/us/td/docs/security/esa/esa_all/esa_api/b_ESA_API_Getting_Started_Guide/b_ESA_API_Getting_Started_Guide_chapter_00.html Features available in API wrt GUI / CLI As of current version 11.0, APIs offer only statistics and health information. Comments / Notes   Sample Codes   Content Last Updated Details 2018/05/13 by ankanani - initial draft based on inputs from glturner Content validated by BU On 2018/05/13 by glturner Return to top   Security Management Appliance (SMA) API Type / Purpose No APIs available currently. APIs will be available as a part of Next-Gen SMA which is yet to be released. API documentation   Features available in API wrt GUI / CLI   Comments / Notes   Sample Codes   Content Last Updated Details 2018/05/13 by ankanani - initial draft based on inputs from glturner Content validated by BU On 2018/05/13 by glturner Return to top   Cisco Cloudlock - REST API API Type / Purpose REST API which is generally used for: Cloudlock incident management (SIEM/ITSM systems primarily for SOC usage) Cloudlock anomaly detection and triage Advanced event correlation (bringing back events) Cloud application management (including classification) API documentation  Cisco Cloudlock REST API documentation - https://docs.umbrella.com/cloudlock-documentation/docs/introduction-to-api-enterprise Features available in API wrt GUI / CLI Variety of endpoints which include among others: incidents (retrieving and updating incidents) anomalies/threats (including dismissal functionality) UEBA events apps - oauth connected apps (including classification capability) Comments / Notes API endpoints are added periodically – please re-check documentation or reach out if you have interest in specific functionality. Integrations exist for Splunk, IBM Qradar, Logrythm and other solutions which make use of the REST API. Sample Codes  Private repo available. Reach out to support@cloudlock.com for samples, scripts and initial configuration Content Last Updated Details 2018/12/12 by yaronca - initial draft Content validated by BU On 2018/12/12 by yaronca Return to top       ... View more

I am pleased to share a script t hat I have created to emulate the Time-Based Access Lists (ACL) functionality on Cisco Firepower Threat Defense (FTD) using the APIs available in Cisco Firepower Management Center (FMC). This can be used until the feature is available natively into the later versions of FTD/FMC.   This script - called as tba.py is a Python Script. It is available for download as an attachment from the bottom of this page.   How does it work: The user creates a text file containing the list of Policy Name, Rule ID and enable/disable timestamps. This script runs every 1 minute as a cronjob / scheduled task. It reads the file created by the user, checks if a rule is supposed to be enabled or disabled. If yes, then it makes the change on FMC by making the API calls. Then it pushes the Policy Changes onto the affected NGFW devices by triggering a Policy Deployment for those devices. Additionally, the script reports all its Activities and Errors to an Audit Log file. There are various error handling and reporting functions built in the script. The script can also send out an email notification after making any Policy updates.   What are the Dependencies / Requirements: Run this script on any separate host that has reachability to FMC via HTTPS for Management. Currently, it has been tested on Linux (however any OS should be fine as long as it has Python & the required Python modules installed). This script has been tested on Python 3.6, however it should work fine on any recent version of Python 3 or Python 2 It requires Python 'requests' module. This can be installed by executing the command "python -m pip install requests" on the CLI of the host where you will be running this script after installing Python. Create a new user on FMC specifically for executing this script. This user must have the Read-Write Privilege to Modify the required the Access Policies to enable/disable a particular rule, and this user must have the Privilege to Deploy the Policies on the NGFW devices. In case if you want to do manual deployment of the policy updates done by this script, then you will not need the Deploy Privilege for this user.   Which FMC / FTD softwares versions are supported: This script is created and tested on FMC version 6.2.2.x. The script makes API calls to the FMC only. So anything above FMC 6.2.2 and above should be fine. The script does not talk to FTD device, hence its version does not matter.   What are the Inputs required: The script will require the user to update the following variables inside the script BEFORE executing it for the first time. fmc_hostname = "x.x.x.x" # REQUIRED - Provide the IP or Hostname of FMC. fmc_username = "xxxx" # REQUIRED - Create a new user on FMC specifically for executing this script. DO NOT keep it same as your regular FMC user account. fmc_password = "xxxx" # REQUIRED - domain_in_fmc = "Global" # REQUIRED - FMC Management Domain. Leave it as it is, if you do not know what this is. smtp_server = 'smtp.mydomain.com:25' # OPTIONAL - provide this if you want email notifications about policy changes done by this script. Make it blank otherwise sender = 'no-reply@mydomain.com' # OPTIONAL - provide this if you want email notifications about policy changes done by this script. Make it blank otherwise receivers = ['securityadmin@mydomain.com'] # OPTIONAL - note the [] brackets in this one. do not delete them deploy_policy_changes_automatically = 1 # REQUIRED - 1 = automatic / 0 = manual, policy deployment to devices   The script will further require the user create a file named - tba-db.txt This file will contain the list of Policy Name, Rule ID and enable/disable timestamps for the Rules which the user wants to enable/disable at a particular pre-defined time. If you run the script without creating this file, then the script will create a sample file for you with simple documentation inside it around how to proceed further.   Here is how the tba-db.txt file would look like in production: ADD YOUR TIME BASED ACL DETAILS HERE IN THE BELOW SYNTAX: <ENABLE Date in YYYY-MM-DD HH:MM> #### <DISABLE Date in YYYY-MM-DD HH:MM> #### "<Policy Name>" #### <Rule ID> FOR EXAMPLE: 2018-03-25 00:00 #### 2018-04-24 23:59 #### "PFW Policy" #### 55 2018-03-25 00:00 #### 2018-04-24 23:59 #### "PFW Policy" #### 88 2018-03-30 00:00 #### 2018-04-31 23:59 #### "PFW Policy" #### 100 NOTE: IT IS ASSUMED THAT YOU HAVE ALREADY CREATED THE POLICIES AND RULES IN FMC BEFORE ADDING THEM HERE. ----------- THE RULE NAME, POLICY UUID AND RULE UUID WILL BE AUTO-POPULATED WHEN YOU EXECUTE THE TBA.PY SCRIPT. THEN THE SAME FILE WILL LOOK LIKE: <ENABLE Date in YYYY-MM-DD HH:MM> #### <DISABLE Date in YYYY-MM-DD HH:MM> #### "<Policy Name>" #### <Rule ID> #### "<Rule Name - auto-populated>" #### <Policy UUID - auto-populated> #### <Rule UUID - auto-populated> FOR EXAMPLE: 2018-03-25 00:00 #### 2018-04-24 23:59 #### "PFW Policy" #### 55 #### "Debug Rule - Ref CHG10861" #### 0050568E-5C8B-0ed3-0000-146028897141 #### 0050568E-5C8B-0ed3-0000-000268437508 ----------- FOR ADDING ANY NEW RULE, JUST FOLLOW THE SIMPLE SYNTAX GIVEN IN THE BEGINNING. FOR REMOVING ANY NEW RULE, JUST DELETE THE WHOLE RULE LINE. FOR MAKING ANY EDITS TO AN EXISTING RULE, SIMPLY UPDATE THE START TIME / END TIME. DO NOT CHANGE ANYTHING ELSE. ADD YOUR CONTENT BELOW THIS HASHED LINE ONLY ########################################################################################### 2018-04-01 00:00 #### 2018-04-10 23:59 #### "DMZ FW Policy" #### 100 2018-04-01 00:00 #### 2018-04-10 23:59 #### "DMZ FW Policy" #### 101 2018-04-01 00:00 #### 2018-04-10 23:59 #### "DMZ FW Policy" #### 102 2018-04-02 00:00 #### 2018-04-11 23:59 #### "Data Center FW Policy" #### 200 2018-04-03 09:00 #### 2018-04-12 17:59 #### "Data Center FW Policy" #### 201 2018-04-03 09:00 #### 2018-04-12 17:59 #### "Data Center FW Policy" #### 202   When you run the script, it pulls up the UUIDs of the above Access Policies and Rules. All the updates in FMC are done using these UUIDs. UUID is an automatically generated unique identifier of any entity like Access Policy, Access Rule, Network Object and more inside the FMC. Using UUIDs ensure that a different Rule is not accidentally enabled or disabled by this script in case if the Rule ID changes anytime due to any Rule Addition / Deletion done by the user directly in FMC.   Where can I track the activities of this script: The script documents all its Activities and Errors, if any, in a log file named - tba-audit.log file. This log file can be found in the same directory where the script is saved. Keep the script and the rules file in the same directory.   How to use this script: Install the pre-requisites as mentioned in the above section. Save the Script ( tba.py ) and the Rules File ( tba-db.txt ) in the directory of your choice. Modify the script and add the variables FMC hostname, username, password, etc as mentioned in the above section Update the Rules File and add the details in the syntax as mentioned in the above section Execute the script once manually to test that it is working fine Add the script as a CronJob in case of Linux / Mac or Scheduled Task in case of Windows. The script should be invoked EVERY 1 MINUTE. All the activities of the script can be viewed in the tba-audit.log file. The user may receive email notifications if email details are configured in the script. The Rules File ( tba-db.txt ) can be updated at any point of time. Any entries due to syntax error or due to the deletion of the Rule from FMC will be automatically commented out in the Rules File and reported in the Log file.   How to add a CronJob for this script: The CronJob for this script can be added just like you do for any other script or task. No special privileges are required for this. Even a non-admin user can add a CronJob.   Here is an article for reference - How do I set up a Cron job? - Ask Ubuntu   Here is the line that he would need to add for this script: * * * * * /usr/bin/python3 /absolute_full_path/tba.py > /dev/null   Where can I get Support / Can I make any changes to this script: This script is available for use to everyone in 'AS-IS' basis WITHOUT any form of support on the script itself. The user is free to make any modifications to the script code as required. It is strongly advised to test the script in a lab environment before using it in production. Also it is strongly advised to take periodic configuration backups before making any changes on the FMC through external medium like API calls. That will make it easier to restore in case if any undesired change happens.   I would like to explicitly call out and thank plakatos and neipatel for their useful inputs and for their attempts to create the initial versions of this. Also I would like to thank @hevyapan for providing an update with support added to deploy the same on Firewalls configured as High Availability (HA) pairs.   Hope the script is useful.   PS: 14/Dec/2018 - Updated the script with support added to deploy the same on Firewalls configured as High Availability (HA) pairs. ... View more

How to configure NSEL (~NetFlow) on Cisco Firepower Threat Defense (FTD) using the FlexConfig feature introduced in Firepower Management Center (FMC) software version 6.2 See the attached doc. Note that in a few versions of FTD code, the Flexconfig deployment for NetFlow as given in this document, may fail. This is due to a minor bug. Check out my comment in this article (scroll towards the bottom of the page) talking about this bug and its workaround. ... View more

In case of Guest Wireless Internet Access involving Self-Registration with Sponsor Approval workflow, currently a Sponsor can VIEW and APPROVE ALL self-registered guest requests. Currently in the default sponsor portal, a sponsor will be able to see & approve all guest registrations whether the guest has come to visitor that particular sponsor or not. There was no configuration to LIMIT a sponsor to view only the guests who has come to meet that particular sponsor. ISE 2.1 For SAML and ISE built-in users you can filter off the person being visited ISE 2.2 Adds support for AD Cisco Identity Services Engine Administrator Guide, Release 2.2 - Configure Guest Access [Cisco Identity Services Engin… Step 9 Configure sponsor Groups Approve and view requests from self-registering guests —Sponsors who are included in this Sponsor Group can either view all pending account requests from self-registering guests (that require approval), or only the requests where the user entered the Sponsor's email address as the person being visited. This feature requires that the portal used by the Self-registering guest has Require self-registered guests to be approved checked, and the Sponsor's email is listed as the person to contact. Any pending accounts—A sponsor belonging to this group an approve and review accounts that were created by any sponsor. Only pending accounts assigned to this sponsor—A sponsor belonging to this group can only view and approve accounts that they created. There is no direct workaround. A special workaround can be creating your own Sponsor portal using ISE REST APIs http://www.cisco.com/c/en/us/td/docs/security/ise/2-0/api_ref_guide/api_ref_book/ise_api_ref_ers1.html PLEASE NOTE THAT THE PORTAL CUSTOMIZATION AND CUSTOM PORTALS USING REST APIs ARE NOT SUPPORTED BY TAC. THE REST API ITSELF WILL BE SUPPORTED BY TAC. There is a Rest API call which will enable a sponsor to see all the guest requests. The same API call allows filters to be crafted on certain fixed parameters provided by the guest during his registration request. This article describes the workaround using this API call. In this article I am giving the minimum necessary steps and REST calls in this article and not the code to create the portal itself. The idea is that the System Integrator can build the sponsor portal himself as needed using the language of his choice. In the backend that will make the REST calls to ISE. --------------------- So First we will modify the GUEST PORTAL to CAPTURE and PASS the email of the sponsor. The default field that takes the “ PersonToVisitEmail ” cannot be used as a filter in the rest API. However the default field “ Company ” can be. So we will copy the data of “ PersonToVisitEmail ” field in the “ Company ” field. Also we create a new CUSTOM FIELD called “ CompanyName ” to capture the Company information, since the default “ Company ” field is being used for other purpose in this workaround. Now just write a Javascript in the Guest Portal to Hide the default “Company” Field and Copy the “PersonToVisitEmail” field into it when clicking the Register Button. List of supported filters can be found here - http://www.cisco.com/c/en/us/td/docs/security/ise/2-0/api_ref_guide/api_ref_book/ise_api_ref_guest.html#14546 Here are the steps to implement: Step 1: Navigate to ISE -> Guest Access -> Settings -> Custom Fields to create the new custom field “ CompanyName ” Step 2: Navigate to ISE -> Guest Access -> Configure -> Guest Portals -> Select the Portal Name -> In the Portal Behavior and Flow Settings Tab -> Click on Self-Registration Page Settings select the newly added Custom Field Step 3: Navigate to ISE -> Guest Access -> Configure -> Guest Portals -> Select the Portal Name -> In the Portal Page Customization Tab -> Click on Self-Registration to add some cosmetic details Step 4: On the same page, now add the javascript to COPY the information from PersonBeingVisited field to Company field and then HIDE the company field. To do this go to Optional Content 2 box, Click on TOGGLE HTML button, copy the below given javascript and then click on TOGGLE HTML button 2 times.  If you have successfully added the script, then it will show up only when TOGGLE HTML is ON. If it is OFF, then the box will show up as empty <script> jQuery("input[name='guestUser.fieldValues.ui_company']").parent().hide(); jQuery('#ui_self_reg_submit_button').on('click',function(evt){ //evt.preventDefault(); jQuery("input[name='guestUser.fieldValues.ui_company']").val(jQuery("input[name='guestUser.fieldValues.ui_person_visited']").val()); return true; }); </script><br _moz_editor_bogus_node="TRUE" /> Click the HTML Toggle button 2 times after putting the above script. Step 5: Click on SAVE button on the top of the page to save the changes. ------------------------------ The configuration is complete. The changes can be tested directly by connecting to the Real Guest Portal or by clicking on the Portal Test URL as shown below After all the changes are done, this is how the new Guest Portal and Sponsor workflow would look like: CUSTOM SPONSOR PORTAL USING REST API calls. SPONSOR CAN SEE AND APPROVE ONLY GUESTS THAT CAME TO MEET HIM ISE REST API is explained here. http://www.cisco.com/c/en/us/td/docs/security/ise/2-0/api_ref_guide/api_ref_book/ise_api_ref_ers1.html To see the Guests for that sponsor GET https://ISE-IP-ADDRESS:9060/ers/config/guestuser/?filter=company.eq.{sponsoremailid} To see details about a guest GET https://ISE-IP-ADDRESS:9060/ers/config/guestuser/{guest-id} To see details about a guest PUT https://ISE-IP-ADDRESS:9060/ers/config/guestuser/approve/{guest-id} Below screenshots show the building of a filter to see only the guests coming to meet particular sponsor. Note in the screenshot that we are passing the email id of the sponsor in the COMPANY field as explained earlier. ... View more