Post Process

Everything to do with E-discovery & ESI

Archive for the ‘Forensics’ Category

PI Licensing Laws in Texas and Michigan Continue to get Press

Posted by rjbiii on July 31, 2008

This time, the CEO (and former litigator) of Catalyst, John Tredennick, writing in Law Technology Today (reg’n may be required) passes comment:

Two states have recently enacted statutes that make it a crime for unlicensed individuals to engage in computer forensics. Texas passed a law that would give regulators the power to impose up to a year in jail and a $14,000 fine on people doing “computer investigations.” Michigan went a bit further. On May 28 th of this year, Governor Jennifer Granholm signed into law a bill that makes unlicensed computer forensics work in Michigan a felony punishable by up to a four-year prison term, damages of up to $25,000 and a criminal fine of up to $5,000.

Read the article for details, but Tredennick summarizes the Texas law thusly:

As I read these [Regulatory Agency] opinions, there is some comfort for people doing routine electronic discovery collection but not if there is a forensic or testimonial aspect to the collection. There is a strong suggestion that experts who are called to testify in Texas courts regarding examinations of electronic files better be licensed in Texas. If you don’t have a license, you might be pulled off the stand and escorted to the hoosegow for an extended visit.

Seriously…not the hoosegow!

With respect to Michigan:

How far does this reach?

Good question. If I were a forensics expert and offering testimonial services, I would be pretty nervous about this law. The Act seems to focus on:

Computer forensics to be used as evidence before a court, board, officer, or investigating committee.

Most electronic discovery is focused on collection rather than forensics and an argument could be made that your eDiscovery efforts are not about forensics but rather the collection of relevant evidence for review. But do you want to make this argument to some Michigan criminal court? I wouldn’t.

Post Process has previously blogged on this issue (here, here, here, here, here, and here).

Advertisements

Posted in Articles, Data Collection, EDD Industry, Forensics, Laws, Michigan, Privacy, Texas, Vendor Liability | Tagged: , | 2 Comments »

Trend in Licensing for Computer Forensics Continues with New Michigan Law

Posted by rjbiii on June 18, 2008

Post Process has already remarked on a Texas law that implies that computer forensics experts must have a private investigator’s license. Now it’s Michigan’s turn.

Joe Howrie has written an article on a new Michigan law that requires people engaging in “computer forensics” to acquire a license as a private investigator:

“According to the state of Michigan Web site, Michigan House Bill 5274, “the professional investigator licensure act,” was signed into law by Gov. Jennifer Granholm on May 28.

According to the terms of the act, it becomes effective immediately (Sec. 29) and it is now a felony punishable by up to a four-year prison term and a $25,000 fine for a person to engage in computer forensics in Michigan unless that person is licensed under the act or falls within one of its exemptions (Sec. 3(3)).”

The exemptions mentions attorneys, but not staff working under a lawyer’s supervision, although Howrie feels that staff would be exempted:

Presumably, the attorney exemption extends to staff employed to assist an attorney as attorneys have historically used support personnel for litigation. If the legislature had intended that lawyers could only use support staff with whom the lawyers had employer-employee relationships, the employer-employee language from 4(e) would also appear in the 4(a) lawyer exemption section.

This particular law, driven evidently from privacy concerns, seems broader and harsher than others we’ve seen recently, including the Texas law. Questions abound: if I am in Houston, and I use an application to pull data from a server in Michigan, for the purposes of preparing some of that data for submission to a court as evidence, am I in violation of the statute? If I merely hold myself out as a computer forensics professional, do no business in Michigan directly, but engage in “forensics” elsewhere, are there any consequences (minimum contacts and the web?).

While protecting the public and privacy is important…is a Private Investigator’s license really the best vehicle for this sort of regulation? Stay tuned…

Posted in Articles, Data Collection, Forensics, Laws, Legislation, Privacy, Trends, Uncategorized | Tagged: , , | 1 Comment »

Forensically Sound?

Posted by rjbiii on July 28, 2007

According to ISec Partners, Inc., forensic software (specifically, EnCase and The Sleuth Kit) that many forensics teams use is not as secure as it ought to be. From a post on D’Technology Weblog:

The San Francisco security company has spent the past six months investigating two forensic investigation programs, Guidance Software Inc.’s EnCase, and an open-source product called The Sleuth kit. They have discovered about a dozen bugs that could be used to crash the programs or possibly even install unauthorized software on an investigator’s machine, according to Alex Stamos, a researcher and founding partner with Isec Partners.

Researchers have been hacking forensics tools for years, but have traditionally focused on techniques that intruders could use to cover their tracks and thwart forensic investigations. The Isec team has taken a different tack, however, creating hacking tools that can be used to pound the software with data, looking for flaws.

