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 Security Officer, BeyondTrust
Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four books: Privileged Attack Vectors, Asset Attack Vectors, Identity Attack Vectors, and Cloud Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. 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.