1 2 3 15 Previous Next


222 Posts

Hewlett Packard Enterprise (HPE) ArcSight is widely deployed by a lot of customers and is used in Security Operations Centers (SOC). Numerous connectors exist to collect events from networking devices, firewalls, (host) intrusion prevention systems, operating systems, antivirus solutions, webservers, databases, vulnerability scanners and many others.


But the capabilities of SAP monitoring are currently limited. There is only a connector for the security audit file. Information form i.e. the business transaction or the change documents log are missing.


On the other hand SAP Enterprise Threat Detection (ETD) has a very deep view into SAP event sources but has currently very limited capabilities in other areas like networking devices.


Therefore SAP and HPE decided to integrate both solutions to provide holistic monitoring capabilities for the complete IT landscape of an organization including SAP systems.


How the Integration works


Since many companies and organizations already have tied their incident management processes to their ArcSight installation we decided to integrate ETD into ArcSight. By doing so one can see alerts from ETD in ArcSight and can trigger the according response processes.

Information Flow.png

The figure above shows the information flow of SAP events into ArcSight. The events are generated in the SAP landscape and collected by ETD. There they are correlated with other events and context information available in SAP systems. Once something suspicious is detected an alert is generated. An ArcSight FlexConnector collects these alerts via ETD’s REST API and parses them into Common Event Format (CEF), the standard format of ArcSight. The REST API is activated in ETD under Settings as shown in the screenshot below. Further Details can be found in the SAP ETD implementation guide in chapter 8.8.

ETD activate REST.png

The mapping of ETD fields to CEF fields is developed in close cooperation between SAP and HPE so that the semantics are preserved as much as possible. The normalized alerts are then forwarded to ArcSight Enterprise Security Monitor (ESM), which is the central server of an ArcSight installation, where all events are stored and correlated. Finally the ETD alerts are displayed to the security analysts together with all other events form the IT landscape in the ArcSight Console.


By using the ArcSight FlexConnector framework we are very flexible and can quickly adapt to API changes on ETD side.


Demo Setup


The figure below shows the detailed information flow from the source systems via ETD and ArcSight connectors to the ArcSight ESM in our demo setup. Straight lines are currently implemented and dotted lines planned for the near future. DC is the domain controller and EH6 and EC6 are two ABAP systems. More systems will be connected to ETD in the near future which will enable us to see Java logs etc.

demo setup.png

One can see that SAP logs are sent to ETD and only resulting alerts are collected by the FlexConnector. On the other hand Windows event logs and database logs (for example Oracle) are collected directly by ArcSight connectors. Since this is a demo environment we installed all these connectors on the same machine. Also due to the demo environment we do not see any network layer logs. In the mid-term it is planned to install a firewall for the showroom, so that we might get logs from there.


Quite typical is the setup where all connectors are on premise and the ArcSight ESM is installed in one of our Security Operations Center (SOC), where the security analysts monitor all alerts via the ArcSight console as well. Such a presentation is shown in the picture below. It is a dashboard giving an overview of the current security situation in our demo environment.

security dashboard.png

The left side shows the graph view where red squares are sources, white squares are targets and the blue circles are the events or in the case of ETD alerts. An analyst can spot easily highly active users and systems here. For example one can see quickly that the user FF_SAPETD is very active on EC6 with client 020. The main issues is that he uses a lot of monitored transaction. So a further investigation here would be appropriate.


On the upper right corner the number of events is shown by severity for the last few hours. One can see that there were no heavy spikes, so it is either a normal situation or the timeframe is too small to see it as a maximum.


On the lower right corner first the top 10 target systems are shown. EC6/020 is number one here, which corresponds to the findings in the graph view. Second the distribution of the alerts is displayed. More than half of the alerts are due to unauthorized firefighter usage. In a productive environment this could be a hint that there is a problem with the firefighter process.


Use case Examples


Based on the additional information available by the integration of SAP ETD into HPE ArcSight in our current demo environment we developed two exemplary use cases. The first one shows how business related alerts from ETD can help to prioritize an incident response. The second one enables you to detect deviations from the DSAG Prüfleitfaden in nearly real-time. 


Targeted Incident Response


Imagine the following situation: an attacker tricked some of your SAP admin to open a phishing mail containing a Trojan that allows for complete control over the victims PC. Unfortunately one of the admins was logged in at a business critical system. The attacker now uses this session to establish a backdoor in the system by creating a new admin user.

Information Flow hihglevel.png

The figure above shows the data flow during such an attack. The lower part shows the operational layer where the compromised terminal accesses some SAP system. This system reports the activity to ETD which then rises an alert that is forwarded to ArcSight. On the other side the operating system log is sent to ArcSight directly.


From only the OS log (i.e. Windows Event Log) ArcSight can detect that there is a Trojan activity on the system and will rise an alert anyway. But what if there is not only one system compromised but 50? Which one to contain first? With the additional information from ETD a security analyst can see immediately that on one system the infection is actively used to further attack business critical SAP systems. So the decision which one to address first is quite easy now.


For further forensic investigations one can drill down in ArcSight as well as in SAP ETD. The screenshot below shows an active channel in ArcSight where all events from ArcSight connectors and the alerts from ETD are displayed for which the compromised systems was either source or destination.

Arcsight drilldown.png

One can see that the Firefighter user FF_SAPETD performed several actions in the system. To view more details about the activity of that user a drilldown in SAP ETD is the best way. Such a forensic investigation can be seen in this screenshot:

ETD Drilldown.png

So the user performed several actions in the user management transaction (SU01) and some action in the security policy transaction (SECPOL). One would now look into the event details to see what exactly happened in the system EC6.

By using the combination of alerts from ArcSight and ETD we can create less precise patterns in ETD so that we can detect more attacks. For example we could create a pattern that triggers whenever the user management transaction (SU01) is performed. With ETD alone this would lead to a lot of false positives since user management is a normal administrative activity. But in combination with a compromised host it becomes a real threat. So we only rise an alert if user management was performed from a compromised host.


Event Based Compliance Monitoring


For any IT organization audits can be a huge burden. Furthermore they only tell you for a certain point in time that your systems are compliant (and hopefully following form that secure).


Event based compliance monitoring not only can make audits easier but also can show you derivation from a compliant state in nearly real-time. This works as follows: First it must be assured that all systems are in a compliant state. From this point on we can detect changes in the system configuration and can rise an alert which tells in detail which system violates which control. So the responsible admin can be informed and the issue can be resolved very quickly.

We decided to implement the DSAG Prüfleitfaden because it is the commonly used compliance standard for SAP systems. One has to keep in mind that not all controls from the DSAG Prüfleitfaden can be checked on a technical level since they are not of technical but of organizational nature. However, we try to implement as much technical controls as possible.


We discovered that violations of most of the controls can be detected in two ways: Directly by monitoring configuration changes and indirectly by observing activity that should not be possible in a compliant environment.


An example of this may be found in chapter 3.7 of the DSAG Prüfleitfaden the control 1.3 which requires that the user SAP* is created without any rights and locked for all clients. A direct detection of a violation would be a log entry that for example states that SAP* was unlocked. An indirect detection would be if ETD detects activity of SAP* on any productive system.


In an ideal world the direct detection should always be enough, but in reality many things can go wrong. Therefore we decided for this security in depth approach to provide a more robust system. 

The table below shows which part of the DSAG Prüfleitfaden can be monitored by which solution. One can see that SAP ETD and HPE ArcSight are quite complementary.

dsag compliance distribution.png

In the figure below an exemplarily dashboard for DSAG Prüfleitfaden compliance can be found. The most interesting part is the list in the lower right corner. This is the “To Do” list. Every compliance violation will be shown there. Once the issue is resolved the alert can be removed. So an empty list means that the entire SAP landscape is compliant at the moment. And whenever this changes a security analyst will be alerted. This is meant by “real-time compliance”.

compliance dashboard.png




We are just at the beginning of the development of joint use cases for ETD and ArcSight but already this first ideas show the power of the integration between the two solutions. With a larger installation base more use cases will be discovered and made available for all customers.


Another very important benefit of integrating ETD into ArcSight is that SAP monitoring capabilities can be added very easily to an existing SOC may it be customer operated or as a managed service.

Messages from the multiple log sources that feed into SAP Enterprise Threat Detection are normalized, so that you can search across logs. This blog is the first in a series that explains the normalized data model, which consists of semantic events and associated semantic attributes. 


Semantic events and attributes represent which software did what on behalf of which user, etc.  In this blog we concentrate on the software.


Most software usually reports only its own actions, and reports on other software only to the extent that it is involved in the action. In this regard log messages resemble a first-person monologue, e.g., for each blocking action it performs a web filter might say:


"I blocked an HTTP request from an HTTP client to an HTTP server."


In graphic terms, you may want a global view. Maybe you have in mind something like Picture 1.

But, the situation represented in logs has more in common with Picture 2.




Picture 1: An ideal of a global view



Picture 2: Logs mostly give you just a local view


In accordance with this observation about logs, the semantic event model, which is shown in Figure 1, is actor/action centric. A software actor performs some action.  Roles of other software involved in the action are assigned relative to the actor/action, reflecting the local view of the actor.


  • Actor is the software that does the action.
  • Initiator causes the actor to act. This is often the SAP terminal ID.
  • Reporter reports the event. This is often the same as the actor.
  • Target is a system or host that the actor asks to do something, e.g., the target of an RFC call.



Figure 1: Actor/Action Centric Semantic Event Model


Take as an example an RFC call from the SAP system ERP/000 to the SAP system ERP/102 as shown in Figure 2. Both systems send business transaction logs and security audit logs to SAP Enterprise Threat Detection.



Figure 2: SAP system ERP/000 makes an RFC call to ERP/102


The RFC client, ERP/000, performs the action call.

The RFC server, ERP/102 performs the action run.


The respective semantic events from the business transaction log are:

  • Executable, RFC-enabled Function Module, Call  (the client event)
  • Executable, RFC-enabled Function Module, Run  (the server event)


Note that extractors in SAP Enterprise Threat Detection process the logs and create message-type codes that are mapped to the semantic events.


Event names are chosen to create a good sorting order and have 3 main elements: Box, Object, Action

  • A box  groups related events. Examples of boxes are: User Admin, System Admin, Executable, Database, etc.
  • An object is the direct object of the action, e.g., RFC-enabled Function Module.
  • An action is what is done by the actor, e.g., call.


Screen shot 1 shows how the software involved in the event is identified using semantic attributes.

The software type of the actor is identified by the attribute ServiceType. Other types are not explicitly identified, since they usually follow from the actor's type. The system that the software runs on is identified by SystemIdActor. For the call event, this is ERP/000, since it does the call. For the run event, it is ERP/102, since it runs the function module. Notice that the role of the software or host is the last word of the attribute name. You can think of everything in front of the role as being the attribute type, e.g., SystemId.


For the call event, the target of the call is identified by SystemIdTarget, and is ERP/102


For the run event, the initiator of the action is identified by SystemIdInitiator, and is ERP/000




Screen Shot 1: Software Roles for the call and run events (click to view)


There are actually three ways to identify the system or host playing a particular role, where <role> can be one of Actor, Initiator, Target, Reporter, or Intermediary. Intermediary is not used often, so is not explained here.


A system or host can be identified by:

  • The pair SystemType<role>, SystemId<role>.  SystemType is ABAP for an SAP system. It is not shown in the screen shots.
  • The pair NetworkHostname<role>, NetworkHostDomain<role>. These two together are a fully qualified domain name.
  • NetworkIPAddress<role>


Screen shot 2 shows NetworkHostnameInitiator which contains the terminal ID of the terminal that initiated the RFC call.




Screen shot 2: Adds NetworkHostnameInitiator, EventLogType and Security Audit Log Event (click to view)


Screen shot 2 is a different view of the two business transaction events in screen shot 1. It also adds an event from the security audit log. The event source is distinguished by the EventLogType attribute. The security audit log only logs the server side of the call, the run event. On the other hand, it does specify that the run succeeded, whereas the business transaction log does not, since it exists primarily to record performance statistics.


An important point to note is that a message type from the security audit log is mapped to the same semantic event as a message type from the business transaction log, enabling both to be found with a search for one semantic event, thereby achieving the desired capability to search across logs.

Don’t miss the upcoming DSAG webinars about single sign-on, identity management, and other security-related topics. SAP’s security experts from Product Management and Development will be presenting the following sessions:



The webinars will be hosted by the DSAG (German User Group), Working Group “Identity Management & Security”. They will be held in German language. Please note that you need to be a DSAG member in order to be able to register for the webinars.


Mark your calendars and register now.

When activating SAP security logs, the audit event types which must be activated are a topic of much discussion. Often the security/audit teams want to have all event types enabled and BASIS teams are reluctant because of disk space or performance concerns.

This article aims to help you answer the questions “Which SAP security event types should I activate first?” and “How much disk space is required?” using on real data.

In the security audit log configuration transaction (SM19), the system allows you to choose which types of events to log. The “detailed display” section shows the different types available to your system.

Since security audit logs are stored on the file system and not the database, they don’t have a performance impact. The main consideration of the operations teams is the storage requirements. Based on the activated event types (audit classes), data volume may change.


Enterprise Threat Monitor - SAP Security Audit Log Configuration .png

Which event types consume the most disk space? What are the sizing requirements for SAP security logs?

The answer to this question depends on your environment. The easiest way to find out is by activating all event types for a brief amount of time, e.g. one hour (preferably a day), and then analyzing the logs.

For the analysis you can write a small ABAP code which retrieves the logs from all application server instances and then does a group-by and a count on the event-type field. You might need to transport it though.

An easier alternative is using a tool. Enterprise Threat Monitor has a log volume analyzer which can be used for this purpose. It is a Windows application which uses standard SAP RFCs for reading and analyzing the security audit logs remotely.

Analyzing the results: Two real-life productive SAP systems:

When you enter the connection information of your system and run the tool, you’ll get results similar to the following:

Enterprise Threat Monitor - SAP Log Volume Analysis.png

What does this tell us?

In the Log Volume Analysis Results section, you can see the total number of logs for the selected period and monthly estimated log sizes for storing logs, compressed and uncompressed, for each security event type.

The example above is a production ERP system with ~10.000 SAP users. The system has all security audit event types active for all clients and users. In the above case, storing logs for that month is expected to take around 20 gigabytes of disk space uncompressed and around 200MB compressed during this time of the year. 

The following is taken from another SAP system, the production BW which have the same settings applied:

