1 2 3 9 Previous Next


123 Posts

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


So what’s new with SP01?

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






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


Relevant SAP Notes

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

Hi all,


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


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


A personal note

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


So what is difference to SAP Enterprise Threat Detection?

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





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

Does SAP Enterprise Threat Detection replace existing SIEM solutions?

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


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

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


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

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


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





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


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







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


Summary and examples

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


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

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

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

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

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



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


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



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

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


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


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



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

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

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



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


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




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




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




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




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



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


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



Hope this is an useful overview about the security portfolio.




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

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

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

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

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

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


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


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

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

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

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


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

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

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

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


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

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

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

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


Figure 6. Registration form display:


SAML Trust Configuration improvements include several new capabilities:

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

All sorts of problems

Bad things can happen to your authorization concept for many reasons:

  1. The security department lacks the education and skill
  2. The security department is understaffed
  3. External service provider built something ridiculous
  4. Legacy authorization concept is not suitable for the new business situation
  5. Political situation in the organization does not play in the security team’s flavour
  6. New functionality (like module) is implemented without clear requirements (which in security means: broad or inconsistent access) and is kept that way after the go-live
  7. SAP does not give the customers the technical means to implement the required security standards
  8. The quality of work done by the members of the security team is inconsistent and varies from very good to very bad (so everyone is demoralized and people break other people’s work every day)
  9. Different departments run their own security or have very inconsistent security requirements and means of implementing them
  10. The technical and philosophical means used in the project (and in the operations) are sub-optimal or simply wrong (value roles, composite roles with task based mini-roles etc.)
  11. The scope of the project is broad and the internal or external delivery is on a high quality standard, unfortunately the after-the-project mode (and resources) don’t allow the security team to keep the level of security so high (so the project was actually a waste)
  12. …and many other situations


These are just some examples that lead to bad things rather sooner than later. Why am I starting a blog post with such a list? Well, you have certain technical tools, certain political and organizational power as well as a certain size of the security team. Your security levels needs to be aligned with these things (and many others as well… we can argue which of the factors are the most important, which are less important and which are rather minor – please leave a comment below).

For this very reason I ask my customers many questions before we even start a project. Questions like: is your management difficult or supportive? Do you have an internal auditing department? How do you check the quality of the work in your team? What system releases do you have available? When did you perform the last big clean up or redesign of your roles or security in general? What are the roles that you’ve defined for yourself and to what extent you stick to them? Do you work centrally or the responsibility (and authorizations and needs etc.) are distributed?

Answers to these questions should help you build roles (generally security) tailored to the organization’s needs (and to the needs of the security admins there) as well as guarantee that the roles you build (generally security) will survive for long enough so that the externals and internals on the team can sleep well.


Here comes the challenge

I know, I am talking about too general things without indicating what is what I want to say in this blog. Let me briefly describe my motivation for this blog first. Under my recent blog “On the way to granularity” I received a comment about the difficulty with S_TABU_DIS and NAM access in the real world, specifically in the area of the Financials. That blog was meant to inform readers about technical means for the granular security access (that things are available and you can optimally use them for your benefit and security).

But the question is less about the technical means and more about the organizational obstacles as well as about the challenge to implement granularity in the finite time (with everyone still aboard and happy when it is finished).

Kesayamol Siriporn asks (using my own words): There is a table LFA1 which contains sensitive information. This table is assigned to an authorization group FA. This group contains 955 tables in the system where I’ve just checked. Users that use LFA1 also use other tables from that group, but not all 955 probably. The question and the challenge is how to authorize for the access to the table LFA1 and other tables from its group so that the workload produced by the approach is not overwhelming for the security team and on the other hand we can still call the approach secure. We also need to consider the users using queries and generic table access transactions (SE11, SE16(N), SM30, SM31, SM34) on these tables.

Choose the right tool for the job

The question is specific, so I will covered the specific details to my best knowledge. On the other hand the question generally asks to what extent we can or should implement the highest possible granularity and how to do it efficiently.

The following points and questions come to mind:

  1. I am pretty sure there are standard means (transactions, reports, queries) how to work with the data in the tables mentioned in our question. Has all standard options been considered for the end-users? Are we forced to come to the lowest level – database tables?
    1. These standard tools will be maintained and developed further by SAP so the upgrade (also mentioned as a point in the challenging question) does not pose any threat or force periodical redesign.
    2. For these standard tools we have transactions available (as the primary building block for the role menus as well as the main door for the users which we can use to talk about the problem with normal mortals).
    3. For these standard tools we have SU24 defined which provides you the “templates” for the roles and you need to define only a couple of fields and values and primarily consider the organizational aspect (org. fields etc.) based on the data.
    4. The organizational aspect (like using the org. fields) is simpler than maintaining long lists of tables for generic table access transactions. You can tell if a user can have access to a specific cost center, profit center, vendor or a purchase order easier than whether than user can see one of those 955 tables in the LFA1’s authorization group (use any other example from your daily work here).
  2. There are many possible answers to the point above:
    1. “We don’t know. We have no clue what standard tools we can use” – is this because you are new to SAP? Or you pay money to people who don’t know their job? Or have you just started considering what you can do about this challenge and the direct table access sounded like the easiest option? Please inform yourself first before jumping to conclusions.
    2. “Yes, the tools are available, but our users cannot use them” – and why is that? Too much training would be needed? Release of the system is too low? Or what is the problem exactly?
    3. A variation of the previous point: “Yes, the tools are available, but the users don’t want to use them as we traditionally use table access and we cannot take that away from users”- ok, but this is not a technical problem. You must either find enough workforce to perform a clean-up and remove the generic tools (like queries or transactions like SE11/16) without bothering the users (the access is the same, but the technical way is more sustainable) or get yourself enough political support so that you can take the generic tools officially away and start giving granular access from scratch and carefully (please see “from scratch” as shortcut for the purpose of the storytelling here, not literally).
    4. “No, the tools we need are not available in the standard” – well, then you can consider building them maybe? Why not custom development?
    5. We must also consider that in some cases “Table access can be fast and efficient for the super-users”. But in this case the challenge is not to secure the whole system and all the tables one by one for users to be able to use them, we are talking about a handful of users and I would say handful of DB tables as well. That leads to the next point.
  3. How many users (and their roles) need to touch the DB tables? How granular the access needs to be?
    1. Example: Some customers use various desktop tools that are easy to operate and they give these tools to the hands of the managers. These users are then privileged by definition as well as the number of the people is limited by definition. In that case it can be enough to create a little delta role, that gives this type of access to a several handpicked individuals. Surely this approach will not work in a large organization, but it will work well in the smaller ones.
    2. Note that queries mentioned in the question and the transactions for queries are just a variant of the “desktop tools” mentioned above.
    3. Please consider that if you try to build a concept around access to table group FA (or even based on table names) which is just one of the hundreds of table groups, doesn’t that mean a commitment that you will be careful and super-secure in other areas as well? Balance is an important think (also for Karma…). If you build such a concept because you think it is a good idea, will your colleagues think that as well? In case you get hit by a bus, will there be people that will be able to maintain your concept further and especially – will those people see the need for your super granular access or they change it to same * (star / asterisk) type of approach as soon as you’re gone?
  4. The question specifically mentions queries. Well, queries are very special beasts. Not technically, but the way they are used or misused (organizationally). There are several things about queries we must keep in mind:
    1. Queries are not super friendly from the transporting perspective
    2. People are generally lazy creatures
    3. Users claim (and it may or may not be the truth) that the data are only available in the production system and so they can only create their queries there.
    4. Users claim (same truth problem) that the flexibility of their “questions” (translated into the queries) is very high and that requires them to be flexible as well – they don’t want (or can) spend time on organizational problems – like testing in test system, developing queries in the development system, transporting queries etc.
    5. Sometimes the organization is difficult and transporting based on the forms and workflows and procedures would take weeks to happen as well as weeks would be needed to have the paper-work done.
    6. If you want to do the thing correctly, do the following: you create queries, you test the queries, you create transactions for the queries, you put those transactions into the role menu and you maintain SU24 for those transactions, you’re doing it the way it was designed and meant to be. Of course the question is – can you do it (enough time? Not too many organizational obstacles) and do you want to do it? Too many variables come to play here, there is no universal approach to this challenge.
  5. Let’s say you want to build a concept around the 955 tables in the group (just an example, ok?). The easiest option would be if SAP provided concept there for you. If they could make the problem ten times smaller by splitting one huge group into ten smaller ones, the size of the challenge immediately shrinks. As I said I am not an expert on all the FI tables sitting in group FA. I would not know how to split the tables into 10 groups (random number which would make the maintenance 10x easier if we went this way). I can’t even say if it is possible or wise in this case. Why I am saying all this is that you can theoretically do it yourself. If I am not mistaken, you can reassign the tables to different groups. The problem here is that it is a modification and your hard work will be overwritten with the next upgrade. That is why getting SAP to do it is the only way I see if you concentrate on “I don’t like this table to be in this group” part of the challenge.
    1. Here please consider a different organizational and also a technical aspect. If SAP did this – if they implemented such a “better concept” (whatever that would mean), it would change the behaviour for everyone. Every customer. That could mean customers that don’t want that are also forced to adjust themselves to the new way. It can mean that changes would be required to keep the system running although no change is needed or wanted by the customer. That means I can’t see SAP doing much here (even if it was a wise idea which I cannot judge competently).
  6. If you want to go all the way down to the tables and authorize for them one by one (because your users are used to it for example – well, you caused yourself the problem, do you see it?) the correct approach would be very similar to what I said above about queries:
    1. Define tables to which granular access needs to be granted
    2. Create parameter transactions for these tables (via SM30 or so)
    3. Maintain S_TABU_NAM proposal for the transaction
    4. Use the transactions in the menus of the roles and pull SU24 proposals for them
    5. Enjoy….!
  7. Consider also a different example. Let’s forget about financials for a moment. Let’s talk about table group &NC& for a moment (or the empty value – no assignment – which is translated to &NC& implicitly). Do you understand what the problem is here? Do you understand that the problem with this “group” is much, much bigger than with group FA or any other group?
    1. Go to table TDDAT and search for CCLASS = &NC&. That gives the word “huge” like in “huge problem” a “huge” new meaning.
    2. Check your custom tables. How many of them are assigned no group or the “group for all garbage”?
    3. Why was someone so lazy that he (she) put the table into this crazy group? Why not a better group? Why not a concept behind the thing?
    4. Go to SU24 and look for objects there (not only transactions!) that have &NC& as the proposed value.
    5. Do you understand that if that value gets into a role and that roles is given to users, they have access to dozens of thousands of tables in the system?
    6. Out of curiosity – has any auditor ever told you about this being a problem? Is that on your to-do list to make sure you are all well on this front? You can answer the question either for &NC& or generally the generic table access transactions.
    7. Point for SAP: Take care of the SU24 proposals with this value as well as make sure it is not needed. You know what the risk is, we know what the risk is. Give us the solution. All of us and now. Not that every customer must perform a SU24 clean-up of these magic (cursed) values.


