Subject: [mile] Causes of an incident

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 17 Jul 2015 14:48:16 +0000

Hello!

Issue #46, sub-question #7 is tracking a need to describe what caused an incident (e.g., misconfigured application, unpatched host).  How much flexibility would the WG like?

A few options come to mind.  These include:

(1) Use Method/AdditionalData/Weakness from the SCI information model

Per Section 4.5.5 of RFC7203, the Weakness class supports a reference to an external identifier or an XML blob.  This "... extension describes the weakness types that are exposed or were exploited in incidents."

++ no additional work required as this approach references external work
-- no free-form description
-- extension requires a specID

(2) Import the SCI Weakness element into Method

(3) Add a free-form field

Define a free-form field to describe the weakness

++ simple
-- limited machine readability
-- doesn't support external registries of weaknesses

(4) Add an extensible enumerated list

Define an extensible enumerated attribute with a candidate list of things that could cause an incident.    This list could be extended with the ext-attribute convention or through an IANA registry.

++ extensible mechanism without needing a specID 
-- doesn't support external registries of weaknesses
-- the WG needs to seed the initial enumerated list

(5) Combine (3) and (4)

Other approaches are likely possible as well.  What is the thinking of the group?

Roman