しかし、Webサイト改ざんの報告は止まらない。これはあくまで一例でしかないが、2014年8月26日には日産自動車の「下取り参考価格シミュレーション」サイトに改ざんが見つかっている。
日産のWebサイトで改ざん見つかる、発覚まで約2カ月も(ITmediaエンタープライズ)
http://www.itmedia.co.jp/enterprise/articles/1408/26/news125.html
本記事執筆時点で日産自動車は現在原因を調査中としているが、分かっているだけでも2014年6月30日午前4時21分〜8月22日午後11時22分までの約2カ月、Webが改ざんされていたことが分かっている。この事件は、Webサイト改ざんの「検知」自体が難しい現状を語っている。
実際にWebサイトを管理している方ならば、この理由はよく分かるだろう。実際に稼働しているWebサイトにおいて、改ざんの検知は能動的にチェックを行わない限り、分かりようがないというのが現実だ。静的ファイルしか置いていないサイトであったとしても、もし管理端末に侵入したマルウェアがそっとJavaScriptを書き換えたとして、気付けるような体制がとられているだろうか。ここにWeb改ざん対策の難しさがある。
Webサイト改ざんの対策においては、攻撃を受けた後、改ざんに気付く仕組みがあるかどうかを確認すべきだ。さらには、攻撃を受けマルウェアに感染したあと、いかにして次の攻撃ステップへの移行を止めるかという観点での防御を考えたい。
Web改ざんに関していえば、多くのベンダーが「Webサイト改ざん検知ソリューション」を持っている。オンプレミスの装置だけでなく、現在ではインターネット側から検知をチェックするクラウド型のサービスもある。対象となるページの多さ、リスクの大きさで正しい対応方式を選択したい。すでにソリューションを導入している企業は、その検知対象範囲が正しいかもこのタイミングで再度精査するといいだろう。
改ざんのリスクを最小限に抑えるには(前編)(@IT)
http://www.atmarkit.co.jp/fsecurity/vagabond/rewrite03/rewrite03.html
改ざんのリスクを最小限に抑えるには(後編)(@IT)
http://www.atmarkit.co.jp/fsecurity/vagabond/rewrite04/rewrite04.html
万が一侵入された時のために、Webサーバーの設定の改ざんチェック、SSLサーバー証明書の再取得フローのチェック、およびSSLサーバー証明書の入れ替えの手順がまとまっているかも併せて確認したい。現在、企業内においてシーサート(CSIRT: Computer Security Incident Response Team)の設置が進んでいる。Webサイト改ざんに対抗、対応するには、事故が発生する前提での組織作りや訓練も必要だろう。
現在、多くのセキュリティベンダーが「ウイルス対策は死んだ」と発言し始めている。これは検体取得、解析、パターンファイル作成、配布といった、シグネチャによるマルウェア検知の限界を表している。この発言は、時代とともに変化する防御手法について「エンジニア側の知識もアップデートせよ」というシグナルだと受け取るべきかもしれない。
いま一度、自社にあるセキュリティ機能を棚卸ししてほしい。足りない部分に対しては、各社が出す改ざん検知ソリューションやIPS、IDS、WAFの機能を知り、効果的に組み合わせることを検討したい。最後にIPAなどが提供する各種リソースへのリンクを掲載する。まだ未見の資料があればぜひ参照してほしい。
よくある相談と回答(FAQ):ウェブサイト改ざん対策
https://www.ipa.go.jp/security/anshin/faq/faq-webfalsification.html
Webアプリケーション制作前に参照したい「安全なウェブサイトの作り方」
http://www.ipa.go.jp/security/vuln/websecurity.html
機器の脆弱性情報を見る「JVN iPedia」
http://jvndb.jvn.jp/index.html
脆弱性体験学習ツール AppGoat
http://www.ipa.go.jp/security/vuln/appgoat/index.html
Copyright © ITmedia, Inc. All Rights Reserved.