Skip to Content
Author's profile photo Otto Gold

Organizational, technical or a workload problem?

All sorts of problems

Bad things can happen to your authorization concept for many reasons:

  1. The security department lacks the education and skill
  2. The security department is understaffed
  3. External service provider built something ridiculous
  4. Legacy authorization concept is not suitable for the new business situation
  5. Political situation in the organization does not play in the security team’s flavour
  6. New functionality (like module) is implemented without clear requirements (which in security means: broad or inconsistent access) and is kept that way after the go-live
  7. SAP does not give the customers the technical means to implement the required security standards
  8. The quality of work done by the members of the security team is inconsistent and varies from very good to very bad (so everyone is demoralized and people break other people’s work every day)
  9. Different departments run their own security or have very inconsistent security requirements and means of implementing them
  10. The technical and philosophical means used in the project (and in the operations) are sub-optimal or simply wrong (value roles, composite roles with task based mini-roles etc.)
  11. The scope of the project is broad and the internal or external delivery is on a high quality standard, unfortunately the after-the-project mode (and resources) don’t allow the security team to keep the level of security so high (so the project was actually a waste)
  12. …and many other situations

These are just some examples that lead to bad things rather sooner than later. Why am I starting a blog post with such a list? Well, you have certain technical tools, certain political and organizational power as well as a certain size of the security team. Your security levels needs to be aligned with these things (and many others as well… we can argue which of the factors are the most important, which are less important and which are rather minor – please leave a comment below).

For this very reason I ask my customers many questions before we even start a project. Questions like: is your management difficult or supportive? Do you have an internal auditing department? How do you check the quality of the work in your team? What system releases do you have available? When did you perform the last big clean up or redesign of your roles or security in general? What are the roles that you’ve defined for yourself and to what extent you stick to them? Do you work centrally or the responsibility (and authorizations and needs etc.) are distributed?

Answers to these questions should help you build roles (generally security) tailored to the organization’s needs (and to the needs of the security admins there) as well as guarantee that the roles you build (generally security) will survive for long enough so that the externals and internals on the team can sleep well.

Here comes the challenge

I know, I am talking about too general things without indicating what is what I want to say in this blog. Let me briefly describe my motivation for this blog first. Under my recent blog “On the way to granularity” I received a comment about the difficulty with S_TABU_DIS and NAM access in the real world, specifically in the area of the Financials. That blog was meant to inform readers about technical means for the granular security access (that things are available and you can optimally use them for your benefit and security).

But the question is less about the technical means and more about the organizational obstacles as well as about the challenge to implement granularity in the finite time (with everyone still aboard and happy when it is finished).

Kesayamol Siriporn asks (using my own words): There is a table LFA1 which contains sensitive information. This table is assigned to an authorization group FA. This group contains 955 tables in the system where I’ve just checked. Users that use LFA1 also use other tables from that group, but not all 955 probably. The question and the challenge is how to authorize for the access to the table LFA1 and other tables from its group so that the workload produced by the approach is not overwhelming for the security team and on the other hand we can still call the approach secure. We also need to consider the users using queries and generic table access transactions (SE11, SE16(N), SM30, SM31, SM34) on these tables.

Choose the right tool for the job

The question is specific, so I will covered the specific details to my best knowledge. On the other hand the question generally asks to what extent we can or should implement the highest possible granularity and how to do it efficiently.

