ECATT, SECATT or CATT has been a popular method with security consultants to automate various tasks. Its not the only tool used for automation and can be considered to be another option available in our arsenal. Till date I have purposely refrained from adding any post about SECATT as almost everything that you can do via SECATT can be done via LSMW which has been already mentioned on the site. Also, documentation around SECATT is fairly ubiquitous on the internet and I did not think that adding the same information here will make any difference. Recently however, I came to use another feature of the ECATT tool which is not as popular among us security consultants and which can actually let us do things which couldn’t do as easily before. So here goes the first post for the new year…. and Happy New Year 2014 for everyone. May this year be better than the last. Continue reading “Mass Changes – eCATT”
Its quite common in the SAP world that one transaction calls another via different menu options. At the code level this is often implemented via the ABAP construct “CALL TRANSACTION”. We know that to start a transaction from menu or typing via the command window, a S_TCODE check is performed at the SAP kernel level. However whether a S_TCODE check is performed for the CALL TRANSACTION statement can be controlled by us through the SE97 tcode. Its not often that we need to mess with the SE97 settings but its good to know about the option is available if needed. Continue reading “SE97 and TCDCOUPLES”
After finishing the last post on SE16N and DEBUG, I realised that since this site primarily caters to the aspiring security consultants, some portion of its target audience might be at all familiar with ABAP debugging at all. The idea behind this post is to acquaint Security Consultants with the basics of debugging. This is certainly not meant as a guide on how to debug ABAP code as you would need to be familiar with ABAP syntax to actually debug code. However, I always consider that knowing ABAP is very helpful for any consultant, functional, security or basis. So if you have some free time you can always go through some of the free ABAP tutorials available on the web and the added knowledge would certainly come in handy the longer you stay with SAP. Continue reading “ABAP Debugger”
This is a continuation of the many different articles on this blog around security around tables. However, the articles till now has concentrated on the different methods provided by SAP to restrict access to tables. Today’s article on the other hand will talk about a common method of accessing tables, the security implications for this form of access and how we react as security consultant when faced with requests for this form of access. Continue reading “SE16N and SAP_EDIT”
Few aspects of SAP Security are as well explored by Security Consultants as security for Tables. SAP already provides a host of objects for controlling access to tables – S_TABU_DIS for security through table authorization groups, S_TABU_CLI for client independent tables, S_TABU_LIN for row level security and S_TABU_NAM for security individual tables. The use of these different authorization objects have been documented elsewhere on this blog and I would not want to discuss any more of them here. However, lets take a different approach and think about a way to secure individual fields for a table or in other words column level security for a table. One of the ways to achieve these is through the use of database views. Please note that creating database view is not the job of a security consultant and in all probablity you would not have access to do it in any system. However its good to know of the option if ever the need arises. Continue reading “Database Views For Tables”
The SE03 transaction (Transport Organizer Tools) is certainly not a security specific application. However it provides at least one report which I find to be invaluable in managing security transports. Basically the report provides all transports (modifiable/ released) which contain a particular role.
We start with the initial screen for SE03 which is really a kind of cockpit to run various applications for transports.
We chose the report “Search for Objects in Requests/Tasks” which gets us to the next screen. To search for roles we need to enter a line with object type ACGR (Activity Group which is old SAP terminology for role), check the relevant boxes as shown and click the execute button.
The output of the report display all transports which contained the affected role.
Though we have just used it for search for roles, we can search for any development objects like Programs, Tables, Org Criterions to ensure that the latest transports are all moved to Production or that no unreleased transports for an object remains in the system.
We have already looked at the other SAP authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI, S_TABU_NAM. We end our discussion on table security with the one remaining object – S_TABU_LIN used for Line Oriented Authorizations. This object can be used to provide row level access control when accessing tables through standard tcodes like SM30 and SM31. I have purposely kept the discussion about this object for the last as its the most complicated to use by far and needs configuration changes in addition to role updates. Also note that S_TABU_LIN is always checked in addition, and not in place of, the check for S_TABU_DIS.
To use S_TABU_LIN in our authorization concept, the first step is to configure a Org Criterion through the SPRO transaction. We can use the org criterions provided by SAP or create our own criteria. The path for configuring org citeria is shown below.
We chose the first of the two options, “Define Org Citeria”. We create a new org citerion called ZMOLGA. The check box, Table-ind should remain unchecked as the new org criteria would only be checked for tables maintained by us and not all tables.
With the new org criteria selected in the screen, we double click the attributes option. This screen allows us to create the attribute for the org criteria. Further we can set the attribute to be the 1st to 8th attribute. The 1st to 8th attribute are actually the authorization fields present in S_TABU_LIN. Though in the present example we will just create a single attribute and set it as the 1st attribute, SAP allows us to create 7 other attributes for the same criterion.
Finally with the attribute created we just need to set the tables/views which will be checked for the org criteria. We use the view V_T510F_B in our example. Currently SAP only allows us to enter one table or view per attribute. The direct result of this limitation is that we need to create a new org criterion for each table we want to secure through S_TABU_LIN.
We can now save our entries. The system will prompt for a transport request to contain the changed objects. We have now successfully created an org criterion. However, we still need to activate it before S_TABU_LIN and the org criterion will be checked during table access. Activating the criterion is simple. We just check the box and save our entries.
Once this preliminary configuration is done, we are free to use S_TABU_LIN in our roles to secure tables based on the Org criterion. Since our criterion ZMOLGA is based on the MOLGA field of the view V_T510F_B, we can actually restrict access to only certain rows of the table depending on the value of the MOLGA field. For example the authorization below will allow the user with this role to change rows for the V_T510F_B view when MOLGA value equals 10.
It is important to remember that S_TABU_LIN will only be checked for the standard SAP table maintenance transactions. Thus if we have some custom code accessing tables, row level security is not going to work for them. Off course nothing is stopping the developer in adding a authority-check statement for S_TABU_LIN in this case.
As security consultants, we are often asked to secure or grant access to SAP tables. So most of us are already aware of the authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI and S_TABU_LIN. Out of this, S_TABU_DIS is the one that is needed for all tables. S_TABU_DIS secures tables on the basis of activity (02, 03) and authorization group for the table. S_TABU_CLI is needed when a user needs access to maintain client independent tables. S_TABU_LIN is meant for Line Oriented Authorizations which allows us to authorize indivdual rows of a table. However, till now security for tables was based on the authorization groups. The limitation with authorization groups is the lack of granular security on individual tables. Once a user has access a particular table authorization group, the user can access all tables linked to the authorization group. Technically it is has always been possible to create a new authorization group and link the offending table. But this soluation came with its own problems, specially when adopted for standard tables. For example a lot of tables are accessed to by standard tcodes. Changing authorizations groups for such tables can potentially impact the functioning of tcodes calling them. Also, the new authorization groups might be overwritten by SAP service packs so this becomes a recurring check for upcoming upgrades. Fortunately SAP in its latest service packs has come up with a new authorization objects for securinf tables, S_TABU_NAM. S_TABU_NAM promises to overcome the limitation of the current S_TABU_DIS object.
As can be seen above, the object has two authorization fields. The first is activity meant to restrict access to just display (03) or update (02). The other field TABLE takes the actual name of the table and allows us to restrict/provide access to individual tables overridding access for authorization groups.
I am copying the relevant SAP code section from the standard function module VIEW_AUHTORITY_CHECK. This FM is called by all standard table access transactions like SE16, SE16N, SM30, SM31, SM34, etc.
As you can see from the code above, VIEW_AUTHORITY_CHECK has a initial check for S_TABU_DIS. Only when the S_TABU_DIS check fails, is the new object S_TABU_NAM checked. So all the existing checks and the security roles built around them need not be updated as a result of the new object. It just provides us with an additional layer of flexibility for building our checks for tables. An example scenario might be to give display access to all tables with authorization group SC but restrict write access to just the T77UA (which shares the same auth group).
The idea for this post was suggested to me by one of the visitors of this blog, who had put in a comment around the use of value roles in security design. I though that the question was general enough to merit its own post instead of a reply to the comment. Let me first begin with a confession, though I have worked in a few set ups using this concept, I have never understood their effectiveness in security design. For me, value role create more problems than they solve. I agree that my views are colored by the projects that I have worked on and elsewhere, their use might make a whole lot of design sense. If any of the visitors have any experience in innovative use of value roles which really simplified security design, please feel free to comment. A healthy discussion on the subject will help everyone of the readers including myself!
The transaction and value/controller role concept revolves around creation of separate roles for transactions ( with S_TCODE) and authorization objects with org level values. The latter are the value roles as the individual values for the org levels are maintained therein. Elsewhere they are also known as controller roles or enablers, as they control the final access to a transaction. The transactional role in addition to S_TCODE also contain the authorization objects which do not have org level values. Since the value roles do not have transaction in their menu, the authorization objects are manually added to them. During assignment, both transaction and value roles need to be assigned to a user (sometimes via a composite role). There is no hard rule around the number of transaction or value roles. In a typical scenario, a transaction roles might be created to map the different jobs defined in the enterprise. A possible starting point of such a design will be provided by the user-transaction matrix. After the transaction roles are set up, a few broad value roles are created with authorization objects needed for a functional area (SD, MM, HR, FICO etc). The number of value roles generally will be much lesser than the number of transaction roles and will have all or most of the authorization objects belonging to the functional area. We can also have separate value roles for display and update and also different ones for the different ones for the various divisions in the enterprise.
I believe the initial logic behind adoption of the value/controller roles was reduction in maintenance effort. For example, instead of maintaining tcodes and authorization objects in all roles, we just add the tcodes to the single transaction role and the authorization objects to the value roles. In fact, since SU24 entries are not involved (authorization objects are manually added to the value roles), value roles will be only be need to be updated for a new authorization object (i.e. an object not used in the transactions being already used). Some people might also consider it to be a cleaner design, to keep the transactions and authorization objects separate.
After knowing the background of value roles, lets explore the problems created by their use. For me the biggest casualty of the value roles, is the loss of all information contained in the SU24 entry for the transaction as transactions and the objects needed for its execution are present in different roles. Without strong documentation practices, we can often end up with a situation where no one has any idea why a particular authorization object was added to a value role. A direct result of the above problem, is the fact that most value roles have more authorizations than are needed for execution of the transaction present with a user through a transaction role. A further problem arises because in many cases SAP allows us to jump to different transaction screens by following navigation options in the menu for a tcode i.e. moving from a display to the corresponding update transaction. Even though SAP would normally check for update activity in such a case, a S_TCODE check might not be enforced. Hence, user would get access to an update transaction through the value role even though transaction role only allows the display version. There might be many other such cases, where access present in the value roles might open up extra access with the tcodes present in the transaction roles. Finally the security testing effort is also increased a great deal as without the use of SU24 to guide us, the only way to determine the complete access needed for a tcode is run a trace for each new transaction and check each of the value roles to ensure that they contain required access.
I have already mentioned my skepticism for the value role concept for security design. In fact, I am even unwilling to accept the argument about less maintenance effort for value roles as the same can be realized with a parent-child role based design. However, there is overwhelming majority of security installations which continue to use value roles. If any senior security experts are currently reading this post, I would sincerely request their comments on the same as its extremely probable that I am missing something about the potential benefits for value roles.
The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. Its specially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child role derived from a parent role will have all attributes (transactions/ authorization object values) same as it parent except the values of the Organizational Level fields (plant, company code, sales organization). Thus maintenance is simplified as only the org levels need be maintained at the derived role level. This also ensures that there is no opportunity to make mistakes during authorization maintenance for the multitude of derived roles and also reduces testing effort for roles.
Creating the parent role follows the same process as creating any other single role. In the example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company code, sales orgs.
With the parent already defined we create a child role “Z_CREATE_SO_US” which allows SO creation for the US companies. We maintain the parent role name as shown below.
The menu for a derived role can not be individually maintained as all entries are inherited from the parent.
Now we maintain the org levels values relevant for the child role. In the example below, we have used a dummy value of @ but in a production system the correct value for org levels should be used. The other other need not be maintained at this stage. Now we save the authorization entry for the derived role.
To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non org level values from the parent to the child role and generates the profiles for both.
The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows different business process in its different subsidiaries.