Security-relevant SAP profile parameters are the instance profile settings that decide how a system authenticates users, whether its gateway will act for a stranger, whether connections are encrypted and whether certain authorisation checks run at all, and they are the settings the RedRays Security Platform reads and compares against recommended values.
The tables below name parameters the review covers and say what each one decides. They are grouped the way an SAP Basis team thinks about them rather than alphabetically, and they are representative rather than exhaustive: the full catalogue is readable inside the product.
The list a report is measured against is on screen, parameter by parameter, with the expected condition beside each name.
Password rules in SAP live in profile parameters, not in a policy document, and the parameters can contradict the policy without anybody noticing.
| Parameter | What it decides |
|---|---|
login/min_password_lng |
The minimum number of characters a password must have |
login/password_expiration_time |
How many days a password stays valid. A value of 0 means no user is ever forced to change one |
login/password_history_size |
How many previous passwords are remembered, and therefore cannot be reused |
login/password_change_waittime |
How long a user must wait before changing a password again, which is what stops a history being cycled through in a minute |
login/password_max_idle_initial |
How long an initial password stays usable before it must be changed. A value of 0 means it never expires |
A password parameter is a statement of intent. Whether the passwords on the system actually resist attack is a different measurement, made against the hashes themselves in SAP password strength testing. This maps to CWE-521, weak password requirements.
The SAP gateway is the component that lets external programs be started and registered server programs connect. Its parameters decide whether that happens under control or on request.
| Parameter | What it decides |
|---|---|
gw/rem_start |
The method by which remote commands may start programs, including whether that is disabled |
gw/reg_no_conn_inf |
Whether a registered server program may connect without the connection information check |
gw/tcp_security |
Whether protection is applied to the starting of external programs |
gw/logging |
What gateway activity is written to the gateway log, and therefore what can be reconstructed afterwards |
gw/logging_secure |
Whether security-relevant gateway events are logged |
A misconfigured gateway is the classic route by which a stranger on the network reaches an SAP system without a user account. Which of these components are reachable at all is answered by the SAP port and service scan, and the trust relationships that make one system a route to another by threat modelling.
| Parameter | What it decides |
|---|---|
rfc/ext_debugging |
Whether debugging is reachable over Remote Function Call (RFC) |
sapgui/user_scripting |
Whether the SAP GUI scripting interface may drive the front end, which automates anything a logged-in user can do |
bdc/shdb/auth_check |
Whether authorisation checks apply during batch input recording |
is/HTTP/show_detailed_errors |
Whether detailed internal errors are returned to an HTTP caller, which is information disclosure to anybody who can reach the port |
igs/listener/http |
How the Internet Graphics Service listener is configured |
| Parameter | What it decides |
|---|---|
snc/enable |
Whether Secure Network Communications is switched on for the instance |
snc/gssapi_lib |
Which security library the instance loads. When this names nothing, no library is configured |
These two are the reason a parameter check has to be read as a set rather than a row at a time. A library path can be present while the feature that loads it is off, and a library can be enabled while individual connection types still accept insecure connections. One passing row is not an encrypted landscape.
These are the parameters that can switch off a check globally, which is why they are worth reviewing even though the answer is normally boring.
| Parameter | What it decides |
|---|---|
auth/no_check_on_tcode |
Whether the transaction start authorisation check is skipped |
auth/system_access_check_off |
Whether system-level access checks are switched off |
rdisp/auth_check_user_list |
Which users an authorisation check applies to |
rdisp/gui_auto_logout |
After how long an idle SAP GUI session is closed. A value of 0 means never |
A parameter here says whether the check runs. It says nothing about who would pass it, which is the subject of segregation of duties analysis. Where a check is switched off globally, that maps to CWE-862, missing authorisation.
No single one. SAP documents each parameter and publishes hardening guidance across several notes and guides, but the working list every organisation reviews is assembled from those sources plus its own standard. That is why the list a report was produced from matters as much as the report.
The ones that decide whether a check runs at all, then the gateway, then the password rules. A switched-off authorisation check and an unprotected gateway are reachable without an account; a weak password rule still requires somebody to arrive at the logon screen.
Yes. The parameters above belong to the ABAP application server. A Java stack has its own settings, and the same is true of SAP Business Technology Platform accounts, which are assessed separately in SAP BTP security assessment.
Yes. The catalogue can be extended with additional parameters and expected values. See where the recommended values come from.