The following points and questions come to mind:

  1. I am pretty sure there are standard means (transactions, reports, queries) how to work with the data in the tables mentioned in our question. Has all standard options been considered for the end-users? Are we forced to come to the lowest level – database tables?
    1. These standard tools will be maintained and developed further by SAP so the upgrade (also mentioned as a point in the challenging question) does not pose any threat or force periodical redesign.
    2. For these standard tools we have transactions available (as the primary building block for the role menus as well as the main door for the users which we can use to talk about the problem with normal mortals).
    3. For these standard tools we have SU24 defined which provides you the “templates” for the roles and you need to define only a couple of fields and values and primarily consider the organizational aspect (org. fields etc.) based on the data.
    4. The organizational aspect (like using the org. fields) is simpler than maintaining long lists of tables for generic table access transactions. You can tell if a user can have access to a specific cost center, profit center, vendor or a purchase order easier than whether than user can see one of those 955 tables in the LFA1’s authorization group (use any other example from your daily work here).
  2. There are many possible answers to the point above:
    1. “We don’t know. We have no clue what standard tools we can use” – is this because you are new to SAP? Or you pay money to people who don’t know their job? Or have you just started considering what you can do about this challenge and the direct table access sounded like the easiest option? Please inform yourself first before jumping to conclusions.
    2. “Yes, the tools are available, but our users cannot use them” – and why is that? Too much training would be needed? Release of the system is too low? Or what is the problem exactly?
    3. A variation of the previous point: “Yes, the tools are available, but the users don’t want to use them as we traditionally use table access and we cannot take that away from users”– ok, but this is not a technical problem. You must either find enough workforce to perform a clean-up and remove the generic tools (like queries or transactions like SE11/16) without bothering the users (the access is the same, but the technical way is more sustainable) or get yourself enough political support so that you can take the generic tools officially away and start giving granular access from scratch and carefully (please see “from scratch” as shortcut for the purpose of the storytelling here, not literally).
    4. “No, the tools we need are not available in the standard” – well, then you can consider building them maybe? Why not custom development?
    5. We must also consider that in some cases “Table access can be fast and efficient for the superusers”. But in this case the challenge is not to secure the whole system and all the tables one by one for users to be able to use them, we are talking about a handful of users and I would say handful of DB tables as well. That leads to the next point.
  3. How many users (and their roles) need to touch the DB tables? How granular the access needs to be?
    1. Example: Some customers use various desktop tools that are easy to operate and they give these tools to the hands of the managers. These users are then privileged by definition as well as the number of the people is limited by definition. In that case it can be enough to create a little delta role, that gives this type of access to a several handpicked individuals. Surely this approach will not work in a large organization, but it will work well in the smaller ones.
    2. Note that queries mentioned in the question and the transactions for queries are just a variant of the “desktop tools” mentioned above.
    3. Please consider that if you try to build a concept around access to table group FA (or even based on table names) which is just one of the hundreds of table groups, doesn’t that mean a commitment that you will be careful and super-secure in other areas as well? Balance is an important think (also for Karma…). If you build such a concept because you think it is a good idea, will your colleagues think that as well? In case you get hit by a bus, will there be people that will be able to maintain your concept further and especially – will those people see the need for your super granular access or they change it to same * (star / asterisk) type of approach as soon as you’re gone?
  4. The question specifically mentions queries. Well, queries are very special beasts. Not technically, but the way they are used or misused (organizationally). There are several things about queries we must keep in mind:
    1. Queries are not super friendly from the transporting perspective
    2. People are generally lazy creatures
    3. Users claim (and it may or may not be the truth) that the data are only available in the production system and so they can only create their queries there.
    4. Users claim (same truth problem) that the flexibility of their “questions” (translated into the queries) is very high and that requires them to be flexible as well – they don’t want (or can) spend time on organizational problems – like testing in test system, developing queries in the development system, transporting queries etc.
    5. Sometimes the organization is difficult and transporting based on the forms and workflows and procedures would take weeks to happen as well as weeks would be needed to have the paper-work done.
    6. If you want to do the thing correctly, do the following: you create queries, you test the queries, you create transactions for the queries, you put those transactions into the role menu and you maintain SU24 for those transactions, you’re doing it the way it was designed and meant to be. Of course the question is – can you do it (enough time? Not too many organizational obstacles) and do you want to do it? Too many variables come to play here, there is no universal approach to this challenge.
  5. Let’s say you want to build a concept around the 955 tables in the group (just an example, ok?). The easiest option would be if SAP provided concept there for you. If they could make the problem ten times smaller by splitting one huge group into ten smaller ones, the size of the challenge immediately shrinks. As I said I am not an expert on all the FI tables sitting in group FA. I would not know how to split the tables into 10 groups (random number which would make the maintenance 10x easier if we went this way). I can’t even say if it is possible or wise in this case. Why I am saying all this is that you can theoretically do it yourself. If I am not mistaken, you can reassign the tables to different groups. The problem here is that it is a modification and your hard work will be overwritten with the next upgrade. That is why getting SAP to do it is the only way I see if you concentrate on “I don’t like this table to be in this group” part of the challenge.
    1. Here please consider a different organizational and also a technical aspect. If SAP did this – if they implemented such a “better concept” (whatever that would mean), it would change the behaviour for everyone. Every customer. That could mean customers that don’t want that are also forced to adjust themselves to the new way. It can mean that changes would be required to keep the system running although no change is needed or wanted by the customer. That means I can’t see SAP doing much here (even if it was a wise idea which I cannot judge competently).
  6. If you want to go all the way down to the tables and authorize for them one by one (because your users are used to it for example – well, you caused yourself the problem, do you see it?) the correct approach would be very similar to what I said above about queries:
    1. Define tables to which granular access needs to be granted
    2. Create parameter transactions for these tables (via SM30 or so)
    3. Maintain S_TABU_NAM proposal for the transaction
    4. Use the transactions in the menus of the roles and pull SU24 proposals for them
    5. Enjoy….!
  7. Consider also a different example. Let’s forget about financials for a moment. Let’s talk about table group &NC& for a moment (or the empty value – no assignment – which is translated to &NC& implicitly). Do you understand what the problem is here? Do you understand that the problem with this “group” is much, much bigger than with group FA or any other group?
    1. Go to table TDDAT and search for CCLASS = &NC&. That gives the word “huge” like in “huge problem” a “huge” new meaning.
    2. Check your custom tables. How many of them are assigned no group or the “group for all garbage”?
    3. Why was someone so lazy that he (she) put the table into this crazy group? Why not a better group? Why not a concept behind the thing?
    4. Go to SU24 and look for objects there (not only transactions!) that have &NC& as the proposed value.
    5. Do you understand that if that value gets into a role and that roles is given to users, they have access to dozens of thousands of tables in the system?
    6. Out of curiosity – has any auditor ever told you about this being a problem? Is that on your to-do list to make sure you are all well on this front? You can answer the question either for &NC& or generally the generic table access transactions.
    7. Point for SAP: Take care of the SU24 proposals with this value as well as make sure it is not needed. You know what the risk is, we know what the risk is. Give us the solution. All of us and now. Not that every customer must perform a SU24 clean-up of these magic (cursed) values.

