Implemantation of SAP security for a public sector organization: Part I

Summary:

This document presents the technical recommendations and improvement opportunities based on a review of the Large Public Sector Security Framework, the Organizational job role definition and requirements.  It is assumed that the organization will develop or contract knowledge security resource(s) to execute the recommendations.  Out of the list of thirteen (13) recommendations, recommendation 1, 2, 3, 5, 6, 9, 11, and 14 should be reviewed first. 

Recommendation 1: Three best practices should be documented in the security framework and be followed to optimize security role design. 

1.    The same transaction code should not appear in more than one core functional role.  This design principle minimizes transaction code redundancies.  It decreases risk of inconsistent access privileges for common transactions.  One adjustment to a role is automatically activated for all assigned users or positions.

2.    Core functional roles should contain a small set of related transactions in a sub business process area.  Core functional roles should be task orientated rather than job orientated.  This approach decreases turnaround time for design and build of roles.  Code changes at the role level involve less clean up because the roles are smaller.  Code adjustments occur less often because many functional design changes only require remapping of roles to position or users. 

3.    Within a functional role there should be no SOD (segregation of duties).  When the roles are combined and assigned to the users / positions, in some instances, SOD has to exist because the conflicting tasks cannot be separated. 

Attached are examples of core functional role design matrixes:

Role Design Matrix Template.xls

How to define functional roles example.xlsx

Recommendation 2: The Organization may consider the use of value activity groups (also referred to as organizational roles) to facilitate roll out of security roles globally. 

Value Activity Groups vs. Master and Derived roles

The Organization’s Security Framework discussed the use of “master” and “derived” roles for global roll out.  The approach of creating master (also referred as Template roles), and then derive the master roles into children roles with different organization attributes can meet the requirements.  However, one important goal of an organization in its security design is to minimize the number of roles in the system.  With this consideration, the use of Value Activity Group will add efficiency and ease maintenance. 

“Master” and “derived” roles approach is to first

1.            Create the master roles (also referred to as the core functional roles) which contain the transactions necessary to perform a process. The required authorization objects and values are developed, with the exception of the Organization Level values. Organization Levels include such values as Company Code, Cost centers, Purchasing Organization, etc.

2.            Then copies of this master role are “derived”. These derived roles contain not only the same transactions and authorization values as the master but also the Organization Level values.

The use of Value Activity Group approach is to first

1.    Create the master roles (also referred to as the core functional roles) which contain the transactions necessary to perform a process. The required authorization objects and values are developed, with the Organization Level fields deactivated or blank. 

2.    Create small value activity groups (also referred to as organizational roles) which contain only organizational authorization objects and fields, such as company code, purchasing groups, business areas and associated activity codes…etc.  These roles differ from the derived roles because they only contain a few applicable organizational objects and values.  They are “small” and easy to maintain.  In addition, derived roles are master role specific and are tied to a specific process or sub process areas.  But value activity groups are independent of any master roles or process areas and can be combined with any core functional roles and assigned to users or positions. 

For example, we would like to restrict five functional roles including Accounts Payable, Accounts Receivable, GL, Purchasing, and Sales roles based on business areas (for example, we have ten business areas).  If we use the master and derived role approach, we will need to first create five master roles for AP, AR, GL, Purchasing and Sales.  Then we will need to derive ten roles for AP, ten roles for AR, ten roles for GL, ten roles for purchasing and ten roles for Sales to restrict the master roles on the ten business areas.  The total number of roles in this case will be fifty-five roles including five master roles and ten derived roles for each of the five master roles. 

If we use value activity group approach, we still will have the five master roles (AP, AR, GL, Purchasing and Sales).  But we will only need 10 value activity group (also referred to as organization roles) each contain one of the ten business areas.  Then at the time of assignment, the appropriate value activity group contain a specific business area will be assigned to the users or positions in addition to the master roles.  In this case the total number of roles is only 15 as compared to the 55 roles in the master and derived role scenario.  

The more functionality and more organizational variations that are in scope, the more advantageous is it to use the value activity.  The benefits of using value activity group are:

1.    Significantly reduces the number of roles in the system

2.    Reduces the size of the roles themselves

3.    The approach is flexible and modular because the value activity groups (organizational roles) can be matched with many different master roles to create the necessary access mix.  These value activity groups are different flavors that can be added to different master roles. 

4.    Change or additions to the value activity groups can be done independent of the master roles with minimum impact on any other roles.  Therefore the implementation and maintenance effort is low with respect to any design change on the organizational attributes. 

Attached is an example of how to define value activity groups:

how to define value activity group.xlsx

Recommendation 3:   The Organization may consider the use of position based security for assignment of the security roles. 

Position Based Security vs. User Based Security:

Most of the Organizations currently uses user based security, which refers to the method of assigning security roles to a user ID. 

Position based security refers to the method of assigning security roles to an org unit, job or position instead of assigned them to a user ID.

At you organization, an HR org structure is available, which allows security to leverage and assign users to an org attributes.  Position based security reduces initial and ongoing administration effort.  Since roles are not tied to a user, rather it is tied to a position the user(s) occupied, once a role is assigned to a position under the org structure, any users occupy that position will get the access.  For example, if a user transfer from Position A to Position B, no role reassignment is necessary, because the roles are assigned to Position A and B, not to the user.  When this transfer happens, the user moves in HR org structure from A to B, and will automatically get authorization which is assigned to Position B and relinquish old authorization from Position A.

In addition, position based security is easier to use with Workflow functionality:

In general, Workflow uses the organizational structure to identify approving positions; the position itself, not the holder of the position, drives the approval

Position-based security is similar to the position-focused Workflow (chief positions); everything is centered on positions.

Here is how to assign security roles to an attributes along the organizational structure:

In PFCG, security team will assign roles via the org mgmt tab,

, choose the org attributes from the org structure to which the role will be assigned.  The role can be assigned to an org unit, a work center, a person, or a position. 

However, for contractors, temporary employees who are not on the HR organizational structure, user based security will have to be applied for this subset of users. 

Recommendation 4: To reduce number of roles in the system, The Organization may consider use of only virtual composite roles (job roles) rather than creating real composite roles (job roles) in the system. 

Composite roles are containers of one or more core functional roles.  Some disadvantages of creating actual composite roles in the system are:

1.    Increase number of roles in the system.

2.    Overtime, composite roles can lose its original definition when more single functional roles are added to the composite. 

3.    Composite roles can hide SOD (segregation of duties) issues because it is not transparent what actually are in the composites. 

Virtual composite roles refer to the approach of maintaining a document with job (composite) role to core functional role mapping.  But in the system, security administrator will directly assign those core functional roles to users or positions.  In this case, virtual composite role serve only as an out of system reference for assignment. 

Recommendation 5: It is very important to have good role naming convention from the start of the project.  The Organization may consider adding a section in its framework to discuss its security role naming convention.  The naming of the roles should be indicative of its functions and other attributes, such as organizational attributes.  An example of a naming convention document is attached:

naming convetion example.docx

 

Recommendation 6: It is important to have a user strategy in the security framework/strategy document. 

1.     User mapping: User/Position mapping is the process of keeping parallel documentation on assignment of roles to users (e.g. an Excel matrix, or using an application such as SAP GRC Role Expert).  User/Position mapping is a vital step in accurately determining user access to the SAP system, substantially decreasing the risk of inappropriate user access.

Below is an example:

The Process should be followed:

–     Functional team leads map users/position to the core functional roles necessary to perform day-to-day business tasks. 

–     User maps should be forwarded to the security team by the functional teams in order to set up the user IDs accurately

–     Segregation of duties analysis should be performed on a role and user level

2.    User ID source and naming convention: One step in the user mapping process is to determine the user ID source and naming convention.  One option for the organization to consider is to use network ID as SAP ID, making it easier for creating users and standardizing user naming across platform.  When applicable, SAP can pull users IDs and other user information such as address data from LDAP (Active Directory).  User ID and password policy should be defined in the security framework or strategy document.

3.    User provision:  The Organization should be starting the process of selecting and implementing user provisioning application. 

Recommendation 7:  The Organization may consider running SOD checks at different phases of its SAP implementation.  During role design phase, SOD check should be performed at transaction level against the core functional roles defined.  After the roles are built in the system, an SOD check should be performed on the roles in the Development box.  The organization may request its GRC vendor to connect to the development box and perform the check.  After unit testing, prior to the transport of the security roles to QA box, another check should be performed.  After the roles are tested during integration testing and modifications are made, The organization may request its GRC vendor to connect to the QA box and run another SOD check.  In the cutover plan there should be a step to perform an SOD check prior to transporting to production.  In production, the GRC application’s productive instance should be connected to the SAP productive instance upon go live and checks be performed continuously.

Recommendation 8:  Key security parameters should be reviewed and documented in the security strategy document and values approved for input in the system.  Attached below is an example of the selected parameters and settings:

