Jagged Thoughts | Dr. John Linwood Griffin

Earlier this month I had the privilege of speaking at George Mason University’s cybersecurity innovation forum.  The venue was a “series of ten-minute presentations by cybersecurity experts and technology innovators from throughout the region. Presentations will be followed by a panel discussion with plenty of opportunity for discussion and discovery. The focus of the evening will be on cybersecurity innovations that address current and evolving challenges and have had a real, measurable impact.”

(How does one prepare for a 10-minute talk?  The Woodrow Wilson quote came to mind: “If I am to speak ten minutes, I need a week for preparation; if fifteen minutes, three days; if half an hour, two days; if an hour, I am ready now.”)

Given my experience with network security job training here at TCS, I decided to talk about the approach we take to prepare students for military cybersecurity missions.  It turned out to be a good choice:  The topic was well received by the audience and provided a nice complement to the other speakers’ subjects (botnet research, security governance, and security economics).

My talk had the tongue-in-cheek title The 5 P’s of cybersecurity: Preparing students for careers as cybersecurity practitioners.  I first learned of the 5 P’s from my college roommate who captained the Auburn University rowing team.  He used the 5 P’s (a reduction of the 7 P’s of the military) to motivate his team:

Poor Preparation = Piss Poor Performance

In the talk I asserted that this equation holds equally true for network security jobs as it does for rowing clubs.  A cybersecurity practitioner who is not well prepared—in particular who does not understand the “why” of things happening on their network—will perform neither effectively nor efficiently at their job.  And as with rowing, network security is often a team sport:  One ill-prepared team member will often drag down the rest of the team.

I mentioned how my colleagues at TCS (and many of our competitors and partners in the broad field of “advanced network security job training”) also believe in the equation, perhaps even moreso given that many of them are former or current practitioners themselves.  I have enjoyed working alongside instructors who are passionate about the importance of doing the best job they can.  Many subscribe to an axiom that my father originally used to describe his work as a high-school teacher:

“If my student has failed to learn, then I have failed to teach.”

After presenting this axiom I discussed several principles TCS has adopted to guide our advanced technical instruction, including:

1. Create mission-derived course material with up-to-date exercises and tools.  We hire former military computer network operators to develop our course content, in part to ensure that what we teach in the classroom matches what’s currently being used in the field.  When new tools are published, or new attacks are put in the news, our content-creators immediately start modifying our course content—not simply to replace the old content with the new, but rather to highlight trends in the attack space & to involve students in speculating on what they will encounter in the future.
2. Engage students with hands-on cyber exercises. Death by PowerPoint is useless for teaching technical skills.  Even worse for technical skills (in my opinion, not necessarily shared by TCS) is computer-based training (CBT).  Our Art of Exploitation training is effective because we mix brief instructor-led discussions with guided but open-ended hands-on exercises using real attacks and real defensive methodologies on real systems.  The only way to become a master programmer is to author a large and diverse series of software; the only way to become a master cybersecurity practitioner is to encounter scenarios, work through them, and be debriefed on your performance and what you overlooked.
3. Training makes a practitioner better, and practitioners make training better.  A critical aspect of our training program is that our instructors aren’t simply instructors who teach fixed topics.  Our staff regularly rotate between jobs where they perform the cybersecurity mission—for example, by participating in our penetration test and our malicious software analysis teams—and jobs where they train the mission using the skills they maintain on the first job.  Between our mission-relevant instructors and our training environment set up to emulate on-the-job activities, our students experience in the classroom builds to what they will experience months later on the job.

The audience turned out to be mostly non-technical but I still threw in an example of the “why”-oriented questions that I’ve encouraged our instructors to ask:

The first half of an IPv6 address is like a ZIP code.  The address simply tells other Inetrnet computers where to deliver IPv6 messages.  So the IPv6 address/ZIP code for George Mason might be 12345.

Your IPv6 address is typically based on your Internet service provider (ISP)’s address.  In this example, George Mason’s ISP’s IPv6 address is 1234.  (Continuing the example, another business in Fairfax, Virginia, served by the same ISP might have address 12341; another might have 12342; et cetera.)

However, there is a special kind of address—a provider-independent address—that is not based on the ISP.  George Mason could request the provider-independent address 99999.  Under this scheme GMU would still use the same ISP (1234), they would just use an odd-duck address (99999 instead of 12345).

Question A:  Why is provider-independent addressing good for George Mason?

Question B:  Why is provider-independent addressing hard for the Internet to support?

