Tuesday, March 26, 2013

Defensive Construct Exchange Standard 0.3

This is the last update of the Defense Construct Exchange Standard (DCES) before implementation of milestone 1 of Moirai.  You can read more about the previous version 0.1 and version 0.2.

The major changes in this version are:

  1. Attribute edges need to be "described by" rather than describes. This will change the direction of the edges in the construct to the standard in version 0.1.  This way edges are not a parent of the node they describe.  This is important for risk calculations. CPTs are based on parents and so edges pointing from attributes to nodes need to have a relationship of "influences" rather than "describes" to make sure CPTs are calculating on the correct edges.
  2. Attributes no longer require a "metadata" property.  Instead, the dictionary containing the single {type:value} dictionary will be stored in the "label" of the attributes
  3. Event, Condition, and Actor nodes are considered the same node if the have exactly matching labels.
  4. Edges are considered the same if they have the same source & target.
The last two are not so much require but should be kept in mind as they influence the inclusion of constructs into the graph.

Defensive Construct Exchange Standard 0.3:

Mandatory Statements:


  1. All discrete pieces of information within a construct shall be given an individual node.
  2. All nodes within the construct shall have the property "class" of value "attribute".
  3. The actual attribute property shall be stored as a JSON object within the node's "label" property.  The object shall have a single {"type":"value"} pair.  All other type:value pares shall be rejected.
  4. All nodes shall be linked to a node containing a construct ID generated by the construct originator.  (It is recommended that those receiving constructs into their own graphs generate a local construct ID so as to avoid conflicts within their graph.)
  5. The construct ID shall be a child node of all Attributes within the construct.
  6. The nodes and edges shall be represented in JSON.  They shall be transmitted in accordance with the JSON format outlined by the gephi graph streaming project (Gephi graph streaming).  In practice, all constructs shall be 'an' (add node) or 'ae' (add edge), with the recipient deciding how to actually handle the information.  All required properties are documented at https://github.com/gdbassett/moirai/blob/dev-ms1/protocol_definitions.txt
  7. The DCES event shall have a "dces_version" property.
  8. The WAMP standard should be used when the DCES event is transmitted to/from an RPC or pubsub.