Enterprise Threat Monitor - SAP Log Volume Analysis - BW System.png

On this system monthly estimate is around 14GB uncompressed, 111MB compressed.


If you already have enough disk space for handling this kind of data volume, you should simply activate all of the event types right away. That’s the simplest and best result for security.

For my comments on activating all event types for all clients and users please see the article: SAP Security Audit Logs: Auditor wants me to switch ALL on!!! Here is what I told him

Which event type consumes the most disk space?

There are around 87 event types which you can activate in the advanced view of SM19 (latest systems may have slightly more). The occurrence of each event type in the audit logs is different. Since we are interested in the big fish, we focus on the ones which generate the most events. The following shows the event distribution of the top 3 items:

Enterprise Threat Monitor - Log Distribution.png


For the two production SAP systems in our example, the data shows that 3 event types (successful RFC calls, successful RFC logons and successful start of reports) consume the biggest portion - 97% - of the disk space whereas all other ones in total consume only around 3%. So, all failed and successful logs of the remaining 84 event types (out of 87) only results in 800MB per month for two large PROD systems (uncompressed) or 10MB per month compressed.

This brings us to a very simple conclusion: It is not worth the political fight for discussing the 3% area. On these systems, you should simply activate all log types other than successful RFC calls, RFC logons and report starts as the first step!

When you run the analysis on your system, the results can be slightly different. E.g. if you run a system which utilises web services extensively then you may see that the Successful Web Service Call (CUV) event type generates over 10% of the overall logs. As always, the best assurance is running the analysis on your environment and building your strategy based on your information.

The activation of security logs does not require a restart of the application server, it can be done instantly. This will also make your auditors and security teams pleased without you having to worry about the disk space! I’m sure they come up with a lot of requests from you regarding various security topics. At least now you have one item you can easily tell them “We cover 96% based on recent changes in production” which may help you leveraging your stance in other security topics.

