We Need Assurance! Brian Snow U. S. National Security Agency [email protected] Abstract When will we be secure? Nobody knows for sure – but it cannot happen before commercial security products and services possess not only enough functionality to satisfy customers’ stated needs, but also sufficient assurance of quality, reliability, safety, and appropriateness for use. Such assurances are lacking in most of today’s commercial security products and services. I discuss paths to better assurance in Operating Systems, Applications, and Hardware through better development environments, requirements definition, systems engineering, quality certification, and legal/regulatory constraints. I also give some examples. 1. Introduction DoD Disclaimer: The views expressed in this article are those of the author and do not necessarily reflect the opinions or policies of the Department of Defense or the U.S. Government. This is an expanded version of the “Distinguished Practitioner” address at ACSAC 2005 and therefore is less formal than most of the papers in the proceedings. I am very grateful that ACSAC chose me as a distinguished practitioner, and I am eager to talk with you about what makes products and services secure. Most of your previous distinguished practitioners have been from the open community; I am from a classified community, the U.S. National Security Agency. Nevertheless, I have worked with and admire many of the distinguished practitioners from prior conferences. I spent my first 20 years in NSA doing research developing cryptographic components and secure systems. Cryptographic systems serving the U.S. government and military spanning a range from nuclear command and control to tactical radios for the battlefield to network security devices use my algorithms. For the last 14 years, I have been a Technical Director at NSA (similar to a chief scientist or senior technical fellow in industry) serving as Technical Director for three of NSA’s major mission components: the Research Directorate, the Information Assurance Directorate, and currently the Directorate for Education and Training (NSA’s Corporate University). Throughout these years, my mantra has been, “Managers are responsible for doing things right; Technical Directors are responsible for finding the right things to do.” There are many things to which NSA pays attention in developing secure products for our National Security Customers to which developers of commercial security offerings also need to pay attention, and that is what I want to discuss with you today. 2. Setting the context The RSA Conference of 1999 opened with a choir singing a song whose message is still valid today: “Still Haven’t Found What I’m Looking For”. The reprise phrase was . . . “When will I be secure? Nobody knows for sure. But I still haven’t found what I’m looking for!” That sense of general malaise still lingers in the security industry; why is that? Security products and services should stop malice in the environment from damaging their users. Nevertheless, too often they fail in this task. I think it is for two major reasons. 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 opponentwants something specific of theirs and is willing to focus his resources on getting it? The following two simple examples might clarify this. Example 1: As a generic threat, consider a burglar roaming the neighborhood wanting to steal a VCR. First, understand his algorithm: Find empty house (dark, no lights) try door; if open, enter, if VCR – take. If the door is resistant, or no VCR is present, find another dark house. Will the burglar succeed? Yes, he will probably get a VCR in the neighborhood. Will he get yours? What does it take to stop him? Leave your lights on when you go out (9 cents a kilowatt-hour) and lock your door. That is probably good enough to stop the typical generic burglar. Example 2: As a targeted threat, assume you have a painting by Picasso worth $250,000 hanging above your fireplace, and an Art thief knows you have it and he wants it. What is his algorithm? He watches your house until he sees the whole family leave. He does not care if the lights are on or not. He approaches the house and tries the door; if open, he enters. If locked, he kicks it in. If the door resists, he goes to a window. If no electronic tape, he breaks the glass and enters. If electronic tape is present, he goes to the siding on the house, rips some off, then tears out the fiberboard backing, removes the fiberglass insulation, breaks though the interior gypsum board, steps between the studs, and finally takes the painting and leaves. It takes more effort to counter a targeted threat. In this case, typically a burglar alarm system with active polling and interior motion sensors as a minimum (brick construction would not hurt either). With luck, this should be enough to deter him. If not, at least there should be increased odds of recovery due to hot pursuit once the alarms go off. There is no such thing as perfect security; you need to know how much is enough to counter the threat you face, and this changes over time. 3. What do we need? NSA has a proud tradition during the past 53 years of providing cryptographic hardware, embedded systems, and other security products to our customers. Up to a few years ago, we were a sole-source provider. In recent years, there has come to be a commercial security industry that is attractive to our customers. NSA also strives to use Commercial-Off-the-Shelf (COTS)