Overall I had a great evening in Virginia and I am thankful to the staff at George Mason for having extended an invitation to speak.

A clever meme hit the Internet this week:

“Stop asking me to change my password. I can’t keep on renaming my dog.”

If you (or the employees you support) aren’t using a password manager, clear off your calendar for the rest of the day and use the time to set one up.  It’s easy security.  Password managers make it simple to create good passwords, to change your passwords when required, to use different passwords on every site, and to avoid reusing old passwords.

The upside to using a password manager:

• You only need to remember two strong passwords.  (One to log into the computer running the password manager, and one for the password manager itself.)

The downside to using a password manager:

• All your eggs are in one basket.  (Therefore you need to pay close attention to choosing a good master password, protecting that password, and backing up your stored passwords.)

Generally speaking a password manager works as follows:

1. You provide the password manager with a master passphrase.
2. The password manager uses your master passphrase to create (or read) an encrypted file that contains your passwords and other secrets.

(For deeper details, see KeePass’s FAQ for a brief technical explanation or Dashlane’s whitepaper for a detailed technical explanation.  For example, in the KeePass FAQ the authors describe how the KeePass product derives 256-bit Advanced Encryption Standard [AES] keys from a user’s master passphrase, how salt is used to protect against dictionary attacks, and how initialization vectors are used to protect multiple encrypted files against known-plaintext attacks.  Other products likely use a similar approach to deriving and protecting keys.)

Password managers often also perform useful convenience functions for you—inserting stored passwords into your web browser automatically; generating strong passwords of any desired length; checking your usernames against hacker-released lists of pwned websites; evaluating the strength of your existing passwords; leaping tall buildings in a single bound; etc.

The root of security with password managers is in protecting your master password.  There are three main considerations to this protection:

(A) Choose a good passphrase. 

I’m intentionally using the word “passphrase” instead of “password” to highlight the need to use strong, complex, high-entropy text as your passphrase.  (Read my guidance about strong passphrases in TCS’s Better Passwords, Usable Security whitepaper.  Or if you don’t read that whitepaper, at least read this webcomic.)

Your master passphrase should be stronger than any password you’re currently using—stronger than what your bank requires, stronger than what your employer requires.  (However, it shouldn’t be onerously long—you need to memorize it, you will need to type it every day, and you will likely need to type it on mobile devices with cramped keyboards.)  I recommend a minimum of 16 characters for your master passphrase.

