U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON : 

For sale by the Superintendent of Documents, U.S. Government Printing Office

Internet: bookstore.gpo.gov Phone: toll free (866) 512–1800; DC area (202) 512–1800

Fax: (202) 512–2250 Mail: Stop SSOP, Washington, DC 20402–0001

72–833CC 2001

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

2

COMMITTEE ON ENERGY AND COMMERCE

W.J. ‘‘BILLY’’ TAUZIN, Louisiana, Chairman

MICHAEL BILIRAKIS, Florida

JOE BARTON, Texas

FRED UPTON, Michigan

CLIFF STEARNS, Florida

PAUL E. GILLMOR, Ohio

JAMES C. GREENWOOD, Pennsylvania

CHRISTOPHER COX, California

NATHAN DEAL, Georgia

STEVE LARGENT, Oklahoma

RICHARD BURR, North Carolina

ED WHITFIELD, Kentucky

GREG GANSKE, Iowa

CHARLIE NORWOOD, Georgia

BARBARA CUBIN, Wyoming

JOHN SHIMKUS, Illinois

HEATHER WILSON, New Mexico

JOHN B. SHADEGG, Arizona

CHARLES ‘‘CHIP’’ PICKERING, Mississippi

VITO FOSSELLA, New York

ROY BLUNT, Missouri

TOM DAVIS, Virginia

ED BRYANT, Tennessee

ROBERT L. EHRLICH, Jr., Maryland

STEVE BUYER, Indiana

GEORGE RADANOVICH, California

CHARLES F. BASS, New Hampshire

JOSEPH R. PITTS, Pennsylvania

MARY BONO, California

GREG WALDEN, Oregon

LEE TERRY, Nebraska

JOHN D. DINGELL, Michigan

HENRY A. WAXMAN, California

EDWARD J. MARKEY, Massachusetts

RALPH M. HALL, Texas

RICK BOUCHER, Virginia

EDOLPHUS TOWNS, New York

FRANK PALLONE, Jr., New Jersey

SHERROD BROWN, Ohio

BART GORDON, Tennessee

PETER DEUTSCH, Florida

BOBBY L. RUSH, Illinois

ANNA G. ESHOO, California

BART STUPAK, Michigan

ELIOT L. ENGEL, New York

TOM SAWYER, Ohio

ALBERT R. WYNN, Maryland

GENE GREEN, Texas

KAREN MCCARTHY, Missouri

TED STRICKLAND, Ohio

DIANA DEGETTE, Colorado

THOMAS M. BARRETT, Wisconsin

BILL LUTHER, Minnesota

LOIS CAPPS, California

MICHAEL F. DOYLE, Pennsylvania

CHRISTOPHER JOHN, Louisiana

JANE HARMAN, California

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

CLIFF STEARNS, Florida

PAUL E. GILLMOR, Ohio

STEVE LARGENT, Oklahoma

RICHARD BURR, North Carolina

ED WHITFIELD, Kentucky

Vice Chairman

CHARLES F. BASS, New Hampshire

W.J. ‘‘BILLY’’ TAUZIN, Louisiana

(Ex Officio)

PETER DEUTSCH, Florida

BART STUPAK, Michigan

TED STRICKLAND, Ohio

DIANA DEGETTE, Colorado

CHRISTOPHER JOHN, Louisiana

BOBBY L. RUSH, Illinois

JOHN D. DINGELL, Michigan,

(Ex Officio)

(II)

3

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)

(1)

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

2

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 seVerDate 11-MAY-2000 11:09 Oct 03, 2001 Jkt 075225 PO 00000 Frm 00006 Fmt 6633 Sfmt 6633 E:\HEARINGS\72833 pfrm09 PsN: 72833
3

curity 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

4

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

5

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 21⁄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

6

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

7

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.

8

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.

9

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 nonmilitary 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

10

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

11

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 tomor- row’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 approVerDate 11-MAY-2000 11:09 Oct 03, 2001 Jkt 075225 PO 00000 Frm 00015 Fmt 6633 Sfmt 6621 E:\HEARINGS\72833 pfrm09 PsN: 72833
12

priately 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 selftesting 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.

13

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

14

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

15

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 re- garding 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 feefor-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

16

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, entitywide 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 apVerDate 11-MAY-2000 11:09 Oct 03, 2001 Jkt 075225 PO 00000 Frm 00020 Fmt 6633 Sfmt 6621 E:\HEARINGS\72833 pfrm09 PsN: 72833
17

