(thanks to Sergey G. Brester for the idea of the title) )
Colleagues, the purpose of this article is to share experiences from a year's testing of a new class of IDS solutions based on Deception technologies.
To maintain the logical coherence of the material, I find it necessary to start with the premises. So, the problem is as follows:
- Targeted attacks are the most dangerous type of attack, even though their share in the overall number of threats is small.
- Some guaranteed effective perimeter protection means (or a complex of such means) have yet to be invented.
- As a rule, targeted attacks go through several stages. Breaching the perimeter is just one of the initial stages, which (feel free to throw stones at me) does not cause significant damage to the 'victim', unless it is an attack of DEoS (Destruction of Service) type (ransomware, etc.). The real 'pain' begins later when the compromised assets are used for pivoting and further developing the attack 'in-depth', which we may not have noticed.
- Since we start facing real losses when criminals manage to reach their attack targets (application servers, databases, data storage, repositories, elements of critical infrastructure), it is logical that one of the tasks of the information security service is to interrupt attacks before this unfortunate event occurs. However, in order to interrupt something, we first need to know about it. And the sooner β the better.
- Accordingly, to successfully manage risks (i.e., reduce the damage from targeted attacks), it is critical to have tools that ensure minimal TTD (time to detect β time from intrusion to detection of the attack). Depending on the industry and region, this period averages 99 days in the USA, 106 days in the EMEA region, and 172 days in the APAC region (M-Trends 2017, A View From the Front Lines, Mandiant).
- What does the market offer?
- "Sandboxes." Another preventive control that is far from ideal. There are many effective techniques for detecting and bypassing sandboxes or whitelisting solutions. The guys from the 'dark side' are currently one step ahead here.
- UEBA (User and Entity Behavior Analytics) can be very effective in theory. However, in my opinion, thatβs something for the distant future. In practice, it is still very costly, unreliable, and requires a very mature and stable IT and information security infrastructure that already has all the tools generating data for behavioral analysis.
- SIEM is a good tool for investigations, but it cannot see and promptly display anything new or original, as correlation rules are essentially the same as signatures.
- As a result, there is a growing need for a tool that would:
- successfully operate in an already compromised perimeter,
- detect successful attacks in near real-time, regardless of the tools and vulnerabilities being exploited,
- not rely on signatures/rules/scripts/policies/profiles and other static elements,
- not require large data sets and their sources for analysis,
- allow for identifying attacks not as a risk-score from 'the best in the world, patented and therefore closed mathematics' that requires further investigation, but practically as a binary eventβ'Yes, we are under attack' or 'No, everything is OK',
- be universal, effectively scalable, and truly implementable in any heterogeneous environment, regardless of the physical and logical network topology used.
The so-called deception solutions are currently vying for this role. These are solutions based on the good old concept of honeypots, but with a completely different level of implementation. This topic is definitely on the rise right now.
According to the results of Deception solutions are in the TOP-3 strategies and tools that are recommended for use.
According to the report Deception is one of the key directions in the development of Intrusion Detection Systems (IDS) solutions.
A whole section of the latest , dedicated to SCADA, is based on data from one of the market leaders, TrapX Security (Israel), whose solution has been operating in our test zone for a year.
TrapX Deception Grid enables the centralized deployment and operation of massive distributed IDS without increasing licensing burdens or hardware resource requirements. In fact, TrapX is a toolkit that allows the creation of a large-scale enterprise attack detection mechanism from elements of the existing IT infrastructure, a sort of distributed network 'alarm'.
Solution Structure
In our lab, we continuously study and test various innovations in IT security. Currently, there are about 50 different virtual servers deployed here, including components of the TrapX Deception Grid.
So, from top to bottom:
- TSOC (TrapX Security Operation Console) is the brain of the system. It is the central management console used for configuring, deploying the solution, and all daily operations. Since it is a web service, it can be deployed anywhere - on the perimeter, in the cloud, or with an MSSP provider.
- TrapX Appliance (TSA) is a virtual server to which we connect those subnets we want to monitor using a trunk port. This is also where all our network sensors effectively 'live'.
In our lab, one TSA (mwsapp1) is deployed, but in reality, there can be many. This may be necessary in large networks where there is no L2 connectivity between segments (a typical example is 'Holding and subsidiaries' or 'Head office of a bank and branches') or if there are isolated segments in the network, such as SCADA systems. Each such branch/segment can deploy its TSA and connect it to a single TSOC, where all information will be processed centrally. This architecture allows building distributed monitoring systems without requiring a major restructuring of the network or violating existing segmentation.
Additionally, we can provide a copy of the outgoing traffic through TAP/SPAN on the TSA. If connections to known botnets, command servers, or TOR sessions are detected, we will also receive results in the console. This is handled by the Network Intelligence Sensor (NIS). In our environment, this functionality is implemented at the firewall, so we haven't utilized it here.
- Application Traps (Full OS) β traditional honeypots based on Windows servers. A large number is not required, as the main task of these servers is to provide IT services to the next level of sensors or to identify attacks on business applications that may be deployed in a Windows environment. We have one such server (FOS01) set up in our lab.
- Emulated traps β the core component of the solution that allows us to create a dense 'minefield' for attackers using a single virtual machine and saturate the enterprise network, all its VLANs, with our sensors. The attacker sees such a sensor, or phantom host, as a real Windows PC or server, a Linux server, or another device that we choose to show.
For the sake of utility and curiosity, we deployed 'a pair for each creature' β Windows PCs and servers of various versions, Linux servers, an ATM with Windows embedded, SWIFT Web Access, a network printer, a Cisco switch, an Axis IP camera, a MacBook, a PLC device, and even a smart bulb. In total β 13 hosts. In general, the vendor recommends deploying such sensors in a quantity of at least 10% of the number of real hosts. The upper limit is the available address space.A very important point is that each such host is not a full virtual machine, which requires resources and licenses. It is a 'decoy', an emulation, a single process on a TSA, which has a set of parameters and an IP address. Therefore, even with a single TSA, we can saturate the network with hundreds of such phantom hosts that will work as sensors in the alarm system. This technology allows for a cost-effective scaling of the honeypot concept across any large distributed enterprise.
From the attacker's perspective, these hosts are attractive as they contain vulnerabilities and appear to be relatively easy targets. The attacker sees services on these hosts and can interact with them, attacking them using standard tools and protocols (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, etc.). However, using these hosts to further an attack or run their code is impossible.
- The combination of these two technologies (FullOS and emulated traps) allows for a high statistical probability that an attacker will eventually encounter some element of our signaling network. But how can we make this probability close to 100%?
Enter the so-called deception tokens. With these, we can include all available PCs and servers of the enterprise in our distributed IDS. Tokens are placed on the users' actual PCs. It's important to understand that tokens are not agents consuming resources and causing conflicts. Tokens are passive informational elements, a sort of 'breadcrumb' for the attacker, leading them into a trap. For example, connected network drives, bookmarks for fake web admin panels in the browser and saved passwords for them, saved ssh/rdp/winscp sessions, our traps with comments in hosts files, passwords stored in memory, credentials for non-existent users, office files that will trigger the system when opened, and much more. This way, we place the attacker in a distorted environment saturated with attack vectors that do not actually pose a threat to us, but rather the opposite. And they have no way to determine where the true information lies and where the falsehoods are. Thus, we not only ensure quick detection of an attack but also significantly slow down its progress.
Example of creating a network trap and configuring tokens. A friendly interface with no need for manual edits of configs, scripts, etc.
In our environment, we have configured and placed several such tokens on FOS01 running Windows Server 2012R2 and a test PC running Windows 7. RDP is running on these machines, and we periodically 'post' them in the DMZ, where a number of our sensors (emulated traps) are also located. This way, we receive a constant flow of incidents, so to speak, naturally.
So, brief statistics over the year:
56,208 incidents recorded,
2,912 host sources of attacks detected.
Interactive, clickable attack map
In this case, the solution does not generate a massive log or event stream that requires extensive analysis. Instead, the solution classifies events by their types, allowing the cybersecurity team to focus primarily on the most dangerous onesβwhen the attacking party attempts to elevate control sessions (interaction) or when binary payloads (infection) appear in our traffic.
All information about events is readable and, in my opinion, presented in an easily understandable format even for users with basic knowledge in cybersecurity.
Most recorded incidents are attempts to scan our hosts or isolated connections.
Or attempts to brute-force passwords for RDP.
However, there have been more interesting cases, especially when attackers 'succeeded' in guessing the RDP password and gained access to the local network.
The attacker tries to execute code using psexec.
The attacker found a saved session, which led him into a trap resembling a Linux server. Immediately after connecting with a pre-prepared set of commands, he attempted to wipe all log files and relevant system variables.
The attacker tries to perform an SQL injection on a trap that mimics SWIFT Web Access.
In addition to such 'natural' attacks, we also conducted a series of our own tests. One of the most illustrative is the testing of the detection time for a network worm on the network. For this, we used a tool from GuardiCore called . This is a network worm that can infect Windows and Linux but does not carry any 'useful' payload.
We set up a local command center, launched the first instance of the worm on one of the machines, and received the first alert in the TrapX console in less than one and a half minutes. The TTD was 90 seconds compared to an average of 106 daysβ¦
Thanks to the ability to integrate with other classes of solutions, we can shift from rapid threat detection to automated responses to them.
For example, integration with NAC (Network Access Control) systems or with CarbonBlack will allow automatically disconnecting compromised PCs from the network.
Integration with sandboxes allows automatically submitting files involved in the attack for analysis.
Integration with McAfee
The solution also includes its own built-in event correlation system.
However, we were not satisfied with its capabilities, so we integrated it with HP ArcSight.
The built-in ticketing system helps to address detected threats collectively.
Since the solution was initially developed for the needs of government agencies and large corporate sectors, it naturally implements a role-based access model, integration with AD, an advanced reporting and trigger (event alerting) system, and orchestration for large holding structures or MSSP providers.
Instead of a summary
If there is a monitoring system that, figuratively speaking, covers our back, then the compromise of the perimeter is just the beginning. The most important thing is that a real opportunity arises to combat security incidents, rather than merely addressing their consequences.
Source: habr.com
