セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない？！

セキュアコーディング／セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。（※ 対策の目的が何か？などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません）

どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング／セキュアプログラミングのガイドラインなどがどうなっているのか？紹介します。

このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング／セキュアプログラミングとは何か？は過去のブログをご覧ください。

CERT Top 10 Secure Coding Practices

セキュアコーディングの元祖とも言えるCERTのCERT Top 10 Secure Coding Practicesでは以下の項目を挙げています。

1. 入力をバリデーションする
2. コンパイラの警告に用心する
3. セキュリティポリシーの為に構成／設計する
4. 簡易にする
5. デフォルトで拒否する
6. 最小権限の原則を支持する
7. 他のシステムに送信するデータを無害化する
8. 縦深防御を実践する
9. 効果的な品質保証テクニックを利用する
10. セキュアコーディング標準を採用する

OWASP Secure Coding Practices

様々なセキュリティガイドラインを作成／公開しているOWASP（Open Web Application Security Project）ですが、セキュアコーディングのガイドも公開しています。その中で「セキュアコーディング実践チェックリスト」として紹介している対策は次の通りです。

1. 入力バリデーション
2. 出力エンコーディング
3. 認証とパスワード管理
4. セッション管理
5. アクセス制御
6. 暗号の取り扱い
7. エラー処理とログ
8. データ保護
9. 通信セキュリティ
10. システム設定
11. データベース管理
12. ファイル管理
13. メモリ管理
14. 一般的コーディング実践

CWE/SANS Top 25 Monster Mitigation

CWE（Common Weakness Enumeration）とはCVE（共通脆弱性識別子） を管理している米国政府の外郭団体であるMITRE社が管理しているプロジェクトです。SANSとは米国防省のセキュリティコンサルティングや教育なども行っているセキュリティ研究／教育機関です。

CWE/SANS Top 25としてCWEの中から最も注意すべき脆弱性トップ25を公開しています。しかし、最も重要なセキュリティ対策はMoster Mitigation（怪物的な緩和策 – 緩和策は国際セキュリティ標準では明確なセキュリティ対策）としてリストアップしています。

1. M1 Establish and maintain control over all of your inputs. （入力バリデーション）
   
2. M2 Establish and maintain control over all of your outputs.
3. M3 Lock down your environment.
4. M4 Assume that external components can be subverted, and your code can be read by anyone.
5. M5 Use industry-accepted security features instead of inventing your own.
6. GP1 (general) Use libraries and frameworks that make it easier to avoid introducing weaknesses.
7. GP2 (general) Integrate security into the entire software development lifecycle.
8. GP3 (general) Use a broad mix of methods to comprehensively find and prevent weaknesses.
9. GP4 (general) Allow locked-down clients to interact with your software.

ISO27000／ISMS

最新のISO27000規格からは個別の入力バリデーション方法の記載は無くなりましたが、セキュアコーディング／セキュアプログラミング標準を採用するように要求しています。それらは何かというと上記のような物になります。つまり入力バリデーションはソフトウェア開発における最も重要なセキュリティ対策です。

以前のISO27000規格のように具体的な入力バリデーション方法を記載しなくなった理由は日本規格協会のISO27000の解説部分に記載されています。セキュアコーディング／セキュアプログラミングが”整備・普及”したので省略されました。

まとめ

セキュアコーディング／プログラミングの基本を正しく理解し、実践すれば実施しない場合に較べて遥かに安全なソフトウェアが構築できます。

アプリケーション要求に「セキュアコーディング・プログラミング標準を採用する」とあり、ソフトウェアの問題で損害が発生した場合に「入力バリデーションはアプリケーション仕様であり、明示的に指示がなかったので入力バリデーションをしていなかった」と言い訳しても、法廷などでは通用しないでしょう。どこからどう見ても入力バリデーションはセキュリティ対策だからです。

因みにどのガイドラインでも入力対策と出力対策は独立したセキュリティ対策として記述しています。境界防御とはそういうモノです。しかし、これは良く間違えるので注意が必要です。誤解する人も居たのでCERT Top 10 Secure Coding Practicesの出力対策は以下のように解説しています。

複雑なシステムを呼び出す側は出力コンテクストを判別できるので、データの無害化はサブシステムを呼び出す前の処理が責任を持つ。

セキュアコーディング／セキュアプログラミングが要求されている場合（されていなくてもですが）、入力バリデーションをセキュリティ対策として実施し、セキュリティ管理のPDCAサイクルでマネジメントしないと大きなリスクが発生します。例：10万件の個人情報漏洩で1件500円保証した場合5000万円、20万件なら1億・・・

私からすると全く理解不能な論理で「入力バリデーションはアプリケーション仕様」とするリスクは見逃す訳にはいかなので、このブログを書きました。セキュリティに関わる人が「入力バリデーションはあまり効果がない対策だ」「セキュリティ対策ではないアプリケーション仕様だ」「出力対策がないと結局意味があまりない対策だ」など意味が通らないことを主張していたら大問題ではないでしょうか？訴訟リスクまで引き受ける覚悟なのでしょうか？

追記：

セキュリティ専門家の方で「ISO27000とかはどうでもよい」と公言されている方も居ます。そういう場合は前置きとして「非標準の考え方である」ことを強調すべきです。それが標準だと勘違いした方が大きな被害を受ける可能性もあるでしょう。