-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_SCManagement
セキュリティに関する一般的なマネジメント・システムに対する言及。
-
リスクのセキュリティ・ポリシ策定は
PMPのリスク・マネジメント（PMP：共通の該当節を参照）とほぼ同じ。
PMBOK のリスク・マネジメントとの対応は以下のとおり。
-
リスク・アセスメント
≒ PMP：計画 - リスク（リスク・マネジメントの計画プロセス）の
リスク対応計画以前 -
-
リスク対応方法の洗出
≒ PMP：計画 - リスク（計画プロセス）のリスク対応計画 -
リスク対応の実施
≒ リスク・マネジメントの実行プロセス（PMP：実行 - その他の該当節を参照）
-
リスク対応方法の洗出
-
リスク及びリスク対応方法の見直し
≒ リスク・マネジメントの監視・制御プロセス
（PMP：監視・制御 - その他の該当節を参照）
リスク＝不確実性
（能動的リスクとも言う）
為替、株価のような、
好機と脅威（利益と損失）
の両方の可能性のあるリスク。
-
脅威（損失）のみを含むリスク。
※ 好機（利益）は含まない。 -
純粋リスクによる損失の種類
- タイムラグの無い直接的な損失
- 資産損失、人的損失
- タイムラグの有る間接的な損失
- 業務中断、信用失墜などの収益損失
- 賠償金、罰金などの責任損失
- 後処理に掛るコスト等
- 復旧や再発防止の費用
-
SC：脆弱性の該当節（用語）を参照。
-
情報資産
-
脅威
-
脆弱性
- 予測し難い。
- 損失が大きい。
リスク・アセスメント ≒ PMP：計画 - リスク（計画プロセス）なので、
- 効果的な、セキュリティ対策プランを導き出す。
- 限られた予算を有効活用して、最大限の対策効果を得る。
リスクの大きさ
重大性を評価する条件
以下の体系（≒ PMP：計画 - リスク（計画プロセス））
- リスク特定
- リスク分析（定性分析）
- リスク評価（定量分析）
（何れも PMP：計画 - リスク の該当節を参照）
リスクが顕在化した際の対応
（対応計画（PMP：計画 - リスクの該当節を参照）に従い対応）
オーナーがアカウンタビリティ（担当、権限）を持つ。
- リスク対応の中の受容の意思決定。
- 受容後はモニタリング対象になる。
- リスク対応後も残留するリスク。
- 特定されていないリスクも含む。
- 残余リスク、保有リスクとも呼ぶ。
-
概要
基準やガイドラインに基づくリスク分析を行う。 -
メリット
- 特別なスキルは不要
- 時間やコストが少なくて済む。
-
デメリット
- 大まかな分析になる。
- 主観によりバラつく。
- 質問表の品質に左右される。
-
概要
知識と経験に基づくリスク分析を行う。 -
メリット
属人的なので分析者の能力が高ければ
高品質な分析結果になる。 -
デメリット
属人的なので分析者の能力が低ければ
低品質な分析結果になる。
-
概要
- ベースライン・アプローチの逆の特徴。
- 所謂、リスクの定性分析と定量分析
（何れも PMP：計画 - リスク の該当節を参照）で、
情報資産、脅威、脆弱性から分析・評価を行う。
-
コスト
- 特別なスキルが必要
- 時間やコストが必要
-
効果
- 詳細な分析になる。
- 抜けや偏りがない。
- 客観的な評価が可能。
-
概要
- 全体をベースライン分析で
- 重要部分を詳細リスク分析で
-
メリット
- コスパの最大化
- 重要な情報資産については詳細に分析評価可能。
-
デメリット
- 全体のベースラインで重要部分の誤認識が発生し得る。
- この、重要部分の判断次第で結果が大きく変わってしまう。
-
対人
- アンケート法
- チェックリスト法
- インタビュー法
-
対物
- ドキュメントレビュー法
- 現地調査法
-
ツール
- リスク分析ツール
チェックリストのソフトウェア化 - 脆弱性調査ツール
ドキュメントレビュー法、現地調査法のソフトウェア化
- リスク分析ツール
- 定性分析
- 定量分析
（何れも PMP：計画 - リスク の該当節を参照）
ISMSの「ステップ１：適用範囲・境界の定義」のリスク版
- 適用範囲（組織, 情報システム, etc.）
- 境界定義（事業, 組織, 拠点, etc.）
- 最初は限定的に実施し、徐々に対象範囲を広げていく。
- 電子化された情報
- 紙媒体も含めた情報資産
※ 元 Wiki では見出しのみで、本文は書かれていない。
※ 元 Wiki では見出しのみで、本文は書かれていない。
-
リスクの洗出し。
-
構成要素
- 情報資産
- 脅威
- 脆弱性
↓ ↓ ↓
- 具体的なリスクの影響
-
構成要素
-
以下の様な表を使用する。
| # | 情報資産 | 脅威 | 脆弱性 | 想定されるリスク |
|---|---|---|---|---|
| 1 | ... | 設備 ▼ | ▼ 災害 | ... |
| 2 | ... | 技術 ◀ | ▶ 障害 | ... |
| 3 | ... | 管理 ▲ | ▲ 人的 | ... |
- 定性
以下の様な表を使用する。
| 情報資産 名称 |
情報資産 レベル |
脅威 内容 |
脅威 レベル |
脆弱性 レベル |
想定されるリスク 機密性 |
想定されるリスク 完全性 |
想定されるリスク 可用性 |
|---|---|---|---|---|---|---|---|
| xxx | ・機密性：a ・完全性：b ・可用性：c |
yyy | x | y | axy | bxy | cxy |
-
定量
-
直接損失
- 資産損失
-
間接損失
- 賠償金
- 機会損失
- 信用低下による損失
-
対応費用
- 損失資産の再購入
- 復旧に伴う人件費
- セキュリティ対策製品の購入費用
-
リスク顕在化頻度（回/年）
-
リスク強度（年間損失額）
＝（直接損失＋間接損失＋対応費用）＊リスク顕在化頻度
-
リスク対応は「セーフガード」とも言う。
純粋リスク（脅威）に対する戦略
（PMP：計画 - リスクの該当節を参照）には以下のモノがある。
-
回避
-
転嫁
特に、保険と契約が代表的 -
低減
回避しきれない場合は低減という対策になる。 -
受容
回避・低減の残留リスクの受容と、
なにもしないで受容のパターンがある。 -
エスカレーション
-
対応手法
-
回避
根本原因の排除 -
低減
-
損失予防
発生頻度を減らす対応 -
損失軽減
発生時の影響を小さくする対応 -
リスク分離（分割）
情報資産など影響を受ける対象の分割（≒損失軽減） -
リスク集中（結合）
情報資産など影響を受ける対象の結合（＋損失予防）
-
-
転嫁（移転）
特に、保険と契約が代表的
-
-
具体例
- 物理的対策
- 技術的対策
- 運用管理的対策
※ 脆弱性に対する対応。
- 評価した損失や対応の諸費用を確保しておく。
- また、転嫁のための保険もリスク・ファイナンシングに含まれる。
※ 元 Wiki では見出しのみで、本文は書かれていない。
-
セキュリティレベルの向上
-
費用対効果の向上
リスクに応じた適切なセキュリティ対策を施す。 -
対外的な信頼性の向上
組織の信頼性の向上
-
基本方針
-
目的、対象範囲、維持管理体制、義務、罰則
-
ISMSの基本方針
情報セキュリティのための方針群は、-
管理層が承認・発行し、
従業員及び外部関係者に通知すること。 -
その有効性や適切性を維持するため、
定期的に、又は重大な変化が発生した場合にレビューすること。
-
-
対策基準
基本方針を実践（適切な情報セキュリティを確保・維持）する
遵守事項や対策基準 -
対策実施手順、規定類
情報資産の特徴を考慮した詳細な手続、手順
-
-
ピラミッド
- 上位層：基本方針 ┬ 情報セキュリティポリシ
- 中間層：対策基準 ┘
- 下位層：対策実施手順、規定類
例（...の責任者）
-
情報システム部門
- システム部門
- ネットワーク部門
-
監査部門
-
法務部門
-
人事部門
-
教育部門
-
営業部門
-
事業部門
-
広報部門
-
弁護士
-
サイバーセキュリティ
-
情報セキュリティの
-
コンサルタント（指揮統制）
- 規格、制度
- リスク・アセスメント
- 内部統制
-
アナリスト（分析実務）
- 最新動向
- 他社の実情
-
- 情報資産
- 適用対象者
- 目的と罰則
- 主体と表現
- 運用方法
A.6 情報セキュリティのための組織
A.6.1 内部組織 目的
組織内で情報セキュリティの実施及び運用に着手し，
これを統制するための管理上の枠組みを確立するため。
A.6.1.1 情報セキュリティの役割及び責任 管理策
全ての情報セキュリティの責任を定め，割り当てなければならない。
（特に重要で責任はポリシに明記する必要がある。）
A.6.1.2 職務の分離 管理策
相反する職務及び責任範囲は，組織の資産に対する，
認可されていない若しくは意図しない
変更又は不正使用の危険性を低減するために，
分離しなければならない。
（利益相反関係下での中立性の維持は、立場の分離によってのみ実現される。）
A.6.1.3 関係当局との連絡 管理策
関係当局との適切な連絡体制を維持しなければならない。
（関係当局＝インシデントがあった場合に関係する内外の組織）
A.6.1.4 専門組織との連絡 管理策
情報セキュリティに関する研究会又は会議，
及び情報セキュリティの専門家による協会・団体
との適切な連絡体制を維持しなければならない。
A.6.1.5 プロジェクトマネジメントにおける情報セキュリティ 管理策
プロジェクトの種類にかかわらず，
プロジェクトマネジメントにおいては，
情報セキュリティに取り組まなければならない。
- CISO : Chief Information Security Officer
- 企業・組織内で情報セキュリティ全般を統括する担当役員。
-
CISOが委員長を務め、委員は各部門長が務める。
-
情報セキュリティマネジメントに関する意思決定を行う。
-
対する経営資源（予算・人材）の割り当て。
-
関する
- 全社的な方針・規程・施策などの承認
- 不予測事態発生時の対応方法（対外的対応、罰則の適用）
-
関連部門から選出された担当者が、
情報セキュリティ委員会の事務局を運営する。
-
情報セキュリティ委員会の下位組織。
-
各部門
-
の部門長から、課長やリーダー層が担当者に任命される。
-
での情報セキュリティ・マネジメントを推進する。
-
書類の作成
対策実施手順書
申請書、管理簿 -
教育の実施
-
インシデントの
発生状況の把握
対策指示
対策状況の把握
-
-
各部門内の情報管理者
- 情報の重要度や取り扱い方法（保管場所、廃棄方法、持出可否）の判断。
- その他、情報セキュリティ推進担当会議業務と重複。
情報システムの管理者
- 全社システム（情報システム部門の管理責任者）
- 部門システム（各部門の管理責任者）
- CSIRT : Computer Security Incident Response Team
- 組織内の情報セキュリティ問題を専門に扱う、インシデント対応チーム。
- 情報セキュリティ委員会に並立する、若しくは下位の組織。
詳細については、CSIRT（インシデント管理）。
情報セキュリティの内部監査
（高度午前 - サービス・マネジメント - システム監査の該当節を参照）を行う。
...。
-
情報資産の特定、台帳の作成、台帳による管理
-
各種資産の利用許容範囲の規則の文書化。
- 情報資産
- 情報処理施設
- その他、関連する資産
-
情報資産の分類
- 法的、価値、重要度、取り扱いなどで分類
- 分類（ラベル付け）に関する手順の策定と実施
-
分類体系に従った、
情報資産の取り扱い手順の策定と実施- 雇用、契約時（貸与、返却）
- 媒体の取外し時（保管、持出可否）
- 媒体の輸送時（保護）
- 媒体の滅却時（廃棄、処分方法）
-
洗出方法
-
台帳を使用して部門で洗い出し作業を実施
-
留意点
-
媒体
HDD, USB, CD/DVD, 紙
DB, ファイルシステム、ストレージ -
保管場所
自社、委託先
クライアント、サーバー、クラウド
オフィス（金庫、キャビネット、机）、倉庫 -
共有情報資産
各部門の情報管理責任者が
協議し責任範囲を決定する。
-
-
-
分類方法
-
機密性
権限の無い者からアクセスを受けることにより...。- 公表している情報
- 自社の業務・プライバシーへの軽微な影響
- 自社の業務・プライバシーへの重大な影響
- 顧客の業務・プライバシーへの影響（契約違反）
-
完全性（脅威の観点）
改ざん、重複、欠落などの発生により...。- 公表している情報
- 自社の業務・プライバシーへの軽微な影響
- 自社の業務・プライバシーへの重大な影響
- 顧客の業務・プライバシーへの影響（契約違反）
-
完全性（脆弱性の観点）
- 電子データ（認証・認可なし）
- 電子データ（認証・認可あり）
- 紙、ROM
-
可用性（影響度）
- 特に影響なし
- 自社の業務への軽微な影響
- 自社の業務への重大な影響
- 顧客の業務への影響（契約違反）
-
可用性（目標復旧時間（RTO）、最大許容停止時間（MTPD））
- 指定なし
- １日以内
- ３０分－数時間以内
- ３０分以内
-
-
台帳の項目例
-
情報資産
- 名称
- データ項目
- 利用者・管理者
- 記録媒体
- 保管方法
- 廃棄方法
-
個人情報
- 主体属性
- 利用目的
- 利用範囲
- 取得方法と取得手段
- 利用目的・範囲の通知方法
- データの件数
-
情報システム
- システム名
- 利用者・管理者
- 設置場所
- 主用途
- システム構成
- 情報内容
- 利用形態
- 認証・認可方式
- バックアップ運用
- ログ取得方式と保存期間
- SLA（Service Level Agreement）
-
-
ラベルの項目例
-
単体
電子ファイル、紙媒体- 重要度
- 開示範囲
-
複数
電子媒体、バインダ- タイトル
- 重要度
- 保管期間
-
-
ライフサイクル
- 取得・作成・生成
- 保存・保管・バックアップ
- 利用（閲覧・複製・加工・配布・公開・持出・送付・提供）
- 削除・廃棄・返却
-
取り扱い方法（ルール）
-
保管
場所・方法 -
複製
- 承認者
- 可否基準（目的・用途）
- 管理基準（管理、取り扱い）
-
持出 / 持込
- 承認者
- 可否基準（目的・用途）
- 管理基準（管理、持出/持込日、取り扱い）
-
廃棄
方法・手順 -
個人情報
利用目的・範囲の遵守
-
主に、セキュリティ領域、境界・区画の定義と運用。
-
物理的セキュリティ境界を定め、入退管理策によって保護する。
- 一般区画とセキュリティ区画を隣接させない。
- 持出 / 持込管理
- 資産（情報資産、機器）を許可なく持ち出さない。
- 媒体の廃棄、処分時に、データ、ライセンスソフトを確実に消去
-
物理的セキュリティ設計によって保護
-
対象：施設、オフィス、部屋
-
脅威：自然災害、人的偶発的（事故）、人的意図的（悪意のある攻撃）
-
対策：
- 装置の保護・保守、ケーブルの保護・保守
- クリアデスク方針、クリアスクリーン方針の適用
- 無人状態の資産（情報資産、機器）には適切なセキュリティ対策を適用
- 構外の資産（情報資産、機器）には異なるセキュリティ対策を適用
-
-
セキュリティ領域での作業に関する手順を設計し適用する。
災害 / 障害系
-
脅威（何れも 脅威の該当節を参照）
- 災害
- 障害（HW/SW以外）
-
対策
-
専用室 / 専用区画への設置
- 空調対策
- 地震対策
- 火災対策
- 電源障害対策
- 回線障害対策
- その他対策
漏水、浸水、落雷、静電気、ノイズ、凍結
-
iDC（Internet Data Center）の活用
- 防災設備（耐震 / 耐火）
- 防犯設備（入館 / 入室管理システム）
- 高信頼性の高速インターネット通信回線
- 大容量電源など、100%に近い可用性（24時間 365日）
-
| # | 項目 | 一般 | iDC |
|---|---|---|---|
| 1 | 利用時間 | 営業日 就業時間 | 24時間 365日 |
| 2 | 立地条件 | 商業用地 | 周辺環境、地盤、活断層など考慮 |
| 3 | 耐震・免振 | 通常 | 通常＋付加価値 |
| 4 | 床荷重(㎏/㎡) | 300 | 700 以上 |
| 5 | 階高(m) | 3.7-4.1 | 3.5-4.5 |
| 6 | 二重床(mm) | 0-500 | 500 以上 |
| 7 | 受電方法 | 通常 | スポットネットワーク方式 |
| 8 | 受電容量(VA/㎡) | 40-50 | 750 以上 |
| 9 | 自家発電 | 防災用、短時間 | 受電容量以上を24時間 |
| 10 | 無停電装置 | なし | 自家発電安定稼働まで電力供給 |
| 11 | 空調 | 通常 | 床吹出し、24時間 365日 |
| 12 | 消火設備 | スプリンクラー | ガス消火設備 |
| 13 | 通信回線 | 通常 | 2系統、多事業者対応 |
災害以外の物理系（不正行為）
-
脅威
人的（意図的）（脅威の該当節を参照） -
対策
- セキュリティ・レベルに応じた、
物理区画分類 / 管理者 / 入室者の明確化
- セキュリティ・レベルに応じた、
| 区画名 | 区画 | 管理規定の例 |
|---|---|---|
| 一般区画 | － | 名札の着用の運用 |
| 業務区画 | 一般区画と強固な隔壁により区切る | ・入室者特定、名札着用の運用。 ・常時施錠、入室記録。 ・常時入室者以外の入室は、常時入室者の立ち合い。 |
| セキュリティ区画 | ・一般区画と隣接させない。 ・業務区画と強固な隔壁により区切る。 |
・入室者特定、名札着用の運用。 ・常時施錠、入退室記録、常時監視。 ・常時入室者以外の入室は、常時入室者の立ち合い。 |
-
各区画の入退館管理方法の決定
-
一般的な開閉扉
・メリット：低コストで設置可能。
・デメリット：共連れ、すれ違いを防止不可能。 -
アンチパスバック開閉扉
・メリット：共連れ、すれ違いを防止可能。
・デメリット：常時入室者が入退室できなくなるケースあり（業務区画に少々、不向き）。 -
ゲートタイプの開閉扉
・メリット：二重扉やセンサにより共連れ、すれ違いを検知・防止可能。
・デメリット：設置にはコスト、スペースが必要。 -
＋警備員の配置
入退室時に日時、氏名、目的、対応者などを管理名簿に記入
または、持出 / 持込時の取り扱いルールの運用など。
-
-
入退館管理システムの導入
-
暗証番号
・メリット：鍵の紛失がない。
・デメリット：個人を識別できない。 -
ICカード
・メリット：個人識別可能、貸与が容易。
・デメリット：紛失が発生し易い。 -
生体情報
・メリット：個人識別可能、紛失が発生しない。
・デメリット：貸与が不可、登録が手間。
-
-
適切な区画に情報資産を設置・保管
主に、情報セキュリティに関する、雇用・契約に対しての要求。
-
雇用契約
-
従業員の経歴などの確認
事業要求、情報分類、リスク、法令、規制、倫理に従い実施する。 -
雇用契約書に
- 情報セキュリティに関する各自の責任、組織の責任を記載する。
- 違反行為に対する正式かつ周知された懲戒手続きを備える。
-
-
経営陣は雇用・契約相手に対し、
-
組織方針に従った情報セキュリティの適用を要求する。
（懲戒など処置、署名） -
職務に関する組織方針・手順についての教育・訓練をする。
-
雇用の変更・終了後の責任及び義務を定め伝達し遂行させる。
（時間外、雇用終了後の守秘責任）
-
-
社員の責務
- 就業規則
- 罰則の適用
-
体制面
-
権限の分散（職務の分離）
-
複数人での確認
- ミスを防ぐ意味
- 牽制（威圧 / 監視）の意味
-
バックアップ体制
-
-
産業保健
- 作業環境の整備
- 健康維持
- メンタル・ケア
-
教育・訓練
-
計画
- 計画の立案
- 教育体制の整備
- カリキュラム立案
・職務・役割（正社員以外も含む）に応じた
・新規雇用、配属 / 契約 / 職責変更時の
-
実施
- 計画の定期的 / 継続的な実施
- 実施記録と、実施効果の測定 / 分析
- 測定 / 分析の結果からカリキュラムを見直す。
-
-
委託先管理
- 情報セキュリティに関する能力 / 資格などの審査 / 選定する。
- 契約の際は秘密保持（NDA）や、責任範囲と対応方法を明確化する。
- 委託先の情報管理、対策実施条項などを定期的にチェックする。
分類がクライアントPCに該当する情報資産管理
-
必要性
クライアントPCの情報セキュリティ上の脅威が増えたため、
クライアントPCのセキュリティ対策の重要性が増した。 -
対策
-
情報セキュリティ・ポリシの策定と徹底
-
利用管理のルール
- 所在、利用者、管理者の明確化
- 共有の有無（有の場合、利用者、管理者の明確化）
- 個人所有PCの有無（有の場合、可否、管理方法の明確化）
-
社外持出時の追加ルール
-
物理的保護
-
認証デバイスの持運び
-
認証・認可関連
パスワードポリシ、ロックアウト、最小限の権限付与 -
ソーシャル・エンジニアリング対策
スクリーンセーバー、覗き見防止フィルタ
-
-
社内持込時のネットワーク接続のルール
- 承認者
- 可否基準（目的・用途）
- 管理基準（管理、持込/持出日、取り扱い）
...ウィルス・スキャンに加え、
OA-LANのセキュリティ・レベルを満たすように設定など。
（厳しい所は、要クリーン・インストールなどとなる）
-
インシデント発生時の対応
- 紛失・窃盗
- ウィルス感染
-
-
必要性
-
小型化
- 持出
- 紛失
- 窃盗
-
マルウェア
- セキュリティ対策
- 持出/持込（ネットワーク）
-
-
対策
-
小型化
- 持出対策（（入）出力デバイスの接続制限）
- 紛失（暗号化）
- 窃盗対策（チェーンで固定、暗号化）
-
マルウェア
エンドポイント（クライアントOS）対策
（脅威の該当節を参照） -
その他
-
認証・認可関連
パスワードポリシ、ロックアウト、最小限の権限付与 -
ソーシャル・エンジニアリング対策
スクリーンセーバー、覗き見防止フィルタ
-
-
情報セキュリティ・インシデントは、
- 迅速かつ適切に
- 徹底的に評価・見直
- 組織全体での再発防止
情報セキュリティ・インシデントに関する、
-
管理層の責任、及び手順の確立。
-
脆弱性の疑いには記録と報告を要求する。
-
インシデント発生前後
- 事象は適切な連絡経路を通じて速やかに報告。
- 事象をインシデントに分類するか否かを決定。
- インシデントには、文書化された手順に従って対応
-
インシデントの証拠情報の特定 / 収集 / 取得 / 保存の手順を定め適用する。
-
脆弱性、インシデントを分析し、将来的な可能性 / 影響の低減に活用する。
-
広義のCSIRT
-
国際連携を行うCSIRT
- JPCERT/CC
日本では一般社団法人 JPCERTなる組織があるらしい。
- JPCERT/CC
-
CSIRT間情報連携を行うCSIRT
- ISAC
セキュリティ情報共有組織（ISAC）
業界毎に、自治体、金融、電力ISACなどがある。
- ISAC
-
-
組織内CSIRT
インシデント・マネジメント（インシデント管理）をする。-
インシデント発生に備えた対応
- 最新情報取集
- 他組織と連携した情報収集
セキュリティ・ベンダ、関連機関、
業界団体（ISAC、協議会）、他のCSIRT
-
インシデント・ハンドリング
インシデント発生時の対応を主導- インシデントの検知 / 連絡受付
- 対応要否 / トリアージ（優先度付け）
- 影響範囲の特定 / 緊急処置
- 対応策と情報連絡の決定 / 実施
-
インシデント収束後の対応
- 対応結果の分析 / 評価。
- 再発防止の対応を行う。
- 対応体制、手順の見直し。
-
-
SOC : Security Operation Center
-
企業に向けたサイバー攻撃の検出や分析を行い、
的確なアドバイスを提供する役割を持つ部門や専門組織。 -
高い専門性が要求され、かつ24時間365日の監視が
必要であることから、外部に委託されるケースが多い。 -
分析のソースは
- IDPS
- IDS（不正侵入検知システム）
- IPS（不正侵入防止システム）
- ログ
- 統合ログ管理システム
- セキュリティ情報イベント管理（SIEM）
- IDPS
など。
- 結果をCSIRTにエスカレーションする。
予算確保は立ち上げプロセス的に行う。
-
CSIRTの活動範囲、対象インシデントの明確化
-
インシデント対応方針 / 計画（年度 / 中長期）の策定
-
CSIRTの体制の整備
- 連絡体制
- 個別の対応手順
-
規定類の策定
-
他のCSIRT関連組織との連携、情報交換
-
セキュリティ情報（脅威、脆弱性、インシデント事例）の
- 収集、ピックアップ
- 対応（分析、周知、対策（規定 / 手順））
-
-
インシデント発生に備える。
-
設備、機器の整備
-
外部リソースの確保（契約）
- 保険
- 監視サービス（SOC）
- インシデント対応サービス
-
システムの導入
- IDS
- IPS
- SIEM
- 統合ログ管理システム
-
教育と訓練の実施
-
-
インシデントの検知 / 連絡受付
- システム的な検知（SOC経由となることも）
- 人的な連絡（連絡受付窓口経由となることも）
-
対応要否 / トリアージ（優先度付け）
- 検知 / 連絡後、対応手順書に従いエスカレーションする。
- トリアージもあらかじめ定めた判断基準によって行う。
-
影響範囲の特定 / 緊急処置
- 被害拡大回避の処置を指示
- インシデント範囲の特定
- 暫定復旧処置（応急処置）
- 対応内容については記録に残す。
-
対応策と情報連絡の決定 / 実施
-
復旧のための対応策を検討
-
対応に必要なリソース確保
-
対応の実施、対応内容の周知
-
情報連絡（影響度、状況、対応、収束）
- 関係者（経営者、顧客、株主、監督官庁、捜査機関）
- デジタルフォレンジックの専門家
- インシデントについて広報（公表）
-
-
分析 / 評価
-
問題点の洗い出し
- システム的な問題か？
- 人的な問題か？
-
改善策の検討 / 決定
- 対応方法、対応手順
- リソースの確保・整備
対応体制、IDPS
-
再発防止策の検討 / 決定
- 即時 / 中長期
- リソースの確保・整備
-
顧客との契約内容の見直し
- SLA
- 責任範囲
-
-
見直し内容に基づき、
要員の教育と訓練を行う。
ITILでは、あくまで、サービス（事業活動）
- ...への影響を最小限に抑えて
- ...を迅速に復旧させること
に主眼を置く。
組織は、困難（危機、災害）な状況における、
情報セキュリティ及び、情報セキュリティ・マネジメントの
-
継続のための要求事項を決定する。
-
プロセス、手順、管理策を
- 確立して文書化する。
- また、それを、実施・維持する。
- 定期的に、管理策を検証する。
-
情報処理施設は、可用性の要求事項を
満たすのに十分な冗長性を持って導入する。
-
事業継続
- 管理（BCM : Business Continuity Management）
- マネジメント・システム（BCMS : Business Continuity Management System）
-
内容
- BCPの策定のためのマネジメント
- レジリエンス : 「回復力」「復元力」「弾力性」
-
BCI（Business Continuity Institute）が
- 実践的ガイドラインの発行などを通じ、
- 普及・啓蒙の活動を行っている。
- 日本には、BCI Japan allianceが設立されている。
-
規格・認証
-
規格
- 英国規格 BS : 25999
- ISO 22301 : 2012 / JIS Q 22301 : 2013
-
認証
一般財団法人日本情報経済社会推進協会（JIPDEC）によるBCMS適合性評価制度
-
-
事業継続
- 計画（BCP : Business continuity planning）
- と復旧計画（BCRP : Business Continuity & Resiliency Planning）
-
災害などの緊急事態が発生したときに、
- 企業が損害を最小限に抑え、
- 重要度の高い事業・サービスの
継続や復旧を図るための計画。
-
緊急時対応計画（CP : Contingency Plan）との違いは
SC：基礎の該当節を参照。
-
需要度の高い事業・サービスを対象とする。
-
BCM文化を根付かせる。
- 定期的なBCPの訓練や試験を行う。
- BCPの有効性を検証する。
-
ビジネス・インパクト分析（BIA : Business Impact Analysis）をする。
-
ボトルネックとなる業務プロセスやリスクを把握する。
（事業内容や環境に変化があった場合は、再度、BIAを実施しBCPを見直す） -
中断時の損失額を算出し、復旧の目標値を設定する。
-
目標復旧レベル（RLO）
業務の復旧のレベル（災害発生時からの経過時間の関数） -
目標復旧時間（RTO）
復旧に要する時間（当該時間の経過時点で、RLOのレベルを上回る事） -
最大許容停止時間（MTPD）
許容される停止時間（目標レベルの達成が、RLOの時間を下回る事） -
目標復旧時点（RPO）
（ロールフォワードする）時点で、バックアップを取る頻度の目安となる。
-
-
-
復旧段階を想定した対応体制を構築する。
-
緊急対応フェーズ
≒初動の対応 -
業務再開フェーズ
重要度の高い業務の復旧 -
業務回復フェーズ
重要度の低い業務の復旧 -
全面回復フェーズ
平時の状態まで復旧
-
-
専門家の客観的評価
-
不備が無く適切に機能しているかどうかを点検
-
定期的に監査を実施し、継続的に問題を改善する。
-
従来の障害要因
-
認識が低く、必要性が理解されていない。
-
統一的な基準がないため、客観的評価が難しい。
-
監査人のスキルや監査結果の妥当性評価の手段が無い。
-
-
欠陥個所の特定
-
情報セキュリティ・マネジメントの確立
（マネジメント＝PDCA、監査はC（Check）に相当する） -
顧客・社会からの信頼の獲得
-
情報セキュリティ監査の普及によるセキュリティ水準向上を目的とする。
- 2002/9より、経産省主管の監査研究会によって検討・研究され、
- 2003/4より、情報セキュリティ監査制度が開始された。
- 以下の管理基準、監査基準、企業台帳が公開されている。
-
情報セキュリティ管理基準
ISMS（SC：基礎の該当節を参照）の- マネジメント基準
- 管理策基準
から構成されている。
-
情報セキュリティ監査基準
監査業務の品質確保と、有効かつ効果的な監査の実施を目的とする、
内部監査、外部監査に適用可能な、下記基準から構成される制度。-
一般基準
監査人の適性、遵守事項 -
実施基準
計画立案、手続きの適用方法等の枠組みの規定 -
報告基準
監査報告の留意事項と、監査報告書の記載方式
-
-
情報セキュリティ監査企業台帳
- 監査を行う事業者（監査主体）を公開している。
- 国内の情報セキュリティ監査の浸透を図ることを目的としている。
-
情報セキュリティ管理基準は、ISMS（SC：基礎の該当節を参照）と同じ
-
ISMS適合性評価制度は、保証型監査
-
情報セキュリティ監査制度は、助言型監査
（何れも 高度午前 - サービス・マネジメント - システム監査
の該当節を参照） -
レベル
情報セキュリティ監査制度から始めてレベルを高め、
下記のレベル4に到達したら、ISMS適合性評価制度で、
ISMS認証を取得を目指すのが良いとされる。- ポリシ無し
- ポリシの策定のみ（実行されていない）
- ポリシの策定と行動
- マネジメント・サイクルが回っている。
- サイクルの見直しが定期的に行われてる。
- サイクルが有機的に結合している。
-
以下の目的で古くから整備されてきた。
「情報システムの信頼性,安全性及び効率性について,
監査対象から独立かつ客観的立場のシステム監査人が
総合的に点検及び評価などを行う一連の活動」 -
沿革
- 1985 : システム監査基準 初版
- 2004 : システム管理基準＋システム監査 に改訂
- 2018 : 以下との整合性を取る見直し（改訂）
- JIS Q 38500 : ITガバナンスに関する規格
- JIS Q 22301 : 事業継続に関する規格
- COBIT : 情報技術 (IT) 管理についてのベストプラクティス集
※ 同様に、監査企業台帳が公開されている。
「組織体の情報システムにまつわる
リスクに対するコントロールが
リスクアセスメントに基づいて
適切に整備・運用されているかを、
独立かつ専門的な立場のシステム監査人が
検証または評価することによって、
保証あるいは助言を行い
ITガバナンスの実現に寄与すること」
-
システム管理基準
≒ITガバナンス定義-
ガバナンス
経営陣がステークホルダーのニーズに基づき、
組織の価値を高めるために、実践する行動。 -
IT（情報システム）
情報システムのあるべき姿を実現するための
戦略策定と実行に必要となる組織能力。
-
-
EDMモデル
- 対象 : ITの企画 / 開発 / 保守 / 運用のマネジメントとプロセス
- 経営陣の行動 : E（Evaluate : 評価）、D（Direct : 指示）、M（Monitor : 監視）
-
原則
-
責任
役割に責任を負う人は、役割の遂行に必要な権限を持つ。 -
戦略
現在、将来の能力を考慮して策定し、ニーズを満たす必要がある。 -
取得
効果、リスク、資源バランスの取れた意思決定に基づく必要がある。 -
パフォーマンス
戦略と同様。こちらは、機能面ではなく性能面。 -
適合
関連するすべての法規 / 法律に適合する必要がある。 -
人間行動
パフォーマンスの維持に関わる人間の行動を尊重。
-
-
留意事項
-
ITガバナンス
-
フェーズ
- 企画
- 開発
- 運用・利用
- 保守
-
アジャイル開発
-
管理
- 外部サービス
- 事業継続管理
- 人的資源管理
- ドキュメント管理
-
リスクの計画、特定、分析、評価、実行＆監視・制御のスコープ
- ISO/IEC 31000 : 2018, JIS 31000 : 2010
PDCAによる継続的改善のフレームワーク
リスクの特定、分析、評価のスコープ
- ISO/IEC 31010 : 2009, JIS 31010 : 2012
リスク・アセスメントの体系的技法の
選択及び適用に関する手引きを提供する。
リスク・アセスメント中の分析・評価の手法。
日本の一般財団法人JIPDECが開発した
リスク分析手法、リスクマネジメントシステム
-
JRAM : JIPDEC Risk Analysis Method 2002
リスク分析手法 -
JRMS2010 : JIPDEC Risk Management System
リスクマネジメントシステム
1992に発行、ISO31000:2009を取り入れ、
成熟度モデル、ギャップ分析の手法を導入。
- CRAMM：CCTA Risk Analysis Management Methodology
- 英国のCCTAが開発したリスク分析手法＆リスクマネジメント・システム
移行メモ
- 「セキュリティ対策瀬品の購入費用」→「セキュリティ対策製品の購入費用」に正した。
- 「詳細リスク分析」は、元 Wiki では「メリット」に 「特別なスキルが必要」「時間やコストが必要」、 「デメリット」に「詳細な分析になる」「抜けや偏りがない」「客観的な評価が可能」と 逆に置かれていたため、見出しを「コスト」「効果」に改めた。
- 「各種明確化」で「情報資産」が 4 回繰り返されていたため 1 つに整理した。
- iDC の比較表の項番が「10」の行が 4 つ続いていたため、10 - 13 に振り直した。 あわせて「消化設備」→「消火設備」に正した。
- 元 Wiki の「概要」は、以降の各章と同じ見出しをリンクとして並べた目次であり、 そのままでは GitHub Wiki でアンカが全て衝突するため、 本文（箇条書き）に組み替えた。
- 同名の見出しが多数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした （「目的（リスク・アセスメント）」「目的（システム監査）」 「リスク・アセスメント（用語）」「リスク対応（用語）」 「情報資産の洗出（リスク分析の手順）」「情報資産の洗出（情報資産管理）」 「ISMSの要求事項（組織体制）」「ISMSの要求（情報資産管理）」 「ISMSの要求（環境的・物理的）」「ISMSの要求（人的）」 「ISMSの要求（インシデント管理）」「ISMSの要求事項（事業継続管理）」 「CSIRT（組織体制）」「CSIRT（インシデント管理）」 「管理（クライアントPC）」「セキュリティ対策（クライアントPC）」 「効果（セキュリティ・ポリシ）」「効果（情報セキュリティ監査）」 「BCM の要点」「BCP の要点」 「リスク・アセスメント（規格）」「リスク分析評価手法（規格）」など）。 なお、元 Wiki では「リスク分析評価手法」の 2 箇所が 同一のアンカ（
#r5212fb6）を持っていた。- 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所 （「構成要素」「脅威の洗出」「脆弱性の洗出」「組織体制」 「ITILでのインシデント・マネジメント」「マネジメント・システム」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
- 元 Wiki の結合セル（
>/~）を含む表は、GitHub Wiki では再現できないため、 ヘッダを 1 行に畳んで平坦な表にした（「リスクの大きさの評価」の定性の表）。&color(red){...};による強調は太字にした。- PukiWiki のページ内アンカ（
#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名の該当節を参照）」の形に置き換えた。- 未移行のページはファイル名を予約し、TODO.md に記録した。
Tags: 移行, 資格, SC, マネジメント, リスク・アセスメント, リスク対応, セキュリティ・ポリシ, CISO, CSIRT, SOC, 情報資産管理, BCM, BCP, 情報セキュリティ監査, システム監査, ISO 31000
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。