ある研究者の手記

セキュリティとかゲームとかプログラミングとかそのへん

『見て覚えろ』の後ろには屍の山がある

www.recomtank.com

ちょうど職場でも新しいメンバーの教育問題がいろいろ議論されているところで、この記事を見て思ったこともいくらかあったのでつらつら書きなぐってみます。

上の人がみんな「俺は見て覚えた」というのは生存者バイアス(の可能性が高い)

どことは言いませんが、マニュアル化された教育法がない世界では確かに「自分は先輩を見て覚えた。だからお前もそうしろ」という言説をよく見かけます。できる上の人達はみんな口をそろえて言うため、それに従えば自分もできる人になれるのか、と思ったり思い込んだりしてします。しかしそれは「上を目指していた人たちが全員そのように上へあがっていた」のではなく「そのような教育方法でも生き残った人たち」なのであり、ただの生存者バイアスに過ぎません。そのやり方についていけなかった人たちがその組織・業界を去っていった結果、残った人たちなのであって、その後ろには屍の山が築かれています。個人的な経験の中でもそういった人たちをいろいろな場面で見てきました。

育てたい人物像をイメージ出来ているか

『最初から教えてばかりだと、考える能力が身につかない』という論もあり、この言葉が完全に間違いではないと思います。ただ、まずこれは程度問題であり、育てたい人物像と設定するハードルの高さのバランスを考える必要があると思います。

例えば本当の超少数精鋭を育てたいのであれば、ほぼ突き放してついてこれた人だけがその組織・業界に残る、ということもあり得ると思います。ただし先程も書いた通り、その後ろには山のような屍が築かれ、その道を志した100人に1人とか、もっとひどければ10000人に1人しか残らない、みたいな話もありえると思います。HxHのハンター試験みたいなものです。貪欲に自分で学習し、人のスキルなどを盗んでいく超逸材だけが残っていくことでしょう。ただし、このモデルは本当に人数を増やす必要が無い場合か、それだけ厳しい道でも志願する人が後を絶たない、といったような状況でなければ成立しないでしょう。

一方で超逸材がいなくてもいいが(いてもいいけど)仕事として100点満点中80点をちゃんととれる人が増えてほしい、という場合だと、全て「自分で勝手に学べ」モデルは非常に相性が悪いと思われます。一般的な企業や組織はほとんどがこちらに該当すると思われます。特に事業などの規模を拡大させたい場合は100人雇って1人しかものになりませんでした、では話になりません。こういった場合は先のブログで書かれていた通り、マニュアル化された作業手順や教育方法があってしかるべきだと考えます。

そもそも「マニュアル化できない」とはどういうことなのか

ちょっと自分のいる業界に偏ってしまいますが、基本的にマニュアル化できない仕事というのは、人によって過程や結果が異なることを許容する 仕事だと考えられます。以下、その例をあげてみます。

  1. 何かを自ら創造するような仕事(システム・ソフトウェア設計、新しい企画の立案)
  2. 前提条件の想定が難しく条件の組み合わせも複雑であり、条件の網羅が困難なもの(トラブルシューティング、インシデントレスポンス)
  3. 試行錯誤しながら進めないといけないもの(新しい機器の検証、探索的データ分析)

確かに上記のような仕事について全てマニュアル化するのはかなり難しいとは思います。しかし、全てをマニュアル化するのは難しいとしても、部分的にはいろいろマニュアル化(ないしは定型的な教育によって身につけた手順によってできるもの)できそうではないでしょうか? 例えばソフトウェアの設計などはどのような道筋でやるべきかという教本はいろいろありますし、トラブルシューティングでもまずはこれをチェックしろ、みたいな初動のマニュアルは作成できそうです。

最終的に人間が考え、発想し、創造する必要のある仕事は確実にあると思います。しかしそのためには、どこからが機械的に作業して(あるいはもう機械に作業させてもいいわけで)どこからが人間の判断の力を発揮しなければいけないか、という線引をすることが重要なのではと思います。

あと、基礎力の必要性などについてもちょっと書きたかったですが、夜更かしが過ぎてきたのでこの辺で。

博士の愛した就活(採用プロセス編)

前回からの続き。

ちょうど経団連的新卒採用プロセスがはじまったということで、博士課程をしている後輩によく話していることをまとめました。この話は私が経験した情報科学系のごく狭い範囲の知見を元に書いていますが、現在博士課程の人やこれから博士課程に進もうと考えている人の参考になれば幸いです。また、主に企業への就職を中心に話をします。

前回は就職先の選び方について書きましたが、では実際に就職しよう!として動き出した時にどういうアプローチで内定をもらうか、という部分についてです。1) 新卒採用プロセスに乗る、2) 中途枠・オープンポジションを狙う、3) つてを頼る という三本立てでお送りします。

1) 新卒向け採用プロセスに乗る

いわゆる説明会に参加して、エントリーシートをだし、何度か面接を経て採用、という学部生や修士生と同じパターンです。博士の場合は例外扱いになるケースも有りますが、こういった新卒採用プロセスを持っている会社の場合はだいたいそこに組み込まれることが多いと思います。細かい対策については学部や修士のものとほぼ変わらないのでSPI対策本などを読んでおく感じでしょう。

時期的な制約が強い

このアプローチで気をつけなければいけないのは、プロセスに乗れる時期が1年のうちに限られているという点です。2017年卒の場合は2016年6月から採用試験がはじまるので、2017年3月に卒業することを前提に2016年6月から就職活動をはじめなければなりません。

学部や修士過程では単位を落とすなどのミスをしないかぎりは決まった時期に卒業できるので「お前は何を言っているんだ」という感じかもしれませんが、ほぼ学内で卒業までが完結する学部や修士と違い、博士課程の卒業審査は学外の要素がからんでくるため、卒業時期が不安定になりやすいというリスクがあります。博士課程の在籍経験がある人はよくご存知かと思いますが、博士過程を卒業するためには研究をして博士論文を書くだけではなく、論文誌への掲載や国際学会での発表という要件が明示的・暗黙的かを問わず存在します。論文誌や国際学会での採択は学内でコントロールできるものではなく、外部の査読者に掲載や発表を了承してもらわなければなりません。これは容易なことではなく、1度の投稿には構想・実験・論文執筆に数ヶ月を要しますし、下手をすると何度投稿しても掲載・発表拒否となることもあります。こういったものが卒業条件(あるいは卒業を決めるためのプロセスの条件)に加わることで希望通りの時期に卒業できないというケースが起こりえます。そのためこの新卒向けプロセスに乗る場合、(例えば2017年卒予定だとすれば)2016年6月には論文誌や国際発表が完了・あるいは見通しが立っている状態にして、6月からは就職活動に時間を割き、その後に研究まとめ、博士論文執筆や発表をこなすということを手際よく進め、2017年3月にちゃんと卒業する、というところまでをやりとげなければなりません。

採用プロセスの課程が分かりやすい

このアプローチは時期の制約が厳しい代わりに、採用プロセスが比較的分かりやすいと言えます。中途枠や例外的な扱いになると他に参考事例が無いので、自分が今どういう状況に立っているのか(採用が進んでいるのか停滞しているのか)ということが不明瞭になりがちです。これが(ある程度大きい企業に限るかもですが)新卒採用のプロセスになると同じプロセスをやっている別の学生が一定数以上いることになります。就職希望の他の学生の方と状況をシェアできることもあるかもしれませんし、過去の事例からおおよその状況を把握できます。あくまで自分の立ち位置がわかるという程度のものですが、戦略的に複数の企業の採用面接を受けている時にはメリットになると考えられます。

2) 中途枠・オープンポジションを狙う

外資ベンチャーだと、そもそもあまり体系だてて新卒採用を実施しておらず、誰でも応募できるオープンポジションという形で募集をしているケースが多く見られます。また日本企業でも中途採用という形で新卒以外の採用希望者を雇用しているため、そこから採用プロセスに乗せてもらうというアプローチがあります。

業務内容が明確で採用プロセスも比較的柔軟

中途枠・オープンポジションはそれぞれ求められる技能や採用後の業務内容について、ほとんど事前に明示的に説明されています。前回でも少し書きましたが、新卒採用プロセスによる就職は採用後の業務内容が明示されないケースが少なからずあります。また、例えば面接中に口頭で説明されれる場合もありますが、所詮は口約束なので会社の都合によっていつの間にかに変わっている場合もあります。もちろん会社都合による業務の内容は中途枠・オープンポジションでも発生する可能性はありますが、最初から業務内容が曖昧な採用プロセスと明確なプロセスでは対応が違ってくると思われます。

また、面接・雇用タイミングの融通がききやすいというアドバンテージもあります。先述の通り、新卒採用のプロセスでは面接などの時期が限られており、内定、ないしは内々定から実際の雇用までにかなり期間があります。経団連の施策によってかなり後ろだおしされたものの、それでも約半年ほどの差があります。それに対して中途やオープンポジションの場合は採用決定後、かなり早い時期で雇用が始まると聞いています。そのため、例えば博士号の審査に関するどたばたも終わり、卒業までのいくらかの期間の間に就職活動をして就職する、というような流れもありえます。

