Least Privilege: Stand Up For Your Principles!

One of the most ubiquitous terms in information security, the principle of least privilege is used in SAP just as much as it is applied across other IT systems.

This principle is widely considered appropriate in SAP systems as it aligns well with the way in which we allocate authorisations to the roles and users. Because SAP authorisations are additive, we start with a blank slate and add the transactions and authorisations to the role, building up a profile which should only contain what’s needed to complete the task or job the role is built for. We cannot add something to the role which restricts what a user can do (for the most part).

In theory, that sounds like the best case security principle to operate from. However, that principle often gets diluted over time. We usually come across this situation in implementations which have grown organically, with access creep and continuous change in environments chipping away at the principled design, until an amalgamation of authorisation is granted which no longer conforms to these principles.

This kind of organic departure from principle can be especially prevalent where security is handled by implementation partners or internal organisations which do not “think security”, like those which are part of a BASIS function, or with a focus on incident resolution, often without the luxury of time or, occasionally the interest in seeking design signoff or approval.

The problem, of course, is one of cost and time – building with least privilege requires designs to be robust, the testing and re-testing of authorisations and can increase time to delivery, or time to resolve incidents. This, understandably, can lead organisations to look for other ways to achieve compliant systems and user accesses.

The most highly regarded security design from a business perspective is one which is invisible to them. Users should have sufficient access to get their job done without impingement. Authorisation failures cause business pain points as they immediately stop the business user from completing the tasks at hand. When you add in the time lost from productive operations, the time taken to log, investigate, resolve and implement the fix, it can be costly to operate at a truly least privilege state. Additionally, any business process innovation or amendment may be constrained by the authorisation restriction thus stifling business dynamism and agility.

To support that desirable situation, some organisations have abandoned the least privilege principle in favour of having a risk based approach which permits potentially wider than required, authorisation profiles to be used, as long as they do not contravene pre-defined risk levels. This can be easier to deal with operationally as users are only restricted from compliance relevant risks but the design can be reactive to fast moving business innovation. It often aligns more easily with a job-based role profile, thus making the design more easily translated into language that a business user or approver may understand.

This approach does require careful management as the risk profile of the organisation may not be static. Access granted may not constitute a risk at the time, according to risk reporting but may, in future, cause additional conflicts which can take time to understand and resolve – unravelling authorisations which have grown in this way is often a more complex and costly exercise than investing the time in a proper design and implementation upfront.

In conclusion, the principle of least privilege is still a worthy aim for many IT systems, but improved risk reporting, monitoring and automation of controls are enabling organisations to approach their security design in a way that can take an approach with slightly wider privileges and place control around that. It is important to understand what your security design is there to do - is it designed to allow compliance to be easily understood by auditors and regulators or is it there to support your business operations in a controlled yet flexible manner?

The concept of least privilege will be a permanent fixture in discussions relating to security - it is still relevant, especially when managing implementation partners and lower-skilled security teams. The alignment with design and build activities plus the supportability and future-proofing of the system justifies the investment in applying these principles to your SAP estate early in development.