The value of commitment indicators in industry

Response time to an incident is critical, and even more so in the industrial control systems, which are already critical. Knowing if a system is vulnerable to an incident in progress, or if it has been compromised or not, is an advantage that may make the difference between managing an incident and managing the chaos caused by an assumed incident. Here is where the indicators of compromise (IoC) come into play.

The excess of information received during an incident is actually as inefficient as having no information at all; the key is processing said information. The exchange of verified information, in a way which is comprehensible, technically replicable and unmistakable for all staff in charge of the management of an incident is the basis of IoCs.

An IoC is an outline, normally written in XML, where certain technical, replicable details which are linked through logical operators (AND, OR, etc.) are specified in order to prove or indicate if a system has been compromised or not. An IoC is not always exhausted; often it is necessary to create one in order to share it either within the company or externally. For that reason, we should know exactly what is considered as an IoC.

The most used IoC is the MD5 of a file, together with its creation date, size, type of file, etc. Normally this comes from the sample that triggers the attack, once this has been identified by the analysis team. As we will see, this is one more indicator and its presence may not be sufficient to indicate whether a system has been compromised. All of the evidence that we can find in our system, and attribute to the incident, should go in the IoC. There is a vast range of evidence, from the already named file hashes MD5, SHA1, etc., to other more specific evidence such as: network observables (IP, Domain, lateral movements, scans...), processes, services, certain chains in registers, etc.

There are various formats that an IoC can be written in, just as there are various programming languages. Depending on the recipient of the IoC, one or the other will be chosen, but the evidence regarding the incident will be within whichever of those IoCs. This way, we will find IoC formats with different XML outlines (STIX, OTX, CIF, OpenIoC, etc.).

The main characteristics of an IoC are:

• It is a document for the exchanging of information.
• It is a live document which is not definitive and is easily adaptable.
• It is a flexible document; it can collect all types of evidence, both that which is specific to a system and that which is general to all affected systems.

-Application cycle of an IoC during an incident, a live document which is constantly changing in a recursive way-

The great majority of companies acknowledge that they know what an IoC is, but that they do not really know either how to use them nor the potential that they have when solving, checking and preventing an incident.

In the initial phase of an incident, the first piece of evidence or indicator that is available will be the hash of the input file, and based on estimates of that, the future IoC will be built.

Let us assume that our company uses the standard OpenIoC and we do not have an IoC in this format. Really, the difficulty here lies in understanding the IoC itself, and possible actions that we can carry out for each piece of evidence in particular.

- Fragment of an IoC in a STIX format, provided by ICS-CERT for the Wannacry incident-

This fragment of an IoC shows us a piece of evidence or fact:

• The existence of a “PE32 executable (GUI) Intel 80386, for MS Windows” file type with an MD5 “5bef35496fcbdbe841c82f4d1ab8b7c2” will be our indicator of compromise.

The ACTION that we should carry out as a result of this shared information will be:

• Create a list with all the system's MD5s and file types.
• Check that the MD5 indicated in the IoC is found on said list.

The complexity of this action can vary, we can use some tools, but a concrete true or false result has to be determined regarding the evidence.

To facilitate this work, specific tools are developed to automate certain tasks. Below, the workings of some of these will be detailed:

Example 1: Visualisation of an IoC in an OpenIoC format

Let us assume that we have an IoC available which was provided by one of our reliable sources. In this example, the IoC in OpenIoC format created by Mandiant for the Stuxnet incident has been used. By simply opening the FireEye tool, IOC Editor, we can open the file and visualise its content. As the image shows, there are a series of different types of indicators (File, Driver, Certificate, etc.) with a series of logical expressions (AND and OR) which operate with them. This allows us to know about the existence of that sequence of evidence, and it determines that our system has been compromised by the Stuxnet incident.

- View, from within the IoC Editor, of an IoC created by Mandiant for the Stuxnet incident-

Example 2: Creation of an IoC in an OpenIoC format

Let us assume that we have information available regarding an incident. This information may come from any of the usual reliable channels or from our analysis team, but if the IoC has been received in an STIX format we need to convert it into an OpenIoC format to be able to work with it.

In order to do that, we will use part of the IoC in the STIX format, provided by ICS-CERT for the Wannacry incident. This IoC informs us of evidence of a compromised system in the form of a hash MD5 of a file, as the image shows.

-Example of the creation of an IoC for internal use, having the evidence drawn from a reliable source such as the ICS-CERT or of our incident analysis team-

The first step is to open the IOC Editor application and create a new, blank IoC. We will fill out the generic fields to make up the small technical file of the IoC. The second step is to add the evidence that we have available at this point, in our case, the MD5.

Its use is very intuitive. Within the body of the IoC, we should simply add a new "ITEM" of the "File MD5" type, and fill in the information on the tap on the right, as shown in the image.

Example 3: Using an IoC

In order to use the information of an IoC, first of all the information of the system must be collected. For this, we will use the execution from the IoC_finder command-line; this task may take several hours.

