はじめに こんにちは、インターンシップ生の田畑（GitHub: TBT0328 ）です。 9月16日から30日の2週間、NTTコミュニケーションズのインターンシップに参加させていただきました。 この記事では、インターンシップでどのようなことをしたのかを紹介します。 概要 今回私は、NTTコミュニケーションズ イノベーションセンターで制御システムネットワークのセキュリティ可視化技術である OsecT （オーセクト）の開発に関する業務を行いました。 今回のインターンシップは新型コロナウイルス感染拡大防止のため、全日リモート形式での実施でした。 参加のきっかけ 大学の研究室の先輩から「実際の業務（もしくはそれに近い業務）に携われるからとても楽しいよ！」と熱い（？）アピールを受け、ぜひとも参加したいと思い応募しました。 参加前の面接では、インターンシップでの業務内容を複数提示していただき、インターン生がやりたい内容に合わせてくれる柔軟性の高いインターンシップだと感じました。 インターンシップ内容 OsecT内で動くツールや仕様の一部変更、最新のLTSへのアップデートをDockerを使用してプログラム作成などを行いました。 ソースコードの管理はGitHubを使用しており、研究室でのコード管理とはまた違った、実際の業務環境で作業しました。 私自身、DockerやGitHubを使った経験があまりなく、GitHubへのPullRequestの投げ方や、Dockerfileの書き方などの基本的なことから教えていただきました。 下図はGitHubへのPushやDockerfileの書き方に悪戦苦闘して長くなってしまったコミット履歴です。 また、人が書いたコードの読み方や実装後のテスト方法などを教えていただきながら、OsecTのサービス化に向けて役に立てるようなことができたと感じています。 業務環境 全日リモート形式での開催ということで、自宅から参加しました。 NTTコミュニケーションズから、インターンシップで使用するPC、インターンシップ期間中の昼食代相当のチケットを支給していただきました。 OsecTの開発は自前のPCを使い、トレーナーの方やチームの方々とはSlackで連絡を取り合いました。 また、期間中毎日、インターンシップの進捗報告と今後の方針を相談する朝ミーティングを開いていただきました。 下図は朝ミーティング後のタスク確認の様子です。 イベントへの参加 期間中はすべてリモートということで、実際にオフィスに行くことはなかったのですが、複数の社内イベントに参加させていただきました。 NTTコミュニケーションズの技術顧問との対話会 インターンシップ生を対象にしたスペシャルイベントとして、NTTコミュニケーションズの技術顧問の方々との対話会を開催していただきました。 技術顧問との対話会と聞いて堅いイベントだと思っていたのですが、とてもカジュアルな対話会でした。 技術顧問の方々が実際にどのような業務・支援しているのか、技術顧問の方々が感じるNTTコミュニケーションズの印象など、リアルな職場を知ることができる対話会でとても勉強になりました。 イノベーションセンター内業務共有会 インターンシップ後半に差し掛かり、イノベーションセンターに所属するインターンシップ生同士での業務内容の共有会を開催していただきました。 期間中どのような業務を行ったか、どのようなことを学んだのかを発表していくという流れで、自分以外のインターン生が行った内容や、他チームが行っている業務について知ることができるイベントでした。 期間中はOsecTに関する業務を行っていたので、他インターン生が参加したプロジェクトやその有用性を多く学べる機会でした。 KOELによるデザイン研修 イノベーションセンター内のデザイン部門である KOEL の方々によるデザイン研修会を開催していただきました。 「デザイン思考」や「デザインプロセス」についてや、KOELがデザインした 「NeWork」 を開発する段階での具体的なデザイン思考についてお話をしていただきました。 アイデアの創出の前にすべきことや、それぞれのデザインプロセスで有用なフレームワークについて学ぶことができ、研究室での活動では得難い視点でとても新鮮で勉強になりました。 TechLunch NTTコミュニケーションズではランチの時間帯に、気軽に参加できる勉強会であるTechLunchが不定期に開催されており、インターン生も参加させていただきました。 今回は「リモートネイティブ新入社員のリアル」というテーマでイノベーションセンターの新入社員の方々に各々取り組んだ仕事についてお話していただきました。 新入社員が感じたリモート形式のメリット・デメリット、不安に感じることなどをお聞きでき、社員のリアルを知れました。 また、お話を聞きながら、他の社員の方が「〇〇に関してはもう少し深堀りしたほうがいいね」などと発言していらして、意見を発信しやすい環境なのだと感じました。 インターンシップを振り返って 今回のインターンシップを通して、様々なことを学ぶことができました。 Dockerを使った開発の進め方や、Gitを用いたコード管理などの技術的な部分はもちろん勉強になったのですが、それよりも、業務の進め方や業務を行う上での考え方がとても勉強になったと感じています。 作業が詰まったときに素早く相談する大切さ タスクとタスクの間の空き時間や、テスト中の空き時間をいかに利用するか タスクの優先順位、取捨選択、割り振りのスピーディーさ リモートでプロジェクトメンバとのこまめな連絡、簡潔かつ必要な情報の先出し意識の高さ これらを学べました。 また、社員同士の活発な、まめな連絡を見て、意見を発信しやすい環境なのだなと再認識しました。 おわりに 夏季インターンシップの内容や感想について書かせていただきました。 約2週間、OsecTに関する業務に携わらせいただいて、技術的にも成長できました。 また、業務を行う上で必要なスキルを持っているか、足りないスキルや考え方はどのようなものなのかを学ぶことができました。 今後の研究活動などにも活かす事ができるとても有意義な経験をさせていただきました。 NTTコミュニケーションズの皆様、大変お世話になりました。ありがとうございました。 トレーナーからのコメント 田畑さんのトレーナーを務めた鍔木（GitHub: takuma0121 ）です。 まずはインターンお疲れさまでした。 10日間という非常に短い期間でしたが、GitHubやDockerだけでなくパケット解析ツールのZeekなど初めて使うツールを学びつつ、OsecTの実装というアウトプットまで出せました。 また、フルリモートということで対面での業務はできませんでしたが、朝ミーティングやSlackを通じてコミュニケーションしつつ上手く業務に取り組めたのではと考えています。 このインターンの経験を研究や将来の仕事に少しでも活かしていただけると、トレーナーである私も嬉しいです。 インターンお疲れさまでした！

マネージド&セキュリティサービス部 セキュリティサービス部門 インシデントレスポンスチームの濱崎と戸祭です。 今回は、 前回 紹介したビジネスメールサービス「Microsoft Exchange Online」の監査ログについて、の後編となります。 前の記事（ 前編 ）ではログの種類と取得方法について説明しました。 後編ではログを記録しておくための設定方法について説明します。 目次 目次 前編の要約 ログの設定 Exchange Online Powershellへの接続 Unified Audit Log（統合監査ログ）の有効化 Mailbox Audit Log（メールボックス監査ログ）の設定 ログの保持期間の延長 まとめ 前編の要約 前編 では、以下のログの概要と、NTT Comでの調査に最低限必要なログの取得方法を説明しました。 Unified Audit Log（統合監査ログ） AzureADサインインログ Mailbox Audit Log（メールボックス監査ログ） Admin Audit Log（管理者監査ログ） Message Trace（メッセージ追跡） 後編では、これらのログを記録しておくための設定方法を説明します。 ログの設定 前編 で紹介したログは、既定では取られていない可能性があるため、ログを確実に残せるよう設定の確認と変更を推奨します。 またログの保存期間も既定では短いため、保存期間の延長を検討する必要があります。 この節では、Powershellを用いた適切なログ取得設定と保存期間の延長方法について紹介します。 Exchange Online Powershellへの接続 まずExchange Online Powershellに管理者権限をもつユーザでログインします。 > Install-Module -Name ExchangeOnlineManagement > Import-Module ExchangeOnlineManagement > Connect-ExchangeOnline -UserPrincipalName <User Principal Name, メールアドレス等> Unified Audit Log（統合監査ログ）の有効化 Unified Audit Logは、現在では基本的には既定で有効 1 です。 しかしライセンスや過去の設定によっては有効でない場合があるため確認を推奨します。 UnifiedAuditLogIngestionEnabled がTrueになっているかを以下のコマンドで確認します。 > Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled UnifiedAuditLogIngestionEnabled : True Falseになっていた場合、次の方法でTrueにしてください 7 。 > Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true （ただしNTT Com IRチームの検証用環境では上記コマンドの前に Enable-OrganizationCustomization の実行が必要でした。また反映まで数時間待つ必要がありました 8 。 エラーが出る場合はお試しください。） Mailbox Audit Log（メールボックス監査ログ）の設定 Mailbox Audit Logは、設定上では有効になっていても検索ができない、既定では取れない項目があるなど一部わかりにくい箇所があります。 基本的な設定をはじめとした、いくつかのポイントをご紹介します。 組織の既定の設定で監査が無効になっていないかを確認 監査の有効無効は、組織の既定、および各メールボックスごと、各ユーザごとに設定できます。 ただし公式のドキュメント 9 に以下のようにあることから、現在は各メールボックスごとの監査の有効無効の設定は無視され、常に組織の既定の設定が優先されるようです。 Turning off mailbox auditing on by default has the following results: Mailbox auditing is not enabled for new mailboxes and setting the AuditEnabled property on a new or existing mailbox to True will be ignored. Currently, you can't disable mailbox auditing for specific mailboxes when mailbox auditing on by default is turned on in your organization. そのため一番重要になる組織の既定の設定で、メールボックス監査が無効にされていないかを確認します。 > Get-OrganizationConfig |Select-Object -ExpandProperty AuditDisabled False もしTrue（監査が無効）だった場合、以下の方法でFalseにします。 > Set-OrganizationConfig -AuditDisabled $false ユーザごとに監査をバイパスしていないかを確認 組織の既定の設定で監査が有効になっている場合でも、ユーザごとに監査を無効にできます。 以下の方法でこの機能がFalseになっていることを確かめます。 MailboxIdentityとしてユーザ名やメールアドレスを渡します。 > Get-MailboxAuditBypassAssociation -Identity <MailboxIdentity> | Format-List AuditByPassEnabled AuditBypassEnabled : False もしTrue（監査をバイパス）になっていた場合、Falseに切り替えます。 > Set-MailboxAuditBypassAssociation -Identity <MailboxIdentity> -AuditBypassEnabled $false ユーザごとに行う必要があるため、スクリプトで自動化することを推奨します。 監査ログ検索を可能にする 既定でメールボックスの監査は有効になっていますが、公式ドキュメント 9 には以下のように注意書きがあります。 If mailbox auditing already appears to be enabled on the mailbox, but your searches return no results, change the value of the AuditEnabled parameter to $false and then back to $true. つまり監査が有効になっているように見えても、Microsoft 365 コンプライアンスセンターやPowershellコマンドレット等での監査ログ検索ができない場合があります。その際はメールボックスごとの監査の有効無効( AuditEnabled パラメータ)を切り替えて再び有効にすることが必要です。 #有効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true #無効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $false #再び有効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true メールボックスごとに行う必要があるため、スクリプトで自動化することを推奨します。 「高度な監査」を有効化 E5/A5/G5といったライセンスを使用すれば、「高度な監査」を使用してより詳しいログの調査が可能です 10 。 中でも有用なものは、 MailItemsAccessed イベントと SearchQueryInitiated 系イベントです。 MailItemsAccessed イベントはメールの閲覧を記録します。 読まれたメールが特定できる ため、漏洩した情報の特定に利用できます。 SearchQueryInitiated 系イベントは検索内容を記録します。攻撃者がどのような情報を探していたのか、意図をつかみやすくなります。 ただし、単一のメールボックスで1,000イベント/日と大量の監査レコードが生成された場合、そのメールボックスに関する MailItemsAccessed のログ生成が打ち切られるという注意点があります 11 。 「高度な監査」が有効になっているかは、次の手順で確かめることができます 12 。 Microsoft 365 管理センター > ユーザー > アクティブなユーザー > ユーザーをクリック > ライセンスとアプリ から右に出るペインのアプリ欄を見て、Advanced Auditingにチェックが入っていることを確認します。 高度な監査が有効になっている例 メールボックス操作の記録設定 Mailbox Audit Logは、ユーザ種別ごとにどんな操作を記録するか設定できます。 確実に必要なログを残すため確認することを推奨します。 公式ドキュメント 13 では以下の記述があるため、特にメールボックスオーナーについての設定は注意が必要です。 メールボックスオーナーの操作を監査すると、大量のメールボックス監査ログ エントリが生成される可能性があるため、既定では無効となっています。 （なお、NTT Com IRチームの検証環境では最初からメールボックスオーナーの監査が有効化されていたようでした。） ユーザ種別は3つあり、 AuditAdmin , AuditDelegate , AuditOwner です。 ユーザ種別ごとにロギング可能な操作一覧 9 を参考に、少なくとも同ページ表中の * マークが付いているものが有効になっていることを確かめてください。 次のようにして、ロギングされる操作の一覧を表示できます。例として以下ではメールボックスオーナー ( AuditOwner )に関して表示しています。 > Get-Mailbox <identity of mailbox> | Select-Object -ExpandProperty AuditOwner Update MoveToDeletedItems SoftDelete HardDelete UpdateFolderPermissions UpdateInboxRules UpdateCalendarDelegation ApplyRecord MailItemsAccessed Send もしメールボックスオーナーに関して MailItemsAccessed がロギングされない設定であった場合、以下のコマンドで有効にします。 > Set-Mailbox -Identity <identity of mailbox> -AuditOwner @{Add="MailItemsAccessed"} （コマンドでデフォルト設定と完全に同一か確認したり、デフォルト設定に戻したりすることも可能です。本記事のスコープ外なので詳しくは公式ドキュメント 9 を参照してください。） また、前セクションで触れた SearchQueryInitiated 系イベントのロギングをメールボックスオーナーに対して有効化します。 > Set-Mailbox -Identity <identity of mailbox> -AuditOwner @{Add="SearchQueryInitiated"} 以上の操作は全てのユーザのメールボックスに対して行うことが望ましいため、スクリプトでの自動化を推奨します。 ログの保持期間の延長 デフォルトでの保持期間は以下の通りです。 設定を変更する、ライセンスを契約する等でできる限り期間を伸ばしておくのが安心です。 ログ名 デフォルト保持期間 延長方法 UnifiedAuditLog (統合監査ログ) 90日-1年 2 ライセンス契約 *1 MailboxAuditLog (メールボックス監査ログ) 90日 9 AuditLogAgeLimit の値を増やす 13 AdminAuditLog (管理者監査ログ) 90日 3 - （オンプレミス版Exchangeなら可） 6 MessageTrace (メッセージ追跡) 90日 4 - Azure AD サインインログ 30日 5 - 将来のインシデント時にデータが残っていないと取れる対処の選択肢が狭まってしまいます。 以上を参考に、できる限り長期間のログを保持するようにしておくことをお勧めします。 更に長期間ログを保持したい場合、SIEMを使用することを推奨します。ログの活用も容易になります。 まとめ 前編 ではMicrosoft Exchange Online に関するログの種類と取得手順を説明し、後編ではログを記録しておくための設定方法を説明しました。 2つを併せて、来たるインシデントへの備えとしてご活用ください。 ログの分析については、各ログの意味の理解や、大量のログを処理しながらの頻度分析、アノーマリ分析、インテリジェンスを活用しての調査が必要となります。機会があれば別記事で解説したいと思います。 [1] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/turn-audit-log-search-on-or-off?view=o365-worldwide [2] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/audit-log-retention-policies?view=o365-worldwide [3] : https://docs.microsoft.com/en-us/exchange/security-and-compliance/exchange-auditing-reports/view-administrator-audit-log [4] : https://docs.microsoft.com/ja-jp/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results [5] : https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-reports-data-retention [6] : https://docs.microsoft.com/ja-jp/exchange/policy-and-compliance/admin-audit-logging/admin-audit-logging?view=exchserver-2019#admin-audit-log-age-limit [7] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/search-the-audit-log-in-security-and-compliance [8] : https://forum.devolutions.net/topics/31378/how-to-use-powershell-with-office-365-through-rdm [9] : https://docs.microsoft.com/en-us/microsoft-365/compliance/enable-mailbox-auditing?view=o365-worldwide [10] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/advanced-audit?view=o365-worldwide [11] : https://docs.microsoft.com/en-us/microsoft-365/compliance/mailitemsaccessed-forensics-investigations?view=o365-worldwide [12] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/set-up-advanced-audit?view=o365-worldwide [13] : https://docs.microsoft.com/ja-jp/exchange/policy-and-compliance/mailbox-audit-logging/enable-or-disable?view=exchserver-2019 *1 : Unified Audit Log（統合監査ログ）についてはライセンスによって異なり、E5などの上位のライセンスで高度な監査が有効な場合（既定で有効）、一部のRecodeTypeをもつログの保存期間が1年となります 2 。また特別なアドオンライセンスを契約すれば、最大で10年間保持することが可能です 10 。

