15

We refer the reader to an excellentpaper by Pavel Gladyshev and AhmedPatel titled Finite State MachineApproach to Digital EventReconstruction. The paper appeared inthe Elsevier publication DigitalInvestigation, issue 2, on pages 130 to149. The theory proposed in this papershould join the work we’ve reported overthe past two years as foundationalresearch in the application of formalmethods to digital investigation. In thiscolumn we’ll take a look at theGladyshev-Patel technique, apply someof the concepts we’ve discussed and proj-ect a bit into the future.

What we mean by finitestate machinesIn many engineering disciplines weapply a technique called finite statemachine analysis to understand how acomplex process functions and what theoutcome of the process might be. Wecan illustrate finite state machines asgraphs very similar in form and function to Colored Petri Nets(CPNets). As with CPNets, finite statemachines have complex underlying

mathematics and may be representedusing formal logic.

When we describe a process usingfinite state machines, we view each stepof the process and assess its ability tochange the state of the system. In somecases a system state change will occur, insome it won’t. It’s the analysis of thechanges of state that help us analyzewhat really is happening in the system.

This is the premise used by Gladyshevand Patel. They describe a simple inci-dent using the narrative of the systemadministrator and then apply a finitestate machine to the problem. The out-come is that they are able to solve themystery. The interesting thing aboutthis approach is that the authors haveapplied the solution (finite statemachine analysis) successfully to a ratherabstract problem. It is this techniquethat poses the most interesting of possi-bilities: the ability to analyze an abstractset of investigative data (evidence, per-haps) using a rigorous, mathematicalprocess.

The potential solution is not withoutits difficulties, of course. As the authorscorrectly point out, the analysis processis a tedious, manual procedure today.

They have attempted to automate thesolution, but it still poses practical chal-lenges to real-world investigators solvingcases in the field. No matter, however.The concept is not only novel, it’s quitepromising. What is most likely is that, having pursued the science, theauthors have left us with an engineeringproblem: automate the data collectionprocess and feed the collected data into an analysis engine. They provide us with an algorithm to help us do that.

The Gladyshev-PatelProblemIn the problem posed by the authors,two users, and only two users, haveaccess to a printer. One user makes theclaim that she has not used and does notuse the printer. Because there is a costinvolved with using the printer, shebelieves she should not pay. An analysisof printer usage, however, casts doubt onher assertion that she has never used theprinter. The authors “interview” the sys-tem administrator and, using his obser-vations and knowledge about how theprinter and network work, apply finitestate machine analysis to prove that theindividual who claimed not to be usingthe printer was lying.

Obviously, if this approach could beused in real investigations, the paybackwould be significant. But the payback isonly significant if the knowledge, skillsand effort required to apply the formaltechnique were not greater than the pay-back for solving the case. Also, the accu-racy, consistency and reliability of thetechnique in any investigative situationmust be indisputable. Clearly, muchmore research must be done to establishboth of these issues as manageable ornot. However, here we begin thatprocess by suggesting that CPNets couldbe a path to production use of the tech-nique.

Gladyshev and Patel describe a threestep analysis process called “event recon-struction by back-tracing transitions”.The notion of transitions is a core con-

Looking ahead – what couldwe do with formal modelingof events?Peter Stephenson

Over the past couple of years we have explored several applications of formalmodeling to digital forensics and digital investigation. In our last few columnswe applied Colored Petri Nets to the problem of modeling a worm or virus infec-tion In this column we will take a look at some other research being done in thearea of formal modeling of digital events and see how it could apply to the con-cepts we have discussed here.

getting the whole picture

cept in CPNets. The three step processis:• Obtain a finite state model of the sys-

tem under investigation.• Determine all possible scenarios of the

incident by back-tracing transitionsfrom the state in which the system wasdiscovered.

• Discard scenarios that disagree withthe available evidence.

Gladyshev and Patel break the problem up into observations, observa-tion sequences and evidential state-ments. Observation is a statement thatsystem behaviour exhibited some prop-erty continuously for some period oftime. An observational sequence is aseries of observations listed in chrono-logical order, and an evidential state-ment is a sequence of observationalsequences.

We may analyze the evidential statement formally and we can testinvestigative hypotheses by applyingthem to the evidential statement. Thebottom line is that if our hypothesis does not fit the evidence, the statemachine will fail. This is no differentfrom the informal way that skilled investigators test their hypotheses.However, for complex investigations –analogous to complex systems – a formalapproach can potentially be a big boostin assessing evidence accurately and con-sistently, and arriving at a correct con-clusion.

Other methods of formalizing theinvestigative process have been suggest-ed. As an example, an extension of fault trees has been proposed as ananalysis tool. However, fault trees sufferfrom a couple of drawbacks. First, it isnecessary to make some assumptionsbased upon considerable knowledge ofthe components of the event in order to construct the tree. Second, once the tree is constructed, there is no guaranteethat it is complete and analysis using the tree is subjective. The more formal approaches in thesecolumns and by Gladyshev and Patelshow more promise once their utility isaddressed.

