When talking about IT control standards, ISACA is one of the top reference organizations. For people in the “audit & controls” world, ISACA is a common word. For those who don’t know, ISACA is an independent, nonprofit organization focused on the development of industry-leading knowledge and practices for information systems. ISACA released a new version of its SAP security guide Security, Audit and Control Features – SAP ERP 4th Edition, which is a very complete guide to audit different processes in SAP from a technical point of view.
Even though SAP has more than 10,000 standard transactions, all companies create their own custom ones. There are different reasons for building custom transactions. For example, a user might need a specific report, a list, or a functionality that isn't in the system. Sometimes there are even cases where custom transactions with identical functionality of an existing standard transaction are created. Creating custom transactions isn't a problem, it is a normal usage of the system.
SAP has its own specific JAVA virtual machine implementation called SAPJVM, which according to SAP documentation: "...is derived from Sun’s HotSpot VM and JDK implementation ... the SAP JVM is only targeting server-side applications. Certain features related to client environments are intentionally omitted or are not supported for general use.".
Authorization groups are a difficult topic to tackle in SAP as they can be considered a double-edged sword. With proper implementation it’s possible to take security to the next level, however if not properly implemented, authorization groups can lead to usage issues and can create a false sense of security. These problems arise due to different reasons:
The world of profile parameters in SAP is vast and complicated as a user can change the entire behavior of the SAP by modifying some of these parameters. But just when we thought that we knew everything about profile parameters, we recently discovered something very interesting. SAP Security Note 1979454 is related to a vulnerability in transaction SHDB (a very sensitive transaction since it’s used to create recordings) which introduced a new profile parameter called “bdc/shdb/auth_check”.
Enforcing a new password policy on an SAP system isn't always an easy task. Most of the existing SAP implementations have been running in production for many years, and since that moment SAP password-related profile parameters evolved to provide enhanced security based on the complex and always changing compliance requirements (SOX, PCI, HIPAA, etc). The problem is, basically, the fact that by default user passwords are compliant to the policies only when created/changed. If the user is never forced to change the password they could potentially have ever-lasting non-compliant passwords.
This week SAP published a paper with the Monthly SAP Notes titled Securing Remote Function Calls (RFC) which outlines guidelines on the best practices to configure different RFC security features. In this post we will focus on two of the newest features in the paper: