This page contains a list of frequently asked questions about SecureX orchestration. FAQs for the broader SecureX platform can be found here.
- Q: Where is SecureX orchestration hosted?
- Q: Do you provide a list of source IPs/hostnames for orchestration nodes?
- Q: How do I connect to on-premises devices?
- Q: What Python modules are available?
- Q: Can I install custom Python modules?
- Q: How do I make a workflow appear in Threat Response/SecureX ribbon/product pivot menus?
- Q: How long are workflow execution logs kept?
- Q: Does SecureX orchestration have an API?
A: As with most of SecureX, orchestration is hosted in Amazon Web Services (AWS). The AWS region depends on which instance of SecureX you’re using. For more information about AWS regions and SecureX privacy, please visit the Cisco Trust Center.
A: Please see the following table for the source IPs used by SecureX orchestration:
|Asia Pacific (APJC)||126.96.36.199 |
|Europe (EU)||188.8.131.52 |
|North America (NAM)||184.108.40.206 |
A: You can use the SecureX orchestration remote to integrate on-premises resources into your workflows. Check out this page for more information.
A: See the Python Modules page.
A: No. Python scripts in SecureX orchestration run inside a container that can’t be customized.
A: See the Response Workflows page.
A: Workflow execution logs, also known as runs, are kept for 90 days. Note that we only keep a workflow run’s full details for 30 days. After 30 days, only a summary of the workflow’s execution will be available.
A: No, SecureX orchestration does not have a publicly available API. However, if you want to run a workflow from an external system you can do so in one of two ways. The first is to use the SecureX response API to trigger a response workflow. The second is to use a webhook.