How to Engineer an Effective Access Review Program

1. How to Engineer an Effective Access Review Program Ram Ramadoss, Staff Information Security Engineer, Ram.Ramadoss@qwest.com September 25, 2008

2. Agenda Definitions Challenges Common Mistakes Made by Organizations Access Review – Applications, Systems and Databases Summary Q & A

3. Definitions Identification Authentication , Authorization and Accounting (AAA) Access Control, ACLs (Access Control Lists) Role Based Access Control & Rule Based Access Control Least Privilege (Need to Know) & Segregation of Duties (SoD) Access Review

4. Definitions (contd…) • PCI (Payment Card Industry) • SOX (Sarbanes-Oxley) Act of 2002 SOX Section 404: Assessment of internal control

5. Applications/Databases and Servers – Access Overview

6. Challenges Small Organizations: Many users may have full access to the system Users may perform multiple functions - Development, Test and Production Group/Shared Ids - individual accountability issues Large Organizations: Large number of users and systems Mainframe and Legacy Systems User Provisioning managed by multiple groups Lack of custom tools for access review Contractors, Partners and IT Outsourcing Validation of non-personal ids, shared ids and ownership

7. Common Mistakes Made by Organizations “Compliance Says So” Confusion between compliance and security Not taking a risk based approach Not defining the scope of review Tool centric rather than process centric Unable to sustain repetitive access reviews No central compliance monitoring group

8. Access Review – High Level Overview Policies and standards Scope of review, frequency, all types of ids (employee / contractor, group ids, system ids…), authorization levels, systems, provisioning and de-provisioning processes Discovery – Extract ids from sample systems, analyze ids, reverse engineer and identify access and authorization rules based on the current access Business SMEs, Production / System Admins and DBAs support crucial Validate ids against access and authorization rules; Obtain management approvals; Identify ids and authorization levels for clean-up;

9. Access Review – High Level Overview Set-up scripts to extract ids and authorization levels Repeat access review process at least every 90 days Review provisioning process - include management approvals and access/authorization rules De-Provisioning must address terminations, users leaving business and moving to other job functions

10. Access Review – HighLevel Flow

11. Access Review – Applications Overview J2EE, DotNet, Mainframe, Legacy, COTS and ERP Business Unit users – large population Large number of applications Challenges Lack of process, documentation andaccess / authorization rules No consistent user id or naming standards – difficulty in mapping individual users Provisioning managed by multiple groups

12. Access Review – Applications Challenges Applications may not use central/core authentication systems Group/Shared Ids, System Ids – Ownership and Accountability Transfer of users within the company No third party tool to address access review for complex application environment Approach Rule based access and periodic access review Conduct reverse engineering – Map ids to users, Job Titles, Business Units, Department Work with business unit contacts to extract access /authorization rules Identify owners for non-personal ids and obtain access and authorization approval Majority of the ids can be mapped to access /authorization rules

13. Access Review – Applications Approach (contd…) Ids with no access/authorization rules – Management approval is required Important Things Access/Authorization rules must be used as part of provisioning Applications with local authentication – Daily process review must be in place to disable/remove employees and users leaving the business 90 day access review – Validation of user ids against access and authorization rules Management approval for remaining ids; Conduct ongoing clean-up Auto Process to suspend Ids with no activity for more than X number of days

14. Access Review – Applications

15. Access Review – Applications Sample Access and Authorization Rules: Sales Consultant from Business Unit A shall have READ / UPDATE access to “Sales” application Repair Consultant from Business Unit B shall have READ access to “Sales” application Administrator Id must be approved by XXX (Segregation of Duties) Further Research Required: Owner must be identified for System Id1,Systems Id2, GroupId1 and GroupId2; Access and authorization levels must be validated; Rules can be created based on the validation Personal Id5 must be challenged – Why does an IT user require update access?

16. Access Review – Operating System Overview Many users may have privileged access Some ids have standard access and authorization levels Windows / UNIX and Mainframe Challenges Provisioning managed by multiple groups Difficult to derive access and authorization rules Difficult to re-validate access permissions UNIX systems – may not use central authentication UNIX servers may have several invalid/inactive ids

17. Access Review – Operating System Approach Sys Admins, Production Support Users and DBAs play a crucial role Extract ids and privileges. Access Review must cover all ids at the server Identify system accounts, global groups and privileges for each platform (Windows / UNIX) Access/Authorization Rules for system Ids and Ids/groups supporting multiple servers and Ids for application/database access Administrators, Back-up Operators, Help Desk or Support teams Remaining ids require management approval

18. Access Review – Windows Server

19. Windows Built-in Users and Built-in Groups

20. Access Review – Mid-Range Databases Overview Oracle, SQL Server, Informix, Sybase Potential data exposure areas Critical data - Company financial data, Customer financial data Challenges Databases may not follow consistent user id or naming standards – difficulty in mapping individual users Provisioning may be managed by multiple groups User ids may be used for database processes Developers / Business user access to databases

21. Access Review – Mid-Range Databases Challenges (contd…) Oracle databases may not be using central authentication Application Ids with DBA privileges Approach Identify users with DBA and Non-DBA privileges for each database Provisioning -strict management approvals for DBA access SoD – Restrict Developers and Testers access Identify owners for Non-Personal Ids – access and passwords restrictions Minimize Group/Shared Ids access to the database

22. Access Review – Mid-Range Databases Approach Risk based approach – identify critical tables that contain sensitive data Identify users with DBA and Non-DBA privileges for each database Provisioning process - strict management approvals for DBA access SoD – Restrict Developers and Testers access to production

23. Access Review – Mid-Range Databases Approach (contd…) Explore AAA central authentication Authorization - Tables that contain sensitive data Logging and Auditing - monitor privileged user access Access and Authorization rules for users with DBA Job Tiles and System Ids, Quarterly review of all user ids Ids with access and authorization rules Remaining ids require management approval

24. Access Review – Mainframe Databases Overview DB2, IMS and Legacy Databases RACF Authentication Challenges Access can be granted independently databases, tables, views and datasets Some databases may have 1000s of tables Development/Test users - access to production environment Difficult to encrypt data in mainframe databases

25. Stakeholders - Engagement • Engage Business unit contacts, Application contacts, System Administrators, Application Administrators, DBAs • Access and Authorization Rules • Provisioning and De-provisioning • Management approvals • Engage Security Compliance, Internal Audit and External Auditor to review for compliance

26. Summary – Access Review • Access Review Standards and Processes • Access Review should include validation of access/authorization rules and management approvals • Provisioning processes - access/authorization rules and management approvals • De-Provisioning process - terminations and users leaving the business. Automated processes to de-activate invalid user ids • Central authentication - AAA (Authentication, Authorization and Accounting)

27. Summary – Access Review (contd…) • Contractors, Service Providers and Partners access review - contractual requirements and oversight • Group/Shared Ids - ownership and access restrictions. (password expiration at periodic intervals and when users leave the business or transfer within the company) • Development/Business users - restricted access to production databases and operating systems and least privileged access • Logging and Auditing - monitor privileged user access • Remote Network Access, Network Element Access & Central Authentication - Access Review

28. Q & A