CCT Day3 復習ログ 暗号 データセキュリティ 監視 インシデント対応 フォレンジック BC DR リスク管理

CCT Day3

パートごとに見直すと良い

---

モジュール14：暗号技術

暗号化セキュリティテクニックについて説明します

暗号技術

情報セキュリティ

• 3要素: CIA
• 5要素: CIA + 真正性・責任追跡性

暗号技術は機密性のために用いられる
本人認証に利用することができる

[IMPORTANT]
暗号化したものを復号できる必要がある
平文 → 暗号化 → 暗号文 → 復号 → 平文

暗号化

暗号の種類は2種類

• 対称暗号：共通鍵暗号

• 非対称暗号：公開鍵暗号

• 暗号にすることを暗号化

• 平文にすることを平文化

  • 一般的には「復号」と言われる

対称型暗号

（左）暗号化と（右）復号で同じ鍵を利用するので「対称型暗号」

• 事前の鍵共有が必要

  • 秘密通信を行いたい場合に相手が誰かわからないと事前共有ができない

• 鍵の本数が相手の数だけ必要になる

  • e.g. 5人いた場合は 5C2 個 (10個) 必要になる

• 高速に暗号化・復号ができる

• 共通鍵：秘密にする必要がある（必要な人だけに渡す）

非対称暗号

（左）暗号化と（右）復号で異なる鍵を利用するので「非対称暗号」

• 2つの鍵がありペアとなっている

  • 片方で暗号化したら、もう片方の鍵で復号する必要がある
  • 暗号化と復号に用いる鍵を入れ替えても良い

• 片方の鍵を公開することができる

  • 不特定多数に公開しても問題ない
  • 事前の鍵共有が不要

• 鍵の本数が自分のものだけになる

  • e.g. 5人いた場合は 5個必要になる

• 暗号化・復号が遅い

  • 計算が非常に大変

• 公開鍵：相手に渡す鍵

• 秘密鍵：自分だけがもつ鍵

様々な暗号アルゴリズムについて説明します

暗号

古典暗号はアルゴリズムと鍵は不可分
現代暗号はアルゴリズムは公開、鍵を秘密にする

暗号は危殆化していく

暗号の種類

• 鍵の種類に応じたもの：対称鍵・公開鍵
• 入力データの種類に応じたもの：
  • ブロック暗号
    • 固定長の暗号化方式
    • 長さが一致しない場合はパディングを入れる
  • ストリーム暗号
    • 連続したデータの暗号化

暗号化方式の元の単語を知っていると、答えを推測できるかもしれない

• Data Encryption Standard (DES)

• Advanced Encryption Standard (AES)
  どちらを利用するべきか → Advanced なので AES

• Digital Signature Algorithm (DSA)

• Rivest Shamir Adleman (RSA)

  • 人の名前

その他の暗号化テクニック及び技術

2つの暗号（対称・非対称）以外の技術

• 量子暗号：光の性質（回転・位相）を用いた技術
• 鍵共有を量子の性質を用いたものになる
  • 対称型暗号・非対称暗号にカテゴライズできない
    • 数学の性質
  • 量子暗号は物理学の性質

各種ハッシュ関数と暗号化ツールについて解説します

MD5とMD6

元の平文がわからない文字列となる

• 暗号技術：可逆（暗号に変換したら必ず平文に戻せる必要がある）
• ハッシュ技術：非可逆（ハッシュ値に変換したら平文に戻せてはならない）
  • 情報を意図的に落とすことで、衝突するパターンが生まれるので推測ができない
  • 改ざん検知に用いられる
  • 少しでも変わると、最後の結果に大きく変わる性質がある
  • 何度計算しても同じ値になる
  • 長さが常に同じ
  • 別名：フィンガープリント・メッセージダイジェスト

MD5: Message Digest 5
MD6: Message Digest 6

Secure Hashing Algorithm (SHA)

• SHA-1, SHA-2, SHA-3 の数字はバージョン
• SHA-256 は 256 bit の意味

PKIと証明書管理の概念について説明します

公開鍵暗号とハッシュ技術を組み合わせてやる

デジタル署名

