VAddyブログ - 継続的セキュリティテストへの道 -

VAddy Adventカレンダー18日目の記事です。

@vaddynet の中の人、西野です。

VAddyは開発者フレンドリーなWebアプリケーション脆弱性検査サービスです。 セキュリティの知識がなくても簡単にWebアプリケーションの脆弱性検査ができます。

いつもは開発者向けの内容ですが、今日は開発者以外の方向けの記事を投稿しようと思います。

まず初めに質問です。 皆さんの中で脆弱性検査を実施した／実施を指示した（された）ことがある方はどれくらいいらっしゃるでしょうか？

このブログに辿り着いた皆さんはセキュリティ意識の高い方々だと思うので、実施したことがあると答えられる方はそれなりにいらっしゃるでしょう。そういう方々にとっては今日の記事は退屈な内容になるかもしれません。

今日は「脆弱性検査」に馴染みのないスタートアップ経営者、マネージャー、サイトオーナー、Webディレクター、プログラマー、営業、投資家などの皆さまに向けた記事です。 

そもそもWebアプリケーションの脆弱性って何？

ひょっとしたら「脆弱性（ぜいじゃくせい）」という言葉より「セキュリティホール」という言い方のほうが馴染みがある方も多いかもしれません。
「脆弱性」とはWebアプリケーション（問い合わせフォームやショッピングカートなど）に存在するセキュリティ上の欠陥のことを指します。

何らかのソフトウェア／アプリケーションに欠陥があった場合「バグがあった」という言い方をしますよね？ 例えば「買い物かごに商品が追加できない」という事象が発生した場合「ショッピングカートのシステムにバグがある」と言います。 これはバグ（欠陥）のせいで本来できるはずのことができない状態です。

セキュリティ上の欠陥と言う以上、脆弱性もバグなのですが、こちらは本来できてはいけないことができる状態のことを指します。

例えば会員登録したショッピングサイトにログインする際に、ある一定の操作をすることで他人の買い物履歴が見れるとしたらどうでしょうか。これはそのアプリケーション（システム）にセキュリティ上の欠陥（脆弱性）があったために、できてはいけないことができて（他人の買い物履歴が見れて）しまっているのです。

そして、Webアプリケーションに脆弱性というバグがあった場合、個人情報の漏えいなど深刻な問題を引き起こします。

この章のまとめ
プログラムの欠陥（いわゆるバグ）
→できるはずのことができない状態

セキュリティ上の欠陥（脆弱性）
→できてはいけないことができる状態

脆弱性は発見しにくい

「脆弱性がバグの一種というのなら公開前に修正しないの？」

こういう疑問を持たれるのは自然なことでしょう。しかしながら脆弱性は通常のバグより発見しにくいという特徴があります。

通常のバグは「できるはずのことができない状態」と書きました。アプリケーションを開発する場合、要件として「何ができるか」が定義されます。ショッピングサイトであれば「会員登録ができる」「お気に入り登録ができる」「決済方法を選べる」などです。公開前の動作確認ではそうした要件に沿ってテストされるので、会員登録が「できない」といったバグは簡単に見つけられます。

一方、脆弱性が「できてはいけないことができる状態」であると述べましたが、要件に「何ができてはいけないか」が定義されることは多くはありません。最近ではセキュリティ要件として定義されるケースも徐々に増えてきているようですが、私たちがヒアリングした限りではまだまだ大多数とは言えないようです。その場合「できてはいけないことができる」といったバグの発見は困難になります。
例えば「この鍵を使って開けられる扉」という要件が定義されていたとしても、「ドライバーでは開けられない扉」と定義されていない場合、ドライバーを使った開扉テストは行われません。（これは異常系のテストと言われるものですが、私たちがヒアリングした限りではWebアプリケーションにおいて脆弱性に関する異常系のテストが行われることは少ないようです。）

また、脆弱性を発見してなんらかの不具合を発生させるためには特殊な操作が必要な場合が多いため、開発とは異なるスキルが必要です。ハイレベルな開発者はそもそも脆弱性を作り込まないための開発スキルを持っていますが、そうであっても規模の大きい会社では開発部門とは別のセキュリティ部門がサービスの公開前に脆弱性検査を実行していますし、そうでない会社でも外部の診断会社に脆弱性検査を依頼する場合もあります。

つまり、アプリケーション開発のスキルとセキュリティのスキルは別物であり、開発部門だけでは脆弱性をゼロにすることは難しいということを理解することが必要です。

この章のまとめ
脆弱性はその性質上、発見するのが困難
開発のスキルとセキュリティのスキルは別物

後回しにされるセキュリティ対策

脆弱性は発見しにくいがゆえに、対策にはそれなりのリソース（人、金、時間）が必要になります。 Webサイトの受託開発や少人数（ときには1人）で開発される新しいWebサービスにおいて、セキュリティ対策のための予算とスケジュールが確保されることは稀です。

最低限の機能を実装したベータ版をリリースした後にサービスを成長させていくというスタートアップ系Webサービスの場合、そこにセキュリティ対策が入り込む余地はありません。セキュリティ対策が後回しにされるくらいならまだましで、サービスがある一定の規模になるまで全く対策されない場合もあります。（もちろん業種にもよります。FinTech他、業務系のサービスのスタートアップでは最初からセキュリティが考慮されているのが普通です）

限られたリソースでプロジェクトを回していかなければならない以上、集客や機能改善にリソースを集中させたい「気持ち」は理解できます。けれども、スタートアップの皆さまは将来多くの利用者の支持を得られると信じて事業を行っているはずです。そうであるならば、今のうちからできる範囲で良いのでセキュリティ対策を行ってください。サービスの規模が大きくなってからだと対策にもお金がかかりますし、万が一事故が起きたら築き上げてきたものを全て失うことになりかねません。開発の早い段階で対策を取っておいたほうがトータルのコストは安くなります。

また、受託開発の場合でも、セキュリティ対策の不備に起因する情報漏えい事件について、開発会社への損害賠償請求がなされた判例が出ています。
参考記事：SQLインジェクション対策もれの責任を開発会社に問う判決

見積書にセキュリティ対策費を組み込むのは難しいとは思いますが、自分たちを守る意味でも可能な範囲で対策の提案をしていただければと思います。また、最近ではセキュリティ対策を行っていることが他社との差別化につながるという声も聞こえ始めています。

この章のまとめ
セキュリティ対策は早めにやっておいたほうが安くつく
セキュリティ対策を積極的に取っていることが自社のアピールポイントになるかも

セキュリティ事故での被害は甚大

近頃では情報漏えい事件が頻発しすぎて話題に上らなくなってきた感もありますが、直近の報道をまとめてみました。
※必ずしも「脆弱性」が原因となったものではありません

2016/10/3
東急ハンズの通販サイトに不正アクセス、カード情報など861人分流出か http://itpro.nikkeibp.co.jp/atcl/news/16/100302878/

2016/10/27
優良住宅ローンが顧客情報など3万7247人分を漏えいか
http://www.nikkei.com/article/DGXMZO08849300X21C16A0000000/

2016/11/27
自動運転のＺＭＰ、顧客情報流出　上場承認直後に
http://www.nikkei.com/article/DGXLZO09677710X11C16A1TJC000/
※その後、上場延期が決定されました。

2016/12/2
資生堂、最大42万人の個人情報流出か　岩井副社長が会見で陳謝
http://www.nikkei.com/article/DGXLASFL02HDW_S6A201C1000000/
※子会社のオンラインショップの脆弱性が原因とのこと

2016/12/15
米ヤフー、新たに10億人以上の情報流出　過去最大
http://www.nikkei.com/article/DGXLASGM15H14_V11C16A2000000/?dg=1
※今年の9月にも5億人の個人情報漏洩が発生しています

こうした現状を受け、経済産業省では「サイバーセキュリティ経営ガイドライン」を改訂しました。その中で「経営戦略としてのセキュリティ投資は必要不可欠かつ経営者の責務である」と明示されたそうです。

2016/12/8
「セキュリティはコストでなく投資」、経産省がガイドラインを改訂
http://www.itmedia.co.jp/enterprise/articles/1612/09/news055.html

本記事の内容を3行で

脆弱性というのはセキュリティ上の欠陥であり、バグの一種
脆弱性を発見するは簡単ではないけど、早めにやっておくべき
事故が起きたときの被害は甚大