Recusing Yourself from Session Monitoring

Regulatory compliance requires that all privileged sessions into sensitive systems have full auditability. This includes logging, activity monitoring, and in many cases, session monitoring.

Recently, I was asked an interesting question: “Is there any business or technical reason that an administrator should ask security or IT operations to recuse themselves from session monitoring?”

In fairness, I had to think long and hard about this one. And, every single use case I came up with was due to deficiencies in the session monitoring utility itself and not due to the task. These deficiencies include (but are certainly not limited to):

• Inability to mask or obfuscate personally identifiable information displayed on the screen
• Failing to recognize password entry fields and capture them as potentially plain text when entered by the user
• Violating applicable policies such as FOUO (For Official Use Only) that may duplicate sensitive information for auditing purposes

And to be fair, there are other excuses I hear regularly that are legitimate, including:

• There is no sensitive data on this system
• The asset is not critical or a Tier-1 environment
• It is a lab or test environment

Now, this is where it gets tricky. Using an excuse purely based on the deficiencies of a tool is not acceptable. However, using an excuse based on the resource risk surface is acceptable. But what happens if the lab, test environment, or other development system contains un-sanitized test data or other information that potentially poses a risk if compromised? You cannot recuse yourself from session monitoring if there is an overlap in the use cases and sensitive data on those resources too. A valid argument for session monitoring recusal must consider the following:

• The resource sensitivity and classification (DMZ, Cloud, Test, Production, Tier 1, Lab, Development, QA, etc.)
• Lateral movement risk when accessing the resource
• The infonomics of the data present on the resource, or potentially accessible from the resource
• The level of privileges granted for the session
• Other security logging, governance, and tools monitoring the resource and session activity

Therefore, you must perform session monitoring if any of these quantify as an unacceptable risk. You can only recuse yourself when the risk or governance does not warrant the process. The tool itself can never be the excuse--but unfortunately, we often hear that argument. Try not to let it undermine your governance efforts.

If you have ever been in the position of recusing yourself or a colleague from session monitoring due to limitations with the session monitoring tool itself, please consider BeyondTrust’s PowerBroker Password Safe, PowerBroker for Unix & Linux, and PowerBroker for Windows. These solutions contain key features to recognize applications, passwords, and screen data that could be considered sensitive, and mask the information, when possible. If you would like more information on how these solutions can address your session monitoring and governance needs, contact us today.