Cobalt Crowdsourced Application PentestCobalt Crowdsourced Application PentestCobalt Crowdsourced Application Pentest

Back to Main

Preparing for the Next Data Breach

Mike Shema
Jun 6, 2018

Data breaches happen. That doesn’t mean it’s acceptable for application owners to neglect security or be cynical about protecting data. It means that app owners need to be aware of how their organizations and the data they collect might be targeted. They need to review what controls and processes they have in place to make attacks more difficult or more easy to detect. And it means they should be ready to respond quickly and effectively in the event of a breach.

Data Contamination

Be Practical

Data you don’t possess can’t be compromised. Of course, many apps are driven by data or need to collect data in order to provide value. But in many cases the utility of data degrades over time. There’s a point where the liability of holding onto data outweighs its value.

One way to approach data handling is reframing the metaphor you associate with it. For example, data can be toxic — accumulate as little as possible, be careful about collecting large doses. Perhaps it’s radioactive — it contaminates every system it touches and therefore those systems need to be protected. Or maybe you consider it digital oil — a valuable, finite resource that has significant negative consequences when it spills.

In any case, be aware of the nature of the data you collect, why it’s being collected, where it’s being stored, and when you can delete it. Again, these are easier said than done, but laying out a framework for the lifecycle of data (from collection to deletion) will help guide how you protect it.

Be Proactive

Encryption is necessary to protect data. It’s not sufficient (strong access control and authorization schemes are important as well), but it’s a baseline expectation for handling data.

Encrypt communications — HTTPS should be enabled and enforced by default with an HSTS header. The Let’s Encrypt project has made it easier to deploy HTTPS sites as part of a DevOps process. It provides free certs, removing objections of initial cost, and its ACME protocol enables automation to maintain, renew, and revoke certs.

Encrypt storage — Data lands in surprising places, from the typical databases, and data stores to AWS S3 buckets that notoriously expose their content due to misconfigurations. Cloud services have made it easier to deploy to instances running encrypted filesystems and interacting with APIs that manage hardware-based key stores. Of course, apps need to work on decrypted data (unless you’ve moved into more sophisticated crypto), so don’t expect this to be the only solution you need.

Protect secrets — Encryption will need private keys and shared secrets. APIs will need access tokens. Make it unnecessary to place credentials in code. Monitor commits and repos for accidental inclusion of private keys, tokens, and passwords.

Rotate secrets — Have a process to revoke and replace compromised or exposed secrets. If you’re encrypting data, but it takes two weeks to rotate encryption keys, then that’s a dangerous level of exposure.

Conduct security testing — Run pen tests to evaluate the baseline and recheck at key milestones. Maintain a bug bounty program to manage vulnerability reports. Use red team exercises to check for gaps in your monitoring and detection capabilities.

Be Prepared

Being prepared means you don’t have to make every decision and take every action under pressure. During a breach investigation there’ll always be pressure and time constraints and legal questions, but being prepared with data and how to answer basic questions will free up time to tackle the challenges you didn’t anticipate.

Just following the few steps of finding out when data is being collected and where it resides will reveal who the stakeholders are that may need to be part of the conversation when a breach occurs. It also helps identify who should be responsible for encrypting communications and storage. The modern DevOps model builds security into processes and technology. Security teams become participants in the CI/CD process, not gatekeepers who only drop in for random inspections.

Discover what you don’t know, whether it’s a data store that’s been forgotten and ill-protected or access controls that lend more access than control. Use a pen test to review the security of your apps. Consider a bounty program to enable a continuous feedback loop. Engage a red team to test the technology and processes you’ve put in place to detect and respond to breaches.

All of these exercises will help you in the unfortunate event that a breach occurs. They’ll also help focus on recovery and improvement instead of falling into blame and chaos.