Subject: [sacm] Is SACM based on a grid?

From: "Jim Schaad" <[email-masked]>
Date: Thu, 16 Jun 2016 12:18:00 -0700

In yesterday's conference call, Henk made a statement that I did not feel
was important at the time to dispute.  I have since changed my mind.

Specifically, he agreed with the statement that SACM is a grid architecture.
I don't believe this is a true statement based both on my own personal
understanding of how things will/should work and based on the use cases
document (RFC 7632).  The use case document has the "Ice Station Zebra" use
case (Section 2.2.5).  In this case one method of setting this up with be
for a SACM component to be placed at the university and another one at the
remote office.  Since there is not going to be either continuous or
high-speed connections between the two locations, one is going to have a
replication type situation between these two components to move guidance
from the university to the station and end point assessments from the
station back to the university.  There is not the concept of a grid here as
there is a single choke point between the two locations.

This view is also reflected in the architecture document.  One has
repositories that can either be standalone or replicate between each other.
One has proxy agents that one can ask for data which will go and get it from
other locations (such as remote offices, partners, or other departments).
One does not want to have everyone talking to the same end-point every time
that they want to get an assessment done.  So one will have a graph rather
than a grid of SACM components.  Some endpoints will only ever talk to a
single other component (a local repository) by publishing data and getting
guidance (and may not even the latter). 

The context that this was raised in was the question of NEA and if the
client and server NEA components are SACM components individually or if only
the NEA server is a SACM component.   I can understand both sides of the
argument that the client is or is not a SACM component.  The argument that
it is not because SACM is a grid is not something that I would consider to
be a valid argument because of the previous paragraphs.  The NEA client can
get guidance: there are provisions for sending guidance both about what to
assess and how to remediate in NEA.  The NEA client can do assessments:  We
talked about this for quite some time on the conference call when looking at
the SWID questions.  NEA can trigger events from either side, this is a SACM
requirement.

There are valid reasons for not considering NEA to be a SACM protocol, but
we need to be clear about why we think it is or is not a valid protocol esp.
if we are looking at adopting it as a SACM work item.

Jim

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 16 Jun 2016 21:50:03 +0000

Jim,

These are good points that align with my thinking as well.

More below.

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Thursday, June 16, 2016 3:18 PM
> To: [email-masked]
> Subject: [sacm] Is SACM based on a grid?
> 
> In yesterday's conference call, Henk made a statement that I did not feel was
> important at the time to dispute.  I have since changed my mind.
> 
> document (RFC 7632).  The use case document has the "Ice Station Zebra"
> use case (Section 2.2.5).  In this case one method of setting this up with be
> remote office.  Since there is not going to be either continuous or high-speed
> connections between the two locations, one is going to have a replication
> type situation between these two components to move guidance from the
> university to the station and end point assessments from the station back to
> the university.  There is not the concept of a grid here as there is a single
> choke point between the two locations.

I agree. 

> One does not want to have everyone talking to the same end-point every
> time that they want to get an assessment done.  So one will have a graph
> rather than a grid of SACM components.  Some endpoints will only ever talk
> to a single other component (a local repository) by publishing data and
> getting guidance (and may not even the latter).

Your point about the problems with having all other components talking to the same target endpoint every time an assessment is needed is a strong one. This is the value of having a single component that coordinates all data collection from the target endpoint. It can consolidate all of the data collection requests, provide previously requested data that is fresh enough, and compute the most efficient way to collect data from the target endpoint. This can dramatically reduce the amount of duplicate collection needed to satisfy the needs of all other downstream SACM components. This reduces the load on the target endpoint, which is a win-win IMHO. This approach is also irrespective to scenarios where the collection component is connected to a grid or directly communicating with the other SACM components requesting collection.

> The context that this was raised in was the question of NEA and if the client
> and server NEA components are SACM components individually or if only
> it is not because SACM is a grid is not something that I would consider to be a
> valid argument because of the previous paragraphs.  The NEA client can get
> guidance: there are provisions for sending guidance both about what to
> assess and how to remediate in NEA.  The NEA client can do assessments:

>From RFC5209 section 5, the NEA Client is the NEA Posture Collectors, Posture Broker Client, and Posture Transport Client on the target endpoint. This component can get guidance and will likely do so in an operational setting. The NEA server consisting of Posture Validators, Posture Broker Server, and Posture Transport Server would be the point of collection coordination. This component would work to ensure that the SACM collection requests are addressed in an efficient way that does not duplicate collection activities. 

This is expressed as requirement OP-003 in the requirements draft.

> We talked about this for quite some time on the conference call when
> looking at the SWID questions.  NEA can trigger events from either side, this
> is a SACM requirement.

Indeed. This is requirement G-011 in the requirements draft.

> if we are looking at adopting it as a SACM work item.

After a number of calls for solution submissions, the approach we have been working on based on extending NEA is the only approach that I have seen that provides an actual solution to the use cases. Use of SWID Messages represents a concrete method for collection of software inventory information from a target endpoint. This is a significant part of what we have been chartered to address. It also supports a significant portion of the data that needs to be collected to address vulnerability assessment. If extensions to NEA are not considered part of the SACM architecture, then I don't think we have made any progress towards a solution. This would be a very troubling outcome considering there is no concrete alternative for collection of software inventory information.

I believe we need to update the architecture to capture the need for a component to coordinate posture collection activities regarding target endpoints. This would bring the architecture in sync with our use cases and requirements. This would also make the role of NEA extensions more clear as part of the SACM solution set.

> Jim

Thanks,
Dave

---

From: Ira McDonald <[email-masked]>
Date: Fri, 17 Jun 2016 09:34:49 -0400

Hi Jim and Dave,

All good points that I agree with.

I especially want to reinforce Jim's comments that SACM is NOT tied
to a grid architecture (a concept as fuzzy as cloud architecture, IMO).

In the existing real world most/many endpoints will only communicate
with one upstream posture server (except when falling back, because
of a failed primary posture server).

SACM will certainly not change the world.  It may offer enough value
to integrate into the world and augment the already complex universe
of security services.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Jun 16, 2016 at 5:50 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> high-speed
> Your point about the problems with having all other components talking to
> the same target endpoint every time an assessment is needed is a strong
> one. This is the value of having a single component that coordinates all
> data collection from the target endpoint. It can consolidate all of the
> data collection requests, provide previously requested data that is fresh
> enough, and compute the most efficient way to collect data from the target
> endpoint. This can dramatically reduce the amount of duplicate collection
> needed to satisfy the needs of all other downstream SACM components. This
> reduces the load on the target endpoint, which is a win-win IMHO. This
> approach is also irrespective to scenarios where the collection component
> is connected to a grid or directly communicating with the other SACM
> components requesting collection.
>
> client
> >From RFC5209 section 5, the NEA Client is the NEA Posture Collectors,
> Posture Broker Client, and Posture Transport Client on the target endpoint.
> This component can get guidance and will likely do so in an operational
> setting. The NEA server consisting of Posture Validators, Posture Broker
> Server, and Posture Transport Server would be the point of collection
> coordination. This component would work to ensure that the SACM collection
> requests are addressed in an efficient way that does not duplicate
> collection activities.
>
> After a number of calls for solution submissions, the approach we have
> been working on based on extending NEA is the only approach that I have
> seen that provides an actual solution to the use cases. Use of SWID
> Messages represents a concrete method for collection of software inventory
> information from a target endpoint. This is a significant part of what we
> have been chartered to address. It also supports a significant portion of
> the data that needs to be collected to address vulnerability assessment. If
> extensions to NEA are not considered part of the SACM architecture, then I
> don't think we have made any progress towards a solution. This would be a
> very troubling outcome considering there is no concrete alternative for
> collection of software inventory information.
>
> I believe we need to update the architecture to capture the need for a
> component to coordinate posture collection activities regarding target
> endpoints. This would bring the architecture in sync with our use cases and
> requirements. This would also make the role of NEA extensions more clear as
> part of the SACM solution set.
>
> >
> > Jim
>
> Thanks,
> Dave
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 17 Jun 2016 22:09:03 +0200

My intend was to highlight that any SACM component should be able to 
discovery any other SACM component and find out how to consume the data 
it provides.

In regard to the use case of Ice Station Zebra, an example:
There is a SACM component on the remote site. That component is 
unavailable/unreachable to the campus site for most of the time. But if 
there is connectivity, the SACM component at the remote site can 
register again at a broker on the campus site, publish data to the SACM 
domain because it is able to register and then becomes unavailable again.

If a grid protocol would be used, data published in the available 
windows could be consumed by any other SACM component or new guidance 
could be discovered and then requested by the remote SACM component.

If an end-to-end protocol is used, data published is transported to a 
single SACM component, which again can provide it to other SACM 
components (because this capability can be discovered and used by other 
SACM components).

The choke-point scenario does not inhibit the use of a grid 
architecture, but that was actually not the point I had in mind when I 
mentioned the grid architecture. Maybe my words were chosen poorly.

My point was: It is vital for SACM components to be able to provide data 
in a standardized way so that other SACM components can consume it 
without the mapping/parsing/homogenization overhead that is still very 
common at every turn. This requires to things:

1) at minimum, SACM components require a base set of standardized 
information elements that can be used to refer to "data of interest" in 
the SACM domain (which are provided by the information model).

2) the data a component provides has to be consumable by other components

If a collector does not produce at least something every other component 
can consume, it is not a SACM component. But thats absolutely okay - if 
that kind of collector always comes with a counterpart that provides the 
functions/capabilities of a SACM component. In this case the SACM 
component might be a composite of sub-components? And this could be an 
addition to the part of the architecture that defines SACM components?

Grüße,

Henk

---

From: Adam Montville <[email-masked]>
Date: Fri, 17 Jun 2016 16:52:23 -0500

Is use of the term “grid” getting in the way?  As a working group, we have let the architecture draft expire.  That draft described an architecture with component discovery and registration as Henk describes.  That draft also described an architecture that can be configured as a consolidation architecture, as Charles put it during the virtual interim.

The drafts we have adopted as a working group presume a NEA architecture as a starting point, and this does not seem contrary to the spirit of our expired architecture draft, nor does it seem contrary to the content of our requirements draft.

It seems that what we have not yet done is to satisfy discovery, registration, and probably other requirements.  Such requirement may not be met by NEA’s.  If not, then it’s the job of the working group to satisfy those requirements by extending NEA (at least that is implied by our adoption of, at least, the SWID over PA-TNC draft).

Kind regards,

Adam

> On Jun 17, 2016, at 3:09 PM, Henk Birkholz <[email-masked]> wrote:
> 
> My intend was to highlight that any SACM component should be able to discovery any other SACM component and find out how to consume the data it provides.
> 
> There is a SACM component on the remote site. That component is unavailable/unreachable to the campus site for most of the time. But if there is connectivity, the SACM component at the remote site can register again at a broker on the campus site, publish data to the SACM domain because it is able to register and then becomes unavailable again.
> 
> If a grid protocol would be used, data published in the available windows could be consumed by any other SACM component or new guidance could be discovered and then requested by the remote SACM component.
> 
> If an end-to-end protocol is used, data published is transported to a single SACM component, which again can provide it to other SACM components (because this capability can be discovered and used by other SACM components).
> 
> The choke-point scenario does not inhibit the use of a grid architecture, but that was actually not the point I had in mind when I mentioned the grid architecture. Maybe my words were chosen poorly.
> 
> My point was: It is vital for SACM components to be able to provide data in a standardized way so that other SACM components can consume it without the mapping/parsing/homogenization overhead that is still very common at every turn. This requires to things:
> 
> 1) at minimum, SACM components require a base set of standardized information elements that can be used to refer to "data of interest" in the SACM domain (which are provided by the information model).
> 
> If a collector does not produce at least something every other component can consume, it is not a SACM component. But thats absolutely okay - if that kind of collector always comes with a counterpart that provides the functions/capabilities of a SACM component. In this case the SACM component might be a composite of sub-components? And this could be an addition to the part of the architecture that defines SACM components?
> 
> 
> Grüße,
> 
> Henk
>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 18 Jun 2016 13:36:51 +0200

+1 for fleshing out discovery, registration and other management-plane 
capabilities/functions.