武田圭史

６月１５日（金）に行った「未知の脅威に対抗する組織のセキュリティー力」と題した講演の概要が明日６月３０日（土）の日経新聞朝刊(全国)に掲載される予定です。

会場の制限のため抽選となってしまったようで、紹介しておきながら大変申し訳ありませんでした。
紙面の都合でざっくりとした内容になってしまうようですが、よろしければご覧ください。

新聞ですので紙面構成が変更になる可能性もありますのでその点ご了承ください。

(参考)
【講演】「見える化」と組織の「セキュリティー力」
http://motivate.jp/archives/2007/06/post_129.html

【イベント】日経Business Innovation Forum　－　「見える化」による情報セキュリティー整備
http://www.adnet.jp/nikkei/innovation/

タイトルのとおりセキュリティの数値化について書かれた本である。

組織における情報セキュリティとその管理活動における数値化の対象や手法について紹介している。数値化した後の具体的な分析手法等はほとんど触れられていない。投資対効果の数値化については著者はこれを否定する立場をとっている。

攻撃の発生回数と失敗と成功の回数を数えましょうなど、数えるべき対象をひたすら列挙しているようなところも多く、何か新しい発見があるというよりはこれまで漠然と言われていたことを数値化という切り口で整理しているにすぎない。

実務や研究にすごく役立つというわけではないが、セキュリティの数値化について触れている数少ない書籍なので紹介しておく。

■書籍
Security Metrics: Replacing Fear, Uncertainty, and Doubt
Andrew Jaquith (著)
Addison-Wesley
￥ 6,367　（税込）

※画像にはAmazon.co.jpへのアフィリエイトリンクが設定されています。

6月21日JPCERT/CCから「標的型攻撃について」と題したレポートが発表されている。このレポート自体はこれまで一部の事例のみが語られていた日本における標的型攻撃の実態について明らかにしたものであり、大変意義のある試みと思われる。（文中CSIRT協議会が登場するあたりは多少強引な感もあるが・・・）

この中でJPCERT/CCは英語の「Targeted Attack」に相当する表現として「標的型攻撃」という訳語を用いている。

“標的型攻撃”の呼び名について
“Targeted Attack”という言葉は標的攻撃、 スピア型攻撃、 スピアー攻撃、 ターゲッ
トアタックなど様々に翻訳されている。本文書では”標的型攻撃”という訳語を用いる。
この表現が比較的定着しており、 初見でも漢字から内容を類推することが容易と思
われるからである。

（「標的型攻撃について」JPCERT/CC, 2007/6/21）

これは、特定の組織等を攻撃対象として行われる「フィッシング攻撃」を意味する「スピアフィッシング攻撃」との混同を避け、「Targeted Attack」の正確な意味が伝わるように配慮がなされているものと推察される。実際同レポートでは「スピアフィッシング攻撃」について以下のような記載が行われている。

「たとえば標的となる組織に特化した差出人や文章を使ったフィッシングを”スピアフィッシング”というが、 これは限定度が高く、 検知が難しい標的型攻撃の1つである。」

（「標的型攻撃について」JPCERT/CC, 2007/6/21）

レポートでは標的型攻撃を「スピアフィッシング」「関係者を装った社員宛のウィルスメール」「『DoSをしかける』という脅迫メール」の３つに分類をしており、「スピアフィッシング」は「標的型攻撃」の一つのタイプとして位置づけられている。

ちなみに欧米では日本で言われるTargeted AttackはTargeted Trojan-horse attackまたはTargeted Trojan attackという形で使われることが多く、この場合「トロイの木馬」を用いた攻撃を意味する。「関係者を装った社員宛のウィルスメール」がTargeted Trojan-horse attackなのかどうかは不明だが、「『DoSをしかける』という脅迫メール」がTargeted Attackと呼ばれることは少ないように思う。

さて、このレポートの内容について日経IT Proが記事として紹介しているのだが、JPCERT/CCが「標的型攻撃」としている事項について、全て「スピア－攻撃」として言い直して記載している。また文中には、

「スピアー攻撃とは、特定の企業や組織を狙った攻撃のこと。標的型攻撃とも呼ばれる。」

（「『国内企業もスピアー攻撃の標的に』――セキュリティ組織が調査」, 日経IT Pro, 6/21）

とわざわざレポート本文とは逆順に用語の定義が行われている。JPCERT/CCが吟味した用語の用法が台無しである。日経IT Proでは過去に「スピア攻撃と闘う」と題した記事の中で、下記のように「スピア攻撃」という用語について明示的に使用の方針を示しており、社内での用語の統一を保つ必要からやむを得ないのかもしれない。

「特定のユーザーや組織を狙った攻撃」は，海外では「Targeted Attack」と呼ばれ，スピア攻撃（Spear Attack）と呼ぶのは日本だけである。しかしながら，国内ではスピア攻撃のほうが現時点では一般的だと考えられるので，本稿では「スピア攻撃」とする。

（「スピア攻撃と闘う」, 日経IT Pro, 2006/9/29）

もっとも「スピア攻撃」だったり「スピアー攻撃」だったりするのでそれほど厳密に意識しているわけでもなさそうだ。

最近のセキュリティ業界関係者の発言を聞く限りでは「スピア（ー）攻撃」という用語を単独で使用することはほとんど無く、大抵「ターゲテッドアタック」や「標的型攻撃」などの他の表現と合わせて使用されている。「スピア攻撃」が一般的というのは現在では当てはまらないのではないか。

そもそも誰が言い出したのか分からない「スピア（ー）攻撃」などという紛らわしい用語を使用しなければ、すっきりすると思うのだが、何かこの言葉を使用しなければならない特別な理由があるのだろうか？

（追記）ふと考えたのは、メディアでは「標的型攻撃」と書くよりも「スピアー攻撃」と書いた方がキャッチーで注目を浴びやすいという理由があるのかもしれない。

（参考情報）
■標的型攻撃について(PDF)（JPCERT/CC, 2007/6/1）
http://www.jpcert.or.jp/research/2007/targeted_attack.pdf

■「国内企業もスピアー攻撃の標的に」――セキュリティ組織が調査（日経 IT Pro, 6/21)
http://itpro.nikkeibp.co.jp/article/NEWS/20070621/275523/

■今週のSecurity Check（第177回） スピア攻撃と闘う(ITPro, 9/22)
http://itpro.nikkeibp.co.jp/article/COLUMN/20060922/248805/

■「スピア型攻撃」より「標的型攻撃」が良いのではないでしょうか？(武田圭史, 2006/10/2)
http://motivate.jp/archives/2006/10/post_102.html

■「スピア型攻撃」は日本独自の表現？(武田圭史, 2006/7/19)
http://motivate.jp/archives/2006/07/post_96.html

いつまでこんなことを続けるのでしょうか。
もういい加減終わりにしませんか？

御冥福をお祈りします。

これまでもそうでしたが、情報漏えいインシデント対応の際は当事者、関係者に対するケアも怠らないようにしなければなりません。
（たとえ本人が悪かったとしても、こういう事態は避けるべきでしょう。）

■ウィニーで児童の個人情報流出、男性教諭が自殺　千葉http://www.asahi.com/national/update/0608/TKY200706080265.html

白浜で行われているサイバー犯罪者サイバー犯罪関係者の集まりに来ています。

今年はメイン会場で無線ＬＡＮは提供されないのでしょうか？

メイン会場でホテルロビーのがばり５で入りますね。非常に怖い状態で犯罪の温床になりそうですが。

（参考情報）
■第11回　サイバー犯罪に関する白浜シンポジウム
http://www.sccs-jp.org/SCCS2007/

リバースエンジニアリングまつり第二弾予告です。

４月９日リバースエンジニアリングをテーマにしたワークショップを秋葉原にて開催いたしましたが、大変好評につきご参加いただけない方も多数いらっしゃいました。
前回はどちらかというとイントロダクション的な意味合いもあり、深く踏み込んだ議論までできなかったという反省点もあります。その一方で実際にリバースエンジニアリングを行うための具体的な手法を紹介して欲しいという要望も多くありました。

というわけで、さらに規模を拡大したリバースエンジニアリングをテーマにしたイベントを秋開催に向けて計画中です。

