– Internal incident data
– Honeypots & the like
– Vendor reports
– Sharing communities
– Free IOC feeds
– Paid IOC feeds
I like this list because it covers automated machine-based collection—internal data, honeypots, and IOC feeds—and analyst-based, human collection: vendor reports and sharing communities. Analysts have to critically read and process reports and must dedicate time to developing external relationships, building trust. These tasks cannot be automated.
Similar to these “analyst-based” sources (which I suppose we could call, but which I’ll refrain from calling, HUMINT), I would add an additional source: internal IT and IT security staff.
By this source, I mean those staff outside of the SOC where the core detection, response, and intelligence functions live. Every organization is different, of course, but other security functions such as security architecture, vulnerability management, asset and content management, application testing, and engineering, may live in the IT shop, not in the security shop.
So, why is it important to highlight this (seemingly obvious) source?
Because threat intelligence analysts face a unique challenge: we are responsible not only for understanding external threats and enabling defenders, but also for communicating to strategic customers how those threats could affect the organization. Making these assessments demands a rich understanding of the business, its technology, its assets, vulnerabilities, and its network architecture. This is hard to do.
In my experience, it is not uncommon for intelligence teams to make assessments based on assumptions about what hardware and software make up the attack surface. We seem to know more about the external threats than the shape of the businesses we are trying to protect.
This is why threat intelligence analysts need to build trusted relationships with external communities and with internal teams. Internal teams are a valuable source. Often times these relationships exist as tribal knowledge. “Oh yea, just talk to Jane in architecture – she can tell you about our Cisco router configurations.”
Instead, take the time to adopt a more formal approach just as you do with your technical sources. Keep a list of your trusted internal contacts on your team’s wiki or in your personal notebook. Meet with them regularly. Pick up the phone and ask them questions. Knowledge from these other teams helps refine and increase confidence in the intel team’s analyses. And, when their insights inform your analysis, cite them in your report (e.g., “Conversation with Jane – IT Architecture, June 1, 2016”). I admit there may be organizational sensitivity in doing this, but consider it just one possible way of more formally managing internal sources.
Even better, regular contact will these teams will help analysts establish and refine requirements. Through one of your regular meetings, maybe you learn from Ted in IT that Windows gold loads will no longer support Flash. This insight will affect the intelligence team’s priorities.
Threat intelligence isn’t just about the data. It’s also about the relationships we develop externally and internally.