With this short guide we will explain how you can add data loss prevention (DLP) as code to communications services like Twilio and SendGrid in a few lines of code, helping ensure your customer communications remain compliant.
Introduction
Transactional email and communication APIs like SendGrid, Twilio, SES, and Mailgun are critical components to modern applications. These services allow developers to easily incorporate end-user communication into their applications without the infrastructural overhead.
However, these services pose a new source of security risk as they can lead to accidental sharing of sensitive data if communications are sent to the wrong users or inadvertently contain sensitive data. Adding data loss prevention (DLP) into your business logic can provide critical capability to classify & protect sensitive data before it exposed, leaked, or stored.
Use Cases
The risk of exposing sensitive data is especially common in situations where these transactional communication services are handling user-generated content like messages between agents and users, or peer-to-peer. Here are a few examples:
Example 1
You're building a grocery delivery application like Instacart. The application allows Shoppers and Customers to send and receive text messages with each other, powered by Twilio. The Customer sends the Shopper a picture of their Driver's License since they won't be home for the delivery, even though their Driver's License needs to be verified in person. Now this image with sensitive PII is processed by Twilio, stored in your application's object store, and viewable by the Shopper and support agents.
Example 2
You're building an application for job seekers to connect with small business owners like restaurants that are hiring, and they can exchange messages over text, powered by Twilio. A malicious user signs up to impersonate a restaurant owner and uses this mechanism to collect PII from job seekers such as their SSN. Now this PII is transmitted by Twilio and is accessible by the attacker.
With the Nightfall API, you can scan transactional communications for sensitive data and remediate accordingly. In this post, we’ll describe the pattern behind how to use Nightfall to scan for sensitive data in outgoing emails.
Standard Pattern for Sending Transactional Email/SMS
The typical pattern for using transactional communication services like SendGrid is as follows:
- Get an API key and set environment variables
- Initialize the SDK client (e.g. SendGrid Python client), or use the API directly to construct a request
- Construct your outgoing message, which includes information like the subject, body, recipients, etc.
- Use the SendGrid API or SDK client to send the message
Let's look at a simple example in Python. Note how easy it is to send sensitive data, in this case a credit card number.
Python
Adding Sensitive Data Classification/Protection to the Pattern
It is straightforward to update this pattern to use Nightfall to check for sensitive findings and ensure sensitive data isn’t sent out. Here’s how:
Step 1. Setup
Get API keys for both communication service (“CS”) and Nightfall (“NF”), and set environment variables. Learn more about creating a Nightfall API key here.
Step 2. Configure Detection
NF: Create a pre-configured detection rule in the Nightfall dashboard or inline detection rule with Nightfall API or SDK client.
Consider using redaction
Note that if you specify a redaction config, you can automatically get de-identified data back, including a reconstructed, redacted copy of your original payload. Learn more about redaction here.
Step 3. Classify and/or Redact
Text
Step 4. Handle Response and Send
Python Example
Let's take a look at what this would look like in a Python example using the Twilio and Nightfall Python SDKs in just 12 lines of code (with comments and formatting added for clarity):
Python
You'll see that the message we originally intended to send had sensitive data:
And the message we ultimately sent was redacted!
Adapting to Inbound Communications
Services like Twilio and SendGrid also support inbound communications from end-users, typically via webhook. Meaning inbound messages will be sent to a webhook handler that you specify. Hence, you would insert the above logic in your webhook handler upon receipt of an event payload.
Now that you understand the pattern, give it a shot!