updated layout of defs, all defs have content, removed TASVS-CONF-1.7 extended TASVS-CODE-3.1 to replace

Author: JeffreyShran

document/0.1/04-TASVS-ARCH.md

@@ -19,7 +19,9 @@ Architecture and threat modeling are inextricably linked. Threat modeling inform
 
 ## Control Group Definitions
 
-### TASVS-ARCH-1.1 
+### *TASVS-ARCH-1 - Threat Modeling*
+
+### TASVS-ARCH-1.1 - Completed a low fidelity threat model for thick client.
 
 #### What defines "Low Fidelity" Modeling?
 
@@ -33,28 +35,28 @@ Recommended "Low Fidelity" baseline:
 
 That's it! Later, continue to elaborate the model and raise fidelity score. Remember the system model is a means to an end - identifying threats.
 
-### TASVS-ARCH-1.2
+### TASVS-ARCH-1.2 - Completed a high fidelity threat model for thick client which is in currently in production.
 
 "high fidelity" threat modeling is a more detailed and comprehensive approach to threat modeling. It includes all the elements of a low-fidelity model but adds more detail and context to the model. This includes:
 
 - Detailed data flow diagrams
 - Detailed trust boundaries
 - Detailed threat identification
 
-### TASVS-ARCH-1.3
+### TASVS-ARCH-1.3 - Threat model includes server-side components and dependencies (cloud APIs, OIDC provider, file storage, etc.).
 
 Server-side components and dependencies should be included in the threat modeling process to ensure that all potential threats are identified and addressed. This includes cloud APIs, OIDC providers, file storage, and any other external services that the thick client interacts with. By including these components in the threat model, you can identify potential vulnerabilities and design security controls to mitigate them.
 
-### TASVS-ARCH-1.4
+### TASVS-ARCH-1.4 - Threat modeling process included all phases (system modeling, auto-threat identification, manual threat identification, threat mitigation).
 
 Phases of threat modeling include system modeling, auto-threat identification, manual threat identification, and threat mitigation. Each phase is essential to the overall threat modeling process and should be completed thoroughly to ensure that all potential threats are identified and addressed.
 
-### TASVS-ARCH-1.5
+### TASVS-ARCH-1.5 - Threat model checked-in to source code repository.
 
 The threat model should be checked into the source code repository to ensure that it is accessible to all members of the development team. This allows team members to review the threat model and provide feedback, as well as track changes to the model over time.
 
 
-### TASVS-ARCH-1.6
+### TASVS-ARCH-1.6 - Threat model updated regularly as part of a documented process within development team's SSDLC.
 
 The threat model should be updated regularly as part of a documented process within the development team's SSDLC. This ensures that the threat model remains current and relevant as the thick client evolves and new threats emerge. Regular updates to the threat model help to ensure that the thick client remains secure and resilient to potential threats.
 

document/0.1/05-TASVS-CODE.md

@@ -3,7 +3,9 @@
 
 ## Control Objective
 
+Ensure that the application's configuration management processes are secure, reliable, and automated. This includes verifying secure build and deployment processes, proper compiler flag configurations, automated deployment scripts, removal of unnecessary features, sourcing third-party components from trusted repositories, maintaining a Software Bill of Materials (SBOM), and keeping all software components up-to-date.
 
+This control objective helps mitigate security vulnerabilities, ensures compliance, and maintains the integrity and availability of the application.
 
 ## Testing Checklist
 
@@ -16,38 +18,35 @@
 | TASVS-CONF-1.4 | Verify that all unneeded features, documentation, sample applications and configurations are removed.                                                                                                                                                                              | X  | X  | X  |
 | TASVS-CONF-1.5 | Verify that third party components come from pre-defined, trusted and continually maintained repositories.                                                                                                                                                                         | X  | X  | X  |
 | TASVS-CONF-1.6 | Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use.                                                                                                                                                                                 | X  | X  | X  |
-| TASVS-CONF-1.7 | Ensure that all software components, libraries, frameworks, and runtimes used in the application are up-to-date and not end-of-life or obsolete. Outdated or obsolete components can introduce security vulnerabilities, performance issues, and compatibility problems.           | X  | X  | X  |
 
 
 ## Control Group Definitions
 
-### TASVS-CONF-1.1
+### *TASVS-CONF-1 - General Configuration Checks*
 
-TBC
+### TASVS-CONF-1.1 - Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI/CD automation, automated configuration management, and automated deployment scripts.
 
-### TASVS-CONF-1.2
+Build and deployments processes should be automated, secure, and repeatable. This includes using CI/CD automation, automated configuration management, and automated deployment scripts. These processes help ensure that the application is built and deployed consistently and securely, reducing the risk of errors and vulnerabilities.
 
-TBC
+### TASVS-CONF-1.2 - Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.
 
-### TASVS-CONF-1.3
+Compiler flags should be configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found. These protections help prevent common security vulnerabilities such as buffer overflows and format string vulnerabilities.
 
-TBC
+### TASVS-CONF-1.3 - Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.
 
-### TASVS-CONF-1.4
+The application, configuration, and all dependencies should be able to be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion. This ensures that the application can be quickly restored in the event of a failure or disaster, reducing downtime and ensuring business continuity.
 
-TBC
+### TASVS-CONF-1.4 - Verify that all unneeded features, documentation, sample applications and configurations are removed.
 
