Transaction usage report in 4.6B

[stephane_lamarche]

Hi,

I'm trying to get a transaction usage report of the last 3 months out of 4.6B.

Can someone point me in the right direction?

This information is easier to get to in 4.7, but I can't find it in 4.6B.

Please help.

Thanks

[Former Member]

How are your getting it in 4.7?

[diwheeler]

Hi there,

I use 4.6c and I can get it by going to ST03 > Click on the DB server you want to look at, Click on 'single stat records', enter in search criteria and tick. That will give you single stat records...

From memory you can get a summarised list of Transactions accessed if you click on 'detail analysis menu' then select from the options there. Have a play in a dev system and have a look. (I think it goes performance history > one recent period > previous months > pick a month > click on Transaction profile button.

Cheers,

Di

[stephane_lamarche]

Your first suggestion looks promising, but it only gave me about two days worth on stats. There must be a parameter to change to get more. (???).

Your second suggestion is also good, but I have to click on every transaction to know who executed it.

Thanks for the info. I guess I'll try to work with this.

[Former Member]

Hello,

I am wondering if you know which tables I would need to look at in order to view the Transaction Usage detail. For example, how would you find out who executed SE38 on a certain date and what they did with the SE38 Transaction? Did they change a program? If so, which Program and what change?

I have identified that the Transaction Use at the Transaction and User Level, can be pulled from the STAT Files (as you mentioned through ST03). I am unfortunately unable to find anything further.

We are running in 4.7 right now.

Any ideas? I need all the help I can get at this point.

Thanks,

Renee

[stephane_lamarche]

Hi Renee,

You can find the transaction used through SM20 if you guys have activated the security audit in transaction SM19.

SM20 will tell you when it was used and by who, but it will not tell you what has changed.

Table logging would need to be activated to see what has changed. I beleive you can see table history using OY18.

Hope this helps

Stephane

[Former Member]

As mentioned, SM20 is the correct tool for this.

But if you do want more detailed infos beyond it and you are fast enough... then take a look at this thread: ...

and Frank's comment in it:

> The transactions access the statistical data using function SAPWL_READ_STATISTIC_FILES (but take care: this function is not a public interface and may be replaced or changed at any time).

Cheers,

Julius

[Former Member]

Hi Stephane,

Thanks so much for the quick response. I have one additional question regarding the logged Tables.

Do you happen to know which tables should be flagged as "logged" for Auditing SE38 access? I was able to pull SE38 Transaction Use through SM20 and ST03, however, I am still not able to see the data at a lower level. What did the user do with the Transaction?

I found a thread on another blog that also pertains to the information that I am looking for. Please see below:

SE38 Transaction Usage Revisited

Asked by MarkD on 4/30/2007 10:21:00 PM

Greetings once again. I know we beat the heck out of securing

this transaction but what detective controls are in place to

monitor usage for those who are authorized to use it? For

instance is there a log or a table that will tell me what

programs were created or changed, when and by who? Would there

be a table we can turn the logging on or some change control

report like what is available in SUIM? Thanks

My Main goal is to find a way to Monitor SE38 Use in a production environment, using 4.7. I am sure that there are many other companies that are required to implement monitoring controls for SE38, due to SOX Audits. Surely, someone else has done this before. : )

Thanks in advance for any help that you can offer.

Regards,

Renee O'Shea

[Former Member]

Thanks Julius. I'll take a look into it and let you know the outcome.

Best Regards,

Renee

[stephane_lamarche]

Renee,

I don't think that activating logging on a any perticular table will give you the information you want. SE38 is a transaction that can be used to access any programs and you would have to start logging on all the tables if you want to track any changes within any tables. Hope this makes sense!

[Former Member]

> I don't think that activating logging on a any perticular table will give you the information you want.

I don't think that only restricting SE38 will solve it either... particularly on a 4.6B system (out of mainstream support...)

> SE38 is a transaction that can be used to access any programs and you would have to start logging on all the tables if you want to track any changes within any tables.

Not exactly like that.

You can also restrict groups of programs (using S_PROGRAM) and the programs themselves make the majority of the checks on a vaste range of objects anyway, which will determine what the user can do.

I would estimate that based on the modularization of programs and number of checks you can rely on, you are looking at something like:

- Start the transaction => 1% security.

- Start the program => 2% security.

- Complete the program successfully => 97% of the security.

Cheers,

Julius

[stephane_lamarche]

Julius,

I was trying to respond to Renee's question. She's on 4.7, not 46B...

She doesn't want to restrict it, she wants to find out what people or doing inside SE38.

Is this correct Renee?

[Former Member]

Yes Julius, that is correct.

I have a Team that has SE38 access in Production for DEBUG purposes, in combination with a Dev Key for the installation. Even though the users cannot make any changes to Programs directly in Prod, the risk is that a user could potentially create and/or change a Program in the Dev environment, push it to Prod via Transport and then execute the Program in Prod. We are currently in the process of streamlining our DEBUG Role, to only include the Program Auth Groups (as defined by S_PROGRAM) that are truly needed.