Tell us: How is the log distribution on your systems? Which type of events do you see the most? Simply write your system type (ERP, CRM, etc.), number of users, and the results in the comments (or send me a so others also benefit from your experience.

In my following article, I’ll discuss the next steps, the event types above, and practical attacks which may be missed if these event types are not recorded.


When you build a data center you look for a location in a safe but accessible area.  You don’t typically choose locations next to chemical plants, high crime areas and you don’t advertise with your name on the outside of the building.  Putting “My Fortune 500 Global Data Center Inside” would be easy for your vendors to locate you, but so could anyone else.  Pretty soon the Google map car drives by and captcha codes are updated and now the whole wide web knows your data center location.

So if we protect our data centers from physical threats, why do so many companies not protect their systems from electronic threats? I hear responses like these:

• Security patches require testing and we don’t have time to test them

• Patches fix known issues, but we do not know what else might be impacted

• We had an issue with a security patch in 200x and so we only put them on with support packs

• Our data center is protected from physical threats and  our firewall rules protect us from electronic threats

Anti-Virus software vendors send updates as threats are identified and solutions are developed to protect against them.  On the second Tuesday of each month (and sometimes the fourth Tuesday also) Microsoft releases batches of security corrections.  On Security Patch Day SAP also releases batches of notes that meet specific requirements related to CVSS scores and risk.  As with any other correction they must be categorized correctly in order to be included. 

From a process stand point, having the Microsoft and SAP patches released on the same day is a benefit to companies who are trying to implement a recurring patch process.  So why would you implement Anti-Virus packages and Microsoft patches without reservation, but you go sometimes years without implementing SAP corrections.  This week an SAP correction from 2010 was highlighted in an announcement from the US Department of Homeland Security.  You can find that announcement here: https://www.us-cert.gov/ncas/alerts/TA16-132A.

This announcement identifies a risk which was corrected in October 2010 by SAP, but many companies which are running obsolete versions of NetWeaver never implemented the correction.  If you review electronic data breaches in the US, you will find alarming statistics from sources such as The Identity Theft Resource Center.  This does not include all data breaches but this alone included 378 incidents through 4.5 months of 2016.  Most of these incidents were electronic data breaches.  Whether you have impenetrable firewall rules or not, implementing security corrections needs to be on your best practices.

For several years Frank Buchholz of SAP has provided monthly webcasts to DSAG, ASUG and even Australian user groups.  These webcasts highlight not only the importance of specific notes, he provides steps to analyze what kind of testing is required and informs attendees of changes in the SAP security processes.  One of those included information that the RSECNOTE tool was obsolete and what you should be doing now. 

Even with this additional communication from SAP, there are at least 36 known organizations with this vulnerability.  However, the actual number is more likely much higher than this.  If you are on NetWeaver 7.4 or 7.5 for all of your SAP landscapes then you know that you are not one of them.  But what if you have a landscape running SAP NetWeaver, releases: 2004, 7.0, 7.1, 7.2 or 7.3?  Do you have the Invoker Servlet disabled?  If you have any of these releases within your environment, I would strongly encourage you to initially take action by disabling the Invoker Servlet, but as a second step you really need a periodic patch process.  Maybe you cannot implement support packs, but applying security notes has to be on your radar.  Many of the companies that have an electronic data breach think their firewall rules are rock solid.  They never thought they would be in one of these reports.

I attempted to attach the .pdf from the note as an attachment but it is not allowed.  I strongly encourage you to review the alert and the notes attachment.  The link below to the identity Theft Breach report shows that cyber crime is a big issue.  We have to do what we can to protect data.  The loss of data whether intentional or accidental can cause great harm to your companies’ image.  The time to protect it is always before it occurs.  A firewall alone is not enough protection when more applications or connected to networks which are exposed to the Internet.



What is your excuse for not learning more about security patching or even applying them?


SAP runs enterprises; any impact to an SAP system could put a halt to business operations and cause downtime to enterprises. Unfortunately, for this very reason attackers target SAP systems; from a business perspective, SAP is the critical infrastructure and the lifeline to the ability to provide goods and services to their customers. By taking down SAP systems, businesses can come to a standstill. At the very least, SAP systems hold critical information and in this day and age, when data is more valuable than gold, everyone from insiders to consultants is accessing sensitive information and with motivations from corporate espionage to terrorism, your systems are at risk.


There have been public references to corporate espionage, targeted attacks and possible state sponsored attacks targeting SAP systems and the critical information these systems hold. The only way to track these targeted attacks is through forensic evidence such as logs – including firewall logs, security event logs, and SAP application trace logs. Often these threats sit dormant, leveraging backdoors and unpatched vulnerabilities to take hold of a system and gather data, and then exfiltrating this sensitive information back to the attackers, often encrypting the evidence to go undetected, and sweeping away the evidence when the task is complete.



Why run both solutions integrated?

SAP Enterprise Threat Detection has a strong focus on protecting the SAP business landscape by analyzing security information on the application level and enriching it with context data. So the solution can detect direct attacks against systems or can analyze the impact of a known attack. But sometimes the SAP system is the target, but was not compromised. In these cases the end user devices are compromised and the hacker may get access to a SAP system with the user’s stolen identity. The kinds of attacks targeting an end user device can be detected with FireEye through monitoring the suspicious activities (network, mail, files …). So would it not make sense that FireEye would send that information to SAP Enterprise Threat Detection, to find out if the hacker already accessed confidential information? Yes, it would and that is what the blog is about.


But why  integrate both solutions if the attack can be detected before the attacker accesses the endpoint?  Attackers can obtain legitimate credentials in a variety of ways. Organizations could be breached when a trusted third party is compromised and the attacker exploits the trust between the parties to access the victim organization with legitimate credentials. A malicious insider can also obtain credentials without any malicious tools on the network. Advanced attackers also cannot be blocked like a firewall opens or close a port. The potential malicious code used by advanced attackers will be executed in a virtual environment (FireEye MVX) to analyze the behavior and to correlate the outcome with other security events to identify an advanced attack. Alerts from the FireEye device combined with the SAP Enterprise Threat Detection can alert you to attacks against your end users and against your SAP systems.


Example scenario

Professional attackers keep getting more determined and organized. The tactics they use are targeted, customized, and persistent. They can attack their targets via the web or a malicious email and use previously unseen malware to achieve their goals. A financially motivated criminal often sends a malicious email to an end user. That email can include a link to send the victim to an infected web page. If the end user clicks on the link, the attacker can gain full access to the victim's computer with access to all its business applications. In our example, an organization can identify attacker tools that are trying to connect to malicious infrastructure to receive commands or send data out, via FireEye's MVX technology.


APT detection example:


  1. A user receive an email with a malicious web link and open it
  2. FireEye sends the potential malicious webflow into MVX for analysis, without blocking the user
  3. FireEye detects the malicious behavior and create an alert. Detected command & control communication will be blocked.
  4. FireEye send an alert to SAP Enterprise Threat Detection about the infected device


Security team:

  • FireEye: Alert about infected device in console
  • SAP Enterprise Threat detection: Provide insight if something happened on the SAP business systems



Integrating the FireEye MVX with SAP Enterprise Threat Detection enables a security analyst to understand, if and how a SAP landscape has been affected. So the security analyst is better prepared to respond in the first crucial minutes following a breach. The longer an intrusion goes unnoticed, the more access attackers have to data that’s no longer secure. The pairing of SAP Enterprise Threat Detection and FireEye MVX gives the analyst the advantage of being able to quickly address a breach, potentially saving significant time, money, and loss of data.


Below is a FireEye detailed report of an analyzed malware object.


Technical configuration

In our case we want to configure the integration between SAP Enterprise Threat Detection and a FireEye MVX engine. The MVX engine sends its notifications in the Common Event Format (CEF). This example uses the sample web-infection event taken from the FireEye Alert Notifications (Release 7.7):


CEF:0|FireEye|CMS||WI|web-infection|4|rt=Mar 25 2015 22:07:50 UTC src=xxx.xx.x.xxx dproc=InternetExplorer 7.0 cs3Label=osinfo cs3=Microsoft WindowsXP 32-bit 5.1 sp3 15.0210 filePath=xxx.xx.x.xx:xxxx/metasploit dvchost=axhwmps dvc=xxx.xx.xx.x smac=00:0c:29:d9:2e:e1 cn1Label=vlan cn1=0 externalId=11646 cs4Label=link cs4=https://www.fireeye.com/event_stream/events_for_bot?inc_id\=11646 act=notified cs2Label=anomaly cs2=misc-anomaly cs1Label=sname cs1=Malware.Binary.url\n

To send the CEF notifications to the SAP Enterprise Threat Detection add the relevant information under the notifications area in setting on your FireEye device:



Ok, so what needs to be done to integrate the products?

  1. Import the FireEye ESP example project which is delivered with SAP Enterprise Threat Detection 1.0 SP3
  2. Configure the SAP ESP project  and execute it
  3. Test the integration and some troubleshooting tips


The goal is, that the FireEye MVX engine sends critical alerts in the CEF format via TCP/IP to SAP Event Stream Processor (ESP), which is part of SAP Enterprise Threat Detection (ETD). SAP Event Stream Processor will then map the data to the SAP Enterprise Threat Detection (ETD) internal format and store the data into the SAP HANA database. After that, the data will be available in the ETD user interface.

The SAP Enterprise Threat Detection installation package (HCO_SECURITY_MON.tgz), which you downloaded from the SAP Service Marketplace (http://service.sap.com/), also contains the FireEye example project for SAP ESP. If you do not have the package, please download it again from the SAP Service Marketplace (alternatively you can also export it from the SAP HANA repository).


Now we have to import this project to SAP ESP. Please open your SAP ESP studio and change to the ESP authoring perspective. Please import the FireEye project file (fireeye_events_over_tcp_in_etd).



On the picture below you can see the structure of the FireEye project. There is a “Socket_Input”, which is a TCP/IP socket, since FireEye will send the data via TCP/IP. The next box is “InputStream”, which is handling incoming data streams. Then the FireEye specific part comes with “Parse Data”. Here is the mapping of the FireEye format to the SAP ETD format. After that there is a “stream out” component (LogEventOut). In the configuration file (*.ccr) there is an existing binding for that output stream. The output stream of the FireEye project will be linked to the ESP project transfer_log_event and its module LogEventIn. So the FireEye project itself is not writing the data into the SAP HANA database, it uses the standard project transfer_log_event, which is delivered by SAP (this means also, if the standard project transfer_log_event is not running, the FireEye project cannot work).



On the next picture you can see the bindings of the FireEye project. Please ensure the Remote Stream settings are correct.



Please also click on parameters. Here you can find the TCP/IP port of the socket. This is required, if you want to send alerts from FireEye to SAP ESP (server  name and port is required.)



Now you can run the FireEye project on your SAP ESP server (you can use local for testing or your can choose your productive instance on the server)



Now we will test it manually (without a FireEye system sending the data). Please change the perspective to “ESP Run” in the SAP ESP studio. Click on the input stream and choose “Select the Stream for Manual Input”.



You can paste a test string into the text input field and use the string below. Please adjust the time settings (actual time and date), otherwise it will be tricky to find that data later in the SAP ETD user interface. Click on run button.


CEF:0|FireEye|CMS||WI|web-infection|4|rt=Mar 25 2015 22:07:50 UTC src=xxx.xx.x.xxx dproc=InternetExplorer 7.0 cs3Label=osinfo cs3=Microsoft WindowsXP 32-bit 5.1 sp3 15.0210 filePath=xxx.xx.x.xx:xxxx/metasploit dvchost=axhwmps dvc=xxx.xx.xx.x smac=00:0c:29:d9:2e:e1 cn1Label=vlan cn1=0 externalId=11646 cs4Label=link cs4=https://www.fireeye.com/event_stream/events_for_bot?inc_id\=11646 act=notified cs2Label=anomaly cs2=misc-anomaly cs1Label=sname cs1=Malware.Binary.url\n


Troubleshooting tip:

If you have problems, you can monitor in the “ESP Run” perspective, if there are new data coming in. Here an example of the “Output  stream” of the FireEye project:


Below “Input stream” of the “transfer_log_event“ project, which is reused by the FireEye project (the data will be refreshed every 3-5 seconds, so if you do not see anything, just send the test string again).



Let us check now the SAP Enterprise Threat Detection user interface (forensic lab). We can see a new FireEye log type. So there is data from FireEye available in SAP ETD.



Now it is very easy to create a view or a pattern with the data from FireEye. So you can easily find out, which transaction or function modules where called in SAP, from a PC which is infected with malware (reported by FireEye).

Read Access Logging (RAL) is available on SAP NetWeaver ABAP and is able to log “read access” to sensitive information from various sources. Currently RAL is supporting Dynpro, Web Dynpro, RFC and web services. You can define rules in RAL, which screens/fields you want to monitor. The log data will be stored in the database and you have the possibility to archive the information via the archive development kit.

Sometimes I get the question, how RAL fits together with SAP Enterprise Threat Detection (ETD)?

RAL is one of many other security information sources for ETD (http log, business transaction log, audit …). So if you want to analyze in ETD read access in ABAP, RAL is a good choice. The goal of RAL is not, to analyze security critical events in a system landscape – the goal is to provide log data per client for read accesses. But there are many attacks, where you need other information and so ETD is the central point of view for all security relevant data in a SAP system landscape.

ETD is more than a central store for security information:
In a first step, ETD is normalizing all the data from various sources. That is one of the most important steps. If you want to correlate data and keep the false positives low, you need a clean data basis of your security information. For that SAP introduced a security knowledge base with defined events and attributes. In a second step ETD pseudonymize the user ID, which is extremely important is some countries. The third step is about enrichment. ETD can enrich incoming events. One example would be to add to an IP address the MAC address. The forth step is to transfer the data to SAP HANA. After all these steps an administrator or security expert has the opportunity, to use pre-delivered patterns or they can browse through the normalized security information. So if you want to know, which transactions where used throughout the complete system landscape from a special terminal and time frame, you are only a few clicks away. Without ETD, this is a job that requires hours or days of manual work to answer only one question.

Other questions which you can answer in some clicks:
Who read HR critical data but is not working the HR organization?
Who accessed blacklisted function modules?
Was there a debugging session in my productive systems?
Any suspicious profile changes?


Oliver Kling

Do you trust your admin?

Posted by Oliver Kling May 10, 2016

Recently I stumbled upon a training about product security, where the topic of privileged users (sure this is not only an admin) was discussed. The simple objective of this training was that you need to trust a privileged user and thus it makes no sense to protect the system from malicious behavior of such a person. There is some truth in that, you need to trust people to do their job diligently. But there is more to that than just trust. Two things come to my mind immediately a) the old security phrase “prevention is key, detection is a must”, and b) the good old story of “segregation of duty”.

Yes, I need to trust the admin, but that does not mean I should look away what he is doing. In contrast there should be a control if an admin is not conducting malicious behavior. The simple control for that is logging. If you know and the admin knows that his tasks are logged in a secure log that he cannot tamper with, the barrier for committing malicious actions surely will raise.

On the other hand, do I need to trust the admin without any limits? No, of course not, even if the reality in many circumstances is like that. You have the option to segregate duties in many cases, unfortunately not in all cases as for example it is a bit harder to segregate duties if you IT staff is very small. But you just need to look in bigger organizations (financial institutes are a good example). There you will typically find a very fine grained segregation of duties. I have even seen models, where the database admin (DBA) was excluded from accessing the business data, using a complex to database instance setup.

And there is even more we can do, for critical things we can for example send an automated email to a different person or we could apply dual control for critical tasks (think about rocket launching ;-) ). And I am sure there are further measures to protect us from the admin beyond trust.

So the good news is that we do not need to trust the admin blindly. The bad news is that we need to take care for the admin in threat modeling as well.

OK, let’s assume we have a server infrastructure where the role of an admin is defined. The conservative approach is to give the admin full blown access rights. As such the admin can do anything, he can start and stop the system, she can change any configuration or network settings, she can deploy applications, and she can manage all the users and so forth. Is there a risk? Without looking at the details I would say yes, but let’s dive deeper.

My standard example for the risk is as follows. You run a web shop but dare to run the payment part of it. You instead outsource it to a card provider or online payment company. With that you have outsourced all the nasty security aspects of the payment handling itself. Almost. Because your hook into the payment provider likely is at least a URL maybe including authentication information. Again let’s put on the black hat: Ouh, a URL, what happens if I change it? I could easily point site visitors to a site where they get a drive-by malware infection. Or I could set up my own payment server pretending to be card provider XYZ (you do not even need an appropriate domain name). As such I log in as the admin, change the URL from time to time to my fake web site, and collect some credit card numbers. If I am clever I can blame the credit card provider for a few of the customer complaints.

If we look at the “prevention is key, detection is a must” paradigm, the first thing we do is take a closer look at logging. Will we find out that the admin has changed the URL and will we find out which values the URL had before it was changed? If not, we might better improve the logging. With this we are not preventing that but might be able to nail down the malicious guy afterwards. To prevent we consider again dual control or other means, which gets a bit trickier and costlier to implement. To be able to decide on our action we need to understand the risk.

Looking at the credit card example, the impact is credit card fraud. I am pretty sure you do not want to see your web shop in the press with a credit-card-fraud headline. As such I would estimate the risk as severe (our highest impact category). You might remember that we are not looking at the likelihood as the second dimension (where do we get realistic data for this?) but on the ease of attack. Admin and ease of attack? We figure out that the required trust is back in the game. For the admin the attack would be fairly easy, but we can balance that with the trust factor. As such we typically map admin attacks to our complex attack category. Severe x complex = high risk. Unfortunately, nothing changes if we have solid logging, as the impact is not affected and the ease of attack is also not increased. You could argue that probability goes down as your admin knows that you know … As such you could move the risk to the category “very complex”, which we typically reserve for extremely well-funded and skilled hacking organizations (I think you know whom I am targeting). If we do so we still end up with “medium” risk, but maybe that is something we can live with.

We could now try to reduce the impact, but that will be hard as it is a business function we likely need (at least once). Further measures will increase attack complexity, for example dual control would require the collaboration of two people… And thus we likely stick with the medium risk for the time being. At least according our internal scheme.

I think it is worth discussing risk evaluation in more detail. To keep it short you can do a more complex scheme, which likely also has downsides, or you try to keep it simple and partially vague. How do you evaluate risk, I would be very interested in that?

This post by SAP Product Security Response Team shares information on Patch Day Security Notes* that are released on second Tuesday of every month and fix vulnerabilities discovered in SAP products. SAP strongly recommends that the customer visits the Support Portal and applies patches on a priority to protect his SAP landscape.

On 10th of May 2016, SAP Security Patch Day saw the release of 10 security notes.

As of March 01, 2016, SAP Security Note prioritization is based on CVSS v3 Base score. The revised prioritization scheme is aligned with the industry’s best practice, and to provide better transparency to our customers. From March 2016 security patch day, all patch day security notes will carry CVSS v3 Base score and vector information to assist our customers in their risk assessment. For further details, please refer to our blog on CVSS v3.




Security Notes vs Vulnerability Type - May 2016


Security Notes vs Priority Distribution (Dec 2015 - May 2016)**



* Patch Day Security Notes are all notes that appear under the category of "Patch Day Notes" in SAP Support Portal

** Any Patch Day Security Note released after the second Tuesday, will be accounted for in the following SAP Security Patch Day.

To know more about the security researchers and research companies who have contributed for security patches of this month visit SAP Product Security Response Acknowledgement Page

Do write to us at secure@sap.com with all your comments and feedback on this blog post.



SAP Product Security Response Team

