SAP & Onapsis Webinar: How to Secure Your SAP Applications Against Modern Ransomware

The Onapsis Blog

The world of business-critical application security is dynamic, with new developments happening on a continuous basis. Check out our blog for recommendations, insights and observations on the latest news for securing your SAP®, Oracle® and Salesforce applications.

Transaction Types and How to Automate SAP User Information System (SUIM) Queries with The Onapsis Platform

Transaction Types and How to Automate SAP User Information System (SUIM) Queries with The Onapsis Platform

One of the most common manual/repetitive tasks that the SAP Security Admin performs is to query SAP’s User Information System (using SUIM tcode). The SAP Security Admin utilizes SUIM in SAP systems manually, one SAP system/client at a time to gather this data for operational use and to report findings internally/externally to Compliance or Audit teams. This can be a time-consuming process.

The solution to this common work efficiency challenge is found in The Onapsis Platform’s capability to automate many of the basic queries that are performed repetitively, the same query week-after-week or month-after-month, and the same query separately performed on multiple SAP Systems. At Onapsis, we call this Automate the Audit. By automating these processes, you gain efficiencies to focus on other important projects.

The Onapsis Platform’s Custom Modules capability gives an Admin the ability to create Scan Jobs on SAP Authorizations, Segregation of Duties, Parameter Settings and key Table values. This ability is similar to what the SAP Security Admin might query manually via the SUIM tcode.  

These Custom Modules are collected into Policies and then executed as Scan Jobs across a Single SAP System or Multiple SAP systems. The scan destinations are determined by The Onapsis Platform Assets or Tags that are associated with the Scan Job. The Scan Job can also be scheduled to run automatically, for example, on a daily, weekly or monthly cadence.

One example Scan Job scenario is an Authorization comparison check to evaluate levels of access to certain functions:

  1. Who has authorization to only monitor Background Jobs that might be running on an SAP system
  2. Who has authorization to modify (release, start, interrupt, cancel) Background Jobs

As part of this analysis, The Onapsis Platform admin might be interested in knowing which users have access to SAP Transaction Code (tcode) SM37. This tcode can be used to monitor Background Jobs which might be processing on your SAP system.

Tcode authorizations are granted to SAP Users through the Authorization Object:  S_TCODE

There is another Authorization Object that is typically paired withSM37. The Authorization Object S_BTCH_ADM.  S_BTCH_ADM determines HOW MUCH access the user has to view or administer a background job. If the BTCADMIN field =Y, then the user is authorized to perform all operations on jobs on the Asset (SID).

Knowing this can be perceived as Sensitive Access, The Onapsis Platform admin can configure a custom module to check which SAP Users have BOTH:

  • Access to tcode SM37
  • Admin Authorization for Batch Jobs

The custom module query could look something like this in The Onapsis Platform Custom Scan Module’s SQL syntax:

