• Perpetual Storage (http://www.perpetualstorage.com/index_home.htm) an off-site storage facility, allegedly lost, by the action or inaction of one of its’ drivers, backup tapes belonging to the University of Utah, when the tapes were stolen from an employee’s car.
• Colorado Casualty is now seeking (see Binder1-Utah) a declaraton that it is not responsible for covering the loss of $3.3 million associated with notifying 1.7 million people whose individually identifiable information was lost. (http://www.sltrib.com/education/ci_14978059).
• On June 1, 2008, an employee of Perpetual Storage picked up backup tapes containing information about 1.7 million people, 1.1 million of which contained social security numbers, in a secure vehicle to transport the backup tapes directly and immediately to the granite vault facility.
• Early on the morning of June 2^nd the tapes were stolen from the vehicle of the Perpetual Storage employee.  This year Colorado Casualty filed a declaratory judgment against Perpetual Storage, Inc. (“Perpetual Storage”) and the University of Utah (which operates a hospital).

The costs associated with the breach included:

• $2,483,057 related to credit monitoring expenses;
• $646,149 related to printing and mailing costs;
• $81,389.00 related to phone bank costs; and
• $144,158.00 in miscellaneous costs.

The Colorado Casualty (the insurer of Perpetual Storage) specifically seeks a judgment Colorado is not obligated to pay the breach related costs sought by the University of Utah.  Despite the lack of cause discussed in the suit, it is likely that the insurance company believes that since the data was in the possession of the storage company, it is not responsible to cover the funds.

According to the University’s Answer to the Complaint, for Declaratory Judgment, Cross-Claim, Counterclaim And Third-Party Claim And Jury Demand (“Answer”):

Perpetual’s normal business practices and protocols required Perpetual to immediately deliver University records, including backup tapes, to the granite vault facility. Specifically, Perpetual employees are required to make all storage runs using a Perpetual vehicle that has locked storage compartments in the rear. Moreover, Perpetual employees are forbidden from delaying their delivery of records from the client to the granite vault facility.

(See Answer at 17).

According to court documents — in early July 1, 2009, law enforcement officials recovered the stolen backup tapes.  However, the University has already committed to offering free credit monitoring to all patients whose social security numbers were contained in the backup tapes.

Related Blogs

• British Insurance & Moneynet Launch Payment Protection Insurance Guide
• Bermans Investments: Term Life Insurance Quotes | financebis
• Granite Ware 11.5 Quart Canner Rack | Sale Best Price
• Large Natural Cart with Granite Top | Best Buy Cheapest Price
• Property and Casualty Insurance License Exam Manual | Auto Insurance Quotes Plan

          

Does your insurance policy cover security incidents? originally appeared on Law Blog 2.0 on June 12, 2010.

The typical use case of an HIE under a federated exchange model transaction involves:

• Initiation of a request to the HIE service to determine if a person has relevant medical information within the HIE;
• A response is returned to the requesting organization, which would request to receive the relevant data.
• The HIE service would verify that the requesting organization is authorized, authenticated, and has access privileges to the information and that the person has provided consent for transmission of the given information;
• The approval along with supporting metadata is transmitted to the supplying organization who has the relevant information; and
• The disclosing organization would supply the information as required by the underlying data sharing or HIE participation agreements.

Both HIEs and networks of HIE (basically the NHIN) must be able establishing a baseline of trust among participants, typically, this trust includes–

• Processes to ensure the integrity of patient data;
• Verifiability of data after transforming, storing and/or sending (e.g. checksum, error checking, etc.);
• Verification that the data source and data content are true; and
• Organization the HIE or the NHIN can define standardized data values and a protocol format for sharing medical data.

Implementation usually requires:

• A data sharing agreements and policies to enable information sharing and make system usable;
• An enterprise master patient index (eMPI) which serves as a record locator; and
• A balancing of data standardization (normalization) and physician freedom to have clinical control of the medical record while being efficient in their treatment of patients.[ii]

I have excerpted privacy and security related covenants from a document entitled Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009, which provides a summary of key features of a comprehensive agreement that governs the exchange of health data across a diverse set of public and private entities.  This agreement – the Data Use and Reciprocal Support Agreement (“DURSA”) requires that:

• To the extent that each Participant has existing privacy and security obligations under applicable law (e.g. HIPAA or other state or federal privacy and security statutes and regulations), the Participant is required to continue complying with these obligations.  Participants, which are neither HIPAA covered entities, HIPAA business associates nor governmental agencies, are obligated to comply with specified HIPAA Privacy and Security Rules as a contractual standard of performance.
• It is the responsibility of the responding Participant – the one disclosing the data – to make sure that it has met all legal requirements before disclosing the data, including, but not limited to, obtaining any consent or authorization that is required by law applicable to the responding Participant. This policy is essential for nationwide health information exchange given the number of different state laws, Federal statutes and local policies related to consent or authorization to exchange data for treatment purposes. To effectively enable the exchange of health information in a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy and Security Rules as minimum requirements.
• Participants are required to promptly notify the NHIN Coordinating Committee and other impacted Participants of breaches which involve the unauthorized disclosure of data through the NHIN, take steps to mitigate the breach and implement corrective action plans to prevent such breaches from occurring in the future. Suspected breaches must be reported within one (1) hour of discovering information that leads the Participant to believe that a breach may have occurred.  As soon as reasonably practicable, but no later than twenty-four (24) hours, Participants must notify affected Participants and the NHIN Coordinating Committee This process is not intended to address any obligations for notifying consumers of breaches, but simply establishes an obligation for Participants to notify each other when breaches occur to facilitate an appropriate response.

(See Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009)

HIE services typically includes:

• Patient identification and registry services within a directory structure;
• Consent management and enforcement of a user’s consent when collecting, storing, accessing, processing, and disclosing personal health information; and
• Information for the patient about the HIE at the point of care and a business process to obtain consent that will be used  for future exchange of data until changed by the individual.

The CONNECT framework is designed to offer similar services for the NHIN.  CONNECT is designed to implement privacy and security controls defined in the NHIN services, and when implemented and combined with the NHIN operating procedures and the DURSA, it allows organizations to participate in the “web of trust” that enables the secure exchange of interoperable health information among the participants of the NHIN.

Privacy and security laws do not directly cover NHIN in the sense NHIN is really a collaboration of many organizations who elect to participate in the network.  Several different types of entities participate in the NHIN. There are HIPAA “covered entities”, such as providers, there are the HIPAA-defined “business associates” of those covered entities, and there are non-covered entities which are not currently required to comply with HIPAA rules.

The NHIN is more like the Internet than a traditional health information system found within a hospital.  NHIN while not a covered entity, NHIN has a similar threat profile.  Similar to an HIE, the Data Use and Reciprocal Support Agreements (DURSA) permit network participants to contract the specific terms under which they will exchange information, including addressing privacy and security needs of each NHIE amongst themselves.  The responsibility for security, including compliance with state and federal laws, including HIPAA, rests with the member organizations or the network nodes a hospital, physician’s office, etc.  Examples of common DURSA contracts/agreements are listed in the table below.

The typical Connect implementation involves the use of a server based PKI and the NHIN NHIE service registry which define and secure the NHIN core backbone.  Connect services include-

• The messaging platform and authorization framework to implement security and privacy controls to address the known threats for Web services implementations of service-oriented-architectures;
• The audit log query service is designed to meet the requirements for HIPAA disclosure accounting;
• The consumer preferences profile allowomg consumers to express their preferences for whether or not to share their information on the NHIN and for more granular control over access to their private information. The CONNECT policy engine enforces those preferences in the runtime environment to insure that the access policies of the organization and the preferences of the consumer are honored in the decision to release health information in response to a request from the NHIN

In a separate draft publication ONC has detailed use cases on how to obtain, modify, and detail a patient’s consent to access his/her medical record.

If this all seems to daunting, a less ambitious project was recently announced by ONC called NHIN Direct.  The NHIN Direct project is focused on smaller providers who are unable to implement the Connect solution, and/or put in place an appropriate DURSA.  According to ONC- “NHIN Direct is intended to solve simple direct secure electronic transport supporting health information exchange currently being handled via paper or portal communication following existing trust models.”

Transactions that would fall within the scope of NHIN Direct would be those transactions involving the communication of pre-existing information typically transferred via fax, courier, mail or clipboard, or in some cases, via a patient/physician portal.  The transactions must be “push transactions” where patient identity is known and consent and legal authorization exists for the information transfer. (See http://nhindirect.org/User+Stories).[iii]

Additional Information – Data Sharing Agreements

Sample DURSA Business Associate Addendum

Sample Health Information Exchange Agreement

AMENDED AND RESTATED CLINICAL OUTCOMES ASSESSMENT PROGRAM HEALTH CARE PROVIDER INFORMATION SHARING AGREEMENT

ONC NHIN Draft Policies

2010 NHIN Final Production Specifications
The following specifications have been provisionally approved by the NHIN Technical Committee. This approval is subject to the validation of the NHIN reference implementation.

• Access Consent Policies Production Specification – v1.0 [PDF - 176 KB]
  
• Authorization Framework Production Specification v2.0 [PDF - 256 KB]
  
• Query for Documents Production Specification v2.0 [PDF - 212 KB]
  
• Retrieve Documents Production Specification v2.0 [PDF - 178 KB]
  
• Health Information Event Messaging Production Specification v2.0 [PDF - 152 KB]
  
• Messaging Platform Production Specification v2.0 [PDF - 248 KB]
  
• Patient Discovery Production Specification v1.0 [PDF - 214 KB]
  
• Web Services Registry Production Specification v2.0 [PDF - 378 KB]
  

Additional Information Available at the Following Sites:

• American Health Information Community (AHIC) http://www.hhs.gov/healthit/ahic.html
• American Health Information Management Association (AHIMA) http://www.ahima.org/
• Certification Commission for Healthcare Information Technology (CCHIT) http://www.cchit.org
• Commission on Systemic Interoperability http://endingthedocumentgame.gov
• Healthcare Information and Management Systems Society (HIMSS) http://himss.org/ASP/index.asp
• HL7 United States http://www.hl7.org/
• International Health Terminology Standards Development Organization (IHTSDO) and SNOMED International http://www.ihtsdo.org/
• Office of the National Coordinator of Health Information Technology (ONCHIT) http://www.hhs.gov/healthit/

[ii] CONNECT has three primary components:

1. The Core Services Gateway implements the core NHIN services enabling such functions as locating patients at other health organizations within the NHIN, requesting and receiving documents associated with the patient, and recording these transactions for subsequent auditing by patients and others. Other features include authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information.
2. The Enterprise Service Component (ESC) provides default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log.
3. The Universal Client Framework contains a set of applications that can be adapted to create an edge system, and be used as a reference system, and/or can be used as a test and demonstration system for the gateway solution.

[iii] The project has highlighted the following use cases for the NHIN project:
1. Primary care provider refers patient to specialist including summary care record
2. Primary care provider refers patient to hospital including summary care record
3. Specialist sends summary care information back to referring provider
4. Hospital sends discharge information to referring provider
5. Laboratory sends lab results to ordering provider
6. Providers without a fully certified EHR send and receive data
7. Primary care provider sends patient immunization data to public health
8. Pharmacist sends medication therapy management consult to primary care provider
9. Provider sends patient health information to the patient
10. Provider sends a clinical summary of an office visit to the patient
11. Hospital sends a clinical summary at discharge to the patient
12. Provider or hospital reports quality measures to CMS
13. Provider or hospital reports quality measures to State
14. Laboratory reports test results for some specific conditions to public health
15. State public health agency reports public health data to Centers for Disease Control
16. Provider reports to the State
17. Hospitals reporting to the State

Related Blogs

• Great Visualizers: Stefanie Posavec | Information Is Beautiful
• The anatomy of HIPAA.: An article from: Arkansas Business
• ‘This is a patient’s bill of rights on steroids’ | RedState
• Patient input in their treatment should be valued by doctors | KevinMD.com

          

HIE and NHIN Implementation Issues: (a) Data Sharing Agreements, (b) the Master Patient Index, (c) Data Standardization, (d) Consent Requirements, and (e) Duties of Network Participants originally appeared on Law Blog 2.0 on March 25, 2010.

Identity Theft and Consumer Protect Laws.

One of the most common (and high risk) user installed software found on the enterprise desktop computer is P2P[i] file-sharing software.  This software can be detected with networking scanning software like Nessus.[ii]

Unlike, other software, P2P file-sharing software is very effective at circumventing an organization’s security perimeter.  In most organizations measures in-place to prevent users from installing software are easily circumvented: (1) by installing and running the device from a USB key, (2) using the local Administrator account to install the software because the local Administrator account has not been set after the last re-image or the local administrator account password is known to users, or (3) IT installs the software at the request of a user.  Recently, the Department of Health and Human Services (“HHS “)has been very proactive in getting the message out that portable media, laptops, and other similar devices that contain electronic protected health information (e-PHI) must be encrypted.  However, despite numerous alleged disclosures of e-PHI on P2P networks, HHS is failing to inform patients, covered entities, and business associates of covered entities about the risks of peer-to-peer (P2P) file sharing and the inadvertent sharing of documents containing e-PHI.

Last Summer P2P programs reportedly inadvertently shared information about presidential motorcade routes, a Secret Service safe house for former first lady Laura Bush, and personal information of more than 220,000 soldiers and hospital patients.[iii]

In February of 2009, a researcher at Dartmouth College using four P2P networks — Gnutella, FastTrack, Aries and eDonkey —collected 3,328 files.  The researcher located 161 unique files contained sensitive information that could be used to commit medical or financial identity theft. (See Johnson, M. Eric, Data Hemorrhages in the Health-Care Sector, Center for Digital Strategies, Tuck School of Business, Dartmouth College, Hanover NH 03755)(available at http://mba.tuck.dartmouth.edu/digital/Research/ResearchProjects/JohnsonHemorrhagesFC09Proceedingd.pdf)(see also http://www.wired.com/threatlevel/2009/03/p2p-networks-le/).

On March 5, 2010, a research paper entitled The Inadvertent Disclosure of Personal Health Information Through Peer-To-Peer File Sharing Programs confirmed the Dartmouth Study.  This study found that:

Approximately 0.4% of Canadian IP addresses had PHI, as did 0.5% of US IP addresses. There was more disclosure of financial information, at 1.7% of Canadian IP addresses and 4.7% of US IP addresses. An analysis of search terms used in these file sharing networks showed that a small percentage of the terms would return PHI and PFI files (ie, there are people successfully searching for PFI and PHI on the peer-to-peer file sharing networks).

(See J Am Med Inform Assoc 2010;17:148e158. doi:10.1136/jamia.2009.000232)(article available at http://jamia.bmj.com/content/17/2/148.short).  Additional examples and case studies of various types of disclosures are available within a web only appendix available at http://jamia.bmj.com/content/17/2/148/suppl/DC1.

Legislators have proposed at least one Bill HR 1319 (December 9, 2009) to limit the undisclosed sharing of files without a user’s consent. (HR 1319 is entitled “AN ACT To prevent the inadvertent disclosure of information on a computer through certain ‘‘peer-to-peer’’ file sharing programs without first providing notice and obtaining consent from an owner or authorized user of the computer” and is available at http://www.govtrack.us/congress/bill.xpd?bill=h111-1319).  With the prospect of legislation requiring P2P software vendors to educate users, control network content, and require other family friendly features – steps are being taken by mainstream P2P file sharing companies to inform users how to properly configure their software.  In addition, some companies have re-designed their products with default configurations that may in some circumstances share less information of a sensitive nature.  (See http://www.limewire.com/legal/safety).

The FTC has been proactive about informing consumers and companies of the risks of P2P file-sharing to their personal information.  In late February (2010) the FTC sent out warning letters to more than 100 companies highlighting concerns about personal information of consumers and/or employees being found on file-sharing networks. The FTC requested that aforementioned companies review internal security procedures and the security procedures of their third party service providers and/or business associates.  The FTC also requested that companies identify affected individuals and assess whether to notify them of the possible risks to their personal information pursuant to applicable state and federal data security breach notification laws (See Widespread Data Breaches Uncovered by FTC Probe FTC Warns of Improper Release of Sensitive Consumer Data on P2P File-Sharing Networks, FTC Press Release dated February 22^nd, 2010, available at http://www.ftc.gov/opa/2010/02/p2palert.shtm).

The FTC also opened non-public investigations of other companies whose customer or employee information has been exposed on P2P networks.  Significantly, the failure to prevent sensitive information from being shared on P2P networks potentially violates the Gramm-Leach-Bliley Act (which includes provisions to protect consumers’ personal financial information held by financial institutions) and/or Section 5 of the FTC Act.  Section 5 of the FTC Act prohibits “unfair methods of competition,” and was amended in 1938 to prohibit “unfair or deceptive acts or practices”.  Recent enforcement actions by the FTC relating to privacy and data security are available at www.ftc.gov/privacy/privacyinitiatives/ promises_enf.html.

The FTC recommends that Companies:

• Delete sensitive information you don’t need, and restrict where files with sensitive information can be saved;
• Minimize or eliminate the use of P2P file sharing programs on computers used to store or access sensitive information;
• Use appropriate file-naming conventions;
• Monitor your network to detect unapproved P2P file sharing programs;
• Block traffic associated with unapproved P2P file sharing programs at the network perimeter or network firewalls; and
• Train employees and others who access your network about the security risks inherent.

(See P2P FIlesharing , available at http://www.ftc.gov/bcp/edu/pubs/business/idtheft/bus64.pdf ; see also Protecting PERSONAL INFORMATION FEDERAL TRADE COMMISSION A Guide for Business, available at http://www.ftc.gov/bcp/edu/pubs/business/idtheft/bus69.pdf.)

Note, the FTC publication entitled Protecting PERSONAL INFORMATION FEDERAL TRADE COMMISSION A Guide for Business is well written and is available for republication.

To secure the personal information stored on one’s computer, the FTC recommends:

• Avoid Changes to Default Settings.  Any changes you make to the P2P software’s default settings during installation could put data at risk.  One could inadvertently share information on their hard drive: like your tax returns, email messages, medical records, photos, or other personal documents;

• System Maintenance. Some file-sharing programs may install malware that monitors a user’s computer use and then sends that data to third parties;

• Close your connection. In many instances, closing the file-sharing program window does not actually close your connection to the network. That allows file-sharing to continue and could increase your security risk; and

• Avoid Using an Administrator Account to run P2P Software. Administrator accounts permit installation of software.  Avoiding the use of an account that would permit the installation of software can help protect against malware.

(See P2P File-Sharing: Evaluate the Risks)

An example of a P2P file sharing policy is available at http://www.k-state.edu/policies/ppm/3490.html.

Related Links

http://www.ftc.gov/infosecurity

http://www.OnGuardOnline.gov

http://www.sans.org/top20

http://www.us-cert.gov

Comparison of Feature of Populat P2P Clients

Not all distributed file sharing protocols are necessarily bad, for example Bittorent, another popular file sharing protocol, is invaluable in distributing large files.  The installation disks for the open source operating system Linux may be as large as 4 gigabytes multiple users downloading this large file could limit the bandwidth of a major university without protocols like Bittorent.  This protocol makes many small data requests over different TCP connections to different machines, while classic downloading is made via a single TCP connection to a single machine.  Many P2P file sharing software packages use a simple http connection for downloading data from a host computer once a host is located with the user’s desired content.  Unlike other P2P software, someone must “seed” a Bittorent download with a small file called a “torrent” that is used as a pointer for the file but the host of the torrent does not serve as the primary source of the data being downloaded by the end user.

[ii] (See http://www.nessus.org/whitepapers/reliability_and_uniqueness_of_nessus.pdf.)

[iii] (See http://www.washingtonpost.com/wp-dyn/content/article/2009/07/29/AR2009072902273_pf.html; http://voices.washingtonpost.com/securityfix/2009/07/report_locations_of_all_us_nuc.html; http://www.computerworld.com/s/article/9136053/Details_on_presidential_motorcades_safe_house_for_First_Family_leak_via_P2P?taxonomyId=17; http://www.smh.com.au/technology/technology-news/topsecret-obama-safe-house-leaked-on-limewire-20090730-e267.html; http://www.nextgov.com/nextgov/ng_20090729_2566.php?oref=topnews; http://www.nextgov.com/nextgov/ng_20090729_3555.php?oref=topnews; http://www.reuters.com/article/technologyNews/idUSTRE56S4T420090729; http://www.internetnews.com/government/article.php/3832556/Data+of+Soldiers+Hospital+Patients+Found+on+P2P.htm.)

Related Blogs

• Legal Information Institute: Sunlight Foundation Proposes Public …
• Wow! Construction Complete! C-SPAN Puts Complete Archive (23 years …
• Privacy Lives » Blog Archive » Federal News Radio: FTC looks at …
• File-Sharing and Link Sites Declared Legal in Spain | TorrentFreak
• Unfinished business « Though Cowards Flinch

          

P2P Leaks of Protected Health Information –HIPAA Covered Entities and Business Associates Should Have a P2P Software Policy Either Prohibiting the Use of P2P Software or Instructing Users on the Safe Use of P2P Software. originally appeared on Law Blog 2.0 on March 16, 2010.

HHS

On December 1st, 2009 the Office of the Secretary of the Office of the National Coordinator (ONC) for Health Information Technology announced the creation of a new Chief Privacy Office and the Office of Economic Modeling and Analysis (among three others including the Office of Chief Scientist, Deputy National Coordinator for Programs & Policy, and Deputy National Coordinator for Operations).  The New Chief Privacy Officer is a necessary creation under the ARRA (and the HITECH Act).  This role is different from the other positions that seem to be a re-organization of roles and responsibilities that already existed to some extent just with more specificity around functions and duties.  Aside from the Chief Privacy Officer the New Economic Modeling and Analysis Position seems like a timely creation given recent articles discussing whether Health Information Technology and more specifically Electronic Health Record Systems (EHRs) actually reduce the cost of care and/or increase the quality of care.  Also of note, the new Office of the Deputy National Coordinator for Programs and Policy will be responsible for the open source Connect initiative and the National Health Information Network.

 (see http://healthit.hhs.gov/portal/server.ptopen=512&objID=1200&&PageID=15520&mode=2&in_hi_userid=10741&cached=true)

Below is a diagram detailing the new offices relative to the National Coordinator.

The Notice in the Federal Register note that the reorganization affects all four of the original Director-level offices:

• The Office of Health Information Technology Adoption (OHITA);
• The  Office of Interoperability and Standards (OIS);
• Office of Programs and  Coordination (OPC); and
• The Office of Policy and Research (OPR).

Five offices will have direct reporting capability to the National Coordinator for Health Information Technology (National Coordinator):

1. The Office of Economic Modeling and  Analysis (ARB);
2. the Office of the Chief Scientist (ARC);
3. The Office of the Deputy National Coordinator for Programs & Policy (ARD);
4. The Office of the Deputy National Coordinator for Operations (ARE); and
5. The Office of the Chief Privacy Officer (ARF).

(see http://edocket.access.gpo.gov/2009/E9-28755.htm).

The Office of the Chief Privacy Officer will advise the National Coordinator.  Chief Privacy Officer of the Office of the National Coordinator for Health Information Technology will be appointed by the Secretary.  The Office of the Chief Privacy Officer duties include:

1. Advising the National Coordinator on privacy, security, and data stewardship of electronic health information; and
2. Coordinating the Office of the National Coordinator for Health Information Technology’s efforts with similar privacy officers in other Federal agencies, State and regional agencies, and foreign countries with regard to the privacy, security, and data stewardship of electronic, individually identifiable health information.

The Office of Economic Modeling and Analysis responsibilities include:

1. Applying advanced mathematical or quantitative modeling to the U.S. health care system for simulating the microeconomic and macroeconomic effects of investing in health information technology; and
2. Providing advanced policy analysis of health information technology strategies and policies to the National Coordinator.

The purpose this position will be to model varying public policy scenarios to perform advanced health care policy analysis for requirements of the Recovery Act, such as reductions in health care costs resulting from adoption and use of health information technology.  The results of these analyses provided to the National Coordinator will inform strategies to enhance the use of health information technology in improving the quality and efficiency of health care and improving public health.

The Office of the Chief Scientist will be responsible for:

1. Applying research methodologies to perform evaluation studies of health information technology grant programs;
2. Identifying, tracking and supporting innovations in health information technology;
3. Leading research activities mandated under the HITECH Act provisions of ARRA;
4. Promoting applications of health information technology that support basic and clinical research;
5. Collecting and communicating knowledge of health care informatics from and to international audiences;
6. Collaborating with other agencies and departments on assessments of new health information technology programs; and
7. Developing and maintaining educational programs for staff of the Office of the National Coordinator and advising the National Coordinator concerning the educational needs of the field of HIT.

The Office of the Chief Scientist possesses and utilizes specialized knowledge of medical bioinformatics, which involves the study and application of advanced information methods and technologies in support of health care and population health.

The Office of the Deputy National Coordinator for Programs and Policy assumes functions previously performed by the Office of Health Information Technology Adoption, the Office of Interoperability and Standards, the Office of Adoption Provider Support, the Office of State and Community Programs, and the Office of Policy and Planning.  The new office will lead ONC programs related to health information exchange, regional extension centers, training of the health IT workforce, and the development of technical standards for interoperability, security, and certification of health IT systems.  The new office comprises:

1. The Office of Standards and Interoperability, with responsibility for standards, security, certification, the Nationwide Health Information Network, Federal Health Architecture and the CONNECT program;
2. The Office of Provider Adoption Support, which administers the Regional Extension Centers program and health IT workforce development;
3. The Office of State and Community Programs, which administers the state-level health information exchange program and the Beacon Communities Program; and
4. The Office of Policy and Planning, which is realigned to include all policy development, including privacy and security policy, and is liaison with legal affairs and legislative affairs, regulations development  and externally focused strategic planning.

The Office of the Deputy National Coordinator for Operations is responsible for activities that are vital to supporting ONC’s numerous programs and enhancing ONC’s ability to communication about health IT.

          

Office of the National Coordinator — Time to Reorganize. originally appeared on Law Blog 2.0 on December 10, 2009.

HHS

On October 7, 2009 HHS announced proposed rulemaking to modify the HIPAA privacy rule to comply with Section 105, Title I of the Genetic Information Nondiscrimination Act of 2008 (GINA)  regarding the privacy and confidentiality of genetic information.  The prosed rule is found here HIPAAPRIVACYRULE13343.0.E9-22492. The HIPAA Privacy Rule establishes national standards to protect individuals’ medical records and other personal health information and applies to health plans, health care clearinghouses, and those health care providers that conduct certain health care transactions electronically.  Similarly Congress by enacting GINA seeks to protect the genetic privacy of individuals — GINA creates ‘‘a national and uniform basic standard [that] is necessary to fully protect the public from discrimination and allay their concerns about the potential for discrimination, thereby allowing individuals to take advantage of genetic testing, technologies, research, and new therapies.’’ (GINA section 2(5).)

The HIPAA Privacy Rule requires a covered entity (and beginning next year Business Associates) to implement reasonable and appropriate administrative, technical and physical safeguards to protect the privacy of personal health information (PHI).  The HIPAA privacy rule more generally sets limits and conditions on the uses and disclosures that may be made of such information without patient authorization. The Rule also gives patients rights over their health information, including rights to examine and obtain a copy of their health records, and to request corrections.  The Department of Health and Human Services (HHS) proposed to modify provisions of the ‘‘Standards for Privacy of Individually Identifiable Health Information’’ (Privacy Rule), issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA).  The purpose of these proposed modifications is to implement Section 105 of Title I of the Genetic Information Nondiscrimination Act of 2008 (GINA) regarding the privacy and confidentiality of genetic information, as well as to make other less technical changes to the HIPAA Privacy Rule.

GINA specifically prohibits discrimination based on an individual’s genetic information with respect to both health coverage and employment.  It is improper to use an individuals genetic information as basis for determining –

1. health coverage,
2. group premiums,
3. eligibility for insurance,
4. eligibility for employment, and/or
5. premiums for individuals and Medicare insurance policy markets.

HHS proposes to modify the HIPAA Privacy Rule to:

(1)    Explicitly provide that genetic information is health information for purposes of the Rule;
(2)    prohibit health plans from using or disclosing protected health information that is genetic information for underwriting purposes;
(3)    revise the provisions relating to the Notice of Privacy Practices for health plans that perform underwriting;;
(4)    make a number of conforming modifications to definitions and other provisions of the Rule; and
(5)    make technical corrections to update the definition of ‘‘health plan.’

In addition Section 105 of the Genetic Information Nondiscrimination Act of 2008 (“GINA”) provides that a group health plan or health insurer may not use or disclose genetic information for purposes of underwriting. These provisions became effective on May 20, 2009.   On October 7, 2009, the Department of Health and Human Services (“HHS”) issued proposed regulations on how Section 105 will impact the HIPAA privacy regulations and HIPAA covered entities.  Additional regulations issued on October 7, 2009 interpreting other health plan aspects of will be discussed in a subsequent client Alert. ’

The proposed regulations would extend GINA’s prohibition on using and disclosing genetic information for underwriting purposes to all health plans that are subject to the HIPAA privacy regulation. T he prohibition would extended long-term care policies, certain public benefit programs, such as Medicare and Medicaid, military health care programs, and limited scope dental and vision benefits so that all provisions would apply uniformly to all health plans covered by the HIPAA privacy regulation.

Comments on the proposed rule will be considered if receive no later than December 7, 2009.  We recommend that a company documents should also be updated to reflect the new GINA provisions, including the health plan’s policies and procedures. Depending on the services that are provided by a business associate and the language of existing business associate agreements, applicable business associate agreements may also need to be updated. Finally health plan sponsors may also consider whether adding protective language in their health plan documents is also appropriate.

          

HHS Announces Proposed Rulemaking to modify the HIPAA privacy Rule to Comply with Section 105 of Title I of the Genetic Information Nondiscrimination Act of 2008 (GINA) originally appeared on Law Blog 2.0 on October 15, 2009.

HHS Security Breach Notice Regulations - Update

A series of privacy advocates have expressed displeasure with the HHS “harm standard” as articulated in the recent Covered Entity .  However, I believe the “harm standard” is reasonable and appropriate.  One recent article is available here (published by computer world): HHS guts health-care breach notification law, groups warn Posted using ShareThis

I am a little unclear as to why privacy advocates and security vendors believe that the harm standard, found within the new HHS regulations for security breaches, in any way hampers the HITECH Act’s security breach notice rule for covered entities and business associates.  Many states use a similar risk based type analysis, in fact only seven states have a strict acquisition based standard, of those only a couple of these states link their definition of encryption to FIPS 140-2.*  In comparison to risk based states where one assesses the potential risk to a consumer resulting from theft of sensitive information, the federal standard is more helpful in the sense that it highlights key criteria to be evaluated in assessing risk to consumers.

*I am not certain on this, but I believe the most problematic state is California.  California includes health information within the definition of personal information, California references FIPS 140-2, California is an acquisition based state, and guidance documents issued by the state are extremely draconian.

Second, implementing a FIPS 140-2 approved encryption system is an expensive and complicated process — it seems reasonable that HHS should temper FIPS 140-2 with a harm standard analysis.  As many covered entities have started to dissect the requirements of what would constitute acceptably encrypted data under the HITECH act they have quickly realized that process of implementing what is largely a FISMA (Federal Government/ Military) based encryption standard presents many problems.  FIPS approved algorithms and processes require precise configuration; such systems are designed to fail closed.  Failing closed means denying access — this could be a good thing with money but a bad thing when dealing with clinical data in an emergency situation.  Security controls in the health care industry are a delicate balance of confidentiality, integrity and availability. (http://law2point0.com/wordpress/2009/09/15/50-state-security-breach-notice-law/).  Pushing out government grade security safeguards too fast could create serious issues in the event a provider needs immediate access to patient records but hospital A cannot communicate with hospital B due to a conflicting encryption schema.

Without the harm standard, covered entities would be forced into over-reporting incidents — over-reporting can be just as damaging as not reporting any security incidents.  There are two studies that help to put the “harm” or risk-based standard for security breach reporting in an appropriate (real-world) context.
The first study is a report prepared by the General Accounting Office (GAO) from 2007 entitled PERSONAL INFORMATION — Data Breaches Are Frequent, but Evidence of Resulting Identity Theft Is Limited; However, the Full Extent Is Unknown (the report is available for free at http://www.gao.gov/new.items/d07737.pdf).  This report evaluated the 24 largest breaches reported in the media from January 2000 through June 2005.  The study found that:

1. In only three instances was there evidence of fraud on existing accounts and in only one instance of the three identified cases did the GAO find evidence of unauthorized creation of a new account;
2. For 18 of the breaches, no clear evidence was uncovered linking the breach to identity theft; and
3. In the remaining two cases there was insufficient information to make a determination.

A second article, by S. Romanosky, R. Telang, and A. Acquisti, entitled Do Data Breach Disclosure Laws Reduce Identity Theft? (available for free at  http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1268926) summarizes the debate surrounding security breach notification laws and their impact.  The authors’ analyses reveal a modest effect of security breach disclosure laws in reducing identity theft rates by approximately 2%.  However, this article also notes that over-reporting has many negative consequences — including unnecessary costs and desensitizing consumers such that when a real incident that they should take notice of is ignored.

The FIPS-140-2 standard is a Federal Standard and the guidance cited by HHS (OMB Memorandum M-07-16 is also a federal standard (available at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf)).  The OMB the guidance and the FIPS 140-2 are both compoennts of the federal government program to protect against harm resulting from a security breach.  It seems logical if that we are following a FISMA structure that OMB Memorandum M-07-16 should be considered when assessing the scope and consequences of a security breach.

The harm standard may result in fewer notices, in some states where there are exceptions for HIPAA covered entities for some provisions of state reporting requirements, but absent an applicable exception an entity could still be bound by the state standard and the federal standard.  Many states are including health information within the definition of personal information; even so it is frequently the case that when health information is compromised the triggering elements for a given state’s reporting statute are present within the compromised health data.  Unfortunately, the end result will likely be a negligible  reduction in notice unless the seven states and the DC that have an acquisition based standard move to a risk based / harm based analysis.  In my opinion an acquisition based standard reaches the wrong result for both consumers and companies.  The one benefit will be that the Federal standard does provide a rational framework for entities absent other guidance that can be used to frame analysis of a security incident and what mitigation efforts are appropriate.

          

Fear Mongering or Legitimate Criticism — “HHS guts health-care breach notification law, groups warn” originally appeared on Law Blog 2.0 on September 22, 2009.

Security Breach

Ms. Kristen Pollock McDonald’s Professional CV, the author of this article, is available here, the website for American Health Lawyers Association is available here. What happens if the offices of a covered entity are broken into and unsecured protected health information (PHI) of more than 500 individuals is stolen? With the enactment of the Health Information Technology for Economic and Clinical Health (HITECH) Act,¹ the ramifications to the covered entity and potential liability stemming from such a breach² are significant to say the least. Not only is the covered entity required to notify the affected individuals of the breach of unsecured PHI,³ but also the covered entity must notify the media and the Department of Health and Human Services Secretary (HHS Secretary) of potentially damaging information concerning the breach. The HITECH Act’s requirement to report details of a significant breach not only to the affected individuals but also to the media and the Secretary may negatively impact the covered entity’s goodwill in the community and cause a loss of business. Of particular concern to the covered entity’s litigation counsel, though, is the potential liability that the covered entity may face due to the breach.

Under the HITECH Act, a covered entity is required to notify individuals of a breach of unsecured PHI and provide the affected individuals with the following information: (1) a description of what happened; (2) a description of the type of unsecured PHI that was involved in the breach; (3) steps the individuals should take to protect themselves; (4) a description of what the covered entity is doing to investigate the breach, mitigate harm to the individual, and ensure that a similar breach does not occur; and (5) contact information if the individual has questions.⁴ Having to detail the nature of the breach, the type of PHI compromised, and what steps the covered entity has taken to mitigate any harm places the covered entity in a precarious position because disclosing such information may be deemed an admission against the covered entity in future litigation brought by affected individuals.

Indeed, the affected individuals may rely upon the notification and the potential admissions contained therein to bring suit against the covered entity under federal or state law. Thus, even though the covered entity abides by the notification rules under the HITECH Act, the fact that there was a breach of unsecured PHI may cause the covered entity to face various liability risks. For example, the breach by the covered entity may violate state patient privacy laws. Or, the covered entity may face liability under various federal statutes, such as the Public Health Services Act if substance abuse treatment records are compromised.⁵ Other examples include the improper disclosure of a diagnosis of a disease, which may cause the covered entity to face liability for intentional or negligent infliction of emotional distress, among other theories. Or, if Social Security numbers are compromised, the covered entity may face liability for financial losses associated with identity theft.⁶ Because the covered entity may face a variety of liability risks under federal and/or state law, the risk of the notification under the HITECH Act being treated as an admission against the covered entity could have far-reaching, negative consequences in litigation.

Also increasing the risk of potential liability is the fact that the same information contained in the notification to the affected individuals also must be provided to the media.⁷ Thus, not only will the general public have access to the details of the breach but competitors will have access to the more damaging information concerning how the breach occurred and what information was compromised. Although publication in the media will not provide the affected individuals with any additional information, it could increase the risk of litigation: (1) by encouraging affected individuals, who may not have otherwise acted upon their personal notification, to pursue litigation against the covered entity; and (2) by educating plaintiffs’ counsels about the breach and who then may seek out the affected individuals for representation.

Although the HITECH Act’s breach notification rules are not yet effective,⁸ what is quite apparent even now is that the breach notification rules will almost certainly foster litigation, particularly for significant breaches affecting more than 500 individuals.

¹ The HITECH Act was enacted on February 17, 2009, as part of the American Recovery and Reinvestment Act of 2009. See Pub. L. No. 111-5 (2009). Most recently, on August 24, 2009, the Department of Health and Human Services (HHS) published regulations further explaining the breach notification rules under the HITECH Act. See Breach Notification for Unsecured Protected Health Information; Interim Final Rule,
74 Fed. Reg. 42740 (Aug. 24, 2009).
² A “breach” is defined as “the unauthorized acquisition, access, use, or disclosure of protected health information which compromises the security or privacy of such information.” Id. at 42741.
³ Unsecured PHI is defined as “protected health information that is not secured through the use of a technology or methodology specified by the Secretary in guidance . . .” Id. The two specific methodologies listed in HHS guidance are encryption and destruction. Id.
⁴ See 74 Fed. Reg. at 42750.
⁵ See Public Health Services Act, set forth at 42 U.S.C. §§ 290dd. HHS’ guidance specifically contemplates potential liability depending upon the type of unsecured PHI compromised. See 74 Fed. Reg. at 42745.
⁶ See id.
⁷ See id. at 42752. In addition to requiring the covered entity to notify the media of a breach affecting more than 500 individuals, the HITECH Act also requires the covered entity to notify the Secretary immediately of the breach. Id. at 42753. The Secretary, in turn, lists on its website all covered entities that report breaches affecting more than 500 individuals. Id.
⁸ The Interim Final Rule becomes effective on September 23, 2009. Id. at 42740, 42753.

          

Excellent Article from American Health Lawyers Association’s Healthcare Liability & Litigation Health Briefs, on 9/9/09. by Kristen McDonald. (Republished with permission from the author.) originally appeared on Law Blog 2.0 on September 15, 2009.

De-identification of Data

Social networking sites, efficient search tools (bing, dogpile, google, yahoo), blogs, cookies, mailing lists, message boards, active x controls/ embedded java script on websites and other databases make it easy to identify that new business prospect or easily cross-reference materials from multiple sources to yield unique insights into a matter of interest.  However, these online repositories of data are making it much more difficult to maintain the anonymity of those whose confidential information has been de-identified.  De-identified data has many useful purposes; the data can be used in its aggregate for tracking disease, flu outbreaks, tax purposes, etc..  There is a darker use of these many data sources, where those in our society that are ethically challenged use these data sources for socially unproductive purposes.  For example cyber-stalking and cyber-harassment are now serious problems for both companies and individuals – if you ever tried to stop such individuals you will note the absence of a well developed corpus of law in these areas.

De-identified Information is information that does not allow an individual to be identified because specified identifiers have been removed.  Scientists have demonstrated they can often “reidentify” or “de-anonymize” individuals hidden in anonymized data. See Ohm, Paul, Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization (August 13, 2009). University of Colorado Law Legal Studies Research Paper No. 09-12. Available at SSRN: http://ssrn.com/abstract=1450006; see also Cassa, Christopher A; Wieland, Shannon C; and Mandl, Kenneth D. Re-identification of home addresses from spatial locations anonymized by Gaussian skew, International Journal of Health Geographics (August 2008) (available at http://www.ij-healthgeographics.com/content/pdf/1476-072X-7-45.pdf)( finding that multiple de-identified versions of the same data set, each anonymized using a method known as nondeterministic Gaussian skew, can be used to ascertain original geographic locations).

The fundamental flaw with anonymizing data methodologies relates to an adversary being able to find a unique data fingerprint (e.g. date of birth, zip code, and gender), and link that data to auxiliary information or outside information.  A potential adversary can use resources such as the web (Google), public records, blogs, social networks, Facebook, etc; the issue is particularly troublesome when multiple organizations independently release anonymized data about the same or similar populations.  The ultimate balance comes in trying to de-identify data sufficient to withstand inspection by a potential adversary, while also remaining useful for public health, or other similar needs.

De-identification of health information on the one hand is essential, but also can be used to embarrass, extort, or otherwise annoy someone whose information has been disclosed.  With respect to Protected Health Information (PHI), the HIPAA Privacy Rule permits covered entities to release data that have been de-identified without obtaining an authorization and without further restrictions upon use or disclosure because de-identified data is not PHI and, therefore, not subject to the Privacy Rule.  Generally a covered entity can de-identify PHI in one of two ways.  The first way, the “safe-harbor” method, is to remove all 18 identifiers enumerated at section 164.514(b)(2) of the regulations.  Data that are stripped of these 18 identifiers are regarded as de-identified, unless the covered entity has actual knowledge that it would be possible to use the remaining information alone or in combination with other information to identify the subject.  However copious amounts of auxiliary information that is publically available on the Internet may render HIPAA safe-harbor protection impossible.  On the other hand the “actual knowledge” requirement may allow for data that could be readily re-identified by a hacker (super user) (i.e. associating a person with the medical or other confidential data), while the covered entity “reasonably” believes the data are de-identified.

The 18 identifiers are:

a)                  Names;

b)                  Geographic subdivisions smaller than a state;

c)                   All elements of dates (except year) related to an individual (including dates of admission, discharge, birth, death and, for individuals over 89 years old, the year of birth must not be used);

d)                  Telephone numbers;

e)                  FAX numbers;

f)                   Electronic mail addresses;

g)                  Social Security numbers;

h)                  Medical record numbers;

i)                    Health plan beneficiary numbers;

j)                    Account numbers;

k)                  Certificate/license numbers;

l)                    Vehicle identifiers and serial numbers including license plates;

m)                Device identifiers and serial numbers;

n)                  Web URLs;

