Organizational, technical or a workload problem?

OttoGold · ‎11-15-2014

All sorts of problems

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

The security department lacks the education and skill
The security department is understaffed
External service provider built something ridiculous
Legacy authorization concept is not suitable for the new business situation
Political situation in the organization does not play in the security team’s flavour
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
SAP does not give the customers the technical means to implement the required security standards
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)
Different departments run their own security or have very inconsistent security requirements and means of implementing them
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.)
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)
…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:

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).
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 super-users”. 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.
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?
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.
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).
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….!
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!