PARAMETER	PRD	QA	DEV
login/failed_user_auto_unlock	0	1	1
login/fails_to_session_end	3	3	3
login/fails_to_user_lock	5	5	5
login/min_password_diff	3	0	0
login/min_password_digits	1	0	0
login/min_password_letters	1	1	1
login/min_password_lng	7	7	7
login/min_password_specials	0	0	0
login/no_automatic_user_sapstar	1	1	0
login/password_change_for_sso	0	0	0
login/password_change_waittime	1	1	0
login/password_expiration_time	60	90	90
login/password_history_size	10	5	5
login/password_max_idle_initial	3	6	6
login/system_client	Depends on SID	Depends on SID	Depends on SID
rdisp/gui_auto_logout	1,800	3,600	3,600
rdisp/max_wprun_time	600	600	600
rdisp/max_alt_modes	3	6	6

The elements of good change control procedures for supporting a complex commercial ERP environment

The factors should be taken into consideration when designing change control procedures and the potential areas of vulnerability, even after well-designed procedures have been put into place

The change control procedure is the key to a successful for any project let alone a complex ERP implementation that spans across countries and involves a suite of products. In my view, and in my practice, I’d consider the following are the key elements in addressing the change control management

• Updated Organizational Change Management Plan: The plan needs to be updated as we are moving over from the blueprinting phase to the realization phase. The realization phase consists of development and technical solutions, will definitely pose a threat to the agreed up on scope. Since this phase has a large scope for the scope creep, a careful amendments to the existing change control plan needs to be incorporated, with the participation of the technical team. In my view, This will involve three main components:

·         Stakeholder Review

·         Risk Mitigation plan review

·         Reviewing Stakeholders

• Sponsorship Engagement: As the realization phase gets traction, there will be a lot of issues that might end up in the following category:

·         Solution is available

·         One or More solutions are available

·         No Solution available: Vendor may provide a solution.

·         No Solution available and the vendor can’t provide a solution.

Since this process is going to go back and forth between the technical teams, business teams and the users (project group), time is of the key element. An SAP suite of solution which has an intensely integrated applications, demands that the issues are raised, discussed and mitigated in time to avoid project slip overs. And also as against the blueprinting phase, here the solutions are tangible and options have to be finalized. I’d think of the following factors are important in this section:

·         Targeted sponsorship report and updated action plans (BRA): This will keep the focus on the people who need to take decision and to facilitate the escalation process to gain visibility.

·         Leadership Coaching: To make faster and effective decision

·         Critical Conversation: Involving all functional streams related to the issues.

• Communication during Realization: As I said, time is the key element as we develop technical solutions and start closing the issues. Since the ultimate approval or suggestions for improvement belongs to the business, a proper communication plan needs to be established and maintained. In my experience, I’ve taken the following steps:

·         Key Messages during Realization: This needs to be done as a periodic process. The team as a project group allocated a specific time to discuss the issues, follow ups and the options available. An issue owner is identified to take the issue to the closure.

·         Optimized FAQ Database and Feedback Loops: In my experience, Most of the issues will have a similar path to the resolution. This process is very critical, so that the focus is on the issue as a whole as against ‘bits and pieces’ of information.

·         Updated Communication Plan: As the realization process unfolds, proper adjustment to be made to the communication plan (This is a part of the best practices of project management)

·         Maintaining the Communication Plan

• Organizational Alignment: This part in specific to the technical solution pertains to the job roles for the end users and how the business functions are mapped in the system as transactions and approval process. As an overall technical solution lead in my current project implementation I’ve spent a great deal of work in this cross application area and consider the following key steps:

·         Organizational Impact Review

·         Job Role Impact Assessment

·         Organizational Alignment Strategy Update

·         Assessing Job Role Impacts

•  Project Team Change Management: This pertains to all forms of project phase and I think the following are the key components and I strongly believe in this as I’m as good as my team.

·         Effective Project Teams

·         Maintaining Project Team Efficiency

The areas of vulnerability are the scope creep that happens as a part of the technical solution. This happens predominantly, if the person or the team does not have a clear understanding of the business process or the understanding of the SAP’s solution architecture. The focus on enhancements that are not supported by SAP, pose a great risk of non-compliance and will affect the future upgrades. This I call it as unnecessary customization lead in to huge development component. The rational for this ‘WILL’ happen in most cases is:

Customization and development of all sort of add-ons to make SAP pleasing seems to be gratifying activity for analysts, developers and sometimes even users. However, first they cost, second, when all pros and cons are considered they often become liabilities to the project and in longer-term to the organization. I insist they should not be done whenever they can be avoided but still it comes easy to justify doing them. We need to take them under effective project governance. I’ve devised a four step principle to avoid it:

·         Adapt before build. First adopt SAP standard functionality wherever possible. Convince users to adapt: check if process can be tweaked if cannot adopt SAP functionality. If process cannot be tweaked are there any workarounds?

