I’ve always believed that the network is a poor substitute for protecting a host, its apps or (ultimately) the Data made available via the n/w, server and its apps. To me, the other layers of perimeter, network, host & applications are necessary means to the end, which is to access, manipulate and sometimes even add to that Data. Similarly, security enforced at the perimeter, network, host or application layers, while necessary, is not sufficient when what you’re really trying to accomplish is to security the Data.
Disclosure: I started my IT career in the desktop arena, and I’ve grown into the server and enterpise data arena over time. It’s been a great journey, but I’m probably still biased towards the PC at heart.
Certainly your ability to protect each set of data scales much better, the further you draw it out towards the perimeter. However, in my experience, you sacrifice the ability to provide very specific protections for the data inside the perimeter, for example:
- the firewall rule which blocks or allows 80/tcp access doesn’t provide an ability to authorize access for specific groups of users (only for IP addresses or subnets)
- the host security that allows/denies a user to Logon to the host (e.g. “access this computer from the network”) doesn’t give you the ability to allow the user to only access one set of data on the host but not access all other sets of data on the host
- the application protection (e.g. SQL per-user/group roles assignment, Samba per-folder ACLs, email per-server/mailstore ACLs) don’t allow you to protect individual pieces of data accessed through the application that “front-ends” the data, though often the application can also provide built-in “bulk data protection” mechanisms. However, if another application were used to access the same on-disk data, it is often possible for the application-level protections to be completely bypassed.
In my opinion, the defining characteristic of data-level protection is that it only allows access for the authorized user(s) to the authorized data (set(s)), no matter what application or OS is used to access the data.
In the extreme, this definition would only include data that has been encrypted such that only the key that is in the authorized user’s posession can unlock the data (e.g. PGP, S/MIME).
Examine for a moment what happens when you rely only on the application-level security:
- Windows file share-level permissions could be bypassed by users who can access the admin shares, a Remote desktop or an FTP session
- SQL roles-based access can be bypassed by anyone who can mount the .mdf file as a new database instance, or who has one of the privileged server or database roles such as sysadmin or db_owner.
In each example, the application protections that were meant to protect the data itself has not been changed, but the data could be accessed by the user (attacker) even though the application protections were configured to block the user.
The principle of “defense in depth” implies that the more layers of defense, the better the asset is protected against a failure at any one layer. However in my experience, a valued asset will “grow” new methods of access over its lifetime – e.g. a mainframe application may start out with access only from terminal emulators, then PC access is added via Communications Server & PComm, then later a Web Services interface is added to the mainframe for direct browser-based access.
The mainframe application may not have changed in the slightest throughout all this, but the “DiD” model that was suitable at first may not be appropriate to protecting from the threats that are now possible via the new interface.
Data-level protection may not require encryption to prevent access, but it’s the only significant protection I can think of, and it seems to be the protection to which most people turn. You can also add DRM (or ERM, RMS, etc.), but if it doesn’t also include encryption, to me it’s pretty much ineffective at actually protecting content you’ve given to someone else from being exploited beyond the rights you wished to assign.