If you made it all the way here, dear reader, also consider that you have the same problem not only with S_TABU_DIS and NAM, but also with S_PROGRAM for example. With S_RFC. With job administration and in many other areas as well. Find and implement the approach that is both secure and pragmatic, so that you can live that approach. So that your team and your organization can live that approach.

What can I say to summarize this ina nice way… Well… hold on. You’re doing it for the brighter future, for your children and their children. They will remember you for being secure and also pragmatic and for choosing the right tools for the right job. Good luck!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tammy Powlas
      Tammy Powlas

      Hello Otto,

      I always enjoy the thoroughness and directness of your blogs.

      I do have a question - you say "The question specifically mentions queries. Well, queries are very special beasts. "

      I thought I read that queries, when built against logical databases, were good at checking/providing/implementing security.



      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Tammy,

      you're seeing it from the other side. I am not saying that queries are not protected, they are (or should be in case of the custom ones). What I am saying is that you must build the roles (ideally via SU24 proposals) which must be in sync with what is tested in the queries. So I am not saying an authority check may be missing here or there, the checks are now fixed for this topic, I am saying that we must find a way how to "mirror" or "import" or "pull" the necessary authorizations (that are already in the queries) into the roles that you build to authorize users to use those queries. Same applies on the generic table access.

      The primary problem here is that you must be aware of ways how to do it (which varies from manual profiles and roles with manual authorization instances to parameter transactions with SU24 proposals translated into standard instances in the roles) and then you must choose a technique (organizational and technical) to implement that thing so that you can also run (and "live") that thing once the initial implementation is over.

      cheers Otto

      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi Otto

      Great blog (like usual)

      1. The security department lacks the education and skill

      This seems to be too common. I come across many security people who do not keep their education and skill up. They still believe their role is solely PFCG and SU01 activities. This group are also the ones when you mention RFC connections and system users are too open will respond with "but that's Basis' job". Proactive activities also get delays (frustrating hearing from security "we don't initiate changes to roles unless functional want them " when you find change access in a display role or sensitive authorisations)

      A lot of security is not designed or built with sustainability involved. SU24 is integral to maintaining security. If done cleanly, introducing a granular object would not be as tedious. Unfortunately, a lot of customers/sites do not invest in security at the beginning. They are brought in towards the end of a project or when the first audit findings are returned. From then on, they are forever catching up.

      We keep hearing security is a top concern/priority for senior management yet we don't often see how important it is through demonstrated actions and investment & support of security.



      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hello Colleen,

      have you heard about transparency before? The customers want their security to be "transparent" so that they don't get to hear about it which is normally good as that means that no incidents happened. But how do you ask or get a budget for something that should be "transparent" (aka "don't bother me" or "invisible"), that is the challenge.

      Maybe other gurus and ninjas have ideas how to get there?

      We don't have that many customers talking to us on SCN, why is that? Too often we see "system integrator" people asking for step-by-step but it would be so great to read something on sustainability from a customer representative.

      cheers Otto

      Author's profile photo Former Member
      Former Member

      Colleen and Otto,

      I suspect that I am not the only customer who recognizes more than one symptom of the issues plaguing SAP security at my past and current SAP shops in the list above, but "airing the dirty laundry" can be a quick way to make oneself persona non grata at the workplace. As for why more customers are not active on SCN,  I can only speak for myself, but my own perception is that SCN is primarily geared towards the challenges of implementation and upgrades, whereas customers are more vexed by the issues of production support. Implementing the solution takes a finite and relatively limited time frame, whereas keeping it running long after the consultants are gone can be years of challenge and struggle, and the options are not always black and white. I will think about it and see if I can draft a post about an approach to sustainable SAP security from the customer perspective without getting myself called into my CIO's office 🙂



      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi Gretchen

      Fair point. I like being an Independent Consultant as my views are allowed to be my own. However, there are a few blogs I would like to write but I would be borderline breaching client confidentiality if I discussed the issue.

      Unfortunately, there is a culture that issues/errors must be attributed to blame/scapegoat. Few people like to admit to issues or challenges as it's seen as a failing on their behalf. Very had to improve if you cannot have an open and honest conversation with peers about common problems.

      One of the topics I would like to pursue is relating to designing security with sustainability in mind. How can you go live and 6 or 12 month later avoid your security being a mess or requiring a complete rebuild. I'm not sure if such a topic would be of value to customers.



      Author's profile photo Matt Fraser
      Matt Fraser

      Gretchen, so true! In my first SAP project, as a customer, indeed security was almost an afterthought at the very end of the project. In my projects as consultant, this tended to still be the case. And then when I became a customer again, security was once again something slammed in quickly at the end, with literally less than a month to GoLive.

      We've reported to management time and time again that we have an inefficient and non-audit-proof security concept in place, and there's occasional talk about an authorizations overhaul project, but it never gets any traction because the 'customers' (the business units) don't see any value in it for themselves, only a distraction taking our support staff away from the more important tasks of churning out another custom report that will be used once or twice.

      Anyway, Gretchen, I would love to see such a post about the customer perspective on sustainability, and Otto and Colleen, I continue to read your posts as inspiration for "how it should/could be" (but all too frequently isn't).

      Yes, it's a little irksome, as a customer, to sometimes feel like I'm telling consultants on SCN how they can do their jobs at other customer sites. I feel like I should get a slice of the consulting fee when that happens!

      Author's profile photo Colleen Hebbert
      Colleen Hebbert

      Hi Otto

      that means that no incidents happened

      what is the customer actually defining as an incident? It is a authorisation error or security breach (when something bad happens). A lot of issues we get in security are not "transparent" to the business layer/decision makers of the organisation. Building a role inefficiently but with correct permissions doesn't weaken security but makes it a headache to maintain later.

      Who do you consider the customer representative to be in the context of what you would desire to see on SCN? You are right, there are too many "integrators" wanting step-by-step. The problem is these guys are so caught up in the detail for a specific scenario (and still at the how to level) they miss the big picture and desire to understand "why". At that stage, I would question if the truly are a "system integrator" even if that's their title.

      I'm no ninja or guru but part of getting there is Security people need educate themselves (yes calls out your first point). More so, they need to shift their communication away from technical and start talking business. It's amazing how different a meeting outcome can be when you go into a workshop and talk about security in business language without getting up and drawing the SAP authorisation concept.



      Author's profile photo Martin English
      Martin English

      Otto Gold wrote:

      The customers want their security to be "transparent" so that they don't get to hear about it which is normally good as that means that no incidents happened.

      None that they know of.