[House Hearing, 107 Congress] [From the U.S. Government Publishing Office] HOW SECURE IS PRIVATE MEDICAL INFORMATION? A REVIEW OF COMPUTER SECURITY AT THE HEALTH CARE FINANCING ADMINISTRATION AND ITS MEDICARE CONTRACTORS ======================================================================= HEARING before the SUBCOMMITTEE ON OVERSIGHT AND INVESTIGATIONS of the COMMITTEE ON ENERGY AND COMMERCE HOUSE OF REPRESENTATIVES ONE HUNDRED SEVENTH CONGRESS FIRST SESSION __________ MAY 23, 2001 __________ Serial No. 107-29 __________ Printed for the use of the Committee on Energy and Commerce Available via the World Wide Web: http://www.access.gpo.gov/congress/ house __________ U.S. GOVERNMENT PRINTING OFFICE 72-833 WASHINGTON : 2001 _______________________________________________________________________ For Sale by the Superintendent of Documents, U.S. Government Printing Office Internet: bookstore.gpr.gov Phone: toll free (866) 512-1800; (202) 512�091800 Fax: (202) 512�092250 Mail: Stop SSOP, Washington, DC 20402�090001 COMMITTEE ON ENERGY AND COMMERCE W.J. ``BILLY'' TAUZIN, Louisiana, Chairman MICHAEL BILIRAKIS, Florida JOHN D. DINGELL, Michigan JOE BARTON, Texas HENRY A. WAXMAN, California FRED UPTON, Michigan EDWARD J. MARKEY, Massachusetts CLIFF STEARNS, Florida RALPH M. HALL, Texas PAUL E. GILLMOR, Ohio RICK BOUCHER, Virginia JAMES C. GREENWOOD, Pennsylvania EDOLPHUS TOWNS, New York CHRISTOPHER COX, California FRANK PALLONE, Jr., New Jersey NATHAN DEAL, Georgia SHERROD BROWN, Ohio STEVE LARGENT, Oklahoma BART GORDON, Tennessee RICHARD BURR, North Carolina PETER DEUTSCH, Florida ED WHITFIELD, Kentucky BOBBY L. RUSH, Illinois GREG GANSKE, Iowa ANNA G. ESHOO, California CHARLIE NORWOOD, Georgia BART STUPAK, Michigan BARBARA CUBIN, Wyoming ELIOT L. ENGEL, New York JOHN SHIMKUS, Illinois TOM SAWYER, Ohio HEATHER WILSON, New Mexico ALBERT R. WYNN, Maryland JOHN B. SHADEGG, Arizona GENE GREEN, Texas CHARLES ``CHIP'' PICKERING, KAREN McCARTHY, Missouri Mississippi TED STRICKLAND, Ohio VITO FOSSELLA, New York DIANA DeGETTE, Colorado ROY BLUNT, Missouri THOMAS M. BARRETT, Wisconsin TOM DAVIS, Virginia BILL LUTHER, Minnesota ED BRYANT, Tennessee LOIS CAPPS, California ROBERT L. EHRLICH, Jr., Maryland MICHAEL F. DOYLE, Pennsylvania STEVE BUYER, Indiana CHRISTOPHER JOHN, Louisiana GEORGE RADANOVICH, California JANE HARMAN, California CHARLES F. BASS, New Hampshire JOSEPH R. PITTS, Pennsylvania MARY BONO, California GREG WALDEN, Oregon LEE TERRY, Nebraska David V. Marventano, Staff Director James D. Barnette, General Counsel Reid P.F. Stuntz, Minority Staff Director and Chief Counsel ______ Subcommittee on Oversight and Investigations JAMES C. GREENWOOD, Pennsylvania, Chairman MICHAEL BILIRAKIS, Florida PETER DEUTSCH, Florida CLIFF STEARNS, Florida BART STUPAK, Michigan PAUL E. GILLMOR, Ohio TED STRICKLAND, Ohio STEVE LARGENT, Oklahoma DIANA DeGETTE, Colorado RICHARD BURR, North Carolina CHRISTOPHER JOHN, Louisiana ED WHITFIELD, Kentucky BOBBY L. RUSH, Illinois Vice Chairman JOHN D. DINGELL, Michigan, CHARLES F. BASS, New Hampshire (Ex Officio) W.J. ``BILLY'' TAUZIN, Louisiana (Ex Officio) (ii) C O N T E N T S __________ Page Testimony of: Adair, Jared, Acting Chief Information Officer, Health Care Financing Administration, accompanied by John Van Walker, Senior Advisor for Technology to CIO and Julie Boughn, Director, Division of HCFA Enterprise Standards............ 9 Neuman, Michael, President and Lead Programmer, En Garde Systems, Incorporated...................................... 18 Vengrin, Joseph E., Assistant Inspector General for Audit Operations and Financial Statement Activities, accompanied by Ed Meyers, Director, Information Technology Systems, Office of Inspector General................................ 13 Material submitted for the record: Documents referenced during hearing.......................... 40 (iii) HOW SECURE IS PRIVATE MEDICAL INFORMATION? A REVIEW OF COMPUTER SECURITY AT THE HEALTH CARE FINANCING ADMINISTRATION AND ITS MEDICARE CONTRACTORS ---------- WEDNESDAY, MAY 23, 2001 House of Representatives, Committee on Energy and Commerce, Subcommittee on Oversight and Investigations, Washington, DC. The subcommittee met, pursuant to notice, at 10 a.m. in room 2322, Rayburn House Office Building, Hon. James C. Greenwood (chairman) presiding. Members present: Representatives Greenwood, Whitfield, and Tauzin (ex efficio). Staff present: Amit Sachdev, majority counsel; Tom Dilenge, majority counsel; Gary Dionne, Congressional Fellow; Peter Kielty, legislative clerk; and Edith Holleman, minority counsel. Mr. Greenwood. Good morning. I am James Greenwood, chairman of the subcommittee, and I apologize to our witnesses and to the rest of you for the delay. The chairman of the full committee, Mr. Tauzin, would like to join us. As if often the case, another subcommittee is having a hearing, and he is giving his opening statement at that hearing and should be with us in a few minutes. So if you will--just ask your forbearance for another few minutes, we will commence then. [Brief recess.] Mr. Greenwood. Well, we are informed that the chairman is on his way, so we will begin. Our hearing will come to order. Good morning. When Americans think about the future, their greatest concern, according to a recent Wall Street Journal/NBC News survey, is protecting their privacy. What is particularly interesting about this discovery is that America's concern for privacy is greater than concerns about such critical issues as overpopulation, global warming, and even nuclear war. And when it comes to the privacy of health data the findings are even more startling. Another recent survey has found that one in five Americans believes his health data has been used inappropriately. And one in six have altered their behavior to avoid the misuse of information, even to the point of avoiding necessary medical care. If we are to address the nagging concerns of our fellow citizens with regard to the privacy of their medical records, then our standards must be very high indeed. Like Caesar's wife, the security of our Nation's private health records must be above suspicion. It is in the light of these and some disturbing findings that we, in this subcommittee, gathered today to examine this issue, particularly as it affects the tens of millions of elderly and disabled Americans who rely on the Federal Medicare Program. The question posed today is how secure is the very sensitive and private medical information gathered by the Health Care Financing Administration, better known as HCFA, and its dozens of fiscal intermediaries and carriers who process literally billions of Medicare claims every year? To begin to answer this question, several months ago I requested that HCFA provide this subcommittee with information and documentation relating to computer security, including all penetration tests or vulnerability audits that have been conducted on its various networks in the past 5 years. Committee staff also met with senior managers at HCFA on a number of occasions since then to review the information provided and to ask follow-up questions. Before discussing our findings, I want to start by providing some important background and context. HCFA processes and pays more than $170 billion annually in claims for Medicare health benefits, using a large and complex computer network that links health providers, such as nursing homes and hospitals, with billing clearinghouses, fiscal intermediaries, and carriers. Using a private dial-up telecommunications network provided by AT&T, and provided by IBM prior to mid-1999, known as the Medicare Data Communications Network, or MDCN, Medicare contractors process standard Medicare claims that contain personally identifiable medical information, such as names, addresses, treatment, and diagnosis codes and payment and insurance data. This sensitive information traverses the MDCN in order to be linked with necessary data bases of information contained by HCFA and its contractors, including beneficiary claim histories, eligibility data, such as social security numbers, and other information stored in HCFA's Common Working File, known as CWF. This computing network has over 75,000 authorized users. And while it is a private-line network, it has connectivity with other HCFA systems that are accessible via the Internet. In addition, AT&T uses this private-line network to provide similar services to roughly 35,000 customers worldwide, including banks, insurance companies, health care companies, and other Government agencies. Much of what we have learned so far is good news. Compared to many of its fellow agencies in the Federal Government, HCFA has taken a much more proactive approach to cyber security, particularly in the last 2 years. HCFA has conducted numerous tests of its own systems, including penetration tests from both inside and outside of the network. HCFA generally has limited its Internet connections to reduce the possibility of outside attack, and last year reconfigured those connections to further minimize the chance of unauthorized intrusions after a team of hired experts successfully penetrated its so-called secure network via the Internet. HCFA also is in the process of upgrading its internal systems to reduce the systemic vulnerabilities in its desktop operations, which should be complete by the end of this fiscal year. Moreover, HCFA recently embarked upon an initiative to review and upgrade the security of its Medicare contractors to ensure compliance with current Federal requirements, something that has not been done in a comprehensive manner in a very long time. The subcommittee has just begun to look at these contractor systems and will continue to monitor HCFA's efforts to improve their overall security. I also should point out that the new Secretary of the Department of Health and Human Services has made improved computer security at HCFA a top priority and has proposed a new $30 million fund to help pay for it. HCFA and several of its Medicare contractors also have reported to this committee that they are unaware of any significant intrusions into their systems by unauthorized individuals, which is surely good news, although it is important to keep in mind that there could have been intrusions that went undetected, as was the case with several of the intrusions perpetrated by the ethical hackers hired by HCFA and the Inspector General, which we will talk about today. The news, however, is not all good. Audit after audit, even the most recent, continue to reveal significant computer security problems at HCFA and its Medicare contractors, vulnerabilities that continue to place personally identifiable medical information at risk of unauthorized access, disclosure, misuse or destruction. While much has been done to limit the possibility of the truly outside attack by the World Wide Web, this threat still exists, as several of our witnesses today will describe. For example, in 1999, HCFA issued a contract to En Garde Systems to conduct ethical hacking in the form of external penetration tests to determine whether the MDCN was secure from attacks from hackers on the Internet. I am pleased that En Garde Systems is before the subcommittee today as a witness, and I am releasing a redacted version of the 1999 test results. In that test, En Garde was easily able to exploit a vulnerability in HCFA's web site to get access to the MDCN and then HCFA's internal computer network. This was rightly viewed as a serious security breach, and at that time En Garde recommended that HCFA reconfigure its computers to discontinue the linkage between the Internet and the secured, private MDCN, the connection that HCFA used to load information onto its web sites. While HCFA made some changes to address this vulnerability at that time, the agency did not follow through on the major En Garde recommendation until pressed by this committee, informing us just yesterday that it has disconnected this particular Internet connection. While that certainly is progress, still more must be done to reduce the risks imposed by external sources. In addition, the threat from internal sources is great and includes the 75,000 employees of HCFA, its contractors, and certain nursing homes that have authorized access to the Medicare Transaction Network. More must be done and soon to minimize this risk as well. HCFA must improve the basics of security management. It lacks complete security plans, risk assessments, and accreditations for many of its major systems and applications. It fails to enforce strong passwords through the use of available automated tools and fails to block its own employees from downloading Internet hacker tools that could be used to exploit the known vulnerabilities in its internal systems, as two separate auditors did in tests conducted over the past year. I was pleased to learn just yesterday that the Department of Health and Human Services, which oversees HCFA, plans to issue for comment a new policy shortly, at our urging, that will require its operating divisions to regularly scan their systems for weak passwords, something that CDC, for example, already has been doing but that HCFA does not currently do. HCFA has also failed, in my opinion, to implement an adequate testing regime to ensure the security of the Medicare system. While many audits and penetration tests have been done over the years, the restrictions imposed by HCFA on both the scope and nature of these tests limit their overall effectiveness in evaluating the real security posture of the agency's various systems and networks. For example, ever since a 1997 penetration test conducted by the IG's auditors resulted in the penetration of HCFA's mainframe in the altering of Medicare payment information, HCFA has refused to permit the IG's auditors to conduct similar in- depth testing. In addition, HCFA oftentimes has been slow to implement needed corrective actions following poor test results, and has not consistently tested the efficacy of the corrective actions once implemented. HCFA also needs to do a better job overseeing its Medicare contractors, as well as those contractors such as IBM and AT&T that provide critical network services utilized by HCFA and its business partners. For too long, it would appear, HCFA has allowed these contractors to essentially assess themselves without sufficiently rigorous independent testing. The committee's review has found only one set of penetration tests ordered by HCFA back in 1998 and covering just four of HCFA's more than 55 Medicare contractors. Since that time, and despite some significant findings, HCFA has not conducted further tests of its contractors, leaving that task to the Department's Office of Inspector General, which conducts annual assessments of financial controls at HCFA and its major Medicare contractors. But these IG audits, as the IG notes in its testimony today, are fairly low-level tests due to restrictions imposed upon them and are not meant to really test the adequacy of computer security. Even so, in every year since 1996, the IG has identified computer security controls to be a, ``material weakness'' at both HCFA's Central Office and its Medicare contractors. HCFA either needs to step up its own testing of these contractors or work to ensure that the IG is permitted to conduct full-scale testing of these contractor systems. I am also concerned that HCFA has not yet insisted that AT&T and IBM, which respectively run the private network upon which the MDCN runs and the HCFA web servers, agree to a thorough testing of the interconnectivity between these networks, HCFA, and the Internet and between the more than 35,000 AT&T customers that utilize the private network in addition to HCFA. Clearly, HCFA has dragged its feet when it comes to assuring the security of these systems. Back in 1998, En Garde Systems sensibly recommended that HCFA conduct several distinct tests of those systems to evaluate their security given the incredible trust HCFA places upon them. Two and a half years later, only one of these tests has been conducted, and despite identifying serious problems, no further testing has been done. As the committee found, neither HCFA nor AT&T has yet tested the security of the MDCN to determine whether one HCFA partner could gain unauthorized access to HCFA internal systems via the MDCN connection or whether one of AT&T's 35,000 other customers that utilize this same network could do the same. Oral assurances are one thing, test results are another. So how secure is confidential and personal Medicare information? Clearly, it is not secure enough. While HCFA is to be commended on its success in making its data more secure than many other types of sensitive data collected by the Federal Government, it is less secure than it can or should be. Accordingly, today I call upon HCFA to take the following actions: One, HCFA must step up its efforts to implement the outstanding corrective actions necessary to address known vulnerabilities in its own systems; two, HCFA must demand that its contractors submit to independent testing of their systems, including those test of the AT&T and IBM networks that were recommended more than 2\1/2\ years ago; three, HCFA must aggressively carry out its plan to review and upgrade the security of its Medicare contractors and be prepared to fund needed corrective actions; four, HCFA must build into its security management a more regular and vigorous process of scanning its networks for vulnerabilities, improve configurations, and weak passwords; and five, HCFA must quickly evaluate the security of its remote access and dial-up capabilities and enhance that security where necessary. I understand the contract for these services is about to expire, and it is my strong recommendation that the new contract reflect these recommendations. I look forward to working with HCFA, this new Administration, and with members on both sides of the aisle to improve the protection afforded to this highly personal information of Medicare beneficiaries. When it comes to such sensitive data, we can never be too vigilant. I will now recognize the chairman of the full committee, Mr. Tauzin, for his opening statement. Chairman Tauzin. Thank you, Mr. Chairman. First, let me assure the witnesses today and our guests that the lack of attendance of members at this hearing should not be taken as any sign of a lack of interest in this important subject. There is an important hearing going on downstairs on the issue of online fraud, which is very similar, in some respects, to our concerns as regards the issues of security of the HCFA systems. And there are other distractions, such as that occurring on the Senate today, that is occupying quite a few members this morning, as everybody considers fallout from what might happen this afternoon. But I can assure there is huge interest and support for you, Mr. Chairman, and this inquiry among the committee members on both sides of the aisle. And I want to join you in the list of recommendations you have made today to HCFA. The protection of privacy and private information in the HCFA systems is a critical issue. It is not only critical for the security of those funds and those systems, which are critical to many millions of older Americans and ill Americans, it is also equally critical in terms of the privacy rights of Americans whose sensitive medical histories, medical treatments, and medical information can be at risk. We recently held hearings with the Secretary of the health agency regarding the ongoing decisions regarding health insurance--health information, rather, privacy. And those privacy rules are currently under review to make sure that we get them right. It will do little good for us to have privacy rules at a health agency and privacy laws in general if the Internet and computer systems that contain those data banks and upon which that information is moved is available to hackers and intruders and people who would create mischief with that information. It is critical that this hearing continue to produce oversight, the kind of extraordinary and sensitive, constant review and attention to the questions of privacy in these systems. Last month, the subcommittee held a hearing that showed just how easily it was for Federal computer systems to be penetrated by hackers. At that hearing, we saw first hand just how easily a team of 20-something ethical hackers could, in minutes, hack into Government computers, crack passwords, and escalate their privileges to allow them not only to get into a computer system but to take control of it and to take control of entire computer networks. That was one frightening hearing. I hope those of you who are here today, if you were not present for that hearing, will go back and read some of the testimony given that day. Anybody watching how easily those hackers got into those systems and controlled those systems and what they said they could do once they controlled them, how they could take control, for example, of the microphones and record any conversations in the room where the computer is located. If you had a camera on your computer, how they could take control of the camera and actually view anything going on in the room where the computer is located. Anybody who saw that demonstration had to be extraordinarily concerned about the security of systems where sensitive, private information is stored and transmitted. Today's hearing will continue our investigation into Federal computer security and will highlight the results of the committee's review of the Health Care Financing Administration, or HCFA. Like Chairman Greenwood, I am pleased, first of all, to learn that HCFA is doing a better job than many other agencies in working to address computer security vulnerabilities. But let us be honest, HCFA has to do a better job than most other Federal agencies. The information is much more sensitive than many other Federal agencies. And the information you have backs up a Federal support system that is critical to the health care of millions of Americans--our own moms and dads and grandparents and aunts and uncles and soon brothers and sisters and ourselves. And we can't permit HCFA to have anything less than the best when it comes to security in these systems. Now, the bottom line is that it is not going to be enough for HCFA to make sure its own systems are properly protected, because oversight testing of Medicare contractors and their systems are equally important. It is not enough to say that HCFA can take the assurances of IBM and AT&T that their systems are secure. We need to know that they have been tested, and we need to know that HCFA is taking great steps to make sure that those assurances are real. It is not that we think that contractors are incompetent or deceptive; it is simply we cannot and should not take anybody's word for it. If you are going to contract with separate systems to carry this data and to help administer the program, the Government agency has an obligation that it cannot waiver from in its self-knowing that those systems are secure, not taking anybody's word for it. So I want to strongly encourage you to go much further in this area than you have gone so far. And I want to congratulate Chairman Greenwood for the very clear successes that his investigation has already produced in terms of pressing the Department and HCFA to make certain improvements in the management of security at HCFA prior to this hearing today. I don't think, Mr. Chairman, this subcommittee can rest until you and I and members can stand before any camera in America and say that we are personally satisfied the medical information of our constituents is adequately protected and that the systems that back up the health security of our families is adequately protected and that the solvency and financial security of those funds is not threatened by hackers, whom we saw in this room, given the chance, that come in and totally destroy sanctity and solvency of those funds. Now, until we can personally do that, until you have done your job to personally assure yourselves of that and satisfied us that it is also true, this committee has to keep up its vigilant attention on this issue. Thank you, Mr. Chairman. [The prepared statement of Hon. W.J. ``Billy'' Tauzin follows:] Prepared Statement of Hon. W.J. ``Billy'' Tauzin, Chairman, Committee on Energy and Commerce Thank you, Mr. Chairman, and let me commend you for holding this very timely hearing on a topic of such great importance to the American people--the protection of their privacy and their private information. Due in part to the Internet, Americans today are paying greater attention to privacy protections. But I don't think that many people realize the extent to which the ongoing debate over privacy is so closely related to the issue of computer security. That is one reason why this Committee has been conducting an investigation into the adequacy of Federal efforts to protect our nation's cyber infrastructure and the vast amounts of sensitive data stored on Federal computers. Last month, the Subcommittee held a hearing that showed just how easily Federal computer systems could be penetrated by hackers. At that hearing, we saw first hand just how easily a team of 20-something ``ethical hackers'' could, in minutes, hack into government computers, crack passwords, and escalate their privileges to allow them to get control of entire computer networks. Today's hearing continues our investigation into Federal computer security and highlights the results of the Committee's review of the Health Care Financing Administration, or HCFA. Like Chairman Greenwood, I am pleased to learn that HCFA has been doing a better job than many other agencies in working to address computer security vulnerabilities. But HCFA is an agency that must do better than most agencies. The security of the Medicare claims system is a matter that HCFA and all of us must take very seriously--for it is one of the most critical Federal assets, containing vast amounts of personally identifiable private medical information. And there is no doubt that HCFA can and must do better in this area. This hearing will explore the very real security vulnerabilities that face HCFA, and the serious management challenges the agency must address in order to properly secure the computer networks that make the Medicare claims system work. Let me highlight just one of these issues, namely HCFA's failure to conduct sufficient oversight and testing of its Medicare contractors and the contractors such as IBM and AT&T that provide critical network services to HCFA. I share Chairman Greenwood's concerns that HCFA has not been aggressive enough in pushing these contractors to allow independent tests of their systems. In an area as sensitive as this one, we simply cannot take their assurances of security at face value-- not because they are incompetent or deceptive, but simply because they may not be as secure as they would like to think. I want to strongly encourage the agency to go further in this area, not just with respect to its contractors' networks, but also its own. Without rigorous, independent testing, we simply cannot assure the American people that their private medical information is indeed protected. Finally, I want to congratulate Chairman Greenwood for the clear successes this investigation already has produced in terms of pressing the Department and HCFA to make certain improvements to the management of security at HCFA prior to this hearing today. I look forward to the testimony from our witnesses today, and continuing to work with HCFA and this Committee as it works to address these concerns. Mr. Greenwood. I thank the chairman for his opening statement and welcome the witnesses. There is an amendment to our witness list. Ms. Michael McMullan, the Acting Deputy Administrator of HCFA will not be testifying, but we do welcome Ms. Jared Adair, the Acting Chief Information Officer of the Health Care Financing Administration. She is accompanied by Mr. John Van Walker, the Senior Advisor for Technology to the HCFA CIO, and Julie Boughn, Director of the Division of HCFA Enterprise Standards. We are also pleased to have with us, Mr. Michael Neuman, president and lead programmer of En Garde Systems, Incorporated, as well as Mr. Joseph Vengrin, Assistant Inspector General for Audit Operations and Financial Statement Activities, who is accompanied by Mr. Ed Meyers, Director, Information Technology Systems of the Office of Inspector General at the Department of Health and Human Services. Welcome to all of you. You are, I believe, aware that the committee is holding an investigative hearing, and when doing so has had the practice of taking testimony under oath. Do you any of you have objections to testifying under oath? Seeing none, the Chair then advises you that under the rules of the House and the rules of the committee you are entitled to be advised by counsel. Do you desire to be advised by counsel during your testimony? In that case, would you please rise and raise your right hand, and I will swear you in. [Witnesses sworn.] Mr. Greenwood. Thank you. You may be seated. You are now under oath. And we would like to proceed, I believe, beginning with an opening statement from Ms. Adair for 5 minutes. Welcome. TESTIMONY OF JARED ADAIR, ACTING CHIEF INFORMATION OFFICER, HEALTH CARE FINANCING ADMINISTRATION, ACCOMPANIED BY JOHN VAN WALKER, SENIOR ADVISOR FOR TECHNOLOGY TO CIO AND JULIE BOUGHN, DIRECTOR, DIVISION OF HCFA ENTERPRISE STANDARDS; JOSEPH E. VENGRIN, ASSISTANT INSPECTOR GENERAL FOR AUDIT OPERATIONS AND FINANCIAL STATEMENT ACTIVITIES, ACCOMPANIED BY ED MEYERS, DIRECTOR, INFORMATION TECHNOLOGY SYSTEMS, OFFICE OF INSPECTOR GENERAL; AND MICHAEL NEUMAN, PRESIDENT AND LEAD PROGRAMMER, EN GARDE SYSTEMS, INCORPORATED Ms. Adair. Thank you. Mr. Greenwood. Good morning. Ms. Adair. Good morning. Chairman Tauzin, Chairman Greenwood, thank you for inviting us here today to discuss the Health Care Financing Administration's information security efforts. Protecting the confidential health information of the Americans who rely on our programs is a critically important responsibility. I assure you we take this duty seriously, and over the last few years we have made substantial improvement. Beneficiary data are essential to carrying out Medicare's health insurance functions. These data allow us to determine if an individual is enrolled in Medicare and to determine whether a claim should be paid and how much to be paid. As custodians of these data, it is our job to ensure that proper safeguards are in place. Our beneficiaries deserve no less. We face considerable security challenges due to Medicare's current, complex environment. The complexity of this environment is driven by the increasingly data-intensive nature of modern health care. And because our claims processing contractors are, by law, decentralized. We are proud in the history of the Medicare Program there have been no significant security or privacy breaches of Medicare systems, and there have been no substantial problems with breaches of confidential, beneficiary or provider data. Nevertheless, we remain vigilant in our efforts to protect beneficiary information. We recognize that although perfect security is unattainable, we must constantly and rigorously improve our defenses. Even the smallest technological change can open us to new threats that cannot always be anticipated. We have worked proactively to identify, correct, and prevent problems. And I want to thank the Office of the Inspector General as well as the General Accounting Office for their assistance in highlighting areas where we can make improvements and in recommending solutions. Their work serves as an important road map for us as we work to improve security. We have instituted a comprehensive system security program across our entire enterprise, and we continue to make great strides in improving security. For example, we became one of the first non-military Federal agencies to initiate third-party penetration testing of our system. At our agency and at some of our claims processor contractors, we have used ethical hackers to test for potential vulnerabilities before someone actually seeking to do harm could discover them. In addition, we have been conservative in moving to new e-business technology to ensure that adequate protections are in place before using this kind of technology. And we do not share confidential beneficiary information for marketing or commercial purposes. We have established baseline security requirements for our claims processing contractors and are assessing how their security measures meet or exceed our requirements. These assessments will be valuable for future security planning. Internally we are improving processes for managing access to data to help ensure that only staff with a legitimate professional need have access to sensitive information and that the data are used appropriately. We look carefully at whether an employee's job entails need-to-know confidential information. Even our senior staff, including the Chief Information Officer and myself, cannot browse this information, because we do not have a need to know. Additionally, we are increasing awareness of security to the entire agency and to our contractors, reminding them that bad habits, such as sharing passwords, could lead to unintended consequences. Beginning this summer, all HCFA staff will complete annual training on computer security. We are working hard to protect confidential health data. Our goal is to create multi-layered security defenses that when taken together establish a solid security posture for our agency. We want to work with you and our partners to make sure that we protect this information and fulfill all of our responsibilities to our beneficiaries and the taxpayers. Thank you for holding this hearing, and I will be happy to answer questions. [The prepared statement of Jared Adair follows:] Prepared Statement of Jared Adair, Deputy Chief Information Officer, Health Care Financing Administration Chairman Greenwood, Congressman Deutsch, other distinguished members of the Subcommittee, thank you for inviting me to discuss the Health Care Financing Administration's (HCFA) information technology security efforts and our plans for the future. Protecting the confidential health information of the Americans who rely on our programs is a critical responsibility, and we take this duty seriously. I appreciate the opportunity to share our efforts and plans with you. Confidential data are essential to carry out many of our business functions. For example, to pay a Medicare claim, we must confirm the beneficiary's eligibility for Medicare benefits, obtain information about secondary payers, review the claims history, and perform other data-intensive activities. Similarly, for a Medicare managed care payment, we have to establish the beneficiary's enrollment, calculate the payment amount, and forward that amount to the plan. In addition, efforts to encourage high quality care require analysis of the treatments and complications that Medicare beneficiaries experience. As manager and custodian of this data, we have a legal and practical responsibility to assure that proper security safeguards are in place for maintaining confidentiality, integrity, and appropriate availability of this data. We take this responsibility seriously, and the public counts on us to do so. This Committee and Congress recognized this when they passed the Government Information Security Reform Act, focusing attention across the government on information security concerns. While we have not yet experienced any significant breach of our systems' security, we remain vigilant in our efforts to protect beneficiary information. Our staff and partners like the Inspector General (IG) have identified security vulnerabilities within our systems, and we have taken appropriate steps to address them. I want to commend the IG, as well as the General Accounting Office (GAO) and others, for their assistance in highlighting these vulnerabilities and their recommendations for solutions. Their work serves as an important roadmap for us as we work to improve security across our Agency. Moreover, in our recent Chief Financial Officer Electronic Data Processing audit, the IG acknowledged that we have made progress with our security efforts. As a result of increasing use and changing technologies, the demands on our information technology architecture are greater than ever before, and security risks continue to evolve. Clearly, we must continue to enhance and improve security in order to meet today's needs and tomorrow's challenges. We recognize that although perfect security is unattainable, we must constantly and rigorously improve our defenses. As the technology we use in administering our programs has grown more complex, old threats have intensified and new security threats have emerged. Even the smallest technological change can open us to new threats, which cannot always be anticipated. As the Deputy Director of HCFA's Office of Information Services and Deputy Chief Information Officer, I am acutely aware of our computer system security responsibilities. We have worked hard, especially in the past 5 years, to identify, correct, and prevent problems with the security of our computer systems. We have instituted a comprehensive and effective system security program across our entire enterprise, and we continue to make great strides in improving security both in our internal systems and the systems of our external business partners. We have greatly improved our security, and we have concrete plans to improve it further. BACKGROUND In the history of the Medicare program, there have been no significant security or privacy breaches with Medicare systems, nor have there been substantial problems with breaches of confidential beneficiary or provider data. However, we face considerable security challenges due to Medicare's current, complex environment. The complexity of this environment is driven by the increasingly data- intensive nature of modern health care as we strive to meet our mission of providing high-quality health insurance coverage to nearly 40 million older and disabled Americans. By law, Medicare fee-for-service claims are processed by about 50 private sector insurance companies who each have their own business processes and variations in the use of Medicare claims processing software, which we are responsible for overseeing. From a technology standpoint, such decentralization requires that we transmit data with contractors to ensure that we bring together up-to-date information on eligibility, enrollment, deductibles, utilization, and other potential insurance payers. We also must share eligibility and managed care enrollment data with the approximately 540 managed care plans providing services to Medicare beneficiaries. In addition to these demands, we are striving to make information about our programs and services more readily available to Medicare beneficiaries, physicians, and other providers. We need to provide timely solutions and ready access to information for our customers and partners so they can research Medicare benefits, billing rules and procedures, the quality and safety of care, and a host of other subjects. However, we must balance this need with our responsibility to protect sensitive information from unauthorized access, such as preventing ``hackers'' from violating our internal systems via our public Internet sites. And we must address both of these priorities within the aging nature of our current information technology infrastructure. We learned a great deal about how to address information technology challenges two years ago when, in partnership with Congress and over one million health care providers across the country, we successfully met the Year 2000 challenge. Now, with our resources no longer committed to that effort, we have resumed efforts to implement legislative changes mandated by the Health Insurance Portability and Accountability Act, the Balanced Budget Act of 1997, the Balanced Budget Refinement Act of 1999, and the Medicare, Medicaid, and SCHIP Benefits and Improvement Act of 2000. We also have initiatives to modernize other areas related to our business functions, including establishing the HCFA Integrated General Ledger Accounting System, to readily support a ``clean opinion'' on our Chief Financial Officer audit; and we have refocused on the security responsibility that comes with using ever-improving information technology. INFORMATION SECURITY In 1997, HCFA's first Chief Information Officer, Dr. Gary Christoph, was hired, and he began an effort to identify security deficiencies in our internal systems. Under Dr. Christoph, we began testing for security problems so we could better realize what problems exist, where they are located, and how we can prevent them. Under this guiding principle, we became one of the first non-military Federal agencies to initiate third-party penetration testing of systems. We used an ``ethical hacker'' to test for vulnerabilities at our Agency and at some of our claims processing contractors before someone actually seeking to do harm could discover them. It is imperative to uncover these vulnerabilities, and in many cases we agreed with and implemented the contractors' recommendations. In other cases, we analyzed the findings, considered the recommendations, and developed solutions that more appropriately fit our business needs while still addressing the underlying vulnerability. In all cases, we recognize the seriousness of any vulnerability and know we must carefully balance security with our other business responsibilities. We do not share confidential beneficiary information for marketing or other commercial purposes. We also have been conservative in moving to new e-business technology, to ensure that adequate protections are in place before we use this type of technology. Moreover, from Fiscal Year 2000 to Fiscal Year 2001, our spending on major information technology security projects increased from $5 million to $11.7 million. In 1998 we began work on an Enterprise-wide Systems Security Initiative that follows guidance from the National Institute of Standards and Technology and the Office of Management Budget Circular A-130, which established policy for the management of Federal information resources. The central tenet of our initiative is to understand and mitigate the risks to our information in the most cost- effective manner. As you know, this effort slowed when we had to dedicate the vast majority of our information technology staff time and resources to Year 2000 remediation efforts. We resumed focusing on the Security Initiative in 2000, implementing it along two parallel tracks: one track focuses on security inside the Agency, and one examines our external business partners, beginning with the Medicare contractors. The Security Initiative's implementation at the Medicare contractors began in earnest earlier this year when we published baseline security requirements for the contractors and followed up with an assessment tool to compare how their security measures to our core requirements. The results of those assessments will serve as a valuable work plan for our security efforts in the future. Our internal HCFA efforts have been ongoing for a longer period of time and we have made substantial progress. We continually assess our internal risks and vulnerabilities and take remedial actions to address them as aggressively as possible within our available resources. For example, we have developed improved procedures and tools for managing access to our data. These efforts help ensure that only staff who have a proper and legitimate professional need have access to sensitive information and that the staff use these data appropriately within our strict guidelines. We look carefully at whether an employee's job entails a ``need to know'' confidential information. Even our senior staff, including the Chief Information Officer and I, cannot browse this information because we do not have a ``need to know.'' Additionally, we are publicizing our intensified data security efforts to the entire Agency and contractor staff, informing them of their responsibilities, and reminding them that bad habits, such as sharing systems passwords, could lead to unintended consequences. And beginning this summer, all HCFA staff will complete annual training on computer security. We believe that this strong effort to protect sensitive material will itself deter individuals from even attempting to violate our systems. Throughout our implementation of the Security Initiative, we have pursued self-testing of our security controls. Periodic recurrent testing can detect new vulnerabilities that have surfaced because of new technology, and reaffirm that old vulnerabilities have not been reopened. We also continue to use third party contractors to conduct ``white hat'' penetration tests of various portions of our computer network. When we began these tests over 3 years ago, we focused on looking into the Agency from external networks such as the Internet. Recently, we conducted more refined testing by looking internally at our network from the perspective of an authorized HCFA user. This is important because published industry-wide statistics indicate that authorized users or employees are suspected as the largest source of security breaches. Along with our own self-assessments and contractor testing, audits performed by the IG have aided us in identifying security vulnerabilities in our information systems. For example, the IG found that Agency and contractor employees could have had unauthorized access to confidential information, because passwords were not being administered properly or computer programmers could have had inappropriate access to some files. They also found instances where people could have had inappropriate access to the areas where computers were stored. In each of these instances, we have worked hard to address the vulnerabilities, and we have made significant progress. For example, we have recertified all of the individuals with password access to our systems, purging hundreds of individual passwords from our systems. Additionally, we have secured areas that before permitted inappropriate access to our computer hardware. Some of these vulnerabilities were easy to address, while others are longer-term projects that require more intensive attention. And we remain open to suggestions of additional ways to improve our security. Information technology continues to evolve, and we will always have to strive to keep our health data secure. CONCLUSION We have been working hard to protect confidential health data. Our goal is to build upon a multi-layered series of security defenses, utilizing firewalls, scanning software, intrusion detection, administrative controls, access controls, good authorization procedures, and recurrent security training and education for staff, among other things. Taken together, these layers of protection establish a solid security posture for our Agency. We face major challenges in continuing to implement and improve our computer security program. Over the next fiscal year, we expect to put our security policy statements into action and develop specific standards, including establishing minimum floors for protecting all of our sensitive data. We want to continue to work with you and our other partners to make sure that we protect this information and fulfill all of our responsibilities as effectively and efficiently as possible. Thank you for your support and assistance, and the opportunity to discuss these important issues with you today. I am happy to answer your questions. Mr. Greenwood. Thank you for your testimony, and thank you for the constructive way that you have approached this relationship. Mr. Vengrin. TESTIMONY OF JOSEPH E. VENGRIN Mr. Vengrin. We share the committee's concerns regarding the security of Government information systems, and we appreciate the opportunity to testify on the vulnerabilities within the Medicare claims processing system. As you mentioned, Mr. Chairman, as part of our annual audit of the Health Care Financing Administration financial statements, we contract with independent public accounting firms to test the adequacy of internal controls over Medicare's information system. The purpose of these tests is to determine the nature, timing and extent of audit procedures to be performed during this financial statement review. Strong internal controls over Medicare systems are essential to ensure the integrity, confidentiality, and reliability of critical data and to reduce the risk of errors, fraud, and illegal acts. However, in the last 5 years we have noted continuing material internal control weaknesses in Medicare systems, particularly those operated by the Medicare contractors. Material weaknesses are defined as serious deficiencies in internal controls that can lead to material misstatements of amounts reported in HCFA's financial statements. Also, such weaknesses could allow unauthorized access to and disclosure of sensitive information, malicious changes that could interrupt data processing or destroy data files, improper Medicare payments, or disruption of critical operations. My statement today will summarize the significant problems noted in the fiscal year 2000 financial statement audit. I will not go into some of the background on the Medicare system--you have mentioned that in your opening remarks. We know it is very complicated and complex. As we previously reported, the internal control environment for the Medicare claims processing operation needs substantial improvement. Our fiscal year 2000 audit identified numerous weaknesses in general controls, which affect the integrity of all applications operating within a single data processing facility and are critical to ensuring the reliability, confidentiality, and availability of data. Auditors identified 124 general control weaknesses--115 at the sampled Medicare contractors and the remainder at the HCFA Central Office. Mr. Chairman, over 60 percent of these weaknesses involved two types of general controls: access and entity-wide security. Access controls ensure that system assets are physically safeguarded and that access to sensitive computer programs and data is granted only when authorized. Weaknesses in such controls can compromise the integrity of sensitive information and increase the risk that data may be inappropriately used or disclosed. Access control weaknesses represent the largest problem area. The most widespread weaknesses concerned poorly controlled passwords, ineffective implementation of system security software, and infrequent reviews of access privileges. We also reported that controls did not effectively prevent access to sensitive data. For instance, computer programmers and other technical support staff had inappropriate access to data files used in the fee-for-service claims process, such as beneficiary history files. As part of their assessment of access controls, auditors performed low-level internal and external penetration testing at eight contractor sites. This testing revealed additional access control risks. Systems permitted excessive remote access logon attempts. Systems disclosed more information about themselves than necessary. Inadequate password protections permitted unauthorized access to certain computer systems, and insufficient controls over print output queues permitted unauthorized read access to sensitive data. Such weaknesses increase the risk of unauthorized remote access to sensitive Medicare information. Entity-wide security programs ensure that security threats are identified, risks are assessed, control techniques are developed, and management oversight is applied to ensure overall effectiveness of the security measures. These programs typically include policies on how and when sensitive duties should be separated to avoid conflicts of interests and stipulate what types of background checks are needed during the hiring process. Inadequacies in the programs can result in inadequate access controls and software change controls affecting mission-critical operations. We reported that several contractor sites lacked fully documented, comprehensive entity-wide security plans, had inadequate risk assessments and lacked comprehensive security awareness programs. At the HCFA Central Office, we found no security assessment of or security plans for significant application systems, insufficient security oversight of Medicare contractors, and no formal process to remove system access of terminated HCFA employees. With respect to the shared systems, since fiscal year 1997, we have reported that Medicare data centers have inappropriate access to the source code of one of the shared claims processing systems. This unresolved weakness, Mr. Chairman, was expanded this year to include the Common Working File, which is shared by all Medicare claims processors. Access to source code renders the Medicare claims processing system vulnerable to abuse, such as implementation of unauthorized programs. While HCFA requires contractors to restrict local changes to emergency situations, local changes are often not subjected to the same controls that exist in the standard change control process. To briefly conclude, we remain concerned that inadequate internal controls over Medicare operations leave the program vulnerable to loss of funds, unauthorized access to and disclosure of sensitive medical information, and malicious changes that could interrupt the data processing or destroy data files. All of the weaknesses that I have described today are troubling. However, we do not know whether the resulting vulnerabilities have been exploited in terms of compromised medical information, fictitious claims, or diversion of taxpayers' dollars. On a positive note, to conclude, I would like to report that HCFA Central Office has continued to make substantial progress in implementing enhanced control procedures, specifically in the area of access controls and application change development controls. I will now entertain any questions. Thank you. [The prepared statement of Joseph E. Vengrin follows:] Prepared Statement of Joseph E. Vengrin, Assistant Inspector General for Audit Operations and Financial Statement Activities, Department of Health and Human Services Good morning, Mr. Chairman. I am Joseph E. Vengrin, Assistant Inspector General for Audit Operations and Financial Statement Activities of the Department of Health and Human Services. With me today is Ed Meyers, Director, Information Systems Audits and Advanced Techniques. We share the Committee's concerns regarding the security of Government information systems, and we appreciate the opportunity to testify on the vulnerability of Medicare claim processing systems. In conducting annual audits of the Health Care Financing Administration (HCFA) financial statements, which are required by the Government Management Reform Act of 1994, we contract with independent public accounting (IPA) firms to express an opinion on the financial statements and report on internal control deficiencies. As part of the body of work underpinning these audits, the IPA firms perform various internal control tests of the Medicare program, including its automated systems. The purpose of these tests is to determine the nature, timing, and extent of audit procedures to be performed during each year's audit. Strong internal controls over Medicare systems are essential to ensure the integrity, confidentiality, and reliability of critical data and to reduce the risk of errors, fraud, and other illegal acts. However, since fiscal year (FY) 1996, when we first began the financial statement audits, we have noted continuing material internal control weaknesses in the systems, particularly those operated by contractors. Material weaknesses are defined as serious deficiencies in internal controls that can lead to material misstatements of amounts reported in subsequent financial statements unless corrective actions are taken. Also, such weaknesses could allow (1) unauthorized access to and disclosure of sensitive information, (2) malicious changes that could interrupt data processing or destroy data files, (3) improper Medicare payments, or (4) disruption of critical operations. My statement today will summarize the significant problems noted in the FY 2000 financial statement audit. MEDICARE AUTOMATED SYSTEMS By way of background, the Medicare program provides health insurance for 39.5 million elderly and disabled Americans at a cost of about $215 billion in FY 2000. The program is administered by HCFA, the largest component of the Department of Health and Human Services. Medicare services are provided through either fee-for-service arrangements or managed care plans. HCFA relies on extensive computerized operations at both its central office and contractor sites to administer the Medicare program and to process and account for Medicare expenditures. The HCFA central office systems maintain administrative data, such as Medicare enrollment, eligibility, and paid claims data, and process all payments to health care providers for managed care. The fee-for-service claim processing system, the Department's most complex and decentralized system, is operated with the help of more than 50 contractors located throughout the country. There are two types of contractors: Intermediaries process claims from institutions, such as hospitals and skilled nursing facilities, filed under Part A of the Medicare program, while carriers process Part B claims from other health care providers, such as physicians and medical equipment suppliers. These contractors and their data centers use several ``shared'' systems to process and pay provider claims. Currently, each intermediary uses one of two shared systems, and each carrier uses one of four shared systems. All of the shared systems interface with HCFA's Common Working File system to obtain authorization to pay claims and to coordinate Medicare Part A and Part B benefits. This fee-for-service network processed over 890 million claims totaling $173.6 billion during FY 2000. Generally, Medicare claim processing begins when a health care provider submits a claim to a contractor. The claim is entered into a shared system which captures, edits, and prices the claim. Once the claim has passed all shared system edits and has been priced, it is submitted to the Common Working File for validation, verification of beneficiary eligibility, and payment authorization. SYSTEMS CONTROL WEAKNESSES As we have previously reported, the underlying internal control environment for Medicare claim processing operations needs substantial improvement. Our FY 2000 audit identified numerous weaknesses in general controls, which involve access controls, entity-wide security programs, application development and program change controls, segregation of duties, operating system software, and service continuity. General controls affect the integrity of all applications operating within a single data processing facility and are critical to ensuring the reliability, confidentiality, and availability of data. Of 124 general control weaknesses identified, 115 were found at the sampled Medicare contractor sites and 9 were found at the HCFA central office. About 80 percent of these weaknesses involved three types of controls: access controls, entity-wide security programs, and systems software. Access Controls Access controls ensure that critical systems assets are physically safeguarded, that logical (e.g., electronic) access to sensitive computer programs and data is granted only when authorized and appropriate, and that only authorized staff and computer processes access sensitive data in an appropriate manner. Weaknesses in such controls can compromise the integrity of program data and increase the risk that data may be inappropriately used and/or disclosed. Access control weaknesses represented the largest problem area. The most widespread weaknesses concerned administration of the controls themselves. At several contractors, passwords were not properly administered, systems security software was not implemented effectively, or access privileges were not reviewed frequently enough to ensure their continuing validity. We also reported that controls did not effectively prevent access to sensitive data. For instance, computer programmers and other technical support staff had inappropriate access to the data files used in the fee-for-service claim process, such as beneficiary history files. Under these conditions, the Common Working File system was vulnerable to inappropriate use. At some contractors, programmers had inappropriate access to system logs; this provided an opportunity to conceal improper actions and obviated the logs' effectiveness as ``detect'' controls. At one contractor, the computer operator could override installation system security precautions when restarting the mainframe computer system. We also noted weaknesses in controls over access to sensitive facilities and media within those facilities. For example, at one contractor, inappropriate individuals had access to the computer center's command post. At another, the computer production control area was not secured during normal business hours. Penetration Tests. As part of their assessment of access controls, IPA firms performed low-level internal and external penetration testing at eight Medicare contractor sites. The purpose of this testing was to identify real and postulated security risks to, and vulnerabilities of, the information systems. A variety of common penetration testing procedures revealed additional access control risks at certain contractor sites. When dial-up connections were made, computer systems permitted an excessive number of failed remote access log-in attempts before disconnection and disclosed more information about themselves than necessary. In addition, inadequate password protections permitted unauthorized access to certain computer systems, and insufficient controls over print output queues permitted unauthorized ``read'' access to sensitive data. Such weaknesses increase the risk of unauthorized remote access to sensitive Medicare systems and data. Entity-Wide Security Programs Entity-wide security programs ensure that security threats are identified, risks are assessed, control techniques are developed, and management oversight is applied to ensure the overall effectiveness of security measures. These programs typically include policies on how and which sensitive duties should be separated to avoid conflicts of interest and stipulate what types of background checks are needed during the hiring process. Entity-wide security programs afford management the opportunity to provide appropriate direction and oversight of the design, development, and operation of critical systems controls. Inadequacies in these programs can result in inadequate access controls and software change controls affecting mission-critical operations. We reported that several contractor sites lacked fully documented, comprehensive entity-wide security plans that addressed all aspects of an adequate security program. Inadequate risk assessments, a lack of comprehensive security awareness programs, and inadequate policies were among the weaknesses noted at the contractors. At the HCFA central office, we found no security assessment of, or security plans for, significant application systems; insufficient security oversight of the Medicare contractors; no formal process to remove system access of terminated HCFA employees and contractors; and deficiencies in the management review and approval process. Systems Software Controls Systems software controls help to prevent unauthorized individuals from using software to read, modify, or delete critical information and programs. Systems software is a set of programs designed to operate and control the processing activities of computer equipment. Generally, it supports a variety of applications that may run on the same computer hardware. Some systems software can change data and programs on files without leaving an audit trail. Weaknesses in systems software controls related to managing routine changes to the software to ensure their appropriate implementation and configuring operating system controls to ensure their effectiveness. Such problems could weaken critical controls over access to sensitive Medicare data files and operating system programs. Shared System Weaknesses Since FY 1997, we have reported that the Medicare data centers have inappropriate access to the source code of the Fiscal Intermediary Shared System, which is used by certain Medicare contractors. This unresolved weakness was expanded this year to include the Common Working File system, which all shared systems use to obtain authorization to pay claims. Access to source code renders the Medicare claim processing system vulnerable to abuse, such as the implementation of unauthorized programs and the implementation of local changes to shared system programs. While HCFA requires contractors to restrict local changes to emergency situations, local changes are often not subjected to the same controls that exist in the standard change control process. CONCLUSIONS In summary, we remain concerned that inadequate internal controls over Medicare operations leave the program vulnerable to loss of funds, unauthorized access to and disclosure of sensitive medical information, malicious changes that could interrupt data processing or destroy data files, improper payments, or disruption of critical operations. Further, because of weaknesses in the contractors' entity-wide security structures, HCFA has no assurance that information systems controls are adequate and operating effectively. While all of these weaknesses are troubling, we do not know whether the resulting vulnerabilities have been exploited in terms of compromised medical information, fictitious Medicare claims, diversion of taxpayer dollars, or some other type of fraud or abuse by an ``insider'' or a hacker. What most concerns us are the continuing problems identified in access and entity-wide security controls. HCFA must ensure that Medicare contractors develop corrective action plans that not only address identified weaknesses but also attempt to determine the fundamental causes of the weaknesses. Among the efforts planned and underway by HCFA is an improved corrective action process. We expect that HCFA's testimony will fully address that process, as well as other short- and long-term actions to shore up information systems controls. We urge HCFA to sustain its focus on these critical internal controls. Furthermore, HCFA and the Medicare contractors should routinely conduct penetration testing to ensure the integrity of their information technology environment. We in the Office of Inspector General will continue to work with HCFA to overcome the persistent risks to the security of the Medicare program. For example, as required by the Government Information Security Reform Act (GISRA) of 2000, we have begun an independent evaluation of HCFA's security program. Our evaluation will incorporate the results of several efforts: the internal control testing conducted during our annual financial statement audits, our ongoing work to ensure compliance with Presidential Decision Directive 63, our additional work focused on access and entity-wide security controls at selected Medicare contractors, information systems reviews (known as Statement on Audit Standards 70 examinations) conducted by IPA firms under contract with HCFA, and other security assessments performed by consultants for HCFA. I will be happy to discuss the extent of our GISRA work, as well as any other matters, in response to your questions. Mr. Greenwood. Thank you. Mr. Neuman, thank you for being with us this morning. TESTIMONY OF MICHAEL NEUMAN Mr. Neuman. Sure. Essentially, we are ethical hackers, and our job is to ensure that the implementation of a network, of an application of a server matches the policy set forth by the organization and that it matches best industry practices. Over the course of 1997 to early 2000, we conducted about six penetration tests, both internal and external, meaning as an average employee of HCFA and as an average hacker on the Internet externally. We have also reviewed their architecture. We have reviewed the desktop PCs that they put on everybody's desk. We have dialed all their phone numbers looking for modems. For findings, the bottom line is this: Over the course of that work, we found several serious vulnerabilities that could easily have allowed anybody unrestricted access to the data owned by HCFA. In our experience with them, these vulnerabilities were quickly fixed, sometimes in a matter of hours. Management also really made security a fairly high priority. Then they wanted to do real security. What we see a lot is people are perfectly happy to deal with security issues by writing more policies dealing with it. That is not the answer. What we do is make sure that the implementation matches that policy. HCFA has made a real effort to ensure that their implementation does match their policy. What we found is this: Absolutely the biggest cause of vulnerabilities at HCFA is not directly from the fault of HCFA employees but through their facilities management contractors, the people who are responsible for running their networks, for installing new machines, for managing their network connectivity. By far this was the biggest source of vulnerabilities that we found. In our experience, we have seen the contractors actually undermine the security efforts of the HCFA staff. They removed security protections without HCFA's knowledge. They misrepresented the security precautions they were taking. They made serious, serious configuration errors that were inconsistent with even the most basic industry security standards. Unfortunately, HCFA does not have the technical expertise overseeing these contractors--and, again, these are the facilities management contractors I am speaking of. They could not detect that these contractors were making these mistakes. They did not have the ability to ask the proper questions to determine if they were doing the right thing. On top of that, HCFA also was lacking the contractual power to make the contractors do what they wanted them to. There was nothing in the contracts which said that they had to perform to a certain level of security or that they need to take certain precautions. Last finding, when we left them, there were a variety of known risks to third parties, in particular we are talking about Medicare contractors. There are a variety of insurance companies, doctors, which are connected both through the MDCN and through direct connectivity into HCFA's network. There are a variety of risks there, which I have detailed in my written testimony. In the end, we recommend this: HCFA needs to focus on technical security not just policy. Really every organization needs a person who is in charge of implementing the security policy, not just telling people how to do passwords but making sure that the passwords are correct, making sure that systems are configured properly, and so forth. They need better control and technical oversight of their contractors. Again, I am not talking about Medicare contractors, although that probably is an issue; in my experience, the facilities contractors. They need more testing of everything. When they install remedial fixes, you need to test those fixes after you are done installing them. You need to test everything from applications to servers to networks, and it needs to be done regularly. Threats and vulnerabilities change all the time. And decisions to ignore those vulnerabilities really need to be taken with a full awareness of what the actual risks are when they take that risk. In the end, if they had the technical expertise and the oversight of their contractors, virtually every vulnerability that we found would have been prevented. And we think that is a significant step they need to take. [The prepared statement of Michael Neuman follows:] Prepared Statement of Michael Neuman, En Garde Systems, Inc. 0. SUMMARY Penetration testing is a critical tool in ensuring the security of everything from an individual software application to an entire network. Unfortunately, security is far too complex to provide any sense of absolutes. Add to that the fact that dozens (if not hundreds) of new vulnerabilities are discovered every week, and the need to continuously test the security of a system is obvious. We have provided services, similar to those we provided HCFA, to hundreds of companies, and are intricately aware of the ``industry standard'' state of security. During our tenure providing security services to HCFA, we found both extremely positive and disturbing issues. Major recommendations include: Technical Oversight: HCFA is lacking the specially trained personnel to oversee their and their contractors' activities and verify the work for security consistent with policy and best practices.. Third-Party Verification: It should be unacceptable for service providers to certify themselves as secure. Any vendor of network services to HCFA should readily accept 3rd party verification of security and have regular testing a part of their contract performance requirements. Security Specified in Contracts: The security expectations and requirements should explicitly be laid out in contracts with network service providers. More Testing is Required: It's necessary to independently verify the security features of everything from applications to WWW servers to networks and to do so on a recurring basis. 1. BACKGROUND En Garde Systems (EGS) provided a variety of security services to the Health Care Financing Administration (HCFA) between December 1997 and June 2000. During that time, EGS performed a number of penetration tests and assisted HCFA in devising network security protections. Specifically, EGS has performed:External Penetration Tests (4). As an average outsider connected to the Internet, we attempted to gain access to internal HCFA resources. Internal Penetration Tests (2). Given a connection to HCFA's internal network, we attempted to gain access to internal HCFA resources. Wardialing. Given a prototype phone number (for example 786- xxxx), we dial every phone number looking for computer modems. When a computer answers, we attempt to gain access. Architecture Review and Design. Given a complete map of network resources, we spent extensive time understanding the various applications HCFA provides and the security needs of each. We then formulated network architecture changes that would build security into the fabric of the network. Test of Internet services hosted by IBM Global Services. At the time we tested, HCFA outsourced its internal and external web servers to IBM. NT Desktop Review. For Y2K, HCFA moved to a Windows NT desktop system. We were provided with a prototypical NT desktop prior to deployment to find security vulnerabilities. HCFA Insider test. We were given a standard user's desktop computer and asked to gain access to HCFA internal resources. In this case, we were not allowed to bring in our own software, floppies, or PC--only what we could retrieve using HCFA's network. Intrusion Detection System Review. HCFA ran a ``bake-off'' of several competing Intrusion Detection Systems and asked us to perform a variety of tests to determine their efficacy. Security Training. We provided classes over a several day period covering everything from good password choice to Intrusion Investigation and Response. 2. APPROACH Penetration testing is a critical tool in ensuring the security of everything from an individual software application to an entire network. Unfortunately, security is far too complex to provide any sense of absolutes. Turning on one network service may result in dozens being turned in non-obvious ways. Connecting a trusted partner to your network often means you not only trust him, but everyone he trusts as well. Add to that the fact that dozens (if not hundreds) of new vulnerabilities are discovered every week, and the need to continuously test the security of a system is obvious. Our approach to testing is almost exclusively ``manual''. We rarely use automated tools, as our experience has shown they are generally only effective in an extremely small number of cases. Instead, we learn about the network and create new attacks on the fly. In doing so, we are doing exactly what a hacker does. Proposing solutions to vulnerabilities is perhaps the most complex part of our work. Before we recommend any solution, we need to determine the: 1) Value of the organization's data. If the data is simply pricing and personnel information, it is far less valuable to a hacker than Privacy Act data, for example. 2) Threat to the organization. A government agency will attract far more interest from the malevolent than a small computer company, for example. 3) Path of least resistance. It makes no sense to spend a great deal of effort protecting a network connection to a partner if the ``front door'' is wide open. These relative threats are determined before any solution is recommended. 4) Cost in man-hours and equipment expenditures. We often make several recommendations based upon the amount of money the customer wishes to spend. 3. FINDINGS We have provided services, similar to those we provided HCFA, to hundreds of companies, and are intricately aware of the ``industry standard'' state of security. During our tenure providing security services to HCFA, we found both extremely positive and disturbing issues. 3.1 Positive 3.1.1. There is a healthy approach to security from HCFA management. Whereas many other organizations believe that all security problems can be solved by writing a policy, HCFA has taken significant steps to not only inscribe the virtues of security, but to ensure they practice what they preach. 3.1.2. When we first arrived at HCFA, we found them to be operating with significant and obvious vulnerabilities. These problems were fixed within hours of our reports. Over the course of the years, HCFA has become significantly more secure than the industry standard. 3.1.3. Beyond simply patching vulnerabilities that were found, HCFA has made significant efforts to find the systemic causes of their vulnerabilities and fix them wherever possible. 3.2 Negative 3.2.1. Contractors By far, HCFA's biggest security problems have been the direct result of the action or inaction of contractors. In general, we have found HCFA's contractors to be outright obstructive to providing sound security. Compounding these errors was HCFA's inability to catch or prevent them. a. HCFA lacked the technical oversight of their contractors to verify the contractor was actually implementing the security measures they claimed. The managerial oversight had no ability to ask relevant questions. b. HCFA's contracts had no mention of security expectations of a contractor. As a result, the contractors were free to implement (or not implement) any measures they felt as appropriate, regardless of HCFA's requests. c. We discovered during our first test that a HCFA contractor ignored change control, bypassed the firewall policy group, and installed his own filter rules directly onto HCFA's primary firewall without anyone's knowledge. These filter rules made the entire HCFA network vulnerable to a variety of serious attacks. After bringing the firewall problem to HCFA's attention, the contractor was directed to remove the rule and instructed about the use of change control. One year later, we tested and found the contractor installed the same rule again without HCFA's knowledge. d. On several occasions, we witnessed HCFA contractors argue against improving security stating that changes HCFA asked for were ``difficult'' or ``impossible'' when, in fact, they were not. e. During our architecture review, we discovered that the HCFA contractors responsible for network operations could not provide a complete list of all network connections external to HCFA. In fact, we spoke to over a dozen groups, and each would make us aware of another undocumented connection from HCFA to another organization. f. Contractors have made extremely poor password and configuration decisions, violating the most basic security principals and completely invalidating other security measures put into place. 3.2.2. IBM HCFA relied on IBM to provide secure network connectivity (via a product called ``SecureNet'') to MDCN partners as well as for both external and internal WWW servers. We were contracted to evaluate the architecture and determine potential risks. During a meeting with HCFA management (up to CIO level), IBM's security staff and management responsible for the HCFA contract, and ourselves, we were told by IBM that we didn't need to test because they had taken every imaginable security precaution. They described how: Administrators can only connect from a physically secure administrative network WWW administration is done through an encrypted management connection Patches are installed immediately after a vulnerability is announced They would be happy to share their firewall's access control lists with us They perform penetration testing every week They have a custom designed IDS along with 24/7 response The firewalls only allow WWW access through Upon extensive questioning from ourselves and HCFA's CIO, it we learned from IBM that: Administrators can also dial-in from home into a generic ``SecureNet'' modem bank, that all other customers use, and administer machines. WWW administration can be encrypted, but they haven't enabled that feature, and probably won't because it's difficult to do so. Patches are only installed when an administrator gets around to it, which is usually in a ``week or two''. They would not share their access control lists because, ``If EGS found a vulnerability in HCFA, they would find a vulnerability in all IBM customers.'' Because HCFA relies so much on the security of IBM to provide everything from secure connectivity for the MDCN to managed web hosting, we proposed performing three distinct tests: 1) External test against the web servers hosted by IBM 2) Tests from a HCFA partner connected to the MDCN directed at HCFA and other partners on the MDCN. 3) Tests from a non-MDCN customer of IBM directed towards HCFA. It took IBM and HCFA a year of negotiation to come to terms to allow just the external test against the web servers. We were given several severe restrictions that made the results of the test unrealistic. Specifically: 1) We were not allowed to test the firewalls or any other infrastructure on the IBM network. They did provide us with an extremely limited subset of filter rules that IBM said were installed on their firewalls. 2) We were not allowed to touch any IBM system other than HCFA's web server. This included administrative systems, other customer servers, or any infrastructure. 3) We were not allowed to route traffic through any other IBM network. These restrictions meant that we could only test the controls in place on the web server. We could not check for configuration errors in access control lists, vulnerabilities in firewalls or routers, or transitive trust issues (i.e. if we can break into the IBM administrative network, or another customer's web server, what can we do then?). In the end, the restrictions ended up being irrelevant. Using an extremely old, very well known vulnerability in the WWW server software, we were able to gain access to HCFA's web server without any more technical expertise than it takes to point and click. Because of the way HCFA's web server was configured, and an error made in the firewall rules set up by IBM, we were then able to access HCFA's internal network resources. IBM's other claims were then shown either false or useless: If they performed a penetration test every week, they would have discovered this blatant vulnerability They provided us with the IDS logs collected during the course of our attack, and we had gone completely unnoticed, despite us making no effort to hide our tracks. The firewalls allowed not only WWW access through but also another protocol that allowed us unfettered access to HCFA's internal network. 3.2.3. Third Party trust HCFA has a need to connect with a variety of insurance companies, doctors, and so forth. Network connections were provided both through the MDCN and by direct connectivity to other companies. These connections were configured such that there was no protection of either HCFA from the company or the companies from each other. Essentially, HCFA was trusting these companies completely. As a result, HCFA is subject to whatever security policies and protections are in place by the trusted company. So, if HCFA trusts company A and company A trusts company B, then HCFA trusts company B. Without any control over or auditing of the partner's network, HCFA should not trust that it's secure. In addition to threatening HCFA, there is a potential for these competing insurance companies to use HCFA as a means to attack one another. HCFA provides the unsecured communications mechanism, and a company simply uses that to get into another's network. 4. RECOMMENDATIONS 4.1. Technical Oversight HCFA is lacking the specially trained personnel to oversee their and their contractors' activities and verify the work for security consistent with policy and best practices. This position should be solely technical--it should not have any policy development duties associated with it. The position should be independent of any contractors and should be associated with the security policy group. Essentially, the role is to be the ``security implementer'' of the organization. The goal is to have an independent and informed person who can ensure that the security of the organization is not simply some high- level goals or a policy on paper. In HCFA's case, such a person would have prevented the vast majority of vulnerabilities introduced by either HCFA or HCFA's contractors. Beyond our experience with HCFA, such a position is direly needed in most organizations. 4.2. Third-Party Verification It should be unacceptable for service providers to certify themselves as secure. Recently, it's become popular for service providers to get an outside certification of their networks or services and provide that as evidence of their security. In our experience, these too are insufficient, as the certifiers do not reveal their methodology or extent of their certification. Any vendor of network services to HCFA should readily accept 3rd party verification of security and have regular testing a part of their contract performance requirements. 4.3. Security Specified in Contracts The security expectations and requirements should explicitly be laid out in contracts with network service providers. Without such clauses, HCFA was essentially powerless to require the use of broadly accepted industry security standards. 4.4. More Testing is Required Security is such a complex field, with new vulnerabilities being discovered daily, that it's impossible for the average Information Technology professional to keep up. As a result, it's necessary to independently verify the security features of everything from applications to WWW servers to networks and to do so on a recurring basis. In HCFA's case, thoroughly testing the security of the MDCN is critical to its continued operation and information integrity. As it stands, there's no way to know if it's really secure or not. Whenever a new application or service is provided to the public, a new network connection is established, or a new modem installed, these need to be tested for proper operation. 5. CONCLUSION We believe HCFA has done more to identify and remedy security problems than is common. Despite this, they have experienced a substantial set of serious vulnerabilities over the course of our provision of security services to them. Their reliance upon contractors to operate makes them particularly susceptible to the types of vulnerabilities we have described within this document. There is always more work to do, however. Security is not a one- time fix--it's something that must be integrated into the business of an organization. It must be continually reinforced, reanalyzed, and redesigned as circumstances dictate. New services, applications, and networks need to be tested before deployment. Mr. Greenwood. Thank you very much. Okay. Questions. And, Ms. Adair, I am sure you understand that HCFA is not being isolated and singled out. This committee is working its way, fairly methodically, through all the agencies and departments over which we have jurisdiction, and today just happens to be your day. I would like to direct your attention, Ms. Adair, to a document that is in your binder. Do you have one of these binders available to you? It is document number 1, which is the current contract HCFA has for the operation of the Medicare Data Communications Network, the MDCN. If you look at the second page of this document, toward the bottom, there is a section on, ``security requirements.'' It says, ``MDCN security shall be provided/slash maintained/assured by the contractor in order to prevent unauthorized physical, electronic or virtual access to telecommunications facilities, to MDCN hardware or software components and to telecommunications services.'' It then goes on for two more sentences about how encryption is not required and that the MDCN contractor must report suspicious activity on the system to HCFA. Now, this document, in reality, is over 100 pages long, but this is only reference to security requirements in the entire document, my staff informs me--these three sentences. Are we to assume from this that HCFA does not provide its MDCN contractor with specific security requirements with respect to access controls, firewall rules, et cetera, and that instead simply simply says, ``Give us a `secure,' system''? This contract also talks about how the contractor will assure the security of its system from unauthorized attacks, but it doesn't contain any requirements that the contractor actually test the security of its system. How can security be, ``assured'' without actual testing? How does HCFA plan to revise its contracts to address this issue in the future? And I am heartened to see you and your staff taking notes so far this morning, so I assume that you intend to take such steps. Ms. Adair. Yes. And I think, though, that I would ask that John Van Walker, who is the Senior Advisor for Technology, to respond to that specific question. Mr. Greenwood. Mr. Van Walker. Mr. Van Walker. Yes, Mr. Chairman. It is certainly true that this is the sole statement in the contract that touches on security. It is written in 1966--or, actually, the contract was entered into in 1966, at a time when security was not such an-- -- Mr. Greenwood. Nineteen ninety-six. Mr. Van Walker. Nineteen ninety-six, sorry, sir. Mr. Greenwood. If it was 1966, I would be praising you for your foresight. Mr. Van Walker. Indeed, and we would have been appreciative. But in 1996, we viewed the network on a far more closed basis, and we actually had interaction with essentially the Medicare contract community. As the network has expanded, as HCFA's responsibilities have enlarged, and the requirements for more and more data from more and more partners have increased, obviously the network has expanded. This paragraph would be completely inadequate in a contract written today. In any future contracts, we certainly would be far more elaborate, sir. What we have done to deal with this situation is institute and even intensify, as incidents such as those reported by Mr. Neuman have come to our attention, our direct interaction with the contractor. We now meet with the contractor every week. That meeting involves not only face-to-face contacts but the IBM and AT&T security specialists dial in to that conversation from the locations around the country so that we can stay on top of these issues and work through them on a united basis. Mr. Greenwood. How long have you been doing that, sir? Mr. Van Walker. We instituted those meetings, sir, roughly 18 months ago at that level of intensity. There were always weekly meetings for MDC and management, but we have certainly increased the level of interaction of the number of participants, especially on the security side, in the past 18 months. Mr. Greenwood. When does the current contract expire? Mr. Van Walker. This contract expires for--and I should point out that the web hosting contract is actually, because of the interaction between AT&T and IBM, a subcontract within the MDCN contract itself. So they expire simultaneously in December of this year. Mr. Greenwood. Okay. And are you in the process or where do you stand in terms of drafting the new contract? Mr. Van Walker. We are using a GSA contractor to assist us in identifying requirements for the new vehicle. We are having discussions with GSA, with the Department of Interior, with other agencies about vehicles they already have in place. And in whatever contract we issue, the explicit types of security requirements that you and the other witnesses have outlined would be included in that. Mr. Greenwood. How about testing? Mr. Van Walker. Testing, obviously, is one of those requirements, and the types of ongoing, sustained testing programs clearly is something that we agree is a necessary base requirement. Mr. Greenwood. We have found that consistently, as we have been involved in this process for some time. Let me address a question, if I could, to Mr. Vengrin. I would like you to refer, if you would, to document number 3 in the binder. Do you have that before you? This is the Department's accountability report for fiscal year 1997. On page 23, it says--I will let you turn to page 23--it says, ``data security remains a major concern at the HCFA Central Office. Our prior year review demonstrated weaknesses in EDP, which stands for electronic data processing controls, through a system penetration test in which we obtained access privileges to read or modify sensitive Medicare enrollment, beneficiary, provider, and payment information. Although HCFA immediately corrected the prior year vulnerabilities, our current year tests resulted in penetrating the mainframe data base. We obtained the capability to modify managed care production files.'' You tell me about this test that penetrated the mainframe, and is it true that you were able to actually alter Medicare payment amounts without HCFA's knowledge? Mr. Vengrin. Yes, Mr. Chairman. I remember that event very well. With the permission of HCFA, we entered the system with a very low-level password, and one of their employees was sitting at the terminal. By entering this system and accessing it with a low level password, an individual from one of our contractors was able to go in and identify basically common passwords that were left on when the system was first put on, like ``Hot Site''; that password was not removed, and it was a high-level password. And with that, we were able to upgrade the low level and enter the managed care file. And HCFA wanted a demonstration that we explicitly could alter a payment, so we identified a beneficiary payment. We actually altered it, put ``zero, zero'' in there, and that concluded the test. So we effectively penetrated the system. Mr. Greenwood. And the purpose of that exercise, I presume, is to demonstrate that an unethical hacker could in fact steal money from HCFA by altering the amounts due on bills to virtually any number he choose. Mr. Vengrin. That is correct, sir. Passwords such as those should be removed. I believe immediately after that test they did remove that password. Mr. Greenwood. Sort of like breaking into Fort Knox. What was HCFA's response to this test? Mr. Vengrin. Mr. Chairman, they did immediately remove that specific vulnerability, and also they advised us that they would have to go back and check and cross check to make sure that the alteration of the payment amount didn't actually get out to the beneficiary. It did take several days to reconstruct it and validate their data base, so they did kind of complain that it was a disruption to the operation. Mr. Greenwood. Well, isn't it true that not only did they complain but they refused to permit subsequent testing that would be that in-depth ever again? Mr. Vengrin. I believe it would be correct to say that we specifically have not reperformed that level of testing. In talking this level of testing over with Dr. Christoph, I think he would prefer to do a higher level of penetration---- Mr. Greenwood. Could you identify him, for the record? Mr. Vengrin. Dr. Christoph, I am sorry, is the CIO at Health Care Financing Administration. And he would prefer to do that level of testing with individuals that he would choose, which we don't have a problem with. Mr. Greenwood. Do you have any indication that in fact he has done that? Mr. Vengrin. Again, he did contract with En Garde to do some of the higher level penetration testing. Mr. Greenwood. Okay. In 1997--let us see--do you think that the CFO audit tests that you have been conducting since 1997 have been sufficient when it comes to penetration tests? And if not, what would you propose? Mr. Vengrin. No, sir. As we have told many of the committee members, since fiscal year 1998, or actually from 1997, our objective was to do more of the higher level intrusion testing procedures. But as we proceeded in fiscal year 1998, it was pretty unanimous that the Medicare contractors refused to allow us to do the high-level procedures. They wanted specific indemnification. Should our contractors do this process, the higher level scans, and disrupt operation, the medical contractors specifically wanted to be indemnified for any loss. For many of these contractors, Medicare is a small part of their business function--in some cases it could be 40 percent-- so if it resulted in a disruption of operation, they wanted to be paid for it. And, unfortunately, we have not been able to successfully resolve that issue. There are legal ramifications, which HCFA can address. Mr. Greenwood. Well, how valid is that concern? Should they be concerned that there is some real exposure there at these tests that require that kind of indemnification? Mr. Vengrin. Mr. Chairman, I have consulted with experts in the field, and as some of our colleagues here have testified, depending on bad configuration, yes, it could shut the operation down. As you do this intense scan, some of the configuration could identify this as a vulnerability, and basically the walls would come down and shut off operations. So no one can guarantee us, sir, that that is not a potential, and hence we would be very dubious about doing further work. Mr. Greenwood. Let me ask Mr. Neuman a question in that regard. This is what you do for a living. Is the state-of-the- art such that you can't do these kind of in-depth penetrations without in fact risking clobbering the system like that? Mr. Neuman. We have done tests for over 100 customers, and we do very in-depth testing. In one case, we brought down a system that we did not intend to. It was back up in a couple of minutes. But there is the possibility of stopping access for at least a short period of time. The possibility of corrupting things such they are unrecoverable is probably very low, but denying service for a few minutes is a reasonable risk. Mr. Greenwood. Okay. Back to you, Mr. Vengrin. This document that I refer to also states, ``Moreover, our system penetration tests revealed additional control problems, which could be exploited by unauthorized individuals to compromise one or more of HCFA's computer systems.'' Can you explain what these additional control problems were? Mr. Vengrin. Mr. Meyers? Mr. Greenwood. Or Mr. Meyers. And, Mr. Meyers, if you--yes, thank you. Mr. Meyers. Yes. The work that we do as a part of the CFO audit splits down between the general control and the application control reviews, as well as the intrusion protection review. The bulk of the focus thus far has been on intrusion protection, but when you get into the area of general controls, entity-wide security, which is the big issue, as well as access control, we found numerous repeat conditions present since 1997. Some of those areas involve the security program that is being developed at either HCFA Central Office and/or its contractors. Those programs could be viewed as an umbrella operation to, one, bring the proper level of management oversight into the whole security environment. It would deal with the accreditation of systems as mandated by various legislation or guidance, like OMB A-130 or the FIP Publications, a very critical function in ensuring that you have an effective security environment to deal with this process. We have also noted findings in the area of system software, findings in service continuity, and findings in the application control area, which were alluded to earlier, in the area of change development and application controls. Mr. Greenwood. Thank you. Question to Mr. Neuman. I would like you to refer in your binder, if you would, to document number 6. Mr. Neuman. All right. Mr. Greenwood. That is your document, I believe, written by En Garde to HCFA, dated November 16, 1998, in which En Garde states, ``Given the trust vested in the secured network run by IBM at the time, provisions for independent third party penetration testing should be negotiated with IGS and added to the contract. Recommend at least annual testing of all servers hosted by IGS and the blank firewall maintained by IGS for HCFA.'' Now, if you would skip a sentence, and then it reads, ``In addition, recommend testing to verify that HCFA cannot be reached from the Internet through the secured network or from another customer site on the secured network.'' These sound like very sensible recommendations. What was HCFA's reaction to this memo, and did they permit you to conduct all of these recommended tests? Mr. Neuman. Their reaction was that they were good ideas. We were permitted to perform the test of their web server. We were not permitted to test from other secured network partners and other secured network customers which were not partners with HCFA. So we tested one out of the three of our recommendations. Mr. Greenwood. Ms. Adair, a subsequent document dated July 6, 1999, it is document number 7 in your binder. Do you have that there? It is a work order for a statement of work that includes the three En Garde recommended tests. HCFA's Internet vulnerability, MDCN partner vulnerability, and non-MDCN/IBM customer vulnerability. We know that En Garde was permitted to do the first test under very limited conditions. That is what Mr. Neuman just spoke of. But why hasn't HCFA followed through on these other two tests in the 2\1/2\ years since they were made? Do you not think it is important to conduct such tests of the alleged secure network? Ms. Adair. I believe, sir, that the answer to the question is, as you pointed out, that we did the first one, we negotiated that, and we have, to date, not been able to negotiate the capability to do the additional tests that are listed here. Mr. Greenwood. Negotiate with whom? Ms. Adair. The MDCN contractor. Mr. Greenwood. Can you elaborate on that? I mean what has prevented in 2\1/2\ years--they work for you, right? Ms. Adair. Yes. Mr. Greenwood. What do you pay for that contract? Mr. Van Walker. The current billings under the MDCN contract, Mr. Chairman, I believe, are in the area of $18 million for all services combined. Mr. Greenwood. Annual figure? Mr. Van Walker. That is this year's figure. It would be in the neighborhood of $15 million to $20 million in every year, sir. Mr. Greenwood. Okay. So we are paying these guys that amount of money, and in 2\1/2\ years you have not been able to negotiate with them to have these other tests performed. Mr. Van Walker. Right. Mr. Greenwood. Which were recommended by your own independent contractor. Mr. Van Walker. Essentially, the position taken by the vendor in this case is that indeed they were surprised that we were even able to negotiate such an arrangement on a one-time basis with the web hosting vendor, that it is not standard industry practice to allow this, that the danger we would bring to their ability to manage their entire network and the operations of their other customers is so severe that it is simply inappropriate for them to do so. We continue to have discussions about how we can get around this and even have gone so far as to talk to them, if we can't do it using our own third part resources, what are the possibilities of using their internal white hat ethical hacking teams to do it in a situation in which HCFA would largely define the terms of that and would have access to additional information. That seems at least to be a possibility, and we are continuing to explore that, sir. Mr. Greenwood. Mr. Neuman, I would be interested in your response to that. From what we have just heard, one would conclude that you recommended two tests that their vendor says are highly unusual and not state-of-the-art and not willing to engage in. So one would tend to think that either you are making unrealistic recommendations or the vendor has unrealistic expectations. Mr. Neuman. Well, the first test that we did, I believe, took over a year to negotiate with them. So I am not terribly surprised that they are making it difficult. What we are proposing is very simple. What we are proposing is simply to go from an MDCN partner, see what you can do to HCFA, from a non- MDCN partner, see what you can do to HCFA. That is it. Touching the infrastructure in the middle is--you are not really hurting the contractor in any way. Mr. Greenwood. And I would assume that you have not been able to negotiate this pursuant to existing contract. What about the future? What does the future hold in terms of contractual language that would enable you to do this? Mr. Van Walker. Certainly we would attempt to get this clause that there are some limitations here. While web hosting is pretty much a commodity practice and we could, without too much disruption to our operations, replace that vendor with another one who might be more willing to allow this kind of testing at the network level--and the HCFA network is somewhat unique. It is not based on current Internet technologies. It uses a combination of Internet technologies and older SNA technologies to do very specific things that are largely concentrated in the financial and insurance industries. Replacing the vendor would be a difficult multi-year process for us, so our efforts are focused on attempting to work out an accommodation with the vendor that would allow us to do these tests or have these tests performed by them, using guidance, strictures, requirements for which we would get assistance perhaps from the Inspector General's Office, perhaps from firms like Mr. Neuman's to attempt to work out a situation in which we would have further assurances, as you have pointed out, that what they say they are doing is indeed what they are doing. And we have routine, ongoing security briefings from them about the various types of technologies that are being deployed and about ongoing enhancements to the network. But the ability to compel them is not within our power at this time. Mr. Greenwood. But you can tell them in your discussions that you are under intense pressure from the Oversight Investigations Subcommittee now. Mr. Van Walker. I believe reading the testimony on your web site will more than accomplish that, Mr. Chairman. Mr. Greenwood. Thank you. Turn to Mr. Neuman again. In a memo that you wrote to HCFA on October 14, 1990, which is document number 10 in your binder, you alerted HCFA to the serious configuration problem with the IBM web servers. You identified this problem as a major vulnerability, because, ``Anyone on the Internet can access internal HCFA systems.'' In particular, you focused on an architectural problem that the external HCFA web servers are, ``dual-homed.'' Your testimony talks about the ease with which that attack was accomplished remotely and the lack of sophistication that was required. In the memorandum you sent, document number 10, you state, ``The web server had absolutely no protection from remote modification.'' In the full report you issued to HCFA about the successful attack, which is document number 11, you stated that, ``The compromise of the external server allowed us, from the Internet, to send and receive arbitrary data with internal HCFA systems.'' What does that mean in lay terms, and can you explain what you could have done with this level of access to the web server if you had been intent on malicious activity? Mr. Neuman. In layman terms, it means exactly that. From the Internet, we were able to access any system inside HCFA's network. No fire walls prevented us, no filters, nothing blocked us from connecting to any service, any server on the HCFA network. We weren't tasked to go any further than simply gaining access, so we weren't told to go and try to modify patient data or anything like that. Mr. Greenwood. Okay. At the time of you work, in a report issued on October 27, 1999, which is document number 11, you recommended that HCFA discontinue dual homing of its web server to prevent someone from being able to do what you did--attack the web server to get access to internal networks and computer systems. Can you explain what it means for a web server to be, ``dual-homed,'' and explain why that poses such a vulnerability for HCFA? Mr. Neuman. Sure. This particular web server was connected both to the Internet and it had a separate distinct connection to the secured net. And through the secured net, it was connected into HCFA's internal network. So dual homing means it not only is connected to one network but two. And in fact in this particular machine, it was actually triple-homed. It was connected to the Internet, to the secured net, and to an IBM administrative network, which sat off somewhere else. We specifically were not allowed to test the IBM administrative network. We were not allowed the test the firewalls, any of the infrastructure, anything else there, just the web server itself, and from the web server find out what we can do to HCFA from there. So there are more serious implications for this multi- homing. Eliminating the dual-home into the MDCN is good, but remember it is also still connected into the IBM administrative network. So if I can get into the administrative network, where can I go from there? There is lots of transitive trust issues which are interesting. A trusts B, B trusts C, therefore A trusts C. It is the same thing. So there are a lot of potential problems that exist, even with removing that back channel, because HCFA still has a connection to the MDCN. It is lots better than it was before. If you are going to attack HCFA, the most obvious target is to go to their web server. That avenue has been directly eliminated. But there are some indirect attacks which remain. Mr. Greenwood. Yesterday, HCFA notified the committee that after 2 years it has finally decided to eliminate the backend web server connection that you exploited. Does this solve all the problems--I think you referred to this, but let me ask you formally, for the record--does this solve all the problems associated with remote penetration of HCFA's internal systems and its Medicare Data Communications Network? Mr. Neuman. Not at all. It helps a lot, as I said. It does not completely solve the problem, because IBM is doing things that they don't tell us about. And we know for sure that they have multi-home systems that still exist. In addition, this is the way that they have been providing web servers for a long time. So not only is HCFA's web server dual-homed into the secured network and the Internet but all the web servers are. So, again, if you can break into one of them, what does that mean to HCFA? There are some serious implications there. Mr. Greenwood. Okay. Ms. Adair or Mr. Van Walker, either one of you, 2\1/2\ years ago you have got the recommendation about the dual homing. Nothing happens to respond to this in terms of the disconnection until a couple of days ago. One might have reason to think that the fact that you called yesterday to tell us that you made that disconnection might have something to do with this hearing. What happened in the intervening 2\1/2\ years? What caused you to decide a few days ago to disconnect? And what is the--is that a permanent change? Ms. Adair. Excuse me. Immediately after the report that we got from En Garde, we did some corrective actions that we believe would assist us. There were some firewalls misconfigured that we had immediately corrected. It is true that---- Mr. Greenwood. Did you follow up and test those changes after you--test the system after you did this? Ms. Adair. No, we did not. We did not. But in conversations that we had with some of your staff last week and when we went back and conversed amongst ourselves, we decided that, in taking another look at it--something we should always be doing in taking a look at security is looking and relooking--that it was indeed a risk that we no longer wanted to take. And so we, in fact, what is commonly referred to, I guess, is air-gapped ourselves from that. And we thought it was a prudent thing to be doing. Mr. Greenwood. Does it create any problems for you? Ms. Adair. It causes us, in order to update--I mean it is a web server to which we put public information out. It does cause a little bit more cumbersome process for us to be doing the uploading, but we have decided now that that is a burden that we are willing to take. I would, again, mention that subsequent to getting--immediately subsequent to getting--the report, changes were made in our updating relationship, changing the router, putting the communication in one way. But, again, in conversation last week with your staff, as we relooked at it, we decided to take an additional step in air- gapping. Mr. Greenwood. We will keep these staff on board for a little while. Mr. Neuman, back to document number 11. You recommended that HCFA, ``Consider adding a substantial firewall between its secured network and the HCFA internal network.'' Why was this recommendation so important, and how would it have helped HCFA with its security problems? Mr. Neuman. Well, the problem is that right now--well, at the time that I last tested, that this test was done, there is absolute trust of the secured network by HCFA. There is no protection there at all. There was no protection there at all. So putting all of your trust into a contractor that won't divulge its methods, that has had known vulnerabilities that we couldn't fully test seemed a prudent thing to do. Mr. Greenwood. My understanding is that some of the contractors, the fiscal intermediaries, have in fact taken this recommendation and employed it. Is that your understanding? Mr. Neuman. I have no knowledge. Mr. Greenwood. Okay. Let me go back to you, Ms. Adair, if I could. I understand that HCFA chose not to implement either of En Garde's recommendations: discontinued dual homing of the web server between the Internet and HCFA's secured network, and also it chose not to add the recommended substantial firewall between the secured network and the internal network. As an attachment to document number 16, HCFA provided the subcommittee with an internal email in which a HCFA employee states--do you have that in front of you, document 16, ``I had discussions with our techs, and we decided not to install the firewall to MDCN at this time. We know that this should be done, and we will do so once a plan is developed and after Y2K Day One.'' Y2K Day One was 18 months ago. Has HCFA added the firewall specifically recommended by Mr. Neuman and apparently agreed to by HCFA? And if not, why not? Mr. Van Walker. Just one moment, please, Mr. Chairman. Mr. Greenwood. Take your time. Mr. Van Walker. I guess there are two points there, Mr. Chairman. In as far as the dual homing goes, just to recapitulate on that one, what HCFA did at the time, Mr. Neuman had actually recommended that we do those exchanges using a virtual private network, an encrypted Internet technology, a fairly standard technique. What HCFA chose to do during that period instead, prior to the air-gapping of this week that you have already discussed, was to establish a situation in which the HCFA connection into the web hosting forum at IBM was essentially a one-way path. Protections were placed on that circuit so that HCFA could move content up to IBM, but no one from the IBM facility could use that same circuit to get back down into HCFA and into its stated infrastructure. The step that we took this week was to actually create a machine that is not connected to anything else at HCFA at all to serve that purpose. That is what air-gapping means in this case. As far as the extended network, HCFA's step for that protection is not to allow anyone who has access to MDCN to access any facilities at the HCFA Data Center or its other contractors. We use a technology or a process called access control list to determine which of our partners can do which things and use that then to filter, as you would, the traffic coming into HCFA. So it is not accurate to state that anyone who has access to the network can get to HCFA and get to the underlying resources. And we use this technology, I believe, on all of the HCFA routers. So, in a sense, the HCFA routers are providing a functionality similar to what firewalls would provide. Mr. Greenwood. Well, let me ask Mr. Neuman if he would comment about that. You heard Mr. Walker's response. He seems to think that the routers are accomplishing what the firewall would have accomplished. It is my understanding that, again, that the--you said you didn't have information about this, but it is my understanding that some of the blues have--they don't have the trust of the network that you seem to have, and they have erected these firewalls. Let me first ask Mr. Neuman if you would respond to what you heard Mr. Walker say. Mr. Neuman. I think it is possible to do filters correctly; again, it needs to be tested. Mr. Greenwood. And you have not tested yours. Mr. Van Walker. We have not conducted the type of third party penetration test, but we certainly have gone through the rules and reviewed them---- Mr. Greenwood. And that is because you have not been able to get that negotiated---- Mr. Van Walker. To conduct the type of test we talked about, sir, yes. Mr. Greenwood. Ms. Adair, as part of the materials provided by your office to the subcommittee, HCFA provided document number 19, which describes HCFA's new contractor security initiative. This document, dated June 26, 2000, indicates that as of that time, HCFA's contractor security requirements were not current and had not been updated since 1992. Specifically noting that this was, ``Before the days of email, Internet, hackers, viruses.'' It also states that current HCFA requirements, ``Do not reflect requirements from GAO and IRS audit guides,'' and, ``Don't include all requirements for HIPAA, which is the Health Insurance Portability Act, Presidential Decision Directive 63, HCFA internal policies or industry best practices.'' I understand that on January 26, 2001 HCFA implemented a new security memorandum to program intermediaries, finally updating the outdated requirements, document 21, which is-- document 21 describes what I just read. What is going on here and why did it take HCFA almost 10 years to update its outdated contractor security requirements? Ms. Adair. I believe that during that time, since 1992, sir, what we had been doing is not necessarily updating our manual and putting in one place what all of our requirements were. We had been putting them out in individual memorandums to our contractors. We had been talking to them about them in meetings. And we felt that in starting down the path of our security initiative that it was important to bring them all up to date in one place and be very clear about what our expectations were to our contractors. That, in essence, putting out the clear expectations was the first way that we could start to really fulfill our oversight responsibilities. We needed to be clear about what our expectations were and what we were going to hold them responsible for. Mr. Greenwood. In the reports provided to the subcommittee, the only penetration tests of Medicare contractor security that were provided were limited penetration tests conducted in 1998 of four specific Medicare contractors. This was a penetration test performed for HCFA by an independent accounting firm of only 4 of the over 55 Medicare contractors, and there does not appear to have been any more recent testing done by HCFA of its Medicare contractors. Why hasn't HCFA required more substantial testing of its Medicare contractors? Ms. Adair. The four tests that you are referring to were of the Medicare contractors, we did do those and we used those as an opportunity for us to shape what our security initiatives should look like, that we needed some input as to what was the state of what was out there. And we used that as input. There is a period of time in there, sir, that HCFA, as many other organizations, put a moratorium on much of our IT work as we were doing the remediation efforts for Y2K. Coming out of the Y2K effort, however, we have put, as I indicated in my last answer, we have put out there a security initiative with what our expectations are. And the contractors right now are in the process of evaluating their own performance relative to our requirements. We will be talking to them about how it is they are going to get up to our standards, and we will be going back and testing subsequent to them making their remediations. It is also important to note that during that period of time there were other avenues of oversight of our Medicare contractors in these areas. The IG does in fact do testing for the CFO audits. There are what we refer to as statement of auditing standards, which are internal control processes that happen at our contractor shops. These corrective actions come in to us, we evaluate them for reasonableness, and then ask them to follow up. In addition, the IG, after having done a full-blown CFO audit, the next year goes out and does a follow- up if there are findings. And we use the information of those to oversee our contractors. Mr. Greenwood. Thank you. The Chair notes the arrival of the vice chair of the subcommittee, Mr. Whitfield. And if he is ready, recognizes the gentleman for 5 minutes for questions. Mr. Whitfield. Mr. Chairman, thank you very much, and I apologize for being late to this important hearing. I was actually in another hearing, and delighted I made it over here before you all recessed or concluded your remarks. Mr. Neuman, I was looking through this book last night, and this document 18 in the binder, the En Garde Systems document test report, which is dated June 7, 2000, was a test conducted by your company of HCFA's internal systems and internal penetration tests from the perspective of a HCFA employee that should not have access to sensitive data bases. Now, your report found quite serious problems in this desktop environment, which I understand HCFA has acknowledged and is moving to remedy. But the document on page 3 of that report says, ``While it is clear that HCFA has put in place many of the proper precautions, the practice of creating all accounts with administrative permissions negates almost all the security precautions taken on the internal network.'' And I was wondering could you just elaborate or explain what that statement actually means or refers to? Mr. Neuman. Sure. The way that the desktop PCs were set up there was no delineation between administrators who had complete access to everything on every system on the entire network and normal users. And, in fact, normal users had access to everything on every machine on every network. Once you have that level of access, it is trivial to gain access to anything else on the network you want to. You capture that machine, you watch and see them type passwords or log into machines or do whatever. You have unlimited access to PCs at that point. So we feel that that is a significant risk in the sense, first of all, you really don't want average users to have unlimited permission; second, their ability to destroy things, even accidentally, is pretty high too, so there are both management and security reasons why you probably don't want this kind of setup. Mr. Whitfield. But that is the current setup; is that correct? Mr. Neuman. Well, we last tested early 2000 so I don't know. Mr. Whitfield. Okay. This report also went on to say that ``Problems reside with the policy and access configuration management and security administration. Several major findings include poor choice of administrator passwords by contractors, loosely configured network infrastructures, like printers and token ring cards, administrative privileges given to every new user.'' And then on the next page, it reads, ``That it was possible to obtain the encrypted passwords for accounts on the machine. We also downloaded, through the HCFA web proxy, that is a password cracking tool, and using this tool we were able to crack passwords on our machine. And then using those passwords were able to obtain further encrypted passwords from virtually every configured machine.'' I wondered can you describe just how easy it was to guess or crack these passwords, including those of the systems administrators who have unlimited access to the system? Mr. Neuman. It was a trivial event. We found probably 50 to 60 passwords that were the users' name. So, for example, your user name is Whitfield, your password is Whitfield, that sort of thing. The administrator password, if I told it to you, you would laugh; it was that badly done. Mr. Whitfield. Okay. Well, don't tell me then. Of course you were not asked to fully penetrate the system, but based on the level of access that you were able to obtain, do you think you could have obtained sensitive--access sensitive medical information of Medicare beneficiaries? Mr. Neuman. Without a doubt. I had the ability to control anybody's PC in the organization. Mr. Whitfield. You did? Okay. Now, Ms. Adair, to follow up on this, roughly 8 months after receiving that June 2000 report, HCFA hired another ethical hacker called Allied Technology to conduct essentially the same set of tests on your desktops. And Allied found virtually identical results, I have been told, and in fact document 23 in this binder says that ``The security assessment of the HCFA work station environment shows that an internal user with normal access may uncover vulnerabilities during an exploit attempt of the HCFA network that would allow further exploit of the HCFA network enterprise and its connected systems.'' And then it goes on to say that, ``In its attempts to successively subvert several user and administrator passwords, Allied Technology discovered blank easily cracked and poorly managed passwords, both from user as well as administrator accounts.'' And then further down, it says that ``Allied Technology was able to use remote-shared connectors to install a password-cracking tool downloaded from the Internet, which was then used to crack passwords on other shared systems.'' So it would appear on these two sets of audit results that HCFA made virtually no progress in addressing the deficiencies identified in the prior year, including the basic actions such as preventing the downloading by HCFA employees of hacker tools on the Internet. Why not and why would HCFA spend the money to do the same battery of tests without taking some corrective actions? Ms. Adair. Let me address, first, your question on the passwords. Passwords are something that we are working very hard on. It is trying to convince people to not use easy passwords. It is a cultural change for individuals. We have a lot of numbers or passwords that we have to remember, for your ATM, for your whatever, and people have a tendency to want to use something such as their children's name, their last name. We are trying very hard to convince people that that is ripe for problems. We work difficult--we work--in trying to work--I am not saying this sentence well, I apologize. We are trying to work with them to enforce that those kinds of bad habits have unintended consequences for us. In addition, we are exploring technology that we could use that would allow us to go in and take a look at passwords and notify people, ``You have passwords that are way too easy. Let us move away from that.'' As well as something that would allow us, through technology, to enforce the policy standards that we have put out since that test result. We are making that kind of progress since that time. Let me think what your other question was, sir. The systems administrator, as I understand it, is that we right now have allowed privileges at the desktop that I think that many of us would say should not be there. And the reason that we have done that is that we think there is, at this point in time, for us, an outweighing benefit, which is it allows us to push out anti- virus updates that we get on a timely basis that we would otherwise have to go out and touch each machine to do. And therefore it would not allow us, as effectively, to counteract such things as the Melissa or the ``I Love You'' virus that were out there. We don't believe it is the best place for us to be, but in order for us to be there, we had to initiate from the first report a rather long life cycle to move us to a place, and we believe that we will be there in the November timeframe. As was discussed earlier, that when we get some of these findings, some of them are fixes that we can do within an hour. Other fixes take us a longer period of time in our complex environment to get us, and this was one of those fixes. Mr. Whitfield. But do you feel comfortable in the progress you are making at this point? Ms. Adair. I believe we are making progress. I certainly would like it to be faster progress. Mr. Whitfield. So you don't feel comfortable with it. Ms. Adair. I believe that we are doing what we can, yes. Mr. Whitfield. Okay. Okay. Now, the Allied report also found that the HCFA network was susceptible to certain denial of service attacks, mostly due to HCFA's failure to stay up to date with software patches issued by your vendors. In fact, this report said that you are several service packs behind, leaving a system with dozens, if not hundreds, of known vulnerabilities. Now, why can't HCFA expedite the process of updating its patches? Ms. Adair. Before we apply a patch, sir, to our system, we go through a rather rigorous testing scheme, and perhaps we, in that process, are not as quick as we could be. Mr. Whitfield. You go through a what now? Ms. Adair. Rigorous testing regime to make sure that the patch to the system we are putting in doesn't have an unintended consequence to something else or how we have set up our operation. Mr. Whitfield. And that is pretty time consuming? Ms. Adair. It can be, yes. Mr. Whitfield. Mr. Chairman, I don't have any other questions. Mr. Greenwood. Thank you. I just have a couple more questions. Let me address one to Mr. Vengrin. There is a document that was provided to us by HCFA that is dated October 14 of 1999, and it is number 8 in your binder, if you would turn to that. Got it? It references a penetration test conducted by your office's contractor, Ernst & Young, of HCFA's Central Office for fiscal year 1999. The document states, ``HCFA provided a detailed documented description of the testing to be performed and the list of IP addresses to be targeted. This is a deviation from the approach Ernst & Young has used for the other selected HCFA contractor sites and does not allow Ernst & Young to fully explore possible vulnerabilities and new exploits.'' Can you explain why it is that HCFA took this approach to this test, how it differed from your tests of other HCFA contractor sites, and what the implications of these changes were for understanding the full extent of HCFA's central vulnerabilities? Mr. Vengrin. Yes, Mr. Chairman. And Ed can elaborate more on this. I believe our contractor was attempting to do more work, but HCFA was going to contract with others, such as En Garde, to do this work. And, therefore, the scope of the CFO work was to be curtailed and cut back. So a lot of the Central Office work that we had planned under the auspices of the CFO Act just has not been performed since fiscal year 1997. Mr. Greenwood. Ms. Adair, do you concur with that? Or Mr. Van Walker, either of you. Ms. Adair. Pardon me, I am sorry? Mr. Greenwood. Either one of you, do you concur with that assessment? Ms. Adair. As you know, we have engaged contractors to take a look at ourselves, and I believe that we do want to work with the IG to ensure that we are not duplicating but in fact complementing our work efforts, that we would not want to--both of us have precious resources, and we would want to ensure that they went as far as they could. Mr. Whitfield. Just one more question. Mr. Vengrin, in your fiscal year 2000 audit report, which was document 22 in our book here, you stated that on several occasions that internal users of the Medicare system had inappropriate access to sensitive beneficiary information. And I was wondering if you might just be able to describe some of the examples from your individual site reports? Mr. Vengrin. Yes, sir. We noted cases in which programmers had inappropriate access to system logs. This provided an opportunity to conceal improper actions and obviated the log's effectiveness as ``detect'' controls. There were a number of cases where the programmer had inappropriate access to beneficiary history files. There should be a segregation of duties so that a programmer would not have access to this level of production. That would give them an opportunity to go in there and possibly effectuate a payment. We found numerous instances of these types of problems. Mr. Whitfield. Where they effectuated a payment? Mr. Vengrin. No, sir; where there is an opportunity. Mr. Whitfield. An opportunity. Mr. Vengrin. Yes, sir. Mr. Whitfield. Okay. Mr. Vengrin. There is just the potential. Mr. Whitfield. All right. Now, this same report also discusses the external threat to the contractor systems. How real do you think that the Internet-based threat is at the contractor sites? Mr. Vengrin. Sir, unfortunately, we have been doing a very low level of testing. That said, vulnerabilities have been detected through footprint analysis and some of the war dialing. We have identified cases where manufacturers' identification of passwords was left on. Second, very, very simplistic passwords were identified. For example, ``manage'' or ``manager.'' We could actually do a penetration test had we been permitted to go further. So we noted numerous instances where passwords were a problem. Mr. Whitfield. Okay. Mr. Meyers. If I may add to that. Mr. Whitfield. Yes, sir. Mr. Meyers. Additionally, when you are trying to make a determination on the risk, you sort of have to look at it as a math formula. You have a vulnerability, and we know that vulnerabilities exist in these systems. You then have to factor in whatever potential impact there may be to that vulnerability, and then offset it with the controls that are present. As HCFA goes through its current information security reassessments and enhancements, that business impact, that financial impact potential has to now be rolled into all the identified vulnerabilities that we know are present. Once you do that, then you come up with the appropriate countermeasure or control, and your risk then becomes a management decision as to ``Do I want to accept this level of risk; can I live with it, or is it a situation where the controls have to be augmented immediately?'' But the benefit and the cost cannot adequately be addressed until you factor in the potential impact of all the identified vulnerabilities. Mr. Whitfield. Okay. Thank you. I appreciate that comment. Mr. Greenwood. Thank you, Mr. Whitfield. One final question for Ms. Adair, and then we will break for lunch. We will adjourn the hearing. Tell us what HCFA's computer security resources consist of. How many people do you have focused specifically on computer security to monitor daily network and web hosting transactions, to evaluation operational procedures, to ensure staff and contractor compliance of security requirements, and to recommend enhanced security policies? How many people do you have doing this? Are we looking at them? Ms. Adair. No, sir. We fortunately have more than this. We actually have--we have doubled the number of people like in the last 3 years that are dedicated to computer security. I would say that we have gone from somewhere in the 30 area, and we are now essentially at 60 FTEs. And I point that out, because it is not necessarily people per se, but sometimes they are in our-- for example, in our regional office, those that are going out and doing the oversight of our Medicare contractors. They may be doing some other additional activities. So I think that we have made some great strides there. Mr. Greenwood. Have you made a specific request for additional funds from the $30 million that the Secretary has testified before one of our subcommittees that he intends to seek for computer security purposes? Ms. Adair. As you point out, sir, that is in the budget request this year, so we have not yet made any requests against it. It has not yet been appropriated. I think that we would certainly view that as additional security needs come up that we would apply, I think would be the right words, for those funds should it be appropriated. Mr. Greenwood. Okay. We thank you. One suggestion I might make is that you said that with regard to passwords that you are encouraging your employees to change their passwords. You might want to just tell them to do that. Ms. Adair. And I probably did not say it. We have changed the policy, and it is. If I may take a second of your time? Mr. Greenwood. Please. Ms. Adair. It was, I think, earlier this month at about the time that I was talking to your staff that I was addressing a security session that we had in our auditorium, and I took the opportunity at that time to tell our staff not only that we were having conversations with you and use that to in fact enforce to our staff how important this was, but at the same time to discuss the passwords. So hopefully the two of those being mentioned together was of assistance to us. Mr. Greenwood. Okay. Thank you. Ms. Adair. Thank you. Mr. Greenwood. When I came to Congress 8 years ago, I remember that the Congressional Institute put on a conference that they annually do, and all of the Members of Congress went out to conference for a couple of days. And one of the things that they had available to us was an opportunity to surf the World Wide Web, and nobody knew what it was. And I think that is telling all of this has happened very quickly. This technology has emerged very quickly and changed the way we do business. This whole hearing would have been completely unintelligible to people just a very few years ago. So we know that the technology changes very quickly, that the challenges emerge very quickly. As I said in the beginning, we are pleased with much of what HCFA has done. I think this whole process leading up to this hearing as well as today's dialog gives us--hopefully gives HCFA some direction as to what our expectations are. Hopefully the recommendations that I specifically made in my opening statement--I will provide you written copies of that if you would like--will be implemented, particularly in connection with the new contracts that you are in the process of negotiating. We look forward to working with you in the future to follow up on these discussions. And thank you again for being here. I would ask unanimous consent to enter into the official record all of the documents that we have referenced today. Hearing no objections, it is so ordered. Mr. Greenwood. Thank you again, and the hearing is adjourned. [Whereupon, at 12 p.m., the subcommittee was adjourned.] [Additional material submitted for the record follows:] [GRAPHIC] [TIFF OMITTED] T2833.072 [GRAPHIC] [TIFF OMITTED] T2833.001 [GRAPHIC] [TIFF OMITTED] T2833.002 [GRAPHIC] [TIFF OMITTED] T2833.003 [GRAPHIC] [TIFF OMITTED] T2833.004 [GRAPHIC] [TIFF OMITTED] T2833.005 [GRAPHIC] [TIFF OMITTED] T2833.006 [GRAPHIC] [TIFF OMITTED] T2833.007 [GRAPHIC] [TIFF OMITTED] T2833.008 [GRAPHIC] [TIFF OMITTED] T2833.009 [GRAPHIC] [TIFF OMITTED] T2833.010 [GRAPHIC] [TIFF OMITTED] T2833.011 [GRAPHIC] [TIFF OMITTED] T2833.012 [GRAPHIC] [TIFF OMITTED] T2833.013 [GRAPHIC] [TIFF OMITTED] T2833.014 [GRAPHIC] [TIFF OMITTED] T2833.015 [GRAPHIC] [TIFF OMITTED] T2833.016 [GRAPHIC] [TIFF OMITTED] T2833.017 [GRAPHIC] [TIFF OMITTED] T2833.018 [GRAPHIC] [TIFF OMITTED] T2833.019 [GRAPHIC] [TIFF OMITTED] T2833.020 [GRAPHIC] [TIFF OMITTED] T2833.021 [GRAPHIC] [TIFF OMITTED] T2833.022 [GRAPHIC] [TIFF OMITTED] T2833.023 [GRAPHIC] [TIFF OMITTED] T2833.024 [GRAPHIC] [TIFF OMITTED] T2833.025 [GRAPHIC] [TIFF OMITTED] T2833.026 [GRAPHIC] [TIFF OMITTED] T2833.027 [GRAPHIC] [TIFF OMITTED] T2833.028 [GRAPHIC] [TIFF OMITTED] T2833.029 [GRAPHIC] [TIFF OMITTED] T2833.030 [GRAPHIC] [TIFF OMITTED] T2833.031 [GRAPHIC] [TIFF OMITTED] T2833.032 [GRAPHIC] [TIFF OMITTED] T2833.033 [GRAPHIC] [TIFF OMITTED] T2833.034 [GRAPHIC] [TIFF OMITTED] T2833.035 [GRAPHIC] [TIFF OMITTED] T2833.036 [GRAPHIC] [TIFF OMITTED] T2833.037 [GRAPHIC] [TIFF OMITTED] T2833.038 [GRAPHIC] [TIFF OMITTED] T2833.039 [GRAPHIC] [TIFF OMITTED] T2833.040 [GRAPHIC] [TIFF OMITTED] T2833.041 [GRAPHIC] [TIFF OMITTED] T2833.042 [GRAPHIC] [TIFF OMITTED] T2833.043 [GRAPHIC] [TIFF OMITTED] T2833.044 [GRAPHIC] [TIFF OMITTED] T2833.045 [GRAPHIC] [TIFF OMITTED] T2833.046 [GRAPHIC] [TIFF OMITTED] T2833.047 [GRAPHIC] [TIFF OMITTED] T2833.048 [GRAPHIC] [TIFF OMITTED] T2833.049 [GRAPHIC] [TIFF OMITTED] T2833.050 [GRAPHIC] [TIFF OMITTED] T2833.051 [GRAPHIC] [TIFF OMITTED] T2833.052 [GRAPHIC] [TIFF OMITTED] T2833.053 [GRAPHIC] [TIFF OMITTED] T2833.054 [GRAPHIC] [TIFF OMITTED] T2833.055 [GRAPHIC] [TIFF OMITTED] T2833.056 [GRAPHIC] [TIFF OMITTED] T2833.057 [GRAPHIC] [TIFF OMITTED] T2833.058 [GRAPHIC] [TIFF OMITTED] T2833.059 [GRAPHIC] [TIFF OMITTED] T2833.060 [GRAPHIC] [TIFF OMITTED] T2833.061 [GRAPHIC] [TIFF OMITTED] T2833.062 [GRAPHIC] [TIFF OMITTED] T2833.063 [GRAPHIC] [TIFF OMITTED] T2833.064 [GRAPHIC] [TIFF OMITTED] T2833.065 [GRAPHIC] [TIFF OMITTED] T2833.066 [GRAPHIC] [TIFF OMITTED] T2833.067 [GRAPHIC] [TIFF OMITTED] T2833.068 [GRAPHIC] [TIFF OMITTED] T2833.069 [GRAPHIC] [TIFF OMITTED] T2833.070 [GRAPHIC] [TIFF OMITTED] T2833.071