Subject: Re: [mile] IOCs

From: "C. Henry Adams & BIE" <[email-masked]>
Date: Tue, 19 Feb 2013 21:29:10 -0800 (PST)

Greetings Everyone,

After further consideration,  I still tend to lean toward a simplified version of the confidence rating.  Which in my opinion, has now changed to ENUM or enumerated type ONLY.

Furthermore,  perhaps { low, medium, high},  should be altered to be {low, minor, medium, high, major}

<confidence rating="low">This has a low confidence rating of compromise</confidence>

<confidence rating="minor">This has a minor confidence rating of compromise</confidence>

<confidence rating="medium">This has a medium confidence rating of compromise</confidence>

<confidence rating="high">This has a high confidence rating of compromise</confidence>

<confidence rating="major">This has a major confidence rating of compromise</confidence>

<< Not sure if the statement below is logical, just Brainstorming>>

Furthermore, let's say Low was map to 1.0.   Minor map to 2.0. Medium map to 3.0  High map to 4.0.  Major map to 5.0

The mapping procedure is the value built-in the ENUM.  (Please feel free to correct me if I'm wrong.)

Then, simple statistical math is apply in some form to equate an overall value of analysis.

C. Henry Adams

This is exactly my point.  I would leave out the numeric ratings.  I
consume the data and at least with the enumerated type I don't have to
also create a map if I want to get back to low, medium and high.  I will
have to make that transform anyway, so that my SOC knows the confidence
without having to keep looking it up ;-)  I like the simplicity of the
enumerated typeŠpeople can take that and make it into whatever they want
as far as numerics are concerned.

Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: [email-masked]

On 2/19/13 9:43 AM, "Eric Burger" <[email-masked]> wrote:

>If the proposal is 0-19 = low, 20-39 = Š, 80-99 = high, then why do we
>have the numbers, or why do we have the enumerated type? Either it is a
>number or it is an enumerative value. Having both is asking for trouble.
>
>On Feb 19, 2013, at 7:40 AM, "Moriarty, Kathleen"
><[email-masked]> wrote:
>
>> Should we provide guidance similar or the same as what CIF uses (was
>>posted to the list previously)?  They use direct mapping to 5 levels so
>>that you can have ranges of numeric values used from 0-100, low to high.
>> This would be the easiest solution...
>>
>> Thanks,
>> Kathleen
>> ________________________________________
>> From: [email-masked] [[email-masked]] On Behalf Of Eric
>>Burger [[email-masked]]
>> Sent: Tuesday, February 19, 2013 7:38 AM
>> To: MILE IETF
>> Subject: Re: [mile] IOCs
>>
>> If there really is no value to a value, do not let people hurt
>>themselves.
>>
>> If there is a proprietary reason for a value, we should say what we
>>mean and call it such. For example:
>>
>>        <confidence rating="low">This is XML so put your
>>NON-INTEROPERABLE mumble you want here</confidence>
>> or
>>        <confidence rating="high">42</confidence>
>> or
>>        <confidence
>>rating="medium"><mydom:meansSomethingToMe>balderdash</mydom:meansSomethin
>>gToMe></confidence>
>>
>> On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher"
>><[email-masked]> wrote:
>>
>>> I would agree that flexibility is something to strive for. However
>>>there
>>> isn't enough in the RFC to make the numeric confidence value
>>>understood by
>>> the recipient and therefore actionable. From the spec:
>>>
>>> "numeric.  The element content contains a number that conveys the
>>>confidence
>>> of the data.  The semantics of this number outside the scope of this
>>> specification"
>>>
>>> Based on that I can score my confidence with 1 being most confident
>>>and 100
>>> being least. Perfectly legitimate but would probably mess everybody
>>>up. What
>>> if my scale is 1000 and yours is 100. I send you something with a
>>>score of
>>> 100 you will think I am absolutely certain when I am only 10% so.
>>>Knowing
>>> how sure the sender is about a piece of data shared is critical. If the
>>> sender puts an arbitrary number in the field I have no point of
>>>reference.
>>> It's meaningless to me.
>>>
>>> We spell out what the relative value is for low/med/high. I know those
>>>are
>>> self-explanatory but they are still spelled out. I would urge that we
>>>do the
>>> same for a numeric value. If not there needs to be something added so
>>>that
>>> in addition to the numeric value I have a point of reference for how
>>>certain
>>> you are based on the number you put there.
>>>
>>> Thanks,
>>>
>>> --Chris
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> Banghart, John
>>> Sent: Monday, February 18, 2013 7:42 AM
>>> To: Eric Burger; MILE IETF
>>> Subject: Re: [mile] IOCs
>>>
>>> Eric,
>>>
>>> Well, I think you answered your own initial question, but I'm going to
>>>jump
>>> in anyway.  :)
>>>
>>> Generally speaking, I think we want to strike a balance between
>>> standardization and flexibility.  We are unlikely to arrive at any
>>>sort of
>>> one-size-fits-all scheme, no matter how long we talk about it.
>>>Instead, we
>>> should be focusing on solidifying the areas we can all agree on, and
>>>allow
>>> flexibility for those that we don't.  It's an age old cliché, but
>>>let's not
>>> let perfect be the enemy of the good.
>>>
>>> -John
>>>
>>> On 2/16/13 12:42 PM, "Eric Burger" <[email-masked]>
>>>wrote:
>>>
>>>> What is the justification for both numeric and enumerated values
>>>> (low/medium/high)?  In general such a schema is begging for
>>>> interoperability problems.
>>>>
>>>> I suppose I can understand both sides of the argument.  On the We Need
>>>> Numbers side is those that actually calculate a percentage or other
>>>> objective measure in the confidence may want to use those real
>>>>numbers.
>>>> As well, on the We Need Numbers side is the argument that three
>>>> enumerated values may not prove sufficient in the future. On the We
>>>> Need Enumerated Values side is confidence, other than 0% and 100%,
>>>>tend
>>>> to be arbitrary guesses. Putting a number on this value imparts a
>>>>level
>>>> of specificity that does not exist. Also, it is a lot easier to map
>>>> 'low' to 'low' than it is to map 0-33 to 'low'.
>>>>
>>>> On Feb 13, 2013, at 2:08 PM, "Harrington, Christopher"
>>>> <[email-masked]> wrote:
>>>>
>>>>> That will work provided I (and everyone else) has a mapping for the
>>>>> numbers.  I would prefer a simple low/med/high scheme. The more we
>>>>>add
>>>>> the more you have to be able to differentiate between them. However
>>>>> for potential interoperability I do see the benefit of the 5.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>> From: Moriarty, Kathleen
>>>>> Sent: Wednesday, February 13, 2013 2:05 PM
>>>>> To: Harrington, Christopher; MILE IETF
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>>
>>>>> If you think of IODEF just for transport, could you meet your needs
>>>>> with storing the values differently in a database (IODEF is just
>>>>>meant
>>>>> for the exchange)?  The numbers map to low/med/high - for db storage
>>>>>-
>>>>> if numbers are used, you could store the equivalent value, adding the
>>>>> 2 additional ones provided.
>>>>>
>>>>> Does it make sense to expand the set of values to match what CIF is
>>>>> doing if we went forward with the approach of supporting both
>>>>>options?
>>>>>
>>>>> Thank you,
>>>>> Kathleen
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of Harrington, Christopher
>>>>> Sent: Wednesday, February 13, 2013 11:49 AM
>>>>> To: 'C. Henry Adams & BIE'; MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> From a data processing standpoint it is going to create extra work
>>>>> for the people who are going to receive this data if we support both
>>>>> numeric and alpha characters in the same field. I can envision people
>>>>> wanting to search, sort, store, etc the data in this field. If we
>>>>> allow both data types then everyone will need to have a mapping of
>>>>> some sort. I have a field for confidence in my threat tracking
>>>>> database. Having both a numeric score and alpha characters / words
>>>>> creates issues when trying to interact with the data. I agree that we
>>>>> need to support both however I don't think both should be in the same
>>>>> field. I would much rather see 2 different fields for Confidence if
>>>>>we
>>>>> are going to support 2 different data types.
>>>>>
>>>>> This will be a larger issue should Confidence be used elsewhere.
>>>>> Ideally in future revisions I would like to see attribution expressed
>>>>> as  some form of attribution is almost always shared with an IoC.
>>>>> Currently there are 5 areas where we  (EMC) uses confidence.
>>>>>
>>>>> Indicator (how confident are you that this is a valid IoC)
>>>>> Indicator_Set (how confident are you that all of the indcators in the
>>>>> set should be in the set)  Campaign (how confident are you that all
>>>>> Indicator_Sets are part of this campaign)  Threat Actor (how
>>>>>confident
>>>>> are you that the Campaign is attributed to this Threat Actor)  Threat
>>>>> Actor type (how confident are you that this Theat Actor is APT,
>>>>> Crimeware, other)
>>>>>
>>>>> The threat actor name and the threat actor type are usually the first
>>>>> 2 things that anyone processing IoCs wants to know as they drive
>>>>>priority.
>>>>> Knowing how sure the sender is that this IoC is APTis a vital piece
>>>>> of information for us.  Sorry to take us a little off the path but I
>>>>> wanted to show where Confidence could be used.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of C. Henry Adams & BIE
>>>>> Sent: Wednesday, February 13, 2013 10:24 AM
>>>>> To: MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Again, I would concur that both a numeric and subjective analysis of
>>>>> the Confidence Rating needs to be express, but combined in a
>>>>> simplified schema as such below:
>>>>>
>>>>> <Confidence rating=" Alphanumeric">1LL</> .... etc.
>>>>>
>>>>> <Confidence rating=" Alphanumeric">2P</>
>>>>>
>>>>> <Confidence rating=" Alphanumeric">3AC</>
>>>>>
>>>>> <Confidence rating=" Alphanumeric">4U</>
>>>>>
>>>>> <Confidence rating=" Alphanumeric">5I</>
>>>>>
>>>>> ( i.e.  1 = Less Likely,   2 = Probable,  3 = A Concern,  4 =
>>>>>Urgent,
>>>>> 5 = Imminent )
>>>>>
>>>>> Here's my point, perhaps a set of numeric related or associated
>>>>> definitions can lower the propagation of error regarding the
>>>>>analysis.
>>>>>
>>>>> Thanks,
>>>>> C. Henry Adams
>>>>>
>>>>>
>>>>> I agree that what we really need is both.  In most situations a low,
>>>>> medium and high may be acceptable but there are times when we will
>>>>> want to show that confidence in a situation is increasing or
>>>>> decreasing.  If we are only looking at a three levels, we cannot
>>>>> express what is needed to show confidence is trending up on the data
>>>>> being exchanged about the event.
>>>>>
>>>>> Kathleen included the following in a previous message.
>>>>>
>>>>> <Confidence rating="low"/>
>>>>>
>>>>> Vs:
>>>>>
>>>>> <Confidence rating="numeric">85</>
>>>>>
>>>>> I really think we need to include both capabilities as John alluded
>>>>> to since confidence is not a three tiered item but something that is
>>>>> indeed subjective and we need a means to show a reasonably accurate
>>>>> confidence index that the sender is trying to convey.
>>>>>
>>>>> Kent Landfield
>>>>>
>>>>> McAfee | An Intel Company
>>>>> Direct: +1.972.963.7096
>>>>> Mobile: +1.817.637.8026
>>>>> Web: www.mcafee.com
>>>>>
>>>>> From: <Banghart>, John Banghart <[email-masked]>
>>>>> Date: Wednesday, February 13, 2013 7:16 AM
>>>>> To: "Stoecker, Paul" <[email-masked]>, Kathleen Moriarty
>>>>> <[email-masked]>, Brian Trammell <[email-masked]>
>>>>> Cc: "C. Henry Adams & BIE" <[email-masked]>, MILE IETF
>>>>> <[email-masked]>
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Paul,
>>>>>
>>>>> I agree that confidence is subjective, but subjectivity can be
>>>>> reduced  within communities that interact frequently.  Prioritization
>>>>> of indicators  and response between tightly connected sharing
>>>>>partners
>>>>> might require a  more specific level of detail, particularly during a
>>>>> crisis situation.
>>>>>
>>>>> From that perspective, I think the guidance should allow for
>>>>> additional granularity, while stressing the "high, medium, low" as
>>>>> preferred for broad interoperability.
>>>>>
>>>>> -John
>>>>>
>>>>> On 2/13/13 8:04 AM, "Stoecker, Paul" <[email-masked]> wrote:
>>>>>
>>>>> I may have been too succinct in my response ;-)
>>>>>
>>>>> Confidence is a subjective thing, so I think we should use subjective
>>>>> terms:  Low, Medium, High.  Having a numeric scale with a map that
>>>>> essentially would say something like:
>>>>>
>>>>> 1-33 = Low
>>>>> 34-67= Medium
>>>>> 68-100=High
>>>>>
>>>>> Is just a more complicated way of saying that something is Low,
>>>>> Medium,  High...do we really thing that how High something is makes
>>>>> that much of a  difference?
>>>>>
>>>>> This is like when you get your Performance review where it is Does
>>>>> Not Meet, Meets and Exceeds...your boss tells you that you are a High
>>>>> Meets...your bonus tells you that you got the same bonus that all the
>>>>> other Meets got
>>>>> ;-)
>>>>>
>>>>> Anyway, I digress but trying to prove a point that I would argue that
>>>>> confidence in this case is going to be basically a gut feeling, so
>>>>>why
>>>>> use  numeric values when Low, Medium, High would do just fine.
>>>>>
>>>>>
>>>>> Paul W. Stoecker, Ph.D.
>>>>> SMC Lead Content Architect
>>>>> RSA, The Security Division of EMC
>>>>> cell: 302.379.3375 | e: [email-masked]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" <[email-masked]>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Both approaches will validate in the current schema.  The
>>>>> representation looks a little different for each, here is an example:
>>>>>
>>>>> <Confidence rating="low"/>
>>>>>
>>>>> Vs:
>>>>>
>>>>> <Confidence rating="numeric">85</>
>>>>>
>>>>> Searching capability is a great point, agreed.  I'd like to hear from
>>>>> more people to make sure we don't lose a capability that others find
>>>>> extremely useful (need to gauge that).  Other options is that the
>>>>> guidance can also discourage the use of the numeric in addition to
>>>>> specifying how to select ranges.
>>>>>
>>>>> Any other opinions?
>>>>>
>>>>> Thanks,
>>>>> Kathleen
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stoecker, Paul
>>>>> Sent: Wednesday, February 13, 2013 7:14 AM
>>>>> To: Brian Trammell
>>>>> Cc: Moriarty, Kathleen; C. Henry Adams & BIE; MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Cant we make Confidence a List that has only 3 values:  High, Medium,
>>>>> and  Low?  Any other value means that the Document will mot validate
>>>>> against  the schema.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Feb 13, 2013, at 2:14 AM, "Brian Trammell"
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>> Hi, Kathleen, all,
>>>>>
>>>>> I think 3.10.4 in 5070 takes the right approach here: trying to build
>>>>> interoperable numeric scales for assessment is a very hard problem.
>>>>> (Were I charged with defining such a scale, the value "70" would mean
>>>>> "we compared this incident report to N past similar incident reports
>>>>> according to similarity algorithm S, and 70% of the past reports had
>>>>> assessed impacts within E% of the actual, measured final impact -- I
>>>>> think for most applications this is vastly more difficult and
>>>>> rigorous than it needs to be.)
>>>>>
>>>>> Unless a numeric Confidence value is based on some actual, repeatably
>>>>> measurable aspect of the Assessment report -- which I suspect in
>>>>> many/most/all cases it's not -- then it just represents a guess,
>>>>> however educated.  Each team will probably naturally tune its own
>>>>> scales such that each value generally means the same thing in each
>>>>> report. Across teams, I don't know.
>>>>>
>>>>> On the other hand, Assessments are by their very nature educated
>>>>> guesses, anyway, so I don't know that I'd find much use in automating
>>>>> a response based on the assessment confidence. Chris has a good
>>>>> point, though -- it makes searching difficult and sorting kind of
>>> pointless.
>>>>>
>>>>> If we've seen a general trend toward "0 = 0%, 100 = 100%", then I
>>>>> agree, we should put that in the guidance document (along with a note
>>>>> that 0-33 map to low, 34 - 66 map to medium, and 67 - 100 map to
>>>>> high, unless we want to do it non-linearly). If the _vast_majority_
>>>>> of the users of this field use a 100-point scale with 100 meaning
>>>>> "yes" and 0 meaning "any resemblance these values may have to actual
>>>>> fact is purely coincidental", then let's consider renaming it
>>>>>"percent"
>>> in 5070-bis.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Brian (as contributor)
>>>>>
>>>>>
>>>>> On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"
>>>>> <[email-masked]> wrote:
>>>>>
>>>>> Please see section 3.10.4 of RFC5070 as a starting point.  We can
>>>>> change it if it needs to be changed.  The value is for a confidence
>>>>> rating on the indicators shared.  The definitions may be helpful for
>>>>> anyone who wants to work on this discussion.  IODEF has various
>>>>> markers that can be used in a complimentary way without conflating
>>>>> the markers meaning.
>>>>>
>>>>> I think some people using IODEF find the numerical values more
>>>>> helpful, and it would be good to understand what people have learned
>>>>> from using the current structure (what works/does not work).  The
>>>>> scales I have seen are 0-100.  There is of course a subjective
>>>>> element to assigning a numerical value to the confidence and it may
>>>>> vary from entity to entity.  With this type of rating you may need to
>>>>> consider who it came from and how they scored the confidence rating
>>>>> to map to your own rating.  It would be good to hear more thoughts on
>>> this.
>>>>>
>>>>> Thanks,
>>>>> Kathleen
>>>>>
>>>>> From: C. Henry Adams & BIE [mailto:[email-masked]]
>>>>> Sent: Tuesday, February 12, 2013 2:46 PM
>>>>> To: MILE IETF
>>>>> Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>>
>>>>> Regarding the IOCs or Indicators of Compromise, Chris made a vital
>>>>> point.  Different Confidence levels will cause confusion.  It appears
>>>>> that there maybe a need for some type of simplified standardization
>>>>> to be established between all Sharing Groups in this regard.
>>>>>
>>>>> Perhaps numerical scoring set at lower values should express levels
>>>>> of urgency.
>>>>> ( i.e.  1 = Less Likely,   2 = Probable,  3 = A Concern,  4 =
>>>>>Urgent,
>>>>> 5 = Imminent )
>>>>>
>>>>> Thanks,
>>>>> C. Henry Adams
>>>>>
>>>>>
>>>>>
>>>>> I see some confusion coming down the pike if we start using
>>>>> Confidence the way it is supported. If I am using low/med/high and
>>>>> someone sends me an IoC with a score of 70, what does that mean to
>>>>> me? What if I am using a scale of
>>>>> 1 to 4 and someone else is on a scale of 1 to 5? We lose the ability
>>>>> to describe something with a consistent language. It really gets ugly
>>>>> when we store IoC from multiple sources. I have confidence values
>>>>> that are numeric as well as text.  Makes searching / sorting very
>>>>> problematic.
>>>>>
>>>>> At this point we have to roll with what we have. I would strongly
>>>>> recommend that we revisit this at some point.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: Moriarty, Kathleen
>>>>> Sent: Tuesday, February 12, 2013 9:59 AM
>>>>> To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul;
>>>>> 'MILE IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> Hi Chris & Take,
>>>>>
>>>>> I'll just focus on the confidence scoring.  Right now, the schema
>>>>> allows for you to either use a numerical score OR the ratings of low,
>>>>> medium, and high.
>>>>> Different sharing groups can decide how they want to share the data.
>>>>> If
>>>>> people were to use the numerical values, I agree it would be helpful
>>>>> to have guidance.  This could go in the IODE guidance document.
>>>>>
>>>>> I have seen examples of current users that use each of the
>>>>> approaches, so we'll need to keep the option for backwards
>>>>> compatibility and it is nice to keep in flexible options where we
>>>>> can.
>>>>>
>>>>> Thank you,
>>>>> Kathleen
>>>>>
>>>>> -----Original Message-----
>>>>> From: Harrington, Christopher
>>>>> Sent: Tuesday, February 12, 2013 9:22 AM
>>>>> To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE
>>>>> IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> The number of indicators wouldn't necessarily drive the use of
>>>>> indicator_set_id. The purpose is to show relationship. If I sent 3 IP
>>>>> addresses that were used as C2 for 3 different campaigns I would have
>>>>> separate indicator_set_ids, each with one of the 3 C2 IPs
>>>>>
>>>>> My suggestion would be a simple low, medium, high. I think if we
>>>>> break it down to more levels than that we would need to provide
>>>>> guidance on scoring, rating, etc. I think most people should be able
>>>>> to understand low/med/high without having to have a mathematical
>>>>> method for arriving at the level.
>>>>>
>>>>> Low - I am not sure
>>>>> Medium - I am reasonably sure
>>>>> High - I am very sure
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>> -----Original Message-----
>>>>> From: Takeshi Takahashi [mailto:[email-masked]]
>>>>> Sent: Tuesday, February 12, 2013 4:21 AM
>>>>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul;
>>>>> 'MILE IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> Regarding the indicator_set_id, I agree, it is useful when we need to
>>>>> deal with large sets of indicators.
>>>>> Since indicator_set_id attribute is optional (right?), it could be
>>>>> omitted if we need to deal with only small number of indicators.
>>>>>
>>>>> Regarding the use case, I like the idea of using the confidence
>>>>> attribute for the reason Chris kindly described.
>>>>> I would like to hear a bit more on this: is it going to be numerical?
>>>>> For
>>>>> instance, 1 means "no confidence" while 5 means "strong confidence",
>>>>> etc?
>>>>>
>>>>> Thank you.
>>>>> Take
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Harrington, Christopher [mailto:[email-masked]]
>>>>> Sent: Friday, February 08, 2013 4:11 AM
>>>>> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE
>>>>> IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> With respect to tying things back to threat actors, from what I have
>>>>> seen and use this is a generally accepted grouping:
>>>>>
>>>>> Indicator --> Indictor Set --> Campaign --> Threat Actor
>>>>>
>>>>> Campaign and Threat Actor are where having a "Confidence" attribute
>>>>> would be beneficial as making those associations is not a perfect
>>>>> science by any means.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Moriarty, Kathleen
>>>>> Sent: Thursday, February 07, 2013 2:00 PM
>>>>> To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE
>>>>> IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> Hi Take & others,
>>>>>
>>>>> Thanks for chiming in, I've been talking about this with Chris and a
>>>>> few others on their use cases and would like more opinions.  I'll
>>>>> provide an option below from what we have discussed from a CIRC view
>>>>> point.  We are also wondering how to also provide logic in IODEF that
>>>>> could cross over into SCI attached schemas or IODEF extensions (the
>>>>> solutions may all tie together with this discussion - or there may be
>>>>> better/more elegant solutions others would like to propose).
>>>>>
>>>>> -----Original Message-----
>>>>> From: Takeshi Takahashi [mailto:[email-masked]]
>>>>> Sent: Tuesday, February 05, 2013 12:04 PM
>>>>> To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen;
>>>>> 'MILE IETF'
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> I like this discussion.
>>>>> I agree, it would be good idea to have indicator identifiers inside
>>>>> the IOC-related classes.
>>>>>
>>>>> KMM: At the class level, we may have several indicators listed that
>>>>> should be viewed as a set and may have another instance of that same
>>>>> class that is a related issue, but a separate set.  We could as you
>>>>> say, list the indicator IDs connected through the reference class.
>>>>> The set IDs might give us other ways to group the values when we get
>>>>> into logic and relationships between sets or indicators.  This could
>>>>> also be a way to connect indicators or sets across XML documents that
>>>>> could have been shared previously.  If there are a large number of
>>>>> indicators in the set, then this becomes useful, for smaller sets, I
>>>>> agree it doesn't make as much sense.
>>>>>
>>>>> What do others think?
>>>>>
>>>>> Then for indicators not included in the base schema that may not fit
>>>>> into a category in the SCI draft, do we create a place for these off
>>>>> of SCI or right off of the IODE schema in EventData?
>>>>> (more details
>>>>> on
>>>>> this in my first message).
>>>>>
>>>>> If we could see any indicator of compromise as computer event record,
>>>>> we could use SCI:EventReport class as the place for the XML-based
>>>>> IOCs that couldn't fit anywhere else.
>>>>>
>>>>> KMM: That sounds like a good idea to me.  This should go into
>>>>> guidance in the SCI draft.  Does anyone else want to weigh in?
>>>>>
>>>>>
>>>>> For the non-XML IOCs, we could use RecordData class, as suggested.
>>>>> KMM: Sounds good, thanks!
>>>>>
>>>>> I agree to have indicator_uid, but I am not sure about the needs of
>>>>> the indicator_set_id.
>>>>> I understand we could do some grouping of individual indicator_uids
>>>>> and its usability, but I am not sure whether we do not have any other
>>>>> way to express these groupings.
>>>>> For instance,  a Reference class refers to several indicadtor_uids.
>>>>> In
>>>>> this case, they could be, in a sense, grouped. Isn't it enough?
>>>>>
>>>>> KMM: It may be, what do you think about large sets of indicators or
>>>>> subsequent messages that add indicators to existing sets?  Would this
>>>>> happen?  Would it be easier to express relationships with sets of
>>>>> indicators in addition to individual indicators?  By using this, it
>>>>> could give us a unique way to also provide the logic and
>>>>> relationships in a new class of IODEF so we don't have to worry about
>>>>> adding it into the current structure.
>>>>> If there are better ways to handle that, and others can provide some
>>>>> options, that would be appreciated!
>>>>>
>>>>> Thank you,
>>>>> Kathleen
>>>>>
>>>>> I would appreciate if anybody could share expertise on this. Though I
>>>>> think I have read all the emails in the list, I might have
>>>>> mis-understood some points.
>>>>>
>>>>> By the way, I think the indicator_uids should be added to the SCI
>>>>> classes'
>>>>> attributes so that they can be correlated with another information as
>>>>> well.
>>>>>
>>>>> Thanks
>>>>> Take
>>>>>
>>>>>
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of Harrington, Christopher
>>>>> Sent: Tuesday, February 05, 2013 4:25 AM
>>>>> To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> I think some sort of group ID would do the trick. We also need a
>>>>> logical and / or somewhere to show relationship between indicators.
>>>>> If
>>>>> I give you
>>>>> 2
>>>>> registry keys do they both have to be present to be an indication of
>>>>> compromise or is either one by themselves an indicator? Both would
>>>>> have the same group ID since they are related.
>>>>>
>>>>> Thanks,
>>>>> --Chris
>>>>>
>>>>> From: Stoecker, Paul
>>>>> Sent: Sunday, February 03, 2013 8:26 PM
>>>>> To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> What if we added indicator group ID along with the indicator_uid?
>>>>> This would allow you to group indicators that are related into the
>>>>> same group ID.
>>>>> Would this resolve the issue?
>>>>>
>>>>> It is either that or going back to adding a Detection (or Indicators)
>>>>> class that will should be used to take all of the indicators put them
>>>>> into one place and have the ability to group the ones that go
>>>>> together.  I don't mean a place to put indicators that are missing
>>>>> from IODEF.I mean a place in the IODEF document where you put the
>>>>> indicators that are used for detection and prevention of the shared
>>>>> Incident.  I don't know the answer here, but there has got to be a
>>>>> good way for indicators to be identified and being able to group them
>>>>> as Chris has suggested without basically recreating something
>>>>> complicated like STIX.
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> Paul W. Stoecker, Ph.D.
>>>>> SMC Lead Content Architect
>>>>> RSA, The Security Division of EMC
>>>>> cell: 302.379.3375 | e: [email-masked]
>>>>>
>>>>>
>>>>> From: <Moriarty>, Kathleen <[email-masked]>
>>>>> Date: Sunday, February 3, 2013 5:11 PM
>>>>> To: "Harrington, Christopher" <[email-masked]>, MILE
>>>>> IETF <[email-masked]>
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I agree, we have some work to do in the updated IODEF, RFC5070-bis.
>>>>>
>>>>> The list has already said they would like to see indicators added to
>>>>> the definitions in RFC5070-bis, to be more explicit about including
>>>>> indicators and sets of indicators in IODE documents as opposed to
>>>>> 'parts of an incident or the useful information on an incident for
>>>>> sharing purposes.  It was written before we used terms like
>>>>> indicators.  With that in mind, Rosella proposed a number of changes
>>>>> back in July, both for guidance and for format updates.  It may help
>>>>> to have the first draft try to address at least some of these issues
>>>>> so people can understand the problems and at least a proposed
>>>>> solution.
>>>>>
>>>>> As you point out, we need to be able to show relationships between
>>>>> sets of indicators, where we may have a few sets of indicators that
>>>>> could have a relationship to each other within a document.  In the
>>>>> July presentation, one of the questions was to see if we should add
>>>>> new category attribute values for the System class that would connect
>>>>> the list of included indicators.  I think we should still keep the
>>>>> concept of a Node to a single node, but perhaps within System, list
>>>>> multiple sets of Nodes that may be one type of attack.  Rosella had
>>>>> suggested pulling forward the "FraudType" from RFC5901, this would
>>>>> help solve the issue as NodeRole values would compliment an
>>>>> AttackType (FraudType values could be included in AttackType or some
>>>>> broader term).  It may be better to have the FraudTypes, plus
>>>>> attribute values like "C2-server", "sinkhole",  "MalwareDistribution"
>>>>> for added context so you know what to do with the received set of
>>>>> indicators.
>>>>>
>>>>> I am proposing that we change IODEF to include multiple sets of
>>>>> indicators, add an AttackType attribute (or some other name), a
>>>>> method to connect indicators and indicator sets within an IODEF using
>>>>> an attribute of indicator_uid (or some other name) with a string
>>>>> value to make the connection points, and add a few indicators that
>>>>> are commonly shared into the base IODEF.
>>>>>
>>>>> Back in July, we talked about adding Registry Key/Value pairs and
>>>>> hashes to the main IODEF document (trying to see if this will help
>>>>> Chris below).  What if we added the Registry Key/Value pairs as a
>>>>> class off of RecordData, using a similar structure to what is in
>>>>> RFC5901, and also added the ability to include hashes in RecordData?
>>>>> I think if we then had the indicator_uid at the RecordData level, we
>>>>> could connect a set within that structure and repeat the structure
>>>>> for other sets in the same way we would do with Node inside of the
>>>>> System class, using the indicator_uid to tie the set together.  Then
>>>>> at the more specific level for the hash, registry Key/value, IP, etc.
>>>>> use an indicator_uid if we needed them marked at this level as well?
>>>>> Maybe we want indicator_set at the higher level?  I'd like some
>>>>> opinions on this approach.  +1 if you agree, suggestions if you have
>>>>> other ideas that may work better.
>>>>>
>>>>> We'll also need to worry about marking the indicators to prevent
>>>>> forward sharing when not permitted.  We may want to use these values
>>>>> or something else.
>>>>>
>>>>> Thank you!
>>>>> Kathleen
>>>>>
>>>>> From: Harrington, Christopher
>>>>> Sent: Friday, February 01, 2013 12:01 PM
>>>>> To: Moriarty, Kathleen; MILE IETF
>>>>> Subject: RE: [mile] IOCs
>>>>>
>>>>> I think we have a bigger relationship issue to address. Let use the
>>>>> Watchlist Use Case. A bunch of indicators are sent in one message. In
>>>>> that message we could have groupings of indicators that we need to
>>>>> show are
>>>>> related:
>>>>>
>>>>> Two or more indicators of different type that relate to the same
>>>>> threat:
>>>>>      The file hash of a malicious file and the URL of the C2 that
>>>>> the file uses. Either or both may be present to indicate a
>>>>> compromise.
>>>>>
>>>>> Two or more indicators of the same type that relate to the same
>>>>> threat:
>>>>>      2 different registry values for the same registry key. If
>>>>> either value is present it is a compromise indicator but both will
>>>>> not be present.
>>>>>
>>>>> The problem compounds itself very quickly. Consider the scenario
>>>>> where both groupings above are part of the same threat. I need to
>>>>> show that logical groupings of Indicators are related as well. We
>>>>> can't send multiple IODEF messages for this from what I remember
>>>>> reading.
>>>>>
>>>>> The last one I can think of would be when you have 2 different
>>>>> indicators that represent the same indicator. It's not uncommon to
>>>>> send both the
>>>>> MD5
>>>>> and SHA1 hash of a malicious file. The indicator is the file but the
>>>>> IOCs are the 2 hash values. How do we show they are related? If we
>>>>> use a unique Inidcator ID for each hash value there needs to be a
>>>>> higher level grouping.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Chris
>>>>>
>>>>> Christopher Harrington
>>>>> Consulting Security Engineer
>>>>> GSO - Critical Incident Response Center EMC - Where Information Lives
>>>>> 174 Middlesex Turnpike
>>>>> Bedford, MA 01730
>>>>> 781-515-5862 (work)
>>>>> 603-583-1585 (cell)
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of Moriarty, Kathleen
>>>>> Sent: Friday, February 01, 2013 11:28 AM
>>>>> To: MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> All -
>>>>>
>>>>> I'd like your input and will refocus the thread to get opinions from
>>>>> the list on options to help solve the problems raised in my message
>>>>> and additionally in Paul's message.
>>>>>
>>>>> Interesting point, C. Henry.  Our objective here is to have machine
>>>>> automated exchanges, so we rely on encryption rather than obfuscation
>>>>> to achieve the necessary level of confidentiality.
>>>>>
>>>>> Paul mentioned the need to distinguish indicators of compromise from
>>>>> context information that may also include IP address or other data
>>>>> that could be indicators.  The question I raised was on how to
>>>>> connect sets of indicators in the same IODEF document, assuming the
>>>>> ability to have watchlists that could have several sets of indicators
>>>>> included, as well as to connect indicators that may be included in
>>>>> embedded schemas.
>>>>>
>>>>> If we add an attribute on all of the relevant indicators, let's say
>>>>> 'indicator-uid' how do we mark the indicators?  Do we use this to
>>>>> mark who sent the indicator as well so that we can prevent forward
>>>>> sharing when it is not permitted or handle that separately?
>>>>>
>>>>> Then for indicators not included in the base schema that may not fit
>>>>> into a category in the SCI draft, do we create a place for these off
>>>>> of SCI or right off of the IODE schema in EventData? (more details on
>>>>> this in my first message).
>>>>>
>>>>> Comments and questions encouraged to figure out the right technical
>>>>> solution to have this machine automatable.
>>>>>
>>>>> Thank you,
>>>>> Kathleen
>>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of C.
>>>>> Henry Adams & BIE
>>>>> Sent: Monday, January 28, 2013 11:25 PM
>>>>> To: MILE IETF
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Temporal Dependency sounds interesting.  I remember when I first ran
>>>>> across this particular craft, an experienced colleague asked me a
>>>>> peculiar question.  He said, " How do you stop someone from tracking
>>>>> the IP Address to your computer?"
>>>>>
>>>>> I replied, "I don't know, how?"
>>>>>
>>>>> Then he said, "Cut the dog-gone thing off  and the modem that it is
>>>>> connected- which is constantly on!"   LOL
>>>>>
>>>>> Here's my point (Hypothetical Situation) :  There is a 1st Responder
>>>>> searching a Neighborhood for Survivors which were hit by a Disaster
>>>>> or let's just say "Live" Terrorist Situation.  He /or She needs to
>>>>> communication back to other Officials that he /or somehow is in
>>>>> Danger.  The device used to communicate has been captured by the
>>>>> great minds of the enemy.  It's only a matter of time before they
>>>>> utilize reverse engineering to figure out how it functions.  However,
>>>>> their pride comes before a fall when seeking the location of other
>>>>> similar devices to attack.  Why? Perhaps the less thought of concepts
>>>>> that makes the device function properly, saves the day by disguise or
>>>>> cutting it off (figuratively speaking).
>>>>>
>>>>> Just a visionary thought.
>>>>>
>>>>> C. Henry Adams
>>>>> [email-masked]
>>>>> http://biemediagroup.com
>>>>>
>>>>>
>>>>> The information contained herein is for the exclusive use of the
>>>>> original recipient. This information is granted for limited
>>>>> distribution within the recipient's place of business for planning
>>>>> purposes only. Further dissemination, whether private or public is
>>>>> prohibited.
>>>>>
>>>>> --- On Mon, 1/28/13, Dave Misell <[email-masked]> wrote:
>>>>>
>>>>> From: Dave Misell <[email-masked]>
>>>>> Subject: Re: [mile] IOCs
>>>>> To: "C. Henry Adams & BIE" <[email-masked]>
>>>>> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with
>>>>> DNS SEC a pemanent and temporal key, with a temporal Id?
>>>>>
>>>>> Yours Faithfully,
>>>>>
>>>>> Dave Misell MSc CISSP
>>>>> SilentCircle  dsm
>>>>> 07710 380044
>>>>> [email-masked]
>>>>>
>>>>>
>>>>> On 29 Jan 2013, at 00:39, C. Henry Adams & BIE
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>
>>>>> Serialization of a particular Lists of XML Classes in a unique way
>>>>> was closely related to what I attempted to express when I stated,
>>>>> "consider to a degree what appears to be illogical in brilliant minds
>>>>> in some instances."
>>>>>
>>>>> However, I see Dr. Stoecker's point a little clearer.  However, it
>>>>> would be nice if the UID was in some way disguised from those who
>>>>> study this Security Art Form in a negative way.
>>>>>
>>>>> C. Henry Adams
>>>>> [email-masked] (Direct Email) [email-masked]
>>>>>
>>>>>
>>>>> The information contained herein is for the exclusive use of the
>>>>> original recipient. This information is granted for limited
>>>>> distribution within the recipient's place of business for planning
>>>>> purposes only. Further dissemination, whether private or public is
>>>>> prohibited.
>>>>>
>>>>> Re: [mile] IOCs
>>>>>
>>>>> Sunday, January 27, 2013 8:52 PM
>>>>> From:
>>>>> "Stoecker, Paul" <[email-masked]>
>>>>> To:
>>>>> "[email-masked]" <[email-masked]>
>>>>> I would like to look at this from a slightly different
>>>>> perspectiveSlet's say I get an XML document that tells me about an
>>>>> incident.  This document has source IP and destination IP that is
>>>>> being shared.  However, what I don't know is which IP address is my
>>>>> indicator and which is just a contextual piece of information.  This
>>>>> means that my detection product isn't going to know which one to use
>>>>> either, because there is nothing to tell me which IP is the one, even
>>>>> if the roles are set it still might not be enough to tell my system
>>>>> which one I should use as the indicator.
>>>>>
>>>>> If we had something like indicator_id as an attribute, it would allow
>>>>> us to easily identify indicators from contextual data.  I do admit to
>>>>> being biased as I have spent much of my career working on the
>>>>> monitoring and detection side of these things, so I am just thinking
>>>>> of ways to make it very clear what the indicators are in the XML
>>>>> document and the other data that may be important as I investigate
>>>>> activity that I have detected off of those indicators.
>>>>>
>>>>>
>>>>> I did suggest the detection class, but I think we may get more
>>>>> flexibility with the indicator_uid.  One thing that I haven't
>>>>> considered is the UID portion of thisShow do we use that UID?  How is
>>>>> the UID created?  Are there standards for UIDs?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>> Paul W. Stoecker, Ph.D.
>>>>> SMC Lead Content Architect
>>>>> RSA, The Security Division of EMC
>>>>> cell: 302.379.3375 | e: [email-masked]
>>>>>
>>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE <[email-masked]>
>>>>> wrote:
>>>>>
>>>>> From: C. Henry Adams & BIE <[email-masked]>
>>>>> Subject: RE: [mile] IOCs
>>>>> To: "KathleenMoriarty" <[email-masked]>
>>>>> Cc: [email-masked]
>>>>> Date: Saturday, January 26, 2013, 6:17 PM
>>>>>
>>>>> Greetings Kathleen,
>>>>>
>>>>> Your logic stimulates my visionary brain because I'm amazed at the
>>>>> many avenues you review with this approach at once.  However,  could
>>>>> you share a few advantages and disadvantages to the latter?
>>>>> --------------------------------------------------------------------
>>>>> --------
>>>>> ----------------------------------------------
>>>>> "we could continue to group items in logical places as is done now in
>>>>> IODEF and then have the extension point for combined indicators via
>>>>> SCI."
>>>>> --------------------------------------------------------------------
>>>>> --------
>>>>> ---------------------------------------------
>>>>>
>>>>> You pointed out what you consider to be logical places, but if I
>>>>> wanted to protect information from parties capable of ascertaining it
>>>>> from your logical places, perhaps we should also consider to a degree
>>>>> what appears to be illogical in brilliant minds in some instances.
>>>>>
>>>>>
>>>>>
>>>>> C. Henry Adams
>>>>> [email-masked] (Direct Email)
>>>>> [email-masked]
>>>>>
>>>>> The information contained herein is for the exclusive use of the
>>>>> original recipient. This information is granted for limited
>>>>> distribution within the recipient's place of business for planning
>>>>> purposes only. Further dissemination, whether private or public is
>>>>> prohibited.
>>>>>
>>>>> --- On Sat, 1/26/13, Moriarty, Kathleen <[email-masked]>
>>>>> wrote:
>>>>>
>>>>> From: Moriarty, Kathleen <[email-masked]>
>>>>> Subject: RE: [mile] IOCs
>>>>> To: "C. Henry Adams & BIE" <[email-masked]>, "[email-masked]"
>>>>> <[email-masked]>
>>>>> Date: Saturday, January 26, 2013, 10:13 AM
>>>>>
>>>>> Hello C. Henry & others,
>>>>>
>>>>> Thanks for taking a look at this.  We have a few considerations in
>>>>> this email thread I would like to hear thoughts on (and there may be
>>>>> more once RFC5070-bis is actively edited).
>>>>>
>>>>> The AdditionalData class and the RecordItem class both allow for
>>>>> non-XML extensions.  Where you place the extensions should be
>>>>> specific to the logical grouping of the parent elements so you can
>>>>> understand more about the included data in most cases.
>>>>>
>>>>> The Impact class can be used to provide context information on the
>>>>> included data of the report and also can include a confidence rating
>>>>> on the report as a whole.  Extensions related to impact would be one
>>>>> level higher (at the moment) in the Assessment class using the
>>>>> AdditionalData extension point.
>>>>>
>>>>> Take asked about including vulnerability information, I would think
>>>>> that would fit under the Vulnerability extension point of the SCI
>>>>> draft in the Method class.  He did ask about non-XML.  RecordItem or
>>>>> AdditionalData do allow for non-XML extension points, we could either
>>>>> have the SCI draft handle these as well or have the extensions that
>>>>> are non-XML come directly off the AdditionalData or RecordItem
>>>>> classes according to what makes sense from a logical standpoint.
>>>>>
>>>>> As for my question, it was two-fold.
>>>>>
>>>>> Indicator based schemas have a reference number or a GUID for the
>>>>> various indicators they share.  If we are extending to embed other
>>>>> schemas that include such reference or GUID identifiers, do we want
>>>>> to add an attribute to the various elements in IODEF that could be
>>>>> indicators?  Is this enough to make the connections or is something
>>>>> else else needed?  We could add something like an Indicator_ID in
>>>>> RFC5070-bis which would then correlate to the reference or GUID
>>>>> identifiers.
>>>>>
>>>>> Then the other question was on how to include indicators that are not
>>>>> in the base schema that may be related or have language with "and"
>>>>> "or"
>>>>> to
>>>>> specify the relationships.  In some cases, you will want to group
>>>>> these indictors in one extension point, where they may fit logically
>>>>> in multiple places if the relationships did not need to be shown in
>>>>> the data format.  If we have cases like this where you need more
>>>>> complex representations, should we use one extension point via the
>>>>> SCI draft off of the EventData class AdditionalData extension point?
>>>>> Opinions are needed here....
>>>>>
>>>>> A few people have mentioned wanting to include some commonly shared
>>>>> indictors into the base IODEF document.  We could have a catch-all
>>>>> class that does this and has an extension point off of it in
>>>>> EventData or we could continue to group items in logical places as is
>>>>> done now in IODEF and then have the extension point for combined
>>>>> indicators via SCI.  I think I like the latter approach.
>>>>>
>>>>> Thank you,
>>>>> Kathleen
>>>>> ________________________________________
>>>>> From: [email-masked] [[email-masked]] On Behalf Of C.
>>>>> Henry
>>>>> Adams & BIE [[email-masked]]
>>>>> Sent: Saturday, January 26, 2013 3:05 AM
>>>>> To: [email-masked]
>>>>> Cc: C. Henry Adams
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Greetings Everyone,
>>>>>
>>>>> Take mentioned two types of indicators based on the :
>>>>> --------------------------------------------------------------------
>>>>> --------
>>>>> --------------------------
>>>>> 1) If the indicators are something like an XML-based alert/warning of
>>>>> information leakage, it could be an event that are conveyed in the
>>>>> SCI's EventReport class, IMHO.
>>>>>
>>>>> 2) If the indicators are something like an non-XML ones, I guess it
>>>>> could be conveyed without using SCI draft.
>>>>> For instance, we could use Impact class of the base IODEF to convey
>>>>> the indicators.
>>>>> We could for instance extend the list of indicators of the Impact
>>>>> class, if needed.
>>>>> --------------------------------------------------------------------
>>>>> --------
>>>>> --------------------------
>>>>>
>>>>> In doing so he pointed out the "Impact Class"
>>>>>
>>>>> Whereas, Kathleen stated,
>>>>> --------------------------------------------------------------------
>>>>> --------
>>>>> -------------------------
>>>>> For the discussion below, I was thinking more of combined set with
>>>>> relationships that may be included in a single extension point, so
>>>>> that's why I was thinking about the EventData class, but there may be
>>>>> better locations or a specific area within the EventData.
>>>>>
>>>>> Paul Stoecker had suggested a "Detection" class as a consideration.
>>>>> --------------------------------------------------------------------
>>>>> --------
>>>>> ------------------------
>>>>>
>>>>> Kathleen thoughts related yet still with other indicators and the
>>>>> EventData Class.
>>>>>
>>>>> Is there a possible way to create a new XML class which encompass
>>>>> combining the EventData, Detection and base IODEF classes to simplify
>>>>> this issue?
>>>>>
>>>>>
>>>>> C. Henry Adams
>>>>> [email-masked] (Direct Email)
>>>>> [email-masked]
>>>>>
>>>>>
>>>>> The information contained herein is for the exclusive use of the
>>>>> original recipient. This information is granted for limited
>>>>> distribution within the recipient's place of business for planning
>>>>> purposes only. Further dissemination, whether private or public is
>>>>> prohibited.
>>>>> _______________________________________________
>>>>> mile mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>
>>>>> _______________________________________________
>>>>> mile mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>
>>>>> _______________________________________________
>>>>> mile mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mile mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>
>>>>> _______________________________________________
>>>>> mile mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>
>>>>> _______________________________________________
>>>>> mile mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>
>>>> _______________________________________________
>>>> mile mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mile
>>>
>>> _______________________________________________
>>> mile mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mile
>>>
>>
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile
>>
>
>_______________________________________________
>mile mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mile
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 20 Feb 2013 02:46:39 -0500

I'd prefer that we don't break the functionality used by a large community (CIF).  Instead of deprecating a feature now, why don't we go down the route of stating a strong preference (RECOMMENDED) for using the tags and listing a mapping in rfc5070bis for the numeric values?

I'd like to hear from some of the current users as well.

We can revisit this again before we finalize the draft.

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of C. Henry Adams & BIE [[email-masked]]
Sent: Wednesday, February 20, 2013 12:29 AM
To: MILE IETF
Subject: Re: [mile] IOCs

Greetings Everyone,

C. Henry Adams

Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>

On 2/19/13 9:43 AM, "Eric Burger" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:

><[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:
>
>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf Of Eric
>>Burger [[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>]
>><[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:
>>
>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf Of
>>> Banghart, John
>>> On 2/16/13 12:42 PM, "Eric Burger" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>wrote:
>>>
>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:
>>>>
>>>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
>>>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
>>>>> Of C. Henry Adams & BIE
>>>>> From: <Banghart>, John Banghart <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> To: "Stoecker, Paul" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>, Kathleen Moriarty
>>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>, Brian Trammell <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Cc: "C. Henry Adams & BIE" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>, MILE IETF
>>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Paul,
>>>>>
>>>>> On 2/13/13 8:04 AM, "Stoecker, Paul" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:
>>>>>
>>>>> cell: 302.379.3375 | e: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2/13/13 7:48 AM, "Moriarty, Kathleen" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> wrote:
>>>>>
>>>>> Hi, Kathleen, all,
>>>>>
>>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:
>>>>>
>>>>> From: C. Henry Adams & BIE [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>]
>>>>> From: Takeshi Takahashi [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>]
>>>>> From: Harrington, Christopher [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>]
>>>>> From: Takeshi Takahashi [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>]
>>>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
>>>>> cell: 302.379.3375 | e: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>>
>>>>> From: <Moriarty>, Kathleen <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> To: "Harrington, Christopher" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>, MILE
>>>>> IETF <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
>>>>> Of Moriarty, Kathleen
>>>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
>>>>> Of C.
>>>>> Henry Adams & BIE
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> http://biemediagroup.com
>>>>>
>>>>>
>>>>> --- On Mon, 1/28/13, Dave Misell <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:
>>>>>
>>>>> From: Dave Misell <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Subject: Re: [mile] IOCs
>>>>> To: "C. Henry Adams & BIE" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>>
>>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> wrote:
>>>>>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> (Direct Email) [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>>
>>>>> "Stoecker, Paul" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> To:
>>>>> "[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> cell: 302.379.3375 | e: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>> --- On Sat, 1/26/13, C. Henry Adams & BIE <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> wrote:
>>>>>
>>>>> From: C. Henry Adams & BIE <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Subject: RE: [mile] IOCs
>>>>> To: "KathleenMoriarty" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Cc: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> (Direct Email)
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>> --- On Sat, 1/26/13, Moriarty, Kathleen <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> wrote:
>>>>>
>>>>> From: Moriarty, Kathleen <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> Subject: RE: [mile] IOCs
>>>>> To: "C. Henry Adams & BIE" <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>, "[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>"
>>>>> <[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>>
>>>>> From: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> [[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf Of C.
>>>>> Henry
>>>>> Adams & BIE [[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>]
>>>>> To: [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> Cc: C. Henry Adams
>>>>> Subject: Re: [mile] IOCs
>>>>>
>>>>> Greetings Everyone,
>>>>>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]> (Direct Email)
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>>
>>>>>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>> [email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>
>[email-masked]<http://us.mc1216.mail.yahoo.com/mc/compose?to=[email-masked]>