How to Engineer an Effective
Access Review Program
Ram Ramadoss,
Staff Information Security Engineer,
Ram.Ramadoss@qwest.com
September 25, 2008
1
Agenda

Definitions

Challenges

Common Mistakes Made by Organizations
Access Review – Applications, Systems and
Databases


Summary

Q&A
2
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
3
Definitions (contd…)

PCI (Payment Card Industry)

SOX (Sarbanes-Oxley) Act of 2002
SOX Section 404: Assessment of internal
control
4
Applications/Databases and Servers –
Access Overview
AAA
Central
Authentication
System
Users
Database 1
Database
Users
Server X
A
P
P
L
I
C
A
T
I
O
N
U
S
E
R
S
Server Y
Application A
Database 2
Database
Users
Application B
Database 3
Application C
Database
Users
Server Z
Local
Authentication
System
Users
Database 4
Database
Users
5
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
6
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

7
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;
8
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
9
Access Review – High Level Flow
A
User List – Access
Levels
access rules
require revision
Employee
Information - HR
Review access
rules
Validation of rules
and next steps
A
Review
ids with no access
rules
Document
Revisions
access
and/or
authority
levels
require
revisions
Access /
Authority
changes
requires
management
approval
Management
Approval
Complete Access
Review
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 and access / authorization
rules
No consistent user id or naming standards – difficulty in
mapping individual users
Provisioning managed by multiple groups
11
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
12
Majority of the ids can be mapped to access /authorization rules
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
13
Access Review – Applications
Id
Privileges
Name
Job Title
Department
Personal ID1
READ / UPDATE
John
Sales Consultant
Business Unit A
Personal ID3
READ / UPDATE
Linda
Sales Consultant
Business Unit A
Personal ID4
READ / UPDATE
Joe
Sales Consultant
Business Unit A
Personal ID6
READ
Ruby
Sales Consultant
Business Unit A
Personal ID2
READ
Mary
Repair Consultant
Business Unit B
Personal ID7
READ
Terry
Repair Consultant
Business Unit B
Personal ID8
READ / UPDATE
Mike
Repair Consultant
Business Unit B
Personal ID9
READ
Wendy
Repair Consultant
Business Unit B
Personal ID5
READ /UPDATE /
DELETE
Ron
Development Engineer
Department IT
SystemId1
READ / UPDATE /
DELETE
SystemId2
READ / UPDATE /
DELETE
GroupId1
READ / UPDATE
GroupId2
READ / UPDATE
Administrator Id
READ / UPDATE /
DELETE / Add
Users
14
Business Unit A
Access Review – Applications
Sample Access and Authorization Rules:
1.
Sales Consultant from Business Unit A shall have READ /
UPDATE access to “Sales” application
2.
Repair Consultant from Business Unit B shall have READ
access to “Sales” application
3.
Administrator Id must be approved by XXX (Segregation of
Duties)
Further Research Required:
1.
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
2.
Personal Id5 must be challenged – Why does an IT user require
update access?
15
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
16
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
17
Access Review – Windows Server
Id
Privilege Group
Group
Name
Job Title
Department
Persoanl ID1
Administrator
Domain\Administrator
John
System Administrator
Department IT
Persoanl ID3
Administrator
Domain\Administrator
Linda
System Administrator
Department IT
Persoanl ID4
Administrator
Domain\Administrator
Joe
System Administrator
Department IT
Ruby
System Engineer Production
Application Support
Department IT
Department IT
Persoanl ID6
Administrator
Domain\Administrator
Persoanl ID2
Administrator
Domain\Domain Administrator
Mary
System Engineer Production
Application Support
Persoanl ID7
Administrator
Domain\Administrator
Terry
Development Engineer
Department IT
Persoanl ID8
Backup Operator
Domain\Back-up Operator
Mike
Analyst
Department IT
Persoanl ID9
Administrator
Domain\Administrator
Wendy
Project Manager
Business Unit 1
Persoanl ID5
Power User
Domain\Global_Group_1
Ron
Business Analyst
Business Unit 2
SystemId1
Power User
Application X
SystemId2
Power User
Application Y
GroupId1
User Right
Developers,
Department
IT
18
GroupId2
User Right
Business Unit 1
Built-in Groups
Windows Built-in Users
and Built-in Groups
Built-in Users
Account Operators
Administrator
Administrators
Anonymous
Authenticated Users
Guest
Backup Operators
Local System
Domain Admins
Domain Computers
Domain Controllers
Domain Users
Enterprise Admins
Everyone
Group Policy Creators Owners
Guests
Network
Power Users
Print Operators
RAS and IAS Servers
Remote Desktop Users
Server Operators
19
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
20
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
21
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
22
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
23
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
24
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
25
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)
26
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
27
Q&A
28