7PK – セキュリティソフトウェア ≠ ソフトウェアセキュリティ

(Last Updated On: 2019年2月4日)

CWE-700としても知られる7PK（7つの悪質な領域／王国）のIEEE Explorerの論文解説では、「セキュリティ機能（Security features）」はソフトウェアセキュリティではない、としています。

Software security isn’t security software. All the magic crypto fairy dust in the world won’t make your code secure, but it’s also true that you can drop the ball when it comes to essential security features.
ソフトウェアセキュリティはセキュリティソフトウェアではない。全ての魔法のような暗号などはあなたのソフトウェアを魔法の様に安全にはしない、不可欠なセキュリティ機能の場合では削除／省略することが不可能であることは事実だが。

暗号を例に「HTTPSがソフトウェアをセキュアにはしない」としています。これは暗号だけには留まりません。

※ 7PKとはソフトウェアセキュリティ全体を包括する7つの脆弱性分類を定義する論文です。実際には7つの領域＋1つ（環境）を定義しています。

7PKのセキュリティ機能（Security features）

7PKのセキュリティ機能（Security features）は認証／認可／暗号などのセキュリティ機能の脆弱性を意図した分類です。

特定のセキュリティ機能を使えば自動的にセキュアなソフトウェアになるのではない現実があり、「セキュリティ機能」では取り扱っていないセキュリティ領域にも注意しなければならない、としています。

7PKを注意深く読むと

Software security isn’t security software – ソフトウェアセキュリティはセキュリティソフトウェアではない

は暗号や認証／認可などのセキュリティ機能のみに適用されるモノではない、と解ります。

「セキュリティ関連API」も「セキュリティ機能＝セキュリティソフトウェア」と捉えることができます。7PKの悪質な領域の一つ、「APIの乱用」では、ざっくり言うと

APIの呼び出し側が呼び出される側の契約（仕様）を考慮せずに呼び出すこと
呼び出されたAPIが契約（仕様）とは異なる結果を返すこと

が問題となるとしています。

「APIの乱用」は頻繁に見られる間違いで、よくある間違いに

◯◯対策は△△API（＝セキュリティ機能）を使うだけで十分／完璧だ

があります。全ての”よくある”インジェクション対策に言えるのですが、SQLインジェクション対策を例に間違いであることを紹介します。

SQLインジェクション対策はプリペアードクエリ／プレイスホルダを使うだけで十分／完璧だ

これを聞いた事がない開発者は居ないと思います。しかし、これだけでは全く不十分です。

SQLクエリを作るには、プリペアードクエリ／プレイスホルダで無害化できるSQLクエリパラメーター、以外にSQL識別子やSQL語句も必要です。

SQLクエリパラメーターを正しく実行するにはLIKE句や正規表現、今時のDBならJSONやXMLといったデータがパラメーターになることも考慮しなければなりません。

それ以前に、クエリを送る側（＝APIの呼出側）がデータ（＝パラメーター）が妥当な値であるかバリデーションしていなければ、DBやDBアクセス用のAPIではエラーや不正入力を防止することが出来ません。

参考：

プリペアードクエリ／プレイスホルダは「SQLパラメーターの無害化を行う責任（契約）」だけを持っています。HTTPSが「エンドツーエンドの通信暗号化の責任（契約）」だけを持っていて、他に必要なセキュリティ機能に一切関知しないことと同じく、「SQLパラメーターの無害化を行う責任（契約）」以外の

入力データの妥当性保証（ ≒ データがアプリにとって無害であることの保証）
SQL識別子の無害化
SQL語句の無害化
パラメーターコンテクストでの無害化／妥当性保証（正規表現、JSON、XMLなどとして無害であるか？妥当であるか？）

などの必要なセキュリティ機能には全く役立ちません。

SQLインジェクション対策はプリペアードクエリ／プレイスホルダを使うだけで十分／完璧だ