マネージド&セキュリティサービス部 セキュリティサービス部門 インシデントレスポンスチームの濱崎と戸祭です。 今回は、Microsoft社がMicrosoft 365 (Office 365) 内で提供するビジネスメールサービス「Microsoft Exchange Online」の監査ログについて、不正アクセスの観点でお話します。 本記事は前後編に分かれており、前編ではログの概要と取得について説明します。 後編 ではログを記録しておくための設定について説明します。 はじめに Microsoft Exchange Onlineへの不正アクセスが発生した場合、いつ発生したか、どのアカウントが被害にあったか、どのようなデータが閲覧・持ち出されたか、どのような攻撃の踏み台にされたか、などを明らかにする必要があります。 ところが、Microsoft Exchange OnlineはAzureAD等いくつかのコンポーネントが連携しあって提供されており、調査に必要なログもまとまって管理されていません。また、Microsoft公式ドキュメントでも、どこにどのようなログが保存されているかインシデントレスポンスの観点で体系的にまとめられたものがありません。加えて、GUIでのログ閲覧機能では一部の情報が欠落するなどの問題があることが知られています。 いざというときにこのような調査ができるよう、事前に把握・準備しておくべき次の内容について簡単にまとめて紹介します。 不正アクセス調査に備えて取得すべきログの種類 （前編） ログの取得方法（前編） ログの設定方法（ 後編 ） なお、本記事の内容は、2021年9月執筆時点での公開情報とNTT Com IRチームで検証用に取得したライセンスでの検証結果に基づきます。商用ライセンスのグレードや契約形態によって、一部異なる事実が含まれる可能性があります。また、Microsoft社は不定期に仕様を変更しています。今後も仕様が変わる可能性がある点、ご了承ください。 目次 はじめに 目次 Microsoft Exchange Onlineとは 不正アクセス調査時に有用なログ Microsoft 365のUnified Audit Log (統合監査ログ) Azure Active Direcotryのサインインログ Exchange Onlineの監査ログ Exchange OnlineのMessage Trace ログ （メッセージ追跡ログ） ログ取得 Powershell vs 管理コンソール（ブラウザ）vs API ログ取得実施手順の概要 事前準備 1. 全ユーザに関するログの取得 2. 攻撃に関与した疑いのあるユーザのログ取得 まとめ Microsoft Exchange Onlineとは 　Microsoft Exchange Onlineは、Microsoft社が提供するメールホスティングサービスであり、同社が古くから提供しているMicrosoft Exchange Server機能をクラウド上で提供するものです。構築や運用の難易度が高いExchange Serverの管理から解放されること、また事業の継続性の確保(BCP) や柔軟な働き方を支援するインフラに適していることから、多くの企業に導入されています。 　一方で、攻撃者目線に立つと、世界中のどこからでもアクセス可能なメールサーバの存在は、メールデータの窃取が従来に比べて行いやすくなることを意味します。実際、ニュースや報道においてMicrosoft 365への不正アクセス事例が数多く報告されており、NTT Comにおいても相談数が増えているのが現状です。また、以前にNTT Comの旧技術ブログで紹介したように、ラテラルフィッシング攻撃も問題となっています。これらの攻撃の有無を確認するためにログが重要な情報源となります 1 。 不正アクセス調査時に有用なログ Microsoft Exchange OnlineはMicrosoft 365の一部として提供されています。また、Microsoft 365はAzureADをID管理として利用しているなど、いくつかのコンポーネントが連携しています。それぞれのコンポーネントがログを取得しており、ログの粒度や内容も異なることが、インシデントレスポンスにおけるログ調査を複雑にします 2 。 Microsoft 365, Exchange Online, Azure AD, ログ閲覧できる管理用サイトの関係性の図 上図のように、Azure ADやExchange Online等の各種サービスのログ情報の一部が、左のUnified Audit Logに収集されます。 しかしUnified Audit Logのみを見ればよいわけではありません。完全に同じログが収集されるわけではないためです。 以降では、それぞれのコンポーネントにおけるログサービスの名称や機能のうち特に不正アクセス調査に有用なログを紹介します。 Microsoft 365のUnified Audit Log (統合監査ログ) Microsoft 365が提供する各アプリケーション（Exchange Online, Sharepoint等）の監査ログを統合管理したもの 各アプリのそれぞれのログのうち、 一部が Unified Audit Logに転送される AzureADのサインインログやExchange Onlineの転送ルールの作成等が含まれるため、調査に有用 主に次の3つの方法で閲覧、ダウンロード可能 *1 Microsoft 365 コンプライアンスセンター > ソリューション > 監査 Exchange Online Powershellを利用したダウンロード 3 APIでのダウンロード Unified Audit Logの表示例 Azure Active Direcotryのサインインログ 4 ユーザのサインインに関する記録を提供 サインインに関する、日時、ユーザ名、送信元IPアドレス、サインインに使用したアプリケーション名、ブラウザ名等が記録されている 意図しないサインインかどうかの判定に利用可能 次の3つの方法で閲覧、ダウンロード可能 Azure AD 管理センター 5 > 監査ログ > サインイン Powershellを利用したダウンロード 6 APIを利用したダウンロード Azure AD 管理センターから閲覧可能なサインログ Exchange Onlineの監査ログ 主にMailbox Audit Log(メールボックス監査ログ)と Admin Audit Log(管理者監査ログ)に記録 各メールボックスに対するログインやメールアイテムの削除、受信ルールの追加／削除／変更などのログを提供 メール閲覧、検索のログを提供（「高度な監査」が使用できるライセンスでのみ利用可能） SessionIdを使いログインと操作のログを紐づけ 7 、攻撃者による メール閲覧履歴 や 転送ルールの作成 や削除されたスパムメール送信履歴の調査などに利用可能 主に次の3つの方法で閲覧、ダウンロード可能 Exchange 管理センター > (左下の) 従来のExchange 管理センター> コンプライアンス管理 > メールボックス監査ログのエクスポート、管理者監査ログのエクスポート Exchange Online Powershellを利用したダウンロード 8 , 9 APIを利用したダウンロード Exchange管理センターの監査ログ閲覧／ダウンロード画面 Exchange OnlineのMessage Trace ログ （メッセージ追跡ログ） メールの送受信ログを提供 攻撃者によるメール転送やスパム攻撃の踏み台有無の調査に利用可能 主に次の3つの方法で閲覧、ダウンロード可能 「Exchange管理センター」 -> メールフロー -> メッセージ追跡 Exchange Online Powershellを利用したダウンロード 10 APIを利用したダウンロード 11 Exchange管理センターから閲覧可能なMessage Traceログ ログ取得 推奨するログ取得方法や、実際の手順をコマンドレベルで説明します。 インシデント発生時の初動対応としてのログ保全や、平時に期限切れで消えてしまうログの定期的な保全などにお役立てください。 ただしログを記録しておくための設定をしておかないと、一部取得できないログがあります。設定方法については 後編 で説明するため、そちらも併せて参照することを推奨します。 Powershell vs 管理センター（ブラウザ）vs API ログを取得する手段としていくつかの方法が提供されていますが、NTT ComではPowershellコマンドレットでの取得を推奨しています。 Web の管理センター経由のログダウンロードでは一部のログの欠損が確認されています。その旨通知は出ずログの欠損に気付くことができないため、信頼できるログ取得の観点からは不向きと言えます。 一方でPowershellの場合、ログが欠損せず信頼性の点で優れています。さらにログ取得操作の自動化が容易で、そのため簡易的な操作で多くのログを扱えるログ取得ツールが有志により提供されています。以上の点でPowershellの使用を推奨します。 なお、APIも同様に信頼性と自動化の利点を持ち、ツールやシステムに組み込む際には有用です。しかし単に情報取得に使うには使用方法が複雑であるため、Powershell のほうが使いやすいと考えます。 注意点として、Powershellでたくさんのリクエストを送ると一定時間ロックされる可能性があるため、適切にリクエストレートを制限する必要があります。 ログ取得実施手順の概要 すべてのログをダウンロードすることが望ましいと言えますが、ログのダウンロード数上限やログサイズの観点から、ユーザ数の多い環境では一部のログのみダウンロードすることが現実解と言えます。 ここでは、NTT Comにおける調査に最低限必要なログをダウンロードする方法を紹介します。 なお、大規模テナントの場合、これらの方法でもダウンロード数上限に達し十分なログが取れない場合があります。大規模テナントをご利用されている場合は、SIEMの使用を推奨します。 ログの取得は次の流れで行います。 攻撃に関与したユーザを特定するため、サインインログを中心とした全ユーザに関するログ取得 1の解析により判明した攻撃に関与したユーザの詳細ログ取得 これらのログを取得するため、NTT Comでは次の2つのツールを利用します。これらの使い方について詳細に説明します。 HAWK 12 Office 365 Extractor 13 事前準備 各種ツールの日本語対応 HAWKやOffice 365 Extractorは現時点では日本語に完全対応はしていないためCSVに日本語が出力できません。これを回避するため Powershell console 上で次のコマンドを実行してから各種ツールを実行してください。 function Export-Csv(){ $input | Microsoft.PowerShell.Utility\Export-Csv @args -Encoding UTF8 } なお、一度 Poweshell console を閉じると、上記設定は無効化されます。Powershell console 起動の都度実行してください。 ExchangeOnlineManagement module のインストール Install-Module -Name ExchangeOnlineManagement 1. 全ユーザに関するログの取得 HAWKでのログ取得 次の通りにPowershellでコマンドを打ち、HAWKでログ取得します。 # HAWKのインストール > Install-Module -Name HAWK # HAWKを使う準備 > Import-Module HAWK # テナントの全ユーザについてログ取得 > Start-HawkTenantInvestigation 実行途中で指定したフォルダに、結果のファイルが出力されます。 Office 365 Extractorでのログ取得 Office 365 Extractorをダウンロードした後、スクリプトを実行します。 > .\Office365_Extractor.ps1 特定の種類のログを取得するため、3を入力します。 Following actions are supported by this script: 1 Show available log sources and amount of logging 2 Extract all audit logging 3 Extract group audit logging 4 Extract specific audit logging (advanced mode) 5 ReadMe 6 Quit Select an action: 3 取得したいログ種別としてAzureを選択するため、2を入力します。 1: Extract all Exchange logging 2: Extract all Azure logging 3: Extract all Sharepoint logging 4: Extract all Skype logging 5: Back to menu Select an action: 2 取得対象とするユーザとして全ユーザを指定するため、1を入力します。 Would you like to extract log events for [1]All users or [2]Specific users >: 1 Extracting the Unified Audit Log for all users... 取得期間を入力します。Enterキーだけを押すと本日から90日間前までが設定されます。 Please enter start date (format: yyyy-MM-dd) or ENTER for maximum 90 days: Please enter end date (format: yyyy-MM-dd) or ENTER for today: 取得間隔を分単位で入力します。 ログ取得に利用しているExchangeOnlinePowershellが一度に5,000件までしか取得できないため、細かく分割して取得することでその制限を回避するための設定です。 短くしすぎると、取得間隔を短くしてのリトライが発生して効率が落ちます。 ログが少ない環境では14400分（10日間）など長くすると早く終わります。 Recommended interval: 60 Lower the time interval for environments with a high log volume Please enter a time interval or ENTER for 60: 14400 この後、認証が求められますが、多要素認証を設定している場合は、最初に出る認証画面はキャンセルを押してください。次に別な認証画面が出るので、そちらでログインしてください。ログ取得が実行され、結果はファイルとしてカレントフォルダに出力されます。 2. 攻撃に関与した疑いのあるユーザのログ取得 全ユーザに関するログの分析により判明した（もしくはすでに明らかになっている）攻撃に関与した疑いのある特定ユーザごとに、より詳細なログを取得します。 可能であれば全ユーザに対して詳細なログを取得することが望ましいですが、ユーザ数が多い場合は現実的でないため、攻撃者の関与が疑われるメールアカウントに限定して取得しています。 HAWKでのログ取得 > Start-HawkUserInvestigation <ユーザのメールアドレス> Office 365 Extractorでのログ取得 スクリプトを実行します。 > .\Office365_Extractor.ps1 全種別のログを取得するため、2を入力します。 Following actions are supported by this script: 1 Show available log sources and amount of logging 2 Extract all audit logging 3 Extract group audit logging 4 Extract specific audit logging (advanced mode) 5 ReadMe 6 Quit Select an action: 2 取得対象として特定ユーザを指定するため、2を入力します。 Would you like to extract log events for [1]All users or [2]Specific users >:2 ログを取得したいユーザのメールアドレスをカンマ区切りで入力します。 Provide accounts that you wish to acquire, use comma separated values for multiple accounts, example (user1@example.com,user2@example.com) >: user1@example.com, user2@example.com これ以降の手順はテナントの全ユーザのログ取得時と同様です。 MessageTraceログの取得 最後に、攻撃者の関与が疑われる特定ユーザに関して、MessageTraceからメールの送受信ログを取得します。 本手順により最大で過去90日、50,000件のログが取得可能です。(過去10日以内の最大1,000件のデータで十分でしたら Get-MessageTrace コマンドレットを使用する方がより簡単です。) まずExchange Online Powershellに接続します。管理者権限のあるアカウントを使用してください。 > Import-Module ExchangeOnlineManagement > Connect-ExchangeOnline -UserPrincipalName <User Principal Name, メールアドレス等> ログ生成クエリを発行します。 (例では -SenderAddress で送信アドレスを指定しています。 -RecipientAddress を使えば受信アドレスを指定できます。) > Start-HistoricalSearch -ReportTitle "test" -StartDate 2019/12/1 -EndDate 2020/1/20 -ReportType MessageTrace -SenderAddress adminuser1@example.com JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test NotStarted 0 タスクの進行状況を確認します。 StatusがNotStartedになっているためまだ開始されていません。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test NotStarted 0 タスクの進行状況を確認します。 StatusがInProgressになっているため実行中です。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test InProgress 0 タスクの進行状況を確認します。 StatusがDoneになっているため実行完了しています。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test Done 2 JobIdを指定し詳細情報を確認します。下記のFileUrlに記載のURLに、ブラウザでアクセスしログをダウンロードできます。 > Get-HistoricalSearch -JobId 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX | Format-List (...略...) FileUrl : https://admin.protection.outlook.com/ExtendedReport/Download?Type=OnDemandReport&RequestID=7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX ReportStatusDescription : Complete – Ready for download ReportType : MessageTrace (...略...) まとめ 本記事では Microsoft Exchange Online 関係のログの概要と、ログ取得方法を説明しました。 どのようなログが取れるかを知っておくことは、いざというとき有効活用するために必要不可欠です。 その一助となるべく公開された本記事をご活用いただけると幸いです。 冒頭で述べたとおり、 後編 ではログを記録しておくための設定について説明します。よろしければそちらもご覧ください。 https://developer.ntt.com/ja/blog/b097ce00-8942-43c6-bad4-842087f8dc6b ↩ https://blogs.technet.microsoft.com/junichia/2015/10/28/office-365-azure-adintuneazure-rms/ ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-unifiedauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-sign-ins ↩ https://aad.portal.azure.com/ ↩ https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-powershell-reporting ↩ https://techcommunity.microsoft.com/t5/security-compliance-and-identity/contextualizing-attacker-activity-within-sessions-in-exchange/ba-p/308710 ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-mailboxauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-adminauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/get-messagetrace?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/previous-versions/office/developer/o365-enterprise-developers/jj984335(v=office.15) ↩ https://github.com/Canthv0/hawk ↩ https://github.com/PwC-IR/Office-365-Extractor ↩ *1 : 他にも複数のダウンロード方法が提供されています。詳しくはMicrosoft社にお問い合わせください。

はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 ( @Mahito ) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト ( The official YAML Web Site ) ではこう書かれています。 YAML is a human friendly data serialization standard for all programming languages. また、Wikipedia ( YAML - Wikipedia ) では初期の意味と現在の意味が違うと書いてありました。 YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語じゃない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。 現在の最新バージョンは 1.2 で 12 年近く更新されていません。 ( 最後のパッチは 2009-10-01 ) 表記方法 階層構造の表現 YAML はインデントを使い階層構造で内容を表現します。ただし、 インデントにはタブが使えずスペースのみが使えます 。（インデントはスペース 2 個単位ですることが多いそうです） 始まりと終わり YAML ドキュメントは 任意 で --- から開始して、 ... で終わらせることができます。 これは、YAML 形式の一部で、ドキュメントの最初と最後を示し、これらを用いることで 1 つのファイル内に複数の YAML ドキュメントを埋め込むことができます。 --- # やることリスト（ブロック形式） - ブログを書く - イベントの企画 - 技術調査・検証 ... --- # 買い物リスト（インライン形式） [ トマト, 卵, サラダ油 ] 1 つのドキュメント内に複数の YAML ドキュメントが埋め込まれている場合、プログラミング言語によっては load / safe_load では 1 つの YAML ドキュメントしか読めない、またはそもそも読み込みできないものがあります。 ( Ruby ) では複数のうち先頭の 1 つの YAML ドキュメントしか読めません。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .safe_load(yml) end # => ["ブログを書く", "イベントの企画", "技術調査・検証"] Python では yaml.composer.ComposerError: expected a single document in the stream が返されます。 import yaml with open ( 'sample.yml' ) as f: docs = yaml.safe_load(f) for doc in docs: print (doc) # => yaml.composer.ComposerError: expected a single document in the stream 1 つのドキュメント内に複数の YAML ドキュメントがあるファイル読み込む際は load_stream ( Ruby )や load_all ( Python ) を使うとまとめて読むことができます。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .load_stream(yml) end # => [["ブログを書く", "イベントの企画", "技術調査・検証"], ["トマト", "卵", "サラダ油"]] なお、 --- を "directives end"、 ... を "document end" と呼ぶそうですが、わかりにくいということで、 --- を YAML 1.1 で使われいた "document start" という名前に戻そうという RFC が上がっています。 私は --- が YAML に書かれているのを見たことがありますし、何なら使ってもいましたが、「YAML の先頭にある記号でなくても良い」程度にしか意識してきていませんでした。さらに、 ... はまったく見たことがなかったので、今回調べて初めて知りました。 コメント 行頭、もしくはスペースの後に番号記号 "#" を指定すると、その後はコメントになります。 # 行頭コメント [ トマト, 卵, サラダ油 ] # これもコメント リスト - を並べることでリスト表現が可能です。 --- # 果物一覧 - りんご - みかん - いちじく - もも 上記はブロック形式ですが、インデントを使わずにインライン形式で [..., ..., ] と表現することもできます。 --- # 果物一覧 [ りんご, みかん, いちじく, もも ] 連想配列 key: value とすることで連想配列の表現が可能です。 --- # 果物と色の組み合わせ一覧 りんご : 赤 みかん : オレンジ いちじく : 白と赤 もも : ピンク # => {"りんご" => "赤", "みかん" => "オレンジ", "いちじく" => "白と赤", "もも" => "ピンク"} リスト同様にインライン形式で {key1: value1, key2: value2, } と表現することもできます。 { りんご : 赤, みかん : オレンジ, いちじく : 白と赤, もも : ピンク } key:value と : の後ろにスペースを空けないと、文字として扱われてしまいます。 key:value # => "key:value" また、 : のあとのスペースもしくは改行はマッピングに利用されるので次のような c: という表現はエラーとなります。 windows_drive : c: # => (<unknown>): mapping values are not allowed in this context at line 1 column 17 (Psych::SyntaxError) マッピング以外の意図で : を利用する際は、 : の後ろにスペースや改行をいれない、もしくは '' や "" で括れば利用できます。 windows_path : c:\windows c_drive : 'c:' d_drive : "d:" # => {"windows_path"=>"c:\\windows", "c_drive"=>"c:", "d_drive"=>"d:"} "" ではエスケープを使用できる点が、 '' との違いです。 single quote : 'エスケープが使えません\n' double_quote : "エスケープが使えます \n " # => {"single quote"=>"エスケープが使えません\\n", "double_quote"=>"エスケープが使えます\n"} 複雑なキーマッピング YAML では "? " ( ? とスペース)を使うと複雑なキーを生成できます。 (出典) Example 2.11. Mapping between Sequences ? - Detroit Tigers - Chicago cubs : - 2001-07-23 # => {["Detroit Tigers", "Chicago cubs"]=>[#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>]} 上の ["Detroit Tigers", "Chicago cubs"] がキー、下の 2001-07-23 が Value となります。 同様に Key に連想配列も指定可能です。 ? { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {{"New York Yankees"=>"Atlanta Braves"}=>[#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>]} ちなみに "? " を外すと下の : 以下は無視されます。 { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {"New York Yankees"=>"Atlanta Braves"} ? を使うことで value を null にした連想配列の作成も可能です。 (出典) Example 2.25. Unordered Sets --- ? Mark McGwire ? Sammy Sosa ? Ken Griff # => {"Mark McGwire"=>nil, "Sammy Sosa"=>nil, "Ken Griff"=>nil} このあたりも YAML の公式ドキュメントを見て初めて知った機能です。 連想配列の key に配列や連想配列を利用したり、連想配列の value を null にするなど、今まで使ったことがない機能ですが知っておくといつの日にか使う機会が訪れるやもしれませんね。 Bool の扱い Bool型値 (True/False) は複数形式で指定可能です。 a : yes b : no c : True d : TRUE e : false # => {"a"=>true, "b"=>false, "c"=>true, "d"=>true, "e"=>false} 連想配列のキーに yes や true , no などを使うと想定しない動きをするので注意が必要です。 yes : "We can" # => {true=>"We can"} もし先頭を yes にする場合は文字として設定する必要があります。 "yes" : "We can" # => {"yes"=>"We can"} 複数行に分けた表現 文字列は、 | または > を使用して複数行に分けることができます。 | を使用して複数行に分けた場合には、改行と、末尾にあるスペースが含まれます。 pipe_lines : | 複数行の文章は '|' を使うことで 楽に書けます。　 # => {"pipe_lines"=>"複数行の文章は\n'|' を使うことで\n楽に書けます。　\n"} > を使うと改行を折り返してスペースに置き換えます。 long_text : > 長い文章は '>' を使うことで 1行で書けます # => {"long_text"=>"長い文章は '>'を使うことで 1行で書けます\n"} どちらの場合もインデントは無視されます。 > を使う場合で改行をしたいときは以下の2つを用いて改行できます。 改行だけの空白行 インデント後に値を記入 long_text_lines : > a b c d e f # => {"long_text_lines"=>"a b\nc d\n e\nf\n"} | や > の機能は知っていましたが、 > の改行で「インデント後に値を記入」は知らない機能でした。 この機能はインデントを含めた改行になるのでちょっと使い方が限られますが知っておくと便利な仕様ですね。 タグと型 YAML は型を明示していない場合、暗黙的な型付けがされます。明示的な型付けは ! のシンボルを使ったタグで示されます。 date : 2021-09-02 not-date : !!str 2021-09-02 # => { # "date"=>#<Date: 2021-09-02 ((2459460j,0s,0n),+0s,2299161j)>, # "not-date"=>"2021-09-02"} デフォルトのタグ URI は tag:yaml.org,2002: です。その中で定義されている型のタグは以下のとおりです。 Collection Types map omap pairs set seq Scalar Types binary bool float int merge (省略記法 << ) null str timestamp value yaml 参照 ： Language-Independent Types for YAML™ Version 1.1 タグの URI を明示的に切り替える場合は %TAG ! tag:hoge.com,2002: のように設定します。 上記のようにデフォルトで定義されているタグの呼び出しは !!str のようにエクスクラメーションマーク 2 つ ( !! ) , アプリケーション特有のローカルタグの呼び出しはエクスクラメーションマーク 1 つ ( ! ) と別れています。 例: omapを指定 --- !!omap - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => {"yesterday"=>"2021-09-01", "today"=>"2021-09-02", "tomorrow"=>"2021-09-03"} 例: omapなし --- - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 例: mapを指定 --- !!map - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 余談 1.10 など末尾に 0 が入る数字を明示的に表現するためには文字にする必要があります。 !!float 型では末尾の 0 が表示されないので注意が必要です。 --- - 1.10 - !!float 1.10 - '1.10' # => [1.1, 1.1, "1.10"] タグと型の機能も全く知らない機能でした。 型の機能は調べている中で便利だと感じたのでこれから使っていきたい機能です。 アンカーとエイリアス YAMLは & でアンカーを設定し、 * で参照が可能です。さらに << もしくは !!merge を使うことで、参照先の値の変更も可能です。 --- !!omap - default : &default user : root password : password db_url : localhost:3306 - development : *default - production : <<: *default db_url : production:3306 # => {"default"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "development"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "production"=>{"user"=>"root", "password"=>"password", "db_url"=>"production:3306"}} 上記の例では default というアンカーを設定し、development はそのまま参照、poroduction は db_url を変更をしています。 エイリアスとアンカーも見たことはあるけどうまく使えてなかった機能です。 今回調べたことで理解が深まったので今後は使っていきたいです。 YAMLの今後 ここまで紹介してきた現在のバージョンは "YAML 1.2 - 3rd Edition, Patched at 2009-10-01" です。 このバージョンは 12 年近く更新されていませんでしたが、今年の 5 月に突然次期バージョンへのRFCが始まっています。 YAML Spec RFCs GitHub 上で Template をベースに PR 形式で RFC を受け付けているので、興味があればリポジトリを覗いてみて、提案があれば RFC を書いてPRをしてみてはいかがでしょう。 まとめ 普段何気なく使っている YAML ですが、まだ知らない、うまく使えていない機能がありました。 この記事では YAML のすべてを紹介できてはいませんが、もしこの記事を読んで YAML に興味を持っていただけたのであれば、一度 YAML の公式ページ を読んでみることをおすすめします。 また、YAML の新しいバージョンが動き出しているので、そちらも興味があればチェックしてみてはいかがでしょう。 参考 YAML Ain’t Markup Language (YAML™) Version 1.2 YAML - Wikipedia (英語) YAML - Wikipedia (日本語) YAML 構文 - Ansible Document Language-Independent Types for YAML™ Version 1.1

はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 ( @Mahito ) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト ( The official YAML Web Site ) ではこう書かれています。 YAML is a human friendly data serialization standard for all programming languages. また、Wikipedia ( YAML - Wikipedia ) では初期の意味と現在の意味が違うと書いてありました。 YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語じゃない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。 現在の最新バージョンは 1.2 で 12 年近く更新されていません。 ( 最後のパッチは 2009-10-01 ) 表記方法 階層構造の表現 YAML はインデントを使い階層構造で内容を表現します。ただし、 インデントにはタブが使えずスペースのみが使えます 。（インデントはスペース 2 個単位ですることが多いそうです） 始まりと終わり YAML ドキュメントは 任意 で --- から開始して、 ... で終わらせることができます。 これは、YAML 形式の一部で、ドキュメントの最初と最後を示し、これらを用いることで 1 つのファイル内に複数の YAML ドキュメントを埋め込むことができます。 --- # やることリスト（ブロック形式） - ブログを書く - イベントの企画 - 技術調査・検証 ... --- # 買い物リスト（インライン形式） [ トマト, 卵, サラダ油 ] 1 つのドキュメント内に複数の YAML ドキュメントが埋め込まれている場合、プログラミング言語によっては load / safe_load では 1 つの YAML ドキュメントしか読めない、またはそもそも読み込みできないものがあります。 ( Ruby ) では複数のうち先頭の 1 つの YAML ドキュメントしか読めません。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .safe_load(yml) end # => ["ブログを書く", "イベントの企画", "技術調査・検証"] Python では yaml.composer.ComposerError: expected a single document in the stream が返されます。 import yaml with open ( 'sample.yml' ) as f: docs = yaml.safe_load(f) for doc in docs: print (doc) # => yaml.composer.ComposerError: expected a single document in the stream 1 つのドキュメント内に複数の YAML ドキュメントがあるファイル読み込む際は load_stream ( Ruby )や load_all ( Python ) を使うとまとめて読むことができます。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .load_stream(yml) end # => [["ブログを書く", "イベントの企画", "技術調査・検証"], ["トマト", "卵", "サラダ油"]] なお、 --- を "directives end"、 ... を "document end" と呼ぶそうですが、わかりにくいということで、 --- を YAML 1.1 で使われいた "document start" という名前に戻そうという RFC が上がっています。 私は --- が YAML に書かれているのを見たことがありますし、何なら使ってもいましたが、「YAML の先頭にある記号でなくても良い」程度にしか意識してきていませんでした。さらに、 ... はまったく見たことがなかったので、今回調べて初めて知りました。 コメント 行頭、もしくはスペースの後に番号記号 "#" を指定すると、その後はコメントになります。 # 行頭コメント [ トマト, 卵, サラダ油 ] # これもコメント リスト - を並べることでリスト表現が可能です。 --- # 果物一覧 - りんご - みかん - いちじく - もも 上記はブロック形式ですが、インデントを使わずにインライン形式で [..., ..., ] と表現することもできます。 --- # 果物一覧 [ りんご, みかん, いちじく, もも ] 連想配列 key: value とすることで連想配列の表現が可能です。 --- # 果物と色の組み合わせ一覧 りんご : 赤 みかん : オレンジ いちじく : 白と赤 もも : ピンク # => {"りんご" => "赤", "みかん" => "オレンジ", "いちじく" => "白と赤", "もも" => "ピンク"} リスト同様にインライン形式で {key1: value1, key2: value2, } と表現することもできます。 { りんご : 赤, みかん : オレンジ, いちじく : 白と赤, もも : ピンク } key:value と : の後ろにスペースを空けないと、文字として扱われてしまいます。 key:value # => "key:value" また、 : のあとのスペースもしくは改行はマッピングに利用されるので次のような c: という表現はエラーとなります。 windows_drive : c: # => (<unknown>): mapping values are not allowed in this context at line 1 column 17 (Psych::SyntaxError) マッピング以外の意図で : を利用する際は、 : の後ろにスペースや改行をいれない、もしくは '' や "" で括れば利用できます。 windows_path : c:\windows c_drive : 'c:' d_drive : "d:" # => {"windows_path"=>"c:\\windows", "c_drive"=>"c:", "d_drive"=>"d:"} "" ではエスケープを使用できる点が、 '' との違いです。 single quote : 'エスケープが使えません\n' double_quote : "エスケープが使えます \n " # => {"single quote"=>"エスケープが使えません\\n", "double_quote"=>"エスケープが使えます\n"} 複雑なキーマッピング YAML では "? " ( ? とスペース)を使うと複雑なキーを生成できます。 (出典) Example 2.11. Mapping between Sequences ? - Detroit Tigers - Chicago cubs : - 2001-07-23 # => {["Detroit Tigers", "Chicago cubs"]=>[#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>]} 上の ["Detroit Tigers", "Chicago cubs"] がキー、下の 2001-07-23 が Value となります。 同様に Key に連想配列も指定可能です。 ? { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {{"New York Yankees"=>"Atlanta Braves"}=>[#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>]} ちなみに "? " を外すと下の : 以下は無視されます。 { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {"New York Yankees"=>"Atlanta Braves"} ? を使うことで value を null にした連想配列の作成も可能です。 (出典) Example 2.25. Unordered Sets --- ? Mark McGwire ? Sammy Sosa ? Ken Griff # => {"Mark McGwire"=>nil, "Sammy Sosa"=>nil, "Ken Griff"=>nil} このあたりも YAML の公式ドキュメントを見て初めて知った機能です。 連想配列の key に配列や連想配列を利用したり、連想配列の value を null にするなど、今まで使ったことがない機能ですが知っておくといつの日にか使う機会が訪れるやもしれませんね。 Bool の扱い Bool型値 (True/False) は複数形式で指定可能です。 a : yes b : no c : True d : TRUE e : false # => {"a"=>true, "b"=>false, "c"=>true, "d"=>true, "e"=>false} 連想配列のキーに yes や true , no などを使うと想定しない動きをするので注意が必要です。 yes : "We can" # => {true=>"We can"} もし先頭を yes にする場合は文字として設定する必要があります。 "yes" : "We can" # => {"yes"=>"We can"} 複数行に分けた表現 文字列は、 | または > を使用して複数行に分けることができます。 | を使用して複数行に分けた場合には、改行と、末尾にあるスペースが含まれます。 pipe_lines : | 複数行の文章は '|' を使うことで 楽に書けます。　 # => {"pipe_lines"=>"複数行の文章は\n'|' を使うことで\n楽に書けます。　\n"} > を使うと改行を折り返してスペースに置き換えます。 long_text : > 長い文章は '>' を使うことで 1行で書けます # => {"long_text"=>"長い文章は '>'を使うことで 1行で書けます\n"} どちらの場合もインデントは無視されます。 > を使う場合で改行をしたいときは以下の2つを用いて改行できます。 改行だけの空白行 インデント後に値を記入 long_text_lines : > a b c d e f # => {"long_text_lines"=>"a b\nc d\n e\nf\n"} | や > の機能は知っていましたが、 > の改行で「インデント後に値を記入」は知らない機能でした。 この機能はインデントを含めた改行になるのでちょっと使い方が限られますが知っておくと便利な仕様ですね。 タグと型 YAML は型を明示していない場合、暗黙的な型付けがされます。明示的な型付けは ! のシンボルを使ったタグで示されます。 date : 2021-09-02 not-date : !!str 2021-09-02 # => { # "date"=>#<Date: 2021-09-02 ((2459460j,0s,0n),+0s,2299161j)>, # "not-date"=>"2021-09-02"} デフォルトのタグ URI は tag:yaml.org,2002: です。その中で定義されている型のタグは以下のとおりです。 Collection Types map omap pairs set seq Scalar Types binary bool float int merge (省略記法 << ) null str timestamp value yaml 参照 ： Language-Independent Types for YAML™ Version 1.1 タグの URI を明示的に切り替える場合は %TAG ! tag:hoge.com,2002: のように設定します。 上記のようにデフォルトで定義されているタグの呼び出しは !!str のようにエクスクラメーションマーク 2 つ ( !! ) , アプリケーション特有のローカルタグの呼び出しはエクスクラメーションマーク 1 つ ( ! ) と別れています。 例: omapを指定 --- !!omap - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => {"yesterday"=>"2021-09-01", "today"=>"2021-09-02", "tomorrow"=>"2021-09-03"} 例: omapなし --- - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 例: mapを指定 --- !!map - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 余談 1.10 など末尾に 0 が入る数字を明示的に表現するためには文字にする必要があります。 !!float 型では末尾の 0 が表示されないので注意が必要です。 --- - 1.10 - !!float 1.10 - '1.10' # => [1.1, 1.1, "1.10"] タグと型の機能も全く知らない機能でした。 型の機能は調べている中で便利だと感じたのでこれから使っていきたい機能です。 アンカーとエイリアス YAMLは & でアンカーを設定し、 * で参照が可能です。さらに << もしくは !!merge を使うことで、参照先の値の変更も可能です。 --- !!omap - default : &default user : root password : password db_url : localhost:3306 - development : *default - production : <<: *default db_url : production:3306 # => {"default"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "development"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "production"=>{"user"=>"root", "password"=>"password", "db_url"=>"production:3306"}} 上記の例では default というアンカーを設定し、development はそのまま参照、poroduction は db_url を変更をしています。 エイリアスとアンカーも見たことはあるけどうまく使えてなかった機能です。 今回調べたことで理解が深まったので今後は使っていきたいです。 YAMLの今後 ここまで紹介してきた現在のバージョンは "YAML 1.2 - 3rd Edition, Patched at 2009-10-01" です。 このバージョンは 12 年近く更新されていませんでしたが、今年の 5 月に突然次期バージョンへのRFCが始まっています。 YAML Spec RFCs GitHub 上で Template をベースに PR 形式で RFC を受け付けているので、興味があればリポジトリを覗いてみて、提案があれば RFC を書いてPRをしてみてはいかがでしょう。 まとめ 普段何気なく使っている YAML ですが、まだ知らない、うまく使えていない機能がありました。 この記事では YAML のすべてを紹介できてはいませんが、もしこの記事を読んで YAML に興味を持っていただけたのであれば、一度 YAML の公式ページ を読んでみることをおすすめします。 また、YAML の新しいバージョンが動き出しているので、そちらも興味があればチェックしてみてはいかがでしょう。 参考 YAML Ain’t Markup Language (YAML™) Version 1.2 YAML - Wikipedia (英語) YAML - Wikipedia (日本語) YAML 構文 - Ansible Document Language-Independent Types for YAML™ Version 1.1

