2019/12月下旬に、NTTグループ全体でNTT Coding Challenge 2019(競技プログラミング大会)を、 日本電信電話株式会社 と、NTTコミュニケーションズと共同で開催いたしました。 本記事では、競技プログラミングについて、イベントの簡単な紹介、また当日の様子について紹介いたします。 競技プログラミングおよびNTT Coding Challenge2019とは 競技プログラミングとは、広義でいえばセキュリティ関連で行われるCTF(Capture The Flag)や、パフォーマンスチューニング向けのISUCON(Iikanji Speed Up CONtest)など、 プログラミング能力（を含む幅広い能力）を競い合う競技の一種です。狭義でいえば、特にアルゴリズムなどのプログラミング能力を競い合う競技の一種であり、今回実施したNTT Coding Challenge 2019はこちらを対象とした競技大会です。 NTT Coding Challenge 2019の開催目的は次の3つです。 Fun to Work(楽しみながら仕事する) エンジニアのスキルアップ＆学びの動機付け エンジニアのコミュニティ形成 当日の様子 競技当日は、NTTグループ各社から130名を超える参加者が集まり、大変活気あるイベントとなりました。 出題された問題は、簡単な図形の知識および標準入出力さえ理解していれば、解けるような平易な問題から、難易度の高い問題まで、いくつかのバリエーションを用意して提供されました。 参加者の声 イベント終了後に参加者からいただいた生の声をいくつか紹介いたします。　 これがきっかけでプログラミング学び始めました！ コンテストが終わったあと参加者間で情報共有しているところを多く見かけられて、多数の会社の人でこうした交流があるのはいいと思った。初めての人向けにチュートリアルがあったのもよかった NTTグループ全体で開催できてとてもよかったと思います。とても楽しかったので是非来年も実施していただきたいです 競技プログラミングへのモチベーションが高まって、スキルアップに活かせた。グループ横断でエンジニアと交流関係を構築できた 初心者歓迎、を銘打って競技プログラミングの裾野を広げる取り組みをしてくれた点。またオンライン開催でなく懇親会など含めたリアル会を、労力をかけて開催していただいたので、この機会に話をするみたいなことも出来た 当初に掲げた目的（Fun To Work、スキルアップ、コミュニティ形成）に沿った感想をいただけており、一定の成果をあげられたと考えております。 まとめ 本記事では、NTTグループの競技プログラミングコンテストであるNTT Coding Challenge 2019について紹介いたしました。今後も、NTTコミュニケーションズでは、自社およびNTTグループ全体の技術力を高める機会を積極的に作っていきます。

12月上旬にロンドンで開催されたBlack Hat Europe 2019に技術開発部セキュリティユニットの伊藤・山本が参加してきましたので報告します。 尚、Black Hatについては以前の記事、「 Black Hat USA 2019 / DEF CON 27に参加してきました 」にも詳細を掲載しておりますので併せてご覧ください。 Black Hat Europe とは Black Hatは世界最大級の商業系セキュリティカンファレンスで、毎年USA、Europe、Asiaの三地域で開催されます。Black Hat Europeの今年の会場は、Excel Londonという幕張メッセのような大規模展示場でした。規模はBlack Hat USAよりも劣るものの依然として強い集客力があり、今年は100ヵ国以上の国からの参加がありました。 カンファレンスの構成もUSAとおおよそ同じでトレーニング（講義）、ブリーフィング（講演）、アーセナル（開発ツールの実演）、ビジネスホール（企業による見本市）で構成されます。2日から4日間のトレーニングがまず最初に行われ、その後の2日間でブリーフィング、アーセナル、ビジネスホールが並行して行われます。今回私達はトレーニングには参加せず、後半のブリーフィング、ビジネスホール、アーセナルから参加しました。 Black Hat Europe 2019でみたセキュリティ動向 Black Hatでは、Web、暗号、IoT、マルウェア、ネットワークなど満遍なく様々なテーマの発表があります。去年少なかったExploitやReverse Engineering、Web App Secなどのテーマは今年は例年と同じ5件程度の講演数があり、やはり根強く関心のあるテーマであることが伺えます。コミュニティ活動の発表も昨年から1つのジャンルとして確立されたようです。また日本人の発表もブリーフィングで2件、アーセナルで1件ありました。 講演のジャンルだけでは今年の傾向がはっきりしませんが、ここ数年でよく耳にするようになったRed TeamやIoTなどは講演を聞いていてもホットワードな印象を受けました。またFunction as a service、Slackなどを開発に取り入れた場合のセキュリティをテーマにした、目新しい講演もありました。一方でMachine Learning関連の講演はほとんどなかったことも個人的には印象に残りました。これらについては後半でもう少しお話します。 企業ブースではCrowdStrikeやRecorded Futureなど、全体的にベンチャー色が強い企業が揃っていました。一方で大企業ではFacebookやLenovoが出展していたものの、FireEyeやCiscoといった「老舗」の出展はなく、USAとは異なる印象を受けました。 以下では印象的であったテーマ別にBlack Hat Europe2019を振り返ってみます。 Red Team/Blue Team Black Hat Europe 2019は、基調講演 "Blue to Red: Traversing the Spectrum"（筆者訳：「BlueからRed - スペクトルの横断」）で始まりました。スピーカーのAmanda Rousseauは業界では有名なセキュリティエンジニアで、これまでフォレンジックやマルウェア研究を専門として政府や民間企業で働き（Blue - 防御側）、現在はFacebookのRed Team（攻撃側）で活躍している方です。講演のなかで彼女は、セキュリティ業界で起こっている技術の過度な専門化（overspecialization）をテーマに、BlueからRedへとキャリアを歩んできた彼女なりの教訓や知見を話してくれました。 数年前、セキュリティ業界ではSandboxといった防御側の技術に注目が集まっておりましたが、今は攻撃側であるRed Teamがもてはやされており、セキュリティ技術の移り変わりの速さに驚きます。すると次は何がくるのか気になるところではありますが、彼女はこの過熱する技術動向を憂えて OVER specialization（注：強調は筆者）という表現をしたのではないかと思われます。彼女は講演中、繰り返し「ツールを信じるな（信じすぎるな）」「基礎を大切に」と話していました。こうした教訓は彼女の講演に限らずよく言われていることかもしれません。ですが、業界の最先端にいるエンジニアの言葉として捉えると、深みは増すように思います。基調講演の動画は こちら でご覧になれます。 AI/ML（Machine Learning） AI/MLは日頃よく耳にすると思われますが、2日間に渡って様々な講演を聞いたなかでは意外なことに殆ど登場しませんでした。見聞きした範囲でAI/MLに関連していたセッションも、IoTデバイスの脆弱性を見つける手法として暗に用いられていたものくらいです。全てのセッションのタイトルを確認しても、AI/MLをキーワードとしているものはなく、ブリーフィングセッション全体であまり取り扱われなかったようです。 しかしながら閉会のパネルディスカッション（Locknote）では、AI/MLの投稿は多数あったと登壇者が話していました。実際、AI/MLのセキュリティ分野への応用はこれまでも多くの研究者やエンジニアが取り組んでおり、例えばマルウェアの分類やログを用いた未知の攻撃の検知（異常検知）といった研究があります。にも関わらず今回のBlack HatでAI/MLに関連するセッションが殆どなかったことから、これらをキーワードとする投稿はあまり採択されなかったようです。採択されなかった理由は特に言及されていませんでしたが、Black Hatは情報セキュリティのカンファレンスであるため、AI/MLをキーワードとする内容はBlack Hatでは適切とはみなされず、採択されにくいのかもしれません。 Endpoint Microsoft Office、Adobe Reader、Google ChromeといったEndpoint（クライアント端末）で利用されるアプリケーションは、非常に幅広いユーザに利用されていることもあり、攻撃者に常に狙われ悪用されてきました。アプリケーション側も対策を施しますが、その対策は根本的ではなく暫定的であることが殆どです。このようなサイバー攻撃とセキュリティ対策の関係は、いたちごっこにしばしば例えられます。 今回セッションを聞いていて感じたことは、先のアプリケーションのセキュリティ対策がより根本的なものへと発展しつつあるということです。いくつかの講演では、いたちごっこのようにも見える攻撃手法の変遷を辿ることで、攻撃手法をいくらか体系化し、それら攻撃手法への対策法を提案または実装していました。Microsoft Officeのマクロを使った攻撃とその防御の発表では、その変遷概要を示した後に（下記スライド参照）、攻撃検知手法を簡潔に定式化し実装していました。（スライドは「 Advanced VBA Macros Attack & Defense 」より引用） IoT/Platform IoTとそのPlatformは、Endpointのセキュリティ対策と比較すると、攻撃側も防御側もまだあまり研究されていないようです。例えばAlexa（Amazonが開発したスマートスピーカー）を利用したPlatformへの攻撃といった、これまであまり事例がなかった新しい攻撃手法を報告するセッションは幾つかありました。他方、家電への脅威を観測および分析するシステムを開発しながらも対策は次のステップであることを講演者は明かしていたり、そのセッションの質疑でコストを気にかける質問があったりと、各社IoTへの対策とコストに課題を抱えている様子が伺えました。 まとめ 今回の記事ではBlack Hat Europeについて紹介しました。さまざまなテーマでの講演があるBlack Hatは自分の専門分野をさらに深掘りするだけでなく、知らないテーマについても知るきっかけになります。Black Hatは年に３回開催されていますので、機会があったらぜひ参加してみてください。

はじめまして、技術開発部セキュリティユニットの志村です。 10月・11月に、NTT Comグループの社員を対象としたCTF形式のセキュリティコンテスト「ComCTF 2019」を開催しました。前年度に引き続き2回目の開催となります。私は運営側としてCTFの作問に携わりました。 今回はその模様をお伝えします。 CTFとは CTFとは “Capture The FLAG” の略であり、セキュリティ分野では、セキュリティなどの技術を競い合う競技のことを指します。国内で開催されるCTFとしては SECCON などが有名です。 CTFの競技形式にはいくつか種類があります。クイズ形式で様々なジャンルの問題を解いていくJeopardy方式、 自チームの脆弱なサーバを守りつつ他チームのサーバに侵入するAttack&Defenseなどの形式が有名です。ComCTFは大人数が参加しやすいJeorpady方式で行われました。 社内CTF 「ComCTF」について ComCTFはNTT Comグループの社員を対象とした、NTT Comグループの有志によって運営や問題の作問が行われるCTFです。 ComCTFの開催の目的には、「参加を通じてセキュリティスキルの向上」「参加者や作問者同士の交流」などが挙げられます。またNTTの持ち株が主催するNTTグループ内のセキュリティコンテストの予選も兼ねており、上位チームはNTTグループ内セキュリティコンテストに参加する予定です。 ComCTFを企画する上では以下のようなことが念頭に置かれました。 1.初学者も参加しやすいCTFであること CTF未経験者も参加しやすくなるように、簡単な問題を用意したり、全問題にヒントを用意しておくことを作問ルールとして定めました。また変わった試みとして 「Deskwork」という初心者が取り組みやすいジャンルを作成しました。(後述) 2.スキルの定着を図ること 参加者がCTFを通じてスキルを定着できるようにすることな取り組みを実施しました。Writeup(想定される問題の解法) を終了後すぐに参加者に配布する、問題環境を参加者に配布するなど、参加者が復習できる環境を用意しました。 大会概要 ComCTF 2019は予選・決勝の2ラウンド制で開催しました。参加者は最大4名のチームを組み予選に参加。上位12チームが決勝に進出し、決勝で最終的な優勝チームを決定しました。 予選・決勝で使う問題はNTT Comグループの有志で内製されました。セキュリティ系の業務に携わっているメンバーだけでなく、Web・ネットワーク・ソフトウェアなど多様なバックグラウンドを持つメンバーによって作問が行われました。 続いて予選・決勝の様子やどのような問題が出題されたかをご紹介します。 予選 予選はWeb上で5日間問題を公開し、参加者は好きなタイミングで問題を解くことができるようにしました。 各問題は以下のようにジャンルごとに分類され、好きな順番で問題を解くことができます。 出題された問題は次の9ジャンルに渡ります。 Web: Webアプリケーションの脆弱性をつく問題 Crypto: 暗号系の問題 Forensics: メモリダンプやディスクダンプなどを解析する問題など Reversing: プログラムの挙動を解析してフラグを取得する問題 Pwn: 実行ファイルの脆弱性をついてFLAGを入手する問題。サーバ上で稼働している実行ファイルの脆弱性をついてFLAGファイルを読み出すなどの問題が多い Coding: プログラムを書いて与えられた問題を解く Network: pcapファイルを解析して隠されたFLAGを見つける、ネットワークに関連する問題 Deskwork : 日常業務に潜むリスクにフォーカスした問題 Misc: その他の問題 ComCTF 2019では独自の「Deskwork」というジャンルを用意しました。このジャンルは日常業務に潜むリスクにフォーカスした問題を出題する、というコンセプトで、普段セキュリティに馴染みのない方やエンジニアでない方も取り掛かりやすいように出題されました。 問題の例としては、「簡単なパスワードで暗号化されたZipファイルを開いて中のFLAGを入手」、「暗号化されたエクセルマクロの中身を見る」など、業務でよく使うツールを取り扱う問題が出題されました。 最終的には全84チーム、241名に参加いただけました。 上位チームの点数の推移は以下通りです。ここには載っていませんが最終日に怒涛の追い上げを見せ上位12チームに滑り込んだチームがあるなど、最後まで白熱した争いが繰り広げられました。 決勝 決勝では、予選を勝ち抜いた上位12チームが一堂に会し、7時間という限られた時間の中で問題に取り組みました。どのチームも真剣に取り組み、運営は問題のトラブルに対応したり、飲み物やお菓子を用意するなど参加者のサポートを行いました。　　 決勝問題は6ジャンル、合計17問の問題で構成されていました。予選と違い1日のみ開催となるため問題数は少なく、ただし難易度は高めにした問題が揃えられました。決勝問題では以下のジャンルの問題が出題されました。 Crypto Pentest Security by Ops Threat hunting Web ここでは予選になかった4つのジャンルについて紹介します。 Pentest Pentestとは、「Penetration test」 の略で、コンピュータやネットワークに実際に侵入を試みることで、システムに脆弱性がないかをテストする手法です。 この問題ではネットワークに侵入し(Intrusion)、システムを発見(Discovery)。その後発見したシステムの脆弱性をついて攻撃(Exploitation)し、攻撃したサーバを足掛かりにし侵入を拡大する(Lateral Movement)という攻撃の一連の流れを体験できる問題になっていました。 各チームにはdockerで作った問題環境が用意され、自チームの環境にVPNアクセスして問題を解く、という形式で行われました。 実際にこの環境がどのように作成されたかについては、 NTTコミュニケーションズ Advent Calendar 2019 の 12/15 の記事 で作問者より公開される予定ですので、詳しくはそちらをご覧ください。 Security by Ops 一般的なCTFには見かけないジャンルの問題になります。セキュリティオペレーションに関する技術を問う問題で、運用や防御側のスキルが問われる問題となっています。 この問題は以下のような構成になっていました。 複数の脆弱性があるサービスが稼働している。 サービスのシステム構成図、アプリケーションログ、pcapが提供される。 ログやpcapから脆弱性を発見する。発見した脆弱性を使えばFLAGが取れる。 エクスプロイトを防ぐようなSnortルール／Yaraシグネチャを作成したら検証システムに提出する。過検知なくエクスプロイトが防げることが検証できたらFLAGを得ることができる Threat Hunting 擬似的なランサムウェアの検体を解析し、暗号ロジックを読み解いて暗号化されたファイルを復元したり、攻撃者が残した情報から擬似攻撃グループの情報をOSINTで追跡する、といった問題でした。　　 懇親会 決勝終了後には懇親会が開催され、参加者と作問者・運営や協力してくださったヒューマンリソース部社員などが交流しました。CTFの問題の話などで大いに盛り上がり、終始楽しい雰囲気に包まれました。　　 また特別ゲストとして株式会社コナミデジタルエンタテインメントの瀬戸康裕様が登壇し、コナミ社内でのCTFの取り組みを紹介してくださりました。その中ではCTFの可視化システムが映像を交えて紹介され、会場が盛り上がりました。 結果発表・問題解説 懇親会中に、決勝の順位発表が行われました。 点数推移は下の通りで、優勝チームは最後の1時間に怒涛のFLAG奪取を行い、突き放しての優勝となりました。 また配布されるWriteupとは別に、Threat hunting作問者から問題の解説が行われました。Threat hunting問題の出題意図や解法などが解説され、参加者は興味深そうに聞いていました。 参加者からの声 参加者からは以下のような意見が聞かれました。 セキュリティの知識向上にとても良い機会だと思います。勉強して来年も参加できればと思います。 解けなかった人ですが、問題解説やお菓子提供やスピーディなwrite-up配布等、運営がとても行き届いていてよかったと思います。皆さまありがとうございました。 一方でジャンルの偏りや、予選と決勝戦の難易度の差などを指摘する声も聞かれたため、今後は頂いたフィードバックをもとに改善していく予定です。 まとめ NTTコミュニケーションズグループで開催されたComCTFについてご紹介しました。この記事で初めてCTFを知ったという方も、 picoctf や ksnctf など常設で公開されているCTFもありますので、興味のある方は挑戦してみてください。

はじめまして! クラウドサービス部の花川です． 9月10日に，社内ISUCONであるN-ISUCONを開催しました．その様子をレポートします． ※ 2020/03/31追記: ソースコードを公開しました! nttcom/n-isucon-2019: Codes used for N-ISUCON 2019 ISUCONとは Iikanjini Speed Up Contest（いい感じにスピードアップコンテスト）の略で，与えられたWebサービスを限界まで高速化していく，チーム対抗のチューニングバトルです． 2011年にライブドア社（現LINE社）が主催となって初めて開催され，その後，年1回開催されているエンジニアには名の知られたイベントです． 今年は第9回として， 09月07日と08日に予選 ， 10月05日に本戦 が開催されています． 社内ISUCON "N-ISUCON" もともと，弊社には DigiCom（デジコン）という社内コンテストが開催されています． DX，イノベーションの新アイデア がテーマであり，どちらかというとハッカソンやアイデアソン的な側面が強いイベントです． そのため，テクノロジーだけではなく，ビジネスやデザインも含めた観点で評価され，順位が決定されます． 一方で， エンジニアが技術で殴り合うようなイベント は社内にはありませんでした． そこで，DigiComと共催という形で，"NTT Communications" の "ISUCON" である N-ISUCONを初開催しました． N-ISUCONの開催目的としては，大きく下の3つです． Fun to Work/楽しんで仕事をする ソフトウェア人材の育成 コミュニケーション活性化（コミュニティの形成） 本家のISUCONと同様にチーム対抗戦となっており，1チーム最大3人で構成としました． また，チームにはComグループのメンバー以外にも，他社の方を含める事も可としました． N-ISUCONのテーマ 今回は初回開催ということで，シンプルなブログシステムをテーマに設定しました． サービス名は Niita で，某プログラマのための技術情報共有サービス風な感じです． 本家とほぼ同様に，下記の機能が実装されています． ユーザ 登録 変更 ログイン/ログアウト アイコン登録 記事 CRUD コメント CRD いいね CR 提供言語とアーキテクチャ Niitaの実装は，バックエンドとフロントエンドに分離されています． フロントエンドは，はVue.jsによるSPA (Single Page Application) で構成されており，バックエンドのAPIサーバは，Python，Ruby，Node.js，Golangで実装し提供しています． 動作環境はGCP（Google Cloud Platform）上のVM（Virtual Machine）に上記の各言語で実装されたアプリケーションと，DBとしてMySQLをインストールしています． 各チームにこのVMを3台割り当て，競技を行いました． ベンチマークは，各チームに指定された1台に対して，HTTPでリクエストを投げる仕様になっています *1 大会中の様子 開始時には，ISUCONなどでよくありがちな小芝居を入れたりしました． 大会中の皆さんは(当たり前ですが)超真剣です． モニタを持ち込んだり，ホワイトボードを持ってきたりとやる気満々． 運営は， CommBASE で椅子を投げあいながらトラブルシューティングをしたり，競技者からの問い合わせに対応していました． こちらも，なかなか白熱した戦いが繰り広げられました． 懇親会 交流 大会後の懇親会では，参加者同士の交流が行われました． N-ISUCONという共通の話題もあり，大いに盛り上がっていました． 順位発表&問題解説 懇親会途中で，順位発表と問題の解説が行われました． 競技開始から終了までの点数推移はこんなかんじでした． 順位発表後には，簡単にパフォーマンスの罠について解説をしました． 大体，解説をしていると，開場からは「やっぱりここか〜」など，悔しい声が聞こえてきたりしました． 参加者からの声 開催後，参加者のみなさんにアンケートを取りました． 問題全体は難しいという意見が多かったですが，「過去の苦労話がそのまま問題に出ていた」や，「問題アプリの構成自体がレガシーではないのが良かった」など，ポジティブな意見も多くいただいきました． また，「今後も参加したい」だったり「学習のモチベーションが上がった」等書かれており，運営としても苦労が報われたなという気持ちになりました． まとめ 今回は，N-ISUCONのイベント開催の報告を行いました． 現在，問題アプリやベンチマーカを公開して，手元で実際に競技を出来るよう調整中です． *1 : この辺は，また別の記事で解説しようと思います.

経営企画部の松木です。ビジネスイノベーション推進室で スポーツ観戦アプリ SpoLive の開発をしています。 先日開催された日本最大のGoのカンファレンスであるGo Conference 2019 Autumn（以降、GoCon）にて発表してきましたので、発表・参加の様子を共有します。 イベントの概要 
GoConは毎年春・秋に開催されている、日本最大級のGoのカンファレンスです。運営（有志）の方々が、海外から著名な方を日本に呼べるようなカンファレンスとなることを目指して開催しており、200人超の来場者・20のセッションからなります。 GoConで発表するためには、Call for Proposals（以降、CfP）へ応募をし、それが採択される必要があります。このような形式は最近のカンファレンスで多いようです。 CfP応募から発表まで 発表申し込み 発表しようとした理由は、SpoLiveチームにおいて技術選定から携わり、システム的な制約も少なく学びが多かっため、どこかで社外に向けてもアウトプットしていきたいと前から思っていたためです。Goは昨年春から学び始め、自分のプロダクトでも積極的に取り入れていた大好きな言語でした。GoConは以前、倍率が高く抽選で外れたために参加できませんでした。次回こそと思っていたところ、発表の締め切りが迫っていたことを知り、倍率関係なしに参加できる発表者として参加するべく、慌てて申し込みました。 この時点では、具体的なネタは用意できていなかったのですが、やるという気概だけは大きかったです。 友人にレビューを取り付け 締め切り駆動で進めるべく、CfPの準備よりも前に、友人にレビューしてもらう約束を取り付けました。CfPを書くこと自体が初めてだったので、最低限フォーマットを埋めて、発表内容を走り書きしたものをみてもらったところ、非常に有意義なレビューをいただきブラッシュアップすることができました。 参加者に対する自分の発表の魅力を意識して、CfPのフォーマットに合わせたものを提出する大切さを学びました。 テーマは２つ応募した CfP応募にあたり注力した点として、テーマを2つ応募したことがあります。これは、自分の学びを最大化するためと、質のために量が必要だと考えたことが理由です。 自分は、経験から話せることは、時間をかけて整理すれば複数挙げられると思っています。大切なことは、普段の業務から良いテーマを設定すること・設定したテーマから今までの知識を整理して肉付けすることだと思っています。肉付けとは、発表のために不足している知識を再学習して補うことです。発表準備を行うことで、この再学習により自分の学びが深まりました。 また、良い発表のためにはテーマ選びが重要ですが、自分が思う一つのテーマよりも、運営の方にも見てもらいその中で良いテーマを選んでもらう方が良いテーマ選びにつながるのでは、と考えました。実際、自分の中で新規性があり現業でも深く触れているテーマが良いと思っていたのですが、結果的にはもう一方のテーマが採択されました。このことから、新規性や専門性を大事にしてしまいがちですが「そもそものカンファレンスの目的（Go言語に関連が深いもの）」「来訪者の関心が大きいもの」といった観点でテーマ検討することの大切さも知りました。 発表当日 100人くらいのホールで、20分の発表をしてきました。内容はこちらの Goにおける API Client 実装パターン です。 API Clientに関して、下記の紹介をしました。より詳細は上記資料を参照ください。 どのようにエラーハンドリングを行うか 通信エラーがあった場合だけではなく、HTTPステータスコードを含めた確認が必要 レスポンスの状態に対して、リトライすべき条件など定義しておくとよい APIリクエストのリトライをする際には、Exponential Backoffの概念が重要 APIサーバー側が捌けるクライアント数を最大化するための概念 GoにおけるExponential Backoffのライブラリの紹介 冪等性を考えた実装が重要 汎用的なAPIClientの実装例 request生成や、headerの共通化の実装例 GoにおけるJSONデコードパターン 特定フィールドの遅延処理を行う方法 Test設計 Clientをmockしてビジネスロジックをtestする方法 E2Eのために、net/http/httptest を利用する方法 発表したことにより、予想以上に得たことが大きかったと振り返ります。今後もいろいろな挑戦をしていきたいと思いました。 やると決めたら、友人が協力してくれた 発表駆動学習ができた 普段の経験について、発表準備の過程で体系的に整理することができ、理解が深まった 参加者の方から、発表に対するフィードバックも得られた 自信につながった 発表申し込み時点では、CfPが採択されること・20分の発表をすることの自信はまったくなかったですが、やり遂げたことで大きな自信につながりました より楽しめた 発表をしたことで参加者の方との会話がしやすくなり、満喫できました 面白かった発表２選 当日発表された資料は、 こちらから 閲覧できるようになっています。特に面白かった発表をご紹介します。 OSS Performance Tuning Tips 資料はこちら OSSに対してパフォーマンス改善のコントリビュートをおこなったorisanoさんの知見が詰まっていた発表でした。 計測のハードルを下げ、問題箇所を特定し、ベンチマークを書いてから改善する といった流れが大切であること、それらの具体的なノウハウを学ぶことができました。 なにより、パフォーマンスチューニングに対する熱意がとても伝わりまってきました。 go gc algorithm 101 資料はこちら GCアルゴリズムが、Goでどのように実装されているかと、その歴史（Goのどのバージョンでどういった改善があったか）について学べました。 GCアルゴリズムの基礎から説明してもらえたのがありがたかったのと、taxioさんは新卒にも関わらず、このレベルの発表をしていることにとても刺激をうけました。 さいごに 私がバックエンドをGoで開発している スポーツ解説アプリ SpoLive では、ラグビーを始めとして、他スポーツもお楽しみいただけるように日々奮闘しております。ぜひダウンロードしてご利用ください。 発表者に配布された、GoのマスコットキャラクターGopherのぬいぐるみ

情報セキュリティ部の久々宮です。 少し前になりますが、2019年6月20日、NTTコムグループ社員を対象にMicro Hardeningを開催しました。 応募者113名とたいへん多く、会場の都合でやむなく85名に絞り、実施しました。その様子をお伝えします。 Hardeningとは Hardeningとは、WASForumが2012年から年2回開催しているセキュリティ技術の向上を目的とする競技会です（くわしくは、 Hardening Project のHPをご覧ください）。WASForumが主催するHardeningは2日間に渡って実施されますが、その他にも1日でよりカジュアルにハードニングを経験できる MINI Hardening Project 、「ゲーム感覚」でサイバー攻撃に対処する能力を磨くMicro Hardening Project( リンク1 、 リンク2 )という、より短い時間で開催できるサブプロジェクトもあります。今回はMicro Hardening形式で開催しました。 この研修では、サイバー攻撃から自分たちのサイトを守りながら、いかにしてビジネスを継続させていくか、という観点での知識・スキルを身に着けていきます。実際のECサイトはインターネット上に公開されているため、日々さまざまなサイバー攻撃にさらされています。攻撃されたからといって、調査や対策の度にサービスを停止させていては、お客さまが買い物をすることができず、ビジネス機会を逸してしまいます。技術とビジネスの2つをバランスさせる感覚を競技を通じて体験し、日頃の業務に活かせる内容になっています。 この他にも年1回社内CTFを開催しています。HardeningとCTFの取り組みを通じて、守りと攻めのセキュリティスキルを備えた人材へ成長してくれることを狙っています。 サイバー攻撃からECサイトを守る演習を4セット実施 講師には、サイバーセキュリティに関する人材育成やSOC支援などに取り組まれている株式会社川口設計の川口洋代表取締役をお招きしました。 研修では3～4人が1チームになり、仮想の脆弱なECサイトの運用者になります。ECサイトにはクローラーが定期的に巡回して買い物をすることで売上が上がり、その売上がスコアになります。ECサイトがサイバー攻撃を受けて本体やデータベースなどの関連サービスがダウンすると、クローラーが買い物をできないため、スコアが伸びません。そこで、研修参加者はECサイトがダウンしないように対策して売上が継続して上がるように努めます。参加者は、45分間、数々のサイバー攻撃からECサイトを守る演習を4セット繰り返します。1つのセットが終了すると、ECサイトがある仮想環境がセット開始前の状態に初期化されます。 【演習の流れ】 1セット目(演習開始→45分経過→演習終了→ECサイトリセット)→2セット目・・・ 攻撃はすべて自動化されており、全チームに対して各セットとも全く同じ攻撃が行われます。参加者は回を重ねるにつれて、徐々に攻撃の内容を把握していきます。攻撃の内容がわかると、それに対する効果的なセキュリティ対策を実施してシステムを堅牢化していきます。攻撃をうまく防ぎ、ECサイトの正常運用をすることで、結果的に売り上げスコアが上がります。 攻撃へのセキュリティ対策として以下のようなことが必要になってきます。 【セキュリティ対策の一例】 ECサイトの運営に不要なサービスやプロセスを停止する 外部NWへ公開していると危険なLISTENポートを塞ぐ ログから攻撃元のIPアドレスを特定し、ファイアウォールでアクセスを制限する 脆弱性のあるプラグインやパッケージをアップデートする 不要なアカウントを停止する、パスワードを強固なものへ変更する 羅列すれば、ごくごく普通の対策なのですが、これらを45分間で効率よく実施するには、チーム内での作業分担や進捗共有、リーダーシップが必要になってきます。チームワークが試されます。演習を繰り返す度にチーム内でのコミュニケーションが活発になる様子が見て取れました。自分達で実施した対策の内容を手順としてまとめたり、スクリプト化することで次のセットですぐに実施できるよう、工夫するチームも現れました。 3セット目が終わった後、講師から一部の攻撃について解説がありました。その内容を受けて、4セット目の直前は、どのチームもメンバー同士で活発に話し合いが行われていました。 競技終了後には参加者同士で振り返りも 4セット目が終わった後に振り返りを実施しました。Hardeningでは振り返りをとても重要なイベントとしています。各チームの代表者から反省点や学んだこと、今後業務で活かせそうな点について発表がありました。その時の皆さんの声を、いくつか紹介します。 ◇会場での参加者の声 実システムを触りながらの研修なので、すごく身になった。今後自己学習を進める上でも極力実機を用いて手を動かしたい。 チームとして誰が何をやっているのかの情報共有の重要性と、チームをコントロールするリーダーの必要性を強く感じた。 最初はシステムの構成を把握するのにも時間がかかった。起動しているサービスの要・不要の判断がつきにくいので、普段業務で触ることがないような部分のシステム・サービスについての知識やスキルもある程度身につける必要性を感じた。 最初は何をされているのか分からなかったが、セットを重ねるごとに攻撃内容の把握や対策を徐々に進めることができ、成長している実感があった。 普段の運用業務においても攻撃や不具合の検知を適切に行うことが必要だと感じた。 普段触るような業務システムはWAFやFirewallで守られているので、今回の研修でシステムに直接攻撃を仕掛けられてサービスが落とされ、それを復旧し対策するような一連のフローが体験できたことは大変貴重で有意義であった。 各チームのスコア発表と講師による攻撃の具体的な解説が行われました。解説では攻撃を受けたシステムの脆弱性についての説明のほか、攻撃はされなかったものの、対応していたらボーナスポイントになった点が紹介されました。 最後に参加者アンケートからいくつかの声を紹介します。 ◇受講者アンケートから 経験豊富で多数の実績がある講師の方だったので、講義内容がとても分かりやすく、今後の業務にも生かせそうと感じた。 講師の方がWebサービスへの攻撃について実例も交えて具体的に説明してくださり、セキュリティの重要性を肌で実感できた。 2セット目までは攻撃の内容がよく分からないまま研修が続き、解説をしてくれないのか……と思ったが、それも含めての研修であり、また事前配布資料をよく読めばヒントも網羅されていて、なるほどと納得できた。 自ら事象を把握し、対策を練っていくということを時間制限がある中でやることが、非常に良かったと思う。ベテランは業務の中で経験することもあると思うが、若手は守られたシステムの中で運用しているので、トラブルに慣れていないこともあり、非常に勉強になると感じた。 飲み物やお菓子の用意がされており良い雰囲気が演出できていた。 Hardeningは頭をフル回転するイベントで、とても疲れます。運営はエナジードリンク、アメやチョコを用意して、参加者への糖分補給をサポートしました。 最後に川口設計様のHPでも、 このイベント が紹介されていますので、ぜひご覧ください。

ServerlessDays Tokyo 2019 参加報告 - コンテスト編 ネットワークサービス部の松田です。 10/21-22 の 2 日間で開催された ServerlessDays Tokyo 2019 の初日に行われたコンテスト形式のワークショップに参加したので、その様子や自身の振り返りをご紹介します。 Workshop Day ワークショップ会場は DMM.com さんの六本木オフィスで、4 つのセッションが用意されていました。一部写真を交えてご紹介します。 AWS公式セッション (AWS Presents, Battle against Massive Load using Your Super Sonic Lambda Function!) -- AWS Lambda を使ったコンテストなのですが、「大量に投入されるイングレスロードを、いかに高速、かつ効率よく捌くかを参加者間で競うコンペティションスタイル」とのことで、なにやらとても AWS の気合を感じます。 Azure公式セッション (Microsoft Serverless App WorkShop) -- Azure の様々なサービスを駆使したアプリケーション開発を体験できるセッション。コンテンツはレベルに応じて用意されていたようです。 コミュニティ主催セッション (S.P.E.C. - Serverless Performance Empowerment Challenge) -- 2 つ目のコンテスト形式セッションですが、こちらはコミュニティが主催します。「Serverless アプリケーションのパフォーマンス向上を競う、何でもありのサーバレスエンジニアを決めるパフォーマンスチューニングバトル・ロワイアル！」とのことで、こちらも盛り上がりを期待させる謳い文句です。 夜間セッション (Knativeで作るDIY FaaS) -- こちらは他の 3 セッションが終わったあとの夜間開催だったため、写真がないのはご容赦ください。 レクチャーを交えながら Knative ベースのプロダクトを DIY するという内容です。最新テクノロジーを学習できる上に、他のセッションと合わせて 2 つ参加できるのは魅力的ですが、その分早くに満員となっていたため受講できませんでした。 これら 4 つの魅力的なセッションの中で私は S.P.E.C. (Serverless Performance Empowerment Contest) に参加しました。 パフォーマンスチューニングと言われると敷居が高そうに思いましたが、 サーバーレスに特化したコンテストは他に聞いたことがない貴重な機会ですし、 Serverless Framework (サーバーレスに特化した、多くのパブリッククラウドに対して Infrastructure as Code を実現する OSS) でのデプロイを必須要件とするあたりが普段使いの自分にとてもマッチしていたので、思い切って参加することにしました。 S.P.E.C. の様子 コンテスト当日、まずはその場で 2-3 人単位のチームが組まれました。 私は単独参加だったので初対面の人と 3 人チームを組みました。 メンバーの 1 人は去年のカンファレンスの登壇者でサーバーレスを実運用している人 (A さん)、 もう 1 人もサーバーインフラやアプリケーションの管理をしている Python 使いの人 (B さん) ということで、とても心強いメンバーでしたし、和やかな雰囲気で安心しました。 また、パフォーマンスチューニングという名前から出場者が集まりにくかったのか、全体のチーム数は 6 チームと比較的こじんまりとした規模でした。 しかし寂しい感じではなく、本当にコミュニティ型のコンテストという感じの、フラットで心理的な距離の近さを醸し出していました。 運営の方も同じスペースに参加者のように座って作業されていましたしね。笑 お題は開始直前に発表されるのですが、ペイメント系サービスを模したサーバーレスのアプリケーションでした。 それを全チームがそれぞれの AWS 環境にデプロイされると、コンテスト開始。 ベンチマーカーが一斉に稼働し始め、スコアが動き始めます。 しかし提供されるアプリケーションには、色々と罠が仕掛けられています。 ロジックの不整合で正常に動かない部分がある パフォーマンスの低下要因が内在している このため、放っておくとどんどん減点されていくのです！　一刻も早く止血してプラスの得点を獲得しないと…。 このようになかなかしびれる状況から約 7 時間のコンテストが始まりました。 （詳細レギュレーションはこちら） コンテスト序盤は私のチームはいまいちうまく連携できず、順位を落とし続けて 5 位に。しかし途中から B さんがどんどんとロジックの不具合を改修していき、一時は 3 位まで上昇。 そこからは 3 人それぞれがパフォーマンス改善を試みて DB の構造改変やロジックのさらなる改善を進めていきます。 私は Lambda 内の API コールが同期的に行われて応答時間を悪化させていた部分に対して、非同期化してパフォーマンス向上するように試みました。 1 度やったことがあるパターンだったのでなんとか形になったのですが、どうも点数が上がらない。それどころか、細かい減点が増え始めている。 よくログをみると、リクエストに対する裏の処理を非同期化したため応答は高速化されたが、裏の処理（コールバックでクライアントに返す部分）でエラーが出ていたようでした。 しかしコンテスト時間内ではうまく改修することができず、おまけにクライマックスに向けてベンチマーカーが多重度を飛躍的に上げていくため、 積み重ねてきたポイントがどんどんと失われていくのをただ眺めることになってしまいました。 「ああ、すまない、これはもう、止められない…」 「いいんだよ、俺たちが果敢にトライした結果じゃないか…」 「Oh... 俺はお前らと一緒のチームになれて幸せだったよ」 そんな謎の一体感に包まれたまま（※若干脚色してます）コンテストは終わりを迎え、結果的に 6 チーム中 5 位でした。 振り返って ここからは、コンテスト参加者としての出来を率直に振り返っていきます。 個人とチーム、2 つの切り口で見ていきます。 個人に関わる敗因と学び 場慣れ: どうも心と頭が浮足立った感じだった。文字通り肩に力が入った状態 (めちゃ凝った) で、本来のパフォーマンスが出なかった。その結果の凡ミスが命取りとなり、終盤の大量出血につながった コーディング力 (read/write とも) の不足: 身にしみるまで書いていない。落ち着いて調べればできるが、時間制限がある中ではいかに体が覚えているかが物を言う こういった点は克服していくと、集中しにくい環境でもパフォーマンスを発揮できるようになり、日頃の仕事にも活きてくるものだと言えそうです。 チームに関わる敗因と学び チームとしての段取り 。これが何よりの敗因で、何よりの学びでした。 起きたこと: お互いの得意不得意が見えない中、伺い合う感じでなかなか真っ直ぐにことが進まなかった 結果的に何よりも大事な動作確認をスクリプト化するのが遅れたことで不具合の炙り出しに時間がかかり得点に影響した（結局 1 位チームも最速で不具合修正をしたことが勝因で、逃げ切りだった模様） 他にも、ファイル分割せず GitHub を介して共同管理していたため、 commit 同士が conflict 、など やればよかった役割分担（例えば、の私案です。この手のコンテスト経験者の経験値をもらうべきだった）: インフラ（AWS 環境整備, モニタリングやロギングの整備など） デプロイとテスト コード読み書き 全体のマネジメント このあたりの主担当を明確にし、ただしお互いにサポートし合うような形が良かったのではないかと思います。 開発スタイルも、コードをみんなバラバラに書くより、モブプロの形で 1 つのコードをみんなで確認しながら書いていけばよかったです。 精度も上がるしファイルの conflict も心配なし。 何よりチームとしてのパフォーマンスは一定化されるし、その間にお互いの能力が測れて、その後の分担がしやすくなるのではないかと思います。 それでも自信になった・良かった点 個人: Serverless Framework でのデプロイや、アカウントやロギング・モニタリング環境の整備はスムーズで貢献できた アーキテクチャの改善については対等以上に議論できた SDK の使い方は多少アドバイスができた チーム: 2 人は AWS 慣れしていてコンポーネントの選択肢を多く持っていた 1 人は純粋にコードの理解・洞察力が強くて、本質的な課題を整理してくれた 3 人ともフラットに話し合えるような人柄で、振り返ってみるととてもバランスの良いメンバーに恵まれた 振り返ると反省点ばかり目立ってしまいますが、自信になった部分も多いです。また、悔しさと引き換えにたくさんの学びがあったので、とてもポジティブな気持ちです。 あとは、何だかんだ言って終始コンテストを楽しめていたことが良かったです。業務では味わえないコンテストのゲーム性や、同じ技術に興味を持った仲間が増えた感覚にとてもワクワクしていました。 おわりに コンテスト形式のイベントへの参加は勇気がいることもあります。しかし「はじめまして」の仲間と短時間でゼロから何かを形にすることで、普段の業務では得られない多くの貴重な経験ができます。 自分がちゃんと通用するところを確認できて自信になったり、強化していくべきポイントが明確になったり。 チームビルディングや、他のエンジニアの発想・習慣、デザインパターンやアプリケーション事例を学ぶこともできます。どう考えても本業にも活きてくるものばかりでした。 また、サーバーレス縛りのコンテストは他に見たことがなく、主催者の方が 「自分が解きたいから、まずは大会を作ることにした」 とおっしゃっていたのが印象深かったです。 とても感謝するのと同時に、自分もコミュニティに貢献していきたいと強く感じました。 ということでサーバーレスに限らずこういったコンテストはまだまだ参加したいですし、サーバーレスに関してはこういったイベントが増えるようにどんどんコミュニティに協力していきたいという熱い気持ちになったのでした。 みなさんもこういったイベントを活用して、ぜひサーバーレスアーキテクチャやそのテクノロジーに触れてみてください！

ネットワークサービス部 伊藤( @yoshiya_ito )です。10/21-22の2日間で開催された ServerlessDays Tokyo 2019 カンファレンスに参加・登壇しましたので、その模様をご紹介します。 ServerlessDaysとは？ ServerlessDaysは、サーバーレスアーキテクチャを用いたシステムの構築・運用における経験の共有を目的とした、コミュニティ主導でベンダーニュートラルな技術カンファレンスです。 https://tokyo.serverlessdays.io/ 日本におけるServerlessの年次カンファレンスは、これまでServerlessconf Tokyoが2016年から開催されていましたが、今年から東京以外の都市での開催の要望から、SeverlessDaysに変更となっております。 もともとServerlessDaysはJeffConfという名で、ヨーロッパ各地で開催されていたカンファレンスでしたが、2018年にServerlessDaysに改名しているので、馴染みのない方も多数いらっしゃるのではないでしょうか？ 経緯はこちら Goodbye JeffConf, hello ServerlessDays!! SeverlessDaysのプログラム選考 ServerlessDaysで登壇するには、 Papercall にてCall for Paper(CfP)に応募する必要があります。ServerlessDaysのプログラム選考では、Papercallの機能により匿名化された状態で選考が行われます。つまり、所属などを一切関係なく、コンテンツ勝負というわけです。 最終締め切りまでにCfPは全部で96件あり、招待講演・スポンサー講演を除いて、全部で13件(LT含む)が選ばれました。 SeverlessDays カンファレンス ServerlessDays カンファレンスでは、サーバレスに関するTipsや事例、メガクラウドベンダーのアップデートなどざまざま発表が行われました。会場は Tabloid で、310名の方々が参加されました。 とてもかっこいい会場。 発表会場もおしゃれ。 自分たちの発表と反応 伊藤( @yoshiya_ito )と松田( @take4mats )で「ISPがサーバレスに手を出した」というお題で発表しました。 発表の様子はこちら↓ 私たちの発表内容の概要は以下の通りです。 NTTコミュニケーションズが提供する OCN v6アルファ では、MAP-E方式を採用したIPv4 over IPv6通信を行っています。 MAP-E方式では、宅内ブロードバンドルータが通信を開始する前にIPv4/IPv6のMAPルールを取得する必要があり、そのルール配信機能をサーバレスで開発したという話です。 IPv6が必須でキャリアグレードの信頼性を担保するために奔走した苦労話や、少人数で継続的な開発をするための工夫についてお話ししました。 発表スライドは下記にあるので、詳細はこちらをご覧ください。 発表中の反応Tweetを一部紹介します。 NTTcomさんの事例、投稿する側がヒヤヒヤするくらいぶっ込んでで面白い。2人ともピンクで良き #slsisp #serverlessdays #serverlesstokyo pic.twitter.com/SluxbyGz6a — Nori Suzuki (@szkn27) October 22, 2019 ISP事業者が、Publicクラウド使って自社のサービスを開発しているのって、知っている人にとってはかなり画期的。 分かりみある。 #serverlessdays #serverlesstokyo — 鈴木 貴典 (@takanorig) October 22, 2019 社内基準と法的な報告義務、IPv6と満たさないといけない制約があるからこそ面白いアーキテクチャになっているよね。 AWSとAzureのマルチクラウド構成とかCDN入れるとことか興味深い #serverlessdays #serverlesstokyo — ぽんず (@ponzmild) October 22, 2019 概ね好感触で、私たちとしては一安心。 その他のセッション どれも素晴らしいトークでしたが、その中でも共有したいものについて触れます。 ゑびや/EBILAB 伊勢神宮にある創業100年以上の飲食店 ゑびや の事例です。ゑびやは2012年以前までほかの老舗飲食店と同様に、そろばんをはじいて、会計処理を行っていました。つまりITにはほど遠い経営をなされていたわけです。 しかし、経営改善を目的として、データを活用した経営を目指すべく、Excelからはじまり、PowerBIや機械学習、そして、サーバレスを駆使する企業となりました。来客情報の可視化、来客・注文予測システムの構築により、フードロス減少・来客満足度向上を実現し、売り上げが2012年に比べ4.8倍となっています。サーバレスはすべてAzureで構築しており、世界のマイクロソフトのパートナーが一堂に会す Microsoft Inspire 2019 においても事例紹介なされています。 老舗飲食店がサーバレスで経営改革できている変遷が非常に面白く、さらにはすべてAzure提供のサービスで実現していたのが興味深かったです。 トヨタ自動車 トヨタ自動車の発表事例では、いまTOYOTAがコネクティッドカーという領域でどのようにサーバレスを活用しているのか紹介がありました。 車がインターネットに接続されるのが当たり前の時代に変わっていく中、TOYOTAは車載デバイスをインターネットを介して接続する必要がありました。そのコネクティッドサービスをサーバレスで開発されたという話です。TOYOTAがサーバレスを選んだ理由は3つあるそうです。 車の利用時間(サーバへのアクセス数) 車の利用時間は波があり、昼は夜間の12倍の利用ともなります。常時稼働させるとアイドルタイムの無駄が大きい。 車のライフサイクル 車のライフサイクルは平均8.5年であり、一度開発したものをアップデートしない=新たな価値を生まないということで、疎結合であるサーバレスであれば継続して開発が可能 より広い地域での提供 国ごとにシェアが異なり、シェアが小さい国では大きくリソースを確保することが困難。 ちいさく始めて必要になったらスケールがしやすい基盤が必要。 現在は数十人規模で開発しているとのことで、国内では最大規模級のサーバレス開発事例です。大規模サーバレス開発における課題と工夫についても紹介がありました。 アプリケーション開発量は少なくなったが、テストがしにくい CI/CDパイプラインで開発環境の整備を行い、単体テストはlocalstackで自動実行、サービス結合テストはkarateを利用されていました。 各機能はシンプルだが、全体が見えにくい ロギング・分散トレーシングが重要で、cloudwatch logsとX-Rayを活用している。 自動スケールは便利だが、制御すべき要素もある 外部サービスの呼び出しで必ず処理が完了するようにした結果、再試行で数千プロセスが同時動作となってしまった。 サーバレスにより価値のない無駄を削除することができたとして、運用コスト50%減により、運用専門部隊を新機能追加等に回すことができたとのこと。 私たちが少人数で開発していることもあり、大規模サーバレス開発を少し垣間見ることができたことはとても新鮮でした。 ダイキン工業 ダイキン工業では、サーバレスを活用して空調設備をIoTでつなぐ事例発表がありました。発表内容はサーバレスIoTシステムの開発に挑戦し、苦労した話とDynamoDBのランニングコストを削減のための工夫のお話しです。 ダイキン工業では、毎分500万アクセスを捌くためのIoT基盤構築をする必要があり、初期投資の削減と接続台数とクラウド利用料を連動させるためサーバレスを選択しました。 ただ、大量負荷がかかるシステムということもあり、コストを意識した設計が非常に重要で、設計ミスが青天井のコストとなり得ることが懸念だったとのこと。そのためDynamoDB設計ではコスト削減の工夫をし、試行錯誤でいろいろな設計を検証し、最もコスト最適な設計に行きついていました。 詳しくは資料が公開されていますので、こちらをご覧ください。 空調設備向けIoTシステムにおけるクラウドランニングコスト 終わりに いろいろなカンファレンスに参加したことがありますが、 ServerlessDays Tokyoはとても勢いのあるカンファレンスで、運営スタッフも参加者も私にはキラキラ見えました。 今回は大企業での事例発表が複数あり、とても参考になりました。 また、発表したことにより、いろんな方々とつながり、外部ではありますが、サーバレス仲間が増えたことはうれしい限りです。 サーバレスはまだまだ道半ばの技術ですので、我々もサーバレスの発展に貢献していきたいと思っています。 最後に懇親会前の集合写真を載せておきます。

経営企画部 マネージドセキュリティサービス推進室の細谷です。私が所属するインシデントレスポンスチームでは、攻撃の被害に遭ってしまったお客様を対象としたインシデントレスポンスサービス（インシデント全容解明・再発防止策の提示）を提供しています。 今回は、インシデントレスポンスチームで構築したOSINT 1 のデータベース（通称、OSINT-DB）を紹介します。 OSINT-DBとは？ OSINT-DBは、主にWeb上に公開されている悪性URLやハッシュ値などの脅威情報を予め収集し、インシデントレスポンスの案件対応時に検索できる弊社独自のデータベースです。OSINT-DBを活用することで、インシデントレスポンス時に見つけたURLやハッシュ値を最新の脅威情報と照らし合わせ、悪性かどうかを瞬時に判断することができます。その結果、既知のばらまき型マルウェアなどの早期発見や、解析時間の大幅な短縮につながります。 また、弊社のOSINT-DBでは、Web上に公開されている脅威情報だけでなく、NTTのセキュアプラットフォーム研究所による独自技術で作成した脅威情報も格納しています。 なぜOSINT-DBが必要なのか？ インシデントレスポンス時に見つけたURLやハッシュ値が悪性であるかを判断する上で、OSINTの情報を参照することがあります。OSINTは、調査効率を向上させる手法として知られています。しかし、OSINTの情報を参照するには、悪性URLを提供する脅威フィードや、ブログ、SNSなど多くの情報源を見に行く必要があり、目的の情報にたどり着くまでに時間がかかってしまう場合があります。 また、インシデントレスポンス時に発見するURLやハッシュ値は大量にあり、そのすべてを手動で調査するにはかなりの時間と労力が必要になります。 このような課題を解決するために、以下のようなデータベースが必要になりました。 調査に適した複数のOSINT情報源が一つにまとまっている 大量のURLやハッシュ値を高速に一斉検索できる これらの要件を満たすOSINT-DBによって、以下の図のように、解析者が検索を行う回数を格段に減らすことができます。以降の節では、OSINT-DBの仕組みについてさらっと触れたいと思います。 どこから情報を収集している？ セキュリティの脅威情報は、様々な形で公開されています。悪性のURLやハッシュ値をリストとして提供している脅威フィードだけでなく、Twitterやブログで公開されているものもあります。 OSINT-DBは、大きく分けて以下５つの情報源からデータを収集しています。 Twitter ：Twitterで公開されている脅威情報を収集します。 （例：UrsnifというマルウェアのIOCに関するツイート https://twitter.com/w3ndige/status/1183799724979249152 ） ブログ ：ブログで公開されている脅威情報を収集します。 （例：Kaspersky Labのブログに記載されている「IOCs」 https://securelist.com/ransomware-two-pieces-of-good-news/93355/ ） 脅威フィード ： URLHaus や Malshare といったサイトで公開されている脅威情報を収集します。 （例：URLhausという悪性URL提供サイト https://urlhaus.abuse.ch/browse/ ） Github ： Githubのリポジトリから脅威情報を収集します。 （例：Fireeyeのiocs https://github.com/fireeye/iocs ） NTTのセキュアプラットフォーム研究所から提供されている悪性URL/ドメイン（非公開情報） ：NTTの独自技術によって生成された脅威情報を収集します。 どうやって収集している？ 収集対象の情報源に応じて、オリジナルのクローラを実装しています。例えば、Twitterに対するクローラは、TwitterのAPIを用いて #malware や #ursnif などのハッシュタグの検索結果を取得します。また、ブログに対するクローラは、RSSフィードの更新状況を確認して最新のブログの情報を取得しています。 クローラが収集した情報から悪性URLやハッシュ値を抽出する処理には、 InQuest が提供している ThreatIngestor というツールを使用しています。このツールを用いることで、Defang 2 された文字列をRefang[^2]した状態で抽出できます。ThreatIngestorには、本来クローリングの機能がありますが、カスタマイズ性を高めるためにその機能は使用せず、上述したオリジナルのクローラを実装しています。 こちらの収集方法については、次の機会に詳しく説明できればと思います。 どう使っている？ 最後に、OSINT-DBの使用例を紹介します。 例として、 2019年10月16日のFireEye社によるブログ で紹介された、APT41 3 という攻撃者グループによるマルウェア感染のインシデントを想定します（こちらは我々が実際に対応した例ではなく、仮の例になります）。この時、フォレンジックやログ解析で見つかったドメインを、PythonのスクリプトでOSINT-DBから検索します。 以下の図は、 checkin.travelsanignacio[.]com というドメインの検索結果になります。検索はコマンドラインで行うので、grepといったその他のコマンドと組み合わせて使用することができます。また、出力される結果はTSV形式で、それぞれの行が検索にヒットした悪性URL/ドメインの情報を示しています。 解析者は、各行に示される情報源のリンクから、検索にヒットしたURL/ドメインがFireEye社のブログに載っていることが判明します。結果的に、見つけたドメインがAPT41による攻撃の痕跡であることが判明します。 今回の例では、簡単のため1つのドメインのみを対象に検索しましたが、実際にはコマンドラインのオプションを変えることで、複数のドメインやURL、ハッシュ値を一斉検索することができます。 まとめ 本記事では、インシデントレスポンスチームで活用しているOSINT-DBを紹介しました。インシデントレスポンスにおいて、OSINT活用は調査効率を向上させる反面、様々な情報源を参照する必要があるため、調査にはかなりの時間と労力が必要になります。このOSINT-DBを使うことによって、短時間で、かつ複数の痕跡の情報源を突き止めることができます。インシデントレスポンスチームでは、このようなオリジナルの解析補助ツールを他にも多く作成しており、高品質で迅速なインシデント対応を実現しています。 最近では、ファストフォレンジックス（調査する痕跡情報を一部に絞ることで、より迅速な調査を行う手法）の必要性が高まっています。それに伴い、近年、システムから調査価値の高い痕跡を抽出するファストフォレンジックツールが多数登場しています。一方で、OSINT-DB等、調査自体を高速化するツールの整備も同様に必要と言えるでしょう。 最後までご覧いただき、ありがとうございました。インシデントレスポンスチームによる次回の投稿では、インシデントの対応事例を紹介したいと思います。 Open Source Intelligenceの略称。諜報活動の一種で、主に一般公開されている情報源を用いた調査のこと。特にインシデントレスポンスにおいては、マルウェアのハッシュ値や通信先URLなどの痕跡をOSINTで調査することで、マルウェアの種類や攻撃手法を知ることができる。 ↩ 本来悪性であるドメインやURLの文字列に特殊な文字を追加することで、無害化する手法のこと。De(=除く) fang(=牙) から、悪性である主体の「牙を除く」という意味を持っている。また、Defangされた値を元に戻す手法をRefangと呼ぶ。Defangの例として、 ntt.com というドメイン名を ntt[.]com に変換する方法や、 https://www.ntt.com/index.html を hxxps://www.ntt[.]com/index.html に変換する方法がある。 ↩ 中国のサイバー攻撃グループの通称。2019年8月8日にFireEye社によって特定された。 https://www.fireeye.jp/company/press-releases/2019/fireeye-identifies-prolific-chinese-cyber-threat-group.html ↩

