Watching the Watchers: Integration

As we wrap up the Watching the Watchers series, it’s good to remind ourselves of the reality of enterprise security today. Basically nothing stands alone, not in the enterprise management stack anyway, so your privileged user management functions need to play nice in the sandbox with the rest of your management tools. There are levels of integration required, as some functions need to be attached at the hip and others can be mere acquaintances.

Identity Integration

Given that the U in PUM stands for user, clearly the Identity infrastructure is one of those categories that need to be attached at the hip. What does that mean? We described the provisioning/entitlements requirement as part of the Privileged User Lifecycle post. Since identity is a discipline itself, it isn’t really in the scope of this series to delve too deeply into the Identity topic.

From an integration standpoint, your PUM environment needs to natively support your enterprise directory. It makes no sense to have multiple authoritative sources for users. Since privileged users (by definition) represent a subset of the user base, you use the main directory to house your users. This is critical both from the standpoint of provisioning new users and deprovisioning those who no longer need specific entitlements. Again, the PUM’s responsibility is to enforce the entitlements, but the groupings of the administrators resides in the enterprise directory.

Another requirement for identity integration is supporting two-factor authentication. Remember, PUM protects the keys to the kingdom, and if a proxy gateway is part of your PUM installation, it’s paramount to make sure a privileged user is actually that user. That means some kind of multiple-factor authentication, as you want to protect against an administrator’s device being compromised and an attacker gaining access to the PUM console. That would be a bad day. We don’t have any favorites in terms of stronger authentication methods, though will not that most organizations opt for the tried-and-true token.

Management Infrastructure

Another area of integration is the enterprise IT management stack. You know, the tools that manage data center and network operations. This can include the configuration, patching, and performance management. This integration is more of an alert push to an ops console. For instance, if the PUM portal is under a brute force password attack, you may want to notify the ops folks to investigate. The PUM infrastructure also represents devices, so there will be some device health information that could be useful to the ops team. So if a device goes down or an agent fails, alerts should be sent over to the ops console.

Finally, you’ll also want to have some kind of help desk integration. Some ops tickets may require access to the PUM console, so being able to address a ticket and close it out directly in the PUM environment could streamline the operations process.

Monitoring Infrastructure

Finally the last area of integration will be with your monitoring infrastructure. Yes, your SIEM/Log Management platform should be the target for any auditable event in the PUM environment. First of all, best practice for log management is isolating the logs on a different device, to ensure log records aren’t tampered with in the event of device compromise. To be candid, if your PUM proxy is compromised, you have bigger problems than log isolation, but all the same you want to exercise due care in protecting the integrity of the log files.

You also want to send events over to the SIEM to provide more detail around user activity monitoring. Obviously a key aspect of PUM is privileged user monitoring, but that pertains only when the users access server devices with their enhanced privileges. The SIEM is watching a broader activity base, which includes accessing applications, email, etc.

Don’t expect to start pumping PUM events into the SIEM and fairy dust to start floating out of the dashboard. You’ll still need to do the work to add correlation rules that leverage the PUM data and update reports, etc. We discuss the process of managing the SIEM rules sets pretty extensively in both the Understanding and Selecting SIEM/Log Management and Monitoring Up the Stack papers. So check those out for more detail on that process.

And with that, we’ll wrap up this series. Over the next few weeks, we’ll be packaging up the posts into our white paper format and having our trusty editor (the inimitable Chris Pepper) turn this drivel into coherent copy. Until then you can check out the other posts in this series:

1. Keys to the Kingdom (Introduction)
2. The Privileged User LIfecycle
3. Restrict Access
4. Protect Credentials
5. Enforce Entitlements
6. Monitor Privileged Users
7. Clouds Rolling In