Identity and Access Management policy guidelines

Identity and access management policies are documents that explain how users should connect to network resources.

IAM policies cover critical security areas. This includes authenticating user accounts, assigning access privileges, and password usage. Guiding users and system administrators, they act as a basis for disciplinary action when policy breaches occur.

The article will introduce IAM policies and discuss their value for organizations. We will discuss their general contents and run through an example document. Readers will be well-placed to create a functional Identity and Access Management policy.

Why do you need to create an IAM policy?

Identity and access management policies assist both users and network administrators. For users, a well-written policy explains how to safely access networks. Meanwhile, administrators receive a clear set of rules for access management.

IAM policies lay the foundations to solve many fundamental access management challenges. Security concerns addressed by policies include:

• Credential thefts due to weak authentication practices
• The use of weak passwords and the exposure of user credentials.
• Internal attacks via administrator account privileges.
• Security risks posed by shared accounts.
• Outsider attacks via third-party users and vendors.
• Orphaned accounts can become vectors for cyber-attacks.
• Insecure remote access via home devices or public wi-fi.
• Compliance issues due to poor auditing of access requests.
• Poor perimeter protection due to chaotic access controls. Lack of a unified enterprise-wide access management policy.
  
  

The policy aims to create certainty and reduce confusion. It provides easy-to-follow rules that apply across the whole organization. A good policy means security teams do not need to improvise.

Access policies make cybersecurity more robust by hardening the network perimeter. Robust MFA and privileges management systems deliver enhanced protection for confidential information. This lowers the risk of data loss and helps companies meet their compliance goals.

IAM policy guidelines

IAM policies vary between organization types. For instance, universities and banks operate different authentication and account management systems. But the basic principles and policy structure are consistent.

A typical policy structure should look something like this:

• Version history. Includes details of previous versions of the policy. Also features information about the current iteration.
• Purpose/Scope. What the policy document aims to achieve, and why it is important.
• Audience. Who the policy applies to, and who is liable for penalties if policies are not followed.
• Definitions. A short glossary of terms used in the document. This will assist readers in understanding authentication requirements.
• Identity and access management policies. Specific sections on critical areas of access management. Topics covered may include:

  • Access control. Rules relating to log-in procedures and account creation.
  • Account management. Rules for system administrators. Includes account data, shared accounts and logging user activity. Also features recommendations on de-provisioning redundant accounts.
  • Administrator/special access. Guidance to reduce the risk posed by administrator account holders.
  • Policies about access rights and verification methods. Includes password management, MFA, and logging policies at the user verification stage.
  • Rules for administrators about managing access privileges. Focuses on providing access while applying the principle of least privilege.
  • Remote access. Policies relating to remote connections and securing remote work. Focuses on device security and authentication practices.
  • Vendor access. Policies about third-party vendor access. May include reference to third-party maintenance and support partners.
  • Rules governing data collection. Seeks to meet regulatory goals and improve general security procedures.
• Exceptions. Users may need access in situations that breach specific access rules. Explain how to manage such exceptions. This should be short because the policy itself should cover most practical situations. Exceptions should be rare, so a short referral is all that's needed.
• References. Details of any regulatory frameworks or internal documents referenced by the policy. This enables readers to access further sources of information. Network users can seek further guidance if needed.
• Enforcement. A short warning section. This details penalties for breaching the Identity and Access Management policy. This includes both internal sanctions and the possibility of civil or criminal penalties.
  
  

This is an example, and information security requirements vary. Some organizations may combine account management and authorization. Other companies may not require a section on vendor identity management.

The final document should reflect the needs of each organization. It should deliver clarity while covering every relevant Identity and Access Management need.

The question is, how should you approach the task of creating an access management policy? There is no single template. But the following policy will help create rules for your information security setting.

Example of Identity and Access Management policy

NordLayer offers a downloadable file with a template for an IAM policy. This helpful resource simplifies managing secure access to company information.

Downloadable PDF

The Identity and Access Management policy of (Organization/Company) establishes requirements to ensure safe access and use of company information resources. The policy aims to guarantee that (Organization/Company) IT resources comply with security and business requirements and in accordance with any relevant (Organization/Company) policies.

Identity and access management policy purpose

The (Organization/Company) Identity and Access Management policy sets out requirements to ensure safe access and use of company information resources. The policy seeks to ensure (Organization/Company) IT resources comply with security and business requirements and according to any relevant (Organization/Company) policies.

Download the PDF of the IAM policy guidelines

Who the IAM policy applies to

The (Organization/Company) Identity and Access Management policy applies to individual account holders responsible for controlling IT resource access. It also applies to all users granted access to use (Organization/Company) resources.

Definitions

• Access. The ability to enter network settings so that users can change or use information resources.
• Authentication. The verification of user identities before allowing access. This may include passwords and additional methods such as multifactor authentication.
• Authorization. The assignment of access privileges following successful authentication.
• Access control. The process of allowing or refusing network entry AND the refusal of access to network resources beyond those specified by a user’s privileges.
• Principle of least privilege. Admins should limit access rights to resources users need to carry out their duties. Security controls should block all other resources.
• Separation of duties. The division of security tasks and responsibilities. Aims to prevent one user from controlling a process from beginning to end. Individuals should not control access systems, authorization approvals, and auditing tasks.
• Data trustees. Senior individuals within the (Organization/Company). Trustees are responsible for protecting data in their functional area. Data trustees must approve exceptions to the access policy.

Identity and access management policy elements

Access Control

• Users of (Organization/Company) resources must have a legitimate business justification. Proof of this justification must be provided before approving access.
• Multi-factor authentication must establish the identity of users before granting access.
• All log-in requests must be processed via secure portals and procedures.
• Ownership of all (Organization/Company) resources should be clearly defined and stored.
• All-access rights must be on a “need to know” basis.
• All-access requests must be logged when users access confidential or private data.
• Connected devices should implement forced lock-outs if users are inactive for a predefined period.
• User access settings and permissions should be stored and added to disaster recovery plans.

Account Management

• Users of the (Organization/Company) network must sign the Information Security Policy Acknowledgement. This must happen before users create an account and before gaining access
• No accounts should be created without documented requests and approvals. Two independent actors should ideally make approvals with technical and administrative roles.
• Duties must be segregated between access requests, authorizations, and account administration.
• The owners of information resources are responsible for approving access rights.
• Access requests and access rights should be reviewed regularly, with reconciliation where required. Reviews must be documented.
• Accounts must receive a unique ID code provided by IT staff. IT teams must implement systems to delete and block redundant user IDs.
• Password expiration should apply, meeting the (Organization/Company) authentication standard.
  
  

In addition to special accounts (see below), security administrators may be responsible for managing the following account types:

• User accounts. Basic user accounts are linked to an individual account holder. If possible, they should be secured by a central directory/repository and provisioned by centrally managed federated authentication.
• Shared accounts. The use of shared accounts should be minimized. If shared accounts are needed, the resource owner must document their use. All shared accounts must receive approval.
• Third-party accounts. Security teams must approve any accounts to access third-party cloud applications. The resource owner must also approve all internal information sharing.
• Service accounts. Accounts connecting applications or services must be documented and approved. Authentication Standards must apply to every service account. Security teams must ensure that individuals do not use service accounts to access (Organization/Company) resources.

Administrator/Special Access

• All administrative/special accounts require individual instructions, documentation, and authorization.
• Multifactor authentication must be used for all administrator account log-ins.
• Administrative account holders must only use their accounts for tasks related to their job description. They must avoid all abuse of privilege while logged into (Organization/Company) resources.
• Individuals with special/administrative accounts should use those accounts only for relevant tasks. Users should only create these accounts as a last resort.
• Passwords for administrative accounts must change when users move between roles or leave the company/organization.
• Password escrow policies should be in place to ensure access to administrative/special accounts to allow access in emergencies.
• All special access accounts must follow the (Organization/Company) authentication policy.

Authentication

User passwords must meet the (Organization/Company) authentication standard:

• Minimum length: 8 characters
• Strength: Must include at least 1 lower case letter, 1 upper case letter, 1 number, and 1 symbol.
• Expiry: Passwords must be changed every 90 days.
• Lock-out limit: 5 failed password attempts.
• Lock-out duration: 45 minutes
• Storage: Encrypted, no clear text storage.
• Screensaver: Password protected after 10 minutes of inactivity
  
  

In addition, the following password management rules apply:

• Users must employ unique passwords for each IT resource/system.
• Security teams must encrypt stored passwords and classify them as confidential.
• Passwords supplied by vendors with third-party products must be changed immediately. Resource owners should delete any default accounts or disable their use.
• All account passwords must remain private. Passwords should never be shared with external contractors or support providers.
• Passwords must be changed immediately if security concerns arise.
• Users should not use remembered passwords, hardcoded passwords, or embedded scripts. Any exceptions to this rule must receive approval from IT managers.
• Password management solutions must comply with the (Organization/Company) Authentication Standard.
• Password change processes should demand strong passwords. Users must change their password at the first login. Administrators must also immediately change passwords if users report external credential theft or exposure.
  
  

MFA standards:

• Multifactor authentication is mandatory for all account holders.
• If the (Organization/Company) uses additional authentication technology (such as smart cards or security tokens), these systems must be assigned to an individual. Logical controls should ensure that only the named individual can use those authentication systems to access IT resources.
• Users should return any physical authentication tokens when their role ends.
• There should be no shortcuts to circumvent the authentication standard. Admin and special account users must apply appropriate access controls.

Authorization

• Administrators should apply role-based authorizations where possible.
• Authorization should be as granular as possible, applying the “principle of least privilege.” Users should have access to the resources they need and nothing more.
• All authorization requests must receive administrative and technical approvals.
• Resource owners must assess shared accounts and ensure users within groups require the same privileges.
• Requests for confidential information should receive approval from Information Security professionals.
• Privileged access requests must be documented. This applies to successful and failed requests. Documentation should include the duration of the access period, the nature of the request, and the identity of the individual making the request.
• Administrators should avoid pre-authorization for requests from administrative/special accounts.

Remote access

• Remote access requests must be made via approved methods. Remote access methods must include encryption and MFA.
• Users must seek approval for remote access connections before accessing the (Organization/Company) network.
• Users should not be able to copy or print confidential data remotely.
• Systems should log all remote access connections.
• Remote access connections should be time-limited. Connections should terminate after a pre-defined inactivity period.
• Users should be unable to connect to additional private networks while connected to (Organization/Company) resources. Exceptions must receive formal approval from IT professionals.
• Remote access for support and maintenance must be approved and logged. Systems should be in place to prevent unauthorized access by third parties.
• All remote access users should receive and approve the (Organization/Company) Remote Access Instructions and Responsibilities.

Vendor access

• Access by vendors to (Organization/Company) IT resources should comply with identity and access management policies. All-access requests must have unique identifiers.
• IT teams must monitor and document all vendor activity while using (Organization/Company) resources.
• Any vendor activity involving external internet or telephone network connections should be disabled. Exceptions for maintenance must receive authorization from IT teams.

Auditing

• IT teams must collect data regarding account creation and deletions and any changes to passwords and authentication processes for individual accounts.
• Audit logs must show evidence of approvals for account creations/deletions and the assignment of privileges.
• Audits of authentication and authorization processes must be carried out regularly. There must be specialist audits for privileged accounts, including the participation of data trustees (or similar executive-level officers).
• Audits should examine account de-provisioning and expiration of third-party privileges to limit access to active (Organization/Company) resource users.

Exceptions

Information security personnel may grant exceptions to the identity and access management policy. Any exceptions require prior review by more than one individual.

In the case of an exception, IT professionals must ensure that compensating controls mitigate any additional risk incurred by granting an exception.

IT staff must also assess the number of exceptions and make appropriate amendments to the IAM policy if required.

Enforcement

Any individuals in violation of this policy will be subject to disciplinary action. Enforcement actions could include termination of employment or applicable civil and criminal penalties. Penalties for breaching this policy include loss of access rights and contract termination. Any relevant civil and criminal sanctions may also apply.