Information security trends. Part 1

Ruslan Rakhmetov, Security Vision

The field of information security, or cyber security, is quite young. Only 10-15 years ago, an IS specialist had to explain to his colleagues and friends what he was doing. However, nowadays the issues of information protection, cyber resistance, hacker attacks are discussed at the level of the first persons of states, and the topics of cyber security and protection from fraudsters do not leave the main pages of news sites. At the same time, like any other modern business area, information security is evolving - and not only in terms of hacker attack tactics and techniques, new computer vulnerabilities or information protection tools. The very concepts of protection are changing: for example, such an approach as ‘controlled information perimeter security’, so familiar and understandable 5-10 years ago, is now no longer practical in most cases, and remote work in connection with the pandemic has only increased the obsolescence of this concept. In this article we will look at the most striking and relevant in our opinion modern trends in the field of information security.

1- Supply Chain Attacks

Modern large high-tech companies try to competently build information security processes, such as cyber risk management, vulnerability and update management, work with information security tools, log collection and analysis, IS audits. However, even for a highly qualified specialist, much modern software remains a ‘black box’: they are often forced to blindly trust vendors - manufacturers of operating systems, application software and even developers of security tools. Few companies have dedicated employees who can reverse-engineer software products to understand what functions a particular component performs. And if we take into account that updates for software solutions are released almost every day, it becomes clear that it becomes almost unreal to check such volumes of code. Thus, companies willy-nilly become dependent on vendor's competences and IS state.

Recent examples of such supply chain attacks are the notorious hacks of IT giants SolarWinds and Kaseya. In both cases, attackers made malicious changes to the source code of these companies‘ software solutions, which resulted in all customers of these IT solutions becoming vulnerable to unauthorised attackers’ influence: the infected systems contained the so-called ‘backdoor’, i.e. a malicious module that receives control commands from the hackers' server. Thus, even a well-built IS system would be powerless in this case - all software updates from SolarWinds and Kaseya containing the malicious module were signed with a correct digital signature, and there was no reason to distrust them. Moreover, even the employees of these IT vendors themselves did not know that unauthorised changes had been made to the source code of their software.

Another example: GitHub repositories containing the source code of open source projects, i.e. programmes based on open source code, available for everyone to read and usually distributed for free. These repositories are also potential sources of supply chain attacks - an attacker need only get hold of a GitHub user account that has the authority to make changes (called commit) to the source code of a project. Having made malicious changes, the attackers only have to wait for the project code to be uploaded by the vendor of the software solution under attack, as it is no secret that many commercial products use open source components under the bonnet.

An option to protect against attacks on supply chains would be a set of measures aimed at checking the reliability of the vendor-supplier of software products and analysing the state of information security processes built by this vendor. To verify the reliability of the vendor, classic economic security tools can be used, including informal audits of financial documents, data requests in the Interfax-SPARK and Contur-Focus systems, and meetings with company management. To analyse the state of information security in vendors, you should prepare a questionnaire (checklist) in which you should formulate all the IS requirements of your company in the form of questions, for example: whether the company has agreed risk management and cybersecurity procedures; what are the software and vulnerability management processes; whether developers follow secure software development life cycle rules (SSDLC - secure software development life cycle) and if so, what are they; what is the process of creating documentation for products; whether static and/or dynamic software development life cycle rules are used; what is the process of creating documentation for products; what is the process of creating documentation for products; and what is the process of creating documentation for products.

To solve the problem of malicious modules deployed by vendors using technical measures, we can recommend that customer companies analyse the anomalous behaviour of installed software components, especially recently updated ones, with UEBA (user and entity behaviour analysis) and IDS/IPS (intrusion detection system / intrusion prevention system) class systems. If suspicious patterns are detected in software network interaction, when running various additional utilities, possibly downloaded ‘on the fly’ from Internet repositories, or when attempting to perform undocumented operations, you should promptly perform a check.

2- Third Party Attacks

Third party attacks are similar to the supply chain attacks discussed above, but the difference is that the attacked counterparties (suppliers, contractors, partners, even customers and clients) may unknowingly become a ‘springboard’ for hackers. This can happen in the following way: let's say your company has a contractual relationship with a contractor. This implies some kind of document flow, which will most likely be done electronically, and for this purpose, again, most likely, some kind of trusted connection will be configured - most often a VPN tunnel or an account in your internal infrastructure for an employee of the contracting organisation. Thus, some part of your IT infrastructure and internal resources will be available to your contractor - for example, shared network drives, internal web portals, some business applications. Or, the contractor's employees will connect to your IT infrastructure using an account issued to them, thus accessing your company's internal systems and resources.

Attackers who originally planned to compromise your infrastructure may take a roundabout way when they realise that your systems are sufficiently protected: the hackers will first try to attack your contractor's IT systems, which may be less secure, then, once they have a strong foothold there, they will try to reach the original target using either a configured VPN tunnel or a stolen login and password for an account with remote access to your infrastructure. In this way, the attacked company acts as a ‘proxy’ for the attackers, allowing them to access assets of interest (documents, finances, personal data) on behalf of your contractor.

This attack differs from supply chain attacks in that it can be easily prevented by applying the Zero Trust principle to all entities that appear in your IT infrastructure. This means checking all accounts, all devices, all network connections, and all running processes regardless of who initiates them. For each entity, be it an executive account, an engineer's smartphone, or even a printer in a conference room, you can calculate a scoring score of trustworthiness that is reduced when connecting from previously unknown locations (atypical cities and countries), after hours, or when there are active cyber incidents on the device. If you look at the problem more broadly, the laptop of your employee who works from home and downloads various files from the Internet to his computer outside of working hours, which then connects via VPN to the corporate network, can become a ‘proxy server’ for attackers. In applying the zero trust principle, we are guided by the paradigm of checking all entities in our IT infrastructure based on several factors such as OS version, OS updates and software patches installed, presence of a working anti-virus tool on the device connecting to the network, time of connection, country of connection, and deviations in normal device behaviour (again, anomaly and pattern analysis systems such as UEBA solutions can help).

Organisational measures, however, can also be applied to this type of attack - the questionnaire described in the previous paragraph can be used as a basis. This checklist should include questions about the counterparty company's agreed information security and risk management policies, OS and software update procedures and rules, the information security tools used, applicable legal provisions and internal regulations. The answers to these questions will help to understand the overall IS maturity level of the counterparty company, and this level should be taken into account when deciding whether or not to cooperate with this contractor, supplier or client.

If the cybersecurity requirements of the counterparty company are clearly not fulfilled, but it is necessary to interact with it, it would be very reasonable to treat all incoming information flows from this counterparty like any other unauthenticated, possibly malicious, information from the Internet. For such a counterparty you should not create accounts in internal IT systems or create a dedicated VPN channel to provide access to internal resources, but handle it like any untrusted entity from the Internet, passing it through the entire set of perimeter defences (firewalls, sandboxes, anti-virus protection, etc.). A legally correct ‘non-disclosure agreement’ (NDA - Non-disclosure agreement) should not be underestimated, which should clearly specify the measures to ensure information security when working together, the responsibility for violating this agreement, and describe the procedure for compensating potential damage from the realisation of cybersecurity risks during interaction.