Using Gladyshev-Patel tosupplement the StephensontechniqueWe view Gladyshev-Patel as foundation-al research in the application of finitestate machine analysis to digital investi-gations. What we will refer to as theStephenson Technique1 (the approachdescribed in previous editions of this col-umn) involves characterization of inci-dents, investigations and informationsystems risk using CPNets and theirunderlying formalisms. It seems intu-itive that Gladyshev-Patel would be, atthe least, compatible with theStephenson Technique and, at best,would feed into it and support it completely.

In this section we explore this pre-mise and take a brief look at a poss-ible future where digital investigationswould be characterized formally andsolved analytically using a modelingtechnique.

Our first task is to apply the twoapproaches correctly. By this we meanthat the application of the technique isappropriate to the problem beingaddressed. When we commence a digitalinvestigation we approach it from a vari-ety of perspectives. One perspective is ananalysis of what actually happened. Ona simplistic level we demonstrated that inour previous columns when we discussedthe modeling of a virus or worm attack.In that approach we cared neither aboutwho did what or why the event hap-pened. All we sought to do was toexplain the event and impose possiblecountermeasures.

A second perspective is that of why andhow the event occurred. This is the nat-ural next step once the event itself isunderstood. The Stephenson Technique

thus far has sought only to model theevent, not to analyze the source, motiva-tion or attack process. While Gladyshev-Patel addresses abstract concepts such asthe results of witness interviews takenagainst known operating parameters ofinvolved systems, the StephensonTechnique addresses the pre- and post-event processes and system states tounderstand what really occurred.

Taken together with the application ofCPNets, these two approaches may offerthe promise of automating the analysis ofa digital incident. That said, and toquiet the firestorm of outcry we wouldexpect from seasoned investigators whodo not accept that investigative analysiscan be automated, we must place thatcontroversial statement in proper con-text. In that regard we state categoricallythat we do not see computers replacinginvestigators in digital incident investiga-tion. We see both techniques as a sort ofdecision support approach that allowsinvestigators to test theories and under-stand an incident and the dynamics sur-rounding it more clearly.

It is clear that these two techniques,properly applied, will require someadjustment to the way investigators gath-er and assess potential evidence and viewthe investigative process. For example,while the notion of “gut feel” is anaccepted part of the investigativeapproach of most seasoned investigators,that approach must be tempered with theability to represent such abstract think-ing in structured terms.

A second issue is the way that investi-gators test their theories of the event.When dealing in formalisms, it is impor-tant to ask the right questions in theright ways. Failing to do this can result inmisleading responses. A model may beperforming correctly, but if populatedwith worthless data it may be expected toreturn a worthless result. One solution,of course, is awareness. Investigatorsmust know how to collect and applyinvestigative data. However, even withthat, tools such as this will need a user-friendly front-end to help investigatorscontinue to the extent practical in theirfamiliar paradigms.

16

getting the whole picture

We do not see computers replacing

investigators in computer investigations

17

One solution to the maturing of thetwo approaches is to develop a taxonomythat offers a consistent way of expressingcommon investigative concepts. Thereare several possible sources for such a tax-onomy. The Digital Forensics ResearchWorkshop (DFRWS) has developed andis maturing a framework2 for digitalinvestigation that, while not exactly a tax-onomy, is a very good start. Another goodapproach is the “Common Language forComputer Security Incident Information”suggested by Howard and Meunier.3 TheCommon Language is, in fact, a taxono-my but may not prove complete enoughas it stands.

Both possibilities will require someeffort to make useful as a framework forusing with Gladyshev-Patel and theStephenson Technique. However, in aproduction environment it is not practicalto exploit either approach without a con-sistent manner of expressing input data.

The contribution of the StephensonTechnique is the formalization of the end-to-end process using CPNets. In earliercolumns we described the End-to-EndDigital Investigation (EEDI) process.EEDI provides a platform upon which togather and analyze appropriate evidence.Using Gladyshev-Patel concepts such asevent reconstruction by back-tracing

transitions and their formal definitions ofobservational sequences and evidentialstatements, we may refine the EEDIprocess and, using the StephensonTechnique, apply those formalisms toCPNets resulting in a complete picture ofincident, investigation and outcome. Wemight view the new, extended, process asshown in Figure 1.

In Figure 1 we take digital evidence,results of interviews and knowledge aboutthe operation of involved systems and usethose facts as input to a Gladyshev-Patelanalysis. The input format follows a pre-determined investigative taxonomy andthe results of the analysis are used as inputto an EEDI analysis as we have describedin earlier editions of this column. Theresults of the EEDI analysis are used asinput to the Stephenson Technique whichuses CPNets (the specific tool set isCPNTools) to develop a formal model ofthe investigation and the event in theirentirety.

This provides a decision support plat-form for the investigator to use to testinvestigative hypotheses. A correcthypothesis ends the process. An incorrectone returns the investigator to the begin-ning to review evidence, add new evi-dence or revise models. The cycle contin-ues until an investigative hypothesis is

validated. It is important to note that thisapproach begins with evidence which isnot, really, where the EEDI processbegins. EEDI begins with data so there isan implied mining of the data for evi-dence. That being the case, it is likelythat a practical application of Figure 1actually would include portions of theEEDI process at various points through-out.

ConclusionsIn this column we have put on ourFuturist hat and explored practical appli-cations of some emerging applications offormal methods to the digital investiga-tive process. It is reasonable to consider,as well, the application of these tech-niques to information systems risk man-agement, post-incident root cause analy-sis, disaster recovery and analysis and sev-eral other quasi-investigative tasks per-formed by information security, audit, IT,and fraud analysis professionals on a dailybasis.

The clear benefit of these approaches isthat they can be made consistent, reliableand repeatable. The down side is thatthey are difficult to learn and require con-siderable effort and knowledge to use.

getting the whole picture

Figure 1 - Flow of Automated Investigation Decision Support Using Gladyshev-Patel as an Input to EEDIand the Stephenson Technique for Testing an Investigative Hypothesis

There is little doubt, then, that, in orderto make them truly useful, a tool set thatrequires little new knowledge or skill onthe part of the operator must be developed.

We trust that you have enjoyed ourexcursion into the application of for-malisms for information security tasksover the past 24 months. We hope itassisted you in in Getting the WholePicture.

References

1 The Stephenson Technique isdescribed in detail in provisionalpatent titled “A Formal Process forInformation Systems Risk Analysisand Management”, in Stephenson,Peter, “Modeling of Post-Incident Root Cause Analysis”.International Journal of Digit Evidence 2003;2(2), and in various

editions of this column over the past24 months.

2 Available at http://home.comcast.net/~prstephenson/DFRWS.htm

3 Howard, John D., Pascale Meunier.“Using a ‘Common Language’ forComputer Security incidentInformation”, Computer SecurityHandbook, fourth edition, ed.Bosworth and KabayJohn Wiley &Sons, 2002. Chapter 3.

18

email monitoring

Email is a key part of both our businessand personal lives, thanks to its speedand ease of use. It can be difficult tobelieve that we survived for so longwithout it – especially with the vagariesof the postal service! But as the man-agers responsible for maintaining cor-porate email deal with growing trafficvolumes and increasing levels of spamand virus-infected mail, they encountera minefield of legal traps and regulatory pitfalls.

In businesses today it is ultimately theresponsibility of board members toensure that laws are being adhered to, toprevent legal or financial repercussions.Some of the biggest problems occur dur-ing the monitoring of corporate email.Many firms use tools to identify spamemails, stop viruses or flag-up inappro-priate or illegal use, but it is essentialthat, at the same time, the individual’sright to privacy is protected to avoidfalling foul of the law.

Laws, and regulations Over the years, a number of differentlaws and regulations have been writtenin the UK which cover the subject ofemail monitoring, but unfortunately

there is overlap and contradictionbetween them. There are regulations toprotect individuals and their right toprivacy with regards to electronic com-munications and information; howeverthese are often inconsistent with thosedesigned to help employers or lawenforcement agencies. And that is just inthe UK: the situation for companiesoperating on a global scale is immeasur-ably more complex.

The different laws and regulations,although originally written to providestructure and guidelines, actually causemore confusion than necessary, and evenrisk scaring companies off doing anymonitoring at all. However, even notdoing any monitoring still leaves thecompany vulnerable as it has a legal obli-gation to protect employees from offen-sive material.

In 2000, the UK government passedthe Regulation of Investigatory PowersAct (RIPA) which clarifies how and whyorganisations can monitor individuals,and protects employees’ rights. It out-lines that businesses must state if emailsare going to be monitored, and the rea-son for that monitoring, but accepts thatcompanies do have the right to capture information under certain

circumstances. On the other hand, itplaces an obligation on individuals andorganizations - with certain safeguards -to make data and encryption keys avail-able to police or security services in thecourse of investigative work.

Legal conflictHowever, RIPA’s declaration that com-panies have the right to collect informa-tion conflicts with the Human RightsAct (HRA), which is focused on an indi-vidual’s right to privacy.

To make things even more complex,the UK Data Protection Act (DPA) safe-guards the rights of individuals regard-ing information relating to them. Thismeans that any details stored about aperson electronically must not only beaccurate, but must be available to thatindividual on request. This is known asSubject Access, which unsurprisingly canbe a logistical nightmare to actuallydeliver. In addition, any company stor-ing personal information is legallybound to provide acceptable levels ofboth physical and logical security to pro-tect personal data.

It is clear that there is no consensus inthe UK regarding the legal issuesinvolved, and, due to a lack of legalactivity challenging these rulings, veryfew precedents have been set to helpcompanies steer a course through thelegal minefield. The different acts aredesigned with different goals in mind,resulting in most businesses not know-ing which way to turn.

For members of the board this can bea real problem. Not only are they

Legal email – email monitoring and UK legal landminesKen Watt, Consultancy Director, INSL