Subject: [sacm] SACM BoF and Continued Discussion

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 13 Nov 2012 17:40:57 -0500

Hello,

Thank you all for a very productive BoF!  The meeting minutes should be posted soon once the two sets of notes are combined.

Out of the discussions, the main concerns of the participants were on scope of the effort and ensuing that we start from a set of requirements.  As such, it would be helpful to have list members work on and agree to a set of requirements, then develop an architecture.  Starting points to the discussion are welcome.

I would also like to make sure people have read the use case document and consider that as input to the discussion.

http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02

I think we are pretty close, but do need more discussion to reach agreement on the following set of guiding documents:
    O  SACM Requirements (we can call this a Frame of Reference as an alternative),
    O  SACM Architecture,
    O  SACM Use Cases, and
    O  SACM Charter.

Thank you,
Kathleen

---

From: Gene Golovinsky <[email-masked]>
Date: Tue, 13 Nov 2012 16:35:55 -0800

Hi.

Several comments/observations.

1.      Most of modern enterprises and their IT departments already employ
assets that come from some sort of SP. That could be corporate Gmail or CRM
or simply set of VMs running outside of their IT department control. These
assets and their users are as much a part of the security posture as any
other traditional asset. It is important to note that SP share of the
enterprise is growing. They also need to participate in the assessment and
continues monitoring. However, the traditional data collection techniques
do not necessarily work here. I think we need to extend our use cases to
call out for SP assets.

2.      I do not think that currently described capabilities provide for *
continues* monitoring. It is scheduled monitoring. In order to achieve the
continues aspect we need to be able not just assess the state but to also
actively monitor activities on the asset. A simple example would be logins,
logouts, failed logins, etc . Activities  like this are often part of the
security policies as well as the vulnerability and patch level.

Cheers.

--Gene

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Moriarty,
Kathleen
*Sent:* Tuesday, November 13, 2012 02:41 PM
*To:* [email-masked]
*Subject:* [sacm] SACM BoF and Continued Discussion

Hello,

Thank you all for a very productive BoF!  The meeting minutes should be
posted soon once the two sets of notes are combined.

Out of the discussions, the main concerns of the participants were on scope
of the effort and ensuing that we start from a set of requirements.  As
such, it would be helpful to have list members work on and agree to a set
of requirements, then develop an architecture.  Starting points to the
discussion are welcome.

I would also like to make sure people have read the use case document and
consider that as input to the discussion.

I think we are pretty close, but do need more discussion to reach agreement
on the following set of guiding documents:

    O  SACM Requirements (we can call this a Frame of Reference as an
alternative),

    O  SACM Architecture,

    O  SACM Use Cases, and

    O  SACM Charter.

Thank you,

Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 20 Nov 2012 11:27:50 -0500

Hi Gene,

Great points and sorry for the delayed response!

For #1, I see a couple of people requesting a narrow of scope to UC 1 (more on that in a separate message).  I agree with the need to address some sort of SP assessment.  If we add into the scope that an SP may categorize itself as an enterprise with the same capability to assess their environment against a common set of controls (controls in a control framework does not mean policy, that can vary within the control framework to meet an SLA for instance), would that address the concern?  I don't see UC1 cover any type of reporting, so that may be in or out of scope.  An enterprise may have reports at varying levels, very detailed for administrators and high-level for management dashboards.  An SP may just provide a high-level report that merely states compliance levels for the security SLA were met (with or without details) for instance.  Any thoughts?

#2, that makes sense to me.  I would also add in information from change and configuration management systems into a definition of continuous monitoring.  The closer to real-time updates would be necessary to achieve continuous monitoring as opposed to point-in-time checks.

Any other thoughts?

Thanks,
Kathleen
________________________________________
From: Gene Golovinsky [[email-masked]]
Sent: Tuesday, November 13, 2012 7:35 PM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: [sacm] SACM BoF and Continued Discussion

Hi.

1.      Most of modern enterprises and their IT departments already employ assets that come from some sort of SP. That could be corporate Gmail or CRM or simply set of VMs running outside of their IT department control. These assets and their users are as much a part of the security posture as any other traditional asset. It is important to note that SP share of the enterprise is growing. They also need to participate in the assessment and continues monitoring. However, the traditional data collection techniques do not necessarily work here. I think we need to extend our use cases to call out for SP assets.

2.      I do not think that currently described capabilities provide for continues monitoring. It is scheduled monitoring. In order to achieve the continues aspect we need to be able not just assess the state but to also actively monitor activities on the asset. A simple example would be logins, logouts, failed logins, etc . Activities  like this are often part of the security policies as well as the vulnerability and patch level.

Cheers.
--Gene

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Moriarty, Kathleen
Sent: Tuesday, November 13, 2012 02:41 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] SACM BoF and Continued Discussion

Hello,

Thank you,
Kathleen

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 20 Nov 2012 13:40:26 -0500

I like the idea of treating SPs as a large enterprise.

I also believe that we need to address both real-time and periodic data collection activities.  The architectural approach I recommended for use case 1 was intended to handle both cases, although I wasn't very clear about that.  I would expect the protocols we identify would support either situation.  I see this as an important requirement.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Tuesday, November 20, 2012 11:28 AM
To: Gene Golovinsky; [email-masked]
Subject: Re: [sacm] SACM BoF and Continued Discussion

Hi Gene,

Any other thoughts?

Thanks,
Kathleen

Hi.

Cheers.
--Gene

Hello,

Thank you,
Kathleen

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Gene Golovinsky <[email-masked]>
Date: Tue, 20 Nov 2012 12:48:00 -0800

Hi Kathleen.

1. Having SP classified as a large enterprise may solve the problem
somewhat. At least from the SP's own internal perspective. However, if I
look just at any type of enterprise that uses traditional software and
hardware deployment and, in addition, uses EC2 VM and Salesforce.com.
Then, as I a security practitioner, I'd like the ability to "scan" my on
premises hw/sw, but also would like access to monitor my VMs at EC2. In
this sense declaring SP just a very large enterprise may not solve the
problem. Or maybe I am missing something here.
2. I agree a lot. I would like to add access to log and event information
on the asset. Periodic and regular collection of this info can address the
point of continues monitoring.

Cheers.
--Gene

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Tuesday, November 20, 2012 08:28 AM
To: Gene Golovinsky; [email-masked]
Subject: RE: [sacm] SACM BoF and Continued Discussion

Hi Gene,

For #1, I see a couple of people requesting a narrow of scope to UC 1
(more on that in a separate message).  I agree with the need to address
some sort of SP assessment.  If we add into the scope that an SP may
categorize itself as an enterprise with the same capability to assess
their environment against a common set of controls (controls in a control
framework does not mean policy, that can vary within the control framework
to meet an SLA for instance), would that address the concern?  I don't see
UC1 cover any type of reporting, so that may be in or out of scope.  An
enterprise may have reports at varying levels, very detailed for
administrators and high-level for management dashboards.  An SP may just
provide a high-level report that merely states compliance levels for the
security SLA were met (with or without details) for instance.  Any
thoughts?

#2, that makes sense to me.  I would also add in information from change
and configuration management systems into a definition of continuous
monitoring.  The closer to real-time updates would be necessary to achieve
continuous monitoring as opposed to point-in-time checks.

Any other thoughts?

Thanks,
Kathleen

Hi.

1.      Most of modern enterprises and their IT departments already employ
assets that come from some sort of SP. That could be corporate Gmail or
CRM or simply set of VMs running outside of their IT department control.
These assets and their users are as much a part of the security posture as
any other traditional asset. It is important to note that SP share of the
enterprise is growing. They also need to participate in the assessment and
continues monitoring. However, the traditional data collection techniques
do not necessarily work here. I think we need to extend our use cases to
call out for SP assets.

2.      I do not think that currently described capabilities provide for
continues monitoring. It is scheduled monitoring. In order to achieve the
continues aspect we need to be able not just assess the state but to also
actively monitor activities on the asset. A simple example would be
logins, logouts, failed logins, etc . Activities  like this are often part
of the security policies as well as the vulnerability and patch level.

Cheers.
--Gene

From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
Moriarty, Kathleen
Sent: Tuesday, November 13, 2012 02:41 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] SACM BoF and Continued Discussion

Hello,

Out of the discussions, the main concerns of the participants were on
scope of the effort and ensuing that we start from a set of requirements.
As such, it would be helpful to have list members work on and agree to a
set of requirements, then develop an architecture.  Starting points to the
discussion are welcome.

I think we are pretty close, but do need more discussion to reach
agreement on the following set of guiding documents:
    O  SACM Requirements (we can call this a Frame of Reference as an
alternative),
    O  SACM Architecture,
    O  SACM Use Cases, and
    O  SACM Charter.

Thank you,
Kathleen

---

From: Gene Golovinsky <[email-masked]>
Date: Tue, 20 Nov 2012 12:57:49 -0800

Hi David.

I responded to Kathleen's suggestion to treat SP as a larger enterprise in
a separate e-mail separately. My concern is that the approach is not going
to address the need of an IT security guy using hybrid environment. We
need to provide some access to SP data from outside the SP perimeter.

+1 on your 2nd point.

--Gene

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Tuesday, November 20, 2012 10:40 AM
To: Moriarty, Kathleen; Gene Golovinsky; [email-masked]
Subject: RE: [sacm] SACM BoF and Continued Discussion

I also believe that we need to address both real-time and periodic data
collection activities.  The architectural approach I recommended for use
case 1 was intended to handle both cases, although I wasn't very clear
about that.  I would expect the protocols we identify would support either
situation.  I see this as an important requirement.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Moriarty, Kathleen
Sent: Tuesday, November 20, 2012 11:28 AM
To: Gene Golovinsky; [email-masked]
Subject: Re: [sacm] SACM BoF and Continued Discussion

Hi Gene,

Any other thoughts?

Thanks,
Kathleen

Hi.

Cheers.
--Gene

Hello,

Thank you,
Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 20 Nov 2012 17:43:29 -0500

Hi Gene,

I agree with you in terms of the broader scope, so we may seek to enable the capabilities for all enterprises (including SPs), but could be limited by SP policies, SLAs, or other agreements.

This should get captured in the big picture/use cases/ architecture and together, we can determine what is in scope or out-of-scope for SACM.  We can add on later as long as we leave our choices open to allow for additional use cases or expansions.  Types of reporting may be enabled, but not specified for instance (just throwing out a possible scenario).

Thanks for the input, these are important points to capture!

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gene Golovinsky [[email-masked]]
Sent: Tuesday, November 20, 2012 3:48 PM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [sacm] SACM BoF and Continued Discussion

Hi Kathleen.

Cheers.
--Gene

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Tuesday, November 20, 2012 08:28 AM
To: Gene Golovinsky; [email-masked]
Subject: RE: [sacm] SACM BoF and Continued Discussion

Hi Gene,

Any other thoughts?

Thanks,
Kathleen

Hi.

Cheers.
--Gene

Hello,

Thank you,
Kathleen

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 21 Nov 2012 13:36:27 +0000

Hi Kathleen,

I just wanted to check in and see if there was any update on the meeting minutes being posted.  I did not see them go by, but, I could have easily missed them.

Thanks,

Danny

From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Tuesday, November 13, 2012 5:41 PM
To: [email-masked]
Subject: [sacm] SACM BoF and Continued Discussion

Hello,

Thank you,
Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 21 Nov 2012 08:41:27 -0500

Hi Danny,

I sent in the meeting minutes the other day, but they have not been posted yet.  I can send them out directly or can send the link when it is ready.  I would prefer to send the link.  When they do get posted, they will show up in the meeting materials in the Security Area under SACM BoF:

https://datatracker.ietf.org/meeting/85/materials.html

Thanks,
Kathleen

________________________________________
From: Haynes, Dan [[email-masked]]
Sent: Wednesday, November 21, 2012 8:36 AM
To: Moriarty, Kathleen; [email-masked]
Cc: OVAL
Subject: RE: SACM BoF and Continued Discussion

Hi Kathleen,

Thanks,

Danny

Hello,

Thank you,
Kathleen

---

From: "Haynes, Dan" <[email-masked]>
Date: Wed, 21 Nov 2012 13:47:05 +0000

Hi Kathleen,

That is not a problem.  I will wait for the link to go out.  I just wanted to make sure that I didn't miss them.

Thanks,

Danny

>Sent: Wednesday, November 21, 2012 8:41 AM
>To: Haynes, Dan; [email-masked]
>Cc: OVAL
>I sent in the meeting minutes the other day, but they have not been posted
>yet.  I can send them out directly or can send the link when it is ready.  I
>would prefer to send the link.  When they do get posted, they will show up in
>the meeting materials in the Security Area under SACM BoF:
>
>I just wanted to check in and see if there was any update on the meeting
>minutes being posted.  I did not see them go by, but, I could have easily
>missed them.
>
>Thanks,
>
>Danny
>
>of the effort and ensuing that we start from a set of requirements.  As such, it
>would be helpful to have list members work on and agree to a set of
>requirements, then develop an architecture.  Starting points to the discussion
>are welcome.
>

---

From: Gene Golovinsky <[email-masked]>
Date: Wed, 21 Nov 2012 09:12:16 -0800

Hi Kathleen.
I agree, as long we capture this in one of the use cases, we do not have
to address it right away. But without SPs support of some sort the whole
effort would be somewhat incomplete and solution would be obsolete even
before we have it. I am perfectly fine with the staged approach.

Cheers.
--Gene

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Tuesday, November 20, 2012 02:43 PM
To: Gene Golovinsky; [email-masked]
Subject: RE: [sacm] SACM BoF and Continued Discussion

Hi Gene,

I agree with you in terms of the broader scope, so we may seek to enable
the capabilities for all enterprises (including SPs), but could be limited
by SP policies, SLAs, or other agreements.

This should get captured in the big picture/use cases/ architecture and
together, we can determine what is in scope or out-of-scope for SACM.  We
can add on later as long as we leave our choices open to allow for
additional use cases or expansions.  Types of reporting may be enabled,
but not specified for instance (just throwing out a possible scenario).

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gene
Golovinsky [[email-masked]]
Sent: Tuesday, November 20, 2012 3:48 PM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [sacm] SACM BoF and Continued Discussion

Hi Kathleen.

Cheers.
--Gene

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]]
Sent: Tuesday, November 20, 2012 08:28 AM
To: Gene Golovinsky; [email-masked]
Subject: RE: [sacm] SACM BoF and Continued Discussion

Hi Gene,

Any other thoughts?

Thanks,
Kathleen

Hi.

Cheers.
--Gene

Hello,

Thank you,
Kathleen