Despite Firefighter’s benefits (management of privileged access, streamlined emergency access management, increased audit compliance, etc.), SAP security teams are finding it increasingly difficult to manage the process. The rise in the use of the FF functionality is causing organisations to see a huge spike in their FF log volume, with this resulting in an accumulation of unchecked records that spans weeks, or even months.
Unsurprisingly, this has caused frustration with many SAP teams, who find the never-ending demands of FF management unsustainable, while it also diverts resources from other critical tasks. However, the right mix of SAP security and FF experiences allows a number of causes for these issues to be identified, and solutions put forward.
Over-use of Firefighter for non-critical transactions
One of the main causes of increasing FF logs is the over-use of low-risk transactions during emergency access sessions, with up to 20 percent of all transactions executed during this activity being non-critical at some enterprises. Removing these immediately reduces work for the FF controller, who is responsible for reviewing all transactions used.
Digging deeper, this over-use is symptomatic of a wider issue, whereby security teams want to maintain a zero-risk environment when designing business-as-usual roles for the end user (everyday tasks for the rest of the company such as processing payrolls, inventory management, etc.). Any transaction that is a potential risk is removed and placed in a FF role, therefore increasing the requirement to use FF identities to complete straightforward tasks.
To solve this, SAP teams should establish a realistic risk appetite. It is impossible to remove all risks, but appropriate controls such as Segregation of Duties and process controls will allow users to complete essential everyday tasks, whilst ensuring only high-risk transactions are part of emergency access process. Roles can then be redesigned to reflect these new priorities.
Lack of workflow
A failure to establish an appropriate workflow causes further issues for security teams. Some organisations outsource log management and approval to third parties; the third party alerts controllers when there is a problem with reporting and the controller carries out further investigations if discrepancies arise.
Not only does this further complicate the emergency access process, it increases the risk of inconsistent standards and false positives/negatives, as well as draining expensive resources. It also means the controller is responsible for both log management, and another team.
Controllers must maintain boundaries to keep processes efficient and avoid over-complicating the solution. Upholding strong Segregation of Duties with clear lines of responsibility is crucial for a secure, streamlined process, along with ensuring emergency identities are only used for high-risk access to reduce the overheads required to review FF incidents.
Failure to document all aspects of the FF process creates unforeseen workloads, resulting in controllers not being provided with enough context to approve logs. This leads to them needing to investigate FF incidents by talking with the end-user in order to understand why certain transactions were required – activity that creates further work.
Therefore, organisations need to maintain strict expectations when FF access requests are submitted. Owners, who are responsible for accepting or rejecting these requests, must be responsible for challenging applications and require the user to clearly explain what necessitates the use of the highly sensitive privileged access. The controller and owner should be working together to scrutinise activity.
Furthermore, simple alterations such as creating a variety of reason codes, would benefit controllers by allowing activity logs to be categorised. The more specific the reason code, the more context it provides, resulting in a detailed understanding of requirements for the controller, without the need for further investigation.
Unclear authorisation levels
Users are often unsure what authorisations each separate FF identity enables, resulting in SAP_ALL capabilities being requested by default (with these rarely being required). Clearly documenting the level of access that is allowed by each FF identity, and relating these to various business scenarios ensures users only request the privileged access that is appropriate for the task in hand.
Approvers should also be provided with guidance on which identities require advanced vetting, and what criteria need to be fulfilled in order to gain SAP_ALL access.
Automation: Potential and limitations
Many high-volume IT security processes benefit from automation and this can be the case for the emergency access processes – but only to an extent, with this activity reserved specifically for low-risk transactions. Automation doesn’t aim to remove the requirement for a trained individual to check logs, but will reduce the number of low-risk logs a FF controller has to analyse. Using historical data, security teams can determine which low-risk transactions are commonly executed during sessions.
Business analytics reporting tools that deliver data in easy-to-follow infographics can be utilised to summarise FF log data in a user-friendly way, which is then approved by the controller.
Any automation needs to be combined with regular spot-checking to ensure this tooling works as expected and that high-risk transactions are not included in the automation process. Ultimately, the FF controller is still responsible for appropriate usage, and the access risks they own.
In summary, Firefighter is an essential tool, but there is a risk that, in being regarded as a panacea for a wide range of issues, it can be overused, leading to excessive workloads and internal pressures. However, the straightforward changes detailed above will help IT security teams benefit from the correct use of privileged access without this compromising their efficiency.