[要約] RFC 8248は、セキュリティ自動化と継続的な監視（SACM）の要件に関するものであり、セキュリティプロセスの自動化と監視のためのガイドラインを提供しています。このRFCの目的は、セキュリティの効率的な管理と脅威の早期検出を促進することです。
Internet Engineering Task Force (IETF) N. Cam-Winget
Request for Comments: 8248 Cisco Systems
Category: Informational L. Lorenzin
ISSN: 2070-1721 Pulse Secure
September 2017
Security Automation and Continuous Monitoring (SACM) Requirements
セキュリティの自動化と継続的監視（SACM）の要件
Abstract
概要
This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632.
このドキュメントでは、Security Automation and Continuous Monitoring（SACM）アーキテクチャ、データモデル、および転送プロトコルのスコープと要件のセットを定義します。要件と範囲は、RFC 7632で説明されている合意済みのユースケースに基づいています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8248.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8248で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4
2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 9
2.4. Requirements for the Data Model . . . . . . . . . . . . . 10
2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1. Trust between Provider and Requestor . . . . . . . . . . 16
4.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Today's environment of rapidly evolving security threats highlights the need to automate the sharing of security information (such as posture information) while protecting user information and the systems that store, process, and transmit this information. Security threats can be detected in a number of ways. The Security Automation and Continuous Monitoring (SACM) charter focuses on how to collect and share this information based on use cases that involve posture assessment of endpoints.
セキュリティの脅威が急速に進化している今日の環境では、セキュリティ情報（ポスチャ情報など）の共有を自動化し、ユーザー情報とこの情報を保存、処理、および送信するシステムを保護する必要性が浮き彫りになっています。セキュリティの脅威は、いくつかの方法で検出できます。 Security Automation and Continuous Monitoring（SACM）憲章は、エンドポイントのポスチャ評価を伴うユースケースに基づいてこの情報を収集および共有する方法に焦点を当てています。
Scalable and sustainable collection, expression, and evaluation of endpoint information is foundational to SACM's objectives. To secure and defend a network, one must reliably determine what devices are on the network, how those devices are configured from a hardware perspective, what software products are installed on those devices, and how those products are configured. We need to be able to determine, share, and use this information in a secure, timely, consistent, and automated manner to perform endpoint posture assessments.
エンドポイント情報のスケーラブルで持続可能な収集、表現、および評価は、SACMの目標の基礎となります。ネットワークを保護および防御するには、ネットワーク上にあるデバイス、ハードウェアの観点からのデバイスの構成方法、デバイスにインストールされているソフトウェア製品、および製品の構成方法を確実に判断する必要があります。エンドポイントのポスチャ評価を実行するには、この情報を安全でタイムリーで一貫した自動化された方法で決定、共有、使用できる必要があります。
This document focuses on describing the requirements for facilitating the exchange of posture assessment information in the enterprise, in particular, for the use cases as exemplified in [RFC7632].
このドキュメントでは、特に[RFC7632]で例示されている使用例について、企業でのポスチャ評価情報の交換を容易にするための要件の説明に焦点を当てています。
As proposals are evaluated for SACM standardization, the documents describing each proposal are expected to include a section that describes how the enumerated requirements are addressed.
SACM標準化のために提案が評価されると、各提案を説明するドキュメントには、列挙された要件への対処方法を説明するセクションが含まれることが期待されます。
This document uses terminology defined in [TERMS].
このドキュメントでは、[TERMS]で定義された用語を使用します。
Use of each capitalized word within a sentence or phrase carries the following meaning during the SACM WG's protocol selection process:
SACM WGのプロトコル選択プロセスでは、文または語句内の大文字の各単語の使用には次の意味があります。
MUST - indicates an absolute requirement
必須-絶対要件を示します
MUST NOT - indicates something absolutely prohibited
してはいけないこと-絶対に禁止されていることを示します
SHOULD - indicates a strong recommendation of a desired result
SHOULD-望ましい結果の強力な推奨を示します
SHOULD NOT - indicates a strong recommendation against a result
すべきではない-結果に対する強い推奨を示す
MAY - indicates a willingness to allow an optional outcome
MAY-オプションの結果を許可する意欲を示します
When the words appear in lower case, their natural language meaning is used.
単語が小文字で表示される場合は、自然言語の意味が使用されます。
This document defines requirements based on the SACM use cases described in [RFC7632]. This section describes the requirements used by SACM to assess and compare candidate data models, interfaces, and protocols. These requirements express characteristics or features that a candidate protocol, information model, or data model must be capable of offering to ensure security and interoperability.
このドキュメントでは、[RFC7632]で説明されているSACMの使用例に基づいて要件を定義しています。このセクションでは、候補データモデル、インターフェース、およびプロトコルを評価および比較するためにSACMが使用する要件について説明します。これらの要件は、候補プロトコル、情報モデル、またはデータモデルがセキュリティと相互運用性を保証するために提供できる必要がある特性または機能を表します。
Multiple data models, protocols, and transfers may be employed in a SACM environment. A SACM transfer protocol is one that runs on top of transport-layer protocols such as TCP/IP or internet-layer protocols such as HTTP, carries operations (requests/responses), and moves data.
SACM環境では、複数のデータモデル、プロトコル、および転送を使用できます。 SACM転送プロトコルは、TCP / IPなどのトランスポート層プロトコルまたはHTTPなどのインターネット層プロトコルの上で実行され、操作（要求/応答）を伝達し、データを移動するプロトコルです。
SACM will define an architecture and information model focused on addressing the needs for determining, sharing, and using posture information securely via posture information providers and posture information consumers. With the information model defining assets and attributes to facilitate the guidance, collection, and assessment of posture, tasks that should be considered include:
SACMは、ポスチャ情報プロバイダーとポスチャ情報コンシューマーを介して、ポスチャ情報を安全に決定、共有、および使用するためのニーズに対処することに焦点を当てたアーキテクチャと情報モデルを定義します。姿勢のガイダンス、収集、および評価を容易にするための資産と属性を定義する情報モデルにより、考慮すべきタスクは次のとおりです。
1. Asset Classification: Map the target endpoint and/or the assets on the target endpoints to asset classes. This enables identification of the attributes needed to exchange information pertaining to the target endpoint.
1.アセットの分類：ターゲットエンドポイントまたはターゲットエンドポイント上のアセット、あるいはその両方をアセットクラスにマップします。これにより、ターゲットエンドポイントに関する情報を交換するために必要な属性を識別できます。
2. Attribute Definition: Define the attributes desired to be collected from each target endpoint. For instance, organizations will want to know what software is installed and its critical security attributes such as patch level.
2. 属性定義：各ターゲットエンドポイントから収集する必要のある属性を定義します。たとえば、組織は、インストールされているソフトウェアと、パッチレベルなどの重要なセキュリティ属性を知りたいと思うでしょう。
3. Policy Definition: This is where an organization can express its policy for acceptable or problematic values of an endpoint attribute. The expected values of an endpoint attribute are determined for later comparison against the actual endpoint attribute values during the evaluation process. Expected values may include both values that are good as well as values that represent problems, such as vulnerabilities. The organization can also specify the endpoint attributes that are to be present for a given target endpoint.
3. ポリシー定義：これは、組織がエンドポイント属性の許容値または問題のある値に対するポリシーを表現できる場所です。エンドポイント属性の期待値は、後で評価プロセス中に実際のエンドポイント属性値と比較するために決定されます。期待される値には、良好な値と、脆弱性などの問題を表す値の両方が含まれる場合があります。組織は、特定のターゲットエンドポイントに存在するエンドポイント属性を指定することもできます。
4. Information Collection: Collect information (attribute values) from the target endpoint to populate the endpoint data.
4. 情報収集：ターゲットエンドポイントから情報（属性値）を収集して、エンドポイントデータを入力します。
5. Endpoint Assessment: Evaluate the actual values of the endpoint attributes against those expressed in the policy. (An evaluation result may become additional endpoint data.)
5. エンドポイントの評価：ポリシーで表現されたものに対してエンドポイント属性の実際の値を評価します。 （評価結果は追加のエンドポイントデータになる場合があります。）
6. Result Reporting: Report the results of the evaluation for use by other components. Examples of the use of a report would be additional evaluation, network enforcement, vulnerability detection, and license management.
6. 結果の報告：他のコンポーネントで使用するために、評価の結果を報告します。レポートの使用例には、追加の評価、ネットワークの実施、脆弱性の検出、ライセンス管理などがあります。
Many deployment scenarios can be instantiated to address the above tasks and the use cases defined in [RFC7632]. To ensure interoperability, scalability, and flexibility in any of these deployments, the following requirements are defined for proposed SACM standards:
上記のタスクと[RFC7632]で定義されている使用例に対処するために、多くの配備シナリオをインスタンス化できます。これらの展開のいずれにおいても相互運用性、スケーラビリティ、および柔軟性を確保するために、提案されたSACM標準に対して次の要件が定義されています。
G-001 (Solution Extensibility): The information model, data models, protocols, and transfers defined by SACM MUST be designed to allow support for future extensions. SACM MUST allow for both standardized and proprietary extensions.
G-001（ソリューション拡張性）：SACMによって定義された情報モデル、データモデル、プロトコル、および転送は、将来の拡張をサポートできるように設計する必要があります。 SACMは、標準化された拡張と独自の拡張の両方を許可する必要があります。
1. The information model and programmatic interfaces (see G-012 for one example) MUST support the ability to add new operations while maintaining backwards compatibility. SACM-defined transfer protocols MUST have extensibility to allow them to transfer operations that are defined in the future.
1. 情報モデルとプログラムインターフェイス（1つの例についてはG-012を参照）は、下位互換性を維持しながら新しい操作を追加する機能をサポートする必要があります。 SACMで定義された転送プロトコルは、将来定義される操作を転送できるようにする拡張性を備えている必要があります。
2. The query language MUST allow for general inquiries as well as expression of specific attributes or relationships between attributes; the retrieval of specific information based on an event or on a continuous basis; and the ability to retrieve specific pieces of information, specific types or classes of information, or the entirety of available information.
2. クエリ言語は、一般的な問い合わせと特定の属性または属性間の関係の表現を許可する必要があります。イベントに基づいて、または継続的に特定の情報を取得する。特定の情報、特定のタイプまたはクラスの情報、または利用可能な情報全体を取得する機能。
3. The information model MUST accommodate the interoperable addition of new data types and/or schemas.
3. 情報モデルは、新しいデータタイプやスキーマの相互運用可能な追加に対応する必要があります。
G-002 (Interoperability): The data models, protocols, and transports MUST be specified with enough details to ensure interoperability.
G-002（相互運用性）：データモデル、プロトコル、およびトランスポートは、相互運用性を確保するために十分な詳細を指定する必要があります。
G-003 (Scalability): SACM needs to support a broad set of deployment scenarios. The data models, protocols, and transports have to be scalable unless they are specifically defined to apply to a special-purpose scenario, such as constrained devices. A SACM transfer protocol standard SHOULD include a section on scalability considerations that addresses the number of endpoints and amount of information to which it can reasonably be expected to scale. Scalability must be addressed to support:
G-003（スケーラビリティ）：SACMは、幅広い展開シナリオをサポートする必要があります。データモデル、プロトコル、およびトランスポートは、制約付きデバイスなどの特別な目的のシナリオに適用するように明確に定義されていない限り、スケーラブルである必要があります。 SACM転送プロトコル標準には、エンドポイントの数とそれに応じて適切にスケーリングできると予想される情報量に対処するスケーラビリティの考慮事項に関するセクションが含まれる必要があります（SHOULD）。以下をサポートするために、スケーラビリティに対処する必要があります。
* Large messages: It is possible that the size of posture assessment information can vary from a single assessment that is small in size to a very large message or a very large set of assessments (up to multiple gigabytes in size).
* 大きなメッセージ：ポスチャ評価情報のサイズは、サイズが小さい単一の評価から、非常に大きなメッセージまたは非常に大きな評価セット（最大数ギガバイトまで）まで変化する可能性があります。
* Large number of messages per second: A deployment may involve many rapid or simultaneous events that require processing, generating many messages per second.
* 1秒あたりの大量のメッセージ：デプロイメントには、処理を必要とする多くの高速または同時のイベントが含まれ、1秒あたり多くのメッセージを生成する場合があります。
* Large number of providers and consumers: A deployment may consist of a very large number of endpoints requesting and/or producing posture assessment information.
* 多数のプロバイダーとコンシューマー：配置は、ポスチャ評価情報を要求および/または生成する非常に多数のエンドポイントで構成される場合があります。
* Large number of target endpoints: A deployment may be managing information of a very large number of target endpoints.
* 多数のターゲットエンドポイント：デプロイメントは、非常に多数のターゲットエンドポイントの情報を管理している場合があります。
G-004 (Versatility): The data model, protocols, and transports must be suitably specified to enable implementations to fit into different deployment models and scenarios, including considerations for implementations of data models and transports operating in constrained environments. Separate solutions may be necessary to meet the needs of specific deployment models and scenarios.
G-004（汎用性）：制約のある環境で動作するデータモデルとトランスポートの実装に関する考慮事項を含め、実装がさまざまな配置モデルとシナリオに適合するように、データモデル、プロトコル、およびトランスポートを適切に指定する必要があります。特定の展開モデルとシナリオのニーズを満たすために、個別のソリューションが必要になる場合があります。
G-005 (Information Extensibility): Non-standard (implementation-specific) attributes MUST be supported. A method SHOULD be defined for preventing collisions from occurring in the naming of all attributes independent of their source. For interoperability and scope boundary, the information model MUST define the mandatory set of attributes.
G-005（情報の拡張性）：非標準（実装固有）の属性をサポートする必要があります。ソースに関係なく、すべての属性の命名で衝突が発生しないようにするためのメソッドを定義する必要があります。相互運用性とスコープ境界のために、情報モデルは必須の属性セットを定義しなければなりません（MUST）。
G-006 (Data Protection): To protect the information being shared, SACM components MUST protect the integrity and confidentiality of data in transit (end to end) and data at rest (as information is stored in repositories). Mechanisms for this protection are unspecified but should include industry best practices. These mechanisms are required to be available (i.e., all data-handling components must support them) but are not required to be used in all cases.
G-006（データ保護）：共有される情報を保護するために、SACMコンポーネントは、転送中のデータ（エンドツーエンド）と保管中のデータ（情報はリポジトリに格納されているため）の整合性と機密性を保護する必要があります。この保護のメカニズムは規定されていませんが、業界のベストプラクティスを含める必要があります。これらのメカニズムは利用可能である必要があります（つまり、すべてのデータ処理コンポーネントがそれらをサポートする必要があります）が、すべてのケースで使用する必要はありません。
G-007 (Data Partitioning): A method for partitioning data MUST be supported to accommodate considerations such as geographic, regulatory, operational requirements, overlay boundaries, and federation (where the data may be collected in multiple locations and either centralized or kept in the local region). Where replication of data is supported, it is required that methods exist to prevent update loops.
G-007（データ分割）：地理的、規制、運用要件、オーバーレイ境界、およびフェデレーション（データが複数の場所で収集され、集中化されるか、ローカル地域）。データの複製がサポートされている場合、更新ループを防ぐための方法が存在する必要があります。
G-008 (Versioning and Backward Compatibility): Announcement and negotiation of versions, inclusive of existing capabilities (such as transfer protocols, data models, specific attributes within data models, standard attribute expression sets, etc.) MUST be supported. Negotiation for both versioning and capabilities is needed to accommodate future growth and ecosystems with mixed capabilities.
G-008（バージョン管理と下位互換性）：既存の機能（転送プロトコル、データモデル、データモデル内の特定の属性、標準属性式セットなど）を含む、バージョンのアナウンスとネゴシエーションをサポートする必要があります。将来の成長と機能が混在するエコシステムに対応するには、バージョニングと機能の両方に関する交渉が必要です。
G-009 (Information Discovery): There MUST be mechanisms for components to discover what information is available across the ecosystem (i.e., a method for cataloging data available in the ecosystem and advertising it to consumers), where to go to get a specific piece of that information (i.e., which provider has the information), and what schemas are in use for organizing the information. For example, a method can be provided by which a node can locate the advertised information so that consumers are not required to have a priori knowledge to find available information.
G-009（情報の発見）：エコシステム全体で利用可能な情報をコンポーネントが発見するメカニズム（つまり、エコシステムで利用可能なデータをカタログ化し、消費者にそれを宣伝する方法）、特定の部分を取得するための場所が必要ですその情報（つまり、どのプロバイダーが情報を持っているか）、およびどのスキーマが情報の編成に使用されているか。例えば、消費者が利用可能な情報を見つけるためにアプリオリな知識を持つ必要がないように、ノードが広告された情報を見つけることができる方法を提供することができる。
G-010 (Target Endpoint Discovery): SACM MUST define the means by which target endpoints may be discovered. The use case in Section 2.1.2 of [RFC7632] describes the need to discover endpoints and their composition.
G-010（ターゲットエンドポイントの検出）：SACMは、ターゲットエンドポイントを検出する方法を定義する必要があります。 [RFC7632]のセクション2.1.2のユースケースは、エンドポイントとその構成を発見する必要性を説明しています。
G-011 (Push and Pull Access): Three methods of data access MUST be supported: a Pull model, a solicited Push model, and an unsolicited Push model. All of the methods of data access MUST support the ability for the initiator to filter the set of posture assessment information to be delivered. Additionally, the provider of the information MUST be able to filter the set of posture assessment information based on the permissions of the recipient. This requirement is driven by the use cases in Sections 2.1.3 and 2.1.4 of [RFC7632].
G-011（プッシュおよびプルアクセス）：データアクセスの3つの方法をサポートする必要があります。プルモデル、要請プッシュモデル、非要請プッシュモデルです。データアクセスのすべての方法は、配信される一連のポスチャ評価情報をフィルタリングするイニシエーターの機能をサポートする必要があります。さらに、情報のプロバイダーは、受信者の権限に基づいて、一連のポスチャ評価情報をフィルタリングできる必要があります。この要件は、[RFC7632]のセクション2.1.3および2.1.4のユースケースによって推進されます。
G-012 (SACM Component Interface): The interfaces by which SACM components communicate to share endpoint posture information MUST be well defined. That is, the interface defines the data model, SACM transfer protocols, and network transfer protocols to enable SACM components to communicate.
G-012（SACMコンポーネントインターフェイス）：SACMコンポーネントがエンドポイントポスチャ情報を共有するために通信するためのインターフェイスは、明確に定義されている必要があります。つまり、インターフェースは、データモデル、SACM転送プロトコル、およびネットワーク転送プロトコルを定義して、SACMコンポーネントが通信できるようにします。
G-013 (Endpoint Location and Network Topology): The SACM architecture and interfaces MUST allow for the target endpoint (network) location and network topology to be modeled and understood. Where appropriate, the data model and the interfaces SHOULD allow for discovery of the target endpoint location, network topology, or both.
G-013（エンドポイントの場所とネットワークトポロジ）：SACMアーキテクチャとインターフェイスは、ターゲットエンドポイント（ネットワーク）の場所とネットワークトポロジをモデル化して理解できるようにする必要があります。必要に応じて、データモデルとインターフェイスは、ターゲットエンドポイントの場所、ネットワークトポロジ、またはその両方を検出できるようにする必要があります（SHOULD）。
G-014 (Target Endpoint Identity): The SACM architecture and interfaces MUST support the ability of components to provide attributes that can be used to compose an identity for a target endpoint. These identities MAY be composed of attributes from one or more SACM components.
G-014（ターゲットエンドポイントアイデンティティ）：SACMアーキテクチャとインターフェースは、コンポーネントがターゲットエンドポイントのアイデンティティを構成するために使用できる属性を提供する機能をサポートする必要があります。これらのIDは、1つ以上のSACMコンポーネントからの属性で構成されている場合があります。
G-015 (Data Access Control): Methods of access control must be supported to accommodate considerations such as geographic, regulatory, operational, and federations. Entities accessing or publishing data MUST identify themselves and pass access policy.
G-015（データアクセスコントロール）：地理的、規制、運用、フェデレーションなどの考慮事項に対応するために、アクセスコントロールの方法をサポートする必要があります。データにアクセスまたは公開するエンティティは、自身を識別し、アクセスポリシーを渡す必要があります。
Following are the requirements for the SACM architecture:
SACMアーキテクチャの要件は次のとおりです。
ARCH-001 (Component Functions): At the simplest abstraction, the SACM architecture MUST represent the core components and interfaces needed to perform the production and consumption of posture assessment information.
ARCH-001（コンポーネント関数）：最も単純な抽象化で、SACMアーキテクチャは、ポスチャ評価情報の生成と消費を実行するために必要なコアコンポーネントとインターフェースを表現しなければなりません（MUST）。
ARCH-002 (Scalability): The architectural components MUST account for a range of deployments, from very small sets of endpoints to very large deployments.
ARCH-002（スケーラビリティ）：アーキテクチャコンポーネントは、非常に小さなエンドポイントのセットから非常に大規模なデプロイメントまで、さまざまなデプロイメントを考慮する必要があります。
ARCH-003 (Flexibility): The architectural components MUST account for different deployment scenarios where the architectural components may be implemented, deployed, or used within a single application, service, or network, or may comprise a federated system.
ARCH-003（柔軟性）：アーキテクチャコンポーネントは、アーキテクチャコンポーネントが単一のアプリケーション、サービス、またはネットワーク内で実装、展開、または使用されるか、フェデレーションシステムを構成するさまざまな展開シナリオを考慮しなければなりません（MUST）。
ARCH-004 (Separation of Data and Management Functions): SACM MUST define both the configuration and management of the SACM data models and protocols used to transfer and share posture assessment information.
ARCH-004（データと管理機能の分離）：SACMは、ポスチャ評価情報の転送と共有に使用されるSACMデータモデルとプロトコルの構成と管理の両方を定義する必要があります。
ARCH-005 (Topology Flexibility): Both centralized and decentralized (peer-to-peer) information exchange MUST be supported. Centralized data exchange enables use of a common data format to bridge together data exchange between diverse systems and can leverage a virtual data store that centralizes and offloads all data access, storage, and maintenance to a dedicated resource. Decentralized data exchange enables simplicity of sharing data between relatively uniform systems and between small numbers of systems, especially within a single enterprise domain. The fact that a centralized or decentralized deployment is used SHOULD be invisible to a consumer. However, there may be cases where the producer chooses to include that information due to consumer preference.
ARCH-005（トポロジーの柔軟性）：集中型と非集中型（ピアツーピア）の両方の情報交換をサポートする必要があります。一元化されたデータ交換により、共通のデータ形式を使用してさまざまなシステム間のデータ交換をブリッジし、すべてのデータアクセス、ストレージ、およびメンテナンスを一元化して専用リソースにオフロードする仮想データストアを活用できます。分散型データ交換により、特に単一のエンタープライズドメイン内で、比較的均一なシステム間および少数のシステム間でデータを簡単に共有できます。集中型または分散型のデプロイメントが使用されているという事実は、消費者には見えないはずです。ただし、消費者の好みにより、プロデューサーがその情報を含めることを選択する場合があります。
ARCH-006 (Capability Negotiation): Announcement and negotiation of functional capabilities (such as authentication protocols, authorization schemes, data models, transfer protocols, etc.) MUST be supported, enabling a SACM component to make inquiries about the capabilities of other components in the SACM ecosystem.
ARCH-006（ケイパビリティネゴシエーション）：アナウンスと機能機能（認証プロトコル、承認スキーム、データモデル、転送プロトコルなど）のネゴシエーションがサポートされている必要があり、SACMコンポーネントが他のコンポーネントの機能について照会できるようにする必要があります。 SACMエコシステム。
ARCH-007 (Role-Based Authorization): The SACM architecture MUST be capable of effecting role-based authorization. Distinction of endpoints capable of and authorized to provide or consume information is required to address appropriate access controls.
ARCH-007（役割ベースの許可）：SACMアーキテクチャーは役割ベースの許可を実行できなければなりません（MUST）。適切なアクセス制御に対処するには、情報の提供または利用が可能なエンドポイントの区別が必要です。
ARCH-008 (Context-Based Authorization): The SACM architecture MUST be capable of effecting context-based authorization. Different policies (e.g., business, regulatory, etc.) might specify what data may be exposed to, or shared by, consumers based on one or more attributes of the consumer. The policy might specify that consumers are required to share specific information either back to the system or to administrators.
ARCH-008（コンテキストベースの承認）：SACMアーキテクチャは、コンテキストベースの承認を実行できなければなりません（MUST）。さまざまなポリシー（ビジネス、規制など）は、コンシューマーの1つ以上の属性に基づいて、コンシューマーに公開または共有できるデータを指定する場合があります。ポリシーでは、コンシューマーが特定の情報をシステムまたは管理者に共有する必要があることを指定する場合があります。
ARCH-009 (Time Synchronization): Actions or decisions based on time-sensitive data (such as user logon/logoff, endpoint connection/ disconnection, endpoint behavior events, etc.) are all predicated on a synchronized understanding of time. The SACM architecture MUST provide a mechanism for all components to synchronize time. A mechanism for detecting and reporting time discrepancies SHOULD be provided by the architecture and reflected in the information model.
ARCH-009（時刻の同期）：時間に依存するデータ（ユーザーのログオン/ログオフ、エンドポイントの接続/切断、エンドポイントの動作イベントなど）に基づくアクションまたは決定はすべて、時刻の同期された理解に基づいています。 SACMアーキテクチャは、すべてのコンポーネントが時間を同期するためのメカニズムを提供する必要があります。時間の不一致を検出して報告するメカニズムは、アーキテクチャによって提供され、情報モデルに反映される必要があります（SHOULD）。
The SACM information model represents the abstracted representation for posture assessment information to be communicated. SACM data models must adhere to and comply with the SACM information model. The requirements for the SACM information model include:
SACM情報モデルは、伝達される姿勢評価情報の抽象表現を表します。 SACMデータモデルは、SACM情報モデルに準拠し、準拠する必要があります。 SACM情報モデルの要件は次のとおりです。
IM-001 (Extensible Attribute Vocabulary): The information model MUST define a minimum set of attributes for communicating posture information, to ensure interoperability between data models. (Individual data models may define attributes beyond the mandatory-to-implement minimum set.) The attributes should be defined with a clear mechanism for extensibility to enable data models to adhere to SACM's required attributes as well as allow for their own extensions. The attribute vocabulary should be defined with a clear mechanism for extensibility to enable future versions of the information model to be interoperably expanded with new attributes.
IM-001（Extensible Attribute Vocabulary）：情報モデルは、データモデル間の相互運用性を確保するために、姿勢情報を通信するための最小限の属性セットを定義する必要があります。 （個々のデータモデルは、必須から実装までの最小セットを超える属性を定義する場合があります。）属性は、データモデルがSACMの必要な属性に準拠し、独自の拡張を可能にする拡張性のための明確なメカニズムで定義する必要があります。属性語彙は、情報モデルの将来のバージョンを新しい属性で相互運用可能に拡張できるようにする拡張性のための明確なメカニズムで定義する必要があります。
IM-002 (Posture Data Publication): The information model MUST allow for the data to be provided by a SACM component either solicited or unsolicited. No aspect of the information model should be dependent upon or assume a Push or Pull model of publication.
IM-002（ポスチャデータ公開）：情報モデルでは、要請されたまたは要請されていないSACMコンポーネントによってデータが提供されることを許可する必要があります。情報モデルのどの側面も、公開のプッシュモデルまたはプルモデルに依存したり想定したりすることはできません。
IM-003 (Data Model Negotiation): SACM's information model MUST allow support for different data models, data model versions, and different versions of the operations on the data models and transfer protocols. The SACM information model MUST include the ability to discover and negotiate the use of a particular data model or any data model.
IM-003（データモデルネゴシエーション）：SACMの情報モデルは、さまざまなデータモデル、データモデルのバージョン、およびデータモデルと転送プロトコルに対する操作のさまざまなバージョンのサポートを許可する必要があります。 SACM情報モデルには、特定のデータモデルまたは任意のデータモデルの使用を発見して交渉する機能が含まれている必要があります。
IM-004 (Data Model Identification): The information model MUST provide a means to uniquely identify each data model. The identifier MUST contain both an identifier of the data model and a version indicator for the data model. The identifiers SHOULD be decomposable so that a customer can query for any version of a specific data model and compare returned values for older or newer than a desired version.
IM-004（データモデル識別）：情報モデルは、各データモデルを一意に識別する手段を提供する必要があります。識別子には、データモデルの識別子とデータモデルのバージョンインジケーターの両方を含める必要があります。識別子は分解可能である必要があるので、顧客は特定のデータモデルの任意のバージョンを照会し、返された値を目的のバージョンより古いか新しいかを比較できます。
IM-005 (Data Lifetime Management): The information model MUST provide a means to allow data models to include data lifetime management. The information model must identify attributes that can allow data models to, at minimum, identify the data's origination time and expected time of next update or data longevity (how long the data should be assumed to still be valid).
IM-005（データライフタイム管理）：情報モデルは、データモデルにデータライフタイム管理を含めるための手段を提供する必要があります。情報モデルは、データモデルが少なくともデータの発生時間と次の更新の予想時間またはデータの寿命（データがまだ有効であると想定される時間）を識別できる属性を識別する必要があります。
IM-006 (Singularity and Modularity): The SACM information model MUST be singular (i.e., there is only one information model, not multiple alternative information models from which to choose) and MAY be modular (a conjunction of several subcomponents) for ease of maintenance and extension. For example, endpoint identification could be an independent subcomponent of the information model, to simplify updating of endpoint identification attributes.
IM-006（特異性およびモジュラリティ）：SACM情報モデルは単数でなければならず（つまり、情報モデルは1つだけであり、複数の代替情報モデルから選択することはできません）、簡単にするためにモジュール式（複数のサブコンポーネントの組み合わせ）である必要がありますメンテナンスと拡張。たとえば、エンドポイント識別は、エンドポイント識別属性の更新を簡略化するために、情報モデルの独立したサブコンポーネントにすることができます。
The SACM information model represents an abstraction for "what" information can be communicated and "how" it is to be represented and shared. It is expected that as applications may produce posture assessment information, they may share it using a specific data model. Similarly, applications consuming or requesting posture assessment information may require that it be based on a specific data model. Thus, while there may exist different data models and schemas, they should adhere to the SACM information model and meet the requirements defined in this section.
SACM情報モデルは、「どの」情報を伝達できるか、および「どのように」情報を表現および共有できるかを表す抽象概念です。アプリケーションがポスチャ評価情報を生成する可能性があるため、特定のデータモデルを使用して情報を共有することが期待されます。同様に、ポスチャアセスメント情報を使用または要求するアプリケーションでは、特定のデータモデルに基づくことが必要になる場合があります。したがって、さまざまなデータモデルとスキーマが存在する可能性がありますが、それらはSACM情報モデルに準拠し、このセクションで定義されている要件を満たす必要があります。
The specific requirements for candidate data models include:
候補データモデルの具体的な要件は次のとおりです。
DM-001 (Element Association): A SACM information model consists of a set of SACM information model elements. A SACM data model MUST be derived from the SACM information model. A SACM data model consists of a set of SACM data model elements. In this derivation, a SACM data model element MAY map to one or more SACM information model elements. In addition, a SACM data model MAY include additional data model elements that are not associated with any SACM information model elements.
DM-001（要素の関連付け）：SACM情報モデルは、SACM情報モデル要素のセットで構成されています。 SACMデータモデルは、SACM情報モデルから派生する必要があります。 SACMデータモデルは、SACMデータモデル要素のセットで構成されています。この派生では、SACMデータモデル要素は、1つ以上のSACM情報モデル要素にマップされる場合があります。さらに、SACMデータモデルには、SACM情報モデル要素に関連付けられていない追加のデータモデル要素が含まれる場合があります。
DM-002 (Data Model Structure): The data model can be structured either as one single module or separated into modules and submodules that allow for references between them. The data model structure MAY reflect structure in the information model but does not need to. For example, the data model might use one module to define endpoints, and that module might reference other modules that describe the various assets associated with the endpoint. Constraints and interfaces might further be defined to resolve or tolerate ambiguity in the references (e.g., the same IP address used in two separate networks).
DM-002（データモデル構造）：データモデルは、1つの単一モジュールとして構造化することも、モジュールとサブモジュールに分離してモジュール間の参照を可能にすることもできます。データモデルの構造は、情報モデルの構造を反映してもかまいませんが、そうする必要はありません。たとえば、データモデルは1つのモジュールを使用してエンドポイントを定義し、そのモジュールはエンドポイントに関連付けられたさまざまなアセットを記述する他のモジュールを参照する場合があります。参照とあいまいさを解決または許容するために、制約とインターフェースがさらに定義される場合があります（たとえば、2つの別個のネットワークで使用される同じIPアドレス）。
DM-003 (Search Flexibility): The search interfaces and actions MUST include the ability to start a search anywhere within a data model structure and the ability to search based on patterns ("wildcard searches") as well as specific data elements.
DM-003（検索の柔軟性）：検索インターフェースとアクションには、データモデル構造内の任意の場所で検索を開始する機能と、パターン（「ワイルドカード検索」）および特定のデータ要素に基づいて検索する機能を含める必要があります。
DM-004 (Full vs. Partial Updates): The data model SHOULD include the ability to allow providers of data to provide the data as a whole or when updates occur. For example, a consumer can request a full update on initial engagement, then request to receive deltas (updates containing only the changes since the last update) on an ongoing basis as new data is generated.
DM-004（完全更新と部分更新）：データモデルには、データのプロバイダーが全体として、または更新が発生したときにデータを提供できるようにする機能を含める必要があります（SHOULD）。たとえば、コンシューマは最初のエンゲージメントで完全な更新を要求し、新しいデータが生成されると継続的にデルタ（最後の更新以降の変更のみを含む更新）の受信を要求できます。
DM-005 (Loose Coupling): The data model SHOULD allow for a loose coupling between the provider and the consumer, such that the consumer can request information without being required to request it from a specific provider, and a provider can publish information without having a specific consumer targeted to receive it.
DM-005（ルーズカップリング）：データモデルは、プロバイダーとコンシューマーの間のルーズカップリングを許可する必要があります（SHOULD）。これにより、コンシューマーは特定のプロバイダーからの情報を要求せずに情報を要求でき、プロバイダーは情報を公開せずに情報を公開できます。それを受け取ることを目標とした特定の消費者。
DM-006 (Data Cardinality): The data model MUST describe their constraints (e.g., cardinality). As posture information and the tasks for collection, aggregation, or evaluation could comprise one or more attributes, interfaces and actions MUST allow and account for such cardinality and for conditional, optional, or mandatory attributes.
DM-006（データカーディナリティ）：データモデルは制約（カーディナリティなど）を記述しなければなりません（MUST）。ポスチャ情報と収集、集約、または評価のタスクは1つ以上の属性を含む可能性があるため、インターフェイスとアクションは、そのようなカーディナリティと条件付き、オプション、または必須の属性を許可および説明する必要があります。
DM-007 (Data Model Negotiation): The interfaces and actions in the data model MUST include capability negotiation to enable discovery of supported and available data types and schemas.
DM-007（データモデルネゴシエーション）：データモデルのインターフェイスとアクションには、サポートされている使用可能なデータタイプとスキーマの検出を可能にする機能ネゴシエーションを含める必要があります。
DM-008 (Data Origin): The data model MUST include the ability for consumers to identify the data origin (provider that collected the data).
DM-008（データ発信元）：データモデルには、消費者がデータ発信元（データを収集したプロバイダー）を特定する機能が含まれている必要があります。
DM-009 (Origination Time): The data model SHOULD allow the provider to include the information's origination time.
DM-009（発信時間）：データモデルは、プロバイダーが情報の発信時間を含めることを許可する必要があります（SHOULD）。
DM-010 (Data Generation): The data model MUST allow the provider to include attributes defining how the data was generated (e.g., self-reported, reported by aggregator, scan result, etc.).
DM-010（データ生成）：データモデルは、プロバイダーがデータの生成方法を定義する属性を含めることを許可する必要があります（たとえば、自己報告、アグリゲーターによるレポート、スキャン結果など）。
DM-011 (Data Source): The data model MUST allow the provider to include attributes identifying the data source (target endpoint from which the data was collected), e.g., hostname, domain (DNS) name, or application name.
DM-011（データソース）：データモデルは、プロバイダーがデータソース（データの収集元のターゲットエンドポイント）を識別する属性（ホスト名、ドメイン（DNS）名、アプリケーション名など）を含めることを許可する必要があります。
DM-012 (Data Updates): The data model SHOULD allow the provider to include attributes defining whether the information provided is a delta, partial, or full set of information.
DM-012（データの更新）：データモデルは、提供される情報がデルタ、部分的、または完全な情報セットであるかどうかを定義する属性をプロバイダーに含めることを許可する必要があります（SHOULD）。
DM-013 (Multiple Collectors): The data model MUST support the collection of attributes by a variety of collectors, including internal collectors, external collectors with an authenticated relationship with the endpoint, and external collectors based on network and other observers.
DM-013（複数のコレクター）：データモデルは、内部コレクター、エンドポイントとの認証された関係を持つ外部コレクター、ネットワークや他のオブザーバーに基づく外部コレクターなど、さまざまなコレクターによる属性のコレクションをサポートする必要があります。
DM-014 (Attribute Extensibility): All of the use cases in Section 2 of [RFC7632] describe the need for an attribute dictionary. With SACM's scope focused on posture assessment, the data model attribute collection and aggregation MUST have a well-understood set of attributes inclusive of their meaning or usage intent. The data model MUST include all attributes defined in the information model and MAY include additional attributes beyond those found in the information model. Additional attributes MUST be defined in accordance with the extensibility framework provided in the information model (see IM-001).
DM-014（属性の拡張性）：[RFC7632]のセクション2のすべてのユースケースで、属性辞書の必要性について説明しています。 SACMのスコープはポスチャ評価に焦点を当てているため、データモデルの属性の収集と集約には、その意味や使用目的を含め、よく理解された属性のセットが必要です。データモデルには、情報モデルで定義されたすべての属性を含める必要があり、情報モデルで見つかった属性を超える追加の属性を含めることができます（MAY）。追加の属性は、情報モデル（IM-001を参照）で提供される拡張性フレームワークに従って定義する必要があります。
DM-015 (Solicited vs. Unsolicited Updates): The data model MUST enable a provider to publish data either solicited (in response to a request from a consumer) or unsolicited (as new data is generated, without a request required). For example, an external collector can publish data in response to a request by a consumer for information about an endpoint, or it can publish data as it observes new information about an endpoint, without any specific consumer request triggering the publication; a compliance-server provider may publish endpoint posture information in response to a request from a consumer (solicited), or it may publish posture information driven by a change in the posture of the endpoint (unsolicited).
DM-015（要請された更新と要請されていない更新）：データモデルは、プロバイダーが要請された（コンシューマーからの要求に応じて）または要請されていない（要求なしで新しいデータが生成されるため）データを公開できるようにする必要があります。たとえば、外部コレクターは、エンドポイントに関する情報のコンシューマーによる要求に応じてデータを公開できます。または、特定のコンシューマーリクエストが公開をトリガーすることなく、エンドポイントに関する新しい情報を観察しながらデータを公開できます。コンプライアンスサーバープロバイダーは、コンシューマーからの要求に応じてエンドポイントのポスチャ情報を公開するか（要請）、またはエンドポイントのポスチャの変化によって引き起こされるポスチャ情報を公開します（非要請）。
DM-016 (Transfer Agnostic): The data model MUST be transfer agnostic, to allow for the data operations to leverage the most appropriate SACM transfer protocol.
DM-016（転送不可知論）：データモデルが転送不可知論でなければならず、データ操作が最も適切なSACM転送プロトコルを活用できるようにする必要があります。
Posture information data adhering to a data model must also provide interfaces that include operations for access and production of the data. Operations requirements are distinct from transfer requirements in that operations requirements are requirements on the application performing requests and responses, whereas transfer requirements are requirements on the transfer protocol carrying the requests and responses. The specific requirements for such operations include:
データモデルに準拠する姿勢情報データは、データのアクセスと生成のための操作を含むインターフェイスも提供する必要があります。操作要件は、要求と応答を実行するアプリケーションの要件であるのに対して、操作要件は転送要件とは異なりますが、転送要件は、要求と応答を伝送する転送プロトコルの要件です。このような操作の特定の要件は次のとおりです。
OP-001 (Time Synchronization): Request and response operations MUST be timestamped, and published information SHOULD capture time of publication. Actions or decisions based on time-sensitive data (such as user logon/logoff, endpoint connection/disconnection, endpoint behavior events, etc.) are all predicated on a synchronized understanding of time. A method for detecting and reporting time discrepancies SHOULD be provided.
OP-001（Time Synchronization）：リクエストとレスポンスの操作にはタイムスタンプを付ける必要があり、公開情報は公開の時刻をキャプチャする必要があります（SHOULD）。時間に依存するデータ（ユーザーのログオン/ログオフ、エンドポイントの接続/切断、エンドポイントの動作イベントなど）に基づくアクションまたは決定は、時間の同期された理解に基づいています。時間の不一致を検出して報告する方法を提供する必要があります。
OP-002 (Collection Abstraction): Collection is the act of a SACM component gathering data from a target endpoint. The request for a data item MUST include enough information to properly identify the item to collect, but the request shall not be a command to directly execute nor be directly applied as arguments to a command. The purpose of this requirement is primarily to reduce the potential attack vectors but has the additional benefit of abstracting the request for collection from the collection method, thereby allowing more flexibility in how collection is implemented.
OP-002（コレクションの抽象化）：コレクションは、ターゲットエンドポイントからデータを収集するSACMコンポーネントの動作です。データアイテムのリクエストには、収集するアイテムを適切に特定するのに十分な情報を含める必要がありますが、リクエストは直接実行するコマンドであってはならず、コマンドの引数として直接適用することもできません。この要件の目的は、主に潜在的な攻撃ベクトルを減らすことですが、収集方法から収集の要求を抽象化するという追加の利点があり、それによって収集の実装方法の柔軟性が高まります。
OP-003 (Collection Composition): A collection request MAY be composed of multiple collection requests (which yield collected values). The desire for multiple values MUST be expressed as part of the collection request, so that the aggregation can be resolved at the point of collection without having to interact with the requestor. This requirement should not be interpreted as preventing a collector from providing attributes that were not part of the original request.
OP-003（収集構成）：収集要求は、複数の収集要求（収集された値を生成する）で構成される場合があります。複数の値の要求は、収集要求の一部として表現されなければならない（MUST）ので、要求元と対話する必要なく、収集の時点で集約を解決できます。この要件は、コレクターが元の要求の一部ではなかった属性を提供できないように解釈されるべきではありません。
OP-004 (Attribute-Based Query): A query operation is the act of requesting data from a provider. Query operations SHOULD be based on a set of attributes. Query operations MUST support both a query for specific attributes and a query for all attributes. The use case in Section 2.1.2 of [RFC7632] describes the need for the data model to support a query operation based on a set of attributes to facilitate collection of information such as posture assessment, inventory (of endpoints or endpoint components), and configuration checklist.
OP-004（属性ベースのクエリ）：クエリ操作は、プロバイダーにデータを要求する行為です。クエリ操作は、一連の属性に基づく必要があります（SHOULD）。クエリ操作は、特定の属性のクエリとすべての属性のクエリの両方をサポートする必要があります。 [RFC7632]のセクション2.1.2の使用例では、ポスチャ評価、インベントリ（エンドポイントまたはエンドポイントコンポーネントの）などの情報の収集を容易にするために、データモデルが一連の属性に基づくクエリ操作をサポートする必要性について説明しています。構成チェックリスト。
OP-005 (Information-Based Query with Filtering): The query operation MUST support filtering. The use case in Section 2.1.3 of [RFC7632] describes the need for the data model to support the means for the information to be collected through a query mechanism. Furthermore, the query operation requires filtering capabilities to allow for only a subset of information to be retrieved. The query operation MAY be a synchronous request or asynchronous request.
OP-005（フィルタリング付きの情報ベースのクエリ）：クエリ操作はフィルタリングをサポートする必要があります。 [RFC7632]のセクション2.1.3の使用例は、クエリメカニズムを通じて情報を収集する手段をサポートするデータモデルの必要性を説明しています。さらに、クエリ操作には、情報のサブセットのみを取得できるようにするフィルタリング機能が必要です。クエリ操作は、同期リクエストまたは非同期リクエストである場合があります。
OP-006 (Operation Scalability): The operation resulting from a query operation MUST be able to handle the return and receipt of large amounts of data. The use case in Section 2.1.4 of [RFC7632] describe the need for the data model to support scalability. For example, the query operation may result in a very large set of attributes as well as a large set of targets.
OP-006（操作のスケーラビリティ）：クエリ操作の結果の操作は、大量のデータの返送と受信を処理できなければなりません（MUST）。 [RFC7632]のセクション2.1.4のユースケースは、データモデルがスケーラビリティをサポートする必要性を説明しています。たとえば、クエリ操作の結果、非常に大きな属性のセットと大きなターゲットのセットが生成される場合があります。
OP-007 (Data Abstraction): The data model MUST allow a SACM component to communicate what data was used to construct the target endpoint's identity, so that other SACM components can determine whether they are constructing an equivalent target endpoint (and its identity) and whether they have confidence in that identity. SACM components SHOULD have interfaces defined to transmit this data directly or to refer to where the information can be retrieved.
OP-007（データ抽象化）：データモデルでは、SACMコンポーネントがターゲットエンドポイントのIDの構築に使用されたデータを通信できるようにする必要があります。これにより、他のSACMコンポーネントは、同等のターゲットエンドポイント（およびそのID）を構築しているかどうかを判断できます。彼らがそのアイデンティティに自信を持っているかどうか。 SACMコンポーネントには、このデータを直接送信するか、情報を取得できる場所を参照するように定義されたインターフェースが必要です（SHOULD）。
OP-008 (Provider Restriction): Request operations MUST include the ability to restrict the data to be provided by a specific provider or a provider with specific characteristics. Response operations MUST include the ability to identify the provider that supplied the response. For example, a SACM consumer should be able to request that all of the data come from a specific provider by identity (e.g., Provider A) or from a provider that is in a specific location (e.g., in the Boston office).
OP-008（プロバイダー制限）：要求操作には、特定のプロバイダーまたは特定の特性を持つプロバイダーによって提供されるデータを制限する機能を含める必要があります。応答操作には、応答を提供したプロバイダーを識別する機能が含まれている必要があります。たとえば、SACMコンシューマーは、すべてのデータが特定のプロバイダー（IDなど）から、または特定の場所にあるプロバイダー（ボストンオフィスなど）からのものであることを要求できる必要があります。
The term "SACM transfer protocol" is intended to be distinguished from underlying transport- and internet-layer protocols such as TCP/ IP or operating at an application-layer protocol such as HTTP. The SACM transfer protocol is focused on moving data and performing necessary access control operations; it is agnostic to the data model operations.
「SACM転送プロトコル」という用語は、TCP / IPなどの基礎となるトランスポート層およびインターネット層のプロトコルや、HTTPなどのアプリケーション層のプロトコルで動作するものと区別されることを目的としています。 SACM転送プロトコルは、データの移動と必要なアクセス制御操作の実行に重点を置いています。データモデルの操作には依存しません。
The requirements for SACM transfer protocols include:
SACM転送プロトコルの要件は次のとおりです。
T-001 (Multiple Transfer Protocol Support): SACM transfer protocols will vary depending on the deployment model that relies on different transfer-layer requirements, different device capabilities, and system configurations dealing with connectivity. For example, where posture attributes may be collected directly from an endpoint using the Network Endpoint Assessment (NEA) model [RFC5209], different transports may be defined to collect them using Posture Transport Protocol for Extensible Authentication Protocol Tunnel Methods (PT-EAP) [RFC7171] or Posture Transport Protocol over TLS (PT-TLS) [RFC6876], depending on the deployment scenario.
T-001（複数転送プロトコルのサポート）：SACM転送プロトコルは、さまざまな転送レイヤー要件、さまざまなデバイス機能、および接続を処理するシステム構成に依存する展開モデルによって異なります。たとえば、ポスチャ属性がネットワークエンドポイントアセスメント（NEA）モデル[RFC5209]を使用してエンドポイントから直接収集される場合、さまざまなトランスポートが定義され、拡張認証プロトコルトンネル方式のポスチャトランスポートプロトコル（PT-EAP）を使用して収集されます。 RFC7171]またはポスチャトランスポートプロトコルオーバーTLS（PT-TLS）[RFC6876]、展開シナリオによって異なります。
T-002 (Data Integrity): SACM transfer protocols MUST be able to ensure data integrity for data in transit.
T-002（データの完全性）：SACM転送プロトコルは、転送中のデータのデータの完全性を保証できなければなりません（MUST）。
T-003 (Data Confidentiality): SACM transfer protocols MUST be able to support data confidentiality. SACM transfer protocols MUST ensure data protection for data in transit (e.g., by encryption) to provide confidentiality, integrity, and robustness against protocol-based attacks. Note that while the transfer MUST be able to support data confidentiality, implementations MAY provide a configuration option that enables and disables confidentiality in deployments. Protection for data at rest is not in scope for transfer protocols. Data protection MAY be used for both privacy and non-privacy scenarios.
T-003（データ機密性）：SACM転送プロトコルはデータ機密性をサポートできなければなりません（MUST）。 SACM転送プロトコルは、プロトコルベースの攻撃に対する機密性、整合性、および堅牢性を提供するために、転送中のデータ（たとえば、暗号化による）のデータ保護を保証する必要があります。転送はデータの機密性をサポートできなければならないことに注意してください。実装は、デプロイメントの機密性を有効または無効にする構成オプションを提供する場合があります。保存データの保護は、転送プロトコルの範囲外です。データ保護は、プライバシーと非プライバシーの両方のシナリオで使用できます。
T-004 (Transfer Protection): SACM transfer protocols MUST be capable of supporting mutual authentication and replay protection.
T-004（転送保護）：SACM転送プロトコルは、相互認証とリプレイ保護をサポートできなければなりません（MUST）。
T-005 (Transfer Reliability): SACM transfer protocols MUST provide reliable delivery of data. This includes the ability to perform fragmentation and reassembly and to detect replays. The SACM transfer may take advantage of reliability features in the network transport; however, the network transport may be unreliable (e.g., UDP), in which case the SACM transfer running over the unreliable network transport is responsible for ensuring reliability (i.e., by provisions such as confirmations and retransmits).
T-005（転送の信頼性）：SACM転送プロトコルは、データの信頼できる配信を提供する必要があります。これには、断片化と再構成を実行し、リプレイを検出する機能が含まれます。 SACM転送では、ネットワーク転送の信頼性機能を利用できます。ただし、ネットワークトランスポートは信頼できない可能性があります（UDPなど）。この場合、信頼できないネットワークトランスポート上で実行されるSACM転送は、信頼性を保証する責任があります（つまり、確認や再送信などの規定による）。
T-006 (Transfer-Layer Requirements): Each SACM transfer protocol MUST clearly specify the transport-layer requirements it needs to operate correctly. Examples of items that may need to be specified include connectivity requirements, replay requirements, data link encryption requirements, and/or channel-binding requirements. These requirements are needed in order for deployments to be done correctly.
T-006（転送層要件）：各SACM転送プロトコルは、正しく動作するために必要な転送層要件を明確に指定する必要があります。指定する必要がある項目の例には、接続要件、リプレイ要件、データリンク暗号化要件、チャネルバインディング要件などがあります。これらの要件は、展開を正しく行うために必要です。
T-007 (Transfer Protocol Adoption): SACM SHOULD, where reasonably possible, leverage and use existing IETF transfer protocols versus defining new ones.
T-007（転送プロトコルの採用）：SACMは、可能であれば、既存のIETF転送プロトコルを活用して使用し、新しいプロトコルを定義する必要はありません（SHOULD）。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
This document defines the requirements for SACM. As such, it is expected that several data models, protocols, and transfer protocols may be defined or reused from already-existing standards.
このドキュメントでは、SACMの要件を定義します。そのため、既存の標準からいくつかのデータモデル、プロトコル、および転送プロトコルを定義または再利用することが期待されます。
To address security and privacy considerations, the data model, protocols, and transports must consider authorization based on consumer function and privileges, to only allow authorized consumers and providers to access specific information being requested or published.
セキュリティとプライバシーの考慮事項に対処するには、データモデル、プロトコル、およびトランスポートで、コンシューマーの機能と特権に基づいて承認を検討し、承認されたコンシューマーとプロバイダーが要求または公開されている特定の情報にのみアクセスできるようにする必要があります。
To enable federation across multiple entities (such as across organizational or geographic boundaries), authorization must also extend to infrastructure elements themselves, such as central controllers, brokers, and data repositories.
複数のエンティティ（組織または地理的な境界など）にわたるフェデレーションを有効にするには、中央コントローラー、ブローカー、データリポジトリなどのインフラストラクチャ要素自体にも承認を拡張する必要があります。
In addition, authorization needs to extend to specific information or resources available in the environment. In other words, authorization is based on the subject (the information requestor), the provider (the information responder), the object (the endpoint the information is being requested on), and the attribute (what piece of data is being requested). The method by which this authorization is applied is unspecified.
さらに、認可は、環境で利用可能な特定の情報またはリソースにまで及ぶ必要があります。つまり、承認は、サブジェクト（情報要求者）、プロバイダー（情報応答者）、オブジェクト（情報が要求されているエンドポイント）、および属性（要求されているデータの一部）に基づいています。この認証が適用される方法は指定されていません。
SACM's charter focuses on the workflow orchestration and the sharing of posture information for improving the efficacy of security applications such as compliance, configuration, assurance, and other threat and vulnerability reporting and remediation systems. While the goal is to facilitate the flow of information securely, it is important to note that participating endpoints may not be cooperative or trustworthy.
SACMの憲章は、コンプライアンス、構成、保証、およびその他の脅威と脆弱性のレポートと修復システムなどのセキュリティアプリケーションの効率を改善するためのワークフローオーケストレーションとポスチャ情報の共有に重点を置いています。目標は情報の流れを安全に円滑にすることですが、参加するエンドポイントは協調的でも信頼できるものでもない場合があることに注意することが重要です。
The information given from the provider to a requestor may come with different levels of trustworthiness given the different potential deployment scenarios and compromise at the provider, the requesting consumer, or devices that are involved in the transfer between the provider and requestor. This section will describe the different considerations that may reduce the level of trustworthiness of the information provided.
プロバイダーからリクエスターに提供される情報は、さまざまな潜在的な展開シナリオとプロバイダー、要求側のコンシューマー、またはプロバイダーとリクエスター間の転送に関与するデバイスでの妥協により、信頼性のレベルが異なる場合があります。このセクションでは、提供される情報の信頼性のレベルを低下させる可能性があるさまざまな考慮事項について説明します。
In the information transfer flow, it is possible that some of the devices may serve as proxies or brokers and, as such, may be able to observe the communications flowing between an information provider and requestor. Without appropriate protections, it is possible for these proxies and brokers to inject and affect man-in-the-middle attacks.
情報転送フローでは、一部のデバイスがプロキシまたはブローカーとして機能し、そのため、情報プロバイダーとリクエスターの間を流れる通信を監視できる場合があります。適切な保護がないと、これらのプロキシとブローカーが中間者攻撃を仕掛けて影響を与える可能性があります。
In general, it is common to distrust the network service provider, unless the full hop-by-hop communications process flow is well understood. As such, the posture information provider should protect the posture information data it provides as well as the transfer it uses. Similarly, while there may be providers whose goal is to openly share its information, there may also be providers whose policy is to grant access to certain posture information based on its business or regulatory policy. In those situations, a provider may require full authentication and authorization of the requestor (or set of requestors) and share only the authorized information to the authenticated and authorized requestors.
一般に、完全なホップバイホップの通信プロセスフローが十分に理解されていない限り、ネットワークサービスプロバイダーを信用しないことが一般的です。そのため、ポスチャ情報プロバイダーは、提供するポスチャ情報データと使用する転送を保護する必要があります。同様に、情報をオープンに共有することを目的とするプロバイダーも存在しますが、ビジネスまたは規制ポリシーに基づいて特定のポスチャ情報へのアクセスを許可することをポリシーとするプロバイダーも存在する可能性があります。これらの状況では、プロバイダーはリクエスター（またはリクエスターのセット）の完全な認証と承認を必要とし、認証されたリクエスターと承認されたリクエスターに承認された情報のみを共有する場合があります。
Beyond distrusting the network service provider, a requestor must also take into account that the information received from the provider may have been communicated through an undetermined network communications system. That is, the posture information may have traversed through many devices before reaching the requestor. SACM specifications should provide the means for verifying data origin and data integrity and, at minimum, provide endpoint authentication and transfer integrity.
リクエスタは、ネットワークサービスプロバイダーを信用しないだけでなく、プロバイダーから受信した情報が未確定のネットワーク通信システムを介して通信された可能性があることも考慮する必要があります。つまり、要求者に到達する前に、ポスチャ情報が多くのデバイスを通過した可能性があります。 SACM仕様は、データの発信元とデータの整合性を検証する手段を提供し、少なくともエンドポイントの認証と転送の整合性を提供する必要があります。
A requestor may require data freshness indications, both knowledge of data origination as well as time of publication, so that it can make more informed decisions about the relevance of the data based on its currency and/or age.
リクエスタは、データの最新性の表示を要求する場合があります。これは、データの発生に関する知識と公開時間の両方を必要とするため、データの最新性や最新性に基づいて、データの関連性についてより多くの情報に基づいた決定を行うことができます。
It is also important to note that endpoint assessment reports, especially as they may be provided by the target endpoint, may pose untrustworthy information. The considerations for this are described in Section 8 of [RFC5209].
エンドポイント評価レポートは、特にターゲットエンドポイントによって提供される場合があるため、信頼できない情報を提供する可能性があることに注意することも重要です。これに関する考慮事項は、[RFC5209]のセクション8で説明されています。
The trustworthiness of the posture information given by the provider to one or many requestors is dependent on several considerations. Some of these include the requestor requiring:
プロバイダーから1つまたは多数の要求者に提供されるポスチャ情報の信頼性は、いくつかの考慮事項に依存しています。これらの一部には、以下を必要とする要求者が含まれます。
o Full disclosure of the network topology path to the provider(s).
o プロバイダーへのネットワークトポロジパスの完全な開示。
o Direct (peer-to-peer) communication with the provider.
o プロバイダーとの直接（ピアツーピア）通信。
o Authentication and authorization of the provider.
o プロバイダーの認証と承認。
o Either or both confidentiality and integrity at the transfer layer.
o 転送層での機密性と整合性のいずれかまたは両方。
o Either or both confidentiality and integrity at the data layer.
o データ層での機密性と整合性のいずれかまたは両方。
SACM information may contain sensitive information about the target endpoint as well as revealing identity information of the producer or consumer of such information. Similarly, as part of the SACM discovery mechanism, the capabilities and roles (e.g., SACM components enabled) advertised by the endpoint may be construed as private information.
SACM情報には、ターゲットエンドポイントに関する機密情報や、そのような情報の生産者または消費者のID情報が含まれている場合があります。同様に、SACMディスカバリメカニズムの一部として、エンドポイントによってアドバタイズされる機能とロール（たとえば、SACMコンポーネントが有効）は、プライベート情報として解釈される場合があります。
In addition to identity and SACM capabilities information disclosure, the use of timestamps (or other attributes that can be used as identifiers) could be further used to determine a target endpoint or user's behavioral patterns. Such attributes may also be deemed sensitive and may require further protection or obfuscation to meet privacy concerns. That is, there may be applications as well as business and regulatory practices that require that aspects of such information be hidden from any parties that do not need to know it.
IDとSACM機能の情報開示に加えて、タイムスタンプ（または識別子として使用できるその他の属性）の使用をさらに使用して、ターゲットエンドポイントまたはユーザーの行動パターンを決定できます。このような属性も機密と見なされる可能性があり、プライバシーの懸念を満たすために、さらなる保護または難読化が必要になる場合があります。つまり、そのような情報の側面を、それを知る必要のない関係者から隠すことを要求するビジネスや規制慣行だけでなく、アプリケーションがあるかもしれません。
Data confidentiality can provide some level of privacy but may fall short where unnecessary data is still transmitted. In those cases, filtering requirements at the data model such as OP-005 must be applied to ensure that such data is not disclosed. [RFC6973] provides guidelines that SACM protocols, information models, and data models should follow.
データの機密性はある程度のプライバシーを提供できますが、不要なデータがまだ送信されている場合は不十分な場合があります。このような場合、OP-005などのデータモデルでのフィルタリング要件を適用して、そのようなデータが公開されないようにする必要があります。 [RFC6973]は、SACMプロトコル、情報モデル、およびデータモデルが従うべきガイドラインを提供します。
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, <https://www.rfc-editor.org/info/rfc7632>.
[RFC7632] Waltermire、D。およびD. Harrington、「Endpoint Security Posture Assessment：Enterprise Use Cases」、RFC 7632、DOI 10.17487 / RFC7632、2015年9月、<https://www.rfc-editor.org/info/rfc7632 >。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, <https://www.rfc-editor.org/info/rfc5209>.
[RFC5209] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「Network Endpoint Assessment（NEA）：Overview and Requirements」、RFC 5209、DOI 10.17487 / RFC5209、June 2008、<https://www.rfc-editor.org/info/rfc5209>。
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013, <https://www.rfc-editor.org/info/rfc6876>.
[RFC6876] Sangster、P.、Cam-Winget、N。、およびJ. Salowey、「A Posture Transport Protocol over TLS（PT-TLS）」、RFC 6876、DOI 10.17487 / RFC6876、2013年2月、<https：// www.rfc-editor.org/info/rfc6876>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, <https://www.rfc-editor.org/info/rfc7171>.
[RFC7171] Cam-Winget、N。およびP. Sangster、「PT-EAP：Posture Transport（PT）Protocol for Extensible Authentication Protocol（EAP）Tunnel Methods」、RFC 7171、DOI 10.17487 / RFC7171、2014年5月、<https： //www.rfc-editor.org/info/rfc7171>。
[TERMS] Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, "Security Automation and Continuous Monitoring (SACM) Terminology", Work in Progress, draft-ietf-sacm-terminology-13, July 2017.
[用語] Birkholz、H.、Lu、J.、Strassner、J。、およびN. Cam-Winget、「セキュリティ自動化および継続的監視（SACM）用語」、作業中、draft-ietf-sacm-terminology-13 、2017年7月。
Acknowledgments
謝辞
The authors would like to thank Barbara Fraser, Jim Bieda, and Adam Montville for reviewing and contributing to this document. In addition, we recognize valuable comments and suggestions made by Jim Schaad and Chris Inacio.
著者は、このドキュメントをレビューして貢献してくれたBarbara Fraser、Jim Bieda、およびAdam Montvilleに感謝します。さらに、ジムシャードとクリスイナシオによる貴重なコメントと提案を認識しています。
Authors' Addresses
著者のアドレス
Nancy Cam-Winget Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
Nancy Cam-Winget Cisco Systems 3550 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: ncamwing@cisco.com
Lisa Lorenzin Pulse Secure 2700 Zanker Rd., Suite 200 San Jose, CA 95134 United States of America
Lisa Lorenzin Pulse Secure 2700 Zanker Rd。、Suite 200 San Jose、CA 95134アメリカ合衆国
Email: llorenzin-ietf@1000plus.com