The Missing Link: Compliance at the Code Level
- by Andreas Wiegenstein, CTO, Virtual Forge
- Mark Schumacher, Software Security Expert
- Sebastian Schinzel, Security Consultant, Virtual Forge
- October 15, 2008
Establishing security processes, developer training, and tools right from day one of development projects leads to initially higher investments. However, the savings resulting from lower cost for corrections and lower risk for cyber attacks in the final product are going to outweigh the initial investments substantially. See some examples of insecure code issues and some ways you can solve GRC problems at the code level.
Mastering security in SAP landscapes is a big challenge. While roles and authorizations, encryption, and single sign-on are well-established practices, security issues at the code level are often neglected. Bad code can lead to vulnerabilities such as backdoors, elevation of privileges, and data manipulation. This in turn can lead to violations of regulations such as Sarbanes-Oxley, Payment Card Industry Data Security Standard, and data protection laws.
Bad code can lead to compliance violations. What’s bad code? Many SAP customers develop vast amounts of custom code (e.g., in the HCM, Financials, or retail area). That can lead to severe issues:
- Experience shows that such code usually contains flaws and bugs
- An attacker can use vulnerability at the code level to bypass role concepts
- Attackers can call critical transactions, thus impersonating other users
- Attackers can change or delete critical business data
In this context, bad means that the application shows unexpected and unwanted side-effects, namely the exposure to attackers (either external or internal). A tool cannot detect these problems. For example, SAP solutions for GRC primarily focus on the authorization concepts and not on the implementation at the code level.
We’ll elaborate on the problem and provide examples in the Sarbanes-Oxley, Payment Card Industry Data Security Standard (PCI-DSS), and data protection context. We also show how to solve the insecure code problem: by ensuring that the software development process covers security and compliance requirements. Independent testing proves whether those requirements are met. That way, SAP users can effectively close this gap in their SAP landscape.
Would you like to see this full item?