セキュリティ の記事一覧

こんにちは、GMOインターネットグループの若林です！GMOインターネットグループは、11/14（木）15日（金）に実施された「CODE BLUE 2024」にTOPスポンサーとして協賛しました。イベント当日の様子に加え、出展ブースやスポンサーセッションについて、ご紹介いたします。 イベント概要 日時：2024年11月14日（木）〜15日（金）会場：ベルサール高田馬場（住友不動産新宿ガーデンタワーB2・1F）参加費用：有料・事前登録制開催形式：対面形式でのカンファレンス主催：CODE BLUE実行委員会公式HP：https://codeblue.jp/ CODE BLUE とは？ CODE BLUEは、世界トップクラスの情報セキュリティ専門家が集まり、最先端の技術や研究成果を共有する国際会議です。日本を含むアジア各国と欧米の著名な研究者が集い、国際的なセキュリティコミュニティの形成を目指しています。今回は第12回目の開催となり、基調講演としてARIA（英国高等研究発明庁）の「Safeguarded AI」プログラムのディレクターを務める研究科学者デビッド・A・ダリンプル氏を招へいするなど、大変盛り上がりを見せました。 ブース出展について GMOインターネットグループでは、ブースにて以下2つの企画を実施しました。 企画①「ガチャガチャを回して豪華景品をゲットしよう！」 ブースでは、豪華景品が当たるガチャガチャを実施しました！CODE BLUEは国際的なセキュリティカンファレンスであるため、多くの海外参加者の方々もブースに訪れていただきました。日本文化として人気の「ガチャガチャ」は海外勢から大変好評で、学生スタッフから海外の参加者に至るまで、幅広い層にご参加いただけました。 ガチャガチャのPOPも新しく制作しました！ ガチャガチャブース ガチャガチャの景品はハズレ無しで、基本賞としてGMOサイバーセキュリティbyイエラエのカルチャーを表したデザインのオリジナルステッカー、豪華景品としてSecurity SmartTrack Card (Airタグ)ほか5点を用意しました。 GMOイエラエ カルチャーステッカー 豪華景品もすべてSOLDしました！ ありがたいことに想定よりも多くの方にご参加いただき、2日間とも夕方にはすべての景品が完売となりました！ 今回のガチャガチャ企画では、CODE BLUE 2024に参加された皆さまにGMOのブースを訪れていただき、楽しみながら交流を深めることを目指していました。2日間でなんと350名の方々がガチャガチャに挑戦していただき、多くの方とコミュニケーションを取ることができました！ご参加いただいた皆様、本当にありがとうございました。 企画②「超簡単！スキミングのリスクをデモで体験！」 ブースでは、ガチャガチャに加えGMOサイバーセキュリティbyイエラエが開発したスキミングデモ体験コーナーを設置しました。この企画のために特別に制作された「スキミング体験用認証システム」を活用し、参加者は非接触ICカードリーダーを使ってカード情報の不正コピーを実際に体験しました。 スキミング体験用認証システム 体験された方には、オリジナルスキミング防止カードをお渡し！ 参加者にはノベルティとしてオリジナルのスキミング防止カードもプレゼントしました！そしてデモ体験の最後には、お渡ししたスキミング防止カードを非接触ICカードリーダーでスキャンし、カード情報の不正コピーがしっかり防げることを一緒に確認しました。CODE BLUEはセキュリティに関心がある方々が集まっているイベントだけあって、たくさんの方から「面白い！」とご好評をいただきました。 スキミングデモ体験ブースの様子 また、このデモ体験を通してセキュリティ対策の大切さや、日常での簡単な防御策についても一緒に学ぶことができ、参加者の皆様との交流を一層深めるきっかけとなりました。 スポンサーセッション スポンサーセッションとして、GMOサイバーセキュリティ byイエラエに所属するホワイトハッカー11名が登壇しました。 各分野のスペシャリストが集結し、最先端のサイバー犯罪とその対策について、質疑応答を含め語り合いました。 「GMOイエラエ全員集合！！進化するサイバー攻撃への対策最前線」 2024/11/15　16:00〜16:45 Track 2/OpenTalks（45分） 登壇内容については、以下の記事に詳細を記載しておりますので、ぜひご覧ください！「攻めと守りの融合」でサイバー犯罪に立ち向かう　ホワイトハッカー集団・GMOイエラエが語る、サイバーセキュリティの最前線 会場の様子 登壇者11人は非常に迫力がありました！ 会場には立ち見の方もいらっしゃるほど、たくさんのお客様にお集まりいただきました。今回の登壇を通じて、GMOサイバーセキュリティ byイエラエには、多岐にわたる分野のスペシャリストが在籍していることを強く印象付けられたのではないでしょうか。 AfterParty@CÉ LA VI CODE BLUE 2024の2日目終了後、お客様とセキュリティ関係者の皆様への感謝の意を込めて、渋谷のCÉ LA VI TOKYOでGMOサイバーセキュリティ byイエラエ主催のアフターパーティを開催しました。 このパーティには、CODE BLUE 2024に参加された皆様を含め、約400名近くの方々にご参加いただきました。セキュリティ関係者との交流を深めながら、皆様の心に残るような盛り上がりを見せるパーティーとなりました！ 最後に CODE BLUE 2024への協賛を通じて、参加者の皆様やスポンサー企業様を含め、多くの方々と貴重な交流を持つことができました！また、安心・安全なインターネット社会の実現を目指すGMOインターネットグループの取り組みやサービスを幅広い方々に知っていただく機会となり、多くの温かい反応をいただけたことを大変嬉しく思います。また来年お会いしましょう！

この記事は「GMOインターネットグループ Advent Calendar 2024」19日目の記事です。こんにちは、GMO NIKKOの横内です。普段はRuby on Railsを使った開発やプロダクトの脆弱性診断などセキュリティ関連の業務をしています。今回はWebブラウザで広く利用されているCookieの脆弱性について書いていきたいと思います。 はじめに 今回この記事を書こうと思った経緯としては、最近の業務でCookieについて理解を深める機会がありそれを共有しようと思ったからです。Cookieは普段あまり意識することなく使用していますが、適切な設定を行わなければ容易に脆弱性になりうることを再確認し、今回ブログにて共有しようと思った次第です。 Cookieの基礎知識 Cookieは、ウェブサイトがユーザーのブラウザに保存する小さなテキストファイルで、ユーザーの情報や設定を保持するために使用されます。具体的には、ユーザーがウェブサイトを訪問するたびに、ブラウザは対応するCookieをサーバーに送信し、ユーザーの状態を管理します。CookieはステートレスなHTTPプロトコルの性質上、ユーザーのセッション情報や個別の設定を維持するための重要な役割を果たします。 Cookieは「送信される対象のドメインやパス」「有効期限」のような複数の属性を持つ構造で、これらの属性によってCookieの動作や有効範囲が制御されます。 そして今回はCookieのセキュリティを強化するSecure属性、HttpOnly属性、SameSite属性について触れていきたいと思います。 Secure属性 Secure属性は、CookieがHTTPS接続時にのみブラウザからサーバーに送信されるように制限する属性です。これにより、通信が暗号化されていないHTTP接続を介してCookieが送信されるリスクを低減します。 Secure属性が設定されていない場合、それを利用しセッションハイジャックや中間者攻撃などの攻撃を受ける可能性があります。 セッションハイジャックの例 Secure属性を設定していないWebサイトを利用したセッションハイジャックの例を紹介します。 ① 攻撃者が公衆Wi-Fiネットワークを設定 まず攻撃者は、カフェや空港などの公衆の場で偽のWi-Fiアクセスポイント（ホットスポット）を設置します。正規のネットワーク名（SSID）に似せた名前を使用することで、ユーザーが誤って接続するよう誘導します。 ② ユーザーが公衆Wi-Fiに接続し、ターゲットサイトにアクセス そしてユーザーが攻撃者の偽装した公衆Wi-Fiに接続した状態で、ログイン機能のあるSecure属性が設定されていないWebサイトにアクセスします。Secure属性が設定されていないため、セッションCookieはHTTPおよびHTTPS接続の両方で送信されます。 ③ 攻撃者が通信を傍受し、セッションCookieを取得 攻撃者は、偽のWi-Fiネットワークを通じてユーザーとサーバー間の通信を傍受します。Secure属性が設定されていないCookieは、暗号化されていないHTTP接続でも送信されるため、攻撃者はセッションCookieを容易に取得できます。 ④ 攻撃者が取得したCookieを使用してターゲットサイトに不正アクセス 攻撃者は取得したセッションCookieを自分のブラウザに設定し、ターゲットサイトにアクセスします。これにより、攻撃者はユーザーのセッションとして認識され、認証された状態で不正にアクセスが可能になります。結果として、ユーザーの個人情報やアカウント情報が漏洩するリスクが発生します。 対策 CookieにSecure属性を設定し、HTTPS接続時のみ送信されるようにします。これにより、暗号化されていないHTTP経由でのCookie漏洩を防ぎ、セッションハイジャックのリスクを低減します。ウェブサイト全体でHTTPSを徹底し、Secure属性を適用することが重要です。 HttpOnly属性 HttpOnly属性は、Cookieがクライアントサイドのスクリプト（例えばJavaScript）からアクセスできないようにする属性です。これにより、クロスサイトスクリプティング（以下XSS）攻撃を通じてCookieが盗まれるリスクを低減します。 XSSの例 HttpOnly属性を設定していないWebサイトにてXSSを利用しCookieを悪用する例を紹介します。 ①攻撃者がウェブサイトに悪意のあるスクリプトを注入まず攻撃者は、XSSを利用してターゲットウェブサイトに悪意のあるJavaScriptコードを注入します。これには、コメント欄やフォーム入力など、ユーザーが入力を行う部分を狙うことが一般的です。 ②ユーザーが感染したページを閲覧ユーザーが攻撃者によって改ざんされたページを閲覧すると、悪意のあるスクリプトがブラウザ上で実行されます。 ③悪意のあるスクリプトが実行され、セッションCookieを取得実行されたスクリプトは、document.cookieを利用してセッションCookieを取得し、攻撃者が管理するサーバーに送信します。HttpOnly属性が設定されていない場合、JavaScriptからCookieにアクセス可能となります。 ④攻撃者が取得したCookieを使用して不正アクセス攻撃者は取得したセッションCookieを自分のブラウザに設定し、ターゲットサイトにアクセスします。これにより、ユーザーのセッションとして認識され、不正にアカウントにアクセスできます。 対策 CookieにHttpOnly属性を設定し、JavaScriptからのアクセスを防ぎます。これにより、XSS攻撃によるセッションCookieの盗難を防ぎ、セッションハイジャックのリスクを大幅に低減します。HttpOnlyを有効にすることで、ブラウザ上での不正なスクリプト実行からCookieを保護します。 SameSite属性 SameSite属性は、Cookieがクロスサイトリクエスト（異なるサイトからのリクエスト）と共に送信されるかどうかを制御する属性です。Strict、Lax、Noneの3種類があり、特にクロスサイトリクエストフォージェリ（以下CSRF）攻撃の防止に有効です。 Strict 完全に同一サイトからのリクエストのみCookieが送信されます。Lax クロスサイトリクエストではCookieが送信されず、トップレベルナビゲーションでは送信されます。None クロスサイトリクエストでもCookieが送信されます。 SameSite属性が適切に設定されていない場合、それを利用しCSRFやセッションハイジャックの攻撃を受ける可能性があります。 CSRFの例 ①ユーザーがターゲットサイトにログインユーザーは正規のウェブサイトにログインし、認証Cookieがブラウザに保存されます。このとき、SameSite属性が適切に設定されていない場合、他サイトからのリクエストでもCookieが送信されます。 ②攻撃者が悪意のあるサイトを用意攻撃者は、ユーザーを誘導するための偽のウェブサイトやメールを用意します。このサイトには、不正なアクションを実行するリクエストを自動的に送信する仕掛けが組み込まれています。 ③ユーザーが攻撃者のサイトを訪問し、不正なリクエストを送信ユーザーが攻撃者のサイトを訪問すると、悪意のあるスクリプトやフォームが自動的に実行され、ターゲットサイトへの不正なリクエスト（例：送金リクエスト）が送信されます。このとき、SameSite属性がNoneや適切に設定されていないため、認証Cookieがリクエストと共に送信されます。 ④ターゲットサイトがリクエストを正当なものとして処理ターゲットサイトは受信したリクエストを正当なユーザーからのものと認識し、リクエストされたアクション（例：送金）を実行します。これにより、ユーザーの意図しない操作が行われ、被害が発生します。 対策 CookieにSameSite属性をStrictまたはLaxに設定し、他サイトからのリクエストでCookieが送信されないようにします。これにより、CSRF攻撃を防ぎ、認証Cookieの不正利用を防止します。 最後に 今回はCookieの脆弱性について書いてみましたがいかがだったでしょうか。 日々の開発業務に取り組む中で、Cookieについてはまだまだ理解が足りない部分があることに気づきました。今回の記事を書くことでCookieの重要性やセキュリティについてしっかり学ぶことができてとても良かったです。これからの開発ではCookieの管理も意識することでよりセキュアな開発をしていきたいと思っています。皆さんもぜひCookieの扱いに注意してみてください！

