Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-00.txt

From: Sean Turner <[email-masked]>
Date: Thu, 11 Jul 2013 12:31:33 -0400

Food for thought.

spt
-------- Original Message --------
Subject: I-D Action: draft-handt-sacm-alternate-architecture-00.txt
Date: Thu, 11 Jul 2013 09:26:58 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : sacm: Alternate Architecture
	Author(s)       : Russ Housley
                           Sean Turner
	Filename        : draft-handt-sacm-alternate-architecture-00.txt
	Pages           : 5
	Date            : 2013-07-11

Abstract:
    This document proposes and alternate architecture for sacm (a
    proposed working group at the time this draft was submitted).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architecture

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-handt-sacm-alternate-architecture-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "David Harrington" <[email-masked]>
Date: Fri, 12 Jul 2013 10:06:53 -0400

Hi,

While I don't fully agree with the original architecture, I find it easier
to understand the intended functionality than in the alternate architecture.

I understand the goal here of showing where the on-the-wire protocols
operate between entities.
The data flows in the Waltermire architecture do not clearly capture the
on-the-wire-ness of the flows, and what sits where in the network.
It might be helpful to use both diagrams, combined, to show the network
entities and on-the-wire data flows, and then show within the entity boxes,
the expected functionality provided by each.

The new architecture seems focused on a combination firewall/IDS box; that
seems like a particular use case.
As you all know already, I think the scope of the sacm work needs to be
narrowed, but this might narrow it too much.

(Sean, can you write up a firewall/IDS use case that I can put into the
use-cases document for this usage?)

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
> Sent: Thursday, July 11, 2013 12:32 PM
> To: [email-masked]
> Subject: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-architecture-
> 00.txt
> 
> Food for thought.
> 
> spt
directories.
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 12 Jul 2013 11:11:12 -0400

I like the original.  It's only concerned with the logical components 
that make up SACM -- the flexibility in how they are mixed and match to 
solve real problems is one of its big strengths.

But it's also apparent that this is not being effectively communicated.

I sent some (lousy) drawings to the mailing list a while back trying to 
capture that flexibility -- attached here again for your 
amusement/befuddlement.

Do very specific use cases help people understand how these standards 
can be applied?

--gun

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 12 Jul 2013 12:02:33 -0400

I can't read your svg files.

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

> Gunnar Engelbach
> Sent: Friday, July 12, 2013 11:11 AM
> To: David Harrington
> Cc: 'Sean Turner'; [email-masked]
> Subject: Re: [sacm] Fwd: I-D Action: draft-handt-sacm-alternate-
> architecture-00.txt
> 
> 
> I like the original.  It's only concerned with the logical components that
make
> up SACM -- the flexibility in how they are mixed and match to solve real
> problems is one of its big strengths.
> 
capture
> that flexibility -- attached here again for your amusement/befuddlement.
> 
> 
> Do very specific use cases help people understand how these standards can
> be applied?
> 
> 
> --gun
> 
> 
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 12 Jul 2013 13:39:25 -0400

Try these.  They're just not scalable.

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 13 Jul 2013 11:16:35 -0400

Hi Gunnar,

Thanks; that's much better.

I think many people will have many different approaches to their
architecture, but there will be quite a bit of commonality we can try to
extract from them.
Would you be willing to write some text quickly describing your collection,
assessment, and management system, so we can add this to the use-cases
document?
The more we understand how people plan to gather and assess data, and turn
the collected data into information that can then be used by humans, the
better we can design a solution to meet the needs of multiple approaches.

I have some questions, so I can better understand your architecture, and to
make sure I don't make any unwarranted assumptions.
Working from EntitiesInUse,
1) Do these diagrams represent a system you have already implemented?
2) Has it been deployed in real-world environments?
3) Has it been deployed in enterprise environments? Service provider
environment?
4) What are you using for protocols between the assessment server and the
computer with agent?
5) What are you using for protocols between the assessment server and the
computers without agents?
6) When the valuator gathers data from agent-less computers, does it convert
the data into the same format that is used to gather data from a computer
with agent?
7) It appears the controller always talks to the evaluator, never directly
to the data collector. I realize this is an architectural drawing, and in
actual coding a direct-connect might be used to performance improvements. Is
the intent that the controller always goes through the evaluator function? 
8) when you have a subdomain, which entities in the super-domain communicate
directly with entities in the subdomain? 
8a) Is this a server-to-server sharing of information?
8b) Can server A directly access the evaluator function in the subdomain B?
or does it proxy requests for evaluations via subdomain server B controller?
8c) Can server A directly query the data collector in subdomain B? does it
us
9) Is it fair to assume that the Independent Workstation is equivalent to a
subdomain, which just happens to support only the one workstation it is
running on?

