ITリスクマネジメントのための リスクシナリオ作成 Think again from start point of IT Risk Management & Challenge to develop IT Risk Scenarios. Based on "COBIT5 for Risk" ITGI Japan 理事： 梶本政利, CISA, CRISC 自己紹介 • 1992: EDPAA（現在のISACA）入会 • 1994 – 2013: Director of ISACA Tokyo Chapter – 2003 – 2005: Chapter President • 2006: ITGI Japanの設立に参加 – 2006 – 2013: 事務局長 – 2013 – Current: 理事 • ISACA InternaHonal関係 – 2009 – 2011: GRA SC1 Member – 2011 – 2014: GRA SC1 Chair, GRAC Member – Subject MaNer Expert • • • • • COBIT5 Framework（日本語版有り） COBIT5 Enabling Processes（日本語版有り） COBIT5 for Assurance（日本語版作成中） COBIT5 Enabling InformaHon Risk Scenarios using COBIT5 for Risk ITガバナンスの目的 COBIT 5におけるITガバナンス 事業ニーズ ガバナンス 評価 方向の指示 マネジメント・フィードバック モニタリング マネジメント 計画 (APO) 構築 (BAI) 実行 (DSS) モニター (MEA) ITのガバナンスとマネジメント • ガバナンスは 以下のことによって、組織目標の達成 を保証することである。（EDM） – ステークホルダーのニーズ、状況及び選択肢を評価する(E) こと； – 優先順位付けと意思決定によって方向を定める(D) こと； – パフォーマンス、コンプライアンス及び合意された方向と目的に対する進捗を モニターする(M) ことである。 • マネジメントは、ガバナンスを担う組織によって設定 された方向に活動を整合させ、組織の目標を達成さ せるために、計画(P)し、構築(B)し、運用(R)し、そし て モニター(M)する活動である。 (PBRM) プロセスの体系（COBIT 5） 組織のITのガバナンスのためのプロセス 評価、方向の指示、モニタリング EDM01 ガバナンスの フレームワークの設定 と維持の保証 EDM02 便益の提供の保証 EDM03 リスク最適化の保証 EDM04 資源の最適化の保証 整合、計画、及び組織化 APO01 ITマネジメント フレームワークを管 理する APO08 関係を管理する APO02 戦略を管理する APO09 サービスアグリーメン トを管理する APO03 エンタープライズアー キテクチャを管理す る APO10 サプライヤーを管 理する APO04 改革を管理する APO11 品質を管理する APO05 ポートフォリオを管 理する APO06 予算と費用を管理 する APO12 リスクを 管理する APO13 セキュリティを管理 する BAI05 BAI06 変革を管理する APO07 人材を管理する EDM01 ステークホルダーへ の透明性の保証 モニター、評価、 及び査定 MEA01 成果と適合性を モニター、評価 及び査定する 構築、調達、及び導入 BAI01 BAI03 プログラムと プロジェクトを 管理する BAI02 要求定義を 管理する ソリューションの特定 と構築を 管理する BAI08 知識を管理する BAI09 資産を管理する BAI10 構成を管理する BAI04 可用性と性能・容 量を管理する 組織変革を可能とす るものを管理する 提供、サービス、及びサポート DSS01 運用を管理する DSS02 サービス要求と インシデントを 管理する DSS03 問題を管理する DSS04 継続性を 管理する DSS05 セキュリティ サービスを管理する DSS06 ビジネスプロセスのコ ントロールを管理す る BAI07 変革の受容と 移行を管理する MEA02 内部統制のシステム をモニター、評価、及 び査定する MEA03 外部要求への コンプライアンスをモ ニター、評価 及び査定する COBIT5におけるリスクマネジメント EDM03: リスク最適化の保証 • プロセスの概要 – 事業体のリスク選好度と許容度が理解、明確化、周知されていること を確認し、IT の使用に関する事業体価値へのリスクを確実に特定、 管理できるようにする。 • プロセスの目的 – IT 関連の事業体リスクが、リスク選好度とリスク許容度を上回らず、 事業体価値へのIT リスクの影響を特定、管理し、コンプライアンス違 反の可能性を最小限に抑えることを確実なものとする。 リスク最適化の責任者は？ APO12:リスクマネジメント • プロセスの概要 – IT 関連リスクを継続的に特定、評価し、事業体の経営幹部が設定し た許容水準の範囲内に低減する。 • プロセスの目的 – IT 関連の事業体リスクの管理を全般的なERM に統合し、IT 関連の事 業体リスク管理のコストと効果のバランスを取る。 リスクマネジメントの責任者は？ IT Risk Categories リスク階層におけるITリスク リスクの考察例 • 戦略リスク – 事業体のIT組織は、新しいIT計画を予算内でスケジュールどおりにうまく遂行できるか？ そのIT計画は、期待どおりのビジネス上の利益をもたらすだろうか？新IT環境への移行が新たなレ ベルのリスクを引き起こすことはないか？ • 環境リスク – そのIT計画は、ユーザ（内部、パートナまたはカスタマーユーザ）に、十分に検討され、直観的で使 いやすい環境を提供するだろうか？その環境は、事前に特定したビジネス要求を満足し、導入後に 識別された要件に適合できるだろうか？ • 市場リスク – そのIT計画は、競争相手が提供する取り組みに匹敵、または、それに勝るユーザ環境を提供する だろうか？現ユーザと新ユーザは、その取り組みを歓迎するだろうか？ • 信用リスク – そのIT計画は、見積もり予算内で完成し、維持管理され、結果として期待以上の価値を出すだろう か？ • オペレーショナルリスク – ベンダーによる運用サポート、自組織の運用組織は、期待どおりのパフォーマンスを維持するだろ うか？ • コンプライアンスのリスク – 新しいIT計画は現時点および将来の規制要件を満たすだろうか？ Risk Scenario Structure 対応の選択肢と優先順位付け Risk Scenario Overview Risk Duality Two PerspecHves on Risk Risk Function Perspective Risk Management Perspective COBIT 5 Enablers The Risk Function perspective describes how to build and sustain a risk function in the enterprise, by making use of the COBIT 5 Enablers. Processes Risk Function Perspective Organisational Structures Culture, Ethics & Behaviour Principles, Policies & Frameworks Information Services, Infrastructure & Applications People, Skills & Competences Risk Management Perspective The Risk Management perspective looks at the core Risk Governance and Risk Management processes and to Risk Scenarios. It describes how risk can be mitigated by using COBIT 5 enablers. Scope of COBIT5 for Risk COBIT 5 for Risk COBIT 5 Enablers for the Risk Function Processes Organisational Structures Culture, Ethics & Behaviour Principles, Policies & Frameworks Information COSO ERM Services, Infrastructure & Applications ISO/IEC 31000 ISO/IEC 27005 People, Skills & Competences Others Enterprise Risk Management Standards COBIT 5 Framework COBIT 5 Enabling Processes Core Risk Processes Risk Function Perspective Risk Risk Management Perspective Mapping Scenarios to COBIT 5 Enablers Risk Scenarios ITIL, ISO/ IEC 20000 ISO/IEC 27001/2 Others IT Management Frameworks Risk Factors Main Issues when Developing & Using Risk Scenarios No. Focus/Issue 1 Maintain currency of risk scenarios and risk factors. 2 Use generic risk scenarios as a starHng point and build more detail where and when required. 3 Number of scenarios should be representaHve and reflect business reality and complexity. 4 Risk taxonomy should reflect business reality and complexity. 5 Use generic risk scenario structure to simplify risk reporHng 6 Ensure adequate people and skills requirements for developing relevant risk scenarios. 7 Use the risk scenario building process to obtain buy-‐in. 8 Involve first line of defence in the scenario building process. 9 Do not focus only on rare and extreme scenarios. 10 Deduce complex scenarios from simple scenarios by showing impact and dependencies. 11 Consider systemic and contagious risk. 12 Use scenario building to increase awareness for risk detecHon. Risk Scenario Development 1 Title Category ☐ 01-‐Porbolio establishment and maintenance ☐ 02-‐Programme/projects life cycle management ☐ 03-‐IT investment decision making ☐ 04-‐IT experHse and skills ☐ 05-‐Staff operaHons ☐ 06-‐InformaHon ☐ 07-‐Architecture ☐ 08-‐Infrastructure ☐ 09-‐Soeware ☐ 10-‐IneffecHve business ownership of IT ☐ 11-‐SelecHon/performance of third-‐party suppliers ☐ 12-‐Regulatory compliance ☐ 13-‐Geo-‐poliHcal ☐ 14-‐Infrastructure thee ☐ 15-‐Malware ☐ 16-‐Logical aNacks ☐ 17-‐Industrial acHon ☐ 18-‐Environmental ☐ 19-‐Acts of nature ☐ 20 InnovaHon and Improvement Describe the risk/opportunity scenario, including a discussion of the negaHve and posiHve impact of the scenario. The descripHon clarifies the threat/vulnerability type and includes the actors, events, assets and Hme issues. Risk Scenario Development 2 Threat Type ☐ Malicious The nature of the event – Is it malicious? If not, is it ☐ Accidental accidental or is it a failure of a well-‐defined ☐ Error process? Is it a natural event or is it an external ☐ Failure requirement? ☐ Natural ☐ External requirement Actor Who generates the threat that exploits a vulnerability. Actors can be internal or external, human or non-‐human Event ☐ Internal actors are within the enterprise, e.g., staff, contractors ☐ External actors include outsiders, compeDtors, regulators and the market ☐ Disclosure Is it disclosure (of confidenDal informaDon), ☐ InterrupLon interrupDon (of a system, of a project), theI or ☐ ModificaLon destrucDon? AcDon also includes ineffecDve design ☐ TheN (of systems, processes, etc.), inappropriate use, ☐ DestrucLon changes in rules and regulaDon (that will materially ☐ IneffecLve design impact a system) or ineffecDve execuDon of ☐ IneffecLve execuLon processes (e.g., change management procedures, ☐ Rules and regulaLons acquisiDon procedures, project prioriDsaDon ☐ Inappropriate use processes) Risk Scenario Development 3 Asset An asset is any item of value to the enterprise that can be affected and lead to business impact (Assets and resources can be idenDcal, e.g., IT hardware is an important resource because all IT applicaDons use it, and at the same Dme, it is an asset because it has a certain value to the enterprise). 1. Process, e.g., modelled as COBIT 5 processes, or business Processes 2. People and Skills 3. OrganisaLonal Structure 4. Physical Infrastructure (faciliDes, equipment etc.) 5. IT Infrastructure (including compuDng hardware, networks, middleware) 6. InformaLon 7. ApplicaLons Resource A resource is anything that helps to achieve goal (Assets and resources can be idenDcal, e.g., IT hardware is an important resource because all IT applicaDons use it, and at the same Dme, it is an asset because it has a certain value to the enterprise). 1. Process, e.g., modelled as COBIT 5 processes, or business Processes 2. People and Skills 3. OrganisaLonal Structure 4. Physical Infrastructure (faciliDes, equipment etc.) 5. IT Infrastructure (including compuDng hardware, networks, middleware) 6. InformaLon 7. ApplicaLons Risk Scenario Development 4 Time 1. Timing of occurrence (criDcal, non-‐ criDcal – Does the event occur at a criDcal moment?) 2. DuraLon (extended – The duraDon of the event – e.g., extended outage of a service or data centre) 3. DetecLon (slow ,moderate, instant) 4. Time Lag (immediate, delayed – Lag between the event and the consequence – Is there an immediate consequence, e.g., Network failure, immediate downDme, or delayed consequence), e.g., wrong IT architecture with accumulated high costs, over a Dme span of several years?) Risk Scenario Development 5 Risk Type Describe the risk type, include whether the risk type is primary or secondary, i.e., a higher or lower degree of fit. Risk Types: – IT Benefit/Value Enablement: Associated with [missed] opportuniDes to use technology to improve efficiency or effecDveness of business processes, or as an enabler for new business iniDaDves • Technology enabler for new business iniDaDves • Technology enabler for efficient operaDons – IT Programme and Project Delivery: Associated with the contribuDon of IT to new or improved business soluDons, usually in the form of projects and programmes as part of investment porWolios. • Project quality • Project relevance • Project overrun – IT OperaAons and Service Delivery: Associated with all aspects of the business as usual performance of IT systems and services, which can bring destrucDon or reducDon of value to the enterprise. • IT service interrupDons • Security problems • Compliance issues Risk Scenario Development 6 PotenLal Impact Describe the impact on the enterprise if the risk materializes. The impact can be described quanHtaHvely using units of money, Hme, weight, etc. The impact can also be described qualitaHvely as high, medium, or low. Frequency (Probability) of Occurring Describe the likelihood of the risk materializing. The likelihood can be described quanHtaHvely using percentages or qualitaHvely as high, medium, or low. Risk Response Describe how the enterprise will respond to the risk. The purpose of defining a risk response is to bring risk in line with the defined risk appeHte and tolerance for the enterprise: • Risk Acceptance • Risk Sharing/Transfer • Risk MiHgaHon • Risk Avoidance Risk Scenario Development 7 Risk MiLgaLon Using COBIT 5 Enablers Describe how the enterprise will work to avoid the risk from materializing. For Risk MiHgaHon possibiliHes use COBIT 5 Management PracHces (Enablers). Please provide the following informaHon: • Reference, Htle and descripHon of one or more relevant enablers that can help to miHgate the risk • The esHmated effect that implemenHng this enabler will have on the frequency and impact of the risk. Use either Low, Medium or High. • Based on the two parameters frequency and impact give an indicaHon whether this enabler is ‘essenHal’ (Key management pracHce to miHgate the risk) or not. An enabler is considered essenHal if it has a high effect on reducing either impact or frequency of the scenario. Reference Title Management PracHce Effect on Effect on Frequency Impact EssenHal Key Risk Indicators IdenHfy a number of metrics to detect and monitor the risk scenario and the risk response. Risk Analysis Methods – QuanHtaHve vs. QualitaHve • EssenHal properHes – Frequency – The number of Hmes in a given period (usually in a year) that an event is likely to occur – Impact – The business consequences of the scenario • LimitaHons – No method is fully objecHve, and results of risk assessments are always dependent on the person performing them and his/her skills and views. – IT-‐risk-‐related data /(such as loss data and IT risk factors) are very oeen of poor quality or quite subjecHve (e.g., process maturity, control weaknesses). Using structures or models can help to achieve more objecHvity and can provide at least a basis for discussion in the risk analysis. – QuanHtaHve approaches run the risk of creaHng over-‐confidence in complex models based on insufficient data. However, over-‐simplified qualitaHve or quanHtaHve models can also result in unreliable results. Risk Response Workflow
© Copyright 2024 Paperzz
