SM20 Reports

Former Member · ‎03-04-2015

Geetings,

We run the SM20 audit log reports each month for DDIC activity when its associated with a terminal name. I understand best practice says to lock DDIC but because it is used for so many automated jobs the Basis group has not had the time to evaluate and simply pulling the plug could have downstream implications that they are affraid of. But I digress.

We run this report for all audit classes/events and all security levels. In the output I get hundreds if not thousands of audit log messages related to the RFC call audit class within the "Severe and Critical" security level:

RFC call Successful RFC Call BDL_DDIF_TABL_GET (Function Group = BDL5)

RFC call Successful RFC Call SALC_UTIL_MT_GET_TREE_LOCAL (Function Group = SALC)

RFC call Successful RFC Call /SDF/EWA_GET_PARAMETER (Function Group = /SDF/EWA)

RFC Call RFC_PING (Function Group = SRFC)

What are the security implications of these types of events? What is so Severe and Critical about these actions? I am trying to filter out as many meaningless or low security events to make the output somewhat reasonable otherwise I have thousands of records to sift through. How accurate is SAP in the assessment of these security levels? Are they being too conservative?

I appreciate whatever guidance you can offer related to this.

Thanks

Mark

Private_Member_69416 · ‎03-05-2015

Hi

Are you sure about example you wrote?

Those audit events are assigned to "non-critical" event class.

Should be marked green in SM20 listing and filtered out with "Severe and Critical"

They don't announce security issue - only info about function executed by RFC.

Those entries can help you with post incident investigation and are feed for external security engines.

Regards

Przemek

Former Member · ‎03-05-2015

Przemek,

That is a very good point that you make. I think there is a bug in the SM20N report. I will try to attach a picture of the output but essentially this is what I see in the output:

Severe and Critical highlighted in green

Only Critical highlighted in yellow

All hightlighted in red

From the main SM20 screen there is a drop down selection related to Events: All, Only Critical, Severe and Critical.. When I select Only Critical, all of the output records are highlighted in red AND the Security level field say All!!

Another example:

When I select Events Severe and Critical I get ouput of Only Critical and All!!

So, is this a problem with our installation or is this an SAP problem? SM20 and SM20N are system deliverd transactions right? It should work out of the box I assume? Is there some configuration or setup that needs to be looked at? In addition, we have 5 instances of SAP and in all 5 SM20 and SM20N behave in the same way.

When I select All events, what exactly does All mean?

Thank you for taking the time to respond to my question.

Mark

Former Member · ‎03-05-2015

Could be a display bug which uses the wrong text. The results are however correct. Which SAP release and kernel are you on?

Cheers,

Julius

Private_Member_69416 · ‎03-06-2015

You have SAP_BASIS version level lower than 7.40

"Security levels" fields have values:

ALL = Critical - Red

Critical = Important - Yelow

Severe and Critical = Non critical - Green

After you will have SAP_BASIS 7.40 security levels will be less confusing:

High = Critical - Red

Medium = Severe - Yelow

Low = Non critical - Green

I hope it is clear for you now.

Former Member · ‎03-06-2015

Julius,

Here is the system info:

1.00.83.00.395718

Kernel 721

Former Member · ‎03-06-2015

Przemyslaw,

Now you tell me!

How did SAP get that backwards?

We have less than 7.4 as you can see in my post so that explains it. Now I need to do what I can to make the output more reasonable and make sense at the same time.

Thanks

Mark

Former Member · ‎03-05-2015

Hi Mark,

It may be a side point, but there is a very document about how to configure SM19/SM20.

Have a look if not already.

Maybe after the configuration is done you wont have these false entries.

Regards,

Adel

Former Member · ‎03-05-2015

You should not (and cannot successfully) admin lock DDIC.

You can reschedule the basis jobs to run under a different step user though to reduce its authorization requirements, but you cannot remove all access or lock it (which amounts to the same).

DDIC is used to perform certain "after import" events in the CTS which activate certain objects, or depending on how the transport is crafted certain function modules will even run as DDIC even if a different user triggered the import or called the RFC which triggered the generation.

You can lock it if you want to prove me wrong, but you will get a bloody nose from it - 100% guaranteed... 🙂

If you are interested, I will post a blog or wiki on the minimum authorizations required by user DDIC so that you can cover what is definitely needed. I have not done it until now, as SAP has been removing some of the hardcoding which has reduced the authorization requirements and also the requirement to know DDIC's password to be able to run some programs as yourself (assumption = if you know DDIC's password, then you could also have run it as DDIC anyway...),but that seems to be stable now on 7.31 systems.

Regarding the audit log: those are the function modules which DDIC needs. Either your basis folks are transporting as DDIC or you have DDIC in RFC connections (very bad idea but not uncommon) or you have set parameter auth/rfc_authority_check to 2 or higher (which recognizes an internal call with the same strictness as an external call)... or all 3 of above, which is causing this "noise".

You must be very careful when making changes in this area as it touches organizational and technical issues which are very deep in the system.

Cheers,

Julius

Former Member · ‎03-05-2015

ps: looking at your log, I will eat my hat if is not the case of a SOLMAN sandbox system which is still "alive" and using DDIC for the RFC calls. DDIC user does not support trusted RFC, so the user is "hardcoded" into the connection with fixed logon data, hence correctly showing up as a successfull RFC call.

In this case critical (even if SAP display interpret it as "all" with "red".. perhaps they made an exception for DDIC to discover such things, as urban legends and convenience to use DDIC for some connections are not uncommon... so it might even be intentional in SM20N...).

From a "hacker" aspect, my first thought is to find the RFC client, because then I can logon as DDIC to the server by simply calling the destination and stopping the program in the call or provoking a dump with connection to user context.

Cheers,

Julius

Colleen · ‎03-05-2015

Hi Julius

You should not (and cannot successfully) admin lock DDIC

I've always locked DDIC down in all clients except 000 -which is where the CTS access is required (or I've seen the background jobs scheduled). Never had an issue as a result. Have I missed something here?

I am, though, chasing Basis and other teams to stop scheduling jobs in Production client under DDIC. Very frustrating to review security change logs where DDIC was the user processing IDOCs from CUA or appearing in other change documents.

Regards

Colleen

Former Member · ‎03-06-2015

In BW you will definitely run into problems as they use this generation feature. They sometimes add table contents which are client specific, even if 000 covers most. It is a lesser evil and DDIC is consistent.

For upgrades DDIC will need SAP_ALL. Do not try it without SAP_ALL and it must be done as DDIC.

The role for DDIC ends up OK if you clean the jobstep users as it has no tcode access and switch user type to SYSTEM so no SAPGui or debugger can be attached. But you need a process for upgrades for the basis team (unavoidable).

So you at the end of the day must have a process for managing the password of DDIC. This is set during the installation now since 7.00 but must be managed (and changed) -> otherwise "noise"...

Cheers,

Julius

Former Member · ‎03-06-2015

Julius,

I bow in deference to your knowledge of this area. It’s extremely helpful to
get a thorough understanding on the nuances surrounding DDIC and SM20.

Some background on me. I am an IT auditor and I inherited this process.
Apparently way before I started here (4 years ago) this discussion must have come up
as a result of SOX testing and the Basis group must have successfully defended
against locking DDIC for the very same reasons you note. The IT Audit Director at the
time understood the situation but PWC wanted some assurances that this activity
was at least being reviewed and it became one of the ITGC’s to run the SM20 log
report each month in each instance and have the Basis group review and sign off on all activity
related to DDIC. If the SM20 output showed that DDIC signed in with reference to
a terminal name or ip address they needed to explain why this was necessary.
They were always able to explain the reasons behind this and the occurrences
seemed minimal considering all the events logged related to that ID. Up until a
few months ago I ran for all audit classes excluding user master changes with
events of Severe and Critical.

Fast forward to 2015 and PWC runs an independent SM20 report from our system
and ran it for all audit classes and events = All. As you can imagine even for
one month worth of activity the number of records was astronomical compared to
running it the way I did. That was when I started taking a closer look at the
log message text and the security levels associated. It didn’t make sense which
brought me here.

I will take you up on your offer to post a blog or wiki on the minimum
authorizations required by user DDIC so that I can confirm we are truly looking
at high risk events and filter out some of the noise to make this report
readable and more accurate. It appears that we probably won’t be able to lock
the ID and for valid reasons.

PS

Is there an OSS note or other governing document that refutes the security
best practice of locking DDIC in production? Every SAP system security related manual
I have read recommends locking this ID in production right after go live as if it’s one of those check the box and be done with it. It really is misleading to do this as you suggest as it could have
greater implications that impact the business. Can I just tell the external auditors that you said it was ok?

Thank you very much for your time.

Regards,

Mark

Former Member · ‎03-06-2015

You have to be very careful with the advice which auditors give you...

I will get around to the blog some time soon and ping this thread. Yes, there is an obscure SAP note about it - will track it down for the blog anyway.

Sure you can tell them that I said it is not only OK but also necessary if the system is to work correctly.

You can also show them this thread and hope for good measure that it gets some traction to counter the urban legend audit advice...

Cheers,

Julius

Colleen · ‎03-10-2015

Hi Julius

For table content scenario - wouldn't that be in client 000 in which DDIC has SAP_ALL and is unlocked?

For updates, that is non-standard situation and in cutover I would have DDIC upgraded and unlocked.

Regards

Colleen