More later ...

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

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Friday, July 12, 2013 1:39 PM
> To: ietfdbh
> Cc: 'David Harrington'; 'Sean Turner'; [email-masked]
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Gunnar Engelbach
> >> that
> >> up SACM -- the flexibility in how they are mixed and match to solve
> >> real problems is one of its big strengths.
> >>
> >>> I understand the goal here of showing where the on-the-wire
> >>> protocols operate between entities.
> >>> The data flows in the Waltermire architecture do not clearly capture
> >>> the on-the-wire-ness of the flows, and what sits where in the network.
> >>> It might be helpful to use both diagrams, combined, to show the
> >>> network entities and on-the-wire data flows, and then show within
> >>> the entity
> >> boxes,
> >>> The new architecture seems focused on a combination firewall/IDS
> >>> box;
> >> that
> >>> As you all know already, I think the scope of the sacm work needs to
> >>> be narrowed, but this might narrow it too much.
> >>>
> >>> (Sean, can you write up a firewall/IDS use case that I can put into
> >>> the use-cases document for this usage?)
> >>>
> >>> David Harrington
> >>> [email-masked]
> >>> +1-603-828-1401
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf
> >> Of
> >>>> Sean Turner
> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>
> >>>>
> >>>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Sat, 13 Jul 2013 15:11:28 -0400

Sure.  I won't be able to get to it right away, though.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 15 Jul 2013 16:03:09 +0000

Re: alternate architecture.

If you don't understand why using logical functional elements is better than
somebody's restrictive physical implementation, you will before long.
Having been through a couple SDO's where weeks were wasted while one vendor
tried to force others to adopt their implementation, I have no wish to
repeat that.

The big take-away I got from this alternate diagram was that you wanted the
evaluator to directly access the sensor (asset) and prohibit other means of
accessing the repository.
I have to wonder is that is as scalable as the original architecture.
Your simplified architecture would simply be:  Sensor-Evaluator-Repository
Adding in the firewalls seems an unnecessary distraction.  Or, are those
evaluators also?
Also, I can guess what C is for, but that should be explained.

Lastly, I don't see the need to insult the reader in section 2.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gunnar Engelbach
Sent: Saturday, July 13, 2013 3:11 PM
To: ietfdbh
Cc: 'David Harrington'; 'Sean Turner'; [email-masked]
Subject: Re: [sacm] Fwd: I-D Action:
draft-handt-sacm-alternate-architecture-00.txt

On 7/13/2013 11:16 AM, ietfdbh wrote:
> architecture, but there will be quite a bit of commonality we can try 
> to extract from them.
> Would you be willing to write some text quickly describing your 
> collection, assessment, and management system, so we can add this to 
> the use-cases document?
> The more we understand how people plan to gather and assess data, and 
> turn the collected data into information that can then be used by 
> humans, the better we can design a solution to meet the needs of multiple
approaches.
>
>
> I have some questions, so I can better understand your architecture, 
> and to make sure I don't make any unwarranted assumptions.
> 4) What are you using for protocols between the assessment server and 
> the computer with agent?
> 5) What are you using for protocols between the assessment server and 
> the computers without agents?
> 6) When the valuator gathers data from agent-less computers, does it 
> convert the data into the same format that is used to gather data from 
> a computer with agent?
> 7) It appears the controller always talks to the evaluator, never 
> directly to the data collector. I realize this is an architectural 
> drawing, and in actual coding a direct-connect might be used to 
> performance improvements. Is the intent that the controller always goes
through the evaluator function?
> 8) when you have a subdomain, which entities in the super-domain 
> communicate directly with entities in the subdomain?
> 8c) Can server A directly query the data collector in subdomain B? 
> does it us
> 9) Is it fair to assume that the Independent Workstation is equivalent 
> to a subdomain, which just happens to support only the one workstation 
> it is running on?
>
> More later ...
>
> Thanks,
> David Harrington
> [email-masked]
> +1-603-828-1401
>
>>>> Behalf Of Gunnar Engelbach
>>>> Do very specific use cases help people understand how these 
>>>> standards can be applied?
>>>>
>>>>
>>>> --gun
>>>>
>>>>
>>>>
>>>>> While I don't fully agree with the original architecture, I find 
>>>>> it
>>> easier
>>>>> The data flows in the Waltermire architecture do not clearly 
>>>>> capture the on-the-wire-ness of the flows, and what sits where in the
network.
>>>>> As you all know already, I think the scope of the sacm work needs 
>>>>> to be narrowed, but this might narrow it too much.
>>>>>
>>>>> (Sean, can you write up a firewall/IDS use case that I can put 
>>>>> into the use-cases document for this usage?)
>>>>>
>>>>> David Harrington
>>>>> [email-masked]
>>>>> +1-603-828-1401
>>>>>
>>>>>> Subject: I-D Action: 
>>>>>> draft-handt-sacm-alternate-architecture-00.txt
>>> https://datatracker.ietf.org/doc/draft-handt-sacm-alternate-architec
>>> tu
>>> re
>>>>>>
>>>>>> http://tools.ietf.org/html/draft-handt-sacm-alternate-architectur
>>>>>> e-
>>>>>> 00
>>>>>>
>>>>>>

