Incident Response

The UniMS-CERT supports IT security officers (IV-SB) and system administrators in dealing with technical and organizational aspects of incidents. In particular, it provides support or advice on the following basic steps of incident handling (as per DFN-CERT [de]):

1. Preparation

For preparation organizational units have to compile contact lists with contact persons, documentation on supervised systems and ideally create emergency plans for different scenarios. More detailed information can be found in section Proactive Activities.

2. Incident Discovery

The discovery of a security incident is the first step in its treatment. Often it is not easy to decide if an incident exists or not. To decide this, one should proceed systematically and be guided by incident checklists (see DFN-CERT Linux checklist [de] and Windows checklist [de]).

3. Incident Analysis

The analysis deals with the clarification of the circumstances of the security incident as well as with the coordination of further proceedings with all involved parties. In addition to colleagues, this also includes supervisors, customers as well as administators and users of the affected systems and applications. Other stakeholders may include their lawyer or investigative authorities (specifically, when legal action is required or reported), the press office, ISPs, manufacturers (e.g., for patches), and possibly other CSIRTs.

To clarify the extent of the incident, the following questions should be discussed:

  • When and where did the incident happen?
  • What exactly happened?
  • Who is involved and who is the attacker?
  • How was the attack executed? Which vulnerability has been exploited?
  • What damage has been done so far? What further damage can be expected?

4. Containment

Containment is about protecting the system from further damage from the incident and eliminating the vulnerability. Often a final solution to the problem is not immediately possible. For example, patches are not allowed during service (Service Level Agreements) or you do not want to cancel running jobs / experiments. Nevertheless, it is important to prevent further damage (for example, through worms, Spam, DDoS attacks, etc.), especially for third parties. Sometimes containment is even the only option left because there is no "final" solution, e.g. during a DDoS attack. Containment measures need to considered very carefully so as to not cause more damage by those measures (for example by shutting down services) than the attacker would (potentially) cause. Some actions are taken only for a short time until system maintenance is possible.

5. Regain Control

Regaining control means in many cases: reinstalling. Unfortunately, this step is unavoidable, especially in the case of infestation by viruses / worms or in case of direct unauthorized system access. The containment described in the previous section has the disadvantage that the cause of the problem is not removed. The removal of backdoors or worms removes e.g. not the weak point that made it possible to break into the system in the first place. Also, you can never be sure (especially with kernel rootkits) that all the remnants of the attacker have been removed from the system.

In addition to the actual reinstallation, the hardening of the system should not be forgotten. This includes not only the installation of all security patches, but also the secure configuration of the services. Software from third-party manufacturers and self-developed software must not be forgotten. Most importantly, all passwords should be changed, both locally and within the domain if the attacker had access to the password database (LDAP server, KDC, domain controller). If weak passwords were the possible cause, the password policy should be adjusted accordingly. Also vulnerable are keys for signature or encryption, so X.509, PGP and SSH keys. If they are not changed, the attacker still could have access to VPNs, e-mail, web applications, or GRID systems.

6. Follow-Up

When emergency plans are applied, rarely everything works as planned. Therefore, after the incident, the participants should gather for a follow-up of the incident and discuss:

  • What (which measures) worked?
  • What did not work?
  • What could have been better?
  • Which (sub)plans have to be changed?
  • Which parts of the documentation are incomplete? Which possible incident types were forgotten?

The result of the follow-up are updated emergency plans and documentation, so hopefully the next time you are better prepared. In addition, the UniMS-CERT collects statistics on security incidents occurring within or involving Münster University. The members of Münster University are notified when the circumstances of the security incident require it. To request the support of the UniMS-CERT when handling a security incident, the contact can be established by e-mail. It should be noted that the level of support may vary.