How to start your own threat intel company?

Have you ever wondered where all the threat intel feeds come from? How do these companies know that this, or that email account has been compromised? How do they identify breaches, early? How do they collect data in a way that does not force them to manually search the internet, dark web, social media, join highly vetted dodgy forums?

The answer is simple:

  • they hoard lots of data
  • they automate the process of acquiring this data, and
  • they keep themselves in the loop.

Here’s list of data sources, assets, know-how they leverage:

  • networking (many years in the industry helps to build connections, relationships, and people moving around between different companies still keep in touch, often sharing highly confidential information between themselves; it’s often the best source of intel, really) – this involves industry peers, but also Law Enforcement, Cloud providers, FinTech, Card Schemes contacts, and … yes, Clients!
  • participation in trusted/vetted peer groups (often focused on ransomware, emerging threats, criminal activities, BEC, etc.)
  • methodology and know-how learned working for the government agencies drives activities in a proper direction — not rewriting the news, but actively participating in strategic processes by providing information to support C-level individuals so they can make educated decisions about IT and IT Security
  • data from security sensors (AV, EDR, FIM, email, proxy logs, etc.) – both high-fidelity detections, and low-, mid- fidelity threat hunting exercises, ideally, across many environments; also, asset inventories!
  • OS vendors and selected software shops have access to crash reports (often indicating failed exploitation attempts, and sometimes in progress)
  • ongoing web crawling, mirroring, and scraping (what is there today, may not be available tomorrow, plus, building the most comprehensive data sets is a must – everything is assumed to be ephemeral!)
  • social media analysis
  • security vendor reports
  • gov agencies reports (f.ex. CISA, FBI)
  • card schemes reports
  • *-ISAC reports
  • specific entities covering 0days (f.ex. Project Zero)
  • staying up to date with the CVE security vulnerability database
  • understanding the historical context (f.ex. trends in security, ups and downs, bugtraq, etc.)
  • actively pursuing understanding of IT Security domain in the the most broadest way (f.ex. CISSP, CISM, SANS courses, but also reading RFCs, OS internals, etc.)
  • working and being comfortable with Vulnerability Management circles
  • working with Support functions (often being the first one to hear about ‘something funny going on’)
  • ongoing repository searches (f.ex. github)
  • ongoing cloud storage facilities scans (f.ex. S3)
  • DNS and WHOIS data analysis
  • internet-wide data analysis (f.ex. shodan, alexa, umbrella, etc.)
  • actively pursuing at least high-level info/know-how on actively developing domains/new areas of interest (f.ex. DoH, deep fakes, SaaS threat models)
  • ongoing dark web scraping and analysis
  • analysis of data dumps from past breaches
  • leveraging findings from DFIR engagements
  • malware sample metadata collection – identifying IOCs
  • malware sample sandboxing (f.ex. extracting configs, credentials, domains, emails, (S)FTP accounts) – identifying TTPs
  • clean sample metadata collection – to understand how ‘good’ looks like
  • hacking admin panels (gray area, but it does happen)
  • purchasing software and services from ‘providers’ with a sole purpose of analysing them
  • virustotal rules (f.ex. for textual files that look like credential dumps)
  • leveraging existing data sets (f.ex. pihole, ad-blocking lists)
  • leveraging passive DNS
  • purchasing data dumps from dodgy providers
  • purchasing feeds from other threat intel providers
  • purchasing VPN software to ID their IPs
  • TOR-new identity rotation to discover TOR IPs
  • analytics of disposable emails and messaging platforms
  • setting up canary tokens
  • setting up google alerts
  • maintaining a network of informers (I made it up, but maybe it does happen)
  • leveraging and aggregating various rules f.ex.: yara, sigma, suricata, lol-anything
  • leveraging Red Team-related project announcements (code injections, evasions, new techniques, iterations of existing techniques, etc.)
  • leveraging existing threat encyclopedias (f.ex. malpedia, APTNotes)
  • leveraging malware samples repos (f.ex. vx-underground, virusshare, malshare, etc.)
  • active and ongoing manual OSINT research
  • leveraging publicly available research (new ideas, powerful google or shodan dorks, etc.)
  • following developments in areas parallel to malware and hacking f.ex. game cheating, warez, P2P, TOR, AI, new programming languages, platforms, package managers
  • learning about and embracing new asset inventory tools (f.ex. for Cloud)
  • leveraging information obtained from clients (f.ex. during tabletop or IR preparedness exercises, hardening exercises, presales and sales talks, SOWs, questionnaires)
  • acquiring existing Threat Intel companies
  • poaching experienced Threat Intel analysts
  • PR stunts