plied 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 longterm 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

18

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.

19

Last finding, when we left them, there were a variety of known

risks to third parties, in particular we are talking about Medicare

contractors. There are a variety of insurance companies, doctors,

which are connected both through the MDCN and through direct

connectivity into HCFA’s network. There are a variety of risks

there, which I have detailed in my written testimony.

In the end, we recommend this: HCFA needs to focus on technical security not just policy. Really every organization needs a person who is in charge of implementing the security policy, not just

telling people how to do passwords but making sure that the passwords are correct, making sure that systems are configured properly, and so forth. They need better control and technical oversight

of their contractors. Again, I am not talking about Medicare contractors, although that probably is an issue; in my experience, the

facilities contractors.

They need more testing of everything. When they install remedial fixes, you need to test those fixes after you are done installing

them. You need to test everything from applications to servers to

networks, and it needs to be done regularly. Threats and

vulnerabilities change all the time. And decisions to ignore those

vulnerabilities really need to be taken with a full awareness of

what the actual risks are when they take that risk.

In the end, if they had the technical expertise and the oversight

of their contractors, virtually every vulnerability that we found

would have been prevented. And we think that is a significant step

they need to take.

[The prepared statement of Michael Neuman follows:]

PREPARED STATEMENT OF MICHAEL NEUMAN, EN GARDE SYSTEMS, INC.

0. SUMMARY

Penetration testing is a critical tool in ensuring the security of everything from

an individual software application to an entire network. Unfortunately, security is

far too complex to provide any sense of absolutes. Add to that the fact that dozens

(if not hundreds) of new vulnerabilities are discovered every week, and the need to

continuously test the security of a system is obvious.

We have provided services, similar to those we provided HCFA, to hundreds of

companies, and are intricately aware of the ‘‘industry standard’’ state of security.

During our tenure providing security services to HCFA, we found both extremely

positive and disturbing issues. Major recommendations include:

Technical Oversight: HCFA is lacking the specially trained personnel to oversee

their and their contractors’ activities and verify the work for security consistent

with policy and best practices..

Third-Party Verification: It should be unacceptable for service providers to certify themselves as secure. Any vendor of network services to HCFA should readily

accept 3rd party verification of security and have regular testing a part of their contract performance requirements.

Security Specified in Contracts: The security expectations and requirements

should explicitly be laid out in contracts with network service providers.

More Testing is Required: It’s necessary to independently verify the security

features of everything from applications to WWW servers to networks and to do so

on a recurring basis.

1. BACKGROUND

En Garde Systems (EGS) provided a variety of security services to the Health

Care Financing Administration (HCFA) between December 1997 and June 2000.

During that time, EGS performed a number of penetration tests and assisted HCFA

in devising network security protections. Specifically, EGS has performed:

• External Penetration Tests (4). As an average outsider connected to the Internet,

we attempted to gain access to internal HCFA resources.

20

• Internal Penetration Tests (2). Given a connection to HCFA’s internal network, we

attempted to gain access to internal HCFA resources. • Wardialing. Given a prototype phone number (for example 786-xxxx), we dial

every phone number looking for computer modems. When a computer answers,

we attempt to gain access. • Architecture Review and Design. Given a complete map of network resources, we

spent extensive time understanding the various applications HCFA provides

and the security needs of each. We then formulated network architecture

changes that would build security into the fabric of the network. • Test of Internet services hosted by IBM Global Services. At the time we tested,

HCFA outsourced its internal and external web servers to IBM. • NT Desktop Review. For Y2K, HCFA moved to a Windows NT desktop system.

We were provided with a prototypical NT desktop prior to deployment to find

security vulnerabilities. • HCFA Insider test. We were given a standard user’s desktop computer and asked

to gain access to HCFA internal resources. In this case, we were not allowed

to bring in our own software, floppies, or PC—only what we could retrieve using

HCFA’s network. • Intrusion Detection System Review. HCFA ran a ‘‘bake-off’’ of several competing

Intrusion Detection Systems and asked us to perform a variety of tests to determine their efficacy.

• Security Training. We provided classes over a several day period covering everything from good password choice to Intrusion Investigation and Response.

2. APPROACH

Penetration testing is a critical tool in ensuring the security of everything from

an individual software application to an entire network. Unfortunately, security is

far too complex to provide any sense of absolutes. Turning on one network service

may result in dozens being turned in non-obvious ways. Connecting a trusted partner to your network often means you not only trust him, but everyone he trusts as

