NISTに学ぶセキュリティのイロハ

NIST（National Institute of Standards and Technology）は米国の商務省配下の機関であり、様々な分野における技術的なスタンダードを発行、管理する機関である。2001年9月11日に発生した、いわゆる「9.11同時多発テロ事件」において、世界貿易センタービルが崩落した技術的な背景などを調査したのもNISTである。

私が身を置くサイバーセキュリティの業界においても、ITL（Information Technology Laboratory）が開発したCSF（Cyber Security Framework）は2014年の初版発行後、世界のスタンダードを牽引してきた。

本記事では、サイバーセキュリティにおける近代モデルの礎とも言えるCSFに基づいて、体系的に組織を守る、概念部分の捉え方を解説する。無論、本連載では今後、更に具体的な実装方法を示したSP800シリーズ、とりわけそれらを体系的にまとめたSP800-53についての詳細な解説も実施する予定である。

CSFはサイバーセキュリティを「特定」「防御」「検知」「対応」「復旧」 という5段階で表現している。

自組織のリソースとそれらに紐づく弱点（システムや業務プロセス上の脆弱性）を「特定」し、それらの穴を極力塞ぎ、攻撃者に侵入されないための「防御」策を講じる。この2つのファンクションは、つまるところ「いかに侵入されないか」ということに着目したものである。

初版が公開された2014年以前はここまでの対策で十分だと考えられてきたが、サイバー攻撃の高度化に対応するには「侵入されることを前提とした守り方」が求められるようになった。それが「検知」以降の世界である。

つまり、「防御」が破られ、侵入を許したことをいかに早く正確に「検知」し、感染端末やネットワークセグメントを隔離するなどの「対応」を行い、汚染されたシステムなどをセキュアに「復旧」するということである。侵入されないための防御策というのは、基本的には何らかの抜け穴を用いて突破されるということを前提とし、侵入されたときに、被害を最小限に抑える努力をする必要があるというのがCSFの示すところということだ。

前回の連載で詳しく触れたが、私はCSFにおいて最も重要なのは「特定」だと確信している。詳しくは前回の記事を参照していただきたいのだが、城の例えを私はよく使ってその理由を説明する。あなたは戦国時代を生きる、ある城の主だとして、その城をいかに守るかを考えるときに、まずすべきことはなんだろうか。高い城壁で城を囲む構想を練ることだろうか。それとも家来に対して不審者を見かけたら問答無用で切り捨てろと伝達することだろうか。ロジカルに物事を判断できる読者の皆様にあたっては、私と同じく「城の設計図等を用いた構造、重要な部屋へのアクセス経路、家来何人がどのようなルーティンで警備をしているかなどの現状把握」と答えるだろう。城を守るには、城に関することを完全に把握している必要があるのは当然のことである。そうでなければ、勝手口から寝室に侵入されたり、昼食に毒を盛られたり、反乱を企てる家来に襲撃を受けるかもしれないのである。

セキュリティとは多角的にあらゆる可能性を探索し、一つ一つにアプローチする綿密さが何よりも重要なのである。だからこそ、城に関する情報を徹底的に把握している必要があるのである。自社が保有する情報や機器、NW構成、業務フロー、情報フロー、アカウントの払い出し状況など、ありとあらゆる情報をセキュリティ部門は集約して管理できている必要がある。また、ここでのポイントは、できるだけリアルタイムにこれらを把握することが望ましいということである。CSFの導入を決意し、この記事を見たあなたが、1週間後に「特定」を実施してIT管理台帳や情報管理台帳を作ったとしよう。しかしその台帳を1年間更新しなければ、社内のIT環境は少なからず変化しているはずなのである。リアルタイムにコンポーネント管理をする方法というのは多々あるので、各々検索してみていただきたい。

また、「特定」にはもう一つ大切な要素が含まれる。それは脆弱性の特定である。「攻撃者が防御策を掻い潜ることを前提にせよ」と前述したが、それはある程度高度な攻撃を指している。きちんと「特定」「防御」ができていれば、特に中小企業にやってくるほとんどの攻撃はきちんと防ぐことができるだろう。その際最も重要なのが、自社が保有するリソースへの脆弱性検査である。特殊なツールを使う方法もあるが、今回は中小企業でもすぐに実践できる方法を紹介する。それはパッチマネジメントである。まず、自社が保有するソフトウェア、ハードウェアのコンポーネントリストを作成する。このとき、製品名とバージョン名（ハードウェアであればOSのバージョン）を必ず調査対象とする。このリストに対して、既知の脆弱性が無いかを確かめるためにCVE（Common Vulnerabilities and Exposures）という番号制度を使う。CVE Detailsというサイトが非常に使い勝手がよく、先程収集したリストを元に、製品名で検索をかけると、どのバージョンに脆弱性があるかを調べることができるのである。もしも使用している製品の同バージョンに脆弱性があれば、構成にもよるが、今すぐにでもその脆弱性を悪用してサイバー攻撃を受ける可能性があるかもしれない。この工程はパッチマネジメントを自動化できる製品なども存在しているため各々検索してみていただきたい。また、それも面倒だという場合には、バージョンが最新か否かで判断するのも悪くはない。また、業務プロセスについても同様で、中小企業によく見られるが、特定の人物がITシステムに多大なる権限を持っており、もしそのアカウントが乗っ取られたり、その人物が内部犯行に及んだ際には甚大な被害をもたらす状況にあるかもしれないということである。こういった部分にも最大限の注意を払ってセキュリティの観点から見直しが必要である。

「特定」で明らかになった脆弱性に対して、可能な限りの防御策を施すのが「防御」である。もちろん防御と一言に言っても数多のカテゴリーがある。CSFでは大きく以下に分類し、体系的な防御を語っている

絶え間なく新たな攻撃が生み出され続け、従来の防御を突破したものを研究し、防御策に昇華するということを業界としては繰り返しているわけなので、「攻撃者側が有利な立場である」ということと「最新の防御策を取り入れ続けなければならない」ということを何よりも認識すべきなのである。

とはいえ、すべてを「防御」でカバーする時代はすでに終焉しているわけなので、バランスよく投資することが重要なのである。ポイントはすべての攻撃を「防御」しようと考えていては、永遠に次のファンクションに進めないということである。本記事では細かく防御策に踏み入ることは控え、連載の中で触れることとする。

「防御」策がすべて突破されることも近年では全く珍しくなくなってきた。いざそうなった時に、まずは侵入されたことを「検知」できる必要がある。これはつまり、全社横断で取得されるログを分析し、正常系から逸脱するアノマリーをいかに正確に検出するかということだ。これには、「特定」のファンクションの出来栄えが関係してくる。自社のインフラや業務プロセスを「特定」し、その中の構造的脆弱性を把握出来たなら、「どこでどのようなログを取るべきか」ということが自ずと連想されるのである。また、この際頻度は当然リアルタイムとして、ログを取得する粒度が重要で、前の記事で書いた通り「なるべくユーザーID単位で記録する」ということが重要だ。ユーザーID単位で取得することで、ログを通じて、ユーザーの動きを継続的に監視することができ、現代のサイバーセキュリティの新たなる基礎概念となるに違いないゼロトラストを導入する際に役に立つ。何より、インシデントが発生した際に、被害範囲を当該ユーザーIDの権限単位で絞り込んだり、どこまでラテラルムーブメントされたかなどを探索することも容易になるのである。ここはむしろ中小企業のほうがことを進めやすいかもしれない。大企業であれば、様々な過去のしがらみから、オンプレシステム、レガシィシステムが存在しており、自分たちでログを取得する必要があるし、ネットワークやユーザー権限管理も複雑になるが、中小企業であればさほど難しいものではないだろう。主にSaaSを利用しているような場合には、エンドポイントくらいしか考えることが無いという場合もあるだろう。

このようにして「検知」した問題に対して、影響範囲の最小化に向けて「対応」を実施する。いわゆるインシデントレスポンスと思っていただいて結構である。インシデントを検知したならば、ログ分析などを通じて現状を詳しく把握し、解決に向けてマネジメント計画を立案する。多くの場合、被害範囲の特定、被害拡大の抑止、原因分析というのが大まかなステップである。近年ではインシデントを起こしたら、早い段階で監督官庁や取引先、親会社などへの報告義務を課しているところが多くなった。それはひとえに、世の中がサイバー攻撃に対して敏感になっているということであり、企業価値に直結するということを意味している。上場企業であればIR対応なども真剣かつ誠実に対応すべきである。間違ってもランサムウェアへ身代金を支払うなどという愚行をやってはいかんのである。

「対応」の最終段階として「復旧」が存在しており、明らかになった被害に対して、セキュアに「復旧」することを目指す。ここでは2つの意味が存在しており、それは「システムの復旧」と「レピュテーションの復旧」である。前者は、影響を受けたシステムが担っていた機能を一部的に代替する必要がある場合などに備えてBCP（Business Contingency Plan）を建てておいてそれを実行するなどが考えられる。後者は関係各所に対して安心材料を提供することである。

今後の連載では、CSFをベースとして、その実装要件であるSP800-53の管理策に関する解説を実施する。私がなぜ数多あるフレームワークからCSFにこだわるのかというと、私自身が過去にバグハンターでありレッドチームであったことから、「こんな守り方をされたら嫌だな」と攻撃者の目線で思うからである。最も基礎的な概念ながら、最も重要なCSFについては書いても書ききれないほど深いのだけど、それは後の連載で体感していただくこととしよう。