アプリケーション仕様とセキュリティ仕様の関係

アプリケーション（ソフトウェア）仕様とセキュリティ仕様の関係とその特徴は正しく理解しておく必要があります。この関係と仕様の特徴を正しく理解しておかないと根本的な部分での間違いにつながります。

アプリケーション仕様とセキュリティ仕様の関係

アプリケーション仕様とセキュリティ仕様の関係は簡単です。アプリケーション仕様が優先されます。

• アプリケーション仕様 ＞ セキュリティ仕様

なぜアプリケーション仕様が優先されるのか？理由は簡単です。世の中にはセキュリティ対策などどうでも良いので「とにかく速い」ソフトウェアが必要だったり、教育目的でセキュリティ対策は取り入れないで作るソフトウェアもあります。基本的には「アプリケーション仕様＞セキュリティ仕様」です。

要するに「セキュリティはどうでも良い」というアプリケーション仕様も正しい仕様として存在します。

ソフトウェアのセキュリティ仕様はアプリケーション仕様の中に取り込まれる仕様になる、ということです。セキュリティ対策によって向上する安全性は様々な要素（実行速度、開発速度、開発コスト、導入コスト、運用コストなど）とのトレードオフ関係、つまりセキュリティを向上させようとすると他の要素にコストが必要になります。

アプリケーション仕様はトレードオフ関係を考慮し、実装するセキュリティ対策を選択します。

セキュリティ対策の特徴

セキュリティ仕様の特徴を説明の前に「セキュリティ対策」の特徴を紹介します。セキュリティ対策の定義は標準と基本概念から学ぶ正しいセキュリティの基礎知識を参照してください。

• セキュリティ対策はリスクを変化させる施策すべて
• セキュリティ対策は常にセキュリティ対策
• セキュリティ対策の評価はその対策の「費用対効果」で評価
• セキュリティ対策の分類
  • 「”効果的な”セキュリティ対策」と「”効果的でない”セキュリティ対策」
  • 「”採用した”セキュリティ対策」と「”採用しなかった”セキュリティ対策」
  • 「”十分な”セキュリティ対策」と「”不十分な”セキュリティ対策」

「セキュリティ対策」の目的は「リスクマネジメント」です。リスクを識別し、対策し、許容可能な範囲にコントロール（制御）するのが「セキュリティマネジメント」です。

• リスクを許容可能な範囲に収めるために必要なセキュリティ対策を実施するのがセキュリティマネジメント

セキュリティ仕様の特徴

基本的には「アプリケーション仕様 ＞ セキュリティ仕様」ですが、リスクマネジメントを行う為に「セキュリティ仕様＞アプリケーション仕様」となる逆転が発生します。

例えば、インターネットにサーバーを接続している会社にとって「任意コード／コマンド実行脆弱性」は許容できないリスクです。個人で運用しているサーバーでも、インターネット上の他のユーザーに多大な迷惑をかけます。全てのインターネットに接続したコンピュータにとって「任意コード／コマンド実行脆弱性」は許容不可能なリスクであり、例え開発者／利用者が「このリスクは許容しているのだ」と主張しても許される物ではありません。

現在、多要素認証を取り入れていないシステムが大多数ですが、状況が変わってきているのでユーザー名とパスワードによる対策だけではリスクを許容できなくなりつつあります。近い将来、多要素認証を取り入れないリスク許容が「任意コード／コマンド実行脆弱性」と同様に許されないリスク許容と認識されるかも知れません。

許容できないリスク

ITシステムを開発／運用する上で「許容できないリスク」は沢山あります。多くのシステムで「許容できないリスク」は共通しており、セキュリティ専門家はこれらのリスクに対してガイドラインを公開しています。CWE/SANS TOP 25、OWASP TOP 10、OWASP Secure Coding Practicesなどは普通は「許容できないリスク」に対するセキュリティ対策として最も重要な物をガイドラインとしてまとめた物です。

• アプリケーション仕様 ＞ セキュリティ仕様

が基本系ですが、例外ももちろんあります。「許容できないリスク」に対しては逆転現象が発生し必ずアプリケーション仕様に取り入れなければならなくなり「セキュリティ仕様 ＞ アプリケーション仕様」となります。

• 許容できないリスクがあると「セキュリティ仕様 ＞ アプリケーション仕様」となる

例えば、プロトタイプを作る場合には「許容できないリスク」が全くない事もあります。こういった場合には逆転現象は発生しません。しかし、一般に利用されるシステムにはほとんどの場合、何らかの「許容できないリスク」が存在します。

現在では一般の開発者が、どのような許容できないリスクがあり、そのリスクに対してどのような対策を取るべきないのか？自分で最初から考える必要性はあまりありません。CWE/SANS TOP 25、OWASP TOP 10、OWASP Secure Coding Practicesなどのガイドラインはもちろん、ISO 27000などのセキュリティ標準規格を参考に「許容できないリスク」を緩和すれば良いです。

セキュリティガイドラインのトップ2のセキュリティ対策

CWE/SANS TOP 25とOWASP Secure Coding Practicesでは明確に

• 入力のセキュリティ対策が第一位
• 出力のセキュリティ対策が第二位

としています。これはセキュリティ対策の基本概念である「境界防御」は最も重要な対策の一つであること、現実に発生している脆弱性を考慮すると入力／出力のセキュリティ対策が最も効果的であることからも妥当な順位です。

まとめ

セキュリティ対策がリスクマネジメントである、との考えは重要です。

• リスクを許容可能な範囲に収めるために必要なセキュリティ対策を実施するのがセキュリティマネジメント

「セキュリティ対策」として識別された施策は「リスクマネジメント」の管理対象とされ、定期的に評価され、「アプリケーション仕様が変わらなくても」現状に合わなくなった場合には追加の対策を行ったり、別の対策を採用するというPDCA※プロセスで管理されます。

※ PDCA: Plan, Do, Check, Actionの管理プロセス。ISOではPDCA管理が幅広く採用されている。

必要なセキュリティ対策をアプリケーション仕様として管理すると、リスクマネジメントのプロセスから除外されてしまいます。このため、

• アプリケーション仕様 ＞ セキュリティ仕様

であっても、許容できないリスクの場合は

• セキュリティ仕様 ＞ アプリケーション仕様

として管理します。CWE/SANS TOP 25やOWASP Secure Coding Practicesでセキュリティ対策の第一位、第二位のセキュリティ対策をセキュリティ対策として採用しない合理的な理由はあまりありません。

採用しなかったセキュリティ対策もセキュリティ対策として管理する必要があります。

• 誤って不採用としたセキュリティ対策を使用しないため
• 状況が変化し、不採用としてきたセキュリティ対策が必要となることがあるため

「セキュリティ対策」の定義が主観などによって変化してはこのような管理を実現することはできません。

• セキュリティ対策はリスクを変化させる施策すべて
• セキュリティ対策は常にセキュリティ対策
• セキュリティ対策の評価はその対策の「費用対効果」で評価
• セキュリティ対策の分類
  • 「”効果的な”セキュリティ対策」と「”効果的でない”セキュリティ対策」
  • 「”採用した”セキュリティ対策」と「”採用しなかった”セキュリティ対策」
  • 「”十分な”セキュリティ対策」と「”不十分な”セキュリティ対策」

このように考えてマネジメントする必要があります。