well. Add to that the fact that dozens (if not hundreds) of new vulnerabilities are

discovered every week, and the need to continuously test the security of a system

is obvious.

Our approach to testing is almost exclusively ‘‘manual’’. We rarely use automated

tools, as our experience has shown they are generally only effective in an extremely

small number of cases. Instead, we learn about the network and create new attacks

on the fly. In doing so, we are doing exactly what a hacker does.

Proposing solutions to vulnerabilities is perhaps the most complex part of our

work. Before we recommend any solution, we need to determine the:

1) Value of the organization’s data. If the data is simply pricing and personnel information, it is far less valuable to a hacker than Privacy Act data, for example.

2) Threat to the organization. A government agency will attract far more interest

from the malevolent than a small computer company, for example.

3) Path of least resistance. It makes no sense to spend a great deal of effort protecting a network connection to a partner if the ‘‘front door’’ is wide open. These

relative threats are determined before any solution is recommended.

4) Cost in man-hours and equipment expenditures. We often make several recommendations based upon the amount of money the customer wishes to spend.

3. FINDINGS

We have provided services, similar to those we provided HCFA, to hundreds of

companies, and are intricately aware of the ‘‘industry standard’’ state of security.

During our tenure providing security services to HCFA, we found both extremely

positive and disturbing issues.

3.1 Positive

3.1.1. There is a healthy approach to security from HCFA management. Whereas

many other organizations believe that all security problems can be solved by writing

a policy, HCFA has taken significant steps to not only inscribe the virtues of security, but to ensure they practice what they preach.

3.1.2. When we first arrived at HCFA, we found them to be operating with significant and obvious vulnerabilities. These problems were fixed within hours of our reports. Over the course of the years, HCFA has become significantly more secure

than the industry standard.

3.1.3. Beyond simply patching vulnerabilities that were found, HCFA has made

significant efforts to find the systemic causes of their vulnerabilities and fix them

wherever possible.

21

3.2 Negative

3.2.1. Contractors

By far, HCFA’s biggest security problems have been the direct result of the action

or inaction of contractors. In general, we have found HCFA’s contractors to be outright obstructive to providing sound security. Compounding these errors was

HCFA’s inability to catch or prevent them.

a. HCFA lacked the technical oversight of their contractors to verify the contractor

was actually implementing the security measures they claimed. The managerial

oversight had no ability to ask relevant questions.

b. HCFA’s contracts had no mention of security expectations of a contractor. As a

result, the contractors were free to implement (or not implement) any measures

they felt as appropriate, regardless of HCFA’s requests.

c. We discovered during our first test that a HCFA contractor ignored change control, bypassed the firewall policy group, and installed his own filter rules directly onto HCFA’s primary firewall without anyone’s knowledge. These filter

rules made the entire HCFA network vulnerable to a variety of serious attacks.

After bringing the firewall problem to HCFA’s attention, the contractor was directed to remove the rule and instructed about the use of change control. One

year later, we tested and found the contractor installed the same rule again

without HCFA’s knowledge.

d. On several occasions, we witnessed HCFA contractors argue against improving

security stating that changes HCFA asked for were ‘‘difficult’’ or ‘‘impossible’’

when, in fact, they were not.

e. During our architecture review, we discovered that the HCFA contractors responsible for network operations could not provide a complete list of all network connections external to HCFA. In fact, we spoke to over a dozen groups, and each

would make us aware of another undocumented connection from HCFA to another organization.

f. Contractors have made extremely poor password and configuration decisions, violating the most basic security principals and completely invalidating other security measures put into place.

3.2.2. IBM

HCFA relied on IBM to provide secure network connectivity (via a product called

‘‘SecureNet’’) to MDCN partners as well as for both external and internal WWW

servers. We were contracted to evaluate the architecture and determine potential

risks.

During a meeting with HCFA management (up to CIO level), IBM’s security staff

and management responsible for the HCFA contract, and ourselves, we were told

by IBM that we didn’t need to test because they had taken every imaginable security precaution. They described how:

• Administrators can only connect from a physically secure administrative network

• WWW administration is done through an encrypted management connection

• Patches are installed immediately after a vulnerability is announced

• They would be happy to share their firewall’s access control lists with us

• They perform penetration testing every week

• They have a custom designed IDS along with 24/7 response

• The firewalls only allow WWW access through

Upon extensive questioning from ourselves and HCFA’s CIO, it we learned from

IBM that:

• Administrators can also dial-in from home into a generic ‘‘SecureNet’’ modem

