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.
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:
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.
This phase aims to mitigate, minimize or eliminate the threat and its consequences.
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.
In this phase, the systems are restored to their original state.
Appendix 8.5 must be completed here.
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.
The purpose of this phase is to secure the business in the future against similar attacks.
On the Server side
On the Network page
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.
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.
Step | Documentation |
Decision point 1 | |
Decision point 2 | |
Decision point 3 | |
Decision point 4 | |
Decision point 5 |
Step | Documentation |
Decision point 1 | |
Decision point 2 |
Step | Documentation |
Decision point 1 | |
Decision point 2 |
Step | Documentation |
Decision point 1 | |
Decision point 2 | |
Decision point 3 | |
Decision point 4 | |
Decision point 5 |
Step | Documentation |
Decision point 1 | |
Decision point 2 | |
Decision point 3 | |
Decision point 4 |
Step | Documentation |
Decision point 1 | |
Decision point 2 | |
Decision point 3 |
Step | Documentation |
Decision point 1 | |
Decision point 2 | |
Decision point 3 | |
Decision point 4 |