SAP Security Beyond Authorizations

by Steve Lord (Technical Director, Mandalorian)

SAP Security – SAP’s an expensive enterprise solution, so those words must go together, right? You’d be surprised how many people think that security comes ‘as standard’ with SAP. In actual fact whilst a default SAP instance could be considered secure (albeit unusable) the onus is placed upon the authorisations team, the basis team and the programmers to ensure that the system is secure in deployment.

The problem is, it usually isn’t.

Consider offshoring customization. In theory it sounds like a great way of saving money (if you’re an integrator or an end-user), but in actual fact you may get more than what you’ve bargained for. Even if you lock that development environment down, the fact remains that your developers are going to be able to execute code at the OS Level, gain direct access to the underlying database and run rings around most authorization settings that you can imagine if you’re going to let them do their job. Tools such as Virsa ComplianceOne go some way towards addressing these issues but unless properly configured, your auditors will still scream about Segregation of Duties, General Computer Controls and Critical Combinations as they only go part way towards resolving the underlying issues. The root cause of the problem is that many integrators approach the security of an SAP implementation as a single headed problem. There’s more to consider than SAP itself.

For example, in an Oracle-based Unix deployment, the SAP instance account will use an External Oracle account. This means that Oracle relies upon the user authenticating to the OS in order to gain access to the database. This makes some sense, after all this means that SQL scripts can be run without having to re-authenticate to the database and potentially leaving passwords lying around the system. However, there is a fundamental weakness in this configuration, namely that anyone with the ability to execute commands on the application server does so as that authenticated OS user, namely the SAP instance user. So an attacker with developer access could write out an SQL script to update Oracle tables in order to escalate their own privileges within SAP and then use a myriad of methods to execute the SQL script from within SAP without authenticating to the underlying system.

When implementing SAP it’s important to realise that within SAP, security starts with authorizations, but doesn’t end there. An SAP implementation requires security consideration at the OS, Database and Network level as well as within SAP itself. Thankfully, we’re not alone. Some smart folks over at the Centre for Internet Security (http://www.cisecurity.org) have come up with benchmarking tools and guides for most operating systems and databases that are supported by SAP. If people followed even some of the advice in these guides, my job would be a lot more difficult. By going through their benchmarks, you should get an idea of what ‘best practice’ really means and by working through implementing what is feasible, your position on OS and Database security will be a lot stronger.

www.mandalorian.co.uk