CSI: LarsonAllen

by Randy Romes

We received a panicked call from one of our clients—a large financial institution—on a Tuesday.

“One of our vendors installed a virus onto our computer network,” he said. “What do we do now?”

He went on to say that he had received a new computer server from a vendor, and the vendor notified him that the server contained a virus. The vendor did not have more details, but suggested not connecting the server to the bank’s network, or to remove it if it was already up and running.

Unfortunately the server had been up and running for four days, according to our client, but it was not yet fully operating. Our client had disconnected it from the network before calling us, but it was still powered on. We advised him to leave it powered on but not connected, and not to shut it down.

The plan

We suggested sending an incident response team to his location, and our client accepted. Our team got on a plane first thing Wednesday morning with a plan to identify the nature and scope of the virus, gather forensic evidence, and if necessary, recover critical systems and data.

We knew our client needed help with the following:

• Validating the presence of the virus and understanding the actions the virus will attempt
• Determining if the virus is isolated to the server in question, or if it has spread to other systems
• Initiating quarantine and clean up actions for infected systems
• Validating whether customer information had been exposed—which is critical from a regulatory and legal perspective
• If possible, determining how the virus was introduced to the system in the first place

The evidence

Before we left, the client received the following additional information from the vendor:

• The virus was diagnosed as “W32.Popwin,” which if accurate, would help us determine exactly how the virus behaved, and give focus to our investigative efforts.
• The vendor did not run antivirus software as part of the server build process, which the vendor reported was the reason the virus was not caught.
• The vendor gave no explanation how the virus was introduced to the system.

Our analysis

After we arrived on Wednesday, we began our field testing. Through this two-day investigation, we determined the following:

• The vendor incorrectly identified the virus as “W32.Popwin,” when in fact it was “W32.Kaxela.A,” which has different actions, requiring different lines of investigations.
• Our forensic analysis indicated the virus was first introduced during the installation phase—while in the vendor’s possession—by a USB thumb drive.
• Our testing also indicated that two different antivirus applications were run on the system while it was in the vendor’s possession, contradicting the vendor’s earlier statement.
• Based on the nature of the virus, we determined that it had not spread to any other systems on the client’s network, and that it could only spread when a USB thumb drive was plugged in. This had not happened at any time when the server was at the client’s location.
• Secondary analysis of other key systems also showed no evidence of the presence of the virus.

Thankfully, in this case, no customer data was exposed. But we uncovered some alarming information about the vendor. The vendor was not following their own stated build procedures (or were misstating these procedures in an attempt to avoid responsibility for the situation). The client is using our investigative results to help terminate their contract, seek reimbursement for the incident response expense, and obtain compensation related to the lost time and effort required to identify and select a new system and vendor.

A vendor management program can help

Most organizations are concerned about information security risks from hackers or other sources—not from their IT vendors.  A well designed vendor management program can help you avoid this situation. The vendor management program should include adequate contract review to ensure:

• Commitment to standards that are at least as secure as the organization’s own standards
• The contract includes input from IT security prior to contract acceptance
• The ability to audit the vendor (“right to audit” clauses)
• The requirements for cooperation, full disclosure, and the ability to hire independent investigators in the event of a security incident

If you do have a security breach, make sure you have a security strategy in place (i.e., an incident response policy and supporting standards and procedures) that includes a written incident handling plan. A sound information security strategy will set the tone for your business by establishing a baseline and a culture for secure business operations. The strategy must also recognize that security incidents will occur, and the risks need to be mitigated through proper preparation.