Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve #2007 by clarifying the protection level concept for data storage and splitting to documentation and implementation requirements #2052

Merged
merged 1 commit into from
Sep 2, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion 5.0/en/0x10-V1-Architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ Architectural requirements are intrinsic to the entire code base, and thus diffi
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
| **1.8.1** | [MODIFIED, MERGED FROM 8.3.4, LEVEL L2 > L1] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data. | ✓ | ✓ | ✓ | 213 |
| **1.8.2** | [MODIFIED] Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | | ✓ | ✓ | |
| **1.8.2** | [MODIFIED, SPLIT TO 8.1.9] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | | ✓ | ✓ | |

## V1.9 Communications Architecture

Expand Down
2 changes: 1 addition & 1 deletion 5.0/en/0x15-V7-Error-Logging.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ For the specific information which should be included in a log entry, refer to e

| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
| **7.1.1** | [MODIFIED, MERGED FROM 7.1.2] Verify that the application does not log credentials, payment details or any data defined as sensitive based on local privacy laws or relevant security policy. Session tokens should only be stored in logs in an irreversible, hashed form. | ✓ | ✓ | ✓ | 532 |
| **7.1.1** | [MODIFIED, MERGED FROM 7.1.2] Verify that when logging sensitive data, the application considers the protection level of the data. For example, it may not be allowed to log certain data such as credentials or payment details. Other data such as session tokens may only be logged having been hashed or masked, either in full or partially. | ✓ | ✓ | ✓ | 532 |
| **7.1.2** | [DELETED, MERGED TO 7.1.1] | | | | |
| **7.1.3** | [MOVED TO 7.2.3] | | | | |
| **7.1.4** | [MODIFIED] Verify that each log entry includes necessary metadata that would allow for a detailed investigation of the timeline when an event happens. | | ✓ | ✓ | 778 |
Expand Down
1 change: 1 addition & 0 deletions 5.0/en/0x16-V8-Data-Protection.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ Ensure that a verified application satisfies the following high-level data prote
| **8.1.6** | [DELETED, NOT IN SCOPE] | | | | |
| **8.1.7** | [ADDED] Verify that caching mechanisms are configured to only cache responses which have the correct content type and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when an non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | | ✓ | ✓ | 444 |
| **8.1.8** | [ADDED] Verify that defined sensitive data is not sent to untrusted parties (e.g. user trackers) to prevent unwanted collection of data outside of the application's control. | | ✓ | ✓ | 200 |
| **8.1.9** | [ADDED, SPLIT FROM 1.8.2] Verify that controls around sensitive data are implemented as defined in the documentation for the specific data's protection level. | | ✓ | ✓ | |

## V8.2 Client-side Data Protection

Expand Down
Loading