Subject: Re: [I2nsf] The defense 'ecosystem' paradigm

From: Linda Dunbar <[email-masked]>
Date: Wed, 1 Apr 2015 21:15:14 +0000

Adam,

You said:
sacm is, at its core, primarily interested in assessing endpoint attributes.  This means expressing the desired attribute to collect, collecting it, and evaluating it against some expressed expectation.  The assessment result is provided for downstream use, irrespective of what that use might be.  Additionally, collection could be the only results provided (if no evaluation piece is needed).

How are the “desired attributes” expressed by SACM? How are the “expectation” being specified?

Thanks, Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Saturday, March 28, 2015 7:41 AM
To: Melinda Shore
Cc: [email-masked]
Subject: Re: [I2nsf] The defense 'ecosystem' paradigm

Having a cross-group understanding of the relationship between i2nsf, sacm, mile, and dots would be beneficial.  I’m less familiar with i2nsf and dots (in the details).

It seems that mile, i2nsf, and dots would all benefit from sacm in some way, as they are largely downstream from the core problem sacm intends to solve.

i2nsf seeks to express and evaluate network service related information, which will ultimately need to identify specific endpoints (virtual or otherwise) to collect specific attributes, evaluate them against some expressed expectation, then make sense of that at the i2nsf level.

mile could benefit from sacm by leveraging the attribute expression and evaluation formats.  Additionally, the “ad hoc” exploratory tools often favored during incident response could use sacm as a means of that exploration.

dots is my least understood domain, but after speaking with Ana Hedanping for a brief time, it seems that dots will have some need to express endpoint attributes, collect values, and evaluate them against some expectation as well.  Only, this will be more of a “real time” circumstance (I presume).

As Bob pointed out, these are all parts of a whole - the “defense ecosystem paradigm”.   And, while deriving a specific taxonomy could be useful, it’s already done in a way.  The “defense ‘ecosystem’ paradigm" seems to me like a synonym for “security program”, and those are well covered.  Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critical Security Controls, and the like.  In fact, I used a similar perspective (I called it “frame of reference”) at a sacm BoF (back in Atlanta during IETF 85 [1]) to frame the “space” in which sacm plays.  I think mile  , i2nsf, and dots all play in this same space (see the second, third, and fourth slides).

What seems important is that we recognize (and name) the different business processes we are supporting.  This should help us recognize the relationships between our work.

Thoughts?

Regards,

Adam

