「悪用可能なバグ（欠陥）」とは
2005年頃からSQLインジェクションの攻撃が多用されはじめたそうだが、著者のブログでも、本書にあるようなセキュリティ対策の漏れに対する裁判が例が紹介されている。それはオンラインショップによる事例で、ご多分に漏れずクレジットカードの情報が漏洩してしまったという。そのショップのシステムでは、データは暗号化されずにデータベースに保存され、SQLインジェクションの攻撃によって顧客情報が漏れてしまった。ショップ側は開発会社を訴え、裁判の結果はショップ側が勝訴した。
ウェブアプリケーションのようなシステムにおいて脆弱性という言葉は、本来的な欠陥として捉えられてきた。例えば、クロスサイト・スクリプティング（XSS）やSQLインジェクションはいわゆるウェブ・アーキテクチャそのものに内在しているような欠陥である。それはプログラミング過程におけるバグとは違う。しかし、開発の側でセキュリティ対策がしっかりと行われていれば100%までとは言わないが、外部からの攻撃には対処することができる。つまり開発過程の中で「セキュリティに対する認識不足そのものがバグである」として捉えることができる。上述した裁判の例もこのような視点から判決が下された。著者も言うように「悪用可能なバグ（欠陥）」がショップのシステムにはあったということだ。もはや脆弱性という言い訳は通用しない。
セキュリティの境界は常に揺らいでいる
暗号理論の発展はインターネットの拡張と密接に結びついている。昨年から話題のFintechにおける仮想通貨も暗号技術そのものがアプリケーションの中に組み込まれている。機械学習のような処理もクラウド上で行われ、APIのような形でデータを活用できるようになってきた。IoTとしての機器も増えれば、今後ますます「悪用可能なバグ（欠陥）」としての問題が顕在化してくるだろう。
セキュリティに対する考え方も更に複雑化してくるのは必至で、そこには人間の行為としての意味が問われることになるだろう。
例えば本書で説明するようなパスワードの例が分かりやすい。パスワード破りとしては、ブルートフォース攻撃、つまり総当たり攻撃という典型的な手法があるが、これはシステムの脆弱性における問題なのだろうか？ 本書で主に取り上げられているのは、日本航空（JAL）や全日空（ANA）で起きた不正ログインの事件だが、これは単純にJALは6桁、ANAは4桁という弱いパスワードによるアーキテクチャにおける問題だった。つまり、システム自体における「悪用可能なバグ（欠陥）」であった。
ただ、もし情報が漏れていた原因が、ユーザが単純に推測できるパスワードを設定していたり、そもそもパスワードを紙に書いてどこかに置き忘れていたらどうだろう？ 著者も言うように、それは明らかに脆弱性でもなければ、悪用可能なバグでもない。ユーザ個人の問題なのだ。もちろんアーキテクチャの設計として個人認証を更に強化していくという流れもある（ポストパスワードとしての生体認証等）。しかし、たとえ悪用可能なバグを認識していたとしても、解決できない問題はまだまだたくさんあるのだ。これはユーザに対する教育でしか解決しない。
ネットが生活に組み込まれるほどに、セキュリティの境界は曖昧となっていく。またその概念も更に拡張されていくことだろう。どこまでがアーキテクチャで対応できる問題なのか？ どこからがユーザの責任になるのか？ そのようなセキュリティの曖昧な境界に対する思考は、事件の後にしかやってこないのであろうか。
参照ページ
独立行政法人 情報処理推進機構 セキュリティセンター
著者である徳丸浩氏のブログ
