このシリーズでは、ISMSに関する様々な取り組みを行う際に出てくるであろう「よくある疑問」について、回答していきたいと思います。

今回は、自社がどのような情報セキュリティ対策を行っていくか考えるために大切な取り組みである「リスクアセスメント」についてです。

リスクアセスメントのFAQ

そもそもリスクアセスメントってなに?

リスクの洗い出しから分析・評価までを行う一連の流れのことを指します。
リスクアセスメントは主に2つの観点からISMS上、重要な取り組みであると言えます。

1. ISMSそのものの目的に関わる

ISMSの土台でもある規格JIS Q 27001の概要において、ISMSの目的として「リスクを適切に管理しているという信頼を利害関係者に与えること」が挙げられています。

つまり、リスクアセスメントが行われないということは、この目的を達成するための手段を放棄していることになります。

2. リスクを把握・管理してはじめて組織に合った仕組み作りを行うことができる

ISMSは決まったルールを組織に適用させて終わりではなく、自組織に合った仕組みを作って有効的に運用していくことが目的です。
つまり、自組織のリスクを把握していなければどのような仕組みを作ればいいのかということが明確にできません。
結果として、本来対策する必要のない部分までガチガチに固めてしまい組織にとって重たい仕組みが完成するかもしれません。

その点、しっかりとリスクアセスメントを行うことで、重点的に対策すべきところには力を入れ、組織として軽量化をはかるべき部分は軽量化するといった対応を行っていくことができます。

洗い出すべきリスクは?

基本的には、ISMS適用範囲内で「機密性・完全性・可用性」の3つの観点から、発生したら困ることを洗い出します。例えば、以下のようなリスクが考えられます。

機密性
  • 大切な情報(個人情報や顧客情報など)が漏えいする
  • 業務データが入ったPCを紛失する
完全性
  • Webサイト上に掲載しているデータが誤っている
  • Webサイトの内容を改ざんされる
可用性
  • クラウドストレージにアクセスできず情報が利用できない
  • 提供しているサービスがシステム障害で利用できなくなる

ISMS上は上記のような観点からリスクを洗い出していただければ問題ありません。
ただ。その他に法律や契約などコンプライアンスの観点、一般的な業務継続に関わる観点など多様な視点から洗い出していただくことで、より自組織の置かれている立場やリスクを明確に把握・管理することができます。

基準として洗い出す必要のある数は?

答えは「決まりがない」です。
規格上求められていることは、リスクアセスメントや対応のルールを決め、実施した結果を管理することであり、いくつ以上どのようなリスクを洗い出しなさいということではありません。

ので極端に言うとリスクが0個でしたという結果も不正解ではありません。
ただ、何らかの事業活動を行っているのであれば、全くリスクがないということは基本ないでしょうし、リスクがないのではなく、リスクに対して何らかの対策を取っているからあまりリスクと感じていないだけかもしれません。

リスクアセスメントでは、まずリスクを認識し・把握することが大切です。
自組織にリスクがないのではと思った場合には、一般的なリスクが当てはまるか考えてみたり、同じような事業・業務を行う会社で起きたインシデント事例などから自社にも当てはまらないか考えてみると良いでしょう。
また、内部監査や外部審査も自分達では見えないリスクを改めて再認識する機会として活用することができます。

洗い出したリスクには全て対応する必要がある?

全てに対応する必要はありません。
リスクとはいえ、発生する可能性がそもそも低いものや、すでに様々な対策を取っているものにまで対応するのは効率が悪く、また、不要な負担が増えるだけです。

ただし、全てに対応する必要はありませんが、「洗い出した全てのリスクについて、対応が必要かどうか判断する」ことは行いましょう。
その上で、優先的に対応すべきリスクや、仕組みの構築や運用に合わせて対策できるものについて対応を行っていくことが好ましいです。

リスクの受容基準ってなに?

規格では、リスク受容基準を確立することが求められています。リスク受容基準とは言い換えると、どの程度のリスクであれば受け入れられるのかということであり、リスク受容基準を超えるものには何らかの対応を考えましょうということです。

このリスクの受容基準では、「発生可能性×影響度」といった形で計算式を設定し、一定の数値を受容基準として設定する場合が多いです。
そのため、数値でなければならないと思われる方もいるかと思いますがそうではありません。
ここでの受容基準とは、リスクを受容するための方法論の基準(どのようにして判断するかの基準)のことを指しており、数値に限らず何等かの形で受容のルールを定めていればいいということです。
なので例えば、「情報セキュリティ委員会で受容するか決める」というのもひとつの受容基準です。

ただ、属人化した基準にすると毎回の判断にばらつきが出る可能性が高いため、一般的には数値など共通認識で同じ答えが出せる基準を設定することが望まれます。

別部署で共通リスクがある場合、両方洗い出すべき?

例えばPCの紛失やメールの誤送信など、どの業務でも当てはまりそうなリスクの場合、各部署で別々に洗い出すべきなのか判断に困る方もいるのではないでしょうか。
この答えに対する回答として2つの選択肢があります。

1. 「共通リスク」かつ「対策も同じ」

この場合、「共通」といったシートを作成してひとつにまとめて管理する方が好ましいです。
理由としては、リスクに対して対策も同じであれば、影響度が変わることはあまり考えられないため、一つのリスクとして管理・対応した方が、より軽く運用することができます。

例えば、PCの紛失というリスクに対して全社的に「パスワードロック」「HDDの暗号化」をルール付けて行っているといったケースが挙げられます。

2. 「共通リスク」だけど「対策が異なる」or「影響が異なる」

この場合は、各部署のシートでリスクを管理する方が好ましいです。
理由としては、対策や影響が異なるリスクを一つにまとめて管理してしまうと、本来対策すべきところを見逃してしまう可能性があるためです。

例えば、メールの誤送信というリスクに対して、営業部ではダブルチェックや送信保留機能を導入しているが、管理部では特に何もしていないというケースの場合、発生可能性や発生時の影響が大きく異なる可能性があります。
また、このリスクを一緒に管理してしまうと、本来管理部で何らかの対策をすべきであっても、全体としては対応策がとられているということで重大なリスクを見逃してしまうかもしれません。

リスク所有者は誰?

リスク所有者とは、「それぞれのリスクの運用管理に対して、説明責任や権限を持つ人」のことです。
そして、ISMSではリスクの洗い出しに加えてそのリスクのリスク所有者を決めることが求められています。

一般的には各部署の部長などの責任者がその部署のリスク所有者と考えることができるでしょう。
ただし、そうではないケースも少なからず存在しています。
その理由は、リスク所有者が持つもう一つの役割である「リスク対応計画や残留したリスクの受容について承認をする」ということにあります。

規格上、リスク所有者はリスクの対応計画やそれらを検討したうえで残ったリスクを受け入れることを承認することが求められています。
この観点から、現実的には情報セキュリティ管理者などISMS全体を統括する人が、リスク管理全体を統括するという意味合いも込めて一括してリスク所有者となるケースが多いです。

まとめ

今回は、「リスクアセスメント」のよくある質問について、回答してきました。
少しでも取り組みの参考にしていただけると幸いです。

弊社コンサルティングでは、リスクアセスメントをはじめ、ISMS取得・運用に関する支援をさせていただいております。
また、弊社サービスSeculioの「セキュリティチェック機能」という自社のセキュリティ対策度合いや、できていない場合の対応策を知ることのできる機能及び、「リスクマネジメント機能」というリスク管理や対策計画の管理を行うことのできる機能を提供しておりますので、ご興味があればぜひお気軽にお問い合わせください。

シリーズFAQ【リスクアセスメント】

