Network Working Group P. Sangster
Request for Comments: 5209 Symantec
Category: Informational H. Khosravi
Intel
M. Mani
Avaya
K. Narayan
Cisco Systems
J. Tardo
Nevis Networks
June 2008
Network Endpoint Assessment (NEA): Overview and Requirements
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced.
この文書では、NEA（ネットワークエンドポイント評価）参照モデルの構成要素間の問題文、範囲、およびプロトコル要件を定義します。 NEAは、ネットワークの所有者（例えば、リモートアクセスを提供する企業に）システムの姿勢を評価するためのメカニズムを提供します。これは、ネットワークアクセスのための、および/またはその後にネットワークに接続している間、いつでも要求時に起こり得ます。学んだ姿勢情報は、コンプライアンス重視の意思決定のさまざまに応用することができます。アンチウイルスおよびホストベースのファイアウォールソフトウェア：姿勢情報が欠けているかのような旧式のセキュリティ保護メカニズムを持っているシステムを検出するために頻繁に便利です。要求のコンテキストを提供するために、基準モデルと用語が導入されています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................5
3. Applicability ...................................................7
3.1. Scope ......................................................7
3.2. Applicability of Environments ..............................8
4. Problem Statement ...............................................9
5. Reference Model ................................................10
5.1. NEA Client and Server .....................................12
5.1.1. NEA Client .........................................12
5.1.1.1. Posture Collector .........................12
5.1.1.2. Posture Broker Client .....................14
5.1.1.3. Posture Transport Client ..................15
5.1.2. NEA Server .........................................15
5.1.2.1. Posture Validator .........................15
5.1.2.2. Posture Broker Server .....................17
5.1.2.3. Posture Transport Server ..................18
5.2. Protocols .................................................18
5.2.1. Posture Attribute Protocol (PA) ....................18
5.2.2. Posture Broker Protocol (PB) .......................19
5.2.3. Posture Transport Protocol (PT) ....................19
5.3. Attributes ................................................20
5.3.1. Attributes Normally Sent by NEA Client: ............21
5.3.2. Attributes Normally Sent by NEA Server: ............21
6. Use Cases ......................................................22
6.1. Initial Assessment ........................................22
6.1.1. Triggered by Network Connection or Service
Request ............................................22
6.1.1.1. Example ...................................23
6.1.1.2. Possible Flows and Protocol Usage .........23
6.1.1.3. Impact on Requirements ....................25
6.1.2. Triggered by Endpoint ..............................25
6.1.2.1. Example ...................................25
6.1.2.2. Possible Flows and Protocol Usage .........26
6.1.2.3. Impact on Requirements ....................28
6.2. Posture Reassessment ......................................28
6.2.1. Triggered by NEA Client ............................28
6.2.1.1. Example ...................................28
6.2.1.2. Possible Flows & Protocol Usage ...........29
6.2.1.3. Impact on Requirements ....................30
6.2.2. Triggered by NEA Server ............................30
6.2.2.1. Example ...................................30
6.2.2.2. Possible Flows and Protocol Usage .........31
6.2.2.3. Impact on Requirements ....................33
7. Requirements ...................................................34
7.1. Common Protocol Requirements ..............................34
7.2. Posture Attribute (PA) Protocol Requirements ..............35
7.3. Posture Broker (PB) Protocol Requirements .................36
7.4. Posture Transport (PT) Protocol Requirements ..............38
8. Security Considerations ........................................38
8.1. Trust .....................................................39
8.1.1. Endpoint ...........................................40
8.1.2. Network Communications .............................41
8.1.3. NEA Server .........................................42
8.2. Protection Mechanisms at Multiple Layers ..................43
8.3. Relevant Classes of Attack ................................43
8.3.1. Man-in-the-Middle (MITM) ...........................44
8.3.2. Message Modification ...............................45
8.3.3. Message Replay or Attribute Theft ..................45
8.3.4. Other Types of Attack ..............................46
9. Privacy Considerations .........................................46
9.1. Implementer Considerations ................................47
9.2. Minimizing Attribute Disclosure ...........................49
10. References ....................................................50
10.1. Normative References .....................................50
10.2. Informative References ...................................50
11. Acknowledgments ...............................................51
Endpoints connected to a network may be exposed to a wide variety of threats. Some protection against these threats can be provided by ensuring that endpoints conform to security policies. Therefore, the intent of NEA is to assess these endpoints to determine their compliance with security policies so that corrective measures can be provided before they are exposed to those threats. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as host-based firewalls, anti-virus software, or the absence of critical security patches, the NEA protocols provide a mechanism to detect this fact and indicate appropriate remediation actions to be taken. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network.
ネットワークに接続されたエンドポイントは、脅威のさまざまなにさらされてもよいです。これらの脅威に対するいくつかの保護は、エンドポイントがセキュリティポリシーに準拠していることを保証することによって提供することができます。したがって、NEAの意図は、彼らがそれらの脅威にさらされる前に是正措置を提供できるように、セキュリティポリシーの遵守を決定するために、これらのエンドポイントを評価することです。システムは、そのようなホストベースのファイアウォール、アンチウイルスソフトウェア、または重要なセキュリティパッチの有無など、適切な防御のメカニズムを欠いているため、コンプライアンスの外にあると判断された場合、NEAプロトコルはこの事実を検出するためのメカニズムを提供しますそして、適切な修復アクションを取ることが示しています。コンプライアントであると考えられるエンドポイントがまだネットワーク上に存在する可能性が脅威に対して脆弱であり得ることに留意されたいです。
NEA typically involves the use of special client software running on the requesting endpoint that observes and reports on the configuration of the system to the network infrastructure. The infrastructure has corresponding validation software that is capable of comparing the endpoint's configuration information with network compliance policies and providing the result to appropriate authorization entities that make decisions about network and application access. Some endpoints may be incapable of running the
NEAは、一般的に観察し、ネットワークインフラストラクチャへのシステムの構成に関するレポートを要求エンドポイント上で実行されている特別なクライアントソフトウェアの使用を含みます。インフラストラクチャは、ネットワークコンプライアンスポリシーとエンドポイントの設定情報を比較し、ネットワークとアプリケーションのアクセスに関する決定を行う適切な認証エンティティに結果を提供することが可能である検証ソフトウェアを対応しています。いくつかのエンドポイントが実行されていることができないかもしれ
NEA Client software (e.g., printer) or be unwilling to share information about their configuration. This situation is outside the scope of NEA and is subject to local policies.
NEA Clientソフトウェア（例えば、プリンタ）、またはそれらの構成に関する情報を共有することが不本意です。この状況は、NEAの範囲外であると、ローカルポリシーに従うものとします。
The result of an endpoint assessment may influence an access decision that is provisioned to the enforcement mechanisms on the network and/or endpoint requesting access. While the NEA Working Group recognizes there may be a link between an assessment and the enforcement of a resulting access decision, the mechanisms and protocols for enforcement are not in scope for this specification.
エンドポイント評価の結果は、ネットワークおよび/またはエンドポイントのアクセスを要求するの執行メカニズムにプロビジョニングされたアクセスの決定に影響を与える可能性があります。 NEA作業部会が評価し、その結果アクセス決定の執行との間にリンクがあるかもしれません認識しますが、執行のためのメカニズムとプロトコルは、この仕様のスコープではありません。
Architectures, similar to NEA, have existed in the industry for some time and are present in shipping products, but do not offer adequate interoperability. Some examples of such architectures include: Trusted Computing Group's Trusted Network Connect [TNC], Microsoft's Network Access Protection [NAP], and Cisco's Cisco Network Admission Control [CNAC]. These technologies assess the software and/or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy.
NEAに似たアーキテクチャは、いくつかの時間のための業界に存在し、出荷製品に存在しているが、十分な相互運用性を提供していませんしています。このようなアーキテクチャのいくつかの例としては、トラステッド・コンピューティンググループのトラステッドネットワークコネクト[TNC]、Microsoftのネットワークアクセス保護[NAP]、およびシスコのCiscoネットワークアドミッションコントロール[CNACを]。これらの技術は、ソフトウェアおよび/またはモニタリングまたは組織のポリシーに従うことを強制する目的のためのエンドポイントデバイスのハードウェア構成を評価します。
The NEA Working Group is developing standard protocols that can be used to communicate compliance information between a NEA Client and a NEA Server. This document provides the context for NEA including: terminology, applicability, problem statement, reference model, and use cases. It then identifies requirements for the protocols used to communicate between a NEA Client and NEA server. Finally, this document discusses some potential security and privacy considerations with the use of NEA. The majority of this specification provides informative text describing the context of NEA.
NEA作業部会は、NEA ClientとNEA Serverの間のコンプライアンス情報を通信するために使用することができ、標準的なプロトコルを開発しています。用語、適用性、問題文の、参照モデル、および使用事例：この文書は、以下を含むNEAのコンテキストを提供します。その後、NEA ClientとNEAサーバ間の通信に使用されるプロトコルのための要件を識別する。最後に、このドキュメントはNEAを使用していくつかの潜在的なセキュリティとプライバシーの考慮事項について説明します。この仕様の大半は、NEAのコンテキストを記述する情報テキストを提供します。
Use of each capitalized word within a sentence or phrase carries the following meaning during the NEA WG's protocol selection process:
文章やフレーズ内の各大文字の単語の使用は、NEA WGのプロトコル選択プロセスの間に以下のような意味を運びます：
MUST - indicates an absolute requirement
MUST - 絶対的な要件を示し
MUST NOT - indicates something absolutely prohibited
MUST NOT - 絶対に禁止何かを示し、
SHOULD - indicates a strong recommendation of a desired result
所望の結果の強い推薦を示す - SHOULD
SHOULD NOT - indicates a strong recommendation against a result
べきではない - 結果に対して強い勧告を示し、
MAY - indicates a willingness to allow an optional outcome
MAY - オプションの成果を許可する意欲を示しています
Lower case use of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" carry their normal meaning and are not subject to these definitions.
小文字の「MUST」の使用、「NOT MUST」、「SHOULD」、「べきではない」、とは、その通常の意味を運び、これらの定義の対象とならない「MAY」。
This section defines a set of terms used throughout this document. In some cases these terms have been used in other contexts with different meanings so this section attempts to describe each term's meaning with respect to the NEA WG activities.
このセクションでは、このドキュメントで使用されている用語のセットを定義します。このセクションでは、NEA WGの活動に関して、各用語の意味を説明しようとしたので、いくつかのケースではこれらの用語は、異なる意味を持つ他のコンテキストで使用されています。
Assessment - The process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy.
評価 - エンドポイント機能のセットのために適切なバリデータは、コンプライアンスポリシーに対する姿勢を評価することができるように（例えば、ホストベースのファイアウォール）の姿勢を回収する工程。
Assertion Attributes - Attributes that include reusable information about the success of a prior assessment of the endpoint. This could be used to optimize subsequent assessments by avoiding a full posture reassessment. For example, this classification of attribute might be issued specifically to a particular endpoint, dated and signed by the NEA Server allowing that endpoint to reuse it for a time period to assert compliance to a set of policies. The NEA Server might accept this in lieu of obtaining posture information.
アサーション属性 - エンドポイントの事前評価の成功について、再利用可能な情報が含まれる属性。これは完全なポスチャ再評価を回避することにより、その後の評価を最適化するために使用することができます。たとえば、属性のこの分類は、NEA Serverは、そのエンドポイントがポリシーのセットに準拠を主張する期間のためにそれを再利用できるようにすることで、日付と署名し、特定のエンドポイントに特異的に発行される可能性があります。 NEA Serverは、姿勢情報を取得する代わりに、これを受け入れるかもしれません。
Attribute - Data element including any requisite meta-data describing an observed, expected, or the operational status of an endpoint feature (e.g., anti-virus software is currently in use). Attributes are exchanged as part of the NEA protocols (see section 5.2). NEA recognizes a variety of usage scenarios where the use of an attribute in a particular type of message could indicate:
属性 - 、観察された予想、またはエンドポイントの機能の動作状態を（例えば、アンチウイルスソフトウェアは、現在使用されている）を記述する任意の必要なメタデータを含むデータエレメント。属性はNEAプロトコルの一部として交換される（セクション5.2参照）。 NEAは、メッセージの特定のタイプの属性の使用は示すことができる使用シナリオの多様を認識します。
o previously assessed status (Assertion Attributes),
、以前に評価ステータス（アサーション属性）O
o observed configuration or property (Posture Attributes),
O（姿勢属性）構成または特性を観察し、
o request for configuration or property information (Request Attributes),
コンフィギュレーションまたはプロパティ情報の入出力要求（リクエスト属性）
o assessment decision (Result Attributes), or
O査定決定は、（結果は属性）、または
o repair instructions (Remediation Attributes).
O修復命令（修復属性）。
The NEA WG will standardize a subset of the attribute namespace known as standard attributes. Those attributes not standardized are referred to in this specification as vendor-specific.
NEA WGは、標準の属性として知られている属性の名前空間のサブセットを標準化します。標準化されていないこれらの属性は、ベンダー固有の、本明細書で言及されています。
Dialog - Sequence of request/response messages exchanged.
ダイアログ - 要求/応答メッセージの順序を入れ替えます。
Endpoint - Any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address.
エンドポイント - ネットワークに接続することができる任意のコンピューティングデバイス。そのような装置は、通常、ネットワーク上で一度ネットワークと潜在的にIPアドレスを接合する前に、特定のリンク層アドレスに関連付けられています。これには、ラップトップ、デスクトップ、サーバ、携帯電話、またはIPアドレスを有することができる任意のデバイスを。
Message - Self contained unit of communication between the NEA Client and Server. For example, a posture attribute message might carry a set of attributes describing the configuration of the anti-virus software on an endpoint.
メッセージ - NEAクライアントとサーバー間の通信の自己完結型ユニット。例えば、姿勢属性メッセージは、エンドポイント上のアンチウイルスソフトウェアの構成を説明する一連の属性を運ぶかもしれません。
Owner - the role of an entity who is the legal, rightful possessor of an asset (e.g., endpoint). The owner is entitled to maintain control over the policies enforced on the device even if the asset is not within the owner's possession. The owner may permit user override or augmentation of control policies or may choose to not assert any policies limiting use of asset.
所有者 - 資産（例えば、エンドポイント）の法的、正当な所有者である事業体の役割。所有者は、資産が所有者の所有物内にない場合でも、デバイスに適用ポリシーの制御を維持する権利を有します。所有者は、ユーザーの上書きや制御ポリシーの増強を可能にすることができるか、資産の使用を制限するいかなる政策を主張しないことを選択できます。
Posture - Configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy.
姿勢 - それは、組織のセキュリティポリシーに関係するようエンドポイントの設定および/またはハードウェアまたはソフトウェアの状態。
Posture Attributes - Attributes describing the configuration or status (posture) of a feature of the endpoint. For example, a Posture Attribute might describe the version of the operating system installed on the system.
姿勢属性 - 属性は、エンドポイントの機能の設定や状態（姿勢）を記述する。例えば、姿勢の属性は、システムにインストールされているオペレーティングシステムのバージョンを記述することがあります。
Request Attributes - Attributes sent by a NEA Server identifying the posture information requested from the NEA Client. For example, a Request Attribute might be an attribute included in a request message from the NEA Server that is asking for the version information for the operating system on the endpoint.
リクエスト属性 - NEAクライアントから要求された姿勢情報を識別NEA Serverによって送信された属性。例えば、要求属性は、エンドポイント上のオペレーティングシステムのバージョン情報を求めているNEA Serverからの要求メッセージに含まれる属性であるかもしれません。
Remediation Attributes - Attributes containing the remediation instructions for how to bring an endpoint into compliance with one or more policies. The NEA WG will not define standard remediation attributes, but this specification does describe where they are used within the reference model and protocols.
修復属性 - 1つまたは複数のポリシーに準拠さ終点を持参する方法について改善命令を含む属性。 NEA WGは、標準的な修復の属性を定義しませんが、それらは参照モデルとプロトコル内で使用されている場合、この仕様は説明しません。
Result Attributes - Attributes describing whether the endpoint is in compliance with NEA policy. The Result Attribute is created by the NEA Server normally at the conclusion of the assessment to indicate whether or not the endpoint was considered compliant. More than one of these attributes may be used allowing for more granular feature level decisions to be communicated in addition to an overall, global assessment decision.
結果は、属性 - 属性は、エンドポイントがNEAポリシーに準拠しているかどうかを記述する。 result属性は、エンドポイントが準拠したと考えられていたかどうかを示すために、評価の終了時に、通常はNEA Serverによって作成されます。これらの属性の複数のは、より詳細な機能レベルの決定は、全体的に、グローバルな査定決定に加えて通信することを可能に使用することができます。
Session - Stateful connection capable of carrying multiple message exchanges associated with (an) assessment(s) of a particular endpoint. This document defines the term session at a conceptual level and does not describe the properties of the session or specify requirements for the NEA protocols to manage these sessions.
セッション - 特定のエンドポイントの（AN）評価（複数可）に関連する複数のメッセージ交換を運ぶことができるステートフル接続。このドキュメントでは、概念レベルでの用語のセッションを定義し、セッションのプロパティを記述するか、これらのセッションを管理するために、NEAプロトコルの要件が指定されていません。
User - Role of a person that is making use of the services of an endpoint. The user may not own the endpoint so he or she might need to operate within the acceptable use constraints defined by the endpoint's owner. For example, an enterprise employee might be a user of a computer provided by the enterprise (owner) for business purposes.
ユーザー - エンドポイントのサービスを利用している人の役割。彼または彼女は、エンドポイントの所有者によって定義された許容使用の制約内で動作する必要がある場合がありますので、利用者は、エンドポイントを所有しない場合があります。例えば、企業の従業員は、ビジネス目的のために企業（所有者）によって提供されるコンピュータのユーザであるかもしれません。
This section discusses the scope of the technologies being standardized and the network environments where it is envisioned that the NEA technologies might be applicable.
このセクションでは、標準化された技術と、それをNEA技術が適用される可能性があることが想定されるネットワーク環境の範囲について説明します。
The priority of the NEA Working Group is to develop standard protocols at the higher layers in the reference model (see section 5): the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to be carried over a variety of lower layer transport (PT) protocols. The NEA WG will identify standard PT protocol(s) that are mandatory to implement. PT protocols may be defined in other WGs because the requirements may not be specific to NEA. When used with a standard PT protocol (e.g., Extensible Authentication Protocol (EAP), Transport Layer Security (TLS) [TLS]), the PA and PB protocols will allow interoperability between a NEA Client from one vendor and a NEA Server from another. This specification will not focus on the other interfaces between the functional components of the NEA reference model nor requirements on their internals. Any discussion of these aspects is included to provide context for understanding the model and resulting requirements.
姿勢属性プロトコル（PA）と姿勢ブローカプロトコル（PB）：NEAワーキンググループの優先順位は、参照モデルにおける上位層に標準的なプロトコル（セクション5を参照）を開発することです。 PA及びPBは、下層のトランスポート（PT）の様々なプロトコルを介して搬送されるように設計されます。 NEA WGは、実装するために必須である標準PTプロトコル（単数または複数）を同定します。要件がNEAに特異的ではないかもしれないので、PTプロトコルは、他のWGsで定義されてもよいです。標準PTプロトコル（例えば、拡張認証プロトコル（EAP）、トランスポート層セキュリティ（TLS）[TLS]）と共に使用した場合、PA及びPBプロトコルは、あるベンダーと他のNEAサーバからNEAクライアント間の相互運用性を可能にします。本明細書は、その内部にNEAの参照モデルも要件の機能コンポーネント間の他のインターフェイスに焦点を当てていないであろう。これらの局面のいずれかの議論は、モデルを理解し、要件を結果のためのコンテキストを提供するために含まれています。
Some tangent areas not shown in the reference model that are also out of scope for the NEA working group, and thus this specification, include:
NEAワーキンググループの範囲外でもある参照モデル、及び従って本明細書に示されていないいくつかの接線領域は、次のとおりです。
o Standardizing the protocols and mechanisms for enforcing restricted network access,
制限付きネットワークアクセスを実施するためのプロトコルやメカニズムを標準化、O、
o Developing standard protocols for remediation of non-compliant endpoints,
非準拠のエンドポイントの修復のための標準プロトコルを開発し、O、
o Specifying protocols used to communicate with remote portions of the NEA Client or Server (e.g., remote collectors or validators of posture),
NEAクライアントまたはサーバの遠隔部分（例えば、リモートコレクタ又は姿勢のバリデータ）と通信するために使用されるプロトコルを指定O、
o Supporting a NEA Client providing posture for other endpoints (e.g., a NEA Client on an Intrusion Detection System (IDS) providing posture for an endpoint without a NEA Client),
他のエンドポイント（例えば、侵入検知システム（IDS）にNEA ClientはNEAクライアントなしでエンドポイントの姿勢を提供する）ための姿勢を提供NEAクライアントをサポートO、
o Defining the set of events or situations that might trigger a NEA Client or NEA Server to request an assessment,
O査定を依頼するNEA ClientまたはNEAサーバをトリガーする可能性がある事象や状況のセットを定義し、
o Detecting or handling lying endpoints (see section 8.1.1 for more information).
横たわっているエンドポイントを検出するか、取り扱いO（詳細については、セクション8.1.1を参照してください）。
Because the NEA model is based on NEA-oriented software being present on the endpoint and in the network infrastructure, and due to the nature of the information being exposed, the use of NEA technologies may not apply in a variety of situations possible on the Internet. Therefore, this section discusses some of the scenarios where NEA is most likely to be applicable and some where it may not be. Ultimately, the use of NEA within a deployment is not restricted to just these scenarios. The decision of whether to use NEA technologies lies in the hands of the deployer (e.g., network provider) based upon the expected relationship they have with the owners and users of potential endpoints.
NEAモデルはNEA指向のソフトウェアは、エンドポイント上およびネットワークインフラストラクチャ内に存在するに基づいており、そしてによる暴露されている情報の性質のために、NEA技術の使用は、インターネット上で可能なさまざまな状況で適用されない場合がありますので、 。したがって、このセクションでは、NEAは、適用し、それができない場合があり、一部である可能性が最も高いシナリオのいくつかを説明します。最終的には、展開内のNEAの使用は、単にこれらのシナリオに限定されるものではありません。 NEA技術を使用するかどうかの決定は、潜在的なエンドポイントの所有者とユーザーと彼らが持っている期待される関係に基づいてデプロイヤ（例えば、ネットワークプロバイダ）の手にあります。
NEA technologies are largely focused on scenarios where the owner of the endpoint is the same as the owner of the network. This is a very common model for enterprises that provide equipment to employees to perform their duties. These employees are likely bound under an employment contract that outlines what level of visibility the employer expects to have into the employee's use of company assets and possibly activities during work hours. This contract may establish the expectation that the endpoint needs to conform to policies set forth by the enterprise.
NEA技術は、主にエンドポイントの所有者は、ネットワークの所有者と同じであるシナリオに焦点を当てています。これは、その職務を行うために従業員に機器を提供し、企業のための非常に一般的なモデルです。これらの従業員は、おそらく雇用者が勤務時間中に会社の資産と、おそらく活動の従業員の使用に持つと予想し、視認性のレベルを概説雇用契約の下で拘束されています。この契約は、エンドポイントは、企業が定めたポリシーに準拠する必要があると期待を確立することができます。
Some other environments may be in a similar situation and thus find NEA technologies to be beneficial. For example, environments where the endpoint is owned by a party (possibly even the user) that has explicitly expressed a desire to conform to the policies established by a network or service provider in exchange for being able to access its resources. An example of this might be an independent contractor with a personal laptop, working for a company imposing NEA assessment policies on its employees, who may wish a similar level of access and is willing to conform to the company's policies. NEA technologies may be applicable to this situation.
いくつかの他の環境は似たような状況にあるため、有益であることがNEA技術を見つけることができます。例えば、エンドポイントが明示的にそのリソースにアクセスできることと引き換えに、ネットワークやサービスプロバイダによって確立されたポリシーに準拠する意欲を表明した当事者（おそらくは利用者）が所有している環境。この例では、アクセスの同様のレベルを希望し、会社のポリシーに準拠する意思があることがその従業員、上NEA査定方針を課す会社のために働いて、個人的なノートPCと独立した契約であるかもしれません。 NEA技術は、このような状況にも適用することができます。
Conversely, some environments where NEA is not expected to be applicable would be environments where the endpoint is owned by a user that has not agreed to conform to a network provider's policies. An example might include when the above contractor visits any public area like the local coffee shop that offers Internet access. This coffee shop would not be expected to be able to use NEA technologies to assess the posture of the contractor's laptop. Because of the potentially invasive nature of NEA technology, such an assessment could amount to an invasion of privacy of the contractor.
逆に、NEAが適用可能であると予想されていない一部の環境では、エンドポイントがネットワークプロバイダのポリシーに準拠することに合意していないユーザーが所有している環境になります。上記の請負業者は、インターネットへのアクセスを提供しています地元のコーヒーショップのような任意のパブリックエリアを訪れたときの例では、含まれる場合があります。このコーヒーショップでは、請負業者のラップトップの姿勢を評価するためにNEA技術を使用することができると期待されません。そのためNEA技術の潜在的に侵襲的な性質のため、そのような評価は、契約者のプライバシーの侵害に達することができました。
It is more difficult to determine whether NEA is applicable in other environments, so the NEA WG will consider them to be out of scope for consideration and specification. In order for an environment to be considered applicable for NEA, the owner or user of an endpoint must have established a clear expectation that it will comply with the policies of the owner and operator of the network. Such an expectation likely includes a willingness to disclose appropriate information necessary for the network to perform compliance checks.
NEAが他の環境にも適用可能であるかどうかを判断することはより困難であるので、NEA WGは、それらを考慮し、仕様の範囲外であると考えます。 NEAは、該当する考慮すべき環境のためのためには、エンドポイントの所有者または使用者は、ネットワークの所有者とオペレータのポリシーに準拠することを明確に期待を確立している必要があります。そのような期待は、おそらくコンプライアンスチェックを実行するためのネットワークのために必要な適切な情報を開示する意欲を含みます。
NEA technology may be used for a variety of purposes. This section highlights some of the major situations where NEA technologies may be beneficial.
NEA技術は、様々な目的のために使用することができます。このセクションでは、NEA技術は有益であるかもしれない主要な状況のいくつかを強調しています。
One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT-specified Operating System (OS) configuration and have certain security applications enabled, e.g., anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network.
1つの用途は、エンドポイントがネットワークに接続したときに、組織のセキュリティポリシーに対するエンドポイントのコンプライアンスチェックを容易にすることです。組織は、多くの場合、IT-指定されたオペレーティングシステム（OS）の設定を実行するためにエンドポイントを必要とし、特定のセキュリティアプリケーションは、例えば、アンチウイルスソフトウェア、ホスト侵入検知/防止システム、パーソナルファイアウォール、およびパッチ管理ソフトウェアを有効にしています。 ITポリシーに準拠していないエンドポイントがネットワーク上に存在する可能性がある既知の脅威の数に脆弱である可能性があります。
Without NEA technology, ensuring compliance of endpoints to corporate policy is a time-consuming and difficult task. Not all endpoints are managed by a corporation's IT organization, e.g., lab assets and contractor machines. Even for assets that are managed, they may not receive updates in a timely fashion because they are not permanently attached to the corporate network, e.g., laptops. With NEA technology, the network is able to assess an endpoint as soon as it requests access to the network or at any time after joining the network. This provides the corporation an opportunity to check compliance of all NEA-capable endpoints in a timely fashion and facilitate endpoint remediation potentially while quarantined when needed.
NEA技術がなければ、企業ポリシーへのエンドポイントのコンプライアンスを確保することは、時間がかかり、困難な作業です。すべてのエンドポイントは、企業のIT組織、例えば、ラボの資産および請負業者のマシンによって管理されるわけではありません。彼らは永久に企業ネットワーク、例えば、ノート型パソコンに添付されていないためであっても管理されている資産について、彼らがタイムリーに更新を受信しないことがあります。 NEA技術により、ネットワークは、それがネットワークに参加した後、いつでもネットワークにまたはでのアクセスを要求するとすぐにエンドポイントを評価することができます。これは、企業にタイムリーにすべてのNEA対応エンドポイントのコンプライアンスを確認し、隔離されながら、必要なときに潜在的にエンドポイントの修復を促進する機会を提供します。
NEA technology can be used to provide posture assessment for a range of ways of connecting to the network including (but not limited to) wired and wireless LAN access such as using 802.1X [802.1X], remote access via IPsec [IPSEC], or Secure Socket Layer (SSL) VPN, or gateway access.
NEA技術は、有線（に限定されるものではない）を含むネットワークに接続する方法の範囲について姿勢評価を提供するために使用することができ、そのような802.1X [802.1X]、IPsecの[IPSEC]を介してリモートアクセスを使用するなど、無線LANアクセス、またはセキュア・ソケット・レイヤー（SSL）VPN、またはゲートウェイへのアクセス。
Endpoints that are not NEA-capable or choose not to share sufficient posture to evaluate compliance may be subject to different access policies. The decision of how to handle non-compliant or non-participating endpoints can be made by the network administrator possibly based on information from other security mechanisms on the network (e.g., authentication). For example, remediation instructions or warnings may be sent to a non-compliant endpoint with a properly authorized user while allowing limited access to the network. Also, network access technologies can use the NEA results to restrict or deny access to an endpoint, while allowing vulnerabilities to be addressed before an endpoint is exposed to attack. The communication and representation of NEA assessment results to network access technologies on the network is out of scope for this document.
NEAに対応していないか、コンプライアンスを評価するために、十分な姿勢を共有しないことを選択したエンドポイントは、異なるアクセスポリシーを受ける可能性があります。非準拠または非参加エンドポイントの処理方法の決定は、おそらくネットワーク（例えば、認証）上の他のセキュリティ・メカニズムからの情報に基づいて、ネットワーク管理者が行うことができます。ネットワークへのアクセス制限を可能にしながら、例えば、修正指示や警告が適切に許可されたユーザと非対応のエンドポイントに送信することができます。エンドポイントが攻撃にさらされる前に、可能な脆弱性に対処するようにしながら、また、ネットワークアクセス技術は、エンドポイントへのアクセスを制限または拒否するためにNEAの結果を使用することができます。ネットワーク上のアクセス技術をネットワークへNEA査定結果のコミュニケーションと表現はこの文書の範囲外です。
Reassessment is a second important use of NEA technology as it allows for additional assessments of previously considered compliant endpoints to be performed. This might become necessary because network compliance policies and/or endpoint posture can change over time. A system initially assessed as being compliant when it joined the network may no longer be in compliance after changes occur. For example, reassessment might be necessary if a user disables a security protection (e.g., host-based firewall) required by policy or when the firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require the patch.
再評価は、それが実行される以前に考えられ準拠したエンドポイントの追加の評価を可能とNEA技術の第二の重要な用途です。ネットワークコンプライアンスポリシーおよび/またはエンドポイントの姿勢が時間の経過とともに変化することができますので、これが必要になる場合があります。それは変更が発生した後、ネットワークがもはや適合しないかもしれない接合時に最初に準拠していると評価システム。ユーザーはセキュリティ保護（例えば、ホストベースのファイアウォール）ポリシーによって要求さを無効にした場合たとえば、再評価が必要になることがありますまたはファイアウォールのパッチが発行され、ネットワークポリシーは、パッチを必要とするように変更された後、ファイアウォールは非対応となったとき。
A third use of NEA technology may be to verify or supplement organization asset information stored in inventory databases.
NEAの技術の第3の使用が確認または、インベントリデータベースに保存された組織の資産情報を補完することであってもよいです。
NEA technology can also be used to check and report compliance for endpoints when they try to access certain mission critical applications within an enterprise, employing service (application) triggered assessment.
NEA技術はまた、彼らは、企業内の特定のミッションクリティカルなアプリケーションにアクセスしようとすると、エンドポイントのコンプライアンスを確認し、報告するために使用することができ、使用するサービス（アプリケーション）の評価を引き起こしました。
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 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).
このセクションでは、ネットワークのエンドポイント評価のための参照モデルを説明しています。このモデルは、要件の議論のためのコンテキストを確立するために提供され、直接、任意の特定の製品または配備アーキテクチャにマップされない場合があります。モデルは、NEAクライアントとサーバとの関係、ならびにそれらが（例えば、PAはPBプロトコルによって運ばれる）様々なレベルでの通信に使用するプロトコルの主要な機能を特定します。
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.
図3層状プロトコルを示しているが、PAは、属性のセットの周りに薄いメッセージラッパーがそうであることが想定され、それはバッチ及びPB中に封入されていること。 PBは、主軽量メッセージバッチプロトコルであるので、プロトコルスタックは、主に輸送（PT）です。モデル内の縦線は、NEAクライアントまたはサーバー内のコンポーネント間のAPIおよび/またはプロトコルを表します。これらのインタフェースは、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
NEW KLIENT新しいサーバ
Figure 1: NEA Reference Model
図1：NEA参照モデル
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.
NEA参照モデルは、NEAクライアントとNEA Serverの発見のためのメカニズムが含まれていません。 NEAクライアントとNEA Serverが、それらが相互に到達することを可能にする情報で構成されていることを期待されています。コンフィギュレーションを参照すると、通信チャネルを確立する具体的な方法は、NEA参照モデルの範囲外であり、このような姿勢トランス（PT）プロトコルなどの候補プロトコルの仕様でカバーされるべきです。
The NEA Client is resident on an endpoint device and comprised of the following functionality:
NEA Clientは、エンドポイントデバイスに常駐し、次の機能で構成されています。
o Posture Collector(s)
O姿勢コレクタ（複数可）
o Posture Broker Client
O姿勢ブローカークライアント
o Posture Transport Client(s)
O姿勢交通クライアント（複数可）
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.
NEA Clientは、クライアントのローカル・オペレーティング・ドメインの構成を説明する属性の要求に応答し、ポリシーに準拠する方法のための潜在的な改善命令を含む評価結果を処理する責任があります。 NEA ClientはNEAクライアントの（他の仮想マシンのドメインで、例えば）エンドポイント上または実行のドメインの外にあるネットワーク上に存在する可能性があるエンティティの姿勢に報告するための責任を負いません。
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.
その背後にある多くのシステムについては、例えば、ネットワークアドレス変換（NAT）デバイスかもしれないルートの通信が、NATデバイスがネットワークに参加したとき、そのNEAクライアントは、自身の（ローカル）姿勢を報告します。同様に、仮想化機能を持つエンドポイントは、実行の複数の独立したドメイン（例えば、OSインスタンス）を有するかもしれません。各NEA Clientは、実行のそのドメインのための姿勢を報告するための唯一の責任があるが、この情報は、エンドポイント上の複数のドメインのための姿勢を表現するために、他の地元のメカニズムによって集約される可能性があります。そのような姿勢凝集メカニズムは、本明細書の焦点外にあります。
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.
エンドポイント（NEAの範囲外である）NEA Clientソフトウェアを欠いているか、NEA Serverで必要な属性を提供しないことを選択は非対応と考えることができます。 NEAモデルは適合になるために、その内容を更新するために、エンドポイントを有効にする機能が含まれています。
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 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.
姿勢コレクターはNEA Serverからのリクエスト属性での姿勢情報のための要求に応答する責任があります。姿勢コレクターも結果属性および修復属性に改善命令に査定決定を処理する責任があります。単一NEAクライアントは、標準および/またはベンダー固有の姿勢のエンドポイントの特定の特徴の属性を収集することが可能ないくつかの姿勢コレクタを有することができます。代表的な例としては、ホストベースの侵入検知システム（IDS）やファイアウォールなどのエンドポイント上のオペレーティングシステム（OS）のバージョンとパッチレベル、アンチウイルスソフトウェア、セキュリティメカニズムに関する情報を提供する姿勢コレクターを含みます。
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).
各姿勢コレクタはPAメッセージの宛先として指定することを可能にする1つの以上の識別子に関連付けられます。姿勢ブローカーClientは、このコレクターにメッセージをルーティングするためにこれらの識別子を使用しています。識別子は、動的であるかもしれない（例えば、登録時に実行時に姿勢ブローカクライアントによって生成される）以上の静的（例えば、インストール時に姿勢Collectorに事前に割り当てられ、登録時に姿勢ブローカークライアントに渡されます）か、コレクターが受信しようとする属性のメッセージ（サブスクリプションなど、メッセージタイプ）の機能。
The NEA model allocates the following responsibilities to the Posture Collector:
NEAモデルは、姿勢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与えられたNEAサーバに開示することを許可される情報を制限することができる地元のプライバシーとセキュリティポリシーにコンサルティング。
o Receiving Request Attributes from a Posture Validator and performing the local processing required to respond appropriately. This may include:
ポスチャ検証の要求属性を受信し、適切に対応するために必要なローカル処理を行うO。これが含まれます。
- 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エンドポイントで機能を更新する方法について改善命令を含む属性を受け取ります。これは、ユーザー、所有者、および/または修復サーバーと対話するコレクタを必要とする可能性があります。
o Monitoring the posture of (a) particular features(s) on the endpoint for posture changes that require notification to the Posture Broker Client.
O姿勢ブローカクライアントに通知を必要とする姿勢変更用エンドポイントで（a）の特定の特徴（複数可）の姿勢を監視します。
o Providing cryptographic verification of the attributes received from the Validator and offering cryptographic protection to the attributes returned.
バリから受信した属性の暗号化検証を提供し、返された属性に暗号保護を提供し、O。
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.
上記のリストは、姿勢コレクターの可能性責任のモデルのビューを説明します。これは、各姿勢コレクタ実装がサポートしなければならない何のための要件の集合ではなく、またそれは姿勢コレクターが行う可能性のあるすべてのものの完全なリストであることに注意してください。
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.
姿勢ブローカーClientはPAメッセージマルチプレクサとデマルチプレクサの両方です。姿勢ブローカクライアントはPBメッセージがNEAサーバから受信した逆多重化し、対応する姿勢コレクタ（複数可）にそれぞれカプセル化されたPAメッセージを配信する責任があります。モデルは、NEA ClientはNEA Serverから特定の属性に対する要求を受信することなく、姿勢を報告できるようにすることで、パフォーマンスを向上させるために、NEAクライアント上で事前にプロビジョニングする姿勢情報要求することができます。
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.
姿勢ブローカークライアントも姿勢コレクタ（複数可）からの応答を多重化し、NEA Serverに返します。姿勢ブローカークライアントは、それが評価に関わる姿勢コレクタ（複数可）から取得したPAメッセージ（複数可）を使用して1つまたは複数のPBメッセージを作成します。姿勢コレクタ応答（PAメッセージ（単数または複数））の量及び順序PB応答メッセージ（単数または複数）に多重化は、基礎となるネットワーク・トランスポート（例えば、MTU）のポリシーまたは特性を含む多くの要因に基づいて姿勢ブローカクライアントによって決定することができます。特定のNEA Clientは1姿勢ブローカーのクライアントを持つことになります。
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:
NEAモデルは、姿勢ブローカークライアントに次の責任を割り当てます。
o Maintaining a registry of known Posture Collectors and allowing for Posture Collectors to dynamically register and deregister.
知ら姿勢コレクターのレジストリを維持し、姿勢のコレクターが動的に登録し、登録解除するためにできるように、O。
o Multiplexing and de-multiplexing attribute messages between the NEA Server and the relevant Posture Collectors.
Oの多重化と逆多重化は、NEA Serverおよび関連する姿勢コレクターの間でメッセージを属性。
o Handling posture change notifications from Posture Collectors and triggering reassessment.
O姿勢コレクターからの姿勢の変更通知を処理し、再評価をトリガーします。
o Providing user notification about the global assessment decision and other user messages sent by the NEA Server.
NEA Serverによって送信されたグローバルな査定決定や他のユーザーのメッセージについてユーザへの通知を提供し、O。
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.
姿勢交通ClientはNEA ClientとNEA Serverの間のメッセージダイアログのNEA Serverと信頼性の高い通信チャネルを確立する責任があります。異なるトランスポートプロトコル（例えば、802.1X、VPN）をサポートする特定のNEAクライアント上で複数の姿勢交通クライアントがあるかもしれません。一定の姿勢トランスポートクライアントは、特定のネットワークに使用するために、適切な姿勢トランスポートサーバーのアドレスを使用して設定することができます。
The NEA model allocates the following responsibilities to the Posture Transport Client:
NEAモデルは、姿勢交通クライアントに次の責任を割り当てます。
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.
NEAサーバへの通信チャネルを開始し、維持し、O。姿勢交通Clientは、レイヤ2またはレイヤ3プロトコル可能性が根底にあるキャリアの詳細を隠します。
o Providing cryptographic protection for the message dialog between the NEA Client and NEA Server.
NEA ClientとNEA Serverの間のメッセージダイアログのための暗号保護を提供し、O。
The NEA Server is typically comprised of the following NEA functionality:
NEA Serverは、通常、次のNEAの機能で構成されています。
o Posture Validator(s)
ポスチャ検証（S）O
o Posture Broker Server
O姿勢ブローカーサーバー
o Posture Transport Server(s)
O姿勢トランスポートサーバー（複数可）
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.
姿勢バリデータは、ローカルとリモートの両方の姿勢バリデータに対処する姿勢ブローカーサーバーを必要とし、姿勢ブローカーサーバーから別のサーバーに配置されることがあります。
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.
姿勢Validatorは姿勢が姿勢コレクタ（複数可）を対応の属性処理する責任があります。姿勢Validatorは姿勢が一つ以上の姿勢コレクターとその逆の属性扱うことができます。ポスチャ検証は、エンドポイント（例えば、アンチウィルスソフトウェア）の一つ以上の特徴のために姿勢評価を行い、結果を作成し、必要に応じて、修正指示を、又は1つ又はそれ以上のコレクタからの追加属性を要求することを選択することができます。
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).
各姿勢ValidatorはPAメッセージの宛先として指定することを可能にする1つの以上の識別子に関連付けられます。姿勢ブローカーサーバーは、この検証にメッセージをルーティングするために、この識別子を使用しています。この識別子は、動的であるかもしれない（例えば、登録時に実行時に姿勢ブローカーサーバーによって生成される）以上の静的（例えば、登録時に姿勢ブローカーサーバーへのインストール時の姿勢バリに事前に割り当てられ、合格）またはValidatorは受信しようとする属性のメッセージ（サブスクリプションなど、メッセージタイプ）の機能。
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.
姿勢バリデータはNEA Server上の同じ場所に配置することができ、または別のサーバーでホストすることができます。特定のNEA Serverは、複数の姿勢バリデータを処理する必要がありそうです。
The NEA model allocates the following responsibilities to the Posture Validator:
NEAモデルは、姿勢バリに次の責任を割り当てます。
o Requesting attributes from a Posture Collector. The request may include:
O姿勢コレクターから属性を要求します。要求が含まれます。
- Request Attributes that indicate to the Posture Collector to fetch and provide Posture Attributes for particular functionality on the endpoint.
- フェッチと姿勢は、エンドポイント上の特定の機能のための属性を提供するためのPosture Collectorに示すリクエスト属性。
o Receiving attributes from the Posture Collector. The response from the Posture Collector may include:
姿勢コレクターから属性を受け、O。姿勢コレクターからの応答が含まれます：
- 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。
o Communicating the posture assessment result to the Posture Broker Server.
姿勢ブローカーサーバーへのポスチャアセスメント結果を伝えるO。
o Communicating the posture assessment results to the Posture Collector; this attribute message may include:
姿勢Collectorにポスチャ評価結果を伝えるO;この属性のメッセージが含まれることがあります。
- Result Attributes that communicate the posture assessment result. - Remediation Attributes that communicate the remediation instructions to the Posture Collector.
- ポスチャ評価結果を伝える結果属性。 - 姿勢Collectorに改善命令を伝える修復の属性。
o Monitoring out-of-band updates that trigger reassessment and require notifications to be sent to the Posture Broker Server.
O再評価をトリガし、姿勢ブローカーサーバーに送信する通知を必要とアウトオブバンドの更新を監視します。
o Providing cryptographic protection for attributes sent to the Posture Collector and offering cryptographic verification of the attributes received from the Posture Collector.
姿勢コレクターに送信された属性の暗号保護を提供し、姿勢コレクターから受信した属性の暗号化検証を提供し、O。
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.
上記のリストは、姿勢バリの可能性責任のモデルのビューを説明します。これは、各姿勢バリデータの実装がサポートしなければならない何のための要件の集合ではなく、またそれは姿勢Validatorが行うことができますすべてのものを網羅したリストであることに注意してください。
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).
姿勢ブローカーサーバーは、属性のメッセージのためのマルチプレクサとデマルチプレクサとして機能します。姿勢ブローカーサーバーはPBメッセージは、それが関連付けられている姿勢のバリデータに渡すPAメッセージにNEA Clientと逆多重化彼らから受け取っ解析します。姿勢ブローカーサーバーは、一つ以上のPBメッセージにPAメッセージ（関連する姿勢検証（S）から（a）の要求属性（複数可）を含む、例えば、メッセージ）を多重化し、姿勢トランスポートプロトコルを介してNEAクライアントに送信します。数量と発注姿勢Validatorの応答（PAメッセージ）の、PBの応答メッセージ（複数可）に多重グローバル査定決定は、基盤となるネットワークトランスポート（例えば、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.
姿勢ブローカーサーバーはまた、様々な姿勢バリデータから個々のポスチャ評価結果に基づいて、グローバルな査定決定を計算するための責任があります。このグローバル査定決定は、PBメッセージ内の結果属性に戻っNEAクライアントに送信されます。特定のNEA Serverは、1姿勢ブローカーサーバーを持つことになり、この姿勢ブローカーサーバーは、すべてのローカルおよびリモートの姿勢バリデータを処理します。
The NEA model allocates the following responsibilities to the Posture Broker Server:
NEAモデルは姿勢ブローカーサーバーに次の責任を割り当てます。
o Maintaining a registry of Posture Validators and allowing for Posture Validators to register and deregister.
姿勢バリのレジストリを維持し、姿勢バリデータを登録し、登録解除することを可能にし、O。
o Multiplexing and de-multiplexing posture messages from and to the relevant Posture Validators.
Oの多重化とから、関連する姿勢バリデータに逆多重姿勢のメッセージ。
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.
O様々な姿勢バリデータおよびコンプライアンスポリシーからポスチャ評価結果に基づいて、グローバルな査定決定を計算します。この評価の決定はPBメッセージに姿勢ブローカクライアントに送信されます。
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.
姿勢トランスポートサーバーは、NEA ClientとNEA Serverの間のメッセージダイアログのNEAクライアントとの信頼性の高い通信チャネルを確立する責任があります。異なるトランスポート・プロトコルをサポートするために、特定のNEAサーバ上に複数の姿勢トランスポートサーバーがあるかもしれません。特定の姿勢トランスポートサーバーは、典型的には、いくつかの姿勢交通クライアントからの要求を処理し、NEAクライアントに到達する方法を記述したローカル設定が必要な場合があります。
The NEA model allocates the following responsibilities to the Posture Transport Server:
NEAモデルは、姿勢トランスポートサーバーに次の責任を割り当てます。
o Initiating and maintaining a communication channel with, potentially, several NEA Clients.
開始および潜在的に、いくつかのNEAクライアントとの通信チャネルを維持O。
o Providing cryptographic protection for the message dialog between the NEA Client and NEA Server.
NEA ClientとNEA Serverの間のメッセージダイアログのための暗号保護を提供し、O。
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).
NEA参照モデルは、ネットワークを介して属性の交換を可能にする三層プロトコル（PA、PB、およびPT）を含みます。これらのプロトコルは、モデル内の特定の役割を果たすために一緒に使用されることが意図されているが、それらは重複した機能を提供することがあります。例えば、各プロトコルは、攻撃（詳細はセクション8.2を参照）から、その情報を保護することができなければなりません。
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.
PAは、姿勢コレクターとそれらに関連するポスチャ検証の間に1つ以上の属性を運ぶプロトコルです。 PAプロトコルが交換されている属性のセットの周りにメッセージ指向の軽量ラッパーです。このラッパーは、メッセージ内の属性の目的を示すことがあります。予想されるメッセージの種類のいくつかは、次のとおり姿勢情報の要求（リクエスト属性）、エンドポイントについての姿勢情報（姿勢属性）、評価の結果（属性の結果）、再利用可能なコンプライアンス・アサーション（アサーション属性）、および非修正の指示をエンドポイントの準拠部分（修復属性）。 PAプロトコルはまた、必要なエンコーディングや姿勢属性の暗号化保護を提供します。
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).
PBは、NEAクライアント上の姿勢コレクター間の集約属性のメッセージを運び、特定の評価に関わるNEAサーバー上の対応する姿勢バリプロトコルです。 PBプロトコルは、すべての評価のためのメッセージダイアログを可能にセッションを提供します。このPBセッションは、特定の評価に関わるさまざまな姿勢コレクターや姿勢バリデータから複数の姿勢属性要求と応答を結合するために使用されます。 PBプロトコルはまた、姿勢ブローカクライアントへの姿勢ブローカーサーバーから結果属性における世界的な査定の裁判を運ぶことができます。 PBは、姿勢ブローカクライアントによる使用およびサーバのメッセージの追加のタイプを運ぶために使用されてもよい（例えば、言語などのユーザの好ましいインターフェイスの設定に関する情報）。
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.
PTはPBプロトコルによって生成されたメッセージを運ぶための責任NEA ClientとNEA Serverの間のトランスポートプロトコルです。ネットワーク接続要求時、またはネットワーク接続が確立された後にPTプロトコル（S）トランスポート（S）PBメッセージ。
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:
展開は、量を制限することを選択することができる及び/又は属性のサイズが交換ので、初期評価は、ネットワーク接続時に発生する必要があるシナリオでは、PTプロトコル（例えば、802.1X内EAP）は、ネットワークの使用を制約していることができます。 NEA ClientとNEA Serverは、潜在的に制約状況は基本的なネットワークプロトコルの特性に基づいて評価する前に存在した場合に検出することができるはずです。この情報を使用して、NEAの方針は、初期評価に含めると潜在的にPAメッセージが交換属性を制限するために、エンドポイントのどのような側面を指示することができます。エンドポイントがネットワーク上に配置された後、これは、完全な再評価によって追跡することができます。また、展開は一時的に事前評価に制限IP接続を許可し、評価中に拘束されていない、高帯域幅のIPベースのトランスポートを使用するようにネットワークアクセス技術を構成することによって、彼らの査定を制限しないことを選択することができます。ネットワーク接続フェーズに関係するプロトコルのために存在する可能性制約の一部を以下に示します。
o Limited maximum transmission unit (MTU) size and ability to negotiate larger MTUs,
O限定最大伝送単位（MTU）サイズと大きいのMTUを交渉する能力
o Inability to perform multiple roundtrips,
多重周回を実行するためのO無力、
o Lack of support for piggybacking attributes for other protocols, o Low bandwidth or high latency limitations precluding exchanges of large amounts of data,
O低帯域幅または大量のデータのやり取りを排除高遅延の制限O他のプロトコルの属性を、ピギーバックのサポートの欠如、
o Inability of servers to initiate messages except during the network connection phase.
Oサーバのできないことは、ネットワーク接続フェーズの間を除いて、メッセージを開始します。
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.
PTプロトコル選択プロセスは、特定のPTを選択し、PAとPBの展開ニーズに基本的なプロトコルのセットの影響を考慮する必要があります。 PAとPBのニーズが知られているであろうように、PAとPBは前PTに選択されます。特定の基礎となるプロトコル・スタックは、ネットワーク接続時に十分なNEA評価をサポートするにはあまりにも制約されてもよいです。
The PT protocol provides reliable message delivery, mutual authentication, and cryptographic protection for the PB messages as specified by local policy.
PTプロトコルはローカルポリシーによって指定されるようにPBメッセージの信頼性の高いメッセージ配信、相互認証、および暗号化保護を提供します。
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.
PAプロトコルは、姿勢コレクターとのPosture Validatorの間の属性の交換のための責任があります。 PBプロトコルはまた、グローバルな査定決定が姿勢ブローカーサーバーから属性を運ぶことができます。属性は、効果的にポスチャ評価の予約語「名詞」であり。 NEA Serverは、このようにして得られたことができる姿勢のどのような種類の境界、対応する属性を持っている情報を求めることが可能です。 NEA WGは、姿勢コレクターに広く適用可能であることが予想され、従って、最大の相互運用性のために使用される属性の一般的な（標準）のセットを定義するが、必要なときに姿勢コレクターは、追加のベンダー固有の属性をサポートすることができます。
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.
展開シナリオに応じて、交換した属性の目的は、（例えば、姿勢情報の対は、コンプライアンスをアサート）異なる場合があります。このセクションでは、PAメッセージ内の属性の各分類の使用が生じ発信元と予想される状況について説明します。これらの分類は、属性の名前空間やスキーマを定義するときNEA WGは、属性を指定する方法を指示することを意図していません。
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.
Oアサーション属性 - 姿勢を思い出すとNEAサーバーに送信する必要性を回避することを望んで政策への最近の前に、コンプライアンスを述べ属性。アサーションの例としては、NEA Serverは前評価を記述する属性（状態）に設けられた（A）を含む状態を検索するNEAサーバによって使用されるか、または（b）のNEAクライアントの識別情報（例えば、エンドポイントに不透明で、タイムスタンプ特定の結果を記述項目を締結）事前の意思決定（例えば、システム結合クッキー）。これらは、の代わりに返される可能性がある、またはそれに加えて、姿勢の属性。
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結果属性 - 姿勢バリデータおよび/または姿勢ブローカーサーバーの決定を含む属性。提供される詳細のレベルは、個々の属性に準拠かだけでなく、グローバルな査定の裁判を通じてそのうち異なる場合があります。
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修復属性 - NEA Serverのポリシーに準拠するようになり、エンドポイントを更新する方法NEAクライアントとそのユーザーに説明属性。グローバルな査定決定は、エンドポイントが現在準拠していないということであったとき、これらの属性は、送信されます。修復と属性の結果は、両方のNEA Serverの属性メッセージ内に存在し得ます。
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.
Oアサーション属性 - NEAクライアントによる将来の使用のための政策への準拠のNEA Serverのアサーションを含む属性。詳細については、セクション5.3.1を参照してください。
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.
このセクションでは、説明する目的でNEAの使用例のいくつかを説明し、一括して検討中のNEAの問題空間を結合しました。ユースケースは、定義された要件のコンテキストおよび一般的な理論的根拠を提供しています。各ユースケースとどのように参照モデルにマップの理解を容易にするために、各ユースケースは、単純な例この例は、NEAプロトコルに関する方法の議論を伴うであろう。提供された例は、ユースケースに対処する唯一のアプローチを示すことを意図していないではなく、流れが発生し、NEAプロトコルに影響を与えるかもしれない方法の理解を容易にするために含まれていることを強調すべきです。
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初期評価 - 最近評価されていないので、それに準拠考慮されるべきであることを任意の有効な証拠を所持していないしているエンドポイントの姿勢を評価します。この評価は、ネットワーク、サービスを利用するための要求、またはシステムの姿勢を理解したいという願望に参加するための要求によってトリガーされる可能性があります。
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.
O再評価 - 以前に評価されているエンドポイントの姿勢を評価します。この評価は、エンドポイントのリスクレベルを上げる可能性があるエンドポイントに影響を与える発生を認識しNEAクライアントまたはサーバを含む、さまざまな理由で発生する可能性があります。これは、エンドポイントの前に再評価以来の久しぶりたほど単純である可能性があります。
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.
NEAクライアントやサーバーイベントは初めてのエンドポイントの姿勢の評価を引き起こすことが発生したときに最初の評価が発生します。彼らは最近評価されているとNEAのクライアントまたはサーバーがその姿勢が再び評価されている必要はありませんので、エンドポイントが準拠している状態（または証明）を維持した場合、エンドポイントは、ユースケースのこのカテゴリーの対象となりません。
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.
このユースケースは、エンドポイントが姿勢評価を必要とするサービスのネットワークや要求の使用に参加しようとする時に行われる評価に焦点を当てています。それはNEA Serverはそれをネットワークやサービスへのアクセスを許可する前に、エンドポイントの姿勢を評価することを可能にするため、このユースケースは、特に興味深いものです。
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.
エンドポイントアクションの種類の様々な評価のこのクラスにつながる可能性があります。例えば、評価が高まり、セキュリティチェックが必要とされ、高度に保護されたネットワークサービス（例えば、財務や人事アプリケーションサーバー）にアクセスしようとしているエンドポイントによってトリガすることができます。良く知られた例は、コンプライアンスポリシーを満たすためにシステムを必要とするネットワークへの入り口を要求して含めることができます。この例では、次のセクションで詳しく説明されています。
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.
休暇から戻ってきたITの従業員は、有線企業ネットワークへの参加要求を生成し、彼のオフィスのデスクトップコンピュータを起動します。ネットワークのセキュリティポリシーは、デスクトップのセキュリティ機能が有効になっているかどうかを判断するために、そして最新の姿勢情報を提供するシステムが必要です。デスクトップはそのパッチ、ファイアウォール、アンチウイルスの姿勢情報を送信します。 NEA Serverは、システムが深刻な脆弱性を修正するために設計された最新のセキュリティパッチを欠いていると判断し、システムが制限されたアクセスネットワーク上に置かれています。デスクトップは、必要なパッチをダウンロードし、インストールして修復指示に従います。その後、デスクトップ要求が再びネットワークに参加すると、この時間は、完全な評価をした後、企業ネットワークへのフルアクセスを提供しています。
The following describes typical message flows through the NEA reference model for this example use case:
以下は、一般的なメッセージは、この使用事例のためにNEA参照モデル流れる説明します：
1. The IT employee's desktop computer connects to the network through an access gateway in the wired enterprise network.
1. IT従業員のデスクトップコンピュータは、有線企業ネットワーク内のアクセスゲートウェイを介してネットワークに接続します。
2. The Posture Broker Server on the NEA Server is instructed to assess the endpoint joining the wired network.
2. NEA Server上のPosture Brokerのサーバは、有線ネットワークに参加するエンドポイントを評価するように指示されます。
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.
3.コンプライアンスポリシーに基づいて、姿勢ブローカーサーバーの連絡先オペレーティングシステムのパッチ、ホストベースのファイアウォール、およびアンチウイルス姿勢バリデータは、必要な姿勢を要求します。各姿勢Validatorはデスクトップシステムからの評価のために要求されるべき所望の属性を含むPAメッセージを作成します。
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.
4.姿勢ブローカーサーバーはPBメッセージに姿勢バリデータからPAメッセージを集約します。姿勢ブローカーサーバーは、デスクトップコンピュータ上のNEA ClientにPBメッセージを送信するためにPTプロトコルを使用姿勢トランスポートサーバーにPBメッセージを渡します。
5. The Posture Transport Client receives the message from the NEA Server and passes it to the Posture Broker Client for message delivery.
5.姿勢交通ClientはNEAサーバーからメッセージを受信し、メッセージ配信のための姿勢ブローカクライアントに渡します。
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.
6.姿勢ブローカークライアントのデマルチプレクスPBメッセージやファイアウォール、オペレーティングシステムのパッチ、およびアンチウイルス姿勢コレクターへの属性の要求にPAのメッセージを配信します。
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.
各姿勢コレクタが関与7.開示することを許可する情報を決定するためにローカルのプライバシーポリシーを参照して、姿勢ブローカークライアントにPAメッセージに認可されている要求された属性を返します。
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.
8.姿勢ブローカークライアントは、単一のPBメッセージにこれらのPAメッセージを集約し、サーバーセッションに姿勢交通クライアントを使用して姿勢ブローカーサーバーに送信します。
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.
9.姿勢トランスポートサーバーは、逆多重化姿勢ブローカーサーバーメッセージにPBメッセージを提供し、対応する姿勢検証に適切な属性を送信します。
10. Each Posture Validator compares the values of the attributes it receives with the expected values defined in its policy.
10.各姿勢Validatorは、そのポリシーに定義されて期待値と受信した属性の値を比較します。
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.
11.アンチウイルスやファイアウォール姿勢バリのリターンは、デスクトップコンピュータを述べる姿勢ブローカーサーバーに属性を準拠していますが、オペレーティングシステムのパッチ姿勢Validatorは非対応返します。オペレーティング・システム・パッチのPosture Validatorは非準拠の結果を示す属性に加えて、改善命令と属性が含まれているPAメッセージを作成します。
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.
12.姿勢ブローカーサーバーはPAメッセージを集約し、姿勢トランスポートサーバーと姿勢交通クライアントを経由して姿勢ブローカーClientにPBメッセージで送信します。
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.
13.姿勢ブローカクライアントは、オペレーティングシステムのパッチ姿勢コレクタに修復指示属性を含むPAメッセージを含む姿勢コレクターに様々な姿勢バリデータの結果とPAメッセージを配信します。この姿勢コレクターは、エンドポイントが隔離されたまま潜在ながら、必要なパッチをダウンロードしてインストールするようにユーザーと対話します。
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).
修復が完了すると14は、1〜10が繰り返される、上記の手順（NEAクライアントによってトリガは、ネットワークに参加するために、その要求を繰り返します）。
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.
15.この時間（オペレーティング・システムのパッチポスチャ検証を含む）各関与姿勢Validatorは準拠ステータスを返し、姿勢ブローカサーバは、グローバル成功を示す準拠結果を返します。
16. The Posture Broker Client receives the compliant result and the IT employee's desktop is now on the network.
16.姿勢ブローカークライアントは、準拠した結果を受けて、ITの従業員のデスクトップは、ネットワーク上で今です。
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エンドポイントの前にポスチャ評価は、ネットワーク上で許可します
o Endpoint sends attributes containing posture information
Oエンドポイントは、姿勢情報を含む属性を送信します
o NEA Server sends remediation instructions
O NEA Serverは、修復指示を送ります
o NEA Client causes a reassessment after remediation
O NEA Clientは修復後に再評価を引き起こし
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.
このユースケースは、（おそらく、ユーザの要求に応じて）エンドポイントのセキュリティ保護メカニズムが実行され、最新の状態にしているかどうかを判断するためにその姿勢の評価をトリガすることを望むかもしれないことを強調しています。
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 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.
学生は、プロジェクト上で動作するように、端末の部屋に行きます。端末室は、ネットワーク上にある学校が所有する共有システムが含まれています。彼らのセキュリティ状況が不明であるので、これらのシステムは、以前に他の学生によって使用されています。学生は、システムが仕事をして前に学校のセキュリティポリシーに準拠し、現在あるかどうかを確認したいので、彼女は、ポスチャ評価を要求します。 NEA Serverは、システムの初期評価を行い、それが準拠しているが、アンチウイルス保護を使用していないと判断します。学生は、システムのアンチウイルスソフトウェアを示す諮問応答がオフになっている受信するが、それはそれ以外の場合は、学校の方針に準拠しています。学生は、アンチウイルスソフトウェアをオンにスキャンを開始し、完了時に彼女の作品を使用してシステムを信頼することにしました。
The following describes the message flows through the NEA reference model for the student using a terminal room shared system example:
以下は、メッセージが端末部屋共有システム例を使用して学生のためNEA参照モデル流れる説明します：
1. Student triggers the Posture Broker Client on the computer system in the terminal room to initiate a posture assessment.
1.学生は、ポスチャ評価を開始する、端末部屋にコンピュータシステム上のPosture Brokerのクライアントをトリガします。
2. The Posture Broker Client establishes a session with the Posture Broker Server that causes an assessment to be triggered.
2.姿勢ブローカークライアントは、評価がトリガされるようにする姿勢ブローカーサーバーとのセッションを確立します。
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.
3.姿勢ブローカーサーバーは、新しいセッションを検出し、姿勢バリデータが評価に関与していることを決定するためのポリシーを調べます。姿勢ブローカーサーバーは、アンチウイルスのPosture検証を含むいくつかの姿勢バリデータを採用することを決定します。
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.
4.関与姿勢バリデータは、学校のセキュリティポリシーに基づいて、所望の端末部屋のコンピュータに関する情報を含む特定の属性に対する要求を含むPAメッセージを作成します。
5. The Posture Broker Server assembles a PB message including each of the PA messages from the Posture Validators.
5.姿勢ブローカーサーバーは、姿勢バリデータからPAメッセージのそれぞれを含むPBメッセージを組み立てます。
6. The Posture Transport Server sends the PB message to the Posture Transport Client where it is passed on to the Posture Broker Client.
6.姿勢トランスポートサーバーは、それが姿勢ブローカークライアントに渡される姿勢交通ClientにPBメッセージを送信します。
7. The Posture Broker Client on the student's computer de-multiplexes the PA messages and delivers them to the corresponding Posture Collectors.
7.学生のコンピュータのデマルチプレクスPAメッセージの姿勢ブローカークライアントとは、対応する姿勢コレクターに配信します。
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.
8.姿勢コレクターは、サーバーと共有する情報を決定するために、プライバシーポリシーを参照してください。許容した場合、コレクターは、それぞれのPosture Brokerのクライアントに要求された姿勢を含むPAメッセージを返します。
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.
9.姿勢ブローカークライアントはPBメッセージに返されたPAメッセージを集約し、姿勢トランスポートサーバーに送信するための姿勢交通クライアントにそれを渡します。
10. The Posture Broker Server separates and distributes the Posture Collector PA messages to the associated Posture Validators.
10.姿勢ブローカサーバは分離し、関連付けられたポスチャバリへ姿勢コレクタPAメッセージを配信します。
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.
11.姿勢バリデータは、姿勢を含む属性はPAメッセージに含まれるかどうかを判断する彼らのポリシーに適合していると姿勢ブローカーサーバーへの姿勢査定決定を返します。この場合、アンチウイルスのPosture Validatorは、ウイルス対策ソフトウェアが実行されていないため、非準拠結果を示すPAメッセージを返し、ソフトウェアを有効にする方法を記述した属性が含まれています。
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).
12.姿勢ブローカーサーバーは、バリ評価結果のすべてに基づいて、全体的なコンプライアンスの決定を決定し、グローバルな査定決定とアンチウイルスValidatorのPAメッセージを表現する属性を含むPBメッセージを送信します。この場合は、グローバルな査定決定は、姿勢ブローカーサーバーのポリシーがある限り、システムが正常にパッチが適用されたように実行し、ファイアウォールを実行していることがないようにアンチウイルスのために許可されているため、システムが（アンチウイルスValidatorの結果にもかかわらず）に準拠していることを示し（これは他の姿勢バリに係るケースでした）。
13. The Posture Transport Server sends the PB message to the Posture Transport Client that provides the message to the Posture Broker Client.
13.姿勢トランスポートサーバーは、姿勢ブローカーのクライアントにメッセージを提供姿勢交通ClientにPBメッセージを送信します。
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.
ターミナル部屋のコンピューター上の14の姿勢ブローカーClientはPBメッセージのグローバルな査定決定属性とシステムが準拠するとみなされたことを学生にレポートを調べますが、助言が含まれていたこと。
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.
修復は、地元の保護を改善するために、アンチウイルスを有効にする方法を説明するためにユーザと対話するアンチウイルスのPosture Collectorに属性を持つ15.姿勢ブローカーClientはPAメッセージを提供します。
16. The student turns on the anti-virus software and on completion steps 1-10 are repeated.
16.学生は、アンチウイルスソフトウェアをオンにし、完了時に1-10が繰り返されます。
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.
17.今回はアンチウイルスのPosture Validatorは、成功のステータスを返し、姿勢ブローカーサーバーはPBメッセージで成功したグローバルな査定決定を返します。
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.
18.姿勢ブローカーClientはPBメッセージに成功したグローバルな査定決定を受け、学生は今彼女の割り当てのためのコンピュータを使用しています。
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自主エンドポイントは、最初の評価を要求しました
o Successful (compliant) global assessment decision included in PB message with a PA message containing an advisory set of attributes for remediation.
O成功（準拠）グローバル査定決定は、修復のための属性の助言セットを含むPAメッセージでPBメッセージに含まれます。
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.
エンドポイントの再評価（複数可）成功した最初のNEA査定後にネットワークに是認された後、いつでも起こる可能性があります。これらの再評価は、イベントベース、姿勢NEAクライアントによって検出された変化、またはそのような不審な挙動の検出またはNEAサーバのネットワークポリシーの更新などのネットワークインフラストラクチャによって検出された変化によって駆動されるようなものであってもよいです。彼らはまた、エンドポイントの健全性を再評価する（タイマー・ドリブン）周期的であってもよいです。
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.
このユースケースは、システムの再評価が必要であることを決定するためにエンドポイントまたはユーザにソフトウェアを可能にします。定期的に最新のポリシーにその条件を相対評価するためにNEAサーバーをポーリングするシステムを可能にするためにも、その以前に報告された姿勢の変化、潜在的に疑わしい動作の検出、または：そのような再評価を含めて有益であるかもしれない理由はさまざまです。
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.
会社の人事部内のデスクトップは、貧しいセキュリティ対策と最終的な妥協の歴史を持っています。人事部門の管理者は、その使用を保証するために、セキュリティ保護機構の使用を監視するために、各デスクトップ上でソフトウェアを展開することを決定しました。ある日、人事担当者が誤ってデスクトップファイアウォールをオフにします。監視プロセスは、ファイアウォール、コンプライアンスの再評価を要求するファイアウォールとの接点NEAサーバーの不足を検知します。 NEA Serverは、ファイアウォールがネットワーク上で滞在して再活性化されなければならない決定を返します。 NEA Clientは、ユーザーとどのようにファイアウォールを再活性化するために決定を説明しています。 HR担当者は、ファイアウォールを再起動し、ネットワークに再参加するための要求を開始します。
The following describes the message flows through the NEA reference model for the HR department example:
次のメッセージが人事部門例えばNEA参照モデル流れる説明します：
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.
1.通常姿勢コレクターとして動作する可能性があるデスクトップの監視ソフトウェアは、姿勢の再評価を開始する姿勢ブローカクライアントをトリガします。姿勢ブローカークライアントは、デスクトップファイアウォールを示すPAメッセージを無効にされている含まれているPBメッセージを作成します。
2. The Posture Broker Client sends the PB message to the Posture Broker Server.
2.姿勢ブローカーClientは姿勢ブローカーサーバーにPBメッセージを送信します。
3. The Posture Transport Client sends the PB message to the Posture Transport Server over the PT protocol.
3.姿勢交通クライアントは、PTプロトコルを介し姿勢トランスポートサーバーにPBメッセージを送信します。
4. The Posture Broker Server receives the PB message and forwards the PA message to the firewall Posture Validator for evaluation.
4.姿勢ブローカーサーバーはPBメッセージを受信して、評価のために、ファイアウォールのPosture検証にPAメッセージを転送します。
5. The firewall Posture Validator determines that the endpoint is no longer compliant because its firewall has been disabled.
5.ファイアウォールのPosture Validatorは、そのファイアウォールが無効になっているため、エンドポイントがもはや準拠していないと判断しました。
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.
6.姿勢Validatorは非準拠ポスチャ評価結果とファイアウォールを再アクティブ化する方法について改善命令を示す属性が含まれているPAメッセージを生成します。
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.
7.姿勢ValidatorはバックNEAクライアントに対応するための態勢ブローカーサーバーへのポスチャアセスメント結果にPAメッセージを伝達します。
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.
8.姿勢ブローカーサーバーは非対応のグローバルな査定決定とファイアウォールのPosture検証からPAメッセージを含むPBメッセージを生成します。
9. The Posture Transport Server transports the PB message to the Posture Transport Client where it is passed to the Posture Broker Client.
9.姿勢トランスポートサーバーは、それが姿勢ブローカークライアントに渡される姿勢交通ClientにPBメッセージを輸送します。
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.
10.姿勢ブローカークライアントは、グローバルな査定決定を含む属性はNEAサーバから受信し、ユーザに非準拠のメッセージを表示し処理します。
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.
11.姿勢ブローカークライアントは、ファイアウォールのPosture CollectorにPAメッセージを転送します。姿勢コレクターは、デスクトップファイアウォールを有効にする方法について改善命令を表示します。
12. The user is prompted to initiate a reassessment after completing the remediation.
12.ユーザーは、修復が完了した後に再評価を開始するように指示されます。
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.
修復が完了すると13は、NEAクライアントが再評価の要求を再び開始し、1~4が繰り返されます。今回は、ファイアウォールのPosture Validatorは、エンドポイントが準拠して決定し、成功したポスチャ評価の決定を返します。
14. The Posture Broker Server generates a PB message with a global assessment decision of compliant and returns this to the NEA Client.
14.姿勢ブローカーサーバーは、対応のグローバルな査定決定にPBメッセージを生成し、NEAクライアントにこれを返します。
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自主、エンドポイント（ソフトウェア）は、姿勢の再評価要求を開始しました
o NEA Server requests specific firewall-oriented Posture Attributes
O NEA Serverは、特定のファイアウォール指向の姿勢属性を要求します
o NEA Client (firewall Posture Collector) interacts with user to remediate problem
O NEAクライアント（ファイアウォール姿勢コレクタ）は、問題を修正するためにユーザと対話します
In many cases, especially for reassessment, the NEA Server may initiate specific or complete reassessment of one or more endpoints triggered by:
多くの場合、特に再評価のために、NEA Serverは、によってトリガされた1つのまたは複数のエンドポイントの具体的なまたは完全な再評価を開始することができます。
o Time (periodic) o Event occurrence o Policy updates
ポリシーの更新O oは時間（周期）Oイベント発生
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 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.
企業の管理者は、利用可能なパッチを作成し、5 PMによってインストールされるように、それらを必要とするネットワークポリシーを変更します。このポリシーの変更は、NEA Serverが影響を受けるとパッチを欠いているエンドポイントを決定するために再評価を要求する原因となります。マーケティング従業員のノートパソコンは、再評価とパッチを必要とするように決定されます。改善勧告がパッチを入手し、それらが5 PMによってインストールされなければならないことをする方法を説明する従業員に送信され、提示されます。マーケティング従業員はすぐにダウンロードしてパッチをインストールし、すべてのパッチがインストールされましたアサーションを取得します。
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.
午後5時、企業は、彼らが、コンプライアンスに今あるかどうかを判断するために、影響を受けるすべてのエンドポイントの別の再評価を行います。マーケティング従業員のノートパソコンは、再評価し、それがインストールされたパッチを持って主張を提示し、これに準拠するために決定されます。
The following describes the message flows through the NEA reference model for the above example:
次のメッセージが上記例えばNEA参照モデル流れる説明します：
1. Marketing employee joins network and completes an initial assessment resulting in a compliant decision.
1.マーケティング従業員は、ネットワークに参加し、対応の意思決定に生じる初期評価を完了します。
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.
2.エンタープライズ管理者は、最近のパッチは深刻な脆弱性を防ぐために、午後5時までで、すべてのエンドポイント上で必要であることを示しているオペレーティングシステムのパッチポリシーを設定します。
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.
3. NEA Serverのオペレーティング・システム・パッチのPosture Validatorは、この政策変更に気付くと、使用中のOSパッチを記述する属性を要求するPAメッセージを作成し、ネットワークに接続されているすべてのエンドポイントの姿勢の再評価を開始する姿勢ブローカーサーバーをトリガします。
4. The Posture Broker creates a PB message that includes the PA message from the operating system patch Posture Validator.
4.姿勢ブローカは、オペレーティングシステムのパッチ姿勢バリデータからPAメッセージを含むPBメッセージを作成します。
5. The Posture Broker Server gradually establishes a session with each available NEA Client.
5.姿勢ブローカーサーバーは、徐々に使用可能な各NEAクライアントとのセッションを確立します。
6. The Posture Broker Server sends the PB message to the Posture Broker Client.
6.姿勢ブローカーサーバーは、姿勢ブローカーClientにPBメッセージを送信します。
7. The Posture Transport Server carries the PB message to the Posture Transport Client over the PT protocol.
7.姿勢トランスポートサーバーは、PTプロトコルを介して姿勢トランスポートクライアントにPBメッセージを運びます。
8. The Posture Broker Client receives the PB message and forwards the PA message to the operating system patch Posture Collector.
8.姿勢ブローカクライアントはPBメッセージを受信して、オペレーティング・システムのパッチ姿勢コレクタにPAメッセージを転送します。
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.
9.オペレーティングシステムのパッチ姿勢コレクターは、エンドポイント上に存在OSパッチを決定し、その開示の方針により許可した場合は、パッチ情報の属性を含むPAメッセージを作成します。
10. The Posture Broker Client sends a PB message that includes the operating system patch PA message.
10.姿勢ブローカクライアントは、オペレーティングシステムのパッチPAメッセージを含むPBメッセージを送信します。
11. The Posture Transport Client transports the PB message to the Posture Transport Server where it is passed to the Posture Broker Server.
11.姿勢交通クライアントは、それが姿勢ブローカーサーバーに渡される姿勢トランスポートサーバーにPBメッセージを輸送します。
12. The Posture Broker Server receives the PB message and delivers the PA message to the operating system patch Posture Validator.
12.姿勢ブローカーサーバーはPBメッセージを受信して、オペレーティングシステムのパッチのPosture検証にPAのメッセージを配信します。
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.
13.オペレーティング・システムのパッチ姿勢ValidatorはPAメッセージから現在のOSパッチを記述する属性を抽出し、エンドポイントが新しいポリシーに準拠しているかどうかを決定するために値を使用します。姿勢Validatorは、それがインストールされた新しいOSのパッチを持っていないため、エンドポイントが準拠していないと判断しました。
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.
14.姿勢Validatorは姿勢査定決定は非対応と必要なOSパッチをダウンロードするようにエンドポイントを有効にするには、修復の指示を含む属性である旨の属性が含まPAメッセージを生成します。
15. The Posture Validator communicates the posture assessment result to the Posture Broker Server along with its PA message.
15.姿勢ValidatorはそのPAメッセージとともに姿勢ブローカーサーバーにポスチャ評価結果を伝えます。
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.
16.姿勢ブローカーサーバーは、グローバルな査定決定を生成し、意思決定およびオペレーティングシステムのパッチのPosture ValidatorのPAメッセージにPBメッセージを送信します。
17. The Posture Transport Server transports the PB message to the Posture Transport Client where it is passed to the Posture Broker Client.
17.姿勢トランスポートサーバーは、それが姿勢ブローカークライアントに渡される姿勢交通ClientにPBメッセージを輸送します。
18. The Posture Broker Client processes the Result Attribute received from the NEA Server and displays the non-compliance decision to the user.
18.姿勢ブローカークライアントは、result属性はNEAサーバから受信し、ユーザに非準拠の判断を表示し処理します。
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.
19.姿勢ブローカクライアントは、オペレーティングシステムのパッチ姿勢コレクタに改善命令を含むPAメッセージを転送します。姿勢コレクターはこの脆弱性を防ぐために、適切なOSパッチのダウンロードなどが対応になる方法についての指示をユーザにガイドします。
20. The marketing employee installs the required patches and now is in compliance.
20.マーケティングの従業員は、必要なパッチをインストールし、今準拠しています。
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.
21. NEA Clientは、上記の手順の多くの繰り返しの原因となるオペレーティングシステムパッチの再評価をトリガします。今回は、ステップ13で、オペレーティング・システムのパッチ姿勢Validatorは、マーケティング従業員のラップトップが準拠して決定します。これは、最新のポリシーにOSパッチのコンプライアンスを主張する属性の再利用可能な（例えば、署名と日付）セットを返します。これらのOSパッチコンプライアンス表明ではなく、決定し、以前のように特定のパッチ・セット・姿勢を提供するオペレーティングシステムのパッチ・コレクターからの将来のPAメッセージに使用することができます。
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.
22.オペレーティング・システム・パッチ姿勢コレクターは、コンプライアンスを主張し、再利用可能な属性が含まれているPAメッセージを受信した今回は、将来の使用のためにそれらの属性をキャッシュします。
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.
23.その後、午後5時で、NEA Serverは、パッチ顧問への準拠を決定するための段階的な再評価をトリガします。オペレーティング・システムのパッチ姿勢コレクタ（上記ステップ9におけるような）姿勢情報を求める要求を受信した場合には、パッチが代わりにすべてのパッチを決定するインストールされていることを示すために（代わりに、特定のOSパッチ情報の）アサーションのキャッシュされたセットを返しますシステムにインストールされています。
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.
オペレーティング・システムのパッチ姿勢Validatorがアサーションを含むPAメッセージを受信すると24は、本物と許容されるアサーションの代わりに特定の姿勢であることを決定することができます。したがって、ラップトップがネットワーク上で維持することが可能に準拠しの姿勢査定決定を返します。
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
Oサーバ起動再評価による緊急パッチの可用性に必要な
o NEA Client submits reusable assertion attributes instead of posture that patch is installed
O NEA Clientは、再利用可能なアサーションがパッチがインストールされていることを代わりに姿勢の属性提出します
o NEA Server capable of recognizing previously issued assertion attributes are sufficient instead of posture
以前に発行されたアサーションの属性を認識することができるO NEA Serverは、代わりに姿勢が十分あります
This section describes the requirements that will be used by the NEA WG to assess and compare candidate protocols for PA, PB, and PT. These requirements frequently express features that a candidate protocol must be capable of offering so that a deployer can decide whether to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment.
このセクションでは、PA、PB、およびPTの候補プロトコルを評価し、比較することNEA WGで使用される要件について説明します。デプロイヤがその機能を利用するためにかどうかを決定できるように、これらの要件は、頻繁に候補プロトコルを提供することが可能でなければならない機能を発現します。このセクションでは、各プロトコルの特徴は、展開中に使用されなければならないかについて要件を記述していません。
For example, a requirement (MUST, SHOULD, or MAY) might exist for cryptographic security protections to be available from each protocol but this does not require that a deployer make use of all or even any of them should they deem their environment to offer other protections that are sufficient.
例えば、要件（MUST、SHOULD、またはMAY）が、各プロトコルから利用できるように暗号化セキュリティ保護のために存在するかもしれないが、これはデプロイヤは、彼らが他を提供するために自分の環境を考える必要があり、それらのすべて、あるいはいずれかの利用を行うことを要求しません十分なされている保護。
The following are the common requirements that apply to the PA, PB, and PT protocols in the NEA reference model:
以下は、NEA参照モデルにおけるPA、PB、およびPTプロトコルに適用される一般的な要件は次のとおりです。
C-1 NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment.
C-1 NEAプロトコルは、単一の評価にNEA ClientとNEA Serverの間の複数のラウンドトリップをサポートしなければなりません。
C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed.
C-2 NEAプロトコルは、必要に応じてポスチャ評価や再評価を開始するためのNEA ClientとNEA Serverの両方のための方法を提供する必要があります。
C-3 NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by intermediaries and endpoints including prevention from replay based attacks.
セキュリティ機能を含むC-3 NEAプロトコルはリプレイベースの攻撃から予防を含む仲介及び端点による能動的および受動的攻撃から保護することができなければなりません。
C-4 The PA and PB protocols MUST be capable of operating over any PT protocol. For example, the PB protocol must provide a transport independent interface allowing the PA protocol to operate without change across a variety of network protocol environments (e.g., EAP/802.1X, TLS, and Internet Key Exchange Protocol version 2 (IKEv2)).
C-4ザPA及びPBプロトコルは、任意のPTプロトコル上で動作可能でなければなりません。例えば、PBプロトコルはPAプロトコルは、ネットワークプロトコルの様々な環境を横切って変化することなく動作することを可能にするトランスポートに依存しないインタフェースを提供しなければならない（例えば、EAP / 802.1X、TLS、およびインターネット鍵交換プロトコルバージョン2（IKEv2の））。
C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist.
C-5 NEAプロトコルの選択プロセスは、新しいものを定義する前に要件を満たす既存のオープンスタンダードの再利用性を評価し、好むしなければなりません。 NEAの目標は、許容可能なソリューションが既に存在している追加の代替プロトコルを作成することではありません。
C-6 NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers.
C-6 NEAプロトコルは、非常にスケーラブルでなければなりません。プロトコルは、複数のNEAサーバー上に存在する数多くの姿勢バリデータによって評価されるようにNEAクライアントの数が多い上、多くの姿勢コレクターをサポートしなければなりません。
C-7 The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server.
C-7プロトコルはNEA ClientとNEA Serverの間の属性のメッセージが多数の効率的な輸送をサポートしなければなりません。
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEAプロトコルは、低帯域幅または高レイテンシのリンクを介して効率的に動作しなければなりません。
C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences.
C-9のユーザーに表示するためのものの任意の文字列の場合、プロトコルは、ユーザーの言語設定にこれらの文字列を適応サポートしなければなりません。
C-10 NEA protocols MUST support encoding of strings in UTF-8 format [UTF8].
C-10 NEAプロトコルは、UTF8形式[UTF8]の文字列の符号化をサポートしなければなりません。
C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on: which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of roundtrips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols.
C-11により、基礎となる候補PTプロトコルによって提供される潜在的に異なる輸送特性に、NEA ClientとNEA Serverは、の認識になり、利用可能なPTプロトコルの制約に適応できなければなりません。終了メッセージまたは完全な評価、ラウンドトリップの回数の上限、および順序（二重）でNEA接続、最大データサイズを開始することができる：例えば、PA及びPBの動作に影響を与える可能性のあるPTプロトコル特性に対する制限を含みますメッセージの交換。 PTプロトコルの選択プロセスは、候補PTプロトコルはPAとPBプロトコルに課す制限を考慮する必要があります。
The Posture Attribute (PA) protocol defines the transport and data model to carry posture and validation information between a particular Posture Collector associated with the NEA Client and a Posture Validator associated with a NEA Server. The PA protocol carries collections of standard attributes and vendor-specific attributes. The PA protocol itself is carried inside the PB protocol.
姿勢属性（PA）プロトコルは、NEA ClientとNEA Serverに関連付けられたポスチャ検証に関連する特定の姿勢コレクタ間の姿勢と検証情報を運ぶために輸送およびデータ・モデルを定義します。 PAプロトコルが標準属性とベンダ固有の属性のコレクションを運びます。 PAプロトコル自体はPBプロトコルの内部で行われます。
The following requirements define the desired properties that form the basis for comparison and evaluation of candidate PA protocols. These requirements do not mandate the use of these properties, but merely that the candidate protocols are capable of offering the property if it should be needed.
以下の要件は、候補PAプロトコルの比較および評価のための基礎を形成する所望の特性を定義します。これらの要件は、これらのプロパティの使用を強制しませんが、候補プロトコルは、それが必要する必要がある場合はプロパティを提供することができるだけであること。
PA-1 The PA protocol MUST support communication of an extensible set of NEA standards defined attributes. These attributes will be distinguishable from non-standard attributes.
PA-1ザPAプロトコルは、属性定義NEA標準の拡張可能なセットの通信をサポートしなければなりません。これらの属性は、非標準の属性と区別されます。
PA-2 The PA protocol MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identified vendor-specific namespaces.
PA-2ザPAプロトコルは、ベンダー固有の属性の拡張可能なセットの通信をサポートしなければなりません。これらの属性は一意に特定ベンダー固有の名前空間に分割されます。
PA-3 The PA protocol MUST enable a Posture Validator to make one or more requests for attributes from a Posture Collector within a single assessment. This enables the Posture Validator to reassess the posture of a particular endpoint feature or to request additional posture including from other parts of the endpoint.
PA-3ザ・PAプロトコルは、単一の評価の中に姿勢コレクターからの属性の1つまたは複数の要求をするために姿勢バリデータを有効にする必要があります。これは、特定のエンドポイントの特徴の姿勢を再評価するか、またはエンドポイントの他の部分からを含む追加の姿勢を要求する姿勢検証を可能にします。
PA-4 The PA protocol MUST be capable of returning attributes from a Posture Validator to a Posture Collector. For example, this might enable the Posture Collector to learn the specific reason for a failed assessment and to aid in remediation and notification of the system owner.
PA-4ザPAプロトコルは姿勢コレクタにポスチャ検証の属性を返すことができなければなりません。たとえば、これは失敗した評価のための具体的な理由を学ぶために、修復やシステムの所有者の通知を支援する姿勢コレクタを有効かもしれません。
PA-5 The PA protocol SHOULD provide authentication, integrity, and confidentiality protection for attributes communicated between a Posture Collector and Posture Validator. This enables end-to-end security across a NEA deployment that might involve traversal of several systems or trust boundaries.
PA-5ザ・PAプロトコルは、姿勢コレクターとのPosture Validatorの間で通信属性の認証、完全性、機密性保護を提供する必要があります。これは、複数のシステムや信頼境界の横断を伴う可能性があるNEAの展開全体でエンドツーエンドのセキュリティを可能にします。
PA-6 The PA protocol MUST be capable of carrying attributes that contain non-binary and binary data including encrypted content.
PA-6ザPAプロトコルは、暗号化されたコンテンツを含む非バイナリ、バイナリデータを含む属性を運ぶことができなければなりません。
The PB protocol supports multiplexing of Posture Attribute messages (based on PA protocol) between the Posture Collectors on the NEA Client to and from the Posture Validators on the NEA Server (in either direction).
PBプロトコルは、姿勢の多重化をサポートしています（いずれかの方向に）NEA Server上の姿勢バリデータにしてから、NEAクライアント上の姿勢コレクターの間（PAプロトコルに基づいて）メッセージを属性。
The PB protocol carries the global assessment decision made by the Posture Broker Server, taking into account the results of the Posture Validators involved in the assessment, to the Posture Broker Client.
PBプロトコルは、姿勢ブローカークライアントに、考慮に評価に関わる姿勢バリデータの結果を取って、姿勢ブローカーサーバーによって行われたグローバルな査定決定を運びます。
The PB protocol also aggregates and transports advisories and notifications such as remediation instructions (e.g., patch references) from one or more Posture Validators.
PBプロトコルはまた、集約し、1つ以上のポスチャバリデータから修復指示（例えば、パッチ参照）として勧告と通知を搬送します。
The requirements for the PB protocol are:
PBプロトコルのための要件は次のとおりです。
PB-1 The PB protocol MUST be capable of carrying attributes from the Posture Broker Server to the Posture Broker Client. This enables the Posture Broker Client to learn the posture assessment decision and if appropriate to aid in remediation and notification of the endpoint owner.
PB-1 PBプロトコルは姿勢ブローカクライアントに姿勢ブローカサーバから属性を運ぶことができなければなりません。このことは、適切であれば修復し、エンドポイントの所有者の通知を支援するために姿勢査定決定を学び、する姿勢ブローカークライアントを可能にします。
PB-2 The PB protocol MUST NOT interpret the contents of PA messages being carried, i.e., the data it is carrying must be opaque to it.
PB-2ザ・PBプロトコルが搭載されているPAメッセージの内容を解釈してはならない、すなわち、それが運んでいるデータは、それに対して不透明でなければなりません。
PB-3 The PB protocol MUST carry unique identifiers that are used by the Posture Brokers to route (deliver) PA messages between Posture Collectors and Posture Validators. Such message routing should facilitate dynamic registration or deregistration of Posture Collectors and Validators. For example, a dynamically registered anti-virus Posture Validator should be able to subscribe to receive messages from its respective anti-virus Posture Collector on NEA Clients.
PB-3、PBプロトコルは、ルート（配信）姿勢コレクターと姿勢バリ間PAメッセージにポスチャブローカーによって使用される一意の識別子を運ばなければなりません。そのようなメッセージルーティングは、姿勢コレクターとバリデータの動的な登録または登録解除を容易にするはずです。たとえば、動的に登録されたアンチウイルスのPosture ValidatorはNEAクライアント上で、それぞれのアンチウイルス姿勢コレクターからのメッセージを受信するためにサブスクライブすることができるはずです。
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT protocol. However this does not preclude PB from operating full-duplex when running over a full-duplex PT.
PB-4ザPBプロトコルは半二重PTプロトコルをサポートできなければなりません。しかし、これは、全二重PT上で実行している場合、全二重動作してからPBを排除するものではありません。
PB-5 The PB protocol MAY support authentication, integrity and confidentiality protection for the attribute messages it carries between a Posture Broker Client and Posture Broker Server. This provides security protection for a message dialog of the groupings of attribute messages exchanged between the Posture Broker Client and Posture Broker Server. Such protection is orthogonal to PA protections (which are end to end) and allows for simpler Posture Collector and Validators to be implemented, and for consolidation of cryptographic operations possibly improving scalability and manageability.
PB-5 PBプロトコルは、それが姿勢ブローカークライアント・姿勢ブローカーサーバーの間で運ぶ属性メッセージの認証、完全性と機密性の保護をサポートするかもしれません。これは、姿勢ブローカークライアント・姿勢ブローカーサーバーの間で交換される属性のメッセージのグループ化のメッセージダイアログのセキュリティ保護を提供します。そのような保護は、（エンドツーエンドである）PAの保護に直交し、かつ簡単姿勢コレクタとバリデータを実装することを可能にし、暗号化操作を統合するための可能性のスケーラビリティと管理性を向上させることができます。
PB-6 The PB protocol MUST support grouping of attribute messages optimize transport of messages and minimize round trips.
PB-6ザ・PBプロトコルは、属性のメッセージのグループ化は、メッセージの転送を最適化しサポートし、ラウンドトリップを最小限にしなければなりません。
The Posture Transport (PT) protocol carries PB protocol messages between the Posture Transport Client and the Posture Transport Server. PT is responsible for providing a protected transport for the PB protocol. The PT protocol may itself be transported by one or more concatenated sessions using lower layer protocols, such as 802.1X, RADIUS [RADIUS], TLS, or IKE.
姿勢トランス（PT）プロトコルは、姿勢交通クライアント・姿勢トランスポートサーバーとの間のPBプロトコルメッセージを運びます。 PTはPBプロトコルのために保護されたトランスポートを提供する責任があります。 PTプロトコル自体は、802.1X、RADIUS [RADIUS]、TLS、またはIKEなどの下位層プロトコルを使用して1つ以上の連結セッションによって輸送されてもよいです。
This section defines the requirements that candidate PT protocols must be capable of supporting.
このセクションでは、候補PTプロトコルをサポートすることができなければならない要件を定義します。
PT-1 The PT protocol MUST NOT interpret the contents of PB messages being transported, i.e., the data it is carrying must be opaque to it.
PT-1ザ・PT・プロトコル、すなわち、それが搬送されたデータは、それに対して不透明である必要があり、搬送されるPBメッセージの内容を解釈してはいけません。
PT-2 The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server.
PT-2 PTプロトコルは、相互認証、整合性、機密性、および姿勢交通クライアント・姿勢トランスポートサーバー間のPBメッセージの再生保護をサポートすることができなければなりません。
PT-3 The PT protocol MUST provide reliable delivery for the PB protocol. This includes the ability to perform fragmentation and reassembly, detect duplicates, and reorder to provide in-sequence delivery, as required.
PT-3ザ・PTプロトコルはPBプロトコルの信頼できる配信を提供しなければなりません。これは、断片化と再アセンブリを実行し、重複を検出し、必要に応じて、インシーケンス配信を提供するために、並べ替えする能力を含みます。
PT-4 The PT protocol SHOULD be able to run over existing network access protocols such as 802.1X and IKEv2.
PT-4 PTプロトコルは、802.1XとIKEv2のような既存のネットワーク・アクセス・プロトコルにわたって実行することができます。
PT-5 The PT protocol SHOULD be able to run between a NEA Client and NEA Server over TCP or UDP (similar to Lightweight Directory Access Protocol (LDAP)).
PT-5 PTプロトコルは、TCPまたは（のLDAP（Lightweight Directory Access Protocol）に似ています）UDP上でNEA ClientとNEA Serverの間で実行することができます。
This document defines the functional requirements for the PA, PB, and PT protocols used for Network Endpoint Assessment. As such, it does not define a specific protocol stack or set of technologies, so this section will highlight security issues that may apply to NEA in general or to particular aspects of the NEA reference model.
この文書では、ネットワークのエンドポイントの評価に使用するPA、PB、およびPTプロトコルの機能要件を定義します。このように、特定のプロトコルスタックを定義していないか、技術のセットので、このセクションは、一般的にまたはNEA参照モデルの特定の態様にNEAに適用できるセキュリティ上の問題を強調します。
Note that while a number of topics are outside the scope of the NEA WG and thus this specification (see section 3.1), it is important that those mechanisms are protected from attack. For example, the methods of triggering an assessment or reassessment are out of scope but should be appropriately protected from attack (e.g., an attacker hiding the event indicating a NEA Server policy change has occurred).
トピックの数は、NEA WGの範囲、従って、本明細書（セクション3.1を参照）の外側にあるが、これらのメカニズムは、攻撃から保護されることが重要であることに留意されたいです。例えば、評価または再評価をトリガする方法が範囲外であるが、適宜（例えば、NEA Serverポリシーの変更を示すイベントを隠し、攻撃者が発生した）攻撃から保護されなければなりません。
NEA intends to facilitate detection and corrective actions for cooperating endpoints to become compliant with network compliance policies. For example, it is envisioned that these policies will allow deployers to detect out-of-date, inactive, or absent security mechanisms on the endpoint that might leave it more vulnerable to known attacks. If an endpoint is more vulnerable to compromise, then it is riskier to have this endpoint present on the network with other valuable assets. By proactively assessing cooperating endpoints before their entrance to the network, deployers can improve their resilience to attack prior to network access. Similarly, reassessments of cooperating endpoints on the network may be helpful in assuring that security mechanisms remain in use and are up to date with the latest policies.
NEAは、ネットワークコンプライアンスポリシーに準拠するようになり、エンドポイントを協力するための検出および是正措置を促進していきます。例えば、これらのポリシーはデプロイヤが既知の攻撃に対してより脆弱に残す可能性があるエンドポイントで時代遅れの、非アクティブ、または不在のセキュリティメカニズムを検出できるようになることが想定されます。エンドポイントは妥協するより脆弱である場合、他の貴重な資産とのネットワーク上に存在し、このエンドポイントを持つことがより危険です。積極的にネットワークへの入り口の前に協力し、エンドポイントを評価することにより、デプロイヤは、ネットワークアクセスする前に攻撃するために彼らの回復力を向上させることができます。同様に、ネットワーク上のエンドポイントを協力の再評価は、セキュリティメカニズムが使用されて残り、最新のポリシーと最新であることを確保する上で役立つかもしれません。
NEA fully recognizes that not all endpoints will be cooperating by providing their valid posture (or any posture at all). This might occur if malware is influencing the NEA Client or policies, and thus a trustworthy assessment isn't possible. Such a situation could result in the admission of an endpoint that introduces threats to the network and other endpoints despite passing the NEA compliance assessment.
NEAは完全ではない、すべてのエンドポイントは、その有効な姿勢（またはすべての任意の姿勢）を提供することで、協力することになると認識しています。マルウェアはNEA Clientまたは政策に影響を与えているので、信頼できる評価が可能でない場合、これが発生する可能性があります。このような状況は、NEAのコンプライアンス評価を渡すことにもかかわらず、ネットワークへの脅威や他のエンドポイントを紹介したエンドポイントの入学につながる可能性があります。
Network Endpoint Assessment involves assessing the posture of endpoints entering or already on the network against compliance policies to assure they are adequately protected. Therefore, there must be an implied distrusting of endpoints until there is reason to believe (based on posture information) that they are protected from threats addressed by compliance policy and can be trusted to not propagate those threats to other endpoints. On the network provider side, the NEA Client normally is expected to trust the network infrastructure systems to not misuse any disclosed posture information (see section 9) and any remediation instructions provided to the endpoint. The NEA Client normally also needs to trust that the NEA Server will only request information required to determine whether the endpoint is safe to access the network assets.
ネットワークエンドポイントの評価は、それらが適切に保護されている保証するために、コンプライアンスポリシーに対するネットワーク上すでに入力したり、エンドポイントの姿勢を評価する必要。それらはコンプライアンスポリシーによって対処脅威から保護され、他のエンドポイントにそれらの脅威を伝播しないために信頼できること（姿勢情報に基づいて）信じるに足る理由があるまでそのため、エンドポイントの暗黙のdistrustingがなければなりません。ネットワークプロバイダ側では、NEAクライアントは、通常、任意の開示された姿勢情報（セクション9を参照）、エンドポイントに提供された修正指示を誤用しないように、ネットワーク・インフラストラクチャ・システムを信頼することが期待されます。 NEAクライアントが正常にもNEA Serverが唯一のエンドポイントがネットワーク資産にアクセスしても安全であるかどうかを判断するために必要な情報を要求することを信頼する必要があります。
Between the NEA Client and Server there exists a network that is not assumed to be trustworthy. Therefore, little about the network is implicitly trusted beyond its willingness and ability to transport the exchanged messages in a timely manner. The amount of trust given to each component of the NEA reference model is deployment specific. The NEA WG intends to provide security mechanisms to reduce the amount of trust that must be assumed by a deployer. The following sections will discuss each area in more detail.
NEAクライアントとサーバ間の信頼できると想定していないネットワークが存在します。そのため、ネットワークについて少しは暗黙のうちにその意欲とタイムリーに交換されたメッセージを輸送する能力を超えて信頼されています。 NEA参照モデルの各構成要素に与えられた信頼の量は、配備特異的です。 NEA WGは、デプロイヤが想定されている必要があり、信頼の量を減らすためにセキュリティ機構を提供することを目的とします。次のセクションでは、より詳細に各領域について説明します。
For NEA to properly operate, the endpoint needs to be trusted to accurately represent the requested security posture of the endpoint to the NEA Server. By NEA WG charter, the NEA reference model does not explicitly specify how to detect or prevent lying endpoints that intentionally misrepresent their posture. Similarly, the detection of malware (e.g., root kits) that are able to trick the Posture Collectors into returning incorrect information is the subject for research and standardization outside the IETF (e.g., Trusted Computing Group [TCG]) and is not specifically addressed by the model. However, if such mechanisms are used in a deployment, the NEA reference model should be able to accommodate these technologies by allowing them to communicate over PA to Posture Validators or work orthogonally to protect the NEA Client from attack and assure the ability of Posture Collectors to view the actual posture.
NEAが正常に動作するには、エンドポイントが正確にNEA Serverへのエンドポイントの要求されたセキュリティ状態を表すために、信頼する必要があります。 NEA WG憲章によって、NEAの参照モデルは、明示的に検出したり、意図的にその姿勢を偽る横たわってエンドポイントを防ぐためにどのように指定されていません。同様に、誤った情報を返すに姿勢コレクターをだますことが可能であるマルウェアの検出（例えば、ルートキット）はIETF（例えば、トラステッドコンピューティンググループ[TCG]）外研究および標準化の対象であり、具体的にすることによって対処されていませんモデル。そのようなメカニズムがデプロイメントで使用されている場合は、NEA参照モデルは、彼らが姿勢バリにPAを介して通信できるようにすることで、これらの技術に対応することができるはずや攻撃からNEAクライアントを保護し、への姿勢コレクターの能力を保証するために直角に働きます実際の姿勢を表示します。
Besides having to trust the integrity of the NEA Client and its ability to accurately collect and report Posture Attributes about the endpoint, we try to limit other assumed trust. Most of the usage models for NEA expect the posture information to be sent to the NEA Server for evaluation and decision making. When PA and/or PT level security protections are used, the endpoint needs to trust the integrity and potentially confidentiality of the trust anchor information (e.g., public key certificates) used by the Posture Collector and/or Posture Transport Client. However, NEA implementations may choose to send or pre-provision some policies to the endpoint for evaluation that would assume more trust in the endpoint. In this case, the NEA Server must trust the endpoint's policy storage, evaluation, and reporting mechanisms to not falsify the results of the posture evaluation.
NEAクライアントの完全性と正確姿勢がエンドポイントに関する属性を収集し、報告する能力を信頼することに加えて、我々は他の想定信頼を制限しよう。 NEAのための使用モデルのほとんどは、姿勢情報は、評価と意思決定のためにNEA Serverに送信されることを期待します。 PAおよび/またはPTレベルのセキュリティ保護が使用される場合、エンドポイントは、完全性と姿勢コレクタおよび/または姿勢交通クライアントが使用するトラストアンカー情報（例えば、公開鍵証明書）の潜在的な機密性を信頼する必要があります。しかし、NEAの実装は、エンドポイントでより多くの信頼を引き受ける評価のためのエンドポイントにいくつかのポリシーを送信したり、事前に準備することもできます。この場合、NEA Serverは、エンドポイントのポリシーストレージを信用評価、およびメカニズムを報告すると、姿勢評価の結果を改ざんしないようにしなければなりません。
Generally the endpoint should not trust network communications (e.g., inbound connection requests) unless this trust has been specifically authorized by the user or owner defined policy or action. The NEA reference model assumes the entire NEA Client is local to the endpoint. Unsolicited communications originating from the network should be inspected by normal host-based security protective mechanisms (e.g., firewalls, security protocols, Intrusion Detection/Prevention System (IDS/IPS), etc.). Communications associated with a NEA assessment or reassessment requires some level of trust particularly when initiated by the NEA Server (reassessment). The degree of trust can be limited by use of strong security protections on the messages as dictated by the network deployer and the endpoint user/owner policy.
この信頼は、具体的には、ポリシーまたはアクション定義されたユーザまたは所有者によって承認されていない限り、一般的にエンドポイントが（例えば、着信接続要求）ネットワーク通信を信頼してはなりません。 NEAの参照モデルは全体NEAクライアントがエンドポイントにローカルである前提としています。ネットワークから発信要請されていない通信は、通常、ホストベースのセキュリティ保護メカニズム（例えば、ファイアウォール、セキュリティプロトコル、侵入検知/防止システム（IDS / IPS）など）によって検査されなければなりません。 NEA査定や再評価に関連した通信はNEA Serverの（再評価）によって開始され、特に信頼のいくつかのレベルが必要です。ネットワークの配備担当者およびエンドポイントのユーザ/所有者のポリシーによって指示されるように、信頼度は、メッセージの強力なセキュリティ保護を使用することにより制限することができます。
Between the NEA Client and Server, there may exist a variety of types of devices to facilitate the communication path. Some of the devices may serve as intermediaries (e.g., simple L2 switches) so they may have the opportunity to observe and change the message dialogs.
NEAクライアントとサーバ間の通信経路を容易にするために、デバイスの様々なタイプのが存在してもよいです。デバイスの中には、仲介者（例えば、シンプルなL2スイッチ）として働くことができるので、彼らは観察し、メッセージダイアログを変更する機会を持つことができます。
The intermediary devices may fall into a few major categories that impact our degree of trust in their operation. First, some intermediary devices may act as message forwarders or carriers for PT (e.g., L2 switches, L3 routers). For these devices we trust them not to drop the messages or actively attempt to disrupt (e.g., denial of service (DoS)) the NEA deployment.
中間デバイスは、その動作の信頼の私達の程度に影響を与えるいくつかの主要なカテゴリに分類されることがあります。まず、いくつかの中間デバイスは、PTのメッセージフォワーダまたは担体（例えば、L2スイッチ、L3ルータ）として作用することができます。我々は彼らが（例えば、サービス拒否（DoS）の）NEAの展開を混乱させるしようと積極的にメッセージを落としたりしないと信頼、これらのデバイスのために。
Second, some intermediary devices may be part of the access control layer of the network and as such, we trust them to enforce policies including remediation, isolation, and access controls given to them as a result on a NEA assessment. These devices may also fill other types of roles described in this section.
第二に、いくつかの中間デバイスは、ネットワークのアクセス制御層の一部であってもよく、そのように、我々は修復、隔離、およびNEA査定の結果として彼らに与えられたアクセス制御を含むポリシーを適用するためにそれらを信頼しています。また、これらのデバイスは、このセクションで説明する役割の他のタイプを満たしてもよいです。
Third, some devices may act as a termination point or proxy for the PT carrier protocol. Frequently, it is expected that the carrier protocol for PT will terminate on the NEA Client and Server so will be co-resident with the PT endpoints. If this expectation is not present in a deployment, we must trust the termination device to accurately proxy the PT messages without alteration into the next carrier protocol (e.g., if inner EAP method messages are transitioned from an EAP [EAP] tunnel to a RADIUS session).
第三に、いくつかのデバイスは、PTキャリアプロトコルの終端点またはプロキシとして動作してもよいです。しばしば、PTのためのキャリアプロトコルは、NEAクライアント上で終了すると、サーバーはそのPTのエンドポイントとの共存であることが期待されます。この予想は、配備中に存在しない場合に内部EAPメソッドメッセージがRADIUSセッションにEAP [EAP]トンネルから移行された場合、我々は次のキャリアプロトコル（例えば、中にそのままPTメッセージ正確プロキシに終端装置を信頼する必要があります）。
Fourth, many networks include infrastructure such as IDS/IPS devices that monitor and take corrective action when suspicious behavior is observed on the network. These devices may have a relationship with the NEA Server that is not within scope for this specification. Devices trusted by the NEA Server to provide security information that might affect the NEA Server's decisions are trusted to operate properly and not cause the NEA Server to make incorrect decisions.
第四に、多くのネットワークは、このような監視や不審な行動がネットワーク上で観測されたときに是正措置をとるIDS / IPSデバイスなどのインフラが含まれます。これらのデバイスは、この仕様のための範囲内ではないNEA Serverとの関係を有することができます。 NEA Serverの意思決定に影響を与える可能性があるセキュリティ情報を提供するために、NEA Serverによって信頼されたデバイスは、間違った決定を下すためにNEAサーバーを引き起こし、正しくない動作させるために信頼されています。
Finally, other types of intermediary devices may exist on the network between the NEA Client and Server that are present to service other network functions beside NEA. These devices might be capable of passively eavesdropping on the network, archiving information for future purposes (e.g., replay or privacy invasion), or more actively attacking the NEA protocols. Because these devices do not play a role in facilitating NEA, it is essential that NEA deployers not be forced to trust them for NEA to reliably operate. Therefore, it is required that NEA protocols offer security protections to assure these devices can't steal, alter, spoof or otherwise damage the reliability of the message dialogs.
最後に、中間デバイスの他のタイプは、NEAの横に他のネットワーク機能をサービスするために存在しているNEAクライアントとサーバの間のネットワーク上に存在してもよいです。これらのデバイスは、受動的に、ネットワーク上の盗聴、将来の目的（例えば、リプレイやプライバシーの侵害）、またはそれ以上の積極的NEAプロトコルを攻撃するための情報をアーカイブできるかもしれません。これらのデバイスは、NEAを促進する役割を果たしていないので、NEAのデプロイヤは確実に動作するNEAのためにそれらを信頼することを強制されないことが不可欠です。したがって、NEAプロトコルは、盗む変更、なりすましをか、そうでない場合は、メッセージダイアログの信頼性を損なうことができないこれらのデバイスを確実にするために、セキュリティ保護を提供することが必要です。
The NEA Server (including potentially remote systems providing posture validation services) is generally trusted to apply the specified assessment policies and must be protected from compromise. It is essential that NEA Server deployments properly safeguard these systems from a variety of attacks from the network and endpoints to assure their proper operation.
（ポスチャ検証サービスを提供する潜在的にリモートシステムを含む）NEA Serverは、一般的に、指定アセスメントポリシーを適用するために信頼されており、妥協から保護されなければなりません。 NEA Server展開が適切に適切な動作を保証するために、ネットワークからの攻撃やエンドポイントの様々なこれらのシステムを保護することが不可欠です。
While there is a need to trust the NEA Server operation to some degree, rigorous security architecture, analysis, monitoring, and review should assure its network footprint and internal workings are protected from attack. The network footprint would include communications over the network that might be subject to attack such as policy provisioning from the policy authoring systems and general security and system management protocols. Some examples of internal workings include protections from malware attacking the intra-NEA Server communications, NEA Server internal logic, or policy stores (particularly those that would change the resulting decisions or enforcements). The NEA Server needs to trust the underlying NEA and lower layer network protocols to properly behave and safeguard the exchanged messages with the endpoint. The NEA reference model does not attempt to address integrity protection of the operating system or other software supporting the NEA Server.
そこにある程度、厳格なセキュリティアーキテクチャ、分析、モニタリングにNEA Serverの操作を信頼する必要があり、かつ審査がそのネットワークのフットプリントを保証すべきであるとしながら、内部の仕組みは、攻撃から保護されています。ネットワークのフットプリントは、ポリシー・オーサリング・システムと一般的なセキュリティとシステム管理プロトコルからポリシーのプロビジョニングのような攻撃を受ける可能性があり、ネットワークを介して通信を含むであろう。内部動作のいくつかの例は、イントラNEAサーバ通信、NEA Serverの内部ロジック、またはポリシーストアを（特に、得られた決定又は施行を変更するであろうもの）攻撃マルウェアからの保護を含みます。 NEA Serverが正常に動作し、エンドポイントと交換されたメッセージを保護するための基礎となるNEAと下位層ネットワークプロトコルを信頼する必要があります。 NEA参照モデルは、NEAサーバをサポートしているオペレーティングシステムやその他のソフトウェアの完全性保護に対処しようとしません。
One interesting example is where some components of the NEA Server physically reside in different systems. This might occur when a Posture Validator (or a remote backend server used by a local Posture Validator) exists on another system from the Posture Broker Server. Similarly, the Posture Broker Server might exist on a separate system from the Posture Transport Server. When there is a physical separation, the communications between the remote components of the NEA Server must ensure that the PB session and PA message dialogs are resistant to active and passive attacks, in particular, guarded against eavesdropping, forgery and replay. Similarly, the Posture Validators may also wish to minimize their trust in the Posture Broker Server beyond its ability to properly send and deliver PA messages. The Posture Validators could employ end-to-end PA security to verify the authenticity and protect the integrity and/or confidentiality of the PA messages exchanged.
NEAサーバーの一部のコンポーネントは、物理的に異なるシステムに常駐する場所を一つの興味深い例です。姿勢バリデータ（またはローカルのPosture Validatorによって使用されるリモートバックエンドサーバが）姿勢ブローカーサーバーから別のシステムに存在するとき、これが発生する可能性があります。同様に、姿勢ブローカーサーバーは、姿勢トランスポートサーバーとは別のシステム上に存在する可能性があります。物理的な分離がある場合、NEA Serverのリモートコンポーネント間の通信は、PBセッションおよびPAメッセージダイアログが盗聴、偽造やリプレイに対して守ら特に能動的および受動的攻撃に対して耐性であることを確認しなければなりません。同様に、姿勢バリデータも適切にPAメッセージを送信して提供する能力を超えて姿勢ブローカーサーバーでの彼らの信頼を最小化することを望むかもしれません。姿勢バリデータは信頼性を確認し、交換PAメッセージの完全性および/または機密性を保護するために、エンドツーエンドのPAのセキュリティを採用することができます。
When PA security is used, each Posture Validator must be able to trust the integrity and potentially confidentiality of its trust anchor policies.
PAのセキュリティを使用する場合は、それぞれのPosture Validatorは誠実さとそのトラストアンカー政策の潜在的な機密性を信頼できなければなりません。
Inherent in the requirements is a desire for NEA candidate protocols throughout the reference model to be capable of providing strong security mechanisms as dictated by the particular deployment. In some cases, these mechanisms may appear to provide overlapping or redundant protections. These apparent overlaps may be used in combination to offer a defense in depth approach to security. However, because of the layering of the protocols, each set of protections offers slightly different benefits and levels of granularity.
要件に固有の特定の配置によって決定されるように、強力なセキュリティメカニズムを提供することができるように、基準モデル全体NEA候補プロトコルの欲求です。いくつかの場合において、これらのメカニズムは、重複または冗長保護を提供するように見えることがあります。これら見かけ重複は、セキュリティへの深さのアプローチにおける防御を提供するために組み合わせて使用することができます。しかし、プロトコルのレイヤ化のため、保護の各セットは、わずかに異なるメリットと粒度のレベルを提供しています。
For example, a deployer may wish to encrypt traffic at the PT layer to protect against some forms of traffic analysis or interception by an eavesdropper. Additionally, the deployer may also selectively encrypt messages containing the posture of an endpoint to achieve end-to-end confidentiality to its corresponding Posture Validator. In particular, this might be desired when the Posture Validator is not co-located with the NEA Server so the information will traverse additional network segments after the PT protections have been enforced or so that the Posture Validator can authenticate the corresponding Posture Collector (or vice versa).
例えば、デプロイヤは盗聴者によってトラフィック分析または傍受のいくつかの形態から保護するために、Pt層でトラフィックを暗号化することを望むかもしれません。また、デプロイヤはまた、選択的にその対応するポスチャ検証にエンドツーエンドの機密性を達成するために、エンドポイントの姿勢を含むメッセージを暗号化することができます。ポスチャ検証がNEAサーバと同じ場所に配置されていない場合に特に、これはPTの保護は、ポスチャ検証は、対応する姿勢コレクタ（または副を認証できるように強制またはれた後ので、情報は、追加のネットワーク・セグメントを横断する所望されるかもしれませんその逆）。
Different use cases and environments for the NEA technologies will likely influence the selection of the strength and security mechanisms employed during an assessment. The goal of the NEA requirements is to encourage the selection of technologies and protocols that are capable of providing the necessary protections for a wide variety of types of assessment.
NEA技術のためのさまざまな使用事例や環境アセスメントの際に用いられる強さとセキュリティメカニズムの選択に影響する可能性があります。 NEAの要件の目標は、評価のさまざまなタイプのために必要な保護を提供することが可能である技術やプロトコルの選択を促進することです。
A variety of attacks are possible against the NEA protocols and assessment technologies. This section does not include a full security analysis, but wishes to highlight a few attacks that influenced the requirement definition and should be considered by deployers selecting use of protective mechanisms within the NEA reference model.
さまざまな攻撃は、NEAプロトコルおよび評価技術に対して可能です。このセクションでは、完全なセキュリティ分析を含むが、要件定義に影響を与えたとNEA参照モデル内の保護機構の使用を選択するデプロイヤによって考慮されるべきいくつかの攻撃を強調したいしません。
As discussed, there are a variety of protective mechanisms included in the requirements for candidate NEA protocols. Different use cases and environments may cause deployers to decide not to use some of these mechanisms; however, this should be done with an understanding that the deployment may become vulnerable to some classes of attack. As always, a balance of risk vs. performance, usability, manageability, and other factors should be taken into account.
論じたように、候補NEAプロトコルの要件に含まれる保護様々なメカニズムが存在します。別のユースケースと環境がデプロイヤがこれらのメカニズムの一部を使用しないことを決定する可能性があり、しかし、これは展開が攻撃の一部のクラスに対して脆弱になることを理解した上で行うべきです。いつものように、パフォーマンス、使いやすさ、管理性、およびその他の要因対リスクのバランスを考慮すべきです。
The following types of attacks are applicable to network protocols defined in the reference model and thus should be considered by deployers.
攻撃次のタイプの参照モデルで定義されたネットワークプロトコルに適用可能であり、従って、デプロイヤによって考慮されるべきです。
MITM attacks against a network protocol exist when a third party can insert itself between two communicating entities without detection and gain benefit from involvement in their message dialog. For example, a malware infested system might wish to join the network replaying posture observed from a clean endpoint entering the network. This might occur by the system inserting itself into and actively proxying an assessment message dialog. The impact of the damage caused by the MITM can be limited or prevented by selection of appropriate protocol protective mechanisms.
第三者が検出されることなく、2つの通信エンティティ間で自分自身を挿入し、そのメッセージダイアログの関与から利益を得ることができたときに、ネットワークプロトコルに対するMITM攻撃が存在します。たとえば、マルウェア感染したシステムは、ネットワークに侵入クリーンなエンドポイントから観察姿勢を再生するネットワークに参加することを望むかもしれません。これは、に自分自身を挿入し、積極的に評価メッセージダイアログをプロキシシステムによって発生する可能性があります。 MITMによって引き起こされる損傷の影響は、適切なプロトコル防御機構の選択によって制限または防止することができます。
For example, the requirement for PT to be capable of supporting mutual authentication prior to any endpoint assessment message dialogs prevents the attacker from inserting itself as an active participant (proxy) within the communications without detection (assuming the attacker lacks credentials convincing either party it is legitimate). Reusable credentials should not be exposed on the network to assure the MITM doesn't have a way to impersonate either party. The PT requirement for confidentiality-protected (encrypted) communications linked to the above authentication prevents a passive MITM from eavesdropping by observing the message dialog and keeping a record of the conformant posture values for future use. The PT requirement for replay prevention stops a passive MITM from later establishing a new session (or hijacking an existing session) and replaying previously observed message dialogs.
例えば、PTは、従来の任意のエンドポイント評価メッセージダイアログに相互認証をサポートすることができるようにするための要件は、攻撃者はそれがいずれかの当事者を説得資格を欠いていると仮定すると（検出せずに通信内に積極的に参加（プロキシ）として自身を挿入する攻撃者を防ぎ合法的な）。再利用可能な資格情報は、MITMは、いずれかの当事者を偽装する方法がありません確実にするために、ネットワーク上で公開するべきではありません。上記認証に連結された機密保護（暗号化）通信のためのPT要件は、メッセージダイアログを観察し、将来の使用のために適合姿勢値の記録を保持することによって盗聴から受動MITMを防止します。リプレイ防止用PT要件は、後で新しいセッションを確立する（または既存のセッションをハイジャック）と以前に観察されたメッセージダイアログを再生から受動MITMを停止します。
If a non-compliant, active MITM is able to trick a clean endpoint to give up its posture information, and the MITM has legitimate credentials, it might be able to appear to a NEA Server as having compliant posture when it does not. For example, a non-compliant MITM could connect and authenticate to a NEA Server and as the NEA Server requests posture information, the MITM could request the same posture from the clean endpoint. If the clean endpoint trusts the MITM to perform a reassessment and is willing to share the requested posture, the MITM could obtain the needed posture from the clean endpoint and send it to the NEA Server. In order to address this form of MITM attack, the NEA protocols would need to offer a strong (cryptographic) binding between the posture information and the authenticated session to the NEA Server so the NEA Server knows the posture originated from the endpoint that authenticated. Such a strong binding between the posture's origin and the authenticating endpoint may be feasible so should be preferred by the NEA WG.
非準拠、アクティブなMITMはその姿勢情報を放棄するクリーンなエンドポイントをだますことが可能であり、MITMが正当な資格情報を持っている場合は、ないときに準拠した姿勢を持つようNEA Serverに表示されることができるかもしれません。例えば、非準拠MITMは接続でき、NEA Serverに認証し、NEA Serverは、姿勢情報を要求したとして、MITMは清潔なエンドポイントから同じ姿勢を要求することができます。きれいなエンドポイントが再評価を行うためにMITMを信頼し、要求された姿勢を共有する意思がある場合は、MITMは清潔なエンドポイントから必要な姿勢を取得し、NEA Serverに送信することができます。 MITM攻撃のこの形式に対処するために、NEAプロトコルはNEA Serverに姿勢情報と認証されたセッションの間の強い結合（暗号化）を提供する必要がありますので、NEA Serverは、姿勢が認証されたエンドポイントから発信さを知っています。姿勢の原点と認証エンドポイント間のこのような強い結合が実現可能であるので、NEA WGによって好まれるべきです。
Without message integrity protection, an attacker capable of intercepting a message might be capable of modifying its contents and causing an incorrect decision to be made. For example, the attacker might change the Posture Attributes to always reflect incorrect values and thus prevent a compliant system from joining the network. Unless the NEA Server could detect this change, the attacker could prevent admission to large numbers of clean systems. Conversely, the attacker could allow a malware infested machine to be admitted by changing the sent Posture Attributes to reflect compliant values, thus hiding the malware from the Posture Validator. The attacker could also infect compliant endpoints by sending malicious remediation instructions that, when performed, would introduce malware on the endpoint or deactivate security mechanisms.
メッセージの完全性保護がなければ、メッセージを傍受できる攻撃者は、その内容を変更して行われる不正な意思決定を引き起こすことができるかもしれません。例えば、攻撃者は、姿勢が常に間違った値を反映し、したがって、ネットワークに参加するに準拠したシステムを防ぐために、属性変更される可能性があります。 NEA Serverは、この変化を検出できない限り、攻撃者は、クリーンな多数のシステムへの入学を防ぐことができます。逆に、攻撃者がマルウェア出没機が送信姿勢従って姿勢バリデータからマルウェアを隠し、対応値を反映するように属性変更することによって認められる可能性があります。攻撃者はまた、行ったときに、エンドポイントでマルウェアを導入したり、セキュリティ・メカニズムを無効に悪意のある改善命令を送信することにより、対応のエンドポイントに感染することができます。
In order to protect against such attacks, the PT includes a requirement for strong integrity protection (e.g., including a protected hash like a Hashed Message Authentication Code (HMAC) [HMAC] of the message) so any change to a message would be detected. PA includes a similar requirement to enable end-to-end integrity protection of the attributes, extending the protection all the way to the Posture Validator even if it is located on another system behind the NEA Server.
このような攻撃から保護するために、PTは、（例えば、メッセージのハッシュメッセージ認証コード（HMAC）のような保護されたハッシュ[HMAC]を含む）強い完全性保護のための要件を含むようにメッセージに変更が検出されるであろう。 PAは、それがNEA Serverの背後にある別のシステム上に配置されている場合でも、すべての方法のPosture検証への保護を拡張し、属性のエンドツーエンドの完全性保護を有効にするには、同様の要件が含まれています。
It is important that integrity protection schemes leverage fresh secret information (not known by the attacker) that is bound to the authenticated session such as an HMAC using a derived fresh secret associated with the session. Inclusion of freshness information allows the parties to protect against some forms of message replay attacks using secret information from prior sessions.
（攻撃者によって知られていない）、完全性保護スキームを活用新鮮な秘密情報は、セッションに関連付けられた派生新鮮な秘密を使用してHMACとして認証されたセッションにバインドされていることが重要です。鮮度情報を含めることは、当事者が前のセッションからの秘密情報を使用して、メッセージリプレイ攻撃のいくつかのフォームから保護することができます。
An attacker might listen to the network, recording message dialogs or attributes from a compliant endpoint for later reuse to the same NEA Server or just to build an inventory of software running on other systems watching for known vulnerabilities. The NEA Server needs to be capable of detecting the replay of posture and/or the model must assure that the eavesdropper cannot obtain the information in the first place. For this reason, the PT protocol is required to provide confidentiality and replay prevention.
攻撃者は、メッセージダイアログを記録し、ネットワークを聴いたり、後で同じNEA Serverに再利用したり、単に既知の脆弱性のために見ている他のシステム上で実行されているソフトウェアのインベントリを構築するために準拠したエンドポイントからの属性があります。 NEA Serverは、盗聴者が最初の場所で情報を取得できないことを保証しなければならない姿勢及び/又はモデルのリプレイを検出可能である必要があります。このため、PTプロトコルは、機密性とリプレイ防止を提供するために必要とされます。
The cryptographic protection from disclosure of the PT, PB, or PA messages prevents the passive listener from observing the exchanged messages and thus prevents theft of the information for future use. However, an active attacker might be able to replay the encrypted message if there is no strong link to the originating party or session. By linking the encrypted message dialog to the authentication event and leveraging per-transaction freshness and keying exchanges, this prevents a replay of the encrypted transaction.
PT、PB、またはPAメッセージの開示から暗号化保護は、交換されるメッセージを観察から受動リスナーを防止し、従って、将来の使用のために情報の盗難を防止することができます。発信側またはセッションへの強いリンクが存在しない場合は、アクティブな攻撃者が暗号化されたメッセージを再生することができるかもしれません。認証イベントに暗号化されたメッセージダイアログをリンクし、トランザクションごとの鮮度を活用し、交流をキーイングすることで、これは暗号化されたトランザクションのリプレイを防ぐことができます。
This section doesn't claim to present an exhaustive list of attacks against the NEA reference model. Several types of attack will become easier to understand and analyze once the NEA WG has created specifications describing the specific selected technologies and protocols to be used within NEA. One such area is Denial of Service (DoS). At this point in time, it is not practical to try to define all of the potential exposures present within the NEA protocols, so such an analysis should be included in the Security Considerations sections of the selected NEA protocols.
このセクションでは、NEAの参照モデルに対する攻撃の完全なリストを提示することを主張しません。攻撃のいくつかのタイプを理解し、NEA WGは、NEA内で使用する特定の選択された技術やプロトコルを記述した仕様書を作成した後に分析することが容易になります。そのような地域は、サービス拒否（DoS）のです。この時点で、このような分析は、選択したNEAプロトコルのセキュリティの考慮事項のセクションに含まれるべきであるので、NEAプロトコル内に存在する潜在的なエクスポージャーの全てを定義しようとすることは現実的ではありません。
However, it is important that the NEA Server be resilient to DoS attacks as an outage might affect large numbers of endpoints wishing to join or remain on the network. The NEA reference model expects that the PT protocol would have some amount of DoS resilience and that the PA and PB protocols would need to build upon that base with their own protections. To help narrow the window of attack by unauthenticated parties, it is envisioned that NEA Servers would employ PT protocols that enable an early mutual authentication of the requesting endpoint as one technique for filtering out attacks.
停電が参加またはネットワーク上に残すことを希望するエンドポイントの多くに影響を与える可能性があるとして、しかし、NEA ServerはDoS攻撃への弾力的であることが重要です。 NEA参照モデルは、PTプロトコルは、DoS攻撃の回復力のいくつかの量を持っており、PAとPBプロトコルは、独自の保護とその基盤の上に構築する必要があるだろうということだろうと期待しています。認証されていない当事者による攻撃の窓を狭める支援するために、NEAサーバーが攻撃をフィルタリングするための1つの手法として要求するエンドポイントの初期の相互認証を有効にPTプロトコルを採用してしまうことが想定されます。
Attacks occurring after the authentication would at least come from sources possessing valid credentials and could potentially be held accountable. Similarly, NEA protocols should offer strong replay protection to prevent DoS-based attacks based on replayed sessions and messages. Posture assessment should be strongly linked with the Posture Transport authentications that occurred to assure the posture came from the authenticated party. Cryptographic mechanisms and other potentially resource intensive operations should be used sparingly until the validity of the request can be established. This and other resource/protocol based attacks can be evaluated once the NEA technologies and their cryptographic use have been selected.
認証後に発生した攻撃は、少なくとも有効な資格情報を所有する情報源から来ると、潜在的に責任を負うことができます。同様に、NEAプロトコルは、再生セッションとメッセージに基づいて、DOSベースの攻撃を防ぐために、強力な再生保護を提供する必要があります。ポスチャ評価は、強力な認証党から来た姿勢を確保するために発生した姿勢トランスポート認証とリンクする必要があります。要求の有効性が確立されるまで暗号メカニズムと他の潜在的にリソース集約的な操作は慎重に使用すべきです。 NEA技術とその暗号の使用が選択されていたら、これと他のリソース/プロトコルベースの攻撃を評価することができます。
While there are a number of beneficial uses of the NEA technology for organizations that own and operate networks offering services to similarly owned endpoints, these same technologies might enhance the potential for abuse and invasion of personal privacy if misused. This section will discuss a few of the potential privacy concerns raised by the deployment of this technology and offer some guidance to implementers.
同様に所有するエンドポイントにサービスを提供するネットワークを所有、運営組織のためのNEA技術の有益な用途の数がありますが誤って使用すれば、これらの同じ技術は、虐待や個人のプライバシーの侵害の可能性を向上させるかもしれません。このセクションでは、この技術の展開によって発生可能性のあるプライバシーの問題のいくつかを議論し、実装者にいくつかのガイダンスを提供します。
The NEA technology enables greater visibility into the configuration of an endpoint from the network. Such transparency enables the network to take into consideration the strength of the endpoint's security mechanisms when making access control decisions to network resources. However, this transparency could also be used to enforce restrictive policies to the detriment of the user by limiting their choice of software or prying into past or present uses of the endpoint.
NEA技術は、ネットワークからエンドポイントの設定に大きな可視性を可能にします。このような透明性は、ネットワークリソースへのアクセス制御を決定する際に考慮にエンドポイントのセキュリティ・メカニズムの強さを取るためにネットワークを可能にします。しかし、この透明度はまた、ソフトウェアの彼らの選択を制限またはエンドポイントの過去または現在の用途に詮索好きで、ユーザーの不利益に制限ポリシーを適用するために使用することができます。
The scope of the NEA WG was limited to specifying protocols targeting the use cases where the endpoints and network are owned by the same party or the endpoint owner has established a clear expectation of disclosure/compliance with the network owner. This is a familiar model for governments, institutions, and a wide variety of enterprises that provide endpoints to their employees to perform their jobs. In many of these situations, the endpoint is purchased and owned by the enterprise and they often reserve the right to audit and possibly dictate the allowable uses of the device. The NEA technologies allow them to automate the inspection of the contents of an endpoint and this information may be linked to the access control mechanisms on the network to limit endpoint use should the endpoint not meet minimal compliance levels.
NEA WGの範囲は、ネットワーク所有者と開示/コンプライアンスの明確な期待を確立しているエンドポイントとネットワークが同じパーティまたはエンドポイントの所有者によって所有されているユースケースを標的特定のプロトコルに限定されていました。これは、政府、機関にとって馴染みのモデル、およびそのジョブを実行するために、従業員へのエンドポイントを提供し、企業の多種多様です。これらの状況の多くでは、エンドポイントが購入され、企業が所有しており、彼らはしばしば、監査、おそらくデバイスの許容用途を決定する権利を留保します。 NEA技術は、彼らがエンドポイントの内容の検査を自動化することを可能にし、エンドポイントは、最小限のコンプライアンスレベルを満たしていなければならない。この情報は、エンドポイントの使用を制限するために、ネットワーク上のアクセス制御機構に連結させることができます。
In these environments, the level of personal privacy the employee enjoys may be significantly reduced subject to local laws and customs. However, in situations where the endpoint is owned by the user or where local laws protect the rights of the user even when using endpoints owned by another party, it is critical that the NEA implementation enable the user to control what endpoint information is shared with the network. Such controls imposed by the user might prevent or limit their ability to access certain networks or protected resources, but this must be a user choice.
これらの環境では、従業員が楽しんで個人のプライバシーのレベルが大幅に現地の法律や慣習に従う低減することができます。しかし、エンドポイントは、ユーザーが所有しているか、現地の法律が他の当事者が所有しているエンドポイントを使用した場合でも、利用者の権利を保護する状況では、NEAの実装は、エンドポイントの情報をと共有されている内容を制御することを可能にすることが重要です通信網。このようなコントロールは、防止または特定のネットワークまたは保護されたリソースにアクセスする能力を制限する可能性があるユーザーによって課されたが、これはユーザーの選択でなければなりません。
The NEA WG is not defining NEA Client policy content standards nor defining requirements on aspects of an implementation outside of the network protocols; however, the following guidance is provided to encourage privacy friendly implementations for broader use than just the enterprise-oriented setting described above.
NEA WGはNEA Clientポリシーの内容の基準を定めるものネットワークプロトコルの外側の実装の側面に関する要件を定義していません。ただし、以下のガイダンスは、前述しただけで、エンタープライズ向けの設定より広い使用のためのプライバシーフレンドリーな実装を奨励するために設けられています。
NEA Client implementations are encouraged to offer an opt-in policy to users prior to sharing their endpoint's posture information. The opt-in mechanism should be on a per-user, per-NEA Server basis so each user can control which networks can access any posture information on their system. For those networks that are allowed to assess the endpoint, the user should be able to specify granular restrictions on what particular types and specific attributes Posture
NEAクライアントの実装は、前にそのエンドポイントのポスチャ情報を共有するユーザーにオプトインポリシーを提供することが奨励されています。各ユーザは、ネットワークは、そのシステム上の任意の姿勢情報にアクセスできるかを制御できるようにオプトイン機構は、ユーザごと、毎NEAサーバ基づいなければなりません。エンドポイントを評価するために許可されているこれらのネットワークでは、ユーザーはどのような特定の種類および特定の属性姿勢に粒状の制限を指定することができるはずです
Collectors are allowed to disclose. Posture Validator implementations are discouraged from having the default behavior of using wild carded requests for posture potentially leading to overexposure of information (see section 9.2). Instead Posture Validators, by default, should only request the specific attributes that are required to perform their assessment.
コレクターは、開示することを許可されています。ポスチャ検証の実装は、野生を使用して、デフォルトの挙動を有するから推奨される（セクション9.2参照）、潜在的に情報の露出過度に至る姿勢の要求をカーディング。代わりに、姿勢バリデータは、デフォルトでは、唯一の自分の評価を行うために必要とされる特定の属性を要求する必要があります。
Requests for attributes that are not explicitly allowed (or specifically disallowed) to be shared should result in a user notification and/or log record so the user can assess whether the service is doing something undesirable or whether the user is willing to share this additional information in order to gain access. Some products might consider policy-driven support for prompting the user for authorization with a specific description of the posture information being requested prior to sending it to the NEA Server.
明示的に共有することを許可（または特に禁止）されていない属性の要求は、ユーザー通知の結果および/またはユーザがサービスは望ましくない、またはユーザーが、この付加的な情報を共有する意思があるかどうか何かをやっているかどうかを評価することができるようにレコードをログに記録しますアクセスを得るためです。一部の製品は、NEA Serverに送信する前に要求されている姿勢情報の具体的な説明と承認のためにユーザを促すための政策主導の支援を検討するかもしれません。
It is envisioned that the owner of the endpoint is able to specify disclosure policies that may override or influence the user's policies on the attributes visible to the network. If the owner disclosure policy allows for broader posture availability than the user policy, the implementation should provide a feedback mechanism to the user so they understand the situation and can choose whether to use the endpoint in those circumstances.
エンドポイントの所有者がオーバーライドしたり、ネットワークへの目に見える属性にユーザーの方針に影響を与えることが開示ポリシーを指定することが可能であることが想定されます。所有者の公開ポリシーは、ユーザーポリシーよりも広い姿勢の可用性を可能にした場合、彼らは状況を理解し、それらの状況でエンドポイントを使用するかどうかを選択することができますので、実装はユーザーにフィードバックメカニズムを提供する必要があります。
In such a system, it is important that the user's policy authoring interface is easy to understand and clearly articulates the current disclosure policy of the system including any influences from the owner policy. Users should be able to understand what posture is available to the network and the general impact of this information being known. In order to minimize the list of restrictions enumerated, use of a conservative default disclosure policy such as "that which is not explicitly authorized for disclosure is not allowed" might make sense to avoid unintentional leakage of information.
このようなシステムでは、ユーザーのポリシー・オーサリング・インターフェースが理解しやすいことが重要であると明確に所有者の方針から任意の影響を含めたシステムの現在の開示方針を明確に表現します。ユーザーは姿勢がネットワークに利用可能であり、この情報の全般的な影響は知られているかを理解することができるはずです。列挙された制限のリストは、そのような「明示的に開示を許可されていないことが許可されていない」として、保守的なデフォルトの開示ポリシーの使用を最小限にするために、意図しない情報の漏洩を防ぐために意味をなさないかもしれません。
NEA Server implementations should provide newly subscribing endpoints with a disclosure statement that clearly states:
NEA Serverの実装は明確に述べて開示文で、新たに加入したエンドポイントを提供する必要があります：
o What information is required
Oどのような情報が必要とされます
o How this information will be used and protected
Oこの情報を使用して保護されますどのように
o What local privacy policies are applicable
Oローカルどのようなプライバシーポリシーが適用されます
This information will empower subscribing users to decide whether the disclosure of this information is acceptable considering local laws and customs.
この情報は、この情報の開示は現地の法律や慣習を考慮し許容できるかどうかを判断するために、ユーザーをサブスクライブする権限を与えます。
One important issue in the design of the NEA reference model and protocols is enabling endpoints to disclose minimal information required to establish compliance with network policies. There are several models that could be considered as to how the disclosed attribute set is established. Each model has privacy related benefits and issues that should be considered by product developers. This section summarizes three potential models for how attribute disclosure might be provided within NEA products and some privacy implications potentially associated with each model.
NEAの参照モデルとプロトコルの設計における一つの重要な問題は、ネットワークポリシーへの準拠を確立するために必要な最低限の情報を開示するために、エンドポイントを有効にしています。開示された属性セットが確立されている方法として考えることができるいくつかのモデルがあります。各モデルは、製品開発者が考慮すべきプライバシー関連の利点と問題点があります。このセクションでは、属性の開示はNEA製品および潜在的に、各モデルに関連付けられているいくつかのプライバシーへの影響内で提供される可能性がありますどのようにするための3つの潜在的なモデルをまとめました。
The first model is easy to implement and deploy but has privacy and potentially latency and scalability implications. This approach effectively defaults the local policy to send all known NEA Posture Attributes when an assessment occurs. While this might simplify deployment, it exposes a lot of information that is potentially not relevant to the security assessment of the system and may introduce privacy issues. For example, is it really important that the enterprise know whether Firefox is being used on a system instead of other browsers during the security posture assessment?
最初のモデルは、実装し、導入が簡単であるが、プライバシーや潜在的に、待ち時間とスケーラビリティに影響します。査定が発生したときに、このアプローチが効果的にすべての既知のNEA姿勢を送信するために、デフォルトのローカルポリシーの属性。これは、展開を簡素化するかもしれないが、それは潜在的にシステムのセキュリティ評価に関連していないとプライバシーの問題を導入することができる多くの情報を公開しています。例えば、それは企業がFirefoxはセキュリティポスチャ評価時に代わりに他のブラウザのシステムで使用されているかどうかを知ることは本当に重要なのですか？
The second model involves an out-of-band provisioning of the disclosure policy to all endpoints. This model may involve the enterprise establishing policy that a particular list of attributes must be provided when a NEA exchange occurs. Endpoint privacy policy may filter this attribute list, but such changes could cause the endpoint not to be given network or resource access. This model simplifies the network exchange as the endpoint always sends the filtered list of attributes when challenged by a particular network. However, this approach requires an out-of-band management protocol to establish and manage the NEA disclosure policies of all systems.
第2のモデルは、すべてのエンドポイントに開示ポリシーの帯域外プロビジョニングを含みます。このモデルは、NEA交換が発生した場合、属性の特定のリストが提供されなければならないというポリシーを確立し、企業を含むことができます。エンドポイントのプライバシーポリシーは、この属性のリストをフィルタリングすることができるが、そのような変更は、エンドポイントがネットワークやリソースへのアクセスを与えられていない恐れがあります。特定のネットワークで挑戦したときにエンドポイントは、常に属性のフィルタリングされたリストを送信し、このモデルは、ネットワークの交換を簡素化します。しかし、このアプローチは、すべてのシステムのNEA開示方針を確立し、管理するためのアウトオブバンド管理プロトコルが必要です。
The third model avoids the need for pre-provisioning of a disclosure policy by allowing the NEA Server to specifically request what attributes are required. This is somewhat analogous to the policy being provisioned during the NEA exchanges so is much easier to manage. This model allows for the NEA Server to iteratively ask for attributes based on the values of prior attributes. Note, even in this model the NEA protocols are not expected to be a general purpose query language, but rather allow the NEA Server to request specific attributes as only the defined attributes are possible to request. For example, an enterprise might ask about the OS version in the initial message dialog and after learning the system is running Linux ask for a different set of attributes specific to Linux than it would if the endpoint was a Windows system. It is envisioned that this approach might minimize the set of attributes sent over the network if the assessment is of a complex system (such as trying to understand what patches are missing from an OS).
第3のモデルは、NEA Serverは、具体的な属性が必要とされているものを要求することを可能にすることによって開示政策の事前プロビジョニングの必要性を回避します。これには、管理する方がはるかに簡単ですNEA交換時にプロビジョニングされたポリシーにやや似ています。このモデルは、反復的に前に属性の値に基づく属性を求めるためにNEAサーバが可能になります。 NEAプロトコルは汎用クエリ言語であることが予想されていなくても、このモデルでは、注意してくださいではなく、としてのみ定義された属性を要求することが可能ですNEA Serverは、特定の属性を要求することを可能にします。例えば、企業は、最初のメッセージダイアログで、システムはLinuxがエンドポイントがWindowsシステムであれば、それは希望よりもLinuxの固有の属性の異なるセットを求める実行されている学習後のOSのバージョンについて尋ねるかもしれません。評価は複雑なシステムであれば、このアプローチは、（そのようなパッチは、OSから欠落しているかを理解しようとすると）ネットワークを介して送信される属性セットを最小化する可能性があることが想定されます。
In each model, the user could create a set of per-network privacy filter policies enforced by the NEA Client to prevent the disclosure of attributes felt to be personal in nature or not relevant to a particular network. Such filters would protect the privacy of the user but might result in the user not being allowed access to the desired asset (or network) or being provided limited access.
各モデルでは、ユーザーは属性の開示を防ぐために、NEAクライアントによって強制ごとのネットワークプライバシーフィルタポリシーのセットを作成することができ、特定のネットワークに関連する自然の中で、個人またはでないと感じました。このようなフィルタは、ユーザーのプライバシーを保護するが、所望の資産（またはネットワーク）へのアクセスが許可されるか、制限されたアクセスを提供されていないユーザーになる可能性があります。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F.、 "UTF8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
[802.1X]ローカルおよびメトロポリタンエリアネットワークのIEEE規格：ポートベースのネットワークアクセスコントロール、IEEE 802.1X STD-2001、2001年6月。
[CNAC] Cisco, Cisco's Network Admission Control Main Web Site, http://www.cisco.com/go/nac
[CNAC]シスコ、シスコのネットワークアドミッションコントロールのメインのWebサイト、http://www.cisco.com/go/nac
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[EAP] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[NAP] Microsoft, Network Access Protection Main Web Site, http://www.microsoft.com/nap
[NAP]マイクロソフト、ネットワークアクセス保護のメインのWebサイト、http://www.microsoft.com/nap
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[TCG] Trusted Computing Group, Main TCG Web Site, http://www.trustedcomputinggroup.org/
[TCG]トラステッド・コンピューティング・グループ、メインTCGのWebサイト、http://www.trustedcomputinggroup.org/
[TNC] Trusted Computing Group, Trusted Network Connect Main Web Site, https://www.trustedcomputinggroup.org/groups/network/
[TNC]トラステッド・コンピューティング・グループ、トラステッドネットワークコネクトメインのWebサイト、https://www.trustedcomputinggroup.org/groups/network/
The authors of this document would like to acknowledge the NEA Working Group members who have contributed to previous requirements and problem statement documents that influenced the direction of this specification: Kevin Amorin, Parvez Anandam, Diana Arroyo, Uri Blumenthal, Alan DeKok, Lauren Giroux, Steve Hanna, Thomas Hardjono, Tim Polk, Ravi Sahita, Joe Salowey, Chris Salter, Mauricio Sanchez, Yaron Sheffer, Jeff Six, Susan Thompson, Gary Tomlinson, John Vollbrecht, Nancy Winget, Han Yin, and Hao Zhou.
、ケビンAmorin、Parvez Anandam、ダイアナアロヨ、ウリブルーメンソール、アランDeKok、ローレンジルー：この文書の著者は、この仕様の方向に影響を与え、以前の要件と問題文の文書に貢献してきたNEAワーキンググループのメンバーを確認したいと思いますスティーブ・ハンナ、トーマスHardjono、ティムポーク、ラヴィSahita、ジョーSalowey、クリス・ソルター、マウリシオサンチェス、ヤロンシェファー、ジェフ・六、スーザン・トンプソン、ゲーリー・トムリンソン、ジョンVollbrecht、ナンシー・ウィンゲット、漢陰、そしてハオ周。
Authors' Addresses
著者のアドレス
Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad, CA 92009 USA Phone: +1 760 438-5656 EMail: Paul_Sangster@symantec.com
ポール・サングスターシマンテックコーポレーション6825シトリン博士カールスバッド、CA 92009 USA電話：+1 760 438から5656 Eメール：Paul_Sangster@symantec.com
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
Hormuzd Khosraviインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA電話：+1 503 264 0334 Eメール：hormuzd.m.khosravi@intel.com
Mahalingam Mani Avaya Inc. 1033 McCarthy Blvd. Milpitas, CA 95035 USA Phone: +1 408 321-4840 EMail: mmani@avaya.com
Mahalingamの宝石Avyではイン。 1033 Mkkarthy Balwd。 95035 408321-4840 1電話へのメールのMilpits、：म्मानी@ावय.कॉम
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 Phone: +1 408 526-8168 EMail: kaushik@cisco.com
Kaushikによるナラヤンシスコシステムズ株式会社10西タスマン・ドライブサンノゼ、CA 95134電話：+1 408 526から8168 Eメール：kaushik@cisco.com
Joseph Tardo Nevis Networks 295 N. Bernardo Ave., Suite 100 Mountain View, CA 94043 USA EMail: joseph.tardo@nevisnetworks.com
ジョセフTardoネイビスネットワーク295 N.ベルナルド・アベニュー、スイート100マウンテンビュー、CA 94043 USA電子メール：joseph.tardo@nevisnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。