Re: [cti-stix] STIX: Messaging Standard vs. Document Standard

I would offer that Jerome is pointing out we are not alone and MILE (IODEF/RID) is having a bit of a renaissance. It also highlights the value of staying in a particular technology family, in this case HTTP and XML. By using standard tooling and not rolling our own, instead of having to reinvent everything, you can use existing tools, like AtomPub for incremental updates and simple notifications.

Also, if you have an interest, the IETF would welcome feedback on the MILE work.

On Dec 14, 2015, at 1:32 PM, Bush, Jonathan <jbush@DTCC.COM> wrote:

Jerome - Trying to put some context around what I'm seeing in the paper - What is being proposed is really a replacement for TAXII, no?  Is that what is being discussed in the TAXII group currently?

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

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jerome Athias

Sent: Monday, December 14, 2015 1:21 AM

To: Jordan, Bret

Cc: Patrick Maroney; Terry MacDonald; Jason Keirstead; Richard Struse; cti-stix@lists.oasis-open.org; Wunder, John A.

Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard

A recommended read, interesting from multiple point of views for CTI, but in the context of this thread, mainly regarding these points:

Message-oriented Architecture

Resource-Oriented Architecture

https://tools.ietf.org/html/draft-ietf-mile-rolie-01

NB: You could also find interesting elements for TAXII

2015-12-12 9:51 GMT+03:00 Jerome Athias <athiasjerome@gmail.com>:

Attached is an OLD draft (so not updated and with errors) diagram from 2012.

(This is a good one in case it helps https://github.com/google/capirca

)

NB: Mitigation is not Remediation

(PS: and really far from me to say that it matters in any way!

But, because we don't share our resumes. I would just say that I am a

36 years old Otaku/Hacker [1] who started manipulating computers 25+

years ago, and who probably spent in average 8 plenty hours a day

(including week-ends and vacations) on these automatons during the

past 10/15 years)

[1] 1. A person who enjoys exploring the details of programmable

systems and how to stretch their capabilities, as opposed to most

users, who prefer to learn only the minimum necessary. RFC1392, the

Internet Users' Glossary, usefully amplifies this as: A person who

delights in having an intimate understanding of the internal workings

of a system, computers and computer networks in particular.

2. One who programs enthusiastically (even obsessively) or who enjoys

programming rather than just theorizing about programming.

3. One who enjoys the intellectual challenge of creatively overcoming

or circumventing limitations.

2015-12-01 3:46 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>:

Nice diagram.  One thing I am working on internal to BC is to get it

so you can send your STIX indicator / CybOX object to the Solera

Security Analytics device and do automatic retrospective analysis.

This will allow you to see if you have seen said object before.  This would fit in to this work flow

nicely, I believe.    Another area would be in automatic remediation, aka

sent a STIX indicator / CybOX object with a Coarse of Action to your

Proxy and tell it to block that traffic.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0

74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,

however, the only thing that can not be unscrambled is an egg."

On Nov 30, 2015, at 17:41, Patrick Maroney <Pmaroney@Specere.org> wrote:

re: " Now lets talk about work flow and how this information is going

to flow around the network, how it is going to flow in to vendor tools,  "

Here is one Reference Implementation for consideration/discussion:

<6DB53CE0-AB02-4DDD-ABB7-4A2A7FCD92B2.png>

Patrick Maroney

Office:  (856)983-0001

Cell:      (609)841-5104

<C690F973-64C5-4C00-889B-C1A5BB4A2A0B[6].png>

President

Integrated Networking Technologies, Inc.

PO Box 569

Marlton, NJ 08053

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan

<bret.jordan@bluecoat.com>

Date: Monday, November 30, 2015 at 7:25 PM

To: Terry MacDonald <terry@soltra.com>

Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Richard Struse

<Richard.Struse@HQ.DHS.GOV>, "cti-stix@lists.oasis-open.org"

<cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>

Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document

Standard

You are correct, some organizations will do it in-house, some will

outsource, and I will add that some will just not care. We have an

amazing group that does APT research and has a massive amount of

internal data mining tools to find this sort of stuff.  We help a lot

of the biggest companies and governments solve these problem, every day.

Some organizations that outsource or do things internally MAY share

sightings or things back within their eco-systems, or they may even

share with certain government groups.  But their own legal

departments and general councils will dictate what they can share and with whom they can share it.

Remember getting a huge repo of STIX data, in your Soltra Edge device

is NOT going to magically make you any more secure. You need vendor

products that sit inline in your network that can actually DO something with that data.

Those products typically only understands what we call CybOX objects.

They do NOT understand nor care about higher level things.  We humans

and analysts and big data intelligence platforms do care about higher

level things.  It helps us figure out what is going on, and REALLY

helps in retrospective analysis of an attack.

Lets put this in real world terms...   Government or vendor XYZ discovers

that threat actor Ivan is launching an attack against executives of

high tech companies in Silicon Valley.  They believe Ivan is going to

use Whale Phishing based on the latest Audi and BMW cars.

This is great information.  Now lets talk about work flow and how

this information is going to flow around the network, how it is going

to flow in to vendor tools, how it is going to flow in to user

awareness programs and training programs.

And maybe, just maybe, some organizations might send some data back

or share pieces of information that they learn.  We do this today.

We have interconnections with lots of groups where we share data back and forth.

This is not new.  We have been doing this for 14 years.

Lets focus on workflow and how we can make an analysts life easier

and make vendor product use and understand the data they can.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0

74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,

however, the only thing that can not be unscrambled is an egg."

On Nov 30, 2015, at 17:09, Terry MacDonald <terry@soltra.com> wrote:

Bret,

I foresee that Organizations will share data between their own

internal tools (to understand threats and look for indicators of that

threats) most often. It’s not all about sharing that information with

external parties. An Organization needs to do both in order to make

best use of Threat Intelligence. They need to join those two

processes together. Threat Intelligence and Incident Response.

Now a lot of Organizations will not have the ability or the

inclination to do the Threat Intelligence gathering/sifting/etc

required to build up a picture of the threats relevant to their

Organization profile, but that’s not a problem. They’ll just outsource it.

Organizations will outsource their threat intelligence function to

third parties who will look for threat intelligence that matches the

Organizations risk profile  on their behalf. The organizations will

then just get feeds of Indicators customized to their Organization,

and will then feedback sightings they see. They will also push up any

interesting observations they notice, and the Threat Intelligence

providers will use that data to discern any new Threat Actors/Campaigns/malware families as needed.

It doesn’t matter if the threat analysis is done in house, or is

outsourced – the deep research still needs to be done in order to

discover new Indicators, and to track the changes that take place

over time. Without the deep analysis, the Indicators will soon lose

their accuracy. And without the real-world feedback, the Threat

Intelligence modelling will become less accurate.

Each process makes the other one stronger.

One thing I would like to point out is the need to move away from ‘dumb’

Indicator feeds, where the recipient gets a hug wall of Indicators

that contain every bad things that the world has seen over the last 3 months.

This won’t scale, and all it does is increase the cost to

Organizations as they have to increase infrastructure and personnel

resources to cope with the increased workload. Higher chances of

false positives and less understanding of what the really important indicators are.

By using Threat intelligence and an understanding of our adversaries

, we will know who is likely to target us, and we can look for the

things they do. We have less noise to contend with, and we spend our

precious infrastructure and personnel resources looking for things that matter to us.

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]

Sent: Tuesday, 1 December 2015 9:45 AM

To: Terry MacDonald <terry@soltra.com>

Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Richard Struse

<Richard.Struse@HQ.DHS.GOV>; cti-stix@lists.oasis-open.org; Wunder, John A.

<jwunder@mitre.org>

Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document

Standard

Re: It’s a symbiotic relationship!

It is only a symbiotic relationship, if the two organizations are

communicating.  We make a LOT of assumptions that people and

organizations are going to do anything more than just process

indicators (meaning block them on their firewall or proxy).  Most,

honestly, do not care.  They may share sighting information back to their own internal tools.  But I doubt

many will share sightings back to the larger community.   The general

council's of most organizations will prohibit that for many years to come.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0

74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,

however, the only thing that can not be unscrambled is an egg."

On Nov 30, 2015, at 14:02, Terry MacDonald <terry@soltra.com> wrote:

