Technical Controls

IT or information security staff should evaluate the following technologies, and adopt those that meet their requirements and work in the target environment.

3.1.1 DLP/ILP Suites

An emerging category of commercial security tools claim to prevent storage or transmission of confidential information in ways that violate security or privacy policies defined by the enterprise or by regulations (e.g., PCI DSS). Those which are full suites include modules for:

1. Data in motion – network perimeter taps, email gateway filters, etc. 2. Data at rest – hosts that scan databases, file shares, web sites, servers,

etc.

3. Data in use – endpoint agents that monitor desktops and removable media

A full feature DLP suite can (configurably) take all of the following actions when relevant data is encountered:

1. Report on it

2. Trigger immediate alert 3. Destroy it

4. Relocate it

5. Block its transmission 6. Encrypt it

Considerable work has been done by Burton Group [2], Gartner [3] and Forres- ter [4] in categorizing and comparing commercial DLP/ILP vendors.

3.1.2 Discovery / Classification Tools

Even an enterprise deploying a robust DLP suite may need to supplement it with point solutions designed to discover and classify information in very specific niches. There are dark corners of an enterprise where the DLP tool may not be able to reach. For example, commercial products are on the market which special- ize in filtering email, scanning web sites, or scanning network file shares.

All these data discovery and classification niche tools need to be carefully as- sessed and compared to any DLP suite the enterprise chooses. Some may prove

redundant and should be retired. But others will complement (or add defense in depth to) the DLP suite and deserve a place in the enterprise toolkit.

3.1.3 Database Security

Much of the current technical control set is database centric, and sound data leak prevention should certainly start at the source. But as we saw in 2.2.4, there is much room for improvement. We can improve database security by activating or tightening many controls already available natively in many RDBMS platforms.

A typical enterprise may need to:

• Promote the use of database views more aggressively to further limit access based on need to know.

• Where possible, ensure consistent deployment of granular (column level if available) access controls in the database to reduce insiders’ read access to sensitive customer attributes.

• Where granular access controls aren’t available, keep sensitive data in separate tables with stronger access control.

• Expand use of granular database encryption (native or external) to re- duce insiders’ visibility to sensitive attributes.

• Extend data scrubbing to extracts, replication feeds, and file exports to minimize instances of sensitive data.

• Implement database security monitoring solutions or so-called “data firewalls”.

• Prohibit or restrict data extracts with sensitive data.

• Use data masking to redact sensitive data values in extracts and re- ports.

• Where possible, configure audit logs to capture data access related to high risk users (i.e. individuals with direct access to data stores out- side of applications that already log access).

• Keep logs on separate servers where administrators cannot access them.

One other thing to consider with regard to database audit logs is integration with an enterprise SIM correlation tool. This could allow more aggressive central- ized monitoring of security events at the database layer, and correlation with inci- dents at other layers of the IT infrastructure such as the network.

3.1.4 Application Entitlements

By externalizing policy entitlement decisions and/or enforcement points (“PDP” and “PEP” in XACML nomenclature) outside of business applications into sys- tems managed centrally (or at least separately), we enable separation of duties that

can thwart data theft and other insider attacks perpetrated by programmers. While most programmers are completely trustworthy, there is always some temptation to include “back door” code in software that will grant the developer special privi- leges or access rights to production data and accounts. Pulling entitlement deci- sion or policy enforcement logic out of applications removes the temptation.

Various commercial products are available, many based on the XACML indus- try standard, to perform this type of entitlement enforcement outside of applica- tions [13]. Some can integrate with provisioning systems which will enable cen- tral (or delegated) administration of application permissions.

Of course rigorous code reviews, combined with sound source code control and configuration management, are another way to mitigate risks from back doors and logic bombs.

3.1.5 Removable Media

Some enterprises need to tighten control over removable media, as this is a pri- mary vector for intentional data theft.

Physical security staff (facility guards) could subject laptops, thumb drives, etc. (especially those belonging to privileged individuals authorized to access sensitive data) to random searches. However this would likely prove costly and controver- sial. A technological control would be more pragmatic, even if less effective as a psychological deterrent.

Some DLP suites with endpoint agents offer the ability to enforce removable media policies on a targeted as well as enterprise wide basis. However a couple other lighter weight options are also available:

• Port lockdown products that disable USB/CD/floppy ports on selected desktops/laptops,

• Removable media encryption (RME) products that prevent access to encrypted thumb drives when plugged into foreign computers.

3.1.6 Defensive Search

The final (albeit forensic, not preventive) technical control available after a data theft is to find the stolen data in order to stop its further dissemination and/or iden- tify the thieves or their partners. Many enterprises do this on a limited basis today through simple (manual) defensive use of Google or other search engines. For ex- ample, through “BIN googling” a financial institution can search for its bank iden- tification number (BIN) on credit cards, debit cards, and employee purchase cards. This may turn up find leaked or stolen card numbers on web sites, ftp servers, or bulletin boards. Through other intelligence gathering methods one may also find traffickers sharing or discussing stolen data on IRC channels and other anonymous communication forums.

An enterprise must exercise caution in forensic Googling in order not to inad- vertently leak the very information they’re searching for. However it is possible to use the Google search API [16] to build tools that discreetly search for private data without inadvertently leaking it, in a way that automates the process so that more data (both quantity and types) can be searched for. Some regular expression matching capabilities are already available in the Google API to facilitate this.