What is SFDS?

SCADA Fault Detection System is a solution designed to address the biggest threat to industrial networks – disruption of process availability and continuity, as well as to detect anomalies. Its main goal lies in continuous and non-invasive monitoring of a maximum number of industrial infrastracture components in order to identify failures and any undesirable activity. Thanks to SFDS we considerably shorten the time from detecting an anomaly/failure to the moment actual steps aimed at remedying the issue have been undertaken.

SFDS system is adressed to:

dedykowani1

Industry in general, such as refineries, mines, factories, other production plants

dedykowani2

Railway, road and maritime transport

dedykowani3

Logistics, and all businesses related to warehousing

dedykowani4

Food industry (including spirits industry)

SFDS – mode of operation

Cient’s infrastructure, such as monitoring devices, databases, production process control systems, PLC controllers and other elements vulnerable to abuse or failures are equipped with dedicated SFDS Local Agents. Their task consists in continuous asquisition of information from sensitive areas within the infrastructure, its initial processing and transfer to the component responsible for agregating data from a given area (e.g. fuel base, warehouse complex). The collected data is then processed by SFDS Rules – a unique mechanism for detecting anomalies in industrial systems based on rules defined by the end user.

User interface – searchingimage

The base of the system – SFDS AGENTS

SFDS Agents encompasses both agents running on specialized software developed by our engineers, as well as the agents designed with specific dedicated devices in mind. The effectiveness of the SFDS system agents stems from their diversity and adjustibility to any infrastructure.The system enables the definition of unlimited agents for a given location. A list of agents operating in a sample location is presented beside.

SFDS AGENTS – scope of operation:

  • gathering data on current industrial infrastructure status from PLC controllers in order to detect failures and undesired use by employees and third parties
  • monitoring the availability of industrial automation systems and devices aimed at detecting failures, but also the instances of unauthorized switching to manual operation mode (e.g. removing fuel from the tank bypassing refueling monitoring systems)
  • collecting CCTV system data and footage aimed to document events and their correlation with other alerts (e.g. fuel theft, unauthorized access to critical premises)
  • monitoring database modifications in terms of changes to the stored information, record detection and structure alternations, combined with correlation with the business aspects of the processed data
  • gathering data on actions taken in managing positions with regard to abuse committed by employees
  • monitoring the fuel level, temperature and humidity in fuel tanks based on communication with industrial automation systems such as Enraf
  • monitoring temperature, humidity and anomalous signals (air-conditioning faults, automation system signals) in critical premises, e.g. rooms with industrial equipment
  • monitoring application servers with regard to the usage of local resources, such as the CPU or RAM in order to detect server overloads
  • monitoring logged user sessions in operating systems and databases aimed at detecting unauthorized access and for latter correlation (e.g. information has been modified in database, the alert will include extensive record of who was logged in the system or database)
  • monitoring file servers with regard to unauthorized access or data modification
  • monitoring pedestrian/vehicle entries to record physical access to the premises by customers and suppliers
  • monitoring access control systems and security systems with regard to unauthorized access e.g. to critical premises after business hours
  • monitoring systems providing remote access services to Client’s infrastructure, such as VPN with regard to access thereto by staff, cooperating businesses or third parties enabling the correlation of recorded sessions with other events

The power of innovation – rules engines with event correlation feature

The SFDS system processes information based on the SFDS Rules Module in order to spot failures and anomalies in the Cient’s systems and devices. Its operation relies strictly on the agents gathering the necessary data, however, dry messages themselves would not be so useful without proper interpretation and correlation. Data interpretation constitutes a vital element of the SFDS system as it facilities the understanding of what events actually took place with a particular incidents. The application of the correlation engine enriches dry facts of an event taking place with a comprehensive array of possible causes of its occurrence, as well as the individuals/devices related to the incident

Continuous data collection on current status of the Client’s system and hardware infrastructure makes it possible to correlate new facts with related events preceding and following the incident. As a result, system operator is given a complete set of reliable information. Equipped with such knowledge, he may then undertake specific measures aimed to mitigate and/or avoid possible repercussions.

A sample CCTV incidentimage

CCTV incidents

A sample CCTV incident reporting i.a. the lack of camera signal is presented beside. Related alert elements show event details, such as camera location, its unique ID and other information.

USEFUL SYSTEM FEATURES

SFDS enables integration with Active Directory, which brings in the possibility to build application access roles based on domain trees. Striving for ever greater user-friendliness and efficiency, the possibility to receive e-mail or text messages has been added.
SFDS includes an extensive dashboard module with real-time information on events taking place within the Client’s infrastructure shown on a map of various scattered locations.

Dashboard module- scattered locationsimage

System architecture exemplified on fuel base operator

The system architecture has been presented below based on a case of fuel-related business. The diagram the dispersed architecture of the SFDS solution, including device access from the IT environment (the ADS module) and an example honeypot network.

SFDS Global Controller a system for data collection and its presentation via a web application interface. SFDS GC correlates detected events generated by the rules engine with the data collected by other SFDS system components are. Thanks to a single instance of SFDS GC installed at the Client’s end, there is only one interface which enables tracking the current status of industrial infrastructure.

SFDS Local Controller a component whose goal is to collect data from local agents and run the correlation process, and then to send it to SFDS Global Controller for further presentation.

SFDS Local Agents a set of agents deployed in sensitive areas of Client’s infrastructure.

SFDS Local Agents trusted zone a zone that encompasses trusted infrastructure components, e.g. PLC

SFDS Local Agents untrusted zone a zone that monitors third party and other solutions susceptible to modification by a large group of people.

System’s architectureimage

ADS - an SFDS system module

Attack Detection System is a dedicated IT-oriented SEM-class system which natively integrates with the SFDS system. Implementing the ADS module enables detecting autonomous events taking place withing IT infrastructure as well as event sequences pointing to the organization being under attack. What is more, collected data may be correlated with other events detected in industrial automation.

Detecting cyber-attacks

It is frequently the case that industrial automation systems require an IT environment to function properly. At some point every infrastructure must use a database, switches, or routers. Attacks targeting an organization using industrial automation solutions may be conducted through its IT network (e.g. through the DMZ network).

ADS provides the possibility to detect attempts aimed at IT devices and systems whose purpose is to run industrial automation. The fact of an attack taking place is detected by analyzing generic events (for instance creating a local user in Windows OS with ADS connected, the system identifies an attack or an attempt to perform one. This enables detecting an attack in its early stage becomes possible, prior to causing any interference in automation-related devices.
Generated alerts are presented in the same console as SFDS ones without requiring the operator to log in to separate systems before gaining access to complete information.

Correlation of automation data with IT environment

    On receiving an SFDS-generated alert, the ADS module enables correlation with:

  • information on sessions from VPN systems in a manner granting the possibility of registering connections made to the corporate network
  • a list of user log-ins to databases
  • a list of user log-ins to operating systems
  • an escalation of user permissions in the operating system or a database
  • instances of users added or deleted in a short period of time
  • deleting event logs in Windows OS
  • a server reboot
  • sending an email message, e.g. to a private account

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.

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:

  • DMZ
  • WiFi
  • SCADA

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.

What benefits does SFDS offer?

  • real-time and ongoing monitoring of industrial infrastructure status in terms of failures which could disrupt business operations
  • monitoring the Client's systems and industrial automation devices aimed at detecting unauthorized actions from staff and third parties
  • a single interface providing exhaustive data on past and present condition of the industrial infrastructure, which translates to enhanced work efficiency
  • redused incident-related cost through collecting maximum amount of data that accompany an event
  • lower cost of employing highly qualified staff
Ask for more details