時期的には９月下旬から１０月上旬、２～３日程度、東京またはその周辺を予定

・チュートリアル
・招待講演
・公募講演
・パネルまたはＢＯＦ

といった構成を検討しています。

特に今回は公募セッションとして、リバースエンジニアリングに関する取り組み、ケーススタディ、ツール、テクニックなど関連のトピックについて発表いただける方を広く募集してみようと考えています。

８月中旬頃に締切、１ヶ月前に発表していただく方を決定できればと思います。ネタをお持ちの方、またお持ちでない方も時間がありますので、ぜひご応募いただけますようご準備のほどよろしくお願いします。

例によりあくまで予定ですので途中でぽしゃったり大きな変更があるかもしれませんのでご了承ください。その他イベントに対する御希望やご意見などもありましたら遠慮なくお寄せください。

(参考情報)
■セキュリティ・ワークショップ「情報セキュリティのためのリバースエンジニアリング」 (カーネギーメロン大学日本校)
http://motivate.jp/archives/2007/04/49ws.html
■4/9リバースエンジニアリングWSにお越しの皆様へ（武田圭史, 4/6）
http://motivate.jp/archives/2007/04/49ws.html
■2007/04/09 リバースエンジニアリングまつりのメモ(by yoggyさん)
http://www.sabamiso.net/yoggy/hiki/?2007%2F04%2F09+%A5%EA%A5%D0%A1%BC%A5%B9%A5%A8%A5%F3%A5%B8%A5%CB%A5%A2%A5%EA%A5%F3%A5%B0%A4%DE%A4%C4%A4%EA%A4%CE%A5%E1%A5%E2
■「リバースエンジニアリングまつり」レポート (by eagle0wlさん on Wizard Bible vol.33)
http://wizardbible.org/33/33.txt

ほかにもレポートがあったような気がしますが・・・御存じの方ご紹介ください。

６月１５日（金）に「未知の脅威に対抗する組織のセキュリティー力（りょく）」と題して講演をしますのでご案内させていただきます。

セキュリティにおける見える化の考え方、インシデント対応を含めたいまどきのセキュリティ対策の考え方、その他最近の技術動向などについてもお話したいと思っています。

後半の「内部統制時代の情報セキュリティーガバナンス」と題したパネルでは岡村久道先生、マカフィーの久我信さん、宮崎緑さんとご一緒させていただきます。どんな展開になるのか楽しみです。

【イベント】
日経Business Innovation Forum　－　「見える化」による情報セキュリティー整備
２００７年６月１５日（金）　１３：３０～１６：４５
会場： 丸の内マイプラザホール
参加無料
http://www.adnet.jp/nikkei/innovation/

私の前のエントリー「住民票コードはパスワードなのか？」という疑問に対して高木さんが大変示唆に富んだエントリー「続・住民票コードを市町村が流出させても全取替えしないのが標準となるか」をアップしてくださった。
この中で高木さんは

「私から言えることは、次のどちらかしかあり得ないだろうという指摘だ。

(A) 住民票コードは、本人確認用途として用いられることがない（と制定されている）ので、住民票コードが公開状態となっても問題ない（住所氏名と共に公開状態となった場合において）。
(B) 住民票コードは行政機関内で閉じて秘密でなければならない（よう運用されている）ので、住民票コードが本人確認用途として用いられることがあり得る。」

とまとめている。この点については私もそのとおりだと思う。

ここで日本国民として(A)、(B)のいずれを選択するのが合理的かという問題が生じる。この点において、私自身の考えは、リスク要素も加味した経済合理性の観点から言って(A)を選択するべきと考えている。

(B)を選択した場合に住民票コードが漏えいした場合本人になりすまされるリスクが発生するが、(A)を選択した場合にはそのようなリスクは発生しない。

一方、(B)を選択した場合のメリットは身分証明書を見せなくても１１桁の番号さえ言えば自分が自分であることを証明できるということだけである。裏返せば他人であってもこの１１桁さえ言えれば自分であること認められるわけであり、身分証明書を提示しないメリットと引き換えにするにはあまりにリスクが大きい。

(B)を選択する前提として住民票コードは行政機関内で閉じて秘密として運用されるという前提がある。現在でも行政機関内の個人情報は秘密として扱われているはずだが、実際の運用を考えるといくらか不安な点が生まれる。通常パスワードのような本人確認情報はその利用時において紙に書いて渡すという行為は行われないが、住民票コードは紙に書いて提示することが求められる。住民票コードを本人確認認証情報として取り扱うに十分なレベルの保護を行うには従来の事務手続きを大きく見直す必要がありそうだ。

本来の住民票コードの導入目的に事務処理の効率化があるはずだ。(B)を選択した場合には、住民票コードに対する秘匿の要求が高くなってしまうため活用できる業務に対しても活用が難しくなってしまう。その観点からも住民票コードを本人確認認証用途に使用することのメリットは小さく、デメリットが大きいといえる。特に今回のような情報漏洩が発生する度に住民票コードの総取替が発生し、住民基本台帳カードも全て再発行ということになるのであれば、それこそ「住民票コード利活用の発展は見込めない」ということになってしまう。（本来漏洩があってはならないのだが・・・）

最後に高木さんは

「仮に現存の手続きの全てを検討して、いずれも住民票コードを本人確認用途で用いていないと確認できたとしても、今後そのような手続きが現れないことを保証する、法令等による定めがない限り、一市町村が上記の(A)だと勝手に解釈して、流出した住民票コードの全取替えをしないと決定するのは許されるのか？」

との指摘をしており、当初のエントリーより高木さんのはこの点について問題提起をしていたと理解している。この問題に対する一つの案として、「住民票コード」の流出時に住民票コードの全取替を行う必要をなくすためにも、「住民票コードを本人確認認証用途で用いてはならない」という法的な規制を加えるのが合理的ではないか。また、そのような規制が行われるまでの間においては、「住民票コードを全取替する」よう要請するよりも「住民票コードを本人確認認証に使うことの危険性」について注意喚起をした方が効率が良く安全ではないだろうか。

（以下5/29　追記）
パスワード等を紙に書かせることを要求しない前提として「その利用時において」という記述を追加した。

本人を確認する情報のうち署名、および印鑑については利用時においても紙により提示することとなるが、これらについては複製に一定レベルの物理的な困難性を伴うことを前提とするためパスワードのような純粋な情報とは区別して議論する。

「本人確認情報」という用語は住民基本台帳法において本人の「氏名、生年月日、性別、住民となった年月日、住所変更の日（市内で変更があった場合のみ）、住民票コード」と定義されている。これは情報レベルにおいてある人物の情報が特定の人物の情報であると識別・確認するための情報として使用されるものと考えられ、ある人物に対して本人であることを確認するために告知を求める情報（パスワードのようなもの）とは異なる意味を持つと解釈している。本エントリー及び先のエントリーで「本人確認情報」という用語を使用していたがこれらは、上記後者の意味（パスワードのようなもの）として使用しており、住民基本台帳法でいる「本人確認情報」ではない。今後、ある人物が特定の人物（本人）であることを証明するために提示が必要な情報については認証情報として住民基本台帳法でいう本人確認情報とは区別する。

高木浩光さんが「住民票コードを市町村が流出させても全取替えしない先例が誕生する？」というエントリーを披露されている。ここでは、住基情報がWinnyネットワークに流出した事故に対する対応として、住民票コードをパスワードとして使用しているサービスが存在するので流出した住民票コードを全取替えすべきだとの主張をされている。

ここで「住民票コードはパスワードなのか？」という疑問が生じる。私自身はこの話を聞くまで住民票コードはパスワードであるという認識がなかった。

高木さんは「住民票コードの記載を条件に本人確認手続きを簡略化した行政手続きとしては、例えば以下などがある」として、「年金の裁定請求等における住民票コードの利用について, 社会保険庁, 2003年」の例をあげている。

一部の手続きにおいて、住民票コードを記載していただくことで市町村長の証明書等の提出を省略できるようになりました。

（略）これにより、一部の手続については、住民票コードをご記入いただくことで、本人確認情報を証明する市町村長の証明書等（戸籍抄本や住民票の写し等）の添付が省略できます。（略）」

この手続きでは、住民票コードの記載により「本人確認情報を証明する（略）戸籍抄本や住民票の写し等の添付が省略でき」るとしており、住民票コードの提示をもって本人確認そのものを省略するわけではない。本人認証が必要な場合は住民票（あるいは住民票コード）と身分証明書などをあわせて判断し本人確認を行うのが正しい運用ではないかと思われる。

(5/26追記)
年金の裁定請求においては「戸籍抄本や住民票の写し等」以外に「年金手帳または厚生年金保険被保険者証」や「年金加入期間 確認通知書 （共済用）」等の提出が求められている。
http://www.sia.go.jp/sinsei/nenkin/saitei/shorui.htm
(追記ここまで)

本来、戸籍抄本や住民票の写しは記載された本人に関する情報が正しいことを証明するためのものでしかなく、所有者自身が本人であることを証明するものではない。実際にそういう運用があったとすればそれ自体が問題である。つまり、「戸籍抄本や住民票の写し」はパスワードに相当するものではなく、住民票コードをもって「戸籍抄本や住民票の写し」の提出に代えられたとしても、住民票コードがパスワードとして利用されているとは言えないのではないか。

(5/26追記)
住民基本台帳法によると住民票の写しは本人・家族以外でも交付を受けることができる。
http://www.houko.com/00/01/S42/081.HTM#012
(追記ここまで)

私の理解では、住民票コードはコンピュータでいうユーザＩＤ（またはユーザ名）に相当する概念であり、対象者を一意に特定するための符号である。情報セキュリティの用語で表現すれば住民票コードは個人に対する「識別(Identification)」のための符号と言えるだろう。もちろんこの情報を使えば本人を一意に特定できるため、知らせないことで他人の悪用に対する敷居を高めることはできるが、それを知っているからといって本人と認証するには不十分である。

これに対して、一般にパスワードと呼ばれるものは、その情報を知っているということをもって他の手段で識別された本人が間違いなく本人であることを証明する「認証(Authentication)」のための符号である。通常パスワード登録後は、紙に書きだすことを求めたり画面に表示されことはなく、利用者に対して厳に秘密情報として管理することが求められる。

「識別」のための情報を「認証」に用いる誤った例としては、米国で社会保障番号がパスワードのように用いられている事例があげられる。また、クレジットカード番号についても本来、識別のための情報でしかないクレジットカード番号が本人確認の目的も兼ねて使用されている例があるのは適切な用法とは言えないだろう。クレジットカードについてはかつて所有者の署名を持って本人確認をしていたが現在では形骸化してしまっている。（これはクレジットカード会社がリスクを負いつつ、利便性やコストを優先しているわけで第三者がどうこう言う必要はないのかもしれない。）

話をもとにもどすと、「住民票コード」をパスワードととらえるのか、単なるユーザＩＤとしてとらえるのかによって、とるべき対応が変わってくるだろう。自治体によって異なるかもしれないが、おおむね制度運用側は「住民票コード」を「識別」のための情報としてとらえているために、大きな支障はないと考えているのではないだろうか。気になる住民は変更するための制度があるのでそれを適用すればよいという程度の認識なのだろう。

「住民票コード」がパスワードとして利用されているケースが実際に存在するのであれば、まず修正すべきはその「住民票コード」の利用方法ではないだろうか？米国の社会保障番号と同じ過ちは避けるべきだろう。また制度運用側に「住民票コード」を本人認証のためのパスワードとして利用してよいという認識があるのであれば、これについてのあらためる必要があるのではないだろうか？

（慌てて書いたので後で若干記述を修正するかと思います。5/23 10:00）
（テニオハや一部表現を修正いたしました。5/23 12:00）
（請求するときに必要な書類に関する記述を追記しました。5/26 11:30）

せっかく神戸にＣＭＵ日本校があって会場等使えるので、CMUJ提供のセミナーなどとは違ったオープンなセキュリティ勉強会を時々開催できればと思っています。

まずは場所やインフラを提供しますので、一緒に企画や運営からご協力いただければと思います。
近傍の方で我こそはと思われる方は、画面右上にあるアドレスまでぜひご連絡ください。

よろしくお願いします。