Request For Comment
The request for comment period for this draft concluded on Thursday, May 3. All comments are currently under review and adjudication by working groups. Comments received after the May 3rd deadline are welcomed and may be included in future adjudication and revision periods.
The purpose of analysis is to produce intelligence that decreases uncertainty in decision making and therefore reduces risk. This document provides an introduction to the information analysis process and how an Information Sharing and Analysis Organization (ISAO) can use it to identify, define, and mitigate cyber-security threats. It is the authors’ intent to provide organizations a general understanding of the tools and processes needed for an analysis team to create cybersecurity information and intelligence within their ISAOs.
This document establishes a conceptual framework for an analytical process, including establishing information and intelligence requirements as well as collecting, processing, analyzing, and exploiting relevant data to generate products that provide ISAO members with cybersecurity situational awareness. The objective of sharing cybersecurity analysis is to provide ISAOs with actionable information, reduce uncertainty, and thereby reduce risk to enable decision makers. As a technical overview, this document is meant to foster discussion on both a managerial and an operational level.
Submitted Comments
The ISAO SO invited the public to provide comments on this document from April 3, 2018 – May 3, 2018. Both fields listed below (line number and comment) are the exact contents as submitted by the commenter.
| Line Reference | Comment | SO Disposition |
|---|---|---|
| 99 | This section seems largely focused on enterprises and not ISAOs. Not sure as to what the link here is for ISAO analysis, which is based on member requirements. | No Action Required |
| 100-111 | All this is fine, but does not add any real value. It can easily be eliminated with any impact to the meaning of this section. | No Action Required |
| 158 | Should we be more specific to what an "analytics community" is? Is this community members or your organization or outside your membership? | Accepted |
| 178-189 | Agree that this collaborative analysis model is a value of ISAOs (a point made in other ISAO SO work), but this doesn't provide the reader any guidance on how to do collaborative analysis. | No Action Required |
| 209-213 | Actually, this concept goes back a lot longer than this. The ISACs were the first to implement this model | No Action Required |
| 214-221 | Yes, CISA can be a force for good, but how is this helping the reader do analysis? | No Action Required |
| 225 | Overall Comment--Section 3 can be eliminated since the value prop of ISAOs is discussed in other SO documents. Or it can reference the established content in public ISAO documents. | No Action Required |
| 232 | We need to avoid giving the perception that this is the intelligence cycle. Maybe say "An Intelligence Cycle" or "Intelligence Cycle Example" so as to make clear what is being shown is not a requirement for ISAOs to follow. | Accepted |
| 258 | This seems to be focused on internal reporting and information requests, as opposed to sharing across or through an ISAO. The reporting requirements section does not seem at all applicable to the ISAO construct. For example, it is likely that no ISAO will have a requirement that members report CVMs with potential impact to the ISAO within 2 hours of publication. | No Action Required |
| Table 1 Column 3 label | There is no "requirement" to report any thing to an ISAO/ISAC. | No Action Required |
| Table 1 Column 1 Line 1 | Not convinced that this is a poor information requirement for an ISAO. They may hear reports that PII has been lost, and will want to know if it is true. If true, they then can issue additional requests specific to the incident. | No Action Required |
| Table 1 Column 1 Line 2 | I am not convinced this is a poor information requirement. An ISAO might be less interested in understanding what CVMs members have not been assessed and more interested in understanding the impacts on its members. | No Action Required |
| Table 1 Column 2 Line 2 | While this is important from an individual company perspective--I can see how a CISO would want to know this for his or her enterprise--from our experience, this is not the information an ISAO would generally seek or collect across its membership. | No Action Required |
| Table 1 Column 3 line 3 | We are all for sharing, but we need to be careful to not give the impression to the reader that they are required or expected to share. There is no requirement to share and every company sets its own policies. | No Action Required |
| 266 | Change to should or "consider giving low priority to . . ." Words such as "will" and "require" should be used sparingly and with caution lest the document become viewed as prescriptive. | Accepted |
| 289 | Suggest using the word "needs" instead of requirements. Understanding "Intelligence Requirements" has its own meaning (do we define the term in the document?) ISAOs and ISACs generally use the term "member needs." Using the term member needs also re-enforces the notion that ISAOs and ISACs are driven by member needs, rather than outside third party | Accepted |
| 296 | is instead of "are" | Accepted |
| 306 | this instead of "these" | Accepted |
| 308 | The topics covered in this section are already covered in more detail in other ISAO documents. Instead of creating new content on the same issue, can we please reference the existing ISAO work? ISAO 300-1 covers all this ground. | Rejected |
| 309 | There are actually two challenges. Understanding member needs and then identifying the right data sources. | Accepted |
| 311 | In some cases it's limitless and in other cases it is hard to come by. | No Action Required |
| 315 | Not necessarily so. Most ISACs and ISAOs do not have members SIEM data. | No Action Required |
| 317 | the word "needs" is a better fit. | Accepted |
| 318 | Should read as, "it is also important" | No Action Required |
| 333 | ISAO 300-1 has a much more extensive discussion about the type of data, which we would be better off referencing | Accepted |
| 381-384 | This again is a section that has been covered elsewhere. Understanding TLP is widely used, we must also note that it has problems and may not fit the needs of the sharing or receiving organization. Instead of focusing on a specific solution, what are the criteria of an effective dissemination and disclosure framework? Or delete this section and refer to existing | Under Review |
| 392-402 | This likely is good advice for enterprises, but establishing a baseline network survey does not work for an ISAO. The goal is to get members to share information with the ISAO. Maybe this needs to be re-worded to note that ISAO members need to have a baseline understanding so that they know what to share with an ISAO? But even that might not be right since what a member shares depends on what other members' needs are/what the members agree to share. | Under Review |
| 403 | I think this presumes a specific model. Most ISAOs that I know of do not require or ask members to share specific data sets to the ISAO, which likely would not have the capacity to go through all the data. Instead, members share "data" as needed to assist in the analysis of a specific incident. Members generally report incidents and data on that incident and members collaborate on analysis. | Under Review |
| 422-423 | This is not true. ISAOs don't have to analyze any network data, but can simply share open source information. They can share whatever their members want. | No Action Required |
| 437-439 | Well, it depends. This is one function an ISAO can provide, but an ISAO can provide other functions that may be less complex but nonetheless valuable to its members. | No Action Required |
| 451-453 | Of course what members contribute depends on the goals, purpose, mission and policies of the ISAO. They may want to share open source news articles, analytical reports (rather than indicators), industry or global threat trends. Not all ISAOs will be focused on cyber threat sharing or indicator sharing. | No Action Required |
| 470-471 | Not related to this point specifically but as a general matter, ISAOs/ISACs should be careful making any definitive recommendations to members. Each member company has a different architecture and unique attributes that ISAO staff are not likely to be aware of. In many caes, providing the data may be enough and then letting the member organization come up with their own conclusion. | No Action Required |
| 478 | While VT may be a good choice for a free tool, there are other open-source resources in addition to VT. I would recommend removing to avoid any appearance of promotion or endorsement. | Accepted |
| 489-490 | We we should not tell ISAOs how they should be spending theire money. An ISAO spending model is designed to meet the goal of its members and its business model. | Accepted |
| 498 | What would be an example of a negative result here? | No Action Required |
| 503-505 | Suggest we instead recommend that ISAOs create policies that relate to archiving, storing and securing their findings or refer to the guidance in ISAO 300-1. | No Action Required |
| 513 | I can envision circumstances in which a submitter would not object to being identified. So, instead of making a blanket statement to not contain identifying markers related to the submitter, perhaps we add the qualifier "for submitters requesting non attribution, . . . " or "any attribution should be don in accordance with established ISAC/ISAO policies. | No Action Required |
| 516-519 | Under this scenario, wouldn't the submitter be identifying the IOCs, TTPs, scope, severity and impact to the ISAO? The ISAO can't determine that for the submitter or for other ISAO members. | Under Review |
| 523 | This gets to the point we made earlier about an ISAO providing recommendations. Of course an ISAO has a right to do so, but there are risks in doing this as well. An ISAO needs to develop its own policies regarding issuing recommendations. | Accepted |
| 527-535 | How is this Analysis? This is mitigation, and going through a set of potential responses to multiple hypothetical incidents strays away from the Analysis focus of the paper, | No Action Required |
| 565 | This is pretty prescriptive. Why don't we be more consistent with previous ISAO work products and say ISAOs should consider establishing policies for storing, securing, and accessing finished products | No Action Required |
| 571-574 | Considering most ISAOs will use open source reporting, additional guidance on how to "drink from the firehouse" might help. Unless 7.6 and 7.7 are designed to do this, in which case the numbers "7.6" and '7.7" should be deleted since the content is related to section 7.5. | Rejected |
| 601-603 | How an ISAO invests its resources is up to the ISAO. We should not be telling an ISAO how they should be spending their money. | No Action Required |
| 610-618 | As mentioned in Line 620, if none of the tools are endorsed or recommended, we would ask for this to be removed. If we mention a few examples, who chooses the examples? There are many other options available so we would recommend removing the bullet points and beginning on line 619. Listing individual vendors or products give the appearance of an endorsement of the product or service from the ISAO SO. | No Action Required |
| 620-622 | Appreciate the inclusion of this language, but unless we list them all, we should not list any. Is there a place or a report we can refer to people to for more information about TIPs? | No Action Required |
| 623 | There is no requirement that an ISAO must use such a platform. What about an ISAO that wants to share incidents on physical security? What about an ISAO that wants to share only open source news? | No Action Required |
| 624-625 | This is interesting. Some of our members insist on APIs, some members want STIX/TAXII, others want UI. The solution an ISAO chooses should be determined by the needs of the members. Also, some vendors charge ISAO members for API connections, which may not fit into an ISAO's operating model. | No Action Required |
| 626 | Not really--if you are spending money on resources your members can't use or leverage or don't want. | No Action Required |
| 628-629 | Well, it could be very important, if that's what your members want. If your at that capability, then it's not at all important. | No Action Required |
| 630 | How is "Data Storage" related to Analysis? | No Action Required |
| 646 | The skill set depends on how the analyst will be used within the ISAO. For example, an ISAO can prioritize the ability of an analyst to lead collaboration with members, but that's not listed here. The required skill set and qualifications is dependent on how the person is being used. Also, I am not at all comfortable proposing employment guidance or practices for an ISAO. If we are to discuss skill sets and expertise, it might be better to discuss some certifications associated with potentially qualified analysts. | Rejected |
| 825 | Please avoid using words such as "must" in a document that provides guidance and practices. Also this section should account for the real possibility that many ISAOs will have success sharing information among members in calls, meetings and webinars. | No Action Required |
| 830-839 | Security and privacy isuses are dealt pretty comprehensively in Section 10 of ISAO 300-1. Instead of creating new content on a topic that has already been covered and that is not related to "Analysis", we suggest this document refer back to the practices in ISAO 300-1 | No Action Required |
| 855-856 | Section 5 of ISAO 300-1 lists a whole set of considerations for ISAOs for establishing policies on how to share information with and among ISAOs. Instead of saying "use encryption" as this section does, we again suggest referencing the work of ISA0 300-1, which the ISAO SO has already completed. | No Action Required |
| 857-858 | There is no "requirement" for a member to share anything with an ISAO, let alone "a detailed sensitive report." We need to be careful with language and not be perceived as prescriptive or to create requirements on ISAOs or their members. | No Action Required |
| 862 | Same points as previous segments. It is unclear why a document on "Analysis" is telling ISAOs how to secure information when previous ISAO work products already provide guidance to ISAOs. | No Action Required |
| 914-918 | Again we're covering content the ISAO SO covers elsewhere. For example, Section 10 of ISAO 300-1 emphasizes the need for ISAOs to develop security plans as they form the ISAO that reflects the ISAO's business and member needs. | No Action Required |
| 924 | Are these definitions pulled from a common source or a set of common sources? If so, we probably should cite. Consistent with previous comments, we should use existing work where it is available. | Under Review |
