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

2009年2月26日(木)
佐藤 元彦

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

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

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

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

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

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

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

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

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

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

定期的な見直し

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

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

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

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

伊藤忠テクノソリューションズ株式会社
ITサービスコンサルティング部。
特定非営利活動法人 日本セキュリティ監査協会(JASA)幹事。ISSA Tokyo Chapter Recording Secretary。公認情報セキュリティ監査人、公認システム監査人、システム監査技術者、情報セキュリティアドミニストレータ。2003年から、情報セキュリティサービスを、公共・民間問わず、さまざまな形式で実施。2006年より現職。現在は、情報セキュリティ監査をメインに、ITリスクに対応するマネジメント・テクニカルサービスを提供している。所属学会(国内):情報ネットワーク法学会、情報処理学会、日本セキュリティ・マネジメント学会(JSSM)。 http://www.ctc-g.co.jp/

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています