<DOC> [108th Congress House Hearings] [From the U.S. Government Printing Office via GPO Access] [DOCID: f:92771.wais] EXPLORING COMMON CRITERIA: CAN IT ASSURE THAT THE FEDERAL GOVERNMENT GETS NEEDED SECURITY IN SOFTWARE? ======================================================================= HEARING before the SUBCOMMITTEE ON TECHNOLOGY, INFORMATION POLICY, INTERGOVERNMENTAL RELATIONS AND THE CENSUS of the COMMITTEE ON GOVERNMENT REFORM HOUSE OF REPRESENTATIVES ONE HUNDRED EIGHTH CONGRESS FIRST SESSION __________ SEPTEMBER 17, 2003 __________ Serial No. 108-126 __________ Printed for the use of the Committee on Government Reform Available via the World Wide Web: http://www.gpo.gov/congress/house http://www.house.gov/reform ______ 92-771 U.S. GOVERNMENT PRINTING OFFICE WASHINGTON : 2003 ____________________________________________________________________________ For Sale by the Superintendent of Documents, U.S. Government Printing Office Internet: bookstore.gpo.gov Phone: toll free (866) 512-1800; (202) 512ÿ091800 Fax: (202) 512ÿ092250 Mail: Stop SSOP, Washington, DC 20402ÿ090001 COMMITTEE ON GOVERNMENT REFORM TOM DAVIS, Virginia, Chairman DAN BURTON, Indiana HENRY A. WAXMAN, California CHRISTOPHER SHAYS, Connecticut TOM LANTOS, California ILEANA ROS-LEHTINEN, Florida MAJOR R. OWENS, New York JOHN M. McHUGH, New York EDOLPHUS TOWNS, New York JOHN L. MICA, Florida PAUL E. KANJORSKI, Pennsylvania MARK E. SOUDER, Indiana CAROLYN B. MALONEY, New York STEVEN C. LaTOURETTE, Ohio ELIJAH E. CUMMINGS, Maryland DOUG OSE, California DENNIS J. KUCINICH, Ohio RON LEWIS, Kentucky DANNY K. DAVIS, Illinois JO ANN DAVIS, Virginia JOHN F. TIERNEY, Massachusetts TODD RUSSELL PLATTS, Pennsylvania WM. LACY CLAY, Missouri CHRIS CANNON, Utah DIANE E. WATSON, California ADAM H. PUTNAM, Florida STEPHEN F. LYNCH, Massachusetts EDWARD L. SCHROCK, Virginia CHRIS VAN HOLLEN, Maryland JOHN J. DUNCAN, Jr., Tennessee LINDA T. SANCHEZ, California JOHN SULLIVAN, Oklahoma C.A. ``DUTCH'' RUPPERSBERGER, NATHAN DEAL, Georgia Maryland CANDICE S. MILLER, Michigan ELEANOR HOLMES NORTON, District of TIM MURPHY, Pennsylvania Columbia MICHAEL R. TURNER, Ohio JIM COOPER, Tennessee JOHN R. CARTER, Texas CHRIS BELL, Texas WILLIAM J. JANKLOW, South Dakota ------ MARSHA BLACKBURN, Tennessee BERNARD SANDERS, Vermont (Independent) Peter Sirh, Staff Director Melissa Wojciak, Deputy Staff Director Rob Borden, Parliamentarian Teresa Austin, Chief Clerk Philip M. Schiliro, Minority Staff Director Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census ADAM H. PUTNAM, Florida, Chairman CANDICE S. MILLER, Michigan WM. LACY CLAY, Missouri DOUG OSE, California DIANE E. WATSON, California TIM MURPHY, Pennsylvania STEPHEN F. LYNCH, Massachusetts MICHAEL R. TURNER, Ohio Ex Officio TOM DAVIS, Virginia HENRY A. WAXMAN, California Bob Dix, Staff Director Chip Walker, Professional Staff Member Ursula Wojciechowski, Clerk David McMillen, Minority Professional Staff Member C O N T E N T S ---------- Page Hearing held on September 17, 2003............................... 1 Statement of: Davidson, Mary Ann, chief security officer, Server Technology Platforms, Oracle.......................................... 73 Fleming, Michael G., Chief, Information Assurance Solutions, Information Assurance Directorate, National Security Agency 21 Gorrie, Robert G., Deputy Director, Defensewide Information Assurance Program Office, Office of the Assistant Secretary of Defense for Networks and Information Integration, and DOD Chief Information Officer.............................. 43 Klaus, Christopher W., chief technology officer, Internet Security Systems, Inc...................................... 83 Roback, Edward, Chief, Computer Security Division, National Institute of Standards and Technology, U.S. Department of Commerce................................................... 7 Spafford, Eugene H., professor and director, Center for Education and Research in Information Assurance and Security, Purdue University................................ 88 Thompson, J. David, director, Security Evaluation Laboratory, Cygnacom Solutions......................................... 66 Letters, statements, etc., submitted for the record by: Clay, Hon. Wm. Lacy, a Representative in Congress from the State of Missouri, prepared statement of................... 56 Davidson, Mary Ann, chief security officer, Server Technology Platforms, Oracle, prepared statement of................... 76 Fleming, Michael G., Chief, Information Assurance Solutions, Information Assurance Directorate, National Security Agency, prepared statement of.............................. 23 Gorrie, Robert G., Deputy Director, Defensewide Information Assurance Program Office, Office of the Assistant Secretary of Defense for Networks and Information Integration, and DOD Chief Information Officer, prepared statement of....... 46 Klaus, Christopher W., chief technology officer, Internet Security Systems, Inc., prepared statement of.............. 85 Putnam, Hon. Adam H., a Representative in Congress from the State of Florida, prepared statement of.................... 4 Roback, Edward, Chief, Computer Security Division, National Institute of Standards and Technology, U.S. Department of Commerce, prepared statement of............................ 10 Spafford, Eugene H., professor and director, Center for Education and Research in Information Assurance and Security, Purdue University, prepared statement of......... 90 Thompson, J. David, director, Security Evaluation Laboratory, Cygnacom Solutions, prepared statement of.................. 69 EXPLORING COMMON CRITERIA: CAN IT ASSURE THAT THE FEDERAL GOVERNMENT GETS NEEDED SECURITY IN SOFTWARE? ---------- WEDNESDAY, SEPTEMBER 17, 2003 House of Representatives, Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census, Committee on Government Reform, Washington, DC. The subcommittee met, pursuant to notice, at 10:10 a.m., in room 2154, Rayburn House Office Building, Hon. Adam Putnam (chairman of the subcommittee) presiding. Present: Representatives Putnam, Clay and Watson. Staff present: Bob Dix, staff director; John Hambel, senior counsel; Chip Walker, professional staff; Ursula Wojciechowski, clerk; Suzanne Lightman, fellow; Erik Glavich, legislative assistant; Ryan Hornbeck, intern; David McMillen, minority professional staff member; and Jean Gosa, minority chief clerk. Mr. Putnam. The Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census will come to order. Good morning, and I apologize for running a few minutes late. I have 20 high school students in Washington for a week for a congressional classroom program to become familiar with the city and our government and how everything works. None of us were figuring on Hurricane Isabel, so we are trying to figure out a way to get 20 airline tickets in very short order, and it's not going to be terribly easy. Welcome to another important hearing on cybersecurity. Today the subcommittee continues its aggressive oversight and examination of the information security issues most important to our Nation. As many of you know, Secretary Ridge announced the creation of the U.S. Computer Emergency Response Team [U.S.-CERT] in conjunction with Carnegie Mellon University. This is an important step in the progress that needs to be made by our government in protecting the Nation's computers from cyber attack. It's no longer a question of if our computer networks will be attacked, but rather when, how often and to what degree. Experts from the government and the private sector who have come before this subcommittee are very concerned that the United States is not adequately prepared to ward off a serious cyber attack that could cause severe economic devastation as well as contribute potentially to the loss of life. Blaster and SoBigF are stark examples of how worm and virus vulnerabilities can cost us billions of dollars in lost productivity and administrative costs in a very short period of time. From the home user to the private enterprise to the Federal Government, we all need to take the cyber threat more seriously and move expeditiously to secure our Nation's computers. I look forward to continuing to work with the Department of Homeland Security and other key Federal agencies in this national security endeavor. Today's hearing will examine the Common Criteria and whether or not a similar certification should be applied to all government software purchasers. For years countries around the globe have wrestled with the inability to have a commonly recognized method for evaluating security software. Out of this climate, the Common Criteria evolved and represents standards that are broadly useful within the international community. The international members of the Common Criteria share the following objectives: to ensure that evaluations of information technology products and protection profiles are performed to high and consistent standards, and are seen to contribute significantly to confidence in the security of those products; to improve the availability of evaluated, security-enhanced IT products; to eliminate the burden of duplicating evaluations; and to continuously improve the efficiency and cost- effectiveness of the evaluation and certification/validation process. The Common Criteria are maintained by an international coalition and is designed to be useful within the widely diverse international community. Currently the recognition arrangement has 15 member countries. The National Security Agency and NIST represent the United States. Each member country accepts certificates issued by the members, making the Common Criteria a global standard. The criteria are technology- neutral and are designed to be applied to a wide variety of technologies and levels of security. The criteria work by providing standardized language and definitions of IT security components. That standardization allows the consumer, in our case the Department of Defense, to create a customized set of requirements for the security of a product, or protection profile. This profile would include the level of security assurance that the customer desires, including the various mechanisms that must be present for achieving that assurance. Alternatively the criteria allows the producer of the technology to develop their own set of targets called a security target. An independent lab overseen by the participating agencies, in the United States' case NIST and NSA, then test the product against either the profile or the target and certifies that it can satisfy the requirements. Currently the Department of Defense requires Common Criteria certification for all security-related software purchases. NSA requires Common Criteria certification for all purchases for systems classified as national intelligence. One of the more useful aspects of the Common Criteria is its ability to allow the purchaser of security software to compare apples to apples. The protection profile which is cast in the language of the Common Criteria provides a view of security features independent of vendor claims. It allows the purchaser to find out with certainty the security features in a product and to compare that product with other similar ones to determine which ones to purchase. The certification process, conducted by independent labs overseen by NIST in the United States, concentrates on analyzing the documentation provided by the vendor testing the product, documenting the result and reporting it out to its oversight agency. That agency then reviews the validation report and issues certification. The process is paid for by the vendor and can be both expensive and time-consuming. Estimates for operating systems can be anywhere from 1 to 5 years and costs in the millions of dollars. The expense and time commitment of the process has given rise to some questioning about the usefulness of the process. For example, the adoption of the Common Criteria could shut small vendors out of the acquisition process because they might not have the resources to go through certification. Another potential problem is the timing. Because certification takes a significant amount of time, the government might not get the most cutting-edge technology available. Conversely, the government does need to gain assurance that security features in products exist and function as advertised. This is the larger question that we are faced with: How can we--governmentwide--get the most secure products available in a timely and cost-efficient manner and at the same time have IT companies compete on a level playing field in a competitive market that rewards rather than stifles innovation? I look forward to the expert testimony we have assembled today, and I thank the witnesses for their participation. As with all of our hearings, today's hearing can be viewed live via WebCast by going to reform.house.gov. We will hold off on the other opening statements until the Members arrive, and I would ask that all of our witnesses comply with the light and the timing. Your written statement will be submitted for the record and will be included in its entirety, but we ask that you summarize your verbal comments to 5 minutes. [The prepared statement of Hon. Adam H. Putnam follows:] [GRAPHIC] [TIFF OMITTED] T2771.001 [GRAPHIC] [TIFF OMITTED] T2771.002 [GRAPHIC] [TIFF OMITTED] T2771.003 Mr. Putnam. With that, as is the custom of this subcommittee, we will swear in the witnesses. I will ask our first panel rise and raise your right hands. [Witnesses sworn.] Mr. Putnam. Note for the record all of the witnesses responded in the affirmative. And we will move right to our distinguished panel. Our first witness is Edward Roback. Mr. Roback serves as the Chief of the Computer Security Division at the National Institute of Standards and Technology supporting the agency's responsibility's to protect sensitive Federal information and promote security and commercial information technology products. As Chief, he leads the implementation of NIST responsibilities under FISMA and Cybersecurity Research and Development Act. Mr. Roback heads NIST's participation on the NIST-NSA Technical Working Group and serves on the Committee of National Security Systems. He has chaired the Federal Agency Computer Security Programs Managers Forum and co-authored An Introduction to Computer Security, The NIST handbook. He has also recently authored NIST's Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products. For those of who you would like a copy, they will be available at Barnes and Noble afterwards, and he will be happy to autograph them for you. Mr. Roback, you are recognized for 5 minutes. Welcome to the subcommittee. STATEMENT OF EDWARD ROBACK, CHIEF, COMPUTER SECURITY DIVISION, NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY, U.S. DEPARTMENT OF COMMERCE Mr. Roback. Thank you, Chairman Putnam. Thank you for the opportunity to testify today. In response to your invitation, I first would like to discuss what security assurance is and the role it plays in overall cybersecurity. I then would like to turn to the role that security testing and particularly the Common Criteria and the NIST-NSA-NIAP program play. I would like to leave you with some ideas as to what else the research community can do to improve the trust and confidence that we must have in the proper, correct and secure functioning of information systems. So let me start. What is security assurance? If we look at assurance broadly, it's the basis we need for overall trust and confidence in the correct and secure information systems. The overall question of assurance tries to address two questions: Does the system do what it is supposed to do, and does it not do the unintended? Within that context, security assurance, simply put, is the degree of confidence one has that the security mechanisms of a system is intended. It is not an absolute guarantee that security is achieved. How do we get security assurance? There is no single way. One can get some degree by looking at how a system is built, the past use of a system, manufacturers' warranties or lack thereof, and, of course, independent testing and evaluation. This testing can vary from the straightforward and repeatable through the more complex and time-consuming. When we have a standard specification that is very precise, such as with an encryption algorithm, testing is straightforward, although not necessarily easy. When a specification is exact, the test can be correspondingly precise. On the other hand, when we look at more complex and diverse IT products which lack common standards specification at the bits and bytes level, we're often confronted with products containing millions of lines of code for which a standard spec does not exist, and testing is not just straightforward. Testing such products necessarily involves human subjectivity. NIST refers to such testing as evaluation. NIAP is such a testing program. Turning to the NIAP and the CC, in my written statement I have provided a summary of the development of each, the Mutual Recognition Arrangement and some of the uses of the criteria both domestically and overseas, and indeed there have been some very significant uses. Major issuers of bank cards have formed work groups to use the Common Criteria to develop a profile for smart cards; the Financial Services Business Roundtable is doing that for the financial services community. The Process Control Security Requirements Forum is using the Common Criteria for SCADA systems security, and it is also being used in the health care community trying to use the Common Criteria to define requirements for the health care systems. But I think it's important to take a minute to review the meaning of a Common Criteria certificate. A Common Criteria evaluation is a measure of the information technology's compliance to the vendor's claimed security. It is not a measure or a guarantee that the product is free from malicious code or that the overall comprised system is secure. Any product that has a Common Criteria specification can undergo an evaluation and receive its certificate if the evaluation process is completed. I provided additional details in my written statement. As you mentioned, we have issued advice to the agencies on the use of evaluated products for non-national security systems. We described the overall role that assurance can play. And, of course, the Committee for National Security Systems has issued its Policy No. 11, and I will defer to my colleagues for additional comments on that. As to whether that policy should be extended, I believe that more data is needed from the CNSS policy experience before extension is considered or recommended for unclassified systems. One of the criticisms often levied on NIAP is that evaluations take too long and cost too much. We hear this from the small business community. Of course, one would expect to hear that of any evaluation process that is not free and instantaneous. However, these products do involve millions of lines of code. But given resolve, flexibility, resources and research, significant progress can be made. For example, the research community should look at new ways to develop enhanced security testing. We need new methods. The current process we have is too expensive and involves too much human subjectivity. We need to invest more in doing such research, because the sooner we do, the sooner we will have benefits from the results. We need to look outward at system- level composability issues and enterprise architecture issues, and we need to look inward to some of the security issues that are present with things like protocols. You have to look across the entire spectrum. In summary, the Common Criteria provides the means to develop specifications and a common means to develop security evaluations. However, more can be done to streamline this process through research and standards development, resources permitting. We must also keep in mind that technology alone will not achieve security, although we are focused on technology today. Thank you for the opportunity to testify today. Mr. Putnam. Thank you very much. [The prepared statement of Mr. Roback follows:] [GRAPHIC] [TIFF OMITTED] T2771.004 [GRAPHIC] [TIFF OMITTED] T2771.005 [GRAPHIC] [TIFF OMITTED] T2771.006 [GRAPHIC] [TIFF OMITTED] T2771.007 [GRAPHIC] [TIFF OMITTED] T2771.008 [GRAPHIC] [TIFF OMITTED] T2771.009 [GRAPHIC] [TIFF OMITTED] T2771.010 [GRAPHIC] [TIFF OMITTED] T2771.011 [GRAPHIC] [TIFF OMITTED] T2771.012 [GRAPHIC] [TIFF OMITTED] T2771.013 [GRAPHIC] [TIFF OMITTED] T2771.014 Mr. Putnam. Our second witness is Michael Fleming. Mr. Fleming currently leads the National Security Agency group responsible for development and customer implementation support of a broad set of IA solutions. Prior to this assignment, he held positions as the Deputy Chief of Network Security Group, Chief of Network Security Systems Engineering Office, Chief of Network Security Products Office and special technology transfer assignment with the NSA Deputy Director For Plans and Policy. Early in his NSA career Mr. Fleming served in a variety of technical and program management assignments in communications security and signals intelligence. He is a recipient of the NSA Meritorious Civilian Service Award and twice received the Presidential Rank Award for Meritorious Service. It is a pleasure to have you, and you're recognized for 5 minutes. STATEMENT OF MICHAEL G. FLEMING, CHIEF, INFORMATION ASSURANCE SOLUTIONS, INFORMATION ASSURANCE DIRECTORATE, NATIONAL SECURITY AGENCY Mr. Fleming. Thank you for your interest in cybersecurity, information security, or information assurance. We have three words that describe this very important endeavor. I would like to provide a quick overview of the Common Criteria and the NIAP current status, some of the potential for even greater applications, and discuss some of the issues that you have already raised. As you stated, it establishes a language which is very important, a syntax. The criteria is, in fact, a language, a dictionary for describing user needs and vendor claims. It also establishes the methodology to make those comparisons in terms of how well those claims meet needs. I think it's important to note the criteria does not apply to all information technology products that make no information assurance claims. The criteria employs a distinct but related set of functional requirements which describe the mechanisms and the assurance requirements which Mr. Roback described in terms of gaining confidence that those mechanisms work correctly. There are seven assurance levels, one being the lowest and the least rigorous; seven being the highest and most rigorous. In 1997, we entered a partnership with NIST called NIAP to promote, demand investment in security products, and establish the commercial security evaluation capability. To support the demand the Committee on National Security Systems in January issued NSTISSP 11, which stipulated the acquisition of commercial IA products, and IA-enabled products would be limited to those evaluated under formal schemes such as NIAP. In terms of demand, we have defined, in fact, 21 protection profiles, and 31 more are in development. These profiles address key technology such as operating systems, firewalls, and intrusion detection systems and other things. And the demand trend there is encouraging. As profiles are introduced for a technology, the number of evaluation claims is increasing. For example, all the operating systems in evaluation or that have been evaluated are compliant. All public key infrastructure are compliant. And about half of the firewall intrusion detection systems are either claiming compliance or compliant with protection profile. As far as the second goal of NIAP, establishing the labs, 8 labs are accredited and have completed 38 evaluations with an additional 55 underway and more being negotiated continuously. In terms of expanding the use across a broader spectrum of environments than just the Department of Defense, the requirements for information assurance in the national security market are almost identical to those in other mission-critical government or commercial systems. Common Criteria can be leveraged to converge these markets. The larger market would result in greater return on investment for the vendors, and everyone in the buying sector would benefit from that leverage. Regarding limitations, you address cost and timeliness. Evaluation of timeliness and cost actually is a function of a number of factors: Product complexity, assurance level aspired to, the vendor's preparedness to undergo an evaluation. And any problems found during evaluation typically want to be fixed before the evaluation is completed. All those can lead to some time and cost. But a vendor can capitalize on an initial evaluation investment by reusing parts for subsequent evaluations for subsequent releases. While the criteria makes every attempt to identify and correct security vulnerabilities to ensure--there is no assurance that these products are bulletproof, especially at the lower assurance level. Vulnerabilities can be introduced in a number of ways, from poor design, inappropriate operation. Source code evaluation is not always required, particularly until you get to the higher assurance levels, which many vendors don't aspire to. And vulnerabilities in an IA-enabled product introduced by unevaluated nonsecurity functionality may go undetected. Mechanisms complementary to the Common Criteria are needed to increase our ability to find and eliminate malicious code in large software applications. In conclusion, information systems require assurance that it was specified and designed properly, that it was independently evaluated against a prescribed set of security standards, that it will maintain proper operation during its lifetime even in the face of malicious attacks and human error. The Common Criteria in NIAP are working. The trends are up, and process improvements continue. A converged market for security products would benefit all potential IA buying sectors. The Common Criteria and NIAP are not a panacea for all security issues and all information technology. We need complementary activities. Security needs to be baked into information systems starting with specification. It cannot just be evaluated in at the end nor sprinkled in after a system is fielded. And I think this is an important point in terms of improving the overall process. This is all about making sure that a security product is, in fact, secure and doing its job. It has certainly been my pleasure to discuss the Common Criteria and share the work of the NIAP with the subcommittee, and I thank you for the opportunity. Mr. Putnam. Thank you very much, Mr. Fleming. [The prepared statement of Mr. Fleming follows:] [GRAPHIC] [TIFF OMITTED] T2771.015 [GRAPHIC] [TIFF OMITTED] T2771.016 [GRAPHIC] [TIFF OMITTED] T2771.017 [GRAPHIC] [TIFF OMITTED] T2771.018 [GRAPHIC] [TIFF OMITTED] T2771.019 [GRAPHIC] [TIFF OMITTED] T2771.020 [GRAPHIC] [TIFF OMITTED] T2771.021 [GRAPHIC] [TIFF OMITTED] T2771.022 [GRAPHIC] [TIFF OMITTED] T2771.023 [GRAPHIC] [TIFF OMITTED] T2771.024 [GRAPHIC] [TIFF OMITTED] T2771.025 [GRAPHIC] [TIFF OMITTED] T2771.026 [GRAPHIC] [TIFF OMITTED] T2771.027 [GRAPHIC] [TIFF OMITTED] T2771.028 [GRAPHIC] [TIFF OMITTED] T2771.029 [GRAPHIC] [TIFF OMITTED] T2771.030 [GRAPHIC] [TIFF OMITTED] T2771.031 [GRAPHIC] [TIFF OMITTED] T2771.032 [GRAPHIC] [TIFF OMITTED] T2771.033 [GRAPHIC] [TIFF OMITTED] T2771.034 Mr. Putnam. Our third witness for this first panel is Robert Gorrie. Mr. Gorrie is the National Security Agency integree serving as the Deputy Director of the Defensewide Information Assurance Program [DIAP], office, Office of the Assistant Secretary of Defense for Networks and Information Integration. Prior to his retirement from the Army after a 26- year career as a signal officer, he was Chief of the Information Assurance Division on the Joint Staff and Deputy Chief of NSA's Information Security Customer Support Office. Following his retirement, he is employed with Titan Systems Corp. as vice president of operations in its managed IT securities service group. He is a graduate of Gannon College and Penn State University in Pennsylvania as well as both the Naval and Air War Colleges. Welcome to the subcommittee. You're recognized. STATEMENT OF ROBERT G. GORRIE, DEPUTY DIRECTOR, DEFENSEWIDE INFORMATION ASSURANCE PROGRAM OFFICE, OFFICE OF THE ASSISTANT SECRETARY OF DEFENSE FOR NETWORKS AND INFORMATION INTEGRATION, AND DOD CHIEF INFORMATION OFFICER Mr. Gorrie. Thank you, sir, and I am honored to be here and pleased to have the opportunity to speak with your committee about some of the efforts DOD has initiated with respect to the evaluation of information assurance and information assurance- enabled products. As demonstrated in recent operations, U.S. forces have been extremely successful in the battlefield. They have been able to translate IT into combat power. However, as our dependence on IT increases, it creates new vulnerabilities as adversaries develop new ways of attacking and disrupting U.S. forces. No one technology operation or person is capable of protecting the Department's vast networks. In October last year, the Department published its capstone information assurance policy. The policy establishes responsibilities and prescribes procedures for applying integrated, layered protection for DOD information systems and networks. The DOD's IA strategies and policies are central to the committee's Common Criteria question. As I stated, no one single person, technology or operation can assure DOD's vast global networks. The Common Criteria, the NIAP evaluation program, the national and DOD policy addressing IA evaluations and the evaluated products themselves are part of an integrated DOD IA strategy. Even with the solid defense-in-depth strategy in place, we must be confident in the security and trustworthiness of the products we use to implement that strategy. New vulnerabilities in the equipment we use are identified daily. Through the Department's IA Vulnerability Alert [IAVA], process, users are made aware of the vulnerabilities and associated fixes. The IAVA process serves us well, minimizing the effects of recent cyber incidents on DOD networks. The IAVA process has also highlighted the alarming rise in the number of vulnerabilities, the risks they represent and the cost of associated remediation. Although we continue to improve the efficiency and effectiveness of the IAVA process, unless we can take proactive measures to reduce the number of vulnerabilities in our systems and networks, our ability to respond will begin to degrade. Although no product will ever be totally secure, we can incorporate security into the design and, through testing, gain a reasonable sense of the risk we assume when we use them. However, that requires policy, enforcement and practice. The Committee on National Security Systems, their National Information Assurance Acquisition Policy directs the acquisition of all COTS IA and IA-enabled products to be used in national security systems be limited to those which have been evaluated. Our DOD policy goes further than that, requiring the evaluation of all IA and IA-enabled products. While vendors are primarily driven by product cost, functionality and time to market, security has also become a significant consideration. Recently the largest vendors have pledged to make security a priority. The decisions of those vendors are based on thorough business cases analyses. None can afford the continued cost of the race against the ``penetrate and patch'' approach to deal with latent vulnerabilities in software packages. The economic cost of that approach is enormous and does not result in a higher level of security. Sound software engineering practices like those tested in a NIAP evaluation are an essential element in the elimination of vulnerabilities and critical to the reduction of postdeployment patching. Still there remains the cost of evaluation and time of evaluation. Both are functions of the complexity of a product, the level of evaluation, the quality of a vendor's product and the vendor's preparation for evaluation. Product complexity in the evaluation level is directly proportional to the amount of testing required, and the amount of testing is directly proportional to the time and cost. A quality product may not require repeat testing. However, products that do get into a test, fix and test cycle incur additional cost not only for testing, but also for product modification. Some vendors, especially small vendors, are concerned about the cost and time of evaluation regardless of the product's complexity. During the development of DOD policy, we met with small businesses individually and in multivendor forums, and, based on their input, we developed policy that attempts to remedy some of their concerns. The evaluation process does what it was designed to do. It provides standardized evaluation reports that help make--help us make informed risk management decisions with respect to the security of our networks and systems. Expectations of evaluated products should not exceed what the evaluations are designed to provide. The type of testing that uncovers vulnerability can be done by the NIAP laboratories and will be done if required. The depth of evaluation depends on how much time and how much money we are willing to pay, as well as how much risk we are willing to accept. Evaluations do not guarantee security. The security comes from sound systems engineering, the combination of technologies, operations and people. The President's recent National Strategy to Secure Cyberspace requires a comprehensive review of NIAP to examine its effectiveness and expansion potential. We are conducting that review in collaboration with the Department of Homeland Security. DOD is also investigating the issue of software assurance with respect to all software, not just IA and IA- enabled products, again working with the Department of Homeland Security. The challenges we face are the same challenges found throughout government and industry, challenges we are addressing in our IA strategic plan. DOD is making progress managing the risks successfully across all of our national security and defense missions. That success is documented in our FISMA reports as well as our annual IA report to Congress. Most importantly, however, it's reflected in our ability to act as an enabler and not as an impediment in the conduct of networkcentric operations in several theaters across the globe. I appreciate the opportunity to appear before your committee and look forward to your continuing support on this very critical issue. Thank you very much. [The prepared statement of Mr. Gorrie follows:] [GRAPHIC] [TIFF OMITTED] T2771.035 [GRAPHIC] [TIFF OMITTED] T2771.036 [GRAPHIC] [TIFF OMITTED] T2771.037 [GRAPHIC] [TIFF OMITTED] T2771.038 [GRAPHIC] [TIFF OMITTED] T2771.039 [GRAPHIC] [TIFF OMITTED] T2771.040 [GRAPHIC] [TIFF OMITTED] T2771.041 [GRAPHIC] [TIFF OMITTED] T2771.042 [GRAPHIC] [TIFF OMITTED] T2771.043 Mr. Putnam. Thank you very much. And we are delighted to have been joined by the ranking member of the subcommittee, the gentleman from Missouri Mr. Clay, and the distinguished gentlelady from California Ms. Watson. And at this time I will recognize the ranking member for his opening statement. Mr. Clay. Thank you, Mr. Chairman, and especially for calling this hearing. I'd like to reiterate two points that I made at last week's hearing. First, the government should use its power in the computer software marketplace to acquire safer software. Second, software vendors should be more aware of the security configuration of the software they produce. Let me briefly elaborate on these two points. The Federal Government spends billions each year on computer hardware and software. Those purchases have a strong influence on what gets produced and sold to the public. The Federal Government can use its market power to change the quality of software produced by only buying software that meets security standards. The result will be an increase in the security of all software and better protection for the public. This is a simple formula. The government doesn't have to regulate software manufacturers, it only has to use its position in the marketplace. Mark Forman, the former Federal CIO and regular witness before this subcommittee, incorporated an idea similar to this when he developed the Smart-Buy program. Mr. Forman realized that Federal agencies were buying the same software over and over again. Each agency was paying a different price for the same software, and the Federal Government was getting little or no leverage out of its position in the marketplace. No business would operate like that. I believe we should build on Mr. Forman's idea to buy not cheaper software, but better software. I hope the new CIO, Karen Evans, will work with the subcommittee to incorporate this concept into the Smart-Buy program. We don't have to wait for computer companies to develop new security procedures. There are some steps that can be taken very quickly to improve computer security. We saw this earlier this year when Microsoft began shipping software that was configured differently. The story Microsoft tells is that the company realized that it was shipping software with all the gates opened. A good computer manager systematically went through the software, closing gate after gate. Those with less training left the gates open, and the hackers walked in. Shipping software with secure configurations should be a first priority of all computer companies. I look forward to the testimony today of these witnesses, and I hope that our witnesses will consider my suggestions and provide the committee with their comments on it. Thank you, Mr. Chairman, for yielding. Mr. Putnam. Thank you very much. [The prepared statement of Hon. Wm. Lacy Clay follows:] [GRAPHIC] [TIFF OMITTED] T2771.044 [GRAPHIC] [TIFF OMITTED] T2771.045 Mr. Putnam. At this time we will recognize the gentlelady from California Ms. Watson for her remarks. Ms. Watson. Thank you so much, Mr. Chairman. I do appreciate this opportunity. Over the last decade or so, the Internet has become a force in our society that it is difficult to identify critical networks in our Nation that are not connected to the Internet. Electricity, traffic, water, freight, all these systems rely on the Internet for their function. This reliance on the Internet has yielded tremendous gains in efficiency, yet we are constantly reminded of the vulnerabilities inherent in such reliance on the Internet. Most recently, the Blaster and the SoBig viruses posed major challenges to the integrity of America's infrastructure. Thankfully, none of the cyber attacks known to us have resulted in cataclysmic damage to the United States, or to our people, or to our infrastructure, at least not yet. We have had many close calls. And in the wake of September 11, many analysts familiar with global terrorism blame America's leaders for missing the signs that we were vulnerable to conventional terrorism. If we in Congress do not wake up to the clear warning signs of our vulnerability, we would be committing just as grave a mistake. In my experience in Micronesia, in my embassy, is that we were getting warnings by cable from the State Department on a daily basis of a virus that ran through our most sensitive computers in the embassy. That's a very scary notion when you depend on the Internet 24/7 to communicate. And so this hearing is very, very valuable to the basic security of our country, and I really would like to be here to hear every bit of the comments that are being made by the panel with such expertise. But we have a hearing on terrorism, and I do hope our enemies around the globe do not--are not able to master the Internet to the extent that they know more than we do and they can get our country's secrets. So thank you so much, panelists, in bringing your expertise to us. Thank you, Mr. Chairman. And I'm going to run down to that classified hearing. Mr. Putnam. You just throw us off like a bad habit. Ms. Watson. I want to find out what those real secrets are. Mr. Putnam. We will begin with the questions for the first panel. Mr. Gorrie, could you explain why DOD decided to adopt the Common Criteria requirement for all DOD procurement. What led to that decision? Mr. Gorrie. The original NSTISSP 11 requirement was for-- only for national security systems, and if you look at the term ``national security systems,'' that's a legislative construct that was brought into being in I believe it was the Nunn-Warner amendment to the Brooks Act. The Brooks Act established that all ADPE, automatic data processing equipment, would be bought through GSA. The Department of Defense found that GSA wasn't really responsive to that. This was in 1986. And the Warner amendment, as it was known, changed that to reflect the term ``national security systems.'' so it said that--and I have it here somewhere, but--and I'll get it for you later, but it says all national security systems--and it went on to list what a national security system was: anything that handled classified information, did intelligence, did cryptologic work, did weapons systems, were national security systems, with the exception of what they term support systems, which were personnel systems, logistics systems and things of that nature. If you went out and talked to any commander around the globe and asked them if their personnel system or their logistic system was a critical part of their warfighting capability, they would undoubtedly all say yes, and so that is why--the reason we in DOD said you need not only security in your national security systems, but in all other systems that we use, because they all touch one another, and the potential for a security flaw in one could spill over to other ones. Mr. Putnam. How would you evaluate your experience thus far in terms of the weaknesses of it, the strengths of it, lessons we can derive as we contemplate its usage beyond DOD? Mr. Gorrie. First, the weaknesses of it. A lot of it has to do with our interaction with our vendors. Some of the vendors are not--and even some of the people, the users in DOD who have to follow the rule, are not familiar exactly with what the rule entails. Some of the criticisms from small businesses that they can't realize a return on investment are borne out of ignorance of what the policy says, because the policy does provide them the opportunity, when making a contract with the government to sell their particular product, that the only thing that they need to do is to stipulate in the contract that they will have the product evaluated, not that they have to evaluate the product prior to establishing the contract, which gives them the opportunity, if selected, to realize a return on that investment because they can include that cost in the cost to the government. The number of systems which are being evaluated, although adequate right now, needs to be much, much higher, and the types of systems that are being evaluated need to be expanded. Those are our problems. Benefits, as I said in my testimony, the ability to know what a product will do is one of the biggest benefits we can have. You can get the glossy brochure from a vendor that says this is the best thing since sliced bread, but until you put it to the test, you don't know what that product will do. And an independent evaluation such as that provided by the NIAP is invaluable not only because you know what it will do, but when you certify and accredit a particular system to be able to be connected to our networks, you have to make a risk decision whether or not that system is safe enough. If you know exactly what those products are doing, then you can craft other things around that particular product to circumvent any shortcomings it may have, things like an operational procedure or some kind of policy control or other things. So in that particular sense, the reports that we get out of NIAP are invaluable in order to make our systems safe. Mr. Putnam. Thank you. Mr. Fleming, when you developed NSTISSP 11, the requirement that national security systems purchase software certified after the Common Criteria, what consideration was given to its impact on small business? Mr. Fleming. NSTISSP 11, first of all, comes out of the national security community, which comprises of some 21 or 22 Federal departments and agencies and sort of the national security slice across those agencies, where in DOD it might go deeper than it would in some of the other agencies. It also requires an evaluation of all information assurance products. The NIAP process is only one of the schemers. NSA does evaluations for high-grade cryptography. So the NSTISSP 11 applies to a broader thing than just NIAP. As far as small businesses are concerned, the cost of evaluation, as I mentioned in the testimony, varies considerably depending on the assurance level. And when NSTISSP 11 was originally issued, it did not specify that all products had to be evaluated in the beginning. It put a date in there of July 2002. It came out in 1999. There was a period in there where it was something to be considered. And the idea there was to allow companies to get used to both the process and the profiles that were coming out. So the mandate did not start until, in fact, almost 2 years later in 2002. So the idea was to allow companies to grow toward what this was. The second thing was it didn't specify any particular evaluation level. The beginning thinking was any evaluation level is better than none. And so the cost is, in fact, considerably lower at the lower levels than it would be at the higher levels because of the demand for generating evidence. So the idea was to ramp this process up to allow companies to grow with it and, over time, ever increase the assurance level in these products. So that's how we wanted to consider, in fact, all vendors, but in particular the small companies. Mr. Putnam. In the beginning of your answer, you mentioned that this was to cut across national security systems. Does the Justice Department and Homeland Security and State also utilize government criteria? Mr. Fleming. Yes. NSTISSP 11 includes all those agencies and the opportunity for them--obviously NSTISSP 11 applies at that level the opportunity to use the Common Criteria, and the NIAP process is there for any buyer. But, yes, NSTISSP 11 covers those kinds of agencies for their national security systems. Mr. Putnam. Mr. Roback, as all of us are aware, and we have held hearings related to this, the Blaster worm exploited a flaw in Microsoft's operating systems to infect thousands of computers. Since that system was certified, why wasn't the flaw found? What is the weakness in the evaluation that does not get at code flaws? Mr. Roback. I think you have to look at the range of possibilities that the NIAP testing program offers. At the low end, where you are looking at things like documentation of how the product was developed, you are not getting into the very detailed code review that you get at the very, very high levels of assurance. So it sort of depends on what level you want to pick for your evaluation, which is the flexibility of it. A vendor can bring in product and target any one of the seven levels or create their own. So unless they target something at the very high level, which, by the way, costs a lot more and takes a lot longer, you are not going to get that level of review. And even if you do, it's subject to human subjectivity in the review. So you may not get--because we don't have very specific standards for this, and you probably couldn't at that level for millions of lines of code--standards you can do very quick, very exact testing. So there's' some art in here, too. Mr. Putnam. Thank you very much. Mr. Clay. Mr. Clay. To all of the witnesses, I would just like to hear from you or hear your comments on the proposal to add secure configurations as another dimension of a Common Criteria. Is this feasible, and how long would it take? We'll start with you, Mr. Roback. Mr. Roback. Actually under the Cybersecurity R&D Act that was passed by the Congress late last fall, they assigned to NIST the task of developing security configurations for specific IT products. And so we are holding a workshop later in September trying to invite the vendors in, and other Federal agencies and NSA and others have already developed some of these checklists for some very specific products. So some of these do exist. Actually I think it would be a very good thing, because if you look at a spectrum, first you want to have very strong standards. Then you want to have some testing program that tells you whether the standard was correctly implemented. And third, you want to have those configurations so that when a system gets one of those products, they know where to set the settings, because even if they are shipped from the vendor with security turned on, which is not always the case, but sometimes it is, it is not necessarily always right for the environment that it's being put into. Configuration guidance is a very good thing. It's also important to remember there's a range of potential environments; that is, the security you would have for a home user might be very different from the security at NSA or the security of a large, centrally managed enterprise. So you have to keep that in mind, too, there's a range there, because there's a range of risks in the type of information that's being exposed. So it does get complicated, but I think checklists of that sort are very useful. Mr. Fleming. I would agree with everything Mr. Roback said. This is a life cycle. Security is a life cycle endeavor. It just doesn't stop when the product is certified and goes out into the field security. Every day you've got to watch these products, particularly security products that sit sometimes in the way of system performance, and it is so often tempting to tweak that firewall a little bit to allow the bandwidth to get greater, but you may have, in fact, left open the door you don't want to open. So I would add to Mr. Roback's points the human dimensions of this. It boils down to how well trained is that system administrator or that security administrator; how well do they understand the multitude of configurations that these products can, in fact, take, and which ones are the good ones and the bad ones. So there's a dimension in this of awareness and training of individuals along with the ideas that Mr. Roback put forth in terms of having configuration guides. And we have been a very, very strong partner in the generation of these configuration guides for major IT systems, but there are many other technologies that need a similar kind of guide for a well-meaning, but sometimes difficult job called system administration, security administration. Mr. Clay. Mr. Gorrie, anything to add? Mr. Gorrie. Well, I could attest that it does work. In DOD we have been using secure technical implementation guides [STIGs], for our products for our operating systems and other things for a long time. We have a process that is known as gold disk, where we will go out and put particular security settings on operating systems. STIGs, security technical implementation guidance. We have them in DOD. They work, and it depends on, again, as Mr. Roback stated, what environment you want to use them in. If you are using them for an inventory system in a gym, no sense in tightening it all down because you want to be more open and share those sorts of things. If you have a critical system that you need protected, it needs to be ratcheted down. And all the people who participate in that network have to have it ratcheted down to the same degree. Mr. Clay. In your opinion, would it be possible to certify software configurations separate from the Common Criteria evaluation? Mr. Gorrie. I don't know. I would have to defer on that. Mr. Clay. Anybody? Mr. Roback. Well, I am not sure if certification is the precise word, but I think that there are indeed--you can separate the two. Whether a product has been tested to know whether the security features work correctly is a separate question from where to turn on and turn off the security features. However, if you haven't gone through certification, the testing process, you are not going to have a great deal of assurance that even if you turn something on, the security is working. And the example I like to give is you go to a Web site, and you get the little lock in the corner on your browser. Well, why do you have any confidence whatsoever that it is doing anything other than showing you a little picture of a lock? If it hasn't gone through testing, you really don't know, other than it makes a nice little picture in the corner. So that is why testing is so important in addition to turning on the security. Mr. Clay. For all of the witnesses, again, I would like each of you to comment on my proposal that the Federal Government use its market power to improve the level of security for our purchasers. Do you believe this is feasible? Mr. Fleming. I will start. During the testimony I used a phrase called converged market, and I think it is along the lines of your reference back to the Smart Buy Program that Mr. Foreman put in place. The idea of a converged market would be find that level of security goodness, that assurance level and that set of security mechanisms that a large buying sector could agree to, the DOD, the national security community, the other Federal agencies, the critical infrastructure marketplace that Ms. Watson referred to, such that a vendor would see a return on investment good enough for them to shoot for that level. And so this idea of getting a common level that all would buy into would, I think, be a good incentive for vendors. Make it appropriate so it is not a bridge too far, and then standardize on that level and let vendors shoot for that level so you can get this economy of scale. Mr. Clay. Thank you. Mr. Gorrie, one question from our other Member who had to leave. She says: It is good to hear that you understand the business costs of the reactive plug and patch approach, but how widespread do you feel this view has been accepted throughout the technology industry? What can we do to spread this message and change the approach? Mr. Gorrie. I think if you will ask the panel members that follow us, those are the words that were given to me by them. I mean, they were the ones who told me those things. I didn't make that up. How can we spread it? I think it will spread itself. Vendors whose products are well developed and have fewer problems as far as having to go out and patch them and things of that nature will be bought more. People will see the benefit of buying them, not being able to be hacked, not having to go in and reengineer their systems every time a patch comes out. Those who have products which are constantly being patched will find their position in the marketplace becoming lower. It is a self-regulating system, and it will become more so in the future as more and more patches have to be made to accommodate shortcomings in software. Mr. Clay. OK. I thank the panel. Thank you, Mr. Chairman. Mr. Putnam. Thank you, Mr. Clay. Mr. Fleming, under Common Criteria evaluation, the product is tested by itself. Obviously it will be used in conjunction with a variety of other products. Is that taken into consideration at all? And how is that issue resolved in terms of the impacts or the problems that can occur with the connectivity? Mr. Fleming. Good. First of all, the product is typically tested in an environment. In order to make the test meaningful, there is an assumed environment. However, that may not represent all possible environments for the application in the real world. So there is--and these are my terms. There is this ``little c'' certification, which is certifying that the product is doing what its claim is. Then there is the application of that product, along with other products, into a larger system. So there needs to be another certification, which is at what I will call the ``big C,'' at the system level. There are processes in place in the DOD and across the Federal communities that go by somewhat different names, and they are like kind of complicated names like DITSCAP, Defense Information Security Accreditation Program, but that is a system-level look. So I see the Common Criteria and any other evaluation program at the product level generating evidence about the performance of the various components. Then there needs to be a separate look at the much larger level, for what the total system security certification is. Now, I will state that the calculus for that is somewhat difficult, because it is not just saying product A has this level of goodness, product B has this level of goodness. You just don't add A and B and get C. In fact, it is a much more complex relationship when you start bringing many products together. But, nevertheless, there are processes in place in the DOD and beyond the DOD to bring this larger certification into play toward the ultimate accreditation of that system to operate in a real environment. Mr. Roback. If I can just add to that, that question of when you understand the property of one component and then the property of another, and you put them together, that is what the researchers call the composability issue, trying to understand in a rigorous way what you have when you put them together and add them up. If I could just add to Mr. Gorrie's comment earlier about the software quality and patching, I think one of the problems we face is the whole developmental cycle in the industry of software products. And you have to really look at how software products are developed in a rigorous sense of specifications and so forth. If you really want to improve the overall security and get away from this problem of continually chasing our own tail and trying to patch, this is a Web site where we put up vulnerabilities in commercial products so people can learn about them and go find fixes for them. Right now we have over 6,000 vulnerabilities up there. And, you know, the tolerance of the marketplace for these products that come out with flaws is just astounding. We really need to look at the overall quality issue of the products; not just the security, but the overall quality. Do they do what they are intended to do? It is a challenge. Mr. Putnam. Mr. Gorrie, several testimonies mentioned a waiver process for the Common Criteria. Under what circumstances would a waiver be granted? Mr. Gorrie. With the way that we have constructed policy within the DOD, I would find it very rare that you would have a request for a waiver. The only one that I could think of would be in a situation if we were going to war, we needed a particular product because its security features were just so obviously great that we could not not afford to have it in our system. But even then, the way that we have policy built, it says that you need not to contract to purchase that piece of equipment, you need not have it evaluated, only have it in the contract that you will have it evaluated as a condition of purchase. However, the vendor always has the option to say, you may need this, this may be the best thing since sliced bread, but we are not going to have it evaluated. If we needed that product that bad, then the user of that product, or the person who wanted to put that product into their system, would have to petition for a waiver, and then we would either have it evaluated internally within DOD through some process, or just use it because it was so important to use. But in any regular process I--because of the way policy is written, I do not see the need for waivers. Mr. Putnam. My final question for this panel will be this, and we will begin with Mr. Roback: Should the Common Criteria certification be extended to cover the entire Federal Government? Mr. Roback. That is a good question, one we are often asked. Let me just start by mentioning that it is policy for the nonnational security side of government that cryptographic products have to go through testing, and there is no waivers allowed for that under FISMA. I don't think the question is necessarily should we adopt that policy, yes or no. There is actually quite a range of options between doing nothing and adopting that policy, and even things beyond that policy. So you might ask yourself: Well, maybe it doesn't make sense to say something can be certified against any specification that is brought forward, but maybe what we need to do is look at things like once we have good specifications for specific technology, that if an agency is buying that technology, they should be buying something that has been evaluated against those specs. So not just that you can bring in--I think someone in their testimony talked about a product that paints the screen blue, and it can go through and get a certification. Well, I don't know if those products are going to do us any good. So I think there is some range of options we have here, and we really need to look at those. Rather than just say, that is the policy for national security; we should simply adopt it. I think we need to learn more from the experience as well. Is it really pushing the vendors toward more security or not? Mr. Putnam. Mr. Fleming. Mr. Fleming. We are putting our trust in networks, in things called security products. They have become sort of a foundation piece, a trust anchor, if you like. And so it would seem to me we should take extraordinary measures, not necessarily expensive, but take extra measures to ensure that, in fact, that trust is well founded. So having some rigor in how we look at security products is, I think, important. Independent evaluation is an important piece of that rigor. That is something different than the vendor claims. So where does one get this independent look? What is the most efficient way to get that independent look that in and of itself can be trusted by people who use these systems? So whether it is a Common Criteria-based system that we use, whether it is some derivative that may be the result of an evolution of the process, I believe that we need to put honest faith in our security products through some independent specification evaluation process. It is too important just to sort of leave to the normal process. Mr. Putnam. Mr. Gorrie. Mr. Gorrie. There is two parts to this, as Mr. Fleming said. There is the independent evaluation portion of it, the Underwriters Laboratory, if you will. Should that be extended to the rest of the Federal Government? The Department of Homeland Security thinks it is. That is why they want us with them to do a review of the NIAP process, to see what that extensibility of the process is to the rest of the Federal Government. Is it extensible to the rest of the civil population? No one forces a consumer to buy a lamp that has the Underwriters Laboratory stamp on the cord, and perhaps no one should be forced to buy a piece of IT security equipment with a NIAP certificate associated with it. There is the evaluation program itself, and then there is the regulatory and policy piece that goes along with it. And although I think the evaluation portion of it can go forward, because knowledge is power, the--how you instantiate that in regulation and in national policy is a different matter altogether. Mr. Putnam. Thank you very much. And I want to thank all of our witnesses on this first panel and encourage you to stay and listen to the second panel, if your time and schedule allow. With that, the committee will stand in recess for 2 minutes while the first panel is dismissed and the second panel is seated. [Recess.] Mr. Putnam. The committee will reconvene. Before we swear in the second panel, I did want to announce publicly that the executive session on SCADA, which was scheduled for tomorrow by the subcommittee, has been postponed thanks to Hurricane Isabel. And with that, I would ask panel two to please rise and raise your right hands for swearing in. [Witnesses sworn.] Mr. Putnam. Note for the record that all of the witnesses responded in the affirmative, and we will move immediately to their testimony. Again, I would ask that you limit your remarks to 5 minutes, and your entire written statement will be submitted for the record. Our first witness is David Thompson. Mr. Thompson directs the CygnaCom Security Evaluation Laboratory. He has led a team to support certification for the Air Force Scope Command's High Frequency voice and data communications system, and managed Public Key Infrastructure products at several Department of Energy National Labs. He led a team to write a Common Criteria security target for Red Hat Linux 5.1, and helped translate high-assurance criteria into Common Criteria protection profiles. Previously Mr. Thompson evaluated the security of network and computing configurations for the space station and space shuttle, and assessed proposed uses of cryptography and distributed authentication at NASA. He was session chairman for the 1993 AIS Security Technology for Space Operations conference, and served on a board investigating a software configuration management failure in a space shuttle mission. Welcome to the subcommittee. You are recognized, Mr. Thompson. STATEMENT OF J. DAVID THOMPSON, DIRECTOR, SECURITY EVALUATION LABORATORY, CYGNACOM SOLUTIONS Mr. Thompson. Thank you. I would like to thank the committee Chair and all of its members for their interest in this issue and their leadership. The motivation for product testing that led to the creation of the Common Criteria came from the U.S. Government's certification and accreditation process for systems. Most systems included at least one computer with operating systems that needed a security functionality identified and assessed. Since operating systems are quite complex and have many key security functions, considerable effort is required to do an appropriate security assessment. As computers became more commodities, the notion of performing these difficult evaluations once and using the results in repeated CNAs took hold. In the early 1990's, as the expense of having products evaluated to different security criteria in different countries increased, Western governments began to seek a set of Common Criteria that they could endorse. We are still in the early stages of implementing the resulting Common Criteria. But the original government participants are still actively engaged, and additional governments are getting involved. Industry also begun to see the value of a common security performance process. The CC defined seven sets of security assurances called evaluation assurance levels. EAL1 has the least assurance, and the EAL7 the most. The most commonly used assurance levels are EAL2 and EAL4. The EAL2 is an acceptable assurance level for most products, and EAL4 is often specified for products that are employed in the first line of defense, such as firewalls and operating systems. Custom sets of CC assurances can also be chosen when one of the seven EALs is not precisely suitable. The result of a successful CC evaluation is a published security target that precisely documents the security functions that the product claims to meet and establishes in precise terms whether these claims are true, the security target to be used to determine the product's suitability for a particular use and to compare its security functionality with that of other products. It is practically impossible to determine that a product of any complexity will be secure regardless of its configuration or that security will mean the same thing in all the situations in which the product is used. What CC testing does show is that to the specified level of assurance, the security functions the vendor claims the product has work as described, and that a coherent and mutually supported set of security functions is available. Just because a product has been successfully evaluated under the Common Criteria does not mean that it has no vulnerabilities. Instead, it shows that the product is suitable for use as a component of a secure system. It is primarily focused on design and development process issues. Although higher CC assurances, such as the EAL7, also can significantly reduce the possibility of bugs, the Common Criteria evaluation process has several strengths. It provides consumers with an independent and well-monitored assessment of vendor security claims. It provides a precise description of a product's security features that is readily comparable to those of other evaluated products. It assesses the ability of a product to be used to build secure systems. It demonstrates that at least one configuration of a product meets the claimed security requirements. It allows precise tailoring of the security criteria to the capabilities of products. It uncovers design flaws and sometimes software bugs. It focuses vendors on security issues. It constitutes the most rigorous and thorough independent product testing process commercially available. It provides international mutual recognition so that vendors have to pursue only one evaluation against a single criteria. The Common Criteria evaluation process also has some drawbacks. It creates additional expense for product vendors. CC evaluation is applied to an exact version of a product in a precise hardware environment, making it sometimes hard to field a product that is strictly conformant. As consumer protection profiles evolve, as vendor products are revised, they must be reevaluated. The evaluation process is complex and time- consuming, which means it requires a lot of vendor resources, understanding and participation. Some of these are conflicting. For example, establishing the security of a product across a broad range of its configurations among many versions is more difficult and would further increase the expense. While large vendors are more easily able to absorb the cost of an evaluation than smaller vendors, small vendors benefit more from an independent product assessment that makes it easier for customers to compare its products' security features to those of its better-known competitors. The CCE offers a broad range of assurances and a corresponding broad range of costs. The EAL1 evaluation costs are in the low tens of thousands of dollars. EAL1 is adequate for many applications. Higher assurance has higher cost and is appropriate where the security risks are higher. The problem of eliminating security bugs from complex systems, such as those we read about regularly in the news, requires resources many orders of magnitude greater than those required for CC evaluations. There is little theory to support solutions to this problem, and it remains an art form. The most productive approaches to bug elimination involve improved software engineering practices to prevent the introduction of bugs in the first place. Finding and fixing bugs in existing products is always more expensive. The CC product evaluation process is a very effective tool when used in the right context. The international support and precise specification of security attributes minimizes the problems inherent in integrating diverse systems and components built in different countries and secure systems whose security attributes are well understood. The Common Criteria evaluation, however, does not serve every purpose. The fact that attempts are made to apply it to situations for which it was not designed shows how great is the need for other kinds of security testing and the challenges facing the available security evaluation services. Thank you for this opportunity to address you today. Mr. Putnam. Thank you very much, Mr. Thompson. We are glad to have you. [The prepared statement of Mr. Thompson follows:] [GRAPHIC] [TIFF OMITTED] T2771.046 [GRAPHIC] [TIFF OMITTED] T2771.047 [GRAPHIC] [TIFF OMITTED] T2771.048 [GRAPHIC] [TIFF OMITTED] T2771.049 Mr. Putnam. Our next witness is Mary Anne Davidson. Ms. Davidson is the chief security officer at Oracle Corp., where she has been for the last 14 years. As Oracle's CSO, she is responsible for Oracle product security, corporate infrastructure security and security policies, as well as security evaluations, assessments and incident handling. Ms. Davidson also represents Oracle on the Board of Directors of the Information Technology Information Security Analysis Center, and is on the editorial review board of the Secure Business Quarterly. Prior to joining Oracle in 1988, Ms. Davidson served as a commissioned officer in U.S. Navy Civil Engineer Corps, during which time she was awarded the Navy Achievement Medal. She has a BSME from the University of Virginia, and an MBA from Wharton at the University of Pennsylvania. We always appreciate your interaction with this subcommittee and your direct and candid remarks. Welcome. You are recognized. STATEMENT OF MARY ANN DAVIDSON, CHIEF SECURITY OFFICER, SERVER TECHNOLOGY PLATFORMS, ORACLE Ms. Davidson. Mr. Chairman, Ranking Member Clay, on behalf of Oracle, I appreciate the opportunity to be here today to offer Oracle's perspective on the Common Criteria. Oracle is uniquely qualified to comment on information assurance policies. We have spent more than 25 years building information management systems for customers that I affectionately call the professional paranoids, which include U.S. intelligence agencies and the Defense Department. To gain and maintain the business of the most security- conscious customers on the planet, we have made extraordinary investment in information assurance and have 17 independent security evaluations to show for it, with 4 more in process. The collective impact of Code Red, Blaster and SoBig to our economy, which amounts to billions of dollars in repairs and down time, have worked to send a sobering message: It is long past time for the entire Federal Government to get serious about information assurance. The benefits go beyond secure Federal information systems. A strong Federal information assurance policy has a potential to change the entire software industry for the better. Let me tell you there is no vendor when faced with this requirement who will build two versions of software, one that is strong, robust and well-engineered, and a buggy, crummy version for the commercial sector. Fortunately, some Federal agencies are listening. NSTISSP 11 and DOD Directive 8500.1 draw a constructive, clear prosecurity line in the sand. The question is not whether NSTISSP 11 makes sense or not. We have had that debate, and it is over. The NSTISSP 11, with the linkage to the Common Criteria, the de facto worldwide evaluation standard, is making a positive, constructive difference in software development. The Common Criteria has three key benefits for vendors who do evaluations: You have more secure products. Evaluators find security vulnerabilities which must be remedied prior to receive a certificate. There has been a lot of discussion about the cost of evaluations, but I have done the analysis, and if we find or prevent even one significant security flaw in our products going through the evaluation, it more than pays for the cost of the evaluation, even at the highest assurance levels that are viable for commercial software, which says nothing about the expense to customers that we prevent by getting it right the first time. Second, a more secure development process. Evaluations actually force you to have a secure development process throughout the entire development process. Security can't be something that is thrown on in the last 2 weeks of a cycle and has to be baked into the development process. That is what the evaluators are looking at. Third, and probably most important, a strong culture of security. If you do evaluations as part of development, then security becomes baked into your corporate culture. That is the biggest problem that we have in the industry: Security always seems to be someone else's job. At Oracle I tell our developers, you are personally responsible and accountable for every single line of code you write. Since NSTISSP 11 has gone into effect, we have seen very positive developments. More firms are doing evaluations. Firms, including Oracle, are sponsoring open-source evaluations. Many other industries are looking at certification efforts along the same lines as the Common Criteria. This has been successful because industry believes the Federal Government is serious this time, and that is a major victory. And thanks goes to people within DOD, the Intel Community, and Congress, who are making an effort to make the process work. So what can we do to make this process work better? You can hold the line by maintaining an eternal but pragmatic vigilance through the no-waivers policy. I said a year ago that it was time for the government to chirp or get off the twig on information assurance, and there has been a lot of chirping going on. But there are still those who want to get off the twig by getting a waiver or seeking opt-outs. It sends a bad message to the marketplace to say that NSTISSP 11 does not apply to us. It really needs to apply to intelligence across the board. NSTISSP 11 should be extended beyond traditional national security systems, and specifically, I think DHS should look at applying this to their own systems. Clearly they have a mission of national security. NSTISSP 11 shouldn't be allowed to--protection profiles should not be agency-specific wish lists. I think vendors are willing to do an evaluation against a common protection profile, but they are not willing to do three of them per each special agency. Country independence of laboratories should be maintained. We do our evaluations in the United Kingdom, because the cost is lower and the expertise is actually far higher than we have found in the United States for our particular product set. We still get resistance to foreign evaluations, and this is ridiculous. We are very happy to support U.S. labs as a competitive alternative, but competence knows no national boundaries. A couple of final points. There are three things that the government can do to foster better security beyond evaluations. We know that it does not provide a silver bullet or perfect products. The Federal Government should require that products have a default setting that is secure out of the box. I think NIST can do a lot of work here. This would also provide a lot of immunity to a number of viruses and worms, because more systems would be locked down by default. It would lower the cost of operations for the government and other customers. The government should invest in cybersecurity research. Quite honestly, the reason vendors cannot find more faults in the products in development is because the tools do not exist to do so, and the venture capital community will not fund it because there is no way to make money on it. If we can stomp out smallpox through investing in medical research, we can certainly get rid of buffer overflows. It is just code. Finally, industry can do more to improve the security profession. I fully support an alternative to Common Criteria evaluations, for example, for consumer products where it is perhaps inappropriate to do a Common Criteria evaluation. And an example would be the Underwriters Lab. Most products are just designed to be secure. And Cuisinarts are designed, for example, that you can't lose your fingers by sticking them in while the blades are whirring. They are just secure. Consumers don't have to do something special to make them operate securely. NSTISSP 11, DOD 8500.1, and the national strategy are welcome developments because they are moving the debate to the expectation that everything will be secure. I believe we have turned a corner, but it took 10 years and numerous sobering events to get us here. It will take continued vigilance and continued leadership here in Congress to keep us on this road. Thank you again, Mr. Chairman, for the opportunity to testify today. Mr. Putnam. Thank you very much, Ms. Davidson. [The prepared statement of Ms. Davidson follows:] [GRAPHIC] [TIFF OMITTED] T2771.050 [GRAPHIC] [TIFF OMITTED] T2771.051 [GRAPHIC] [TIFF OMITTED] T2771.052 [GRAPHIC] [TIFF OMITTED] T2771.053 [GRAPHIC] [TIFF OMITTED] T2771.054 [GRAPHIC] [TIFF OMITTED] T2771.055 [GRAPHIC] [TIFF OMITTED] T2771.056 Mr. Putnam. Mr. Clay, if I heard her correctly, she said that she tells her developers that they are personally responsible for every line of code that they write. It is a good thing nobody holds us to that standard on the U.S. Code. Our next witness is Mr. Klaus. Christopher W. Klaus is the founder and chief technology officer of Internet Security Systems, Inc., a leading global provider of information protection solutions that secure IT infrastructure and defend key online assets from attack and misuse. Prior to founding Internet Security Systems, Mr. Klaus developed the Internet Scanner, the first vulnerability scanner, while attending the Georgia Institute of Technology. Mr. Klaus was honored in MIT's magazine, Technology Review. In addition, he received the award for Ernst & Young's Entrepreneur of the Year in 1999, in the category of Internet products and services. Welcome to the subcommittee. You are recognized. STATEMENT OF CHRISTOPHER W. KLAUS, CHIEF TECHNOLOGY OFFICER, INTERNET SECURITY SYSTEMS, INC. Mr. Klaus. Thank you, Mr. Chairman. It is an honor to testify today. And I am representing Internet Security Systems from a small company's point of view that builds the security products, and we are in the process of going through the Common Criteria and NIAP certification and wanted to share some of our experiences as a company going through it, and what are some of the benefits and some of the failures of the process that we see today. We do believe the overall goal and the intent of the Common Criteria and going through NIAP certification is a positive goal, but we see that there is at least three areas of major improvement that need to happen. And if they do not get addressed, we believe that following this path of requiring the government to follow the guidelines of NIAP certification actually makes the government less secure. And we will go through these three reasons and talk to why do they make both the government and others that follow the certification less secure. No. 1 would be the accuracy. The current different levels of evaluation do not reflect whether the security product is actually more accurate in protecting against vulnerabilities and exposures. To take a step back, let me explain two goals within security, so you understand what we are measuring. There is two major goals in security. One is to allow good people into the network, or into an operating system, into an application. And what we typically think of good guys in technology is like your user name and password that allows you to get into the system. There is biometrics, fingerprinting, VPN, virtual private networks. All of those technologies are great for--help certify the right people get into the system. And one of the problems, though, is it assumes that the infrastructure stops the bad guys out. So the second goal of security is keeping bad guys out. The problem we find is that the assumption that the infrastructure keeps the bad guys out is false. We know there is everyday bugs in the code. These bugs lead to vulnerabilities that then allow intruders, worms, viruses to leverage that. So on the second goal of keeping the bad guys out, that is a major area of measurement. And one of the things that we track very closely as a company that produces security products, we are tracking over 200 plus vulnerabilities every 3 months, every quarter, as we measure that, and what is interesting about this is as we go through this process, products that are less accurate in finding those vulnerabilities have the same certification as the companies that have much more accurate products. And if you likened it to antivirus, which most people are familiar with antivirus software, if only 10 percent of the vulnerabilities were--or 10 percent of the viruses were found with one product, and 99 percent were found with another product, today they would be measured equal in terms of the certification level. And that is one of the major reasons why government agencies that believe they are getting a more robust product may end up--just because they are purchasing a higher level certified product may actually end up with a less robust and less accurate product. The next major area is speed. The current evaluation process is extremely slow and bureaucratic. It can take over a year to become certified. By the time it does become certified, it is outdated and behind the latest version of protection. The commercial sector could apply the latest version, and while the government would lag behind in security, in the race against cybercrimes threats, all organizations need to apply the current, most up-to-date security protection products. I just would add that there is over 40 IDs or intrusion detection companies in the process today, but only two of them have actually been certified. So we have a long way to go before all of them have gone through this process. The issue, though, also with security products, we are in a much different stage in the technology industry where we are rapidly evolving the technology to keep up with the cyberthreats. A lot of older technologies, like operating systems, data bases, Web servers, those technologies have been around longer, more mature, have a much longer development cycle. So in many cases the larger the application, and the larger the deployment cycle, the more likely you can keep in pace with the certification. In the security circles it is at a much faster rate. And finally, the cost part of this is that the current evaluation process is extremely burdensome and costly for security vendors to follow. And after following the process, the expense does not--for us has not resulted in any security improvement. It has not found any buffer overflows. It has not found anything that many of the hackers and worms and viruses take advantage of. So, therefore, many of the resources and capital that we are spending on this, if it was doing something to make our products a lot better, and more protected, and more robust, and more accurate, we would be in favor of this. So those three things, accuracy, speed and cost, are critical to improving, to make this thing worthwhile. Mr. Putnam. Thank you very much. [The prepared statement of Mr. Klaus follows:] [GRAPHIC] [TIFF OMITTED] T2771.057 [GRAPHIC] [TIFF OMITTED] T2771.058 [GRAPHIC] [TIFF OMITTED] T2771.059 Mr. Putnam. Our next witness, our last witness on this panel, is Eugene Spafford. Dr. Spafford currently serves as the director of the Center for Education and Research in Information Assurance and Security at Purdue University, a position he has held for 5 years. He has written and spoken extensively on the topic of information security. His research focuses on the prevention, detection, and remediation of information security failures and misuse, including fault tolerance, software testing and debugging, and security policies. He holds a Ph.D. in information computer science from the Georgia Institute of Technology. We are delighted to have this level of expertise on the panel. And you are recognized for 5 minutes. STATEMENT OF EUGENE H. SPAFFORD, PROFESSOR AND DIRECTOR, CENTER FOR EDUCATION AND RESEARCH IN INFORMATION ASSURANCE AND SECURITY, PURDUE UNIVERSITY Mr. Spafford. Thank you, Mr. Chairman. And thank you also, Ranking Member Clay and members of the committee. The question posed to us for this hearing was can the Common Criteria ensure security for the Federal Government? And my answer to that is very definitely not. It will not. And that is not to say that the Common Criteria is not a valuable instrument. The many thousands of man-years of effort by experts around the world putting it together has resulted in a procedure and set of documents that have great value as guidance for those building systems and for a means to compare systems as to their level of quality. However, it does not actually address the problem of ensuring that the government systems or any systems that possess the certification are themselves secure. It is in some sense, if I may use the analogy, similar to wanting to be sure that your house will not burn down and believing that the Underwriters Laboratory seal on the cord of your toaster will ensure that. It is not the case. What it does do is it gives you a small added measure that one item involved is less likely to cause you damage, but it is certainly no guarantee for the whole enterprise. We can see that with an example that has been cited by many others. If we look at the Windows 2000 operating system, it is certified at the highest currently available level available under the Common Criteria, and yet it was a target. It was vulnerable to the Blaster worm, the Natchi Worm, dozens if not hundreds of current viruses, and has had nearly 100 patches issued for it--those are security patches, not functionality patches--since it was released. And that is something that is certified at the highest level. There are other examples. I have given a detailed list in my written testimony as to why I do not believe that the Common Criteria is going to give us the level of security that we want. And in the very limited time available here, what I am going to do is give a different approach to this, and I am going to do it by analogy. Let's take that toaster example that I was talking about. Suppose that you were the vendor of that toaster, and you wanted to compete on the market and decided that an evaluation was something that would give you a competitive advantage. So you submit it to a consumer testing lab. However, when you submit it to the testing lab, you submit it without a cord, and you tell the testing agency that you want to submit it as a bread storage device. Well, the agency is required to test it against the requirements that you gave them. So they will test it as a bread storage device. They will go against the checklist for all the devices in the kitchen, and they will discover there are no radioactive materials or explosives embedded in it, and that, in fact, it does meet all of the documentation that you provided, it was built by the engineers in the appropriate way, and it does store slices of bread. So they give you their highest level of certification. You then turn around and put it in the marketplace with a cord and with a consumer option to include a speaker phone, because while you are making toast, you want to call your neighbors and tell them to come over and have some of the toast. The problem there is that about every tenth piece of toast that you put in burns and possibly starts a fire. What is more, the speaker phone is defective and calls up your neighbors and starts fires in their toasters. And because parts of the toaster were built overseas in a country that was unfriendly to the United States, if you use the toaster in any government kitchen, it simply doesn't work. On top of that, the manual is badly written. Customers who buy it don't really understand how to use it. They attempt to toast jello, they use it in the bathtub. And when all of the various disasters occur, the fires and deaths, they find that the disclaimer that shipped with the toaster says that the vendor has no responsibility for anything that the user may do with the toaster, and therefore they have no legal recourse, and there is no penalty that comes back on the vendor. However, the toaster does very well in the marketplace because it is cheaper than the other toasters that aren't certified and happen to work without fault. Those who go out and buy in large quantity, using the lowest bid, proceed to make you the market leader. Certification does not guarantee that what you have is safe. It says that it meets the standards for the certification. It also does not tell you that it is going to be used safely or in an environment where it is appropriate to use it. That is why the Common Criteria is not appropriate. Quality needs to be built in from the very beginning. As has already been noted by others, we don't know how to do that well, because this is an area that has been underfunded. It is an area where we need more research. We need more resources put into the agencies that are involved in this, particularly NIST. This is a problem that we are going to continue to face for many years because we have such a large base of legacy code that is already in place and is too expensive to replace with something, even if we developed it tomorrow, that was much better. Thank you for--the committee for listening to us on this today, and I stand ready to answer questions. [The prepared statement of Mr. Spafford follows:] [GRAPHIC] [TIFF OMITTED] T2771.060 [GRAPHIC] [TIFF OMITTED] T2771.061 [GRAPHIC] [TIFF OMITTED] T2771.062 [GRAPHIC] [TIFF OMITTED] T2771.063 [GRAPHIC] [TIFF OMITTED] T2771.064 [GRAPHIC] [TIFF OMITTED] T2771.065 [GRAPHIC] [TIFF OMITTED] T2771.066 [GRAPHIC] [TIFF OMITTED] T2771.067 [GRAPHIC] [TIFF OMITTED] T2771.068 [GRAPHIC] [TIFF OMITTED] T2771.069 [GRAPHIC] [TIFF OMITTED] T2771.070 [GRAPHIC] [TIFF OMITTED] T2771.071 [GRAPHIC] [TIFF OMITTED] T2771.072 Mr. Putnam. Sounds like this could be a fun panel. Mr. Clay will lead off this round of questions. Mr. Clay. Thank you, Mr. Chairman. And I will start with Mr. Spafford. You said your research center has a data base of computer vulnerabilities. In your search of that data base, how many of the software products identified were certified under the Common Criteria? Mr. Spafford. Sir, I didn't do a search specifically on that criteria, but from the numbers that I know from looking at similar searches, I would suspect that we have several hundred that apply to certified products. As I noted, there are over 100 for Windows. A few of the other products, the firewalls and intrusion detection systems, the Oracle data base system has a few as well. We know that there are several hundred vulnerabilities for the bulk of certified products. Mr. Clay. You also point out that software certified at the highest level of the Common Criteria is subject to the same worms and viruses as software that has not been certified. The certification process is already a long and costly process. What would have to be changed in the Common Criteria to address these problems, and what would that do to the cost and time for certification? Mr. Spafford. Sir, the certification process is against the documentation that is provided by the vendors and against a set of specifications that have been put out by the groups that have set the Common Criteria, and those do not include issues such as resistance to malicious software. There are architectural issues to the way that the code is actually written that would need to be changed in the products fundamentally. So, for instance, taking macros out of word processing and spreadsheets, preventing e-mail programs from automatically executing attachments are ways to stop viruses, but they are not the only ways to stop those kinds of software problems. And those are not issues that are tested under the Common Criteria. Those are architectural features that are actually part of the product and the reason it is sold as it is. Mr. Clay. Mr. Klaus, you indicate that you do not believe that Common Criteria evaluation improves security. How would you propose the government determine in the procurement process that the software it buys is secure? Mr. Klaus. I think the--in talking about the security products, say, for example, the firewalls and the intrusion detection systems, today there is no certification that I am aware of that says, you know, take Gene Spafford's data base of thousands of vulnerabilities and exploits and different ways hackers get in today and evaluate whether a firewall or IDS system stops all of these vulnerabilities and all of these attacks. So today there is no benchmark or operating system among the security products to say which one is most robust against these types of attacks; these are the known attacks much less the unknown attacks that are continually evolving. If we can just measure how good are security vendors keeping up with the current pace of vulnerabilities, because there is a lot. There are over 200 vulnerabilities, like I said, every month, where we are tracking and need to keep measuring the quality of the security vendors' products. It is a little bit counterintuitive. I think if we look at some of the commercial certification companies out there, they have been able to hit the goals. When you look at the companies that certify the antivirus companies, they meet 99.9 percent of all viruses. They have been able to hit it. So they are testing what is out in the wild, what are the latest things that are happening, so they can quickly, at the end of the product, measure did the security company keep in pace at the very end? Did they hit the end result of what they said that they would do for protecting against those threats? And then the onus of having a very robust security product and the processes are still left on the security vendor to follow. And from a speed and cost perspective, because it is only testing at the very end, did this thing catch all of the hacker exploits, all of the worm exploits, all of the different ways that systems get compromised, it is a much more lightweight process. You can accomplish it in a month. It doesn't take a year to go through that, and therefore the turnaround is much faster. Rather than trying to be completely overcomprehensive in your evaluation of every detail and aspect of the security design and architecture, I think that needs to be held to probably the security vendor themself making sure that they end up with that, because otherwise they themselves become part of Gene Spafford's data base of vulnerable systems. But, on the flip side, the most important thing in terms of protecting the government: Can they stop these risks? I think shrinking it down to a much more focused process would help drive lower costs, faster speed and a much more accurate measurement of is this product more secure or less secure for the government. Mr. Clay. Ms. Davidson, did you have something to add? Ms. Davidson. I did. Actually I had a couple of responses to that, one of them a personal anecdote. My company did look at deploying one of the hottest new security products in a particular sector, which is supposed to defend against certain classes of application vulnerabilities. This is something, a specialty firewall, that you would put out to protect yourself against various types of attacks. It claimed to be the one of the market-leading products. My hacking team broke it in less than an hour using an attack that product was supposed to prevent. It is important that security products, because they are the early warning system, have some type of independent assessment of security worthiness. I am also aware that people's intrusion detection systems failed when Slammer was going around because of the composability of the systems. They were running things back end which themselves were not secure. I would certainly be open to flexible ways of validating the security worthiness of security products, but it is not all about feature function. It does one no good to protect, allegedly protect, against certain classes of attacks only to find that the security system itself is badly flawed, and that in at least two cases has been our experience. Mr. Clay. Thank you. Mr. Thompson, did you want to add something? Mr. Thompson. I just wanted to point out that the security evaluation process is designed to verify what a vendor claims, but it does that--there is a very publicly available statement of what the vendor claims. For example, if--you know, if the toaster manufacturer says that--has this evaluated as a bread storage device, it would be evaluated as a bread storage device. And if the government wanted to buy toasters, and they wrote a protection profile that specified toasters, the bread storage device probably wouldn't meet the projection profile for toasters. And somebody could write a security target for a bread storage device, and it would be--you know, it would be classified as a bread storage device. The confusion--the CC process allows products to be compared by specifying their security criteria in a semiformal language that is easily comparable. Mr. Clay. Well, the security issue sounds more like a moving target, you know, as people come up every day with new viruses, new worms, new ways to penetrate computers. Mr. Thompson. Well, that is sort of a---- Mr. Clay. Can we win? Can we win the battle of securing these computers? Mr. Thompson. That is a different--finding patches and fixing them is a very difficult process, very expensive process, and I don't think that is the way we are going to win in the end. There is certainly things we can do--to find a patch is something we should do, as long as we have these vulnerabilities, but the kind of software development that the Common Criteria is encouraging is using sound engineering principles and design life cycle processes. And that is with the higher assurances like EL6 and 7, encourage those kinds of things. In other words, you can't--if you are going to evaluate EL7, you have to develop it in the process of documenting. You have to formally prove that it meets its security policies and things like that. And those engineering principles have to be applied to the development process. And we think that is a more--in the long run the only way you are going to get secure products. Mr. Clay. Mr. Klaus. Mr. Klaus. I think there is--within the Common Criteria, one of the issues that I think that the previous panel had really pointed out repeatedly was that this is still an art form in terms of finding the vulnerabilities, more R&D money for automating the tools. But at the end of the day, what we are finding is, is it really requires subject matter experts to be able to--who understand how to find buffer overflows, how to find heap overflows, how to find--many of the techniques that hackers use to break into the systems. And what we find is, a lot of the approved testing labs don't have that expertise, to find these kinds of vulnerabilities; and from that perspective, we are not measuring whether the systems have those types of vulnerabilities. And I think if we can build a system that's measuring for ``can the security products find and identify attacks and stop them''--I think that's where Mary Anne Davidson was pointing out that security products need to get better at: on ``being evaluated,'' on ``can they identify the attacks?'' Just as important as identifying the attacks, it is almost more important for enterprises to make sure that we're also not identifying false positives. This is where we falsely see, say, legitimate traffic and identify it as, ``oh, here's an attack,'' but the minute you do that, you start cutting off real business transactions and so on, and then your security product is no longer trusted; or you turn off that functionality within the security product, and you are now less secure. And the other thing that needs to be tested is for invasion techniques. A lot of the known hacker community has published-- there's lots of white papers on how to evade many of the security products, and many of the security product vendors behind that have not responded to those techniques. They are still valid and still work. And there's no, I guess, in the certification process, anything that reflects how good they identify the attacks, the false positives, the invasion techniques; and I think, to answer another question, I think would be critical for security companies to be measured on is the effect of ``zero-day'' exploits. What I mean by zero-day is, when the worm comes out or a virus comes out, the most impact, full-time, is within the first 24 hours, in that it's spreading and nobody has protection. All of the security vendors are trying to respond to get the latest, ``What is that attack; OK, let's update our security products.'' There's a concept of--within the security industry that we're moving toward behavior-based security models, where I don't have to take a fingerprint of every virus, every worm. I'm actually looking at the behavior of that program so that if something tries to compromise a system and acts to propagate and format your hard drive and change your registries and other things on the system, those are all bad behaviors, and it gets flagged; and you could stop it without even knowing the--what was the virus before you saw it. And I think if we added some measurement to how good do security products deal with zero-day threats, all you have to do is test an old version--if it hasn't been updated, test against a new threat. Did it stop it? If it did, great, you get a point for that. If it didn't, you don't get a point and you can start measuring across a lot of security parts out there. Ms. Davidson. With all due respect, I think most of us believe in defense and depth and that security cannot be outsourced. If a vendor has a fault in their product, they cannot outsource the remedy for that, even to intrusion prevention. For example, the customer comes to me and says they found a fault in our software. I can't say to them, Do you have a fire wall? Do you have an intrusion prevention system? Because if you do, I won't fix it. They will have my head. So I have to get it right the first time anyway. And if I get it wrong, it will still cost me a million dollars to fix it if it's on every single version of product on every operating system. Everyone needs to write better code. In order to write better code, we need better tools. It's not just training, because developers are human; they make mistakes. One mistake and the hacker is in. Mr. Spafford. I wanted to add, we have mentioned that we need more research and tools. We need more personnel. This is an area where we have a very small pool of expertise. But one thing that would make a difference, I believe, is a matter of accountability. And the sentiment expressed by Ms. Davidson here has not been widespread enough within the industry, which is, if there is a problem in the code, then the people who wrote the code are held responsible. Currently, when the government buys systems, if they have a failure, then everybody rushes around and applies a patch and then goes on as if nothing else had happened until the next failure and the next patch. I really believe that if there's some negative feedback to the vendors involved, if they have a bad history of producing software that isn't reliable, then perhaps that should be figured into the next series of acquisitions. Perhaps there should be a penalty applied to some vendors if they consistently provide bad software. It's something worth considering because simply encouraging them by buying the next product cycle isn't resulting in the changes that we should be seeing. We are seeing vulnerabilities that have been known for 30 years to be security problems and bad practice; and we are discovering that 50 percent of all the vulnerabilities that are being reported today, 2 or 3 a week, are those bad practices that are 30 years old and that my colleagues and I teach in the very first few weeks for students to avoid. There should be something back at--a negative pressure to have them start paying attention to better practice. Mr. Clay. Thank the panel for their responses. Mr. Putnam. Could you give us an example of a 30-year-old vulnerability? Mr. Spafford. In the very introductory programing classes we teach, we tell the students they should check the inputs. For instance, if it's requested that a number be provided between 1 and 10, we ask them to check that the value is between 1 and 10. If they are asked to provide a character string that is 10 characters long, then they should check to make sure they aren't provided with one that is 11 characters or 1,000 characters. When we talk about buffer overflows or when you've heard that mentioned by the panelists, that's a case where a program was expecting 20 characters and was given 2,000 and there was no check made to see that too many characters were provided. That is something that has been known for 30 years to be a problem. It has been exploited in many systems. We teach against it, and it's still occurring and being discovered at the rate of several a month. Mr. Putnam. Ms. Davidson, Oracle began certifying products very early in 1998. What led you to come to that conclusion and how has it affected your business? Ms. Davidson. We initially began doing evaluations, actually the pre-Common Criteria days, we did the orange book and IT section evaluations. Actually, we did four of them at once on two of our products. We did that because one of our core customer constituencies demanded it; at least we thought they demanded it, as I testified previously. They would occasionally wuss on the procurement requirement--that's a technical term--but we kept doing them anyway. We thought it was important. We found the benefits for us were substantial for the reasons that I previously laid out. I feel actually the cultural values--making security part of a corporate culture has been the biggest value. I don't have discussions or arguments about, are we going to hold the release, because there's a security fault. Of course, we do that. This is something that we are measuring on and it is something we are held accountable on. We certainly are not perfect. We have developers who have committed the sin of buffer overflows or not checking input conditions, but I would consider myself to be successful if I could stomp buffer overflows in our time, but we need help to do this. We spend a lot of money training people. When I was in the Navy, there was an expression, ``To err is human; to forgive is not Navy policy.'' People do make mistakes in programming. If there are 21 conditions that have to be validated, our developer checks 20 of them, the hacker only needs to find that one. If complexity is the enemy of security, so are manual processes. The more that we can automate some of these checks in addition to training people and holding them accountable, the easier it will be for people to do the right thing. And right now it is really hard, because you are only as good as every single person checking every single possible programming condition; and they're not perfect, and they never will be perfect. It's been good for us as a business. And I don't think the Common Criteria is a solution for all security ills, but I think if people don't bake security into their development processes, however we get there--just checking air conditioners will also not make us secure; you need both. Mr. Putnam. How would you respond to the toaster metaphor? You know your company is committed to it, you follow through, you are believers in Common Criteria. Mr. Spafford and to a certain degree Mr. Klaus have laid out a series of arguments why it will not get us where we hope that it will. How do you respond to that? Ms. Davidson. I think it is a great analogy on a lot of levels. The other counter-argument is, if you glue all the pieces together, you may not get a secure house, but if you don't start off with a secure foundation, you certainly will not get a secure house. Yes, evaluations do not make for perfect conditions. But would you really want to plug your toaster in, even with the cord, and have no idea how strong the building foundations were, whether the engineers had done their jobs, whether they had building inspectors in. You need to do a lot of things to have secure software. I think evaluations are part of the answer because it will change the way people build software. It changed the way we build software. I think have better validation. If we had automated tools--most security faults are not faults in the security mechanisms; they are as a result of bad programming. If you have better automated checks for good programming practice, you also will be able to add a level of robustness. And the third piece I mentioned earlier is, many vendors, despite our best efforts, don't deliver products that are secure enough out of the box. We give our customers long lists of things to do and to tweak to become secure. And most system administrators never have enough hours in the day to do that. You have to make it easy for people. You have to install your product so that ideally people don't have to do anything-- like the Cuisinart--to have it operate securely. If you do that, it not only lowers people-cost-of-operation and increases their security, I think you will get resistance to some viruses and worms that typically exploit lots of things that are left wide open on your system, or things that are left lying around in your system because a vendor shipped it and the customer didn't know how to secure it. Common Criteria is a strong necessity, but I would agree it is not sufficient. Mr. Klaus. I think from the house perspective, if you look at how--I just went through the process of finishing a house. The certification process and compliance is typically at the end of the process. You have the government come out and look at the house and make sure it's up to code and you meet that criteria, or for a building or for--you are looking at the, at the very end, did the House meet all the necessary standards. And some of the important--and it's looking for the critical issues. Are sprinklers in place, etc. What you don't see in the certification process--and this is where I think we are failing--is, the opposite is happening in the Common Criteria where if you had a document--as the architect, the designer of the house had to sit there and as it goes through the process add another year--I mean, it took a long enough time to finish the house. If you add another year to building the house, to make sure that everything was documented, and here was all--I trust my architect to make sure it's designed to be built strongly. The government shouldn't have to go in there and say, did you use all the metrics to make sure it's going to stand, and then at the end the government checks to makes sure the most important issues are addressed and certified. And to the extent--if we could move the Common Criteria more to, did the important issues get addressed? And I think you could look at it, hey, a lot of these applications, especially business applications, are very complex. Many ways--many lines of code, etc. But if you actually identify what are the most common ways that hackers, worms, viruses hack into a system, the majority of the risk is at the network protocol code. You know, if you look at, why did Blaster get into the operating system, well, it was because there was an RPC service running on every Windows box that had this vulnerability. You can say there's millions and millions and millions of lines of code within operating systems and these business applications, but the most important thing is to look at, what are the things that are exposed at the network level? That tremendously reduces what you have to evaluate. We do a lot of security penetration tests, a lot of security assessments trying to figure out how would a hacker break into a system, and we always start at the network layer. And I think if the certification process looked more at--the same way that the hackers, the worms and viruses looked at, how does somebody break into the system, you'd start saying, OK, do you want to check the doors and the windows? You don't want to--I mean, you don't try to evaluate every wall and floor, the whole house. You evaluate the areas that hackers get into. And that's kind of intuitive, but if we focused on the bigger issues measuring whether you have a good security product or not; less on, did the overall process get followed, because right now it's not helping us find the buffer overflows and other things within the product at the end of this certification process. Mr. Putnam. Dr. Spafford, you started this metaphor, and I would ask for you to talk a little bit about what the better alternative is. Software assurance, how do we get there if it's not Common Criteria? Mr. Spafford. I didn't mean my comments to mean that Common Criteria is not a value, because I believe it is. It provides guidance as to how go about building a quality product. But it's building that quality product that is the key to what we are talking about. It's not simply a matter of security. We want to have greater trust in our systems, but we also want it to be reliable in the face of failure, unexpected circumstances. It appears, for instance, that the blackout that occurred in the East Coast was as a result of unfortunate circumstances happening at once, without sufficient capacity and reserve to make up for the failure. We don't want that to occur with our computer systems either. That means going back and looking at fundamental assumptions that are made on how we build the systems. What are the features that we really want? How is it being built? Is it being built using good tools and by people who understand the technology? Are they putting in more features than are really necessary, which I believe is the root cause of a number of the problems that we see. Is the documentation in the interface? Are those two items put together in such a way that the average user is able to understand how to use the system and how to configure it? Again, I do not believe that is the case. The average user currently is very often someone at home who doesn't understand what a firewall is or a virus is or what it means to have their system connected all the time. Then we have to have better testing tools and some known reasons to test, some known test sets to work against. We have to be able to test in real environments, so that if we are going to deploy something in a large-scale system, we have to have testbeds to do that; and again, we have to have the people trained to do that. And last of all, we have to have a mechanism so that we understand if we need to apply the technology to new arenas, how we go about going back in the process and changing the technology rather than simply reusing the old technology because that's what we have a large investment in. We should be using the most appropriate tools for the tasks at hand. What has happened over the last 30 years for computing, if we look, there's been incredible strides from mainframes and small networks to where we are now with global, international activity with our systems. We don't even know where some of our software comes from because of the international trade and development that goes on. We spent those 30 years trying to make the technology work, and I think we have done a really admirable job of that. So much of our society, so much of our dominance in the world has come about through our ability to create good technology. But now we have to change our mind-set to think about how to most appropriately use that technology and how to make it safe, and that means really taking a step forward, leaving behind some of the technologies of the past. So again, to summarize, it's not a simple step. It's going to be a whole number of steps throughout the life cycle of building and designing software. And to revisit Mr. Klaus' comments about the architect, well, the architect has been through many years of professional training. They probably served an apprenticeship with a master architect to understand what they're doing. And if they have designed his house, and it ends up getting built and there's no doors and it collapses afterwards, he has some recourse. And it's possible that architect will not be able to sell a design again in the future. We haven't done that in the software arena. We need to start thinking in terms of how we're going to protect our future. Are we going to continue to reward bad performance? So it's a long answer--I apologize--but it's a very multifaceted problem. Mr. Putnam. The $64,000 question: Should we expand Common Criteria to civilian agencies? Mr. Spafford. I believe that, on balance, that should not be mandatory. As a voluntary step, it may be good, but mandatory, it will not solve the basic problems. There are certified products that won't work as required. The process is not easy to understand. The Common Criteria standard document is 700 pages long, and so many of the people are going to be buying and deploying these systems who won't understand what the certification means, which is why I used the analogy of the toaster. The average consumer won't understand what that means. It can help to get some vendors to pay more attention, but I believe that the additional overhead, time and costs that were discussed by the other panelists are probably counterproductive to government's needs. I believe there are other steps that should be taken first. Mr. Klaus. My answer would be, until the, at least the 3 years we talked about, better measurement of what you are trying to do with the Common Criteria is met, meaning, is this product actually providing better protection against the known threats and making process later, because if it takes a year to get our products out the door to help the government, they're going to be a year behind the commercial sector. And the cost of it is--I think overall, the cost is expensive, so startups have--will have a hard time entering into the government sector. But most importantly, if the cost was moving toward making the products better, I'd be in favor of it. Today there's very little value in what it is today. Mr. Putnam. Ms. Davidson. Ms. Davidson. If it's not too expensive and doesn't take too long to do. With all due respect to Mr. Klaus' company and their fine products, we have more complex products. We get certificates out within 6 months of the production release, and we release major versions of product every year to 18 months. It is cheap compared with the alternative. We are already paying for bad security. I believe that it should be extended at least--clearly, to entities who have a national security focus. And if the Department of Homeland Security is not doing national security, what is it that they're doing? As I mentioned earlier, there are other things we can do, but unless we fundamentally, as an industry, change the way that we build product, nothing will ever change. And this is the government's last chance on this. If we abandon information assurance efforts and go only to a testing approach, you will never know whether someone developed good product. Testing alone, while I think an important add-on on top of Common Criteria evaluations, also will not solve the problem. Mr. Thompson. I think I agree with Gene that we have to encourage good software development, good software design, and encourage companies to develop products that are safe in the beginning; and not just throw them on the market and let the rest of the world find the bugs one at a time or let the hackers find the bugs. They need to produce good software and need to be held accountable when they don't. And the Common Criteria approach to evaluation encourages vendors to do that. It is not designed to find bugs in a particular release of a product, but designed to encourage vendors to use good software and build that house according to good architectural principles in the beginning and not to find, you know, where the beams have been left out or where the small beams were used. Expanding the market for evaluated products would encourage that, send a signal to industry that the government is serious about good software engineering and development; and the products should be, you know, secure from the get-go. And anything you can do to allow--make vendors accountable to their--for putting out bad software would further the government's ability to buy good software. Everyone would have better software available if vendors were held accountable. Mr. Putnam. Thank you, Mr. Thompson. I want to thank all of our witnesses today, particularly the second panel, for their efforts in helping us to better understand this very complicated issue. Gaining assurance that the software the government buys to protect itself actually can do the job is an important goal. I also want to thank Mr. Clay and Ms. Watson for their participation. In the event that there may be additional questions that we did not have time for, the record shall remain open for 2 weeks for submitted questions and answers. With that, the subcommittee stands adjourned. [Whereupon, at 12:15 p.m., the subcommittee was adjourned.]