RFC3881 日本語訳
3881 Security Audit and Access Accountability Message XML DataDefinitions for Healthcare Applications. G. Marshall. September 2004. (Format: TXT=86130 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Marshall Request for Comments: 3881 Siemens Category: Informational September 2004
コメントを求めるワーキンググループG.マーシャル要求をネットワークでつないでください: 3881年のジーメンスカテゴリ: 情報の2004年9月
Security Audit and Access Accountability Message
XML Data Definitions for Healthcare Applications
ヘルスケアアプリケーションのためのセキュリティ監査とアクセス責任メッセージXMLデータ定義
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and notes that it has not had IETF review. The RFC Editor has chosen to publish this document at its discretion.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的、およびそれにはIETFレビューがないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。
Abstract
要約
This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data.
このドキュメントは、ヘルスケアアプリケーション・システムのセキュリティー監査のためにキャプチャされる必要がある集まっていて最小のセットの属性になるようにデータの書式を定義します。書式はXML図式と定義されます。(それは、ヘルスケア規格開発者とアプリケーション設計者の参照として意図します)。 それはヘルスケアデータのセキュリティー監査の前のいくつかのドキュメントを統合します。
Marshall Informational [Page 1] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[1ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
Table of Contents
目次
1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Data Collection . . . . . . . . . . . . . . . . . . . . . 4
2.2. Anticipated Data End-uses . . . . . . . . . . . . . . . . 5
2.3. Conformance . . . . . . . . . . . . . . . . . . . . . . . 6
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Effective Data Gathering. . . . . . . . . . . . . . . . . 6
3.2. Efficiency. . . . . . . . . . . . . . . . . . . . . . . . 7
4. Trigger Events. . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Security Administration . . . . . . . . . . . . . . . . . 8
4.2. Audit Administration and Data Access. . . . . . . . . . . 9
4.3. User Access . . . . . . . . . . . . . . . . . . . . . . . 10
5. Data Definitions. . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Event Identification. . . . . . . . . . . . . . . . . . . 13
5.2. Active Participant Identification . . . . . . . . . . . . 17
5.3. Network Access Point Identification . . . . . . . . . . . 20
5.4. Audit Source Identification . . . . . . . . . . . . . . . 22
5.5. Participant Object Identification . . . . . . . . . . . . 24
6. XML Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. XML Schema Definition . . . . . . . . . . . . . . . . . . 31
6.2. XML Schema Localization . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 44
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References. . . . . . . . . . . . . . . . . . . 44
8.2. Informative References. . . . . . . . . . . . . . . . . . 45
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47
1. 目的. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 データ収集. . . . . . . . . . . . . . . . . . . . . 4 2.2。 データ最終用途. . . . . . . . . . . . . . . . 5 2.3を予期しました。 順応. . . . . . . . . . . . . . . . . . . . . . . 6 3。 目標. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1。 有効なデータ集会。 . . . . . . . . . . . . . . . . 6 3.2. 効率。 . . . . . . . . . . . . . . . . . . . . . . . 7 4. イベントの引き金となってください。 . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. セキュリティ政権. . . . . . . . . . . . . . . . . 8 4.2。 政権とデータ・アクセスを監査してください。 . . . . . . . . . . 9 4.3. ユーザアクセス. . . . . . . . . . . . . . . . . . . . . . . 10 5。 データ定義。 . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. イベント識別。 . . . . . . . . . . . . . . . . . . 13 5.2. 積極的な参加者識別. . . . . . . . . . . . 17 5.3。 アクセスポイント識別. . . . . . . . . . . 20 5.4をネットワークでつないでください。 ソース識別. . . . . . . . . . . . . . . 22 5.5を監査してください。 関与しているオブジェクト識別. . . . . . . . . . . . 24 6。 XML図式。 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. XML図式定義. . . . . . . . . . . . . . . . . . 31 6.2。 XML図式ローカライズ. . . . . . . . . . . . . . . . . 43 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 44 8。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.1. 引用規格。 . . . . . . . . . . . . . . . . . . 44 8.2. 有益な参照。 . . . . . . . . . . . . . . . . . 45の承認。 . . . . . . . . . . . . . . . . . . . . . . . . . 45作者のアドレスの.46の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 47
1. Purpose
1. 目的
To help assure healthcare privacy and security in automated systems, usage data needs to be collected. This data will be reviewed by administrative staff to verify that healthcare data is being used in accordance with the healthcare provider's data security requirements and to establish accountability for data use. This data collection and review process is called security auditing.
自動化されたシステムにおけるヘルスケアプライバシーとセキュリティを保証するのを助けるために、用法データは、集められる必要があります。 このデータは、医療サービス提供者のデータ機密保護要件に従ってヘルスケアデータが使用されていることを確かめて、データ使用のために責任を証明するために管理職員によって再検討されるでしょう。 このデータ収集と吟味の過程はセキュリティー監査と呼ばれます。
This document defines the format of the data to be collected and minimum set of attributes that need to be captured by healthcare application systems for subsequent use by an automation-assisted review application. The data includes records of who accessed healthcare data, when, for what action, from where, and which
このドキュメントは、その後の使用のヘルスケアアプリケーション・システムによってオートメーションで補助されたレビューアプリケーションでキャプチャされる必要がある集まっていて最小のセットの属性になるようにデータの書式を定義します。 そして、データがだれがどんな動作のためにどこからヘルスケアデータ、いつにアクセスしたかに関する記録を含んでいる、どれ
Marshall Informational [Page 2] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[2ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
patients' records were involved. The data definition is an XML schema to be used as a reference by healthcare standards developers and application designers.
患者の記録はかかわりました。 データ定義はヘルスケア規格開発者とアプリケーション設計者による参照として使用されるべきXML図式です。
This document consolidates previously disjointed viewpoints of security auditing from Health Level 7 (HL7) [HL7SASIG], Digital Imaging and Communications in Medicine (DICOM) Working Group 14, Integrating the Healthcare Enterprise (IHE) [IHETF-3], the ASTM International Healthcare Informatics Technical Committee (ASTM E31) [E2147], and the Joint NEMA/COCIR/JIRA Security and Privacy Committee [NEMASPC]. It is intended as a reference for these groups and other healthcare standards developers.
このドキュメントはセキュリティー監査の以前にばらばらの観点をDigitalのHealth Level7(HL7)[HL7SASIG]、Imaging、およびCommunicationsからMedicine(DICOM)作業部会14、Integrating Healthcareエンタープライズ(IHE)[IHETF-3]、ASTMの国際Healthcare Informatics Technical Committee(ASTM E31)[2147E]、Jointネーマ/COCIR/JIRA Security、およびPrivacy Committee[NEMASPC]に統合します。 それはこれらのグループと他のヘルスケア規格開発者の参照として意図します。
The purposes the document fulfills are to:
ドキュメントが実現させる目的は以下のことのためのことです。
1) Define data to be communicated for evidence of compliance with, or
violations of, a healthcare enterprise's security and privacy
policies and objectives.
1) 承諾に関する証拠のためにコミュニケートするべきデータを定義する、違反、ヘルスケア企業のセキュリティ、プライバシーに関する方針、および目的。
This document defines the audit message format and content for
healthcare application systems. The focus of auditing is to
retrospectively detect and report security/privacy breaches. This
includes capturing data that supports individual accountability
for patient record creation, access, updates, and deletions.
このドキュメントはヘルスケアアプリケーション・システムのための監査メッセージ・フォーマットと内容を定義します。監査の焦点は、回顧的にセキュリティ/プライバシー不履行を検出して、報告することになっています。 これは、患者記録のために個々の責任をサポートするデータとして作成、アクセス、アップデート、および削除を得るのを含んでいます。
This document does not define healthcare security and privacy
policies or objectives. It also does not include real-time access
alarm actions since there is a perception in the healthcare
community that security measures that inhibit access may also
inhibit effective patient care, under some circumstances.
このドキュメントはヘルスケアセキュリティとプライバシーに関する方針か目的を定義しません。 また、知覚がアクセスを抑制する安全策がそうするヘルスケア共同体にあるので、それはリアルタイムのアクセス警報動作を含んでいません、また、有効な患者管理を抑制してください、いくつかの状況で。
2) Depict the data that would potentially reside in a common audit
engine or database.
2) 一般的な監査エンジンかデータベースに潜在的にあるデータについて表現してください。
Privacy and security audit data is to be collected on each
hardware system, and there are likely to be separate local data
stores for system-level and application-level audits. Collating
these records and providing a common view - transcending hardware
system boundaries - is seen as necessary for cost-effective
security and privacy policy administration.
プライバシーとセキュリティ監査データはそれぞれのハードウェアシステムに集められることです、そして、システムレベルのための別々の地方のデータ・ストアとアプリケーションレベル監査がありそうです。 ハードウェアシステム限界を超えていて、これらの記録を照合して、共通認識を提供するのは費用対効果に優れたセキュリティとプライバシーに関する方針管理に必要であるとみなされます。
The data definitions in this document support such a collation,
but the technical implementation alternatives are not covered in
this document.
データ定義は本書ではそのような照合をサポートしますが、技術的実装代替手段は本書ではカバーされていません。
Marshall Informational [Page 3] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[3ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
3) Depict data that allows useful queries against audited events.
3) 監査のイベントに対して役に立つ質問を許すデータについて表現してください。
Audit data, in its raw form, reflects a sequential view of system
activity. Useful inquiries for security and privacy
administration need workflow, business process, organizational,
role, and person-oriented views. Data definitions in this
document anticipate and support creating those views and queries,
but do not define them.
監査データはシステム活動の連続した視点を生のフォームに反映します。 セキュリティの役に立つ問い合せとプライバシー管理は作業フロー、ビジネスプロセス、組織的で、役割の、そして、人指向の視点を必要とします。 データ定義は、本書ではそれらの視点を作成して、質問を予期して、サポートしますが、それらを定義しません。
4) Provide a common reference standard for healthcare IT standards
development organizations.
4) ヘルスケアIT規格開発組織に一般的な基準ゲージを提供してください。
By specifying an XML schema, this document anticipates extensions
to the base schema to meet requirements of healthcare standards
bodies and application developers.
XML図式を指定することによって、このドキュメントはヘルスケア標準化団体とアプリケーション開発者の必要条件を満たすためにベース図式に拡大を予期します。
2. Scope
2. 範囲
2.1. Data Collection
2.1. データ収集
This document specifies audit data to be collected and communicated from automated systems. It does not include non-automated processes.
このドキュメントは、自動化されたシステムから集められて、コミュニケートするために監査データを指定します。それは非自動化されたプロセスを含んでいません。
Data for events in the above categories may be selectively collected, based on healthcare organization policy. This document does not specify any baseline or minimal policies.
上のカテゴリにおけるイベントのためのデータはヘルスケア組織方針に基づいて選択的に集められるかもしれません。 このドキュメントはどんな基線や最小量の方針も指定しません。
For each audited event, this document specifies the minimal data requirements plus optional data for the following event categories:
それぞれの監査のイベントとして、このドキュメントは以下のイベントカテゴリのための最小量のデータ要件と任意のデータを指定します:
1) Security administrative events - establishing and maintaining
security policy definitions, secured object definitions, role
definitions, user definitions, and the relationships among them.
In general, these events are specific to the administrative
applications.
1) セキュリティの管理イベント--オブジェクト定義と、役割の定義と、ユーザ定義と、それらの中の関係であることが保証された安全保障政策定義を、確立して、維持します。 一般に、これらのイベントは管理アプリケーションに特定です。
2) Audit access events - reflecting special protections implemented
for the audit trail itself.
2) 監査アクセスイベント--反射している特別な保護は監査証跡にそれ自体を実装しました。
3) Security-mediated events - recording entity identification and
authentication, data access, function access, nonrepudiation,
cryptographic operations, and data import/export for messages and
reports. In general, these events are generic to all protected
resources, without regard to the application data content.
3) セキュリティで調停されたイベント--実体識別と認証を記録して、データ・アクセス、機能アクセス、非拒否、暗号の操作、およびデータは、メッセージとレポートのためにインポートするか、またはエクスポートします。 一般に、これらのイベントはアプリケーションデータ内容への尊敬のないすべての保護されたリソースへのジェネリックです。
Marshall Informational [Page 4] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[4ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
4) Patient care data events - documenting what was done, by whom,
using which resources, from what access points, and to whose
medical data. In general, these audits are application-specific
since they require knowledge of the application data content.
4) 患者管理データイベント--何がどのリソースを使用するかでだれによって行われたかを記録して、どんなアクセスポイントと、そして、医学のデータに。 一般に、彼らがアプリケーションデータ内容に関する知識を必要とするので、これらの監査はアプリケーション特有です。
Security subsystems found in most system infrastructures include a capability to capture system-level security relevant events like log-on and security object accesses. This document does not preclude such functions being enabled to record and supply the data defined in this document, but transformation of the collected data to the common XML schema definition may be necessary to support requirements consolidated auditing views.
ほとんどのシステムインフラストラクチャで見つけられたセキュリティサブシステムはシステムレベルセキュリティがログオンとセキュリティオブジェクトアクセスのように関連イベントであるとキャプチャする能力を含んでいます。 このドキュメントは記録するのが可能にされるそのような機能とデータが本書では定義した供給を排除しませんが、一般的なXML図式定義への集まっているデータの変換が、視点を監査しながら、要件が統合したサポートに必要であるかもしれません。
Application-level events, such as patient record access, are not captured by system-level security audits. The defined data support applications' record access auditing for healthcare institutional security and privacy assurance plus related policy administration functions.
患者記録アクセスなどのアプリケーションレベルイベントはシステムレベルセキュリティ監査によって得られません。 定義されたデータはヘルスケアの制度上のセキュリティ、プライバシー保証、および関連する方針管理のために機能を監査するアプリケーションの記録的なアクセスをサポートします。
System-local data definitions for collection and storage of audit data, prior to transformation to a common schema and transmission to a common repository, are not included in this document.
収集のためのシステム地方のデータ定義と一般的な図式への変換と一般的な倉庫へのトランスミッションの前の監査データのストレージは本書では含まれていません。
2.2. Anticipated Data End-uses
2.2. 予期されたデータ最終用途
This document anticipates, but does not define, end-uses for the data collected.
予期しますが、このドキュメントが定義しない、データのための最終用途は集まりました。
The typical healthcare IT environment contains many systems from various vendors and developers who have not implemented common or interoperable security administrative functions. This document anticipates a requirement to transmit data from several unrelated systems to a common repository. It also anticipates the aggregated data which may then be queried and viewed in a variety of ways.
典型的なヘルスケアIT環境は一般的であるか共同利用できるセキュリティが行政機能であると実装していない様々なベンダーと開発者からの多くのシステムを含んでいます。 このドキュメントは数個の関係ないシステムから一般的な倉庫までデータを送るという要件を予期します。 また、それは次にさまざまな方法で質問されて、見られるかもしれない集められたデータを予期します。
There are distinctions of detail granularity, specificity, and frequency between audit data required for surveillance versus forensic purposes. While some surveillance data may be useful for forensics, the scope of this document is limited to surveillance.
監視に法廷の目的に対して必要である監査データの間には、詳細粒状、特異性、および頻度の区別があります。 いくつかの監視データがフォレンジックの役に立つかもしれない間、このドキュメントの範囲は監視に制限されます。
This document does not address access real-time policy violation alarm actions. There is a perception in the healthcare community that security measures which inhibit access may also inhibit effective patient care, under some circumstances.
このドキュメントは、アクセスがリアルタイムの方針違反警報動作であると扱いません。 知覚がアクセスを抑制する安全策がそうするヘルスケア共同体にあります、また、有効な患者管理を抑制してください、いくつかの状況で。
Marshall Informational [Page 5] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[5ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
This document does not define any data for patient care consents or patients' permissions for data disclosure. It is conceivable that the proposed audit data could be input to such applications, however, assuming strict access controls for audit data have been established.
このドキュメントは患者管理同意のためのどんなデータかデータ公開のための患者の許容も定義しません。 監査データのための厳しいアクセス制御が確立されたと仮定しながら、しかしながら、提案された監査データをそのようなアプリケーションに入力できたのは想像できます。
This document does not define system-specific or application-specific data that may be collected and reported in addition to the defined elements. For example, it is conceivable that audit mechanisms may be useful for tracking financial or payroll transactions. At the same time, this document does not preclude extending the XML schema to incorporate additional data.
このドキュメントは定義された要素に加えて集められて、報告されるかもしれないシステム特有の、または、アプリケーション特有のデータを定義しません。 例えば、監査機構が財政的であるか給料支払名簿の追跡トランザクションの役に立つのが想像できます。 同時に、このドキュメントは、追加データを取り入れるためにXML図式を広げるのを排除しません。
There is a potential requirement for a set of administrative messages to be sent from a central source to each participating system to uniformly specify, control, enable, or disable audit data collection. Such messages are not included in this document.
1セットの監査データが収集であると一様に指定するか、制御するか、可能にするか、または無効にするために主要なソースからそれぞれの参加システムに送られるべき管理メッセージのための潜在的要件があります。 そのようなメッセージは本書では含まれていません。
2.3. Conformance
2.3. 順応
This document does not include any definitions of conformance practices. Instead, it anticipates that standards development organizations that reference this document may specify their own conformance requirements.
このドキュメントは順応練習の少しの定義も含んでいません。 代わりに、このドキュメントがそうする参照がそれら自身の順応要件を指定するのがその規格開発組織を予期します。
3. Goals
3. 目標
3.1. Effective Data Gathering
3.1. 有効なデータ集会
The process of assuring that security policies are implemented correctly is essential to information security administration. It is a set of interrelated tasks all aimed at maintaining an acceptable level of confidence that security protections are, in fact, working as intended. These tasks are assisted by data from automated instrumentation of system and application functions.
安全保障政策が実装されることを保証するプロセスは正しく情報セキュリティ管理に不可欠です。 それは相関的な事実上、機密保持が意図されるとして働いているという合格水準の信用を維持するのがすべて目的とされた1セットのタスクです。 これらのタスクはデータによってシステムとアプリケーションの機能の自動化された計装から補助されます。
Data gathered from a secured environment is used to accumulate evidence that security systems are working as intended and to detect incidents and patterns of misuse for further actions. Once messages have been collected, various reports may be created in support of security assurance and administration information requirements.
機密保護している環境から集められたデータは、セキュリティシステムが意図されるとして動作しているという証拠を蓄積して、さらなる動作のための誤用のインシデントとパターンを検出するのに使用されます。 メッセージがいったん集められると、様々なレポートは安全保証と管理情報必須条件を支持して作成されるかもしれません。
When a site runs multiple heterogeneous applications, each application system may have its own security mechanisms - user log- on, roles, access right permissions and restrictions, etc. Each application system also has its own security log file that records security relevant events, e.g., log-in, data access, and updates to the security policy databases. A system administrator or security auditor must examine each of these log files to find security
サイトが複数の異種のアプリケーションを実行するとき、各アプリケーション・システムには、それ自身のセキュリティー対策があるかもしれません--、ユーザログ、オンである、役割とアクセス権許容と制限など また、各アプリケーション・システムはセキュリティの関連イベントを記録するそれ自身のセキュリティログファイル、例えば、ログイン、データ・アクセス、およびアップデートを安全保障政策データベースに持っています。 システム管理者かセキュリティ監査役が、セキュリティを見つけるためにそれぞれに関するこれらのログファイルを調べなければなりません。
Marshall Informational [Page 6] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[6ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
relevant incidents. Not only is it difficult to examine each of these files separately, the format and contents of each file may be confusingly different.
関連インシデント。 別々に単にそれぞれのこれらのファイルを調べるのが難しいのではなく、それぞれのファイルの形式とコンテンツは紛らわしく異なっているかもしれません。
Resolving these issues requires a framework to:
これらの問題を決議するのが、以下のことがフレームワークは必要です。
- Maximize interoperability and the meaningfulness of data across
applications and sites
- Minimize ambiguity among heterogeneous systems
- Simplify and limit the costs of administrative audit tasks.
- アプリケーションとサイトの向こう側にデータの相互運用性と重要を最大にしてください--多相系の中であいまいさを最小にしてください--行政監査タスクのコストを簡素化して、制限してください。
3.2. Efficiency
3.2. 効率
One of the leading concerns about auditing is the potential volume of data gathering and its impact on application system performance. Although this document does not prescribe specific implementations or strategies, the following are meant as informative guidance for development.
監査に関する主な心配の1つはアプリケーション・システムの上のデータ集会とその影響の潜在的ボリュームです。 このドキュメントは特定の実装か戦略を定めませんが、以下は開発のための有益な指導として意味されます。
1) Audits should be created for transactions or record-level data
access, not for individual attribute-level changes to data.
1) 監査はデータへの個々の属性レベル変化のために引き起こされるのではなく、トランザクションか記録的なレベルデータ・アクセスのために引き起こされるべきです。
2) This document does not discourage locally optimized gathering of
audit data on each application system. Instead, it anticipates
implementation-defined periodic gathering and transmission of data
to a common repository. This common repository would be optimized
for after-the-fact audit queries and reporting, thus unburdening
each application system of those responsibilities. It is also
important to keep the message size compact so that audit data will
not penalize normal network operation.
2) このドキュメントは各アプリケーション・システムにおける監査データの局所的に最適化された集会に水をさしていません。 代わりに、それはデータの実装で定義された周期的な集会と伝達を一般的な倉庫に予期します。 この一般的な倉庫は事実の後の監査質問と報告のために最適化されて、その結果、それらの責任の各アプリケーション・システムに重荷をおろさせるでしょう。 また、メッセージサイズをコンパクトに保つのも、監査データが通常のネットワーク操作を罰しないくらい重要です。
3) On each application system, a variety of policy-based methods
could be employed to optimize data gathering and storage, e.g.,
selective auditing of only events defined as important plus
workload buffering and balancing. Data gathering itself should be
stateless to avoid the overhead of transactional semantics. In
addition, prior to transmission, some filtering, aggregation, and
summarization of repeated events would reduce the number of
messages. Audit data storage and integrity on each application
system need only be scaled for relatively low-volume and short-
duration requirements, yet be consistent with implementation-
defined minimums for holding the data for subsequent collection.
3) 各アプリケーション・システムの上では、重要であると定義されたイベント、ワークロードバッファリング、およびバランスをとることだけのデータ集会とストレージ、例えば、選択している監査を最適化するのにさまざまな方針ベースのメソッドを使うことができました。 集まるデータは、取引の意味論のオーバーヘッドを避けるために状態がないはずです。 さらに、トランスミッションの前に、繰り返されたイベントの何らかのフィルタリング、集合、および総括はメッセージの数を減少させるでしょう。 各アプリケーション・システムの上の監査データ保存と保全は比較的低ボリュームの、そして、短い持続時間要件のためにスケーリングされるだけでよくて、しかし、実装が定義されている一貫した最小限は、その後の収集のためのデータを保持するものですか?
4) Leveraging existing data collection should be considered. For
example, most commercial security subsystems record events in a
local common log file, so the log file data can be extracted for
communication to a common repository. Also, it is common in some
systems' designs to have a transaction log for data reconstruction
4) 既存のデータが収集であると利用するのが考えられるべきです。 例えば、ほとんどの商業セキュリティサブシステムがローカルの一般的なログファイルにイベントを記録するので、コミュニケーションのために一般的な倉庫にログファイルデータを抜粋できます。 また、データ再構成のための取引ログを持っているのもいくつかのシステムのデザインで一般的です。
Marshall Informational [Page 7] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[7ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
in event of database loss, so collecting data-update audit data
within this subsystem could reduce impact on application system
performance.
データベースの損失の事件では、したがって、このサブシステムの中にデータ最新版の監査データを集めると、影響はアプリケーション・システムの上で減少するかもしれません。
5) A security audit repository would gather all audit message data
from the different applications in one database with one standard
structure. This would allow easier evaluation and querying. Once
a suspicious pattern has been found in the audit log repository,
investigation might proceed with more detail in the application
specific audit log. The presence of a common repository also
simplifies and streamlines the implementation of policies for
audit data storage, integrity, retention, and destruction.
5) セキュリティ監査倉庫は1つの標準構造で1つのデータベースにおける異なったアプリケーションからすべての監査メッセージデータを集めるでしょう。 これは、より簡単な評価と質問を許すでしょう。 疑わしげなパターンが監査ログ倉庫でいったん見つけられると、調査はアプリケーションの特定の監査ログのその他の詳細を続けるかもしれません。 また、一般的な倉庫の存在は、監査データ保存のための方針、保全、保有、および破壊の実装を簡素化して、能率化します。
4. Trigger Events
4. 引き金のイベント
The following identifies representative trigger events for generating audit messages. This is not a complete list of trigger events.
以下は、監査メッセージを生成するために代表している引き金のイベントを特定します。 これは引き金のイベントに関する全リストではありません。
For those events arising in the security infrastructure the "minimal" and "basic" level of auditing as outlined in the Common Criteria [ISO15408-2] should be used as a reference standard.
セキュリティインフラストラクチャで起こるそれらのイベントのために、Common Criteria[ISO15408-2]に概説されている監査の「最小量的」、そして、「基本的な」レベルは基準ゲージとして使用されるべきです。
4.1. Security Administration
4.1. セキュリティ政権
This group includes all actions that create, maintain, query, and display definitions for securing data, functions, and the associated access policies. For each trigger type, the creation, update or amendment, deletion, and activation or deactivation are auditable.
このグループはデータ、機能、および関連アクセス方針を保証するための定義を作成して、維持して、質問して、表示するすべての動作を含んでいます。 それぞれの引き金のタイプにおいて、作成かアップデートか修正か、削除と、起動か非活性化が監査可能です。
4.1.1. Data Definition
4.1.1. データ定義
This includes creation, modification, deletion, query, and display of security attributes for data sets, data groups, or classes plus their atomic data elements or attributes.
これはそれらのデータセットかデータグループかクラスと原子データ要素か属性のためのセキュリティー属性の作成、変更、削除、質問、およびディスプレイを含んでいます。
4.1.2. Function Definition
4.1.2. 関数定義
This includes, for example, creation, modification, deletion, query, or display of security attributes and auditable events for the application functions used for patient management, clinical processes, registry of business objects and methods, program creation and maintenance, etc.
これは例えば作成か変更か削除か質問かセキュリティー属性のディスプレイと我慢強い管理と臨床のプロセスとビジネスオブジェクトの登録とメソッドとプログラム作成とメインテナンスなどに使用されるアプリケーションの機能のための監査可能イベントを含んでいます。
4.1.3. Domain Definition
4.1.3. ドメイン定義
This includes all activities to create, modify, delete, query, or display security domains according to various organizational categories such as entity-wide, institutional, departmental, etc.
これは、実体全体の、そして、制度上の、そして、部門のなどの様々な組織的なカテゴリに従って、セキュリティー領域を作成するか、変更するか、削除するか、質問するか、または表示するためにすべての活動を含んでいます。
Marshall Informational [Page 8] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[8ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
4.1.4. Classification Definition
4.1.4. 分類定義
This includes all activities that create, modify, delete, query or display security categories or groupings for functions and data such as patient management, nursing, clinical, etc.
これは機能のためのセキュリティカテゴリか組分けと我慢強い看護していて、臨床の管理などのデータを作成するか、変更するか、削除するか、質問するか、または表示するすべての活動を含んでいます。
4.1.5. Permission Definition
4.1.5. 許可定義
This includes all activities that create, modify, delete, query or display the allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods.
これはアップデートを読まれて、作成する機能とデータに関連している許容が削除する許容できるアクセスを作成するか、変更するか、削除するか、質問するか、または表示するすべての活動、および特定の機能的なユニット、オブジェクトアクセスまたは操作メソッドの実行を含んでいます。
4.1.6. Role Definition
4.1.6. 役割の定義
This includes all activities that create, modify, delete, query or display security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control.
これはセキュリティ管理、入場デスク、看護婦、医師、臨床の専門家などの様々なタスクを分類しているカテゴリに従って、セキュリティの役割を作成するか、変更するか、削除するか、質問するか、または表示するすべての活動を含んでいます。 また、それは役割のベースのアクセスコントロールのための役割で許容の協会を含んでいます。
4.1.7. User Definition
4.1.7. ユーザ定義
This includes all activities that create, modify, delete, query, or display user accounts. It includes password or other authentication data. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control.
これはユーザアカウントを作成するか、変更するか、削除するか、質問するか、または表示するすべての活動を含んでいます。 それはパスワードか他の認証データを含んでいます。 また、それは役割のベースのアクセスコントロールのためのユーザ、またはユーザベースのアクセスコントロールのためのユーザとの許容で役割の協会を含んでいます。
4.2. Audit Administration and Data Access
4.2. 監査政権とデータ・アクセス
This category includes all actions that determine the collection and availability of audit data.
このカテゴリは監査データの収集と有用性を決定するすべての動作を含んでいます。
4.2.1. Auditable Event Enable or Disable
4.2.1. イベントが有効にするか、または無効にするAuditable
This reflects a basic policy decision that an event should or should not be audited. Some, but not necessarily all, triggers or use cases must create an audit record. The selection of what to audit depends on administrative policy decisions. Note that, for integrity, this event should always be audited.
これはイベントを監査するべきであるか、または監査するべきでないという基本方針決定を反映します。 ケースがそうしなければならない必ずすべて、引き金または使用ではなく、或るものが監査記録を作成します。 監査するべきことに関する選択は施政方針決定によります。 このイベントが保全においていつも監査されるべきであることに注意してください。
Marshall Informational [Page 9] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[9ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
4.2.2. Audit Data Access
4.2.2. 監査データ・アクセス
This includes instances where audit data is viewed or reported for any purpose. Since the audit data itself may include data protected by institutional privacy policies and expose the implementation of those policies, access to the data is highly sensitive. This event should therefore always be audited.
監査データがどんな目的のためにも見られるか、または報告されるところにこれはインスタンスを含んでいます。 監査データ自体が制度上のプライバシーに関する方針によって保護されたデータを含んで、それらの方針の実装を暴露するかもしれないので、データへのアクセスは非常に敏感です。 したがって、このイベントはいつも監査されるべきです。
4.2.3. Audit Data Modify or Delete
4.2.3. データが変更するか、または削除する監査
This includes instances where audit data is modified or deleted. While such operations are sometimes permitted by systems policies, modification or destruction of audit data may well be the result of unauthorized hostile systems access. Therefore, this type of event should always be audited.
監査データが変更されるか、または削除されるところにこれはインスタンスを含んでいます。 そのような操作がシステム方針で時々受入れられる間、監査データの変更か破壊がたぶん権限のない敵対的なシステムアクセサリーの結果でしょう。 したがって、このタイプのイベントはいつも監査されるべきです。
4.3. User Access
4.3. ユーザアクセス
This category includes events of access to secured data and functions for which audit data might be collected.
このカテゴリは監査データが集められるかもしれない機密保護しているデータと機能へのアクセスのイベントを含んでいます。
4.3.1. Sign-On
4.3.1. 雇われてください。
This includes successful and unsuccessful attempts from human users and automated system. It also includes re-authentication actions and re-issuing time-sensitive credentials such as Kerberos tickets.
これは人間のユーザと自動化されたシステムからのうまくいっていて失敗の試みを含んでいます。 また、それは、再認証動作とケルベロスチケットなどの時間敏感な資格証明書を再発行するのを含んでいます。
4.3.2. Sign-Off
4.3.2. サインオフしてください。
This includes explicit sign-off events and session abandonment timeouts from human users and automated systems.
これは人間のユーザと自動化されたシステムからの明白な下に署名するイベントとセッション放棄タイムアウトを含んでいます。
4.3.3. Function Access
4.3.3. 機能アクセス
This includes user invocation of application or system functions that have permission definitions associated with them. Note that in a Discretionary Access Control environment not all functions require permissions, especially if their impact is benign in relation to security policies.
これはそれらに関連している許可定義を持っているアプリケーションかシステム機能のユーザ実施を含んでいます。 Discretionary Access Control環境で、すべての機能が許容を必要とするというわけではないことに注意してください、特にそれらの影響が安全保障政策と関連して優しいなら。
The following are examples of trigger events relevant to healthcare privacy. The actual triggers for institutional data access, policies for non-care functions, and support regulatory requirements need to be identified by application-domain standards developers and system implementers.
↓これはヘルスケアプライバシーに関連している引き金のイベントに関する例です。 制度上のデータ・アクセスのための実際の引き金、非注意機能のための方針、アプリケーションドメイン規格開発者によって特定されるように法的な要求事項が必要とするサポート、およびシステムimplementers。
Marshall Informational [Page 10] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[10ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
4.3.3.1. Subject of Care Record Access
4.3.3.1. 注意の記録的なアクセスの対象
This includes all functions which manipulate basic patient data:
これは基本の患者データを操るすべての機能を含んでいます:
- Create, e.g., demographics or patient profile
- Assign identifier, e.g., medical record number
- Update, amend
- Merge/unmerge, e.g., combine multiple medical records for one
patient
- Import/export of data from/to an external source, including
printing and creation of portable media copies.
- Delete, e.g., invalid creation of care record
- 作成、例えば、人口統計か患者プロフィール--案配識別子、例えば、数--アップデートが修正するという医学の記録--マージ/「非-マージ」、例えば、ある患者のために複数のカルテを結合してください--データの/から携帯用のメディアコピーの印刷と作成を含む外部電源までの輸入/輸出 - 削除、例えば、注意記録の無効の作成
4.3.3.2. Encounter or Visit
4.3.3.2. 遭遇か訪問
This includes all functions which associate a subject of care with an instance of care:
これは注意の対象を注意のインスタンスに関連づけるすべての機能を含んでいます:
- Create, e.g., demographics or patient profile
- Assign encounter identifier
- Per-admit
- Admit
- Update, amend
- Delete, e.g., invalid creation of encounter record, breakdown of
equipment, patient did not arrive as expected
- 作成、例えば、人口統計か患者プロフィール(案配遭遇識別子)、-認めてください、--、認めてください--アップデート、修正してください--、削除、例えば、遭遇記録の無効の作成、設備の故障、患者は予想されるように到着しませんでした。
4.3.3.3. Care Protocols
4.3.3.3. 注意プロトコル
This includes all functions which associate care plans or similar protocols with an instance or subject of care:
これはケアプランか同様のプロトコルを注意のインスタンスか対象に関連づけるすべての機能を含んでいます:
- Schedule, initiate - Update, amend - Complete - Cancel
- スケジュール、開始--アップデートは修正します--、完全である、--取り消してください
4.3.3.4. Episodes or Problems
4.3.3.4. エピソードか問題
This includes specific clinical episodes within an instance of care. Initiate:
これは注意のインスタンスの中に特定の臨床のエピソードを含んでいます。 以下を開始してください。
- Update, amend - Resolve, complete - Cancel
- アップデート、修正してください、--決心で、完全--、キャンセル
Marshall Informational [Page 11] RFC 3881 Security Audit & Access Accountability September 2004
マーシャル情報[11ページ]のRFC3881セキュリティ監査とアクセス責任2004年9月
4.3.3.5. Orders and Order Sets
4.3.3.5. 注文とオーダーセット
This includes clinical or supplies orders within an instance or episode of care:
これは注意のインスタンスかエピソードの中に臨床か供給命令を含んでいます:
- Initiate - Update, amend - Check for contraindications - Verify - Deliver/complete - including instructions - Cancel
- 開始--アップデートは修正します--contraindicationsがないかどうかチェックしてください--、検証、--キャンセルを提供するか、または終了してください(指示を含んでいます)
4.3.3.6. Health Service Event or Act
4.3.3.6. 公共医療イベントか条例
This includes various health services scheduled and performed within an instance or episode of care:
これは注意のインスタンスかエピソードの中で予定されて、実行された様々な公共医療を含んでいます:
- Schedule, initiate - Update, amend - Check for contraindications - Verify - Perform/complete - including instructions - Cancel
- スケジュール、開始--アップデートは修正します--contraindicationsがないかどうかチェックしてください--、検証、--キャンセルを実行するか、または終了してください(指示を含んでいます)
4.3.3.7. Medications
4.3.3.7. Medications
This includes all medication orders and administration within an instance or episode of care:
This includes all medication orders and administration within an instance or episode of care:
- Order - Check - Check for interactions - Verify - Dispense/deliver - including administration instructions - Administer - Cancel
- Order - Check - Check for interactions - Verify - Dispense/deliver - including administration instructions - Administer - Cancel
4.3.3.8. Staff/Participant Assignment
4.3.3.8. Staff/Participant Assignment
This includes staffing or participant assignment actions relevant to an instance or episode of care:
This includes staffing or participant assignment actions relevant to an instance or episode of care:
- Assignment of healthcare professionals, caregivers attending
physician, residents, medical students, consultants, etc.
- Change in assigned role or authorization, e.g., relative to
healthcare status change.
- De-assignment
- Assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. - Change in assigned role or authorization, e.g., relative to healthcare status change. - De-assignment
Marshall Informational [Page 12] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 12] RFC 3881 Security Audit & Access Accountability September 2004
5. Data Definitions
5. Data Definitions
This section defines and describes the data in the XML schema. The actual XML schema definition is in section 6.
This section defines and describes the data in the XML schema. The actual XML schema definition is in section 6.
The proposed data elements are grouped into these categories:
The proposed data elements are grouped into these categories:
1) Event Identification - what was done 2) Active Participant Identification - by whom 3) Network Access Point Identification - initiated from where 4) Audit Source Identification - using which server 5) Participant Object Identification - to what record
1) Event Identification - what was done 2) Active Participant Identification - by whom 3) Network Access Point Identification - initiated from where 4) Audit Source Identification - using which server 5) Participant Object Identification - to what record
5.1. Event Identification
5.1. Event Identification
The following data identifies the name, action type, time, and disposition of the audited event. There is only one set of event identification data per audited event.
The following data identifies the name, action type, time, and disposition of the audited event. There is only one set of event identification data per audited event.
5.1.1. Event ID
5.1.1. Event ID
Description
Description
Identifier for a specific audited event, e.g., a menu item,
program, rule, policy, function code, application name, or URL.
It identifies the performed function.
Identifier for a specific audited event, e.g., a menu item, program, rule, policy, function code, application name, or URL. It identifies the performed function.
Optionality: Required
Optionality: Required
Format / Values
Format / Values
Coded value, either defined by the system implementers or as a
reference to a standard vocabulary. The "code" attribute must be
unambiguous and unique, at least within Audit Source ID (see
section 5.4). Examples of Event IDs are program name, method
name, or function name.
Coded value, either defined by the system implementers or as a reference to a standard vocabulary. The "code" attribute must be unambiguous and unique, at least within Audit Source ID (see section 5.4). Examples of Event IDs are program name, method name, or function name.
For implementation defined coded values or references to
standards, the XML schema defines these optional attributes:
For implementation defined coded values or references to standards, the XML schema defines these optional attributes:
Attribute Value
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended
to be valued for locally-defined code-sets.
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
Attribute Value -------------- -------------------------------------------- CodeSystem OID reference CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined code-sets. DisplayName The value to be used in displays and reports OriginalText Input value that was translated to the code
Marshall Informational [Page 13] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 13] RFC 3881 Security Audit & Access Accountability September 2004
To support the requirement for unambiguous event identification,
multiple values may not be specified.
To support the requirement for unambiguous event identification, multiple values may not be specified.
Rationale
Rationale
This identifies the audited function. For "Execute" Event Action
Code audit records, this identifies the application function
performed.
This identifies the audited function. For "Execute" Event Action Code audit records, this identifies the application function performed.
5.1.2. Event Action Code
5.1.2. Event Action Code
Description
Description
Indicator for type of action performed during the event that
generated the audit.
Indicator for type of action performed during the event that generated the audit.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Enumeration:
Enumeration:
Value Meaning Examples
----- --------------------- ----------------------------------
C Create Create a new database object, such
as Placing an Order.
R Read/View/Print/Query Display or print data, such as a
Doctor Census
U Update Update data, such as Revise
Patient Information
D Delete Delete items, such as a doctor
master file record
E Execute Perform a system or application
function such as log-on, program
execution, or use of an object's
method
Value Meaning Examples ----- --------------------- ---------------------------------- C Create Create a new database object, such as Placing an Order. R Read/View/Print/Query Display or print data, such as a Doctor Census U Update Update data, such as Revise Patient Information D Delete Delete items, such as a doctor master file record E Execute Perform a system or application function such as log-on, program execution, or use of an object's method
Rationale
Rationale
This broadly indicates what kind of action was done on the
Participant Object.
This broadly indicates what kind of action was done on the Participant Object.
Marshall Informational [Page 14] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 14] RFC 3881 Security Audit & Access Accountability September 2004
Notes
Notes
Actions that are not enumerated above are considered an Execute of
a specific function or object interface method or treated two or
more distinct events. An application action, such as an
authorization, is a function Execute, and the Event ID would
identify the function.
Actions that are not enumerated above are considered an Execute of a specific function or object interface method or treated two or more distinct events. An application action, such as an authorization, is a function Execute, and the Event ID would identify the function.
For some applications, such as radiological imaging, a Query
action may only determine the presence of data but not access the
data itself. Auditing need not make as fine a distinction.
For some applications, such as radiological imaging, a Query action may only determine the presence of data but not access the data itself. Auditing need not make as fine a distinction.
Compound actions, such as "Move," would be audited by creating
audit data for each operation - read, create, delete - or as an
Execute of a function or method.
Compound actions, such as "Move," would be audited by creating audit data for each operation - read, create, delete - or as an Execute of a function or method.
5.1.3. Event Date/Time
5.1.3. Event Date/Time
Description
Description
Universal coordinated time (UTC), i.e., a date/time specification
that is unambiguous as to local time zones.
Universal coordinated time (UTC), i.e., a date/time specification that is unambiguous as to local time zones.
Optionality: Required
Optionality: Required
Format / Values
Format / Values
A date/time representation that is unambiguous in conveying
universal coordinated time (UTC), formatted according to the ISO
8601 standard [ISO8601]
A date/time representation that is unambiguous in conveying universal coordinated time (UTC), formatted according to the ISO 8601 standard [ISO8601]
Rationale
Rationale
This ties an event to a specific date and time. Security audits
typically require a consistent time base, e.g., UTC, to eliminate
time-zone issues arising from geographical distribution.
This ties an event to a specific date and time. Security audits typically require a consistent time base, e.g., UTC, to eliminate time-zone issues arising from geographical distribution.
Notes
Notes
In a distributed system, some sort of common time base, e.g., an
NTP [RFC1305] server, is a good implementation tactic.
In a distributed system, some sort of common time base, e.g., an NTP [RFC1305] server, is a good implementation tactic.
5.1.4. Event Outcome Indicator
5.1.4. Event Outcome Indicator
Description
Description
Indicates whether the event succeeded or failed.
Indicates whether the event succeeded or failed.
Marshall Informational [Page 15] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 15] RFC 3881 Security Audit & Access Accountability September 2004
Optionality: Required
Optionality: Required
Format / Values
Format / Values
Enumeration:
Enumeration:
Value Meaning
---- ----------------------------------------------------
0 Success
4 Minor failure; action restarted, e.g., invalid password
with first retry
8 Serious failure; action terminated, e.g., invalid
password with excess retries
12 Major failure; action made unavailable, e.g., user
account disabled due to excessive invalid log-on attempts
Value Meaning ---- ---------------------------------------------------- 0 Success 4 Minor failure; action restarted, e.g., invalid password with first retry 8 Serious failure; action terminated, e.g., invalid password with excess retries 12 Major failure; action made unavailable, e.g., user account disabled due to excessive invalid log-on attempts
Rationale
Rationale
Some audit events may be qualified by success or failure
indicator. For example, a Log-on might have this flag set to a
non-zero value to indicate why a log-on attempt failed.
Some audit events may be qualified by success or failure indicator. For example, a Log-on might have this flag set to a non-zero value to indicate why a log-on attempt failed.
Notes
Notes
In some cases a "success" may be partial, for example, an
incomplete or interrupted transfer of a radiological study. For
the purpose of establishing accountability, these distinctions are
not relevant.
In some cases a "success" may be partial, for example, an incomplete or interrupted transfer of a radiological study. For the purpose of establishing accountability, these distinctions are not relevant.
5.1.5. Event Type Code
5.1.5. Event Type Code
Description
Description
Identifier for the category of event.
Identifier for the category of event.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Coded value enumeration, either defined by the system implementers
or as a reference to a standard vocabulary. For implementation
defined codes or references to standards, the XML schema defines
these optional attributes:
Coded value enumeration, either defined by the system implementers or as a reference to a standard vocabulary. For implementation defined codes or references to standards, the XML schema defines these optional attributes:
Marshall Informational [Page 16] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 16] RFC 3881 Security Audit & Access Accountability September 2004
Attribute Value
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended
to be valued for locally-defined code-sets.
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
Attribute Value -------------- -------------------------------------------- CodeSystem OID reference CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined code-sets. DisplayName The value to be used in displays and reports OriginalText Input value that was translated to the code
Since events may be categorized in more than one way, there may be
multiple values specified.
Since events may be categorized in more than one way, there may be multiple values specified.
Rationale
Rationale
This field enables queries of messages by implementation-defined
event categories.
This field enables queries of messages by implementation-defined event categories.
5.2. Active Participant Identification
5.2. Active Participant Identification
The following data identify a user for the purpose of documenting accountability for the audited event. A user may be a person, or a hardware device or software process for events that are not initiated by a person.
The following data identify a user for the purpose of documenting accountability for the audited event. A user may be a person, or a hardware device or software process for events that are not initiated by a person.
Optionally, the user's network access location may be specified.
Optionally, the user's network access location may be specified.
There may be more than one user per event, for example, in cases of actions initiated by one user for other users, or in events that involve more than one user, hardware device, or system process. However, only one user may be the initiator/requestor for the event.
There may be more than one user per event, for example, in cases of actions initiated by one user for other users, or in events that involve more than one user, hardware device, or system process. However, only one user may be the initiator/requestor for the event.
5.2.1. User ID
5.2.1. User ID
Description
Description
Unique identifier for the user actively participating in the event
Unique identifier for the user actively participating in the event
Optionality: Required
Optionality: Required
Format / Values
Format / Values
User identifier text string from the authentication system. It is
a unique value within the Audit Source ID (see section 5.4).
User identifier text string from the authentication system. It is a unique value within the Audit Source ID (see section 5.4).
Rationale
Rationale
This field ties an audit event to a specific user.
This field ties an audit event to a specific user.
Marshall Informational [Page 17] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 17] RFC 3881 Security Audit & Access Accountability September 2004
Notes
Notes
For cross-system audits, especially with long retention, this user
identifier will permanently tie an audit event to a specific user
via a perpetually unique key.
For cross-system audits, especially with long retention, this user identifier will permanently tie an audit event to a specific user via a perpetually unique key.
For node-based authentication -- where only the system hardware or
process, but not a human user, is identified -- User ID would be
the node name.
For node-based authentication -- where only the system hardware or process, but not a human user, is identified -- User ID would be the node name.
5.2.2. Alternative User ID
5.2.2. Alternative User ID
Description
Description
Alternative unique identifier for the user
Alternative unique identifier for the user
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
User identifier text string from authentication system. This
identifier would be one known to a common authentication system
(e.g., single sign-on), if available.
User identifier text string from authentication system. This identifier would be one known to a common authentication system (e.g., single sign-on), if available.
Rationale
Rationale
In some situations a user may authenticate with one identity but, to access a specific application system, may use a synonymous identify. For example, some "single sign on" implementations will do this. The alternative identifier would then be the original identify used for authentication, and the User ID is the one known to and used by the application.
In some situations a user may authenticate with one identity but, to access a specific application system, may use a synonymous identify. For example, some "single sign on" implementations will do this. The alternative identifier would then be the original identify used for authentication, and the User ID is the one known to and used by the application.
5.2.3. User Name
5.2.3. User Name
Description
Description
The human-meaningful name for the user
The human-meaningful name for the user
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Text string
Text string
Marshall Informational [Page 18] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 18] RFC 3881 Security Audit & Access Accountability September 2004
Rationale
Rationale
The User ID and Alternative User ID may be internal or otherwise
obscure values. This field assists the auditor in identifying the
actual user.
The User ID and Alternative User ID may be internal or otherwise obscure values. This field assists the auditor in identifying the actual user.
5.2.4. User Is Requestor
5.2.4. User Is Requestor
Description
Description
Indicator that the user is or is not the requestor, or initiator,
for the event being audited.
Indicator that the user is or is not the requestor, or initiator, for the event being audited.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Boolean, default/assumed value is "true"
Boolean, default/assumed value is "true"
Rationale
Rationale
This value is used to distinguish between requestor-users and
recipient-users. For example, one person may initiate a report-
output to be sent to a another user.
This value is used to distinguish between requestor-users and recipient-users. For example, one person may initiate a report- output to be sent to a another user.
5.2.5. Role ID Code
5.2.5. Role ID Code
Description
Description
Specification of the role(s) the user plays when performing the
event, as assigned in role-based access control security.
Specification of the role(s) the user plays when performing the event, as assigned in role-based access control security.
Optionality: Optional; multi-valued
Optionality: Optional; multi-valued
Format / Values
Format / Values
Coded value, with attribute "code" valued with the role code or
text from authorization system. More than one value may be
specified.
Coded value, with attribute "code" valued with the role code or text from authorization system. More than one value may be specified.
The codes may be implementation-defined or reference a standard
vocabulary enumeration. For implementation defined codes or
references to standards, the XML schema defines these optional
attributes:
The codes may be implementation-defined or reference a standard vocabulary enumeration. For implementation defined codes or references to standards, the XML schema defines these optional attributes:
Marshall Informational [Page 19] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 19] RFC 3881 Security Audit & Access Accountability September 2004
Attribute Value description
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended
to be valued for locally-defined code-sets.
Display Name The value to be used in displays and reports
OriginalText Input value that was translated to the code
Attribute Value description -------------- -------------------------------------------- CodeSystem OID reference CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined code-sets. Display Name The value to be used in displays and reports OriginalText Input value that was translated to the code
Rationale
Rationale
This value ties an audited event to a user's role(s). It is an
optional value that might be used to group events for analysis by
user functional role categories.
This value ties an audited event to a user's role(s). It is an optional value that might be used to group events for analysis by user functional role categories.
Notes
Notes
Many security systems are unable to produce this data, hence it is
optional.
Many security systems are unable to produce this data, hence it is optional.
For the common message, this identifier would be the one known to
a common authorization system, if available. Otherwise, it is a
unique value within the Audit Source ID (see section 5.4).
Consider using a globally unique identifier associated with the
role to avoid ambiguity in auditing data collected from multiple
systems.
For the common message, this identifier would be the one known to a common authorization system, if available. Otherwise, it is a unique value within the Audit Source ID (see section 5.4). Consider using a globally unique identifier associated with the role to avoid ambiguity in auditing data collected from multiple systems.
Role ID is not a substitute for personal accountability.
Role ID is not a substitute for personal accountability.
Ambiguities arise from composite roles and users with multiple
roles, i.e., which role within a composite is being used or what
privilege was a user employing?
Ambiguities arise from composite roles and users with multiple roles, i.e., which role within a composite is being used or what privilege was a user employing?
5.3. Network Access Point Identification
5.3. Network Access Point Identification
The network access point identifies the logical network location for application activity. These data are paired 1:1 with the Active Participant Identification data.
The network access point identifies the logical network location for application activity. These data are paired 1:1 with the Active Participant Identification data.
5.3.1. Network Access Point Type Code
5.3.1. Network Access Point Type Code
Description
Description
An identifier for the type of network access point that originated
the audit event.
An identifier for the type of network access point that originated the audit event.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Marshall Informational [Page 20] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 20] RFC 3881 Security Audit & Access Accountability September 2004
Enumeration:
Enumeration:
Value Meaning
----- --------------------------------
1 Machine Name, including DNS name
2 IP Address
3 Telephone Number
Value Meaning ----- -------------------------------- 1 Machine Name, including DNS name 2 IP Address 3 Telephone Number
Rationale
Rationale
This datum identifies the type of network access point identifier
of the user device for the audit event. It is an optional value
that may be used to group events recorded on separate servers for
analysis of access according to a network access point's type.
This datum identifies the type of network access point identifier of the user device for the audit event. It is an optional value that may be used to group events recorded on separate servers for analysis of access according to a network access point's type.
5.3.2. Network Access Point ID
5.3.2. Network Access Point ID
Description
Description
An identifier for the network access point of the user device for
the audit event. This could be a device id, IP address, or some
other identifier associated with a device.
An identifier for the network access point of the user device for the audit event. This could be a device id, IP address, or some other identifier associated with a device.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Text may be constrained to only valid values for the given Network
Access Point Type, if specified. Recommendation is to be as
specific as possible where multiple options are available.
Text may be constrained to only valid values for the given Network Access Point Type, if specified. Recommendation is to be as specific as possible where multiple options are available.
Rationale
Rationale
This datum identifies the user's network access point, which may
be distinct from the server that performed the action. It is an
optional value that may be used to group events recorded on
separate servers for analysis of a specific network access point's
data access across all servers.
This datum identifies the user's network access point, which may be distinct from the server that performed the action. It is an optional value that may be used to group events recorded on separate servers for analysis of a specific network access point's data access across all servers.
Note
Note
Network Access Point ID is not a substitute for personal
accountability. Internet IP addresses, in particular, are highly
volatile and may be assigned to more than one person in a short
time period.
Network Access Point ID is not a substitute for personal accountability. Internet IP addresses, in particular, are highly volatile and may be assigned to more than one person in a short time period.
Marshall Informational [Page 21] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 21] RFC 3881 Security Audit & Access Accountability September 2004
Examples
Examples
Network Access Point ID: SMH4WC02
Network Access Point Type: 1 = Machine Name
Network Access Point ID: SMH4WC02 Network Access Point Type: 1 = Machine Name
Network Access Point ID: 192.0.2.2
Network Access Point Type: 2 = IP address
Network Access Point ID: 192.0.2.2 Network Access Point Type: 2 = IP address
Network Access Point ID: 610-555-1212
Network Access Point Type: 3 = Phone Number
Network Access Point ID: 610-555-1212 Network Access Point Type: 3 = Phone Number
5.4. Audit Source Identification
5.4. Audit Source Identification
The following data are required primarily for application systems and processes. Since multi-tier, distributed, or composite applications make source identification ambiguous, this collection of fields may repeat for each application or process actively involved in the event. For example, multiple value-sets can identify participating web servers, application processes, and database server threads in an n-tier distributed application. Passive event participants, e.g., low-level network transports, need not be identified.
The following data are required primarily for application systems and processes. Since multi-tier, distributed, or composite applications make source identification ambiguous, this collection of fields may repeat for each application or process actively involved in the event. For example, multiple value-sets can identify participating web servers, application processes, and database server threads in an n-tier distributed application. Passive event participants, e.g., low-level network transports, need not be identified.
Depending on implementation strategies, it is possible that the components in a multi-tier, distributed, or composite applications may generate more than one audit message for a single application event. Various data in the audit message may be used to identify such cases, supporting subsequent data reduction. This document anticipates that the repository and reporting mechanisms will perform data reduction when required, but does not specify those mechanism.
Depending on implementation strategies, it is possible that the components in a multi-tier, distributed, or composite applications may generate more than one audit message for a single application event. Various data in the audit message may be used to identify such cases, supporting subsequent data reduction. This document anticipates that the repository and reporting mechanisms will perform data reduction when required, but does not specify those mechanism.
5.4.1. Audit Enterprise Site ID
5.4.1. Audit Enterprise Site ID
Description
Description
Logical source location within the healthcare enterprise network,
e.g., a hospital or other provider location within a multi-entity
provider group.
Logical source location within the healthcare enterprise network, e.g., a hospital or other provider location within a multi-entity provider group.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Unique identifier text string within the healthcare enterprise.
May be unvalued when the audit-generating application is uniquely
identified by Audit Source ID.
Unique identifier text string within the healthcare enterprise. May be unvalued when the audit-generating application is uniquely identified by Audit Source ID.
Marshall Informational [Page 22] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 22] RFC 3881 Security Audit & Access Accountability September 2004
Rationale
Rationale
This value differentiates among the sites in a multi-site
enterprise health information system.
This value differentiates among the sites in a multi-site enterprise health information system.
Notes
Notes
This is defined by the application that generates the audit
record. It contains a unique code that identifies a business
organization (owner of data) that is known to the enterprise. The
value further qualifies and disambiguates the Audit Source ID.
Values may vary depending on type of business. There may be
levels of differentiation within the organization.
This is defined by the application that generates the audit record. It contains a unique code that identifies a business organization (owner of data) that is known to the enterprise. The value further qualifies and disambiguates the Audit Source ID. Values may vary depending on type of business. There may be levels of differentiation within the organization.
5.4.2. Audit Source ID
5.4.2. Audit Source ID
Description
Description
Identifier of the source where the event originated.
Identifier of the source where the event originated.
Optionality: Required
Optionality: Required
Format / Values
Format / Values
Unique identifier text string, at least within the Audit
Enterprise Site ID
Unique identifier text string, at least within the Audit Enterprise Site ID
Rationale
Rationale
This field ties the event to a specific source system. It may be
used to group events for analysis according to where the event
occurred.
This field ties the event to a specific source system. It may be used to group events for analysis according to where the event occurred.
Notes
Notes
In some configurations, a load-balancing function distributes work
among two or more duplicate servers. The values defined for this
field thus may be considered as an source identifier for a group
of servers rather than a specific source system.
In some configurations, a load-balancing function distributes work among two or more duplicate servers. The values defined for this field thus may be considered as an source identifier for a group of servers rather than a specific source system.
5.4.3. Audit Source Type Code
5.4.3. Audit Source Type Code
Description
Description
Code specifying the type of source where event originated.
Code specifying the type of source where event originated.
Optionality: Optional
Optionality: Optional
Marshall Informational [Page 23] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 23] RFC 3881 Security Audit & Access Accountability September 2004
Format / Values
Format / Values
Coded-value enumeration, optionally defined by system implementers
or a as a reference to a standard vocabulary. Unless defined or
referenced, the default values for the "code" attribute are:
Coded-value enumeration, optionally defined by system implementers or a as a reference to a standard vocabulary. Unless defined or referenced, the default values for the "code" attribute are:
Value Meaning
----- ------------------------------------------------------
1 End-user interface
2 Data acquisition device or instrument
3 Web server process tier in a multi-tier system
4 Application server process tier in a multi-tier system
5 Database server process tier in a multi-tier system
6 Security server, e.g., a domain controller
7 ISO level 1-3 network component
8 ISO level 4-6 operating software
9 External source, other or unknown type
Value Meaning ----- ------------------------------------------------------ 1 End-user interface 2 Data acquisition device or instrument 3 Web server process tier in a multi-tier system 4 Application server process tier in a multi-tier system 5 Database server process tier in a multi-tier system 6 Security server, e.g., a domain controller 7 ISO level 1-3 network component 8 ISO level 4-6 operating software 9 External source, other or unknown type
For implementation defined codes or references to standards, the
XML schema defines these optional attributes:
For implementation defined codes or references to standards, the XML schema defines these optional attributes:
Attribute Value
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended
to be valued for locally-defined code-sets.
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
Attribute Value -------------- -------------------------------------------- CodeSystem OID reference CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined code-sets. DisplayName The value to be used in displays and reports OriginalText Input value that was translated to the code
Since audit sources may be categorized in more than one way, there
may be multiple values specified.
Since audit sources may be categorized in more than one way, there may be multiple values specified.
Rationale
Rationale
This field indicates which type of source is identified by the
Audit Source ID. It is an optional value that may be used to
group events for analysis according to the type of source where
the event occurred.
This field indicates which type of source is identified by the Audit Source ID. It is an optional value that may be used to group events for analysis according to the type of source where the event occurred.
5.5. Participant Object Identification
5.5. Participant Object Identification
The following data assist the auditing process by indicating specific instances of data or objects that have been accessed.
The following data assist the auditing process by indicating specific instances of data or objects that have been accessed.
These data are required unless the values for Event Identification, Active Participant Identification, and Audit Source Identification are sufficient to document the entire auditable event. Production of
These data are required unless the values for Event Identification, Active Participant Identification, and Audit Source Identification are sufficient to document the entire auditable event. Production of
Marshall Informational [Page 24] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 24] RFC 3881 Security Audit & Access Accountability September 2004
audit records containing these data may be enabled or suppressed, as determined by healthcare organization policy and regulatory requirements.
audit records containing these data may be enabled or suppressed, as determined by healthcare organization policy and regulatory requirements.
Because events may have more than one participant object, this group can be a repeating set of values. For example, depending on institutional policies and implementation choices:
Because events may have more than one participant object, this group can be a repeating set of values. For example, depending on institutional policies and implementation choices:
- Two participant object value-sets can be used to identify access
to patient data by medical record number plus the specific health
care encounter or episode for the patient.
- A patient participant and his authorized representative may be
identified concurrently.
- An attending physician and consulting referrals may be identified
concurrently.
- All patients identified on a worklist may be identified.
- For radiological studies, a set of related participant objects
identified by accession number or study number, may be identified.
- Two participant object value-sets can be used to identify access to patient data by medical record number plus the specific health care encounter or episode for the patient. - A patient participant and his authorized representative may be identified concurrently. - An attending physician and consulting referrals may be identified concurrently. - All patients identified on a worklist may be identified. - For radiological studies, a set of related participant objects identified by accession number or study number, may be identified.
Note, though, that each audit message documents only a single usage instance of such participant object relationships and does not serve to document all relationships that may be present or possible.
Note, though, that each audit message documents only a single usage instance of such participant object relationships and does not serve to document all relationships that may be present or possible.
5.5.1. Participant Object Type Code
5.5.1. Participant Object Type Code
Description
Description
Code for the participant object type being audited. This value is
distinct from the user's role or any user relationship to the
participant object.
Code for the participant object type being audited. This value is distinct from the user's role or any user relationship to the participant object.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Enumeration:
Enumeration:
Value Meaning
----- -------------
1 Person
2 System Object
3 Organization
4 Other
Value Meaning ----- ------------- 1 Person 2 System Object 3 Organization 4 Other
Marshall Informational [Page 25] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 25] RFC 3881 Security Audit & Access Accountability September 2004
Rationale
Rationale
To describe the object being acted upon. In addition to queries
on the subject of the action in an auditable event, it is also
important to be able to query on the object type for the action.
To describe the object being acted upon. In addition to queries on the subject of the action in an auditable event, it is also important to be able to query on the object type for the action.
5.5.2. Participant Object Type Code Role
5.5.2. Participant Object Type Code Role
Description
Description
Code representing the functional application role of Participant
Object being audited
Code representing the functional application role of Participant Object being audited
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Enumeration, specific to Participant Object Type Code:
Enumeration, specific to Participant Object Type Code:
Value Meaning Participant Object Type Codes
----- -------------------- ----------------------------------
1 Patient 1 - Person
2 Location 3 - Organization
3 Report 2 - System Object
4 Resource 1 - Person
3 - Organization
5 Master file 2 - System Object
6 User 1 - Person
2 - System Object (non-human user)
7 List 2 - System Object
8 Doctor 1 - Person
9 Subscriber 3 - Organization
10 Guarantor 1 - Person
3 - Organization
11 Security User Entity 1 - Person
2 - System Object
12 Security User Group 2 - System Object
13 Security Resource 2 - System Object
14 Security Granularity 2 - System Object
Definition
15 Provider 1 - Person
3 - Organization
16 Data Destination 2 - System Object
17 Data Repository 2 - System Object
18 Schedule 2 - System Object
19 Customer 3 - Organization
20 Job 2 - System Object
21 Job Stream 2 - System Object
Value Meaning Participant Object Type Codes ----- -------------------- ---------------------------------- 1 Patient 1 - Person 2 Location 3 - Organization 3 Report 2 - System Object 4 Resource 1 - Person 3 - Organization 5 Master file 2 - System Object 6 User 1 - Person 2 - System Object (non-human user) 7 List 2 - System Object 8 Doctor 1 - Person 9 Subscriber 3 - Organization 10 Guarantor 1 - Person 3 - Organization 11 Security User Entity 1 - Person 2 - System Object 12 Security User Group 2 - System Object 13 Security Resource 2 - System Object 14 Security Granularity 2 - System Object Definition 15 Provider 1 - Person 3 - Organization 16 Data Destination 2 - System Object 17 Data Repository 2 - System Object 18 Schedule 2 - System Object 19 Customer 3 - Organization 20 Job 2 - System Object 21 Job Stream 2 - System Object
Marshall Informational [Page 26] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 26] RFC 3881 Security Audit & Access Accountability September 2004
22 Table 2 - System Object
23 Routing Criteria 2 - System Object
24 Query 2 - System Object
22 Table 2 - System Object 23 Routing Criteria 2 - System Object 24 Query 2 - System Object
A "Security Resource" is an abstract securable object, e.g., a
screen, interface, document, program, etc. -- or even an audit
data set or repository.
A "Security Resource" is an abstract securable object, e.g., a screen, interface, document, program, etc. -- or even an audit data set or repository.
Rationale
Rationale
For some detailed audit analysis it may be necessary to indicate a
more granular type of participant, based on the application role
it serves.
For some detailed audit analysis it may be necessary to indicate a more granular type of participant, based on the application role it serves.
5.5.3. Participant Object Data Life Cycle
5.5.3. Participant Object Data Life Cycle
Description
Description
Identifier for the data life-cycle stage for the participant
object. This can be used to provide an audit trail for data, over
time, as it passes through the system.
Identifier for the data life-cycle stage for the participant object. This can be used to provide an audit trail for data, over time, as it passes through the system.
Optionality: Optional
Optionality: Optional
Format/Values
Format/Values
Enumeration:
Enumeration:
Value Meaning
----- --------------------------------------
1 Origination / Creation
2 Import / Copy from original
3 Amendment
4 Verification
5 Translation
6 Access / Use
7 De-identification
8 Aggregation, summarization, derivation
9 Report
10 Export / Copy to target
11 Disclosure
12 Receipt of disclosure
13 Archiving
14 Logical deletion
15 Permanent erasure / Physical destruction
Value Meaning ----- -------------------------------------- 1 Origination / Creation 2 Import / Copy from original 3 Amendment 4 Verification 5 Translation 6 Access / Use 7 De-identification 8 Aggregation, summarization, derivation 9 Report 10 Export / Copy to target 11 Disclosure 12 Receipt of disclosure 13 Archiving 14 Logical deletion 15 Permanent erasure / Physical destruction
Marshall Informational [Page 27] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 27] RFC 3881 Security Audit & Access Accountability September 2004
Rationale
Rationale
Institutional policies for privacy and security may optionally
fall under different accountability rules based on data life
cycle. This provides a differentiating value for those cases.
Institutional policies for privacy and security may optionally fall under different accountability rules based on data life cycle. This provides a differentiating value for those cases.
5.5.4. Participant Object ID Type Code
5.5.4. Participant Object ID Type Code
Description
Description
Describes the identifier that is contained in Participant Object
ID.
Describes the identifier that is contained in Participant Object ID.
Optionality: Required
Optionality: Required
Format / Values
Format / Values
Coded-value enumeration, specific to Participant Object Type Code,
using attribute-name "code". The codes below are the default set.
Coded-value enumeration, specific to Participant Object Type Code, using attribute-name "code". The codes below are the default set.
Value Meaning Participant Object Type Codes
----- ---------------------- -----------------------------
1 Medical Record Number 1 - Person
2 Patient Number 1 - Person
3 Encounter Number 1 - Person
4 Enrollee Number 1 - Person
5 Social Security Number 1 - Person
6 Account Number 1 - Person
3 - Organization
7 Guarantor Number 1 - Person
3 - Organization
8 Report Name 2 - System Object
9 Report Number 2 - System Object
10 Search Criteria 2 - System Object
11 User Identifier 1 - Person
2 - System Object
12 URI 2 - System Object
Value Meaning Participant Object Type Codes ----- ---------------------- ----------------------------- 1 Medical Record Number 1 - Person 2 Patient Number 1 - Person 3 Encounter Number 1 - Person 4 Enrollee Number 1 - Person 5 Social Security Number 1 - Person 6 Account Number 1 - Person 3 - Organization 7 Guarantor Number 1 - Person 3 - Organization 8 Report Name 2 - System Object 9 Report Number 2 - System Object 10 Search Criteria 2 - System Object 11 User Identifier 1 - Person 2 - System Object 12 URI 2 - System Object
User Identifier and URI [RFC2396] text strings are intended to be
used for security administration trigger events to identify the
objects being acted-upon.
User Identifier and URI [RFC2396] text strings are intended to be used for security administration trigger events to identify the objects being acted-upon.
The codes may be the default set stated above, implementation-
defined, or reference a standard vocabulary enumeration, such as
HL7 version 2.4 table 207 or DICOM defined media types. For
implementation defined codes or references to standards, the XML
schema defines these optional attributes:
The codes may be the default set stated above, implementation- defined, or reference a standard vocabulary enumeration, such as HL7 version 2.4 table 207 or DICOM defined media types. For implementation defined codes or references to standards, the XML schema defines these optional attributes:
Marshall Informational [Page 28] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 28] RFC 3881 Security Audit & Access Accountability September 2004
Attribute Value
-------------- --------------------------------------------
CodeSystem OID reference
CodeSystemName Name of the coding system; strongly recommended
to be valued for locally-defined code-sets.
DisplayName The value to be used in displays and reports
OriginalText Input value that was translated to the code
Attribute Value -------------- -------------------------------------------- CodeSystem OID reference CodeSystemName Name of the coding system; strongly recommended to be valued for locally-defined code-sets. DisplayName The value to be used in displays and reports OriginalText Input value that was translated to the code
Rationale
Rationale
Required to distinguish among various identifiers that may
synonymously identify a participant object.
Required to distinguish among various identifiers that may synonymously identify a participant object.
5.5.5. Participant Object Sensitivity
5.5.5. Participant Object Sensitivity
Description
Description
Denotes policy-defined sensitivity for the Participant Object ID
such as VIP, HIV status, mental health status, or similar topics.
Denotes policy-defined sensitivity for the Participant Object ID such as VIP, HIV status, mental health status, or similar topics.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Values are institution- and implementation-defined text strings.
Values are institution- and implementation-defined text strings.
5.5.6. Participant Object ID
5.5.6. Participant Object ID
Description
Description
Identifies a specific instance of the participant object.
Identifies a specific instance of the participant object.
Optionality: Required
Optionality: Required
Format / Values
Format / Values
Text string. Value format depends on Participant Object Type Code
and the Participant Object ID Type Code.
Text string. Value format depends on Participant Object Type Code and the Participant Object ID Type Code.
Rationale
Rationale
This field identifies a specific instance of an object, such as a
patient, to detect/track privacy and security issues.
This field identifies a specific instance of an object, such as a patient, to detect/track privacy and security issues.
Notes
Notes
Consider this to be the primary unique identifier key for the
object, so it may be a composite data field as implemented.
Consider this to be the primary unique identifier key for the object, so it may be a composite data field as implemented.
Marshall Informational [Page 29] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 29] RFC 3881 Security Audit & Access Accountability September 2004
5.5.7. Participant Object Name
5.5.7. Participant Object Name
Description
Description
An instance-specific descriptor of the Participant Object ID
audited, such as a person's name.
An instance-specific descriptor of the Participant Object ID audited, such as a person's name.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Text string
Text string
Rationale
Rationale
This field may be used in a query/report to identify audit events
for a specific person, e.g., where multiple synonymous Participant
Object IDs (patient number, medical record number, encounter
number, etc.) have been used.
This field may be used in a query/report to identify audit events for a specific person, e.g., where multiple synonymous Participant Object IDs (patient number, medical record number, encounter number, etc.) have been used.
5.5.8. Participant Object Query
5.5.8. Participant Object Query
Description
Description
The actual query for a query-type participant object.
The actual query for a query-type participant object.
Optionality: Optional
Optionality: Optional
Format / Values
Format / Values
Base 64 encoded data
Base 64 encoded data
Rationale
Rationale
For query events it may be necessary to capture the actual query
input to the query process in order to identify the specific
event. Because of differences among query implementations and
data encoding for them, this is a base 64 encoded data blob. It
may be subsequently decoded or interpreted by downstream audit
analysis processing.
For query events it may be necessary to capture the actual query input to the query process in order to identify the specific event. Because of differences among query implementations and data encoding for them, this is a base 64 encoded data blob. It may be subsequently decoded or interpreted by downstream audit analysis processing.
5.5.9. Participant Object Detail
5.5.9. Participant Object Detail
Description
Description
Implementation-defined data about specific details of the object
accessed or used.
Implementation-defined data about specific details of the object accessed or used.
Marshall Informational [Page 30] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 30] RFC 3881 Security Audit & Access Accountability September 2004
Optionality: Optional
Optionality: Optional
Format
Format
Type-value pair. The "type" attribute is an implementation-
defined text string. The "value" attribute is a base 64 encoded
data.
Type-value pair. The "type" attribute is an implementation- defined text string. The "value" attribute is a base 64 encoded data.
Rationale
Rationale
Specific details or values from the object accessed may be desired
in specific auditing implementations. The type-value pair enables
the use of implementation-defined and locally-extensible object
type identifiers and values. For example, a clinical diagnostic
object may contain multiple test results, and this element could
document the type and number and type of results.
Specific details or values from the object accessed may be desired in specific auditing implementations. The type-value pair enables the use of implementation-defined and locally-extensible object type identifiers and values. For example, a clinical diagnostic object may contain multiple test results, and this element could document the type and number and type of results.
Many possible data encodings are possible for this elements, so
the value is a base 64 encoded data blob. It may be subsequently
decoded or interpreted by downstream audit analysis processing.
Many possible data encodings are possible for this elements, so the value is a base 64 encoded data blob. It may be subsequently decoded or interpreted by downstream audit analysis processing.
6. XML Schema
6. XML Schema
This section contains the actual XML schema definition for the data defined in section 5. It also provides brief guidance for specifying schema localizations for implementation purposes.
This section contains the actual XML schema definition for the data defined in section 5. It also provides brief guidance for specifying schema localizations for implementation purposes.
The XML schema specified in section 6.1 conforms with the W3C Recommendations for XML Schema structure [W3CXML-1] and data types [W3CXML-2].
The XML schema specified in section 6.1 conforms with the W3C Recommendations for XML Schema structure [W3CXML-1] and data types [W3CXML-2].
6.1. XML Schema Definition
6.1. XML Schema Definition
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="AuditMessage">
<xs:complexType>
<xs:sequence>
<xs:element name="EventIdentification"
type="EventIdentificationType"/>
<xs:element name="ActiveParticipant" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="ActiveParticipantType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="AuditSourceIdentification"
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="AuditMessage"> <xs:complexType> <xs:sequence> <xs:element name="EventIdentification" type="EventIdentificationType"/> <xs:element name="ActiveParticipant" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="ActiveParticipantType"/> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="AuditSourceIdentification"
Marshall Informational [Page 31] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 31] RFC 3881 Security Audit & Access Accountability September 2004
type="AuditSourceIdentificationType" maxOccurs="unbounded"/>
<xs:element name="ParticipantObjectIdentification"
type="ParticipantObjectIdentificationType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="EventIdentificationType">
<xs:sequence>
<xs:element name="EventID" type="CodedValueType"/>
<xs:element name="EventTypeCode" type="CodedValueType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="EventActionCode" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="C">
<xs:annotation>
<xs:appinfo>Create</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="R">
<xs:annotation>
<xs:appinfo>Read</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="U">
<xs:annotation>
<xs:appinfo>Update</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="D">
<xs:annotation>
<xs:appinfo>Delete</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="E">
<xs:annotation>
<xs:documentation>Execute</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="EventDateTime" type="xs:dateTime"
use="required"/>
<xs:attribute name="EventOutcomeIndicator" use="required">
<xs:simpleType>
type="AuditSourceIdentificationType" maxOccurs="unbounded"/> <xs:element name="ParticipantObjectIdentification" type="ParticipantObjectIdentificationType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="EventIdentificationType"> <xs:sequence> <xs:element name="EventID" type="CodedValueType"/> <xs:element name="EventTypeCode" type="CodedValueType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="EventActionCode" use="optional"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="C"> <xs:annotation> <xs:appinfo>Create</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="R"> <xs:annotation> <xs:appinfo>Read</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="U"> <xs:annotation> <xs:appinfo>Update</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="D"> <xs:annotation> <xs:appinfo>Delete</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="E"> <xs:annotation> <xs:documentation>Execute</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="EventDateTime" type="xs:dateTime" use="required"/> <xs:attribute name="EventOutcomeIndicator" use="required"> <xs:simpleType>
Marshall Informational [Page 32] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 32] RFC 3881 Security Audit & Access Accountability September 2004
<xs:restriction base="xs:integer">
<xs:enumeration value="0">
<xs:annotation>
<xs:appinfo>Success</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Minor failure</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:appinfo>Serious failure</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="12">
<xs:annotation>
<xs:appinfo>Major failure; action made unavailable
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="AuditSourceIdentificationType">
<xs:sequence>
<xs:element name="AuditSourceTypeCode" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="CodedValueType">
<xs:attribute name="code" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="1">
<xs:annotation>
<xs:appinfo>End-user display device, diagnostic
display</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>Data acquisition device or
instrument</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:restriction base="xs:integer"> <xs:enumeration value="0"> <xs:annotation> <xs:appinfo>Success</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Minor failure</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>Serious failure</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>Major failure; action made unavailable </xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="AuditSourceIdentificationType"> <xs:sequence> <xs:element name="AuditSourceTypeCode" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:restriction base="CodedValueType"> <xs:attribute name="code" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>End-user display device, diagnostic display</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>Data acquisition device or instrument</xs:appinfo> </xs:annotation> </xs:enumeration>
Marshall Informational [Page 33] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 33] RFC 3881 Security Audit & Access Accountability September 2004
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Web server process</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Application server process</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:appinfo>Database server process</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:appinfo>Security server, e.g., a domain
controller</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="7">
<xs:annotation>
<xs:documentation>ISO level 1-3 network
component</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:appinfo>ISO level 4-6 operating software</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="9">
<xs:annotation>
<xs:appinfo>External source, other or unknown
type</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="AuditEnterpriseSiteID" type="xs:string"
use="optional"/>
<xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Web server process</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Application server process</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> <xs:appinfo>Database server process</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:appinfo>Security server, e.g., a domain controller</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:documentation>ISO level 1-3 network component</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>ISO level 4-6 operating software</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="9"> <xs:annotation> <xs:appinfo>External source, other or unknown type</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="AuditEnterpriseSiteID" type="xs:string" use="optional"/>
Marshall Informational [Page 34] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 34] RFC 3881 Security Audit & Access Accountability September 2004
<xs:attribute name="AuditSourceID" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="ActiveParticipantType">
<xs:sequence minOccurs="0">
<xs:element name="RoleIDCode" type="CodedValueType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="UserID" type="xs:string" use="required"/>
<xs:attribute name="AlternativeUserID" type="xs:string"
use="optional"/>
<xs:attribute name="UserName" type="xs:string" use="optional"/>
<xs:attribute name="UserIsRequestor" type="xs:boolean"
use="optional" default="true"/>
<xs:attribute name="NetworkAccessPointID" type="xs:string"
use="optional"/>
<xs:attribute name="NetworkAccessPointTypeCode" use="optional">
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:enumeration value="1">
<xs:annotation>
<xs:appinfo>Machine Name, including DNS name</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>IP Address</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Telephone Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="ParticipantObjectIdentificationType">
<xs:sequence>
<xs:element name="ParticipantObjectIDTypeCode">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="CodedValueType">
<xs:attribute name="code" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="1">
<xs:attribute name="AuditSourceID" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="ActiveParticipantType"> <xs:sequence minOccurs="0"> <xs:element name="RoleIDCode" type="CodedValueType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="UserID" type="xs:string" use="required"/> <xs:attribute name="AlternativeUserID" type="xs:string" use="optional"/> <xs:attribute name="UserName" type="xs:string" use="optional"/> <xs:attribute name="UserIsRequestor" type="xs:boolean" use="optional" default="true"/> <xs:attribute name="NetworkAccessPointID" type="xs:string" use="optional"/> <xs:attribute name="NetworkAccessPointTypeCode" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Machine Name, including DNS name</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>IP Address</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Telephone Number</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ParticipantObjectIdentificationType"> <xs:sequence> <xs:element name="ParticipantObjectIDTypeCode"> <xs:complexType> <xs:complexContent> <xs:restriction base="CodedValueType"> <xs:attribute name="code" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="1">
Marshall Informational [Page 35] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 35] RFC 3881 Security Audit & Access Accountability September 2004
<xs:annotation>
<xs:appinfo>Medical Record Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>Patient Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Encounter Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Enrollee Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:appinfo>Social Security Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:appinfo>Account Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="7">
<xs:annotation>
<xs:appinfo>Guarantor Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:appinfo>Report Name</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="9">
<xs:annotation>
<xs:appinfo>Report Number</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="10">
<xs:annotation>
<xs:appinfo>Search Criteria</xs:appinfo>
</xs:annotation>
<xs:annotation> <xs:appinfo>Medical Record Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>Patient Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Encounter Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Enrollee Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> <xs:appinfo>Social Security Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:appinfo>Account Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:appinfo>Guarantor Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>Report Name</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="9"> <xs:annotation> <xs:appinfo>Report Number</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="10"> <xs:annotation> <xs:appinfo>Search Criteria</xs:appinfo> </xs:annotation>
Marshall Informational [Page 36] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 36] RFC 3881 Security Audit & Access Accountability September 2004
</xs:enumeration>
<xs:enumeration value="11">
<xs:annotation>
<xs:appinfo>User Identifier</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="12">
<xs:annotation>
<xs:appinfo>URI</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value=""/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:choice minOccurs="0">
<xs:element name="ParticipantObjectName" type="xs:string"
minOccurs="0"/>
<xs:element name="ParticipantObjectQuery" type="xs:base64Binary"
minOccurs="0"/>
</xs:choice>
<xs:element name="ParticipantObjectDetail"
type="TypeValuePairType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ParticipantObjectID" type="xs:string"
use="required"/>
<xs:attribute name="ParticipantObjectTypeCode" use="optional">
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:enumeration value="1">
<xs:annotation>
<xs:appinfo>Person</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>System object</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Organization</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:enumeration> <xs:enumeration value="11"> <xs:annotation> <xs:appinfo>User Identifier</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>URI</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value=""/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:choice minOccurs="0"> <xs:element name="ParticipantObjectName" type="xs:string" minOccurs="0"/> <xs:element name="ParticipantObjectQuery" type="xs:base64Binary" minOccurs="0"/> </xs:choice> <xs:element name="ParticipantObjectDetail" type="TypeValuePairType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ParticipantObjectID" type="xs:string" use="required"/> <xs:attribute name="ParticipantObjectTypeCode" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Person</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>System object</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Organization</xs:appinfo> </xs:annotation> </xs:enumeration>
Marshall Informational [Page 37] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 37] RFC 3881 Security Audit & Access Accountability September 2004
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Other</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ParticipantObjectTypeCodeRole" use="optional">
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:enumeration value="1">
<xs:annotation>
<xs:appinfo>Patient</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:appinfo>Location</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo> Report</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Resource</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:appinfo>Master file</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:appinfo>User</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="7">
<xs:annotation>
<xs:appinfo>List</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Other</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ParticipantObjectTypeCodeRole" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Patient</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation> <xs:appinfo>Location</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo> Report</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Resource</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> <xs:appinfo>Master file</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:appinfo>User</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:appinfo>List</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation>
Marshall Informational [Page 38] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 38] RFC 3881 Security Audit & Access Accountability September 2004
<xs:appinfo>Doctor</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="9">
<xs:annotation>
<xs:appinfo>Subscriber</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="10">
<xs:annotation>
<xs:appinfo>Guarantor</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="11">
<xs:annotation>
<xs:appinfo>Security User Entity</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="12">
<xs:annotation>
<xs:appinfo>Security User Group</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="13">
<xs:annotation>
<xs:appinfo>Security Resource</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="14">
<xs:annotation>
<xs:appinfo>Security Granualarity Definition</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="15">
<xs:annotation>
<xs:appinfo>Provider</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="16">
<xs:annotation>
<xs:appinfo>Report Destination</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="17">
<xs:annotation>
<xs:appinfo>Report Library</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:appinfo>Doctor</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="9"> <xs:annotation> <xs:appinfo>Subscriber</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="10"> <xs:annotation> <xs:appinfo>Guarantor</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="11"> <xs:annotation> <xs:appinfo>Security User Entity</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>Security User Group</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="13"> <xs:annotation> <xs:appinfo>Security Resource</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="14"> <xs:annotation> <xs:appinfo>Security Granualarity Definition</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="15"> <xs:annotation> <xs:appinfo>Provider</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="16"> <xs:annotation> <xs:appinfo>Report Destination</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="17"> <xs:annotation> <xs:appinfo>Report Library</xs:appinfo> </xs:annotation> </xs:enumeration>
Marshall Informational [Page 39] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 39] RFC 3881 Security Audit & Access Accountability September 2004
<xs:enumeration value="18">
<xs:annotation>
<xs:appinfo>Schedule</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="19">
<xs:annotation>
<xs:appinfo>Customer</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="20">
<xs:annotation>
<xs:appinfo>Job</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="21">
<xs:annotation>
<xs:appinfo>Job Stream</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="22">
<xs:annotation>
<xs:appinfo>Table</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="23">
<xs:annotation>
<xs:appinfo>Routing Criteria</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="24">
<xs:annotation>
<xs:appinfo>Query</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ParticipantObjectDataLifeCycle" use="optional">
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:enumeration value="1">
<xs:annotation>
<xs:appinfo>Origination / Creation</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:enumeration value="18"> <xs:annotation> <xs:appinfo>Schedule</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="19"> <xs:annotation> <xs:appinfo>Customer</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="20"> <xs:annotation> <xs:appinfo>Job</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="21"> <xs:annotation> <xs:appinfo>Job Stream</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="22"> <xs:annotation> <xs:appinfo>Table</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="23"> <xs:annotation> <xs:appinfo>Routing Criteria</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="24"> <xs:annotation> <xs:appinfo>Query</xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ParticipantObjectDataLifeCycle" use="optional"> <xs:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:enumeration value="1"> <xs:annotation> <xs:appinfo>Origination / Creation</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> <xs:annotation>
Marshall Informational [Page 40] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 40] RFC 3881 Security Audit & Access Accountability September 2004
<xs:appinfo>Import / Copy from original </xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:appinfo>Amendment</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:appinfo>Verification</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:appinfo>Translation</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:appinfo>Access / Use</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="7">
<xs:annotation>
<xs:appinfo>De-identification</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="8">
<xs:annotation>
<xs:appinfo>Aggregation, summarization,
derivation</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="9">
<xs:annotation>
<xs:appinfo>Report</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="10">
<xs:annotation>
<xs:appinfo>Export / Copy to target</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="11">
<xs:annotation>
<xs:appinfo>Disclosure</xs:appinfo>
</xs:annotation>
<xs:appinfo>Import / Copy from original </xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> <xs:annotation> <xs:appinfo>Amendment</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="4"> <xs:annotation> <xs:appinfo>Verification</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="5"> <xs:annotation> <xs:appinfo>Translation</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="6"> <xs:annotation> <xs:appinfo>Access / Use</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="7"> <xs:annotation> <xs:appinfo>De-identification</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="8"> <xs:annotation> <xs:appinfo>Aggregation, summarization, derivation</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="9"> <xs:annotation> <xs:appinfo>Report</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="10"> <xs:annotation> <xs:appinfo>Export / Copy to target</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="11"> <xs:annotation> <xs:appinfo>Disclosure</xs:appinfo> </xs:annotation>
Marshall Informational [Page 41] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 41] RFC 3881 Security Audit & Access Accountability September 2004
</xs:enumeration>
<xs:enumeration value="12">
<xs:annotation>
<xs:appinfo>Receipt of disclosure</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="13">
<xs:annotation>
<xs:appinfo>Archiving</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="14">
<xs:annotation>
<xs:appinfo>Logical deletion</xs:appinfo>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="15">
<xs:annotation>
<xs:appinfo>Permanent erasure / Physical destruction
</xs:appinfo>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ParticipantObjectSensitivity" type="xs:string"
use="optional"/>
</xs:complexType>
<xs:complexType name="CodedValueType">
<xs:attribute name="code" type="xs:string" use="required"/>
<xs:attributeGroup ref="CodeSystem"/>
<xs:attribute name="displayName" type="xs:string" use="optional"/>
<xs:attribute name="originalText" type="xs:string" use="optional"/>
</xs:complexType>
<xs:complexType name="TypeValuePairType">
<xs:attribute name="type" type="xs:string" use="required"/>
<xs:attribute name="value" type="xs:base64Binary" use="required"/>
</xs:complexType>
<xs:attributeGroup name="CodeSystem">
<xs:attribute name="codeSystem" type="OID" use="optional"/>
<xs:attribute name="codeSystemName" type="xs:string"
use="optional"/>
</xs:attributeGroup>
<xs:simpleType name="OID">
<xs:restriction base="xs:string">
<xs:whiteSpace value="collapse"/>
</xs:restriction>
</xs:simpleType>
</xs:enumeration> <xs:enumeration value="12"> <xs:annotation> <xs:appinfo>Receipt of disclosure</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="13"> <xs:annotation> <xs:appinfo>Archiving</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="14"> <xs:annotation> <xs:appinfo>Logical deletion</xs:appinfo> </xs:annotation> </xs:enumeration> <xs:enumeration value="15"> <xs:annotation> <xs:appinfo>Permanent erasure / Physical destruction </xs:appinfo> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ParticipantObjectSensitivity" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="CodedValueType"> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attributeGroup ref="CodeSystem"/> <xs:attribute name="displayName" type="xs:string" use="optional"/> <xs:attribute name="originalText" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="TypeValuePairType"> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="value" type="xs:base64Binary" use="required"/> </xs:complexType> <xs:attributeGroup name="CodeSystem"> <xs:attribute name="codeSystem" type="OID" use="optional"/> <xs:attribute name="codeSystemName" type="xs:string" use="optional"/> </xs:attributeGroup> <xs:simpleType name="OID"> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> </xs:restriction> </xs:simpleType>
Marshall Informational [Page 42] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 42] RFC 3881 Security Audit & Access Accountability September 2004
</xs:schema>
</xs:schema>
6.2. XML Schema Localization
6.2. XML Schema Localization
The schema specified in section 6.1 may be extended and restricted to meet local implementation-specific requirements. W3C Recommendation for XML Schema structure [W3CXML-1], section 4, is the governing standard for accomplishing this.
The schema specified in section 6.1 may be extended and restricted to meet local implementation-specific requirements. W3C Recommendation for XML Schema structure [W3CXML-1], section 4, is the governing standard for accomplishing this.
As of the current version of this document, a public reference URI for the base schema has not been established.
As of the current version of this document, a public reference URI for the base schema has not been established.
Local definitions reference the common audit message base schema. For example, here is a schema with a local vocabulary restriction for "Audit Enterprise Site ID" plus an extension adding a new "Audit Source Asset Number" element.
Local definitions reference the common audit message base schema. For example, here is a schema with a local vocabulary restriction for "Audit Enterprise Site ID" plus an extension adding a new "Audit Source Asset Number" element.
The URI used to identify this schema (http://audit-message-uri) is a syntactically valid example that does not represent an actual schema. Schema validators might report an error when attempting to import a schema using this URI.
The URI used to identify this schema (http://audit-message-uri) is a syntactically valid example that does not represent an actual schema. Schema validators might report an error when attempting to import a schema using this URI.
<xs:schema xmlns:audit="http://audit-message-URI"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import schemaLocation="http://audit-message-URI"/>
<xs:complexType name="LocaAuditSourceIdentificationType">
<xs:complexContent>
<xs:restriction base="AuditSourceIdentificationType">
<xs:attribute name="AuditEnterpriseSiteID" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Main"/>
<xs:enumeration value="Clinic1"/>
<xs:enumeration value="Clinic2"/>
<xs:enumeration value="Radiology"/>
<xs:enumeration value="Lab"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="LocalAuditSourceIdentification">
<xs:complexType>
<xs:complexContent>
<xs:extension base="LocaAuditSourceIdentificationType">
<xs:attribute name="AuditSourceAssetNumber" type="xs:string"
<xs:schema xmlns:audit="http://audit-message-URI" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import schemaLocation="http://audit-message-URI"/> <xs:complexType name="LocaAuditSourceIdentificationType"> <xs:complexContent> <xs:restriction base="AuditSourceIdentificationType"> <xs:attribute name="AuditEnterpriseSiteID" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Main"/> <xs:enumeration value="Clinic1"/> <xs:enumeration value="Clinic2"/> <xs:enumeration value="Radiology"/> <xs:enumeration value="Lab"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="LocalAuditSourceIdentification"> <xs:complexType> <xs:complexContent> <xs:extension base="LocaAuditSourceIdentificationType"> <xs:attribute name="AuditSourceAssetNumber" type="xs:string"
Marshall Informational [Page 43] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 43] RFC 3881 Security Audit & Access Accountability September 2004
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>
use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:schema>
7. Security Considerations
7. Security Considerations
Audit data must be secured at least to the same extent as the underlying data and activities being audited. This includes access controls as well as data integrity and recovery functions. This document acknowledges the need for, but does not specify, the policies and technical methods to accomplish this.
Audit data must be secured at least to the same extent as the underlying data and activities being audited. This includes access controls as well as data integrity and recovery functions. This document acknowledges the need for, but does not specify, the policies and technical methods to accomplish this.
It is conceivable that audit data might have unintended uses, e.g., tracking the frequency and nature of system use for productivity measures. ASTM standard E2147-01 [E2147] states, in paragraph 5.3.10, "Prohibit use for other reasons than to enforce security and to detect security breaches in record health information systems, for example, the audits are not to be used to explore activity profiles or movement profiles of employees."
It is conceivable that audit data might have unintended uses, e.g., tracking the frequency and nature of system use for productivity measures. ASTM standard E2147-01 [E2147] states, in paragraph 5.3.10, "Prohibit use for other reasons than to enforce security and to detect security breaches in record health information systems, for example, the audits are not to be used to explore activity profiles or movement profiles of employees."
Some audit data arises from security-relevant processes other than data access. These are the trigger events listed in section 4.1 and 4.2 of this document. Audit data, defined in this document, can record the accountabilities for the results of these processes, as part of a complete security implementation. A discussion of the associated authorities, reference standards, and implementation technology choices for the processes is outside the scope of this document.
Some audit data arises from security-relevant processes other than data access. These are the trigger events listed in section 4.1 and 4.2 of this document. Audit data, defined in this document, can record the accountabilities for the results of these processes, as part of a complete security implementation. A discussion of the associated authorities, reference standards, and implementation technology choices for the processes is outside the scope of this document.
8. References
8. References
8.1. Normative References
8.1. Normative References
[E2147] "E2147-01 Standard Specification for Audit and
Disclosure Logs for Use in Health Information Systems",
ASTM International, June 2002.
[E2147] "E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems", ASTM International, June 2002.
[ISO15408-2] "ISO/IEC 15408:1999 Common Criteria for Information
Technology Security Evaluation, Part 2: Security
Functional Requirements", ISO, August 1999.
[ISO15408-2] "ISO/IEC 15408:1999 Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements", ISO, August 1999.
[ISO8601] "ISO 8601:2000 Data elements and interchange formats --
Information interchange -- Representation of dates and
times", ISO, December 2000.
[ISO8601] "ISO 8601:2000 Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO, December 2000.
Marshall Informational [Page 44] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 44] RFC 3881 Security Audit & Access Accountability September 2004
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[W3CXML-1] W3C Recommendation "XML Schema Part 1: Structures",
version 1.0, May 2001.
[W3CXML-1] W3C Recommendation "XML Schema Part 1: Structures", version 1.0, May 2001.
[W3CXML-2] W3C Recommendation "XML Schema Part 2: Datatypes,"
version 1.0, May 2001.
[W3CXML-2] W3C Recommendation "XML Schema Part 2: Datatypes," version 1.0, May 2001.
8.2. Informative References
8.2. Informative References
[HL7SASIG] Marshall, G. and G. Dickinson, "Common Audit Message",
HL7 Security and Accountability Special Interest Group,
November 2001.
[HL7SASIG] Marshall, G. and G. Dickinson, "Common Audit Message", HL7 Security and Accountability Special Interest Group, November 2001.
[IHETF-3] "IHE Technical Framework", Volume III, HIMMS/RSNA, April
2002.
[IHETF-3] "IHE Technical Framework", Volume III, HIMMS/RSNA, April 2002.
[NEMASPC] "Security and Privacy Auditing in Health Care
Information Technology", Joint NEMA/COCIR/JIRA Security
and Privacy Committee, 26 June 2001.
[NEMASPC] "Security and Privacy Auditing in Health Care Information Technology", Joint NEMA/COCIR/JIRA Security and Privacy Committee, 26 June 2001.
Acknowledgments
Acknowledgments
The author gratefully acknowledges the advice and assistance of the following people during the preparation of this document:
The author gratefully acknowledges the advice and assistance of the following people during the preparation of this document:
Carmela Couderc, Siemens Medical Solutions
Michael Davis, SAIC
Gary Dickinson
Christoph Dickmann, Siemens Medical Solutions
Daniel Hannum, Siemens Medical Solutions
Robert Horn, Agfa
James McAvoy, Siemens Medical Solutions
John Moehrke, General Electric Medical Systems
Jennifer Puyenbroek, McKesson Information Solutions
Angela Ray, McKesson Information Solutions
Lawrence Tarbox, Siemens Corporate Research
Carmela Couderc, Siemens Medical Solutions Michael Davis, SAIC Gary Dickinson Christoph Dickmann, Siemens Medical Solutions Daniel Hannum, Siemens Medical Solutions Robert Horn, Agfa James McAvoy, Siemens Medical Solutions John Moehrke, General Electric Medical Systems Jennifer Puyenbroek, McKesson Information Solutions Angela Ray, McKesson Information Solutions Lawrence Tarbox, Siemens Corporate Research
Marshall Informational [Page 45] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 45] RFC 3881 Security Audit & Access Accountability September 2004
Author's Address
Author's Address
Glen Marshall Siemens Medical Solutions Health Services 51 Valley Stream Parkway Malvern, PA 19312 USA
Glen Marshall Siemens Medical Solutions Health Services 51 Valley Stream Parkway Malvern, PA 19312 USA
Phone: (610) 219-3938 EMail: glen.f.marshall@siemens.com
Phone: (610) 219-3938 EMail: glen.f.marshall@siemens.com
Marshall Informational [Page 46] RFC 3881 Security Audit & Access Accountability September 2004
Marshall Informational [Page 46] RFC 3881 Security Audit & Access Accountability September 2004
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
Intellectual Property
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and 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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Marshall Informational [Page 47]
Marshall Informational [Page 47]
一覧
スポンサーリンク