Since March 2016 patch day, SAP has started to publish CVSS Base scores in security notes based on CVSS version 3.0 standard. As a result of complete adoption of CVSS version 3.0, including recommended prioritization, security notes that were classified as ‘High’ in version 2.0 may now be classified as ‘Medium’. Customers are strongly advised to review their internal guidelines to IT teams in interpreting and analyzing the note priorities released by SAP.

Adoption of CVSS version 3.0 in SAP:

Across all (almost) vulnerability types, SAP expects a slight increase in CVSS Base Scores in version 3.0, compared to version 2.0. The CVSS version 3.0 documentation includes a list of comparisons of public vulnerabilities scored via CVSS version 2 and version 3.0. Listed below are some reasons for these differences in my opinion.

The version 3.0 standard provides a comprehensive assessment of potential risks associated with a vulnerability with more factors to consider than the CVSS version 2 standard. For example, most cross-site scripting (XSS) vulnerabilities, when exploited allows an attacker to inject and run malicious code in victim's browser. CVSS version 2 does not have a way to capture the change in impact from the vulnerable web server to the impacted browser. In version 3.0, the Scope metric allows us to assess the impact to the browser where a differentiation is made between vulnerable component and impacted component.  A typical XSS vulnerability has a base score of 4.3 in version 2 whereas a base score of 6.1 is assigned in version 3.0.

Overall, SAP expects version 3.0 Base scores to be higher than CVSS version 2, but bear in mind that CVSS version 2 scores are always relative to the "target host operating system", whereas version 3.0 scores are relative to the vulnerable component, or the impacted component if there is a scope change. In other words, CVSS version 3.0 will provide a better indication of the relative severity of vulnerabilities because it better reflects the true impact of the vulnerability being rated in software components.

Why SAP provides only CVSS version 3 Base score in security notes?

The CVSS scores provided by SAP in security notes are CVSS Base scores. SAP does not provide Temporal or Environmental score for vulnerabilities fixed in the security notes. We believe the Temporal score would have limited value to customers where two of the three factors affecting the Temporal score would never change (The Remediation Level would always be "Official Fix", and the Report Confidence would always be "Confirmed"). Further, the third factor (Exploit code maturity) would be “Proof of Concept” in most cases. As a result, Base score deducted by a constant value of 0.7 (based on the above values) would always be the Temporal score. For example, a Base score of 7.0 will always yield to a Temporal score of 6.3. Finally, SAP cannot compute the Environmental Score because this score is specific to the customers' environment (about which SAP has no or very little insight).

Does SAP publish CVSS version 3.0 scores for all security notes released?

Starting from March 2016 patch day, All ‘patch day notes’ will carry CVSS version 3.0 Base scores. However, in extraordinary situations (like 0-day disclosures), the security note priority may be escalated to 'Very High' (Hot News) irrespective of the CVSS version 3.0 Base metric score.

For more information:

The CVSS version 3.0 documents are available online on FIRST’s website at https://www.first.org/cvss

Related blog posts:

Introduction to CVSS. How SAP uses it?

Changes to CVSS in version 3.0

CVSS Version 3.0:

CVSS version 3.0 was released on June 10th 2015 after been under development for 3 years. This was overseen by the CVSS Special Interest Group (SIG) with inputs from representatives of a broad range of industry sectors, from banking and finance to technology and academia.

What is new in CVSS version 3.0?

There are many improvements introduced in version 3.0. In this post I will cover only the major improvements in Base metric group, which is the metric group that SAP uses.

If you need more information about the Base metric group, please refer to CVSS version 3.0 specification document (section 2).

1) Scope, Vulnerable Component, and Impacted Component     

One of the major development goals for CVSS version 3.0 was to solve the ‘Scope’ problem. Let me explain what a ‘Scope’ problem is.

‘Scope’ problem: In CVSS version 2, vulnerabilities are scored in relation to the “target host operating system”. As a result, vulnerabilities which have severe impact to SAP applications but limited impact to the target host operating system are rated as less severe (‘partial impact’). For example, a vulnerability in SAP application allows an attacker to perform a Denial-of-Service (DoS) attack with impact to the availability to the vulnerable SAP application. Even with a total take down of the vulnerable SAP application would only result in a ‘Partial’ (impact) rating for Availability metric in CVSS version 2. A ‘Complete’ (impact) rating for Availability can only be given if the host operating system can be taken down as well, per CVSS version 2 guidance.

This is clearly a problem for many application software vendors, including SAP. As a result, a solution is introduced in CVSS version 3.

To address the issue, CVSS version 3 introduces ‘Authorization Scope’, or simply ‘Scope’ metric to the Base metric group.  This new metric allows us to capture the extent of a vulnerability with impact that extends beyond the vulnerable component.

The definition of scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) which grant access to computing resources (e.g. files, CPU, memory, etc).

When we have two discrete components which manage privileges to computing resources separately, they represent separate (authorization) authorities. Referring back to our DoS attack example, let’s say the vulnerable SAP application is managed by "Authority A," while the host Operating System is managed by "Authority B."


(Credit: CVSS user guide) As depicted in the above diagram, CVSS version 3.0 leverages the Exploitability metrics to assess the vulnerable component in isolation. On the other hand, the Impact metrics are scored relative to the impacted component. When the vulnerable component is the same as the impacted component, there is no scope change. However, a scope change has occurred when there are impacts to components outside of the vulnerable component. In these cases, Confidentiality, Integrity and Availability impact metrics should be scored to reflect impact to either the vulnerable component, or the impacted component, whichever is most severe.

Going back to our DoS attack example above, in CVSS version 3, we can rate the Availability impact as ‘High’ (maximum score) to represent the real impact on the vulnerable application irrespective of its impact on Host Operating System. For cases where the Availability of the Host Operating System is also impacted, the increased severity is represented by the ‘Scope’ metric – scope changed.


(Credit: CVSS user guide) The diagram above illustrates the ‘Scope’ metric calculation.

2) Explanation of   Impact metric score calculation

a)  ‘Primary Impact’ versus ‘Reasonable Final Impact’

In version 3.0 the ‘Impact metric’ (CIA - Confidentiality impact, Integrity impact and Availability impact) calculation represents the ‘reasonable final impact’ possible caused by a successful vulnerability exploitation. In CVSS version 2, the impact calculation only considers the ‘primary impact’. CVSS version 3 is superior in considering the big picture in my opinion.

For example, a vulnerability resulting in disclosure of administrator credentials was rated with ‘partial’ impact to Confidentiality (with no impact to Integrity or Availability) in CVSS version 2. Yet, we should recognize the potential impact (or consequences rather) would lead an attacker to obtain administrative privileges. In version 3.0, the same vulnerability would be rated with ‘High’ impact to CIA.

b) ‘None, Partial, Complete’ versus ‘None, Low, High’

In CVSS version 2, the possible values for CIA impact were ‘None, Partial and Complete’ which are replaced by ‘None, Low and High’ in version 3.0. The new metric values reflect the overall ‘degree of impact’ caused by an attack. This is a departure from the overall percentage of the systems impacted by an attack in CVSS version 2. This change can be best explained via the ‘Heartbleed’ vulnerability (CVE-2014-0160). This ‘buffer over-read’ vulnerability which enabled an attacker to read up to 64 KB of victim’s memory is rated as having a Base metric score of 5.1 (NLN|PNN) in CVSS version 2. A successful exploitation of this vulnerability can result in only some (up to 64 KB) amount of information disclosure. However the ‘partial’ rating provided for ‘Confidentiality Impact’ does not consider the sensitivity of the data (or information) which is disclosed. Since CVSS version 2 cannot capture the sensitivity of data under attack, a vulnerability which results in disclosing information of lower sensitivity like version information of a web server, is also rated with the same Base metric score of 5.1. Yet in the ‘Heartbleed’ vulnerability, information of higher sensitivity like secret keys used for X.509 certificates, user names and passwords, emails, instant messages, business critical documents is disclosed. In version 3.0, ‘Heartbleed’ vulnerability has a Base metric score of 7.5 (NLNN|UHNN). You can see the Confidentiality impact is rated as ‘High’ considering the sensitivity\criticality of data under attack, even though the data is less than 64 KB.

3) Attack Complexity

Access Complexity (from CVSS version 2) conflated two issues: 1) Any condition beyond the attacker’s control that must exist or occur in order for the vulnerability to be successfully exploited (for example a software race condition, or a specific configuration setting), and 2) the requirement for human interaction (for example, requiring a user to click on a button or a link in case of ‘clickjacking’ or phishing attack scenarios). Therefore, Access Complexity has been separated into two metrics in CVSS version 3 - Attack Complexity (which addresses the former condition), and User Interaction (which addresses the later condition).

4) Privileges Required

The new metric – ‘Privileges Required’ replaces the Authentication metric of CVSS version 2. Instead of measuring the number of times an attacker must separately authenticate to a target system, Privileges Required captures the level of access required for an attacker to mount a successful attack. In CVSS version 2, rating of ‘Single’ for Authentication metric was unable to distinguish whether an attacker needs to have low level (for example read-only) privileges or high level (for example Administrator) privileges to successfully exploit a vulnerability.

Summary of all the changes introduced in CVSS version 3.0 compared to CVSS version 2 can be found here (section 2.9)

For more information:

The CVSS version 3.0 documents are available online on FIRST's website at https://www.first.org/cvss

Related blog posts:

Introduction to CVSS. How SAP uses it?

How to interpret SAP's CVSS score?

SAP has released the monthly critical patch update for April 2016. This patch update closes 26 vulnerabilities in SAP products including 19  SAP Security Patch Day Notes and 7 Support Package Notes. 8 of all Notes were released after the second Tuesday of the previous month and before the second Tuesday of this month.

10 of all closed SAP Security Notes have a high priority rating. The highest CVSS score of the vulnerabilities is 7.5.

SAP Security Notes April 2016 by priority

Most of the discovered vulnerabilities belong to the SAP ABAP applications security.

SAP Security Notes April 2016 by platforms

The most common vulnerability type is Missing authorization check.

SAP Security Notes April 2016 by type

This month, 5 critical vulnerabilities identified by ERPScan’s researchers Nursultan Abubakirov, Dmitry Yudin, and Vahagn Vardanyan were closed.

How 2 DoS vulnerabilities can allow full system compromise


Two of the off-schedule patches addressing Denial of Service vulnerabilities discovered by Dmitry Yudin ([1] and [2]) were released on March, 14. On March,16 at the Troopers Security conference ERPScan director of SAP cyber security services Dimitry Chastuhin showed how to execute code remotely using these 2 DoS, one configuration mistake, and race condition vulnerability.


His presentation titled “Exploiting the unexploitable” proved that even low-impact vulnerabilities can be used together to gain full administrative access to the system. Since patching process on a real SAP landscape is time-consuming and costly, the idea to fix only the most dangerous security issues seems rather tempting, but, as we can see, completely insecure.


According to responsible disclosure rules, we can’t give any details of this attack vector before 90 days after disclosure.


Issues that were patched with the help of ERPScan


Below are the details of the SAP vulnerabilities  that were found by ERPScan researchers.


  • A Denial of service vulnerability in SAP Enqueue Server (CVSS Base Score: 7.5). Update is available in SAP Security Note 2258784. An attacker can use a Denial of service vulnerability to terminate a process of the vulnerable component. For this time, nobody can use this service, which negatively influences on  business processes, system downtime and business reputation.
  • A Denial of service vulnerability in SAP Internet Communication Manager (CVSS Base Score: 7.5). Update is available in SAP Security Note 2256185
  • A Denial of service vulnerability in SAP jstart (CVSS Base Score: 7.5). Update is available in SAP Security Note 2259547.
  • An XML external entity vulnerability in SAP UDDI (CVSS Base Score: 7.1). Update is available in SAP Security Note 2254389. An attacker can use an XML external entity vulnerability to send specially crafted unauthorized XML requests which will be processed by XML parser. An attacker can use an XML external entity vulnerability to get unauthorised access to OS filesystem.
  • A Cross-site scripting vulnerability in SAP UR Control (CVSS Base Score: 6.1). Update is available in SAP Security Note 2201295. An attacker can use a Cross-site scripting vulnerability to inject a malicious script into a page. More information about XSS vulnerabilities in SAP systems is available in ERPScan’s research.


Other critical issues closed by SAP Security Notes April 2016


Some of our readers and clients asked us to categorize the most critical SAP vulnerabilities to patch them first. Companies providing SAP Security Audit, SAP Vulnerability Assessment, or SAP Penetration Testing services can include these vulnerabilities in their checklists. The most critical vulnerabilities of this update can be patched by the following SAP Security Notes:


  • 2262710: SAP HANA DP Agent has a Denial of service vulnerability (CVSS Base Score: 7.5 ). An attacker can use a Denial of service vulnerability to terminate a process of the vulnerable component. For this time, nobody can use this service, which negatively influences on  business processes, system downtime, and business reputation. Install this SAP Security Note to prevent the risks.
  • 2262742: SAP HANA DP Agent has a Missing authorization check vulnerability (CVSS Base Score: 7.3 ). An attacker can use a  Missing authorization check vulnerability to access a service without authorization and use service functionality that has restricted access. This can lead to information disclosure, privilege escalation, and other attacks. Install this SAP Security Note to prevent the risks.
  • 2252191: SAP HANA XS Advanced Java Runtime has a Remote command execution vulnerability (CVSS Base Score: 7.3 ). An attacker can use a Remote command execution vulnerability to execute commands remotely without authorisation. Executed commands will run with the same privileges as the service that executed the command. An attacker can access arbitrary files and directories located in a SAP server filesystem including application source code, configuration, and critical system files. It allows obtaining critical technical and business-related information stored in the vulnerable SAP system. Install this SAP Security Note to prevent risks.


It is highly recommended that SAP customers patch all those SAP vulnerabilities to prevent business risks affecting SAP systems.


SAP has traditionally thanked the security researchers from ERPScan for found vulnerabilities on their acknowledgment page.

We (The SAP Product Security Response Team) have received many questions from our customers on how SAP uses the Common Vulnerability Scoring System, also known as CVSS. This blog is the first post in a series that aims to provide an insight into CVSS and how it is used in SAP.

Background: In the last 5 years, SAP has been using CVSS to communicate the severity of vulnerabilities fixed in SAP security notes. SAP security notes are released on the second Tuesday of every month, known as SAP security patch days. We also use CVSS to prioritize our engineering effort internally to triage product security vulnerabilities. SAP is an active member of the CVSS Special Interest Group (SIG), and actively contributes to the development of CVSS version 3.0, the latest CVSS version.

What is CVSS?

