Establish and maintain an identification, authentication, and access rights management plan.

UCF ID: 00513

Control Type: Establish/Maintain Documentation

Status: Live

Supporting and supported controls

This control directly supports:

Establish and maintain a policy for establishing access policies and procedures. [UCF Control ID 00512]

This control has the following supporting controls:

Implement a centralized identification and access rights management process. [UCF Control ID 00528]

Maintain control over access rights and user privileges. [UCF Control ID 00004]

Maintain user accounts and access management for those users. [UCF Control ID 00514]

Review user and shared accounts via automatic means or management review. [UCF Control ID 00525]

Manage and maintain user accounts according to organizationally documented policies and procedures. [UCF Control ID 00526]

Protect and manage biometric and/or other authentication systems and values. [UCF Control ID 01261]

Authority documents complied with:

AICPA/CICA Privacy Framework, ID 8.2.2.a, ID 8.2.2.b; AICPA Suitable Trust Services Principles and Criteria, ¶ .17 § 3.1.b, ¶ .20 § 3.4.b, ¶ .24 § 3.5.b, ¶ .29 § 3.4.b; Safety and Soundness Standards, Appendix of OCC 12 CFR 30, App B § III.C.1.a, Supp A § I.B.2.a, Supp A § II; Bank Secrecy Act (aka The Currency and Foreign Transaction Reporting Act), September 2000, Pg 19, Pg 85, Pg 86, Obj 4 (Processes), Obj 5 (Processes), Obj 6 (Processes), Obj 13 (Processes); FFIEC Guidance on Authentication in an Internet Banking Environment, Pg 2, Pg 3; FFIEC IT Examination Handbook – Audit, August 2003, Exam Tier II Obj D.1; FFIEC IT Examination Handbook – Business Continuity Planning, March 2008, Exam Tier I Obj 7.6; FFIEC IT Examination Handbook – E-Banking, August 2003, Pg 34, Obj 4.4; FFIEC IT Examination Handbook – Information Security, Pg 23, Pg 26, Pg 47, Pg 49, Exam Tier II Obj A.3 (Authentication), Exam Tier II Obj C.6, Exam Tier II Obj A.8 (Authentication); FFIEC IT Examination Handbook – Operations, July 2004, Pg 28, Exam Tier I Obj 8.2; FFIEC IT Examination Handbook – Wholesale Payment Systems, July 2004, Pg 17, Pg 31; System Security Plan (SSP) Procedure, Version 1.0, App A § 4.1; FDA Electronic Records; Electronic Signatures FDA 21 CFR Part 11+D1, § 11.10(d); North American Electric Reliability Corporation Critical Infrastructure Protection Cyber Security Standards, CIP-007-1 R5; Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 1.2.1, § 7.2 thru § 7.2.3; VISA E-Commerce Merchants Guide to Risk Management Tools and Best Practices for Building a Secure Internet Business, Pg 73, Pg 75, Pg 78, Pg 81; Corporate Information Security Working Group: Report of the best practices and metrics teams; subcommittee on technology, information policy, intergovernmental relations and the census; Government Reform Committee, United States House of Representatives, § 15.a; NISPOM - National Industrial Security Program Operating Manual (DoD 5220.22-M) February 26, 2006, February 28, 2006, § 8-105, § 8-607.b; FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006, § 3; Federal Information System Controls Audit Manual (FISCAM), February 2009, AC-3.2(A); National Incident Management System (NIMS), Department of Homeland Security, December 2008, Chap V.B.2.B(6); The National Strategy to Secure Cyberspace, February 2003, Pg 46; US Export Administration Regulations Database, § 734.2(b)(9)(iii); IRS Publication 1075: TAX INFORMATION SECURITY GUIDELINES FOR FEDERAL, STATE AND LOCAL AGENCIES AND ENTITIES; Safeguards for Protecting Federal Tax Returns and Return Information, § 5.6.7, Exhibit 4 IA-1, Exhibit 6; The DIRKS Manual: A Strategic Approach to Managing Business Information, rev. July 2003, § G.4.3; Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996, § 3.11; Recommended Security Controls for Federal Information Systems, NIST SP 800-53, Revision 3, App F § AC-2(7), App F § AC-14(a), App F § AC-14(b), App F § AC-14(1), App F § IA-1, App F § IA-4, App F § IA-5; Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A, July 2008, IA-1; CobiT, Version 4.1, DS5.3; The Standard of Good Practice for Information Security, SM4.4.1, SM4.4.2, CB3.1.1, CI4.3.1, UE2.1.1; DISA Secure Remote Computing Security Technical Implementation Guide, Version 1, Release 2, § 6.2.1; ISO/IEC 15408-2 Common Criteria for Information Technology Security Evaluation Part 2, 2008, § 12.4, § 13.4, § G.4, § H.4; ISO/IEC 17799 Code of Practice for Information Security Management, 2005, § 11.2.4; ISO/IEC 27001 Information Security Management Systems - Requirements, 2005, Annex A.11.2.1; ISO/IEC 27002 Code of practice for information security management, 2005, § 11.2.4; OGC ITIL: Security Management, § 4.2.4; OECD / World Bank Technology Risk Checklist, Version 7.3, § IV; Australian Government ICT Security Manual (ACSI 33), § 3.6.2, § 3.10.14; Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 1.2, § 7.2 thru § 7.2.3; Guide to Bluetooth Security, NIST SP 800-121, September 2008, Table 4-2 Item 21; Guide to Securing Legacy IEEE 802.11 Wireless Networks, NIST SP 800-48, Revision 1, § 6.3.6; Center for Internet Security Open Enterprise Server: NetWare (v1) Consensus Baseline Security Settings, Version 1.0 August 2006, § 2.9; Italy Personal Data Protection Code, § 34.1(a) thru § 34.1(c); Payment Card Industry (PCI) Payment Application Data Security Standard, Version 1.1, § 3.1, § 3.2; Bank Secrecy Act (aka The Currency and Foreign Transaction Reporting Act), September 2000, Pg 19, Pg 85, Pg 86, Obj 4 (Processes), Obj 5 (Processes), Obj 6 (Processes), Obj 13 (Processes); ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000, ¶ 8.2.1, ¶ 9.2 Table Row “I and A Based on Something the User Knows”, ¶ 9.2 Table Row “I and A Based on Something the User Possesses”, ¶ 9.2 Table Row “I and A Based on Something the User Is”, ¶ 10.3.4; ISO/IEC 13335-5 Information technology — Guidelines for the management of IT Security — Part 5: Management guidance on network security, 2001, ¶ 13.3.2, ¶ 13.3.3, ¶ 13.7, ¶ 13.9, ¶ 13.10, ¶ 13.11

Banking and Finance Guidance

The organization should implement access controls to authenticate users and only permit authorized users access to the system. Controls should be in place to prevent employees from providing customer information to unauthorized individuals. [App B § III.C.1.a, Supp A § I.B.2.a, Supp A § II, Safety and Soundness Standards, Appendix of OCC 12 CFR 30]

Identification standards should be developed for positively identifying new customers. The bank should have an explicit policy to prohibit significant transactions from individuals who do not provide identification evidence. [Pg 19, Pg 85, Pg 86, Obj 4 (Processes), Obj 5 (Processes), Obj 6 (Processes), Obj 13 (Processes), Bank Secrecy Act (aka The Currency and Foreign Transaction Reporting Act), September 2000]

The organization should implement an effective authentication system to protect customer information in order to comply with all applicable requirements. The type of authentication technology used by the organization should be based on the risk assessment. An effective authentication program should include customer acceptance of the methods; further, the methods should perform reliably; the methods should be able to be scaled for growth; and the methods should be able to operate with existing systems. [Pg 2, Pg 3, FFIEC Guidance on Authentication in an Internet Banking Environment]

[Exam Tier II Obj D.1, FFIEC IT Examination Handbook – Audit, August 2003]

[Exam Tier I Obj 7.6, FFIEC IT Examination Handbook – Business Continuity Planning, March 2008]

The organization should ensure the authentication controls are consistent with the security policy. The authentication controls should be evaluated for password length, password expiration, account lockout, and password history requirements. [Pg 34, Obj 4.4, FFIEC IT Examination Handbook – E-Banking, August 2003]

The organization should develop criteria for granting appropriate access rights and establishing proper activities for using those rights. The organization should use single-factor or multifactor authentication processes to verify the unique identity of the user. The organization should ensure the authentication methods restrict system access to users and applications. The authentication method should be commensurate with the criticality and sensitivity of the application. [Pg 23, Pg 26, Pg 47, Pg 49, Exam Tier II Obj A.3 (Authentication), Exam Tier II Obj C.6, Exam Tier II Obj A.8 (Authentication), FFIEC IT Examination Handbook – Information Security]

Access to the telecommunications system should follow the organization's policy for identification, authorization, and authentication. [Pg 28, Exam Tier I Obj 8.2, FFIEC IT Examination Handbook – Operations, July 2004]

The organization should implement identification and authentication controls in order to authenticate all access to the payment messaging system and to ensure the authenticity of the payers and the payees. [Pg 17, Pg 31, FFIEC IT Examination Handbook – Wholesale Payment Systems, July 2004]

Assess the organization's identification requirements for creating new personal and business accounts. Review a sampling of accounts to ensure they comply with the account opening requirements and review the associated account statements to ensure they are consistent with the nature of the customer or business. [Pg 19, Pg 85, Pg 86, Obj 4 (Processes), Obj 5 (Processes), Obj 6 (Processes), Obj 13 (Processes), Bank Secrecy Act (aka The Currency and Foreign Transaction Reporting Act), September 2000]

Healthcare and Life Science Guidance

Identification and authentication controls should be present in all systems, including mechanisms that provide the ability to verify users. [App A § 4.1, System Security Plan (SSP) Procedure, Version 1.0]

Identification and authentication controls must be included on all systems, including mechanisms that provide the ability to verify users. [§ 11.10(d), FDA Electronic Records; Electronic Signatures FDA 21 CFR Part 11+D1]

Energy Guidance

The Responsible Entity shall establish, implement, and document technical and procedural controls that enforce access authentication of, and accountability for, all user activity, and that minimize the risk of unauthorized system access. [CIP-007-1 R5, North American Electric Reliability Corporation Critical Infrastructure Protection Cyber Security Standards]

Payment Card Guidance

The organization must ensure systems with multiple users have an access control system implemented that restricts access based on need-to-know and denies all users unless specifically allowed.
Verify an access-control system is implemented and covers all components, assigns privileges based on job function, and is set to default to "deny-all."
Observe an individual gaining access on each component and for each type of authentication to verify the authentication is functioning correctly. [§ 7.2 thru § 7.2.3, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 1.2.1]

The organization should consider requiring customers to become members of the web site. Employee access to the customer information should be limited. [Pg 73, Pg 75, Pg 78, Pg 81, VISA E-Commerce Merchants Guide to Risk Management Tools and Best Practices for Building a Secure Internet Business]

The organization must ensure systems with multiple users have an access control system implemented that restricts access based on need-to-know and denies all users unless specifically allowed. [§ 7.2 thru § 7.2.3, Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 1.2]

Unique usernames and secure authentication should be used to gain administrative access, for access to any cardholder data, and to access PCs, servers, and payment databases. Changing this setting in the application after installation may result in noncompliance with PCI DSS. [§ 3.1, § 3.2, Payment Card Industry (PCI) Payment Application Data Security Standard, Version 1.1]

US Federal Security Guidance

