Pentestas

Ruslan Rakhmetov, Security Vision

When developing a cyber security strategy for a company, one should not underestimate the capabilities and motivation of attackers: even seemingly perfect defence systems can be successfully hacked by hackers, data can be stolen even from physically isolated information systems, and experienced and trained employees can make a fatal mistake at some point. Therefore, both when building an ISMS from scratch and when making changes to an existing ISMS, the assumption must be made that attackers have successfully compromised the infrastructure some time ago, but have not yet manifested themselves in any way, and their actions have remained undetected by security systems. For example, who can guarantee that the software installed on one of the servers some time ago did not contain a software tab that periodically accesses a certain Internet server and receives commands from it: up to a certain point, this behaviour will not trigger most defences, since formally no malicious actions are being performed. However, at the will of the attackers, at some point the server may command the software to copy or destroy all information on the hosting server and all infrastructure elements accessed from the device.

If such an incident happens quickly enough and after hours, the hackers will have a high chance of success. This example is quite illustrative, but not the most frightening: there are examples of malware infecting the firmware of various devices connected to the corporate network, which at some point began to perform destructive actions or provide attackers with access to the network - in such a situation, it becomes much more difficult to determine the cause of the incident. Given the above, the IS community has developed the principle of ‘Assumed Breach’, which means ‘Consider yourself already breached’ - this means that no one can or should be 100% sure of the security of the protected infrastructure, and should always assume the presence of a dormant threat that has yet to be identified.

With this in mind, when building an ISMS, it is important to move from reactive, post-incident cybersecurity, where an incident is only responded to after the consequences have occurred, to proactive incident detection to find and eliminate hidden cyber threats. This transition can be initiated by implementing Cyber Threat Intelligence processes to proactively search for malicious or suspicious activities in the information infrastructure that cannot be detected by standard methods. Cyber threat analytics, or cyber intelligence, is based on the analysis of indicators of compromise (abbreviated IoC, from Indicator of Compromise) - objects or artefacts, the presence of which with a high degree of probability may indicate an impending, ongoing or already carried out computer attack. Classic examples of IoC would be IP addresses, domains, URLs, hash sum values - however, all of these attributes are easily modified by attackers for each new attack, so they become outdated rather quickly and are not always reliable.

Another way to work with cyber intelligence data is to analyse indicators of attack (abbreviated IoA, from Indicator of Attack), which are a sequence of actions and steps, as well as a set of tactics, techniques, and procedures of attackers (abbreviated TTPs, from Tactics, Techniques, Procedures). Examples of IoA are: running utilities and commands in a certain sequence, unusual behaviour of accounts (creation, inclusion in highly privileged groups with subsequent deletion), changes in the nature of network activity of devices (sharp increase in ICMP or DNS traffic, for example). However, for the best detection of hidden cyber incidents, a process of continuous Cyber Threat Hunting should be implemented - i.e. searching for threats within the network, analysing potential signs of infections, searching for traces of cybercriminal group activity, searching for signs of infections, and analysing messages on relevant IS resources and in the cybercriminal environment (forums, social networks and messengers).

When conducting a cyber threat search (i.e. Threat Hunting), analysts form certain hypotheses - assumptions about likely malicious activity, attacker actions, likely artefacts, indicators of compromise and indicators of attacks to look for in the infrastructure. In other words, cyber threat hunting is the purposeful execution of a developed plan to identify hidden malicious activity and attacker activities in the infrastructure. The Threat Hunting process must be conducted continuously, in accordance with the developed hypotheses and plans for detecting hidden threats, which means that cyber threat hunting cannot be chaotic or sporadic, with IS analysts only occasionally checking to see if there are any signs of undetected cyber incidents in previously recorded IS events.

When implementing a cyber threat hunting process in a company, it is important to develop a Threat Hunting policy, which should include rules for developing and documenting hypotheses (e.g., based on regular analysis of MITRE ATT&CK matrix updates, the person in charge generates likely new attack methods and relevant TTPs of attackers to be tested), the procedure for creating a plan for searching for signs of attacks not detected by other methods, a plan for executing actions in case of successful confirmation of the developed hypothesis, and ways to improve the cyber threat hunting process in case the hypothesis is confirmed. The document should also list the necessary resources (personnel, tools, infrastructure) to perform the cyber threat hunting process, define the expected results and reporting forms, how to transfer the detected threats to the response team, establish the authority of those responsible and executives, and then coordinate the developed policy with the head of the business unit. It is important to keep in mind that cyber threat hunting cannot replace the overall cyber incident management process, but it can serve as a good complement to it, providing an opportunity to close ‘white spots’ in the detection of IS incidents. In addition, successful implementation of the Threat Hunting process requires a deep understanding of the company's business processes to reliably detect anomalies and deviations in the normal behaviour of systems and users, interaction with the IT and IS department or SOC centre to share knowledge, experience, tools and information obtained, as well as regular analysis of processed IS incidents, relevant cyber intelligence data, information from ATT&CK's MITRE matrix and other sources about hackers' actual TTPs. In conclusion, the process of searching for cyber threats is quite complex and costly and can justify investments in it and bring significant benefits to those companies that have a high maturity of other IS processes - otherwise, investments in improving the basic level of cyber defence of the company will bring more benefits.

