風邪のため中断していましたが、引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は可用性の原則と基準の表の基準1.3です。
Criteria 1.3
Responsibility and accountability for the entity’s system availability and related security policies, and changes and updates to those policies, are assigned.
基準 1.3 システムの可用性と関連す るセキュリティポリシーとそれらポリシーへの 変更・更新の責務と説明責任は割り当てられて いる。
Illustrative Controls
Management has assigned responsibilities for the maintenance and enforcement of the entity’s availability policies to the chief information officer (CIO). Others on the executive committee assist in the review, update, and approval of these policies as outlined in the executive committee handbook.
Ownership and custody of significant information resources (for example, data, programs, and transactions) and responsibility for establishing and maintaining the system availability of and related security over such resources is defined.
統制の実例
経営者は 最高情報責任者（CIO）に可用性のポリシーの保守と執行の責任を割り当てる。他の執行委員会のメンバーはこれらのポリシーの確認、更新、承認を補助すると執行委員会ハンドブックで説明されている。
重要な情報源（例えば、データ、プログラ ム、そして取引）とシステムの可用性の確立と保守、そしてこのようなリーソース全体に関連するセキュリティの所有権と保護が定義されている。
公認内部監査人（CIA）tunetterのブログです。 内部監査の試行錯誤を記録していきます。
2010年4月23日金曜日
基準1.2
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は可用性の原則と基準の表の基準1.2です。
Criteria 1.2
The entity’s system availability and related security policies include, but may not be limited to, the following matters:
a. Identification and documentation of the system availability and related security requirements of authorized users.
b. Allowing access, the nature of that access, and who authorizes such access.
c. Preventing unauthorized access.
d. The procedures to add new users, modify the access levels of existing users, and remove users who no longer need access.
e. Assignment of responsibility and accountability for system availability and related security.
f. Assignment of responsibility and accountability for system changes and maintenance.
g. Testing, evaluating, and authorizing system components before implementation.
h. Addressing how complaints and requests relating to system availability and related security issues are resolved.
i. The procedures to handle system availability and related security breaches and other incidents.
j. Provision for allocation for training and other resources to support its system availability and related security policies.
k. Provision for the handling of exceptions and situations not specifically addressed in its system availability and related security policies.
l. Provision for the identification of, and consistency with, applicable laws and regulations, defined commitments, service-level agreements, and other contracts.
m. Recovery and continuity of service in accordance with documented customer commitments or other agreements.
n. Monitoring system capacity to achieve customer commitments or other agreements regarding availability.
基準 1.2
シ ステムの可用性と関連するセキュリティポリシーは以下のことがらを含む。（限定されるわけではない）
a. システムの認証されたユーザーの可用性と関連するセキュリティの要求の認証と考証
b. アクセスの許可、アクセスの性質、そして、誰がそのようなアクセスを承認したか
c. 未承認のアクセスを防ぐ
d. 新規ユーザーを追加する、既存ユーザーのアクセスレベルを変更する、そして、不要となったユーザーを削除する手順
e. システムの可用性と関連するセキュリティについての責任と説明責任の割り当て
f. システムの変更と保守についての責任と説明責任の割り当て
g. 実装前のシステムコンポーネントの試験、評価、そして、承認
h. どのようにシステムの可用性と関係するセキュリティ事項に関連する不平と要望が解決されるかを説明する
i. システムの可用性と関連するセキュリティ侵害と他の事件を取り扱う手順
j. システムの可用性と関連するセキュリティをサポートするためのトレーニングや他のリソース割 り当ての規定
k. システムの可用性 と関連するセキュリティの例外および特に説明されていない状況を取り扱う規定
l. 適用される法令と規則、定義された約束、サービスレベル合意、そして他の契約規定との一致または整合
m. 文書化された顧客との約束またはその他合意に従ったサービスの復旧と継続
n. 可用性についての顧客との約束やその他合意を達成するための監視システムの能力
Illustrative Controls
The entity’s documented availability and related security policies contain the elements set out in criterion 1.2.
統制の実例
文書化された可用性と関連す るセキュリティポリシーは基準1.2で設定された要素を含む
Criteria 1.2
The entity’s system availability and related security policies include, but may not be limited to, the following matters:
a. Identification and documentation of the system availability and related security requirements of authorized users.
b. Allowing access, the nature of that access, and who authorizes such access.
c. Preventing unauthorized access.
d. The procedures to add new users, modify the access levels of existing users, and remove users who no longer need access.
e. Assignment of responsibility and accountability for system availability and related security.
f. Assignment of responsibility and accountability for system changes and maintenance.
g. Testing, evaluating, and authorizing system components before implementation.
h. Addressing how complaints and requests relating to system availability and related security issues are resolved.
i. The procedures to handle system availability and related security breaches and other incidents.
j. Provision for allocation for training and other resources to support its system availability and related security policies.
k. Provision for the handling of exceptions and situations not specifically addressed in its system availability and related security policies.
l. Provision for the identification of, and consistency with, applicable laws and regulations, defined commitments, service-level agreements, and other contracts.
m. Recovery and continuity of service in accordance with documented customer commitments or other agreements.
n. Monitoring system capacity to achieve customer commitments or other agreements regarding availability.
基準 1.2
シ ステムの可用性と関連するセキュリティポリシーは以下のことがらを含む。（限定されるわけではない）
a. システムの認証されたユーザーの可用性と関連するセキュリティの要求の認証と考証
b. アクセスの許可、アクセスの性質、そして、誰がそのようなアクセスを承認したか
c. 未承認のアクセスを防ぐ
d. 新規ユーザーを追加する、既存ユーザーのアクセスレベルを変更する、そして、不要となったユーザーを削除する手順
e. システムの可用性と関連するセキュリティについての責任と説明責任の割り当て
f. システムの変更と保守についての責任と説明責任の割り当て
g. 実装前のシステムコンポーネントの試験、評価、そして、承認
h. どのようにシステムの可用性と関係するセキュリティ事項に関連する不平と要望が解決されるかを説明する
i. システムの可用性と関連するセキュリティ侵害と他の事件を取り扱う手順
j. システムの可用性と関連するセキュリティをサポートするためのトレーニングや他のリソース割 り当ての規定
k. システムの可用性 と関連するセキュリティの例外および特に説明されていない状況を取り扱う規定
l. 適用される法令と規則、定義された約束、サービスレベル合意、そして他の契約規定との一致または整合
m. 文書化された顧客との約束またはその他合意に従ったサービスの復旧と継続
n. 可用性についての顧客との約束やその他合意を達成するための監視システムの能力
Illustrative Controls
The entity’s documented availability and related security policies contain the elements set out in criterion 1.2.
統制の実例
文書化された可用性と関連す るセキュリティポリシーは基準1.2で設定された要素を含む
2010年4月22日木曜日
可用性の原則と基準の表の基準1.0、1.1
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は可用性の原則と基準の表の基準1.0、1.1です。
Availability Principle and Criteria Table
可用性の原則と基準の表
Policies: The entity defines and documents its policies for the availability of its system.
基準 1.0原則：システムの可用性のポリシーは定義されと記述されている。
Criteria 1.1
The entity’s system availability and related security policies are established and periodically reviewed and approved by a designated individual or group.
基準 1.1
システムの可用性と関連するセキュリティポリシーは確立され、定期的に確認され、指名された個人またはグループにより 承認される。
Illustrative Controls
The entity’s documented systems development and acquisition process includes procedures to identify and document authorized users of the system and their availability and related security requirements.
User requirements are documented in service-level agreements or other documents.
Management reviews the entity’s availability and related security policies annually. Proposed changes are submitted as needed for approval by the information technology (IT) standards committee, which includes representation from the customer service department.
統制の実例
ドキュメント化されたシステム 開発と獲得過程は、認証の手順と承認されたユーザーのドキュメントと可用性および関連するセキュリティの要求を含む。
ユーザーの要求はサービスレベル合意や他 のドキュメントに文書化される。
経営者は可用性と関連するセキュリティポリシーを毎年確認する。
変更提案は顧客サービス部署の代表を含む情報技術（IT）標準委員会に よる要承認事項として提出される。
Availability Principle and Criteria Table
可用性の原則と基準の表
- .20 The system is available for operation and use as committed or agreed.
- .20 システムは約束または合意した操作と利用が可能である。
Policies: The entity defines and documents its policies for the availability of its system.
基準 1.0原則：システムの可用性のポリシーは定義されと記述されている。
Criteria 1.1
The entity’s system availability and related security policies are established and periodically reviewed and approved by a designated individual or group.
基準 1.1
システムの可用性と関連するセキュリティポリシーは確立され、定期的に確認され、指名された個人またはグループにより 承認される。
Illustrative Controls
The entity’s documented systems development and acquisition process includes procedures to identify and document authorized users of the system and their availability and related security requirements.
User requirements are documented in service-level agreements or other documents.
Management reviews the entity’s availability and related security policies annually. Proposed changes are submitted as needed for approval by the information technology (IT) standards committee, which includes representation from the customer service department.
統制の実例
ドキュメント化されたシステム 開発と獲得過程は、認証の手順と承認されたユーザーのドキュメントと可用性および関連するセキュリティの要求を含む。
ユーザーの要求はサービスレベル合意や他 のドキュメントに文書化される。
経営者は可用性と関連するセキュリティポリシーを毎年確認する。
変更提案は顧客サービス部署の代表を含む情報技術（IT）標準委員会に よる要承認事項として提出される。
2010年4月21日水曜日
可用性の原則と基準
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は可用性の原則と基準です。
Availability Principle and Criteria
可用性の原則と基準
Availability Principle and Criteria
可用性の原則と基準
- .18 The availability principle refers to the accessibility to the system, products, or services as advertised or committed by contract, service-level, or other agreements. It should be noted that this principle does not, in itself, set a minimum acceptable performance level for system availability. The minimum performance level is established through commitments made or by mutual agreement (contract) between the parties.
- .18 可用性の原則は、契約やサービスレベル他の合意により宣伝または約束された、システムや製品またはサービスへの到達性に言及する。この原則はそれ自身では システム可用性の最小許容可能なパフォーマンスレベルを設定しないことに注意すべきである。最小許容可能なパフォーマンスレベルは約束作りを通じて、または、当事者間の相互の合意（契約）によって確立されます。
- .19 Although there is a connection between system availability, system functionality, and system usability, the availability principle does not address system functionality (the specific functions a system performs) and system usability (the ability of users to apply system functions to specific tasks or problems). It does address system availability, which relates to whether the system is accessible for processing, monitoring, and maintenance.
- .19 システムの可用性とシステムの機能性、そしてシステムの有用性の間に関係があるとしても、可用性の原則はシステムの機能性（システムの特定の機能）とシス テムの有用性（特定のタスクや問題へのシステムの機能に適応するユーザーの能力）を扱わない。システムが処理、監視、そして保守に関連し到達可能であるか 否かはシステムの可用性を説明しない。
2010年4月20日火曜日
基準 4.3
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 4.3です。
Criteria 4.3
Environmental and technological changes are monitored and their effect on system security is assessed on a timely basis.
基準 4.3
環境と技術変更は監視さ れ、それらがシステムセキュリティにおよぼす影響は適時に見積もられる。
Illustrative Controls
Senior management, as part of its annual IT planning process, considers developments in technology and the impact of applicable laws or regulations on the entity’s security policies.
The entity’s IT security group monitors the security impact of emerging technologies.
Users are proactively invited to contribute to initiatives to improve system security through the use of new technologies.
統制の実例
上級管理職は、年度IT計画の 策定プロセスの一部として、開発技術とセキュリティポリシーに適用される法令・規定の影響検討する。
ITセキュリティグループは技術の出現によるセキュリティへの影響を監 視する。
ユーザー は率先的に、新技術の利用を通じてシステムセキュリティの改善を主導し貢献することに招かれる。
Criteria 4.3
Environmental and technological changes are monitored and their effect on system security is assessed on a timely basis.
基準 4.3
環境と技術変更は監視さ れ、それらがシステムセキュリティにおよぼす影響は適時に見積もられる。
Illustrative Controls
Senior management, as part of its annual IT planning process, considers developments in technology and the impact of applicable laws or regulations on the entity’s security policies.
The entity’s IT security group monitors the security impact of emerging technologies.
Users are proactively invited to contribute to initiatives to improve system security through the use of new technologies.
統制の実例
上級管理職は、年度IT計画の 策定プロセスの一部として、開発技術とセキュリティポリシーに適用される法令・規定の影響検討する。
ITセキュリティグループは技術の出現によるセキュリティへの影響を監 視する。
ユーザー は率先的に、新技術の利用を通じてシステムセキュリティの改善を主導し貢献することに招かれる。
2010年4月19日月曜日
基準 4.2
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 4.2です。
Criteria 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its defined system security policies.
基準 4.2
システムセキュリティポリシーに則り目的を達成するための継続能力に対する潜在的な障害を識別し対処するプロセスがあ る。
Illustrative Controls
Logs are analyzed to identify trends that may have a potential impact on the entity’s ability to achieve its system security objectives.
Monthly IT staff meetings are held to address system security concerns and trends; findings are discussed at quarterly management meetings.
統制の実例
記録はシステムセキュリティ の目的を達成する能力に対する潜在的な衝撃の傾向を識別するために分析される。
月例ITスタッフミーティングはシステムセキュリティ懸念事項と傾向に対処するために開催さ れる。
Criteria 4.2
There is a process to identify and address potential impairments to the entity’s ongoing ability to achieve its objectives in accordance with its defined system security policies.
基準 4.2
システムセキュリティポリシーに則り目的を達成するための継続能力に対する潜在的な障害を識別し対処するプロセスがあ る。
Illustrative Controls
Logs are analyzed to identify trends that may have a potential impact on the entity’s ability to achieve its system security objectives.
Monthly IT staff meetings are held to address system security concerns and trends; findings are discussed at quarterly management meetings.
統制の実例
記録はシステムセキュリティ の目的を達成する能力に対する潜在的な衝撃の傾向を識別するために分析される。
月例ITスタッフミーティングはシステムセキュリティ懸念事項と傾向に対処するために開催さ れる。
2010年4月16日金曜日
基準 4.0、4.1
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 4.0、4.1です。
Criteria 4.0
Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system security policies.
基準 4.0
監 視：システムを監視し、定義されたシステムセキュリティポリシーの遵守を維持するためのアクションをとる。
Criteria 4.1
The entity’s system security is periodically reviewed and compared with the defined system security policies.
基準 4.1
システムセキュリティは定期的に確認され、定義されたシステムセキュリティポリシーと比較される。
Illustrative Controls
The information security team monitors the system and assesses the system vulnerabilities using proprietary and other tools. Potential risk is evaluated and compared to service-level agreements and other obligations of the entity. Remediation plans are proposed and implementation is monitored.
The entity contracts with third parties to conduct periodic security reviews and vulnerability assessments. The internal audit function conducts system security reviews as part of its annual audit plan.
Results and recommendations for improvement are reported to management.
統制の実例
情報セキュリティチームはシステムを監視し、所有権や他のツールを使いシステムの脆弱性を見積もる。潜在的なリスクは評価され、サービスレベル合意と他の義務と比較される。修復計画が提案され、実装が監視される。
定期的なセキュリティ確認と脆弱性見積について第三者と契約する。内部監査機能はシステムセキュリティ確認を年度の監査 計画の一環として指揮する。
結果と改善の提言は経営者へ報告される。
Criteria 4.0
Monitoring: The entity monitors the system and takes action to maintain compliance with its defined system security policies.
基準 4.0
監 視：システムを監視し、定義されたシステムセキュリティポリシーの遵守を維持するためのアクションをとる。
Criteria 4.1
The entity’s system security is periodically reviewed and compared with the defined system security policies.
基準 4.1
システムセキュリティは定期的に確認され、定義されたシステムセキュリティポリシーと比較される。
Illustrative Controls
The information security team monitors the system and assesses the system vulnerabilities using proprietary and other tools. Potential risk is evaluated and compared to service-level agreements and other obligations of the entity. Remediation plans are proposed and implementation is monitored.
The entity contracts with third parties to conduct periodic security reviews and vulnerability assessments. The internal audit function conducts system security reviews as part of its annual audit plan.
Results and recommendations for improvement are reported to management.
統制の実例
情報セキュリティチームはシステムを監視し、所有権や他のツールを使いシステムの脆弱性を見積もる。潜在的なリスクは評価され、サービスレベル合意と他の義務と比較される。修復計画が提案され、実装が監視される。
定期的なセキュリティ確認と脆弱性見積について第三者と契約する。内部監査機能はシステムセキュリティ確認を年度の監査 計画の一環として指揮する。
結果と改善の提言は経営者へ報告される。
2010年4月14日水曜日
基準 3.12
引き続 き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.12です。
Criteria 3.12
Procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval).
基準 3.12
緊急変更が文書化され承認されることを供給する手順が存在する。（事後の承認を含む）
Illustrative Controls
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Emergency changes that require deviations from standard procedures are logged and reviewed by IT management daily and reported to the affected line-of-business manager. Permanent corrective measures follow the entity’s change management process, including line-of-business approvals.
統制の実例
変更要求、システム保守、そしてサプライヤーのメンテナンスは標準化され、文書化された変更管理手順に従う。変更は分 類され、優先度により順位付けされ、緊急事項を取り扱う手順がある。
変更要求はそれらの状況が継続的に知らされる。
標準的な手順から逸脱する必要のある緊急 変更は記録されIT管理者により毎日確認され、影響のあるビジネスラインの管理者へ報告される。常設是正措置は、ビジネスラインの承認を含む、変更管理プ ロセスに従う。
Criteria 3.12
Procedures exist to provide that emergency changes are documented and authorized (including after-the-fact approval).
基準 3.12
緊急変更が文書化され承認されることを供給する手順が存在する。（事後の承認を含む）
Illustrative Controls
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Emergency changes that require deviations from standard procedures are logged and reviewed by IT management daily and reported to the affected line-of-business manager. Permanent corrective measures follow the entity’s change management process, including line-of-business approvals.
統制の実例
変更要求、システム保守、そしてサプライヤーのメンテナンスは標準化され、文書化された変更管理手順に従う。変更は分 類され、優先度により順位付けされ、緊急事項を取り扱う手順がある。
変更要求はそれらの状況が継続的に知らされる。
標準的な手順から逸脱する必要のある緊急 変更は記録されIT管理者により毎日確認され、影響のあるビジネスラインの管理者へ報告される。常設是正措置は、ビジネスラインの承認を含む、変更管理プ ロセスに従う。
2010年4月13日火曜日
基準 3.11
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.11です。
Criteria 3.11
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.
基準 3.11
システムへの変更の承認、テストそ して文書化のみを供給するための手順が存在する
Illustrative Controls
Senior management has implemented a division of roles and responsibilities that segregates incompatible functions.
The entity’s documented systems development methodology describes the change initiation, software development and maintenance, and approval processes, as well as the standards and controls that are embedded in the processes. These include programming, documentation, and testing standards.
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Changes to system infrastructure and software are developed and tested in a separate development or test environment before implementation into production.
As part of the change control policies and procedures, there is a “promotion” process (for example, from “test” to “staging” to “production”).
Promotion to production requires the approval of the business owner who sponsored the change and the manager of computer operations.
When changes are made to key systems components, there is a "backout" plan developed for use in the event of major interruption(s).
統制の実例
上級管理職は互換性のない機能 を分離する職務の分離と責任を実装する。
文書化されたシステム開発手法には、プロセスに埋め込まれた標準と統制と同様に、変更の開始、ソフトウェア開発と保守、 そして承認プロセスが記載される。これらはプログラミング文書とテストの基準も含む。
変更、保守そしてサプライヤーの保守への要求は標準化され、文書化された変更管理手続 に従う。変更は優先度により分類・順位付けされる。そして、緊急事項を取扱う手順がある。
変更要求者は自らの要求の状況について情報が与え続けられる。
システムインフラとソフトウェアの変更 は分離された開発またはテスト環境にて製品への実装前に開発されテストされる。
変更統制ポリシーと手順の一部として、「促進」プロセス（例：テストから提供、製作へ）があ る。
製品の促進は 変更を提供するビジネスオーナーとコンピューター操作の管理者の承認を要する。変更が主要システムコンポーネントに行われる時は、大規模中断のために開発 された「復元」計画が存在する。
Criteria 3.11
Procedures exist to provide that only authorized, tested, and documented changes are made to the system.
基準 3.11
システムへの変更の承認、テストそ して文書化のみを供給するための手順が存在する
Illustrative Controls
Senior management has implemented a division of roles and responsibilities that segregates incompatible functions.
The entity’s documented systems development methodology describes the change initiation, software development and maintenance, and approval processes, as well as the standards and controls that are embedded in the processes. These include programming, documentation, and testing standards.
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Changes to system infrastructure and software are developed and tested in a separate development or test environment before implementation into production.
As part of the change control policies and procedures, there is a “promotion” process (for example, from “test” to “staging” to “production”).
Promotion to production requires the approval of the business owner who sponsored the change and the manager of computer operations.
When changes are made to key systems components, there is a "backout" plan developed for use in the event of major interruption(s).
統制の実例
上級管理職は互換性のない機能 を分離する職務の分離と責任を実装する。
文書化されたシステム開発手法には、プロセスに埋め込まれた標準と統制と同様に、変更の開始、ソフトウェア開発と保守、 そして承認プロセスが記載される。これらはプログラミング文書とテストの基準も含む。
変更、保守そしてサプライヤーの保守への要求は標準化され、文書化された変更管理手続 に従う。変更は優先度により分類・順位付けされる。そして、緊急事項を取扱う手順がある。
変更要求者は自らの要求の状況について情報が与え続けられる。
システムインフラとソフトウェアの変更 は分離された開発またはテスト環境にて製品への実装前に開発されテストされる。
変更統制ポリシーと手順の一部として、「促進」プロセス（例：テストから提供、製作へ）があ る。
製品の促進は 変更を提供するビジネスオーナーとコンピューター操作の管理者の承認を要する。変更が主要システムコンポーネントに行われる時は、大規模中断のために開発 された「復元」計画が存在する。
2010年4月12日月曜日
基準 3.10
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.10です。
Maintainability-related criteria applicable to the system’s security
システムのセキュリティに適用される保守関連の基準
Criteria 3.10
Procedures exist to maintain system components, including configurations consistent with the defined system security policies.
基準 3.10
定義されたシステムセキュリティポ リシーと一致した設定を含むシステムコンポーネントを維持する手順が存在する。
Illustrative Controls
Entity management receives a third-party opinion on the adequacy of security controls, and routinely evaluates the level of performance it receives (in accordance with its contractual service-level agreement) from the service provider that hosts the entity’s systems and Web site.
The IT department maintains a listing of all software and the respective level, version, and patches that have been applied.
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Staffing, infrastructure, and software requirements are periodically evaluated and resources are allocated consistent with the entity’s security policies.
System configurations are tested annually, and evaluated against the entity’s security policies and current service-level agreements. An exception report is prepared and remediation plans are developed and tracked.
The IT steering committee, which includes representatives from the lines of business and customer support, meets monthly and reviews anticipated, planned, or recommended changes to the entity’s security policies, including the potential impact of legislative changes.
統制の実例
経営者はセキュリティ統制につ いての妥当性の第三者意見を受け取り、定常的にシステムとウェブサイトをホストするサービスプロバイダーから（契約上のサービスレベル合意に従って）受け取るパフォーマンスレベルを評価する。
IT部門は全てのソフトウェアとそれぞれのレベル、バー ジョン、適用されるパッチの一覧を維持する。
変更要望、システム維持、そしてサプライヤーのメンテナンスは標準化され、文書の変更管理手続に従う。変更は分類され、優先度で順位付けられ、そして緊急事項を処理するための手順がある。
変更要求は要求のステータスに関する情報が保持される。
人材、インフラストラクチャ、およびソフトウェアの要件は、定期的に評価され、リソースは、セキュリティポリシーと一致して割り当てらる。
システム設定は毎年テストされ、セキュリティポリシーと現在のサービスレベル契約に対する評価を行う。例外レポートが用意され、改善計画が開発され、追跡され る。
ビジネスラインの代表とカスタマーサポートを含むIT運営委員会は月例会合を持ち、法改正の潜在的な影響を含む、予想されまたは計画されまたは推奨されるセキュリティポリシーの変更を確認す る。
Maintainability-related criteria applicable to the system’s security
システムのセキュリティに適用される保守関連の基準
Criteria 3.10
Procedures exist to maintain system components, including configurations consistent with the defined system security policies.
基準 3.10
定義されたシステムセキュリティポ リシーと一致した設定を含むシステムコンポーネントを維持する手順が存在する。
Illustrative Controls
Entity management receives a third-party opinion on the adequacy of security controls, and routinely evaluates the level of performance it receives (in accordance with its contractual service-level agreement) from the service provider that hosts the entity’s systems and Web site.
The IT department maintains a listing of all software and the respective level, version, and patches that have been applied.
Requests for changes, system maintenance, and supplier maintenance are standardized and subject to documented change management procedures. Changes are categorized and ranked according to priority, and procedures are in place to handle urgent matters.
Change requestors are kept informed about the status of their requests.
Staffing, infrastructure, and software requirements are periodically evaluated and resources are allocated consistent with the entity’s security policies.
System configurations are tested annually, and evaluated against the entity’s security policies and current service-level agreements. An exception report is prepared and remediation plans are developed and tracked.
The IT steering committee, which includes representatives from the lines of business and customer support, meets monthly and reviews anticipated, planned, or recommended changes to the entity’s security policies, including the potential impact of legislative changes.
統制の実例
経営者はセキュリティ統制につ いての妥当性の第三者意見を受け取り、定常的にシステムとウェブサイトをホストするサービスプロバイダーから（契約上のサービスレベル合意に従って）受け取るパフォーマンスレベルを評価する。
IT部門は全てのソフトウェアとそれぞれのレベル、バー ジョン、適用されるパッチの一覧を維持する。
変更要望、システム維持、そしてサプライヤーのメンテナンスは標準化され、文書の変更管理手続に従う。変更は分類され、優先度で順位付けられ、そして緊急事項を処理するための手順がある。
変更要求は要求のステータスに関する情報が保持される。
人材、インフラストラクチャ、およびソフトウェアの要件は、定期的に評価され、リソースは、セキュリティポリシーと一致して割り当てらる。
システム設定は毎年テストされ、セキュリティポリシーと現在のサービスレベル契約に対する評価を行う。例外レポートが用意され、改善計画が開発され、追跡され る。
ビジネスラインの代表とカスタマーサポートを含むIT運営委員会は月例会合を持ち、法改正の潜在的な影響を含む、予想されまたは計画されまたは推奨されるセキュリティポリシーの変更を確認す る。
2010年4月10日土曜日
基準 3.9
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.9です。
Criteria 3.9
Procedures exist to provide that personnel responsible for the design,
development, implementation, and operation of systems affecting security are qualified to fulfill their responsibilities.
基準 3.9
セキュリティに影響するデザイン、開発、実装、そしてシステムオペレーションに責任を持つ社員の責任を満たすための資 格を提供する手順が存在する。
Illustrative Controls
The entity has written job descriptions specifying the responsibilities and academic and professional requirements for key job positions.
Hiring procedures include a comprehensive screening of candidates for key positions and consideration of whether the verified credentials are commensurate with the proposed position. New personnel are offered employment subject to background checks and reference validation.
Candidates, including internal transfers, are approved by the line-of-business manager before the employment position is offered.
Periodic performance appraisals are performed by employee supervisors and include the assessment and review of professional development activities.
Personnel receive training and development in system security concepts and issues.
Procedures are in place to provide alternate personnel for key system security functions in case of absence or departure.
統制の実例
主たる業務ポジションに求められる責任と学位と専門的要件を明記した職務記述書がある。
採用手順には、主要ポジションの候補者に ついての、包括的な審査と検査認定が提示されたポジションにふさわしいかどうかの考慮が含まれる。新しい社員はバックグラウンドの確認と推薦状の検証を目 的とした仕事を提示される。
候補者（内部異動者を含む）は、雇用ポジションの提示以前に、ビジネスラインの管理者によって認定される。
定期的なパフォーマンス評価は従業員監 督者によって行われ、専門能力開発活動の見積と確認を含む。
従業員はシステムセキュリティのコンセプトと項目の訓練と開発を受ける。
欠勤や離反に備え、主要システムセキュリ ティ機能について代替要員の供給手順がある。
Criteria 3.9
Procedures exist to provide that personnel responsible for the design,
development, implementation, and operation of systems affecting security are qualified to fulfill their responsibilities.
基準 3.9
セキュリティに影響するデザイン、開発、実装、そしてシステムオペレーションに責任を持つ社員の責任を満たすための資 格を提供する手順が存在する。
Illustrative Controls
The entity has written job descriptions specifying the responsibilities and academic and professional requirements for key job positions.
Hiring procedures include a comprehensive screening of candidates for key positions and consideration of whether the verified credentials are commensurate with the proposed position. New personnel are offered employment subject to background checks and reference validation.
Candidates, including internal transfers, are approved by the line-of-business manager before the employment position is offered.
Periodic performance appraisals are performed by employee supervisors and include the assessment and review of professional development activities.
Personnel receive training and development in system security concepts and issues.
Procedures are in place to provide alternate personnel for key system security functions in case of absence or departure.
統制の実例
主たる業務ポジションに求められる責任と学位と専門的要件を明記した職務記述書がある。
採用手順には、主要ポジションの候補者に ついての、包括的な審査と検査認定が提示されたポジションにふさわしいかどうかの考慮が含まれる。新しい社員はバックグラウンドの確認と推薦状の検証を目 的とした仕事を提示される。
候補者（内部異動者を含む）は、雇用ポジションの提示以前に、ビジネスラインの管理者によって認定される。
定期的なパフォーマンス評価は従業員監 督者によって行われ、専門能力開発活動の見積と確認を含む。
従業員はシステムセキュリティのコンセプトと項目の訓練と開発を受ける。
欠勤や離反に備え、主要システムセキュリ ティ機能について代替要員の供給手順がある。
2010年4月8日木曜日
基準 3.8
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.8です。
Criteria related to the system components used to achieve the objectives
目的を達成するために使用されるシステムコンポーネントに関する基準
Criteria 3.8
Design, acquisition, implementation, configuration, modification, and management of infrastructure and software related to system security are consistent with defined system security policies to enable authorized access and to prevent unauthorized access.
基準 3.8
システムセキュリティ関連のインフラスト ラクチャーとソフトウェアのデザイン、獲得、実装、設定、変更、そして管理は、承認されたアクセスを可能にして未承認のアクセスを防ぐために定義されたシ ステムセキュリティポリシーと一致する。
Illustrative Controls
The entity has adopted a formal systems development life cycle (SDLC) methodology that governs the development, acquisition, implementation, and maintenance of computerized information systems and related technology.
The SDLC methodology includes a framework for classifying data and creating standard user profiles that are established based on an assessment of the business impact of the loss of security. Users are assigned standard profiles based on needs and functional responsibilities.
Owners of the information and data classify its sensitivity and determine the level of protection required to maintain an appropriate level of security.
The security administration team reviews and approves the architecture and design specifications for new systems development and/or acquisition to ensure consistency with the entity’s security objectives, policies, and standards.
Changes to system components that may affect security require the approval of the security administration team.
The access control and operating system facilities have been installed, including the implementation of options and parameters, to restrict access in accordance with the entity’s security objectives, policies, and standards.
The entity contracts with third parties to conduct periodic security reviews and vulnerability assessments. Results and recommendations for improvement are reported to management.
統制の実例
コンピュータ化された情報システムと関連する技術の開発、獲得、実装、そして維持の正式なシステム開発ライフサイクルの 方法論を取り入れる。
SDLCの方法論は分類されたデータと標準的なユーザーのプロファイル作成のフレームワークを含む。これらはセキュリ ティ欠如によるビジネスインパクトの見積に基づいて確立される。ユーザーは必要性と機能的な責任に基づいて標準的なプロファイルを与えられる。
情報とデータの所有者は、機微の度合い により分類され、適切なセキュリティレベルを維持するための防御の度合いにより決定される。
セキュリティ管理チームは、セキュリティの目的、ポリシー、そして標準 と一致を確保するために、新システムの開発と（あるいは）獲得の構造とデザイン仕様を確認し承認する。
セキュリティに影響するかもしれないシステムコンポーネントの変更は セキュリティ管理チームの承認を要する。
セキュリティの目的、ポリシー、そして標準に従って制限するためのアクセスコントロールとオペレーションシステム設備が 構築されている。（オプションとパラメーターの実装を含む）。
サードパーティと定期的なセキュリティ確認と脆弱性見積実施の契約を結ぶ。結果と改善提案は経営者に報告される。
Criteria related to the system components used to achieve the objectives
目的を達成するために使用されるシステムコンポーネントに関する基準
Criteria 3.8
Design, acquisition, implementation, configuration, modification, and management of infrastructure and software related to system security are consistent with defined system security policies to enable authorized access and to prevent unauthorized access.
基準 3.8
システムセキュリティ関連のインフラスト ラクチャーとソフトウェアのデザイン、獲得、実装、設定、変更、そして管理は、承認されたアクセスを可能にして未承認のアクセスを防ぐために定義されたシ ステムセキュリティポリシーと一致する。
Illustrative Controls
The entity has adopted a formal systems development life cycle (SDLC) methodology that governs the development, acquisition, implementation, and maintenance of computerized information systems and related technology.
The SDLC methodology includes a framework for classifying data and creating standard user profiles that are established based on an assessment of the business impact of the loss of security. Users are assigned standard profiles based on needs and functional responsibilities.
Owners of the information and data classify its sensitivity and determine the level of protection required to maintain an appropriate level of security.
The security administration team reviews and approves the architecture and design specifications for new systems development and/or acquisition to ensure consistency with the entity’s security objectives, policies, and standards.
Changes to system components that may affect security require the approval of the security administration team.
The access control and operating system facilities have been installed, including the implementation of options and parameters, to restrict access in accordance with the entity’s security objectives, policies, and standards.
The entity contracts with third parties to conduct periodic security reviews and vulnerability assessments. Results and recommendations for improvement are reported to management.
統制の実例
コンピュータ化された情報システムと関連する技術の開発、獲得、実装、そして維持の正式なシステム開発ライフサイクルの 方法論を取り入れる。
SDLCの方法論は分類されたデータと標準的なユーザーのプロファイル作成のフレームワークを含む。これらはセキュリ ティ欠如によるビジネスインパクトの見積に基づいて確立される。ユーザーは必要性と機能的な責任に基づいて標準的なプロファイルを与えられる。
情報とデータの所有者は、機微の度合い により分類され、適切なセキュリティレベルを維持するための防御の度合いにより決定される。
セキュリティ管理チームは、セキュリティの目的、ポリシー、そして標準 と一致を確保するために、新システムの開発と（あるいは）獲得の構造とデザイン仕様を確認し承認する。
セキュリティに影響するかもしれないシステムコンポーネントの変更は セキュリティ管理チームの承認を要する。
セキュリティの目的、ポリシー、そして標準に従って制限するためのアクセスコントロールとオペレーションシステム設備が 構築されている。（オプションとパラメーターの実装を含む）。
サードパーティと定期的なセキュリティ確認と脆弱性見積実施の契約を結ぶ。結果と改善提案は経営者に報告される。
2010年4月7日水曜日
基準 3.7
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.7です。
Criteria 3.7
Procedures exist to provide that issues of noncompliance with system security policies are promptly addressed and that corrective measures are taken on a timely basis.
基準 3.7
システムのセキュリティポリシーの違反が迅速に処理された結果と適時にとられた是正措置を提 供する手順が存在する。
Illustrative Controls
Security issues are recorded and accumulated in a problem report.
Corrective action is noted and monitored by management.
On a routine basis, security policies, controls, and procedures are audited by the internal audit department. Results of such examinations are reviewed by management, a response is prepared, and a remediation plan is put in place.
統制の実例
セキュリティ結果は問題報告に記録さ れ蓄積される。
是正対応は経営者により記録され監視される。
定期的に、セキュリティポリシーと統制、そして手続は内部監査部門により監査 される。このような検査の結果は経営者によって確認され、対応が準備され、改善計画が整備される。
Criteria 3.7
Procedures exist to provide that issues of noncompliance with system security policies are promptly addressed and that corrective measures are taken on a timely basis.
基準 3.7
システムのセキュリティポリシーの違反が迅速に処理された結果と適時にとられた是正措置を提 供する手順が存在する。
Illustrative Controls
Security issues are recorded and accumulated in a problem report.
Corrective action is noted and monitored by management.
On a routine basis, security policies, controls, and procedures are audited by the internal audit department. Results of such examinations are reviewed by management, a response is prepared, and a remediation plan is put in place.
統制の実例
セキュリティ結果は問題報告に記録さ れ蓄積される。
是正対応は経営者により記録され監視される。
定期的に、セキュリティポリシーと統制、そして手続は内部監査部門により監査 される。このような検査の結果は経営者によって確認され、対応が準備され、改善計画が整備される。
2010年4月6日火曜日
基準 3.6
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.6です。
Criteria 3.6
Procedures exist to identify, report, and act upon system security breaches and other incidents.
基準 3.6
認証、報告そしてシステムセキュリティ侵害やその他ゆ事故への対応の手続が存在する。
Illustrative Controls
Users are provided instructions for communicating potential security breaches to the information security team. The information security team logs incidents reported through customer hotlines and e-mail.
Intrusion detection and other tools are used to identify, log, and report potential security breaches and other incidents. The system notifies the security administration team and/or the network administrator via e-mail and pager of potential incidents in progress.
Incident logs are monitored and evaluated by the information security
team daily.
Documented incident identification and escalation procedures are approved by management.
統制の実例
ユー ザーは、情報セキュリティチームへ潜在的なセキュリティ侵害を伝達する訓練がなされている。情報セキュリティチームは顧客ホットラインや電子メールを通じ て報告された事故を記録する。
侵入検知と他のツールは認証、記録そして潜在的なセキュリティ侵害とその他事故の報告に使用される。システムはセ キュリティ管理者と（または）ネットワーク管理者に潜在的で進行中の事故についてメールまたはポケットベルにて警告する。
事故の記録は毎日情報セ キュリティチームによって監視され評価される。
文書化された事故識別と上位報告の手順は経営者によって承認されている。
Criteria 3.6
Procedures exist to identify, report, and act upon system security breaches and other incidents.
基準 3.6
認証、報告そしてシステムセキュリティ侵害やその他ゆ事故への対応の手続が存在する。
Illustrative Controls
Users are provided instructions for communicating potential security breaches to the information security team. The information security team logs incidents reported through customer hotlines and e-mail.
Intrusion detection and other tools are used to identify, log, and report potential security breaches and other incidents. The system notifies the security administration team and/or the network administrator via e-mail and pager of potential incidents in progress.
Incident logs are monitored and evaluated by the information security
team daily.
Documented incident identification and escalation procedures are approved by management.
統制の実例
ユー ザーは、情報セキュリティチームへ潜在的なセキュリティ侵害を伝達する訓練がなされている。情報セキュリティチームは顧客ホットラインや電子メールを通じ て報告された事故を記録する。
侵入検知と他のツールは認証、記録そして潜在的なセキュリティ侵害とその他事故の報告に使用される。システムはセ キュリティ管理者と（または）ネットワーク管理者に潜在的で進行中の事故についてメールまたはポケットベルにて警告する。
事故の記録は毎日情報セ キュリティチームによって監視され評価される。
文書化された事故識別と上位報告の手順は経営者によって承認されている。
2010年4月5日月曜日
基準 3.5
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.5です。
Criteria 3.5
Encryption or other equivalent security techniques are used to protect user authentication information and the corresponding session transmitted over the Internet or other public networks.
基準 3.5
ユーザー認証情報と対応する インターネットまたは他の公衆網上で送信されたセッションは、暗号化または同等のセキュリティ技法が使われて保護される。
Illustrative Controls
The entity uses 128-bit secure sockets layer (SSL) encryption for transmission of private or confidential information over public networks, including user ID and password. Users are required to upgrade their browser to the most current version tested and approved for use by the security administration team to avoid possible security problems.
Account activity, subsequent to successful login, is encrypted through a 128-bit SSL session. Users are logged out on request (by selecting the “Sign-out” button on the Web site) or after 10 minutes of inactivity.
統制の実例
ユーザーIDとパスワードを 含むプライベートまたは機密情報を公衆網上で送信するために128ビットのセキュアソケット レイヤー（SSL）暗号を使用する。ユーザーはブラウザを、起こりうるセキュリティ問題を回避するためにテストされセキュリティ管理チームに使用を認められた、最 新版へアップグレードすることが要求される。
ログイン成功後のアカウントの動作は、128ビットSSL通信によって暗号化される。ユーザーは要求（ウェブサイト上の「サインアウト」ボタンを選ぶこ とによる）があった場合または 10分間動作がなければログア ウトする。
Criteria 3.5
Encryption or other equivalent security techniques are used to protect user authentication information and the corresponding session transmitted over the Internet or other public networks.
基準 3.5
ユーザー認証情報と対応する インターネットまたは他の公衆網上で送信されたセッションは、暗号化または同等のセキュリティ技法が使われて保護される。
Illustrative Controls
The entity uses 128-bit secure sockets layer (SSL) encryption for transmission of private or confidential information over public networks, including user ID and password. Users are required to upgrade their browser to the most current version tested and approved for use by the security administration team to avoid possible security problems.
Account activity, subsequent to successful login, is encrypted through a 128-bit SSL session. Users are logged out on request (by selecting the “Sign-out” button on the Web site) or after 10 minutes of inactivity.
統制の実例
ユーザーIDとパスワードを 含むプライベートまたは機密情報を公衆網上で送信するために128ビットのセキュアソケット レイヤー（SSL）暗号を使用する。ユーザーはブラウザを、起こりうるセキュリティ問題を回避するためにテストされセキュリティ管理チームに使用を認められた、最 新版へアップグレードすることが要求される。
ログイン成功後のアカウントの動作は、128ビットSSL通信によって暗号化される。ユーザーは要求（ウェブサイト上の「サインアウト」ボタンを選ぶこ とによる）があった場合または 10分間動作がなければログア ウトする。
2010年4月2日金曜日
基準 3.4
引き続き、Trust Services Principles, Criteria and Illustrations for Security, Availability, Processing Integrity, Confidentiality, and Privacy (Including WebTrust® and SysTrust®)の勝手訳です。今回は基準 3.4です。
Criteria 3.4
Procedures exist to protect against infection by computer viruses, malicious codes, and unauthorized software.
基準 3.4
コンピューターウィルスや悪意のあるコード、認められていないソフトウェアによる感染を防御 する手続が存在する。
Illustrative Controls
In connection with other security monitoring, the security administration team participates in user groups and subscribes to services relating to computer viruses.
Antivirus software is in place, including virus scans of incoming email messages. Virus signatures are updated at least weekly.
Any viruses discovered are reported to the security team and an alert is created for all users notifying them of a potential virus threat.
統制の実例
他のセキュリティー監視と関連して、セキュリティー管理チームはユーザーグループに参加し、コンピューターウィルス関連 のサービスに申し込む。アンチウィルスソフトウェアが導入され、受信メールのウィルススキャンを含んでいる。ウィルスシグネチャは少なくとも週ごとに更新 される。
発見され たあらゆるウィルスはセキュリティーチームに報告され、全ユーザーに潜在的なウィルスの脅威を喚起する警告が作成される。
Criteria 3.4
Procedures exist to protect against infection by computer viruses, malicious codes, and unauthorized software.
基準 3.4
コンピューターウィルスや悪意のあるコード、認められていないソフトウェアによる感染を防御 する手続が存在する。
Illustrative Controls
In connection with other security monitoring, the security administration team participates in user groups and subscribes to services relating to computer viruses.
Antivirus software is in place, including virus scans of incoming email messages. Virus signatures are updated at least weekly.
Any viruses discovered are reported to the security team and an alert is created for all users notifying them of a potential virus threat.
統制の実例
他のセキュリティー監視と関連して、セキュリティー管理チームはユーザーグループに参加し、コンピューターウィルス関連 のサービスに申し込む。アンチウィルスソフトウェアが導入され、受信メールのウィルススキャンを含んでいる。ウィルスシグネチャは少なくとも週ごとに更新 される。
発見され たあらゆるウィルスはセキュリティーチームに報告され、全ユーザーに潜在的なウィルスの脅威を喚起する警告が作成される。
登録:
投稿 (Atom)