o)                  Internet protocol addresses (IP);

p)                  Biometric identifiers (including finger and voice prints);

q)                  Full face photos and comparable images; and

r)                   Any unique identifying number, characteristic

The second method to de-identify data is to have a qualified statistician determine, using generally accepted statistical and scientific principles and methods, that the risk is very small that the information could be used, alone or in combination with other reasonably available information, be used to identify the subject of the information.  The qualified statistician must document the methods and results of the analysis that justify such a determination. (See 67 Fed, Reg. 53233 (August 14, 2002.))

As is typically the case — if some method is built into the system to allow for re-identification, then the covered entity may not (1) use or disclose the code or other means of record identification for any purposes other than as a re-identification code for the de-identified data, and (2) disclose its method of re-identifying the information.  In essence the method and key (the code) almost become an encryption method, but like with encryption when the key is compromised the data are compromised.

One study using 1990 census data showed that 87% (216 million of 248 million) of the United States population reported characteristics that made them uniquely identifiable using only three pieces of data:  5-digit ZIP, gender, date of birth.  Fifty-three percent of the U.S. population could be uniquely identified using only gender, location (city, town, or municipality), and date of birth.  At the county level approximately 18% of the U.S. population could be uniquely identified.  L. Sweeney. Uniqueness of Simple Demographics in the U.S. Population, LIDAP-WP4. Carnegie Mellon University, Laboratory for International Data Privacy, Pittsburgh, PA: 2000 (available at http://privacy.cs.cmu.edu/dataprivacy/papers/LIDAP-WP4abstract.html)

Interesting the older the population the easier (the more likely) an individual can be uniquely identified.  Accordingly greater care must be taken with the medical data of elderly populations.  Philippe Golle, Revisiting the Uniqueness of Simple Demographics in the US Population (Palo Alto Research Center October 30, 2006)(available at http://www.truststc.org/wise/articles2009/articleM3.pdf).  Additional research has found that when multiple de-identified data sets are made from overlapping data sets re-identification of data becomes progressively easier.  Accordingly even where extremely large geographical areas are used to aggregate data for population studies this information may still be de-identified.

Unlike de-identified data, a limited data set is even easier to re-identify (albeit there are significant legal restrictions on the use of this information).  A limited data set is one that excludes the direct identifiers in 164.514(e)(2). Unlike a de-identified data set, a limited data set is PHI because it may include dates, city, state, and ZIP codes, and other unique identifying codes or characteristics not listed as direct identifiers.  A limited data set may be used or disclosed, without Authorization, for research, public health, or health care operations purposes, in accordance with section 164.512(e), only if the covered entity and limited data set recipient enter into a data use agreement. However, if the use or disclosure could be made under another provision of the Privacy Rule, such as for public health purposes in accordance with section 164.512(b), such agreement is not required.

“Value-added” de-identification that replaces personal health information with tags that retain temporal sequences and the georgraphic context simply may not work in a networked world.  Covered entities, business associates and others who aggregate and de-identify data sets may need to start limiting the downstream rights of licensees’ of de-identified data, and conduct some type of quality assurance proccess of their de-identification techniques.  What works today to de-identify data may not work in a year however your data will likely still be available somewhere on the Internet.  However, simply removing all personal health information may negate the value of the data.

Other Resources:

Federal Committee on Statistical Methodology, Office of Management and Budge, Statistical Policy Working Paper 22 (Revised 2005)- Report on Statistical Disclosure Limitation Methodology (available at http://www.fcsm.gov/working-papers/SPWP22_rev.pdf).

The New York Times reported in article entitled When 2+2 Equals a Privacy Question “Some healthcare concerns say they have been able to offer study data to researchers stripped of specific personal details like your name, phone number, and email address,” but “in some cases researchers may be able to re-identify you by correlating anonymous information with the digital trail that you’ve left on blogs, chat rooms and Twitter.” (see http://www.nytimes.com/2009/10/18/business/18stream.html)

Related Blogs

• Green-ing the World’s Data: A Q&A With IBM’s VP of Energy and Environment » INFRASTRUCTURIST
• Balloon Juice » Blog Archive » C-Span Gold
• systemic » Inside Information
• C-SPAN Launches Free Searchable Online Video Library | Blogza.in.th
• Fresh Code – Barcode For Freshness Indication by Sisi Yuan, Yiwu Qiu, Lei Zhao, Qiulei Huang, Lijun Zhang & Weihang Shu » Yanko Design

          

Is Truly De-identified Data an Impossibility? originally appeared on Law Blog 2.0 on September 11, 2009.

a.    Take immediate action to stop the incident from continuing or recurring.

b.    If the incident does not involve the loss of confidential information or have other serious impacts to individuals IT should repair the system, restore service, and preserve evidence of the incident.

c.    If the incident involves the loss of confidential information or critical data or has other potentially serious impacts, you should consult with your general counsel or your legal counsel for guidance under applicable federal and state laws.

e.    File a Security Incident Report including a description of the incident and documenting any actions taken thus far.

f.     Refrain from discussing the incident with others until a response plan has been formulated.

g.    Repair the system and restore service.

h.    Preserve evidence of the incident.

Did a reportable security breach occur?

Some factors to consider when evaluating a potential security breach.

When determining whether or not acquisition has actually or is reasonably believed to have occurred, on should consider, at a minimum, the following indicators:

1. The information is in the physical possession and control of an unauthorized person, such as a lost or stolen computer or other devices that have the capability of containing information, or such as a misdirected electronic mail transmission received and opened by an unauthorized person containing notice-triggering information.
2. The information has been downloaded or copied (e.g., any evidence that download or copy activity has occurred which may require forensic analysis);
3. The attacker deleted security logs or otherwise “covered their tracks”;
4. The duration of exposure in relation to maintenance of system logs or in cases of an inadvertent or unauthorized Web site posting;
5. The attack vector is known for seeking and collecting personal information;
6. The information was used by an unauthorized person, such as instances of identity theft reported or fraudulent accounts opened.

Appropriate Incident Handling Procedures Are Key.

DOs

1. Immediately isolate the affected system to prevent further intrusion, release of data, damage, etc.
2. Use the telephone to communicate. Attackers may be capable of monitoring email traffic.
3. Immediately notify your security incident response team.
4. Activate all auditing software, if not already activated.
5. Preserve all pertinent system logs, e.g., firewall, router, and intrusion detection system.
6. Make backup copies of damaged or altered files, and keep these backups in a secure location.
7. Identify where the affected system resides within the network topology.
8. Identify all systems and agencies that connect to the affected system.
9. Identify the programs and processes that operate on the affected system(s), the impact of the disruption, and the maximum allowable outage time.
10. In the event the affected system is collected as evidence, make arrangements to provide for the continuity of services, i.e., prepare redundant system and obtain data back-ups. To assist with your operational recovery of the affected system(s), pre-identify the associated IP address, MAC address, Switch Port location, ports and services required, physical location of system(s), the OS, OS version, patch history, safe shut down process, and system administrator or backup.

DON’Ts

1. Delete, move, or alter files on the affected systems.
2. Contact the suspected perpetrator.
3. Conduct a forensic analysis.

Other Considerations

1. Collect information for each server, router, switch, and Data Service Unit (DSU) including:
   • IP address
   • Media Access Control (MAC) address
   • Switch Port location (switch name and port number)
   • Port assignment
   • Ports and services are required
   • Statement that all other unneeded ports and services are closed and/or removed
   • Responsible system administrator and backup
   • Physical location of server
   • Physical security implemented
   • Emergency contact information (both technical and user management)
   • OS/Version/Patch history
   • Systems supported, impact of outage, and maximum allowable outage (MAO)
   • Shutdown script (if applicable)
   • Recovery process
2. Identify all external connections, assess the need for the connections, the security risk to each connection, and any recommended safeguards or strategies.
3. Provided an adequate security message and warning banner on your system.
4. Implement a keystroke monitoring program.
5. Does personal information reside on, or is it transmitted through the affected system (as defined by federal and/or state security breach notification statutes)?

Steps to Minimize Potential Liability

1. Review physical and electronic access by employees and investigate abnormal activity in ALL computing environments.
2. Review system administrators, field accounts, and special access rights for appropriate access levels.
3. Ensure that systems are always backed up and the data is securely placed in an offsite location. Periodically conduct data restore tests.
4. Ensure that current anti-virus protection software and upgrades are installed, operational, and monitored. In addition, schedule routine virus scans on servers and desktops.
5. Remove sensitive information from websites.
6. Limit the size and manage the type of email attachments that can be received (certain systems allow you to disable executable files).
7. Keep the IT Operational Recovery Plan (ORP) and Business Continuity Plan (BCP) up-to-date, tested, and ready for implementation.
8. Establish security accountability for any and all users at appropriate levels.
9. Improve security on access to critical assets and facilities with technology environments.
10. Remove unnecessary services on routers, ports, servers, and network devices.
11. Trace or monitor the necessary services.
12. Designate an Information Security Officer (ISO) who shall report to the Director of the department or designee. The ISO shall not report to the Chief Information Officer (CIO).
13. Continuously educate management on the priority of security and the security risks associated with Information Technology.
14. Install warning banners at the login process for access to all state systems and applications.
15. Increase user awareness in security by continuously enhancing technology use policy such as “non-personal use of email.”
16. Verify that software updates and patches are continuously installed on a timely basis to operating systems and applications. Be wary of standard software installations. These installations often include services or features which you do not use and do not update.
17. Ensure that current anti-virus protection software and upgrades are installed, operational, and monitored.
18. Improve or remove user accounts with weak passwords, default or built-in passwords, old passwords, or no passwords. All accounts must have passwords and passwords should be complex and difficult to guess.
19. Require use of passwords containing alpha-numeric-special character combinations. Passwords should expire after a set period of time and employ a password history to prevent repeated passwords.
20. Ask if you have a policy which cancels log-ins/passwords when employees leave your organization. If so, verify that the policy is enforced.
21. Implement intrusion detection, provide monitoring on critical information systems, such as maintaining system logs on write only CDs.
22. Restrict non-business use of e-mail.
23. Review your remote access procedures and policies. Who is granted access? How is it monitored? If virtual private network (VPN) access is provided, have minimum security standards been established for the remote computer? How is this verified?
24. Enforce a policy regarding Internet use (viruses such as Trojan Horses can be introduced by visiting websites).
25. Restrict use of chat room software, AOL Instant Messenger, IRC Chat, ICQ Chat, (viruses can be introduced by visiting chat rooms).
26. Maintain a firewall between your system and any untrusted system (Internet connection).

Recommended Resources

NIST Special Publication 800-61 (Rev. 1)(Mar 2008    ) Computer Security Incident Handling Guide (available at http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf).
NIST Special Publication 800-86(Aug 2006) Guide to Integrating Forensic Techniques into Incident Response (available at http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf).
NIST Special Publication 800-83(Nov 2005) Guide to Malware Incident Prevention and Handling (available at http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf).

          

Evaluating Secutiy Incidents — Security Incident DOs and DON’Ts originally appeared on Law Blog 2.0 on September 8, 2009.