IQHealth Security Standards, Methods, and Policies

The attached policies are undergoing review by counsel. Elements of the policy may be modified as a result of the review. Proposed elements of the policies will be implemented before full deployment of the IQHealth systems to assure substantial compliance with all material federal, state and local laws and regulations governing operations of the corporation.

Table of Contents

Introduction

Present State

Confidentiality

Risk and Threat considerations

System Integrity

Media and Record Backup and Storage

System Accountability

PKI and Digital Certificates

Security Environment and System Analysis

Testing Procedures

Operational Review

Vulnerability Analysis

System Access

Employee Education

Procedure for Intrusion

Security Reporting

Other Security Practices

1.0 Introduction

Of the 110 million internet users in the U.S., some 30 million are expected to use the internet for obtaining health care information this year; that is up nearly 5.5 million from the previous year. With this virtual explosion of e-health activity on the Web, the importance of establishing ethical practices and safeguarding the privacy of personal health information is paramount to establishing consumer confidence and trust in this new medium.

The importance of security on the web is one that cannot be trivialized and must be dealt with actively, aggressively, and continuously. With new system vulnerabilities being discovered daily, it is now more important than ever to have a capable and trusted service provider. Recently, internet security flaws have resulted in the defacement of web sites, as well as the theft of credit cards, e-mail, and other private information. The health care industry cannot afford to run the risks of similar events happening to their secured information. A security breach in the health care environment could result in the theft, manipulation, or deletion of confidential, personal information. The consequences of such an event could be anything from the publicizing or deletion of personal health records, to the manipulation of dosages or allergy records.

Because it is becoming increasingly apparent that the internet will play an important role in providing people with health care information, IQHealth has implemented a set of plans, procedures, and standards that will insure the security and privacy of all confidential health care information. The security that has been implemented on and around the IQHealth system includes the physical security of data, network security, administrative security, and application security. IQHealth believes that all individuals and organizations using the Internet must have confidence in the integrity, confidentiality, security and availability of health care information. IQHealth also believes that by assuring the privacy of such information, the best interests of patients, physicians, other health care providers and payers will be served now and in the future. Implementation of appropriate privacy standards will enable providers and payers to confidently adopt new applications and services, offer users a competitive advantage, and comply with accreditation standards and government regulation.

1.1 Present State

In the present environment of declining resources, and because of the rapid advances in systems and technology, current healthcare security policies do not provide sufficiently detailed guidance on how to certify, accredit, and maintain a system. This has resulted in healthcare systems that want to move forward into internet based health care, but cannot provide the necessary security and support to guarantee the privacy, and safety of their physicians, patients, and third party users (pharmacies, insurance companies, etc). The importance of this privacy and safety issue, especially in the healthcare field, cannot be under estimated and must have the appropriate resources devoted to creating and maintaining a high level of integrity.

With HIPAA regulations on the horizon, the lack of a guiding framework has led most healthcare organizations to develop disparate methodologies that may or may not provide sufficiently detailed guidance to analyze systems from an information systems security perspective that is sufficient to meet HIPAA requirements. Security and confidentiality requirements set forth under HIPAA relates to the protection of information systems against unauthorized access to or modification of information, whether in storage, processing, or transit. HIPAA security also includes protection against the denial of service to authorized users or the provision of service to unauthorized users, including those measures necessary to detect, document, and counter such threats.

Today's challenge is to be able to comply with HIPAA requirements in support of a cost-effective and efficient care delivery process without jeopardizing the protection mechanisms, practices, and security safeguards for healthcare systems that the law will require. IQHealth is prepared to provide a single operational and administrative framework to provide focused oversight and responsibility of entire systems, including computer hardware, firmware, software, data, procedures, environment, and people.

2.0 Confidentiality

IQHealth is committed to conducting its activities with the highest level of integrity and in compliance with law. This includes protecting and maintaining the confidentiality of patient, provider, supplier and payer data. In addition, data policies and agreements with IQHealth's business partners will require them to maintain the confidentiality of information obtained from IQHealth and not to use or disclose the information except as specifically permitted or required. The policies stated within are not intended to set forth fully all of the substantive programs and practices of IQHealth that are designed to achieve legal compliance but instead to provide an overview of the steps that have been taken to insure a safe environment for health care information.

2.1 Compliance with Law and Regulations

IQHealth will adopt security standard protocols designed to protect against unauthorized access to personal health information in the Company's possession. As part of this effort, the Company will comply with the privacy, confidentiality and security standards developed by the Secretary of the Department of Health and Human Services ("HHS") pursuant to 42 U.S.C. § 1320d-2(d) and the 1998 HCFA Internet Security Policy bulletin. Also IQHealth will comply with the Certification and Accreditation requirements set forth in federal security policies including FIPS Pub 102 and OMB A-130. These documents are at the root of NIST GASSP and Computer Security Handbook on which HIPAA requirements are directly based. The method used in assuring that our systems environment is a secure and well protected one is detailed in the following pages.

2.2 Maintaining Confidentiality of Health Information

IQHealth has access to, and is responsible for transmitting and storing, personally identifiable health information. IQHealth will act in accordance with this policy and will require that its business partners agree to maintain the same standards of confidentiality.

Confidentiality services provide protection of information from unauthorized disclosure. Information may be disclosed in many ways, such as unauthorized user access, poor procedural controls, incorrect labeling of information, emissions, and interception. The following is a non-comprehensive list of the mechanisms that may be used to provide a confidentiality service:

· Access control
· Object reuse
· Encryption
· Authentication
· Separation of components
· Administrative procedures
· Physical security
· Fixed message length

IQHealth's standards for maintaining confidentiality:

1. IQHealth limits access to personal health information to those of its employees who have a legitimate business need to access the information. Employees granted access to personal health information for a legitimate business purpose will have access to only the type of information necessary for that purpose. Access to personal health information will be limited both physically and electronically.

