Got Some \W+ech?

Could be Japanese. Could be English. Android, セキュリティ, 機械学習などをメインに、たまにポエムったり雑感記載したりします。

JTB不正アクセス & 個人情報流出についてまとめてみた

更新履歴

  • (6/15更新)下記にてpiyologが更新されているので、そちらを見つつ足りてない情報を加え、情報を再整理d.hatena.ne.jp
  • (6/16更新)6/15午前から6/16 0時までに公表された情報を追加
  • (6/16 18:20更新)タイムラインを更新
  • (6/17 01:30更新)6/16から6/17 0時までに公表された情報を追加
  • (6/20 01:17更新)6/17から6/20 0時までに公表された情報を追加
  • (6/27 19:00更新)6/20から6/27 までに公表された情報を追加

イントロ

  • 後でpiyologと答え合わせする用エントリ。

  • 2016/6/14、JTBグループは株式会社i.JTBのサーバーに、外部からの不正アクセスがあったことを報告しました。

タイムライン*1*2

  • ここではすべて2016年内での出来事とします
日時 出来事 備考
3/15 i.JTBの従業員がメール上の添付ファイルを開いたことでパソコンが感染 取引先を装ったメール。この時点で感染は認知されず。最終的にサーバー2台2台以上・PC6台に感染拡大*3
3/19 JTB情報システム(JSS)が内部Web*4サーバから外部への不審通信を最初に確認。遮断作業を開始。 当該サーバは本来個人情報を含まない。システム監視会社によって検知。継続的な不信通信をブラックリストに登録する作業をおこなっていた。遮断に関する報告はi.JTBからJTBにはなかった*5*63連休
3/20 Webサーバーを社内ネットワークから物理的に切り離し。不審通信は別経路で継続 「当該日に不審通信を全遮断することは業務的にも技術的にも可能だった」*7 3連休
3/21 不正侵入者はデータベースにアクセスしCSVファイルを生成。制御サーバにCSVファイル設置し、その日の内に削除.*8 | データファイルが作成された制御サーバと不審通信を発したサーバは別*93連休
3/24 内部サーバから外部への不審通信を最後に確認
3/25 遮断作業を終了。JSSがJTB IT企画部門に報告 *10
3/XX~3/YY ネットワーク内の全サーバとパソコンを調査 3/19 ~ 3/30?
4/1 不正侵入者が作成・削除したデータファイルの存在を確認。CSIRT立ち上げ。 削除した日付については記述がない作成日に同時に削除。CSIRT自体は前々から準備していた。
X/XX~5/13 外部セキュリティ専門会社と共同で、ウイルスを駆除・データファイルの復元と不正アクセスの調査・分析・対応を実施 調査開始のタイミングの記述はない。復元対象のデータファイルは不正侵入者が作成・削除したデータファイルかと思われる
5/13 復元したデータファイルに個人情報が含まれることを確認。i.JTBよりJTBにエスカレーション*11個人情報流出の可能性を認定。事故対策本部を設置。 不審な通信とデータファイルの関係性が不明だったために”可能性"? 不審通信によるファイル持ち出しは確認されていないが、可能性は否定できないとのこと
5/13~X/XX 直ちにデータを正規化し、約793693万件の個人情報があることを確認 *12
5/17 JTB 高橋社長が情報を認知
5/30 警察に相談  被害届か明言はされてない被害届はだしていない*13 
5/31 観光庁に相談 *14
X/XX 問い合わせ窓口を設置 
6/10 対象顧客が判明 *15
X/XX~ 対象のユーザーへメールによる通知を開始  1ヶ月以内に連絡するとのこと*16
6/14 発表 && 調査継続。警察による操作開始 不正アクセス禁止法違反や不正指令電磁的記録供用の容疑にて操作中*17
6/15 個人情報流出の可能性があるユーザーへの注意喚起 *18 送信元メールアドレス、添付ファイル、ヒアリング内容に関して通達。観光庁が再発防止策の提出依頼*19
6/17 国交省、再発防止策を検討する有識者検討会の設置を発表 *20
6/24 観光庁への再発防止策の報告期限。該当する顧客への連絡は24日午前までに、ほぼすべて終了 「さまざまな企業や団体で個人情報が流出した事案の教訓が生かされておらず、大変遺憾だ」「全体的に遅すぎる」
7/1 末永安生専務をCISOに任命。社長直下のITセキュリティ専任統括部門を設置 *21

攻撃の概要

f:id:kengoscal:20160616023320p:plain *22

当時のJTBの体制

発覚以前

  • セキュリティを横断的に見る部門は存在せず *23

    5.対策: (中略)ジェイティービー(グループ本社)内にITセキュリティ専任統括部門を設置いたします

  • CSIRTも存在せず *24

    サイバー攻撃の緊急対応チームも当時は存在しなかった

  • 一部ログを取得していなかった*25
  • すぐ情報を公開しなかったのは「不安と混乱を招くと考え、特定できた段階で公表する方針を取った」*26
  • 対象データを暗号化していなかった。*27
  • 実績データベースへアクセス可能な社員は1人だが、そのPCは乗っ取られていない*28
  • 実績データベースのデータを使うBI(ビジネスインテリジェンス)ツールは25人の社員がアカウントを持っていたが、今事案との関連性は薄いと見られる*29

発覚後

  • 問い合わせ窓口を設置
    • スタッフ300名規模*30
    • 6/14時点で数千件の問い合わせ
  • 警察への相談済み(調査中)
  • 7/1までにITセキュリティ専任統括部門を設置

送信された標的型メール*31*32*33*34*35

  • 件名: 航空券控え添付のご連絡
  • メアド: ごくごく普通のありがちな日本人の苗字@全日本空輸ドメイン*36
  • 署名: 取引先の署名
  • 添付ファイル名:
    • 「北京行きのEチケット」パターン*37
    • 「E-TKT控え」パターン*38
      • 社内でもよく使われる
  • 添付ファイル種別: PDF。
    • 実態はELIRKS(の亜種?)とPluX(の亜種?)に当該PCを感染させる新種マルウェア
  • オペレータから返信。エラーメールがかえってくる
    • 開封すると航空券のeチケットが表示される
  • メールヘッダー: 海外のレンタルサーバー(香港を経由)*39
  • 本文内容
    • 本文無しパターン*40
    • 「お世話になっております』などの通常の挨拶文のあとに、『eチケットを送付しますのでご確認下さい』と偽った内容パターン*41
  • 添付ファイル開封者: オペレータ
    • 標的型メールの訓練済み
      • JTB全体では定期的に訓練していたようだが、当該オペレータが複数回の訓練を受けていたかは不明

