Subject: Re: [mile] IOCs

From: "C. Henry Adams & BIE" <[email-masked]>
Date: Wed, 13 Feb 2013 07:24:08 -0800 (PST)

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
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

_______________________________________________
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: Kevin Neely <[email-masked]>
Date: Wed, 13 Feb 2013 16:29:27 +0000

Merely as a data point, here is a reference to the Collective Intelligence Framework's description of confidence levels.  They also use 5 categories with numeric ranges.  More detail available at the link:
https://code.google.com/p/collective-intelligence-framework/wiki/TaxonomyConfidence_v1

Certain (95 - 100)
Very Confident (85 - 94)
Somewhat Confident (75 - 84)
Not Confident (50 - 74)
Unknown (0 - 49)
cheers,
K

From: "C. Henry Adams & BIE" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 13, 2013 7:24 AM
To: MILE IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] IOCs

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.

Vs:

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<http://www.mcafee.com/>

From: <Banghart>, John Banghart <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Date: Wednesday, February 13, 2013 7:16 AM
To: "Stoecker, Paul" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>, Kathleen Moriarty <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>, Brian Trammell <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Cc: "C. Henry Adams & BIE" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>, MILE IETF <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Subject: Re: [mile] IOCs

Paul,

-John

On 2/13/13 8:04 AM, "Stoecker, Paul" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:

1-33 = Low
34-67= Medium
68-100=High

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

On 2/13/13 7:48 AM, "Moriarty, Kathleen" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
wrote:

Hello,

Vs:

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

Sent from my iPhone

On Feb 13, 2013, at 2:14 AM, "Brian Trammell" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
wrote:

Hi, Kathleen, all,

Best regards,

Brian (as contributor)

On Feb 12, 2013, at 9:56 PM, "Moriarty, Kathleen"
<[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:

Thanks,
Kathleen

From: C. Henry Adams & BIE [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>]
Sent: Tuesday, February 12, 2013 2:46 PM
To: MILE IETF
Cc: Moriarty, Kathleen; 'Takeshi Takahashi'; Stoecker, Paul
Subject: Re: [mile] IOCs

Thanks,
C. Henry Adams

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,

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

Low - I am not sure

Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>]
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

Thank you.
Take

