Joint Workshop on Security 2008, Tokyo 1日目
Joint Workshop on Security 2008, Tokyo 開催記録サイト（資料は順次公開される予定）
3/25と3/26の2日間にわたってJoint Workshop on Security 2008が秋葉原で開催されている。これはFIRST TC（3/27-28）の開催に先立って行われる、一般参加が可能なワークショップである。（FIRST TCはFIRST加盟メンバーしか参加できない）
全てではないが参加できたセッションについて内容をまとめておく。キーノートスピーチを除くと発表時間が30分と少し短めなので、全般的にあまり突っ込んだ話はでなかった。
参考までに、午前中の様子はInternet Watchも伝えている。
セキュリティ担当者会議「Joint Workshop on Security 2008」が東京で開催
オープニングスピーチ -- 山口英（奈良先端科学技術大学院大学）
タイトルは "Efforts for building trustworthy information infrastructure in our society"。ICDF2008で聞いた話と大体内容は同じ。ということで省略。
最後の方で、「"Technical Expert"に求められる役割はなにか？」という話をされており、ソリューションの開発、分析、研究などだけでなく、非技術者とのコミュニケーションの重要性を強調していた。相手がわかる言葉で、相手のコンテクストでわかりやすく話をすることが求められている。
ちなみに、もうすぐプレスリリースがでるらしいが、来年のFirst Conferenceは京都で開催されることが決まったらしい。（2009/6/27-2009/7/4）
標的型攻撃と近年のマルウェアの分析 -- 鵜飼 裕司（IPA）
最近IPAから公開されたレポートの内容をはしょって紹介。プレゼンは「重要インフラ情報セキュリティフォーラム2008」のものとほぼ同じ。ということで以下省略。
インタードメイン・トレースバックシステムの概要 -- 櫨山 寛章（奈良先端科学技術大学院大学）、若狭 賢（Telecom-ISAC Japan)
攻撃パケットの追跡を行うシステムの紹介。NICTからの委託研究として実施している。仕組みは、AS内の境界ポイントにパケットキャプチャシステムを設置し、AS間で連携して追跡するというもの。トリガーとなる攻撃の検知自体はIDSベース。
最終的には実証実験を予定しているが、その前にStarBED上でエミュレーションテストを実施（2007/12-2008/01）。StarBEDというのはNICT北陸研究センターにある大規模なテスト環境のこと。
実証実験はISP間で実験専用のVPNを構築して行う（実トラフィックへの影響を避けるため）。ISPでトラフィックデータをミラーして実験ネットワーク側にデータを流す。なおどういう仕組みでトレースバックを行えば法的な問題が解決できるのかも検討しているところ。
実証実験では、まず模擬攻撃（シナリオ）で人間系の動きの検証を行う。その後、リアルな攻撃で検証する予定。また実験終了時にはデータが不正に利用されていないか確認したうえで、確実にデータ消去を行う。（法的な問題への対処）
今後のスケジュールは、事前実験をISP5社くらいで2008年10月-12月に実施予定。最終実験は参加ISPを増やして2009年6月-１2月に実施予定。（委託研究の最終年度にあたる）
我が国のボット対策について 〜サイバークリーンセンターの紹介〜 有村 浩一（Telecom-ISAC Japan)
https://www.ccc.go.jp/
ボット対策プロジェクトは2006年12月からスタート。現在68のISPが参加している。他にAVベンダーも。総務省と経産省の連携プロジェクトで、T-ISAC-J、JPCERT/CC、IPAが実際の活動を行っている。
CCCではボットに感染したクライアントPCを対象とした活動を行っている。ハニーポットを運用しており、ボットの活動を検知する。その後は2つのフローを実施する。
これまで48,000人にメールを出しているが、全員が対応してくれるわけではない。ツールをダウンロードしてくれるのは全体の30%くらい。ツールを実際に実行してフィードバックデータが返ってくるのは15%くらい。メール送信からツール実行までは平均して3日間〜1週間くらい。ツールの鮮度がある（ボットが変化する可能性がある）ので、1週間に1回の頻度でツールは更新している。CCCの活動の効果として、複数のISPで新規にボットに感染するユーザの数が徐々に減少してきているのが観測されている。
またボットの脅威のタイプが変わってきていることも観測されている。これまではワーム感染型（能動的に脆弱性の攻撃を行うタイプ）が大半だったが、最近はWebベース感染型（受動的な攻撃を行うタイプ）が増加している。
Webを介して感染するマルウェアの実態調査 〜クライアントハニーポットの運用〜 松木 隆宏（LAC）
CCCの研究プロジェクトとしてクライアントハニーポットを運用。名前は"Honey Whales"。その成果を紹介。
（参考）http://www.soumu.go.jp/joho_tsusin/policyreports/chousa/next_generation/pdf/071205_2_si2-3.pdf
ブラックリストに載っている10万のURLを2週間で巡回し、8,500のURLでマルウェアがホスティングされていることを確認した。これにより27,755のファイル、1,921種類のマルウェアを補足した。このうち70%（の種類）は未知のもの。既知のものではトロイの木馬が17%で最も多い。
(注：未知か既知かの判断はトレンドマイクロ社の1製品のみで判断している。)
ハニーポットの仕組みはシンプル。VMware上のWindows XPでIEを利用して対象URLを巡回。IEでアクセスしただけで自動的になんらかのバイナリがダウンロードされて実行される場合をMaliciousと判定。プロキシのデータやパケットキャプチャなどのトラフィックログ、VM内のログなどを取得して解析する。
マルウェア取得数で上位10種類の静的解析も実施している。内訳は、偽のセキュリティソフトが2種類、スパイウェアが2種類、残り6種類はダウンローダー（例えば、MPackに含まれている DreamDownloader）。ダウンローダー型の場合、多段のダウンロードを繰り返して最終的なマルウェアを落としてくるようになっており、検知が難しい。
Vulnerabilities and Incident Response in SCADA, DCS and Other Control Systems -- Dale Peterson (Digital Bond, US)
Digital Bond – For Secure & Robust ICS
Control Systemのセキュリティについての話。このようなシステムは大きく2つに分類される。
- SCADA: Supervisory Control and Data Acquisition (WAN)
- DCS: Distributed Control System (LAN)
シンプルな Control Systemの構成は3つの要素からなる。
Control Center <-> Field Device <-> Sensor&Actuators
この分野は少なくとも5年以上前のテクノロジで動いている（例えばWindowsNTや95がいまだに使われている）。以前は制御システムのネットワークはインターネットなど他のネットワークからは隔離されており、プロトコルも特殊なものが利用されていた。そのためサイバーセキュリティの問題とは無縁だった。ところが90年代に状況は変わり、Control CenterにPCが導入され、ネットワークに接続されるとデータをビジネスに利用しようというニーズが生まれた。セキュリティは全く考慮されていなかった。Control CenterにPCが導入されるにしたがって、Field DeviceもEthernetでつながるようになり、Ethernet上でToken Ringに似たプロトコルが実装されたり、TCP/IPでカプセル化したりした。
制御システムにおける主要なセキュリティ問題
- ネットワークセグメンテーション
- アンチウィルス
- パッチ
- 管理権限
脆弱性の例
- 異常系データについてのテストが行われていない（ネットワークのスキャンをしただけでシステムがクラッシュする）
- プロトコルの一部の仕様しか実装していない（プロトコル仕様に従ったパケットも適切に処理されない。ブロードキャストやマルチキャストなど）
Security Development Lifecycle(SDL)にも問題が多い。
- セキュアコーディングに注意が払われていない
- パッチを当てることができない
過去20年間にITの世界で起こった問題が制御システムでも今後同じように繰り返されると予想される。制御システムの世界は5年は遅れているため、IT分野のプロフェッショナルがいろいろと支援できることも多い。支援求む！
BGP route monitoring -- 松崎 吉伸 （Telecom-ISAC Japan）
BGP prefix hijacｋの問題についての話。最終的には新たなプロトコルの標準化が必要になるという議論が活発に行われているが、これには時間がかかる。まずは現状を認識するところから。
Prefix hijackingとは本来そのPrefixを広報する許可のない人が広報する事象。ただし実際に起こっている事象の大半は管理者のミスで起こる。
主要な問題
- black holing
- impersonation
- tapping
実際に最も観測されているのは black holing。
Prefix hijackの実際の事例。
2008年2月24日にYoutubeにアクセスできなくなったというケース。Youtubeでは 208.65.152.0/22という自分のルーティング情報を広報していたが、Pakistan Telcomが /24のprefixを広報してしまった（自国内からYoutubeへのアクセスをできなくするため）。しかし上位のISP（PCCW）がそれを誤って全世界に広報してしまった。Youtubeもこれに気づくとすぐに対抗して /24を広報したが、最終的にはPCCWが広報を止めるまで障害が続いた。この例では、自分がフィルターすべき経路を理解できていなかったり、prefixの広報が正しいのかどうかチェックしていなかったのが問題。
T-ISAC-Jでは「経路奉行」というシステムで、どの程度 prefix hijackingが起こっているか観測してみた。正しい経路情報データと、実際のISPからのデータの突合せを行う仕組み。正しいデータはInternet Routing Registry(IRR）のデータにもとづくもの。経路奉行では広報元のASナンバーとその広報している prefixに関する情報のみをチェックしている（そのため単純なミスは検知できるが、複雑の攻撃の検知は難しい）。検知精度を上げるには、正しい経路データを常に更新していくことが必要。JPIRRのデータをISP各社で更新するようにしている。JPIRRのデータは将来もっと信頼性があがっていくはず（データ更新元の認証とか）。
「経路奉行」では日本の大手ISP11社からのデータにもとづいて実環境で観測した。bogonデータ（本来広報されるべきでないもの。プライベートアドレスとか未割り当てアドレスとか）はかなり多く観測されている。prefix hijackと思われる事象も、2007年の半年で5件観測された。原因は管理者によるミスと思われる。観測後に対応しようとしている間に数分で直ってしまうことが多い。
検出システムの限界もわかってきた。ハイジャックがあるリージョン内に閉じてしまったり、どこかでフィルタされている場合には検出するのは難しい。また広報元のASを詐称されていたりすると検知できない。
今後はCJK（Chaina, Japan, Korea）で連携していくための話し合いが行われていく予定。
（参考）http://www.janog.gr.jp/meeting/janog19/2007/01/_meets_jpirr.html
Technical and Social Approaches Against Botnets -- Stephen Gill (Team Cymru, US)
ボットネットなど最新の脅威についての話。よく聞いていなかったので内容省略。
Activity Update in Japan
各チーム5分ずつくらいのアップデート情報紹介コーナー。
日本CSIRT協議会の活動紹介
- CSIRT間のベスト・プラクティス、ノウハウ、脅威情報などの共有を目的とした組織
楽天CERTの活動紹介
- 楽天グループ全体で 4,400万人の利用者、6万以上の店舗
- 昨年11月にCSIRTスタート
- Webサイトセキュリティの向上に貢献していきたい
カカクコムCSIRTの活動紹介
- 多数のコミュニティサイトを運営
- 2005/05/11 Webサイトがクラックされ、22,511人のメールアドレスが漏洩。Webサイトにマルウェアを仕込まれた。この影響で10日間サイトを閉鎖した。
- この事件をきっかけにして情報セキュリティ室が新設された。
- アドバイザーとして伊藤穣一さんと三輪さんにもはいってもらった。
- 2007年から、JPCERT/CCからのすすめでKKCSIRTを立ち上げた。
Telecom-ISAC Japanの活動紹介
- CCC WG
- BGP WG
- Traceback WG
- SoNAR WG
IPAのCSIRT関連活動紹介
JNSAの活動紹介
- PKI相互運用技術WG
- 脆弱性定量化WG
- セキュリティインシデント被害調査WG
ISEPAの活動紹介
