Daily Archives: February 23, 2016

DHS Establishes Information Sharing Capability and Process Required under CISA; Issues Multi-Agency Information Sharing Guidance

The Department of Homeland Security (“DHS”) has posted four documents on the US Computer Emergency Readiness Team (US-CERT) website to satisfy several requirements set forth in the  Cybersecurity Information Sharing Act of 2015 (“CISA”).  Details on the four documents are provided below.

By way of background, CISA was passed into law on December 18, 2015 and provides authorization for, among other things, the sharing of cyber threat indicators and defensive measures by and between the federal government, private entities, and state, local, and tribal governments.  The law also provides liability protections for non-Federal entities that share or receive cyber threat indicators or defensive measures, provided that these activities are conducted “in accordance with” the Act.  This requires, among other things, that (1) the information shared meets the definitions of cyber threat indicator or defensive measure, as applicable; (2) that the sharing be “for a cybersecurity purpose”; and (3) that the sharing entity comply with the requirement to screen information prior to sharing it for personal information that is not directly related to a cybersecurity threat and remove it.

In addition, when sharing with the federal government via electronic means, liability protections generally attach only if the information is submitted through the capability and process required to be established by DHS under the act.  CISA directs that this be “through electronic mail or media, an interactive form on an Internet website, or a real time, automated process between information systems.”



In keeping with these requirements, the three ways DHS has established for entities to electronically submit cyber threat indicators to the federal government are as follows:

  1. Via DHS’ Automated Indicator Sharing (“AIS”) program, which allows entities to share information with the federal government in real time by connecting through a specialized client to an AIS server operated by DHS’s National Cybersecurity and Communications Integration Center (NCCIC).  Information shared in this manner must conform to the Structured Threat Information eXchange (STIX) and be transmitted via the Trusted Automated eXchange of Indicator Information (TAXII), which are the format and exchange mechanisms, respectively, selected by DHS for real time threat sharing.  Among other features of AIS, DHS notes that it:
    • Performs a series of automated analyses and technical mitigations to ensure that personally identifiable information that is not directly related to a cybersecurity threat is removed before any information is shared (with human review where necessary); and
    • Anonymizes the identity of the submitter of the information, unless the submitter has consented to sharing its identity.
  2. Via email.  When using this method, entities must email “ncciccustomerservice@hq.dhs.gov” and ensure that the shared information conforms to specified formatting requirements.
  3. Via a webform established by DHS for this purpose.

DHS discusses these methods for sharing cyber threat indicators and defensive measures with the federal government in one of the four documents it posted: Interim Procedures Related to the Receipt of Cyber Threat Indicators and Defensive Measures by the Federal Government.  This document, issued by the Secretary of Homeland Security and the Attorney General in consultation with the heads of appropriate federal agencies, “describes the processes for receiving, handling, and disseminating information that is shared pursuant to CISA,” as required under Section 105(a)(1) of CISA.

