How to securize SE16N

[Former Member]

Hello,

I have securize SE16N with SAP OSS note which is checking SY-TCODE.

Currently if you trying to launch SE16N through SE37, SE38, SA38 SEU_INT or SE93, it checks if you are authorized to SY-TCODE = SE16N.

Despite that, I have still discover that some people have found another way to use SE16N despite my controls set up.

To definitly secure my system, I need to understand how they can proceed. Do you have any idea on how they can do.

The only trace I found in STAT is :

Transaction : SESS Program : RK_SE16N

Thanks for your help.

[Former Member]

Hi Philippe,

Please apply the following SAP Note

Note 597117 - CO-OM tools: SE16N as pure display transaction.

Implement the attached program corrections in your system. Afterwards, the 'View Maintenance' pushbutton is deactivated if you use SE16N as a display transaction.

Please award points.

Regards,

Kiran Kandepalli.

[Former Member]

It is better not to use SE16N at all, better is to create a custom TRX for every table!

[Former Member]

There are so many transactions, reports, etc for displaying and even changing tables in SAP...

Why SE16N is a "taboo" is because it's reputation is ruined by auditors and controllers.

When the system throws an S_DEVELOP check at the user (particularly any for object type DEBUG) it is a warning to them that they might have the possibility to override, or depart from or abruptly exit from logic of the program.

Similarly for S_TABU_DIS, the system is warning that the user might have the possibility to bypass organizational logic which is otherwise in the program reading the table.

This is also the control possibility for security (restricting S_DEVELOP and S_TABU_DIS).

Cheers,

Julius

[Former Member]

Julius

I agree that there are more possible ways of changing data in a table. Or seeing data in tables which the user should not have access to!

But when you look at the better EDP audits you will see that all of them are being checked.

What we also often discover is that due to lack of understanding the problems users have access through back doors by being given roles where S_TABU_DIS is set to value * in combination with very secure roles where because of SE16 S_TABU_DIS is limited.

That is why I still do believe that in most systems SE16 and SE16N should not be given, the custom TRX however is limited to a single Table in a different way so even when S_TABU_DIS is not restricted there is no way a user can get access to a different table.

There are very few SAP administrators that do a regular check on not asigning conflicting roles!

In most situation i see this, it is only done a short while before the auditors come in

[Former Member]

Auke,

I've yet to see a Big4 security work program that covers all the ways to access or change data in a table, but much of that is down to inconsistent use of work programs between territories & also the abilities of the individuals performing the audits. For every one experienced auditor, there are more inexperienced ones who are following a checklist without really understanding what they are checking for.

I also agree that a lot of the problems are due to lack of understanding of the auth concept by those implementing and maintaining that design.

The way I see it is that fundamentally speaking I don't necessarily have a problem with SE16 or SE16N on the proviso that it is secured properly at a role level, at the user level and that due dilligence has been done with the auth groups. It is not exactly a common situation though.

For typical end user applications, like you I will always advocate linking tables to a transaction for the obvious reasons.

I was at a client recently where they copied SE16 to include a check for table name. A custom object was used that had activity, auth group & table name. This allows a reasonably quick way of assigning specific tables to IS staff without having to develop a very granular auth group setup or letting them have access to a huge amount of data. It seemed a reasonably pragmatic approach for that particular situation.

Cheers

Alex

[Former Member]

Hi Auke,

I agree with you. A specific transaction to further restrict the table(s) within the permitted table group is better.

If the choice is made or the fact is accepted that the user (any user, in any client) might be able to submit reports of their choice, select views of their choice or start generic display transactions and select a table of their choice, then SE16N is not the evil it is made out to be - IF the user has the correct authorizations!

>> There are very few SAP administrators that do a regular check on not asigning conflicting roles!

>> In most situation i see this, it is only done a short while before the auditors come in.

That is sad. It is also inconsistent with the notion of having a functioning <b>internal</b> control system.

Certainly, if one concept uses restricted tcode but open s_tabu_dis and s_develop for a role A, and another concept uses generic tcodes but restricted s_tabu_dis and s_develop for a role B, and those two concepts are in the same system and the roles A + B are assigned to the same user ID, then it is doomed from the start.

Cheers,

Julius

[Former Member]

Alex, Julius

To make it worse i recently came across a client were DEBUG was in the general users role, so the possibility to change table data was given to all users!

They were lucky that most users had even less knowlegde of SAP than the people who designed security!!

On the audit remark I agree thst most auditors are persons that have learned a trick without really knowing what to do, anyway that leaves enough work for us!!!

I do educate them if possible!

We also do checks if the administrators have run the control reports and when and the result comes in the management report!

But in most companies the admin functions are heavely understaffed so it really is a management problem. Especailly when everything has run for a large number of years without any problem, management wants to bring down operational costs and creates the problems for them selves!!

[Former Member]

It never fails to surprise me what they have in some places.

It also makes me laugh when a security admin has created a design of such complexity that without them their knowledge, the system would not be maintainable.

[Former Member]

@ Philippe: What is the name of the report shown in STAT which was submitted immediately prior to 'RK_SE16N'?

[fredrik_borlie]

We have made a special tool for our developers, supportpersonnel and basisguys to use.

This works by using the same functionmodel that SE16 uses for displaying the table content.

The tool checks authorization by using the table class and the S_TABU_DIS object.

We let all SS, SC classes right through since they are tables containing system data like source code etc. It does not check S_TABU_DIS on system tables (non transactional data tables).

When a table have a class like PA we can restrict who gets access to the tables by S_TABU_DIS.

Tables that need more protection we set our own table class on so they are not automatically routed through.

Auditors have not yet complained over this solution. It feels like using SE16 so all maintenance people is happy!

/fredrik

[Former Member]

Hello Philippe,

Sorry, this thread has drifted somewhat from your question / problem...

If the STAT shows a report starting with WS... (work bench) immediately prior to the 'RK_SE16N', then you can implement SAP note 1085326, which will force a check on transaction SE80 for entering the work bench tools from navigation.

This "navigation" is a very usefull feature in the system (particularly for developers in development and test systems), but if you dont know about it then it is easy to make "mistakes" in production as well.

Having said that, please remember that the user does have some S_DEVELOP access... which can most likely (Alex and Auke are thinking "hopefully"...:-) be explained by the fact that they have a transaction in their role which is bringing in the S_DEVELOP - and correctly so - which means that chances are very good for them to still submit 'RK_SE16N' to access the tables you want to protect (from that transaction! - for example SE93) and then displaying a report name. So do not neglect S_TABU_DIS or S_DEVELOP when selecting transactions for users, particularly when checked at transaction start (see SE93). It is a warning from the system that your choice in transaction should be questioned...

If you want to, you can also take another measure by protecting the reports (see SAP note 694148 & 835958), but you will have a tough time finding them all....

... so monitoring is very important too.

You seem to have that bit going in the right direction.

"Hat's off" to that!!

Julius

[Former Member]

PS: When you select "long names" in STAT, does it show more about the transaction?

@ the others: I enjoy the lively discussions here

I don't think that starting a separate thread of its own for analyzing auditors and project experiences is necessary... but if you want to drift too far from the question... or get some bigger picture of why / how / what-ever... happens to the security aspect in projects and the aftermath, you want to involve the other aspects (such as PM´s...:-)... or just let off some steam... then SDN already has a forum for this:

Cheers,

Julius

[Former Member]

Hello,

Thanks for all these answers,

Yes - desactivation of SE16N to display is good way, but I need a backdoor (Debug in change mode perhaps) to solve few problems that transport can't solve. SO it can't be the solution immediatly.

Off course, if I ask how to secure it's because it is supposed to be !!!!

So the exercise is not to remove SE16, SE38, etc...

Today I just discover is that they use SE38 with SAPLSE16N which is a function pool (So not executable). I need to understand how they proceed to block them.

Concerning the question on STAT, I am not sure to understand the relation with my problem : Another thread should be better.

PS Julius Long name in STAT shows nothing more than : SESS RK_SE16N

[Former Member]

Hi Philippe,

I dont think that speculating about backdoors further will help you in this case. (we dont even know your release level)

I would recommend that you contact the user in question and ask them how they do this, or they should demonstrate where they starting these objects from. That will be more efficient.

If there is a bug which cannot be controlled via authorizations or setup, or your user has found one which they are using... then the correct procedure is to report it to SAP via "OSS" (Service Marketplace) or via email to 's e c u r i t y ( a t ) s a p ( d o t ) c o m' .

Kind regards,

Julius

[Former Member]

One more thing to add to this discussion:

Errors that happen now and then should never be a reason for giving people day to day access to trx or functions like we discussed.

Best way to solve these issues : Have an emergency userid available!

Procedure:

1. The error should be recorded in the system were all errors are recorded.

2. The whole support team should be consulted to see if there is a solution possible in a regular manner

3. One support team member should be assigned to solve the error.

4. Before execution of the job a clear description should be added to the error rapport listing how the problem will be solved (this should also include the TRX Needed for the solution)

