Data Security

Introduction

Our data security philosophy is pretty much the opposite of your standard privacy policy document. While our current Privacy Policy states,

In the event that any information under our control is compromised as a result of a breach of security, we will take commercially reasonable steps to investigate the situation and, where appropriate, notify those individuals whose information may have been compromised and take other steps, in accordance with any applicable laws and regulations. Please keep in mind that you are responsible for the security of any Personal Information in your control.

by contrast, our data security obligations compel us, as a team, to accept responsibility for the transfer, receipt and usage of certain kinds of data. Even though the statements above claim to address “any information under our control,” the MDA team’s data security measures supersede those statements and acknowledge that certain categories of data represent a major liability for our organization and are, in fact, our legal responsibility by way of contractual agreements asserting that we will protect that data against specific kinds of transfer or usage which are expressly or implicitly prohibited by the contract. The main purpose of a comprehensive Information Security practice is to ensure compliance with these prohibitions while also facilitating practical access and productive usage of the data for the benefit of our clients and users.

Data Access Points

With regard to protected and/or sensitive data, our information security considerations can be divided approximately into two high-level facets:

  1. Environments in which that data is stored and accessed.
  2. Procedures for receiving, transmitting and disposing of that data.

We process, store and access data within the following environments, as described with relevant security measures:

  • Amazon Web Services (EC2 / RDS / S3):
    • AWS is our primary cloud infrastructure platform
    • Access is controlled through IAM user accounts, using standard methods for authentication, authorization and delegation of platform privileges
    • We never use our AWS root user account to perform any changes to the system, so all changes can be tracked back to a specific user within our org
    • SSH and SFTP access to our EC2 virtual machines is also regulated by individual user accounts, using encrypted private/public key pairs
    • S3 access is restricted by IAM user accounts and bucket policies
  • Database (PostgreSQL):
    • The ability to read and/or alter the contents of our database instances (on AWS RDS) is regulated by PostgreSQL roles; individual user roles are authorized to connect to the database by password protected login
    • These roles are defined and scoped by database administrators who are the only roles with the capability to create/alter database instances and grant/deny data access permissions to all other roles
    • Access to the database by database administrators is controlled by Active Directory and restricted to internal network connections facilitated by AWS VPN; AD & VPN together form an administrative security boundary
    • Regular database user access also relies on whitelisting the user’s IP address within AWS Security Groups (firewall) for an additional layer of access control.
  • Laptops/Workstations (Mac OS X + Bitfender + Uprise):
    • All members of our team work on some variation of MacBook Pro laptop, with its standard set of built-in security protocols and password protected login.
    • All laptops are equipped with Bitdefender Anitvirus software
    • Local and remote IT security services, as well as general support and maintenance of the organization’s laptops, workstations and local area networks are provided by Uprise, our external IT vendor.

Our procedures for handling protected and/or sensitive data include the following:

  • The methods we use to transfer data from one authorized environment to another are restricted to:
    • SSH/SFTP is used to transfer data to/from laptops and EC2 virtual machines
    • S3 is used to transfer data to/from S3 buckets which can only be accessed by other authorized IAM users (including users external the organization, as authorized)
    • PostgreSQL database connections (secured by password and SSL) are used to transfer data to/from our database instances
  • S3 is our main staging area for receiving data assets in preparation for data ingestion
  • Protected data assets and files are never checked into version control (git) and common data file type extensions are explicitly excluded by each project’s .gitignore file
  • On completion of a project or when deemed necessary any time beforehand, protected and/or sensitive data is removed from all database instances, S3 buckets and laptops/workstation hard drives

Public and/or Open Data

  • …