If you made it all the way here, dear reader, also consider that you have the same problem not only with S_TABU_DIS and NAM, but also with S_PROGRAM for example. With S_RFC. With job administration and in many other areas as well. Find and implement the approach that is both secure and pragmatic, so that you can live that approach. So that your team and your organization can live that approach.

What can I say to summarize this in a nice way… Well… hold on. You’re doing it for the brighter future, for your children and their children. They will remember you for being secure and also pragmatic and for choosing the right tools for the right job. Good luck!

SAP delivers attack detection patterns with SAP Enterprise Threat Detection, and in the course of time there will be more. However, you need to have the possibility to get patterns from elsewhere – and sometimes in a hurry. So it is essential that patterns can be easily created using the tools provided by SAP Enterprise Threat Detection.


There are two main steps for creating attack detection patterns. First, you make a series of filters to reduce the stored events to a subset that is of interest. Second, you specify what aspects of this subset you are going to measure and define the attack detection pattern. I am going to focus on the second step so my starting point is shown in the screenshot below.


06-11-2014 12-54-53.jpg

The first filter restricts the set to the events of the last hour, the second filter further restricts the set to events relevant to the security audit log, and the final filter restricts the set to those security audit log events that have an Event ID equal to AU2 (representing failed logon attempts). I could now explore many aspects of this subset but I simply want to create my pattern. So I choose Create Pattern.


06-11-2014 12-56-25.jpg


Let’s say my pattern should be automatically executed every 30 minutes and should generate a low-severity alert when the number of failed logons from any one terminal exceeds 5 in the preceding hour. I enter the relevant details.


06-11-2014 12-57-46.jpg


Now a couple of OK clicks and I am done.


There is no programming knowledge necessary to create an attack detection pattern. For normal people, this is generally a good thing. Creating your patterns is easy enough, so you can focus on the more challenging aspect – finding patterns to create.

With SAP NetWeaver Application Server ABAP 7.40 it is possible to synchronize ABAP Users to a DBMS system especially to SAP HANA . This blog describes the configuration steps that are necessary to set up the functionality and the different features.


Use Cases

  • SAP NetWeaver Business Warehouse (SAP NetWeaver BW), needs a 1:1 user mapping to map analytic privileges of the database to the virtual analysis authorizations of the SAP NetWeaver BW
  • Your users run applications that access the database directly. You must assign privileges to the user in the database.
  • As an ABAP developer, to create SAP HANA objects, you must have a SAP HANA user.
  • Use the DBMS user management function of SAP NetWeaver AS when you have the users of a single, standalone SAP NetWeaver AS ABAP to synchronize with the users of the DBMS.


1. In more complex use cases, use SAP Identity Management (SAP ID Management). Such use cases include the following:

  • You need to distribute user data across a variety of systems in a landscape.
  • You want to synchronize the users of multiple clients of SAP NetWeaver AS ABAP with the underlying DBMS.

2. Currently the possibility to synchronize users to a DBMS system is implemented only for SAP HANA as database system. It is however possible to connect any other database system that is supported by the SAP Neweaver AS ABAP by a customer implementation of the class interface IF_DBMS_USER. The implementation for SAP HANA is done in class CL_DBMS_USER_HDB.


Configuration Steps


1. Create the Database User for the Database Connection

SAP NetWeaver Application Server (SAP NetWeaver AS) uses a database user to perform user management operations on database users. The database user requires the following attributes.

  • The database user must log on with user name and password.

  • The database user has a productive password.

  • You have assigned the database user the following privileges

Necessary authorizations for SAP HANA user administrators:


PrivilegePrivilege TypeDescription
USER ADMINSYSTEMEnables you to maintain users in the DBMS.

Enables you to grant and revoke roles.

Note: This privilege also grants a user in SAP HANA the authorizations to create and delete roles.

CATALOG READSYSTEMEnables you to display role assignments granted by users other than the user created for the database connection, for example the system user _SYS_REPO.
EXECUTE on the procedure GRANT_ACTIVATED_ROLESQLEnables you to grant roles created in the SAP HANA repository to DBMS users.
EXECUTE on the procedure REVOKE_ACTIVATED_ROLESQLEnables you to revoke roles created in the SAP HANA repository to DBMS users.

You can also use several personalized DBMS user administrators instead of one fixed technical user that is configured in the database connection. In this case you need to create DBMS user administrators having the same user name as the ABAP user administrators. In the following step (Setup a database connection) you can select between these 2 options.

2. Add a Database Connection

In transaction DBCO: Add a database connection in table DBCON with Change View “Description of Database Connections”: Overview  for the database user and database type HDB:


Steps in Detail:

  1. Start transaction DBCO.
  2. Choose New Entries.
  3. Enter a name for the database connection.
  4. Enter „HDB“ for the database type.
  5. Enter the name of the DBMS user for the connection.
  6. Enter the password for this user. Note: The password must be productive.
  7. Enter the connection information: <hostname>:<port>.
  8. Save your entries.



Optional: Using a Personalized User Administrator in SAP HANA

If you do not want to use one technical user administrator in SAP HANA you can also define in the database connection that the current ABAP user administrator is authenticated in SAP HANA . Precondition is that the user administrator exists in SAP HANA having exactly the same user name as in the ABAP system and having the authorizations mentioned above. You can then set up the database connection as described in SAP Note 2005856

