Using SensorFu Beacon to supplement Threat Intel

SensorFu Beacon can be used effectively to supplement (cyber) threat intelligence (TI). With our example use case, we open couple of ideas how to facilitate understanding threats organizations may observe with Beacon and further utilize such data as part of their TI ecosystem. When bulk data becomes actionable information, organization is able to utilize understanding of their assets in very different ways compared to just data without context.

SensorFu Beacon basic use case

To understand how SensorFu Beacon can be part of the organizations threat intelligence ecosystem, we must first understand how Beacon works.

In this example, we have use case in which SensorFu Beacon has been deployed to network (LIEKSA_CRM_DEFENCE_VLAN) as virtual machine, named as BEACON2. The Home — which Beacon is trying to reach is somewhere outside of the Lieksa network(s), most likely on Internet.

Figure 1: Our example of GLOBAL SALES organization at Lieksa with Critical asset of CRM

Type of Beacon may span from physical device like Raspberry Pi, Virtual Machine to Windows or Linux Application, the capabilities remain mostly same on threat intelligence point of view.

The basic use case used in our example is as follows:

1. SensorFu Beacon tries to find breakout towards Home.
2. When Home is reached via some of the techniques available, Home creates observation of it.
3. Observation(s) contain information of Beacon which reached Home including unique identifier, time, protocol and breakout type.
4. Observation(s) can be further processed and are available via syslog or API.

Difference of Indication of Compromise (IOC) and Indication of Threat in SensorFu Beacon context

In our use case, Beacon delivers information if our host is able to reach Home via some of the breakout techniques used. This information can be seen as Indication of Threat from Threat Intelligence point of view.

In our example, some of the notables include:

• In our case, BEACON2 resides as a Virtual Machine on LIEKSA_CRM_DEFENCE_VLAN which is asset to organization. This could mean lots of different things, however, our organization has defined such asset (the VLAN in question) to be Critical in nature. Containing customer CRM data, there are liabilities and thus any access outside the VLAN is possessing a threat to organization and possible sanctions.
• When looking into BEACON2 behavior more closely, we can see that the actual breakout technique used to bypass security controls over LIEKSA_CRM_DEFENCE_VLAN was using DNS. The VLAN is categorized as Critical, meaning in our use case example environment should use dedicated DNS hosted inside of the secured network, without any recursions or iterations possible towards outside from the network. This leads to environment security design principles or controls being misaligned against threats, knowingly or by mishap.

Figure 2: Drilldown to BEACON2 event with DNS breakout tactics used. The reference set is included in SensorFu App For Splunk.

NONE of these threats mentioned are actually IOC’s that can be seen as malicious perpetrator utilizing vulnerabilities, however — knowing such breach is possible serves value as threat information. In addition, it is possible that our critical asset (the VLAN in question) leaked due the configuration error. The result is same — such observation provided information organization has severe (critical) threat that should be mitigated. Furthermore, people responsible of possible configuration mistakes can effectively co-ordinate repairs.

Observations as Threat Intel information

What could Observations then mean as a Threat Intel Information?

When thinking about organization assets, such as servers, they typically include amount of exposure, vulnerabilities, data and usage (methods & interfaces) of the system.

Taking the two previous notables, we can summarize that:

1. Critical asset (LIEKSA_CRM_DEFENCE_VLAN) is possible to breach with DNS
2. Based on the asset criticality and name — it is possible to exfiltrate information out from network (example: CRM data from vulnerable server located on same network) by using DNS.
3. It may be possible to control systems (via C2) residing the secure network.
4. It may be possible to pivot or use such network as part of the lateral movement within the organization.

Figure 3: Example of indication chain (SensorFu Beacon App for Splunk)

What it means?

Our example shows that going beyond basic threat intelligence, where e.g. IP addresses are the IoCs, adds value. Organizations should add understanding of behavior of their assets and breaches as part of the threat information.

Figure 4: SensorFu to supplement Threat Intel feeds; CSV as example.

By using SensorFu observations to supplement threat intel, this could mean adding information of indications retrieved from Home, supplementing with asset details, criticality and type of breach from observations.

The example above (Figure 4) shows plain and simple addition to CSV based threat feed summary.

However, somewhat more accurate results can be achieved if actual information systems, such as CRM in our example has some sort of an entry in asset management or in configuration management database to supplement such information directly.

About impact assessment — instead of having certain asset, like VLAN defined as “Critical” from impact point of view — we could define that asset “THIS HOST” having SensorFu Beacon Windows or Linux Application combined with breach type like “DNS” from ANY of the networks should be categorized as “Better call Cavalry” — type of incident. Maneuvering around threats greatly depends how organizations manage threats in general, however SensorFu Beacon is able to supplement TI in many ways.

In bigger picture, organizations should move forward to more tightly integrating asset management, threat intel and observation mechanisms. Your organizations assets matter in making threat data into actual intelligence.