Enterprise IOC Feed

the enterprise ioc feed turns research into proactive defense it strengthens your threat detection and response posture by pushing intelligence directly into your security stack feeds deliver threat intelligence from flare into your existing security tooling (siem, soar, edr, tip, or firewalls) in industry standard stix 2 1 format via the taxii 2 1 protocol the enterprise ioc feed is delivered as two taxii feeds flare cti feed carries the intelligence objects themselves, including indicators, malware, threat actors, campaigns, and the other entity types flare cti relationship feed carries the stix relationships that connect those objects to one another, for example linking an indicator to the malware, campaign, and threat actor it belongs to both feeds use the same configuration they use taxii 2 1, with basic authentication using your flare api key each feed points to its own taxii endpoint and collection, which flare provides for more information, see our intelligence feeds api documentation https //api docs flare io/guides/ioc feeds key features broad ioc coverage support for the core indicator types security teams rely on, such as, domains, urls, ips, file hashes, campaigns, threat actor profiles, and intrusion sets stix/taxii delivery all feeds use stix 2 1 for the intelligence format and taxii 2 1 as the transport protocol this is the industry standard and most siems, soars, tips, and edrs support it natively your existing tooling can consume these feeds without custom integration work stix object relationships indicators are delivered with their full relationship context intact an indicator links to the campaign it belongs to, which links to the threat actor behind it, which links to the associated malware family your tip receives queryable, traversable intelligence, not a flat list access to this feature requires an add on please reach out to your csm for more information trials for trial accounts, once the cti module is enabled, these ioc feeds will begin populating from the moment the tenant is created it does not backfill historical intelligence, so objects published before the feed existed will not appear in the collection walkthrough click through the following product tour to learn how to integrate the enterprise ioc feed into your existing security stack configuring the ioc feed in opencti flare delivers intelligence through two taxii feeds the flare cti feed carries the indicators (iocs) along with their context objects, such as malware, campaigns, and tools the flare cti relationship feed carries the relationships objects that connect each indicator to the malware, campaigns, and threat actors it belongs to, so the intelligence arrives connected rather than as isolated objects follow these steps to configure flare's ioc feed in opencti create a new taxii feed in opencti, and use the following configuration for the flare cti feed name flare cti feed taxii server url https //api flare io/taxii2/cti/ taxii version taxii 2 1 taxii collection f1a4ec71 0c00 4f5f 9dbd e8a4cd33aa66 authentication type basic user / password this points to flare's taxii server using taxii 2 1 and the taxii collection id flare provides, authenticating with basic auth (api key as the username, a flare api key as the password) an empty import from date pulls the full collection create a second taxii feed, and use the following configuration for the flare cti relationship feed name flare cti relationship feed taxii server url https //api flare io/taxii2/cti/relationships/ taxii version taxii 2 1 taxii collection f1a4e540 2c14 4d5f 8bbc 2e7eb31ad104 authentication type basic user / password this points to the relationships endpoint using taxii 2 1 and its own taxii collection, with the same basic auth (api key as the username, a flare api key as the password) ingesting it alongside the main feed is what links each indicator to its malware, campaigns, and actors with both feeds configured and active, the tip polls flare's taxii server on a schedule and pulls new and updated objects automatically no manual exports or imports are involved once the connection is in place as ingestion runs, indicators flow into the platform each indicator arrives with full context showing stix pattern, a score and confidence level, kill chain phases, execution, and other information with this context in place, the tip can apply the indicators to detection and blocking rules integrating the ioc feed with misp flare delivers intelligence through two taxii feeds the flare cti feed carries the indicators (iocs) along with their context objects, such as malware, campaigns, and tools the flare cti relationship feed carries the relationships objects that connect each indicator to the malware, campaigns, and threat actors it belongs to, so the intelligence arrives connected rather than as isolated objects follow these steps to configure flare's ioc feed in misp setup the environment a create and activate a virtual environment, then install the two client libraries python3 m venv venv && venv/bin/activate pip install pymisp taxii2 client b set your connection details as environment variables, replacing the placeholder values with your own export flare api key="paste your flare api key" export flare sdo collection url="https //api flare io/taxii2/cti/collections/\<sdo id>/" export flare sro collection url="https //api flare io/taxii2/cti/relationships/collections/\<sro id>/" export misp url="https //your misp example com" export misp key="your misp automation key" export misp verify ssl="true" # "false" only for a self signed lab instance flare sdo collection url points to the flare cti feed, and flare sro collection url points to the flare cti relationship feed set misp verify ssl to false only for a self signed lab instance test the connection run this script first to confirm your api key works and to list the collections your key can reach view script #!/usr/bin/env python3 import os from taxii2client v21 import server server = server("https //api flare io/taxii2/", user="api key", password=os environ\["flare api key"]) print("connected to ", server title) for root in server api roots for c in root collections print(root url, " >", c id, c title) import indicators run this script to validate the pipeline with a first import it pulls the last day of indicators into a single misp event and does not include relationships view script #!/usr/bin/env python3 import os, json, uuid, tempfile, datetime, urllib3 from taxii2client v21 import collection, as pages from pymisp import pymisp urllib3 disable warnings() col = collection(os environ\["flare sdo collection url"], user="api key", password=os environ\["flare api key"]) since = (datetime datetime now(datetime timezone utc) \ datetime timedelta(days=1)) strftime("%y %m %dt%h %m %s 000z") objects = \[] for env in as pages(col get objects, per request=100, added after=since, type="indicator") objects extend(env get("objects", \[]) or \[]) if len(objects) >= 1000 # keep the bundle modest objects = objects\[ 1000]; break print(f"pulled {len(objects)} indicators") bundle = {"type" "bundle", "id" f"bundle {uuid uuid4()}", "objects" objects} with tempfile namedtemporaryfile("w", suffix=" json", delete=false) as f json dump(bundle, f); path = f name misp = pymisp(os environ\["misp url"], os environ\["misp key"], ssl=os environ get("misp verify ssl", "true") lower() == "true") print(misp upload stix(path=path, version="2")) import indicators with relationships once the pipeline is working, use this script for the full import it pulls the relationships first, then the objects they reference, and uploads them together so that each indicator lands in misp tagged with its related malware, campaign, or tool it records a timestamp in a state file for incremental sync, so each run only pulls what is new view script #!/usr/bin/env python3 """flare cti > misp with relationships preserved incremental via a state file """ import os, json, uuid, tempfile, datetime, urllib3 from taxii2client v21 import collection, as pages from pymisp import pymisp urllib3 disable warnings() flare key = os environ\["flare api key"] sdo url = os environ\["flare sdo collection url"] sro url = os environ\["flare sro collection url"] state = os environ get("state file", "flare state json") rel cap = int(os environ get("flare max relationships", "500")) \# standard stix types misp understands (flare's actor/chat channel/forum thread do not map) allowed = {"attack pattern","campaign","indicator","infrastructure","intrusion set", "location","malware","report","threat actor","tool","vulnerability"} def now() return datetime datetime now(datetime timezone utc) def iso(d) return d strftime("%y %m %dt%h %m %s 000z") def added after() try return json load(open(state))\["added after"] except exception return iso(now() datetime timedelta(hours=24)) def col(url) return collection(url, user="api key", password=flare key) def pull(url, cap=0, f) out = \[] for env in as pages(col(url) get objects, per request=100, f) out extend(env get("objects", \[]) or \[]) if cap and len(out) >= cap return out\[ cap] return out def resolve(url, ids, types, added=none) """flare ignores match\[id], so scan by type and keep the referenced objects """ f = {"type" types} if added f\["added after"] = added remaining, found = set(ids), {} for env in as pages(col(url) get objects, per request=100, f) for o in env get("objects", \[]) or \[] if o get("id") in remaining found\[o\["id"]] = o; remaining discard(o\["id"]) if not remaining break return found start = now() since = added after() sros = pull(sro url, cap=rel cap, added after=since) print(f"relationships {len(sros)}") srcs = {r\["source ref"] for r in sros if r get("source ref","") split(" ")\[0] in allowed} tgts = {r\["target ref"] for r in sros if r get("target ref","") split(" ")\[0] in allowed} inds = resolve(sdo url, srcs, "indicator", added=since) # recent indicators ctx = resolve(sdo url, tgts, "," join(sorted({i split(" ")\[0] for i in tgts})) or "malware") # older context have = set(inds) | set(ctx) good = \[r for r in sros if r get("source ref") in have and r get("target ref") in have] objects = list(inds values()) + list(ctx values()) + good print(f"uploading {len(objects)} objects") bundle = {"type" "bundle", "id" f"bundle {uuid uuid4()}", "objects" objects} with tempfile namedtemporaryfile("w", suffix=" json", delete=false) as f json dump(bundle, f); path = f name misp = pymisp(os environ\["misp url"], os environ\["misp key"], ssl=os environ get("misp verify ssl","true") lower()=="true") print(misp upload stix(path=path, version="2")) json dump({"added after" iso(start)}, open(state, "w")) # advance state for next run schedule the sync run the import script on a schedule so that misp stays current this cron entry runs it hourly # hourly, at 07 7 cd /opt/flare misp && venv/bin/activate && /ingest py >> ingest log 2>&1 keep the state file on a persistent path so that incremental sync survives restarts you can also run the script in a loop inside a container what the imported intelligence looks like once the import runs, the intelligence appears in misp as a populated event here is an example of an event that came in with a campaign, several intrusion sets, malware, and a tool, along with the indicators and the relationships between them under the event's attributes, each imported indicator carries its confidence level and tlp tags, and its related malware appears as a galaxy on the attribute these galaxies are filterable and pivotable, so you can move from an indicator to the malware family behind it imported indicators appear as event attributes, each tagged with its confidence level, tlp, and related malware galaxy opening a galaxy cluster shows the full intelligence context, such as the lazarus group intrusion set and its description each cluster retains its external references, linking back to the source reporting behind the intelligence notes and troubleshooting here are some important things to keep mind test the scripts review and test all scripts before running in production pull both feeds together new indicators often reference older malware or campaign objects if you pull only a narrow date window from both collections, those references will not resolve and misp will show no relationships the step 4 script handles this by resolving referenced objects regardless of their age keep bundles modest and request only standard stix types misp rejects very large uploads with an http 413 error relationships appear as galaxies in misp, a linked indicator shows its related malware or campaign as a galaxy on the ioc, which you can filter and pivot on