The current ABAP user is then forwarded to SAP HANA in an assertion ticket.

Alternative Steps in Detail (When Using the Personalized User):

  1. Start transaction DBCO.
  2. Choose New Entries.
  3. Enter a name for the database connection.
  4. Enter „HDB“ for the database type.
  5. Enter <space>as name of the DBMS user for the connection.
  6. Enter any password. (It will not be used)
  7. Enter the connection information: @SSO;HOST=<hostname:port>;DBNAME=<name of DB>
  8. Save your entries.


In both cases we recommend you protect the connection with Secure Sockets Layer (SSL).

For more information, see the SAP HANA Security Guide and SAP Note 1718944

3. Enter Database Connection in Table USR_DBMS_SYSTEM

Enter the name of the database connection and the client in the USR_DBMS_SYSTEM view with Maintain Table View (transaction SM30)


Steps in Detail:

  1. Start transaction SM30.
  2. Enter the USR_DBMS_SYSTEM table and choose Maintain.
  3. Choose New Entries.
  4. Enter the name of the connection and the ABAP client.
  5. Save your entries.


Only customize one ABAP client. The same user ID on different ABAP clients can represent different users with different authorizations. It is not good practice to map user from different clients to the same DBMS user. If you need to support multiple ABAP clients, use SAP Identity Management (SAP ID Management). SAP ID Management has the tools to ensure that users in multiple client represent a single person or identity.

Administration of Users

You can use transaction SU01 for single user maintenance or the ABAP report  RSUSR_DBMS_USERS  for mass synchronization between ABAP and SAP HANA users.


Maintaining Users in ABAP Transaction SU01

In transaction SU01 a new tab named "DBMS" will appear if all configuration steps have been done correctly:


Creation  of Users


Steps in Detail:

  1. Start transaction SU01.
  2. Enter the user name and create the new user.
    NetWeaver Application Server (SAP NetWeaver AS) ABAP enters the given ABAP user ID for the DBMS user ID by default. Not all DBMS systems support the same user IDs as SAP NetWeaver AS ABAP. Other DBMS systems may have other restrictions. You can change the SAP HANA user name if needed. If the user name is left empty no SAP HANA user will be created.  If you desire other default values or blank user names for certain users you can implement the BAdI BADI_DBMS_USERNAME_MAPPING.  See also SAP Note 1927767.
  3. Enter data as required, such as Last Name or Initial Password.
  4. You must also enter an initial password for the DBMS user. 
    Note: SAP NetWeaver AS ABAP and the DBMS have independent security policies. We recommend that you make these security policies as similar as possible. For example: You can create all possible security policies in SAP NetWeaver AS ABAP to match any security policy in SAP HANA. You cannot create all possible security policies in SAP HANA to match any security policy in SAP NetWeaver AS.
    For more information, see chapter 7.1 Password Policy in thehttp://help.sap.com/hana/hana_sec_en.pdf SAP HANA Security Guide.
  5. Save your entries.


Note: There is NO synchronization of productive passwords. As soon as a user changes his password on one side they are out of sync.


Editing Users

Changes to the ABAP user do not effect the DBMS user with the following exceptions:

  • Administrative lock: Locking or unlocking the ABAP user locks or unlocks the DBMS user.
  • Initial password: As the administrator, you set the initial passwords independently. Users change their own passwords in the separate password change facilities of the different systems.
  • You cannot change the DBMS user mapped to the ABAP user directly. You must delete the DBMS user assignment and save before you can assign an existing DBMS user.
  • Assignment of DBMS authorizations
    For SAP HANA, you
    can only add a remove system privileges for privileges that were assigned by the user configured for the database connection. If you try to remove system privileges assigned by a different user, there is no error message. Although the privilege appears to be removed, the next time you view the user in User Management (transaction SU01), the privilege is still assigned. Exception is repository roles, which are always assigned by the user _SYS_REPO. If you have the required privileges you can remove repository roles.


Deleting Users

When deleting an ABAP user, you are prompted to confirm the deletion of a corresponding SAP HANA user if it exists. Choosing Yes deletes the users in both systems.


Using the Report RSUSR_DBMS_USERS

The  report RSUSR_DBMS_USERS allows mass synchronization between ABAP and DBMS users. There are several user selection possibilities to exactly select the ABAP users that shall be synchronized to the DBMS system.  The report documentation in the system  is quite exhaustive. It is recommended to have a look at it.


Please also see SAP Note 1927767 and SAP Note 2068639


Selection criteria for the report:

  • User
  • User type
  • User group
  • Users having a certain ABAP role assigned
  • Users without corresponding SAP HANA users


It is recommended to first start the report in selection mode to check whether the right ABAP users are selected. Then several updates can be run on the DBMS users.


Available functions:

  • Remove mappings to DBMS users
  • Create and map DBMS users. As in SU01 the BAdI BADI_DBMS_USERNAME_MAPPING can be used to configure the name of the DBMS user that is created.
  • Assign DBMS roles
  • Remove DBMS roles
  • Update user attributes   (Such as e-mail and SNC mapping)


Using the Check Report RSUSR_DBMS_USERS_CHECK

When you synchronize database management system (DBMS) user management with SAP NetWeaver Application Server (SAP NetWeaver AS) user management, you must periodically check that the users SAP NetWeaver AS expects are still available.
This can happen, for example, when a database administrator deletes a DBMS user without the SAP NetWeaver AS administrator knowing about it.



