Threat intelligence “know thyself”

I worry about the over use of threat intelligence. The idea of intelligence came to the information technology space in the early 1990s and many from the intelligence world and the information technology community scoffed at the idea. In the current form we have is a fusion of risk management paradigm and a data analytics paradigm.

equation

Risk heuristic

Where the concept of a risk management heuristic is bounced off the metrics and analysis mechanisms.

equation2

Threat heuristic

Where threats are external actors, entities, or events and intelligence is the acquisition of knowledge, concepts, and evidence. We end up fusing that into some kind of holistic formulation and area is fairly wide open. Enterprise risk management requires a set of metrics and capabilities to evaluate current and near future events. Unfortunately metrics and actual numbers applied to an environment is usually side lined by “new shiny” and FUD.

The first step for any enterprise should not be buying a “feed” or reading a bunch of reports that don’t reflect your actor, entity, event risks. The first step for an enterprise is to know itself. A good historical accounting of what has happened, what exists, and what might happen is more important than “new shiny”.
How?

Enterprise know thyself. If you don’t have a good idea about your enterprise and what exists within that enterprise any threat intelligence product will be useless. The first thing is to have a good network map whether it is fractal representation with exceptions noted or an entire map is up to the particular enterprise. You can use your #DFIR after action reports to inform what has broke, and what has been investigated.

In the process of defining internal processes to know the enterprise domain the #DFIR team is of paramount importance. Threat intelligence that is enterprise focused and utilizes the metrics that should already be in existence are a best practice. If the security team is engaged in using a HoneyNet or HoneyPot for adaptive detection of adversaries then that should be an evidence feed to the incident response entities of the enterprise.

The concept is to focus on the past to inform the now. Once and only when you have a handle on the now should you try and move into the future. Analysis in the intelligence field is based on sensors and signals from the environment. In the information security field we look primarily to technical acquisition. That is like operating the network with a blind eye and somebody pokes you in the good eye. There are a variety of books on open source intelligence analysis that should give you a much broader conceptual understanding than simple technical intelligence.

If you can’t write down on a whiteboard 10 adversarial actors to your enterprise you are not thinking deep enough. For each adversary you should be able to pinpoint targets. Model the primary channels of access and then look for sideways access. Examples of sideways access include things like shipping or order fulfillment systems that check credit card approval status. Oh yeah that system! Once again your #DFIR team can be a great addition to the gaining of evidence (not probative but still important).

At some companies they maintain a threat briefing for general counsel and their board of directors. At an unnamed company I looked their very technically astute report on current threats to the enterprise. I asked them what was the cause of their three biggest unexpected outages. In two cases it was weather. Yet their report didn’t even mention weather going out to any level of planning. A focus on the bits and bytes misses lighting and floods.

Modeling adversary access attempts to the organization takes some skill. You will never do this perfectly. It is difficult to get people to understand that an adversary does not have to work within your rules, procedures, or capabilities. That freedom allows them to analyze and evaluate how to work outside our organizational structure and use enterprise risk to their advantage. This kind of analysis does not come in a threat feed. It is not a list of IPs and most assuredly it isn’t something you should be sending outside of your organization.
There is a maturity process in place that becomes fairly obvious. If you can work from past to current to future the maturity path is well formed. Trying to jump through this analysis without having a good grounding in each step will only cause issues and denigrate from the upper levels.
To be sure the first step in any threat intelligence process is “know thyself”.

Leave a Reply