Skip to Content

Realtime Control of SAP Access for Netweaver and HANA

The time of the old paradigm “Safe and Sound by Obfuscation” in SAP Network Security has long time reached an end in all Networks.

But a new design in terms of a secured Network within Software Defined Perimeters is a new way of looking into SAP Networks and User Access.

Once it was safe and easy

In the past (You know, these times, when everything was better anyway) SAP Security was easy.
When you were on premise, admitted by your valuable corporate badge, using your privileged SAPGUI as a proprietary access software as client and accessing a system that only a few people knew (SAP), you could start working.
Nearly no one could cross these boundaries of location and software, SAP was considered safe by obfuscation and unresolvable requirements.
Today, networks are open, vulnerable and unsafe on any level, from afterhours script kids to cyber warriors. And SAP has moved from Lost Island to Downtown with their crown jewels, the most valuable target for every hacker.

The initial answer of the Network Security Department was “castling”. Security in most companies today is realized as firewalls (the higher, the better – on three tiers) and extended to next generation technologies, with pattern recognition and intrusion prevention.

But basically, it is based on the old paradigm: Once you are on premise, you are trusted and you are allowed to do everything. Occasionally, you get restricted, but like Windows, once you are logged in, you are trusted until you log off.

This trust paradigm, this approach to network and application security is no longer valid in these times of cyber-attacks, backdoors and malicious insiders.
It is time to re-phrase the security guideline to the opposite of trust, to mistrust and suspicion:

The SAP Network Of No Trust

Like setting the Apache access rule from AllowAll to DenyAll, this new security approach starts with disabling all clients from access.

Then the new enterprise rules start with rules of who, when and in which context a secure logon is valid. This context should include parameters like working hours, holidays, business rules, SAP user context (From a SAP System like Netweaver or HANA) and Identity context (from Identify Access Management Software).
This context gives for a given time and a given personal context a good proximity, if this context is trusted or not.

Security Software should then either grant or deny this access at a given point in time. This time restriction is crucial. Only if this context is permanently checked (as in “Office hours are over”) the idea of a granular security context is feasible.

There are not many software or appliances today that can deliver this kind of access control in a SAP environment. And while requirements for SAP Netweaver Systems are relatively clear due to their maturity in installation, SAP HANA systems with their vast array of client software, from Excel via Browsers to Eclipse IDE is demanding a complete new point of view to Security in general and access control as a specific requirement.
With our small, SAP Security specialized company, we had some great time in our SAP Lab environment with a company called Cryptzone which had a product called AppGate. If you check their web site, you see in the management board people like Leo Taddeo… (the former Special Agent in Charge of the Special Operations/Cyber Division of the FBI – the guy who took down Silkroad.. ) And their background in international defense organizations as well as common industries shows, that there is more to it than just a new product on the line.

Log Transfer to SAP Enterprise Threat Detection

One sidekick to this kind of appliances/Software is that all information about user activities are logged and can be replicated to Analysis systems like SAP Enterprise Threat Detection. Inside ETD, working with these log files will also adhere to the new standards of European Data Protection laws, since ETD always works with anonymized data, which is key in the near future for all kind of incident researches in European IT systems.

Future of Software Defined Perimeter

The reason to write this here at SAP scn is to show that we will see a complete new line of new security access technologies, when other companies will follow this paradigm. With the expected rise in Software Defined Networks Technologies, this kind of new security thinking will offer new possibilities in future to control access in a much stronger way than before.

Adding more firewalls to your SAP landscape does not really help anymore.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Joachim Rees

    Nice read, thanks for sharing, Holger!

    What I’m wondering, though: if you “include parameters like working hours” how about things like working overtime?

    (or: emergency-fixing something in the middle of the night?)

     

    No longer possible, as after 5 PM, access will be denied?

    This would probably be good for the work/life balance, but I’m not sure if bosses would be all that happy?

     

    best

    Joachim

    (0) 
    1. Holger Stumm Post author

       

      Hi Joachim,

      thanks for the comment. The topic with working hour is just an example. If an employee is working outside his/her working hours, it COULD be an indicator, depending on the business context, the role and the situation (shift worker/clocking time/etc). Outside of working hours, just the risk increases – there is no on/off rule. Therefore it is also important, to have tools like ETD in parallel to look into further context (here in this example, large downloads after hours  as a risk)   .

      Usually, for high priviledged users like admins, there are completely different rolesets. (And normally they do not rely on time 😉 )

      Regards and Thanks

      Holger

       

       

      (1) 

Leave a Reply