デジタル署名：ハッシュ値を暗号化した暗号文のこと

• 改ざんされていないことの確認
  • ハッシュ値を求めてわかる
  • 完全性（Integrity）の保証
• 本人性の確認
  • 公開鍵暗号を用いる
  • 送信者はハッシュ値を送信者が暗号化して送る
  • 受信者は復号したハッシュ値と計算したハッシュ値の比較を行う
  • 第三者が、この鍵は誰のものということを保証してもらう必要がある
    • PKI (Public Key Infrastructure) が必要

IPAの問題では

• ハッシュ値の暗号化は誰の何の鍵を用いるか
• ハッシュ値の復号は誰の何の鍵を用いるか

デジタル証明書の規格：X.509

サブジェクト（鍵の持ち主）と公開鍵が含まれている必要がある

Public Key Infrastructure (PKI)

公開鍵の本人の結びつきを証明する

1. Key Pair を生成する
   • どちらを秘密鍵・公開鍵にするかを決定する
2. Registration Authority (RA) に申請する
   • 本人であることを確認する
   • 免許証やマイナンバーカード
3. Certification Authority (CA) にRAが発行要求
   • 公開鍵証明書を発行
4. ユーザが公開鍵証明書を受け取る
5. 証明したい相手に公開鍵証明書を送る
6. Validation Authority (VA) に受け取った人が公開鍵証明書が正しいか確認
   • 正しいか
   • 有効期限を迎えていないか
   • 失効していないか

[NOTE]
失効管理もされている

[IMPORTANT]
ストーリー系問題として出やすいので流れを抑えておく
e.g. どの順番で行われますか

暗号技術の他の応用例について議論します

興味があれば読んでおく

ブロックチェーン

ハッシュ技術を利用した技術
ブロックチェーンは改ざん可能だがバレる

• 新しい情報を登録するときに、前の情報から求めたハッシュ値を末尾につけることで改ざんを把握することができる

ステガノグラフィ

ステガノグラフィ：電子透かし

• 本物かどうか確認するのに用いられる
• 見た目が同じ写真に、何らかの情報を埋め込むことができる

[NOTE]
用語を抑えておく

---

モジュール15：データセキュリティ

アクセス制御に関する内容

データセキュリティとその重要性を理解します

データセキュリティの必要性

ビジネスデータ：組織があったときに、様々なデータが発生する

• 無駄なものがなければ重要データである
• 分類すると
  • お客様データ
  • 個人識別可能データ
  • 取引データ
    原因が発生したときに、影響を受ける

データのセキュリティしっかりしたほうが良いですよね

[NOTE]
覚えておく必要はない

データセキュリティ

どこにデータがあるかの3区分

• Data in Transaction: 転送中
  • 傍受されたり・改ざんされていないか
• Data in Use: 使用中
• Data in Rest: 保存中
  • 暗号化したり・パスワードロックしたり
  • 保存されている状況が一番長い

データが消えた時にバックアップから復旧できること
暗号化とアクセス制御の話が主体となる

情報管理ライフサイクル

• 長い時間がたった後のデータ
  • データが保持される期間と、組織に滞在する時間が一致しないことがある
• データの後始末の話
  • データを作った時にいつまで保存して、いつ削除するかを記載する

データの役割と責任

名称と意味が一致するようにしておく

データの分類

機密度で分類する

• データを誰に見せるか

データセキュリティテクノロジー

機密性の観点

• データアクセス制御
• データ暗号化：データが戻せる必要がある

データが戻せると困る

• データマスキング
• データ破壊

可用性の観点

• データ回復とバックアップ

その他

• データ保持：アカウンタビリティ・認証

様々なデータセキュリティ制御を議論します

ACL: Windowsでのファイルやフォルダのアクセス制御とアクセス許可を設定する

ファイルを右クリックしてアクセス権を設定することができる

ACL: Linuxでのファイルやフォルダのアクセス制御とアクセス許可を設定する

基本的にはコマンドでやるケースが多い

「保存中のデータ」の暗号化

• ドライブ単位の暗号化
  • 内蔵ドライブ
  • リムーバブルドライブ
