Controlling the Core

Regardless of whether an application solution suite is hosted on premise, in the cloud or some combination of the two, someone somewhere still needs to access server space to perform the basic functions of installation, configuration, and maintenance. Of course in cloud space this may be somebody else’s problem while in on premise space the responsibility may be squarely on your shoulders.

Computer security has not changed much in the past generations of hardware spinning and operating system re-inventing. The current access model still uses the same authentication components of something you are, something you have, or something you know with the most basic and easiest offering being a username and password combination. On the authorization front we still have user and group ID’s for UNIX and a plethora of fine-grained pre-defined access rights for Microsoft Windows.

While the standard tried and true resident security systems are quite good for blocking aberrant access at most levels, every operating system has one security hole that is the holy grail of rogue access. On UNIX this is root and on Microsoft Windows this is Administrator. Sure, the names can change to protect the innocent (renaming Administrator, for example) but once kernel-level access has been attained then the world is the infiltrator’s oyster to be consumed slowly and with savor.

In the not too distant past, waves of technologies were introduced to audit the activity of key players. It was believed that if one could review what happened during a malicious event then the exposure could be mitigated somewhat to recover assets and prevent future failures. Recording activity is a very good way to watch the good guys do good things for compliance auditability, but it does nothing to prevent the truly malicious administrator from just plain copying or wiping an entire system. Simply put, auditing is akin to watching a video of your 100 inch television walk out your front door with absolutely no power to block the exit.

To counter the audit-only model and bring a scoped limitation to sensitive account access, CA Privileged Identity Manager (PIM) was introduced. The term PIM has seen several iterations from Shared Account Management (SAM) to Privileged Access Management (PAM) and back to PIM. But, while the acronyms have changed, the concept has remained the same. Basically, grant uber access to those users that require such access but control the granting to a pre-defined protocol.

In the UNIX world this means that the root user has the ability to log in as root, but only if someone else agrees to, or grants, the permission to do so. Since multiple administrators may need to access the root account, the account is known as being “shared”; hence the Shared as in the SAM acronym.

The PIM model, then, gives a user the key to the front door, a locked closet or safe; and allows that user to access the facility. You may have multiple users with the same key in the same space at the same time, but proper monitoring (auditing, recording) will show what each individual is doing.

Now, in all honesty, UNIX and Linux have done a fine job of removing the user named “root” from the requirement of being directly accessed. Specifically, the current secure shell (SSH) offerings can prohibit direct root log on, and the sudo (superuser do) facility enables a “common” user to perform root-level functions simply by issuing agreed upon, or granted, commands. SeLinux is in the offering, as well. And, as mentioned, Microsoft Windows has a very nice array of roles that may be assigned to enable users to have quite a range of privileges.

So, we now have both UNIX and Microsoft Windows with administrative scope limiting resident security system abilities, a PIM model to limit uber access in addition to the resident security model, and monitoring to record all activities. Great!

Well, no.

The preceding keeps honest people honest but does not address what happens when yet one more hole is exposed. And, yes, the axiom of all software is that “there is always one more bug or one more hole.” So, whether it is a buffer overflow exposure or some other obscure entry point, you can be assured that someone somewhere will find something that is not good.

Zero Day attacks are no longer infrequent but sufficiently common to finally make exposed financial data a Dark Web commodity. And, yes, phishing is a primary entry point; hence the comment about PIM and recording keeping honest people honest.

CA Technologies (CA) Privileged Identity Manager is a server centric security offering that has the power to scope root on UNIX and Administrator on Microsoft Windows. The operative words here are “server centric” and “scope”. Simply put the server component of CA Privileged Identity Manager works at a level that will block even a root shell access compromise.

The way this works is not magic but is based on kernel level syscall intercepts combined with a two-factor user identification model.

Upon server log on, CA Privileged Identity Manager captures the logging in user and writes that datum to a private internal table. The user noted in the initial log on event is the user that is then checked against resource access authorizations.

For example, if Alice logs on and su’s to root, CA Privileged Identity Manager will know the user as Alice while UNIX will know the user as root. So, for all UNIX activities, the current shell is treated as root. But, and this is a very big and very protective but, if there are private data that should only be accessed by Alice then any other “root” user will not have the ability to access those data. Even if a “true root” logs in that user will not be able to access Alice’s data.

Where this multi-level access scoping is very important is in the situation where truly private data should be maintained as truly private data. Just because a shell can rationally gain access to or usurp kernel level access should not mean that the shell should be able to access protected data.

Think about it.

In closing, the above discussed a bit using UNIX examples but as goes UNIX so goes Microsoft Windows. The very same security offerings are common in both operating systems so it is possible to ensure that Alice’s data are protected on both UNIX and Microsoft Windows.

And, yes, CA Technologies has a PIM offering as does CyberArk, Lieberman, and others. But, this discussion deals with controlling the core data access which is fundamental to all server suites and should be considered regardless of the PIM provider in use.

Dennis PierceIT Security Architect