Besides the work carried out by our colleagues in the forensic analysis, malware analysis or Threat Hunting teams, which we have reviewed in the articles in this series associated with incident response, there is an additional element to be considered: the support given by the cyber intelligence teams to the above and how we in the Telefónica Tech team manage the products derived from this work. In this last part of the series, we will review the objectives of this team, the work it carries out and how the material generated is used in the framework of an incident.
What do we mean when we talk about cyber intelligence?
Establishing points of consensus on the meaning of the concepts we are going to use is always a good basis for any communication exercise and the term cyber intelligence is an example of how the use (and perhaps also the abuse) of the term can end up distorting messages and confusing objectives. To understand what we mean when we talk about the cyber intelligence team within the incident response area, what better way to start than by answering what we mean by intelligence first and cyber intelligence second.
Although there are many definitions of intelligence, a fairly consolidated reference is that contained in the Glossary of intelligence published in 2007 by the Spanish Ministry of Defence and coordinated by Miguel Ángel Esteban. On page 82, intelligence is defined as the “product resulting from the evaluation, integration, analysis and interpretation of the information gathered by an intelligence service”. Therefore, by application of the prefix cyber- we can venture to say that cyber intelligence is intelligence related to computer networks.
In any case, the basic element is that intelligence as such goes beyond data or information feeds, even if these are used to generate the final product. It is not even just a context or a list of raw links to be reviewed when the time comes. It is a concrete product intended to support specific decision making which, in the case of security incidents experienced by our customers in the context of a ransomware incident, can end up being dramatic.
Material for technicians and decision-makers
Information tends to be confused and inaccurate, especially in the first hours of an incident, until the incident begins to be contained after the planned response plan comes into play, which, if lucky, will only have been implemented conceptually or in directed drills. It is precisely in the context of this coordination and planning work that some of the target audiences for the products provided by the cyber intelligence team in the field of incident response can be identified.
- The customer’s own interlocutors. They need to have visibility as much as possible of the type of threat they are facing and to know if there is a risk of possible exfiltration beyond the visible impact in the form of encryption, for example, or how to act in the face of certain actions of the attacker that may arise. It is important that the information is on the table to be able to manage both the expectations of information recovery and to help management teams to act quickly.
- The response coordination team: the incident managers. As the organising party in an incident, they need to have visibility of the attacker’s known tactics, techniques and procedures, and potential vectors of entry and exploitation. The objective from a technical point of view is to have sufficient knowledge to operationally coordinate the necessary efforts and to be able to organise activities at the containment and investigation level, but also when coordinating forensic, log or malware analysis that may be required based on what is known about the threat and the state of the customer’s perimeter. At the same time, as part of this work it may be necessary to identify other action points that are not necessarily technical (legal, communication, etc.) but require immediate attention beyond the purely technological.
- The team in charge of conducting the investigation. Forensics, malware analysts and log analysts will find their work easier if they have a good grounding in the attacker’s tactics, techniques and procedures. Without prejudice to the more in-depth analysis that takes place during the response itself, threat intelligence reports will allow them to narrow down the initial framework of the investigation and select preliminary targets with agility, especially at the beginning of the investigation.
- The Threat Hunting team. With a very relevant specific weight in the containment of the incident as we have already seen in previous articles, this team is in charge of containing ongoing threats as soon as they are identified and identifying new subjects of investigation on which to perform triage and immediate mitigation actions for which additional context such as the techniques that the attacker is believed to have applied or the software he/she uses beyond the specific indicators of compromise is normally required.
Thus, in the framework of incident response, the deliverables of cyber intelligence teams go far beyond the mere identification of specific observables, although, of course, these are also provided. We are talking about providing technical analyst teams with specific tools that enable them to pinpoint specific malicious behaviour on the machines they are analysing and to provide the necessary support on threat behaviour in a timely manner.
Intelligence that is not shared loses effectiveness
The timeliness of the intelligence products generated has a lot to do with what we deliver and how we deliver it, but more importantly, when we deliver it and how confident we are in what we attach to our reports and deliverables. It is about making sure that the recipient will interpret what we say as it is written and unambiguously: it is a matter of speaking the same language so that sharing takes place in a structured way, with no room for doubt about what is stated forcefully and with absolute transparency to point out those aspects that need to be taken with reservations.
The work of the analyst teams is therefore no longer so much a one-off action/reaction task, but the result of continuity efforts maintained by a team that has to be aware of the threats and that has to be able to convey this information in an orderly, clear and consistent manner. And part of that work, of course, has to be done after incidents, closing the loop. Because the work of analysis does not end when the response team leaves the incident, but with the review of the lessons learned from the incident in order to integrate what has been learned into the team for the future.
In any case, if we understand communication as the transmission of signals by means of a code common to the sender and receiver, establishing a common framework on the level of trust is fundamental. This is what the STIX intelligence sharing standard (currently in version 2.1) does in the definition of the confidence attribute with which each of its objects can be catalogued between 0 and 100 using different credibility scales such as the one known as the admiral’s scale proposed in the US Army’s Field Manual 2-22.3.
The aim of these scales is to give the analyst the possibility of expressing different degrees of certainty about each object and to avoid failing to document behaviour for fear of having to take a binary assessment (confirmed/unconfirmed). Thus, the fact that there is evidence with questionable credibility at a given moment is relevant because only if it is documented and recorded will it be possible to correlate it in the future, which reminds us of the importance of the time factor when making the assessments included in the reports.
Time factor
It is clear that an intelligence unit will accumulate knowledge over the years that can be built up and integrated for the future. Storing it in a consistent and reusable way is critical as we have seen, especially if it is to be available just when it is most needed in the form it is needed. But in incident response, the pressure and timing of decision-making is decisive.
Indeed, one of the aspects that most differentiates the analytical professional in incident response from a purely academic or research profile is that he or she works precisely against the clock and under uncertainty. Those dealing with the reality of an incident must cope with the gradual arrival of information, the unavailability of some of it when it is most needed, and the pressure being experienced by a client who is inundated with calls from concerned customers and suppliers and who has to meet statutory reporting obligations. All this while trying to contain a threat whose impact is only hinted at by the massive encryption of computers and while trying to ensure that backups and systems are impacted as little as possible.
In academic research, the urgency is not as immediate and with days or weeks to spare we have more options to review the details of all the scenarios, look at them in depth and learn accordingly. The reality of an incident where our clients have factories or entire areas shut down is unfortunately much more dramatic. It includes Hunting colleagues with specific operational needs that cannot be extended in the form of indicators and behaviours to block and forensic colleagues who need context and clues on which machines to start the search for patient 0 and to understand how, why and up to what extent the threat occurred.
This is where time – understood both in terms of effort and timeframe – is key to getting tactics, techniques and procedures known from similar threats to their intended audience: both at the operational level for containment and mitigation, and at the strategic level to support the decision-maker on the possible scenarios that lie ahead. It is right there, when things don’t seem to be working, where the different areas of the response team can help working side by side to recover that longed-for normality. Against the clock, but right in time.
