[House Hearing, 108 Congress]
[From the U.S. Government Publishing Office]




 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.]

