Subject: Re: [Nea] WG Action: Network Endpoint Assessment (nea)

From: "todd glassey" <[email-masked]>
Date: Sat, 4 Nov 2006 04:33:29 -0800

All - not that you ever listen to me - but what you are referring to is an
auditing protocol so allow me to make some commentary about the charter and
tuning it. There are a number of spots where it gets too granular and those
need to be removed wholesale.

NEA is unlike ANY OTHER IETF PROJECT since it encompasses a who range of
functionality and services. It is essentially possibly something that needs
its own Area as well. Since it is an amalgam of other protocols and
processes within the scope 'of being able to prove the integrity of the
operating nodes in some network'.

---

As to the rest ... this document starts to focus on the workproduct of the
NEA team rather than the team and its goals. Bluntly, it designs too much of
NEA rather than the WG that is going to implement it. Or how that WG intends
to standardize or  develop or cobrand this work effort.

IMHO The NEA Charter is for the organization to produce the product not the
product itself. (sorry that's one of my complaints about the IETF process -
anyway more 'editing' below.

----- Original Message ----- 
From: "IESG Secretary" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 31, 2006 3:50 PM
Subject: [Nea] WG Action: Network Endpoint Assessment (nea)

> A new IETF working group has been formed in the Security Area.
> For additional information, please contact the Area Directors
> or the WG Chairs.
>
> +++
>
> Network Endpoint Assessment (nea)
> ===================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Steve Hanna <[email-masked]>
> Susan Thomson <[email-masked]>
>
> Security Area Director(s):
> Russ Housley <[email-masked]>
> Sam Hartman <[email-masked]>
>
> Security Area Advisor:
> Russ Housley <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> Subscription: http://www1.ietf.org/mailman/listinfo/nea
> Archive: http://www1.ietf.org/mail-archive/web/nea/current/index.html
>
> Description of Working Group:
>
> Network Endpoint Assessment (NEA) architectures have been implemented
> in the industry to assess

Replace the word ASSESS with COMMUNICATE

>the "posture"

Replace this use of the term POSTURE with OPERATIONAL COMPLIANCE

> of endpoint devices for the
> purposes of monitoring compliance to an organization's posture

Replace this use of the term POSTURE with "IT SECURITY and OPERATING"

>  policy

period. End of sentence.

> And optionally restricting access until the endpoint has been updated
> to satisfy the posture requirements.

Yeah - more posturing...  lose this as well.

Hey Sam - Steve and Susan; I understand the need to want to be able to
control the node if it comes out of compliance, but this is a separate
action from the CONTROL of reporting when that device is out of compliance.
So you got several pieces here, you need a compliance framework, a set of
metrics for the compliance models. A set of baseline policies to use as
controls, and then the protocol and messaging model itself. All in all this
is several man-years worth of work, especially for a group with as many
cooks in the kitchen as this one has.

By the way, NEA as an Audit Tool is a neat idea but what it really is, is a
platform configuration and integrity management service and the daemon's to
implement it.Everything boils down from an audit perspective to being a
config/integrity or function transaction instance. So ...  let me put my
auditor hat on and say -

The AUDIT DISTINCTION between reporting and functional controls in a IT
Workflow is critical to the design of any service that could conceivably be
used to control remote nodes' operations. What you are taking about is a
Systems Integrity System;  A Policy-Centric SCADA for OS and IT
Infrastructure Appliances per se.

> An endpoint that does not comply
> with posture policy may be vulnerable to a number of known threats that
> may exist on the network.

Too wordy. Lose this whole FEAR UNCERTAINTY AND DOUBT schtick please, its
worthless in the bigger picture of things and doesnt paint a nice picture
for the audit community who will be asked to rely on this system

> The intent of NEA is to facilitate corrective
> actions to address these known vulnerabilities before a host is exposed
> to potential attack.

Hmmm- I would tune this too - At the functional level, the NEA is a tool set
that allows remote control of a node with regard to its operating compliance
to some defined set of organisational IT policies. It (NEA) provides the
transport and messaging models for those communications and some secured
agent services which can then be used to make operating changes in the
remote nodes based on the reports that NEA delivers from those nodes on
their compliance-status.

It will also be the task of the NEA Working Group to define some prototype
controls and messaging features for an implmentation of this system.

The Intent of the NEA is to aggregate all of those controls and features
used in the divergent systems in a IT device so that they can be monitored,
controlled, and administered through a common framework in a secure and
reliable manner.

>  Note that an endpoint that is deemed compliant may
> still be vulnerable to threats that may exist on the network.

>  The
> network may thus continue to be exposed to such threats as well as the
> range of other threats not addressed by maintaining endpoint
> compliance.

JFC -

>
> Posture refers to the hardware or software configuration of an endpoint
> as it pertains to an organization's security policy.

It should also control endpont configuration and updates for code footprint
management. Likewise patching would need to be manageed by NEA as well to
enable it to know when some end-node was out of compliance with some set or
specific IT 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. An endpoint supporting NEA protocols can be queried for
> posture information.

Why define the scope of the messaging? Leave it open-ended.

>
> An organization may make a range of policy decisions based on the
> posture of an endpoint. NEA is not intended to be prescriptive in this
> regard. Supported deployment scenarios will include, but are not
> limited to, providing normal access regardless of compliance result
> along with any recommendations for remediation ("advisory mode"), as
> well as providing restricted access sufficient for remediation purposes
> and any essential services until an endpoint is in compliance
> ("mandatory mode"). Specifying mechanisms for providing restricted
> access is outside the scope of the NEA WG.

This is way too much detail for the Charter. This should go into the ID and
RFC's for the compnents of the NEA System.

>
> Since NEA involves many different components from different vendors,
> interoperability is important. The priority of the NEA working group is
> to develop standard protocols at the higher layers in the architecture:
> 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, the PA and PB
> protocols will allow interoperability between an NEA Client from one
> vendor and an NEA Server from another.
>
> Since there are already several non-standard protocols at these higher
> layers, the NEA working group will consider these existing protocols as
> candidates for the standard protocols. 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 and
> specify the use of one mandatory to implement PT protocol that is fully
> documented in an RFC.
>
> The PA (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. A base set of standard posture
> attributes will be specified that are expected to address many common
> posture policies. Vendor-specific attributes will also be supported;
> vendor-specific attributes will be identified by a private enterprise
> number and a vendor assigned value. Vendors are strongly encouraged to
> document vendor-specific attributes in an RFC. The NEA WG will
> investigate the use of a standard syntax for all attributes.
>
> 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 carries the PB protocol.
>
> 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.
>
> Note that NEA is not chartered to develop standard protocols for
> remediation. NEA is intended to be used with new or existing tools that
> can be used in the absence of NEA. NEA is applicable to computing
> enterprise environments, where endpoints accessing the enterprise's
> network are owned and/or expected to conform to the policies set forth
> by the organization that owns and operates the network. All other
> cases are outside the scope of the NEA charter, since we do not know
> that NEA would be useful in such cases. NEA applicability and security
> considerations will be described in the appropriate NEA documents.
>
> Further work in the NEA WG will be considered via the rechartering
> process after the completion of these milestones.
>
> Milestones:
>
> November 2006:
> * At IETF 67, discuss issues with NEA Requirements I-D
> * Submit first draft of NEA Requirements I-D
> * Agree on solutions to issues with NEA Requirements I-D
>
> December 2007:
> * Submit revised requirements I-D
>
> February 2007:
> * WGLC on NEA Requirements I-D
>
> March 2007:
> * At IETF 68, resolve any open issues with requirements I-D
>
> April 2007:
> * Submit NEA Requirements I-D to the IESG for IETF Last Call
> and publication as an Informational RFC
>
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nea

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