Protection of SAP Log Files

[Former Member]

Does anyone know of any tools (SAP or third-party) to protect SAP log files (system logs, security audit logs, etc.) from alteration by an authorized user (e.g., someone with SAP_ALL)? We are looking for an audit-friendly method to protect log files such that someone with SAP_ALL privileges (via Firefighter or special SAP userid (DDIC, SAP*)) can't perform actions and then cover up their tracks by deleting log entries etc. For example, we're wondering if any tools exist that enable the automatic export of the log files to a protected area (that's inaccessible to users with SAP privileges)? We'd certainly appreciate any advice or insight as to how to resolve this issue.

Regards,

Gail

[Former Member]

SAP logs by nature are read only. I don't think even SAP_ALL gives you the ability to edit log files.

Thank you,

Partha

[Former Member]

Thanks for your response Partha. When I spoke of "alteration of log files", I was thinking more of deleting the log files or entries within the log files rather than trying to edit them. My assumption is that a knowledgeable user with SAP_ALL (especially if they also have access at the database level) can delete log files/entries. We're interested in any ideas on how to automatically copy off the log files to some area to which the Basis Team (for example) wouldn't have access.

[Former Member]

SM18 will block files "younger" than three days from being deleted. But that is the application layer and SAP_ALL is not.

Why not drop the SAP_ALL?

Plan B would be to restrict the permissions of the sidadm user to a directory where you copy them into but how fast can you do that and how fast is a "knowledgable person"?

Plan C is to use auto-reaction methods to the messages which someone might want to delete. If SAP_ALL is too "holy" then this is my prefered weapon of choice.

It would be very difficult for them to remove all traces and monitoring "skidmarks" certainly helps.

Do you already know what you should be looking for in the logs if they were still there? Just react faster to them in the CCMS (transaction RZ20).

Cheers,

Julius

[WolfgangJanzen]

Just react faster to them in the CCMS (transaction RZ20).
Cheers,
Julius

I like that idea - yes, by subscribing to events one could implement an "alert handler" which simply persists the message on an external (append-only) device. Such an "external copy" could not be tampered by any ABAP user - irregardless of his ABAP permissions. If done properly, not even the OS user sidadm would be able to change / delete the information which has been copied to an external storage device (just think of those old "line printers" - they are truly "append-only").

Cheers, Wolfgang

[cris_hansen]

Hello Gail,

As far as I know, you cannot edit Security Audit Log files; they are binary files and you cannot simply edit them...

I think the same applies to syslog files.

You can also think about OS-level file operations; but usually your regular users will not access the directories/files.

Julius's plans are also nice options. (Thanks Juluis!).

All the best,

Cristiano

[Former Member]

Thanks for everyone's ideas and suggestions. Yes, I too had thought abuot the possibility of using the alert monitor to send an email when certain security-relevant actions occur. That may be our best bet. I did find a thread in the ASUG Security forum on this topic. One person mentioned Cyber-Ark as a possible tool. I may look into that too (although I'm wondering about the cost). If I find out anything interesting (or if we come up with some kind of slick idea), I'll post back.

Best regards,

Gail

[Former Member]

Bugger with it is that external product which are not certified do not respect API's always, so you might never go live or survive a release upgrade with them.

Some products are also only certified that they can be installed without hurting the SAP system, but not to work correctly themselves.

Make sure they use released API's to read the logs.

In comparison CCMS is much easier and works in my experience.

Cheers,

Julius

[Former Member]

For anyone who is interested, I wanted to pass along what we did (this was in response to an audit finding):

First, SAP_ALL access is restricted to monitored Firefighter accounts (we already had that in place). Recognizing that users with SAP_ALL and super-user access at the UNIX level (i.e., our Basis Team) can still circumvent pretty much any measure we take (e.g., can disable alerts in CCMS, delete batch jobs, deactivate Security Audit Log filters, delete Security Audit Log files, etc.), at least the actions would be captured via FF (although they could disable that as well) or other utilities at the UNIX level. And the more things the person has to disable/deactivate, the more likely it becomes that someone would notice that something was amiss.

Our company was already using SPLUNK to capture logs from other (non-SAP) systems so we decided to leverage that to capture and retain certain SAP Security Audit Log entries. We created a batch job on SAP that runs a custom program at 5 minute intervals to extract records from the Security Audit Log files into a UNIX file (the program includes some logic that uses timestamps in the UNIX file to determine which records to extract). The UNIX file is monitored by the UNIX tail-f command which is spawned by a Perl script. The output from the tail-f command is then piped to a file on a central syslog server via the logger command in the script. Finally, a SPLUNK process, which monitors syslog entries, extracts the information into SPLUNK real-time.

This process is not bulletproof as our Basis Team (with SU privileges at the UNIX level) could disable the Perl script or delete/change entries within the UNIX file. All we can really do is make it difficult for them to cover their tracksu2026

Gail