こんにちは、イノベーションセンターの三島です。 本記事では、次世代の監視技術として期待されるTelemetry技術についてご紹介します。 この記事について 本記事では下記の3点を共有します。 従来の監視技術が抱える課題とTelemetryの可能性 Telemetryの技術概要と、各社の実装状況 NTT Comのネットワーク上で検証し得られた知見と、期待されるユースケース 従来の監視技術が抱える課題 ネットワーク運用においては、障害検知やパフォーマンス分析のため監視技術が重要となります。 従来のネットワークでは、SNMP（Simple Network Management Protocol）と呼ばれる技術が広く利用されています。 SNMPの仕組みを図1に示します。SNMPはUDPベースなネットワーク監視技術です。データモデルはMIB（Management Information Base）と呼ばれるデータベースに定義されており、ベンダ共通の標準MIBと固有の拡張MIBが存在します。 SNMPの情報取得者をSNMP Manager、情報発行者をSNMP Agentと呼びます。情報の取得手法として、SNMP Managerがリクエストベースに情報を取得するPollingと、SNMP Agentがトリガーベースに情報を送信するTrapが存在します。 従来のSNMPが抱える課題として、下記の3点が挙げられます。 高負荷な処理構造 マルチベンダ環境における管理の煩雑さ N対N構成での規模性の限界 1.高負荷な処理構造について図2に示します。 ネットワーク監視ではトラフィック量や機器の負荷情報（Memory・CPU・温度等）の取得が求められます。しかしSNMPのPollingはリクエストベースであるため、高精細な情報を取得するために間隔を狭めると、CPU負荷の増大と処理時間の増加が課題となります。 2.マルチベンダ環境における管理の煩雑さについて図3に示します。 SNMPでは標準MIBが乏しく、例えばCPU使用率等のパラメータを取得できない課題が存在します。 そのため、マルチベンダな環境で同じ情報を取得するためには、機種ごとに固有な拡張MIBのOID（Object ID）を指定する必要があり、管理コストが増大します。 3.N対N構成での規模性の限界について図4に示します。 大規模なネットワークでは、データ利活用のため複数のデータ利用者が同じ機器の情報を取得することが考えられます。（例えば利用者Aはトラフィック量を可視化のために取得し、利用者Bはインターフェース状態をDown検知のために取得するなど） SNMPではAgentとManagerを1対1のUDPで接続して監視するため、N対N構成ではAgent/Managerの組み合わせ分のUDP接続が必要となり、受信側で処理可能なメッセージに限界が生じます。 また、送信先・監視先ごとに異なる値を取得したい場合、組み合わせに応じてSNMP Agent/Managerに定義する必要があり、管理コストが増大します。 まとめとして、SNMPは下記3種の課題を抱えています。 高負荷なプロトコル構造による取得可能な情報精度の低下と、リアルタイム性の損失 標準MIBの乏しさによるマルチベンダ環境における管理の煩雑さ N対N構成構築時の規模性の課題 これらを解決する監視技術として、Telemetry技術が期待されています。 Telemetryについて Telemetryは次世代のネットワーク監視技術であり、各社による検討や実装・OpenConfig等による標準化が進められています。 Telemetryは、一般的には下記3つの特徴を持つよう設計されています。 SNMPと比較し低負荷なプロトコル設計による高精細でリアルタイムな情報取得 OpenConfigによるベンダフリーな情報取得 Pub/Subモデルの導入が容易な設計による高い規模性 これらの特徴から、前節で挙げたSNMPの課題を解決する技術として期待されています。 Telemetryは、Pub/Subモデルと呼ばれるデータの送受信モデルを採用しています。 Pub/Subモデルについて図5に示します。 Pub/Subモデルは下記3つの要素から構成されます。 Publisher: 発行者 (送信者)。メッセージを発行する Broker: 仲介者。メッセージを仲介する Subscriber: 購読者 (受信者)。メッセージを取得し活用する Pub/Subモデルの利点として、① メッセージの送信者・受信者がお互いを直接認識する必要がなく、非同期かつ疎結合である点、②Brokerを介して1対N、N対N構成が取れるため、規模性の高い点 が挙げられます。情報はTopicという属性で管理され、Publisher・SubscriberはTopicを指定することにより情報を送信・受信します。 図6にTelemetryのパイプライン構成を示します。 Telemetryパイプラインは下記の要素から構成されます。 Publisher: データの発行元であるネットワーク機器 Broker: Pub/Subの多重化を行う仲介役 Subscriber: データの受け取り・利用をするアプリケーション Pub/Subモデルの利点は失われますが、上記の構成以外にPublisherとSubscriberを直結する構成も可能です。 以降でそれぞれの要素について解説します。 Publisher Publisherはメッセージの発行者であり、下記の3つの要素から構成されます。 監視対象となるネットワーク機器 監視対象機器とCollectorを繋ぐTransport部分 Publisherからデータを受信するCollector 監視対象機器に関する概念として、情報モデルと接続方式の分類についてご説明します。 機器の情報モデルには、主にOpenConfig・ベンダネイティブの2種が存在します。OpenConfigはベンダニュートラルな利用を想定して標準化が進められているネットワークコンフィグのモデルであり、YANGに従い定義されています。一方ベンダネイティブは製品ごとに固有の情報モデルであり、一般的にOpenConfigよりも対応状況が良く、扱うことのできる情報も豊富な傾向があります。 機器が発行する情報は、Sensor-Pathと呼ばれるデータパスにより予め指定されており、決められた間隔でメッセージを発行し、Collectorへと送信します。 下記にSenrsor-Pathの例を示します。Sensor-PathはYANGのツリー構造に合わせて情報を取得するためのデータパスであり、SNMPにおけるOIDに近い概念です。 OpenConfig: Interfaceに関する情報全般（Configuration/State/Statistic含む） “/interfaces/” OpenConfig: Interfaceごとの入力パケットカウンタ（単位: byte） “/interfaces/interface/state/counters/in-octets” OpenConfig: xe-0/0/0の入力パケットカウンタ（単位: byte） “/interfaces/interface[name='xe-0/0/0']/state/counters/in-octets” Juniper ベンダネイティブ: Interfaceに関する情報全般 “/junos/system/linecard/interface/” 例のように、深いパスを指定することで取得する情報を細かく指定できます。 また、OpenConfigとベンダネイティブでは同じ情報を取得する場合でも異なるパスを指定する必要があります。 2021年8月時点の実装では、同じOpenConfigでもベンダにより対応状況が異なるため、各社のドキュメントを確認し取得するSensor-Pathを決める必要があります。 次に接続方式の違いについてご説明します。Telemetryでは、情報を発行するPublisherと受け取るCollectorの接続方向により、Dial-InとDial-Outの接続方式が存在します。図7にそれぞれぞれの概念を示します。 Dial-InはCollectorがPublisherに接続する手法です。利点としてはgRPCによる自動化を行っているネットワークの場合、機器に設定されたgNMIを利用して情報を取得できるため、Telemetry用追加設定の不要な点が挙げられます。 一方Dial-OutはPublisherがCollectorに接続する手法です。利点としてはCollector側が監視するPublisherのリストを管理する必要がないためCollectorをステートレスに設計可能であり、Dial-Inに比べて規模性が高い点や、Publisher側にもACLによる制御が不要となる点が挙げられます。 上記より、特別な理由がない場合は管理コストを考慮しDial-Outを採用することをお勧めします。ただし、例えばgRPCによる運用自動化を行っているネットワークなどでは、Dial-InのTelemetryが容易に導入可能な場合もあります。また、2021年8月時点では、ベンダによりDial-In/Dial-Outの対応状況が異なるため、注意が必要です。 次にTransport部分について説明します。Transportは監視対象デバイスとCollectorを繋ぐ転送の役割を持ちます。 TransportはEncodingとEncapsulationの要素から成り立ちます。 Encoding: メッセージの形式。JSON、GPBなどから選択可能 Encapsulation: 通信形式。TCP/UDPやgRPC、NETCONFなどを選択可能 SNMPはUDPによる通信のみを採用していましたが、Telemetryではメッセージをどのような形式で記述し、どのような通信形式で送るかを決めることができます。取得したい情報の性質や、運用で既に採用しているプロトコルなどを考慮しながら決めることをお勧めします。 CollectorはPublisherが発行したメッセージを受信する役割を持ちます。2021年8月時点の主なCollector実装を下記の表にご紹介します。 ベンダ OSS実装 ベンダ純正実装 ※Subscriber機能も兼ねる Arista ockafka Openconfigbeat Arista CloudVision Cisco Pipeline Telegraf/Fluentd等の専用Plugin Crosswork Health Insights Juniper Jtimon Telegraf/Fluentd等の専用Plugin Paragon Insights SONiC gnxi（単発で取得するCLIツール） gNMIc - 上記でご紹介したベンダ純正実装は、単体のCollectorではなくSubscriberとしての可視化や自動化の機能を備えています。 Collectorごとに特徴や存在する機能が異なるため、例えばPublisherのグループ化やKafkaとの連携など、必要な機能を考慮し選定することをお勧めします。 Broker Brokerはメッセージの仲介者であり、Message Queueが該当します。 Message Queueはメッセージを中継する要素であり、主な実装としてはApache Kafkaや、Public CloudにおけるCloud Pub/Sub・SQSなどが挙げられます。 一般的な実装では、クラスタリングやミラーリングなど、冗長化を行う仕組みを持つことが多いです。図8に一般的なBrokerのMessage Queue的な役割を示します。 Publisherが発行するメッセージにはTopicとデータが含まれています。Brokerは受信したメッセージをTopicごとのキューに格納した後、Subscriberからの購読に応じてメッセージを送信します。 Subscriber Subscriberはメッセージの受信者であり、データを受け取り利用する要素です。 Subscriberはユースケースごとに様々な機能・パイプラインを持ちます。一般的には①リアルタイムな監視 & 詳細な情報に基づく可視化・分析、②アラート、③設定の自動化/自己治癒 などが考えられます。 検証構成と取得結果 ここからは、NTT Com内にて実施した検証についてご紹介します。 今回の構成では、NTT Comの社内ネットワーク環境において検証を実施しました。図9に構成図の一部を示します。 検証ではPublisher/Subscriberをそれぞれ多重化し、Brokerに収容しています。 監視対象の機器はArista・Cisco・Juniperと、Whiteboxな伝送装置に搭載されたSONiCの4ベンダを採用しています。また、SubscriberはオンプレミスのGrafanaによる可視化を行うと同時に、Google Cloud Platform上のKafkaにミラーリングを行い、Public Cloudと連携が行えることも検証しました。 図10、図11にそれぞれから取得した実際のデータをJSON形式で示します。 図10はArista機器で発行し、ockafkaを通じ取得したデータの例です。図の通り、データは単発のJSON型となっています。 一方、図11はその他の機器から取得したデータの例です。図の通り、Juniper/TelegrafではネストされたJSON型になっており、SONiC、gNMIcはJSON型の中にリストが含まれています。また、Cisco/Pipelineでは複数のJSON型がリストに含まれる形式であることがわかります。 このようなデータは直接InfluxDBに取り込むことができないため、整形処理が必要となります。LogstashやTelegrafといったコレクタには整形機能が存在しますが、デバッグが難しい、複雑な条件分岐を書きにくいなど、汎用性に問題がありました。 そこで、今回の検証ではデータ整形機を作成し対応しました。図12にデータ整形機を含めたフローを示します。 作成したデータ整形機は、まずKafkaから生データが含まれるTopicを購読し、データを取得します。取得したデータをPython Scriptで整形した後、Kafkaに対して取得したものとは異なるTopicでメッセージを発行します。これにより、Subscriberがデータ整形機の発行したTopicを指定することで、整形後のデータを取得できるようにしています。 図13に、実際に取得したデータをGrafanaで可視化した例を示します。 今回の検証では、TelemetryとSNMPで、Interfaceの受信したTraffic量の可視化を行いました。Telemetryは1000ms（Junosのみ2000ms）、SNMPでは負荷を考慮し、一般的に1分以上の間隔で取得することが多いですが、今回はPrometheusが取得可能であった15秒間隔でデータを採り、比較しています。 図13ではマイクロバーストの検知を想定しバーストトラフィックを生成しております。結果の通り、Telemetryではリアルタイムで複数のスパイクが観測されますが、SNMPでは、Pollingによる遅延が入った後、なだらかな山となり可視化が行われていることが読み取れます。 検証を通じて得られた知見 ここからはNTT Com内での検証を通じて得られた知見と期待されるユースケースをご紹介します。 導入時に考慮すべき点として、下記3点が挙げられます。 1. 対象機種ごとにパラメータを分ける手法の検討 現時点のTelemetryでは、ベンダごとに①Collector、②Dial-In / Dial-Out、③OpenConfig/ベンダネイティブの選択を含めたSensor-Path などのパラメータを指定する必要があります。 マルチベンダ環境における効率的な管理のため、例えばNetbox・Zabbix等でデバイス情報を管理しているネットワークでは、それらの情報と組み合わせ、ベンダごとに設定を切り替える仕組みを開発することで、管理コストを下げることが期待できます。 2. データの保持期間と粒度 Telemetryはms単位での情報取得が可能であるため、取得した大量のデータを長期にわたって保持することが現実的ではありません。 そのため、Telemetry導入の際にはデータの保持期間や保持する時間的な粒度などの事前検討が必要となります。 これらに該当するユースケースは主に ① 取得した瞬間の閾値による処理（その瞬間の詳細なデータが必要）、② 障害発生後の切り分け（1日-2日以内の詳細なデータが必要）の2種が想定されます。①、②どちらのユースケースでも、詳細なデータは1日-2日のみ保持し、それを過ぎたものはデータを時間単位などで集約して保持すれば良いと考えます。 3. 監視基盤の性能 2.の内容とも関連しますが、Telemetryを導入する際にはネットワーク規模と取得データと量・保持期間に従い、事前に監視基盤のメモリやストレージ等のリソースを計算しておく必要があり、導入前の検証が必須となります。 Telemetryに期待されるユースケース これまでの結果より、現時点のユースケースとして下記の3点を考えています。 シングルベンダ環境におけるリアルタイムな情報収集 gNMIを通じたコンフィグ投入等、自動化技術との組み合わせ 他の監視技術との連携 1.については、OpenConfigでの実装が追いついていない部分もベンダネイティブなSensor-Pathにより情報を取得でき、またベンダごとの独自機能や純正Collectorの利用が可能です。さらに、ベンダ固有の実装（Cisco Event Driven TelemetryやMellanox What Just Happened等）を利用できるなどの利点が存在します。 2.については、共有のgNMIを利用して監視・自動化が可能である利点を生かし、Telemetryにより振る舞いを監視し、閾値や機械学習ベースでのコンフィグ変更・自己治癒などの利用が考えられます。 3.については、例えばTelemetryのStatisticをxFlowのリアルタイムなフローと組み合わせ利用する、SyslogアラートをトリガーとしTelemetryのState・Statisticを保存するなど、高精細な情報を生かす手法が考えられます。 またどの用途についても、今後OpenConfig対応の充実やCollector・Dial-Out対応などの統一により、マルチベンダ対応が進むことにより、より利用しやすい技術となると期待しています。 まとめ NTT Comでの技術検証を通じ、Telemetryの下記3点の特徴を検証しました。 SNMPと比較し低負荷な設計によるリアルタイムな情報取得 OpenConfigによるベンダフリーな情報取得 Pub/Subモデルの導入が容易な設計による高い規模性 2021年8月時点の実装では、リアルタイムな情報取得はms単位での情報取得・低負荷なプロトコル設計等により期待通りの強みがありますが、マルチベンダ性に課題があるというのが検証から得られた所感です。 OpenConfigの対応状況やCollectorの統一については、これからますます実装が進むと予想されるため、今後の発展に期待しています。 付録 今回の検証で用いた各機器のコンフィグ例を共有します。お手元での検証にご利用ください。 なお、これらコンフィグ例は現状有姿で提供され、NTT Comは明示的・黙示的を問わず一切の保証をせず、何ら責任を負いません。 Arista 本体側はgNMI設定か専用デーモンを立ち上げるかの2択。 EOS 4.22以降ではgNMI設定が推奨されている。 本体側 - gNMI設定 management api gnmi transport grpc Telemetry port <Port> ip access-group <ACL名> provider eos-native ! 本体側 - 専用デーモン設定 ※ OpenConfigの場合はTerminAttrをOpenConfigに読みかえる。 daemon TerminAttr exec /usr/bin/TerminAttr -disableaaa -grpcaddr <CollectorのIP addr>:<Port> ip access-group <ACL名> no shutdown ! Collector - ockafaka（Dockerでの立ち上げ例） 手順は 公式リポジトリ を参照。 $ docker pull aristanetworks/ockafka $ docker run aristanetworks/ockafka -addrs <Publisher Addr>:<Port> -kafkaaddrs <Kafka Addr>:<Port> -kafkatopic arista_eos_telemetry -subscribe <PATH> Collector - openconfigbeat（Dockerでの立ち上げ例） 手順は 公式リポジトリ を参照。 % git clone https://github.com/aristanetworks/openconfigbeat.git // openconfigbeat.ymlを編集 openconfigbeat: addresses: ["<Publisher Addr>"] default_port: <Port> paths: ["interfaces/interface/name"] username: "<Username>" password: "<Password>" output.kafka: hosts: ["<Kafka Addr>:<Port>"] topic: <Topic名> // openconfigbeat.ymlを/直下に配置するようDockerfileを編集 % docker build -f ./Dockerfile -t openconfigbeat:latest . --no-cache=true % docker run -d --net=host --name openconfigbeat openconfigbeat:latest Cisco IOS-XR 本体側 - Dial-Out設定 telemetry model-driven destination-group <destination-group名> vrf <VRF名> address-family ipv4 <Collector Addr> port <Port> encoding <エンコーディング手法> protocol <トランスポートのプロトコル> ! ! sensor-group <sensor-group名> sensor-path <sensor-path> ! subscription <subscription名> sensor-group-id <sensor-group名> sample-interval <Interval(ms)> destination-id <destination-group名> source-interface <インターフェース名> ! ! 本体側 - TPA（Third Party Applications）設定 IOS-XR標準のマネジメントVRF以外でTelemetryを扱う場合に必要。 vrf <VRF名> address-family ipv4 update-source dataports active-management ! ! ! Collector - Pipeline 手順は 公式リポジトリ を参照。 pipeline.confを編集後、 $ docker run -d --net=host [--volume <local>:/data] --name pipeline pipeline:<version> [collector] stage = xport_input type = grpc encap = gpbkv listen = :<Port> [kafka] stage = xport_output type = kafka encoding = json_events brokers = <Kafka Addr>:<Port> topic = <Topic名> [inspector] stage = xport_output type = tap file = /data/dump.txt datachanneldepth = 1000 Juniper 本体側 - Dial-In設定 set system services extension-service request-response grpc clear-text address <Publisher Addr> set system services extension-service request-response grpc clear-text port <Port> set system services extension-service request-response grpc skip-authentication set system services extension-service notification allow-clients address <Collector Addr> Junos 20.2R1以降でDial-Outにも対応している が、対応するOSSのCollector実装が存在しないため未検証。 Collector - Telegraf Juniper公式のCollector実装である jtimon も存在するが、Kafkaとの連携機能が存在しないため本検証ではTelegrafのモジュールを採用。 [[inputs.jti_openconfig_telemetry]] servers = ["<Publisher Addr>:<Port>", "<Publisher Addr>:<Port>"] # 取得対象を複数指定可 username = "<Username>" password = "<Password>" client_id = "telegraf" # 取得対象の機器内(ルータ等)でユニークである必要がある # 1つの機器に対して複数プロセスからsubscribeする場合は、 # 異なる文字列にする sample_frequency = "2000ms" sensors = [ "/interfaces/interface[name=vme]/state", "/system", "/components", "/junos" ] retry_delay = "1000ms" str_as_tags = false [[outputs.kafka]] brokers = ["<Kafka Addr>:<Port>"] topic = "<Topic名>" data_format = "json" SONiC 本体側 - Telemetryサービスの設定 # vi telemetry-service.yaml apiVersion: v1 kind: Service metadata: name: telemetry-svc spec: type: NodePort ports: - port: <Port> protocol: TCP selector: app: usonic # kubectl apply -f telemetry-service.yaml kubectl get svc を実行し、待ち受けポートを確認しておく。 Collector - gNMIc 手順は 公式ページ 参照。 # vi gnmic.yml targets: <Publisher Addr>:<Port>: subscriptions: - port_stats skip-verify: true username: <Username> password: <Password> insecure: true subscriptions: port_stats: target: COUNTERS_DB paths: - <Sensor-Path> mode: stream stream-mode: sample sample-interval: 5s encoding: json outputs: output1: type: kafka address: <Kafka Addr>:<Port> topic: <Topic名> format: json debug: true

