皆さんこんにちは、川口です。われわれセキュリティアナリストはお客さまに忍び寄る脅威を見つけるために日々頭を悩ませています。そんな脅威と闘うアナリストを悩ませているのは、セキュリティセンサーから送られてくる情報のフォールスポジティブ（False Positive：誤検知）とフォールスネガティブ（False Negative：見逃し）です。
フォールスポジティブとは、見つけたい脅威とは違う事象が発見される状態です。フォールスネガティブとは本来見つけたい脅威が発見されない状態です。人が目を離したすきに警報を見逃すケースもフォールスネガティブに該当しますが、今回は脅威を発見し、警報を出すところに焦点を絞ります。脅威を分析するうえでは、フォールスポジティブとフォールスネガティブのどちらの発生確率もゼロになることが理想です。
シグネチャの考え方を銀行強盗に例えると
脅威を検知するための代表的な仕組みに、それらの特徴を収録した「シグネチャ」を使う方法があります。シグネチャによる検知手法は、アンチウイルスソフトやIDS／IPSなどに実装されています。今回は銀行強盗を例にしてこのシグネチャを使った脅威検知の考え方を説明しましょう。
では、監視カメラに写った特徴から、銀行強盗を発見する仕組みを作りましょう。あるときの銀行強盗の特徴は以下のものでした。
●マスクをしている
●サングラスをしている
●黒い服を来ている
●拳銃を持っている
この特徴を基にシグネチャを作ります。監視カメラを見る担当者は「サングラス」と「拳銃」を持っていたら銀行強盗と定義しました。このシグネチャを作ることでほかの銀行強盗が銀行に入ってきても速やかに対応することができました。
あるとき、銀行強盗は学びました。自分の特徴を変えたとしたら……？
●マスクをしている
●サングラスをしている
●黒い服を来ている
●ライフル銃を持っている（←ここが違う）
「拳銃」を持っていることが発見されているのではないかと考えた銀行強盗は「拳銃」を「ライフル銃」に変えて、銀行を襲いました。銀行強盗を発見するためのシグネチャは「サングラス」かつ「拳銃」という条件になっているため銀行強盗の発見が遅れてしまいました。この事象がフォールスネガティブです。
本来発見しなければならない強盗がシグネチャにマッチングしなかったために見逃す結果となってしまいました。このフォールスネガティブの確率を下げるために、担当者は「サングラス」をかけていた場合に銀行強盗とする条件のシグネチャに変更しました。その結果、「サングラス」をかけた強盗は拳銃でもライフル銃でもどちらでも発見されるようになり、フォールスネガティブの確率は下がりました。
しかし、今度はサングラスをかけている芸能人が警備員に拘束される事件が発生しました。この事象がフォールスポジティブです。シグネチャの条件が「サングラス」のみという緩い設定になっているため、フォールスネガティブの確率は下がりましたが、フォールスポジティブの確率が上がってしまいました。
この後、銀行の担当者は銀行強盗を発見するシグネチャを「サングラス」かつ「銃全般」と再定義しました。この結果、「サングラス」をかけて、「銃」を持った銀行強盗を発見できるようになり、フォールスポジティブの確率を下げることができました。銀行強盗はさらに「ストッキング」をかぶって、「拳銃」を持って銀行を襲いました。再び、銀行強盗を見逃してしまい、フォールスネガティブの確率が上がってしまいました。
脅威を検知するための対策（シグネチャ）が進歩すれば、その裏をかくように銀行強盗の手法も進歩します。
フォールスポジティブとフォールスネガティブの相関関係
このようないたちごっこを見ても分かるように、フォールスポジティブとフォールスネガティブは以下の図のような相関関係になります。
縦軸が確率、横軸がシグネチャ定義の精度です。フォールスポジティブの確率はシグネチャの定義を細かくすればするほど下がります。逆にフォールスネガティブの確率はシグネチャの定義を細かくすればするほど上がります。厳密には、グラフの角度は状況によって異なるため、あくまで上図は相関関係のイメージとしてとらえてください。
シグネチャのフォールスポジティブの確率を下げるため、シグネチャの定義を細かく行えば行うほど、フォールスネガティブの確率は上がってしまいます。問題はどのポイントを落としどころにするかということです。過剰なフォールスポジティブが発生してしまうシグネチャは発生したアラートに対応することができず、イソップ童話でいうところの「オオカミ少年」になってしまいます。逆にフォールスネガティブの確率が高い場合には本来の目的とする脅威を発見できなくなります。
アンチウイルスソフトやIDS／IPS製品は、シグネチャを作成する人とシグネチャのアラートに対応する人が異なっている場合がほとんどです。シグネチャを作成する人はシグネチャのアラートに対応する人を想定して、この（フォールスポジティブとフォールスネガティブの落としどころの）ポイントを見極める必要があります。アンチウイルスソフトの場合、パソコン初心者が多数利用しているため、発生したアラートがフォールスポジティブであっても正しく対処することができない場合が多くあるでしょう。そのため、アンチウイルスソフトのシグネチャは極力フォールスポジティブが発生しないように作られています（それでもちょこちょこフォールスポジティブは発生しているようですが）。
攻撃通信を遮断するための機器であるIPSも、フォールスポジティブが発生した場合、ネットワークの通信に影響を与えるため、初期状態ではフォールスポジティブが発生する確率が低いシグネチャ設定がされています。逆にIDSはアンチウイルスソフトと比較してフォールスポジティブが発生する確率が高いシグネチャが多数あります。ネットワークの通信へ影響を与えにくいことと、アラートに対応する人として比較的知識のある人を想定していることが影響しているのでしょう。
アンチウイルスソフトやIPSのシグネチャはフォールスポジティブの確率が低くなるように作られているため、フォールスネガティブの確率が高くなってしまいます。フォールスネガティブの確率を低くするために、脅威の手法別にシグネチャを作成し、フォールスネガティブの確率の高さをシグネチャの数でカバーしています。その結果、作成するシグネチャの数が多くなるため、開発のコストや機器のパフォーマンスに影響します。
セキュリティアナリストのアプローチ
われわれセキュリティアナリストは、脅威を発見できないフォールスネガティブが本当に怖いです。そのため、われわれがシグネチャを作るときにはフォールスポジティブの確率が上がることを覚悟して、フォールスネガティブの確率を下げるため、条件を粗くしたシグネチャを作ります。
われわれは「シグネチャの作者＝アラートの分析者」ですので、多少のフォールスポジティブが発生しても、そのフォールスポジティブを排除するわれわれの作業量が増えて困るだけであり、お客さまは困ることはありません。フォールスネガティブの確率を下げるために、粗いシグネチャを作成し、多数のインシデントを検知させます。そして検知したインシデントからフォールスポジティブを排除することで本当の脅威を発見します。例えるなら、目の細かいザルで多くの「疑い」を引っ掛けて、人の目の手作業で本当の脅威を見つける手法、“サハラ砂漠で砂金を見つける”そんな作業なのです。
当然のことですが、分析する人間が処理できないほどのフォールスポジティブを発生させることはお勧めできません。あくまで分析可能な範囲で設定することが重要です。クライアントパソコンで管理するアンチウイルスソフトであれば、一般ユーザーがインシデントを確認する場合も多いので、フォールスポジティブは少ない方がよいでしょう。逆に専任のセキュリティ担当者が確認できるのであれば、フォールスポジティブが多くなる設定で運用することも可能です。私たちセキュリティアナリストが監視するサービスは、単なるアラートの処理を行うセキュリティオペレーションではありません。その点が「マネージドセキュリティサービス（MSS）」と呼ばれるゆえんです。
セキュリティアナリストが開発したシグネチャのフォールスポジティブの確率がどの程度であるかは、実際にそのシグネチャを設定してみないと分かりません。テストの段階で過剰にフォールスポジティブを発生させるシグネチャは修正が行われますが、存在し得るすべての通信を想定して開発することはできません。シグネチャを設定したところ、特定の環境で過剰にフォールスポジティブが発生してしまうこともあります。このような場合には個別にチューニングを行い、対処します。
新しく作成したシグネチャのアラートを分析するユーザーはセキュリティアナリスト自身であるため、過剰なフォールスポジティブを発生させるシグネチャを作ったセキュリティアナリストにはほかのチームメンバーから苦情が寄せられます。
「何を狙ってこのシグネチャを作ったんだ？」
「このアラートはどう分析するんだ？」
この内部からの苦情が厳しいものであるため、アナリストは成長していきます。シグネチャ作成の能力は重要ですが、普段からのチーム内でのコミュニケーションが欠かせません。よって、セキュリティアナリストはチーム内の円滑なコミュニケーションのために今夜も飲みに行くのです。
Profile
川口 洋（かわぐち ひろし）
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
ラック入社後、IDSやファイアウォールなどの運用・管理業務を経て、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS／IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリスト兼セキュリティアナリストとして、JSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。
- 「DNS通信」記録していますか？――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは？
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた！
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ！
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は？
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか？ クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み？静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは？
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実：「検知できる」ってどういうこと？
- ところで、パッケージアプリのセキュリティは？
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.