GMOインターネットグループは、世界トップクラスの情報セキュリティ専門家が集う国際会議「CODE BLUE 2024」にトップスポンサーとして協賛、登壇いたしました。このレポートではパネルディスカッション「GMOイエラエ全員集合！！進化するサイバー攻撃への対策最前線」の様子についてお届けします。 ホワイトハッカーが語る、最先端のサイバー犯罪とその対策 デジタル社会の進展とともに、サイバー攻撃の手法は日々進化を遂げています。企業や組織を狙ったランサムウェアやフィッシング詐欺など、その手口は巧妙化の一途をたどり、従来の防御態勢では対応が困難になりつつあります。近年進むIoTやスマートホームもこうしたサイバー攻撃の糸口となることもあり、現代のサイバーセキュリティ対策は技術の進化や人材育成・組織構造など多角的なアプローチが求められるといえるでしょう。こうした最先端のサイバー犯罪とその対策について、GMOサイバーセキュリティ byイエラエ（以下、GMOイエラエ）に所属する各分野のホワイトハッカー11名が語りました。 「困っている誰かを助ける」を軸に据えた技術と組織 林：本日はたくさんの方にお越しいただき、ありがとうございます。「GMOイエラエ全員集合！！進化するサイバー攻撃への対策最前線」というタイトルで、オープントークをさせていただきます。モデレーターの林（林 彦博/上席執行役員）です。 林 彦博（上席執行役員） 三村：同じく、モデレーターの三村（三村 聡志/セキュリティエンジニア）です。GMOイエラエはペネトレーションテスト（※1）のイメージが強いですが、実際には攻撃側に強い「レッド」、守りに強い「ブルー」、どちらも兼ね備えた企業です。本日はそんなイエラエの奥行きを皆様に感じていただければ幸いです。※1 ネットワークやシステムのセキュリティを検証するために、専門家が実際に攻撃を仕掛けることでセキュリティの対策状況やリスクを評価する取り組み。 三村 聡志（セキュリティエンジニア） 三村：というわけで、まずは牧田（牧田 誠/代表取締役社長）さんに、GMOイエラエについて聞いてみましょう。牧田さん、GMOイエラエはどういう会社でしょうか？ 牧田：GMOイエラエの根底にあるのは「誰かを助ける」精神です。ただし、誰かを助けたいなら自分たちが強くなければいけません。そこで「強い人」たちを募り、力を合わせて誰かを助けようとしている会社だと思っています。 林：ありがとうございます。では次に、インターポールで働いていたという福森（福森 大喜/サイバー犯罪対策センター長）さん。大変興味深いお仕事ですが、可能な範囲で、何をしていたのか聞かせていただけますか？ 福森：インターポールは皆さんご存知のように、国際的なサイバー犯罪への対処や、対処するための組織を育成していく組織です。そこで犯罪捜査の支援やトレーニング、各国警察官に対するものをやっていました。 林：「守る」という観点からいえば、ルスラン（サイフィエフ ルスラン/執行役員）さん。日本企業のセキュリティは破りやすいですか？ ルスラン: 非常に破りやすいですね。 林：（笑）。これは手厳しい。阿部（阿部 慎司/執行役員）さん、SOC（Security Operation Center）（※2）サービスを提供するイエラエとして、この状況にどう立ち向かいますか。※2 組織のITインフラを24時間365日監視し、セキュリティインシデントの早期発見や対応を行う専門チームまたは施設。 阿部：我々は誇りを持ってSOCサービスを提供していますが、残念ながら「痒いところに手が届かない」部分も残されているのが実情です。 例えばですが、SOCという形に必ずしもこだわらず、「イエラエとご契約いただければ、どの製品でも必ず見解を出す」のように、踏み込んだサポートを提供できるとよりよいのかなと。「皆さんの困りごとに対して何ができるか」という軸は変えずに、「痒いところ」を逃がさないような新しい形のSOCが実現できるように頑張っているところです。 阿部 慎司（執行役員） 林：なんて言っていたら、馬場（馬場 将次/セキュリティエンジニア）さんと目が合いましたね。何かご意見はありますか？ 馬場：GMOイエラエのいいところは、他社の製品報告についての脆弱性を発見すると、会社から報奨金を支給してもらえるところです。自分は最近、太陽光発電を自宅に導入したのですが、さっそく脆弱性を発見し、報告して報奨金をもらいました（笑）。 どのようなプロダクトでも良いわけではなく、ある程度普及しているプロダクトという前提はありますが、脆弱性を見つけるのが得意な人は、ぜひGMOイエラエに入ってください。 林：今年は何件ぐらい見つけたんですか？ 馬場：10件ほどですね。でも、もっと見つけている人も全然います。実は世の中のプロダクトって脆弱性だらけなので、みんなで一緒に社会を守れれば嬉しいですね。 馬場 将次（セキュリティエンジニア） 林：攻撃の技術を守りに使っていく、まさにホワイトハッカーですね。そういえば市川（市川 遼 開発部長）さんは今、現状を可視化してどういう対策をしていけばいいか示すというサービスを提供していますね。せっかくなのでご紹介いただけますか？ 市川：私が取り組んでいるのは「GMOサイバー攻撃ネットde診断」というサービスで、一般的にはASM（Attack Surface Management）（※3）と呼ばれるものです。他にも脆弱性診断をツール化・自動化して、お客様のセキュリティに貢献するサービスも提供しています。※3 インターネットから アクセス可能なIT資産の情報を調査し、それらに存在する脆弱性などのリスクを継続的に検出・評価する取り組みです。 これらのサービスはいわば、我々の持っている知見をサマライズし、ツールに落とし込んだものです。イエラエの技術力を皆さんにおすそ分けするイメージですね。 林：素晴らしいです。奥野（奥野 史一/執行役員）さんはどうですか？ 奥野：私は官公庁の事業を担当し、ペネトレーションテストからサイバー演習まで幅広い領域を扱っています。最近ではグローバルの官公庁、たとえばモンゴルのウランバートル市に「ネットde診断」が入りましたし、大手銀行の方でも脆弱性やスマホアプリの診断をしています。 このメンバーを見ていただければわかるように、せっかくの技術がグローバルに出ないのはもったいないので、これからどんどん世界に出ていきたいなと、一生懸命やっています。 奥野 史一（執行役員） 林：広い視野で取り組んでいるわけですね。モンゴル出張はよく行かれるんですか？ 奥野：行くこともあります。2月に行ったときはマイナス30度でした。覚悟して行きましたが、意外と大丈夫でした（笑）。これだけ寒いと、データセンターが効率的に冷えるのでいいですね。ちなみに、モンゴルの一番のおもてなしは羊の丸焼きです。2回出てきました。 組織&人材育成に多くのメリットをもたらすCTF 林：さて、CTF（Capture The Flag）（※4）については、小池（小池 悠生/執行役員）さんに聞かなければなりません。技術をどう伸ばすか、素晴らしいエンジニアをどう育成していくか。この点について、どうでしょうか。※4 セキュリティ分野で行われる競技形式のセキュリティコンテスト。参加者は専門技術や知識を駆使して特定の課題を解くことで「フラッグ」を獲得し、時間内に獲得した合計点数を競い合う。 小池：私はIoTのペネトレーションまわりのマネジメントをしている立場になりますが、それとは別に、執行役員として会社ブランドの取りまとめにも携わっています。そのための取り組みの一例が、先ほど出てきた脆弱性発見の報奨金制度や、CTFへの参加推奨ですね。 これは牧田さんも同意してくれるところだと思うんですけど、CTFセキュリティコンテストで上位の成績を上げているような人たちは、実際の業務においても非常に優秀な成果を出してくれます。 小池 悠生（執行役員） 三村：うちの会社は、社長が「鶴の一声」で採用を決めることがありますが、そうしてジョインする方は、一芸に秀でている人が多い印象ですよね。 牧田：一芸はめちゃめちゃ大事です。まさにCODEBLUEで出会ってスカウトした方もいますが、とても活躍されているので、「鶴の一声」形式は間違ってないはず（笑）。みなさん素晴らしい方ばかりです。 林：王（王 瀚邦/リバースエンジニア）さんもCTFのトッププレーヤーとして活躍されていますよね。何をモチベーションにされていますか？ 王：CTFに取り組み始めたのは4年ほど前になりますが、私が好きなパズルゲームのように「壊して、つくる」楽しみがモチベーションになっています。これは、リバースエンジニアリング（※5）にも似ている部分ですね。※5 既存のプログラムから設計情報を抽出し、構造や動作を解析する技術。動作理解や改良、セキュリティ検証に活用される。マシンコードに複合させたり、一般的に組み立てたりする点に近しいものを感じます。そのうえで、物事がどのように機能しているか解き明かすことに楽しみを見出しています。 三村：私も以前、CTFの力を高めるために「Baba Is You」（思考力が鍛えられると話題のインディーズゲーム）をやれと言われたことがあります。馬場さんは普段、どういう形で頭を鍛えたり休ませたりしていますか？ 馬場：頭の鍛え方はやっぱり脳トレがベストですね。「Baba Is You」のいいところって、「こういう操作はできないだろう」という思い込みがあると、絶対に解けないところなんです。機転を効かせた発想を学べるので、あれは真面目に、良いトレーニングになると思いますね。みなさんもBabaになりましょう（笑）。 三村：CTFでも、本来の用途からひねったデータを使って攻撃コードを組んだりとか、そういうのが求められるので、柔軟さは必要になってきますもんね。他にも、教育とか育成という観点で、ルスランさんいかがですか？ ルスラン：皆さんにぜひ育てていただきたいのは、クリエイティビティです。それがないと、いくら勉強しても限界があるので…。頭を柔らかくして「どうやって解くべきか」の引き出しを増やし続けるのが一番良いと考えています。 サイフィエフ ルスラン（執行役員） 林：福森さんはどうですか？インターポール時代にこうしたストーリーはありませんでしたか？ 福森：インターポールは197か国からなる組織なので、中には「どうせ自分たちなんかダメだろう」「FBIが出てきたから、出る幕がないな」と卑屈になってしまう人もいました。そういう人をいかにモチベートするかは、大きな課題でしたね。 そんなときには、たとえば「フリーツールだけでも、FBIが見つけられないような脆弱性を見つけられる」という経験をさせ、小さい成功体験から自信を持ってもらうようにしていました。 福森 大喜（サイバー犯罪対策センター長） 三村：守るためには技術だけではなく、人とのつながりも重要です。当社には仲間づくりのプロである林がおりますが、そういう点ではどうでしょう。 林：セキュリティへの取り組みを自分だけで考えるのには限界があるので、外の知見やコミュニケーションがすごく大事だなと、昔から思っていました。なおかつ、セキュリティの人たちって、ときには「余計なお世話」と思えるくらい親切な人が多くて、質の高いアドバイスをもらえるのが嬉しいところです。 質のいいコミュニティとの縁をつなぎ、いい仲間作りをしていくことが、巡り巡ってセキュリティへの知見のレベルも高めてくれているような気がします。 攻撃の手法から対象まで、日々進化するサイバー攻撃との終わりなき戦い 三村：小池さんは最近、「面白いな」と感じた攻撃や、CTFはありますか？ 小池：NDAの関係であまり言えなかったりするんですが、最近面白いなと思ったのは、いわゆるプロンプトインジェクションですね。攻撃者がLLMに対して与えるプロンプトを上書きして、LLMが意図しない挙動をさせるという。 そこからいろんな攻撃に繋げていくわけですが、対策はいたちごっこになっていまして、対策をさらに回避させるような攻撃があったりします。 例えば、モールス信号をプロンプトとして与えるという攻撃手法が最近有名になりましたね。自然言語での入力は対策されていますが、モールス信号のような非言語は想定されていなかったので、上位モデルのLLMではモールスでそのまま返しちゃう、と。 牧田：それでいうと、スマートシティ社会になっていく中で、アタックベクターも多彩になってますね。手法自体もリビングオフザラウンドとか、そもそもマルウェアを使わないとか。 太陽光発電の脆弱性でいえば、天気がいいときは蓄電池に積極的に貯めて、雨の日は使用を控えるといった制御機器の脆弱性には注意が必要です。またこうした制御機器は、他の家電と連携して操作するリモコンの役割も果たしていたりするので、いま話題の闇バイトにも悪用されかねない怖さがあります。 林：予想もしないリスクが潜んでいるということですね。次は阿部さん、SOCやブルーチームのホットトピックがあれば伺いたいです。 阿部：他の方からもお話があった通り、ちまたを賑わせるインシデントはものすごく多く、攻撃はどんどん分かりにくくなっています。その結果、守る側としても、トレーニングの仕事やインシデントレスキューの機会が増えてきている印象です。 三村：会社で見ていても、SOCの名将と呼ばれる阿部さんの額に流れる汗の量が日に日に増えているのを感じます（笑）。 阿部：（笑）。ここ数年で流行っているEDR（※6）やAIのふるまいなど、守るべき点は多岐にわたります。外部脅威からの保護はもちろんですが、組織やビジネスとしてのリスクも考えながら対策を講じなければなりません。※6 エンドポイント（PCやスマートフォンなど）を監視し、不審な挙動を検知・分析して適切な対応を行うセキュリティ対策。 そのため、これからのセキュリティ事業者には、単に知見を持つだけでなく、クライアントと幅広く同じ目線で考え、積極的に提案できる会社であることが求められるでしょう。そうしたときにイエラエの強みが生きるように思います。 AI活用も進めつつ、ホワイトハッカーを「億万長者」に 三村：ASMではどうですか？ 市川：ASMについては、昔から言われてきた「サーバーのバージョンをちゃんとアップデートしましょう」といったレベルから大きく変わったところはありません。可視化が進んだことにより、対策しやすくなった面はありますが。 ただ、世の中のサイバー攻撃は、未知のゼロデイ（※7）がどんどん飛んでくるというよりも、権限設定が甘かったり、個々のPCが狙われていたりするものが圧倒的に多いので、こうした対策を徹底するのは依然として重要と言えます。このあたり、会社のガバナンスがうまく効いてないとかなり危ないことになるケースもあります。※7 未公開で修正パッチが存在しない脆弱性を指す。攻撃者は開発者が脆弱性を認識し対処する前に攻撃を仕掛けるため、非常に危険とされる。 市川 遼（開発部長） 林：王さんにも聞いてみましょう。王さん、テクノロジーやエンジニアリング周りで、ホットトピックはありますか？ 王：最近、CTFのリバースエンジニア・チャレンジに参加したのですが、他のリバースエンジニアとどうやってその課題を解決したかを話したら、みんな、「AIに入力しただけだよ」と。 どうやらAIは、課題のコードを入力するだけで、それを解いてくれる段階まで来ているようです。なので「僕はもう必要とされていない」と悲しく思うと同時に（笑）、AIの使い方も学ばなければと感じています。 王 瀚邦（リバースエンジニア） 三村：では締めとして牧田さんから、今後イエラエという船がどう進んでいくのかという展望、これからイエラエに来てみたいという人に向けてひとことお願いします。 牧田：我々イエラエの手が届く範囲は、今や日本全体に広がりました。とりあえずここをやり切り、その後はアジア、そして世界へと、グローバルに戦いの場を移していく所存です。 また僕のサブミッションとして、「社内のセキュリティエンジニアを億万長者にする」ことがあります。みんなが成果を出して巨万の富を得られれば、子どもたちが「ホワイトハッカーになりたい」という世界観ができるかもしれません。そうなれば、そのエコシステムで社会全体が良くなっていくじゃないですか。 エンジニアに利益を還元することで、自然と次世代を担う子どもたちから「ああいうふうになりたい」と思ってもらえる未来を実現したいです。多分、ここにいるみんなも初めて聞く野望かもしれませんが（笑）、そんな未来がたぐり寄せられるように、日々の業務に邁進します！ 牧田 誠 代表取締役社長

