Creating Policies
Understand Nightfall Policies
This document applies only to the Nightfall SaaS application customer. If you are a Nightfall developer platform customer, refer to this document.
Background Knowledge
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.
Understanding Policies
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.
Policy Stages
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 as follows.
The options in the Scope stage and Advanced Settings stage vary for each integration. Each of the stages is explained below.
Selecting Integration
In this stage, you select an integration for which the policy is being created.
Based on the integration selected, the options vary in the upcoming policy stages.
Policy Scope
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. All the integrations (except Notion) in Nightfall 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 Scope section has the following components.
Inclusion Rules
The Inclusion rules allow you to select sections of your integration that must be scanned by Nightfall. The options available in inclusion rules vary for each integration.
Exclusion Rules
The Exclusion rules allow you to select sections of your integration that must be excluded by Nightfall from scanning. The options available in exclusion rules vary for each integration.
For instance, consider the JIRA integration. For this integration, you must first select the JIRA instance that you wish to be scanned by Nightfall.
Once you select the JIRA instance, you must configure the inclusion and exclusion rules. In this case, the options available for inclusion and exclusion rules are projects (options vary if you select another integration). You must now select which projects you wish to scan. In some scenarios, you might have created a JIRA project just for testing some workflows. You can choose to exclude such projects and also other projects that you feel are least prone to data leak attacks.
You can choose your required projects in one of the following ways.
In the Include In Monitoring section (inclusion rules) select All Projects and then in the Exclude From Monitoring (exclusion rules) section select the projects to be excluded.
Select Choose Projects in the Include In Monitoring section (inclusion rules) and select the required projects.
In the following image, Demo service request is a test project and we wish to exclude it from monitoring. There are two ways to do it as shown below.
If you wish to scan all the projects of a JIRA instance, select All Projects in the Include In Monitoring (inclusion rules) section and do not select anything from the Exclude From Monitoring (exclusion rules) section. Alternatively, select Choose Projects in the Include In Monitoring (inclusion rules) section and select the required projects.
You can configure multiple instances of JIRA in a single policy. You must follow the same procedure and set the inclusion and exclusion rules for each instance. In the following image, you can see three instances of JIRA, each configured with different inclusion and exclusion rules.
Similarly, you can configure the inclusion and exclusion rules in other integrations as well. As stated above, the options vary for each integration.
Detection Rules
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.
Advanced Settings
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.
Admin Alerting
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.
Automated Actions
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.
End-User Notification
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.
Name and Description
In this stage, you must provide a name to your policy. Policy names must be unique across a single Nightfall tenant. You can also add an optional description.
Edit and Review
In the final stage, you can verify the policy configurations, make any modifications if required, and create the policy.
Last updated
