サイバーセキュリティが損なわれる原因を理解する(6) - 統計上多い事故は、設定の脆弱性が悪用されるケース

　前回のコラムでは、前々回に引き続き「設定の脆弱性」がなぜ生じるのかをみてきました。ソフトウェアを「アップデートしたら脆弱」になってしまうケース、外部サービスを「切り替えたら脆弱」になってしまうケースなど、よかれと思って踏み切ったインフラ更新措置が裏目に出てしまうケースもあるのですね。テストドリブンという言葉がソフトウェア開発の現場でようやく主流になりつつありますが、インフラ更新もテストドリブンでいきたいものです。
（前回のコラム、前々回のコラム）

　今回も、設定の脆弱性について別の角度から解説を試みるとしましょう。
　これまでのコラムを読む限り、設定の脆弱性は、どうやらソフト開発とシステム運用に起因する問題ばかりです。ソフト開発とシステム運用の人たちに設定の脆弱性を潰してもらうとして、セキュリティ担当に出来ることはないのでしょうか？

　システム運用の現場では、設定項目は数千とあります。このうち、どれがセキュリティを損なう致命的な設定の脆弱性につながるのか、システム運用の担当者にすべて精査して把握してくれと要請しても、非現実的な要求だとして一蹴されることでしょう。

　このためセキュリティとシステム両方に詳しい人が設定項目を精査し、安全側に倒した設定をまとめて、ベースラインとして社内で活用することが効果的です。例えば Webサーバやクラウドむけのデータベースは情報公開を前提としたシステムなので、多くの場合、世界中から情報にアクセスできるような設定になっています。これをシステム運用に投入する前に設定項目を精査し、社内イントラネット向けに設定をカスタマイズして、セキュリティ検査をしたうえでベースラインとして提供するだけでも、今日世の中で起きている情報漏洩事故の多くは未然に防げたでしょう。

　もちろんベースラインを作るのは手間がかかります。前々回のコラムで述べたように、設定のメンタルモデルを理解して、セキュリティを損なう要因となりそうな設定項目を洗い出して、それをデフォルト値から修正して、テストする。これをソフトウェアの更新にあわせて、また最新の脆弱性情報を勘案しながら更新していくわけですから、一度きりの作業ではありません。また開発現場や運用現場からは、多種多様なソフトウェアを使いたい、という要求が上がってくることでしょう。すべてを受け入れているとベースラインの構築、検証工数がどんどん膨れ上がりますから、ある程度はプラットフォームを収斂させつつ、かつ最新のイノベーションも取り入れていく必要があります。このあたりは CIO, CISO を含めた判断となるでしょう。

　また、ひろく流通するソフトウェアについては推奨ベースラインが用意されていたり、ベースラインからの逸脱をチェックするツールが使えるケースもあります。ベースラインを設定しても、システム全体で活用されなければ意味がありません。できるだけ自動化して、ベースラインからの逸脱をチェックしたいものです。

　セキュリティ検査、というとWebシステムに対する脆弱性検査や、複雑なシステム全体に対するペネトレーションテスト、のようなものを思い浮かべる方も多いと思いますが、セキュリティ検査はそれだけではありません。

　例えば前回のコラムで挙げたケースを反省材料として、ソフトウェアのアップデート時に脆弱性が混入する可能性を考えて、アップデートのたびにシステム全体のペネトレーションテストや脆弱性検査をやったとしたらどうでしょう。検査コストは間違いなく跳ね上がります。あまり現実的とは言えないでしょう。セキュリティ担当としては、毎回膨大な検査コストをかけずに、設定の脆弱性が混入する可能性をつぶしたい、と考えるのが自然でしょう。はたして、そんなことはできるのでしょうか。

　ペネトレーションテストや脆弱性検査のような、どこからモグラが出てくるかわからない、発見的な検査はスキルも要りますから、コストもかかります。しかし設定の脆弱性で、例えば本来アクセスできない場所からファイルが見えてしまう、といった問題が生じるとしたら、これを見つけるのは容易です。テストを自動化して、どのアカウントで何にアクセスできるか、定期的にチェックすればよいのです。

　ITチーム、財務、法務、カスタマーサポートなど、社内にはさまざまなロール（役割）があります。セキュリティを考慮して情報管理する場合、ファイルサーバのアクセス権設定を工夫して、ロールごとに細かくアクセス権を管理し、例えばカスタマーサポートの方が株主総会で発表予定の財務情報にアクセスできないように、といった権限分割を行うのが理想です。

　しかし例えば新任役員が財務情報にアクセスできない、といったトラブル対応時に、アクセス権設定が一時的に甘くなり、喉元過ぎれば熱さ忘れるで、財務情報へのアクセス権限が甘いまま経過する、といったこともありそうな話です。これを見つけて、アクセス権の設計方針にしたがって直していく（あるいはアクセス権を見直していく）、といった作業はセキュリティ担当者にしかできない仕事でしょう。

　そもそも、一般従業員やシステム管理者の関心事は「システムが使えること」「必要な情報にアクセスできること」です。「動いていたシステムが、ある日動かなくなること」や「必要もない情報にアクセスできること」は彼らにとっては余計な心配であり、考えたくもないことでしょう。「必要もない情報にアクセスできること」一つをとっても、数多くのケースが想定され、これを整理して系統的に、できるだけ漏れなくチェックすることは専任の担当者を必要とする仕事でしょう。そしてセキュリティ担当者としては、これを自動的かつ定期的にチェックして、設定の脆弱性が致命的な情報漏洩につながることを未然に阻止すべきでしょう。

　以上、３回にわたって設定の脆弱性について解説を試みましたが、その重大さがお分かりいただけたでしょうか。

　設定の脆弱性を放置して、一生懸命ログを穴があくほど眺めて、不正アクセスの兆候を見つけるのも一つの方法ですが、できれば攻撃者に気づかれる前に身内で設定の脆弱性を発見して、直してしまいたいですね。
　もちろん、設定の脆弱性がなくても、ソフトウェア脆弱性を突かれたらそれで終わり、というケースもあるのですが、いろいろな事故統計から、設定の脆弱性が悪用されるケースが非常に多い、ということが分かっています。
　ソフトウェア脆弱性は機構的に精巧であり、セキュリティ技術者や研究者の関心をあつめることが多いのですが、セキュアなインフラ運用の現場では、セキュリティ関係者の技術的興味だけに引っ張られることのないよう、バランスのとれた脅威認識を持っていただきたいと思います。

　次回からは、プロトコル脆弱性について紹介したいと思います。

■関連ページ
【アクセリアのサービス一覧】
　・サービスNAVI