タイミングよく求職している業務経験者

じゃあ新卒プロセスは忘れて、中途枠・オープンポジションを狙うのがいいのか?という話になりますが、もちろんデメリットもあります。

まず、中途枠やオープンポジションでは「業務経験者」を条件にしている場合が多く、そのケースでは博士課程卒はこれに該当するのか?という問題があります。博士課程での専門にマッチしていれば下手な業務経験者よりも技術的な面については優っているケースは多々あると思います。また、博士課程の学生でも研究プロジェクトをまわす経験があるのだからそういった面でも業務と比べて遜色ない、と主張する方もいらっしゃします。ただ、自分も博士課程を卒業して企業に就職して5年ほどたった今考えても、やはり経験の質は若干違うと感じています。特に中途枠という設定の窓口に多いと思いますが、そういったことを採用担当の方が懸念される場合は「新卒採用の窓口があるのでそちらからどうぞ」と突っ返されるリスクがあります。

また、受けたいときに受けられる可能性が高い事と、受けたいときに希望する職種を募集しているかというのは全く別問題になります。企業側としていつでも採用希望を受け入れるということは(適切な人材がいれば)早く採用して働き始めてほしいということの裏返しでもあります。追加で募集するということもありますが、多くの場合は人が見つかればその募集は打ち切ることになるので、この辺りの動きはかなり流動的です。また企業側の方針転換などで誰も採用しないままの打ち切りということもありえます。自分の希望する企業の希望する職種が都合の良い時期に募集しているかは完全に運である、というところにリスクがあります。

3) つてを頼る

前述の中途枠を狙う、に若干近いところがありますが、知り合いの会社の中の人経由で採用面接をうけさせてもらうケースです。博士課程の学生となると企業とのプロジェクトや学会参加などでその人なりの人脈を築いている場合が多いと思います。そういった人たちに紹介してもらい、面接を受けさせてもらいます。多くの場合、紹介してもらう人に人事権がなかったりするので、紹介=即採用みたいにはならない(というかそのケースはヤバイ)のですが、いくつか中途採用やオープンポジションに比べて有利な点があります。

面接にたどり着きやすい、というアドバンテージ

外資系に多いパターンだと思いますが、レジュメだけ登録させて「空きができたら会社から連絡を出すね」というのを見かけます。こういうのは大手ほど大量のレジュメが登録されることになるので、特別な業績などあれば別でしょうが、待てども待てども連絡がこないのはざらです。その点、紹介の場合は比較的面接プロセスまではたどり着きやすく、同じような内容が書かれた大量のレジュメの中から選ばれるのを待つよりは、面接官に直接自分をアピールできるチャンスが得やすいと言えます。これは採用する側からも、どこのだれだかわからない応募者より、同じ会社で働く社員の紹介のほうが安心感があります。そのため、大企業でも応募者が面接をパスして入社したら紹介した人に褒賞がでる紹介制度がある、という話をよく聞きます。

一朝一夕ではどうにもならない

つてを頼る時の難しさは、当然ですが自分の人脈を学生時代どれくらい築けたかによって頼れる範囲が変わってくることです。これは少なくとも大学の研究室などに所属してからどのように活動してきたか、すなわち対外発表や外部講演、勉強会での交流などをどれくらい積極的にこなしてきたかということに依存します。そのためそれなりに長い期間がかかっていることが重要であり、エントリーシートのように今日明日で何十社にアプローチできるというものではありません。

自分の状況・ペースにあわせた就活を

長々と書きましたが、結局のところ博士課程にいる時点でいわゆる「みんなで足並み揃えて」何かをするという道からは外れていると思います。それぞれ学生さんごとに状況・ペースが違うので、いろいろなやり方のメリット・デメリットを勘案して自分にあった方法を選ぶと良いと思います。

博士の愛した就活(就職先の選び方編)

タイトルは思いつきです。

博士課程にいる後輩によく話していることをまとめました。この話は私が経験した情報科学系のごく狭い範囲の知見を元に書いていますが、現在博士課程の人やこれから博士課程に進もうと考えている人の参考になれば幸いです。また、企業への就職を中心に話をします。

博士課程を修了した後に企業への就職を考えている場合、企業を選択するにあたって以下のことをチェックするとよいのでは、という点をまとめてみました。

就職後の業務は明確か?

就職したとして自分の専門を活かした仕事ができるかというのは、その会社の採用形態によって異なります。外資系などの場合は新卒採用の場合でもある程度は業務内容を明確にしたうえで募集しているところが多いと思います。さらにオープンポジションのような形式で募集している場合は、より具体的に業務内容が明示されていることが多く、自分の専門が活かせるかどうかということについて判断しやすいでしょう。

逆に日本企業の場合は「とりあえずとるだけとって後から事業部や部署に振り分ける」という形式をとっているところが比較的多い印象です。こういう場合、自分が専門でやっていた分野を得意とする企業であっても研究職などにはつけず、営業など研究開発とは遠い部門へ配属されるということも普通にありえます。

特に日本企業では定期的に部門を移っていくことでキャリアアップするといった、官僚のシステムに近い会社もあるようです。いろいろなことを広く経験したい、という方にとってはそういうシステムはいいのかもしれませんが、博士に進んだ人で自分の専門をずっとやっていたい、という方にとってはミスマッチになる可能性があります。そういう観点から就職後、どのようなキャリアパスが用意されているかということも確認しておくのがよいでしょう。

会社として博士号を評価してくれるか?

血の滲むような思いをしてとった博士号を評価してくれるかどうかというのは、博士課程の学生にとって重要な関心事だと思います。残念ながら、企業によっては博士号をプラスに捉えてもらえないどころか、マイナスの評価になる場合すらあります。博士号を持っている人は専門指向の強い人と捉えられがちなので、ポジションとのミスマッチがあるとそれがマイナスイメージに働くことがあります。また、単純に学部生に比べて歳を重ねているという現実もあり、新卒採用主義の企業からすると敬遠されやすい傾向があります。企業によっては正規ルートでは博士の学生は就職できないということすら聞いたことがあるため、もし博士課程後に特定の企業へ就職しようと考えている学生さんがいらっしゃる場合、事前に確認しておくべきです。

しかし一方で博士号をプラスに評価してくれる企業もあります。主観的な意見ですが、やはり外資系やベンチャー企業などに多いと思います。博士号取得の過程ではある分野への専門性だけではなく、他分野にも応用が効く問題発見・設定や解決能力などが養われるので、そういった点を見てもらえるようであれば採用に対しても有利に働く面があると思います。

給与面での優遇はあるか?

また採用過程だけでなく、給与面に反映があるかも重要な点です。学部卒と修士卒で給与がわかれているというケースは多く見かけますが、博士卒に対して給与面での優遇がある企業もまれに見かけます。博士卒の給与が書かれていない企業は、そもそも博士の応募が少ないので例外的な扱いになっており給与面については応相談な場合と、そもそも修士と同じ扱いである場合があるかと思います。博士課程は在籍中に毎年学費を払わなければなりませんし、就職すればそれだけ給与を稼げたであろう3年以上の在籍期間を消費しています。就職に際して給与が全てとは思いませんが、給与は会社に対する貢献へのフィードバックの一つの形ではあるため、給与が修士卒と同じということは、博士号についてはあまり評価してくれていないと考えるのが自然かもしれません。

また、働いた経験がないと実感しにくいと思いますが、給与というのは同じ会社で働き続けるにしても後から転職するにしても、最初の年収というのが後々に響いてきます。昇給は元の給与に対してN%加算みたいな形式になるかと思いますし、転職するにしても元の給与に+N百万みたいな形で増えれば上々、普通はほぼ同額、みたいになると噂に聞きます(これは業界によって大きく違うかもしれませんが)。あまり給与だけみて就職先を決めても不幸になることが多々ありそうですが、その一方で給与を甘く見ない、ということも非常に重要です。

全く違う分野を考える場合

上記3点は自分の専門をある程度意識した就職の話になりますが、全く違う分野を考える場合は年齢がやはり重要なポイントになってきます。学部卒と比べると通常で約5年、在籍期間が長ければそれ以上の差がついています。年齢が上になった人が全て新しいことを学ぶのに不向きだということはありませんが、経験則的には年齢が若い方が学習にも意欲的で飲み込みも早いという側面はあります。そういったことから採用に不利になったり、新卒採用に対してそもそも年齢制限が加えられるというケースもあります。

博士課程はこじらせると6年、あるいはそれ以上かかるケースがあり、その場合は学部・修士で浪人・留年がなかったとしても卒業時点で30歳を超えてしまいます。これは違う分野に行く場合だと大きなハンデキャップになってしまう可能性が高く、個人的には途中で見切りをつけるという選択肢も検討するべきではと思います。

インターネット通信データ量をd3jsのツリーマップで可視化してみた

練習などを兼ねてちょいと書いてみました。

自分のMacBookProで作業をしていた時に取得した通信データから、通信相手をドメイン名で判定し、送受信量をもとにツリーマップにしてみました。通信からのデータ取得は自作ツールを使い、出力結果をPythonごにょっといじった後にd3jsで描画しました。通信データは約5時間ほど。

HTML版はここに公開しています。細かい通信量とか見えます。

送信データ量のツリーマップ

送信データ量と受信データ量は一度に表現するのが難しいので、今回は分けてみました。まずは送信データ量から。

f:id:mztnex:20151114163953p:plain

解説を入れるとこんな感じです。

f:id:mztnex:20151114164009p:plain

送信データ量そのものは多くないのですが、作業していたソースコードDropbox配下にあったので頻繁にDropboxにデータを送信していたため、Dropboxがとても大きく出ています。といっても、送信データ量はDropboxの島を全部あわせて70MB程度ですね。どうということはありません。さらに、作業時にずっとみていたニコ動の通信が目立って見えるのがわかります。これも送信データ量としては少なく、トータルで20MB強というところでしょうか。これはこちらから生中継をするようなデータを流していたわけではないため、ほぼTCPのack(受信確認)のパケットだけでこれぐらいの容量になっていることが伺えます。

受信データ量のツリーマップ

一方、受信側はこんな感じです。

f:id:mztnex:20151114165102p:plain

解説付きだとこんな感じになります。

f:id:mztnex:20151114165134p:plain

さっきより顕著にニコ動の通信がデータ量を占めているのがわかります。マイリスト登録していた動画をBGM代わりに受信しつづけていたので、その配信される動画のデータががつんと乗ってきている状態ですね。全体で約2.5GBほどあり、携帯キャリアの回線(テザリング)などを使っていたらあっというまに帯域制限にひっかかったでしょう。(この時はカフェに設置されてるWiFiを使っていました)

次に大きなポーションになっているのが左下のBlizzard社からの通信です。これはBlizzard社が制作、発売しているHeathstoneのパッチが落ちてきたためだと考えられます。Hearthstoneはゲームとしてとてもシンプルなのですが、演出などが豊富なためアプリ・パッチのサイズがとても大きいというのが若干ネックになっている気がします。でもゲーム内容はとても面白いのでおすすめですよ(脈絡のない宣伝)

他に注目すべき点としては右下にあるtwimgからのトラフィックでしょうか。そこまでtwitterの画像をずっと見続けた記憶はないので、Twitterクライアント(Tweetbot)がサムネイル(および画像本体?)を取得する通信だけで約100MBほどを受信しているのがわかります。ちなみにツイートの受信であるuserstream.twitter.comからの受信は右上にある青の細長い部分で、受信は20MB程度です。写真投稿などが多い昨今だと通信データ量だけでみればかなりtwimgに負荷がかかっているようです。

ということで、通信を無制限に使える環境であれば特に気にすることのないものですが、データ量制限のある環境ではどの通信がどれくらいの割合をしめているかということがわかると通信データ量の節約がはかどるのではと思います。(一部当然のことですが)今回の知見としては以下のとおりです。

  • 動画垂れ流して見ているのは非常にインパクトがでかい
  • アプリケーションのパッチも種類によってはそれなりに重い
  • ツイート取得はそうでもないが、画像閲覧はそれなりに重いようなのでクライアントの設定しだいではデータ量を節約できるかも?

こちらからは以上です。

自動化するときに考えるべきこと3つ

自分の経験を元にメモ書き。

1. 自動化の目的は「属人性排除」「ヒューマンエラーの除去」「高速化」のいずれか、もしくは全てである

属人性排除

「この作業は○○さんしかできないから」みたいなものをなくすのが属人性排除。 これは自動化することによって作業の一部、あるいは全てをほかの人でもできるようにすることで達成される。 職場における人の入れ替わりで秘伝の技が途絶えてしまったり、引き継ぎの労力を少なくすることによって 組織としての靭性を高めることができる。 また自動化する過程で、ある人物しか理解していなかったロジックや、そもそも作業をしている本人ですら説明できないような手順や理論を解き明かし、再現性のある形へ落とし込めるという副次的な成果がある。これが手順書という形だと解釈の違いによる間違いなどが発生する可能性があるが、コードによって自動化されていることで誤解を生む可能性を極小化する。(ただし0になるわけではない)

ヒューマンエラーの除去

プログラムによって自動化された作業でも当然例外やバグによって思わぬ挙動をすることがあるが、人間も言うに及ばずしょっちゅう間違いをおこす。 しばしば「集中力が足りない」「もっと注意する」「気合」などの精神論で解決できると信じている人がいるが、個人的な経験則でいうと、どれだけ注意深く作業したとしてもだいたい最低0.01〜0.1%程度の確率でミスをする。プログラムのバグの発生も同程度、あるいはもっと高い確率かもしれないが、最大の違いは(バグ修正すれば)プログラムは同じ間違いを二度起こさないことである。人間の場合、同じ人物が同じミスをしてしまうこともあるし、作業者が入れ替わると同じミスを起こすかもしれない。

高速化

単純作業やロジックが決まっているものについては、それを得意とする機械にやらせるべきである。

2. 自動化の目的は「コスト削減」であってはならない

よく「自動化によってコストが削減されます」という言い方がされているが、だいたいの場合こういうプロジェクトは失敗する傾向が強い。 これは、この文脈ででてくる「コスト」とはすなわち「人件費」のことであり、「コスト削減」といは「人員整理・リストラ」につながるからである。 多くの場合、自動化するためには今その仕事をしている人物から作業のロジックやノウハウを教えてもらわなければならないが、 プロジェクトの最終目的がリストラだとすると、教えてもらう人たちがまさのその対象になるわけである。 これでは協力してノウハウを教えてもらうどころか、その人達が抵抗勢力になってしまうため、プロジェクトが進まなくなってしまう。

結局のところ自動化とは人間の作業を機械にやらせることになるので、コスト削減が最終目的ではないとしても少なからず上記のような問題を引き起こしやすい。ただし、以下のようなケースでは比較的スムーズにすむ。

  1. 他にやるべき作業があるにも関わらず、現在は自動化対象の作業に業務時間が圧迫されている場合
  2. 全てを完全に自動化できず、最終的に人間の判断などが必要な作業の場合

(1) は例えば、目先の作業に振り回されてしまって先行投資的な作業に取り掛かれていないような状況である。(2) は例えば現実世界や人物間の文脈をもとに最終的な判断しなければいけない作業だったり、一定確率でしか正解が導かれるが外した時の影響が大きいので人間が責任を負う必要があるようなケースである。こういう類のものは結果が導かれるまでの過程を正しく理解している人物が必要になるので、単純に機械を人に置き換えられるものではない。

3. 自動化は「熟練の作業者」ではなく「未熟な作業者」に対して効果が高い

なぜか自動化の話がでると「専門家(熟練の作業者)」「それ以外」という登場人物しかでてこなかったりすることが多いのだが、現実にはその中間たる「未熟な作業者」がいる。最初の目的に挙げた「属人性排除」「ヒューマンエラーの除去」「高速化」は、もちろん熟練の作業者に対しても有効だが、それ以上に「未熟な作業者」に対してはより大きい効果を生みやすい。これは作業を完全自動化するわけではなく、未熟な作業者がとりかかる一部だけでもその効果がでやすいという観点もある。(熟練の作業者の一部の作業を置き換えると、逆に効率が下がってしまうことがしばしばある)ただし、先述した判断が必要な作業などもあるため、自動化された作業について無知でよいというわけではない、ということについては注意が必要である。

コンピューターセキュリティシンポジウム2015に参加してきました

f:id:mztnex:20151027230810j:plain

情報処理学会 コンピューターセキュリティシンポジウム(CSS)2015@長崎に参加してきました。ちゃんぽん美味しかったです。

より実践的になっている学会

f:id:mztnex:20151027231345j:plain

実学的な発表が多くなってきている印象でした。CSSにはマルウェア対策研究人材育成ワークショップという発表枠が含まれているのですが、ここで発表されているネットワーク侵入検知や防御、マルウェア分析などは他のコンピュータ科学の研究とくらべてもとくに実践的な内容になっていると思います。マルウェア対策技術というのは、攻撃者側のマルウェアや攻撃手法の変化が非常に早く、自分も昔指導教員に「マルウェア関連の研究で5年前というのは石器時代」と言われたことがあります。そのため研究でも数年後に芽がでるようなものではなく「今」「役立つ技術」というものが求められていると思います。

今回もそうですが、このマルウェア対策研究人材育成ワークショップ(MWS)というのは大学や企業の研究所だけでなく、セキュリティをサービスとして売っているような会社やそれこそアンチウィルスベンダの方も参加されており、こうやってデータ収集してみた、みたいな内容も多く発表されています。これはこのワークショップが始まってから徐々に広まってきた流れであり、それ以前のCSSにはなかった流れだったと記憶しています。ワークショップの委員の方もこういった実践に沿った研究活動を広めてほしいという願いがあったようで、それが形になってきているということを強く感じました。

研究は良くも悪くも機械学習的な話が多かった

f:id:mztnex:20151027232554j:plain

自分が参加したセッションの偏りがあったからという気もしますが、とりあえずデータを機械学習に食わせて何か結果をだす、というような発表が多かったのが印象に残っています。データをいろいろな視点から扱ってみるという点では貢献があるかなと思う反面、機械学習系の研究の悪いところとしてでやすい「なぜこの手法を選んだのか」ということを論じきれていなかったり、「この結果は他の環境や実環境でも有用なのか」というようなことに対しての突っ込みが甘いものも少なくなかったように思います。

研究所から離れた自分が参加してみて

f:id:mztnex:20151027232217j:plain

私自身が今年の4月から研究所を離れて現場(SOC)に入っているのですが、やはり現場的視点を持ってからこういう研究発表を聞くと面白いと思いました。特にMWSというのは事前に配布されるマルウェア関連のデータがあるのですが、この共通のデータをいろいろな視点で料理している研究を見ると、実際の現場でも「ああ、こういう見方や分析をして見ると何か見えてくるかもしれない」というような着想を得ることができました。

すでに多くのセキュリティ対策ベンダだけでなく大手Webサービスの方などもちらほら参加されるなど、多様な方々が集まるよい場だったと思います。研究というキーワードがあるとちょっと疎遠になってしまいますが、普段セキュリティに関わっている方ならいろいろと有益だと思いますので、参加を検討してみるとよいと思いますよ。

AWS EC2へのSSHに対する攻撃をハニーポットで分析してみた (2015年4月〜6月)

数ヶ月間、私のお小遣いを貪り続けてきたAWS EC2上のハニーポットですが、さすがに財布へのダメージが蓄積してきたのでいったん停止させました。停止させたもののそれなりにデータを蓄積していたので、さてどうしようかなと思っていたのですが、 先日、長崎で開催された情報処理学会コンピュータセキュリティシンポジウム2015で聞いた講演の一つに SSHの新しい攻撃方法について触れられていてちょっと気になったので、収集したデータのうちSSHに関しての通信のみちょっと分析してみました。

ハニーポットの構成やデータの収集方法については過去のエントリを参照していただきたいのですが、 今回はAWS Asia Pacific (Tokyo)上でEC2のインスタンス4つを4月頭から6月末まで動かしてデータを取得しました。財布へのダメージも4倍! しかしおかげで複数IPアドレスで観測した時に生じる差分について知ることができました。

アクセス件数の推移

f:id:mztnex:20151026010203p:plain 2015年4月から6月までEC2の4インスタンスで観測したSSHサーバへのアクセス件数

まずはベタに各インスタンスに対するアクセス件数を時間軸で見たものです。A, B, C, Dがそれぞれのインスタンスになりますが、 4つともアクセス件数の傾向にそれほど大きなブレ方はしていないことがわかります。これらのインスタンスが使っているIPアドレスは どこにも広告していないので基本的には全て無差別に打ち込まれている攻撃であると言えます。そのため特定の組織などに対する 攻撃とは異なるかもしれませんが、このようなアクセスは使用しているIPアドレスに関わらず、安定(?)して日々起きていることがわかります。

アクセス先ポート番号の件数

f:id:mztnex:20151026010325p:plain 2015年4月から6月までEC2の4インスタンスで観測したSSHサーバに対するアクセス先ポート番号の件数

つづいてアクセス先ポート番号の分布です。4インスタンスの合計値から上位20件をグラフにしてみました。 当然ながらデフォルトポートである22番へのアクセスがダントツですが、それ以外にも様々なポート番号に対して アクセスが来ていることがわかります。ちなみに観測されたポート番号は合計56種類となっており、 505018080 などといったSSHとは全く関係なさそうなポート番号もターゲットとなっていました。

今回利用したハニーポットは特にSSHサーバを偽装するわけではなく、 アクセスしてきた接続元のホストに対してSYN-ACKを返すだけで、あとは勝手に相手が送ってくれたデータをせっせと回収します。 ではなぜ22番ポート以外もSSHだとわかったのか?というとSSHの接続確立時に相手が勝手にバナーとして SSH-2.0-PUTTY のような文字列を送ってきてくれるので、そこからSSHをターゲットにしているということがわかります。 なかにはSSH-2.0-paramiko_1.15.2SSH-2.0-libssh2_1.4.2のように、あからさまにツール使ってますぜと宣伝してくれている やつもいたりします。 しかし先に述べたとおりこちらからは何も情報を渡していないため、相手は攻撃先がSSHサーバであるかどうかを確認などせずに22番以外の ポートに接続をしにきているということがわかります。「ポート番号を変えているからパスワード認証でも大丈夫だよね」とか 「ポートスキャンを止めているからどこがSSHのポート番号かわからないよね」と考えている管理者の方はぜひ設定の見直しをお勧めいたします。

アクセス先IPアドレスと攻撃元IPアドレスの関係

f:id:mztnex:20151026010340p:plain 2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレスの件数(アクセス先IPアドレス毎)

それではようやく複数インスタンスを使ってデータ収集した強みをみたいと思います。 気になることの一つとして「攻撃者はIPアドレスのレンジを舐めるように攻撃しているのでは?」ということだと思います。 実際にSSHにかぎらずport sweep(アドレスレンジに対して特定のポートが空いていないか順番に確認するタイプのスキャン)などでは そういった挙動も見られます。

上の表は各インスタンス(A, B, C, D)で観測されたかどうかと、それぞれで観測されたIPアドレスのユニークな数になります。 観測されたIPアドレスは全部で6,669件ですが、そのうちの約80%にあたる5344件の攻撃元IPアドレスがどれか一つのインスタンスでのみ 観測されているということになります。それぞれのインスタンスはある程度同じレンジにおさまっていたため、 このことから 攻撃者は近接するアドレスに対して何度も出現する可能性が高いとは言えない ということがわかります。 先ほどのポート番号に比べると直接的な対策ができるような類のものではありませんが、例えば自組織で管理されている サーバでSSHの不審なアクセス(Brute forceなど)が発生したさいに他のサーバも利用するブラックリストに追加する、 というような対策はそれほど効果的ではないかもしれません。(もちろん、残り20%は複数インスタンスで観測されているので 無意味ということはありませんが、それでも全インスタンスで観測されたアドレスは約6.5%ほどになっています)

攻撃元IPアドレス毎の接続試行回数

f:id:mztnex:20151026010355p:plain 2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレス毎の接続試行回数の分布(n<10)

最後にご紹介するのが1つの攻撃元IPアドレスからやってくるSSHアクセスは何回まで試行されるか?ということをグラフにしたものです。 先述したとおり、このデータ収集はあくまでTCPセッションが確立したとみせかけてデータを送信させるだけという仕様になっているため、 本当にBrute force attackのようなパスワード試行された回数をカウントしているわけではありません。 しかし、通信状態の問題などでうまく接続できないなどのケースが考えられるため、相手がどれくらいしつこかったのかということを 知る指標にできるかと思います。

このグラフでは1つのインスタンスでのみ観測された5344件のIPアドレスに対してそれぞれのアドレスは何度接続試行したのかを ヒストグラムで表したものとなります。一番左のバーが1回だけの試行だった攻撃元IPアドレスのかたまりになるのですが、 これを見るとほとんどの攻撃元IPアドレスが試行1回目でダメそうだったらその時点で諦めているということがわかります。 このグラフは試行10回までの分布しか表示していませんが、10回以上試行してきたIPアドレスは16件だけでした。 全体的に非常に諦めがよい、ということを読み取ることができます。

しかし、ここで最初にふれた情報処理学会コンピュータセキュリティシンポジウム2015の話に戻ってくるのですが、 富士通研究所の齊藤さんが発表された「SSHログインセンサによるSTBF(Brute Force attacks with Single Trials)の観測」において 一つのIPアドレスからパスワード試行が1回だけ実施されて、次は別のIPアドレスから試行されて、というのを繰り返すBrute force攻撃が確認されたという 事例が報告されていました。これは、一つのホストからパスワード試行を繰り返すと防御側に目立って接続拒否されたり、 共有されているブラックリストに掲載されてしまい他の環境に対しても攻撃ができなるなることを攻撃者が警戒した結果、 ボットネットのように悪性ホストを大量に所有(またはレンタル)している攻撃者が目立たないように1回だけパスワード試行をして去る、という 一撃離脱型の攻撃が連続して発生しているということだと考えられます。 この攻撃に対してはIPアドレスを基準としたパスワード試行回数制限による対策がほぼ無効化されてしまうということが言えます。

実際にこの攻撃がどのくらい世の中に蔓延しているかについては発表者の方も今後調査を継続していくとおっしゃられていましたが、 ここで紹介した分析からもそのような種類の攻撃が発生している可能性を示唆する結果となりました。 AWSでのインスタンスに限りませんが、SSHでリモートアクセスをしているホストについては 今一度設定の見直しなどをしたほうがよいかもしれません。