技術開発部 セキュリティユニットの後藤です。 Black Hat USA 2019 / DEFCON 27関連の記事として、第一弾「 Black Hat USA 2019 / DEF CON 27に参加してきました 」、第二弾「 Black Hat USA 2019 / DEF CON 27に参加してきました -Black Hat編- 」に続き、今回は、DEF CON 27についてご紹介します。 DEF CONの概要は第一弾の記事をご参照ください。本記事では主に、DEF CONで体験してきたことを中心にご紹介したいと思います。 DEF CONでは、様々なイベントが並列して開催されていますので、過ごし方はその人次第です。例えば次のようなイベントがあります。 DEF CON CTF Final: 有名なCTFの決勝戦が開催されています。 多数のVillage: 各分野のスペシャリストらが開いているブースで、トーク、ワークショップ等が行われています。 コンテスト、CTF、チャレンジ: オンラインや各Village等、いたるところで開催されています。廊下の壁に貼られているポスターにも問題が貼ってあることもありました。 Presentation: Black Hatと同様に講演もあります。Black Hat発表者が同じくDEF CONでも発表することもあります。Black Hatで聞くことができなかった発表は要チェックです。 ベンダブース: ディープなハードウェア、書籍等が販売されています。 Demo Labs: 私はチェックできませんでしたが、デモ等も行われていたようです。 私たちは主にVillageを回ったり、コンテストやCTFに参加して過ごしていました。 DEF CON バッジについて 今回のDEF CONバッジは、円形の白い石に基板が取り付けられたものになっています。 6つのLEDが搭載されており、他の参加者とバッジ同士をタッチすることで懐かしい8bitサウンドとともにLEDが光ります。バッジにはいろいろなタイプが存在し、いろいろな人とタッチすることでゲームが進行していくようです。 こちらのデバイスは第一弾の記事でも紹介したとおり毎年ハックでき、今ではWriteup等も公開されています。気になる方はぜひチェックしてみてください。 Village 初日に一通りVillageを回りましたが、4つのホテルに渡って多種多様なVillageがあり、混雑と会場の広さのために一通り回るだけでもかなり時間がかかります。私が特に興味を持っていたRed Team Offense Villageの行列がとりわけ長かったことが印象に残っています。 Village一覧は以下ウェブサイトを参照ください。 List of Villages At DEF CON 27 Red Team Offense Villageの問題にチャレンジ 私が主に時間を費やしたのはRed Team Offense Villageのチャレンジです。こちらのVillageでは3〜4つほどのチャレンジが開催されていました。 その中で私は「HACKING WEB APPS」のAdvancedの問題に挑戦しました。問題は指定されたウェブサイトに攻撃を仕掛け、内容を書き換えるというものです。取り組んだ理由として大きかったのが、その時点でまだ誰も解くことができていなかったという点です。 序盤は1番に解いた人に100ドルの賞金が出るとのことでしたが、正解者が現れなかったためか、後半になると賞金が200ドルにアップしていました。 The bounty is now $200 to the first that hacks and defaces the site at the @defcon @VillageRedTeam hacking web apps station #DEFCON #defcon27 pic.twitter.com/7S79krHC6j — Omar Ωr Santos (@santosomar) 2019年8月10日 私が知る限りでは、最後まで解けた人は現れなかったのではないかと思います。 ここでは私が問題に挑んだときの経過を追いながら、問題の雰囲気をお伝えすることができればと思います。 与えられた情報は標的のHTTPサーバのURLです。 Nmapでサーバをスキャンすると、HTTPに加えSSHのポートも開いていることがわかりましたが、NginxもOpenSSHも最新の状態でした。 まずは、与えられたURLのページにはインジェクションができそうなフォーム要素(文字入力可能なテキストボックス)等を探してみました。もし脆弱なフォームがあれば、そこからSQLコマンドやOSコマンドを注入し、非公開情報の読み書きや任意の操作ができます。これを利用してWebコンテンツの書き換えができたり、非公開コンテンツにアクセスできたり、ログイン情報を知らなくともログインできる可能性があります。しかし、ページ上にはフォーム要素は見つかりませんでした。 次に、HTTPサーバで公開されるべきではないファイルが公開されていないかといった設定の誤りに着目しました。そういったファイルは公開することを意図しておらず、秘密情報や攻撃者にとってさらなる攻撃の手掛かりとなる情報が記載されていることがあります 1 。 そこで、 dirb というツールを用いてリンクされていない公開ファイルを辞書ベースで探してみました。その結果、いくつかの静的ファイルが見つかったのですが、中でも気になったのは.gitディレクトリ 2 が見つかったことです。このディレクトリを丸ごと手に入れてしまえば、それを利用して最新・過去コミットのファイルを全て復元することができます。 ここで問題となったのは、標的のHTTPサーバではディレクトリリスティング 3 が無効になっており、.gitディレクトリの中身を把握することができない点でした。.gitディレクトリを構成するファイルのほとんどは名前が決まっており推測が容易です。しかし.git/objectsの中身は、コミット、バージョン管理対象ディレクトリ、バージョン管理対象ファイルを示すオブジェクトのそれぞれの {SHA-1ハッシュ値上2桁のディレクトリ名}/{SHA-1ハッシュ値下38桁のファイル名} という規則でファイルが格納されていますので、容易に推測できません。 そのため、私は以下の手法を用いて特定することにしました。 Don’t publicly expose .git or how we downloaded your website’s sourcecode - An analysis of Alexa’s 1M - Internetwache - A secure internet is our concern こちらの手法は、以下のようにして.git/objectsの中身のファイルを特定します。 .git/refs/heads/{ブランチ名} ファイルから、ブランチの先頭コミットを示すハッシュ値を取得 git cat-file -p {コミットを示すハッシュ値} コマンドでその1つ前のコミットを示すハッシュ値とリポジトリのルートディレクトリを示すハッシュ値を取得 git cat-file -p {ディレクトリを示すハッシュ値} コマンドでそのディレクトリ配下のディレクトリ、ファイルを示すハッシュ値を取得 2.を繰り返すことでコミットをたどり、3.を繰り返すことで各コミットのディレクトリ、ファイルをたどることができます。 こうして得られたSHA-1ハッシュ値群がそのまま.git/objectsディレクトリの中身となります。 上記の手法で.gitディレクトリ以下の中身を特定し、ローカルにダウンロードしてから、gitコマンドで最新のコミット・過去のコミットのファイルを復元することができましたが、突破口が見つからず、そこで時間切れとなってしまいました 4 。 残念ながら最後までたどり着くことはできませんでしたし、解答が公開されていないため、上記のアプローチが合っているかはわかりません。 しかし、Black Hatトレーニングで学んだ様々なツールを使用して試行錯誤することはよい実践になりました。またWebサーバのディレクトリリスティングが無効化されていても、.gitディレクトリからファイルを復元できてしまうことも実際に手を動かして体験できました。 ちなみにRed Team Offense Villageは今年初の開催だったようです(DEF CON 26ではVillage一覧になかったため)。 SNS上では、「来年はもっと大きなスペースを」という声も上がっていました。 その他のVillage その他、私たちが回ったVillageを簡単にご紹介します。 Crypto Village: 暗号系のVillageです。こちらではポピュラーなシーザー暗号から変わり種のDancing Manと呼ばれる換字式暗号までさまざまな問題が用意されていました。同行したメンバーは「Crypto & Privacy Village Puzzle」に挑戦していましたが、かなり難易度の高い問題だったとのことでした。 Lock Pick Village: 鍵を使わず錠を開ける方法を学べるVillageです。錠の構造がわかるプレゼンテーションが行われていたり、設置されたテーブルで解錠を試したりできるようになっていました。手元で中身の構造を理解できる透明な錠もありました。ピッキングツールの販売もありましたが、日本では一般の方の所持は違法となるため注意が必要です。 Lock Bypass Village: ピッキングによる解錠とは異なり、錠の仕組みを理解してロックを迂回するようなことを学ぶことができたそうです。 Packet Hacking Village: 実際にネットワークに繋いでパケットをキャプチャし、そこからバイナリを解析する等のチャレンジに同行したメンバーが取り組んでいました。非公式のSSIDに接続して平文でCredentialをやり取りするとその情報を表示されてしまう「Wall of Sheep」のスクリーンもこのVillage内に設置されています。 Internet of Things Village: ユニークだったのがATMをハックするチャレンジです。ハックできた人は実際にそのATMから現金を出金できるというおまけつきでした。 DEF CON CTF Final ホテルのロビーの一部を使って決勝が開催されており、DEF CONの参加者は誰でも様子を見ることができるようになっていました。 CTFでは競技中に大抵BGMが流れるものなのですが、今回も同様に流れており、会場はCTFらしい雰囲気に包まれていました。 ベンダブース Black Hatのビジネスホールとはまた違った、もう少し”緩い”ブースがDEF CONのベンダブースです。 アンテナ、ピッキングツール、ハッキングツール、ひと目見ただけではなにができるのかわからない基板のようなものまで、ディープな商品が並んでいるテーブルを眺めているだけでも非常に面白かったです。技術書の出版社による販売もあり、興味深い技術書が多く、私含めメンバー全員が何らかの本を購入していました。 DEF CON開催期間の前半は特に混雑しており、エリアを一周するだけでも一苦労でしたが、後半になるにつれて徐々に混雑も緩和されたので、人気商品を買う目的がないのであれば落ち着く頃を狙っていくとよいかもしれません。 参加を終えて Black Hatとは雰囲気が全く異なり、まさに「お祭り」で、様々な分野のセキュリティを楽しめるようなイベントであったと感じました。Black Hatはどちらかといえば最新動向の収集、新しいソリューションの目利き等が中心で、DEF CONはみんなが参加してワイワイと手を動かすことが中心です。 Villageでは素晴らしい技術者たち(運営側や他の参加者たち)と非常に近い距離で交流ができますので、ぜひ交流してみてください。より一層DEF CONを楽しめると思います。 例えば、ポピュラーなCMSであるWordPressでは、wp-config.phpにデータベースの認証情報等が記載されています。ついやってしまいがちな設定誤りの例として、バックアップ目的でwp-config.php.bak等にリネームして保存してしまうと、PHPファイルとみなされず、テキストファイルとして中身が公開されてしまうことが挙げられます。 ↩ このディレクトリはバージョン管理システムであるGitを利用すると生成されるものです。この中にはGitで管理されているファイルの情報が格納されています。 ↩ URLでディレクトリ名を指定した場合に、配下のファイルリストを表示する機能を指します。ディレクトリ構成が見えてしまうため、理由がない限りこの機能は無効にすべきです。 ↩ 本記事を作成しながら、もしかすると別ブランチに重要なファイルがあったのでは、と思い始めました。 ↩

技術開発部セキュリティユニットの山崎です。 enPiT-Security（愛称 SecCap） 1 において、今年度もNTT Comは協力企業として、2019年8月27日（火）～8月30日（金）の4日間に渡って産学連携によるリスクマネジメント演習を行いました。セキュリティユニットの伊藤、後藤、星野、久保、山崎がNTT Comの“Security Bootcamp プログラム”を用いて演習を行いましたので、初日の模様を紹介します。 SecCapとは SecCapは、セキュリティを正しく理解し、実社会で生かすことのできる実践力を備えた技術者や経営者、すなわち産業界が求めるセキュリティ実践力のあるIT人材を増やすことを目的として、2013年より5つの連携大学（情報セキュリティ大学院大学、奈良先端科学技術大学院大学、北陸先端科学技術大学院大学、東北大学、慶應義塾大学）が中心となり始動したプロジェクトです。 NTT ComもSecCapの目標である「セキュリティ対策を技術面・管理面で牽引できる実践リーダーを育成する」を実現するため、開設当初より技術演習をはじめとした協力を続けています。 NTT Comの“Security Bootcamp プログラム” NTT Comでは座学による幅広い知識の獲得に加え、ハンズオンによる実践的な研修を重視しています。この方針に沿って技術開発部で独自に開発したセキュリティ研修が “Security Bootcamp プログラム”です。 プログラムの受講者は「受講者ポータルサイト」とさまざまな攻撃を再現して分析・解析する作業を安全に行うための「サイバー攻撃テストベッド」上の仮想環境を通じて演習を行います(図1)。 Security Bootcamp プログラムでは「Basicコース」と、応用力をつけるための「Advancedコース」(図2)の2コースを設け、いずれもセルフトレーニングにより学習できるようデザインしています。 SecCapでは、Advancedコースの一部をSecCap向けに特別にカスタマイズし、1日コースとして提供しました。 演習模様 演習当日は、講師・スタッフはじめ、若手社員を中心とした有志13人がチューターとして加わりました。チューターにとっても初めての演習となるため、事前に同演習を受講してもらうことでチューター自身のスキル向上を図り、あらかじめ学生がつまずきそうな場所を推定したり、スライドや配布資料で分かりづらかった点を改善したりするなど、より充実したサポートができるように努めました。その甲斐あって、参加学生からは、次のような大変高い評価をいただきました。 -「今回の演習では、全体を通してつきっきりでチューターの方に気遣っていただき、アドバイスもいただけたので、進捗が滞ることなくはかどって、短い時間の演習でも効率よく集中して取り組むことができました」 -「セキュリティに関してはあまり詳しくなかったのですが、わからない箇所があったときには逐一チューターの方が解説してくださったので、理解しながら進めることができました」 最後に演習を終えて、慶應義塾大学大学院の砂原教授から「リスクマネジメント演習には、NTT Com様はじめ協力企業様から多大なご協力をいただいており、セキュリティ最前線で活躍されている社会人の方々と学生の交流を実現する大変有意義な機会となっています。重ねてご対応に感謝申し上げます」とのお言葉をいただきました。引き続き産学連携によるセキュリティ人材、実践的リーダー育成に貢献していきます。 enPiT-Security ↩

技術開発部セキュリティユニットの小林です。 開催中の大規模スポーツイベントに便乗したサイバー犯罪が報告されています。 ^1 端的に言えば「無料で試合をインターネット中継します」という触れ込みで、メールアドレスやパスワード、クレジットカード番号の窃取を試みるものです。この記事では、同じ手法の攻撃を観測したこと、またその他のスポーツイベントに対しても同様の手口による攻撃を観測したことから、スクリーンショットを交えて報告します。 観測した事象 （以下で提示する画像は、都合により一部マスクしているところがあります） 2019/11/08追記： 事態を確認した時点で関係機関に連絡しており、下記の踏み台にされているページはすでに削除されています。 Googleで「フランス トンガ live」をキーワードに検索した結果がこちらです（シークレットモードを利用しています）。 トップニュース下の、検索結果の第1位に挙げられたサイトをご覧ください。サムネイルに「LIVE」や「進行中」の文字があり、正規のインターネット中継に見えます。 これをクリックして遷移すると、いくつかのリダイレクトの後、いかにもライブ中継が見られそうなページに着地します。 ここでスクリーン上の再生ボタンを押すと、アカウントが必要であることが示され、そのために「CREATE FREE ACCOUNT」を押すよう促されます。これをクリックすると次のページに飛ばされます。ちなみにWATCH LIVE、SIGNUP NOWのどれを押しても同じページに飛ばされます。 簡単なユーザー登録を済ませればいろいろな映像を見られそうな雰囲気がありますが、実体はそうではありません。勘の鋭い方は日本語がおかしいので気づけるかもしれません。右側の「無料でお申し込み頂けます！」の欄に入力されたメールアドレスとパスワードが攻撃者に窃取されます。 このほかに、当初遷移したサイト（マスクしてあるサイト）のドメインをGoogleで検索したところ、このように表示されました。オレンジの枠で囲った部分に、今回と同様の意図が見られるページが表示されています。 なお図の最上位に表示されているページにアクセスすると、ドメインの所有者が運営しているサイトが表示されました。このことは、すでにこのサイトが攻撃者によって乗っ取られており、サイト管理者の目の届かないところで攻撃キャンペーンの踏み台として使われていたことを示唆しています。 Google ChromeやMozilla Firefoxブラウザにはフィッシングサイトやマルウェアに関係したサイトを閲覧しようとするとブロックする機能がありますが、記事執筆時点（2019年10月8日）でGoogle Chrome 77とFirefox 69で同サイトを閲覧しても特にブロックされることはありませんでした。 想定される被害 なぜメールアドレスとパスワードの取得が脅威になるかといえば、「メールアドレスは日頃よく使うものを入力しがち」「パスワードは少ない種類を使い回しがち」という人間の特徴を押さえていることによります。攻撃者は窃取したメールアドレスとパスワードの組み合わせを、リスト型攻撃に利用することが想定されます。想定される被害としてはアカウント情報を使い回しているサイトになりすましログインされ、ECサイトであれば身に覚えのない買い物をされたり、銀行や送金サービスなど金銭を扱うサイトであれば不正に送金されるなどが考えられます。 また攻撃者にとって「生きている」メールアドレスは価値が高い情報です。フィッシング詐欺やスパムキャンペーンのリストに登録される可能性も出てきます。あるいは過去に既に流出したアカウントリストと照合され、新たなアカウント情報としてリスト型攻撃に使われることも考えられます。 どうすればよいか 身も蓋もありませんが、まずはこのようなサイトにたどり着かないことが第一です。そのためにはTVerやNHK、J SportsやDAZNなど素性が分かっているサイトで視聴することが重要です。 上の悪性サイトが謳うような、「無料」「広告なし」「高品質」で「あらゆるコンテンツ」が視聴できるほどうまい話はありません。このようなコンテンツは、インターネット・地上波・BS・CSにかかわらず放送している会社が権利元に放映権料を払って配信・放送しているので、広告なしの無料というのは商業上考えられない状況です。 しかし、誰が公式配信者であるかが一目では分かりにくいため、自衛策としては怪しいサイトに気づくしかないという状況にあります。 一般論として、リスト型攻撃を回避するためにはパスワードを使い回さないことが一番です。そのためにはパスワード管理ソフトを使い、アカウント情報を代わりに覚えさせておく方法が考えられます。一つのマスターパスワードさえ自分で覚えておけば、Webサイトごとに異なるアカウント情報を安全に記録できます。ランダムなパスワードを自動的に生成する機能と合わせて使うことが前提になります。 読者のみなさまもくれぐれもご注意ください。

はじめまして、技術開発部の小倉です。 9月18日にNTTグループのエンジニアが技術交流を行うNTT Engineers' Festa #3を開催しました。 今回はその開催背景や当日の様子についてご紹介したいと思います。 NTT Engineers' Festaとは NTT Engineers’ Festaは、NTTグループのエンジニアたちが一堂に会して技術交流を行うためのイベントです。 NTTグループ内には、各社の様々な案件でアプリケーションやシステムの開発・運用を行うエンジニアやOSSのコミッタ、メンテナ、コントリビュータなどを担う多様なエンジニアが所属しています。 本イベントではエンジニアたちがもつ技術の（無駄遣い含む）ノウハウや悩みを共有・議論しあうことで、参加者ひとりひとりがエンジニアとして成長することを目的としています。 本イベントはNTTグループのエンジニア有志によって運営され、場所やNWについて会社から支援を得るという形で開催しており、今回で3回目の開催となりました。 開催の背景 もともとは3年前からNTTグループのエンジニアと外のエンジニアが交流するNTT Tech Conference（以下、TechConf）というイベントの開催を行っていました。 ^1 ^3 TechConfのアンケートは毎回すべて目を通していますが、NTTグループの参加者から「NTTグループ内でしか話せない内容を相談したい」などの声が複数ありました。 また、スタッフのイベント運営慣熟のため、練習としてNTTグループ内で行ったTechConf#0というイベントが参加者に好評だったこともあり、TechConfとは別のイベントとしてNTT Engineers' Festaの開催を昨年からはじめました。 当日の様子 当日はNTTグループ15社から合計約150名が参加しました。 発表では「 SpinnakerでBlue-Green Deploymentやってみた 」をはじめ、コンテナやKubernetes、NW、セキュリティ、Deep Learningなど多岐にわたる技術トピックや、エンジニアのはたらきかたについての発表などが行われ、それぞれで発表と質疑が行われました。 （発表資料については発表者に公開をお願いしておりますが、公開できないものもありタイトル等伏せております。） また、NTTグループに限定したイベントということでグループ内の人事にお声がけし、エンジニアのそだてかたについて人事とエンジニアが簡易なOST（Open Space Technology）形式で5つのテーマを出し、議論と発表が行われました。 当日は弊社の経営層も参加し、質疑や議論を行い発表者や参加者と意見を交わしていました。（下記証拠） NTT Engineers’ Festa #3ってのを今日やってて 、懇親会で他社の人から「コムの発表者と年配の男性が激論してるのが面白かった」って言われて「あれコムの副社長」「ふぁっ！？」ってなったのが面白かった。最近経営幹部が草の根なイベントに出てきてくれるようになってとても良い。 — ゆやりん (@yuyarin) September 18, 2019 まとめ NTT Engineers' FestaはNTTグループのエンジニアによって開かれ、エンジニアたちが交流し、成長するイベントとして今後も続けて行きたいと思います。 また、この冬にNTT Tech Conference #4の開催を計画しています。この記事をお読みのみなさまとも交流できればと思いますので、興味のある方はぜひご参加ください！

技術開発部セキュリティユニットの星野です。 前回の 「Black Hat USA 2019 / DEF CON 27に参加してきました」 では、それぞれのイベントの概要とおすすめの歩き方についてご紹介しました。 今回は、そのうちBlack Hat USA 2019の詳細な内容についてご紹介します。 前回も述べたとおり、Black Hatの中で行われるイベントは主にトレーニング、ブリーフィング、ビジネスホールの3つがあります。その3つのうち、私が参加したトレーニングの内容と、聴講したブリーフィングの一部をご紹介します。 トレーニング内容の紹介 私は、 “Advarsary Tactics: Red Team Ops” という4日間のトレーニングを受講しました。 https://www.blackhat.com/us-19/training/schedule/#adversary-tactics---red-team-ops-14189 このトレーニングは主に座学と実践という二つの内容で構成されています。座学では、Red Team 1 のための「インフラ構築」「攻撃テクニック」「ツールやPost-Exploitフレームワークの活用方法」等を学びます。実践では、ラボ環境に模擬的な企業の環境が用意されており、座学で学んだ内容を元にRed Team活動、つまりは攻撃を行います。 ラボへの攻撃に関してはチーム戦でした。同じ卓に座った受講者がチームとなり、攻略したホスト、奪ったクレデンシャルなどに応じて得点が得られる、いわゆるCTFのような競技形式になっていました。言い換えると、ラボ環境はチームで共通のものを使用する形式となっていました。これはRed “Team”であることを意識した計らいであると考えられます。 ここからはトレーニングのポイントをいくつかご紹介します。 熟練のトレーナー・スタッフ このトレーニングでは、かなり専門的な内容を学ぶことができます。それもそのはず、このトレーニングを提供するSpectreOpsという組織には、数ある有名なRed Team向けOSS・ツール・ライブラリの開発に関わった人が多数在籍しているのです。PowerPick、PowerShell Empire、BloodHoundなどのツールを聞いたことがある人は多いのではないでしょうか。このトレーニングでは、長年に渡りRed Team的なセキュリティ業務に携わってきたトレーナーが直々にそのノウハウを教えてくれるわけです。 熟練の受講者??? トレーニングの内容、トレーナーのキャリアもさることながら、特筆すべきはその受講者たちです。「あなたは本当にこのトレーニングを受ける必要があるのですか？」、そんな”熟練の受講者”が散見されました。 実は、座学と実践は、交互ではなく同時に進行していました。どういうことかと言うと、座学を聞く必要が無いと判断した受講者は、次々にラボ環境へ攻撃をして良いことになっていたのです。実際、私の隣に座っていたチームメンバーは、トレーニング開始と同時に攻撃を仕掛けていました。彼こそが熟練の受講者です。私が攻撃を始める頃には、彼がラボ環境で暴れまわっており、そこには最初は存在しなかったであろう端末・クレデンシャル情報が無数に列挙されていました。もはや初期状態がわかりません。その侵入の速さに絶句していたのも束の間、「君のために権限昇格したコネクションを用意しておいたよ」と今後の人生で言われることのないであろう言葉をかけられ、どこからツッコめば良いかわからない状況でした。聞いたところによると、彼はRed Team的な業務に長年携わっており、今回使用したツールの利用にもかなり長けていたようです。 洗練されたラボ環境・監視システム トレーニングのRed Team活動では、主としてCobalt Strikeというツールを使いました。Cobalt Strikeは、多機能な有償のペネトレーションテストツールです。PsExecやWMI 2 を使ったリモートでのペイロード実行や、PowerShell.exeを使わないPowerShellスクリプト実行（いわゆるPowerShell without PowerShell）の機能を有しています。PowerUp, PowerSploit, PowerViewなどのライブラリをインポートし、それらのコマンドレットを感染端末上で使うこともできます。侵入した端末をビジュアライズしたり、抜き取ったクレデンシャルなどの情報をリスト化するような機能もあります。これらの機能を使い、脆弱なサービス設定を悪用した権限昇格、SYSTEM権限でクレデンシャルダンプ、そのクレデンシャルを使い横展開、ドメイン管理者の特定、ドメイン管理者が利用している端末の特定、キーロガーによるドメイン管理者のクレデンシャル窃取、DCへのログイン、などのように攻撃を進めていきました（あくまで一例で、いくつかの侵入経路が存在します）。ここまでのラボ環境の構築だけでもかなり大変だと思うのですが、さらに倍ほどの端末が用意されており、非常に洗練して作られた模擬企業だったと言えます。 もう一つ目を見張る点は、お手製の監視システムです。運営側が用意した監視システムが、各チームの攻撃を監視していました。攻撃したことがバレやすい、イケてない攻撃をすると、以降の攻撃が成功しなかったり、その旨がチャットで通知されたりします。ただ攻撃させるだけではなく、隠蔽の必要性も考慮したラボ環境を用意している点はこのトレーニングならでは、だと感じました。 残念ながら最深部まで侵入を進めることはできませんでしたが、よくできたラボ環境で有償ツールを用いた攻撃を試行することができるこのトレーニングは、非常に価値のあるものだったと感じています。 ブリーフィングの紹介 ブリーフィングは、講演のことです。なお、Black Hatの講演で使われたスライドは一部を除いてBlack Hat公式サイトの各講演詳細ページにアップロードされています。 MITRE ATT&CK: The Play at Home Edition https://www.blackhat.com/us-19/briefings/schedule/index.html#mitre-attck-the-play-at-home-edition-15035 MITRE ATT&CK自体の活用方法にフォーカスした唯一の講演だったと思います。ATT&CKを組織で活用する術をストーリー仕立てで説明するといった内容でした。この講演のポイントは2点あり、一つは企業・チームが抱えているであろう問題点とATT&CKの効果が分かりやすく説明されている点です。もう一点は、解決にあたり使用できる・参考にできる、ATT&CKに関連するツールやブログ等の情報源が紹介されている点です。脅威から組織を防御するためには、新しい脅威を見逃さないための継続的な対応が必須であることを主張し、そのための考え方や活用できるツールについて説明していました。 （出典： http://i.blackhat.com/USA-19/Wednesday/us-19-Nickels-MITRE-ATTACK-The-Play-At-Home-Edition.pdf ） Fantastic Red-Team Attacks and How to Find Them https://www.blackhat.com/us-19/briefings/schedule/#fantastic-red-team-attacks-and-how-to-find-them-16540 Atomic-Red-TeamとEQLという二つのツールについて、それぞれの開発者がその活用方法を紹介しています。Atomic-Red-TeamはRed Team的な侵入テスト用のOSSで、MITRE ATT&CKで定義されるテクニックベースでシンプルに攻撃を自動化することができます。EQLはsysmonのログ等のイベントの検索を行うためのPython実装のツールです。この講演では、Atomic-Red-Teamを使った攻撃をEQLを使ってログの中から見つけ出すためのノウハウを、デモや実際のログを見せながら解説していました。攻撃と防御双方のノウハウを説明しているわけです。これは筆者の意見ですが、どちらか一方が欠けてしまうとそれぞれの結果を評価できなくなりますので、この観点は大切だと思います。 Black HatのKeynoteで、自分の解析能力を何倍にも高める梃子となるツールを持つことが重要であるといった話がありました。筆者もこの考えに同感で、この講演で紹介されたものに限らず、セキュリティチームとして流行りのツールやOSSをウォッチすることは非常に重要だと思います。 （出典： http://i.blackhat.com/USA-19/Thursday/us-19-Smith-Fantastic-Red-Team-Attacks-And-How-To-Find-Them.pdf ） Dragonblood: Attacking the Dragonfly Handshake of WPA3 https://www.blackhat.com/us-19/briefings/schedule/#dragonblood-attacking-the-dragonfly-handshake-of-wpa-15991 Dragonflyと呼ばれる、WPA3のハンドシェイク方式に関する脆弱性の話題です。いくつか問題点はあるようですが、中でもハンドシェイク時のパスワード生成アルゴリズムへのサイドチャネル攻撃の説明が非常に分かりやすく印象に残っています。パスワード生成時に特定の値が取れるまでiterationする部分がありますが、その値の計算に任意に変えられる値が使われているため、様々な値を取らせた状態でiterationの処理時間を計測してサイドチャネル攻撃を仕掛けることができます。ちなみに、講演者はもちろんDragonbloodを発見した研究者本人です。また、WPA2の脆弱性であるKRACKsを発見した研究者でもあります。そのご本人に直接お目にかかれるのも、講演に参加する大きなメリットと言えるかもしれません。 （出典： http://i.blackhat.com/USA-19/Wednesday/us-19-Vanhoef-Dragonblood-Attacking-The-Dragonfly-Handshake-Of-WPA3.pdf ） まとめ 星野が参加したトレーニングの内容と聴講したブリーフィングの内容についてご紹介しました。 トレーニングについては、他のメンバーが参加したトレーニングも面白そうなものばかりでした。非常にクオリティが高いです。今年は各トレーニングにSKILL LEVELというのも示されていたので、来年のトレーニングの参加を検討している方はそれを参考にするのが良いかもしれません。 ブリーフィングについては、他にも数え切れない程の講演がありました。興味が湧いた方は是非公開されている発表資料をご覧いただくか、来年のBlack Hatへの参加を検討してみると良いと思います。 次回はBlack Hatとはまた一風変わった、DEF CONに関する内容を、同じチームの後藤より紹介いたします。 実際の攻撃と同等の手法で攻撃シミュレーションを企業・組織に行うことで、それらの実施しているセキュリティ対策が正しく機能しているかを評価することを目的としたチーム。 ↩ いずれもMicrosoft正規のツール・技術である。リモート端末でプログラムを実行する機能を有しており、攻撃者が悪用することが知られている。 ↩

技術開発部 セキュリティユニットの小林です。 8月上旬にアメリカ・ラスベガスで開催された Black Hat USA 2019 および DEF CON 27 へ参加してきました。その模様をレポートしつつ、初めての方向けのアドバイスも添えてお送りします。 Black Hatとは Black Hatは1997年より開催されているコンピューターセキュリティに関する世界有数のカンファレンスで、レギュラーイベントとしては毎年アメリカ (USA) 、ヨーロッパ (Europe) 、アジア (Asia) の3地域で行われています。今回参加したUSAはBlack Hatの中でも最も長い歴史を持ち、また参加者の数も最大です。USAの会場は例年ラスベガスのマンダレイ・ベイホテルのコンベンションセンターで、今回は世界112カ国から2万人を超える参加者が訪れました 1 。 ちなみに本来このイベント全体を指してBlack Hat Briefingsといいますが、よくBlack Hatと略されてますので本稿でもそれに倣います。 イベントは大まかにトレーニング、ブリーフィング、ビジネスホールの3つに分かれています。8月3日から8日までの6日間の会期のうち、最初の4日間でトレーニング、残りの2日間でブリーフィング・ビジネスホールが催されます。 トレーニングはセキュリティベンダーの社員などが提供する講義で、今回は延べ120コース以上開催されました。2日間コースと4日間コースがあり、スタイルも座学とハンズオン、グループワークなど様々です。私はOSINTに関するハンズオンベースのトレーニングを受講してきました。今年からは受講者に対して受講証 (Digital Certificates) が発行されるようになりました。 ブリーフィングはBlack Hatのメインイベントとも言え、セキュリティベンダーやソフトウェアベンダーの社員、研究者らがそれぞれの成果を発表する場です。21のジャンルから、新たに発見した脆弱性や攻撃手法、防御のためのベストプラクティスなど、120を超える発表がありました。日本のニュースサイトでも話題になった、WPA3の脆弱性 "Dragonblood" もここで発表されました。 ビジネスホールは端的に言えば見本市で、ベンダーが製品紹介や小さなプレゼンテーションをしたり、ワークショップやミニCTFが行われていたり、あるいは採用活動を行っていたりと、盛りだくさんの内容です。その一角にアーセナルと呼ばれる会場があり、85以上のオープンソースツールの実演が行われました。ブリーフィングよりも発表者との距離が近く、内容について議論している風景も見られました。 DEF CONとは DEF CONもBlack Hat同様歴史あるイベントで、今回で27回を数えます。ただ色合いはBlack Hatとはまるで異なり、言うならば「ハッカーのお祭り」という雰囲気です。今年の会期は8月8日から11日までの4日間で、今年の会場はホテル4軒にまたがっていました。 内容はBlack Hat以上に多種多様で、大雑把にジャンル分けしても昼間はプレゼンテーション、コンテスト、ワークショップ、ツール・製品のデモなどが行われているほか、夜になると映画の上映会が始まったり音楽イベントが始まったりと賑やかです。特筆すべきイベントとしては、期中にDEF CON CTFの決勝戦が開催されることが挙げられます。CTF自体の説明はほかに譲りますが、世界最高峰の大会として名が知られており、毎年5月のオンライン予選を勝ち上がったチームが本戦に臨みます。 会場内にはビレッジという仕切られたエリアが各所にあり、ある特定のテーマに関する展示、プレゼンテーション、ワークショップが行われています。一例を挙げるとAI, Block Chain, Cloud, IoTなど技術分野や、Blue team, Red team, Social engineeringなどセキュリティ分野、変わり種ではBio Hacking, Car Hacking, Lock Pickなども見られました。興味深かったのはAviation Villageの一角でアメリカ国防総省のDefense Digital Service ( https://dds.mil ) という部局が人材を募集していた点で、DEF CONのようなカジュアルな場にも出展して人的リソースを確保しようとしているところに日本との違いを感じました。 会場を歩いていると、謎のQRコードが書かれたポスターが張られていたり（中身は謎のバイナリ）、いきなりクイズを渡してくる人がいたり、必死に何かCTFを解いている人がいたりと、本当にいろいろな人、物に出くわします。ただ散歩しているだけでも楽しいですが、訪れた際にはぜひ何かHackしてみるのをお勧めします。私は休憩所でCrypto & Privacy Villageで配られていたパズルを解いていたところ、隣の席にやってきたトルコ人の青年に「何をHackしてるの？」と声をかけられ、1時間ほどいっしょに解いてくれるという素敵な体験がありました。 ちなみにバッジですらハックできるそうです。組み込み方面で腕に覚えのある方、ぜひデバッグ機材をお持ちになってお越しください。 参加するには Black Hatは参加登録が必要です。早期割引があるので、参加すると決めたら早めに登録するのがよいでしょう。パスは何種類かありますが、ブリーフィングパス、またはブリーフィング＆トレーニングパスをお勧めします。ビジネスパスは安価なものの、ビジネスホールにしか立ち入れません。 とりわけ、トレーニングを受けたい方はとにかく早く登録しましょう。席数がかなり限られているため、4月時点で売り切れ間近となっているコースも見られました。 https://www.blackhat.com/us-19/training/schedule/index.html DEF CONには早割などはありませんが、Black Hatの参加登録時に同時に購入できるのでそちらがお勧めです。その場合Black Hatの会期中に、 Black Hat会場内の カウンターでDEF CONバッジ（入場証）と引き換えることになります。DEF CONのみに参加したい場合は、会期中に会場の受付窓口で参加費を払えばOKです。 おすすめの歩き方 とにかくまずRegistrationを済ませる 参加登録のことではなく、現地での参加受付のことです。これを済ませないとどこの会場にも入れません。本人確認があるのでパスポートをお忘れなく。 Black HatのRegistrationではバッジ（入場証）のほかバックパックがもらえました。DEF CONのバッジを引き換えた（上述）際には、バッジ、ステッカー、ノートと会場案内の小冊子がもらえました。この会場案内の小冊子がWebサイトを見るよりもよほど良くまとまっていますので、引き換えが始まったら早めに入手しておくことをお勧めします。 スタッフに聞く Black Hat, DEF CONとも会場が広く、また案内も不十分なので、目的地がわからなくなったらスタッフに聞きましょう。どちらのイベントでもスタッフは同じTシャツを着ており、そこかしこにいます。 身軽な装いで Black Hat, DEF CONとも会場が大変広く、相当な距離を歩くことになります。動きやすい服装に履き慣れた靴で臨むことをお勧めします。ただ会場の冷房がけっこう強めなので、羽織り物が1枚あるとよいでしょう。またBlack Hatのトレーニングやビジネスホールを訪れる場合、けっこうな量の配布物をもらうことになるのでエコバッグがあると便利です。 Black Hatはアーセナルに注目 Black Hatでのブリーフィングの内容は (1) 後日スライドが公開される (2) セッションの録画が販売される――ものの、アーセナルの発表ではそのような手当てがありません。ブリーフィングとアーセナルは同時進行で行われているため、もしアーセナルに気になる内容があればそちらを優先することをお勧めします。Black Hatで発表された内容はDEF CONでも同じ内容で発表されることがあるので、DEF CONのスケジュールにも注目です。 DEF CONの無線LANに注意 DEF CONは会場で無線LANによるインターネット接続サービスを提供していますが、適切に暗号化されたSSID (DefCon) のほか、まったく暗号化されていないSSID (DefCon-Open) が飛んでいます。前者は安全に使えるものの、後者は何をされるか分からないので、接続したければそれ専用に「まっさらなラップトップ」を持参することをお勧めします。 会場では、DefConという名の「暗号化されていない」アクセスポイントを実際に観測しました。これはユーザーを騙して（暗号化されていると勘違いさせて）通信を横取りしようとするものと思われます。私も危うく接続しかけたので、多少気を引き締めねばと思いました。一部の危険な無線LANはPacket Capture VillageのWall of Sheepにつながっており、Webサービスやメールのユーザー名・パスワードを送信しようものならここで晒し上げられてしまいます（さすがにパスワードは一部がマスクされますが）。 最後に 次回は、Black Hatで見聞きしてきたテクニカルな内容を、同じチームの星野より紹介します。 なおBlack Hatのクルーが撮影した写真アルバムはこちらからご覧になれますので、併せてご覧ください。 https://www.flickr.com/photos/blackhatevents/albums/72157710161031186 Black Hat USA 2019 Closes Out Another Record-Breaking Event in Las Vegas ↩

こんにちは、技術開発部 セキュリティユニットの田中です。社内のセキュリティエンジニアのメンバーで、サイバーセキュリティ関係の話題を書いていきます。初回となる今回は「ラテラルフィッシング」についてお送りします。 ラテラルフィッシングとは？ 皆さんは、最近ネットでも取り上げられるようになってきた、「ラテラルフィッシング」(Lateral Phishing)というセキュリティ脅威をご存知でしょうか？ ラテラルとは横方向へ、を意味し、サイバー攻撃では、攻撃者が内部ネットワークに不正侵入後、感染を拡大する行為を「ラテラルムーブメント」（横方向への移動）と呼び、ご存知の方も多いと思います。 「ラテラルフィッシング」は、攻撃者が組織内のメールアカウントを何らかの手法で乗っ取り、その組織の正規アカウント（ドメイン）からフィッシングメールを送るものです。正規の内部アカウントからのメールなので、現在の攻撃検知の想定外のため、一般に検知が困難で、攻撃の実態もよくわかっていないのが現状でした。 ラテラルフィッシングの実態と対策に関する論文発表 この「ラテラルフィッシング」に対し、大規模なデータセットで実態を明らかにし、防御手法を提案・評価した、非常に質の高い研究論文発表が先月8/15に行われたので、本ブログで皆さんに紹介したいと思います。 セキュリティの学術系国際トップカンファレンスは、ゴルフ界やテニス界のように、4大メジャー大会が存在します。その1つが毎年USで夏に開催されるUSENIX Securityで、この難関カンファレンスに採択され（採択率16%, 2019）、かつ、Distinguished Paper Award Winnerに選ばれた優れた論文です。 ちなみに今年のUSENIX Securityは、28回目、サンタクララで開催され、何年ぶりかに日本人がファーストオーサの論文が採択されるなど話題になりました。 ラテラルフィッシングの実態は？ Detecting and Characterizing Lateral Phishing at Scale[1] と題して、92組織の113Million(1.13億）ユーザのOffilce 365のメールを解析したところ、7つのうち1つの組織で「ラテラルフィッシング」が行われている実態が明らかにされました。92組織は、16業界からなり、多いものから、Real-estate, Technology, Education, Industrials, Healthで、データセットは十分な規模であると思われます。 実際、Office365への不正アクセスは各社SOCでも多く検出して、インシデント対応をしているということで、同様に信頼性が高いデータセットと言えます。 また、「ラテラルフィッシング」では、標的型攻撃で用いられる、標的を調査し、巧妙なメールを用いるケースは、全体の7%にすぎず、93%は、このドキュメントを見ておいて、このリンクをクリックして等、シンプルなものですが、信ぴょう性を高めるため、あのメール見てくれた？等催促したりと応答をすることも特徴です。 検知手法は？ このようなメールを特定するのは、シンプルな機械学習で誤検知を少なく検知できるという内容です。特徴量としては以下の3つを使います。 Lure：メール内にphishyな単語を入れているか Exploit：メール内にレアな（通常ではないような）URLを入れているか Targeting：標的型のような特殊な偽装をしているか 実際に「ラテラルフィッシング」が起きた110インシデントのうち、同手法で実験を行ったところ、106インシデントを検知できたとのこと。110インシデントのうち49インシデントは、ユーザから報告が上がってこなかったもので、これを見つけられたのは実務的にも非常に効果が高いと言えます。またFalse Positiveは0.0004%と非常に低いという凄さです。 もちろん、セキュリティ業界はいたちごっこな点は否めないので、永続的にこの手法で検知できるという保証はありません。 まとめ まだ、情報が少ない、「ラテラルフィッシング」(Lateral Phishing)について紹介させていただきました。データセットでは、16業界をカバーしていたのですが、どの業界でこの攻撃が多いか等の情報はありませんでした。おそらく学術界の発表は、倫理問題も最近は気にする必要が背景にはあるからかもしれません。この点については、コマース界のBarracuda Networksが今後発表をすることも予想されます。また日本で「ラテラルフィッシング」が起きているのかについても、情報公開の限界もあり、なかなか実態がわからないのが現状です。 また、今回の論文発表は、Office365の大規模データから分析をしているということで、Office365のセキュリティ対策やインシデントへの備えも重要と言えます。 この論文がAwardを取ることができた背景には、4大メジャー大会の中でも特に、理論の完成度に加えてフィージビリティも重視する、USENIX Securityならではと思います。 92組織から1.13億のメールを入手するには、研究者だけの力ではなかなかできないので、企業とのコラボが必須になります。今回はUC BerkeleyとBarracuda Networksの産学連携ですが、USENIX Securityからは、この連携により優れた技術が生まれ、スピンオフしたセキュリティ系ベンチャー企業も多くあります。 学術系カンファレンスは集客力の高い商業系カンファレンス（例 Blackhat）と比べると、数%の集客規模ですが、また一味違う興味深さがあります。USENIX Security自体についても、機会がありましたら、紹介させていただきたいと思います。 参考文献 [1] Grant Ho and Asaf Cidon and Lior Gavish and Marco Schweighauser and Vern Paxson and Stefan Savage and Geoffrey M. Voelker and David Wagner. Detecting and Characterizing Lateral Phishing at Scale. In Proc. of 28th Usenix Security, 2019. https://www.usenix.org/system/files/sec19-ho.pdf

こんにちは、 NTT国際通信株式会社 ICTインフラサービス部 クラウドサービス部門の北澤です。先日NTTグループの国内事業再編に伴い、NTTコミュニケーションズ株式会社 クラウドサービス部 から所属が変更になりました。 先日新会社になってすぐに、チーム内にて Kubernetes 1day 勉強会を実施しました。今回はその様子をお伝えします。 背景 私たちのチームは SREs (Site Reliability Engineers) として GKE (Google Kubernetes Engine) を運用しています。また週に1度、 Kubernetes に関する勉強会を実施することで自分たちの扱う技術に関する知識を深めています。 しかしながら GKE はマネージド Kubernetes サービスであるために Kubernetes クラスタを利用者としてしか使用できません。そのため、 Kubernetes が Pod をどのように立ち上げているか、そのステートをどのように管理しているかなどの仕組みの部分を実感する機会がありませんでした。 この度、チーム全体における Kubernetes の理解を深める事を目的として、Kubernetes クラスタを 1 から手動で構築する勉強会を開催しました。 実施内容 今回の勉強会では、事前に Kubernetes 構築用のドキュメントを用意し、当日は GCE (Google Compute Engine) 上の VM にログインしドキュメントを読みながら構築作業を行う方式をとりました。 今回構築した構成は以下のようになります。 Kubernetes を 1 から手動で構築する手順として、 kubernetes-the-hard-way が有名ですが、今回は各コンポーネントの仕事をきちんと理解してもらうことを目的に、Kubernetes の各コンポーネントにどのようなオプションを指定するか調べながら構築してもらうような構築手順を新しく作成しました。 以下に勉強会の流れの一例として kube-apiserver のみ構築後の話をします。Kubernetes は各コンポーネントが http(s) で kube-apiserver というコンポーネントと通信を行うことで動作します。そのため、kube-apiserver だけあればクライアント (kubectl) からの通信を受けることが可能です。しかしながら kube-apiserver のみ構築した状態で kubectl get node コマンドを実行しても No resources found. といった Kubernetes クラスタ内に Pod を建てる対象の Node が存在しないという意味のメッセージが返ってきます。Kubernetes の Pod として動作するコンテナは kubelet というコンポーネント経由でコンテナランタイムが立ち上げます。そのため次に kubelet とコンテナランタイムである Docker を構築することで、 kubectl get node で Node が取得できるようになることを確認できます。 このように各コンポーネントの構築後に Kubernetes の動作を都度確認することで、各コンポーネントがなぜ必要なのかを意識しながら Kubernetes の動きを理解してもらうことを狙いました。 実施風景 勉強会開始直後、 Kubernetes の各コンポーネントがどのように動作するかという説明を行い、その後はひたすら構築作業を行ってもらいました。 また、作業の進捗は Slack のリアクション機能を用い確認しました。これをみて構築に手詰まってる人などのフォローを頻繁に行うことができました。 昼食の :sushi: と :pizza: まとめ 今回の勉強会にて実際に Kubernetes クラスタを構築することで Kubernetes の理解を深められたのではないかと思います。また、開催側としても事前の構築検証や当日の質問を通じて学ぶことがたくさんありました。 以降も機会があれば勉強会等を実施し、 Kubernetes に関する技術力の底上げやコミュニティの活発化に貢献ができればと思っています。 なお、勉強会にて使用したリポジトリは GitHubで公開 しています。 Kubernetes 構築用のドキュメントや動作確認用のマニフェストファイルの他に GCP 上に勉強会の環境を構築するためのスクリプトもおいてあるので、Kubernetes の構築を 1 からやってみようと思っている方に参考程度になれば幸いです。

こんにちは、 SkyWay の開発・運用をしている岩瀬（ @iwashi86 ）です。 今回の記事では、弊社の研修内容の一部を公開します。 研修の狙い 毎年200名超の社員がNTTコミュニケーションズグループに入社しています。 入社いただいた社員の中には、もともと高い技術力を持っている社員も多くいます。 今年度より、ソフトウェアエンジニアリングのスキルの高い社員（今回は35名）を対象として新たな研修 1 を実施しています。 研修の主な狙いは以下の2つです。 即戦力レベルのスキル習得 実際の現場で有用となる技術・開発スキルの習得して、現場ですぐに活躍できるように ネットワーキングの強化 / コミュニティ形成 同期だけでなく、講師・メンタを含む先輩エンジニアとのネットワークを形成し、互いに影響を与え合い成長できるように なお、2点目について補足すると、今回の研修では社外のエキスパートによるプログラムに加えて、開発の最前線に立つエンジニアが講師を担っています。 最前線に立つエンジニアだからこそ、実務で使われる技術が分かっており価値がある研修を提供できると考えているためです。 先輩エンジニアと触れ合うことによって、もしかしたら新入社員自身のロールモデルも見つかるかもしれません。 プログラム全体像 本研修は5日間で構成されており、概要は以下の通りです Day1: テスト駆動開発ワークショップ Day2: アジャイル開発、スクラムワークショップ Day3: IaaS、カオスエンジニアリング、障害注入型ISUCON Day4: CaaS、docker、kubernetes、GKE Day5: FaaS、AWS lambda、Serverless framework Day1-2は社外のエキスパートの力を借りて、Day3-5は社内のエンジニアが講師・メンタを担当しています。 各日程の概要・資料 以下で簡単に各日程の内容を紹介します。 Day1: テスト駆動開発ワークショップ 和田さん にご協力いただき、テスト駆動開発のワークショップを実施いたしました。 研修資料へのリンク ]( https://speakerdeck.com/twada/tdd-live-and-workshop-2019-spring ) Day2: アジャイル開発、スクラムワークショップ アトラクタ社の 永瀬さん 、 吉羽さん にご協力いただいて、アジャイル開発およびスクラムのワークショップを実施いたしました。 (こちらは資料公開無し) Day3: IaaS、カオスエンジニアリング、障害注入型ISUCON Day3以降は社内のエンジニアが講師・メンタを担当しています。IaaSは本記事執筆者の岩瀬が担当しています。研修資料は以下のとおりです。 2019年度 IaaS ワークショップ @ NTTコム from Yoshimasa Iwase なお、以下の研修現場画像を見ていただければピンと来るかもしれませんが、IaaSでは ISUCON を参考にしています。 ただ、ISUCONとは1点だけ大きな違いがあり、それは ベンチマーク実行中に障害(VMがランダムで1台再起動)が恣意的に引き起こされる という点です。 現実のサービス開発・運用では、予期せぬ事象によってあるVMがサービス提供できなくなることは想定されます。 そこで、クラウドの特性を活かした構成にすることによって、サービスを継続して提供するという内容にしてあります。 なお、ISUCON定番の茶番（？）的な前振りも実習開始前にしています 2019年度 IaaS 実習イントロダクション @ NTTコム from Yoshimasa Iwase Day4: CaaS、docker、kubernetes、GKE CaaSコースでは、Day3で実施したWebアプリと同様のシステムを、コンテナを利用して組み上げていく内容になっています。研修資料は以下のとおりです。 2019年度 CaaS ワークショップ @ NTTコム from TomoyaTakegoshi Day5: FaaS、AWS lambda、Serverless framework FaaSコースでは、Day3-4と同様の仕様をAWS Lambda + Dynamo DBを使って組み上げる内容となっています。研修資料は以下のとおりです。 FaaS研修資料へのリンク ]( https://gitpitch.com/nttcom/2019-sw-training?p=faas/presentation#/ ) IaaS/CaaS/FaaSのソースコード Day3-5の研修で使っていたソースコードは GitHubで公開 しています。 まとめ 本記事では、NTTコミュニケーションズグループで実施している研修の一部(ソフトウェアエンジニア向けコース)を公開いたしました。NTTコミュニケーションズでは、今後もソフトウェアエンジニアの育成に力を入れていきます！ 参考: ソフトウェア以外にも、たとえばネットワークエンジニア向け研修なども実施 ↩

こんにちは、 SkyWay のエンジニアの岩瀬( @iwashi86 )です。 NTTコミュニケーションズに新しい拠点が完成しました。名前は Lean Agile Base (略して LAB) と言います。 本記事では、 LABの概要・狙い どうやって作り上げていったのか？ の2点を紹介いたします。 概要 まずはどんな感じか見ていただくのが早いので、いくつか新オフィスの写真を載せておきます。 複数人でモブプログラミングする場合は、全員が同一方向を見て作業できると身体的負荷が軽減され、快適に作業できます。そこで、ソファで囲むようにして作業できる環境を用意しています。 モブプログラミングだけではなく、ペアプロ/ペアワークに便利なデスクも配置しています。このデスクは、高さが電動で変更できるため、座って作業するだけでなく、スタンディングでの作業も可能です。 打ち合わせをする場合や、チームで固まって作業が必要な場合に作業できるスペースも用意しています。 また、作業内容によっては、一人で集中したいこともあります。そのためのスペースとして高い仕切りが併設されたデスクも用意してあります。 気軽にリフレッシュできるスペースもあります。例のソファも置いてあるので、そのままの姿勢で仕事モードに入ってしまうことも。 狙い このオフィスを作った狙いとして、主に次の2点があります。 組織を横断した、エンジニア同士 1 のコミュニケーションを促進したい リーン、アジャイルに試行錯誤するプロダクトを増やしたい 弊社には多くの組織があり、どうしても組織と組織をまたぐとコミュニケーションが減ることがあります。一方で、組織やチームが違ったとしても、同じような技術エリアに取りくんでいるケースも多くあります。会社・組織として全体のスキルを高めていくためには、雑談から生まれるようなノウハウの共有が効果的です。もちろん、Slackなどのオンラインコミュニケーションも併用していますが、Face to Faceでの情報帯域に勝るものはありません。そこで、LABではコミュニケーションが生まれやすい場を提供しています。 また、プロダクトやサービスの成功率をあげるために、様々なフィードバックをもとにした試行錯誤が効果的です。新オフィスの名称として、 Lean Agile Baseをつけたように、 Leanに & Agileに に挑戦していくプロダクトやサービスのメンバが集まる場を狙っています。 どうやって作っていったのか？ 実際のオフィス設計は、 ヒトカラメディア 様にご協力いただきました。 弊社から要件を端的に伝えてオフィスを設計してもらうのではなく、複数回のワークショップを経て、「どのような働き方をしたいのか？」「どのような想いがあるのか？」「どうやったらチームの開発の腕があがるのか？」といった、より根源に近い要求からオフィスを設計していただいています。 実際のワークショップの様子を以下に何枚か貼っておきます。 皆でブレストして、 イメージを具体化し ドット投票しつつ重要な点を絞り込んでいきます。 また、オフィス構築終盤では、一部DIYして仕上げをしていきました。 本オフィスは、常にWork In Progressの状態だと考えており、今後も必要に応じて常に改善していきたいと考えています。 まとめ 本記事では、NTTコミュニケーションズの新オフィスであるLABを紹介しました。気軽に遊びにきてください！ わかりやすくエンジニア同士としていますが、エンジニア以外も本オフィスは利用していきます。たとえば、プロダクトマネージャ、デザイナなど。 ↩

ネットワークサービス部 初開発合宿開催！！ こんにちは。ネットワークサービス部テクノロジー部門の嶋です。そろそろ暖かくなってきた先月、2月25～2月27日にかけて、ネットワークサービス部テクノロジー部門のエンジニアが集まって、伊東温泉（静岡県）で開発合宿を行いました。今回はその様子をお伝えします。 開発合宿を行ったきっかけ 先日、ComCTFが開催されました。ComCTFとは、NTT Com内で実施しているセキュリティに関するテクニックを競い合うコンテストのことです。そのとき、「惜しくも予選突破できなくて悔しい」という意見や、「本選で実力不足を感じた」など、さまざまな意見がありました。また、「まとまって勉強できる時間がなかなか確保できず厳しい」という意見もあり、「どこかで勉強できたらいいよね」ということになって開発合宿を計画しはじめ、その後、合宿に参加する有志7人が集まり、“開発合宿にオススメ！旅館5選”に選ばれている山喜旅館にて2泊3日で内製開発強化を目的とした開発合宿を開催することになりました。開催するにあたって協力していただいた皆さま、ありがとうございました。 開発合宿中の様子について 合宿は以下のスケジュールで進みました。 1日目 o 朝: 各自電車移動 (新幹線 or 踊り子) o 10：00 山喜旅館ロビー集合 → 環境準備 o 11：00 開会宣言、 自己紹、 やること宣言 2日目　自由開発時間 3日目 o 12：00 チェックアウト後、会議室へ移動 o 14：30～16：00 LT的に成果報告 o 17：00 会議室 撤収 個人的な感想も含みますが、合宿期間中は本当に自由に開発することができました。集中力がなくなったら目の前が海ということもあり、散歩や漁港に泳いでいる魚を眺めに行くことができました。開発場所としてきれいな会議室が確保されていて、そこで開発してもいいし、旅館の部屋で開発してもいい、としてあったのでストレスフリーで作業することができました。また温泉地ということもあり、夜は温泉など、リラックスできるものがたくさんあったので、楽しみながら開発することができました。 開発ネタについて 今回の開発合宿では各自が自分で持ってきたネタを実装する形式をとりました。何人かのネタをここでご紹介したいと思います。 Batfish + inet-hengeでconfigテスト + トポ図自動生成 ansible nw module, gitlab でCICD化 SOプログラムのpython置き換え 100万pps送信する自作ツールに再チャレンジ これらは1部ですが、さすがネットワークサービス部ということでネットワーク周りのプログラミングが多かったように感じます。 またopenstackなので仮想基盤系のネタもあり、クラウド系のネタに挑戦するメンバーも多くいました。またお互いに不足している知識や経験を補い合うような場面もあり、討論が盛り上がる場面も多々、見られました。 最終発表に使った資料の一部をご紹介します。 →　 https://gitpitch.com/take4mats/201902techcamp#/ 合宿形式の有用性について 開発合宿という、普段とは異なった環境で開発するのは普段、オフィスで働くのと、どう違うのか？について、全員の感想をご覧いただきながら解説します。 　＜全員に聞いた感想＞ ・やる気のある人が集まって取り組むだけで、完成までのモチベーションが持続する ・途中、アイデアや実装に詰まっても他の人の意見をもらえ、解決の糸口になることもある ・事務作業にほとんど触れず、プログラミングだけに集中できる ・もくもくやる人が目の前に集まっているだけでやる気が持続する ・もくもくやる一方で、たまに独り言からの会話が解決につながることがあり、とても良かった ・改まった質問と独り言ではハードルがぜんぜん違う ・しゃべると頭が整理される（1人で考え込むより良い） ・余計な interrupt がないのにはすごく感謝（特に自分は普段ひどいため） ・寝食をともにしていると、作業時間以外での会話も良い影響になる（ナレッジ共有、アイデア議論、親睦） ・リモートワークは2日までに制限されているが、1つのPoCを集中して仕上げるには3日間の合宿が適切だと思った ・慣れない分野で1つの成果を生み出すために断続的に計3日間リモートワークとるより、合宿で3日間連続して取り組む方が効率が良いと実感 意見として多かったのは、質問のハードルの低さや目の前で頑張っている人がいるだけでもう少し頑張ろうと思える、ということです。あとはモチベーションについての意見も多く、普段の環境よりもモチベーションの持続性が全然違うと口をそろえて言っていました。エンジニアリングにおいて、モチベーションの維持というのは結構重要な位置を占めるものです。開発合宿というのはそのための新たな働き方の1つになるのではないでしょうか？ もう1つ大事だと感じたのは、テーマ選定や事前の環境準備です。事前に参加者同士で集まってテーマ候補を話し合うようにしましたが、そのテーマにどんなアプローチで取り組むか、いくつかの案を練っておくことも重要です。 せっかくの機会なので、無策で臨んで成果ゼロ……というようなことにはないように準備が大切です。決められた短期間でアウトプットを出す訓練としても有用だと思います。 今後の開発合宿について 今後も継続的、定期的に開発合宿が開催できるように努力していきたいと考えています。 最後に伊東温泉での美味しかったご飯（伊東温泉名物「うずわめし」）と旅館の部屋をご紹介して終わります。