2. Trust Groups and Trident

The concept of trust groups has its history in the efforts of computer security researchers, network operators, and expert system administrators at large sites, working together to help guide law enforcement and federal government entities and organizations like Carnegie Mellon CERT/CC, in combatting computer system and computer network compromises affecting the integrity, availability, and/or confidentiality of information and information systems.

These compromises, while sometimes innocent exploration, are none the less potentially criminal acts. At the extreme, things like massive-scale distributed denial of service (DDoS) attacks cost businesses who are disrupted tens of thousands to potentially millions of dollars in lost revenue and expenses. High profile data losses like those suffered by the likes of TJ Maxx, Sony Pictures, Target, and Saudi Aramco arguably cost in multi-million dollar range.

Those who perpetrate these crimes operate in the shadows, using pseudonyms. They cover their tracks using proxies, stepping stones on compromised hosts at innocent third-party sites, or sophisticated multi-layer distributed attack networks commonly known as botnets, often operated at bullet-proof hosting sites who are non-responsive to requests from the private sector or law enforcement to stop the abuse.

Those who try to defend against these compromises, working with law enforcement to try to bring the perpetrators into the criminal justice system. This may mean disrupting the flow of millions of dollars in ill-gotten gains from criminal acts. When someone impacts the flow of that much money, sometimes the people who are profiting get unhappy and fight back. For those reasons, trust groups are formed to try to keep the efforts to counter the criminals secret from those criminals.

2.1. Limitations to Trust

As pointed out by Raaum [Raaum(2011)] in his Master’s thesis on barriers to trust, trust does not scale well (either within a single trusted information sharing group, or across multiple trusted information sharing groups). At the Coordinating Attack Response at Internet Scale (CARIS) workshop [Internet Architecture Board(2015)] at least two interviewees used the number 100 as the approximate limit at which trust within a single group begins to noticeably decrease within the group. (The original ops-trust group from which the Trident portal grew, has many times this number of members.)

Besides Raaum, there are other studies, reports, and resources related to information sharing and trust (see [Jøsang et al.(2006a) Jøsang et al.(2006b) Demolombe(2011), Evans and Mahoney(2011)])

To establish a strong trust fabric, the Trident portal supports a rigorous vetting process workflow. This workflow depends on the members of the trust group taking the process seriously and adhering to the spirit of the process in their attestations of the trustworthiness of prospective new members. This process is covered in more depth in Section Vouching in the Vetting Process.

2.2. Trust and the Need to Know

The Need to Know is a primary and strong motivator for the sharing of highly-sensitive information for incident response. At the same time, need to know is a limiting factor on the sharing of information, since the more people who have a piece of information, the greater the chances that it loses its secrecy (in the worst case, becoming widely public).

Even in a tightly coherent trust group, not every member of the group needs to know every piece of information. The person sharing the information must decide whether the person they are sharing it with needs to know it, though some people make the assumption that being a member of the trust group by definition means they need to know it.

There are some mechanisms or tactics that are used to address need to know.

• Prior to sharing information, it can be tagged with labels defined by the Traffic Light Protocol (TLP) to indicate how to handle the information to protect it from disclosure. (See FIRST announces Traffic Light Protocol (TLP) version 1.0 and Traffic Light Protocol (TLP) Definitions and Usage.) The responsibility for handling TLP-tagged information properly then falls on the recipient. An effort to define a more rigorous information sharing protocol known as the Information Exchange Policy (IEP) - Version 1.0 is being sponsored through FIRST.
• Rather than sending information in broadcast form to the full trust group membership, limiting the number of recipients by sending to a task-specific trust group list (e.g., a “warroom” list that focuses on operations-related information about emerging threats), or by sharing directly with individuals rather than sending to generic email lists.
• For some sensitive operations, such as active investigations of criminal intrusion activity that is likely to move to criminal process, information must be tightly held. In those cases, creating a new trust group and limiting membership to just those victim sites who are involved is the right choice. For this reason, spinning up new trust groups should be very low cost, and retiring them when the incident is resolved should be just as easy.

