ARCH and CODE first draft control group definitions

Author: JeffreyShran

document/0.1/04-TASVS-ARCH.md

@@ -4,6 +4,7 @@
 
 Architecture and threat modeling are inextricably linked. Threat modeling informs architectural decisions, while architecture provides the context for identifying and addressing threats systematically. This symbiotic relationship is essential for delivering secure software and systems that meet their intended design goals.
 
+
 ## Testing Checklist
 
 | TASVS-ID       | Description                                                                                                                                 | L1 | L2 | L3 |
@@ -16,4 +17,46 @@ Architecture and threat modeling are inextricably linked. Threat modeling inform
 | TASVS-ARCH-1.5 | Threat model checked-in to source code repository.                                                                                          | X  | X  | X  |
 | TASVS-ARCH-1.6 | Threat model updated regularly as part of a documented process within development team's SSDLC.                                             |    | X  | X  |
 
+## Control Group Definitions
+
+### TASVS-ARCH-1.1 
+
+#### What defines "Low Fidelity" Modeling?
+
+"Low Fidelity" modeling greatly reduces the effort to create an initial threat model. A "Low Fidelity" system model still includes assets, links, and trust boundaries, but with limited attributes.
+ 
+Recommended "Low Fidelity" baseline:
+- Define data assets with CIA (confidentiality/integrity/availability)
+- Define technical assets with technology.
+- Define communication links with protocol.
+- Place technical assets inside trust boundaries.
+
+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
+
+"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
+
+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
+
+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
+
+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
+
+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.
+
+
 \newpage{}

document/0.1/05-TASVS-CODE.md

@@ -18,4 +18,36 @@
 | 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
+
+TBC
+
+### TASVS-CONF-1.2
+
+TBC
+
+### TASVS-CONF-1.3
+
+TBC
+
+### TASVS-CONF-1.4
+
+TBC
+
+### TASVS-CONF-1.5
+
+TBC
+
+### TASVS-CONF-1.6
+
+TBC
+
+### TASVS-CONF-1.7
+
+TBC
+
+
 \newpage{}

document/0.1/06-TASVS-CONF.md

@@ -19,4 +19,39 @@
 | 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.                 | X  | X  | X  |
 | TASVS-CRYPTO-3.2 | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | X  | X  | X  |
 
+
+## Control Group Definitions
+
+### TASVS-CRYPTO-1.1
+
+TBC
+
+### TASVS-CRYPTO-2.1
+
+TBC
+
+### TASVS-CRYPTO-2.2
+
+TBC
+
+### TASVS-CRYPTO-2.3
+
+TBC
+
+### TASVS-CRYPTO-2.4
+
+TBC
+
+### TASVS-CRYPTO-3.1
+
+TBC
+
+### TASVS-CRYPTO-3.2
+
+TBC
+
+
+
+
+
 \newpage{}

document/0.1/07-TASVS-CRYPTO.md

@@ -27,4 +27,70 @@
 | TASVS-NETWORK-4.3 | Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL injection attacks.                                                                                                  | X  | X  | X  |
 | TASVS-NETWORK-4.4 | Verify that the thick client doesn't expose services on the network like debugging features, even if bound to the local host.                                                                                                                                                          | X  | X  | X  |
 
+
+## Control Group Definitions
+
+### TASVS-NETWORK-1.1
+
+TBC
+
+### TASVS-NETWORK-1.2
+
+TBC
+
+### TASVS-NETWORK-2.1
+
+TBC
+
+### TASVS-NETWORK-2.2
+
+TBC
+
+### TASVS-NETWORK-2.3
+
+TBC
+
+### TASVS-NETWORK-2.4
+
+TBC
+
+### TASVS-NETWORK-2.5
+
+TBC
+
+### TASVS-NETWORK-2.6
+
+TBC
+
+### TASVS-NETWORK-2.7
+
+TBC
+
+### TASVS-NETWORK-3.1
+
+TBC
+
+### TASVS-NETWORK-3.2
+
+TBC
+
+### TASVS-NETWORK-4.1
+
+TBC
+
+### TASVS-NETWORK-4.2
+
+TBC
+
+### TASVS-NETWORK-4.3
+
+TBC
+
+### TASVS-NETWORK-4.4
+
+TBC
+
+
+
+
 \newpage{}

document/0.1/08-TASVS-NETWORK.md

@@ -19,4 +19,44 @@
 | TASVS-STORAGE-2.1 | DLL Replacement: Swapping a genuine DLL with a malicious one, optionally using DLL Proxying to preserve the original DLL's functionality.                                                                                         | X  | X  | X  |
 | TASVS-STORAGE-2.2 | <br>DLL Search Order Hijacking: Placing the malicious DLL in a search path ahead of the legitimate one, exploiting the application's search pattern.                                                                              | X  | X  | X  |
 
+## Control Group Definitions
+
+### TASVS-STORAGE-1.1
+
+TBC
+
+### TASVS-STORAGE-1.2
+
+TBC
+
+### TASVS-STORAGE-1.3
+
+TBC
+
+### TASVS-STORAGE-1.4
+
+TBC
+
+### TASVS-STORAGE-1.5
+
+TBC
+
+### TASVS-STORAGE-1.6
+
+TBC
+
+### TASVS-STORAGE-1.7
+
+TBC
+
+### TASVS-STORAGE-2.1
+
+TBC
+
+### TASVS-STORAGE-2.2
+
+TBC
+
+
+
 \newpage{}