Eventually, all will. At the current time, a license to any of the Cisco products listed here grants immediate rights to use the SecureX platform:
Note that for many of the on-premise products, there will also be version number requirements - consult the relevant documentation for more information.
The short, functional answer: SecureX doesn't keep data. We are not a data aggregator, we are an API aggregator. The products keep their own data; SecureX only asks questions. Each product has its own data retention policies. We ask our questions, we get our answers, and we keep those answers for as long as the user is looking at them, and no longer. Users can store data in SecureX... Incidents, snapshots, casebooks, judgments. That is opt in only. And we store each of those until the user opts to delete it.
The longer, legalese answer: SecureX adheres to the general Cisco Cloud Services privacy policies, and the specific SecureX document can be seen here.
SSE (Security Services Exchange) is the cloud-hosted data and authentication broker that facilitates communication between SecureX and on-premise devices such as Firewalls and Email / Web security appliances. Authentication to and through SSE is handled by tokens and/or Smart Accounts.
In order to unlink your Smart Account from your Security Services Exchanges (SSE) organization you use the controls available in SSE. You can then link that Smart Account to another SSE organization in the usual fashion.
Yes. There is no option or reason to do otherwise, and all inter-service communications started by either service assume that the other service's region is the same as its own.
The browser plugin is an applet that lives in your browser (for Chromium and Firefox based browsers, including MS Edge). It allows you to take all the tools in the Ribbon with you everywhere you go on the web, including the Incident Manager, casebook and Orbital ribbon apps, and the ability to scrape browser content for observables and immediately take response actions and/or pivot into details investigations of them in your environment.
More information on obtaining and configuring the browser plugin can be found in the plugin FAQ here:
SecureX includes SecureX Signon (SXSO), which is an identity provider (IdP). SecureX also, however, honors IdP services provided by Cisco Security (aka "CS", "CSA", or "Cisco Security Account") and Threat Grid. Users are given the option for backwards compatibility purposes. CS accounts will be migrated into SecureX Signon as SXSO accounts, and Threat Grid users will be migrated into using SecureX Signon as well.
ONLY If you are not already a user of Threat Response, Secure Endpoint (AMP for Endpoints), or the Secure File Analysis (Threat Grid) cloud portal, you should create a SecureX account.
If you are already a user of any of those products, please refer to this document for further instruction:
Navigate directly to securex.us.security.cisco.com and choose 'Cisco Security' as the identity provider. From here you will be redirected to https://auth.amp.cisco.com/ where you can enter a username and password or choose single sign-on (users managed at https://castle.amp.cisco.com).
More info about 3rd party IdP support is available here:
An excellent introduction to the concepts and operation of SecureX Signon is available here:
As well, please refer to this page for more SecureX Sign on answers and guidance:
Threat Response, released in early 2018, is now part of SecureX. Threat Response features, configurations, saved data etc, will remain intact for existing users who are now accessing Threat Response as part of SecureX. For more information, see this document: https://www.cisco.com/c/dam/en/us/products/se/2020/7/Collateral/securex-threat-res-faq.pdf
CTR did not use SecureX sign-on accounts. CTR used and still uses a different login, either a "Cisco Security Account" or a Threat Grid login. You signed into SecureX with an account that's not connected to your CTR organization. If you’re already using CTR, keep using the same account for SecureX. That will connect SecureX to CTR for you. You can keep your SecureX sign-on account and use it to connect to other products including Umbrella, Cisco Defense Orchestrator, Stealthwatch Cloud, Meraki, and Cloudlock. In the future, we'll migrate Cisco Security Accounts to SecureX sign-on. For more information, see this article.
It is recommended that input be no more than 2000 characters. Longer inputs can be chunked for inspection (the process of discovering observables in the text) and then the resultant observables, if less than 2000 characters, can be submitted for a single unified investigation.
Yes, the graph will not show more than 200 nodes at a time. If that limit is exceeded in the data, there is a hierarchy applied and only the top 200 will be drawn.
While we consolidate resources, please check in the Threat Response FAQ for answers to questions about SecureX Threat response.
If you launch orchestration and come across an error that says "upstream connect error or disconnect/reset before headers. reset reason: connection termination" please clear your browser cache and launch orchestration again. This is a known issue the SecureX team is working to resolve.
For a custom workflow to appear in the pivot menu, two things have to be true. It has to have a category label of "response" applied to it, and it has to have been validated. For it to work, it also has to take two input variables, "observable_type" and "observable_value". These corresponding to the two pieces of information about the observable that are provided to the workflow by SecureX threat response when the workflow is called from that observable's menu.
The Python interpreter is included in the Action Orchestrator interpreter, which is hosted in the SecureX cloud infrastructure.
You can check at any time by running the following python command as a part of, or as the entirety of, the script to be run in the adapter:
A relay adapter is in development that will facilitate this.
Yes. All Cisco Security products will be SecureX-capable.
To enable the Ribbon in other products, generate an API client with the following scopes enabled (checked):
[casebook, enrich, global-intel, inspect, integration, orbital, private-intel, profile, registry, response, telemetry, users].
The credentials for this API Client can then be provided to all ribbon-capable products to enable all Ribbon features in that product's UI.
AMP for Endpoints provides Visibility and Control. By adding AMP for Endpoints to SecureX, investigators will be able to search for IP addresses, domains, URLs and file hashes that have been recorded by AMP for Endpoints. AMP for Endpoints also provides you the capabilities within Threat Response to block a file SHA or isolate an affected host.
With this integration, investigators can see intrusion and other events from Firepower devices correlated with enrichment from other Cisco Security products, adding greater context and helping the SOC investigate incidents with broader internal visibility.
The Firepower integration also supports Incident Manager, in which investigators can see, manage, and investigate curated high urgency intrusion events in Threat Response. Intrusion events from Firepower are the first data source that populates the Incident Manager (with more coming soon).
At least v6.3 for a syslog integration, although 6.5+ is highly recommended. Direct event forwarding is supported in 6.4+ in the NAM region, and 6.5+ in the EU and APJC regions. As well, the 6.5 upgrade introduced the ability to forward additional even types to be used as enrichment data and potential Incident tracking.
Yes, they can still contribute to SecureX by using the CSSP syslog relay as described in the documentation here.
SMA was SecureX-capable as a module in threat response as of AsyncOS version 12.0. To get SMA tiles in the SecureX dashboard, the SMA needs to be at version 13.6.2 or higher.
AsyncOS 13.0 and higher support Threat Response functions; the ability to search the history of observed email in the course of investigations.
AsyncOS 13.5.2 or higher is required to also have Cisco Secure Email tiles in the SecureX doashboard.
SWE 7.2.1 and higher supports SecureX dashboards and SecureX threat response functions. (integration guide)
SWE 7.1.2 and 7.1.3 will support SecureX threat response functions only. (integration guide)
After integration, the SecureX Ribbon is available in the SWC console, bringing threat intelligence and response capabilities from the rest of your combined SecureX stack. Also, SWC contributes tiles into the SecureX dashboard, allowing key metrics from that stack, including SWC, to be viewed in one place at any time.
Current and recent versions of Chrome, Firefox, and Edge
The browser plugin allows you to leverage SecureX ribbon capabilities on and with browser content. For example, you can pivot directly into investigations in SecureX Threat Response with observables automatically extracted from any web page, such as your favorite infosec blog or the web management console of any security or networking product. You can also immediately pivot into any of your connected SecureX-capable Cisco or 3rd party tools, and natively use ribbon apps like Incident Manager and Orbital.
The configuration process is very straightforward and is described here.
Our partner ecosystem catalog is available at http://cs.co/CSTA
There is also this blog article: https://blogs.cisco.com/security/securex-threat-response-ecosystem
A Relay Module is how SecureX can leverage a third party product for to use it as an information source in investigations and response actions in threat response. It requires a relay, hence the name. The relay translates from Cisco SecureX APIs and data model (CTIM) on one side, and the third party product's API and data model on the other. The existence of this relay greatly accelerates the speed at which third party product integrations can be developed and deployed.
Relays can be hosted by users, or by the vendors of the integrated products, or in some integrations by SecureX.
Several relays already built to use various 3rd party tools are available for download from: http://github.com/CiscoSecurity
Thorsten Schranz has documented the process here: https://community.cisco.com/t5/security-documents/part-1-serverless-relay-on-aws-for-securex-ctr-3rd-party-modules/ta-p/4121874
The capabilities granted to Admin accounts but not Users are: