¶ Suppressed, Waived and Reported
A suppressed segregation of duties conflict in the RedRays Security Platform is one the analysis found and then held back because of a recorded fact about the SAP system, not because a person decided the risk was acceptable.
Those are different claims and they live in different columns. Suppression is the engine's verdict. Waiving is somebody's decision, taken by name, against a control or an expiry date. A product that merges them into one word on screen makes an audit conversation impossible.
¶ What are the reasons a conflict is suppressed?
Four, each a fact about the landscape rather than an opinion about the risk.
| Reason | What it means | What it depends on |
|---|---|---|
| Assignment outside its validity window | One side arrives only through a role assignment whose valid-from and valid-to dates do not contain the scan date | Assignment dates |
| Account locked | The account is locked and cannot be used as it stands | User attributes |
| No shared organisational value | The two sides are pinned to organisational values that cannot intersect, so the duties cannot meet on the same document | Organisational values in the roles |
| Reference user | The row names an access template that carries authorisations, has no password and cannot sign in. The people who inherit from it are reported separately | User attributes |
Exactly one reason is recorded per finding, in a fixed precedence, so a row never carries two even when two are true of it. Suppressed rows stay in the list with the reason on them rather than being dropped, so the reported figure and the suppressed figure always add up to what is on screen.
¶ Is a suppressed conflict safe to ignore?
No, and the distinction is worth carrying into the audit. Each reason has a different half-life.
- A lapsed assignment returns the day somebody extends the date.
- A locked account is closed until it is unlocked, which is a routine administrative act.
- An organisational separation is a control that is currently working, and it stops working the moment the scoping changes.
- A reference user is not a person, but everyone inheriting from it is, and those rows are reported.
An auditor will ask which reason applied. That is why the breakdown is itemised by reason rather than shown as a single suppressed total, and why the reason is stored on the row instead of being recomputed for a screen.
¶ What is the difference between suppressed and waived?
| Suppressed | Waived or mitigated | |
|---|---|---|
| Who decided | The engine, from recorded facts | A named person |
| Basis | The system state at the time of the scan | A judgement, usually against a mitigating control or an accepted risk with an expiry date |
| Reversible by | The system state changing | Somebody changing the decision |
| Effect | Excluded from the reportable count, and from nothing else | The case is marked, and the reason and owner are recorded with it |
A decision that rests on a control nobody has shown to be working is marked as such rather than shown as a clean mitigation. See mitigating controls for SoD risk.
¶ Why is a count sometimes a dash instead of a zero?
Because "no locked accounts" and "we were not told which accounts are locked" are opposite claims about a landscape, and only one of them can be true of an extract that carried no user attributes.
Each suppression reason is computed from a fact the scan either read or did not. Where the fact was never supplied, the count is drawn as a dash with the reason beside it, never as a zero. The reasons are listed from the ruleset rather than derived from the findings, so a reason that produced no rows still appears with the right answer against it, instead of vanishing from a screen that then reads as though nothing was suppressed.
This is the same rule the rest of the platform applies to any unmeasured number. See what a finding does and does not claim.
¶ Limits
- Suppression is not remediation. A drop in the reportable count with a rise in the suppressed count is account locking or lapsing assignments, which is why the two are trended as separate series rather than added together.
- Organisational suppression is deliberately conservative. Where a role's organisational value is a range or a prefix rather than a single value, the role is treated as unrestricted and the conflict is reported, because a finding that is never printed is never found.
- The four reasons are the whole list. Anything else that removes a finding from the reportable count is a decision, taken by a person, and recorded as one.
What a pack would contain is asked and answered before the file is produced, not after.
¶ Frequently asked questions
¶ Can we turn a suppression reason off?
The verdict is computed from facts and is not a preference. What you can do is include suppressed rows in the list, which is the default, and export them with their reasons.
¶ Do suppressed conflicts appear in the report pack?
Yes. They are excluded from the reportable count and from nothing else, and the pack states, per reason, either that nothing was suppressed for it or that nothing could be, naming the fact that was missing.
¶ A row is suppressed because the account is locked. What should we do with it?
Treat it as work queued rather than work finished. The conflict is in the role design and returns with the account. Locked accounts that stay locked are their own finding.