Risk-based password requirements
Let’s look at two examples to understand how password implementation might differ based on risk. (Note: Risk assessments are extensive and dive deeply into the entire healthcare ecosystem being considered. These examples should be taken as high-level illustrations intended to help you understand how to get started.)
Example 1: Lower Risk
In the first example, a healthcare provider logs into a workstation to view ePHI that is encrypted and stored on a local server. The workstation and the server are located on an internal subnet that is only accessible from designated workstations within that office, neither the workstations nor the server can be accessed remotely, and the subnet is hard wired, with no Wi-Fi access.
As a result, you might choose to implement a password policy that calls for shorter, simpler passwords, a longer timeout period before the password must be re-entered, and fewer required password changes each year.
Example 2: Higher Risk
In the second example, a doctor working from home accesses ePHI through a cloud-based application. The risks associated with this example include brute force attacks that could successfully get past simpler, shorter passwords, or phishing attacks that supply the attacker with account credentials.
In this case, your passwords should be as strong as possible, and you should have multi-factor authentication in place as well.
When determining what your password policy should be, it’s a good idea to start with a defined standard.
- Set an 8-character minimum length.
- Change passwords only if there is evidence of compromise.
- Screen new passwords against a list of known compromised passwords.
- Skip password hints and knowledge-based security questions.
- Limit the number of failed authentication attempts.
Other well-known standards include PCI DSS, CIS CSC, etc.
Next steps: map your ePHI
Implementing a functional password policy starts with performing a risk assessment. Part of the risk assessment includes enumerating all the systems that require passwords, all the places ePHI exists, and all the people who potentially have access to those systems.
Map out the ePHI data flows to include relevant information so that you can apply password policies in meaningful ways, as determined by risk. Remember that each individual accessing ePHI needs their own unique ID, and passwords should never be shared. Finally, logins need to be logged so that access to ePHI can be traced to individuals.
Jen Stone (MSCIS, CISSP, QSA) is a Principal Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.