As we wrap up Watching the Watchers it’s worth reminding ourselves of the reality of enterprise security today. Nothing stands alone – not in the enterprise management stack anyway – so privileged user management functions need to play nicely with the other management tools. There are levels of integration required, as some functions need to be attached at the hip, while others can be mere acquaintances.
Given that the ‘U’ in PUM stands for user, clearly Identity infrastructure is one of the categories that needs to be tightly coupled. What does that mean? We described the provisioning/entitlements requirement in the Privileged User Lifecycle. But Identity is a discipline itself, so we cannot cover it in real depth in this series.
In terms of integration, your PUM environment needs to natively support your enterprise directory. It doesn’t really work to have multiple authoritative sources for users. Privileged users are, by definition, a subset of the user base, so they reside in the main user directory. This is critical, for both provisioning new users and deprovisioning those who no longer need specific entitlements. Again, the PUM Lifecycle needs to enforce entitlements, but the groupings of administrators are stored in the enterprise directory.
Another requirement for identity integration is support for two-factor authentication. PUM protects the keys to the kingdom, so if a proxy gateway is part of your PUM installation, it’s essential to ensure a connecting privileged user is actually the real user. That requires some kind of multiple-factor authentication to protect against an administrator’s device being compromised and an attacker thereby 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 we note that most organizations opt for tried-and-true hard tokens.
Another area of integration is the enterprise IT management stack. You know, the tools that manage data center and network operations. This may include configuration, patching, and performance management. The integration is mostly about pushing alert to an ops console. For instance, if the PUM portal is under a brute force password attack, you probably want to notify ops folks to investigate. The PUM infrastructure also represents devices, so there will be some device health information that could be useful to ops. If a device goes down or an agent fails, alerts should be sent over to the ops console.
Finally, you will 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 operations.
The last area of integration will be monitoring infrastructure. Yes, your SIEM/Log Management platform should be the target for any auditable event in the PUM environment. First of all, a best practice for log management is to isolate the logs on a different device to ensure log records aren’t tampered with in the event of a compromise. Frankly, if your PUM proxy is compromised you have bigger problems than log isolation, but you should still exercise care in protecting the integrity of the log files, and perhaps they can help you address those larger issues.
Sending events over to the SIEM also helps provide more depth for 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 watches a much broader slice of activity which includes accessing applications, email, etc.
Don’t expect to start pumping PUM events into the SIEM and fairy dust to start drifting out of the dashboard. You 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 SIEM rule sets fairly extensively in both our Understanding and Selecting SIEM/Log Management and Monitoring Up the Stack papers. Check them out if you want more detail on that process.
And with that, we wrap up this series. Over the next few weeks we will package up the posts into a white paper and have our trusty editor (the inimitable Chris Pepper) turn this drivel into coherent copy.