Subject: [mile] Missing data elements useful for incident reporting

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 27 Feb 2014 16:15:58 +0000

Hello!

I cross-walked a few references describing the incident reporting process (e.g., NIST SP800-61 and CERT's Handbook for CSIRTs) and a number of operational reporting forms, and found that 5070bis can't easily represent these data fields:

(1) Status of an Incident (e.g., New/In Progress/Ended/Resolved/Unknown; Occurring/Contained/Concluded/Future Threat)
(2) Consortium-specific incident categories -- consortiums defined label classifying this incident
(3) Mitigation factors -- a free form description on mitigating factors that influence the technical or business impact 
(4) Distinguishing between the report time (e.g., time when this incident was reported as occurring) vs. generation time (i.e., when this IODEF-Document was created).
(5) Enumerating which organizations have been notified in the incident -- need to review current HistoryItem and Contact classes
(6) RecoveryTime -- the wall-clock timestamp of when the impact of the incident was remediated.
(7) Cause of the incident (e.g., misconfigured app, unpatched host) -- the SCI draft introduces Method/AdditionalData/Weakness and this may be sufficient.

Does anyone feel we shouldn't add a particular data elements listed above to the data model?

Roman

---

From: "Harrington, Christopher" <[email-masked]>
Date: Thu, 27 Feb 2014 11:37:03 -0500

With respect to times there are 4 times that we track with regards to an
incident. 

1. Time the event (compromise) happened.
2. Time the event was discovered
3. Time when mitigations / response actions took place
4. Time of the indicator sharing (generation time)

Tracking time this way allows us to better understand and prioritize our
efforts. The time between #1 and #2 is what we call Dwell Time or Attacker
Free Time. We monitor that closely. 

For cause of incident we map all of ours to the VERIS framework. Makes for
much more consistent reporting and trend analysis. 

Thanks,

--Chris

Christopher Harrington
Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)
-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Thursday, February 27, 2014 11:16 AM
To: [email-masked]
Subject: [mile] Missing data elements useful for incident reporting

Hello!

I cross-walked a few references describing the incident reporting process
(e.g., NIST SP800-61 and CERT's Handbook for CSIRTs) and a number of
operational reporting forms, and found that 5070bis can't easily represent
these data fields:

(1) Status of an Incident (e.g., New/In Progress/Ended/Resolved/Unknown;
Occurring/Contained/Concluded/Future Threat)
(2) Consortium-specific incident categories -- consortiums defined label
classifying this incident
(3) Mitigation factors -- a free form description on mitigating factors that
influence the technical or business impact 
(4) Distinguishing between the report time (e.g., time when this incident
was reported as occurring) vs. generation time (i.e., when this
IODEF-Document was created).
(5) Enumerating which organizations have been notified in the incident --
need to review current HistoryItem and Contact classes
(6) RecoveryTime -- the wall-clock timestamp of when the impact of the
incident was remediated.
(7) Cause of the incident (e.g., misconfigured app, unpatched host) -- the
SCI draft introduces Method/AdditionalData/Weakness and this may be
sufficient.

Does anyone feel we shouldn't add a particular data elements listed above to
the data model?

Roman

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile