[dssa] please review: a summary of the "threat events" conversation on the call yesterday

["Mike O'Connor" <mike@xxxxxxxxxx>]

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.)