¶ What One SoD Finding Says
A segregation of duties finding in the RedRays Security Platform is one person holding both sides of one rule on one SAP system as of one sealed scan, with every access path and every matched authorisation value recorded behind it.
That sentence fixes the unit. A finding is never one role and never one access path. If the same person reaches both duties through four different roles, that is one finding with four paths, not four findings. Products that show a single role name on each row are wrong on a large share of them, because access commonly arrives by more than one route.
¶ What is the unit of an SoD finding?
One person, one rule, one system, one scan. The count on the front page is therefore a count of conflicts and not a count of role assignments, and the two are far apart on any real landscape. The evidence behind the row is what makes the claim checkable: for each side of the rule, the role or profile that granted it, whether the access is direct or inherited, the authorisation instance, and the field values that matched.
An account can also hold both sides through a single role. That case looks identical in a list and is completely different to remediate, so it is drawn separately when the finding is opened.
Opening a conflict shows both duties, each path the access travelled and the values that matched, so the claim can be checked rather than believed.
¶ What are the three kinds of claim on one report?
The headline total is not all one thing, and the product does not present it as though it were.
| Kind of row | What it asserts | Sides |
|---|---|---|
| Segregation | Two duties that should be held apart are held by one person | Two |
| Critical access | Nobody should hold this function at all | One |
| Superuser | The account carries an unrestricted profile assigned straight to it, with no role in between | None; it matches a profile |
Only the first is what "segregation of duties" describes. The other two are worth reporting and are labelled as what they are, so a total is never presented as though every row in it were a two-sided conflict.
¶ How is a duty defined, if not by a role name?
By authorisations, in five levels with only two logical operators in the whole model.
| Level | What it is | Satisfied when |
|---|---|---|
| Condition value | One term: authorisation object, field, value | The granted value and the required value overlap |
| Condition block | One authorisation object and every field required on it | A single authorisation instance satisfies every field, by any one of the values listed on that field. Fields are ANDed, values on a field are ORed |
| Variant | A set of blocks | All of them |
| Function, or duty | A set of variants | Any one of them |
| Rule | Two functions, one function, or a profile | One account satisfies every side |
The requirement that a block is satisfied by one authorisation instance is the whole idea. It is the difference between "this role can create purchase orders in that company code" and "this role can create something somewhere, and can also do something in that company code". Because a duty is defined this way, a rule survives a role being renamed or rebuilt.
¶ What decides whether a finding is reported or suppressed?
A recorded fact about the system, evaluated the same way for every row, never a code branch and never a person's opinion. Four facts can hold a finding back: the account is a reference user and cannot log on, the account is locked, one side arrives only through an assignment whose validity window does not contain the scan date, or the two sides are pinned to organisational values that cannot intersect.
Suppressed rows stay in the list with the reason on them. They are excluded from the reportable count and from nothing else, and exactly one reason is recorded per finding, in a fixed precedence, so a row never carries two. Suppressed, waived and reported covers what that means for an auditor.
¶ What is the difference between a verdict and a decision?
The verdict belongs to the engine: reported, or suppressed with a named reason. The decision belongs to a person: open, in remediation, mitigated, accepted, false positive, closed. They are two columns and are never merged into one status.
The decision is held in a case keyed on the system, the user and the rule, so it outlives the scan that raised it. The next scheduled run does not erase it, a rule can hold open cases after it stops firing, and a case raised by a rule that has since left the ruleset stays visible rather than disappearing quietly.
¶ What does it mean for a scan to be sealed?
Sealing is a set of assertions, not a status word somebody sets. A scan publishes only if it examined at least one account, if every finding's recorded path count equals the paths actually stored, if every conflict has exactly the number of sides its rule declares, if every superuser row names a profile, if every recorded organisational verdict re-derives from the paths, and if no conflict came from an inactive rule version. A scan that fails an assertion is not published, and the previous scan of that system is left untouched.
The scan also records, fact by fact, what it was told and what it was not: user attributes, names and departments, assignment validity dates, organisational values, directly assigned profiles, reference users, composite membership, withdrawn authorisations and last logon. Each is marked measured, partial or not supplied, with the row count it came from. A count that rests on a fact nobody supplied is drawn as a dash and not as a zero.
¶ Limits worth knowing before you quote a number
- A condition is not a capability. The engine matches a condition; the reader takes away a sentence. A rule side that accepts any one of several transactions can be satisfied by a display transaction in that list, and the resulting sentence then overstates what the person can do. This is a property of rule content, not of the engine, which is why rules carry versions, why every rule's full condition set is visible, and why a new rule is measured against a real population before it is switched on.
- A ruleset looks at what it was pointed at. Coverage is published as a proportion of the transactions and authorisation objects that people on the landscape actually hold, rather than claimed as complete. A business process with no rules is drawn as an empty row rather than dropped, because a process with no rules is not a process with no risk.
- Row-level evidence expires. Sealed counters are permanent; the row-level evidence behind them is kept for a bounded retention window. Reports built from the counters survive that, reports built from the evidence do not, and the export states which is which before the file is produced rather than after.
- No usage evidence. Dormancy here means no logon recorded as of the scan date. It does not mean the access was unused.
¶ Frequently asked questions
¶ If one person holds both duties through four roles, is that four findings?
No, it is one finding with four paths recorded. The role count on the row tells you how many ways the access arrives, which is what decides how much work remediation is.
¶ Can a finding disappear because somebody edited a rule mid-scan?
No. The active ruleset is frozen and copied before the analysis runs, and the scan records a hash of exactly the rule content it used. Two scans run under different rulesets are marked as answering different questions, and the trend chart refuses to join them with a line.
¶ Why does the total sometimes fall without anything being fixed?
Because accounts were locked or assignments lapsed, which moves rows from reported to suppressed. Suppressed is carried as its own series for that reason: a fall in reportable with a rise in suppressed is not remediation.