この記事はGMOインターネットグループ Advent Calendar 2024 9日目の記事です。GMOブランドセキュリティ株式会社の寺門です。今回はデジタル証明書の基礎技術であるX.509とVMCについて紹介します。 はじめに 近年、フィッシング詐欺やスパムメールが増加し、電子メールの信頼性を向上させるための技術が求めらています。その中で注目されるのが、BIMI（Brand Indicators for Message Identification）とVMC（Verified Mark Certificates）です。特にVMCは、ブランドロゴの信頼性をデジタル証明書で保証する仕組みであり、その基盤技術としてX.509が利用されています。 本記事では、X.509の基本的な仕組みから始め、BIMIとVMCの役割、そしてX.509とVMCがどのように関連しているのかを簡潔に解説します。 X.509とは X.509の概要 X.509はデジタル証明書の国際標準規格（ITU-T勧告）として、1988年に初めて制定されました。この規格は、公開鍵インフラストラクチャー（PKI, Public Key Infrastructure）の一部として機能し、デジタル証明書を通じて、エンティティのアイデンティティを検証するために使用されます。インターネットの安全性を支える重要な基盤技術であり、以下の分野で利用されています。 SSL/TLS証明書：ウェブサイト間の暗号化通信を実現コード署名：ソフトウェアの信頼性を保証電子署名：電子的な文書の改ざんを防止電子メール証明書：メールの真正性を確認 X.509証明書の構造 X.509証明書には、以下の重要なフィールドが含まれています。 バージョン番号：使用するX.509規格のバージョン、一般的にはv3シリアル番号：証明書を一意に識別するための番号署名アルゴリズム：証明書の信頼性を保証するための暗号化アルゴリズム発行者（Issuer）情報：証明書の発行元の詳細情報有効期限：証明書が有効な開始日と終了日対象（Subject）情報：証明書の対象となるエンティティの情報拡張フィールド：特定用途のための追加情報公開鍵：対象エンティティの公開鍵 拡張フィールドの役割 X.509 v3で導入された拡張フィールドは、証明書の柔軟性を高めるために設計されています。技術書には拡張フィールドの構造が定義されており、用途に合わせて様々な拡張子を設計することができます。 LogotypeImageInfo ::= SEQUENCE { type [0] LogotypeImageType DEFAULT color, fileSize INTEGER, -- In octets xSize INTEGER, -- Horizontal size in pixels ySize INTEGER, -- Vertical size in pixels resolution LogotypeImageResolution OPTIONAL, language [4] IA5String OPTIONAL } このフィールドは、VMCのような新しい技術にも対応できる拡張性を提供しています。 BIMI/VMCとは BIMIの目的と仕組み BIMI（Brand Indicators for Message Identification）は、ブランドロゴをメールクライアント上に表示するための仕組みです。この技術は、メールの送信者がブランドロゴを正当かつ安全に表示できることを保証します。これにより、次のような効果が期待されます。 ブランド認識の向上：受信者がメールを一目で信頼できるセキュリティの強化：フィッシング詐欺やなりすましのリスクを軽減マーケティング効果の向上：ブランドイメージの一貫性を保つ BIMIを導入するためには、送信ドメイン認証技術（SPF、DKIM、DMARC）のセットアップが必要であり、さらにVMCによるブランドロゴの認証が必須です。 VMCとは何か VMC（Verified Mark Certificate）は、BIMIの実現に必要なデジタル証明書です。特別な監査を通った会社が発行し、ブランドがロゴを正当に所有し、使用する権利があることを商標権を使って証明します。VMCの主な役割は以下の通りです。 ロゴの正当性の保証：証明書内に格納されたブランドロゴが改ざんされていないことを確認ブランドの信頼性の向上：メール受信者に対して、送信者が認証済みであることを保証BIMIの技術的基盤の提供：BIMIの使用に準拠するための証明書 X.509とVMC VMCにおけるX.509の応用 VMCは、X.509証明書の拡張フィールドを活用して、ブランドロゴに関する情報を格納します。具体的には、以下のような仕組みが使われています。 SVGロゴのエンコード：ブランドロゴはSVG形式で証明書に埋め込まれます。SVGデータは署名され、改竄を防止します。特定のOID（Object Identifier）：X.509証明書の拡張フィールドには、ロゴに関する追加情報を記録するためのOIDが指定されています。具体的には、OID: 1.3.6.1.5.5.7.1.12（logotype extension）や、OID: 1.3.6.1.4.1.53087.4.1（pilot identifier extension）などを使用し、RFC3709やRFC6170に定義されています。署名アルゴリズム：SHA-256やRSAなど、強力な暗号技術を使用して証明書全体を保護します。 実際のVMCの中身を見てみるとイメージが湧きやすいと思うので、CNNのVMCを見てみましょう。 terakado@01-0083444 Downloads % openssl x509 -noout -text -in cnn.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0b:6b:bf:fd:69:86:05:b2:27:8e:8b:14:43:e5:ce:3b Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert, Inc., CN=DigiCert Verified Mark RSA4096 SHA256 2021 CA1 Validity Not Before: Jul 15 00:00:00 2024 GMT Not After : Aug 15 23:59:59 2025 GMT Subject: jurisdictionC=US, jurisdictionST=Delaware, businessCategory=Private Organization, serialNumber=2976730, C=US, ST=Georgia, L=Atlanta, street=190 Marietta St NW, O=Cable News Network, Inc., CN=Cable News Network, Inc., 1.3.6.1.4.1.53087.1.13=Registered Mark, 1.3.6.1.4.1.53087.1.3=US, 1.3.6.1.4.1.53087.1.4=5817930 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:86:0f:c0:72:55:a7:2d:d6:dd:61:a6:99:b1:87: bc:a7:e7:8a:d1:af:ee:cc:c0:e4:90:4f:16:40:66: 36:5f:c3:14:86:9f:82:aa:9c:ca:67:c2:bc:85:e9: ca:60:f9:5b:c6:6d:61:07:d7:d6:ae:50:a5:0d:d0: 44:a6:7c:96:87:08:de:f5:9d:60:2d:58:4f:71:6a: 36:8f:3c:4e:9f:58:5f:1f:ef:84:16:14:5f:5a:04: 16:b0:dc:d5:ae:b0:d7:94:6c:35:ee:42:e9:55:0d: 1e:56:98:ea:28:c9:e5:4d:62:11:2b:34:56:8e:10: 30:ff:92:7a:cb:45:1e:28:ca:a7:fa:b3:9a:09:03: a5:61:fa:77:6c:3a:a7:15:62:b2:01:b3:4b:af:a8: 65:6c:57:48:1b:33:c7:30:62:c7:08:d1:d6:c0:ed: 50:c3:53:d9:2a:96:e8:28:78:72:18:55:ad:85:76: a6:1b:78:8d:9c:66:23:c4:3c:ed:3d:eb:24:6b:52: e6:66:38:93:2f:b4:23:05:fa:d3:88:28:c1:e0:7d: 13:65:03:b3:bd:6c:03:d6:6c:7f:3f:cb:86:36:61: 23:aa:82:56:28:2f:71:d1:97:68:8c:24:f4:ee:9a: 68:3b:a3:82:7a:f4:47:55:4b:93:df:8c:3b:f1:76: c7:df Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: BE:9F:BD:8D:57:6D:95:B5:AD:63:C3:97:4E:AB:A8:84:5D:3A:07:F5 X509v3 Subject Key Identifier: 2B:55:A5:D5:6F:43:8D:BB:32:BA:45:B8:DC:66:A0:F9:85:27:43:49 X509v3 Subject Alternative Name: DNS:cnn.com X509v3 Certificate Policies: Policy: 2.16.840.1.114412.0.2.5 CPS: http://www.digicert.com/CPS Policy: 1.3.6.1.4.1.53087.1.1 X509v3 Extended Key Usage: Brand Indicator for Message Identification X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertVerifiedMarkRSA4096SHA2562021CA1.crl Full Name: URI:http://crl4.digicert.com/DigiCertVerifiedMarkRSA4096SHA2562021CA1.crl Authority Information Access: CA Issuers - URI:http://cacerts.digicert.com/DigiCertVerifiedMarkRSA4096SHA2562021CA1.crt X509v3 Basic Constraints: critical CA:FALSE 1.3.6.1.5.5.7.1.12: image/svg+xml0#0!0...+............c<f.bb.JxWl..v8.0.......data:image/svg+xml;base64,H4sIAAAAAAAACp1UTW/bOBA9x7+Cq54KkDSHFL+MOEUbFE2BblFgAV8XrqLGwmptQ1bktL9+31AJ0kNQYAsk5HiGnHnz5lGXbx7+7cXUDqfusF9XpE0l2n1zuO32d+vqfvymUvXmanH5h1LiQ7tvh+14GFbi7e3hays+9v39aSwuYWuNy1L8tfkg3j8cD8MovvT3d+rjXuji3Mw1ViJoY8S7+66/Fea1EEoh/Wm6+xmErcTX7an9Mhy+dX27rsZu/10dT5XobtfVp+33dvibKgHk+9O62o3jcbVcns9nfXb6MNwtrTFmiZSPR1YPfbf/56WDlHNelmi1mLr2/O7wsK6MMCKHqP28liSr03HbAMhxaE/tMLUVMI/d2LdX158/Xy5nc3F53I47Acj9unp1fQ0UYBOI/4wxay+dddpONpCuGyPJ6FoFuClrUhS0lZZ0ahTpLI32yumEPSmvI++NirqWRpGHz+morFUE0j+FWMs6BZ0XF71CcqfIeD7vUIAPJ23x7xVZ3IracSRLQnFc1KHsebKGq/8CV9JOWqSCPyuDmI3IR047LuxxUGWgAIbAfvIvIkgzglqSZgQBCPIjAsocAgJ0AI4kJFUrXop1YxMKNZw9MQ3W4KKvGWMxeQX+Of7sl8U/2zug3nk7KZd12Clv0VQCBBz1GSxHppV8gknBcl8NyRTBQCQmxEeOzHFedwTObOPQmjQyYLoYCmxY6A0QJpVxES0hWnMG9GUlqwomCGtqkiEzAko8DCCdTSaZFhe4HzX97v1NEdxNEd+PavkLfVL0GG6d0H8DjiTYYE2hFpnI6U3pnFf0bFA44DwmBTgqzBsvG5cs6xBjYBnJwDMHEslgVZERVKQsJ85F5iRtSe148qxv/HA1Q0iIl1lCSeDAMus14/L8IHKQrDjsOqGeYz/OMmSeBgtNsprABJJBZ6rmfGAmzyBfgkhPEO0TxPQEMchZ6M8gjfSEnV+znB/cs6s4LMeYOyT+nwB5bjtWaZyI2+W60DxrQNFMeiwma0DVEBtEoObJ10XuRQ/c1/SkoN+7zQ+DStsYCV5ZUaHhZ2KgACrfJY4ZrLas0MVOhRJwzBsK43tVPioJf6dHU5ZfN875jYvlMS4uri0aDxK/eR7QJESIp+/kT/qchcxf96vFf2yTubu9BgAA CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 55:59:53:AE:30:96:00:80:6C:D2:EB:52:08:A6:C9:9E: 93:18:28:AC:10:56:B4:42:1C:55:36:15:4C:5F:75:AC Timestamp : Jul 15 18:58:05.865 2024 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:21:00:93:06:5D:61:37:F4:AF:09:9E:6E:29: 9C:21:E5:86:BF:CD:75:06:2E:DC:44:6C:8A:A6:19:97: 89:FA:3E:D9:A1:02:20:1D:22:99:C3:09:F4:00:AF:E4: BD:01:D0:56:00:95:20:07:4A:DE:13:E0:B1:DB:EC:CA: FC:8C:88:EC:8C:9C:28 Signature Algorithm: sha256WithRSAEncryption Signature Value: d1:57:25:f2:2a:83:b1:19:f3:63:ba:44:f5:a5:a9:af:61:3d: 60:8b:e8:91:2d:1a:38:21:47:74:2f:8e:eb:0d:a1:2c:97:68: 6f:32:c2:21:2a:b4:1a:1d:35:e1:60:4f:4d:ef:aa:30:b0:cb: a8:88:b0:e8:0a:b5:f5:d2:3f:22:75:46:42:47:ec:ff:75:bc: fc:dd:92:24:a4:b5:03:1c:b2:90:0d:0b:d6:7a:c1:6b:80:e5: 56:34:05:fd:49:a4:7d:c7:8f:b6:48:47:36:8d:97:24:93:07: a8:79:ea:8e:0e:52:79:1d:02:31:93:8f:a4:44:44:37:8f:56: 5f:41:57:d9:87:96:d7:33:3f:a8:22:6b:fd:fa:54:93:64:d1: f4:76:3b:11:83:69:73:7d:58:c5:82:54:6e:f8:2a:3c:6a:a8: ff:e1:e2:b6:b6:68:56:29:64:d2:dd:df:34:6e:f1:aa:3a:9e: 44:cb:67:21:08:2e:a2:7b:43:fd:45:32:50:0e:44:71:2e:ee: 8f:08:22:3c:01:d6:4f:28:81:df:51:b2:91:82:69:b0:d8:fd: bb:a3:77:e3:35:4c:8a:81:c4:3e:71:68:ce:37:1a:ca:a8:8c: ef:f6:40:11:67:93:28:23:76:d9:4b:55:8f:62:13:53:a3:ba: bb:92:f9:ee:89:91:b7:f1:4f:95:f6:e4:3b:ee:76:a7:7c:7e: e1:d8:55:03:d9:70:31:50:13:38:13:62:75:58:c1:9f:35:a8: e5:e2:5a:e2:32:ff:02:cf:fa:da:9d:f3:f3:c0:d2:76:9f:3d: f7:1c:8e:00:c1:a7:7d:d1:9f:38:45:a4:c7:64:2b:3b:8b:2c: 7c:c3:2b:35:a8:6b:17:58:c0:ed:0d:70:80:99:1a:ae:e8:c4: 99:6c:8e:c5:15:07:d5:fd:f0:09:a7:a2:e6:42:2f:5a:5a:ac: 8b:bf:6f:61:91:fa:38:74:9a:fd:50:86:84:85:22:2a:a2:25: 21:22:2b:cb:70:a0:fa:3d:43:31:a0:f7:d8:45:8e:61:6b:a1: a5:0a:ac:4f:8d:39:93:38:cc:3c:9d:43:80:69:5e:1a:b4:17: 6e:3c:8f:e3:72:cb:93:1f:1c:2e:1d:71:ee:02:da:34:3e:dd: 33:b9:e0:90:ac:a3:e2:3b:dd:fd:73:fa:a8:9a:6d:55:ce:68: 70:89:59:b7:a0:68:f6:16:5e:43:2f:cb:f5:32:f2:95:ae:51: 38:27:0e:28:20:cf:bd:d3:74:a6:98:33:9a:23:12:09:60:92: 7b:1d:2a:b0:d4:99:18:37:58:50:33:78:0a:43:47:c6:81:37: 1c:a7:9d:b1:d3:04:fe:3c まず注目していただきたいのは「X509v3 extensions」と表示されている部分です。ここにエンベッドされるデータこそがX.509の拡張子を利用している部分になります。「Authority Key Identifier」や「CRL Distribution Points」などはSSLを知っている方にとっては見慣れている内容かと思います。 次に見ていただきたいのは拡張子が「1.3.6.1.5.5.7.1.12」と記されている部分です。この拡張子がVMC特有のロゴ情報になります。見て分かる通り、SVG形式のロゴデータをbase64で埋め込んでいます。 正式にはこの拡張子は「Logotype extension」という名前がつけられているのですが、OpenSSLでは名前ではなくOIDで表示されています。（寺門は最初ここにすごく戸惑いました） いろいろ調べた結果、OpenSSLにはデフォルトで「Authority Key Identifier」などよく使用される拡張子はOIDで認識してくれるように作られており自動で認識してくれますが、「Logotype extension」はあまり使用されていないことから「この拡張子は何なのか知らないけど、こんなデータが埋め込まれてたよ」と言う感じでOIDとデータを表示してくれているそうです。 これにより、VMCは既存のPKIインフラとシームレスに統合され、新しい用途に対応できる柔軟性を備えています。 技術的メリット VMCがX.509を基盤とすることで得られるメリットは以下の通りです。 互換性の確保：インターネット全体で使用されているPKIと完全に互換性を保つ信頼モデルの活用：既存のCAネットワークを利用して、証明書の信頼性を保証柔軟な拡張性：X.509の拡張フィールドを使用して、新たな情報や用途を追加可能 VMCの発行プロセス VMCを取得するための手順は以下の通りです。 ドメイン認証の設定：SPF、DKIM、DMARCを正しく構成する ブランドロゴの確認：ロゴが国際商標データベースに登録されていることを確認証明書発行の申請：VMCを発行する会社に申請ロゴと情報の審査：CAがロゴの正当性や商標登録の状態を確認証明書の発行：審査が通過するとVMCが発行される まとめ VMCは、X.509という堅牢な証明書規格を基盤として、ブランドロゴの信頼性を保証する新たな技術です。X.509の柔軟性を活用することで、VMCは既存のインフラと互換性を保ちながら、ブランド認証という新たなニーズに対応しています。 BIMIとVMCを導入することで、ブランドの信頼性向上やメール受信者への安心感を提供でき、フィッシング詐欺対策としても有効です。企業にとっては、自社ブランドの保護と顧客体験の向上を実現する重要な手段となり、注目すべき技術だと個人的に思っています。 また次の機会があれば、OpenSSLで自作のVMCを作成方法について書こうと思っていますので、よろしくお願いします。

こんにちは！セキュリティエンジニアを担当している濱本です。今回はAIと対話した結果などを用いて、サイバー攻撃に対する防御についてお話します。 １．今回の対話の趣旨について 普段、私はSIEMを使用したログ分析業務を行うことで、社外からの攻撃や社内の不信な動きを検知することで、社内の重要な情報や資産などを守っています。そんな中、セキュリティ業界に関しては新しい脆弱性が出たり、個人情報やクレジットカードの流出に関するニュースが流れてくるなど頭が痛くなる日々もありますが、それと同じくAIに関するニュースもよく見ます。そこで今回はせっかくなので、サイバー攻撃からどうやって重要な資産を守るべきかをAI（ChatGPT-4o）と対話することで新しい考え方やアドバイスを得られるのか。ということを目的に進めたいと思います。 ２．攻撃側と防御側について まず確認したいのは、いわゆる「攻撃側」と「防御側」の場合にはどちらの方が有利なのか。です。 Question（濱本）セキュリティ業界において、攻撃側と防御側だとどちらが有利でしょうか？ Answer（ChatGPT-4o）一般的に、攻撃側が有利とされることが多いですが、具体的な状況や条件によって異なることがあります。以下にその理由を挙げます。 ■攻撃側が有利な理由：1.驚きの要素攻撃者は、いつ、どのように攻撃を仕掛けるかを選べるため、防御側に不意打ちを与えることができます。2.攻撃手法の多様性攻撃者は、多くのツールや手法（マルウェア、フィッシング、ゼロデイ攻撃など）を利用し、多方向から攻撃を仕掛けることができます。3.防御の複雑性防御側は、膨大なシステムやネットワーク、デバイス全てにおいて完全な防御を維持する必要があり、一つの脆弱性でも攻撃を許す可能性があります。4.コスト効率攻撃者は比較的低コストで攻撃を実施できるのに対し、防御側は多くのリソースを防御に投入する必要があります。■防御側が有利な理由：1.情報共有と協力今日では多くの組織が情報を共有し、攻撃に対する共同対策を講じています。2.技術の進化機械学習やAIなどの新しい技術が、防御の強化に活用されつつあり、より素早く攻撃を検知し対応できるようになっています。3.法的措置と規制攻撃者に対する法的措置や国際的な規制が強化され、攻撃のリスクが増大しています。4.セキュリティの意識向上セキュリティに関する意識が全体的に向上しており、組織や個人のセキュリティ対策が強化されています。結論として、攻撃側が有利と感じられる場面が多い一方で、防御側も絶えず進化し続けており、適切な対策を講じることで、攻撃に立ち向かうことが可能です。両者の戦いは継続的であり、常に新しい戦略や技術が求められます。 おぉ！私としては有利なのは攻撃者側一択だと思っていましたが、AIの回答としては必ずしも攻撃者側が有利、というわけではなさそうです。最初から絶望せずにすみました。 ３．防御側におけるAIの活用について 先ほどのAIからの回答にもありますが、「技術の進化」として機械学習やAIを防御に使うことで強化することも記載されています。では防御側においてAIの活用とはどういったものがあるのでしょうか？ Question（濱本）防御側が機械学習やAIを活用する場合、どういったシチュエーション、ツールの組み合わせがありますか？ Answer（ChatGPT-4o）防御側が機械学習やAIを活用する場面は多岐にわたります。以下は、具体的なシチュエーションとそれに伴うツールや技術の例です。 ■シチュエーションと活用方法：1.異常検知・ネットワークトラフィックの監視　通常と異なるトラフィックパターンを検出するために、機械学習アルゴリズムを使用します。この方法は未知の攻撃を早期に検知するのに有効です。・利用ツール　Splunk、Elastic Stack（以前のELK Stack）、Darktraceなど。2.メールセキュリティ・フィッシングメールの検出　AIを用いてメールの文面を解析し、フィッシングの可能性があるメールを検出します。・利用ツール　Proofpoint、FireEye Email Securityなど。3.エンドポイントセキュリティ・マルウェア検出　エンドポイントでの不正な活動やファイルの振る舞いをAIによって分析し、マルウェア感染を防ぎます。・利用ツール　Cylance、CrowdStrike Falcon、SentinelOneなど。4.インシデントレスポンス・自動化された分析と応答　AIを活用して攻撃の兆候をリアルタイムで分析し、自動で対応策を講じます。・利用ツール　IBM Security QRadar、Splunk Phantomなど。5.ユーザー行動分析（UBA/UeBA）・内部脅威の検出　社内ユーザーの行動を学習し、通常とは異なる行動を示した場合に警告を上げ、内部からの脅威に対抗します。・利用ツール　Exabeam、Rapid7、Securonixなど。6.脆弱性管理・脆弱性の優先順位付け　システム内の脆弱性をAIがスコア化し、優先的に対処すべき脆弱性を特定します。・利用ツール　Tenable.io、Qualys、Rapid7 InsightVMなど。■ツールの組み合わせ：・SIEM（Security Information and Event Management）とAISIEMツールとAIソリューションを組み合わせることで、ログデータの大量集積から有意義なインサイトを抽出し、先手の防御策を講じることが可能になります。・SOAR（Security Orchestration, Automation, and Response）とAISOARを導入して、AIと連携させることでインシデントに対する応答を効率化し、自動化することができます。これがインシデント対応の迅速さと正確性を向上させます。AIと機械学習は、防御策の効力を強化し、攻撃に対する迅速で効果的な対応を可能にします。ただし、これらの技術を導入する際には、その限界とバイアスについて理解し、専門家の監視と調整が必要です。 防御策の一つとしてSIEMがちゃんと入っているようで安心しました！もちろん、これら全てを導入して管理/運用というのはかなり難しいとは思いますが、実際に状況や優先度などに応じて選択するためのアイデアや議論のためのベースとしては使えるのではないかなと思います。 ４．取り込むべきログとは 私がSIEMを使ったログ分析業務を行っているからではありますが、SIEMに取り込むべきログの種別やどれくらいのログの量を取り込むとAIとして活用できるのか、という観点で聞いてみます。 Question（濱本）SIEMとAIを組み合わせる場合、どういったログを取り込むと効果的ですか？またどれくらいのログの量を取り込むと精度高く判断できますか？ Answer（ChatGPT-4o）SIEMとAIを組み合わせる際に効果的なログの種類と、取り込むべきログの量に関する考慮事項を以下に示します。 ■効果的なログの種類：1.ネットワークログ　・ファイアウォールログ: 各トラフィックの許可・拒否のルールに関する情報。　・IDS/IPSログ: 不正アクセスや攻撃の試みを記録。　・ルータやスイッチのログ: ネットワークトラフィックの流れに関する情報。2.エンドポイントログ　・オペレーティングシステムのイベントログ: WindowsやLinuxのシステムイベント、セキュリティログ。　・アンチウイルスソフトウェアのログ: マルウェアの検出記録。3.アプリケーションログ　・Webサーバーログ: アクセスログやエラーログ。　・データベースログ: クエリ履歴やエラー、アクセス制御の変更記録。4.ユーザーアクティビティログ　・シングルサインオン（SSO）やIDプロバイダのログ: 認証、認可の情報。　・プロキシサーバーログ: ユーザがアクセスしたウェブサイト情報。5.クラウドサービスログ　・クラウドリソースのイベントログ: AWS CloudTrail、Azure Activity Log、Google Cloud Audit Logsなど。■ログの量と精度：・データ量の影響AIモデルの学習には多様で大量のデータが不可欠です。具体的な量は環境によって異なりますが、一般に多くのログを集めることでモデルに多様な異常やパターンを学習させることが可能となります。・初期学習初期段階で最低でも数週間から数ヶ月分のログデータを基にモデルを学習させることが推奨されることがあります。これにより通常の動作パターンを基にベースラインを構築できます。・リアルタイムと歴史的データリアルタイムのデータは即座の脅威検出に役立ちますが、歴史的なデータも長期的な傾向分析や異常検出に重要です。・ノイズとシグナル大量のデータを取り込むことでノイズが増える可能性もあるため、適切な前処理（データのノイズフィルタリング、データ正規化）が重要です。・スケーラビリティ大規模なデータ量の取り扱いを可能にするために、スケーラブルなインフラ（クラウドやビッグデータ技術の活用）が求められます。効果的なAI駆動のSIEMシステムを構築するためには、適切な量と質のログデータを取り込むことが重要です。これ やはりAIとして分析するためには「大量のデータが不可欠」のようですね。また「歴史的なデータも長期的な傾向分析や異常検出に重要」と回答がある一方で「大量のデータを取り込むことでノイズが増える可能性もある」とも回答があるため、最終的には「適切な前処理が行われた大量かつ長期間のデータ」が必要そうです。 各ログをどのレベルまで取り込むのか、というのはコストや優先順位に応じて変動するかと思いますが、取り込むべきログの種類に関しても、基本的には私の考えとも相違ありません。余力があれば各PCなどの端末のログやSlackやチャットワークといったコミュニケーションツールのログ、セキュリティゲートなどのログとかを取り込んでも面白いかもしれません。 ５．運用について 防御側が脅威を検出するために機会学習やAIの活用が有効であることは分かりました。しかし、回答にあったようなツールをすべて導入するためには莫大なコストがかかりますし、運用するとなると更に大変になります。莫大なコストをかけて大量のツールを導入しても、運用できなければ効果を最大化することはできません。 普段、私はSIEMを使った分析業務をメインとしていますが立ち位置としてはいわゆる社内環境における脅威を検出するためのプライベートSOCとなります。企業によっては防御するための環境を構築するのも大変でしょうし、それらを運用するとなるとセキュリティエンジニアの採用も必要となり、さらに大変になるとことが予想されます。 最後にAIはセキュリティエンジニアの代わりになるのかを聞いてみましょう。 Question（濱本）セキュリティ製品やログの分析を行うためには専門的なセキュリティエンジニアが必要と考えていますが、それらをAIに代行してもらうことは可能でしょうか？ Answer（ChatGPT-4o）AIはセキュリティ分野で非常に有効なツールとして活用できますが、現時点でAIが専門的なセキュリティエンジニアのすべての役割を完全に代行することは難しいです。以下に、AIが代行できることと、セキュリティエンジニアが依然として重要である理由について説明します。 ■AIが代行できる業務1.データ分析と異常検知　AIは大量のデータを迅速に解析し、通常のパターンからの逸脱を検出することが得意です。これにより、潜在的な脅威を早期に発見できます。2.インシデントの初期対応　いくつかの対応済みアクション（例えば、疑わしいIPアドレスの遮断や被疑リソースへのアクセス制限など）の実行を自動化することで、AIがインシデントの初期対応を行うことが可能です。3.レポート作成とアラート　定型的なレポート作成やアラートの発行を自動化し、セキュリティチームの負担を軽減します■セキュリティエンジニアが必要な理由1.高度な判断と戦略策定　複雑な脅威の判断や、新たな脆弱性に対する戦略策定は、人間の専門知識と経験が不可欠です。2.AIモデルの監視と改善　AIモデルの性能を監視し、必要に応じて改善を行うためには、セキュリティとデータサイエンスの知識が必要です。3.インシデント対応と復旧計画　深刻なインシデントに対する対応やシステム復旧には、人間の創造力と柔軟性が求められる場面があります。4.倫理と規制の順守　セキュリティ対策には法規制や倫理的な判断が伴うことが多く、これはAIだけで実行するのは挑戦的です。結論として、AIはセキュリティ業務の多くの側面を支援し、効率化することが可能ですが、それだけでは十分ではありません。セキュリティエンジニアは、AIによる補助を活用しつつ、より高度なタスクや戦略的な判断を担うことで、全体としてより強力で効果的なセキュリティ体制を築くことが期待されます。 まだ私には仕事があるよう安心しました。AIを活用することでセキュリティエンジニアとしての運用業務の効率化や脅威を検出するための速度や精度を向上することは出来そうですが、戦略策定や複雑な脅威の判断は人間が行うべきのようです。 ６．まとめ いかがだったでしょうか。AIに対する質問の仕方や使用するツールによって回答結果や精度は変わってくると思いますが、サイバー攻撃から守るために考えるべきことや実施すべきことなどは十分得られると思います。 しかし最後の質問に対する回答にもありますが、すべてをAIに代行させるということは現時点ではできません。必ず人が必要となります。またそれらを活用/運用していくためには状況に応じた組織の設計やガバナンスの徹底なども必要です。 今回は防御側の視点でAIに質問しましたが、攻撃側の視点で質問すれば同様に攻撃手法に関する情報が得られる可能性は大いにあります。最終的にAIをどう使うか、使いこなせるかは人次第なのだと思います。 AIは非常に便利で今後も発展を続けていくでしょう。そんなAIと向き合いながら引き続きセキュリティエンジニアとして成長していきたいと思いますが、本説明が少しでもみなさんのセキュリティ改善に貢献できれば幸いです。

弊社ではアプリケーションのリリース時に行うSOC（Security Operations Center）チームによる脆弱性診断とは別に開発者自身によるOWASP ZAPを使用したセルフ診断を行っています。今回は、OWASP ZAPのスキャンルールをカスタマイズしたい方のために、参考情報をご紹介します。 OWASP ZAPとは OWASP ZAP (Zed Attack Proxy) は、ウェブアプリケーションの脆弱性を診断するためのオープンソースのセキュリティツールです。プロキシ機能や自動スキャン機能を持ち、セキュリティ診断の初心者から上級者まで幅広く利用されています。 OWASP ZAP 公式サイト SOCチームの判定基準と異なる場合がある OWASP ZAPにデフォルトで組み込まれているスキャンルールは、一般的な脆弱性の検出には有効ですが、特定の組織のSOC（Security Operations Center）が持つ判定基準とは異なることがあります。これにより、SOCチームが期待する結果を得られない可能性があります。 ちょっとした違いであればスキャンルールをカスタマイズすることで吸収できるかもしれません。 ソースからビルドする インストーラーを使用する分には多くの紹介サイトがあるのでここでは割愛します。 OWASP ZAPはソースコードが公開されておりビルドして使用することも可能です。 ビルド方法は公式サイトで紹介されていますので参考にしてください。開発者向けガイド 開発環境整備 (Windows環境) OWASP ZAPのカスタマイズを行うためには、開発環境を整える必要があります。詳細なセットアップ手順は、公式の開発者向けクイックスタートガイドを参照してください。 OWASP ZAPのソースを入手 OWASP ZAPのソースコードは、GitHub上で公開されています。以下の手順でソースを取得してください。 git clone https://github.com/zaproxy/zaproxy.git git clone https://github.com/zaproxy/zap-extensions.git zaproxy がOWASP ZAP本体です。 zap-extensions は、OWASP ZAPの機能を拡張するための追加プラグインやルールを含むリポジトリです。 OWASP ZAPはJavaで作成されています。GUIにはSwingが使われています。 手順通りに進めればよいのですが、少しハマりそうな箇所はこちらです。 JAVA 21ではコンパイルエラーに 公式ではJAVA 11以上とされていますが、JAVA 21ではコンパイルエラーになります。素直にJava 11を使う方がよいでしょう。 Gradle実行前に JAVA_HOME を設定しておきます。 $env:JAVA_HOME = "C:\Program Files\Java\jdk-11.0.14" IDEはIntelliJ IDEAがおすすめ 公式サイトにも書かれていますが、Eclipseの場合AddOnがすべて並列に表示されてしまうという問題があるため、IntelliJ IDEAを使用することをおすすめします。 Eclipseの場合 IntelliJ IDEAの場合 カスタム方法 OWASP ZAPのルールはJavaで作成されているので、Javaの知識があれば誰でもカスタムすることが可能です。 AddOnの追加方法については公式ページに手順が紹介されています。[公式の手順はこちら] 公式ページの説明では新しくAddOnを作成する方法が書かれていますが、既存のスキャンルールをカスタムしたいことも多いのではないでしょうか。 簡単ではありますが、スキャンルールのソースや生成物の配置先を説明します。 ルールってどこにあるの？ （パッシブスキャンルールの場合） Windows インストール版のアドオンは次の場所に格納されています。 C:\Program Files\ZAP\Zed Attack Proxy\plugin pscanrules-release-xx.zap がパッシブスキャンルールになります。 zapファイルがルールセットになります。複数のルールclassがZIP形式で圧縮されています。jarと同じですね。 ソースからビルドする場合は、こちらにソースコードがあります。 zap-extensions\addOns pscanrulesパッケージが パッシブスキャンルールのパッケージになります。スキャンルールの種類ごとにパッケージが分けられています。 静的スキャンで使用されるルールセットになります。このルールセットの中に複数のルールが含まれています。 Ruleクラスが各々のスキャンルールになります。 copyZapAddOn タスクを実行すると、zap-extensionsに作成されたzapファイルがzaproxyにコピーされます。 ./gradlew copyZapAddOn zap-extensions/addOns/pscanrules/build/zapAddOn/bin/pscanrules-release-58.zap zaproxy/zap/src/main/dist/plugin/pscanrules-release-58.zap ZAP起動時にはzaproxy/zap/src/main/dist/pluginディレクトリのZAPファイルがアドオンとして読み込まれます。 チェックをしているクラスは？ 例として Reverse Tabnabbing ルールのカスタマイズについて説明します。 （具体的なロジックの説明は行いません。） Reverse Tabnabbingの詳細はこちら Reverse Tabnabbingは、ウェブサイトでリンクを新しいタブやウィンドウで開く際に発生する脆弱性です。 新しいタブから元のページを操作することが可能となり、フィッシング攻撃に利用される可能性があります。 対策として、リンクに rel="noopener noreferrer" を追加することで、このリスクを軽減できます。 現在では、ブラウザ側での対策が進みOWASP ZAPでは重大脆弱性とされず、チェック内容が緩くなっています。しかし、他の脆弱性診断ツールでは厳密にチェックされる場合があります。 org.zaproxy.zap.extension.pscanrules.LinkTargetScanRule.java がスキャン内容を実装したクラスになります。ロジックを変更することでチェック内容をカスタマイズすることが可能です。 スキャンレポートに表示する内容もカスタム可能です。 org/zaproxy/zap/extension/pscanrules/resources/Messages.properties に出力内容が定義されています。 pscanrules.linktarget.desc = At least one link on this page is vulnerable to Reverse tabnabbing as it uses a target attribute without using both of the "noopener" and "noreferrer" keywords in the "rel" attribute, which allows the target page to take control of this page. pscanrules.linktarget.name = Reverse Tabnabbing pscanrules.linktarget.refs = https://owasp.org/www-community/attacks/Reverse_Tabnabbing\nhttps://dev.to/ben/the-targetblank-vulnerability-by-example\nhttps://mathiasbynens.github.io/rel-noopener/\nhttps://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c pscanrules.linktarget.soln = Do not use a target attribute, or if you have to then also add the attribute: rel="noopener noreferrer". OWASPの説明ページのリンクも載っています。 https://owasp.org/www-community/attacks/Reverse_Tabnabbingこちらのサイトには脆弱性の内容が説明されています（勉強になります！） 直接スキャンルールに手を入れることの問題点 公式アップデートによる不整合 : 元のルールを直接変更すると、公式ソースが更新された際に変更したスキャンルールとの不整合が生じる可能性があります。(OWASP ZAPは頻繁に更新されています) 解決策としてルールセットを分ける 一つの有効な解決策は、ルールセットを分けることです。カスタムルールセットを作成することで、オリジナルのコードを保護しつつ、独自の判定基準に沿ったスキャンを行うことができます。 pscanrulesルールをコピーし、独自のルールセットを作成することができます。 （pscanrulesの場合は構造の問題で瀕雑な作業が必要ですが、、） 生成した zapファイルを配布することで社内独自のルールを展開することも可能です。 （インストール版の以下フォルダにコピー） C:\Program Files\ZAP\Zed Attack Proxy\plugin このようにPassive scanner rulesが2つ表示されています。（下がカスタマイズ版） まとめ 以上、ちょっとスキャンルールを変更したいといった場合にお役に立てていただければ幸いです。 （脆弱性診断ツールってどんなロジックになってるの？といったときの勉強にもおすすめです）