• ファイルやフォルダレベルの暗号化

データベースの暗号化

データベースのデータの暗号化

• 読み取りなどからの保護
• 結果として暗号化されたデータとなっていれば良い
  • アプリケーションが保存前に暗号化
  • トランスペアレントの暗号化
    • アプリケーションが予め定義しておくだけで、データベース側が暗号化・復号する方式
    • 暗号化の単位
      • データベース全体
      • テーブルレベル
      • 列レベル
      • セルレベル
    • MS SQL Server / Oracle などで対応

「転送中のデータ」を暗号化する

• Webサイトとブラウザの間の暗号化
• 電子メールの暗号化

デジタル証明書によるセキュアなHTTP接続

HTTPS
ブラウザとWebサイトでも、共通鍵と公開鍵の好いとこ取りをしている

• SSL証明書
  • Extended Validation (EV) SSL証明書
  • 標準SSL証明書
    • Domain Validation (DV) SSL証明書
    • Organizational Validation (OV) SSL証明書

1. ブラウザ側が共通鍵を作成する
2. ブラウザに共通鍵を送る際に、Webサイトの公開鍵を用いる
3. セッション確立後は、その共通鍵で秘密通信を行う

SQL Server データベースエンジンのインスタンスに対する暗号化接続の有効化

ブラウザ → Webサーバ → データベース

• Webサーバとデータベース間の暗号化
  • SSL / TLS で暗号化できる

電子メールの暗号化：MS Outlook

下記両方できる

• 1つのメッセージを暗号化
• すべての送信メッセージの暗号化

電子メールの暗号化：Gmail

• S/MIME でメールを暗号化
• SecureGmail で暗号化

データマスキング

元のデータに戻せてはならない
マスキング：データを見えなくする処理

データのバックアップ、保持、破壊について話し合います

可用性 (Availability) の確保

データバックアップ用メディアデバイスの例

自分たちに適したメディアを選択する

• 光ディスク
• HDD / USBフラッシュドライブ
• テープドライブ

ほとんど HDD / SSD

RAIDレベル0：ディスクのストライピング

並列化して高速化することを目的としている

[IMPORTANT]
RAID0 と RAID1 と RAID5 の違いをわかるようにする

RAIDレベル1：ディスクのミラーリング

冗長性を確保することが目的

RAIDレベル3：パリティ付きディスクのストライピング

どれかが集中して壊れやすい

[NOTE]
ほとんど使われていない

RAIDレベル5：ブロックインターリーブ分散パリティ

RAIDレベル3の対策
負荷が分散する

RAIDレベル10：ブロックのストライピングとミラーリング

4台用意すれば、冗長性と高速性を担保できる

Storage Area Network (SAN)

ストレージの高速化を確保するためのもの

Network Attached Storage (NAS)

LANの中に設置すれば、すぐにファイルサーバとして使える
大量の読み書きをするとネットワークを圧迫する

適切なバックアップ方法の選択

• ホットバックアップ
  • オンライン：読み書きが発生しているときにバックアップがとれる
• コールドバックアップ
  • オフライン：読み書きが発生しているときにバックアップがとれない
• ウォームバックアップ
  • ニアライン：比較的トランザクションが少ない時にとるオンライン

バックアップ先の選択

• オンサイト：バックアップのすぐ横においておく
• オフサイト：遠くに置く
  • 同じ自然災害や火災に巻き込まれない
  • バックアップするのに時間がかかる
• クラウドデータバックアップ
  • データ保護の信頼性が高い
  • 欠点：遅い
    • 今は選択肢も多いので、コストと速度をトレードオフで選ぶことができる

[NOTE]
バックアップをオンサイトとオフサイトの2つ用意しておけば良いところ取りはできる
最近はメディアを送ることをやめて、クラウドの活用がされている

バックアップの種類

• フルバックアップ
• 差分：フルバックアップとの差を取るもの
  • 情報量が増分に比べて多いので安心感が上がる
• 増分：前回分からの差を取るもの
  • ディスク容量が減らせる
  • バックアップ速度を上げることができる

[NOTE]
人によって差分と増分が一緒に語られることがある

