永続的なシステムはあり得るのか？

自らの手で穴をあけている？

　第1回でシステムの5つの弱点として、「資産の特定」「リスクの分析」「リスクの評価・管理策の適用」「管理策の有効性の評価」「リスクの変化への対応」ができていない、という点をあげました。

　それぞれ資産によって、対応すべき対象を絞っていない弱点、リスクの分析においてさまざまな情報にまどわされる弱点、管理策の適用において、そもそも脆弱（ぜいじゃく）性を生む土壌を発生させている基盤設計、設定の弱点について言及しました。

　最終回となる今回は、「後から作られた脆弱性」に対応できていない弱点について説明します。

　監査で発見されるシステム上の脆弱性の中には、もともとの設計や開発に起因するものがあることを説明しましたが、脆弱性を発生させるもう1つの主要な原因として、運用中に行われた設定の変更や、システムやアプリケーションの追加／変更があげられます。

　技術的な監査の中で、発見された脆弱性の原因を確認したり、不正侵入が発生した際に利用された脆弱性の発生原因を確認したりすると、不適切な設定の変更や、ユーザーの追加が原因であった、という例が多くあります。

　こういった後から作られた脆弱性は、非常に厄介で危険です。

　本来、守られていると思っていたことが、実際には守られていないわけですから、最悪の結果を引き起こしかねません。そして、不幸にも実際に起きた例もあります。よくある後から作られた脆弱性の発生例を図1にまとめました。

　まさかそんなことがと思われるかもしれませんが、図1の原因で管理策が有効ではなかった、という例を幾度も経験しています。

　そのため、これらの後から作られた「致命的な脆弱性」を感知するための仕組みを考えなければいけません。

定期的な見直し

　このようなミスを発見するには、第三者的な目でチェックをすることが有効です。

　例えば第2回で紹介した脆弱性スキャナーのようなツールを使ったり、サービスを活用したりすることで、効果的に発見することが可能です。また、第3回で紹介した設定標準のチェックを定期的に実施することで、これらの「失態」を発見することも可能です。

　最も重要なポイントは、セキュリティーは運用を日々重ねることで、「劣化」する可能性がある、ということを「認識」することです。日々の運用に追われているところほど、こうした定期的な見直しは実施できないのですが、できないのであれば、「劣化リスク」を担保できていないことを組織として認識し、対策を実施しなければなりません。

　残念ながら、担当者レベルで忙しくて手が回らないという認識はしていても、経営陣に対して、忙しくて手が回らないことによって、劣化リスクが発生しているということを説明し、認識してもらっている例は極まれです。