Many of these breaches occurred because of a failure to maintain base level security or enterprise data. Although structured databases are a treasure trove of sensitive information, most database systems offer many layers of protection with the advantage that the database itself remains, usually on IT-managed infrastructure.
Security controls are potentially more critical for unstructured content -- because file-based information is insanely portable and moveable with modern devices and always-on connections. It’s important to consider content security in light of the more recent history of enterprise security. For a long time, security has been defined by borders and boxes.
20 Years Ago - Borders
At the dawn of the Internet era, most enterprise security was defined at the edge of the network. Early firewalls provided the primary defense between the “outside” Internet and our internal corporate networks. Security was defined by ports and target IP addresses only. Even then security-aware IT pros were mindful of the risks in allowing outside traffic to traverse internal networks. In part, this explains the rapid rise of perimeter “DMZ” networks. However, once an external host gained access to the internal network it was generally free to roam anywhere on the network.
10 Years Ago - Boxes
Around the dawn of the SharePoint era, we started to grow equally concerned about the security of the container -- in particular, the site or library that housed a given piece of content. SharePoint 2003 only allowed security at the site level, while 2007 allowed granular permissions at the file level. Nonetheless, inherited permissions remain the most common way to secure sensitive information today.
Now - Content Centric Security
Content based security now runs on multiple levels -- access control, permissions and encryption. These may be thought of as progressively higher-level of the classic OSI reference model for networking:
2. Data link
Access control runs at a fundamental level (3-5), with permissions and security running near the top of the stack. Got that? In the real world, you might use any combination of them, based on your situation, to control your documents. Let’s take a look.
Dynamic Access Control (DAC)
Microsoft introduced DAC as part of Windows Server 2012. Think of dynamic access control as the doorman for your content application. DAC takes an attribute-based, rules driven approach to controlling information -- determining if a user even gets to know if a selected file exists or not. Sample conditions for DAC rule could include:
- If User.Location = Non-US and File.Attributes = ITAR then DENY
- If User.Type = Employee and File.Sensitivity = Public then ALLOW
DAC is natively available for Windows file shares on Windows Server 2012 or higher, and third party solutions exist for other platforms, like SharePoint. Dynamic access is a real time, high speed approach to allow requests to proceed further, but can be limited in terms of controlling what a user is allowed to do with the file provided they're granted access.
Since DAC is tied to the attributes of the file, it can help ensure uniform controls for files regardless of where it is copied. For example, in the example above, if a user copies a file from a secure team site to a more public section of the information architecture, the file retains the same attributes and thus the same access controls remains in effect.
SharePoint inherits its native permission sets from the NTFS file system:
- Full control (charge permission and other attributes)
File permissions are a good way to assure that you can prevent users from making changes to a document while still allowing them to work with a file’s contents.
However, NTFS does not permit an intrinsic denial of rights -- the absence of explicit permission is presumed to be a denial. Many systems like SharePoint embody some level of security trimming so users without rights to a file don’t even see links to files while browsing or searching.
Permissions are usually inherited and hierarchical -- the users and groups that are given permissions at the top of the site flow down to subsites, libraries and folders, although they can be overwritten. In this scenario, where a file lives in the hierarchy is extremely important. Because of permission inheritance, copying or moving files usually changes their permissions.
You can also apply permissions on a document-by-document basis, but with enterprise repositories running into millions of files, permission management on this basis becomes almost impossible.
Permissions, generally, are limited to read/edit/control, and read permissions don’t restrict what users can do with the contents. Nothing prevents a user from copying the contents of a read-only file to a new editable document under his or her control. This is ideal under some business scenarios -- for example, creating an annual report may begin by reusing text from last year’s archived copy.
Both DAC and permissions rely on the content management system -- SharePoint, file systems, etc. -- to supply security. This makes keeping content “in SharePoint” paramount: if the files are moved via email they lose permissions and DAC no longer applies. For the file to remain portable, it needs to act as its own security container. Encryption is the most common approach.
Encrypted files can be thought of as “scrambled.” Users may have rights to access the file -- even edit it. However, they can’t actually do anything without unscrambling the contents. Decryption usually requires checking back in to the original system to reverse the encryption process. Almost all decryption uses a form of PKI (public key infrastructure) that combines a binary signature from the client with a public “key” from the system to unlock the scrambled bits. There needs to be a process running locally to supply decrypted data to the calling application (Word, Notepad, image viewers). That process can also monitor user actions. As a result, encryption can be used to allow a given file to be freely copied across the Internet and distributed via email -- but no one can actually use the file until they reconnect to the source system -- and that reconnection process can limit what users can do with the encrypted contents.
Encryption is central to many rights management systems. Instead of just read or edit permissions, users can be allowed to open a document but not copy, print, or redistribute it. Encryption is a mandate for many regulated industries (e.g., healthcare) and offers the most finely grained control. It is also complex and usually requires preinstallation of local software, which makes it appropriate for highly sensitive content such as personal health information (PHI), but too much for casual collaboration on a sales presentation.
Balancing Security Needs and Demands
No one would suggest that firewalls and secure containers are out of date. Modern security design demands in depth defense, with multiple layers of control (which can often be redundant), so a breach of one control has limited impact.
In much the same way, DAC, permissions and encryption combine to offer a mix of powerful and flexible governance tools for enterprise content. Each offers a different level of cost, usability, control and manageability. Permissions may be the best known content controller -- but DAC and encryption, combined singularly with permissions or all three together, offer a scalable mix of tools to balance usability, performance, manageability and control. As always, think about the business outcomes and business process, then back these up with the right level of control needed to sustain and protect the information.