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 までに公表された情報を追加
イントロ
タイムライン*1*2
- ここではすべて2016年内での出来事とします
日時 | 出来事 | 備考 |
---|---|---|
3/15 | i.JTBの従業員がメール上の添付ファイルを開いたことでパソコンが感染 | 取引先を装ったメール。この時点で感染は認知されず。最終的にサーバー |
3/19 | JTB情報システム(JSS)が |
当該サーバは本来個人情報を含まない。システム監視会社によって検知。継続的な不信通信をブラックリストに登録する作業をおこなっていた。遮断に関する報告はi.JTBからJTBにはなかった*5*63連休 |
3/20 | Webサーバーを社内ネットワークから物理的に切り離し。不審通信は別経路で継続 | 「当該日に不審通信を全遮断することは業務的にも技術的にも可能だった」*7 3連休 |
3/21 | 不正侵入者はデータベースにアクセスしCSVファイルを生成。制御サーバにCSVファイル設置し、その日の内に削除.*8 | | データファイルが作成された制御サーバと不審通信を発したサーバは別*9。3連休 |
3/24 | 内部サーバから外部への不審通信を最後に確認 | |
3/25 | 遮断作業を終了。JSSがJTB IT企画部門に報告 | *10 |
3/XX~3/YY | ネットワーク内の全サーバとパソコンを調査 | 3/19 ~ 3/30? |
4/1 | 不正侵入者が作成・削除したデータファイルの存在を確認。CSIRT立ち上げ。 | |
X/XX~5/13 | 外部セキュリティ専門会社と共同で、ウイルスを駆除・データファイルの復元と不正アクセスの調査・分析・対応を実施 | 調査開始のタイミングの記述はない。復元対象のデータファイルは不正侵入者が作成・削除したデータファイルかと思われる |
5/13 | 復元したデータファイルに個人情報が含まれることを確認。i.JTBよりJTBにエスカレーション*11 。個人情報流出の可能性を認定。事故対策本部を設置。 | |
5/13~X/XX | 直ちにデータを正規化し、 |
*12 |
5/17 | JTB 高橋社長が情報を認知 | |
5/30 | 警察に相談 | |
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 |
攻撃の概要
当時のJTBの体制
発覚以前
- セキュリティを横断的に見る部門は存在せず *23
5.対策: (中略)ジェイティービー(グループ本社)内にITセキュリティ専任統括部門を設置いたします
- CSIRTも存在せず *24
サイバー攻撃の緊急対応チームも当時は存在しなかった
- 一部ログを取得していなかった*25
- すぐ情報を公開しなかったのは「不安と混乱を招くと考え、特定できた段階で公表する方針を取った」*26
- 対象データを暗号化していなかった。*27
- 実績データベースへアクセス可能な社員は1人だが、そのPCは乗っ取られていない*28
- 実績データベースのデータを使うBI(ビジネスインテリジェンス)ツールは25人の社員がアカウントを持っていたが、今事案との関連性は薄いと見られる*29
発覚後
- 問い合わせ窓口を設置
- スタッフ300名規模*30
- 6/14時点で数千件の問い合わせ
- 警察への相談済み(調査中)
- 7/1までにITセキュリティ専任統括部門を設置
「外部流出について可能性があるという表現にとどめたという。JTBは通信ログの一部を取っていなかった。」とあるので事実がないのではなく事実を確認する術がないというのが正しいかもしれませんね。 https://t.co/fkvewFVs7P
— nobuhiro tsuji (@ntsuji) 2016年6月14日
送信された標的型メール*31*32*33*34*35
- 件名: 航空券控え添付のご連絡
- メアド: ごくごく普通のありがちな日本人の苗字@全日本空輸のドメイン*36
- 署名: 取引先の署名
- 添付ファイル名:
- 添付ファイル種別: PDF。
- 実態はELIRKS(の亜種?)とPluX(の亜種?)に当該PCを感染させる新種マルウェア
- オペレータから返信。エラーメールがかえってくる
- 開封すると航空券のeチケットが表示される
- メールヘッダー: 海外のレンタルサーバー(香港を経由)*39
- 本文内容
- 添付ファイル開封者: オペレータ
- 標的型メールの訓練済み
- JTB全体では定期的に訓練していたようだが、当該オペレータが複数回の訓練を受けていたかは不明
- 標的型メールの訓練済み
被害範囲
- 個人情報悪用の報告もない
流出は確定されていない- 流出に関するログが確認できないため、わからない*42
- 尚、一部ログを取得していなかったとのこと
- 可能性は否定されていない*43
- 知らない宛先から不審なメールマガジンが届いた」といった指摘がおよそ100件よせられた
- 詳細調査中*44
個人情報の項目
以下の一部か全て
- 氏名(漢字、カタカナ、ローマ字)
- 性別
- 生年月日
- メアド
- 住所
- 郵便番号
- 電話番号
- パスポート番号
- パスポート取得日
- 現在で有効なものは
約4300件4359件*45
- 現在で有効なものは
訪日外国人の情報も含む*46
- 以下の情報は含まれない*47
- 予約した旅行の内容
- クレカ情報
対象となるユーザー
JTB関連のサービス
- 以下のサービスでオンライン予約したユーザー679万人
- "ネットで予約後、店舗でご清算のお客様の情報は対象となります。" <- ??
- 予約 && オンライン清算が対象??
期間についての記述はない- 2007/9/28 ~ 2016/3/21*48
別会社
NTTドコモのdトラベルユーザー*49*50
- 対象ユーザー: 2014/2/27~2016/3/21に予約したユーザー
- 対象範囲: 33万人
- 窓口設置済み
- ドコモの吉澤和弘新社長が謝罪と対策の強化を表明
auトラベル by DeNAトラベルを*51
対策
不正アクセス対策
- 特定された外部への不審な通信の遮断
- 感染範囲の特定とウイルスの駆除
- 個人情報へのアクセス制御の強化
グループ全体の対策
被害額試算
不明な点
ウイルス感染からの流れ
- 最初に不審通信を確認してから何をしたのか*52
- 感染したパソコンがどの様な用途で使われたか。
- 踏み台もしくは直接操作されたのか
- 内部パスワードを取得されたのか
- 取得したパスワードで社内ツールを使ったのか
- 取得したパスワードでサーバにログインしたのか
- サーバ上でどうファイル作成・削除の操作する権限を得たか。
サーバ上に普段はないデータをどの様に取得したか。
不審通信はどの様な内容なのか => 不審なパケットデータだったか*57
- 宛先・通信種別は一定なのか
- ファイルを送信するような通信なのか
- 単純にいままでに観測されていない通信だったのか
普段の通信量とどれぐらい違うか(ちがわなそう)
- 何をもってして流出の可能性があると判断したか
- 不正アクセス者が作成・削除したファイルの存在で判断したか
- ファイルを外部に送信するような不審通信があったのか
- ウイルスの解析結果をもって判断したのか
業務推進がミッションの実務担当者に、標的型攻撃につながるメールを開いてしまったことに責任など負わせられない。「そこは訓練していたんです」なんてことは、記者会見で言い訳として言及することですらない。むしろ、その後の攻撃の連鎖への対応に何が欠けていたのかが、スタディには必要。
— riotaro okada (@okdt) 2016年6月14日
インパクト
事後対応
- なぜ情報公開が認知後すぐでなかったか
- 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はやっぱり凄い
*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、情報流出で再発防止策を報告 外部調査委を設置 :日本経済新聞
*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/
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賞: 国際電子ビジネス専門学校の紹介パンフ・入学願書・割引券のセットと激励の言葉
その他
おまけ
- 沖縄の海は最高だった。入れてないけど。
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出してました。
結果
After-partyでは参加者がワイワイ楽しそうにやってたので、本当にやって良かったです。Androidコミュニティの人っていい意味で大人ですね。器が広い。感謝しかない。反省点としては、いまだにハンドルネームと顔がまっちしないこと....後、次回はもっとコミットしたいです。
登壇編
何故CFPに応募したのか
2つの思いから応募しました。主目的は自分の経験・知識を提供し、良いAndroidアプリ(ひいてはサービス)を世の中に拡大したかったからです。一部でもそれが響いてアプリに活用されてくれれば、そんなに素敵なことはありません。 もう一つの目的は自分を追い込むためです。感覚レベルから検証を経て論理的な考えに昇華し、それを噛み砕いて発表する...というのは中々骨が折れますが、それが出来た時の経験値は、通常業務で得られるそれとは比較になりません。
何を応募したか
- 明日、敗訴しないためのセキュアコーディング
- Android Clean Architecture for Dummies In Detail
締め切り1周間前あたりから、自分の強み・Android界隈の話題・潜在的にニーズがありそうな話題・応募状況を考え始め、ちょいちょい文字に起こしながら推敲を重ね、24h前にCFPに提出しました。最初に提出してちょいちょい肉を足していく手法でもよかったかも...出来るかわからないですが。
2つ出したのは、絶対何か話したかったからです。当る確立を高めたかったから。
結果
2つとも採択されました。予定外でした。その後、時間的余裕と自分の強みから前者である「明日、敗訴しないためのセキュアコーディング」を選択しました。後者は自分もまだ手探りだからなぁ〜
準備
セキュアコーディングについて調査しまくりました。最近のインシデントや何が原因でそれが発生するのかを主に調査しました(1月中旬)
わかった事は、セキュアコーディングのガイドライン自体は昔から存在していて、最近のインシデントに起因する脆弱性対策も記載されてるんですよね。そこに課題が見えました。セキュアコーディングあるのに使われてないじゃん、もったいね〜、と。じゃあ、何で読まれないかを開発者の視点でガイドラインを再読しながら考えて気づいたのは、ガイドラインは広範囲すぎてインデックスとして使わなければあかん、しかし開発中にそんなインデックスをいちいち引いてらんない、ということでした(1月下旬)
そう分かったので、セキュアコーディングそのものではなく、各々の開発段階におけるセキュアコーディングと言う形でプロットを作りました。資料自体は結構余裕を持って3日前には作り終わってましたね(2月中旬)
気持ちの問題でいうと、割りと気合をいれて入念に作っていたつもりです。何故ならお金を取るカンファレンスでしゃべるものですから。後、偉大な先輩諸兄が登壇・運営する場なので、中途半端なものは出したくなかったのです。
発表そのもの
発表前は腹式呼吸など瞑想のテクニックで、割りと落ち着いてたと思います。しかし、資料中盤くらいで何故かテンパってしまいました。言いたい所(設計ちゃんとしろ!とかCI環境ちゃんとしよう!とか)を強調せずに、言わなくていいところ(セキュアコーディングそのもの)について話てしまったりなど、練習どおり行かなかったですね。区切りを一個おいて、そこで落ち着けば良かったなあ、と思ってます。又、質疑応答時も??なことを言ってた気がします。
- 質疑応答に対するフォローアップは下記になります。
結果 & 反省点
全体的には良かったと思います。でも一番重要なポイントのストレスが弱かったから60点です。Cです。アフターパーティで結構それをネタにお話出来て、且つよさ気なフィードバック頂けました。反省点は下記にまとめましたので、質問等あればバシバシください(OperandOSさんを真似して)。
後、登壇する事は冗談抜きでいいことしかないです。細かい勉強会や業務で腕を磨きつつ、来年も応募して登壇できるようにしたいです。
今後
セキュリティ関係のライブラリやプラグインを作りたいな、と思っています。でも、まずは他の発表資料をキャッチアップしないと!
【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
データサイエンス
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
【2016年1月18日〜24日】忙しい人のためのweeklyニュース
FinTech
- 特集:FinTech入門(3):ブロックチェーンは「取引コストゼロ」の世界を実現しようとしている (1/3) - @IT
- ブロックチェーンをFinTechカテゴリに入れるのはちょっと違うかも
セキュリティ
- http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-the-japanese-underground.pdf
- 国内初の“POSマルウェア”被害確認か、ホテルチェーンのハイアット、東京・箱根など国内4ホテルで感染の疑い、クレジットカード情報が漏えい -INTERNET Watch
- POSに対するマルウェア侵入検知数が8->46件に増大
- メルカリ、出品者/購入者ともに匿名で配送できるサービス -INTERNET Watch
- 良い取り組み。
- 人材獲得に力をいれはじめたSlack、データ解析のPalantirや元Facebookメンバーをエグゼクティブクラスに登用 - THE BRIDGE(ザ・ブリッジ)
- CSOが登用される
- 【セキュリティ ニュース】CSIRTだけでは不十分、求められるセキュリティの「橋渡し」人材(1ページ目 / 全1ページ):Security NEXT
- ベンチャーも混ぜてほしいお
- 記者の眼 - 政府予算はサイバーセキュリティ分野が急伸:ITpro
- 「国・自治体・独立行政法人等のサイバーセキュリティ強化」の経費として計上された合計額は520億円。2015年度当初予算に計上された326億円の1.6倍にも上る
- 次世代ファイアウォールに「設計上の脆弱性」?--セキュリティ専門家の間で議論に - (page 2) - ZDNet Japan
- ハイアット、カード情報流出か--250施設でマルウェア感染 - ZDNet Japan
- サイオス、機械学習IT運用分析ソフトの新バージョンをリリース - ZDNet Japan
- サイバー攻撃の被害を最小化する考え方と方策--2016年も情報漏えいは続く - (page 4) - ZDNet Japan
- 中小企業のガバナンス
- ランサムウェアが流行る予想
- 端末のバックアップだけじゃなく、ログのジャーナルもしましょう
- Security as a Service
- ニュース - 金融庁のWebサイトにDDoS攻撃、「アノニマス」の犯行声明も:ITpro
- FDA Issues Guidelines on Medical Device Cybersecurity | Threatpost | The first stop for security news
- Firm Sues Cyber Insurer Over $480K Loss — Krebs on Security
- サイバー保険が適用されなかった例
- 標的型メール文面が保険適用外だったという話
- セキュリティ教育現場便り(1):「セキュリティ人材」って、何ですか?――本当に必要なセキュリティ教育を考える (2/2) - @IT
- 【セキュリティ ニュース】NICT、暗号化したままビッグデータを解析する新技術(1ページ目 / 全1ページ):Security NEXT
- 金融庁のWebサイト閲覧障害についてまとめてみた - piyolog
- 狙われるネットワークインフラ - [第2回]サーバー:インターネットのエッジサーバーが盾、WebサイトをDDoS攻撃から守る:ITpro
- CDNにWAK(KONA)がくっつく形態はAkamaiにしかないんだよなあ
- LastPassでさえも盗まれうる – LastPassのセキュリティを探る | コンピュータサイエンス | POSTD
- 情報セキュリティ市場は堅調、マイナンバーなど法制度が後押し--IDC調査 - ZDNet Japan
- 【セキュリティ ニュース】PwC、模擬標的型攻撃による演習サービスをリリース(1ページ目 / 全1ページ):Security NEXT
- ダメなパスワード、2015年版ランキングが公開--スターウォーズ用語も - ZDNet Japan
- 【セキュリティ ニュース】アークンへの不正アクセス - 管理者アカウントでログインか(1ページ目 / 全1ページ):Security NEXT
- 外部バックアップサーバが管理者アカウントで不正アクセス
- “組織犯罪”サイバー攻撃に立ち向かう術--NTTコミュニケーションズの専門家に聞く - ZDNet Japan
- 【やじうまWatch】安倍内閣、サイバーセキュリティ対策で草薙素子氏を起用 -INTERNET Watch
データサイエンス
機械学習
- ニュース - サイオステクノロジー、機械学習機能を搭載したIT運用分析ソフト最新版:ITpro
- 『DARK SOULS』のデータ解析から生まれた対人戦AI「Project King」、10か月の開発を経て不死の世界に降臨 | AUTOMATON
- 人工知能 (AI)や機械に絶対奪われない3つのスキル | freshtrax | btrax スタッフブログ
- 【セキュリティ ニュース】NICT、暗号化したままビッグデータを解析する新技術(1ページ目 / 全1ページ):Security NEXT
- 具体的にはロジスティック回帰分析で用いられる複雑な関数を、近似した2次関数で置き換え、データの加工をあらかじめデータ提供者側で実施
Spark SQLとHive、Hadoop上でのクエリ処理性能を比較してみた - ZDNet Japan
- Spark処理性能
平均8回を要すると言われるミーティングの設定を任せられる「X.ai」の人工知能アシスタント - THE BRIDGE(ザ・ブリッジ)
- 人工知能で不良債権の発生を通知、「freee」の会計データと連携する経営分析ツール提供 -INTERNET Watch
- 総務省統計局、社会人向けにデータサイエンスのオンライン講座、「gacco」で開講、誰でも受講可能 -INTERNET Watch
- ニュース - 総務省統計局が「データサイエンス演習」、入門に続く実践編、JALなどから講師:ITpro
- スカスカのデータから知見を見出す救世主?--「スパースモデリング」とは何か - ZDNet Japan
- スパース性について
- 通行人はポスター見た? 注目度を映像で解析、フューチャースタンダードが1.3億円調達 | TechCrunch Japan
- 記者の眼 - 人工知能に仕事を奪われてもいいじゃないか:ITpro
- 記者の眼 - 人工知能に仕事を奪われてもいいじゃないか:ITpro
Android
- Create promo codes for your apps and in-app products in the Google Play Developer Console | Android Developers Blog
- プロモーションコード
- Facebook Messenger may soon get a big taste of Material Design on Android
- Facebook Messengerマテリアルデザインへの取り組み開始(
その他テクノロジー
- セキュアで効率の良い管理に向けた変更:イメージ格納方法が変更になるDocker v1.10、RC版と移行支援ツールを公開 - @IT
- 分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | コンピュータサイエンス | POSTD
採用
ビジネス
- とある投資家が語る「こんな場合には投資しちゃダメ」という4つのケース - THE BRIDGE(ザ・ブリッジ)
- テクニカル指標ではかる株価反発の時機--投資参考銘柄の紹介 - (page 2) - ZDNet Japan
- 君の「10億ドルを生むアイディア」には1円の価値もない【寄稿】 - THE BRIDGE(ザ・ブリッジ)
その他
- How To Become A Hacker
- VPNアクセスを許容していたNetflixがグローバル展開とともに厳しい取締りに転ず | TechCrunch Japan
“地球最強”クマムシ、30年の冷凍からよみがえる その後繁殖も - ITmedia ニュース
- クマムシさんパネッす
- Boston Dynamicsの人型AIロボットAtlasが家を片付ける様子をご覧あれ | TechCrunch Japan
- Scott Kelly on Twitter: "#SpaceFlower out in the sun for the first time! #YearInSpace https://t.co/Cghu9XGv1J"
- 微笑重力環境で初めて開花した
- 百日草
- コーディングを学ぶこと、それはあなたが考えるよりも大変です | キャリア・働き方 | POSTD
- 人は「好き」を仕事にするべきか? - THE BRIDGE(ザ・ブリッジ)
- Amazon、プライム会員向け「プライム・フォト」 写真専用の容量無制限ストレージ - ITmedia ニュース
- Amazonは神