---

From: Sean Turner <[email-masked]>
Date: Mon, 15 Jul 2013 17:14:49 -0400

> the expected functionality provided by each.

I could see using both some people like functional architectures some 
people like the more box + protocol architectures.  Sometimes showing 
how one applies to other helps everybody get on the same page.  That was 
my goal.  Maybe it would have been better title additional architectural 
views.

> seems like a particular use case.

I figured (and stand ready to be corrected) that what we have is an 
asset, one or more evalators, one or more sensors, and ...

> use-cases document for this usage?)

No worries I'll provide something.

spt

---

From: Sean Turner <[email-masked]>
Date: Mon, 15 Jul 2013 17:25:52 -0400

> tried to force others to adopt their implementation, I have no wish to

Mike,

Definitely stand ready to be corrected - seriously.  I'm just looking at 
protocols and what flows where.

> accessing the repository.

That part, I have to admit wasn't fully baked.  I could see that one 
might restrict access to the repository but with proper 
authentication/access control that's probably not necessary.  In fact, 
it might be a bad idea because it might slow things down.

> Adding in the firewalls seems an unnecessary distraction.  Or, are those

I was thinking the BPDs would evaluators/sensors.  I don't think the 
evaluator would be looking at all the traffic as it flows out of the 
asset.  There might be something on the asset that says hey this assets 
starting to act funny, but I would always think there would be a 
backstop at enterprise boundary that would also want to check that the 
asset is acting like it's supposed to be.

> Also, I can guess what C is for, but that should be explained.

Definitely need to explain that more and am hoping to have some more in 
the -03 draft.

> Lastly, I don't see the need to insult the reader in section 2.

Point taken.  Apologies and it's removed.

spt

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 15 Jul 2013 17:58:46 -0400

Hi,

I like Gunnar's pictures better  - not just cause they're prettier ;-) but
because they mix the functional approach of the Waltermire architecture and
the physical separation of the Turner/Housley architecture.

s/ For those not in the know, it makes more sense to/Some people prefer to/

In the text it says " Lines marked A, flowing from the asset to the
Evaluator,"
However, in figure 2, lines marked A are drawn as being bi-directional. I
recommend removing the arrows going into the asset boxes.

In the text, it says " Lines marked B, flowing from the client to the BPD",
but there are no boxes labeled "client", and the lines marked B also appear
to be bi-directional in the diagram. 
The lines marked B flow between the asset and the BPD. I guess I'm confused
because you are mixing NEA terminology with the sacm terminology, and it's
not clear to me where the NEA client server are in the diagram.
The text says "The asset has an NEA client" and "the evaluator has an NEA
server", but then you put lines marked B between the asset and the BPD.

Then you go on to talk about doing NEA assessment before access, and
monitoring after, which seems to be a whole different issue -temporal
dataflows - than the actual boxes and protocols dataflows. This temporal
dataflow seems better represented by a waltermire dataflow loop of
DF2/DF1/DF2. 

The text says "   Lines marked C, flowing from the BPD to the (Evaluator or
   Repository?) ensure that the BPDs know how the asset are supposed to
   be acting."
So your combination of evaluator and repository also act as the policy
server?
In much of the discussions I have been in over the years about policy-based
management and policy-based access control, we often talk about a policy
decision point (PDP), where it is decided which policy applies to the asset,
and a policy enforcement point (PEP), which enforces the policy. So if I
were to use the terminology I am used to in describing your  architecture,
the evaluator/repository would be the PDP, and the BPD would be a PEP? [see
RFC3198 " Terminology for Policy-Based Management"]

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

> From: Sean Turner [mailto:[email-masked]]
> Sent: Monday, July 15, 2013 5:15 PM
> To: David Harrington
> Cc: [email-masked]
> > While I don't fully agree with the original architecture, I find it
> > easier to understand the intended functionality than in the alternate
> architecture.
> >
> > network entities and on-the-wire data flows, and then show within the
> > entity boxes, the expected functionality provided by each.
> 
people
> like the more box + protocol architectures.  Sometimes showing how one
> applies to other helps everybody get on the same page.  That was my goal.
> Maybe it would have been better title additional architectural views.
> 
> > The new architecture seems focused on a combination firewall/IDS box;
> > that seems like a particular use case.
> 
> I figured (and stand ready to be corrected) that what we have is an asset,
> one or more evalators, one or more sensors, and ...
> 
> >> Of Sean Turner

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 18 Jul 2013 17:55:30 -0400

David, et al,

Text to accompany the pretty pictures I sent out last week.  I'm not 
even going to try turning them into ASCII diagrams right now.

If you'd like more information on the alternate architecture I 
originally drew these to illustrate you can go back to these archive 
messages:

http://www.ietf.org/mail-archive/web/sacm/current/msg00884.html
http://www.ietf.org/mail-archive/web/sacm/current/msg00947.html

but that's not really the focus I have at the moment.

Plus, answers to your other questions inline below.

---------------------=========================---------------------
1) BasicEntities:

"Entities" are logical constructs that are defined by which of the SACM 
standards they implement.  In this first diagram these entities have 
been broken out to their most primitive.

The intention of this diagram is as a starting point in illustrating the 
flexibility of the architecture and not as a complete representation. 
For that reason the Content Repository entity has not been included, but 
the interaction points of the Results View and Controller Front-End (not 
currently covered by the SACM working group) have been added.

This architecture and its data flows also differ from the 
waltermire-sacm-architecture.  The purpose at this time is not to 
discuss the merits of either approach, but to show how the concept of 
these proposed standards gives the flexibility to solve a wide variety 
of real-world situations while also reaping the benefits of standardization.

Taking the entity "Data Collector" as an example, what qualifies it as a 
Data Collector is the ability to receive requests to collect data and 
return the collected data where the request and response are done via 
the standards proposed by this working group.  The Data Collector may 
have more capabilities, but without covering these at a minimum it would 
not qualify as a Data Collector.

Similarly, the Evaluator receives/responds to marching orders from the 
controller, sends/receives data collection requests and (optional dotted 
line) interacts with the data store.

       ---------------=========================---------------

2) Basic Grouped Entities

The primitive entities from (1) have been grouped into two physical 
implementations.  The Management System has the user interface (Results 
Viewer, Controller Front-End), the Controller, and the Results Data 
Store.  It exposes no interfaces, but is able to query any number of 
Evaluators to performs assessments.

The Collector/Processor has both the Data Collector and the Evaluator. 
The only line of communication exposed by the Collector/Processor is 
Evaluator requests/responses, so to an external entity it only qualifies 
as an Evaluator.  However, it also has its own integrated Data Collector 
that operates at the local level of scope.  This, then, is a smart agent 
that distributes the evaluation process.  It could also easily expose 
the Data Collector interfaces making it accessible to other Evaluators.

If the Collector/Process does not expose the Data Collector interfaces 
it could actually do collection via a proprietary means.  This type of 
hybrid my be necessary to address cases that fall outside of these 
standards, but it can also be used to give access to existing 
proprietary solutions.

       ---------------=========================---------------

3) Entities in Use

Each of the green boxes represents a single computer, with the necessary 
interfaces exposed to qualify it for each of the role entities that it 
encloses.

The Results Datastore, for example, is on a dedicated database server 
that can be optimized for database activity and may in fact be 
administered by separate personnel.

The Assessment Server contains the entities necessary for performing the 
scheduled tasks, evaluating data collected from Data Collector agents, 
using its own Data Collector(s) to collect data agentlessly, and 
retrieving artifacts from a separate independent enclave.

The Independent Workstation can perform and display self-assessments but 
can also be linked into the enterprise management system.

> 3) Has it been deployed in enterprise environments? Service provider

These diagrams are based primarily on what has been discussed so far on 
the SACM mailing list.  I'm making an effort to ignore what has already 
been done and focus on what makes best sense based on my current 
understanding of the goals of this working group.

But by some strange coincidence there are a lot of similarities between 
this and the products we currently build.  Which includes enterprise 
environments.

> 4) What are you using for protocols between the assessment server and the

Proprietary, but based on pretty standard things like XML and TLS.

> computers without agents?

Whatever makes sense for each asset type and doesn't create an 
additional security exposure.  DCOM, NetBIOS, SSH, WBEM/WMI, telnet, ...

> the data into the same format that is used to gather data from a computer

In our current products, yes, the Evaluator in that case acts as a 
remote agentless Data Collector.

For SACM that would only be necessary if the raw collected data was a 
product to be transferred.  If the only product to be returned was the 
completed benchmark evaluation then there's no need to convert it to the 
SCAM Collected Data format.

On the other hand, if you look at Dave Waltermire's architecture, the 
Controller is between the Sensor (Data Collector) and Evaluator, so the 
only way to get assessment results from the Evaluator is if it is fed a 
SACM standard data collection.

It doesn't show up in my diagrams, but I think the Evaluator *should* be 
able to produce results when fed a diet of collected items.

> the intent that the controller always goes through the evaluator function?

I'm undecided on that.  I'm wary of the bottleneck created being too 
reliant on the controller and I like being able to distribute the 
workload by possibly having evaluators local to the assets.

At the same time it's also more complicated to determine if an 
assessment request failed to occur in a timely manner if each request 
isn't being actively monitored by the controller.

There's also the problem of being able to authenticate to each asset to 
perform the collection/evaluation.  The exposure to that kind of data 
needs to be kept to an absolute minimum.

> directly with entities in the subdomain?

First, for clarity, the subdomain is just one category of subdividing an 
organization.  "Enclave" would be a better label to put on that.  Some 
entity that does its own security management, but is also part of a 
larger organization.

Communication is at whatever level is needed to fulfill the needs of the 
implementing organization.  That might be as informal as just doing 
database replication so that only results are available, or it might be 
all the way down to the level of direct data collection from individual 
assets.

I think that level of detail would be a bad idea for general usage, but 
we're already dealing with auditors who need to do periodic spot checks 
on a random selection of assets at multiple remote locations.

> 8c) Can server A directly query the data collector in subdomain B? does it

Possibly any of the above.  All it takes is access to the SACM interface 
at whatever level of access you are looking for, knowledge of what 
assets to access, and the ability to authenticate.

Most of the time anything other than summary information would be a bad 
idea.  Networks aren't built for the purpose of doing security audits on 
themselves after all.  Which is why I showed the subdomain having its 
own controller and database.  Distribute the workload and share the 
results -- which is a level not covered by SACM.

Alternatively, somebody on Network A could use a Results Viewer to 
connect to the Results Datastore in the subdomain.  This data flow is 
not currently covered in SACM so it would be proprietary, but there's no 
reason a Results Viewer couldn't connect to multiple Results Datastores 
and present the data as a single unified view.  No data replication 
necessary.

> subdomain, which just happens to support only the one workstation it is

In many ways, yes.  Being a local machine it poses no more cost in 
accessing at the data collection level than any other asset in the local 
domain and there are many benefits, from the enterprise level, in just 
treating it like another Collector or Evaluator.  Not something you'd 
want to do for a subdomain.

At the same time, we work with some multilevel organizations where 
security data for all assets must be collected but there is no single 
entity that has permissions to collect from all assets.  In that case a 
self-assessment must be performed and the results pushed to the 
repository and that's one of the things I was attempting to show with 
the Independent Workstation.