Optional Statements to facilitate usage:

  1. Attribute nodes within the construct may have their own attributes.  (I.E. A threat construct's location attribute may have a 'classification' attribute.)
  2. Individual constructs should be contained in a single JSON message represent a single DCES event.  (I.E. {"an":{1:{...}, 2:{...}, 3:{...}}, "ae":{4:{...}, 5:{...}}, "dces_version":"0.3"} could represent a single construct".  While it is possible to create a construct in the receiving graph with multiple messages, it is unnecessarily complex.
  3. The recipient of a DCES event may define it's own response to receipt depending on it's needs. If the sender needs to understand the linkage of the construct in the recipient's attack graph, it is recommended the recipient return the the node ID of the node storing the construct ID in the recipient's graph.
  4. "an"s are implicitly anchored to originIDs. (Because the node doesn't exist in the DB graph yet, there is no dbID to anchor to.) If any "an"s are present in the event, any "ae"s in that event are explicitly anchored to originIDs to avoid confusion
  5. Event, Condition, and Actor nodes are considered the same node if the have exactly matching labels.
  6. Edges are considered the same if they have the same source & target.

Example:

This example, used previosuly has been updated to be a DCES version 0.3 compliant construct transmitted in a single event.  Graphically, it can be represented as:

    This produces the following Object which can be dumped to json.  (Please note, as the CPT for the construct ID is quite large, I have left it out.)
    {"dces_version":"0.3",
    "ae":{"1":{"source":"B","target":"A","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "2":{"source":"C","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "3":{"source":"D","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "4":{"source":"C","target":"D","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "5":{"source":"B","target":"C","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "6":{"source":"E","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "7":{"source":"F","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "8":{"source":"G","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "9":{"source":"F","target":"G","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "10":{"source":"E","target":"F","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "11":{"source":"H","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "12":{"source":"I","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "13":{"source":"J","target":"A","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "14":{"source":"I","target":"J","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"},
    "15":{"source":"H","target":"I","directed":true, "relationship":"described by","start":"2013-03-14T16:57Z"}},
    "an":{"A":{"label":{"id":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"A"}},
    "B":{"label":{"url":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"B","index":["C",true,false],"0":[0,1,0],"1":[1,1,0]}},
    "C":{"label":{"domain":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"C","index":["D",true,false],"0":[0,1,0],"1":[1,1,0]}},
    "D":{"label":{"whois":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"D","index":[true,false],"0":[1,0]}},
    "E":{"label":{"dns query":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"E","index":["F",true,false],"0":[0,1,0],"1":[1,1,0]}},
    "F":{"label":{"dns record":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"F","index":["G",true,false],"0":[0,1,0],"1":[1,1,0]}},
    "G":{"label":{"record type":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"G","index":[true,false],"0":[1,0]}},
    "H":{"label":{"dns query":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"H","index":["I",true,false],"0":[0,1,0],"1":[1,1,0]}},
    "I":{"label":{"dns record":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"I","index":["J",true,false],"0":[0,1,0],"1":[1,1,0]}},
    "J":{"label":{"record type":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"J","index":[true,false],"0":[1,0]}}}}

    This version of the DCES standard will be used for Moirai Milestone 1.  For those interested, the following python code can reproduce the CPT for node A.  .

    d = {}
    d["nodeid"] = "A"
    d["index"] = ["B", "C", "D", "E", "F", "G", "H", "I", "J", true, false]
    parents = len(d["index"]) - 2
    for i in range(0,2**parents):
       k = [int(x) for x in list('{0:0b}'.format(i))]
       for l in range(0, parents - len(k)):
          k.insert(0,0)
       k.append(1)
       k.append(0)
       d[i] = k

    Thursday, March 21, 2013

    A Path to Understanding Risk

    Part of the life of an information security professional is assessing risk, however we rarely feel that the likelihood and consequence we give a risk at the end of the day represents our true feelings about the risk.  That is because most of the processes we have for assessing risk are vague approximations of the true context we understand as professionals.  Whether it's an organic approach or an approach such as CVSS, it is usually a system for creating buckets that we try to capture the context of the risk in.  However, it ends up being like trying to set buckets outside to capture all of the rain.  Instead we need a way to capture the entire context of the risk as it exists in our minds.

    1. Instead, we should start with what is in our head when we consider the risk.  A Narrative.  The narrative starts with a threat actor and ends when they accomplish their goal, realizing our risk along the way.  The narrative includes events that happen and conditions that exist or occur because of events in the narrative.  An example might be...
    A thief wants to steal my dog.  He walks by my house and sees my dog in the window.  He walks up to the front door and rings the door bell.  I'm not home so nobody answers.  He then tries the door nob.  The door was unlocked so he walks in.  He picks up my dog and leaves.  The thief now has my dog and I do not.
    In this example we have a threat actor, (the thief), his goal, (steal my dog), the consequence, (I no longer have my dog), multiple actions, (the thief walks by, he rings the doorbell, he walks in, etc), and multiple conditions, (my dog is in my house, I am not, my door is unlocked, etc).

    Conditions represent many things.  The thief's goal and the consequence in the example above, (and in general), are conditions.  Mitigations and vulnerabilities are also conditions.  In the example, my door being unlocked is a vulnerable condition.  If I had a security system, that would be a mitigating condition.  This helps tie this approach back to our normal risk assessment process.

    2. The next step is to understand the consequences.  I lost my dog, yes, but what was the impact? In the example, the impact is mostly personal.  However, in the real world, the impact should be assessed against the Business Mission.  The impact is likely a loss of:

    • Confidentiality
    • Integrity
    • Availability
    • Resources
    • Control
    Some good questions to ask are:
    • Can the Information System's mission still be accomplished?
    • How is the mission degraded?
      • What are the secondary impacts to mission degradation (political, brand image, confidence, etc)
    • Is the mission recoverable?
      • What are the resources (cost, schedule, technical, risk) to recovery?
    • What happens if the mission is executed with incorrect information?
    • Does the loss of information decrease our (or our friends') ability to act?
    • Does the threat gaining information decrease our (or our friends) ability to act?
    • Does the threat gaining information increase their ability to act?
    • What additional control does the threat gain by realizing the risk (even if we do not lose control)?
    3. From the narrative, create an attack path.  The attack path is going to include the same actors, conditions and events as above.  We're also going to add another element, an "attribute".  Attributes are characteristics that describe other steps in the attack path.  In our example, the thief has the attribute: "motive" = "wants my dog".  Additionally, the thief having the attribute "skill" = "lock picks" may make it more likely for him to open the door, even if it were locked.  Also, we can capture other, alternate approaches.  If the door was locked, the thief might try a window, the garage door, or a back door.  In our example, the attack path may look something like:

    • STEP NUM - STEP NAME - STEP CLASS - LIKELIHOOD - DESCRIPTION
    1. - A Thief - Actor - 5 - A normal, everyday thief.
    2. - "Motive" = "Wants to steal my dog" - Attribute - 1 - I don't know why anyone would want to steal my dog.
    3. - Walks by my house - Event - 3 - Not many thieves walk by my house.
    4. - Sees my dog - Event - 1 - My dog is normally asleep on the couch where you can't see him.
    5. - Walks up to my door - Event - 5 - Walking up to my door is easy.
    6. - Rings the doorbell - Event - 5 - Anyone can ring my doorbell.
    7. - Nobody is home - Condition - 2 - My wife is usually at home when I'm not, but there are times when nobody's home.
    8. - Nobody answers door - Event - 5 - If no-one's home, of course no-one's going to answer the door.
    9. - Tries door nob - Event - 5 - Anyone can turn my doornob
    10. - Door's unlocked - Condition - 2 - The house is usually locked when no-ones at home.
    11. - Actor walks in - Event - 5 - The actor comes inside my house.  If the door is unlocked, there's nothing stopping him from doing this.
    12. - Actor picks up my dog - Event - 4 - My dog is kinda hard to pick up.
    13. - Actor leaves - Event - 4 - The actor leaves my house with my dog and without being caught.  Notionally he then walks to wherever he is parked with my dog in his hands.  While not completely likely, it's possible and I doubt anyone would stop him.
    14. - Actor has my dog - Condition - 5 - If they took it, they have it.
    15. - I don't have my dog - Condition - 5 - If they have my dog, I definitely don't.
    16. - "Impact" = "2" - Attribute - 5 - I like my dog, but I can find a new one.  Life could be worse.
    Ultimately, you can make the attack path as detailed or as general as you want.  You can have more steps or fewer, more attributes or less, let it branch more or make it very linear.  I assessed likelihood and risk on a 1-5 scale.  You could do 1-3 (low, medium, high), or a percentage.  It really doesn't matter much.  There are ways to calculate a final number from this that are mathematically sound, but, more importantly, you can capture the risk and it's context as it exists in your mind.  You can also see what mitigating conditions and vulnerable conditions effect your risk.  And as you become more adept at it's use, you can combine the attack paths you collect into an attack graph to ultimately help you manage your information security posture.

    Friday, March 15, 2013

    Defensive Construct Exchange Standard .2

    Previously I laid out the need for a graph-based standard to exchange information (here).  After working with Defensive Construct Exchange Standard (DCES) events in my personal projects I want to provide some additional refinement of the standard.  If you want to read they why, read the last post.

    As a primer, graphs are made up of nodes and edges.  Nodes are the circles.  Edges are lines that connect them.  All have other names, but we'll use nodes, edges, and graphs for now.  Nodes and edges can have properties, just like properties attached to an object in programming.  DCES events are constructs from other tools.  Where in another tool, the construct may have been a record in a table in a database, the DCES event represents it as a small graph in a JSON compatible format.

    Defensive Construct Exchange Standard .2:

    1. All discrete pieces of information within a construct will be given an individual node.  All nodes within the construct have the property "class" of value "attribute".
    2. The actual attribute property will be stored as a JSON object within the node's "metadata" attribute.  The object will have a single {"type":"value"} pair.  All others shall be rejected.
    3. All nodes will be linked to a node containing a construct ID generated by the construct originator.  (It will be recommended that those receiving constructs into their own graphs generate a local construct ID so as to avoid conflicts within their graph.)
    4. The construct ID will be a parent node of all Attributes within the construct.
    5. The nodes and edges will be represented in JSON.  They shall be transmitted in accordance with the JSON format outlined by the gephi graph streaming project (Gephi graph streaming).  In practice, all constructs shall be 'an' (add node) or 'ae' (add edge), with the recipient deciding how to actually handle the information.  All required properties are documented at https://github.com/gdbassett/moirai/blob/dev-ms1/protocol_definitions.txt
    6. Attribute nodes within the construct may have their own attributes.  (I.E. A threat construct's location attribute may have a 'classification' attribute.)
    7. Individual constructs should be contained in a single JSON message represent a single DCES event.  (I.E. {"an":{1:{...}, 2:{...}, 3:{...}}, "ae":{4:{...}, 5:{...}}, "dces_version":"0.2"} could represent a single construct"
    8. The recipient of a DCES event may define it's own response to receipt depending on it's needs. If the sender needs to understand the linkage of the construct in the receipient's attack graph, it is recommended the recipient return the the node ID of the node storing the construct ID in the receipient's graph.
    9. The WAMP standard should be used when the DCES event is transmitted to/from an RPC or pubsub.
    10. The DCES event shall have a "dces_version" property.
    11. "an"s are implicitly anchored to originIDs.  (Because the node doesn't exist in the DB graph yet, there is no dbID to anchor to.)  If any "an"s are present in the event, any "ae"s in that event are explicitly anchored to originIDs to avoid confusion. If an "ae" needs to be referenced to a dbID, add it as a separate event.

    Example:

    This example from the previous post has been updated to present version .2 of the standard.  Graphically, it looks like this:

    Parsed into JSON with all properties included, it looks like this:
    {"dces_version":"0.2",
    "ae":{"1":{"source":"A","target":"B","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "2":{"source":"A","target":"C","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "3":{"source":"A","target":"D","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "4":{"source":"D","target":"C","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "5":{"source":"C","target":"B","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "6":{"source":"A","target":"E","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "7":{"source":"A","target":"F","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "8":{"source":"A","target":"G","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "9":{"source":"G","target":"F","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "10":{"source":"F","target":"E","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "11":{"source":"A","target":"H","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "12":{"source":"A","target":"I","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "13":{"source":"A","target":"J","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "14":{"source":"J","target":"I","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"},
    "15":{"source":"I","target":"H","directed":true, "relationship":"describes","start":"2013-03-14T16:57Z"}},
    "an":{"A":{"label":"Construct From X","class":"attribute","metadata":{"id":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"A","index":[true,false],"0":[1,0]}},
    "B":{"label":"url","class":"attribute","metadata":{"url":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"B","index":["A","C",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
    "C":{"label":"domain","class":"attribute","metadata":{"domain":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"C","index":["A","D",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
    "D":{"label":"whois","class":"attribute","metadata":{"whois":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"D","index":["A",true,false],"0":[0,1],"1":[1,0]}},
    "E":{"label":"dns query","class":"attribute","metadata":{"dns query":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"E","index":["A","F",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
    "F":{"label":"dns record","class":"attribute","metadata":{"dns record":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"F","index":["A","G",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
    "G":{"label":"dns record type","class":"attribute","metadata":{"record type":"<value>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"G","index":["A",true,false],"0":[0,1],"1":[1,0]}},
    "H":{"label":"dns query","class":"attribute","metadata":{"dns query":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"H","index":["A","I",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
    "I":{"label":"dns record","class":"attribute","metadata":{"dns record":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"I","index":["A","J",true,false],"0":[0,0,0,1],"1":[0,0,0,1],"2":[0,0,0,1],"3":[1,0,0,0]}},
    "J":{"label":"dns record type","class":"attribute","metadata":{"record type":"<value2>"},"start":"2013-03-14T16:57Z","cpt":{"nodeid":"J","index":["A",true,false],"0":[0,1],"1":[1,0]}}}}
    However, in practicality, the receiving graph will probably add much of the information.  For edges, "relationship", "directed", and "start" can all be added by the receiver.  For nodes, "class", "start", and "cpt" can be added by the receiver greatly simplifying the sender's job.

    Ultimately, this standard will continue to evolve slowly as it is put into use.  While it is another new standard in a sea of standards, it is truly unique and offers clear benefits.

    Wednesday, March 13, 2013

    Conditional Probability Tables in JSON

    I have found myself in need of a JSON format to transmit and process Bayesian Conditional Probability Tables (CPTs).  While there are a few XML formats, none seem to be both simple and effective.  As such, I propose the following standard, (with the intent of using it in my future projects):


    • The CPT will be inclosed in a javascript object or python dictionary when not in string format.
    • One item labeled "nodeid" with the node ID of the node the CPT represents. (as booleans are acceptable values in JSON, if the CPT has only states true and false, which it should, they may be recorded as such rather than as strings)
    • One item labeled "index" with an array of the node IDs of parents of the represented node followed by the CPT states.
    • 2^p (where p = # of parents) arrays representing the states of the CPT with a label of the base 10 representation of the state (as a string)
    • The CPT may have a "reviewed" item of type "bool" representing whether the CPT has been manually reviewed.  (Set it to "false" if the CPT was auto-generated and "true" if someone manually updated/reviewed the CPT.)
    For example:
    {
    "nodeid":4,
    "index":[1,2,3,true,false],
    "0":[0,0,0,0,1],
    "1":[0,0,1,0.1,0.9],
    "2":[0,1,0,0.1,0.9],
    "3":[0,1,1,0.1,0.9],
    "4":[1,0,0,0.1,0.9],
    "5":[1,0,1,0.1,0.9],
    "6":[1,1,0,0.1,0.9],
    "7":[1,1,1,0.9,0.1]
    }

    Friday, March 1, 2013

    Capture Your Thoughts

    This is not really a security blog though many security people will appreciate it.  This is for all the people who have good ideas; all the people who think "you know, this would work better if ..."; all the people who can't help but think about solving every problem they hear:

    CAPTURE YOUR THOUGHTS

    There are very few things which can not be created w/ time & money.  Thoughts and ideas are one of them.  No matter how much money you spend, it will not make the award winning idea appear.  No matter how long you wait, you will not simply outlast the idea.  It will not get tired of being hidden and jump into your mind (or the mind of another).  But once it's there, it is the most precious commodity in the world.  It has real value. And you will lose it if you don't do something about it.

    The first step is to have the facilities to capture it.  Do you tell yourself you'll just remember it later?  You won't.  Whether you always carry pen and paper, have a phone with something like evernote or springpad, or even twitter, make sure you have something with you.  If there's some place you are particularly creative (hiking, in the shower, or right before bed), make SURE you have something there.  I especially like aquanotes!

    The second is to commit to writing it down.  It's very easy to tell yourself you'll do it later.  Or to try and file it in your head for when you really need it.  Don't.  You might as well be pouring a Duval down the drain.  You're wasting something of value.  Even if you aren't going to use it right then, write it down.  Tag it with some metadata.  Capture it!

    You may never use your ideas.  You may never tell anyone about them. You may forget you even had them.  But when it comes time to solve problems, you'll always have them and the world will be better because of it!

    Fault Tolerance

    Fault tolerance is "the property that enables a system (often computer-based) to continue operating properly in the event of the failure of (or one or more faults within) some of its components. If its operating quality decreases at all, the decrease is proportional to the severity of the failure..." (1)

    Fault tolerance is integral to systems engineering of critical systems.The assumption is that systems will fail and that the impacts of those failures must be controlled.  An example approach would be to mandate that a system be two fault tolerant.  This would then drive the design of three inhibits, any one of which could prevent the failure of the system.  For a physical system, the failure may be physical failure.  For an information system, the failure will likely be loss of confidentiality, integrity, or availability of critical data or a critical business process.

    Fault tolerance can and should be applied to infosec as well.  When we plan our defenses, we should assume that some defenses will fail to mitigate the risks they were designed to prevent.  We should assume that some vulnerable conditions will be taken advantage of.  To plan infosec inhibits, we must understand the attack path between the causes of our risk (likely a threat) and where the consequences are realized.  It is along these paths that we can then document inhibits.  Whether it be a firewall, code whitelisting, requiring a written form before receiving privileges, or detecting and responding to threats before consequences are realized, we can capture those along the attack path.  Currently we refer to this as 'defense in depth'.  We all have a general understanding of what it means, but the above approach provides a concrete and quantifiable method for implementing it.

    A few months ago there was a significant discussion on whether pen test teams should have a 'zero day' card they could use during a pen test.  What this is really asking is, "Should we test whether the system's backup defenses can be relied upon in case of a failure of primary defenses?"  Or, in other words, "Is the system fault tolerant?" The answer is we should absolutely include a 'zero day' card.  Part of any pen test should be to articulate which defenses, inhibits, or mitigating conditions (whatever you call them) failed.  However, it a system is supposed to implement 'defense in depth', then a 'zero day' card allows us to test that assertion by simulating the failure to see how well the system's defenses handle a failure.  The documentation simply needs to be able to articulate that a failure was simulated to test the fault tolerance of the system.

    Ultimately, we should plan for our information systems to be fault tolerant, even under purposeful information security attack.  One fault tolerant, two fault tolerant, three fault tolerant... Regardless the standard set, not planning for fault tolerance is assuming the system's defenses will function perfectly.  An inherently flawed assumption.