Netskope Global Technical Success (GTS)

UEBA: Compromised Credentials - General Q/A

Netskope Cloud Version - 119

Objective

UEBA Compromised Credential - General Q/A

Prerequisite

Netskope UEBA license is required

Context

This document contains general Q&A related to Netskope UEBA Compromised Credentials

Parent Article

Link

Lets Begin

• Question 1: Netskope Compromised Credentials?

Answer: Netskope Compromised Credentials refers to the feature that identifies when user login information has been compromised or is being misused, helping organizations detect and respond to potential security breaches promptly.

• Question 2: What are the origins of Netskope's Compromised Credentials data?

Answer: Netskope's Compromised Credentials feature is typically sourced from various data feeds and sources that provide information on compromised or leaked credentials. Netskope partners with various vendors, and their sources of information may include: -

1. Hacker dump sites
2. Black market
3. Hacktivist forums
4. File sharing portals
5. Data leaks
6. Keylogger dumps
7. Malware logs

• Question 3: Do Netskope's partners provide detailed information about the sources from which they collect data on compromised or leaked credentials?

Answer: Netskope partners exclusively with market leaders. They provide Netskope with a feed of compromised or leaked credentials only after validation. Netskope then shares this validated top-level information with customers through compromised credential alerts.

• Question 4: Where can we locate alerts for Compromised Credentials on the Netskope Tenant?

Answer:

Option 1 - Path: Netskope Tenant UI >>> Incidents >>> Compromised Credentials

Option 2 - Path: Netskope Tenant UI >>> Skope IT >>> Alerts

Filter: Alert Type: Compromised Credentials

• Question 5: In some Compromised Credentials incidents , the "Date Compromised" field is marked as 'Not Available'. Why is this the case?

Answer: In some Compromised Credentials incidents, the "Date Compromised" section may be marked as 'Not Available'. This typically occurs because the exact date when the credentials were first compromised may not be known or recorded. The information might be incomplete due to the nature of the breach, limitations in the data available, or challenges in pinpointing the exact moment of compromise.

• Question 6: In the below reference image, how can a customer retrieve the specific application events where the end-user utilized the email ID listed in the Matcher User section?

Answer: 

Filter - (from_user eq ‘grprtsnghxxxxxx.com’)

• Question 7: If a breach occurs tomorrow, how promptly is the Compromised Credentials Database updated?

Answer: Netskope updates the Compromised Credentials Database daily. Therefore, in the event of a breach today, Netskope ideally detects it within 2 days.

Note - It's important to note that breaches often occur weeks or months before they are announced, so strict timeliness in detection has limited effectiveness

• Question 8: Can Netskope provide detailed password-level information associated with a Compromised Credentials alert?

Answer: As per the design of Netskope Compromised Credentials, Netskope does not save and share password-level information associated with a Compromised Credentials alert

• Question 9: If the customer resolves these compromised passwords, how should Netskope update the UI to indicate that these accounts have been mitigated?

Answer: Once the remediation is complete, Admin should acknowledge the breach events. Once acknowledged, Netskope will no longer display that alert in future

• Question 10: Can the Netskope Compromised Credentials service be disabled from the backend?

Answer: Yes, it can be done, but please note that disabling this service is not recommended.

• Question 11: What are the recommended Netskope best practices for handling Matched User - Domain Users versus Non-Domain Users scenarios?

Answer:

For Domain Users - Makes sure that the end-user updates the passwords ASAP

For Non-Domain Users - 

1. While matching with a @gmail.com, @yahoo.com, @live.com, @outlook.com is acceptable.
2. Educating end-users about refraining from using non-sanctioned applications on official machines is a viable approach.

Note - It's important to educate end-users about the risks associated with using official email addresses for non-sanctioned or non-business applications. Netskope recommends implementing the following security measures:

• Avoid Using Official Email Addresses: Encourage users not to create accounts on non-sanctioned or non-business applications using their official email addresses. Using personal email addresses for such purposes helps mitigate security risks.
• Enable Multi-Factor Authentication (MFA): Ensure that all business applications are enabled with multi-factor authentication (MFA). MFA adds an extra layer of security by requiring users to provide additional authentication factors, such as a code sent to their mobile device, in addition to their password.
• Implement Password Update Policy: Enforce a password update policy to ensure that users regularly update their account passwords. This helps prevent unauthorized access in case of compromised credentials.

By following these recommendations, organizations can enhance their security posture and reduce the risk of unauthorized access to business applications.

Terms and Conditions

• All documented information undergoes testing and verification to ensure accuracy.
• In the future, If any such platform changes are brought to our attention, we will promptly update the documentation to reflect them.

Notes

• This article is authored by Netskope Global Technical Success (GTS).
• For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.