Skip to content

3.5 Security View

Minimum AWS Security Azure Security

The Security View describes how the solution protects against threats, manages identity and access, and safeguards data. It addresses the concerns of security architects, the CISO office, compliance teams, and auditors.

Minimum

| Question | Response | |----------|----------| | Does the solution support regulated activities? | Yes / No - [details] | | Is the solution SaaS or third-party hosted? | Yes / No - [details] | | Has a third-party risk assessment been completed? | Yes / No - [reference] |

| Impact Category | Business Impact if Compromised | |----------------|-------------------------------| | Confidentiality | [impact of unauthorised data access] | | Integrity | [impact of unauthorised data modification] | | Availability | [impact of service unavailability] | | Non-Repudiation | [impact if actions can be denied] |

Guidance

Rate each category as Critical / High / Medium / Low / Negligible. The highest rating drives the security requirements for the solution — a system with Critical confidentiality needs stronger encryption and access controls than one rated Low. Use your organisation’s data classification policy to inform these ratings.

Comprehensive

Document the key threats and how the design addresses them:

| Threat | Attack Vector | Likelihood | Impact | Mitigation | |--------|-------------|-----------|--------|------------| | [threat] | [how] | H / M / L | H / M / L | [design controls] |

Minimum Minimum

| Access Type | Role(s) | Destination(s) | Authentication Method | Credential Protection | |------------|---------|----------------|----------------------|----------------------| | End Users | [roles] | [servers/apps] | [SSO/SAML/OIDC/etc.] | [method] | | IT Operations | [roles] | [servers/apps] | [method] | [method] | | Service Accounts | [scope] | [servers/apps] | [method] | [method] |

| Access Type | Role(s) | Destination(s) | Authentication Method | Credential Protection | |------------|---------|----------------|----------------------|----------------------| | External Users | [roles] | [servers/apps] | [method] | [method] | | External Applications | [scope] | [servers/apps] | [method] | [method] |

Guidance

Document every authentication path into the solution. Prefer federated identity (SSO, OIDC, SAML — see glossary for definitions) over local credentials. Consider:

  • Internal users — should use the organisation’s identity provider (e.g., Entra ID, Okta)
  • External users — may need a separate identity provider or customer-facing auth (e.g., OAuth 2.0)
  • Service accounts — prefer managed identity or workload identity over shared secrets
  • API consumers — document whether mutual TLS (mTLS), API keys, or OAuth client credentials are used

For each authentication method identified above, document the detailed configuration:

Recommended

| Control | Response | |---------|----------| | Does the application use SSO or group-wide authentication? | […] | | What is the unique identifier for user accounts? | […] | | What is the authentication flow? | [describe or diagram] | | How are credentials issued to users? | […] | | What are the credential complexity rules? | […] | | What are the credential rotation rules? | […] | | What are the account lockout rules? | […] | | How can users reset forgotten credentials? | […] |

Session management controls prevent session hijacking and ensure users are re-authenticated appropriately.

Document how authenticated sessions are maintained and protected:

Recommended

| Control | Response | |---------|----------| | How are sessions established after authentication? | [tokens, cookies, etc.] | | How are session tokens protected against misuse? | [signing, encryption, etc.] | | What are the session timeout and concurrency limits? | […] |

Document how access rights are assigned and controlled after authentication:

Minimum

| Access Type | Role / Scope | Entitlement Store | Provisioning Process | |------------|-------------|-------------------|---------------------| | Business Users | [roles and scope] | [where entitlements stored] | [how provisioned] | | Technology Users | [roles and scope] | [where entitlements stored] | [how provisioned] | | Service Accounts | [roles and scope] | [where entitlements stored] | [how provisioned] |

Recommended

| Control | Response | |---------|----------| | Account re-certification process | […] | | Segregation of duties controls | […] | | Delegated authorisation capabilities | […] |

Recommended

| Account Type | Management Approach | |-------------|-------------------| | OS privileged accounts (root/admin) | [how managed, rotated, audited] | | Infrastructure / platform admin | [how managed] | | Application admin | [how managed] |

Guidance

Privileged access is a primary attack vector. Document how privileged accounts are:

  • Controlled — who can request access, what approval is needed
  • Time-limited — prefer just-in-time (JIT) access over standing privileges
  • Audited — session recording, command logging, periodic review
  • Break-glass — emergency access process with post-incident review

3.5.3 Network Security & Perimeter Protection

Section titled “3.5.3 Network Security & Perimeter Protection”
Recommended

Describe network segmentation, firewalls, and perimeter controls. Cross-reference Section 3.3.3 (Network Topology) for the underlying infrastructure.

| Control | Implementation | |---------|---------------| | Network segmentation | [firewalls, security groups, NSGs] | | Ingress filtering | [WAF, DDoS, rate limiting] | | Egress filtering | [proxy, gateway, allowlists] | | Encryption in transit | [TLS versions, certificate management] |

Recommended

Cross-reference Section 3.4 (Data View) for the full data architecture. Document the security controls applied to the solution.

Encryption at rest and secret management protect sensitive data from exposure if storage or infrastructure is compromised.

Encryption protects data from unauthorised access even if storage media is compromised.

| Attribute | Detail | |-----------|--------| | Encryption deployment level | Storage / Logical Container / Application | | Key type | Symmetric / Asymmetric | | Algorithm / cipher / key length | […] | | Key generation method | [HSM / software / other] | | Key storage | [HSM / KMS / other] | | Key rotation schedule | […] |

| Attribute | Detail | |-----------|--------| | Secret store | [e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault] | | Secret distribution | Distributed at deployment / Retrieved on-demand | | Secret protection on host | Local vault / File system / Memory only / Not stored | | Secret rotation | Automatic / Manual / Not rotated |

3.5.5 Security Monitoring & Threat Detection

Section titled “3.5.5 Security Monitoring & Threat Detection”
Recommended

| Capability | Implementation | |-----------|---------------| | Security event logging | [what events, where stored] | | SIEM integration | [tool and integration method] | | Infrastructure event detection | [how monitored] | | Security alerting | [how alerts are generated and routed] |

[Insert security monitoring architecture diagram if applicable]

Scoring Guidance

| Score | What This Looks Like | |:-----:|---------------------| | 1 | Authentication method identified but controls not detailed | | 3 | Business impact assessed, authentication and authorisation documented, encryption at rest and in transit specified | | 5 | All of the above plus threat model complete, secrets management documented, security monitoring integrated with SIEM, privileged access controlled with JIT |

Quality Attribute Cross-References:

  • 4.1 Operational Excellence - Security monitoring is part of operational observability
  • 4.2 Reliability - Security incidents affect availability