この1年、生成系AI（Generative AI）... 詳しくはこちら ›
Catoが生成系AIセキュリティの謎を解き明かし、ChatGPTへの組織からのアクセスを保護する方法 この1年、生成系AI（Generative AI）やChatGPTを中心に、AIのリスクについて無数の記事、予測、予言、予知が語られてきました。その範囲は、倫理から広範囲にわたる社会や労働力への影響まで多岐にわたります（今のところ、ターミネーターが現実のものになることはないと思いますが…）。Catoのセキュリティ研究とエンジニアリングが、この予測と懸念に高い興味を示していたことから、ChatGPT によってもたらされるビジネスへのリスクを調査することを決めました。私たちの発見は、いくつかの重要な結論に要約することができます。
ChatGPT などを使用している組織では現在、実際のリスク以上に恐怖心を煽るような行為が散見されます。
生産性におけるメリットは、リスクをはるかに上回っています。
とはいえ、脅威の状況は急速に変化する可能性があるため、組織はChatGPTなどのツールで機密情報や所有権を持つ情報が使用されないよう、セキュリティ管理を導入する必要があります。
懸念事項
前述の、恐怖心を煽るような行為の多くは、ChatGPTとその基盤となる生成系AI技術の「プライバシー」という側面に関するものです。 主な懸念事項は、ChatGPTで共有されているデータは具体的にどうなるのかという点です（モデルをトレーニングするためにバックグラウンドでどのように使用されるのか、または使用されないのか、保管されている場合はその保管方法など）。
問題は、ユーザーが ChatGPT を操作する際のデータ侵害や企業の知的財産のデータ漏洩のリスクです。いくつかの典型的なシナリオを見てみましょう：
ChatGPTを使用する従業員 - ソフトウェアエンジニアがAIにレビューしてもらうためにコードのブロックをアップロードするなど、ユーザーが所有権を持つ情報や機密情報をChatGPTにアップロードする。もしモデルがそのデータを使ってさらに自己学習した場合、後で該当のコードが不注意か悪意かによる他のアカウントへの返信を通じて漏れてしまう可能性はないのでしょうか？現実には、その可能性は低く、実際に組織的な搾取を証明するものは発表されていません。
サービス自体のデータ漏洩 - OpenAIが侵害されたり、ChatGPTのバグによってユーザーデータが漏洩した場合、ChatGPTを使用している組織はどのようなリスクにさらされるのでしょうか？機密情報がこのような形で漏れる可能性はあるのでしょうか？現実の可能性としては、OpenAIのインフラストラクチャのバグが原因で、一部のユーザーが自分のアカウントで他のユーザーのチャットタイトルを見ることができたという、少なくとも1つの公開インシデントがOpenAIによって報告されている程度です。
独自の生成系AI実装 – AI はすでに、独自の専用 MITRE攻撃フレームワークである ATLAS を持っており、入力操作からデータ抽出、データポイズニング、推論攻撃などに至るまでの手法を備えています。こうした手法で、組織の機密データが盗まれる可能性はあるのでしょうか？答えはイエスです。このテーマに関する最近の Cato リサーチポスト の投稿で紹介されているように、手法は無害なものから理論的なもの、実践的なものまで多岐にわたりますが、いずれ生成系 AIの独自実装のセキュリティ保護についてはこの記事に含まれていません。
常に私たちが行うことにはリスクが伴います。インターネット接続にはリスクがあるにも関わらず、毎日何十億人ものユーザーがインターネットを利用しています。ただ、適切な予防策を講じる必要があるだけです。ChatGPTにも同じことが言えます。 いくつかのシナリオは他のシナリオよりも可能性が高いですが、現実的な観点から問題を分析することで、簡単なセキュリティ対策を実施して安心することができます。
[boxlink link="https://catonetworks.easywebinar.live/registration-everything-you-wanted-to-know-about-ai-security"] Everything You Wanted To Know About AI Security But Were Afraid To Ask | Watch the Webinar [/boxlink]
生成系AIのセキュリティ管理
最新のSASEアーキテクチャは、CASBとDLPをプラットフォームの一部として含んでおり、これらのユースケースに簡単に対応できます。Catoのプラットフォームはまさにそのように設計されており、ChatGPTや同様のアプリケーションを組織内で安全に使用するためのレイヤーアプローチを提供します。
どのアプリケーションを許可し、どのユーザー/グループにそのアプリケーションの使用を許可するかを制御
送信を許可するテキスト／データを制御
アプリケーション固有のオプション（データ保持のオプトアウト、テナント制御など）の実施
最初のアプローチは、どのAIアプリケーションの使用が許可され、どのユーザーグループに使用が許可されるかを定義すること。これは、「Generative AI Tools」アプリケーション・カテゴリーと、許可する特定のツール、例えば、すべての生成系AIツールをブロックし、「OpenAI」のみを許可するという組み合わせを指定して行うことができます。
高度なDLPソリューションの基礎となるのは、データを確実に分類する能力であり、データの完全一致、静的ルール、正規表現といった従来のアプローチは、単独で使用する場合、もはや時代遅れとなっています。例えば、クレジットカード番号は正規表現を使えば簡単にブロックできますが、金融文書を含む現実のシナリオでは、機密情報が漏れる可能性のある手法は他にもたくさんあります。ただ機能するより、高度なソリューションがなければ、データの変化やポリシーの微調整に追従しようとしてもほとんど意味をなしません。
ここで、CatoのML（機械学習）データ分類器の出番です。これは、Catoが長年にわたってプラットフォームに統合してきたAI/ML機能の広範な配列に、すでに追加された最新バージョンです。何百万もの文書とデータタイプでトレーニングされた当社のLLM（大規模言語モデル）は、ネイティブでリアルタイムに文書を識別することができ、このようなポリシーに最適なツールとして機能します。ChatGPTで特定のテキスト入力をブロックするシナリオを見てみましょう。例えば、プロンプトを通して機密データや機密データをアップロードする場合です。たとえば、法務部門の従業員が NDA (機密保持契約) 文書の草案を作成し、最終的に完成する前にChatGPT に文書を渡して、内容を確認して改善を提案したり、文法を確認したりするとします。特に文書に PII が含まれている場合、これは明らかに会社のプライバシーポリシーに違反する可能性があります。
図1 - ML 分類子を使用して法的文書のアップロードをブロックするルールの例
もっと深く知る
包括的なCASBソリューションの実力と柔軟性をさらに実証するために、ChatGPTのプライバシーコントロールのもう一つの側面を見てみましょう。設定には「チャット履歴とトレーニング」を無効にするオプションがあり、基本的にユーザーは自分のデータがモデルのトレーニングに使用され、OpenAIのサーバーに保持されないように決めることができます。この重要なプライバシー制御はデフォルトで無効になっています。つまり、デフォルトではすべてのチャットが OpenAI によって保存されます。これはユーザーがオプトインされていることを意味し、組織が ChatGPT を使用するビジネス関連の活動においては避けるべきでしょう。
図2 - ChatGPTのデータ制御構成
ChatGPTをユーザーが柔軟に使用できるようにする一方、より厳格な制御を適用することとのバランスを取るための良案として、チャット履歴が無効になっている ChatGPT でのチャットのみを許可することが挙げられます。CatoのCASBグラニュラーChatGPTアプリケーションは、ユーザーがチャット履歴にオプトインしているかどうかをリアルタイムで区別し、データが送信される前に接続をブロックすることができるため、このような柔軟性が可能になります。
図3 - 「トレーニング・オプトアウト」実施ルールの例
最後に、上記の代替 (または補完) アプローチとして、ChatGPT アクセス用のテナント コントロールを構成することができます。つまり、アプリケーションへのアクセス時にどのアカウントが許可されるかを強制することができます。考えられるシナリオは次の通りです。組織は ChatGPT に企業アカウントを持っており、デフォルトのセキュリティおよびデータ制御ポリシーが全従業員に適用されており、従業員が無料枠の個人アカウントで ChatGPT にアクセスしないようにしたいと考えています。
図4 - テナント・コントロールのルール例
CatoのCASBとDLPについての詳細はこちらをご覧ください：
https://www.catonetworks.com/platform/cloud-access-security-broker-casb/
https://www.catonetworks.com/platform/data-loss-prevention-dlp/
要約すると、この脆弱性は当初予想されていたよりも深... 詳しくはこちら ›
Cato による cURL SOCKS5 ヒープ・バッファ・オーバーフロー (CVE-2023-38545) の分析と対策 要約すると、この脆弱性は当初予想されていたよりも深刻ではないようです。Catoの顧客とインフラは安全です。
先週、cURLのオリジナル作者であり、長年にわたり開発を手動するDaniel Stenbergが、ユビキタスなlibcurl開発ライブラリと、curlコマンドラインユーティリティに存在する重大度の高い脆弱性の「ティーザー」を発表しました。
一週間も待たされた挙句、人道に対する複数の凶悪犯罪、そして宣戦布告がなされ、脆弱性が公表されました。
今になって思うと、この最初の発表は、セキュリティとシステム管理者たちに、やや過度ともいえるパニックを引き起こしました。しかし、libcurl とcurl の使用法が世界中でいかに広く普及しているかを考え、（Catoでは同じ様に広く使用されています。詳しくは後述します)、libcurlのウェブサイトから引用します - インターネットに接続されている地球上のすべての人間は、意識的かどうかにかかわらず、毎日 (lib)curl を使用していると推定されています - ですから、当初の懸念は当然でした。
libcurl ライブラリとcurl ユーティリティは、URLとの対話やさまざまなマルチプロトコル ファイル転送に使用され、すべての主要な Linux/UNIX ディストリビューションにバンドルされています。おそらくそうした理由から、プロジェクトの管理者は脆弱性を非公開にすることを決め、攻撃者を阻止するために詳細をほとんど共有せず、パッチ適用済バージョンが公開されたときに備えてそれぞれのパッケージ管理システムで準備を整えている間、OS ディストリビューションの管理者に事前に通知するだけでした。
[boxlink link="https://www.catonetworks.com/rapid-cve-mitigation/"] Rapid CVE Mitigation by Cato Security Research [/boxlink]
脆弱性の詳細
バッファ・オーバーフローの脆弱性を含むコードは、SOCKS5プロキシプロトコルをサポートするcurlの一部です。SOCKS5は、組織のプロキシを設定したり、Torネットワークで使われているようにトラフィックを匿名化したりするための、よく知られたシンプルなプロトコルです（最近ではあまり使われていませんが）。
脆弱性はlibcurlのホスト名解決にあり、このホスト名解決はターゲットのプロキシサーバーに委譲されるか、libcurl自身によって行われます。255バイト以上のホスト名が与えられた場合、ローカル解決に切り替わり、解決されたアドレスのみが渡されます。このバグのせいで、ハンドシェイクが十分に遅い場合（投稿によると、「十分に遅い」とは典型的なサーバーのレイテンシーを指します）、バッファ・オーバーフローが引き起こされ、解決された結果の代わりに「長すぎるホスト名」全体がバッファにコピーされる可能性があります。
脆弱性が悪用されるのに満たされる必要がある条件は、具体的に次のとおりです。
「CURLOPT_BUFFERSIZE」を設定していないアプリケーション、または 65541 未満に設定しているアプリケーション。curl ユーティリティ自体はこの値を100kBに設定するため、特別にコマンドラインで変更しない限りは脆弱ではないことに注意してください。
CURLOPT_PROXYTYPEを CURLPROXY_SOCKS5_HOSTNAME 型に設定します。
CURLOPT_PROXYまたはCURLOPT_PRE_PROXYは、スキームsocks5h://を使用するように設定します。
バッファ・オーバーフローを悪用する可能性のある方法として、攻撃者がSOCKS5経由でlibcurlクライアントからアクセスされるウェブサーバを制御し、バッファ・オーバーフローを引き起こすのに十分な長さのホスト名を持つLocationヘッダを含む細工されたリダイレクト（HTTP 30xレスポンス）を返させることです。
Catoの(lib)curlの使い方
Catoは、もちろんlibcurlとcurlそのものを複数の目的で利用しています：
curlとlibcurlベースのアプリケーションは、スクリプトや社内アプリケーションのグローバルなインフラストラクチャで広範囲に使用されています。
CatoのSDPクライアントもlibcurlを実装し、複数の機能に使用しています。
当社はSOCKS5を使用しておらず、Catoのコードとインフラは、このCVEのいかなる形に対しても脆弱ではありません。
CatoによるCVEに対する分析回答
CVEの詳細と公開されたPOCに基づき、Catoリサーチラボの研究者は、これが悪用される可能性は中程度～低いと考えています。
とはいえ、当社はもちろんこのCVEにIPSシグネチャを追加し、仮想パッチを適用することで、世界中のCatoに接続されたサイトに保護を提供し、世界中のCatoに接続されたすべてのユーザーとサイトに対して、検出から保護までの時間を1日と3時間と定めてエクスプロイトの試みをブロックし、14時間後にはすでにオプトイン保護を利用できるようにしています。Catoは、影響を受けるバージョンはlibcurl 7.69.0から8.3.0までで、該当するサーバーとアプリケーションにパッチを当てることを推奨しています。さらに、前述のように、脆弱性を誘発する可能性のあるCURLOPT_PROXYTYPE、CURLOPT_PROXY、およびCURLOPT_PRE_PROXYパラメータの使用法を特定することで、緩和することが可能です。
CVE-2023-38545に関する詳細なインサイトや、その他多くの興味深くオタク的なサイバーセキュリティの話については、次のCato ポッドキャストをお聞きください（そして購読してください！）The Ring of Defense:サイバーセキュリティのポッドキャスト（音声版もあり）。
追いつくのがほとんど不可能なペースで、新たなアプリ... 詳しくはこちら ›
Catoアプリケーションカタログ – AI/MLによるアプリ分類の強化方法 追いつくのがほとんど不可能なペースで、新たなアプリケーションが登場し、それらはシャドーITとして、ITチームとセキュリティチームに絶え間ない課題と盲点を生み出しています。組織は、適切なセキュリティを維持するために、アプリケーション・ランドスケープにおける最新の開発や変更に合わせて自動的に更新されるツールを使用することで、後れを取らないようにする必要があります。
SASE製品に不可欠なのは、ユーザーのトラフィックを正確に分類し、実際に使用されているアプリケーションにマッピングする能力です。認可または非認可アプリケーションを管理し、アプリケーションまたはアプリケーションのカテゴリに基づいてネットワーク全体にセキュリティポリシーを適用し、特にCASBを使用してきめ細かなアプリケーション制御を行うには、包括的なアプリケーションカタログを維持する必要があります。
これを維持するためにCatoは、高度に自動化されていると同時に重要なデータ駆動型のプロセスを構築する必要がありました。これにより、お客様が最も使用しているアプリケーションに焦点を当て、詳細な分類ができるようになります。この投稿では、手間のかかる手作業だったアプリケーション・カタログの更新を、データ駆動型パイプラインの形で完全に自動化されたAI/MLベースのプロセスへと強化し、新たなアプリケーションの追加率を、毎週数十から数百のアプリケーションへと、文字通り桁違いに向上させた方法について詳しく説明します。
カタログに掲載されているアプリケーションとは一体何ですか？
アプリケーション・カタログに掲載されているアプリケーションには、次のようないくつかの特徴があります：
一般 - 会社の事業内容、従業員、本社所在地など。
コンプライアンス - アプリケーションが保持し、準拠している証明書。
セキュリティ - TLSや2要素認証、SSOなどをサポートしているかなど、アプリケーションがサポートする機能。
リスクスコア - ネットワークに対する実際に起こりうる脅威にIT管理者やCISOが集中できるよう、複数のヒューリスティック（詳細は後述）に基づき当社のアルゴリズムによって算出される重要なフィールド。
本題に入ります。実際にどのように行われるのでしょうか。
アプリケーションを追加するプロセスを「署名」と呼びます。つまり、自動化されたプロセスから始まり、人間のアナリストが毎週のリリース・サイクルでリリースされるアプリのリストを調べ、最終的に人間による検証を行うまでです（余談ですが、新しいコンテンツを運用環境に公開する際には最高の制御と品質を必要としているため、これは現在プロセスのボトルネックでもありますが、プロセスのこの部分も改善する方法に取り組んでいます）。
前述のように、まず最初に追加したいアプリケーションを選ぶことで、そのためにネットワークを流れるすべてのトラフィックからすべてのメタデータを収集する巨大なデータレイクを利用します。当社の複数の顧客アカウントにまたがって繰り返される、当社ネットワーク全体で最も使用されているドメイン（FQDN）を見て、まだ署名されておらず、当社カタログに掲載されていないものを特定します。
[boxlink link="https://catonetworks.easywebinar.live/registration-everything-you-wanted-to-know-about-ai-security"] Everything You Wanted To Know About AI Security But Were Afraid To Ask | Watch the Webinar [/boxlink]
当社のセキュリティ・リサーチ・チームが開発・保守する社内ツール「Shinnok」を使用して、自動化はエンド・ツー・エンドで行われます。Shinnokは、特定された未署名アプリの一覧をもとに、すべてのアプリについて4つのフィールド（説明、コンプライアンス、セキュリティ、リスク・スコア）の集計を開始します。
説明 – これは最も簡単な部分で、CrunchbaseからAPI経由で取得した情報に基づいています。
コンプライアンス – 対象とするコンプライアンス認証ごとに、オンライン検索と追加のヒューリスティックを組み合わせて、アプリがサポートする認証のリストを作成します。例えば、GoogleのクエリAPIを使用して、指定されたアプリケーション+ "SOC2 "を検索し、信頼性の低いソースからの偽陽性の結果をさらにフィルタリングすることで、SOC2準拠のサポートを特定することができます。
セキュリティ – コンプライアンスに似ていますが、データレイクを使用して、ネットワーク上で観察したアプリが使用している特定のセキュリティ機能を特定します。
リスクスコア – 最も重要な項目であり、複数のデータを組み合わせてリスクスコアを算出します：
ポピュラリティ：これは、当社ネットワークのリアルタイムのトラフィックデータを含む複数のデータポイントに基づいており、当社ネットワーク全体でアプリケーションの発生を測定し、さらにオンラインソースとの相関をとっています。通常、人気のあるアプリや知名度の高いアプリは、無名の新しいアプリよりも低リスクです。
CVE分析：アプリケーションの既知のCVEをすべて収集し、集計します。明らかに、アプリケーションに深刻度の高い CVEが多ければ多いほど攻撃される隙が多くなり、組織のリスクが高まります。
センチメントスコア：当社は、ニュース、メンション、企業またはアプリケーションに関連するあらゆる記事を収集し、アプリケーションに関するすべてのメンションにおいてデータセットを構築します。そして、このデータセットを当社の高度なAIディープラーニングモデルに通し、すべてのメンションについて、それが肯定的な記事またはメンションか、否定的な記事またはメンションかを出力し、最終的なセンチメントスコアを生成し、全体的なアルゴリズムのデータポイントとして追加します。
当社アルゴリズムを使ってすべての異なるデータポイントを抽出し、アプリの最終的なリスクスコアを計算することができます。
どんなメリットがあるの？
アプリケーション分類に対するこのアプローチの主なメリットは、プロアクティブであることです。つまり、Cato を使用するネットワーク管理者は、すべての最新アプリケーションの最新アップデートを自動的に受信します。収集したデータに基づいて、ネットワーク内のすべての HTTPトラフィックの80～90%が既知のアプリケーションの分類によってカバーされていると評価しています。管理者は、すでに要約されているデータを参照して、組織内で注意が必要なトップリスクを把握することで、時間をより効率的に活用できます。
使用例その1 – MetaのThreads
積極的なアプローチを実証するために、MetaによるThreadsプラットフォームが一般公開された際の爆発的な立ち上げにおける、最近の使用例を見てみましょう。このプラットフォームは話によると、現在の成功とは別に、ChatGPTを追い越し史上最大の製品発表として記録されました。5日間でのユーザー登録数は、1億人を超えました。以下の図では、アプリカタログに追加する資格を持つ、新しいアプリケーションのすべてのボックスをオンにして、独自のネットワークの観点からこれを確認できます。一意の接続とユーザーの数から、Threadsを使用していたさまざまな顧客アカウントの合計数まで。
自動化されたプロセスのおかげで、Threadsは今後署名するアプリケーションのバッチに自動的に組み込まれました。リリースから2週間後には、エンドユーザーはアクションを実行する必要が全くなく、すでにCatoアプリカタログの一部になっていました。
使用例その2 – 地理的地域によるカバレッジ
当社のセキュリティ調査チームが行った分析の一環として、日本市場向けのアプリケーションのカバレッジにかなりのギャップがあることが判明しました。これは、カバレッジが不足しているという日本の営業チームから受け取ったフィードバックと一致していました。同じ自動プロセスを使用して、今回はデータレイクから Shinnokに入力されるデータの範囲を日本のユーザーのみに制限し、日本市場に特化したアプリケーションでアプリケーション・カタログを強化する集中プロジェクトを開始し、さらに多くのアプリケーションを追加することができました。4か月間で600 件を超える新規申請がありました。
これに続き、日本の宛先への検査対象 HTTP トラフィック全体の50% 未満から90% 以上まで、アプリのカバレッジが大幅に増加したことを測定しました。
まとめ
当社は、巨大なネットワークとデータレイクを活用することで、リアルタイムのオンライン・データ・ソースとAI/ MLモデルを組み合わせることで高度に自動化されたプロセスを構築し、人的作業をほとんど行わずにアプリケーションを分類できる方法をレビューしてきました。もちろんCatoの顧客にとって主なメリット、ユーザーが使用している最新のアプリケーションを常に最新の状態に保つための心配する必要がなく、インターネット上のトップトレンドや、使用状況に基づいて自動的にアップデートを受け取ることができることです。
Atlassianは、2023年10月4日に発表し... 詳しくはこちら ›
CatoがAtlassian Confluence Serverのエクスプロイトからの保護を実現 (CVE-2023-22515) Atlassianは、2023年10月4日に発表したセキュリティアドバイザリにおいて、オンプレミスのConfluence Data Centerおよび Server製品の新たな重大な脆弱性を公表しました。攻撃者が、インターネットからアクセス可能な Confluenceインスタンスの脆弱なエンドポイントを悪用し、未承認の Confluence 管理者アカウントを作成し、Confluence インスタンスにアクセスできるという権限昇格に関する脆弱性です。
本稿執筆時点では、この脆弱性にCVSSスコアは割り当てられていません。しかし、リモートから悪用が可能であり、悪用されるとサーバーへのフルアクセスが可能になることから、非常に高い（9～10）ことが予想されます。
[boxlink link="https://www.catonetworks.com/rapid-cve-mitigation/"] Rapid CVE Mitigation by Cato Security Research [/boxlink]
Catoの対応
公開されているエクスプロイトの概念実証（POC）はありませんが、Atlassianは「外部攻撃者が未知の脆弱性を悪用した可能性があるという少数の顧客からの報告により、このエクスプロイトを認識していたこと」を確認したと述べており、高い確率ですでに悪用されていると推測されます。
このセキュリティアドバイザリがリリースされた直後、Cato リサーチラボは一部の顧客における脆弱なエンドポイント(“/setup/”) の悪用の可能性を特定しましたが、ユーザーの介入を必要とせずにブロックすることに成功しました。このCVEの固有シグネチャが利用可能になる前から、URLスキャナの識別とブロックを目的とした当社のIPSシグネチャによって、この試みはブロックされていました。
オンライン・スキャナーが、アドバイザリーから得られるわずかな情報の迅速な利用を実装していたことから、Confluenceサーバーがどれほど価値の高いターゲットであるかは明らかであり、公開されている Confluenceサーバーが多数存在することを考えると懸念すべきことです。
公開後、Catoは脆弱性のある “/setup/” エンドポイントとのやり取りをブロックするシグネチャを展開し、世界中のCatoに接続しているすべてのユーザーとサイトに対して、検出から保護までの時間を1日と23時間、オプトイン・プロテクションを24時間以内に利用できるようにしました。
さらにCatoは、Confluenceサーバーの管理エンドポイントへのアクセスを許可された IP からのみに制限することを推奨しており、できればネットワーク内から、不可能な場合は Cato ソケット配下や、Catoクライアントを実行しているリモートユーザー、Cato によって保護されたホストからのみアクセスできるようにする必要があります。
Catoリサーチラボは、引き続き追加情報の入手のためにCVEの監視を続けており、より多くの情報が入手可能になった場合、またはPOCが公開され、追加情報が明らかになった場合には、シグネチャを更新します。今後の情報については、CVE軽減のページとリリースノートをご覧ください。
