SAP Security Sample Interview Questions

Sample SAP Security Interview Questions with Answers

105 SAP Security Interview Questions with Answers & Explanations – eBook

SAP Security interview questions can cover a very wide range.

Here is a sample of questions that a typical Security Consultant can be expected to face.

Q1. You setup Single Sign-On with SAP logon tickets in Application Server ABAP and an error is displayed in the trace of transaction SM50 .

What kind of errors may you see, and what are the possible causes & their potential solutions?

Answer;

The following is a list of the error messages and their possible causes.

1. Invalid certificate

This error means that the signature of the SAP logon ticket cannot be checked. The reason for this error is often because the certificate that is used is no longer valid. the certificate that is used is not yet valid. the maximum validity of the certificate exceeds the date January 01, 2038.

In the system that issues the ticket, check the validity of the certificate that is used. If necessary, create a new certificate which conforms to the above criteria.

2. An entry is missing from the access control list (ACS)

The ACL is client specific and must be maintained in the client in which you intend to use the SAP logon ticket. In the accepting system, use transaction STRUSTSSO2 to check whether the ACL is maintained in the corresponding client.

If you have implemented ICF SAP Note1566201, these entries may occur for CLI 000 even though you do not want to log on to client 000. Implement the ICF SAP Note 1674879 to correct the error.

3. There is an obsolete entry in the ACL

When an entry is added to the ACL, the serial number of the certificate is also added. If you have created a new certificate in the system that issues the ticket and its serial number is different from the serial number used previously, you must update the entry in the ACL also.

4. The certificate does not exist in the certificate list

This error means that the certificate of the issuing system cannot be found. The reason for this error is often because the certificate of the issuing system is not in the certificate list of the system Personal Security Environment (PSE) in the accepting system.

There is an obsolete certificate of the issuing system in the certificate list of the accepting system (for example, after the regeneration of a key pair in the issuing system).

The accepting system is configured so that a different PSE is used to verify the logon ticket which the certificate of the accepting system does not contain.

5. Receiver data is incorrect

For the SAP assertion ticket, the receiver data must match the current system data. Therefore, you must check the entries in the issuing system.

6. No digital signature could be generated

To issue a digital signature, the system requires a PSE. The PSE is stored on the file system of the application server and additional meta information about the file is saved in the database. If you now change the file directly at file system level, inconsistencies may occur.

To correct this problem, proceed as follows:

– Call transaction STRUST

– Double-click the entry “System PSE”

– From the menu, select “PSE > Save as.. .”

– Select the option “System PSE”

– Confirm the dialogs that follow

=> As a result, the PSE is saved again in the file system and the database tables are cleaned up.

Q2. A WebService Definition is created from a Function Module.

When creating a runtime configuration (endpoint) in transaction SOAMANAGER, it is not possible to select ‘No authentication’. The option is grayed out.

Why is this and how can this be dealt with?

Answer;

‘No authentication’ is considered to be too weak to meet the Design Time object’s security requirements.

Resolution

Change the security profile as follows:

Go to transaction SE80 and search for the WebService definition within Enterprise Services.
Switch to Change mode.
Click on the Configuration tab.
Select Security Profile from the Objects tree.
On the right side choose ‘None’ from the radio button list.
Save and activate the service.

Q3. You are looking for different possibilities to log user activities in the SAP system, among other things to;

– understand transactions and changes

– execute DP audits

– analyse security incidents in the system

– recognize security gaps

– optimize the security settings

How would you do this?

Answer;

In the standard SAP System, extensive functions exist for logging user activities and changes to the system.You must use them selectively to record the required data specifically, and at the same time to facilitate their efficient evaluation and utilization. When you log user activities you must generally note that;

– Existing data protection laws are not violated (for example, German Data Protection Act). In certain cases, recording is only permitted when approved by the data protection officer and an employee representative and is additionally subject to the regulations of a company agreement.

– Large datasets can develop very quickly whose storage and evaluation require considerable operating funds which can reach the limits of practical feasibility.

In the overview, the following functions are displayed in the standard SAP System:

Logging table changes:
————————————–
Logging table changes for Customizing is activated via the profile parameters rec/client. In the standard system tables that must be logged are marked for logging. Customer-specific settings are possible via Transaction SE11: Tools –> ABAP Workbench –> Dictionary –> Database table –> Technical settings

Transaction SCU3 can be used for evaluation.

(see R/3 Online help: BC ABAP Dictionary –> Logging)

Master data table changes are written according to the principles of the respective accounting (GOBS) in the proper business areas via change documents. With this, the change, the name of the user, the current field contents and the previous field contents are all logged for each field.

Statistical data for user behavior:
————————————————
In the system, statistical data for the workload and for the user behavior is constantly recorded and compressed in adjustable time intervals.This statistical data is only accessible for users with administration authorization and is used exclusively for the purpose of an efficient and secure operation of the SAP system.

If statistical data is used for the purpose of the settlement, the settlement number is evaluated rather than the user name. The recording of statistical data can also be deactivated.

Transaction STAT: Tools –> CCMS –> Control/Monitoring –> Performance menu –> Workload –> Statistics records

(also see R/3 Online Help: BC Computing Center Management System –> Workload Monitor)

Logging security-related system events:
——————————————————
The syslog is available for this, and as of Release 4.0 the security audit log is additionally available.In the syslog, the locking of users and operating system calls are logged.

In the security audit log, the following is recorded: Logon, RFC logon, transaction start, call of RFC function modules, call of reports (as of Release 4.6), changes to user master records, start/stop of systems, download from data (as of Release 4.6) and so on.

To activate the security audit log, the profile parameter rsau/enable must be set, and settings must be defined with Transaction SM19.With Transaction SM20, the evaluation of the security audit log is carried out. The audit files can be reorganized using Transaction SM18.

System log (Transaction SM21): Administration –> System administration –> Monitor –> System log

(see R/3 Online help: BC System services –> System logs)

Security audit log (Transaction SM18, SM19, SM20): Administration –> System administration –> Monitor –> Security audit log

(see R/3 Online help: BC System services –> Security audit log)

SQL Audit log
——————-
As of Release 4.5, there is additionally the option to record all the resulting SQL “SELECT” statements from user actions in the database interface by specifiying the selection criteria, users, time, report and statement (refer to Note 115224).

Q4. What do you know about Cross-Site Request Forgery (XSRF) & how to effectively deal with it?

Answer;

Cross-site request forgery (also known as XSRF, CSRF, and Figure 2: example of a Cross-Site Request Forgery Attack session riding) is an attack in which an attacker is able to trick the victim into issuing an undesired request to a vulnerable application.

The challenge here lies in the fact that the request might inherit the identity and privileges of the victim (automatically sent by the browser) to perform an undesired function on the victim’s behalf, like changing the victim’s e-mail address, home address, or password or performing other actions like purchasing something. XSRF is especially critical if the application is protected by a single-sign-on mechanism that does not require any user interaction .

VULNERABILITIES

XSRF attacks generally target functions that cause a state change on the server or other critical or resource-consuming  operations. The figure below outlines such an attack by attacker Mallory on victim Bob.

The first two message exchanges between victim Bob’s user agent and the attacked Web AS of the imaginary “MyBank” serve for logging Bob on to the system and ensuring that Bob receives a valid session ID. In the following, the victim accesses a page on the right-hand side Web AS, which contains a link prepared by the attacker pointing to a vulnerable application on the “MyBank” server.

If the victim is lured into clicking that link, Bob’s user agent requests the resource from the “MyBank” Web AS. Together with that request, the session ID is sent along as a cookie. Therefore, the “MyBank” Web AS Victim Bob’s User Agent web application server (AS) www. myBank.com web AS with malicious code Access protected resource Provide credentials Return protected resource incl. valid authenticated sessions ID “Successfully transferred desired amount.”

Browser tries to read “image data”

Access page on the Web AS containing the link prepared by Mallory. Page contains malicious link, for example, hidden in IMG tag <img src=”http.www.MyBank. com/transfer?amount=100000&target=mallory”alt=”clickme”>

Minimum validity period of the victim’s session at www.MyBank.com accepts Bob’s request and executes the desired action of transferring €100,000 to Mallory.  Bob receives in his browser the confirmation message from “MyBank” that a transfer that he had not intended has been finished successfully.

Note that more advanced mechanisms exist for making the attack less obvious, such as hiding the malicious link in an image HTML tag (<img>), using JavaScript to auto-submit form data, and so on.

COUNTERMEASURES
A common countermeasure against XSRF relies on a secret token used to ensure the “freshness” of the requests as they are received at the application server. This secret token is created after logon and stored in the user’s session.

Subsequently, the token is included into state-changing local links and forms of an application. Upon receiving an HTTP request, the obtained secret token from the request can be compared with the expected secret token stored in the session.

The attacker cannot forge a request reliably, since the token value for the victim is not known to him or her. There are basically two players involved in providing XSRF protection: the technology or framework (like Java Web Container, the ABAP-based Web Dynpro development environment, or binary space partitioning [BSP]) and the application built on top of it.

The approach on how to protect applications depends on the characteristics of the technology. The following table gives an overview of the XSRF protection for various technologies used at SAP. In order to protect your own custom applications, you must first make the SAP framework available on the technology level by applying provided patches and, second, adapt your application to use the security framework.

The table “Notes on How to Use Security Mechanisms” provides notes on how to use these security mechanisms as well as things to consider – since in some cases your applications must be adapted.

SAP closes XSRF vulnerabilities in standard code with several SAP Notes like; web Dynpro – ABAP™ XSRF protection within the technology -> SAP Notes 1430970, 1436936, and [16] in web Dynpro – Java XSRF protection within the technology -> SAP Notes 1521024, 1327872

BSP applications XSRF protection within the framework -> SAP Note 1458171

ITS services XSRF protection within the framework -> SAP Note 1481392

Q5. SAP applications as well as custom-developed applications rely on relational database management system (RDBMS) servers.

The information is stored and retrieved with structured query language (SQL) statements. The vulnerability for ABAP-based implementations lies in the creation of dynamic SQL statements within program code (using native or open SQL), which allows user input to be executed directly without filtering or verification.

What do you know about these vulnerabilities & how would you secure your SAP landscape against these?

Answer:

Attackers are successful if they are able to change the semantics of a dynamic SQL statement for their benefit or are able to insert their own statements into the application. Figure 3 shows how malicious user input can lead to data leakage: a “where” clause is dynamically built upon user input, which retrieves unauthorized database content (here for open SQL).

The programmer expects single values in a string-named in-put that the program receives. As long as input contains only character strings like “LH,” the program works as intended. An attacker could put a string like “‘LH’ OR CARRID LIKE ‘%’,” which in this example selects all entries from the database table.

User input can come directly from an HTML form within a Web application, a URL, an input field in any SAP user interface, or other inputs (for example, within remote function calls from other systems or data-loading activities).

An attacker can exploit  this vulnerability to execute arbitrary database commands to retrieve, modify, or remove data persisted by the system.

For example, an attacker could gain unauthorized access to critical data like credit card numbers or manipulate the outcome of a business process by manipulating the data read.

COUNTERMEASURES
Open SQL for ABAP already provides some implicit protection against SQL code injection, and SAP further improved the quality of code in order to prevent SQL injection attacks on SAP products. Implement the provided SAP Notes in order to avoid SQL injection vulnerabilities for SAP products and applications.

Please consider that once the patches have been applied, SAP applications will not accept arbitrary input for dynamic SQL statements. This is especially important if your own applications perform calls to SAP applications that are affected by the SAP Notes. Please test your corresponding applications and adapt them if needed.

Further, if you have modified SAP applications or created your own programs that involve dynamic SQL statements (native or open SQL), consider improving your own code quality (for example, by replacing dynamic code with static code as far as possible).

Q6. Besides DIAG, ABAP systems offer Web-based access over HTTP. With HTTP all communication, including user credentials like passwords or SAP logon tickets, is unencrypted and can be sniffed in the network. Therefore, Web-based access should be secured using HTTPS (HTTP over SSL/TLS).

What are some of the best practices around it?

Answer:

Usage of HTTPS is strongly recommended at least for all browser access from end users to ABAP systems.

End users should not use HTTP to access ABAP systems. For communication between ABAP systems, HTTPS should be implemented if the network traffic is susceptible to sniffing by end users.

HTTPS should be implemented to terminate on infrastructure components (for example, load balancers or reverse proxies) in the server network, or ABAP systems should be configured to directly support HTTPS/SSL servers.

SSL server configuration requires cryptographic keys. Other cryptographic keys are used for creation of SAP logon tickets, SNC, or Web service security. These keys are stored in personal security environment (PSE) files on the server file system in the directory <instance directory>/sec and in the database table SSF_PSE_D.

Access to these keys must be protected. The system security of ABAP systems is highly endangered if unau-thorized access to cryptographic keys is possible. The following security measures should be taken to restrict the access.

PROTECTION OF  CRYPTOGRAPHIC KEYS
Restrict access to the table SSF_PSE_D by assigning the table to a dedicated table authorization group.29 End users should not have access to this new table authorization group. Restrict file system access to PSE files from ABAP programs.30

PROTECTION OF SESSION IDENTIFIERS
Web applications use security session identifiers created after logon to authenticate subsequent access. The identifiers are destroyed after logoff. Session handling must be securely config-ured in order to prevent misuse of security session identifiers.1

Q7. What are some of the ways in which you can manage the security of logical RFC destinations?

Answer;

To securely manage ABAP and logical RFC destinations, three different categories are distinguished:

1. Destinations storing technical connectivity configuration without stored credentials and without trust relationships between the systems. They require user authentication for each access.

2.        Destinations with technical connectivity configuration using stored credentials (such as client, user, and password)

3.        Destinations with technical connectivity configuration using trusted system logon (trusted/trusting RFC)

All three categories of RFC destinations are allowed to be used between systems of the same security classification (that is, from a production system to another production system). They are also allowed from systems of higher security classification to systems of lower security classification (such as from a test system to a development system).

As a general guideline, destinations from systems of lower security classification to systems of higher security classifica-tion are not allowed to store user credentials or to use trusted system logon (for example, from a development system to a production system).

These destinations are only allowed to store technical connectivity configuration and authenticate the user for each access (see Figure 6). One exception to this general guideline is transport management system (TMS) destinations. If these destinations are required, they must be considered security risks and must only be used after thorough risk analysis.

Additionally, systems of higher security classification should be generally forbidden to trust systems of lower security classifi-cation. Otherwise, the security level of the trusting system is reduced to the security level of the trusted system.

Access to trusting systems is further controlled by the authori-zation object S_RFCACL.38 This object must be strictly con-trolled, and full wildcard authorizations should not be granted. Also, the default configuration to leave the authorization object out of the authorization profile SAP_ALL should not be changed (ADD_S_RFCACL=NO in customizing table PRGN_CUST). Particularly in production environments, users stored in RFC destinations should only have the minimum authorization in the destination target that is required for the business scenario executed over that destination. We recommend using dedicated accounts per scenario wherever possible. It is a common misunderstanding to assume that assigning SAP_ALL privileges to users in destinations with stored credentials is secure as long as the user is not of type “DIALOG.”

The following security measures should be taken to mitigate the risk of unauthorized access via RFC destinations:

• Ensure that RFC authority checks are enabled by setting profile parameter auth/rfc_authority_check.39

•Analyze all system trust relationships between ABAP systems using transactions SMT1 and SMT2. Identify the trust relation-ships in which systems of higher security classification trust systems of lower security classification (development to test, test to production, or development to production). Remove this system trust wherever possible.

•Identify RFC destinations with stored user credentials from systems of lower security classification to systems of higher security classification. The stored credentials should be removed wherever possible. This way, user authentication is enforced for every access.

• Create a list of RFC destinations with stored credentials, and ensure that user accounts have minimum authorizations (especially not SAP_ALL) assigned in the destination target.

More Interview Questions? Have a look at:

105 SAP Security Interview Questions with Answers & Explanations – eBook