The organization must implement and monitor the status of identification and authentication controls.
In general, the use of group authenticators precludes the association of a particular act with the individual who initiated that act. In turn, this can preclude assignment of responsibility and can exacerbate the difficulties involved in incident investigation. Group authenticators shall be used only for broader access after the use of a unique authenticator for initial identification and authentication, and documented in SSP. Group authenticators may not be shared with anyone outside of the group.
The organization will establish procedure for an identification and authentication management mechanism that ensures a unique identifier for each user and that associates that identifier with all auditable actions taken by the user. The following must be specified in the System Security Plan:
(a) Initial authenticator content and administrative procedures for initial authenticator distribution.
(b) Individual and Group Authenticators. Group authenticators may only be used in conjunction with an individual/unique authenticator, that is, individuals must be authenticated with an individual authenticator prior to use of a group authenticator.
(c) Length, composition and generation of authenticators.
(d) Change processes (periodic and in case of compromise.
(e) Aging of static authenticators (i.e., not one-time passwords or biometric patterns)
(f) History of authenticator changes, with assurance of non-replication of individual authenticators.
(g) Protection of authenticators. [§ 15.a, Corporate Information Security Working Group: Report of the best practices and metrics teams; subcommittee on technology, information policy, intergovernmental relations and the census; Government Reform Committee, United States House of Representatives]

All users must be accountable for their actions on the system. [§ 8-105, § 8-607.b, NISPOM - National Industrial Security Program Operating Manual (DoD 5220.22-M) February 26, 2006, February 28, 2006]

Calls for Identification and Authentication (IA): Organizations must identify information system users, processes acting on behalf of users, or devices and authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. [§ 3, FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006]

[AC-3.2(A), Federal Information System Controls Audit Manual (FISCAM), February 2009]

The National Incident Management System (NIMS) must develop an authentication and certification standard to ensure that information is properly authenticated and protected. [Chap V.B.2.B(6), National Incident Management System (NIMS), Department of Homeland Security, December 2008]

[Pg 46, The National Strategy to Secure Cyberspace, February 2003]

Internet transfers of eligible export products must employ precautions, such as an access control system that checks every address to ensure the Internet address or domain name is not a foreign government end-user; an access control system that provides each receiving or requesting party a notice stating the download includes cryptographic software that is subject to export controls and cannot be exported without a license; and an acknowledgment by each receiving or requesting party that states the software is not to be used by a government end-user and the software is subject to export controls. [§ 734.2(b)(9)(iii), US Export Administration Regulations Database]

US Internal Revenue Guidance

The organization must develop, document, distribute, and continuously update an identification and authentication policy and procedures for the implementation of identification and authentication security controls. [§ 5.6.7, Exhibit 4 IA-1, Exhibit 6, IRS Publication 1075: TAX INFORMATION SECURITY GUIDELINES FOR FEDERAL, STATE AND LOCAL AGENCIES AND ENTITIES; Safeguards for Protecting Federal Tax Returns and Return Information]

Records Management Guidance

[§ G.4.3, The DIRKS Manual: A Strategic Approach to Managing Business Information, rev. July 2003]

NIST Guidance

[§ 3.11, Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996]

App F § AC-2(7) The organization should establish, administer, track, and monitor role-based system access for privileged user accounts.
App F § AC-14(a) The organization must not permit users to access the information system without identification and authentication.
App F § AC-14(b) The organization must document and justify, in the security plan, any exceptions that permit users to access the information system without identification and authentication.
App F § AC-14(1) The organization may permit users to access the information system without identification and authentication only for specific mission/business objectives.
App F § IA-1 The organization must establish and maintain identification and authentication policies and procedures and implement associated controls.
App F § IA-4 The organization must establish and maintain identification management policies and procedures that require approval for user or device identifiers, assure identifiers are unique, applied correctly, may not be reused, and are disabled when inactive.
App F § IA-5 The organization must establish and maintain authentication management policies and procedures that verify the user or device, define authenticator protocols, require changing defaults, protect against loss, compromise, and unauthorized release or changes. [App F § AC-2(7), App F § AC-14(a), App F § AC-14(b), App F § AC-14(1), App F § IA-1, App F § IA-4, App F § IA-5, Recommended Security Controls for Federal Information Systems, NIST SP 800-53, Revision 3]

Organizational records and documents should be examined to ensure identification and authentication policies and procedures exist, are disseminated, reviewed and updated periodically, and specific responsibilities and actions are defined for the implementation of the identification and authentication policy and procedures control. Any problems discovered during the implementation of the identification and authentication policy and procedures control should be documented and used to improve the controls. Public accounts should be tested to ensure protected information cannot be altered.
Interviews should be conducted with personnel involved in the documentation of the identification and authentication policy and procedures and with personnel involved in configuring the identification and authentication controls. [IA-1, Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A, July 2008]

The organization should implement strong user authentication methods, such as smart cards, two-factor authentication, public key infrastructure, or biometrics. [Table 4-2 Item 21, Guide to Bluetooth Security, NIST SP 800-121, September 2008]

The organization should implement strong user authentication methods, such as smart cards, two-factor authentication, public key infrastructure, biometrics, or a combination of these methods. [§ 6.3.6, Guide to Securing Legacy IEEE 802.11 Wireless Networks, NIST SP 800-48, Revision 1]

System Configuration Guidance

All users must be authenticated before accessing eGuide. [§ 2.9, Center for Internet Security Open Enterprise Server: NetWare (v1) Consensus Baseline Security Settings, Version 1.0 August 2006]

Other Configuration Guidance

Remote access users must be authenticated by one of the following methods: RADIUS, TACACS+, CiscoSecure ACS, or SecurID. If the organization wants to use a different method, it must first be approved and documented by the Information Assurance Manager. RADIUS servers may not use NetWare Bindery to authenticate remote users who are accessing a Novell network. [§ 6.2.1, DISA Secure Remote Computing Security Technical Implementation Guide, Version 1, Release 2]

ISO Guidance

All available authentication mechanisms should be defined. Examples of controls are "none, biometrics, passwords". The system should state when and how each type of authentication mechanism should be used. The system should have the ability to revoke rights to users, subjects, and objects based on revocation rules. Revocation rules can include: Revocation will take place on the next login; revocation will take place the next time the file is opened; and revocation will take place in a fixed period of time. [§ 12.4, § 13.4, § G.4, § H.4, ISO/IEC 15408-2 Common Criteria for Information Technology Security Evaluation Part 2, 2008]

User access rights should be reviewed at regular intervals. The following guidelines should be used when reviewing user access rights: Access rights should be reviewed at 6 months and after promotion, demotion, or termination and reviewed when users change jobs in the same organization; special privileged access rights should be reviewed every 3 months; checks should be made to ensure unauthorized privileges have not been obtained; and changes to privileged accounts should be logged. [§ 11.2.4, ISO/IEC 17799 Code of Practice for Information Security Management, 2005]

Formal procedures should be in place to grant or revoke access privileges to the information system or services. [Annex A.11.2.1, ISO/IEC 27001 Information Security Management Systems - Requirements, 2005]

User access rights should be reviewed at regular intervals. The following guidelines should be used when reviewing user access rights: Access rights should be reviewed at 6 months and after promotion, demotion, or termination and reviewed when users change jobs in the same organization; special privileged access rights should be reviewed every 3 months; checks should be made to ensure unauthorized privileges have not been obtained; and changes to privileged accounts should be logged.ss rights should be reviewed every 3 months; checks should be made to ensure unauthorized privileges have not been obtained; and changes to privileged accounts should be logged. [§ 11.2.4, ISO/IEC 27002 Code of practice for information security management, 2005]

¶ 8.2.1 Identification and Authentication (I&A). An organization should implement safeguards which assure Identification and Authentication. Identification is the means by which a user provides a claimed identity to a system. Authentication is the means of establishing the validity of this claim. The following ways are examples of how to achieve I&A safeguards (other ways of classifying I&A mechanisms are possible).
1. I&A (Identification and Authentication) Based on Something the User Knows.
Passwords are the most typical way to provide I&A based on something the user knows linked with a user identification process. The allocation of passwords and their regular change should be controlled. If users are choosing the passwords themselves, they should be aware of the common rules for password design and handling. Software can be used to support this, for example by limiting the use of common passwords or patterns and characters. If it is necessary or wanted, copies of passwords should be stored securely to allow authorized access if the user is not available or has forgotten the password. I&A based on something the user knows can also make use of cryptographic means and authentication protocols. This type of identification and authentication can also be used for remote I&A.
2. I&A (Identification and Authentication) Based on Something the User Possesses.
Objects that users possess for the purpose of I&A can be memory tokens and smart tokens. A common application of memory tokens is the magnetic material on the back of a credit card. Authentication is provided based on something the user possesses (the card) and something the user knows (the PIN). Typical examples of smart tokens are smart cards.
3. I&A (Identification and Authentication) Based on Something the User Is.
Biometric authentication technologies use the unique characteristics or attributes of an individual to authenticate the person’s identity. This could be fingerprints, hand geometry, retina pattern, as well as voice patterns or hand-written signatures. Relevant details can be securely stored on smart cards, or a system.
¶ 9.2 Table Row “I and A Based on Something the User Knows” in safeguard I&A (Identification & Authentication) should be implemented under normal circumstances for Stand-alone Workstations, Workstations (Client without Shared Resources) Connected to a Network, and Servers or Workstations with Shared Resources Connected to a Network.
¶ 9.2 Table Row “I and A Based on Something the User Possesses” in safeguard I&A (Identification & Authentication) should be implemented under normal circumstances for Stand-alone Workstations, Workstations (Client without Shared Resources) Connected to a Network, and Servers or Workstations with Shared Resources Connected to a Network.
¶ 9.2 Table Row “I and A Based on Something the User Is” in safeguard I&A (Identification & Authentication) may be implemented under some circumstances for Stand-alone Workstations, Workstations (Client without Shared Resources) Connected to a Network, and Servers or Workstations with Shared Resources Connected to a Network.
¶ 10.3.4 Masquerading of user identity. An organization should implement safeguards to prevent masquerading of user identity, which can be used to circumvent authentication and all services and security functions related to that. In conclusion it can lead to integrity problems whenever this masquerade allows access and modification to information. Safeguards in this area are listed below.
• I&A (Identification & Authentication): Masquerade becomes more difficult if I&A (Identification & Authentication) safeguards based on combinations of something known, something possessed, as well as intrinsic characteristics of users are applied.
• Logical access control and audit: Logical access control cannot distinguish between an authorized user and somebody masquerading as this authorized user, but the use of access control mechanisms in place can reduce the area of impact. Review and analysis of audit logs can detect unauthorized activities.
• Protection against malicious code: A way to acquire passwords is to introduce malicious code to capture passwords, protection against such software should be in place.
• Network management: Implement network management to prevent unauthorized access by masquerading as a user in traffic, e.g. e-mail.
• Data integrity protection: Additional protection can be provided using cryptographic means like digital signatures. [¶ 8.2.1, ¶ 9.2 Table Row “I and A Based on Something the User Knows”, ¶ 9.2 Table Row “I and A Based on Something the User Possesses”, ¶ 9.2 Table Row “I and A Based on Something the User Is”, ¶ 10.3.4, ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000]

¶ 13.3.2 Remote Log-in. Remote log-ins, whether from authorized personnel working away from the organization, from remote maintenance engineers, or personnel from other organizations, are accomplished either via dial-ups to the organization, Internet connections, dedicated trunks from other organizations, or shared access through the Internet. They are connections established at need by either internal systems or contractual partners using public networks. Each type of remote log-in requires additional safeguards appropriate to the nature of the connection type. Safeguard examples are:
• not allowing direct access to system and network software from accounts used for remote access, except where additional authentication has been provided (see clause 13.3.3 below), and perhaps end-to-end encryption,
• protecting information associated with e-mail software and directory data stored on PCs and laptops used outside of an organization's offices by its personnel, from unauthorized access.
¶ 13.3.3 Authentication Enhancements. The use of user id/password pairs is a simple way to authenticate users, but they can be compromised or guessed. There are other more secure ways to authenticate users, particularly for remote users. Authentication enhancements are needed when there exists a high possibility that an unauthorized person may gain access to protected and important systems. This may be, for example, because the access may be initiated using public networks, or the accessing system may be out of the direct control of the organization (e.g. laptop).
Where authentication enhancements over network connections are required (for example, by contract) or justified by the risks, an organization should consider strengthening the person authentication process by implementing relevant safeguards. Examples are:
• using other means of identification to support the authentication of users, such as remotely verified tokens, smart cards and magnetic stripe cards (e.g. through readers attached to PCs), hand held one time pass key generation devices, dial back modems, and biometric based facilities, • ensuring that the token or card can only function in conjunction with the authorized user’s authenticated account (and preferably, that user’s PC and location/access point) and, for example, any related Personal Identification Number (PIN) or biometric profile,
• using caller line verification,
• using links via modems that are disconnected when not in use, and only connected after verification of the caller's identity.
¶ 13.7 Network Security Management. The management of any network should be undertaken in a secure manner, and indeed provide support for the management of network security. This should be accomplished with due consideration of the different network protocols available and related security services.
In furtherance of this, an organization should consider a number of safeguards, the majority of which can be identified through using Part 4 of TR 13335. In addition, remote diagnostic ports, whether virtual or physical, should all be protected from unauthorized access.
¶ 13.9 Data Confidentiality Over Networks. In circumstances where preservation of confidentiality is important, encryption safeguards should be considered to encrypt information passing over network connections. The decision to use encryption safeguards should take account of:
• relevant government laws and regulations (especially where the network connection involves several countries or jurisdictions),
• the requirements of key management and the difficulties that need to be overcome to ensure that real security improvements are achieved without creating significant new vulnerabilities, and
• the suitability of the encryption mechanisms used for the type of network connection involved and the degree of protection required.
¶ 13.10 Data Integrity Over Networks. In circumstances where preservation of integrity is important, digital signature and/or message integrity safeguards should be considered to protect information passing over network connections.
Message integrity safeguards (for example using message authentication codes) are appropriate in cases where protection against accidental or deliberate alteration, addition or deletion of information is the prime requirement.
Digital signature safeguards can provide similar protection to message authentication safeguards, but also have properties that allow them to enable non-repudiation procedures (see clause 13.11 below). The decision to use digital signature or message integrity safeguards should take account of:
• relevant government laws and regulations (especially where the network connection links several countries or jurisdictions),
• relevant public key infrastructures,
• the requirements for key management and the difficulties that need to be overcome to ensure that real security improvements are achieved without creating significant new vulnerabilities,
• the suitability of the underlying mechanisms used for the type of network connection involved and the degree of protection required, and • reliable and trusted registration of users or entities associated with keys (certified where relevant) used in digital signature protocols.
¶ 13.11 Non-Repudiation. Where there is a requirement to ensure that substantive proof can be provided that information was carried by a network, safeguards such as the following should be considered:
• communication protocols that provide acknowledgment of submission,
• application protocols that require the originator's address or identifier to be provided and check for the presence of this information,
• gateways that check sender and receiver address formats for validity of syntax and consistency with information in relevant directories,
• protocols that acknowledge delivery from networks, and
• protocols that include mechanisms that allow the sequence of information to be determined.
Where it is important that information transmission or receipt can be proven should it be contested, further assurance should be provided through the use of a standard digital signature method. Senders of information, where proof of source is required, should seal the information using a digital signature to a common standard. Where proof of delivery is required, senders should request a reply sealed with a digital signature. To achieve this level of assurance the following should be considered:
• use of non-repudiation mechanisms (digital signature, time stamping, etc.) supported by a trusted third party such as a certification authority, and associated public key infrastructure,
• logging messages using mechanisms that prevent alteration of logs,
• mechanisms to protect secret and/or private (signature) keys against unauthorized use, and
• archiving any certificates or keys necessary to resolve disputes to ensure their availability and integrity for the required time (which may be longer that the period of use of the associated keying material). [¶ 13.3.2, ¶ 13.3.3, ¶ 13.7, ¶ 13.9, ¶ 13.10, ¶ 13.11, ISO/IEC 13335-5 Information technology — Guidelines for the management of IT Security — Part 5: Management guidance on network security, 2001]

ITIL Guidance

[§ 4.2.4, OGC ITIL: Security Management]

General Guidance

The access procedures should include how to authorize, register, identify, and authenticate internal personnel. [ID 8.2.2.a, ID 8.2.2.b, AICPA/CICA Privacy Framework]

Procedures should exist to restrict logical access to the system by identifying and authenticating all users. [¶ .17 § 3.1.b, ¶ .20 § 3.4.b, ¶ .24 § 3.5.b, ¶ .29 § 3.4.b, AICPA Suitable Trust Services Principles and Criteria]

All users (internal, external and temporary) and their activity on IT systems (business application, system operation, development and maintenance) should be uniquely identifiable. User access rights to systems and data should be in line with defined and documented business needs and job requirements. User access rights are requested by user management, approved by system owner and implemented by the security-responsible person. User identities and access rights are maintained in a central repository. Cost-effective technical and procedural measures are deployed and kept current to establish user identification, implement authentication and enforce access rights. [DS5.3, CobiT, Version 4.1]

An identity and access management plan should be developed to provide access control measures throughout the organization. The identity and access management plan should be applied to all new applications when they are installed on the organization's systems. No identifying information should be displayed until after the sign-on process is successfully completed. [SM4.4.1, SM4.4.2, CB3.1.1, CI4.3.1, UE2.1.1, The Standard of Good Practice for Information Security]

EU Guidance

[§ IV, OECD / World Bank Technology Risk Checklist, Version 7.3]

Other European and African Guidance

The processing of personal data by electronic means will only be allowed if the following minimum security measures are implemented with the technical specifications stated in Annex B of this Code: computerized authentication; authentication credentials management procedures; and an authorization system. [§ 34.1(a) thru § 34.1(c), Italy Personal Data Protection Code]

Asia and Pacific Rim Guidance

The organization should develop policies and procedures for user identification, user authentication, and user authorization. All personnel should be made aware of these policies and procedures. [§ 3.6.2, § 3.10.14, Australian Government ICT Security Manual (ACSI 33)]

Metrics

The metrics associated with this control are as follows:

Report on the percentage of information assets with defined access privileges that have been assigned based on role and in accordance with policy. [UCF Control ID 02054]

Report on the percentage of active computer accounts that have been reviewed for justification of current access privileges in accordance with policy. [UCF Control ID 02094]