In light of the recent Uber data breach, I thought it would be a good time to review common techniques used to properly secure sensitive information. The steps below are largely related to AWS, however, they apply equally to other cloud and on-premises solutions.

Protect User Logins

In the event that a user’s password is exposed, multi-factor authentication (MFA) can save the day.  MFA is your first and best protection against leaked passwords. Best practice dictates that passwords, access keys, ssh keys, and all secrets used in authentication should still be rotated to help block a hacker from being successful.

Protect Data at Rest

There are two primary locations where data is stored at rest: the data store itself and the backup. In AWS, you have three things that should be encrypted: the database, the backups, and the file store. In RDS, enable encryption for the database to ensure backups will be encrypted. In S3, turn on the flag that marks the bucket as encrypted. If you’re using EBS, there’s a flag to enable encryption for that as well. These actions are all it takes to ensure that all data that is sitting on a disk is encrypted within AWS.

Protect Data in Transit

When transferring data, you should plan for a scenario where your network has been compromised. Fortunately, most data stores, be it through a REST api (like S3) or a database connection, provide an easy mechanism to use Transport Layer Security (TLS) to establish encrypted connections to secure data. In many cases, TLS can often be used as the authentication mechanism for applications as well, offering a stronger level of protection than a username and password. If for some reason you cannot use TLS, then you need to set up an encrypted tunnel using IPsec, or another encryption protocol, when transferring data.

Protect the Network

The first line of defense is preventing access to data in the first place. Make sure your data is in a private network that can’t be directly accessed. Further, add firewall rules (security groups) that limit access to the data store to only the services that need the data. This can be done for hosted solutions like S3 as well by configuring a bucket policy in Identity Access Management (IAM) or some other Access Control List (ACL).

Protect Secrets

Use a password vault to store credentials and implement a secondary authorization mechanism (like IAM roles) to enforce granular access permissions to the password vault.  Many of our clients use an encrypted SSM Parameter Store to store credentials, however, AWS Secrets Manager is also a good option. Using this method also makes it easy to automate password and key rotations.

Protect Customer Secrets

Protecting customer information may require an additional layer of protection. For example, you may not need to store a customer’s password but choose to store a unique hash of the password instead. If the password is lost or compromised, you will still need a method to change the password. 

For other types of sensitive data like banking, healthcare or any regulated information, you may need to encrypt the data with a tertiary encryption key before storing it in a database. This means backups are encrypted x3; inside the database, the backup itself, and the storage (S3) the backup onto which it is saved. For regulated environments, ensure that you discuss these options with your compliance officer.

Protect Logs

Logs are often an overlooked location for protection, but they are a place where passwords and other sensitive information, like credentials or bank account information, can be exposed in plain text. During normal operations, sensitive information is usually suppressed. However, if something goes wrong, you may change the log level to debug the application behavior.  That higher log level may reveal sensitive information as developers need to see the additional granularity when writing the software. So for any system that stores or accesses sensitive information, place a filter on your log storage that will automatically redact fields or potentially suspicious sequences of data (like four, 4 digit numbers separated by hyphens).

Protect Code

Similar to protecting your logs, putting checks in place for passwords, access keys, or other common expressions that provide sensitive information is important. The first goal is to ensure these types of data never leave your computer and make it to a remote server. One of the easiest ways to accomplish this is to implement git hooks, or whatever mechanism your version control system (VCS) uses. This will ensure that sensitive information is not in the source code before being pushed to the code repository.  Running it alongside a linter is a great time to check for this.  However, since those run locally, you should have an automated workflow also check for the same sensitive information in the code after being pushed to your VCS service. This could be done with GitHub workflows, TravisCI, CodePipeline, or any similar part of your CI/CD solutions.

Clean Up Data

Current data is an asset. However, old data is a liability. Set rules to clean up data based on your internal retention policies and/or regulatory requirements. You should have an automated process that specifically prunes old data from databases and other data stores.  Also, set up lifecycle rules in S3 to automatically archive old data to Glacier for long term retention and then purged based on your data retention policies. However, there’s an additional reason to do this.  Extra data costs money.  It costs more money to store and it has higher computational and memory requirements to process. So don’t skip data cleanup, or hold onto data that might be helpful but has no purpose now. Clean up old data the moment it is no longer required. If a new requirement comes along looking to store data for longer, that is the time to change your policies and processes.

Bring in an Outside Expert

Many times, tradition creeps in where it shouldn’t. You get accustomed to just grabbing a password, or having an internal portal that can access data for you. Maybe there are development tools that are extremely helpful when creating your software, but those tools work in production too and can potentially expose information. There are many ways that habits, or a rush to meet a deadline, can cause steps to become overlooked or join the pool of TODO’s in your codebase.  Bringing in an outside company to help review your security will shine a light on these areas that are unknowingly causing significant risk to your company.

Foghorn Consulting has significant experience in providing security assessments through our Fog360 offering. We recommend annual Fog360 security audits to discover any areas for improvement, ergo prevention over cure. 

In addition we can help architect, design, and implement solutions that will position your organization to better secure your infrastructure. By utilizing prebuilt libraries we have at hand some solutions can be implemented very quickly, while others can be tailored to your specific requirements. Secure some time with one of our cloud enablement pros to learn more about how Foghorn can assist.

Thank you for reading, and keep your data safe.

A Senior Engineer at Foghorn, Daniel is a security thought leader having established and led security teams and compliance audits since 2006 for Fortune 50 companies and Silicon Valley startups.