8/12（月）～8/17（土）5泊6日で開催された、セキュリティ・キャンプ 全国大会 2024に、GMOインターネットグループはシルバーメンバーで協賛しました。当日は企業紹介イベントへの参加や、GMOインターネットグループの社員が講師として参加してきましたので、その内容をレポートしていきます！ イベント概要 セキュリティ・キャンプ全国大会とは 「セキュリティ・キャンプ」のメインイベントとして主に夏休み期間中に実施する合宿形式の勉強会です。 毎年テーマ別に集められるエキスパートが講師となり、専門的・実践的な講義が受講できるほか、合宿の中で同じ趣味を持った仲間との交流もあります。全国大会のほか、全国大会修了生の次のステップとなるネクストキャンプ、小中学生を対象としたジュニアキャンプも同時開催いたします。また会期中には、これまでにセキュリティ・キャンプに参加した修了生がチューターとして学習の支援等も行います。 開催日：2024年8月12日（月）～8月17日（土）開催場所：クロス・ウェーブ府中参加費：無料（事前登録制）主催：独立行政法人情報処理推進機構（IPA）、一般社団法人セキュリティ・キャンプ協議会公式HP：https://www.security-camp.or.jp/IPA HP：https://www.ipa.go.jp/jinzai/security-camp/2024/camp/index.html 会場となるクロス・ウェーブ府中は、勉強する部屋、食堂、ホテルがすべて建物内に入っており、学生たちは過ごしやすそうで勉強に集中しやすい環境が整ってました。 事前配布ノベルティ 毎年参加者の楽しみの1つでもある！？協賛企業からのノベルティが参加者の各自宅へ、ノベルティボックスとして事前に郵送されました。 GMOインターネットグループからは、『オリジナルカップ麺（わかめラーメン）×　スキミング防止カード』をノベルティとして用意しました！ 学生の皆さまがこのノベルティを手に取り、楽しみながらセキュリティについて学び、理解を深めてもらいたいという思いを込めて、作成しました。 スキミング防止カードクレジットカードやICカードの不正読み取りを防ぐセキュリティガジェット！皆さんのお財布やカードケースに入れて、是非たくさん使用していただけたら嬉しいです。オリジナルカップ麺（わかめラーメン）デザインにとてもこだわりました！皆さん気づいていただけましたでしょうか？わかめの広がりをフィッシング攻撃の蔓延と脆弱性の拡大に見立て、フィッシングの危険性・セキュリティの重要性を直感的に理解してもらえるような意味を込めてデザインしました。スキミング防止カードを捲ると･･･学生の皆さんへ、GMOインターネットグループからのメッセージを添えさせていただきました！ 企業紹介イベント 全国大会期間中の実施予定でしたが、台風の影響で延期となってしまい、後日開催された『アフターイベント』にて、オンラインによる企業紹介を実施いたしました。 ブースセッション / フリータイム 今回は、セキュリティチームの現場で活躍するエンジニア2名と人事が参加させていただきました。セキュリティに携わるエンジニアより、実際に行っている業務内容や働いていくうえでのモチベーションなど、なかなか聞けないリアルな現場の話をお話しました。 また、学生参加者からの質問にもお答えすることができ、少しでも弊社に興味を持っていただけたら嬉しいです。 全国大会での講師紹介 当日は、GMOインターネットグループより講師として、グループ3社6名が参加いたしました。実際に参加してみての感想や、学生に向けたインタビューをいただきましたので、是非ご覧ください。 GMOサイバーセキュリティ byイエラエ株式会社 三村 聡志 専門コース│A3『ファイルシステムの理解と記憶チップ内あデータの解析』 開発コース│S08『ハードウェアのリバースエンジニアリングゼミ』 Q：全国大会の講師を終えての感想 三村昨年に引き続き全国大会の講師を務めまして、 情報セキュリティの分野に対する学生からの関心や受講生のレベルが年々上がっているのを感じています。もちろん、学生の皆さんが楽しかったと感じてもらえる内容を作るのは大変です。 自分自身の知識の整理や学生の皆さんからの素直なフィードバックを得られ、 フィードバックから次回の講義や業務の質向上に繋がりますので、私自身も参加するたびに達成感や充実感を感じております。 Q：学生へのメッセージ 三村何事にも「初心忘るべからず」ということ、 そして学習する際は、学んでいること・知っていることに共通項を見つけ、 知識を関連づけることを心がけることをお勧めします。そして今の学生の時間を使って、好きなことをどんどん掘り下げること。それが将来にわたっての自分自身の「わくわく」を維持してくれる源泉になると思っています。 三村Developer Experts として、様々なところで活動をしております。私自身、様々なかたから声を掛けられるのは好きですので、SECCONなど、どこかでお見かけした際には気兼ねなく声を掛けて頂けたらありがたいです。 GMOサイバーセキュリティ byイエラエ株式会社 緑川 志穂 開発コース│S04『暗号フルスタック開発ゼミ』 Q：全国大会の講師を終えての感想 緑川年々洗練されていく全国大会とレベルの高い受講生にはこちらとしても勉強させられる思いしかありません。そんな中で講師を務めさせていただけていることについて光栄に思います。今年は特にスピード感があり、具体的には弊ゼミは「TLS1.3のプロトコル・スタックを作る」という目標を全国大会一週間前に達成してしまっていました。応用・発展をそこから考え、会期中は楽しく先を考えながら開発を進められたことは良いところだったかなと思います。 Q：学生へのメッセージ 緑川何か理論的な記述のあるものに実装をつける、ひいては「何か理想を考えたときに、それを具体的に実現する方法を考える」という行為は、本質的に何かしらの要素を切り落とさなければ不可能な行為です。すなわち、何かを作ろうとするときにまず考えるのは、その具体的な内容よりも具体的に実現できなさそうな部分なのです（勿論最初はわからないものですから、経験者に聞くなり、自分で試しに作ってみて失敗してみたりといったトライも必要でしょう）。裏を返せば、実現できなさそうな部分を的確に切り取れさえすれば、どんな目標でも到達に向けた道筋を立てられます。切り取ったとしても、切り取っただけなら後から追加実装を考えられるのですから！巨大なものを作るときによく言われるのはスモールスタートの考え方です。しかし起点や経路の選択が悪いとスモールスタートでもうまく行きません。上記を踏まえ、「ほぼ全てを捨てて実装するなら何を実装するか」と考えると、その選択の手助けになるかもしれません。セキュリティ・キャンプでこれまで利用していたクロスウェーブ府中はこの8月で閉業してしまいました。今後どこになるのかわかりませんが、願わくは是非その新施設一年目から参加してみたいところです。 GMOペパボ株式会社 紫関 麗王 開発コース│S11『Rustで実装するLinux向けアンチウィルスゼミ』 Q：全国大会の講師を終えての感想 紫関昨年に引き続き、弊ゼミではLinuxをターゲットとしたアンチウィルスをRustで実装する。という内容を取り扱いました。 テーマは同じですが、目標や方針はガラリと変わっており、今年はeBPFによる検知を実装しました。講師という立場での参加でしたが、これを期に自分も多くの学びを得られました。 また機会があれば来年以降も担当できたらと思います。 Q：学生へのメッセージ 紫関セキュリティとは言っても攻撃を行うだけではありません。セキュリティエンジニアも「エンジニア」である以上、ものや仕組みを作ることが仕事だと考えています。セキュリティ・キャンプではそういった実装力を身につけるチャンスでもあるので、ぜひ参加してみてください。また、参加された学生のみなさんは自身を持って、今後も自分のやりたいことをやり、アウトプットしていってください！ さいごに セキュリティ・キャンプ全国大会 2024にご参加された学生の皆さま5泊6日の勉強合宿、大変お疲れさまでした！！ 皆さんの今後の頑張り・活躍を応援し、心より期待しております！

