When someone from the National Security Agency talks, I listen. The NSA is one of the government’s most secretive agencies. It has to be, as it deals in SIGINT — generally, electronic communications. Specifically it has the dual mission of intercepting the communications of other countries while devising methods of protecting U.S. government communications from interception. And recently, someone from the NSA not only talked, but talked a lot.

Brian Snow is a Technical Director at NSA’s Directorate for Education and Training. Before that, he served as Technical Director of the Research Directorate and of the Information Assurance Directorate. While neither he nor I can discuss the specifics of what he does, I can tell you that he recently gave a presentation at the 2005 Annual Computer Security Applications Conference on the role of assurance in computer and communications security.

That presentation is now online (PDF). It’s somewhat technical, so if you don’t know the ins and outs of programming or operating system design, much of it will go right over your head. But there are a few choice cuts which anyone will be able to understand, and are critical to keep in mind when thinking about security, not only of the computer variety, but here in the physical world as well.

Security products and services should stop malice in the environment from damaging their users. Nevertheless, too often they fail in this task. . . .

First, too many of these products are still designed and developed using methodologies assuming random failure as the model of the deployment environment rather than assuming malice. There is a world of difference!

Second, users often fail to characterize the nature of the threat they need to counter. Are they subject only to a generic threat of an opponent seeking some weak system to beat on, not necessarily theirs, or are they subject to a targeted attack, where the opponent wants something specific of theirs and is willing to focus his resources on getting it?

Too frequently, the government responds to unrealistic “movie plot” threats when deciding on security measures. Or it fails to accurately assess the threat, and wastes its time and our money on pointless measures, such as the city of New York did.

Snow goes on to say that the major problem in computer security today is assurance, or rather, the lack of assurance, in commercial products.

Assurances are confidence-building activities demonstrating that

1. The system’s security policy is internally consistent and reflects the requirements of the organization,
2. There are sufficient security functions to support the security policy,
3. The system functions meet a desired set of properties and only those properties,
4. The functions are implemented correctly, and
5. The assurances hold up through the manufacturing, delivery, and life cycle of the system.

We [NSA] provide assurance through structured design processes, documentation, and testing, with greater assurance provided by more processes, documentation, and testing.

Snow criticizes the software industry for its lack of building assurance into existing products, and says that he doesn’t expect the situation to improve in the next few years.

Am I depressed about this state of affairs? Yes, I am. The scene I see is products and services sufficiently robust to counter many (but not all) of the “hacker” attacks we hear so much about today, but not adequate against the more serious but real attacks mounted by economic enemies, organized crime, nation states, and yes, terrorists.

We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.

The serious enemy knows how to hide his activities. What is the difference between a hacker and a more serious threat such as organized crime? The hacker wants a score, and bragging rights for what he has obviously defaced or entered. Organized crime wants a source, is willing to work long, hard, and quietly to get in, and once in, wants to stay invisible and continue over time to extract what it needs from your system.

Clearly, we need confidence in security products; I hope we do not need a major bank-failure or other disaster as a wake-up call before we act. (Emphasis in original)

If you’re building a product which is supposed to offer security, or you are evaluating the security of an existing product, service, or process, this is a must-read.

(Thanks again to Bruce Schneier.)