高度化を続けるサイバー攻撃に対応するため、企業の情報システムではセキュリティ対策のエンハンスメント（追加・拡張）を継続的に実施しています。ただ、行き当たりばったりのエンハンスメントだと、追加・拡張した機能が「情報セキュリティ負債」に変化してしまい、企業の情報セキュリティ対策に悪影響を及ぼすことになります。
本記事では、「情報セキュリティ負債」とは何なのか、そしてその負債をどう乗り越えていけば良いのかを解説します。
ソフトウェア開発の世界では「技術的負債」という言葉があり、開発を行う上で、開発のスピードを優先した結果発生した品質の低いコードを指す言葉とされています。具体的には、継続的に開発を行う中で発生する、複雑、重複、手抜きのコードが該当します。
これらの技術的負債は、ソフトウェア開発の段階では大きな問題にはならず、注意を払われないことが多くあります。特にスピーディな開発が要求される場合などには、そのような対応がやむを得ないケースもあるかもしれません。
しかし、技術的負債は放置していると雪だるまのように肥大化する性質があり、早めにコードを整理して修正するリファクタリングなどの手を打たないと保守や次の開発・改修の際に多大なコストがかかるようになります。
これが借金と返済の関係に似ているため「負債」という比喩表現を使われているようです。短期的なメリットを優先しすぎると、後にツケが回ってきて中長期的にはデメリットが大きくなるというのは、実際の生活でもよくあります。
筆者は情報セキュリティ対策についてもこれに似た現象が生じていると考えています。すぐにセキュリティレベルを上げようと対策を積み上げたり、対策の導入スピードを優先させたりした結果、後にツケが回ってきて対策自体が新たな課題となってしまう現象です。
筆者はこうした現象を引き起こす要素を「情報セキュリティ負債」と呼んでいます（表 1）。では情報セキュリティ負債は具体的にどのような経緯で発生し、どんな問題を引き起こすのか、見ていきましょう。
|
|
技術的負債 |
情報セキュリティ負債 |
|
短期的視点 |
ソフトウェア開発のスピードを優先 →複雑、重複のコードが生じる
|
セキュリティ対策の早期の実装を優先 |
|
中長期的視点 |
品質改善・軌道修正に必要なリソースの肥大化 |
・品質改善・軌道修正に必要なリソースの肥大化 ・セキュリティ対策維持のためのリソースの肥大化 |
表1. 情報セキュリティ負債とは
情報セキュリティ負債が発生するのは、主にセキュリティ対策のエンハンスメントを実施したときです。サイバー攻撃は日々巧妙化を続けているため、システムを守るためにはセキュリティ対策のエンハンスメントを実施し続ける必要があります。
また、システムのセキュリティに関する公的機関や業界団体の規程・ガイドラインは継続的に更新され、実施すべきセキュリティ対策は増えたり変更されたりしています。
ただ、求められるがままに行き当たりばったりにエンハンスメントを続ければ、セキュリティ対策は増える一方で、全体としてはどんどん複雑化していきます。セキュリティ対策が増えると、複数の対策の間で機能の重複が発生します。
また、複雑化する中で古いセキュリティ対策が見直されずに残ってしまったり、必要なセキュリティ対策機能の導入に漏れが生じたりします。このような、実際には機能しないセキュリティ対策が「情報セキュリティ負債」にあたります。
情報セキュリティ負債は、セキュリティ対策の機能だけでなく運用プロセスにも存在します。既に不要になっているにも関わらず運用プロセスが現場に残っている、といった状態です。
導入当初に運用プロセスを過剰なレベルに設定して、見直しがないままになっている運用現場は少なくありません。運用は単純作業の繰り返しが多く、時を経るごとに当初の目的を見失いがちです。当事者では無駄かどうかを気付けないものです。
情報セキュリティ負債が引き起こす問題は主に三つあります（図 1）。
図1. 情報セキュリティ負債が引き起こす問題
一つめは「維持コストの増加」です。情報セキュリティ負債は本来不要なセキュリティ対策です。この維持にリソース（ヒト・モノ・カネ）を投入していると、情報セキュリティ対策コストが適正値よりも過剰になります。
コストはソフトやハードウエアに支払う直接的な金銭負担だけではありません。ヒトやモノといったほかのリソースを過剰に使うため、間接的なコスト増も相当な額になります。
例えば、追加の対策により、それまで利用していたセキュリティ機能が不要になったとします。情報セキュリティ負債を放置している現場だと、不要になったセキュリティ機能（コードや API）が残り続けます。
動作している限り、CPU やメモリーといったサーバーリソースを消費します。実装時のテストや維持管理といった作業に費やす人的リソースも、機能が残っていれば引き続き必要になります。
また、多くのセキュリティ対策は目的通りに機能させるための運用業務が必要となります。例えば、セキュリティ対策の場合は、情報資産の棚卸し、システムへのアクセス履歴の収集と蓄積、通信トラフィックの分析といった、実施結果の定期的な報告を必要とします。
報告を行うセキュリティ対策が増えるほど、報告のためのデータ収集や報告フォーマットの整理に必要な作業量が増えます。問題は、エンハンスメントを続けていると運用業務がもはや不要であるにもかかわらず形骸化した形で、情報セキュリティ負債として蓄積してしまうことです。不必要な業務に人的リソースを取られる原因になってしまいます。
二つめは「セキュリティ対策の品質低下」です。不要な対策が多いほど、追加対策を実施した際に連携する機能や運用が増え、実装やテストが多くなり、不具合や不足が生じてしまう可能性が高くなります。
また、重複した機能や運用が多いと、本来正常な処理まで異常として検知（フォールスポジティブ）してしまうことも考えられます。新たな脅威への対応を行う際に考慮すべきことが増え、余分なリソースを使うだけでなく、結果的にミスやトラブルが増えてしまうといった影響を及ぼします。これでは、セキュリティ対策レベルを上げるどころか、下げる要因となってしまいます。
三つめは「軌道修正コストの増加」です。冒頭で紹介した技術的負債と同様に、情報セキュリティ負債も放置すればするほど軌道修正に必要なリソースが大きくなります。セキュリティ対策にはお金がかかります。数が増えていけば、それだけ変更にかかるコストが増えます。
また、セキュリティ対策の導入から時間が経過するほど、実施時の目的が分からなくなっていきます。軌道修正をするには、対策がその時点で有効か否か、対策を中止した場合にどういった範囲に影響するのかをコストをかけて調査したうえで、中止や変更を検討しなければなりません。
サイバー攻撃の脅威は年々高度化しており、セキュリティ対策に対する投資の重要性に異論がある人はほとんどいないでしょう。しかし、IT投資は本来ビジネスを変革するために行うもので、セキュリティコストが増えすぎIT投資をひっ迫するようでは本末転倒です。
「セキュリティレベルは高めたいが、セキュリティコストが増え続けるような事態は避けたい」というのが多くの経営者、IT担当者の本音でしょう。そこで情報セキュリティ負債に焦点を当て、不要なセキュリティ対策をなくし無駄なコストがかからないようにするべきです。
次に、機能面と運用面に分けて情報セキュリティ負債を解消するための方法を説明します。
機能とは、例えば「脆弱性を突いた攻撃のネットワーク上での検知・防御」といった、セキュリティ対策を支える個別の機能を指します。セキュリティ対策の継続的なエンハンスメントの結果、重複する機能がシステム内に存在する可能性があります。情報セキュリティ負債をなくすために実施すべき対応は「定期的なアセスメント」「エンハンスメント時の見直し」「機能の標準化・統合化」の3点です。
まずは「定期的なアセスメント」を実施し、組織におけるセキュリティ対策全般を俯瞰して見直します。不要なサービス、セキュリティコード、資産（ID、アクセス権、収集ログ）など、重複した対策や既に不要になったものの残存・形骸化している対策を洗い出し、セキュリティ負債として可視化することが第一歩です。
可視化された課題についてその都度対応することで、発生してしまったセキュリティ負債を一定のタイミングで解消することができます。既存のシステムアセスメントや棚卸しなどの定期的に行われている対応と併せて実施すると効率的です。
次に、セキュリティ負債の発生を未然に予防するために「エンハンスメント時の見直し」を行います。個別のエンハンスメントのタイミングで、対策の目的・内容をレビューし、既存の対策や別の対策計画と重複する機能がないか確認します。
できればさらに一歩進んで、予め「機能の標準化」を行い、セキュリティ対策機能の目的や要件を明確に定義し文書化をしておくとよいでしょう。きちんと定義された文書化された形で標準化が行われていれば、エンハンスメント時のレビューを効率的に行うことができ、機能の重複は起こりません。情報セキュリティ負債の発生を未然に防ぐことができます。
もうすでに不要となったにも関わらず形骸化されたまま行われている運用業務も情報セキュリティ負債になりえることを説明しました。運用面の情報セキュリティ負債をなくすために実施すべき対応は「定期的な業務の棚卸し」と「必要な運用業務の言語化・文書化」です。
まずは「定期的な業務の棚卸し」を行います。機能面のセキュリティ負債の際に説明した「定期的なアセスメント」と合わせ実施するとよいでしょう。例えば、資産の見直しの中で特定のログについては収集・分析する必要がないことが判明した、といった場合には該当のログに関連する業務（収集・分析・報告など）の見直しを行います。
次に、棚卸しを経て必要と判断された業務の目的や要件を「言語化・文書化」を行います。文書化することで目的が明確になり将来の形骸化を防ぐことができ、次回以降の棚卸しを効率的に行うことができます。また、要件が明確になることで、オペレーションの自動化やアウトソースの検討を行いやすくなります。
本来なら企業内の様々なシステムの全体像を捉え、中長期的な視点に立った対策の計画や見直しが必要です。しかし現実には、個別の対策を優先して後回しになっている現場が多く、筆者が支援する企業においても「情報セキュリティ負債」と捉えられる課題に現場が疲弊しているケースを目にしてきました。
情報セキュリティ対策は増やしていけば対策レベルが高まっているという単純なものではありません。多層防御の観点から優先度を考え、全体最適を意識したバランスの取れた対策の取捨選択と見直しが必要です。「情報セキュリティ負債」という観点から、改めて自らの組織のセキュリティ対策の全体像を俯瞰し見直してみてはいかがでしょうか。
※本記事は、以下書籍の内容を元に再構成したものです。
「上流工程でシステムの脅威を排除する セキュリティ設計実践ノウハウ」
編著：山口 雅史
発行元：日経BP社
https://tech.nikkeibp.co.jp/atcl/nxt/books/18/00010/111300196/