Tari Schreider describes a real-life investigation into a scam that threatened to undermine a large organization.
The names have been changed, but the story is real. At stake was more than just the organization's reputation. Highly personal and confidential data was being leaked, and the race was on to discover those responsible.
The organization bamboozled in this case was a not-for-profit association with several million members throughout the United States. Reputation and integrity is, and has been, the cornerstone of its charter for over 100 years.
With a fairly extensive enterprise network, the organization had an IT staff of nearly 75. Approximately half of these IT employees were covered by a collective bargaining agreement negotiated on their behalf by their union.
Unix is the infrastructure operating system of choice and Windows 2000 is installed on the desktops of more than 1,000 users. The association also had an extensive set of portal services for its members, and had been moving quickly to deploy a rich portfolio of web applications and services. To meet some of these aggressive timelines, it was not unusual to see a number of consultants working on mission-critical projects.
It was the last organization anyone would think of falling victim to a cybercrime, let alone an attack orchestrated by one of its own. But rather than sweep the breach under the rug like so many others who have been victims of cybercrime, the association decided to fight back and bring the criminal to justice. It wanted to send a clear message to others within the organization that such incidents would not be tolerated.
Late one evening, I received a phone call from a colleague who explained that a client of his was witnessing "some funny things" occurring within his network. The more he explained , the more intrigued I became.
He described one particular scenario where local drive files would seemingly disappear from workstations and then mysteriously reappear before the help desk could investigate. He also explained that employees seemed to have an inordinate amount of information on management's pending plans for restructuring the IT department. It was almost as if the IT union's shop stewards had a sixth sense.
Tracking the mischief
In addition to these happenings, morale in the IT department had dropped precipitously, and the helpdesk staff were becoming progressively antagonistic toward network and system administrators. Puzzled by the goings on, my colleague asked if I would speak with his client.
As the director of IT for the organization, the client (we'll call him Dave) was an articulate, technology-savvy manager who had risen up through the ranks since his start as a computer operator 20 years earlier. He knew everyone and everything about the organization's IT department - or so he thought.
His recounting of the situation, as compared to my colleague's, had a twist. One of his system administrators had come to him with a complaint that a fellow system administrator's profile had appeared on his workstation. I asked when this had occurred. Dave looked down and said, "I am ashamed to say, nearly four months ago."
Dave explained further that they tried to keep this matter in-house, only involving their legal department. He reviewed the investigative steps they had already taken, mentioning that although they had some suspects in mind, they could not produce irrefutable evidence. I agreed to take the case.
In deciding to help, I should have been pleased, right? Wrong. While I had some kind of crime, suspects and a cooperative victim, I also had a cold trail, a trampled crime scene, and no verifiable chain of custody for the evidence.
Approaching the investigation
Because so much time had passed, I decided that the best approach was to perform my own primary research to baseline the incident. From this point forward everybody had to be considered a suspect until we could go through a formalized process of elimination.
I gave Dave a code word so we could begin to establish a chain of trust and custody. The project was known as 'hanzai,' the Japanese word for crime. Only six people knew about the investigation and could only refer to it in code.
My strategy was to treat this as a 'cold case' and review all the evidence prior to performing an on-site investigation. Based on previous cases of this nature, it was highly probable that the perpetrators would continue their nefarious activities. I had to know what they did before I faced them on-site.
Regardless of what occurred previously, proper forensic procedures had to be followed. My personal preference is the International Origination on Computer Evidence (www.ioce.org). It is internationally recognized and used by government computer crime agencies throughout the world. This process would allow me to preserve any evidence that I would collect, as well as establish a chain of custody.
Uncovering the evidence
Dave had secretly made images of the suspects' hard drives and locked them in a tape vault. I provided Dave with instructions to securely ship these drives to our lab in Atlanta, Georgia so that my team and I could perform our analysis. Once the drives arrived and the authentication was made (meaning that the parties authorized to send and receive evidence were validated through the use of passwords and authentication codes), the forensics team made working images and began the process with a first pass of the disks.
The initial pass of the data did not uncover anything remarkable. However, the search for deleted files uncovered a treasure trove that, when pieced together, created an amazing web of internal espionage, and a trail of personal and business files that were systematically harvested from employee hard drives. We also uncovered a vast amount of inappropriate material, including hardcore porn and morally reprehensible web site links.
Pointing the finger
So, the plot thickened - just how many employees were in on this thing? Digging deeper, we found parts of deleted email messages and evidence that confidential internal documents were sent outside of the organization.
After I was convinced that we had gathered as much evidence as we possibly could from the suspects' hard drives, I called Dave to let him know I was prepared to discuss our findings with him.
Two days later, I was sitting in his office telling him a seemingly fantastic story of his employees' cybertransgressions. I explained that I believed his entire network's security had been compromised, and that several trusted IT employees freely harvested confidential files from other employees of the organization.
"These are the things that only happen to the other guy," Dave said.
As if what I had told Dave wasn't bad enough, I had to tell him who it was. Two of his most trusted IT staff were the perpetrators of the cybercrimes. To make matters worse, they were both system administrators, which meant they had the 'keys to the kingdom.'
And, based on the files that we found, we believed that an outside influence was also involved and that these two administrators were gathering data against the organization to help their position with the union. The outside influence denied any knowledge of the incident throughout the case. An 'arrangement' was reached, but the terms cannot be discussed.
Taking the next step
To say the least, Dave was furious. His first question: "Where do we go from here?"
We had to begin with a review of the organization's security policies to determine what level of enforcement was available to us. The look on Dave's face was that of a man who had just been diagnosed with a terminal disease.
"Our policies are pretty basic and, in fact, do not cover anything like this," he said. "But, why would we need them - they broke the law!"
I explained that technically no laws were broken. Dave (and other managers and executives who will likely find themselves in a similar situation) must understand that in the eyes of the law, the system administrators involved had tacit authority granted to them by position to have full and complete access to the network. Without any specific policies that defined acceptable use, options were limited.
I recommended that our next step was to interview all the systems administrators, a total of six, in order to see if the perpetrators would reveal themselves without our having to show the evidence that had been gathered.
The process began by first assembling the senior IT management, the legal department and human resources for a private conference. In that meeting, each system administrator was scrutinized as to potential motive and opportunity. At the end of the day, the same two names kept coming up.
Armed with this background information, each system administrator was interviewed. Surprisingly, the others not involved implicated the prime suspects. They described an environment where the two suspects had alienated themselves from others in the organization and became secretive.
I saved the interviews of the suspects for last. As expected, they denied everything. They both had a story where they blamed each other, revealing no love lost between them. And, more importantly, what did emerge was that two entirely separate acts of cybercrime were actually occurring.
The suspects apprehended
With the interviews completed, I met with Dave to present my findings. I explained to him that although both were guilty based on the evidence and the results of the interrogation, they had entirely different motives. I recommended that both employees be immediately suspended until the formal investigation was completed. But while they both presented a clear and present danger to the organization, the collective bargaining agreement would not allow for their dismissal - only their reassignment to other duties.
Luckily, and to everyone's amazement, after being reassigned, one of the two suspects gained access to his workstations and attempted to delete all evidence of his deeds. Unwittingly, this was the evidence that proved to be his ultimate downfall. After all, why would an innocent person try to cover his tracks? He was easily caught and this provided grounds for his immediate dismissal. The second suspect remained in his reassigned position without causing any incident.
The lawsuit and trial
As irony would have it, the suspect who was immediately dismissed sued the organization to get his job back. Lawyers for his union represented him. Their entire case was built on the fact that no policy existed. With no policy, there was nothing stating that what he had done was against organizational mandates. On top of this position, he claimed that he was being set up in an attempt by management to frame him.
Both sides agreed to an expedited arbitration and a trial was set for a month later. Prior to the trial, the organization and I spent several weeks extensively documenting the incident. Knowing that we would be presenting evidence to a layperson, our evidence had to be clear, concise and compelling.
On the day of the trial we reconstructed the incident using a step-by-step graphical representation of the crime. We explained how computers work and showed that what had happened could not have been faked under the circumstances.
Arguing the case
The lawyers for the accused argued that neither a crime, nor a violation of company policy, had been committed. They continually pointed to the fact that without strict security policies, the systems administrator could not be convicted of any wrongdoing.
Our position was that as a system administrator, an implied covenant of trust existed. Further, the Computer Fraud and Abuse Act, 18 U.S.C. 1030(a) (2) actually makes it unlawful for anyone who "intentionally accesses a computer without authorization or exceeds authorized access..."
Six months had gone by since the original event, an event whose conclusion was now in the hands of a layperson. How would the judge rule? Did we present a compelling enough case? We would have to wait a whole 48 hours for a decision.
On the day that the verdict was due, we had taken stock of all that we could lose. The ramifications were unthinkable. To lose would allow a computer criminal to go back to work at his previous job as system administrator. Dave kept saying, "all this because we didn't have a policy written down." I told him that many organizations are in the same situation.
A few hours later the verdict was faxed to the organization's chief legal council. The judge ruled in favor of the not-for-profit association. We had won.
If you were wondering what happened to the second suspect, he was fired as well. Once the precedent was set that a system administrator had the 'duty of care' to ensure the acceptable use of the network, the client was certain this employee could be dismissed without prejudice. The successful adjudication of the case ensured that both firings would be sustained and that any appeals would be negated.
After such a difficult situation, it is easy to have 20/20 hindsight. However, there were several important lessons that the organization learned from its experience, not the least of which was understanding the need for a comprehensive security policy with clearly articulated enforcement measures commensurate with state and federal computer crime statutes.
A security policy is the most powerful piece of paper an organization can have. Although seemingly simple, the lack of one nearly cost this organization public embarrassment, a tainted reputation, significant settlement costs, and an IT organization that could have easily denigrated into a malaise of distrust for years to come. This is one time where it doesn't pay to have a completely paperless office.
Tari Schreider is director of the security solutions practise at Extreme Logic (www.extremelogic.com).
Investigation takes foresight
Along with establishing security policies that identify acceptable use of computer resources and offer up enforcement rules, the not-for-profit organization taken for a cybercrime ride by two of their own system administrators also implemented a comprehensive Computer Emergency Response Team (CERT) plan. This plan covered anything from the entire incident detection process to notification and response activities.
The following comprise the main components companies should include in a CERT plan dealing with incidents: monitoring, detection, notification, response, reporting, investigation, referral, support and post mortem.
This process covers the opening of a case number, activating the CERT, preserving the evidence/scene, investigation and gathering evidence, preserving the evidence, referring the case internally or to government authorities, and supporting the prosecution phase.
Running for cover
The security policies that the not-for-profit association put into place after the event included a formal information security policy that clearly identified acceptable use of computer resources, and an enforcement policy. Each of these was based on both state and federal computer crime statutes.
In addition to implementing such policies, the corporation required employees to go through an awareness program. They also had to sign the security policy to acknowledge acceptance.
"There are more than 1,400 computer security policies that generally exist today," says Schreider, "however, the majority of companies only require a small portion of those."
To protect themselves legally, he adds, organizations should make a point to include coverage of some of the items below in their security policies: