Raymond G. Kammer



Director



National Institute of Standards and Technology



U.S. Department of Commerce







Before the





House Science Subcommittee on Technology









June 24, 1999





Good morning Madam Chairwoman and members of the Subcommittee. I am Ray Kammer, Director of the National Institute of Standards and Technology in the Department of Commerce. Thank you for inviting me here today to testify about the implementation of the Computer Security Act and, more specifically, about the security of Federal web sites. NIST has important responsibilities to assist Federal agencies in the protection of sensitive unclassified systems by developing and promulgating security standards and guidelines. This is in addition to our mission of strengthening the U.S. economy--including improving the competitiveness of America's information technology (IT) industry. I briefly discussed these issues with you in testimony in April on the Melissa computer virus.



At NIST, the Computer Security Division of the Information Technology Laboratory (ITL) focuses exclusively on security issues; however, given that needs for security are pandemic, other components of ITL also carry out security related tasks. The Computer Security Division uses its approximately $5 million dollars of direct Congressional funding both to support Federal agencies with standards and guidelines and to support competitiveness of the American IT industry. In addition, we receive approximately $3 million in outside agency funding to advise specific agencies and to help them apply security technology. I mention this because it is important to maintain expectations of our program that are reasonably consistent with its size. Our computer security program focuses on a few key areas: cryptographic standards and guidelines; public key infrastructure; security research, agency assistance and the National Information Assurance Partnership which is jointly managed by NIST and the National Security Agency to focus on increasing the number and quality of IT security products.



Our Federal responsibilities, as assigned in the Computer Security Act (P.L. 100-235), focus on "developing technical, management, physical, and administrative standards and guidelines for the cost-effective security and privacy of sensitive information in Federal computer systems." For example, NIST has recently published updated guidelines for the training of employees in computer security. NIST also sets security cryptographic standards for Federal agencies. We support these standards by operating a conformance testing program that enables agencies to have confidence that cryptographic security products meet government standards. NIST's standards, guidelines, and other products and services assist agencies in implementing their computer security programs as required by Office of Management and Budget (OMB) Circular A-130, Appendix III, "Security of Federal Automated Information Resources." Detailed information about our work products is available electronically at our Computer Security Resource Clearinghouse (http://csrc.nist.gov). Among other publications, NIST's ITL publishes bulletins which provide timely, up-to-date, information on significant security issues. The May 1999 ITL Bulletin on computer attacks and prevention measures is particularly timely. I encourage all agencies to make use of all the guidance available from the Clearinghouse.



I commend the Committee for its continuing interest in computer security, and particularly on the security of web sites. As security is one of those topics that can quickly disappear from the management radar screen, the Administration has sought to reemphasize the importance of securing Federal IT systems. Today's hearings serve as yet another reminder to managers of their responsibilities for, and the seriousness of, security.



Although we are focusing specifically on web site security today, I encourage everyone to take a wide view of what needs to be done to obtain effective computer security. Security is much more than just protecting against the "computer attack du jour." A few months ago we met in this room to address the risks from the Melissa computer virus. Today, we are looking at the problem of web site intrusions. Next month there may well be another attack making the headlines. While we must respond to the most recent technical attacks, we must also step back and ensure that we have effective processes in place to resist future technical attacks and address newly discovered vulnerabilities. The OMB guidance that I mentioned earlier makes clear that agencies must have a process in place so that when a warning of a particular attack is distributed, there is an institutionalized process in place to take the appropriate corrective action.



The fundamental principle is that agencies must take a comprehensive view of computer security. This means that necessary security programs supported by appropriate funding must be in place at the agency, program, and system levels. Controls must be selected, effectively implemented, and maintained. First there must be managerial controls, such as threat analysis, risk management and life cycle planning. Second, operational controls such as personnel security, contingency and disaster planning, incident handling, and training and awareness are also required. Finally, there are the important technical components, such as identification and authentication, logical access controls, audit trails, and cryptography. Sometimes when IT managers focus on technical controls, they forget the need for the essential complementary operational and managerial controls.



The comprehensive view of security must extend throughout the system life-cycle of both specific applications and supporting technology systems. We cannot ignore the often stated fact: planning for security during system design is more effective and less costly than attempting to retro-fit security once a system is operational. In the future, we expect to use systems built to be secure. In fact, this might be the only way to implement cost-effective security.



Today's topic, the security of Federal web sites, might be puzzling to creatures arriving from Mars or Venus. After all, isn't information placed on public web sites to be freely available? Information placed on web sites should have been reviewed and therefore can be presumed to be suitable for public disclosure. In reality, however, security involves more than the protection of confidentiality. It also protects integrity and availability of both information and services. Failure to protect confidentiality, integrity, and availability will reduce public confidence in agencies and in the government's ability to carry out its responsibilities in a competent manner. Citizens rely increasingly upon the ready availability of web-based information and services, including direct government/citizen interactions in the provision of government services. Citizens rely upon the integrity of information placed on web sites. For example, they assume that if they download a tax table, the figures it contains are correct. When looked at from this perspective, in some ways we are fortunate that, to date, corrupted web sites have been easy to identify. A corrupted web site where only very limited information, such as a few figures in a tax table, has been modified would be far harder to detect. This kind of intrusion could cause quite a bit of frustration for both tax payers and the tax administration authorities.



Additionally, even though web sites contain files intended for public dissemination, they also contain system management tools and other information not intended for public access. However, these often become available to hackers during a break-in. Also, when networks are poorly constructed, compromised web sites have served as springboards to attack other parts of an organization.  Thus, when facilitated by improper architecture and management, penetrated web sites may represent open doors to an organization's networks and more sensitive data.



Let me give a bit of context to the technological issues facing us as we try to address the threats to our web sites.



There exists a high degree of homogeneity of software, especially among operating systems and web servers, and there is an increasing demand for connectivity despite the security risks. Our society insists on sharing not only data, but also actual code on a regular basis across the Internet. People want increased automation of manual tasks, they want to use familiar software, and they want to communicate seamlessly with others on the Internet. These demands for new and exciting features unfortunately cause security complications leading to vulnerable systems. Let me state parenthetically that the pace of IT innovation in the private sector has brought us far more benefits than the risks and costs we are talking about today. While, it is important that we address these risks and costs it is equally important to keep a balanced perspective, especially as we expand into areas such as electronic commerce.



When these societal demands are coupled with the very tight time-to-market and cost pressures experienced by software developers, very powerful and useful software is developed that unfortunately sometimes lacks needed security. Powerful macro code (small software programs) that can be embedded into data sometimes can be subverted. E-mail systems can do great damage when driven by malicious code. Web sites have complex, and thus often vulnerable, interfaces. Technical advances bring new risks to enterprises. A few years back, viruses spread physically through floppy disks. Now, viruses spread across the world in a matter of hours through the use of e-mail attachments and macros. In addition, the increasing complexity of the operating systems, networked environments, and applications make the system administrator's job that much more difficult. It is a daunting task for IT vendors to both provide all the features customers demand (low-cost, sharing, full-featured, and easy global access and administration) and deliver high-grade security in today's fast time-to-market environment.



Now let me describe a bit of how we see the threat picture. While there is often a great degree of hyperbole in attack statistics, the threats are serious.

Here is the reality we face:



· Attack information is available to the public;



· Secure system administration skills and abilities are scarce;



· Attackers have a natural advantage;



· Software continues to contain vulnerabilities; and



· Federal web sites are high profile targets and in some ways are naturally vulnerable to attack.



Let me elaborate. First, many web sites exist that contain hundreds of computer attack tools; many of them are automated. Many attacks are so simple that typing a URL or address can launch them. Second, the ability to securely administer a network is a scarce skill that is not always understood or appreciated. The typical Federal systems administrator does not have the skills he or she needs. Third, attackers need only find one way into a system while the defender or system administrator must typically find and block nearly all of the ways into their systems. In fact, software exists that will automatically scan systems in order to find the parts that are vulnerable. Fourth, as I said earlier, modern IT systems are extraordinarily complex and contain many flaws. These flaws do not normally hinder operation but do provide exploitable holes for attackers. Fifth, compromising a Federal web site gains one intense media exposure, which makes them high profile targets for those wishing to embarrass or discredit our government. There are many attackers around the world with the motivation to penetrate our web servers.



Federal agencies' web server security is sometimes lax because public web servers typically contain only public data and sit outside of more important networks. Combined with the fact that new vulnerabilities are being discovered continuously, it is not unexpected that Federal web servers are being successfully penetrated.



Attackers can easily find automated computer attack weapons. Typing the words "attack exploit script" into major search engines often yields references to web sites containing hundreds of computer attacks. One popular site has over 400,000 unique visitors per month downloading attacks. We estimate that at least 30 computer attack tools per month are written and published on the Internet. NIST analyzed 237 computer attack tools published on the Internet in 1998 that performed a variety of malicious actions like remotely controlling computer systems, often including shutting them down. Thirteen of these specifically attack web servers. Four vulnerabilities published since last summer apply to the second most popular web server.



These attack tools are especially effective when first announced because the installed software has not yet been fixed to resist the attack. Recently, an attack was publicly distributed that automatically penetrated the second most popular web server software. Overnight, this rendered a major portion of the 1.3 million web servers that use this software vulnerable to complete control by attackers on the Internet. It often takes hours or days before a software fix to an attack is announced and days or weeks before all web sites are updated. Even the best systems administrator can not counter this kind of threat alone. It is important that we test and evaluate the integrity of important software like web servers before its installation.