はじめに IoT Connect Gatewayとは？ IoT Connect Gatewayの特徴 閉域網がなくてもセキュアにクラウド接続を実現 処理負荷がかかる暗号化処理をサービス側で実施 暗号化通信によるデータ転送量を抑制 クラウドアダプタ機能で各種クラウドサービスに簡単接続 IoT Connect Gatewayにかける思い CI/CDの取り組みとサービスリリース Infrastructure as Code Test as Code GitOps 個人的な思い 最後に 次回予告 ICGWに関するお問い合わせ先 はじめに こんにちは、データプラットフォームサービス部でIoT Connect Gateway開発チームのTech Leadを している 栗原良尚(@yoshinao) です。 この度、NTT Com Engineers' Blogオープンに合わせて、開発をおこなっているIoT Connect Gatewayについてご紹介、情報発信をできる機会をいただきました。閲覧頂きありがとうございます。 Engineers' Blogでは、単なるサービス紹介だけでなく、IoT Connect Gatewayの使い方や、どんな事ができるのか？などのレシピや周辺技術を実験や電子工作を通じて発信していきたいと思っております。 また、皆様からのリクエストやフィードバックを通じて、双方向の情報発信、みなさまの声を次期開発に活かしたいと考えておりますのでリクエストやコメントを頂けますと幸いです。個人的にも記事投稿の励みになります（笑） どうぞ、よろしくお願い致します。 IoT Connect Gatewayとは？ IoT Connect Gateway（ICGW） とは、NTT Comが 2021年4月6日にリリース したIoT向けGatewayサービスです。 このサービスは、IoTセンサーやデバイスで収集したデータをクラウドやお客様のサービスに簡単かつセキュアに転送するためのゲートウェイサービスです。 ICGWでは、IoTデバイスからの通信をNTT ComのGatewayで一度終端することで、IoTデバイス側に必要な機能をオフロードしたり、転送先を切り替えたり、デバイス側に機能追加必要なく様々な付加価値を利用することが可能になります。 ICGWは、NTT Comが提供している SmartDataPlatforｍ(SDPF) のIoTカテゴリのサービスで、 IoT Connect Mobile Type S と組み合わせてご利用が可能です。 今後も他のSDPFサービスのシームレスな連携を目指すことで、一つのプラットフォーム上でシームレスに融合、データを整理して利活用を容易にすることを目指しています。 IoT Connect Gatewayの特徴 以下に、現在のサービスの特徴をご紹介します。 1. 閉域網がなくてもセキュアにクラウド接続を実現 IoTデバイスからクラウドにセキュアにデータを送信したい場合、個別に閉域網で接続する、デバイスからデータ暗号化して送信するといった方法がありますが、どちらもコストがかかるという課題があります。 ICGWは、モバイル網とインターネットの境界に位置し、IoTデバイスからICGWの区間はモバイル網でセキュアに、ICGWからクラウドサービスに接続する時は、ICGWで暗号化(HTTPS/MQTTS) することでセキュアで安価なサービス接続を実現しています。 2. 処理負荷がかかる暗号化処理をサービス側で実施 IoTデバイスから暗号化したデータを送信する場合、デバイス側で暗号化を行うことになりますが、いくつかの課題に直面することがあります。 暗号化によってIoTデバイスの消費電力が大きくなってしまう IoTデバイスの製造コストが高くなってしまう ICGWは、これらの課題をサービス側で暗号化を行うことで解決します。端末側で暗号化の暗号化能力を気にする必要はありません。 また、鍵の交換などの作業もサービス側で一括して実施できるので、端末ごとの個別設定は必要なくなるというメリットがあります。 3. 暗号化通信によるデータ転送量を抑制 IoTデバイスから暗号化通信を行う場合、暗号化によるプロトコルオーバヘッドが発生し、暗号化しない通信と比較してデータ通信料が多くなるという課題があります。 ICGWでは、IoTデバイスからICGW区間は、閉域のモバイル網を利用するため、暗号化を必要とせずセキュアにデータを転送可能です。また、サービス側で暗号化処理を行うため、セキュアかつデータ通信量を節約することが可能です。 4. クラウドアダプタ機能で各種クラウドサービスに簡単接続 ICGWでは、暗号化と合わせて、各種クラウドサービスの差異を 意識することなく簡単に接続できるクラウドアダプタを提供しています。 この機能によって、IoTデバイスに利用クラウドに合わせた接続パラメータなどの個別の設定や開発のコストを削減することが可能となります。 各種クラウドサービスは、頻繁に機能アップデートや新規サービスを展開していますが、既に展開済みのIoTデバイスに、これらのアップデートを追従していくことは困難です。 しかしICGWを利用している場合、簡単に転送先サービスの変更や新機能が利用可能になります。 これはすでに展開済みのIoTデバイスを管理する上でも大きなメリットとなります。また、長期運用の観点では、暗号化プロトコルのアップデートや追従ができる点も重要になります。 現在対応中のクラウドサービス クラウドサービス プロトコル AWS IoTCore HTTP MQTT GCP IoTCore HTTP MQTT Azure IoTHub HTTP MQTT 現在、NTT ComのIoTプラットフォームである Things Cloud のクラウドアダプタやその他の新アダプタ対応についても現在開発を行っていますので、ご期待ください。 IoT Connect Gatewayにかける思い CI/CDの取り組みとサービスリリース ICGWの開発は、スピーディーに新機能を開発し、いち早くお客さまに提供するためにDevOpsチームとして開発、運用を行っています。 新機能開発・提供を実現するために以下のようなことをICGWのDevOpsチームでは取り組んでいます。このあたりの話もブログ投稿などでお話できればと思ってます。 1. Infrastructure as Code ICGWの環境構築作業は Terraform を利用し、コード管理で 開発環境、テスト環境、商用環境の構築を行っています。 これにより、新機能をリリースするために必要となる構成変更や拠点の追加をスピーディーに実現することが可能になりました。 2. Test as Code スピード感をもった開発も重要ですが、品質も重要ですので これまで通り品質を担保し、開発するための仕組みとして UnitTest, E2E Testなどの検証作業をGitHub Actionsで自動化することで従来の検証時間を削減しています。 また新機能追加でデグレが発生していないかをチェックし、品質を担保する仕組みを実現しています。 3. GitOps これまでの開発では、コード開発以外の作業や多大な時間が必要でした。 そこで、コンテナ化や Argo CD や Helm を利用することで、CI/CDを実現し開発者が開発に集中できる環境を実現し、商用環境に適応していくという仕組みを作りました。 また、Stg環境では、開発中の新機能を先行的にお客様やIoTデバイスベンダの方にトライアルして頂くなどの取り組みもすすめています。 個人的な思い このICGWは、私が小さなころから好きな 電子回路の世界 と大学院から夢中になった ネットワークやクラウドの世界 をつなぐサービスとして非常に思い入れがあるサービスです。 このサービス開発をはじめて、趣味でIoTデバイスをRaspberry PiやM5Stackなどを利用して色々と開発していますが、その根底には、 「つくるひと」 でありたいという思いがあると思っています。 以下の動画は2007年頃、とある番組の1000回放送記念CMとして１度だけ放送されたもので、リアルタイムに見て衝撃を受けたものです。 当時、分野をネットワークに変えて大学院進学するか悩んでおり、その後も、博士後期課程に進むか就職するかなど、いつも人生の大きな分岐点をこれまで支えてきてくれた大切な動画なので、紹介させてください。 この動画の中で、息子がただただ聞いてくる「なんでこの会社にしたの？」という無邪気な質問に対して、私達は自身の勤める社名に置き換えた時、「自分の子供が納得する答え」、「自分自身が納得できる答え」を出せるでしょうか？ 私の場合、「なんでNTT Com/NTTグループにしたの？」という質問に対して、父親の回答である「つくる人になりたかった」を 「つくる人であると共に、つなぐ人になりたかった」 と息子に自身をもって言えるよう、これからもサービス開発に取り組みたいとおもっています。 最後に IoTサービス関係者、クラウドサービス提供者などみなさんと共に、 私達の技術が誰かの何かの役に立ちたい 、またその先にいる 利用者の幸せに貢献できれば という思いをもって、これからもサービス開発を続けていきたいと思っています。 それがNTT Comが掲げる Re-connect X と自分は思っています。 この思いは、弊社のNTT Com Engineers' Blog投稿者の共通の思いであると思っています。そんな会社にしていきたいと思っていますので、これからも NTT Com ならびに NTT Com Engineers' Blog をよろしくお願い致します。 次回予告 今回は、ICGWのご紹介とICGWにかける思いの投稿になってしまいましたが、次回はICGWの使い方や、ICGWを使った電子工作やアプリの記事を投稿する予定です。 to be continued... ICGWに関するお問い合わせ先 トライアル、サービス導入に関するお問い合わせ 資料請求・お問い合わせフォーム 開発チームへのお問い合わせ メールを送る ※お手数ですが＠を半角文字に置き換えてください

こんにちは、デジタル改革推進部の河合と浅野です！ 私たちデジタル改革推進部では、普段から全社で使うためのデータ分析環境の開発・提供を行っています。 今回は社内でデータ分析コンペティションを開催したのでその内容を報告します。 社内データ分析コンペティションとは？ 社内にある様々なデータ活用課題をコンペティション形式に落とし込み、全社で知恵をしぼって解こうという試みです。 もともと、データサイエンスの界隈ではKaggleやatmaCupと呼ばれる分析力を競うコンペが行われており、課題や技術を集団で共有して解く文化があります。 今回はそれらを参考に、社内のデータを使ったコンペを 6/21~7/2 の２週間にかけて初開催しました。 開催にあたって期待したことは、以下の３つです。 様々な部署に散らばっているサービス特有のドメイン知識、データ、分析技術を一箇所に集める 優れたソリューションを集合知によって短期間で探し出す データ活用人材の育成や発掘 上記を満たすために、KaggleやatmaCupを参考にコンペのルールを工夫して作りました。 具体的には下記のような点です。 予測結果の設定 特定期間に過学習してしまうのを避けるため、予測範囲を2種類に分けて評価する。 一方は予測値を投稿すると即時計算されるpublic scoreに、もう一方は最終日まで結果がわからず順位決めに使われるprivate scoreとして評価する。 情報共有に対する評価 参加者は分析結果を適宜共有する（Discussion）ことができ、そこにいいねやコメントをつけることが可能。いいね数が上位の方も表彰対象とする チームでの参加も可能とする コンペのテーマと進め方 第一回のテーマとして、インターネットのトラフィック量(※通信量のこと)の将来予測を設定しました。 必要な分析技術の範囲としては、複数地域のトラフィックを予測する多変量の時系列予測となります。スコアとしては平均絶対パーセント誤差(MAPE)を使いました。 コンペティションは以下のようなスケジュールで実施しました。 6/21(月) 開会式:　テーマの説明 6/22(火) 初心者向け講座#1 データの読み込みからベースラインのsubmitまでのチュートリアル 6/24(木) 初心者向け講座#2 応用コンテンツの紹介。 EDA/validation評価について 6/28(月) もくもく会#1 6/29(火) もくもく会#2 7/2(金) ~17:30 コンペ終了 7/6(火) 結果発表・閉会式 7/14 成績上位者の発表. 分析内容の共有会 今回のイベントはフルリモートのオンライン開催でしたが、 コンペ初参加の方でもイベントに入りやすいように、初心者向け講座を複数回 また分析作業内容や疑問点を解消するためのもくもく会も複数回実施しました。 これらに参加すれば、誰でも共有されたサンプルコードを使って 予測結果を作って投稿できるような形にしています。 コンペ環境 デジタル改革推進部では、NTTcom内のデータ活用を推進するためDLXと呼ばれる全社員が使える分析基盤を開発しています。 今回はこの分析基盤にコンペ参加者に向けてJupyter labベースの環境を用意し、PythonやRを使って分析できるようにしました。 データセットはhadoop上に置き、trinoと呼ばれる分散SQLクエリエンジンを使って自由に参加者がSQLを叩いてアクセスできるようになっています。 また、某コンペサイトを参考に、社内コンペサイト「Saggle」を用意し、予測結果の投稿やコードの共有ができるようにしました。 分析Notebookの共有 リーダーボード 結果 ５０名を超えるエントリーをいただき、最終的なsubmit回数は800回を超えました。 参加者の予測誤差のスコア(public)の推移は以下のような感じでした。 コンペが進むにつれ全体のスコアが良くなっていく様子がみて取れます。 一方でprivate scoreの方も合わせて見てみると、分析コンペでありがちな過学習が発生していたのがわかります。 今回はsubmit回数の制限を行わなかったこともあり、public scoreを追い求めすぎてprivate scoreが下がり、最終順位が下がる(shake down)という悲しい思いをされた参加者が多かったと思います。 順位発表後には、スコア上位者の方に使った手法を解説していただきました。 参加者の声 開催後、参加者の方からアンケートを取ったところ 課題がやや難しかったという意見もありましたが、 「知識が無いなりにも操作ができる環境・サンプルコード準備を始め、基礎的な質問への応援サポートに感謝感謝でした」「初めてのコンペ参加でしたが、ディスカッションも盛り上がり、いろいろな気付きがあって大変楽しむことができました」 といった意見を多数いただくことができました。 このうち90%以上の方から、「次回開催があれば他の社員にも参加をお勧めしたい」と回答をいただき、社内でも非常にポジティブな意見をいただくことができました。 まとめ 今回は社内の実データを使った分析コンペの開催報告でした。 今回の分析コンペによって下記のような結果が得られました。 共通のデータを使って多様なスキルやバックグラウンドを持つ社員が議論しながら一つの分析課題に取り組むことができた 2週間という短い期間でデータの理解とより高精度な予測モデルを作成することができた 初めてコンペに参加した方/分析知識がなかった方を含め50名以上の方が、データ分析、予測までできるようになった 今後は、アイデアソンなどもう少し範囲を広げて分析コンペを定期開催できるよう目指していきたいと考えています。 これからもコムのデータ活用が盛んになり、業務やサービスをよりよくしていけるように取り組んでいきます！

職場体験型インターンシップ（エンジニアコース）募集中です！ (~2021/8/20) 本インターンシップは、実際に各分野でエンジニアとして働いているNTTコミュニケーションズの社員と一緒に働くことで、実際の開発現場を肌で感じて頂くことができるインターンシップです。 業務体験を通じて、NTTコミュニケーションズにおけるエンジニアの仕事が理解できるだけでなく、職場体験を通してみなさん自身が成長を実感できる内容になっています。 参加者からは「エンジニアの仕事が理解できた」「自分の活躍のイメージが湧いた」などの声も毎年多数頂いています。 また、参加いただいた学生の方から、次のようなアウトプットもいただいております。 NTTコミュニケーションズでインターンシップをしてきました!! NTTコミュニケーションズ インターンシップレポート 働くイメージを持ちたい方、自分のスキルや能力がどのように活かせるのかを知りたい方はぜひご応募ください！ 募集中のエンジニア種別は次のとおりです。 AIエンジニア ソフトウェアエンジニア ネットワークインフラエンジニア セキュリティエンジニア テレプレゼンスエンジニア その他詳細情報は、 募集ページ をご覧ください。みなさんのご応募をお待ちしております！ ※新型コロナウイルス感染状況により、開催の中止・開催内容の変更等の可能性があります。 ※夏インターンで実施するものは、エンジニアコースのみとなります。

