コンサル抜きでも可能
簡単に導入できるリスク評価フレームワーク
自社の情報資産を保護するためには、何らかのリスク評価を実施するべきだ。中堅企業向けの簡易版リスク評価プロセスを紹介する。
リスク評価それ自体はもちろんのこと、リスク評価フレームワークのコンセプトでさえも中堅企業にとっては不要だと思っているかもしれない。しかしリスクを評価するというコンセプトは、あらゆる規模の企業にとってITセキュリティの核となるものだ。自社の情報資産を保護することに関心を抱いている中堅企業(言い換えればあらゆる中堅企業)は、何らかのリスク評価を実施する必要がある。たとえそれが、少人数のスタッフ向けに作成された簡易型フレームワークだとしてもだ。
うれしいことに、リスク評価フレームワークは無料だ。Webから容易にダウンロードし、自由に印刷して検討できる。これらは難解な文書で、コンサルタントの助けを借りなければリスク評価フレームワークを導入できないと思うかもしれないが、実際には必ずしもそうではない。どれほど複雑なフレームワークであっても、中堅企業が導入できる形に簡素化するためのベストプラクティスが存在するからだ。
リスク評価の目標は、ITインフラの各要素におけるITセキュリティリスクに優先順位を付けることだ。リスクの優先順位がなければ、企業は最大のリスクに対するコントロールに必要な予算を効果的に割り振ることができない。その結果、過大なコントロールや不必要なコントロールに費用を掛け過ぎたり、それとは逆に、悪質な攻撃にさらされているシステムを放置するといったことになってしまうのだ。予算に制約がある中堅企業にとって最大の問題はコストだ。経営幹部にとって高価に思えたり、難解に感じられたりするセキュリティシステムの場合は、なおさらそうだ。
また、リスクの優先順位付けを行うことにより、不正利用や攻撃のリスクが低いシステムはどれかを特定して過度のセキュリティ対策を避ける一方で、高いリスクにさらされ、強力な防御を必要とするシステムを特定できる。リスク評価フレームワークは何種類か存在するが、業界ベンチマークはNIST(米国立標準技術研究所)から提供されている。
NISTが発行している「Special Publication 800-100, Information Security Handbook: A Guide for Managers」には、リスク評価プロセスにおける4つのステップが示されている。SP800-100を基本とした中堅企業向けの簡易版リスク評価プロセスを以下に記す。
自分自身を知る
最初のステップはすべてのIT資産のインベントリーを作成し、分類することだ。2番目のステップは脅威を特定すること、3番目のステップは脅威に対応する脆弱性を特定することだ。最後のステップは実際のリスク分析であり、
- IT資産に対するセキュリティコントロールの評価
- 攻撃の可能性とその影響度の判定
- リスクレベルの決定
という作業が含まれる。評価の完了後、推奨されるコントロールを示した報告書を作成する必要がある。リスク評価は、定期的な見直しと実施が必要とされる繰り返しプロセスだと考えるべきだ。
IT資産のインベントリーは、リスク評価の範囲を規定するものとなる。企業がセキュリティコントロールを実施する前に、自社がどんな資産を保有しており、どのようなコントロールを既に実施しているのかを把握する必要がある。インベントリーには、すべてのハードウェア、ソフトウェア、データ、プロセス、外部システムとのインタフェースのリストが含まれていなければならない。
次のステップは脅威を特定することだ。これには、自然災害や停電といった物理的脅威も含まれるが、もちろんシステムへの不正アクセスやマルウェアによる攻撃といったITセキュリティに対する脅威も含めなくてはならない。創造性を発揮する必要もある。自分の経験、そしてカーネギーメロン大学のUS Computer Emergency Response Team(US-CERT)などから発行されているセキュリティ情報に基づき、自社のシステムに対して最も可能性の高い脅威は何かを考えることが大切だ。
脅威は単独で存在するわけではない。システムに脆弱性があるからこそ、脅威になる。この脆弱性を特定することが3つ目のステップだ。この場合も、NISTが貴重なリソースとなる。NISTのNational Vulnerability Database(NVD)には、現在の脅威のリストと以前の脅威のアーカイブが収められている。NVDのほかにも、ハードウェア/ソフトウェアベンダーのWebサイトにある脆弱性のリストもチェックすること。ハッキングの掲示板などのソースも、脆弱性を把握する上で大いに参考になる。
システムのセキュリティテストやスキャニング(脆弱性テストや侵入テストなど)も、脆弱性を把握するのに役立つ。
これらのデータを収集したら、最後のステップは実際のリスク分析だ。この作業には3つの段階がある。
- 既存のセキュリティコントロールの評価
- これらのコントロールに基づいた、攻撃の可能性と影響度の判定
- リスクレベルの決定
だ。攻撃の可能性と影響度は、それぞれ高、中、低の3段階に分類できる。各リスクレベルに点数(例えば0~10)を割り当てた上で、攻撃の影響度を横軸、可能性を縦軸とする3×3のマトリクスに記入する。
この組み合わせによって得られるリスクスコアを最終報告書に記載する。この報告書では、リスクレベルを低くする、すなわち自社が許容できる程度にまで下げるには、どのようなセキュリティコントロールを実施すべきかについて説明する。セキュリティ対策のコストの理由を説明するのにも、この報告書が役立つ。例えば、「高いリスクレベルは、潜在的な攻撃が差し迫っており、セキュリティコントロールを直ちに実施する必要性を意味する」といった説明を付ければよい。
本稿で示した簡易版リスク評価プロセスはNISTのガイドラインをベースとしたものだが、そのほかのフレームワークも、IT資産、脅威、脆弱性を特定した上で、収集したデータに基づいてリスクレベルを決定するという基本的なプロセスはほぼ同じだ。こういったフレームワークとしては、CERTのOCTAVE(Operationally Critical Threat, Asset, and Vulnerability Evaluation)やInformation Systems Audit and Control AssociationのCOBIT(Control Objectives for Information and related Technology)などがある。
どのようなフレームワークを選んでも、リスク評価は中堅企業にとって巨大なプロジェクトのように感じられるかもしれない。リスク評価にスタッフや時間を注ぎ込む余裕がないという企業もあるだろう。しかし小規模な企業では、リスク評価の実施にスタッフがかかりきりになる必要はない。1人のITスタッフが定期的に(例えば年に一度)、あるいは大幅なシステム変更(企業買収やITシステムの刷新など)の際に実施するだけで対応できることもある。
リスク評価の実施に必要な時間を短縮するもう1つの方法は、範囲を限定することだ。例えば、多くの中堅企業は社内でアプリケーションを開発しているわけではない。つまり、評価対象が1つ少なくて済むということだ。大抵の中堅企業にとっての関心事、すなわち、アクセス管理、ネットワークセキュリティ、物理的セキュリティ、Webサイトのセキュリティをリスク評価の基本項目とすればいいのだ。
リスクの評価は、どのような情報セキュリティプログラムにも不可欠だ。本稿で紹介したステップが、中堅企業でのリスク評価プロセスの簡素化に役立つものと期待している。
本稿筆者のジョエル・デュビン氏はCISSP(公認情報システムセキュリティ専門家)資格を持つ独立系コンピュータセキュリティコンサルタント。 Microsoft MVPに選ばれ、Web/アプリケーションセキュリティを専門とする。著書に「The Little Black Book of Computer Security」(29th Street Press)があり、シカゴのラジオ局WIITでコンピュータセキュリティの番組を担当。「IT Security Guy」ブログも運営している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社フィックスターズ] 組み込み開発特有の課題も解消できる「AI活用」の秘訣とは? -
事例
[株式会社ビザスク] 「新規事業」事例集:大手企業はどのように想定顧客ヒアリングを行っているのか -
市場調査・トレンド
[株式会社ビザスク] 質の高い「仮説検証インタビュー」を実施するためのポイント -
事例
[株式会社ビザスク] 富士フイルムの新領域参入に学ぶ事業創出 「畑違い」でもビジネス化できる方法 -
事例
[株式会社ビザスク] 三菱電機 上席執行役員に学ぶ、未来を切り開く「新事業創出」の実践方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
4
IT製品の導入に関するアンケート「PC&デバイス」編
-
5
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
8
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
9
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
-
10
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
3
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
8
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー