システムの脆弱性対策戦略は、セキュリティテストだけで十分なのか
アプリケーションにおけるセキュリティ脆弱性対策を成功させることは喫緊の課題です。米国国立標準技術研究所がリリースしたドキュメントNISTIR-8151 “Dramatically Reducing Software Vulnerabilities(劇的にソフトウェア脆弱性を減らす方法)”は多くの示唆を与えています。
このドキュメントによると、ソフトウェアセキュリティ保証の価値は、以下の式で表すことができます。
ソフトウェア保証Aは、ソフトウェアが必要に応じて安全に動作することを保証するもので、3つの広範な源泉からもたらされます。
第1の源泉は、 p:開発プロセスです。ソフトウェアが明確な要件を備えたチームによって開発され、十分に訓練され、低い脆弱性率で優れたソフトウェアを構築する能力を実証しているなら、そのソフトウェアが生産するソフトウェアには脆弱性が少ないという確信が得られます。
第2の源泉は、s:ソフトウェアの分析です。例えば、コードのレビュー、受入れテスト、静的分析は、ソフトウェアにおける脆弱性がまれである可能性を保証します。
第3の源泉は、e:復元力のある実行環境です。例えば、ソフトウェアの品質に自信がなければ、コンテナで実行し、システム権限をほとんど与えずに、他のプログラムで実行を監視させ、脆弱性の影響を制御することができます。
これらの3要素のうち、特に開発プロセスと検証プロセスはトレードオフすることができるかもしれません。開発プロセスが強力で成熟していると、検証プロセスはそれにブレがないか調べるだけで良いと考えられます。逆に、開発プロセスがセキュリティを保証してくれるレベルが低いと、検証プロセスが盤石でないと、セキュリティが実現できません。
開発プロセス、検証プロセス、そして実行環境の3要素について、それぞれ弱点を把握し、効果的に強化することが必要だということです。さらに、これら3つの保証の連携が、多くの問題を解決します。
OWASP SAMMでは、開発プロセス、検証プロセス、実行環境、そしてそれぞれのガバナンスの77のアクティビティについてポイントを示しています。ここ数年、わたしたちはこれらを参考にしながら、少なからぬセキュリティ・イニシアチブと品質保証改善に取り組んできました。しかし、それらはこれからも本当に有効なのでしょうか。また、どのように実践できるのでしょうか。
ブリーフィング&ディスカッションにお越しください
定期的に、セミナーを提供しています。
5月27日・東京 システムへのサイバー攻撃に備える -「DevOps」という選択
資料をご請求ください
漠然としたチームの活動を組織的に捉えるツールとしての開発スコアリング、数々の脆弱性テストをポータルで一元管理できる脆弱性検査マネジメント、また体系的なトレーニングも提供しています。
どうぞ、弊社のサクセスマネージャにご相談ください。