2. IQHealth employees will not disclose personal health information to any individual, including another IQHealth employee, who is not authorized to have access to the information.

3. Written authorization of the subject individual is obtained for all uses of personal health information beyond those specifically permitted or required by law or regulation.

4. IQHealth's agreements with business partners who will have access to personal health information will specify the business partner's permitted uses and disclosures of the personal health information, and will require the business partner to maintain the confidentiality of the personal health information to the same extent as that provided by IQHealth.

5. Patient requests for disclosure of personal health information will be referred to the original source of the information, such as the treating practitioner or the payer, unless IQHealth is the sole source of the information. Business requests for personal health information by anyone other than another IQHealth employee or participant authorized to have access may yield only aggregated or de-identified information.

6. IQHealth will not disclose personal health information to law enforcement
officials unless the officials have legally authorized access to the information or
there is a legal requirement to disclose the information. In such cases, a court
order, a warrant or similar legal document must be produced by the respective
law enforcement official to gain access to the information.

3.0 Analyze Risk-related Considerations

A threat is defined as the capabilities, intentions, and attack methods of adversaries to exploit, or any circumstance or event with the potential to cause harm to information or an information system. Threats may also come from intentional or accidental misuse by authorized users. Most systems have common threats such as attack by hackers, damage by disgruntled employees, and failure to follow standard procedure. Recent security surveys report that over 80% of the detected and reported attacks to computer systems are from inside the organization. This percentage breaks down into 24% due to inattention to procedures (carelessness), 26% due to inadequate training, and 30% due to dishonest employees. Unfortunately, inappropriately and improperly increasing the amount of security on the system may not significantly decrease the insider threat. We take into consideration the communication paths used, local processing capabilities, and the capabilities given to the users of the system. These common threats should always be analyzed and appropriate safeguards implemented.

In addition to threats from individuals or groups, we consider threats from natural occurrences (e.g., hurricanes, earthquakes, floods, lightening) and ensure that proper safeguards and contingency plans are developed, implemented, and adequately tested.

The threats, their corresponding attacked system vulnerabilities, and resultant operational impacts provide the foundation to understanding risks. As described here, threats and risks need to be re-analyzed throughout the development, operation, and maintenance of the system.

3.1 Threat Analysis

Historically, healthcare threat analysis has not placed adequate emphasis on computer security or networked systems. Identifying the threat of malicious logic attacks (e.g., viruses, worms, and computer misuse) is important to the security of the system. The threat analysis can also be used as input to the system threats and vulnerabilities, and risk analysis.

Potential threats can be organized into two basic hierarchical levels, namely, threat consequences and threat actions. Threat consequences define a negative effect that a threat may have on the secure operation of an information system. In contrast, threat actions define the potential causes for these consequences. Threat consequences include:

- Disclosure: Any circumstance or event that may result in an individual or entity gaining access to information they are not authorized to receive. Exposure, interception, inference, and intrusion are threat actions.

- Deception: Any circumstance or event that may result in an authorized individual or entity receiving false information that is believed to be true. Masquerade, falsification, and repudiation are threat actions.

- Disruption: Any circumstance or event that interrupts or prevents the correct operation of the system services or functions. Incapacitation, corruption, and obstruction are threat actions.

- Usurpation: Any circumstance or event that results in the control of system services or functions by an unauthorized individual or entity. Appropriation and misuse are threat actions.

3.2 Preliminary Risk Analysis

Risk analysis is the process of analyzing threats to and vulnerabilities of an information system to determine the risks (potential for losses), and using the analysis as a basis for identifying appropriate and cost-effective countermeasures. Countermeasures include technical, physical, personnel, and administrative. Risk analysis processes are used at each stage in the system life-cycle to aid in deciding whether the implementation of additional safeguards would be cost-effective with respect to reducing security risks and should include the following:

· Identify system assets
· Identify and analyze threats to the system
· Identify and analyze vulnerabilities to the system
· Identify and analyze risks caused by threats acting upon vulnerabilities
· Identify countermeasures to mitigate risks

Risk analysis should be applied throughout the system life cycle at key milestones/decision points (e.g., during requirements definition, completion of architecture, system installation) and is done to assist in making decisions concerning the level of residual risk. It focuses on (1) what can happen (2) what are the consequences if the risk occurs, and (3) what is the possibility of the risk occurring. In determining the possibility of a risk occurring, we use the following criteria:

· The perpetrator is well equipped.
· The perpetrator uses sophisticated techniques.
· That such a well equipped, sophisticated perpetrator exists.
· The perpetrator is interested in performing the specified action.
· The perpetrator is willing to use the necessary capabilities.

4.0 Integrity

Integrity services provide protection from information or resources being created, inserted, modified, or deleted by entities not authorized for these actions. Integrity protection may include the prevention or detection from these actions, and may also provide capabilities to recover from successful attacks on the integrity of a system. Additionally, it may be necessary to prevent users from inadvertently impacting the integrity of the data or the system.

The following is a non-comprehensive list of mechanisms that may be employed to provide integrity services:

· Access control
· Checksums
· Digital signatures
· Recovery mechanisms
· Nonvolatile memory
· Deterrence
· Configuration control
· Secure maintenance of components
· Inspection of hardware/firmware/software (to include diagnostic routines)
· Comparison with known correct components
· Administrative procedures
· Physical security

IQHealth's standards for maintaining integrity:

1. The IQHealth system permits access to various types of information depending on the authorization status of the user. Different categories of personnel have access to different types of identifiable data, and may be authorized to read, enter, modify, amend or download data. Access is limited by physical controls, such as lock and key, secure card readers, biometric devices, and by electronic controls, such as password protection. Data access privileges will be periodically reviewed and revised based on job duties and requirements according to stated policies.

2. The identity of each internal IQHealth user will be verified, and time, date, user and purpose of use will record each action taken, including each access to information. The system's data security officer will be automatically notified of any inappropriate access or breach of authorization

3. Handling requests for personal health information:
§ Identifiable personal health information will not be disclosed to persons inside or outside of IQHealth without specific written authorization signed by the patient, or as required or permitted by law.

§ Requests for personal health information to be used for purposes such as marketing or sales, or to be provided to an outside third party or unauthorized employee, must be made in writing to IQHealth. Only aggregated or de-identified information may be provided without specific authorization from the patient. Any request for information must include a description of the information requested, why the information is needed, and the intended use for the information.
§ When a patient makes a request to review or copy his or her own personal health information, the patient will be referred to the individual or entity that created the information (e.g., the treating physician for medical records, the laboratory for test results, the payer for claims information). IQHealth will provide patients with copies of their personal health information if IQHealth is the sole source of the requested information.

4. In addition to other training required for users of the IQHealth system, employees whose work responsibilities necessitate access to personal health information must receive additional privacy and confidentiality training tailored to their work duties. For example, employees responsible for preventing unauthorized access to personal health information will receive training on DHHS's privacy, confidentiality and security standards. Training regarding privacy and confidentiality will be repeated and updated periodically.

5. Employees are obligated to report potential or actual violations of any security policy violation.

6. IQHealth employees must sign an agreement to protect the confidentiality of personal health information and, agree not to use or disclose such information except as specifically required or permitted by law. Unauthorized disclosures or uses of personal health information, or permitting unauthorized personnel access to such information may result in disciplinary action, up to and including termination of employment.

7. The Director of Computer Operations in conjunction with the Security Manager will ensure that an archive is maintained of all security-related patches for all applications, operating systems and versions and, that the appropriate patches are installed on the systems.

8. The Security Manager is responsible for maintaining awareness of new security vulnerabilities and attacks relevant to IQHealth's environment through various security publications including, but not limited to, the following in order to prepare for and prevent possible incidents.
§ CERT web site and advisories (http://www.cert.org)
§ CIAC we.g. site and advisories (http://www.ciac.org)
§ Vendor/supplier security advisories
§ BUGTRAQ newsgroup
§ NTBUGTRAP newsgroup
§ Anti-virus vendor/supplier advisories
§ The senior executive of each IQHealth functional business unit will ensure that the Privacy and Security Incident Response Team receives appropriate training.
4.1 Access to Media

Media volumes may be mounted and removed only by authorized employees, contract workers or consultants. Only company provided media will be mounted on IQHealth systems. All such actions will be recorded in the audit log.

4.2 Media Storage

The Security Manager or their designated surrogate will inventory all media residing at IQHealth facilities that store or have the potential to store personal health information on a weekly basis. The results of the inventory will be compared with the tracking log and any discrepancies investigated. Discrepancies will be reported within 24 hours to the Director of Computer Operations.

Storage Standards:

1. A tracking log will be maintained that accounts for each piece of media involved in storing personal health information including the description of the media and its use or status.

2. The Security Manager or their designated surrogate will apply a unique identification tag to each discrete piece of media introduced into IQHealth facilities including hard and floppy disks, tapes, CDs and any other storage media. Tags for internal hard drives will be affixed to the hard drive or the processor housing.

3. Each time a piece of tagged media either enters or leaves IQHealth facilities (e.g. transfer to off-site storage) the identification tag must be entered into the log along with the date, the origination point, the destination, the individual authorizing release of the media, and the person taking possession of the media.

4. The Security Manager and Director of Computer Operations will assign release authority.

5. The Security Manager or their designated surrogate will examine the tracking log daily. Irregularities will be investigated and dealt with accordingly.

4.3 Production Data Center Access

Access to the IQHealth production data center and systems is limited to only those employees, contract workers or consultants with explicit authority granted through the access control procedures or through special authorization by the Security Manager

5.0 Accountability

Accountability services provide the capability to verify the identity of various entities that initiate system events and allow reliable auditing of these events. Accountability includes authenticity and non-repudiation. Accountability validates and documents that an entity attempted to initiate a process or system event, that an event or process was initiated, who sent a message, that a message was sent, who received a message, and that the message was received. The following is a non-comprehensive list of mechanisms that are used to provide accountability services:

· Identification and Authentication
· SSL 128 bit encryption
· PKI technology and digital certificates
· Physical access controls
· Electronic Digital Signature
· Passwords and digital signatures
· Cryptography
· Event auditing

Secure Sockets Layer (SSL)

In conjunction with PKI, IQHealth utilizes the latest in Secure Sockets Layer encryption. SSL 3.0, using 128 bit encryption provides server authentication, encryption and decryption, and data integrity services. Authentication assures the web client that the data is actually being sent to the correct server and that the server is secure. Encryption/decryption transforms the data so that it cannot be read by anyone other than the secure target server. Data integrity ensures that the data stream has not been altered or tampered with in anyway.

IQHealth's standards for passwords:

1. All passwords must be difficult to guess. Words in a dictionary, derivatives of user IDs, and common character sequences such as 134567 or 9999999 must not be used. A name, a word, a license plate number, social security number, or date must not be used unless accompanied by additional unrelated characters. Acronyms, geographical locations, and slang terms must not be used.

2. The display and printing of passwords must be masked, suppressed, or otherwise obscured so that unauthorized parties will not be able to observe or subsequently recover them.

3. Passwords must not be stored in readable form in batch files, text files, automatic logon scripts, software macros, terminal function keys, in computers without access control, or in other locations where unauthorized persons might discover them.

4. All passwords must be promptly changed and the Security Manager must be notified if it is suspected or known that there has been information disclosed to unauthorized persons.

5. If there is evidence that a security environment has been breached, all passwords within that security environment shall be changed immediately.

5.1 PKI and Digital Certificates

Public Key Infrastructure (PKI) has emerged as the leading method for protecting sensitive information. Leveraging PKI, two parties can authenticate each other, and communicate securely via the Internet. IQHealth has implemented a PKI solution that allows a user to be identified by username, password, and a private key that exists only on the user's computer. Also, IQHealth serves as our own Certificate Authority, enabling us to issue or revoke digital certificates in a timely and effective manner.

The following are the core elements of our PKI solution:
· Public/Private key pairs: each pair consists of both a published public key known to all, and a private key known by only a single individual. The pairs are such that a message encrypted with one of the keys can only be decrypted using the other. This characteristic is useful from multiple perspectives. For example, encrypting a message with a user's public key guarantees that only that user can decrypt and view the message. Additionally, if that message has an attached digital signature formed from the private key of the sender, the receiver can use the sender's public key to verify that the message originated from that individual. This practice of signing a message with one's private key for proving authenticity is called digital signature.
· Certificate Authority (CA): The CA is an organization that issues digital certificates to other corporate entities or to individuals. A digital certificate ties together the owner's identity and the owner's public key. It is the responsibility of the CA to verify the identity of an individual or entity prior to issuing new certificates. The CA signs the certificate using the CA's unique digital signature so that anyone can use the CA's public key to check the certificate's authenticity. It is imperative that the CA be an organization that can be trusted to properly manage issued certificates. Proper management not only involves prudent credential checking during certificate issuance, but includes revoking and renewing certificates if digital certificates are lost or stolen, or security is otherwise compromised.

5.2 Test Coordination

IQHealth has a Test Planning Working Group since some of the assurance is provided through testing. This group is responsible for planning, coordinating, scheduling, and performing the various tests on the system. The security-relevant tests may be included in the various other tests to use the limited system testing time more effectively.

5.3 Follow-On or Upgrade to Existing System

When applicable, we closely monitor the decisions and methods used to upgrade a system to ensure that: (1) security is provided in or between the upgraded components, (2) security weaknesses in the existing/non-upgraded components are analyzed and appropriate countermeasures implemented, (3) inadequate components (from a security perspective) are replaced as part of the upgrade, and (4) transition to the upgraded system is securely accomplished.

Most likely, the request for the modification will be driven by (1) a new user requirement, (2) a new threat identified, or (3) a change in a technology (e.g., commercial-off-the-shelf (COTS) hardware or software products). No matter what the driving factor for the modification, the request should be processed through an IQHealth Consulting Project Executive.

6.0 Identify Security Environment

With the increased use of networking, the environment in which IQHealth products are deployed and maintained becomes a critical factor to the degrees of assurance, especially in regard to malicious code. Because the software is developed and maintained by trusted individuals and controls are implemented to protect against introduction of malicious logic, then the level of effort for reviewing the security-critical portion may be reduced.

6.1 Analyze and report

This phase includes two Activities: (1) perform an analysis of the system, and (2) report findings/recommendations. This phase also allows us to analyze the potential vulnerabilities and associated operational risks by revisiting the threat and risk analyses conducted earlier. These analyses are used during the architectural, design, and implementation work. In fact, threat, vulnerability, and risk analyses are conducted several times as this work progresses. The areas of risk on which IQHealth focuses are the protection of information from unauthorized access by individuals, denial of service with regard to deliberate attempts to disrupt the access to and processing of information, assurance that the integrity of information and system is maintained, and assurance of accountability. During this phase, IQHealth analyzes the system capabilities from a security perspective.

System security measures are typically based on system security policy and operational requirements. It must be emphasized that to provide a realistic and effective evaluation of the security posture of a system, all appropriate security disciplines must be included in the certification. The security disciplines include:

· Technical Security
· Communications security (e.g., network security, cryptosecurity)
· Physical security
· Operations security
· Personnel security
· Industrial security
· Other security disciplines are also to be considered

6.2 Perform Security Analysis

These tasks verify by analysis, inspection, and testing that the information security requirements have been correctly implemented and function correctly. In performing the system analysis, the following three major tasks are performed:

· Analyze detailed system information
· Conduct security analysis (e.g., documentation review, testing, architecture studies)
· Conduct a vulnerability assessment and risk analysis

Analyzing detailed system information involves a detailed review of system documentation gathered previously to determine if and how the system security requirements have been met and to determine where to focus the system analysis and testing. This activity is performed in preparation for system testing, to prepare documentation, and to verify if the security features are in place and meet the appropriate security requirements.

When conducting the analysis, each task must be conducted and the results viewed from a functional perspective to analyze trade-offs between solutions in the various security disciplines. This activity builds upon the knowledge gained during the detailed system analysis. The level of testing and analysis for each discipline will vary depending upon the sensitivity and criticality of the system and the assurance requirements.

6.3 System Security Architecture

The system security architecture is the physical representation of the security policy and the system functional requirements. It focuses on those aspects of the overall architecture that identify security services and mechanisms, allocates security-related functionality to system components or configuration items (CIs), and identifies interdependencies among the security-related components. System security architecture consists of system architecture, software architecture, interface analysis, security backdoor analysis, information domain identification, and composition analysis. The intent of the system security architecture analysis is to identify how effectively the system architecture enforces the security policy and implements the security requirements. The interfaces are evaluated to assess their effectiveness in maintaining the security posture of the infrastructure.

6.4 Network Connection Analysis

Task Objective: Analyze the connections to other systems and/or networks to ensure that network and overall system security policies are being enforced.

Task Description: The connection of an individual system to a network requires assurance that the addition of that particular system does not adversely impact the network's security posture. Similarly, assurance is required that users of the network can not adversely impact the system security posture. This subtask examines the system to ensure: 1) the system adheres to the network's security posture by enforcing the network's security rules and procedures, and 2) a system security policy has been defined and is sufficiently enforced to protect the system from unauthorized users or processes attempting access from the network. This subtask examines the system to ensure the system adheres to the network's security policy by enforcing the network's security rules and procedures.

6.5 Software Engineering Analysis

Task Objective: Ensure the developer/maintainer is using sound and proven development approaches, engineering environment, system analysis and design methodologies, coding standards, and software modularity techniques.

Task Description: Review the developer/maintainer's software engineering discipline, development approach, and engineering environment to analyze whether its use is likely to result in a system that meets the system architecture requirement. During the code studies, the team compares the implementation to the system described in the design documentation and determines whether the software engineering discipline is reflected in the implementation. In analyzing the modularity of the software, the certification team may analyze the strengths of attributes that may be indicative of modularity and software quality. The following is a non-comprehensive list of these attributes:

· Code cohesion
· Complexity
· Coupling
· Data cohesion
· Duplicate code and data
· Extraneous code and data
· Reliability
· Correctness
· Verifiability

Coding standards, the principles by which the code is written, are usually part of the documentation of the software engineering process, and they may support both the configuration management and system architecture requirements. The analysis includes:

· A description of restrictions on the size of modules

· A description of the rules for using mechanisms that support least privilege

· A review of the rules and conventions governing the selection of identifiers (variables, parameters, filenames)

· A justification for the languages chosen

· The interface constraints and standards that describe a form and style for interfaces supporting the information domain model

· The standard forms and styles for handling initialization and termination conditions, and error recovery and exception handling

· The peer review of the software modules (e.g., design consistency, malicious code)

6.6 Interface Analysis

Task Objective: Identify interfaces into the system components.

Task Description: With the increased use of third party communication and security products, the interfaces between the various components of the system become a critical area. Although standards exist, each vendor may have a slightly different method of implementing the appropriate standards. This task must be repeated if technical countermeasures are implemented after this task has been completed.

6.7 Engineering Backdoor Analysis

Task Objective: Determine if any engineering backdoors exist and identify their maximum attainable function(s). Once backdoors have been identified, their functions should be reduced to an acceptable level per the security policy.

Task Description: Ensure that no unintended/unauthorized communications paths exist that violate the security policy. IQHealth focuses on the identification of one or more of the following: (1) illegal information flows in top-level design specifications and source code, (2) identification of shared information domain components, (3) state transition analysis of the information domainTCB, and (4) changes implemented to the system to reduce the functions of each backdoor.

6.8 Life-Cycle Analysis

There are several ways to ensure life-cycle assurance and they must build on each other in order to achieve the final goal of assuring the security features are implemented properly. Life-cycle assurance provides the overall structure, but security analysis, verification, and testing provide the specifics. Technical security analysis is the primary way to determine if the requirements are analyzed and documented properly. Validation that the specifications have been implemented properly may be accomplished by various methods (e.g., analysis, demonstration, inspection) depending on the system and assurance required.

This process begins as soon as the system's requirements are approved and continue until the system is retired or replaced. There are several reasons for performing life-cycle assurance:

· A baseline be established at a given point in the system life cycle,

· Systems evolve over time and do not remain static.

· Contingency planning must be addressed for catastrophes (natural or human).

· The use of the system's finite set of resources will grow through the system's life cycle.

The purpose of these reviews is to ensure that change control and configuration management
practices are in place to preserve the integrity of the system.

7.0 Testing

Testing is the most traditional method of demonstrating that a system functions correctly. Unfortunately, there is truth in the familiar observation that testing only documents the presence of errors, not their absence. One cannot know that a particular error has been made (or not made) unless one tests for it, and there is no way of ensuring that a testing program covers every possible kind of error. The more complex a system, the harder it is to devise thorough tests because the number of possible sequences of operation for even a small program can be enormous. Testing is one of the four methods (i.e., testing, analysis, inspection, demonstration) to verify that a requirement has been correctly implemented.

7.1 Security Functional Testing

Task Objective: Validate that the system provides the required security features. If the system connects to a network or another system, ensure that the security of both ends is being maintained.

Task Description: Hands-on testing should focus on information domain interfaces, system initialization, shutoff, and aborts, ensuring that the system remains in a secure state. Because it is not feasible to include every possible input when testing a system, the tester tries to select those inputs that will exercise every module or every system function and place stress on the system. The tester starts with inputs that will demonstrate that the module or system meets each requirement. Errors are introduced to demonstrate whether the system fails to perform its function when given invalid commands. If network connections are being used, the team verifies that the connection rules are enforced.

7.2 Reliability Testing

Task Objective: Validate that the system meets the required reliability.

Task Description: Obtain the hardware and software failure reports and determine the reliability of each critical component. This data is obtained from the operational system (if it is an existing system), or from the application and platform suppliers.

7.3 Penetration Testing

Task Objective: Circumvent the system security features.

Task Description: Penetration testing includes reviewing all system design and implementation documentation (e.g., system source code, manuals, and communications diagrams) and hands-on testing. When performing this testing, the certification team should work under no constraints and should have complete hands-on access to the system. Although a penetration test plan should be developed, it should allow for flexibility if weaknesses in the system are found. A team of individuals who are familiar with the system being tested and with typical flaws in protection systems should attempt to defeat the protection mechanisms of the system. The techniques used are both analytic and intuitive. First, flaws are hypothesized and tested. If these flaws materialize, they are extended to try to defeat more components of the system. In this way, the penetration testers should try to operate as would an intruder intent on defeating the protection mechanisms of the system.

7.4 Human Factor Testing

Task Objective: Determine the security awareness requirements of the personnel who will be using the system and responsible for maintaining the integrity of the information domain model. Proper personnel security awareness is the major focus of this task.

Task Description: Health care and other personnel who make routine use of the system require a clear operational understanding of their own responsibilities for the privacy and confidentiality of the medical record, and for the security functions of applications used to store, process and communicate the record. Personnel are selected on a sampling basis and efforts made to provoke a violation of the organization's security policy and procedures should be carried out.

In conducting security awareness reviews we consider the location of the facility, the sensitivity and perishable nature of the information processed, the physical control over the facility, and the sensitivity/criticality profile of equipment. However, the requirement to conduct or validate a security awareness review does not necessarily imply the need to implement technical countermeasures. Oftentimes the greatest benefit to security functionality can be obtained through an effective security awareness program.

7.5 Contingency Plan Testing

Task Objective: Ensure that the contingency plan addresses all known risks to the system and is current, complete, and is tested. These risks include:

· Natural risks (fire, storms, earthquakes)
· Environmental risks (water, steam, power, air conditioning)
· Security risks (system failure, security violation)

Task Description: These procedures specify the steps and actions to be taken to protect life and property and to minimize the impact of the contingency. Since there will always be risks associated with any computer system, backup and recovery plans are a necessity. A contingency plan contains the procedures for backing up critical applications and hardware and procedures to recover quickly from an unforeseen disaster for which no safeguard was implemented, the safeguard failed, or was bypassed. The team should review the Risk Analysis Report and identify emergency conditions that will impact system operation. The contingency plan covers the following items:

· Emergency response procedures
· Backup operations
· Recovery procedures
· Plan maintenance
· Preparatory actions
· Testing
· Critical applications identification
· Critical resources identification

IQHealth standards:

1. Each full backup will be retained for at least two weeks and will be stored off-site.

2. Full backups will be completed on a daily basis.

3. Backups of essential business and clinical information will be stored in an environmentally protected and access-controlled site that is a sufficient distance away from the originating facility to escape a local disaster.

4. Prior to completing the backup process, the media will be verified for accuracy with the original.

5. To prevent information from being accessed by or used by unauthorized parties, all sensitive, valuable, or critical information recorded on backup computer media (e.g. magnetic tapes, floppy disks, optical disks) stored outside IQHealth facilities must be in an encrypted form.

6. IQHealth uses strong encryption for the protection of personal health information. Encryption standards will insure the selected encryption schemes and keys are considered invulnerable to brute-force attack for ten or more years. Key lengths and encryption methods will be evaluated on an annual basis to determine if levels of encryption are adequate in view of cryptographic and processing technology.

7. Computer and network backup storage media that has not been transferred offsite must be temporarily stored in secure, separate fire zones from the machine producing the backup.

8. The data center in which all IQHealth media is kept is staffed 24 hours a day, 7 days a week.

9. All fire and alarm systems are maintained and tested regularly.

10. Designated emergency procedure teams are available 24/7 and are trained in Emergency response procedures and critical information systems back up.

8.0 Operational Procedure Review

Task Objective: Determine if operational procedures have been established and are being followed by all appropriate users to minimize system security deficiencies.

Task Description: For each system risk that an operational countermeasure was implemented to address, we ensure that the procedure has been implemented correctly, reduces the risk to the specified level, and is being followed by all appropriate system users. For each operational procedure, determine that all users have been properly trained.

8.1 Conduct Vulnerability Analysis

The vulnerability analysis task is conducted throughout the process and in conjunction with the other analysis tasks. It is completed at the end of multiple previous activities to examine all the reported discrepancies, to determine if any vulnerabilities exist, and if so, to evaluate the residual risk from these vulnerabilities. This task is a key function of the ongoing risk management of the system development.

8.2 Vulnerability Evaluation

Task Objective: Evaluate security vulnerabilities of the services providing confidentiality, integrity, availability, and accountability, evaluate residual risk, and recommend appropriate countermeasures.

Task Description: Analyze each of the vulnerabilities and discrepancies isolated during the course of the System Analysis to determine the ease of exploitation, potential rewards to the exploiter, probability of occurrence, related threat, and residual risk. Conduct fault tree or flaw hypothesis (static penetration) analysis to determine the ability to exploit the vulnerabilities discovered during the previous analysis tasks. Determination of the potential rewards to the exploiter shall consider the sensitivity of the data and processes, criticality of system operation, time criticality, ability to recreate the data or processes, etc. The residual risk (that portion of risk that remains after security measures have been applied) are determined by ranking the evaluated vulnerabilities against threat, ease of exploitation, potential rewards to the exploiter, and a composite of the three areas. All residual risks are identified and evaluated. The evaluation indicates the rationale as to why the risk should be accepted or rejected. Appropriate countermeasures are determined for each of the high-risk vulnerabilities.

8.3 Protection of Findings

The disclosure of information which, if exploited, could impact the function of a system or allow security features to be bypassed, must be protected from disclosure to unauthorized persons. These findings include, but are not limited to, identification of residual risks and recommendations made during the analysis. The package containing all the information and findings must be marked, handled, and controlled consistent with the sensitivity of the information it contains.

9.0 Access to Systems and Information

9.1 Remote access

All computers that have remote, real-time dialogues with IQHealth production systems must run an access control package approved by the Security Manager.

9.2 Access termination for departing employees, contract workers or consultants

Individuals who are no longer employed, under contract or actively consulting with IQHealth will not have access to any non-public, corporate information systems.

Standards:

1. Human Resources will notify the Security Manager of any voluntary or involuntary termination or suspension prior to the actual termination or suspension.

2. The user will surrender all keys, badges, access cards or company owned equipment in the user's possession providing access to secured system resources.

3. The Security Manager will inform the administrator to delete the terminated or suspended user's account.

4. Once the Administrator deletes a user account, the Security Manager will be informed of the deletion.

5. If the user had root privileges and/or access to any shared passwords for any system, the shared password for that system will be changed.

6. The Security Manager will check the master accounts list to ensure that all user accounts assigned to the user have been deleted. The Security Manager will record the user's name and the date on which each user account was deleted.

7. At the next audit cycle the Security Manager will positively verify that no user account for the user exists in any security environment and that no activity related to the user has occurred.

9.3 Access to Information by Designated Providers

Aside from policy directed at IQHealth employees, contract workers or consultants, personal health information is provided only to authorized physicians and health care providers that are responsible for a patient's medical treatment. IQHealth will maintain a specific provider agreement with each such individual. This approval does not obviate the need to obtain appropriate consent of the individual. Wherever possible, the anonymity of individual healthcare recipients will be preserved. Where anonymity is not possible, the "need to know" standard will be applied.

Privacy is the essential duty of all authorized physicians and health care providers. All suspected violations of IQHealth's privacy guidelines -- whether accidental or intentional-- must be reported as soon as possible using the appropriate channels of communication.

9.4 Continuing Education for Staff with Access to Personal Health Information

All staff with access to personal health information must have sufficient initial training as well as continuing education in all critical aspects of their jobs including corporate policies regarding privacy, security, confidentiality, information integrity, and access to personal health information.

9.5 Access to Individually Identifiable Health Information by Remote Means

Maintaining the confidentiality, security and privacy of personal health information is of the utmost importance to IQHealth. By maintaining the highest standards, IQHealth can be entrusted with the most personal of information by the public. No non-encrypted or unauthorized access to any personal health information will be allowed for any purposes not specified in the policies, standards and procedures of IQHealth. Individuals working with such information on a regular basis will be required to work at designated IQHealth facilities.

9.6 Use of the Systems

Users will not engage in any activity with intent to harass other persons; degrade the performance of systems, deprive an authorized user of access to a resource, obtain extra resources without proper authorization, and/or, circumvent security measures or gain access to a system or information without proper authorization. Users will not make copies of system or network configuration information (e.g. password lists, network diagrams) for their own unauthorized personal use, or to provide to other people for unauthorized uses.

10.0 Procedure for Intrusion

It is the responsibility of all users to immediately report any knowledge of system intrusion or potential attacks on IQHealth systems to a Security Manager or their designated surrogate.

10.1 Responsibility to Report Violations

Violation, intentional or otherwise, of any of the policies stated above will constitute a security violation and will be reported to the user's management. Disciplinary action will be determined, on a case-by-case basis. Disciplinary action can include, but is not limited to, warnings or revocation/suspension of access to specific computing resources. In severe cases disciplinary action may include termination of employment, civil prosecution, or criminal prosecution.

10.2 Collecting Privacy and Security Violation Information

The Privacy and Security Incident Response Team will log all relevant response information (i.e., information that addresses the who, what, where, when, why and how of the incident). Examples include name of system, date and time of each entry, what actions were taken, who was notified, who had access, and what data was collected. Other information will be obtained as determined by the Privacy and Security Incident Response Team.

10.3 Collection of Information

The Privacy and Security Incident Response Team will identify, collect, tag and protect all transaction information that may have relevance to the privacy or security violation. The Privacy and Security Incident Response Team is responsible for maintaining a complete chain of custody record for all information gathered in the process of investigation.

11.0 Security Reporting

11.1 Reporting Security Incidents

All suspected information security incidents or vulnerabilities must be reported as quickly as possible through the correct IQHealth internal channels.

Reporting Standards:

1. Employees, contract workers or consultants who observe evidence of a possible intrusion attempt should contact the Data Center immediately since the Data Center is staffed 24 hours a day, seven days a week. To reach the Data Center staff, individuals should call the Data Center support line at (816) 201-4673 and speak with the Data Center Operator on duty.

2. The Data Center Operator will immediately contact the Security Manager. If a response is not received within 15 minutes the report will be escalated to the Director of Computer Operations.

3. The Data Center Operator will also immediately contact the Privacy and Security Incident Response Team and security and system managers at other locations. If the Privacy and Security Incident Response Team members do not respond within 15 minutes, alternate members will be chosen and contacted.

4. Due to the possibility that the e-mail system could be compromised during such an incident, all contact will be accomplished primarily through pager and phone calls.

5. The Security Manager or the Privacy and Security Incident Response Team leader will fully document the precipitating event in writing. The Privacy and Security Incident Response Team leader will sign the written document.

11.2 Incident or intrusion investigation responsibility.

The Privacy and Security Incident Response Team will be responsible for leading the investigation of any perceived or real incident or intrusion of the IQHealth system.

Standards for Analysis:

1. The Privacy and Security Incident Response Team will capture and record system information that could be lost during execution of backup procedures. This includes
§ All current network connections.
§ All current processes.
§ Active users currently logged on.
§ All open files.

2. The Privacy and Security Incident Response Team will immediately construct two full backups of the compromised system(s), ideally onto write-once media. One copy will be immediately placed into a secure location and protected under the rules of evidence. The second copy will be made available for analysis.

3. Once full backups are constructed, the Privacy and Security Incident Response Team will search other systems for signs of intrusion; examine logs generated by firewalls, network monitors, and routers; identify the attacks used to gain access; and, identify what the intruder did once access was gained.

Standards for Collecting and Protecting Intrusion Information:

1. The Privacy and Security Incident Response Team will log all relevant response information (i.e. information that addresses the who, what, where, when, why, and how of the incident). Examples include name of system, date and time of each entry, what actions were taken, who was notified, who had access, and what data was collected. Other information will be obtained as determined by the Privacy and Security Incident Response Team.

2. The Privacy and Security Incident Response Team will archive all relevant information to physically secure off-line and off-site media.

3. The Privacy and Security Incident Response Team Leader is responsible for maintaining a complete chain of custody record for all evidence gathered in the investigation. The Security Standards Committee will be responsible for approving the chain of custody protocol used in incident investigations.

11.3 Short-term Containment:

The Privacy and Security Incident Response Team is responsible for containment of the intrusion or incident. Measures that will be taken include such areas as changing passwords or disabling accounts; disabling specific services; disconnecting the compromised system from the local area network; or disconnecting the local area network to which the system is connected from the networks that the intruder is using.

Standards for Intruder Access Elimination:

1. The Privacy and Security Incident Response Team will take steps to ensure that all systems are protected against the same or similar types of attack. The Privacy and Security Incident Response Team will use the results of the intrusion analysis to determine the means by which an intruder gained access and take steps to eliminate the possibility of a similar future intrusion. These can include:

§ Known vulnerabilities for which patches are available,
§ The presence of malicious code,
§ Changing the passwords of existing users,
§ Corrupted configuration files containing, for example, previously disabled entries,
§ Trojan horses or back doors executed at boot time.

2. The Privacy and Security Incident Response Team will restore compromised executable programs (including application services) and binary files from trusted sources.

3. The Privacy and Security Incident Response Team will review system configurations including user accounts, system services, audit and monitoring facilities, and access control lists. They should be checked against trusted copies or cryptographic checksums. If these are unavailable, a peer review should take place.

4. The Privacy and Security Incident Response Team will confirm that all available patches and fixes have been installed.

5. The CSIRT will review the configuration of protection and detection mechanisms.

Standards to Return Systems to Normal Operation:

1. The Privacy and Security Incident Response Team will verify that operating systems on all affected system(s) have not been altered. If this cannot be done or checks indicate unauthorized modifications, reinstallation of the operating systems from trusted copies is required. Site-specific modifications and relevant patches will be completed, as necessary.

2. The Privacy and Security Incident Response Team will restore user data from trusted sources in the event the original user data was compromised during the intrusion or incident.

3. Once these procedures are accomplished, the system will be re-enabled and application services re-initiated by the Privacy and Security Incident Response Team. Reconnection of restored systems will be made to the local area network.

4. Once the system is fully operation, the Privacy and Security Incident Response Team will observe the system for scans or probes that may signal the intruder's return and, in particular, monitor attempts to re-exploit the original vulnerability.

11.4 Avoidance of Communication Network Central Point of Failure

IQHealth requires that the communications network system be totally redundant. A minimum of two separate and distinct network access services will be maintained at all times to prevent the unavailability of communication linkages due to external system failures.

11.5 Continuous Computer Center Staffing for Prompt Problem Resolution

To assist with problem detection and resolution, technically competent staff will staff the primary data center twenty-four hours per day, seven days per week. A minimum of at least two employees, contract workers or consultants will be on duty at any time to staff the primary data center.

11.6 Expected Employee Assistance during Business Restoration

Employees, contract workers and consultants are expected to be present, and to assist to the best of their abilities, with the restoration of normal business activity after an emergency or a disaster disrupts IQHealth business activity. In the event the emergency or disaster involves the employee's family and/or personal assets, the family and personal assets will be the priority. Once the individual's personal situation is determined to be safe, the employees, contract worker or consultant will be expected to work overtime to assist IQHealth in recovering from the emergency or disaster.

12.0 Cross Training For Staff in Critical Technical Jobs

At all times, at least two staff members should be able to provide essential technical services for information systems critical to IQHealth business. If less than two staff members can provide these essential technical services, management must initiate cross training, additional hiring, outsourcing, or other remedial actions. Once per year, management will prepare an inventory of key IQHealth technical jobs and the names of the individuals holding those positions.

12.1 Preventive Maintenance on Computer and Communication Systems

Preventive maintenance must be regularly performed on all computer and communications systems such that risk of failure is kept to a reasonably low probability.

12.2 Software Version Control

All information system software used for mission processing, including internally developed and commercial software will be catalogued with current version numbers, configurations and installation locations. A version control library will be established and maintained so that the current version is clearly identified, and prior versions of software are retained for at least two years beyond the operational use of the software.

12.3 Information Systems Equipment Maintenance Requirements

All information systems equipment used for production processing will be maintained at a minimum in accordance with the supplier's recommended service intervals and specifications. Only qualified and authorized maintenance personnel will perform repairs and servicing of equipment.

12.4 Directory of Information Held in Archival Storage

All archival backup data stored off-site will be documented in a directory containing the date the information was most recently archived and the nature of the information. The Security Manager will maintain the directory.

12.5 Access to Media

Media volumes may be mounted and dismounted only by authorized employees, contract workers or consultants. Only company provided media will be mounted on IQHealth systems. All such actions will be recorded in the audit log.

12.6 Disposal

Media that are internally recycled within IQHealth facilities from a secure to a non-secure environment will be overwritten to Department of Defense standards to prevent recovery of any personal health information. Media intended for disposal or external transfer beyond IQHealth control must be erased using a device or utility that meets or exceeds NSA/CCS L1 4-4-A standards. The Security Manager or Director of Computer Operations will confirm the recycling or disposal procedure prior to release of the media.

Disposal Standards:

1. The Security Manager or their designate surrogate will log media out of the tracking system when media are moved from a secure IQHealth environment to a non-secure environment.

2. The log will indicate the date the media was recycled or transferred including the details of its disposition (e.g. discarded, recycled, transferred to development).

12.8 Change Management

Change management is the application of engineering and administrative protocols when introducing changes in the IQHealth production and development information systems. Software, hardware configuration, and work procedures are all subject to change management under explicit protocols. For change management to be an effective tactic for managing the information systems, it must be applied throughout the entire development lifecycle of the system. Effective change management insures that:

§ Approved changes are properly integrated to reduce the potential impact of the change on production systems.
§ Items submitted for integration are carefully tested and controlled versions to minimized troubleshooting during version control rather than focusing on integrating the item(s).
§ The integrity of all operating environments is maintained and compatible.
§ Only authorized modifications are made to an established configuration baseline; thereby eliminating the potential for inadvertent, malicious, or fraudulent changes to be introduced into the system.
§ Service Level Agreements are maintained and decision affecting service levels are made from known baseline.
§ Previous Service Level Agreement commitments can be identified and change history determined during any investigation.