Discussion topic: Wat's the value of a list of 'forbidden' transactions

[jurjen_heeck]

This is not a question in the sense that I want to know which transactions are forbidden/should be locked etc. I've seen my share of lists like that.

In the message I noticed that Auke stated

SE/SA38 are on the list of forbidden transactions in Productive systems.

What I do want to know is everyones opinion on these lists. At my present customers' site I saw one pop up as well and the only thing I could do was shake my head..... because:

1- The list was incomplete in my opinion, listing SE38 but not SE80 for instance, and many more....

2- This particular list was partially a copy-past job and the motivation to declare transactions to be dangerous had no clear relationship to our customers' site.

3- In newer systems the granularity of authorizations in the programs behind "dangerous transactions" becomes better with every release.

4- The list was mentioned in a session about functional design. A stage in which transactions are almost irrelevant to the audience.

In my opinion we (as security folks) would be better equipped with a list of dangerous activities for various sytem types/roles (DEV/QAS/PRD). One of the control measures to prevent those from happening is blocking their transsactions but this would only be one part of the complete control framework.

Benefits of a list of activities instead of transactions include the fact that you can explain them to people who have no SAP experience (yet) and that it will remain usable over various system versions and types (ECC/BI/EP etc).

A list of transactions on one hand often leads to the misperception that blocking those is enough to secure your system while on the other hand people will bypass the blocked transaction and claim they've done nothing wrong.....

What do you think about the subject?

[Former Member]

I'd have to agree that 'forbidden transactions' is a wrong concept. The goal is to deny users to specific activities, ofter represented by a transaction code. People will always associate transactions with their respective activity.

What you would rather have is a statement like 'The user must not be able to change code', and then determine what authorizations to check for various programs. Although authorization checks are more and more moving from the front (transaction) to the back (program), not all activities can be safely locked down that way... yet.

A question back though... if authorization is not being done on program level, is there any failsafe way of blocking access to the activity besides on transaction level?

[jurjen_heeck]

> A question back though... if authorization is not being done on program level, is there any failsafe way of blocking access to the activity besides on transaction level?

Yes, via the authorization group. Text from SAP help screen:

===================

Authorization group to which the program is assigned.

The assignment of a program to an authorization group plays a role when

the system checks whether the user is authorized to:

o Execute a program

Authorization object S_PROGRAM

o Edit a program (-Include) in the ABAP Workbench

Authorization object S_DEVELOP

Programs that are not assigned to an authorization group are not

protected against display and execution.

Security-related programs should, therefore, always be assigned to an

authorization group.

===================

[Former Member]

> Security-related programs should, therefore, always be assigned to an authorization group.

That is a very blunt and rather antiquated approach.

SAP has also (when the opportunity is ripe) redesigned many of their Report type transactions.

The best place for an authority-check to use the coding function which actually does the work, is beyond these blunt tools such as transaction codes, program groups, function groups, services, etc.

In this way the entry points are scalable and the checks are consistent to be used in a sustainable authorization concept where the user has the correct authority to use functionality, almost regardless of the entry point.

That is what transaction SU24 is all about and why you can maintain proposals for various types of entry points (not just the vast number of tcodes). Take a look at the drop-down menu in Su24 and the options on the Menu tab of PFCG which correspond to them and then rethink S_TCODE lists...

