イノベーションセンターの小林です。普段は、ある日は部内情シス、ある日は情報セキュリティオペレーションをやっています。以前の開発者ブログに寄稿したこともあり、今回の開発者ブログリニューアルにもかかわりました。 今回のリニューアルにあたっては、各記事に対する社内レビューと記事公開のプロセスを「いい感じ」にしたいよねとの声があり、現時点ではそれなりに満足いくものを作れました。その中身を少しご紹介します。 レビュー 以前の開発者ブログの頃から、寄稿された記事は有志によるレビューを通してから公開するようにしていました。主に見ていたのは文法的な間違いがないか、NTT Comの統一表現を使っているか、明らかな事実誤認や錯誤がないか、といったポイントです。このレビューの仕組み自体は、リニューアルにかかわった面々とのディスカッションを踏まえて、今回のリニューアル後も引き続き行うことにしました。 かつてのレビューは、Google DocsやWordなどで寄稿者がまとめた原稿に、レビュワーがコメントをつけて寄稿者に戻し、寄稿者が内容を修正した後ブログプラットフォームへ投稿する流れになっていました。このプロセス自体は一応動くには動くものの、開発者ブログの中身としてはあまり「いい感じ」の状態ではないね、との話はずいぶん前からありました。 どうしたか 今回のリニューアルに際し、次のような仕組みを作りました（説明のため一部割愛しているところがあります）。 簡単な流れはこうです。 寄稿者にはMarkdown形式で原稿を書いてもらい、画像（あれば）とともにGitHubにコミットします。そのコミットをpull requestにしてもらいます（図中の1）。 レビュワーは従来通り内容をチェックし、問題なければマージします（図中の2）。 マージをきっかけにGitHub Actionsによるデリバリプロセスがスタートし、原稿と画像を読み込んでブログプラットフォームのAPI経由で記事を送信、最終的に公開される仕組みです（図中の3と4）。 図中では表現していませんが、1でpull requestをオープンした時点でもGitHub Actionsが起動し、Linterによる文法・表現のチェックを行うようにもしました。記事が長いと見落としがちな表記揺れにも気づきやすくなります。 得られたこと GitHubのpull request機能に備わっているコメント機能（ソースコードの行を指定してコメントがつけられる）を使えるようになったこと、また変更前後の差分をすぐ引き出せるようになったことが大きいです。Google Docsでも任意の箇所にコメントをつけたり、修正を提案する機能もありますが、解決済みとしたコメントや修正を受け入れた箇所を後から探すことには困難が伴います。 また、ブログプラットフォーム本体の、投稿権限を持つユーザーをいたずらに増やさなくて済む点も挙げられます。投稿したい人はGitHubへのアクセスさえあればよく、プラットフォーム側のユーザー管理にかかる手間が削減できます。寄稿者にしてみても、エンジニアにとっては使い慣れた道具であるGitHubでライティングができることは、新たな学習コストをかける手間が省けます。 今後 GitHubとGitHub Actionsを中心としたエコシステムでは、まだいろいろできることがありそうです。 画像の適切なリサイズ、記事サムネイルの生成など画像に関する処理 表現チェックの自動化（textlintを使うなど） 社内Slackに新着投稿の通知を出して、コミュニティを盛り上げる……などなど 寄稿者、レビュワーほか開発者ブログにかかわる人にとって「いい感じ」のプラットフォームにしていければいいなとも思います。 もちろん読者の皆様にもメリットがある話だと思っています。「簡単に書ける」ことがNTT Com内に知れ渡れば、きっと隠れた寄稿者がどんどん出てきて、皆様にもどんどん新しい記事をお届けできる、はず。 今後の開発者ブログのコンテンツにもご期待ください！

こんにちは、イノベーションセンターの前田です。今回は、私のチームで取り組んでいる、制御（Operational Technology: OT）システムネットワークのセキュリティとその対策技術についてご紹介します。 本記事は前編と後編の2部構成となっており、 前編では、OTネットワークの概要やOTのセキュリティ対策・課題等の背景情報と、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの概要とネットワーク可視化機能 後編では、OsecTの脅威検知機能 について、それぞれご紹介します。 OTネットワークとは OTネットワーク（ICS: Industrial Control System ネットワークのように呼ばれることもあります）とは、ビル、工場、プラントなどの制御システムの管理・制御に利用されるネットワークです。 制御システムでは、従来、独自のOS・通信プロトコルが利用され、オフィス等の他のITネットワークから分離された閉域ネットワークとして構築されていたこともあり、セキュリティを意識した設計になっていませんでした。しかし、近年では、汎用OSへの対応、通信プロトコルの標準化やIP化が進められていることや、生産性・利便性の向上のためのスマート化に伴い、外部ネットワーク（オフィスITネットワーク・クラウド等）への接続が進められていることで、セキュリティリスクにさらされる危険性も増加してきています。 OTネットワークのセキュリティ対策と課題 OTネットワークとITネットワークでは、以下の図のように、セキュリティ対策の考え方に違いがあります。 ITのセキュリティではデータの機密性が重視されますが、OTのセキュリティではシステム停止時の事業や社会への影響が大きいため、機密性よりも可用性が重視されます。また、OTのシステムはライフサイクルが長く、サポート切れのOSを利用しているケースも多くありますが、基本的なセキュリティ対策である、OSの最新化やセキュリティパッチの適用などは、可用性を損なう危険性があるため、一般的には実施が困難です。 さらに、上の図の理想の絵のように、OT関連のセキュリティガイドラインでは、ITやOTなどのネットワークを機能階層毎に分離（セグメンテーション）してその境界を保護することが求められていますが、現実の絵のように、OTとITのネットワーク領域が混在していたり、セキュリティの監視ポイントが曖昧なまま運用されていたり、そもそもOTの資産を十分に把握できていなかったりするケースも多くあります。OTとITでは管理組織が異なり、セキュリティに対する意識も異なるため、ITの考え方で、OT側のセキュリティ対策を進めるのは容易ではありません。 （蛇足になりますが、OTのネットワークは、ITにあまり詳しくない方が設計されている場合もあり、過去の分析では、RFC1918で規定されたIPv4のプライベートアドレス帯(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)以外のアドレスをプライベートアドレスとして利用しているケースに遭遇したこともあります） OTセキュリティ対策技術 OsecT OTのセキュリティ脅威の高まりを受けて、NTT Comでは、OTのセキュリティ対策のための技術であるOsecT（オーセクト）を開発しています。 OsecTには、 守るべき資産や通信の可視化を行うネットワーク可視化機能 と、 不正に接続された端末やサポート切れのOSを利用する端末等を検出した際のアラート機能（脅威検知機能） の2つの機能があります。 また、既存の制御システムの可用性に影響を与えないように、次のような作りにしています。 NIDS(Network Intrusion Detection System)型で、エンドポイントへの対策ツールの導入が不要 既存スイッチ等でのパケットのミラーリング、または既存のpcapファイルを読み込ませることでネットワーク可視化と脅威検知を実施 ミラーリングも困難な場合は、ブロードキャスト通信のみで、限定的なネットワーク可視化・脅威検知を実施 パッシブな解析のみを実施（ネットワークに検査のための通信を流さない） OsecTは、リアルタイムのトラヒックデータを元にセキュリティアラートを監視する使い方とオフラインのトラヒックデータを元に定期アセスメント等で利用する使い方の両方に対応しています。 以降では、OsecTのネットワーク可視化機能の詳細について、開発の工夫点などを交えながらご紹介します。（なお、脅威検知機能は、後編の記事でご紹介します） ※OsecTは現在開発中の技術であり、正式リリース時には仕様・画面イメージが変わる可能性が大いにあります。 ネットワーク可視化機能 OTでは、守るべき資産や流れている通信を十分に把握できていないことが多々あり、このような場合に有用なのがネットワーク可視化機能になります。 資産台帳の自動生成 パケットから取得した情報を元に、こちらのような端末一覧を作成できます。 こちらは、IPv4/v6アドレス、MACアドレス、MAC Vendor、Service(プロトコルとポート番号)、Host Name、OS、通信が最初に観測された時刻、通信が最後に観測された時刻などの情報で構成されています。守るべき資産の把握や資産台帳の最新化に役立つ他、台帳に記載のない不審な端末やサポート切れOSを利用している疑いのある端末、ごく短期間のみ通信が観測された端末などの洗い出しにも利用できます。 OTの資産の可視化が可能ないくつかの製品では、MACアドレスとHost Nameを元に、資産の一覧を生成していますが、組み込み系機器では、Host Nameにデフォルトで機種情報などが格納されていることが多く、資産を正確に一覧化できなくなるため、OsecTでは、MACアドレス情報をメインで利用して資産の一覧を作成しています。また、こちらで可視化している情報の内、特に、OS情報では、 p0f といった既存のフィンガープリンティング技術を利用しつつ、複数のメトリックによる推定技術を適切に組み合わせることで、OS推定精度を向上させています。 IPアドレス情報の表示機能 こちらでは、IPアドレスの一覧情報や特定のIPアドレスの通信先一覧等を表示できます。 マトリックス表示機能 MAC Vendor、OS、端末の役割（client / server / 両方の性質を持つもの）を色分けして、縦16x横16のマトリックス形式（/24セグメント単位）で表⽰することで、多数の端末から構成されるOTネットワークを俯瞰的に見ることができます。 こちらは、MAC Vendor情報に基づくマトリックスになります。画面右側にMAC Vendor情報と色の対応を表示しています。また、マトリックスの特定の数字にカーソルを合わせることで、対応するMAC Vendor情報がホバーとしても表示されます。 こちらは、OS情報に基づくマトリックスになります。画面構成等はMAC Vendorと同様です。 こちらは、端末の役割に基づくマトリックスになります。画面構成等はMAC Vendorと同様です。 マトリックス表示機能によって、例えば、サポート切れのOSが多いネットワークセグメント等を視認しやすくなるため、対策・監視などを導入する箇所の検討に利用できます。また、ネットワークセグメント毎のIPアドレスの割り当てルールを視認しやすくなるため、想定しないIPアドレスを使っている疑わしい端末の発見にも利用できます。 ネットワークマップの作成 OsecTでは、資産（端末）の可視化だけでなく、端末間でやり取りされる通信も可視化できます。 こちらの機能では、注目すべきネットワーク構造や端末を抽出しやすくするための工夫として、次のようなことを行っています。 直接通信するIPアドレス同士を近くに配置し、直接通信していないIPアドレスを遠くに配置 各IPの役割（client、server、両方の性質を持つもの）を推定し、役割別に異なる色で表示 通信が集中しているIPアドレスを大きく表示 これにより、通信特性が似ているグループやグループ間の通信などが分かりやすくなり、各種ガイドラインで求められている、適切なネットワークセグメンテーションの検討やアクセス制御の検討に繋げることができます。また、管理者の方が想定していない端末間で通信が発生していないかを確認することで、グループ間を橋渡しするような攻撃経路の発見や、不正な通信を行う端末の発見などにも利用できます。 重要度/特異度の高い端末の可視化機能 ネットワークの中で重要な/特異性のある端末を可視化することで、多数の端末が存在するOTネットワークにおいて、優先的に対処すべき端末を抽出できます。 こちらでは、次数中心性(通信先の数が多いほど大きい値になる指標)と媒介中心性（通信を仲介している数が多いほど大きい値になる指標）の2つの軸に基づき、前述のマップを数学的なグラフとして解析することで、定量的に重要な端末や構造を理解できるようにしています。 次数中心性と媒介中心性が大きい端末ほど、ネットワークの中心に位置し、重要度の高い端末になります。OsecTでは、原点からの距離（distance）として定量化しています。 また、通常では、次数中心性と媒介中心性は比例することが多いですが、どちらか一方のみが大きい場合は、ネットワークの中で特徴的な役割を担っている可能性があるため、こちらも優先的に確認すべき端末になります。OsecTでは、次数中心性と媒介中心性のどちらかが大きい度合いを特異度（Specificity）という指標で定量化しています。 ランキング表示 MAC Vendor、ホスト毎のトラヒック量、サービス毎のトラヒック量などをランキング表示できます。こちらは、ネットワークの特徴や全体傾向を把握するのに役立ちます。 こちらは、MAC Vendor情報のランキングになります。全体傾向の把握のほか、利用していないベンダの端末が存在しないかの確認にも利用できます。 こちらは、通信量が多い端末のランキングになります。 こちらは、通信相手の数が多い端末のランキングになります。 こちらは、通信量が多い通信サービスのランキングになります。第2位のBACnetは、ビルのオートメーション・制御に利用されるOTプロトコルです。また、OTの独自サービスのプロトコルの中には、一般的な通信サービスの振る舞いとは異なり、送信元ポート番号が固定値で、宛先ポート番号がランダム or 範囲の値を取るものがあります。OsecTには、こうしたサービスを自動判別する仕組みがあり、第3位の(15100/udp/srcport_aggregated) は、送信元ポート番号が15100/udpであり、宛先ポート番号が発散しているサービスであることを意味しています。 こちらは、利用しているホスト数の多い通信サービスのランキングになります。 通信量の時系列表示 通信量(bps/pps)を時系列で表示できます。 こちらの機能を利用することで、通信量の傾向を把握したり、通常の通信量から逸脱する異常な通信量の増加などを発見できます。画像の例では、8/20頃に急激な通信の増加が発生していることが確認できます。 差分分析表示 任意の2つの期間を指定して、資産情報の変化や通信状況の変化などを比較できます。定期的にセキュリティアセスメントを実施する場合などに、前回のアセスメント時と比較して、各種情報がどのように変化したかを確認するのに便利な機能となっています。 資産台帳の差分分析は、次のようになります。 こちらでは、2つの期間で追加された資産（端末）は、addとして赤色で表示され、削除された端末はdelとして青色で表示されます。また、既存の端末において、利用するサービス情報（通信プロトコルや宛先ポート番号）が変化した場合には、chgとして黄色で表示されます。 マトリックス情報（MAC Vendor）の差分分析は、次のようになります。 こちらでは、2つの期間で変化のあったネットワークセグメントは黄色の枠で表示されます。例では、10.1.2.0/24のセグメントにおいて、.106のIPアドレスを利用していた端末が消失しています。 ネットワークマップの差分分析は、次のようになります。 こちらでは、2つの期間で追加されたIPアドレスを濃い緑の枠で囲んで表示しており、消失したIPアドレスを青色の枠で囲んで表示しています。こちらの例では、左上辺りに存在している、10.1.2.105、10.1.2.106、10.1.2.107のグループが2つの期間の前後で消失していることが分かります。 名前解決通信に基づく可視化 DNSなどの名前解決通信による可視化ができ、業務上不要なサイトへアクセスする端末やファイル共有サービスなどのセキュリティインシデントにつながる可能性のあるサービスを利用する端末を特定できます。 ブロードキャスト通信に基づく可視化 既存のスイッチ等へのミラーリングの設定が困難な環境向けに、可視化できる内容は限定的なものにはなりますが、ARPなどのブロードキャスト通信のみを用いたネットワーク可視化機能も作成しています。こちらは、既存スイッチのデータプレーン（データ通信用のネットワークセグメント）に余っているポートがあれば、そちらにOsecTを接続することで、流れてきたブロードキャストのパケットをOsecTがキャプチャして可視化するイメージになっています。 最後に 今回は、OTネットワークの概要、OTのセキュリティ対策とその課題に関するお話と、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの概要とネットワーク可視化機能についてご紹介しました。工場等のスマート化を推進していく上では、これまであまり検討が進められていなかった、OTのセキュリティ対策を考えることが非常に重要になってきます。 後編では、OsecTの脅威検知機能についてご紹介します。よろしければ、そちらもご覧ください。 ※2021年6月現在、OsecTの実証実験のトライアル利用者様を募集しております。無償でご利用頂けますので、国内に制御システムをお持ちの製造業・インフラ事業者の方で実際にお試ししたいという方がいらっしゃいましたら、是非 こちら からご応募頂けますと幸いです。

データプラットフォームサービス部の花川です。 普段はSDPFのメニュー開発をしていたり、社内のイベントとかに趣味で首を突っ込んでいます。 最近では Software Design 7月号のISUCON特集に社内メンバーと寄稿したりしました。 NTTコミュニケーションズの開発者ブログはこのたび NTT Communications Engineers' Blog としてリニューアルしました。 今日は「開発者ブログ」を「Engineers' Blog」としてリニューアルするきっかけについてのお話です。 開発者ブログのこれまで もともとdeveloper.ntt.comで運営されていた開発者ブログは、2015年6月頃に開始されました。 最初の記事は "開発者ブログはじめました" でした。 当時はNTT ComでAPIゲートウェイを提供し始めた頃であり、実はこの開発者ブログは弊社のAPIドキュメントやチュートリアルをまとめたサイト（NTTコミュニケーションズ デベロッパーポータル）の中のいちコンテンツとして産声を上げています。 engineers.ntt.com （2023/11/07追記：この記事の当初公開時点では、developer.ntt.comにホストされていた記事へのリンクとしていました。そのコンテンツはすべてこのブログに移転してありますので、リンク先をこのブログに張り替えてあります。以下の記事も同様です） 主なブログの役割は "APIを探そう。国内外のインデックスサービスまとめ" など、世間でのAPIの活用事例など、啓蒙としての技術詳解がメインコンテンツでした。 engineers.ntt.com 2018年1月頃から、社外イベントでの登壇の報告や、社内での勉強会紹介を記事として公開しはじめました。 それ以降、多くのエンジニアがイベント紹介や技術の解説などで寄稿をしています。 中の人目線ですが、今見ると懐かしい気持ちになるものも多いですね。 engineers.ntt.com engineers.ntt.com ありがたいことに、多くの方々に記事を見ていただけており、はてなブックマーク経由でコメントが寄せられるなどしております。 ここがつらいよ開発者ブログ さて、多くのエンジニアが寄稿し始めた開発者ブログですが、運営をしているといくつか厳しいポイントも出てきました。 開発者ブログのプラットフォームが使いづらい 前述したように、開発者ブログは弊社のAPIゲートウェイ/デベロッパーポータルというサイトのいちコンテンツという立ち位置でした。 そのため、開発者ブログの記事とデベロッパーポータルの記事は1つのCMSで管理されており、ブログ記事の執筆には大きすぎて使いづらいものでした。 また、いちコンテンツであるがゆえにデベロッパーポータルのデザインが適用されています。 「ドキュメントとして読みやすいサイト」が主な目的となっているため、開発者ブログに向いたデザインなどの適用が難しい状態となっていました。 執筆後のレビューがしづらい 2019年頃から、投稿時のルールとして、有志による相互レビューを実施しています。 これは、社内情報など出してないけないことのチェックもありますが、記事そのものをより良くすることが最大の目的です。 例えば、分かりづらい固有表現がないか、文章で読みづらい部分がないか、といった点が主なレビューポイントでした。 しかし、これまで使っていたブログのプラットフォームは下書き状態の記事は執筆者と管理者以外は閲覧できず、またレビューに使える機能もなかったため、記事のレビューがたいへんしづらかったのです。 このように、NTT Comのエンジニアが集うSlackに下書きを投稿しThreadにコメントを書くという方法でレビューをしています。 これがなかなか厳しく、定期的に「やりづらいよねえ」という話が上がっていました。 有志に負担が寄りすぎてしまう運営状況 これまで、NTT Com社内の多くのチームにおいて、記事の執筆やレビューは業務であると認められていませんでした。 そのため、社外へ情報発信する意義について理解があるチームから集まった、有志のメンバーが執筆もレビューも実施していました。 NTT Comには多くのエンジニアが存在しており、JANOGを始めとした外部での発表も多く行っています。 発表や雑誌への寄稿に対する認知・承認がある一方で、自社メディアである開発者ブログは社内の認知度が低く、エンジニア個人の意志で業務時間中に堂々と執筆に取り組むのは難しい状況でした。 新開発者ブログ、はじめます これらの問題を解決するために、デベロッパーポータルからブログだけを切りだした新開発者ブログ "NTT Communications Engineers' Blog" として再出発を切ることにしました。 詳細は今後の記事として公開する予定ですが、開発者ブログをリニューアルするにあたって、ざっくりとこんなことに取り組んで来ました。 社内デザインスタジオ KOELのメンバーの協力の下、デザインを作成 GitHubを活用したレビューと記事公開プロセスの設定と実装 社内のコミュニティ活動としてのブログ執筆やレビューの公認 記事の執筆やレビューの方針を書いたガイドブックの作成 ここまでして開発者ブログを整えるのには、大きな理由があります。 NTT Comという会社は、とても大きな会社です。 社外からは具体的になにをやってるのか分かりづらいとよく言われますが、社内にいても部署間での技術的な交流に乏しいと感じる場面も少なくありません。 しかし、社内には多くの"おもしろい"エンジニアや、技術的に高度な取り組みをしているチームが実は多くいます。 こういったエンジニアやチームが、社内だけではなく、社外に発信できる場として、このブログを整備しました。 このブログを閲覧してくれるみなさまが「へーNTT Comってこんなにおもしろいことやってるんだ〜」と思っていただければ、開発者ブログを整備したメンバーはうれしいかぎりです。 まとめ NTT Comで今までひっそりとやっていた開発者ブログをリニューアルしました。 今までイマイチだなと運用していた部分をきちんと整備し、社内のメンバーが情報発信しやすい環境をつくりました。 このリニューアルを通して、読者のみなさまが「NTT Comおもしろいことやってるじゃん」と思って頂けるような記事をどんどんと出していければと思っていますので、よろしくおねがいします! 余談ですが、すでに社内のエンジニアからいくつか記事が寄せられております。 今後の記事の更新も楽しみにしておいてください!

こんにちは、イノベーションセンターの志村です。 開発者ブログ 兼 NTTコミュニケーションズ Advent Calendar 2020 の2日目の記事です。 昨日はmahitoさんの記事、 日本企業でTGIFのような対話型イベントをやってる話 でした。 今回はThreat Intelligenceのツールである、MISPの概要とその使い方について紹介します。 この記事の要約 インテリジェンス活用のため、オープンソースのThreat Intelligence 共有プラットフォームのMISPが広く活用されている APIやモジュールによるインポート/エクスポートなど、自動化や外部連携をするための機能が充実している 「ブロックチェーン型セキュリティインテリジェンスプラットフォーム」では、MISPを活用したインテリジェンスの活用・共有を促進するプラットフォームとなっている Threat Intelligenceについて MISPの説明の前に、そもそもThreat Intelligence (セキュリティインテリジェンス、CTI: Cyber Threat Intelligence などとも呼ぶ) とは何か、についてお話しします。定義は様々ですが、かみ砕いて言ってしまえば「サイバー脅威の軽減に役立つ情報」であるといえます。 セキュリティ活動のためのThreat Intelligenceは、以下のような場面で活躍・活用できます 脆弱性マネジメント: 脆弱性の情報を収集し、パッチ対応の優先順位などを決定する セキュリティオペレーション: セキュリティアラートに関連する情報を使用し、アラートのトリアージ (対応の優先順位付け) を行う インシデントハンドリング: インシデントハンドリング中に発見されたIOC (Indicator of Compromise: 攻撃されたことを示すIPアドレスやハッシュ値などの証跡)をセキュリティインテリジェンスを用いて詳細に調査する セキュリティ意思決定: 自組織を狙う攻撃者グループの戦術、テクニック、攻撃手法 (TTPs) を収集し、不足している防御能力を把握して対処する Threat Intelligenceを活用することにより、事実に基づいたセキュリティ活動や意思決定を行うことが可能になります。 Threat Intelligenceの活用を促進するツールなどは多種ありますが、今回はその中でもオープンソースのThreat Intelligence のプラットフォームである、 MISP について紹介します MISPとは 引用: https://www.misp-project.org/features.html MISPは、Threat Intelligenceの蓄積・共有・関連づけを行うオープンソースソフトウェアです。MISPの開発はCIRCL (The Computer Incident Response Center Luxembourg: ルクセンブルグの民間部門・地方自治体・非政府組織向けのCERT) によって主導されており、機能の追加などが進められています。 MISPは公式サイトによれば「MISP - Open Source Threat Intelligence Platform & Open Standards For Threat Information Sharing」、つまりThreat Inteligenceのプラットフォームであり、またThreat Intelligence共有のオープン標準であるとされています。MISPを活用することで、Threat Intelligence を効率的に蓄積・共有し、Threat Intelligenceを活用したセキュリティオペレーションを実施することができます。 本ブログでは、MISPの利用方法や基本的な概念について紹介します。より詳細な情報などは、 MISP公式サイトの解説 、もしくは 公式サイトのトレーニング資料 やGithubの misp-training などが参考になります。 MISPを使うことで、以下のようなことが実現できます。 IOCの保存と検索 関連するインテリジェンスをイベントという形式で保存したり、保存してあるインテリジェンスを検索することができます 組織間でMISPインスタンスを接続し、インテリジェンスを共有する 自動的にMISP上の情報を共有することができます。共有していい情報とそうでない情報を区別することも可能です セキュリティアプライアンスで活用可能なデータ形式でのエクスポート suricataなど、セキュリティアプライアンスに投入可能な形式でインテリジェンスをエクスポートすることができます イベント間の相関分析 IPアドレスやドメイン名、ハッシュ値などが共通するイベントがあった場合、そのイベントと関連付けることができます。これによりアラート対応時に関連する情報を簡単に参照することなどが可能になります MISPの概要 MISPの基本的な構成単位などについて説明します。 Event MISPはEvent (イベント) という単位でインテリジェンスを管理します。 インシデント、マルウェア、インテリジェンスレポートなどを1つのイベントとして管理します。 イベントの例 Attribute 各イベントに紐づく具体的なIOC (IPアドレス、ドメインなど) などを保存する単位として、Attribute (アトリビュート) があります。 イベントとアトリビュートは1対多の関係になっており、1つのイベントに複数のアトリビュートが属する形になっています。 例として、あるインシデントを1つのイベントとして作成した場合、そのインシデントで発見されたIPアドレスやドメインなどをアトリビュートとしてイベント配下に作成します。 アトリビュートにはカテゴリーとタイプが存在します。例えば Network activity というカテゴリーには　 domain , ip-src , ip-dst などのタイプが存在します。 ユーザは適切なアトリビュートのカテゴリーとタイプを選択し、イベントに追加していきます。 アトリビュートの例 Object Object (オブジェクト) は、アトリビュートの組み合わせによって構成され、アトリビュート間の関連性を表すことができるものです。 例えば domain-ip というオブジェクトは domain , ip-dst , port などのアトリビュートを組み合わせ、観測されたドメイン/IPを表現するためのオブジェクトになります。 オブジェクトの例 オブジェクトは他のアトリビュート、オブジェクトとの relationships (リレーションシップ) を追加することができるのも大きな特徴です。これにより、MISPオブジェクトの背景情報を追加することが可能になります。 例えば communicates-with というリレーションシップをドメインのオブジェクト間に作成すれば、あるオブジェクト(例: マルウェアを表すオブジェクト) から別のオブジェクト(例ネットワークホストを表すオブジェクト)に通信が発生したことをMISPイベント上で表現することができます。 Tag Tag (タグ) はイベントやオブジェクトに付与することができる、イベント間の関連づけを行うためのものです。 タグを使うことで、イベントやオブジェクト間の関連性をMISP上で表すことができます。 Taxonomy Taxonomy (タクソノミー) は、情報のタグ付けや整理を行うための、共通のタグのライブラリです。タクソノミーはタグとして表現されます。 MISP間でイベントを共有する際、各インスタンスが独自のタグで管理を行うと、タグの意味するとことが分からずに混乱を生じます。 タクソノミーを使うことで、複数のインスタンス間で共通のタグを利用でき、円滑に情報共有することができます。 タクソノミーは、Githubの misp-taxonomy で定義されています。例えばTLP (Traffic Light Protocol)のタクソノミーを使うことで、情報の公開可能範囲をタグで規定することができます。 Galaxy Galaxy (ギャラクシー) は、イベントやアトリビュートに付与することができる、cluster (クラスター) と呼ばれる巨大なオブジェクトです。クラスターは複数のkey-value形式の要素を持ち、タクソノミーなどより多くの情報を付与することができます。 ギャラクシーはタクソノミー同様Githubのmisp-galaxy]( https://github.com/MISP/misp-galaxy )で定義されています。定義済みのギャラクシーには攻撃者グループの情報やマルウェアなどがあり、ギャラクシーを使うことでイベントやアトリビュートを補完することができます。 MISPのインストール方法 MISPを利用するために、MISPをインストールする方法について紹介します。 MISPのインストール方法は、 MISP公式ページ に記載されており、いくつかの選択肢があります。 公式のインストールガイドを使う場合 https://github.com/MISP/misp-taxonomies 基本的には自分が使用するOSのインストールガイドに従うことで、MISPのインストールが可能です。 例として、Ubuntu 18.04の場合は以下のコマンドでインストール可能です。 # インストールスクリプトのダウンロード wget -O /tmp/INSTALL.sh https://raw.githubusercontent.com/MISP/MISP/2.4/INSTALL/INSTALL.sh # インストールスクリプトの実行 bash /tmp/INSTALL.sh Dockerイメージを使う場合 MISPのdockerイメージはいくつか 公式サイト で紹介されておりますが、現在は docker-misp を利用するのが良いと思われます。 MISPの使い方の紹介 MISPのUIの使い方を簡単に紹介します。 Feedからのデータの入手 MISPをインストールした段階では、イベントは空の状態です。Feedと呼ばれる機能を使うと、イベントを外部から入手することが可能になります。 MISPはデフォルトでフィードの設定がいくつか存在しており、それを有効化することでOSINT (open source intelligence) などを入手することができます。 画面上部のメニューバーから、"Sync Actions" -> "List Feeds" とクリックし、フィードを設定画面に入ります。その後、有効にしたいフィード ("CIRCL OSINT Feed" など) の列の右端の "Actions" の項目のEditマークをクリックします。 そして "Enable" をクリックしてフィードを有効にし、ページ下の"Edit" をクリックして設定を完了します。 すると"Actions" の項目に "Fetch all events" というボタンが表示されるのでクリックすると、有効にしたフィードのイベントをMISPに取り込むことができます。 フィードはデフォルトで存在しているもの以外にも、自分で設定することも可能です。 イベントの閲覧 イベントの一覧の表示は、画面上部メニューバー左端の "Home" をクリックするか、"Event Actions" -> "List Events" と選択することで可能です。 イベント一覧から各イベントの画面に入るには、 "Id" の列に表示されているイベントIDの数値をクリックします。 各イベントの画面では、Evnetの各種情報などを閲覧できます。また画面下部にある + , - と書かれているボタンを押しますと、各項目の表示/非表示が切り替えられます。 例として "Correlation graph" の左の "+" をクリックすると、イベント間の相関分析のグラフを表示することができます。 Correlation graphでは、共通するアトリビュートを持つイベントを表示して関連性を調査することができます。 イベント・アトリビュートの作成 MISPのイベント・アトリビュートの作成方法について簡単に紹介します。詳細な説明は、MISPドキュメントの クイックスタートページ などを参照してください。 イベントの作成 MISPにデータを投入するためには、最初にイベントを作成する必要があります。 MISPのホーム画面の左側の "Add Event" を選択するか、上のメニューバーにある "Event Actions" -> "Add Event" を選択することでイベントの作成画面に入ることができます。 続いてイベントの情報を入力します。 Date: イベントの日付を入力します。 Distribution: MISPの機能でイベントが共有される範囲を選択します。 Threat Level: イベント作成者が考える、このイベントの脅威度を選択します。 Analysis: このイベントの解析段階を選択します。 Event info: イベントの概要を入力します。 Extends Event: 継承するイベントのID、もしくはUUIDを指定することでそのイベントを継承することができます。 アトリビュートの作成 イベントを作成すると、そのイベントに紐づくアトリビュートを作成可能になります。 イベント画面の左側の "Add Attribute" をクリックすることでアトリビュートの作成画面に入ることができます。 続いてアトリビュートの情報を入力します。 Category: "Network Activity"、"Antivirus Detection" など、アトリビュートの情報のカテゴリを選択します。 Type: アトリビュートの種類を選択します。Categoryごとに選択できるTypeが決まっています。 (Network Activity なら "ip-src", "domain"など) Distribution: このアトリビュートの公開範囲を選択します。デフォルトではイベントの公開範囲と同じになります。 Value: アトリビュートの具体的な値を入力します。 以上の作業により、イベントとそれに紐づくアトリビュートを作成することができます。 より多くのアトリビュートを一度に入力したい場合は、イベント画面左側の "Populate from" を選択することで、 "Freetext import" などの一括投入機能を使うことができます。 Freetext importは、自由なテキスト形式でIOCを投入できる機能です。IOCをテキスト形式で入力すると、自動的にカテゴリーとタイプを解釈して一括で入力が可能になります。 自動化 MISP はイベントの検索・取得や、イベントの新規作成などの各種操作を可能とする、REST API を提供しています。 REST APIの操作方法などは、 公式ドキュメント などに記載されています。 PyMISPについて REST APIを簡単に使用する方法として、公式のPythonライブラリーである PyMISP が提供されています。 PyMISPを利用することで、イベント/アトリビュートの作成や検索、タグ付けなどの操作をPythonを利用して自動化することができます。 PyMISPの利用方法は、 公式ドキュメント や PyMISPの Tutorial などが参考になります。 PyMISPの利用方法 MISPの操作には、pymispインスタンスを作成します。 from pymisp import PyMISP # アクセスURLの設定 MISP_URL = "https://misp.exmaple.com" # APIキーの設定 MISP_KEY = "YOURMISPKEY" # pymispインスタンスの作成 misp = PyMISP(url=MISP_URL, key=MISP_KEY, ssl=False, debug=False) イベント・アトリビュートの作成 イベントやアトリビュートの作成をする際は、 PyMISP.add_event を使用してイベントを作成した後にアトリビュートを追加します。 from pymisp import MISPEvent # イベントの作成 event_obj = MISPEvent() event_obj.info = 'This is my new MISP event' # Required event_obj.distribution = 0 # Optional, defaults to MISP.default_event_distribution in MISP config event_obj.threat_level_id = 2 # Optional, defaults to MISP.default_event_threat_level in MISP config event_obj.analysis = 1 # Optional, defaults to 0 (initial analysis) # オブジェクトの追加 event_obj.add_attribute('ip-dst', '192.168.10.1') # MISPインスタンスへの追加 misp.add_event(event_obj) イベント・アトリビュートの検索 文字列などで検索する場合は PyMISP.search を利用します。 例として、 192.0.2.1 という文字列を含むイベントを検索したい場合は以下のようになります r = misp.search(controller='events', value='192.0.2.1') イベントではなく、アトリビュートを検索することも可能です。 r = misp.search(controller='attributes', value='192.0.2.1') MISP活用の注意点 MISP活用していて注意すべき点について紹介します。ただ常に当てはまるわけではなく、意見には個人差がある旨をご了承ください。 イベントを肥大化させすぎない MISPでは、既存のMISPイベントにもアトリビュートを追加することができます。 しかし既存のMISPイベントにアトリビュートを追加し続けると、古い情報と新しい情報が混在するイベントになってしまいます。 インテリジェンスには鮮度があり、IPアドレスやドメインなどはすぐに陳腐化するため、古い情報を参照し続けることは誤検知などの原因になります。 1つのアラートの調査結果を1つのMISP イベントとして作成するなど、適切にイベントを分けるのが重要です。 イベント間の関連付けをタグなどで行うと、データの関連を示しつつイベントを分割することができます。 タグを積極的に活用する タグはイベントの概要を把握が容易になる、同一のタグのイベントなどを容易に検索できるなど、多くのメリットがあります。 MISPではコミュニティ主導でタクソノミーやギャラクシーの更新などが行われています。積極的に活用して、マルウェアファミリーなどの情報を付加するのが望ましいです。 またAPIを用いて自動化の際に、タグの値によって処理を変える、といった使い方も可能です。 情報ソースを残す このイベントは何を意味しているのかなどの背景情報を残すことは重要です。 例えばWeb上の情報などを基にイベントを作成する場合、そのページへのリンクともにPDFを添付するなど情報ソースを残す取り組みをするとよいでしょう。 まとめ 本日は、オープンソースのThreat Intelligence 共有プラットフォームのMISPを紹介しました。 MISPはコミュニティベースで開発が進められており、今も新しい機能が追加され続けています。 MISPを使用することで、Threat Intelligenceを使用するオペレーションの高度化・実現をすることが可能になります。 宣伝 最後に宣伝を。10月にニュースリリースで公開された 「ブロックチェーン型セキュリティ情報流通フレームワーク」 では、MISPを利用して脅威情報の共有・高度化を可能にするプラットフォームとなっています。 MISPインスタンスを接続していなくてもインテリジェンスを共有できるなどの特徴を備えています。 実証実験を実施中なので、ご興味ある方はニュースリリースの問い合わせフォームよりお問い合わせください。 https://www.ntt.com/about-us/press-releases/news/article/2020/1006_2.html 最後に 明日は yuki_uchida さんの 「 WebSocketの次の技術！？WebTransportについての解説とチュートリアル 」です。お楽しみに。

こんにちは、インシデントレスポンスサービス担当の濱崎です。今回は日本時間で 2020/9/12 10:00 ～ 10/24 10:00 に開催された Reverse Engineering の腕を競う大会、Flare-On 7 Challenge に参加したので、その内容と結果を紹介したいと思います。 Flare-On Challenge とは Flare-On Challenge は FireEye 社が毎年主催している Reverse Engineering に特化した Capture The Flag(CTF) 形式のセキュリティコンテストです。2014年から毎年 8～10 月の期間で開催されており、今年で7回目なので Flare-On 7 Challenge と呼ばれています。他の CTF に比べ次のような特徴があります。 多くの問題が Windows で動作するソフトウェアで構成されている FireEye 社が業務で実際に解析したマルウェアにインスピレーションを得て問題を作成しており、数ある CTF の中でも実践的な問題が多い 毎年 10～12 問出題され、一つ問題を解くと次の問題が提供される 開催期間は 6 週間と長い 多くの CTF は Linux で動作するソフトウェアを中心に構成されていると思います。また、マルウェア解析というタスクを意識した問題はそんなに多くないかと思います。そのため、Windows マルウェア解析の技術研鑽や腕試しをしたい人にはうってつけの CTF です。また、一般的なCTFは土日の間の24時間、または48時間で開催されますが、Flare-On Challenge は6週間と長い期間開催されるため、隙間時間を利用して取り組むことができます。土日にまとまった時間が取れない人にも優しい開催スケジュールとなっています。 私の普段の業務はマルウェア解析ではないのですが、趣味で楽しんでいることもあり今年は腕試しに参加してみることにしました。 チャレンジ結果 今年は計11問出題され、参加者は全部で5,668人。全問正解者は279人（全体の4.92%）という結果でした。その中で私は9問解くことができました。正直、開催前は6問くらい解ければいいなあと思ったのですが、思った以上に解けましたし、何より問題を解く中で新しい技術や知識が身についたので非常に満足しています。本業のディスクフォレンジック業務に役立つものもあり、業務の品質向上につながるものであったと感じています。ただ、10問目はかなり時間を使ったのですが解けず、まだまだ未熟だなと感じたのも正直なところです。ちなみに、Twitter などの評判を見ると、毎年最後の2問は一段とレベルがあがるそうです。見事にその壁に阻まれたことを知り、非常に悔しい気持ちでいっぱいです。臥薪嘗胆、来年は突破すると心に誓いました。 　 Flare-On Challenge Score 　 各問題の正答者数（1問以上解けた人は3,574/5,668人） 出典： https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html FireEye社のブログには正答者に関する各種統計値が載っていますが、個人的に興味深かったのは全問解けた人が所属する国についての集計値です。（所属国の入力は任意ですしバリデーションもないので、どこまで信用できるかは不明ではあります） 　 全問正答者の所属国の集計値 出典： https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html アメリカが見事に1位に輝いていますが、これには驚きはありません。驚いたのは、2位のシンガポールです。シンガポールの人口は570万人ほどだそうです。アメリカは約3.2億人ですので、シンガポールのセキュリティエンジニアのレベルの高さを感じさせます。また、3位ロシア、5位イスラエル、7位ベトナム、8位中国、10位ウクライナなど、サイバーセキュリティ関連のニュースで話題になる傾向が高い国は、比較的上位に位置しているように思えます。この結果は、国としてのサイバーセキュリティへの力を入れ具合、という指標になっているのかもしれません。ちなみに日本は全問正答者1名です。日本もサイバーセキュリティに力を入れていますし、多くの素晴らしい取り組みを行っていますが、こういった大会・イベントでのプレゼンスを上げたいと思うのは私だけではないと思います。 出題内容概要 はじめは WriteUp(=解法) を書こうかと思いましたが、FireEye 社公式 WriteUp が素晴らしいのでそちらを参照いただくとして、ここでは全11問について、その内容を一言でまとめてみます。一部解法のエッセンスを含みますのでご注意ください。 challnege # challenge title 概要 challenge1 fidler ゲームのクラック問題（python ソースコード付き） challenge2 garbage.exe 壊れた packed binary の修復問題（フォレンジックなどで復元した、データの一部が壊れてしまったバイナリを想定？） challenge3 Wednesday (mydude.exe) ゲームのクラック問題（ソースコード無し） challenge4 report.xls VBA stomping された xls の解析 challenge5 TKApp.tpk Tizen OS という Samsung の TV, wearable device などで使用されている OS で動作するアプリケーションパッケージ。ただ、やることは、 .NET アプリケーションの解析 challenge6 codeit.exe Autoit マルウェアの解析からインスピレーションを得た問題。解析自体は容易だが、flag の特定にクセがあり、個人的には難問だった challenge7 re_crowd.pcapng pcap に含まれる IIS の RCE 脆弱性(CVE-2017-7269)攻撃ペイロードの解析 challenge8 Aardvark ゲームのクラック問題。WSL 環境のみで動くことを特定する必要あり。 challenge9 crackinstaller.exe ソフトウェアのクラック問題。様々な暗号方式＋COM Objectの理解＋カーネルドライバの理解など、幅広い知識を求められる問題。個人的には最高に好きな問題。 challenge10 break Linux ELFバイナリ。子プロセス、孫プロセスが親プロセスを ptrace することで RPC 通信を実現している。ptrace を使っているのでデバッグが難しく厄介。解けなかった。 challenge11 Rabbit Hole チャレンジできなかった。かなり難問らしい。Gozi V3 を模倣しているとのこと。 個人的に最も好きなのは challenge9 の crackinstaller.exe です。この問題は、様々な技術要素が盛りだくさんで本当に勉強になりました。知らない知識や知っていてもあまり触れたことがない技術要素が詰まっているこの問題は大好きです。少しだけ紹介します。 この問題は、ソフトウェアのクラックをモチーフにしており、registry に正しい password が設定された状態でプログラムを特定の方法で動かすと flag を取得することができます。この password が何なのか、そして flag を取得するためのプログラムの動かし方は何なのか、を探す問題になります。 最初に渡される PE ファイルに、3つの別の PE ファイルが暗号化された状態で含まれています。一部はドロップし、一部はメモリ内で実行されます。 任意のユーザコードをカーネルモードで実行可能にする機能を持つ、正当な署名を持つ既知のカーネルドライバ 署名なしのカスタムカーネルドライバで、1の署名有カーネルドライバを通して実行される COM Server DLL 1,2はある文字列の SHA256 ハッシュを key とした ChaCha20 暗号方式で暗号化されており、3はシンプルな XOR で暗号化されています。 　 SHA256 hash 生成(Base64にも見えるがSHA256） 　 ChaCha20 復号処理 password については、2のカスタムカーネルドライバ内に ChaCha20 で暗号化された状態で保存されており、同ドライバ内の処理で復号されます。これを特定するにはカーネルドライバ特有の API や Registry Filter Driver の知識が必要です。また、その password は regedit などの一般的な viewer では閲覧できない Registry Class Type Strings に設定されるため、この辺の知識もあるとスムーズな解析が可能でした。 flag については、上記の方法で取得した password を HKEY_CLASSES_ROOT\CLSID\{CEEACC6E-CCB2-4C4F-BCF6-D2176037A9A7}\Config\Password に設定後、前述の 3. COM Server DLL の機能を呼び出せば取得できます。そのためには COM Class IID の特定と、それを呼び出す COM プログラムを書く必要があります。私は COM Class IID の特定を行う流れでそのまま静的解析をすることで flag を取得しました。その際、password を key とした RC4 暗号方式で flag を復号する処理があるため、RC4 の知識も必要になりました。他にも、AES 暗号方式で暗号化されている部分もあります。 　 RC4 Key-scheduling algorithm (KSA) このように、シンプルな XOR, RC4, ChaCha20, AES などの様々な暗号方式が何度も使用されています。そして、複数のバイナリが複雑に絡み合っていたり、カーネルドライバが絡んでくるため、動的解析もやりにくいものでした。結果として静的解析による暗号データ復号のとても良い訓練になりました。 ただ、カーネルデバッグの環境が整っている人は、動的解析でやってしまえば暗号方式特定作業は不要だったかもしれません。私は勉強したことがある程度で慣れてもないし、環境も用意していなかったので静的解析するしかなかった点は、経験不足を感じたところです。 最後に 私個人は challenge 9 でも十分難しく感じましたが、 SNS 上の世界のマルウェア解析者の感想では challenge 10, 11 への反応が非常に多く、まだまだレベルが追いついていないように感じました。次回は全問正解を目指したいと思いますし、日本人のプレゼンスも向上すると良いなと思っています。 This year’s winners are truly the elite of the elite! https://www.fireeye.com/blog/threat-research/2020/10/flare-on-7-challenge-solutions.html エリート中のエリートを目指して、皆さんも一緒に挑戦しませんか？

