But times have changed (mostly). While there are still "enterprise" grade apps that don't understand identity management strategies (especially, from my experience, in the ASP/Hosted environment-- "Identity Federation" has yet to catch on like wildfire, probably mostly as a result of all of the differing federation standards out there; and like a friend of mine says: 'the wonderful thing about standards is that there are so many from which to choose'), generally speaking the 'industry' has matured to the point now where I actually see some applications come in now with the mantra: "why would we want our app to keep track of users-- aren't you already doing that someplace else?"
Ah, but there must be a reason for me to bring up identity management ...
Security products vendors (specifically, ones that don't focus on identity management as their core competency) range from really bad (Symantec) to 'we get it for users, but not admins' (PGP) to 'yeah, ok, but we will only support one method and it may not be the most flexible for you' (Sourcefire).
Let's take a pause and first make sure we're on the same page with our definitions...
"Identity Management" is comprised of the "Authentication" and "Authorization" of "principals" (I'm abstracting up a layer here to include "users", "computers", "systems", "applications", etc.), as well as the technology used to make managing those aspects easier, (of course) as the business processes require.
Wikipedia's definition of "authentication" is fine for our purposes:
"Authentication (from Greek αυθεντικός; real or genuine, from authentes; author) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying their identity. Authentication depends upon one or more authentication factors."Wikipedia's definition of "authorization" is less general, unfortunately, but you'll get the point:
"In security engineering and computer security, authorization is a part of the operating system that protects computer resources by only allowing those resources to be used by resource consumers that have been granted authority to use them. Resources include individual files or items data, computer programs, computer devices and functionality provided by computer applications."
Now let's move on ...
Symantec's Enterprise Anti-Virus suite (which now has the personal firewall, anti-spyware, and probably anti-[insert your marketing threat-du-jour here]), doesn't actually even have authentication for most of the administrative components in its version 10 suite; technically, it only has authorization. To get into the administrative console, you must know a password; this is not authentication in that an admin is not presenting an identity that must be validated by the password-- the admin just presents a password. This is just like using the myriad of Cisco products without RADIUS/TACACS+ authentication: just supply the "enable" password. Fortunately for Cisco, they get this fairly well now. Especially since this product line is for enterprises with Microsoft products, I am surprised that they didn't (at a minimum) just tie authentication and authorization back to Active Directory users and groups.
The threats/risks here are the same ones that come with all password management nightmares. An admin leaves; the one password needs to be reset. Somebody makes an inappropriate configuration change; there's no accountability to know who it was. Those are fundamental identity management problems for enterprises. It is such a shame that a security products vendor couldn't have spent the extra 20 hours of development time to implement some basics.
Moving up a notch in the identity management of security products' food chain, we come to PGP's Universal Server. [All thoughts that I am recently picking on PGP aside, please. This is not a vulnerability, but creates risky situations-- albeit not as bad as the ones I described above for Symantec.] One of the novel features the PGP Universal Server brought to the market was its ability to do key management for users ... Read that: it is good at managing users' keys. User identities can even be tied back into LDAP stores (or not). Public Key crypto (PKC) is manageable even on large scales.
However, what the PGP Universal Server is lacking is the identity management of administrators; administrator credentials are stored within the PGP Universal Server's application code. There is no tie back to a centralized user repository for administrative access. Read that: it is bad at managing admins. If you are an enterprise and you want your 24x7 helpdesk to be able to generate recovery tokens for your whole disk encrypted users, you have to provision yet-another-account for them. If you are an enterprise that wants to leverage an outsourcing arrangement for your helpdesk (which is in and of itself a risky business-- manage your contracts well) and provisioning and termination of your helpdesk staff is important-- look elsewhere, as you'll find nothing helpful here. You'll either have to give some 'supervisor' person the ability to generate helpdesk accounts within the PGP Universal server, or your enterprise's security practitioners will be busy with mundane account creations/terminations.
Why oh why, PGP Corp, did you not build in support for LDAP, Kerberos, RADIUS, TACACS+, SAML, SOA Federation, or one of the other in the myriad of authentication services for managing administrative access to the PGP Universal Server?
Another issue is the notion of authorization within the PGP Server's application. There are several access "roles", but they are all or none. It is not possible-- in today's version-- to authorize a helpdesk user to generate one-time recovery tokens (in the event that a user cannot remember their boot password) for only a subset of computers protected by and reporting to a PGP Universal Server. Say you want your helpdesk to manage all computers except for a special group (e.g. Finance, HR, Executives, etc.). In PGP's product, that sort of authorization control requires a whole new instance; you cannot achieve that level of authorization separation within the tool. It's all or nothing. [Which is considerably similar to how many of PGP's products work-- a binary action. A user is either trusted to have access to the Volume Master Key in PGP Whole Disk Encryption or the user is not trusted at all. There's little sense of what a user can do versus an administrator, let alone a global administrator versus helpdesk personnel.]
Sourcefire is an example of the next tier on the totem pole of identity management inside of security products. Users can log in either locally (application layer accounts, not OS) to the Defense Center console or the server can be configured to authenticate and authorize users against LDAP. This is great when it comes to provisioning/terminating access or just managing password compliance across a range of distributed systems. However, just like the security products mentioned above, I would have liked to see the vendor do more. LDAP is a great protocol for standard user directories, but for environments where access to intrusion detection logs is sensitive business, a natural requirement is multi-factor authentication. Very few one-time-password generators (e.g. RSA SecurID or Secure Computing's Safeword) truly support LDAP as a method of authenticating users. It's even harder still to get other forms of second-factors (i.e. biometrics or smart cards) to work with LDAP. I would have preferred to see a more flexible authentication and authorization architecture, such as requiring both LDAP and RADIUS to handle the situation where an Active Directory password and RSA SecurID token would be required for access.
Moral of the today's story? If you are a security products vendor, make sure you encompass all of the security requirements that are placed upon non-security products.
No comments:
Post a Comment