I recently held a conversation with a highly-experienced risk manager from one of our valued customers. As we were discussing the topic of development it dawned on me that this subject is often neglected by risk managers – despite the fact that development issues are a major potential for business risk.
What I mean by development are the codes added to the standard ERP package, including isolated own-developed programs and reports, user exits (term in SAP), enhancements and code snippets.
I must say it was a very productive discussion and I came out identifying the following key standards risk managers should require of developers.
1. Avoid Bad Coding in Production
Nothing good can come of bad coding. If your company has not yet defined appropriate programming standards, you may end up with mediocre coding. Bad coding calls for hackers and bored programmers (next week’s blog will convey the adventures and consequences of a bored programmer). Furthermore, bad coding easily increases the probability of mistakes even if just through normal use. Risk managers should insist on a well-managed process for transferring codes from the development environment to production systems, including testing (unit and functional) and code review.
In addition, make sure that every programmer and code-changer is obligated to comply with these standards. I’ve often seen senior programmers who transfer codes to the production environment on their own, bypassing the recommended procedures set in the company. Although these codes may be fine, a well-managed process means that procedures are followed by everyone, at all times.
2. Authorization Check for Enhanced Protection
An authorization check essentially serves as the gatekeeper protecting the system from unauthorized use (in SAP the ABAP command for this is AUTHORITY-CHECK). Hence, an authorization check should be added to any sensitive path in the program. For example when displaying the population, right before issuing an invoice in the code, prior to altering the database, etc.
Be prepared for justifications on the programmers’ side. They may excuse the lack of authorization checks by claiming that a program is private and should be used only once by a specific person. That being said, make sure to stick to the standard; authorization checks must always be added before a program is transferred to the productive environment.
3. Monitor Access to Production Systems
There are various reasons for why developers login to the production environment. Most of them are legitimate, such as checking performance of the codes, fixing bugs, etc. However, in many cases developers will not stop there. Furthermore, bored programmers are likely to start poking around looking for interesting information as invoice amounts, high salaries, and yes, you can definitely let your imagination take you from here.
Access to production systems should be granted if (and only if) there is a genuine reason for it. In any case, developers should be monitored while in the production environment in order to ensure ongoing security and control, as well as enabling future inspection if needed.
By ensuring that developers stick to these easy-to-follow norms, risk managers are certain to benefit from a significantly lower chance for risk alongside enhanced security throughout their organization.
Visit again next week to read about the full adventures of the bored programmer. I promise to also suggest an effective way to handle the “adventurous type” in a way that enables justified access to the production environment, yet ensures no breach in security.