Webアプリケーションが攻撃されるセキュリティ事故が相次いでいる。ログイン情報が盗まれたり情報漏洩につながったりする厄介な攻撃だ。今回からWebアプリケーション攻撃への対応策を解説する。対策製品は有用だが100%ではないため、3段階で痕跡を探し出そう。

 前回までは、マルウエア感染や内部不正など、社内で起こるセキュリティ事故(インシデント)対応について解説してきました。今回から、自組織がインターネットに公開するWebアプリケーションがサイバー攻撃に遭った場合のインシデント対応について解説します。

 Webアプリケーションは一般に24 時間365日稼働します。常に攻撃者に狙われている状態であり、いつ被害に遭ってもおかしくありません。事実、Webアプリケーションを狙ったインシデントが後を絶ちません。

 日本のインシデント情報を収集・分析するJPCERTコーディネーションセンターによれば、Webサイトが改ざんされたとする報告件数は2015年は減少傾向にあるものの、それでも月200 件程度あります(グラフ)。

グラフ Webサイトを狙った攻撃の推移
一定数で発生し続けるサイバー攻撃
JPCERTコーディネーションセンター「JPCERT/CC インシデント 報告対応レポート[2015年7月1日~2015年9月30日]」と 「JPCERT/CC インシデント報告対応レポート[2014年7月1日~ 2014年9月30日]」を基にリクルートテクノロジーズが作成
JPCERTコーディネーションセンター「JPCERT/CC インシデント 報告対応レポート[2015年7月1日~2015年9月30日]」と 「JPCERT/CC インシデント報告対応レポート[2014年7月1日~ 2014年9月30日]」を基にリクルートテクノロジーズが作成
[画像のクリックで拡大表示]

 インターネットバンキングのサイトやECサイト、オンラインゲームサイトなどのログイン情報を盗み取ることを狙ったフィッシングサイトや、マルウエア(悪意のあるソフトウエア)を配付するマルウエアサイトを設置されたとする報告は大きく増減することなく、一定数の被害が出続けています。

 これらは報告ベースであることからWebアプリケーションに関する実際のインシデント数はもっと多いのではないでしょうか。自組織で運営するWebアプリケーションへの攻撃を検知したり実際に攻撃に遭ったりした場合、CSIRT(情報セキュリティインシデント対応チーム)がどう対処すべきか。以下で具体的に解説します。