としているセキュリティガイドや”セキュリティ専門家”が更に悪いのは

入力バリデーションの重要性を無視／軽視している

ことです。

7PKでは「入力バリデーションと表現」の領域として、データバリデーションが必須かつ重要であることを最初に明記していますが、

入力バリデーションはセキュリティ対策ではない／重要ではない／単なる仕様である

として「入力バリデーション」を無視しているセキュリティガイドまであります。このようなガイドは危険極まりないガイドであるのですが、中には長年堂々と公開されているモノもあります。その代表がIPAの「安全なウェブサイトの作り方」です。

”ソフトウェアセキュリティを理解しているセキュリティ専門家”が読んだら、噴飯物の出鱈目なガイド、ですが長年安全なWebアプリケーションソフトウェアのガイドとして公開されています。

まとめ

IPAのセキュリティガイドと言えば、ベストプラクティスやセキュリティ標準を十分に考慮したガイドである、と普通の人／開発者なら思うでしょう。

実際にはソフトウェアセキュリティの基礎の基礎から間違っているセキュリティガイドであるのがIPAの「安全なウェブサイトの作り方」です。

専門家や専門組織が基礎から間違ったことをまるで正しいことかのように解説する、こういった事は時々あります。騙されないようにするには何事でも、権威があるから、と鵜呑みにしないことが重要です。

セキュリティ機能を使う、ではソフトウェアセキュリティは作れない
APIを使うだけ、ではソフトウェアセキュリティは作れない

安全なソフトウェアを作るには、総合的／全体的に整合性のある対策が欠かせません。◯◯には△△”だけ／さえ”使えばよい、とするセキュリティ対策はほぼ全て不十分でダメな対策です。

ダメな例：

WAF”さえ”使っていれば安全なソフトウェアになる
プリペアードクエリ”だけ”使っていれば安全にSQLを実行できる
execv系（コマンドと引数が分離されているAPI）”さえ”使っていれば安全にコマンドを実行できる
自動エスケープするHTMLテンプレートシステム”さえ”使っていれば安全にHTMLを表示できる

数えだしたらキリがありません。

セキュリティソフトウェア（機能やAPI）は、ソフトウェアセキュリティに役立ったり、欠かせない物であったりしますが、”自分が作っている”ソフトウェアセキュリティはそれら”だけ”で確保できる物ではありません。そのソフトウェアを作っている開発者自身が責任を持って必要な対策全てを実施して、初めて必要なソフトウェアセキュリティを確保できるようになります。

開発フレームワークの機能”だけ”使っていれば良い
適当なAPI”さえ”使っていれば良い

更に悪いことに、セキュアなソフトウェア構築で最も重要な入力バリデーションを

入力バリデーションはソフトウェアセキュリティではない／重要ではない／単なる仕様である

と勘違いしているケースがほとんどです。これでは十分なソフトウェアセキュリティの達成は遠退くばかりです。

セキュリティ用のソフトウェア（≒コード）を使う ≠ ソフトウェアのセキュリティ

この認識は全てのソフトウェアエンジニアが意識している必要があります。7PK論文の全文はMITREがPDFで公開しています。CWE-700として定義されている7PKはCERT Secure Codingと同じく、ISO 27000(ISMS)/NIST SP800-171/PCI DSS/GDPRなどの情報セキュリティ標準／法規制の基礎知識として要求される知識の一つと考えられます。

参考1： ”個々に良い”とされている事を積み重ねても、全体最適化を考慮しないと”全体として悪くなる”ことは珍しくない

参考2：同じ”ソフトウェア”と言っても、”アプリケーション”は専用ソフトウェア、”ライブラリ”は汎用ソフトウェアであり”性質”が異り、”責任”が異なる。ユーザーが利用するソフトウェア全体（≒アプリケーション）としてのセキュリティを保証する責任は”アプリケーション”にはあるが、”ライブラリ”には必ずしもない。