Texas Instruments: Making the Journey from Home-Grown SoD Compliance to SAP GRC AC 10.0 Chris Fowler Solution Architect, Texas Instruments Vicki

Transcription

1 Texas Instruments: Making the Journey from Home-Grown SoD Compliance to SAP GRC AC 10.0 Chris Fowler Solution Architect, Texas Instruments Vicki Purcell Senior Associate, PricewaterhouseCoopers

2 About Texas Instruments

3 TI s SAP Landscape Single global instance of ECC 6.04 Originally implemented R/3 4.01B in Jan 1999 Not using SAP for HR processing Approximately 12,000 users world-wide Also running single instances of: GTS 8.0 SRM 4.0 (being upgraded to 7.0) CRM 4.0 (being upgraded to 7.0) SCEM 1.1 (being upgraded to EM 7.0)

4 Learning Points How TI: Replaced a limited, custom SOD management solution with standardized SOD controls. Managed implementation of SOD controls and remediation in one project. Moved from job-based security roles to task-based security roles.

5 Challenges & Revelations Existing access request process was not adequate Need to implement a new access request tool Existing SoD tool was not adequate Need to implement a new tool to standardize SoD management Scope of violations in existing roles was too large to mitigate Need a new approach for SAP security design

6 Challenge #1 Existing access request process was not adequate Sensitive access approval decentralized and manual No integration of custom SoD tool with access requests Manual security provisioning after approvals All reminders and escalations generated manually No enforced SLA - requests taking 2 days to 3 months Inadequate archiving of security requests Firefighter process was ad-hoc

7 Revelation #1 Need to implement a new access request tool SAP GRC Access Control 10.0 ARM and EAM Access Request Management (ARM) Replace manual provisioning Emergency Access Management (EAM) Replace ad-hoc firefighter process

8 Challenge #2 Existing SoD tool was not adequate Custom SoD tool only did Role-to-Role analysis Rules checked for roles that should not be combined Only evaluated violations in the ECC system Only evaluated business risks Mitigating control documentation was only at individual user level Internal Audits found that this level of SoD analysis was not effective

9 Challenge #2 - Example Example: TI Rule #3: Returns Administration and Advanced Receiving Role A: RL143 Returns Administration - VS - Role B: RL119 Advanced Receiving Tool would only flag this role combination as an SoD violation

10 Revelation #2 Need to implement a new tool to standardize SoD management Evaluated several different compliance solutions Decided on SAP GRC Access Control 10.0 ARA Convert TI role to role ruleset structure to GRC s function-risk structure Create more comprehensive SoD rules SAP standard GRC rules TI unique rules PwC leading practice rules

11 Original Project Scope Phase 1: Implement ARA and EAM Define TI SoD ruleset and run against ECC and GTS systems Assign IT users broad, individualized firefighter ID s Complete in October, 2012 Phase 2: Implement ARM and finish EAM Define Access Request approval workflows Final definition and assignment of Firefighter users Complete in February, 2013

12 Challenge #3 Scope of violations in existing roles was too large to mitigate SoD analysis showed an unexpectedly high number of violations Intra-role conflicts were biggest problem User conflicts very high, especially in IT support SoD violations that had not been tracked before What now?

13 Revelation #3 Need a new approach for SAP Security design Clean up existing violations within roles Be sustainable over time Introduce least privilege access for all users

14 Security Approach Options Option 1: Remodel Split roles to single out conflicting transactions Remove authorization objects from specific roles Benefits Provides quick(er) incremental fixes Addresses easy issues Risks Create additional roles which increase maintenance costs Corrects initial issue, but could cause long-term issues Could be more costly in long term Repetitive process required to fix all issues Duplication of access and mixed design complicates provisioning

15 Security Approach Options Option 2: Rebuild Build all new security roles Use transaction usage history, role mapping templates, etc. Implement consistent design meeting business and regulatory needs Benefits Complete SoD remediation much sooner Long-term fix to issues Continuous compliance is possible (get clean stay clean) Reduce maintenance and compliance costs Provides sustainable provisioning design with GRC Efficient resolution of all SAP Security Assessment audit red flags Risks No immediate impact on SoD statistics Will require change in mindset of business and security team

16 Role Design Decision Decision Point: Keep Job-based role model or switch to task-based roles? Pain points with job-based roles: More difficult to control SoD violations Excessive duplication of transactions Roles provide excessive access to the users who only need some of the functions Broad definition of job roles permit them to grow over time Least privilege concept is more difficult to implement with job roles Conclusion: In TI s dynamic environment, designing new job-based roles would have resulted in overly broad access or in a huge number of individually tailored roles

17 Role Design Decision TI s decision: implement task-based role model All roles free of intra-role SoD violations Minimal duplication of tcodes across roles Roles are designed to lowest common denominator to make them reusable Easy to implement least privilege concept User SoD violations are handled with role unassignments rather than role changes Eliminate non-used tcodes from new roles

18 What Task-Based Roles What are task-based roles? What are task-based roles? TIER 1: GENERAL ACCESS General access is provisioned via one single role made up of tasks common to all users, such as printing, inbox, SU53, etc. Where Contract Maintenance AR Common Display Company Code: 1003 User General Process Billing FI Common Display Sales Organization: 1003 Tier 1 Vendor Master Maintenance Tier 2 Tier 4 Tier 3 TIER 2: DISPLAY ACCESS Display access is provisioned via a set of roles defined by functional area that allow display and reporting access intended to compliment the functional roles of the users TIER 3: FUNCTIONAL ACCESS Functional access is provisioned via multiple single task based roles. Role grouping of activities that are the lowest common denominator of tasks and permission components to suit the needs of the end users. These groupings usually are SOD free and part of a sub-process such as Invoice Processing or Material Master Maintenance. TIER 4: CONTROL POINTS Roles that provide additional control point access or granularity needed by Tiers 1-3 such as Company Code, Plant, etc.

19 Project Scope Change Where does role redesign fit in the project scope? Decided to integrate the role redesign and GRC Access Control implementation into a single project Extended Phase 2 (ARM) to complete May, 2013 Added Role Design project to execute in parallel

20 Metrics Increased SoD risk visibility by 700% Decreased number of transactions in roles by 50% Reduced transaction duplication in roles by 97% Eliminated 100% of manual and changed authorizations Eliminated 100% of intra-role SoD violations Reduced SoD user violations by 97%

21 Key Learnings This is rocket science! (you need experts to help) Ensure availability of the core team In a highly customized environment, having a Developer on the project team is key GRC doesn t end with the implementation Be prepared for the potential results - you really don t know how bad the SoD situation is You may not eliminate all SoD violations by segregation

22 SoD Compliance Process Compliance Effort Breakout Mitigation 10% Ruleset Customization 30% Remediation 20% Role Redesign 40%

23 Best Practices Do not allow business users to have direct access to tables and programs Make sure you have at least 12 months of transaction usage data Have separate transactions for display vs. update SAP Security Team should be involved at the beginning of any development project Ensure all roles are free of intra-role violations to make user remediation easier Ownership of risk and role management must belong to the business, not IT Do not underestimate business readiness requirements

24 Key Benefits Automation of security provisioning processes allows SAP Security Team to focus on proactive activities Greater visibility to mitigated and unmitigated SoD conflicts Provides tools to empower the business to own their risk management process Audit independence

25 Questions?

26

27 THANK YOU FOR PARTICIPATING Please provide feedback on this session by completing a short survey via the event mobile application. SESSION CODE: 0901 For ongoing education on this area of focus, visit