Privileged Behavior Analytics Recap
Thycotic’s Privileged Behavior Analytics (PBA) software monitors user activity within Secret Server to detect anomalous behavior. Once the user’s baseline activity is determined, deviations from that behavior can trigger alerts or warnings to notify security admins. The software’s machine learning considers the time of day, IP address, user history, Secret importance, and other factors to determine a risk score for the user. Behavior that would go unnoticed for weeks by human administrators can be immediately detected.
Getting an alert when suspicious behavior is detected is better than digging through logs manually—but what happens when nobody is checking their email?
When Alerts are Not Enough
Getting an alert whenever suspicious behavior is detected is certainly better than digging through logs manually—but what happens when nobody is checking their email? If a malicious insider is grabbing every password they can find on their way out the door, an alert email is not enough. In a situation like that, action needs to be taken in minutes, not hours.
Enter Responsive Actions
In Privileged Behavior Analytics, both Warnings and Alerts can be configured with Response Actions. Administrators can choose what action should be taken in addition to an alert being sent, so that the suspicious user’s actions can be limited or stopped completely without human intervention. There are several types of Responsive Actions in PBA, and each can be assigned to either a warning or an alert action.
This Responsive Action simply forces the user to pass a two-factor verification check. This could be a situation in which an employee’s Active Directory credentials were compromised, and you want to ensure the user behind the keyboard is who they claim to be. Even if the user passed a two-factor check upon login, an additional Two-Factor check can be useful. If a user goes to the bathroom and leaves his or her computer unlocked, someone might sit down at their desk and begin accessing passwords that the rightful user would rarely use. PBA can recognize that kind of unusual activity and automatically force the user through a two-factor check that an attacker would be unable to pass.
A stricter method of controlling suspicious access is to require that the user requests permission to view any additional Secrets. Normally, Request Access is a feature that needs to be enabled on each individual Secret, or on a folder via a Secret Policy. With PBA, the “Request Access” requirement sticks to the user instead. A suspicious user won’t notice that anything is wrong until they try to access another Secret, at which time they’ll need to enter a reason and wait for another user to approve.
The last resort: lock the user out completely for an extended period of time so that a human Administrator can review the flagged activity. The downside to this option is that the user cannot do any work until their access is restored, so this option should not be used lightly. One strategy is to customize the Warning and Alert thresholds to be stricter, so that Warnings correspond to a risk score that previously would have sent an Alert. This way Alerts can be saved for more serious situations with higher risk scores, ultimately locking the user out.
Coming Soon: Web Hooks
Is email the best way to get hold of you? Probably not. Web Hooks allow PBA administrators to add their own customized actions that occur in addition to the email alert and any Responsive Actions that have been selected. Want an incident opened in ServiceNow so security administrators can follow up on the alert and review the activity? No problem. Want to be messaged on Slack, or even texted when an alert occurs? Web hooks can do that, too. Web Hooks will be available to customers using Secret Server 10.4 or later starting in March 2018.
Coming This Summer: Risk-Based Session Monitoring
Similar to Request Access, Session Monitoring will be available soon as a Responsive Action. If a user triggers a Warning or an Alert, all of that user’s launched sessions will be able to be recorded even if that feature had not been enabled on the Secrets that user accesses. The Session Monitoring notification can also be disabled in this situation so that the user does not realize they are being recorded.
*** This is a Security Bloggers Network syndicated blog from Thycotic authored by Dan Ritch. Read the original post at: http://feedproxy.google.com/~r/Thycotic/~3/agg_V3Tv1Ho/