Testimony for Hearing on Healthcare Security Standards
National Committee on Vital and Health Statistics
August 5-6, 1997

Dixie B. Baker, Ph.D.
Chief Scientist
Center for Information Security Technolgoy

Good afternoon.. I'm Dixie Baker, and I'm the Chief Scientist for the Center for Information Security Technology at Science Applications International Corporation, a large consulting and systems integration firm. I've been working in information system security for over 16 years, and for the past two years, most of my work has been in the healthcare industry. I now am the security architect for a major HMO and the principal investigator for a research project that is building a system to provide secure Internet access to highly sensitive patient information. Much of my testimony today will draw from recent experience with these two projects.

As I respond to the specific questions I've been asked to address, you'll notice that my observations and comments tend to center around the following two major points:

  1. Privacy protection is necessary, but not sufficient . Healthcare security requires protecting both the confidentiality of patient information, and the integrity and availability of healthcare data, software programs, and services. Privacy clearly is an important social issue, but integrity and availability are critical human safety issues! Perhaps the most challenging aspect of healthcare security is obtaining the optimal balance between privacy and safety.
  2. Security technology is necessary, but not sufficient. Security technology provides important functional capabilities, including authentication, access control, encryption, and auditing. However, security technology is only as strong as the information system components upon which it depends. Effective healthcare security requires a dependable and responsive information system architecture.

Now let me address the specific questions I was given.

What security features do your products employ?

SAIC is not a product company. However, our research project with the National Library of Medicine is developing a prototype system to provide highly secure access to patient information over the Internet. The system will be deployed within the University of California, San Diego, Medical System and ultimately will be delivered to the government. So I will respond to this question from the perspective of that "product."

PCASSO (which stands for Patient Centered Access to Secure Systems Online) provides a number of security "features," but more importantly, it is built on a high-assurance architecture. The PCASSO access mediator comprises a server that runs on Data General's B2 DG/UX operating system and a Trusted Oracle 7 database management system, which collectively enforce a role-based access control policy. The access mediator uses label-based access control to separate and protect five hierarchical levels of sensitivity: non-patient-identifiable (low), patient-identifiable (standard), public-deniable (e.g., HIV/AIDS, abortion, adoption, mental health), guardian-deniable, and patient-deniable.

PCASSO uses the Secure Socket Layer (SSL) encryption protocol and public-key encryption to mutually authenticate the client and the server, after which it authenticates the user using a challenge-response protocol. Following authentication, all transmissions between the client and the server are encrypted using secret-key encryption. Individual users are granted access to data and the ability to perform specific functions based upon their assigned roles. All actions are audited, and SAIC's Computer Misuse Detection System is used to detect potential intrusions. Unlike most other systems, PCASSO also has design features and functional capabilities to protect the client environment, which in the prototype is presumed to be the highly insecure Windows 95 environment.

What security features are customers asking for?

Healthcare providers are asking for guidance in implementing security that will enable them to conduct their business, while complying with legal and regulatory requirements; avoiding costly legal suits; and presenting themselves in a good light to their existing and potential patients. As I mentioned in my introductory statement, I think one of the greatest challenges for healthcare security is to effectively manage the balance between privacy and safety; that is, protecting patient privacy without unduly constraining the system such that critical information is not available when it is needed for care.

Some specific security capabilities customers are asking for are:

Is cost a factor?

Of course, but so are costs associated with fines, lawsuits, and the loss of patients and members resulting from bad press.

Can security technology being used in other industries be integrated into your products?

Definitely! Most of today's security technology came out of the Department of Defense. Specifically, the DOD Trusted Computer System Evaluation Criteria, published in 1985, defined the security requirements for operating systems, and was later extended to database management systems and networks. The TCSEC's "C2" rating has become the industry standard and is the minimal requirement for all government systems. The TCSEC functional and assurance requirements were the basis of the European and Canadian standards, and the new international Common Criteria. Similarly, encryption technology originated within the DOD and has been broadly adopted. The banking industry is a good model for how the security technology that originated within the DOD has been applied in a non-government, commercial arena. Several large banks are using the same label-based access controls used by the DOD to protect classified information, and encryption has been used in banking for decades.

Unfortunately, many healthcare enterprises are incorrectly assuming that electronic commerce will provide a ready-made solution for securely transmitting healthcare information over the Internet. Although electronic commerce solutions clearly have a role in healthcare with respect to purchases and sales, they fall far short of providing a solution. Electronic commerce solutions address one part of the problem: the transmission, specifically of credit card information. Also, they assume shared risk between the credit-card holder and issuer, an approach to risk management that is not applicable to healthcare.

PCASSO is a good example of how security technology developed for other industries can be used in the healthcare domain.

How do you help a client identify their data security risks, threats, and exposures?

Thanks to media coverage, most healthcare enterprises recognize the importance of taking appropriate steps to protect the privacy of their patients and members. But we attempt to broaden that focus to see the complete business problem: protecting privacy and human safety. So this question relates directly to my first major point. In my opinion, the most serious security threats to healthcare enterprises are those that threaten the integrity and availability of critical systems, programs, and data. These threats include insiders and outsiders, as well as malicious and misbehaving software programs.

Seeing is believing. So one of the most effective ways we've found to help a client see these threats and the associated risks and exposures is through penetration testing and vulnerability demonstration. In our penetration exercises, a penetration team attacks the client's "secured" system. Obviously, clients have us do this only when they think their system is secured – yet we have about a 90% "hit rate," in many cases resulting in a total take-over of the system. Interestingly, very few firewalls prove resistant to penetration.

How do you help a client develop an effective data security strategy, design, or architecture?

This question relates to my second major point: no security component can be any more trustworthy than the components upon which it depends. So, from a technology perspective, it's essential to look at the entire architecture and the dependencies inherent in it. In general, the "lower" in the architecture a security capability is integrated, the more difficult it is for a malicious or misbehaving user or computer program to circumvent it. The "higher" in the architecture a security capability is integrated, the easier it is for a malicious or misbehaving user or computer program to circumvent it. So for more assurance, build an infrastructure that provides security services to applications, rather than adding security bells and whistles to applications.

Developing an effective security architecture must be tightly coupled with developing the overall information system architecture. Particularly in healthcare, the focus must be on developing a dependable system – which goes a long way toward developing an effective security architecture. Developing the security architecture involves:

  1. Performing a risk assessment.
  2. Developing a strategy for attaining an effective balance between risk avoidance, risk acceptance, and risk sharing.
  3. Developing a security policy.
  4. Determining what security technology is needed to enforce the security policy, and specifying security standards.
  5. Designing and integrating this technology into the overall architecture.

How do you avoid technology-dependent security procedures and systems?

The best way to avoid dependency upon a particular vendor or technology is to specify standards (de facto or de jure) whenever possible. For example, by specifying a "C2" operating system, the enterprise is assured that its system will have hardware isolation of system and application execution domains, as well as essential security features such as user authentication, identity-based access control, and auditing. Yet, they will still have a wide range of specific products from which to choose. Similarly, a number of products support the Open Group's Distributed Computing Environment and Kerberos authentication; a growing number of Web products support SSL and Java; and most encryption products use RSA for public-key and DES for secret-key encryption.

Thank you. I'd be happy to answer any questions.