SELECT USERS FROM AUTHORIZATIONS WHERE ( S_TCODE[TCD IS 'SM37'] AND S_BTCH_ADM[BTCADMIN IS 'Y')

 

image 1

 

Just to give you some more ideas, you might know that there are two other Authorization Objects which could be important for reviewing the authorizations for the Batch Job Administrators:

S_BTCH_JOB

S_BTCH_NAM

So, another Custom Module query could look at authorization combinations for the tcode and authorization objects S_BTCH_JOB and S_BTCH_NAM. The query syntax could look something like this in The Onapsis Platform:

SELECT USERS FROM AUTHORIZATIONS WHERE ( S_TCODE[TCD IS 'SM37'] AND

S_BTCH_JOB[JOBACTION IN ('DELE','RELE','PLAN')] AND S_BTCH_NAM[BTCUNAME IS '*'] )

 

2

 

Now, let’s dig in even deeper with some advanced analysis and look at the possible results of a query like this.

There is the possibility that your custom scan module might return results for people who have authorization to SM37 or SM37DISP. SM37DISP is a separate tcode with similar but limited functions as SM37 tcode.  

It might cause the question to be raised if this SM37DISP is a “false positive” since it was not included in the query. The question might arise whether the query returning SM37DISP is acting upon either a “CONTAINS” or “STARTS_WITH” operator instead of explicitly an EQUALS operator.

In order to troubleshoot this as a potential false-positive scenario, I set up a similar test scenario to look at tcodes SU01 and SU01D. I assigned various mixes of authorizations to my test users to grant:

  • Only SU01
  • Only SU01D
  • BOTH SU01 and SU01D
  • NEITHER SU01 nor SU01D

I set up a similar test scenario with another set of test users to grant:

  • Only SM37
  • Only SM37DISP
  • BOTH SM37 and SM37DISP
  • NEITHER SM37 nor SM37DISP

Interestingly, in the testing for these two different pairs, the SU01/SU01D test results were different from the results for the SM37/SM37DISP pair. What I noticed specifically is that queries looking for only SU01 would consistently NOT return SU01D tcode. But, custom queries looking for only SM37 would consistently return BOTH SM37 and SM37DISP.

So next, I verified if there was something in the logic of The Onapsis Platform that might be causing the difference. The Onapsis Platform checked out fine with the Onapsis engineering team.

With these rounds of analysis completed, I could conclude that syntax/coding in the Custom Module (STARTS WITH or CONTAINS vs EQUALS) was NOT the root cause.

Next, the Onapsis engineering team dug in a little deeper to help understand why this SM37DISP tcode was showing up.  

The answer is actually due to a different factor that deals with how SAP defines the TYPES of Transaction Codes in an SAP system. With guidance from the Onapsis engineering team, I took a look at the transaction TYPES for these four tcodes.

If you have any experience or training in SAP Security/Authorizations, the topic of transaction code “variants” has probably come up, but it may not have been a major part of your training or focus. However, in this case, it is important to review the topic. I will include some screenshots below as we go along. When administering transaction codes, the SAP Security admin will execute tcode-SE93 to create/change/display the transactions/tcodes that are used in SAP ABAP-based systems.

When creating a tcode, the admin is presented first with a screen to set the tcode type. If you take a look at SM37 and SM37DISP in SE93, you will observe that SM37DISP is a “Transaction Variant” of SM37. So under the ABAP covers, it is still transaction SM37 as seen here from running SE93.

NOTE: SAP has both a “transaction code” field and a “transaction” field, and for this tcode type there is a “transaction variant” field. So, we are stepping into fine lines of distinguishing details here.

3

 

When creating a demo/new tcode (e.g. ZTEST) we can see FIVE types of Transactions that we can make:

  1. Dialog
  2. Report
  3. OO
  4. Variant
  5. Parameter

See here the tcode types from tcode-SE93-create screen dialog

4

 

Using analysis in SE93, we can see that SU01D is NOT a variant of SU01. It is a separate tcode with type “Report”.

56

 

So, what’s next? 

  • Be aware that The Onapsis Platform will return the Transaction, but also, will return that transaction’s Variant Transactions (e.g. SM37DISP) and its Parameter transactions (e.g. OABA)
    • SM37DIS is a Variant Transaction of SM37
    • OABA is a Parameter transaction of SM37
  • If you see a tcode show up in the report that you did not expect to see, check the tcode type via SE93

To return to this core question, was it a “false positive” to report on SM37DISP? Not technically, but the tcode variant is populating into a column that shows all the tcode “Types” in the same column without distinguishing the tcode type, so that may have generated confusion. Once we are aware that the tcode column includes Transactions plus their Variant Transactions and their Parameter Transactions in the same column, we can understand why a report for SM37 will also include SM37DISP and OABA in the output.

Conversely, Report Transactions do stand-alone and are not “tied” to an origin transaction even though they might be named similarly. Recall that SU01D stands alone, and it is not a variant transaction or parameter transaction of SU01.

If you would like to try these scans in your SAP environment, please reach out to your Onapsis representative and we can help you look into scenarios like these. The Onapsis Platform offers many analytical and assessment capabilities to provide insights that you can use to keep your SAP environment secure. Let’s engage and work together to keep your mission-critical applications that run your business protected and in compliance.

View All SAP Security Notes

Secure your 
business-critical SAP,
Oracle, Salesforce
and SaaS apps

Get a firsthand look at the visibility, reporting and automation capabilities provided by The Onapsis Platform by scheduling a personalized demo with our application security experts.

Request a demo