Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

A6 Sensitive Data Exposure

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:

  1. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
  2. Don't store sensitive data unnecessarily. Discard it as soon as possible. Data you don't have can't be stolen.
  3. Ensure strong standard algorithms and strong keys are used, and proper key management is in place. Consider using FIPS 140 validated cryptographic modules.
  4. Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcryptPBKDF2, or scrypt.
  5. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.
  6. Cryptography Storage Cheat Sheet

6.1 Introduction

6.1.1 Architectural Decision

6.2 Providing Cryptographic Functionality

6.2.1 Secure Cryptographic Storage Design

6.2.1.1 Rule - Only store sensitive data that you need

6.2.1.2 Rule - Use strong approved Authenticated Encryption

6.2.1.2.1 Rule - Use strong approved cryptographic algorithms

6.2.1.2.2 Rule - Use approved cryptographic modes

6.2.1.2.3 Rule - Use strong random numbers

6.2.1.2.4 Rule - Use Authenticated Encryption of data

6.2.1.3 Rule - Store a one-way and salted value of passwords

6.2.1.4 Rule - Ensure that the cryptographic protection remains secure even if access controls fail

6.2.1.5 Rule - Ensure that any secret key is protected from unauthorized access

6.2.1.5.1 Rule - Define a key lifecycle

6.2.1.5.2 Rule - Store unencrypted keys away from the encrypted data

6.2.1.5.3 Rule - Use independent keys when multiple keys are required

6.2.1.5.4 Rule - Protect keys in a key vault

6.2.1.5.5 Rule - Document concrete procedures for managing keys through the lifecycle

6.2.1.5.6 Rule - Build support for changing algorithms and keys when needed

6.2.1.5.7 Rule - Document concrete procedures to handle a key compromise

6.2.1.5.8 Rule - Limit quantity of data encrypted with one key

6.2.1.6 Rule - Follow applicable regulations on use of cryptography

6.2.1.6.1 Rule - Under PCI DSS requirement 3, you must protect cardholder data

This article provides a simple model to follow when implementing solutions to protect data at rest.

  • No labels