tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5209

 
 
 

Network Endpoint Assessment (NEA): Overview and Requirements

Part 2 of 3, p. 10 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
5.  Reference Model

   This section describes the reference model for Network Endpoint
   Assessment.  This model is provided to establish a context for the
   discussion of requirements and may not directly map to any particular
   product or deployment architecture.  The model identifies the major

Top      Up      ToC       Page 11 
   functionality of the NEA Client and Server and their relationships,
   as well as the protocols they use to communicate at various levels
   (e.g., PA is carried by the PB protocol).

   While the diagram shows 3 layered protocols, it is envisioned that PA
   is likely a thin message wrapper around a set of attributes and that
   it is batched and encapsulated in PB.  PB is primarily a lightweight
   message batching protocol, so the protocol stack is mostly the
   transport (PT).  The vertical lines in the model represent APIs
   and/or protocols between components within the NEA Client or Server.
   These interfaces are out of scope for standardization in the NEA WG.

    +-------------+                          +--------------+
    |  Posture    |   <--------PA-------->   |   Posture    |
    |  Collectors |                          |   Validators |
    |  (1 .. N)   |                          |   (1 .. N)   |
    +-------------+                          +--------------+
          |                                         |
          |                                         |
          |                                         |
    +-------------+                          +--------------+
    |   Posture   |                          |   Posture    |
    |   Broker    |   <--------PB-------->   |   Broker     |
    |   Client    |                          |   Server     |
    +-------------+                          +--------------+
          |                                         |
          |                                         |
    +-------------+                          +--------------+
    |   Posture   |                          |   Posture    |
    |   Transport |   <--------PT-------->   |   Transport  |
    |   Client    |                          |   Server     |
    |   (1 .. N)  |                          |   (1 .. N)   |
    +-------------+                          +--------------+

       NEA CLIENT                               NEA SERVER

                 Figure 1: NEA Reference Model

   The NEA reference model does not include mechanisms for discovery of
   NEA Clients and NEA Servers.  It is expected that NEA Clients and NEA
   Servers are configured with information that allows them to reach
   each other.  The specific methods of referencing the configuration
   and establishing the communication channel are out of scope for the
   NEA reference model and should be covered in the specifications of
   candidate protocols such as the Posture Transport (PT) protocol.

Top      Up      ToC       Page 12 
5.1.  NEA Client and Server

5.1.1.  NEA Client

   The NEA Client is resident on an endpoint device and comprised of the
   following functionality:

      o Posture Collector(s)

      o Posture Broker Client

      o Posture Transport Client(s)

   The NEA Client is responsible for responding to requests for
   attributes describing the configuration of the local operating domain
   of the client and handling the assessment results including potential
   remediation instructions for how to conform to policy.  A NEA Client
   is not responsible for reporting on the posture of entities that
   might exist on the endpoint or over the network that are outside the
   domain of execution (e.g., in other virtual machine domains) of the
   NEA Client.

   For example, a network address translation (NAT) device might route
   communications for many systems behind it, but when the NAT device
   joins the network, its NEA Client would only report its own (local)
   posture.  Similarly, endpoints with virtualization capabilities might
   have multiple independent domains of execution (e.g., OS instances).
   Each NEA Client is only responsible for reporting posture for its
   domain of execution, but this information might be aggregated by
   other local mechanisms to represent the posture for multiple domains
   on the endpoint.  Such posture aggregation mechanisms are outside the
   focus of this specification.

   Endpoints lacking NEA Client software (which is out of NEA scope) or
   choosing not to provide the attributes required by the NEA Server
   could be considered non-compliant.  The NEA model includes
   capabilities to enable the endpoint to update its contents in order
   to become compliant.

5.1.1.1.  Posture Collector

   The Posture Collector is responsible for responding to requests for
   posture information in Request Attributes from the NEA Server.  The
   Posture Collector is also responsible for handling assessment
   decisions in Result Attributes and remediation instructions in
   Remediation Attributes.  A single NEA Client can have several Posture
   Collectors capable of collecting standard and/or vendor-specific
   Posture Attributes for particular features of the endpoint.  Typical

Top      Up      ToC       Page 13 
   examples include Posture Collectors that provide information about
   Operating System (OS) version and patch levels, anti-virus software,
   and security mechanisms on the endpoint such as host-based Intrusion
   Detection System (IDS) or firewall.

   Each Posture Collector will be associated with one or more
   identifiers that enable it to be specified as the destination in a PA
   message.  The Posture Broker Client uses these identifiers to route
   messages to this Collector.  An identifier might be dynamic (e.g.,
   generated by the Posture Broker Client at run-time during
   registration) or more static (e.g., pre-assigned to the Posture
   Collector at install-time and passed to the Posture Broker Client
   during registration) or a function of the attribute messages the
   Collector desires to receive (e.g., message type for subscription).

   The NEA model allocates the following responsibilities to the Posture
   Collector:

      o Consulting with local privacy and security policies that may
        restrict what information is allowed to be disclosed to a given
        NEA Server.

      o Receiving Request Attributes from a Posture Validator and
        performing the local processing required to respond
        appropriately.  This may include:

         - Collecting associated posture information for particular
           features of the endpoint and returning this information in
           Posture Attributes.

         - Caching and recognizing the applicability of recently issued
           attributes containing reusable assertions that might serve to
           prove compliance and returning this attribute instead of
           posture information.

      o Receiving attributes containing remediation instructions on how
        to update functionality on the endpoint.  This could require the
        Collector to interact with the user, owner, and/or a remediation
        server.

      o Monitoring the posture of (a) particular features(s) on the
        endpoint for posture changes that require notification to the
        Posture Broker Client.

      o Providing cryptographic verification of the attributes received
        from the Validator and offering cryptographic protection to the
        attributes returned.

Top      Up      ToC       Page 14 
   The above list describes the model's view of the possible
   responsibilities of the Posture Collector.  Note that this is not a
   set of requirements for what each Posture Collector implementation
   must support, nor is it an exhaustive list of all the things a
   Posture Collector may do.

5.1.1.2.  Posture Broker Client

   The Posture Broker Client is both a PA message multiplexer and a
   de-multiplexer.  The Posture Broker Client is responsible for
   de-multiplexing the PB message received from the NEA Server and
   distributing each encapsulated PA message to the corresponding
   Posture Collector(s).  The model also allows for the posture
   information request to be pre-provisioned on the NEA Client to
   improve performance by allowing the NEA Client to report posture
   without receiving a request for particular attributes from the NEA
   Server.

   The Posture Broker Client also multiplexes the responses from the
   Posture Collector(s) and returns them to the NEA Server.  The Posture
   Broker Client constructs one or more PB messages using the PA
   message(s) it obtains from the Posture Collector(s) involved in the
   assessment.  The quantity and ordering of Posture Collector responses
   (PA message(s)) multiplexed into the PB response message(s) can be
   determined by the Posture Broker Client based on many factors
   including policy or characteristics of the underlying network
   transport (e.g., MTU).  A particular NEA Client will have one Posture
   Broker Client.

   The Posture Broker Client also handles the global assessment decision
   from the Posture Broker Server and may interact with the user to
   communicate the global assessment decision and aid in any necessary
   remediation steps.

   The NEA model allocates the following responsibilities to the Posture
   Broker Client:

      o Maintaining a registry of known Posture Collectors and allowing
        for Posture Collectors to dynamically register and deregister.

      o Multiplexing and de-multiplexing attribute messages between the
        NEA Server and the relevant Posture Collectors.

      o Handling posture change notifications from Posture Collectors
        and triggering reassessment.

      o Providing user notification about the global assessment decision
        and other user messages sent by the NEA Server.

Top      Up      ToC       Page 15 
5.1.1.3.  Posture Transport Client

   The Posture Transport Client is responsible for establishing a
   reliable communication channel with the NEA Server for the message
   dialog between the NEA Client and NEA Server.  There might be more
   than one Posture Transport Client on a particular NEA Client
   supporting different transport protocols (e.g., 802.1X, VPN).
   Certain Posture Transport Clients may be configured with the address
   of the appropriate Posture Transport Server to use for a particular
   network.

   The NEA model allocates the following responsibilities to the Posture
   Transport Client:

      o  Initiating and maintaining the communication channel to the NEA
         Server.  The Posture Transport Client hides the details of the
         underlying carrier that could be a Layer 2 or Layer 3 protocol.

      o  Providing cryptographic protection for the message dialog
         between the NEA Client and NEA Server.

5.1.2.  NEA Server

   The NEA Server is typically comprised of the following NEA
   functionality:

      o Posture Validator(s)

      o Posture Broker Server

      o Posture Transport Server(s)

   The Posture Validators might be located on a separate server from the
   Posture Broker Server, requiring the Posture Broker Server to deal
   with both local and remote Posture Validators.

5.1.2.1.  Posture Validator

   A Posture Validator is responsible for handling Posture Attributes
   from corresponding Posture Collector(s).  A Posture Validator can
   handle Posture Attributes from one or more Posture Collectors and
   vice-versa.  The Posture Validator performs the posture assessment
   for one or more features of the endpoint (e.g., anti-virus software)
   and creates the result and, if necessary, the remediation
   instructions, or it may choose to request additional attributes from
   one or more Collectors.

Top      Up      ToC       Page 16 
   Each Posture Validator will be associated with one or more
   identifiers that enable it to be specified as the destination in a PA
   message.  The Posture Broker Server uses this identifier to route
   messages to this Validator.  This identifier might be dynamic (e.g.,
   generated by the Posture Broker Server at run-time during
   registration) or more static (e.g., pre-assigned to a Posture
   Validator at install-time and passed to the Posture Broker Server
   during registration) or a function of the attribute messages the
   Validator desires to receive (e.g., message type for subscription).

   Posture Validators can be co-located on the NEA Server or can be
   hosted on separate servers.  A particular NEA Server is likely to
   need to handle multiple Posture Validators.

   The NEA model allocates the following responsibilities to the Posture
   Validator:

      o Requesting attributes from a Posture Collector.  The request may
        include:

         - Request Attributes that indicate to the Posture Collector to
           fetch and provide Posture Attributes for particular
           functionality on the endpoint.

      o Receiving attributes from the Posture Collector.  The response
        from the Posture Collector may include:

         - Posture Attributes collected for the requested functionality.

         - Assertion Attributes that indicate the compliance result from
           a prior assessment.

      o Assessing the posture of endpoint features based on the
        attributes received from the Collector.

      o Communicating the posture assessment result to the Posture
        Broker Server.

      o Communicating the posture assessment results to the Posture
        Collector; this attribute message may include:

         - Result Attributes that communicate the posture assessment
           result.
         - Remediation Attributes that communicate the remediation
           instructions to the Posture Collector.

      o Monitoring out-of-band updates that trigger reassessment and
        require notifications to be sent to the Posture Broker Server.

Top      Up      ToC       Page 17 
      o Providing cryptographic protection for attributes sent to the
        Posture Collector and offering cryptographic verification of the
        attributes received from the Posture Collector.

   The above list describes the model's view of the possible
   responsibilities of the Posture Validator.  Note that this is not a
   set of requirements for what each Posture Validator implementation
   must support, nor is it an exhaustive list of all the things a
   Posture Validator may do.

5.1.2.2.  Posture Broker Server

   The Posture Broker Server acts as a multiplexer and a de-multiplexer
   for attribute messages.  The Posture Broker Server parses the PB
   messages received from the NEA Client and de-multiplexes them into PA
   messages that it passes to the associated Posture Validators.  The
   Posture Broker Server multiplexes the PA messages (e.g., messages
   containing (a) Request Attribute(s) from the relevant Posture
   Validator(s)) into one or more PB messages and sends them to the NEA
   Client via the Posture Transport protocol.  The quantity and ordering
   of Posture Validator responses (PA messages) and global assessment
   decision multiplexed into the PB response message(s) can be
   determined by the Posture Broker Server based on many factors
   including policy or characteristics of the underlying network
   transport (e.g., MTU).

   The Posture Broker Server is also responsible for computing the
   global assessment decision based on individual posture assessment
   results from the various Posture Validators.  This global assessment
   decision is sent back to the NEA Client in Result Attributes within a
   PB message.  A particular NEA Server will have one Posture Broker
   Server, and this Posture Broker Server will handle all the local and
   remote Posture Validators.

   The NEA model allocates the following responsibilities to the Posture
   Broker Server:

      o Maintaining a registry of Posture Validators and allowing for
        Posture Validators to register and deregister.

      o Multiplexing and de-multiplexing posture messages from and to
        the relevant Posture Validators.

      o Computing the global assessment decision based on posture
        assessment results from the various Posture Validators and
        compliance policy.  This assessment decision is sent to the
        Posture Broker Client in a PB message.

Top      Up      ToC       Page 18 
5.1.2.3.  Posture Transport Server

   The Posture Transport Server is responsible for establishing a
   reliable communication channel with the NEA Client for the message
   dialog between the NEA Client and NEA Server.  There might be more
   than one Posture Transport Server on a particular NEA Server to
   support different transport protocols.  A particular Posture
   Transport Server will typically handle requests from several Posture
   Transport Clients and may require local configuration describing how
   to reach the NEA Clients.

   The NEA model allocates the following responsibilities to the Posture
   Transport Server:

      o Initiating and maintaining a communication channel with,
        potentially, several NEA Clients.

      o Providing cryptographic protection for the message dialog
        between the NEA Client and NEA Server.

5.2.  Protocols

   The NEA reference model includes three layered protocols (PA, PB, and
   PT) that allow for the exchange of attributes across the network.
   While these protocols are intended to be used together to fulfill a
   particular role in the model, they may offer overlapping
   functionality.  For example, each protocol should be capable of
   protecting its information from attack (see section 8.2 for more
   information).

5.2.1.  Posture Attribute Protocol (PA)

   PA is a protocol that carries one or more attributes between Posture
   Collectors and their associated Posture Validator.  The PA protocol
   is a message-oriented lightweight wrapper around a set of attributes
   being exchanged.  This wrapper may indicate the purpose of attributes
   within the message.  Some of the types of messages expected include:
   requests for posture information (Request Attributes), posture
   information about the endpoint (Posture Attributes), results of an
   assessment (Result Attributes), reusable compliance assertions
   (Assertion Attributes), and instructions to remediate non-compliant
   portions of the endpoint (Remediation Attributes).  The PA protocol
   also provides the requisite encoding and cryptographic protection for
   the Posture Attributes.

Top      Up      ToC       Page 19 
5.2.2.  Posture Broker Protocol (PB)

   PB is a protocol that carries aggregate attribute messages between
   the Posture Collectors on the NEA Client and the corresponding
   Posture Validators on the NEA Server involved in a particular
   assessment.  The PB protocol provides a session allowing for message
   dialogs for every assessment.  This PB session is then used to bind
   multiple Posture Attribute requests and responses from the different
   Posture Collectors and Posture Validators involved in a particular
   assessment.  The PB protocol may also carry the global assessment
   decision in the Result Attribute from the Posture Broker Server to
   the Posture Broker Client.  PB may be used to carry additional types
   of messages for use by the Posture Broker Client and Server (e.g.,
   information about user preferred interface settings such as
   language).

5.2.3.  Posture Transport Protocol (PT)

   PT is a transport protocol between the NEA Client and the NEA Server
   responsible for carrying the messages generated by the PB protocol.
   The PT protocol(s) transport(s) PB messages during the network
   connection request or after network connectivity has been
   established.

   In scenarios where an initial assessment needs to occur during the
   network connection, the PT protocol (e.g., EAP within 802.1X) may
   have constrained use of the network, so deployments may choose to
   limit the amount and/or size of the attributes exchanged.  The NEA
   Client and NEA Server should be able to detect when a potentially
   constrained situation exists prior to the assessment based upon
   properties of the underlying network protocol.  Using this
   information, NEA policy could dictate what aspects of the endpoint to
   include in the initial assessment and potentially limit the PA
   message attributes exchanged.  This could be followed up by a full
   reassessment after the endpoint is placed on the network.
   Alternatively, deployments can choose not to limit their assessment
   by configuring their network access technology to temporarily grant
   restricted IP connectivity prior to the assessment and use an
   unconstrained, high bandwidth IP-based transport during the
   assessment.  Some of the constraints that may exist for protocols
   involved in the network connection phase include:

      o Limited maximum transmission unit (MTU) size and ability to
        negotiate larger MTUs,

      o Inability to perform multiple roundtrips,

      o Lack of support for piggybacking attributes for other protocols,

Top      Up      ToC       Page 20 
      o Low bandwidth or high latency limitations precluding exchanges
        of large amounts of data,

      o Inability of servers to initiate messages except during the
        network connection phase.

   The PT protocol selection process needs to consider the impact of
   selecting a particular PT and set of underlying protocols on the
   deployment needs of PA and PB.  PA and PB will be selected prior to
   PT so the needs of PA and PB will be known.  Certain underlying
   protocol stacks may be too constrained to support adequate NEA
   assessments during network connection.

   The PT protocol provides reliable message delivery, mutual
   authentication, and cryptographic protection for the PB messages as
   specified by local policy.

5.3.  Attributes

   The PA protocol is responsible for the exchange of attributes between
   a Posture Collector and Posture Validator.  The PB protocol may also
   carry the global assessment decision attributes from the Posture
   Broker Server.  Attributes are effectively the reserved word 'nouns'
   of the posture assessment.  The NEA Server is only able to ask for
   information that has a corresponding attribute, thus bounding what
   type of posture can be obtained.  The NEA WG will define a common
   (standard) set of attributes that are expected to be widely
   applicable to Posture Collectors and thus used for maximum
   interoperability, but Posture Collectors may support additional
   vendor-specific attributes when necessary.

   Depending on the deployment scenario, the purpose of the attributes
   exchanged may be different (e.g., posture information vs. asserted
   compliance).  This section discusses the originator and expected
   situation resulting in the use of each classification of attributes
   in a PA message.  These classifications are not intended to dictate
   how the NEA WG will specify the attributes when defining the
   attribute namespace or schema.

Top      Up      ToC       Page 21 
5.3.1.  Attributes Normally Sent by NEA Client:

      o Posture Attributes - Attributes and values sent to report
        information about a particular aspect (based on semantic of the
        attribute) of the system.  These attributes are typically sent
        in response to Request Attributes from the NEA Server.  For
        example, a set of Posture Attributes might describe the status
        of the host-based firewall (e.g., if running, vendor, version).
        The NEA Server would base its decision on comparing this type of
        attribute against policy.

      o Assertion Attributes - Attributes stating recent prior
        compliance to policy in hopes of avoiding the need to recollect
        the posture and send it to the NEA Server.  Examples of
        assertions include (a) NEA Server provided attributes (state)
        describing a prior evaluation (e.g., opaque to endpoint, signed,
        time stamped items stating specific results) or (b) NEA Client
        identity information used by the NEA Server to locate state
        about prior decisions (e.g., system-bound cookie).  These might
        be returned in lieu of, or in addition to, Posture Attributes.

5.3.2.  Attributes Normally Sent by NEA Server:

      o Request Attributes - Attributes that define the specific posture
        information desired by the NEA Server.  These attributes might
        effectively form a template that the Posture Collector fills in
        (subject to local policy restrictions) with the specific value
        corresponding to each attribute.  The resulting attributes are
        typically Posture or Assertion Attributes from the NEA Client.

      o Result Attributes - Attributes that contain the decisions of the
        Posture Validators and/or Posture Broker Server.  The level of
        detail provided may vary from which individual attributes were
        compliant or not through just the global assessment decision.

      o Remediation Attributes - Attributes that explain to the NEA
        Client and its user how to update the endpoint to become
        compliant with the NEA Server policies.  These attributes are
        sent when the global assessment decision was that the endpoint
        is not currently compliant.  Remediation and Result Attributes
        may both exist within a NEA Server attribute message.

      o Assertion Attributes - Attributes containing NEA Server
        assertions of compliance to a policy for future use by the NEA
        Client.  See section 5.3.1 for more information.