In the special case of tcodes you can however turn some checks off in a context sensitive way. This is an exception, to be treated with caution - but for some objects you cannot turn it off at the application layer and for others you cannot turn it off in the kernel either (checks triggered behind ABAP statements, even if you don't check the authority).

Again: There are millions of programs, there are 100's of thousands of function modules, there 10's of thousands of transactions, there are ~ 2500 authorization objects (not all of which are relevent for your implementation...

Take your pick which is easier to administrate and audit....

Where I give Auke full credit, is that if the user is not authorized to use the transaction + all subsequent consequences, then it is rather suspect why they are authorized to start it so obviously....

However you will have a tough time preventing a determined user from submitting reports in a system.

I think I am starting to repeat myself. Perhaps I am wrong....

Cheers,

Julius

[Former Member]

Perhaps what Auke meant is:

> SE/SA38 and etc etc etc etc etc etc etc etc etc etc etc etc etc etc etc etc etc etc etc etc equivalents ...

I dont think that any one person or group will find them all nor should they, and such lists are a joke and knowing what the "forbidden tcodes" are is an invitation to find (or create) an exception.

If you look in transaction SE97 at the "Message" field and the documentation on it's possible values, you will find that there are different levels which go up to "Most Secure" - not "Competely Secure".

If a group of transactions is "Most Secure" and dear to you, then forget about S_TCODE and concentrate on the objects.

If the transaction is highly navigable and meant to be for business flows, then forget about S_TCODE and concentrate on the objects as well.

In both cases there can be exceptions (where the checks can be turned off or are turned off) - for these it is more usefull to look for critical combination or violations of minimum baseline security.

Having said that - most people and certainly end users cannot relate to such design considerations and will only be bothered by it. They want a menu, and to be able to click on it and not be informed about authorization errors because they have full or the correct authority for what they can see.

This is why building roles via the user menu and maintaining SU24 diligently to derive the correct authority is the winner in the long run.

Another thing which goes hand-in-glove with this is training. If someone with correct authority to use SE16N calls the helpdesk to ask for SE17... then this is not a security problem...

My 2 cents to the discussion,

Julius

[Former Member]

basically I do agree with all that has been said here.

a few thoughts to bring into the discussion.

The better auditors do not only look at Dangerous T-Codes but also at authorization objects with certain values, for instance Debug.

Is there a list of transactions already?

Yes in system administration made easy!

Part of that list you can see below

The table below is organized with input from Basis consultants and users and lists

transactions that we recommend you lock. The transactions are categorized by the following risk categories:

< Dangerous

< Security-related

< Performance impact

Transaction Description Dangerous Security Performance

F040 Document Archiving X

F041 Bank Master Data Archiving X

F042 G/L Accounts Archiving X

F043 Customer Archiving X

F044 Vendor Archiving X

F045 Document Archiving X

F046 Transaction Figures Archiving X

GCE2 Profiles: Initial screen X

GCE3 Maintain Authorizations: Object Classes X

KA10 Archive Cost Centers (all) X

KA12 Archive cost centers (plan) X

KA16 Archive cost centers (line items) X

KA17 Archive admin: cost centers (line items) X

KA18 Archive admin: completely cancelled X

doc

KA20 Archive admin: cost centers (all) X

O001 Maintain Users: Initial Screen X

O002 Profiles: Initial Screen X

O016 Maintain Authorizations: Object Classes X

OBR1 Reset Transaction Data X (delete transaction data)

OBZ7 Maintain Users: Initial Screen X

OBZ8 Profiles: Initial screen X

I once have seen an accident with OBR1 so I can tell from own experience what a lot of trouble that was and use that as an example of the list saying that I luckily did not have bad experience with much the rest of the list

this book describes that one should lock these dangerous transactions, i am not in favor of that.

However during my implementations I do advise clients not to have these transactions in either :

u2022 any role given to any user (advise them to use firefighter instead for controlled access ) or

u2022 not to give it to end-users.

I must admit Jurjen that sometimes it is hard to convince clients.

I am not always around long enough after go-live to see things go wrong if they did not follow my advice, but then I think, I do not have to solve the problem also so who cares!!

[Former Member]

If you look in those transactions, you will find an armada of other checks...

- Client needs to be open (T000-CCCORACTIV)

- Company code needs to be unproductive (T001-XPROD)

- S_ARCHIVE checks.

- Maximum authority checks (on * values).

- S_PROGRAM group checks which relate to development work or SPRO activities.

- etc

IS it not more efficient and consistent for security to prevent the use of the transaction (or the report or function module behind it...) than to find all the tcodes, ways of submitting reports, or possible ways of calling function modules (also as other users, either remotely or in job-steps).

My vote: Forget about "forbidden tcode" lists.

Cheers,

Julius

[Former Member]

Julius

although I tend to agree with what you say it makes things far more complicated.

How to convince a client not to give debug access can be pretty hard.

Secondly we need not to forget the damage that some (inexperienced) Functional consultants do.

I recently had a hard job to convince the client not to use ABAP query by end users!

One of the other consultants on the project thought to make his own life simple by not creating the reports the end users needed!

For myself I hold a list of forbidden transactions WITH THE REASON for not granting it, end a number of authorisations that should not given!.

Besides there is always a number of things that are implementation specific.

Like HR being used by a single company in the system thus not allowing other companies in the same system unlimited access to HR!

I allways do a check on * (STAR) values as i rather give all possibel values then a *.

Remeber that most programms auditors use chack on * values given in a number of fileds and do not allow that, the worst of that as we all should know is S_TCODE or field TCD Which should NEVER have a *!

In the end I feel it all bares down again on Knowledge of the security consultant and in that area I have seen too many things go wrong. So for those less experienced consultants I say let them stick to the forbidden transaction list. As that is at least giving a little security!

And for the rest, It is giving us a lot of work to correct the errors others have made and lets be happy for that

[jurjen_heeck]

> For myself I hold a list of forbidden transactions WITH THE REASON for not granting it, end a number of authorisations that should not given!.

Now this reason is the interesting thing because it should be the problem that's listed and not just the solution. Shouldn't it be far better if we had a list of dangerous activities/situations. These in turn come with proper control measures (authority-wise or by logging).

These dangers can be described in such a way auditors without SAP experience can appreciate them as well. "I think we should not allow anyone to change data within a running program" should trigger any IT auditor and have them agree that debugging rights are dangerous.

To my frustration some people kling on to transaction lists without really understanding the implications. That's where the creative guys go seeking (and finding) the backdoors.

[Former Member]

Hi guys,

I see where Auke is coming from in this "next best" or "something is better than nothing" solution which is possible, but that does not make in right or prevent it from breeding more problems and should not be encourages to grow in popularity.

> Auke wrote:

> although I tend to agree with what you say it makes things far more complicated.

Compare the number of authorization objects in SAP (SU21) to the number of transactions(SE93) + reports (SE38) + function modules (SE37) + methods (SE24) + services (SICF) etc etc in SAP and then reconsider which is less complicated and more scalable (for consistent reuse).

> Like HR being used by a single company in the system thus not allowing other companies in the same system unlimited access to HR!

This is also a nice example of why * values or no checks except blunt ones (like S_TCODE or S_PROGRAM) should be avoided as the only security or used with caution if you want to rely on them.

> I allways do a check on * (STAR) values as i rather give all possibel values then a *.

I definately agree with this, but sometimes there is not sufficient time or risk to justify the granularity for some fields.

> In the end I feel it all bares down again on Knowledge of the security consultant and in that area I have seen too many things go wrong. So for those less experienced consultants I say let them stick to the forbidden transaction list. As that is at least giving a little security!

Relying on a little negative list of tcodes to design security is like being a little bit pregnant...

> And for the rest, It is giving us a lot of work to correct the errors others have made and lets be happy for that

I prefer having some time for my family, the garden, SDN, researching something new.... and let a program with a sustainable concept behind it do my work for me

> Jujen wrote:

> To my frustration some people kling on to transaction lists without really understanding the implications. That's where the creative guys go seeking (and finding) the backdoors.

Exactly. That is also were the accidents happen when the real authority protection is neglected in favour of some tcode which only the author knows about... and the user clicks on some strange button, or someone lures them into running the program.

Cheers,

Julius

[Former Member]

Julius

I agree with most of your comments, but we are not living in an ideal world so i am confronted with people who claim to be very experienced and than come up with very poor security designs and i have to convince the client that they have a bad design.

and with many clients presenting a list is helping to convince them!

as many clients have even less knowlegde on security than those bad consultants!

[jurjen_heeck]

>

> and with many clients presenting a list is helping to convince them!

Okay, Auke,

Here's a teaser for you:

When I train people in SAP security or when I respond to SDN threads where people want to take stuff out of SAP_ALL I always explain that SAP security is about allowing stuff, not denying. I will tell new customers the same and how would I fit a list of forbidden transactions into that?

In my opinion transactions can be classified as dangerous and banned for most users but only as part of the control mechanism to minimize other risks. These underlying risks should be listed, not just one part of the control mechanism. That's my present pet peeve, where people declare transactions to be dangerous without knowing any other reason than "it is on the list".

[Former Member]

Jurjen

when I teach Security I do not even mention SAP_ALL other then absolutely forbidden to give in any system. And I do explain the risks!

As I currently join most projects only in a stage when someone else has made a mess out of security, I am confronted with a lot of SAP_ALL users and it takes quite a lot of effort to replace that with good roles.

One of the steps when analyzing the problems is using my forbidden transaction list and see if any of those are in the roles design.

When I see such a thing I go talk with the process designer and ask why the transaction is in that role.

Most of the times I can convince them to remove it from the design.

I do exactly the same with object and values that should not be used.

However that discussion is more difficult as functional consultants normally have no clue what the objects do and are too afraid to have these removed!