New cybersecurity talk recorded

Posted December 4, 2018 by Marc Abel

It's not a coincidence that the four countries most known for cyber attacks against the United States are the same four that are most known for human rights abuses against their own people. Unfortunately, U.S. treatment of these regimes as plausible opponents in cyberspace tends to legitimize claims of sovereignty with respect to their crimes at home. The reason for this is that if Iran, North Korea, China, and Russia can be viewed as peers with respect to technology, they can also be given credence in other domains.

Until these parts of the world improve their stance on human rights, no bragging rights should be extended them concerning any kind of military capacity. A key domain where the U.S. needs to stand its ground is information and network security—but we're doing a crummy job thus far. We need to show by example that our shared values, approach to the economy, and representative system of government are stronger. Please listen to my thoughts as to how we can win in cyberspace, and tell your friends.

Apocalypse Not
Practical Security Against State-Sponsored Shenanigans
about 48 minutes

When given in person, this talk includes a section for questions and answers. I hope you'll consider inviting me.

Finally, user-friendly password standards

Posted July 12, 2018 by Marc Abel

I still remember my first computer password, even though it's been more than 35 years since I've had to use it. In those years, new passwords were a lot less intrusive. They weren't obnoxiously long, there weren't esoteric rules for the characters allowed, and most people didn't have to remember very many passwords. But then civilization made a dark turn.

As a random example, consider TreasuryDirect.gov, the website where you buy EE savings bonds and other securities backed by the full faith and credit of the U.S. government. As of July 2018 your password can have a breve ` in it, but backslash \ is forbidden. You can have braces, parentheses, and square brackets giving you all of {}()[], but if you choose < or > you will be needing a U-turn.

Then there is the whole matter of password expiration policies. Only yesterday, one of my vendors insisted that I retire a password because I hadn't changed it in more than 60 days. As it happens, I hadn't used their website in more than 60 days, so I was only allowed to use my last password on the day that I changed it. This story might sound familiar to certain government personnel! Of course there is no security concern with a password's age, whether 60 days like this one or 13,000 days like my first one. The security concern is when a password is leaked, and once that happens, the next few seconds can see assets stolen or destroyed. You don't have weeks or months for the password to expire, and even if it does expire, years might pass before its owner returns to be prompted to change it.

Fortunately if your organization's password rules date from the Triassic period, contemporary expert advice permits you to make very sensible updates, and there are business incentives to move quickly. Whence originates this wisdom? Here again, your government:

NIST Special Publication 800-63B
Digital Identity Guidelines:
Authentication and Lifecycle Management
June 2017

The part of this document that pertains to passwords is section 5.1.1, although NIST doesn't use the word password when referring to your password. They call it a memorized secret authenticator, and they can use this term because, well, they're NIST. I'm going to call it a password anyhow, even though none of my "passwords" are actually words, and hopefully none of yours are, either. Here is what your users stand to gain:

all US keyboard symbols allowed
space character allowed
Unicode characters allowed
no requirement to include specific character groups
required length of no more than 8 characters
supported length of at least 64 characters
length as short as 6 characters if randomly generated

In short, organizations that adopt section 5.1.1 guarantee their users a predictable, consistent, and realistic set of rules with respect to password selection. That means that one set of password rules can work across many organizations and systems, allowing users to work out methods for choosing passwords that work regardless of where they are used. The guidelines also impose new technical standards that improve password processing security that aren't visible to end users.

With all this relaxation, streamlining, and standardization, you might be wondering what will stop users from picking weak passwords. They always seem to! The answer is that you will stop them, and SP 800-63B specifies effective ways of banning unwise passwords.

It turns out that when people choose bad passwords, they're always bad for the same reason: they're too easy to guess. NIST's solution is for you to compile or obtain a list of commonly used passwords, and check to see if your user has chosen a password in that "blacklist." Because there are (at least) tens of millions of leaked passwords available online along with some other lexicons, it's easy to produce a good list of unsuitable choices and automatically disallow their use.

It's tempting to think that if your infrastructure seems to be working, there is no urgency to adopt SP 800-63B. After all you may already require eight characters, and at least one capital letter, lowercase letter, numeral, and other symbol. What can possibly go wrong? The trouble is that many of your users already hate computers, and the formula in this paragraph is reckless enough that some of that hatred may get redirected toward your company. This hatred may show up in an employee's demeanor or a customer's departure. Even if the user's frustration isn't apparent to you, it might be overwhelmingly evident in their choice of password, which you won't know about until there is a data breach.

It turns out that P@ssword1 is seen very frequently when character-set inclusion rules are imposed. Not only do users turn in frustration and exhaustion to this combination, but as of this writing there is a large bank that actually advertises this as the initial password for new accountholders! If things are like this in your shop, NIST SP 800-63B should be your new best friend.

Summer computer security reading

Posted July 17, 2018 by Marc Abel

Here is a very small collection of superb quality, upbeat, diverse, and distinctly non-technical literature by other writers that has immediate relevance to contemporary information security challenges.

Leaders Eat Last: Why Some Teams Pull Together and Others Don't
Simon Sinek
New York: Portfolio/Penguin
2014 paperback

All information vulnerabilities are of human origin, and their solutions are more human than technical. Sinek's book examines leadership-induced failures of the human spirit in workplace situations and teaches a safer path for management. While this does not purport to be a computer book, it is highly applicable to security and is an excellent read at all levels in your cybersecurity management.

A reimplementation of NetBSD based on a microkernel
Andy Tanenbaum
EuroBSDcon, Sofia, Bulgaria
2014 video

This entertaining talk is easy to follow, even if you don't recognize the three longest words in its title. Dr. Tanenbaum is one of computing's rock stars, and his practical wisdom on simplicity, usability, and security will resonate even if you'll never write a line of code.

Technology and Courage
Ivan Sutherland
Sun Microsystems Laboratories
1996 PDF

This is a revised transcript of a 1982 lecture by a business and technology revolutionary, and none of Dr. Sutherland's observations have eroded in the 35 years since. Whether you're leading in groundbreaking technology, meeting brisk opposition in business, or tackling a numbing computer security backlog, Sutherland's plain wisdom in subtle matters is simultaneously empowering and liberating.