Besides the problems found with vulnerable server software, attackers can overwhelm web servers with requests in order to bring them to a halt. These are called denial of service attacks, and they are common. One agency's homepage was recently hit with this type of attack and was unavailable for over 6 days. An attacker does not actually have to enter a site but can disable it by overwhelming available resources. Thirty percent of our 237 sampled attacks from 1998 were remote denial of service attacks. An attacker can launch these attacks even against a perfectly implemented web server. An additional problem related to these attacks is that many of them are difficult to trace and can be launched for days at a time before the attacker is identified.



This problem with Federal web servers is symptomatic of two endemic problems with computer systems. First, software is error-prone because of its complexity. Second, software is often improperly configured resulting in security holes. We can mitigate the effects of error prone software and solve the problem of mis-configured software by:

1. Purchasing independently tested and evaluated software for critical systems;

2. Creating a nationally accredited process for testing and evaluating software;

3. Training systems administrators how to securely configure critical systems and to quickly apply appropriate software fixes;

4. Hiring security specialists who will work with systems administrators to secure our networks and install and monitor security tools; and

5. Promoting research on how to create secure systems.

NIST is working in various ways to help government agencies implement these solutions. The National Information Assurance Partnership (NIAP), a joint project with the NSA, has helped to create an international standard for specifying security requirements in IT products and evaluating them to that specification. Various technologies are currently under evaluation. Recently, with NSA, firewalls from three major vendors representing more than 50 percent of the firewall market share were tested and evaluated against a set of NIST/NSA developed-security requirements. Our Cryptographic Module Validation Program has created a method by which to test cryptographic modules in software. NIST oversees the testing by private sector laboratories and has approved more than 50 such modules. Agencies are coming to recognize the value of using trusted products.

Besides promoting software evaluation, NIST has actively promoted giving agencies the ability to quickly respond to attacks. To do this, in 1996 NIST created the Federal Civilian Incident Response Capability (FedCIRC), a joint effort with two existing incident handling teams, with funding from the Government Information Technology Services Working Group. The two-year pilot was successful. FedCIRC has transitioned from NIST to GSA which uses the technical services of the Computer Emergency Response Team at Carnegie-Mellon University. In FY 1997/98, FedCIRC (while still run by NIST) handled 1927 incidents, held 22 workshops, issued 195 security advisories, and trained more than 1600 people in incident handling and web security. FedCIRC continues to issue advisories. It works closely with the National Infrastructure Protection Center and remains an important asset for the coordinating and dealing with these recent attacks.

Additionally, we have developed documents on how to write security plans and policies, IT security-training requirements, Internet security guidance, implementing security with firewalls, and incident handling guidance. With NSA, we run one of the largest computer security conferences in the world, attracting between 1500 and 2000 attendees. Our security web site, called the Computer Security Resource Clearinghouse, accounts for some 25 percent of all the general web traffic at NIST. We have published some 23 IT security bulletins since 1996. We sponsor both the Federal Information System Security Educators Association and the Federal Computer Security Manager's Forum. We work closely with both organizations on projects such as a comprehensive security training web-based repository, and we have sponsored training for both groups on web security and testing networks for security vulnerabilities. We have encouraged the private sector to conduct security training at NIST for the Federal sector. By the end of this year, we will have hosted more than thirty-five training classes in the past two years. In addition, we have given presentations to Federal personnel by those who have been victimized by web attacks to speak about lessons learned.

There are many other NIST research and development efforts that address securing our systems against attacks. We have an active R&D and testing capability which energetically works with the public and private sectors in intrusion detection, access control, public key infrastructure, digital signatures, authentication, telecommunication switch security, and smart cards to name a few. Finally, we are developing the Advanced Encryption Standard that will provide strong cryptographic protection well into the next century.



NIST also has worked with officials at OMB to develop guidance to agencies regarding intentional disruptions in web site service. OMB is asking agencies to conduct a review of their security practices to ensure that a process is in place for program officials and security managers to understand the risk to their systems and take necessary measures to mitigate that risk to acceptable levels. This process should include specific procedures to ensure the timely implementation of security patches for known vulnerabilities, especially for those systems which are accessible via the Internet. We support OMB's actions to remind agencies of these important security responsibilities.



Finally, let me close with some general recommendations for securing our networks, most of which are contained in a recent bulletin we issued. Security risk management, planning, training, and budgeting are critical, and must be addressed by all agencies.



1. Agencies need to develop and implement security policies and architectures consistent with their agency mission.

2. Agencies need to embrace the obvious solutions such as patching their systems with the current security patches, taking action consistent with security advisories, deploying virus detection tools, firewalls, intrusion detection software, and vulnerability scanners.

3. Agencies should test their own systems continuously.

4. Agencies should configure their systems with security in mind.

5. Agencies should buy security technology that has been evaluated and tested by an independent party.

6. Despite limited IT budgets, agencies must support security.



I want to thank you again for the opportunity to speak before the Committee.



We look forward to working with you and others in the Congress on these important issues.