[要約] RFC 5209は、ネットワークエンドポイント評価（NEA）の概要と要件について説明しています。このRFCの目的は、ネットワーク上のエンドポイントのセキュリティ評価を行うためのフレームワークを提供することです。
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
ネットワークエンドポイント評価（NEA）：概要と要件
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 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は通常、ネットワークインフラストラクチャへのシステムの構成を観察およびレポートする要求エンドポイントで実行されている特別なクライアントソフトウェアの使用を伴います。インフラストラクチャには、エンドポイントの構成情報をネットワークコンプライアンスポリシーと比較し、ネットワークおよびアプリケーションアクセスに関する決定を下す適切な認証エンティティに結果を提供できる対応する検証ソフトウェアがあります。一部のエンドポイントは、NEAクライアントソフトウェア（プリンターなど）を実行できない場合や、構成に関する情報を共有したくない場合があります。この状況は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と同様のアーキテクチャは、しばらくの間業界に存在しており、出荷製品に存在していますが、適切な相互運用性を提供していません。このようなアーキテクチャの例には、信頼性の高いコンピューティンググループの信頼できるネットワークConnect [TNC]、Microsoftのネットワークアクセス保護[NAP]、CiscoのCisco Network Andimince Control [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クライアントとNEAサーバー間のコンプライアンス情報を通信するために使用できる標準プロトコルを開発しています。このドキュメントは、NEAのコンテキストを提供します。用語、適用可能性、問題ステートメント、参照モデル、およびユースケースを含みます。次に、NEAクライアントと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 NOT - indicates something absolutely prohibited
そうでないでください - 絶対に禁止されている何かを示します
SHOULD - indicates a strong recommendation of a desired result
すべき - 望ましい結果の強力な推奨事項を示します
SHOULD NOT - indicates a strong recommendation against a result
そうすべきではありません - 結果に対する強い推奨事項を示します
MAY - indicates a willingness to allow an optional outcome
5月 - オプションの結果を許可する意欲を示します
Lower case use of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" carry their normal meaning and are not subject to these definitions.
「必須」、「「必須」」、「そうでなければ」、「すべき」、「はない」、および「「必要」、および「」の使用は、通常の意味を持ち、これらの定義の対象ではありません。
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サーバーによって日付および署名され、そのエンドポイントが一連のポリシーへのコンプライアンスを主張するためにそれを再利用できるようにする特定のエンドポイントに特に発行される場合があります。NEAサーバーは、姿勢情報を取得する代わりにこれを受け入れる可能性があります。
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 構成またはプロパティ情報のリクエスト（要求属性）、
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.
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クライアントから要求された姿勢情報を識別する属性。たとえば、要求属性は、エンドポイントのオペレーティングシステムのバージョン情報を要求しているNEAサーバーからのリクエストメッセージに含まれる属性である場合があります。
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ポリシーに準拠しているかどうかを説明する属性。結果属性は、評価の終了時にNEAサーバーによって通常、エンドポイントが準拠していると見なされるかどうかを示します。これらの属性の1つ以上を使用して、全体的なグローバルな評価決定に加えて、より詳細な機能レベルの決定を伝えることができます。
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.
NEAワーキンググループの優先順位は、参照モデルの高レイヤーで標準プロトコルを開発することです（セクション5を参照）：Positure属性プロトコル（PA）およびPositure Broker Protocol（PB）。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),
o NEAクライアントまたはサーバーのリモート部分と通信するために使用されるプロトコル（例：リモートコレクターや姿勢のバリデーター）、
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),
o NEAクライアントが他のエンドポイントに姿勢を提供するサポート（たとえば、NEAクライアントなしでエンドポイントの姿勢を提供する侵入検知システム（IDS）のNEAクライアント）、
o Defining the set of events or situations that might trigger a NEA Client or NEA Server to request an assessment,
o NEAクライアントまたは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評価ポリシーを課している会社のために働いています。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]を使用するなど、有線およびワイヤレスLANアクセス、IPSEC [IPSEC]、またはリモートアクセスなど、さまざまなネットワークに接続する方法（ただし、これらに限定されない）を提供するために使用できます。セキュアソケットレイヤー（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テクノロジーの2番目の重要な使用です。これは、以前に関連していたエンドポイントを実行できる追加の評価を可能にするためです。ネットワークコンプライアンスポリシーやエンドポイントの姿勢が時間とともに変化する可能性があるため、これが必要になる場合があります。最初に、ネットワークに参加したときに準拠していると評価されたシステムは、変更が発生した後にコンプライアンスがなくなる可能性があります。たとえば、ユーザーがポリシーで必要なセキュリティ保護（ホストベースのファイアウォールなど）を無効にする場合、またはファイアウォールパッチが発行された後にファイアウォールが非準拠になり、ネットワークポリシーが変更されてパッチを要求する場合、再評価が必要になる場合があります。
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
NEAクライアントNEAサーバー
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サーバーの発見のためのメカニズムは含まれていません。NEAクライアントとNEAサーバーは、互いに届くことができる情報で構成されていることが期待されています。構成を参照して通信チャネルを確立する特定の方法は、NEA参照モデルの範囲外であり、Positure Transport（PT）プロトコルなどの候補プロトコルの仕様でカバーする必要があります。
The NEA Client is resident on an endpoint device and comprised of the following functionality:
NEAクライアントはエンドポイントデバイスに居住しており、次の機能で構成されています。
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クライアントは、クライアントのローカル動作ドメインの構成を説明する属性のリクエストに応答し、ポリシーに準拠する方法の潜在的な修復指示を含む評価結果を処理する責任があります。NEAクライアントは、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クライアントは、実行の領域の姿勢を報告する責任がありますが、この情報は、エンドポイント上の複数のドメインの姿勢を表すために他の局所メカニズムによって集約される可能性があります。このような姿勢集約メカニズムは、この仕様の焦点の外にあります。
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スコープから外れている）を欠いているエンドポイントまたはNEAサーバーが必要とする属性を提供しないことを選択することは、非準拠と見なされる可能性があります。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サーバーからの要求属性の姿勢情報の要求に応答する責任があります。姿勢コレクターは、結果属性の評価決定と修復属性の修復命令を処理する責任もあります。単一のNEAクライアントは、エンドポイントの特定の機能のための標準および/またはベンダー固有の姿勢属性を収集できるいくつかの姿勢コレクターを持つことができます。典型的な例には、オペレーティングシステム（OS）バージョンとパッチレベル、アンチウイルスソフトウェア、およびホストベースの侵入検知システム（IDS）やファイアウォールなどのエンドポイント上のセキュリティメカニズムに関する情報を提供する姿勢コレクターが含まれます。
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つ以上の識別子に関連付けられます。姿勢ブローカークライアントは、これらの識別子を使用して、メッセージをこのコレクターにルーティングします。識別子は、動的である可能性があります（登録時に実行時に姿勢ブローカークライアントによって生成される）またはより静的（たとえば、インストール時に姿勢コレクターに事前に割り当てられ、登録中に姿勢ブローカークライアントに渡されます）またはコレクターが受信したい属性メッセージの関数（例：サブスクリプションのメッセージタイプ）。
The NEA model allocates the following responsibilities to the Posture Collector:
NEAモデルは、姿勢コレクターに次の責任を割り当てます。
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.
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サーバーに返します。姿勢ブローカークライアントは、評価に関与する姿勢コレクターから取得したPAメッセージを使用して、1つ以上のPBメッセージを構築します。PB応答メッセージに増殖した姿勢コレクター応答（PAメッセージ）の数量と順序付けは、基礎となるネットワーク輸送のポリシーや特性（例えばMTU）を含む多くの要因に基づいて姿勢ブローカークライアントによって決定できます。。特定のNEAクライアントには、姿勢ブローカークライアントが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.
Posture Brokerクライアントは、Possure Broker Serverからのグローバル評価決定も処理し、ユーザーと対話して、必要な修復手順でグローバル評価の決定と支援を伝えることができます。
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サーバーと関連する姿勢コレクターの間の多重化および脱30を除外する属性メッセージ。
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.
o NEAサーバーが送信したグローバル評価決定およびその他のユーザーメッセージに関するユーザー通知を提供します。
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.
姿勢トランスポートクライアントは、NEAクライアントとNEAサーバーの間のメッセージダイアログについて、NEAサーバーとの信頼できる通信チャネルを確立する責任があります。さまざまな輸送プロトコル（802.1x、VPNなど）をサポートする特定のNEAクライアントに複数のPositure Transportクライアントがいる可能性があります。特定の姿勢輸送クライアントは、特定のネットワークに使用する適切なPosure Transport Serverのアドレスで構成される場合があります。
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.
o NEAサーバーへの通信チャネルの開始と維持。姿勢輸送クライアントは、レイヤー2またはレイヤー3プロトコルになる可能性のある基礎となるキャリアの詳細を隠します。
o Providing cryptographic protection for the message dialog between the NEA Client and NEA Server.
o NEAクライアントとNEAサーバーの間のメッセージダイアログに暗号化保護を提供します。
The NEA Server is typically comprised of the following NEA functionality:
NEAサーバーは通常、次のNEA機能で構成されています。
o Posture Validator(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.
Positure Validatorsは、Positure Broker Serverから別のサーバーに配置されている場合があり、Posure Broker ServerがローカルおよびリモートPositure検証装置の両方に対処する必要があります。
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.
姿勢バリーターは、対応する姿勢コレクターからの姿勢属性を処理する責任があります。姿勢バリエーターは、1つ以上の姿勢コレクターからの姿勢属性を処理でき、その逆も同様です。Positure Validatorは、エンドポイントの1つ以上の機能（例：ウイルス対策ソフトウェア）の姿勢評価を実行し、結果を作成し、必要に応じて修復命令を作成するか、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).
各姿勢バリーターは、PAメッセージの宛先として指定できるようにする1つ以上の識別子に関連付けられます。Positure Broker Serverは、この識別子を使用して、メッセージメッセージをこのバリデーターにルーティングします。この識別子は、動的である可能性があります（登録時に実行時に姿勢ブローカーサーバーによって生成される）またはより静的（たとえば、インストール時に姿勢検証装置に事前に割り当てられ、登録中に姿勢ブローカーサーバーに渡されます）または属性メッセージの関数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.
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.
-
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:
o 姿勢評価の結果を姿勢コレクターに伝える。この属性メッセージには以下が含まれます。
- Result Attributes that communicate the posture assessment result. - Remediation Attributes that communicate the remediation instructions to the Posture Collector.
- 姿勢評価の結果を伝える結果属性。 - 修復命令を姿勢コレクターに伝える修復属性。
o Monitoring out-of-band updates that trigger reassessment and require notifications to be sent to the Posture Broker Server.
o 再評価をトリガーし、姿勢ブローカーサーバーに通知を送信する必要があるバンド外の更新を監視します。
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.
上記のリストは、姿勢バリーターの責任の可能性に関するモデルの見解について説明しています。これは、各Possure Validatorの実装がサポートしなければならないものの一連の要件ではなく、Posure 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).
姿勢ブローカーサーバーは、属性メッセージ用のマルチプレクサとde-multiplexerとして機能します。Positure Broker Serverは、NEAクライアントから受信したPBメッセージを解析し、それらを関連するPosure Validatorsに渡すPAメッセージにそれらを解除します。姿勢ブローカーサーバーは、PAメッセージ（例えば、（a）要求属性を含むメッセージ）を1つ以上のPBメッセージにマルチプレックスし、姿勢輸送プロトコルを介してNEAクライアントに送信します。姿勢バリデーター応答（PAメッセージ）の数量と順序付けと、PB応答メッセージに多重化されたグローバル評価決定は、基礎となるネットワーク輸送のポリシーまたは特性を含む多くの要因に基づいて姿勢ブローカーサーバーによって決定できます（例：MTU、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.
Positure Broker Serverは、さまざまな姿勢バリーターからの個々の姿勢評価結果に基づいて、グローバル評価の決定を計算する責任があります。このグローバル評価決定は、PBメッセージ内の結果属性でNEAクライアントに送り返されます。特定のNEAサーバーには1つの姿勢ブローカーサーバーがあり、このPossure Broker ServerはすべてのローカルおよびリモートPositure Validatorを処理します。
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メッセージでPosure Brokerクライアントに送信されます。
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.
Positure Transport Serverは、NEAクライアントとNEAサーバーの間のメッセージダイアログについて、NEAクライアントとの信頼できる通信チャネルを確立する責任があります。さまざまな輸送プロトコルをサポートするために、特定のNEAサーバーに複数の姿勢輸送サーバーがある可能性があります。特定の姿勢トランスポートサーバーは、通常、いくつかのPossure Transportクライアントからのリクエストを処理し、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.
o 潜在的に複数のNEAクライアントとのコミュニケーションチャネルの開始と維持。
o Providing cryptographic protection for the message dialog between the NEA Client and NEA Server.
o NEAクライアントとNEAサーバーの間のメッセージダイアログに暗号化保護を提供します。
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参照モデルには、ネットワーク全体で属性の交換を可能にする3つの層状プロトコル（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.
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は、Posture Brokerクライアントとサーバーが使用するための追加の種類のメッセージを運ぶために使用できます（たとえば、言語などのユーザー優先インターフェイス設定に関する情報）。
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は、NEAクライアントとPBプロトコルによって生成されたメッセージの運搬を担当するNEAサーバーの間のトランスポートプロトコルです。ネットワーク接続要求中またはネットワーク接続後のPTプロトコル輸送（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クライアントとNEAサーバーは、基礎となるネットワークプロトコルのプロパティに基づく評価の前に、潜在的に制約されている状況が存在する場合を検出できるはずです。この情報を使用して、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プロトコル選択プロセスは、PAおよびPBの展開ニーズに基づいて特定のPTと基礎となるプロトコルのセットを選択することの影響を考慮する必要があります。PTとPBの前にPAとPBが選択されるため、PAとPBのニーズが既知になります。特定の基礎となるプロトコルスタックは、ネットワーク接続中に適切な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プロトコルは、姿勢コレクターと姿勢バリデーターの間の属性の交換を担当します。PBプロトコルは、姿勢ブローカーサーバーからのグローバル評価決定属性を伝達する場合があります。属性は、事実上、姿勢評価の予約された単語「名詞」です。NEAサーバーは、対応する属性を持つ情報のみを要求することができるため、どのタイプの姿勢を取得できるかを制限します。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が属性をどのように指定するかを決定することを意図していません。
5.3.1. Attributes Normally Sent by NEA Client:
5.3.1. 通常、NEAクライアントによって送信される属性：
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 姿勢属性 - システムの特定の側面に関する情報を報告するために送信される属性と値。これらの属性は通常、NEAサーバーからの要求属性に応じて送信されます。たとえば、姿勢属性のセットは、ホストベースのファイアウォールのステータスを記述する場合があります（たとえば、実行、ベンダー、バージョンなど）。NEAサーバーは、このタイプの属性をポリシーと比較する決定に基づいています。
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サーバーに送信する必要性を回避することを期待して、ポリシーへの最近の事前のコンプライアンスを記載する属性。アサーションの例には、（a）NEAサーバー提供属性（STATE）が含まれます（例：エンドポイントへの不透明、署名、特定の結果を記載するタイムスタンプ項目）または（b）NEAサーバーが状態を見つけるために使用するNEAクライアントID情報以前の決定について（システムに縛られたCookieなど）。これらは、姿勢属性の代わりに、またはそれに加えて返される可能性があります。
5.3.2. Attributes Normally Sent by NEA Server:
5.3.2. 通常、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 要求属性 - NEAサーバーが望む特定の姿勢情報を定義する属性。これらの属性は、姿勢コレクターが各属性に対応する特定の値で（ローカルポリシーの制限の対象となる）（現地のポリシー制限の対象となる）テンプレートを効果的に形成する可能性があります。結果の属性は、通常、NEAクライアントからの姿勢またはアサーション属性です。
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クライアントとそのユーザーに説明する属性エンドポイントを更新してNEAサーバーポリシーに準拠する方法。これらの属性は、グローバル評価の決定がエンドポイントが現在準拠していないということであったときに送信されます。修復属性と結果属性は両方ともNEAサーバー属性メッセージ内に存在する可能性があります。
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サーバーアサーションを含む属性。詳細については、セクション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:
ユースケースを2つのカテゴリに広く分類し、それぞれに独自のトリガーイベントセットがあります。
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サーバーがネットワークまたはサービスにアクセスする前にエンドポイントの姿勢を評価できるため、特に興味深いものです。
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.
さまざまな種類のエンドポイントアクションが、このクラスの評価につながる可能性があります。たとえば、高度に保護されたネットワークサービス（金融またはHRアプリケーションサーバーなど）にアクセスしようとするエンドポイントによって評価がトリガーされる可能性があります。よく知られている例には、コンプライアンスポリシーを満たすためにシステムを要求するネットワークへの入場を要求することが含まれます。この例については、次のセクションで詳しく説明します。
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従業員は、Wired Enterprise Networkに参加するリクエストを生成する彼のオフィスデスクトップコンピューターの休暇から戻ってきました。ネットワークのセキュリティポリシーでは、デスクトップのセキュリティ機能が有効かつ最新のものであるかどうかを判断するために、システムが姿勢情報を提供する必要があります。デスクトップは、パッチ、ファイアウォール、アンチウイルス姿勢情報を送信します。NEAサーバーは、システムに深刻な脆弱性を修正するように設計された最近のセキュリティパッチがないことを決定し、システムは制限付きアクセスネットワークに配置されています。デスクトップは、必要なパッチをダウンロードしてインストールするために、提供された修復手順に従います。その後、デスクトップが再びネットワークに参加するよう要求し、今回は完全な評価の後、エンタープライズネットワークへの完全なアクセスが提供されます。
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サーバーのPosure 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. コンプライアンスポリシーに基づいて、Positure Broker Serverは、オペレーティングシステムパッチ、ホストベースのファイアウォール、およびウイルス対策Posure Validatorsに連絡して、必要な姿勢を要求します。各Possure 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.
5. The Posture Transport Client receives the message from the NEA Server and passes it to the Posture Broker Client for message delivery.
5. 姿勢トランスポートクライアントは、NEAサーバーからメッセージを受信し、メッセージ配信のためにPossure Brokerクライアントに渡します。
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. 関係する各姿勢コレクターは、地元のプライバシーポリシーを参照して、どの情報を開示することが許可されているかを決定し、Posure Brokerクライアントに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. Posure Brokerクライアントは、これらのPAメッセージを単一のPBメッセージに集約し、Posure Transport Clientからサーバーセッションを使用してPossure Broker Serverに送信します。
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. Positure Transport Serverは、メッセージを測定し、対応するPosure Validatorに適切な属性を送信するPsure Broker ServerにPBメッセージを提供します。
10. Each Posture Validator compares the values of the attributes it receives with the expected values defined in its policy.
10. 各Possure 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. アンチウイルスとファイアウォールの姿勢バリデーターは、デスクトップコンピューターが準拠している姿勢ブローカーサーバーに属性を返しますが、オペレーティングシステムのパッチ姿勢検証ターは非準拠を返します。オペレーティングシステムのパッチPOSURE BALIBATORは、コンプライアンスの結果を示す属性に加えて、修復命令を含む属性を含む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メッセージを集約し、Posure Transport ServerおよびPossure Transportクライアントを介してPosure Brokerクライアントに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. 今回は、それぞれ姿勢バリーター（オペレーティングシステムパッチPosure検証ターを含む）が準拠したステータスを返し、Positure Broker Serverはグローバルな成功を示す準拠した結果を返します。
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 EndPointは、姿勢情報を含む属性を送信します
o NEA Server sends remediation instructions
o NEAサーバーは修復手順を送信します
o NEA Client causes a reassessment after remediation
o NEAクライアントは、修復後に再評価を引き起こします
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サーバーは、システムの初期評価を実行し、それが準拠していると判断しますが、アンチウイルス保護は使用されていません。生徒は、システムのアンチウイルスソフトウェアがオフになっていることを示すアドバイザリー対応を受け取りますが、それ以外の場合は学校のポリシーに準拠しています。学生はアンチウイルスソフトウェアをオンにし、スキャンを開始し、完了時に彼女の作業でシステムを信頼することを決定します。
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. 学生は、端末室のコンピューターシステムで姿勢ブローカークライアントをトリガーして、姿勢評価を開始します。
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. 姿勢ブローカーサーバーは新しいセッションを検出し、ポリシーに相談して、評価に関与する姿勢バリエーターを決定します。姿勢ブローカーサーバーは、ウイルス対策姿勢検証装置を含むいくつかの姿勢バリエーターを使用することにしました。
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. 姿勢ブローカーサーバーは、Posure Validatorsからの各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. Positure Transport ServerはPBメッセージをPositure Transportクライアントに送信し、Positure Brokerクライアントに渡されます。
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. 姿勢コレクターは、サーバーと共有する情報を決定するためにプライバシーポリシーを参照してください。許容される場合、コレクターはそれぞれ、姿勢ブローカークライアントに要求された姿勢を含む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. 姿勢ブローカークライアントは、返されたPAメッセージをPBメッセージに集約し、Possure Transport Serverに送信するためにPossure Transportクライアントに渡します。
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メッセージに含まれる姿勢を含む属性がポリシーに準拠しているかどうかを決定し、姿勢評価の決定を姿勢ブローカーサーバーに返します。この場合、アンチウイルスの姿勢検証装置は、ウイルス対策ソフトウェアが実行されていないため、非準拠の結果を示す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. 姿勢ブローカーサーバーは、すべてのバリデーターの評価結果に基づいて全体的なコンプライアンス決定を決定し、グローバル評価決定とアンチウイルスバリエーターのPAメッセージを表す属性を含むPBメッセージを送信します。この場合、グローバル評価の決定は、姿勢ブローカーサーバーポリシーがシステムの適切にパッチが適切にパッチングされ、ファイアウォールの実行が長く実行されないようにしたため、システムが準拠していることを示しています（バリューターの結果にもかかわらず）（これは、他の姿勢バリデーターによるとそうでした）。
13. The Posture Transport Server sends the PB message to the Posture Transport Client that provides the message to the Posture Broker Client.
13. Positure Transport Serverは、Posure Brokerクライアントにメッセージを提供するPositure Transportクライアントに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. ターミナルルームコンピューターの姿勢ブローカークライアントは、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.
15. 姿勢ブローカークライアントは、PAメッセージを提供し、ユーザーと対話するためにユーザーと対話するアンチウイルスをオンにする方法を説明するために、局所保護を改善する方法を説明する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. 今回は、アンチウイルスの姿勢バリデーターが成功状況を返し、Posure Broker Serverは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. 姿勢ブローカーのクライアントは、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に含まれる（準拠）グローバル評価の決定は、修復のためのアドバイザリーの属性セットを含むPAメッセージを含むPAメッセージを含む。
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.
このユースケースにより、エンドポイント上のソフトウェアまたはユーザーがシステムの再評価が必要であると判断できます。以前に報告された姿勢の変更、潜在的に疑わしい行動の検出、またはシステムが最新のポリシーと比較してその状態を定期的に投票できるようにすることを含む、このような再評価が有益である可能性があるさまざまな理由があります。
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.
企業のHR部門内のデスクトップには、セキュリティ慣行の貧弱な歴史と最終的な妥協があります。HR部門の管理者は、各デスクトップにソフトウェアを展開して、セキュリティ保護メカニズムの使用を保証することを監視することを決定します。ある日、HRの人が誤ってデスクトップファイアウォールをオフにします。監視プロセスは、ファイアウォールの欠如を検出し、NEAサーバーに連絡してファイアウォールコンプライアンスの再評価を要求します。NEAサーバーは、ネットワークにとどまるためにファイアウォールを再アクティブ化する必要があるという決定を返します。NEAクライアントは、ユーザーへの決定とファイアウォールを再アクティブ化する方法について説明します。HRの人はファイアウォールを再起動し、ネットワークに再加入するリクエストを開始します。
The following describes the message flows through the NEA reference model for the HR department example:
以下は、HR部門の例の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. 通常、姿勢コレクターとして機能する可能性のあるデスクトップ監視ソフトウェアは、姿勢ブローカークライアントを引き起こし、姿勢の再評価を開始します。Posture Brokerクライアントは、デスクトップファイアウォールが無効になっていることを示すPAメッセージを含むPBメッセージを作成します。
2. The Posture Broker Client sends the PB message to the Posture Broker Server.
2. 姿勢ブローカークライアントは、PSURE Broker ServerにPBメッセージを送信します。
3. The Posture Transport Client sends the PB message to the Posture Transport Server over the PT protocol.
3. Positure Transportクライアントは、PTプロトコルを介してPB Messageを姿勢輸送サーバーに送信します。
4. The Posture Broker Server receives the PB message and forwards the PA message to the firewall Posture Validator for evaluation.
4. Positure Broker ServerはPBメッセージを受信し、PAメッセージを評価のためにファイアウォールPosure Validatorに転送します。
5. The firewall Posture Validator determines that the endpoint is no longer compliant because its firewall has been disabled.
5. ファイアウォールの姿勢バリーターは、ファイアウォールが無効になっているため、エンドポイントが準拠していないと判断します。
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. Positure 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. Posure Validatorは、PAメッセージを姿勢評価結果と姿勢ブローカーサーバーに伝え、NEAクライアントに返信します。
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. 姿勢ブローカーサーバーは、非遵守のグローバル評価決定やファイアウォールPosure Validatorからの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. 姿勢トランスポートサーバーは、PBメッセージをPossure Transportクライアントに輸送し、Possure Brokerクライアントに渡されます。
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. 姿勢ブローカークライアントは、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が繰り返されます。今回は、ファイアウォール姿勢バリデーターがエンドポイントが準拠しており、成功した姿勢評価の決定を返します。
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サーバーは、特定のファイアウォール指向の姿勢属性を要求します
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サーバーは、次のようにトリガーされる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時までにインストールすることを要求します。このポリシーの変更により、NEAサーバーは再評価を要求して、どのエンドポイントが影響を受け、パッチに欠けているかを決定します。マーケティング従業員のラップトップは再評価され、パッチが必要になると決心しています。修復勧告が送信され、従業員に提示され、パッチの取得方法と午後5時までにインストールする必要があることを説明します。マーケティングの従業員はすぐにパッチをダウンロードしてインストールし、すべてのパッチがインストールされるという主張を取得します。
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のオペレーティングシステムパッチ姿勢検証ターは、このポリシーの変更を認識し、使用中のOSパッチを説明する属性を要求するPAメッセージを作成し、姿勢ブローカーサーバーをトリガーして、ネットワークに接続されたすべてのエンドポイントの姿勢の再評価を開始します。
4. The Posture Broker creates a PB message that includes the PA message from the operating system patch Posture Validator.
4. 姿勢ブローカーは、オペレーティングシステムパッチPosure ValidatorからのPAメッセージを含むPBメッセージを作成します。
5. The Posture Broker Server gradually establishes a session with each available NEA Client.
5. Posture Broker Serverは、利用可能な各NEAクライアントとのセッションを徐々に確立します。
6. The Posture Broker Server sends the PB message to the Posture Broker Client.
6. Positure Broker Serverは、PSURE BrokerクライアントにPBメッセージを送信します。
7. The Posture Transport Server carries the PB message to the Posture Transport Client over the PT protocol.
7. 姿勢トランスポートサーバーは、PTプロトコルを介してPSURE Transportクライアントに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. Posture Transport Clientは、PBメッセージをPossure Transport Serverに輸送し、Positure Broker Serverに渡されます。
12. The Posture Broker Server receives the PB message and delivers the PA message to the operating system patch Posture Validator.
12. Posture Broker ServerはPBメッセージを受信し、PAメッセージをオペレーティングシステムパッチPosure Validatorに配信します。
13. The operating system patch Posture Validator extracts the attributes describing the current OS patches from the PA message and uses the values to determine whether the endpoint is compliant with the new policy. The Posture Validator determines that the endpoint is not compliant since it does not have the new OS patches installed.
13. オペレーティングシステムパッチPosure Validatorは、PAメッセージから現在のOSパッチを記述する属性を抽出し、値を使用してエンドポイントが新しいポリシーに準拠しているかどうかを判断します。Posure 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. 姿勢バリーターは、姿勢評価の決定を示す属性を含むPAメッセージを生成します。これは非準拠であり、エンドポイントが必要なOSパッチをダウンロードできるように修復命令を含む属性です。
15. The Posture Validator communicates the posture assessment result to the Posture Broker Server along with its PA message.
15. Positure Validatorは、PAメッセージとともにPosure Broker Serverに姿勢評価の結果を伝えます。
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. 姿勢ブローカーサーバーは、グローバルな評価決定を生成し、決定とオペレーティングシステムパッチPosure 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. 姿勢トランスポートサーバーは、PBメッセージをPossure Transportクライアントに輸送し、Possure Brokerクライアントに渡されます。
18. The Posture Broker Client processes the Result Attribute received from the NEA Server and displays the non-compliance decision to the user.
18. 姿勢ブローカークライアントは、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クライアントは、上記の多くのステップを繰り返すオペレーティングシステムパッチの再評価をトリガーします。今回、ステップ13では、オペレーティングシステムのパッチPosure Validatorは、マーケティング従業員のラップトップが準拠していると判断します。最新のポリシーへのPATCHコンプライアンスを主張する属性の再利用可能な（例えば、署名および日付）セットを返します。これらの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サーバーは徐々に再評価をトリガーして、パッチアドバイザリーへのコンプライアンスを決定します。オペレーティングシステムパッチ姿勢コレクターが姿勢情報の要求を受信すると（上記のステップ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.
24. オペレーティングシステムのパッチPosure Validatorがアサーションを含むPAメッセージを受信すると、特定の姿勢ではなく本物で許容可能なアサーションであると判断できます。準拠の姿勢評価の決定を返し、ラップトップがネットワーク上に残ることを可能にします。
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クライアントは、パッチがインストールされている姿勢の代わりに再利用可能なアサーション属性を提出します
o NEA Server capable of recognizing previously issued assertion attributes are sufficient instead of posture
o 以前に発行されたアサーション属性を認識できるNEAサーバーは、姿勢ではなく十分です
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.
たとえば、暗号化セキュリティ保護を各プロトコルから利用できるようにするために要件（必要、すべき、または必要な、または可能性があります）が存在する可能性がありますが、これは、環境を他の人に提供するために環境を考える場合、展開者がすべてまたはそれらのすべてを使用する必要はありません。十分な保護。
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クライアントとNEAサーバー間の複数のラウンド旅行をサポートする必要があります。
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クライアントとNEAサーバーの両方が、必要に応じて姿勢評価または再評価を開始する方法を提供する必要があります。
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プロトコルは、さまざまなネットワークプロトコル環境（EAP/802.1x、TLS、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2））でPAプロトコルを変更せずに動作できるように、トランスポート独立インターフェイスを提供する必要があります。
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クライアントとNEAサーバー間の多数の属性メッセージの効率的な輸送をサポートする必要があります。
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プロトコルは、UTF-8形式[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クライアントとNEAサーバーは、利用可能なPTプロトコルの制限を認識し、適応させることができなければなりません。たとえば、PAおよびPBの動作に影響を与える可能性のあるいくつかのPTプロトコル特性には、以下の制限が含まれます。NEA接続、メッセージまたは完全な評価の最大データサイズ、ラウンドトリップの数の上限、および注文（デュプレックス）交換されたメッセージの。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クライアントに関連付けられた特定の姿勢コレクターとNEAサーバーに関連付けられた姿勢バリーターの間で姿勢と検証情報を運ぶトランスポートとデータモデルを定義します。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プロトコルは、姿勢コレクターと姿勢検証装置の間で伝達される属性の認証、整合性、および機密保護を提供する必要があります。これにより、いくつかのシステムまたは信頼の境界の移動を伴う可能性のある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クライアントの姿勢コレクター間の姿勢属性メッセージ（PAプロトコルに基づく）の多重化をサポートしています（NEAサーバーの姿勢検証装置（どちらの方向））と出入りします。
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プロトコルは、評価に関与する姿勢検証装置の結果を姿勢ブローカークライアントに考慮して、Possure Broker Serverによって行われたグローバルな評価決定を伝えます。
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つ以上のPosure Validatorsから修復命令（パッチ参照など）などのアドバイザリと通知を集約および輸送します。
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メッセージをルーティング（配信）するために使用する一意の識別子を運ぶ必要があります。このようなメッセージルーティングは、姿勢コレクターとバリデーターの動的な登録または登録を容易にするはずです。たとえば、動的に登録されたウイルス対策姿勢検証ターは、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プロトコルをサポートできる必要があります。ただし、これにより、PBは全二重PTを実行したときに全二重の動作を妨げるものではありません。
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プロトコルは、姿勢ブローカークライアントと姿勢ブローカーサーバーの間で持つ属性メッセージの認証、整合性、および機密保護をサポートする場合があります。これにより、Positure Broker ClientとPossure Broker Serverの間で交換される属性メッセージのグループのメッセージのセキュリティ保護が提供されます。このような保護は、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）プロトコルは、Positure Transport ClientとPossure Transport Serverの間にPBプロトコルメッセージを搭載しています。PTは、PBプロトコルの保護輸送を提供する責任があります。PTプロトコル自体は、802.1x、半径[半径]、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またはUDPを介してNEAクライアントとNEAサーバーの間で実行できるはずです（Lightweight Directory Access Protocol（LDAP）と同様）。
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サーバーポリシーの変更が発生したことを示すイベントを隠している攻撃者）。
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クライアントまたはポリシーに影響を与えている場合に発生する可能性があり、したがって信頼できる評価は不可能です。このような状況は、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.
ネットワークエンドポイントの評価には、コンプライアンスポリシーに対してネットワーク上に入ったり、既に既にエンドポイントの姿勢を評価して、それらが適切に保護されていることを保証することが含まれます。したがって、コンプライアンスポリシーによって対処されている脅威から保護され、他のエンドポイントにそれらの脅威を伝えないと信頼できると信じる理由が（姿勢情報に基づいて）、エンドポイントの暗黙の不信があるに違いありません。ネットワークプロバイダー側では、NEAクライアントは通常、ネットワークインフラストラクチャシステムが開示された姿勢情報（セクション9を参照）とエンドポイントに提供される修復命令を誤用しないように信頼することが期待されています。NEAクライアントは通常、NEAサーバーがエンドポイントがネットワークアセットに安全であるかどうかを判断するために必要な情報のみを要求することを信頼する必要があります。
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サーバーへのエンドポイントの要求されたセキュリティ姿勢を正確に表すために信頼する必要があります。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サーバーに送信されることを期待しています。PAおよび/またはPTレベルのセキュリティ保護を使用する場合、エンドポイントは、姿勢コレクターおよび/または姿勢輸送クライアントが使用する信頼アンカー情報（例：公開キー証明書など）の整合性と潜在的な機密性を信頼する必要があります。ただし、NEAの実装は、エンドポイントにより多くの信頼を想定するために、エンドポイントにいくつかのポリシーを送信または事前に解決することを選択する場合があります。この場合、NEAサーバーは、姿勢評価の結果を偽造しないために、エンドポイントのポリシーストレージ、評価、および報告メカニズムを信頼する必要があります。
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サーバー（再評価）によって開始される場合、ある程度の信頼が必要です。Network DeployerとEndpointユーザー/所有者ポリシーによって決定されたメッセージに強力なセキュリティ保護を使用することにより、信頼の程度を制限できます。
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エンドポイントと共同住宅になります。この期待が展開に存在しない場合、次のキャリアプロトコルに変更せずにPTメッセージを正確にプロキシをするために終了デバイスを信頼する必要があります（たとえば、内側のEAPメソッドメッセージがEAP [EAP]トンネルから半径セッションに遷移する場合）。
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.
第4に、多くのネットワークには、ネットワークで疑わしい動作が観察された場合に是正措置を監視および実行するIDS/IPSデバイスなどのインフラストラクチャが含まれます。これらのデバイスは、この仕様の範囲内ではないNEAサーバーとの関係がある場合があります。NEAサーバーの意思決定に影響を与える可能性のあるセキュリティ情報を提供するためにNEAサーバーから信頼されているデバイスは、適切に動作し、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.
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サーバー（姿勢検証サービスを提供する潜在的にリモートシステムを含む）は、一般に、指定された評価ポリシーを適用することが信頼されており、妥協から保護する必要があります。NEAサーバーの展開が、適切な動作を保証するために、ネットワークおよびエンドポイントからのさまざまな攻撃からこれらのシステムを適切に保護することが不可欠です。
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サーバーの操作をある程度信頼する必要がありますが、厳密なセキュリティアーキテクチャ、分析、監視、およびレビューは、ネットワークのフットプリントと内部ワーキングが攻撃から保護されることを保証する必要があります。ネットワークフットプリントには、ポリシーオーサリングシステムからのポリシープロビジョニングや一般的なセキュリティおよびシステム管理プロトコルなど、攻撃の対象となる可能性のあるネットワーク上の通信が含まれます。内部作業のいくつかの例には、NEA内サーバー通信、NEAサーバーの内部ロジック、またはポリシーストア（特に結果の決定または執行機関を変更するもの）を攻撃するマルウェアからの保護が含まれます。NEAサーバーは、基礎となる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.
興味深い例の1つは、NEAサーバーの一部のコンポーネントが異なるシステムに物理的に存在する場合です。これは、Positure Brokerサーバーの別のシステムに姿勢検証装置（またはローカルPosure Validatorが使用するリモートバックエンドサーバー）が存在する場合に発生する可能性があります。同様に、Posture Broker Serverは、Positure Transport Serverから別のシステムに存在する可能性があります。物理的な分離がある場合、NEAサーバーのリモートコンポーネント間の通信は、PBセッションとPAメッセージダイアログがアクティブな攻撃とパッシブ攻撃、特に盗聴、偽造、リプレイに守られていることを確認する必要があります。同様に、Posure Validatorsは、PAメッセージを適切に送信および配信する能力を超えて、Posure Broker Serverに対する信頼を最小限に抑えたい場合もあります。姿勢バリエーターは、エンドツーエンドの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セキュリティを使用する場合、各Possure 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層でトラフィックを暗号化して、盗聴者によるトラフィック分析または傍受から保護することをお勧めします。さらに、展開者は、エンドポイントの姿勢を含むメッセージを選択的に暗号化して、対応する姿勢バリーターに対してエンドツーエンドの機密性を達成することもできます。特に、これは、Positure Valibatorが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.
ネットワークプロトコルに対するMITM攻撃は、第三者が検出なしで2つの通信エンティティ間に挿入し、メッセージダイアログに関与して利益を得ることができる場合に存在します。たとえば、マルウェア感染システムは、ネットワークに入るクリーンエンドポイントから観察されたネットワークリプレイの姿勢に参加したい場合があります。これは、アセスメントメッセージのダイアログに積極的にプロキシを挿入するシステムによって発生する可能性があります。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サーバーには、姿勢がない場合に準拠した姿勢を持つように見えるかもしれません。たとえば、非準拠MITMはNEAサーバーに接続して認証でき、NEAサーバーが姿勢情報を要求すると、MITMはクリーンエンドポイントから同じ姿勢を要求できます。クリーンエンドポイントがMITMが再評価を実行することを信頼し、要求された姿勢を共有する意思がある場合、MITMはクリーンエンドポイントから必要な姿勢を取得し、NEAサーバーに送信することができます。この形式のMITM攻撃に対処するために、NEAプロトコルは、NEAサーバーへの姿勢情報と認証されたセッションの間に強い（暗号化）結合を提供する必要があります。姿勢の起源と認証エンドポイントの間にこのような強力な結合が実行可能である可能性があるため、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サーバーがこの変更を検出できない限り、攻撃者は多数のクリーンシステムへの入場を防ぐことができます。逆に、攻撃者は、送信された姿勢属性を変更して準拠した値を反映することにより、マルウェアに感染したマシンを認めることができ、姿勢検証装置からマルウェアを隠すことができます。攻撃者は、実行時にエンドポイントにマルウェアを導入したり、セキュリティメカニズムを非アクティブ化する悪意のある修復命令を送信することにより、準拠したエンドポイントに感染する可能性もあります。
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] [HMAC]のような保護されたハッシュを含む）。PAには、属性のエンドツーエンドの整合性保護を有効にするための同様の要件が含まれており、NEAサーバーの背後にある別のシステムにある場合でも、保護をPosure Validatorに拡張します。
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サーバーに再利用するか、既知の脆弱性を監視する他のシステムで実行されているソフトウェアのインベントリを構築するためだけです。NEAサーバーは、姿勢のリプレイを検出できる必要があります。このため、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内で使用される特定の技術とプロトコルを説明する仕様を作成すると、いくつかのタイプの攻撃が理解し、分析しやすくなります。そのような分野の1つは、サービス拒否（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サーバーが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クライアントポリシーコンテンツ標準を定義したり、ネットワークプロトコル以外の実装の側面に関する要件を定義したりしていません。ただし、上記のエンタープライズ指向の設定よりも、より広範な使用のためのプライバシーに優しい実装を促進するために、次のガイダンスが提供されています。
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 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.
NEAクライアントの実装は、エンドポイントの姿勢情報を共有する前に、ユーザーにオプトインポリシーを提供することをお勧めします。オプトインメカニズムは、各ユーザーがシステム上の姿勢情報にアクセスできるネットワークを制御できるように、ユーザーごとのサーバーベースにある必要があります。エンドポイントを評価することが許可されているネットワークの場合、ユーザーは、特定のタイプと特定の属性の姿勢を開示できる特定の属性について詳細な制限を指定できる必要があります。Possure Validatorの実装は、情報の過剰露出につながる可能性のある姿勢に対するワイルドカードされたリクエストを使用するというデフォルトの動作を妨げられます（セクション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サーバーに送信する前に要求されている姿勢情報の特定の説明を使用して、ユーザーに承認を求めるポリシー主導のサポートを検討する場合があります。
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サーバーの実装は、新しくサブスクライブするエンドポイントに、明確に記載されている開示声明を提供する必要があります。
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参照モデルとプロトコルの設計における重要な問題の1つは、エンドポイントがネットワークポリシーのコンプライアンスを確立するために必要な最小限の情報を開示できるようにすることです。開示された属性セットがどのように確立されるかについて考慮できるモデルがいくつかあります。各モデルには、製品開発者が考慮すべきプライバシー関連の利点と問題があります。このセクションでは、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サーバーが必要な属性を具体的に要求できるようにすることにより、開示ポリシーの事前プロビジョニングの必要性を回避します。これは、NEA取引所中にプロビジョニングされているポリシーに多少類似しているため、管理がはるかに簡単です。このモデルにより、NEAサーバーは、以前の属性の値に基づいて属性を繰り返し要求できます。このモデルでさえ、NEAプロトコルは汎用クエリ言語であるとは予想されていませんが、定義された属性のみが要求できるため、NEAサーバーが特定の属性を要求できるようにします。たとえば、企業は最初のメッセージダイアログでOSバージョンについて尋ねる場合があり、システムが実行中のLinuxを実行した後、EndpointがWindowsシステムである場合とはLinuxに固有の異なる属性セットを要求します。このアプローチは、評価が複雑なシステムである場合（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。、「UTF-8、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 STD 802.1x-2001、2001年6月。
[CNAC] Cisco, Cisco's Network Admission Control Main Web Site, http://www.cisco.com/go/nac
[CNAC] Cisco、Cisco's Network Andiming Control Main 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.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[NAP] Microsoft, Network Access Protection Main Web Site, http://www.microsoft.com/nap
[NAP] Microsoft、ネットワークアクセス保護メイン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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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.
この文書の著者は、この仕様の方向性に影響を与えた以前の要件と問題の声明文書に貢献したNEAワーキンググループのメンバーを認めたいと考えています：ケビン・アモリン、パルベス・アナンダム、ダイアナ・アロヨ、ウリ・ブルーメンタル、アラン・デコク、ローレン・ジルー、スティーブ・ハンナ、トーマス・ハードジョノ、ティム・ポーク、ラビ・サヒタ、ジョー・サロウィー、クリス・ソルター、マウリシオ・サンチェス、ヤロン・シェファー、ジェフ・シックス、スーザン・トンプソン、ゲイリー・トムリンソン、ジョン・ヴォルブレヒト、ナンシー・ウィンゲット、ハン・イン、ハオ・Zhou。
Authors' Addresses
著者のアドレス
Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad, CA 92009 USA Phone: +1 760 438-5656 EMail: Paul_Sangster@symantec.com
Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad、CA 92009 USA電話：1 760 438-5656メール：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 Intel 2111 NE 25th Avenue Hillsboro、または97124 USA電話：1 503 264 0334メール：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 Mani Avaya Inc. 1033 McCarthy Blvd.カリフォルニア州ミルピタス95035米国電話：1 408 321-4840メール：mmani@avaya.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 Phone: +1 408 526-8168 EMail: kaushik@cisco.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose、CA 95134電話：1 408 526-8168メール：kaushik@cisco.com
Joseph Tardo Nevis Networks 295 N. Bernardo Ave., Suite 100 Mountain View, CA 94043 USA EMail: joseph.tardo@nevisnetworks.com
Joseph Tardo Nevis Networks 295 N. Bernardo Ave.、Suite 100 Mountain View、CA 94043 USAメール：joseph.tardo@nevisnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。