Attack Detection System
ADS is a SEM-class (Security Event Management) product whose purpose is to acquire, correlate and present incidents accompanying cyber-attacks carried out from the outside as well as within the organization.
SEM system definition
The key goal of SEM systems is to function as a center for collecting and processing the data obtained from logs generated by other systems, i.e. firewalls, database servers, domain controllers, or application servers.
The system pays special attention on information which may directly point to events presenting a probable attempt to breach the clients security. SEM correlates the data significant from the security point of view and presents it to the operators of a given system. Its central console allows the data to be presented in one place, allowing for a prompt response and minimizing losses incurred due to a breach in security both on the systems present on the edge of the corporate network, and on client stations or file or application servers.
How is SEM different from SIEM?
SIEM is a blend of two acronyms, i.e. SIM and SEM. SIM-class solutions collect, archive and generate alerts based on logs delivered by other systems where the correlation system is limited to the minimum. Moreover, with the SIM systems the stress is put predominantly on long periods of log retention. Their characteristics resemble these of log management systems. SEM systems, in contrast, are oriented towards analyzing logs in search of incidents. Operators receive alerts with a risk level indication resulting from the correlation collected and normalized logs.
Currently, SIEM systems attempt to bridge the two functionalities ensuring long log retention and a correlation engine based on elaborate database inquiries. As a result, SIEM systems are sophisticated solutions and the implementation cost is considerably higher than that of a SEM system.
How does ADS stand out from peer solutions available on the market?
The SEM-class ADS system we are offering has been designed by STM Cyber in response to the market demand for a tool intended for analyzing security-related incidents. It balances relatively low implementation cost with high adaptability to the Customer’s production environment. Experience gained through running penetration tests, the ADS correlation rules have been adjusted t current techniques employed in performing cyber-attacks. The rules are additionally enriched with information acquired through analyzing log traces left by potential attackers. Departing from the classic approach of gathering all logs from all available devices resulted in considerable savings in implementation and minimize problems resulting in stemming from communication with other systems. ADS is based on open source software and the codes for particular connectors is made available to the Client on a case by case basis.
Furthermore, an undeniable benefit of such a solution is that the STM Cyber department in charge of product development and upgrades is located in Poland, which enables us to guarantee direct contact and individual approach to actual needs of each Client.
The diagram below represents the ADS architecture indicating the direction of data flow between particular components and log sources:
ADS architecture has been divided into three areas, each of which is realized on a separate server in a manner maximizing the performance of every component.
In the further section we present a description of each area, including the explanation of the principles of information flow between particular infrastructure elements.
Honeypot – controlled attack detection
The ADS system includes modules related to an environment detecting security breach in a controlled way – so-called. honeypots. There are three honeypot types available:
Component design makes it relatively easy to perform a successful attack, however, advanced enough to ensure the attacker possesses specialized knowledge. These assumptions help eliminate people performing attacks simply for fun from those whose actions aimed at a particular organization (a profiled attack).
The honeypot network is separated from the Client’s production area in order to prevent the latter from being penetrated. The honeypot architecture has been designed to allow an attacker to gain access to the network (WiFi or DMZ honeypot) getting the impression of accessing the industrial automation network (the SCADA module). The task of each honeypot is to emulate genuine traffic and data from the devices in order to support the credibility of it being the Client’s actual network.
Typically, having gained access, the attacker starts browsing the devices/machines in search of any valuable data, such as network documentation or infrastructure. In the process of honeypot implementation, we cooperate with the Client in creating documents intended to direct the attacker to physical contact with the company’s infrastructure. For instance, the event may be documentation including data on a service box located by the barrier which gives access to the Client’s production network. If a break-in to the host containing such information has been detected, the attacked may be expected to arrive at the location personally.
Moreover, honeypots are adjusted to the physical conditions of Client’s infrastructure, for instance the WiFi signal strength is reduced to a level which will require approaching the buildings equipped with a CCTV system, which may enable to capture the attacker on video.
ADS-Collector means the main machines in the ADS architecture. They combine services collecting/receiving data from Client’s systems, as well as those processing the acquired information. The process of data collection is controlled by a dedicated ADS Data Processing component, logically separate from the rest of the system.
The same servers also contain agents whose task is to read data from the less typical systems the Client employs. The ADS DB Collector agent is responsible for gathering database logs and transferring them to ADS Data Processing.
Another crucial agent is ADS Checkpoint Collector downloading security logs from Checkpoint devices. Freshly collected data is then passed down to the ADS Data Processing service.
On receiving the information from the source systems, ADS Data Processing sends them to the ADS-Storage mechanism.
Both data processing and the correlation mechanism were implemented using the ADS Rule Manager module. which also decides whether to initiate an alert based on the received data. The alerts are then sent via ADS-API to the ADS-Web data presentation server.
One of ADS-Web functionalities is the possibility to make available the ADS-GUI application which is a tool for presenting alerts resulting from attacks and events detected by the ADS system.
Alerts detected by ADS Rule Manager service are received by the ADS-API communication channel located on the same machine. ADS-GUI, on the other hand, is responsible for presenting alerts to the end user. Additionally, this module enables searching received alerts and reporting. Alert searches may be performed based on numerous criteria, e.g. via client source addresses, logins, and any other fields filled in the alerts.
It is possible to integrate ADS-GUI with Active Directory, which allows efficient definition of access roles to the application based on the domain tree. In order to make working with the ADS-GUI system as effective as possible, a solution has been introduced to enable sending email and text messages informing of alerts. These messages are personalized for each user depending on alert type and/or event priority.
Thanks to a complex dashboard module, ADS-GUI provides real-time information on events within Client’s infrastructure – also mapping them to allow a practical overview of dispersed locations.
Client’s system logs, irrespective of the transfer channel, must eventually be deposited in the storage system. This process is realized by the ADS-Storage. The data saving and reading mechanisms have been optimized for use in large data warehouses, which is indispensable for SEM-class solutions in order to minimize attack detection time.
Methods of including log sources
ADS system offers various ways of connecting log sources, i.e. operation systems, databases, switches, routers and, for instance, applications. Not only can the system monitor in order to process the logs sent by Client infrastructure, but it may also download them of its own initiative. Implementing the ADS system it is possible to create connectors for non-standard systems and devices. As the product has been created entirely in Poland, it may be adapted to the Client’s real needs and infrastructure.
It is equipped with native log reception/download mechanisms:
- Syslog – supports the versions consistent with standards defined in RFC, as well as some less typical ones, such as those sent by Cisco devices. Moreover, parsing non-standard logs is possible.
- GELF (Graylog Extended Log Format) – an extended syslog version developed by Graylog programmers. This format enables transmission of amount of information larger than just flat lines with a log.
- OPSEC LEA –a protocol supported by Checkpoint devices. This API allows to download events, including the security events, from infrastructures based on Checkpoint devices. In that scope, ADS handles information download.
- Databases – numerous applications store logs in databases. Client application logs represent a source of sensitive information therefore it must be incorporated in the SEM system. In that scope, ADS handles information download.
The innovative power of the system – rule engine with event correlation capacity
Data interpretation, as a key element of the ADS system, employs business terms in event processing to facilitate understanding what actually happened. Technical information combined with a business description provide the Client with a complete information package allowing reliable incident analysis.
Together with the correlation engine, the final message goes beyond informing of a single event taking place by supplying complete knowledge on potential causes, as well as individuals/devices related to the incident.
What does ADS implementation include?
Project planning and execution, i.e. each ADS implementation is preceded with a workshop aimed at:
- Familiarizing Client’s infrastructure,
- Defining potential attack vectors,
- Identifying the systems which data will be collected from,
- Agreeing the schedule for system implementation..
The above result in selecting suitable parameters for the hardware platform dedicated for the ADS system. Further activities include verification of proper connector operation and programming for connecting non-standard log sources.
Having completed the implementation phase, STM Cyber provides the Client with necessary support throughout the system stabilization period.