I wrote a post for Dave Farber’s IP list on the use of lie detectors by the government.  My basic point was that some uses of imperfect technology are ok, if we understand the kind of risks and errors we are encountering.  I continue to see people without an understanding of the difference between Type I and Type II errors, and the faulty judgements made as a result.

What follows is a (slightly edited) version of that post:

The following is a general discussion.  I am in no sense an expert on lie detectors, but this is how it was explained to me by some who are very familiar with the issue.

Lie detectors have a non-zero rate of error.  As with many real-world systems, these errors manifest as Type I errors (alpha error, false positive) and Type II errors (beta error, false negative), and instances of “can’t tell.”  It’s important to understand the distinction because the errors and ambiguities in any system may not be equally likely, and the consequences may be very different.  An example I give to my students is after going over a proof that writing a computer virus checker that accurately detects all computer viruses is equivalent to solving the halting problem.  I then tell them that I can provide them with code that identifies every program infected with a computer virus in constant running time.  They think this is a contradiction of the proof.  I then write on the board the equivalent of “Begin; print “Infected!”; End.” —identify every program as infected.  There are no Type II errors.  However, there are many Type I errors, and thus this is not a useful program.  But I digress (slightly)...

I have been told that lie detectors more frequently exhibit Type I errors because subjects may be nervous or have a medical condition, and that Type II errors generally result from training or drugs (or both) by the subject, although some psychological disorders allow psychopaths to lie undetectably.  Asking foil questions (asking the subject to lie, and asking a surprise question to get a reaction) helps to identify individuals with potential for Type II errors.  Proper administration (e.g., reviewing the questions with the subject prior to the exam, and revising them as necessary to prevent ambiguity), helps to minimize Type I errors.  [Example.  When granting a security clearance, you want to weed out people who might be more likely to commit major crimes, or who have committed them already and not yet been discovered (they may be more prone to blackmail, or future offenses).  Thus, you might ask “Have you committed any crimes you haven’t disclosed on your application?”  Someone very literal-minded might think back to speeding down the Interstate this morning, lying to buy beers at age 20, and so on, and thus trigger a reaction.  Instead, the examiner should explain before the exam that the question is meant to expose felonies, and not traffic violations and misdemeanors.]  “Can’t tell” situations are resolved by giving the exam again at a later time, or by reporting the results as ambiguous.

In a criminal investigation, any error can be a problem if the results are used as evidence.***  For instance, if I ask “Did you commit the robbery?” and there is a Type I error, I would erroneously conclude you were guilty.  Our legal system does not allow this kind of measurement as evidence, although the police may use a negative result to clear you of suspicion.  (This is not generally a good step to take in some crimes, because some psychopaths are able to lie so as to generate Type II errors.)  If I asked “Are you going to hijack this plane?” then you might be afraid of the consequences of a false reading, or have a fear of flying, and there would be a high Type I error rate.  Thus, this probably won’t be a good mechanisms to screen passengers, either.  (However, current TSA practice in other areas is to have lots of Type I errors in hopes of pushing Type II to zero.  Example is not letting *any* liquids or gels on planes, even if harmless, so as to keep any liquid explosives from getting on board.)

When the US government uses lie detectors in security clearances, they aren’t seeking to identify EXACTLY which individuals are likely to be a problem.  Instead, they are trying to reduce the likelihood that people with clearances will pose a risk and it is judged as acceptable to have some Type I errors in the process of minimizing Type II errors.  So, as with many aspects of the adjudication process, they simply fail to grant a clearance to people who score too highly in some aspect of the test—include a lie detector test.  They may also deny clearances to people who have had too many close contacts with foreign nationals, or who have a bad history of going into debt, or any of several other factors based on prior experience and analysis.  Does that mean that those people are traitors?  No, and the system is set to not draw that specific conclusion.  If you fail a lie detector test for a clearance, you aren’t arrested for treason! *  The same if your evaluation score on the background investigation rates too high for lifestyle issues.  What it DOES mean is that there are heightened indications of risk, and unless you are “special” for a particular reason,**  the government chooses to not issue a clearance so as to reduce the risk.  Undoubtedly, there are some highly qualified, talented individuals who are therefore not given clearances.  However, they aren’t charged with anything or deprived of fundamental rights or liberties.  Instead, they are simply not extended a special classification.  The end result is that people who pass through the process to the end are less likely to be security risks than an equal sample drawn from the regular population.

The same screening logic is used in other places.  For instance, consider blood donation.  One of the questions that will keep a donation from being used in transfusions is if the donor is a male and indicates that he has had sex with another male since (I think) 1980.  Does that mean that everyone in that category has hepatitis or HIV?  No!  It only means that those individuals, as a class, are at higher risk, and they are a small enough subset that it is worth excluding them from the donor pool to make the donations safer in aggregate.  Other examples include insurance premiums (whether to grant insurance to high risk individuals), and even personal decisions (“I won’t date women with multiple facial piercings and more than 2 cats—too crazy.”)  These are general exclusions that almost certainly include some Type I errors, but the end result is (in aggregate) less risk.

Back to lie detectors.  There are two cases other than initial screening that are of some concern.  The first is on periodic rechecks (standard procedure), and when instituting new screening on existing employees, as was done at some of the national labs a few years ago.  In the case of periodic rechecks, the assumption is that the subject passed the exam before, and a positive reading now is either an indication that something has happened, or is a false positive.  Examiners often err on the side of the false positive in this case rather than triggering a more in-depth exam;  Aldrich Ames was one such case (unfortunately), and he wasn’t identified until more damage was done.  If one has a clearance and goes back for a re-exam and “flunks” it, that person is often given multiple opportunities to retake it.  A continued inability to pass the exam should trigger a more in-depth investigation, and may result in a reassignment or a reduction in access until a further determination is made.  In some cases (which I have been told are rare) someone’s clearance may be downgraded or revoked.  However, even in those cases, no statement of guilt is made—it is simply the case that a privilege is revoked.  That may be traumatic to the individual subject, certainly, but so long as it is rare it is sound risk management in aggregate for the government.

The second case, that of screening people for the first time after they have had access already and are “trusted” in place, is similar in nature except it may be viewed as unduly stressful or insulting by the subjects—as was the case when national lab employees were required to pass a polygraph for the first time, even though some had had DoE clearances for decades.  I have no idea how this set of exams went.

Notes to the above

*—Although people flunking the test may not be charged with treason, they may be charged with falsifying data on the security questionnaire!  I was told of one case where someone applying for a cleared position had a history of drug use that he thought would disqualify him, so he entered false information on his clearance application.  When he learned of the lie detector test, he panicked and convinced his brother to go take the test for him.  The first question was “Are you Mr. X?” and the stand-in blew the pens off the charts.  Both individuals were charged and pled guilty to some kind of charges; neither will ever get a security clearance!

**—Difficult and special cases are when someone, by reason of office or designation, is required to be cleared.  So, for instance, you are nominated to be the next Secretary of Defense, but you can’t pass the polygraph as part of the standard clearance process.  This goes through a special investigation and adjudication process that was not explained to me, and I don’t know how this is handled.

***—In most Western world legal systems.  In some countries, fail the polygraph and get a bullet to the head.  The population is interchangeable, so no need to get hung up on quibbles over individual rights and error rates.  Sociopaths who can lie and get away with it (Type II errors) tend to rise to the top of the political structures in these countries, so think of it as evolution in action….

So, bottom line:  yes, lie detector tests generate errors, but the process can be managed to reduce the errors and serve as a risk reduction tool when used in concert with other processes.  That’s how it is used by the government.

I recently did an interview with Network World magazine.  The topics discussed might well be of interest to readers of this blog.
[tags]network security,risk management,diversity,security trends[/tags]

[posted with ecto]

This is a great blog posting: Security Absurdity: The Complete, Unquestionable, And Total Failure of Information Security.  The data and links are comprehensive, and the message is right on.  There is a tone of rant to the message, but it is justified.

I was thinking of writing something like this, but Noam has done it first, and maybe more completely in some areas than I would have.  I probably would have also said something about the terrible state of Federal support for infosec research, however, and also mentioned the PITAC report on cyber security.

[posted with ecto]

[tags]passwords, human factors, general security[/tags]
Today, I found a pointer to this short news story: Password Security is Her Game.  Here’s a quote from that story:

Many users have half a dozen passwords to remember. That’s why the most common password is “password.” The usual solution is to write it down. But how secure is that? Practicality wins. The probability of remembering six passwords is not that great. Half the people who say they never write down their passwords need to have their passwords reset because of forgetting.

I wasn’t going to post anything else on passwords so soon, but this seemed particularly pertinent.  Plus, the researcher is a Purdue alumna.

When I posted earlier about passwords and best practices, I had no idea it would elicit such a response!  So, now that my class’s final exams and papers are graded, I will return to the topic and attempt to address some of the points raised in comments—or, at least those comments that were related to the original blog entry.
[tags] best practices, passwords, awareness, general security[/tags]

Best Practices
It was certainly not my intent to disparage all best practices.  I was merely observing that sometimes best practices are viewed as a panacea.  It is important for people to understand the origins of the best practices they espouse, and whether they are indeed “best”!  Sometimes, excellent practices are adopted outside their realm of proper application, or are used too long without proper (re)evaluation of the underlying conditions.  “Best practices” are designed for the average case, but are not meant to be blindly applied in every case—reason should be applied to the situation, but isn’t.  And all too often, folklore and superstition are accepted as “best practice”  because they “seem” correct, or coincidentally produce desired results.

Consider an example of the first of these (understanding the realm of application): showing an ID to get inside a closed facility, proving that you are a current employee of the company or agency.  That is excellent security practice…until you move it to the lobby of every office building!.  At that point, too many guards aren’t really checking the cards to see if someone is really who they claim to be.  Instead of watching for suspicious behavior, many guards now simply look for a laminated card with a picture on it, and something that looks like an official seal.  Security in many places has degraded by accepting what “best practice” is without understanding where it is really best.

The second case (blind application without reasoning) is illustrated by many of the things that TSA does in airline passenger screening.  One example, told to me by a Federal law enforcement agent, is when he showed his badge and papers while passing though security.  They didn’t make him take out his weapon when going through the metal detector…but then they insisted that he run his shoes through the X-ray machine!  They had rules that allowed them to let a law enforcement agent with a semiautomatic handgun through the checkpoint, but they couldn’t appropriately reason about why they had a rule about screening shoes and apply it to this case!  (Of course, several aspects of TSA screening are poorly considered, but that may be a topic for a later post.)

The third case—folklore and superstition accepted as best practice—is rampant in information security, and I intend to say more about this in later postings.

My post about password security was based on the fact that the “change passwords once a month” rule is based on very old practice, and doesn’t really help now in many real-world environments.  In fact, it may result in weaker security in many cases, as users try to find a way around the rules.  At the least, the average user will have the impression reinforced that “Those security guys are idiots and their goal seems to be to make my life more difficult.”  That doesn’t help build a cooperative working environment where the user population is part of the security infrasrtructure!

Risk Assessment
Donn Parker was one of the first people to argue persuasively that traditional risk assessment would not work in modern IT, and that sound design and best practice would have to do.  I greatly respect Donn’s long experience and opinions, but I don’t completely agree.  In many cases it is possible, using recent experience and expert knowledge, to appropriately estimate risk and loss to quartiles or deciles.  Although imperfect, it can help in making choices and understanding priorities.  When there is insufficient experience and knowledge, I agree with Donn that relying on sound practice is the next best thing; of course, sound design should be used at all times!

Some readers commented that they didn’t have the money to do a risk evaluation. Resolving a question such as password change frequency does not require a full-blown audit and risk analysis.  But, as with my previous comment, if you don’t have the resources, experience or knowledge, then pick sound practice—but put in some effort to understand what is sound!

Password Vaults
A number of responses (including several private responses) were directed to the growing number of passwords, PINs, serial numbers and employee IDs we are expected to remember.  Good security practice suggests that authenticators used in different realms of privilege be unique and uncorrelated.  Good privacy practice suggests that we develop independent identifiers for different uses to prevent correlation.  The two combined result in too many things to remember for those of us whose brains are full (to indirectly pay homage to an old Larson cartoon), and especially for the average person who is overly-taxed when remembering anything beyond who was voted off of American Idol this week.  Now, add frequent requirements to change some of those values, and the situation becomes well-nigh impossible.

Several readers mentioned password vault programs that they use, either on PDAs or the WWW.  I was asked my opinion of some of these.

I use several password vaults myself.  They have 4 characteristics that I believe are important:

1. The programs use published, strong ciphers to encrypt the contents. (e.g., AES). I don’t need to worry about some random person getting the encrypted database and then decrypting all my keys.
2. The programs are cross-platform so that I can use the same program on my PDA, my laptop, and my home system.  This keeps me from creating keys and passwords then forgetting them because I don’t have the vault program at hand.
3. The different versions of the program sync with each other, and allow the database to be backed up.  If I lose my PDA, I’m not completely locked out of everything—I can do a restore, unencrypt, and carry on as before.
4. I don’t store the database and the encryption routines on someone else’s machine.  That way, I don’t have to worry about the owner of a remote site altering the encryption routines, or making a surreptitious copy of my keys.  It is still possible for someone to intercept my interaction with the program on my local machine, but I have other mechanisms in place to monitor and verify those.

Needless to say, I don’t use a web-based password vault service, nor would I necessarily recommend it to anyone who has sensitive passwords.

One other thing—I escrow some of my passwords.  No, I’m not talking about the ill-fated government key escrow scheme that gave the idea a bad name.  I am referring to self-escrow.  Some of my important passwords at work, which would need to be recovered by the staff if I were to be abducted (again ) by a UFO crew, have been encrypted and escrowed in a safe place that can be accessed in an emergency.  As more things get locked up with extreme encryption, it is all the more critical that we each consider self-escrow.

So, What’s the Frequency, Kenneth?
How often should passwords be changed?  Many of you asked that, and many of you volunteered your own experience, ranging from monthly to “hardly ever.”  These times were backed up with anecdotes.  Of course, this simply serves to reinforce my comment that the time period should be based on risk assessment of your particular, including access to the system, strength of mechanism, usage, sensitivity of protected information, security of the underlying system, and sophistication of the users…to name a few factors.

Basically, I would suggest you start with an assumption that passwords should be changed every quarter.  If the passwords are used over a lightly protected communications link, then change them more often.  If someone could break the password and use the account without being noticed, then further accelerate the change interval.  If users get guidance on strong password selection, and are motivated to help ensure good security, then maybe you can extend the time period.  In many cases, without due care, you realize that any reuse of passwords is risky.  Instead of dismissing that and imposing monthly password changes, use that knowledge to address the underlying problems.

Several of you mentioned the problem of people sharing passwords and only finding out about it after a mandatory password change.  If that’s the case, you have deeper problems than stale passwords!

I continue to advocate use of a one-time password token for highly sensitive or at-risk resources.  Otherwise, use your judgement and professional evaluation of the risks and benefits of change frequencies.

[posted with ecto]

(This is an updated version of a contribution I made to the Educause security mailing list last week.)

In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration.  Some of these get included in policies, and thus may get propagated to environments they were not meant to address.  It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change.  The result is a stale policy that may no longer be effective…or possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.

From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place.  Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses.  “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

Consider the underlying role of passwords: authentication.  Good authentication is intended to support access control, accountability and (in some cases) accounting.  Passwords provide a cost-effective and user-familiar form of authentication.  However, they have a number of failure modes depending on where they are used and the threats arrayed against them.  Failure modes include disclosure, inference, exposure, loss, guessing, cracking, and snooping.  In the most general case, passwords (such as the security numbers on credit cards, or mother’s maiden name) are not sufficiently secret and are simply too weak to use as strong authenticators.  I’ll skip this case, although it is far too pervasive to actually ignore.

Disclosure is a systemic threat on the platforms involved, as well as in the operational methods used to generate and transmit the passwords.  This cannot be addressed through changing the password.  Instead, the methods used to generate and distribute passwords needs to be examined to ensure that the passwords are not disclosed to the wrong parties.  Most operating systems are currently designed so that passwords are not stored “in the clear” and this reduces the chance of disclosure.  Unfortunately, some 3rd-party applications (including web-based systems) fail to adequately guard the passwords as they are entered, stored, or compared, resulting in potential disclosure.

Another form of disclosure is when the holder of the password discloses the password on purpose.  This is an education and enforcement issue.  (Anecdote:  at one location where a new policy was announced that passwords must be changed every month, a senior administrator was heard to moan “Do you know how much time I’m going to waste each month ensuring that everyone on my staff knows my new password?”)

Inference occurs when there is a pattern to the way the passwords are generated/chosen and thus can be inferred.  For instance, knowing that someone uses the same password with a different last character for each machine allows passwords to be inferred, especially if coupled with disclosure of one.  Another example is where generated passwords are employed and the generation algorithm is predictable.

Exposure is the case where accident or unintended behavior results in a sporadic release of a password.  As an example, think of someone accidentally typing her password as the user name in login, and it is captured in the audit trail.  Another example is when someone accidentally types his password during a demonstration and it is exposed on a projection screen to a class.

Loss is when someone forgets his or her password, or (otherwise) loses whatever is used to remind/recreate the password.  This introduces overhead to recover the password, and may induce the user to keep extra reminders/copies of the password around—leading to greater exposure—or to use more memorable passwords—leading to more effective guessing attacks.  It is also the case that frequent loss opens up opportunities for eavesdropping and social engineering attacks on the reset system as it becomes more frequently used: safeguards on reset may be relaxed because they introduce too much delay on a system under load.

Guessing is self-explanatory.  Guessing is limited to choices that can be guessed.  After a certain limited number of choices, the guessing can only transform into a cracking attempt.

Cracking is when an intermediate form of the password (e.g., an encrypted form stored in the authentication database) is captured and attacked algorithmically, or where iterated attempts are made to generate the password algorithmically.  The efficacy of this approach is determined by the strength of the obfuscation used (e.g., encryption), the checks on bad attempts, and the power and scope of the resources brought to bear (e.g., parallel computing, multi-lingual databases).

Snooping (eavesdropping) is when someone intercepts a communication employing the password, either in cleartext or in some intermediate form.  The password is then extracted.  Network sniffing and keyloggers are both forms of snooping.  Various technical measures, such as network encryption, can help reduce the threat.

Now, looking back over those, periodic password changing really only reduces the threats posed by guessing, and by weak cracking attempts.  If any of the other attack methods succeed, the password needs to be changed immediately to be protected—a periodic change is likely to be too late to effectively protect the target system.  Furthermore, the other attacks are not really blunted by periodic password changes.  Guessing can be countered by enforcing good password selection, but this then increases the likelihood of loss by users forgetting the passwords.  The only remaining threat is that periodic changes can negate cracking attempts, on average.  However, that assumes that the passwords choices are appropriately random, the algorithms used to obfuscate them (e.g., encryption) are appropriately strong, and that the attackers do not have adequate computing/algorithmic resources to break the passwords during the period of use.  This is not a sound assumption given the availability of large-scale bot nets, vector computers, grid computing, and so on—at least over any reasonable period of time.

In summary, forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat—unless the password is immediately changed after each use.  This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost “password.”

So where did the “change passwords once a month” dictum come from?  Back in the days when people were using mainframes without networking, the biggest uncontrolled authentication concern was cracking.  Resources, however, were limited.  As best as I can find, some DoD contractors did some back-of-the-envelope calculation about how long it would take to run through all the possible passwords using their mainframe, and the result was several months.  So, they (somewhat reasonably) set a password change period of 1 month as a means to defeat systematic cracking attempts.  This was then enshrined in policy, which got published, and largely accepted by others over the years.  As time went on, auditors began to look for this and ended up building it into their “best practice” that they expected.  It also got written into several lists of security recommendations.

This is DESPITE the fact that any reasonable analysis shows that a monthly password change has little or no end impact on improving security!    It is a “best practice” based on experience 30 years ago with non-networked mainframes in a DoD environment—hardly a match for today’s systems, especially in academia!

The best approach is to determine where the threats are, and choose defenses accordingly.  Most important is to realize that all systems are not the same!  Some systems with very sensitive data should probably be protected with two-factor authentication: tokens and/or biometrics.  Other systems/accounts, with low value, can still be protected by plain passwords with a flexible period for change.  Of course, that assumes that the OS is strong enough to protect against overall compromise once a low-privilege account is compromised….not always a good bet in today’s operating environment!

And, btw, I’ve got some accounts where I’ve used the same password for several years with nary an incident.  But in the spirit of good practice, that’s all I’m going to say about the passwords, the accounts, or how I know they are still safe.

One of my favorite Dilbert cartoons (from 9/10/05) ends with the pointy-haired boss saying “...and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises.”  Sound familiar to anyone?

[A follow-up post is available.]