Four Regions, One When Rule, and a Relief Auditor Who Can Edit
Claims adjusters at a national insurer must see only claims from their own region; there are four regions and roughly 400 adjusters. Each region has its own access group. The current implementation puts a When rule on the case-list section that hides the Region column and filters the region dropdown, and the team considers the requirement met. A penetration test found that the case list, the Excel export of the same list, and the search results all return claims from every region. Separately, an auditor who also does relief adjusting was given both the Adjuster access group and an Auditor access group whose role allows write, and can now edit claims during a review that is supposed to be read-only. A nightly batch job and the CRM integration service account run under the same access group as human adjusters and under an operator ID that has no region value.
1. Where must region filtering live, and why does the When rule not satisfy the requirement? Draw up the list of surfaces you would test.
Read the worked answer
Why the When rule fails
It is a rendering rule. It changes what is drawn in a section; it does not change what was retrieved, what is cached on the clipboard, or what a user is permitted to read. Anything that reaches the class by another route is unaffected - and there are several such routes here, which is exactly what the penetration test found.
Where the filter belongs
Constrain the data source. Put the region condition on the data page and the report definition that feed the list, parameterized by the operator's region, so every consumer of that source inherits the constraint rather than reimplementing it. One filter, one place, or it will drift.
Then layer class and property access on top, using the role-to-object matrix (read access on the work class and on sensitive properties) so that even a crafted request for a specific claim ID is denied. If the rule is conditional - supervisors see all regions, adjusters see one - express that condition explicitly in the security model rather than in the UI.
Surfaces to test, one operator per region, including at least one negative test each
- Case list, including paging and sorting
- Excel/CSV export (frequently a different code path from the list)
- Search results and any saved search
- Direct navigation to a claim ID belonging to another region
- Any ad-hoc report the user can build
- Case data visible on a related object (a subcase, an attached document)
- Any REST or service exposure of the class
Hiding a column is not masking and it is not filtering; treat it as cosmetic only.
2. The relief auditor can now edit. Explain the mechanism and fix it without breaking legitimate audit access.
Read the worked answer
Mechanism
Access groups are additive. A user who belongs to two access groups receives the union of the permissions carried by their roles - there is no most-restrictive-wins and no subtraction. The Auditor role's write permission on the work class therefore applies for the whole session, including while the user is acting as an adjuster. There is no "deny" entry in the role-to-object matrix to counteract it; you remove a permission from a role, you do not add a denial.
Fixes, in order of preference
- Make the audit role genuinely read-only: read on the work class and on the properties an auditor must see, no write, no delete, no privilege that mutates a case. The reason auditors could not "open" a case before is usually that read was missing, not that write was missing.
- Do not use a single broad role for oversight work. Give auditors a narrow review screen and the read access to back it.
- If relief adjusting genuinely requires write, model it as a combined role granted for the relief period, and remove the plain audit group from those users - accepting that within one session the union applies and the fix can only be in role design.
- Review the population: who holds both groups, why, and for how long. Log and periodically re-certify.
Verify
Test with an account holding both groups: attempt an edit on a claim in review and confirm it is denied, then confirm the same account can still read everything audit needs. Also re-run the region tests under this combined account, because union can widen data visibility as well as actions.
3. The nightly batch job and the CRM integration use the same access group and an operator with no region value. What are the risks and how would you redesign this?
Read the worked answer
Risks
- Permission inheritance. The service account inherits every human permission available through that access group, including write and delete on case data. A compromised credential is now a human-equivalent administrator of claims data.
- Silent fail-open. Any region filter keyed to the operator will meet a blank region. Written defensively, a common implementation is "if the operator has no region, do not filter" - which turns the integration into a channel that reads every region's claims. The alternative, "blank means no rows," makes the batch silently process nothing and look like a job that ran clean.
- Misleading test evidence. Human testing will pass while the non-human operators behave differently, because they have no operator attributes to key on.
- No attribution. Two systems and possibly many scheduled jobs share one operator ID, so the audit trail cannot tell you which process did what.
Redesign
- Separate access groups for the batch and for the integration, each bound to its own application and a role limited to the classes and operations it actually needs.
- Separate operator IDs, one per process or per system, with credentials rotated and not shared with people.
- Give the system operators an explicit region/system attribute if the filter needs one - or, better, give them a distinct data access path that does not pretend to be a region-bound user, and document why.
- Make blank fail closed. "No region means no rows" is correct for a human; for the batch, provide the correct scope explicitly rather than relying on a fallback.
- Add the non-human operators to the region test matrix. A passing human test proves nothing about a shared service account.