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 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 ADFS infrastructure so the policy will apply automatically.
The third-party services that do not support SSO / Web SSO integration with Resolver’s ADFS infrastructure should be configured according to this Password Policy document.
1.3. Criteria for critical third-party services
All third-party services considered as Critical should be protected with 2FA Authentication.
Critical services are those which 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.
- 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)
- For all purposes, except regular (interactive) users accounts, passwords should be created with the maximum number of characters the specific software allows.
- Never use the same password for multiple resources.
3.1. Initial password creation and distribution
- Passwords should be generated according to the rules in the Password complexity guidelines section of this document.
- 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. In the event of the absence of one or more members of each of these teams, a member of IT will, via private Slack channel containing members of the IT and Talent teams, post the password the night before or day of employee start. 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 themselves 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.2. User password complexity guidelines
- 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 30 characters.
- There is no enforced maximum password age or requirement to periodically update a password, 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, as well as the space character, 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.3. Firmware passwords
- BIOS protection: access to 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 full-disk encryption protection solution.
- Trusted Platform Module (TPM): enable the TPM password.
3.4. 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.5. 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: firstname.lastname@example.org
- If an account or password is suspected to have been compromised, report the incident immediately to email@example.com and change all passwords.
Password cracking or guessing may be performed on a periodic or random basis by the Information Security department. 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.
- The temporary password used for a first system log-on must be unique and strong, as prescribed above.
- 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.
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 July 2020.
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: September 2020
REVIEW CYCLE: Annual at least and as needed
REVIEW, APPROVAL & CHANGE HISTORY: Last time reviewed and approved in August 2020 by Resolver’s Information Technology Security team.