¶ Duties, Functions and SoD Rules
In segregation of duties analysis a duty is a job somebody is employed to do, a function is that duty expressed in SAP authorisation objects and fields, and a rule pairs two functions; the RedRays Security Platform evaluates rules, not role names.
Getting these three apart matters, because most disappointing SoD reports come from confusing them. A ruleset built from thousands of single-transaction checks paired against each other produces a large number that answers no question anybody asked.
¶ What is the difference between a duty, a function and a rule?
| Term | What it is | Example in words |
|---|---|---|
| Duty | A job. Usually three to fifteen transactions and the authorisations behind them | Maintain vendor master data |
| Function | That duty written as authorisation conditions, so it can be evaluated | The objects, fields and activities that let someone create or change a vendor |
| Rule | Two functions that should not meet in one person, or one function nobody should hold, or a profile that grants everything | Maintain vendor master data together with releasing an outgoing payment |
Inside a function there are three more levels, and only two logical operators in the entire model. A function holds variants, and any one of them satisfies it. A variant holds condition blocks, and all of them must be satisfied. A block names one authorisation object and the fields required on it, and it is satisfied only when one authorisation instance carries every one of those fields.
That last point is the whole idea. Requiring the fields to come from a single instance is the difference between "can create purchase orders in that company code" and "can create something somewhere, and can also do something in that company code". Two blocks on the same object are allowed and deliberately mean something weaker, because then the fields may come from different instances.
A duty is held as authorisation conditions rather than as a role name, which is why nothing on this screen is itself a finding.
¶ Why is a catalogue of checks not a ruleset?
Because a check and a duty are different objects. Content libraries commonly ship tens of thousands of entries of the form "users who can execute this transaction": one entry per transaction code, with the authorisation objects behind it. That is a library of critical access checks, and it is genuinely useful as raw material, because knowing which objects and fields sit behind a transaction is the expensive part of authoring a function.
It is not a set of duties. Segregation of duties needs two opposing duties inside one business process. Pairing two arbitrary checks gives "can do X and can do Y", which is a conflict only when X and Y are opposite sides of the same cycle. Pair every check with every other check and you get a cross product wearing a ruleset's name: thousands of rules, no severity, no process, and no sentence a remediator can act on.
The three honest uses of such a catalogue are as raw material for authoring functions, as single-sided critical access rules where no duty modelling is needed, and as a cross-check run past a curated ruleset at the end to ask whether a pair worth having was missed.
¶ How should rule quality be judged?
By whether the people a rule names can actually do what the finding says. A rule side that names only transactions records no activity, so it is satisfied by a display transaction as readily as by a maintenance one, and the resulting sentence overstates the risk. Writing the side over the authorisation object and its activity field is what makes create mean create.
Two habits follow from that. Rules carry a version, and the version moves when the code, title, severity, active state or either side changes, so a finding can always be traced to the rule text that raised it. And a new or adopted rule arrives switched off, to be measured against a real population before it is allowed to produce findings a customer will act on.
Each rule carries its severity, its version and whether it is switched on, so a finding can be traced back to the rule text behind it.
¶ Limits
- The shipped ruleset is a starting point. Which duties conflict is a property of how a business runs its processes, and the first review after the first scan usually changes it.
- Rule counts are not comparable between products, because vendors count at different levels: risks, functions and generated combinations. Compare at the risk level or not at all.
- A process with no rules produces no findings, which is not the same as a process with no risk. Coverage is reported per process, including the empty ones.
¶ Frequently asked questions
¶ Can we write our own rules and functions?
Yes. Functions and rules are editable, shipped content is read-only and can be copied for editing so that a customer copy survives a content update, and every change creates a version.
¶ What happens to findings when we switch a rule off?
The rule leaves the next scan and anything already open on it stays open. A case is keyed on the system, the user and the rule, so it outlives both the scan and the rule that raised it.
¶ Does the ruleset include organisational scoping?
Yes. Organisational values such as company code, plant and purchasing organisation are compared side against side, so two duties that cannot meet on the same document are held back with the reason recorded rather than reported.