Request For Comment
The request for comment period for this draft concluded on Friday, May 5, 2017. All comments were reviewed and adjudicated by working groups. Comments received after the May 5th deadline may be included in future adjudication and revision periods.
In September 2016, the Information Sharing and Analysis Organization Standards Organization published ISAO 300-1: Introduction to Information Sharing. Section 9, Information Privacy, included core and supporting principles for consideration by entities in establishing an ISAO. This document supplements that high level guidance to further assist entities as they assess the potential privacy implications of cybersecurity information sharing. It builds upon the core and supporting principles by outlining actions to promote efficient and effective information sharing while minimizing the impact on privacy interests.
This document is not intended to create baseline requirements for regulatory or enforcement action. It is consistent with the Cybersecurity Information Sharing Act of 2015 (CISA), draws upon the U.S. Departments of Homeland Security and Justice Guidance to Assist Non-Federal Entities to Share Cyber Threat Indicators and Defensive Measures with Federal Entities, and makes additional suggestions to advance privacy and facilitate robust information sharing.
Submitted Comments
The ISAO SO invited the public to provide comments on this document from April 20, 2017 – May 5, 2017. The line reference and comment fields listed below are the exact contents as submitted by the commenter.
| Line Reference | Comment | Disposition |
|---|---|---|
| 3 | This should elaborate on what "directly related to" means. You can easily draw from the explanation provided by DHS is its guidelines: "Information is not directly related to a cybersecurity threat if it is not necessary to detect, prevent, or mitigate the cybersecurity threat." It also offers examples to illustrate what kinds of personal information can and cannot be shared. Both documents highlight that personal information related to victims of cyber-attacks, such as information that identifies the recipient of a phishing email, is not directly related to a cybersecurity threat, and must be removed before sharing or dissemination. See DHS's Company Guidelines at pg. 5 and Privacy Guidelines at pg. 12. | Accepted |
| 4 | De-identify is used several times—I'm not sure why it's necessary where there is already a redact or remove requirement. Also, de-identification can be problematic because increasingly that information can be re-identified. I'd remove all instances of the term "de-identify". | Accepted |
| 7 | FS-ISAC values the ISAO SO's efforts and generally finds the practices included consistent with the guidance that DHS and DOJ has previously provided. We would suggest adding the following at end of line 7: " to encourage information sharing of threat indicators and defensive measures." | Accepted |
| 34-35, 39-41, 68-69 | The language in these lines describes what kinds of information identifying an individual should be removed or redacted using various forms of "information of a specific individual or that identifies a specific individual". However, this is wrapped up in the debate about personally-identifiable information vs. personal data. There is data that does not necessarily identify an individual and that is not "of" an individual that is still quite sensitive and should be removed or redacted. For example, persistent device identifiers or hardware identifiers (Ethernet/WiFi MAC addresses, OS-level unique identifiers like the UUID on iOS and the SSAID (Android ID) on Android OS) are recognized to have serious privacy implications for users that could enable tracking and other kinds of unwanted privacy violations. While software platforms are moving away from exposing hardware identifiers, network operators and other enterprises will encounter them in network traffic and intrusion-related data and these values should be removed or redacted unless specifically needed to counter the cybersecurity threat. | Rejected |
| 34-42 | #3 and #4 say basically the same thing, although I assume the intention is that #3 is for information you share, and #4 is for information you receive. Suggest you make that a little clearer. | Accepted |
| 39,49 | "The language in these two lines stipulates that entities should ""securely dispose of, deidentify, or anonymize"" information related to a specific individual. (Of course, my earlier comment about ""individual"" versus ""device"" stands here too.) However, the three things listed here are very different and accomplish different goals. Disposing of information generally refers to deleting it and, as we explain in a recent paper [1], this means de-indexing or securely deleting the information (we would advise secure deletion). Anonymization refers to a process that destroys linkability between a data record and the data subject, and this can take a number of forms (shuffling, dummy data creation, etc.) as described well by the Article 29 Working Party [2]. De-identification is the real outlier in this group; de-identification refers to removing identifiers and ""quasi-identifiers"" that could be used to link a data subject to a data record. De-identification is prone to some controversy as academic computer scientists have shown time and time again that they can still identify records in de-identified data sets. In short, without further guidance these three verbs give too much flexibility and could result in data being shared that is easily identifiable. I could go on about what that guidance should look like, but I suspect the ISAO SO may have other materials on that. I suspect ""minimize"" replacing all of these verbs would be the best way forward, as that makes it clear that you should remove or in general reduce risk in the data. Of course, civil society like us at CDT would suggest you simply remove ""deidentify"" as the other two options better assure the information will not hold latent risks for users or sharing entities. [1]: https://cdt.org/?p=79577 [2]: https://cnpd.public.lu/fr/publications/groupe-art29/wp216_en.pdf | Accepted |
| 54 | "Please add the below to bullet #7: ""However, do not use TLP to overly restrict sharing of cybersecurity information and strive to distinguish information that should ordinarily be shared broadly for organizations to protect themselves (e.g., indicators of compromise) from more sensitive cyber data (e.g., attribution of indicators to a particular threat actor or specific techniques being used)."" Want to ensure folks are thinking about how to properly mark data for sharing. Thanks. | Partially Accepted |
| 62-64 | #10 gives you a good set of overarching concepts: receipt, retention, dissemination, and use. Every other provision fits into one of those, assuming you consider destruction as a aspect of retention policy. You might consider organization all 11 principles into those 4 buckets since it makes it easier to parse, particularly to ops folks that may have responsibilities in one or more of those areas. | Rejected |
