Cybersecurity
Security architecture review
The cheapest time to fix a design flaw is before it ships. We examine how the system is put together: where data moves, who and what is trusted, and what happens when one component fails or is compromised.
The problem this service solves
Penetration tests find implementation bugs. They are poor at finding structural problems: a shared service account across tenants, a trust relationship that spans environments, a message queue anyone on the network can write to. Those come from design choices, and fixing them late is costly.
A review looks at diagrams, documentation, configuration and the people who built it. It asks where an attacker would start, what they could reach and which of your controls would notice.
What is in scope
-
Context and assets
What the system does, the data it handles and the business impact of compromise.
-
Trust boundaries and data flows
Diagram components, flows and the points where trust changes.
-
Threat modeling
Use STRIDE or a similar method to identify credible threats per component and flow.
-
Identity and access
Authentication, authorization, service identities and administrative access.
-
Data protection
Classification, encryption, key management, retention and backups.
-
Resilience and recovery
Failure modes, isolation, recovery objectives and dependency risks.
-
Detection and logging
Which events are recorded, where they go and who looks.
-
Third-party dependencies
SaaS, APIs and libraries that the design relies on.
How the work runs
Understand
Learn the design.
-
1
Document review and workshops
Walk through the design with architects and engineers.
Analyze
Find the risks.
-
2
Threat modeling session
Work through threats component by component.
-
3
Control review
Compare design with standards and patterns.
Recommend
Make decisions easier.
-
4
Report
Risks ranked by impact, with design alternatives and trade-offs.
-
5
Follow-up
Review revised design if needed.
What you receive
- Annotated architecture diagrams
- Threat model
- Findings and design recommendations
- Decision log of accepted risks
- Follow-up review
Tooling and technique
Tool categories describe how we work. They are not a claim of vendor partnership or certification.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- Architecture documents and diagrams
- Time with architects and developers
- Data classification information
What this service is not
- Implementation testing
- Architecture design from scratch without your team
What changes afterwards
- Structural risks are found before launch
- Teams have documented trade-offs
- Review output feeds testing scope
Questions people ask
Can you review a design that is already in production?
Yes. We often find that the diagram differs from reality, which is itself a useful finding.
How is this different from a penetration test?
A penetration test tries to break an implementation. An architecture review judges the design and its trust assumptions. The two inform each other.
Related
-
Security engineering and implementation
Hands-on delivery of security controls and platforms: design, deploy, integrate, migrate, test and hand over.
-
Zero trust architecture
Plan and implement zero trust principles: strong identity, device health, segmentation, least privilege and continuous verification.
-
Enterprise architecture
Target-state architecture, application and integration landscapes, data architecture and the principles that keep many teams building compatible things.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response