こんにちは、イノベーションセンターの田良島です。普段はコンピュータビジョンの技術開発や検証に取り組んでいます。7月27日から30日にかけて、画像の認識と理解技術に関する国内会議の MIRU2021 が開催され、NTT Comからは計4名が参加し2件の発表をしました。 7/27(火)-7/30(金)にオンラインで開催される、画像の認識・理解シンポジウム( #MIRU2021 ) において、弊社イノベーションセンターから2件の研究成果を発表します！ 映像AI分野の研究者・エンジニア・学生が集う国内最大級の学会です。 学生は参加費無料✨ ぜひご参加ください▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月27日 画像の認識・理解シンポジウム( #MIRU2021 ) において、本日28日(水)のプログラムに、弊社の田良島が登場します！ ■15:00-15:30　口頭発表（ショート2） ■17:15-18:30　インタラクティブ1-2 「One Shot Deep Model for Multi-Actor Scene Understanding」 詳細はこちら▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月28日 画像の認識・理解シンポジウム( #MIRU2021 ) にて、弊社の丹野、市川、島田、木村、泉谷が研究成果を発表します！ ■7/29(木) 15:45-17:00 「プロセスデータおよび炉内映像Optical-Flowに基づくマルチモーダル深層学習によるごみ焼却プラントの蒸気量推定」 詳細はこちら▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月29日 ここでは、参加メンバーでMIRUの報告をしたいと思います。 ※なお私たちのチームでは、2021年8月4日現在エントリー受付中の 職場体験型インターンシップ に、 AI/MLシステムとの統合を志向した、メディアAI技術の研究開発 というポストを出しています。学生さんであればどなたでも応募可能です、ご興味あればぜひエントリーを検討ください！ MIRU2021 MIRUはコンピュータビジョンや画像映像認識を扱う国内最大級の学会です。個人的には、MIRUは SSII と並んで画像映像認識を対象とした国内学会の二大巨頭をなしている印象があります。MIRUの方がよりアカデミックな雰囲気 今年は過去最多の1,428名の参加があった とのことで、この技術分野の勢いをひしひしと感じます MIRUの発表区分(招待講演等を除く)には口頭発表(ロング、ショート)とインタラクティブ発表があり、前者は査読があります。今回NTT Comからは、口頭発表(ショート)1件とインタラクティブ発表1件を行いました。以下ではまず、口頭発表の機会をいただいた "One Shot Deep Model for Multi-Actor Scene Understanding" についてご紹介します。 NTT Comからの発表 この研究では、不特定多数の人物(アクター)が写る映像を入力としてそのシーンを認識する問題に取り組んでいます。より具体的には、アクターを検出・追跡することに加え、各個人がとる動作と、アクターが集団でとる行動とを認識するという問題です。集団の行動は、チームスポーツでのセットプレイをイメージしていただくと分かりやすいかもしれません。アクターはシーンの中でお互いに影響を及ぼし合うので、特に個人の動作や集団の行動の認識では、アクター間の相互作用を捉えることも重要になってきます。 アプローチとして、アクターの検出・追跡・個人動作認識・集団行動認識の各サブタスクにState-of-the-art(SOTA)の方法を適用するというものがまず思いつきます。ですがこのアプローチには、全体の処理が冗長でかつ時間がかかってしまう問題があります。どのサブタスクにも何かしらの深層学習モデルを用意することになり、かつそれらはしばしば同じバックボーンであったりするので、当然と言えば当然です。一方で各サブタスクについて考えてみると、例えば同一人物は前後のフレームで同じ動作を継続している可能性が高いなど、それらは少なからず関係し合っていることに気が付きます。サブタスクは関係し合っているのに各々は独立に解くというアプローチには、改善の余地がある気がしてきました。 このモチベーションのもと、本研究では上記の全サブタスクを解くための特徴をワンショットで出力可能なモデルを提案しています。モデルは、各フレームから検出、追跡、行動/動作認識のための特徴抽出を担う畳み込みニューラルネットワーク(CNN)、行動/動作特徴をその相互作用を考慮して変換するニューラルネットワーク(Relation Encoder)とから構成しています。Relation Encoderでは、Transformer 1 で採用されているMulti-Head Attentionを拡張し、アクターの見え方と位置どちらの情報もふまえた特徴変換を実現しているところがポイントです。 Volleyballデータセット 2 という代表的なベンチマークで評価したところ、各サブタスク毎にSOTAを適用するアプローチと同等の性能を、全体で約半分のモデルサイズおよび2倍の処理速度で実現できることが確認できました。 発表はZoomのウェビナーで実施し、およそ450名の方に聴講いただきました。またインタラクティブ発表はoViceで実施し、多くの方と直接ディスカッションさせていただきました。MIRU運営の皆様や聴講・質疑くださった皆様、まことにありがとうございました。この分野の競争は本当に激しいなと感じていますが、来年以降もぜひ私たちの取り組みを発表していけるよう頑張りたいです。 気になった発表 こんにちは、イノベーションセンターの鈴ヶ嶺です。普段は、クラウド・ハイブリッドクラウド・エッジデバイスを利用したAI/MLシステムに関する業務に従事しています。私からは3件気になった発表をご紹介します。 L1-2 動的光線空間のシングルショット撮影 概要 時間成分を含んだ動的な光線空間をシングルショット撮影から復元する手法を提案していました。光線空間とは様々な角度から撮影した画像を利用した多視点画像群で3次元ディスプレイなどに応用されます。従来的なカメラアレイでは装置の大規模化という課題、レンズアレイ型のplenoptic cameraでは一台のカメラで撮影できる代わりに視点ごとの空間解像度が低下するという課題があります。 例: 大規模なカメラアレイシステム 3 提案法では、1台のカメラの開口面と撮像面で得られる情報を適切に2次元上に符号化し、CNNで5次元の動的な光線空間を復元し高解像度、高フレームレートを実現していました。さらにハードウェアによる検証も実施しており、実応用上の有効性も示していました。 所感 1台のカメラにある開口面と撮像面の関係が光線空間を表現していることを利用し、それを2次元空間上に符号化し復元する発想が面白かったです。さらにハードウェアでも検証が成功しており、今後の応用が期待される研究でした。 L2-1 連動する骨格動作の表現に適した時空間特徴の学習による人物運動予測法 概要 人物骨格動作の予測モデルにおいて動作特徴を時間的・空間的に集約するアーキテクチャを提案していました。 人物運動予測モデルには、2つ課題があります。まず直前の動作が支配的なケースや、長期的な動作が支配的なケースなど参照すべき特徴が異なる時間的問題です。次に、局所的な動作のみを考慮すれば良いケースと大域的な動作を考慮しなければならないケースなど参照する特徴が異なる空間的問題です。提案法では、時間的問題に対してMultiscale Temporal Convolution 4 のそれぞれの中間層を用いて参照時間の異なる特徴を表現することで時間的に集約しています。空間的問題に対しては、Encoderでは位置ベースの空間に出力し、Decoderに角度ベースの空間を入力として利用していました。それぞれの空間は位置と回転ベクトルのヤコビ行列から2つの特徴量空間間のヤコビ行列を生成して写像されます。これらの手法から、高い性能を示す予測結果を提示していました。 所感 EncoderとDecoderで位置と角度という異なる特徴を用いることで空間的に頑健な予測モデルにしている点が面白かったです。実際のデモを見ても高い精度で予測されており、興味深い研究でした。 L5-3 An Improved Inter-intra Contrastive Framework for Self-supervised Video Representation Learning 概要 この発表では、動画に関する対照学習 5 の手法Inter-Intra Contrastive(IIC) 6 を改良したIICv2を提案していました。 IICの全体像 主にIICv2は3つの要素が拡張されています。1つ目がAnchorであるフレーム群からFrame repeating, Temporal shuffling, Clip rotationなど操作をして対照学習の負例を生成するintra-negative sampleです。2つ目は画像に対してのStrong data augmentations 7 です。3つ目はContrastive lossが適用される空間に表現をマッピングする小さなネットワークであるprojection head 8 です。実験結果として UCF101 9 , HMDB51 10 のデータセットにおいて最新のSOTAを上回る結果を示していました。 所感 動画に対する対照学習において、負例の生成方法や効果的なデータの水増し法などの様々な改良をしており勉強になりました。最終的な性能も現在のSOTAを上回っており、今後の参考にしたいと思いました。 こんにちは、イノベーションセンター新入社員の齋藤です。普段は、今回一緒に参加している鈴ヶ嶺と同じく、クラウド・ハイブリッドクラウド・エッジデバイスを利用したAI/MLシステムの研究開発をコンピュータビジョンを題材に取り組んでいます。私からも3件気になった発表をご紹介します。 L1-3 Can Vision Transformers Learn without Natural Images? arXiv:2103.13023 概要 Vision Transformer(ViT) 11 の性能は、学習に用いるデータセットサイズに強く影響を受けることが知られていますが、大規模なデータセットを用意するにはコストや倫理の問題が生じます。この研究では、数式から画像とラベルを自動生成する FractalDB 12 を用いてViTの事前学習を行うと、自然画像とその正解ラベルを用いて学習した場合とほぼ同精度が得られる、つまり自然画像を用いることなくViTの事前学習は可能だという驚くべき結果が示されています。 評価 ・FractalDBで事前学習したViTとImageNet-1k 13 ,Places-365 14 などを事前学習させたViTを比較した実験 ・FDSL(FractalDB-10k)とSSL(Jigsaw 15 , Rotation 16 , MoCov2 17 , SimCLRv2 18 )の比較実験を行っています。 Computer Vision and Pattern Recognition (CVPR). (2009) 248–255 DeiTsで事前学習済みのFractalDB-1k/10kがImageNet-100/Places-30のモデルを上回り、ImageNet-1k/Places-365を上回ることはできませんでした。ですが、ImageNet-1kと肉薄した性能を持っていることが実験から分かりました。 FractalDB-10KはSimCLRv2よりも若干精度を上回った結果を出しました。また、C10、VOC12、P30においては精度を上回った結果を出しています。 所感 今後、研究が発展することにより様々なタスクへの応用可能性が高いため、楽しみな研究の1つになりました。ソースコードもオープンソースで公開されているので、手元で試してみたいとも思います。 L2-4 Lightning-fast Virtual Try-on without Paired Data and Direct Supervision 概要 この研究では、弱教師あり学習を用いて、仮想試着を提案しています。仮想試着とは、Sourceの画像に対して、Targetの服に着せ替える技術のことで、応用先として、アパレルのECショップなどがあります。従来手法の、アノテーションコスト、メモリの消費量、テスト速度の問題を解決するものとして、本発表の手法 (LiVIRT) を提案しています。エンジンの中身としては、3つのネットワークを用いています。その中で無駄を取り払うなどの工夫によるネットワークの高速化を行っています。 評価 データにペアデータがある場合の実験では、教師あり学習の手法(CP-VTON 19 , SieveNet 20 )とLiVIRTの比較を行い、教師あり学習とほぼ同じ精度で仮想試着ができています。 ペアデータが存在する場合の実験においても、精度が良いことが実験で示されています。 所感 私が試したことのある仮想試着は、実際に着ている感があまりありませんでした。仮想試着の技術はECサイトのUX向上に大きく影響すると思うので、興味深く発表を聞かせていただきました。 L5-1 複屈折反射特性の計測に基づく材質識別 概要 材質識別は、資源の開発やリサイクル、自動運転など様々なシーンで求められる技術です。この研究では、複屈折反射特性から抽出された特徴量をU-net 21 に入力してクラス分類を行っています。 評価 79種類の材質を、金属・木材・布・樹脂・石材に材質クラスの識別を行っています。U-netと比較する手法としては、k近傍法を用いています。結果として、5種類の材質クラスの識別平均正解率は、U-netで0.90、k近傍法で0.87となり、U-netを用いた方が正解率が高いことが確認できました。 所感 複屈折反射特性から特徴量を求めている点が面白いと感じました。モデルのバックボーンを変えた場合の精度変化も気になるところです。 最後に MIRU2021の模様をご紹介しました。NTT Comでは、今回ご紹介した学会での発表調査はもちろんのこと、画像や映像、更には音声言語も含めた様々なメディアAI技術の研究開発に今後も積極的に取り組んでいきます。また一緒に技術開発を進めてくれる仲間も絶賛募集中です。 アカデミックな研究に注力したくさん論文を書きたい 最新の技術をいちはやく取り入れ実用化に結び付けたい AIアルゴリズムに加え、AI/MLシステム全体の最適な設計を模索したい という方々に活躍していただけるフィールドが弊社には多くあり、いくつか新卒採用のポジションを用意する予定です。エントリーの受付開始は2022年1月以降となる予定ですが、よろしければぜひ新卒採用ページをウォッチしていただけると嬉しいです さらに冒頭でも述べた通り、2021年8月4日現在、NTT Comでは 夏の職場体験型インターンシップ のエントリーを受付中です。私達のチームからも、AIエンジニアカテゴリに AI/MLシステムとの統合を志向した、メディアAI技術の研究開発 というポストを出しています。インターンを通じて、会社やチームの雰囲気、そして私たちの取り組みを知っていただく機会にできればと考えています。皆様のご応募、心からお待ちしています！ Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., … & Polosukhin, I. (2017). Attention is all you need. In Advances in neural information processing systems (pp. 5998-6008). arXiv:1706.03762 ↩ Ibrahim, M.S., Muralidharan, S., Deng, Z., Vahdat, A., & Mori, G. (2016). A Hierarchical Deep Temporal Model for Group Activity Recognition. 2016 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 1971-1980. ↩ 裸眼立体ライブ映像システムを支えるカメラアレイの開発 https://news.mynavi.jp/photo/article/20080625-cameraarray/images/004l.jpg ↩ Lea, C., Flynn, M. D., Vidal, R., Reiter, A., & Hager, G. D. (2017). Temporal convolutional networks for action segmentation and detection. In proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 156-165). arXiv:1611.05267 ↩ Khosla, P., Teterwak, P., Wang, C., Sarna, A., Tian, Y., Isola, P., … & Krishnan, D. (2020). Supervised contrastive learning. arXiv preprint arXiv:2004.11362. arXiv:2004.11362 ↩ Tao, Li, Xueting Wang, and Toshihiko Yamasaki. “Self-supervised video representation learning using inter-intra contrastive framework.” Proceedings of the 28th ACM International Conference on Multimedia. 2020. arXiv:2008.02531 ↩ Grill, J.-B., Strub, F., Altche, F., Tallec, C., Richemond, P. H., ´Buchatskaya, E., Doersch, C., Pires, B. A., Guo, Z. D., Azar, M. G. et al.: Bootstrap your own latent: A new approach to self-supervised learning, Advances in Neural Information Processing Systems (2020) ↩ Chen, T., Kornblith, S., Norouzi, M., & Hinton, G. (2020, November). A simple framework for contrastive learning of visual representations. In International conference on machine learning (pp. 1597-1607). PMLR. ↩ Soomro, K., Zamir, A. R. and Shah, M.: UCF101: A dataset of 101 human actions classes from videos in the wild, arXiv preprint arXiv:1212.0402 (2012). ↩ Kuehne, H., Jhuang, H., Garrote, E., Poggio, T. and Serre, T.: HMDB: A large video database for human motion recognition, IEEE International Conference on Computer Vision, pp. 2556–2563 (2011). ↩ Dosovitskiy, A., Beyer, L., Kolesnikov, A., Weissenborn, D., Zhai, X., Unterthiner, T., … & Houlsby, N. (2020). An image is worth 16x16 words: Transformers for image recognition at scale. arXiv preprint arXiv:2010.11929. arXiv:2010.11929 ↩ H. Kataoka, K. Okayasu, A. Matsumoto, E. Yamagata, R.Yamada, N.Inoue, A. Nakamura, and Y. Satoh. Pre-training without Natural Images. In Asian Conference on Computer Vision (ACCV), 2020. arXiv:2006.10029 ↩ Deng, J., Dong, W., Socher, R., Li, L.J., Li, K., Fei-Fei, L.: ImageNet: A LargeScale Hierarchical Image Database. In: The IEEE International Conference on ↩ Zhou, B., Lapedriza, A., Khosla, A., Oliva, A., Torralba, A.: Places: A 10 million Image Database for Scene Recognition. IEEE Transactions on Pattern Analysis and Machine Intelligence (TPAMI) 40 (2017) 1452–1464 ↩ Noroozi, M., & Favaro, P. (2016, October). Unsupervised learning of visual representations by solving jigsaw puzzles. In European conference on computer vision (pp. 69-84). Springer, Cham. ↩ Gidaris, S., Singh, P., Komodakis, N.: Unsupervised Representation Learning by Predicting Image Rotations. In: International Conference on Learning Representation(ICLR) (2018) arXiv:1803.07728 ↩ Chen, X., Fan, H., Girshick, R., & He, K. (2020). Improved baselines with momentum contrastive learning. arXiv preprint arXiv:2003.04297. arXiv:2003.04297 ↩ Chen, T., Kornblith, S., Swersky, K., Norouzi, M., & Hinton, G. (2020). Big self-supervised models are strong semi-supervised learners. arXiv preprint arXiv:2006.10029. arXiv:2006.10029 ↩ Bochao Wang, Huabin Zheng, Xiaodan Liang, Yimin Chen, Liang Lin, Meng Yang.“Toward Characteristic-Preserving Image-based Virtual Try-On Network”.arXiv preprint arXiv:1807.07688. arXiv:1807.07688 ↩ Surgan Jandial, Ayush Chopra, Kumar Ayush, Mayur Hemani, Abhijeet Kumar, Balaji Krishnamurthy.“SieveNet: A Unified Framework for Robust Image-Based Virtual Try-On”.arXiv preprint arXiv:2001.06265. arXiv:2001.06265 ↩ O. Ronneberger, P. Fischer, T. Brox, ”U-net: Convolutional networks for biomedical image segmentation”, MICCAI, 2015 ↩

こんにちは、イノベーションセンターの前田です。今回は、前回に引き続き、私のチームで開発中の制御（OT）システム向けセキュリティ対策技術OsecT（オーセクト）についてご紹介します。 前回の記事（前編）では、以下の内容をご紹介しました。 OTネットワークの概要 OTネットワークのセキュリティ対策と課題 OsecTの概要 OsecTのネットワーク可視化機能の詳細 本記事では、 OsecTの脅威検知機能の詳細 について、ご紹介します。 前編のおさらい 工場・ビル等のスマート化に伴い、OTネットワークのセキュリティリスクも高まっています。しかし、OTのネットワークは閉域ネットワークとして構築されてきたことや独自OS・プロトコルが多数利用されてきたことから、セキュリティ対策が進んでいない現状があります。こうした状況を受けて、NTT Comでは、OTのセキュリティ対策技術OsecT（オーセクト）を開発しています。 OsecTには、 守るべき資産や通信の可視化を行うネットワーク可視化機能 と、 不正に接続された端末やサポート切れのOSを利用する端末等を検出した際のアラート機能（脅威検知機能） の2つの機能があります。 以降では、OsecTの脅威検知機能の詳細について、開発の工夫点などを交えながらご紹介します。 ※OsecTは現在開発中の技術であり、正式リリース時には仕様・画面イメージが変わる可能性が大いにあります。 脅威検知機能 OTの守るべき資産・ネットワークを可視化し、資産台帳の最新化や監視ポイントの明確化等が行えたら、次のステップとして有用なのが脅威検知機能になります。 こちらの機能もネットワーク可視化機能と同様に、オフラインのトラヒックデータを元に定期アセスメント等で利用する使い方もできますが、リアルタイムのトラヒックデータをミラーリングで取り込んで脅威検知機能で処理し、発出されるアラートを監視する使い方が有効です。 OsecTでは、以下の7つの脅威検知機能を開発中です。機能毎にコンテナを分けることで、必要なものだけを選択して導入できる作りにしています。 また、各脅威検知機能は、次のいずれかに属しています。 学習期間を定めてその期間を正常状態として学習し、検知期間において、学習モデルと異なる振る舞いが観測された場合にアラートを発出する「アノマリ検知」 セキュリティの脅威につながる通信パターンやサポート切れのOS情報などを事前定義したルールに基づき検知期間の通信をチェックし、ルールにマッチした場合にアラートを発出する「ルールベース検知」 新規端末検知 こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{IPアドレス, MACアドレス}の組み合わせを学習して、学習モデルに登場しない{IPアドレス, MACアドレス}の組み合わせの通信が観測された場合にアラートを発出しています。 アラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{IPアドレス, MACアドレス}の組み合わせに加えて、当該端末を特定しやすいように、MAC Vendorの情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、計画されていない端末がネットワークに接続された際などに早期発見することができます。 ネットワークホワイトリスト こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。 OTの独自サービスのプロトコルの中には、一般的な通信サービスの振る舞いとは異なり、送信元ポート番号が固定値で、宛先ポート番号がランダム or 範囲の値を取るものがあります。こちらの特徴を考慮せずにネットワークホワイトリストの学習モデルを作成すると、学習モデルの行数（テーブル数）が膨大になる問題があります。OsecTでは、こうしたサービスの通信を自動判別・集約して効率的に学習しています。 学習モデルは、例えば、以下のようなものが作成され、4行目や7行目が前述の仕組みで集約された箇所になります。 また、ネットワークホワイトリストのアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示するようにしています。こちらのアラートを見ることで、平常時とは異なる宛先への通信や平常時に利用していない不審なサービスの通信などを早期発見できます。 OTコマンドホワイトリスト こちらは、アノマリ検知に属し、OTプロトコルのL7情報を用いた脅威検知機能になっています。 現在は、ビルのオートメーション・制御に利用されるBACnet/IPに対応しており、学習期間のトラヒックデータに登場する、{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。 OTコマンドホワイトリスト（BACnet/IP）のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示しています。こちらのアラートを見ることで、平常時とは異なるBACnetサービス（コマンド）通信の発生を早期発見でき、例えばビルシステムの保守作業スケジュール等と突合して適切な通信かを確認することで、異常を特定できます。 流量ベースライン検知 こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス}のペア毎に、各時間帯のトラヒック量（パケット数、バイト数）をベースに、各時間帯で取り得るトラヒック量の範囲（上限値と下限値）を推定して、その値を学習モデルとして保存します。検知期間では、学習されたトラヒック量の上限値を上回る/または下限値を下回る通信が観測された場合にアラートを発出します。また、OTでは決められた時間に機械的に通信する端末が多く存在するため、{src_ip, dst_ip}のペア毎に、各時間帯での通信の有無を学習して、平常時は通信が発生する時間帯にもかかわらず、通信が発生しなくなった場合にもアラートを発出しています。 OTでは、工場等が稼働している日なのか、非稼働の日なのかによって、通信量や頻度の傾向が大きく異なる場合があるため、こちらの機能では、非稼働日や非稼働の時間帯を設定できるようにしています。非稼働日・時間帯の場合は、稼働日とは別のベースライン（上限値と下限値）を作成して検知に利用します。 流量ベースライン検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、送信元IPアドレス、宛先IPアドレス、アラート種別（上限値を上回った/下限値を下回った/通信が停止した）、データ種別（パケット数/バイト数）、観測した通信量、学習された通信量の上限値、学習された通信量の下限値、通信断の判定に利用されるカウンタの値などを表示しています。また、他の脅威検知と同様に、IPアドレスにマウスカーソルを合わせた際の端末情報の吹き出し表示もあります。 例えば、画像の2行目では、2019/08/20 6:30において、10.1.0.232から10.1.0.55へのパケット数が学習された上限値の483個に対して、10052個観測されており、上限値を超えたことでアラートが発出されています。 流量ベースライン検知ではさらに、通信量の変化や異常性を分かりやすくするために、次のような時系列グラフで、観測された通信の詳細を確認できるようにしています。 こちらのグラフでは、赤線が学習された上限値、青線が学習された下限値、黒線が観測値を表しています。また、グラフ上の点にマウスカーソルを合わせることで、観測された値や通信に含まれるサービスの内訳を吹き出しで表示しています。さらに、こちらの画面で分析に必要な情報が極力完結するように、画面右には、送信元IPアドレスと宛先IPアドレスに紐づく端末の詳細情報を表示しています。こちらのアラートや通信の詳細ページを見ることで、平常時からの急激な通信量の増加や攻撃等でのシステム停止による通信断などを早期発見できます。 周期異常検知 こちらは、アノマリ検知に属し、BACnet/IPに特化した脅威検知機能となっています。学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、信号処理技術を用いて、通信周期（60秒に1回、通信発生など）を抽出して学習します。検知期間では、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}毎に、通信周期を抽出し、学習された周期と比較して、周期外の通信が発生した場合、または周期的な通信が消失した場合にアラートを発出します。 こちらは、NTTの社会情報研究所で考案された 技術 がベースとなっており、複数のビルの通信データを分析して得られたノウハウに基づき、アルゴリズムの構築、特徴量・各種パラメータの設定を行っています。 周期異常検知の学習モデルは、次のようになっています。 こちらでは、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、学習された通信周期(PRI)、学習時に非周期として判定された通信数(non_periodic)、最終判定されたモデル(period=通信に周期性あり、non=通信に周期性なし、period_and_non=通信に周期性ありとなしが混在)などを表示しています。学習された通信周期(PRI)の項目は、(時間間隔, 通信回数)で表記されるようになっており、例えば、(62, 3)は、62秒毎に3回ずつの通信が発生することを意味しています。また、周期性なしの場合は(-1, 1)が表示されます。なお、1行目の[(62, 3), (-1,1)]は、通信を分解した際に、周期性のある通信と非周期の通信が混在していることを意味しています。 また、周期異常検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、アラートの内容(Non Periodic communication=周期外通信の発生、Lost Communication=周期通信の消失)、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ、ホバーで端末の詳細情報を表示しています。こちらのアラートを見ることで、BACnet/IPにおける不正なコマンドの挿入や通信断を早期発見できます。 サポート切れOS端末検知 こちらは、ルールベース検知に属します。サポート切れOSの一覧表を事前ルールとして保持しており、検知期間のトラヒックデータの中に登場する{IPアドレス, MACアドレス}の組み合わせ毎にOSを推定し、サポート切れOSの一覧表の内容とマッチする場合にアラートを発出しています。 前編でご紹介したネットワーク可視化機能でも、OS推定情報を表示していますが、あちらは主に定期アセスメント等で利用することを想定しているため、様々なメトリックを利用して、少しでも古いOSの疑いがあれば表示するようにしているのに対して、脅威検知機能は主にリアルタイムにアラートを監視する使い方を想定しているため、運用者の負担を軽減する（誤検知を減らす）ように、確実性が高く、改ざんが困難なメトリックのみを利用してOS情報を推定しています。 サポート切れOS端末検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、{IPアドレス, MACアドレス}の組み合わせ、OS情報に加えて、当該端末を特定しやすいように、MAC Vendorとホスト名の情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、サポート切れのOSを利用する端末がネットワークに接続された際に早期発見できます。 シグネチャ検知 こちらは、ルールベース検知に属します。セキュリティの脅威につながる通信パターンの情報（シグネチャ）を事前ルールとして保持しており、シグネチャの内容に合致する通信が観測された場合に、アラートを発出しています。 こちらの機能では、オープンソースのIT向けIDS(Intrusion Detection System)である「 Suricata 」と、Proofpoint社が配布している ルールファイル （シグネチャ）を利用しています。 ルールファイルには、セキュリティの脅威につながる通信パターンを表すルールが複数記載されていますが、一例を挙げると、次のようなものがあります。 alert http $HOME_NET any -> any any (msg:"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"; flow:established,to_server; content:"Authorization|3a 20|Basic"; nocase; http_header; content:!"YW5vbnltb3VzOg=="; within:32; http_header; content:!"Proxy-Authorization|3a 20|Basic"; nocase; http_header; threshold: type both, count 1, seconds 300, track by_src; reference:url,doc.emergingthreats.net/bin/view/Main/2006380; classtype:policy-violation; sid:2006380; rev:13; metadata:created_at 2010_07_30, updated_at 2020_08_28;) Suricataのルールのフォーマットは、以下のようになっています。 action: シグネチャにマッチした際のアクション（例では、alert） header: ルールを適用するプロトコル、IPアドレス、ポート番号、通信の向き（例では、http $HOME_NET any -> any any） rule options: オプション（例では、(msg: から 28;) までの括弧で囲まれた部分） 上記の例は、http通信かつ監視対象のネットワークから任意のポート、宛先への通信を検査し、rule optionsで指定された条件を満たした場合に、"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"(ベーシック認証でHTTPパスワードが暗号化されていないことを検出したという意味)のアラートを発出するルールになっています。 rule optionsには、細かなマッチ条件などを;で区切って複数指定可能で、例えば、 flow:established,to_server; content:"Authorization|3a 20|Basic"; の部分は、フローが確立していてclient→server方向であること、ペイロードに"Authorization: Basic"が含まれること、を表しています。 正確なルールの読み方は、 公式ドキュメント をご参照ください。 OsecTでは、Suricataの出力結果を、次のようなアラート画面として表示しています。 こちらでは、当該通信が発生した時刻、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号、プロトコル、マッチしたルールの内容とカテゴリ、Severity（1: high, 2: medium, 3: low）を表示しています。また、他の脅威検知機能と同様に、極力こちらの画面だけで必要な情報を確認できるように、ホスト情報をホバー表示しています。 こちらのアラートを見ることで、脆弱性を含む古いJavaの利用や平文でのパスワードのやり取りなど、セキュリティの脅威につながる通信の発生を早期発見できます。 アラート統合画面 OsecTでは、ここまでにご紹介した7つの脅威検知機能のアラートをまとめて確認できる画面も作成しています。 こちらは、日常的にアラートを監視する際にメインで利用する画面をイメージして作成しています。送信元IPアドレスや宛先IPアドレスなどの条件を設定して、アラートをフィルタリングできるため、特定のIPアドレスに着目して、複数の脅威検知のアラートの有無を横断的に確認したい場合などにも利用できます。 最後に 今回は、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの脅威検知機能についてご紹介しました。工場等のスマート化を推進していく上では、これまであまり検討が進められていなかった、OTのセキュリティ対策を考えることが非常に重要になってきます。本記事の内容が、ご検討のお役に立ちましたら幸いです。また、本記事の感想やフィードバックもお待ちしております。 ※2021年6月現在、OsecTの実証実験のトライアル利用者様を募集しております。無償でご利用頂けますので、国内に制御システムをお持ちの製造業・インフラ事業者の方で実際にお試ししたいという方がいらっしゃいましたら、是非 こちら からご応募頂けますと幸いです。

イノベーションセンターの小林です。普段は、ある日は部内情シス、ある日は情報セキュリティオペレーションをやっています。以前の開発者ブログに寄稿したこともあり、今回の開発者ブログリニューアルにもかかわりました。 今回のリニューアルにあたっては、各記事に対する社内レビューと記事公開のプロセスを「いい感じ」にしたいよねとの声があり、現時点ではそれなりに満足いくものを作れました。その中身を少しご紹介します。 レビュー 以前の開発者ブログの頃から、寄稿された記事は有志によるレビューを通してから公開するようにしていました。主に見ていたのは文法的な間違いがないか、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