Loading
Quite often, aiming to speed up the process of deploying their IS system, companies may be tempted to start deploying a SIEM as its foundation without a pre-developed tactic and strategy for its usage. Despite saving time initially, this approach quickly turns any modern SIEM into a massive dump of log files, with data from which simply clogs up disk arrays.
Another typical case is that a company carefully selects the types of data sources and the number of log files but spends a vast amount of time developing a considerable number of different correlation rules that can overcomplicate the system and lead to the generation of unnecessary types of events.
What do both of these examples have in common? Lack of a precise formulation of the initial hypothesis/question addressed to the data in the log files. Examples of such questions include: "What is the most optimal location of network decoys in the infrastructure? On which hosts is an attacker more likely to hit file decoys? What bait services can lure an attacker to a network segment with monotonous network services?"
With Splunk, an IS analyst can quickly identify the network segments where incidents occurred most frequently and, based on this data, fill the free IP range of these subnets with network decoys. If there are segments in the infrastructure with the same type of services, setting different types of decoy services will increase the chances of detecting the attacker at the stage of network research. Thus, file decoys should be placed on hosts with the highest number of network connections and file operations.
However, there is also a difficulty here - most events in log files only indirectly indicate security-related anomalies. In contrast, an alert from a Labyrinth deception system informs about an incident that requires an IS analyst's attention.
To increase the coverage of the infrastructure with the Labyrinth deception system, it is necessary to utilize the capabilities of file decoys fully. To do this, it is essential to maintain their consistency and track any use by the attacker of the information contained in the decoy files.
Our customers commonly combine Splunk Alerts, Labyrinth Alerts, and other sources of security events, such as IPS or EDR triggers. In this case, information from the deception system adds more context to Splunk Alerts.
At the same time, thanks to Labyrinth's two-way integration with Splunk, all deception system alerts are enriched with information about the attacking host obtained from Splunk based on attacker-IP. Thus, this mechanism speeds up the alert review by the Labyrinth system operator several times.
Setting up two-way integration with Splunk is done in the Settings -> Integrations -> Splunk section and takes no more than a few minutes.
The Labyrinth system itself maintains the relevance of the data in the decoy files, and detection of attempts to use, for example, pre-prepared credentials on actual hosts/devices is ensured by the above two-way integration: Labyrinth periodically queries and compares data from Splunk's auth files with information from decoy files. If Labyrinth detects this action by an attacker, it will notify the system operator with an appropriate Alert.
Thus, the basis of an efficiently functioning security system is, first and foremost, clearly defined goals and thoughtful planning. Labyrinth, in turn, will detect all malicious activities within the network, providing comprehensive coverage of all possible attack vectors.
