標的型攻撃に悩む管理者へのメッセージ。メールに添付されたパスワード付圧縮ファイル、HTTPS通信の危険性を再認識してみました。
（冒頭には解説になっています。２つの課題へ直接向かうにはこちら。）
セキュリティ担当者の悩み
「インターネットから、マルウェア感染をいかに防ぐか」という課題は、攻撃手法の発達と防御製品の世代交代という終わりなき戦いのことであり、セキュリティ対策費の継続的な増加という、セキュリティ担当者の悩やみの種になっている。
ここ数年でも、あっという間に新技術の波が押し寄せ、退いている
- ウィルス検出、ファイアウォール
- IPS
- UTM
- WAF（Web Application Firewall）
- 次世代ファイアウォール
- 標的型攻撃 専用対策
同時にこれらの提供形態も、オンプレミスでの物理アプライアンスから始まり、VMwareのような仮想基盤上で使う仮想アプライアンス、さらにはクラウド型へと変化が激しい。
（詳しくは、平成２６年版 情報通信白書 脅威の変遷 でご確認あれ）
もちろん製品の入替だけで済んでいたのは遠い過去のことであり、最新の対策製品を使いこなすには相応の技術スキルが必要で、情報システム部門が片手間で対応できるレベルではない。これは更に、運用委託のコストも必須ということである。
利益も生まず、どちらかという作業効率の低下を招くことが多いセキュリティ対策であるが、経営層を納得させコスト確保をして、攻撃へ対抗し続けている担当者は、実に報われていない人が多いのではないか。まずここで、せめてでも、彼らへエールを送りたい。
攻撃とその防御
新しい攻撃方法が開発され続けているが、意外と検査している対象は変わりがないのが、この分野ではないかと思う。対象は大きく３つの切り口になる。
◆流れてくるパケット
ソフトウェアの脆弱性を狙って、アプリケーションに異常な動作を引き起こさせることで、即攻撃となるケース。
対象は外部へ公開されているサーバー機能（OpenSSH、Apache、IIS）などがターゲットにされることが多い
（１）現状の対策 IPS専用機、UTM（IPS機能付）
攻撃の特徴をまとめたシグニチャーを定期的にメーカーから取り込む、もしくは準リアルタイムにメーカーのデータベースと比較することで、攻撃性パケットと類似しているか（パターンマッチング）行い、危険なパケットを破棄することで防御する仕組み。（主に、OSI参照モデルでいうレイヤー４での対策）
（２）現状の対策 WAF
Web系アプリケーションに特化した対策となるが、サーバーへのアクセスを、HTTP要求メッセージのレベルまで解析することで、不正なものを破棄することで防御する仕組み。（主に、OSI参照モデルでいうレイヤー７での対策）
◆受け取るファイル
メールの添付ファイルや、Webサイトからダウンロードされるファイルに、マルウェア本体やダウンローダーが仕込まれているケース
（１）従来から現在まで、主流の対策
ウィルス対策ソフトが、ウィルスの特徴を記述したデータベース（パターンファイル）と、検査対象を比較し、類似性が高い場合に、ウィルスと判定する方法。
ただし、近年はこの類似性の下げるために、ウィルス本体のパターンをファイル毎に変化させ（亜種）、パターン比較をすり抜ける技術が発達したため、有効性は８割程度まで低下しているという評価もある。
（２）ここ数年間で、普及してきた対策
検査を行うために用意した、本物のWindowsが動作している仮想マシン上で、実際に検査対象ファイルを、アプリで開く、もしくは実行するということを行い、そのアプリケーションがどのような挙動をするか検査する「動態解析」という仕組みが出ています。
実際に動作させることで、ウィルス固有の動作（たとえば、レジストリーへ自信の自動起動設定をする）など、よりウィルスを検出しやすくなっています。
◆文中に含まれるURL
受け取ったメールの文面や、Webページ内のリンク先など、それをクリックしたときに危険なサイトへ誘導され、攻撃が成立するケース（受動的攻撃）
現在の対策
リンク先の安全性を、準リアルタイムでデータベース化するという手法を、各セキュリティベンダーが行ったおり、リンクが文中に出てきた段階、もしくはクリック直前に、そのデータを利用して危険なサイトをブラウザー等のアプリケーションが開くことを阻止することで、防御する仕組み。
データベースの網羅性と、危険度判断の精度が重要となるため、メーカー毎に差が出る場合もあり。
また残念なことに、正常なサイトに対しても危険という判断がなされているケースもあり、過検知による業務影響を受けるケースもありうる。
マルウェア対策で忘れてはいけない「２つの課題」
暗号化された通信（HTTPS等のTLS）の問題
◆ファイルのマルウェアチェックができない
暗号化されているために、ダウンロードされたファイルが危険なマルウェアであるか、検疫することができません。
◆アクセス先のURIで、パスがチェックできない
FQDN（例：www.yahoo.co.jp）の部分までしか把握できず、パス部分（例：/news/2016/06/03/kiji.html）を確認することができない。
⇒対策
ゲートウェイ機器で一度、暗号通信を復号化して内容チェックを行い、再度暗号化してクライアントへ転送する手法となります。しかし、以下の課題が付きまといます
処理スピードの問題
復号化と再暗号化は、計算処理負荷が高いため、専用ASICを搭載した物理アプライアンスか、汎用CPUを用いる仮想アプライアンスの場合はスケールアウトさせる必要があります。
独自CA（認証局）証明書を信頼させる問題
再暗号化に使う証明書は、独自CA（認証局）証明書で署名されたサーバー証明書に置き換わります。そのため、事前にOSやブラウザー、アプリケーションで、その独自CA証明書を信頼するCA（認証局）リストへ登録しておく必要があります。
Windowsでは、コンピューター・アカウントの証明書ストアに登録することで、IEや標準的なブラウザーは信頼するように一括設定できます。しかし、Java Runtime Environment、FireFoxなどは独自の証明書ストアを持っているため個別に設定を行う必要があります。
Linuxに関しては、各コマンドで独自証明書を信頼するように設定する必要があり、非常に煩雑です。
パスワード付き 暗号化ファイル の 問題
◆ファイルのマルウェアチェックができない問題
通信レベルで暗号化されていないケースでも、ファイル自体を暗号化されている場合は、やはりマルウェアを含むかのか検疫ができません。
つまり、日本企業の多くで定着している「ファイルをパスワード付で暗号化・圧縮してから、メール添付する」という手法は、社内に入ってくるメールの添付ファイルに対して、マルウェア検疫ができないという結果になっています。
今もっとも増加している、メール添付ファイルを足がかりにした標的型攻撃に対して、非常に対策がしづらい状況を作り出しています。
⇒対策
暗号化されたファイルを受け取らない運用が採用可能であれば、別途ファイル交換の仕組みを用意して、暗号化などの理由でマルウェア検疫ができないファイルは破棄する仕組みを構築することが望ましいでしょう
その他考慮点
◆処理できる最大ファイルサイズ
ファイルに対する検疫を行うセキュリティ対策製品は、検疫可能なファイルサイズの上限があることが多いため、その能力を確認する必要があります。
また検疫に関しても、大きく２つ方式があります。
ネットワーク上を流れる状況のまま（ストリーム）を対象に検疫する方式
パケットの断片を逐次パターンマッチングすることで、マルウェアの特徴を探す方式。処理できるファイルサイズ上限が比較的大きい反面、パケットの断片を対象とするために検出率が低下する傾向がある。
製品内部に一度蓄積してから検疫する方式
製品内部メモリーもしくはディスクに一度ファイル全体を蓄えた上で検査を行う方式。処理できるファイルサイズの上限が比較的小さいが、ファイル全体を対象とするため、パターンマッチング精度はストリームに対して処理するよりも高まる傾向にある。
また、最近の動態解析方式（仮想マシン上で、実際に実行する方式）は、基本的にこの方式でしか実行できない。
◆滞留時間
製品内部に一度蓄積してから検疫する方式では、蓄積（バッファリング）するための時間が発生するため、ファイルサイズが大きい場合は、数分～十数分とかなり長時間の滞留が発生する。
（そのためWebブラウザーが、セッション・タイムアウトを発生させないように、少しづつパケットを流す処理が組み込まれていることが多い）
また、最近の動態解析方式（仮想マシン上で、ファイルを実行して検査する）では、滞留時間が長くなる。
これは、マルウェアが検疫をかいくぐるため、しばしば待機をすることへの対抗策であり、避けることができない。
製品によっては、予備的な検疫でマルウェアの可能性があるものを選別し、その上で動態解析を行うという方式をとっている。
＜免責＞
本記事は、個人の意見であり、一般的なセキュリティ管理の指針を示すものではありません。参考意見として、ご覧いただけますようお願いいたします。