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.
Morey J. Haber, Chief Technology Officer and Chief Information Security Officer at BeyondTrust
Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.