CVSS is an open, vendor-neutral, technology-independent framework for communicating the characteristics and severity of software vulnerabilities. In practice, CVSS scores can be used to rate the severity of security vulnerabilities. CVSS can be applied to a very wide-range of software products including operating systems, web applications, security products (like firewalls, antivirus software), databases, etc.

CVSS consists of three metric groups: Base, Temporal, and Environmental. In-depth details of these metric groups can be found here. SAP focuses on the Base metric group only, because we believe it will bring the most value to our customers, and represents the intrinsic characteristics of a vulnerability. The Base metric group is constant over time and across user-environments.

Evolution of CVSS

CVSS was initially announced in February 2005 on the U.S. Department of Homeland Security website. From its introduction, CVSS underwent two major revisions under the custodial ownership of FIRST (Forum of Incident Response and Security Teams). As of writing this blog, the current version is CVSS version 3.0 released in June 2015.

CVSS VersionReleased on
Version 12005
Version 22007
Version 32015

Why you should start using CVSS?

CVSS offers the following three benefits for a software vendor like SAP   to convey the severity of a fixed vulnerability to its customers:

1) It provides standardized vulnerability severity scores.  This helps an organization in making informed decisions to schedule an appropriate patch window based on vulnerability severity.

2) It provides an open framework. Users may be confused when a vulnerability is assigned with an arbitrary score by a third party. With CVSS, the individual characteristics used to derive a score are transparent.

3) CVSS helps in risk prioritization. When the CVSS Environmental metric score is computed (typically done by end-user organizations because they are best able to assess the potential impact of a vulnerability within their own computing environment), the vulnerability becomes contextual to each organization, and helps provide a better understanding of the risk posed by the vulnerability to the organization

Additional points to keep in mind:

  • Presence of un-patched vulnerabilities with a CVSS score of 4.0 or higher will have negative impact to PCI (Payment Card Industry Data Security Standard) compliance.
  • International Telecommunication Union (ITU) recommends the usage of CVSS for vulnerability severity rating.

How SAP uses CVSS?

To provide transparency to our customers, security note priority is now calculated entirely based on CVSS v3 Base metric score.

Security Note PriorityCVSS v3 Base score
Low0.1 - 3.9
Medium4.0 - 6.9
High7.0 - 8.9
Hot News9.0 - 10.0

Also, SAP uses CVSS version 3.0 Base score for vulnerability prioritization in our products. We believe it is critical for us to ensure time taken to provide a fix for vulnerability is in inverse proportion to the CVSS score of the vulnerability, such that a high CVSS score will yield to the least time to provide a fix to our customers. This prioritization also has an effect to the ‘downporting’ requirements – i.e. to how many legacy versions of the software we supply a patch.

For more information:

The CVSS version 3.0 documents are available online on FIRST’s website at https://www.first.org/cvss

Related blog posts:

Changes to CVSS in version 3.0

How to interpret SAP's CVSS score?

This post by SAP Product Security Response Team shares information on Patch Day Security Notes* that are released on second Tuesday of every month and fix vulnerabilities discovered in SAP products. SAP strongly recommends that the customer visits the Support Portal and applies patches on a priority to protect his SAP landscape.

On 12th of April 2016, SAP Security Patch Day saw the release of 16 security notes. Additionally, there are 3 Out-of-Band Security Notes released this month.

As of March 01, 2016, SAP Security Note prioritization is based on CVSS v3 Base score. The revised prioritization scheme is aligned with the industry’s best practice, and to provide better transparency to our customers. From March 2016 security patch day, all patch day security notes will carry CVSS v3 Base score and vector information to assist our customers in their risk assessment. For further details, please refer to our blog on CVSS v3.




Security Notes vs Vulnerability Type - April 2016


Security Notes vs Priority Distribution (Nov 2015 - April 2016)**



* Patch Day Security Notes are all notes that appear under the category of "Patch Day Notes" in SAP Support Portal

** Any Patch Day Security Note released after the second Tuesday, will be accounted for in the following SAP Security Patch Day.

To know more about the security researchers and research companies who have contributed for security patches of this month visit SAP Product Security Response Acknowledgement Page

Do write to us at secure@sap.com with all your comments and feedback on this blog post.



SAP Product Security Response Team

I remember one case where we did a threat modeling workshop for a product that consists of a rich client that allows editing of objects (e.g. contract, a file, a master data record, source code …). These objects are managed by the server and the server keeps track of all these changes and maintains the appropriate version history. To keep track of the changes each object gets a temporary unique identifier, which is assigned to the object in scope. With the identifier the server can verify and manage versioning.

From a pure functional view point any unique identifier serves the purpose. But in threat modeling we are not thinking in proper working solutions but we want to know how we can break things. Let’s switch the perspective from a developer to a hacker. Where the developer might think uniqueness is key and helps to achieve the objective of consistent versioning, the hacker in us thinks: Hey, there is an identifier, what can I do with it to do something unexpected?

It is easy to observe identifiers if you have access to the system as a normal business user. In our case we just need to touch a few objects in a row, it does not even matter if these objects hold sensitive information (let’s look at that later). It turned out that the identifiers are based on a sequence. The server just incremented the identifier by one with each request. As said, that is perfectly fine for the pure functional use case. But for the hacker in us it is an interesting hook. A sequence gives at one hand a clear view on the history of identifiers and allows on the other hand a simple prediction of upcoming identifiers.

Let’s look what happens if we change the identifier to an identifier that already has been used. How will the system behave in this case? It might be possible to overwrite an object that already was created. The same is true for an identifier yet to be used; you could change the identifier to the current value plus one to interfere with the work the next edit job is doing.

What can go wrong here? If the identifier is the sole barrier for consistency, an attacker can tamper with the records in the system. Depending on the object type this might allow anything between nuisance and criminal fraud.

On the basis of this abstract information we cannot conclude on that. In addition, we are not yet sure if the identifier in use is just an optimization, and tampering with the identifier is not working as the server does different other checks and will figure out that something is going wrong or simply will not allow any attempt to manipulate files or objects in that way.

But hey, we are in a threat modeling workshop, we do not start analyzing the server behavior ourselves, we just ask the developers in the room. And the question is as simple as that: What happens if an attacker is manipulating the identifier by incrementing it or using by using a past value?

And be sure, there will be silence for a moment, the developers will think about it. If they actually work on that for quite a while, you might get the answer fast. If the team is only responsible for the client, they might need to check with someone else or dive into that deeper later on.

But we found a potential vulnerability. Now all we need to do is to figure out how high the risk of the respective threat is and consider the need and cost of a mitigation.

Typically, I avoid discussing the mitigations in detail. But in this case there is a standard cure. Identifiers that have potential security relations (confidentiality, integrity…) should be based on cryptographically secure random numbers (be sure to use a secure random function). Having that in place, the chance of guessing or predicting and thus tampering with the identifier is basically gone.

What is my conclusion? Successful threat modeling requires a different perspective (how can I break it), curiosity (what can I do with that, even if it is not immediately an attractive hacking target), and then you just need to raise a few simple question – e.g. What happens if I increment the identifier manually on client side by one?

In my threat modeling workshop, the threat did not really materialize as the surrounding framework prohibited a feasible materialization of a successful attack. Is it worth attacking your identifiers? Let me know, happy to discuss your scenario with you.


Filter Blog

By author:
By date:
By tag: