In CC 18 we discussed incident handling that encompasses planning for and implementing Incident Response procedures. Fortunately, or unfortunately depending on perspective, there is a large body of both experience and material that exists. [1]

The quick win list [1] provides a great initial roadmap to success for this control some of which I would like to call out but first, evidence handling procedures.

A couple of employers ago, I was tasked, along with a couple of other talented Security Engineers, with updating the evidence handling procedures for the company. It is important to understand that during an incident that evidence collection is just as critical as getting to the bottom of what happened.

One rule that we adhered to, even when we were sure that an incident was downgraded to an “Event”, is treat it as if it was going to be reviewed in a court of law.

Interesting that there is also an RFC you can follow in this regard [2]. RFC 3227 outlines some guidelines for Evidence collection and archiving.

I would like to call out section 2.4 of RFC 3227 and show this as some basic things to think about when doing incident handling:

2.4 Legal Considerations
Computer evidence needs to be
- Admissible: It must conform to certain legal rules before it
can be put before a court.
- Authentic: It must be possible to positively tie evidentiary
material to the incident.
- Complete: It must tell the whole story and not just a
particular perspective.
- Reliable: There must be nothing about how the evidence was
collected and subsequently handled that casts doubt about its
authenticity and veracity.
- Believable: It must be readily believable and understandable
by a court.

So, in honor of our critical controls month, I would like to know what you do for evidence handling.