GMOインターネットグループ株式会社では、2023年から九州大学にて夏学期および冬学期に単位制の授業を開講しています。本ブログでは、授業の紹介と授業を通じて得られた「学生が求める授業」について記したいと思います。 導入 GMOインターネットグループ株式会社では、2023年から九州大学にて夏学期および冬学期に単位制の授業を開講しています。本ブログでは、授業の紹介と授業を通じて得られた「学生が求める授業」について記したいと思います。 自己紹介 私は2022年から、インフラエンジニアの傍ら採用や技術広報の活動に従事しています。採用活動ではインターンシップを担当、技術広報ではインフラ系のハッカソンであるDevSecOpsThonの主催を通じて、採用と企業認知度向上に努めてきました。 授業の概要と背景 これらの活動を通して、九州大学の岡村 耕二 教授とのご縁をいただき、九州大学で総合科目の授業を開講することになりました。弊社がインターネット・Web業界で蓄積してきた技術を学生に伝授し、本業界を共に盛り上げてくれる未来のエンジニアを育成することが主たる目的です。 授業の詳細 参加条件は特に設けず、学部・学年、知識やスキル不問、インターネット・Web業界に興味がある学生は誰もが受講できるようにしました。 2023年の授業 「インターネットサービスを支える技術」という科目名で、情報モラル、セキュリティ、情報テクノロジーの三要素を包括的に学べる内容にしました。容易に理解を深められるようにマインクラフトを教材として取り入れ、デジタル/情報リテラシーの向上と、ICTを駆使して社会をリードする力の育成を目指しました。各コマのテーマと概要は以下の通りです。 1コマ目では、弊社のホスティングサービスであるConoHaの事業企画担当者を招き、Webサービスを作る際の工程を、実際に利用しているフレームワークやその他の分析手法、観点を紹介しながら説明しました。 2～3コマ目はインフラがテーマで、ConoHa VPSを用いてLinux上でマインクラフトのマルチサーバーを構築し、さらに運用を体験しました。 4～5コマ目ではマインクラフトのMakeCodeを使用して視覚的にプログラミングを体験し、プログラミング的思考を養いました。 6コマ目では、近年の事例を基にSNSでの誹謗中傷に関する授業を企業法務担当者が行いました。 7～8コマ目ではマインクラフトを用いたセキュリティ演習を実施し、脅威から情報資産を防衛する策を学びました。 2023年の授業のフィードバック 以下は最終日に学生から回収したアンケート結果の一部です。約8割の学生がインターネット・Web業界への関心を示してくれました。また、多くの学生がより高度な授業、特にアプリ開発の授業開講を望んでいることが分かりました。 今後弊社に期待する授業 2024年の授業 2023年にいただいたフィードバックを踏まえ、より高度な授業内容に刷新しました。「TODOリストのWebアプリ開発」を通じて、プログラミングスキルとアプリの実行基盤であるサーバーの構築、運用スキル向上を目指します。 前半はJavaScriptとReactを用いたプログラミングを学習し、実際に自分のPCで開発を行います。後半は開発したアプリをConoHa VPSにデプロイ、さらにWebサーバーを構築してインターネット上に公開します。また、インフラの役割や仮想技術、セキュリティの重要性を学びます。 2024年の授業のフィードバック 予期せぬエラーやトラブルにより進行がスムーズではなかった部分がありましたが、概ね好評に終わりました。いま以上の高度な技術習得を求める声が43%あった一方で、より初心者向けのレベルを期待する声が54%ありました。難易度は今後チューニングが必要なものの、いずれにせよ本業界に対する興味は引けたと考えております。 授業を通して身に付いたこと、今後役立ちそうなポイント まとめ 学生たちの興味が増加していることから、未来のエンジニア育成という目的は達成できたと考えています（少なくともスタートラインには立ってもらえたと感じています）。また、2年間の授業を通じて、学生たちは企業のエンジニアからより実践的な授業、高度なレベルの授業を求めていることが分かりました。 今後も企業に勤める現役エンジニアだからこそできる実践的な授業を提供し、未来のエンジニア育成に努めてまいります。最後に、このような貴重な機会と多大なサポートを提供してくださった岡村先生に心から感謝申し上げます。

今回は弊社社内で行われている診断業務で気になったWeb Content Security Policy (CSP) を中心に、その基本から代表的なディレクティブまで、そして大規模・中規模サイトにおける導入するか否かの判断をどうしたらよいかあたりを書いていきます。 CSPの基本 CSPは、ウェブページがどのようなリソースを読み込むことができるかを制御するセキュリティレイヤーです。導入することで主に以下の攻撃を防ぐことができます。 XSS攻撃クリックジャッキングパケット盗聴攻撃 実装はHTTPレスポンスヘッダーで CSPはHTTPレスポンスヘッダーとして実装されます。このヘッダーは、ブラウザに対してウェブページのセキュリティポリシーを指示します。CSPヘッダーを設定することで、ブラウザはそのポリシーに従って、許可されていないリソースの読み込みやスクリプトの実行を制限します。 そして、CSPヘッダーの基本的な構文は次のとおりです。 Content-Security-Policy: <directive> <source>; 例えば、次のヘッダーはスクリプトの読み込みを自身のドメインのみに制限することができます。 Content-Security-Policy: script-src 'self'; CSPディレクティブの詳細 CSPには多くのディレクティブがありますが、いくつかよく使いそうなものをここでは紹介していきます。 　- default-src : 他のディレクティブのフォールバックとして機能　- script-src : JavaScriptの読み込み元を制限　- style-src : CSSの読み込み元を制限　- img-src : 画像の読み込み元を制限　- connect-src : HTTPリクエストの送信先を制限 各ディレクティブには、 'none' , 'self' , 'strict-dynamic' などのキーワードを使用できます。ディレクティブの詳細はこちらから確認をお願いいたします。 導入手順をCSPの仕様から考える 攻撃を防ぐ手段としてすぐに導入を。と考えるケースもあると思いますが、導入は段階的なアプローチがお勧めです。 CSPにはデバッグにも活用できるレポートモードがあり、まずはそこを入り口とすることでポリシーの微調整も早めに行うことができると考えています。 レポートモードでの導入（ Content-Security-Policy-Report-Only ヘッダーを使用）基本的なディレクティブの適用（ default-src 'self' など）より厳格なポリシーの段階的適用 導入対象をサイト規模から考える CSPに関わらず、新しい設定を入れる場合はサイト規模や運用コストも考慮する必要があります。ここでは、既存（大・中・小）規模と新規サイトへの導入メリット、デメリットを整理していこうと思います。 まずは既存サイトへのCSP導入ですが、これは慎重に行う必要があります。レポートモードでの長期運用や、重要な部分からの段階的導入を前提にする必要があると思います。 大規模サイトの場合 大規模サイトでは、セキュリティリスクが高く、攻撃の標的になりやすいため、CSP導入のメリットが大きくなります。ただし、段階的な導入と十分なリソース確保が必要です。 メリット　- 高度なセキュリティ保護　- ブランド価値の保護　- コンプライアンス要件の満たしやすさ デメリット　- 導入・維持に高いコストがかかる　- レガシーコードとの互換性の問題　- サードパーティースクリプトの管理の複雑さ 中規模サイトの場合 中規模サイトでは、CSP導入のメリットとコストのバランスを取ることが重要です。段階的な導入と、重要な部分から優先的に適用することを検討しましょう。 メリット:　- セキュリティ強化　- 今後の拡張性の確保 デメリット:　- 導入に一定のリソースが必要　- 既存の機能との互換性確保の手間 小規模サイトの場合 小規模サイトでは、CSP導入のコストと得られる利益を慎重に比較する必要があります。セキュリティリスクが比較的低い場合は、完全なCSP実装よりも基本的なセキュリティ対策に注力する方が効果的になるケースもあるかもしれません。 メリット:　- 基本的なセキュリティ強化　- 長期的な成長に向けた基盤づくり　- セキュリティ意識の高さをアピール　- 比較的少ない労力で導入可能 デメリット:　- 限られたリソースでの導入・管理　- 開発速度の低下の可能性　- 過剰なセキュリティ対策となる可能性 新規サイトの場合 既存と異なり、新規サイトではCSPを最初から導入することで、長期的なセキュリティ管理が容易になります。初期コストは高くなりますが、将来的なメリットが大きいです。考え方としては 小規模サイト に近いものがあるので、同時にメリット・デメリットを確認することをお勧めします。 メリット:　- 最初からセキュアな設計が可能　- 将来的なセキュリティコストの削減 デメリット:　- 初期開発コストの増加　- 開発チームのCSP理解が必要 CSPの将来と新しい機能 CSPは古いものではなく、2024年8月現在も開発が行われています。昨今の CSP Level 3 では、以下のような機能が追加されています。 - worker-src : Web WorkerやShared Workerを読み込むことができるソースを制御- manifest-src : マニフェストファイルを読み込むことができる出所を制御し、潜在的な攻撃ポイントを制限 これらの新機能を活用することで、より柔軟かつセキュアなCSP実装が可能になります。 まとめ CSPは強力なセキュリティツールですが、その導入には慎重な判断と計画が必要です。サイトの規模、既存のコード基盤、運用リソースなどを総合的に考慮し、段階的な導入を心がけることが成功の鍵となると思います。セキュリティと運用効率のバランスを取りながら、ウェブサイトの保護を強化していくことが重要です。

ドローンに関する総合展示会である「Japan Drone 2024 / 次世代エアモビリティ EXPO 2024」が千葉県・幕張メッセで開催されました。GMOインターネットグループはプラチナスポンサーとして協賛し、空のセキュリティをテーマにブース出展を行いました。さらに国際コンファレンスとして「ハッカー目線で徹底解説！ ドローンセキュリティ最新版」と題したセッションも開催しました。GMOインターネットグループからはGMOサイバーセキュリティbyイエラエから2人の専門家が参加。経済産業省の担当者がモデレーターとなって、ドローンに対するサイバー攻撃の最新情報を解説しました。今回はこちらの国際コンファレンスで行ったセッションのレポートをお届けします。 出展概要 日　時：2024年6月5日（水）～7日（金）10:00～17:00会　場：幕張メッセ（展示ホール5・6）千葉県千葉市美浜区中瀬2-1主　催：一般社団法人日本UAS産業振興協議会（JUIDA）共　催：株式会社コングレ 登壇者 山本健一氏　経済産業省製造産業局航空機武器宇宙産業課次世代空モビリティ政策室次世代空モビリティ戦略企画調整官小池悠生　GMOサイバーセキュリティbyイエラエ株式会社　サイバーセキュリティ事業本部執行役員三村聡志　GMOサイバーセキュリティbyイエラエ株式会社　高度解析部高度解析課 災害現場など様々な分野で活躍するドローンの規制の現状 ドローンは現在、空撮や測量、インフラ点検、物流、農業など、様々な分野で利用が拡大しています。ドローン技術の発展に伴って様々なリスクも高まっています。その1つがサイバー攻撃のリスクです。 まず冒頭、経済産業省の山本健一氏が、ドローンの活用事例として能登半島地震での活用状況を紹介。今回の地震では道路が寸断されて孤立した地域が発生して、歩いて行くにも5～6時間かかるような事例が起きていたといいます。 図1　令和6年能登半島地震　ドローン調査実施個所 それに対してドローンで物資輸送したところ「わずか16分で届けられた」と山本氏は紹介。そのほかにも、壊れた家に人が入れない場合にドローンで確認する、災害住宅の建設に適した場所をドローンで上空から探す、といった活躍をしていたそうです。 こうしたドローンは、現在日本で38万機が登録されていると山本氏。現行の法規制では100g以上のドローンは登録が義務付けられており、100g未満のトイドローンなどを含めると数十万機のドローンが実際に使われていると山本氏は話します。 図2　新制度等の運用状況 現行の政府の規制では、有人地帯での補助者なし目視外飛行を可能とするレベル4と立入り禁止措置（補助者、看板、道路横断時の知一停止）をおこなった目視外飛行が可能なレベル3があり、「立入り禁止措置」のハードルが高いため、「レベル3.5」という新たな制度も設けられました。 図3　無人航空機目視外飛行（レベル3飛行）の事業化に向けた改革 これによって、「道路を横切るときに見張りが必要だった」という状況から、ドローンのカメラで確認することで人の手間を省ける、ということになりました。こうしてドローンの利用拡大を図っているのが政府の方針だと山本氏は言います。 ただ、こうしてドローンの利用が増えると運行管理も重要になります。どのようにコントロールするか、規制、技術の両面から政府でも取り組んでいるそうです。 図4　無人航空機の運航管理（UTM）に関する制度整備の方針 ドローンの運航管理技術だけでなく、性能評価、機体の安全性評価など、「政府では毎年30億円ほどの予算を使って開発している」と山本氏は説明しました。 図5　次世代空モビリティの社会実装に向けた実現プロジェクト 図6　ReAMo　機体の安全性能を評価する手法の開発 ドローンに対するサイバー攻撃の脅威 現在、世の中のすべてのものがインターネットに接続する、いわゆるIoT（モノのインターネット）が広がっており、家電製品だけでなくドローンもIoTの1つに数えられます。そうしたインターネットに接続することで便利になる反面、危険性も高まっています。 そこで経済産業省でもIoT製品に対するセキュリティ適合性評価制度構築に向けた検討会を立ち上げるなど、セキュリティの確保に向けた取り組みを始めています。これはドローンに関しても同様で、政府はドローンの評価におけるセキュリティ適合性評価を検討していく考えです。 図7　IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会について そうした規制の現状に対して、実際の攻撃の現状はどうなっているのでしょうか。GMOサイバーセキュリティbyイエラエの三村聡志は、ドローンに対するサイバー攻撃の脅威について次のように説明します。 「ドローンというのは、適切に対策をしないとサイバー攻撃の脅威に晒されてしまう危険性があります。例えば、第三者からの意図しない操作をドローンが受け付けてしまって、救援物資を意図しないところに運んでしまう、もしくは落とされてしまうというものです」。 これに加えて、ドローンが撮影した映像のデータを攻撃者に盗み取られてしまう、またそれを改ざんされてしまうといった、ドローンを介した攻撃というものも考えられます。 実際の攻撃手順についても三村は説明します。まずはドローン自体を把握するために分解をします。これによってWi-Fiとコントローラー間の通信など、一通りの機能を調べるのだといいます。ドローンの制御プログラムが書き込まれたチップを取り出して、プログラムを抜き出すといったことも行えます。 これによって、実際の攻撃ではどこをどのように狙えばいいのかといった部分がだんだんと見えてくると三村は指摘します。加えて、通信経路も調査します。ここで無線LAN経由での攻撃を調査した結果、攻撃の穴が見つかってドローンの映像を盗み見ることができたそうです。 過去の事例では、ドローンと接続したスマートフォンの画面を差し替えて制御を乗っ取り、PCで映像を盗むといった攻撃が成功したそうです。 図8　2023年度弊社ブースで実施したハッキングデモから紹介 こうした攻撃に対して、三村は「ドローンを守るには、まず前提として何を守らなければならないか」として2つのポイントを上げます。1つがデータ漏えい、もう1つが不正操作です。 図9　ドローンの主なサイバー攻撃リスク 気をつけるべきはドローンそのもの、通信経路、クラウドサーバーだと三村は指摘します。クラウドサーバーにはフライトプランなどの情報が格納されていて、録画データも伝送されている場合も多いため、クラウドの保護も重要になってくるわけです。もちろんカメラの映像を盗み見られる可能性もあり、「この3点セットの対策が重要」と三村。 図10　ドローンにおける守るべき対象 基本的な対策としては初期設定パスワードを使わずに変更する、ソフトウェアアップデートを行う、通信はTLSなどにより暗号化する、不要な通信機能が存在していないか、秘密鍵や個人情報は適切に保護されているか、といった基本的な対策を適切に行うだけでも安全になると三村は説明します。 図11　ドローンにおける確認ポイント こうした対策に対して国の取り組みとしては、サイバーセキュリティガイドラインでドローンの用途ごとに、例えば点検用ドローンであればどの程度守るべきか、災害・警備のような人命に関わるドローンだとどうかなど、用途に応じてリスク分析をしてセキュリティの具体的な対策を示しています。 図12　経済産業省　サイバーセキュリティガイドライン こうした政府のガイドラインも参考にしているとGMOサイバーセキュリティbyイエラエの小池は説明します。ドローンの開発支援をする場合も、まずはこのガイドラインを把握する必要性を紹介したり、診断の際にガイドラインに沿った説明をしたり、実際の現場で活用しているそうです。 「ドローンは、攻撃が実際の物理空間にも影響を出してしまうという側面を持ったデバイス」と三村は話します。従来のサイバー攻撃はPC内のデータが盗まれたり壊れたりといった被害は出ますが、ドローンの場合は墜落を含めて物理的な影響も出かねません。 悪用によって人命の被害が出る可能性もあるため、安全なドローンを作り上げるために、官民一丸となって取り組んでいく必要があると三村は訴えます。 小池も「ドローンは飛行高度が変わってしまうだけで何か事件が起きてしまう可能性も考えられる」と、ドローンのセキュリティ対策の重要性を指摘。ドローンの制御が奪われることで重大事件に繋がりかねないという認識は共有すべきだと強調しています。 三村は、ドローンは重要なインフラとしてセキュリティ対策は重要ですが、現時点で基本的な対策がしっかりできているドローンが増えれば、安全なプラットフォームとしてドローンがビジネスとして活用できるようになる、と説明。セキュリティ対策以上の効果が得られるとアピールします。 山本氏も、スマートフォンを購入して使うときに個人情報の漏えいに気をつけるように、ドローンを買ったら同様にセキュリティ対策に注意をする。一人一人が危機感を持って考える必要があると指摘します。 ドローンのセキュリティに取り組むことは、今後のドローンビジネスの拡大にも重要で、メーカーや政府、ユーザーそれぞれが取り組んでいくことが必要になりそうです。