99 lines
5.5 KiB
Markdown
99 lines
5.5 KiB
Markdown
Title: Identity and Authentication Standard
|
|
Document ID: [STD-IAM-001]
|
|
Version: 0.2 Draft
|
|
Status: Draft
|
|
Owner: CISO (Paul Jenkins)
|
|
Approver: CISO (Paul Jenkins)
|
|
Classification: Internal
|
|
Effective date: [DD Month YYYY]
|
|
Review date: [DD Month YYYY]
|
|
|
|
# Identity and Authentication Standard
|
|
|
|
## Purpose
|
|
|
|
This standard defines the minimum requirements for identity lifecycle control, authentication strength, and account management within the ISMS scope.
|
|
|
|
## Scope
|
|
|
|
This standard applies to user accounts, administrative accounts, service accounts, machine identities, authentication systems, and identity integrations used by BlackDice.
|
|
|
|
## Mandatory Requirements
|
|
|
|
All accounts must be uniquely identifiable to an individual user or controlled system identity unless an approved exception exists.
|
|
|
|
Access must be provisioned through an approved process based on authorised business need.
|
|
|
|
Authentication mechanisms must be appropriate to the sensitivity and exposure of the system or service.
|
|
|
|
Wherever technically available, multi-factor authentication must be enabled for workforce, privileged, administrative, remote, cloud, and other in-scope access paths unless a formally approved exception exists.
|
|
|
|
Multi-factor authentication must be used for privileged access, remote access, cloud management access, internet-facing systems, and other high-risk access paths unless formally exempted.
|
|
|
|
Where practical, BlackDice should reduce reliance on standalone passwords by using single sign-on, federated identity, hardware-backed methods, or other stronger authentication mechanisms.
|
|
|
|
Password-based authentication must not rely primarily on password complexity rules or frequent mandatory password changes as the main security control.
|
|
|
|
Where user-chosen passwords are used, systems should support strong password selection through minimum length expectations, deny-listing of common or compromised passwords, and controls against brute-force or password-spraying attacks.
|
|
|
|
Passwords must be changed when compromise is known or suspected, when required by a role change or credential exposure event, or when a system-specific risk assessment requires it.
|
|
|
|
BlackDice should provide or approve secure password management mechanisms where passwords remain necessary at scale. Use of approved password managers should be encouraged where appropriate.
|
|
|
|
Default credentials must be changed or disabled before systems are placed into operational use.
|
|
|
|
Any default vendor-supplied password identified on a production or operationally relevant system, service, device, or administrative component must be changed before use and notified to the CISO.
|
|
|
|
Privileged accounts must be restricted, monitored, and reviewed more closely than standard user accounts.
|
|
|
|
Service accounts and machine identities must be limited to the permissions required for their defined purpose and must not be used for interactive activity unless explicitly justified.
|
|
|
|
Authentication secrets must be protected in line with the approved secrets management approach.
|
|
|
|
Account access must be reviewed at defined intervals and promptly updated for role changes, departures, or identified misuse.
|
|
|
|
Dormant, temporary, emergency, and shared accounts must be controlled, documented, and removed or disabled when no longer required.
|
|
|
|
## Implementation Guidance
|
|
|
|
BlackDice should centralise identity control where practical to improve consistency, traceability, and joiner-mover-leaver handling.
|
|
|
|
Authentication decisions should consider user population, deployment model, administrative exposure, and customer or supplier integration patterns.
|
|
|
|
Single sign-on should be preferred for workforce access where it improves consistency and reduces password burden. Where SSO is used, it should itself be protected by multi-factor authentication.
|
|
|
|
Where password-based login remains necessary, BlackDice should favour approaches aligned with recognised good practice, including reducing password overload, supporting password managers, and using technical controls such as throttling, lockout, or monitoring rather than depending on user memory of complex passwords.
|
|
|
|
For cloud-native and Kubernetes-based operations, identity design should cover workforce access, platform administration, automation identities, pipeline identities, and workload-to-service authentication as distinct control areas.
|
|
|
|
Systems that cannot meet the standard directly should be isolated, monitored, and subject to compensating controls pending remediation or replacement.
|
|
|
|
## Roles and Responsibilities
|
|
|
|
- [Role] must define identity and authentication control requirements.
|
|
- Managers and access approvers must validate business need before access is granted.
|
|
- System owners must ensure their systems implement the required controls.
|
|
- Users must protect authentication credentials and report suspected compromise promptly.
|
|
|
|
## Exceptions
|
|
|
|
Exceptions must be documented, justified, risk-assessed, approved, and reviewed through the exception management process.
|
|
|
|
## Related Documents
|
|
|
|
- Access Control Policy
|
|
- Cloud Security Policy
|
|
- Access Review Procedure
|
|
- Joiner Mover Leaver Procedure
|
|
|
|
## External Reference
|
|
|
|
- UK National Cyber Security Centre, "Password policy: updating your approach": https://www.ncsc.gov.uk/collection/passwords/updating-your-approach
|
|
|
|
## Version Control
|
|
|
|
| Version | Date | Description of Change | Author |
|
|
| --- | --- | --- | --- |
|
|
| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
|
|
| 0.2 Draft | [DD Month YYYY] | Expanded to include explicit password management, MFA, SSO, and default credential requirements aligned with NCSC guidance. | ChatGPT |
|