¶ A Parameter Scan Against a Checklist
An automated SAP profile parameter scan and a hardening checklist ask the same question and keep different records: the scan reads every parameter on its list on every run and writes down what it could not read, while a checklist records what a person found and not what they looked at. The RedRays Security Platform runs the first kind.
Both approaches have a place. This page is about which questions each one can answer afterwards, when the person who did the work is not in the room.
¶ What does a scan record that a checklist does not?
| Hardening checklist in a spreadsheet | Automated parameter scan | |
|---|---|---|
| The list of parameters | Whatever the reviewer typed this time | The same catalogue every run, readable on screen |
| The value | As transcribed | As returned by the system |
| The expected value | Usually in a separate document, if anywhere | Printed beside the value on the finding |
| Parameters that could not be read | Left blank, or left out | Counted and named as unmeasured |
| What was not looked at | Unknowable | The catalogue is the list; anything outside it is out of scope by definition |
| Repeatability | A different person types a different list | Identical, across systems and dates |
| Evidence a year later | A file with no provenance | A report with its date, its counts and its conditions |
The difference that matters is the fourth row. A checklist that comes back with twelve rows filled and three blank cannot say whether the three were fine, absent, or forgotten. That gap is why manual parameter reviews stop being comparable after the second one. See what RZ11 does not tell you.
¶ What does a checklist still do better?
Two things, and it is fair to name them.
It carries judgement. A person working through a checklist knows that this system is a sandbox, that the gateway sits behind a firewall nobody can reach from outside, and that the auto-logout was set to zero for a documented reason in 2019. A scan has none of that context and will report the setting every time. The scan is better at asking; a person is still better at deciding.
It can look at things nobody wrote a rule for. A reviewer notices a parameter that looks wrong even though it is not on the list. A scan only reports what its catalogue names, which is why the catalogue is visible and extendable. See where the recommended values come from.
¶ Does a scan replace transaction RZ11?
No, and it should not. RZ11 remains the right tool for looking at one parameter, and it is where a finding should be confirmed before a profile is edited. A finding names the parameter so the reader can go and check it, which is the workflow the two tools are meant to have: the scan produces the list, RZ11 settles the individual case.
¶ Which one produces audit evidence?
The scan, with one condition. Evidence has to say what was covered, what was found and what was not measured. A report that shows three counts, one of them for parameters that never came back, is evidence. A percentage on its own is not, whichever method produced it, because a percentage hides its denominator. That principle applies to every capability on this site: what a finding does and does not claim.
A report carries its own date and its own counts, the unmeasured parameters among them, which is what makes it evidence rather than a percentage.
¶ Limits worth stating
- A scan is a point-in-time reading, exactly as a checklist is. Both are wrong the moment somebody changes a profile.
- Neither method distinguishes a value set deliberately from one the kernel supplies as a default. SAP reports the two separately; a review records the value in force.
- Neither method proves a setting is exploitable. That question needs the network picture from a port and service scan and the trust picture from threat modelling.
- Automation removes the transcription error, not the disagreement about what the value should be. The disagreement is the useful part, and it should happen with the condition on the screen.
¶ Frequently asked questions
¶ Can a scan replace our quarterly manual review?
It can replace the typing and the transcription, which is most of the effort and all of the drift. The review meeting is still worth having, and it goes faster when the evidence in front of it names its own gaps.
¶ How long does a parameter scan take against one system?
A single system is read in one connection and a single call, so the reading itself is short. The time in a real programme goes on deciding what to do with the findings, not on the measurement.
¶ Does the scan need a firefighter or administrator account in SAP?
No. It needs RFC logon rights and permission to call the read-only function that returns the profile parameters in force. No write authority is required or used. See what one parameter check says.
¶ Can the results feed our existing GRC or ticket process?
Findings can be downloaded as a report file, exported row by row for a spreadsheet, or raised as an issue in the customer's own issue tracker. The installation and its data stay on the customer's infrastructure; see deployment and where data goes.