イノベーションセンターの星野と名雲です。 前回 に引き続き、2020年8月上旬にオンラインで開催されたBlack Hat USA及びDEF CONの発表内容を2つ、紹介します。 BlackHat及びDEFCONについては、 去年の参加記事 を御覧ください。 この記事では、以下の2つの講演を紹介いたします。 講演 資料 動画 Office Drama on macOS 資料 動画 A Framework for Evaluating and Patching the Human Factor in Cybersecurity 資料 - Office Drama on macOS 出典： http://i.blackhat.com/USA-20/Wednesday/us-20-Wardle-Office-Drama-On-macOS.pdf Microsoft Officeのマクロ付きドキュメントを介した攻撃に関する講演です。対象はWindowsではなく、macOSです。(BH・DEFCONあるあるですが、この講演はBHとDEFCON双方で発表されていました。) 本講演では、大きく分けて以下の3点について説明しています。 最近の攻撃事例 上記事例よりも先進的な攻撃実証(最新OSでパッチ適用済み) 実証した攻撃の防御方法 最近の攻撃事例 一つ目は、最近の攻撃事例です。Microsoft Officeのマクロ付きドキュメントを用いた攻撃について、2017年、2018年、2019年に起きた事例を一つずつ紹介しています。それぞれのマクロやペイロードの分析結果も説明されています。攻撃事例には以下のような特徴がありました。 米大統領選やビットコインなど時事的なファイル名を利用 APT GroupであるLazarus APTがマクロ付きドキュメントを悪用 マクロ経由でPythonを呼び出し、ペイロードのダウンロードや実行を行う 2018年の事例ではサンドボックスをエスケープする手法を利用(以降、サンドボックスエスケープと記載) この中で最も興味深いのは、サンドボックスエスケープです。最近のMicrosoft Officeのアプリケーションは、サンドボックス化された環境で動いています。これが何を意味するかというと、仮にマクロ付きドキュメント経由で悪性なコードが実行されても最小限の被害に留めることができます。例えば、攻撃者がリバースシェル 1 を張ったとしても、サンドボックス内で許可されたリソースにしかアクセスできず、ユーザが利用するディレクトリにある機微情報の含まれたファイルにはアクセスできません。また、Persistence(永続化)を行うこともできません。 サンドボックスエスケープは、このサンドボックスから脱出する手法であり、権限的に許されるすべてのファイルへのアクセスや、Persistenceが可能になります。この手法は、Adam Chesterという研究者の手法で、講演中ではAdam's PoCと呼んでいます。Adam's PoCは、Microsoft Officeのアプリケーションが、特定の名称のファイルに限り、サンドボックス外のファイルの読み取り・書き込みを許可する仕様があることを利用します。これを利用すると、macOSのLaunchAgentsディレクトリ配下にプロファイルリストを作成できます。つまり、ログイン時に実行される処理に任意の悪性コードを登録できます。ここで起動されるコードは完全にサンドボックス外にいるため、Microsoft Officeのサンドボックスを抜け出して感染を実現できるというわけです。 詳細は こちら を御覧ください。 発表者によると、上述の攻撃はどれも"Super lame"(ちょーだせぇ)とのこと。なぜなら、マクロを実行する時に警告のポップアップが表示され、「許可」をおさなければマクロが実行されないためです。この機能は1999年にメリッサと呼ばれるマクロウィルスが登場した後、Microsoftが緩和策として施した機能のようです。 上記事例よりも先進的な攻撃実証(最新OSでパッチ適用済み) ２つ目の「上記事例よりもAdvancedな攻撃実証」では、いくつものエクスプロイトを組み合わせて、よりスマートな攻撃を目指します。個人的にはこれが最も興味深い内容でした。 個々のエクスプロイトを説明するとかなり長くなってしまうので、ここでは最終的なエクスプロイトチェーン 2 を簡単に説明します。 1. "0-click Attack"によるマクロ付きドキュメント開封時の警告をバイパスする 2. "Adam's PoC"に対するMicrosoftのパッチの穴を利用してマクロ経由でとあるZIPファイルを ~/Library 配下へダウンロードし、ログイン項目(Login Items)に登録する。 3. ユーザが再ログインすると、ZIPが展開され、 ~/Library/LaunchAgents/foo.plist が配置される 4. さらにユーザが再ログインするとfoo.plistで指定した悪性コードが実行され、感染する 出典： http://i.blackhat.com/USA-20/Wednesday/us-20-Wardle-Office-Drama-On-macOS.pdf 一つずつ意味を説明します。 1.では、SYLKというファイル形式とXLMというマクロ言語を利用し、マクロ付きドキュメントの保護ビューやマクロのアラートをバイパスします。 2.では、Adam's PoCに対するMicrosoftのパッチが「 LaunchAgentディレクトリ等の特定のディレクトリへのファイル書き込み/読み込みの禁止」であったことを利用し、サンドボックス外の領域へ任意のファイルを配置し、それをログイン項目に登録します。ログイン項目は、ユーザのログイン時に自動で指定したファイルを実行する機能です。ここでは、ZIPファイルを ~/Library 配下に配置し、そのZIPファイルをログイン項目に指定します。この理由は後ほど説明します。 なお、ログイン項目はあくまでファイルを指定するだけであり、引数指定ができないので、ターミナルアプリを起動させても悪性な処理を実行できません。かといって、ペイロードを含んだファイルをログイン項目に指定すると、信用できない作成者のファイルとみなされてブロックされます。そこで、3.の手法を取ります。 3.では、2.で配置したZIPファイルが展開されています。これは、ログイン項目にZIPが指定された場合、ZIPを開く際デフォルトのアプリケーションとして指定されているアーカイブユーティリティが起動し、自動でZIPを展開することを利用しています。さらに、ZIPファイルの圧縮前のディレクトリ構造を ./LaunchAgents/foo.plist にしておくことで、展開されたときに ~/Library/LaunchAgents/foo.plist となるようにします。2.でZIPファイルを ~/Library 配下においたのはこのためです。 4.では、再ログイン時に3.で配置した起動エージェントが実行され、本命の感染処理が行われます。ログイン項目ではなくLaunchAgentsを利用することで、bashに引数を指定し、任意の処理を実行できます。発表者のスライドの例では、bashを使って外部とソケット通信を行うようにしています。 以上が、より先進的なエクスプロイトチェーンの簡単な説明です。 実証した攻撃の防御方法 最後は上記の攻撃実証に対する防御方法です。発表者は以下の二つを推奨しています。 まず一つ目は、プロセス監視です。Excel等のOfficeアプリを親プロセスに持つcurlやPythonなどのプロセスを監視することで、ファイルダウンロードや実行を検知します。 二つ目はファイル監視です。ログイン項目は、 ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm で管理されます。そのため、このファイルを監視することで、意図しないログイン項目が追加されたかどうかを確認できます。 以上、本講演の内容を簡単に説明しました。 彼らの発表スライドでは、リファレンスが多く示され、その一つである彼らのブログではより詳細な説明がされていました。そのため、興味を惹かれた部分を深堀りしやすいという点で、良い発表だと感じました。（あと、スライドのキャラクターが可愛かったです。） A Framework for Evaluating and Patching the Human Factor in Cybersecurity ソーシャルエンジニアリング攻撃に対するユーザーの対応力を評価するための方法とフレームワークを紹介した発表です。 ソーシャルエンジニアリング攻撃は、スピアフィッシング、スパムポップアップ、怪しい権限要求、証明書の操作など近年変化しており、これらの多様な種類の攻撃の対策のためにユーザーが必要とするスキルが多岐にわたることは、皆さんご存知かと思います。 これまで、一般的には以下のような対策がとられておりますが、いずれも単独では課題があります。 ヒアリング 自己申告ベースであり正確性に欠ける 攻撃シミュレーション 部分的であり網羅性に欠ける トレーニング 汎用的であり現実性に欠ける 保護・隔離 一次的であり継続性に欠ける 提案 発表者は「特定のソーシャルエンジニアリング攻撃に対するユーザーの対策力を継続的かつ客観的に評価するためのフレームワーク」を提案しています。 上記に挙げた対策の欠点を補うため、全てを組み合わせて実施します。つまり、以下のようになります。 ユーザーのアンケートによるセルフ診断 フィッシング攻撃のシミュレーション セキュリティ意識トレーニング メール保護・ブラウザ隔離 セルフ診断では、ユーザーにセキュリティに関するアンケートを取り、対策が出来ているかを自己申告してもらいます。 攻撃シミュレーション中は、ユーザーが利用中のデータを収集します。測定機能として以下の方法を使用します。 Androidエージェント スマートフォンで操作しているときのユーザーの実際の行動を測定 Chrome拡張機能 PC操作している間のユーザーの実際の動作を測定 ネットワークトラフィックモニター デバイスとの間で送受信されるネットワークトラフィックを分析 攻撃シミュレーター ユーザーに複数のソーシャルエンジニアリング攻撃を実施 これらのアンケートと測定結果は別のデータベースで紐づけられており、例えばブラウジングに関する項目は以下のようになっています。 出典：引用文献である Evaluating the Information Security Awareness of Smartphone Users から抜粋および和訳 そして、継続的に評価するため、分析→監視→訓練というワンショットで終わるのではなく、このサイクルを回していくことが提案されています。 出典：資料から引用 実験結果と考察 提案するフレームワークの評価のため、162人のユーザーを対象とした7～8週間の実験結果が報告されています。 出典：資料から引用（※MDA：Mobile Device Agent、NTM：Network Traffic Monitor、SEQ：Security Questionnaire） 結果として、以下の考察がされています。 攻撃の種類によって、ユーザーが攻撃を対策するために必要なスキルは異なる。 実際の動作に対して、ユーザーの自己申告は多く誤っている。 実際の動作から算出されたセキュリティ意識レベルは、ソーシャルエンジニアリング攻撃を対策する能力と高い相関がある。 本発表の基となった論文 )の方にはアンケートや測定手法の詳細、ユーザーの意識レベルの計算方法など、興味深い内容が記載されています。そちらも合わせて見てみると見識が広がるのではないでしょうか。 リバースシェルとは、遠隔操作対象の端末から手元の端末に対して通信し、接続させる手法。攻撃者はこれを悪用し、一般的なFW回避などを目的に、標的マシン側から攻撃者マシンに対して接続させ、bashなどのシェルを遠隔で操作できるようにする。 ↩ エクスプロイトチェーン: 複数のエクスプロイトの組合わせで実現される一連の感染・攻撃プロセスを指す。 ↩