ISec has yet to divulge the exact nature of the flaws, but will reveal some details at the upcoming Black Hat convention in Las Vegas. The Black Hat website says that the Isec discussion will make these points:

  • Forensic software vendors are not paranoid enough. Vendors must operate under the assumption that their software is under concerted attack.
  • Vendors do not take advantage of the protections for native code that platforms provide, such as stack overflow protection, memory page protection), safe exception handling, etc.
  • Forensic software customers use insufficient acceptance criteria when evaluating software packages. Criteria typically address only functional correctness during evidence acquisition when no attacker is present, yet forensic investigations are adversarial.
  • Methods for testing the quality of forensic software are not meaningful, public, or generally adopted. Our intention is to expose the security community to the techniques and importance of testing forensics software, and to push for a greater cooperation between the customers of forensics software to raise the security standard to which such software is held.

Along with this information is the announcement that:

We will release several new file and file system fuzzing tools that were created in support of this research, as well as demonstrate how to use the tools to create your own malicious hard drives and files.

Some of you may have seen an earlier article concerning anti-forensic tools that are already widely used. From that article:

The investigator (who could only speak anonymously) wonders aloud what other networks are right now being controlled by criminal enterprises whose presence is entirely concealed. Computer crime has shifted from a game of disruption to one of access. The hacker’s focus has shifted too, from developing destructive payloads to circumventing detection. Now, for every tool forensic investigators have come to rely on to discover and prosecute electronic crimes, criminals have a corresponding tool to baffle the investigation.

This is antiforensics. It is more than technology. It is an approach to criminal hacking that can be summed up like this: Make it hard for them to find you and impossible for them to prove they found you.

An InfoWorld article mentions that The Sleuth Kit has already patched the flaws, so those bugs will be revealed. What details concerning the deficencies found in EnCase depends much upon what actions Guidance has taken by the time of the conference.

Guidance software, in the person of Larry Gill has now publicly responded to these concerns.

As a result of this extensive testing regimen, they were able to identify six test scenarios, out of ?tens of thousands? of test scenarios run, that apparently revealed minor bugs ? in some cases for which there are straightforward workarounds ? in our EnCase® Forensic Edition software. All of the testing involved intentionally corrupted target data that highlighted a few relatively minor bugs. The issues raised do not identify errors affecting the integrity of the evidence collection or authentication process, or the EnCase Enterprise process (i.e., the operation of the servlet code or the operation of the SAFE server). Moreover, the iss
ues raised have nothing to do with the security of the product. Therefore, we strongly dispute any media reports or commentary that imply that there are any ?vulnerabilities? or ?denials of service? exposed by this report.

(Excuse the rogue question marks, these are displayed in the response, and represents character translation issues).
One additional point of interest in Mr. Gill’s response, as noted in a slashdot post, may cause those concerned with legal issues to pause. Here is Mr. Gill’s 5th point:

5. EnCase Had Difficulty Reading Intentionally Corrupted NTFS File System Directory.

Response: This issue involves the authors intentionally corrupting an NTFS file system to create a ?loop? by, ?replacing a directory entry for a file with a reference to the directory?s parent directory.? Experienced forensic examiners are trained to identify such instances of data cloaking. The purposeful hiding of data by the subject of an investigation is in itself important evidence and there are many scenarios where intentional data cloaking provides incriminating evidence, even if the perpetrator is successful in cloaking the data itself. The chances of this specific scenario occurring in the field are extremely remote, but Guidance Software will test and, if verified, place this anomaly in its development queue to be addressed in the future.

I think it obvious that the “masking” or “cloaking” of data is not always evidence of wrongdoing. The slashdot post takes issue with such an argument in this manner:

That begs the question: if one cloaks data by encrypting it, exactly what incriminating evidence does that provide? And how important is that evidence compared to the absence of anything else found that was incriminating? Are we no longer allowed to have any secrets, even on our own systems?”

As Michael Caloyannides wrote in his book, Computer Forensics and Privacy, “[t]he right to privacy is not a ‘cover for crimes,’ as some law enforcers would assert.”

As a final thought, I would emphasis that the flaws in software is likely the least important item in any basic civil discovery process. An element of truest is imbued within the whole concept of civil discovery, and while strict forensic methodologies and tools are sometimes required, it is not typically necessary. What any discovery team should be focused on is the reasonable nature of the total process, from data collection to data processing, to document review. The processes used should reasonably be expected to find relevant documents, and initial assumptions (such as data custodians and search criteria) should undergo a verification process to ensure their effectiveness. But this is a discussion for another post.

Posted in Computer Security, Data Management, EnCase, Forensics, Guidance Software, Privacy, The Sleuth Kit | 1 Comment »