CWE-359 Detail

The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.

Modes Of Introduction

Architecture and Design : OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Technologies

Class: Mobile (Undetermined)

Common Consequences

Potential Mitigations

Phases : Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.

Phases : Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

Detection Methods

Architecture or Design Review

Private personal data can enter a program in a variety of ways:

• Directly from the user in the form of a password or personal information
• Accessed from a database or other data store by the application
• Indirectly from a partner or other third party

If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.

Effectiveness : High

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness : High

Vulnerability Mapping Notes

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

NotesNotes

This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed. However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.

There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation.

Some types of private information include:

• Government identifiers, such as Social Security Numbers
• Contact information, such as home addresses and telephone numbers
• Geographic location - where the user is (or was)
• Employment history
• Financial data - such as credit card numbers, salary, bank accounts, and debts
• Pictures, video, or audio
• Behavioral patterns - such as web surfing history, when certain activities are performed, etc.
• Relationships (and types of relationships) with others - family, friends, contacts, etc.
• Communications - e-mail addresses, private messages, text messages, chat logs, etc.
• Health - medical conditions, insurance status, prescription records
• Account passwords and other credentials

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

References

REF-6

Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, Gary McGraw.
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf

REF-338

AOL man pleads guilty to selling 92m email addies
J. Oates.
https://www.theregister.com/2005/02/07/aol_email_theft/

REF-339

Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)
NIST.
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf

REF-340

Safe Harbor Privacy Framework
U.S. Department of Commerce.
https://web.archive.org/web/20010223203241/http://www.export.gov/safeharbor/

REF-341

Financial Privacy: The Gramm-Leach Bliley Act (GLBA)
Federal Trade Commission.
https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act

REF-342

Health Insurance Portability and Accountability Act (HIPAA)
U.S. Department of Human Services.
https://www.hhs.gov/hipaa/index.html

REF-343

California SB-1386
Government of the State of California.
http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

REF-267

SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology.
https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf

REF-172

Mobile App Top 10 List
Chris Wysopal.
https://www.veracode.com/blog/2010/12/mobile-app-top-10-list

REF-1047

General Data Protection Regulation
Wikipedia.
https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

REF-1048

California Consumer Privacy Act (CCPA)
State of California Department of Justice, Office of the Attorney General.
https://oag.ca.gov/privacy/ccpa

Submission

Modifications