There’s an expression in geekdom called “yak shaving” that refers to doing busywork that appears important but is actually useless. The essence is that yak shaving is easier to do than dealing with the actual problem at hand (which is often complex and hard).1
There’s only so much security training the average user can absorb before it falls out of their ears and they want to get back to work. Yet, some organizations will do long and extensive security awareness campaigns followed up with simulated phishing attacks to shame users. There is already a bit of skepticism2 in the industry regarding the effectiveness of security awareness training and repeated phishing training.3 Granted, targeted and relevant security awareness training is effective and useful, but it should be focused on what actionable decisions you want the user to make. Long lectures about the effectiveness of complex passwords are a waste of time if you can already just force them to use complex passwords by policy (which nearly all systems support). Pick your battles and consider your users’ attention span: keep training laser-focused and actionable.
Like the security awareness user overload problem, there is the torrent of security policies and rules. Yes, security policy is critical as is robust acceptable usage policy,4 but some folks don’t stop there. Some organizations require every employee and contractor to read and agree to dozens (if not hundreds) of pages of security policy. How much do you expect users to retain and obey? The receptionist at the front desk doesn’t need to concern himself with a multi-page policy section on server patching and configuration hardening. It’s too much.
Remember, regulators and auditors can hold you responsible for everything you’ve promised to do in your policy. A 75-page policy with thousands of “musts” and “thou shalts” can backfire if everyone doesn’t read, understand, and obey every single rule, all the time.
You’re better off following the KISS principle and Keeping It Simple and Stupid. An overarching security policy is a high-level statement that applies to general staff and doesn’t need to be more than a few pages long. Think about who will be reading and interpreting the policy. It should affirm management’s commitment to reducing cyber risk and implore staff to follow guidelines and safeguards to keep systems and data safe. Then, you can publish specific, detailed security guidelines, procedures, and standards for the relevant folks who will actually do the work with the appropriate technologies. I’ve seen more than a few organizations that have separate, longer security policies and rules for those with extraordinary access like system administrators.
No security control is going to stop all hacks (unless that control involves pulling the plug out of your computer), but that doesn’t stop some security folks from spending months trying to find the perfect solution. It’s an easy trap: the solution that’s compatible with our processes and technology will only stop 80 percent of attacks, but if we keep looking at and piloting tools, we might get that up to 90 or 95 percent. And then begins the endless hunt for the perfect firewall, the perfect multi-factor solution, the perfect code scanner, the perfect change control policy, the perfect encryption tool… Meanwhile, there is an existing unacceptable risk that is not being addressed creating a window of exposure, as well as numerous other risks not being mitigated.
As they say, perfect is the enemy of good.5 Pick a control that is going to be the most effective in your organization. By effective, I mean good enough that it addresses an acceptable level of the risk and fits with your other requirements (money, process, compatibility). Tune and tweak the best you can. There will be leftover risk not being addressed. This is where you can add a second, diverse control to get defense in depth.6 Either that, or have management accept what risk is left over and move on. There are undoubtedly many other risks and emerging threats you need to deal with.
Some CISOs expend a lot of energy trying to make a rigid password policy fit across every system and process within an organization. They cling to the best practices for password complexity, rotation, and length as tightly as a religious dogma. I have seen large global organizations with 45-day password rotation policies which, of course, led to all kinds of riskier user workarounds. Most password “best practices” were born before the age of rainbow tables,7 phishing, credential theft, and credential stuffing. In fact, most of the risks that traditional password standards were trying to address date back to the time of the mainframe.8
Rather than focusing on best practices and rules for a control, it would be more useful to address the real risk. In fact, the National Institute of Standards and Technology (NIST) recently revised its authentication guidelines to include looking at password management as a risk management problem and not a simplistic hard rule in password configuration. The guidelines state:
“Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. The minimum password length that should be required depends to a large extent on the threat model being addressed.” 9
The current window of risk with passwords now is the period between the theft of a password and the owner changing it. It would be more useful to address your bigger picture of authentication management than get hung up in password management.
As always in security, everything comes to down to risk management: What are the actual threats and what are the most effective ways to treat them? If you keep that in mind, you’ll never stray too far into yak shaving.
MODIFIED: Jul 25, 2017