データ破壊

データを読めなくする
破壊：すべてを二度と読めなくする
マスキング：一部だけ読めなくする

データ破壊のテクニック

ハードウェアとしては使える状態で残る

• クリアリング：ソフトウェアの機能で実現可能

ハードウェア的に使えなくなる

• パージング：強力な磁場で使えないようにする
• 破壊：物理的に跡形もなくなるようにする
  • 物理的に復元が不可能

機密度に合わせて選択すれば良い

データ損失防止の概念について説明します

Data Loss Prevention (DLP)

用語だけ覚えておく

---

モジュール16：ネットワークトラブルシューティング

ネットワークトラブルシューティングについて話し合います

ネットワークにトラブルがあった時に原因の切り分けをコマンドで行う

• ping / netstat / dig を打ってみる など

ユーティリティとツールを使ったネットワークの基本的な問題のトラブルシューティングを学びます

Lab でコマンドを使いこなせるようにする

• ping
• ipconfig
• ifconfig
• netstat
• pathping
• route
• dig
• nmap
• wireshark
  • 自分が見たいパケットをフィルタリングして見るためのツール

[IMPORTANT]
使いこなせるように

• nmap のオプション
  • 使いそうなオプションは把握しておく
• wireshark の絞り込みが重要（ディスプレイフィルタ）
  • フィルタの書き方

---

ラボの解説

4以降の内容

[IMPORTANT]
ツールは色々使って使えるようにしておく

[IMPORTANT]
環境構築が必要なラボは、試験には出ない
結果のキャプチャ情報は問題に出てくる
環境のことでヤマを張らない方が良い

[NOTE]
ハッシュ計算

• MD5の計算: MD5 and MD6 hash Calculators の md5calc を利用できる
• コマンドでもOK

[IMPORTANT]
ハッシュの問題は改ざんの有無が聞かれることが多い
改ざんされていないファイル名は何か など

Mod.13:Ex.1

ラボにはIoTデバイスは入っていない
エミュレータで行っている

Wireshark はリアルタイムキャプチャと、pcap を事後に読み込む

Mod.17:Ex.4

IPアドレスでスキャンした後ポート番号でスキャンする

• nmap で両方使える

Mod.18:Ex.2

Windows の Event Viewer を使う

• Log Viewer
• ログから読み取りたい内容を読み取れるようになる
• フィルタの設定が重要
• ファイルでログが提示されることもある

Mod.19:Ex.2

インシデントレスポンスのモジュール
マルウェアに感染した場合にどのようなマルウェアかを突き止める

[IMPORTANT]
マルウェア解析問題は、解析に時間がかかることがあるので、先に他の問題を解く

Mod.20:Ex.4

フォレンジックの常套手段はコピーを取る

• アドレス空間すべての情報を取得してコピーする
• それに対して解析しないと、改ざんしていないことを証明することが難しい

与えられたマシンイメージを解析する

• Autopsy：マシンイメージの解析ツール
  • 立ち上げてディレクトリ空間を確認することができる

Mod.17:Ex.1

Wireshark と tcpdump

[IMPORTANT]
フィルタを色々試す

Mod.16:Ex.2

トラブルシューティングのコマンドを使う
nmap をしっかり使いこなせるようにする

• オプションを把握する

Hping3をトラブルシューティング

---

モジュール17：ネットワークトラフィックの監視

ネットワークトラフィックモニタリングの必要性と利点を理解します

ネットワークトラフィックの監視

2つ視点：大きさと小ささ

• 一つ一つのパケットを見る
• 全体の量
  • 帯域モニタリング

ネットワーク監視の必要性

• トラブルが無いときも監視する必要がある
  • 常に監視する
• ツールで見つけることができるのは異常との一致

正常なネットワークトラフィックと不審なネットワークトラフィックのベースライントラフィックシグネチャを決定します

ネットワークトラフィックシグネチャ

フィルタが大事

• 見る必要がないものを見ないのが大事
• 正常な通信は見る必要はない

トラフィックの観察は何を見ないかが重要

• グレーと黒の塊を抜き出して、確認する

通常トラフィックシグネチャのベースライン

