Security Vision
We are used to standard response plans, which are either a bunch of algorithms covering a large number of situations or a lot of small playbooks specialised for a specific type of incident. At the same time, the enterprise infrastructure is a living organism that is constantly changing: new devices are added, network segments are added, policies for the important boss's laptop are changed, and anti-virus systems are added. For this reason, organisations with a developed IS level regularly conduct audits and inventories to help update the information model of the enterprise, but do the playbooks change based on the results of the inventory?
The next aspect that affects the effectiveness of defence is the variability of the external environment. In the current realities, attack techniques are evolving, becoming more complex, affecting new types of infrastructure data, using new mechanisms and methods of post-compromise (for example, ransomeware now not only encrypts an organisation's data and demands payment to regain access, but can also steal an organisation's information, demanding additional payment in exchange for non-disclosure to authorities, competitors or the public).
Due to the ever-changing threat landscape and the ways in which threats are implemented, our playbooks must also change to ensure that they do not become obsolete in the face of changing attacker behaviour.
To address the first challenge (infrastructure variability), an approach has been developed that is referred to in the foreign community as CD/CR, or Continuity of Detection and Response.
It consists in applying the best practices of OOP to building information security processes. Google Corporation was the first to announce this technology as a promising development. Their research proposes to break down IS processes and procedures to atomic functions that can be over-utilised and are essentially small unified processes to perform an operation. Atomic unified processes are stored in a repository; a function is executed by a single instance of a workflow that is corrected in the same place by different stakeholders (in this way we respect consistency) and, when the need arises, this process is included in the playbook in a standard way due to unified input/output.
An example of a unified process would be the procedure for collecting authentication sessions from a host. It can be performed in different ways and by different means depending on the host type, host usage policies, or the closing NWI. But if all these variations are handled in one universal authentication collection process with one standard input/output, it becomes much easier to build IS processes. The atomic process, in addition, will be reused in completely different IS processes: not only when building dynamic plebucts in incident management, but also in asset management, IDM, etc. A set of such universal processes gives us the opportunity to form a custom approach to a custom infrastructure.
But we have considered a way to solve only the first part of the problem - infrastructure relevance. We also need to solve the problem of obfuscating the conduct of attacks, which is essentially already a deductive investigation that is hard to cover with a correlation engine. To some extent, behavioural deviations can be covered through anomaly analysis (UEBA) and it's still not what we need: looking for anomalies in device/human behaviour and deviations in attack execution are different things. But when you think about what specialisation or area of expertise is involved in looking for signs of device or security level compromises, the first thing that comes to mind is threat hunting technology (hypothesis building to look for suspicious activity). Indeed, controlling the variability of attack techniques through common device compromise indicators is one of the tasks performed by 3rd line analysts specialising in threat hunting.
If we use threat hunting approaches applied to the vicinity of an incident, we can find additional objects that have been compromised even though they were not previously affected by the attack technique. For example, the exploitation of a vulnerability did not compromise a security layer or the virus did not upload some hacker tool set.
Suspicious activity can be completely diverse, which is why manual threat hunting is such a time-consuming procedure that requires skills and knowledge in completely different subject areas. One threat exploits protocol weaknesses, which requires knowledge of networking technologies; another threat exploits custom encryption, which requires knowledge of crypto. To understand how rootkit works, programming knowledge will help us: indicators of suspicious activity can be so different that a specialist's background should be as broad as a general practitioner's. The good news is that some of these tasks can be automated by using modern threat hunting techniques such as sigma, microsoft threat detection, elastic security rules, and IDS system alert analysis.
Here is what you can find in the vicinity of an incident if you automate threat hunting:
- Internal network scans and attempts to exploit vulnerabilities within the network
- Suspicious network activity of the system utilities rundll32, regsvr32, mshta, certutil.
- Running command interpreters (powershell, cmd, wscript, cscript) by office applications (word, excel)
- Writing to registry keys responsible for autoloading or changing OS system settings
- Creating services, scheduler tasks with powershell and LOLbins utilities
- Running unregulated software (administration utilities, VPN clients, TOR, torrent clients, etc.).
Suspicious processes are found by suspicious parents of system processes:
In the command line you can find powershell code with paiload in base64, which means code obfuscation, and there can be anything there already: an archive in an archive, encrypted commands, etc. Naturally, admins will not hide their activities, and this is a clear sign of suspicious activity:
Running admin tools from under an unprivileged user, suspicious elevation of privileges to the system account, and so on and so forth.... This approach can give us a huge set of additional information and new affected incident objects.
If we build the search for these objects into the incident analysis, the dynamic playbook will be based on the real actual context of the attack, i.e. all the objects from the incident.
In total, we will have a real kill area on which we can start to assemble an object-oriented response from the process repository:
- select a set of possible atomic response processes for internal hosts
- select a set of response processes for the compromised security level
- or for VPO, mail, and more.
From these, a dynamic playbook starts to build up: if this type of object appears, the process is added to the response process. Multiple universal response processes on multiple objects are limited to recommending specific actions, depending on the attack technique defined in the incident classification process. That is, the dynamics of the playbook is to change the composition of actions, depending on the affected objects and the attack technique. This approach allows the creation of a playbook of actions relevant to a specific situation.
Another important point is to build the attack chain from individual incidents into a connected story depicting the attack landscape, stretched in perimeter, time and execution methods. In reality, attacks are becoming increasingly complex and sophisticated, from incidents with different techniques that are also connected by rather non-obvious things (e.g., having the same process in the incidents, or using the same named pipes). Of course, such situations cannot be covered by standard response plans, but if we add a dynamic component to standard approaches, we can link incidents by identical objects and context: launching similar suspicious processes, network authentications, security levels involved. The same hosts involved in different incidents are likely to say they belong to the same kill chain. With this approach, our incidents become connected and dynamic playbooks are sequenced to work on the attack, i.e., moving to a higher strategic level of response plans.
If we analyse the information collected through the Mitre Att@ck threat classification or the FSTEC BDU, the kill chain stages in general are transformed into a sequence of tactics used by the attacker, to which we dynamically build a contextual response.
With the current volatility in the IS, the very rapidly changing behaviour of the intruder and the state of the protected infrastructures, we need to apply appropriate symmetric dynamic approaches.
.jpg)