2.3. Trust Group Formation

Trust groups are commonly formed by a group of individuals with a common goal of protecting their own networks, responding to common threats, and ideally collecting information about compromises to their computer and network assets to provide them to others (up to and including law enforcement, who may eventually bring evidence to grand juries and courts of law in the criminal process.)

Trust group formation typically goes like this:

1. Someone takes the lead and offers to form the group.
2. The leader, or someone who wants to help them, sets up an email list server.
3. The initial members populate the list and start communicating over it.
4. For the next month or two, list members send the leader suggestions for new members, or they send the suggestion to the list. The leader asks existing members if the suggested new members should be trusted, and a handful of members respond to the list (or directly to the leader) with their opinions. The leader then makes a command decision for the new members and manually adds them to the list. This takes a significant amount of the leader’s time.
5. Every now and then, someone wants a list of all of the current members, with their contact information. Not wanting to send this out in a clear-text email, the leader figures out how to encrypt an Excel spreadsheet. Then the leader sends the password (in clear text, but in a different message) to get it to the list. (This is slightly better than just sending the list in clear text.)
6. Periodically, during a crisis event in the news, someone asks for indicators or feedback about potentially malicious sites, malware, etc. They ask that the details be sent directly, not to the list (defeating somewhat the purpose of a list for sharing actionable information).
7. On a regular basis, information about upcoming meetings, events, etc., is sent to the list. Sometimes a flurry of emails occurs if the exterior door to the building is locked prior to the meeting. This creates noise on the list for those who could not attend and don’t need to know that the door is locked.
8. When a cyber exercise occurs, a flurry of exercise emails are sent to the list (that are marked something like “EXERCISE - NOT REAL!” with headlines about buildings exploding and major DDoS events taking down the power grid. Anyone who is not participating in the exercise has their inbox spammed that day and just deletes everything with the list address (loosing the announcement about the next meeting, which was hidden in the noise.)
9. At some point, members start to gripe about not having a wiki for notes, not having a secure place to upload indicators and securely store the membership list (which is now out of date and the leader needs to spend a couple hours updating it), and for only having one email list that carries all of the communication.

While this is somewhat in jest, all of these things actually do happen. The Trident portal (actually its predecessor, the ops-trust portal) was designed specifically to meet the requirements implicit in the above listed friction points. It handles the vetting and vouching workflow, supports a wiki, secure file upload storage, encrypted mailing lists, idle user detection, multi-factor authentication, and much more.

2.4. Trust Group Membership Life-cycle

Note

The Figures in this section come from the Trident Documentation page. There may be inaccuracies due to changes in the code base over time. If you notice any discrepancies, please report them (or issue a pull request) to help get them updated.

Figure Member states and what they mean shows a list of the states in which a member may exist.

• The process starts by an existing member or trust group administrator nominating a new member, giving them a user name, establishing their email address, and registering a vouch for their trustworthiness.
• Current members of the trust group are notified of the nomination and are then able to vouch for the person themselves. Anyone wishing to register a private concern over the trustworthiness of the person can contact a trust group or system administrator to let them know about the concern.
• When a sufficient number of positive vouches is registered, the person reaches the approved state and a system password is prepared for secure transmission to the new user to allow them to log in to the portal and complete their account profile.
• Once the new user’s profile is complete, their GPG/PGP key is uploaded, and they have registered some vouches themselves to help grow the bi-directional trust network, their account becomes active and they begin to receive emails for lists to which they are subscribed.

Other states are reached when users are idle, are blocked because of some serious breach of trust (for example, they are arrested for suspicion of a crime), or they did not receive enough vouches to become active in the first place. The table in Figure Member state transitions describes these state transitions.

Member state transitions

Member states and what they mean

The table in Figure Permissions in each state shows what permissions apply to a user account in a given state. The table in Figure Permissions descriptions details those permissions.

Permissions in each state

Permissions descriptions