wakatonoの戯れメモ このページをアンテナに追加 RSSフィード

たわいもないこと(日々の妄想とも言う)をつらつらと書いてます。断じて壊れメモではありません。ましてや「穢れメモ」でも爛れメモでもありません(涙)。
が、時により一つのことを掘り下げる傾向が見られるので、article数は少ないカモ。
ちなみにSlashdot Japanの日記もあります。個人的な連絡がある方はwakatono@todo.gr.jpまで("@"は2バイト文字になってるんで、てけとうに書き直してください)。GnuPG公開鍵はこちら

他のあたり:PFSEC - Systems Platform and Securityアマゾンのレビュー

強いWindowsの基本 WebDAVシステム構築ガイド(萌えバナーその1)
WebDAVシステム構築ガイドの方のバナーの絵柄は、内容とは何の関係もありません(汗)
アクセス探偵IHARA

おとなり日記はこちら

2009-01-26 風邪っぽい?ミョーにだるい

また別モンの病原体もらった?(汗)

[]あちこちで漏洩が発生してますが、対応時に見落とされがちなこと あちこちで漏洩が発生してますが、対応時に見落とされがちなことを含むブックマーク あちこちで漏洩が発生してますが、対応時に見落とされがちなことのブックマークコメント

情報漏洩の際に、「漏洩した情報に掲載されている内容」で影響を受ける人や、漏洩した情報をもとに引き起こされる事象(想定される事項)に対応するってのは、(普通に)行われます。これがされないのは論外としても…

見落とされがちなのは「つこうた当人」のフォローアップ(つこうた場合ね)。

こうした場合、どうしても「漏洩させるやつが〜」という文脈になりがちなのですが、一般的にインシデントを発生させた人(つこうた人)に話を聞くと、「漏洩させてやった」という人は出てきません。ほとんどが「こうなるとは思ってなかった」というところです*1

一般的に、脆弱性を突かれてコンピュータを攻撃され、そのコンピュータを攻撃に使われた場合には、そのコンピュータ(の利用者)は被害者であると同時に他者への加害者にもなってしまう、という事故の特性を持ちます。

暴露ウィルスによる情報漏洩の場合も一緒で、つこうた人は「情報漏洩による被害を引き起こした人」(=加害者)という側面とともに、「暴露ウィルスに感染させられた人」(=被害者)という側面も持ちます。

もちろん、なぜにnyなりを使ったのか?という動機や、「つこうた」状態にならないような対策をどうやったか?とかその他多くの点において瑕疵がある、という話はあるでしょうが、それでもウィルスによる被害を被ったという点において被害者なわけで、この点を抜きにした対応を行うことは到底考えられないというのが正直なところです。

実際に事故対応を行う際には、この部分についても留意の上、当事者のケアを行う必要がある、と強く感じてるので、あえて書いておきます。

自業自得という見方もありますし、この点について否定するものではありませんが、それでも「周囲の対応が首吊りの片棒を担ぐ結果になった」とかいう状態は気持ちのいいものではないので…。

ちなみに会社組織においてこういう話が出たときは、(世論の調子にもよるとはいえ)基本的には内規に従って粛々と対応する、というのが通常です。

#そこで感情に駆られて(必要以上に)厳しい対応をするような組織は、もはや

#組織とはいえない気がしますし、正直このテの事案において「メシウマ」とい

#う言葉を見てると、このあたりの痛みがわからない人が増えたのかなぁ…とい

#うようにも思います。

なお、上記の話は「ファイル共有ソフトウェア」による(違法な)ファイルのやりとりを容認するものではなく、あくまで「一般的な事故対応の1つ」として考えなきゃいけないことには「こういうこともあるよね」ということを述べるものでした。

[]事例によらず、リンチはいくない 事例によらず、リンチはいくないを含むブックマーク 事例によらず、リンチはいくないのブックマークコメント

確かに「同情の余地がない」と判断されても仕方はない事例もありますが、だからといってリンチ状態に持っていくのは反対だったりします。

もちろん、漏洩したデータによって、直接的/間接的に何らかの被害が出てくる人に対しては、救済や対応を行うというのは当然やられる前提ですが…

漏洩させた企業なりに対して非難なり苦情が集まるのは当然のことです。ただそれは、「正当な」抗議なりの活動の上で行われるべきものであり、決して「付きまとい」や「無言電話」「誹謗中傷系のビラまき」などを容認するものではありません。

そりゃまぁ、そうしたくなる事案があるのも理解はしますが、だからといってそのような行動に出るのは「そういう行動に出た当人の権益を損ねる」結果にもなりえます(近隣住民に通報されて、損をするのはそういう行動に出る人)。

[]つこうた件とキンタマウィルスに関する仮説 つこうた件とキンタマウィルスに関する仮説を含むブックマーク つこうた件とキンタマウィルスに関する仮説のブックマークコメント

つこうた件と、Winnyが持つ(プログラム上の)脆弱性について、(たまに)混同する人がいるのですが、「つこうた」件については、存在する脆弱性について「開発者が対応できなくなったからそうなった」という話にはならんと考えてます。

仕様を脆弱性というのであれば、そりゃそのとおりかもしれないのですが、その仕様を(今のny利用者にとって)不都合な形で改修したバージョンは、邪魔としか映らない機能を搭載したバージョンは、(おそらく)使われないでしょう。そういうのを使う人の立場に立つのであれば、目に見える不利益が出てくるまでは、古い(要は今使われている)バージョンを使い続けるでしょうね。目に見える不利益を上回る利便性なりボーナス機能が実装されていれば話は別ですが。

次にキンタマウィルスの話。オレとしては、(流通ファイルの)名前や挙動から、以下のような説を持っています。

  • キンタマウィルスの作者は(当初は)冗談で作った
  • →影響がでかくなりすぎて、「すいません」を言えなくなった
  • →どこの誰だかが作った亜種が山ほど出すぎて、無法状態

もちろん、「冗談にしては悪質すぎる」とも思ってますが、最初はそんなところなのではないでしょうか。

[]なぜ「当事者のフォロー」が必要なのか なぜ「当事者のフォロー」が必要なのかを含むブックマーク なぜ「当事者のフォロー」が必要なのかのブックマークコメント

それがすべてとはいわないまでも、オレが知る限りの事例を俯瞰的に見た場合、「最大公約数的にやらなきゃならないことの1つ」として考えられるのがそこだから。前にも書いたけど、首吊られたらまた騒ぎが大きくなるわけで。情報漏洩が元で首を吊られるのも嫌ですし、そのデータが元で何か事件が起きるってのも嫌ですが、漏洩させちゃった人が首を吊るってのもそれは嫌なものです。

で、漏洩情報の母集団によって、その騒ぎなり不安が、何らかのバイアスがかかった形で出てくるというのがお決まりのパターンです。

ただ、(私見ではありますが)どのようなバイアスがかかろうと、漏洩させちゃった人のフォローってのは(場合によっては漏洩させられた情報の持ち主のフォローと同じくらいの優先度で)行わなきゃいけないし、そうしないと再発防止もなかなか打ちづらいという状況になりえます(「なぜ」漏えいさせちゃったのか?てあたりがわからなくなる危険性があるので)。このあたり、組織を運営したり、集団を統率したりする立場の人はよくわかると思います。そうでない人や「関係ない」人は、感情に任せて石投げたり、「面白いから」煽ってみたりということをする可能性があるので始末に負えないわけですが、漏洩の中心にある組織なり会社がやらなきゃいけないことは、被害者のフォロー(救済)、組織防衛、そして漏洩させちゃった当人のフォローです。

やっちゃった人を罰することが一義ではないはずなんで、対処にあたって「(当事者以外の)世間の声」を必要以上に意識する必要はないかと。

もちろん、根拠ある抗議(そんなことをするような会社には、情報を預けられないなど) には、誠意を持って対応するほかにないわけですがね。

ついでに言うならば、「漏洩させちゃった人」ってのは、その事実と漏洩内容、そして影響度を告げられると、たいてい「こんなことになるとは思ってなかった」となり、落ち込むのが通常かと。そこに(通常の処分内容を超える)塩をすりこむとか、さらなる追い討ちをかけるというのは、理性ある人がやることとは到底思えません。

なので、「対外的なフォロー内容、方法のさらなる検討、拡充」に加え、「内部的なフォロー内容、方法のさらなる検討、拡充」という話は必須になるというのが僕の認識です。

[]漏洩させちゃった人に物申すことが出来るのは誰? 漏洩させちゃった人に物申すことが出来るのは誰?を含むブックマーク 漏洩させちゃった人に物申すことが出来るのは誰?のブックマークコメント

情報を漏洩させちゃった人に物申すことができる人は、情報を漏洩させられちゃった被害者だと思ってます。

もちろんこれは、社会的な影響とか業界に対する影響とかを勘案しなきゃいけない部分が多分にありますが、ガイドラインに記述された漏洩時の対応を見ると、何がなんでも「当事者以外の(不特定多数な)面々に対する説明」をしなきゃいけない、という話にはなりません。これは、以下のガイドラインのP.26から始まる「事故又は違反への対処」を実践するために講じることが望まれる手法の例示」を見ても、そういう内容はありません。

このことを無視して、自分の身元も明らかにせずに「事実関係を公開せよ」と迫る人は、ぶっちゃけスルーしても無問題かと。逆に「情報を漏洩させられちゃった人」に対しては、対応を行う必要が(当然ですが)あります。

・個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン

 http://www.meti.go.jp/policy/it_policy/privacy/080229kaisei-guideline.pdf

 一応、該当部分を引用しますと

(ア)事実調査、原因の究明

(イ)影響範囲の特定

(ウ)再発防止策の検討・実施

(エ)影響を受ける可能性のある本人への連絡

(オ)主務大臣等への報告

(カ)事実関係、再発防止策等の公表

というように、対処には6つの内容を含む話になるわけですが、このうち(カ)については、以下のような但し書きがあるわけです。これが、必ず公表の必要があるわけではない、とする根拠。

ただし、例えば、以下のように、二次被害の防止の観点から公表の必要性がない場合には、事実関係等の公表を省略しても構わないものと考えられる。なお、そのような場合も、類似事案の発生回避の観点から、同業種間で、当該事案に関する情報が共有されることが望ましい。

  • 影響を受ける可能性のある本人すべてに連絡がついた場合
  • 紛失等した個人データを、第三者に見られることなく、速やかに回収した場合
  • 高度な暗号化*2等の秘匿化が施されている場合
  • 漏えい等をした事業者以外では、特定の個人を識別することができない*3場合(事業者が所有する個人データと照合することによって、はじめて個人データとなる場合)

*1:「自分は大丈夫だと思ってた」という人もいますが、「こうなるとは〜」とほぼ同義かと。

*2:「高度な暗号化」は、CRYPTREC(http://www.cryptrec.go.jp/)あたりで公開してる「電子政府推奨暗号リスト」あたりで公開されている内容を参考にすればよろしいかと(もちろん、危殆化って問題はありますが)。

*3:最後のやつは「漏れた情報だけでは『個人情報』にはならん」パターンなんかがそれにあたるかと。例えば単に「どっかの会社から顧客番号と購入物品リストがもれた」とかだけであれば、それは機密情報の漏えいにはなりますが、個人情報の漏えいにはならない。

2009-01-22 あっちもこっちも情報漏えいorz

かんべんしてくだせえorz

とりあえず、年始早々のIPAの漏洩ネタが、当事者の懲戒処分という形でまとまりそうな風味なので、mixiに書いた分のうち、オレ自身が書いた部分を掲載しときます。コメントとして書いた部分の表題は、適当につけてますw

[]年初のIPAの漏洩は、停職3ヶ月 年初のIPAの漏洩は、停職3ヶ月を含むブックマーク 年初のIPAの漏洩は、停職3ヶ月のブックマークコメント

先日、年度早々に発生したIPAの職員による情報漏洩について、処分が発表されました。

・プレス発表 当機構職員の私物パソコンによる情報流出等について

 http://www.ipa.go.jp/about/press/20090119.html

内容を見ると、「就業規則に基づき」とあるので、真っ当に(懲戒処分の決定に係る)会議体が開催され、その結果こうなったというように読めます。

処分が重過ぎるんじゃないか?もしくは軽すぎるんじゃないか?という話はあるとは思いますが、まぁ妥当じゃないかと思います。勤務先の機密情報は含まれていなかったわけですし、「当機構イベントの私的撮影写真及び2007年の当機構職員海外出張伺いの下書き」をどう捉えるか?にもよりますが、基本的には「ガチガチに縛って外に出てはならない機密情報」とは思えません。

漏洩した内容のみを考えると「重過ぎる処分」になりますが、、結果として組織の信用や名誉を毀損せしめたという点が「加重要素」として加味されて、このような処分が決まったのだとしたら(多分そんなところだと思いますが)、納得いく内容であろうと考えます。それに、(表には見えませんが)この件でマネジメントラインも何らかの処分が行われてると見てますので、(良くも悪くも)本件そのものについては組織としてのけじめをつけた、と考えてよいでしょう。あとは再発防止ですかね。

ただ今後は、就業規則そのものに改定が加えられると見てますんで、同じ組織で同じことをやったからといって、まったく同じ処分内容になるとは思えないです。

[]てなことをmixiの日記で書いたらいい感じ(?)の議論に(汗 てなことをmixiの日記で書いたらいい感じ(?)の議論に(汗を含むブックマーク てなことをmixiの日記で書いたらいい感じ(?)の議論に(汗のブックマークコメント

「妥当だろ」という話をしたところ、「重過ぎる」という意見が…。

[]懲戒というプロセスを執行すること 懲戒というプロセスを執行することを含むブックマーク 懲戒というプロセスを執行することのブックマークコメント

組織の一員として動く以上、その組織のルールに従って動くのが筋ですし、賞罰もまた、その組織のルールに従って行われるべきです。

今回の件は、(私自身が想定している)「就業規則」というルールにしたがって、懲戒プロセスが走った結果としては真っ当だと思ってます。

(一見重過ぎるように見えても)「『つこうた』ことに対する世論」に必要以上に反応して「解雇」に行かなかったのは、大きく評価すべきだと思ってたりします。

あくまで想像でしかありませんが、今回内部での処分検討を行うにあたっては、世論に必要以上に反応して「解雇」という声も(大きさはよくわかりませんが)出てはいたはずです。ただ、その声に任せて「解雇」としてしまったら、(逆に)私はIPAの内部プロセスについて「信用ならん」と公言してたと思います。

[]組織の信用失墜と、当事者の重過失 組織の信用失墜と、当事者の重過失を含むブックマーク 組織の信用失墜と、当事者の重過失のブックマークコメント

オレはIPAの就業規則を知る立場にないので*1 、組織の性格、「普通に閲覧可能な就業規則」の例、そしてその事故によって引き起こされた事象をもとに考察しているわけです。

で、私はこの漏洩については(故意ではないにしても)重過失といわれてもしょうがないくらいの話だと思ってます。さらに言うならば、損害も(事故対応にかかるコスト、組織の信用失墜とその回復にかかるコストという観点からは)組織にとって致命的とはいえないまでも、与えちゃってると思ってます。

祭りの原点に立ち戻ると、「誰がつこうたか」を、組織も含めて特定されてしまった(そして特定に必要な材料が漏洩していた)ところが最大のキーなわけで、おそらく中の人も「せめてこれさえなけりゃなぁ…」とアタマを抱えたはずです。

オレ自身のコンピテンシの1つが情報セキュリティということもあって、贔屓目入っていると思われるかもしれませんが、本件の評価については、組織の性格と経営の観点、そして世論の3つは(普通に)考慮してます。

もちろん、「過失の認定とその重大度」については、組織内で議論と認定が行われたと思うわけですが、下記のような材料がそろってしまっている状況を考えると、客観的には「重過失」と見られても文句言えません。

[]オレなりの理解 オレなりの理解を含むブックマーク オレなりの理解のブックマークコメント

…今回の件を追うと、以下のようにまとめられます。

  • 誰かが「つこうた」
  • 漏洩した内容に、その「誰か」の経歴や現在の所属が明らかになるような情報が含まれており、現在の所属がIPAであることが判明した
  • 漏洩した内容を掘ると、「これはちょっと」という内容が山のように
  • IPAの性格上、「そういうことはするな」という指導をしなきゃいけないところではないのか?というところでまず祭りに
  • 「身内がつこうた」というところで、IPA面目丸つぶれ&涙目。

で、あちこちで「つこうた」話が出ていて、危ないということがわかっているにもかかわらず*2、その啓発をしている組織の中の人が「つこうた」ことが判明してしまってるわけです。

ここまで材料がそろっていると、私なんかは「こりゃ重過失」だと判断しちゃうわけです。

これで機密情報が漏洩してたらアウチ(解雇)だったとは思いますが、幸いにしてそういうことはなかったので、「組織の信用を失墜させた」&「重過失」ということで「停職3ヶ月」*3となったのではないかと。

*1:書いた後で気がついたのですが、ありました>IPAの就業規則(http://www.ipa.go.jp/about/johokokai/johoteikyo/sosiki/pdf/shugyokisoku.pdf)。

*2:そしてそういうことを明言して、「そういうことしないでね」「注意してね」という啓発をしているにもかかわらず

*3:就業規則上は、解雇一歩手前くらいですね

2009-01-14 ESTA申請してみた

渡航の予定があるわけじゃないけどw、時間があるうちに申請しとこうと思ったので。

[]ESTA申請してみた。 ESTA申請してみた。を含むブックマーク ESTA申請してみた。のブックマークコメント

いつ行くことになるか知らんけど、とりあえず「渡航72時間前」には申請受理されてる必要があるという脅しがあったのでw、時間あるうちにと思ってのこと。

必要な項目をざくざく入れてって、「申請」ボタンを押すと、(あたりまえといえばあたりまえだけど)以下のようなメッセージが。

渡航認証保留

あなたの申請について即座に決定を下すことができないため、あなたの渡航認証は審査中です。この回答は、良くない事実が見つかったことを示すものではありません。判定は72時間以内に受け取ることが可能です。

えーと…

  • ESTAの申請内容に関する判定は、最大72時間かかる
  • 前の日記にも書いたけど、「米国行きの飛行機に搭乗する少なくとも72時間前に、米国への渡航に必要な事前渡航認証の承認を取得する必要があります。」とのこと

なので、余裕を見るのであれば、申請提出は72時間+72時間ってことで、144時間前には行っておく必要がある、つうことじゃねえかorz

まー、そこまで判定に時間がかかるケースも稀だとは思うけど、念のためてことで。

個人的には、「ESTA」混乱なく開始 米国渡航ネット認証制度(イザ!の記事)の文中にある、以下の内容が少々気になる。

成田空港では申請をしなかった旅行客らに対応するため、全日空が第1旅客ターミナルビルの出発ロビーにあるチェックインカウンター前に「ESTA申請専用カウンター」を設置。パソコン6台を用意したが午前は利用する旅行客らはいなかった。

…72時間ギリギリまでかかるようであれば、フライト直前に申請してもまったく間に合わないと思うのだけどw

追記:20時間くらい経過したところで確認したところ、無事(?)渡航は許可されていました。

注意事項としては、以下のような感じ。

  • 審査結果を閲覧するためにはパスポート番号と申請番号が必要
  • 上記のうち、申請番号は、申請送信時にしか確認できないので、何かに書き留めておく必要がある

メールアドレス入れさせるわりには、メールでの通知は一切行われませんでしたw

2009-01-13 連休終了〜

連休は

という感じで過ぎ去りましたw

[]キャラバンの参加者の方の日記 キャラバンの参加者の方の日記を含むブックマーク キャラバンの参加者の方の日記のブックマークコメント

質問の内容、よく覚えてますw

技術職を希望して、そっち採用(だったかな?)にもかかわらず営業に…という話でしたが、私としては(今にして思えば)うらやましい、という感じだったりします。

もちろん、当人からしてみれば「とんでもない」とも思うのでしょうけど…。

私としては、「営業として技術者が動く」ことは、最終的にはプラスになると思っています。

技術者は確かに、高い専門性とスキルを要求される局面がありますが、そのような特性を発揮して作ったものを売ってくれるのは誰か?というと、営業の方々です*1。そして、全体的にそのバランスをとって、会社を存続させることを第一に考えるのは、経営層の方々。

そんな状態で、営業な方々に「売ろう」と思わせるモノをつくるためには、当然営業の論理を知らなければ作れない。どんなにいいモノ/いい技術であったとしても、それを使うのはお客様であり、売るのは営業の方々である。

私自身の言葉もさることながら、そのあたりの話はogochanの日記に詳しいので、ぜひ読んでほしい。

不幸にして営業に携わる経験を得られていない人は、チャンスがあったら是非携わるようにしてみてほしい、という感じ。営業にカバン持ちでついていって、直にお客様の声を聞くだけでも、だいぶ違うと思うです。

何かを(仕事として)作る時は、多くの場合は作ったものもしくは作ったものを使って得た結果を「(誰かに)渡す」ということになるはず。そうして身についた経験や知識は、きっと開発に携わる場合にも役に立つでしょう。

*1:営業の方々は逆に「作れない/提供できないものは売れない」わけですが

freedomcatfreedomcat 2009/01/13 02:46 おつかれさまでしたー。

名乗る程では無いです名乗る程では無いです 2009/01/13 21:54 人間すべて、自己の営業マンです。

wakatonowakatono 2009/01/13 22:56 freedomcatさん:
おつかれさまでしたw

名乗る程では無いですの方:
確かにそうですね。
ただ、そこまで意識して行動してる人がどこまでいるかは不明ですが…。

2009-01-07 ESTA必須化まであと4日?5日?

なんですが、重大な落とし穴発見…

[]ESTAによる認証取得は、渡航の72時間前までに、かなー ESTAによる認証取得は、渡航の72時間前までに、かなーを含むブックマーク ESTAによる認証取得は、渡航の72時間前までに、かなーのブックマークコメント

以前のエントリ(http://d.hatena.ne.jp/wakatono/20081113#p1)では、ESTAが2009/1/12から必須化される旨は書いたけど、どのくらい前をメドにってのは書いてなかったので…。

ノースウェスト航空からのお知らせがメールで来て、そこに72時間ってのはあったわけだけど、JALからのお知らせでも同様に72時間、と書かれてた。

何が72時間?と調べてみると、以下のとおり(JALの場合)。

平素は日本航空をご利用いただき厚く御礼申し上げます。

 査証免除プログラム(VWP/Visa Waiver Program)を利用して米国に入国する全てのお客さまは、米国行きの飛行機に搭乗する少なくとも72時間前に、米国への渡航に必要な事前渡航認証の承認を取得する必要があります。

事前認証は、米国国土安全保障省(DHS)が管理するウェブサイト内の、ESTA (Electronic System for Travel Authorization/電子渡航認証システム)を通じ、認証を得る必要があり、インターネット以外の認証方法はありません。

ということで、渡航72時間前までに認証を取得できるように申請をしとく、という必要があります。

…混乱しそう…

taraijpntaraijpn 2009/01/07 15:23 乗り継ぎとかあったら冷や冷やしそうですねえ。

wakatonowakatono 2009/01/07 15:27 今日明日には申請しとかないとアウチでしょうね。
でも、72時間ってどうなんよ?とも思います。

0000 | 00 | 01 |
2003 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 04 | 05 | 06 | 07 | 08 |
2011 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 12 |
2012 | 01 |
2013 | 05 | 06 | 07 | 08 | 09 | 12 |
2014 | 03 | 06 | 08 |
2015 | 02 | 04 | 08 | 10 |
2016 | 02 | 03 | 04 | 07 | 08 | 10 |
2017 | 05 | 07 |
hacker emblem
ページビュー
1909465
Connection: close