Directs federal agencies participating to:

• Transmit to Congress a cybersecurity strategic research and development plan and triennial updates; and
• Develop and annually update an implementation roadmap for such plan. Provides for the award of computer and network security research grants by the National Science Foundation (NSF) in the research areas of social and behavioral factors, including human-computer interactions, and identity management.

Instructs that applications for the establishment of Computer and Network Security Research Centers include how such Centers will partner with government laboratories, for-profit entities, other institutions of higher education, or nonprofit research institutions.

Requires the NSF Director to carry out a program of awarding fellowships to encourage young scientists and engineers to conduct postdoctoral research in the fields of cybersecurity and information assurance, including the research areas under which computer and network security research grants are awarded.

Requires the Office of Science and Technology Policy (OSTP) Director to convene a cybersecurity university-industry task force to explore mechanisms for carrying out collaborative R&D activities. Requires (currently, permits) the National Institute of Standards and Technology (NIST) Director to establish priorities for the development of checklists of settings and options that minimize security risks associated with computer systems that are, or are likely to become, widely used within the federal government.

Requires:

• Development or identification and revision or adaptation as necessary, of checklists, configuration profiles, and deployment recommendations for products and protocols that minimize such risks; and
• Development of automated security specifications respecting checklist content and associated security related data.  Ensures that any products developed under the National Checklist Program for any information systems, including the Security Content Automation Protocol, be disseminated to federal agencies Requires conducting of intramural security research activities under NIST’s computing standards program.

Instructs the NIST Director to:

• Ensure coordination of U.S. government representation in the international development of technical standards related to cybersecurity;
• Implement a cybersecurity awareness and education program through the Manufacturing Extension Partnership program; and
• Establish a program to support development of technical standards, metrology, testbeds, and conformance criteria with regard to identity management research and development.

(Summary excerpted from http://www.govtrack.us/congress/bill.xpd?bill=h111-4061).

Related Blogs

• Legal Information Institute: Sunlight Foundation Proposes Public …
• Information About Usual Swine Flu Symptoms | Pig Flu Pandemic …
• PHP Development India – maglev08.com
• elearnspace › Social Networks and Learning: Research/Doctoral Seminar
• Club Troppo » What a free computer might do for a kid's education …
• Book preview: PHP 5 E-commerce Development « Eirik Hoem's Blog
• Commtouch's New Open-Source Email Security Technology Featured at …
• Cybersecurity Technologies a Government Priority | The New New …
• Featured Job- Cyber Security Engineer with Booz Allen | The New …
• Stock Gumshoe Investigates: “$25 Cyber Security Doubler to Hit $50 …
• SEO Consult – Different content requires different styles of writing
• Programmers that… can't program. | Musings of an Anonymous Geek
• Nokia Research Centre Africa (NRC-Africa) research insights and …
• IP Osgoode » Building new models for innovation and R&D requires …
• The Alex Jones Show with Jason Bermas 1/3: Cybersecurity Act …
• UK Government Criticized For Frightening Climate Change Television …
• 50 Excellent Tutorials for Web Development Using CSS3 | Dzinepress
• Europe's economic recovery requires e-Skills
• Temporary Worker Program Could Threaten Immigration Reform …
• [Fix] Installation of Microsoft Office 2010 Requires MSXML Version …

          

Would you like to play a nice game of chess? originally appeared on Law Blog 2.0 on February 5, 2010.

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.

Health Information Exchange

A Health Information Exchange (HIE) is a network of healthcare information systems electronically connected across organizations within a region or a community using a common communication protocol for the transparent exchange of health information.  HIEs provide the capability to move clinical information among disparate health care information systems while maintaining the meaning and context of the data being exchanged.  The goal of an HIE is to facilitate access to and retrieval of clinical data to provide safer, more timely, efficient, effective, equitable, patient-centered care.  HIEs are also useful for public health authorities to assist in analysis of the health of a population.  Federal Health Architecture is intended to deliver free, scalable solution to help organizations to tie health information systems into the NHIN.  Thus far the project has yielded at least one success (outside of the federal government) where data have been successfully transferred between a civilian hospital and the VA.

In February 2009, the CONNECT software gateway was used for the first time in a limited production environment when the SSA began receiving live patient data from MedVirginia through the NHIN.  The agencies built CONNECT using open source components, made it available under an open source license in order to encourage innovation and ease the cost of adoption.

Key issues with testing and/or implementing CONNECT include:
•    Too many manual steps where human typing errors can occur (setting environmental variables incorrectly, typos, setting incorrect directories, etc);
•    Having to manually edit scripts and different files to update with IP address, add XML pieces, etc;
•    Once Gateway is set-up, no way to communicate to another Gateway unless you set-up another Gateway;
•    Log files are confusing; and
•    Need better out of box experience.

The license found at the Connect websites allows the user many rights (including the right to withhold developments done privately from the project as a whole).  Many open source libraries require the community to give back new features/ source code to the project.  Guidance and documentation on how to connect into the NHIN framework is available at http://www.connectopensource.org/display/NHINR21/Guidance+on+Joining+the+NHIN+Using+the+CONNECT+Gateway.  The interface schema for the Connect gateway is available at http://www.connectopensource.org/download/attachments/14450700/CONNECT_+Release_2_1_Integrated_Interface_Description_Document_070709.pdf?version=1.  Currently the software can be compiled and run in a MSFT Windows environment, however, organizations including the open source community and Red Hat are working on a *nix version what will allow the distribution of a VMware image for easy testing and review by organizations that are potentially interested in using the software for resolving internal communication issues in large health systems and also to connect to the NHIN.  The software is available for download at http://www.connectopensource.org/display/NHINR21/Release+2.1+Home.
The success of NHIN thus far was made possible by the Federal Health Architecture and open source software.  The Federal Health Architecture (“FHA”) is an E-Government Line business initiative.  The FHA made software, called CONNECT and supporting documentation available at www.connectopensource.org, available to help health information technology systems communicate to the Nationwide Health Information Network (NHIN), a federal initiative to facilitate the electronic exchange of health information.

The NHIN seeks to achieve these goals by:
•    Developing capabilities for standards-based, secure data exchange nationwide;
•    Improving the coordination of care information among hospitals, laboratories, physicians offices, pharmacies, and other providers;
•    Ensuring appropriate information is available at the time and place of care;
•    Ensuring that consumers’ health information is secure and confidential;
•    Giving consumers new capabilities for managing and controlling their personal health records as well as providing access to their health information from electronic health records (EHRs) and other sources; and
•    Reducing risks from medical errors and supporting the delivery of appropriate, evidence-based medical care.

The FHA is responsible for:
•    Leveraging federal expertise by creating a federal health information sharing environment;
•    Supporting federal efforts to develop and adopt health IT standards and services; and
•    Ensuring that federal agencies can seamlessly exchange health data among themselves, with state, local and tribal governments, and with private-sector healthcare organizations.

Organizations are now emerging at the community, state and federal level to detail/ create the necessary protocols that will allow health information exchange efforts to succeed.  These organizations (often called Regional Health Information Organizations, or RHIOs) are ordinarily geographically-defined entities which develop and manage a set of contractual conventions and terms, arrange for the means of electronic exchange of information, and develop and maintain HIE standards.  The NHIN is a commercial/government effort working to build an electronic infrastructure to allow data to move among different organizations and applications.

To promote a more effective marketplace, greater competition, and increased choice through accessibility to accurate information on healthcare costs, quality, and outcomes, the Office of the National Coordinator (ONC) is advancing the NHIN as a “network of networks” which will connect diverse entities that need to exchange health information, such as state and regional health information exchanges (HIEs), integrated delivery systems, health plans that provide care, personally controlled health records, Federal agencies, and other networks as well as the systems.

From the press release Federal Health Architecture Delivers Free, Scalable Solution Helping Organizations Tie Health IT Systems into the NHIN (dated April 2009)(http://www.connectopensource.org/display/Gateway/2009/04).

“The CONNECT software is the outcome of a 2008 decision by more than 20  federal agencies to connect their health IT systems to the NHIN.  Rather than  individually building software required to make this possible, the federal  agencies, through the Federal Health Architecture, created CONNECT. This shared  software solution can be used by each agency within its own environment. CONNECT  implements the core services defined by the NHIN including standards for  security to protect health information when it is exchanged with other trusted  health organizations.”

          

Open Source Programmers Collaborate To Improve the CONNECT Gateway originally appeared on Law Blog 2.0 on August 31, 2009.

Key differences under the California Act include: (i) the right of a party to request production in a specific format; (ii) a responding party bears the burden of proving that data are inaccessible; and (iii) an explicit right to inspect, copy, test, and or sample ESI in the possession or control of a third party.

Limits on ESI Discovery can be appropriate where: (i) the information can be produced from a less-burdensome source, (ii) the discovery sought is unreasonably cumulative or duplicative, or (ii) the burden of producing the ESI outweighs the benefit.

ESI that “is from a source that is not reasonably accessible because of undue burden or expense” shall not be produced, provided the responding party provides written responses identifying data classified as inaccessible and the responding party takes affirmative action to seek a protective order and bear the burden of demonstrating that the ESI is in accessible.  If it is established that the electronically stored information is from a source that is not reasonably accessible because of undue burden or expense, the court may nevertheless order discovery if the opposing party shows good cause.

A party that inadvertently produces ESI that is subject to a claim of privilege or attorney work product protection may seek the return of the ESI by notifying the receiving party.  Upon notice, the opposing party must sequester or return (and not use) the ESI until the claim of privilege is resolved.  The opposing party, where appropriate, may file a motion within 30 days to contest the producing party’s claim of privilege.

          

California Electronic Discovery Act Signed Into Law — Takes Effect Immediately originally appeared on Law Blog 2.0 on July 7, 2009.

Going to Court to force an ISP to disclose the identity of anonymous blogger raises many legal road blocks including issues of First Amendment rights. For example,

On June 13, 2007, the New Jersey Township of Manalapan filed a malpractice suit against its former attorney Stuart Moskovitz, alleging misconduct regarding the Township’s purchase of polluted land in 2005. The decision to file suit was met by a lively debate in the regional press and among local bloggers. One blogger who was particularly critical of the Township, of this and other decisions, was Blogspot blogger “datruthsquad”

(http://www.eff.org/cases/manalapan-v-moskovitz).

Long story short the Township lost, a copy of Electronic Freedom Foundation’s (“EFF”) motion squash is available here motiontoquashmpa-signed; and the Court order squashing the subpoena is available here order-122107.  However, there may exist an alternative method for “unmasking” anonymous bloggers, cyber-stalkers, etc. using public information.  Everyone has a unique writeprint (basically a written fingerprint that can be used to identify him or her).  This technique s has traditionally been used to identify the true author of a text (e.g. a book) where authorship is disputed or unknown. Forensics linguistics has been used to provide evidence in trademark disputes cases, identifying the author of anonymous texts (such as threat or harassment letters), and identifying cases of plagiarism. The identification process relies on the analysis of an individual’s particular patterns of language use (vocabulary, collocations, pronunciation, spelling, grammar, etc.). The term “idiolect” is defined as the speech patterns of a specific person (a dialect, unique in pronunciation, grammar, and vocabulary to a single person). Stylistic features can be used to create a fingerprint of an individual’s writing style (a linguistic fingerprint is called a “writeprint”). A writeprint is composed of features that represent an author’s writing style, which are consistent across all of an individual’s writings. For a gentle introduction, see Digital fingerprints: tiny behavioral differences can reveal your identity, by Julie Rehmeyer in the January 13, 2007 issue of Science News (Westlaw cite 2007 WLNR 2239738).

Email identification is a unique subset of authorship identification. When identifying authorship of anonymous emails, the following considerations have been noted:

• The identification of an author is usually attempted from a small set of known candidates; and

• Other evidence in the form of e-mail headers, e-mail trace route, e-mail attachments, time stamps, or other independent evidence is often used in conjunction with linguistic analysis to establish the identity of the author.

Two studies (both funded by security related government agencies) have applied forensic linguistics to the identification of the authorship of anonymous emails. (See A. Anderson, M. Corney, O. de Vel, and G. Mohay; Identifying the Authors of Suspect E-mail, Communications of the ACM, 2001 (available at eprints.qut.edu.au/archive/00008039/01/8039.pdf); see also Jiexun Li, Rong Zheng, Hsinchun Chen; From Fingerprint to Writeprint, Communications of the ACM (April 2006)).

Characteristics of an email that are relevant in establishing authorship include:

• Composition and writing, such as particular syntactic and structural layout traits;

• Patterns of vocabulary usage;

• Unusual language usage (e.g., converting the letter “f” to “ph”); and

• The excessive use of digits or upper-case letters.

Id.

These studies have found that a dataset of available e-mail used to conduct an evaluation ideally should include about 50 emails per author where each author’s emails include in total approximately 12,000 words. Id. However, other studies have shown that a total of 20 documents for each author are adequate to achieve sufficient accuracy for purposes of authorship identification of an unknown email if additional independent corroborating features are also available. Id. One study, focusing on knowledge acquisition within an organization (for purposes of maintaining institutional knowledge which is lost when an employee leaves an organization) found that email text analysis was superior to a content matter based approached in identifying subject matter expertise within an organization. Campbell, Christopher S.; Maglio, Paul P; Cozzi, Alex; and Dom, Bryon, Expertise Identification using Email Communications, IBM Almaden Research Center (ACM © 2003). Moreover, this study finds a small number of emails sufficient to identify a subject matter expert within an organization. Id.

The literature has found the following stylistic features relevant in describing an individual’s dialect:

• Number of blank lines/ total number of lines;

• Average sentence length;

• Average word length (number of characters);

• Vocabulary richness: (distinct words (V) / total number of words (M));

• Total number of function words (Conjunctions, prepositions, and articles) / total number of words;

• Total number of words three letters or less: all, at, his;

• Hapax legomenon / total number of words (hapax legomenon is a word which occurs only once in the text);

• Hapax legomenon/ total number of unique words;

• Total number of characters in words/ total number of characters in the body of the email (C);

• Total number of alphabetic characters in words/ total number of characters in the body of the email (C);

• Total number of upper case characters in words/ total number of characters in the body of the email (C);

• Total number of digit characters in words/ total number of characters in the body of the email (C);

• Total number of white space characters/ total number of characters in the body of the email (C);

• Total number of space characters/ total number white space characters; and

• Total number of tab spaces/ total number of characters in the body of the email (C).

To date there is only one application publicly available for performing authorship analysis of emails. This application is a python script called Unmask. The application was presented at a computer security conference in 2002 to demonstrate the ease with which stylistic patterns could be used to identify authorship and demographic information of an author using only the text of an email or IRC chat session log. Unmask has been used by forensic examiners for the last few years to identify the authorship of unknown emails with a high degree of accuracy (depending on the stylistic features used). Accuracy ranges between 97.85% and 99.01%. Unmask identifies the author of anonymous email text by analyzing select stylistic features and matching properties of the anonymous text with a known email text. Unmask does not use all the listed stylistic features. A summary of features recognized by various researchers has been compiled for reference purposes. The stylistic features detailed above can also be used to classify emails based on the geographical origin of the author, gender, age, occupation, and sexual orientation.

Unmask is available at http://www.immunitysec.com/downloads/unmask1.0.tar.gz. Unmask was developed by Dave Aitel, who currently is CTO of Immunity Security.¹ Unmask was written soon after Dave Aitel’s departure from the National Security Agency where he worked for six years. Similar tools are known to be in use by the Federal Government for purposes of identifying terrorists and other criminals: these tools are not publically available. By compounding it he expands the differences between different people. The more you match, the more an individual score will increase, however, this is not a linear function. There are some really obvious words, like “a”, “the”, “I”, and “an” that a hypothetical email user will use, and thus common doubles. The frequency of triples is significantly less frequent. Punctuation

Relatively minor differences between the raw scores for two hypothetical test users may reflect significant differences in the likelihood of a match. For example Jane may have a raw score of 20 and John a raw score of 18 and John when identifying an unknown email compared against each users known sample emails. Jane compared against John shows that John’s score is ninety percent that of Jane. Numerous, normal, stylistic similarities between Jane and John will result in their scores hitting a local minimum value that reflects these “normal” stylistic similarities. Beyond this local minimum value unusual and unique stylistic features become a factor (the relative magnitude of these differences are significantly smaller as compared to normal stylistic similarities) accordingly these few matches reflect an exponentially difference in the quality of the match. Accordingly, a 10% relative difference in raw score may potentially equate to a 99% match for Jane and 10% (or less likelihood) of a match for John, even though Jane and John share styles are objectively very close to each-other.

Some unique features of the matching algorithm should be carefully considered when evaluating the quality of a given match:

• Two hypothetical users, with a strong command of English that use a lot of articles, prepositions and conjunctions where there is little bias of either user toward a given combination of words, the more significant small variations become;

• Individuals with a limited vocabulary will have their stylistic features padded by less common words, and generally by default will match less well, accordingly, the likelihood of error is significantly higher where comparing an anonymous email against a universe of potential email users some of which have a good command of English and other users who have a limited English vocabulary. However, users with a limited command of English will likely have stylistics variations that are indicate of their demographic group or nationality; and

• Unique words have been to shown to be strongly correlated to a given user. However, the Unmask algorithm may not match long and/or odd word combinations especially where the sample size for a given library of emails for a given user test case becomes extremely large. Nevertheless the matching algorithm should not be significantly affected with emails because emails are relatively short (opposed to other types of written texts) and where the total sample size of 12,000 words among all emails for a given user is maintained.

Figure 1 – Functions Words (Prepositions, Articles, and Conjunctions Are Distinctive Features)

The few courts that have addressed the issue over the last century have generally found linguistic stylistic features to be admissible evidence:

• In the Matter of the Estate of Violet Houssien, 3AN-98-59 P/R, Superior Court for the State of Alaska(1999)(available at http://www.touchngo.com/sp/html/sp-5496.htm), Court held that the disputed will was not authored by the decedent but by the Appellants [or at their direction].

• In the Matter of the Appeal of Amarjit Saluja, 30082 and 94-16 (1994 California State Personnel Board)(available at http://www.spa.ca.gov/spblaw/pdsindex.htm), the Court found that employee authored anonymous letters that harmed other employees.

• In United States v Larson, 596 F2d 759 (CA8 Minn. 1979), the court held that the jury in a criminal prosecution had been properly permitted to consider evidence showing that one ransom note contained three separate misspellings of “approach” as “approuch,” while a letter known to be written by the accused also contained the same misspelling.

• In Josephs v Briant, 115 Ark 538, 172 SW 1002 (Ark. 1914), court allowed evidence of spelling peculiarities, as well as syntactical peculiarities, to establish authorship of a document.

• In Bartholomew v Walsh, 191 Mich. 252, 157 NW 575 (Mich. 1916), evidence of punctuation characteristics and technical typing characteristics were found admissible.

• In Re Cravens’ Estate, 206 Okla. 174, 242 P2d 135 (Okla. 1952), the court allowed evidence of distinctive punctuation technique along with other typing characteristics to show that a purported testator had not typed certain portions of a disputed will.

Over the last 25 years, with the evolution of more advanced statistical methods and algorithms to identify authorship of a document, this type of evidence has not been challenged. Statistical methods of evaluating the authorship of an article are distinct from traditional literary theory (which in at least one researcher’s opinion is not sufficient to satisfy a Daubert challenge). See C. Chaski., A Daubert-inspired assessment of current techniques for language-based author identification, Technical Report, US National Institute of Justice, 1998 (available at www.ncjrs.org). Writeprinting authors using stylistic features is a new method to combat cybercrime where law enforcement or victims of cybercrimes can use a criminal’s own anonymous emails, blog entries and IRC chat sessions as evidence of their illegal conduct.

          

Fingerprinting (Writeprinting) Text Using Stylistic Features Can Be Used To Accurately Identify the Authorship of Anonymous Emails, Blog Entries and IRC Chat Sessions originally appeared on Law Blog 2.0 on June 20, 2009.

Open Source EMR

On April 23rd Senator John Rockefeller IV introduced the Health Information Technology Public Utility Act of 2009to to build upon open the source electronic health record (eleconic medical record) solution developed by the Department of Veterans Affairs (called VistA)  and other open source software (e.g. OpenEMR).  Unlike proprietary “closed source” software solutions, open source software allows unrestricted access to the source code and does not prohibit the use or re-distribution of software.

Open Source

Currently there are few EMR solutions avaliable in market.  However one vendor attempting to offer an open source solution is called clear-health (http://www.clear-health.com/).  According to ClearHealth’s website: “ClearHealth has taken the powerful VistA EMR system which powers the Veterans Administration health network and modernized it. With added, seamless, scheduling and billing WebVista offers the only fully comprehensive VistA based system in a cost-effective, Web 2.0.”  (http://www.clear-health.com/content/view/41/51/).

Open source is defined by three key characteristics:

• The right to make copies of the program, and distribute those copies;
• The right to have access to the software’s source code;
• The right to make improvements to the program.

(Bruce Perens, The Open Source Definition, 1st Edition Oreilly (January 1999)).

“Open source software is a cost-effective, proven way to advance health information technology – particularly among small, rural providers. This legislation does not replace commercial software; instead, it complements the private industry in this field – by making health information technology a realistic option for all providers.” (Senator Rockefeller)

Summary of Act

Health Information Technology Public Utility Act of 2009:

• Create a new federal Public Utility Board within the Office of the National Coordinator for Health IT to direct and oversee formation of this HIT Public Utility Model, its implementation, and its ongoing operation;
• Implement and administer a new 21st Century Health IT Grant program for safety-net providers to cover the full cost of open source software implementation and maintenance for up to five years, with the possibility of renewal for up to five years if required benchmarks are met;
• Facilitate ongoing communication with open source user groups to incorporate improvements and innovations from them into the core programs;
• Ensure interoperability between these programs, including as innovations are incorporated, and develop mechanisms to integrate open source software with Medicaid and CHIP billing;
• Create a child-specific Electronic Health Record (EHR) to be used in Medicaid, CHIP, and other federal children’s health programs; and
• Develop and integrate quality and performance measurement into open source software modules.

CCHIT Certification and the Open Source Community

CCHIT is the only certification body for electronic medical record systems (EMRs) to date there has been some disagreement around the relevance of the CCHIT standards with respect to open source solutions.  VistA is the U.S. Department of Veterans Affairs National Scale Healthcare Information Systems, which happens to be available for downloaded at no cost from http://www1.va.gov/cprsdemo/.  The open source community and CCHIT requirements are seen to be at odds by some.

One example, noted by a commentator,  SC 03.10 — requires that passwords shall support case-sensitive passwords that contain typeable alpha-numeric characters in support of ISO-646/ECMA-6 (US ASCII).

The commentator noted:

The problem, VistA supports three user ids, one that is equivalent to a username, and two that are similar to passwords. Without getting over my head on the details, there are two possible password types so that you can have one that your admin user can know and reset for you, and one that no one knows but you. There are all kind of administrator abuse scenarios that this addresses, but the VistA username/password/password system is not certifiable out of the box because it does not support case sensitivity. Which, as you can see, is a requirement. Most people are only aware of the CPRS client for VA VistA but in reality there are several clients, all of which support the username/password/password mechanism.  So when any VistA-based EHR goes and gets CCHIT certified it has to make the password system -act- dumber (in compliance with SC 03.09), and add case sensitivity.

(Fred Trotter, CCHIT Feature bucket)

Another critique and a response by CCHIT is avaliable at http://www.emrandhipaa.com/emr-and-hipaa/2009/02/24/cchit-being-thrown-under-the-bus/.  Some commentators argue that a commercial relationship is inconsistent with the definition of open source is required for CCHIT certification.

Bill Status

          

Health Information Technology Public Utility Act of 2009 Would Facilitate the Adoption of Open Source EMR Solutions originally appeared on Law Blog 2.0 on April 26, 2009.