イノベーションセンターの山本と久保です。 2020年8月上旬にオンラインで開催されたBlack Hat USA及びDEF CONの発表内容を一部調査しましたので報告します。 Black Hatは世界最大級の商業系セキュリティカンファレンスで、毎年USA、Europe、Asiaの三地域で開催されます。Black Hat USAは例年はラスベガスで開催されているのですが、今年はCOVID-19の影響でオンラインのみの開催となりました。Black Hat USAと併せて開催されるハッカーの祭典とも言えるDEF CONも同じくオンライン開催です。今年の会場の雰囲気をお伝えすることができないため、Black HatやDEF CONの詳細については以前の記事、「 Black Hat USA 2019 / DEF CON 27に参加してきました 」をご覧ください。 この記事では、今年のBlack Hat USA/DEF CONのブリーフィングから私たちが興味を持った発表の一部を紹介いたします。PART1で紹介する発表は以下の2つです。 講演 資料 動画 Virtually Private Network 資料 デモ動画 Deep Dive into Adversary Emulation - Ransomware Edition 資料 講演動画 Virtually Private Network OrangeCyberdefense社のWicus Ross氏による、VPNの安全性について調査及び評価した発表です。 Research Proposal もしVPNの接続元のネットワーク（例えば公衆無線LAN）が攻撃者の手により汚染されていた場合、社内NWへと接続するVPNは想定される脅威に対してどの程度抵抗できるのか。この疑問に答えるために、発表者は6つの具体的な脅威を想定し、4社のVPN製品の評価しました。想定された脅威は、機密情報の盗聴、DNSスプーフィング、Webサイトのなりすましによる認証情報の窃取、ResponderによるWindowsハッシュの窃取、ブラウザのプロキシトンネリング化、IPv6でのホストとの通信です。 Overview of findings これら脅威へのVPN製品の評価結果概要は以下の通りです。 初期設定状態のVPNはベンダーに関わらず、攻撃者により掌握されたAPに接続した際に想定される脅威の多くに対抗できない。（VPNのスプリットトンネリングはあまり推奨できない。） 脅威への対抗措置として任意の通信をVPNトンネルへ通すことは、ベンダーに依存するものの一定の効果が期待できる。 Background この評価検証の動機は、発表者が所属するOrangeCyberdefense社で実際に発生したインシデントだそうです。 そのインシデントは、2名の社員が公衆無線LANからVPNを利用していた際に、社員2名のそれぞれの端末がインターネット上のサーバにSMB接続したことを示すセキュリティアラートから始まったそうです。SMB接続は共有フォルダに接続する際になされますが、インターネットへのSMB接続は見知らぬ接続先サーバに認証情報を窃取される恐れがあるので、この企業ではセキュリティ監視されていました。アラートを元に調査を進めると2名の社員は同じホテルの同じ公衆無線LANを利用していたことが判明し、それぞれの端末には同じIPへのSMB接続へのログが残っていました（下図。スライドは 公開資料 より引用）。 接続先のサーバ名 PRINTER-HQ は、社内ネットワークに実在する共有プリンターを示しています。この共有プリンターには端末の起動時やスリープ解除時にアクセスすることがログからも確認できました。しかしログのサーバアドレスはインターネット上の 66.96.162.92 を示し、それは domain.com のアドレスであり、社内ドメインとは異なる外部ドメインでした。本来であればプリンターのアドレスは、社内のプライベートアドレスであるはずです。なぜホテルの公衆無線LANに接続していた際に、外部ドメインで名前解決がされたのか疑問が残ります。 調査を続けたところ、ホテルのWi-FiのDHCP設定に今回のアラートの原因が見つかりました。ホテルの公衆無線LAN接続時にDHCPから提案されるIPアドレスなどの設定情報の一つ、DNS Search Suffixの値が domain.com だったのです。DNS Search Suffixは不完全なドメイン名（例えば PRINTER-HQ ）で名前解決がなされた際に補われるドメイン名です。端末起動時に端末が自動的にプリンターの名前を解決しようとしたところ、それが外部ドメインに結びつけられインターネットへSMB接続したのがアラートの原因だったのです。 このインシデントをきっかけにVPNのセキュリティ機構に発表者は興味を持ったそうです。それが最初に述べた、もしVPNの接続元のネットワーク（例えば公衆無線LAN）が攻撃者の手により汚染されていた場合、社内NWへと接続するVPNは想定される脅威に対してどの程度抵抗できるのか、という疑問となり発表内容であるVPN製品の評価検証に繋がったようです。 スライドを斜め読みした際には内容の面白さが実は分かりませんでしたが、読み進めていくと面白さがわかる発表でした。 Deep Dive into Adversary Emulation - Ransomware Edition by Jorge Orchilles SCYTHE社のCTOであるJorge Orchilles氏による、ランサムウェア攻撃のAdversary Emulationを実施する方法についての講演です。 講演の前半部分ではRedTeam、Purple Teamingなどについても触れられていますが、本ブログでは後半部分のAdversary Emulationを実施したかという点に絞って説明いたします。 Target Adversary & Operation 2020年7月、Evil Corpという攻撃グループによってGarminがランサムウェア攻撃を受け、約一週間オンラインサービスを停止しなくてはいけない事態に陥りました。 この攻撃では、WastedLockerという新種のランサムウェアが使用されたと言われています。 出典： ランサムウェア攻撃によってGarminのサービスが世界的に停止 講演では，このEvil Corpによる攻撃事例を題材として，Adversary Emulationを組み立てていました。 Cyber Threat Intelligence Adversary Emulationを行うに当たって、まず実施するのがCyber ThreatIntelligenceによるTTPの抽出、そしてAdversary Emulationプランの作成です。 Evil Corpによる攻撃については、 nccgroup や symantec 、 malwarebytes が詳細な分析レポートを公開しており、そのレポートを用いてEvil Corpが使用したTTPの抽出とプラン作成、MITRE ATT&CKへのマッピングを行ったそうです。 （攻撃の詳細についてはレポートを参照ください。） 出典： ATT&CK Navigatorへのマッピング結果 SCYTHE社は、 #ThreatThursday という取り組みを行っており、定期的にAdversary Emulationのプラン作成の過程と結果( github )を公開しています。 ハッシュ値やIPアドレスのようなIOCと異なりTTPを抽出するのは大変な作業なので、そのノウハウと結果を公開してくれているのはとてもありがたいですね。 [参考]講演では紹介されていませんが、ATT&CKが TRAM というツールを公開しており、TTPの抽出の助けになります。 Adversary Emulation Adversary Emulationにおいて、配慮すべきこととしてお客様環境への影響があります。 ランサムウェア攻撃はMITRE ATT&CKでいうところのTactic：Impact、Technique：Data Encrypted for Impact, Data Manipulationに当たるわけですが、お客様もRedTeamもこのオペレーションを実データに対して行うことは避けたいでしょう。 そのため、実際のビジネスデータは暗号化しない、新しいファイルを作成してそれを暗号化（and/or 搾取）するというやり方、取り決めでランサムウェア攻撃を模倣することにしたそうです。 C2 FrameworkはCobaltStrikeとSCYTHE（SCTYHE社が開発している）を使用していました。 CobaltStrikeはとても有名なC2 Frameworkであり、攻撃者もRedTeamも使用することで知られています。Evil Corpの攻撃でも実際に使用されていたと言われており、本講演でも攻撃者を模倣するためにCobaltStrikeを使用していました。 また、ランサムウェア攻撃の模倣については、SCYTHEを使用していました。SCYTHEを用いて以下の機能を持つ疑似マルウェアを作成し、WastedLockerに似せた攻撃を行ったようです。 Desktopに EvilCorp ディレクトリを作成 作成したディレクトリにファイルを作成し、暗号化 攻撃者のメッセージを真似したテキストファイルをディレクトリに設置 出典： #ThreatThursday - Evil Corp [参考] 講演ではC2 FrameworkのCapabilityなどがまとめれている C2 Matrix についても触れられていました。 以上、簡単にですが講演内容を紹介しました。 SCYTHE社は#ThreatThursdayの他にも、SDKを公開してTTP Bountyという形でユーザに拡張機能を開発してもらいSCYTHEのプラットフォームを推進するという面白い取り組みを行なっており、今後の動向に注目したいなと思っています。 最後に 次回は同じチームの名雲と星野が「Office Drama on macOS」と「A Framework for Evaluating and Patching the Human Factor in Cybersecurity」を紹介をします。

