Insidious Insiders: Bank of America

When I talk or write about inappropriate confidential information disclosure, I often point out that data loss prevention (DLP) systems most commonly help reduce the everyday mistakes by well-intentioned employees just trying to do their jobs. A DLP system also helps discover a malicious insider gathering or passing confidential information to outsiders. Regardless of intent, a good DLP system can help administrators notice a trend of confidential leaks and help build a case file for action with regard to a problematic insider.

A story I saw today about a problem at Bank of America that has been under investigation for a while where an apparently-malicious employee, who had access to "personally identifiable information such as names, addresses, Social Security numbers, phone numbers, bank account numbers, driver's license numbers, birth dates, e-mail addresses, family names, PINs and account balances," allegedly passed this information to criminals. The estimated resulting direct financial loss is $10 million.  Indirect losses, including employee time spent investigating the problem, cost of credit report monitoring for affected customers, revisiting policies and controls, and diminished brand may be significant as well.

A DLP system is one of the best practices that a business can put into place to help track and prevent data breach events. If you have a DLP system in place, make sure it is correctly configured, installed in the correct locations in your network, servers, and clients, and make sure it is monitored. (It is highly likely that Bank of America has a DLP system in place, but I do not have any knowledge in regards to whether information from a DLP system helped with the investigation of this case.)


Other best practices for protection of information include:

• Limiting the amount and scope of information available to employees to that necessary to do their jobs. Often, employees are given increasing access to information over their tenure, and it's a good idea to review access to make sure potential for problems is limited.
• Logging information access and reviewing the logs for unusual patterns. A Security Event Manager (SEM, also known as SIEM) can help with this by making it possible to centrally manage and review information from servers.
• Limit network access for workstations and servers. Servers should generally not be using protocols like Internet Relay Chat or accessing random web sites. A network protocol manager or firewall can be configured to prevent unexpected network use. Unexpected use of web sites or network protocols from servers might be indicative of an intrusion that should be investigated.

With good practices and vigilance, you can reduce the risk posed by malicious intent.

Classes of Protected Information and DLP

Data Loss Prevention (DLP) systems have to deal with a variety of formats of data and identify protected data in those formats.  In general, protected information falls into these formats:

• Unstructured text - as found in text documents - including various types of information:
• Corporate proprietary information or trade secrets
• Personal health records
• Personal financial records
• Personal identifying information
• Structured data - as found in spreadsheets, tables, database output, and CSV files

To deal with these different formats of protected information, a variety of approaches are used in a DLP system.

For corporate proprietary information, document fingerprinting is the predominant approach to identifying parts or complete copies of proprietary documents.  This requires the administrator to register proprietary documents with the DLP system, and then the DLP system can match fragments or wholesale copies of the proprietary documents.

Another approach that can be used for proprietary documents is to embed tags in the documents, such as "Company Confidential", and then add a simple rule to the DLP system to watch for that tag.  However, this depends on corporate users applying the correct tags to the documents, and is easy for a malicious insider to circumvent, for example, by simply removing the tag before transmitting the document to an unauthorized recipient.

For data like personal health information (PHI) or personal financial information (PFI), several approaches (or a combination of approaches) are typically used.  A combination of search terms can be used to determine if data contains information referring to a particular individuals or group of individuals, plus whether the data contains significant information about those individuals.  For example, an email message from a bank containing the customer's account number, name, and account balance, it might be considered to be information protected under the Gramm-Leach-Bliley Act (GLBA).

Another approach to PHI and PFI is to use information from a corporate database, such as account numbers and customer names, in the DLP system to search for matches.  If an account number and associated customer name turns up in an email message, the message might be considered to contain information protected under GLBA.

A third approach, specific to personal financial information, is to look for credit card information.  Credit card numbers use a standard format and are assigned in specific ways, so it is possible to look at a sixteen-digit number and determine with a high degree of accuracy whether that number is probably a VISA or MasterCard credit card number.

For personal identifying information, an approach is to look for national identification numbers, state driver's license numbers, or account numbers.  In the United States, the Social Security Number (SSN) is often used (and abused) for purposes of identification and authentication for financial and health purposes, and as such has gained status as a protected piece of information.  Unfortunately, the format of the SSN was developed without the concept of check digits or embedded validators, so it is easy for a DLP system to mistake a number in the form 123-45-6789 as an SSN.

As for structured data, DLP systems can identify protected contents in a couple of ways.  One is to write rules for the DLP system that match the format of data typically used in a company, such as forms that are often used for things like customer orders.  Another approach is to use information from a corporate database, such as account numbers and customer names, in the DLP system to search for matches.

These formats cover the majority of ways I have seen protected information stored and transmitted in ways that DLP systems can help identify and protect the data.

Bouncing Through the Cloud

A Bloomberg report over the weekend referenced an unnamed source as saying that Amazon cloud resources were used in the breach of the Sony Playstation Network.  Specifically, Amazon's cloud infrastructure was not compromised, but instead used as a "relay" for the attacker to hide his/her origin.

An article on Reuters makes an (IMO) unsubstantiated claim that the attack on Sony spells doom for cloud computing.  My response is that, whether or not cloud computing had anything to do with this, Sony simply had vulnerable software and apparently had insufficient controls and management in place to detect and respond to security issues.  Poor security and controls are mostly unrelated to cloud technologies -- yes, there is a possibility of attacks on the hypervisor in shared infrastructure, among other things -- but none of the recent significant breaches has involved vulnerabilities in cloud computing.

What I see as a more significant exposure in cloud computing is the extent to which confidential data is being stored in the public or hybrid cloud and being provided via cloud-based servers to end users over the Internet without sufficient monitoring and controls in place.  The glaring security deficiencies in cloud computing right now are the lack of visibility and the lack of security functionality that we have in private data centers, including network traffic analysis, intrusion detection systems (IDS), data loss prevention (DLP) systems, and audit and logging systems.

We're working at Palisade Systems to improve the security controls available in cloud computing. Palisade has virtual DLP appliances available for VMware cloud environments, and will have more good cloud security products coming up.

Virtualization and Data Loss

Well, it had to happen to me eventually.  A physical server running VMware ESXi crashed and I lost a set of virtual servers that I had moved to it.

It seemed to result from a power hiccup.  Nearly everything important in the server room is on a UPS, except for this system.

This failure mode was new to me: VMware ESXi would not finish its boot, but complained about an invalid file (sorry, exact filename escapes me) and stopped.  (It looked an awful lot like a Windows boot failure I've seen in the past where a corrupted registry hive file prevented Windows from booting!)  I had to perform a VMware ESXi recovery installation, and that resulted in the ominous warning that one of my filesystems had an invalid partition table.

This particular VMware server has two VMFS filesystems on it (two separate hard drives to improve I/O performance for the VMs), and the second of the two filesystems was toast.

I hadn't considered the virtual machines on this VMware server to be irreplaceable, but they were valuable.  It took a couple of days of work to rebuild one of the lost VMs.  Another of the lost VMs caused a troublesome cascaded failure: it provided an infrequently-used web proxy whose loss caused unexpected software update failures elsewhere, and that took some time to diagnose as well.

In summary: I wish I had enough disk space everywhere to have backups of all the virtual machines, and I wish I had a good way to use apcupsd (or equivalent) to shutdown ESXi servers nicely on power failures.

Data Loss Prevention and Mobility

At Palisade we are often asked how to protect data from loss when your employees and/or partners all have access to your corporate private/privileged data through handy little gadgets like iPhones.

The problem we are finding is that gadget vendors have not provided hooks into the devices so we can do DLP on the gadgets directly.  In fact, software on iOS devices is intended to be quite isolated to prevent any application accessing information that belongs to another application, such as email messages or stored PDFs.

Enter some pretty cool software from Whisper Systems for Android systems.  WhisperCore looks very intriguing:

WhisperCore integrates with the underlying Android OS to protect everything you keep on your phone. This initial beta features full disk encryption and basic platform management tools for Nexus S phones. WhisperCore presents a simple and unobstrusive interface to users, while providing powerful security and management APIs for developers. 

 Will be looking into this more deeply :-)  Maybe this would encourage Apple to provide hooks for similar software into iOS.