1 2 3 9 Previous Next


132 Posts

In our previous [1] article we’ve already introduced you to the list of the 9 most important business application security critical issues. We’ve also had a chance to present to you the skeleton of our guideline with its 33 security assessment steps. As you’ve seen only the skeleton of it, now it’s high time to pay attention to a more detailed explanation of each step to be taken.

In order to insure full-scale system security it is crucial to regularly install security support packages. The number of support packages necessary for a system may be huge. Supporting this idea is the fact that the number of SAP Security Notes grew up to more than 3000 by the mid-2014. As some of you may know, each Sap Security Note serves to fix one or more vulnerability. About 50 Security Notes are issued monthly. Sometimes one can even find a SAP Security Note that was made based on the results of a third-party researcher’s work [2]. Also, when it comes to prompt vulnerability elimination we should take into consideration all the possible consequences implementation of such utilities as Metasploit to get free access to corporate information can lead to. Given the above arguments, it is reasonable to conclude that to develop and establish a patch management process that would ensure the implementation of adequate preventive measures against potential threats is highly necessary at this stage. Let us now focus on the two major checks that must be in place to address the most critical problems.

Further Steps.

To verify security of SAP components, particularly those of them that are installed separately from the application server you can use such services as SAP Router, SAP Webdispatcher, SAP GUI. Additionally, it’s convenient to use those systems that are linked to the NetWeaver ABAP application server, but operate on the basis of the NetWeaver J2EE or SAP BusinessObjects application servers. Their security is regulated by a separate document included in the EAS-SEC. It’s substantial that, a security patch should be checked for operating systems where SAP services are installed, as well as for DBMS that store SAP solution data.

[EASAI-NA-01] Check for components update (SAP Security Notes)


The essence of the whole patching procedure is that a patch is designed to substitute outdated and vulnerable objects. There are two ways to fix a vulnerability: one can either implement the correction instructions from an SAP Security Note in the system, or have a Support Package installed. As a rule, initially a particular SAP Security Note (with appropriate correction instructions) is issued. After that, a Support Package is applied. The Support Package usually contains changed or new functionality with a set of correction instructions for a certain period of time.
As mentioned above, the number of support packages and SAP Security Notes required by the system may be huge. That's why the development of patch management process should also involve establishing a priority of patch installation. While determining the right priority one should consider the following factors:

  • Threat severity,
  • Threat probability,

  • Required system privileges,

  • Complexity of exploitation, and
  • Public exploit availability.


WARNING! Sometimes vulnerability management processes can mix up. That is to say, vulnerabilities may be fixed with either a support package, or with the help of the SAP Security Notes. The matter is, they won’t synchronize. For instance, a vulnerability fixed with a support package would not be implemented as fixed via the SNOTE transaction to the SAP Security Notes list.


As soon as there appears a new security patch, newly identified vulnerabilities rather quickly become publicly available. To put it another way, anyone can gain access to their description. Accordingly, in case security patch was implemented after a long period of time it gives an adversary a chance to exploit those vulnerabilities, to get an unauthorized access to sensitive business data.


It is imperative to perform regular checks for security patches updates. To do that, one should strictly follow main patch management process steps (data collection, risk assessment, implementing security patch software, result monitoring).
 Using SAP Patch Manager (SPAM) offered by the SAP one can download and implement required support packages from the Online Server System (OSS). Note that this is only related to versions 3.0 and higher. In order to start the SPAM, you should enter the command “SPAM” in the transaction code field.

Also, it’s possible to use the multi-purpose SAP Software Update Manager (SUM) to implement various system updates. The good news is that a demo version of this product is publicly available at the time [3]

To implement SAP Security Notes, use the SNOTE transaction to get a list of security notes required for a particular system. As mentioned above, these two mechanisms are not synchronized, so it is preferable to make some changes manually or with some additional third-party tools.

Before proceeding to our next security check let us make a small digression. The thing is we’ve decided to be proactive in terms of information security, thus in addition to major all-purpose checks, each item of our guideline contains a subsection called "Further steps". This subsection gives major instructions on how to further securely configure each particular item.

[EASAI-NA-02] Check for kernel updates


We should keep in mind that in SAP system kernel there are executable files containing SAP Dispatcher, SAP Gateway, SAP Message Server, SAP Router and some other SAP services. For that reason, SAP system kernel has its own update mechanism that is different from other components. Kernel updates are released as service packs for a specific kernel type.

So as to clarify, support packages are cumulative. Therefore they include all the previous updates, even though sometimes releases contain updates for a certain support package only.


As soon as there appears a new security patch, newly identified vulnerabilities rather quickly become publicly available. To put it another way, anyone can gain access to their description. Accordingly, in case security patch was implemented after a long period of time it gives an adversary a chance to exploit those vulnerabilities, to get an unauthorized access to sensitive business data.

Kernel updates mostly fix highly critical vulnerabilities, as any system has a kernel. So, it’s crucial that kernel update should have highest priority and should be installed before other components.


It is imperative to perform regular checks for security patches updates. To do that one should strictly follow main patch management process steps (data collection, risk assessment, implementing security patch software, result monitoring).

In case you want to check out the current version of a service pack using SAP GUI you need to open the Status window in System tab and click on the Other kernel info button (Shift+F5 by default). There is always some information on the latest service pack version published on the SAP support portal[4]

The SAP Security Note is usually downloaded as a system and executable files directory that replaces the previous files. Software Update Manager (SUM) utility is also available to facilitate the manual process a lot (ref. to the operating manual [5]).

That’s it for today’s article, we’ve checked out the first critical issue “patch management flows” and the two steps relating to it. We hope you like our work and share our urge to promote information security to a higher level.

With this article we are starting a new series of guidelines describing some basic assessment procedures one can carry out on various business applications that would help security professionals to expand their ERP systems’ immunity to attacks.


As we all know, ERP systems such as SAP may favour the quality of management of all the information and resources involved in a company's operations.


