Missing concept #1: Obscurity

[adamshostack]

I think "don't rely on obscurity" is a tremendously important part of "most important areas of concern that software developers must be aware of. "

[andreashappe]

I agree.. just thinking about your other comments too.

What about the following suggestions: rename 'c4: use secure architecture patterns' into something 'c4: Seek Secure Architectures' with the following sub-points:

• preliminary: document your architecture
• follow the KISS principle (for transparency, maintenance, easier reasoning/decomposability, etc.)
• security by obscurity is no scurity at all
• think about your trust boundaries
• in "related work/background" we could add the 'secure architecture patterns' as examples

We don't have threat modelling directly within the proactive controls as the consensus was that while it is important, it is not 100% fitting (we didn't want a dev looking up the document to find potential controls to see "step 1: perform threat modelling and find your own controls" and then turn away). We should have mentioned threat modelling in the introduction (related OWASP documents) and mention that it is an important step towards security (feel free to add updates to that section too) as IMHO it feels very wrong to not mention it in the document.

What do you think? cheers and thanks for your input, Andreas

[adamshostack]

I think not mentioning threat modeling (except maybe as a #11 :) makes sense, or maybe mention it in related work. Making this actionable is a good north star.

With this change, I might extend "think about your trust boundaries" to "think about your trust boundaries and where security controls are implemented." which is too wordy,

[jmanico]

For proactive controls I want to aim for the positive like “use secure architectures” or similar. Any other suggestions in the vein?

[andreashappe]

@adamshostack : we had 'threat modeling' as a special appendix, but I fear that noone ever reads those, so having it references up front in "related documents" might be even better (; ad wording: "implement security controls where they matter"?

@jmanico: I suggest "make your architecture secure" as main title and add the content as expected (as well as reference security patterns). There was another contributor that mentioned "make the secure thing easy to do" which would also fit well into this (new proposed) section

[adamshostack]

I think "Make your architecture secure" lacks the actionability you want. What does that mean? what do I do? Maybe a set of bullets:

• Identify and minimize your exposed components ("attack surface")
• Clearly articulate what's trusted to do what, and ensure those relationships are enforced (trust boundaries deliniate blast radius and are enforced by controls, such as firewalls or gateways.)
• Attenuate what's allowed by careful validation at each step.
• Go deeper with threat modeling mnemonics like stride or methodologies like stride per element

I'm not sure if those are the right ones.

On Thu, Apr 11, 2024 at 02:14:31PM -0700, Andreas Happe wrote:

@adamshostack : we had 'threat modeling' as a special appendix, but I fear that noone ever reads those, so having it references up front in "related documents" might be even better (; ad wording: "implement security controls where they matter"?

@jmanico: I suggest "make your architecture secure" as main title and add the content as expected (as well as reference security patterns). There was another contributor that mentioned "make the secure thing easy to do" which would also fit well into this (new proposed) section

-- Reply to this email directly or view it on GitHub: https://github.com/OWASP/www-project-proactive-controls/issues/32#issuecomment-2050563748 You are receiving this because you were mentioned.

Message ID: @.***>

-- Adam Shostack • +1 917 391 2168 Level up your security 🎓 https://shostack.org/training/open My next book is out now: ✨ Threats: What Every Engineer Can Learn from Star Wars ✨ threatsbook.com

[andreashappe]

@adamshostack not being a native English speaker, I am very open for suggestions for better titles (;

I know it's not putting a positive spin on it, but "Don't build your architecture on quicksand" is the way I think about it. A secure, understandable and maintainable architecture is creating a secure foundation (or grounding) for the rest of the dev work.

[adamshostack]

Not sure... maybe design for attack or design to resist attack? Address security from the start?

[andreashappe]

"Design for Resilience"? (to become buzzword-complete)

[andreashappe]

I've created a branch and started with some restructuring: https://github.com/OWASP/www-project-proactive-controls/blob/rewrite-secure-architecture/v4/en/c4-secure-architecture.md

I added a high-level overview to the 'design' section about general principles and added some of the mentioned topics in 'implementation'. The previous 'use architecture patterns' is now a subsection in the 'implementation' section, maybe it should also be mentioned in 'description' like "don't reinvent the wheel".

Commits to that branch that flesh out the different areas would be highly appreciated (; @adamshostack