continuing the post mortem

Before we move on, however, we need tomake a slight update to the two DIPLlistings from last month.

Expanding the IdentificationClassDIPL is still in the refinement stage, andprobably will be for some time as investi-gators and researchers use it and refine itscapabilities. In last month’s column weused the following construct:

(Report(When

(Time 19:23:00 GMT 04 05 2003))(Initiator

(RealName ‘Jane SysAdmin’))(Observer

(RealName ‘Joe Investigator’))

The Report SID has been deprecatedand is replaced with the DetectEventSID, so the listing now looks like:

(DetectEvent(Initiator

(RealName ‘Jane SysAdmin’)(Observer

(RealName ‘Joe Investigator’)(When

(Time 19:23:00 GMT 04052003))

)

Additionally, last month, we took a fairlygeneralized view of the Identification Classin DIPL. It is possible to expand that con-siderably. That expansion, using the newDetectEvent SID, can include a more com-plete picture of the class using its onlyrequired element, Event/Crime Detection.If we were to limit ourselves to that ele-ment we can expand the listing somewhatmore. Note that we now have created fourDIPL sentences. These sentences areordered temporally.

The first sentence addresses the attackitself using the verb Attack. The secondsentence recognizes that the state of theenterprise has changed, probably due tothe attack, and uses the verb ChangeState.

17

Continuing the PostMortemPeter Stephenson

Last column we got started on an actual incident post mortem by looking at theIdentification Class of the DFRWS Framework. We characterized the identification ofthe attack using the Digital Investigation Process Language (DIPL) and then began toexpand upon the investigation by mapping (in DIPL) the discovery of an attack packetby the victim’s UK office. This week we’ll move on to other classes in the Framework.

GETTING THE WHOLE PICTURE

(And(Attack

(AttackSpecifics(AttackNickName [Name Here])

(Comment [Additional Information])(BeginTime [hh:mm:ss ddmmyyyy])(EndTime [hh:mm:ss ddmmyyyy])(FileName [Name Here])

)(Target

(HostName [Name Here]))

)(ChangeState

(Observer(RealName [Name Here])

)(OldState [Old State]

(ArchtitectureName ‘VictimEnterprise’))(CurrentState [New State]

(ArchitectureName ‘VictimEnterprise’))(When

(Time [hh:mm:ss GMT ddmmyyyy]))

)(DetectEvent

(Initiator(RealName [Name Here])

)(Observer

(RealName [Name Here]))(When


)(ManageCase


)(Comment [Additional Information – Case Notes])(When


))

Figure 1: SID Listing of a Top Level Reference Model for theIdentification Class

18

The third sentence in the sequence is theDetectEvent statement and represents theinitiator’s reporting of the event to theobserver. Finally, our investigator makesthe appropriate entry in his or her casefiles using the ManageCase verb. The foursentences are connected using the Andconjunction.

The extended listing, a complete refer-ence model for the Identification Class andits required element can be seen in Figure 1.

Inserting the incident post mortemdata discovered so far into this more com-plete reference model is left to the reader.

The Preservation ClassThe Preservation Class deals with thoseelements that relate to the management ofitems of evidence. The DFRWS describesthis class as “…a guarded principle across‘forensic’ categories.”1 The requirementfor proper evidence handling is basic tothe digital investigative process as itrelates to legal actions. There are threerequired elements in this class: CaseManagement, Chain of Custody andTime Synch. These elements use theManageCase and SynchronizeTime verbs.

Additionally, there are several atom SIDsthat support these verbs. The obviousexample is ChainOfCustody.

In last month’s column we began a slightdigression in the examination of the com-puter (“Bilbo”) recognized by the victim’sUK office as the source of the first attackpacket across the organization’s intranet.Analysis of a particular computer begins inthe Preservation Class. Because thePreservation Class is pervasive across theremaining classes, it represents a set of recur-ring requirements that are applied repeated-ly as our investigation proceeds.

The concepts inculcated in theDFRWS Framework related explicitly tothe temporal arrangement of the actualsteps in a digital investigation. First, theexistence of a digital incident is reportedand verified. Next gross data sets believedto contain possible evidence are preservedforensically. Next, possible evidence iscollected from the gross data sets, exam-ined and analyzed. That evidence is,finally, presented to the suspect(s) and/orthe finder(s) of fact.

Logically, at least one of the threads aninvestigator in our example incidentwould follow is the analysis of Bilbo.

Interestingly, this is one area where DIPLis of considerable value since it is likelythat there will be many of these threads ina complex investigation. Each investiga-tor or forensic examiner can keep individ-ual DIPL characterizations of his or herprocesses and these can be collated at theend of the investigation to provide thetotal picture.

Instead of developing listings for theremaining classes piecemeal as we have toillustrate the Identification class, from thispoint on we will offer a reference model forthe class and its required elements and theninsert the actual (but sanitized, of course)investigation data for our example incident.The reference model for the PreservationClass is shown in Figure 2. Bear in mindthat this model may, and probably will, popup frequently as we continue our investiga-tion. In that sense it is a sort of reusableDIPL module requiring only customiza-tion to the details at hand.

This listing needs a bit of explanationbefore we insert Bilbo’s information. Thecore of the class is the ManageCase verb.This verb will be seen repeatedly through-out any DIPL characterization. There areseveral possible SIDs that the verb mayinclude and we’ve shown only some ofthem here. The general rule is, if youwould put a particular atom SID’s con-tents in your case notes, use the SID herein ManageCase.

The Initiator role is very important andwill be present in all cases of the verb. Thisis the investigator. The ChainOfCustodyatom and its accompanying atoms,CaseName and EvidenceID are usuallyincluded as well to ensure that the listing isproperly annotated for the particular case.BeginTime and EndTime refer to the startand end times of the period covered by thecase notes. The When SID refers to the dateand time that the investigator made theentries in the case notes.

Link requires some special discussion.This role SID, while not always present,is important when it is. Linking is key tothe analysis class (though not required)and is an important aspect of traceability,pervasive through the Examination andAnalysis classes. The SID has a syntax ofLink [Arg1], [Arg2] where Arg1 is the start

getting the whole picture

(And(ManageCase


)(Link [Argument1], [Argument2])(ChainOfCustody [Custodian Name])(CaseName [Identifier of the Case])(EvidenceID [ID Number])

.

.

.(BeginTime [hh:mm:ss GMT ddmmyyyy])(EndTime [hh:mm:ss GMT ddmmyyyy])(Comment [Case Notes or Other Comment])(When


)(SynchronizeTime


)(ReturnCode [1|0])(When

(Time [hh:mm:ss GMT ddmmyyyy]))(BeginTime [hh:mm:ss GMT ddmmyyyy])(EndTime [hh:mm:ss GMT ddmmyyyy])

))

Figure 2: Preservation Class Reference Model

getting the whole picture

19

of a link and Arg2 is the end of the link.When using a sophisticated link analysistool in a complex case there may be mul-tiple links discovered. In that case theLink role may be used as many times asnecessary to establish all applicable linksdiscovered by the investigator or the tool.The arguments are strings.

The SynchronizeTime verb also hassome special considerations. TheInitiator is the investigator or analyst.The BeginTime is the time showing onthe log, computer or any other piece ofevidence or device containing a gross dataset of interest. The EndTime is the timeto which the BeginTime is “synchro-nized”. This is the standard time that theinvestigator will use throughout theinvestigation. It may be a fixed time suchas GMT or it may be variable such as theclock on the victim. It is important tounderstand that these times are neverreally altered. Rather the discrepancybetween the two times is normalized.

The ReturnCode indicates whether ornot the times were initially synchronized.If they were, ReturnCode is 0(zero). Ifnot, it is 1. A 0 ReturnCode results in noneed for a BeginTime or EndTime. Onlythe time that the synchronization test wasmade (When) is necessary.

Back to BilboWe have some information about Bilbothat we need to include in this class.Recall the Identification Class listing oflast month. Figure 3 shows the portion ofthat listing that reported Bilbo:

Fitting that information (and otherinformation developed by the investiga-tor) into our reference model, we getFigure 4.

Only one area of this listing needs spe-cial explanation. Note that the Link con-nects Bilbo and EU-SQLServer-2. Sincewe have included these two devices in aLink, we need to describe them fully forour case notes. We do that in the follow-ing portion of the listing:

(HostName ‘Bilbo’)(IPV4Address 192.168.15.30)(HostName ‘EU-SQLServer-2’)(IPV4Address 10.10.10.225)(UDPPort 1434)

We have not included all of the otherdetails present in the IdentificationClass listing because it is not necessaryto repeat information simply for thesake of repeating it. In this case the spe-cific descriptive data serves to clarifythe information introduced by Link.The time synchronization, as can beseen, was not required. Apparently at15:30:21 GMT on 10 May 2003 thetime on the source for the evidence log (EU-Firewall-2) was in synchro-nization with GMT. That would notbe surprising since the firewall is in theUK and it would be normal for a sys-tem administrator to synch an impor-tant device such as a firewall with sometime standard.

Next stepsOnce we have identified a gross data setthat may or may not contain evidence,our next step is to collect that possible evi-dence. There are several ways we can dothat. If the gross data set is a computerdisk, we can take a bitstream image of thatdisk. If it is contained in a log, such as thefirewall log above, we can collect the log.

(Attack(AttackSpecifics

(AttackNickName ‘Unknown Denial of Service Attack’)(Comment ‘Probably SQLSlammer’)(BeginTime 10:24:00 GMT 02 05 2003)(EndTime 10:30:15 GMT 02 05 2003)

)(Initiator

(HostName ‘Bilbo’)(IPV4Address 192.168.15.30)

)(Target

(HostName ‘EU-SQLServer-2’)(UDPPort 1434)

))

)

(And(ManageCase

(Initiator(RealName ‘Joe Investigator’)

)(Link ‘Bilbo’, ‘EU-SQLServer-2’)(ChainOfCustody ‘Joe Investigator’)(CaseName ‘Victim Org – 123)(EvidenceID VO-1)(Comment ‘Log from EU-Firewall-2’)(HostName ‘Bilbo’)(IPV4Address 192.168.15.30)(HostName ‘EU-SQLServer-2’)(IPV4Address 10.10.10.225)(UDPPort 1434)(BeginTime 10:20:35 GMT 02052003)(EndTime 19:23:00 GMT 04052003)(When

(Time 15:42:30 GMT 10052003))

)(SynchronizeTime

(Initiator(RealName ‘Joe Investigator’)

)(ReturnCode 1)(When

(Time 15:30:21 GMT 10052003))

))

Figure 3: Partial Identification Class Listing for Identification of Bilbo

Figure 4: Preservation Class Listing for Bilbo

20

events

Third IFIP CONFERENCE ON E-COMMERCE, E-BUSINESS AND E-GOVERNMENT30 September -1 October 2003Location: Guarujá, São Paulo, BrazilWebsite: http://www.cenpra.gov.br/I3E-conferenceContact: [email protected]

INFOWARCON 200330 September - 1 October 2003Location: Washington, USWebsite: www.infowarcon.com

CMS 20032-3 October 2003Location: Turin, ItalyWebsite: http://security.polito.it/cms2003/Email: [email protected]

ISSE 20037-9 October 2003Location: ViennaWebsite:https://www.eema.org/isse

INFOSECURITY CHINA21-23 October 2003Location: Bejing, ChinaWebsite: www.infosec-china.com

COMPSEC 2003 - COMPUTER SECURITY - MAPPING THE FUTURE30-31 October 2003Location: London, UKWebsite: http://www.compsec2003.com/

BIOMETRICS 2003 - 6TH ANNUAL CONFERENCE ANDEXHIBITION ON THE PRACTICAL APPLICATION OF BIOMETRICS29-31 October 2003Location: London, UKWebsite: http://www.compsec2003.com/

IDSMART 2003 - CARDS FOR GOVERNMENT AND HEALTHCARE29-31 October 2003Location: London, UKWebsite: http://www.compsec2003.com/

RSA CONFERENCE EUROPE 20033-6 November 2003Location: Amsterdam, NetherlandsWebsite: http://www.rsaconference.com/Email: [email protected]

THE CSI 30TH ANNUAL COMPUTER SECURITY CONFERENCE AND EXHIBITION3-5 November 2003Location: Washington DC, USWebsite:http://www.gocsi.com/events/annual.htmlTel: ++11 202 328 5600

IICIS 200313-14 November 2003Location: Lausanne, SwitzerlandWebsite:http://lbd.epfl.ch/e/conferences/IICIS03/index.htmlEmail: Prof.dr. Sushil Jajodia - [email protected]

INFOSECURITY 2003December 9-11Location: Jacob K. JavitsConvention CenterNew York,Website: http://www.infosecurityevent.com

Events Calendar

In the case of Bilbo, we want to treat thecomputer as an attacker, so we will collectthe gross data set from its hard drive(s).

Additionally, we will collect the fire-wall log from some period leading up tothe incident to some period following it.Looking at the Identification Class list-ing we see the apparent time frame cov-ered by the incident. The packet passingfrom Bilbo through the EU firewalloccurred during that incident. Thus, wewill select firewall logs for the entire 24hour period surrounding the incidentwith the incident about in the middle ofthat 24 hour period. This is a somewhatarbitrary selection and, depending uponthe type of investigation and incident,we certainly may want to collect a widerexpanse of logs.

SummaryThis month we extended the DIPLIdentification Class to be somewhat morecomplete and representative of the facts.This showed how the DIPL language canbe used to a greater or lesser degree ofgranularity. The reference models weconstruct are listings for idealized investi-gations in our particular area of practice.These reference models are dictated bylocal investigative custom, case law andstatute law where we practice. There isno “one size fits all”.

Next month we will proceed to theCollection Class and continue with ourcharacterization of Bilbo. We will seehow the Preservation Class elements arepervasive, how to show the results of tak-

ing a bit-stream image and how weensure that we have the authority to con-duct our investigation.

References1Digital Forensics Research Workshop.“A Road Map for Digital ForensicsResearch 2001.” Digital ForensicsResearch Workshop 6 November (2001):

About the author

Peter Stephenson, is currently ExecutiveDirector of the newly formed InternationalInstitute for Digital Forensic Studies afterformerly being CTO of QinetiQ TrustedInformation management division. Peterholds a BSEE and currently is a Ph.D. can-didate at Oxford-Brookes University.

continuing the post mortem

Documents