はじめまして、技術開発部セキュリティユニットの神田です。 2月7日、21日にNTT Comグループ社員を対象にセキュリティワークショップ『ハニーポッターになろう ～インターネットの今を知って正しく怖がる～』を開催しました。本記事では、その内容や当日の様子について紹介します。 セキュリティワークショップ『ハニーポッターになろう ～インターネットの今を知って正しく怖がる～』 このワークショップは、NTT Comグループ内セキュリティコミュニティの有志を中心として完全内製で企画、開催されました。開催の主な目的は以下の通りです。 インターネットを取り巻く脅威の現状を体感し、理解を深める ハニーポットの運用や分析に必要な視点を習得する セキュリティコミュニティの活性化（交流の促進） ワークショップは二部構成のグループワーク形式で、第一部（2/7）でハニーポットを構築後、2週間のログ収集期間をおいて、第二部（2/21）で収集したログの分析ハンズオンを行いました。また、第二部後半にはログを活用したアイディアソンも開催しました。 ハニーポットとは このワークショップで題材としたのは、 ハニーポット です。ハニーポットとは、不正なアクセスの観測を主な目的とした囮（おとり）環境のことです。蜜壺の名が表すように、敢えてセキュリティを甘くした脆弱な環境（攻撃者にとっては魅力的な環境）を用意することで不正なアクセスを誘い込み、情報を収集します。 ハニーポット運用者のことを親しみを込めて ハニーポッター と呼ぶことがあるため、ワークショップのタイトルはここからとっています。 コース概要 第一部：ハニーポット構築・操作ハンズオン 第一部では、まずクラウド環境上に構築された仮想サーバ（ほぼ初期状態）からスタートして、自分たちでハニーポットを構築してインターネット上に公開してもらいました。 ハニーポット稼働開始後は、ハニーポットの基礎を座学形式で学んでもらうとともに、構築したハニーポットに自ら触れてみるハンズオンも実施しました。 第一部のハンズオンの特徴的なところは、 防御者（アクセスを待ち受けて分析する側）の視点 だけではなく、 攻撃者（不正アクセスを試みる側）の視点 でもハニーポットに触れてみるという点です。自ら攻撃者の視点に立ってハニーポットにわざとはまってみることで、攻撃者から見てハニーポットがどう見えるのか、どこにハニーポットを見破るポイントがあるのかを体感してもらいました。また、自分の（攻撃者としての）アクセスログを防御者の視点で追いかけることで、ログから実際のアクセス行動や意図をイメージしやすくする狙いもありました。 第二部：ハニーポット分析ハンズオン＆アイディアソン 第二部では、第一部で稼働させたハニーポットで収集したログを使った分析ハンズオンを実施しました。収集したリアルなログデータの分析を通じて 今のインターネットで起きていることを生々しく体感 してもらうとともに、攻撃者の行動履歴からその目的を推測したり、アクセス元が何者なのかを調査するといった発展的な分析も体験してもらいました。 第二部後半では、参加者同士の相互理解と交流を促すために「ハニーポットログのビジネス活用」というテーマでアイディアソンも開催しました。 当日の様子 リソースの関係上、今回のワークショップは30人という定員を設けて募集しましたが、セキュリティ関連業務に従事している社員だけではなく、クラウド・アプリケーションといった別分野のエンジニアやオペレーションエンジニア、セールスなど幅広いジャンルの社員から応募があり、予定よりも早く募集を締め切る人気ぶりでした。 第一部では、普段サーバを触ることのない人もおり、構築に悪戦苦闘する場面もありましたが、ハニーポットを公開した途端にアクセスが来る様子に驚きの声が会場のあちらこちらから聞こえていました。 （COVID-19対策のために、マスク着用・消毒用アルコール設置・加湿器稼働で臨みました） 第二部前半では、特にアクセスの多かったポートを中心にインターネットからのアクセスを分析しました。分析を進める中で攻撃者が仮想通貨採掘型マルウェアを送り込んで実行しようとしていたことが確認できたグループもありました。 （講師もマスク着用） 第二部後半のアイディアソンでは、運営側の予想を超えたバラエティ豊かなアイディアが披露され、大いに盛り上がりました。ここには書けないような情報も含まれているため詳細は割愛しますが、他のサービスと組み合わせたアイディアや普段の業務と絡めたアイディアなどが出ました。参加者自身の業務経験を踏まえたアイディアは運営としてもとても刺激になりました。 参加者の声 最後に、参加者へのアンケートから得られたコメントをいくつか紹介します。 インターネット上での漠然とした脅威を実感できた セキュリティに関する具体的なイメージが強まった 業務で扱っている商材に追加できるかもしれない ハニーポットの話だけでなく各部参加者からの発表が良い勉強になりました まとめ 本記事では、NTT Comグループ内で開催したセキュリティワークショップ『ハニーポッターになろう ～インターネットの今を知って正しく怖がる～』について紹介しました。 昨今のCOVID-19に関する騒動もそうですが、人は知らないことに対して恐怖を感じる性質があり、ときにその恐怖は必要以上に増幅することがあります。冷静に現実を捉えて、事実に基づいてインターネットを正しく怖がるために、引き続き社内外に向けて情報を発信していきたいと思います。

