Skip to content

Threat Model

Jump to bottom
aagbsn edited this page Oct 12, 2013 · 2 revisions

OONI • Threat-Model • Roles • Use-Cases • Threats • Impacts • Disclosure

Contents

Threat Model

This page is an overview defining the goals and process. See also:

Overview

Goals

The three primary goals of this threat model are:

  1. Role and Use Case Definition - To define which assumptions different users of OONI can justifiably rely upon, depending on their particular roles, use cases, and risk tolerances;
  2. Scope Definition - For the OONI developers and operators to decide which of these reliance relationships are technical goals for OONI through its development; and
  3. Security Evaluation - To reason about security issues such as evaluating a potential vulnerability, either post-hoc or in an anticipatory manner.

Scope

Given the goals above, we should emphasize a few things about the scope of this document:

It will necessarily include use cases, roles, or relied upon security properties which are not current goals for OONI. We want to ensure we first have a clear description, and then decide whether or not to adopt a goal for the next OONI release. Conflating definition and acceptance is a common source of confusion.

Also, this document will not contain vulnerability details. Instead, vulnerability descriptions should refer to this document and should either be confidentially disclosed to the developers or entered into issue tracking when the risk is low.

Process

We're developing a threat model following this process:

  1. ☑ Brainstorm about use cases, roles, and potential threats.
  2. ☑ For each threat, determine the impacts on each role.
  3. ☐ Define reliances by determining, for each threat and each affected role, what assumption that role depends on which is violated. (This will live in Roles)
  4. ☐ Provide a concise description of roles, and for each describe what assumptions that role relies on. (See Roles)
  5. ☐ Simplify use cases as much as possible, referring to the roles involved at each step, and what assumptions are relied upon. (See Use-Cases)
  6. ☐ Provide an architectural overview, showing the justification for each component or implementation detail in terms of the prerequisite role reliances. One component may rely on some properties of another due to the reliance of one or more roles. (Pick the correct page for this.)

Once a threat model is specified, a repeated audit cycle improves security:

  1. Audit the design and code in terms of the above to identify security vulnerabilities.
  2. Mitigate discovered vulnerabilities, by code patches, mitigation work around announcements, documentation, or other means.
  3. Refine the Threat Model as each new issue is discovered and mitigated. This keeps it accurate and relevant.

The end result is a document which everyone can refer to when considering threats. The focus on reliance helps clarify reasoning about potential attacks: Select one or more relied upon assumptions, then determine how to violate them with the current architecture or implementation.

This will always be incomplete, so there's an ongoing process of improving this document. New roles, use cases, reliance assumptions, or threats may pop up. Any time an issue isn't captured here, we augment the document and proceed through the process again for the new change.

Clone this wiki locally