Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Advantages of a Cloud DLP and introduction to Nightfall cloud DLP
In today's data-centric environment, organizations are moving to the cloud to cut down infrastructure expenses and concentrate only on their organization tasks thus empowering them to build powerful applications catering to their customers.
When organizations migrate to the cloud, their entire infrastructure is stored on the cloud. The organization's infrastructure moving to the cloud implies that its sensitive data is also stored in the cloud. Sensitive information being stored in the cloud is becoming a normal phenomenon.
A Cloud security survey conducted by Thales on 3000 IT professionals across 18 countries revealed eye-opening facts. A whopping 75% of respondents said that around 40% of their data stored in the cloud is sensitive. With Cloud being the go-to option for modern businesses, the amount of sensitive information moving to the cloud will only increase in the coming years.
The sensitive data stored on the cloud can either belong to the organization itself or it can be the customer's data required for business purposes. If this sensitive data is lost or even exposed to unauthorized users the consequences can be fatal for organizations and their customers. It's the responsibility of the organization operating in the Cloud to ensure the safety of customers and their sensitive data. Governments around the globe have defined complaint frameworks like GDPR, PII, HIPAA, and so on, which must be adhered to by cloud organizations that collect customer data for operations.
Data breach is a well-known threat that has already affected many businesses around the world and is continuing to do so, bringing companies to a standstill and in the worst cases even closure of businesses.
A data breach is a scenario in which your organization's data security is compromised by a malicious user or group (hacker), who steals your organization's sensitive data. Once the data is stolen, hackers can demand ransom to return your data which can lead to data loss by your organization. Hackers might even directly expose your sensitive data on platforms like the dark web without demanding any ransom.
As we saw in the previous section, a data breach can easily lead to data loss or data exposure. So, you need to prevent data breaches in your organization. But what exactly can cause a data breach?
The Infosecurity magazine's July 2023 article revealed that human error is the most common cause that leads to a data breach. Of all the data breaches caused, human error was responsible for 55% of the total data breaches. (The next distant factor was the exploitation of vulnerabilities which accounted for 21% of all the data breaches).
A human error is a scenario in which an employee from the cloud provider organization leaks out sensitive data unintentionally. This is known as a data leak. Data leaks are pretty common in organizations because employees are generally occupied in their day-to-day tasks. Some or most of their tasks involve the usage of sensitive data present in the organization. While using sensitive data there is a very high possibility that employees might leak it publicly, causing a data leak, thus leaving room for a potential data breach attack which can ultimately lead to data loss.
The following examples are scenarios of data leaks that can be caused by employees.
A developer commits a piece of code to GitHub that consists of an API key or some other credentials.
An employee shares an image in a public Slack channel that contains sensitive data.
A developer submits live API keys to ChatGPT to generate a block of code.
An employee uploads a document with sensitive data to a public Google Drive or AWS S3 bucket.
A support team member reveals secret data in a Zendesk ticket.
The above examples are pretty common cases of data leaks which are difficult for any organization to prevent. In the real world, many more scenarios of data leaks go unnoticed until they lead to a data breach. Even after a data breach, it could be difficult for organizations to figure out how hackers were able to gain access to sensitive data, which can help them stop such attacks in the future. It is only when organizations perform a hardcore root cause analysis they get to know that a minor data leak by an employee led to a mammoth data breach.
So, it's pretty clear that not exercising anti-data leak solutions in your organization is as good as serving your organization's sensitive data on a platter to malicious attackers. This is because some employee at some point is bound to accidentally cause a data leak.
Framing policies to protect sensitive data and educating employees about these policies is a common approach followed by organizations. However, every organization that experienced a data leak, did have data protection policies and implemented rigorous training to employees on adhering to these policies which unfortunately could not prevent the attack.
Another approach can be the use of Cloud Access Security Brokers (CASBs), or some data leak prevention (DLP) tools that can automatically halt unintentional data leak attempts by employees. However, the issue with such tools is that many of them cannot be used in the cloud. Some other DLPs are deployed as agents. The issue with these agents is that when information is transferred to cloud applications from unmanaged or off-network devices, these legacy solutions are powerless to intercept it. Once the sensitive information is stored within the cloud application or infrastructure, legacy endpoints, and network solutions can no longer see it. As a result, users of legacy DLP solutions are left with no visibility into sensitive data that already exists in the cloud, or which is being transferred to the cloud on unmanaged networks or devices.
So, how do you protect your sensitive data in the cloud?
Nightfall’s Cloud DLP provides a solution to this problem. Nightfall is cloud-native and integrates directly with other cloud applications and infrastructure at the application level via API. Nightfall can inspect content stored within the cloud application regardless of how it got there, for complete visibility into cloud DLP risk. Another key advantage of direct cloud-native integration is that Nightfall can take remediation actions on sensitive data that is discovered in the cloud, thus eliminating the DLP risk at the source - a method that legacy solutions cannot hope to achieve. Nightfall’s cloud-native DLP does not require the installation of agents and can be integrated with your cloud applications in just a few clicks. The result is a DLP solution for the modern world that can proactively identify and eliminate DLP risk across your cloud environment.
This section enlists the feature enhancements released by Nightfall in November 2024.
User and User Group Filtering in Google Drive: Nightfall now allows you to filter users and user groups in Google Drive policies. You can now choose to monitor or exclude the monitoring of specific users and user groups. Click here to learn more about this feature.
Support for Labels in Google Drive Policies: You can now use Google Drive Labels in Google Drive policies. You can use Labels during the configuration of Scope, Automated actions, and End-user remediation stages of a Google Drive policy. Click here to learn more about this feature.
Detectors for South Korea and Spain: Nightfall has released new detectors which support PII data protection for South Korea and Spain. Click here to learn more about the detectors.
Internal Data Governance in Posture Management: You can now monitor the addition of unsanctioned internal users and groups in Google Drive policies in posture management. With this feature, the Gives Access trigger is filters are now updated and allow you to include or exclude specific users and groups. Click here to learn more about this feature.
Monitor Sharing and Exfiltration of Labeled Assets: Nightfall now enables you to only monitor or exclude the monitoring of assets based on Google drive labels. This feature is applicable to Google Drive policies in exfiltration and posture management. Click here to learn more about this feature.
This section enlists the feature enhancements released by Nightfall in October 2024.
Upload Domain List to Domain Collection: Nightfall now allows you to upload a list of domains while creating a domain collection in the MAC endpoint integration. Click here to learn more about this feature.
Add Domain from Event Detail View: Nightfall now allows you to add a newly discovered domain which is listed on the Event detail view, to one of the existing domain lists. Click here to learn more about this feature.
New "Download Original Content" button in OneDrive: Nightfall has introduced a new action button Download Original Content in OneDrive. You can find this button on the OneDrive Event detail view page. This button downloads the content from OneDrive that contains sensitive data. Click here to learn more about this feature.
MAC OS Agent Auto Update: Nightfall can now automatically update the macOS agent without any actions needed from customers. This feature ensures that customers get agent bug fixes and feature updates directly to endpoints.
Domain Filtering in Data Security Posture Management Policies: Nightfall now allows you to filter and select specific domains and free email domains (ymail, gmail, and so on) for monitoring. Click here to learn more about this feature.
Support for Okta as an Identity provider: Nightfall now allows you to perform Directory Sync by using Okta as an Identity provider. Click here to learn more about this feature.
Slack User and User Group Filtering: Nightall now allows you to configure Slack policies by filtering specific users and user groups. Click here to learn more about this feature.
Support for Labels in Google Drive Policies (early preview): You can now use Google Drive Labels in Google Drive policies. You can use Labels during the configuration of Scope, Automated actions, and End-user remediation stages of a Google Drive policy. Click here to learn more about this feature.
Introduction of Playground 2.0: Nightfall has now enhanced the Playground capabilities. You can now use advanced features like 7 detection use cases across 20 top detectors providing real-time feedback as users type, use cases with preloaded sample data, and ability to instantly use detection capabilities with just a click. Click here to test the enhanced version of Nightfall playground.
Ability to Download Sensitive Data Events: Nightfall now allows you to export sensitive data events. You can click the Export as CSV button to download the data. The data is exported as a CSV file to the email ID of the logged in user. Click here to learn more about this feature.
Introduction of Events and Policies in Data Encryption: Nightfall has now introduced Events and policies in Data Encryption. You can now create policies in Data encryption and view Event data for these policies. Click here to learn more about this feature.
Ability to Remediate by Content Type in Slack: Nightfall now allows you to remediate Slack data based on content type. This feature allows you to enable delete file, and redact messages as two independent actions in a single Slack policy.
This section enlists the feature enhancements released by Nightfall in September 2024.
Ability to Search Within Google Drive Event Attributes: Nightfall now allows you to search Google Drive Events by using the values from Google Drive #event-detail-view. You can now search and filter Google Drive Events with Google Drive shared drive name, Link settings, Shared with internal users & groups, Shared with external users & Group, File owner, and Last edited by attributes. Click here to learn more about this feature.
Introduction of Events and Policies in Data Encryption (early preview): Nightfall has now introduced Events and policies in Data Encryption. You can now create policies in Data encryption and view Event data for these policies. Click here to learn more about this feature.
Sender, Recipient, and Domain Filtering in Email DLP: Nightfall now allows you to configure Email DLP policies to include or exclude specific senders, recipients, and domains for monitoring. Click here to learn more about this feature.
Support for Okta as an Identity provider (early preview): Nightfall now allows you to perform Directory Sync by using Okta as an Identity provider. Click here to learn more about this feature.
Slack User and User Group Filtering (early preview): Nightall now allows you to configure Slack policies by filtering specific users and user groups. Click here to learn more about this feature.
Detector for Philippines Tax ID Number (early preview): Nightfall has now introduced a detector that can detect the TIN (tax ID number) in Philippines. Click here to learn more about this feature.
Improvements to the PHI Detector: Nightfall has now enhanced the PHI detector. This enhancement ensures improved data output handlings, greater accuracy in file classification, greater model precisions, and validation of findings. Click here to learn more about this feature.
This section enlists the feature enhancements released by Nightfall in August 2024.
Detectors for Southeast Asian Countries: Nightfall has released new detectors which support sensitive data protection for southeast asian countries namely Cambodia, Indonesia, Philippines, Singapore, and Vietnam. Click #standard-pii-apac to learn more about the detectors.
Risk Scoring: Nightfall now allows you to rank violations in accordance to the risk associated with them. Click here to learn more about this feature.
New Vendor Specific API Key Detectors: Nightfall has launched vendor specific API key detectors for four vendors namely OPenAI, Pagerduty, Databricks, and, Hugging Face. Click here to learn more about the detectors.
Introduction of Exfiltration Prevention for Salesforce (early access): Nightfall now supports exfiltration prevention for Salesforce. Click here to learn more about this feature.
Enhanced Image ID Detectors: Nightfall has significantly enhanced the capabilities of image ID detectors. These enhancements reduce false positives and improve detector coverage. Click here to learn more about the detectors.
Unified Events Page: Nightfall has now unified all the events across all the products on a single page. Going forward, Violations would now be known as Events. Click here to learn more about the feature.
Ability to Exclude Applications from Google Drive Exfiltration: Nightfall now allows you to exclude applications from being monitored in Google Drive exfiltration policies. Click here to learn more about the feature.
Introduction of Lineage-Based Policies in macOS (early preview): Nightfall has now introduced endpoint lineage and lineage based policies for macOS. Click here to learn more about the feature.
This section enlists the feature enhancements released by Nightfall in July 2024.
Introduction of Data Exfiltration and Posture Management for Google Drive: The Google Drive integration is now equipped with exfiltration prevention and posture management capabilities. For more information, refer to this document for exfiltration prevention and this document for posture management.
IDP Integration with Corporate Directory Services: Nightfall now supports directory service in Microsoft Entra and Google Directory. Click here to learn more about this feature.
Introduction to Nightfall Data Encryption: Nightfall has now introduced data encryption for the Gmail integration. Click here to learn more about this feature.
Sensitive Data Protection to Emails: Nightfall can now scan your emails for sensitive data. This feature is currently available in Gmail. Click here to learn more about this feature.
Introduction of AI-powered Automated Labelling in Google Drive (early preview): Nightfall now allows you to use Labels in Google Drive policies. Click here to learn more about this feature.
Introduction of Role Based Access Control (RBAC): Nightfall now supports RBAC for better resource management. Click here to learn more about this feature.
Improved Navigation Bar: The Nightfall application's navigation bar is now enhanced for better user experience. You can view the latest navigation bar by logging in to Nightfall.
This section enlists the feature enhancements released by Nightfall in June 2024.
Sensitive Data Protection now available for OneDrive: Nightfall now supports sensitive data protection in Microsoft OneDrive for Business. Click here to learn more about this feature.
Sensitive Data Protection now available for Teams Chat: Nightfall now supports protection of sensitive data in Microsoft Teams for chat messages. Click here to learn more about this feature.
Bulk Remediation for Google Drive Violations: Nightfall now supports bulk remediation for violations reported in Google Drive. Click here to learn more about this feature.
Ability to Detect UK and Canadian Street Addresses: Nightfall has enhanced the Street_Address
detector to detect UK and Canadian street addresses. Click here to learn more about this detector.
Ability to Detect UK Phone Numbers: Nightfall has enhanced the Phone_number
detector to detect UK and Canadian street addresses. Click here to learn more about this detector.
Exfiltration Protection for macOS Devices (early access): Nightfall now supports exfiltration prevention in macOS devices.
This section enlists the feature enhancements released by Nightfall in May 2024.
Launch of Firewall for AI: The rebranded and retargeted version of Nightfall Developer platform is now available as Firewall for AI, which focuses on Generative AI model building. Click here to learn more about this feature.
Nightfall Data Exfiltration for Google Drive (early preview): Nightfall has launched exfiltration prevention platform. Google Drive is the first tool that is currently supported by Nightfall for exfiltration prevention. Click here to learn more about this feature.
Sensitive Data Protection for Gmail: Nightfall now provides security against sensitive data exposure through emails; specifically Gmail. Click here to learn more about this feature.
Ability to Include and Exclude Drives in Google Drive Policies: Nightfall now provides you the flexibility to include or exclude specific drives from being scanned. you can configure these settings while creating a Google Drive policy. Click here to learn more about this feature.
Updates to ID document Classifiers: Nightfall has now updated the detectors that pick up shared drivers licenses, passports, credit cards, and us social security cards. Click here to learn more about this detector.
This section enlists the feature enhancements released by Nightfall in April 2024.
Nightfall Sensitive Data Protection (early access): Nightfall sensitive data protection for emails is now available for early access. With this feature, you can protect sensitive data in your emails sent through Gmail. Click here to learn more about this feature.
In-product Announcements: Nightfall has now introduced in-product announcements. You can click the question mark icon a the bottom right of your screen from any Nightfall page and select the News option to view the latest announcements.
Support for directory Sync via Identity Providers (early preview): Nightfall now supports the Directory Sync feature. This feature is available in early access. With this feature, you can now import users and user groups via identity providers like Google Directory and Microsoft Entra ID. Click here to learn more about this feature.
This section enlists the feature enhancements released by Nightfall in March 2024.
Introduction to GitHub Deduplication feature: Nightfall has introduced the deduplication feature for GitHub integration. This feature automatically detects and prevents duplicate entries of GitHub violations on the Violations page. You can refer to this document to learn more about this feature.
This section enlists the feature enhancements released by Nightfall in February 2024.
Introduction of APIs to detect sensitive data: Nightfall has now introduced APIs to detect sensitive data in SaaS applications. You can use these APIs to You can use these APIs to fetch violations, search through violations, annotate findings, and so on. You can navigate to this link for API documentation for SaaS applications.
Introduction of the Independent ML Services: Nightfall now uses independent Machine Learning services to enable Real-Time File Scanning.
Enhanced Database Connection String Detector: The Database Connection string detector is now updated. This detector can now recognise URI-based, driver-based, and key-value pair based connection strings. Click here to learn more about this detector.
Enhancements to the Password Detector: The Password detector is now enhanced to recognise commonly used password placeholders in code. These placeholders are no longer identified as violations by the detector, thus reducing the false positive cases. Click here to learn more about this detector.
New "Ignore All" Option for Google Drive Violations: Nightfall now allows you to ignore all the current and future Violations arising out from a specific file in your Google Drive. Click here (refer to step 5) to learn more about this feature.
This section enlists the feature enhancements released by Nightfall in January 2024.
Improvements to the Person Names Detector: The Person Names detector is now enhanced to recognize synthetic names from Brazil, Portugal, Mexico, Argentina, Spain, and Colombia countries.
New Pending and Resolved Tabs in Violation Management: The Violations page now has two new tabs, Pending and Resolved. The Pending tab displays the list of Violations to be resolved and the Resolved tab displays the list of Resolved and Ignored Violations.
Improvements to the Street Address Detector: The street address detector is now enhanced to identify Spanish and Portuguese street addresses, resulting in enhanced address detection.
Improvements to the Password Detector: The Password detector is now updated to recognize and ignore commonly used development environment passwords, environment variables, and encrypted passwords.
New Ignore All Option for Google Drive Violations: Nightfall now allows you to ignore all the current and future Violations arising out from a specific file in your Google Drive.
Automatic Annotation and Auto Resolution of Findings: Nightfall now allows you to automatically annotate all the findings that are similar to a Finding. With this feature, if all the Findings of a Violation are false positive the Violation is automatically ignored.
Introduction of Custom Date Range Filters: Previously, you could filter historic Dashboard and Violation data using fixed time frames like Last 7 Days, Last 30 Days, and so on. Nightfall now allows you to set custom date range filters on the Dashboard and Violations pages.
Learn more about PCI compliance and how Nightfall helps with it.
Payment card industry (PCI) compliance is mandated by credit card companies to help ensure the security of credit card transactions in the payments industry. Payment card industry compliance refers to the technical and operational standards that businesses follow to secure and protect credit card data provided by cardholders and transmitted through card processing transactions.
Financial data, especially credit card numbers, pose an obvious DLP risk. Banks, financial institutions, and others concerned with protecting financial data typically use Nightfall’s payment card detectors.
Appendix 3.2.6 states the requirement for DLP applicable to ALL PCI-covered entities, making this the strongest case for Nightfall. As written:
Appendix 3.2.6 - Mechanisms are implemented for detecting and preventing clear text PAN from leaving the cardholder environment.
Note that PCI’s example given explicitly states DLP: “Mechanisms to detect and prevent unauthorized loss of cleartext PAN [credit card number] may include the use of appropriate tools such as data loss prevention (DLP) solutions as well as manual processes and procedures.”
The following PCI DSS sections further supported the need for a DLP:
3. Protect Stored account Data. specified that cardholder data must be protected at rest. Nightfall can identify when such data is being stored somewhere where unauthorized access has or may occur.
7. Restrict access to system components and cardholder data by business need to know. Same as above point. Nightfall can determine when need-to-know access might be violated.
10. Log and monitor all access to system components and cardholder data. Same as above, while Nightfall is not an access control, within certain integrations Nightfall can help determine who has had access to a specific piece of data.
12. Support information security with organizational policies and programs. Nightfall can help teams build enforceable information security policies.
Learn more about ISO 27001 and how Nightfall helps you with it.
The International Organization for Standardization (ISO) is a non-governmental organization that provides transnational standards across technology and engineering fields. ISO 27001 is a set of standards or ISMS (information security management system) to help orgs build out a coordinated and functional infosec program by assessing risk and identifying the types of controls critical to securing data in electronic systems.
There are currently two versions of ISO 27001
This version of ISO 27001 can no longer be used after October 31, 2025. It has limited data protection requirements that are outlined in a control supplement called ISO 27002.
These two requirements would be supported with Nightfall:
11.2.6: Security of Equipment & Assets Off-Premises
Framing: data is the asset, and the cloud / SaaS is considered off-premises
Security controls need to be applied to off-site assets, which essentially means protecting data (the asset) on the cloud (the off-site / third-party data center). ISO requires the same technical controls as if it were on-site, meaning that Nightfall supports these ISO control sections:
8.1.3 / 8.2.3: Acceptable use of information and systems - this is the appropriate handling (i.e., sharing / disclosure) of sensitive data, which is Nightfall’s main mission
12.4.1 - 12.4.3: Monitoring of sensitive data use
16.1.2 - 16.1.3: Information Security Event Reporting
18.2.2 - 18.2.3: Compliance with policies and standards for information security
13.2.1: Information Transfer Policies & Procedures
Communications must be secure, regardless of which system used. With Slack, Google Workspace, and other systems in development, Nightfall provides protection of comms over public internet to a variety of audiences, and is thus a control that supports this ISO requirement for confidentiality by taking into account the type, nature, amount and sensitivity or classification of the information being transferred.
Version 2022
This latest version of ISO 27001 will be required after October 31, 2025, and it adds the following new data protection requirements:
A.8.12: Data leakage prevention. A tool like Nightfall is now required if processing sensitive information, which is almost always the case. The requirement states that “data leakage prevention measures shall be applied to systems, networks, and any other devices that process, store or transmit sensitive information.”
In support of the above requirement, Nightfall also would be a control for:
A.8.10: Information deletion. Nightfall’s automated remediation such as deletion enabled this requirement, which states that “information stored on information systems, devices or in any other storage media shall be deleted when no longer required.”
A.8.11: Data masking. Nightfall’s data masking in protecting data is identified as a specific requirement. The requirement states “data masking shall be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.”
A.8.16 Monitoring activities: networks, systems and applications shall be monitored for anomalous behavior and appropriate action taken to evaluate potential information security incidents.
A.8.28: Secure coding. Nightfall’s protection of secrets and keys, none of which should ever be disclosed in development, supports this ISO requirement, which states that “secure coding principles shall be applied to software development.”
Learn more about Nightfall Cloud DLP from this brief document
Understand the reasons to choose Nightfall DLP.
Unlike traditional IT environments, cloud systems have no perimeter in the traditional sense. Historically, security revolved around keeping intruders out and hardening systems explicitly owned by an organization. However, the entire point of cloud adoption is to enable data to be wherever it needs to in order to be useful. As such, data itself is best thought of as part of your organization’s attack surface — the more data you have, the bigger your data exposure risk.
1. The cost of exposures tends to be higher in the cloud
Data is growing rapidly in the cloud and many organizations don’t have the best handle on the data proliferating within cloud silos. The end result is that basic policy violations have the potential to expose a massive amount of records. We discussed this very issue in an article published in ITProPortal. In that post, we revealed that just five cloud data leaks in 2020 exposed nearly 27 billion records. The data was derived from our 16 year breach report published earlier in 2021. In the report, we illustrated that misconfigurations in cloud systems, especially those like AWS S3 and Elasticsearch, can result in disproportionately higher numbers of exposures because of the volumes of data stored in these systems.
SaaS systems aren’t exempt from this risk either. Systems like GitHub can contain secrets that can be used to access other systems and collaborative tools like Google Drive, Jira, and Confluence may have files that are exposed publicly due to permissions misconfigurations. The commonality with all cloud exposures is that they can go on indefinitely until an organization is notified by an altruistic third party, or until they acquire the tools that let them see any data exposures.
2. Security and IT teams are stretched thin
It’s no secret that the cybersecurity industry is currently undergoing a skills shortage and that, at the same time, the costs of breaches are rising. This leaves security professionals in the hard spot of triaging risk, possibly leaving gaps in some organizations’ security programs. Having a solution that can intelligently automate security tasks and only alert on events that are critical.
3. It’s very difficult to consistently enforce proper data policies in the cloud
One of the key problems organizations face regarding security and compliance is ensuring that employees are aware of best practices and verifying that they’re following these guidelines. Without sufficient visibility into cloud systems, this can be very difficult to do for the reasons we’ve highlighted above.
4. The cloud shared responsibility model requires it
The shared responsibility model, best articulated by AWS, requires organizations to understand their risks and have the ability needed to address them. Organizations should begin this work by identifying and mapping critical cloud security areas to processes and solutions that are relevant. Ty Sbano, Sisense’s Chief Security & Trust Officer, briefly illustrates how resources like CIS’s representation of the shared security model could be used to help with this process in the segment below.
Nightfall Documentation landing page
Welcome to Nightfall Documentation. A one-stop shop for all your queries about the Nightfall DLP product.
A comparison between Cloud-native DLP and CASB
A common misconception is that Cloud Access Security Brokers (CASBs) can accomplish the same level of DLP protection as cloud-native DLP solutions. CASBs are deployed as proxies and sit between the network layer and the cloud application layer allowing them to inspect traffic traveling between your network and designated cloud environments. The limitations of CASBs stem primarily from the fact that they can only inspect network traffic, and do not natively integrate with cloud applications or infrastructure.
A summary of differences between Nightfall’s Cloud DLP and CASBs is shown below.
Learn how Nightfall AI-powered data leak prevention (DLP) for SaaS and Cloud can help organizations maintain compliance with various global compliance frameworks across different industries.
This article discusses how Nightfall, the AI-powered data leak prevention (DLP) platform for SaaS and cloud, can help organizations maintain compliance with various global compliance frameworks across different industries. It provides an overview of Nightfall detection and its pre-built detectors. It then delves into specific compliance frameworks such as GDPR, CCPA, HIPAA, HITRUST, PCI, GLBA/FCRA, SOX, ISO 27001, FERPA, CMMC, and FedRAMP/NIST 800-53, and explains how Nightfall can help organizations comply with the specific requirements of each framework. The article also includes links to additional resources for each compliance framework.
Please note that while these specific frameworks and controls may be relevant to DLP, it is essential to consult the full text of these frameworks and any applicable regulations or guidelines to ensure comprehensive compliance with the law. The information presented here should not be considered legal advice or a confirmation of compliance with any specific laws or regulations. Legal advice specific to your situation is recommended to understand the complete obligations and requirements of these frameworks.
Nightfall comes with many pre-built detectors out of the box. You also have the ability to add custom detectors, rules, keywords, and regexes. To explore our pre-built detectors, visit our .
The General Data Protection Regulation (GDPR) operates under the principle of data protection by design and by default. This requires organizations to implement appropriate technical and organizational measures to ensure the protection of personal data. Specifically, Data Leak Prevention (DLP) solutions can be used to detect and prevent unauthorized transmission or storage of personal data, such as names, addresses, and personal identification numbers.
The specific controls are:
Article 32: Security of processing, which requires organizations to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. Nightfall is a control to protect personal data from unauthorized access, alteration, destruction, or accidental loss.
Article 5(1)(f): Data minimization, which requires organizations to limit the collection and retention of personal data to what is necessary for the specific purposes for which it is processed. Nightfall’s realtime monitoring can help organizations to identify and prevent the retention of unnecessary personal data.
Article 33: Notification of a personal data breach to the supervisory authority, which requires organizations to report personal data breaches to the appropriate supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Nightfall’s realtime monitoring enables organizations to detect and respond to personal data breaches in a timely manner.
Article 35: Data protection impact assessment (DPIA), which requires organizations to carry out a DPIA when the processing is likely to result in a high risk to the rights and freedoms of natural persons. Nightfall helps organizations to identify and mitigate risks to personal data by detecting and preventing data breaches.
The California Consumer Privacy Act (CCPA), much like GDPR, requires protecting personal information via reasonable security measures like DLP. Nightfall is a control to detect and prevent the unauthorized transmission or storage of personal information, such as names, addresses, and personal identification numbers.
These specific CCPA sections and controls supported by Nightfall are:
Section 1798.81.5 of CCPA requires businesses to implement and maintain reasonable security procedures and practices appropriate to the nature of the information to protect personal information from unauthorized access, destruction, use, modification, or disclosure. Nightfall is a control to protect personal data from unauthorized access, alteration, destruction, or accidental loss.
Sections 1798.82 and 1798.83 of CCPA requires businesses to disclose to the California attorney general and California residents of any breach of the security of the system data, including a description of the categories and specific pieces of personal information that were or are reasonably believed to have been the subject of a breach. Nightfall helps organizations to identify and mitigate risks to personal data by detecting and preventing data breaches.
Section 1798.125 of CCPA requires businesses to provide certain rights to California residents regarding their personal information, such as the right to know what personal information is being collected, the right to request deletion of personal information, and the right to opt-out of the sale of personal information. Nightfall helps organizations to identify and control the collection and sharing of personal information.
The Lei Geral de Proteção de Dados (LGPD) is the Brazilian data protection law that regulates the processing of personal data. Here are some specific controls and section numbers of the LGPD that are relevant to data leak prevention (DLP) for SaaS:
Article 46: This article establishes that the data controller is responsible for adopting security measures to protect personal data against unauthorized access, accidental or unlawful destruction, loss, alteration, communication, or any form of improper or unlawful processing. Nightfall is a control to protect personal data from unauthorized access, alteration, destruction, or accidental loss.
Article 47: This article states that the data controller must adopt administrative, technical, and security measures to protect personal data, considering the nature, scope, context, and purposes of the processing, as well as the risks and rights involved. Nightfall is a technical security measure for protecting personal data.
Article 48-A: This article, introduced by Provisional Measure No. 869/2018, requires the data controller to carry out a Data Protection Impact Assessment (DPIA) for processing operations that may present risks to individuals' rights and freedoms. Nightfall can conduct historical scans that identify sensitive data like PII across SaaS applications.
Article 48-B: Also introduced by Provisional Measure No. 869/2018, this article establishes that the data controller must adopt mechanisms for auditing and demonstrating compliance with data protection regulations. Nightfall can conduct historical scans that provide reports on sensitive data exposure across SaaS applications.
Article 48-C: This article, introduced by Provisional Measure No. 869/2018, requires the data controller to implement administrative and technical measures to protect personal data, including measures aimed at preventing unauthorized access, accidental or unlawful destruction, loss, alteration, communication, or any form of improper or unlawful processing. Nightfall is a technical measure to protect sensitive data and can prevent accidental exposure or access through real-time monitoring and remediation.
In the context of the Personal Information Protection and Electronic Documents Act (PIPEDA) in Canada, there are several specific controls that relate to data leak prevention. Here are some of the controls and how they map to data leak prevention:
Safeguards Principle (Section 4.7): This principle requires organizations to protect personal information against unauthorized access, disclosure, copying, use, or modification. Implementing technical and organizational measures to prevent data leaks, such as encryption, access controls, and network security, helps ensure compliance with this principle. Nightfall is a technical measure that prevents data leaks and exposure through real-time monitoring and remediation.
Security Safeguards (Section 4.7.1): This control specifies that organizations must protect personal information using safeguards appropriate to the sensitivity of the information. It includes physical, technological, and organizational security measures to prevent data leaks, such as secure storage, firewalls, intrusion detection systems, and employee training. Nightfall can remediate sensitive data through different means whether that mean training an employee, redacting it, or deleting it, depending on the sensitivity of the information.
Access Controls (Section 4.7.3): Organizations need to establish controls to limit access to personal information on a need-to-know basis. By implementing user authentication mechanisms, role-based access controls, and strong password policies, organizations can prevent unauthorized access and data leaks. Nightfall monitors a SaaS environment in real-time so that sensitive data is not exposed in areas that it should not be in and thus contained on a need-to-know basis.
Training and Awareness (Section 4.7.4): This control emphasizes the importance of educating employees about privacy policies, procedures, and best practices to prevent data leaks. Training programs should cover topics like handling sensitive information, recognizing phishing attacks, and secure data disposal. Nightfall can notify end-users and employees that transmit sensitive data so that coaching is relevant and done in real-time to promote best practices.
Incident Response (Section 4.7.5): Organizations must have procedures in place to respond to and mitigate privacy breaches. This control includes developing an incident response plan, promptly investigating and addressing breaches, and notifying affected individuals and the appropriate authorities. Nightfall can scan a SaaS environment for sensitive data to determine if data was exposed.
Monitoring and Auditing (Section 4.7.6): Regular monitoring and auditing of security controls help identify and address vulnerabilities that could lead to data leaks. This control involves conducting security assessments, penetration testing, log analysis, and reviewing access logs to detect and prevent unauthorized access or data breaches. Nightfall can conduct a risk assessment to scan a SaaS environment and understand the nature of sensitive data exposure in the environment.
Disposal and Destruction (Section 4.7.8): Proper disposal of personal information is crucial to prevent unauthorized access and data leaks. Organizations should have policies and procedures for securely destroying or anonymizing personal data when it is no longer required. Nightfall remediation capabilities including actions like deleting and redacting sensitive data in real-time.
Data protection is intimated but not explicitly required for HIPAA compliance. It is intimated in the following ways:
The Security Rule requires organizations to use appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity, and security of sensitive information.
Nightfall provides:
Administrative safeguards through highly contextualized end-user security awareness and training.
Technical safeguards by detecting and preventing clear-text personally identifiable information (PI) / protected health information (PHI) from leaving the environment, as well as automated corrective actions that lock down sharing or disallow download and print. Additionally, Nightfall supports the Audit Control standard by maintaining logs of PHI record creation or dissemination on the systems it monitors.
Nightfall does not cover the other two rules, namely the Privacy Rule and the Breach Notification Rule. These rules are outside of Nightfall's domain as they respectively govern a patient's access to their records and the processes for managing breaches.
Data Protection & Privacy:
Where possible and technologically feasible, the organization locates and removes/redacts specific PII or uses anonymization and de-identification techniques to allow the use of retained information while reducing its sensitivity and the risk from disclosure. Nightfall's automated remediation actions, such as deletion and redaction, support this control and serve as an overall risk mitigation for data disclosure.
The organization protects important records, such as contracts, personnel records, financial information, and client/customer information from loss, destruction, and falsification through the implementation of security controls. These controls include access controls, encryption, backups, electronic signatures, locked facilities or containers, among others. Nightfall's real-time monitoring enables organizations to detect and respond to sensitive data loss.
Transmission Protection:
Before allowing the use of information systems for information exchange, the organization formally addresses multiple safeguards.
The organization never sends sensitive information without encryption using end-user messaging technologies (e.g. email, instant messaging, and chat). Nightfall can monitor SaaS applications that are not approved to confirm that PHI is not transmitted.
Education, Training & Awareness:
Personnel are appropriately trained on leading principles and practices for all types of information exchange (oral, paper and electronic). Nightfall can assist teams in building enforceable information security policies and provide end-user security awareness and training that is highly contextualized.
PCI stands for Payment Card Industry, and it refers to a set of security standards and regulations designed to protect the sensitive cardholder data during payment card transactions. It ensures that businesses that handle payment card information maintain a secure environment to prevent data breaches and protect customer information. PCI is divided into 12 major sections, with several appendices, and 5 of 12 PCI controls are supported by Nightfall.
Of the five sections, Appendix 3.2.6 is the section that most clearly states the requirement for DLP for all PCI-covered entities. As written:
Appendix 3.2.6 - Mechanisms are implemented for detecting and preventing cleartext PAN from leaving the cardholder environment.
Note that PCI’s example given explicitly states DLP: “Mechanisms to detect and prevent unauthorized loss of cleartext PAN [credit card number] may include the use of appropriate tools such as data loss prevention (DLP) solutions as well as manual processes and procedures.”
The following four PCI DSS sections are also relevant to DLP controls:
Section 3: Protect Stored Account Data specifies that cardholder data must be protected while at rest. Additionally, the requirements state that methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if the full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies such as email and instant messaging. Nightfall specifically covers these messaging technologies and can identify when such data is being stored somewhere where unauthorized access has occurred or may occur.
Section 7. Restrict access to system components and cardholder data by business need to know: This point is the same as the one above. Nightfall can determine when need-to-know access might be violated.
Section 10. Log and monitor all access to system components and cardholder data: While Nightfall is not an access control, it can help determine which users have had access to specific pieces of data within certain integrations.
Section 12. Support information security with organizational policies and programs - Nightfall can help teams build enforceable information security policies. Additionally, it provides end-user security awareness and training that is highly contextualized.
No changes regarding DLP or additional requirements from prior version 3.2.1.
Accounts numbers
Credit card numbers
Social Security numbers
These regulations are broad in nature and do not include specific enumerated requirements like PCI. However, they are explicit about not exposing customer records and impose fines for infractions (up to $100K per violation). Nightfall can be used as a compliance control to detect and prevent clear-text personally identifiable, payment, or account information from transmission. It also provides automated corrective actions that can lock down sharing or disallow downloading and printing.
Sarbanes-Oxley (SOX) is a financial reporting regulation that applies to publicly traded companies. It was created in response to the Enron collapse, which was caused by creative accounting of financial results. SOX focuses on the principles of integrity, accuracy, and completeness, and requires publicly traded companies to maintain confidentiality of their financial results before reporting.
Nightfall supports specific SOX requirements by detecting and preventing the movement of financial and accounting information in and out of the organization. It also provides automated corrective actions that restrict sharing and prevent downloading and printing.
Section 302 of SOX requires the CEO and CFO to certify the accuracy of the financial statements. This certification requires a control to mitigate unauthorized access, alteration, or sharing of financial data.
Section 404 of SOX requires internal controls that focus on access, confidentiality of financial records, and their testing by management. Data leak prevention (DLP) solutions can be a part of those internal controls to protect sensitive financial data.
This version is the only currently accepted version of SOC 2 by AICPA.
For the SOC 2 sections specified, Nightfall supports these requirements through its monitoring, notification, and automated remediation:
Confidentiality CC6.7: The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives. This requirement specifically mentions data loss protection. Nightfall meets the standard to restrict the transmission and movement of data.
Confidentiality CC6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives. Nightfall protects the following SOC 2 specifically identified sensitive data:
Confidential information assets such as personal information.
Encryption keys during use, storage, and transmission.
Confidentiality CC6.6: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. Nightfall provides coverage of the cloud and protects against personal devices (BYOD) that may be outside the system boundaries, making it a Boundary Protection System. Nightfall also addresses a specific SOC 2 concern by protecting identification and authentication credentials outside of the system boundaries.
Confidentiality CC2.2: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. Nightfall's automated responses to end users provide real-time security awareness training that is highly contextualized to the specific violation identified.
This version of ISO 27001 will no longer be valid after October 31, 2025. It includes limited data protection requirements that are detailed in a control supplement called ISO 27002. Two of these requirements can be supported with Nightfall:
11.2.6: Security of Equipment & Assets Off-Premises
Context: In the context of this section, data is considered the asset, and the cloud / SaaS is considered off-premises.
Security controls must be applied to off-site assets, which means protecting data (the asset) on the cloud (the off-site / third-party data center). ISO requires the same technical controls as if it were on-site. Nightfall supports the following ISO control sections:
8.1.3 / 8.2.3: Acceptable use of information and systems - this refers to the appropriate handling (i.e., sharing / disclosure) of sensitive data, which is a prime directive of Nightfall.
12.4.1 - 12.4.3: Monitoring of sensitive data use.
16.1.2 - 16.1.3: Information Security Event Reporting.
18.2.2 - 18.2.3: Compliance with policies and standards for information security.
13.2.1: Information Transfer Policies & Procedures
Communications must be secure regardless of the system used. Nightfall provides protection for communications over the public internet to various audiences, including Slack, Google Workspace, Jira, Confluence, and other systems. Thus, it is a control that supports the ISO requirement for confidentiality by taking into account the type, nature, amount, and sensitivity or classification of the information being transferred.
The latest version of ISO 27001 will be required after October 31, 2025. It includes the following new data protection requirements:
A.8.12: Data leakage prevention. The requirement states that “data leakage prevention measures shall be applied to systems, networks, and any other devices that process, store or transmit sensitive information.” Therefore, it is recommended to use a tool like Nightfall when processing sensitive information, which is almost always the case.
In support of the above requirement, Nightfall also serves as a control for:
A.8.10: Information deletion. Nightfall's automated deletion enables this requirement, which states that "information stored on information systems, devices, or in any other storage media shall be deleted when no longer required."
A.8.11: Data masking. Nightfall's data masking in protecting data is identified as a specific requirement. The requirement states that "data masking shall be used in accordance with the organization's topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration."
A.8.16: Monitoring activities. Nightfall is a monitoring control that fits within this requirement, which states that "networks, systems, and applications shall be monitored for anomalous behavior, and appropriate action taken to evaluate potential information security incidents."
A.8.28: Secure coding. Nightfall's protection of secrets and keys, none of which should ever be disclosed in development, supports this ISO requirement. The requirement states that "secure coding principles shall be applied to software development."
The Family Educational Rights and Privacy Act (FERPA) directs educational organizations to keep student school records private and confidential. Nightfall can be used to detect and prevent the unauthorized transmission or storage of student education records, such as student names, addresses, grades, transcripts, and other personal information.
While FERPA does not specify control numbers, it does require educational institutions to:
Ensure that administrative and technical controls are in place to protect student education records from unauthorized access, disclosure, alteration, or destruction. Nightfall is one such control as it protects personal data from unauthorized access, alteration, destruction, or accidental loss.
Limit access to student education records to school officials who have a legitimate educational interest in the records. Nightfall can detect and prevent unauthorized access.
Keep a record of all individuals who have requested or obtained access to student education records, along with the legitimate educational interest that each person has in obtaining the records. Nightfall can assist educational institutions in maintaining these records and detecting any unauthorized access to student education records.
The Cybersecurity Maturity Model Certification (CMMC) is a framework developed by the Department of Defense (DoD) to protect unclassified information. CMMC's scope is the Defense Industrial Base (DIB), which includes all organizations that support the DoD. This is defined as any organization that enables research and development, design, production, delivery, and maintenance of military weapons systems, subsystems, and components or parts to meet U.S. military requirements. In short, any system or component used by the DoD is covered by CMMC.
As of May 2023, version 2.0 is required. CMMC measures maturity and ranks it by levels.
3.1.3: Control CUI Flow: Control the flow of CUI in accordance with approved authorizations. Nightfall supports this requirement by monitoring alerts and implementing automated remediations to maintain compliance with authorized CUI sharing on cloud systems.
3.8.5 Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. Nightfall supports protecting digital CUI. It applies mechanisms to prevent unauthorized loss or access to CUI via monitoring alerts and automated remediations such as access removal.
3.13.16 – Data at Rest: Protect the confidentiality of Controlled Unclassified Information (CUI) at rest. Nightfall’s automated remediation can help maintain confidentiality.
Note that Level 3 requirements have not yet been written. However, an additional requirement is currently under consideration.
3.1.3e - Employ secure information transfer solutions to control information flows between security domains on connected systems. This requirement calls for the use of secure information transfer solutions to control information flows between security domains on connected systems. Using Data Leak Prevention (DLP) to protect confidential data would satisfy this requirement. Therefore, Nightfall would help meet this requirement.
NIST 800-53, which forms the basis for FedRAMP, is considered one of the less robust data protection security frameworks because it has fewer controls overall. Nightfall supports two major sections of the NIST CSF.
Information Flow:
AC-4: Information Flow Enforcement - The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on organization-defined information flow control policies. Nightfall enables this control through its policies and automated remediations.
Media Protection (note that the CSF definition of media includes laptops / mobile devices):
MP-6 - Employs sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information. Nightfall's automated remediations, such as redaction, support this control.
MP-7 - The organization restricts/prohibits the use of system media (in Nightfall's case, cloud systems/storage). Nightfall's automated sharing changes (e.g., Google Drive) support this control.
Learn how Nightfall benefits your organization
Nightfall has several key benefits, including:
Reductions in both the cost and occurrence of data breaches. Nightfall limits the exposure of things like credentials and secrets, which are a common cause of data breaches. Nightfall also limits the exposure of PII and other business critical content, which means that if a breach does occur, its impact is minimized
Nightfall generates time savings by helping automate the task of discovering, classifying, and appropriately remediating sensitive and business-critical data.
To learn more, see our ROI calculator:
Learn how to ensure HIPAA compliance in your collaborative cloud applications
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal law protecting the disclosure of individuals' health information (aka protected health information or PHI).
Nightfall's PHI detector identifies PHI with high accuracy and relevancy using 15 PII and healthcare entity detectors combined, as described in Tables 1 & 2.
Table 1: Nightfall PHI detector = Nightfall PII + Healthcare detectors in specfic combinations
Please refer to the for more information on the individual detectors above.
Table 2: Nightfall PHI detection confidence
Learn about various factors to be considered while choosing a Nightfall detector.
One of the first things you’ll do to get started with Nightfall is to choose which detectors you want to use. Ultimately, you will organize your chosen Detectors into in order to apply them to your cloud applications and infrastructure - but beforehand, we recommend that you carefully assess your needs and goals for sensitive data detection. Below, we suggest a few questions to ask yourself as you determine which detectors to leverage.
What data do you want to detect?
As discussed above, there is always a tradeoff between sensitivity and specificity. You want to plan your Detection Rules carefully to strike the right balance of accuracy without too much noise. The main question to ask yourself at this stage is what data you want to look for.
Do you have a specific concern around a particular type of data (e.g. from a previous DLP issue)? In this case, you may be able to target a limited set of detectors.
Do you want to implement a very broad DLP process, and don’t have a sense of which data might be problematic? Doing so will require more detectors, and thus means you may find a higher number of violations and/or noise.
Try to limit your detectors to data that you know or suspect are tracked or shared at your organization. For example, if you never discuss or store Vehicle Identification Numbers, then you likely do not need to set up a detector for that type of data.
How severe are the consequences of data leakage?
Some detectors will give more false positives due to their nature (e.g. widely occurring data types such as Dates, or less structured data types such as Names). In order to avoid excessive noise, you should weigh the relative risk of data exposure. For example, it may be problematic for your organization to leak Credit Card Numbers, but not Dates.
How much does the data’s context matter?
Another way to eliminate noise is to create specific Detection Rules that scan for combinations of data types. For example, it may be problematic for your organization to have Dates appearing alongside Names, but not for Dates to appear alone.
An introduction to the Nightfall Detection Platform.
Nightfall detection platform looks for sensitive data. When sensitive data is detected, a notification or automated remediation action is initiated. The detection platform consists of three components; Detectors, Detection Rules, and Policies.
A Detector is an entity that can detect the presence of sensitive data in publicly exposed entities. You can either use the default detectors provided by Nightfall or create your custom detectors.
A Detection rule is a group of detectors. Once you create your detectors or finalise the Nightfall detectors you wish to use, you can add them to a detection rule. You can customize the degree of weightage for each detector in a detection rule.
Once you finalize the creation of detection rules, you can add them to policies. A Policy consists of multiple detection rules. When a detector in any of the detection rules detects sensitive data, the Policy can trigger auto notifications to be sent to specific users, initiate automated remediation measures, and allow end-users to take remediation actions.
So, a Detector or a Detection rule do not have the ability to trigger alerts or take remediation steps by themselves, you need to add them to a policy.
The following diagram shows how you can leverage the three entities of the Nightfall Detection platform.
Learn how to onboard and start using the Nightfall AI platform.
Nightfall is a SaaS-based cloud application. This document explains how you can sign up for a Nightfall account and start using the Nightfall application.
To sign up for Nightfall:
Navigate to .
Click Sign up.
Provide the required details and click Continue.
(Optional) Enter the additional details.
Click Create account.
The following verification screen is displayed. Check your Email. You should have received a new Email from support@nightfall.ai. Click the verification link in the Email to verify your account.
Click Continue to login to navigate to the login screen. You can log in to Nightfall only after verifing your Email.
The blank Nightfall Dashboard page is displayed as follows.
The Nightfall SaaS app provides you with numerous integrations to connect to various third-party applications in which your data resides. You can connect to the integration in which your organization's data resides and then start scanning your data with Nightfall to detect sensitive information.
By default, none of the integrations are active. You must contact Nightfall to subscribe to a paid plan and activate the required integration.
If an integration is not available for your desired application, you can subscribe to the Nightfall Firewall for AI. The Firewall for AI's APIs and SDKs help you integrate even those applications for which integration is not available in the Nightfall app.
IMPORTANT
Learn about Nightfall detectors.
A Detector is a tool that scans any online entity to detect if any sensitive data is present in the entity. An "entity" can refer to any resource on the Internet like a file in Google Drive, ticket data in JIRA, code snippets in GitHub, customer data in Salesforce, and so on.
There are two types of detectors; Nightfall Detectors and Custom Detectors.
Nightfall provides core machine learning-powered detectors known as Nightfall detectors. All the detectors provided by Nightfall, are provided out-of-the-box and are present in your Nightfall environment by default. You can navigate to the Detectors section in the left menu and select the BUILT BY NIGHTFALL option to view all the Detectors provided by Nightfall.
Each Nightfall detector is designed to identify a specific type of sensitive data. For instance, The Email detector can identify Email IDs. You can use this detector to check if any Email IDs from your organization are being leaked out on the Internet.
Similarly, there are detectors to detect personally identifiable information (PII) from various countries. The PII of each country is unique. For instance, French passport numbers have a different format as compared to German passport numbers. So, if you are a French company that wishes to detect if any of the French passport numbers of your employees or customers are leaked or are prone to be leaked, you can use the France Passport detector. Similarly, German companies can use the Germany Passport detector.
The detectors are classified in terms of the sensitive data that they protect. The various categories under which Nightfall detectors are classified are as follows.
Common Entities: This category consists of detectors that uniquely identify a person. The detectors in this category are Name, Email, Address, and Phone number.
Content Moderation: This category consists of detectors that can identify harmful data in images. The detectors in this category are Violent or Disturbing Image detector which can detect violent content from images and Sexually Explicit Image detector which can identify sexual activity in images.
Documents: This category consists of detectors that can identify sensitive data in images. Some of the detectors in this category are Credit Card image detector which can detect credit card numbers from images and Passport or Visa Image detector which can detect passport numbers or visa numbers from images.
Finance - Banking: This category consists of detectors that can identify sensitive data related to the financial industry. Some of the detectors in this category are Canada Bank Account Number detector which can detect bank account numbers from Canada and the IBAN code detector which can detect the IBAN codes.
Financed - PCI: This category consists of detectors that can identify sensitive data related to payment cards. Credit card numbers is one such detector that falls under this category and identifies the credit card numbers of customers.
Network/Hardware: This category consists of detectors that can identify sensitive data related to hardware and networking. The IP address detector in this category can identify IP addresses.
Healthcare: This category consists of detectors that can identify sensitive data related to the healthcare industry. The Protected Health Information (PHI) detector can identify data that can uniquely recognize a person.
Personally Identifiable Information (PII) - Americas: This category consists of detectors that can identify sensitive data that can uniquely identify citizens from various countries of the American continent. Some of the detectors in this category are the Canada Driver License Number detector which can identify driving license numbers issued to Canadian citizens and residents, US Driver license detector which which can identify driving license numbers issued to US citizens and residents.
Personally Identifiable Information (PII) - EMEA/AP: This category consists of detectors that can identify sensitive data that can uniquely identify citizens from various countries in Europe and Asia Pacific. The Indian Aadhar Card number detector is a part of this category that can identify the Aadhar numbers of Indian citizens.
Secrets: This category consists of detectors that can identify user's sensitive data. The API key detector can identify live API keys exposed to the Internet.
To view the detectors of a specific category, click the category name. All the Nightfall detectors' category names are highlighted in the above image.
Organizational compliance is one of the leading drivers that require DLP tooling such as Nightfall. These are the recommended configurations for each compliance framework.
Other detectors that exist are not recommended for use for the above compliance frameworks. For all use cases, Nightfall further recommends:
Tune and amend Minimum Confidence over time in accordance with your violations and data set
Scoping should cover all locations where the sensitive data should not be disclosed
Using Exclusion Rules to reduce false positives and fine-tune alerts
Reporting false positives for machine learning training to support@nightfall.ai
Learn more about SOC 2 compliance and how Nightfall helps with it.
Many companies seek to become SOC 2 compliant to showcase their strong security practices for safeguarding their company’s and their customer’s data.
During SOC 2 compliance audit periods, auditors review that security controls are in place, triggered, and responded to appropriately to assess the strength of an organization’s security posture. Auditors generally look for a number of controls, including the following:
Information security practices that are documented & managed on an ongoing basis
Data classification policies and protocols that detail the security and handling of customer data
Nightfall’s Customer Success team specializes in helping you leverage the platform to meet your compliance needs successfully.
Configure detection rules that detect sensitive data your business handles. Select from common templates in our library for out of the box coverage.
Enable real-time monitoring on business applications that house sensitive data such as Slack, Google Drive, Confluence, Jira, and GitHub.
Implement manual or automated workflows and processes to remediate any findings.
Run historical scans to search for sensitive data that exists in data silos today.
Visualize historical scan results in a custom Nightfall dashboard.
Engage Nightfall’s Managed Services team to facilitate bulk remediation of sensitive data at rest in cloud silos.
Review and export scan results should they be required in the event of an audit.
The following table lists security practices and policies that companies should implement for a strong security posture. A data classification & protection platform like Nightfall can help companies enforce and manage these controls.
(Health Information Trust) is a proprietary cybersecurity framework primarily used by mature healthcare organizations to demonstrate leading security practices. Data protection is explicitly mentioned in multiple sections of the framework.
The Gramm-Leach-Bliley Act mandates that financial institutions safeguard consumers' personal financial information. Meanwhile, a smaller subset of financial institutions known as must maintain consumers' right to privacy when preparing consumer reports (also known as credit reports) on individuals, as required by the Fair Credit Reporting Act (FCRA). In both cases, the following data points must be protected if they identify an individual:
If an organization is at Level 2, it must adhere to all requirements outlined in . Note that in CMMC terminology, CUI stands for Controlled Unclassified Information. Nightfall provides support for these requirements.
Irrespective of whether you wish to use the Nightfall SaaS app or the Nightfall Firewall for AI, you must have a fair understanding of the (Detectors, Detection rules, and Policies).
For the complete list of all the detectors present in all the categories, you can view the document.
Now that you are aware of all the available detectors, you can choose to use any of the existing Nightfall detectors or create your detector specific to your organization's requirements. If you are not sure of which Nightfall detector to use, view the document.
If Nightfal detectors can address your organization's requirements and you do not wish to create any custom detectors, you can refer to the document, to learn about how to add detectors to a detection rule.
If Nightfall detectors cannot address your organization's requirements, you can create your own detector(s) or customize a Nightfall detector. You can refer to the document to learn about custom detectors.
November 2023
Delayed Remediation
Policy Level Alert Configuration
New Nightfall for MS Teams Integration
New Data Scanned Widget
End-users are now capable of taking remediation measures for data leak incidents caused by them.
Nightfall now allows you to delay automated remediation.
You can now configure alerts at the policy level as well.
You can now deploy Nightfall to prevent data leaks from MS Teams.
The new Data Scanned widget on the Nightfall widget displays the total data scanned by Nightfall. You can also view this data scanned for each integration.
October 2023
1. Nightfall for Notion
2. Bulk Actions
3. Nightfall for GitHub - Comments in pull requests
You can now deploy Nightfall to prevent data leaks from Notion.
Nightfall now allows you to perform an action on more than 50 violations simultaneously.
Nightfall now allows you to tag developers in pull request comments within GitHub. This enhancement requires additional permissions in the Nightfall app for GitHub. The new permissions required are:
Read access to code, commit statuses, and metadata
Read and write access to issues and pull requests
September 2023
Nightfall for Microsoft Teams
You can now deploy Nightfall to prevent data leaks from Microsoft Teams within your organization.
August 2023
Policies Workflow
Policies workflow is standardised for all Integrations.
August 2023
Nightfall for ChatGPT
You can deploy Nightfall to scan prompts in ChatGPT.
July 2023
Automated actions for Send to Jira
Violations UI updates
You can now configure Send to Jira as an automated action. Once set up, a violation is automatically forwarded to Jira as a ticket. Currently, you can send a violation to Jira manually. This functionality is pre-installed for Jira DLP customers with no additional app or connector to install. If you are not a Jira DLP user, you must first connect Nightfall to Jira.
Improved tabular view where rows of violations are visually scannable, while retaining information density.
A slide out content preview panel with much improved and scalable content architecture for features and experiences to come.
The addition of Policies and Detection Rules to the content preview
Content preview now offers,
May 2023
Annotating Findings
You can now act on a finding instantly from within the Violation dashboard. This will save you time on eliminating False positive and gaining attention to serious violations.
April 2023
Send to Jira. Applies to all integrations.
You can now send a violation to Jira as a ticket for easier tracking and resolution.
Note:
If you have Jira implemented, this feature already exists.
If you do not have Jira, you must install Jira to be able to use this functionality.
To send a violation to Jira,
Select the Finding on Violation console. The violation preview displays.
Click the ellipsis on the right end of the finding. A set of task options display in the menu.
Select Send to Jira. A Create Ticket in Jira pop up displays.
Select the Project.
Select the Issue Type.
Enter a name for the issue.
Enter any comments if required.
Click Send to Jira. The violation finding is now converted to a Jira ticket. The ticket can be assigned to user to resolve the issue from within Jira.
February 2023
Integration: Salesforce Service Cloud
Enhancement: Salesforce Support for platform events
Integration: Zendesk
Nightfall DLP for Salesforce now supports Salesforce Service Cloud. You can scan all the 8 standard objects and all associated standard, custom fields within the objects in Service Cloud using the same Nightfall package that supports Sales Cloud.
Nightfall DLP for Salesforce now supports platform events that utilize apex triggers to push updates to platform events Nightfall reads the updates from platform events and minimizes any impact of apex trigger limits to the Salesforce org.
Nightfall also creates triggers only for those objects, and fields that are defined in a policy instead of enabling trigger on all objects and fields.
Real-time scanning for Zendesk tickets is now available. Nightfall can:
. scan all tickets in real-time within a Zendesk instance.
. enable easy onboard and setup.
. support multiple instances.
. send slack, Email, and Webhook Alerts
January 2023
Enhancement: Advanced Secrets Detection
Detector: HIPAA PHI
Detector: File Detector- Based Exclusions
Redaction: Confluence
The Advanced Secrets Detection improves the accuracy of the existing API key detector and extends it to identify keys from top SaaS and Cloud vendors and determines if a vendor key is an active risk. Advanced API key detector performs using two models:
. Vendor-specific API key model - detects secrets from the top 25 SaaS and Cloud services. Nightfall labels the secret findings by vendor and service type and determines with the secret if it is an active risk.
. General API key model - an ML-based model encompassing the complete range of secrets types and forms. The model includes regex candidate scanning, a ML-based token model, and an ML-based context model.
Nightfall HIPAA Detector uses Artificial Intelligence (AI) to accurately identify the exposure of patient data with maximum accuracy and relevance. It uses 15 dimensions of patient data (like person name, Date of Birth, Social Security Number, address, diagnosis, medications, etc.) in concert.
You can now bulk ignore noise generated by known file sources, file types or any finding that matches an entry in a file-based dictionary.
You can do this by customizing a detector to ignore findings in a given file type, a given file of a match in a dictionary file. Customers can utilize existing dictionaries, file type detectors or file fingerprint detectors to author an exclusion rule.
Nightfall can perform manual or automated remediation action to redact text-based findings in pages and blog posts within Confluence.
December 2022
Enhancement: Detection Rules Page
Improved Search, improved detection rule creating and editing experience.
November 2022
Detector: File-Related Detectors
Remediation: Disabling Download in Google Drive
Enhancement: HTTP Header Support in Webhooks
Enhancement: Violations monitoring
Enhancement: Historical Scans
Integration: Slack - User and App exclusions
Nightfall now has new specialized file related detectors.
. File Fingerprint Detector - creates a unique hash of the sensitive files that enables you to receive alerts and discover where they are located or shared.
. File Type - Receive alerts when certain file types (like audio or video) are discovered. You can adhere to compliance policies that prohibit certain file types from being shared on particular applications or storage locations. These file types are detected regardless of file extension.
File Name - You can scan for sensitive data in file names a well as file content by setting the “scope” of detection on your Detectors. Use regular expressions to match either file extensions or file names.
A new remediation option is available for violations detected in Google Drive. From the violations console, administrator can disable download of offending files. Click More Options ellipsis (...) next to a violation finding to access the option.
You can now provide custom HTTP headers to alerts sent to webhooks. These headers may be used to support systems collecting SIEM data that do not allow for query string authentication as well as other purposes such as routing.
Enhancements for a simplified, efficient violation monitoring workflow:
. Finding type to be the first column as a stronger risk assessment vector.
. Age of violation is the primary way date and time are factored into risk assessment.
. Violation status is instantly visible/available with color-coded status pills.
. Improved UI reducing the amount of content displayed by removing policies, and integration columns.
Historical scans in Google Drive and Confluence are now disabled by default for all new Nightfall customers. You can reach out to Nightfall support to request historical scans in Google drive or Confluence. Existing customers shall continue to view historical scans from the console.
Nightfall administrators can instantly select specific users of apps whose messages must be excluded from scans. This feature is supported on both Slack Pro & Enterprise.
October 2022
Enhancement: Webhook alerts - Updated schema v2
Updated schema for webhook alerts enables you to:
1. Filter and report per tenant with a company UUID key/value pair in each alert.
2. Consolidate common fields into one, coherent core set that is shared across all integrations for consistent, out-of-the-box reporting and analytics across all integrations.
3. List all findings up to 1000 per alert removing aggregation/summary for detailed downstream reporting an analytics.
4. Remove findings results from JSON key names eliminating custom scripting required to extract and analyze findings.
5. Keep Integration specific information under integration metadata.
August 2022
Integration: Nightfall for Salesforce
Enhancement: Reporting
Salesforce data security and compliance is now available to all customers. Scan objects and fields in real-time and take remediation actions from Slack, email alerts or the Nightfall console to eliminate data exposure risks.
Customers can now navigate directly to Dashboard → Generate Reports to access four independent reports:
1. Policy violations report - Aggregation of violations along with distribution by confidence thresholds and status by the policy.
2. Highest risk users report - Aggregation of violations along with distribution by confidence thresholds and status by each user.
3. Total data scanned report - Summary of total data and items scanned per integration.
4. Sensitive data exposure report
July 2022
Remediation: Nightfall for Confluence
You can now set up remediation actions to be taken from your Confluence policies. Alerts can be used to trigger manual or automated actions.
June 2022
Integration: Nightfall for Salesforce
You can use Nightfall to scan sandbox and production organizations in Salesforce in real-time.
May 2022
Enhancement: Nightfall Console - Dashboard and Violations Monitoring
Real-time Scanning: Nightfall for Confluence
Remediation: Nightfall for Jira
The new Violations UI in the console now displays real-time visualizations that show:
. Violations with the distribution of active and resolved violations
. Distribution of violations cross all integrations with the ability filter to a specific integration
. Distribution of violations across detectors and policies
. Highest risk users with a flexibility to filter by integration likelihood, and detector
Scan all Changes in your Confluence environment in real-time and receive immediate alerts on any violations. The update includes user interface enhancements that simplify the configuration.
. Take automatic or manual remediation actions in Jira including:
. Notifying the file owner
. Redacting sensitive findings
. Deleting attachments
For more information, see Nightfall’s Jira Remediation Guide
January 2022
Enhancement: Nightfall for Slack, GDrive, Jira: Custom Notifications in Alerts
You can send custom notifications for Slack, Google Drive, and Jira alerts.
. Reference your internal security policy.
. Direct end users to helpful security resources from an alert notification.
November 2021
Redaction: Nightfall for Slack - Message Redaction
Nightfall Slack Enterprise are now able to use redaction as remediation action for messages.
September 2021
Remediation: Nightfall for GDrive
Nightfall has added actions to violation alerts for GDrive. You can take remedial action with a click.
August 2021
Integration: Nightfall for Slack
Nightfall’s revamped Slack Integration is now in GA, featuring:
. Enhanced policy flexibility.
. More context in end user alerts Updated UI.
June 2021
Enhancement: Alerts
Integration: Nightfall for Jira
View finding snippets within alerts from Nightfall's native integrations.
Easily locate findings in long documents or spreadsheets with many tabs.
Make judgements at a glance about a violation’s severity. 2. Real time scanning for Jira is available.
. Scan for all changes in Jira and receive immediate alert for any violations.
. New policy flexibility allows for multiple alert triggers per Jira Project.
POLICY
WHAT DOES IT DETAIL?
HOW DOES NIGHTFALL HELP?
Data Classification & Management
Company should have procedures to classify data in accordance with classification policies and periodically monitor/update such classifications. The company stores and disposes of sensitive data, in a manner that:
Reasonably safeguards data confidentiality
Protects against the unauthorized use or disclosure of the data
Secures or destroys the data
Sensitive data should be validated and protected against unauthorized disclosure or modification, when in use, stored, or transported, to ensure information security and to mitigate risk against attacks.
✓ Identifies if sensitive data exists in a system or when it enters into an application in real-time
✓ Leverages variables such as internal/external visibility and permissions to prioritize findings by risk level
✓ Provides remediation capabilities
✓ Fulfills auditor checks against controls for data classification and information security policies
✓ Managed services team monitors configuration and alerting to facilitate management/improvement of the classification
Data Retention & Disposal
Company should maintain a process designed to prevent sensitive data from being exposed to unauthorized individuals.
✓ Provides remediation capabilities for real-time scans
✓ Enables companies to operationalize a process to remove or obscure sensitive data
Password Security
Company should ensure passwords and credentials are not hard coded or embedded in static code.
✓ Proprietary detectors intelligently find secrets and credentials across applications, including code repositories
One or more
Both
Both
+
One or more
US Social Security Number (SSN)
Vehicle Identification Number (VIN)
Device Identifiers
Medical Beneficiary Identifier (MBI)
US Health Insurance Claim Number
US Individual Taxpayer Identification Number (ITIN)
Person Name
Date of Birth
Person Name
Street Address
+
ICD10 Code
ICD10 Description
Nation Provider Identifier (NPI)
FDA Drug Name
FDA Drug Code
PHI (Very Likely)
PII Group 1, 2, or 3 AND a Health Identifier are found, all with Very Likely confidence.
PHI (Likely)
PII Group 1, 2, or 3 AND a Health Identifier are found, some with Likely confidence.
An introduction to the Nightfall Cloud DLP
Nightfall recommends you to read the Why Cloud DLP? document and then proceed with this document.
Nightfall is the industry’s first AI-native data leak protection platform. Nightfall integrates directly with cloud apps and data infrastructure to discover, classify, and protect sensitive information. Typical use cases for Nightfall include data loss prevention (DLP), data classification, and content moderation. Nightfall has pre-built integrations for popular cloud apps like Slack, GitHub, Google Drive, Confluence, Jira and Salesforce; and also offers the ability to integrate with any application or data flow via our Developer Platform.
With Nightfall:
Identify where you have risks related to sensitive information exposure in the cloud.
Protect sensitive information, for example by removing it from where it doesn’t belong.
Add content inspection and remediation capabilities to any third-party application, without agents or proxies.
Leverage machine learning (ML)-based detection for smarter results, with high accuracy, easy tuning, and fewer false positives.
Configure and customize data detection policies that meet your organization’s unique needs, such as allowing data to exist in one location but not another.
Nightfall provides 150+ ML-based detectors out of the box to identify and remove a wide range of sensitive data, helping organizations to implement a holistic approach to data stewardship across their cloud ecosystem, and to comply with SOC 2, HIPAA, PCI, CCPA, and client requirements.
Nightfall is backed by Bain Capital Ventures, Venrock, Webb Investment Network, and a cadre of high-profile operators, including CEO/executives of Okta, Splunk, FireEye, Atlassian, and Salesforce.
Learn more about Nightfall here.
Learn about Nightfall secret detection.
Nightfall's API key supports generic API key detection plus vendor-specific and use-case-specific keys. Nightfall attempts to validate the key status of vendor-specific keys and JWT tokens.
• AWS
• Azure
• Coinbase
• Confluence
• Confluent
• Databricks
• Datadog
• ElasticSearch
• Facebook • GCP - Google Cloud
• Google API - All other Google Services
• GitHub
• GitLab
• Hugging Face
• JIRA
• Nightfall
• Notion
• Okta
• OpenAI
• PagerDuty
• Paypal
• Plaid
• Postmark
• Postman
• Rapid API
• Salesforce
• Sendgrid
• Slack
• Snyk
• Square
• Stripe
• Twilio
• Zapier
• Authentication Token
• CSRF Token
• OAuth Token
• Generic API Key
• Generic Token
• JWT
• Private Key
• Refresh Token
• Session Token
Nightfall identifies and validates popular crypto keys for locking or unlocking cryptographic functions, including authentication, authorization, and encryption.
• DSA Private Key
• RSA Private Key
• EC Private Key
• OpenSSH Private Key
• Private Key
• Encrypted Private Key
• PGP Private Key Block
You can send us a request for new Secrets detectors directly in Nightfall.
Learn how to evaluate detection rules in Nightfall.
In order to evaluate the success of your cloud DLP detection, you must first have clarity around your organization’s goals. This will be highly dependent on your organization’s unique circumstances and needs.
Here are some guiding questions:
What sensitive data would you like to detect and which are the highest priorities for each SaaS application?
What level of risk are you comfortable with? Would you like to alert on only the most risky findings or have visibility into even low-risk data types that may not warrant action?
How much operational load are you willing to take on? The more granular your approach, the less human discretion will be required in the filtering and remediation steps.
What are the requirements of any compliance regimes you are accountable to?
What user strategy would you like to implement?
Some potential answers:
Minimal impact on user experience, only alerting and monitoring to security staff and notifications to end users to guide towards remediation?
Educating and empowering users about DLP best practices?
Enforcing DLP through strict controls and automation?
Once you have a sense of your goals, we recommend that you optimize your detection during a phased, iterative implementation - start small, and broaden gradually. Typically, the biggest pitfall customers want to avoid during implementation is to get flooded by too many low-priority alerts that become unmanageable - which is typically caused by taking too broad of an approach to detection. By taking the time to optimize your detection gradually during the first few weeks, your team will be set up for ongoing success.
For this reason, we have created our Detection Wizard, which is a resource that will recommend the exact configuration to suit your use cases. You can shortcut a lot of legwork in choosing and fine-tuning rules by immediately identifying the recommended and validated configuration that matches your use case.
There is generally little reason to deviate from the Wizard’s recommendations at the outset, but your use case may warrant fine-tuning and broadening your detection logic over time:
We recommend that you select just a few detectors to start out with as recommended by the Wizard, in order to optimize detection of the most critical and high-risk information types.
Once a few detectors and initial detection rules are in place, test some sample data and monitor the results. We suggest you evaluate metrics such as false positive and false negative rates, and assess whether the volume of alerts/results is manageable by your team. You may adjust parameters such as Minimum Confidence and Minimum Number of Findings to optimize the level of alerts through your testing process.
Then, continue to iterate and modify your detection by adding and optimizing a few more detectors as required. Focus on starting with tighter detection rules (higher confidence levels), and slowly relax or broaden the rules over time.
Nightfall offers a library of Sample Data that we recommend for evaluating DLP technologies.
It’s important to understand that the rate of true positive data “in the wild” tends to be significantly lower than true positive data in a test environment. That’s because, in a test environment, many occurrences of sensitive information will be intentionally planted.
As a result, test environments are typically most useful for optimizing sensitivity, or the true positive rate - detection is optimized toward identifying sensitive information as sensitive. While this helps ensure that occurrences of sensitive information are, in fact, correctly flagged, it also means detection is somewhat skewed toward flagging information as sensitive, thus increasing the potential for false positives (see the tradeoff between sensitivity and specificity).
What this means for you is that if you fine-tune a detection rule in a test environment, you may over-index towards sensitivity rather than specificity, which can result in a higher degree of false positives in the wild. As a result, we highly recommend evaluating detection rules in a production environment rather than a test environment, when possible.
Understand how detection works in Nightfall.
Each machine learning detector is a model, which is trained using curated datasets to recognize sensitive data tokens based on certain characteristics (e.g. structure) and on surrounding context (e.g. preceding words). Machine learning models have the ability to automatically learn and improve from experience, without being explicitly programmed - giving them broader scope and higher accuracy than hard-programmed models (such as regular expressions).
Nightfall’s detectors are trained via machine learning to recognize many potential permutations of sensitive data tokens, and also to recognize and assess the surrounding context. The ability to recognize a variety of data structures and context gives Nightfall’s detection far more scope and accuracy than traditional regular expression (regex)-based detection. Nightfall’s internal team of machine learning engineers and data scientists are continuously developing new machine learning-based detectors, and they also handle the ongoing maintenance and training of our detection engine to continually improve accuracy and results.
A little background on measuring accuracy will be helpful to understand before you embark on your detector optimization journey. Accuracy is the ability of a detector to correctly flag sensitive content and not flag content that is not sensitive.
No detector is 100% accurate, and it is possible to have a discrepancy between information that is actually sensitive, and information that is flagged by a detector as sensitive. For example, a detector may incorrectly assess a piece of sensitive content as nonsensitive (this would be a false positive). The various result types you may get, based on the actual versus assessed sensitivity of content, are illustrated below.
Is the Content Actually Sensitive?
Yes (“Positive”)
No (“Negative”)
Row Total:
Was the detector flagged?
Yes (“Positive”)
True Positive (TP)
False Positive (FP)
TP + FP
(total number of content items flagged by detector)
No (“Negative”)
False Negative (FN)
True Negative (TN)
FN + TN
(total number of content items not flagged by detector)
Column Total:
TP + FN
(total number of content items that are actually sensitive)
FP + TN
(total number of content items that are actually not sensitive)
TP + FP + FN + TN
(total number of content items)
Accuracy = (TP + TN) / (TP + TN + FP + FN)
Sensitivity = TP / (TP + FN)
Specificity = TN / (FP + TN)
Your organization will, of course, want sensitive data detection to be as accurate as possible. However, it’s important to understand that there is always a tradeoff between accurately identifying true positives (sensitivity) versus accurately identifying true negatives (specificity).
Sensitivity (also known as: recall, hit rate, or true positive rate [TPR]) is the ability of a detector to correctly identify content with sensitive findings.
Specificity (also known as: selectivity, true negative rate [TNR]) is the ability of a detector to correctly identify content without sensitive data.
The tradeoff between sensitivity and specificity occurs because you must choose whether to optimize a detector toward or away from flagging information. Higher sensitivities mean lower specificities and vice versa. For example, to optimize for sensitivity, you may enable more detectors at lower minimum confidences to catch more true positives. In doing so, you will open yourself up to more false positives, which will lower your specificity.
As a result, each organization should spend time optimizing its detectors to strike the right balance between sensitivity and specificity.
A confidence level represents Nightfall’s confidence in the accuracy of a given detection. Each detector is a unique model and will have its own confidence level profile. For details on how confidence level is determined for a given detector, please reach out to us.
Confidence may be any of the following values corresponding to the given confidence intervals:
Likelihood
Probability Threshold
Interpretation
POSSIBLE (“Possible”)
40%+
“It is possible that the data matches the info type.”
LIKELY (“Likely”)
60%+
“It is likely that the data matches the info type.”
VERY_LIKELY (“Very Likely”)
80%+
“It is very likely that the data matches the info type.”
Each info type is unique, so it is not possible to dictate that what yields a “Very Likely” match for one detector, will yield a “Very Likely” result for another. Nonetheless, we can provide some high-level guidance. Generally speaking, higher confidence detections may have certain features that increase confidence in the detection being accurate - some examples of the features include:
Formatting of token
Passes validation functions
Passes substring checks
Context clues that are indicative of that info type
Model scoring
Some Nightfall integrations (e.g. Nightfall DLP for Google Drive) offer options for both historical and real-time scanning. Some organizations wish to minimize the amount of real-time alerts they receive daily but still want to maintain a comprehensive data scanning and protection strategy.
One option is to create Detection Rules for real-time scans that are limited to the types of sensitive information that are most critical or highest risk to your organization. Then, leverage broader historical scans to capture less critical risks on a routine cadence, when your team can plan resourcing in advance (e.g. monthly or quarterly).
Nightfall can fully manage historical scan executions on your behalf to scan data in your SaaS applications. Due to the sheer volume of content that can amass in cloud apps over time, historical scans can be very resource-intensive and may take days or more to process. As such, we advise against running broad historical scans all at once.
Instead, we recommend that you prioritize certain detectors based on your organization’s definition of critical violations and limit the scan to a specific date range (e.g. one month at a time). Then, you can request the Nightfall team (support@nightfall.ai or contact your customer success representative) to run a historical scan on a SaaS application of interest.
Upon completion of the historical scan, Nightfall will share a risk assessment report with an overview of the highest severity findings, highest risk files or resources, users with the most number of violations, the total amount of data scanned, and more.
Tips for improving finding accuracy.
Our models learn from diverse data sets, aim for high accuracy, and often perform well. However, customer data sometimes contains new patterns. Think of our models as capable students who excel in some subjects but still have unavoidable gaps in their knowledge. New data may expose gaps.
By reporting these misses, you directly help close knowledge gaps and improve alerting for your company and others.
Reporting misidentified findings
If your company is a member of our ML training program, annotate the false positive in the Violations UI. Your annotated sample will be added to our ML data set and used in upcoming model re-training.
If not an ML training program member, please send us anonymized samples without changing the key pattern.
Reach out to support@nightfall.ai for more information about our ML training program.
If the customer needs a fix urgently, many cases can be addressed by extending a Nightfall detector. if you need help, please don’t hesitate to ask for help.
Reporting missed sensitive data.
Please provide us with anonymized samples without changing the key pattern.
If anonymization is impossible, coordinate with us to send the data using a secure tool like Keybase.
With the Nightfall Detection Engine, there are various ways you can improve the accuracy of detection:
Share your false positives with Nightfall. We'll identify the issue and retrain our models. If your company is a member of our ML training program, annotate the false positive in the Violations UI. Your annotated sample will be added to our ML data set and used in upcoming model re-training. If not an ML training program member, please send us anonymized samples without changing the key pattern. Reach out to support@nightfall.ai for more information about our ML training program.
Modify the detector using an exclusion rule recognizing known test or mock values. Read more about exclusion rules in How do I use Exclusion Rules?
Modify the detector using a context rule recognizing common patterns in the text surrounding the sensitive token. Read more about context rules in How do I use Context Rules?
Increase the detector's minimum confidence to “Likely” or “Very Likely”. Read more about detector confidence levels in What do different “Confidence Levels” mean?
Set up the Detection Rule’s to trigger when each entity type is found. Common Entities such as names, addresses, phone numbers, and emails are found everywhere and are generally not sensitive unless found in combination.
Set up policies appropriate to the scanned data source - i.e. integration, channel, folder, instance, etc. For example with Slack Enterprise, you can enable or disable detection in private channels, direct messages by channel ID, workspace ID, or in all private channels & DMs. Reach out to support@nightfall.ai and we will help.
Increase the Detection Rule’s minimum number of findings threshold. For example, when trying to detect phone list sharing, set you detection rule to ony trigger alerts when seeing 10 or more person names and phone numbers.
Learn how Nightfall assigns confidence levels to sensitive data classifications.
Detection results are comprised of two parts:
A data type detector that was scanned for (either a Nightfall detector or a custom regex detector). For example, a Credit Card Number.
A confidence that the scanned data matches the specific info type. For example, a “Very Likely” match.
Confidence may be any of the following values corresponding to the given intervals:
Likelihood
Probability Threshold
Interpretation
POSSIBLE (“Possible”)
40%+
“It is possible that the data matches the info type.”
LIKELY (“Likely”)
60%+
“It is likely that the data matches the info type.”
VERY_LIKELY
(“Very Likely”)
80%+
“It is very likely that the data matches the info type.”
Each info type is unique, so it is not possible to dictate that what yields a “Very Likely” match for one detector, will yield a “Very Likely” result for another. Nonetheless, we can provide some high-level guidance. Generally speaking, higher confidence detections may have certain features that increase confidence in the detection being accurate - some examples of the features include:
Formatting of token
Passes validation functions
Passes substring checks
Context clues that are indicative of that info type
You can learn more about these specific features and how detection works in How does detection work?
Minimum confidence may be specified as part of any condition in the Nightfall Detection Engine. In the Nightfall scan API and Atlassian integrations, the confidence is returned to the end-user as part of the results. In Nightfall’s Slack and GitHub integrations, the confidence is not returned with the results at this time. You can tune the accuracy of the results by adjusting the confidence thresholds in the Nightfall dashboard.
For pre-built detectors, a “Possible” confidence level is triggered by the appearance of the token, without considering context, whereas “Likely” and “Very Likely” take context into account. When a custom regex is detected, its Confidence Level is assessed as “Likely” - you may determine how the Confidence Level adjusts from there based on context.
Of course, there is a tradeoff - a lower Confidence Level may result in more noise. We highly recommend setting the Minimum Confidence of every detector to Likely or Very Likely in order to reduce noise and focus your DLP efforts on priority violations. Setting your detectors to Possible or below will lead to many more findings and is best suited for scenarios in which risk tolerance is very low, or for special / advanced use cases that involve optimizing for reducing false negatives.
When setting confidence thresholds, also consider how structured the data tends to be. For example, a Social Security Number or Credit Card Number has a very typical structure and false positives may be less likely - so you could decrease the confidence threshold in order to implement a very conservative policy. On the other hand, less structured data such as Names could result in more false positives, and thus you may want to increase the confidence threshold.
Nightfall scans for sensitive data in a broad range of file types
Nightfall supports scanning most file types, except for audio and video files. Image files are scanned using optical character recognition (OCR). Embedded files images and non-visible URLs are included in file scans. Max file size is 1 GB. Contact us at support@nightfall.ai, if you need us to raise this limit.
Supported file types:
Microsoft Office documents (Word, Excel, Powerpoint, etc.)
Google Workspace documents (Doc, Sheet, Slide, etc.)
Image file types (PNG, JPG, TIFF, GIF, etc.)
PDF files
All text-based document files (HTML, TXT, etc.)
All text-based code and config file types
All text-based data file types (CSV, TSV, JSON, XML, parquet, etc.)
Compressed file types (zip, gzip, etc.) are decompressed, and the contained files are scanned.
Unsupported file types (audio, video, and animation):
audio/midi
audio/mpeg
audio/wav
audio/x-midi
video/mp4
video/mpeg
application/photoshop
video/Quicktime
Autodesk 3d animation files (ma, fbx)
Select from an aggregated library of regexes
Yes! While Nightfall's pre-built detectors listed above are trained via machine learning, Nightfall also supports RE2 regexes and word lists for any custom detectors that may be of interest to you. Over time, we've aggregated the following Regex Library, which you're welcome to select from to save you some time.
Please note that a regular expression is an established yet limited method that searches for pre-defined patterns, so your mileage may vary.
You can test regular expressions here.
You can input custom detectors directly in the Nightfall console at app.nightfall.ai by navigating to Detectors → New Detector → Regular expression.
Learn about typical cases of Nightfall
Social security numbers (SSNs) are a common data type we scan for. You may notice 9-digit numbers in your data that resemble SSNs. If you lower your detection rule confidence to possible, these numbers will appear in your dashboard.
However, over 90% of 9-digit numbers are typically false positives that don't require action. Numbers formatted like SSNs are often used as internal IDs - for tickets, service calls, events, dispatches, transactions, etc. They can also be valid driver's licenses or bank account numbers.
With more context, our models can better determine if a 9-digit number is likely an SSN. For example, when a number appears in a sentence or tabular data with a descriptive header, our confidence in predicting it as an SSN increases to likely or very likely.
Providing contextual cues helps our models accurately identify SSNs and avoid false positives. We continue improving our algorithms to balance detection with precision.
The same thinking applies to other alpha-numeric info types like credit card numbers and passport numbers.
Please reach out if you have any further questions!
Zoom Password Findings
Previously, Nightfall Password detector used to report Zoom passwords as sensitive data findings. However, the Nightfall Password detector now recognizes passwords found in personal Zoom links. Customers sharing these links in docs and messages will no longer be alerted for these non-sensitive findings.
The detector can now identify patterns such as:
Zoom meeting invites containing embedded PWD parameters and separate alpha-numeric passcodes.
Zoom recording URLs with associated passcodes.
Examples:
Multi-line meeting invite with embedded Zoom password and passcode
https://company.zoom.us/j?pwd=VBhZM3h5SEhQTXEzQzEyYUREWkJHQT09
Meeting ID: 991 1959 8432
Passcode: 475749
Recording URL with passcode
https://company.zoom.us/rec/share/zuBQvxkbLce3PRl6eYSBXN0Uj47mE9grL_6G4J1qeFcaWCqB94hdgC5hb4B3R3SF.VxapNL9oXfGuiokO
Passcode: BH%$!.06
In many cases, you may not need all of your data, residing in the integration, to be scanned. You might only require a specific section of your data to be scanned which is highly prone to data leakage.
The Scope stage allows you to set boundaries for monitoring. You can pick only a required section of the integration to be scanned thus reducing the noise from trusted sources. All the integrations in Nightfall (except Notion and ChatGPT) provide you the flexibility to pick and choose specific sections to include or exclude for monitoring. Nightfall scans only the data that matches the scope settings configured by you.
The configurations of the Scope stage varies for each integration. The following sections briefly describe the Scope stages for all the integrations.
The GitHub integration's Scope stage allows you to select a specific GitHub org initially. Once you select the org, you can choose to scan either all of the repositories, only the public repositories, or only the private repositories from within the selected GitHub org. Once you select the required repository type (all, public, or private) to be scanned, Nightfall allows you to set conditions to exclude a specific repository (or repositories) which you do not wish to scan.
The Scope stage in the Microsoft Teams integration allows you to set the scope on two entities.
a. Chats: The Chats section allows you to scan individual chat messages sent in MS teams. You can choose to scan either messages from all the users or specific users and groups. Furthermore, if you choose to scan messages from all the users, Nightfall optionally allows you to exclude scanning of specific users and user groups.
b. Teams: The teams section allows you to scan messages shared in Teams. You can choose to scan either specific Teams or specific Teams. Within the selected team, you can choose to scan the required channels. You can also use exclusion rules to exclude specific channels or Teams.
The Scope stage in the Slack integration is different for Slack Pro and Business+ editions, and Slack enterprise edition.
a. Slack Pro and Business+: In Slack pro and business+ editions, you can choose to monitor all the public channel, private channels, public connect channels, or private connect channels. You can choose to scan the required channel type(s). Within the selected channel type(s), Nightfall allows you to scan or exclude scanning of individual users, groups, or apps.
b. Slack Enterprise: In Slack Enterprise edition, you can choose to scan either specific workspaces or specific channels. If you choose to monitor Workspaces, you can further choose to monitor all the types of channels and connect channels. Furthermore, you can choose to scan or exclude scanning of specific Users, groups, channels, or apps.
The Scope stage in JIRA integration allows you to select a specific JIRA instance initially. Once you select a JIRA instance, you can choose to scan either all the projects or specific projects from the selected JIRA instance. If you choose to scan all the JIRA projects, Nightfall allows you to exclude trusted JIRA projects from being scanned.
The Scope stage in Confluence integration allows you to select a specific Confluence site initially. Once you select a Confluence site, you can choose to scan either all the Spaces or specific Spaces from the selected Confluence site. If you choose to scan all the Confluence Spaces, Nightfall allows you to exclude trusted Confluence Spaces from being scanned.
The Google Drive Scope stage allows you to select all User Drives or shared drives. Within shared drives you can choose to scan either specific shared drives, exclude scanning of specific shared drives, or scan all the shared drives. Furthermore, you can also choose to scan files based on their sharing permissions. Lastly, Nightfall provides a host of filters to for granular controls. You can use the filters, to include or exclude specific users, groups, files, or labels.
The Gmail Scope stage allows you to scan or exclude the scanning of emails sent by specific users or user groups. Apart from senders you can also choose to scan or exclude scanning of emails sent to specific recipients and domains.
The Scope stage in OneDrive allows you to select files either based on permissions or special folders. Once you select the files based on permissions and special folders, you can choose to exclude certain files by creating specific exclusion rules.
The Zendesk Scope stage allows you to select a Zendesk instance. Once you select a Zendesk instance, you can choose to scan messages based on status of the tickets. Once you choose tickets with the required status, you can choose to exclude tickets from specific groups or agents.
The Salesforce Scope stage allows you to select a Salesforce org initially. Once you select a Salesforce org, you can choose to scan the required objects within the org, and the fields within the selected objects.
Policy scopes allow you to configure which data to scan in your connected SaaS, GenAI applications. By carefully defining your policy scopes, you can reduce alert volume and focus on the most critical data. Here are some key considerations and best practices for creating effective policy scopes:
Start broad, then narrow: Begin with a wide scope and gradually refine it based on your findings and needs. You can execute a historical scan on supported SaaS apps to assess where and what types of sensitive data reside in these apps and use this information to create policies.
Prioritize sensitive data: Focus on areas where sensitive or regulated data is most likely to be stored or shared.
Consider your organizational structure: Align scopes with your company's departments, teams, or projects.
Review and update regularly: As your organization changes and as you start reviewing policy violations from Nightfall, revisit and adjust your policy scopes accordingly.
Create scopes based on channel types such as public, private or connect channels or DMs.
Utilize users, user groups to limit scanning of messages sent by specific users or users within specific groups.
Use file permissions to limit the scanning of files that are externally shared or shared with external users, groups
Leverage users, user groups synced via Okta/Google Directory/Entra ID for team or department-wise scoping. Implement label-based filtering for sensitive document categories.
Focus on external communications by filtering specific recipient domains or emails sent by specific senders, and recipients.
Create separate policies for different departments or teams based on email patterns. For example, you may only want to monitor email communications of the support team to specific recipient domains.
Focus on specific objects and fields containing sensitive customer data.
Utilize file permissions to focus on shared or externally accessible content.
Consider scoping by specific user drives for high-priority individuals.
Use file type exclusions to ignore non-sensitive formats.
Leverage label-based exclusions for efficient filtering.
Scope by including or excluding specific projects in Jira.
Use space inclusions/exclusions to focus on specific areas of your knowledge base.
Consider separate policies for public and restricted spaces.
Scope by each organization within GitHub
Use repository pattern exclusions to ignore non-sensitive code bases.
Implement file extension filtering to focus on specific file types.
Utilize path exclusion to ignore non-critical areas of repositories.
Create scopes based on ticket status to prioritize discovery and remediation of sensitive data within closed issues.
Test policies with limited scopes before expanding.
Monitor alert volumes and adjust scopes as needed.
Collaborate with stakeholders from different departments to ensure comprehensive coverage.
Regularly review and update scopes as your SaaS usage evolves.
By following these best practices and considering the unique filtering capabilities of each supported app, you can create effective policy scopes that balance comprehensive data loss prevention with manageable alert volumes.
Learn how to create policies in Nightfall.
This document applies only to the Nightfall SaaS application customer. If you are a Nightfall Firewall for AI customer, refer to this document.
An Integration in Nightfall refers to a SaaS application in which your organization's data resides. This SaaS application can be Google Drive, JIRA, Notion, GitHub, and so on. The sensitive data residing in these applications is highly prone to data leakage, accidentally by your employees.
You can connect your SaaS applications to Nightfall by adding them as integrations. Once a SaaS application is added as an integration, Nightfall continuously scans it to check if there is any sensitive data leakage.
A Policy in Nightfall allows you to define a specific part of your integration or the entire integration to be monitored for sensitive data leakage, by Nightfall. Apart from monitoring your environment, Policies in Nightfall also allow you to configure alerts and automatic actions if Nightfall discovers sensitive information in the integration being scanned.
Once you create a policy, if there is any instance of data leakage, Nightfall sends notifications to the audience configured by you in the policy. It also takes automated actions, configured by you in the policy. If you have disabled automated actions and no action is taken by you, Nightfall also sends reminders, as per the frequency set by you in the policy. All these actions are done automatically by Nightfall, as per the policy settings, configured by you.
A Policy in Nightfall is always associated with integration. You can create multiple policies on a single integration. Before creating a policy for an integration, you must first ensure that the integration is added to Nightfall.
A Nightfall Policy has multiple stages. You can configure various settings like adding specific sections of integration to be scanned, configuring alert notifications, end-user actions, and so on. The various stages of a policy are described in the following document.
Learn how to use Jira as an alert platform in Nightall.
The Jira alert platform is installed automatically once you install the DLP for Jira app. You can refer to this document to learn more about how to install the app. Once the app is installed, you can use Jira as an alert platform.
Learn how to operationalize NIghtfall Playbook.
When implementing any new security tool or system, it is important to always consider the following for a seamless roll out:
Developing playbooks for the tool’s owners and primary users
Limiting disruption to end users
Maximizing impact and value of the tool
Nightfall is simple to implement all at once, but as with any tool, you want to make sure that you and your team are able to effectively incorporate a new tool into your day to day. This is especially important if you did not already have existing oversight into where sensitive information may have proliferated in your tech stack and you are going from 0 to 1 when it comes to discovering and managing violations.
To implement Nightfall effectively, we recommend a phased rollout - by tool coverage and by use case.
Which tools require imminent monitoring? Prioritize your systems accordingly.
We recommend phasing the rollout by tool or system simply because each new tool and system allows for different policy configurations. There is not a one-size-fits-all approach to remediating violations across tools and systems. Each tool will have its own “appropriate” measures for remediation based on what that tool’s function is at the company. For example, remediating violations on Slack can entail notifying, redacting, quarantining, or even deleting messages. However, those same actions do not apply in Google Drive; in Google Drive, Security teams care more about proper permissions and sharing settings. See below for considerations for each tool.
What are you solving for when monitoring tools for sensitive data? Are you fulfilling a compliance requirement? If so, which one(s)? Are you safeguarding secrets & credentials to protect customer data in your data warehouses?
Order these use cases in terms of priority.
By phasing the rollout by use case, you allow your team to thoughtfully consider the best practices for each use case so you can effectively train your end users. In addition, the phased rollout gives you an opportunity to assess the current state of affairs per use case without overwhelming your team with violations (in the event your end users are indeed sharing sensitive data inappropriately left and right — we hope not!).
From a workflow perspective, consider how many SecOps team members will be managing violations. Larger teams may have multiple designated owners to manage violations for each product covered; smaller teams may only have a single designated owner to manage violations across all products. If you have a larger team, we recommend staffing coverage by product, as you can send alerts to separate channels to help optimize triaging. Additionally, each owner would be trained to handle and remediate violations across use cases, which allows for seamless team coverage in the event someone is out of the office.
Some teams like to designate ownership by use case. This is useful especially when there are cross-functional stakeholders involved and you want to align your Security team to functional teams. We would continue to recommend this approach so your business partners have a go-to partner on your team to oversee or manage joint security initiatives.
i. Determine which teams and end users might be affected
The teams and end users affected will vary depending on tool coverage and use case. Examples:
Slack: likely to impact all employees
Google Drive: likely to impact all employees
GitHub: likely to impact the Engineering org
Jira: likely to impact the Product and Engineering orgs; depending on which services in Jira your company uses, such as Jira Service Desk, this can also impact IT, Customer Success and Support, or even more broadly, the whole company
Confluence: likely to impact all employees
Salesforce: likely to impact the Go-To-Market org
Zendesk: likely to impact Customer Success and Support teams
Others: consider who are the primary users of the tool or system
ii. Communicate with impacted teams and end users about Nightfall’s protection being in place
Template for rolling out Nightfall to your business users
iii. Install Nightfall to cover the tool or system
Please refer to our Help Center or reach out to your CSM or support@nightfall.ai for additional support.
iv. Identify scope of coverage within the tool or system
Consider where you want to scan. This can vary product by product - in some cases, you will want to scan everywhere and everything; in others, in certain areas only. Review the Considerations by Product section for guidance.
v. Set up your detectors, detection rules, and policies for your use case
Review our Detection Wizard for details on how to set up your detection rules.
vi. Monitor for 3-7 days to assess the lay of the land. Begin manually remediating findings
Here are some initial guiding principles on managing violations. If you have a larger SecOps team managing violations per product, we strongly recommend following the third guiding principle. Acknowledging an alert helps to avoid duplicative efforts so that your team is spending their time efficiently.
Ways to acknowledge an alert
If receiving alerts via Slack, put a reaction emoji on the alert to denote that you are looking on it, e.g. 👀 = “I have eyes on this”
Use Nightfall’s in-alert Acknowledge
action. The Acknowledge
action can indicate that you have received the alert and are reviewing, or, if no other action needed, that the alert has already been reviewed
Some larger SecOps teams may also institute rotationals to manage alerts. These rotationals are much like on-call, where if you have multiple SecOps team members who might be reviewing alerts, you designate ownership in any given week to triage alerts. Each week, you would rotate who is responsible for reviewing violations. This accomplishes three things: clear ownership delineation per week, no single points of failure since multiple people will know how to manage alerts, and increased productivity across the team since people won’t be all jumping in to triage alerts at once.
For smaller teams, or teams where there is one individual responsible for managing alerts, we recommend time blocking 15 minutes at the beginning, middle, and/or end of the day on your calendar to review any outstanding violations. This helps eliminate context switching throughout the day and provides and ensures dedicated time to remediate any findings. The amount spent reviewing violations can and will be reduced over time as you institute automated remediation actions once ready.
Contact the end user: in general, we want the end user to understand the violation and what they should have done instead. For this reason, for every sensitive violation, we recommend reaching out to the end user to let them know of the violation and guide them towards best practices. Template for flagging a violation to a user. Note that when we set up notifications in the Nightfall platform, we can templatize this language for your company’s circumstances.
Test and sample data: test and sample data are often fine to be shared internally. To optimize your team’s bandwidth, we recommend no action needed on test and sample data. During step vii., we can fine tune out test and sample data, to reduce triggering violations on test and sample data as needed. You can find sample test data here.
As you get into the groove of managing violations, we strongly recommend documenting your processes. As your team grows, this playbook can become handy to ensure consistency in reviewing and remediating findings across your tech stack. Since remediation can ultimately differ by product and use case, writing down guidelines will help your team scale.
vii. Tune and refine your detectors, detection rules, and policies
As you learn new things about how your end users and other teams’ processes work, you can assess if those processes make sense from a security standpoint or adjust the configuration to accommodate. These are case by case situations and Nightfall can work with you to help identify what makes the most sense.
Detectors & detection rules: you may find that your company has specific identifiers, keywords, files, etc. that may trigger false positives. In this step, we can help refine these detectors and detection rules to ensure you are only receiving true positive alerts to manage. Nightfall also has a false positive annotation feature which will help train our detectors to improve for you over time.
Policies: during the process of monitoring violations with Nightfall, you will learn how other teams manage processes and you should work with your cross-functional business partner to determine what makes sense from a security standpoint. Nightfall is happy to join these conversations to support. In some cases, you may want to advise your business partner on process change management for their teams to ensure best security practices. In others, you may want to fit how the team remediates violations to their practices. E.g. a team is necessarily going to share files with sensitive data in Google Drive internally; you can ensure that they are not getting shared externally and refine policies to reflect this practice.
Nightfall will also automatically fine tune your detectors and detection rules to improve your configuration over time. However, the initial setup and fine tuning of your policies will set you up for long-term success.
viii. Monitor for 3-7 days to assess impact
You can review reporting and analytics on your Nightfall dashboard.
ix. Set up automated notification for the policy
At this point, you should have a handle on the appropriate ways for users to share certain sensitive information with one another, if needed. In addition, your detectors and detection rules should be firing with a relatively high accuracy rate. Now is a good time to set up automated notifications on the policy because you can have confidence that Nightfall will notify and begin training your end users on alerts with accuracy.
Setting up automated notifications helps take one step off of your SecOps team’s plate. Before setting up this notification, we recommend creating an internal help center guide that the alert can point to for best practices. This helps with long-term training and documentation.
In the notification itself, you can point to this internal help center guide for further reading. Alternatively, if you prefer to not use a help center page, you can point your end users to different resources depending on the use case. For example:
If you need to share secrets internally, please do so via [1Password, Keybase, other encrypted tool, etc.].
If you need to share sensitive PII internally, please do so using [Keybase, other encrypted tool, etc.].
If you need to share any of the above externally, please consult [your manager] for guidance.
If you have any questions, please feel free to reach out to Security at [email address, Slack channel, etc.].
The goal of this notification is to guide end users towards the appropriate behavior so that over time your company adheres to the best security practices.
x. If findings are highly sensitive, set up other automated actions as appropriate
Some habits will have already been built on workflows, but the introduction of a new use case may add nuance to how to manage violations from a different use case. For example, how you work with one team to share sensitive HR information with each other may be different from how you might address another team sharing secrets & credentials with one another.
Additionally, we recommend setting up separate Nightfall alert channels for each tool or system for ease of triaging violations.
Do you want to monitor shared channels? Recommendation: we strongly recommend doing so because these are the channels where it is easiest for private data to be leaked into, even on accident
Do you want to monitor private channels and direct messages?
Are there shared drives where sensitive data is allowed to be housed in? If so, who should have access to those drives? E.g. HR or Data team drives. Recommendation: we strongly recommend continuing to monitor these drives but looking specifically for files where permission settings are too open, such as if those files are shared with anyone with the link, to external users, or even anyone in the organization. These files should remain on “Restricted” permission settings.
Are there drives where data can be shared externally?
Are there private repos where sensitive data such as secrets & credentials are allowed to reside? Recommendation: exclude these repos from scanning for those policies to limit noise.
Are there any Jira Projects where you would expect and allow sensitive data to be shared? Our view is that this is unlikely, but if so, you should exclude these from scanning.
Are there any Spaces or Pages where you would expect and allow sensitive data to be shared? Our view is that this is unlikely, but if so, you should exclude these from scanning.
Which objects or fields in your Salesforce instance are most likely to house sensitive information? Consider long text fields or objects where data may be synced from other sources (cases, activity history, attachments, emails, tasks).
Are there any agents or groups of agents that are allowed to share sensitive information?
If customers share sensitive information on accident, do you want that data removed immediately? Recommendation: remediate findings on tickets that are in progress or closed, as sometimes your Customer Support agents need certain pieces of information to be effective. Once a ticket is closed, then that data should be removed immediately.
Use pre-defined templates to get started quickly with policies.
To view the recommended configurations to apply to different use cases, you are welcome to leverage the Detection Wizard in the Nightfall Playground. This wizard will generate the detection rules that you can apply in your Nightfall console. Learn more about Creating Detection Rules.
Once you have generated the detection rules, you can implement these templates on your own and add the detection rules to your Nightfall Dashboard. You should be all set within 10-15 minutes.
Alternatively, feel free to forward the email you receive with the templates to support@nightfall.ai to have your Customer Success Manager implement these in your tenant on your behalf.
Once you've implemented your detection rules, test them using our sample data sets.
Learn how you can integrate Nightfall with various security tools.
Many customers choose to leverage other security tools, such as SIEMs (e.g. Splunk, Sumo Logic, etc.), to aggregate security-related information and SOARs (e.g. Cortex, Phantom, etc.) to orchestrate remediation & response. With Nightfall, you can export historical scan results and automatically push real-time alerts to third-party sources like a SIEM. From there, you can leverage SIEM capabilities to aggregate, search, filter, and manage alerts.
Some customers have also used workflow tools (e.g. Zapier) to automate workflows or to manipulate data.
Creating dashboards for Nightfall alerts in Splunk
Follow Nightfall's best practices for Alert Management and Remediation
As a best practice, any alerts that contain real, sensitive data should be remediated as soon as possible. This will minimize your security risk and will help set the tone for your DLP strategy moving forward. It is also encouraged to annotate findings within the violation for easy reference, efficient collaboration and detector model improvements.
To lessen the load of which alerts need to be remediated, a best practice is to not take action on sample data or test data. Instead you can annotate such data as false positives for easy reference and model improvements. Remediation should only be a focus for sensitive data that is found through the alerts.
If you already are reviewing an alert, it should be acknowledged to avoid duplicate efforts.
Nightfall FAQs for end-users
Nightfall is like a security guard for your organization’s digital information. It lives in the cloud and keeps an eye out for any signs of data leaks. Imagine it as a watchful friend who ensures that sensitive information doesn’t accidentally slip out. Nightfall ensures that your organization’s secrets stay safe.
You can learn more about Nightfall from this document.
Here are some everyday situations where Nightfall steps in to protect your data:
Google Docs, Sheets, and Slides:
If you create a document, spreadsheet, or presentation with sensitive content (such as financial data or personal info), Nightfall alerts your security team which in turn may choose to alert you.
Messaging Apps (Slack, MS Teams): When you send messages containing sensitive information (maybe a credit card number or confidential project details), Nightfall gives your security team a heads-up which in turn may choose to alert you.
Zendesk Tickets:
Even in customer support interactions, if you accidentally add sensitive info in comments or descriptions, Nightfall intervenes.
Code Commit on GitHub:
When you’re working on code and accidentally include sensitive details (like passwords or private keys), Nightfall raises a flag. Your security team might choose to notify you of such an event.
These are a few examples of how Nightfall helps your organization protect sensitive data. Your security or data governance team may decide to send you additional information about best practices for your situation, invite you to take action, or for you to provide additional context to the situation.
You should expect the following information in a Nightfall notification:
Policy Information
A custom message from your organization often includes information about the data policy and best practices related to the sensitive data discovered.
Event Information
Details about the type of sensitive data including the location and time of the event
Call to action
A list of actions you can take to ensure compliance with your organization's policy or the ability to submit a business justification or report a false positive.
Once you identify the potentially sensitive data, you can take appropriate action. The Nightfall alert displays the actions you can take. The category of actions is as follows.
Report as False Positive:- If you are confident that the potentially sensitive data identified by Nightfall is not sensitive, you can choose either the Report False Positive or the Report False Positive with Business Justification actions.
Remove Sensitive Data or Access:- If the Nightfall alert identified sensitive data you must take action immediately. The available actions vary for each platform. Some examples of these actions are:
For Slack, you can Redact the sensitive information or Delete the message.
For GitHub or Zendesk, you can choose to either Redact or Remove the sensitive data.
For Google Drive, you can choose to Remove access to external users, Restrict Link, or Disable Download.
For Notion, you can either Redact, Remove access to external users, or Restrict Link.
Note: The available actions depend on the settings configured by your Nightfall administrator. If you are unable to view a specific remedial action, contact your Nightfall administrator.
New notifications
Your organization may choose to notify users associated with a potential sensitive data leak or exposure risk. If you think that you have received a notification by error, make sure to report it as a false positive if this option is available to you on the notification or reach out to your data governance and security team.
Reminder notifications
When the notification you receive contains a set of actions you can take, you will keep receiving reminders until you take action, submit a business justification or report as a false positive..
If something you sent or created was automatically removed, this means Nightfall detected what your organization considers a piece of sensitive information. Nightfall will not remove or redact any content that your Nightfall Administrator did not explicitly instruct it to detect.
If you are confident that any data redacted by Nightfall is not sensitive, contact your Nightfall Administrator. If the redacted data is sensitive, you need not take any further action but adhere to more safe sharing practices in the future.
Some of the best practices Nightfall recommends are:
Be overly cautious when sharing active credentials only through approved applications or channels. If you wish to share dummy API keys or testing credentials, notify your organization's Nightfall Administrator.
Thoroughly check if any content that you are about to publish or share contains any sensitive data.
Sensitive data includes information that requires special protection due to its potential impact if exposed. Examples include personally identifiable information (PII), payment card information (PCI), and protected health information (PHI). The full list varies based on the organization and the industry in which it operates.
Sensitive data leaks or breaches can lead to loss of trust, financial repercussions, and legal consequences. Everyone in the organization must prioritize safeguarding this data.
Get started with installing and integrating Nightfall for Slack.
Nightfall for Slack is offered in two variants:
Nightfall Pro DLP for Slack
Nightfall DLP for Slack Enterprise
Learn the process of selecting the Slack integration while creating a Nightfall policy.
In this stage, you select the Integration for which the policy is created. In this case, Slack integration must be selected.
Click Policies from the left menu.
Click + New Policy.
Select Sensitive Data.
Select the Slack integration.
Learn how to configure Nightfall policies for Slack Pro and Slack Business+
DLP policies are a set of rules that include specific conditions, actions, and exceptions that monitor and filter data. DLP policies help you to monitor and remediate the flow of sensitive data within your organization. Depending on your Nightfall policy configuration, you can set up policies to monitor data that is sent through some or all applications within your organization. You can configure policies and choose to not apply them all the time.
Before you define a policy, or a set of policies, you must define the objectives of each policy, which can then be fulfilled when you configure the policy. Here are a few important questions to ask before configuring your policies:
• What data do you plan to monitor?
• Where within the organization do you want to monitor?
• What should be the scope of each policy?
• What conditions must apply for the policy to match?
• What exceptions/exclusions can be allowed?
• What remediation actions should the policy take?
You can now set up policies to determine which Slack channels are monitored (and which are excluded) for violations and what actions Nightfall must take. Policies determine the content that will be scanned by Nightfall, and workflows that are followed to manage violations.
Policies for Slack integration allow you to define configurations specific to Slack, such as how to handle messages for particular channels or use automated actions such as Quarantine.
Creating a Nightfall policy involves the following tasks:
Create Policies
Define the policy scope and exclusions
Configure Detection Rule
Configure Automated Actions
Note: Instructions to configure policies differ for Slack Pro and Slack Enterprise options. Refer to the Slack tier that you are using.
Learn about the various out-of-the-box detectors provided by Nightfall.
This document lists all the out-of-the-box detectors provided by Nightfall.
DATE_OF_BIRTH
Detects a date associated with a person's birth.
EMAIL_ADDRESS
Detects valid e-mail addresses.
PERSON_NAME
Detects a person's name, including first, middle, and last names.
PHONE_NUMBER
Detects a phone number. The number can include an area code and country code.
STREET_ADDRESS
Detects street address, address number, street, city, state, and zip code.
BRAZIL_BUSINESS_TAX_ID_NUMBER_CNPJ
Detects a Brazilian business tax identification number, Cadastro Nacional de Pessoas Jurídicas (CNPJ), a 14-digit number with format XX.XXX.XXX/XXXX-XX. The last two numbers are check digits generated through an arithmetic operation on the previous 12 digits.
BRAZIL_NATURAL_PERSON_REGISTRY_NUMBER_CPF
Detects a Brazilian Natural Person Registry number (CPF number), an 11-digit number with format 000.000.000-00.
BRAZIL_CPF_NUMBER
Detects a Brazilian Natural Person Registry number (CPF number), an 11-digit number with format 000.000.000-00.
BRAZIL_DRIVERS_LICENSE_NUMBER
Detects Brazilian driver''s license number, Carteira Nacional de Habilitação (CNH). Add the Driver''s License image detector to detect an image or photo of the license.
BRAZIL_NATIONAL_ID_CARD_NUMBER_RG
Detects Brazilian national ID card number, Registro Geral (RG).
BRAZIL_PASSPORT_NUMBER
Detects a Brazilian passport number, an 8- to 9-character alphanumeric string. Add the Passport Image detector to detect an image or photo of the passport.
CANADA_BANK_ACCOUNT
Detects a Canadian bank account number, typically a 15-20 digit number.
CANADA_BC_PHN
Detects British Columbia personal health numbers. The 10-digit personal health number is assigned to individuals to receive health services in the British Columbia province. This token must pass the checksum validation.
CANADA_DRIVERS_LICENSE_NUMBER
Detects Canadian driver's license numbers.
CANADA_GOVERNMENT_ID
Detects Canada government ID numbers. This number is provided to all residents that do not have a driver’s license, used for general identification purposes.
CANADA_OHIP
Detects an Ontario health insurance plan number. This 10-digit personal health number is assigned to individuals for health services in Ontario province.
CANADA_PASSPORT
Detects a Canadian passport number, an 8-character alphanumeric identifier.
CANADA_PERMANENT_RESIDENT_NUMBER
Detects a Canada permanent resident number, a 9-12 alphanumeric token assigned to permanent residents in Canada who are not Canadian citizens.
CANADA_QUEBEC_HIN
Detects Quebec health insurance numbers. This 12 alphanumeric token is a personal health number assigned to individuals to receive health services in Quebec province.
CANADA_SOCIAL_INSURANCE_NUMBER
Detects a Canadian Social Insurance number (SIN). This number is required for accessing government benefits and for employment verification.
COLOMBIA_INDIVIDUAL_TAX_ID_NUMBER_NIT
Detects a Colombian Individual Tax ID number, Numero De Identificacion Tributaria (NIT), a 10 digit identifier in the format NNN.NNN.NNN-N where the last digit is a verification digit.
COLOMBIA_PASSPORT_NUMBER
Detects a Colombian passport number. Add the Passport Image detector to detect an image or photo of the passport.
MEXICO_BUSINESS_TAX_ID_NUMBER_RFC
Detects a Mexican business tax payer id number, Registro Federal de Contribuyentes (RFC), a 12-character alphanumeric string used as a unique identifier for individual taxpayers.
MEXICO_INDIVIDUAL_TAX_ID_NUMBER_RFC
Detects a Mexican individual tax payer id number, Registro Federal de Contribuyentes (RFC), a 13-character alphanumeric string used as a unique identifier for individual taxpayers.
MEXICO_NATIONAL_ID_CARD_NUMBER
Detects a Mexican individual identification number (CURP, Clave Única de Registro de Población), an 18-character alphanumeric string used to identify individuals for government services, enrolling in schools, and obtaining official documents.
MEXICO_PASSPORT_NUMBER
Detects a Mexican passport number. Add the Passport Image detector to detect an image or photo of the passport.
US_DRIVERS_LICENSE_NUMBER
Detects US driver's license number, an alphanumeric string varying in a format unique to the issuing state.
US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER
Detects a US individual taxpayer identification number (ITIN)
US_PASSPORT
Detects a US passport number, typically a 6-9 character alphanumeric string.
US_SOCIAL_SECURITY_NUMBER
Detects US social security number (SSN), a 9-digit numeric string often used as a unique identification number for United States citizens and residents.
US_VEHICLE_IDENTIFICATION_NUMBER
Detects US vehicle identification number, a 17-character alphanumeric string used to identify a motor vehicle uniquely.
AUSTRALIA_DRIVERS_LICENSE_NUMBER
Detects an Australian driver''s license number: A 8-, 9-, or 10-digit number, or a 6-digit alphanumeric pattern depending on the issuing state or territory.
AUSTRALIA_MEDICARE_NUMBER
Detects an Australian Medicare number: A 10- or 11-digit alphanumeric code with a specific format and check algorithm used to uniquely identify individuals eligible for healthcare services under the Australian Medicare system. The 11th digit is the Individual Reference Number (IRN) and it’s optional.
AUSTRALIA_PASSPORT
Detects an Australian passport number, an 8- to 10-character alphanumeric string. Begins with one of these single letters (N,E,D,F,A,C,U,X) or one of these 2 letter combinations (RA,PA,PB,PC,PD,PE,PF,PU,PW,PX,PZ).
AUSTRALIA_TAX_FILE_NUMBER
Detects an Australian tax file number (TFN), a 9-digit numeric string with a specific format and check algorithm issued to identify individuals for AU tax purposes uniquely.
FRANCE_CNI
Detects a French CNI (carte nationale d’identité) number. A CNI is a national identifier frequently used when opening a bank account.
FRANCE_INSEE
Detects a France INSEE (National Institute of Statistics and Economic Studies) number, also known as the National Identification Number. An INSEE is composed of 13 digits + a two-digit key.
FRANCE_PASSPORT
Detects a France passport number, typically a 9-character alphanumeric string.
GERMANY_IDENTITY_NUMBER
Detects a Germany ID number. The German identity card, Personalausweis, is used as a national identifier.
GERMANY_PASSPORT
Detects a German passport number, typically a 9-character alphanumeric string.
INDIA_AADHAAR_INDIVIDUAL
Detects an India Aadhaar card number, 12 digit number issued to all Indian residents that include an individual's biometric and demographic data.
INDIA_PAN_INDIVIDUAL
Detects an Indian Permanent Account Number (PAN), a 10-character alphanumeric token.
IRELAND_PASSPORT
Detects an Ireland passport number, typically a 10-character alphanumeric string.
IRELAND_PPSN
Detects an Ireland Personal Public Service Number (PPSN), an 8-9 alphanumeric code.
SCOTLAND_COMMUNITY_HEALTH_INDEX_NUMBER
Scotland Community Health Index (CHI) number, a 10-digit number used for identification in Scotland's National Health Service (NHS).
UK_DRIVERS_LICENSE_NUMBER
Detects a UK driver's license number..
UK_ELECTORAL_ROLL_NUMBER
Detects a UK electoral roll number.
UK_NATIONAL_HEALTH_SERVICE_NUMBER
Detects a UK National Health Service number, a 10-digit number used for identification in the British National Health Service (NHS).
UK_NATIONAL_INSURANCE_NUMBER
Detects a UK National Insurance Number (NINO), a 9-character alphanumeric string. A NINO may also be used for tax purposes or other identification.
UK_PASSPORT
Detects a UK passport, a 9-digit number.
UK_TAXPAYER_REFERENCE
Detects a unique taxpayer reference (UTR) for individuals and entities paying taxes in the United Kingdom, typically a 10-digit number.
SPANISH_SOCIAL_SECURITY_NUMBER
Detects a Spanish Social Security Number (Número de la Seguridad Social).
Spanish National ID (DNI) Number
Detects a Spanish Documento Nacional de Identidad (DNI) number, a unique 9-character alphanumeric code assigned to all Spanish citizens.
CAMBODIA_NATIONAL_ID_NUMBER
Detects a Cambodian National ID number, a unique 9-digit number assigned to Cambodian citizens for identification purposes.
INDONESIA_DRIVERS_LICENSE_NUMBER
Detects an Indonesian Driver's License number, a 12- or 14-digit number issued to licensed drivers in Indonesia. The format and structure of the number may vary based on the issuing region.
INDONESIA_NATIONAL_ID_NUMBER
Detects an Indonesian National Identification Number (Nomor Induk Kependudukan, NIK), a unique 16-digit numeric code assigned to all Indonesian citizens and permanent residents.
MALAYSIA_NATIONAL_ID_NUMBER (MyKad)
Detects a Malaysian National ID (MyKad) number, a unique 12-digit numeric string assigned to Malaysian citizens for identification purposes. This ID is used in various legal, financial, and governmental transactions.
MYANMAR_NATIONAL_ID_NUMBER
Detects a Myanmar National ID number, a unique identification number issued to Myanmar citizens.
PHILIPPINE_DRIVERS_LICENSE_NUMBER
Detects a Philippine Driver's License number, a unique alphanumeric code assigned to licensed drivers in the Philippines.
PHILIPPINE_UMID (Unified multi-purpose ID)
Detects a Philippine UMID number, a unique 12-digit alphanumeric code used as a unified identification number for various government services and benefits in the Philippines.
SINGAPORE_DRIVERS_LICENSE_NUMBER
Detects a Singaporean Driver's License number, a unique alphanumeric code assigned to licensed drivers in Singapore.
SINGAPORE_NRIC_NUMBER
Detects a Singaporean NRIC number, a unique 9-character alphanumeric string used for identifying citizens and permanent residents of Singapore. Includes a validation character computed by a checksum algorithm, which we verify.
THAILAND_NATIONAL_ID_NUMBER
Detects a Thai National ID number, a unique 13-digit numeric string assigned to Thai citizens for identification purposes.
VIETNAM_NATIONAL_ID_NUMBER
Detects a Vietnamese National ID number, a unique identification number issued to citizens of Vietnam.
South Korean Driver's License Number
Detects a South Korean Driver's License number, a unique number assigned to licensed drivers in the South Korea.
South Korean Resident Registration Number (RRN)
Detects a South Korean Resident Registration Number, a unique 13-digit code issued to all residents of South Korea.
Southeast Asian Phone Number
Detects a phone number originating from Southeast Asia, typically formatted according to the national or regional numbering plans of countries within the region, such as Indonesia, Malaysia, Singapore, Thailand, and others.
Thai National ID Number
Detects a Thai National ID number, a unique 13-digit numeric string assigned to Thai citizens for identification purposes.
CANADA_BANK_ACCOUNT_NUMBER
Detects a Canadian bank account number, typically a 15-20 digit number.
AMERICAN_BANKERS_CUSIP_ID
Detects CUSIP (American Bankers Committee on Uniform Security Identification Procedures) codes, 9-character numeric or alphanumeric codes for identifying North American financial security.
CREDIT_CARD_NUMBER
Detects credit card numbers, 12-19 digit number used for payments and other monetary transactions.
IBAN_CODE
Detects International Bank Account Number (IBAN) codes defined under the ISO 13616:2007 standard used to identify an individual’s account.
SWIFT_CODE
Detects SWIFT (Society for Worldwide Interbank Financial Telecommunication) codes. A SWIFT code is an 8 or 11 alphanumeric identification code for banks used for financial transactions and other communications between banks. It is synonymous with a Bank Identifier Code (BIC).
US_BANK_ROUTING_MICR
Detects bank routing numbers, a 9-digit code used to identify a financial institution in monetary transactions. MICR stands for magnetic ink character recognition.
US_EMPLOYER_IDENTIFICATION_NUMBER
Detects a US employer identification number (EIN), also known as a Federal Tax ID number. An EIN is a unique identifier for US business entities.
PROTECTED_HEALTH_INFORMATION
FDA_NATIONAL_DRUG_NAME
Detects brand and non-proprietary FDA drug names.
ICD10_CODE
Detects ICD10 codes (International Classification of Diseases, Tenth Revision). ICD10 is a series of codes used by medical practitioners to identify diagnoses and procedures.
ICD10_DIAGNOSIS_DESCRIPTION
Detects ICD10 diagnoses or procedures.
US_HEALTH_INSURANCE_CLAIM_NUMBER
Detects a US healthcare national provider identifiers (NPI), a 10-digit identifier for US Medicare providers, individuals (physicians, dentists, pharmacists, etc.) and organizations (hospitals, clinics, pharmacies, etc.).
US_HEALTHCARE_NPI
Detects US health insurance claim number (HCIN), used as a Medicare identifier.
US_MEDICARE_BENEFICIARY_IDENTIFIER
Detects a US Medicare Beneficiary Identifier (MBI), an 11-character alphanumeric string given to all Medicare recipients and used in Medicare transactions.
IMEI_HARDWARE_ID
Detects an International Mobile Equipment Identity (IMEI) ID, a unique identification number programmed into GSM and UMTS mobile devices.
IP_ADDRESS
Detects an internet protocol (IP) network address. An IP address is a numerical label used to identify a device connected to a network. This detector supports both IPv4 and IPv6 addresses.
MAC_ADDRESS
Detects a MAC address, a 12-digit hexadecimal value used to identify a network adapter. MAC stands for Media Access Control.
API_KEY
CRYPTOGRAPHIC_KEY
DATABASE_CONNECTION_STRING
Detects a database connection string, an expression that contains the parameters required for the applications to connect to a database server. Supports most popular databases.
PASSWORD_IN_CODE
Detects passwords embedded in code and has been extended to detect those shared in natural language contexts, such as messages, sentences, and paragraphs. This detector is designed to identify user access credentials or login information to a system, providing comprehensive coverage across various formats. It aligns with the "Password" detector listed in the Nightfall console.
CREDIT_CARD_IMAGE
Detects an image of a credit, debit, or gift card from any institution.
DRIVERS_LICENSE_IMAGE
Detects an image of a driver's license and government-issued identification card from any nation.
PASSPORT_VISA_IMAGE
Detects an image of a passport or visa from any nation.
US_SOCIAL_SECURITY_CARD_IMAGE
Detects an image of a US social security card.
This stage is optional. This stage allows you to configure notification alerts, automated actions, and end-user actions. This stage has three components. Before we proceed further, you need to understand the following terms.
Admin: These are the users in your organization who work on Nightfall. These users configure integrations, create Policies, monitor Dashboards and Violations, and perform other actions in the Nightfall console. These users can be called Nightfall administrators.
End-User: These are the users who do not work on the Nightfall console but work on other SaaS applications in your organization. These users can be the members of your software development teams, QA engineers, network administrators, and so on. End-users are more prone to leaking sensitive data from your organization.
The Advanced Settings stage has the following components.
In this stage, you can configure notifications. The Nightfall admin receives the notifications configured in this stage. The various notification channels available are as follows.
Slack Alerts: You can configure Slack as a notification channel. When you configure Slack as an alert channel, admin users get a notification each time the policy has been violated. To learn more about configuring Slack as an alert channel in policies, see this document.
JIRA alerts: You can configure JIRA as an alert platform for policies. When the policy is violated a new JIRA ticket is created in the JIRA project of the JIRA instance selected by you and the Nightfall admin receives a notification in JIRA for the creation of the new ticket. You can refer to the Setting up Jira as an Alert Platform to learn more about using the alert platform.
Email Alerts: You can configure Email notifications and enter the Email IDs of the Nightfall admin users. The admin users receive an email when the policy is violated.
Webhook Alerts: You can configure Webhook as an alert platform. You can refer to this document to learn more about webhook configuration.
The Nightfall automated actions are neither performed by the Nightfall admin nor the end-users. They are triggered automatically when a violation is detected. Nightfall admin only needs to enable the automated actions. Automated actions are not present in all the integrations. Nightfall admins can either choose to trigger automated actions immediately when a Nightfall is detected or after some time.
The various automated actions are described as follows.
Redact: This action redacts the sensitive data that caused the violation. Admins can choose to implement this action either immediately when the violation is detected or after some time.
Delete Attachment: This action deletes the attachment that contains sensitive data. Admins can choose to implement this action either immediately when the violation is detected or after some time.
Remove Access: This action revokes public access to the page that contains sensitive information and makes it private or revokes page access to guest users (external users who are not part of your organization. Admins can choose to implement this action either immediately when the violation is detected or after some time.
As mentioned above, all the integrations do not have automated actions. Furthermore, not all the automated actions are supported by all the integrations. For instance, the Remove Access action is only present in the Notion integration.
The settings configured by the Nightfall admin in this stage send notifications to end-users (users whose actions triggered violation). Furthermore, end-users can also take remediation actions (human firewall) from within the notifications, provided the Nightfall admin configures the required settings.
This stage has the following configurations.
Custom Message: In this section, you can draft a custom 1000-character violation message to be sent to end-users. By default, Nightfall provides you with a violation message. You can use it or draft your custom message.
Automation: This section allows you to choose the notification channel through which the above message must be sent. Slack and email are some of the supported channels. The channels vary for each integration.
End-user Remediation (Human Firewall): In this section, Nightfall admins can configure remedial actions that end-users can take when they trigger a violation. The available actions vary for each integration. If end-users do not perform any of the remediation actions after triggering a violation, Nightfall admins can set reminders and also the frequency at which the reminders must be sent.
The alert methods you set up in the #admin-alerting and #end-user-notification sections apply only to the specific policy on which they are configured. To configure the alerts on all the policies of integration, you must set up the alerts at the integration level.
Learn more about the search operators provided by Nightfall, to filter Events.
This document describes all the operators provided by Nightfall to perform search operations on the Events page. You can use these operators to search for specific Events.
Nightfall provides you with two types of operators which are described in the following sections.
annotation_comment
This operator allows you to filter Events using the annotation comments.
annotation_type
confidence
This operator allows you to filter Events using the Confidence level which can either be Possible, likely, or Very Likely.
detection_rule_id
This operator allows you to filter Events using the unique detection rule ID.
detector_id
This operator allows you to filter Events using the unique detector ID.
file_name
This operator allows you to filter Events using the name of the file that triggered the violated
file_type
This operator allows you to filter Events using the type of file that triggered the violation.
integration_name
This operator allows you to filter Events using the integration name.
policy_id
This operator allows you to filter Events using the unique ID of the policy.
policy_name
This operator allows you to filter Events using the name of the policy.
post_context
pre_context
quote
This operator allows you to filter Events using the quote.
user_email
This operator allows you to filter Events using the email ID.
user_name
This operator allows you to filter Events using the name of the user who triggered the Event.
violation_id
This operator allows you to filter Events using the unique ID of the Event.
This operator allows you to filter violations using the Confluence page's parent page name in which the Event was discovered.
This operator allows you to filter Events using Confluence's space name in which the Event was discovered.
This operator allows you to filter Events using the Email ID of the GitHub user who triggered the Event.
This operator allows you to filter Events using the name of the GitHub branch in which the Event was triggered.
This operator allows you to filter Events using the GitHub commit ID in which the Event was discovered.
This operator allows you to filter Events using the GitHub organization name in which the Event was discovered.
This operator allows you to filter Events using the GitHub repository name in which the Event was discovered.
This operator allows you to filter Events using the name of the GitHub repository owner in which the Event was discovered.
This operator allows you to filter Events using the name of the JIRA project in which the Event was discovered.
This operator allows you to filter Events using the ticket number of the JIRA in which the Event was discovered.
This operator allows you to filter Events using the name of the user who created the notion page in which the Event was discovered.
This operator allows you to filter Events using the name of the user who last edited the notion page in which the Event was discovered.
This operator allows you to filter Events using the title of the page in which the Event was discovered.
This operator allows you to filter Events using the name of the Notion workspace in which the Event was discovered.
This operator allows you to filter Events using the ID of the Slack channel in which the Event was discovered.
This operator allows you to filter vEvents using the name of the Slack channel in which the Event was discovered.
This operator allows you to filter Event using the name of the Slack Workspace in which the Event was discovered.
This operator allows you to filter Events using the name of the channel in which the Event was discovered.
This operator allows you to filter Events using the channel type name in which the Event was discovered.
This operator allows you to filter Events using the name of the sender who triggered the Event.
This operator allows you to filter Events using the name of the team in which the Event occured.
This operator allows you to filter Events using the name of the current user who triggered the Event.
This operator allows you to filter Events using the name of the group to which the Event ticket is assigned.
This operator allows you to filter Events using the Zendesk ticket status.
This operator allows you to filter Events using the name of the Ticket.
Learn the process of informing and teaching users about Nightfall platform.
Cloud security is a team sport, and we recommend that you work within your broader organization to achieve understanding and buy-in for a successful DLP program.
Your organization’s users play a large role in keeping your organization safe from a DLP perspective - after all, they are the ones who are interacting with cloud applications to create and edit information every day. We recommend communicating with your broader organization during the early phases of implementing your new cloud DLP approach, so users are not caught off guard if they are involved in a violation that requires remediation. Transparent communication up front can go a long way toward mitigating users’ feelings of being “monitored” or “reprimanded.” See below for a template message you can send out company-wide.
Template for rolling out Nightfall to your business users:
Hi all,
[PRODUCT NAME: Slack, Google Drive, GitHub, Confluence, Jira] are integral to how we work together at [Company Name]. Many of us use [Product Name] regularly to collaborate and to be effective in our day to day work.
As [Company Name] continues to grow, it remains critically important to protect and secure the information that we share within and across products. Starting [Roll out date], we will begin using a data loss prevention tool called Nightfall which will monitor [Product Name] so that sensitive data (e.g. customer PII, employee personal data, or other forms of restricted data) is not shared or stored insecurely.
Why is this important?
Our customers require us to provide a high level of protection for any data that they provide to [Company Name]. When we share sensitive data, it should be through a secure cloud sharing solution and not across cloud applications that are not intended to house sensitive information.
What is sensitive or restricted data?
Sensitive or restricted data is a classification of information at [Company Name]. This data is often customer or employee personal data, including SSNs, credit card information, dates of birth, and credentials.
How does this impact you?
If you have access to sensitive or restricted data, please be mindful of where and with whom you share it in [Product Name]. Note that our security team may reach out to you to help with remediating any violations to ensure that our data is safe and secure.
If you have any questions, please reach out to [Security Team email]. Thanks for helping to keep [Company Name] secure!
We also recommend that you work closely with users as violations materialize, and take the opportunity to educate them or even involve them in remediation efforts. The end goal should be to reduce violations from occurring in the first place, with the DLP program functioning as a safeguard in case of slip ups. Coaching and education are the true foundations to reduce DLP violation occurrences, and by empowering end users to be active participants, you can also reduce some of the follow up actions needed from your team.
There are two aspects to this:
Real-time training as violations arise
Regular best practices training and content
When violations come up, the best practice is to contact the user upon review and let them know that the sensitive information was flagged and ask them to remediate the violation for the company’s security.
Template for flagging a violation to a user:
Hi [Name],
We noticed you shared content that may contain sensitive information in Slack at this link: [insert link]. Did you intend to send this message? If not, could you please delete it? We would like to ensure security best practices to ensure [Company Name] has the strongest security posture for our data.
Thanks!
Hi [Name],
We noticed this file you shared [externally] in Google Drive may contain sensitive information: [insert link]. Did you intend to share this with the external parties? If not, can you help adjust the sharing settings to be "Restricted" or to "Users in our organization only"? We would like to ensure security best practices to ensure [Company Name] has the strongest security posture for our data.
Thanks!
To communicate best practices more broadly, we would recommend reviewing the top violations found by Nightfall and identifying the best way for users to resolve or avoid those violations.
Template for communicating best practices to the company:
Hi all,
A few weeks ago, the Security team implemented a data loss protection tool called Nightfall, which detects sensitive information shared between users on [Product].
To date, Nightfall has scanned [XXX] messages that detected sensitive information not authorized for sharing via [Product]. This baseline data highlights a few trends that violate our security policies.
We’d like to remind everyone to follow the below security protocols and secure sharing practices:
Customer PII and employee personal data should never be shared over [Product].
[insert key security protocols and best practices for sharing at your company; examples below]
Example: Passwords of any kind must be stored in [1Password/LastPass/RPass] or another secure password vault.
Example: Passwords should be complex and unique. Use [1Password/LastPass/RPass]’s password generator to generate random string passwords - not “Acme123!” or passwords without sufficient randomness.
Example: Passwords should never be posted in a shared document.
Example: API Authentication tokens (e.g., Basic, Bearer) or Private Keys are effectively passwords and should never be stored or sent in plain text.
If you are aware of sensitive information that could be mishandled, or you’d like help share sensitive information in a safe and secure way, please reach out to [security@acme.com].
Thank you for always keeping [Company Name] secure!
HIPAA Compliance
Use the Protected Health Information (PHI) detector
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
Depending on the type of healthcare organization, disclosure of personal information may disclose PHI (e.g., a sufficiently uniquely named person going to a health provider like an AIDS clinic would likely disclose the person’s PHI).
PCI Compliance - Text
Use the Credit Card Number
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
For greater rigor, set on each of your locale’s detection rules alongside the Person Name detector configured to trigger with All Detectors, per:
PCI/PII Compliance - Images
Use the Drivers License Image, Passport Image, US Social Security Image, Credit Card Image detectors
Set Minimum Confidence level to Very Likely
Set alert to trigger on Any Detectors
These detectors analyze the layout and formatting of content within images, accurately identifying government-issued ID documents from any nation and payment cards from any institution.
ACH Compliance
Use the US Bank Routing and Person Name detectors
Set Minimum Confidence level to Likely
Set alert to trigger on All Detectors
GLBA Compliance
Use the SWIFT and US Bank Routing detectors
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
ISO 27001 Compliance for v2022
Enable all Secrets detectors:
API key
Cryptographic key
Database Connection String
GCP credentials
Password in code
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
Organizations may need to protect specific data types either by contractual obligation or to protect intellectual property. These are the recommended configurations to protect these data types.
Protected Health Data
Use the detector
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
Depending on the type of healthcare organization, disclosure of personal information may disclose health status (e.g., a sufficiently uniquely named person going to a health provider like an AIDS clinic would likely disclose the person’s PHI).
Secrets & Credentials
Enable all :
API key
Cryptographic key
Database Connection String
GCP credentials
Password in code
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
Banking / Financial Transactions
Select applicable
Set Minimum Confidence level to Likely
Set alert to trigger on Any Detectors
Learn how to create a File Type detector in Nightfall.
A File Type detector allows you to select MIME (multi-purpose mail extension) types. The selected MIME types are considered as tokens and Nightfall scans your data to identify if there is anything that matches the MIME token. If a match is found, it is flagged as sensitive data.
To create a File Type Detector:
Navigate to the Detectors section from the left pane.
Click + Custom Detector and select File Type.
Enter a name for your custom Detector in the Name field.
(Optional) Enter a description for the Detector in the Description field.
Click Add File Type and select an MIME type.
(Optional) Repeat step 3 to add multiple MIME types to your rule.
(Optional) Click the delete icon to delete an MIME type, if you do not require it.
Click Add.
Learn how to create a Dictionary detector in Nightfall.
A dictionary detector can detect a specific piece of sensitive data (referred to as a token). The token can be any type of sensitive data like a password, API key, IP address, PII, and so on. You must add the token to a file and then upload the file while creating the dictionary. Nightfall scans your data to check if the token present in the uploaded file exists in your data. If a match is found, it fis flagged as sensitive data exposure.
To create a Dictionary Detector:
Navigate to the Detectors section from the left pane.
Click + Custom Detector and select Dictionary.
Enter a name for your custom Detector in the Name field.
(Optional) Enter a description for the Detector in the Description field.
Upload or drag and drop the text file which contains a token.
(Optional) Select the Match substrings check box to match the sub-strings of the text file.
Click Add.
Learn how to create custom detectors in Nightfall.
Nightfall allows you to create custom detectors that match your organization's requirements. If none of the existing Nightfall detectors match your requirements, you can use this option to create a custom detector.
Nightfall provides you with four types of custom detectors.
Dictionary: This Detector allows you to upload a text file. The text file must have a specific token which is sensitive data for your organization. The Detector looks for this token in all the data and if a match is found, it flags it as sensitive data found.
File Type: This Detector allows you to select a MIME (Multipurpose Internet mail extension). (roughly speaking, every file on the Internet is recognized by its format which is called MIME). The Detector scans all your data to check if it has a file with the selected MIME type.
File Fingerprint: This Detector accepts a file as input. You can add all the content that you feel is sensitive to your organization. The detector uses this file as the base and scans your data to check if any matching content is present. If found, it flags it as sensitive data.
Regular Expression: This Detector allows you to define regular expressions matching the RE2 syntax. The Detector scans all your data to find any content that matches the regular expression. If found, it flags it as sensitive data.
Extend a Nightfall Detector: This Detector type allows you to customize an out-of-the-box Detector by defining Context Rules and Token rules.
Apart from the above custom Detectors, you can also use the Request a new detector option to request an entirely new custom Detector created by Nightfall.
To view only custom detectors created by you, click the CUSTOM filter in the left pane.
To learn more about how to create each of the custom detectors, you can refer to the following documents.
Learn how to create a File Fingerprint detector in Nightfall.
A File Fingerprint detector allows you to upload a file. You must enter the exact data that is sensitive to your organization, in this file. Nightfall scans your data to check if there is an exact match between the contents of the uploaded file and your organization's data. If a match is found, it is flagged as sensitive data.
To create a File Fingerprint Detector:
Navigate to the Detectors section from the left pane.
Click + Custom Detector and select File Fingerprint.
Enter a name for your custom Detector in the Name field.
(Optional) Enter a description for the Detector in the Description field.
Upload or drag and drop the text file whose content needs to be matched.
Click Add.
In this stage, you select an integration for which the policy is being created.
To select an integration:
Click Policies from the left menu.
Click + New Policy.
Select Sensitive Data.
Select the integration for which you wish to create the policy.
Based on the integration selected, the options vary in the upcoming policy stages.
Learn the process of creating detection rules in Nightfall.
As described in the Nightfall Detection Platform once you have finalised the the Detectors to be used or created custom detectors which leverage your organization's sensitive data security requirements, you must add the detectors to a detection rule and then add the detection rule to a policy. You cannot use detectors directly. Detectors become useful only when you add them to a Detection rule and then add the detection rule to a policy.
You can add multiple detectors to a single detection rule. Nightfall does not restrict you on the type of detector that can be added to a detection rule. You can add both, a custom detector and a Nightfall detector to the same detection rule.
You can create multiple detection rules to detect different types of sensitive data. For example, you can add the Password detector to a Detection rule and use it to detect password leaks. You can add the API key detector to another detection rule and use it for detecting API key leaks.
Once you add all the required detectors to the detection rule, Nightfall allows you to test the detection rule in the Nightfall Playground. You can use the Nightfall playground only for testing if the detection rule works as expected. Once you confirm that the detection rule works as expected, you must add the detection rule to policy to leverage your data security requirements. Conversely, you can also have a single detection rule in which you add both Password and API key detectors.
You can access the Detection rules page by clicking Detection from the left pane and then clicking Detection Rules. To create a new Detection rule, you must click the + New Detection Rule button the top right corner.
If you wish to get guidelines from Nightfall on what detectors must be included in your detection rules, refer to the Detection Rules document.
You can add a Detector to the Detection rule by executing the following steps.
Click the + New Detection Rule button the top right corner.
Enter a name for the detection rule in the Name field.
(Optional) Enter a description for the detection rule in the Description field.
Click + Add Detectors to add detectors to the detection rule.
Select the check box for the detectors that you wish to add to the detection rule. You can use the filters to view only the Nightfall detectors or the custom detectors or the search bar to search detectors.
Click Add.
You can see that the selected detectors are added to the detection rule. In the following image two detectors have been added to the Detection rule.
Once you add the required detectors to the detection rules, you can se that there are three columns; Scope, Minimum Confidence, and Minimum # of Findings. These settings define the weightage of the detector in the detection rule. You must configure these settings for each detector.
These settings are explained in the following sub-sections.
The Scope setting allows you to define which part of the data the detector must scan. You can configure this setting to scan either the name of the file, the contents of the file or both.
If you select the Content option, this detector only scans the content of the files and not the name of the file, and vice versa, if you select File Name. However, if you select Both, the detector scans the file name as well the contents of the file.
For example, if the API key detector has to scan a Google Drive file and if you select, File Name, then the detector only scans the name of the file to check if the name has any API key. Similarly, if you select Content, then the detector only scans the content of the file and not the name. If you select Both, then the detector scans both; the name and the contents of the file.
Important
If you wish to scan content that is not part of any file, you must either select the Content or Both option.
For example, if you wish to scan direct messages or group messages from Slack or MS Teams, these messages are not part of any files. In such cases, if you select the File Name option, the detector does not detect any violation because it considers direct messages as Content not part of any file. Hence to scan such types of content you must select either Content or Both options.
The minimum confidence setting defines the probability of a detector's findings being actual violations. Nightfall provides you with three Minimum Confidence settings; Possible, Likely, and Very Likely.
The Possible option indicates that there is a 40-60% chance of the Detector's finding being an actual case of data leak, Similarly, the Likely option indicates that there is a 61-80% chance of the Detector's finding being an actual case of data leak. The Very Likely option indicates that there is a 81-100% chance of the Detector's finding being an actual case of data leak.
You can set the Minimum Confidence setting for each detector. When the detector detects any data leak, it is logged in the Sensitive Data Protection Events page with the Minimum Confidence setting configured here.
This setting defines the minimum number of data leak cases that a detector must encounter for it to be considered as a Violation by the Detection rule. You must configure this setting for each detector. For example, if you set this setting to 10, the detection rule does not consider the first 9 occurences of data leak encountered by the detector. Detection engine starts considering the 10th and all subsequent cases of data leak to be actual case of violations.
If a detection rule has a single detector and if that detector detects a data leak, the detection rule is triggered and it is logged as a Finding.
However, when you have multiple detectors in detection rule, you can choose to trigger the detection rule when any of the detector detects a data leak or when all the detectors detect a data leak.
As you can see in the above image, you can choose the flag a Finding of the detection rule either when any single detector detects a data leak or when all the detectors of the detection rule detect a data leak.
The above image has two detectors. The following statements hold good.
The Scope of both the detectors is set to scan the file content and file name.
When any of these detectors detect a data leak, it is logged as a Finding in the Violations page and tagged as Very Likely.
The minimum number of findings for each detector is 1. So even if there is a single case of a data leak, a detector rule considers it as a finding.
The detection rule is triggered even if a single detector detects a data leak.
Once you create the detection rule, it is highly recommended that you test the rule to ensure that it returns the expected results, when added to policies. Nightfall provides you with a Playground to test the detection rules.
You must have an API key to use the Nightfall Playground. You can refer to this document to learn about how to create an API key.
You must have some sample data to test the Detection rule. This Nightfall document has various types of sample data sets that you can use.
Each Detection rule in Nightfall has a UUID. This is a unique ID assigned to each detector when it is created. You cannot edit the UUID of any detector. You must capture this UUID to use it in Playground to test the detection rule.
To capture Detection rule UUID:
Navigate to Detection rules.
Click the detection rule whose UUID has to be captured.
Click the UUID to copy it.
To use the Nightfall playground:
Navigate to the Nightfall playground.
Use either the I'm Scanning Text or I'm Scanning Files tab based on whether you wish to scan text or file.
Replace the existing sample data with your sample data in Step 1: Payload.
Skip Step 2: Pick Detection rule.
Expand Advanced Detection Settings (Optional)
Paste the Nightfall API key in the Nightfall API Key field.
Paste the Detection rule UUID in the Detection Rules field.
Click Start Scan.
If sensitive data is found in the sample data, the Findings section looks as shown in the following image.
Paste the file URL or upload the file in Step 1: Files to scan.
Enter the Email to which the scan results must be sent in the Step 2: Email field.
Skip Step 2: Pick Detection rule.
Expand Advanced Detection Settings (Optional)
Paste the Nightfall API key in the Nightfall API Key field.
Paste the Detection rule UUID in the Detection Rules field.
Click Start Scan.
This stage allows you to select detection rules to be included in the policy. The policy uses the detectors present in the detection rules to scan your data and check if there is any data leakage. You must include all the required detection rules in this section. You can select a maximum of 15 detectors in a single policy. You can use the search bar to search for a detection policy.
You must first select the required detection rule(s). Once you select the rule(s), you can set one of the following options.
All Detection Rules: This option displays all the detection rules in the policy, irrespective of the rules selected by you.
Selected Detection Rules: This option displays only those detection rules in the policy, that you have selected. If you move to the next stage, only the selected detection rules are included in the policy.
Unselected Detection Rules: This option displays only those detection rules that you have not selected. You can still select any of the detection rules and even those will be excluded from the policy.
In the following image, you can view the search bar in Detection rules. You can see that:
When you select the All Detection Rules option, all the rules are displayed.
When you select the Selected Detection Rules option, only those detection rules are displayed that you have selected and only these rules will be used in the policy.
When you select the Unselected Detection Rules option, only those detection rules are displayed that you have not selected. You can still select any of the detection rules and even those will be excluded from the policy.
Please find links to our Detection Platform FAQs below:
Customize finding confidence to suit your business logic
Context Rules are a way to tune detectors and increase their sensitivity by up-weighting or down-weighting detection of a sensitive finding based on its surrounding context. Contrary to Exclusion Rules, which will disqualify “tokens” or items from detection, Context Rules are a way to increase or decrease the Confidence Level in your detections if there are certain types of tokens, also known as “hot words”, that surround the sensitive token.
For example, let’s say you are detecting the Social Security Number “489-36-8350”. If you see “MyCo Test SSN is 489-36-8350” you may want to lower the Confidence Level of this alert because you know this is a test or invalid SSN. Alternatively if you see “MyCo Customer SSN: 489-36-8350” you may want to upweight this confidence level because you know that at your company SSNs are real when they are formatted in this way. In this way, Context Rules help adapt detectors to specific business context relevant to you.
Context Rules are based on a regular expression (a known pattern to match against, also known as a “regex”) that you can create. They follow RE2 syntax listed here. You can test your regular expression here.
Context Rules can be added to any detector (either pre-made by Nightfall or to your own custom regex). You can control how many characters surrounding a finding define its context, and adjust how the original confidence level is affected by this context.
Here’s how you can build your own Context Rule and attach it to a detector:
Enter a regex pattern for your context rule. If you wish the pattern to be case sensitive, check the box to the right of the input window.
Define the window to be considered as context by specifying the number of characters away to look for your regex pattern and whether to consider context before the discovered token, after it, or both.
Define the confidence adjustment for your context rule from the dropdown menu. If your context rule is triggered, the finding will automatically be adjusted to your selected confidence level.
Add your Context Rule to the detector by clicking the "Save" button in the lower right.
Exclude certain tokens from detection to suit your business logic
Exclusion Rules, also known as an allowlist, help you reduce false positives in your sensitive findings by ignoring content from detection, or “allowing” it to pass through without being flagged.
For example, let’s say you are using the Email Address detector and you don’t want any corporate domains of “@example.com” to be detected by Nightfall. You can add “*@example.com” as a regex Exclusion Rule.
You can add in a list of known safe tokens as a dictionary or craft a regular expression. A dictionary is a list of literal values, for example, a list of dummy credit card numbers or API keys. Regular expressions are known patterns to match against, for example if you want to allow all emails of a given domain as in the example above. Regular expressions follow RE2 syntax listed here. You can test your regular expression here.
Exclusion Rules can be added on to any detector (either pre-made by Nightfall or off your own custom regular expression or “regex”) to omit certain “tokens” or items from resulting in detection events.
Here’s how you can build your own Exclusion Rule and attach it to a detector:
Select the type of Exclusion Rule you would like to use. It can be either a dictionary of words (which may be entered manually or uploaded from a list) or a regex pattern.
Select the match type from the dropdown menu on the right, either Partial or Full match.
Append your Exclusion Rule to your custom detector by clicking the "Save" button in the lower right.
Regular expressions for unique situations
Nightfall provides detectors for the most common data protection use cases. For unique situations, you can build custom detectors using regular expressions.
Please double-check our Nightfall Detector Glossary before creating your own, including the API and cryptographic key detectors listed below, as regex detectors can introduce noise.
Nightfall's API key supports specific detection and validation of API keys for the top 50 vendors and use cases, as shown below.
• AWS
• Azure
• Confluence
• Confluent
• Datadog
• ElasticSearch
• Facebook • GCP
• Google API
• GitHub
• GitLab
• Hugging Face
• JIRA
• Nightfall
• Notion
• Okta
• OpenAI
• PagerDuty
• Paypal
• Plaid
• Postmark
• Postman
• Salesforce
• Sendgrid
• Slack
• Snyk
• Square
• Stripe
• Twilio
• Zapier
• Authentication Token
• CSRF Token
• OAuth Token
• Generic API Key
• Generic Token
• JWT
• Private Key
• Refresh Token
• Session Token
Nightfall's Cryptographic Key Detector
Nightfall's identifies popular keys for locking or unlocking cryptographic functions, including authentication, authorization, and encryption.
• DSA Private Key
• RSA Private Key
• EC Private Key
• OpenSSH Private Key
• Private Key
• Encrypted Private Key
• PGP Private Key Block
You can send us a request for new ML detectors directly in Nightfall.
Here is a list of regex detectors used by other Nightfall customers.
google_two_factor_backup
^(?:BACKUP VERIFICATION CODES|SAVE YOUR BACKUP CODES)[\s\S]{0,300}@$
Credentials
heroku_key
^(heroku_api_key|HEROKU_API_KEY|heroku_secret|HEROKU_SECRET)[a-z_ =\s"'\:]{0,10}[^a-zA-Z0-9-]\w{8}(?:-\w{4}){3}-\w{12}[^a-zA-Z0-9\-]$
Credentials
MailGun API Key
^key-[0-9a-zA-Z]{32}$
Credentials
microsoft_office_365_oauth_context
^https://login.microsoftonline.com/common/oauth2/v2.0/token|https://login.windows.net/common/oauth2/token$
Credentials
PayPal Braintree Access Token
^access_token\$production\$[0-9a-z]{16}\$[0-9a-f]{32}$
Credentials
Picatic API Key
^sk_live_[0-9a-z]{32}$
Credentials
ECDSA Private Key
^-----BEGIN ECDSA PRIVATE KEY-----\s.*,ENCRYPTED(?:.|\s)+?-----END ECDSA PRIVATE KEY-----$
Credentials
KeePass 1.x CSV Passwords
^"Account","Login Name","Password","Web Site","Comments"$
Credentials
KeePass 1.x XML Passwords
^<pwlist>\s*?<pwentry>[\S\s]*?<password>[\S\s]*?<\/pwentry>\s*?<\/pwlist>$
Credentials
Password etc passwd
^[a-zA-Z0-9\-]+:[x|\*]:\d+:\d+:[a-zA-Z0-9/\- "]*:/[a-zA-Z0-9/\-]*:/[a-zA-Z0-9/\-]+$
Credentials
Password etc shadow
^[a-zA-Z0-9\-]+:(?:(?:!!?)|(?:\*LOCK\*?)|\*|(?:\*LCK\*?)|(?:\$.*\$.*\$.*?)?):\d*:\d*:\d*:\d*:\d*:\d*:$
Credentials
MailChimp API Key
^[0-9a-f]{32}-us[0-9]{1,2}$
Credentials
PGP Header
^-{5}(?:BEGIN|END)\ PGP\ MESSAGE-{5}$
Credentials
PKCS7 Encrypted Data
^(?:Signer|Recipient)Info(?:s)?\ ::=\ \w+|[D|d]igest(?:Encryption)?Algorithm|EncryptedKey\ ::= \w+$
Credentials
PuTTY SSH DSA Key
^PuTTY-User-Key-File-2: ssh-dss\s*Encryption: none(?:.|\s?)*?Private-MAC:$
Credentials
PuTTY SSH RSA Key
^PuTTY-User-Key-File-2: ssh-rsa\s*Encryption: none(?:.|\s?)*?Private-MAC:$
Credentials
Samba Password config file
^[a-z]*:\d{3}:[0-9a-zA-Z]*:[0-9a-zA-Z]*:\[U\ \]:.*$
Credentials
SSH DDS Public
^ssh-dss [0-9A-Za-z+/]+[=]{2}$
Credentials
SSH RSA Public
^ssh-rsa AAAA[0-9A-Za-z+/]+[=]{0,3} [^@]+@[^@]+$
Credentials
SSL Certificate
^-----BEGIN CERTIFICATE-----(?:.|\n)+?\s-----END CERTIFICATE-----$
Credentials
Lightweight Directory Access Protocol
^(?:dn|cn|dc|sn):\s*[a-zA-Z0-9=, ]*$
Credentials
Arista network configuration
^via\ \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3},\ \d{2}:\d{2}:\d{2}$
Network
John the Ripper
^[J,j]ohn\ [T,t]he\ [R,r]ipper|john-[1-9].[1-9].[1-9]|Many\ salts:|Only\ one\ salt:|openwall.com/john/|List.External:[0-9a-zA-Z]*|Loaded\ [0-9]*\ password hash|guesses:\ \d*\ \ time:\ \d*:\d{2}:\d{2}:\d{2}|john\.pot$
Network
Huawei config file
^sysname\ HUAWEI|set\ authentication\ password\ simple\ huawei$
Network
Metasploit Module
^require\ 'msf/core'|class\ Metasploit|include\ Msf::Exploit::\w+::\w+$
Network
Network Proxy Auto-Config
^proxy\.pac|function\ FindProxyForURL\(\w+,\ \w+\)$
Network
Nmap Scan Report
^Nmap\ scan\ report\ for\ [a-zA-Z0-9.]+$
Network
Cisco Router Config
^service\ timestamps\ [a-z]{3,5}\ datetime\ msec|boot-[a-z]{3,5}-marker|interface\ [A-Za-z0-9]{0,10}[E,e]thernet$
Network
Simple Network Management Protocol Object Identifier
^(?:\d\.\d\.\d\.\d\.\d\.\d{3}\.\d\.\d\.\d\.\d\.\d\.\d\.\d\.\d\.\d{4}\.\d)|[a-zA-Z]+[)(0-9]+\.[a-zA-Z]+[)(0-9]+\.[a-zA-Z]+[)(0-9]+\.[a-zA-Z]+[)(0-9]+\.[a-zA-Z]+[)(0-9]+\.[a-zA-Z]+[)(0-9]+\.[a-zA-Z0-9)(]+\.[a-zA-Z0-9)(]+\.[a-zA-Z0-9)(]+\.[a-zA-Z0-9)(]+$
Network
Bank of America Routing Numbers - California
^(?:121|026)00(?:0|9)(?:358|593)$
Finance
BBVA Compass Routing Number - California
^321170538$
Finance
Chase Routing Numbers - California
^322271627$
Finance
Citibank Routing Numbers - California
^32(?:11|22)71(?:18|72)4$
Finance
USBank Routing Numbers - California
^12(?:1122676|2235821)$
Finance
United Bank Routing Number - California
^122243350$
Finance
Wells Fargo Routing Numbers - California
^121042882$
Finance
SWIFT Codes
^[A-Za-z]{4}(?:GB|US|DE|RU|CA|JP|CN)[0-9a-zA-Z]{2,5}$
Finance
CVE Number
^CVE-\d{4}-\d{4,7}$
General
Dropbox Links
^https://www.dropbox.com/(?:s|l)/\S+$
General
Box Links
^https://app.box.com/[s|l]/\S+$
General
Large number of US Zip Codes
^(\d{5}-\d{4}|\d{5})$
General
MySQL database dump
^DROP DATABASE IF EXISTS(?:.|\n){5,200}CREATE DATABASE(?:.|\n){5,200}DROP TABLE IF EXISTS(?:.|\n){5,200}CREATE TABLE$
Database
MySQLite database dump
^DROP\ TABLE\ IF\ EXISTS\ \[[a-zA-Z]*\];|CREATE\ TABLE\ \[[a-zA-Z]*\];$
Database
If you need help with regexes or have regexes you'd like to share, please reach out to support@nightfall.ai.
Filter Nightfall Events based on parameters.
You can filter Events based on several parameters, to view violations that occurred:
During specific time periods. You can filter based on pre-set time ranges of last 7 days, 30 days, 90 days and 180 days,
Integration - the application that is being monitored by Nightfall.
Detector - the detector that you selected as part of your policies to monitor.
Likelihood - the confidence level of the detection by Nightfall.
Status - the current current status of the violation
User - the user associated to the violation
To filter violations,
Select a Filter.
Select an Option. You can select one or many options.
Click Apply. The filtered list of violations displays.
Note: Nightfall offers additional monitoring capabilities to meet various monitoring needs. You can learn more about using email, Slack and other monitoring options using our supported alerts destinations including alerting to http endpoints using webhook alerts.
Learn about the Events page in Nightfall
An Event is an incident that is triggered when a data leak is detected by Nightfall. The Data Sensitive Events page displays all the details about the data sensitive events recorded in Nightfall from all the integrations.
Before we proceed further, let's understand what exactly is a Finding and a Event.
Finding: A Finding refers to a single instance of a data leak incident detected during scanning.
Event: An Event is an incident of data leaks, and a collection of findings that were detected while scanning an entire document or data in your database.
When Nightfall scans data, a single Event can have multiple findings. For instance, consider that you upload a document to Google Drive. This document has 10 instances of secret information (10 API keys or 10 credit card numbers). These 10 instances are known as Findings. Since Nightfall scans the entire Google document at once, these 10 Findings are recorded as a single Event.
The sensitive data Event list view page consists of a table that displays the details of each Event. The contents consist of columns which are described as follows.
Finding
The finding displays the name of the Detector that was violated. As a result of this violation, an Event was created. A single Event entry can have multiple findings.
When
The time elapsed (either in hours, days, weeks, months) since the Event was recorded. You can arrange this in increasing or decreasing order.
Integration
The integration in which the Event was recorded.
Policy & Rule
The policy and rule names that were violated.
Risk
User
The user whose actions triggered the Event (finding).
Status
The current status of the Event. You can hover on the status to view the user who triggered the current status and the date and time when the current status was reached.
Ellipsis menu
The Finding column displays the name of the detector whose condition was violated thus resulting in the generation of the Event. The Finding column displays a list of Events that originated from scanning a single file, a web page, or any other publicly available entity.
Each Event's name is the same as the Detector's name whose condition was violated. You can also view the Likelihood or confidence level (Possible, Likely, Very Likely) of an Event being an actual case of data leak and also the number of instances for each Likelihood. The Possible Likelihood Findings are displayed in blue color with a fully dotted blue circle. The Likely Finding is displayed in yellow color with a half-dotted and half-shaded yellow circle. The Very Likely Finding is displayed in red color with a red circle.
For instance, in the following image, a detector called Person name violated 28 times. Of these 28 instances of violations, 1 is Possible Event (in blue), 5 are Likely Events (in yellow), and 22 are Very Likely Events (in red).
The Event detail view consists of various sections. These sections are as follows.
Each field is highlighted and a number is associated with the highlighted field. Using the number, you can refer to the section that follows the image to learn more about the field associated with that number.
1 - Name of the Event
2 - Current Status of the Event. For more information on Event status, refer to the Event Status document.
3 - The nature (Credit card in the above image) and number of Findings (1 in the above image) in the Event.
4 - The name of the document in which the sensitive data was found (TEst Automation Action.Docx in the above image). If there are multiple documents that contain sensitive data, each document is listed here. However, in this case only one document contained sensitive data.
5 - The actual sensitive data found in the document (4242-4242-4242-4242 in the above image). The sensitive data is highlighted in yellow which indicates the Likelihood is Likely. Findings whose Likelihood are Very Likely are highlighted in red and Findings with Likelihood of Possible are highlighted in blue. For more information on Likelihood, see #working-on-eventsdocument.
6 - Number of Findings in the selected document. In the above case there is only one finding and it has a Likelihood is Possible.
The contents of this section vary for each integration. You can view the complete list of fields available in the second section after you click the Expand Details button.
The following section contains tabs for each integration. Each tab represents an integration and contains an image of the second section followed by the description of each fields.
The second section of the OneDrive detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (OneDrive in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name(s) of the policy/policies that was violated and as a result of which the Event was triggered.
Detection rule - The name(s) of the detection rule(s) within the policy that was violated.
Last modified by - The name of the user who was the last person to act on the Event.
Last modified time - The date and time when the Event was last modified.
File name - The name of the file that contains sensitive data.
OneDrive ID - The ID of the OneDrive that contains the file holding sensitive data. This field is only available for OneDrive Events.
OneDrive Owner - The name of the user who owns the OneDrive containing file(s) with sensitive data. This field is only available for OneDrive Events.
Size - The size of the file that contains sensitive data.
The second section of the Google Drive detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Google Drive in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name(s) of the policy/policies that was violated and as a result of which the Event was triggered.
Detection rule - The name(s) of the detection rule(s) within the policy that was violated.
Type - The type of the document in which sensitive data exists.
Size - The size of the document in which sensitive data exists.
Link Permissions - The link permissions of the file in which the sensitive data exists.
Viewers can Download - This is a boolean field (Yes/No) which indicates whether users can download the file that contains sensitive data.
File Owner - The email ID of the user who owns the file that contains sensitive data.
In Trash - This is a boolean field (Yes/No) which indicates whether file that contains sensitive data is moved to trash or not.
Date Created - The date and time when the file containing sensitive data was created.
Date Last Modified - The date and time when the file containing sensitive data was last modified.
Shared Drive Name - The name of the shared drive in which the file containing sensitive data resides.
Shared With - Internal - The list of internal users with whom the file is shared.
Shared With - External - The list of internal users with whom the file is shared.
Last Edited By - The email ID of the user who last edited the file that contains sensitive data.
The second section of the JIRA detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (JIRA in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Event Type - The type of the event.
Project Name - The name of the project that contains the ticket with sensitive data.
Project Type - The type of the project that contains the ticket with sensitive data.
Ticket Number - The ID of the ticket that contains the ticket with sensitive data.
Site - The URL of the JIRA site that contains the ticket with sensitive data.
The second section of the Confluence detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Confluence in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Item Name - The name of the Confluence entity that contains sensitive data.
Site - The link to the Confluence site that contains sensitive data.
Item Type - The type of the item that contains sensitive data.
Is Archived - This is a boolean field (Yes/No). It states if the Confluence entity containing sensitive data is archived or not.
Date Created - The date and time when the Confluence entity containing sensitive data, was created.
Date Last Modified - The date and time when the Confluence entity containing sensitive data, was last modified.
Labels - The Labels attached to the Confluence entity containing sensitive data, was last modified.
Space Name - The name of the Confluence space that contains sensitive data.
Author Name - The name of the user who created the Confluence entity containing sensitive data.
Author Email - The Email ID of the user who created the Confluence entity containing sensitive data.
The second section of the Confluence detail view is as shown in the following image. The image The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Salesforce in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Object Name - The name of the Salesforce Object that contains sensitive data.
Record - The unique Record ID of the row that contains sensitive data.
Content Type - The format of the file that contains sensitive data.
Event Type - The type of the event that resulted in sensitive data creation.
User - The name of the User who added sensitive data.
Organization ID - The Org ID of the Salesforce org that contains the sensitive data.
Organization Type - The nature of the Salesforce org (Production/Sandbox) that contains the sensitive data.
Organization Name - The name of the Salesforce org that contains the sensitive data.
Modified At - The date and time when the record containing sensitive data was last modified.
The second section of the Gmail detail view is as shown in the following image. The image The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Gmail in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Send Date - The date and time when the Email containing sensitive data was sent.
Subject - The Subject line of the Email that contains sensitive data.
From - The Email ID of the user who sent the Email that contains sensitive data.
To - The Email ID(s) of the recipient user who received the Email that contains sensitive data.
Cc - The Email ID(s) of the user(s) who were included in the CC field of the Email that contains sensitive data.
Bcc - The Email ID(s) of the user(s) who were included in the Bcc field of the Email that contains sensitive data.
Thread ID
The second section of the Zendesk detail view is as shown in the following image. The image The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Zendesk in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Ticket ID
Ticket Title
Date Created
Date Updated
User Role
Zendesk instance
Ticket Requestor
Group assignee
Agent Assignee
Event Type
Ticket Type
Ticket Priority
Ticket Status
Ticket Followera
The second section of the GitHub detail view is as shown in the following image. The image The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Confluence in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Commit Date - The date and time when the code containing sensitive information was committed.
Organization - The name of the GitHub organization that contains the code containing data.
Branch - The GitHub branch that contains the code which has sensitive data.
Repository - The GitHub Repository name that contains the code which has sensitive data.
Repository Type - The nature of the repository that contains the code which has sensitive data.
The second section of the Notion detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Confluence in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Workspace - The link to the Notion Workspace that contains sensitive data.
Page - The link to the Notion Page that contains sensitive data.
Page Created Date - The date and time when the Notion page containing sensitive data was created.
Last updated Date - The date and time when the Notion page containing sensitive data was last modified.
Created By - The name of the user who created the Notion page containing sensitive data.
Last Edited By - The name of the user who last edited the Notion page containing sensitive data.
Location - The location of the sensitive data.
Page ID - The unique ID of the Notion page containing sensitive data.
Shared Externally - This is a Boolean field (Yes/No) in dicating if the Notion page containing sensitive data is shared externally or not.
The second section of the MS Teams detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Confluence in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
Team Name - The name of the team that contains sensitive data.
Team ID - The unique ID of the team that contains sensitive data.
Channel Name - The name of the Channel that contains sensitive data.
Channel Membership - The membership of the Channel that contains sensitive data.
Creation Time - The date and time when the channel containing sensitive data was created.
From - The Email ID of the user who sent the message containing sensitive data.
Message Priority -
Last Edit Time - The date and time when the message was last edited.
Chat Participants -
The second section of the Slack detail view is as shown in the following image. The section after the image describes each field.
The various fields in the above section are as follows.
Actions Taken - The latest action taken on the Event. If no action is taken yet, this field is empty.
When - The time period when the Event was registered.
Integration Name - The Nightfall integration in which the Event was registered (Confluence in this case).
User - The user whose actions triggered the Event.
Violated Policy - The name of the policies that was violated and as a result of which the Event was triggered.
Detection rule - The name of the detection rule(s) within the policy that was violated.
File Name - The name of the file that contains sensitive data.
File Type - The type of the file that contains sensitive data.
Location - The name of the channel that contains sensitive data.
Channel Type - The type of the channel that contains sensitive data.
Members - The number of members that are present in the Channel.
The third section contains Event logs and comments. These sections are highlighted in the following image.
Event logs - The event logs section contains a log of activities performed on the Event. By default, the first log activity recorded is the Event creation activity. The next set of activities generally provide information about Event notifications sent via various notification channels and actions taken on the Event.
Comments - The comments section allows you to enter comments on the Event. The maximum character limit for the comment is 300.
If a single scanned entity (file or web page) violates multiple detector rules, Nightfall displays the list of all the detectors that the finding has violated. Such Events are displayed with a detector name, followed by a +1 (if two detectors are violated), +2 (if three detectors are violated), and so on, on the Event List view.
In the following image, you can see that the Finding has violated a detector called Credit card number and also another detector. Hence a +1 is displayed.
In the above case, if the Finding violated three detectors, +2 is displayed. If the Finding violated 4 detectors, +3 is displayed.
To view the list of detectors violated and the Likelihood (Possible, Likely, and Very Likely) of each finding discovered in the file, click the Event. This opens the Event detail view. You can view the names of the violated detectors and the number of findings on the Event detail view.
In the following image, a single file Automated upload 1728418320 has violated three detectors. The detectors are Person name, Tom Cruise with Exclusions and Phone number. The Person name detector has been violated 22 times and hence there are 22 findings for this detector. You can view each of these 22 instances of findings by clicking the 22 Person name tab and scrolling down. The findings that are highlighted in Blue are Possible findings, findings highlighted in Red are Most Likely findings, and the findings highlighted in yellow are Likely findings. There is a Showing field which displays the number of Findings and the likelihood of each finding. In the following image, the Showing field displays 22 in red. It implies that all 22 findings have the Most Likely likelihood.
The Tom Cruise with Exclusions detector has 3 findings. You can view the Likelihood of each of the 3 findings. You can view the findings that violated this detection rule by clicking the 3 tom cruise with exclusions tab.
Similarly, you can click the 3 Phone Number to view the details of the findings that violated the Phone number detector.
As learned above, a Event can have multiple findings. If you find that any of the findings discovered by Nightfall is not an actual case of data leak, you can use the Annotate feature to annotate the specific finding as a false positive. Furthermore, you can also annotate those findings, which surely are a case of data leak, as true positives. Each finding has the annotate option.
To annotate a finding:
Hover the mouse on the finding that you wish to annotate.
Click the annotation icon.
Select one of the following annotation options.
Not a Credit card number: Select this option if you feel that the Credit card number discovered by Nightfall is not a credit card number but some other number. This marks the finding as a False positive.
Not a violation: Select this option if you feel the finding discovered by Nightfall is not a violation (an imaginary credit card number shared publicly as an example). This marks the finding as a False positive.
True Positive: Select this option if you feel that the finding discovered by Nightfall is an actual case of data leak. This marks the finding as True positive.
(Optional) Enter comments for annotation.
(Optional) Turn the Apply to all identical findings toggle switch to annotate all the similar findings. Click #bulk-annotate to learn more about this feature.
Click Apply.
In step 3, of the above task, you see three options for annotation. The name of the first option depends on the nature of the Finding. For instance, if the sensitive data found is a suspected API key, the option name changes to Not an API key. If it is a Personally Identifiable Information (PII), the option name changes to Not a Personally Identifiable Information, and so on.
When you annotate a finding as Not a credit card, Not an Address, and so on, or annotate a finding as Not a Violation, the Finding is displayed as False Positive on the Finding column. If you annotate a Finding as True Positive, it is displayed as True Positive on the Finding column.
In the following image, a Violation has 25 Very Likely Findings and 28 Possible Findings. We annotate a Very Likely Finding as True Positive and a Possible Finding as Not a Violation. You can see that the values are reflected accordingly. Findings annotated as True positive are displayed in green color and Findings annotated as False Positive are displayed in grey color.
The Finding column also reflects the latest data on each finding. You can view that Very Likely Findings has reduced to 24. This is because one of them is annotated as True Positive. Similarly, Likely findings have reduced to 27. This is because one of them is annotated as False Positive.
If you accidentally annotate a Finding or annotate a Finding incorrectly, Nightfall provides remediation measures too. For accidentally annotated Findings, you can revert the annotation to return to the original Likelihood (Possible, Likely, Very Likely). For incorrectly annotated findings, you can modify the annotation.
When the Apply to all identical findings toggle switch is enabled, the following events occur.
annotation is applied to all exact matches of the finding in all the existing Events.
annotation is applied to all exact matches of the findings in new Events.
Furthermore, the Nightfall AI Smart Auto-Ignore feature performs the following tasks.
Events whose 100% of findings are annotated as false positives are automatically ignored.
When auto-ignored, an entry is added to the Event activity log for visibility
Auto-ignored Events are updated to "Ignored" status and moved to the "Resolved" tab for visibility, analysts' review, or audit.
Undo Auto-Ignore
Undo is an action available on any Event that has been automatically ignored by Nightfall AI.
Taking the undo action reverts the status of the selected Event back to the pre-ignore state.
Undo Annotation and Disable Automatic Annotation
The annotation for a specific token/finding can be undone by reverting the annotation (no change from current behavior).
When edited the "apply to all..." flag can be disabled. When disabled, future instances of the exact finding will not be automatically annotated.
You can also find more details about the Event from the Event detail view. By default, only a few details are displayed on the Event detail view. You must click the Expand details button to view all the details of the Event. You can also view the chronological order of events (annotations applied, reverted, Event resolved, and so on) on the Event. The events start from the date on which the Event was created. You can also add comments on the Event.
You can also apply various actions on the Events. The actions menu displays a list of actions that you can perform on an Event.
To learn more about Event actions, you can view the Applying Actions on Events document.
When you wish to implement an action on multiple Events simultaneously, you can use the bulk action feature. To learn more about how to use this feature, refer to the Applying Bulk Actions on Events document.
Nightfall provides you with various filters to view Events specific to an integration, User, or Status. This ensures that you view data that is specific to your requirements. The various filters are described as follows.
This filter allows you to view historical data. You can choose to view data for the last 7, 30, 90, 120, or 180 days. You can also select a custom date range by entering the date in the MM/DD/YY format. When you apply a specific period, all the data on the Event management page is fetched from the selected period till the current date. For instance, assume that the current date is 1 December 2023. If you select the time filter as Last 7 days, the data is displayed from 25 Nov 2023 to 1 December 2023. Similarly, if you select the time filter as last 30 days, the data is displayed from November 2, 2023, to December 1, 2023. By default, this filter displays the data for the Last 7 days. You can click the Last 7 Days button to edit the date.
The miscellaneous filters allow you to apply filters on various Nightfall entities. The entities are described as follows.
This filter facilitates you to view Event data specific to a Detecter.
This filter facilitates you to view Event data specific to an Integration
This filter facilitates you to view Event data specific to the Likelihood of sensitive data being detected.
This filter facilitates you to view data specific to the status of Event
This filter facilitates you to view data specific to users who triggered Events.
To apply a filter:
Click the Filter button.
In the When drop-down menu select a filter.
Note: The Select an Option drop-down menu is activated once you select a filter. The options in the drop-down menu vary for each filter selected.
Select a filter value from the Select an Option drop-down menu. For some filters (like integration filter), you can select multiple values.
(Optional) Click Add Filter to add multiple filters.
(Optional) Repeat steps 2-3 to add multiple filters.
Click Apply.
You can add multiple filters. Nightfall allows you to add a maximum of five filters.
When you add multiple filters, logical AND operation is applied between the filters. As a result, only the data that matches all the applied filters is displayed.
To remove the miscellaneous filters, click the Reset button.
If an Event is reported multiple times, Nightfall updates the Event to the new instance, instead of creating new Events. However, it maintains a trail of the Events to ensure no reporting is lost.
Filtering duplicates reduces alerts. It also saves you the time spent on analyzing each finding.
Nightfall filters duplicate findings in multiple ways. New Events are not created when:
You remove a previously reported finding. The existing Event is updated. You can view the update in the Event metadata.
a duplicate of a finding previously reported is added. The existing Event is updated.
Note: Filtering duplicate Events is currently available for Jira and Confluence.
An Event is auto-resolved:
When you remove all reported findings.
When you delete a resource (ex. ticket, comment, or page).
Consider the case of JIRA integration. If Nightfall detects a data Event in either your JIRA ticket description or JIRA ticket comments an Event is created. This Event has a single finding which was detected in the JIRA ticket. You can view the history of this Event as highlighted in the following image.
Now, consider that you add more sensitive data in the ticket. When Nightfall scans the ticket again the following events occur
A new Event is created with a single finding. This finding refers to the new sensitive data detected during the second scan.
The previous Event record is updated. It now has two findings (even more than two if multiple findings are detected on the same ticket).
You can now find the duplicate ticket information in the ticket history section.
The search bar in Events allows you to search Events in two ways as described in the following sections.
You can search for Events using a keyword. The search returns all Events that contain all the keywords submitted.
For instance, searching for a Credit Card returns all Events that contain Credit AND Card in any of the indexed Event properties.
You can search for an exact phrase. Use double quotes around the phrase (ex."Credit Card Number").
Use the AND to search for Credit Card Number Events by John Doe (ex. "Credit Card Number" AND "John Doe")
Use the Not operator to exclude Events from your search query (ex."Credit Card Number" AND "John Doe" NOT Confluence)
Nightfall provides you with search operators to search for the exact Event required. A search operator is an entity that you can use as a filtering factor. For instance, Detector_name is an operator that you can use to view Events specific to a detector. Similarly, Confidence is an operator that you can use to filter Events based on confidence levels (Very Likely, Likely, Possible).
You can use an operator as shown in the following image.
You can see that when you search for Events with Likely Confidence, the search returns all the Events in which at least one instance of Likely Finding. Similarly, when you search for Possible Confidence, the search returns all the Events that have at least one instance of Possible finding.
Nightfall also displays the last five search terms for each user. These values are stored in the user's browser cache.
Nightfall provides two types of search operators.
General Search Operators: These operators are based on Nightfall entities. These can be confidence level, Nightfall actions, Event status, and so on. To view the complete list of general search operators, see #general-operators.
Integration Search Operators: These are the search operators based on specific integrations. These operators vary for each integration. To view the complete list of integration-based search operators, see #integration-operators.
You can use multiple operators to refine your search. When you use multiple operators, Nightfall applies the AND logic between the operators. So, if you wish to view all the active Events in the Zendesk integration, you can accomplish it as shown in the following image.
You can also use a single operator to filter multiple values. For instance, to view all the Events of Zendesk and Salesforce integrations, you can use the search as shown below.
Note
:
is used as an operator delimiter for search as so :
cannot be used as a search string. If you wish to search a text with :
colon in it, replace it with ?
or *
and submit the query, else the prefix to colon would be considered an operator.
While :
is a special character that is an operator seperator for search actions, there are other special characters that cannot be used directly in the search bar. The complete list of special characters that cannot be searched directly, are as follows.
So, if your policy name contains reserved characters like && {}, you cannot use these characters directly in the search bar. You must make some changes to your search query before using them. To search any of the above special characters, you must perform any one of the following tasks:
Use an escape character \ before the special character (this will work with all special characters but not with :
)
Replace the special character with the wildcard (*).
Replace the special character with a question mark (?).
Some of the examples are as follows.
To search the policy name Google Drive! Critical_Document
, you must use one of the following search terms.
To search the policy name H&&M,
you must use one of the following search terms.
To search the policy name Google !
, you must use one of the following search terms.
Nightfall allows you to share and download the Event data. The Share option creates a link to the current view with all the filters applied. When you click this link,the Events page opens with all the filters applied.
The Export option, creates a CSV file with all the event data. The CSV file is mailed to the logged in user's Email ID. The CSV file contains all the filters which were applied before initiating the download process. Click Export to CSV to start the export process.
Once you click the Export to CSV button, a pop up window comes up. Click Download and Send to Email.
You receive an Email from Nightfall with the subject line Nightfall - Report <Download date>. You must click the Download Report button in the email. The link to the report expires 7 days after you receive the email.
The CSV table contains the same columns as in case of the Event list view. The file looks as follows.
Learn how to apply actions on Nightfall Events.
When an Event is registered, a Nightfall admin can take suitable action on the registered Event. The action(s) performed on an Event ensures that the prevention of sensitive data leakage. Nightfall provides a set of actions that the Nightfall admin can implement. The actions vary for each integration. You can implement an action on an Event from the Event list view or Event detail view.
While Annotations are applied to individual Findings, Actions apply to the entire Event.
When a new Event is registered, by default, the Event is assigned the Active status and you can find it under the Active tab. The Pending tab displays the list of violations on which you have taken some action but have not yet resolved them. The Resolved tab displays the list of violations that have been resolved.
IMPORTANT
You must act on the active violations within 30 days. If you do not perform any action on an active violation within 30 days, the violation expires and moves to the Expired tab.
You can apply an action on a Violation either from the Violation list view page or the Violation details page, as displayed in the following image.
The actions menu in the detail view page displays the same list of actions as in the case of the ellipsis menu. Additionally, you can view a few more actions in the action menu which may not be present in the ellipsis menu.
The list of Actions provided by Nightfall are as follows.
The action copies the link to the Event. You can save or send this link to directly open the Event. This action is available only on the Event detail view.
This action opens the document from within the integration that contains sensitive data. This action is available only on the Event detail view.
This action downloads the file that contains sensitive data. If the file is deleted or moved to a different location within OneDrive, this action fails. This action is available only on the Event detail view.
This action moves the Event to the Ignored tab. For Google Drive, you can choose to Ignore multiple existing Events or future violations simultaneously. To learn more about the Ignore all feature in Google Drive, see Manage Google Drive Events (step 5).
Acknowledge action sends an email alert about the policy Event to the email account associated with your login.
This action allows you to notify end users about the Event. The notification can be via Slack, Email or MS Teams (varies for each integration)
This action allows you to select a JIRA project and create a ticket for this Event.
This action redacts the sensitive data found.
This action temporarily moves files or sensitive data from the original place in which it was discovered to a quarantined Nightfall space for further review. You can restore the quarantined items or permanently remove them by approving or rejecting them through Nightfall alerts.
This action modifies the link setting to anyone signed in to an account in your organization to use the link to your file.
This action applies to Google Drive integration and disables download, print, and copy actions for Commenter and Viewer roles. Editor roles will retain all actions.
This action deletes the attachment with sensitive tokens in a ticket comment (public replies and internal notes). You cannot revert this action.
This action modifies the permissions of a ticket comment from a public reply to an internal note. Converting to an internal note means the ticket comment will no longer be visible to the end user. This action is permanent.
This action removes the page from the web and/or removes guest access to the page. This action is active when it applies to the page at the time of the violation
This action is specific to the GitHub integration and sends a notification to GitHub about the violation.
This action marks the violation as resolved. You can revert this action.
The following table displays the list of all the Nightfall integrations and the Actions supported for each of these integrations.
Confluence
Ignore Acknowledge Notify Slack Notify Email Send to JIRA Redact Delete Resolve
Google Drive
Ignore Acknowledge Notify Slack Notify Email Send to JIRA Change Link Settings Disable Download Resolve
JIRA
Ignore Acknowledge Notify Slack Notify Email Send to JIRA Redact Delete Resolve
Slack
Ignore Notify Send to JIRA
Quarantine Redact Delete (Nightfall supports both, deletion of messages and attachments) Resolve
Salesforce
Ignore Acknowledge Send to JIRA Redact Delete Resolve
Zendesk
Ignore Acknowledge Send to JIRA Redact
Mark as Private
Delete Attachment
Notify Slack
Notify Email Resolve
ChatGPT
Ignore Resolve
GitHub
Send to JIRA Acknowledge Ignore Notify GitHub Notify Email Resolve
Notion
Send to JIRA Ignore Acknowledge Notify Slack Notify Email
Remove Access
Delete Attachment Redact Resolve
MS Teams
Ignore Acknowledge Notify Email
Notify Slack Notify Teams
Change Link Settings
Disable Download Resolve
OneDrive
Ignore Acknowledge Notify Email Notify Slack Notify Teams Delete File Move to Recycle Bin Restrict to Owner Resolve
Gmail
Ignore Acknowledge Notify Email Notify Slack Resolve
Learn how to use the Nightfall Dashboard.
The Nightfall Dashboard provides centralized, aggregated insights across all native integrations in the Nightfall console. The Nightfall dashboard enables you to quickly determine, at a high level, the types, quantities, and trends of sensitive data violations with the ability to break down and filter these violations based on particular integrations, filters, and likelihoods, over various periods of time.
The dashboard consists of various visualizations like widgets, charts, and tables. You can apply filters to view data specific to a time period, integration, detector, status, and so on. The Nightfall Dashboard automatically refreshes every few minutes.
The various tasks that you can perform on the Dashboard are as follows.
The Dashboard displays the date and time when the data was last refreshed. The Nightfall dashboard refreshes automatically every few minutes. You can manually trigger a refresh by refreshing your browser.
Nightfall provides you with various filters to slice and dice data on the dashboard. This ensures that you view data that is specific to your requirements. The various filters are described as follows.
This filter allows you to view historical data. You can choose to view data for the last 7, 30, 90, 120, 180 days, or set a custom date range. When you apply a specific time period, all the data on the dashboard is fetched from the selected time period till the current date. For instance, assume that the current date is 1 December 2023. If you select the time filter as Last 7 days, the data is displayed from 25 Nov 2023 to 1 December 2023. Similarly, if you select the time filter as last 30 days, the data is displayed from November 2, 2023, to December 1, 2023. By default, this filter displays the data for the last 7 days. You can also set a custom date range.
The miscellaneous filters allow you to apply filters on various Nightfall entities. The entities are described as follows.
This filter facilitates you to view data specific to a Detecter.
This filter facilitates you to view data specific to an Integration
This filter facilitates you to view data specific to a Likelihood of sensitive data being detected.
This filter facilitates you to view data specific to the status of Violation. Basically, you can use this filter to view violations caused by a specific user(s
This filter facilitates you to view data specific to users who triggered violations.
To apply a filter:
Click the Filter button.
Click + Add Filter.
Select a filter Entity from the When drop-down menu. The options in the Is drop-down menu are based on the filter entity selected.
Select an option or multiple in the Is drop-down menu. For instance, if you selected Integration as the entity, then you must select the check boxes for the integrations whose data you wish to view.
(Optional) Repeat steps 2-5 to add multiple filters.
Click Apply.
You can add multiple filters. Nightfall allows you to add a maximum of three filters.
When you add multiple filters, logical AND operation is applied between the filters. As a result, only the data that matches all the applied filters is displayed.
To remove the miscellaneous filters, click the Reset button.
The Nightfall Dashboard displays a list of widgets, charts, and tables. These visualizations are described as follows. The data displayed on the visualizations depends on the filters applied.
The Nightfall Dashboard displays the following widgets.
This widget displays the amount of data scanned by Nightfall. You can view the data scanned in real-time and also historically. This widget also displays a line chart. This line chart shows data scanned on each day when you hover over the chart. The x-axis of this chart changes based on the filters applied in the #historic-data-filter.
Apart from the total scanned data, this widget also displays data scanned at a granular level; you can view the real-time and historical data scanned for each integration. When you hover over an integration, you can view the real-time and historical data scanned for the integration. If you have applied a miscellaneous filter to display data for a specific integration, granular data is displayed only for the filtered integration.
This widget displays all the violations recorded in Nightfall during the time period selected in the #historic-data-filter. This widget displays the number of violations irrespective of their status ( New, Active, Pending, Resolved, and Expired). If you apply any #miscellaneous-filters, violations are displayed only for the filters applied.
his widget displays all the actioned violations recorded in Nightfall during the time period selected in the #historic-data-filter. These are the violations that are generated but no action has been taken on them yet. If you do not take any action on an active violation within 30 days from the date on which it was generated, the violation expires. If you apply any #miscellaneous-filters, violations are displayed only for the filters applied.
This widget displays all the actioned violations recorded in Nightfall during the time period selected in the #historic-data-filter. These are the violations on which you have acted (notified in Email or Slack, created JIRA ticket, and so on) but have not yet marked as resolved. This widget displays the number of violations whose current status is active. If you apply any #miscellaneous-filters, violations are displayed only for the filters applied.
You can also view a line chart at the bottom of these three widgets. This line chart shows the number of violations generated each day. The x-axis of this chart changes based on the filters applied in the #historic-data-filter.
Percentile Difference Value
All the widgets display a percentile value, apart from the actual value. This percentile value is either in positive or negative. Nightfall generates this value by the following method.
The current value of the widget and the filter value selected in #historic-data-filter are considered.
This value is compared with the equivalent preceding time period. If the current value is better than the preceding value, the value is converted to a percentage and displayed as a positive result. However, if the current value is worse than its preceding value, the percentile difference is displayed in a negative.
For instance, consider the above image. The value of Active Violations is 25. The selected #historic-data-filter is Last 7 Days. Let's assume that the current date (today's date) is 1 Dec 2023. This implies that there were a total of 25 violations from 25 Nov to 1 Dec (last 7 days).
The value 25 is compared with the equivalent preceding time period (7 days prior to 25 Nov which is Nov 19 to Nov 25). In this case, the current value 25 is greater than its preceding value by 76%. This implies that active violations increased by 76% in a span of a week. Hence, the percentile difference value is displayed as -76%. (An increase in number of violations is not a good sign. Hence it is displayed in red with a negative sign).
The percentile difference value always compares the current value with its equivalent preceding value. In the above case, the #historic-data-filter was selected as the Last 7 Days. hence the current value was compared with its preceding 7 days' value. If you select Last 30 Days as #historic-data-filter, then the current value is compared to the preceding 30 days' value.
The above calculation method is applied in the calculation of percentile difference value for all the widgets.
The Nightfall Dashboard consists of two bar charts. The bar charts are described as follows.
This bar chart displays the top five detectors with the highest number of violations during the time period selected in #historic-data-filter. This bar chart consists of the top five detectors on the x-axis and the number of violations on the y-axis. Each bar represents a detector. When you hover over a bar, you can view the number of violations triggered by the detector.
This bar chart displays the top five policies with the highest number of violations during the time period selected in #historic-data-filter. This bar chart consists of the top five policies on the x-axis and the number of violations on the y-axis. Each bar represents a policy. When you hover over a policy, you can view the number of violations triggered by the detector.
The data displayed in the above bar charts contain violation data. Each violation may further have multiple Findings. To check the number of findings in each Violation, see . To understand the difference between Violations and Findings, see #violation-vs-finding.
The Tables section on the Nightfall Dashboard consists of the following.
This table contains the details of the users who have triggered the highest number of violations. The columns of this table display details like user name, number of violations, and the integrations on which the violations are caused. You can rearrange the contents of the User column alphabetically and the Violation Count column in increasing or decreasing order.
The Nightfall Dashboard allows you to generate reports. The Dashboard currently supports four types of reports.
Sensitive Data Exposure: This report consists of information like the location of sensitive data, the nature of sensitive data, and the overall risk associated with it.
Policy Violations: This report provides information on the policies that are generating the highest number of violations.
Highest Risk Users: This report provides information about users who are triggering the highest number of violations across all integrations.
Total Data Scanned: This report displays the total data scanned by Nightfall across all integrations.
You can select the historical time period for which you wish to generate the reports. The time period is the same as the #historic-data-filter.
To generate a Report:
Click Generate Reports.
Select the check boxes of the reports to be included. Click Select All to include all the reports.
Select the historic time period for which you wish to generate the report.
Click Generate. A pop-up window appears that confirms the Email ID to which reports will be sent.
Click Done.
The Report is mailed to the Email ID of the logged-in user.
When you generate a report, it is sent as an Email to the logged-in user. This email contains a link to download the reports. The download link expires in 7 days from the date you received the Email.
A folder is downloaded to your system. The folder is named as Nightfall_Reports_<date on which report was gnerated>_<historical time period>. This folder contains the reports that you selected for download in step 2 of the #generating-reports section. All the downloaded files are in CSV format.
The following image shows a folder downloaded on 26-11-2023 for the last 30 days. All four reports were selected for download hence you can see four CSV files.
The Highest Risk Users report is named as <date on which report was generated>highest_risk_users_<histroical time period selected>. This report displays the list of users who have triggered the maximum number of violations. The users are sorted in decreasing order of violations triggered. Hence the user who caused the highest number of violations is at the top and the user who triggered the lowest number of violations is at the bottom. This report also displays the integrations, policies, and Detection rules that were violated.
This report has the following columns.
User Name
The user name of the user who triggered the violation.
Integration
The integration(s) on which the user triggered the violation.
Violated Policies
The policy(ies) that the user violated.
Detection Rules
The detection rule(s) that the user violated.
All Violations
Active Violations
The total number of violations that were in active status at the time the report was downloaded.
Actioned Violations
The total number of violations that were in actioned status at the time the report was downloaded.
Quarantined Violations
The total number of violations that were in quarantined status at the time the report was downloaded.
Archived Violations
The total number of violations that were in archived status at the time the report was downloaded.
Reported Violations
The total number of violations that were in reported status at the time the report was downloaded.
Count of Likely
The total number of violations whose Likelihood was Likely, when the report was downloaded.
Count of Very Likely
The total number of violations whose Likelihood was Very Likely, when the report was downloaded.
Count of Possible
The total number of violations whose Likelihood was Possible, when the report was downloaded.
The following image shows a screenshot of the Highest Risk users report.
The Policy Violations report is named as <date on which report was generated>_policy_violations_<histroical time period selected>. This report displays the list of policies that triggered the violations. The policies are sorted in decreasing order of violations triggered. Hence the policy that triggered the highest number of violations is at the top and the policy that triggered the lowest number of violations is at the bottom. This report also displays the integrations, policies, detection rules, and detectors that were violated.
This report has the following columns.
Policy Name
The name of the policy on which the violation was triggered.
Policy UUID
The UUID of the policy on which the violation was triggered.
Policy Version
The version number of the policy on which the violation was triggered.
Integration
The name of the integration to which the policy belongs.
Detection Rules
The detection rules in the policy, that were violated.
Detection Rule UUIDs
The UUID of the detection rules in the policy, that were violated.
Detection Rules Version
The version number of the detection rules on which the violation was triggered.
Detectors
The detectors in the detection rules that were violated.
All Violations
Active Violations
The total number of violations that were in active status at the time the report was downloaded.
Actioned Violations
The total number of violations that were in Actioned status at the time the report was downloaded.
Quarantined Violations
The total number of violations that were in Quarantined status at the time the report was downloaded.
Archived Violations
The total number of violations that were in Archived status at the time the report was downloaded.
False Positives
The total number of false positive violations triggered by the policy.
Count of Likely
The total number of violations whose Likelihood was Likely, when the report was downloaded.
Count of Very Likely
The total number of violations whose Likelihood was Very Likely, when the report was downloaded.
Count of Possible
The total number of violations whose Likelihood was Possible, when the report was downloaded.
The following image shows a screenshot of the Policy Violations report.
The Policy Violations report is named as <date on which report was generated>_sensitive_data_exposure_<histroical time period selected>. This report displays all the details of the sensitive data exposed. This report also displays the integrations, policies, detection rules, and detectors to which the sensitive information belongs to.
This report has the following columns.
Location
The location where the leaked sensitive information resides. This can be the
project name in which sensitive data resides for the JIRA integration, the folder name for the Google Drive integration, the instance name for Zendesk, the page name for the Notion integration, and the repository name for the GitHub integration.
Sub-Location
The sub-location where the leaked sensitive information resides. This can be the
URL of the ticket in which sensitive data resides for the JIRA integration, the URL for the Google Drive integration, the section name for the Notion integration, the ticket URL for Zendesk, and the file name for the GitHub integration.
Integration
The name of the integration from where the sensitive data was leaked.
Violated Policies
The name(s) of the policies that were violated as a result of the sensitive data leak.
Detection Rules
The name(s) of the detection rules that were violated as a result of the sensitive data leak.
Detectors
The name(s) of the detectors that were violated as a result of the sensitive data leak.
Active Violations
The total number of active violations on sensitive data.
Actioned Violations
The total number of actioned violations on sensitive data.
Archived Violations
The total number of archived violations on sensitive data.
Count of Likely
The total number of violations whose Likelihood was Likely, when the report was downloaded.
Count of Very Likely
The total number of violations whose Likelihood was Likely, when the report was downloaded.
Count of Possible
The total number of violations whose Likelihood was Likely, when the report was downloaded.
The following image shows a screenshot of the Sensitive Data Exposure report.
The Total Data Scanned report is named as <date on which report was generated>_stotal_data_scanned_<histroical time period selected>. This report displays all the details of the data scanned.
This report has the following columns.
Data Scanned (GB)
The total data scanned (in Gigabytes)
Items Scanned
The total number of items scanned.
All Violations
The integrations on which the scan was performed.
Active Violations
Actioned Violations
The total number of violations that were in Actioned status (due to the scan).
Quarantined Violations
The total number of violations that were in Actioned status.
Archived Violations
The total number of violations that were in Actioned status.
False Positives
The total number of false positive violations.
Count of Likely
The total number of violations whose Likelihood was Likely, when the report was downloaded.
Count of Ver Likely
The total number of violations whose Likelihood was Likely, when the report was downloaded.
Count of Possible
The total number of violations whose Likelihood was Likely, when the report was downloaded.
The following image shows a screenshot of the Total Data Scanned report.
Learn how to apply bulk actions on Nightfall Events.
Nightfall allows you to perform actions on a large set of Events. The Violations page displays a maximum of 50 Events. With Bulk actions, you can choose to implement an action either on the 50 Events which are currently displayed on the screen or on all the Events including the 50 displayed on the Events page.
Important
You can apply bulk action on a set of Events, only if all the violations belong to a specific integration. Hence, you must use the filter on the integration screen to view only those violations which belong to a specific integration.
You cannot apply remediation actions on expired Events. Events expire automatically after 30 days.
For example, you can apply filter to display on Events reported by the Salesforce integration. Once you apply the filter to view only Salesforce integrations, you can then apply bulk action on all the Salesforce Events.
To use the Bulk actions feature:
Navigate to the Sensitive data Events page in Nightfall.
Apply an integration filter to view the list of Events which belong to a specific integration. You must select only a single integration. If you select multiple integrations, you cannot use the Bulk actions feature.
Select the Finding check box. The 50 violations displayed on the screen are selected.
(Optional) You can also choose to select all of the violations that belong to the filtered integration.
In this stage, you must provide a name to your policy. Additionally, you must also select the Risk scoring method for the policy.
You must provide a name and optional description to the policy. Policy names must be unique across a single Nightfall tenant.
To help SecOps teams prioritise their efforts, we have introduced a risk-scoring system. The risk scoring system helps teams quickly identify and address the most critical issues.
This system scores violations based on various factors, such as the type and quantity of sensitive entities in a resource and the number of people with access to it.
Nightfall assigns a risk score to each violation, reflecting its potential organisational damage. The score is determined based on several factors:
Info Type: The sensitivity level of the specific information found affects the risk score.
Subtype: The sensitivity level of the specific subtype of information, such as vendor-specific API keys and their status, adjusts the score. For example, an active cloud infrastructure API key has a higher risk than an active mail service API key, which in turn is riskier than an inactive API key.
Confidence: The confidence level of each finding influences the risk score.
Count: The number of instances of each info type found in a violation impacts the score.
Combination: The combination of findings in a violation can increase risk. For instance, a combination of patient name, date of birth, and diagnosis constitutes a HIPAA violation.
Scope: The number of people with access to the sensitive data affects the risk score. Data shared privately, internally, or publicly will have different risk levels.
Source: The location of the violation, such as Slack messages, GitHub repositories, Google Drive documents, or ChatGPT prompts, also adjusts the risk score.
Document Type (Future): In the future, document types will be considered in the risk score. Leaking sensitive documents like M&A plans, executive compensation, product designs, formulas, and R&D plans can pose an existential threat to the business.
The risk score can be one of the following.
Critical: Violations with Critical risk score pose an existential threat to the business. For example, an active AWS key can give a bad actor immediate control of the company's infrastructure. A second example would be a resource containing ≥ 100 credit card numbers or PHI records.
High: Violations with High risk score present a significant immediate legal and financial risk to the business or a strong indicator of future critical risks. For example, if a malicious actor gains access to your customer data through a database connection string, it can result in customer churn, lawsuits, and large governmental fines. The discovery of a credential demonstrates a standard of practice that will likely lead to active and critical risk. A second example would be a resource containing 10 to 100 credit card numbers and PHI records.
Medium: Violations with medium risk score indicate poor data hygiene, which threatens the business when discovered in numbers or combination with other entities.
Low: Violations with low risk score indicate poor data hygiene. It may become a medium or high-risk issue when discovered with other entities. For instance, a VIN can uniquely identify a person (PII) and contribute to a protected healthcare information (PHI) finding.
To accommodate users' custom detection needs, our risk scoring system for custom regex detectors assigns scores based on the number of findings detected within documents. The predefined risk score thresholds are:
low-risk for fewer than 10 findings,
medium-risk for 10 to 99 findings,
high-risk for 100 to 499 findings, and
critical-risk for over 500 findings.
Users can override the automated score with a single, user-defined overall score, allowing for greater flexibility and control over the risk assessment process.
While creating a policy, you will notice that Nightfall's advanced scoring algorithm (known as Nightfall Risk Score) is selected by default. However, you can override this with a customized score tailored to your organization's needs (known as Custom Risk Score).
The Risk Scoring feature is introduced in July/August 2024. All the policies created prior to this period, are automatically assigned the Nightfall Risk Score since it is the default option.
If a single document violates two different policies, each of which have a different level of risk score, the policy whose risk score has a higher level of precedence is assigned to the violation. For instance, consider that there are two policies called Policy A and Policy B. Policy A has a risk score High and Policy B has a risk score of Medium. If a single document violates both A and B policies, the risk score assigned to this violation is High since this score has the higher priority.
The Violations page contains a column called Risk. This column displays the risk level for each violation.
When you hover on a risk score, you can view if the risk score is calculated manually or assigned automatically by Nightfall. If a risk score is automatically assigned by Nightfall, the label shows Nightfall Score.
If a risk score is automatically assigned manually, the label shows Custom Score.
You can also click on the label from the content preview pane of a violation to automatically search for all violations matching that label and source.
You can sort the Violations based on this column. Sorting ensures that violations are sorted in either ascending or descending order of risk levels. Security teams can sort the violations in decreasing level of severity and start remediating them.
Security teams can also search for risks with specific label (score) or source (custom or Nightfall). The risk_label operator allows you to search risks based on risk scores.
The risk_source operator allows you to filter Violations based on the source of the risk score.
Use sample data sets provided by Nightfall to test Nightfall's detection capabilities.
The following datasets can be used to test Nightfall's advanced AI-based detection capabilities. The data has been fully de-identified and can be used to test any data loss prevention (DLP) platform.
Nightfall's genAI-based model outperforms traditional entity-based detectors by detecting PHI entities in patient healthcare-related documents.
Nightfall AI's fine-tuned API key detection LLM detects secrets with high precision and dramatically reduces false positives.
Testing note: If a key status is marked as ‘Active’, please rotate the key immediately. Not all vendors provide an "Inactive" response code. In these cases or if the vendor service is offline, the finding status will be marked ‘Unverified’.
Nightfall AI detects passwords shared in conversational text and code.
This sample dataset demonstrates Nightfall's ability to detect cryptographic keys.
This sample dataset demonstrates Nightfall's ability to detect PII with high precision and low noise in text, spreadsheets, and screen grabs. Samples include names, U.S. social security numbers, and driver's licenses.
This sample dataset demonstrates Nightfall's ability to detect sensitive banking and payment information with high precision and low noise in text, spreadsheets, and screen grabs. Samples include positive and negative examples of credit card numbers, routing numbers, IBAN codes, and SWIFT codes.
Nightfall’s computer vision (CV) transformer model outperforms legacy Optical Character Recognition (OCR) text scanning to identify driver’s licenses, passports, credit cards, and US social security cards even though images may be degraded (rotated, glossy, low contrast, blurry, skewed, or cropped).
Learn about the Nightfall alert platforms
Nightfall alert platforms support the configuration of various SaaS apps as alert destinations. Once you configure a SaaS app as an alert destination, you can use it in policy configuration. Nightfall provides you with three SaaS apps that you can use as alert destinations. Apart from these three alert destinations, you can use Email and Webhooks as alert destinations too.
To access the Alert Platform:
Click Settings from the left pane.
Click the Alert platforms tab.
Nightfall provides the following alert platforms.
Setting up Slack as an Alert Platform
Learn how to use MS Teams as an alert platform in Nightall.
This document explains the process of using MS Teams as an alert platform in the Nightfall application.
Currently, you can use MS Teams as an alert platform only in the Microsoft OneDrive for Business and MS Teams integrations.
Contact your Nightfall CSM to obtain the package file required during the setup.
You must have credentials to an MS Teams admin account.
Open the MS Teams app.
Click the Apps menu from the left sidebar
Click Manage your apps.
Click the Upload an app option.
Select the Upload an app to your organisation’s app catalogue option.
Upload the Nightfall package obtained from your Nightfall CSM. The Nightfall Alerts app is available in your organisation’s Teams app catalogue once you upload the package.
Search the term Nightfall in the Teams search bar. You must now be able to see the Nightfall Alerts app.
Click Add for the Nightfall Alerts app.
Click the Add drop-down menu and select Add to a team. You can select multiple Teams.
Select a Team from the drop-down menu.
Once you select a Team, Nightfall Alerts will be available for all the public channels in the selected team.
Once you select the target Team(s) where you may wish to receive the Nightfall alerts, Nightfall allows you to select one of the Team and a public channel within this team in the alert setup pages of MS Teams and OneDrive integrations. You can select a public channel over there and the alerts are sent to the selected channel. The app would post alert messages to the selected channel and you can also @mention Nightfall Alerts to chat with it.
Learn how to start creating a dashboard of Nightfall alerts/actions in your Splunk Enterprise/Splunk Cloud environment.
If you are looking to connect Nightfall to Splunk, please reference the instructions here:
Once you have gone through the Splunk integration steps, we are ready to get started creating Dashboards using Splunk.
Now that the HTTP Event Collector has started receiving alerts from the webhook, you can search by a specific query or create charts to add it to a new or an existing Dashboard.
Below, you will see what a JSON payload looks like in Splunk:
Search:
To search for a specific policy that was violated, click on Search and select a time frame from the dropdown menu. In this example, we will be searching for our policy titled "Internal Channels and Direct Messages"
This is what our Search query would look like:
index="*" | "policiesViolated{}"="Internal Channels and Direct Messages"
This query will list out JSON data for all instances which had "Internal Channels and Direct Messages" as the policy that was violated.
Similarly, you can search for multiple parameters too. If you want to search for a specific detection rule that was violated in the "Internal Channels and Direct Messages" policy, the query would then be:
index="*" | "policiesViolated{}"="Internal Channels and Direct Messages" | "detectionRulesViolated{}"="Credentials and Secrets"
From the Homepage, click on "Search and Reporting". Click on "Dashboards". Click on "Create New Dashboard". Enter a suitable name for your dashboard. Choose the type of dashboard you would like to create- Classic/Studio. Click "Create".
Once the dashboard is created, it is displayed in the list of dashboards.
Navigate to the "Search & Reporting" tab. You can create a chart by either entering a search query or navigating to the "Visualization" section.
For a basic search, enter a query like:
index="*"
Go to "Visualization" tab, select "Pivot".
Next, you can either select "All Fields" or "Selected Fields"; these are the fields you would like to use as your Data Model.
Select "Pie Chart" to create a pie chart to show all the detection rules that were violated.
Next, you can click on the dropdown for "Range" to choose the timeframe/time range you want the data to be from.
Next, select "detectionRulesViolated{}" from the "Field" and "Color" dropdown. You can also create a custom label and give it a name.
If you hover over any of the pieces of the pie, it displays specific details about the detection rule that was violated and also displays the number of times it was violated.
Once the pie chart has been created, click on "Save As" > "Dashboard Panel". Select the "Existing Dashboard Panel" that was created in Step 1. Make sure to select the name of the dashboard from the list. Panel title would be the title of the panel. e.g. "Detection Rules Violated" and give a unique model id. e.g. detectionrules. Click on "Save"
Steps 1 and 2 can be used to create multiple charts and to add them to an existing dashboard.
Finally, here are some sample Nightfall-Splunk Dashboard examples:
Please use these as a guide to get started creating your own Dashboards within Splunk. If you have any questions, or would like some assistance on how to get started using Splunk with your Nightfall integration, please reach out to support@nightfall.ai.
Learn how to integrate Nightfall with a SIEM or push violations downstream to any alert drain, SOAR tool, BI tool, and more.
To integrate with a SIEM or push Nightfall alerts downstream, specify a webhook URL in your Nightfall console.
First, configure an incoming webhook in the tool you'd like to send Nightfall alerts into. For example, this could be Splunk, Sumo Logic, LogRhythm, Slack, PagerDuty, etc.
For LogRhythm integration, initialize the Webhook Beat by following these instructions.
This process will provide you with an HTTPS URL endpoint (as seen in step 4c). Copy this URL as you will use it to complete set up.
For Sumo Logic integration, configure an HTTP Logs and Metrics Source via the following instructions.
This process will provide you with a URL endpoint (as seen in step 10). Copy this URL as you will use it to complete set up.
For a Splunk integration, configure an HTTP Event Collector within Splunk via the following instructions.
This process will provide you with a URL endpoint (as seen in this step). Copy this URL as you will use it to complete set up.
To authenticate to the HTTP Event Collector, you may add an Authorization
http header as described in the Splunk documentation with your HTTP Event Collector token.
Note that the Authorization HTTP header for HEC requires the "Splunk" keyword before the HEC token.
It is also possible to add your HEC Token as part of the query string of the Collector URL. This can be done for both Splunk Cloud as well as Enterprise.
If you are a Splunk Cloud customer, you will have to reach out to Splunk to enable the "allowQueryStringAuth" flag for your Splunk Cloud instance. This can be done by raising a Support Ticket with Splunk. This field can only be updated if on a Paid account. For a free/trial account, it will be unavailable.
For Splunk Enterprise, you will have to enable query string authentication for your instance, by following these steps:
Go to $SPLUNK_HOME/etc/apps/splunk_httpinput/local/inputs.conf file. Your tokens will appear by name in this file, in the form of http://<token_name>.
Within the stanza for each token you want to enable query string authentication, add or change the following setting:
Once the flag is enabled, please use the following steps to query the HEC Token within the URL String. For more information on Query string authentication from Splunk, please reference the docs here.
You can specify the HEC token as a query string in the URL that you specify in your queries to HEC. This can be done with the format shown below:
The following example shows a full Collector URL including a dummy HEC Token appended as a query string: (The example is for an Enterprise instance)
Note: We will be using the /services/collector/raw endpoint
instead of the /services/collector/event
endpoint. This is because of the JSON format that webhooks from Nightfall will carry, which will only be accepted with the raw version of the HTTP Event Collector endpoint.
For Splunk Cloud customers, the above example URL will look different including the public facing HEC URL. The endpoint (/services/collector/raw?token=12345678-1234-1234-1234-1234567890AB
) should remain the same, however. Since you are on a Splunk Cloud instance, this URL should already be visible to the Nightfall console, and you would be able to start using this Webhook URL in the Nightfall console. Please continue with the steps after this section to complete webhook set up.
For Splunk Enterprise customers, there are a few extra steps to have the Splunk Collector exposed to the Nightfall webhook console below.
The next step will be exposing the local host and port of the Splunk collector an HTTP Listening tool. This can be done by using an ngrok tunnel or nginx server, for example This is required so that the Enterprise Splunk instance is accessible to Nightfall's webhook from the console. Please make sure that port 8088 (this is the default port for receiving data for HEC) is accessible by navigating to "Global settings" in your Splunk Enterprise instance and enabling it.
Steps for setting up a ngrok tunnel can be found here. If using a ngrok tunnel, the following command would generate a ngrok tunnel listening to the correct port and protocol for the collector:
./ngrok http https://localhost:8088
Once complete, the ngrok tunnel should show you an HTTPS Forwarding address, that can be used as the ngrok host in the following step. (HTTPS is required by Nightfall's webhook URL validation)
Your ngrok tunnel URL with your HEC auth token should now look something like this:
https://<NGROK_HOST>/services/collector/raw?token=<YOUR_HEC_TOKEN>
This will be your Webhook URL that you can use in the Nightfall console. Now you are all set to integrate alerts from your Nightfall webhook to your ngrok tunnel.
Next, configure the outgoing webhook in Nightfall. This webhook will fire in real-time upon a new event (e.g. a new violation is created).
Navigate to the integration for which you would be interested in setting up a webhook for alerts. Webhooks are available all native integrations.
Select the Settings tab on the top.
Select Change or Add next to the Webhook option.
Enter the URL to your webhook endpoint.
You may send a sample payload to the endpoint that you have entered to verify a successful connection using the Test button.
You may also add HTTP Headers to send authentication tokens or other content using the Add Headers button.
Once your header key and value is entered you may obfuscate it by clicking on the "lock" icon next to the value field for the header. Click the Save button to persist your changes to the headers.
When you have completed configuring your Webhook URL and Headers, click the Save button.
Going forward, you will now see events sent directly from Nightfall into your SIEM or other solution of choice.
When Nightfall sends a message to the configured Webhook, an event is always included in the message. Nightfall sends the following four types of events listed in the following table.
exposure_update
resolution
violation
remediation
The following are examples of a sample payload for detection rules that were violated, that will be delivered to the webhook. These are examples from each integration, so the specific fields may vary based on the Nightfall product you are using (e.g. Slack, Github, Google Drive Jira, etc.).
The following are examples of a sample payload for remediations/actions that were taken on the above mentioned Nightfall Events, that will be delivered to the webhook. These are examples from each integration, so the specific fields may vary based on the Nightfall product you are using (e.g. Slack, Github, Google Drive Jira, etc.).
Learn how to integrate Nightfall with Microsoft Sentinel.
Microsoft Sentinel is Microsoft's SIEM tool which is part of the Microsoft Azure suite. You can use Sentinel as a SIEM tool and send Nightfall alerts to this tool.
To ingest any data into Microsoft Sentinel, you must use a data connector. A Sentinel data connector is a data pipeline which transfers data (alerts, incidents, and so on) from a specific source to Sentinel. Microsoft provides many out of the box data connectors to ingest data into Sentinel.
To use Sentinel as a Webhook and send alerts from Nightfall to Sentinel, you must first configure Sentinel as a webhook. To configure sentinel as a webhook, you must create a custom connector in Sentinel, since there is no out of the box connector for Nightfall AI in Sentinel. Microsoft provides multiple ways in which you can create custom connectors. To learn more about how to create a custom connector, you can refer to this Microsoft documentation.
Once you create a custom connector in Sentinel, you must configure the Webhook endpoint in Nightfall.
Click Integrations in Nightfall.
Click Manage for the required integration.
Scroll down to the alerting section and click + Webhook.
Enter the Sentinel URL obtained in the #configure-sentinel-as-webhook section.
Click Test to verify the URL.
You must receive a message as shown in the following image.
Check your webhook if you received a POST message from Nightfall. If no POST message is generated, verify your Webhook URL and try again.
(Optional) Click Add Header to add authentication parameters.
Enter the authentication parameters (key value format) under the key and value columns, respectively.
Click the unlock icon to obfuscate the key value pair.
Click Save.
Once you configure Sentinel as a Webhook, Nightfall sends alert notifications to Sentinel. You can view these notifications in Sentinel. To learn more about how to view visual data in Sentinel, you can refer to this Microsoft documentation. To learn more querying logs using Microsoft's Kusto Query Language, refer to this Microsoft documentation.
Learn how to set up your integration with Slack so that you can scan and protect sensitive data across your Slack workspace.
Welcome to Nightfall! This guide is intended to help you install and set up Nightfall in a matter of minutes on your own. Within 24 hours of you signing on to be a customer, you will receive an invitation in your inbox to access your newly created account.
Once you receive your account, review the following pages in this guide to get set up.
Get ready to install by reviewing the . Go through the installation flow, depending on your Slack plan type:
Next, use the Detection Wizard to set up the right Detection Rules for your organization in your Nightfall dashboard. You can learn more about and access the Detection Wizard .
Once you’ve generated your Detection Rules with the Wizard, configure them on your Nightfall Dashboard.
On the , copy the Detection Rule UUIDs that you wish to use for DLP scanning.
Configuring a policy, review the Configuring Policiessection, including:
How to
Defining the policy scope
Selecting detection rules that you configured above
Determining what automated actions you would like to take
Refer to the in the guide to learn more about the various actions you can take
Nightfall allows multiple methods of receiving alerts, via Slack, email, webhooks, or Jira tickets. Review the Configuring Alerts section to learn more.
To test detection, we recommend the following tutorials:
Congratulations - you are all set up. You’ve now successfully connected and tested Nightfall for Slack!
Learn how to start creating a dashboard of Nightfall alerts/actions in your Sumo Logic environment.
If you are looking to connect Nightfall to Sumo Logic, please reference the instructions here:
Once you have gone through the Sumo Logic integration steps, we are ready to get started creating Dashboards using Sumo Logic.
Now that the HTTP Event Collector has started receiving alerts from the webhook, you can search by a specific query or create charts to add it to a new or an existing Dashboard.
In this example, my HTTP Event Collector's name is "Minify Tax Collector". Below, you will see what a JSON payload looks like in Sumo Logic:
The JSON payload gives granular details like detection rules violated, policies violated, including findings and details about the sender.
Search:
To search for a specific policy that was violated, click on Search and select a time frame from the dropdown menu. In this example, we will be searching for our policy titled "High Risk, Likely"
This is what our Search query would look like:
(_source="Minify Tax Collector") | where policiesviolated=="High Risk, Likely"
This query will list out JSON data for all instances which had "High Risk, Likely" as the policy that was violated.
Similarly, you can search for multiple parameters too. If you want to search for a specific detection rule that was violated in the "High Risk, Likely" policy, the query would then be:
(_source="Minify Tax Collector") | where policiesviolated=="High Risk, Likely" && detectionrulesviolated == "Credit cards, Likely"
From the Homepage, click on "+New". Click on "Dashboard". Choose a panel type, I have selected "Categorical" in this example. Enter the name of the dashboard. In this example, "Minify Tax - Nightfall" is the name of my dashboard. On the dashboard is created, the next step is to add panels/charts to the newly created dashboard.
For a basic dashboard, we will be searching for all the alerts from all services. Enter the search query:
(_source="Minify Tax Collector") | count by service
Select a time range. In this example, we will look at data from the past 7 days. Click on Search. This query will result in a pie chart which shows alerts from all the 5 services (Slack, GitHub, GDrive, Jira and Confluence).
You can customize this chart using the customization panel on the right side. Once the customization is complete, click on "Add to Dashboard" on the right. Also rename the name of the panel, in this case, the name of the pie chart/panel is "Alerts from Services". Panel name should be something that can make properties of the chart easily identifiable.
Next, we will be creating another chart to look at the different detection rules that were violated.
Select "Add Panel" to add a new panel/chart to the dashboard. Select "Categorical", enter "Last 7 days" as the date range and then enter the search query:
(_source="Minify Tax Collector") | where eventtype == "violation" | count by detectionrulesviolated
This query returns a list of detection rules that were violated in the last 7 days. Sumo Logic gives you the flexibility to have different time ranges in the same dashboard. You can select time period as "Last 30 days" for one panel and have a customized time period for another panel within the same dashboard. For this query, I'll be using "Bar chart" as as my chart type so it would look like:
Step 2 can be replicated to add multiple panels to the existing dashboard.
Here is a sample Sumo Logic - Nightfall Dashboard for your reference:
Please use these as a guide to get started creating your own Dashboards within Sumo Logic. If you have any questions, or would like some assistance on how to get started using Sumo Logic with your Nightfall integration, please reach out to support@nightfall.ai.
Learn how to install Nightfall for Slack
Make sure you know which variant of Nightfall for Slack you want to install.
Learn the process of installing Nightfall DLP for Slack Pro and Slack Business+.
To install Nightfall Pro DLP for Slack,
Click Add to Slack to install the Nightfall Slack bot.
Select the Slack workspace associated with your Nightfall account.
Click Allow. You will be directed to setup instructions. Complete these steps to start receiving alerts.
The Nightfall bot is automatically added to public channels within 24 hours. If you wish to disable this automated process, please contact .
The Nightfall bot is also automatically added to public connect Slack channels for the Slack Business+ edition. You must manually add the bot to private connect Slack channels in Slack Business+ edition.
To invite the bot to private channels use the following command:
/invite @Nightfall Pro #[channel]
Learn the process of installing Nightfall DLP for Slack enterprise.
Note: Nightfall DLP for Slack Enterprise requires that the Slack Discovery API be enabled. See the page for more information and additional installation requirements.
To install Nightfall Enterprise for Slack,
Select Authorize to authorize the Discovery API access in to Slack environment. You must be an org owner to authorize Nightfall DLP for Slack Enterprise Grid.
Select the correct workspace associated with the Nightfall account.
Click Allow. Nightfall can access the Discovery API now.
Note: If the authorization fails, the Discovery API is not yet enabled in your Slack organization. Contact your Slack sales rep or write to to enable this.
Once you have granted access to the Discovery API, you will be directed back to the dashboard to install the Nightfall Enterprise bot.
Click 'Install' to grant our bot access to your Slack workspace.
Select the ‘Install’ option.
Click 'Install'. You will be directed to another 'Allow' page. Select the correct workspace associated with your Nightfall account and click Allow.
The workspace you select here will be the one in which Nightfall creates new private channels in which to send you DLP alerts and triage the quarantine. Once complete, Nightfall is installed in your Slack workspace.
Make sure the following requirements are fulfilled before you get started.
Understand the requirements for Nightfall DLP for Slack Pro.
Ensure the following requirements are fulfilled before you get started.
A service account with permission to install apps in the appropriate workspace is required.
The Channel Management permission for “People who can create Private channels” must be set to “Everyone, plus Multi-Channel Guests (default)”. Failure to set this permission will result in a “Restricted Action” error. See article for instructions on how to check and set this permission. Once you have completed the installation, you can revert the permission to its original setting.
Learn the process of configuring the Scope in the Slack Pro and Business+ editions while creating a Nightfall policy.
This document explains how to set up the Policy Scope for Slack Pro and Slack Business+ editions. If you are using a Slack Enterprise edition, you must refer to .
The Scope stage allows you to select Slack Channels and Connections which must be scanned by the policy.
To configure Policy Scope:
Select one of the following options under the Select Channels section. The scope of this policy is limited to only those channels and connections which you select in this section.
Channels: Select the Select All check box to scan the data in all your Slack channels. Select the Public Channels check box to scan data only in your Public Slack Channels. Select the Private Channels check box to scan data only in your private Slack channels.
Connections: Select the Select All check box to scan the data in all your Slack connections. Select the Public Connect Channels check box to scan data only in your Public connect Slack Channels. Select the Private Connect Channels check box to scan data only in your private connect Slack channels.
You must add the Nightfall Pro Slack application to all the channels that you wish to scan with Nightfall.
The Filters section provides you an added level of granularity in setting the Scope. You can use specific filters to filter data based on Users, Groups, Channels, or Apps.
Slack policies support filtering based on users, user groups, and apps. These options provide flexible, granular control on whom to apply the monitoring. The Only Include option is very useful to pick specific required users, groups or apps for monitoring. particularly useful for creating broad policies with specific exceptions. Combining user and group options allows for complex, layered access control. The exclude option allows you to exclude the monitoring of unwanted users, user groups and apps, thus reducing the unwanted noise from secure entities.
Only Include: Only messages sent by selected users are scanned for sensitive data.
Exclude: Messages sent by excluded users are not scanned.
Only Include: Only messages sent by users in included Slack groups are scanned for sensitive data.
Exclude: Messages sent by users in excluded Slack groups are not scanned.
Only Include: Only messages sent by included Slack apps are scanned for sensitive data.
Exclude: Messages sent by excluded Slack apps are not scanned.
Nightfall uses prioritization to decide which messages to scan when multiple filters are configured in a policy. The order of priority is:
User Exclusion
User Inclusion
Group Exclusion
Group Inclusion
How it works:
1. Initially, Nightfall checks if the file owner is on the User Exclusion list. If they are, their messages are not scanned, no matter how other filters are configured in a policy.
2. If the user isn't excluded, Nightfall then checks if they're on the User Inclusion list. If they are, all their messages are scanned for that policy.
3. If the user isn't on either the exclusion or inclusion lists, Nightfall looks at group memberships. It checks if the user belongs to any excluded groups. If they do, their messages are not scanned for that policy.
4. Finally, if none of the above apply, Nightfall checks if the user is in any included groups. If they are, their messages are scanned for that policy. If not, the messages are not scanned.
Learn how to handle Nightfall Events that were created as a result of sensitive data leak in the Nightfall for Slack Pro and Slack Business+ editions.
When an end user violates a policy in Slack, an Event is generated based on the notification settings configured by you in the policy configurations. To learn more about Events, see .
This document explains where you can find notifications on Slack policy Events and what actions can be taken.
To view Events in the Nightfall Console:
Click Detection and Response from the left pane.
(Optional) Modify the days filter to view Events prior to last 7 days. By default the Events recorded in the Last 7 Days are displayed.
Apply filters to view only the Slack Events.
Click on any of the Events to view details of an Event. You may click anywhere in the row of an Event that you wish to inspect. Details will be present via a side panel.
The second section displays details that are source / integration specific and so the details vary from one integration to the other.
In Slack, you can take actions either from the Event list view page or the Event detail view page. On the Event list view page, you can click the ellipsis menu to view the available list of actions.
On the Event detail view, you can view the applicable actions from the actions section at the bottom.
The list of actions supported for Slack are as follows. Some of these actions are common to other integrations as well.
Copy Event Link: The action copies the link to the Event. You can save or send this link to directly open the Event. This action is available only on the Event detail view.
View in Slack: This action redirects to the sensitive data in the source Slack account. While this action is available only on the Event detail view, please note that relevant access to the source of sensitive data in Slack should be present.
Ignore: The ignore action flags Nightfall to ignore all the findings in the Event and may be taken if you find the findings false positive. This action marks the Event as resolved and moves it to the Resolved section. You can undo this action.
Acknowledge: You can take this action to notify other users that you have looked into this Event and will take suitable action in future.
Notify Email: This action notifies the end user who added the sensitive data file to the OneDrive about the event, through email.
Notify Slack: This action notifies the end user who added the sensitive data file to the OneDrive about the event, through Slack.
Send to JIRA: This action creates a JIRA ticket for the Event. You can pick a project and Issue type while creating the JIRA ticket and can assign the JIRA ticket to the end-user.
Delete: This action deletes the sensitive data present in Slack messages or attachments.
Resolve: This action must be taken when the sensitive data is removed completely. This action resolves the Event.
When a data leak occurs, Slack sends an Email to end users, if they have configured Email as a Notification method in their Slack account.
Learn the process of selecting the Detection rules in the Slack Pro and Business+ editions while creating a Nightfall policy.
In this section, you can select the Detection rules for the policy and If not already created, you can create detection rules. To learn more about how to configure detection rules, see .
To select detection rules, select the detection rules from the list of rules that display.
You can also sort the rules that you want to view.
All Detection Rules: View all detection rules created
Selected Detection Rules: View detection rules that are selected and mapped to this policy
Unselected Detection Rules: View detection rules that are neither selected nor mapped to this policy.
Click Next.
Learn the process of configuring automated actions in the Slack Pro and Business+ editions while creating a Nightfall policy.
This section describes the various actions that Nightfall takes automatically when a violation is detected. You must turn on the toggle switch to enable an action. You can also set the timeline as to when an action must be taken (immediately after detecting a violation or after some time).
Currently, Nightfall supports the Delete automated action for the Slack Pro and Business+ editions.
You must first turn on the toggle switch to enable any of the automated actions.
Once you enable the toggle switch, you can configure when the action must be applied.
If you select immediately, the action is implemented automatically after the sensitive data is detected.
If you select After, you must also set the time frame as to when exactly the action must be applied, after detecting the sensitive data.
The action is described as follows.
The delete action automatically deletes the message or attachment that has sensitive data. This is a permanent action and cannot be reverted.
Learn the process of configuring alerts for Slack.
The Nightfall for Slack integration allows you to configure alerts at the policy level and also at the integration level. Alerts for Slack can be sent to the following destinations.
When you configure alert settings at the integration level, the alert settings apply to all the policies, created for the Slack integration. However, when you configure alert settings specifically for a policy, which is created in the Slack integration, the alert settings are applicable only for that specific policy.
This document explains how to configure alerts at the integration level.
You can configure alerts at the integration level once you have installed the Nightfall for Slack DLP integration.
To configure alerts at the integration level:
Navigate to the Slack integration.
Scroll down to the Slack section.
You can configure one or multiple alert channels.
To configure Slack as an alert channel, click + Slack channel.
In the Slack alert channel field, enter the name of the Slack channel in which you wish to receive the alerts.
Click Save.
A confirmation pop-up box is displayed to confirm if the Slack channel (entered in the second step) must be used only for Slack DLP integration or all the Nightfall integrations.
Select No, only integration level to use the Slack channel only for Slack DLP, or select Yes, please to use the selected Slack channel for all the Nightfall integrations.
Click + Email.
Enter the Email ID of the recipient who should receive the notifications.
Click Save.
A confirmation pop-up box is displayed to confirm if the Email ID (entered in the second step) must be used only for Slack DLP integration or all the Nightfall integrations.
Select No, only integration level to use the Slack channel only for Slack DLP, or select Yes, please to use the selected Slack channel for all the Nightfall integrations.
Click + Webhook.
Enter the Webhook URL.
Click Test. If the test result is not successful, check the Webhook URL.
(Optional) Click Add Header to add headers.
Click Save.
When you configure alerts to a Webhook, Nightfall AI sends occasional posts to:
To validate that the Webhook is properly configured before the policy is saved.
Periodically thereafter to ensure that the Webhook is still valid.
The response to the test Webhooks is 200
status code if successful.
An example of Webhook request is as follows.
This is part of alert event consumption and can be ignored.
Click + Jira Ticket.
Select a JIRA project from the Jira Project drop-down menu.
Select an issue type from the Issue Type drop-down menu.
(Optional) Add comments to be added in the JIRA ticket.
Click Save changes.
A confirmation pop-up box is displayed to confirm if the JIRA settings configured for the Slack DLP integration must be applied to all the other Nightfall integrations too.
Select No, only integration level to use the configurations only for Slack DLP, or select Yes, please to use the selected JIRA configurations for all the Nightfall integrations.
When an Event is triggered, Nightfall sends a notification to the end-user whose actions triggered the Event. While notifying the end-user, Nightfall also sends a text message. You can draft the text message to be sent to the end-user. This message applies to all the policies. Click Save changes once done.
Detects protected health information (PHI). as data that uniquely identifies an individual plus a diagnostic indicator such as medication, diagnosis, and procedure.
Detects API keys, credentials needed to authenticate and authorize a cloud provider’s API request. Findings will include the vendor name and active key validation for the most popular services. Nightfall supports more than 50 vendor-specific and generic types.
Detects private cryptographic keys. A cryptographic key is a data string used to lock or unlock cryptographic functions, including authentication, authorization, and encryption.
This operator allows you to filter Events using the type of annotation. Nightfall provides three types of annotations. To learn more about annotations, see
Note: if you are using the Slack product, there is a built-in template that will send a message to users if you select the “Notify User” remediation option. This template can be customized in the .
The risk score of the Event. When you hover on the risk score, you can view if the score was assigned automatically or calculated manually by Nightfall. For more information on Risk score, see .
A set of remediation actions that you can take on a Event. To view the list of actions supported in Nightfall, see .
The total number of violations triggered by the user (for the time period selected in ).
The total number of violations triggered by the policy (for the time period selected in ).
The total number of violations triggered from the scan (for the time period selected in ).
An alert that triggers if there are new findings or if findings have been removed from the .
An alert that triggers when the is resolved.
An alert that triggers when a new is created.
An alert that is triggered when any remediation action (eg . Redact, delete) content is taken on the .
To confirm that sensitive data is getting scanned by Nightfall, you can run a few tests with Nightfall-provided sample data. In doing so, you will see Violations populate on the Nightfall dashboard on . You'll also start to see high-level metrics aggregate on .
If you have any questions, check out thesection for support.
Note: This command must be executed by a member of the private channel or by a Workspace Owner using Slack’s Channel Management Tools. For more information on enabling Channel Management Tools, see article.
Once you filter the Events to view only the Slack Events, you can refer to the section to learn more about the available options.
The side panel (or the Event detail view) is divided into three separate sections. The first section has information about the occurrence of individual findings with a preview. The third section is an activity log for the Event. Both these sections reveal information that is common across all sources/integrations. You can refer to these common sections in the section.
Nightfall allows you to take various action on Events. When you take an action on an Event, the status of the Event changes accordingly. To learn more about Event status, refer to the document.
To view the complete list of actions, applicable to all the integrations, you can refer to the document.
Quarantine: This action quarantines the message with sensitive data. Click to learn more about the action. This action is available only in the Slack Enterprise edition.
Redact: This action redacts the sensitive data present in the Slack message. Click to learn more about the action. This action is available only in the Slack Enterprise edition.
Additionally, if you have configured Email Notification in , Nightfall admins receive the Email notification as shown in the following image.
If you have configured Email Notification in the Automation section of settings, end users receive an email from Nightfall. This Email allows end users to take actions from within the Email. The actions are present at the end of the email. The available actions depend on the settings configured by you admin in the section.
If you have configured Slack as a Notification in the Automation section of , end users can view the violation notification from within Slack.
To use Slack as an alert platform, you must first perform the required Slack configurations. You can refer to to learn more about how to configure Slack as an Alert platform.
To use Webhook as an alert platform, you must first perform the required Webhook configurations. You can refer to to learn more about how to configure Webhook as an Alert platform.
To use JIRA as an alert platform, you must have the DLP for the JIRA app installed from the . You can read more about the DLP for JIRA integration .
Learn more about the Nightfall Cloud DLP
Nightfall is:
Agentless. Nightfall isn't deployed as software that requires installation, rather it integrates with the applications we secure through APIs. This makes deployment easy and updates to our platform effortless, without getting end-users or IT involved.
API driven. Central to Nightfall is the API driven nature of our platform. Connecting with cloud platforms via API means that visibility and security policies immediately apply at the application layer. Nightfall can derive platform-specific context & metadata, as well as provide granular, platform-specific actions, versus broad-brush blocking on the network.
Agnostic. Nightfall is platform, endpoint, and network agnostic in that we’re capable of integrating with cloud platforms quickly and can provide single pane of glass visibility across multiple cloud apps simultaneously. Via our Developer platform, you can also provide coverage for applications we don't natively integrate with, including your own custom apps be they cloud-based or on-prem.
Automated. Nightfall doesn't just provide visibility into the cloud, but helps automate policies whenever possible. The sheer volume of data that moves through cloud systems combined with the always-on nature of cloud applications means that incidents can happen at any time and will require immediate remediation. Automation ensures that security teams can respond to these as quickly as possible.
Accurate. Finally, in order to help security teams process the massive amounts of data in the cloud, cloud-native DLP must be accurate. The accuracy of Nightfall is enabled by the same systems that allow us to automate detection — an effective use of machine learning that can quickly and accurately identify when business-critical data has been exposed.
See the diagram below to understand the coverage provided by Nightfall.
Learn how you can extend the functionality of an existing Nightfall detector.
You can customize a Nightfall detector to meet your organization's requirements. Once you customize a Nightfall detector, it is considered to be a custom detector. The Nigytfall detector that you used and customized, continues to exist as is.
Nightfall provides you with two customization options. Context rules and Exclusion rules. You must use at least one of these two rules to customize a Nightfall detector. The procedure to use Context rules and Exclusion rules is the same as in the case of Regular Expression Detector. You can learn how to configure Context rules and Exclusion rules from the document.
To extend a Nightfall Detector:
Navigate to the Detectors section from the left pane.
Click + Custom Detector and select Extend a Nightfall detector.
Select the Nightfall detector that you wish to customize.
Enter a name for the customized detector in the Name field.
(Optional) Enter a description for the detector in the Description field.
Click Next.
Click + Add Context Rule to configure the context rule.
Click Save to save the rule.
Click Next.
Click + Add Token Rule to configure token rules.
Click Save to save the rule.
Click Next.
It is mandatory to either define the Context rule or the Token rule.
Review the configurations and click Add.
Learn how to create a Regular Expression detector in Nightfall.
A regular expression detector allows you to define a regular expression pattern. Once you define a pattern, Nightfall scans your data to check if there is anything that matches the given pattern. If a match is found, it is flagged as sensitive data. You can also refer to to generate regular expressions.
To use the Regular Expression detector effectively, Nightfall provides you with two special rules; Context Rules and Exclusion Rules. When Nightfall scans your data and finds some sensitive data, these rules are used to further scrutinize the sensitive data to be sure that the data is sensitive. Context rules and Exclusion rules are optional and you can define them only if you wish to have added filtration on sensitive data to be sure that data that is termed as sensitive, is sensitive.
Context rules are a set of hot and cold words that help Nightfall to effectively identify sensitive data.
Exclusion rules define specific scenarios in which data flagged by a detector should be excluded from the list of findings.
You can find these rules in the Regular Expression detector. You must click + Rule to create a Context rule or Exclusion rule.
Context rules help Nightfall identify sensitive data by providing data about the text surrounding sensitive data. You can define a regular expression pattern to match the data that usually surrounds sensitive data. You can then instruct Nightfall as to where this surrounding data can be generally found. It can be found before sensitive data, after sensitive data, or both before and after sensitive data. You can also define confidence level settings when a match is found.
For example, credit card data is sensitive data. If a user shares it accidentally online, then they generally draft the following phrases before disclosing the credit card number.
After disclosing the credit card information, users generally draft the following messages.
You can also choose to make your regular expression case-sensitive by selecting the Case sensitive check box.
The terms "Finding" and "Sensitive data" are synonyms to each other.
Windows Setting: Once you create the regular expression to define the possible phrases that can surround the sensitive data, you can use the Windows setting to instruct Nightfall as to where exactly this surrounding text can exist around the sensitive data (before, after). Nightfall provides you the following Windows settings.
Before the finding: You can use this setting to define the number of characters before the prospective sensitive data at which surrounding text can be found. For example, if you define this setting as 20 characters before the finding, and if Nightfall detects the prospective sensitive data on line 4 column 60, it looks at the data on line 4 and from column 40 to check if it matches the defined regular expression for Context rules.
After the finding: You can use this setting to define the number of characters after the prospective sensitive data at which surrounding text can be found. For example, if you define this setting as 20 characters after the finding, and if Nightfall detects the prospective sensitive data on line 4 column 60, it looks at the data on line 4 and from column 60 to check it that matches the defined regular expression for Context rules.
Before or after the finding: You can use this setting to define the number of characters before or after the prospective sensitive data at which surrounding text can be found. For example, if you define this setting as 20 characters before or after the finding, and if Nightfall detects the prospective sensitive data on line 4 column 60, it looks at the data on line 4 and from column 60 and also on data at line 4 from column 40 to check it any of the two match the defined regular expression for Context rules.
Confidence Change: If Nightfall finds any data to be sensitive and if this prospective sensitive data matches the Context rules as well, you can then define Confidence change settings to instruct Nightfall on what to label this prospective sensitive data. Nightfall provides you with four Confidence change settings
Exclude: If you set the Confidence Change setting to Exclude, Nightfall does not consider the prospective Finding to be actually sensitive (even though it matched both; sensitive data's regular expression and also the Context rules' regular expression and Windows setting) and excludes it from Findings. You can use this setting to eliminate false positive findings. For example, consider that one of your prospective customer is testing your API and you need to share an API key for this testing. You share a dummy API key and do not wish this API key to be flagged as sensitive data. You can ask your employees to draft a specific phrase before sharing the API key (something like, the dummy API key is ). You can then define a context rule for this phrase, set the Windows setting to define where exactly it can be found, and then set Exclude as the Confidence change setting, to exclude this dummy API key from being flagged as sensitive data.
Once you create the regular expression for Context rule, define the Windows setting and the Confidence Change settings, you must click Save to create the context rule.
Once you save the Context rule, you can see that Nightfall creates a sentence which defines the summary of your Context rule. You can choose to edit or delete the rule, if required.
Exclusion rules specify data that is not sensitive in nature (false positive findings). If you feel that Context rules cannot help you to stop false positive findings being logged, you can use Exclusion rules. You can also use Exclusion rules and also Context rules together to eliminate the possibility of getting false positive findings.
Nightfall provides you four methods by which you can define Exclusion rules.
For example, consider that one of your prospective customer is testing your API and you need to share an API key for this testing. You create a series of dummy API keys (say ABCD1234, ABCD2345, ABCD3124, ABCD5412, and so on). You can create a regular expression to match each of these dummy APIs and select the Full match option. Nightfall does not treat any of these as sensitive data and excludes them.
You can observe that all the API keys start with the term ABCD. In such cases, you can use the Partial match option and just define regular expression for any one of the API keys. This is helpful if you have hundreds of dummy APIs, which have some common data between them. You need not create a regular expression for each of them.
Since all the dummy APIs start with ABCD, if Nightfall detects any of these API keys, it straight away excludes them. In this case, you must ensure that none of the live APIs have the term ABCD in them.
If you are facing a hard time creating regular expressions for content that needs to be excluded, you can use the dictionary option. This option allows you to define phrases that must not be considered as sensitive data. You can use this option to directly define commonly used passwords, dummy API keys, and so on.
The Dictionary exclusion rule has three options.
Manual Entry: In this option you can directly enter the password or API key to be excluded and press enter. You can add multiple items (need not have any delimiter). You can choose to match the string partially or fully.
Existing Dictionary: In this option, you can choose an existing Dictionary detector as the exclusion token. When you select the Existing Dictionary option, a new drop-down menu is displayed. You can select any of the previously created dictionary detector.
The File Type exclusion rule allows you to exclude a specific file type. If Nightfall finds that the prospective sensitive data is part of one of the file types defined in this section, it excludes it.
File type provides you two options.
New File Type: This option allows you to define new file type(s) that must be excluded.
Existing Custom Detector: This option allows you to use a File Type Detector created previously as the exclusion token. When you select this option, a new drop-down menu is displayed which consists of the list of previously created File type detectors. You can select the required detector.
This option allows you to upload a file with all the data that you feel is not sensitive. Nightfall checks if any of the prospective findings match the data in this file. If a match is found, the data is not considered to be sensitive and excluded from Findings. You can also upload an existing File Fingerprint detector as the input token.
There are two options in this rule.
Upload New File: This option allows you to upload a new file.
Existing Custom Detector: This option allows you to use a previously created custom File Fingerprint detector.
You can execute the following steps to create a Regex detector.
Navigate to the Detectors section from the left pane.
Click + Custom Detector and select Regular Expression.
Enter a name for your custom Detector in the Name field.
(Optional) Enter a description for the Detector in the Description field.
(Optional) Select the Case sensitive check box if you wish to match case sensitive pattern.
(Optional) Click + Rule under the CONTEXT RULES section and define regular expression pattern for Context rule.
(Optional) Click + Rule under the EXCLUSION RULES section and define regular expression pattern for Exclusion rule.
Click ADD.
Context rules involve creating regular expressions to define these types of phrases that surround the sensitive data. You can use to generate regular expressions to define data that surrounds sensitive data. You can define the Context rule regular expression in the Pattern to match text box.
Possible: If you set the Confidence Change setting to Possible, Nightfall classifies the prospective finding as an actual sensitive data and this finding is logged on the page as a Possible finding (around 20-30% chance of data actually being sensitive in nature). For example, in the above scenario for the Exclude option, if you wish to get notifications even for dummy APIs, to ensure that your employees might have not shared an actual API key instead of a dummy key, you can use the Possible setting. This setting logs the finding on the Violations page as Possible finding. You can check the finding on the Violations page and if its dummy API key, and not a live API key, you can set it to Ignore the finding from the Violations page.
Likely: If you set the Confidence Change setting to Likely, Nightfall classifies the prospective finding as an actual sensitive data and this finding is logged on the page as a Likely finding (around 50-60% chance of data actually being sensitive in nature). For example, consider the scenario described above for the Exclude option. If you feel that sometimes your employees may share a dummy API key with prospective customers without using the mandatory phrase (the dummy API key is). In such cases, you they might have used some other phrases. You cannot really be sure if they transmitted dummy API keys or shared live API keys. In such cases, you can set the Confidence to be Likely (50-60% chance of data actually being sensitive). Nightfall logs it as a Finding in the Violations page with Likely confidence level. You can view the Violations page, verify this Finding which is tagged as Likely and take appropriate actions based on whether the data is actually sensitive or not.
Very Likely: If you set the Confidence Change setting to Very Likely, Nightfall classifies the prospective finding as an actual sensitive data and this finding is logged on the page as a Very Likely finding (around 80-90% chance of data actually being sensitive in nature). For example, consider the scenario described above for the Exclude option. Apart from the dummy API key there are lots of sensitive data in your organization. If an employee accidentally shares such information, they generally use phrases like our organization's API keys are, our API OAuth key is, the password is... and so on. You can create a regular expression for all such phrases, define the Window settings for them and then set the Confidence level as Very Likely. Nightfall logs such findings on the Violations page as Very Likely findings (80-90% chance of data actually being sensitive). You can navigate to the Violations page and take appropriate actions.
You can use Regex method and define a regular expression. If a prospective sensitive data matches the defined regex, it is immediately excluded from being considered as a Finding. Nightfall also allows you to match either the whole regular expression or partial regular expression. You can use to generate regular expressions.
Upload Dictionary: With this option, you can upload a new dictionary. The process is same as in case of dictionary detector. You can refer to the document for details.
Enter the Regular expression pattern in , in the Regex field.
Learn how to configure Nightfall to send alerts to Microsoft Teams using email.
Integrating your Nightfall alerts to Microsoft Teams for Slack/Jira/GDrive/Confluence can be done using the following the steps:
Log in to your Microsoft Teams account and create a new channel called "Nightfall Alerts". You can also use your existing channel to send your alerts to it. Click on the three dots next to the channel name, "More options"
2. Select "Get email address" in more options.
3. Copy the email address shown in the pop-up:
4. Log in to your Nightfall account, click on the integration you want to integrate with. In this example, I have selected "Jira":
5. Click on "Settings" and in the "Email alert" textbox, enter the Microsoft Teams email address from Step 3 and Save it.
Once a policy is violated, you should an receive alert in your Teams channel:
You can also take remediation actions like "Redact Findings" or delete (in case of attachment) through Microsoft Teams. For any issues or questions, please feel free to reach out to support@nightfall.ai.
Understand the requirements for Nightfall DLP for Slack Enterprise.
Ensure the following requirements are fulfilled before you get started.
You must enable the Slack Discovery API before getting started with Nightfall. You can confirm or request this by writing to Slack at feedback@slack.com.
A service account with appropriate Slack permissions is required.
For Slack Enterprise Grid plans, an Org Owner is required and must be a member of at least one of the workspaces. Org Primary Owner is not required.
For Slack Enterprise Select plans, a Workspace Owner is required. Workspace Primary Owner is not required.
The Channel Management permission for “People who can create Private channels” must be set to “Everyone, plus Multi-Channel Guests (default)”. See this article for instructions on how to check and set this permission. Once you have completed the installation, you can revert the permission to its original setting.
While not a requirement for installation, in order for Nightfall to scan edits in direct messages, Slack’s Retention Policy must be set to “Keep all messages, including revision history.” Please review this article for information on configuring this policy.
Learn more about various status of Nightfall Events.
The Status of an Event implies the current state of the Event. For instance, an Event whose status displays Notified, implies that the end-user whose actions caused the violation has been notified about their actions. They must now take appropriate actions.
When a new Event is created in Nightfall, the status is Active. The status of the violation gets modified by one of the following methods.
Automatically: If you have configured either Admin alerting, end-user alerting, or have allowed end-user remediation, the status of the violation changes automatically.
Manually: If you apply an action on a Violation manually either from the Violations page or from any other platform, the status of the violation changes accordingly.
The various Status available in Nightfall are listed as follows.
This status implies that the Event is newly created and no action (not even notification about the Event) is implemented.
This status implies that the Nightfall admin has viewed acknowledged the Event. A further action needs to be taken in future.
This status implies that the end-users have been notified about their actions that caused the Event.
This status implies that the sensitive data that triggered the Event, is redacted.
This status implies that the entity (file, email, and so on) that contains the sensitive data is quarantined from rest of the data.
This status implies that the access to the file or entity that contains sensitive data is no longer accessible to the internal users of the organization.
This status implies that the access to the file or entity that contains sensitive data is no longer accessible to the external users who are not part of your organization.
This status implies that the file's (that contains sensitive data) access permissions have been modified.
This status implies that the file or the entity that contained the sensitive data is deleted.
This status implies that the Nightfall admin has ignored the Event either because its false positive or because they wish to look into it in the later.
This status implies that the file that contains sensitive data has been disabled from downloading. This prevents any user from downloading the file.
This status implies that the file or the entity containing sensitive data is marked as private.
This status implies that the attachment that contains sensitive data has been deleted.
This status implies that a new JIRA ticket has been created to represent this Event.
This status implies that the sensitive data has been encrypted.
This status implies that the entity containing the sensitive data has been encrypted.
This status implies that a notification has been sent to the end-user requesting justification for their actions that caused the Event.
This status implies that the end-user has provided justification of their action(s) that triggered the Event.
This status implies that the access to the file containing sensitive data is now restricted only to the owner of the file.
This status implies that the file containing sensitive data is deleted.
This implies that the entity containing sensitive data is moved to recycle bin.
This status implies that the email has been quarantined. A Nightfall admin must visit the quarantine settings in Gmail and take an action accordingly. This status is applicable only to Gmail.
This status implies that the email was sent to the recipient after scanning. There were no actions taken on the email. This status is applicable only to Gmail.
These are the violations which have been notified to the end-users. However no action has been taken by the end-users or any other user.
This status implies that the sensitive data issue in the Event has been addressed and thus the Event is resolved.
This status implies that the Event has expired since no action has been taken even after the stipulated time period.
Learn the process of configuring the advanced settings in the Slack Pro and Business+ editions while creating a Nightfall policy.
This stage allows you to select notification channels if a policy violation occurs. The notification alerts are sent at two levels.
The alert configurations configured in this section describe the process of creating alerts at the policy level. Policy-level alerts apply only to the policy on which they are configured. To configure an alert on all the Slack policies, you must configure alerts at the integration level. To learn more about how to configure integration-level policies for Slack integration, read this document.
The steps to configure alert channels for policy-level integration are the same as in the case of integration-level alerts. You can refer to this document for steps.
This section allows you to configure notifications to be sent to the end user whose actions triggered the violation.
Enter a custom message to be sent to the end user. This message is sent in an Email. You can modify the default message provided by Nightfall and draft your message. The total character length allowed is 1000 characters. You can also add hyperlinks in the custom message. The syntax is <link | text >. For example, to hyperlink https://www.nightfall.ai with the text Nightfall website, you must write <https://www.nightfall.ai | Nightfall website> .
You can select one of the following methods. You must turn the toggle switch to use this option.
Via Email: This option sends an Email to the End user.
Via Slack: This option sends a Slack notification to the end-user in a pre-configured channel.
End-user remediation (also known as Human Firewall) allows you to configure remediation measures that end users can take, when a violation is detected on their GitHub operations. You must turn on the toggle switch to use this option. The various available options are as follows.
Delete: This option allows the end-user to delete the message that caused the violation.
Report as False Positive with Business Justification: This option allows end users to report false positive alerts and provide a business justification as to why the alert is considered to be false positive.
Report as False Positive: This option allows end users to report false positive alerts.
When a Violation is Reported as False Positive: You can use this option to set actions to be taken when a violation is reported as false positive by the end-user. You can either set the remediation to be automatic or manual.
Remind Every (until Violation expires): You can use this option to set a reminder for the end-user to take action on the violation. You can choose to remind the end user every 24, 48, or 72 hours.
Learn how to use Slack as an alert platform in Nightall.
This document explains how to set up Slack to receive violation alerts. You can create a dedicated Slack channel to receive violation alerts from Nightfall. All the violation messages from policies are sent to the dedicated Slack channel.
You must have admin permissions for the Slack workspace that you wish to use as an Alert platform in Nightfall.
You can use Slack as an Alert platform in Nightfall. You can create a Slack channel and configure it as an Alert platform in Nightfall. All the violation notifications are directed towards the dedicated Slack channel that you created, once you complete the configuration.
Apart from provisioning you to use Slack as an Alert platform, Nightfall also provides you a Slack integration. This integration is known as Nightfall for Slack. This integration ensures that no sensitive data leaks out of your organization through the Slack medium.
The process of using Slack as an alert platform is different for Slack integration and other non-Slack Nightfall integrations.
The following three sections highlight the steps required to set up Slack as an alert platform for Slack and non-Slack integrations.
Invite the Nightfall DLP Application to your Slack Channel. This step is only required for the Slack integration in Nightfall.
Install Slack as an Alert platform. This step is only required for non-Slack integrations in Nightfall.
Invite the Nightfall alerts application to your Slack channel. This step is only required for non-Slack integrations in Nightfall.
This step is only required for the Slack integration in Nightfall.
Create a dedicated channel in Slack to receive violation notifications from Nightfall.
Navigate to the Slack channel created in the above step.
Click Get channel details.
Click the Integrations tab.
Click Add an App under the Apps section.
Search with the term Nightfall in the search bar and select Nightfall Pro DLP for Slack.
Click Add to Slack.
You can now navigate to the Slack integration in Nightfall and set this channel as an alert platform for the Slack integration. All violations that occur through Slack are notified through this Slack channel.
This step is only required for non-Slack integrations in Nightfall. To use Slack as an alert platform for non-Slack integration, you must first install Slack as an alert platform.
To set up Slack as an Alert platform:
Log in to your Nightfall account.
Click Settings in the left pane.
Click the Alert Platforms tab.
Click Install for the Slack alert platform.
Enter the name of your Slack workspace.
Click Continue.
Enter the Email ID associated with your Slack account.
The Nightfall permission request page is displayed. Click Allow.
This completes all the steps. You can verify if your connection was successful by navigating to the Alerts platform page. If you see the Uninstall button for Slack, it implies that Slack was successfully installed as an alert platform.
Important: Do not click the Uninstall button. It uninstalls the Slack alert platform.
This step is only required for non-Slack integrations in Nightfall. Once you install Slack as an alert platform, you must now invite the Nightfall alerts application to your desired channel in which you wish to receive violation notifications.
Create a dedicated channel in Slack to receive violation notifications from Nightfall.
Navigate to the Slack channel created in the above step.
Click Get channel details.
Click the Integrations tab.
Click Add an App under the Apps section.
Search for the term Nightfall in the search bar.
Click Add for the Nightfall Alerts application.
You can now navigate to any non-Slack integration in Nightfall and enter the name of this channel in the Slack alerts section. All the violation alerts from the selected integration are directed towards the Slack channel.
Links to all the Nightfall integrations
Nightfall allows you to create policies to detect sensitive data across various SaaS applications mentioned below. Nightfall supports these SaaS applications out of the box which can be setup easily and you can get started in minutes.
Currently, the following SaaS applications are supported in Nightfall.
If your data does not reside in any of the above applications, you can use the to build a custom workflow and scan data from any other SaaS application, cloud infra services such as AWS S3, Logging tools like Datadog, and more.
Learn the process of configuring the Risk Score and naming the policy while creating a Nightfall policy for the Slack Pro and Slack Business+ editions.
In this final stage, you assign a name to the policy, verify your configurations, and create the policy.
Enter a name for the policy.
(Optional) Enter a description for the policy.
Choose the Policy risk score. By default the risk score is set to Nightfall Risk Score. You can set it to Custom Risk score, and select one of the risk levels, if required. To learn more about Risk scoring, refer to the #risk-scoring document.
Click Next.
Verify if all the policy configurations are set up as per your requirements.
(Optional) Click back to modify any of the policy configurations.
Click Submit.