7PK（7つの悪質な領域 – CWE-700として定義されている業界標準のソフトウェアセキュリティ分類）では「セキュリティ機能はソフトウェアセキュリティではない」としています。明白なのは「他のソフトウェアやデバイスのセキュリティ機能によるセキュリティ」です。7PKでは例としてHTTPSを挙げています。
HTTPSは必要なセキュリティ機能ですが、HTTPSの利用＝ソフトウェアセキュリティ、ではありません。HTTPSを使って保護できる分野はありますが、HTTPSを使っても開発者が作っているソフトウェアのセキュリティを作る物ではないからです。
結局の所、他の”モノ”に頼らず開発者が作っているソフトウェアの中でセキュリティを作らないとソフトウェアは安全になりません。7PKの「セキュリティ機能はソフトウェアセキュリティではない」とは、「ソフトウェアセキュリティはそのソフトウェアを開発している開発者が実現する」ということです。
※ 7PKはソフトウェアセキュリティの基礎概念の一つと考えられています。 （CWE-700） セキュリティ機能を使うこと自体はセキュリティ対策になります。しかし、セキュリティ機能を使う＝ソフトウェアセキュリティ対策、にはなりません。「セキュリティ機能を使う」は「必要なセキュリティ対策」のサブセット（一部、それも極一部）でしかないからです。「セキュリティ機能を使う」＝「必要なセキュリティ対策」、こういった誤解が度々あるので7PKでは「セキュリティ機能」の解説として態々明示していると思われます。一言でいうなら「ソフトウェアセキュリティは”その”ソフトウェアを作っている開発者の責任に於て作るモノ」です。「◯◯、△△、を使えばOKではない」です。
HTTPS以外の「ソフトウェアセキュリティ」ではない例
HTTPS以外にも色々あります。例えば、
- スタックオーバーフロー検知＆防止
- データ領域実行禁止（DEP）
は現在のプログラム（コンパイラ／OS）では当たり前に利用されています。メモリを直接操作可能なC/C++プログラムでこれらの機能に頼り、メモリのオーバー／アンダーフロー仕放題のコードを書くのはソフトウェアセキュリティではない、と直ぐに理解ると思います。
ソフトウェアセキュリティ、特にアプリケーションセキュリティ、は開発者が作っているソフトウェアのセキュリティを開発者自身が書いたコードで実現しなければなりません。
- おかしなSQLクエリを送ってもRDBMSが問題を検知＆利用を防止
はしっかりとしたデータベース設計ではセキュリティ機能として動作します。出鱈目なクエリを送ってもデータベースでエラーになって実行＆保存できない、だからこれで自分が書いたソフトウェアのセキュリティが達成された、とはなりません。
スタックオーバーフローやDEPがソフトウェアセキュリティではない、と同様にSQLクエリを送信するソフトウェア（最終的にはアプリケーション）に出鱈目なクエリではない（＝妥当なクエリ）を送信する責任があります。SQLエラーになるからとそれに頼り、出鱈目なクエリ送信が可能になるコードを書くのはソフトウェアセキュリティではありません。ましてや出鱈目なクエリにより保存できてしまうのは論外です。
- おかしなHTTPリクエストが送られてもWAFが問題を検知＆防止
HTTPSやSQLクエリと同様にWAF（Web Application Firewall）の機能に頼った／頼ならければならない作り方もソフトウェアセキュリティではありません。OWASP TOP 10ではWebアプリケーションはWAFの機能のほとんど全てを実装しなければならないとしています。WAFを利用することはソフトウェアセキュリティではないのです。
「APIの乱用」もNG
7PKは「APIの乱用」もダメだ、としています。当然ですが、APIには仕様（契約）があり
- APIを利用する場合、仕様（契約）に則り正しく利用しなければならない
としています。例えば、SQLのプリペアードクエリは、SQLクエリ文とSQLクエリパラメーターを分離して実行する、仕様（契約）しかありません。このため、SQLインジェクション対策にはプリペアードクエリ（プレイスホルダ）さえ使っていればOK、としてコードを書くと「APIの乱用」になります。詳しくは次のブログを参照してください。
※ おかしな名前もAPIの乱用例として挙げています。一般にはAPIの仕様外（契約違反）の使い方がAPIの乱用です。
誰が7PKを利用／推奨しているのか？
WAFを「ソフトウェアセキュリティ対策」とはできない、と私が勝手に言っているのではありません。MITREでは7PKをCWE-700として定義しています。つまりソフトウェア／ITセキュリティの専門家集団であるMITREが昔から主張していることです。7PKは2005年に書かれた論文です。ソフトウェアセキュリティ専門家にとっては10年以上前からHTTPSなど、必要／必須のセキュリティ機能であっても外部のセキュリティ機能に頼るのはソフトウェアセキュリティではない、と定義しています。
現在のISO 27000ではセキュアプログラミング／セキュアコーディングが体系的にまとめられ普及した、としてセキュアプログラミング／セキュアコーディング技術の導入を要求しています。CERT Secure Codingは勿論、MITREのCWEも「体系的にまとめられたセキュアプログラミング／セキュアコーディング技術」の一つと考えられます。
ISMS（ISO 27000）は勿論、GDPR、NIST SP800-171、PCI DSSといった情報セキュリティ規格や法規制に対応するには7PKの概念は欠かせません。
IPAのおかしなWebアプリケーション構築セキュリティガイド
IPAの「安全なウェブサイトの作り方」はおかしなガイドラインになっています。
- ソフトウェアセキュリティガイドのはずの「安全なウェブサイトの作り方」の中で”ソフトウェア”セキュリティ対策としてWAF導入を推奨している
- 「安全なウェブサイトの作り方」はCWEを参照する形式で記述されているにも関わらず、MITREが恐ろしく効果的なセキュリティ対策とするCWE-20（入力バリデーション）の記述がない
- 「APIの乱用」がセキュアなアプリケーションの作り方だとしている
”ソフトウェア”セキュリティのガイドラインとしてはあり得ない解説であると言えます。
IPAの「安全なウェブサイトの作り方」の解説は、CWEのベストプラクティスのつまみ食い、になってしまっており実態／全体としてはアンチプラクティスになっています。セキュアなソフトウェア構築の基礎の基礎（セキュアコーディングの入力バリデーション/CWE SANS TOP 25/CWE-20、7PKの概念/CWE-700、など）を無視し、その上でWAFまでソフトウェアセキュリティの一部かのように解説していてかなりオカシクなっています。
OWASPが2017年版OWASP TOP 10でA10: Insufficient logging and monitoringを導入する際に一悶着ありました。その最大の理由はRC版OWASP TOP 10 A10の記述が
- まるでWAFの導入が必須であるかのような解説になっていたこと
でした。
私自身もRC版を読んだ時に「一応、開発者のアプリケーションで入力バリデーションを実装しなさい、とはしているがWAF導入を強く勧める解説になっており、WAF業者が大喜びしそうだ」と感じました。OWASPにも同じように感じたセキュリティ専門家が多数居たようで、「WAFの導入が必須かのようだ」と問題となりました。結局2017年版OWASP TOP 10のリリースを延期、プロジェクトマネージャーを交代して「WAF導入を勧めている」とは思わせない解説に修正され、4ヶ月遅れでリリースされました。
IPAの「安全なウェブサイトの作り方」はWAF導入の匂わせる内容どころか、WAFを「入力バリデーション機能」として利用できる仕組みとし、WAF導入を直接薦めています。
世界のセキュリティ専門家が見たら、噴飯物のソフトウェアセキュリティガイドである、と感じることは間違いないでしょう。少なくともOWASPやMITREの多くのソフトウェアセキュリティ専門家がそう思うはずです。
まとめ
IPAは出鱈目な”ソフトウェア”セキュリティガイドである「安全なウェブサイトの作り方」を長年公開し啓蒙し、多くのソフトウェア開発者が基礎的誤りがあるガイドを「正しく妥当なセキュリティガイドである」として利用しています。
日本のセキュリティ対策は10年は遅れている、と時々耳にします。全ての分野が10年遅れている、とは思いませんが、少なくとも公的ソフトウェアセキュリティガイドの分野では確実に10年以上遅れていると言えるでしょう。
参考：
類似の勘違いに「APIの乱用」があります。 APIレベルでも「セキュリティ用APIを使うこと」だけではセキュリティ対策になりません。
※ WAF導入が悪い、ということはありません。「ソフトウェアセキュリティではない」だけで「システムセキュリティではある」からです。ITシステムのセキュリティを考える場合、少なくとも4つの信頼境界を区別して考える必要があります。ソフトウェアのセキュリティとシステムのセキュリティはイコールではありません。”ソフトウェア”セキュリティを考えるべきソフトウェア開発者は基本的にWAFは無い物として作ります。一般にWAFはブラックリスト型のセキュリティ対策で、アンチウィルスソフトウェアによるセキュリティ対策と同じく、脆弱性な対策であることも理由の一つです。
