DataMuseum.dk

top - metrics - download

    Length: 5143 (0x1417)
    Types: TextFile
    Names: »handling.tex«

└─⟦4f9d7c866⟧ Bits:30007245 EUUGD6: Sikkerheds distributionen
    └─⟦36857feb3⟧ »./papers/Security_Primer/primer.tar.Z« 
        └─⟦5c5f5f2d8⟧ 
            └─⟦this⟧ »handling.tex« 

TextFile

\section{Incident Handling}

The difficulty of handling an incident is determined by several
factors.  These include the level of preparation, the sensitivity of
the data, and the relative expertise levels of the attacker(s) and the
defender(s).  Hopefully, preliminary work in terms of gathering tools,
having notification lists, policies and most importantly backup tapes,
will make the actual handling much easier. 

This section is divided into three parts.  The first of these deal
with general principles.  The second presents some particular (simple) techniques
that have proven useful in the past.  Finally, the third section
presents a description of a simulation exercise based a set of real attacks.


\subsection{Basic Hints}

There are a number of basic issues to understand when handling a
computer incident.   Most of these issues are present in handling most
of these issues and techniques are relevant in a wide variety of
unusual and emergency situations.

\subsubsection{Panic Level}  

It is critical to determine how much
panic is appropriate.  In many cases, a problem is not noticed until
well after it has occurred and another hour or day will not make a
difference. 

\subsubsection{Call Logs and Time Lines} 

All (or almost all) bad situations eventually come to an end.  At that
point, and perhaps at earlier points, a list of actions and especially
communications is needed to figure out what happened.

\subsubsection{Accountability and Authority}

During an incident it is important to remind people what decisions
they are empowered to make and what types of decisions that they are
not. Even when this is explicitly discussed and formulated in a
contingency plan, people have a tendency to exceed their authorities
when they are convinced that they know what {\it should\/} be done.



\subsubsection{Audit Logs}

Audit logs need to be copied to a safe place as quickly as possible.
It is often the case that an attacker returns to a computer to destroy
evidence that he had previously forgotten about.

\subsubsection{Timestamps}

The second most powerful tool (second only to backup tapes) in an
incident handlers arsenal is timestamps.  When in doubt as to what to
do, try to understand the sequencing of the events.  This is
especially true when some of the actions will change the value on the
system clock.



\subsection{Basic Techniques}

There are five basic sets of techniques for understanding what has
happened.  

\subsubsection{Differencing}

Differencing is that act of comparing the state of a part of the
computer system to the state that it was in previously.  In some cases
we have compared every executable system file with the corresponding
file on the original distribution tape to find what files the attacker
may have modified.  Checksums are often used to decrease the cost of
differencing. Sometimes people look only for differences in the
protection modes of the files.


\subsubsection{Finding}

Finding is generally cheaper than differencing.  Finding is the act of
looking at a part of a computer system for files that have been
modified during a particular time or have some other interesting
property.  


\subsubsection{Snooping}

Snooping is the act of placing monitors on a system to report the
future actions of an attacker.  Often a scripting version of the
command line interpreter is used or a line printer or PC is spliced
in to the incoming serial line.

\subsubsection{Tracking}

Tracking is the use of system logs and other audit trails to try to
determine what an attacker has done.  It is particularly useful in
determining what other machines might be involved in an incident.

\subsubsection{Psychology}

A wide range of non-technical approaches have been employed over the
years with an even wider range of results.  Among these approaches have
been leaving messages for the attacker to find, starting talk links,
calling local high school teachers, etc.

\subsection{Prosecution}

Prosecution has historically been very difficult.  Less than a year
ago, the FBI advised me that it was essentially impossible to succeed
in a prosecution.  More recently, FBI agent Dave Icove, ({\tt
icove@dockmaster.cnsc.mil}, 703--640--1176) has assured me that the
FBI will be taking a more active role in the prosecution of computer
break-ins and has expressed interest in lending assistance to
investigation where prosecution is appropriate.

\subsection{Exercise}

The bulk of this class hour is reserved for an incident handling
simulation.  A facility will be described.  A consensus policy for
incident handling will be agreed upon and then the simulation will
begin. 

During the simulation, the effects of the attackers actions and those
of third parties will be described.  The participants can choose
actions and take measurements and will be informed of the results of
those actions and measurements.  In a sufficiently small working
group that had several days, we would run a software simulation; but
as many of the actions take hours (e\. g\. a full system comparison
to the original distribution), we will proceed verbal in the short
version of this workshop.