門林 雄基氏によるコラム、【サイバーセキュリティが損なわれる原因を理解する(6)】を公開

第7回：サイバーセキュリティが損なわれる原因を理解する(6)

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

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


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

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

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

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


「膨大な検査コストをかけずに設定の脆弱性が混入する可能性をつぶす方法は、「テストの自動化」」
　セキュリティ検査、というとWebシステムに対する脆弱性検査や、複雑なシステム全体に対するペネトレーションテスト、のようなものを思い浮かべる方も多いと思いますが、セキュリティ検査はそれだけではありません。

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

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

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

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

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


・・・ここから先は、アクセリア株式会社で公開中のコラム本編でご覧ください。
(リンク »)


【門林 雄基氏のコラム】
・第1回：サイバーセキュリティに求められるバランス感覚 (リンク »)
・第2回：サイバーセキュリティが損なわれる原因を理解する(1) (リンク »)
・第3回：サイバーセキュリティが損なわれる原因を理解する(2) (リンク »)
・第4回：サイバーセキュリティが損なわれる原因を理解する(3) (リンク »)
・第5回：サイバーセキュリティが損なわれる原因を理解する(4) (リンク »)
・第6回：サイバーセキュリティが損なわれる原因を理解する(5) (リンク »)