In this stage, you select the Integration for which the policy is created. In this case, GitHub integration must be selected.

1. Click Policies from the left menu.

2. Click + New Policy.

3. Select Sensitive Data.

4. Select the GitHub integration.

GitHub file paths do not contain the GitHub org name or repository names. They only contain the folder name(s) and file name. Hence a regular expression to match GitHub directories must only contain characters to just match the folder name and file name.

Matching Files at the Repository Level

These are the files that are directly located under a repository. They are not nested under any repository folders. If the file name is abcd.py and the repository name is Python repository, in a GitHub org called Python Project, then the file path would be Python Project/Python repository/abcd.py. However, as mentioned above, GitHub file paths do not include the GitHub org name and repository name, and hence the file path would just be abcd.py in this case.

To exclude all such files (.py), you must create the regular expression as follows.

 .*\.py

Similarly, to exclude any other file types, you must replace py in the above pattern with your respective file extension.

Matching Files Nested in Directories

You can match files nested under repositories, by using the escape sequence character (\) for every level of nesting. An escape sequence character is required to match a forward slash (/) used in directories.

For instance, to match a file abcd.py under the folder first (effective GitHub file path is first/abcd.py), you must use the following regular expression.

first\/.*

The above expression matches all the files under the first folder and not just the abcd.py. To match only Python files (.py extension), you must use the following regular expression.

first\/.*\.py

To match only the abcd.py file, under the first folder, you must use the following regular expression.

first\/abcd\.py

Matching Nested Directories

To exclude all the files under a directory, you must match the entire directory. Consider that a directory is first/second. You wish to exclude all the files under this directory. Also, in this case, you must use the escape sequence character twice, since there are two levels of nesting and as a result, two forward slashes.

first\/second\/.*

This regex matches and excludes all the files under the directory.

Similarly, to exclude files nested at multiple levels, you can use escape sequence character-based matching.

Cheat Sheet

This cheat sheet displays the regex to be used for various scenarios.

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 Configuring Detection Rules.

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.

1. Click Next.

In this final stage, you assign a name to the policy, verify your configurations, and create the policy.

1. Enter a name for the policy.

2. (Optional) Enter a description for the policy.

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

1. Click Next.

2. Verify if all the policy configurations are set up as per your requirements.

3. (Optional) Click back to modify any of the policy configurations.

4. Click Submit.

This stage allows you to select notification channels if a policy violation occurs. The notification alerts are sent at two levels.

Admin Alerting

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

End-User Notification

This section allows you to configure notifications to be sent to the end user whose actions triggered the violation.

Custom Message

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 with the text Nightfall website, you must write < | Nightfall website>.

Automation

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 GitHub developer. If Nightfall cannot detect the Email ID of the developer, the Email ID provided in the Fallback Email field is used.

• Via GitHub: This option tags the developer in the Pull Request / Commit with the details on the violation. This will also generate a notification that the developer can view in their GitHub profile account.

End-User Remediation

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.

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

The Scope stage allows you to select a GitHub org in which you can the policy can be created.

To configure Policy Scope:

1. Click + Org and select the GitHub org.

2. Select one of the following options under the Include in Monitoring section. The scope of this policy is limited to only those repositories which you select in this section.

• All Repositories: This option adds all the repositories (public and private) in your GitHub org to the policy scope.

• Public Repositories: This option adds all the public repositories in your GitHub org to the policy scope.

• Private Repositories: This option adds all the private repositories in your GitHub org to the policy scope.

The Exclude Repositories section allows you to exclude repositories, files, and directories from the policy scope. It is optional and you can proceed without configuring this section, if you wish to maintain the scope of the policy to all the repositories and its directories, selected in Step 2.

1. Select a method to exclude repositories.

• Select Repository: This option displays a drop-down menu of all the repositories selected in Step 2. You can directly select any repository to exclude it from the scope of the policy.

• Enter pattern to exclude: Select a text pattern to be matched for excluding repositories from policy scope.

  • Starts With: All repositories that start with the mentioned text will be excluded.

  • Ends With: All repositories that end with the mentioned text will be excluded.

  • Contains: All repositories that contain the mentioned text will be excluded.

• File Extension Exclusion: Select a file extension. All the files with the selected extension are excluded from the policy scope.

1. Click Next.

Example Scenario

Consider that you wish to scan all public repositories of your GitHub account with Nightfall. However, there are a few public repositories that were created for testing purposes. These test repositories contain the word "test" in their names. You can use the Repository Exclusion drop-down menu to choose each repository that contains the word test. However, this task can be cumbersome.

You can use the Enter pattern to Exclude menu with the Contains option and enter the term test in the field as shown in the following image.

Consider another scenario in which you wish to include all the repositories but wish to exclude files with the "cert" extensions. You can accomplish this as shown in. the following image.

DLP policies are a set of rules that include specific conditions, actions, and exceptions that monitor and filter data. DLP policies also enable you to remediate any leakage of sensitive information from within your organization.

• You can set up policies to scan 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, we recommend that you 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 configure policies on the GitHub integration to determine which repositories are monitored, and which ones are excluded from monitoring. You can also automate the remediation actions that you want Nightfall to perform on a policy violation.

Creating Policies in Nightfall for GitHub

The process of creating policies in Nightfall consists of six stages enlisted as follows.

Integration

Scope

Detection Rules

Advanced Settings

Creating Policy

Managing Violations