Posted under: Research and Analysis
Information Security is a profession. We have job titles, recognized positions in nearly every workplace, professional organizations, training, and even some early degree programs. I mean none of that sarcastically, but I wouldn’t necessarily say we are a mature profession. We still have a lot to learn about ourselves. This isn’t unique to infosec, it’s part of any maturing profession, and we can learn their lessons.
As I go through the paramedic re-entry process I realized, much to my surprise, that I have been a current or expired paramedic for over half the lifetime of the profession. Although I kept my EMT up, I haven’t really stayed up to date with paramedic practices (the EMT level is basically advanced first aid; paramedics get to use drugs, electricity, and all sorts of interesting… tubes). Paramedics first appeared in the 1970’s and when I started in the early 1990’s we were just starting to rally behind national standards and introduce real science of the prehospital environment into protocols and standards. Now the training has increased from about 1000 hours in my day to 1500-1800 hours, in many cases with much higher pre-training requirements (typically college level anatomy and physiology). Catching back up and seeing the advances in care is providing the kind of perspective that an overly-analytical type like myself is inexorably drawn towards, and provides powerful parallels to the less-mature information security profession.
One great example of a deeper understanding of the consequences of the science is how we treat head injuries. I don’t mean the incredible, and tragic, lessons we are learning about Traumatic Brain Injury (TBI) from the military and NFL, but something simpler, cleaner, and more face-palmy.
Back in my active days we used to hyperventilate head injuries with increased intercranial pressure (ICP, because every profession has to have their TLAs). In layman terms… hit head, go boom, brain swells like anything else you smash into a hard object (in this case, the inside of your own skull), but in this case it is swelling inside a closed container with a single exit (which involves squeezing the brain through the base of your skull and pushing the brain stem out of the way, oops). We would intubate the patients and bag them at an increased rate with 100% oxygen for two reasons — to increase the oxygen in their blood and try and get more O2 to the brain cells, and because hyperventilation reduced brain swelling. Doctors could literally see a brain in surgery shrink when they hyperventilated their patients. More O2? Less swelling? Cool!
But outcomes didn’t seem to match the in-your-face visual feedback of a shrinking brain. Why? It turns out that the brain shrinks because when you hyperventilate a patient you reduce the amount of CO2 in their blood. This changes the pH balance, and also triggers something called vasoconstriction. The brain sank because the blood vessels feeding the brain were providing less blood to the brain.
Well, darn. THAT probably isn’t good.
I treated a lot of head injuries in my day, especially as one of the only mountain rescue paramedics in the country. I likely caused active harm to these patients, even though I was following the best practices and standards of the time. They don’t haunt me, I did my job as best I could with what we knew at the time, but I certainly am glad to provide better care today.
Let’s turn back to information security and focus on passwords. Without going into the history our password standards, in most cases, no longer match the risk profile. In fact, we see these often causing active harm.
Requiring someone to come up with a password with a bunch of strange characters and rotate it every 90 days no longer improves security. Blocking password managers from filling in password fields? Beyond inane.
We originally came up with our password rules due to peculiarities with hashing algorithms and password storage in Windows. Length is a pretty good one to put into place, and advising people not to use things that are easy to guess. But we threw in strange characters due to rainbow tables and hash matching. Forced password rotations due to letting people steal or databases and having time to brute force things.
However, if we use modern password hashing algorithms and good seeds we dramatically reduce the chances of brute force attacks even if someone steals the password. The 90 day and strange character requirements really aren’t overly helpful. They are, in fact, more likely harmful since users will forget their passwords and rely on weaker password reset mechanisms. Think the name of your first elementary school is hard to find? Let’s just say it ain’t as hard to spot as a unicorn.
Blocking password managers from filling fields? In a day and age when they are included in most browsers and operating systems? If you hate your users that much just dox them yourselves and get over it.
The parallel to treatment protocols for head injuries is pretty damn direct here. We made decisions with the best evidence at the time, but the times changed. Now the onus on us is to update our standards to reflect the current science.
Block the 1234 passwords and require a decent minimum length, but let the users pick what they want and focus more on your internal security and storage, seeds, and hashing. Support an MFA option appropriate to the kind of data you are working with, and build in a hard to fake password reset/recovery option. Actually, that last area is one that’s ripe for more research and better options.
We shouldn’t codify negative outcomes into our standards of practice. And when we do, we should recognize and change. That’s the mark of a true, continuously evolving profession.
*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by firstname.lastname@example.org (Securosis). Read the original post at: http://securosis.com/blog/best-practices-unintended-consequences-negative-outcomes