<DOC>
[107th Congress House Hearings]
[From the U.S. Government Printing Office via GPO Access]
[DOCID: f:72833.wais]
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:
<bullet> External Penetration Tests (4). As an average outsider
connected to the Internet, we attempted to gain access to
internal HCFA resources.
<bullet> Internal Penetration Tests (2). Given a connection to HCFA's
internal network, we attempted to gain access to internal HCFA
resources.
<bullet> 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.
<bullet> 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.
<bullet> Test of Internet services hosted by IBM Global Services. At
the time we tested, HCFA outsourced its internal and external
web servers to IBM.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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:
<bullet> Administrators can only connect from a physically secure
administrative network
<bullet> WWW administration is done through an encrypted management
connection
<bullet> Patches are installed immediately after a vulnerability is
announced
<bullet> They would be happy to share their firewall's access control
lists with us
<bullet> They perform penetration testing every week
<bullet> They have a custom designed IDS along with 24/7 response
<bullet> The firewalls only allow WWW access through
Upon extensive questioning from ourselves and HCFA's CIO, it we
learned from IBM that:
<bullet> Administrators can also dial-in from home into a generic
``SecureNet'' modem bank, that all other customers use, and
administer machines.
<bullet> WWW administration can be encrypted, but they haven't enabled
that feature, and probably won't because it's difficult to do
so.
<bullet> Patches are only installed when an administrator gets around
to it, which is usually in a ``week or two''.
<bullet> 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:
<bullet> If they performed a penetration test every week, they would
have discovered this blatant vulnerability
<bullet> 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.
<bullet> 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