このシリーズでは、ISMSに関する様々な取り組みを行う際に出てくるであろう「よくある疑問」について、回答していきたいと思います。

今回は、自社がどのような情報セキュリティ対策を行っていくか考えるために大切な取り組みである「リスクアセスメント」についてです。

リスクアセスメントのFAQ

そもそもリスクアセスメントってなに?

リスクの洗い出しから分析・評価までを行う一連の流れのことを指します。
リスクアセスメントは主に2つの観点からISMS上、重要な取り組みであると言えます。

1. ISMSそのものの目的に関わる

ISMSの土台でもある規格JIS Q 27001の概要において、ISMSの目的として「リスクを適切に管理しているという信頼を利害関係者に与えること」が挙げられています。

つまり、リスクアセスメントが行われないということは、この目的を達成するための手段を放棄していることになります。

2. リスクを把握・管理してはじめて組織に合った仕組み作りを行うことができる

ISMSは決まったルールを組織に適用させて終わりではなく、自組織に合った仕組みを作って有効的に運用していくことが目的です。
つまり、自組織のリスクを把握していなければどのような仕組みを作ればいいのかということが明確にできません。
結果として、本来対策する必要のない部分までガチガチに固めてしまい組織にとって重たい仕組みが完成するかもしれません。

その点、しっかりとリスクアセスメントを行うことで、重点的に対策すべきところには力を入れ、組織として軽量化をはかるべき部分は軽量化するといった対応を行っていくことができます。

洗い出すべきリスクは?

基本的には、ISMS適用範囲内で「機密性・完全性・可用性」の3つの観点から、発生したら困ることを洗い出します。例えば、以下のようなリスクが考えられます。

機密性
  • 大切な情報(個人情報や顧客情報など)が漏えいする
  • 業務データが入ったPCを紛失する
完全性
  • Webサイト上に掲載しているデータが誤っている
  • Webサイトの内容を改ざんされる
可用性
  • クラウドストレージにアクセスできず情報が利用できない
  • 提供しているサービスがシステム障害で利用できなくなる

ISMS上は上記のような観点からリスクを洗い出していただければ問題ありません。
ただ。その他に法律や契約などコンプライアンスの観点、一般的な業務継続に関わる観点など多様な視点から洗い出していただくことで、より自組織の置かれている立場やリスクを明確に把握・管理することができます。

基準として洗い出す必要のある数は?

答えは「決まりがない」です。
規格上求められていることは、リスクアセスメントや対応のルールを決め、実施した結果を管理することであり、いくつ以上どのようなリスクを洗い出しなさいということではありません。

ので極端に言うとリスクが0個でしたという結果も不正解ではありません。
ただ、何らかの事業活動を行っているのであれば、全くリスクがないということは基本ないでしょうし、リスクがないのではなく、リスクに対して何らかの対策を取っているからあまりリスクと感じていないだけかもしれません。

リスクアセスメントでは、まずリスクを認識し・把握することが大切です。
自組織にリスクがないのではと思った場合には、一般的なリスクが当てはまるか考えてみたり、同じような事業・業務を行う会社で起きたインシデント事例などから自社にも当てはまらないか考えてみると良いでしょう。
また、内部監査や外部審査も自分達では見えないリスクを改めて再認識する機会として活用することができます。

洗い出したリスクには全て対応する必要がある?

全てに対応する必要はありません。
リスクとはいえ、発生する可能性がそもそも低いものや、すでに様々な対策を取っているものにまで対応するのは効率が悪く、また、不要な負担が増えるだけです。

ただし、全てに対応する必要はありませんが、「洗い出した全てのリスクについて、対応が必要かどうか判断する」ことは行いましょう。
その上で、優先的に対応すべきリスクや、仕組みの構築や運用に合わせて対策できるものについて対応を行っていくことが好ましいです。

リスクの受容基準ってなに?

