Page Navigation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
Printable Version: RFC2196.PDF
RFC 2196 Site Security Handbook September 1997
5.3 Identifying an Incident
5.3.1 Is It Real?
This stage involves determining if a problem really exists. Of
course many if not most signs often associated with virus infection,
system intrusions, malicious users, etc., are simply anomalies such
as hardware failures or suspicious system/user behavior. To assist
in identifying whether there really is an incident, it is usually
helpful to obtain and use any detection software which may be
available. Audit information is also extremely useful, especially in
determining whether there is a network attack. It is extremely
important to obtain a system snapshot as soon as one suspects that
something is wrong. Many incidents cause a dynamic chain of events
to occur, and an initial system snapshot may be the most valuable
tool for identifying the problem and any source of attack. Finally,
it is important to start a log book. Recording system events,
telephone conversations, time stamps, etc., can lead to a more rapid
and systematic identification of the problem, and is the basis for
subsequent stages of incident handling.
There are certain indications or "symptoms" of an incident that
deserve special attention:
(1) System crashes.
(2) New user accounts (the account RUMPLESTILTSKIN has been
unexpectedly created), or high activity on a previously
low usage account.
(3) New files (usually with novel or strange file names,
such as data.xx or k or .xx ).
(4) Accounting discrepancies (in a UNIX system you might
notice the shrinking of an accounting file called
/usr/admin/lastlog, something that should make you very
suspicious that there may be an intruder).
(5) Changes in file lengths or dates (a user should be
suspicious if .EXE files in an MS DOS computer have
unexplainedly grown by over 1800 bytes).
(6) Attempts to write to system (a system manager notices
that a privileged user in a VMS system is attempting to
alter RIGHTSLIST.DAT).
(7) Data modification or deletion (files start to disappear).
(8) Denial of service (a system manager and all other users
become locked out of a UNIX system, now in single user mode).
(9) Unexplained, poor system performance
(10) Anomalies ("GOTCHA" is displayed on the console or there
are frequent unexplained "beeps").
(11) Suspicious probes (there are numerous unsuccessful login
attempts from another node).
Fraser, Ed. Informational [Page 50]