Connor Group Information Security
Identity and Access Management (IAM)
Standard
Feb 2024
v.1.2
Introduction
Identity and Access management is central to securing the modern workforce. SaaS solutions and cloud implementations have distributed resources far beyond internal networks and controls, making identity the new border for security. Connor Group’s Identity and Access Management (IAM) Standard defines the requirements and expectations of managing access to resources using an identity-centric methodology.
This standard codifies expectations and requirements pertaining to Connor Group Identities managed by Connor Group IT . The standard exists as one in a set of documents which together, form Connor Group's Information Security Management System (ISMS).
Purpose
The purpose of this standard is to control access to Connor Group’s systems, applications, and sensitive data through secure identity management. Identity and Access controls are vital to ensuring business operations maintain availability, integrity, and confidentiality goals. Identity and Access controls ensure permissions to Connor Group resources are requested in an auditable process, approved by authorized individuals, regularly monitored, regularly reviewed, and promptly removed when no longer needed.
Scope
This Standard applies to IT systems managed or accessed by Connor Group, including both physical and virtual desktops, laptops, servers, handhelds, and third-party systems utilized by CG employees for business purposes.
This Standard applies to identities or accounts for all of the following:
- user accounts
- system accounts
- operating systems
- network or telephony systems
- infrastructure
- automated processes
- managed third party software products, including software as a service (SaaS)
- appliances
- hardware
- databases
- public cloud
- serverless
- application software
All staff and Third Parties responsible for the management of IT Systems must understand and follow the requirements herein.
In the event of uncertainty regarding the applicability of this Standard, contact Information Security for clarification and/or guidance at [email protected].
Definitions
References for terminologies or acronyms used within Information Security Standards can be accessed within the Glossary of Definitions (https://helpdesk.connorgp.com/a/solutions/articles/11000112202)
Standard
1. Controlling User Accounts And Groups
Ref |
Requirement |
1.1 |
Business requirements to control access to assets shall be defined and documented by the resource owner and based on requirements such as job function, role, group, department, etc. Access requirements should consider the following guidelines:
|
1.2 |
Changes to groups, roles, etc. must be controlled and documented to prevent unauthorized changes. |
1.3 |
Segregation of Duties
|
1.4 |
Resource owners of critical systems shall review and approve access requirements or privileges assigned to users, roles, groups, etc. at least annually or when new access requirements are defined. |
2. User Access Management
Ref |
Requirement |
2.1 |
Information Technology manages the creation of identities and birth right access within Connor Group’s environment using a formal process. |
2.2 |
System or data owners are responsible for approving non-birth right access to systems, including access to application data, logs, and application functions.
|
2.3 |
Formal records must be retained for evidence of authorizations and access rights (both granting and revoking) for audit and compliance. |
2.4 |
When a Connor Group employee or Independent Contractor changes jobs or ceases working for Connor Group, user access rights must be properly updated or revoked within 48 hours of notification. |
2.5 |
Managers must review and re-approve user access rights for all their staff at least annually and after any significant organizational change. |
3. Password Use and Management
Ref |
Requirement |
3.1 |
Initial allocation and resetting of passwords, including codes for multifactor tokens and private encryption keys, must be controlled through a formal process.
|
3.2 |
Passwords or data used as part of the password reset process (e.g., knowledge-based answers) are considered Confidential Data and must be protected as such. |
3.3 |
Systems should not display passwords on the screen by default. |
3.4 |
Passwords must not be stored as cleartext within application, system, code, or configuration files. Encrypted passwords stored within application, system, code, or configuration files must meet encryption requirements established by Information Security. |
3.5 |
Passphrases will be used instead of passwords where technically feasible and must:
|
4. Identification and Authentication
Ref |
Requirement |
4.1 |
User account names must conform to naming standards and should not give indication of the users’ access rights (e.g., contain words such as manager, supervisor or privileged). |
4.2 |
When connected remotely, multi-factor authentication technology must be in place to substantiate the identity of users. |
4.3 |
Generic or default user and system accounts must be renamed or removed as appropriate. |
4.4 |
Nonrepudiation is required for all interactive accounts. Accounts may not be shared among individuals without a mechanism to assign accountability for use. |
4.5 |
Accounts must not be shared across environments (Test/Development/Production). |
4.6 |
Non-Human accounts (service accounts) should be configured to block interactive use.
|
Compliance
Information Security team shall verify compliance to this policy through various methods, including but not limited to, walk-throughs, environment sampling, process review, monitoring, business tool reports, internal and external audits, and through feedback to the policy owner.
Any exceptions to this Standard require a formally approved exemption documenting justification and approval against compliance to this Standard. Exemption approvals are required prior to systems entering live operations or remaining online after the remediation plan grace period has expired.
The following are required to adhere to this Standard, except where a formal exception has been granted as above:
- All Connor Group Systems and employees, independent contractors, and subcontractors. Any individual found to have violated this Standard may be subject to disciplinary actions including termination and legal recourse.
- Any Third-Party System that is used to support Connor Group data and/or Services. Any Third Party that violates this Standard will be considered to have breached their contract with the Connor Group.
Revision History
Revisions require approval by the Director of Information Security and dissemination to applicable business units prior to release.
Version |
Detail |
Author |
Date |
1.1 |
Formatting revised with Requirements section enumerated for easier reference. |
Connor Group Information Security |
May 2022 |
1.1.1 |
Annual review and 4.4 updated for non-repudiation |
Connor Group Information Security |
Feb 2023 |
1.2 |
Annual Review - Introduction section updated to resolve references to Patching Standard - Purpose section updated for clarity - Removed ‘platform’ from Scope section for clarity - Definition section updated to reflect FS link for IT Glossary
|
Connor Group Information Security |
Feb 2024 |
|
|
|
|