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

From: "Roman D. Danyliw" <[email-masked]>
Date: Sun, 2 Mar 2014 20:47:29 +0000

Hello David!

It sounds to me like your trying describe the severity of the incident impact relative to the mission of the organization.  How do your examples and intended use case map to the BusinessImpact class (Section 3.14.2)?  What would be missing from this class to suit your needs?

Roman

From: David Misell [mailto:[email-masked]]
Sent: Thursday, February 27, 2014 11:26 AM
To: Roman D. Danyliw
Cc: [email-masked]
Subject: Re: [mile] Missing data elements useful for incident reporting

Roman,  how about Impact assessment or priority, this could be split but I have seen this before.

P1 PAN National Infrastructure, Millions affected, or loss of life
P2 A company balance sheet/ share price affected, major impact to a region or large numbers discomforted
P3 Still potential for a major outage or degraded service but mainly functional,/ downgraded P1/2 incident subject to mitigation (we turned off the www access?)
p4 Minor issue for special case of individuals not greatly impacting their lives (we repeatedly click to buy a ticket- its busy big deal)

Just a thought

dave

Yours Faithfully,

Dave Misell MSc CISSP
+44 (0)7710 380044
[email-masked]<mailto:[email-masked]>
Skype: misell.dave

On 27 Feb 2014, at 16:15, Roman D. Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Sun, 2 Mar 2014 21:03:03 +0000

Hi Chris!

Good operational feedback.  I annotated the types of times you track using the current capabilities of the data model.  Let me know if you disagree with this mapping.

> 1. Time the event (compromise) happened.

This is Incident/StartTime or EventData/StartTime

> 2. Time the event was discovered

I agree that this is important and an oversight.  I would propose adding a DateTime to the Discovery class to address this shortcoming.

> 3. Time when mitigations / response actions took place

This is HistoryItem/DateTime.

> 4. Time of the indicator sharing (generation time)

This is Incident/ReportTime.

Roman

-----Original Message-----
From: Harrington, Christopher [mailto:[email-masked]] 
Sent: Thursday, February 27, 2014 11:37 AM
To: Roman D. Danyliw; [email-masked]
Subject: RE: Missing data elements useful for incident reporting

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

[email-masked]

---

From: "Harrington, Christopher" <[email-masked]>
Date: Mon, 3 Mar 2014 07:12:33 -0500

I think those make sense. Thanks Roman. 

Thanks,

--Chris

-----Original Message-----
From: Roman D. Danyliw [mailto:[email-masked]] 
Sent: Sunday, March 02, 2014 4:03 PM
To: Harrington, Christopher; [email-masked]
Subject: RE: Missing data elements useful for incident reporting

Hi Chris!

Good operational feedback.  I annotated the types of times you track using
the current capabilities of the data model.  Let me know if you disagree
with this mapping.

> 2. Time the event was discovered

I agree that this is important and an oversight.  I would propose adding a
DateTime to the Discovery class to address this shortcoming.

Roman

-----Original Message-----
From: Harrington, Christopher [mailto:[email-masked]]
Sent: Thursday, February 27, 2014 11:37 AM
To: Roman D. Danyliw; [email-masked]
Subject: RE: Missing data elements useful for incident reporting

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)

Thanks,

--Chris

Christopher Harrington
-----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!

Roman

---

From: David Misell <[email-masked]>
Date: Thu, 27 Feb 2014 16:26:11 +0000

Just a thought

dave

Yours Faithfully,

Dave Misell MSc CISSP

+44 (0)7710 380044
[email-masked]
Skype: misell.dave