Re: [dssa] please review: a summary of the "threat events" conversation on the call yesterday
Mikey, all,
I think our discussion has been covered perfectly. Thanks Mikey.
However, what is newly stated ("Dimensions of the analysis" - paragraph)
will - to my point of view - still need some overlooking in its
definition, in particular for example "Adverse impact" and
Vulnerabilities.
Best regards
Joerg
> Von: "Mike O'Connor" <mike@xxxxxxxxxx>
> An: dssa@xxxxxxxxx
> Datum: 24.02.2012 22:14
> Betreff: [dssa] please review: a summary of the "threat events"
conversation on the call yesterday
> Gesendet von: owner-dssa@xxxxxxxxx
>
> hi all,
>
> 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 and comment.
>
> 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
provider)
> 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 scenarios.
>
> 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
relationships).
> 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%?
>1,000,000,000?)
> 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%? >10,000,000?)
> 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
methodology):
>
> Dimensions of the analysis
>
> Threat-events (what happens) should not be confused with:
> Adverse impact - the likelihood of things that will result from the
threat-event
> Vulnerabilities - the severity of things that allow it to happen
> Predisposing conditions - the pervasiveness of things that help
prevent it from happening
> 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 something?
>
> 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.
>
> mikey
>
> - - - - - - - - -
> phone 651-647-6109
> fax 866-280-2356
> web http://www.haven2.com
> handle OConnorStP (ID for public places like Twitter, Facebook, Google,
etc.)
Attachment:
smime.p7s
|