Solving the complexities of SAP account and entitlement reviews

Account and entitlement reviews are essential so that organisations can understand and therefore control exactly who has access to what. Access rights are first assigned by setting up users with accounts for certain applications, according to their role in the organisation. But many applications contain a myriad of functions and store vast swathes of information. Not every user needs access to all the information contained within an application. For example, in a customer relationship management system, a salesperson may need to access customer contact information, but does not need to access the financial records associated with customers.

Therefore, entitlements are set, which manage access rights at a more granular level, limiting what a user can do within a particular application. These should only be granted on a need-to-use basis. But, as an employee’s tenure in an organisation increases, they tend to accrue more and more entitlements – unless regular reviews are conducted to keep entitlements in check and to remove those that are no longer necessary. For example, if an accounts employee who was previously in charge of raising invoices is moved to a position where they are in charge of invoice fulfillment, their entitlement to raise invoices should be removed. If they are not, the organisation could face serious segregation of duties violations.

Therefore, in order to establish appropriate access levels, access reviews are conducted at an entitlement level, rather than merely by user account.

So far so good. But what if the application is not designed that way? This is the case with SAP, which is the top choice for many organisations for managing their business operations and customer relationships. If we translate account and entitlement to SAP parlance we get user accounts, transaction codes and authorisation objects, respectively. With SAP, there are more than 150,000 transaction codes to choose from, each of which has associated authorisation objects – or entitlements – which are needed to perform transactions. There are far fewer authorisation objects available – just some 1,000, which can actually be reduced to just 300 functional groups.

In SAP applications, once a particular transaction is evoked, a check is run to see if the user has the proper authorisation or entitlements to execute that transaction. It cannot see what other entitlements they have for that transaction, nor can it see what transaction will be evoked next, or whether excessive entitlements could lead to a violation in terms of the two transactions that are being conducted one after another. So, if the first transaction is to set up a user account and the second is to authorise a payment to that account, should a user have entitlements that allow that person to create, modify, delete, send out payment and reconcile the account, there is no way of the system flagging that.

With native SAP tools, security audits focus at the transaction layer. With so many transaction codes available, this makes conducting such an audit an extremely complex task and conflicts or excessive entitlements can be missed, leaving security gaps and causing real risks to not be reported. This means that there is no way to discover all authorisations attached to each transaction code in order to root out conflicts or excessive entitlements. If the organisation blindly relies on such audits, there could well be gaps that it has missed.

CSI Tools was founded by auditors who realised the problem and looked to find a way to solve it. SAP applications were designed to improve the efficiency of business processes and to give users the tools they need to get their jobs done. Auditors don’t think like that. They look for checks and balances, inconsistencies and violations. An employee looks for the most efficient way to get the job done; an auditor looks for improprieties.

The tools that CSI Tools offers turn the SAP equation around – back to where it should be. Instead of focusing on transaction codes, which in SAP is an extremely complex undertaking owing to the complexity of the functionality offered in its applications, CSI Tools focuses on the authorisation objects. For any security specialist, that should be a no-brainer. Granting a user access is one thing, but auditing exactly what entitlements they have and therefore what they are actually doing is another.

There has always been a disconnect between IT and security. IT exists to facilitate the business, to ensure that applications are available and running. Security is the police department that ensures that boundaries are adhered to. As security becomes an ever more vital part of the running of the business to ensure that risks are managed effectively, and that governance and compliance requirements are met, IT and security must work hand in hand. This is one example of this in practice.