Skip to main content
Do checkout my poem section. You are going to love it.

Security Enhancements in SAP BASIS


Security Enhancements and their Setup & Configuration in SAP Basis

I. Introduction to SAP Basis Security

SAP Basis security focuses on protecting the SAP system at the technical layer, encompassing the operating system, database, application server, and network communication. It's about implementing safeguards to prevent unauthorized access, data breaches, system compromises, and ensuring compliance with security policies and regulations.

Key areas of SAP Basis Security:

  1. User and Authentication Management: Who can access the system and how they prove their identity.
  2. Authorization Management: What users can do once authenticated.
  3. Secure Communication: Protecting data in transit.
  4. System Hardening: Reducing the attack surface of the SAP system components.
  5. Auditing and Logging: Monitoring security-relevant events.
  6. Vulnerability Management: Identifying and patching security weaknesses.

II. Core Security Enhancements & Setup

A. User and Authentication Management

  1. Strong Password Policies:

    • Purpose: Enforce complex and regularly changed passwords to prevent brute-force attacks.
    • Configuration: Adjust profile parameters in RZ10 (instance/default profiles):
      • login/min_password_length: Minimum password length (e.g., 8-12 characters).
      • login/password_history: Number of old passwords remembered (e.g., 5-10).
      • login/password_expiration_time: Password validity in days (e.g., 30-90 days).
      • login/fails_to_user_lock: Number of failed logon attempts before user lock (e.g., 3-5).
      • login/min_password_letters, login/min_password_digits, login/min_password_specials: Require mixed characters.
      • login/password_regular_expression: (Newer NetWeaver) Use regex for highly complex rules.
    • Setup: Activate the "Password Change at Next Logon" flag (SU01) for new users.

  2. Single Sign-On (SSO):

    • Purpose: Enhance user experience and security by reducing password fatigue and the risk of weak/reused passwords. Centralizes authentication.
    • Methods & Setup:
      • SNC (Secure Network Communications):
        • Principle: SAP's native security layer for application-level data encryption and authentication. Uses external security products (e.g., SAP NetWeaver SSO, CommonCryptoLib, Kerberos, X.509 certificates).
        • Setup:
          • Install SNC library (libsapcrypto.so/sapcrypto.dll) and CommonCryptoLib (or other security product).
          • Configure profile parameters (snc/enable, snc/gssapi_lib, snc/identity/as, snc/qop).
          • Create credentials (e.g., PSEs for X.509) and distribute.
          • Configure users (SU01) with SNC names.
          • Configure RFC destinations (SM59) for SNC.
        • Benefits: End-to-end encryption, strong authentication (digital certificates, Kerberos).
      • SAML 2.0 (Security Assertion Markup Language):
        • Principle: Web-based SSO standard. SAP system acts as Service Provider (SP), integrating with an Identity Provider (IdP) like Azure AD, Okta, SAP IdM.
        • Setup:
          • Activate SICF service /sap/public/bc/sec/saml2.
          • Configure SAML 2.0 via transaction SAML2. Establish trusted providers (IdP/SP metadata exchange).
          • User mapping (e.g., email address, User ID).
        • Benefits: Standardized, cloud-friendly, supports multi-factor authentication (MFA) at IdP.
      • SPNego (Simple and Protected GSS-API Negotiation Mechanism):
        • Principle: For Windows-centric environments, leverages Microsoft Active Directory and Kerberos for SSO to SAP ABAP systems.
        • Setup:
          • Configure Active Directory (Service Principal Names - SPNs for SAP service user).
          • Install Kerberos keytab file on SAP system.
          • Configure profile parameters (spnego/enable, spnego/krb5_lib, spnego/user_principal, etc.).
          • Activate SICF service /sap/public/bc/spnego.
        • Benefits: Seamless SSO for Windows users, strong Kerberos authentication.

  3. Client 000/001/066 Security:

    • Purpose: These are default clients; 000 and 001 are for SAP reference and post-installation, 066 for SAP EarlyWatch/Solution Manager. They have powerful default users.
    • Configuration:
      • Change Default Passwords: Immediately change passwords for SAP*, DDIC, EARLYWATCH, SAPCPIC in these clients after installation.
      • Lock SAP* and DDIC: After initial setup and creating specific administrative users, consider locking SAP* and DDIC in clients 000, 001, 066 if not actively used.
      • Restrict Access: Restrict remote access to these clients.
      • Profile Parameter login/no_automatic_user_sapstar: Set to 1 to disable the automatic creation of SAP* if it's deleted. This prevents a backdoor.

B. Authorization Management

  1. Principle of Least Privilege:

    • Purpose: Users should only have authorizations absolutely necessary for their job function.
    • Setup:
      • Role-Based Access Control (RBAC): Design roles using PFCG.
      • Composite Roles: Combine single roles.
      • Derive Roles: For organizational units (e.g., company code, sales org).
      • Restrict Sensitive Authorizations: Restrict objects like S_TABU_DIS (table access), S_DEVELOP (development access), S_ADMI_FCD (system administration functions).
      • Separation of Duties (SoD): Identify and prevent conflicting authorizations (e.g., creating and approving a vendor). Use tools like SAP GRC Access Control.

  2. Critical Authorization Monitoring:

    • Purpose: Track usage of powerful authorizations to detect misuse.
    • Configuration: Configure the Security Audit Log (SM19) to monitor specific transactions (SM50, SM51, RZ10, SU01, PFCG, SE16, SA38, SM59), successful/failed logons, and changes to security-relevant parameters.

C. Secure Communication

  1. RFC (Remote Function Call) Security:

    • Purpose: Secure communication between SAP systems and external systems.
    • Configuration:
      • SM59 (RFC Destinations):
        • SNC Activation: Activate SNC for critical RFCs (Type 3 - ABAP, Type T - TCP/IP).
        • Trusted Systems: Use trusted system relationships (S_RFCACL) cautiously.
        • Gateway Security: Implement gateway security rules (reginfo, secinfo files) to control which programs can register and connect to the SAP gateway.
        • Authorization: Ensure the RFC user has only necessary S_RFC authorizations.
        • Secure Communications (SSL/TLS): Use HTTPS for HTTP-based RFCs.
      • Profile Parameters: gw/acl_mode, gw/reg_no_reg_info, gw/reg_info, gw/sec_info.

  2. Web Service Security (SOAP/REST):

    • Purpose: Secure external access to SAP web services.
    • Configuration:
      • SICF (Maintain Service):
        • Activate SSL/TLS for all external-facing services.
        • Require logon for services; avoid anonymous access unless absolutely necessary.
        • Use strong authentication methods (e.g., X.509 certificates, SAML assertions).
      • STRUST (Trust Manager): Manage SSL Server and Client PSEs for certificate-based authentication.
      • Message-Level Security: Implement WS-Security for SOAP-based services (digital signatures, encryption of message parts).

D. System Hardening

  1. Security Profile Parameters (RZ10):

    • DIR_CT_RUN: Restrict access to executable directories.
    • rsau/enable: Enable Security Audit Log.
    • rdisp/gui_auto_logout: Automatic GUI logout for inactivity.
    • rdisp/max_alt_modes: Limit parallel sessions per user.
    • RZ11: For runtime parameter changes and documentation.

  2. OS and Database Security:

    • Principle: Standard OS/DB hardening guidelines apply (e.g., minimum services, strong passwords for OS/DB users, regular patching, file system permissions).
    • Database User Management: Only allow necessary OS/DB users to access the database. Restrict default powerful users.
    • File System Permissions: Secure SAP installation directories (/sapmnt, exe, work directories).
    • Firewalls: Implement host-based firewalls (e.g., iptables, Windows Firewall) in addition to network firewalls.
    • Regular Patching: Apply latest OS, DB, and SAP security patches.

  3. Diagnostic and Debugging Tools:

    • Purpose: Limit powerful tools like debuggers (/h), ABAP Workbench (SE80), OS commands (SM49, SM69).
    • Configuration: Restrict S_DEVELOP, S_TOOLS_EX, S_ADMI_FCD=ADMN and SM49, SM69 authorizations to developers and Basis administrators only. Monitor their usage.

E. Auditing and Logging

  1. Security Audit Log (SM19 / SM20):

    • Purpose: Records security-relevant events for analysis and forensics.
    • Configuration (SM19):
      • Activate filters for critical events: successful/failed logons, transaction starts (SM50, SU01, PFCG), RFC calls, changes to user master data, security profile parameters.
      • Define filters for specific users or clients.
      • Activate the audit profile (rsau/enable = 1 in RZ10).
    • Analysis (SM20 / SM20N): View and analyze audit log entries.
    • Storage: Ensure sufficient space for audit logs and regular archiving.

  2. Gateway Logging:

    • Purpose: Logs connection attempts and activities via the SAP gateway.
    • Configuration: Profile parameters gw/logging, gw/log_level, gw/log_file.

  3. Work Process Trace Files:

    • Purpose: dev_w* and dev_disp logs can contain security-relevant information (e.g., failed logon attempts, program errors).
    • Monitoring: Regularly review.

III. Important Configuration to Keep in Mind

  1. Top-Down Approach: Start with network and OS security before configuring SAP application security.
  2. Least Privilege: Apply this principle rigorously to users, RFCs, and system accounts.
  3. Virtual Hostnames: Use virtual hostnames for all SAP instances (ASCS, DB, HANA) to provide a layer of abstraction and simplify network changes, reducing direct exposure of physical IPs.
  4. Dedicated Users: Create specific users for RFCs, system integrations, and background jobs with only the necessary authorizations. Avoid using powerful dialog users.
  5. Regular Patch Management: Stay up-to-date with SAP Security Notes, OS patches, and DB patches. Use SAP Note 1944855 for patch assessment.
  6. Security Audit Log (SM19/SM20): Always enable and configure this for critical events. It's your primary forensic tool.
  7. login/no_automatic_user_sapstar = 1: Set this parameter to prevent a back-door.
  8. Gateway Security Files (reginfo, secinfo): Harden these files to explicitly control what can register and connect to the SAP gateway. By default, they are often too open.
  9. SSL/TLS Everywhere: Encrypt all network communications where possible: SNC for internal SAP, SSL/TLS for HTTP/HTTPS, secure FTP (SFTP) for file transfers.
  10. Client 000/001/066: Secure SAP*, DDIC users in these clients immediately after installation.
  11. System Hardening Parameters: Review and set parameters like rdisp/gui_auto_logout and restrict debugging authorizations (S_DEVELOP).
  12. External Security Tools: Consider integrating with Security Information and Event Management (SIEM) systems for centralized logging and analysis.
  13. Security Notes Implementation: Use SAP Note Assistant (SNOTE) to implement recommended security notes.
  14. Transport Layer Security: Ensure secure transport routes between development, quality, and production systems.
  15. User Defaults: Set sensible defaults for new users (e.g., initial password policy, validity period).
  16. Monitoring: Actively monitor security logs, audit trails, and system health for anomalies.

30 Interview Questions and Answers (One-Liner) for Security Enhancements in SAP Basis

  1. Q: What is the purpose of login/min_password_length?
    • A: To enforce a minimum length for user passwords.
  2. Q: Which transaction is used to manage and configure the Security Audit Log?
    • A: SM19.
  3. Q: What is the main benefit of implementing SSO in SAP?
    • A: Enhanced user experience and stronger authentication, reducing password fatigue.
  4. Q: What does SNC stand for in SAP security?
    • A: Secure Network Communications.
  5. Q: Which profile parameter disables automatic creation of SAP* if it's deleted?
    • A: login/no_automatic_user_sapstar = 1.
  6. Q: In SM59, what setting enables SNC for RFC destinations?
    • A: Activation of SNC under the "Logon & Security" tab.
  7. Q: What is the purpose of rdisp/gui_auto_logout?
    • A: To automatically log out inactive GUI users.
  8. Q: Which standard allows SAP to integrate with Identity Providers like Azure AD for SSO?
    • A: SAML 2.0.
  9. Q: What are reginfo and secinfo files used for?
    • A: To secure the SAP gateway (external program registration and client connections).
  10. Q: What transaction is used to manage SSL certificates in SAP?
    • A: STRUST.
  11. Q: What is the principle of "least privilege" in security?
    • A: Users should only have authorizations absolutely necessary for their job.
  12. Q: Which SAP authorization object is critical for table access?
    • A: S_TABU_DIS.
  13. Q: What is SPNego used for in Windows-centric SAP environments?
    • A: SSO via Kerberos and Active Directory.
  14. Q: Which transaction is used to analyze the Security Audit Log?
    • A: SM20 or SM20N.
  15. Q: What are Service Principal Names (SPNs) related to in SAP security?
    • A: SPNego for Kerberos authentication.
  16. Q: How can you limit the number of parallel sessions a user can have?
    • A: Profile parameter rdisp/max_alt_modes.
  17. Q: Why is it important to change default passwords for users like SAP* and DDIC?
    • A: To prevent unauthorized access using well-known credentials.
  18. Q: What is the role of CommonCryptoLib in SAP security?
    • A: Provides cryptographic functions for SNC and SSL.
  19. Q: What is a key security risk of open RFC destinations?
    • A: Unauthorized access and execution of functions or commands.
  20. Q: What kind of encryption does SNC provide for data in transit?
    • A: Application-level encryption.
  21. Q: What is the login/fails_to_user_lock parameter for?
    • A: To set the number of failed logon attempts before a user is locked.
  22. Q: How can you harden the security of SICF services?
    • A: By activating SSL/TLS and requiring strong authentication.
  23. Q: What is the main purpose of "Separation of Duties (SoD)"?
    • A: To prevent a single individual from performing conflicting tasks that could lead to fraud.
  24. Q: Which OS-level files are crucial for Gateway security?
    • A: reginfo and secinfo.
  25. Q: What is login/password_expiration_time used for?
    • A: To set the validity period of passwords in days.
  26. Q: What is the DIR_CT_RUN parameter related to?
    • A: Restricting access to executable directories.
  27. Q: What is the purpose of a SIEM system in SAP security?
    • A: Centralized collection, analysis, and correlation of security logs from various sources, including SAP.
  28. Q: Which transaction helps manage trust relationships via certificates (PSEs)?
    • A: STRUST.
  29. Q: What is a typical recommendation for RFC user authorizations?
    • A: Use dedicated RFC users with the least privilege (S_RFC only for needed FMs).
  30. Q: What is the primary method for ensuring patch level security in SAP?
    • A: Regularly applying SAP Security Notes via SNOTE.

