セキュリティ施策として話題になるのは、複雑さを満すパスワードとか、多要素認証とか、ゼロトラストとか「手法」がクローズアップされることが多いのですが、セキュリティの本質はそこではなかったりします。
「なんとなく今時のセキュリティ施策をしたので、なんとなく安全になった気がする」では、本当に安全になっているかの確信が持てませんし、抜け道とか大穴が残っていたとしても、それを認識することが出来ません。
ここで改めてセキュリティの考え方を整理してみます。
つかみどころが無いように思われがちなセキュリティなのですが、実は考え方にセオリーがあったりします。
・守るべき対象の把握
・セキュリティ侵害のダメージ見立て
・リスク想定
・リスク発生の頻度見立て
・リスク評価と対策目標の策定
・リスク対策の考案と、リスク対策後のリスク再評価
・セキュリティ施策をどう維持管理をするのか
そもそも、守るべき対象が何なのかがあやふやでは、どうやって守るかの施策を的確に考えることはできません。
セキュリティを考える第一歩は、「守るべき対象を把握する」ことから始まります。
では、守るべき対象とは何なのか。
大きく分けて以下に分類することが出来ます。
| ・情報資産 ・アカウント ・エンドポイント ・インフラ/ネットワーク ・システム |
一番多いのがこの情報資産ですね。
業務上作成するドキュメントであったり、外部から収集した情報であったり...
一般的なドキュメントだけではなく、メールとかも情報資産の仲間です。
部署別にどのような情報資産があるのか、各部署に棚卸してもらうのが手っ取り早く情報資産を把握する手段です。
紙とかの物理媒体は ICT 施策では守ることが出来ないので、あくまで電子媒体になっている物を対象にするのがミソです。
ICT 特有のものですね。
守るべき対象はパスワードなどの「資格情報」です。
アカウントの種類は、以下のものがあります。
| 一般利用者アカウント | 利用者が使うアカウント |
| 業務管理者アカウント | 経理システム等のサービス内の業務管理者アカウント |
| システムアカウント/サービスアカウント | システムやサービスが内部的に使用するアカウント |
| システム開発/運用者が開発/運用業務に使用するアカウント | システムの開発/運用に使用する特別な権限を持ったアカウント 経理システム等のサービスそのものの設定変更ができる特権を持つ管理アカウント |
| インフラ管理アカウント | Server OS のアカウント ネットワーク機器やセキュリティ機器の管理アカウント Azure/AWS 等のクラウドそのもののアカウント |
業務で使用している Windows PC や Mac や、iPhone Android 等のスマートデバイスなど、日常的に使用するデバイスが守るべき対象になります。
エンドポイントはハードウェアや OS だけではなく、イントールされているアプリケーションも守るべき対象として捉える必要があります。
USB メモリーやデジタルカメラなどの「入れ物」もエンドポイントして捉えるののも良いアイディアですが、中に入っている写真やファイル情報資産として守るように考えるのが妥当です。
利用者視線ではあまり馴染みが無いものですが、システム的にとらえた時にはネットワーク、サーバー、クラウドサービス等のインフラも守るべき対象として捉える必要があります。
業務システムを構築したり、業務システムを利用している場合は、これらも守るべき対象になります。
外部に対して SaaS 等を提供している場合も同様に守るべき対象して捉える必要があります。
セキュリティの三大要素といえば、機密性、完全性、可用性ですね。
| 機密性(confidentiality) | 権限を持たない人に対して、情報を利用できないようにすること |
| 完全性(integrity) | 権限を持たない人によって書き換えられたリ、消されたりしないようにすること |
| 可用性(availability) | 利用したいときに利用できるようにすること |
これらの三大要素の頭文字をとって 「CIA」と略称で呼ぶこともあります。
セキュリティが侵害された状態とは、この三大要素が満たされなくなった状態を言います。
守るべき対象に対し、セキュリティ侵害が起きた時のダメージを見積ります。
見積もるのは、以下の5段階で見積もるのですが、「致命的」といっても具体性が無いので、まずは、それぞれのダメージレベルで具体的な基準を決めていきます。
例えば、「致命的」とは「事業の存続が出来なくなるダメージ」といった具合です。
| 致命的:4 |
| 重大:3 |
| 中程度:2 |
| 軽微:1 |
| 無傷:0 |
それぞれの守るべき対象に対し、セキュリティ侵害が起きた時のダメージを見積っていきます。
ダメージは想定出来たので、今度は守るべき対象がどのようなリスクにさらされているかを見極めます。
ふわっとリスクを考えても、網羅的にリスクを拾い上げるのは難しいので、守るべき対象のライフサイクル別にリスクを想定します。
例えば、エンドポイントであれば「購入」「配布」「利用」「回収保管」「廃棄」のライフサイクルがあります。
| 購入 | 業務に使用する端末を選定し、購入する |
| 配布 | 利用者が端末を使用できるように準備し配布する |
| 利用 | 利用者が端末を利用し業務を遂行する |
| 回収保管 | 使用されなくなった端末を回収し、次の配布に備え保管する |
| 廃棄 | 使用されなくなった端末を廃棄する |
それぞれのライフサイクルに対し、セキュリティ三大要素である「機密性」「完全性」「可用性」が侵害されるリスクにはどのようなものがあるのかを想定します。
例えば、「購入」時の想定リスクは
機密性
機密性侵害対策可能なデバイスが選定できていない。
完全性
該当なし
可用性
該当なし。
こんな感じですね。
リスクの想定が出来たら、そのリスクがどのくらいの頻度で起きえるのかを見積ります。
ダメージの見積もりと同様に状態の定義をまずすることから始めます。
例えば「頻繁」は「いつ起きてもおかしくない」といった具合です。
頻度の定義が手来たら、先程想定したリスク別に、どの程度の頻度でそのリスクが現実化するのかを見積っていきます。
| 頻繁:5 |
| しばしば:4 |
| 時々:3 |
| 起こりそうにない:2 |
| まず起きえない:1 |
| 考えられない:0 |
リスクアセスメントの知識がある方であれば「R-Map」手法を使おうとしているのにお気づきでしょう。
R-Map はリスクを 「ダメージ x 頻度」表形式にしてリスク評価をするのですが、僕は表形式ではなく数値化して評価する手法をよく使います。
| リスク評価値 ＝ ビジネスダメージ × リスク発生頻度 |
全てのリスクに対してリスク対策するのは、時間やコスト的に現実的ではありません。
優先度をつけてヤバいリスクから対処をするのが現実的です。
「致命的」で「頻繁」に起こりうるリスクは最優先で対処しなくてはいけないリスクです。
リスク評価値を出すことで、リスク対策を検討するリスクを評価値の閾値で判断できます。
以下の閾値を決めます。
| ・リスク対策をする閾値 ・リスク対策後の目標値 |
優先度の高いリスクからリスク対策を考えます。
リスクを下げるのは、「ダメージを下げる」「頻度を下げる」の2軸の対策が考えられます。
つまり「致命的」なダメージ引き起こすリスクであっても「考えられない」の頻度まで引き下げることが出来れば、5 x 0 = 0 なので、リスク対策は大成功です。
具体的なリスク対策を考えるのが、日頃良く目にするゼロトラストや多要素認証といった「セキュリティ手法」の話にやっとなってきました。
大切なのは、リスク対策をした後のリスク再評価です。再評価した結果が目標に達していないのであれば、目標を達成するようにさらにリスク対策考えます。
リスク対策をする事によって、別のリスクが発生する事もあるので、再評価はとても大切です。
リスクによっては、どう頑張っても目標値がクリアできないリスクが出てくることがあります。
その場合は、攻撃者の経済効果を考え、攻撃には成功するが経済的効果が得られないリスクであるかを判断します。
昨今の攻撃は、ビジネス化しており、攻撃に必要なコストが利益を上回る場合、つまり攻撃者から見て「割が合わない」状態にすれば攻撃される可能性は大幅に下げることが出来ます。
業務効率を考慮した場合、どうしても目標値をクリアすることが出来ないリスクの場合は、経営判断として「業務効率のためにリスクを容認する」決断が必要になります。
この選択をする場合、セキュリティ侵害をいち早く検出する仕組みと、どのような攻撃があったのかを後追い調査できる仕組みの導入が必要になります。
リスク評価とリスク対策が出来たからと言って終わりではありません。
リスクは状況に応じて刻々と変化するので、リスク評価は継続的に実施する必要があります。
セキュリティ規定を明文化し、組織全体の共通認識として言語化しておく必要もあります。
セキュリティを維持する体制も必要になってきます。
このような「規定」「体制」を整備し、維持進化させる仕組みを作る必要があります。
セキュリティ インシデントが発生した時ま対応も決めておく必要もあります。
もちろん、セキュリティ施策の導入/運用の計画と、コストも計画的に予算化する必要があります。
Copyright © MURA All rights reserved.