被害範囲

  • 個人情報悪用の報告もない
  • 流出は確定されていない
  • 流出に関するログが確認できないため、わからない*42
    • 尚、一部ログを取得していなかったとのこと
    • 可能性は否定されていない*43
  • 知らない宛先から不審なメールマガジンが届いた」といった指摘がおよそ100件よせられた
    • 詳細調査中*44

個人情報の項目

  • 以下の一部か全て

    • 氏名(漢字、カタカナ、ローマ字)
    • 性別
    • 生年月日
    • メアド
    • 住所
    • 郵便番号
    • 電話番号
    • パスポート番号
    • パスポート取得日
      • 現在で有効なものは約4300件4359件*45
  • 訪日外国人の情報も含む*46

  • 以下の情報は含まれない*47
    • 予約した旅行の内容
    • クレカ情報

対象となるユーザー

JTB関連のサービス

  • 以下のサービスでオンライン予約したユーザー679万人
    • JTBホームページ、るるぶトラベル、JAPANiCAN
    • オンライン転売提携先でJTB商品を予約したユーザー
      • JTBグループ内外問わない
      • ただし以下の商品を予約したユーザーは対象にならない
      • JTB旅物語、高速バス、現地観光プラン、レジャーチケット、定期観光バス、レストラン、海外ダイナミックパッケージ、海外航空券、海外ホテル、海外現地オプショナルツアー、その他旅行関連商品
    • また、以下の店舗で予約したユーザーは対象にならない
      • JTB店舗、提携販売点店舗、JTB旅物語販売センター
  • "ネットで予約後、店舗でご清算のお客様の情報は対象となります。" <- ??
    • 予約 && オンライン清算が対象??
  • 期間についての記述はない
    • 2007/9/28 ~ 2016/3/21*48

別会社

NTTドコモのdトラベルユーザー*49*50

  • 対象ユーザー: 2014/2/27~2016/3/21に予約したユーザー
  • 対象範囲: 33万人
  • 窓口設置済み
  • ドコモの吉澤和弘新社長が謝罪と対策の強化を表明

auトラベル by DeNAトラベルを*51

  • 対象ユーザー: 「auトラベル by DeNAトラベル」国内宿サービスを利用したことのあるユーザー
    • 期間は不明
  • 対象範囲: 4,462人
  • 窓口設置済み

対策

不正アクセス対策

  • 特定された外部への不審な通信の遮断
  • 感染範囲の特定とウイルスの駆除
  • 個人情報へのアクセス制御の強化

グループ全体の対策

  • JTBグループ本社にITセキュリティ千人統括部門を設置
  • 実践的な教育演習でサイバー攻撃の察知力を高める (全グループ社員向け)

被害額試算

不明な点

ウイルス感染からの流れ

  • 最初に不審通信を確認してから何をしたのか*52
  • 感染したパソコンがどの様な用途で使われたか。
    • 踏み台もしくは直接操作されたのか
    • 内部パスワードを取得されたのか
      • 取得したパスワードで社内ツールを使ったのか
      • 取得したパスワードでサーバにログインしたのか
  • サーバ上でどうファイル作成・削除の操作する権限を得たか。
  • サーバ上に普段はないデータをどの様に取得したか。

    • ディレクトリサーバ経由ではない*53
    • 遠隔操作である可能性が高い*54
    • データコピー元のサーバは1人しかアクセス権限のないサーバー*55
      • アクセス権限をもつ社員のPCは感染していない*56
  • 不審通信はどの様な内容なのか => 不審なパケットデータだったか*57

    • 宛先・通信種別は一定なのか
    • ファイルを送信するような通信なのか
    • 単純にいままでに観測されていない通信だったのか
    • 普段の通信量とどれぐらい違うか(ちがわなそう)
  • 何をもってして流出の可能性があると判断したか
    • 不正アクセス者が作成・削除したファイルの存在で判断したか
    • ファイルを外部に送信するような不審通信があったのか
    • ウイルスの解析結果をもって判断したのか

インパク

  • パスポート情報漏洩(の可能性)がどれほどのインパクトがあるのか
    • 直接的な賠償額(クレカとかだと500円の金券などをよく聞く)現時点では顧客への一律的な補償は考えていない*58
    • その後の2次的な被害額
    • 直接的なインパクトは余りなさそうだ*59 *JTBホームページ」で6月21日までの月間販売額が前年同期比1割減*60
  • るるぶトラベル」では6月21日までの月間販売額が前年と同じぐらい
    • いずれも通常なら1~2割増

事後対応

  • なぜ情報公開が認知後すぐでなかったか
    • CSVデータを復元しても正規化が必要で、それだけではユーザーの特定ができず、余計な混乱をまねきたくなかったから
  • パスポート情報漏洩(の可能性)に対するエンドユーザーの対策
    • 対策をJTBがしめすのか。外務省がしめすのか。
    • 可能性であれば対応不要で終わらせるのか。

その他

  • ホームページのニュースリリース配下に「不正アクセスによる個人情報流出の可能性について」がないのはなぜ?
  • 公表した日付と警察が捜査に着手した日付が同じ
  • 一部のログが取得されてなかッタ理由
    • 意図的ではなく様々なWebサイトを運営する中で統一できなかったとみられる*61

その他

  • 後でpiyologと答え合わせする。
  • (2016/6/15追記) piyologと初期情報の量が異なるので、piyologが取得している情報ソースのリストを作る
    • 見せ方に関しては、それをまとめてどう使うかは作成者によって違うので、これはこれでよし
  • (2016/6/20追記)2日置いてみたが特にめぼしい新情報がなかった(非営業日だからか?)。とりあえずここまでの振返りをする

振返り

まず最初に

  • 今回はJTBがいちはやく整理された公式報告を公表していたので、概要が掴みやすかった。
  • 恐らく、こういうタイプのインシデントはレアなのだと思うが、今後のインシデントを気にする(いや、起こらないのがベストなのだが)

