How to export your data from Anomali ThreatStream before the contract ends
A renewal, a price change, a residency rule or a concern about lock-in can each mean indicators have to leave ThreatStream before the contract ends. ThreatStream exports search results in eight formats: CSV, Snort, OpenIOC, STIX 1.1.1, STIX 1.2, STIX 2, STIX 2.1 and PDF. Each format carries its own result cap, so a complete export is a batched job, not a single download. This section relies only on Anomali's export documentation. That documentation describes no bulk export of everything at once, so the reader should confirm in writing with Anomali whether such a function exists for their tenant and deployment.
Batch planning starts with the caps. CSV exports are limited to 10,000 results, or 1,000 in the merged local and remote view on ThreatStream OnPrem, while STIX exports are limited to 100 results. The format therefore drives the size of the job. Illustratively, a search returning 25,000 results would need three CSV batches but 250 STIX batches. Users choose which columns go into a CSV export, so select the fields your target platform needs before you start. Every timestamp converts to UTC on export, so record that convention in your migration notes. Organization administrators can also configure maximum export limits, so ask your ThreatStream administrator whether any limit in your tenant is lower than the documented figures.
STIX output is the most direct route into OpenCTI and MISP. OpenCTI structures its data on STIX 2, so STIX 2 or STIX 2.1 files are the first ones to test, and MISP supports STIX 1 and 2 formats. Before the contract ends, run one small export per format into a test instance. Confirm object counts, timestamps and which fields arrive intact, and check how each target platform handles the file. Keep a log for every batch that records the search query, the export date, the format and the row count. That log is your evidence of completeness if a later check finds a gap. Finally, get the terms for access to your data after expiry in writing, because the export documentation does not address them.
What ThreatStream exports, by format and limit
This table lists the export options ThreatStream offers for search results and the row caps that set how many exports a migration needs. Read the limit column first, because the CSV and STIX caps determine the batch sizes you plan for each query. Figures come from Anomali's exporting search results documentation, and administrators can set lower maximums, so confirm current settings before scheduling exports.
| Export option | ThreatStream behavior or limit | What it means for your migration |
|---|---|---|
| Search-result formats | CSV, Snort, OpenIOC, STIX 1.1.1, STIX 1.2, STIX 2, STIX 2.1 or PDF | Use STIX 2.1 or CSV for loading; PDF is for reading only |
| CSV row limit | Up to 10,000 results per export | Split large sets by date or source filter to stay under the cap |
| CSV limit on OnPrem merged view | 1,000 results in the merged local and remote view on ThreatStream OnPrem | Export local and remote data separately if the merged view is capped |
| STIX row limit | Up to 100 results per export | Expect many more runs than CSV; script paging or ask Anomali about options |
| CSV column selection | Users choose which columns go into the file | Pick only the fields your MISP or OpenCTI import mapping expects |
| Timestamp handling | All timestamps convert to UTC on export | Confirm your target platform reads UTC and document the conversion |
| Administrator export limits | Organization admins can set maximum export limits | Ask the ThreatStream admin for current caps before planning batches |
| Snort and OpenIOC output | Available as search-result export formats | Confirm import support in your target MISP or OpenCTI version before relying on them |
How the per-format caps turn one export into many
The result caps in ThreatStream limit how many rows one export can carry, so they set the number of batches you need, not the amount of data you can move. A search that returns more results than the cap for its format must be split into smaller searches, each narrowed by filters such as time range, source feed or indicator type, and each exported on its own. The CSV cap is 10,000 results, or 1,000 in the merged local and remote view on ThreatStream OnPrem, while STIX exports stop at 100 results. A STIX export of a large search therefore produces a very large number of files, which is why the choice of format should follow the migration target, not habit.
Three factors drive how many batches you will run. The first is the number of observables in scope, which you can estimate from the search counts before exporting. The second is how precisely you narrow each search: splitting by time window is simple to script and keeps batch boundaries predictable, while splitting by source or indicator type keeps related records together but may leave some batches uneven. The third is whether your deployment uses the OnPrem merged view, because the 1,000 result limit there changes the arithmetic even when the same search runs against a smaller local dataset. Record the filters and counts for every batch so you can prove afterward that no observable was skipped or exported twice.
Before you plan batch sizes, confirm the current caps and any administrator limits in your own tenant. Organization administrators can configure maximum export limits, which can be lower than the documented values, and Anomali's export documentation at Exporting search results is the place to check the current figures for your version. Ask your administrator for the configured limits in writing, and run a test export of one batch per format to confirm row counts match the search total before you commit to a schedule.
What does not export from ThreatStream and what to do instead
The documented search result exports cover observables and their columns, but several things an analyst or administrator relies on sit outside that path. The cards below cover each gap, the workaround using documented exports or a manual inventory, and what to confirm with Anomali before you plan the migration.
PDF output as structured data
ThreatStream can export search results as PDF, but a PDF is a presentation format, not a data format. Columns, types and timestamps are hard to parse back into MISP or OpenCTI, so treat PDF as a human-readable record only. For machine import, use the CSV or STIX exports instead, and keep the PDF as an archived snapshot of what an analyst reviewed. Ask Anomali whether any other structured export exists for your tenant.
Analyst notes and investigation context
Search result exports carry observables and selected fields, not the free-text notes, tags added during triage or the investigation history attached to an indicator. Before you export, record which indicators have analyst commentary and copy the key notes into a manual inventory sheet with the indicator value, date and author. Import these as attributes or comments in MISP or as notes on report objects in OpenCTI so the reasoning survives the move.
Sharing agreements and partner trust groups
Who receives which indicators, under which terms, is governed by ThreatStream sharing relationships with partners and communities. Those agreements do not travel with an export. Write down each partner, the data they receive, the handling terms and the contact owner in a register. MISP models this through distribution levels and sharing groups, so the register becomes the blueprint for rebuilding trust relationships rather than a copy of ThreatStream's settings.
Feed subscriptions and TAXII configuration
Your list of subscribed feeds, their polling intervals, credentials and TAXII collection endpoints are configuration, not search results. None of the documented export formats carry them. Export the indicators you still need, then record each feed's name, source, update frequency and owner from the ThreatStream console. Re-subscribe in MISP or OpenCTI using that list, and confirm with Anomali which feed configuration, if any, the tenant can produce.
Integration rules in SIEM and firewalls
The logic that pushes ThreatStream indicators into SIEM watchlists, firewall block lists and DNS policies lives in those products, not in ThreatStream exports. An exported indicator list does not tell you which rule consumed it, which action it triggered or which block list it fed. Inventory every consuming system, its rule names and its update method before cutover, then repoint each one to the MISP or OpenCTI feed endpoint and test it in a non-production system first.
User accounts and roles
Analyst accounts, group memberships, organization administrator settings and per-user export limits are administrative data. Exports of observables contain none of it. Build a manual inventory listing each user, role, team and the export limits set by administrators, then map those roles to MISP roles and OpenCTI groups and organizations. Confirm with Anomali whether the tenant offers any user listing export, and record who approved each access decision.
Sequence for a complete ThreatStream export with verification
This sequence turns a ThreatStream export into a set of files you can prove are complete, correctly formatted and ready for MISP or OpenCTI before the subscription ends. Each step ends with a count, a file fingerprint or a re-import check that someone other than the exporter can review.
Inventory searches and indicator types in scope
Start by listing every saved search, filter and indicator type your teams rely on, including observables tagged for SIEM, firewall or sharing use. Record the expected count for each search from the ThreatStream interface, along with the owner and the destination system. This inventory is the baseline you reconcile against later, so keep it in a controlled location and version it. The step is done when every search has an owner, a destination and a recorded expected count.
Confirm export limits with the administrator
Ask the organization administrator for the export limits configured for your account, since administrators can set maximum export limits. Use the researched caps as the starting point: CSV exports are capped at 10,000 results, or 1,000 in the merged local and remote view for ThreatStream OnPrem, and STIX exports at 100 results. Ask the administrator to confirm these values in writing for your tenant and deployment. The step is done when the limits are recorded next to the inventory.
Choose a format for each destination
Select the export format based on where the data will land. For OpenCTI, use STIX 2.1 because OpenCTI structures its data on STIX 2. For MISP, choose STIX 2 or CSV, depending on which import path your team has tested. Note that Snort, OpenIOC, STIX 1.1.1, STIX 1.2 and PDF are available but are not the default route for either target. Record the chosen format per search in the inventory. The step is done when each search has one format and one destination.
Split queries into batches under the caps
Divide each search into batches that stay below the applicable cap. For CSV, you can narrow by indicator type, date window or confidence band. For STIX, the 100-result cap means many more batches, so plan the splits before you start exporting. Give every batch a stable name that includes the search, format, date window and sequence number. Confirm the batch plan adds up to the expected total from the inventory. The step is done when the batch plan sums to the baseline count.
Select CSV columns that carry the value
For CSV batches, choose the columns that preserve the information you will need downstream: observable value, indicator type, confidence, source, and the timestamps. ThreatStream allows column selection for CSV, so save the same column set for every batch so files can be compared. Record the column list in the export log. The step is done when a test export opens with all five fields populated for a sample of rows.
Export each batch and record counts
Run each batch in the planned order and save the file under its batch name. Immediately record the row count of each file, excluding headers, in the export log together with the search, format, date window and the time of export. For STIX files, count the indicator objects rather than lines. Compare each batch count against the plan, and re-run any batch that is short or shows a cap warning. The step is done when every batch has a recorded count and a matching export entry.
Check UTC timestamps and file integrity
ThreatStream converts all timestamps to UTC on export, so check that the timestamp values in a sample of rows match the UTC times shown in the source. Then compute a SHA-256 hash for each file with
sha256sumand store the hashes beside the export log, so later copies can be verified as unchanged. Keep the originals read-only. The step is done when timestamps are confirmed on samples from every batch and each file has a stored hash.Re-import samples and reconcile totals
Import a sample from each batch into the target platform, either a test MISP instance or an OpenCTI test environment. Compare the imported object count and a set of spot-checked values with the source file. Once samples pass, import the full batch set and reconcile the total number of records in the target against the baseline from the inventory, noting any differences and their causes. Complete this reconciliation before the ThreatStream subscription ends, and keep the export log, hashes and reconciliation report as the retained evidence. The step is done when the target totals match the baseline or each difference has a documented explanation.
How STIX output lands in MISP or OpenCTI
Test a sample batch of STIX output in both target platforms before you move the full export. ThreatStream can produce STIX 1.1.1, STIX 1.2, STIX 2 and STIX 2.1, and the version you choose determines which importer handles the file. MISP supports STIX 1 and 2 import as well as its own MISP format, so a STIX 2.1 file and a STIX 1.x file will not be processed the same way. OpenCTI structures its data on the STIX 2 standard and loads STIX 2 bundles, so STIX 2.1 is the natural format to test there. Before choosing, confirm in the current MISP and OpenCTI documentation which STIX versions each importer accepts and how they handle object types that ThreatStream uses.
Check object mapping, duplicates and relationships on the sample, not in production. Export a small set of indicators, malware and threat actor objects through the STIX route, import them into a test instance and compare the result against the source in ThreatStream. Look at whether indicator patterns, observables, labels and confidence values arrive where you expect, whether re-importing the same bundle creates duplicates, and whether relationships between indicators and actors survive the import. Record each difference as a mapping rule you accept, a rule you fix with a transformation, or a gap you handle by hand. Because STIX 1.x files need conversion or a deliberate version choice, decide early whether legacy exports will be converted, re-exported as STIX 2 or left out of scope.
Treat connectors and sharing settings as separate decisions from the file format. In OpenCTI, the STIX bundle is the data model, but ingestion is handled by its platform and connectors, so confirm which connector you will use for each source and how it writes to the knowledge graph. In MISP, imported objects receive distribution and sharing settings, which determine who can see them once synchronized with partners. Set those defaults before the import so that a test batch does not get shared with a community by accident. Document the results of the sample run, including the versions you tested, so the full migration can repeat the same steps.
What do buyers ask before they export ThreatStream data?
How much effort does a full ThreatStream export take?
The effort depends on how much data you hold, how it is split across searches and how carefully you verify the result. The per-format result caps are the main driver. CSV exports stop at 10,000 results, or 1,000 in the merged local and remote view on ThreatStream OnPrem, and STIX exports stop at 100 results, so a large indicator base becomes many smaller exports. Other drivers are the number of saved searches, how many fields you keep in each CSV, and whether you reconcile counts and timestamps after import. Timestamps are converted to UTC on export, so your target platform needs to expect that. Ask for a written count of searches and expected export batches before agreeing on scope.
Can our own team export the data without outside help?
Often yes, for a small and well-documented data set. An administrator can run the searches, choose columns for CSV, and download files using the export options in the product. The harder part is repeating that across many searches, keeping a record of what was exported, and checking that nothing was missed because of a cap. Teams with a single analyst, no test environment and no target platform usually find the verification work is the bottleneck. Outside help makes most sense when you need a repeatable export log, a reconciliation report and an import that has been tested before cutover.
What access and preparation does the export need?
Start with access and a destination. You need an account that can run searches and exports, and an organization administrator who can confirm or change the configured maximum export limits, since those can differ from the defaults. You also need a target platform, either MISP or OpenCTI, and a non-production test environment where imports can be checked. Prepare a list of the saved searches, feeds and tags that matter, and decide which CSV columns map to which attributes. Keep the exported files in controlled storage with access logging, because indicator data is often sensitive.
Can MISP or OpenCTI receive ThreatStream exports directly?
Each platform takes data in a different way, so the answer depends on the format. MISP supports STIX 1 and 2, its own MISP format, CSV and OpenIOC, so ThreatStream exports in these formats can be reviewed for import, though field mapping still needs checking. OpenCTI structures its data on the STIX 2 standard, so STIX 2 or STIX 2.1 exports are the natural starting point for import. Plain CSV usually needs a mapping step before it becomes useful. Expect actor, campaign and malware relationships to need rebuilding rather than arriving intact, and confirm the format and version with a sample file before committing to a full run.
What does a fixed-scope export engagement cover?
A fixed-scope engagement covers the work agreed in writing before it starts: the searches and formats in scope, the target platform, the import and mapping approach, the verification method and the deliverables. DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms in your own infrastructure, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Anything outside the written scope, such as rebuilding SIEM integrations or running feed curation, should be listed separately. A quote follows from the written scope, and DeployOpen does not publish a price list.
What must we confirm with Anomali before ending the subscription?
Confirm, in writing, what your contract allows you to export, in which formats, and for how long you keep access after termination. Ask whether the export limits configured for your organization can be raised for the exit period, and whether the local and remote views on your deployment change how many results you can pull. Check any restrictions on reusing the data, including feed content that the vendor licenses rather than you owning. Also ask what happens to archived data, support channels during the transition, and any notice period. Anomali's own export documentation is the first reference for format and limit behavior.
How do we check that the export is complete?
Completeness is checked by comparing counts and samples, not by assuming the download succeeded. Record the result count for each search before export, then compare it to the rows in each file, paying attention to any search that hit a per-format cap. Spot-check a sample of indicators in both systems after import, including timestamps, which are in UTC on export, and tags or confidence fields. Keep a simple log of file names, checksums and counts so an auditor or a colleague can trace what moved. This verification step is often the largest share of the effort.
What to plan before the ThreatStream renewal or termination
The export itself is the last step of a longer exit. Contract terms, the inventory of what you rely on, and the hosting decision all set how much you can export, how long you have, and who must confirm the result. Settle these first, and confirm each term with Anomali in writing.
Notice window and export rights
Read the renewal and termination clauses for the notice period, the end-of-term date, and whether you keep read access to search results after termination. Ask Anomali in writing whether export limits in your organization differ from the standard documented caps, since administrators can configure maximum export limits. Confirm whether bulk or support-assisted exports are available if you need more than the interface allows.
Inventory of searches and feeds
List every saved search, watchlist, scheduled export, and feed subscription your teams use. Record which ones feed detections, blocklists, or reports, because those are the ones that cannot lapse during cutover. Note the owner of each item and the format it is currently exported in, so the export plan covers all of them.
Target platform and hosting decision
Choose between self-hosted MISP and OpenCTI, or both, and decide where they will run: your cloud account, a data center, or an air-gapped network. OpenCTI needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage alongside the platform, which affects the hosting plan. Use the sizing guidance in the vendor documentation to scope infrastructure before you commit to a date.
Parallel running and integration cutover
Plan a period where ThreatStream and the new platform run side by side. Map every SIEM, firewall, and TAXII integration that consumes ThreatStream output, then decide the order in which each is re-pointed. Keep the old feed active until each consumer confirms it receives indicators from the new source, so detections do not gap during the switch.
Retention and deletion obligations
Exported indicators may carry partner or sharing restrictions, personal data in context fields, or retention rules set by your own policy or regulator. Decide how long exported CSV and STIX files may be kept, where they are stored, and how they are deleted once the new platform holds the data. Check whether your contract restricts how Anomali-sourced data is retained or shared after termination.
Verification sign-off
Name the person who approves that the export is complete. Compare record counts per format against the ThreatStream results, check that timestamps were converted to UTC on export, and confirm that the columns you selected for CSV contain every field the analysts need. Record the sign-off in your change log so auditors and the contract owner can trace the exit.
How DeployOpen scopes and delivers a ThreatStream exit
DeployOpen works on ThreatStream exports as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. We plan, build, test, document and hand over the export pipeline inside your own infrastructure, so the exported data lands in a platform you operate.
How we scope
- Inventory every ThreatStream search, saved view and export format your teams use today.
- Confirm which export formats and CSV column sets feed downstream SIEM, firewall or partner workflows.
- Record the per-format result caps and how many batches each dataset requires, agreed in writing.
How we build
- Script batched exports that stay within the documented CSV and STIX result limits.
- Map exported CSV columns and STIX objects to the target MISP or OpenCTI data model.
- Test imports on a copy of the export, checking UTC timestamps, counts and duplicate handling.
How we hand over
- Deliver runbooks for each export batch, import step and reconciliation check.
- Document the completed count per dataset so your team can verify the transfer independently.
- Walk your operators through the target platform so the export process is repeatable.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Confirm with your ThreatStream administrator whether export limits were changed before work begins.
- Agree in the written scope who retains copies of exports and when they are securely deleted.