- Execution on IOC Finder command-line in 'collect' mode in order to collect all of the system's information-

After collecting all of the system's information, this data must be analysed in terms of the requirements for our specific IoC.

-Execution of IOC Finder in 'report' mode, where it searches for evidence of our IoC in the collected data and it reports on such-

Example 4: Resolving an incident in a "Compromised System"

To check if a system is compromised we can search for evidence by using the framework Redline.

In this example we are going to make use of a modified IoC, in which a hash of evidence for the ‘PDF_inofensivo_please_open_it.pdf’ file which was previously calculated is being searched for.

Here a specific collector is created to resolve our IoC, not all of the information is extracted; rather only the information which is relevant to resolving the IoC, therefore it is far quicker. This way, it only takes us a few minutes to check if our system is compromised.

To be able to understand an IoC, we should always bear one premise in mind: the IoC stores information about a technically acquired evidence, it does not indicate how or with which tools we can find that evidence. This gives us freedom when checking an IoC, but we should know which tool to use to check each indicator in a system pending analysis. There are specialised tools, such as the previously mentioned Framework Redline, which allow for a great number of indicators to be analysed, thus facilitating our work. However, there are more complex and more specific indicators which require the use of concrete tools. In this category we find indicators of compromise based on YARA.

IoCs BASED ON YARA RULES

The tool yara is designed for the searching of chains, therefore allowing it to identify a chain within a file in a quick and flexible way. The yara rules are the base of this tool, as within these the structure is defined which responds to which chain(s) needs to be searched for and the way in which these chains can be related. The versatility of these rules allows for the use of chains written in a text or hexadecimal format, via regular expressions or for the use of wildcards. Furthermore, logical operators are included to operate among them (AND, OR, ==, >=, etc.).

- Yara rules provided by the ICS-CERT for the Wannacry incident-

As the image shows, the structure consists of three fields and they are quite intuitive:

• "meta": This shows information regarding the author, date and why this rule has been written.
• “strings”: Chains to look for, in whatever format supported by yara.
• “condition”: Which returns a Boolean value ("true" or "false") after searching the related chains in the expressed way.

Through the rule described in "meta", the scanning motor is ordered to search all the files to see if there is a match with the "strings" chains which fulfil the "condition" expression, in which case they will come back with a "True" result.

The yara rules are known and used by many security investigators, as such they are currently considered as an indicator of compromise themselves. Some standards, such as STIX 2.0, indicate a correct way of integrating these rules in an IoC.

- IoC in the STIX standard with a Yara Rule included, provided by the ICS-CERT for the Wannacry incident-

IoCs BASED ON SNORT

One of the indicators of compromise that can help us during the containment phase of an incident is the sharing of information regarding the snort rules. Sharing this information or knowing how it is reflected within an IoC and how we should use it will be key when containing the advancement of an incident. Just as with the yara rules, the snort rules have a specific format and a motor under which they can be implemented.

Some of the standards indicate a specific way of integrating the Snort rules in an IoC.

-Reglas SNORT extraídas de CERT-EU Security Advisory 2017-012 para el incidente Wannacry-

Let us assume that thanks to one of our reliable sources we have received the snort rules shown in the image. The image shows one way of integrating them in our IoC, which can then be transmitted internally:

-IoC in STIX standard with Snort rules created for this example. SNORT rules extracted from CERT-EU Security Advisory 2017-012 about Wannacry-

In industrial settings, the tools available to test the indicators of compromise are being reduced due to the use of less common or specific operative systems. This will involve a larger effort when carrying out checks in closed settings, limiting the tools to those that the system itself has. Let us remember that the power of IoCs lies in the sharing of information related to an incident, giving those that are in charge of managing the incident the freedom of how to apply this information in their systems. The time that is saved by not repeating the work that has already been completed, checked and shared by others in a reliable IoC is an advantage when up against an incident. For example, if there is already a vaccination or a way of breaking the "killchain" for an incident, we can focus on analysing other parts of the incident (permanence, file analysis, etc.).

Having a repository of IoCs available, either those created by ourselves or provided by reliable sources (such as the ÍCARO service, currently offered by INCIBE-CERT, of the sharing of IoCs to strategic operators, institutions affiliated to RedIRIS and international CERTs), will help us to check and protect out industrial systems in the face of a determined malware. Currently more specific IoCs are used to analyse the way the malware attacks, where similarities in the behaviour of the way it infects or persists can be distinguished, this can help us to have a certain advantage in the next steps of the incident; even identifying an attacker or a family of malware, even if it is mute, or a common group which always acts in the same way.

In the examples shown, the Wannacry incident has been used as a reference. Although the actions of this last phase of this malware are visible, there are many other incidents that can go by completely undetected. Carrying out a check to rule out if our systems are compromised by using the IoCs that we have available is crucial when hardening these systems.

Learning to manage the IoCs will provide us with knowledge of our system. The use of these indicators of compromise will help us to have a series of tools available, and to improve these, which may be key in the resolving and prevention of a future incident.