Companies have solutions implemented that are designed to protect them against viruses: Strategies, concepts and, last but not least, intelligently impelemented technologies, that are kept up to date. But what is lacking more often than not is a clearly structured modus operandi when it comes to the protection of your company’s IT-infrastructure as well as emergency protocols should a virus be detected in your company. Sometimes, there are rulings concerning incident management or CERT-Scenarios, but when it comes down to reacting quickly in a coordinated and targeted fashion, protocols, checklists, tools and communication channels, to name just a few, are missing. Especially those that are concerned with combatting the threat of the virus. In this article you will find important recommendations so that you can successfully deal with viruses in a rational manner.

Subjectively speaking, it seems that the subject of virus infections has been derailed in the media, unless it’s about the currently popular spying incidents, which appear to be a favourite subject of news outlets. Thus, it’s time to get the subject back into our minds and back to its roots. Because the risks are highest, when everyone involved thinks that they’re safe.

Terminology

What I mean by saying “virus”

In general, all appearances of malware are considered to be virus attacks. The term malware stands for software that inflicts damage and is a portmanteau of the Latin word malus (English: bad or malicious) and the term ware. Malware is a collective term that covers the entire spectrum of software that is compromising systems in unwanted ways and/or intrudes systems. These programs are able to perform unwanted tasks that may or may not be damaging to our systems in either a very obvious or a hidden way. Examples of malware are the following:

• Viruses
• Worms
• Malicious Code
• Spyware
• RootKits
• Trojans (They still make up about 70% of all malware!)
• Backdoors
• Et cetera

Due to the fact that the term virus – even though it’s factually not quite correct – has established itself as a synonym for malware, I will use the term “virus” for the rest of the article in order to preserve the legibility of this article. Thus, when I’m writing about virus protection, I am writing about the protection against all sorts of malicious software.

These days, the main job of a virus is not its spread anymore. Most of today’s viruses come in the shape of a Trojan horse and are custom-tailored to spy on a system from afar or remote control them. Or both.

Special case of an incident – the virus infection:

Security incidents in this contest are occurences in which the security and integrity of the services, the data or the infrastructure of a company are affected in a negative way. Reasons for these incidents can be targeted attacks or accidental tampering. Companies are constantly monitoring their IT-infrastructure with the intent to spot security compromises and reacting to them according to their criticality.

In this article you will find advice for the handling of the incidents known as viral attacks. We are focusing on reactive actions in case of emergency. However, this articles assumes that fundamental rules in case of an incident exist and are established.

Possible cases

The occurence of a virus in a corporate environment should be categorized, applying rankings regarding relevancy and potential effects as well as dangers. The following table gives an overview of the scenarios that make sense.

The cases that require immediate action (Numbers 2 and 4) are being described in detail in this document. Cases with low or medium risk can be delegated inside the company to internal teams that deal with the issue according to standard protocols.

Modus Operandi

The succession of events to determine the threat as well as answer further questions about the incident is being structured as follows: h2. Realtime

• Recognition / Classification
• Alarm
• Immediate action / Isolation

Processing

• Intervention / Analysis
• Postvention / Post-Processing
  The Modus Operandi obviously divides itself into two phases according to the critical factor of time: In the first phase, the Realtime phase, steps are taken to recognize and classify the threat as well as alarming the instances that need to be informed. Furthermore, immediate actions are determined and undertaken in this phase. These actions will be completed in the shortest possible time in order to minimize the spread of the threat and the possible damage. The processing phase, the second phase, is not as critical when it comes to time.

Step 1: Recognition / classification

The first step of any threat management is of vital important: The recognition of the incident and the classification of the relevancy of the incident. It is up to the system administrators of the targeted area to ensure the alarming of the automated surveillance systems (Malware/Anti-virus-tools and consoles among others) are set up so that the generated messages are automatically relayed to the people in operations. Each message generated by a virus-surveillance system should also be relayed to a central instance where a complete correlation of all messages received can be performed. Thresholds should be defined that aim to increase accuracy of surveillance. These thresholds should be defined by suitably equipped teams and they are to be custom-tailored to the environment it’s used in.

If a system administrator has knowledge of an intrusion into the system, he undertakes a first classification. This classification must be based on the likelihood of a worst-case scenario as well as the potential damage associated with it. A detailed analysis will have to be done later on after the initial threat has been successfully neutralized. That later analysis may contradict the system administrator’s earlier classification. However, it is the thought of prevention that is deciding. This means: When in doubt, it is better to operate on a higher threat level than needed.

Step 2: Sounding the alarm

Before further measures can be undertaken, people need to be informed of what is going on. These are predefined stakeholders and teams. Usually, these groups are:

• Operations
• Incident Management
• IT-Security
• People in charge of the affected application
• People in charge of business
  The alarm has to sounded via direct channels of communication. The easiest channels are the phone or the face-to-face conversation. This because everyone involved gets immediate confirmation that the information has arrived at its destination. Has said placement of information been confirmed, the system administrator hands over the coordination of incident management to the predefined handlers of such things. Until the handover’s been officiated, the responsibility of the incident lies with the system administrator.

Step 3: Immediate Measures / Isolation

Depending on the urgency of an incident, the predefined person responsible decides whether or not the measures taken to combat the threat need to be sped up or not. He decides, if immediate measures – usually after receiving a recommendation from the system administrator – are to be initiated or if further escalation is needed. Decisions taken by the system administrator must be discussed with operations, application managers and people in charge of business as well as incident management teams.

In particularly critical cases, those who are causing a lot of damage in a company, Incident Management and potential BCM Protocols can call in an Emergency Team made up of other teams in the company. The person responsible for this team decides in collaboration with Incident Management, if other people in the company need to be informed or involved.

The goal is to limit the impact of the incident and stop its spread in order to minimize the negative effects of the intrusion. Should this not be feasible, other measures need to be taken, such as isolation. Should this measure be necessary, it needs to be discussed with operations, the emergency response teams and of course the security officer, the business owners and incident management.

Step 4: Intervention / Analysis

As soon as the immediate negative effects have been tackled, the incident can be thoroughly analyzed. The goal is to find out the following:

• Reason for infection
• Background
• Spread of infection
  Based on this information, there can be suggestions for solutions in order to not only clear the system of the infection, but also to ensure that such an incident will not occur again. This solution will be worked out by people who have been involved in removing the threat from the affected systems.

Documentation from this moment on is not just done by ways of Incident Management but also in the form of Lessons Learned. The system administrators are responsible for the completeness of the documentation.

Step 5: Postvention / Post-Processing

To clean up the incident in a persistent way, the solution chosen in Step 4 will be carried out. The main goal should be the prevention of the incident ever occurring again as well as the restoration of nominal operational conditions.

The findings that have been made during the combatting of the threat are to be analyzed under in a Lessons Learned process. These lessons have a place in the documentation of the incident and are to be relayed to all persons involved in the management of the incident.

Support tools

The tools that can be utilized to support the dealing with the threat are largely dependent on your company’s system and the malware. But each relevant division of the company should have clearly defined checklists and toolboxes that can be deployed in case of an incident and worked with in a systematic fashion. It is up to the system administrators to define these tools and keep them up to date.

Standardized processes and checklists

Based on the aforementioned advice, companies should define checklists and other clearly fleshed-out and defined actions that are custom-tailored for each division and for each subject. These lists and factsheets have to be short and contain a specific path to follow so that they can be used in case of crisis. Ideally, these lists are step-by-step instructions, minimalistic, based on text and mainly visual aids.

These lists and factsheets are to be checked and kept up to date on a regular basis. Also, a review of the emergency protocols should happen whenever there’s been a significant change in the system topography. There should be a review process for revised protocols.

Tools

Each affected division should have a toolbox to handle an incident.

• Product-specific Knowledgebase: A collection of information (articles, processes, White Papers, user manuals, reviews et cetera) concerning a specific product.
• Malware Scanner: Free services that analyze suspicious data as well as URLs online. It should look for viruses, worms, Trojans and all other sorts of Malware that has been identified by Anti-Virus-Software and Web Analyzers.

Summarizing overview

Summary

It is of vital importance to not only actively bother with the technology surrounding malware and Anti-Virus solutions, but to define clear structures that are used in case of an incident. Especially the illusion of safety should be avoided, simply because there is extensive anti-malware software deployed in the system and despite the fact that the classic subject of virus is not that prevalent in the media anymore. It is not enough to wish away things that you do not want to deal with. It seems prudent to plan for possible scenarios. These offer systematic points of reference and help to orientate the crisis management crew in case of an incident.

About the Author

Flavio Gerbino has been in information security since the late 1990s. His main areas of expertise in cybersecurity are the organizational and conceptual security of a company.

Links

• https://vuldb.com