Request For Comment
The request for comment period for this draft concluded on Friday, August 5, 2016. All comments were reviewed and adjudicated by working groups. Comments received after the August 5 deadline may be included in future adjudication and revision periods.
These guidelines serve to address the needs for newly forming Information Sharing and Analysis Organizations (ISAOs). Designed to take into consideration the different types of ISAOs that may be formed and the capabilities each may incorporate, it presents an organized approach to the various topics pertinent to ISAOs while considering the immediate needs of emerging ISAOs. As this is a draft document that will continue to be edited and refined until its release in Fall 2016, sections that appear in this version of the draft may not be included in the final release. Additional documents to be released will include more detailed discussions of various information sharing subjects.
Submitted Comments
The ISAO SO invited the public to provide comments on this document from July 27, 2016 – August 5, 2016. Both fields listed below (line number and comment) are the exact contents as submitted by the commenter.
| Line Reference | Comment | Disposition |
|---|---|---|
| General | In several places the document qualifies statements to allow for flexibility in what a specific ISAO provides its stakeholders and how it operates. Consider consolidating this into one place for consistency and clarity. This can be stated up front in the document and then not repeated again. Doing so will make the document more consistent and easier to read. | Under Review |
| General | We made the suggestion before, but in terms of cyber incident response resources, the Forum of Incident Response and Security Teams (FIRST) created a SIRT framework for security incident response teams: https://www.first.org/global/education. This could be a good reference for developing ISAOs. | Under Review |
| General Comment | We understand there is discussion on establishing a third-party certification regime to ensure ISAOs meet a set of "minimum requirements". The SO has stated there is "growing consensus" on this approach. It is worth noting that comments submitted on behalf of a substantial number of industry and information sharing organizations during the previous public comment process expressed concerns with this approach and indicate that the community does not have a "growing consensus". | Accepted |
| General Statement | Unless the draft guide is going to undergo severe editing, I really question its value. It's too long, wordy, confusing, uneven, vague in many places and overly complicated in others. If the final version as anything like this draft, the prospect of starting an ISAO will be very daunting. Our aim should be a practical set of suggestions - not an academic-y treatise. I strongly encourage the SO to hire [unbiased] SMEs to comb through the document to determine what some of the writers are trying to get at and re-do the language where necessary. Below are a few examples. By the way, I recommend a good explanation of the security clearance programs, what to expect and the relative benefits of having a clearance. You would want to note that DHS policy is that if your org has a CRADA with CISCP, your clearances must go through CISCP and if you have one through the private sector clearance office, you'll be deactivated. | Under Review |
| Section 2 | Section 2 - The entire introduction should be rewritten and refocused once the body of the document has stabilized. As it is this section, covers why info sharing is needed, the process used to create the document, a discussion of the anticipated variety of ISAOs, and then very little about the document itself. It would be nice to see the introduction provide an explanation of the document, its content, and its intended use. | Under Review |
| Section 3 | Section 3 - Given the broad international audience of this set of guidelines, consider deemphasizing US EO 13691 and instead use examples from the private sector that can characterize the ISAO ecosystem. | Rejected |
| Section 5.1 | Section 5.1 - the descriptions of situational awareness, decision-making, and actions should use a consistent perspective. Given that the target audience of this paper is an ISAO, orient all descriptions around that perspective. For example, the description of situational awareness starts with "ISAO members" and the description of decision-makers starts with "ISAOs need to". | Under Review |
| Section 5.1 | Section 5.1 - In section 5 the document uses a three categories (strategic, tactical, and immediate). While section 5.1 seems to use two (strategic and tactical). These should be aligned. | Under Review |
| Section 5.2 | Section 5.2 - refocus this section to encourage ISAOs to develop a clear articulation of their value proposition. Allow section 3 and 4 to generally talk about the value of an ISAO. This section should be about recommendations / guidelines for ISAOs. As it is, the list of benefits is not exhaustive or applicable to all ISAOs. The current list of benefits represents examples of some benefits that an ISAO might provide. It is not a comprehensive list and it should be positioned as set of examples. Additionally, the last item in the list "ISAO members can carry out effective and timely responses if they discover unauthorized intrusions." Is not an example of a benefit that an ISAO offers its members. | Under Review |
| Section 5.3 | Section 5.3 - remove the listing of types of information that might be shared. This material is inconsistent with the material that is listed in section 6 and duplicative of the material in section 6. | Accepted |
| Section 5.3 | Section 5.3 - The section heading seems disconnected from the section content. This section should try to list and describe the high level concepts that an ISAO should consider. Looking through the full section content, it appears as though these are the concepts that were intended to be listed: Policy, types of information shared, Role, Purpose, Triggers for sharing, how the information is shared (machine to machine and automated vs other options), data sensitivity and data handing and use, mechanism for formalizing these policies. For each concept, define it and explain why it is relevant. Do not try to list lots of examples. Allow later sections in this document to provide the details. | Under Review |
| Section 5.3 | Section 5.3 (continued 2) - starting at Line 248, the text seems to imply that the role of the ISAO needs to be clearly articulated and agreed upon. Discuss that point rather than list a few possible roles. | Accepted |
| Section 5.3 | Section 5.3 - line 283 says that the ISAO members determine what information is shared. That may not be true. The ISAO might make that determination. | Under Review |
| Section 5.4 | Section 5.4 - in general the contents of this entire section are vague and do not support a consistent and easily understood set of guidelines. This section offers many good thoughts on ISAO creation, but the material is unorganized and often lacks explanation and justification. | Under Review |
| Section 5.4.1 | Section 5.4.1 - this section has some good driving questions to consider when defining the value proposition of an ISAO. However, the section should be rewritten to more explicitly focus on defining the essence of the ISAO (its mission and vision). A guidelines document should have the perspective of how to systematically address the questions vs. listing over 20 questions that should be addressed. Additionally, the questions are not of the same class. Some are focused on mission and vision at a high level. Others are focused on how information will be shared and what will be shared. Others seem to be focused on other areas. Consider reorganizing and grouping these questions into topic areas and ordering them from high level mission and vision defining to lower level operational considerations. | Accepted |
| Section 5.4.2 | Section 5.4.2 - This section needs to be rewritten to first talk about a few key factors of trust and then list common key considerations for and ISAO. As is, this section (and other sections in 5) rely heavily on bullets, some of which are not well explained (lines 428-446), and much of it lacking the prose that provides coherence and cohesion - and is critical for understanding the section, especially for someone who is new to the topic of ISAOs. | Accepted |
| Section 5.4.2 line 431 | Section 5.4.2 - line 431 - perhaps transparency must not be supported. How would anonymity be supported? | Accepted |
| Section 5.4.2 - line 435 | Section 5.4.2 - line 435 - what about by sector? | Accepted |
| Section 5.4.3 | Section 5.4.3 - the intro states, "establishing a membership model consisting of the follow" and then it lists a membership model as one of the components of a membership model. Suggest renaming the "membership model" heading | Under Review |
| Section 5.4.6 | Section 5.4.6 - This section contains a large amount of information on forming a legal entity that seems very general in nature. Suggest focusing the material on just what is specific to an ISAO and then citing some external resource that might help group determine how best to form a legal entity. | Accepted |
| Sections 5.5 and 5.6 | Sections 5.5 and 5.6 - Mention concepts such as the 3 level of Capabilities, lexicon, roadmap for development, and standard descriptive form, which are not referenced elsewhere in the document. It's difficult to understand the full relevance of these concepts and how/when/where one would use them when standing up an ISAO given the lack of reference elsewhere. Also, bear in mind that these resources will need to be maintained and the ISAO SO should be prepared to support that maintenance. | Accepted |
| Section 5.5 Line 900 | Section 5.5 - Line 900 - I like the idea of creating a form for ISAOs to use to describe their capabilities. This could both help the ISAO SO learn about the ISAO landscape as it evolves to allow the ISAO SO to mature its own offerings and it could really drive the content of the ISAO registry. This section of text needs revision though. The text reads as though it is an idea for consideration rather than a statement of what the ISAO SO is doing. For example, change "this approach would feature" to "this approach features". This revision needs to extend though about line 932. | Under Review |
| Section 5.6 - Lines 975 through 1006 | Section 5.6 - Lines 975 through 1006 - consolidate this text to one simple paragraph that describes the section as a whole and why categories of ISAOs are useful. | Under Review |
| Section 5.7 | Section 5.7 - This section can probably be deleted. | Under Review |
| Section 6.3.11 - Lines 1511 - 1557 | Section 6.3.11 - Lines 1511 - 1557 should have been deleted. These are left over from an earlier draft before we had fleshed out the rest of the content in section 6.3. I previously mentioned this to the WG, but I think that my revisions got lost in the effort to merge other comments and edits. I sent a follow up email to WG3 on this topic on July 27th. | Accepted |
| Section 6.4.3 - lines 1764 - 1770 | Section 6.4.3 - lines 1764 - 1770 are duplicative of the earlier explanations of these three categories of information. This can be deleted. | Accepted |
| Section 9 | Section 9 - Add a reference to the work that DHS NCCIC did for AIS looking at PII. Section 9.2 references this material, but consider moving the reference up to the top of Section 9. https://www.us-cert.gov/sites/default/files/ais_files/PIA_NPPD-AIS.pdf and https://www.us-cert.gov/sites/default/files/ais_files/Privacy_and_Civil_Liberties_Guidelines_%28Sec%20105%28b%29%29.pdf | Partially Accepted |
| Section 11.1 - Delete lines 2344 - 2356 | Section 11.1 - Delete lines 2344 - 2356 - these paragraphs are context that is not needed when this material is included in this consolidated document. Additionally, the paragraph at line 2357 could be the opening to the higher level section 11. The heading for Section 11.1 could be deleted. | Accepted |
| Section 11.2 | Section 11.2 - add reference to each supporting function to allow readers to find more information about each. | No Action Required |
| Section 13 | try to cite other sources for the definitions. | Partially Accepted |
| 14 | computer security seems to date the document to the 60's. Isn't it really more about "data security"? | Rejected |
| 38 | In the sentence "there will also be varying levels of organizations within the ISAOs, and there may be commercial entities that form to provide services to ISAOs" recommend adding "or if they are already formed, self- certify as ISAO" between "form" and "to provide services to ISAOs". This is to recognize that some organizations already engage in information sharing and analysis activities as described in the definition of an ISAO as part of their routine business and will not have to form a separate organization to be an ISAO but will only have to self-certify to be recognized as ISAO. | Accepted |
| 38 | Not sure what is meant by "various levels of organizations within ISAOs" and its relevance to the paragraph's point | Accepted |
| Line 39 | The phrase "there may be commercial entities that form to provide ISAO services" seems to not account for the fact that commercial entities that currently exist do provide ISAO services and may want to be recognizes as an ISAO. Recommend changing the language to state "there may be commercial entities that choose to serve as an ISAO and provide ISAO services." | Accepted |
| 45-47 | While understanding the intent of the language, as written, it implies that ISAOs of limited capabilities are not effective or do not meet member needs. Suggest re-wording to emphasize how the ISAO can change based on member needs and direction. For example: Additionally, an ISAO may initially form with limited objectives and targeted capabilities but then adjust or enhance services to meet evolving member needs. | Accepted |
| 54-56 | Is the intent to really say that "any individual" or "any" organization can become part of the national information sharing initiative? "Any" includes bad actors and individuals or companies that may have malicious intent. | Rejected |
| 83-93 | The document really should avoid getting involved in policy discussions and statements. For example, discussion about the need to "understand" the "impact" of information sharing and where it is being shared are not appropriate discussion points for a standards document. These are all policy matters that need to be sorted through with the Federal Government and stakeholders. Stating what the EO says is fine, but the extra policy commentary is not appropriate for a document who's goal is to identify voluntary guidelines for ISAOs. | Partially Accepted |
| 94-120 | Since the official definition reiterates "critical infrastructure" four times, I think it's important the we clearly state that not all ISAOs pertain to the 16 or so defined critical infrastructures. At minimum, I'd suggest BOLDING the last sentence (lines 116-120. | Under Review |
| 121 | General comment about section 5 - first in the title "Capabilities" seems misleading based on the actual content of the section. This entire section is very confusing - not sure what we're trying to say to the reader. Either the introduction (5.1) is off - that is it doesn't match the follow-on discussions, or there are simply subsections out of order. Subsections 5.2 - 5.6 seem to make more sense under Section 4.0. Several ideas are introduced that are never really explained/defined or conflict: fully capable, broad categories - sit aware, decision-making, actions, and later: foundational, additional, unique, and then defined later as: individuals, industry, geo, or other. Then there are "four strategic drivers", "core capability areas", but only "three types of capabilities". Sorry, I'm completely lost. Where is the simple cafeteria list of capabilities and their descriptions that and ISAO needs to understand? More comments to follow based on line numbers... | Under Review |
| 124 | We need to avoid describing an ISAO as being "fully capabable" which implies their is an optimal ISAO model or that an ISAO needs to have a set of advanced capabilities to be "fully capable." The goal of an ISAO is to meet its member/customer needs. This will require some ISAOs to have malware analysis and fly-away teams, and will require others to share pdf documents. But both are "fully capable" of meeting their member needs. | Under Review |
| 124, 128 | What is "fully capable"? Where even is the list of "capabilities"? What are the "services"? | Partially Accepted |
| 128 | Recommend that the ISAO SO considers the following in connection with the concept of fully capable ISAO. If the SO guidelines establish minimum requirements for each ISAO capability level, will that become a de facto standard of care that can open an ISAO up to liability for a failure to meet minimum requirements or an organization who certified the ISAO as a fully capable one? I am wondering whether the SO is considering this question in its internal debates about "minimum requirements" and "capability levels"? | Under Review |
| 129-131 | Similar to our comment #5: Some ISAOs may be asked by members/customers to provide strategic information. Some may be asked to provide tactical. Some may be asked to provide both. But it's not right to say a "fully capable" ISAO provides both. | Under Review |
| 133 | Recommend adding "contextualize" after "analyze it" in the following sentence - "ISAO members need to understand both the tactical and strategic aspects of the environment in which they are managing risks. This support includes activities to collect and share information, analyze it, and recommend what to do with it". This is to emphasize the role of context in cyber risk management. Context is what creates the larger picture that is required to make informed decisions about threats. Information and indicators need to be supplemented by contextual data about the nature, scope, and risk associated with those indicators. Context enables prioritization and decision making, allowing defenders to respond faster and more effectively. Contextually based cyber threat intelligence delivers a deeper view into the actions, intent, tools and tactics, techniques and procedures (TTPs) utilized by the adversary. | Accepted |
| 137-141 | This suggessts that the ISAO "needs" to do these specific activities and implies the ISAO will have a staff to do this. An ISAO may not have a staff and members of the ISAO may share information directly with other ISAO members, without a third party receiving it, establishing relevance, or identifying potential courses of action. Overall, we don't disagree that this section (133 - 150) describes the potential value of an ISAO, but it is implying that an ISAO must do ALL of these activities ("The ISAO in turn also has responsibilities for each of these categories" --line 148-150) to be "fully capable." This is not the case since ISAO members/customers may only request the ISAO to provide specific capabilities or services.We sug gest that this section can be improved by describing how ISAOs can provide value to members/customers by providing the members/customers enhanced situational awareness and informed decision making, which leads to effective risk mitigation activities. | Under Revew |
| 151 | Is the value prop a capability? This might flow better as subsection 4.1 under the definition of an ISAO. | Under Review |
| 154-169 | The language needs to be clarified that these are among the potential benefits an ISAO can offer its members/customers. For example, an ISAO can offer indicators, but not best practices. Not every ISAO will provide each of the benefits listed. | Accepted |
| 157 | ISAOs will make to "ISAOs that will assist in making" | Under Review |
| 163 | Recommend adding "or from multiple sources or places" after "multiple organizations" in the following sentence "by aggregating information from multiple organizations, ISAOs present a richer picture of malicious activity taking place around the country and the world." In an ISAO, and in a single-company ISAO in particular, a richer picture of activity can come from various places or sources, and not necessarily only from multiple organizations. For example, information can be aggregated from multiple appliances, incident response teams, cyber threat research, or subsidiaries located around the world etc. | Under Review |
| 170 | For readability, suggest moving under section 4 as subsection 4.2 (assuming previous comment is accepted). | Under Review |
| 225-337, 1522-1557 | As organizations around the country and world develop information sharing capabilities, we see shadows of some of the same challenges that arose in the context of post-September 11th terrorism information sharing efforts. The ISAO process has an opportunity to nip this risk in the bud by fostering a common language to describe the key attributes of cyber threat information. For data to be useful beyond an immediate context, it has to be searchable. In other words, for data to be useful in a longer term - particularly data around Tactics, Techniques & Procedures (TTPs), Threat Actors and Incidents - it should ideally be standardized at collection. The Markle Foundation Task Force on National Security in the Information Age calls this concept "discoverability" - the "who, what, where, when" values - and analogizes to a card catalogue in a library. Without standardization, it can be impossible to draw actionable information out of the data being shared. In a terrorism context, the National Information Exchange Model (NIEM) was developed and has formed the foundation for such capabilities as the National Data Exchange (N-DEx) system utilized by state and location law enforcement, as well as the National Suspicious Activity Reporting Initiative. In other words, these systems entail "semantic interoperability" so we can understand that what one system calls a "car" and another calls a "vehicle" is in fact the same thing. In the context of 100-1, we would recommend the following modifications to address this issue. | Under Review |
| 225-337, 1522-1557 | a. In the cyber context, we welcome the reference to the Structured Threat Information Expression (STIX) framework. In our view, STIX should be more prominently reflected in ISAO 100-1 - not just in Section 6.3 but also in all other sections of the document that address the process of sharing, in particular the examples of information to be shared in Section 5.3 starting on page 7 at line 225. The current list conflates information types (indicators such as malicious IP addresses, indicators of compromise) with sources of information (vendors, government) and analyses products (big data, trending and analysis). By conflating aspects of information sharing, the current draft muddles what would otherwise be a common language. Sources and analysis products should be described as separate aspects of the nature of information sharing. A similar issue appears in 6.3.11 ("Best Practices") as regards the list the starts on page 45, line 1522. b. That said, at an operational level, many practitioners today leverage the Vocabulary for Event Recording and Incident Sharing (VERIS) to manage threat and incident information. VERIS includes schema for a number of aspects of cyber threat activity, including detailed categorizations for Actors, Actions, Assets and Attributes. We recommend that VERIS be expressly called out as a mechanism for describing the various STIX data attributes" particularly TTPs - in greater detail, particularly in Section 6.3. c. We also believe it may be worth leaving a placeholder for future work in aligning common threat language for cyber risks (e.g., VERIS) with NIEM so that, as Internet-of-Things and other cyber-to-physical risks materialize, we will have a common threat language to apply against a converged set of security risks. | Partially Accepted |
| 338 | How is "Creating an ISAO" a capability - suggest moving under Section 4 as subsection 4.3. | Under Review |
| 338-1065 | In discussion the creation of an ISAO (Section 5.4), ISAO 100-1 includes descriptions of the characteristics of each ISAO category and examples of what such an ISAO could look like. The language in places - e.g., funding models, membership models, types of legal entities - appears to rest on a flawed assumption that an ISAO will in all cases be established as a standalone organization. In fact, already existing industry associations have the capability to serve as an ISAO. In our experience, several industry associations already serve as ISAOs, providing their members with information sharing and analysis services at no additional cost to member organizations. Thus the language on establishing an ISAO should be amended to acknowledge that preexisting organizations may establish an ISAO capability. Certain issues such as fees may thus be moot, but the preexisting status of an organization does not obviate the need to consider whether specialized, supplemental commitments or legal agreements should be required of members seeking to participate in an ISAO capability. | Under Review |
| 375 | Recommend explicitly recognizing "for-profit- fee for product/fee for service model" as one of the ways how ISAOs will maintain sustainability in the following sentence - "How will the ISAO maintain sustainability? What funding models support the ISAO - Grant(s), Corporate Sponsorship, Membership Model, etc". This is important for consistency as the guidelines for establishment of ISAO mention for-profit ISAOs. Additionally, the EO 13691 explicitly recognize the for-profit model. | Accepted |
| 412 | This section can benefit from an introduction that introduces the topic and makes clear that what is provided are some potential considerations for ISAOs. They are free to choose to incorporate what they think will work for their specific circumstances, business model and organization. | Accepted |
| 447 | This discussion on Membership Model should note that this is one potential model. There is also a "customer model" where a company provides ISAO services to its customers. | Accepted |
| 447 | Recommend adding "and/or customer base" to the section title "ISAO Membership". This is important to recognize that some ISAOs will have paying customers and not members. In addition, some ISAO may have both for-profit and not-for-profit structures and have both members and customers. | Accepted |
| 483-483 | Generally, it is best to limit the use of the word "should" in the document. The word implies that this is something an ISAO must do. In this specific case, an ISAO does not need a marketing budget if it does not intend to expand beyond its current membership. Also, perhaps the ISAO members will donate marketing and PR professionals to assist the ISAO. The only thing an ISAO "should" do is meet the needs of its members and customers. If they don't want to market their services, they should not have to have a marketing budget. | Accepted |
| 540-542 | This just one example of language that is vague and offers no helpful advice. And what does "external environment" cover? Does it refer to the items that follow? If so, that's not clear. | Accepted |
| 553 | We propose adding ", if any" after "support staff" since an ISAO may choose to forgo the costs of dedicated staff and/or may not have a model that requires dedicated staff. | Accepted |
| 596 | Error in the PDF document: "Error! Not a valid bookmark self-reference." The "Figure 1" referenced for funding models is not present. | Under Review |
| 596 | Obvious "Error" Message needs to be corrected. | Under Review |
| 612 | Suggest highlight funding models as examples only - there are others. | Accepted |
| 612-613 | The types of business models are inaccurate. For instance, being member-driven is not exclusive to non profits, and non profits are can have free levels of service. The charts are really confusing and unnecessarily complicate the subject. Why would a nonprofit not be able to "build products that use information gathered from the ISAO."? What types of products? Who are you referring to when you say gathering information FROM the ISAO? Another company? | Under Review |
| 628 | Recommend adding "End User License Agreement (EULA)" as one of the documents for membership requirements. In ISAOs where sharing of information occurs through products and services EULA would be one of the documents governing the content of the membership/customer-ISAO relations. | Accepted |
| 642 | Do we REALLY need to discuss office space? | Accepted |
| 676, 758, 787 | don't believe that a discussion of the different types of legal entities, shareholders vs. members, what bylaws are for, etc... belong in this document. That's business 101. If one type of legal entity or another will affect an ISAO's ability to do ISAO stuff, then discuss that. For instance, nonprofits with volunteer boards, as of now, will have an impossible time getting facility clearances from the gov't, which is a prereq. for getting personnel clearances to work with CISCP. Don't fill up the guide with advice that people are going to learn from their accountants or counsel or from an SBA webpage. | Under Review |
| 724 | The document should be very cautious about providing legal advice. This section teeters on the edge of what probably is appropriate. Also, given the talk of "liability protection" afforded to companies who share information under CISA, this section could benefit by being more clear about what type of "liability" concerns are addressed through a LLC. The way it reads currently, one can read this to mean that liability protections under CISA are easier to obtain for LLC's. | Accepted |
| 736-741 | This is way too detailed for a general guideline. The document should not be talking about tax liability issues or be giving such tax advice. Instead, we suggest the document say "here are options, consult an attorney to decide what works best for you." | Accepted |
| 842 | The capabilities offered as examples in this section aren't the types of capabilities the Capabilities WG is working on. Perhaps that needs to be discussed. Related, vetting (line 936) is not a capability by the WG's definition. | Under Review |
| 842 | Section 5.5 finally gets around to ISAO Capabilities, but then proceeds to add to the reader's confusion. You introduce three types here that are different from the three broad categories in subsection 5.1. You introduce "Basic Voluntary Capability" under the Foundational type, but no others. Perhaps there's a picture somewhere that shows all the hierarchies and relationships? | Under Review |
| 885 | When developing a "common lexicon to describe the capabilities" FireEye recommends to ensure that this lexicon is broad and flexible enough to accommodate a wide range of information sharing models and concepts and that it considers future innovation in information sharing, eg AI. | Partially Accepted |
| 885-887 | If a common lexicon is to be developed, the community, not the SO, should be developing it. | No Action Required |
| 885-931 | This conversation seems to be talking about what the ISAO SO intends to do sometime. What is its purpose in this document. | Rejected |
| 932 | Back to the definition of a Basic Voluntary Capability but I'm not sure how we got here. | Under Review |
| 932- 949 | We propose developing a limited number of defined attributes or functions of an ISAO. This will help define what an ISAO is but avoid dictating "minimum requirements" they have to implement. The ISAOs then can use the guidelines developed in this document to help them build those functions in a manner that meets the needs of their members/customers. This is consistent with the publicly stated objectives of the SO and DHS to provide ISAOs the flexibility to deploy and adjust capabilities and services as they deem appropriate to meet the unique and changing needs of their members/customers. Potential examples of the core functions might include: *They share cyber threat information with their members/customers in a trusted manner *They have established rules or agreements concerning how members can use and share information they receive *They have defined rules on how information is to be protected | Under Review |
| 932-949, 1440-1486 | In its description of ISAO Capabilities (Section 5.5), ISAO 100-1 discusses "foundational capabilities" that are "considered fundamental for most ISAOs" and defines a "Basic Voluntary Capability" for ISAOs in lines 932 - 949. The Basic Voluntary Capability could be construed as effectively minimum capability requirements for an ISAO. Among these capabilities is an analysis capability, which is described as the ability to analyze "incoming information to assess its relevance to members and implications for them." This description is subjective and will create confusion over what "assessing implications" for members means. We recommend instead simply referring to section 6.3.9, which contains a more complete description of the term. In other words, the clause should read: "Analyzing information as described in Section 6.3.9." | Accepted |
| 936 - 937 | This does not account for for profit ISAOs. Would a company providing ISAO services have to vet each one of its customers? | Partially Accepted |
| 938-940 | Enabling information sharing is the key message, but then we add it may include SARS. Why? What else might it include - why would you need to call out one example over another? | Under Review |
| 941-942 | So the capability to provide analysis services is a "basic" capability? | Under Review |
| 976 | Now we introduce "core capability areas" never really defined, but then immediately reference three "types" of capabilities. | Under Review |
| 1039 | In "other" examples of categories of ISAO FireEye recommends leaving out the reference to sharing with the U.S. government from the sentence "It may be that this group shares directly with the U.S. government in order to collect the most current cyber threat indicator information." Reference to sharing with the U.S. government could detract some organizations from being ISAO, especially those global companies that would like to operate as international or global ISAOs. | Under Review |
| 1039 | Recommend additions to the definition of "other" - Include "or are conducting research of cyber threat indicator" after "or security operations" to include threat researchers who are an integral part of cybersecurity firms. Include "in analyzing and" before "in sharing information about malware". Analysis is an integral part of development of information to be shared recognized by the title "information sharing and analysis organization" | Under Review |
| 1067 - 1068 | What "objectives?" | Accepted |
| 1079 | Suggest for readability drop 6.1.1 and 6.1.2 and just make bullets under 6.1 | Accepted |
| 1113-1117 | Is this part of 6.1.2, or is it summarizing 6.1? | Accepted |
| 1114 - 1115 | Again, while acknowledging this is fine work, other vendors have issued similar reports. It is important that the SO not appear to be endorsing any specific product or work of a specific company. | No Action Taken |
| 1120 | Be careful we don't confuse the ISAO's value prop defined earlier, with just information sharing's value prop. Watch for consistency. | Under Review |
| 1150-1151 | suggest that this final sentence be deleted or edited to read: "Any changes made should be done consistent with the organization's governing documents." Perhaps an organization's governing documents enables Board of Directors to make the changes without | Accepted |
| 1156 | Remove "should" and rephrase as "Using consistent standardized frameworks and data formats helps facilitate these diverse cross organization information exchanges." | Accepted |
| 1161-1185 | The STIX discussion seems out of place, but it's important to define because it's later used in the document. Maybe you could have a simple paragraph indicating "For reference in this document we will adhere to the STIX definitions." Then move the STIX definition stuff to a side bar or appendix. | Under Review |
| 1187 - 1188 | Change should to "May want to consider" or something similar. | Rejected |
| 1197 - 1199 | Here's the word "should" again... There are other ways to ensure an ISAO understands the needs and capabilities of its members. | Accepted |
| 1202 | Same with last comment - might want to reference the STIX definitions in an appendix. | Under Review |
| 1288-1328 | The reference to the Verizon DBIR should be accompanied by a short discussion of the VERIS framework for collecting, recording, and sharing incident information, with an appropriate reference (e.g., http://veriscommunity.net/). Also, there is no reference to NIST 800-150 Second Draft (Guide to Cyber Threat Information Sharing) anywhere within the ISAO guidelines, which seems like a major oversight. | Under Review |
| 1325 | Curious as to why this specific vendor report is called out. Other companies provide threat reports based on incidents as well. So does the government. If we are to give an example of such a report, it should be of work product of DHS so as to not appear to provide recognition/endorsement of one vendor and its work over others. | Rejected |
| 1346 | Does indicator sharing really "tend to focus" on machine-to-machine? Maybe reword to indicator sharing is more efficient through M2M? It's important to get indicators shared whether H2H or M2M, so you don't want to imply you have to have an M2M capability. | Accepted |
| 1346 - 1355 | Recognizing the momentum of STIX and TAXII, it's also appropriate to note that there are other automated languages available and in use. | Accepted |
| 1421 | Seems out of place - analysis is more of a service than a category. Could stand on its own as a 6.4? | Under Review |
| 1427 | Insert "may" or "can" after "analysis" and before "find." | Accepted |
| 1447 | Replace "should" with "may" or "can." | Accepted |
| 1503 - 1504 | There are a lot of companies and organizations that issue advisories. Some ISAOs issue public advisories, some issue them only to members. To avoid the appearance of favoring or endorsing one over the other, why not use as an example a public DHS advisory? | Accepted |
| 1507 | Instead of "Best Practices" suggest using the term "Effective Mitigation Strategies" since "Best Practices" implies a method was used to determine that one practice is better than another. Whereas "Effective Mitigation Strategies" implies the sharing of techniques that were known to have worked, even if they have not been formally catalogued, captured or identified as a "Best Practice." | Under Review |
| 1520-1557 | This list doesn't correspond to the subsection heading of Best Practices. Need to fill out the best practices. Then this list might make more sense in the 6.3 introduction. | Accepted |
| 1560 | Delete "At this point." | Accepted |
| 1561 | context depicted above should be better defined | Accepted |
| 1600 - 1692 | Overall, this is good content. However, it can benefit from context that clarifies not all ISAOs are expected to have these capabilities and perhaps this is most relevant for for profit companies providing ISAO services or ISAOs with significant resources. | Accepted |
| 1641-1671 | This is perhaps the best example in the whole document of language that is over complicated.. I can't fathom who would find this information useful. This is a massive over-complication of what could be straight-forward information. It's indecipherable to anyone but statisticians. | Partially Accepted |
| 1700 | Replace "should" with "may want to" or something similar. | Accepted |
| 1749 - 1750 | Unless they are the only one with this capability, which they are not, there is no reason to mention only them since it is not a capability unique to them. There are several ISACs that do automated sharing and we must be fair to everyone. Either the document contains need a complete list, it doesn't list any. | Accepted |
| 1899-1937, 2213-2233 | While ISAO 100-1 acknowledges the variety of ways in which an ISAO can facilitate the sharing of threat information data in section 7.3 and Table 2- Sharing Mechanisms to Consider, language in section 10.1 of the document suggests that a "secure web portal" is a "basic security component" of an ISAO (see lines 2213-2233). While a secure web portal that facilitates communications can be a valuable capability, we do not believe that this capability to be a "basic security component" of an ISAO. In our experience, many ISAOs start out by utilizing a secure listserv, secure conference calls, and other information sharing mechanisms in order to disseminate and discuss relevant threat information data. While many ISAOs may eventually adopt a secure web portal for communications, this is not, in our view, a "basic security component" of an ISAO and should not be considered an ISAO requirement. | Partially Accepted |
| 1933 | Typographical errors in the table: "In persons meetings", "wirh encrypted message", "SMIME" (instead of "S/MIME") | Accepted |
| 1941 | Remove the word "must" and re-word so that it reads: The trusted relationships essential to an effective ISAO are best achieved when organizations embrace a culture of operational security among its members, partners, and those with whom they share information. | Accepted |
| 1945 | Remove the word "should" and replace with "may." | Rejected |
| 1956 - 1957 | ... shall be documented and be a condition for participation in an ISAO. This language is way too prescriptive. It's not for this document to set conditions of membership on ISAOs. Some organizations have long established personal trust relationships and may not have documented their information sharing rules, but everyone understands and agrees to them. The word "shall" implies that these organizations must now change their trust model or not be an ISAO. While our organization operates with a common agreement among all members, we also know of several long standing and highly successful models that do not. The document should account for these. | Accepted |
| 1966 - 1967 | Not all ISACs use TLP and TLP certainly has its limitations. It might be appropriate to identify TLP as one possible framework to be considered, but it should be noted that the TLP may not meet the needs of all ISAOs. For for profit, single company ISAOs, it might also be worth noting that a EULA would be another example of a system that defines appropriate use of information. | Rejected |
| 1973 | Shall ensure This is term is not at all appropriate for a voluntary guideline. | Accepted |
| 1977 - 1978 | Change "should"; to "can"; or "may." | Under Review |
| 1993 | Suggest that this final sentence be deleted or edited to read: "Any changes made should be done consistent with the organization's governing documents." Perhaps an organization's governing documents enables Board of Directors to make the changes without the need for member vetting. In the case of a single company ISAO, that company does not need its customers to vet the changes. For these reasons and others, we suggest the more general language proposed, rather than the more directive language in the current document. | Accepted |
| 2009 - 2010 | Delete "must"; (unless there is a specific law that requires this, in which case it should be cited) and re-word to the following: "Before sharing cyber threat indicators, it is important to consider the privacy implications of what is being shared, including..." | Accepted |
| 2013 - 2014 | This can benefit from some clarity--to attain the liability protections under CISA, it is ok to have this information, but only if it is part of a cyber threat indicator. But what if an organization is not interested in the liability protection? Are thy violating any federal or state privacy laws by passing along indicators that contain PII that are not part of a cyber indicator? | Accepted |
| 2020 | The ISAOs must limit the impact of the data they collect on individual privacy. The use of the word "must"-- Is this a specific legal requirement? If so, where can one find more information? | Rejected |
| 2022 | This is not the norm, so the sentence would benefit from beginning with the qualifier "In some rare cases" | Accepted |
| 2028 - 2034 | General comment on this section--It is highly unlikely companies will be sharing information that is part of Sarbanes-Oxley or HIPPA. Therefore, perhaps this section can be simplified and benefit from a statement to the effect of "To the extent possible, it is a sound policy for ISAOs to share and receive only cyber threat indicators. ISAOs may want to establish policies against sharing PII or other sensitive data not related to cyber threat indicators. However, ISAOs may also be subject to HIPPA, PCI or other regulations on data they hold or store. For example, an ISAO that collects credit card payments is subject to PCI requirements and employee health records are covered under HIPPA regulations. Therefore, it is important for ISAOs that store or collect this information to understand their obligations under the appropriate regulations." As it currently reads, it appears that all ISAOs are responsible for understanding every privacy regulation that exists. | Partially Accepted |
| 2040 2042 | The word "should" again. Please delete and replace with "may want to establish policies ..." Also, this section is confusing. It is our understanding that under CISA it is OK to collect PII as long as it is part of a Cyber Threat Indicator. This section seems to read that PII should not be collected even if it is part of an indicator. | Partially Accepted |
| 2043 | This section can benefit from an introduction ... Core principles of what for who? | Accepted |
| 2109 - 2123 | This section might be made more effective if it stated more simply that DHS has instituted privacy controls for sharing with it through the AIS program. For example, "It is important for organizations interested in participating in that program to understand those controls, which are available here: . . . . Further, DHS, DoJ and DoD have issued guidance on steps organizations must take to attain liability protection under CISA. That guidance is available here: ..." | Accepted |
| 2207 - 2211 | The resources listed under Privacy Framework Catalogue-- is this an all inclusive list of privacy resources? The privacy section lists HIPPA, Sarbanes-Oxley, PCI among others, but there are no resources listed for those regulations. Also, the work listed under HITRUST is good, but some of it also is aspirational or ongoing. We suggest that the document only list completed work. | Under Review |
| 2214 | 2215-2233 discussion doesn't match header of "Secure Web Portal..." | Accepted |
| 2234 | 2235-2244 discussion does not explain header topic very well | Partially Accepted |
| 2280 | I think the ISAO SO should strongly recommend use of TLP since it's widely accepted in ISACS and government already, so why mention "or other classification schemes"? Also, do you want to mention "Red/Amber/Green/White"? And suggest put TLP definitions in an appendix. Also, for the 10.1.2 section, may include a sample labeling scheme. NRF leveraged the FS-ISAC's and I believe the R-CISC is using the same. For example, use an alert type indicator (CYT = Cyber Threat) followed by a criticality number (1-10). Just a thought - why provide the example so that if all ISAOs are communicating with a common label, information could flow faster. | Rejected |
| 2294 - 2295 | What is the meaning of this "Note" and how does it relate to the security and privacy content contained in the draft? Will discussions on these topics continue separate from the current development process/work streams? What are these "companion groups?" | Accepted |
| 2364 | The checklist concept is confusing. Will the SO provide a checklist to ISAOs that they need to complete as a means of demonstrating they are an ISAO, or is this a checklist the SO will use to standardize its relationship with the ISAO? | Partially Accepted |
| 2372 | What is the purpose of the "Note"; regarding the DHS AIS data retention policy. Is the suggestion that all ISAOs should use the DHS policy? While a reference to those policies is appropriate, ISAOs should maintain the flexibility to institute policies that meet their needs. | No Action Taken |
| 2398 | Recommend replacing the definition of "analysis" by the following: A review of host and network data to identify malicious activity and an assessment of the identified malicious activity to existing threat information to say something greater about the data at hand. This will ensure that the definition of analysis reflects accurately the description of the process of "information analysis" in section 6.4.1. | Under Review |
| 2419 | Recommend adding "includes hardware and software vulnerabilities, courses of action, and warnings" as examples of cybersecurity information after "data-related risks and practices. | Accepted |
| 2415 | Recommend adding "host and network indicators" and "tools" to the list of information regarding the adversary to better reflect the scale of information that are relevant to gather on an adversary and necessary for proper analysis. | Under Review |
| 2493 - 2527 | We made the suggestion before, but in terms of cyber incident response resources, the Forum of Incident Response and Security Teams (FIRST) created a SIRT framework for security incident response teams: https://www.first.org/global/education. This could be a good reference for developing ISAOs. | Partially Accepted |