-### TASVS-CONF-1.5
+Unneeded features, documentation, sample applications, and configurations should be removed from the application. This helps reduce the attack surface of the application, improve performance, and simplify maintenance. Removing unnecessary features also reduces the risk of security vulnerabilities and compliance issues.
 
-TBC
+### TASVS-CONF-1.5 - Verify that third party components come from pre-defined, trusted and continually maintained repositories.
 
-### TASVS-CONF-1.6
+Third-party components should come from pre-defined, trusted, and continually maintained repositories. This helps ensure that the components are secure, reliable, and up-to-date. Sourcing components from trusted repositories reduces the risk of introducing security vulnerabilities, malware, or other issues into the application.
 
-TBC
+### TASVS-CONF-1.6 - Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use.
 
-### TASVS-CONF-1.7
-
-TBC
+A Software Bill of Materials (SBOM) should be maintained of all third-party libraries in use. An SBOM provides a detailed inventory of all software components used in the application, including third-party libraries, frameworks, and runtimes. This helps track dependencies, identify vulnerabilities, and ensure compliance with licensing requirements.
 
 
 \newpage{}

document/0.1/06-TASVS-CONF.md

@@ -2,14 +2,14 @@
 
 ## Control Objective
 
-
+Ensure that all cryptographic operations, including communication, storage, and general usage, adhere to current best practices and standards to maintain data confidentiality, integrity, and security.
 
 ## Testing Checklist
 
 | TASVS-ID         | Description                                                                                                                                       | L1 | L2 | L3 |
 | ---- | ------------- | - | - | - |
 | TASVS-CRYPTO-1   | Communication                                                                                                                                     |    |    |    |
-| TASVS-CRYPTO-1.1 | The TLS settings are in line with current best practices,                                                                                         | X  | X  | X  |
+| TASVS-CRYPTO-1.1 | The TLS settings are in line with current best practices.                                                                                         | X  | X  | X  |
 | TASVS-CRYPTO-2   | Storage                                                                                                                                           |    |    |    |
 | TASVS-CRYPTO-2.1 | The thick client doesn't re-use the same cryptographic key for multiple purposes.                                                                 | X  | X  | X  |
 | TASVS-CRYPTO-2.2 | All random values are generated using a sufficiently secure random number generator.                                                              | X  | X  | X  |
@@ -22,36 +22,37 @@
 
 ## Control Group Definitions
 
-### TASVS-CRYPTO-1.1
-
-TBC
+### *TASVS-CRYPTO-1 - Communication*
 
-### TASVS-CRYPTO-2.1
+### TASVS-CRYPTO-1.1 - The TLS settings are in line with current best practices.
 
-TBC
+TLS should be version 1.2 or higher, with secure cipher suites and secure configurations. This includes disabling insecure protocols and cipher suites, enabling Perfect Forward Secrecy (PFS), and using strong cryptographic algorithms. TLS should be configured to provide secure communication between the thick client and the server, protecting data confidentiality and integrity.
 
-### TASVS-CRYPTO-2.2
+### TASVS-CRYPTO-2.1 - The thick client doesn't re-use the same cryptographic key for multiple purposes.
 
-TBC
+Cryptographic keys should not be re-used for multiple purposes, as this can weaken the security of the encryption. Each key should be used for a specific purpose and should not be shared between different cryptographic operations. Re-using keys can increase the risk of key compromise and make it easier for attackers to decrypt sensitive data.
 
-### TASVS-CRYPTO-2.3
+### TASVS-CRYPTO-2.2 - All random values are generated using a sufficiently secure random number generator.
 
-TBC
+Random values should be generated using a secure random number generator (RNG) that provides sufficient entropy to ensure randomness and unpredictability. Insecure or predictable random values can weaken the security of cryptographic operations and make it easier for attackers to guess or manipulate sensitive data.
 
-### TASVS-CRYPTO-2.4
+### TASVS-CRYPTO-2.3 - The thick client does not use cryptographic protocols or algorithms that are widely considered deprecated for security purposes.
 
-TBC
+Cryptographic protocols and algorithms that are widely considered deprecated or insecure should not be used in the thick client. This includes algorithms with known vulnerabilities, weak key lengths, or insecure modes of operation.
 
-### TASVS-CRYPTO-3.1
+### TASVS-CRYPTO-2.4 - The thick client does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.
 
-TBC
+Symmetric cryptography should not rely on hardcoded keys as the sole method of encryption in the thick client. Hardcoded keys can be easily extracted by attackers and used to decrypt sensitive data. Instead, cryptographic keys should be securely managed, stored, and protected to ensure the confidentiality and integrity of the encryption.
 
-### TASVS-CRYPTO-3.2
+### *TASVS-CRYPTO-3 - General*
 
-TBC
+### TASVS-CRYPTO-3.1 - Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
 
+Cryptographic modules should fail securely and handle errors in a way that does not enable Padding Oracle attacks. Error handling should be implemented securely to prevent attackers from exploiting vulnerabilities in the encryption and decryption process.
 
+### TASVS-CRYPTO-3.2 - Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.
 
+Industry-proven or government-approved cryptographic algorithms, modes, and libraries should be used in the thick client instead of custom-coded cryptography. Using standardized cryptographic algorithms and libraries helps ensure the security and reliability of the encryption, as these algorithms have been rigorously tested and validated by security experts.
 
 
 \newpage{}