Detections of Past, Present, and Future

There are countless blog posts specifically focusing on how different techniques work and recommending building detections, however, there is an often overlooked aspect of building detections. Outside of the typical core focus of what a detection is looking for, when is the detection looking? The perspective of time is something that can easily be lost between the person designing the detection or analytic and the assumption by an organization of what is actually being detected.

Too often, an alert will be built to specifically detect a new occurrence of a malicious technique… only to find out a few days/weeks/months later that the initial infection or action began prior to building the detection and therefore, no “alert” was generated.

The reality is that there are several different time frames which should be considered when building detections in order to properly focus the effort.

Past: Has this already happened?

Present: Is this happening now?

Future: Will we know if this happens?

Past — Has this ever happened before?

Just like in real life, you can’t change the past, you can only look back and reflect on what has already happened. For building detections, this means that you are limited by data retention; you can only look back as far as you have saved your data. Additionally, assuming the data was retained, you are further limited to the specific data collected at that time. If there was any limitation in the logging of the organization during that time… you’re out of luck. Since we are in the past, there is not an option to fill in any additional information which was not logged; the past was the past and the present is the present. Finally, an important consideration is that as time goes on, things can change which may limit the utility of the past data. Things like websites, IP addresses, or files can all change over time and no longer match what was accessed during the original event.

Why is this important? The answer to the question of “has this happened before” will only be as accurate as the data collection and retention plan present in an organization. While you cannot go back in time and change what was collected in the past, the present data collection and retention eventually becomes the past, so plan accordingly to set yourself up for success.

TL;DR for detections of the past

What data did you collect?

How long do you store said data?

Is the data still relevant today?

Present — Is this happening now?

When considering the present, immediate access to data across the environment is of utmost importance. In the present, we are trying to obtain current information about the network or endpoints. Answering a question in the present is completely dependent upon the flexibility of existing tooling in the environment to rapidly provide the desired information on demand. Additionally, connectivity is a major consideration with assessing the present state. If laptops are used in the environment, any system “in transit” between networks will not be able to provide the desired information, causing a blind spot in the assessment of the present.

The tooling required to gather this on-demand must be configured prior to the requirement for the information. In the case of using an installed agent EDR-like solution, the agent needs to be properly installed and configured on all endpoints. If using an agentless query format such as Windows Management Instrumentation (WMI) or PowerShell remoting, you have to ensure that you have the necessary credentials and configuration of systems in the environment to be able to query for the desired information. Next, an understanding of how the EDR functions in gathering data is required. Is data available in real time or only based on a schedule? Can ad-hoc information be gathered or only use pre-defined collection mechanisms? Finally, the ability to actually collect desired information at scale needs to be validated, not assumed.

Assuming the information desired was actively being logged, this problem could seemingly be easily addressed by searching through a SIEM to find the answer, similar to detecting things in the past. However, data does not always make it into a SIEM in a timely manner, nor is all the information always being collected/parsed in a fashion which makes it usable for an analyst. Data in the SIEM is going to be influenced by the complete data ingestion pipeline and collection process, which is not guaranteed to provide information about what is occurring at this exact moment.

Answering the question about present compromise is often overlooked as if you wait… the present becomes the past. While not necessarily a problem, the need to immediately validate something across the enterprise may arise at some point and in that situation it is important to have an understanding of what is required to actually fill that requirement.

TL;DR for detections of the present

What access do you have to all systems?

What tooling do you have available on all systems?

Future — Will we know if this happens?

We finally get to the area where the majority of detections are based… though not always deliberately. This is the stereotypical “detection building” goal, to build something that will detect if/when something malicious happens in the environment in the future.

Just like with the real world, the future is built upon the past and present. We will assume that you have deliberately designed a data collection and retention plan (supporting detections of the past) and the necessary tooling to gather information you need (supporting detections of the present). What more could you need to detect activity in the future?

When building detections for the future, it is imperative to have well built and documented alerting with equally well built and documented response processes. If a detection is built which will fire when the activity of interest occurs in the future, however there is not a corresponding process to ensure that alert is investigated through to completion… we may as well not have had the detection in the first place.

The final aspect of detections for the future is change. As the old adage goes, “the only constant is change”, which is especially true within information security. Therefore, detections for the future must be built to account for said change to occur within the organization. Detections should be built with some mechanism of validation in mind to ensure that future changes do not make an alert irrelevant without knowledge of that within the organization. If there are dependencies upon specific data sources or tools, those should be documented. This helps to limit unintended side effects of changes within the environment unknowingly impacting detection posture.

TL;DR for detections of the future

What dependencies do detections have?

What is the alerting and response process?

How are detections tested over time?

Conclusion

The ability to build a detection for the full lifecycle (past, present, and future) requires deliberate effort and a strong understanding of both the current technology within an organization as well as the policies surrounding data collection and tooling. When developing a detection, there should be thought put into not just the technique that is intended to be detected by the analytic, but also which timeframe the detection will alert on. If there is a lack of data to build “past detections” or a lack of tooling supporting “present detections”, then don’t waste time focusing on those areas. Instead focus on understanding and mitigating the limitations that poses to the overall security of an organization. Deliberately build detections that fill the specific needs and concerns of your environment and document when and where there are shortfalls.