Configuration Review
Configuration Review of SAP
SAP holds the transactions, the master data and usually the payroll, and it is frequently outside the scope of both the security team and the penetration test because nobody in either group speaks it. The result is a system running default credentials on standard users, RFC connections with stored passwords, and an authorisation model that grew through copied roles. This review is specifically for that gap.
Methodology
- 01
System landscape review
Development, quality and production systems, client structure, patch and support pack level, and the connections between them.
- 02
Profile parameter review
Security-relevant instance parameters assessed against SAP's recommendations — password policy, login controls, gateway, message server and RFC security.
- 03
Standard user review
SAP*, DDIC, EARLYWATCH, TMSADM and SAPCPIC checked for default passwords, lock status and client coverage, including clients nobody uses.
- 04
Authorisation review
Critical authorisations, wide-open objects, roles granting SAP_ALL equivalents, and the composite roles that combine benign single roles into something dangerous.
- 05
Segregation of duties analysis
Toxic combinations across finance, procurement and HR — vendor creation with payment approval, purchase order creation with goods receipt.
- 06
RFC and interface review
RFC destinations with stored credentials, trust relationships between systems, and whether a development system can reach production.
- 07
Transport and change control review
Client settings, transport approval, and whether production is open for direct changes.
- 08
Reporting and retest
Technical report and executive summary together, with remediation sequenced around SAP change windows, then a retest confirming closure.
Approach to testing
- Read-only assessment using a dedicated audit role. No configuration changed, no transport created, nothing executed in production beyond display transactions.
- The whole landscape is assessed, not just production. A development system with a trusted RFC to production is a production risk.
- Every client is checked, including the ones nobody uses. Client 066 and unused copies routinely hold standard users with default passwords.
- Segregation of duties is assessed against the client's own rule set where one exists, and against a standard rule set where it does not — with the absence reported.
- Remediation is sequenced around SAP release and transport cycles. Authorisation changes are tested in development and transported, not made directly in production.
Types of assessment
Configuration and authorisation review (default)
Parameters, standard users, roles and interfaces across the landscape. Read-only.
Segregation of duties analysis
Toxic combination analysis across finance and procurement. Usually driven by audit and often the trigger for the wider review.
Interface and RFC review
Focused on connections between systems and to external parties, where credentials are commonly stored in clear.
Pre-audit readiness
Scoped to what an external auditor will test, run ahead of the audit so findings are remediated rather than reported.
Frameworks and standards
- SAP Security Baseline Template
- SAP's own baseline, which is the primary reference and is frequently ignored.
- SAP Security Notes
- Patch correlation, particularly for the notes rated Hot News.
- DSAG Audit Guideline
- The German-speaking user group's guidance, widely used as the practical audit standard.
- ISO/IEC 27001 Annex A
- Control mapping where the client maintains an ISMS.
- SOX / ITGC
- Where in scope, access provisioning, change control and segregation of duties are assessed against audit expectations.
Tools used
Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.
SAP standard transactions (display only)
RSPARAM, SUIM, SM59, STMS, SE16 in display mode for configuration and authorisation extraction.
SAP EarlyWatch Alert
Reading the client's own existing reports for patch and parameter baseline.
Custom authorisation analysis scripts
Role and profile extraction, and toxic combination detection at scale.
SAP Solution Manager
Configuration validation and security note compliance where deployed.
Pathlock / Onapsis (where deployed)
Reading existing controls rather than duplicating them.
Checklist approach
The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.
Standard users and passwords
- SAP* and DDIC default passwords across every client
- EARLYWATCH, TMSADM, SAPCPIC status
- Client 000, 001 and 066 review
- SAP* existence in clients where it should be deleted
- Password policy parameters against SAP guidance
- Lock and expiry status for dormant administrative users
Profile parameters
- login/* parameters: failed attempts, password complexity, session limits
- Gateway security: gw/monitor, gw/reg_no_conn_info and access control lists
- Message server access control
- RFC security parameters
- auth/no_check_in_some_cases and authorisation switch settings
- Audit log activation and retention
Authorisations
- Users with SAP_ALL, SAP_NEW or equivalent composite access
- Critical authorisation objects granted widely: S_DEVELOP, S_TABU_DIS, S_RFC
- Debug with replace authorisation in production
- Roles copied and modified without review
- Dialog users with system or communication user privileges
- Firefighter and emergency access process
Segregation of duties
- Vendor master maintenance combined with payment processing
- Purchase order creation combined with goods receipt
- Journal entry creation combined with posting approval
- HR master data combined with payroll execution
- User administration combined with role maintenance
Interfaces and transports
- RFC destinations with stored credentials
- Trusted RFC from lower systems to production
- External interfaces and their authentication
- Client change options in production
- Transport approval workflow and emergency transport handling
- Direct table maintenance in production
How findings are scored
Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.
- Critical
- Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
- High
- Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
- Medium
- Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
- Low
- Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
- Informational
- A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.
Scan types selected
- Safe Checks
- Standard / OWASP Top 10
- Destructive
- SANS Top 25
- Business Logic Vulnerability Testing
Standard toolset by stage
- OSINT
- Datasploit, Google Dorks, Shodan
- Enumeration & Scanning
- Nmap, Wfuzz, Unicornscan
- Domain Enumeration
- Nikto, DnsRecon, Knock
- Crawling & Fuzzing
- Burp Suite, Acunetix, Netsparker
- Vulnerability Analysis
- OpenSSL, sqlmap, CVE-Details
- Exploitation
- Metasploit, Netcat, Exploit-DB
How CSS tests
A unified swarm of agents, for blind spot detection
AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.
Authorisation analysis in SAP is combinatorial across users, roles, profiles and objects. Effective authorisation for every user is computation that manual review cannot approach at scale.
Segregation of duties conflicts arise from combinations of roles that are each individually reasonable; enumerating every pair and triple across thousands of users is machine work.
Unused clients and forgotten systems in the landscape are found by systematic enumeration rather than by asking, because nobody remembers them.
RFC destination analysis across every system, including which have stored credentials and which direction the trust runs, builds a graph that reveals paths from development to production.
Every agent finding is validated by a human reviewer with SAP experience before it reaches the report. Analysis runs against extracted data; nothing is executed in production beyond display transactions, and no change is made.
Why this differs
What CSS does that most vendors do not
Every one of these is checkable. Ask any vendor for the same and compare the answers.
SAP is actually in scope
Most security programmes exclude SAP because the security team does not speak it and the SAP team does not consider security their remit. CSS assesses it directly, which for many clients is the first time anyone has.
The whole landscape, not just production
A development system with a trusted RFC to production is a production risk. Assessing production in isolation misses the route in.
Both reports, always
Technical report and executive summary together, with findings expressed in business process terms for the second.
Fixation, not a backlog
SAP authorisation remediation is delicate. CSS works the change through development and transport with the Basis and functional teams, and retests to evidence closure.
Reporting
Two documents, two audiences
Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.
Technical assessment report
For the engineers who will fix it
- Disclaimer, and Limitations on Disclosure and Use
- Risk Level & Description — the five levels above, scored on CVSS 3.1
- Scan Type — which of the five assessment types were selected
- Assessment Scope — the control areas covered
- Assessment Date — the exact testing window
- Objective of the Assessment — objectives listed against completion status
- Tools Utilization — manual and automated tooling by stage
- Summary of the Assessment
- Overall Recommendations, split into Must Have and Should Have
- Vulnerability Overall Classifications as per Organization
- Security Issues Highlighted
- The Key Findings — each with evidence and detailed recommendation
- Summary of Findings & Conclusion
For this assessment specifically
- Scope: systems, clients, release and support pack levels, and the review date
- Findings against the SAP Security Baseline with parameter and note references
- Standard user status across every client
- Critical authorisation analysis with affected user counts
- Segregation of duties conflicts with the role combinations named
- RFC and interface inventory with credential storage and trust direction
- Remediation sequenced through the transport landscape
- Retest results appended against each original finding
Executive summary
For the people who will fund the fix
- Objectives, each against a completion status
- Overall Finding of the Assessment — total threats identified, broken down by component and severity
- Summary of the Assessment
- Artefacts of the Assessment — the key findings as a numbered register with severity
- Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
- Overall Recommendation, including a Business Enabling Recommendation sequence
- Must Have and Should Have actions
For this assessment specifically
- Whether anyone outside the SAP team could obtain unrestricted access, and how
- Segregation of duties conflicts expressed as business risk, not as object names
- The three changes that most reduce exposure
- Audit and regulatory position where ITGC or SOX applies
- Remediation timeline against the transport calendar
- One page
Case studies
What this finds in practice
Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.
A manufacturer running ECC across development, quality and production.
- Finding
- SAP* existed in client 066 in production with the default password and was not locked. Client 066 had been unused since 2014 and was absent from every inventory, but it shared the same system and the account could be used to reach the database layer.
- Recommendation
- Delete client 066, and audit every client rather than only those in active use.
- Outcome
- Client deleted after confirmation it held no data. The audit found a second unused client from a 2018 test migration with the same issue.
A retail group preparing for SOX compliance.
- Finding
- Effective authorisation analysis found 43 users able to both create a vendor master record and approve payment against it. None held a role named for either function; the combination arose from three composite roles each granted for a legitimate reason.
- Recommendation
- Redesign the composite roles to eliminate the combination, and add a segregation of duties check to the role assignment workflow so the conflict cannot be reintroduced.
- Outcome
- All 43 conflicts resolved before the audit. The workflow check has since blocked eleven assignment requests that would have recreated a conflict.
A logistics company with a three-system SAP landscape.
- Finding
- The development system held a trusted RFC destination to production with a stored service user credential holding SAP_ALL. Any developer with debug access in development could use it to execute with unrestricted privilege in production.
- Recommendation
- Remove the trusted RFC, or restrict the destination user to a narrowly scoped role with no dialog capability. Review every RFC destination for direction and stored credentials.
- Outcome
- The destination was removed after confirming it was no longer used by any interface. The wider review found four more destinations with stored credentials, two of which were also removed.
Next
Scope this assessment
Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.