Contributing to a Community or Source

Last Updated: Nov 01, 2018 05:52PM EDT
Sharing Administrator

Overview

When contributing a Group to a Community or Source, a copy of the Group is added to that Community or Source. This copy is a separate Group, and any modifications to it will not affect the original Group. When contributing a Group, copies of the Tags, Attributes, and associated Indicators and Groups are also created (depending on the security settings selected; see the “Group Hierarchy and Association Directionality” section at the end of this article for details on which associated Groups are copied with a contributed Group). ThreatConnect® also allows the user to contribute a Group to multiple Communities or Sources. Groups may be shared between Communities or contributed from an Organization to a Community. For data in an Organization, but not in a Community or Source, contribution of the data to a Community or Source is a prerequisite for sharing intelligence across ThreatConnect instances via the Publish feature. See The Publish Feature for more information.

Steps

  1. From the top navigation bar (Figure 1), place the cursor over BROWSE and then over the GROUPS option. Click on one of the objects (E-MAIL in this example) to display a results table (Figure 2).
  2. Click on one of the entries, and the Details flyout for that entry will appear (Figure 3).
  3. Click the Details  icon at the top right of the flyout, and the Overview screen will appear (Figure 4). Alternatively, hover over the object's entry in the table in Figure 2 and click on the Details icon that appears on the right side of its Summary cell to go straight to the Overview tab of the Details screen.
  4. Click the Sharing tab, and the Sharing screen will appear (Figure 5).
  5. Click the CONTRIBUTE TO COMMUNITY/SOURCE... button, and the Contribute to Community/Source dialog box will open (Figure 6).
  6. Select the Community with which to share the selected Group. If the Group is shared with the Common Community, then all Organizations will have access to the Group. If the Group is copied to any other Community, then only Organizations with access to that Community will be able to access the Group.
    • If merging with an existing Group, select EXISTING GROUP and enter the Group Name in the text box, which will auto-populate with available possibilities after three characters have been entered.
    • If creating a new Group, select NEW GROUP and enter the new Group's name.
  7. Click the NEXT button. The Data screen, with options for Attributes, Tags, and Groups, will appear (Figure 7).
  8. Select the appropriate options:
    • Copy Attributes? Select Yes to copy the Group's Attributes.
    • Include Tags? Select Yes to associate all Tags from the existing Group with those of the new Group.
    • Create Tags That Don't Exist? Select Yes to create any Tags that do not already exist.
    • Copy Associated Groups? Select Yes to copy associated Groups to the Community. A selection of Group types is listed below this option. Select the Group types to copy. See the “Group Hierarchy and Association Directionality” section later in this article for more information about which Groups associated to associated Groups will be copied.
  9. Click the Next button, and the Security Labels screen will appear with the Exclude radio button selected by default (Figure 8). If the Exclude button remains selected, then the Choose Security Labels dropdown menu is used to select the Security Labels that will determine exclusion for associated Indicators, Groups, and Attributes, where objects with any of the selected Security Labels will be excluded. Selecting the Include radio button causes the Choose Security Labels dropdown menu to be used to select the Security Labels that will determine inclusion for associated Indicators, Groups, and Attributes, where objects with at least one of the selected Security Labels will be included.
  10. By default, the Copy System-level Security Labels radio button at the bottom of the window will be selected, which will cause only System-level Security Labels that are assigned to associated objects to be copied. Clicking the Choose Security Labels to apply to copied data: radio button will cause three dropdown menus to appear (Figure 9). Use these menus to select Security Labels from the Community to apply to the Group being contributed and its associated objects.
  11. Click the Next button, and the Save screen will appear (Figure 10).
  12. If desired, change the Suppress Notifications? radio button selection to disable notification messages about the contribution to members of the Community. Select the Publish after Copy checkbox to publish the data in a package so it may be shared across instances. (See The Publish Feature for more information.) Click the SAVE button to copy the Group to the selected Community.
  13. The Sharing tab of the Details screen for the Group will now show all Communities/Sources from which and to which the Group has been contributed (Figure 11).
  14. Click the Details icon to see a summary of the options chosen for the Group’s contribution (Figure 12).

To contribute to multiple Communities or Sources, click the CONTRIBUTE TO MULTIPLE... button (Figure 5), and follow Steps 5–12. Note that this option will not allow a user to click on the EXISTING GROUP radio button (Figure 6). A NEW GROUP must be created.

Group Hierarchy and Association Directionality

