Subject: [sacm] use case document

From: "David Harrington" <[email-masked]>
Date: Fri, 31 May 2013 18:32:14 -0400

Hi,

I read through the use cases document last night.
The current document sounds like pure marketing, with lots of promises of
the wonderful world that will exist once we finish defining this new
architecture and standards.
Lots of people new to IETF make this mistake.
This is the Internet ENGINEERING Task Force. We prefer engineering documents
to marketing documents.

To that end, let me make some comments and suggestions. 
Some SDOs work top-down; they design a pretty architecture and then try to
populate it with protocols and data models, and so on.
This is consistent with the way many proprietary engineering departments
work.
Historically, the IETF works bottom-up.
A problem exists in the real world; multiple vendors solve it using
proprietary approaches.
Then  the problem becomes more or less a solved problem that is not solved
in a standardized manner.
A lack of interoperability becomes the problem.
That's when the IETF comes into play - helping the community establish a
multi-vendor interoperable standard to help solve the original problem in an
interoperable manner.
The IETF approach is historically built on field-tested solutions, which
then get standardized.
Interoperability problems frequently are an aggregation of problems.
Typically, the IETF focuses on standardizing details, like specific
protocols or specific data models, based on uses that already exist in the
real world.
Of course, with multiple contributors involved, the final result is usually
changed quite a bit form the original because different segments of the
community need to USE the technologies in different ways, often to add value
to their products or services.

The security automation use cases document would greatly benefit from
content that describes how security automation is currently being USED in
the real world, using proprietary solutions - the "use cases".
>From that, we can try to extract the common functionality and work to
establish vendor-neutral, interoperable engineered standards, such as
protocols and data models.

Are there users of security automation subscribed to this list? 
If so, how are they using their automation? Who is the customer? 
What technical decisions have worked well; which have been problematic?

I think the use cases document should help to identify users (e.g., vendors,
services, operators) whose products/services utilize security automation.
We should try to get vendors to participate in building these standards,
since they are the ones who will use them to build products.
We should try to get operators to participate in building these standards,
because they are the people who will configure and maintain the networks
that use security automation.
The use cases document doesn't represent the users of proprietary solutions
that we propose to improve through standardization. 
The use cases document doesn't represent the expected users of the standards
we propose to build (our customers).

I think it should.

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 3 Jun 2013 19:00:03 -0400

Great points and good questions.

Would you be interested in working as an editor of the current use cases draft to drive it forward while addressing your concerns?

Sincerely,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: Friday, May 31, 2013 6:32 PM
> To: [email-masked]
> Subject: [sacm] use case document
> 
> Hi,
> 
> This is the Internet ENGINEERING Task Force. We prefer engineering
> documents to marketing documents.
> 
> A problem exists in the real world; multiple vendors solve it using proprietary
> approaches.
> The IETF approach is historically built on field-tested solutions, which then get
> standardized.
> Typically, the IETF focuses on standardizing details, like specific protocols or
> specific data models, based on uses that already exist in the real world.
> community need to USE the technologies in different ways, often to add
> value to their products or services.
> 
> 
> We should try to get vendors to participate in building these standards, since
> they are the ones who will use them to build products.
> The use cases document doesn't represent the expected users of the
> standards we propose to build (our customers).
> 
> I think it should.
> 
> David Harrington
> [email-masked]
> +1-603-828-1401
> 
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 3 Jun 2013 20:01:25 -0400

I have no objection to helping edit the draft.
However, the main failing of the draft in my eyes is that it doesn't really
contain use cases.
I am not active in the industry we are targeting, so we would need some
input on use cases from operators, security admins, vendors, etc. who are.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Monday, June 03, 2013 7:00 PM
To: David Harrington; [email-masked]
Subject: Re: [sacm] use case document

Would you be interested in working as an editor of the current use cases
draft to drive it forward while addressing your concerns?

Sincerely,
Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of David Harrington
> The current document sounds like pure marketing, with lots of promises 
> of the wonderful world that will exist once we finish defining this 
> new architecture and standards.
> Some SDOs work top-down; they design a pretty architecture and then 
> try to populate it with protocols and data models, and so on.
> This is consistent with the way many proprietary engineering 
> departments work.
> Then  the problem becomes more or less a solved problem that is not 
> solved in a standardized manner.
> That's when the IETF comes into play - helping the community establish 
> a multi-vendor interoperable standard to help solve the original 
> problem in an interoperable manner.
> The IETF approach is historically built on field-tested solutions, 
> which then get standardized.
real world.
> Of course, with multiple contributors involved, the final result is 
> usually changed quite a bit form the original because different 
> segments of the community need to USE the technologies in different 
> ways, often to add value to their products or services.
> 
> 
> content that describes how security automation is currently being USED 
> in the real world, using proprietary solutions - the "use cases".
> I think the use cases document should help to identify users (e.g., 
> vendors, services, operators) whose products/services utilize security
automation.
> We should try to get vendors to participate in building these 
> standards, since they are the ones who will use them to build products.
> We should try to get operators to participate in building these 
> standards, because they are the people who will configure and maintain 
> the networks that use security automation.
> The use cases document doesn't represent the users of proprietary 
> solutions that we propose to improve through standardization.

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 04 Jun 2013 08:03:10 +0200

You can get many at least one set of use
cases from the SECAM working group in
3GPP SA3 - which is very active doing much
the same things as are occurring in SACM.
Ditto for the ISI group in ETSI.

SACM can improve its effectiveness by
proactively engaging the multiple other
similar groups out there.
--tony

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Jun 2013 11:25:39 -0400

Hi Tony,

Steve took your suggestion and looked at the SECAM work, and by his
analysis, the SECAM work is focused differently than the sacm work somewhat.
http://www.ietf.org/mail-archive/web/sacm/current/msg00920.html

The IETF is driven by efforts of individual volunteers; there are no
membership requirements; just join in the discussion. And it's free.
Individuals from the 3GPP SECAM and ETSI ISI efforts are welcome to come be
a part of the IETF work being done in sacm.
I looked at the possibility of participating in the SECAM and ISI work to
"actively engage" as an individual across SDOs (not that I actually want to
take on that extra work).
3GPP requires a corporate membership in order to contribute. I might be able
to get a guest membership, but that would only allow me access to the
documents, not any rights to contribute or vote, and a guest membership is
only good for six months (which is less time than this WG is expected to
last).
ETSI requires contributors to be a member of an Organizational Partner, and
has a membership fee schedule that is well outside my range as an individual
contributor.
So the active engagement would appear to be one-way (from SECAM and ISI to
sacm) if I were to do it. And I don't want to commit my time to doing all
three efforts.

If you, as an IETF individual contributor, believe that there is something
in the SECAM work that should be considered in our use cases, then by all
means please do the analysis and send some text to the WG asking that your
text be incorporated into the use case document.
Ditto for the ETSI ISI work.
(being careful of copyrighted material, of course)
If you know of others participating in SECAM and/or ISI who want to
contribute to the IETF sacm work as individual contributors, please let them
know they are welcome to contribute here. For free, with no membership
requirements.
And we certainly welcome your taking the work being done here (which is
freely available anyway) and making the SECAM and ISI efforts aware of it.
While the sacm work isn't cast in stone yet, you, as a contributor to SECAM
and ISI, could also pass on some of the sacm work to those efforts to
provide some active engagement between the efforts. 

Let me stress, however, that the" active engagement" would be you acting as
an individual contributor to multiple efforts. The SECAM and ISI work will
typically be given no greater weight than any other individual contribution,
per IETF rules.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
Rutkowski
Sent: Tuesday, June 04, 2013 2:03 AM
To: ietfdbh
Cc: 'David Harrington'; 'Waltermire, David A.'; [email-masked]
Subject: Re: [sacm] use case document

You can get many at least one set of use cases from the SECAM working group
in 3GPP SA3 - which is very active doing much the same things as are
occurring in SACM.
Ditto for the ISI group in ETSI.

On 2013-06-04 2:01 AM, ietfdbh wrote:
> However, the main failing of the draft in my eyes is that it doesn't 
> really contain use cases.
> I am not active in the industry we are targeting, so we would need 
> some input on use cases from operators, security admins, vendors, etc. who
are.

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 Jun 2013 12:32:26 -0400

Dave,

I kind of have to agree with you here.  I think the draft ought to cover 
the basics of here's what we want to do in the intro and then dive in to 
the how's this going work say where:

a. My IT people bought some shiny new thing and plunk it on the network 
and ...
b. My IT people didn't put a patch in when they should have and ...
c. My enterprise supports BYOD, and I plug my D in to the network and ...
d. ....

I've got no problem if the use case documents goes way beyond what the 
charter says it just needs to be clear and say this bit is covered now, 
this bit might be done later, and this bit over here is done in that 
other wg.

spt

---

From: Adam Montville <[email-masked]>
Date: Wed, 12 Jun 2013 14:43:10 +0000

I like the idea of being more pedantic with our use cases.  Several people have more-or-less formalized use case documentation structures (Alistair Cockburn [1] and Martin Fowler [2] come to mind).   For purposes of the use case draft, I think it would be useful to agree on 1) the content a use case should contain, and 2) the structure of that content.  

This might mean that some reformatting needs to be done to the draft, but I'd rather see it convey what it needs to convey than worry about reformatting.

I don't think every possible edge case should necessarily be included within each use case description.

I also believe that a representative set of use cases can be leveraged rather than every possible case.  Thinking aloud, would it be useful to consider user scenarios [4] as a means of focusing use cases?  I've seen scenarios work very well in practice.

Adam

[1] http://alistair.cockburn.us/index.php/Basic_use_case_template
[2] http://martinfowler.com/bliki/UseCases.html
[3] http://www.usability.gov/methods/design_site/usecasesresource.html
[4] http://www.usability.gov/methods/analyze_current/scenarios.html

> Sean Turner
> Sent: Tuesday, June 11, 2013 9:32 AM
> To: ietfdbh
> I kind of have to agree with you here.  I think the draft ought to cover the
> basics of here's what we want to do in the intro and then dive in to the how's
> this going work say where:
> 
> charter says it just needs to be clear and say this bit is covered now, this bit
> might be done later, and this bit over here is done in that other wg.
> 
> spt
> 
> > some input on use cases from operators, security admins, vendors, etc.
> who are.
> >
> > David Harrington
> > [email-masked]
> > +1-603-828-1401
> > Of Waltermire, David A.
> > Would you be interested in working as an editor of the current use
> > cases draft to drive it forward while addressing your concerns?
> >
> > Sincerely,
> > Dave
> >
> >> The current document sounds like pure marketing, with lots of
> >> promises of the wonderful world that will exist once we finish
> >> defining this new architecture and standards.
> >> That's when the IETF comes into play - helping the community
> >> establish a multi-vendor interoperable standard to help solve the
> >> original problem in an interoperable manner.
> >> content that describes how security automation is currently being
> >> USED in the real world, using proprietary solutions - the "use cases".
> >>  From that, we can try to extract the common functionality and work
> >> to establish vendor-neutral, interoperable engineered standards, such
> >> as protocols and data models.
> >>
> >> standards, because they are the people who will configure and
> >> maintain the networks that use security automation.
> ...

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 12 Jun 2013 12:58:50 -0400

Hi Adam,

I looked at your references.
I found some useful information for things to consider.
OTOH, my impression is that the Alistair and fowler approaches are more
oriented toward formal software development, ala UML, than we need for our
purposes.

There are a number of use case documents already published in the IETF.
They are far less formal, but consistent with IETF practice.
I recommend we look at a few of those.
I have not gone through these in detail, and they each have their own style
and amount of detail depending on their purpose.
RFCs: 3752, 4496, 5344, 6294, 6341, 6394, 6405, 6461, 6770, 6789, 6907, and
6953.

First, though I think we need some contributions.
Who is planning to use security automation, and how do they plan to use it?
And let's get beyond motherhood and apple pie; let's get into some detailed
usage scenarios.

Are the assessments going to be used for approving network access? If so,
why is this not being done in NEA WG?
Is the vulnerability information going to be shared across management
domains? If so, why is this not being done in MILE?
If the purpose is collecting data from sensors into a database, why not do
this using SNMP?
If the purpose if policy-based config, why not do this work in NETCONF?
If the purpose is to standardize data models of security protocols, like TLS
and SSH, why not do this work in the those WGs?
What explicitly makes the sacm work different from all the other work
already being done that relates to automated management functionality?
Just the fact that the focus is on security? 
SNMP has been used to manage bridging, routing, host resources, and hundreds
of other specific focus points.
Should the IETF have had specific WGs for "routing automation and continuous
monitoring" with a completely new architecture for that?
Should the IETF have had specific WGs for "bridging automation and
continuous monitoring" with a completely new architecture for that?
Should the IETF have had specific WGs for "host automation and continuous
monitoring" with a completely new architecture for that?
...

What makes sacm different enough to require its own WG and its own
architecture?
How are sacm standards going to be used? By what types of applications?

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville
Sent: Wednesday, June 12, 2013 10:43 AM
To: Sean Turner; ietfdbh
Cc: 'David Harrington'; 'Waltermire, David A.'; [email-masked]
Subject: Re: [sacm] use case document

I like the idea of being more pedantic with our use cases.  Several people
have more-or-less formalized use case documentation structures (Alistair
Cockburn [1] and Martin Fowler [2] come to mind).   For purposes of the use
case draft, I think it would be useful to agree on 1) the content a use case
should contain, and 2) the structure of that content.  

This might mean that some reformatting needs to be done to the draft, but
I'd rather see it convey what it needs to convey than worry about
reformatting.

I don't think every possible edge case should necessarily be included within
each use case description.

I also believe that a representative set of use cases can be leveraged
rather than every possible case.  Thinking aloud, would it be useful to
consider user scenarios [4] as a means of focusing use cases?  I've seen
scenarios work very well in practice.

Adam

> Of Sean Turner
> I kind of have to agree with you here.  I think the draft ought to 
> cover the basics of here's what we want to do in the intro and then 
> dive in to the how's this going work say where:
> 
> a. My IT people bought some shiny new thing and plunk it on the 
> network and ...
> charter says it just needs to be clear and say this bit is covered 
> now, this bit might be done later, and this bit over here is done in that
other wg.
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of David Harrington
> >> The security automation use cases document would greatly benefit 
> >> from content that describes how security automation is currently 
> >> being USED in the real world, using proprietary solutions - the "use
cases".
> >> to establish vendor-neutral, interoperable engineered standards, 
> >> such as protocols and data models.
> >>

This message and attachments may contain confidential information.  If it
appears that this message was sent to you by mistake, any retention,
dissemination, distribution or copying of this message and attachments is
strictly prohibited.  Please notify the sender immediately and permanently
delete the message and any attachments.
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Thu, 13 Jun 2013 13:55:30 +0000

David,

Thank you for your questions - they're helpful.

I think we should start to take your questions to heart and review some of the material from our Atlanta BoF where we presented Use Cases, ultimately, in the context of Operational Risk Management and with specific types of actors.  

One example scenario that might get us to a more meaningful use case discussion would be that an organization's Chief Information Security Officer wants a thumbnail sketch of the organization's PCI-related security posture, as measured by configuration and vulnerability of its PCI-related assets.  To get this information, a security administrator, filling the role of an "auditor," may be tasked to collect this information, which requires that the security administrator:

1. Identify PCI-related assets
2. Assess configuration and vulnerability posture of each of those assets against known organizational hardening standards (we assume that such hardening standards are aligned with PCI)
3. Generate a report of some kind

It's what happens in 2 that you, I think, want more detail on.

Is this right?

Adam

> From: David Harrington [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2013 10:01 AM
> To: Adam Montville; 'Sean Turner'; 'ietfdbh'
> Cc: 'Waltermire, David A.'; [email-masked]
> Subject: RE: [sacm] use case document
> 
> Hi Adam,
> 
> oriented toward formal software development, ala UML, than we need for
> our purposes.

Fair enough.  I was just looking toward the facets of a use case we might want to convey.

> RFCs: 3752, 4496, 5344, 6294, 6341, 6394, 6405, 6461, 6770, 6789, 6907, and

Thank you.  We should certainly review a handful of these for formatting/content ideas.

> Who is planning to use security automation, and how do they plan to use it?

I would recommend reviewing IETF Proceedings information from our Atlanta BoF.  In particular, the Use Case presentation: http://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf

That presentation provides our primary frame of reference and an overview of the actors involved.

> If the purpose is collecting data from sensors into a database, why not do this
> using SNMP?
> SNMP has been used to manage bridging, routing, host resources, and
> hundreds of other specific focus points.
> Should the IETF have had specific WGs for "routing automation and

The questions you pose above are good ones.  In general, the "why is this not being done in X?" questions may be answered in a similar way: No one existing WG is concerned with the intersection of the whole.  It so happens that configuration assessment is a component of SACM that can be reused across some of these other efforts.

To me, the biggest differentiator between SACM and some of the other WGs is the fact that it is less operational in nature and more security/compliance focused.  A primary use case for the SACM architecture will be to enable organizations to ensure that appropriately hardened host configurations are in place throughout the asset management lifecycle and to manage configuration drift over time in a manner that is consistent with higher-level policies, which may be driven by internal or external requirements (i.e. PCI, COBIT, SOX, EU Data Protection, Monetary Authority of Singapore, DSD Top 35, CSC Top 20, and so on).   Also, note that "asset" can include information and is not restricted to computing devices.

> What makes sacm different enough to require its own WG and its own

See above.  Additionally, the architecture for SACM may well include facets of other IETF WGs where warranted.  

> How are sacm standards going to be used? By what types of applications?

Primarily security control/tool vendors (choose your terminology here).  Tripwire, McAfee, Symantec, IBM, RedHat, Microsoft, CIS, SPAWAR, and a host of other tools in this space.  If you throw in the integrations that are possible by collaborating with other working groups, then more tools/efforts can be added to the list (i.e. those supporting network access control or incident response capabilities).

> Adam Montville
> I also believe that a representative set of use cases can be leveraged rather
> than every possible case.  Thinking aloud, would it be useful to consider user
> scenarios [4] as a means of focusing use cases?  I've seen scenarios work very
> well in practice.
> 
> Adam
> 
> Behalf