1. Introduction

This runbook is the TU Oeucumene IT Operations guide to handling security incidents, where it is a matter of finding ongoing attacks that give rise to (or might be expected to give an) operational impact on systems.

The purpose of this runbook is to provide technicians and major incident owners, as well as other related to Situation Management into the toolbox that the business has access to in connection with attacks of this nature.

It is also the intention that the guidance is used for ongoing write-down of notes in relation to decisions made, so that later reporting is simplified. This runbook must never take precedence over the applicable security regulations and operational plans.

If a conflict with the general provisions is found during a review below, Security must be informed immediately.

It is implicit in several decision points that a given decision can be GO / NO-GO for initiating measures to counter ongoing threats. However, in case of doubt, the document should always be reviewed completely so that the incident is 360 degrees covered in terms of emergency preparedness.

2. Phase 1: Overview

In this phase, the attack is detected and the emergency preparedness is activated. The roles are defined.

Step 1: The emergency preparedness is activated

A security incident is established, either in the form of direct contact from the customer or from the surveillance. Monitoring can take place e.g. of syslog (eg exceeding thresholds of max. 300 encrypted files per 15 min) and gives an alarm if threshold is exceeded.

The instructions for handling incidents are always used here.

Emergency preparedness is activated. An MIM / Coordinator and persons are appointed for the other tasks.

The procedure for Major Incident is always used here.

Step 2: Identify the type of threat

It is important that agreement is reached here on the type of attack in question:

• Virus / malware - foreign, malicious code accessed to the customer's systems via mail, web pages or external devices (eg USB keys).
• Ransomware - foreign, malicious code that has been accessed by the customer's systems, usually via an infected file that the user has gained access to via a seemingly innocent email. Once a system has been infected, files on shares and servers will be encrypted with a virtually unbreakable encryption key. The backers, together with the encrypted files, enclose instructions on how they can be unlocked, against payment of a larger amount of money.
• Mailspoofing - sending mails with a masked sender address so that it apparently comes from a (ancestry) known sender. Mail contains either SPAM, or a link to an external site from which a worm is installed. The worm reads the user's contacts and sends a new email with the same link, however with the current user's email address.
• DDOS - simultaneous sending of a massive number of data packets from a large number of computers (often botnets), which overloads i.a. company firewalls. Backers contact the company, and offer to stop the attack against paying a larger amount of money.
• Hacking - Unauthorized access to the company's network has been gained, either through the exploitation of vulnerabilities in the infrastructure or through cracking of passwords.

Appendix 8.1 must be completed here.

Step 3: Impact

First of all, the affected environment must be identified:

Appendix 8.2 must be completed here.

Step 4: Identify Ground Zero.

In this step, an attempt is made to clarify how the system has been infected. Often the user has an idea of ​​how it happened, but if you are on a bare bottom, the type of attack from Step 1 can often give an idea.

In most cases, it is the click on a malicious link in an email that is the cause. The next step is to identify from which account it happened. In the case of Ransomware, the account can be found by examining which account (s) have encrypted files.

Appendix 8.3 must be completed here.

3. Phase 2: Mitigation

This phase aims to mitigate, minimize or eliminate the threat and its consequences.

3.1 Virus / Malware, Ransomware or Mailspoofing:

Step 1: Disable lanman server

Disable the lanman server service on file servers (via script). Stopping this service stops all writing and reading to the file servers and prevents multiple files from being modified or encrypted.

Step 2: Account disables

If Ground Zero is identified, access from here must also be restricted. The user's account disables in AD. In the case of a stand-alone PC, the user's PC must be peeled off the network and scanned before it can access the network again.

Step 3: Cleaning files

Bitdefender (if not already on the servers) is installed on all servers and a scan and cleaning is performed.

Step 4: Deleting infected mails

If Ground Zero is identified as an e-mail, permission must be obtained from the user to perform a scan of all mailboxes on the domain for other mails with the same content. Scanning is done via the developed script.

If the search is positive, the found mails will be permanently deleted. Alternatively or as a supplement, the web page where the worm or script is located can be closed. This can e.g. happen in DNS and / or at firewall level.

Appendix 8.4 must be completed here.

4. Phase 3: Restore

In this phase, the systems are restored to their original state.

• Previous version
• Actual backup
• Snapshots

Appendix 8.5 must be completed here.

5. Reporting the incident

Before the incident ends, it must be reported in the normal reporting of the operation. It must be assessed whether there is a security incident which should be reported in a security report and registration in Service Desk System (SDS).

Appendix 8.6 must be completed here.

6 Protection (preventive measures)

The purpose of this phase is to secure the business in the future against similar attacks.

On the Server side

• More thn one AV solution?
• IDS/IPS systems?

On the Network page

• Elderberry umbrella?
• SPF
• NAC?
• 802 1x?

7. Closing of the incident

The incident must be closed and it must be acknowledged that the incident has been mitigated and that the root cause has been identified. Reports from external stakeholders may be included as part of the reporting to the customer and relevant authorities or organizations must be contacted.

Appendix 8.7 must be completed here.

8 Appendix 1 - Checklist

The following serves as a logbook for use in documenting the activities of the event. Relevant decisions must be documented at each incident, as the decisions are subsequently used to report the incident and for learning in connection with the prevention of similar incidents in the future.

8.1 Identification of threat type

• Decision point 1: What type of attack is this?
• Decision point 2: Has the attack been verified and must it be combated?
• Decision point 3: Who are the contact persons at the customer?
• Decision point 4: Is the case created as a security incident in the Service Desk System and with which id?
• Decision point 5: What has been done to stop infection in the initial phase?

8.2 Impact

• Decision point 1: Has the extent of the affected environment been identified? To what extent are we affected? Number of files, immediate criticality
• Decision point 2: Is the attack still ongoing?

8.3 Identification of Ground Zero

• Decision point 1: What / who is ground zero?
• Decision point 2: Are there other users infected?

8.4 Mitigation

• Decision point 1: Is LANman server disabled (enter name)
• Decision point 2: Are relevant Accounts disabled (specify which)
• Decision point 3: AV installed and scanning and cleaning is performed
• Decision point 4: Is Ground Zero identified (specify where / what)
• Decision point 5: Scan all mailboxes (documents who we have spoken to and attach any email as an attachment)

8.5 Restore

• Decision 1: What type of backup?
• Decision 2: Contact person for backup
• Decision 3: Schedule for recovery
• Decision 4: Are there any concerns? (Plan B) ??)

8.6 Reporting

• Decision 1: Has there been raised an Event in the Service Desk System?
• Decision 2: Do we have a security incident and is it reported to Service Desk and Security dep. if necessary?
• Decision 3: Does the incident give rise to the implementation of further initiatives internally?

8.7 Closing

• Decision point 1: Can root cause be identified?
• Decision point 2: Have reports been received from external collaborators?
• Decision point 3: Which external parties must be informed - Authorities (CERT), the Police, others?
• Decision point 4: Can the case be closed?