This past year we as an SAP community have had some great discussions around adequate logging in SM19/SM20, e.g.:
http://scn.sap.com/docs/DOC-60743
...and
http://scn.sap.com/community/security/blog/2015/10/05/sap-security-audit-logs-auditor-wants-me-to-sw...
Setting log levels in SM19 and SM20 appropriately is important; I’ve personally be involved in several instances where adequate logging allowed customers to go back and place retroactive mitigating controls to research potential security gaps; for example, we found users access that allowed SODs but we were able demonstrate that it was not taken advantage of by reviewing historical activity.
However, as the internal controls for SAP customers have matured, customers are becoming aware of the external threat sources out there – the black hat hackers, gray hat hackers, and, yes, even state actors with an awareness of SAP and common vulnerabilities that can be used to gain access to systems and sensitive data. External attacks on SAP systems, for the most part, will occur without executing a single transaction code or report. What types of logging can we enable to later identify suspicious network-based activity and, better yet, proactively monitor to alert on attacks as they are happening?
Logging Activity for Critical SAP Services
This list is meant to be comprehensive for the NW ABAP stack; that said if I miss anything please feel free to comment. I come across a lot of SAP customers that have these enabled; that said, I still find systems out there without logging enabled for these services.
The following services should be logged and, ideally, proactively monitored for suspicious activity:
- Ensure SAP Gateway logging is configured. Maintain the profile parameter "gw/logging" with appropriate logging activated in transaction SMGW; more information is available in SAP note 910919.
- Enable SAP message server logging. This is configured via profile parameter ms/audit; I haven’t found good overview notes on this but note 1831927 is helpful.
- ICF logging – in my experience, you can activate at the service level, but a “noisy”, brute-force attack looking for, say, vulnerable Apache or IIS systems (i.e., services that don’t exist in ICF) will not be logged. In this case I’d recommend implementing logging at the Web Dispatcher level if used. This is configured using the parameters icm/HTTP/logging_<xx> and icm/HTTP/logging_client_<xx> within the Web Dispatcher instance(s). More information is available here: https://help.sap.com/saphelp_nwpi711/helpdata/en/48/406e93ca2331c3e10000000a42189d/content.htm
- Ensure table change logging is enabled, especially for the productive client. This is not necessarily focused on external threats but is sometimes missed. This is set via profile parameter rec/client; more information is available in note 1106605. Some customers are reluctant to set this based on older notes that indicate a performance impact; this is worth testing but in my experience, I haven’t detected notable performance impacts on newer systems. And, of course, the performance impact on HANA-based systems is negligible.
- And, of course, don’t forget to enable SM19/SM20 logging. You can always read Frank Buchholz and Ertunga Arsal’s write-ups on these!
Is it critical that I log these? And how much is enough?
The answer, of course, is “it depends”. Many customers out there have a clear compliance mandate to log system activity – PCI, for example, has an entire requirement (Requirement 10 – Track and Monitor all access to network resources and cardholder data) dealing with logging and monitoring. If you have PCI obligations and aren’t logging activity for these services, you are risking this showing up as a finding. And given PCI is a leading practice standard, continually updated based on changes to the threat environment, it’s a great standard that customers concerned with external threats can use to identify
For those of you out there with the Onapsis X1 or OSP platforms or for those considering researching Onapsis, some of these will show up as HIGH or MEDIUM risk issues. That said, if the services in question are available externally, and given risk = impact * likelihood, then your likelihood goes up by orders of magnitude (along with your risk).
