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