Skip to Content

The two-edged sword of security automation

NOTE: this content is the copyrighted property of the author, Gretchen Y. Lindquist, and is published by the author’s permission on SDN.SAP.COM. If you are reading it elsewhere, you are reading stolen property.***

My colleague’s request was simple: could I take a few minutes to call an end user who had submitted a problem ticket concerning SAP security access requests? Sure thing, give me her contact information and I’ll handle it. When I reached her by phone, she explained that she was having a problem using our old access request form to request access to approve expense reports. I reassured her that I could talk her through using the new access request toolset, and she would see how all the new features made it a much easier process.

Getting her logged into our SAP portal and launching the request application was a snap. We were progressing swimmingly until a pop-up error message said that she was being blocked from requesting the expense approver role; either a request for that role was already in process, or it was already assigned. OK, let’s back up a minute, click the Show User’s Current Role Assignments button and let’s take a look. Sure enough, the role was already there. But I am gettting a security error every time I try to approve this expense report, she protested.

I had her log into the core production client and try again, up to the point where she was stopped, then I verified her last authority check. As I had started to suspect, it told me that all authority checks were successful. I told her that she was not having a security problem, that something else was wrong here. Perhaps the expense report was not in the correct status. I suggested she contact a process expert in expense approvals, and wished her luck.

 Afterwards, I thought about this user and considered the possible root causes of her problem. Was something done incorrectly in the submission of the expense report, or was she making some kind of error in her attempts to approve it? It seemed likely that it was a training issue of some sort, which led to further questions.

Access to submit expense reports is granted in our general user role, which is assigned to most users via assignment to the organization unit, after the user IDs are created automatically by a custom program. We don’t do a lot of security by org structures, but it is a huge time / cost savings to have user IDs created automatically and basic general access and access to employee self service (ESS) granted automatically. However, the down side to this automation is that the users are granted access to these transactions without any training.  The ESS transactions are fairly straightforward, but on a few occasions I’ll admit that they had me stumped, and Engish is my native language. What about all of those transactions in the general user role? Are all of them so straightforward that users could do them correctly without any training, even users for whom English is not their first language? I’m not so sure about that optimistic assumption.

Then I considered the new identity management tools that assign a whole bundle of roles in several systems, based on an employee’s hiring into a particular position.  I have doubts that automation to that extent would be acceptable to the business here. Today, a good number of  roles are not approved for assignment until the user provides evidence of passing a training course.

Therein lies the conflict. The idea that users would get roles based upon their assignment to a particular HR position, and removal of those roles when moved to a new one, has some inherent control benefits, preventing the continued accumulation of security roles as employees move about the organization. The down side is that the roles are assigned without any training, which might be OK for some roles but not others. How much automation of role assignments would be considered low risk? I can see that in our organization at least, quite a few roles would never be approved for automatic assignment.

In this case, I suspect that either the expense report creator or the would-be approver needed some training on expense reports, but as is so often the case, the user having problems automatically assumed that the error message meant that she was having a security problem. Over ten years after our initial implemention, people still occasionally jump to the conclusion that an error message is always indication of a security problem. Why didn’t the help desk agent help her review the message and determine that it was not a security problem? Another training issue seems evident. Sometimes what appear to be problems are just training issues, and we certainly do not want to contribute to more business disruption caused by training issues by letting loose untrained users to attempt complex transactions.  How do organizations balance out the need to ease onboarding of new employees and to keep security aligned with their current jobs, and still require training prior to role assignments? There is the million dollar question.

You must be Logged on to comment or reply to a post.
  • The bugger with training and other org. procedures in the way of role assignment is that folks start sharing user ID’s, or technical “workarounds” are found or requests start coming in for development of upload programs.

    Once you have a few of those, chances are also good that you will have a generic include for it and a bigger security gap than you originally tried to solve.

    IMO the solution lies in good service (like the analysis you did) on the security side and responsible role ownership which respects what security design has set up (and does checks on).

    I agree with you that many messages are assumed to be missing access, or may even be misleading. Much of it is simply faulty config, sub-optimal coding and of course shoddy custom reports / exits.


    • I agree, Julius, that the messages can be confusing to users, and it can take years of security experience to get a sense of when something is really broken security or not. The ever-increasing multiplicity of authorization concepts does not help matters either.  The sooner that the product suite can get to a standardized authorization concept (or at least a simplified/ limited number of authorization concepts), the easier/ less resource intensive it will be to provide security support to the ERP landscape.
      Thanks for your comments!
  • I have seen this issue several times – user reports a security error, security team does some analysis and says all is well and they should contact an application/process expert – except that the security person does not know who that person would be. User is no wiser at the end of this process.

    We also had a very intersting dilemma with CRM Access control engine – where access is controlled by a combination of ABAP logic, master data and good old Basis roles. In this case – it was pretty hard to assign ownership to any one team if a user was denied access. Finally, we cross trained people in ACE and basis – and did a lot of process work to get it right.

    • That is an excellent point, Vijay, and I am afraid that I can see a number of factors at work. I suspect that a typical scenario is starting out with a strong process expert organization; however, over the years,  many of the experts move into other areas of the organization, or leave the company altogether. In some areas I suspect that cost-cutting measures may be the root of the less-than-optimal state of the key user/ process expert network. Consequently, years down the road, it is not too surprising if some of the process areas have strong process expert organizations and well documented online knowledge base material, and others have, hmm, let’s just say, improvement opportunities. Cutting such personnel (or allowing these positions to remain vacant due to attrition) can be a false economy.
      Thanks for your comments!
  • I am in this situation now and than, where first easy target for help desk people are SAP security team.
    Although I do not blame them as user’s initial complain is, However I do agree with you where each SAP Product has different authorisation logic.

    In our Organisation, we do not have dedicated SAP trainers for end users,
    imagine being end user point of view, this makes difficult to be expert overnight, hence out come is more support calls.
    Automation brings benefits of assigning role align with the position with risk of getting access to new function.
    Now in absence of good training or prerequisite steps before jumping on SAP is also about the recognising risk. (although I would also like to point that without automation of security, risk can be much higher by not aligning access level or being reactive).

    • Kinjar, I agree that the lack of dedicated training resources certainly can be a challenge and an extra burden on security support. Recorded training modules can be a big help for some usage scenarios, but not everyone learns in the same way, and it can be very challenging when the only live training available is user-to-user, in these days of reduced staffing and knowledge walking out the door with every staff reduction. It really can be a dilemna to decide which is the bigger risk to your data integrity, the case of untrained users with the correct security roles, mucking up your system, causing errors, costly re-work, or worse, or the case of well-trained users with obsolete access. I had hoped that by now, someone would have come forward to tell us all what the product vision was to mitigate these risks in landscapes with automated identity management. Perhaps we will yet get some further comments.

      I hope that those interested in these questions will be able to join us at SAP TechEd, where I plan to continue the discussion in Phoenix. Thanks for sharing your thoughts!

      • The ABAP/BI guy in me is just thinking out loud here 🙂 –
        Since we can find
        1. what roles a user has
        2. what transactions the roles have
        3. the create and change date for roles
        4. how many transactions got created/posted by given user in a certain time frame
        5. how many dumps / error status transactions a given user has encountered

        Can we whip up a report of some sort that combines such information – so that security team has a clear view of the problem, and eliminate several usual causes?

        • Vijay, although considered obsolete, the reverse business engineering (RBE) toolset can be used for some of the kinds of analysis you mention, and I am aware of some security people who have used it very successfully for role redesign initiatives. It does generally require some months of data gathering before trends will be clear enough for decision-making.

          On a somewhat less grand scale, we have a homegrown program that gathers usage statistics so that a query can be run to see what transactions a user has executed within a date range, or conversely, the list of users executing a particular transaction. This kind of information can be helpful when deciding if role can be removed from a user without impacting his/her usual work processes, or if the users mapped to role are actually executing a high risk transaction.  I expect that as the Identity Management and Business Objects GRC suites become more robust over time, similar functionality may become available if not already on the horizon.

          Speaking of which, I would like to mention some upcoming web casts on the NetWeaver Customer Call series sponsored by ASUG. Tomorrow we will hear from Torgeir Pederson speaking on the Identity Management overview and roadmap. The final presentation in this series, on the GRC Access Control overview and road map, will be presented by Michaela Zwinakis on August 19.
          For more info and past session recordings:

          Hope to see a lot of you then!