Add Identity and Access Management dimension - #82
Conversation
|
This one's been a bit of a tough one, since you have to frame the dev team's responsibilities from an IT ops standpoint. Feedback would be appreciated. I could see this growing bigger in the future, but I think it's a good starting point, given broken access control is still #1 in the OWASP Top 10. |
|
Do we need to cleanup, e.g. moving https://dsomm.owasp.org/activity-description?uuid=598e9f13-1ac8-4a01-b85e-8fab93ee81de to this subdimension? Can we delete or move https://dsomm.owasp.org/activity-description?uuid=070bb14b-e04a-4f3d-896a-a08eba7a35f9 ? |
|
i would move RBAC and MFA https://dsomm.owasp.org/#598e9f13-1ac8-4a01-b85e-8fab93ee81de, but leave MFA for admins where it is thoughts? |
|
Why would that not be in the new dimension? They are both very much connected I will one day change RBAC to Attribute Based Access Control. |
|
Yes, you're absolutely correct. I got confused, as I was thinking it was specifically related to infrastructure. There is also a simple access controls category for systems: https://dsomm.owasp.org/#82e499d1-f463-4a4b-be90-68812a874af6. I'll move that as well. I think RBAC might be better positioned as "Fine-Grained Access Controls", encompassing approaches such as ABAC, RBAC, and PBAC. That would align better with the Simple Access Controls category as well. |
|
Drafted the change for RBAC |
|
It feels to me that there are too many activities at level 2 |
Simple access control for systems — all internal systems use basic authentication; a documented baseline gate MFA for admins — two+ factor authentication on all privileged accounts Account inventory — a current, owned list of every account, human and non-human Enforce server-side authorization on every request — deny-by-default authz checked on the server, stopping IDOR / broken access control Level 2 — consolidate and structure Central identity provider for human access — all human access federated through one IdP/SSO instead of per-system logins MFA — extend two+ factor to all accounts on important systems Use correct OAuth2/OIDC authorization flows — Auth Code + PKCE for apps, Client Credentials for services; no Implicit/ROPC Least-privilege access baseline — default-deny roles, no shared accounts, capped admins, scoped service accounts Role-based access control (RBAC) baseline — access driven by defined, documented roles rather than per-user grants Level 3 — automate and assure Segregation of duties for critical actions — conflicting duties (author vs approver, deploy vs approve) split and technically enforced Automated authorization test coverage — CI tests asserting each role/permission boundary, including negative "should be denied" cases Automated joiner-mover-leaver provisioning — access granted/changed/revoked automatically from an authoritative source, with a leaver SLA Workload and machine identity — short-lived, verifiable identities (OIDC federation/SPIFFE) for non-human access, retiring static keys Level 4 — eliminate standing privilege / policy-driven access Just-in-time privileged access — time-boxed, approved, auto-revoked elevation; zero standing admin Attribute/policy-based access control (ABAC/PBAC) — attributes or centrally evaluated policies (e.g. OPA) where roles are too coarse Periodic access recertification — scheduled re-attestation of access with enforced revocation, covering service accounts too Level 5 — continuous verification Continuous and risk-adaptive access — decisions re-evaluated on device/context/risk, with automatic segregation-of-duties conflict detection
|
Level 1 — foundations Simple access control for systems — all internal systems use basic authentication; a documented baseline gate Level 2 — consolidate and structure Central identity provider for human access — all human access federated through one IdP/SSO instead of per-system logins Level 3 — automate and assure Segregation of duties for critical actions — conflicting duties (author vs approver, deploy vs approve) split and technically enforced Level 4 — eliminate standing privilege / policy-driven access Just-in-time privileged access — time-boxed, approved, auto-revoked elevation; zero standing admin Level 5 — continuous verification Continuous and risk-adaptive access — decisions re-evaluated on device/context/risk, with automatic segregation-of-duties conflict detection |
|
Hi, Level 1 should be a no brainer, so at least "Account inventory — a current, owned list of every account, human and non-human" needs to move to 2. |
2 participants
Adds a new "Identity and Access Management" dimension to the Implementation stage, covering both governance controls (central SSO/IdP for human access, account inventory, segregation of duties, automated joiner-mover-leaver provisioning, periodic access recertification, just-in-time privileged access) and controls owned directly by developers (server-side authorization enforcement, automated authorization test coverage, correct OAuth2/OIDC flows, least-privilege scoping for service accounts and CI permissions).
Non-human identities (service accounts, workload identities, CI/CD pipelines) are called out explicitly since they're an increasingly common source of access-related incidents.