Security Audit - Tracking Program-Code Changes

[Former Member]

Dear all.

I encountered difficulties with the following issues.

Appreciate any help that can be offered.

Thanks in advance.

Our security policy requires that we be able to justify all program code changes.

For changes implemented by Transport Requests (TR), we are already able to trace back to our Change Requests (CR).

So my next step is to identify program changes/creations that were done directly in our production client.

I have tried to look into table REPOSRC for this objective.

Although results from the table entries look promising, I am puzzled by the field RMAND.

We thought the field to contain the client number in which the program was changed/created.

However, we started to notice some numbers which is not known to be our client.

I checked SCC4 and confirmed we do not have those 'unidentified' clients.

I have also changed the change log for the clients-table and there were no changes associated with the 'unidentified clients'

And one more thing, there were some entries where RMAND field is blank.

Does anyone have advice on this RMAND field ?

I understand that for certain SAP Notes, changes to program codes may be implemented directly in production client.

In such scenarios, does anyone have advice how changes can be traced back to the cause ?

I also noticed some programs that go by the following name.

ZCL_TEXTS=====================CM003

Does anyone know what this is and how it comes about ?

Thank you very much.

[mvoros]

Hi,

why do you have direct changes in production client? Now I can't remember if there some special cases where this is necessary but this shouldn't be allowed. All changes in production should come from QA system after proper testing. You should always use SNOTE in development system for implementing OSS notes and transport it to production. The program ZCL_TEXTS=====================CM003 corresponds to class ZCL_TEXTS. SAP keeps separate source code for each method. CM003 corresponds to particular method but I don't know how these names are generated. Regarding field RMAND my guess is that it's the original client. So development is done in many different clients.

Cheers

[Former Member]

Hi Martin,

thanks for your response. Now at least I know what ZCL_TEXTS=====================CM003 encompasses.

Actually, in practice and in policy, we don't make changes directly in production.

However, to conduct a proper audit, I had to scan in production client itself to see if there were indeed changes done there directly. Now, I don't really know how to do this. SAP doesn't seem to include such a function in its AIS to survey program code changes. So I was looking in table REPOSRC. It does tell me the last change date and the person who changed it. But to identify if the changes were done directly in production, I was looking under the RMAND column of REPOSRC table. (I was also looking out for programs created directly in production).

Surveying the table in the above way, I found several entries. Many of them had those weird program names. I am a BASIS person in practice (a junior one at that), so I couldn't tell what those programs were. I understand some programs were auto-generated by SAP itself, so I don't want to look at those. But to do this I needed a way to identify them for sure.

And about the RMAND column, I started to see client numbers which I could not recognise. I checked and confirmed that we don't have those clients numbers before. So now I am beginning to wonder what RMAND column values actually meant. So I wanted to ask if anyone knows with confidence what the RMAND value indicates.

About SAP notes, I was told by our developer that some code changes in SAP notes had to be done directly in the client itself. So if this is the case, then most probably we will be seeing entries in REPOSRC, assuming that is the right table to look at for my purposes. And then I will need to have a way to identify that the changes were attributed to SAP Notes.

My appreciation if you or anyone else have further advice for me.

Thank you very much.

[Former Member]

Normally it is sufficient to user "version management" of the code to check for changes. This however assumes that you have your development authorizations and change management under control.

Some objects are created and generated at runtime. They come from fixed programming contexts which perform these generations, for example the selection screens of transaction SE16 or the "padded" definitions of classes (these are always 30 characters long, so the system inserts ='s to get the length right. You will see the latest generation being your own client and user ID even in the repository ( tables TRDIR / TADIR ) and the loaded program (use view D010SINF if you want to dig that far down) will be the same if this was reconstructed.

For example, SQ01 queries are client specific (and generated to be used from that client) although programs are generally client independent (you can run the same static program for your own client and it returns your own client data).

Therefore, coding which is client specified and accessing data from other clients is suspect. It should be client independent normally, but there are some exceptions.

Given the power of ABAP, your best and most realistic option is to control the authorizations to hobble the coding and do QA checks on the coding coming into the system (for example, via the transport mechanism for developments and a validation of the source for SNOTE patching).

It also makes sense to periodically scan your code for dangerous statements, or include this as a step in your QA procedures. It takes out the "low brainers" --> such as execution of parameter table content text as code from remote callers.

Cheers,

Julius

[mvoros]

Hi,

if you really want to be sure what was changed in production then you can try to implement integrity check similar to old Unix program Tripwire. You can run a custom program which will retrieve a source code for each program in REPOSRC and it will calculate hash. Comparing hashes between two systems will give you a list of all differences. There will be some false positives which you can exclude from next run. Be careful that this program will create load on your production system with level which might not be acceptable

Cheers

[Former Member]

I think you will be flooded by false-positives from screen and other object generators, and if you filter them out then someone with authority to change them (e.g. debugging or editor-calls, etc) will toast the security anyway without you spotting it.

Prevention is better than cure --> code reviews of the generators and input validation of their interfaces.

Some monitoring of the syslog SM21 and developer trace ST11, with alerts, is another more SAP-ish alternative. Defining a variant for known messages and scheduling to output to a spool recipient is easy and fast in terms of reaction time. Or centrally from SolMan with an auto-reaction which turns the lights off for "illegal callers".

Cheers,

Julius

Edited by: Julius Bussche on Sep 13, 2010 6:58 AM