川口です。少々遅くなりましたが、皆さんあけましておめでとうございます。このコラムを皆さんが見ているころは2008年が過ぎ、2009年になっていることでしょう。皆さんにとって2008年はどのような年だったでしょうか。金融危機だ、不況だと騒がれているこのご時世ですが、いまもこうしてコラムを書くことができていることが私はうれしいです。
私は2008年の3月からこのコラムを書き始めました。このコラムを書き始めて知ったことはメディアのすごさです。自分が思っている以上の人がコラムを読んでいることがとても衝撃的でした。初めて会うお客さまや同業者の方に、
「川口さんは今日も飲みに行くんですか?」
と質問されることもしばしばあり、影響力のすごさを体感している今日このごろです。このような質問をされるついでに、
「お酒は飲める方なんですね?」
といわれることも多いです。毎回コラムでお酒の話を書いていますが、これは答えるのが難しい質問です。飲めないわけではありませんが、強い方でもないような気がします。しかし、これだけ飲みに行っているのを知っている人には「飲めません」とはいいにくいので、日本人の必殺技「笑って流す」を使っています。
同じように答えにくい質問に、
「料理できるんですか?」
というものもあります。これも答えることが非常に難しい。
「まったく料理ができないわけではない」
「ある程度の料理なら本を見ながらできる」
「それでも人さまにお出しできるようなものは作れない」
「そもそも最近料理をすることが少なくなった」
などと考えています。質問した本人にとってみれば何かの会話のきっかけ探しであることも多いのですが、意外と回答に困る質問です。
それ、検知できますか?
お酒や料理の質問と同様に答えることが難しい質問は、
「○○の攻撃(or通信)はIDS/IPS/WAFで検知できますか?」
というものです。セキュリティアナリストという職業柄、新種の攻撃やボットなどをファイアウォールやIDSなどで検知ができるか、というご質問をよくいただきます。この質問に答えるのが毎回気を使います。お仕事ですから、お酒の質問のように笑って流すこともできません。このような質問の集積が製品やサービスの機能表に書いてある○×表です。
まったく検知できないものに関しては説明ができるので×を付けることはたやすいです。例えば盗聴行為のようなものはネットワークに通信が流れないため、IDS/IPSなどで検知することは非常に難しくほとんどの製品で×とされているでしょう。できないことを説明することはたやすく、このような通信に関して問題になることはほとんどありません。
また、バッファオーバーフロー攻撃やSQLインジェクション、バックドア通信などの「悪意」のある通信は○が付けられているでしょう。これらの攻撃は技術的には手の込んだ手法を行うことでIDS/IPSなどの検知機能を回避することはできますが、そのような攻撃が行われることは多くはありません。「一般的に行われるような手法としては検知可能」として○の意味をとらえておけば十分でしょう。この点については製品メーカーによって検知能力に若干の差はありますが、ほとんど問題になるレベルではありません。
一番問題となるのは、○とはなっているものの実際には検知が難しいものの場合です。例えば、スプーフィングやブルートフォース攻撃、DDoS攻撃などのような「異常」を検知する場合です。これらの検知について○とされている場合もありますが、IDS/IPSで検知するのはとても難しいのが現状です。これらの「異常」な状態を検知するためにはその機械が「正しい情報」を知らなければなりません。この「正しい情報」を定義できるのは人間だけであり、機械に判断させるのは難しいことです。
製品やサービスの機能比較表に書いてある○×の裏には技術的な思惑と営業的な思惑が隠されています。営業的には少しでもできれば○と記載してあります。もしも技術的な観点から×と記載してしまった場合、その×が書いてある機能で競合製品に負けてしまうかもしれません。つまり、まったくできないことには×は書いてあるが、少しでもできることとほぼできることの両方が同じ○で書いてあるということです。機能比較をする際に、どうしても必要な機能に関してはどの程度の精度なのかを確認する必要があるでしょう。
○×表で判断するよりも先に考えるべきこと
このように単純な○と×で考えてしまうと、大事なことが見えなくなってしまうことがあります。かといってすべての事象に対して100点満点で採点することも現実的ではありません。攻撃の手法や難易度、悪用のしやすさなどは日々変化しており、それらに追従し、更新し続けるコストも膨大なものになってしまうからです。
一番大事なことは「何を発見(検知)したいのか?」を明確にすることです。この点を明確にしないままセキュリティ機器を使っている例も多数ありますが、その機器を導入することになった理由は必ず何かあるはずです。「システムへの不正アクセスを見つけたい」「サーバが止まるような攻撃を発見したい」などの本来の目的に照らし合わせて、機能比較表を眺めてみてください。
次に「検知できて何をするのか?」ということを考えてください。「ただ何となく検知したい」という組織もたくさんあります。「アラートが上がれば、そのアラートの説明文に何か書いてあるだろう」と期待することもほぼ間違っていないのですが、それだけでは足りません。例えばあるアプリケーションの通信を検知するアラートが上がった場合は「このアプリケーションの利用がセキュリティポリシーで禁止されているかどうか」が対処する基準になります。対処できない、または対処しない事象のためにアラートを上げ続けるのはリソースの無駄です。
つまり「ただ何となく危険な事象を検知したい」というのは組織のリソースを無駄に浪費するだけです。対処するべきインシデントと対処する必要のないインシデントを組織で定義し、そのインシデントが発生した場合の対処方法を定義しておきましょう。この定義を行うためには各企業の担当者の方が自分で行うしかありません。この定義を他者に依存しないためにも、担当者の学習が必要になってきます。このコラムで書いていることが、少しでも担当者の方の情報収集の一助になればと願って今年も書き続けていきます。
先日、友人と忘年会と称して、婁熊 東京(るくま とうきょう)というもつ焼きのおいしいお店で飲んでいました。そこで友人の友人が、
「おれは昔、椎名桔平に似ているといわれていた(そしてモテるんだ)」
と豪語していたという話を聞きました。写真を見せてもらうと確かに髪型は似ていましたがお世辞にも似ているとはいえないようなと思ってしまいました。そこで思い出したのが今回のテーマ「検知できますか?」。このケースも似たようなものなのでしょう。少しでも似ているポイントがあれば○×表で○を付けて自分を売り込むというのも日常的に見ることができる光景ですね。
2008年の12月も忘年会ラッシュでした。これだけお酒を飲む日が続くと冒頭の質問に○を付けざるをえない状況であるとはうすうす気付いていました。忘年会ラッシュを乗り切った私は新年会と称して、今夜も飲みに行くのでした。
Profile
川口 洋(かわぐち ひろし)
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
CISSP
ラック入社後、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.