Implement CSF B24

Implement Cybersecurity Framework skill B24,
"Handle sensitive data responsibly by applying data anonymization,
encryption techniques, and adhering to data protection regulations
and organizational security policies."

Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>

Author: david-a-wheeler

docs/lfd121.md

@@ -480,7 +480,7 @@ The first step for addressing privacy is acknowledging that privacy is important
 
 The simplest approach to privacy, and often the best starting point, is to *not* collect information about individuals unless you need it. If you do not collect the information, you cannot divulge it later, and you do not have to determine how to prevent its misuse. Eliminating it is best from a privacy point of view.
 
-Failing that, minimize personal information to what you absolutely require. If you must collect information about individuals, you must provide a variety of protections for them, at the very least those required by law and regulation. This can be complicated, because many laws and regulations may apply.
+Failing that, minimize personal information to what you absolutely require. If you must collect information about individuals, you must provide a variety of protections for them, at the very least those required by law and regulation. Often the focus is on Personally Identifiable Information (PII). PII is any information that can be used to identify, contact, or locate a specific individual, or that can be combined with other sources to uniquely identify a person. Protecting this data in practice can be complicated, because many laws and regulations may apply.
 
 #### Privacy Laws and Regulations
 
@@ -598,6 +598,18 @@ Here are some resources for learning more about the GDPR:
 
 * [California Online Privacy Protection Act, Chapter 22. Internet Privacy Requirements [22575-22579]](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=BPC&sectionNum=22575)
 
+#### Anonymization and Pseudonymization
+
+To handle sensitive data responsibly and adhere to regulations like the GDPR, you should apply techniques that reduce the risk to individuals if a data breach occurs. Two primary techniques are anonymization and pseudonymization:
+
+* Anonymization is the process of irreversibly altering personal data so that the "data subject" can no longer be identified, either directly or indirectly. Once data is truly anonymized, it is no longer considered personal data under many regulations.
+
+* Pseudonymization replaces identifying fields within a record with one or more artificial identifiers, or pseudonyms. Unlike anonymization, pseudonymization is reversible; the original identity can be recovered if you have access to a separate "key" or mapping table.
+
+Again, minimize personal data so it's hard to re-identify someone. Handle sensitive data responsibly throughout the lifecycle. For example, when creating test datasets from production data, anonymize the data so that testers never handle real PII. If you need to track user behavior for analytics while maintaining privacy, you might pseudonymize user IDs so that individual actions can be correlated without revealing the user's actual identity.
+
+Adhering to these techniques helps software comply with laws, regulations, and organizational security policies, as well as minimizing the impact of potential data exposure.
+
 #### Telemetry
 
 Software sometimes includes functionality to collect telemetry data, that is, data about how the software is used or performing. Telemetry data is often collected through a “phone home” mechanism built into the software itself, where the software sends this data elsewhere.
@@ -3424,7 +3436,14 @@ Data for logs often includes data from untrusted users, and attackers may intent
 
 Greatly limit who can read the logs; they generally should not be readable by all. However, even doing this is not enough.
 
-As a general rule, don’t include passwords or very sensitive data in logs. Since people may need to review logs later, log data sometimes gets out to more people than you might expect. Sometimes logs are revealed to others, and the recipient may use the logs in unauthorized ways. Beware of including data if it might include passwords or private keys! If you must include possibly-sensitive data, consider logging the data as an encrypted or cryptographically hashed value, so that people who receive the log cannot easily use it in an unauthorized way.
+As a general rule, don’t include passwords or very sensitive data in logs. Since people may need to review logs later, log data sometimes gets out to more people than you might expect. Sometimes logs are revealed to others, and the recipient may use the logs in unauthorized ways. Beware of including data if it might include passwords or private keys! If you must include possibly-sensitive data, handle it responsibly. Adhere to organizational security policies and data protection regulations where they apply. Consider logging the data as an encrypted or cryptographically hashed value, so that people who receive the log cannot easily use it in an unauthorized way.
+
+Two other common techniques for handling sensitive data in logs are data masking and redaction:
+
+* Data Masking replaces sensitive data with structurally similar but inauthentic data. For example, a credit card number might be masked so that only the last four digits are visible. This allows the data to remain useful for basic identification or troubleshooting without exposing the entire secret.
+* Redaction is the total removal of sensitive information from a record. For example, an error log might redact a user's password or social security number entirely, replacing the sensitive value with a placeholder like [REDACTED] or [SENSITIVE DATA REMOVED].
+
+You should implement these techniques as close to the data source as possible. For example, configure your logging library to automatically mask or redact known sensitive fields before the data is even written to a file or sent over a network. This proactive approach minimizes the impact if your log files are later exposed.
 
 🔔 *Security Logging and Monitoring Failures* is 2021 OWASP Top 10 #9. *Insufficient logging and monitoring* is 2017 OWASP Top 10 #10. *Inclusion of Sensitive Information in Log Files*, [CWE-532](https://cwe.mitre.org/data/definitions/532.html), is such a common cause of security vulnerabilities that it is 2021 CWE Top 25 #39 and 2019 CWE Top 25 #35.
 
@@ -4752,7 +4771,7 @@ That said, in *some* systems cryptography is a vitally important part of making
 
 Failing to use cryptography when it should be used is, by itself, a security vulnerability. Information that is not encrypted is often called “cleartext” or “plaintext”.  In many networks (including the Internet and its subset the world wide web), as well as many storage systems (such as backups), plaintext can be intercepted and modified by unauthorized parties.
 
-For example, we typically want our web browsers and web servers to have an encrypted connection between each other so that the information is confidential from others, cannot be modified without detection, and so that at least the web browser can have high confidence that it is communicating with the correct web server. Many systems manage sensitive data such as financial data, healthcare data, and personally-identifiable information (PII). Cryptography is often an important part of protecting this data so it cannot be easily read or undetectably modified by others.
+For example, we typically want our web browsers and web servers to have an encrypted connection between each other so that the information is confidential from others, cannot be modified without detection, and so that at least the web browser can have high confidence that it is communicating with the correct web server. Many systems manage sensitive data such as financial data, healthcare data, and personally-identifiable information (PII). Cryptography is often an important part of protecting this data so it cannot be easily read or undetectably modified by others. Applying these encryption techniques is often a requirement for adhering to data protection regulations and organizational security policies. To handle sensitive data (like PII) responsibly, you should ensure that it's encrypted, both in transit and at rest, whenever practical.
 
 However, there are many people who know how to attack cryptographic systems. Using cryptography incorrectly can sometimes lead to having false confidence in an insecure system. What’s worse, incorrectly-used cryptography can sometimes be hard to spot if you are not an expert, so these mistakes may be exploited for long periods of time.
 
@@ -5563,7 +5582,7 @@ When operating:
 
 * When you receive a vulnerability report, process and fix it in a timely manner. Then give the reporter public credit unless the reporter requests otherwise.
 
-When disposing, make sure you fully destroy any data you are supposed to destroy. Just removing a file does not actually remove its contents from most storage devices.
+When disposing, make sure you *fully* destroy any data you are supposed to destroy. To handle data responsibly at its end-of-life, you must ensure that the data cannot be later recovered by an attacker. Often just deleting or removing a file is not enough; that does not actually remove its contents from most storage devices. To ensure that the data cannot be recovered, consider crypto-shredding (irreversibly destroying the encryption keys), repeatedly overwriting the storage area with random data, or destroying the storage device (e.g., by burning it).
 
 > 😱 STORY TIME: 2024 Crowdstrike-related IT outages