(Side note:  For similar reasons, another place where you should use stronger-than-elsewhere passphrases is with full-disk encryption products, such as TrueCrypt or FileVault, where you enter in a password at boot time that unlocks the disk’s encryption key.  As Microsoft’s #7 immutable law of security states, encrypted data is only as secure as its decryption key.)

(B) Don’t use your passphrase in unhygienic environments.

An interesting concept in computer security is the $5 wrench.  Attackers, like electricity, follow the path of least resistance.  If they’ve chosen you as their target, and if they aren’t able to use cryptographic hacking tools to obtain your passwords, then they’ll try other approaches—perhaps masquerading as an IT administrator and simply asking you for your password, or sending you a malicious email attachment to install a keylogger onto your computer, or hiding a pinhole spy camera in the light fixture above your desk.  So even with strong encryption you are still at risk to social engineering attacks targeting your passwords and password manager.

One way to reduce the risk of revealing your passphrase is to avoid typing it into computer systems over which you have neither control nor trust, such as systems in Internet cafes, or at airport kiosks, or at your Grandma Edna’s house.  To paraphrase public-service messages from the 1980s, when you give your passphrase to an untrusted computer you could be giving that passphrase to anyone who used that computer before you.

For situations where you simply must use a computer of dubious provenance—say, you’re on vacation, you take a wrong turn at Albuquerque, your wallet and laptop get stolen, and you have to use your password manager at an Internet cafe to get your credit card numbers and bank contact information—some password managers provide features like one time passwords, screen keyboards, multifactor authentication, and web-based access to help make lemonade out of life’s little lemons.

(C) Make regular backups of your encrypted file.

If you have a strong passphrase [(A)] and you keep your passphrase secret [(B)] then it doesn’t matter where copies of your encrypted file are stored.  The strong encryption means that your file won’t be susceptible to a brute-force or password-guessing attack even if an attacker obtains a copy of your file.  (Password management company LastPass had a possible security breach of their networks in 2011.  Even so, users with strong passphrases had “no reason to worry.”)  As such you are safely able to make backup copies of your encrypted file and to store those backups in a convenient manner.

Some password managers are designed to store your encrypted file on your local computer.  Other managers (notably LastPass) store your encrypted file on cloud servers managed by the same company, making it easier to synchronize the password file across all devices you use.  Still other managers integrate easily with third-party cloud storage providers (notably Dropbox) for synchronization across multiple devices, or support direct synchronization between two devices over a Wi-Fi network.  (In all remote-storage cases I’ve found, the file is always encrypted locally before any portion of the file is uploaded into the cloud.)

Whichever type of manager you use, be aware that that one file holds your only copy of all of your passwords—it is critical that you not lose access to the contents of the file.  Computers have crashed.  Password management companies have disappeared (Logaway launched on May 4, 2010, and ceased operations on February 2, 2012).  Cloud services havelost data and have experienced multi-day disruptions.  Protect yourself by regularly backing up your encrypted file, for example by copying it onto a USB dongle (whenever you change or add a password) or by printing a hard copy every month to stash in a safe deposit box.

If you maintain a strict separation between your home accounts and your work accounts—for example to keep your employer from snooping and obtaining your Facebook password—simply set up two password managers (one on your home laptop, the other on your work PC) using two unique passphrases as master keys.

Password manager software is easy to set up and use.  The biggest problem you’ll face is choosing from among the cornucopia of password managers.  A partial list I just compiled, in alphabetical order, includes: 1Password, AnyPassword, Aurora Password Manager, Clipperz, DataVault, Dashlane, Handy Password, Kaspersky Password Manager, KeePass, Keeper,LastPass, Norton Identity Safe, Paranotic Password Manager, Password Agent, Password Safe, Password Wallet, PINs, RoboForm, Secret Server, SplashID, Sticky Password, TK8 Safe, and Universal Password Manager.  There is even a hardware-based password manager available.

Your top-level considerations in choosing a password manager are:

1. Does it run on your particular OS or mobile device?  (Note that some password managers sometimes charge, or charge extra, to support synchronization with mobile devices.)
2. Do you already use Dropbox on all your devices?  If not, consider a manager that provides its own cloud storage (LastPass, RoboForm, etc.)  If so, and only if you would prefer to manage your own encrypted file, choose a service that supports Dropbox (1Password, KeePass, etc.)

I don’t recommend or endorse any particular password manager.  I’ve started using one of the “premium” (paid) password managers and am astonished at how much better any of the managers are over what I’d been using before (an unencrypted manual text-file-based system that I’d hacked together last millennium).

Earlier this month the (ISC)² U.S. Government Advisory Board (GAB) invited me to present my views and opinions to the board.  What a neat opportunity!

The GAB is a group of mostly federal agency Chief Information Security Officers (CISOs) or similar executives.  Officially it comprises “10-20 senior-level information security professionals in their respective region who advise (ISC)² on industry initiatives, policies, views, standards and concerns” and whose goals include offer deeper insights into the needs of the information security community and discuss matters of policy or initiatives that drive professional development.

In terms of content, in addition to discussing my previous work on storage systems with autonomous security functionality, I advanced three of my personal opinions:

1. Before industry can develop the “cybersecurity workforce of the future” it needs to figure out how to calculate the return on investment (ROI) for IT/security administration.  I suggested a small initial effort to create an anonymized central database for security attacks and the real costs of those attacks.  If such a database was widely available at nominal cost (or free) then an IT department could report on the value of their actions over the past year: “we deployed such-and-such a protection tool, which blocks against this known attack that caused over $10M in losses to a similar organization.”  Notably, my suggested approach is constructive (“here’s what we prevented”) rather thannegative (“fear, uncertainty, and doubt / FUD”).  My point is that coming at the ROI problem from a positive perspective might be what makes it work.
2. No technical staff member should be “just an instructor” or “just a developer.”  Staff hired primarily as technical instructors should (for example) be part of an operational rotation program to keep their skills and classroom examples fresh.  Likewise, developers/programmers/etc. should spend part of their time interacting with students, or developing new courseware, or working with the sales or marketing team, etc.  I brought up the 3M (15%) / Hewlett-Packard Labs (10%) / Google (20%) time model and noted that there’s no reason that a practical part-time project can’t also be revenue-generating; it just should be different (in terms of scope, experience, takeaways) from what the staff member does the rest of their time.  My point is that treating someone as “only” an engineer (developer, instructor, etc.) does a disservice not just to that person, but also to their colleagues and to their organization as a whole.
3. How will industry provide the advanced “tip-of-the-spear” training of the future?  One curiosity of mine is how to provide on-the-job advanced training.  Why should your staff be expected to learn only when they’re in the classroom?  Imagine if you could provide your financial team with regular security conundrums — “who should be on the access control list (ACL) for this document?” — that you are able to generate, monitor, and control.  Immediately after they take an action (setting the ACL) then your security system provides them with positive reinforcement or constructive criticism as appropriate.  My point is that if your non-security-expert employees regularly deal with security-relevant problems on the job, then security will no longer be exceptional to your employees.

I had a blast speaking.  The GAB is a group of great folks and they kept me on my toes for most of an hour asking questions and debating points.  It’s not every day that you get to engage high-level decision makers with your own talking points, so my hope is that I gave them some interesting viewpoints to think about — and perhaps some new ideas on which to take action inside their own agencies and/or to advise the government.

Of the many marvelous Calvin and Hobbes cartoons by Bill Watterson, one of the most marvelous (and memorable) is The Horrendous Space Kablooie.  Quoth Calvin, “That’s the whole problem with science.  You’ve got a bunch of empiricists trying to describe things of unimaginable wonder.”

I feel the same way about X.509, the name of the international standard defining public key certificates.  X.509?  It’s sort of hard to take that seriously — “X.509” feels better suited as the name of an errant asteroid or perhaps a chemical formula for hair restoration.

But I digress.  X.509 digital certificates are exchanged when you create a “secure” connection on the Internet, for example when you read your webmail using HTTPS.  The exchange happens something like this:

• Your computer:  Hi, I’m a client.
• Webmail server:  Howdy, I’m a server.  Here’s my X.509 certificate, including the public key you’ll use in the next step.
• Your computer:  Fabulous.  I’ve calculated new cryptographic information that we’ll use for this session, and I’ve encrypted it using your public key; here it is.
• (Further traffic is encrypted using the session cryptographic information.)

Several things happen behind the scenes to provide you with security:

1. Your computer authenticates the X.509 certificate(s) provided by the server.  It checks that the server uses the expected web address.  It also verifies that a trusted third party vouches for the certificate (by checking the digital signature included in the certificate).

2. Your computer verifies that there is no “man in the middle” attack in progress.  It does this by ensuring that the server has the private key associated with its certificate.  It does this by encrypting the session cryptographic information with the server’s public key.  If the server didn’t have the private key then it wouldn’t be able to encrypt and decrypt any further traffic.

Unfortunately the system isn’t perfect.  The folks who programmed your web browser included a set of trusted root certificates with the browser.  Those root certificates were issued by well-known certificate authorities [CAs] such as Verisign and RSA.  If an attacker breaches security at either a root CA or an intermediate CA, as happened with the 2011 Comodo and DigiNotar attacks, then an attacker could silently insert himself into your “secure” connection.  Yikes!  Efforts like HTTPS Everywhere and Convergence are trying to address this problem.

Public-key cryptography is pretty neat.  When you use public-key cryptography you generate two keys, a public key (okay to give out to everyone) and a private key (not okay).  You can use the keys in two separate ways:

• When someone wants to send you a private message, they can encrypt it using your public key.  The encrypted message can only be decrypted using your private key.

• When you want to publish a message, you can encrypt (sign) it using your private key.  Anyone who has your public key can decrypt (validate) your message.

In a public key infrastructure, a root CA (say, Verisign) uses its private key to sign the public-key certificates of intermediate certificate authorities (say, Thawte).  The intermediate CAs then use their private key to sign the public-key certificates of their customers (say, www.google.com).  When you visit Google’s site using HTTPS, Google provides you both their certificate and Thawte’s certificate.  (The chained relationship Verisign-Thawte-Google is sometimes called the “chain of trust”.)  Your browser uses the certificates provided by Google, plus the Verisign root certificate (bundled with the browser), to verify that the chain of trust is unbroken.

[I use Google as the example here, since you can visit https://www.google.com and configure your browser to show the certificates that Google provides.  However, I have no knowledge of Google’s contractual relationship with Thawte.  My assertions below about Google are speculative, but the overall example is valid.]

Recently I was asked “We have been trying to understand Certificate Chaining and Self Signing.  Would a company [like Google] be allowed to purchase one certificate from a Certificate issuer like Verisign and then issue its own signed additional certificates for additional use?”

Great question!  (Where “great question” is defined as “um, I don’t know, let me check into that.”)  It turns out the answer is no, a company’s certificate(s) cannot be used to sign other certificates.

Using Google as an example, the principal reason is that neither Verisign nor Thawte let Google act as an “intermediate certificate authority.”  It’s (1) likely against the license agreement under which Thawte signed Google’s certificate, and (2) prohibited by metadata fields inside both Thawte’s certificate and Google’s certificate:

• Google’s certificate is prohibited from signing other ones because of a flag inside the certificate metadata.  (Specifically, their Version 3 certificate has an Extension called Certificate Basic Constraints that has a flag Is not a Certificate Authority.)  And Google can’t modify their certificate to change this flag, because then signature validation would fail (your browser would detect that Google’s modified certificate doesn’t match the original certificate that Thawte signed).

• Certificates signed by Thawte’s certificate cannot be used as Certificate Authorities (CAs) because of a flag inside Thawte’s certificate.  (Specifically, their Version 3 certificate has an Extension called Certificate Basic Constraints that has an field Maximum number of intermediate CAs that’s set to zero, meaning that no verification program should accept any certificates that we signed using their key.)

If your company needs to issue its own signed certificates, for example to protect your internal servers, it’s relatively easy to do.  All you have to do is run a program that generates a root certificate.  You would then be like Verisign in that you could issue and sign as many other certificates as you wanted.  (The down side of your “private PKI” is that none of your users’ browsers would initially recognize your root certificate as a valid certificate.  For example, anyone surfing to a web page protected by certificates you signed would get a big warning page every time, at least until they imported your root certificate’s signature to their trusted-certificates list.)

The article I found most helpful in digging up this answer is here:
http://unitstep.net/blog/2009/03/16/using-the-basic-constraints-extension-in-x509-v3-certificates-for-intermediate-cas/

(The full name of the X.509 standard is the far worse ITU-T Recommendation X.509: Information technology – Open systems interconnection – The Directory: Public-key and attribute certificate frameworks.  One name with four hyphens, two colons, and the hyphenated equivalent of comma splicing?  Clearly rigorous scientific work.)

There have been many, many words written about the IPv4-to-IPv6 transition — probably around 340 undecillion words at this point — but perhaps my favorite words came in a recent Slashdot comment by AliasMarlowe:

I believe in the incremental approach to updates; it’s so much safer and usually easier.
So it’s going to be IPv5 for me, while you suckers make a mess of IPv6!

I’ve long been a fan of IPv6.  Deploying IPv6 has the obvious benefit of solving the IPv4 address exhaustion problem, as well as making it easier to do local subnetting, and site network architecture, and to some degree internet-scale routing.

But perhaps the greatest benefit of deploying IPv6 is the restoration of end-to-end transparency.  IPv6 obviates the need for network address translation (NAT).  With IPv6, when your Skype application wants to initiate a call to my Skype application, the apps can address each other directly without relying on hole punching, third-party relaying, or other “clever” NAT-circumvention techniques.

(End-to-end addressing may sound unimportant, but if we could restore this critical Internet design goal to practice then we could party like it’s 1979!)

I recently spoke with some of TCS’s computer network operations students about security considerations for IPv6 deployments.  They were surprised when I claimed that NAT is not needed in an IPv6 security plan; several students commented that the NAT on their home network router was the only thing protecting their computers from the evils of the Internet.

A common misperception!  There are generally two functions performed by your home network router (or your corporate upstream router, if so configured):

1. Firewalling / stateful packet inspection.  This is a security function.
2. IP masquerading / network address [and port] translation.  This is not a security function; it simply allows all the devices on your internal network to share a single external network (IP) address.

With IPv6 you can (and should) still deploy inline firewall appliances to perform function #1.  But with the plethora of available addresses in IPv6 — 18,446,744,073,709,551,616 globally routable addresses per standard local subnet — there is no overt need for masquerading.

Of course, masquerading provides ancillary benefits:  It somewhat hinders external traffic analysis, such as network mapping, by obfuscating the internal source and destination of traffic.  Combining masquerading with private IPv4 addressing also prevents internal addresses from being externally routable.

But similar benefits can be realized in IPv6 without masquerading and therefore without losing the benefits of end-to-end transparency.  For example IPv6 privacy extensions can obfuscate your internal network architecture and IPv6 unique local addresses can be used to isolate systems that shouldn’t be visible on external networks.