Ruslan Rakhmetov, Security Vision
Fig. 1 - Evolution of XDR
Before we start talking about the tasks and capabilities of XDR, it is worth to understand the reasons and conditions for the emergence of such a product. eXtended Detection and Response is a solution for extending the capabilities of classic EDR, which originates from antivirus solutions at the endpoints. Thus, XDR becomes useful in those organisations where there is a need to detect complex attacks using protection tools not only at the endpoints but also at the network nodes. Such tasks can be solved with different tools: manual analysis of EDR events, automated correlation using UBA/EUBA and SIEM, or even building response processes in IRP. Regardless of the size of the company and the tools it uses, you can use this formula:
EFFECTIVE PROTECTION = Events + Incidents + Processes + Automation
Now let's deal with the variables in this equation, but before that, for those readers who are unfamiliar with the different acronyms (of which there will be many below) we recommend an overview of information protection tools: part 1, part 2, part 3 and part 4.
Events. This component is log data where you can search for anomalies and suspect a possible attack. For example, several attempts of unsuccessful user authentication in some information system are separate events that can be analysed even manually, the main thing is to know where to look. Similar events would be legitimate traffic transfer inside or outside the company, which is detected and labelled by DLP (Data Loss Prevention), user actions at the workplace and in the office, received from ACS (Access Control and Management Systems) or UAM (User Activity Monitoring) /EM (Employee Monitoring) solutions. Materials from VS (Vulnerability Scanner) reports are also separate events consisting of detected vulnerabilities - since some of them may be unrecoverable or non-critical, they are not incidents yet and will have to be analysed additionally for sure.
Incidents. Simply put, incidents = events worth paying attention to. In the case of password brute force, an incident would be, for example, activity in ‘decoys ’ and fake DDP (Distributed Deception Platform) nodes, the activity in which definitely belongs to attackers. DLP systems mark incidents using their own algorithms. For example, sending personal data to HR is unlikely to be an incident, but saving a customer database to a flash drive is a strange activity and most likely an incident. A chain of events can also become one incident detected, for example, by UEBA tools - an abnormal number of saved files, changes in work schedule and trigger words in correspondence are combined into a possible incident like ‘possible dismissal’ and should be analysed separately.
Processes. They can be different and are determined by the business logic of the departments in the company and their interactions. In the case of ‘possible dismissal’ from the previous example, HR, information security and IT specialists may be involved in the process: HR specialists should see the potential outflow of staff and make decisions together with the manager, security specialists may strengthen control over communication channels and limit VPN connections, and IT specialists may initiate preparation of equipment for possible decommissioning by the current employee.
Automation. The actions of specialists from different departments from the example above can be replaced by robot actions, and automation tools will be responsible for this. For example, the lifecycle of technical assets can be managed in CMDB (Configuration Management Database) systems, and HR and accounting processes can be run automatically via 1C, for example.
So, for protection in general, you can get by with manual analysis of pure events, but the more variables in your formula - the simpler, faster and more reliable the process.
Fig. 2 - Components of an effective defence
The summands from the first part of our article can take different forms: XDR and other similar solutions become separate parameters or their combination, so further we will deal with possible variants.
Events and incidents are similar in their essence and can be the results of the work of separate information protection systems (IPS): AV, DLP, UAM, UAM, NGFW, EM, etc. If the systems are poorly configured or used out of the box, SIEM and UEBA systems and those XDRs that include these components will help isolate incidents from events.
XDR = EDR + EDR_1 + ... + EDR_x + UEBA + SIEM
This formula is valid if all solutions on the right side of the formula are created and supported by a single vendor. Therefore, vendors that have SIEM in their portfolio look the most complete of XDR solution providers.
If the protection systems are a ‘zoo’ of solutions and cannot be united by standard means, it is logical to replace the use of XDR with SIEM/SOAR solutions. The only difference is that XDR performs analysis at endpoints and is limited by the possibilities of ready-made connectors for integration, while SIEM performs analysis centrally and is usually ready to ‘digest’ data from any system without being tied to a specific vendor.
In addition to incident events, it is important to consider two other components - the response processes themselves and the automation capabilities. Processes are already found in XDR and SIEM solutions, so if external integrations are not even considered as described above, it is likely that you can be satisfied with the processes built into XDR. If the maturity level of the processes is already high, there is a risk that out of the box capabilities will not suffice, so be sure to consider SOAR, BPM and RPA solutions where you can create and support absolutely any process. SOAR is also more suited to those companies that require high customisation and need to orchestrate an unlimited number of systems from a single point.
XDR in this case can be compared to a washing machine with a drying function or a 3in1 coffee machine: it takes up little space in the laundry room and kitchen cupboard, is easier to buy, quicker to use and doesn't need to be customised. But if you like coffee from a turba with almond milk or well washed clothes, you're more likely to consider solutions separately. In that case, a separate SIEM and/or SOAR solution will be a real kitchen, with everything you need, where you can rearrange furniture and create your own recipes. It is also interesting that XDR integration is done at the deployment stage rather than added later, which can tie the hands of developing teams or large companies with self-written systems and data sources.
This comparison is rather crude and equates all XDR solutions, which is really unfair. Solutions can be equal to SOAR if the core is integrated with network tools to protect mail, web traffic and possible data leaks; EDR as a part supports a large number of data sources at the endpoint level (PCs, laptops, virtual machines, mobile devices, etc.), there is enrichment from Threat Intelligence feeds and interoperability with MITRE ATT&CK. If there are few ready integrations within XDR or the out-of-the-box processes do not cover all the needs of IS, ESB, IT and other departments, then in the course of operation there will definitely be a need to expand BI, UEBA and SIEM solutions, and process organisation and automation will have to be transferred to solutions with BPM and RPA engines.