5. The emergency userid should normally be locked . And it should be in separate usergroup (called emerge) which is ONLY accessible for the security team lead. The emergency userid has SAP_ALL and SAP_NEW assigned (allowed only because of the strict procedure!)

6. A senior support manager approves the request to unlock the uid for solving the error. This approval is recorded in the error report including the name of the team member will solve the issue.

7. The emergency uid is unlocked the password given to the team member aforementioned. Time is recorded in the error report. Trace is switched on.

8. The four eyes principle applies here. So the team member is being watched all the time by a second person during the time the emergency uid is being unlocked.

9. Immediately after the error has been solved the emergency uid is being locked again and the password reset.

10. Trace report being read for TRX used, and checked against the scenario (as in point 4) any other trx used should be explained in the error report.

11. All personnel involved should attend a close-out meeting where all points aforementioned should be addressed. And a close-out report should be signed by all and added to the error report.

12. First Audit all error reports should be presented to the auditors for review

Be aware that All points mentioned are mandatory

[Former Member]

Hello,

Thanks for your complete solution.

My interest is really to secure SE16N, I had already implement OSS note 957252 on my message request.

Today I plan to do directly an authority check on TCODE without condition to avoid direct changes in table.

I keep you informed...

On our side we already have a SUPERUSER tool (Home made) which is tracking all changes done our consultants in production system.

But the four eyes principle is for me mandatory on using SE16N in production that's why I need to secure it and allow it on demand with a strong workflow validation.

[Former Member]

I also agree that there is a necessity for an emergency user concept.

That is also an "enabler" for restricting the access of users during normal operations...

>> Today I just discover is that they use SE38 with SAPLSE16N which is

>> a function pool (So not executable). I need to understand how they

>> proceed to block them.

You definately can execute objects in function pools from transaction SE38 etc, IF the user is given the authorization for this... so you can control it in the same system.

Most likely at your release /SP level you will need to restrict authorization for S_DEVELOP object_type 'FUGR' (function groups) using activity '03' (display). If you implement SAP note 587410 than you can distinguish between display (03) and execute (16).

Kind regards,

Julius

[Former Member]

Thanks to you Julius for your interesting proposals.

I finally discovered how they use a backdoor to use SE16N update facilities.

They were going in any function module through system>Status and double click on abap name using the navigation. After they can switch to SE16N_START function module by using button others object. SAP keep in SY-TCODE the initial TCODE.

By removing the conditions in OSS note 957252, my security problem is solved.

It means that removing SE37 transaction from profiles is not enough, additionnal control must be set up if you want to prevent people from executing sensitive function module which do not contain any authority check.

Thanks

[Former Member]

Hi Julius!

Excuse me to write this post, but it is near my question.

We want to log, who display the content of a table.

In SM20 ( audit log ), you can LOG se16, se11, se38, and so on...

If I view a table with SE16, I can see the full generated report name, for example:

Report /1BCDWB/DBEKKO

But if I view a table with SE16N, on the audit log, I just see the SE16N transaction.

So, how can I find, that what is the table name, viewed (not modified) with SE16N.

Thanks for your answers!

[Former Member]

I only know of forensic "tricks" to obtain this information, including the records selected.

For normal operations your friend is S_TABU_DIS and understanding the &NC% mechanism. Once you hand this out, you have lost the table access battle between the developers and the users - in the favour of both of them...

Rather concentrate on preventative mechanisms.

Cheers,

Julius

[Former Member]

Thanks for youe answer.

I only know of forensic "tricks" to obtain this information, including the records selected.

And what are these forensic tricks?

I have no idea how to handle this SE16N problem. There are no user-exit or badi for SE16N.

I read a thread, when you mention that there is a table, which contains the user activity and you can view your activity from SAP standard menü. I watch it, and it only contains 2 record for me. But I did a lot other activity.

Have you got any idea, where can this logging configured?

Unfortunately we have a lot table in &NC& authority class.

Thanks

Peter

[Former Member]

For change mode activities, you can use the standard records from SCU3 and for SE16N's own edit function there are tables in the SE16N_CD* range.

For display only you really have to rely on preventing the user accessing the data, but once they have then they might leave some footprints behind in...

- GOS history (--> see report RSSGOSHIRE)

- The user's Access DB on the frontend terminal (--> Do they access via Citrix environments?)

- Spool requests.

- System log and runtime errors (--> see table SNAP).

- If they navigated from any technical field name to the workbench (--> where-used-list?)

- Emails and other storage media, printer spools.

- The PC's and / or the person's subsequent behaviour.

- Identical behaviour on other PC's in the past...

Cheers,

Julius

[Former Member]

Thanks for the answer.