Tuesday, 24 July 2018 14:29

SecurityBridge, trigger event based actions

Rock climbers know, any missed step while preparing for the next climb can mean the difference between to live or to die. This equation also applies to security.

In this blog article, we like to give you one example of how to use the Action Framework integrated within SecurityBrigde, a cybersecurity product for SAP©. For a better understanding of the use-case, we briefly explain the functionality of SecurityBrigde. If you already know the basics, we would recommend to directly go to the use-case. SecurityBridge is the first real-time intrusion detection system for SAP systems on the market. It continuously monitors activities that happen within an SAP instance as they are executed. This can only be achieved through a machine embedded algorithm, which continuously listens to system- and user events and analyses all available logs.

Use-Case, Development keys

SAP development instances, in particular, are focused on by attackers. By gaining development rights SAP authorizations can be elevated relatively easy.  Development systems are also reviewed as part of regular SAP license audits. The more it becomes essential to run a well-managed development stage.

Before a developer can start his/her work, an account is needed. The user needs to have sufficient permissions to perform development. Also, the account needs to have a registered developers key. If you think about granting the developer SAP_ALL instead of using a dedicated hand-carved role using the S_DEVELOP authorisation object, you need to rethink your security concept asap. After that, the SAP user account needs a specific license type, which is derived from the used pricelist but typically is Type "55 - NetWeaver Developer". Now, the developer is ready to process his/her works. Perfect, all set, now the new developer can work! An SAP system instantly maintains the table "DEVACCESS" when the developer enters the key to gain access to the edit-mode of a custom object.

The table DEVACCESS is client-independent and has a rather basic structure. It contains only the username, which has a foreign key relation to the user master), and the developer key, which got generated via the SAP portal.

Challenge

At the time of offboarding, I mean when the developer resigned and had left the company, the account is typically locked by the admin or an automated process. Shortly after that, the account shall be deleted. The deletion of the developer's account will lead to a ghost-entry within the table "DEVACCESS." The entry remains, and links the SSCR key to an account that does not exist in the user-master anymore. Here, you may think, who cares about this entry! Let me explain...

Since the linkage between the SAP user-master and the table "DEVACCESS" was done via the username and not via a hash or GUID (Global Unique Identifier) any new user that will be created with the same name, inherit the active developer-key. This technique can be utilized by an attacker to gain access to your ABAP code base. Once coding can be manipulated, the attacker gained access to a rich toolkit to introduce new vulnerabilities.

The Actions-Framework (AF) enables SecurityBridge customers to instantly reduce the attack surface of your development instances.

 Process IDS Action

The process cannot be more simple! With only two clicks in the configuration, the administrator can define a new Action. The Action can be attached to the user deletion event. Whenever the intrusion detection scanner now detects this specific event, the configured action gets executed, and the table "DEVACCESS" is instantly cleansed. Using the AF of SecurityBridge, and without additional coding in user-exists, SAP systems are secured from ghost entries within the DEVACCESS table.

 

Additional Info

  • Language:: English
Christoph Nagy

Christoph Nagy

I have been working for close to a decade in the SAP area as an in-house- and external consultant.

Email This email address is being protected from spambots. You need JavaScript enabled to view it.