情報ソースについて

  • Googleでの検索"JTB 情報流出 情報漏洩"
  • Feedlyでのニュース登録: Security NEXT, ITmedia, ITpro, Jpcert/CC, ZDNet, @IT, INTERNET Watch
  • piyologを見て利用したニュースサイト: 日経、毎日、朝日、産経、時事通信、読売
  • 上記のサイトをウォチしてて思ったことは、大手ニュース(日経、毎日...)の情報提供は早く且つ頻繁だということ。
    • ただし各ニュースが全てを完結しているのではなく、欠けていたり、定義が異なったりしていた
    • 当たり前だけど複数の情報ソースを通じてフィルターするのは大事。仮に共通点がない場合は、確定していないということで、断定めいた文脈にしないよう本エントリでは意識した。
    • 産経の記事がどの大手ニュースよりも初情報で踏み込んだ内容をリリースしていたイメージ
    • 日経の記事が最速だったイメージ
    • 日経と毎日の記事は更新頻度が高いイメージ
    • まとめを作りたいなら、大手ニュースをくまなく見るのがヨイ
  • 逆に、非大手ニュースはリリース時期も後ろで、内容はほぼ共通していた
    • まとめだけをみたいなら、非大手ニュースを数個見ればヨサそう

情報整理について

  • まあまあ出来たのではないかと。できるだけpiyologを見ずに情報収集・整理したが(途中みてしまったが...)、取りこぼしたものはあまり無かったので。
  • 勿論、取りこぼしたものもある。ので、更新頻度が高く、また情報密度も濃いpiyologはやっぱり凄かった

まとめの構成

GotSome \W+ech?

  • 更新内容 -> イントロ -> タイムライン -> 攻撃の概要 -> JTBの体制(発覚前と後) -> 流出した可能性のある情報の項目 -> 対象となる可能性のあるユーザー ->対策 ->被害額 -> 不明点

piyolog

  • 公式発表 -> タイムライン(提携先も含む) -> 被害状況 -> 発端 -> 原因 -> 対策…対応 -> ユーザーへの対応 -> 更新履歴

  • まず最初に更新内容を持ってくるのはやめる。更新が増えれば増える分だけ、リーダーが欲しい情報に到達するまでの距離と時間が長くなるから

  • タイムラインを直後に持ってきたのは良かった。提携先を別テーブルに切り出すことはまでは考えつかなかったけど....備考カラムを作ったのは良い
  • 此処から先が明確にpiyologの構成と大きく異なってくる。piyologの場合は"被害状況"と軸をユーザーと現在の時間に置いてるが、本エントリの場合は「攻撃の概要」と環境に軸を置いている。これは本エントリが、この話を自分の担当する環境とのdiffをとり改善ポイントを洗い出せることを目的としているので、この書き方になっている。逆にpiyologは広範囲への情報共有が主目的である(気がする)から、軸が異なるのではないかと推測する。よって、どっちが良い悪いではないと思う。
  • それを踏まえた上でいうと、本エントリの流れと粒度は若干ぎこちない。攻撃内容ときたからには、攻撃結果(攻撃成否, 攻撃対象,..)が次にくるべきではないか。で、その後に対策がくるのがキモチイと思われる。よって、今後新しく書くとしたら...

    • イントロ -> タイムライン -> 攻撃の概要 -> 攻撃の成否 -> 攻撃の影響(範囲、期間、被害額) -> 原因 -> 対策 -> 不明点 -> 更新内容
  • という訳で、次は構成にもうちょっと気をつかって書いてみる

  • ミニネタとして、はてなでは大見出しと中見出し2つで構成したほうがよさそう。少見出しと中見出しの見た目に違いがないように思える
    • piyologの標的型メールのみやすさが圧倒的だった
    • 問い合わせ窓口は想定リーダーが異なるから本ブログではいいかな...

今後

  • 本件について引き続きウォチ
    • 現在わかっていることを元に、仮説を立ててみたいと思う
  • 今後のインシデントもまとめていけたらおもう。どれを線引にするかは自分の匙加減次第で、自分にもわからない。何となくじゃないかな。
  • piyologはやっぱり凄い

*1:JTBグループサイト

*2:標的型メール急増 情報流出、経営に打撃も :日本経済新聞

*3:JTB情報流出、感染サーバー3台以上 再発防止策など公表 - 産経ニュース

*4:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*5:JTB個人情報793万件流出か?…標的型攻撃の巧妙な手口 : 科学 : 読売新聞(YOMIURI ONLINE)

*6:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*7:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*8:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*9:JTB、最大793万人分の情報流出か 不正アクセスで:朝日新聞デジタル

*10:標的型メール急増 情報流出、経営に打撃も :日本経済新聞

*11:記者の眼 - (4/5)JTBの情報漏洩事故報告は遅すぎだ! ではいつだったら良かったのか?:ITpro

*12:JTB、情報流出で再発防止策など報告 観光庁に :日本経済新聞

*13:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*14:JTB情報漏洩、国交省が有識者委設置へ :日本経済新聞

*15:JTB、個人情報流出か、約793万人分-7月に対策部門新設 | 旅行業界 最新情報 トラベルビジョン

*16:JTBの端末、海外サーバーと不審通信 顧客情報流出 :日本経済新聞

*17:不正アクセス容疑で捜査=JTB情報流出-警視庁:時事ドットコム

*18:http://www.jtbcorp.jp/jp/160615.html

*19:http://www3.nhk.or.jp/news/html/20160615/k10010557611000.html

*20:全文表示 | 国交省へ「批判の矛先」向く可能性も JTB個人情報流出と「対応の遅さ」 : J-CASTニュース

*21:JTB、情報流出で再発防止策を報告 外部調査委を設置 :日本経済新聞

*22:標的型攻撃の概要。取材を基に編集部で作成した

*23:JTBグループサイト

*24:標的型メール急増 情報流出、経営に打撃も :日本経済新聞

*25:ニュース - 「流出事実ないがお客様にお詫びする」、793万人の情報流出可能性でJTBの高橋社長が謝罪:ITpro

*26:JTB:不正アクセス、最大793万人分の情報流出か - 毎日新聞

*27:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*28:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*29:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*30:JTB、個人情報流出か、約793万人分-7月に対策部門新設 | 旅行業界 最新情報 トラベルビジョン

*31:ニュース - 「流出事実ないがお客様にお詫びする」、793万人の情報流出可能性でJTBの高橋社長が謝罪:ITpro

*32:JTB、外部侵入者が閲覧の可能性 「標的型メール」か :日本経済新聞

*33:JTB情報流出:また「標的型メール」 巧妙偽装、防げず - 毎日新聞

*34:793万人分の個人情報流出…JTB、対応後手に 巧妙な標的型メール「脅威を十分に認識していなかった」(2/2ページ) - 産経ニュース

*35:793万人分の個人情報流出…JTB、対応後手に 巧妙な標的型メール「脅威を十分に認識していなかった」(1/2ページ) - 産経ニュース

*36:JTBの顧客情報流出、ウイルス発信源は中国か :日本経済新聞

*37:【情報流出】あなたは見抜けるか JTB がはまった「巧妙なメール」の罠とは (BuzzFeed Japan) - Yahoo!ニュース

*38:JTB個人情報793万件流出か?…標的型攻撃の巧妙な手口 : 科学 : 読売新聞(YOMIURI ONLINE)

*39:【JTB情報流出】全日空装うメールで感染 香港を経由 - 産経ニュース

*40:【情報流出】あなたは見抜けるか JTB がはまった「巧妙なメール」の罠とは (BuzzFeed Japan) - Yahoo!ニュース

*41:JTB個人情報793万件流出か?…標的型攻撃の巧妙な手口 : 科学 : 読売新聞(YOMIURI ONLINE)

*42:ニュース - 「流出事実ないがお客様にお詫びする」、793万人の情報流出可能性でJTBの高橋社長が謝罪:ITpro

*43:JTB、外部侵入者が閲覧の可能性 「標的型メール」か :日本経済新聞

*44:http://www3.nhk.or.jp/news/html/20160624/k10010570411000.html

*45:JTB、個人情報流出か、約793万人分-7月に対策部門新設 | 旅行業界 最新情報 トラベルビジョン

*46:JTB、顧客情報793万人分流出か 取引先装うメール :日本経済新聞

*47:JTB、最大793万人分の情報流出か 不正アクセスで:朝日新聞デジタル

*48:http://www.yomiuri.co.jp/national/20160614-OYT1T50095.html

*49:報道発表資料 : 提携先のJTB社のグループ会社サーバーへの不正アクセスに伴う「dトラベル」の個人情報流出の可能性について | お知らせ | NTTドコモ

*50:ドコモ、JTBへの不正アクセスに伴う「dトラベル」の33万人の個人情報流出か | マイナビニュース

*51:株式会社i.JTBへの不正アクセスによる個人情報流出の可能性に関するお知らせ|auトラベル

*52:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*53:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*54:793万人分の個人情報流出…JTB、対応後手に 巧妙な標的型メール「脅威を十分に認識していなかった」(2/2ページ) - 産経ニュース

*55:793万人分の個人情報流出…JTB、対応後手に 巧妙な標的型メール「脅威を十分に認識していなかった」(2/2ページ) - 産経ニュース

*56:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*57:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

*58:JTB社長、情報流出問題「補償は個別対応」 一律は考えず :日本経済新聞

*59:JTB個人情報流出事件「パスポート番号」は悪用できるのか調べてみたときのメモ

*60:http://www.nikkei.com/article/DGXLASDZ24HHZ_U6A620C1000000/

*61:News & Trend - (2/4)[詳報]JTBを襲った標的型攻撃:ITpro

2016年Hardening 100 Value x Valueを振り返ってみる

2016/6/4~2016/6/5に沖縄県宜野湾市で開催されたHardening 100 Value x Valueにチームリーダーとして参加したので、振り返って見ようと思う。ただし、技術情報やシステム構成は秘密扱いなので、どんな攻撃があったかは話さない(話せない)のでご容赦を。ちなみに自費でいった。

まずは

  • ともに戦ってくれたチームメンバーの皆様、ありがとうございました。これ以上のメンツは望めないでしょう。
  • 多くの学びと困難を準備してくださった運営委員の皆様、ありがとうございました。

Hardening 100 Value x Valueとは?

  • 堅牢化(Hardening)の腕を競う大会
  • これには開発・運用・検知といった技術の軸に加え、マネジメント・広報などの非技術部の連携も必要
  • また、運営により準備されているリソースに投資し、チームを強化・補強することが可能
  • これら役割・手法を最適に組み合わせValueを最大化することを試みる
  • 今回のValueは、eコマースサイトの見込み販売力(Sales Potential)を含む複数の指標が計測された。
    • 技術点 - Technical Merit
    • 顧客点 - Customer Impression
    • 対応点 - Incident Response
    • 経済点 - Market Creation
    • 協調点 - Information Sharing

目的: 何故参加(応募)したか

  • 前職(SI)でもIRやってたけど総合判断が不要だった。なので俯瞰的なIR対応をしたかった
  • 実際の攻撃によって、どのような被害をうけるかシミュレートしたかった
  • 非技術的な部分も含めたマネージメントの経験も
  • 目標としてはあわよくば1位をとる気概

流れ

現地入り前

  • Slack上にチャネルを作り、そこでやりとり
  • エクセル上でメンバーのスキルマップを作成。それを元に担当を決め。
  • サーバ堅牢化の確認と設定手順を作成。
  • 特にハングアウトなどによる顔合わせは行っておらず。

Hardening 前日(0日目)

  • メンバーと顔合わせ
  • 食事処で作戦会議
    • 運営から指示されたことの対応
    • 資料の読み合わせ
    • 担当の確認
    • 初期動作の設定割り振り

Hardening Day(1日目)

  • 序盤(最初の2時間くらい?)は防御力向上を目指す
  • しかけられた攻撃をいかに検知・復旧させるか
  • 売上があがるような施策をうつ

Softening Day(2日目)

  • 振り返り発表
  • 結果発表
  • その他のプレゼン

結果

  • ビリ out of 12 (KBC賞)
  • 他チームとの最終スコアを比較すると、販売力に大きな差があった
  • 他のスコアについても平均より下回っている

振返り

  • 後で、もうちょっと綺麗に整理する

現地入り前

  • 通常Linuxサーバのハードニング手順を作成したことはおk
  • それにあわせてメンバーの役割をそれぞれ分割していたこともナイス
  • 細かいサービスの調査概要は書いてたけど、もっと詳細な手順は書いてなかったのがマイナス
    • 細かいサービスは機密に触れそうなのでぼかしてる。
  • これらの内容はスプレッドシートに書いた。それはよい。
    • だが遅すぎた。もっと各担当者が準備できる期間をもたせておけばよかった
    • 3weeksほど前にやっておけばよかったかもしれない。who knows.
    • 後、システム運用の面に偏りすぎた。ビジネス面の対応(テンプレ作成)がなかった。
  • Windowsは作業端末として持っておこう。VM越しのファイルやりとり・キーボード配列、どれをとっても作業端末としてMacよりベター
  • 又、できればもう一台、調査用としてあったほうが良い。VMとブラウザを行き来するのはめんどいぞ!

Hardening 前日(0日目)

  • 可能であればこの日は夕方くらいには到着した方がいい
  • 宿泊先はメンバー間で統一ないしは近場にしたほうがいい
    • 移動するのはダルい。
    • 次やるのであれば、会議室かります
  • ここで何故かスプレッドシートに記載した手順の共有をしなかった。何故だ。疲れていたからか。
    • 痛恨のミスその1
  • タスク管理+優先順位決め担当者を置かなかった
    • 痛恨のミスその2
    • 勿論、その担当者が何をやるか具体化も必要
      • X時間に1回、広告を買う、タスク整理する、売上状況を確認する etc etc
    • この判断の根拠はチーム人数の総数。「前回は10人超だったけど、今回は5人だから皆手を動かさなきゃね」という考え
    • システム運用だけでなく"ビジネス"の視点がすっぽり抜け落ちてた証拠。
      • ユーザー企業に務める自分がこれを抜かしてたのが驚異。
    • 広報も担わせるか、それは難しい。判断がわかれると思う。だが、経験上、この人に集約すべきだろう。
  • この競技において最もスコアに関わる基本方針についてメンバー間で落とし込めてなかった
    • 痛恨のミスその3
  • 資料の読み込みはしたが、中途半端だった
    • 読み込む為の観点が整理されてなかった
    • 読み込み自体も役割をわけて重要箇所をまとめる事がよいかもしれない
      • 企業(仮)情報、評価方法、環境構成(含むシステム運用ルール)、マーケットプレイスといった形でやるのがよいのではないか。
    • 全員で1ページ目から順に読むのは無駄が多い。
  • やっぱり紙媒体が最強ですわ
    • プリントアウトできる宿泊先にする
  • マーケットプレイスにおける購入内容・優先順位を決めたのはナイス
    • 環境構成に従った購入方法にすべきであった
    • そもそも優先順位は一番足りてないもの = 人手だと感じた。優秀かつ自発的に動ける人間が機器そのものより、財産になるのである。
    • そういう感傷的なものもそうだが、慣れてないアプライアンスを使うのは時間的にもツライ
      • マーケットプレイスにさいた作業時間、慣れようとした作業時間、設定に落としこむ作業時間を考えたら、そのコストメリットはあまりないのかもしれない。
      • でも買わざるを得ない。
  • この時点で環境構成がわかっていたので、ネットでマニュアル等を探すべきだった

Hardening Day(1日目)

  • 事前準備した手順の共有がなかったことによる問題
    • バックアップがとれず!
    • 事前に準備していたことが9割がたできなかった
    • 痛恨のミスその1−1
  • 基本的にタスク管理+優先順位決め担当者を置かなかったことによる問題
    • 購入担当の導入後フォローをせず、購入物の置物化
    • インシデント発生時の場当たり的対応化。レイヤーごとの切り分けをせず。
      • 痛恨のミスその2−1。
      • 冷静にやれば、もっと早く対応できてたはず。
      • 1)NW構成図を書いて 2)影響範囲を特定し 3)各タスクに落としこむ切り分け作業をしなければいけない
    • 「こういう対応したらいいんじゃない?」と言うナイスアイディアをスルー(皆手を動かすのに忙しすぎた)
    • 「え、今それやるの?」「え、やること変えちゃったの?」と言った事態が発生。
    • 在庫管理をせず!なんということか
      • サーバ乗っ取られにより売上があがってないと、実は考えていたのではないか。在庫の管理をしてないのに。
    • 売上をちゃんと追ってたのはよい。
    • 資産と広告単価率と比較して、常に広告をうちまくる判断をしたのもよい
    • あるメンバーが気づいていた脆弱性を他のメンバーに共有されない事象が発生!ちゃんとエスカレーションしよう!
  • 基本方針を共通認識化出来てなかったことによる問題
    • システム優先な判断になりすぎた。ビジネスへのリソース比重が少なかった。
    • 乗っ取られたサーバを復旧するためのサービスを敢えて使わない選択をしたこと。
      • 毎度のことだが、乗っ取られた手法はかけない
      • 痛恨のミスその3−1
  • その他
    • ユーザーへの報告・とあるセキュリティ組織への報告など、メンバー間情報共有だけでなく、一般的な組織がする情報共有も足りてなかった
    • 対処方法が分からなかった場合、ダメ元で運営に質問してみたら教えてくれた。聞くべし。周りを巻き込むべし。これも大事な能力だ!
      • コレが一番できてたのがチーム: アンセキュアだった。凄い巻き込み力だった。

Hardening Day(2日目)

  • 特に無し
  • iPhone落として割ったぐらい
  • 帰宅!
    • 気持ちをリセットするために、もう1日ステイすることをおすすめする。

他のチーム

  • グランプリ: No. Bee。技術と顧客対応が頭一つ抜けていた印象です。また、プレゼンを聞く限りチーム分けが綿密に出来ていた印象
  • CTC賞: Love Winner。スポンサーであるCTC様の賞。No. Beeについで全体のスコアが高く、かつ投資額も物凄かった。
  • LAC賞: アンセキュア。スポンサーであるLAC様の賞。Love Winnerよりも投資額が高いこともそうだが、周辺の巻き込み力が非常に高いことが印象的。

参加した感想

  • 最高だった。自分のチームだけでなく、他のチームとも関われて楽しかった
  • 自分に足りないのは以下
    • タスク管理、マネジメント、linux系の操作、実際のエグゼキューション
    • 自分でやり過ぎようとする部分
  • チームビルディング大事。
  • アンチパターンの塊だったのではないか。これを是非、業務に活かして欲しい。これだけで次の半年のLTができそう。
    • 本競技はプラクティカルな極みなので、是非、企業の人間には参考にしてほしい。マジで。
  • 昨年度のチームにヒアリングしたのにそれを活用できなかった(というよりしなかった)
    • 判断のミス。
  • 逆に良かったことは
    • 事前準備には結構力をいれたのではないだろうか。ただこの事前準備もシステム運用に偏りすぎてた気がする。
  • KBC賞は辛かった。すでにスコア発表でライフはもうゼロだったので、これは相当キタ。
    • KBC賞: 国際電子ビジネス専門学校の紹介パンフ・入学願書・割引券のセットと激励の言葉

その他

  • iPhone落として画面割れた。
  • 帰りのLCCの航空券が欠航になった。+2万出費
  • これで今年の厄は落ちただろう。後は上がるだけだ。

おまけ

  • 沖縄の海は最高だった。入れてないけど。

f:id:kengoscal:20160607021938p:plain

RecyclerViewAdapterのnotifyDataSetChangedとnotifyItemRangeChangedの違い

  • notifyDataSetChangedでリスト(recyclerView)を更新したい時に、意図しない挙動になってた
    • このリスト内の値がかわることはあるけども、構成自体は固定だっった。
    • このリストはnestedScrollViewの中にある
    • 例えばあるモデルを選択して、そのモデルをリストにbindしnotifyDataSetChangedをすると、一瞬だけ順番が入れ替わった後に戻るような挙動
    • つまりリスト内のモデルをまるっと更新したときに"ちらつき"が発生していた
  • 最初はynzmさんのRecyclerView の notifyItemChanged() 時のちらつきを止めるかと思ったが、解決できず
  • notifyItemRangeChangedにしたら、"ちらつき”がなくなった
  • 直感的だが、notifyDataSetChangedは下記の通りViewをrelayoutをするので、そこに差分があるように思えた。ので中身をみてみた。
private class RecyclerViewDataObserver extends AdapterDataObserver {
        @Override
        public void onChanged() { // notifyDataSetChanged内部で呼び出される
            assertNotInLayoutOrScroll(null);
            if (mAdapter.hasStableIds()) {
                // TODO Determine what actually changed.
                // This is more important to implement now since this callback will disable all
                // animations because we cannot rely on positions.
                mState.mStructureChanged = true;
                setDataSetChangedAfterLayout();
            } else {
                mState.mStructureChanged = true;
                setDataSetChangedAfterLayout();
            }
            if (!mAdapterHelper.hasPendingUpdates()) {
                requestLayout();
            }
        }

    @Override
        public void onItemRangeInserted(int positionStart, int itemCount) {
            assertNotInLayoutOrScroll(null);
            if (mAdapterHelper.onItemRangeInserted(positionStart, itemCount)) {
                triggerUpdateProcessor();
            }
        }
}
  • このrequestLayout内部で、ViewのrequestLayoutを呼んでいる
  • ViewのrequestLayoutはリファレンスにもある通り、レイアウト構成が変わったときにView階層を再計算させるために呼び出すべきものらしい

Call this when something has changed which has invalidated the layout of this view. This will schedule a layout pass of the view tree.

  • よって構成が固定されているリストのアイテムの更新において、notifyDasetChangedの使用は望ましくないので、notifyItemRangeChangedを使うべし。
  • ただ今までrecyclerViewの更新でnotifyDasetChangedを使用してたこともあったが、今回のようなことはおきなかった。これはnestedScrollViewの中にrecyclerViewを入れていることが関係するかもしれない(再描画が走ってしまいnestedScrollViewの高さが変化してた?)
    • 深く調べるならnestedScrollView及びrecyclerViewをフカボルべき

Railsで1対他のリレーションになっているモデル・コントローラにパラメタを渡したい

  • 最近、所用でRailsでWebアプリを作っているので、その時にぶちあたったメモ
  • 今回は下記をしようと思っています
    • モデルAはモデルBをhas_manyしている
    • モデルBのmodels_pathにアクセスする時、モデルAに紐づくモデルBのみを表示したい

詰まってたこと

  • 例えばViewで下記のようなリンクで、indexに飛ばしたいとすると、idが無いというエラーがでた
<%= link_to 'Bデータ', models_path(a_id) %>
def index
    @models = ModelB.find(params[a_id])
  end

解決

  • ROUTINGに下記を記載。そうすると、 /モデルA/A.id/モデルBへのルーティングが形成される。
  • これをリンクに貼り付ければおk
resources :As do
    resources :Bs
  end
2.2.1 :098 > app.A_Bs_path(1)
 => "/As/1/Bs" 
2.2.1 :099 > 

DroidKaigiで登壇 & スタッフしたから振り返るお

DroidKaigiで登壇 & スタッフしたから振り返るお

おっきなカンファレンスで初めて登壇 + スタッフをやってみたので、色々考えてみる

  • 発表資料はこちら

www.slideshare.net

運営編

何故スタッフに応募したのか

Android界に貢献したかったからです。今まで私をSOやGithub上のソースコードから助けてくれたAndroidエンジニアが集まるイベントなので、そこで私なりのコミュニティへの(今現在出来る)貢献をしようと思いました。今年からはライブラリを始めとしたコードレベルでの貢献もしたくおもってます。

何をした?

参入が遅かったため(12月かな)、基本的に英訳・当日対応(受付など)を主にしました。後、地味に公式アプリにContributorとして参加しています。おっかなびっくりでしたが、自分の出来そうな部分をやってpull req出してました。

f:id:kengoscal:20160223005547p:plain

結果

After-partyでは参加者がワイワイ楽しそうにやってたので、本当にやって良かったです。Androidコミュニティの人っていい意味で大人ですね。器が広い。感謝しかない。反省点としては、いまだにハンドルネームと顔がまっちしないこと....後、次回はもっとコミットしたいです。

登壇編

何故CFPに応募したのか

2つの思いから応募しました。主目的は自分の経験・知識を提供し、良いAndroidアプリ(ひいてはサービス)を世の中に拡大したかったからです。一部でもそれが響いてアプリに活用されてくれれば、そんなに素敵なことはありません。 もう一つの目的は自分を追い込むためです。感覚レベルから検証を経て論理的な考えに昇華し、それを噛み砕いて発表する...というのは中々骨が折れますが、それが出来た時の経験値は、通常業務で得られるそれとは比較になりません。

何を応募したか

  • 明日、敗訴しないためのセキュアコーディング
  • Android Clean Architecture for Dummies In Detail

締め切り1周間前あたりから、自分の強み・Android界隈の話題・潜在的にニーズがありそうな話題・応募状況を考え始め、ちょいちょい文字に起こしながら推敲を重ね、24h前にCFPに提出しました。最初に提出してちょいちょい肉を足していく手法でもよかったかも...出来るかわからないですが。

2つ出したのは、絶対何か話したかったからです。当る確立を高めたかったから。

結果

2つとも採択されました。予定外でした。その後、時間的余裕と自分の強みから前者である「明日、敗訴しないためのセキュアコーディング」を選択しました。後者は自分もまだ手探りだからなぁ〜

準備

セキュアコーディングについて調査しまくりました。最近のインシデントや何が原因でそれが発生するのかを主に調査しました(1月中旬)

わかった事は、セキュアコーディングのガイドライン自体は昔から存在していて、最近のインシデントに起因する脆弱性対策も記載されてるんですよね。そこに課題が見えました。セキュアコーディングあるのに使われてないじゃん、もったいね〜、と。じゃあ、何で読まれないかを開発者の視点でガイドラインを再読しながら考えて気づいたのは、ガイドラインは広範囲すぎてインデックスとして使わなければあかん、しかし開発中にそんなインデックスをいちいち引いてらんない、ということでした(1月下旬)

そう分かったので、セキュアコーディングそのものではなく、各々の開発段階におけるセキュアコーディングと言う形でプロットを作りました。資料自体は結構余裕を持って3日前には作り終わってましたね(2月中旬)

気持ちの問題でいうと、割りと気合をいれて入念に作っていたつもりです。何故ならお金を取るカンファレンスでしゃべるものですから。後、偉大な先輩諸兄が登壇・運営する場なので、中途半端なものは出したくなかったのです。

発表そのもの

発表前は腹式呼吸など瞑想のテクニックで、割りと落ち着いてたと思います。しかし、資料中盤くらいで何故かテンパってしまいました。言いたい所(設計ちゃんとしろ!とかCI環境ちゃんとしよう!とか)を強調せずに、言わなくていいところ(セキュアコーディングそのもの)について話てしまったりなど、練習どおり行かなかったですね。区切りを一個おいて、そこで落ち着けば良かったなあ、と思ってます。又、質疑応答時も??なことを言ってた気がします。

  • 質疑応答に対するフォローアップは下記になります。

qiita.com

結果 & 反省点

全体的には良かったと思います。でも一番重要なポイントのストレスが弱かったから60点です。Cです。アフターパーティで結構それをネタにお話出来て、且つよさ気なフィードバック頂けました。反省点は下記にまとめましたので、質問等あればバシバシください(OperandOSさんを真似して)。

github.com

後、登壇する事は冗談抜きでいいことしかないです。細かい勉強会や業務で腕を磨きつつ、来年も応募して登壇できるようにしたいです。

今後

セキュリティ関係のライブラリやプラグインを作りたいな、と思っています。でも、まずは他の発表資料をキャッチアップしないと!

【2016年2月01日〜07日】忙しい人のためのweeklyニュース

FinTech

フィンテック (FinTech) 10の最新トレンド予測 ~改革は既に始まっている~ | freshtrax | btrax スタッフブログ

http://www.atmarkit.co.jp/ait/articles/1601/13/news020.html/

ニュース - 三菱UFJがFinTechの新組織、銀行組織と一線を画すチームで先進行に伍する体制に:ITpro

注目のビットコイン、2016年はどうなる?「coincheck」大塚雄介氏がその可能性を語る [THE BRIDGE Fes] - THE BRIDGE(ザ・ブリッジ)

コイニーの月間決済額は24カ月で33倍に急伸、スマホ決済成長の鍵は? - THE BRIDGE(ザ・ブリッジ)

プライベートブロックチェーン技術mijinの正体が(少しだけ)明らかに、インフォテリアとテックビューロが説明会 | TechCrunch Japan

インドのBitcoinモバイルウォレットアプリ「Zebpay」が、シリーズAラウンドで100万米ドルを調達 - THE BRIDGE(ザ・ブリッジ)

セキュリティ

【セキュリティ ニュース】「Cyber3 Conference 2015」の報告書が公開(1ページ目 / 全1ページ):Security NEXT

【セキュリティ ニュース】「FFR yarai」に教育機関向けライセンス - セキュリティ研究室用ライセンスも(1ページ目 / 全1ページ):Security NEXT

General Motors Launches Bug Bounty Program - Infosecurity Magazine

Rovnix Zeroes in on Japanese Banks with Minimal Detection Rate - Infosecurity Magazine

Rovnix Zeroes in on Japanese Banks with Minimal Detection Rate - Infosecurity Magazine

'OAuth please do grow up' say IETF boffins • The Register

DDoS攻撃の対処法 : FastMailがDDoS攻撃にとった対策と事後分析 | インフラ・ミドルウェア | POSTD

セキュリティ、いまさら聞いてもいいですか?(4):なぜ、「フィッシング詐欺」に気付けないの? (1/4) - @IT

アークンへの不正アクセスと恐喝未遂についてまとめてみた - piyolog

NRIセキュアがクレジットカード情報漏えい事故に関する専門調査機関として認定される〜日本企業で唯一、PCI DSSの4つの認定を取得〜|ニュースリリース |情報セキュリティのNRIセキュア

Distinguishing Threat Intelligence From Threat Data | SecurityWeek.Com

2016年はAPTが減り、ファイルレスの見つけづらい攻撃へ - カスペルスキー | 企業IT | マイナビニュース

Fortinet SSH Backdoor Found In Firewalls - Darknet - The Darkside

Israeli security firms Check Point, CyberArk in talks – report • The Register

【セキュリティ ニュース】「Redis」狙う不正アクセスが年末年始に急増(1ページ目 / 全1ページ):Security NEXT

HackerOne 2015 Bounty Program Review and New $10K Minimum Bounty - HackerOne

Average Cost of a Spear Phishing Incident: $1.6Mn - Infosecurity Magazine * $1.6million/標的型のコスト * 被害を受けた時の対応なのか?

Shape Security Raises $25 Million to Expand "Botwall" Technology | SecurityWeek.Com

CSIRTだけでは不十分--セキュリティ人材育成の課題明らかに - ZDNet Japan

マカフィーが最新脅威レポートを公開:マクロマルウェアが再び増加傾向に - @IT * Android/OpFake」や「Android/Marry」と呼ばれる2種類のトロイの木馬を発見している。これらは東ヨーロッパで数千のモバイルバンキング用アカウントを狙った攻撃に使用されたもの。アプリのデータをバックエンドで管理しているサービスプロバイダーにネットワーク接続することを目的に、モバイルアプリ内に実装された脆弱なコードを悪用

アカマイがWeb脅威に関する報告書を公開:Web担当者必見。知らぬうちにSEO攻撃に組み込まれる可能性 - @IT 【セキュリティ ニュース】SEO目的の改ざん攻撃 - SQLiで被リンク増やす(1ページ目 / 全1ページ):Security NEXT * SEO攻撃。SQL攻撃を通じて、HTMLリンクを配信し、検索エンジンボットを混乱させてページのランキングに誤った影響を与える * 使うのライバル会社くらいじゃないか

Building Security In versus Building Security On | SecurityWeek.Com * よい記事

ニュース - [データは語る]2015年4Qのインシデントは前年同期比45%減―JPCERT/CC:ITpro 【セキュリティ ニュース】2015年4Qはサイト改ざんが4割増 - CMSの脆弱性が標的に(1ページ目 / 全2ページ):Security NEXT * 報告件数はへった * スキャンに分類されるシステムの弱点を探索するインシデントの報告が最も多い(ポート80, 25, 22) * Webサイト改ざん

【セキュリティ ニュース】「Emdivi」拡散に「Angler EK」を使用か - 「ZeusVM」にも(1ページ目 / 全1ページ):Security NEXT

【セキュリティ ニュース】SCSK、標的型攻撃の監視防御サービス(1ページ目 / 全1ページ):Security NEXT * scskの標的型攻撃の監視防御サービス

auユーザーのメール不正転送(盗み見)事案についてまとめてみた - piyolog

データサイエンス

ビッグデータに潜むバイアス、米規制当局が警告 - WSJ

Detecting and avoiding bucket imbalance in A/B tests | Twitter Blogs

データサイエンティストの卵、学生には無料配布:マイクロソフトが「Microsoft R Server」を公開 - @IT

Shape Security Raises $25 Million to Expand "Botwall" Technology | SecurityWeek.Com

機械学習

Apple、感情認識のAI(人工知能)企業Emotientを買収──Wall Street Journal報道 - ITmedia ニュース

TensorFlowによるディープラーニングで、アイドルの顔を識別する - すぎゃーんメモ

Distinguishing Threat Intelligence From Threat Data | SecurityWeek.Com

ニュース - ディープラーニングの画像認識モデルをマウス操作で作成できるWebサービス:ITpro

ニュース - Google自動運転車、14カ月間の公道テスト走行で272回の技術的不具合:ITpro

Alpacaが画像深層学習の「Labellio」をKCCSに譲渡、トレーディング基盤「Catapilico」を軸にフィンテック特化へ - THE BRIDGE(ザ・ブリッジ)

Yahooがこれまでで最大の機械学習用データセットを研究コミュニティーに解放 | TechCrunch Japan * Yahoo各種サービスでのインタラクションデータの公開

エンジニアリング

テスト

5 Reasons Automated Testing Is Worth the Investment | via @codeship

Android

Google Sign-In API のアップデートについて - Google Developers Japan

マカフィーが最新脅威レポートを公開:マクロマルウェアが再び増加傾向に - @IT * Android/OpFake」や「Android/Marry」と呼ばれる2種類のトロイの木馬を発見している。これらは東ヨーロッパで数千のモバイルバンキング用アカウントを狙った攻撃に使用されたもの。アプリのデータをバックエンドで管理しているサービスプロバイダーにネットワーク接続することを目的に、モバイルアプリ内に実装された脆弱なコードを悪用

10 awesome examples of material design (updated) - Android Authority

採用

Go AbekawaのGo Global!〜Brent Reichow編:情熱もチームワーク力も必要ない――米国人起業家が「一緒に働きたいエンジニア」とは (1/3) - @IT * Linuxが分かる * ハードウェア * Python * バーチャルマシンやコンテナ化といった新しいテクノロジーや業界に精通 *

ビジネス

トラベル情報のSkyscanner、Yahoo Japan他からの1.92億ドルでアジア進出を加速 | TechCrunch Japan

初めての資金調達の際に、ファウンダーが知っておくべきこと - THE BRIDGE(ザ・ブリッジ)

ユーザ企業の顧客の質問にオンラインで自動的に答えるMindTouchが$12Mを調達 | TechCrunch Japan

結果がすべてを癒やす——イグジットした起業家がエンジェル投資をする意義とは | TechCrunch Japan

日本の自動運転社会がスタート──Tesla、国内向けに初のソフト提供開始 - ITmedia ニュース

その他

純度100%スズ製“ガンダムぐいのみ”現る 大河原邦男さん監修、高岡鋳物の職人手作り - ITmedia ニュース

NRI楠真 強いITはココが違う - 「東洋一のデータセンター」が時代遅れになった理由:ITpro

ベテラン投資家、フレッド・ウィルソン氏が振り返る「2015年に起こらなかった」こと - THE BRIDGE(ザ・ブリッジ)

DDoS攻撃の対処法 : FastMailがDDoS攻撃にとった対策と事後分析 | インフラ・ミドルウェア | POSTD

メモしておこう―今年のGoogle I/Oは5/18-5/20(日本時間5/19-5/21)開催と発表 | TechCrunch Japan

Tech Basics/Keyword:REST - @IT

漢(オトコ)のコンピュータ道: 残業は悪か?あるいは日本人の生産性が低い最大の理由

ニュース - 2015年の世界パソコン出荷台数は過去最大の落ち込み、前年比10.4%減:ITpro

【2016年1月18日〜24日】忙しい人のためのweeklyニュース

FinTech

セキュリティ

データサイエンス

機械学習

Android

その他テクノロジー

採用

ビジネス

その他