Strong Passwords and SEC Enforcement

Enforcements pertaining to passwords? There’s only been one cybersecurity enforcement and it pertained to a lack of policy and procedure, right? (We’re referring here to R.T. Jones) Wrong. In 2008 LPL Financial Corporation was enforced for willfully violating Rule 30(a), “The Safeguards Rule,” by having insufficient security controls and for failing to implement such controls. In the list of specific failures were numerous items pertaining to passwords – the basic building block of solid information security practices. For not responding to breaches resultant from failures in passwords and other items, LPL was fined $275,000 and censured. Furthermore, the firm was required to contract with an independent consultant to review their Policies and Procedures. How can you make sure that a similar fate doesn’t befall your firm? Read on for 6 basic password policies that your firm should have in place.

1) Use Strong Passwords – The language from the LPL enforcement is telling, so we will repeat it here: “… passwords did not meet industry standards for so-called “strong passwords” (our emphasis). A lot has changed since 2008 with respect to passwords, but even at that time the SEC believed strong passwords to be an industry standard. If your firm is not using strong passwords, it’s not a matter of if your firm will be breached, but when and what the SEC’s fine will be.
We have a lot more passwords floating around today than we did six years ago. Additionally, biometrics are starting to supplant the use of written combinations of letters, numbers, and symbols. Still, dating back to 2008 it was clear to the SEC that the use of simple passwords that didn’t involve upper-case letters, lower-case letters, numbers, and symbols wasn’t cutting it. We have to imagine that now, 8 years later, that still holds true. Your passwords should be as complex as feasible:

  • 8 characters is a minimum;
  • Upper-case, lower-case, numbers, and symbols should all be used;
  • If biometric passwords (like a fingerprint) can be used, they should be. Remember here, though, that a scanned fingerprint is usually backstopped by a password in case the scanner doesn’t work. Make sure that password is complex too; and
  • Mobile Devices, that primarily utilize a biometric reader, should also be backstopped with a complex password. If a simple numerical password is used, it should be paired with a lockout or wipe function (See Tip 6).

2) Set Password Expirations – A lack of timelines for password expiration was also noted in the LPL enforcement. Part of good password management is knowing when it’s time to go “out with the old.” At a minimum, we recommend that a password be changed at least every 6 months. Most firms these days choose to set more frequent password reset requirements, such as every 90 days. Stick with a reasonable limit and it will become just another part of your business process. You may see a slight uptick in IT related incidents around password change time, but these typically abate pretty quickly.

3) Don’t Allow the Reuse of Passwords or Common Passwords – As we’ve mentioned in previous posts, a password expiration policy is rendered essentially useless if your company does not restrict the reuse of passwords. From an industry best-practice standpoint, we find that non-reuse of the last 6 passwords is sufficient, although you can always opt for more.

In addition, do not allow for the use of common passwords (where one user has the same password for everything). This goes beyond business services and their corresponding passwords. Users should not have in place any passwords for work services that they use for their personal services. A lack of password commonality is also essential for system administrators or other individuals who may have access to elevated levels of permission on your network.

We also recommend prohibiting the use of sequential passwords. This typically is addressed from a policy standpoint, versus a technical one, but don’t let your users replace their password with a substantially similar one (e.g. – Complex1! to Complex2!). They may be different in the eyes of a policy, but if an old password is somehow compromised, the first thing hackers will attempt to do is to brute-force the system using sequential passwords.

4) Don’t Share Passwords – This was one of the key points of the LPL enforcement – users were not able to change their own passwords, they had to contact IT to do so, and the IT department maintained lists of all the usernames and passwords for the company. It may seem silly today, but it still happens. Oftentimes, under the guise of helpful IT staff. A lost password is reset by IT, who doesn’t require the user to go change that password. What just happened there, you might ask? Well, now the IT helpdesk has access to the user’s account who requested the reset. A password has just been shared within your organization. Data that the user may have restricted access to is now available to a different department. And, importantly, the IT staffer may now have responsibility if that username and password is at the center of a breach.

5) Employ Password Lockouts – Password lockouts exist to prevent an attacker from attempting to brute-force their way into a device or network by just repeatedly guessing a password. These lockouts should be employed across your network on all devices. This includes mobile devices such as smartphones and tablets.

If your policy allows for it we typically recommend setting a remote wipe on these type of devices after 10 incorrect password attempts. This is more important when a device is using a 4 digit pin as its primary password protection. Such a device can be cracked in a very short period of time.

For workstations and laptops with complex passwords, you can choose a lockout policy that requires a manual unlock by your IT person or a time-based unlock. The time-based unlock is typically preferable for smaller offices with limited IT staff. Should a person enter in their password incorrectly a given number of times, the account will be deactivated for a period of 10 minutes. This type of delay is generally enough to serve two purposes: first, it renders brute-forcing (or guessing) of passwords ineffective because it will take an infinitely long amount of time; second, it generally annoys users enough that they remember their passwords.

6) Include your Third-Party Vendors and Websites in your Password Policy – Remember to include your third-party vendors in your password change schema. If your firm decides to change its passwords every 90 days, but your vendor only requires a website login to be changed every 180 days, we recommend that you require your employees by policy to adhere to your more regular change cycle. We do see some vendors out there that still do not enforce any password change requirements, or complexity requirements. Remember that, even if you are placing your data with third parties, you have an obligation to reasonably protect it. If your vendor doesn’t require a complex password, you should. The regulators will expect it.

Like it or not, password security is still a foundational element of cybersecurity. The SEC made it clear in 2008 that a failure to implement and maintain a sufficient password policy could be an enforceable action. Eight years later, all IAs and BDs should review their password standards and controls surrounding them. These changes are easy to make and most of your employees are used to such controls from other places in their digital lives. If you haven’t looked at them in a while, make a password review part of your risk assessment this year. This will be time well spent.

For Reference:

In the Matter of LPL Financial Corporation, 2008 – https://www.sec.gov/litigation/admin/2008/34-58515.pdf