Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5209

Network Endpoint Assessment (NEA): Overview and Requirements

Pages: 53
Informational
Part 2 of 3 – Pages 10 to 34
First   Prev   Next

Top   ToC   RFC5209 - Page 10   prevText

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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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   ToC   RFC5209 - 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 Section