Please enable JavaScript.
Coggle requires JavaScript to display documents.
ASVS V1Arch, Design and Threat Modeling, OWASP Proactive Controls, 4.…
ASVS V1
Arch, Design and Threat Modeling
-
-
6. Crypto Arch.
-
-
1.6.2 Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.
Protected by vault or API?
Keys and passwords are replaceable and part of re-encrypt's process.
which means when resetting passwords should got old pswd.
Treat all client's key, token or passwords as insecure. AND never use them to access sensitive data.
8. Data Protection Arch.
-
-
Define every protection level whose encryption requirements, intefrity requirements, privacy...
-
11. Business LogicArch.
-
Severe Function would not share unsynchronized state of auth, session or access control
-
-
14. Config Arch.
Well define every mechanisms like firewall rules, security controls or proxies to ensure the segregation.
-
-
-
Check if sandbox, containerize or isolate to prevent or delay attacks like deserialization attacks
Check the usage of unsupported, insecure or deprecated client-side tech like Flash
-
4. Access Control Arch.
-
-
Check every trust point whether implement access control or not.
Such as Gateway, Server etc.
Never do it on the client side.
-
-
5. I/O Arch.
-
-
-
So, where is trust boundary?
In ASVS, Trusted Service Layer
9. Communications Arch.
-
-
Secure Communication between two components especially one at AWS, the other at GCP
-
-
-
-