Steps in Detail:

  1. Start report RSUSR_DBMS_USERS_CHECK with ABAP: Program Execution (transaction SA38).
  2. Choose Select inconsistent users.
  3. Enter a range of users.
    Note: To reduce the runtime of the report for systems with large numbers of users, you can specify individual user names or ranges to search for inconsistent data.
  4. Choose Execute.
  5. SAP NetWeaver AS ABAP returns the list of users that are inconsistent, if any. These users are SAP NetWeaver AS ABAP users for which a mapping is saved, but the user saved in the mapping does not exist in the DBMS.
  6. Decide how to handle any inconsistent users.
  7. Choose Back F3.

  8. Enter users or ranges of users and select the appropriate action.
    Create the DBMS user: SAP NetWeaver AS ABAP creates a matching DBMS user. The user has an initial password. You must inform the owner of the users about the new DBMS user and the initial password.
    Remove the mapping: SAP NetWeaver AS ABAP deletes the mapping to the missing DBMS user. Any scenarios dependent on that user in both systems no longer work.

  9. Choose Execute.

Otto Gold

On the way to granularity

Posted by Otto Gold Oct 16, 2014

Let’s start with S_TABU_DIS and S_TABU_NAM

We still remember the times when it was not so easy to authorize for generic tools for the access to database tables (transactions such as SE16, SE17, SM30, SM31 or SM34). The only option was the authorization object S_TABU_DIS, which lets one authorize on the level of authorization groups (groups of tables). Just to summarize -> it means that you permit access to a certain group of tables which means that the user can either access all of these tables or none of them. Some people tried tricks with reassigning the tables to different groups

Then S_TABU_NAM object has been introduced which has made it possible to authorize for a single table which was something many MANY (!!) authorizations administrator wanted and prayed for. Now you can maintain parameter transactions for the tables you need to authorize for, maintain the S_TABU_NAM proposal for that parameter transaction in SU24 and via the role menu get the S_TABU_NAM instances all “Standard” in the role.

And how this S_TABU_NAM works exactly? In the module VIEW_AUTHORITY_CHECK, the system checks S_TABU_NAM only if the authorization check on S_TABU_DIS was unsuccessful. This procedure enables both the retention of the previous table access concept and the superposed use of both authorization objects. Notes 1500054 and 1434284 are provided for information regarding the optimum use of this enhancement.

If you build roles via menus and understand the benefit of SU24, you will never give any table access which is not necessary or which you cannot link back to why it had been given when your auditor asks (assuming you understand the “Standard” instance type and know “sun over the mountains” icon and its magic).

Technical details for the interested:

  1. You can see what group the table is assigned in table TDDAT. The combination TABNAME and CCLASS is what you are looking for.
  2. It is probably more convenient for you to find this information somewhere in the SAP standard screens. Then I can recommend you transaction SE11 > provide the name of the table and click “Display”. Then in the main menu Utilities > Assign Authorization Group.
  3. Note that not every table is assigned to a group. Or a meaningful group. Note that table group &NC& is equivalent to “empty value”. Beware of SAP standard SU24 proposals that pull the &NC& value for S_TABU_DIS-DICBERCLS field. But that would be another story.
  4. If you want to learn more about the authorization concept options for generic table access or simply want to have everything describe in one place, please find your way to OSS Note 1434284 - FAQ| Authorization concept for generic table access.
  5. Avoid coding your own S_TABU_* objects’ (all objects in the family) authorization checks at all costs. Use function module VIEW_AUTHORITY_CHECK for this purpose every time. You can see OSS Note 1481950 - New authorization check for generic table access for some details (in combination with 1434284 above!!).
  6. Note: changing authorization group of a standard table is a modification!
  7. Warning: Be careful with banning the S_TABU_DIS object completely. It should not be used as a hardcoded authority check in the SAP standard code any more (if you find it, outside of VIEW_AUTHORITY_CHECK, please inform us about it here!), but you can still find it in TSTCA (check in SE93 – authorizations needed to start a transaction). Because the S_TABU_DIS/ NAM logic is implemented in the VIEW_AUTHORITY_CHECK function module, TSTCA mechanism does not know about it (does not use this way!) and so S_TABU_DIS in TSTCA must still be authorized for using the object not some “friend” object like with DIS and NAM. In case you find TSTCA in SAP standard transactions, you can also consider reporting it here and we can see if we can get rid of it once and for all somehow.
  8. S_TABU_DIS and NAM get a little mention in Frank Buchholz’ blog ABAP Development Standards concerning Security. Unfortunately it does not mention the information about not using S_TABU_* checks hardcoded in the code and the need for VIEW_AUTHORITY_CHECK but maybe you can just believe me on that one.

I must also remind you about the blog by Greg Capps: Reduce the Risk of SAP Direct Table Access.


Then we got S_RFC, RFCTYPE = FUNC

We used to have the same problem with authorizing for S_RFC. You may have noticed that S_RFC gets generated automatically by the PFCG framework when you put a function module into a menu of a role (yes, that works!). Unfortunately what gets generated is a S_RFC instance with RFCTYPE = FUGR. This means that by putting a function module into a menu of a role your role will get S_RFC instance generated which will authorize for all function modules in the function group.

The good news is that there is better granularity possible here since RFCTYPE = FUNC has been introduced. It means you can (MANUALLY!) authorize for a single function module.

It works very much like S_TABU_DIS and NAM: At run time the first check is for the function group executed. If this check fails a second check for the function module is executed. By this behaviour no changes are to be expected during upgrade, but a more granular authority check can be activated on demand. It also share something with S_TCODE – generated entries you cannot edit (because they correspond to the menu entries): Note that the S_RFC standard authorizations discussed in this note are not authorization default values but automatically created start authorizations analogous to S_TCODE. Therefore, they cannot be edited.