規格では、リスク受容基準を確立することが求められています。リスク受容基準とは言い換えると、どの程度のリスクであれば受け入れられるのかということであり、リスク受容基準を超えるものには何らかの対応を考えましょうということです。

このリスクの受容基準では、「発生可能性×影響度」といった形で計算式を設定し、一定の数値を受容基準として設定する場合が多いです。
そのため、数値でなければならないと思われる方もいるかと思いますがそうではありません。
ここでの受容基準とは、リスクを受容するための方法論の基準(どのようにして判断するかの基準)のことを指しており、数値に限らず何等かの形で受容のルールを定めていればいいということです。
なので例えば、「情報セキュリティ委員会で受容するか決める」というのもひとつの受容基準です。

ただ、属人化した基準にすると毎回の判断にばらつきが出る可能性が高いため、一般的には数値など共通認識で同じ答えが出せる基準を設定することが望まれます。

別部署で共通リスクがある場合、両方洗い出すべき?

例えばPCの紛失やメールの誤送信など、どの業務でも当てはまりそうなリスクの場合、各部署で別々に洗い出すべきなのか判断に困る方もいるのではないでしょうか。
この答えに対する回答として2つの選択肢があります。

1. 「共通リスク」かつ「対策も同じ」

この場合、「共通」といったシートを作成してひとつにまとめて管理する方が好ましいです。
理由としては、リスクに対して対策も同じであれば、影響度が変わることはあまり考えられないため、一つのリスクとして管理・対応した方が、より軽く運用することができます。

例えば、PCの紛失というリスクに対して全社的に「パスワードロック」「HDDの暗号化」をルール付けて行っているといったケースが挙げられます。

2. 「共通リスク」だけど「対策が異なる」or「影響が異なる」

この場合は、各部署のシートでリスクを管理する方が好ましいです。
理由としては、対策や影響が異なるリスクを一つにまとめて管理してしまうと、本来対策すべきところを見逃してしまう可能性があるためです。

例えば、メールの誤送信というリスクに対して、営業部ではダブルチェックや送信保留機能を導入しているが、管理部では特に何もしていないというケースの場合、発生可能性や発生時の影響が大きく異なる可能性があります。
また、このリスクを一緒に管理してしまうと、本来管理部で何らかの対策をすべきであっても、全体としては対応策がとられているということで重大なリスクを見逃してしまうかもしれません。

リスク所有者は誰?

リスク所有者とは、「それぞれのリスクの運用管理に対して、説明責任や権限を持つ人」のことです。
そして、ISMSではリスクの洗い出しに加えてそのリスクのリスク所有者を決めることが求められています。

一般的には各部署の部長などの責任者がその部署のリスク所有者と考えることができるでしょう。
ただし、そうではないケースも少なからず存在しています。
その理由は、リスク所有者が持つもう一つの役割である「リスク対応計画や残留したリスクの受容について承認をする」ということにあります。

規格上、リスク所有者はリスクの対応計画やそれらを検討したうえで残ったリスクを受け入れることを承認することが求められています。
この観点から、現実的には情報セキュリティ管理者などISMS全体を統括する人が、リスク管理全体を統括するという意味合いも込めて一括してリスク所有者となるケースが多いです。

まとめ

今回は、「リスクアセスメント」のよくある質問について、回答してきました。
少しでも取り組みの参考にしていただけると幸いです。

弊社コンサルティングでは、リスクアセスメントをはじめ、ISMS取得・運用に関する支援をさせていただいております。
また、弊社サービスSeculioの「セキュリティチェック機能」という自社のセキュリティ対策度合いや、できていない場合の対応策を知ることのできる機能及び、「リスクマネジメント機能」というリスク管理や対策計画の管理を行うことのできる機能を提供しておりますので、ご興味があればぜひお気軽にお問い合わせください。

Author: 石濱 雄基
  • はてなブックマークに追加
  • ツイートする
  • facebookでシェアする
  • LINEでシェアする