Password Policy

1. Purpose, scope, and users

A password policy is an important aspect of information systems security. A properly created password may significantly increase the security of a system, and vice versa; an improper weak password may compromise corporate sensitive assets.

The purpose of this document is

• To define a clear Corporate Password Policy standard for creating, protecting, and updating strong passwords for all Internal and External supported systems;
• To define a list of all third-party services that should be synchronized with the Resolver Corporate Password Policy;
• To prescribe rules to ensure secure password management and secure use of passwords; and
• To define criteria for critical services that should be protected with Multi-Factor Authentication (MFA) or Two-Factor Authentication (2FA)

This document applies to the entire Information Security Management System (ISMS) scope and all personal data processing activities.

The users of this document are all Resolver employees.

1.1. In-scope services

The following list of services should apply Resolver’s Password Policy:

1.2. Third-party services

Third-party services supporting Web SSO configuration should be integrated with Resolver Azure AD infrastructure so the policy will apply automatically.

The third-party services that do not support SSO / Web SSO integration with Resolver’s Azure AD infrastructure should be configured according to this Password Policy document.

1.3. Criteria for critical third-party services

All third-party services considered Critical should be protected with MFA or 2FA.

Critical services are those that store or process Confidential or Customer Confidential information as defined in Resolver’s Corporate Data Handling Policy.

2. Reference documents

• ISO/IEC 27001:2013 standard, controls A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, A.9.4.3
• NIST Special Publication 800-63B
• EU GDPR Article 32
• Information Security Policy
• Statement of Acceptance of ISMS documents

3. Policy rules

• All system-level default administration accounts (e.g., root, network administrator, local administrator, application administrator) should be disabled (not in use). Instead, alternative accounts with pseudo-administrative privileges should be created.
• Passwords should not be shared with anyone for any reason. They should not be written down or inserted into email messages or other forms of electronic communication or instant messaging systems.
• Users must use a unique password for each account. Using a unique password for each account means that your other accounts are not at risk, even in the event of a data breach in one of the services you use.
• Passwords should be stored in an encrypted or hashed manner with approver in “A.10 Resolver Corporate Cryptography Policy and Standards” algorithms (AES-256, SHA-256)

3.1. Account name

• Employee’s User Account name/UIDs/IDs must not contain any other personal information except First Name and Last Name.
• No roles, Access level, SS, SIN, or other personal information are allowed to be part of the account name.

3.2. Initial password creation and distribution

• Passwords should be generated according to this document’s Password Complexity Guidelines section rules.
• If the password is the initial Active Directory domain credentials, it should be communicated directly to the user by the user’s direct manager, domain administrators, or a member of the talent team. If one or more members of each of these teams are absent, a member of IT will post the password the night before or the day of the employee start via a private Slack channel containing members of the IT and Talent teams. The post will be deleted on confirmation of password change by the user.
• Initially created passwords (for all other systems except AD) should be communicated to the user utilizing at least two independent communication channels to mitigate the risk of the initial password being intercepted during transmission to the user, e.g. first part of the password over e-mail and second over Slack – deleting the password message in Slack when an entry is complete.
• Initial passwords set by a System Administrator and not by the user must be changed to a secret known only to the user on the first login.
• Forcing an initial password to expire after a set time period (e.g., 72 hours) helps mitigate this risk.
• Users will be forced to change their password at first login.

3.3. User password complexity guidelines

• All Resolver employees must set up Multi-Factor Authentication (MFA) using Office 365: https://aka.ms/mysecurityinfo .
• Resolver follows the password standards set out in NIST Special Publication 800-63B, section 5.1.1.
• The minimum password length is 20 characters.
• The maximum password length should be the maximum allowed by the application and, in any case, not less than 20 characters.
• There is no enforced maximum password age or requirement to update a password periodically; however, passwords must be changed if there is evidence of compromise.
• “Minimum password age” should be set to “1 day.”
• All printing ASCII [RFC 20] characters and space characters are acceptable in passwords.
• Passwords must be unique and cannot be reused from other accounts.
• Passwords must not be composed entirely of repetitive or sequential characters, for example, “aaaaa” or “12345”.
• Passwords cannot contain contextual information such as the user or service name.
• No other conditions shall be imposed on passwords, for example, requiring mixtures of different character types.
• “Enforce password history” should be set to “24.”
• “Store Password using reversible encryption” should be set to “Disable.”
• “Account lockout duration” should be set to “30 minute(s).”
• “Account lockout threshold“ should be set to “5.”
• “Reset account lockout counter after” should be set to “30.”
• “Screen Lock time out” should be set to “10 minutes.”

3.4. Service account

• Service account passwords must follow the same complexity standard as User password complexity guidelines.
• Service account passwords must be stored and managed using one of the approved Passwords or Secrets managers for this purpose. Currently, it is 1Password, AWS SSM Parameter Store, AWS KMS, and Vault by HashiCorp.
• Service account passwords must be changed whenever:
  • Any DevOps team member is terminated,
  • Or has changed roles and no longer requires access to the passwords
  • Or there is evidence of password compromise.

3.5. Employees account revocation

• Upon employee termination, the employee’s account password must be reset immediately if possible but not later than 24 hours after the termination.
  • for detailed step-by-step instructions for spot termination activities please refer to: /wiki/spaces/IST/pages/3577807043
  • For a regular employee’s deprovisioning process, see the IT Team’s HR project deprovisioning templates in Asana, created specifically for different employee groups.

3.6. Firmware passwords

• BIOS protection: Access to the Basic Input Output System (BIOS) should be protected by a password.
• Hard Drive Protection: Enable BitLocker for Windows and FileVault 2 for Mac platforms or another approved by the IT team full-disk encryption protection solution.
• Trusted Platform Module (TPM): Enable the TPM password.

3.7. Network infrastructure device passwords

This policy applies to (but is not limited to) Network Managed Switches, Routers, Firewall devices, Wi-Fi routers, Wi-Fi access points, Video / Phone Conferencing services, and anything defined as Internet of Things (IoT) devices.

• The default password for admin accounts for all network access devices should be changed.
• If any version of the SNMP protocol is used for remote administration, default SNMP
  community strings such as “public” and “private” should be removed before real community strings are put into place. If the SNMP protocol is not utilized for this hardware administration/monitoring purpose, SNMP should be disabled.

3.8. Printer passwords

• The default password for admin accounts for all printer Web access should be changed.

4. User obligations for password protection

• Do not share your password with ANYONE.
• Do not reveal your password over the phone to ANYONE.
• Do not reveal your password through an email/instant message to ANYONE.
• Do not reveal your password to your manager/boss.
• Do not hint at the format of a password (e.g., “my family name”).
• Do not reveal a password on questionnaires or security forms.
• Do not share a password with family members.
• Do not reveal a password to a co-worker while on vacation.
• Do not use the “Remember Password” feature of applications.
• Do not write passwords down and store them anywhere in your office.
• Do not store passwords in a file on ANY unencrypted computer system.
• Do not use the same password for multiple administrator accounts.
• If someone demands a password, refer them to this document or have them contact Information Security: infosec@resolver.com.
• If an account or password is suspected of being compromised, immediately report the incident to infosec@resolver.com and change all passwords.

The Information Security department may perform Password cracking or guessing periodically and randomly. If a password is guessed or cracked during one of these scans, the user will be required to change it.

5. User obligations for password management

When allocating and using user passwords, the following rules must be acknowledged and followed:

• By signing the Statement of Acceptance of ISMS Documents, users accept the obligation to keep passwords confidential, as prescribed by this document.
• Each user may use only his/her own uniquely allocated username.
• Each user must have the option to choose his/her own password, where applicable.
• As prescribed above, the temporary password used for a first system log-on must be unique and strong.
• Temporary passwords must be securely communicated to the user, and the user’s identity must be previously checked.
• The password management system must require the user to change the temporary password upon the first log-on to the system.
• The password management system must require the user to select strong passwords in accordance with this policy’s Password Complexity Guidelines.
• If the user requests a new password, the password management system must determine the identity of the user by a combination of these three unique attributes:
  • User logon name
  • Full user name
  • E-mail address
• Verification should be done through an alternative to e-mail communication channels like Slack.
• The user must confirm the receipt of the password by e-mail and/or Slack.
• The password must not be visible on the screen during log-on.
• If a user enters an incorrect password 5 consecutive times, the system must lock the user account in question.
• Passwords created by the software or hardware manufacturer must be changed during the initial installation.
• Files containing passwords must be stored separately from the application’s system data.

6. Non-Conformance

All policies require the participation of staff and contractors to be successful. Any employee or contractor found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

7. Validity and document management

This document is valid as of August 2023.

The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.

When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:

• The number of incidents arising from the unclear definition of the ISMS scope.
• The number of corrective actions taken due to an inadequately defined ISMS scope.
• Time put in by employees implementing the ISMS to resolve dilemmas concerning the unclear scope.

EFFECTIVE ON: August 2023

REVIEW CYCLE: Annual at least and as needed