¶ What One Parameter Check Says
One profile parameter check in the RedRays Security Platform is a statement about a single SAP instance profile parameter on a single system at a single moment: the value the system returned, the condition that value was judged against, and which of three states the check finished in.
That is a narrower claim than "this system is configured correctly", and the difference matters when the report reaches an auditor. This page sets out what a check records, what a report made of those checks can and cannot say, and what the read needs on the SAP side.
¶ What does one check record?
Four things about the reading, and no more:
| Recorded | What it is |
|---|---|
| The parameter | The exact SAP parameter name the check asked for, for example login/password_history_size |
| The value | The string the system returned, or nothing at all when the parameter did not come back |
| The verdict | Secure, Vulnerable, or Not Found |
| The moment | When the reading was written down |
Beside those, the report shows the condition the value was judged against and the remediation text for a failing value, so a reader can check the verdict rather than take it. What a check does not carry is a severity, a Common Vulnerability Scoring System (CVSS) score or a category, because a parameter deviation is not a vulnerability with an exploit path; it is a setting that differs from a recommended one, and how much that matters is a question about your landscape rather than about the parameter.
One check is a statement about one parameter: the value that came back, the condition that judged it, and the state it ended in.
¶ How is each of the three states produced?
| State | How it is reached |
|---|---|
| Secure | The parameter was among those the system returned, and its value satisfied the expected condition |
| Vulnerable | The parameter was returned, and its value did not satisfy the condition |
| Not Found | The parameter was not among those the system returned, so no comparison was made at all |
The third state is decided before any comparison happens. A parameter that did not come back cannot be given a verdict, because reaching a verdict requires a value to judge, and there is no path in the product on which an absent parameter acquires one. That is a structural guarantee rather than a convention some screen agreed to honour, and the product states it to the reader in place of a verdict: the parameter was not returned by the system, which is not the same as a safe value, so nothing was measured and nothing was judged.
Two consequences follow that are worth carrying into a report review. An unmeasured parameter is never drawn in the colour of a passing one. And it carries no remediation, deliberately, because an instruction to change a setting nobody could read is advice about a fact not in evidence.
¶ What does a report say, and what does it not?
A report is one scan of one system. It holds one row per catalogue entry, always, and it summarises them as three counts: how many passed, how many failed, and how many were never returned. The third count has a column of its own, at the same weight as the other two.
What a report can say: how much of its own catalogue it filled in, and how each entry came out.
What a report cannot say: how much of the system it looked at. The scan walks the catalogue, not the system, so parameters the system returned that no catalogue entry asks about are discarded. A system that answers with several hundred parameters and one that answers with a few dozen produce a report of the same length. If you need the coverage question answered, the answer is the size and content of the catalogue, which is readable in the product. See where the recommended values come from.
¶ What access does the read need?
A dialogue user or a technical user with RFC logon rights to the system being reviewed, and permission to call the read-only function that returns the instance profile parameters in force. No S_TABU_* access, no ABAP source access, no user or role data, and no write authority of any kind is required or used.
The whole conversation with the SAP system is one connection, one call and a disconnect. Nothing is written on the SAP side, no transaction is executed, and no business data is read. The evaluation happens on the customer's own installation, against the catalogue stored there. See deployment and where data goes.
¶ What comes out of a review?
- A report inside the product, with the three counts, the per-parameter rows, and for each row the value, the condition and the remediation where one applies.
- A downloadable report file for a person who has to read it away from the console.
- A row-per-check export for a spreadsheet, carrying the parameter name so a reader can go and look at it in RZ11.
- Optionally, an issue in the customer's own issue tracker for a finding somebody has to act on.
Each run is kept as its own report, so a system read in March and again in June has two records rather than one that overwrote the other.
¶ Limits of a single check
- A check is about the value in force, not about how it got that way. The profile value and the kernel default are not distinguished in the record, so a compliant reading does not prove a deliberate decision.
- A check is a point-in-time reading. A parameter that can be changed dynamically can be different an hour later, and the report does not watch it.
- A passing condition is not proof the control is on. Some settings are governed by more than one parameter: a library path can be present while the feature that loads it is switched off elsewhere. Read the neighbouring parameters, not one row.
- A long value can be reported as its leading part. The SAP field that carries a parameter value has a fixed width, and a long value can arrive cut. Where the value on the row looks truncated, confirm it in RZ11 before acting.
- Nothing here is a claim about exploitability. A finding says a setting deviates from a recommended value. Whether that deviation is reachable by anybody is a question for threat modelling and the port and service scan.
¶ Frequently asked questions
¶ Why is there no severity on a parameter finding?
Because a severity would be invented rather than measured. The same deviation matters differently on a sandbox and on a production system reachable from a partner network. The finding states the setting and the expected value; the ranking is yours to make with landscape context the check does not have.
¶ Can a check tell me the parameter does not exist in our release?
No, and it says so. Not Found means the parameter was not among those the system returned. That is consistent with a release that does not have it and with a read that did not deliver it, and the product does not pretend to know which. See not found, not set and zero.
¶ Does the report show the condition that produced the verdict?
Yes, next to the value. That is the point: a verdict whose condition is hidden is one the reader has to take on trust, and a reader who spends ten seconds on the two fields has verified a finding rather than believed it.
¶ Can two reports of the same system be compared?
They can be read side by side, count by count and row by row. Note that if the catalogue changed between them, the two reports cover different lists, and that is the first thing to check before treating a difference as a change on the SAP system.