Chad Sigler

Platform Team for Virtru.

Lock Your Door and Close Your Windows Especially If You Are Developer

(Photo by Fanny Rascle on Unsplash)
Hello and welcome to this, my first blog post. This topic is near and dear to my heart, from my personal experiences with data leakage from human error. Let’s dive into protecting application data using the Virtru SDK.

A Common Customer Concern

Many of our customers develop custom applications that store, receive, or share sensitive data, they have concerns that AWS and S3 are a possible large surface area of attack. The larger the application and the more teams involved, the more chances for errors to be introduced.
The errors may be as minuscule as misspellings in the UI, up to a configuration error on the S3 bucket. While the misspelling of a label won’t necessarily result in data loss, an S3 bucket misconfiguration can be both damaging and expensive, which was the case for companies like British Airways and TicketMaster.
Many of our developer end users express concern about maintaining security and control of their data while working in a cloud environment. I recently worked with Sam, a full-stack developer at a web service company, to help secure their data throughout the data lifecycle.

Business Problem

Sam was tasked with gathering customer information in an online form, including what would be considered personally-identifying information (PII). He has control over the application and to some extent the environment in which the application runs.
Sam’s corporate business requirements included:
  • Using server/services provisioned by the Corporate Hosting Team
  • Using S3 for client application data managed by the Corporate Storage Team
  • Web application with a Javascript frontend and Python backend
  • Standard development timeline (too short!)
Ensuring the security of his client’s data is now at the top of his list of personal requirements for the application.
Additionally, Sam noted the following personal requirements:
  • Ensure customer data is secure
  • Minimize integration headaches
  • Make the approach repeatable
  • Boto for the S3 integration

Minimizing Security Risk

Sam’s company requires the use of TLS and “at rest encryption” in the S3 buckets. As the developer, he does not have control over the S3 bucket ACL and encryption keys. AWS offers native security features that his client utilizes but Sam would like to add a layer of data protection to ensure that his customer’s confidence and trust are not betrayed.
The Virtru SDK provides Sam the following benefits:
  • SaaS Infrastructure — Completely managed
  • Key Management — Completely managed
  • Access Control — Simple policy interface to add and remove access
  • Audit Logs — Access to all actions taken on secured files
  • Easy Integration — Few lines of code to get it running

Using Virtru SDK with S3

Per the company business policy, Sam is required to use Boto3 to perform any S3 calls as it has been approved by their security team. Sam was able to add Virtru to his application by simply replacing his calls to Boto3 with Virtru Boto3.
It was done with very little effort because the Virtru Boto3 wrapper code is open source and the calls were straight-forward and available on Github.

Examples

Upload and Encrypt
virtru_upload_file(local_file, 
                   bucket, 
                   s3_file, 
                   is_virtru_encrypt=True, 
                   virtru_owner=virtru_owner)
Download and Decrypt
virtru_download_file(bucket, 
                     s3_file, 
                     local_file, 
                     virtru_owner)

Adding Policy Controls

Sam or another designated administrator can manage Virtru encrypted files and policies in the future by storing attributes in their application database.
Fields Stored:
  • Virtru Policy Id
Once these attributes are stored, Sam can:
  • Revoke access to the policies; reverse that revocation if needed.
  • View audit records associated with a file
  • Add and remove users from the policy
  • Add and remove auto-expiration from the policy

Security Incident Response

The Security Team reached out to Sam about a potential security incident. Some of the corporate S3 buckets were not configured correctly, which led to possible data exposure.
One of the exposed buckets contained the data from Sam’s application. Sam was able to revoke access to all files until the security team researched the incident and gave the ‘all clear’.
Because Sam was able to provide the security team with an audit log showing who tried to access the file and when; the security team was assured that there were no decrypt requests.

Tags

Comments

Topics of interest