5 Scenario-Based Hard Questions and Answers for Security Enhancements in SAP Basis

  1. Scenario: Your SAP ECC system uses SNC for secure communication between application servers and the database, and for client GUI connections. Users frequently report "SNC Logon Failed" errors, while some RFC connections also fail with SNC-related errors. You've confirmed the SNC library (libsapcrypto.so) is present and accessible, and snc/enable is set to 1.

    • Q: What are the common underlying reasons for "SNC Logon Failed" errors in this scenario, and what specific Basis-level troubleshooting steps would you take to diagnose and resolve such issues?
    • A:

      • Common Underlying Reasons for "SNC Logon Failed" Errors:

        1. Incorrect SNC Name (User/RFC): The SNC name configured in SU01 for the user or in SM59 for the RFC destination does not match the actual SNC identity provided by the security product (e.g., certificate DN, Kerberos principal). This is a very common mistake.
        2. Missing/Expired Credentials (PSEs/Keytabs): The underlying security credentials (e.g., the Personal Security Environment - PSE file for X.509 certificates, or the Kerberos keytab file) are either missing, corrupted, expired, or have incorrect permissions/ownership for the SAP service user (<sidadm>).
        3. Incorrect SNC Library Path: The snc/gssapi_lib profile parameter points to the wrong path, or the libsapcrypto.so itself is corrupted or not the correct version.
        4. Network/Firewall Issues: Although SNC is application-level, underlying network connectivity issues (e.g., firewall blocking specific ports used by the security product for authentication or certificate revocation checks) can manifest as SNC failures.
        5. Time Synchronization: Significant time differences between the client/server and authentication server (e.g., Domain Controller for Kerberos) can cause authentication failures.
        6. Trust Issues (for X.509): If X.509 certificates are used, the SAP system's PSE (SSL Server/Client) might not trust the Certificate Authority (CA) that issued the user's/RFC's client certificate, or vice-versa.
        7. SNC QoS Mismatch: The snc/qop (Quality of Protection) level specified in the profile or RFC destination does not match what the client/server expects.

      • Specific Basis-Level Troubleshooting Steps:

        1. Check SAP Profile Parameters:
          • Verify snc/enable = 1 and snc/gssapi_lib path is correct (and library is accessible/readable by <sidadm>).
          • Verify snc/identity/as matches the system's SNC name and snc/qop is appropriate.
        2. Verify User/RFC SNC Names:
          • For Users: In SU01, check the "SNC" tab for the affected user. Compare the "SNC name" format with the actual identity. Example: p:CN=User Name, OU=Org Unit, O=Company, C=Country (for X.509) or p:user@REALM (for Kerberos).
          • For RFCs: In SM59, for the problematic RFC destination, go to "Logon & Security" tab. Ensure "SNC active" is checked and "SNC partner name" is correctly specified for the target system/program.
        3. Check Credentials (STRUST / Keytab):
          • For X.509 (PSEs): Go to STRUST. Check the SSL Server Standard and SSL Client Standard PSEs. Ensure they are valid (not expired), contain the correct certificates, and have the necessary trusted root certificates. Verify the ownership and permissions of the .pse and sapgenpse files at the OS level.
          • For Kerberos (Keytab): Verify the Kerberos krb5.conf path and the keytab file's existence, content, and permissions (read/execute for <sidadm>).
        4. Security Trace (snc/data_protection/min = 2):
          • Set snc/data_protection/min to 2 (Integrity) or 3 (Privacy) in RZ10 (or RZ11 for temporary runtime change) for more detailed SNC trace messages.
          • Restart the SAP instance (if changing in RZ10).
          • Reproduce the error.
          • Analyze dev_w* and dev_ms (Message Server) trace files. Look for SNC keywords and specific error codes (e.g., GSS-API error).
        5. Network and Time Checks:
          • Firewall: Temporarily disable host-based firewalls on client/server/DB to rule them out (only in controlled test environments).
          • Time Sync: Ensure strict time synchronization (NTP) across all involved systems (SAP instances, DB, AD/IdP).
        6. Security Product Logs: If using a third-party security product (e.g., Windows Event Viewer for Kerberos, specific logs for SSO solution), check their logs for authentication failures.
        7. SNC Configuration Tool (e.g., sapgenpse): Use sapgenpse (for CommonCryptoLib) to verify PSEs, generate certificates, and test SNC parameters outside of SAP.

  2. Scenario: Your recent external security audit of a production SAP ERP system flagged several critical findings: 1) Too many users with SAP_ALL profile in PROD, 2) Weak password policy parameters are set, 3) Critical transactions like SE16 (table browser) and SM49 (OS commands) are not being logged in the Security Audit Log (SM20), and 4) Default SAP client 000 has unused users with default passwords.

    • Q: Detail the specific Basis actions you would take to address each of these four audit findings, including relevant transactions, profile parameters, and best practices.
    • A:
      • Addressing Audit Findings:
        1. Too Many Users with SAP_ALL Profile in PROD:
          • Action: This is a major violation of the "Principle of Least Privilege."
            • Identify Users: Use SUIM (Users by Complex Selection Criteria -> By Authorization Profiles -> SAP_ALL).
            • Review and Restrict: For each user, collaborate with their manager and the security team to understand their exact job function.
            • Replace with Custom Roles: Design and assign specific custom roles (PFCG) that provide only the necessary authorizations for their daily tasks.
            • Remove SAP_ALL: Once custom roles are assigned and tested, remove the SAP_ALL profile from these users (SU01).
            • Emergency Access (Break-Glass): Implement a robust "break-glass" procedure using a limited set of SAP_ALL users (e.g., 2-3 Basis leads) with strict logging and approval processes (e.g., using SAP GRC Emergency Access Management). These accounts should be locked by default and only unlocked for approved, audited emergency situations.
        2. Weak Password Policy Parameters:
          • Action: Strengthen password policies to enforce complexity and regular changes.
            • Review Parameters (RZ10):
              • login/min_password_length: Increase to 10 or 12.
              • login/password_history: Increase to 10.
              • login/password_expiration_time: Decrease to 60 or 90 days.
              • login/min_password_letters, login/min_password_digits, login/min_password_specials: Set to ensure mixed case, numbers, and special characters.
              • Consider login/password_regular_expression for advanced rules.
            • Activation: Activate the changes in RZ10 and restart the SAP instance(s).
            • Forced Password Change: After changing policies, instruct users to change their passwords, or trigger a mass password reset requiring a new password at next logon.
        3. Critical Transactions (SE16, SM49) Not Logged in Security Audit Log:
          • Action: Configure SM19 to log these critical transactions.
            • Access SM19: Go to transaction SM19.
            • Create/Modify Profile: Select the active audit profile (or create a new one).
            • Add Filters: Go to "Filters" tab. Add new filters:
              • For "Event ID" select DIA (dialog events) or T (transaction start).
              • For "Transaction Code" enter SE16, SM49, SM50, SU01, PFCG, RZ10, etc.
              • Ensure "Log for" is set to "Success" and "Failure" (or just "Success" if desired for SE16/SM49).
            • Activate Profile: Ensure the updated profile is activated.
            • Verify Parameter (RZ10): Ensure rsau/enable = 1.
            • Monitor (SM20/SM20N): Regularly review SM20/SM20N to confirm these transactions are now being logged.
        4. Default SAP Client 000 has Unused Users with Default Passwords:
          • Action: Secure default users in standard clients.
            • Identify Users: In client 000 (or 001/066), use SU01 to check users like SAP*, DDIC, EARLYWATCH, SAPCPIC, TMSADM.
            • Change Passwords: Immediately change passwords for ALL these default users to complex, random strings.
            • Lock Users: For users not actively used (e.g., EARLYWATCH, SAPCPIC, TMSADM if not configured for TMS/Solution Manager), lock them using SU01.
            • login/no_automatic_user_sapstar: Ensure this profile parameter is set to 1 in RZ10 for enhanced protection against SAP* backdoor.
            • Restrict Access: Implement network-level restrictions (firewalls) to limit direct access to clients 000/001/066 to only Basis administrators from secure subnets.

  3. Scenario: Your company decides to implement Single Sign-On (SSO) for all SAP GUI users using Kerberos via SPNego (Simple and Protected GSS-API Negotiation Mechanism). You have a multi-application server SAP ECC system on Windows, connected to a Windows Active Directory domain. The Basis team is responsible for the SAP-side configuration.

    • Q: Outline the detailed Basis-level steps for configuring SPNego SSO on the SAP ABAP system, including prerequisite checks and potential challenges specific to a multi-application server environment.
    • A:

      • Detailed Basis-Level Steps for SPNego SSO Configuration:

        Phase 1: Prerequisites & Active Directory (AD) Coordination

        1. OS / Network:
          • Verify all SAP application servers (including ASCS) are joined to the Active Directory domain.
          • Ensure strict time synchronization (NTP) between all SAP servers and Active Directory Domain Controllers.
          • Verify DNS resolution for all SAP hostnames.
        2. SAP Kernel:
          • Ensure the SAP kernel is compatible with SPNego (NetWeaver 7.0 EHP2 or higher recommended).
          • Ensure CommonCryptoLib (or a compatible GSS-API library) is installed and accessible in the kernel's executable directory (e.g., DIR_EXE).
        3. Active Directory (Coordination with AD Team):
          • Service Account: Create a dedicated Active Directory user account (e.g., SAPService<SID>) that will represent the SAP system for Kerberos authentication. This account must have "Trust this user for delegation to any service (Kerberos only)" unchecked (security best practice).
          • Service Principal Names (SPNs): Register the necessary SPNs for the SAP service account. This maps the SAP service to the AD account.
            • For the ASCS Virtual Hostname: setspn -A SAP/<ASCS_VirtualHost> <Domain>\SAPService<SID>
            • For the ASCS Virtual Hostname FQDN: setspn -A SAP/<ASCS_VirtualHost.FQDN> <Domain>\SAPService<SID>
            • For each Application Server Physical Hostname: setspn -A SAP/<PhysicalHost> <Domain>\SAPService<SID>
            • For each Application Server Physical Hostname FQDN: setspn -A SAP/<PhysicalHost.FQDN> <Domain>\SAPService<SID>
            • (Note: For a multi-app server system, the SPNs for the application servers are often also needed if users might connect directly to them, although the ASCS SPNs are most critical for initial ticket granting).
          • Keytab File: The AD team (or you, with appropriate permissions) will generate a Kerberos keytab file (krb5.keytab) for the SAPService<SID> account. This file contains the cryptographic keys and must be securely transferred to the SAP system.

        Phase 2: SAP ABAP System Configuration

        1. Keytab File Placement:
          • Place the krb5.keytab file in a secure, accessible location on all SAP application servers (including ASCS) (e.g., C:\usr\sap\<SID>\SYS\global\security\). Ensure <sidadm> user has read/execute permissions.
        2. Profile Parameters (RZ10):
          • Go to RZ10 and configure the following parameters in the Default Profile or Instance Profiles for all relevant application servers:
            • spnego/enable = 1 (Enables SPNego)
            • spnego/krb5_lib = <path_to_CommonCryptoLib> (e.g., C:\usr\sap\<SID>\SYS\exe\uc\NTAMD64\sapcrypto.dll)
            • spnego/krb5_conf_lib = <path_to_Kerberos_config> (e.g., C:\Windows\krb5.ini or leave blank if using default AD configs)
            • spnego/keytab = <path_to_keytab_file> (e.g., C:\usr\sap\<SID>\SYS\global\security\krb5.keytab)
            • spnego/user_principal = SAP/<ASCS_VirtualHost>@YOUR.AD.REALM (Service Principal Name of the ASCS, specify the full Kerberos realm). This is critical for the ASCS instance.
            • snc/enable = 1 (SPNego relies on SNC infrastructure).
            • snc/gssapi_lib = <path_to_CommonCryptoLib> (same as spnego/krb5_lib).
            • snc/permit_insecure_start = 0 (Best practice, forces secure connections).
          • Restart SAP Instances: After changing profile parameters, restart all relevant SAP application servers (including ASCS) for changes to take effect.
        3. Activate SPNego Service (SICF):
          • Go to SICF. Navigate to path /sap/public/bc/spnego.
          • Activate this service.
        4. SNC Configuration in SU01 (User Mapping):
          • For each SAP user who will use SPNego, maintain their SNC name in SU01 (SNC tab).
          • Format: p:<AD_User_UPN>@YOUR.AD.REALM (e.g., p:johndoe@YOUR.AD.REALM). Alternatively, for initial setup, you can also use p:* for testing, then configure specific users.
          • This maps the Kerberos principal to the SAP user.

      • Potential Challenges Specific to Multi-Application Server Environment:

        1. Keytab Distribution & Permissions: Ensuring the krb5.keytab file is identical, placed correctly, and has correct permissions on all application servers (including ASCS) can be challenging. An incorrect keytab on even one server can cause intermittent SSO failures.
        2. SPN Registration Complexity: Correctly registering all necessary SPNs (especially for application servers if they handle direct user connections or specific services) can be tricky. Missing or duplicate SPNs will cause authentication failures.
        3. Load Balancing for SSO: If using SAP Web Dispatcher or a hardware load balancer, ensuring Kerberos tickets are correctly handled across multiple application servers is important. The SPN for the Web Dispatcher's virtual hostname might also be needed.
        4. Client-Side Configuration: Users' desktops must be correctly configured for Kerberos (e.g., trusted sites in IE, no proxies breaking Kerberos authentication). GPOs in AD can help standardize this.
        5. Troubleshooting Trace Files: Debugging SPNego issues often requires analyzing Kerberos logs (Windows Event Viewer on Domain Controllers/clients), SAP developer traces (dev_w*), and sapstartsrv logs, which can be verbose.

  4. Scenario: Your company's internal security team detected suspicious activity originating from an RFC connection. Further investigation revealed a custom RFC-enabled function module (FM) that allows arbitrary OS commands to be executed via CALL SYSTEM without sufficient authorization checks. This FM is used by a third-party application via a dedicated RFC user.

    • Q: What are the immediate and long-term Basis-level security measures you would take to mitigate this vulnerability and secure your SAP system against similar future attacks via RFC?
    • A:

      • Immediate Basis-Level Security Measures:

        1. Disable/Restrict Vulnerable RFC FM:
          • Action: Immediately identify the custom RFC-enabled function module. In SE37, change its processing type to "Normal function module" (remove "Remote-Enabled Module") or delete it if it's no longer needed. Alternatively, temporarily disable the RFC user or remove its S_RFC authorization for that specific FM.
          • Rationale: Stop the immediate threat of arbitrary OS command execution.
        2. Lock/Review RFC User:
          • Action: Lock the dedicated RFC user (SU01) used by the third-party application.
          • Action: Review the S_RFC authorizations of all RFC users (SUIM) to identify any other users with overly broad access (e.g., S_RFC for * or critical function groups like SXPG).
          • Rationale: Prevent the attacker from using the same entry point.
        3. Check Security Audit Log (SM20/SM20N):
          • Action: Review SM20/SM20N for past activities by the compromised RFC user and any related RFC event IDs. Look for T (transaction start), B (RFC call), C (command execution) events.
          • Rationale: Understand the extent of the breach and identify any other executed commands.
        4. Network-Level Block:
          • Action: Coordinate with the network team to immediately block inbound RFC connections from the IP address of the compromised third-party application or its server, if the application is not immediately critical.
          • Rationale: Add an immediate layer of network defense.

      • Long-Term Basis-Level Security Measures:

        1. Secure Gateway Security Files (reginfo, secinfo):
          • Action: Harden these files. reginfo controls program registration at the Gateway (e.g., for external RFC servers). secinfo controls which hosts and programs can connect to the Gateway.
          • Configuration: Define explicit ACL_ALLOWED_PROGRAMS in reginfo for only allowed registered programs. Define P (program), H (host), U (user) rules in secinfo for allowed connections. Set gw/acl_mode = 1 in RZ10.
          • Rationale: Prevents unauthorized external programs from registering or connecting to the SAP Gateway.
        2. Principle of Least Privilege for RFC Users:
          • Action: For every RFC user, define authorizations strictly based on the Function Modules (FMs) they absolutely need to call. Grant S_RFC authorization only for specific function groups or FMs, not *.
          • Action: Review custom FMs that use CALL SYSTEM (or similar OS command execution). These should never be RFC-enabled unless absolutely necessary and with extremely strict internal authorization checks (e.g., AUTHORITY-CHECK on S_ADMI_FCD=UNIX).
          • Rationale: Limits the impact if an RFC user is compromised.
        3. Implement SNC for RFC Connections:
          • Action: Configure SNC for all critical RFC destinations (SM59). This encrypts the communication and provides strong authentication using certificates or Kerberos.
          • Rationale: Prevents eavesdropping and replay attacks, and ensures mutual authentication.
        4. Code Review and Static Analysis:
          • Action: Work with development teams to implement security-focused code reviews and static code analysis (e.g., using SAP Code Vulnerability Analysis - CVA) for all custom RFC-enabled FMs, especially those involving OS interaction or sensitive data.
          • Rationale: Proactively identify and fix vulnerabilities in custom code.
        5. Security Audit Log (SM19) Enhancement:
          • Action: Ensure SM19 is configured to log all RFC calls (event ID B) and critical system commands (event ID C). Filter for specific RFC users or function modules.
          • Rationale: Provides an audit trail for all RFC-related activities.
        6. Regular Vulnerability Scans:
          • Action: Implement regular vulnerability scanning of your SAP systems (using tools like SAP's own security tools or third-party scanners) to identify open ports, insecure configurations, and unpatched vulnerabilities.

  5. Scenario: Your Security Audit Log (SM20) is generating an overwhelming number of "successful logon" messages, making it difficult to detect actual suspicious activities. Additionally, your storage team reports that the audit log filesystem is filling up rapidly, requiring frequent manual purges. Your current policy dictates keeping audit logs for at least 3 months.

    • Q: How would you optimize the Security Audit Log configuration to reduce log volume while retaining critical security information for a 3-month retention policy, and what additional steps would you take to manage log storage and improve alert signal-to-noise ratio?
    • A:

      • Optimizing Security Audit Log Configuration (SM19) to Reduce Volume:

        1. Refine Event Filters:
          • Action: In SM19, for the active audit profile, go to the "Filters" tab.
          • Log Event A (Successful Logon): Instead of logging all successful logons for all users, refine this.
            • Filter by User Type: Only log successful logons for dialog users (login/user_type_diag) and system users (login/user_type_system), but exclude CPIC users unless specifically required for integration troubleshooting.
            • Exclude Trusted RFC Users: For high-volume RFC integrations from trusted systems, consider if you truly need every successful RFC logon logged for dedicated, tightly controlled RFC users. If not, exclude them or apply specific, less verbose filters.
            • Focus on Failures: Prioritize logging failed logons (Event ID B for RFC, A for dialog) for all users, as these are often more indicative of an attack.
          • Focus on High-Value Events:
            • Ensure critical events are logged: Transaction Starts (T) for sensitive Tcodes (SU01, PFCG, RZ10, SM59, SE16, SM49, etc.), User Master Record Changes (U), Security Profile Parameter Changes (E), RFC Calls (B).
            • Consider not logging verbose but non-critical events (e.g., specific reports that run very frequently but are not security-sensitive).
        2. Filter by Client/User Group: If certain clients or user groups are "low-risk" or generate excessive noise, consider creating specific filters to exclude them or reduce the granularity of logging for them.
        3. Activate Profile: After adjusting filters, ensure the new audit profile is activated in SM19.

      • Additional Steps for Log Storage and Alert Signal-to-Noise Ratio:

        1. Increase Audit File Size and Number:
          • Action: Adjust profile parameters rsau/max_diskspace/local (total disk space for local audit files) and rsau/local/file (individual file size) in RZ10. Increase these to allow fewer, larger files, reducing overhead and allowing longer local retention.
          • Rationale: Provides more local buffer before files are sent to the central audit log.
        2. Central Audit Log (rsau/collect_all_sids):
          • Action: If not already configured, set up a central audit log server (rsau/collect_all_sids = 1 on the collector system, rsau/collector_host on the systems being logged). This consolidates logs from multiple application servers to one location.
          • Rationale: Simplifies management, archiving, and analysis.
        3. Automated Archiving and Deletion:
          • Action: Implement a regular background job (e.g., using RSNU_ARCHIVE_SECURITY_AUDIT or RSNUA000) to:
            • Read audit files from the active directory (DIR_AUDIT).
            • Archive them to a dedicated, secure storage (e.g., an NFS share, a content repository, or a separate drive with sufficient space).
            • Delete old files from the active directory after successful archiving, while ensuring the 3-month retention policy is met (e.g., keep 3 months of archived files).
          • Rationale: Ensures compliance and prevents filesystem overflow.
        4. Integration with SIEM (Security Information and Event Management) System:
          • Action: Forward SAP Security Audit Logs (and other relevant logs like Gateway logs, System Logs) to an external SIEM system (e.g., Splunk, QRadar, ArcSight). This usually involves configuring SAP to send syslog messages or using a dedicated connector/agent.
          • Rationale:
            • Centralized Storage & Long-Term Retention: SIEMs are designed for massive log storage and long-term retention beyond 3 months.
            • Advanced Analytics & Correlation: SIEMs can correlate SAP logs with logs from OS, network, firewalls, and other applications, providing a more holistic view of security incidents and reducing false positives (improving signal-to-noise).
            • Automated Alerting: Configure the SIEM to generate alerts only for truly suspicious or critical correlated events, rather than every successful logon.
        5. Review and Optimize Other Logging:
          • Action: Review other SAP logs (e.g., Gateway logs gw/logging, System Logs SYSLOG) to ensure they are not excessively verbose if not needed for critical security monitoring.

This comprehensive approach helps balance the need for detailed security logging with system performance and storage efficiency.

Comments

Post a Comment

Popular posts from this blog

An experiment with the life

"Best Thing about experiment is that it only improves the outcome." Well, I am Rakshit, hope you already know. I am not special and surely not especially gifted. Neither things go according to my wish. Neither I am the best writer.  But I am myself who is totally unique from anyone else. And I am Rakshit Ranjan Singh. I have my own fun, fights and fall in the most fundamentalistic way. Mechanical is my degree. IT is my Job. Beauty in nature is what I search. Words of my heart are what I write. Four different things I carry on my shoulder and a smile on my face, hope you might have seen that. What do I care for? Family, friends and nature. Do I have regrets? More than I can imagine. Let us move further to see what really is my life.
Read more

Learn Java

Hello Friends, You might already know what Java is. Without taking much of your time, I would like to ask you to please click below if you are ready to learn it from end to end. The Material over here is available on the internet and is free to access.  I would request you to bookmark this page and follow it. Please comment if you are happy with the learning. click here
Post a Comment
Read more

Driving

My Driving Journey: From Zero to (Almost) Hero! Hello everyone! I'm excited to share my ongoing adventure of learning to drive. It's been a mix of nervous excitement, hilarious near-misses, and the slow but steady feeling of progress. Buckle up, because here's a peek into my journey behind the wheel! The First Lesson: Clutch Confusion! My first time in the driver's seat was... memorable. Let's just say the clutch and I weren't immediate friends. Lots of jerky starts and a few stalls later, I began to understand the delicate dance between the pedals. My instructor was incredibly patient (thank goodness!). Mastering the Steering Wheel (Sort Of) Steering seemed straightforward enough, but navigating turns smoothly was a different story. I definitely had a few moments of feeling like I was wrestling with the wheel. Slowly but...
Post a Comment
Read more