·         For any type of request that is not part of standard SAP, analyze the requirements first. Is it really required? Can we use standard SAP data element (note if this is a SAP standard field consider future usage of that data element). Just because it may not be used now does not mean it will never be used.

·         For reports, check standard reports to see if most of the requirements can be satisfied

·         In case of screen simplification, we either simplify the existing screens or if the function is simple (e.g. infotype maintenance) we can build from scratch. But we cannot apply the same to other complex transaction (e.g. PO or Sales order entry). In summary we do not reproduce SAP functionality.

Further to that these were translated in the change control process as:

·         Before considering a custom solution the functional analysts develops a thorough understanding of the requirement and validates it; checks standard solution, proposes alternatives or workarounds if standard solution is not available.

·         In case it is a showstopper – a critical requirement, the functional analyst defines the requirements for custom solution. The custom solution has to be completely defined in terms of why it is needed, what are the consequences of not developing the custom solution, any business implications around this.

·         The definition of the custom solution needs to be submitted to technical team lead who can then decide whether to conduct technical feasibility and estimation of effort and impact on development. The technical lead may decide not to develop the custom solution based on the priorities and workload and specifics of a request – then it will be the end of the procedure.

·         The technical lead forwards the definition of the custom solution along with the feasibility, resource, and impact summary to Project Technical Manager, who is authorized to issue a final negative decision.  Project Technical Manager will communicate the decision to the technical and business lead.

The elements of a high-level project plan for designing, building and testing the technical solution, assuming FRICEW elements will be required for every major area

The High Level project plan that any SAP global implementation, which can follow any project management methodology should fall in the following categories. I myself had implemented one complete global SAP implementation for an UN agency and had followed SAP prescribed ASAP methodology. The steps are

o   Project Preparation

o   Business Blueprint

o   Realization

o   Final Preparation

o   Go Live and support

Before going in to the details of the technical solution, which predominantly happens in the realization phase, I need to make sure the following four facts are considered even during the business blueprint. Even though in many occasions, the business blue printing may be software agnostic, when considering SAP suite as a solution, I’d like to point out the following facts, which I strongly believe and follow, to demystify the whole process and the need for a ‘technical solution’ expert to handle them.

• The first and foremost fact is the SAP IS-PS software, off the shelf product, how best maps to the requirement of your business process. Even though the golden rule of a SAP application implementation is to have minimal customization to avoid the complexity and the total cost of ownership; it is unavoidable to get in to the discussion of what amount is considered as safe for the organization to undertake the customization.  The new SAP application architecture provides some interesting and compelling features that can manage this argument effectively, because the out of the box software (SAP IS-PS) is either too much or too little, and is always not enough.
• The next fact that needs to be understood is that the core business process of a public sector is completely opposite of the conventional industry. The significance of the application component integration within the public sector solution is more pronounced as against the others. The integration of Funds management and budget control system is a distinct example of this. This tight integration needs higher degree of technical understanding in providing the solutions for the process or business issues. The ‘technical solution’ that is taken as an overarching principle in all areas of the project stream.
• The third fact is the need of real-real time reporting and the availability of real time data across the platform. Even though this requirement is pronounced in the UN agencies is traditionally undeserved, lacks competency and depth. And also the global SAP implantation projects take years of implementation, years of stabilization demands the nature of the technical solutions to be able to handle the business requirement for a considerable future.
• Finally, it is the subject of sustainability and making the project reflect that we are socially responsible as the organization and its mission. There are certain functions that UN requires are not in part of the SAP’s core system. This will require buying and installing bolt on systems either belonging to SAP’s suite or third party systems. In either way these decision incur a set of hardware, software, processing and maintenance. This increases not only the total cost of ownership, but also the greenhouse gas emissions. Utmost care should be taken to avoid any bolt on system as long as they are unavoidable. Sensible architecture approach will eliminate majority of these requirements

The Major elements of the development comprise of the FRICFW components, which would have been identified in the business blue print phase. But in reality, it is a process of progressive elaboration. In my experience, there were instances that some of the business requirements that were not possible, some of them had to change and some of them were created after understanding the possibility. The following are the steps I insisted, followed and believe in the realization phase, where the technical solutions are designed, build, and tested.

·         General Project Management (Realization Phase): This needs to be created based on the outcome of the business process blueprinting

·         Organizational Change Management: Is a key component that needs to be addressed upfront. This includes the increasing the awareness, managing the user expectation, keeping the scope of the project intact and focusing the milestones.

·         Training and Documentation (Realization Phase): This process needs to be taken seriously, as this is addition with the project communication plan will affect the end users directly. Development od end user training templates, modes of delivery and creation of the content are to be performed here.

·         Developments, User Interface, Integration: This is the key area where the technical solution plays an important part. All agreed and approved developments are managed here. I’d followed and insisted to have one project plan for the entire development effort, but would split it in to multiple streams of business functions (Programme. Finance, HR, Supply and common functions). I’ll detail the development process in the next section (Managing the technical solution)

·         Baseline Configuration: SAP System is configured with the baseline information and is pretty much ready for the unit testing

·         Quality Assurance Installation: Testing instances are created. And both functional tests (unit test, Integration test, User acceptance test, Systems integration test, Data test & Security tests) and performance tests (Volume testing & stress testing) are performed to validate the final product. All defects that are identified in each cycle are classified, prioritized and remediated. Care should be taken to differentiate the defects and the change requests.

·         Cutover and Go-Live Planning

·         Lifecycle Data Management

·         Authorizations and Security Implementation

·         Final Integration Test

Managing technical solution and Design Thinking in all areas (FRICEW)

• Any business requirement that has been established in the blue print may convert in to the one of the following during the realization phase. The following should be the sequence of actions while providing a technical solution:
• Standard product supports the process
• Standard product supports the process with enhancement
• Standard product does not support the process, go back to business and suggest change in the process
• Standard product does not support the product and the business cannot change the process, then think of ‘custom development’
• The talk about of the Custom development is treated, as a sin in the SAP implementation world, is partly true and partly exaggerated. The true part is that the any custom development that needs to be built by the customer poses a risk of future upgrades and loss of SAP’s standard support. But the no-so true part is the increase in the total cost of ownership. This is because the lack of knowledge in this area and the lack of the understanding of the architecture of the SAP product itself. A typical global implementation solution would be somewhere 80% standard configuration combined with 20% of custom development to reflect the agreed upon business process requirements. But because of the lack of knowledge of how and where to implement and provide custom enhancement had greatly affected the implementations. The core principles that needs to be followed are:
• Aligning with SAP’s architectural components and (to eliminate upgrade risk)
• Non-destructive construction of custom developments (for SAP’s support)
• The biggest challenge that is faced by any SAP implementation, in particular is to go back to business to explain them that their genuine, simple requirement can’t be reflected in the system quite simply because the underlying software does not allow the change. This was very acceptable argument till last few years, when SAP was considered as the collection of business processes that are ‘the’ benchmarked practices and should be followed unequivocally by all businesses. But recently SAP they themselves understood their non-rational statement and rebuilt their product on enterprise service oriented architecture (e-SOA). This enables the customer who is implementing this process to orchestrate their business process in the way they want and to focus and minimize the custom development. If one follows this methodology and build the final product, this will yield highest business buy-ins and ultimately reduce the total cost of ownership (TCO).
• SAP’s Accelerated SAP (ASAP) implementation methodology supports these custom developments and encourages the business to start this ‘design thinking’ even during the blue printing phase. In reality they themselves do that with many customers. I had worked with them in developing the SAP-HR and payroll for NPO solutions and have a first-hand knowledge of how SAP build the solution as a customer development and merge the CDP solutions into them in their own future products.

The Open Group Architecture Framework

I've made a comprehensive presentation on the overview and the architecture in the following presentation:

Printing in SAP

Printing from SAP should be an easy task, however the nature of SAP and the options available make it a little bit difficult. One of the most important and less realized factor is the user of all sorts of page layouts in your print forms.

SAP has traditionally integrated the printing forms to the transactions by what is called Sapscript. This is very similar to the html scripts but with a lot of restrictions. Even though it is very old technology, it is still predominantly used all over the application suite.

The evolution of the sapscript is called smartforms. This also used in many of the applications. Currently SAP supports the ADOBE print forms as apart of the netweaver suite, but is not being adapted widely in the traditional transactions and correspondence forms.

During a global roll out, one simple task will come back and haunt you is to make the print forms available in all printers (drivers) and all page sizes. This is very important as the SAP's document print forms are set with the print characteristics at the design time. This means the page layout is set at the design time and not changeable when you want tot print.

To overcome here is the simple solution: Printing in SAP

E Recruitement for Public Sector

I have implemented one successful e-Recruitment project, which is a SAP product that resides outside SAP. SAP provides you with an option of integrated or distributed recruitment system. We based on out business requirement, opted for the distributed model and that brought in a lot of complexities. This Integration Document, is a starting point for a typical distributed scenario.

Public Sector Metrics

I came across an interesting article on Public sector metrics in SAPPHIRENOW conference. I'll make my comments later.