-----Original Message-----
From: Harrington, Christopher [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>]
Sent: Friday, February 08, 2013 4:11 AM
To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

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,

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[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.

What do others think?

Thank you,
Kathleen

Thanks
Take

From: [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[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

Thanks,
--Chris

From: Stoecker, Paul

Paul

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

From: <Moriarty>, Kathleen <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Date: Sunday, February 3, 2013 5:11 PM
To: "Harrington, Christopher" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>, MILE
IETF <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Subject: Re: [mile] IOCs

Hi Chris,

Thank you!
Kathleen

Thoughts?

Thanks,

--Chris

Christopher Harrington

From: [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
Of Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] IOCs

All -

Thank you,
Kathleen

From: [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf
Of C.
Henry Adams & BIE
Sent: Monday, January 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

C. Henry Adams
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
http://biemediagroup.com

--- On Mon, 1/28/13, Dave Misell <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>> wrote:

From: Dave Misell <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[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]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE
<[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
wrote:

C. Henry Adams
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> (Direct Email) [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>

Re: [mile] IOCs

"Stoecker, Paul" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
"[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>

Regards,

Paul

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

--- On Sat, 1/26/13, C. Henry Adams & BIE <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
wrote:

From: C. Henry Adams & BIE <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Subject: RE: [mile] IOCs
To: "KathleenMoriarty" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Cc: [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
Date: Saturday, January 26, 2013, 6:17 PM

Greetings Kathleen,

C. Henry Adams
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> (Direct Email)
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>

--- On Sat, 1/26/13, Moriarty, Kathleen <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
wrote:

From: Moriarty, Kathleen <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Subject: RE: [mile] IOCs
To: "C. Henry Adams & BIE" <[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>, "[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>"
<[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>>
Date: Saturday, January 26, 2013, 10:13 AM

Hello C. Henry & others,

Thank you,
Kathleen
________________________________________
From: [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> [[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf Of C.
Henry
Adams & BIE [[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>]
Sent: Saturday, January 26, 2013 3:05 AM
To: [email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
Cc: C. Henry Adams
Subject: Re: [mile] IOCs

Greetings Everyone,

C. Henry Adams
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> (Direct Email)
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>

[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>

_______________________________________________
mile mailing list
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Harrington, Christopher" <[email-masked]>
Date: Wed, 13 Feb 2013 11:49:01 -0500

>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

Thanks,
C. Henry Adams

Vs:

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web:  <http://www.mcafee.com/> www.mcafee.com

From: <Banghart>, John Banghart <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >
Date: Wednesday, February 13, 2013 7:16 AM
To: "Stoecker, Paul" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >, Kathleen Moriarty <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >, Brian Trammell <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >
Cc: "C. Henry Adams & BIE" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >, MILE IETF <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >
Subject: Re: [mile] IOCs

Paul,

broad interoperability.

-John

On 2/13/13 8:04 AM, "Stoecker, Paul" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> > wrote:

1-33 = Low

34-67= Medium

68-100=High

difference?

Meets...your

;-)

 

Paul W. Stoecker, Ph.D.

cell: 302.379.3375 | e: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

 

On 2/13/13 7:48 AM, "Moriarty, Kathleen" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

wrote:

Hello,

Vs:

Any other opinions?

Thanks,

Kathleen

-----Original Message-----

From: Stoecker, Paul

To: Brian Trammell

Subject: Re: [mile] IOCs

the schema.

Sent from my iPhone

On Feb 13, 2013, at 2:14 AM, "Brian Trammell" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

wrote:

Hi, Kathleen, all,

than it needs to be.)

teams, I don't know.

Best regards,

Brian (as contributor)

<[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> > wrote:

meaning.

Thanks,

Kathleen

From: C. Henry Adams & BIE [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ]

To: MILE IETF

Subject: Re: [mile] IOCs

urgency.

5 = Imminent )

Thanks,

C. Henry Adams

the

an IoC

scale of

to

when we

numeric

recommend

Thanks,

--Chris

-----Original Message-----

From: Moriarty, Kathleen

'MILE

IETF'

Subject: RE: [mile] IOCs

Hi Chris & Take,

allows for

high.

If

to have

so

nice to

Thank you,

Kathleen

-----Original Message-----

IETF'

Subject: RE: [mile] IOCs

it

scoring,

low/med/high

level.

Low - I am not sure

High - I am very sure

Thanks,

--Chris

-----Original Message-----

From: Takeshi Takahashi [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ]

IETF'

Subject: RE: [mile] IOCs

deal

omitted

attribute

For

etc?

Thank you.

Take

-----Original Message-----

From: Harrington, Christopher [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ]

IETF'

Subject: RE: [mile] IOCs

science by any means.

Thanks,

--Chris

-----Original Message-----

From: Moriarty, Kathleen

IETF'

Subject: RE: [mile] IOCs

Hi Take & others,

-----Original Message-----

From: Takeshi Takahashi [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ]

'MILE

IETF'

Subject: RE: [mile] IOCs

I like this discussion.

the IOC-related classes.

What do others think?

(more details

on

guidance

 

the indicator_set_id.

In

relationships

into

the current

structure.

Thank you,

Kathleen

I

classes'

as

well.

Thanks

Take

From: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ] On Behalf

Subject: Re: [mile] IOCs

If

I give you

2

Thanks,

--Chris

From: Stoecker, Paul

Subject: Re: [mile] IOCs

same group ID.

complicated like STIX.

Paul

Paul W. Stoecker, Ph.D.

cell: 302.379.3375 | e: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

From: <Moriarty>, Kathleen <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

To: "Harrington, Christopher" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >, MILE

IETF <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

Subject: Re: [mile] IOCs

Hi Chris,

format

AttackType

values

context

indicators,

into the base IODEF.

for

that may work better.

or something else.

Thank you!

Kathleen

Subject: RE: [mile] IOCs

show are

related:

threat:

compromise.

threat:

not

be

present.

where

send both the

MD5

use

level

grouping.

Thoughts?

Thanks,

--Chris

Christopher Harrington

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

From: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ] On Behalf

Of Moriarty, Kathleen

To: MILE IETF

Subject: Re: [mile] IOCs

All -

connect

to

schemas.

mark

Thank you,

Kathleen

From: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  [mailto:[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ] On Behalf

Of C.

Henry Adams & BIE

To: MILE IETF

Subject: Re: [mile] IOCs

or

great

C. Henry Adams

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

http://biemediagroup.com

prohibited.

--- On Mon, 1/28/13, Dave Misell <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> > wrote:

From: Dave Misell <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

Subject: Re: [mile] IOCs

To: "C. Henry Adams & BIE" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

DNS

Yours Faithfully,

Dave Misell MSc CISSP

SilentCircle  dsm

07710 380044

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

<[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

wrote:

was

in some instances."

would

this

C. Henry Adams

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  (Direct Email) [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

original

within

the

Re: [mile] IOCs

From:

"Stoecker, Paul" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

To:

"[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> " <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

even

which

allow

to

 

is

Regards,

Paul

Paul W. Stoecker, Ph.D.

cell: 302.379.3375 | e: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

--- On Sat, 1/26/13, C. Henry Adams & BIE <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

wrote:

From: C. Henry Adams & BIE <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

Subject: RE: [mile] IOCs

To: "KathleenMoriarty" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

Cc: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

Greetings Kathleen,

many

share

a

--------

in

SCI."

--------

wanted to

appears

to

 

C. Henry Adams

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  (Direct Email)

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

original

within

the

--- On Sat, 1/26/13, Moriarty, Kathleen <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

wrote:

From: Moriarty, Kathleen <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

Subject: RE: [mile] IOCs

To: "C. Henry Adams & BIE" <[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >, "[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> "

<[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> >

Hello C. Henry & others,

this

once

non-XML

about

the

on

the

higher

extension

point.

that

the

AdditionalData

do

draft

directly

sense

various

that

attribute

enough

add

correlate

to

not

in

to

these

multiple

format.  If

should

class

class

we

could

then

like

the latter approach.

Thank you,

Kathleen

From: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  [[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ] On Behalf Of C.

Henry

Adams & BIE [[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> ]

To: [email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

Cc: C. Henry Adams

Subject: Re: [mile] IOCs

Greetings Everyone,

--------

of

could

be

the indicators.

class,

if

needed.

--------

--------

that's

--------

------------------------

EventData Class.

this

issue?

C. Henry Adams

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>  (Direct Email)

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

original

within

the

mile mailing list

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

mile mailing list

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

mile mailing list

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

 

mile mailing list

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]> 

mile mailing list

[email-masked] <http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 13 Feb 2013 14:04:59 -0500

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

Thanks,
--Chris

From: [email-masked]<mailto:[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

Thanks,
C. Henry Adams

Vs:

Kent Landfield

Paul,

-John

1-33 = Low
34-67= Medium
68-100=High

Paul W. Stoecker, Ph.D.

Hello,

Vs:

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

Sent from my iPhone

Hi, Kathleen, all,

Best regards,

Brian (as contributor)

Thanks,
Kathleen

Thanks,
C. Henry Adams

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,

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

Low - I am not sure

Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>]
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

Thank you.
Take

-----Original Message-----
From: Harrington, Christopher [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[email-masked]>]
Sent: Friday, February 08, 2013 4:11 AM
To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

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,

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]<http://us.mc534.mail.yahoo.com/mc/compose?to=[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.

What do others think?

Thank you,
Kathleen

Thanks
Take

Thanks,
--Chris

From: Stoecker, Paul

Paul

Paul W. Stoecker, Ph.D.

Hi Chris,

Thank you!
Kathleen

Thoughts?

Thanks,

--Chris

Christopher Harrington

All -

Thank you,
Kathleen

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044

C. Henry Adams

Re: [mile] IOCs

Regards,

Paul

Paul W. Stoecker, Ph.D.

Greetings Kathleen,

C. Henry Adams

Hello C. Henry & others,

Thank you,
Kathleen

Greetings Everyone,

C. Henry Adams

---

From: "Harrington, Christopher" <[email-masked]>
Date: Wed, 13 Feb 2013 14:08:04 -0500

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

Thank you,

Kathleen

Thanks,

--Chris

Thanks,
C. Henry Adams

Vs:

Kent Landfield

Paul,

broad interoperability.

-John

1-33 = Low

34-67= Medium

68-100=High

difference?

Meets...your

;-)

 

Paul W. Stoecker, Ph.D.

 

 

wrote:

Hello,

Vs:

Any other opinions?

Thanks,

Kathleen

-----Original Message-----

From: Stoecker, Paul

To: Brian Trammell

Subject: Re: [mile] IOCs

the schema.

Sent from my iPhone

wrote:

Hi, Kathleen, all,

than it needs to be.)

teams, I don't know.

Best regards,

Brian (as contributor)

meaning.

Thanks,

Kathleen

To: MILE IETF

Subject: Re: [mile] IOCs

urgency.

5 = Imminent )

Thanks,

C. Henry Adams

the

an IoC

scale of

to

when we

numeric

recommend

Thanks,

--Chris

-----Original Message-----

From: Moriarty, Kathleen

'MILE

IETF'

Subject: RE: [mile] IOCs

Hi Chris & Take,

allows for

high.

If

to have

so

nice to

Thank you,

Kathleen

-----Original Message-----

IETF'

Subject: RE: [mile] IOCs

it

scoring,

low/med/high

level.

Low - I am not sure

High - I am very sure

Thanks,

--Chris

-----Original Message-----

IETF'

Subject: RE: [mile] IOCs

deal

omitted

attribute

For

etc?

Thank you.

Take

-----Original Message-----

IETF'

Subject: RE: [mile] IOCs

science by any means.

Thanks,

--Chris

-----Original Message-----

From: Moriarty, Kathleen

IETF'

Subject: RE: [mile] IOCs

Hi Take & others,

-----Original Message-----

'MILE

IETF'

Subject: RE: [mile] IOCs

I like this discussion.

the IOC-related classes.

What do others think?

(more details

on

guidance

 

the indicator_set_id.

In

relationships

into

the current

structure.

Thank you,

Kathleen

I

classes'

as

well.

Thanks

Take

Subject: Re: [mile] IOCs

If

I give you

2

Thanks,

--Chris

From: Stoecker, Paul

Subject: Re: [mile] IOCs

same group ID.

complicated like STIX.

Paul

Paul W. Stoecker, Ph.D.

 

Subject: Re: [mile] IOCs

Hi Chris,

format

AttackType

values

context

indicators,

into the base IODEF.

for

that may work better.

or something else.

Thank you!

Kathleen

Subject: RE: [mile] IOCs

show are

related:

threat:

compromise.

threat:

not

be

present.

where

send both the

MD5

use

level

grouping.

Thoughts?

Thanks,

--Chris

Christopher Harrington

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

Of Moriarty, Kathleen

To: MILE IETF

Subject: Re: [mile] IOCs

All -

connect

to

schemas.

mark

Thank you,

Kathleen

Of C.

Henry Adams & BIE

To: MILE IETF

Subject: Re: [mile] IOCs

or

great

C. Henry Adams

http://biemediagroup.com

prohibited.

Subject: Re: [mile] IOCs

DNS

Yours Faithfully,

Dave Misell MSc CISSP

SilentCircle  dsm

07710 380044

 

wrote:

was

in some instances."

would

this

C. Henry Adams

 

original

within

the

Re: [mile] IOCs

From:

To:

even

which

allow

to

 

is

Regards,

Paul

Paul W. Stoecker, Ph.D.

wrote:

Subject: RE: [mile] IOCs

Greetings Kathleen,

many

share

a

--------

in

SCI."

--------

wanted to

appears

to

 

C. Henry Adams

original

within

the

wrote:

Subject: RE: [mile] IOCs

Hello C. Henry & others,

this

once

non-XML

about

the

on

the

higher

extension

point.

that

the

AdditionalData

do

draft

directly

sense

various

that

attribute

enough

add

correlate

to

not

in

to

these

multiple

format.  If

should

class

class

we

could

then

like

the latter approach.

Thank you,

Kathleen

Henry

Cc: C. Henry Adams

Subject: Re: [mile] IOCs

Greetings Everyone,

--------

of

could

be

the indicators.

class,

if

needed.

--------

--------

that's

--------

------------------------

EventData Class.

this

issue?

C. Henry Adams

 

original

within

the

mile mailing list

mile mailing list

mile mailing list

 

mile mailing list

mile mailing list

---

From: Eric Burger <[email-masked]>
Date: Sat, 16 Feb 2013 12:42:42 -0500

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:

> [email-masked] (Direct Email) [email-masked]
>  
>

---

From: "Banghart, John" <[email-masked]>
Date: Mon, 18 Feb 2013 07:41:44 -0500

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'.
>
>> 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
>> 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 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.
>>
>> 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
>>
>> 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:
>>
>> 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.
>>
>> 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
>>
>> To: "Stoecker, Paul" <[email-masked]>, Kathleen Moriarty
>><[email-masked]>, Brian Trammell <[email-masked]>

---

From: "Harrington, Christopher" <[email-masked]>
Date: Tue, 19 Feb 2013 07:24:01 -0500

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:

>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'.
>
>>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
>>if numbers are used, you could store the equivalent value, adding the 
>>2 additional ones provided.
>>
>> 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.
>>
>>Ideally in future revisions I would like to see attribution expressed 
>>as  some form of attribution is almost always shared with an 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
>>
>>Of C. Henry Adams & BIE
>>the Confidence Rating needs to be express, but combined in a 
>>simplified schema as such below:
>>
>>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.
>>
>> 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
>>
>> 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
>> ;-)
>>
>>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.
>> Both approaches will validate in the current schema.  The 
>> representation looks a little different for each, here is an example:
>>
>> 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
>>
>> think for most applications this is vastly more difficult and 
>> rigorous than it needs to be.)
>>
>> 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.
>>
>> 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.
>> 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.
>> 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.
>>
>> 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.
>> 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 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
>> 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.
>>
>> recommend that we revisit this at some point.
>>
>> Thanks,
>>
>> --Chris
>>
>> 'MILE IETF'
>> allows for you to either use a numerical score OR the ratings of low, 
>> medium, and high.
>> 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
>>
>> 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
>> To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 
>> 'MILE IETF'
>> Subject: RE: [mile] IOCs
>>
>> deal with large sets of indicators.
>> omitted if we need to deal with only small number of indicators.
>>
>> attribute for the reason Chris kindly described.
>> 'MILE IETF'
>> of SCI or right off of the IODE schema in EventData?
>> (more details
>> on
>> 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.
>>
>> guidance in the SCI draft.  Does anyone else want to weigh in?
>>
>>
>> and its usability, but I am not sure whether we do not have any other 
>> way to express these groupings.
>> relationships in a new class of IODEF so we don't have to worry about 
>> adding it into the current structure.
>> I would appreciate if anybody could share expertise on this. Though I 
>> attributes so that they can be correlated with another information as 
>> well.
>>
>> Thanks
>> Take
>>
>>
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> not be present.
>> 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.
>>
>> use a unique Inidcator ID for each hash value there needs to be a 
>> higher level grouping.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> --Chris
>>
>> Christopher Harrington
>> 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.
>>
>> mark who sent the indicator as well so that we can prevent forward 
>> sharing when it is not permitted or handle that separately?
>>
>> or let's just say "Live" Terrorist Situation.  He /or She needs to 
>> 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 
>> DNS SEC a pemanent and temporal key, with a temporal Id?
>>
>> Yours Faithfully,
>>
>> Dave Misell MSc CISSP
>> SilentCircle  dsm
>> 07710 380044
>> [email-masked]
>>
>>
>> was closely related to what I attempted to express when I stated, 
>> 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
>> either, because there is nothing to tell me which IP is the one, even 
>> 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 
>> considered is the UID portion of thisŠhow do we use that UID?  How is 
>> 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 
>> 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
>> this email thread I would like to hear thoughts on (and there may be 
>> more once RFC5070-bis is actively edited).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>> 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....
>>
>> 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
>> 1) If the indicators are something like an XML-based alert/warning of 
>> could be conveyed without using SCI draft.
>> class, if needed.
>> that's why I was thinking about the EventData class, but there may be 
>> better locations or a specific area within the EventData.
>>
>> this issue?

---

From: Eric Burger <[email-masked]>
Date: Tue, 19 Feb 2013 07:38:34 -0500

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:meansSomethingToMe></confidence>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 19 Feb 2013 07:40:51 -0500

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

On Feb 19, 2013, at 7:24 AM, "Harrington, Christopher" <[email-masked]> wrote:

>>> perspectiveSlet's say I get an XML document that tells me about an
>>> considered is the UID portion of thisShow do we use that UID?  How is

---

From: "Banghart, John" <[email-masked]>
Date: Tue, 19 Feb 2013 09:28:10 -0500

Chris,

I guess I'm envisioning a circumstance where the "meaning" of the values
is agreed to between sharing partners offline.  But you are correct, that
the spec should allow for the that meaning to be characterized.

-John

On 2/19/13 7:24 AM, "Harrington, Christopher"
<[email-masked]> wrote:

>jump

---

From: Eric Burger <[email-masked]>
Date: Tue, 19 Feb 2013 09:43:41 -0500

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.

---

From: Eric Burger <[email-masked]>
Date: Tue, 19 Feb 2013 09:45:35 -0500

That's the purpose of allowing arbitrary (or, possibly well defined) values to the <confidence> tag. You can go entirely off the reservation and make up stuff, but you can also create a standard name space to promote interoperability. Going this route also lets you experiment and then pick what does work in the wild, instead of us spending the next two years arguing over what a confidence of 27 means.

---

From: "Banghart, John" <[email-masked]>
Date: Tue, 19 Feb 2013 09:52:10 -0500

I think we agree.

-John

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

>That's the purpose of allowing arbitrary (or, possibly well defined)
>values to the <confidence> tag. You can go entirely off the reservation
>and make up stuff, but you can also create a standard name space to
>promote interoperability. Going this route also lets you experiment and
>then pick what does work in the wild, instead of us spending the next two
>years arguing over what a confidence of 27 means.
>
>>> self-explanatory but they are still spelled out. I would urge that we
>>>do
>>> the

---

From: "Stoecker, Paul" <[email-masked]>
Date: Tue, 19 Feb 2013 09:54:16 -0500

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.

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.
>
>> 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
>>        <confidence rating="low">This is XML so put your
>>NON-INTEROPERABLE mumble you want here</confidence>
>> or
>>        <confidence
>>rating="medium"><mydom:meansSomethingToMe>balderdash</mydom:meansSomethin
>>gToMe></confidence>
>>
>>>do the