The other three documents that DHS posted to its website generally satisfy specific directives in CISA to provide additional detail around certain processes, as follows:

  1. Guidance to Assist Non-Federal Entities to Share Cyber Threat Indicators and Defensive Measures with Federal Entities under the Cybersecurity Information Sharing Act of 2015: This document responds to Congress’s directive in Section 105(a)(4) of CISA and provides guidance on (1) types of information that would qualify as a cyber threat indicator that would be unlikely to include information that is not directly connected to a cybersecurity threat that is also personal information or personally identifiable information, and (2) types of information protected by otherwise applicable privacy laws and that are unlikely to be directly related to a cybersecurity threat.
  2. Privacy and Civil Liberties Interim Guidelines: Cybersecurity Information Sharing Act of 2015:  Section 105(b)(1) of CISA directs the Attorney General and Secretary of Homeland Security to “jointly develop, submit to Congress, and make available to the public interim guidelines relating to privacy and civil liberties which shall govern the receipt, retention, use, and dissemination of cyber threat indicators by a Federal entity obtained in connection with activities authorized in this title.”  The interim guidelines created in response to this directive direct federal entities to “follow procedures designed to limit the effect on privacy and civil liberties of federal activities under CISA.”  Specifically, the interim guidelines define CISA-specific implementations of the Fair Information Practice Principles (FIPPs) set forth in Appendix A of the National Strategy for Trusted Identities in Cyberspace, namely: transparency, individual participation, purpose specification, purpose specification, data minimization, use limitation, data quality and integrity, security, and accountability and auditing.
  3. Sharing of Cyber Threat Indicators and Defensive Measures by the Federal Government under the Cybersecurity Information Sharing Act of 2015: In response to a directive in Section 103 of CISA, the Director of National Intelligence, the Secretary of Homeland Security, the Secretary of Defense, and the Attorney General, in consultation with the heads of appropriate federal entities, issued these procedures, which “facilitate and promote” the sharing of threat information by the federal government with non-federal entities, such as private entities and state and local governments.  Such sharing falls into the following categories:
    • Timely sharing of classified cyber threat indicators and defensive measures in the possession of the Federal Government with representatives of relevant federal entities and nonfederal entities that have appropriate security clearances;
    • Timely sharing with relevant federal entities and non-federal entities of cyber threat indicators, defensive measures, and information relating to cybersecurity threats or authorized uses under this title, in the possession of the Federal Government that may be declassified and shared at an unclassified level;
    • Timely sharing with relevant federal entities and non-federal entities, or the public if appropriate, of unclassified, including controlled unclassified, cyber threat indicators and defensive measures in the possession of the Federal Government;
    • Timely sharing with federal entities and non-federal entities, if appropriate, of information relating to cybersecurity threats or authorized uses under this title, in the possession of the Federal Government about cybersecurity threats to such entities to prevent or mitigate adverse effects from such cybersecurity threats; and
    • Periodic sharing, through publication and targeted outreach, of cybersecurity best practices that are developed based on ongoing analyses of cyber threat indicators, defensive measures, and information relating to cybersecurity threats or authorized uses under this title, in the possession of the Federal Government, with attention to accessibility and implementation challenges faced by small business concerns (as defined in Section 3 of the Small Business Act (15 U.S.C. 632)).

The procedures note that the required information sharing is currently implemented through a series of existing programs, of which the procedures provide an overview.  The procedures also provide an overview of the roles and responsibilities of federal entities, non-federal entities, and Information Sharing and Analysis Centers (ISACs) and Information Sharing and Analysis Organizations (ISAOs) in the information sharing context.

For Your Eyes Only: Experts Explore Preventing Inadvertent Disclosures During Discovery

The Altep, kCura and Milyli webinar explored best practices for safeguarding information, as well as technological tools for redaction

There may be a number of “Scott’s” in Chicago, but there are fewer with a specific last name attached, and there is only one with that specific Social Security Number. This information – or a telephone number, or a fingerprint, or even the MAC address of a computer – can be used to identify and verify a person.

But of course, for as valuable as personally identifiable information (PII) may be for you, it’s just as valuable to a malicious actor looking to steal and utilize it for nefarious purposes. That’s why, when conducting discovery, protecting that information should be of the utmost importance for organizations, law firms, and discovery vendors.

Three of those legal technology companies joined together to put that security forth in a recent webinar called“How to Prevent the Disclosure of PII.” The webinar’s panel included Hunter McMahon, vice president of legal and consulting services, Altep; Scott Monaghan, technical project manager, Milyli; Aileen Tien, advice specialist, kCura; and Judy Torres, vice president of information services, Altep.

In order to prevent disclosure, the panelists asked one important question: What exactly is PII? “It really comes down to what information can identify you as an individual,” McMahon said. This includes information that can be categorized into different categories based on how specific and how personal it is , leading McMahon to notenote that data holders should examined PII to determine if it is sensitive, private, or restricted.