Top      Up      ToC       Page 22 
6.  Use Cases

   This section discusses several of the NEA use cases with intent to
   describe and collectively bound the NEA problem space under
   consideration.  The use cases provide a context and general rationale
   for the defined requirements.  In order to ease understanding of each
   use case and how it maps to the reference model, each use case will
   be accompanied by a simple example and a discussion of how this
   example relates to the NEA protocols.  It should be emphasized that
   the provided examples are not intended to indicate the only approach
   to addressing the use case but rather are included to ease
   understanding of how the flows might occur and impact the NEA
   protocols.

   We broadly classify the use cases into two categories, each with its
   own set of trigger events:

      o Initial assessment - evaluation of the posture of an endpoint
        that has not recently been assessed and thus is not in
        possession of any valid proof that it should be considered
        compliant.  This evaluation might be triggered by a request to
        join a network, a request to use a service, or a desire to
        understand the posture of a system.

      o Reassessment - evaluation of the posture of an endpoint that has
        previously been assessed.  This evaluation could occur for a
        variety of reasons including the NEA Client or Server
        recognizing an occurrence affecting the endpoint that might
        raise the endpoint's risk level.  This could be as simple as it
        having been a long time since the endpoint's prior reassessment.

6.1.  Initial Assessment

   An initial assessment occurs when a NEA Client or Server event occurs
   that causes the evaluation of the posture of the endpoint for the
   first time.  Endpoints do not qualify for this category of use case
   if they have been recently assessed and the NEA Client or Server has
   maintained state (or proof) that the endpoint is compliant and
   therefore does not need to have its posture evaluated again.

6.1.1.  Triggered by Network Connection or Service Request

   This use case focuses on assessments performed at the time an
   endpoint attempts to join a network or request use of a service that
   requires a posture evaluation.  This use case is particularly
   interesting because it allows the NEA Server to evaluate the posture
   of an endpoint before allowing it access to the network or service.

Top      Up      ToC       Page 23 
   This approach could be used to help detect endpoints with known
   vulnerabilities and facilitate their repair before they are admitted
   to the network and potentially exposed to threats on the network.

   A variety of types of endpoint actions could result in this class of
   assessment.  For example, an assessment could be triggered by the
   endpoint trying to access a highly protected network service (e.g.,
   financial or HR application server) where heightened security
   checking is required.  A better known example could include
   requesting entrance to a network that requires systems to meet
   compliance policy.  This example is discussed in more detail in the
   following section.

6.1.1.1.  Example

   An IT employee returning from vacation boots his office desktop
   computer that generates a request to join the wired enterprise
   network.  The network's security policy requires the system to
   provide posture information in order to determine whether the
   desktop's security features are enabled and up to date.  The desktop
   sends its patch, firewall, and anti-virus posture information.  The
   NEA Server determines that the system is lacking a recent security
   patch designed to fix a serious vulnerability and the system is
   placed on a restricted access network.  The desktop follows the
   provided remediation instructions to download and install the
   necessary patch.  Later, the desktop requests again to join the
   network and this time is provided full access to the enterprise
   network after a full assessment.

6.1.1.2.  Possible Flows and Protocol Usage

   The following describes typical message flows through the NEA
   reference model for this example use case:

      1. The IT employee's desktop computer connects to the network
         through an access gateway in the wired enterprise network.

      2. The Posture Broker Server on the NEA Server is instructed to
         assess the endpoint joining the wired network.

      3. Based upon compliance policy, the Posture Broker Server
         contacts the operating system patch, host-based firewall, and
         anti-virus Posture Validators to request the necessary posture.
         Each Posture Validator creates a PA message containing the
         desired attributes to be requested for assessment from the
         desktop system.

Top      Up      ToC       Page 24 
      4. The Posture Broker Server aggregates the PA messages from the
         Posture Validators into a PB message.  The Posture Broker
         Server passes the PB message to the Posture Transport Server
         that uses the PT protocol to send the PB message to the NEA
         Client on the desktop computer.

      5. The Posture Transport Client receives the message from the NEA
         Server and passes it to the Posture Broker Client for message
         delivery.

      6. The Posture Broker Client de-multiplexes the PB message and
         delivers the PA messages with the requests for attributes to
         the firewall, operating system patch, and anti-virus Posture
         Collectors.

      7. Each Posture Collector involved consults local privacy policy
         to determine what information is allowed to be disclosed and
         then returns the requested attributes that are authorized in a
         PA message to the Posture Broker Client.

      8. The Posture Broker Client aggregates these PA messages into a
         single PB message and sends it to the Posture Broker Server
         using the Posture Transport Client to Server session.

      9. The Posture Transport Server provides the PB message to the
         Posture Broker Server that de-multiplexes the message and sends
         the appropriate attributes to the corresponding Posture
         Validator.

     10. Each Posture Validator compares the values of the attributes it
         receives with the expected values defined in its policy.

     11. The anti-virus and firewall Posture Validators return
         attributes to the Posture Broker Server stating the desktop
         computer is compliant, but the operating system patch Posture
         Validator returns non-compliant.  The operating system patch
         Posture Validator creates a PA message that contains attributes
         with remediation instructions in addition to the attribute
         indicating non-compliance result.

     12. The Posture Broker Server aggregates the PA messages and sends
         them in a PB message to the Posture Broker Client via the
         Posture Transport Server and Posture Transport Client.

Top      Up      ToC       Page 25 
     13. The Posture Broker Client delivers the PA messages with the
         results from the various Posture Validators to the Posture
         Collectors including the PA message containing attributes with
         remediation instructions to the operating system patch Posture
         Collector.  This Posture Collector then interacts with the user
         to download and install the needed patches, potentially while
         the endpoint remains quarantined.

     14. Upon completion of the remediation, the above steps 1-10 are
         repeated (triggered by the NEA Client repeating its request to
         join the network).

     15. This time each involved Posture Validator (including the
         operating system patch Posture Validator) returns a compliant
         status and the Posture Broker Server returns a compliant result
         indicating a global success.

     16. The Posture Broker Client receives the compliant result and the
         IT employee's desktop is now on the network.

6.1.1.3.  Impact on Requirements

   The following are several different aspects of the use case example
   that potentially need to be factored into the requirements.

      o Posture assessment before endpoint allowed on network

      o Endpoint sends attributes containing posture information

      o NEA Server sends remediation instructions

      o NEA Client causes a reassessment after remediation

6.1.2.  Triggered by Endpoint

   This use case highlights that an endpoint (possibly at the request of
   a user) may wish to trigger an assessment of its posture to determine
   whether its security protective mechanisms are running and up to
   date.

6.1.2.1.  Example

   A student goes to the terminal room to work on a project.  The
   terminal room contains shared systems owned by the school that are on
   the network.  These systems have been previously used by other
   students so their security posture is unknown.  The student wishes to
   check whether a system is currently in compliance with the school's
   security policies prior to doing work, so she requests a posture

Top      Up      ToC       Page 26 
   assessment.  The NEA Server performs an initial assessment of the
   system and determines it is compliant but the anti-virus protection
   is not in use.  The student receives an advisory response indicating
   the system's anti-virus software is turned off but that otherwise it
   complies with the school's policy.  The student turns on the
   anti-virus software, initiates a scan, and upon completion decides to
   trust the system with her work.

6.1.2.2.  Possible Flows and Protocol Usage

   The following describes the message flows through the NEA reference
   model for the student using a terminal room shared system example:

      1. Student triggers the Posture Broker Client on the computer
         system in the terminal room to initiate a posture assessment.

      2. The Posture Broker Client establishes a session with the
         Posture Broker Server that causes an assessment to be
         triggered.

      3. The Posture Broker Server detects the new session and consults
         policy to determine that Posture Validators to involve in the
         assessment.  The Posture Broker Server decides to employ
         several Posture Validators including the anti-virus Posture
         Validator.

      4. The Posture Validators involved create PA messages containing
         requests for particular attributes containing information about
         the desired terminal room computer based on the school's
         security policy.

      5. The Posture Broker Server assembles a PB message including each
         of the PA messages from the Posture Validators.

      6. The Posture Transport Server sends the PB message to the
         Posture Transport Client where it is passed on to the Posture
         Broker Client.

      7. The Posture Broker Client on the student's computer
         de-multiplexes the PA messages and delivers them to the
         corresponding Posture Collectors.

      8. The Posture Collectors consult privacy policy to decide what
         information to share with the Server.  If allowable, the
         Collectors each return a PA message containing the requested
         posture to the Posture Broker Client.

Top      Up      ToC       Page 27 
      9. The Posture Broker Client aggregates the returned PA messages
         into a PB message and hands it to the Posture Transport Client
         for transmission to the Posture Transport Server.

     10. The Posture Broker Server separates and distributes the Posture
         Collector PA messages to the associated Posture Validators.

     11. The Posture Validators determine whether the attributes
         containing the posture included in the PA message are compliant
         with their policies and returns a posture assessment decision
         to the Posture Broker Server.  In this case, the anti-virus
         Posture Validator returns a PA message indicating a
         non-compliant result because the anti-virus software is not
         running and includes attributes describing how to activate the
         software.

     12. The Posture Broker Server determines the overall compliance
         decision based on all of the Validators' assessment results and
         sends a PB message containing an attribute expressing the
         global assessment decision and the anti-virus Validator's PA
         message.  In this case, the global assessment decision
         indicates the system is compliant (despite the anti-virus
         Validator's result) because the Posture Broker Server policy
         allowed for the anti-virus to not be running as long as the
         system was properly patched and running a firewall (which was
         the case according to the other Posture Validators).

     13. The Posture Transport Server sends the PB message to the
         Posture Transport Client that provides the message to the
         Posture Broker Client.

     14. The Posture Broker Client on the terminal room computer
         examines the PB message's global assessment decision attribute
         and reports to the student that the system was deemed to be
         compliant, but that an advisory was included.

     15. The Posture Broker Client provides the PA message with the
         remediation attributes to the anti-virus Posture Collector that
         interacts with the user to explain how to turn on anti-virus to
         improve the local protections.

     16. The student turns on the anti-virus software and on completion
         steps 1-10 are repeated.

     17. This time the anti-virus Posture Validator returns a success
         status and the Posture Broker Server returns a successful
         global assessment decision in the PB message.

Top      Up      ToC       Page 28 
     18. The Posture Broker Client receives the successful global
         assessment decision in the PB message and the student now uses
         the computer for her assignment.

6.1.2.3.  Impact on Requirements

   The following are several different aspects of the use case example
   that potentially need to be factored into the requirements.

      o Voluntary endpoint requested initial assessment,

      o Successful (compliant) global assessment decision included in PB
        message with a PA message containing an advisory set of
        attributes for remediation.

6.2.  Posture Reassessment

   Reassessment(s) of endpoints can happen anytime after being admitted
   to the network after a successful initial NEA assessment.  These
   reassessments may be event-based, such as driven by posture changes
   detected by the NEA Client, or changes detected by network
   infrastructure such as detection of suspicious behavior or network
   policy updates on the NEA Server.  They may also be periodic (timer-
   driven) to reassess the health of the endpoint.

6.2.1.  Triggered by NEA Client

   This use case allows for software on the endpoint or a user to
   determine that a reassessment of the system is required.  There are a
   variety of reasons why such a reassessment might be beneficial
   including: changes in its previously reported posture, detection of
   potentially suspicious behavior, or even to enable the system to
   periodically poll the NEA Server to assess its condition relative to
   the latest policies.

6.2.1.1.  Example

   The desktops within a company's HR department have a history of poor
   security practices and eventual compromise.  The HR department
   administrator decides to deploy software on each desktop to monitor
   the use of security protective mechanisms to assure their use.  One
   day, an HR person accidentally turns off the desktop firewall.  The
   monitoring process detects the lack of a firewall and contacts the
   NEA Server to request a reassessment of the firewall compliance.  The
   NEA Server returns a decision that the firewall must be reactivated
   to stay on the network.  The NEA Client explains the decision to the
   user and how to reactivate the firewall.  The HR person restarts the
   firewall and initiates a request to rejoin the network.

Top      Up      ToC       Page 29 
6.2.1.2.  Possible Flows & Protocol Usage

   The following describes the message flows through the NEA reference
   model for the HR department example:

      1. The desktop monitoring software that typically might act as a
         Posture Collector triggers the Posture Broker Client to
         initiate a posture reassessment.  The Posture Broker Client
         creates a PB message that contains a PA message indicating the
         desktop firewall has been disabled.

      2. The Posture Broker Client sends the PB message to the Posture
         Broker Server.

      3. The Posture Transport Client sends the PB message to the
         Posture Transport Server over the PT protocol.

      4. The Posture Broker Server receives the PB message and forwards
         the PA message to the firewall Posture Validator for
         evaluation.

      5. The firewall Posture Validator determines that the endpoint is
         no longer compliant because its firewall has been disabled.

      6. The Posture Validator generates a PA message that contains
         attributes indicating a non-compliant posture assessment result
         and remediation instructions for how to reactivate the
         firewall.

      7. The Posture Validator communicates the PA message with the
         posture assessment result to the Posture Broker Server to
         respond back to the NEA Client.

      8. The Posture Broker Server generates a PB message including a
         global assessment decision of non-compliant and the PA message
         from the firewall Posture Validator.

      9. The Posture Transport Server transports the PB message to the
         Posture Transport Client where it is passed to the Posture
         Broker Client.

     10. The Posture Broker Client processes the attribute containing
         the global assessment decision received from the NEA Server and
         displays the non-compliance messages to the user.

Top      Up      ToC       Page 30 
     11. The Posture Broker Client forwards the PA message to the
         firewall Posture Collector; the Posture Collector displays the
         remediation instructions for how to enable the desktop
         firewall.

     12. The user is prompted to initiate a reassessment after
         completing the remediation.

     13. Upon completion of the remediation, the NEA Client reinitiates
         a request for reassessment and steps 1-4 are repeated.  This
         time the firewall Posture Validator determines the endpoint is
         compliant and returns a successful posture assessment decision.

     14. The Posture Broker Server generates a PB message with a global
         assessment decision of compliant and returns this to the NEA
         Client.

6.2.1.3.  Impact on Requirements

   The following are several different aspects of the use case example
   that potentially need to be factored into the requirements.

      o Voluntary, endpoint (software) initiated posture reassessment
        request

      o NEA Server requests specific firewall-oriented Posture
        Attributes

      o NEA Client (firewall Posture Collector) interacts with user to
        remediate problem

6.2.2.  Triggered by NEA Server

   In many cases, especially for reassessment, the NEA Server may
   initiate specific or complete reassessment of one or more endpoints
   triggered by:

      o Time (periodic)
      o Event occurrence
      o Policy updates

6.2.2.1.  Example

   An enterprise requires employees on the network to always stay up to
   date with security critical operating system patches.  A marketing
   employee joins the network and performs an initial assessment.  The
   assessment determines the employee's laptop is compliant.  Several

Top      Up      ToC       Page 31 
   hours later, a major operating system vendor releases a set of
   patches preventing a serious vulnerability that is being exploited on
   the Internet.

   The enterprise administrators make available the patches and change
   the network policy to require them to be installed by 5 PM.  This
   policy change causes the NEA Server to request a reassessment to
   determine which endpoints are impacted and lacking the patches.  The
   marketing employee's laptop is reassessed and determined to need the
   patches.  A remediation advisory is sent and presented to the
   employee explaining how to obtain the patches and that they must be
   installed by 5 PM.  The marketing employee immediately downloads and
   installs the patches and obtains an assertion that all patches are
   now installed.

   At 5 PM, the enterprise performs another reassessment of all impacted
   endpoints to determine if they are now in compliance.  The marketing
   employee's laptop is reassessed and presents the assertion that it
   has the patches installed and thus is determined to be compliant.

6.2.2.2.  Possible Flows and Protocol Usage

   The following describes the message flows through the NEA reference
   model for the above example:

      1. Marketing employee joins network and completes an initial
         assessment resulting in a compliant decision.

      2. The Enterprise Administrator configures an operating system
         patch policy indicating that recent patches are required on all
         endpoints by 5 PM to prevent serious vulnerabilities.

      3. The NEA Server's operating system patch Posture Validator
         becomes aware of this policy change and creates a PA message
         requesting attributes describing OS patches in use and triggers
         the Posture Broker Server to initiate a posture reassessment of
         all endpoints connected to the network.

      4. The Posture Broker creates a PB message that includes the PA
         message from the operating system patch Posture Validator.

      5. The Posture Broker Server gradually establishes a session with
         each available NEA Client.

      6. The Posture Broker Server sends the PB message to the Posture
         Broker Client.

Top      Up      ToC       Page 32 
      7. The Posture Transport Server carries the PB message to the
         Posture Transport Client over the PT protocol.

      8. The Posture Broker Client receives the PB message and forwards
         the PA message to the operating system patch Posture Collector.

      9. The operating system patch Posture Collector determines the OS
         patches present on the endpoint and if authorized by its
         disclosure policy creates a PA message containing the patch
         information attributes.

     10. The Posture Broker Client sends a PB message that includes the
         operating system patch PA message.

     11. The Posture Transport Client transports the PB message to the
         Posture Transport Server where it is passed to the Posture
         Broker Server.

     12. The Posture Broker Server receives the PB message and delivers
         the PA message to the operating system patch Posture Validator.

     13. The operating system patch Posture Validator extracts the
         attributes describing the current OS patches from the PA
         message and uses the values to determine whether the endpoint
         is compliant with the new policy.  The Posture Validator
         determines that the endpoint is not compliant since it does not
         have the new OS patches installed.

     14. The Posture Validator generates a PA message that includes
         attributes stating the posture assessment decision is
         non-compliant and attributes containing the remediation
         instructions to enable the endpoint to download the required OS
         patches.

     15. The Posture Validator communicates the posture assessment
         result to the Posture Broker Server along with its PA message.

     16. The Posture Broker Server generates a global assessment
         decision and sends a PB message with the decision and the
         operating system patch Posture Validator's PA message.

     17. The Posture Transport Server transports the PB message to the
         Posture Transport Client where it is passed to the Posture
         Broker Client.

     18. The Posture Broker Client processes the Result Attribute
         received from the NEA Server and displays the non-compliance
         decision to the user.

Top      Up      ToC       Page 33 
     19. The Posture Broker Client forwards the PA message containing
         the remediation instructions to the operating system patch
         Posture Collector; the Posture Collector guides the user with
         instructions on how to become compliant that include
         downloading the appropriate OS patches to prevent the
         vulnerability.

     20. The marketing employee installs the required patches and now is
         in compliance.

     21. The NEA Client triggers a reassessment of the operating system
         patches that causes a repeat of many of the steps above.  This
         time, in step 13 the operating system patch Posture Validator
         determines the marketing employee's laptop is compliant.  It
         returns a reusable (e.g., signed and dated) set of attributes
         that assert OS patch compliance to the latest policy.  These OS
         patch compliance assertions can be used in a future PA message
         from the operating system patch Collector instead of
         determining and providing the specific patch set posture as
         before.

     22. This time when the operating system patch Posture Collector
         receives the PA message that contains reusable attributes
         asserting compliance, it caches those attributes for future
         use.

     23. Later at 5 PM, the NEA Server triggers a gradual reassessment
         to determine compliance to the patch advisory.  When the
         operating system patch Posture Collector receives the request
         for posture information (like in step 9 above) it returns the
         cached set of assertions (instead of specific OS patch
         information) to indicate that the patches have been installed
         instead of determining all the patches that have been installed
         on the system.

     24. When the operating system patch Posture Validator receives the
         PA message containing the assertions, it is able to determine
         that they are authentic and acceptable assertions instead of
         specific posture.  It returns a posture assessment decision of
         compliant thus allowing the laptop to remain on the network.

6.2.2.3.  Impact on Requirements

   The following are several different aspects of the use case example
   that potentially need to be factored into the requirements.

      o Server-initiated reassessment required due to urgent patch
        availability

Top      Up      ToC       Page 34 
      o NEA Client submits reusable assertion attributes instead of
        posture that patch is installed

      o NEA Server capable of recognizing previously issued assertion
        attributes are sufficient instead of posture



(page 34 continued on part 3)

Next RFC Part