“There is no actual reason that indicator or sighting messages need

to be a layer on top of the ontology. They are for totally different

use cases and can be developed completely independently.”

There needs to be a relationship between the Indicators and sightings

that are exchanged and the higher-order threat intelligence that is

exchanged, or there is no way to relate the two levels together. The

key important part in all of this is to be able to maintain relationships from one to the other.

Without that ability then there is no way to do the analysis.

Frode Hommedal put it best in his presentation to FIRST:

http://frodehommedal.no/presentations/first-tc-oslo-2015. I implore

you to read it if you haven’t already. Especially this slide.

As I see it the two camps fall into these broad groups:

·         All of STIX: Threat Intelligence group

o   “We need to track everything otherwise we won’t be able to understand

the bad guys”

o   “Everything is related to everything”

·         Indicators and Sightings: Incident Response group

o   “We don’t need to understand them, we just need to detect them damn it”

o   “I only care about Indicators and Sightings”

The thing that not many people realize is that you need both, and you

need a way of crossing from one to the other. I think this diagram I

created

(©Threatloop.com) demonstrates why:

<image001.png>

The Incident Response process needs to know what Indicators are the

ones that your Organization needs to look for. At present monitoring

and detection systems are struggling to operate with the number of

indicators they need to be looking for. The Threat intelligence

process knows what threats are most likely…. So wouldn’t it be

sensible to use the Threat Intelligence process to generate/filter

the Indicators so that the Incident Response process has a far

smaller number of things and more important things to look for?

And the Threat Intelligence process need to know what the Incident

Response process is seeing. Maybe there is a new Threat Actor in

town? Maybe an existing Threat Actor is starting a new campaign?

Threat Intelligence processes need to be able to record what is

happening to be able to generate Indicators that make sense and

follow what the real risks to the Organization are.

It’s a symbiotic relationship! Both are equally important, and in

fact are critical to improving Organization’s abilities to protect themselves.

You MUST be able to map from one process to another.

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

From: cti-stix@lists.oasis-open.org

[mailto:cti-stix@lists.oasis-open.org]

On Behalf Of Jordan, Bret

Sent: Tuesday, 1 December 2015 4:35 AM

To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>

Cc: Richard Struse <Richard.Struse@HQ.DHS.GOV>;

cti-stix@lists.oasis-open.org; Wunder, John A. <jwunder@mitre.org>

Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document

Standard

I agree with Jason.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0

74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,

however, the only thing that can not be unscrambled is an egg."

On Nov 30, 2015, at 08:35, Jason Keirstead

<Jason.Keirstead@ca.ibm.com>

wrote:

Precisely.

If we can agree on the below.. then work on the standardization of

messages can be done independently of the underlying model.

RE @Sean: However, I do not view these message specifications as an

alternative or independent thing from the model/ontology. I would

view them as a layer on top of the model/ontology that allows focused

and explicit representation of a small subset of information from the

model/ontology that is relevant for a given exchange use case.

I disagree here - this is why we are having such a hard time with the

current paradigm.

There is no actual reason that indicator or sighting messages need to

be a layer on top of the ontology. They are for totally different use

cases and can be developed completely independently.

-

Jason Keirstead

Product Architect, Security Intelligence, IBM Security Systems

www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion -

Unknown

<graycol.gif>"Struse, Richard" ---11/30/2015 11:04:55 AM---So, what I

think I’m hearing is that we envision a world where we define a

serialization for STIX &

From: "Struse, Richard" <Richard.Struse@HQ.DHS.GOV>

To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A."

<jwunder@mitre.org>

Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>

Date: 11/30/2015 11:04 AM

Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document

Standard ________________________________

So, what I think I’m hearing is that we envision a world where we

define a serialization for STIX & CybOX (let’s assume in JSON) and

implementations can exchange “documents” using the serialization of

the complete data model (e.g. for communicating a new TTP for an

existing threat actor).  However, in addition to this, we might

define/standardized specialized message exchanges for a set of common

use-cases such as indicator or indicator-sighting exchange.  This

would allow appliances, for example, to simply implement the

use-case-specific message exchanges that make sense without having to implement the full STIX model.

As a result, I foresee implementations asserting what exchanges they

support, perhaps as follows:

CTI-O-MATIC Threat Analysis Platform

                STIX Exchange: SUPPPORTED

                Indicator Exchange: SUPPORTED

                Indicator-Sighting Exchange: SUPPORTED

                Etc.

ACME IDS 9000 Appliance

                STIX Exchange:  NOT SUPPORTED

                Indicator Exchange: SUPPORTED

                Indicator-Sighting Exchange: SUPPORTED

Does this make sense?

From: cti-stix@lists.oasis-open.org

[mailto:cti-stix@lists.oasis-open.org]

On Behalf Of Jason Keirstead

Sent: Monday, November 30, 2015 9:47 AM

To: Wunder, John A.

Cc: cti-stix@lists.oasis-open.org

Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document

Standard "What about a new TTP for an existing threat actor? I would

not want to have to do an RDF-based exchange to share that type of

information (still holding out hope for a reasonable JSON-LD

approach) but I’m also not sure we can build messages to cover those use cases."

I believe you would indeed do a complex exchange for that. This is

not a "messaging" use case, it is a "document share" use case. The

difference in complexity between sharing TTP information to sighting

information is similar to emailing a word document vs. engaging in an

IM session. It's not the same.

My point is that the huge amount of third party vendors who want to

"speak STIX" to communicate and/or absorb indicators, observables,

and sightings, are not interested in use cases like "TTP for an existing threat actor".

They don't have that information, and they can't act on that information.

You aren't going to get TTP information out of an IPS, and you aren't

going to send TTP information to an IDS or Firewall. But you will get

Indicators and sightings from an IPS, and you will want to send

observables to an IDS or Firewall.

These are the two different use cases - one that lends itself to a

semantic model, and one that lends itself to a compact and coherent messaging format.

-

Jason Keirstead

Product Architect, Security Intelligence, IBM Security Systems

www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion -

Unknown

<graycol.gif>"Wunder, John A." ---11/30/2015 10:04:36 AM---So to be

honest I’m not yet as convinced on this approach as all of you

(sorry). I can definitely se

From: "Wunder, John A." <jwunder@mitre.org>

To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>

Date: 11/30/2015 10:04 AM

Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document

Standard Sent by: <cti-stix@lists.oasis-open.org>

________________________________

So to be honest I’m not yet as convinced on this approach as all of

you (sorry). I can definitely see the value of messages at the level

of sightings and indicators but it seems to me like there’s a giant

middle ground of use cases where we don’t want to define

tightly-scoped messages but the document-based approach would still

be a burden. For these cases I was hoping the JSON serialization of the full model would be used.

For example, would we have a message to represent a new incident?

What would the message semantics be? What about a new TTP for an existing threat actor?

I would not want to have to do an RDF-based exchange to share that

type of information (still holding out hope for a reasonable JSON-LD

approach) but I’m also not sure we can build messages to cover those use cases.

Jason, Jon, Mark…what do you all think about that? Would we define

messages for that? Would we have third-party messages (i.e. my app

can define a non-standard CTI message based on the data model)? Would we just use RDF?

John

On Nov 30, 2015, at 8:42 AM, Jason Keirstead

<Jason.Keirstead@CA.IBM.COM>

wrote:

+1 to all below recommendations... exactly my line of thinking.

It may or may not be more work to undertake these two parallel

efforts - but I believe that it would allow both efforts to more

forward in a faster and more coherent way than the current methodology.

-

Jason Keirstead

Product Architect, Security Intelligence, IBM Security Systems

www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion -

Unknown

<graycol.gif>"Baker, Jon" ---11/30/2015 09:36:44 AM---+1 Thanks for

thinking through the underlying issues that might be making it so

hard to achieve cons

From: "Baker, Jon" <bakerj@mitre.org>

To: Jason Keirstead/CanEast/IBM@IBMCA, "cti-stix@lists.oasis-open.org"

<cti-stix@lists.oasis-open.org>

Date: 11/30/2015 09:36 AM

Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document

Standard Sent by: <cti-stix@lists.oasis-open.org>

________________________________

+1

Thanks for thinking through the underlying issues that might be

making it so hard to achieve consensus. I completely agree that by

trying to develop a messaging standard and a document standard in one

effort is a significant source of frustration for this group. This is

how I have thought about this

issue:

STIX has two primary use cases

• UC1: Holistic cyber threat analysis • UC2: Exchange cyber threat

information Requirements for UC1 are not always conducive to

effective information exchange

My basic recommendation would be as follows:

Differentiate analysis and sharing requirements • avoid overloading

analysis model with exchange requirements • avoid overloading

exchange with analysis requirements Develop a high level model of

cyber threat intelligence for analysis • initially in UML, but a

semantic representation can be developed Develop messages tailored to

information exchange needs • each exchange has a formal specification

• ensure messages are compatible with the analysis model • allow

protocol and serialization to be dictated by information exchange

needs • initially specify only a few well known and well defined

messages • plan for many messages, but add messages over time as real

needs are understood

Thanks,

Jon

============================================

Jonathan O. Baker

J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE

Corporation

Email: bakerj@mitre.org

From: cti-stix@lists.oasis-open.org

[mailto:cti-stix@lists.oasis-open.org]

On Behalf Of Jason Keirstead

Sent: Thursday, November 26, 2015 8:47 AM

To: cti-stix@lists.oasis-open.org

Subject: [cti-stix] STIX: Messaging Standard vs. Document Standard

When I originally started this message, I had started it with a "here

is why I am against JSON-LD" stance, but then decided to take a step

FAR BACK and try to figure out / tease apart the fundamental reasons

why people are both for and against JSON-LD. As a result of my

analysis, I think am starting to figure out why there are two diametrically opposed camps here.

The root I believe is that there is a fundamental disconnect between

an ideal messaging standard and a document standard, yet STIX is

trying to serve both masters. I am not sure that it can, and keep

everyone happy. At any rate, I hope if everyone can read through the

below, it will at least help each camp start to see the other's point of view.

Things desired in a document standard:

- Clarity of the source and meaning of the data

- Readability by humans can sometimes be a factor depending on use

cases

- Byte-efficiency is a secondary or tertiary concern (disk is cheap)

In a document standard, it is now the standard practice that the

schema accompanies the document. This is the core tenant of JSON-LD

and other related semantic technologies - that your data is annotated

in a way such that it can be linked back to the schema that defined

it, which then also allows you to infer the semantic meaning behind

fields in the document. This lets people and systems cross-correlate

and search documents of different types that contain fields that are

related semantically, without having to have standard-specific code written for them.

Things desired in a messaging standard:

- Maximum byte efficiency (bandwidth is not cheap)

- Absolutely zero ambiguity

- Readability by humans is a secondary (or tertiary) concern,

sometimes not a concern at all In a messaging standard, the schema

has no reason to accompany the message, because anyone who implements

it would have zero ambiguity anyway, and doing so greatly inflates

the size of the messages. You also don't have to infer meaning of a

field in a messaging standard, because the meaning is fixed and is

not open to any interpretation. As such, semantic technologies are

not required in a messaging standard, because they aren't even

applicable to the use case.

The root of our problem here and I believe why we can not come to

consensus, is we are trying to come up with one standard that does

both things, which are actually philosophically opposed to

each-other. There is an extremely large community of people and

systems who want to "speak STIX", but they have no plans to STORE

STIX, and this could not care less about semantic representations.

Similarly, there is a large community of people and systems who want

to (and already have) systems with large STIX warehouses, and very

much care about semantic representations, so that they can tie that data to other systems.

Maybe we should take a step back and look at this more critically. If

you look at what people care about from a "frequently messaged"

perspective (namely of indicators and observable occurrences) maybe

that should be moved under TAXII? Currently, TAXII is just a transit

protocol and the standard of the messages is simply " a STIX

document". I am starting to think that this is not enough and it's

part of why we can't reach any consensus. There is no reason that

there could not be a messaging format in TAXII to communicate

indicators and observables that was an offshoot of STIX but not STIX

itself... meanwhile there could continue to be a channel for full/complete "STIX documents" which are transmitted with much less frequency.

-

Jason Keirstead

Product Architect, Security Intelligence, IBM Security Systems

www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion -

Unknown

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

To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

cti-stix message