A Q&A with Andrew Obuchowski
When a data breach occurs, a computer forensic investigator can save a company hundreds of thousands of dollars by establishing what exactly happened, potentially obviating the need for notification, and offering recommendations for remediation. To better understand how these investigations work, I spoke to Andrew Obuchowski, associate director of technology solutions at Navigant Consulting in New York, NY.

Let’s say you receive a panicked call from a client, and they just learned that their database holding all of their customer’s personal information was hacked. Can you explain in layperson’s terms how a typical computer forensic investigation may unfold? What might a process flow look like?
Of course, each investigation is unique. I’m tasked with asking questions to identify all possible sources of information that can be used to help me determine the affected data, when and how the incident occurred, and the outcome. There will be a series of high-level questions to start—and generally, one person cannot answer all of them. My interviews would include the legal department, HR, marketing and communications, in addition to IT staff. These conversations might lead to third parties such as cloud computing or other IT vendors. From there, I would ask more detailed questions about the network, systems and logging capabilities, remote access, user and application accounts, and then make a determination regarding what information should be collected. I also like to focus on what is unknown to the company, what else is going on and what could be affected—for instance, if someone’s laptop had malware installed that could compromise other areas on the network. Part of doing due diligence is covering all possible scenarios. Then there is the preservation stage, which includes imaging computer hard drives and collecting network data, for example. Some of these steps might occur after hours due to staff availability or volume of network activity and could be in conjunction with third party resources. We work with the staff to assist in the investigation and ask them to carve out time to support us. Here’s an example of what the flow might look like:

• Setting up scoping meetings to identify background information, availability of staff personnel, data sources, and actions taken since the incident was discovered.
• Deploying qualified trained personnel to preserve and collect data from relevant computer systems such as laptops or servers, network logs, administrative documentation, and perform vulnerability scans (if needed). Onsite analysis of this collected information would be performed to “triage” the incident and offer any immediate remediation tasks to mitigate further risk.
• Detailed analysis would be performed in a controlled environment, such as a forensic lab. This analysis could include generating various reports or monitor malware behavior to help us identify the level of compromise and will be used to help us reach a conclusion. (This could take a few days to weeks and usually involves follow-up questions.)

What are some typical problem spots or issues that might complicate your investigation?
Some of the biggest challenges occur when the company doesn’t know where sensitive data is stored, who the key contacts are, the location of backups, or how long they have been maintaining records. Gaps like this could extend our investigation and cause delays. Having access to all available information is critical—even though we may not “need” all of the information we are asking for, it is useful to know it is there.

Often when there’s a third party such as a cloud computing vendor it can be difficult to gain access to the data we need. Sometimes vendors sell a solution to host the data but don’t provide vital logging information in terms of who accessed the data, what actions were performed, and when this occurred. These things are commonly overlooked and should be detailed in the service level agreements you have with your provider.

Many organizations rush to focus on repairing the incident rather than preserving the information. This would cause a loss of valuable evidence that can help us determine whether we are handling a data breach or an information security incident, and what was affected. The loss of crucial evidence could force a company into a position where they have to notify customers of a data breach since we would be unable to defend the claim that sensitive information was never compromised.

Another overlooked task is the lack of historical documentation or report. The information contained in the incident report should include who performed an action/task, when it was performed, and a description of the action/task.

Finally, I’d say we could run into delays when administrative documentation such as network diagrams or incident response plans are outdated or incomplete. In many instances, and it is more frequent with smaller organizations, all of the network and relevant information rests on the shoulders of one individual. Murphy’s Law would suggest that an incident will happen when that individual is on vacation and out of the country. Be sure that the weight of this responsibility doesn’t lie with just one person in an incident. This is not only useful for an investigation but also provides a form of internal checks and balances for an organization.

What are some best practices used by clients that aid your investigation?
Certainly, all the issues I have previously mentioned should be addressed in some level.  Companies need to have the ability to maintain business continuity while balancing the staff and system requirements needed in an investigation. Here are a few high level bullet items that are useful:

• Detailed logging information of your network and key systems should at least be retained for 60 to 90 days.
• Information security awareness training and educating employees to identify risks can help to minimize human error, although it will not prevent the disgruntled employee from taking your data.
• Network diagrams and incident response plans are also very helpful. Keep in mind that you should not just create an incident response plan but perform a tabletop exercise to test this plan and make sure it works.
• If the company has acquired solutions for email and data archiving, they need to ensure that the information can be extracted in a usable format. Don’t just implement your products; test them.
• Key staff should be able to identify where all sensitive data is stored—and sensitive but unrelated data such as HR and financial information should never be stored together or with common group and file shares.

Finally, companies need to pay attention to service level agreements and understand where they are relinquishing control of the data and make sure that it can be accessed when needed. Identifying where your data is physically stored can also be a concern. Your data could be stored in New York, Denver, or maybe even in Europe. Although most vendors are not going to provide you with this information, this does pose a legal challenge if data has to be collected.

In summary…
We feel the forensic investigation is often critical to the insurance company’s ability to make a proper coverage determination in order to pay out on a loss resulting from a data breach event. For example, the insurer needs to factually verify:

• Date of the breach? This is key to determining whether coverage was in place at the time of the event.
• Date of detection? This is important to show an Attorney General (or plaintiff lawyer) that the insured business responded in a timely and prudent manner to the event.
• Location of the breach? Did the incident occur on the insured’s system or a third-party provider’s system or Cloud (which could trigger a later subrogation action)?
• What controls/safeguards were defeated that contributed to the cause of the loss? This is important in order to document during a postmortem review of the claim that new safeguards are in place to minimize the chance of the incident happening again.

Of course, as Mr. Obuchowski illustrates, a claims investigation typically doesn’t come with a neat bow wrapped around it. Problems often occur. The Cloud, in particular, may present challenges for both the insured client and the insurer. A Cloud provider may not allow a forensic investigation of an alleged breach incident on its network (assuming, of course, that the Cloud provider actually notified the insured client of the alleged breach in the first place).