Groups in ThreatConnect are related to each other according to the hierarchy in Figure 13, where the topmost Group (Report) is a superset that can contain all of the Groups “below” it, the next group down (Threat) is a superset that can contain all of the Groups “below” it (i.e., all of the Groups except itself and Report), and so on. Or, starting from the bottom of the list, a Document can contain only itself; a Signature can contain a Document; an Email can contain a Signature and a Document; an Event can contain an Email, a Signature, and a Document; and so on. The hierarchy is like a Russian nesting doll, where Document is the smallest doll and fits inside the Signature doll, which fits inside the Email doll, which fits inside the Event doll, and so on.

This hierarchy is based on the definition of each Group and the way each Group can contain or be contained by other Groups. For example, a Document can be included in a Signature, but a Signature cannot be included inside a Document. An Adversary can be a component of an Intrusion Set, but an Intrusion Set is a “greater” structure and thus cannot be part of an Adversary. A Campaign is a collection of Incidents, and therefore it can contain Incidents, but an Incident cannot contain a Campaign. An Email can contain a Signature and a Document inside of it, but neither a Signature or a Document could have an Email as a component. An Email can be one of the components that are grouped together into an Event, but it would not make sense to say that an Event is a part of an Email.

When contributing a Group to a Community or Source, Groups that are associated directly to that Group (i.e., one degree of association from the original Group) also get contributed if the Yes button for the Copy Associated Groups? question in Figure 7 has been selected and if the checkbox for the type of Group has been selected. However, Groups that are associated to the associated Groups (i.e., two or more degrees of association from the original Group) get contributed only if the association traverses up or down the hierarchy in the same direction as the association between the original Group and the associated Group. Also, a horizontal traversal (i.e., from one kind of Group to the same kind of Group, such as a Signature associated with another Signature) would get contributed regardless of the prior direction of traversal.

For example, say the Group being contributed is an Event that is associated to an Incident. The Incident, being directly associated to the Event (one degree), will be contributed along with the Incident. If the Incident is associated with an Adversary, the Adversary will also get contributed, because the chain of association began by traveling “up” the hierarchy (i.e., from Event to Incident) and continued “up” the hierarchy (i.e., from Incident to Adversary). However, if the Incident is also associated with a Signature, that Signature will not be contributed with the Email, because the initial association traveled “up” the hierarchy (i.e., from Event to Incident), but then traveled “down” the hierarchy (from Incident to Signature). This situation is illustrated in Figure 14, where the dashed arrow indicates a contribution that will not happen.

As another example, if the Group being contributed is a Campaign that is associated with an Adversary, a Threat that is associated with the Adversary will be contributed as well, because the chain of association from Campaign to Adversary to Threat is uniformly in the “up” direction. However, a different Campaign associated with the Adversary will not be contributed, because the chain of association from Campaign to Adversary to Campaign goes “up” and then “down.” Similarly, if a Signature is associated with the original Campaign, both the Signature and a Document associated to the Signature will be contributed with the Campaign, because the chain of association from Campaign to Signature to Document goes uniformly “down,” whereas an Email associated to the Signature will not be contributed, because the chain of association from Campaign to Signature to Email goes “down” and then “up.” This situation is illustrated in Figure 15.

As a final example, consider a Signature that is associated with a Campaign. If the Campaign (“Campaign 1”) is associated with another Campaign (“Campaign 2”), which is associated with an Adversary and an Incident, then when the Signature is contributed to a Community or Source, Campaign 1, Campaign 2, and the Adversary will be contributed as well, because the directionality of association is universally “up” or, in the case of the two Campaigns, horizontal, but the Incident would not be contributed, because the directionality initially goes “up” (from the Signature to the first Campaign), horizontal (from Campaign 1 to Campaign 2), and then “down” (from Campaign 2 to the Incident). This situation is illustrated in Figure 16.

NOTE: The reason for this methodology is that traversal along the hierarchy in one direction and then in the other direction means that you are likely to encounter a separate chain of association not related to the original Group. For example, consider the scenario in Figure 14. The Email is a part of the Incident, which in turn is a component of the Adversary. But the Signature associated with the Incident may have nothing to do with the Email. The Signature may be associated with an Email, but there is no evidence that it is associated with the Email being contributed, and so including it as part of the contribution would mean that extraneous, unrelated data are being passed with the contribution. In the Russian nesting doll analogy, it is as if the Incident doll has two separate dolls—Email and Signature—rattling around inside of it. The presence of both of them inside the Incident doll does not mean they are related to each other.

20001-09 EN Rev. B

Contact Us

  • ThreatConnect, Inc.
    3865 Wilson Blvd.
    Suite 550
    Arlington, VA 22203

    Toll Free:   1.800.965.2708
    Local: +1.703.229.4240
    Fax +1.703.229.4489

    Email Us



https://cdn.desk.com/
false
desk
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
false
Invalid characters found
/customer/en/portal/articles/autocomplete