bank, that all other customers use, and administer machines.

• WWW administration can be encrypted, but they haven’t enabled that feature,

and probably won’t because it’s difficult to do so.

• Patches are only installed when an administrator gets around to it, which is usually in a ‘‘week or two’’.

• They would not share their access control lists because, ‘‘If EGS found a vulnerability in HCFA, they would find a vulnerability in all IBM customers.’’

Because HCFA relies so much on the security of IBM to provide everything from

secure connectivity for the MDCN to managed web hosting, we proposed performing

three distinct tests:

1) External test against the web servers hosted by IBM

2) Tests from a HCFA partner connected to the MDCN directed at HCFA and other

partners on the MDCN.

3) Tests from a non-MDCN customer of IBM directed towards HCFA.

22

It took IBM and HCFA a year of negotiation to come to terms to allow just the

external test against the web servers. We were given several severe restrictions that

made the results of the test unrealistic. Specifically:

1) We were not allowed to test the firewalls or any other infrastructure on the IBM

network. They did provide us with an extremely limited subset of filter rules

that IBM said were installed on their firewalls.

2) We were not allowed to touch any IBM system other than HCFA’s web server.

This included administrative systems, other customer servers, or any infrastructure.

3) We were not allowed to route traffic through any other IBM network.

These restrictions meant that we could only test the controls in place on the web

server. We could not check for configuration errors in access control lists,

vulnerabilities in firewalls or routers, or transitive trust issues (i.e. if we can break

into the IBM administrative network, or another customer’s web server, what can

we do then?).

In the end, the restrictions ended up being irrelevant. Using an extremely old,

very well known vulnerability in the WWW server software, we were able to gain

access to HCFA’s web server without any more technical expertise than it takes to

point and click. Because of the way HCFA’s web server was configured, and an error

made in the firewall rules set up by IBM, we were then able to access HCFA’s internal network resources. IBM’s other claims were then shown either false or useless:

• If they performed a penetration test every week, they would have discovered this

blatant vulnerability

• They provided us with the IDS logs collected during the course of our attack, and

we had gone completely unnoticed, despite us making no effort to hide our

tracks.

• The firewalls allowed not only WWW access through but also another protocol

that allowed us unfettered access to HCFA’s internal network.

3.2.3. Third Party trust

HCFA has a need to connect with a variety of insurance companies, doctors, and

so forth. Network connections were provided both through the MDCN and by direct

connectivity to other companies. These connections were configured such that there

was no protection of either HCFA from the company or the companies from each

other. Essentially, HCFA was trusting these companies completely. As a result,

HCFA is subject to whatever security policies and protections are in place by the

trusted company. So, if HCFA trusts company A and company A trusts company B,

then HCFA trusts company B. Without any control over or auditing of the partner’s

network, HCFA should not trust that it’s secure.

In addition to threatening HCFA, there is a potential for these competing insurance companies to use HCFA as a means to attack one another. HCFA provides the

unsecured communications mechanism, and a company simply uses that to get into

another’s network.

4. RECOMMENDATIONS

4.1. Technical Oversight

HCFA is lacking the specially trained personnel to oversee their and their contractors’ activities and verify the work for security consistent with policy and best

practices. This position should be solely technical—it should not have any policy development duties associated with it. The position should be independent of any contractors and should be associated with the security policy group. Essentially, the

role is to be the ‘‘security implementer’’ of the organization.

The goal is to have an independent and informed person who can ensure that the

security of the organization is not simply some high-level goals or a policy on paper.

In HCFA’s case, such a person would have prevented the vast majority of

vulnerabilities introduced by either HCFA or HCFA’s contractors. Beyond our experience with HCFA, such a position is direly needed in most organizations.

4.2. Third-Party Verification

It should be unacceptable for service providers to certify themselves as secure. Recently, it’s become popular for service providers to get an outside certification of

their networks or services and provide that as evidence of their security. In our experience, these too are insufficient, as the certifiers do not reveal their methodology

or extent of their certification.

Any vendor of network services to HCFA should readily accept 3rd party

verification of security and have regular testing a part of their contract performance

requirements.

23

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

24

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?

25

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?

26

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

27

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 A130 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,

28

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 21⁄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 21⁄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 con- tract, 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 21⁄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

29

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?

30

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, ‘‘dualhomed,’’ 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 multihome 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

31

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, 21⁄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 21⁄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.

32

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.

33

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

34

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.

35

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.

36

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.

37

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?

38

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

39

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.

40

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

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111