¶ SAP Vulnerability Assessment
The RedRays Security Platform runs an SAP vulnerability assessment by putting a catalogued security check to each SAP service a landscape exposes, and recording, for each host and each port, which of those checks the service answers the way an affected system answers.
- Sends requests, reads answers
- Never exploits what it reports
- Checks chosen by service type
This is the question that follows a network sweep. A port scan produces an inventory: hosts, instance numbers, service types, ports, each row there because something answered. That inventory carries no severity and no recommendation. A vulnerability assessment takes the inventory as its input and asks the next question, which is usually asked by somebody outside the team that produced it: of the SAP services this landscape exposes, which are affected today, where exactly, and which of them has somebody already decided about.
The module opens with nothing chosen, and reaches no system until a landscape is selected and a scan is started.
¶ What is an SAP vulnerability assessment?
It is a check of running SAP services against a catalogue of known issues, performed over the network against each service as it is actually configured, rather than against a list of what is installed. Each check is written for one kind of SAP service. The scan sends the check's request to the service, reads what comes back, and writes a finding when the answer is the one an affected system gives.
Four kinds of statement appear on a report, and only the first is a measurement of the landscape. The capability keeps them apart on purpose.
| Statement | Where it comes from | What it is |
|---|---|---|
| This service answered the way an affected system answers | The scan, at the moment it ran | A measurement, of one port of one host |
| This class of issue is rated critical | The check catalogue, and the SAP vendor rating beside it | A published opinion about the issue, not about your system |
| Somebody accepted this risk | A person, in the console, after the scan | A record of a decision, with no re-test behind it |
| This report holds twenty findings | Arithmetic over the rows in the report | A count of rows, not a count of distinct problems |
¶ How does the scan decide which checks to run?
By service type. Every check in the catalogue is written against one kind of SAP service, and a scan runs only the checks belonging to the service types that were found on that host. A landscape whose exposure is mostly Java HTTP is asked a large set of questions. A landscape exposing one dispatcher is asked a small one.
The consequence is worth stating plainly, because it is invisible on a report: the catalogue never runs whole. What ran against a landscape was decided by what the port scan recorded on it. A service that was not in the inventory was not probed, and a service of a type the catalogue has nothing written against was visited and asked nothing. Neither of those looks different from a service that was asked everything and answered clean, which is why what a clean report does not say is a page here rather than a footnote.
¶ What does one finding identify?
One issue, on one host, on one instance, on one port, in one report. Change any of those and it is a different finding, with its own record and its own triage state. The port is part of the answer, not a detail of it: the plain and the encrypted face of the same service are two listeners, they can be patched or filtered apart, and an assessment that folded them into one row would be asserting something it did not measure.
The full anatomy of a finding, including what it deliberately does not carry, is on what one vulnerability finding says.
¶ Which SAP services are covered?
Checks are written per service family, and the families are the ones an SAP landscape typically exposes to a network:
- The ABAP web stack, reached through the Internet Communication Framework (ICF)
- The message server's HTTP face
- The ABAP dispatcher
- The SAP Java HTTP stack, and the Java P4 service
- SAP HANA, checked over a database session rather than over HTTP
- SAP Cloud Connector
- SAP Business One Web UI
- SAP BusinessObjects REST web services
SAP vulnerabilities an assessment finds covers what the checks are looking for in each: missing authentication on administrative endpoints, optional services left enabled, information disclosure, denial of service exposure, and configuration files whose absence removes an access control.
The catalogue never runs whole: a service the port scan did not record was not probed, and a service of a type nothing is written against was asked nothing. Neither looks different on a report from a service that was asked everything and answered clean.
¶ What does the scan need from the landscape?
Two things, and the second is optional in a way that changes the answer. It needs the service inventory from a completed port scan, and it needs any credentials you choose to store against a service. Checks written to be answerable by a stranger run without any logon. The rest run only where a logon is stored, and where none is stored they are skipped rather than run and found clean. Scanning with and without credentials sets out what each half can and cannot see.
A full scan also runs this platform's SAP profile parameter, component version and SAP Security Notes checks over Remote Function Call (RFC), where the licence permits them, so a scan window should be planned for more than an HTTP sweep.
A check sends a request and reads an answer. Nothing in the assessment attempts an exploit or writes business data.
¶ What this capability does not do
- It does not exploit anything. A check sends a request and reads an answer. It does not create a user, run a configuration task, or attempt the denial of service it reports. A finding is an inference from how the service replied, and it is exactly as good as that inference.
- It does not score. There are four severity bands and no numeric field: no CVSS score, no risk figure, nothing to sum, average or threshold. Severity decides an order and nothing else.
- It does not reconcile one scan against the next. A new scan writes a new report. Nothing matches a finding to a finding in the previous report, and no decision is carried forward. See repeat scans and comparing reports.
- It does not re-test a decision. Marking a finding fixed records that a person said so. Nothing re-runs the check.
- It does not ask what is listening. That is the SAP port and service scan, and this capability inherits its answer.
- It does not ask who can reach the service. Everything recorded was reachable from the machine the scan ran on. The assessment holds no network topology and makes no claim about anybody else's route.
- It does not ask about people. No user, role or authorisation object appears here. That is SAP segregation of duties analysis.
¶ Start here
¶ Frequently asked questions
¶ Is this an authenticated or an unauthenticated scan?
Both, on the same run. Checks written to be answerable without a logon always run. Checks that need one run only against services where a logon is stored. A report does not carry a mark saying which of the two populations produced it, so record what was stored at the time of the scan.
¶ Does the scan change anything on the SAP system?
The network checks send requests and read answers. A full scan additionally reads profile parameters, component versions and SAP note status over RFC. Nothing in the assessment attempts an exploit or writes business data.
¶ Does it give me a CVSS score per system?
No. Findings carry one of four severity bands, and the catalogue publishes a RedRays rating and an SAP rating for the underlying issue. There is no numeric score in the capability and no aggregate risk figure for a system.
¶ Where does the data go?
The platform is installed on your own infrastructure, and scan results, connections and history stay there. See deployment and where data goes.
¶ How is this different from asking the Basis team for the SAP note list?
A note list says what is installed. An assessment says what a service answers on the port it answers on. The two disagree in both directions, and why a patch list is not an exposure report works through how.