How to control rogue programmers?

[former_member229314]

Hello all!

Does anyone know how to reign in rogue programmers, short of locking their user IDs?

What we notice in our development system is 'on-the-fly' code execution, i.e. malicious code that does not get saved and activated first, but executed immediately from within the ABAP editor, SE38.

Is there a way to block 'on-the-fly' program runs?

A second method used is to temporarily overwrite a legitimate customer program they are supposed to be working on, with suspicious code, save, activate, and run that, and then put the original code back.

Either way, we have no trace of the code that was actually executed in the system.

Any suggestions?

Thanks,

Ruben

[Former Member]

you cannot restrict evil will by adjusting your system or your authorizations. if they are really good they will find out about a special function module (the name of which i will not put here but might give you in an e-mail) which would allow them to grant a SAP_ALL to their UserID again. if you start out on that road, you are on the losing side whatever good the intention.

that leaves controlling them. hard work. you could consider setting up SM19/SM20 which will allow you to monitor their doings a bit more closely (except for the running without saving bit) but then you would have to run through the logs all the time and be watching.

but then, maybe it'll help identify the culprits and have them sacked? worth a try?

but clearly you should have a couple of words with your management about your observations ...

[Former Member]

Only solution is to block them and then tell them they are sacked.

By the way block them, before telling them they are sacked, we had a hacking program once, while we told the person first before sacking!!!

Edited by: Auke Visser on Feb 6, 2008 7:49 PM

Edited by: Auke Visser on Feb 6, 2008 7:50 PM

[Former Member]

Using Security Audit Logs, and CCMS Log agents, you can monitor the Security audit logs for any text string you have identified as relavant.

The CCMS Log agent will alert you if that text string is found in the Security Audit logs so you do not have to watch it.

Security Audit logs cannot be deleted using SM18 for at least 3 days. (protect delete access at the OS level)

I agree that you cannot completely control a developer in a development system and I am not sure you would want to.

[Former Member]

Hello Ruben,

I agree with the comments of the above posters about the power of organizational measures (after all, you would want a qualified and experienced surgeon to operate on you, and developers also have a reputation and perhaps even a job to loose), but to add a few small comments:

- It helps the developers and you if you have developer guidelines and security requirements for development work. This way you also have something to hold them against for having bent any rules.

- Bypassing security is not only limited to one function module, and not only to function modules.

- Though it helps, identifying users with developer access is not only limited to those who have developer keys (entries in table DEVACCESS). Take a look at the Tips&Tricks report in transaction SE30 and others which check the modifiable / not modifiable status of the system and the client(s). See [this thread|; for more search terms.

- In a development system you will most likely be unsuccessfull using the above controls. You can use restrictions to object S_DEVELOP (the fields have changed in higher releases and there have been some posts here about the package concept for organizing development work which sounds very promising). See [this thread|; and [this one|; for further infos.

- Writing rogue programs is one thing, being able to import them or upload them into other systems is another category. There is a well known program which did the rounds for a while and might still possibly be found in some systems. It often has the name ZABAPUP, or if renamed, then you can sometimes find various copies of it by searching for the string "INSERT REPORT" in customer programs (you can use report RPR_SCAN_ABAP_SOURCE for that). If found, you should secure it, or preferably delete it completely.

In some "systems" I have been involved with, I have worked closely together with developers and raised security awareness. They can also be your best allies in security matters, particularly so if they understand the system and know about some of the "hacks".

Cheers and good luck,

Julius