```

[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
    

```