Cisco Cognitive Threat Analytics (CTA) will be migrated to a new location, which results in new URLs and IP addresses for access and use of the service.
In order to help ensure future flexibility and performance, Cisco CTA will be migrated to the Amazon Web Services (AWS) Cloud.
The migration will take place in two phases:
The first phase covers the migration of the CTA Landing Page, CTA Portal, API Services, and Trusted Automated eXchange of Indicator Information (TAXII) service.
The second phase covers the migration of the data ingest services.
This document covers the changes related to the first phase of the migration only. A subsequent document that covers the second phase of the migration will be published at a later date.
The switchover is scheduled to take place on Monday, August 20, 2018, 7:00 - 9:00 a.m. CEST (Sunday, August 19 10:00 p.m. - midnight Pacific).
During the switchover, there will be a two-hour maintenance window required to resync data from the old data center to the AWS data center during which the CTA user interface, Structured Threat Information eXpression (STIX)/TAXII services, and integration services will be unavailable. Data ingest will continue to accept customer telemetry, but no new devices can be provisioned during the maintenance break.
In the process of the migration, we are not replicating incident database from the legacy data center to the new location. Instead, the system will migrate only anomalous traffic within the look-back period of 45 days and will independently derive new incidents in the target AWS environment. As a result of that, the visible history of your incidents is limited to only 45 days of anomalous traffic. Also there might be slight differences in the incident detail, due to the probabilistic nature of the detection engine.
As a consequence of the migration, you might need to perform changes in order to use the service unaffected. Failure to perform the needed changes will not result in loss of data analytics, but might result in loss of access to the CTA portal as well as a stop of import into your security information and event management (SIEM) solution should you use one.
The current URLs will stay unchanged but point to new IP addresses after migration. In order to continue to use the service after the completed switchover, you should make these changes:
If you have access control lists (ACLs) in place in your firewall that limits outbound access, and these ACLs are IP address-based, you must add the new IP addresses/ranges. Allow both AWS Elastic IP (EIP) addresses and Cisco IP addresses listed in the table.
If you use the API offered by Cisco CTA to export your security data into your own SIEM solution, and you reference Cisco's API by IP address and not by URL, Cisco recommends that you change your setting in your SIEM solution to use the URL. If you cannot use the URL in your SIEM solution, you can change your settings to point to one of the IP addresses, but in that case, Cisco cannot guarantee the service availability. If you need the service to always be available you need to use the URL, as high availability will be implemented with Domain Name System (DNS).
Refer to the tables for the new as well as the current URLs and IP addresses.
Hi,I would like to ask for experts' opinion on how to address the following design scenario: We currently rely on Posture (Anyconnect based) for NAC via ISE for granting endpoint access to our network (per VPN as well as WLC based) based on a given s...
Hi guys,Running ACS v5.8 and created an admin account in the ReadOnlyAdmin role but when they try and login to web gui(https://<ip address>/acsadmin) they get Access Denied. If I make them a SuperUser they get on fine........any ideas for ReadOnlyAd...
Have a 5525-X used as a perimeter fw and we want to update the software to the appropriate stable release. We do not have FirePower. Read the ASA Upgrade Guide and have looked at the various interim releases and I don't know which to select.&nb...
Hello everyone, we noticed that in the client VPN group "XXXX" access to internal resources without AD group membership (ATTRIBUTE_MAP) is possible!!. E.g. Open the $ shared folders of internal systems (tested with \\ 10.10.8.10 \c$\ if the user does not ...