システムの弱点を補強するには？

弱点3：リスクの評価・管理策の適用

　本連載では、システムの5つの弱点（「資産の特定」「リスクの分析」「リスクの評価・管理策の適用」「管理策の有効性の評価」「リスクの変化への対応」）の中の「リスクの分析」について紹介しました。

　第2回の末尾では、「If we guard our toothbrushes and diamonds with equal zeal, we will lose fewer toothbrushes and more diamonds（もしわれわれが歯ブラシとダイヤモンドを同じ熱意で守ろうとしたら、われわれは少しの歯ブラシと多くのダイヤモンドを失うだろう）」という言葉を紹介しました。

　3回目になる今回は、「どのくらいの熱意で守るか」という、「リスクの評価・管理策」について、紹介します。

　さて、前回はダイヤモンドを誰がどこからどのように盗んでいくか、という脅威と脆弱（ぜいじゃく）性について述べさせていただきました。

　その中で、脆弱性を特定するためのツール、サービスについて簡単に触れましたが、かなり、消化不良な書き方だと感じられたと思います。

　このツールを使えば、この脆弱性がわかるので、こう直しましょう、と書ければいいのですが、ことセキュリティーに関することとなると、そういった書き方はできなくなってしまいます。

　例えばOWASP Testing Guideを紹介して、このガイドを理解して、実施すれば、Webアプリケーションの脆弱性を突き止めることができます。発見できた脆弱性に対して、対応を進めてください、と書いたとしたら、かなり現実性に欠ける話題となることは否めません（もしくは、「万能網羅脆弱性検査ツール」があればうれしいのですが、残念ながら筆者の知る限りでは存在していません）。

　では、どうすればよいのでしょうか。

　脆弱性の「原因」について考えると解が見えてきます。

　その原因の1つは、「最初からあった脆弱性」、そしてもう1つは「後から作られた脆弱性」です。

　脆弱性は、原因から解決していく、ということがもっとも有効な対策です。すでにできあがったシステムを運用しているので、戻ることはできないことはわかっています。それでも、あえて、原因からの解決を述べるのには理由があります。今回は、最初からあった脆弱性に対して、どのように対処をしていくかを考えてみます。

システムの開発プロセス

　まず、情報システムのライフサイクルについて、SDLCをモデルとして考えることにします。

　SDLCとは、情報システム開発ライフサイクル（Information system development life cycle）を指し、汎用的な情報システム開発のモデルや方法論を示しています。ここでは、SDLCを、「企画」「調達／設計」「開発／導入」「運用／保守」および「廃棄」の5つのフェーズに分けて記載します（図1-1）。

　アプリケーションの開発プロセスも、SDLC（もっともこちらはsoftware development life cycleですが）とほぼ同じですが、さらにここでは、Webアプリケーションに特化して、SDLCの「企画 ～ 開発」部分の具体的な作業を、図1-2のようなフレームワークモデルで考えてみます。

　われわれが監査を実施する場合は、そのほとんどが保守／運用フェーズのシステムなのですが（まれに導入時）、発見される脆弱性の多くが、それ以前の「企画」「調達／設計」「開発／導入」の際にセキュリティーが考慮されていなかったことに端を発していることに気づきます。

　なぜ「企画」「調達／設計」「開発／導入」の各時点でセキュリティーが考慮されないのかについては、さまざまな要因があります。この中で多い要因として、業務委託による開発／構築で、委託者は受託者がセキュリティーを当然考えてくれると思っており、受託者は委託者がセキュリティーに関して当然指示をしてくれると思っている、というセキュリティーの空白地帯が生まれることがあります。

　また別の例では、インフラ部分はセキュリティーに強い情報システム部門が設計／構築を指示していたが、その上で動作するWebアプリケーションについては、業務部門が提供するサービスであることから、業務部門が設計／構築を統括していたため、結果として、セキュリティーに対する明確な指示が出せず、Webアプリケーションに大きな脆弱性が発生していることが発見された、ということもあります。

　運用を開始する前の「どこか」で、セキュリティーのピースが欠けると、結果としてピースが欠けたまま、システムは動き続けるのです。

　自分のシステムの成立過程を振り返った時に、上記のポイントでそれぞれセキュリティーが反映されていたでしょうか？反映していないのであれば、どこかにピースの欠落が発生し、そこに脆弱性が存在する可能性が高くなります。

　それでは、どこか欠けているかも？という人のために、まずは、脆弱性を特定して個別に対処するのではなく、「企画」「調達／設計」のフェーズにいったん戻って、効果的に大きな穴をふさいでいく作業を紹介します。