Organizational compliance is one of the leading drivers that require DLP tooling such as Nightfall. These are the recommended configurations for each compliance framework.
| Compliance | Configuration | Considerations |
|---|---|---|
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
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.
| Data Protection | Configuration | Considerations |
|---|
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
Protected Health Data |
|
|
Secrets & Credentials |
|
Banking / Financial Transactions |
|
|
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.