Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Tip of the Day: Logbooks SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Tip of the Day: Logbooks
Over the years I found the use of a logbook, either on paper or electronically an essential instrument in managing (security of) devices.  They can be useful for more than just managing security but they shine during emergencies. Since most emergencies with devices involve loss of either Confidentiality, Integrity, or Availability, the use of these logbooks is highly related to security.
In some organizations the system or network administrators are the ones who are in the best position to keep them up to date and working properly, sometimes making it hard to coordinate with a different set of security people.

What should be in such a logbook ?

Hardware and configuration


You need to be able to identify a device should it get lost, stolen or otherwise compromised. I've found it useful for administrators who are less familiar with certain devices to still locate the right device and be able to power toggle a completely unresponsive system back to life. This information can be of great value and is easy to obtain during physical installation and initial staging.
  • Hostname
  • Location
  • Brand
  • Model
  • Options: CPUs, memory, disks ...
  • Serial numbers
  • Host ID
  • ...


Information on the network connections.
  • Interface
  • Connects to: device, port
  • Speed/Duplex
  • MAC address
  • IP addresses (use CIDR, network and broadcasts written out, remember you'll use it in an emergency!)
  • FQDN (DNS name)


Filtering used by this device such as packet filters, their configuration, how to turn them on and off and how to get a closed emergency filter installed.


Detailed information on disks, partitions and slices. Make sure to add what they are used for and the information needed to select the right replacement drive.

The easiest is to print out the information from the OS. E.g.:
$ sudo fdisk wd0
Disk: wd0 geometry: 24321/255/63 [390716865 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 1 - 24320 254 63 [ 63: 390716802 ] OpenBSD

$ sudo disklabel wd0a
# /dev/rwd0a:
type: ESDI
disk: ESDI/IDE disk
label: WDC WD2000JD-00G
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 16383
total sectors: 390721968
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

16 partitions:
#        size   offset    fstype   [fsize bsize   cpg]
  a:  4194225       63    4.2BSD     2048 16384   328   # (Cyl.    0*- 4160)
  b:  1048320  4194288      swap                        # (Cyl. 4161 - 5200)
  c: 390721968        0    unused        0     0        # (Cyl.    0 - 387620)
  d:  4194288  5242608    4.2BSD     2048 16384   328   # (Cyl. 5201 - 9361)
  e:  4194288  9436896    4.2BSD     2048 16384   328   # (Cyl. 9362 - 13522)
  f: 377085681 13631184    4.2BSD     2048 16384   328  # (Cyl. 13523 - 387615*)

$ mount
/dev/wd0a on / type ffs (local)
/dev/wd0e on /home type ffs (local, nodev, nosuid)
/dev/wd0d on /var type ffs (local, nodev, nosuid)
/dev/wd0f on /var/www type ffs (local, nodev, nosuid)


Make sure you have all the information to deal with raid devices you might have. As most often this is proprietary in format, giving guidance is hard. But make sure you have all information needed to replace drives, use hotspares, rebuild partity and reconfigure them in the same way as they were should the configuration information get lost.


Operating System

This information changes with reinstallation but stays as a while fairly static
  • Brand
  • Version
  • Revision (if any)
  • Installation time choices indicating installed components.
  • ...

OS patches

This information changes a lot in modern OSes. An informational paragraph on how the patches are applied now and how they are done normally should suffice. Having a log of what was installed when is important.


This section is what you installed as applications on the machine. It should include the important choices made during installation so that people coming after the installer could redo the installation in the same manner. This section must be expanded as time goes by and more applications are installed or removed.
If activation keys are used they should be copied here as well or at least clearly indicated how they can be obtained in an emergency.

Service contracts

Information on all hardware and software or other service contracts related to this machine. It should include the needed procedures, contract numbers , FAX and phone numbers, and any reference the other party will demand before they will start their service execution.


A tricky part in larger organization to get right and it might make use of automation if you have many. Basically you want to show:

Services offered

Services the device offers. It should list what needs to be in place, how to test that the services are working, and a list of machines and/or other services depending on them. A prediction of what happens when the services are lost can be very valuable information when dealing with incidents and their needed communication.

Services used

Devices typically need a bunch of services of other machines. Having such a list with simple test to see if those services perform their intended task can be a great timesaver.


Any incident this machine was involved in, should be documented in detail. Even simple hardware failures should be documented as they can lead to discover a trend that could indicate a problematic device and trigger a need for replacement.
  • operator
  • date&time
  • what was observed
  • what was done


Procedures can be either detailed procedures or pointers to specifics. Remember you'll need them under stressy conditions, so make them easy to find and execute. Make sure they list when and by whom they were last actually tested.

Emergency access

How does an authorized person not having or remembering the passwords access the system in an emergency (e.g a sealed envelope in a safe).

Check Backup status

How do you see what backups have been made, what they contain etc.

Normal backup out of sequence

How do you make a backup use normal means for backing up ?

Emergency backup

How do you make a backup in an emergency ?

Restore of data

How do you restore a single file or directory ?

Restore of full system

How do you restore a full system ?

Raid procedures

As needed.

For additional inspiration refer to Security Consensus Operational Readiness Evaluation check lists and incident forms and
Swa Frantzen -- Section 66

760 Posts
Aug 15th 2006

Sign Up for Free or Log In to start participating in the conversation!