[1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf

On Mar 27, 2015, at 9:01 PM, Melinda Shore <[email-masked]<mailto:[email-masked]>> wrote:

I'm rather surprised that nobody has answered this!

I think this is a very reasonable approach, with the
caveat that what's needed *here* is not so much an architecture
but an actual protocol conveying actual data between actual
network elements.  This may be why other middlebox protocols
<rimshot> have been able to move forward, even while being
redundant, while this effort has been stuck.  It seems to
me, based on discussions during the week and on both the
input to and the output from the dots BOF, that there's
still room for a good backend protocol to convey requests
to what used to be called policy enforcement points based
on the active threat data being shared through a dots-like mechanism.
But that's a very narrow example.

So, I think to the extent that a taxonomy can help this
effort develop a narrow focus, it would be a very helpful
thing indeed.  But it's got to be very applied - I am
skeptical about the value of high-level architectures in
the IETF.

Melinda

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 2 Apr 2015 06:41:43 -0500

> On Apr 1, 2015, at 4:15 PM, Linda Dunbar <[email-masked]> wrote:
> 
> Adam,
>  
> You said:

At this point we are working on an information model [1] and have not yet arrived at data models.  I would anticipate several data models to exist, depending on the source of the data being collected.

[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/> (note that this will almost certainly updated between now and IETF 93).  Intermediate work can be found here: https://github.com/sacmwg/draft-ietf-sacm-information-model <https://github.com/sacmwg/draft-ietf-sacm-information-model>).

> [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf <https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf>
>  
>  
>  
> On Mar 27, 2015, at 9:01 PM, Melinda Shore <[email-masked] <mailto:[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 23 Apr 2015 13:03:42 -0400

Hi,

I have been meaning to respond on how MILE and SACM fit with I2NSF and DOTS
in a bigger picture view.  I just have old slides for MILE and SACM.  See
slide 12 of this PPT, where SACM is on the far left (Configuration and
possibly Assets) and MILE is circled.
http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20IETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standards.pdf

I had better versions of that slide, but I am not able to find them online
and don't want to clog up everyone's email.  This should be good enough.

DOTS could feed into MILE, where reports from DOTS are part of a larger
investigation or set of indicators being exchanged using DOTS formatted
data within an IODEF envelope.  It's a specific sub-use case that has
different enough requirements that it should not be in MILE.

I2NSF is concerned with tenant's ability to provision/change rules on
hosted security devices, allowing tenants to make these changes.  This is
different from SACM as SACM is assessing posture and not doing things like
managing firewall rule sets or changing filtering options for flow based
protocols.

On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville <
[email-masked]> wrote:

> *sacm is, at its core, primarily interested in assessing endpoint
> attributes.  This means expressing the desired attribute to collect,
> collecting it, and evaluating it against some expressed expectation.  The
> assessment result is provided for downstream use, irrespective of what that
> use might be.  Additionally, collection could be the only results provided
> (if no evaluation piece is needed).*
>
> At this point we are working on an information model [1] and have not yet
> arrived at data models.  I would anticipate several data models to exist,
> depending on the source of the data being collected.
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ (note
> that this will almost certainly updated between now and IETF 93).
> Intermediate work can be found here:
> https://github.com/sacmwg/draft-ietf-sacm-information-model).
>
>
>
>
> Thanks, Linda
>
> *From:* I2nsf [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Adam W. Montville
> *Sent:* Saturday, March 28, 2015 7:41 AM
> *To:* Melinda Shore
> *Cc:* [email-masked]
> *Subject:* Re: [I2nsf] The defense 'ecosystem' paradigm
>
> Having a cross-group understanding of the relationship between i2nsf,
> sacm, mile, and dots would be beneficial.  I’m less familiar with i2nsf and
> dots (in the details).
>
>
> It seems that mile, i2nsf, and dots would all benefit from sacm in some
> way, as they are largely downstream from the core problem sacm intends to
> solve.
>
> i2nsf seeks to express and evaluate network service related information,
> which will ultimately need to identify specific endpoints (virtual or
> otherwise) to collect specific attributes, evaluate them against some
> expressed expectation, then make sense of that at the i2nsf level.
>
> mile could benefit from sacm by leveraging the attribute expression and
> evaluation formats.  Additionally, the “ad hoc” exploratory tools often
> favored during incident response could use sacm as a means of that
> exploration.
>
> dots is my least understood domain, but after speaking with Ana Hedanping
> for a brief time, it seems that dots will have some need to express
> endpoint attributes, collect values, and evaluate them against some
> expectation as well.  Only, this will be more of a “real time” circumstance
> (I presume).
>
> As Bob pointed out, these are all parts of a whole - the “defense
> ecosystem paradigm”.   And, while deriving a specific taxonomy could be
> useful, it’s already done in a way.  The “defense ‘ecosystem’ paradigm"
> seems to me like a synonym for “security program”, and those are well
> covered.  Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critical
> Security Controls, and the like.  In fact, I used a similar perspective (I
> called it “frame of reference”) at a sacm BoF (back in Atlanta during IETF
> 85 [1]) to frame the “space” in which sacm plays.  I think mile  , i2nsf,
> and dots all play in this same space (see the second, third, and fourth
> slides).
>
> What seems important is that we recognize (and name) the different
> business processes we are supporting.  This should help us recognize the
> relationships between our work.
>
> Thoughts?
>
> Regards,
>
> Adam
>
> On Mar 27, 2015, at 9:01 PM, Melinda Shore <[email-masked]>
> wrote:
>
> [email-masked]
> [email-masked]

-- 

Best regards,
Kathleen

---

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 23 Apr 2015 13:20:19 -0500

Has anyone else been able to grab these slides?  It may be my network, but I can’t get to them completely - the download hangs.

> On Apr 23, 2015, at 12:03 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> I have been meaning to respond on how MILE and SACM fit with I2NSF and DOTS in a bigger picture view.  I just have old slides for MILE and SACM.  See slide 12 of this PPT, where SACM is on the far left (Configuration and possibly Assets) and MILE is circled.
> http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20IETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standards.pdf <http://scap.nist.gov/events/2011/itsac/presentations/day2/Moriarty%20-%20IETF%20MILE,%20Improving%20Incident%20and%20Information%20Sharing%20Standards.pdf>
> 
> I had better versions of that slide, but I am not able to find them online and don't want to clog up everyone's email.  This should be good enough.
> 
> DOTS could feed into MILE, where reports from DOTS are part of a larger investigation or set of indicators being exchanged using DOTS formatted data within an IODEF envelope.  It's a specific sub-use case that has different enough requirements that it should not be in MILE.
> 
> I2NSF is concerned with tenant's ability to provision/change rules on hosted security devices, allowing tenants to make these changes.  This is different from SACM as SACM is assessing posture and not doing things like managing firewall rule sets or changing filtering options for flow based protocols. 
> 
> On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Apr 1, 2015, at 4:15 PM, Linda Dunbar <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Adam,
>>  
>> You said:
>> From: I2nsf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Adam W. Montville
>> Cc: [email-masked] <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Apr 2015 22:07:16 +0000

Kathleen,

Page 12 has Incident/RID/IODEF circled in Blue (IETF). Are they all part of MILE?

Your summary of I2NSF is very accurate: provide interface for customers to specify/monitor their security polices to be enforced by Security Functions hosted by providers.

Customers may also request specific profile or signature file for security functions hosted in provider domain (e.g. IPS:<signature>). The interface need to have this extra attribute, in addition to the “Subject matching (bits/fields from packets)”, “object matching (contextual: events, time, geo-location, etc). This is definitely different from the “Incident” described by MILE.

Linda

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Thursday, April 23, 2015 12:04 PM
To: Adam W. Montville
Cc: Linda Dunbar; [email-masked]; Melinda Shore
Subject: Re: [I2nsf] The defense 'ecosystem' paradigm

Hi,

On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 1, 2015, at 4:15 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Adam,

You said:

[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-information-model/ (note that this will almost certainly updated between now and IETF 93).  Intermediate work can be found here: https://github.com/sacmwg/draft-ietf-sacm-information-model).

Thanks, Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Saturday, March 28, 2015 7:41 AM
To: Melinda Shore
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] The defense 'ecosystem' paradigm

Thoughts?

Regards,

Adam

Melinda

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 23 Apr 2015 19:26:44 -0400

Hi Linda,

> Page 12 has Incident/RID/IODEF circled in Blue (IETF). Are they all part

No, only the Incident area in Blue is covered by MILE.  SACM covers the
Configuration and it must use asset information.  Remediation from posture
assessment is all part of that configuration section, but they may add that
on and do it in other ways - but it's limited to asset
assessment/remediation and not what I2NSF is doing.

>
>
> Your summary of I2NSF is very accurate: provide interface for customers to
> specify/monitor their security polices to be enforced by Security Functions
> hosted by providers.
>
>
>
> Customers may also request specific profile or signature file for security
> functions hosted in provider domain (e.g. IPS:<signature>). The interface
> need to have this extra attribute, in addition to the “Subject matching
> (bits/fields from packets)”, “object matching (contextual: events, time,
> geo-location, etc). This is definitely different from the “Incident”
> described by MILE.
>

MILE's data format can carry signatures, but they are used in different
ways than what you are describing for I2NSF.  For MILE, it might be that a
signature can help identify a particular incident or be an indicator of a
threat.  MILE might be used to get this information, but then hand of to
something done by I2NSF to deploy signatures against those threats.  MILE
could also hand something off to the SACM work where they can see they are
vulnerable to specific threats if systems have specific assessment
characteristics.

DOTS could hand off to MILE, but the reverse is probably true too.

Kathleen

>
>
> Linda
>
>
>
> *From:* Kathleen Moriarty [mailto:[email-masked]]
> *Sent:* Thursday, April 23, 2015 12:04 PM
> *To:* Adam W. Montville
> *Cc:* Linda Dunbar; [email-masked]; Melinda Shore
>
> I have been meaning to respond on how MILE and SACM fit with I2NSF and
> DOTS in a bigger picture view.  I just have old slides for MILE and SACM.
> See slide 12 of this PPT, where SACM is on the far left (Configuration and

-- 

Best regards,
Kathleen

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 24 Apr 2015 07:35:37 +0000

Hi,

Just a note regarding SACM and I2NSF: In many cases, I2NSF tenants would be interested in having some assessment about the conditions of the security functions, and there SACM postures could be of applicability.

Be goode,

On 23 Apr 2015, at 19:03 , Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Adam,

You said:

Thanks, Linda

Thoughts?

Regards,

Adam

Melinda

--

Best regards,
Kathleen

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 24 Apr 2015 07:44:14 -0400

Hi Deigo,

I agree.  Sure, there was some work do e 10-15 years ago where assessments of posture fed risk assessments.  When a vulnerability became known, there could be an automated response to set a firewall rule as a mitigation for that vulnerability on the systems protected by the firewall.

The efforts can interact and feed each other, but don't overlap.

Thanks,
Kathleen

Sent from my iPhone

> On Apr 24, 2015, at 3:35 AM, DIEGO LOPEZ GARCIA <[email-masked]> wrote:
> 
> Hi,
> 
>> On 23 Apr 2015, at 19:03 , Kathleen Moriarty <[email-masked]> wrote:
>> 
>> Hi,
>> 
>>> On Thu, Apr 2, 2015 at 7:41 AM, Adam W. Montville <[email-masked]> wrote:
>>> 
>>>> On Mar 27, 2015, at 9:01 PM, Melinda Shore <[email-masked]> wrote:
>>>>