If anyone from SAP reads this I would be interested to know if anyone plans to generate S_RFC type FUNC in PFCG either as a default option (after installation or upgrade of the system) or as a default option once a customizing switch is changed (PRGN/SSM_CUST?). That would be wonderful.

Let me share a workaround for type FUNC if you have the time (or the strict requirement) or the urge to make your roles super secure. What you can do is you can manually add new SU24 proposals to the function modules that you want to use (you already are using) in your roles: S_RFC with RFCTYPE = FUNC. Then when you create your role menus and SU24 gets pulled into the authorizations as well as S_RFC RFCTYPE = FUGR gets generated by the PFCG for you, you have the necessary authorization needed to use your functions modules covered twice. Once by FUGR, once by FUNC. Now if you deactivate the instance with RFCTYPE = FUGR, you have a role authorized for S_RFC values which it really needs and not all the function modules that happen to be in the function groups.


Technical details for the interested:

  1. S_RFC type FUNC has been introduced with OSS Note 931251 - Security Note: Authority Check for Function Modules.
  2. OSS Note 1640733 - PFCG: Additional S_RFC authorization describes the mechanism how PFCG generates standard instances for S_RFC object for (remote enabled) function modules in the menu of a role.
  3. OSS Note 1749485 - PFCG: Problems when updating start authorizations mentions the generated instances for S_START and S_SERVICE objects based on the role’s menu entries just like we get for S_RFC.

Anyway I hope you see my point. Just like S_TABU_DIS got more granular with S_TABU_NAM, so did S_RFC (although within one object).


…and now we’ve got S_PROGNAM

And finally… here we are getting to the point why I reminded you about old and known facts above – as an introduction to the “get-more-granular” movement which now has a brand new member. Let me introduce you to S_PROGRAM’s younger brother S_PROGNAM. Please check the spelling to see the difference once again;-).

So what is this new S_PROGNAM? It is a possibility to authorize for individual programs rather than via program groups. Note that you must activate the feature to be able to use it, for existing customers using existing authorization concepts it does not change anything (backwards compatible).

The programmatic submit of reports is secured by the authorization group (old S_PROGRAM) the report is assigned to. In case the authorization group is empty, the report may be executed without an initial authorization check. How I see the new check (if active) it checks your authorizations every time (every time you start a program using the API which also takes care of S_PROGNAM). Which means it does not “just happen” when you call SUBMIT <program> in your custom code. If any of my assumptions is wrong, I will update the texts once I learn the facts (and can cite them via an OSS note).

As a consequence of this new granularity and flexibility you can authorize for only those programs that are really needed and if you work carefully and patiently (and manually), you may get up into a world where S_PROGRAM does not have * in the value and S_PROGNAM is used in combination with SU24 proposals and role menus. Happy hardening (of your security).


Technical details for the interested:

  1. To learn more about the new S_PROGNAM object start with the note 1946079 - Initial Authorization Check in Function SUBMIT_REPORT. Note that this authority check IS OPTIONAL and you must turn it on (see point 3 below).
  2. Note that although this S_PROGNAM object is quite new, it is back-ported all the way to NW 700 SP4 (which a LOOONG time ago!). In case you run an older system, you can consider importing the correction instructions if you can upgrade for whatever reason. If I am not mistaken, by default the mechanism and the object exist in the NetWeaver systems 740 onwards. Try transaction SACF and you will see.
  3. To be able to use the new S_PROGNAM you need to have the SACF transaction (switchable authorizations framework installed first). For more information about what that is you can read OSS Note 1922808 - SACF: FAQ - Supplementary application information and Note 1908870 - SACF: Workbench for switchable authorization scenarios.
  4. To read an interesting discussion about the old S_PROGRAM navigate here: http://scn.sap.com/message/6903382.


P. S.: Rumours have it that we can expect more granularity coming for other objects as well. A candidate that some people are waiting for (like DSAG – German User Group in its materials) is S_GUI that would give the admins the granularity to decide about export / import feature for each program separately. In case anyone has any updates on this one, I would love to hear about it.


Questions for SAP:

1) Will you change the S_RFC behaviour in PFCG? So that PFCG generates S_RFC type FUNC instead of FUGR now when such option is available? Even if you don't make it a mainstream thing for everyone, would you at least consider a switch (PRGN/SSM_CUST) that would let customers switch that on/ change the current default behaviour? Note: we are well aware of the limit on the number of values in a PFCG instance, especially when names of functions are so long.

Update 06/12/2014: 1640733 - PFCG: Additional S_RFC authorization

2) Would you consider an option to check S_TABU_NAM first (before S_TABU_DIS) or provide a switch to do this so that in the authorization trace the more granular access comes first? Then the info which table it was if the check was unsuccessful comes first and makes it easier for the normal and also the lazy to spot the value which must go to SU24/ role in PFCG?).

3) Would you consider cleaning the TSTCA table records to remove S_TABU_DIS from there (as that is not considered for NAM&DIS mechanism because that only works via VIEW_AUTHORITY_CHECK)?

4) Would you tell us why you decided to perform the check on S_TABU_DIS before S_TABU_NAM? Ideally put that into some OSS note (or KBA?) and let us read it there - from the official source.

5) Although it is unlikely, has that ever been considered to retire S_TABU_DIS object one day? Would you consider a switch that would deactivate S_TABU_DIS in the system so that customers can force more granular access only?

6) Can you provide any updates on S_GUI getting more granularity as well? Like when, new object or new field, SACF or standard delivery etc.?


Interesting points from the discussion:

Martin Voros recommends note 2041892 - Logging of call of generic table accesses to your attention.

A bundle of information about the solution can be found at http://scn.sap.com/docs/DOC-58501.


Formalities over, why bother with yet another security product?


I have had the same model of Swiss Army Knife for over thirty years. At the time I got it, it was probably the top of the range model. I worked in research and development for quite a few years and I would have felt naked without it.  Probably all the tools have been used in one way or another, often not for their intended purpose. Usually only a sub-set of the tools got used on a regular basis, and now that I am in software the main tool is the bottle opener. The great thing about such a device is its general purpose nature. You can do almost anything with it and a little imagination. Sometimes you need to do something; you whip it out and its “job done”. Other times though, it’s only better than nothing in an emergency – I would not like to carve roast beef with it, for example. I have sometimes really fumbled and sweated trying to achieve something that with the right tool would have been accomplished in seconds without risk to whatever I was working on.


The same applies to software but people tend to believe otherwise. They are looking for a magic solution to every problem when, in reality, the best you can hope for is to have the right combination of general purpose and specialized tools. SAP Enterprise Threat Detection is like the carving knife in the kitchen – the best tool for its purpose.

I have been following the news on the Shellshock vulnerability the last few days (more information here, here, here, and here) - the vulnerability affects millions of systems and devices. And, a lot of SAP customers run UNIX/Linux systems and consequently have unpatched Bash vulnerabilities that should be patched. But what’s the criticality for SAP customers? Would an SAP customer be vulnerable to application-level attacks taking advantage of this vulnerability? Would an SAP customer with services exposed externally be vulnerable to this type of exploit?


Over the weekend Rob Kelly, a colleague of mine, and I spent some time thinking through security ramifications for our clients; Rob spent some time attempting to exploit this vulnerability at the application level on a NetWeaver Gateway and an ABAP AS system front ended by Web Dispatcher. The good news is, SAP has standardized on the C Shell for a lot of their *NIX scripts, and external services are not script-based. PI/PO developers might use Bash scripts but these normally can't be invoked directly.


The primary consideration for SAP customer is a separation of duties issue. One of the critical technical separation of duties conflicts is that between development and system administration. With this vulnerability, a developer could release code that allowed them to execute arbitrary commands and thus gain system administrator access.


However, SAP customers following the common sense security practices outlined below would already find they have processes in place to address to address this specific risk:


  1. Removing access for Developers to execute OS level commands in production.
    1. The env command used to exploit this vulnerability is defined in SM69 by default; developers should not have access to make modifications in SM69.
    2. Developers shouldn’t have the ability to set up background jobs that would allow them to pass additional parameters.
    3. Don’t forget to remove the ability to run report RSBDCOS0 in SA/SE38.
  2. Addressing infrastructure security
    1. OS-level logins should be restricted to administrators
    2. Restrict the ability to obtain console level access via firewall – do your users need the ability to SSH to your application or database servers?
  3. Following secure software development practices
    1. Run Code Inspector or a like product to ensure input validation for user defined variables being passed to OS Commands (via function module SXPG_COMMAND_EXECUTE, PI/PO scripts, or otherwise).
    2. Have another developer peer review code for workbench requests as part of your change control process.


While the BASH shell should definitely be patched, having these controls in place should mitigate this risk of shellshock being exploited on SAP systems significantly. Practically speaking, most customers can afford to wait to apply this patch in their SAP landscapes during their normal patch maintenance cycle.


What about you? Has anyone else out there explored the implications of the shellshock in their SAP landscapes?


Note: As mentioned in the comments, SAP has released a note on Shellshock: 2072994 - "ShellShock“ vulnerability (CVE-2014-6271).



thanks for joining the Webinar: “Security in an age of Big Data and proliferating Systems”. The recording is available here:



I want to share first the most important links:


SAP Single Sign-On



SAP Identity Management



SAP Enterprise Threat Detection

On October 15, SAP’s new product SAP Enterprise Threat Detection went into ramp-up. Find detailed information about SAP Enterprise Threat Detection here: http://scn.sap.com/docs/DOC-58501. If you are interested in becoming a ramp-up customer, go to the SAP Service Marketplace.


SAP Cloud Identity



SAP Cloud Identity Service



http://service.sap.com/roadmaps --> authentication required



Matthias Kaempfer

This is a close look at the advanced cyber defense portfolio of Telekom and T-Systems.

I once had a long term and intense 3-year project with T-Systems and there are still strong ties between me and the good folks at T-Systems on a personal level.


This made me write this blog, out of the fascination of the topic and the people. By no means - this is no marketing stint, and I have no commercial ties to TSI.  I also promised in one of my last blogs to make a report about the Cyber Center and a lot of people mentioned interest.


Given the old project ties, it is no wonder that in my new long-term security project at a different customer site we

are still in contact and keep talking. I heard of this newly opened, with much media coverage and even more German politician opened “Cyber Defense Center” in the former German capital Bonn (now capital of Deutsche Telekom). It really interested me and I kept researching about the technology behind the story.



I had the chance for a longer talk with Dr. Karl-Friedrich Thier, Senior Security Consultant of the Business Unit Cyber Security at T-Systems International. We talked for nearly two hours about the technology used and the strategies behind the cyber defense center. It is not only used by Deutsche Telekom itself to protect their huge network, but is also available as a service to (usually very large) customers from T-Systems. There is also one operational aspect (Telekom Cyber Defense Center in Bonn) and one service-level, customer aspect (Advanced Cyber Defense as a service by T-Systems)


But why am I so excited about this ACD? It is more than the usual “firewall bigger and higher” or the casual “we handle the largest DDOS”. It is a complete new philosophy of cyber defense and – as opposed to an abstract philosophy – extremely well executed and put into broad practice. The last sentence is my impression.


The idea and intention behind this center and the used software and hardware, project and people is (according to their web site):


“Companies that don't adapt their cyber detection and response capabilities to this threat constantly lag behind the complex and targeted attacks. To free themselves from this risky and frustrating cycle of playing "catch-up," companies need to construct an intelligent security management system that links information from a range of data sources and analyzes it in real time. The goal of this proactive approach is not only to protect the company from known attacks, but also to identify unknown attacks and quickly initiate countermeasures.”


The technology behind the Cyber Defense Center is very diverse and colorful. A lot of tools are used, like different instruments in an orchestra.

It all starts with building situational awareness. Deutsche Telekom operates  around 180 “honeypots” that mimic vulnerable systems around the world which attract all kinds of attackers. By watching and measuring the hacking attempts, you get a pretty good overview of the actual tools used, current attack vectors in favor and organizations using them. The deployed honeypots are actually mostly raspberry PI’s, btw, that are quite cool gadgets.


Watch 180 honeypots live in action



The results are public and can be viewed on the web site http://www.securitydashboard.eu/. In parallel, there is an automated watch of twitter and news feeds for related activity based on used keywords. Here you see in summary in real-time, where actually threats are brewing. Like a weather radar.


The actual network operations and analytics is performed by tools of RSA, which have a huge large-scale portfolio for network operations analytics and threat detection. But it is all thread-based and pattern based.


The “art of security” is, to look for the right patterns to react upon. And this is something you can’t buy – you have to collect and build it yourself over time. And it is constantly changing. This is one major task of every cyber security center. This is the core IP (Intellectual Property) that makes you excel over all other approaches.


Security analytics is complemented by forensic and advanced malware detection tools like FireEye®. Rather than scanning for specific patterns, FireEye executes potential threats in an isolated virtual machine (Sandbox), and monitors its behavior. Like a virus, that is contained and captured in a laboratory section. The attacker, however, doesn’t see a VM but rather a physical workstation or server. One of the cool features is a “time warp” where you can fool “sleeper Trojans” that will sleep for some time before starting.


There are dozen more interesting and used tools of various companies, but they all underline the various aspects of network security

All these tools are nothing without the proverbial orchestration. The core of the cyber defense center is central organization, different present skillsets from analysts to operators and squad leaders that can act on the spot on any actual thread.


The concept of a Security Operation Center SOC




People as success factors


is the mentioned underline in the slide  and this phrase is taken very seriously here in the ADC-concept.


As shown on this picture, it is the staffing and the organization together with the elected software and hardware tools, that makes this Cyber Defense Center so powerful. A lot during the talk with Dr. Thier, we did not discuss software and feature, but how an organization needs to cater to the need of customers. Every customer is different, every customer has other threat and risk areas and there is no “one size fits all”, especially not in security.


The fascination of the setup was, that there was a deep knowledge of security, both commercial as well as governmental at the people involved at T-Systems, and in conjunction with the well selected software and the organizational strength of a large organization, that this all together made a great picture.


The key of all this technology (like the patterns) is how they are applied, the intellectual property behind the tools. This is how it all works well together.


One of the questions that came to my mind is, if regular customers (and even my customers are not really small) would afford such an organization. Probably not, the reduced risk would be in sharp contrast to the big investments in center, people and technology. But I see in the future a convergence of on premise strategies that are self-contained and services like the Advance Defense Center that will like a shell surround the overall strategy.


We will see, how the security strategies everywhere are evolving in the future.


(Disclaimer: This is not a sales pitch, but if you look into a European case of applied security for large networks, this is someone you should talk to or at least, even if you do this on a much smaller scale, you should learn from the big Ones)

UPDATE: SAP Enterprise Threat Detection 1.0 Now Generally Available!!!


On March 16, 2015, SAP Enterprise Threat Detection 1.0 powered by SAP HANA successfully completed the ramp-up phase and is now generally available. At the same time the first service pack SP1 was released, which already includes the feedback of our customers and partners.


For detailed information, see the blog: SAP Enterprise Threat Detection 1.0 - General Availability.




Over the last few years there have been indications of rising interest in SAP systems by white hatters and black hatters, and I guess any color in between. In any case the world has got more dangerous for systems in general, not least because they are increasingly interconnected and exposed in ways that were unthinkable (for most) in the past. Although traditional security solutions remain vital for minimizing the attacks on your system landscape, you can and should assume that there will be unhealthy activity within your defensive perimeters. Determined attackers are likely to get through eventually and the best technical precautions might be nullified by internal personnel or by social engineering tricks.


These are well known dangers, and there appears to be a serious gap in the coverage of SAP systems by existing security products. These lack insight into SAP business software and also run up against what is essentially a big-data problem - that is, how to analyze the security-relevant data that exists in the landscape. Later this year, SAP plans to go into ramp-up with a new product designed to address exactly this issue.


For customers who may be interested in joining the ramp-up, further information can be found at www.service.sap.com/public/rampup on the tab Upcoming Ramp-Ups.


More information on SAP Enterprise Threat Detection will be available here on SCN when it goes into ramp-up.


Filter Blog

By author:
By date:
By tag: