¶ What RZ11 Does Not Tell You
Checking SAP profile parameters by hand in transaction RZ11 produces a list of what somebody looked at, not a list of what the system is set to, because RZ11 is a lookup: it answers about the parameter name you type and stays silent about every name you did not think of.
The RedRays Security Platform exists for the second half of that sentence. This page is about why the manual method degrades, and what a spreadsheet of parameter values cannot tell its next reader.
¶ Why is a manual parameter check hard to repeat?
Because the hard part happens before the transaction is opened. RZ11 presupposes the question. Somebody has to produce the list of names to type, out of memory, out of a hardening guide of unknown vintage, or out of the last auditor's spreadsheet. Two people doing the same review a quarter apart type different lists, and neither list is written down beside the answers.
The result is a document that records what was found and not what was looked at. The next reader cannot tell whether a parameter is missing from the sheet because it was fine, because the system does not have it, or because the person ran out of afternoon. That answer degrades the moment it is filed, and it degrades invisibly.
¶ Why does a blank cell mean four different things?
Because four different events all end up as an empty cell, and only one of them is good news.
| What actually happened | What it means for remediation |
|---|---|
| This release of SAP does not have the parameter | Nothing to change; the checklist is wider than the system |
| The parameter exists and nobody read it | Nothing is known; the review has a gap in it |
| The system returned the parameter and the answer was empty | A real finding. Something that should name a value names nothing |
The system returned the parameter and the value is 0 |
A real reading, and for several settings zero means the control is switched off |
A blank beside rfc/ext_debugging can be read as "this system does not expose RFC debugging", which is reassuring and might be true, and as "nobody checked", which is not reassuring and might equally be true. Nothing about the blank says which, and the person who wrote it down has usually forgotten by the time anybody asks. Not found, not set and zero is the page that separates them.
¶ Why is the value in the profile file not always the value in force?
Because SAP keeps two answers for every parameter: the value set in an instance or default profile, and the kernel default that applies when no profile sets it. Which of the two is in force decides what remediation is even needed.
A parameter that is compliant because somebody set it that way is a control. A parameter that is compliant because the kernel happens to default that way is a coincidence that the next kernel upgrade is entitled to withdraw, and it survives no profile edit made by anybody who does not know it is load-bearing. Reading a profile file with a text editor answers the first question and misses the second entirely.
¶ Why does a patch cycle not cover this?
Because nothing here is a defect in software SAP wrote. gw/reg_no_conn_inf, login/password_expiration_time and snc/enable are not vulnerable code; they are decisions. SAP Security Notes fix what SAP shipped. Profile parameters are what your team configured, usually once, usually by copying a profile from another system, and no patch day revisits them. Whether the published fixes are applied is a separate question, answered by vulnerability assessment.
¶ What a review has to record to be worth repeating
Three things, and the manual method reliably keeps only the first:
- The value. What the system returned, not what a profile file says.
- The condition. What value was expected, written down beside the reading, so the verdict can be checked later by somebody who was not there.
- The absences. Which parameters were asked for and did not come back, kept apart from the ones that came back and passed.
The third is what makes a review comparable to the next one. Without it, two reports that look identical may be one stable system read twice, or one read that quietly returned less than the other. See what one parameter check says for how a single check records all three, and what a finding does and does not claim for the rule the whole platform is written under.
Each run is kept as its own record with its own counts, so two dates can be read against each other instead of one overwriting the other.
¶ Frequently asked questions
¶ Can we not just export the profile files and diff them?
That answers what is written in the profiles, which is useful, and it misses the kernel defaults that apply where a profile is silent. It also misses dynamic changes made since the last restart, and it gives you no expected value to compare against, which is the part that takes the time.
¶ Is RZ11 the wrong tool then?
No. RZ11 is the right tool for looking at one parameter, including checking a finding after it is reported. It is a poor tool for producing evidence that a list of settings was reviewed, because it keeps no list and no history.
¶ Does an SAP system have a standard list of security-relevant parameters?
There is no single published list that everyone agrees on. Guides, auditors and internal standards each carry their own, which is why a review has to name the list it used and print the expected value beside each reading. See where the recommended values come from.