Access Control Guide

Access to programs and data
© [year] [legal member firm name], a [jurisdiction] [legal structure] and a member firm of the KPMG network of independent member firms affiliated with KPMG
International, a Swiss cooperative. All rights reserved. Printed in [country in which the publication will be printed]. 1
FOR INTERNAL USE ONLY
Security Model - Overview
♦ Relationship of General Control

Security and Application
Security
− Application Security Processes
Processes
• Our security testing at the s
application level must be Application
Applications
adequate to achieve the s
process level audit objectives Data/
Data/DBMS
− General Controls DBMS
Platform
• For General Controls we must Platforms
test database, operating s
system, and network security Networks
Networks
(at the general controls level) to
a sufficient extent to conclude Physical
Physical
that we may rely on the l
application security controls
KPMG Perspective on
Access to Programs and Data
1. Information Security Policy/User Awareness

2. Physical Access
3. Configuration of Access Rules
4. Identification and Authentication
5. Access Administration
6. Monitoring
7. Super users
Security Policy/User Awareness
Objectives
♦ Issuing and maintaining an information security

policy.
♦ End-users should be aware of their roles and

responsibilities with respect to access to programs
and data.
TOD/TOE
1. Information Security Policy

The entity has a comprehensive IT security policy in place which is
available to all relevant staff. Clearly communicated to all staff.
TOD
♦ Inquire whether the entity has a security policy/policies.
♦ Inspect the policy and ensure it covers all key areas of IT security (see
next slides).
♦ Who compiled the policy? Do they have the right
qualifications/experience?
♦ Is it based on a risk assessment?
♦ Who approves policy? Is it enforced by management?
♦ Is there a process in place for updating the policy?
♦ Where is the policy kept? Can it be accessed by all employees?
(intranet, public folders, emailed, etc.)
TOD/TOE
TOE
- Review policy to confirm approval and periodic
review/update.
- Confirm policy is available to all employees.
Considerations
♦ Review content of policy, as a minimum would expect it to contain:
− those responsible to enforcing the policy.
− Logical access controls.
− rules surrounding physical computing assets.
− employee responsibilities.
− movement of data.
− virus controls.
− Backups.
− change management and system development.
− internet usage.
− e-mail.
In general ensure that ITGC sections are covered in the policy and
relevant to in-scope systems.
TOD/TOE
2. User awareness
End-users are aware of their roles and responsibilities with
respect to information security.
TOD
♦ Determine whether end users have received appropriate
information security awareness sessions.
♦ Review the security policy to ensure that it addresses the
information security responsibilities of end users (or separate
end user information security policy has been prepared).
♦ Ensure that users sign non disclosure agreements. Test sample
if available.
TOD/TOE
TOE
- Select sample of users and ensure they have signed
the non disclosure agreements
(consider KAM sampling. If 52 users = weekly
control, i.e. Select 8 samples).
- Confirm policy is available to all employees.
- Inquire sample users to determine they are aware of
the information security policy.
TOD/TOE
3. Security function (for certain cases only).

The entity has established an information security function that is
appropriately positioned and is independent of development and
operations.
TOD
♦ Inspect the entity’s organizational charts.
♦ Inquire about the responsibilities of the security function and review the
job description.
♦ Determine responsibilities are appropriate given the nature and size of
the organization.
♦ Inspect one of the periodic reports of the security function and
determine that the content appropriately reflects its duties.
TOD/TOE
TOE
- Inspect additional reports based on KAM sample
size.
NOTE
The difference between the security function and IT
internal audit.
- Responsibilities.
- Independence.
KPMG Perspective on

2. Physical Access
6. Monitoring
7. Super users
Physical Access Controls
Objectives
♦ Physical access to information systems relevant to
financial reporting is appropriately restricted to
authorized individuals.
TOD/TOE
1. Physical Access Controls
Physical access to computer facilities that house the financial applications
(including DBs and network devices) is restricted to appropriate personnel.
TOD (all computer rooms related to in-scope systems should be reviewed).

♦ Observe the computer room/s and determine that appropriate physical
access and environmental controls are in place. (see next slide)
♦ Is access to computer room/s restricted? Who to? Does this seem
appropriate?
♦ Is access to computer room/s is subject to a formal access administration
process?
♦ Inquire about the procedures for granting visitors access to computer
room/s and determine if those procedures are appropriate.
TOD/TOE
TOE
♦ Ensure that the fire suppression system is inspected
annually - (evidence)? Are hand-held fire extinguishers
tagged for inspection and inspected annually?
♦ Obtain a list of current year leavers from payroll/HR and

ensure all are removed from the access system or
authorized list. If not applicable select a sample based
on KAM sampling.
Considerations
♦ Physical access controls
− Door locks – bolting/electronic/Biometric.
− Logging – Manual/Electronic.
− Identification badges (photo IDs).
− Video cameras/ Security guards.
− Controlled visitor access.
− Location of the rooms.
♦ Environmental controls
− air conditioning.
− fire suppression system using materials as (FM2000, COs or Halon).
− Hand held fire extinguishers and smoke detectors.
− UPS (Uninterrupted power supply).
− Generators in case of certain clients.
− Flammable materials!!
♦ In smaller less complex companies we would do very limited testing as this

risk is minimal
KPMG Perspective on

2. Physical Access
6. Monitoring
7. Super users
Configuration of Access Rules
Objectives
♦ IT systems often have the ability to define certain
roles or profiles with defined access to programs
and data.
♦ This is the basis for ensuring that individual access

opportunities are limited to job responsibilities.
Examples
− A key client assertion-level control dictates that
no staff outside the finance department should
have access to the accounting module
− The system should contain a ‘role’ or group of
users that only have access to the accounting
module.
− The system should have the ability to add only
finance department employees to this group
TOD/TOE
1. SOD
Controls are in place to allow for effective translation of
business rules into system access rules
TOD (per system)
♦ Inquire whether rule based authorization (group/role) or
individual assigned privileges are used for in scope systems.
♦ Inquire that users assigned different levels of access based on
their job role.
♦ Check the system to understand how is this assigned? E.g.
assigning individual menus or responsibility levels containing a
number of menus.
♦ Ensure that there is a specific mapping/Matrix in place for
assigning access rights or are levels assigned on an ad hoc
basis.
TOD/TOE
TOE (per system)

♦ For each in-scope system select a sample of users (in
line with KAM sampling) and compare the access
rights of the users to their job role and ensure
appropriateness.
♦ Discuss any concerns/queries with the systems
administrator, information owner or line manager.
TOD/TOE
2. Internal Audit
Internal Audit or other entity management performs a
periodic review of the entity’s segregation of duties.
TOD (covers TOE)

♦ Inquire whether IA or other independent entity performs a
periodic review of SOD.
♦ Inspect the periodic review of the entity’s segregation of
duties by internal audit or management including follow-
up of identified issues.
SoD – Key Areas to Look Out For
− Excessive full system admin access by IT and

business unit personnel.
− “Super User” or “end user” access by IT
personnel/business unit that can process a
transactions from start to finish circumventing all
controls.
− Too many “Super Users” override process level
controls (business or IT).
− IT or business unit personnel who can change
configurations.
− IT developers with access to production.
KPMG Perspective on

2. Physical Access
6. Monitoring
7. Super users
Identification and Authentication
Objectives
♦ The use of a userID and password (user’s credentials
for ), or other more robust methods.
♦ Access to programs and data is appropriately
restricted by the implementation of identification and
authentication mechanisms.
♦ Effectiveness of authentication controls (e.g.,
passwords).
♦ Sufficient logical security controls in place for
applications and systems that support financial
reporting (e.g., network, infrastructure, applications,
databases, etc.).
♦ Key Elements:
− No shared id’s
− Password rules (or other mechanisms) that are appropriate to the
relevant risks, including:
• Initial password change after first logon (review procedure during
access administration).
• Complexity:
− Minimum password lengths (6-8).
− Alpha-numeric and special characters.
• Forced password changes (30-90).
• previous passwords cannot be reused (eg. last 10)
• a limited number of login attempts before the user account is locked.
♦ User ID’s and Passwords need to be in place for:

✓Network
✓Operating system
✓Database
✓Application (most important if system supports
Segregation of Duties at process level)
TOD/TOE
1. Identification
♦ Individual User-ID’s should be issued for each user.
No shared logon is allowed to provide accountability
of transactions.
TOD
♦ Inquire about the access mechanisms in place.
♦ Check whether a standard naming convention is in
place for user-IDs.
♦ Observe a user accesses to the in-scope systems and
check identification and authentication method.
TOD/TOE
TOE
♦ Inspect the user list and search for generic userIDs
like “ADMIN, test, sales, audit, etc.” to determine that
no function userIDs exist which could be shared
among several individuals.
Any findings should be properly discussed with the

administrators/information owners.
TOD/TOE
2. Authentication mechanisms
♦ For each Application and IT platform, adequate password-based
access restrictions is in place.
TOD (automated control covers the TOE)
♦ Inspect the policy to ensure that individual systems password
criteria are detailed in the IT security policies.
♦ If not, who decides password criteria of systems? Is this
appropriate?
♦ Review the system parameters for passwords to verify that the
system enforces secure password settings inline with the
security policy.
♦ Review procedures for password resets by help-desk or other
personnel to determine the authenticity of the user requesting
the password reset.
Consideration on passwords review
♦ Observe password criteria screen. Where possible

obtain a print-screen as evidence.
♦ Where password criteria cannot be viewed on screen
obtain evidence from software provider.
♦ Where this is not possible TEST A USER.
(get client to change password, entering passwords
that do not meet specific criteria and ensure that they
are not accepted as a password).
What if the application does not support strong

password controls?
TOD/TOE
3. Remote Access
♦ Remote access to the network and in-scope systems is
restricted and monitored.
TOD
♦ Identify whether users are able to access the network remotely
(e.g. via a dial up connection or VPN).
♦ If so identify whether access is restricted to certain programs or
files and that access is appropriately authorised.
♦ What is the process for allowing users remote access to the
network? ensure only appropriate users are able to access the
network remotely, based on authorisation from appropriate line
manager.
♦ Review the security controls in place for remote access,
authentication mechanism (e.g. by secureID system) and
security logging.
TOD/TOE
TOE
♦ Obtain a list of users with remote access and select a
sample (in line with KAM sampling) to ensure that for
each user there is appropriate supporting
documentation allowing the user remote access.
TOD/TOE
4. Audit Logs (all layers)
♦ Effective mechanisms are in place to log security
activity and identify potential violations and then
escalate and act upon them in a timely manner to
reduce the risk of unauthorized / inappropriate access
to the entity’s relevant financial reporting applications
or data.
TOD (covers TOE):
♦ Review in-scope systems’ parameters to ensure that
audit logs are activated and all security violations and
financial transactions are logged.
♦ Logging features/activities are in line with the security
policy.
TOD/TOE
♦ Logging facilities and log information should be protected against
unauthorized access:
− log files being edited or deleted;
− storage capacity of the log file media being exceeded, resulting in
either the failure to record events or over-writing of past recorded
events.
♦ Check whether alerting mechanism is in place to notify
administrators/information owners about certain activities or
transactions.
♦ Inquire about the incident reporting and escalation mechanism. Inspect
the policy, if any and select one sample for review.
TOE
♦ Inspect a sample of reports of security violations and ensure that
violations are properly escalated and resolved. (KAM sample size)
TOD/TOE
5. LAC of O/S, DB, and network devices
♦ Use specific audit programs and select relevant
controls for review.
♦ Examples:
− Authentication mechanisms.
− Auditing and reporting.
− Security configuration standards defines the minimum security
requirements.
− System-specific security settings.
− Management of service accounts.
KPMG Perspective on

2. Physical Access
6. Monitoring
7. Super users
Access Administration
♦ Access administration includes establishing a userID

with an initial password,
♦ The ongoing access maintenance through the granting

and revoking of access rights.
♦ Procedures are in place so that user accounts are

added, modified and deleted in a timely manner.
Key
Key Elements:
Concepts
♦ User accounts are added, modified and
deleted with the following elements:
− Privileges based on authorized duties
− Approved by appropriate management
− Documented
− In a timely manner
Administering New Users
♦ Consider new users for each operating system, network and application
in scope, not just network!!
− Tests should be recorded separately on the ITGC for clarity
♦ Accounts set up in the year should be recorded within each application
− IT staff should be able to print these out for us to choose a sample to
check authorization
♦ Authorization can be via email / forms etc.
− Ideally both line managers and IT
♦ System access requests should be specific and not just “full” access
− E.g., purchase ledger
Administering Changed Users
A user who previously had access but now needs

amending
− E.g., when someone gets promoted, changes roles
♦ Modifications can include removing some access as
well as gaining new ones
♦ Process should follow same basics as new users and
can sometimes be tested together
Administering Terminated Users
♦ Need to consider termination process for each operating system,

network and application in scope, not just network!!
− Tests should be recorded separately on the ITGC to show
clarity
♦ Source data should be HR lists, NOT system prints or forms
(these can be incomplete)
♦ Compare HR lists to active user lists to confirm deletions from
system
♦ Sometimes HR lists are by department so samples can be picked
easily by application; otherwise you may need to sample from all
terminated users
♦ Sometimes accounts are deactivated but not deleted – this can
pose a risk depending on the complexity of the company
Administering Disabled Users
♦ System access should be disabled when a user is on a long

leave.
♦ What is the client definition of long leave? (3 months, 6 months, a
year, etc.)
♦ If there is remote access or not?
TOD/TOE
1. Adding new users
There are procedures in place for the management of users and thier
privileges for in-scope systems. The management procedures require
formal approvals for the establishment of users and granting of
privileges.
TOD
♦ Understand the process for setting up new users on the application and
network.
♦ Inspect a user access request form (electronic or manual) for one
individual to ensure that there is a clear indication of the authorization.
(Consider vendor users (temporary system access), remote access and
physical access).
♦ Inquire whether user-access request forms are retained, and where.
♦ Review procedure for granting initial passwords.
♦ Are there any controls in place to ensure ‘ghost users’ are not setup?
TOD/TOE
TOE
♦ Obtain an electronic list of current network users and current
employees. Use IDEA to match the two databases. Follow up any areas
where there are users who are not employees.
When not possible

♦ Obtain a list of new hires -during the review period- from payroll/HR and
select a sample (in line with KAM sampling).
♦ Confirm each new user has a formal “access form” that has been
processed correctly and that the details agree to the system.
For any changes in access rights identified in sample testing confirm
that these are appropriately supported.
TOD/TOE
1. Deleting, disabling and changing user access
For each in-scope IT system, adequate arrangements are in place for
deleting, disabling and changing users access.
TOD
♦ Through discussions with IT manager, information owners and HR
ascertain the process for:
− removing leavers from the systems.
− amending access rights of transfers.
− disabling users on long leave.
(Consider vendor access, remote access and physical access).
♦ Ensure the process is aligned with the policy, if any.
TOD/TOE
TOE (to be tested during TOD if there is no formal user access
management procedure in place)
♦ Obtain a list of current year leavers from payroll/HR and ensure all are
removed from the system. If not applicable select a sample based on
KAM sampling.
♦ Obtain a list of current year transfers from payroll/HR and select a
sample based on KAM sampling, and ensure their access rights are
changes as approved by line manager.
♦ Obtain a list of users who are currently on long leave and ensure all
system access are disabled. If not applicable select a sample based on
KAM sampling.
KPMG Perspective on

2. Physical Access
6. Monitoring
7. Super users
Monitoring System Access
Objectives
♦ Controls are in place to ensure that management /

information owners conduct periodic reviews of access to
information systems.
♦ Should be performed by line manager or someone senior

who knows job roles
♦ Formality and frequency of review should be appropriate
in light of number of users and risk
♦ Review should be considered for each in-scope operating
system, network, application
♦ Should include access of individual permissions
♦ In smaller companies the review is informal – testing is
done via corroborative enquiry
TOD/TOE
The entity performs a periodic review of active users and user
access rights to identify and remove inappropriate system access.
Access changes due to the review process are appropriately
documented and the documentation is retained.
TOD
♦ Inquire whether a periodic review of systems access rights is
undertaken. How often? (Expect at least annually).
♦ Who carries out the review, someone other than the systems
administrator?
♦ How the review and access changes due to the review are
documented?
Before making recommendation consider the value this will add to
the system’s security. If there are strong and robust controls over
starters and leavers in place may consider that it is not necessary.
TOD/TOE
TOE
♦ Review the documentation supports the performance of a review of users
and their access rights.
KPMG Perspective on

2. Physical Access
6. Monitoring
7. Super users
Super-users
Objectives
• Controls are in place to restrict super user
access to an appropriate group of individuals.
• Monitor the activities performed by those

users to reduce the risk of
unauthorized/inappropriate access to the
relevant programs or data.
• Consider whether responsibilities are

adequately segregated both within the IT
department and between the IT department
and business users.
Super-users
♦ Powerful userIDs ('super users') whose access rights could override
controls.
♦ Such super users may exist at the system level (e.g., system, security and
database administrators) as well as at the application level.
System level:
♦ Administrators.
♦ Special system logon IDs.
♦ System “exits”.
♦ Special system or database utilities.
Application level:
♦ The ability to perform sensitive transactions (i.e., book a
journal entry with no approvals, issue checks with no
approvals, write off receivables with no approvals).
Super-users
♦ Sensitive transactions are recorded on a sensitive transaction log that is

reviewed by appropriate entity management personnel. (Exception report).
NOTE:
♦ Operating system level (audited as an ITGC)
♦ Application level (these may be audited as an application control within
each process – this should be coordinated within audit team)
Super-users
TOD/TOE
The entity follows an appropriate policy for super user access to IT
applications.
TOD
♦ Review security policy and identify any criteria over who has super user
access.
♦ Obtain a list of super users for in-scope systems and determine that the
individuals with access have appropriate job functions, and inline with the
policy, if any.
(Print screen of administrators on system levels).
♦ Who decided/authorized this access? Formal form in place?
♦ Ensure that access to powerful system level ID’s is logged, where
possible, and recorded for appropriate review. Check whether the log can
be amended and who have access to amend the log.
Super-users
TOD/TOE
TOE
♦ Bases on KAM sampling, select a sample of users’ access outside
of the super-user function and ensure that they don’t have
powerful system level IDs.
♦ Inspect of the log report reviews and ensure that any unusual
activity was followed up on and appropriately resolved. Consider
KAM sample size.
Control Deficiencies
Access to Programs and Data – Key Points
♦ We conclude whether sufficient controls are in place for Access

to Programs and Data.
♦ The overall conclusion is based on the combination of controls -
a single failure does not make the whole section ineffective
♦ We should consider relevant compensating controls we have
tested prior to provide conclusions – based on the environment.
− E.g., strong logical access often compensate for physical
security deficiencies
− E.g., Network access can partially compensate for poor
application security
− E.g. Strong monitoring controls can sometimes
compensate for deficient Access administration.
Learning Points Access to Programs and
Data – Key Points (continued)
♦ Conclusions at each stage need to be specific to

relevant network, operating system or application
♦ For a control to be “effective”, it only need be
sufficient for the type of company and it’s dependence
on automation:
− The severity of the deficiency will impact the result.
− Evidence must be obtained to support conclusions.
Common issues
Access to Programs and Data - Common
Issues
♦ Password parameters for all in-scope applications is
not being tested (including network, database etc)
♦ Super user access testing is being done by inquiry

alone. A system generated listing should be reviewed
♦ When reviewing a list of users for appropriateness

this is being done on a sample basis. Note – we
should review 100% of user access lists
♦ Segregation of duties not being addressed or being

cross-referenced to user access test work

Access Control Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Access Control Guide

Uploaded by

Copyright:

Available Formats

Access to programs and data

♦ Relationship of General Control

1. Information Security Policy/User Awareness

♦ Issuing and maintaining an information security

♦ End-users should be aware of their roles and

1. Information Security Policy

3. Security function (for certain cases only).

1. Information Security Policy/User Awareness

TOD (all computer rooms related to in-scope systems should be reviewed).

♦ Obtain a list of current year leavers from payroll/HR and

♦ In smaller less complex companies we would do very limited testing as this

1. Information Security Policy/User Awareness

♦ This is the basis for ensuring that individual access

TOE (per system)

TOD (covers TOE)

− Excessive full system admin access by IT and

1. Information Security Policy/User Awareness

♦ User ID’s and Passwords need to be in place for:

Any findings should be properly discussed with the

♦ Observe password criteria screen. Where possible

What if the application does not support strong

1. Information Security Policy/User Awareness

♦ Access administration includes establishing a userID

♦ The ongoing access maintenance through the granting

♦ Procedures are in place so that user accounts are

A user who previously had access but now needs

♦ Need to consider termination process for each operating system,

♦ System access should be disabled when a user is on a long

When not possible

1. Information Security Policy/User Awareness

♦ Controls are in place to ensure that management /

♦ Should be performed by line manager or someone senior

1. Information Security Policy/User Awareness

• Monitor the activities performed by those

• Consider whether responsibilities are

♦ Sensitive transactions are recorded on a sensitive transaction log that is

♦ We conclude whether sufficient controls are in place for Access

♦ Conclusions at each stage need to be specific to

♦ Super user access testing is being done by inquiry

♦ When reviewing a list of users for appropriateness

♦ Segregation of duties not being addressed or being

You might also like