🥇TS Total Sight. Event Collection, Incident Analysis, and Threat Response Automation

Good afternoon, in previous articles we got acquainted with the work of the ELK Stack. And now we will discuss the possibilities that can be realized by an information security specialist in using these systems. What logs can and should be added to elasticsearch. Let's consider what statistics can be obtained by setting up dashboards and whether there is a profit in this. How can I implement automation of information security processes using the ELK stack. Let's create the architecture of the system. In sum, the implementation of all the functionality is a very big and difficult task, so the solution was given a separate name - TS Total Sight.

Currently, solutions that consolidate and analyze information security incidents in one logical place are gaining popularity, as a result, a specialist receives statistics and a front for action to improve the state of information security in an organization. We set ourselves such a task in using the ELK stack, as a result, we singled out the main functionality in 4 sections:

Statistics and visualization;
IS incident detection;
Prioritization of incidents;
Automation of information security processes.

Let's take a closer look at each one in more detail.

Information security incident detection

The main task in using elasticsearch in our case is to collect only information security incidents. You can collect information security incidents from any means of protection if they support at least some log transfer modes, the standard one is syslog or scp saving to a file.

You can give standard examples of protection tools and not only from where you should configure the forwarding of logs:

Any NGFW funds (Check Point, Fortinet);
Any vulnerability scanners (PT Scanner, OpenVas);
Web Application Firewall (PTAF);
Netflow analyzers (Flowmon, Cisco StealthWatch);
AD server.

Once you have set up Logstash to send logs and configuration files, you can correlate and compare with incidents coming from various security tools. To do this, it is convenient to use indexes, in which we will store all incidents related to a particular device. In other words, one index is all incidents for one device. This distribution can be implemented in two ways.

First option is to configure Logstash config. To do this, you need to duplicate the log for certain fields into a separate unit with a different type. And then later use this type. The example clones logs from the IPS blade of the Check Point firewall.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

In order to store such events in a separate index depending on the fields of the logs, for example, such as the Destination IP of the attack signature. You can use a similar construction:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",<IP_address_elasticsearch>:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

And in this way, you can save all incidents to the index, for example, by IP address, or by the domain name of the machine. In this case, we store in the index "smartdefense-%{dst}", by the IP address of the signature destination.

However, different products will have different log fields, resulting in chaos and wasted memory. And here it will be necessary either to carefully replace the fields in the Logstash config settings with pre-designed ones, which will be the same for all types of incidents, which is also a difficult task.

Second implementation option - this is writing a script or process that will access the elastic base in real time, pull out the necessary incidents, and save them to a new index, this is a difficult task, but it allows you to work with the logs as you please, and correlate directly with incidents from others security tools. This option allows you to customize the work with logs as useful as possible for your case with maximum flexibility, but here there is a problem in finding a specialist who can implement this.

And, of course, the most important question what can be correlated and detected?

There may be several options here, and depending on what security tools are used in your infrastructure, a couple of examples:

The most obvious and from my point of view the most interesting option for those who have an NGFW solution and a vulnerability scanner. This is a comparison of IPS logs and vulnerability scan results. If an attack was detected (not blocked) by the IPS system, and this vulnerability is not closed on the end machine based on the results of the scan, it is necessary to blow all pipes, since there is a high probability that the vulnerability was exploited.
Many login attempts from one machine to different places can symbolize malicious activity.
Downloading of virus files by the user due to visiting a huge number of potentially dangerous sites.

Statistics and visualization

The most obvious and understandable purpose of the ELK Stack is the storage and visualization of logs, in past articles it was shown how you can get logs from various devices using Logstash. After the logs go to Elasticsearch, you can set up dashboards, which were also mentioned in past articles, with the information and statistics you need through visualization.

examples:

Dashboard of Threat Prevention events with the most critical events. Here you can reflect which IPS signatures were detected, where they come from geographically.
Dashboard on the use of the most critical applications for which information can be leaked.
Scan results from any security scanner.
Logs from Active Directory by users.
VPN connection dashboard.

In this case, if you set up dashboards to update every few seconds, you can get a fairly convenient system for monitoring events in real time, which can then be used to respond to information security incidents as quickly as possible if you put dashboards on a separate screen.

Incident prioritization

In conditions of a large infrastructure, the number of incidents can go off scale, and specialists will not have time to analyze all incidents in time. In this case, it is necessary first of all to single out only those incidents that carry a great threat. Therefore, the system must prioritize incidents according to their severity in relation to your infrastructure. It is advisable to set up a notification in the mail or telegrams of these events. Prioritization can be implemented using regular Kibana tools, by setting up visualization. But with a notification it’s harder, by default this functionality is not included in the basic version of Elasticsearch, only in the paid one. Therefore, either buy a paid version, or, again, write a process yourself that will notify specialists in real time by mail or telegram.

Automation of information security processes

And one of the most interesting parts is the automation of actions for information security incidents. Previously, we implemented this functionality for Splunk, you can read a little more in this article. The basic idea is that the IPS policy is never tested or optimized, although in some cases it is an essential part of information security processes. For example, a year after the implementation of NGFW and the absence of actions to optimize IPS, you will accumulate a large number of signatures with the Detect action that will not be blocked, which greatly reduces the state of information security in the organization. Here are some examples of what can be automated:

Switching the IPS signature from Detect to Prevent. If Prevent does not work on critical signatures, then this is out of order, and a serious breach in the protection system. We change the action in the policy to such signatures. This functionality can be implemented if the NGFW device has the REST API functionality. This is only possible if you have programming skills, you need to pull out the necessary information from Elastcisearch and execute API requests to the NGFW control server.
If a lot of signatures were detected or blocked in network traffic from one IP address, then it makes sense to block this IP address for some time in the Firewall policy. The implementation also consists of using the REST API.
Launch a host scan with a vulnerability scanner if this host has a large number of signatures for IPS or other security tools, if it is OpenVas, then you can write a script that will connect via ssh to the security scanner and run the scan.

TS Total Sight

In sum, the implementation of all the functionality is a very large and difficult task. Without programming skills, you can set up the minimum functionality, which may be enough for use in productivity. But if you are interested in all the functionality, you can pay attention to TS Total Sight. You can find more details on our Online. As a result, the whole scheme of work and architecture will look like this:

Conclusion

We looked at what can be implemented using the ELK Stack. In subsequent articles, we will separately consider in more detail the functionality of TS Total Sight!

So stay tunedTelegram, Facebook, VK, TS Solution Blog), Yandex Zen.

Source: habr.com

TS Total Sight. Event Collection, Incident Analysis, and Threat Response Automation Tool