セキュリティ標準では入力データの妥当性確認（入力バリデーション）が要求されています。具体的な方法はBS 7799（英国のJIS規格のような物、2000年に国際標準化）が作られた時（90年代後半）から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。（日本では普及していないような。。）
セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。
かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて（？）ブログにします。
ISO27000の入力データ妥当性確認
以下の解説はJIS X 5080:2002 (ISO/IEC 17799:2000）からの引用です。昔から標準として定められている、ということが理解るよう古い標準から引用しています。国際標準化は2000年、JIS規格としても2002年から要求されているセキュリティ対策になります。
ISO 17799は後にほぼそのままISO 27000規格として改訂されています。このためISO 17799の内容はISO 27000の内容と同じです。また、冒頭に記載したとおり、現在ではセキュアプログラミングなどが普及したので、現行版のISO 27000からは具体的な記述は省略されています。
入力データの妥当性確認（10.2.1）
業務システムに入力されるデータは、正確で適切である事を確実にするために、その妥当性を確認することが望ましい。業務取引処理（transaction）、常備データ（名前、住所、信用限度、顧客参照番号）及びパラメタ（売価、通貨レート、税率）の入力を検査することが望ましい。次の管理策を考慮することが望ましい。
- 次の誤りを検出するための二重入力又はその他の入力検査。
- 範囲外の値。
- データフィールド中の無効文字。
- 入力漏れデータ又は不完全なデータ。
- データ量の上限及び下限からの超過。
- 認可されていない又は一貫しないデータ。
- その妥当性及び完全性を確認するために重要なフィールド又はデータファイルの内容の定期的見直し。
- 入力データに認可されていない変更があるかどうかについての紙に印刷した入力文書の点検（入力文書に対する変更はすべて、認可を得ることをが望ましい。）。
- 妥当性確認の誤りに対応する手順。
- 入力データのもっともらしさを試験する手順。
- データ入力仮定にかかわっているすべての要因の責任を明確に定めること。
金融機関向けのような記述があるのはBS 7799が金融機関などの重要インフラのITセキュリティの標準として策定されたためだと思われます。金融機関向けの具体例はただの例に過ぎず、これらのデータだけが確認対象ではないことは文脈から解ります。
またISO 27000はソフトウェアセキュリティの為だけの標準ではないので、全般的なバリデーション方法、運用方法も含めた記述になっています。
「望ましい」と記載されているのは、標準規格が認証取得の”ガイドライン”であることが理由です。全てのベストプラクティスを実装しなくてもISO認証（ISO 27000の場合はISMS認証）は取得できるようになっています。「しなければならない」と記述すると、PDCAサイクルによる漸進的かつ継続的な改善を目標とするISO標準には似わないことが理由です。
「望ましい」と記載されている＝「実施しなくてもよい」ではないので注意してください。むしろ「実施すべき」と書かれている、と理解すべきです。
ソフトウェア開発で役立つ部分
ソフトウェア開発は運用も含めて考えなければならないので全て役立つと言えます。しかし、ソフトウェアで実装する上で特に重要な指針となる部分はこの部分です。
- 次の誤りを検出するための二重入力又はその他の入力検査。
- 範囲外の値。
- データフィールド中の無効文字。
- 入力漏れデータ又は不完全なデータ。
- データ量の上限及び下限からの超過。
- 認可されていない又は一貫しないデータ。
この記述でセキュアプログラミング指針として今一つな点は”データフィールド中の無効文字”が含まれていないことを要求している点です。
現在の標準ではセキュアプログラミング／セキュアコーディングを行う、としているので問題ありませんが、”許可している物だけが含まている”ことを検証すること（ホワイトリスト型チェック）により確認すべきです。
参考：ホワイトリストの作り方
まとめ
世の中には標準セキュリティとは全く異る概念の情報セキュリティ概念を持っている方もいるので誤解している方も多いようです。入力対策は当たり前に実装すべきアプリケーション仕様の一部であるからセキュリティ対策ではない、とする意味が解らない主張もあります。
”当たり前”はセキュリティ対策でないなら、無数にある仕様の中でセキュリティに関係する部分を集めた、つまり、こういう時にはこうすべきという”当たり前”を集めたセキュリティガイドラインすべてがセキュリティ対策ではない、ということになってしまいます。支離滅裂な論理であることは明らかです。
入力対策は国際標準において明白なセキュリティ対策で、
- その妥当性及び完全性を確認するために重要なフィールド又はデータファイルの内容の定期的見直し。
- 入力データに認可されていない変更があるかどうかについての紙に印刷した入力文書の点検（入力文書に対する変更はすべて、認可を得ることをが望ましい。）。
- 妥当性確認の誤りに対応する手順。
- 入力データのもっともらしさを試験する手順。
のようにセキュリティ対策として継続的に確認＆見直し（つまり管理）することが求められています。
セキュリティ対策はリスク対策として管理し定期的なレビューと見直しが必要です。セキュリティ対策かどうかはどうでも良い！とする議論も聞いたことがあるのですが、セキュリティ対策とは何か？理解していない証拠です。
基本的な部分で認識を誤っていると、基礎も作らず建てたビルのように不安定（つまり高リスク）なソフトウェアを作ってしまうことになります。
セキュアプログラミング／コーディングで一番の対策は入力対策です。つまりISO 27000での祖父トゥエアセキュリティの一番の対策が入力対策です。セキュリティ対策として実装していないと、SQLインジェクション脆弱性で訴訟となり契約書以上の賠償金を支払ったケースと同じリスクがあります。
入力対策は10年以上も前のセキュリティ標準から要求されているセキュリティ基本要素です。”私はセキュリティ対策とは考えていない”ので、は訴訟などでは通用しないでしょう。
現在のISO 27000はセキュアコーディング標準などを参照するようになっています。先ずは
を参考にすると良いと思います。
参考：
現在のISO 27000では「セキュアプログラミング技術は体系的にまとめられ普及した」として具体的なバリデーション方法を記載せず「セキュアプログラミング技術を採用すること」を要求しています。CWE/SANS TOP 25 Monster Mitigation（恐ろしく効果的なセキュリティ対策）の第一番目で解説されているバリデーションが必要です。
現在、ISO 27000で要求される入力バリデーションはCWE-20と言えます。
CWE-20は最も基礎的なセキュリティ対策と言えます。しかし、基本的に間違った形で理解されているケースが少くありません。
- ISO 27000の歴史を正確に記述すると長くなりすぎるので省略しています。 ↩
