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.
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.
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.
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.
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.
