Today, we’re excited to announce Panther’s integration with Push Security as a log source provider. Push is a browser-based agent that generates unique endpoint and identity telemetry to detect and prevent identity breaches. At Panther, we’re always looking for impactful security information in our customers’ environments to bring into Panther. With identity-based attacks being so common and impactful, identity telemetry data directly from users’ browsers is exactly the kind of high-impact logs we want to support.
As a starting point for this integration, we want to discuss two exciting identity attack detection use cases made possible by bringing Panther and Push together.
Our first use case involves a combination of Panther’s new Correlation Rule capabilities and Push Security’s new session hijacking detection feature. Panther’s Correlation Rule capability allows you to define sequences or groups of behaviors that, when seen together, indicate a potential attack, even if separately they might be harmless or prone to false positives. Push Security’s new session hijacking feature allows you to force all logins from managed devices to append a unique string, called the user agent string marker, to the User Agent of the request. The absence of this string would indicate an authentication from a non-managed device, potentially as a result of compromised credentials.
So how can we bring these two capabilities together? We can start with a Panther rule that looks for any Okta logins missing the Push User Agent string marker.
This rule looks for any Okta sign-ins where the user agent is missing our organization’s unique user agent string. In an environment where all your users are logging in from managed devices, this is all we need! We know every login will have this token appended to the User Agent field, and any logins missing it are immediately suspicious and worthy of an alert to your security team.
But unfortunately, not all of us are so lucky to have our entire organization restricted to managed devices. In the current world of hybrid work environments, we have team members logging in from phones, tablets, cloud compute resources, and sometimes even personal computers. Alerting on the lack of the Push marker could lead to false positives in these cases. This is where Panther’s Correlation Rules and Push’s phishing detection features improve the fidelity of this alert.
Push has a number of capabilities to detect potential phishing attacks. We can use Panther’s Correlation Rules functionality to correlate a login without a Push user agent string marker to a potential phishing attack and alert with very high confidence. Let’s take a look.
Here we can see a very simple sequence Correlation Rule. If we ever see Push identify a potential phishing attack followed by an Okta login without the Push marker, we create an alert. In this case we’re correlating the new.employee.email field from the Push security logs to the actor.alternateId field from the Okta system logs to make sure we’re only alerting when these both happen for the same user.
This is higher fidelity than alerting on either step in isolation, as the first step indicates a phishing attack was attempted but not necessarily successful and the second step could be indicative of a normal login from an unmanaged device. But in concert, they tell a story that is highly indicative of a compromised user!
Our second use case is another way to detect identity attacks, but this time by taking advantage of Push Security’s browser agent telemetry data directly instead of the Push identified attacks. We’ll once again be using Panther’s new Correlation Rules capabilities to do this.
When a user signs in through a device with the Push browser extension, this creates telemetry data in the form of the PushSecurity.Activity log type in Panther. We can use this information to make note of when a user is logging in legitimately, and alert when we see IDP authentication logs for a user without the corresponding Push telemetry data.
To start, we create a Panther signal every time we see a successful Okta login. Note that Create Alert is toggled off, this is important because we don’t want to alert on this behavior! We are only creating signals here, to be used by our Correlation Rule later.
Next, we will create a Panther signal every time we see Push telemetry data indicating a legitimate login for this user. Again, we are only creating a signal here, not an alert, because this is not suspicious activity. This is exactly what we expect to see.
Now we can tie these two innocuous signals together by using the Must be Absent clause of Panther’s Correlation Rules feature. We define a Sequence Correlation Rule which will alert whenever we see an Okta login signal and then the absence of corresponding Push browser telemetry data within 5 minutes of that login. Here we would always expect a legitimate Okta login to be followed by corresponding Push telemetry data, so the presence of one without the other is alert worthy! This means a user’s credentials might be compromised, and an attacker is authenticating as one of our legitimate users from an attacker controlled device.
We’re very excited to be integrating with Push Security, both so that we can centralize security findings from our customer’s tools and pass those forward, and also so we can take advantage of the unique browser identity telemetry data made available from the integration. In both cases, we believe these findings and data becomes even more useful when correlated across time & log types with Panther’s Correlation Rules functionality to create high fidelity detections of identity based attacks.
