[dssa] please review: a summary of the "threat events" conversation on the call yesterday
- To: dssa@xxxxxxxxx
- Subject: [dssa] please review: a summary of the "threat events" conversation on the call yesterday
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Fri, 24 Feb 2012 15:12:33 -0600
i just want to take a moment to summarize the conversation we had on the DSSA
call yesterday. i know that sometimes this process feels like we're working
really hard and making really small advances. but when things are hard like
that, it often means we're all doing a lot of learning -- and then there are
times when things suddenly snap into clear focus. i'm feeling like like that
happened this week and i want to push this out to the rest of you for review
please take a look at this note, comment about it on the list over the next few
days, and join us next Thursday to see if we can arrive at a consensus view.
much of our struggle has focused on the list of threat-events that we want to
evaluate and we've dramatically simplified that list (mostly by removing
variables that we can evaluate separately). here's the list we've been
evaluating for the last month or so, followed by the new version that we've
come to as of yesterday:
Old Threat Event list
TE-10 Disrupts a "global" zone file (.COM/.NET/.UK/.DE etc.)
TE-20 Disrupts a "lesser" zone file (that is not outsourced to a major
TE-30 Root zone -- is published incorrectly
TE-40 Root zone -- is not published
TE-50 Disrupts the IANA zone file
TE-60 Disrupts DNSSEC from a "Major" DNSSEC provider
TE-70 Disrupts DNSSEC for a TLD zone
TE-80 Disrupts Critical DNS support files
TE-90 Disrupts provisioning systems between registries and registrars (the
result being that registrars can't add/change/delete zones from the TLD)
New Threat Event list
TE-100 Zone -- does not resolve
TE-110 Zone -- is incorrect
TE-120 Zone -- security is compromised
as you can see, our new list is much broader and leaves out several ideas that
we were evaluating in the earlier version of the list. one of the biggest
things that's left out of this list is the notion of "size" or "range" of a
zone. here's the big observation that leads us to do that:
Impact depends on your perspective
A zone that is not resolving, is incorrect, or has security that is compromised
is always a significant problem to registrants and users within the zone. But
the impact of the loss of a given zone on visitors to that zone or the whole
internet varies with the number of users of that zone (eg .COM or the root)
thus, what we were trying to do with our more-detailed threat-event list was
combining two ideas -- threat-event and scale. we've concluded that trying to
evaluate that "impact" issue has gotten us sidetracked from our real mission
and that we can move forward by limiting that evaluation to worst-case
the way we'll do that is to modify the Impact scales that we'll use to evaluate
the threat-events to focus on the worst case, since we're chartered to look at
"the actual level, frequency and severity of threats to the DNS" rather than
evaluating the relative harm that may happen between different zones. with
that in mind, here are the revised versions of the three scales that we'll use
to evaluate these threat-events:
New version of Table H2 -- Threat event - worst-case type of impact (more than
one may apply)
(multiple scenarios to be documented in report-text)
A -- Damage to or incapacitation of a critical infrastructure sector.
B -- Relational harms, e.g.:
Damage to trust relationships.
Damage to reputation (and hence future or potential trust
C -- Harm to individuals, e.g.:
Injury or loss of life.
Damage to image or reputation.
D -- Harm to assets, e.g.:
Damage to or loss of physical facilities.
Damage to or loss of information systems or networks.
Damage to or loss of information technology or equipment.
Damage to or of loss of information assets.
E -- Harm to operations, e.g.:
Inability to perform current missions/business functions.
Direct financial costs.
Harms (e.g., financial costs, sanctions) due to noncompliance with
laws, contracts or regulations.
New version of Table H3 --Threat event - worst-case severity of impact
(multiple scenarios to be documented in report-text)
10 -- Multiple severe or catastrophic adverse effects
8 -- A severe or catastrophic effect
5 -- Serious adverse effect
3 -- Limited adverse effect
1 -- Negligible adverse effect
New version of Table H4 -- Threat event - worst-case range of effects
10 -- sweeping, involving almost all of the users of the DNS (100%?
8 -- extensive, involving most of the users of the DNS (80%? >100,000,000?)
5 --wide-ranging, involving a significant portion of users of the DNS (30%?
3 --limited, involving some of the users of the DNS (10%?, 1,000,000?)
1 -- minimal, involving few if any of the users of the DNS (1%?, 100,000?)
by using our refined/simplified list of threat-events (a zone doesn't resolve,
is inaccurate or has security that is compromised) and applying these
worst-case scales we can say that all three of those threat-events are
extremely severe in the worst-case and move on to the next part of our
analysis. which gets me to the last breakthrough idea of this "big week full
of breakthrough ideas" which to remind ourselves of the following (from the
Dimensions of the analysis
Threat-events (what happens) should not be confused with:
Adverse impact - the likelihood of things that will result from the
Vulnerabilities - the severity of things that allow it to happen
Predisposing conditions - the pervasiveness of things that help prevent it
Adversarial threat-sources - the capability, intent, or targeting of the
people initiating it, or
Non-adversarial threat-sources - the range of effect of a non-adversarial
event that initiates it
Controls and mitigation - actions to reduce likelihood and impact
i'd like to have two conversations about this over the next few days.
for those of you who were on the call -- have i got this right? did i miss
for those of you who were NOT on the call -- what do you think of this idea?
is it clear? is it right?
looking forward to your thoughts.
- - - - - - - - -
handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)