This may appear to be a rather odd combination. However, since it's all about the data, anything that protects the data is fair game for our consideration. With that in mind, we begin by taking a close look at the three product types in this month's group.
The easy one is identity management (IdM). It's easy because IdM is a traditional approach to dealing with access management, especially in a large enterprise. The traditional issues of access management are identification, authentication and authorization. Identity management has some fairly tough tasks to perform, especially when a large enterprise is splashed across the planet. The first one of these that comes to mind is provisioning.
While there is no argument that IdM has other tasks to perform - administration of individual identities, managing roles, managing access privileges, and more - getting users that are widely disbursed hooked up and authorized starts with figuring out how to set up their accounts without being as widely distributed as the users. That often just isn't practical, so today's IdMs favor self-provisioning. This is a technique that moves the provisioning as close to the user as possible. Since IdMs are almost always policy-driven, this is not an impossible feat.
The bottom line is that everyone who needs to access data on the enterprise must have exactly one and only one identity. This one-person-one-identity scheme enables auditing and, thus, enables security management to the granularity of the user. Not so long ago, the individual functions of IdM were carried out by different types of products or by individual applications. Today, all of the important functions of IdM are bundled into a single product, usually an appliance. That is no mean feat because modern enterprises have a wide variety of devices - such as desktops, laptops, servers, mobile devices and more They all need identity management to protect the data.
Data leakage prevention (DLP) is another area that has evolved significantly over the past few years. The most important aspect of the maturation of DLP has been the simple recognition that data needs to stay where it can be controlled. It has been common practice to configure firewalls to block traffic from the public network inbound to the protected network, but not to block the outbound traffic. That has become seriously problematic since the current start of the attacker's art is focused on stealing from a network.
Theft of data comes in a lot of flavors. Data can be removed physically on a thumb drive, it can be emailed out by an employee or it can be taken by malware. Bots that sit quietly on an enterprise, harvest sensitive data, such as credit card numbers, and phone home periodically to ship out their payloads. A good DLP can handle most types of data exfiltration. There are challenges, of course, such as encrypted data. Encrypted data can't be identified as exfiltrated data.
Finally, we come to network access control (NAC). NAC has been a favorite of ours since it started to appear on the scene several years ago. If we want to manage authorization from a central location for a large enterprise we really can't see any other way to do it practically. NAC comes in a couple of configurations. There are inline NACs that sit between the inside and outside, sort of like a gateway. Our preferences, though, are for those that are not inline. This removes the bottleneck that an inline device can present. That is a bit controversial, though, so rather than get into a religious debate, we'll leave it at that. However, administrators should consider which of these architectures fits the enterprise's needs best.
We like a NAC that has a lot of functionality. NACs can perform an important function on the enterprise: they can provide a basis for authorization. In other words, once a user has been identified and authenticated, what can that user do? What resources can they access? How is the user permitted to interact with the resource?
We also like a NAC that is easy on the user. There are NACs that we find intrusive. They are constantly checking computers to see if it is properly protected and it gets in the way while it is doing that. Since a good NAC deals with devices as well as users, it is, of course, necessary to check a computer to ensure that it meets the policy requirements of the organization. However, it should not get in our way when it does that unless a device doesn't measure up.