Once we have the Role set up appropriately, this will still be a SOX deficiency, unless we can Monitor what the user actually does with the SE38 access.

We are in 4.7 right now and will be upgrading to ECC 6.0 later next year. Our current program (FoxT Behavior Analysis - External Vendor Tool) will only pull Transaction Use at the Transaction Start level. This is the same data that I have determined can be pulled through SM20, ST03 and AL11.

I need to know how to Monitor SE38. What controls can I put in place to ensure the transaction is not being used inappropriately? I am being asked to identify the Tables where the data is stored, so that we can look at possibly building a query / custom program to pull the related information for SE38 use.

Any thoughts?

Regards,

Renee

[Former Member]

Sorry, the intra-question with release dependencies got mixed up.

In higher releases, you can log the start of reports via SM20 (Security Audit Log), so an option is to create "emergency users" who are logged for this when such events are required for debugging.

In older releases, there was a way to find out who has displayed which program (not only limited to SE38) as this would have been done to set break-points, but now you are really raking my brain to remember the name of the table as I don't have access to a 46B system anymore.

The ABAP editor was a report type transaction, and if you drill down further into it or debug it itself then you might still be able to find that table. I thing is was a SEU* name, but am not sure.

But that still doesn't solve the question really, and the table seemed to have disappeared in release 6.10 and I did not find a replacement back then.

The rest of your question is a much bigger one about restricting the risks, and design of how the user accesses the ABAP system (the entry points) and which access they have.

Actually, debugging programs from SE38 has disadvantages, because the transaction context for the real scenario is missing...!!... and this can have an influence on the behaviour of many transactions, including security relevant behaviour (which will affect the debugger as well).

This is a big question. I would like to think about it for a while and then post my views on it.

Cheers,

Julius

[ashley_kenealy]

Hi Renee,

Granting access to transactions like SE38, SA38, SE37, SE80, etc... in production systems is loaded with potential risks.

In our productive systems we do not allow anyone (and this includes the Basis/Security team!!) to have transactions like SE38, all reports must be executed via a Z tcode or an Area Menu. Access to SE38 is granted only in emergency situations, must be approved by management and a user trace must be activated. If you take this approach, monitoring SE38 usage becomes simpler => ST03, SM20, SM21 will tell you what reports have been run and ST05/ST01 traces can tell what tables were touched (if you are lucky and table logging is switch on for the relevant tables you can even get what entries were changed)

Also note that access to SE38 and access to be able DEBUG are two seperate security requirements, DEBUG can be granted independently from SE38. In production we allow DEBUG (display) access for our support teams (this caters for Julius' reference to disadvantages for debugging programs directly with SE38), while access to DEBUG (change) is granted only in an emergency.

This topic is huge (don't get me started on SE16 and what we have to do to secure it!!!) and can't be completely covered in a forum such as this. We spent many months restricting access in areas like SE38, SE80, SE16, etc.. and we still find holes every so often, but that is the nature of SAP.

I hope this has helped in some way.

Regards

Ashley

[Former Member]

Thank you Ashley!

What you have done in your systems in very admirable - although I know some folks who claim that if you lock down people's access to such an extent that they become inflexible (e.g. cannot start arbitrary reports of their choice)... then it motivates them more to find those loop-holes you refer to which appear from time to time, instead of keeping them blissfully ignorant. I am not one of those folks though, and don't believe in "security in obscurity" because I am sure that someone who enters the system with malice or fraudulent intentions will not care about it either...

2 "gotchas" with reports are those intended only for background jobs and therefore don't have a transaction code to start them, necessarily. I guess it is not that difficult to create one, and there is also the possibility to debug programs scheduled in SM37 using the job-debugger (JDBG).

The other is that some standard reports are delivered without a transaction code to start them, or at least none which is obvious. Again, I guess one could easily create a transaction to start the report if there is intention to use it periodically.

I think much of this new awareness (and legal requirements) came long after the ABAP reporting itself was invented, and this causes some teething problems and a transition phase in the SAP world.

In very early days, there was nothing to stop a user from running a report... (except the checks in the report itself). Those were "the good old days"...

Then came SA38 for ABAP reporting purposes and ABAP itself (as it's German acronym hints at) was for customers to create additional reporting outputs... (ha ha ha :-).

The best (and most consistent) security is still that each program (including function modules, particularly if they are remote enabled and methods) perform the the correct authority-checks which are niether too weak nor too strict, because this mitigates many of the risks when answering the "what if the user can break out of the tcode?" question. This is one of the reasons why I am a big BAPI fan (see transaction BAPI).

To me it seems that the greater the risk of starting reports is percieved to be, the less confidence in the quality of the programming is hiding behind it. This is true of programs from all name ranges.

My 2 cents,

Julius