One such basic, fundamental cyber security process is IS audits. An IS audit is an examination of the status of the elements of a company's information security management system. In fact, an IS audit is an analysis of the extent to which the actual state of cyber security complies with internal IS regulations and best practices, standards, and legal requirements in the field of information protection. IS audits can be internal or external: internal audits are conducted by the IS department itself, which is essentially a self-audit, while external audits are conducted by a contracting organisation, which in certain cases must be licensed by Russian regulators. IS audits for compliance with internal cybersecurity regulations may be carried out at agreed intervals, as well as unscheduled - for example, by decision of the company's head or internal audit department, in the event of an investigation of a major cyber incident, or when a new head of the IS function is appointed.

When conducting audits, it is important to determine the regulatory support - this may be the company's IS audit policy, which specifies the objectives, audit procedure, roles and responsibilities of those responsible, reporting forms, methods of eliminating identified deficiencies and ways of processing the results to improve the ISMS in the company. It is important to conduct scheduled internal audits according to a formed plan, which may specify the main aspects of the work: verification of the main internal regulatory documents on IS (policies, regulations, instructions), verification of the implementation of documented provisions in practice (settings and results of the work of security systems and infrastructure components), analysis of reporting (reports on closed IS incidents, a list of inspections and training, reports on the performance of the IS department). Checklists with a list of questions to which the responsible persons give comprehensive answers, supported by reports and uploads from IS systems, may be used as a form of verification. In the case of compliance audits, the audit is usually conducted by an external organisation - this is required, for example, to obtain a certificate of compliance with PCI DSS or ISO 27000 series standards, or for top management to understand how compliant the company is with data protection legislation. In the case of voluntary (non-mandatory) IS audits, the auditors may additionally issue technical recommendations to eliminate the identified deficiencies, which should be promptly worked out and then repeat the audit. In general, we can conclude that an IS audit is a check of the company's IS status in laboratory, ‘greenhouse’ conditions: organisational and administrative documents, settings of security systems, reports on completed work, closed incidents and eliminated cyber threats, as well as the quality of work of the IS department are checked.

In order to verify the state of the company's IS in real, ‘combat’ conditions, you can use the service of penetration testing (pentest, from the English penetration test, abbreviated pentest). Pentests are conducted by independent IS experts (pentesters) who simulate the actions of attackers to detect weaknesses in the company's cyber defence. In essence, a pentest is a controlled cyber attack to improve the overall level of a company's security. Pentests are conducted using black-box, grey-box and white-box methods:

• Black-box pentest means that pentesters are given minimal prior knowledge of the company under test and have no privileges in the infrastructure under test - such a pentest is as close to real life as possible, in which attackers get all information about the target company under attack from public sources;
  
• Gray-box pentest means that pentesters receive limited information about the infrastructure under test beforehand, which gives them limited insight into possible attack methods;
  
• White-box pentest involves pentesters working virtually from inside the company, using certain privileges and network access - thus simulating the actions of a highly skilled insider.

When conducting pentests, it is important to strike a balance between the depth and realism of testing and the continuity of the business processes of the company being tested: it is no secret that a plausible simulation of a cyberattack can lead to disruption of the infrastructure, especially in the case of black-box testing, when pentesters may not fully realise the criticality of a particular service, which may be accidentally stopped during testing.

When conducting a pentest, it is important to notify the heads of the company's relevant departments and several key employees, who should not disclose information about the testing to increase the plausibility of the pentest. You should also agree on the scope and boundaries of the testing: for example, that data will not be destroyed and that services and equipment will not be rebooted or overloaded. It is also important to provide for a communication model between the pentester team, their manager and the person responsible for the pentest on the part of the company being tested - if a situation arises that is potentially dangerous to the company's operations, it is important to suspend the testing in time and check the operation of the company's services. At the same time, the reaction of the incident response team should be monitored - in case of a ‘blind’ pentest, when the company's IS department is not notified of the pentest, the response team or the SOC centre should timely detect the pentest and stop the simulated attack.

The pentest report should contain complete information about the methods and tools used for reconnaissance, initial penetration, privilege escalation, lateral movement, and performing specified actions in the attackers' role (e.g., gaining access to an account with domain administrator privileges). Pentesters should carefully log the actions performed so that the company can then receive actionable recommendations for remediating identified cyber defence vulnerabilities.