PSS-09 Authorisation Mechanisms
Restrict service functions behind authorisation checks confirming that a user, IT component or application may perform the action, validate those checks before releasing new functions or changing existing ones, rate defe
4
artefacts
0
held by a system
1
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Regression evidence covering authorisation after a change to an existing function · Document repository
governing documentDocuments that govern the control
- Test cases and results validating authorisation checks before a feature release · Policy repository / GRC workspace
- Severity ratings applied to authorisation defects using a standard scoring metric · Policy repository / GRC workspace
- Entries in the public vulnerability listing for unresolved authorisation flaws · Policy repository / GRC workspace
First move
This control is evidenced by people and documents, not systems. Put the document under version control with an owner and review date, and log each review as a record with reviewer and date. Do not try to automate it.
Common gaps auditors find
- Authorisation enforced in the user interface but not at the service endpoint
- New features shipped without an authorisation specific test case
- Defects fixed quietly and never disclosed in the published listing
- Object level checks missing, so substituting an identifier reaches another tenant's data
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetPSS-08 Roles and Rights Concept · PSS-10 Software Defined Networking