Subject: Re: [mile] IOCs

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

RFC5070 Chapter 3 section 10 item 4 does not appear to restrict conflation of a numeric value and its definition. I would guess that what I'm really trying to state here is there should perhaps be a simple standardization establish in a sort of an Alpha-numeric value if possible as oppose to a numeric value.

Please see (Revision) below:
( i.e.  1LL = Less Likely,   2P = Probable,  3AC = A Concern,  4U =  Urgent,  5I = Imminent )

I would concur, perhaps Sharing Groups regarding the IODEF should be given a survey of some kind to address potential issues with the High, Medium, Low assessment combined with a numeric rating  0 - 100 to possibly revisit creating a simplified approach.

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
> > perspectiveŠlet'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 thisŠhow 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
> 
>