Traffic Light Protocol (TLP) is a pretty universal term these days, especially as STIX/TAXII is gaining momentum within the *-ISAC communities. However, for completeness its a sensitivity marking term which determines “with whom” and “how far” information can be shared and in most cases is dictated by the Source of the information. Sharing information is a very powerful weapon for defenders^[1] but as with everything there are sharing guidelines to follow to ensure (as much as possible) that the information is dealt with in a responsible manner and does not tip off the adversary (i.e. submitting targeted malware to VirusTotal or extensive research on a C2 domain).  Why you may ask?  Most mildly professional adversaries, regardless of motivation, monitor open source channels for signs their attack(s) have been identified and their malicious infrastructure is burned.

A slight but purposeful derailment, as an example, when Mandiant released their APT1 Report – the sharing of indicators and TTPs unequivocally helped the security industry realize nation-state intrusions were happening at an alarming rate and helped organizations take back their environment.  As a result of the publication of the APT1 report, APT1 went dark as they knew the security industry and public spotlight was on them.  More advanced organizations who were tracking them before the APT1 Report did get a bit worried as, at the time, it was unknown how the adversary would respond – fade into darkness?  Completely pivot TTPs?  Completely pivot IOCs?  However, luckily as APT1’s mission did not change significantly the attacks did pick back up and even saw an increase – assuming to meet their mission quotas. </end derailment rant>

As previously mentioned “responsible sharing” allows the Source of the information to determine who the downstream recipients can, in turn, share that information with.  The most common TLP categories used throughout the industry are defined by the US-CERT and are broken down into 4 categories including Red, Amber, Green, and White. Basically recipients of information containing associated TLP markings have a moral obligation to:

• Conform to the rules
• Not change the TLP markings and
• Receive explicit permission from the Source if they would like to share to a broader audience

So what is different about ThreatQ’s TLP implementation?!  At the heart of our TLP capability is our ability to de-duplicate, consolidate, and inherit the necessary sensitive markings.  This is critical because we designed the object itself (aka Indicator, Adversary, Event, etc.) to inherit the contextual attribute’s TLP value.  For example, if ThreatQ has an indicator [ex 185.158.115.7] that has been disclosed by multiple Sources each with additional context AND with varying TLP markings then the IP address itself with have multiple TLPs allowing ThreatQ to map each piece of additional contextual data to that Source’s TLP category.  So when that indicator is exported to the sensor grid [reference old blogs] or shared with another downstream organization the IP address will “inherit” whichever TLP is applicable based on the user’s needs (and will not break TLP).

Let’s take a deeper look at how this works:

If we take a quick glance at the IP address 185.158.115.7 it has been published by 6 unique sources with 68 supporting contextual pieces of information having a mix of TLP markings.

Figure 1 – an IP address with 68 additional attributes

However, that IP address was shared by 6 unique sources with varying TLP markings.  So in the ThreatQ Threat Library the IP address can “inherit” any of the associated TLP markings based on what the analyst needs and only include the associate attributes.  This allows them to share/export intelligence cleanly without explicitly or accidentally breaking TLP obligations.

To highlight TLP inheritance, let’s explore the ThreatQ Export page to create an export per TLP to demonstrate TQ’s TLP inheritance.  When an analyst exports or shares the intelligence it resembles something like this:

White:

Figure 2 – an example of white TLP

Amber (which is typically a yellow shade…just to confuse EVERYBODY):

Figure 3 – an example of Amber TLP

Red:

Figure 4 – an example of Red TLP (with sensitive Attribute values obfuscated – practice what you preach)

Other products cannot easily manage this because they do NOT de-duplicate data or at least NOT across their segmented communities.  So, in other platforms 185.158.115.7 has a different record per Source or Event – potentially across siloed communities.  This causes several major pain points, but more so, increases the probability of breaking TLP by ‘accidentally sharing’ information infringing on contractual or informal obligations associated with TLP.  Yikes!! 

^[1] When done selectively in both a ‘trust and verify methodology’ and by a trusted source with an above average track record for sharing timely and accurate information.