はじめまして、ネットワークサービス部 山本です。 1/22-24の3日間で開催されたJANOG45 Meeting in Sapporoに参加しましたので、その模様をご紹介します。 JANOG とは？ JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。( JANOG 公式 より引用) ものすごく簡単に言ってしまえば、インターネットを良くするために技術的な項目等を話し合うためのグループと言うことになります。 JANOG45 Meeting概要 JANOGの普段の活動はメールによるやりとりですが、年に2回実際に顔を合わせてのミーティングを行います。 開催場所は前々回は甲府、前回は神戸といったように地方を中心に開催されてきていますが、今回は北海道総合通信網株式会社様、 株式会社ネクステック様にホスト頂き、札幌プリンスホテル 国際館パミールで開催されました。 (JANOG45ミーティングフォトアルバムより) 入り口を入ると、スポンサー企業がずらりと並べられていました。今回も多くの企業に協賛いただいたようです。 (JANOG45ミーティングフォトアルバムより) ミーティングには、1/24 16時時点の集計で 1529名 もの人が参加したそうです。 今回のMeetingでは多種多様なバックグラウンドを持った方が参加し様々な角度から議論ができるようにということで、 「360° connect」 がテーマとして掲げられていました。このテーマに沿い、一部のセッションでは同時通訳が行われるなど新しい試みが行われていました。この試みは海外からの参加者には大変感謝されていたようです。自分自身英語で行われたセミナーを聴講する際に、同時通訳のおかげで安心して臨めた経験があるだけにその気持ちはとてもよく理解できます。日本のネットワークが扱われることが多いですが、こうした試みを継続することで海外からの参加者が増え、より実りのあるミーティングにすることができるのではないかと思いました。 弊社もスポンサーとして協賛し、ブースの方では昨年9月にリリースした次世代インターコネクトサービス「Flexible InterConnect」を紹介させて頂きました。 また、私と同じ部署の先輩である伊藤 良哉と松田 丈司からは「OCNでサーバレス導入してみたけど、通信サービスでクラウド使うのってどうなのよ？」と題し、 ネットワークサービスに関してはオンプレでの構築が1st チョイスであった弊社においてなぜサーバーレスアーキテクチャを採用したのか 3ヶ月という短納期で開発するために行った工夫や開発時の苦労 サービスリリース後のシステム構成の変遷 などについて共有させていただきました。 当日の発表資料は こちら に公開していますので、ご興味がある方はぜひご覧になってください。 この他にも、2つのセッションと1つのBoFで弊社グループの社員が登壇させていただきました。 「フィッシングの現状とその対策」登壇者: カスタマーサービス部 山田 慎悟 資料は こちら 「サービスプロバイダーでのEVPN導入事例」登壇者: NTTPCコミュニケーションズ 大塚 悠平 資料は こちら 「サイバーセキュリティBoF #6 サイバー犯罪に悪用される日本国内の『踏み台』の実態と対応」登壇者: NTTコムエンジニアリング 近藤 和弘 資料は こちら 面白かったセッション 扱われるテーマは多岐にわたっており面白いセッションは数多くありましたが、ここからは個人的に面白かった/印象に残ったセッションを2つ紹介します。 地域内通信基盤としてのNTT-NGN折り返し機能 このセッションのテーマは、「一般家庭がインターネットに接続する際によく使われるNTT-NGNを緊急時の地域内情報通信のインフラとして使用するためにはどのような方策が必要になるか」ということでした。自然災害が多い昨今、緊急時により正確な情報を安易に入手できることの重要性はとても高いこともあり、登壇者/聴講者含め熱い議論が交わされていたことが強く印象に残りました。 総務省の「ネットワーク中立性研究会」の中間報告書 ( 公開資料 )で言及されている通り、現在の日本のネットワークは都市部一極集中型の構成・トラヒック交換となっています。大規模災害により都市部を介した相互接続ができなくなった際に、災害情報をはじめとした多様なコンテンツの配信を継続するための手段としてNTT-NGNにおける折り返し機能に焦点が当てられました。 NTT東日本の石田さんから、NGNのIPv6対応状況や折り返し通信を可能とするフレッツ・v6オプション、NGNのトラフィック推移などが共有されました。 IPoEのトラフィックは前年同月比1.6倍で増加している NGN全ユーザの約87%が折り返し通信が可能である 等、普段あまり聞くことができないNGN網内のトラフィック情報などが報告されました。 また、インターネットマルチフィードの外山さんからは、NGNが多数の通信事業者が相互接続していることからIX的に活用した場合を想定し、NGNの3つインタフェース(UNI, SNI, NNI)それぞれについてどれを使用するべきかについて検討した結果が共有されました。現状のNGNのインタフェースをそのまま使用しようとした場合、コストやBGPでの経路制御、ユーザー共用となるため帯域の確保が難しいというような観点で何らかの妥協をする必要があるとまとめられていました。 JANOG meetingでは登壇者からの発表後はミーティングらしく聴講者を含め議論の時間となります。会場からは下記のような今後より一層議論を深めるための提案や意見が挙げられていました。 (全体論で話しても)けりがつきにくいため、スモールスタートで議論を進めた方が良い CATV事業者のために第4のインタフェースを用意して欲しい 災害時だけではなく常時みられるようなサイトを用意するべきだ 普段業務としてインターネット接続サービスの開発を担当しており、自身もユーザーとしてNTT-NGNを利用している身としては、NTT-NGNの動向や様々な意見を生で聞くことができたという意味で非常に収穫となったセッションでした。 Faster SRv6 D-plane with XDP 前々回、前回のJANOGに引き続きLINEのバックボーンネットワークに関する取り組みが共有されたセッションです。 LINEでは複数のサービスを提供するにあたり、それぞれ個別のネットワークを構築することによる運用コスト増大が問題となっていたそうです。この問題に対する対処として、アンダーレイネットワークを共通化してオーバーレイをテナント分離することを検討し、SRv6の導入へと踏み切りました。 SRv6の実装はLinux kernelに対して行われており、SRv6のパケットを転送するためにソフトウェアによるFIBのルックアップを複数回行う必要がありました。このルックアップや関数呼び出しのコストがボトルネックとなり、普通のIPv6転送と比べて半分程度の性能しか出なかったとのことです。その課題への対処として、LINEの用途に特化した上でXDPによる改善がなされました。 SIDとSRv6パケットを処理させるVRFの関係はプロジェクトネットワークが構築された際に決まります。そこで、その関係を事前に計算し、XDPで処理する際にその結果を参照することで最適化が図りました。これによりFIBのルックアップの回数を減らすことができただけでなく、参照する必要があるVRFの数の削減も実現しました。その結果、改善前と比較して約3倍の性能向上が図られたとのことでした。 ちなみにこのセッションの内容ですが、発表者の齋藤さんがインターンの課題として行った取り組みだったそうで個人的には大変刺激を受けました。twitterでの反応を見てみると、インターンで取り組んだ課題のレベルの高さや、会社としてその結果を惜しみなくコミュニティに共有する姿勢を評価する声なども見られました。 終わりに ブログでは触れることはできませんでしたが、今回のJANOG meetingも総務省をはじめとする官公庁の方々や、大学教員、JANOGの若者支援プログラムで参加した学生など、官民学 様々な立場の人が参加していました。実際に会場で参加してみて、参加する人は皆 立場や背景の違いによる意見の違いはあるがネットワークをより良くするためにはどのようにすべきか考えている点は変わらないということを知れた点が大きな学びでした。自身もいちエンジニアとして貢献できるよう努力していこうと思います。この他にも他社の抱えるの悩みといった普段職場で働くだけでは聞くことができない話を聞けたりなど、大変有意義な時間を過ごすことができました。今後もこのような機会があればぜひ参加していきたいと思います。 また、紹介できなかったプログラムの多くについて、 JANOG45公式 では資料を公開しています。期間限定でプログラムを撮影した動画アーカイブなども公開されていますのでぜひ一度ご覧になってみてください。 早くもJANOG meeting46の情報も解禁されていますので、次回参加してみたいと思った方は是非スケジュールを調整の上参加してみてください！ #JANOG 45 ニュースレターの「JANOG46 へのいざない」を公開しました。 https://t.co/59XTMm5r8x 本ニュースレターでは JANOG46 の開催地である沖縄についての概要，JANOG46 への想いなどが記載されております。 皆様とシーズンインの沖縄でお会いできることを心より楽しみにしております！ — JANOG Meeting (@janogmeeting) January 31, 2020

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 ↩