Communicating Intelligence: Getting the message out

In my previous blog I discussed some of the challenges associated with communicating intelligence. In this follow up piece, I’ll explain some of the methods we use here at Digital Shadows (now ReliaQuest) and provide examples. If intelligence cannot effectively communicate, then it not only reduces its utility, it can mislead the consumer, and even increase the threat to an organisation.

To ensure that our clients can get maximum value from our product, we strive to make our intelligence as accessible as possible. We have an online portal which our clients can ‘pull’ our intelligence from. We also have email alerts that can be configured through our portal, a reporting module that can be used to create customised reports, and an API for integrating with SIEM platforms. Lastly, we have intelligence summaries that clients can subscribe too and receive via email, or through our portal.

The example in Figure 1 is a screen shot from our portal of an intelligence incident as a client would see it. Here we have the source of the incident at the top of the screen, including the URL and a snippet – we like to be transparent with our sources. At the top right we also include a severity rating, which gives the reader a quick indication of whether an incident is important or not. Below severity we have a screen shot of the source URL, as well as STIX/TAXI tags, which can be used to search for similar incidents. Also included is a link to our profile related to this incident (in this case the Patreon breach), which is where consumers can find further information on an entity, as well as view our other related reporting. Lastly, we have a function to export this incident to PDF, and to provide feedback. This enables users to quickly share intelligence with colleagues and to update us on the utility of the intelligence we provide. We’ve designed these details to be as intuitive and accessible as possible, thereby removing obstacles between the consumer and the product.

Figure 1

On the left of the incident screen we have the full incident content written by our analysts. This consists of four headings; summary (‘bottom line up front’ for busy readers), description (providing an overview of the incident), assessment (giving our insight and valuable ‘so what’), and lastly our source evaluation. We’re striving to provide a clear and concise product, whilst also including the required depth and transparency. This must also be easy to consume, and informative for the reader. We know our readers are busy people, and we work hard to summarise and keep our word counts as low as possible.

Our clients value specificity in our intelligence, and if an incident directly affects them, for instance, if they were part of a breach, we would also include an assessment of the impact to that organisation, as well as mitigation advice. We work hard in this area to ensure that the ‘so what’ from our intelligence is clear, and that there is always an actionable element to our product.

To help our clients receive these incidents, users can configure email alerts based on a combination of incident type and severity. This helps get the intelligence product quickly to the right people.

As well as this, clients can also subscribe to combinations of STIX/TAXI tags and severity used in our threat intelligence incidents. For instance: Financial Services (target sector) AND Malware (TTP category) AND United Kingdom (target geography). Thereby allowing them to focus on the intelligence which is truly relevant to them. Less noise, more signal.

Our intention is that clients can consume our intelligence in the most efficient way, therefore reducing ignorance in their decision making, and helping them defend against the bad guys. For us, intelligence should be seen as an enabler to operations and communicating it effectively is critical for this.

In my next blog, I’ll talk through how we communicate our intelligence base products, including profiles and our weekly intelligence summary.