脆弱性報告の多少はソフトウェアの安全性の指標にはならない
いや,今更こんなこと言うのもどうかと思うけど,いまだにこんなことを言ってくさる記事があるのですよ。
ちなみに Chrome がトップなのは驚くに値しない。 Chrome(というか Google)はここ1,2年くらいセキュリティ脆弱性の改善に努めていて,昨年の500を超える脆弱性報告はその成果と言えるものだ(しかも内容もメモリリークに関する軽微なものが多い)。
「スノーデン以後」の現在において,ソフトウェア分野ではセキュリティ脆弱性の改善が急務になっている。 セキュリティ脆弱性を放置しておくことは企業の機密や個人のプライバシーにとって直接的な脅威になり得るからだ。 昨年大騒ぎになった HeartBleed も ShellShock もそうした動向のひとつとして捉えることができる。 つまり現時点においてセキュリティ脆弱性の報告が多いことは,歓迎すべき事態なのである。
むしろ問題なのは,発覚したセキュリティ脆弱性に対してどうアクションをとるか,つまり security incident responce の良し悪しである。
これに関連して最近面白い記事が出ている。
この記事では米国 NIST の NIST Cybersecurity Framework(CSF)を紹介している。 CSF は従来のセキュリティ対策フレームワークである SP800 シリーズの後継にあたるもので “Respond & Recover”までカバーしてるのが特徴らしい。
「サイバー攻撃はブロックできない」ということは,セキュリティはハザードではなくリスクで考えなければならない,ということである。 そしてリスクは系(system)全体で最小になるように最適化されなければならない。 水際対策にお金をかけすぎても駄目ということだ。 (まぁ私はずうっと前から「セキュリティはリスク」だと言ってるけどね)
この話はベンダ企業というよりユーザ(個人や企業・組織を含む)寄りの話だが,ユーザがセキュリティをリスクの観点で「運用」するのであれば,ベンダ企業は今よりもっと incident responce に気を使う必要がある。 駄々をこねてモラトリアムを主張すべきではないし,ましてや自分の OS は安全だからストアからセキュリティ対策アプリを削除するなんて愚の骨頂である。
こういう企業の言動を私たちはちゃんと覚えておくべきである。