However, while ERP applications promote the way business processes are organized, they also may undermine information security within organizations.

We should not forget how important it is to secure enterprise applications and various ERP systems.


No need to say, that the ERP system is in the core of any large company: it deals with all processes critical for business – purchases, payments, logistics, HR, product management, financial planning etc.  All information stored in the ERP systems is sensitive, and any unauthorized access to this information can cause huge damages up to a business interruption.


According to the report[1] by the Association of Certified Fraud Examiners (ACFE), in 2006 - 2010, the organizations losses caused by the internal fraud (the IT-frauds) amounted to app. 7% of annual revenue [2].


For the last five years, a widespread myth that the ERP security is only a SOD matrix was over, and today this belief seems to become a history for many people. For that time, the SAP security experts have presented lots of detailed reports on various attacks on the internal SAP subsystems:

     — the RFC protocol,

     — the SAP ROUTER access control system,
     — the SAP web-applications, 
     — the SAP GUI client workstations, and many others.


The interest for this area grows exponentially every year: compared to only 1 report on SAP Security [3] in 2006, more than 30 of such reports were presented in 2013 at specialized hacking and security technical conferences. Lately, a number of hacking utilities were released, and thus confirmed the possibility of attacks on the SAP solutions.


According to the business application vulnerability statistics [4] and [5], more than one hundred vulnerabilities in the SAP products were fixed in 2009, while this figure was more than 500 in 2010. In July 2014, there were more than 3000 SAP Security Notes, i.e. notifications on various SAP components vulnerabilities.

This entry will help you to get extended info about what is going to come next. And why it is so important to know everything about it.

General information

"The Enterprise Application System Vulnerability Assessment Guide" describes 9 most known business application security areas relating to implementation and operation. This top list was prepared by the authors during vulnerability assessments of multiple business applications; this list may be applied to any of them. These areas are weighty factors for many emerging threats and related attacks. Securing of these areas means getting ready to prevent numerous attacks targeted at business application security.


This series of posts contains a detailed analysis of the most widespread business application platform - the SAP NetWeaver ABAP. During this analysis 33 key settings were identified and distributed between 9 areas mentioned above. This post will  show how to protect against the most widespread vulnerabilities in this area as well as provide further steps on securing all 9 areas  .

The top-9 critical areas for business applications


Below, you can find the list of Top-9 critical areas for vulnerability assessment of business application. They are ranked from 1 to 9 according to their severity and impact on the ERP system, business applications and related security. For this list, 3 main parameters were considered:


     1. initial access to exploit the vulnerability;
     2. severity of vulnerability (a potential impact if exploited);
     3. complexity of vulnerability exploitation.


This list is the same for all the business applications. In the next chapters, checks for each of these items (specific to the SAP NetWeaver ABAP platform) are described in detail. However, these descriptions are stated in a way to ensure understanding of the basic principles relating to vulnerability assessment for any enterprise application systems.


    Critical areaAccessSeverity  Simplicity
1. Patch management flawsAnonymousHighHigh
2. Default passwords for access to the applicationAnonymousHighHigh
3.Unnecessary functionalityAnonymousHighHigh
4. Open remote management interfacesAnonymousHighMedium
5. Insecure settingsAnonymousMediumMedium
6. Unencrypted connectionsAnonymousMediumMedium
7. Access control and SOD conflictsUserHighMedium
8. Insecure trusted connectionsUserHighHigh
9. Security events loggingAdministratorHighMedium


The Guide description

Our approach contains 33 steps to securely configure SAP NetWeaver ABAP platform, that were distributed among 9 areas mentioned above.

The authors' efforts were to make this list as brief as possible but also to cover the most critical threats for each area. This approach is the main objective of this Guide: as despite best practices by the SAP, ISACA and DSAG, our intention was not to create just another list of issues with no explanation on why a particular issue was (not) included in the final list, but to prepare a document that may be easily used not only by SAP security experts. Report should also provide comprehensive coverage of all critical areas of SAP Security.


At the same time, the development of the most complete guide would be a never-ending story as at the time of writing there were more than 7000 checks of security configuration settings for the SAP platform as such, without those of specific role-based access and in-house applications.


As a result, each of the 9 areas includes major checks that must be implemented first and can be applied to any system regardless of its settings and custom  parameters. It also important that these checks are equally applicable both to production systems and those of testing and development.


In addition to major all-purpose checks, each item contains a subsection called "Further steps". This subsection gives major guidelines and instructions on what should be done in the second and third place, and then how to further securely configure each particular item. The recommended guidelines are not always mandatory and sometimes depend on a specific SAP solution. On the one hand, with this approach, the authors were able to highlight key security parameters for a quick assessment of any SAP solution (from the ERP to the Solution Manager or Industry Solution) based on the NetWeaver ABAP platform and, on the other hand, to cover all issues and give complete recommendations on them.


In terms of quality, this makes the present Guide different from the SAP best practices that also contain few items, but do not cover the overall picture, as well as from best practices by ISACA and DSAG that have a lot of items, but the priorities are unclear and too complicated for the first step (though these papers are highly valuable and necessary).


33 steps to security

So, here it is. Our list of most critical checks for SAP NetWeaver ABAP - based systems

1. Patch management flaws
[EASAI-NA-01] Check for components update (SAP Security Notes)
[EASAI-NA-02] Check for kernel updates

2. Default passwords for access to the application
[EASAI-NA-03] Default password check for a SAP* user
[EASAI-NA-04] Default password check for the DDIC user
[EASAI-NA-05] Default password check for the SAPCPIC user
[EASAI-NA-06] Default password check for the TMSADM user
[EASAI-NA-07] Default password check for the EARLYWATCH user

3. Unnecessary functionality
[EASAI-NA-08] Access to the RFC-function via the SOAP interface
[EASAI-NA-09] Access to the RFC-function via the form interface
[EASAI-NA-10] Access to the Exchange Infrastructure (XI) via the SOAP interface

4. Open remote management interfaces
[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions
[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions
[EASAI-NA-13] Unauthorized access to the Message Server service functions
[EASAI-NA-14] Unauthorized access to the Oracle DBMS

5. Insecure settings
[EASAI-NA-15] Minimal password length
[EASAI-NA-16] Number of invalid logon attempts before the user account lock out
[EASAI-NA-17] Password compliance with the security policies in place
[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat)
[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)

6. Access control and SOD conflicts
[EASAI-NA-20] The check for SAP_ALL profile accounts
[EASAI-NA-21] The check for accounts that may start any programs
[EASAI-NA-22] The check for accounts that may modify USH02 table
[EASAI-NA-23] The check for accounts that may execute OS commands
[EASAI-NA-24] Check for disabled authorizations

7. Unencrypted connections
[EASAI-NA-25] The SSL encryption to protect HTTP connections
[EASAI-NA-26] The SNC encryption  to protect the SAP GUI client connections
[EASAI-NA-27] The SNC encryption  to protect RFC connections between systems

8. Insecure trusted connections
[EASAI-NA-28] RFC connections that store user authentication data
[EASAI-NA-29] Trusted systems with low security level

9. Logging of security events
[EASAI-NA-30] Logging of security events
[EASAI-NA-31] Logging of HTTP requests
[EASAI-NA-32] Logging of table changes
[EASAI-NA-33] Logging of SAP Gateway activities


As you can see – the guide is not as enormous as it could have been due to the complicity of the topic. We tried to maximize the clarity of the guide to security assessments for you.


Stay in touch with us as next week we’ll come back with the new article where the guideline will reappear in its all glory. We’ll provide you with detailed explanation of each step.

SAP has released the monthly critical patch update for April 2015. This patch update closes a lot of vulnerabilities in SAP products. Most of them are potential information disclosure vulnerabilities.


The most critical issues found by other researchers

Some of our readers and clients asked us to categorize the most critical issues to patch them first. So, the most critical issues of this update can be patched by the following SAP Notes:

2067830: SAP Web Dynpro Java has an Implementation Flaw (CVSS Base Score: 5.8). An attacker can upload a malicious file to a system when the virus scanner is not configured correctly. It is recommended to install this SAP Security Note to prevent risks.

2094830: SAP Sybase Unwired Platform Online Data Proxy has an Information Disclosure vulnerablity (CVSS Base Score: 4.7). An attacker can use Information Disclosure to learn additional information (system data, debugging information, etc.) which will help them plan other attacks. It is recommended to install this SAP Security Note to prevent risks.

2084037: SAP NetWeaver RFC SDK has an Information Disclosure vulnerability (CVSS Base Score: 4.3). An attacker can use Information Disclosure to learn additional information (system data, debugging information, etc.) which will help them plan other attacks. It is recommended to install this SAP Security Note to prevent risks.

Visit us in Orlando and learn about SAP's security offerings and strategy.



We'll be there with a booth as well as a number of lectures, demos, and discussion forums around various

security features.


One of the focus topics this year is preventing cyber attacks: Come to one of our demos to see how our new SAP Enterprise Threat Detection product can help you safeguard your organization. Compliant identity and access management is on the agenda as well as an overview of our current security functionality, cloud security, best practices, and an outlook into planned enhancements in a roadmap session.

Presenters range from SAP experts to savvy customers and partners providing an insight into their implementations.


Sapphire Now and the ASUG Conference run from May 5-7 in the Orange County Convention Center in Orlando, Florida.


We look forward to seeing you there!

To register, stay informed, and build your agenda, visit http://events.sap.com/sapandasug/en/home

April 17, 2015 – As a part of monthly updates Microsoft released security update MS15-034 which closes vulnerability in driver HTTP.sys which enables an attacker to execute arbitrary code on OS remotely.

This update has a critical status as almost every modern version of Microsoft operating systems (Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2) is vulnerable.

We think it is necessary to report about this kind of vulnerabilities due to the fact that a part of SAP products uses web server IIS for their work and as a result is also vulnerable to this issue.

At the least the following components and SAP modules could be threatened:

  • SAP Afaria
  • SAP Content Server
  • SAP DB Web Tools.


To compromise a system an attacker just have to send a specially generated HTTP-request to a vulnerable server.

The vulnerability is an improper processing of HTTP header "Range" in function HTTP! UlpParseRange. It allows an attacker to use the vulnerability of an integer overflow to execute arbitrary code in the OS.

To secure your systems you must install Microsoft security update.

To check whether your systems are vulnerable, you can use the following script.

As our mission is to close the gap between technical and business security, we constantly monitor the important news about the security of business applications so that our customers are always warned about the latest facts in this sphere.

Mobile devices are actively integrated into business processes. Companies have more and more business applications and mobile devices. Employees increasingly bring their own equipment to the workplace (BYOD policy – Bring Your Own Device) and gain access to critical corporate information.

SAP Mobile Platform (or SMP, formerly called Sybase Unwired Platform, or SUP) is a MEAP (Mobile Enterprise Application Platform) solution. SMP is used for monitoring and controlling applications which are installed on mobile phones and have access to business data. The main goal of SMP is providing business data to mobile devices with enterprise security. Platform capabilities allow users to work with data from SAP business applications using mobile applications both online and offline. This data can be accessed through all modern mobile devices. Android, Blackberry, iPhone / iPad and Windows / Windows Mobile devices are used by end users. Installed client applications are connected to SMP. These programs can be found on Play Market, Apple Store, or Windows Store.

SMP security service supports secure connections using SSL between app and server. Data on the device or in-transit can be encrypted using user supplied key. It supports authentication, authorization, access control to various apps and roles, single-sign-on, security audit logging etc. to provide an end to end security from device to the platform.

In order to further secure the access, Mobile Device Management software should be used. All of the security functionality from device to SMP such as SSL, authentication, authorization, and single-sign-on are provided along with the device management, app configurations, and device data security. SMP works with any MDM provider besides Afaria/Mobile Secure for mobile device management.

SMP is also a platform for development. This platform includes tools for rapid development of client applications for various platforms and much more, but let’s focus on risks first.

Risks associated with attacks on SAP Mobile Technology

Risks related to business applications usually include espionage, sabotage, and fraud. Some of the potential risks for SAP Mobile Platform if somebody finds vulnerabilities in this platform and exploits them are provided below:

  • (ESPIONAGE/FRAUD). Unauthorized Access to business applications, such as ERP, CRM, BI, by hacking SAP Mobile platform. SMP can be considered a “proxy” for access to business systems. Usually, mobile devices and mobile applications, especially from 3rd parties, are for security reasons not allowed to connect directly to ERP but use SMP instead. If a cybercriminal is able to get access to SMP, they will be able to get almost direct access to mission-critical systems inside the company, such as ERP, SCM, BI, and others.
  • (ESPIONAGE). Access to critical data stored on mobile devices, such as personal data (SSN), personal healthcare data (PHI), credit card data (PCI). Unauthorized access to this data can turn into a data breach if somebody exploits this vulnerability against multiple mobile devices, or into a targeted attack against high-level executives from commerce, government, or military.
  • (SABOTAGE/FRAUD). Modification of critical data stored or presented on mobile devices. Some vulnerabilities may allow changing critical data stored on a mobile device, or show fake data by means of a Man-in-the-Middle attack. Imagine what will happen if a nurse sees the wrong results, executives get modified information about financial results from a BI system, warehouse logistics employees will be informed about the lack of goods in stock, and many other examples.
  • (SABOTAGE). Denial of Service attacks on SAP Mobile Infrastructure. Imagine that nobody will be able to connect to the latest business data via a mobile device. This risk is especially critical due to the reason that mobile access is mostly used by C-level executives to analyze the latest dashboards. Also, mobile devices can be used in a warehouse, so the entire supply chain can be deactivated with a simple DoS attack.


Vulnerabilities identified by ERPScan researchers:Now let’s see how real the listed risks are and if there are vulnerabilities which can be exploited to prove that those risks exist. We found multiple vulnerabilities in SAP Mobile Technology including SAP Mobile Platform, SAP Mobile Applications, and SAP Afaria MDM. We will now show 4 of them, which were recently patched by SAP. Each of them is associated with a particular risk described in the previous section. The first two vulnerabilities are server-side and the last two are client-side.

  • Sabotage attack example. SAP Mobile Platform uses Sybase SQL Anywhere as the database. An attacker can use a special request to crash the Sybase SQL Anywhere database server resulting in a denial of service.
    Vulnerability reported: 09.12.2014
    Vendor response: 10.12.2014
    Date of Public Advisory: 15.03.2015
    Defense: SAP Note 2108161
  • Vulnerability in SAP Mobile Platform Portal page. An XXE (XML External Entity) vulnerability allows multiple attack vectors. First of all, XXE can be used for a Denial of Service attack on Portal, which would make impossible all interactions between mobile devices and ERP system or any other mission-critical application. Secondly, it is possible to get access to the file system and potentially get full control over the server. Sometimes, access to business systems is provided to 3rd parties or subcontractors only via SAP Mobile, so they can use this XXE vulnerability to obtain broader and direct access to ERPs or other mission-critical systems. Then they may proceed to espionage, sabotage, and fraud attacks against SAP ERP using vulnerabilities in SAP ERP, and there are plenty of them there according to our report.
    Vulnerability reported: 29.12.2014
    Vendor response: 30.12.2014
    Date of Public Advisory: 15.03.2015
    Defense: SAP Note 2125513
  • Espionage attack example. Critical healthcare information disclosures in the SAP EMR Unwired application for Android. Google store indicates that the number of installations is 1000-5000. SAP EMR Unwired allows doctors and nurses to get up-to-date information of all patients, including findings and charts, view X-ray and CT images (non-diagnostic quality images), clinical orders, risk factors, demographics, lab results, patients’ latest vital signs, progress notes, DRG, diagnoses, procedure codes, etc. The app connects to clinical back-end systems, including hospital information and imaging systems (PACS), and displays the patient’s data in a clear and easy-to-read format on the Android device (information from the app description in Android store). An unauthorized access vulnerability in the mobile application allows attackers to get access to short-lived temporary documents. To exploit this kind of vulnerability, you need to upload a malicious app to the victim’s phone. Normally, you can’t get access to an application from another one without a local privilege escalation exploit.
    Vulnerability reported: 20.04.2013
    Vendor response: 21.04.2013
    Date of Public Advisory: 16.11.2013
    Defense: SAP Note 1864518
  • Sabotage/Espionage. Vulnerability in the SAP EMR Unwired application for Android. It is possible to reconfigure this application so that it will connect to a malicious server. The threat exists only if the user confirms the settings changes, but the attacker can show this confirmation window infinitely until they click OK. Thus, it will be possible to send fake medical data into the mobile application so nurses will receive wrong information about the patient’s health and assign the wrong course of treatment. This can lead to unpredictable damage for patients.
    Vulnerability reported: 20.04.2013
    Vendor response: 21.04.2013
    Date of Public Advisory: 15.02.2015
    Defense: SAP Note 2117079

What's New?


We have just finished recording a number of video tutorials for the SAP HANA Academy on SAP Cloud Identity service, a cloud solution for identity lifecycle management for SAP HANA Cloud Platform applications and optionally for on-premise applications.

Complete playlist: SAP Cloud Identity - YouTube

SAP Cloud Identity provides a number of security related services:

  • authentication
  • single sign-on
  • on-premise integration
  • self-services such as registration or password reset

Target use-case scenarios for SAP Cloud Identity services are:

  • employees (B2E)
  • customer partners (B2B)
  • consumers (B2C)


For features and functions, see the SAP Cloud Identity service release note: SAP Cloud Identity Service.


For more information about SAP Cloud Identity service, see




In the first video, we provide a brief introduction to the SAP Cloud Identity services.



Operations: Administration Console


The next video provides an overview of the Administration Console



Operations: SAML Trust


The next video shows how to configure SAML trust between service provider and identity provider.



Operations: Configure Forms


The next video shows to configure forms for registration and upgrade.



Operations: Password Policy


The next video shows how to configure a password policy.



Operations: Terms of Use and Privacy Policy


The next video discusses how to configure a custom Terms of Use document and Privacy Policy document.



Operations: Branding


The next video shows discusses how to configure application branding.



Operations: Social Sign-On


The next video shows discusses how to configure social sign-on.



Thank you for watching


You can view more free online videos and hands-on use cases to help you answer the What, How and Why questions about SAP HANA and the SAP HANA Cloud Platform on the SAP HANA Academy at youtube.com/saphanaacademy, follow us on Twitter @saphanaacademy., or connect to us on LinkedIn.

With SAP NetWeaver Application Server ABAP 7.40 SP8 it is possible to activate an encrypted and authenticated communication between the SAP Netweaver AS ABAP server components. This security measure is very easy to configure and allows to replace ACLs that have been used so far to secure the communication between server components.  (For the ACL configuration see for example the SAP Help Doku . This will not be explained in this blog.)

IMPORTANT: The functionality is currently in a pilot phase. Interested customers should check SAP Note 2040644 for current limitations.

Use Cases

There exist several options to secure the communication between the ABAP server components. one possibility is to secure the network segment where the server components reside to ensure that they can not be reached from outside the segment. It is still possible to use the ACLs .

The new option allows to encrypt and authenticate the traffic between the system components with SSL.

How it works

During the first system restart after the activation of the secure server communication, the SAP Start Service sets up a certificate infrastructure (a system internal PKI). All instances of the SAP NetWeaver AS for ABAP server are integrated into the PKI and receive an instance specific certificate with private key that they can use to authenticate and to encrypt their system internal communication with other system instances.

  • The certificates are automatically renewed.
  • The root PSE file is stored in the secure store of the file system.
  • All other instance PSE files are encrypted with a PIN that is stored in the secure store of the file system as well.

After the setup of the PKI, all communication between system instances uses SSL for encryption and authentication.


Keep in Mind: This encryption is only active for the system internal communication . All external communication for example RFC communication with external RFC server is NOT encrypted unless it is done separately via SNC or SSL. The trust of the system PKI can only be used internally in the system.


Overview: Secured connections between application server components with activated secure server Communication



  • The "red" connections that are encrypted via Secure Server Communication and the internal PKI
  • The "green" connections are external HTTP communications that can be secured using SSL
  • The "blue" connections are external RFC communications that can be secured using SNC
  • The "black" connections are connections to the Message Server. They are used top gather the list of application servers.
  • The "violet" connections are local host internal
  • The "yellow" internal ICM communication can be secured as described in the SAP Help Documentation.

  • The connections that are described with a circle (ICM and GW) are internal RFC or HTTP communications between these components.


Limitations and Possible Incompatibilities

  • The usage of SSL results in a higher CPU consumption and a modest performance impact (~1%)
  • For ABAP servers with a high load of internal RFC communication the performance impact can be higher.
  • If customer components addressed a server component via an internal port this is no longer possible as external components cannot be  part of the internal PKI infrastructure.  External components now necessarily need to communicate over the external ports. All external SAP components use the external ports as well for example GWMON MSMON DPMON or LGTST.
  • For the SAP tool SAPEVT please check SAP Note 2000417


  1. Stop all instances of the system (including e.g. ASCS, ERS) by using e.g. SAP MMC:  "Stop..." context menu on the system node or Command line tool: "sapcontrol ... -function StopSystem".

  2. Add the following profile parameter to the default profile DEFAULT.PFL of the system: system/secure_communication = ON

    It is also possible to use the value "BEST" instead of "ON" . If best is used and for some reason a server component is unable to communicate via SSL an unencrypted communication is possible as a fallback mechanism without an error. All other communications remain encrypted via SSL.

  3. Restart of Start Services of all instancesof the system by using e.g. SAP MMC: "All Tasks->Restart Service" context menu for each instance

    Command line tool: "sapcontrol ... -function RestartServices".

  4. Start the system using e.g. SAP MMC: "Start..." context menu on the system node or Command line tool: "sapcontrol ... -function StartSystem".

  5. Verify that all instances are displayed "green" in SAP MMC or "sapcontrol ... -function GetSystemInstanceList".


In transaction SM51 you will see that SSL is now used:




See also the  SAP Help Documentation.




IMPORTANT: The parameter system/secure_communication can be safely switched back to the OFF position without harming the system.


Using the command line tool "sapcontrol"


Checking the system status with "sapcontrol"

It is possible to check the usability of the System PKI with "sapcontrol" (without changing anything in the system). To do this use:

      sapcontrol -nr <NR> -systempki <Profile> [-host <HOST>] [-debug] -function AccessCheck Stop



  • Result: You should get an "AccessCheck OK" if no error is found.
  • The parameter <Profile> needs to contain the profile of a local instance.
  • With the parameters "-nr" and "-host" the connection to all system instances using the system PKI can be tested.
  • The parameter "-debug" allows to trace the SSL handshake


Reset the System PKI with "sapcontrol"


In general it should not be necessary to reset the PKI as the whole certificate lifecycle is triggered automatically. If ever you want to enforce it there exist 2 web service methods in the "sapcontrol" which are also used by the system internally to maintain the PKI:

  • UpdateSystemPKI[<force>]       "Updates the whole system PKI
  • UpdateInstancePSE[<force>]     "Updates an instance PSE

If the parameter force=0 (default value) the update is only done when considered necessary by the system with force=1 the update is enforced.


ABAP check reports


To check the internal PKI some ABAP check reports exist that can be executed in SE38 . They should not show any error messages:

  • SSFPKITEST1      Checks the system PKI (root and instance PSE)
  • SSFPKITEST2      Checks a remote application server of the system
  • SSFPKITEST3      Shows the certificate and the certificate list of the application server


Useful information for SAP Support


If you need help from SAP Support the following information is helpful to analyze problems with the System PKI :

  • Secure store files in $(rec/ssfs_datapath)
  • If available secure store key files in $(rec/ssfs_keypath)
  • The Instance PSEs of all instances: $(DIR_INSTANCE)/sec/sap_system_pki_instance.pse

On 16th March, SAP Enterprise Threat Detection 1.0 exited ramp-up and became generally available. This coincided with the availability of SP01, which incorporate many lessons learned during the ramp-up phase, and I would recommend going straight to SP01 if you are starting a new project.  The Implementation Guide and the Operations Guide have been updated with the latest developments.


So what’s new with SP01?

In SP00, the focus was on monitoring of ABAP systems. This remains the case for SP01 with over 50 ABAP-based patterns and the addition of the change document log. However, the first steps were made in expanding the out-of-the-box support for other SAP platforms with the addition of the audit trail from SAP HANA and some patterns based on it.






The audit trail on SAP HANA can be written to the logging system of the operating system (syslog), which is easily configured to transmit using UDP. SAP Enterprise Threat Detection receives the messages, and the incoming events are normalized using the built-in audit trail rules of the new log adapter. Looking forward, this log adapter will also be an important way of integrating non-SAP systems and devices, as it is intended for text-based logs in general.


Relevant SAP Notes

2137018 - Compatibility information for SAP Enterprise Threat Detection support packages and SAP HANA revisions
2128060 - Release Note SAP Enterprise Threat Detection 1.0 SP01 (Revision 2)
2133037 - Enhancements ABAP Interface for SAP Enterprise Threat Detection 1.0 SP01
2068112 - Installation Information for SAP Enterprise Threat Detection 1.0

Hi all,


SAP Enterprise Threat Detection and SIEM systems. What is the difference? Here you can find an answer ....


So what is SIEM? SIEM stands for security information and event management. The application is  collecting security event information throughout a IT landscape. SIEM products are already a long time in the market.


A personal note

Some SIEM vendors really missed the opportunity to renew their architecture (security data is a big data issues nowadays which require a change in the architecture and the use of new analytical tools). Some products are distributed across several servers and databases, actual data in one database, historically in another and you have to jump between tools for analysis and reporting. But these are vendor specific issues and not a problem of the SIEM idea and there are also good vendors out there! So watch out if your are selecting a SIEM solution and do not implement yesterdays technology.


So what is difference to SAP Enterprise Threat Detection?

It is the focus of security events types. SIEM solutions traditionally use security events on the network and operation system level to detect attacks. But the most solutions have no idea what happens in the applications,. But nowadays sophisticated attacks cannot be only detected on the lower levels, you have to look into the applications stack! That is the starting point of SAP Enterprise Threat Detection. It collects security information on the application stack and correlated it with context information to detect cyber attacks when it happens. This is only working because we are using the newest technology on the market: SAP HANA as a big data platform in combination with SAP Event Streaming processor.





Just an example. How do you want to find an internal or external who stole some credentials to a SAP system (there are many techniques - this would fill a comlete own blog) and try to steal confidential data with the help of the credentials? It is about the user behaviour in the system in combination with context(region, device, HR information, IP, ...) information --> SAP Enterprise Threat Detection.

Does SAP Enterprise Threat Detection replace existing SIEM solutions?

No, SIEM solution are very good on the operation system and network level. They incorporate the experience of many years. They are complementary to ETD like other security solutions (virus scanner, IPS, IDS, ...). My opinion: There will be not one solution in the market, which can protect everything.


Does SAP Enterprise Threat Detection support also non-SAP data?

Yes, you can  also upload your proxy data (or any other) to analyze it and many other things which your exisitng system is perhaps not able to do because of an outdated technology. But the content (security patterns) delivered by SAP focuses on the SAP application level. By the way, there are many security partners planning to provide additional security patterns.So watch out for partners which not only provide impementation services but also additional content.


Why did SAP not build the ETD solution on existing SIEM solutions?

We would not invested into SAP Enterprise Threat Detection without our SAP HANA technology. SAP HANA allows us to analyze large amouts of data, correlate and visualize it. With the predictive, geospacial, data scaling and other functionalities we are able to provide a complete new experience in the future. Furthermore we do not want to lock-in our customers to one SIEM solution. SAP will rather integrate with leading SIEM solutions to use the strength of both worlds.


So the products is availabe since the end of 2014 and provides already now a great insight. But there is also a roadmap available and SAP will deliver innovations with each service pack.





There is sometimes the question, what the difference is between SAP Fraud Management and SAP Enterprise Threat Detection. I would like to explain the 2 complementary solutions in this short blog.


SAP Fraud Management solution focuses on business process related frauds and SAP Enterprise Threat Detection is about IT threats which imperil companies and society.  Both solutions have the goal to protect a company or organization, but have two different approaches since the origin of fraud and threats are different.







  • Detect frauds and threats when they happened (and not a week later in  a report nobody is interested in)
  • Protect companies and organizations (against threats or frauds)
  • Harnessing the power of in-memory computing (of course with SAP HANA)
  • Support of SAP and non-SAP data (open interfaces)
  • SAP pre-delivered content (so not only a framework)


Summary and examples

So the big difference is the perspectives on security. SAP Enterprise Threat Detection has a technical approach to detect attacks against the business. In case of external attacks, cyber criminals are using existing/unknown software vulnerabilities or spying techniques to get technical access to a system. In most cases the goal is to download sensitive business information. In some cases the goal is also to disrupt the business (example: national interests) or harm the reputations (example: political interests). So the system detects at the end abnormal behaviors of users?


Why is someone accessing my systems who left my company based on the HCM system?

How I detect that someone tries to access my SAP system landscapes with standard users or the most common passwords combination (brute force)?

Why is someone manipulating data within a SAP debug session in a productive system?

Why is someone changing user data in transaction su01 and working not in the related organisation?

Why is someone trying to use different transations then normal and using a device not known?



SAP Fraud Management detects frauds on a process level. Nobody is trying to hack the system. They misuse existing permissions or lacks within the process.


Protect against potential fraud through ad-hoc procurement procedures and supported by clearly communicated policies and ad-hoc internal controls.





You want to enable SAML Single Sign On for SAPGui windows.

You have these components in place: IdP, SAPGui windows, Internet Explorer and SAP NetWeaver AS ABAP 7.02 or higher.


SAPGui does not offer native support for SAML. To make this happen, we combine the legacy support feature of the ABAP SAML service provider with the SAPGui shortcut SSO using the MYSAPSSO2 cookie.




Solution components


  1. Enable SAML authentication on the ABAP system using transaction SAML2 and exchanging the metadata with your IdP.
    The important setting in this case is to set the value of "Legacy Systems Support (Issue Logon Ticket) to "On" in the SAML Local Provider Configuration.

  2. Build a BSP application that will establish the SAML SSO with the IdP. This BSP application takes the cookie from the browser and puts it in a SAPGui shortcut. More information around SAPGui shortcut SSO can be found here Single Sign-On for SAP Shortcuts - User Authentication and Single Sign-On - SAP Library

BSP application:


    • Start page launchGui.htm: grabs the cookie and navigates to the BSP page creating the shortcut file.


(source code attached in launchGui.txt.zip)


    • Page createSapGuiShortcut.htm parses the cookie and creates a SAPGui shortcut file containing the MYSAPSSO2 logon ticket.



(source code attached in createSapGuiShortcut_OnRequest.txt.zip )


Put this BSP application in the "Default Application Path" of the "Assertion Consumer Service" setting of the SAML Service provider.


Now start an IDP initiated request. After successful authentication against the IdP, the BSP application takes the MYSAPSSO2 cookie from the browser session and puts it in the SAP shortcutfile. Opening the SAP shortcut file will initiate a SAP logon ticket SSO to SAPGui. Depending on a registry setting in windows, the user will get a popup to open the shortcut file or start the SAPGui immediately. More details about this setting and how to influence it can be found in this SAP note: http://service.sap.com/sap/support/notes/604324.



User mapping


In a typical scenario, the user names of the ABAP system will not be identical to the ones on the IdP. To facilitate this, you can use the user mapping as described here Mapping SAML Principals to AS ABAP User IDs - User Authentication and Single Sign-On - SAP Library


To enable this mapping, set the "Supported NameID Formats" in the trusted provider in the SAML configuration to "unspecified" and then in the details of "NameID Format" specify the source "Mapping in USREXTID table". Then go to "Name ID Management", select the user you want to map and select the Name ID Format "Unspecified" and add the user there. This will generate an entry in the table VUSREXTID. Alternatively, you can also populate that table directly as described in note http://service.sap.com/sap/support/notes/1362866

Finally! After a very long waiting period SAP has received the FIPS 140-2 certificate for the SAP SSO 2.0 Secure Login Library Crypto Kernel.

You can find further details at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2308. The certificate will be available soon at http://csrc.nist.gov/groups/STM/cmvp/validation.html#05.


Please follow SAP Note http://service.sap.com/sap/support/notes/2117112 to run your SAP SSO 2.0 Secure Login Library Crypo Kernel in FIPS 140-2 mode.


Partner and Customers need an S-User to view the note. You can order the S-User here:



how does the SAP security portfolio in the platform area relates to SAP HANA system. A question which is often asked. So this blog should provide some insight on this question.

In the center should be always the user, who wants to access information via different devices.Users do not take care about the IT landscape.They expect a simple and secure access to the data of the company. But the IT landscape is grown historically and are often very complex.

SAP's strategic platform is SAP HANA. So customers using SAP cloud solutions in the SAP cloud --> SaaS, that are often LoB focused solutions. Furthermore they start to implement SAP Business Suite powered by SAP HANA on-premise or in the SAP managed cloud (SAP HANA Enterprise Cloud). SAP HANA Cloud Platform (SAP HCP) is SAP's Platform as a Service (PaaS) to create customer specific extensions, integration scenarios or new customer applications. Last but not least there are the very important I call them "traditional" systems running on any database and of course also non-SAP applications (see picture below)..



SAP Fiori is SAP's strategic user interface running on any device and simplifies the user interaction. Simple access is provided by SAP Single Sign-On or SAP Cloud Identity. SAP Single Sign-On is optimized for on-premise system landscapes and supports SAP and non-SAP applications via various standards like Kerberos, SPNEGO, X.509 certificates or SAML. The IT department can choose, which technology fit's the best to the existing system landscape and business requirements. SAP Single Sign-On also supports  proprietary SAP clients like SAP GUI.


SAP Cloud Identity is single sign-on as a service based on SAML for web based applications. So why this new solution? Why not use SAP Single Sign-On? If you run a new SAP HCP based application or other cloud based applications - do you then want to install an on-premise solution for single sign-on and open your network for external scenarios? In most cases not. So customer can run SAP Single Sign-On and SAP Cloud Identity integrated but both solution have their strengths: SAP Single Sign-On for the on-premise world and the support of proprietary SAP clients. SAP Cloud Identity for cloud based Web application (see picture below).




Companies are more and more afraid about loosing control about their data especially due the mobile device trends. Here two solution coming into play. It is SAP Mobile Secure, which has the focus on secure development and management of mobile applications/devices. The second one is SAP Mobile Documents which is a solution to manage documents in a secure way (see picture below).




But what about users and permissions? How they can be handled in a compliant and easy way in heterogeneous landscapes? Central user and permission management solves the challenge (see picture below). SAP Identity Management has here a strong user provisioning focus for SAP and non-SAP applications. SAP Access Control provides especially segregation of duties and emergency access capabilities.




But what about the existing ABAP customer code in the on-premise landscape? How to fix all the unknown vulnerabilities ? Secure code is the answer. SAP delivered code is of course already scanned by SAP but ABAP customer code can be checked now with SAP NetWeaver AS, add-on for code vulnerability analysis. And yes, this is really the offical name.




Nobody can ensure 100% security. How to detect now internal and external attacks against a system landscape? SAP Enterprise Threat Detection. This solution collects all the security events throughout the system landscape and detect suspicious activities. SAP Enterprise Threat Detection is a new solution and provides a great roadmap. The solution is not a replacement for existing firewalls, IPS, SIEM or IDS systems. It complements these solutions and provides insight based on security events on the applications layer stack (see picture below).



What you will not find in this blog are all the security functions within the SAP platform (SAP NetWeaver, SAP HANA), also not the security functions within SAP Solution Manager (like SAP System Security Optimization self service)  and the SAP GRC portfolio. So  perhaps this is comming soon ...


Below again my view on the security portfolio - again in contains not everything which is available at SAP.



Hope this is an useful overview about the security portfolio.




With the latest release of the SAP Cloud Identity we offer several new capabilities:

  • extended branding
  • social login
  • responsive user interfaces
  • registration form setup
  • SAML trust configuration improvements.

Extended branding offers a setup of a custom global logo on the SAP Cloud Identity forms for log-on, registration, upgrade, password update, and account activation for all applications in a tenant. With the first SAP Cloud Identity release we already offered a Custom Logo Setup on Application Level.

The custom global logo is used to replace the SAP Cloud Identity product logo, displayed by default on the bottom left side or top left side of the SAP Cloud Identity forms. The custom global logo is different from the logo, used on application level. When a custom global logo is set up for a tenant, it is visible on the logon page together with the logo of the application, see Figure 2 below.

For more details, how to setup a custom global logo on tenant level and also the details about the size and type of the image, see the documentation Configure a Tenant Logo.

Figure 1. Display of the default SCI Log On form:


Figure 2. Display of an SCI Log On form with custom branding, including application logo, custom colors and custom global logo on tenant level:


Social login allows users to link their SAP Cloud Identity service accounts with social network accounts. Social login setup is performed on tenant level and then could be enabled or disabled for a particular application. With the latest release of the SAP Cloud Identity, we offer social login using the following social providers: Twitter, LinkedIn, Facebook and Google.  Social provider buttons are available on the logon page of the cloud application, when the social login option is switched on for this application, see the Figure 3 below.

When a user tries to authenticate via a social identity provider for the first time, he is prompted to allow his SAP Cloud Identity account to be linked with his social network account. After this initial setup, the user can log on to the application using only the social provider authentication.

For more details, see Enable or Disable Social Sign-On for an Application.

Figure 3. Display of an SCI Log On form with custom branding and enabled social login for the application:


Responsive user interface (UI) technology is an approach to UI design for providing optimal viewing experience for wide range of devices and specially mobile phones and tablets. User interfaces, designed using this technology, offer easy reading and navigation with a minimum of re-sizing, scrolling and panning of the pages.

SAP Cloud Identity forms adapt their layout to the viewing environment by using fluid, proportion-based grids, flexible images and other responsive UI technics in order to bring a better user experience for the end users. You can see the effect by comparing the screenshot on Figure 3 with the re-sized view of the SCI Log On form, displayed on a mobile device, on Figure 4.

For more details about the supported browsers, see Supported Browser Versions for User Applications.

Figure 4. Display of an SCI Log On form on a mobile device:


Registration form setup - you can configure which user attributes SAP Cloud Identity service sends to the service provider to be displayed on application's registration and upgrade forms.

After the user has filled in the form, the information from these attributes is recorded in the user's profile. In the registration form setup you specify which personal, company, and contact information the application will prompt the user to provide when registering or upgrading and you also can select if the attribute is required or optional, see Figure 5 below. Two of the attributes “Last Name” and “E-mail” are always required and their settings could not be changed. All attributes set as required are marked with an asterisk on the respective form, see and Figure 6 below.

For more details about the registration and upgrade form setup, see Configure Registration and Upgrade Forms.

Figure 5. SAP Cloud Identity Administration Console: Registration form setup on application level:


Figure 6. Registration form display:


SAML Trust Configuration improvements include several new capabilities:

  • Manual trust configuration of the service provider with respective Endpoit URLs and signing certificate - an alternative way to configure trusted service provider (With the first release we offered configuration of a trusted service provider by importing the service provider metadata *.xml file). For more details, see Configure Trusted Service Provider.
  • SAML Assertion Attributes configuration – you can change the default names of the assertion attributes that the application uses to recognize the user attributes. You can use multiple assertion attributes for the same user attribute. For more details, see Configure the User Attributes Sent to the Application.
  • Constant Attributes configuration – you can set the names and the fixed values of the constant attributes included in the assertion. For more details, see Configure the Constant Attributes Sent to the Application.
  • Automatic trust configuration between a customer SAP HANA Cloud Platform account and an SAP Cloud Identity tenant of the customer. This automatic trust configuration is initiated from the SAP HANA Cloud Platform account and creates a new application on the respective SAP Cloud Identity tenant and sets the trust configuration on both sides – on the Service Provider side (SAP HANA Cloud Platform account) and on the Identity Provider sider (SAP Cloud Identity tenant). For more details, see ID Federation with a SAP Cloud Identity Tenant.


Filter Blog

By author:
By date:
By tag: