Identification-and-Access-Management-Practice-Aid

You might also like

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 11

Identification and Access

Management (IAM)
Internal Audit Practice Aid
Program Description

As technology permeates the business environment, it becomes paramount to ensure the


protection of the Agency’s technology assets. The most basic protection is the use of
identification and access controls to limit (1) who can legitimately gain access and (2) access to
what digital resources. At the core of Identification and Access Management (IAM) is the idea to
manage users (people and systems) so they are uniquely identified along with tracking their
actions while using the target system. IAM involves the provisioning (establishing), maintaining
(changing level of access), and monitoring (reviewing user actions) of user identities for the life
cycle of the system/ account. The implementation of appropriate IAM controls will help ensure
only authorized accounts have access to technical resources such as applications, systems,
networks, and the underlying data. A secondary goal of IAM is to hold users accountable for
activity performed with their user account which is known as non-repudiation. The user activity
is generally tracked by automated logging also referred to as auditing.

This practice aid relies on the National Institute of Standards and Technology (NIST) special
publication 800-53 rev. 5, Security and Privacy Controls for Federal Information Systems and
Organizations. The SP 800-53 rev. 5 is a freely available security control framework. The
controls referenced in this practice aid are a subset of controls specifically selected to support a
healthy IAM process. The auditor is at liberty to include or exclude any of these controls based
on their risk environment. These controls are referenced with a two-letter identifier followed by a
control number such as AC-2; which would reference the second control in the Access Control
family, “Account Management”.

Statutes and Regulations

There are no specific Federal statutes that apply to Identification and Access Management.
Individual State Transportation Agencies may have state specific statutes or regulations that
govern System Development Projects that should be considered during an engagement.

1
Catalogue of Federal Domestic Assistance (CFDA#)

No CFDA applies to this program.

Scope and Objectives

The scope of this engagement includes a review of the controls over the Identification and
Access Management (IAM) process. This guide is intended to be generic enough to cover a wide
range of user types and systems. It is expected that the auditor will first perform a level risk
assessment of user types and systems to focus on those with the highest risk.

Audit Objectives
Specifically, the audit objectives are to determine whether internal controls were adequate to
ensure:
 Appropriate identification and access management policy implementation.
 Appropriate risk management practices are employed.
 Appropriate identification, account management, and password methodologies are
implemented.

Audit Program.........................................................................................................................3
Objective A: Determine if appropriate identification and access management (IAM)
policy is implemented.....................................................................................3
Objective B: Determine if appropriate risk management practices are employed...............4
Objective C: Determine if appropriate identification methodologies are implemented......4
Objective D: Determine if appropriate account management methodologies are
implemented....................................................................................................5
Objective E: Determine if appropriate account password methodologies are implemented.6
Glossary....................................................................................................................................8

2
Audit Program

Objective A: Determine if appropriate identification and access management (IAM) policy


is implemented.

Step 1. Obtain and review approved IAM policy.


Step 2. Verify policy was approved and reviewed in accordance with applicable
agency policy or state regulation by an appropriate board/ committee.
Step 3. Verify policy was properly distributed to staff, contractors, vendors and
third parties appropriately and as necessary. (AC-1)
Step 4. Determine if the IAM policy(ies) addresses the controls listed below:
Access Controls
 Account management (AC-2)
 Account enforcement (AC-3)
 Information flow enforcement (AC-4)
 Separation of duties (AC-5)
 Least Privilege (AC-6)
 Unsuccessful log in attempts (AC-7)
 Device lock (AC-11)
 Session termination (AC-12)
 Permitted actions without identification or authentication (AC-14)

Audit and Accountability


 Event logging (AU-2)
 Audit record generation (AU-12)

Identification and Authentication


 Identification and Authentication (Organizational Users)(IA-2)
 Authenticator management (IA-5)
 Authentication feedback (IA-6)
 Cryptographic module authentication (IA-7)
 Identification and Authentication (Non-Organizational Users)(IA-8)

Personnel Security
 Personnel termination (PS-4)
 Personnel transfer (PS-5)
 Access agreements (PS-6)

3
 External personnel security (PS-7)

System and Information Integrity


 System monitoring (SI-4)
 Information input validation (SI-10)

Step 5. Verify IAM processes are integrated with Human Resource (HR)
processes such as onboarding, change of duty assignment, and terminations. (AC-
2, PS-1, PS-4, PS-5)
Step 6. Determine if all systems and user types within scope are required to
comply with IAM policy (for external users, there should be contractual
obligation). (AC-1, AC-3, PS-6, PS-7, PT-1)
Step 7. Determine if policy allows for exemptions; if it does, request and review
policy exemptions. Review exemptions for limitations, periodic review for
continued applicability, risk assessment, and approval. (AC-1)

Objective B: Determine if appropriate risk management practices are employed.

Step 1. Obtain and review approved risk management procedures for IAM. (RA-
1)
Step 2. Obtain and review the most recent risk assessment for IAM for the system
and user types in scope. (RA-3)
Step 3. Obtain and review any other risk assessment documentation that may be
pertinent. (RA-3)
Step 4. Determine if risks identified in Steps 2 and 3 above are addressed and
IAM follows approved risk management procedures obtained in step 1.

Objective C: Determine if appropriate identification methodologies are implemented.

Step 1. Identify who is responsible for implementing IAM controls. (AC-1, IA-1)
Step 2. Obtain and review account provisioning procedures. (AC-1, IA-1)
Step 3. Obtain and review account transfer and termination procedures (from IT,
HR, and possibly business units). (PS-1)
Step 4. Obtain and review user access revalidation procedures. (AC-2, AC-6)
Step 5. For each system under review, obtain and review a sample segregation of
duty tables/ documentation for the user types within scope. (AC-5)
4
Step 6. For each system under review, obtain a sample of user accounts.
Step 7. Identify account approvers/ data/ system owners.
Step 8. Verify procedures obtained in Steps 1-5 were followed and proper
approvals were obtained (Step 7.) for the sample of user accounts obtained in Step
6 above. (AC-2)

Objective D: Determine if appropriate account management methodologies are


implemented.

Step 1. For each system under review, verify the IAM process adheres to IAM
policy and functions accordingly. (AC-1)
Step 2. Verify IAM staff have the appropriate level of skill, experience, and
training to perform all IAM duties assigned. (AC-2)
Step 3. For each system under review, verify that each user type account is
authenticated using an approved process prior to gaining access to the system.
(AC-3)
Step 4. For each system under review, verify that all user types follow the
agency’s defined identity verification process. (AC-3)
Step 5. For each system under review, verify that access control (AC) databases
are secured behind firewall and DMZ. (SC-28)
Step 6. For each system under review, review and verify access to the AC
databases are appropriately controlled by the use of encryption and least privilege.
(SC-28, AC-6)
Step 7. For each system under review, verify account identifiers are uniquely
defined and does not contain sensitive information such as SSN. (IA-2, IA-4)
Step 8. For each system under review, determine if any account identifier is
shared by individuals or systems. (IA-2, IA-4)
Step 9. For each system under review, determine and verify account usage is
regularly and adequately monitored. (AC-2)
Step 10. For each system under review and if privileged accounts are in scope, determine if
privileged account identifiers are used for any general purpose tasks where
elevated privilege is not required. (AC-2(7), AC-6(2))
Step 11. For each system under review, determine if, by policy and automated procedure,
accounts are to be disabled after a standard number of failed attempts. (AC_1,
AC-7)

5
Step 12. For each system under review, verify the system enforces account lock after a
standard number of failed attempts. (AC-7)
Step 13. For each system under review, determine if, by policy, user sessions are
automatically disconnected or locked after a standard amount of time. (AC-2, AC-
11, AC-12)
Step 14. For each system under review, verify the system enforces a user session lock or
disconnect after a specified amount of time. (AC-11, AC-12)
Step 15. For each system under review, determine if/how activity logs are generated,
securely stored, and reviewed by authorized staff/ management. (AU-2, AU-6))
Step 16. For each system under review, determine if data/ system owners and security
specialists routinely receive and review access change reports. (AC-3)
Step 17. For each system under review, determine if user accounts can be logged in from
multiple endpoints simultaneously. (If allowed, determined legitimacy). (AC-10)

Objective E: Determine if appropriate account password methodologies are implemented.

Step 1. Obtain and review password policy. (IA-5)


Step 2. For each system under review, determine if password complexity rules are
enforced for accounts by the provisioning system. (IA-5)
Step 3. For each system under review, determine if the system allows for the
password to match or contain the user account identifier. (IA5)
Step 4. For each system under review, determine if, by policy, user account
passwords must be changed by a preset number of days. (IA-5)
Step 5. For each system under review, determine if the system enforces account
password age policy. (IA-5)
Step 6. For each system under review, determine if the password policy is relevant
to the sensitivity of information and the user account class/ type. (IA-5)
Step 7. For each system under review, determine if, by policy, password reuse is
allowed. (What is the level of password generations). Verity it is adequate
considering the data and system being protected. (IA-5)
Step 8. For each system under review, determine if the method/ procedure for
changing a password fits within the IAM policy and is appropriate. (IA-1, IA-5)
Step 9. For each system under review, verify temporary passwords require
immediate reset after first login. (IA-5)

6
Step 10. For each system under review, determine if temporary passwords are
randomly generated. (IA-5)
Step 11. For each system under review, verify that any challenge and response questions
for password change do not allow any PII or sensitive information. (IA-5)
Step 12. For each system under review, verify transmission of passwords is only over
cryptographically protected channels. (IA-5)
Step 13. For each system under review, verify that a process has been established for
reissuing shared/group account credentials (if deployed) when individuals are
removed from the group. (IA-5)

7
Glossary

Access Agreements: Access agreements include nondisclosure agreements, acceptable use


agreements, rules of behavior, and conflict-of-interest agreements. (NIST.gov)

Access Control: The process of granting or denying specific requests for obtaining and using
information and related information processing services; and to enter specific physical facilities
(e.g., Federal buildings, military establishments, and border crossing entrances). (NIST.gov)

Access Management: Access Management is the set of practices that enables only those
permitted the ability to perform an action on a particular resource. The three most common
Access Management services you encounter every day perhaps without realizing it are: Policy
Administration, Authentication, and Authorization. (NIST.gov)

Approvers: A member of the organization that determines the organization's official approval or
rejection of an app. (NIST.gov)

Authentication: Verifying the identity of a user, process, or device, often as a prerequisite to


allowing access to resources in a system. (NIST.gov)

Authenticator: Something the claimant possesses and controls (typically a cryptographic


module or password) that is used to authenticate the claimant’s identity. (NIST.gov)

Channel: An information transfer path within a system. May also refer to the mechanism by
which the path is effected. (NIST.gov)

Contractor: a person or company that undertakes a contract to provide materials or labor to


perform a service or do a job. (Oxford)

Cryptographic Module Authentication: Authentication mechanisms may be required within a


cryptographic module to authenticate an operator accessing the module and to verify that the
operator is authorized to assume the requested role and perform services within that role.
(NIST.gov)

DMZ: A perimeter network or screened subnet separating an internal network that is more
trusted from an external network that is less trusted. (NIST.gov)

Firewall: A gateway that limits access between networks in accordance with local security
policy. (NIST.gov)

Identifier: Unique data used to represent a person’s identity and associated attributes. A name or
a card number are examples of identifiers. A unique label used by a system to indicate a specific
entity, object, or group. (NIST.gov)

8
Identification and Authentication for Agency Users: Uniquely identify and authenticate
organizational users and associate that unique identification with processes acting on behalf of
those users. (NIST.gov)

Identification and Authentication for Non-Agency Users: Non-organizational users include


system users other than organizational users. Non-organizational users are uniquely identified
and authenticated for accesses other than those explicitly identified and documented. (NIST.gov)

Information Flow Enforcement: Enforce approved authorizations for controlling the flow of
information within the system and between connected system. (NIST.gov)

Information Input Validation: Checking the valid syntax and semantics of system inputs—
including character set, length, numerical range, and acceptable values—verifies that inputs
match specified definitions for format and content. (NIST.gov)

Least Privilege: The principle that users and programs should only have the
necessary privileges to complete their tasks. (NIST.gov)

Onboarding: The action or process of integrating a new employee into an organization or


familiarizing a new customer or client with one's products or services.
(https://languages.oup.com/)

Permitted Actions without Identification or Authentication: Specific user actions may be


permitted without identification or authentication if organizations determine that identification
and authentication are not required for the specified user actions. Organizations may allow a
limited number of user actions without identification or authentication, including when
individuals access public websites or other publicly accessible federal systems, when individuals
use mobile phones to receive calls, or when facsimiles are received. (NIST.gov)

PII (Personally Identifiable Information): Information that can be used to distinguish or trace
an individual’s identity, either alone or when combined with other information that is linked or
linkable to a specific individual. (NIST.gov)

Privileged Account: An information system account with approved authorizations of a


privileged user. (NIST.gov)

Risk Management: The process of managing risks to organizational operations (including


mission, functions, image, or reputation), organizational assets, or individuals resulting from the
operation of an information system, and includes: (i) the conduct of a risk assessment; (ii) the
implementation of a risk mitigation strategy; and (iii) employment of techniques and procedures
for the continuous monitoring of the security state of the information system. (NIST.gov)

Separation of Duties: Separation of duties refers to the principle that no user should be given
enough privileges to misuse the system on their own. Separation of duties can be enforced either
statically (by defining conflicting roles, i.e., roles which cannot be executed by the same user) or
dynamically (by enforcing the control at access time). (NIST.gov)
9
Session Lock: Session locks are temporary actions taken when users stop work and move away
from the immediate vicinity of information systems but do not want to log out because of the
temporary nature of their absences. (NIST.gov)

Session Termination: Automatically terminate a user session. (NIST.gov)

System Owners: Person or organization having responsibility for the development,


procurement, integration, modification, operation, and maintenance, and/or final disposition of
an information system. (NIST.gov)

Vendors: A commercial supplier of software or hardware. (NIST.gov)

10

You might also like