close

Enter

Log in using OpenID

COBIT5 for Risk - 第11回 itSMF Japanコンファレンス/EXPO

embedDownload
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
Author
Document
Category
Uncategorized
Views
0
File Size
2 599 KB
Tags
1/--pages
Report inappropriate content