セキュリティ課題はどこから着手すべきなのか

ソフトウェアセキュリティ問題の背景と解決の出発点

ソフトウェアセキュリティの問題は、技術的な要因よりもむしろ開発者にとって“退屈な”オペレーションに起因している場合が多い。

公開 2009年04月22日 07時30分

更新 2012年09月04日 18時09分

著者

Kevin Beaver

[TechTarget]

印刷する

　ソフトウェアセキュリティの分野では、われわれ開発者は技術的な問題にばかり目を向ける傾向がある。技術的な問題は面白く、また手応えがあり、チームの全員にとって取り組みやすい。コードの継続的なチェックという地味な（退屈といえる）面も同様に重要だが、なおざりにされがちだ。これは、ソフトウェアに関連するセキュリティリスクの根底にある問題の1つだ。

　コンサルティング先の社内ドキュメントをレビューしたり、開発者や開発マネジャー、QA（品質保証）スタッフにインタビューしたりすると、こうした問題が明らかになる場合が多い。ソフトウェアのセキュリティがビジネスリスクの大きな要因となっているのも当然だ。

　ソフトウェアのセキュリティ問題の根本的な背景として、以下の4つが挙げられると思う。

Microsoft Security Development Lifecycle（SDL）やOWASP Top 10 Projectのようなセキュリティモデルやフレームワークの導入があまり進んでいない
基本的なシステムの展開や可用性以外の問題については、IT担当者とセキュリティ担当者の間で最低限の連携しか取れていない
SSL、強力なパスワードの強制、多要素認証といったセキュリティ対策が、ビジネスリスクを最小化する手段として浸透するのではなく、「やらされている」という感覚で行われている
ソフトウェアチームのメンバーが、情報リスクに関連するポリシー、評価・監査、脅威の軽減策の中で、役割を与えられていない（役割を免除されている場合もある）

　ソフトウェアのセキュリティ問題のこうした背景は、企業や業種にかかわらず、かなり共通している。会社の規模が大きくても小さくても、社内ソフトウェアのセキュリティ問題の多くは、根本的にオペレーション上の問題に起因している可能性がある。

　では、どこから手を着けるか。また、どうすればビジネスオペレーションに深く根ざしたそうした問題を解決していけるのか。これらの問題を解決することは容易なことではないが、もちろん可能だ。そのためにはまず、IT、セキュリティ、開発／QAの担当者とマネジメントが、以下の問いに自信を持って答えられなければならない。

「ソフトウェアセキュリティ」が定義されているか

　「ソフトウェアセキュリティ」がビジネスの文脈で何を意味するかが明確に定義されているか。理解していない問題を解決することはできない。

セキュリティ基準が文書化されているか

　OSやルータ、データベースだけでなくアプリケーションについても、文書化されたセキュリティ基準やそれに類するものがあるか。文書化されていない基準は願望にすぎない。

セキュリティポリシーで担当者が言及されているか

　開発担当者とQA担当者が社内のセキュリティに関するポリシー、計画、手続きの中で言及されているか。これらを効果的に運用するには、言及されている必要がある。

定期的なチェックを行っているか

　ソフトウェアが一連の標準的なセキュリティ対策に適合するように、良いツールと優秀な人材を動員して一貫したチェックを定期的に行っているか。すべての企業が、効果が誇張されているSSLや強力なパスワード、入力の妥当性チェックにとどまらず、少なくとも、一般に受け入れられている基本的な対策を徹底しなければならない。

お墨付きは誰から得るのか

　これは最も重要な問いかもしれない。マネジメントは誰からお墨付きを得なければならないか。内部監査人か、あるいは規制当局だろうか。相手によって、お墨付きを得るための難易度はかなり違うかもしれない。誰が相手かを見極めれば、目指すべきセキュリティのレベルが明確になる。

　ソフトウェアセキュリティの技術的な面は魅力的だが、多くの場合、退屈なビジネスに関連する面をなおざりにしたり、勝手に判断したりすることが、トラブルを招くことになる。関係者にこれらの重要な問いをぶつけてみよう。全員が共通認識に立って答えられることが、自社に必要なセキュリティの維持管理に取り組む出発点になる。

本稿筆者のケビン・ビーバー氏は、米アトランタにあるPrinciple Logicを経営する独立系情報セキュリティコンサルタントで、執筆、講演も手掛ける。情報セキュリティに関する7冊の著書および共著書がある。

印刷する