¶ Where the Recommended Values Come From
Every verdict in an SAP profile parameter review comes from a catalogue entry that names one parameter and the value expected of it, and in the RedRays Security Platform that catalogue ships with the product, is readable on screen, and can be extended by the customer.
There is no second route to a finding. If a parameter has no entry, it produces no row. If an entry expects the wrong value for your landscape, it produces the wrong verdict. So the catalogue is worth reading before the report is.
¶ What is in a catalogue entry?
| Part | What it is for |
|---|---|
| Parameter name | The exact SAP parameter to ask about. It is a key, not a description, so it has to match what SAP returns |
| Condition | The value or range expected of that parameter |
| Title | The name a reader sees on the finding |
| Description | What the parameter governs, so a reader who has never met it can decide whether the finding matters |
| Recommended solution | What to change, in the words the person doing the change needs |
An entry carries no severity and no score. A parameter deviation is a difference from a recommended setting, and how much it matters depends on the system it was found on.
An entry is editable in the product, so a house standard or a compensating control replaces the shipped expectation instead of living in a footnote.
¶ Why is the condition shown on the finding?
Because a verdict whose condition is hidden is one the reader has to take on trust. The finding shows the value the system returned next to the condition it was judged against, which lets three different people do three useful things:
- The administrator can confirm the reading is what they expect before touching a profile.
- The auditor can see the standard being applied rather than a coloured chip.
- The security owner can disagree with an expected value on the evidence, in the meeting, rather than a quarter later.
An SAP security review that will not show its own conditions is asking to be believed. This one is asking to be checked.
¶ Can we change the expected values?
Yes. Entries can be edited and new ones added, which is how a house standard, a regulator's baseline or a compensating control gets into the review instead of living in a footnote. Two consequences are worth knowing before you do it:
- A change applies to future reports. A new or edited entry does not backfill reports already taken. Two reports of the same system taken either side of a change cover different lists, so when comparing dates, check the catalogue first and the SAP system second.
- The catalogue is the denominator. A report says how much of its own list it filled in. Adding entries makes the report wider, not the system worse.
¶ What a catalogue cannot do for you
- It cannot know your landscape. An expected value that is right for a production ERP system may be wrong for a sandbox, a training system or a system behind a documented compensating control.
- It cannot cover parameters nobody wrote down. Parameters outside the catalogue are not examined and are not counted as missing. Coverage is a question about the list, and the list is on screen for that reason.
- It cannot rank findings for you. With no severity on an entry, the order of work is a decision made with landscape context, from threat modelling or from what the port and service scan says is reachable.
- It cannot make a stale entry current. A parameter introduced by a recent SAP release or Security Note is only reviewed once an entry exists for it, which is an argument for reviewing the catalogue when you upgrade.
¶ Frequently asked questions
¶ Who decides the recommended value that ships with the product?
The shipped catalogue is assembled from SAP's own documentation and published hardening guidance for each parameter. It is a starting position, not a standard body's ruling, which is why it is visible and editable rather than compiled in.
¶ If we edit an entry, does the old report change?
The verdicts already recorded stay as they were recorded. Treat a catalogue change the way you would treat a change to any control standard: note the date, and read reports either side of it as covering different lists.
¶ Can we run different expectations for production and non-production?
That is a question about how you organise reviews rather than about a single entry, and it is worth raising during a proof of value. The point to hold on to is that a report should name the standard it applied, and this one shows the condition on the finding itself.
¶ What happens to a parameter with no entry?
Nothing. It is not reported, and it is not counted as unmeasured either, because the review never asked about it. Only parameters in the catalogue that the system did not return are reported as unmeasured. See not found, not set and zero.