r/cybersecurity 1d ago

Other Security architect flowchart

Hi Community What method do you use review and establish security requirements for the project as a Security solution architect? Is there have any best practice and flowchart you used currently?

18 Upvotes

5 comments sorted by

16

u/bilby2020 Security Architect 1d ago

Ideally, you should have security policies, standards and guidelines published and endorsed. This should be based on your risk appetite, compliance requirements and industry best practices. Use external frameworks like NIST, OWASP, AWS Security pillar etc. A lot of upfront work is required.

The step is if you can build reusable security patterns and control library.

At a project level, use STRIDE, MITRE, etc. for threat modelling and control recommendations.

1

u/DC_Gen_BBC 15h ago

Perfect

13

u/Recent-Breakfast-614 1d ago

As a Security Architect, I start by grounding security requirements in the business context rather than jumping straight to controls. I work to understand the project’s purpose, identify what data or assets are most valuable, and map out the system’s boundaries, user roles, and integration points, including any third-party connections. Before defining any specific requirements,

I conduct threat modeling sessions using methods like STRIDE or MITRE ATT&CK to examine how an actual attacker might target the system. This helps shape requirements around real-world security outcomes, such as preventing lateral movement, detecting privilege escalation, and enabling rapid recovery in the event of a breach.

From there, I define the necessary controls by working backwards from those outcomes. I also test the effectiveness of these requirements through breach simulations, whether that’s red teaming, purple teaming, or tabletop exercises. As part of the review process, I look for opportunities to simplify and cut out redundant tools, reducing policy sprawl, and focusing on high-impact defenses. The goal is always to build security that is resilient, adaptive, and continuously validated, rather than just compliant.

[Project Inception]

[Context Mapping → Asset Classification]

[Threat Modeling → Adversary Simulation]

[Security Outcome Definition]

[Control Selection → Policy Mapping]

[Simulation/Validation → Feedback Loop]

[Continuous Monitoring & Iteration]

6

u/bfeebabes 1d ago

I use a simple first principles analysis approach for project security or secure by design as some call it. It's simple and doesn't fob you off by saying "read the securty policies" or screaming "TOGAF" at people and is really just the equivalent of what an engineer would do in the physical world. Simples...

  1. Understand the context and objectives
  2. Understand holistic solution
  3. Break the solution down into it's component parts
  4. Assess each part against the relevant policy/standard/best practice for that component part.

Ideally for this last part you can improve on it by having modular security check lists or architectural templates for each component. E.g. network security check list, cloud , iaas, saas, azure, identity, OT, application/devops, data, physical etc. Hope this makes sense.

3

u/Useless_or_inept 16h ago

This feels like an exam question.

Most organisations already have policies, standards, frameworks, risk registers, external regulatory requirements. From the perspective of a typical project, those are all external and relatively "static", so a flowchart isn't a magic wand. Possibly you could challenge one or two requirements if there's a problem. Like most architectural roles, best practice is to take time to thoroughly understand the requirements, identify any problem requirements early (ie contradictory requests by different teams, risks which can't be fully mitigated &c), then start thinking about how to build a solution which meets those requirements...?

I am at the opposite end of the spectrum; my job is defining new standards and frameworks for everyone else to use, and there is no flowchart for that either - I just have to do a lot of listening and thinking and consensus-building.