SIIS Developer's Workshop: System Security Functions

Sponsored by the Centers for Disease Control and Prevention
Atlanta, GA, August 2, 1995
Noam H. Arzt, Ph.D.

New Jersey Comprehensive Immunization Program (NJ-CIP)
University of Pennsylvania, Leonard Davis Institute of Health Economics

• Ernst & Young Security Survey: Almost 50% of respondents rated information security issues as "less than important." (1)
• Part of the development of a client/server system is an analysis of the threats to information security, and possible steps that can be taken to mitigate these threats.
  
• Information security is defined as ". . . a set of technical and administrative procedures designed to protect data systems against unwarranted disclosure, modification, or destruction and to safeguard the system itself."(2)

Goals are:

• Maintain the integrity of the data under the Program's stewardship
• Make the data available easily to legitimate users
• Ensure the privacy and appropriate use of patient data (2)

Tradeoff: information security and ease of access

• Identify the information assets that need protecting
• Describe the architecture of the information system to be deployed
• Identify and rank the threats to those information assets based on the architecture
• Identify the most serious threats and develop solutions to mitigate the threats as much as possible
• Make specific recommendations of solutions for deployment

• Major groupings of SIIS data (NJ-CIP):
  • Information about People: Includes patient biographical/demographic data, aliases of names, information about relatives and guardians, immunization provider information
  • Information about Patient Records: Focuses on the relationship between a patient and an immunization provider
  • Information about Immunizations: Includes immunizations administered, normative schedule information (see related working paper Automated Immunization Evaluation Process), vaccine vendor information
  • Information about Registry Output: Patient/family outreach information
  • Information about Technical Aspects: Includes system user profiles and permissions, system access logs
  • Code tables:More than a dozen code tables for valid values of various database elements
• Patient right to privacy
  • There must be no personal data record-keeping systems whose very existence is secret
  • There must be a way for an individual to find our what information about him is in a record and how it is used.
  • There must be a way for an individual to prevent information about him that was obtained for one purpose for being used or made available for other purposes without his consent.
  • There must be a way for an individual to correct or amend a record of identifiable information about him.
  • Any organization creating, maintaining, using,or disseminating records of identifiable personal data must assure the reliability of the data for their intended use and must take precautions to prevent misuse of data.
• Secondary effects of Improper Information Access
  • A manufacturer recall of a vaccine lot may result in patients having received vaccine that may be harmful. Inadvertent disclosure of this information improperly may violate the privacy of the patient involved.
  • The Registry could be used inappropriately by child welfare or Immigration and Naturalization agencies for followup or case management.
  • Address/contact information in the Registry could inadvertently be used to locate a parent or child improperly (e.g. cases of adoption, legal restraining order, etc.).

Major components of the architecture:

• Database: The database management system will be the Oracle 7 RDBMS running on an HP-UX server.
• Client Computers: The client computers will be industry-standard personal computers running MS-Windows 3.1 (at least initially). Typical configuration will probably include a 66Mhz Intel 80486 or Pentium processor, 500+MB of disk space, 16MB of RAM, and a 15 inch SVGA monitor.
• Network Protocol: TCP/IP will be used exclusively for this project.
• Wide-area Network: The Internet will be the wide area network connecting client sites with the database server.
• Applications: Client applications are expected to be written in MS-Visual Basic, relying on Oracle SQL*Net, Oracle Glue, and/or ODBC as middleware connecting the client applications to the Registry database via TCP/IP.
• Query Tools: Additional "off-the-shelf" commercial SQL query tools are expected to be deployed, likely relying on SQL*Net connectivity.
• Data Collection: Data will be harvested into the Registry via custom interface to the WIC/AFDC KISS system, via custom interface to the Electronic Birth System, and via standard interface to other local data systems found in clinical provider locations.
• Data Access: Eventually, an applications program interface (API) will be developed to allow vendors to write software that accesses data in the Registry for transfer to local data systems found in clinical provider locations.
• User Access: Database users normally do not receive Unix login privileges, but rather receive database usernames and passwords only. SQL*Net encrypts the database password as it travels across the network, with a session key, but does not support user alteration of the password.

• Identify threats to desktop, server, and network via a structured methodology
• Rank those threats on a high/medium/low scale as to likelihood of occurrence and the likely harm if the threat occurred.

Desktop example (7 potential threats in all):

THREAT A-1: Unauthorized access to someone's desktop resulting in disclosure of sensitive data that has been stored on the desktop.

Server example (15 potential threats in all):

THREAT B-7: Someone who has access to the system as part of their job responsibilities uses that access to destroy data or programs.

Network example (8 potential threats in all):

THREAT C-3: Someone uses a packet sniffing tool to capture accounts and passwords to gain access to host systems containing sensitive medical data.

• Data in inappropriately disclosed or altered: inappropriate access to a "live" Registry client inherently brings potential for disclosure or alteration of data
  • Develop an information security policy that addresses these concerns, and includes descriptions of appropriate behavior and sanctions for inappropriate behavior.
  • Develop the Registry application security with security profiles to only allow a given user to access and/or modify data appropriate to his or her role in the organization.
  • Promote awareness and good behavior to reduce the occurrence of Registry applications being left unattended in clinical settings.
• An important local file is deleted: desktop computers at provider sites are the least controlled part of the architecture
  • Develop an information security policy that requires regular data backups and compliance to participate in the Program.
  • Purchase and install software (or hardware) to secure Program files on provider site desktops.
  • Encourage sites to install Program software on local file servers which are likely better maintained and backed-up than individual desktops.
• Attack on the server via the Internet
  • Restrict the number of network services that are co-existing with the database
  • Install the most secure version of the basic operating system as possible, and keep all security patches up-to-date.
  • Use one-time passwords
  • Install utilities that require frequent password changes, that enforce rules against easily-guessable passwords, and that scan the system for easily-guessable passwords.
  • Restrict access to the database server from certain network locations
  • Deploy a network firewall to best protect the server from attack.
• Inadequate System Administration: Unix and Oracle are powerful, yet difficult products to learn, master, and properly maintain.
  • Invest in necessary training for all systems staff.
  • Be sure necessary staff are cross-trained to provide sufficient backup for critical skills.
• Physical threats to server or network
  • Locate server in a secure machine room.
  • Provide upgraded environmental conditions wherever the server is located, including uninterrupted power supply, redundant network connections, and redundant systems in different locations.
  • Implement a proper backup procedure, including off-site storage of backup media, to facilitate recovery from a catastrophic failure or accident.
• Promiscuous monitoring of network traffic
  • Encrypt all data as it passes across the network.
  • Restrict database access from the public Internet by providing connectivity between the server and clients behind a firewall.
  • Restrict physical access to the subnet upon which the server is deployed.

• Policy: Develop an information security policy that delineates the roles and responsibilities of the Program staff and participants with respect to the Registry and its data. Include appropriate procedures to ensure local site data and software is properly managed.
• Security Levels for Applications: General Reader, General User, Site Manager (Sample screens: Child Lookup, General User screen, "Critical Fields" modification screen)
• Harden Server Against Network Attack: Several steps can be taken to harden the server against attack from the Internet.
• Train Staff Appropriately: Appropriate systems and operations training needs to be provided for staff, including backup personnel. Consulting assistance needs to be provided when necessary.
• Physically Secure the Server: The database server should be kept in a locked facility, alarmed whenever left unattended. Uninterrupted power should be provided. Data backups (including off-site storage of backup media) should be in place and functioning. Restoration from backups should be periodically tested.
• Prevent Promiscuous Access to Data: Via Oracle's Secure Network Services, the full client/server data stream can be encrypted to prevent even accidental disclosure of data by promiscuous capture on the network. In addition, the IP subnet upon which the server is attached should be a "trusted" subnet: all computers on the subnet should be used and administered by "trusted" personnel. In addition, the network topology for the pilot should have Project participants attached to this same subnet rather than come into the server over the public Internet.

• Security Assessment paper available upon request
• This presentation available via WWW. URL: www.cip.upenn.edu/cip/, select Technical Papers
• Feel free to contact me later:
  

  	Dr. Noam H. Arzt
  	University of Pennsylvania
  	Information Systems and Computing
  	Suite 221A
  	3401 Walnut Street
  	Philadelphia, PA 19104-6228
  	215/898-3029 (Voice)
  	215/898-9348 (FAX)
  	URL: http://nextb.dccs.upenn.edu/noam.html
  	arzt@isc.upenn.edu (MIME is OK)