ISAO 100-1 Guidelines for Establishing an ISAO v0.1

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.

Download This Draft Document
Having trouble viewing this document?

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 ReferenceCommentDisposition
GeneralIn 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
GeneralWe 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: This could be a good reference for developing ISAOs.Under Review
General CommentWe 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 StatementUnless 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 2Section 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 3Section 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.1Section 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.1Section 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.2Section 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.3Section 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.3Section 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.3Section 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.3Section 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.4Section 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.1Section 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.2Section 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 431Section 5.4.2 - line 431 - perhaps transparency must not be supported. How would anonymity be supported?Accepted
Section 5.4.2 - line 435Section 5.4.2 - line 435 - what about by sector?Accepted
Section 5.4.3Section 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" headingUnder Review
Section 5.4.6Section 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.6Sections 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 900Section 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 1006Section 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.7Section 5.7 - This section can probably be deleted. Under Review
Section 6.3.11 - Lines 1511 - 1557Section 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 - 1770Section 6.4.3 - lines 1764 - 1770 are duplicative of the earlier explanations of these three categories of information. This can be deleted.Accepted
Section 9Section 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. and Accepted
Section 11.1 - Delete lines 2344 - 2356Section 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.2Section 11.2 - add reference to each supporting function to allow readers to find more information about each.No Action Required
Section 13try to cite other sources for the definitions. Partially Accepted
14computer security seems to date the document to the 60's. Isn't it really more about "data security"?Rejected
38In 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
38Not sure what is meant by "various levels of organizations within ISAOs" and its relevance to the paragraph's pointAccepted
Line 39The 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-47While 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-56Is 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-93The 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-120Since 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
121General 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
124We 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, 128What is "fully capable"? Where even is the list of "capabilities"? What are the "services"?Partially Accepted
128Recommend 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-131Similar 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
133Recommend 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-141This 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
151Is the value prop a capability? This might flow better as subsection 4.1 under the definition of an ISAO.Under Review
154-169The 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
157ISAOs will make to "ISAOs that will assist in making"Under Review
163Recommend 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
170For readability, suggest moving under section 4 as subsection 4.2 (assuming previous comment is accepted).Under Review
225-337, 1522-1557As 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-1557a. 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
338How is "Creating an ISAO" a capability - suggest moving under Section 4 as subsection 4.3.Under Review
338-1065In 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
375Recommend 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
412This 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
447This 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
447Recommend 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-483Generally, 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-542This 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
553We 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
596Error in the PDF document: "Error! Not a valid bookmark self-reference." The "Figure 1" referenced for funding models is not present.Under Review
596Obvious "Error" Message needs to be corrected.Under Review
612Suggest highlight funding models as examples only - there are others.Accepted
612-613The 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
628Recommend 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
642Do 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
724The 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-741This 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
842The 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
842Section 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
885When 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-887If a common lexicon is to be developed, the community, not the SO, should be developing it.No Action Required
885-931This conversation seems to be talking about what the ISAO SO intends to do sometime. What is its purpose in this document.Rejected
932Back to the definition of a Basic Voluntary Capability but I'm not sure how we got here.Under Review
932- 949We 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 protectedUnder Review
932-949, 1440-1486In 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 - 937This does not account for for profit ISAOs. Would a company providing ISAO services have to vet each one of its customers?Partially Accepted
938-940Enabling 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-942So the capability to provide analysis services is a "basic" capability?Under Review
976Now we introduce "core capability areas" never really defined, but then immediately reference three "types" of capabilities.Under Review
1039In "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
1039Recommend 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 - 1068What "objectives?"Accepted
1079Suggest for readability drop 6.1.1 and 6.1.2 and just make bullets under 6.1Accepted
1113-1117Is this part of 6.1.2, or is it summarizing 6.1?Accepted
1114 - 1115Again, 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
1120Be 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-1151suggest 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 withoutAccepted
1156Remove "should" and rephrase as "Using consistent standardized frameworks and data formats helps facilitate these diverse cross organization information exchanges."Accepted
1161-1185The 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 - 1188Change should to "May want to consider" or something similar.Rejected
1197 - 1199Here's the word "should" again... There are other ways to ensure an ISAO understands the needs and capabilities of its members. Accepted
1202Same with last comment - might want to reference the STIX definitions in an appendix.Under Review
1288-1328The 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., 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
1325Curious 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
1346Does 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 - 1355Recognizing the momentum of STIX and TAXII, it's also appropriate to note that there are other automated languages available and in use.Accepted
1421Seems out of place - analysis is more of a service than a category. Could stand on its own as a 6.4?Under Review
1427Insert "may" or "can" after "analysis" and before "find."Accepted
1447Replace "should" with "may" or "can."Accepted
1503 - 1504There 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
1507Instead 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-1557This 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
1560Delete "At this point."Accepted
1561context depicted above should be better definedAccepted
1600 - 1692Overall, 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-1671This 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
1700Replace "should" with "may want to" or something similar.Accepted
1749 - 1750Unless 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-2233While 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
1933Typographical errors in the table: "In persons meetings", "wirh encrypted message", "SMIME" (instead of "S/MIME")Accepted
1941Remove 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
1945Remove 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 - 1967Not 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
1973Shall ensure This is term is not at all appropriate for a voluntary guideline.Accepted
1977 - 1978Change "should"; to "can"; or "may."Under Review
1993Suggest 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 - 2010Delete "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 - 2014This 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
2020The 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
2022This is not the norm, so the sentence would benefit from beginning with the qualifier "In some rare cases"Accepted
2028 - 2034General 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 2042The 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
2043This section can benefit from an introduction ... Core principles of what for who?Accepted
2109 - 2123This 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 - 2211The 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
22142215-2233 discussion doesn't match header of "Secure Web Portal..."Accepted
22342235-2244 discussion does not explain header topic very wellPartially Accepted
2280I 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 - 2295What 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
2364The 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
2372What 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
2398Recommend 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
2419Recommend adding "includes hardware and software vulnerabilities, courses of action, and warnings" as examples of cybersecurity information after "data-related risks and practices. Accepted
2415Recommend 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 - 2527We 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: This could be a good reference for developing ISAOs.Partially Accepted