As you can see, it’s a piece of cake.

When I started jotting these items down I thought it will be probably 10-15 items, max. It’s actually over 50 now and I am sure there is actually more… If you can think of any that I missed, please let me know and I will add it to the list. TA!

Can you start your own TI company today?

Probably, but it’s gonna cost you, and the existing companies that have millions of dollars in their budget will not give their piece of the pie away easily…

Full disclosure: I have never ran a Threat Intel company or function. After years of not seeing much value in TI I finally grew up, and feel that this discipline will mature in ways most of us will find surprising. Especially in purchasing decision area. This is why I wrote that other post.

The myth of “knowing your org” -> know_your_org.docx

The cyber consulting world delivers a lot of useful security work. They do workshops, trainings, table top exercises, they write playbooks, red team, provide assessments, and help companies with gap analysis, system configuration and hardening.

Many of these engagements often start with some sort of a questionnaire. The customer is asked about scope of engagement, network architecture, Active Directory configuration, list of crown jewels, number of endpoints, OS/platform coverage, cloud setup, containers usage, *aaS, security controls, software, etc. The answers help consultants to tweak their deliverables to customers’ needs. They assume, rightfully so, that when they are being engaged and paid big bucks for their work, they will work with the company’s senior managements, architects, and SMEs. The company’s best.

Sometimes it is the case.

Most of the time though, there is a chaos on the other side of the fence.

I am definitely biased, but I have seen enough consulting engagements bought on a whim to conclude that many decision makers should not be responsible for spending these budgets :-). Yes, sadly, many ‘cyber leaders’ find themselves in a situation where either they need to quickly demonstrate that they are doing something useful (and hiring a consulting company is an easy OKR!), or they simply have a budget that needs to be spent. Budget either inherited from the previous leadership, or won after long battles – an asset that one cannot and should not let go. Because if you don’t spend all the money in your budget, next year you will see cuts. Not cool.

It may look like a vicious cycle, but doesn’t have to be. There is a value in these consulting gigs, but some planning needs to be done first. The number one is… documentation about your org. If you don’t have a short document that covers (on a high-level) what your company looks like from a perspective of IT/cyber, you may want to write one. This is a perfect document to share with the consulting firm when they send you their questionnaire.

The document should include:

  • contact details
  • one paragraph about the company, its M&As, possible tech debt and shadow IT
  • one paragraph about type of data being processed (employees, customers, medical, etc.)
  • list of domain names and IP ranges
  • high-level overview of environments: corp network, dev network, test network, guest network, etc.
  • high-level overview of regulated markets: US, UK, Germany, Australia, etc.
  • estimated number of non-cloud assets, ideally broken down by platform, version, function (DC, web server, email gateways, jumpboxes, windows and linux servers, workstations, laptops, etc.)
  • any dependencies on frameworks, platforms, programming languages f.ex. Java, Python
  • cloud assets: provider, estimated number of systems, their longevity, security controls present ‘out of the box’, etc.
  • high-level network architecture
  • high-level overview of the Security function, including Triage, SOC, Forensics, Threat Hunting, Threat Intelligence, Detection Engineering, Compliance, and finally Architects, Senior Management, and CISO
  • security controls in place + coverage (laptop/workstations, cloud, etc.) – firewall/WAF/proxy/AV/EDR/SIEM, etc.
  • SSO/MFA: type, provider, configuration
  • *aaS in use
  • Security Vault in use
  • Asset Inventory, SBOMs
  • List of existing security policies
  • etc.

Building such document is NOT easy. It’s a gargantuan task that needs to be sponsored from a CISO level.

And this is why Threat Intel should build it.

They are in the best position to write it and own it, because in the course of doing so, they will get to ‘know the org’. They have a vested interest in knowing all the possible company assets and their value. They will meet CISO, Senior Management, various teams, engineers, SMEs, Project Managers, Vulnerability Managers, SOC, etc.. They will build important relationships. They will leverage existing asset inventories, and validate them with Threat Hunters. They will use all this data to cross-reference information from many different sources. And once they create document like this, they will be best positioned to contextualize intel gathered from TI vendors, social media, peers.

The way many TI teams are set up today is a set up destined to fail.

So, back to the consulting gigs… If you plan to engage consultants, make your TI team build a ‘know your org.docx’ first, then work with them on how best to spend this extra dollar…