1 2 3 16 Previous Next


229 Posts

Hey community,


Some weeks ago I wrote a Troubleshooting Guide regarding how to properly troubleshoot and overcome the SSSLERR_PEER_CERT_UNTRUSTED error that can be found in the ICM trace.


Often when setting up a RFC or Web Service connection to another system that is protected with SSL you can face this common error.

Troubleshooting Guide - How to troubleshoot the SSSLERR_PEER_CERT_UNTRUSTED (peer certificate (chain) is not trusted) issue


Please share your thoughts and let me know if it was helpful for you!



Filipe Santos



there is a white paper on Real Time Protection of SAP Landscapes of KuppingerCole.


Content (extract)

  • Explaining the change in cyber-attackers and cyber-attack patterns, targeting core business systems and critical industries
  • Cyber-risks becoming business risks, requiring risk mitigation processes that are connected to Enterprise Risk Management and Enterprise GRC
  • Overview of a comprehensive cyber-risk incident management and response process
  • The role Real Time Security Intelligence (RTSI) plays in mitigating cyber-risks
  • SAP Enterprise Threat Detection (ETD) as a RTSI solution for SAP environments and beyond


Link to white paper: http://go.sap.com/documents/2016/06/d6df83ea-777c-0010-82c7-eda71af511fa.html




The current issue of the SAPinsider journal highlights a selection of security topics, with articles running the gamut from risk mitigation to enterprise security.


In the executive Q&A, SAP's Chief Security Officer Justin Somaini talks about protecting the enterprise in phases of digital transformation and changing threat landscapes.


In "Gain Control and Mitigate Risk", Bruce McCuaig explains the three lines of defense for a holistic security framework.


"Integrated Security Solutions to Mitigate Risks on All Fronts" by Thomas Frénéhard goes into more detail to show how SAP's governance, risk, and compliance (GRC) and security solutions protect companies in the digital age.


Ralph Salomon, VP of Secure Operations at SAP, describes how "SAP Runs SAP Secure" in his article about SAP's own security infrastructure and strategy on the basis of three pillars: Prevention, detection, and reaction.


And finally, "An Integrated Approach to Identifying Security Risks" by Martin Plummer gives on overview of the SAP Enterprise Threat Detection solution, which enables companies to set up an integrated security analysis across their IT landscape.


Happy reading!

SAP has released the monthly critical patch update for June 2016. This patch update closes 21 vulnerabilities in SAP products including 15  SAP Security Patch Day Notes and 6 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. 3 of all notes are updates to previous Security Notes.

3 of all closed SAP Securtiy Notes have a high priority rating and 1 has a Hot News rating. The highest CVSS score of the vulnerabilities is 9.1.

SAP Security Notes June 2016 by priority

Most of the discovered vulnerabilities belong to the SAP NetWevwer  ABAP platform, the oldest and the most widespread one. It is a backend platform for most of the common business applications such as ERP, CRM, SRM, and PLM.

SAP Security Notes June 2016 by platforms

The most common vulnerability types are Cross-site scripting and Missing authorization check.


This month, 4 critical vulnerabilities identified by ERPScan’s researchers Nursultan Abubakirov, Alexander Polyakov, and Vahagn Vardanyan were closed.


How long does it take a vendor to patch an issue?


Third-party researchers discover numerous security issues in various products on a daily basis. A responsible vendor usually tries to fix an issue in a timely fashion. As a rule, it takes a vendor approximately 1-3 months to release a patch. However, some of vulnerabilities are not easy to close (especially architectural ones). As long as SAP is concerned, the required time to patch a security issue is 3 months, according to rough estimations.

This month, SAP fixed a vulnerability detected by ERPScan researcher Alexander Polyakov 3 years ago. The identified cybersecurity issue is an Information Disclosure vulnerability in BI Reporting and Planning of the Business Warehouse (BW) component. The product can transform and consolidate business information from virtually any source system.

The issue was reported about on the 20th of April, 2013. It means that it took SAP more than 3 years to fix the issue. Moreover, not all companies implement a patch after the release date. As the Invoker Servlet case shows, sometimes SAP systems stay unpatched even for 5 years after the Security Note release. Taking into account that vulnerability impact is rather severe (CVSS v3 Base Score: 5.3/10), as it allows an attacker to discover information useful for further attacks, the unpatched vulnerability put companies at serious risks.


Issues that were patched with the help of ERPScan


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


  • A Cross-site scripting vulnerability in SAP ecattping (CVSS Base Score: 6.1). Update is available in SAP Security Note 2256178. An attacker can use Cross-site scripting vulnerability to inject a malicious script into a page.
  • An Information disclosure vulnerability in SAP BI Reporting and Planning (CVSS Base Score: 5.3). Update is available in SAP Security Note 2197262. An attacker can use an Information disclosure vulnerability to reveal additional information (system data, debugging information, etc) which will help an attacker to learn about a system and to plan further attacks.
  • A Denial of service vulnerability in SAP Sybase SQL Anywhere MobiLink Synchronization Server (CVSS Base Score: 4.9). Update is available in SAP Security Note 2308778. An attacker can use a Denial of service vulnerability to terminate a process of a vulnerable component. For this period of time, nobody can use this service, this fact negatively affects business processes, system downtime, and, as a result, business reputation.
  • A Directory traversal vulnerability in SAP Data Services (CVSS Base Score: 2.7). Update is available in SAP Security Note 2300346. An attacker can use a Directory traversal to access arbitrary files and directories located in an SAP server filesystem including application source code, configuration, and system files. It allows obtaining critical technical and business-related information stored in a vulnerable SAP system.


Other critical issues closed by SAP Security Notes June 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:


  • 2306709: SAP Documentation and Translation Tools has a Code injection vulnerability (CVSS Base Score: 9.1 ). Depending on the code, attacker can inject and run their own code, obtain additional information that should not be displayed, modify data, delete data, modify the system output, create new users with higher privileges, control the behavior of the system, or potentially escalate privileges by executing malicious code or even to perform a DoS attack. Install this SAP Security Note to prevent the risks.
  • 2222731: SAP DesignStudio SFIN has a Cross-site scripting vulnerability (CVSS Base Score: 8.8 ). An attacker can use Cross-site scripting vulnerability to inject a malicious script into a page. Install this SAP Security Note to prevent risks.
  • 2308217: SAP Web-Survey has an XML external entity vulnerability (CVSS Base Score: 7.5 ). 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. 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 its acknowledgment page.

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 14th of June 2016, SAP Security Patch Day saw the release of 13 security notes. Additionally, there were 2 updates to previously released Patch Day 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 - June 2016


Security Notes vs Priority Distribution (Jan 2016 - June 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

US-CERT alert on SAP Cyberattack


On May 11, 2016, the Department of Homeland Security published the first-ever US-CERT Alert for cybersecurity of SAP business applications.

Nonetheless, what we do know from public sources is that there were threads on some Chinese forums related to the attack. However, is there any proof? I mean, I’m absolutely sure that cybercriminals perform attacks against SAP. I also believe that we should pay more attention to them and increase awareness. But as researchers and experts to whom the industry tends to trust, when we state that there was an attack, we ought to always provide IT community with solid proofs. I was personally involved in forensic investigation of SAP systems compromise and have no doubts that attacks are real, but I can’t disclose the details, that’s why I do not advertise that dozens of systems are under attack.

The original Invoker Servlet vulnerability


What kind of vulnerability was used and how dangerous is it?


As it was stated  in the report, the attackers used an invoker servlet vulnerability.
We were the original authors who were first to describe how exactly that this misconfiguration can be used to exploit SAP Systems and thus can lead to cyberattacks.  Firstly, the information about this misconfiguration was published by SAP in 2010. SAP stated that it would be better to disable this functionality if customers don’t use it. However, they didn’t provide any specific details about risks. In other words, the customers were not encouraged to disable it.

We [Alexander Polyakov and Dmitry Chastukhin] highlighted this issue at the BlackHat USA conference in 2011 during the talk titled  “Crushing Blow at the heart of SAP’s J2EE Engine”.

To help companies to understand why this misconfiguration has crucial importance, what it allows hackers to do, and how to prevent its exploitation, we discovered an example of a vulnerable servlet which can be exploited because of this invoker servlet misconfiguration. This vulnerability was found in CTC servlet, and it can be used to perform almost any critical action in SAP such as creating a new user or reading any table.  Later, we published a whitepaper  and delivered a series of talks on an international scale to warn people about this vulnerability and help them to securely configure it.

As the issue is not easy to identify when you have a lot of services and a set of custom applications, we introduced a free tool called  ERPScan WEBXML Checker that can be used to manually assess SAP Configurations and detect this issue as well as some others issues with J2EE web services functionality.

To make matters even worse, the vulnerability was not easy to patch either. First, it was necessary to analyze if an invoker servlet is enabled by default, then disable it and reboot the system. After that, you have to manually assess every web service (and there are 500+ of them just in a default J2EE installation) and check if invoker servlet functionality is enabled or disabled. If enabled, a task was either disable it or manually analyze a configuration file, if it is exposed any critical services which can be bypassed and then to configure it properly. Our tool also makes this process easier.

I can say that this tool was downloaded more than 300 times from our website in the last years, which may have prevented some attacks (at least I hope so). Now, as far as we know from the news articles, there are only 36 vulnerable companies and this number could be even bigger without our tool. In our turn, we, as always, tried not just to scare SAP users, but to do everything possible to protect them.


Real attacks on SAP using Invoker Servlet vulnerability


Sadly, there are no facts in this report that can be somehow proven by anybody except the original author. That is why I decided to check the facts myself.

The only interesting fact about the attack is this  -  ”The exploitation of the affected organizations’ SAP systems was publicly disclosed during 2013-2016 at a digital forum registered in China. In all cases, the individuals leveraged a publicly-known SAP application vulnerability, for which SAP had released a security patch more than five years ago.”  - So, the only thing we know from trusted report is that on some Chinese forums we can find information that cybercriminals shared the data about vulnerable systems. I didn’t believe that cybercriminals published any relevant information in the wild. Within a couple of minutes, it turns out that on of the forums where Chinese white-hat community shares data on systems they can exploit and notify vendors and victims there were examples of systems which are vulnerable to the issue that we responsively disclosed back in 2011. It was a CTC servlet which was susceptible to invoker servlet bypass vulnerability. I found out that there were 44 posts with SAP hacking examples, all of them were using the invoker servlet vulnerability together on a critical web service that was also patched by SAP. The number of attacked systems  - 44 correlates with the number of compromised companies (36 companies), taking into account that there can be multiple systems in one company. The countries involved are also the same, which allows us to conclude that we speaking about the same forum.

But the thing is that those examples were not the attacks but rather responsively disclosed issues by security experts from such companies as Baidu.

Here is one of the examples from this forum where experts share timeline of responsible disclosure:

2016-03-14:Details have been sent to manufacturers and vendors Processing
2016-03-15:Manufacturers have confirmed that the details disclosed only to manufacturers
2016-03-25:Details disclosed to the core white hat and experts in relevant fields
2016-04-04:Details to the general public a white hat
2016-04-14:Details disclosed to practice white hat
2016-04-29:Details to the public

So it turns out that most and probably all of those issues were sent to responsible authorities as listed in the status of vulnerability.  Some vulnerability statuses are “It was handed over to third party institutions (CNCERT National Internet EmergencyCenter) processing” (translation of the last field on the screenshot below).

And for most of the issues we can find that there was a coordinated work with CNCERT to notify vendors “CNVD identify and reproduce the circumstances, it has been notified to the China Mobile Group transferred CNCERT, coordinated by the subsequent disposal site management.”

While in most posts that we analyzed we see that information was responsively disclosed. However, we can’t guarantee that nobody, including the authors really used them to conduct a cyberattack.

So, now we can see that those posts were not actually examples of cyberattacks and system compromise. But! Do not think that cyberattacks on SAP do not really exist. The other thing which worth mentioning here is that one of our Network sensors of global threat intelligence platform has recently (dd 12/4/2016, 14:19-14:20) identified the attack attempt exploiting the similar kind of issue, but as it was the only example against one sensor, we left that information internally for further investigation before publishing alerts.

The last but not least.  At the end of 2014, we were asked to participate in forensic investigation project where the company was attacked via SAP vulnerability, and results of this project correlate with this data.

How big is the threat?

The matter here is not the fact of the attacks, but how many systems are vulnerable to this issue in addition to 44 systems identified, according to our investigation. Mathieu Geli – Head of SAP Threat Intelligence at ERPScan, revealed that approximately 533 systems across the globe (data obtained via non-intrusive network recon techniques leveraged by the open-source project IVRE) which are potentially vulnerable to one of the example of Invoker servlet vulnerability.

The other examples are by far more difficult to calculate. Those services can have unique names so that it’s not possible to get the final figure (approximately 500+ systems). Taking into account that most of them belong to Fortune 2000 companies, it’s quite critical issue to discuss.

Invoker servlet vulnerability – takeaways


So, at the end of the day, it doesn’t matter who was compromised and whether it was a real attack. The only thing that matters for the industry is how to prevent the issue exploitation. And I have an answer.

Information how to fix the vulnerability was published in our whitepaper, but here is a brief overview.


1) Update to the latest patch level that corresponds to your support package
2) Disable the vulnerable feature by changing the value of the “EnableInvokerServletGlobally” property of the JSP service on the server nodes to “false”
3) If you need to have an enabled invoker servlet for some applications, see SAP Security Note 1445998 for SAP NetWeaver Portal and SAP security Note 1467771
4) If you can’t install patches, you can check all the WEB.XML files using ERPSCAN WEB.XML Checker to find insecure configurations and locally enabled invoker servlets and manually secure all web services by adding protection to /* folder.



1) I was talking about it many times and continuing it especially now. A large number of SAP patches don’t exactly fix an issue as it seems to a unexperienced user. This situation  relates mostly to configuration issues. SAP closes most issues by just introducing new parameters, which SAP administrators need to manually enable. That's why one has so many difficulties with Securing SAP Systems. Simply saying, you can't just implement patch. In most cases additional configurations are required after that. That's the most important takeaway.
2) SAP gives you a lot of customization functionality, so you can build your own apps where you should manually enable security features. Going back to our example, even if you disable invoker servlet globally, it can be enabled by any of your developers or admins. So, take a closer look at the customizations, and not only in this case, but in general. Check the source code of custom programs and  authorizations for all users.
3) Finally, do not expose unnecessary services online. All of the 36 systems that may have been compromised  had an administrative service were unnecessarily exposed to the Internet.

The new projects of the Customer Engagement Initiative (CEI) are now open for registration until June 10th, 2016 (Update: You can still register for the new projects, please send an email to the respective contact person stated below). In the area of security and identity management, don’t miss these upcoming CEI projects:



SAP's Customer Engagement Initiative (CEI) enables you, as an SAP customer or partner, to get early insights into SAP product developments. You will have the opportunity to evaluate and discuss your ideas together with us.



CEI "Enterprise Threat Detection (ETD)"


SAP Enterprise Threat Detection offers real-time detection of security incidents as well as powerful forensics analysis. Join our new CEI if you are interested in working with us to further improve SAP Enterprise Threat Detection by adding new attack detection scenarios and enhancing the arsenal of analysis techniques to spot intruders early on. We are seeking your experience and stories in attacks against SAP or ERP systems in order to tune the tool into the solution you are expecting from SAP. Find out more and contact Carmen Graf to register.



CEI "Identity and Access Provisioning for Cloud Applications"


If your company is extending business processes with SAP cloud offerings and if you are interested in identity and access provisioning for cloud applications, you are invited to join our new CEI and discuss with our team the challenges that your company is facing from an identity and access management perspective when integrating new cloud SAP and non-SAP applications with your existing IT infrastructure. Find out more and contact Donka Dimitrova to register.



CEI "Extending SAP Identity Management Connectivity"


SAP Identity Management helps enterprises to manage user access to heterogeneous applications securely and efficiently, in alignment with their business processes and in accordance with audit and compliance requirements. This CEI is about extending connectivity to cloud solutions such as Cloud 4 Customer and Ariba as well as enabling customers and partners to build their own connectors more easily. Find out more and contact Fedya Toslev to register.



Register now for the initial call for the projects interesting to your organization. After that call, you decide to take the next steps in the collaboration.

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?


Filter Blog

By author:
By date:
By tag: