Sensitive Basis Transactions

[Former Member]

I am looking for a listing of sensitive basis transactions with descriptions of their functionality (more than the TSTCT description), risk associated with them and who should have them in production. I have looked high and low and have found many lists of transactions with the short description, but nothing with much detail. I know this has to exist somewhere, just can't find it.

Thanks!

[Former Member]

Cpollad,

Here are a few transactions that I could think of off the top of my head. I recommend that you work with your BASIS and Tech Teams to identify the reqests for access to any techincal transction and work together to ensure any access is granted has not assumed any risks.

Risk to changing Logical System definations and useage within client configuration

BD54 : Maintain Logical Systems

BDLS : Convert Logical System Names

Risks to changes of OS commands and OS

OS02 : Operating System Configuration

OS03 : Operating System Parameter Changes

OS04 : Local System Configuration

OS05 : Remote System Configuration

Risks to Administer the System Parameters on the system (auditors look at these)

RZ04 : Maintain SAP Instances

RZ10 : Maintain Profile Parameters

RZ11 : Profile Parameter Maintenance

Risks to changing system/enviroment settings and connections

SAINT : Add-On Installation Tool

SCC4 : Client Administation

SCOT : SAPConnect Administration

Risk to activate/execute services

SICF : HTTP Sevice Hierarchy Manitnenance

Change licenseing data pertaining to contracts and functuonality ($$ impact with SAP when audited)

SLICENSE : SAP Licenses Administration

Risk to locking tcodes used for processes/sending messages to all system users/removing required locks for PERNR Objects

SM01 : Lock Transcations

SM02 : System Messages

SM12 : Display & Delete Locks

Thanks.

[Bernhard_SAP]

I think its easier to search for non-critical basis t-codes..... Also the result list will be shorter.

b.rgds, Bernhard

[Former Member]

I agree with Bernhard here. Transactions start with SCC* has highest priority. From the auditing point of view, you should lock them in SM01.

Regards,

Gowrinadh

[jurjen_heeck]

> From the auditing point of view, you should lock them in SM01.

That's the point of view from auditors who do not know the difference between locking transactions and securing functionality. As soon as someone comes to me and demands transactions to be locked he/she instantly looses all credibility.

[Former Member]

I think you missed Bernhard's message as well:

> easier to search for non-critical basis t-codes

= easier to control via the critical objects to use the basis functions, regardless of the tcode or report etc.

You lock authorization objects by not granting access. This is much more reliable and the user will have consistent system behaviour.

Cheers,

Julius

[Former Member]

Thanks for both of you for pointing out.

As a security administrator, when creating the role the first important aspect is to secure the critical objects (like basis, cost center and etc) ,this is what I do.

And regarding locking the transactions, we have external auditors who simply point to the top management that this has to be done. I was involved in 3 audits continuously and every time they simply ask for the list

Always do what client says and "just" recommend them what we think and the best approach is.

Regards,

Gowrinadh

[jurjen_heeck]

> And regarding locking the transactions, we have external auditors who simply point to the top management that this has to be done. I was involved in 3 audits continuously and every time they simply ask for the list

Best tell your top management they're wasting money on incompetent auditors

[Former Member]

Add SA38 and SE16 to the "critical list" and their audit checklists will come to a grinding halt..

Cheers,

Julius

[Former Member]

Julius : Will tell you some thing, please dont freak out.

In our system all the endusers get SE16, about 4000 users. business and managemnet dont like removing SE16 from them..I tried so many times but no luck so i only restricted HR authorization classes.

-AJ

[Former Member]

Nothing necessarily critical about that if they have the correct S_TABU_DIS authorizations and you have no concerns about display access to org. level data.

I maintain SU24 very accurately for S_TABU_DIS. If SAP's "best guess" at an authorization group does not suite mine, then I change it and maintain SU24 to reflect my choice as well.

> please dont freak out.

I'm cool. If a user found their way into SE16, they would not be much the wiser for it.

Cheers,

Julius

[Former Member]

I think having a look at the SAP GRC RAR ruleset makes your job easy. You could review the default ruleset basis tcodes(all critical and non-critical) and assess them according to your client needs.

Thanks

Himadama

[Former Member]

The bugger here is that many "basis tcodes" are report type transactions, they are highly navigable between each other, but generally well written and make consistent checks on the application authorization objects to use them ...

Some of them can only be used in client 000 even and generally need the ability to be application server independent, so they have remote enabled equivalents to the same functionality (which by definition do not include an S_TCODE check..).

Central administration, monitoring and integration make the front-ends almost freely definable, also beyond the server network. For the important ones, the checks on the ABAP user's authority are even performed in the "basis" kernel functions - you cannot even debug those, so they are safe.

Forget about finding all the S_TCODE's if functionality is that sensitive.

Specifically for GRC, see which was my own question how to do it.

Cheers,

Julius

[Former Member]

Forget about finding all the S_TCODE's if functionality is that sensitive.

I agree. There are other auth objects you should consider when defining the sensitivity. You find these combinations If you look at the rule set "Basis_function_permission.txt"file.

I say it would be a good reference and starting point for this task

Thanks,

Himadama

[Former Member]

> I say it would be a good reference and starting point for this task

That is exactly what I would recommend in the mean time. The information was of little use in earlier solutions, so you might find posts of mine which contradict this...

Load the standard rule-set, work on the "low brainers", deactivate the irrelevant ones and add you own.

I can also recommend doing this via management of the file system layer, also for version management. This works very well. You will save yourself a lot of hassle, but unfortunately some project managers always want to have the occupational therapy task of being asked to "click on something in the application" otherwise it is not approved...

The best projects I have had was where the CIO and CFO told everyone that they have to do what Julius tells them...

It is unlikely for this to work easily in large complex organizations and is a real challenge. That is why they get "milked" and / or "sink" into costs on this topic.

Cheers,

Julius