リスクアセスメント(RA)と内部監査(CA)

本連載において、NIST Cyber Security Framework(CSF)及びSP800-53を解説し、サイバーセキュリティのセグメントの全容を示すにあたり、リスクアセスメント(RA)と内部監査(CA)は、始まり(リスクの認知)と終わり(対策実装の評価/監視)を示す重要なファミリーであると言える。
SP800-37 Risk Management Framework(RMF)を例に取れば、リスクマネジメントとは以下の流れで表現されており、「セキュリティ分類、アセスメント」がリスクアセスメント(RA)、「認可、監視」が内部監査(CA)なのである。
- セキュリティ分類(CATEGORIZE)
- 管理策選択(SELECT)
- インプリ(IMPLEMENT)
- アセスメント(ASSESS)
- 認可(AUTHORIZE)
- 監視(MONITOR)
したがって、NIST SP800シリーズを用いたサイバー対策実装において、ステップを理解する上でも重要であるリスクアセスメント(RA)、内部監査(CA)に関する解説を実施する。

リスクアセスメント:セキュリティ分類
前述のRMFの手順からも読み取れるが、一般的に組織がセキュリティの向上を図るためには、まず各システムをどの程度のセキュリティレベルに設定するかを決定する必要がある。闇雲に一定のセキュリティ水準を全システムに適応すれば、無理にコストが肥大化し、結局のところセキュリティがコストセンターと化すことは目に見えている。したがって、リスクアセスメントの第一歩目は、「各システムが処理・格納・通信している情報を機密性・完全性・可用性から重要度別に分類すること」である。少々ややこしい文言が並んだため、それぞれ解説を実施する。
処理・格納・通信
まず「処理・格納・通信」という3つのアクションについては、NISTを理解するにあたり何度も出現する考え方なのでぜひ覚えていただきたい。
1.処理
「処理」とは、情報を読み取ったり加工したりすることを指す。例えば、DBから情報を読み取って出力したり、それらの情報を例えばエクセルなどで加工したりすることを指す。
2.格納
「格納」とは、当該の情報をDBやフォルダなどに格納することを指す。要するに恒常的に当該情報を保管するか否かということで考えれば良い。
3.通信
「通信」とは当該情報を別のシステムに転送したり、受け取ったりすることを指す。
この3つのアクションのいずれかを当該情報に対して実施しているかで、該当するシステムを選別できるというわけである。無論大まかに「当該情報を扱っているか」という言葉で片付けてしまっても特段大きな問題にはならないが、時々この基礎知識の有無が理解度に影響するため、習得を推奨する。
機密性・完全性・可用性
次に「機密性・完全性・可用性」という言葉についてであるが、幾分かこちらの方が一般的に理解が進んでいると思慮する。
1.機密性
「機密性」とは情報が外部に漏れないことを指す。
2.完全性
「完全性」とは情報が改ざん/削除されないことを指す。
3.可用性
「可用性」とは情報が使える状態にある(システムが正常に稼働しており取り出し可能な状態)ことを指す。
この3つの軸から情報の重要度を算出せよというのが後半の意味合いとなる。改めて「各システムが処理・格納・通信している情報を機密性・完全性・可用性から重要度別に分類すること」という文章を見てみよう。
つまり私が記したのは、「各システムがどのような情報を扱っているかを明らかにし、それらの情報が漏洩、改ざん/削除、使えない状況に至った時に、如何程に経営に影響があるかを軸にシステムを分類しなさい」ということである。
リスクアセスメント:情報のクライテリアの設定
前述のような分類をする際には「どのような情報がどの程度会社にとって重要な情報なのか」という定義をする必要がある。つまり、社内で扱っている情報に対してクライテリア(指標)を設定するということである。一般的に「秘密、グループ外秘、社外秘、極秘」などのクライテリアを設ける会社が多いが、ここではあくまでセキュリティを軸にした分類方法を考えてみよう。もっとも、前述したような社内の情報のクライテリアがすでに存在する場合には、それらを踏襲する形で分類に役立てても良い。
セキュリティ軸で考えるにあたっては前述した通り「それらの情報が漏洩、改ざん/削除、使えない状況に至った時に、如何程に経営に影響があるか」を考える必要がある。更に、経営上のリスクというのを考えるとき、「金銭的なビジネスリスク」と「レピュテーション/コンプライアンス的なビジネスリスク」の2つを大きく考えてみてほしい。「この情報が漏洩した場合社会的信用は地に落ちるだろう(機密性)」「この情報がランサムウェアにロックされたら生産ラインが止まって大打撃となる(完全性/可用性)」などが例となる。
こうした思考の結果、ある一定のリスクレベルを超える情報は保護対象情報として選出しクライテリアを作成するのである。できればこの時、重要度のレベルを「高・中・低」くらいの三段階程度に分類しておくことで、セキュリティ対策の緩急をつけることができ、コストの削減にもつながる。しかしこの工程も特に大企業の場合は情報の棚卸しをやるだけでも一苦労なので、藪から棒にやるのではなくて、定義から先に作ってしまって、当てはまる情報を部門ごとに整理して出してもらうというのも手である。このとき、「機密性・完全性・可用性」の中で序列は存在するのかと問われることが多いが、定義自体に序列は存在しないというのが回答である。ただし、個人情報を取り扱うシステムでは機密性、決済などを行うようなシステムでは完全性、製造業の生産ラインに関わるシステムであれば可用性が重視されるのは明白であり、つまるところシステムや事業特性により重み付けを変えても良いということである。このとき重要なのは、無理をしすぎないということである。定義を広げれば広げるほど、後の工程にかかるコストも指数関数的に増加する。できればいくつかの案(松竹梅)を出しておいて、後の工程であまりにも範囲が広がったときに、対象を絞り込むための材料にすることが好ましい。
このようにして、セキュリティ対策により「守るべき対象情報」を明確にするのである。
リスクアセスメント:システムの分類
前述した情報のクライテリアが確かになったら、それらの情報を「処理・格納・通信」しているシステムを洗い出すことで、「守るべき対象情報を処理・格納・通信しているシステム」≒「守るべき対象システム」を導き出すことができるのである。このとき、一般的にはなるべく守るべき対象情報が局所的に存在している方がセキュリティ対策が容易であるという考え方ができる。100個のシステムに「守るべき対象情報」が存在しているよりも、33つのシステムに集約されている方が楽に決まっている。また、後々の連載の中で、Authorization Boundaryという概念を紹介する予定であるが、ネットワークの観点も重要である。守るべき対象情報を扱っているシステムと、同一ネットワーク上にあるシステムについてどう考えるべきかという問題である。このテーマに切り込むと簡単に一冊の本が出版できてしまうため、後の連載に期待されたい。
本記事では兎に角、守るべき対象情報を扱っているシステムを特定せよということである。このようにシステムにタグ付けをしていくと、どこでどのような情報を扱っているかを可視化することができる。
要するに、扱っている情報を軸として、各システムが内包するリスクレベルを算定することができるのである。このようにして優先してセキュリティ対策を実施すべき対象システムを絞り出すことができる。
リスクアセスメント:脆弱性評価
前述した、取り扱っている情報を軸としたシステムのリスク評価に加えて、内包している脆弱性の評価もリスクアセスメント(RA)ファミリーの重要な要素である。先ほど取り扱い情報を軸に選定したシステム群に対して、脆弱性の度合いを評価する。脆弱性の度合いとは、例えば「重要度の高い情報を扱っているものの、当該システムは専用線で接続されており、容易には外部からのサイバー攻撃に晒されない」など、サイバー攻撃に対してどれほど弱いのかという度合いを図るということである。
また、「実際に悪用可能なシステムの脆弱性は如何程に残存しているか」というのも重要な観点である。私はこの手の脆弱性評価の専門家であるため、本来であればここにその手法や考え方を列挙すべきであるが、あまりに専門的かつ膨大な列挙となり、読者層にそぐわないと判断する。
つまりこの脆弱性評価こそ、外部ツールや外部業者に頼らなければならないステップであると言える。脆弱性評価のコストを圧縮してセキュリティ製品を購入したとしても適当な効果が得られるとは到底思えないのである。それは、冒頭に記した通り、このリスクアセスメントこそがすべての始まりであるからである。
最低限私から伝えたいことは、中小企業であれば無料でも良いので「脆弱性診断」を受けることと、ある程度の規模の会社なのであれば、脆弱性診断に加えて「侵入テスト」も受けておくことを強く推奨する。
つまりこういうことだ。精密検査を受けて自分の健康状態を把握したうえで生活習慣病や既存の病に対応するのか、自覚症状が出始めてから後発的に対処をし、それまでは効くかどうかも分からない流行りの健康法に身を委ねるか。当然前者がまともな考え方であるということがわかるだろうし、定期診断が重要なこともご理解頂けるだろう。ここまでの、セキュリティ分類、システム分類、脆弱性評価がNIST CSFで言うところの特定の最大のポイントなのである。
管理策選定とインプリ
本来管理策の選定とインプリについてはRMFの解説となるためコラム的な位置づけとなることを前置きする。
前述の通り、「情報のクライテリアを設定」「対象システムの選定」「各システムの脆弱性把握」を実施した後に、「管理策の選定」というステップに移る。「情報のクライテリアを設定」「対象システムの選定」が対象範囲の選定に使用する指標で、「各システムの脆弱性把握」は「どのシステムにどのような対策実装が必要か」を選定する指標なのである。従って、検出された脆弱性やシステム特性などを加味しながら1000個以上あるSP800-53の管理策から適当なものを選出するのである。
しかしそんなことを全ての会社ができるはずはないため、予算に余裕がある、ある程度の規模の会社においては、外部専門家を使うことを推奨する。そのような予算がない企業においては、SP800-53を民間企業向けにサブセット化したSP800-171を参考にしていただきたい。かなり管理策が絞られているため参考になるはずである。ただし、SP800-171とて、かなり厳格に作られているため、その全てを実装するのは至難の業である。ついては、このSP800-171から更に自社が今無理なくできる範囲はどこかということを見つけていくのが実質的な管理策選定となる。このようにして選出された管理策と前段で発見された脆弱性に対して実際に対応/実装していくのかインプリのフェーズである。(本記事では割愛する)
内部監査(CA)(Certification and Accreditation)
内部監査(CA)では、選定された管理策が適切に実装されているかを評価する。この時、内部不正に繋がらないためにもできれば当該システムの利害関係者ではないメンバーによる監査を実施することが望ましい。
評価の結果、実装が完了していると見なされたシステムについては認可が与えられるが、実装が完了していないシステムについては、完了計画を作成させ、完了するまでの間、何らかの対処(緩和策)をとることで一定のリスクレベルを下回るかを評価する必要がある。どの程度の状態であれば当該システムを稼働し続けてもよいかという判断をする必要があるわけであるが、中小企業であれば稼働させなければ明日の飯は無いわけであるから、なるべく早く対策実装を終えるための計画が重要になってくる。
この評価/認可フェーズの後に、認可されたシステムと計画を提出して対策中のシステム双方に対して監視フェーズが存在する。前述の定期診断に近い考え方であり、準拠状況が維持されているか、新たな脆弱性が発生していないかなどを監視する。
多くの企業の場合半年に一回の定期監査を実施している。セキュリティレベルの高い企業であれば、ログなどの情報からリアルタイムで準拠状況を監視していることもある。認可されていないシステムについては計画の進捗などもここで監視を行う。
最後に
本記事ではリスクアセスメント(RA)と内部監査(CA)について記載した。また、企業がセキュリティ対策を考えるにあたり重要な基盤となるRMFについての解説も行った。
基本的にはRMFの手続きに則り、リスクアセスメントを実施し、管理策選定をして、内部監査に遷移するのが王道であるが、決してこの型にはまる必要はない。ポイントは「無理をしないこと」である。過度な目標設定は長期的なセキュリティ水準を下げる要因となるため、まずは目先の脆弱性への対策を着実に実施することが望ましいと考える。
ただし、絶対に妥協してはいけない部分がある。それはリスクアセスメントの脆弱性診断である。文中でも触れたが、このステップは極めて重要であるが、専門的でもある。従って、外部業者の手を借りることを強く推奨する。まずは無料診断でもよいので、ぜひ検討されたい。
執筆者
