[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-grip-prot-evidence-01.txt
- To: grip-wg@TransSys.COM
- Subject: Comments on draft-ietf-grip-prot-evidence-01.txt
- From: Bill Woodcock <email@example.com>
- Date: Mon, 27 Mar 2000 21:59:14 -0800 (PST)
- Comment: grip-wg mailing list add/drop requests to Majordomo@TransSys.COM
Sect 1, para 2: missing lines from middle of paragraph.
Sect 2:"Generate an automatic transcript... not on the media that is
part of the evidence." If the attack is ongoing, obviously scripts
and binaries used to generate the output should not be on the media of
the machine under attack, nor should the process names call attention
"When confronted by a choice between collection and analysis..." I
think it might be useful to state the priorities as three, rather than
two: 1) Collection, 2) triage, that is, selective discard to keep
collection manageable, and only then 3) analysis and discard of the
original data. The only valid reason for discard of original data is
that it is too large to store.
Sect 2.1: Perhaps add "Physical
configuration/architecture/state/topology" whatever terminology you
like, on the end of the list.
Sect 2.2: Forensics CD, or within an ssh shell from a machine set up
for the purpose of forensic examination of other machines, across the
Sects 4.1 and 4.2: Perhaps cryptographic signatures and signed
timestamps of the data or disk image are a good way to ensure no
meddling during custody handoffs. I know that several of the NTP
clock vendors offer products and services which provide
cryptographically timestamped signatures of data files. This is the
use they intend. This also allows the image to be stored on
network-attached storage, rather than on a mirror of the original
Sect 5: Are you sure it's a good idea to leave your forensics scripts
readable on the attacked system? That just tells the attackers what
to do to cover their tracks.