Detect Cyber Events

by | Jul 15, 2021

All ransomware has something in common: as it interacts with the host it is trying to lock down, without fail it triggers host logs and network logs that can be used to detect the malicious activity. Unless, that is, the appliances and software responsible for generating those logs were never properly configured. What follows is an overview of the research you will need to do and the kinds of resources you will need to put in place to generate and gather meaningful and sufficient cyber event data.

Introduction

In cybersecurity, “detection” is a loaded term. In the context of NIST’s overarching Cybersecurity Framework, detection includes noticing potentially malicious activity, analyzing what has happened in more detail, and reaching final conclusions about what has happened. There is a lot going on there, all in a single stage. You will notice that data collection, which is a prerequisite for detecting anything within the data, is assumed and not specifically spelled out. For the purposes of our discussion, it is useful to consider the following flow, which is based on NIST’s Incident Response framework but is more granular:

Preparation > Collection > Analysis

Preparation

For our purposes, preparation is all about knowing your organization and your network:

  • First, determine your high value assets and mission essential functions, using a methodology such as Crown Jewels Analysis.
  • Knowing what is normal behavior on your network.
  • Training your team on how to use the tools at their disposal and how to interpret and act on alerts
  • Whitelisting:
    • Who are the authorized users on the network?
    • Which activities are permitted by which user roles?
    • Which hostname and IP addresses are expected to be seen on the intranet?
    • Which hosts are allowed to reach out to the internet?

Preparation is not a one-size-fits-all formula; what is important is to grasp the spirit of preparation and create documentation that makes sense for your organization. It is possible to catch some malicious activity without having done the type of preparation defined here, simply by deploying canned products and analytics. However, skipping this work will reduce your success rate and will also make remediation of an event more confusing, slow, and difficult.

Preparation can also include understanding adversary behavior. Knowing this information can help you identify what to look for and where to look for it. This type of preparation is described in greater depth in the Cyber Threat Intelligence resource page.

Collection

This is the collection and aggregation of raw network and host events: an unfiltered view into what is happening on your network. Which process are running, who is logging in, what kinds of packets are being sent from where to where – all of these questions and more should be answered by the data you collect. This data is gathered from sensors, which are utilities, services, or pieces of hardware on your network that sense what is happening and package the information into “events” that you can read and analyze. Typical sensors include:

Firewalls

Firewalls not only block suspicious traffic, but produce logs of what they’ve seen that can be a rich resource for security analysts.

Network Intrusion Detection Systems (NIDS)

Commonly known Free Open-source (FOSS) NIDS include Snort, Suricata, and Zeek. While similar to a firewall, they are out-of-band and can be placed anywhere within your network. They are designed to produce alerts that can be a great starting point for investigations. They can also be configured to give you metadata for every flow on your network, malicious or not, which gives you tremendous visibility into what is happening on your network.

Windows Event Logs

These host logs are incredibly detailed and can be configured to alert you to almost any kind of activity on a particular computer, ranging from a user logging in, to a process spawning, to a registry key being modified.

Auditd

While not as detailed, Auditd logs serve much the same purpose as Windows Event Logs, on Linux systems.

Sysmon

This after-market security tool offers alerts for critical host events such as process creation, in a more distilled format than what is offered by Windows Event Logs.

Endpoint Detection and Response (EDR) or Host Intrusion Detection System (HIDS)

An EDR is essentially a next-generation anti-virus platform that lives on each host in your network and catches malicious activity as it happens. This software typically can be configured to generate detailed logs, which are a valuable source of information to catch hackers as they try to move laterally in your network. Most of these platforms are paid, proprietary software, but they can be well worth it. Windows Defender is an example of an EDR that just happens to be built into the operating system.

While do not have to have every log type listed above, the more diversity of logs you have, the more effective your analysis will be. Data from all your sensors typically should be aggregated together in one place, in a normalized schema and time zone, so that you can reference and correlate all the logs conveniently. Most organizations choose to use a Security Information and Event Management (SIEM) platform, which is designed for storing and viewing these logs. Open source examples include Elastic SIEM and Apache Metron. To get all your logs into your SIEM, you will have to configure pipelines, or shippers, that send each log type from its place of origin to your SIEM. The best way to do this varies with each SIEM.

Analysis

Once you have logs consistently flowing into your SIEM, you are ready to analyze them, which is the most important part of Detection! Refer to Health Cyber’s Analytics page for resources and a step-by-step guide for deploying open source analytics on your data.

To learn how to gain more insight into your detections, refer to the Cyber Threat Intelligence page.

Resources:

Pin It on Pinterest