Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 4 Oct 2006 09:58:02 -0700

All,
Comments on the charter inline below.  

> -----Original Message-----
> From: IESG Secretary [mailto:[email-masked]]
> Sent: Monday, October 02, 2006 7:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Nea] WG Review: Network Endpoint Assessment (nea)
> 
> A new IETF working group has been proposed in the Security Area.  
> The IESG has not made any determination as yet. The following draft 
> charter was submitted, and is provided for informational purposes 
> only.
> Please send your comments to the IESG mailing list
> ([email-masked]) by October 9.
> 
> +++
> 
> Network Endpoint Assessment (nea)
> ======================================
> 
> Current Status: Proposed Working Group
> 
> Chair(s): 
> TBD
> 
> Security Area Director(s):
> Russ Housley <[email-masked]>
> Sam Hartman <[email-masked]>
> 
> Security Area Advisor:
> Russ Housley <[email-masked]>
> 
> Mailing List: [email-masked]
> 
> Description of Working Group:
> 
> Network Endpoint Assessment (NEA) architectures have been implemented 
> in the industry to assess the "posture" of endpoint devices for the 
> purposes of monitoring compliance to an organization's posture policy 
> and optionally restricting access until the endpoint has been updated 
> to satisfy the posture requirements. An endpoint that does not comply 
> with posture policy may be vulnerable to a number of known threats 
> that may exist on the network. The intent of NEA is to facilitate 
> corrective actions to address these known vulnerabilities before a 
> host is exposed to potential attack.

Is it fair to then say that NEA is attempting to protect the endhost and
not necessarily the network? That is not immediately clear in the
charter. Obviously, the network must deal with all kinds of known and
unknown threats and a process like NEA is inadequate to protect it at
any acceptable level. That is why we employ a number of other mechanisms
like firewalls, access control, packet filters, IDS/IPS, etc. in any
combination to appropriately protect the networks. 

So, stating that NEA is not attempting to protect the network at large
would bring a lot of clarity to the charter. 

> Two deployment scenarios will be supported: advisory mode and 
> mandatory mode.
> In advisory mode, an endpoint may be advised of the result of posture 
> assessment and any recommended remediation actions, but is provided 
> normal network access regardless of the result. In mandatory mode, a 
> non-compliant endpoint is given restricted access to the network 
> sufficient for remediation purposes and any essential services or 
> denied access completely.
> 

It is unclear how the advisory vs mandatory model relates to the NEA
procedures itself. NEA is attempting to provide a vehicle to perform
some compliance tests on acceptable "postures". What the network decides
to do with that information seems entirely dependent on the policy of
the network and the extent of non-compliance, etc. What does it mean to
say that NEA *allows* an advisory and/or a mandatory model? 

> Posture refers to the hardware or software configuration of an 
> endpoint as it pertains to an organization's security policy. Posture 
> may include knowledge that software installed to protect the machine 
> (e.g. patch management software, anti-virus software, host firewall 
> software, host intrusion protection software or any custom software) 
> is enabled and up-to-date.
> On network access and while connected, an endpoint supporting NEA 
> protocols can be queried for such posture information in either 
> advisory or mandatory modes.
> 

Again, what does it mean to be queried in a particular mode? 

> Since NEA involves many different components from different vendors, 
> interoperation

s/interoperation/interoperability

> is highly desirable. The priority of
> the NEA working group is to standardize protocols at the higher layers

> in the architectures:
> the Posture Attribute protocol (PA) and the Posture Broker protocol 
> (PB).
> PA and PB will be designed to support a variety of lower layer 
> protocols.
> When used with standards for lower layers, these new protocols will 
> allow interoperability between an NEA Client from one vendor and an 
> NEA Server from another.
> 

This seems like an optimistic goal. Given that only a subset of
attributes are envisioned to be standardized and given that the kind of
attributes are likely to be ever increasing, considering that posture
refers to hardware/software configuration of an endpoint, I fail to see
how we would practically get NEA clients and NEA servers from different
vendors to perform any meaningful NEA procedures. In theory, I can see
how this can be slated to be a goal - but, I have to believe that
reality would be different. 

> Since there are already several non-standard protocols at 
> these higher layers, the NEA working group will consider 
> these existing protocols as candidates for standardization. A 
> requirements document will be written and used as a basis for 
> evaluating the candidate protocols.
> The working group may decide to standardize one of the 
> candidate protocols, use one of them as a basis for a new or 
> revised protocol, or decide that a new protocol is needed.
> 
> The NEA Requirements document will include a problem 
> statement, definition of terms, requirements for the PA and 
> PB protocols, and an overall security analysis. It will also 
> include generic requirements for the protocol transporting 
> PA, PB: the Posture Transport protocol (PT). PT protocols may 
> be standardized in other WGs since these protocols may not be 
> specific to NEA. The NEA WG will identify one mandatory to 
> implement PT protocol to ensure interoperability.
> 

I assume that the mandatory to implement PT protocol must satisfy the
criteria that will allow the NEA process to be triggered at any time
(i.e., during or after network access). Clarifying this would be good. 

> PA, the Posture Attribute protocol, consists of posture 
> attributes that are carried between a particular Posture 
> Collector in a NEA client and a particular Posture Validator 
> in a NEA Server. The PA protocol is carried inside the PB 
> protocol. Certain posture attributes will be standardized to 
> ensure interoperability but vendor-specific attributes will 
> also be supported. Vendor-specific attributes must be 
> documented in an RFC.
> 

This goes back to my comment on interoperability. Unless it is expected
that there will be ongoing efforts to continually standardize attributes
of significance to the community as the hardware/software configurations
of devices evolve, I am afraid that we won't have interoperability of
any significance. 

> The PB (Posture Broker) protocol aggregates posture 
> attributes from one or more Posture Collectors in an NEA 
> client and sends them to the NEA server for assessment by one 
> or more Posture Validators.
> 
> The PT (Posture Transport) protocol (or stack of protocols) 
> is suitable for carrying the PB protocol at the time of 
> network connection, or shortly after.
> 
> The NEA working group will not specify protocols other than 
> PA and PB at this time. The expectation is that an existing 
> protocol can be used for the PT.
> 
> 
> One commonly discussed issue with NEA systems is how to 
> handle compromised endpoints, whose reports of their own 
> posture may not be accurate. Detecting or handling such 
> endpoints is out of scope of the NEA WG. Work on PA will 
> focus on attributes useful for assessing posture of those 
> endpoints reporting accurate information. However, the 
> protocols developed by the NEA WG must be designed to 
> accommodate emerging technologies for identifying and dealing 
> with lying endpoints.
> 

I'm not sure what the last sentence means here - everything in this
paragraph alludes to the fact that lying endpoints are out of scope. If
the last sentence is alluding to the TCG efforts, why is it cryptic? As
currently stated, it doesn't seem to add any value. If we say that in
order for NEA to have a meaningful use case, it must work together with
some of the TCG stuff, then, perhaps that is effort that the WG must
ensure gets done. 

> Note that NEA is not chartered to standardize protocols for 
> remediation.
> NEA is intended to be used with new or existing tools that 
> can be used in the absence of NEA. There is an open issue 
> with respect to NEA applicability in deployment scenarios 
> where the endpoint is owned by a party that is different from 
> the organization providing network access.
> 

Why is this an open issue? When the endpoint and the organization
providing network access are owned by different parties, it simply does
not seem to be viable to do any kind of configuration assessment on the
endpoint. I think this should be stated rather clearly along these
lines: 

"NEA is limited in applicability to the case where the endpoint is owned
by the organization providing network access and performing the
assessment. In the cases where the two belong to a different party, it
is practically infeasible for an organization providing network access
to perform any kind of posture assessment or related compliance tests on
the endpoint."

Thanks,
Vidya

> Further work in the NEA WG will be considered via the 
> standard rechartering process after the completion of these 
> milestones.
> 
> Milestones:
> 
> June 2006:
> * Submit first version of NEA Requirements I-D
> 
> July 2006:
> * Agree on charter and milestones at IETF 66
> 
> October 2006:
> * Submit first draft of NEA Requirements I-D
> 
> November 2006:
> * At IETF 67, discuss issues with NEA Requirements I-D
> * Agree on solutions to issues with NEA Requirements I-D
> 
> December 2006:
> * Deadline for submission of candidate specs for PA and PB
> * Submit first version of NEA Evaluation I-D
> 
> January 2007:
> * WG Last Call on NEA Evaluation I-D
> 
> February 2007:
> * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC
> * Submit first draft of PA and PB specs for review
> 
> March 2007:
> * Discuss unresolved issues with PA and PB specs at IETF 68
> * Agree on solutions to unresolved issues with PA and PB specs
> 
> April 2007:
> * Submit revised draft of PA and PB specs
> 
> June 2007
> * WG Last Call on PA and PB specs
> 
> July 2007
> * Resolve outstanding WGLC comments on PA and PB specs at IETF 69
> 
> August 2007:
> * Submit PA and PB specs to IESG for publication as Proposed
> 
> September 2007:
> * Decide how to address MTI PT, recharter if needed
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nea
> 

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

---

From: "todd glassey" <[email-masked]>
Date: Wed, 4 Oct 2006 14:31:36 -0700

Vidya  good commentary, maybe I can add some more. The NEA, per the
charter-need's justification statement says:

> in the industry to assess the "posture" of endpoint devices

Ah two new terms of Art - "Posture" and "Devices".

> for the

here again we have Posturing... but now its a policy. The policy of dancing
or what?  so is this posture relative to the Security Policy? or how about
the Operations Integrity Policy? And is the Posture erect or is it rolling
on the floor laughing ones ...

> and optionally restricting access until the endpoint has been updated

This is a statement of effect rather than describing the thing itself. This
comment is specific to what the design of the NEA would do and not what the
NEA is but what the hey...

So then this 'thingee', the 'Posture manager', is something that is an
agent that lives in the computer to make sure its doing what its supposed to
and has all of the stuff its supposed to be, right? So the NEA seems to be
an integrity management and compliance agent right? Which means you want to
go to blows with Tripwire and the Change Management Integrity of Operations
people too? Nice...

Tripwire and Aide seem to be things that do that - Fremont and COPS too. The
configuration management is Titan and YASSP or other hardening scripts. The
logging and setup for managing the logging is already in place too. So where
does this 'compliance assurance thingee' live in that array?

> to satisfy the posture requirements.

Again - I gotta mention that you are doing alot of posturing there... So
guys - here we go again - which posture is it this time???  bent over
backwards or what?

> An endpoint that does not comply
> that may exist on the network.

And here we have the justification for the service proposed in the charter
statement... come on guys...

> The intent of NEA is to facilitate

Ahhh... Inline and continuous hardening and reporting.  So then is this the
creation of the IETF's version of an embedded Titan or YASSP? Does that real
make sense. If it does, why not  just run Titan and YASSP through SNMP,
or buy Tripwire, or use Aide and SNORT, or ... you get my point I hope.

Try this:

"The NEA is a process and methodology to integrate ongoing integrity and
process refinement into the operations of network services. The principal
goal of the NEA is a higher set of reporting models to support those
required by today's network operators for their IT Infrastructure Integrity
Programs"

And the process statement:

"To facilitate this goal, the NEA provides Audit and Systemic
Integrity/Change Management as integrated features and provides proper
evidentiary models to support this under whatever level of scrutiny is
required. Scrutiny including as formal evidence with Chain of Custody issues
to address as well"

and finally:

"To accomplish these ends, the NEA may use pieces of other services or
technologies in creating this Open Framework for operating integrity and its
evidentiary documentation."

Todd Glassey

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 04, 2006 9:58 AM
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)

All,

Thanks,
Vidya

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Oct 2006 16:48:46 -0400

> Ah two new terms of Art - "Posture" and "Devices".

I only see one.  I believe "device" is a fairly well-understood term, 
though perhaps "node" would have been more appropriate in this context.

However, I completely agree that this proposed charter uses the term 
"posture" far too often not to define it.  I fail to see how whether my 
computer is sitting upright or lying on its side is relevant to whether it 
should be allowed access to the network.

-- Jeff

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 14:36:30 -0700

Jeff -
----- Original Message ----- 
From: "Jeffrey Hutzelman" <[email-masked]>
To: "todd glassey" <[email-masked]>; "Narayanan, Vidya"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Jeffrey Hutzelman" <[email-masked]>
Sent: Monday, October 09, 2006 1:48 PM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> should be allowed access to the network.

OK Devices is really well defined in both a technical and legal sense per
the Device based Frauds Act - the little brother of the CFAA. But in this
instance I wanted to bring out the use of the misnomer "Posture" relative to
a Device.

The Device is what it is. The Posture is clearly a term for Operating Policy
which includes change management, security/integrity proofing, and the
general state-response policies that make up the controls and processes for
the Entity in question.

The problem we both saw was the indiscriminant use of the term Posture to
define a group of policies which were specific to a number of things that
the Charter was trying to lay claim to.

I don't necessarily think the NEA is a bad idea - but its about auditing and
so it needs to be crafted as an audit tool and use audit speak in the
process IMHO.

Todd Glassey

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 14:36:30 -0700

Jeff -
----- Original Message ----- 
From: "Jeffrey Hutzelman" <[email-masked]>
To: "todd glassey" <[email-masked]>; "Narayanan, Vidya"

Todd Glassey