A week or so ago I published the Data Security Lifecycle, and so far the feedback has been very positive. The lifecycle is a high-level list of controls, but now we need to dig into the technologies to support those controls.

The Data Security Lifecycle is designed to be useful today while still being visionary- it’s important to keep in mind that not all these technologies are at the same maturity level. Most data security technologies are only in an adolescent stage of development- they provide real value, but are not necessarily mature. Some technologies, especially Enterprise DRM, aren’t yet suitable for widespread deployment and work best for smaller teams or business units. Others, like logical controls, are barely productized, if at all. As we go through these tools, I will try to clearly address maturity level and suitability for deployment of each one. Over time I’ll be digging into each of these technologies, as I’ve started doing with DLP, and will be able to discuss some of the more detailed implementation and maturity issues.

200710041348

In today’s post we’ll focus on the first two stages- Create and Store. Since we’ll be delving into each technology in more detail down the road, these posts will just give a high-level overview. There are also technologies used for data security, such as data-in-motion encryption and enterprise kay management, that fall outside the lifecycle and will be covered separately.

200710041349

Create

Classify: Eventually, in this stage the content-aware combination of DLP/CMF/CMP and Enterprise DRM will classify content at the time of creation and apply rights, based on enterprise policies. Today, classification at the time of creation is a manual process. Structured data is somewhat classified based on where it’s stored in the database, but since this isn’t a content-aware decision and still relies on manual controls, there’s no real technology to implement. In both cases I expect technology advancements over the next 1-3 years to provide classification-on-creation capabilities.

Assign Rights: Currently a manual process, but implemented through two technologies:

  1. Label Security: A feature of some database management systems that adds a label to a database row, column, or table, classifying the content in that object. The DBMS can then implement access and logical controls based on the data label.
  2. Enterprise Digital Rights Management (EDRM): Content is encrypted, and access and use rights are controlled by metadata embedded with the content. The EDRM market has been somewhat self-limiting due to the complexity of enterprise integration and assigning and managing rights. Eventually it will combine with CMF/CMP (notice I dropped DLP on purpose here) for content and policy-based rights assignment.

Access Controls: One of the most fundamental data security technologies, built into every file and management system, and one of the most poorly used.

  1. DBMS Access Controls: Access controls within a database management system, including proper use of Views vs. direct table access. Use of these controls is often complicated by connection pooling, which tends to anonymize the user between the application and the database.
  2. Administrator Separation of Duties: Newer technologies implemented in databases to limit database administrator access. On Oracle this is called Database Vault, and on IBM DB2 I believe you use the Security Administrator role and Label Based Access Controls.
  3. File System Access Controls: Normal file access controls, applied at the file or repository level. Eventually I expect to see tools to help manage these more centrally.
  4. Document Management System Access Controls: For content in a document management system (e.g., Documentum, SharePoint), the access controls built into the management system.

Encryption: The most overhyped technology for protecting data, but still the most important. More often than not encryption is used incorrectly and doesn’t provide the expected level of security, but that’s fodder for a future discussion.

  1. Field-Level Encryption: Encrypting fields within a database, normally at the column level. Can take 2-3 years to implement in large, legacy systems. A feature of all DBMSs, but many people look to third party solutions that are more manageable. Long-term this will just be a feature of the DBMS with third-party management tools, but that’s still a few years out.
  2. Application-Level Encryption: Encrypting a piece of data at the application on collection. Better security than encrypting at the database level, but needs to be coded into the application. Can create complexities when the encrypted data is needed outside of the application, e.g., for batch jobs or other back-end processing. Tools do exist to encrypt at the application layer using keys available to other applications and systems, but that market is still very young.
  3. File/Media Encryption: In the context of databases, this is the encryption of the database files or the media they’re stored on. Only protects data from physical theft and certain kinds of system-level intrusions. Can be very effective when used in combination with Database Activity Monitoring.
  4. Media Encryption: Encryption of an entire hard drive, CD/DVD, USB stick, tape, or other media. Encrypting the entire hard drive is particularly useful for protecting laptops.
  5. File Encryption: Encryption of individual files and/or directories on a system using software on that system and typically managed on a system-by-system basis by users.
  6. Distributed Encryption: Distributed encryption consists of two parts- a central policy server for key management and access control lists, and distributed agents on systems with the data. When a user attempts to access a file, the agent on the local system checks with the server and retrieves the keys if access is approved (in reverse, it can encrypt data using individual or group keys assigned by the server). Distributed encryption provides file-level granularity, while maintaining central control and easing management difficulties.

Rights Management: The enforcement of rights assigned during the Create stage.

  1. Row-Level Security: Non-label based row-level access controls. Capable of deeper logic than label security.
  2. Label Security: Described in Create
  3. Enterprise DRM: Described in Create

Content Discovery: Content-aware scanning of files, databases, and other storage repositories to identify sensitive content and take protective actions based on enterprise policies.

  1. Database Content Discovery: Use of a database-specific tool to scan for sensitive content outside of expected fields. For example, searching for credit card numbers stored outside of the encrypted credit card column. This is a very early market and a feature we sometimes see in a Database Activity Monitoring tool.
  2. Data Loss Prevention/Content Monitoring and Filtering Discovery: A feature of most top-tier products to scan data-at-rest for sensitive data outside of approved repositories. More details here.
  3. Storage/Data Classification Tools: Non-security tools used in ILM to classify content. While focused on a non-security buying center, and often with limited content analysis capabilities, these tools are capable of dealing with very large storage environments and we expect to see increasing overlap, if not outright merger, with DLP/CMF Content Discovery.

Again, this is all still in an early stage of development so I’m extremely interested in your feedback

Share: