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.
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.
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.
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.
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.
section 8.2 for more information).
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.
section 5.3.1 for more information.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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