When examining PII in the system, it’s also important to examine what regulations and laws the PII falls under. This can include a number of different federal regulations, HIPAA/HITECH (health PII), GLBA (financial PII), Privacy Act (PII held by Federal Agencies), and COPPA (children’s PII). Forty-seven states also have their own information laws, including varying guidelines on breach notification, level of culpability, and more.

Once that information is known, said the panelists, those conducting discovery should turn to the next question: What are the processes in place to protect the data? “Documents that are in the midst of discovery are really an extension of your retention policy… so you have to think about that risk the same way,” McMahon noted.

Torres explained that the proper approach to take to PII is that it will always be in a document set, if it seems unlikely that PII exists in a system. For example, she said not to assume that because a data set concerns only documents accessed during work hours, it will not contain PII.

“Most people, when they’re working, are also working the same time as those people they need to send documents to,” Torres explained. In one case, looking at data from Enron’s collapse, the documents in the case contained 7500+ instances of employee PII, including that of employee’s spouses and children, as well as home addresses, credit card numbers, SSN, and dates of birth.

In order to combat this data lying in the system, it’s important to take a proactive approach, the panel said. “The approach is much like data security in that it’s not going to be perfect, but you can help reduce the risk,” McMahon added.

To protect it in review, those conducting discovery can limit access to documents with PII, limit the ability to print, and limit the ability to download native files. Likewise, teams can employ safeguards during review such as training review teams on classifications of PII, training reviewers on PII workflow, implementing a mechanism for redaction and redaction quality control, and establishing technology encryption.

And even if not using human review, abiding these protocols can be important, “I see such a trend of more cases using assisted review, so you’re not necessarily having human eyes on every document. So it makes sense to make our best effort to protect PII on documents that may not necessarily have human review,” Torres said.

Properly conducting redactions to make sure nothing is missed can be a pain for reviewers as well, but Tien walked the webcast’s viewers through an introduction of regular expressions (reg-ex), one of the most common technology tools for PII redaction. In short, reg-ex is a pattern searching language that allows one to construct a single search string to search for a pattern of characters, such as three numbers, or three letters.

For one example, Social Security Numbers have a very specific format: XXX-XX-XXXX. Reg-ex can be used to find all constructions of this type, using an input like the following: [0-9]{3} – [0-9]{2} – [0-9]{4}

“With practice, you’ll be able to pick this up like any foreign language,” Tien said.

See post Sneaky PII: What’s Hiding in Your Data?

PCI DSS 3.2 slated for early 2016

100815500x188pciimage_883995

To accommodate updated migration dates to a more secure version of TSL and other factors in the payment industry, the PCI Security Standards Council will release PCI DSS version 3.2 in the spring

PCI DSS version 3.2, scheduled for release in the first half of 2016, likely March or April, will address  the current threat landscape as well as “trending attacks causing compromises” detailed in current breach forensics reports, PCI Security Standards Council Chief Technology Officer (CTO) Troy Leach said in a blog post Q&A.

“With this in mind, for 3.2 we are evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed,” Leach said.

New versions of PCI DSS are typically released in the fall, but the council moved 3.2’s debut up, in part, to “address the revised migration dates away from SSL/early TLS,” Leach said. In a December bulletin, the council extended the deadline to June 30, 2018 for organizations to complete migration from Secure Socket Layer and Transport Layer Security 1.0 to a secure TLS iteration.

An early release also acknowledges PCI DSS‘s status as a “mature standard” that doesn’t need significant updates any longer. “Moving forward, you can likely expect incremental modifications to address the threat landscape versus wholesale updates to the standard,” he said.

Leach also noted that a spring release “with long sunrise dates” gives organizations time to do the business case for their security investments in the drastically changing payment acceptance market “from advancements in mobile payments to EMV chip rollout in the United States, to adoption of other forms of dynamic data and authentication.” An earlier release “allows us more time to dedicate to security priorities for those specific payment channels in the future,” he explained.

Additionally, the organization will release changes to PA-DSS a month after PCI DSS 3.2 is unveiled.

As is customary, the council will retire version PCI DSS 3.1 three months after it releases version 3.2.