• ホワイトなパケットはできるだけ取り除く
  • グレーなパケットを引っ張ってくる

不審なトラフィックシグネチャの分類

• グレーなパケットに対して、白黒を人が判断していく

攻撃シグネチャ解析テクニック

• 黒を判断した場所によって名前がついている
  • コンテンツベース：ペイロードに問題がある
  • コンテキストベース：ヘッダ部分におかしい問題がある
  • アトミックシグネチャベース：単体
  • コンポジット：複数情報

不審なトラフィックに対するネットワーク監視を実施します

Wireshark

パケットスニファ：一つ一つのパケットを解析するソフトウェア

Wireshark でTCPストリームを追跡する

[NOTE]
試験時にラボで使うツールについてはラボ環境で確認することができる
テキストにも書いてあるラボの内容はしっかり覚えておく

Wireshark のディスプレイフィルタ

• キャプチャフィルタ：pcap ファイル
• ディスプレイフィルタ：キャプチャした情報の中で何を表示するか

追加のWiresharkフィルタ

[NOTE]
ラボの演習で使ったフィルタを覚えておく

ftp / telnet / http は暗号化されていないのでパケットの内容が読める

---

モジュール18：ネットワークログの監視と分析

ログの概念を理解します

ログ

エラーなどの記録

• いつ、どんなことがあったかが記載されている
  • タイムスタンプは必ず書いてある
  • イベントやエラーの時系列の情報
• 内容はログレベルで変更できる

攻撃は防げない

• 抑止効果：ログを取っていると宣言することで、攻撃者のモチベーションを下げる
• 検証・解析：被害の範囲を特定するのに用いる
  • ログがあれば流出件数がわかる
  • ログがない場合は最大数を伝える
    • e.g. ◯万人の情報が漏れたかもしれない
  • 原因を追求して対策するために利用する

ロギング要件

「ログを使ってやりたいことは何か」から決める

• 何を取る
• いつまで取る
  など

一般的なログフォーマット

実際にはバラバラ

• 必ず含まれているタイムスタンプですら、様々な書き方がある
  • Y-m-d なのか d-m-Y なのか など

ログを取るときには

• 時間の同期が取られている必要がある
• ログのフォーマットを合わせるか、正規化する
  • データクレンジング的な操作が必要

ロギングのアプローチ

• ローカルロギング
  • ホストマシンの中にある
• 集中ロギング
  • 一箇所にログ情報を集める

Windowsシステムにおけるログの監視と分析について話し合います

[IMPORTANT]
ラボの内容が理解できるように読んでおくと良い
ログビューアで何ができるか見ておく

Windowsログの監視と分析

ログの見方をしっかり把握しておく

Linux におけるログの監視と分析について議論します

Linuxログ

Linuxのログはほとんど PlainText になっている
下記で確認する

• cat
• less
• head
• tail
• grep

Linuxログの重大度レベルと値

重要度：数字が小さいと大変なこと

[NOTE]
CVSSとは大小関係が逆なので気をつける

各種ログ管理ツールを説明します

Syslogツール

EC-Council は集中ロギングを推している
集中ロギングをしていると、改ざん対策にもなる
データクレンジングを兼ねた形になる

---

モジュール19：インシデント対応

ラボ：マルウェアに感染して、マルウェアをツールで解析する
オペレーションの話（≠ テクニカルな話）

インシデント対応の概念を理解します

インシデント対応

• 起こさないようにする
• 起こってしまったら迅速に対応できるようにする
• NIST SP 800
  • 識別・防御・検知・対応・復旧
  • 最初にやるべきは、防御をしっかりやる
    • 脆弱性対応 など
    • 識別をして、存在する情報資産の防御を行う
• 防御までしっかりやったうえでの対応について考える
• インシデント：対策をしっかりしたうえで発生する
  • 二重の備えが大事
  • 日頃の準備が大切

IH&Rチームの役割と責任

• インシデント対応は持ち回り
  • 割り当てられた仕事としてやっているケースがほとんど
• インシデント発生時は経営の問題
  • 経営者が出て謝罪する必要がある
  • 経営者が自分事として取り組む
  • インシデント対応の担当役員として行う必要がある
    • 経営者が権限委譲して、社長としっかり話し合う必要がある
• 事実関係を資料として渡す
  • IR: インベスターリレーションズをやっている人が多い
  • PR: パブリックリレーションズをやっている人も関連する

[IMPORTANT]
様々な人が関係する

インシデント対応における一次対応者の役割を理解します

一次対応者

一番初めにインシデントに気付いた人が大事

• 一般ユーザのケース
  • とにかく触らずにすぐに報告すること
• ネットワーク担当者のケース
  • 初動が正しく早く行えると、インシデントの影響を小さくできる

[IMPORTANT]
とにかく報告すれば褒められるという環境を作る

• 余計なことをしない
• 初動を正しく行う

一次対応者の役割と責任

トレードオフな場合がある

• 証拠の保全
• 被害拡大の防止
  どちらも大事

現場では議論している暇はないので

• 記録を残す
• 予め議論をしておく
  すぐに動ける状況を作っておく

[NOTE]
マニュアルはほとんど意味がない
インシデントのマニュアルを作る過程で現場で起こる内容の議論を予め行う
組織が何を大事にしているかで折り合いを探す
実際に発生している中で、それを話している時間はない

現場で一次対応をするときには、ちゃんと記録を残すと、裁判でも証拠として認められる

一次対応の前に知っておきたいこと

読んでおく
インシデント対応計画を作った人たちの頭には入っているはず

インシデントハンドリングと対応プロセスを説明します

IH&Rプロセスの重要性

IH&R: Incident Handling & Response
読んでおく

IH&Rプロセスフローの概要

インシデント対応計画が使われる場面がないことが一番良い
使われないように対策する

もし発生したら、責任者（判断できる人）にすぐに報告する

• 初動を早くする
• 報告された内容が本当にインシデントなのかを確かめる
  • インシデントだった場合は重要度（内容や程度）を確認する
  • 被害拡大防止と証拠保全を行う
  • 落とし所は客観的な記録を取りながらやる
    • 二人で行うことが理想
      • 一人が実行者
      • もう一人が確認者
    • 他の人達は見ている人（証人となる）

[IMPORTANT]
二度と同じインシデントを起こさないための教訓にする

---

モジュール20：コンピュータフォレンジック

興味深い内容なので、読んでみると良いかも

コンピュータフォレンジックの基本を理解します

読んでおく

フォレンジックインベスティゲータの役割と責任の明確化

デジタル証拠の種類

揮発性データ

• 電源が切れてしまうと証拠がなくなる

証拠に関する規則

証拠が満たしておくべき条件

• 理解しやすい
  • 犯罪のこととどう結びついているのか
• 許容範囲
  • 確からしさが許容できるか
• 真正性
  • 本物かどうか
• 信頼性
• 完全性

ベストエビデンスルール

読んでおく

フォレンジック調査のプロセスとその重要性を理解します

面白い内容

フォレンジック調査の様々なフェーズについて説明します

SKIP

フォレンジック調査を支援するデジタルフォレンジックの情報源

フォレンジック調査報告書テンプレート（☆Module 20 Page 2349）

• どんな調査をしたか
• 調査の目的
• 調査のプロセス

裁判官にとって信頼に足るものであるようにする

• 推測や飛躍がないようにする

証拠の収集

デジタル証拠の情報源：ログファイル

読んでおく
ログは証拠になる

• セキュリティログ
• Webアクセスログ
• DNSログ
• ダンプファイル
• 認証ログ

パワーオンコンピュータへの対応

パワーオンの状態で存在する証拠は、スタティックな状態にする必要がある

• パワーオンの状態で写真・書き写す などで、できるだけ残す

[NOTE]
電源オフにするまえにできるだけ沢山残す

[IMPORTANT]
基本的に操作は何もしない
やるのはスリープ解除やウィンドウの切り替えくらい

パワーオフコンピュータへの対応（☆Module 20 Page 2378）

パワーオフのコンピュータは基本的にパワーオフの状態を維持する

• パワーオンにはしない
• 基本的に触らない

解析する場合はオフの状態で複製をとる

