Developing a Password Policy
A password policy cannot be created in a vacuum, it must be derived from the Security Policy & Process of the Organization. Usually, this is called the ISMS, or Information Security Management System. In the general case, it will consist of a variety of policy documents addressing different aspects of information security.
For Banking and Payments, an ISMS will direct its Business Units to derive best practices from at least the following standards and regulatory artifacts:
- PCI SSC – Payment Card Industry Security Standards Council
- SOX – Sarbanes-Oxley Act
- GLBA – Gramm-Leach-Bliley Act
- … and potentially others.
Per PCI, SOX and GLBA requirements, your password needs will comply with these requirements:
- 2.1 – Never use vendor-supplied defaults
- 2.3 – Encrypt all non-console administrative access using strong cryptography
- 3.6.6 – If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
- 6.3.1 – Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
- See Requirement 8: Identify and authenticate access to system components
Sarbanes-Oxley experts and auditors recommend that to meet the minimum for compliance, passwords should:
- Be at least eight characters long;
- Include a combination of letters and numbers;
- Not contain personal information.
Section 501 of the GLBA, “Protection of Nonpublic Personal Information,” requires financial institutions to establish appropriate standards related to the administrative, technical, and physical safeguards of customer records and information. The scope of these safeguards is defined in the GLBA Data Protection Rule, which states that financial institutions must:
- Ensure the security and confidentiality of customer data
- Protect against any reasonably anticipated threats or hazards to the security or integrity of such data
- Protect against unauthorized access to, or use of, such data that would result in substantial harm or inconvenience to any customer.
When creating any kind of Security Policy, avoid the temptation to first consider assets, such as information systems consisting of infrastructure, applications, and operating systems. Instead, focus on the sensitive information that requires protection.
A Security Policy can be understood as follows:
It is a high-level statement (plan or framework) addressing security requirements and objectives. It may address an entire organization or be specific to an issue or system.
It is a type of governance in that it expresses the security framework established by management. It is the primary method by which an organization sets expectations for a variety of topics.
- The audience for the policy consists of architects, designers, implementers, installers, maintainers, and users of the Information the Organization needs to protect.
- Policies can be written to affect hardware, software, access, people, connections, networks, telecommunications, enforcement, and so forth.
- A good Security Policy cannot be drafted without a comprehensive understanding of the security standards that must be achieved.
While a Security Standard may be an internally developed, it is usually an external document authored by a regulatory organization (e.g., PCI SSC), or an organization tasked with developing best practices (e.g., NIST, ISO, ISACA).
- A Security Standard is an enumeration of actions or rules that must be performed or followed to implement a Best Practice. E.g., NIST SP-800-53, ISO 27001, COBIT
- A Security Process defines a set of activities or related tasks that when combined, produce the desired result.
- Procedures are step-by-step instructions to perform various tasks in accordance with established Policy and Process.
- Guidelines provide advice regarding how to achieve a goal of a Security Policy, or Process. They are a communication tool used to provide suggestions, they do not provide rules.
Developing an Information Security Policy
Data Identification and Scope
- Identify sensitive information that must be protected;
- Identify every location where sensitive information is scored;
- Develop data classifications and tag data;
- Determine in-scope information systems and out-of-scope information systems, tagging information systems appropriately;
- Determine the approved ways in which data may be accessed.
Develop a Risk Management Framework
This is a key process to developing a password policy.
- A Risk management framework helps you understand the risks associated with your information and how to manage those risks.
Establishing a risk assessment framework
- Identify risks
- Analyze risks
- Evaluate risks
- Select risk management options
Create the Risk Treatment Plan
- This involves creating and managing security controls to mitigate and remediate risks.
Putting it together
Once you understand the data that must be protected, and the systems that process that data, the risks to which you are most commonly exposed, you can then begin developing requirements for Information Systems relevant to:
- Regulatory requirements;
- Data classification;
- Best Practices;
- User Experience & Acceptance