Practical Cloud Security

Moderate

This information should not be disclosed outside of the organization without the proper nondisclosure agreements. In many cases (especially in larger organiza‐ tions) this type of data should be disclosed only on a need-to-know basis within the organization. In most organizations, the majority of information will fall into

this category. Here are some examples:

• Detailed information on how your information systems are designed, which

may be useful to an attacker

• Information on your personnel, which could provide information to attack‐

ers for phishing or pretexting attacks

1 Ransomware is both an availability and an integrity breach, because it uses unauthorized modifications of

your data in order to make it unavailable.

2 If you have unlimited resources, please contact me!

14 | Chapter 2: Data Asset Management and Protection

• Routine financial information, such as purchase orders or travel reimburse‐

ments, which might be used, for example, to infer that an acquisition is likely

High

This information is vital to the organization, and disclosure could cause signifi‐ cant harm. Access to this data should be very tightly controlled, with multiple safeguards. In some organizations, this type of data is called the "crown jewels."

Here are some examples:

• Information about future strategy, or financial information that would pro‐

vide a significant advantage to competitors

• Trade secrets, such as the recipe for your popular soft drink or fried chicken

• Secrets that provide the "keys to the kingdom," such as full access credentials

to your cloud infrastructure

• Sensitive information placed into your hands for safekeeping, such as your

customers' financial data

• Any other information where a breach might be newsworthy
Note that laws and industry rules may effectively dictate how you classify some infor‐

mation. For example, the European Union's General Data Protection Regulation (GDPR) has many different requirements for handling personal data, so with this sys‐ tem you might choose to classify all personal data as "moderate" risk and protect it accordingly. Payment Card Industry (PCI) requirements would probably dictate that you classify cardholder data as "high" risk if you have it in your environment.

Also, note that there are cloud services that can help with data classification and pro‐

tection. As examples, Amazon Macie can help you find sensitive data in S3 buckets, and the Google Cloud Data Loss Prevention API can help you classify or mask cer‐ tain types of sensitive data.

Whatever data classification system you use, write down a definition of each classifi‐

cation level and some examples of each, and make sure that everyone generating, col‐ lecting, or protecting data understands the classification system.

Relevant Industry or Regulatory Requirements

This is is a book on security, not compliance. As a gross overgeneralization, compli‐

ance is about proving your security to a third party—and that's much easier to accomplish if you have actually secured your systems and data. The information in this book will help you with being secure, but there will be additional compliance work and documentation to complete after you've secured your systems.

Data _dent_fic_t_on and C__ss_fic_t_on | 15

However, some compliance requirements may inform your security design. So, even

at this early stage, it's important to make note of a few industry or regulatory require‐

ments:

EU GDPR

This regulation may apply to the personal data of any European Union or Euro‐ pean Economic Area citizen, regardless of where in the world the data is. The GDPR requires you to catalog, protect, and audit access to "any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier." The techniques in this chapter may help you meet some GDPR requirements, but you must make sure that you include relevant personal data as part of the data you're protecting.