• 複製に対して解析を行う

[NOTE]
モバイルデバイスの場合も同じように扱う
証拠を変えないように取り出した後に電源をオフにする

証拠の確保

管理の連鎖（CoC）

CoC: Chain of Custody
証拠は確保されてから、法廷に持っていかれるまで、どのように管理されているかの情報が必要

管理の連鎖（CoC）文書の簡易フォーマット

他の人が証拠の完全性が保証されていない状態にならないようにする必要がある

[IMPORTANT]
CoC が大事

データ取得の概要

Skip

証拠分析の実施

Skip

---

モジュール21：事業継続と災害復旧

BC: Business Continuity
DR: Disaster Recovery
BIA: Business Impact Analysis
RPO / RTO

事業継続（BC）と災害復旧（DR）の概念を理解します

事業継続

ISO規格がわかりやすい
事業継続性がある: e.g. 地震という災害が起こったときに事業を続けられる状態（冗長化）をしている

• 事業継続性がある企業は顧客からの信頼を得られる
• 災害に対する準備をしておく
  • 先行投資

災害復旧

読んでおく

事業継続管理

コストがかかる

• 後で得られるメリットを上回るか
• 定量的な判断が必要

Business Impact Analysis: BIA

何もしないときにどれくらいの被害があるか
どれくらいの被害があるかを考えておく

• 対策は何があるかを後から考える
• 一番費用対効果が高くなるものを考える

Recovery Time Objective: RTO

バックアップを取っておく

• いつの時点まで戻したいかで、どれくらいの頻度でバックアップを取得するかが変わる

RPO: どこまで戻したいか
RTO: どれくらいの頻度でバックアップを取るか

• 理想は RTO は0
• RPO / RTO を小さくすればするほどコストがかかる
  BIA から判断する

サービス中断をどこまで許容できるかを考える
すぐに戻したい場合はコストがかかる

BC / DR活動について話し合います

Skip

事業継続計画（BCP）、災害復旧計画（DRP）を理解します

読んでおく

---

モジュール22：リスク管理

RM: リスクマネジメント

• ISO 31000
• JIS Q 31000（5章と6章が大事）

リスク管理の概念を理解します

いろいろな人が関係する
経営者の経営の問題

リスク管理の様々なフェーズを議論します

リスク管理のフェーズ

リスクは想像

1. リスク特定
   • 様々な部署から考える限りのリスクを列挙する
     • ブレストでやる
     • リスクを洗い出す
   • リスクについての想定外をなくす
2. リスク評価
   • ストーリーや被害を洗い出す
   • 起こってしまった場合の確率と影響を決める
3. リスク分析
4. リスクの優先順位付け
   • マトリクスに当てはめていく
5. リスク対応
   • リスク軽減：結果が低くなるようにする
     • リスクを許容できるところまで下げる
   • リスク回避：どうしても折り合いがつかないのであれば事業をやめる
   • リスクの移転
     • ほぼ発生しないので保険にかける
6. リスクの追跡とレビュー
   • リスクが増えたら対処する
   • 絶えずレビューを行って、リスクが低減された状態を維持する

リスクマトリクス

• 起こった時にどういう被害があるか
• どれくらいの頻度か

3段階くらいで決めることが多い

早く対処して確率を下げるか、影響を小さくする必要がある

• すべてのリスクをマトリクスにプロットして、優先順位を決める

[IMPORTANT]
把握しておく

リスクレベル

3段階で決める

リスク対応プロセス / オプション

リスクを低減、リスク移転をして、リスク受容できる状態に持っていく
組織として受容できるリスクの大きさに持っていったら維持する

各種リスク管理のフレームワークを理解します

名称が頭に残っている程度で良い

---

BluePrint: 試験の設計図

日本語版ブループリント

サブドメインを見る

Official CCT（英語）の情報がすべて
CCT は問題集はない
CEH は問題集がある

試験は択一問題

• 正しいコマンドはどれかという問題は出るかも
• ストーリー（順番）をしっかり把握するようにする
• 選択肢を見てから文章を読むほうが良い
  • CCT においては背景の説明は不要な情報が多い