** 本記事は、Pacific Rim: Learning to eat soup with a knife の翻訳です。最新の情報は英語記事をご覧ください。**
ネットワークアプライアンスなどの組み込み型アーキテクチャデバイスはこれまで、セキュリティ機能に関してはバックログほど重要だと見なされていませんでした。しかし、Pacific Rim の活動を通じて、これらのデバイスはエスカレートする「軍拡競争」の対象となりました。この問題にはソフォスだけでなくすべてのブルーチームのメンバー全員で対処する必要があります。
良いニュースは、既存の原則の多くを非常にうまく応用できるということです。最近のネットワークアプライアンスのテクノロジーは、Linux のような一般的な OS をベースにしています。悪いニュースは、これらの原則の中には微調整が必要なものもあるということです。テクノロジーが進歩した一方で、難解かつセキュリティに無頓着な組み込みアーキテクチャを実行するデバイスの多くが、ラックに置かれたまま埃をかぶっているのが現状です。
もちろん、ソフォスは情報セキュリティ企業として、セキュリティと対応について 2 つの視点を持っています。ソフォスは、企業としてのソフォスに影響を及ぼすインシデントだけでなく、ソフォスの製品やサービス、つまり、より広く世界に発信される「ソフォス」に影響を及ぼすインシデントにも対応しています。したがって、ソフォスのインシデント対応プロセスは自社の環境にとどまらず、ソフォスがお客様のために展開しているインフラストラクチャにまで及んでいます。この事実もソフォスの 2 つの視点を実現する要素であり、現在のニーズを満たすためにインシデント対応の原則をどのように進化させるかを考える上で役立つはずです。
しかし、2 つの視点を実際に機能させるには、ソフォスの製品を開発するチームと、製品に関するセキュリティ問題に対応するチーム、および製品セキュリティインシデント対応チーム (PSIRT) との緊密な協力が必要です。すべての企業に PSIRT がある (あるいは PSIRT を必要とする) わけではありません。調査結果を掘り下げる前に、まずソフォスの PSIRT がどのように運営されているかをご説明します。
ソフォスの PSIRT
ソフォスの PSIRT は、ソフォスの製品やサービスに関する新たな発見について、いくつかのチャネルを監視しています。たとえば、Sophos Intercept X の透明性を詳述した最近の記事 (コンテンツアップデートアーキテクチャの追跡調査 ) で述べたように、ソフォスは 2017 年 12 月 14 日から外部のバグ報奨金プログラムに参加しています。今にしてみれば、Pacific Rim 攻撃の最初の兆候が発生するわずか 1 年足らず前のことです。ソフォスは、このプログラムがもたらす精査とコラボレーションの機会を歓迎しています。ソフォスの責任ある情報開示ポリシーは、自らの発見を善意で開示するセキュリティ研究者にとっての「セーフハーバー」ともなっています。外部からの報告に加え、ソフォスでは独自の内部テストとオープンソースのモニタリングも実施しています。
PSIRT はセキュリティイベントが発生するとトリアージ、つまり確認、測定、連絡、追跡を行い、自らの対応が適切かつ安全で十分であることを確認します。必要であれば、グローバルセキュリティオペレーションセンター (GSOC) に問題を報告します。GSOC は、24 時間 365 日、十数か所の周辺施設と連携します。
ソフォスの PSIRT は、製品 SME と連携して技術的なセキュリティガイダンスを提供し、対応標準に沿って解決へと導くことで、お客様が関連するリスクを迅速けつ効果的に管理できるよう、改善を推進します。ソフォスは CVSS スコア、CWE (共通脆弱性タイプ一覧)、CAPEC (共通攻撃パターン列挙および分類) 情報を含む、実用的なセキュリティ勧告と包括的な CVE を用いて結果を明確に伝えることを目指しています。
これらの要素はすべて、一般的な PSIRT のベストプラクティスであるだけでなく、CISA の Secure by Design イニシアティブへのコミットメントをも意味します。実際、ソフォスはこのイニシアティブの誓約に最初に取り組んだ組織の 1 つです。具体的な誓約の詳細はこちらからご確認いただけます。(ソフォスの CEO である Joe Levy によるエッセイでは、Secure by Design へのソフォスのコミットメントと、Pacific Rim から得た教訓すべてを踏まえて、このコミットメントをどのように進めていくかを詳述しています。)
もちろん、優れた PSIRT はただ報告が来るのを待つだけではありません。その裏では、独自のテストや調査を行うだけでなく、製品のセキュリティ標準、フレームワーク、ガイドラインの充実化、根本原因の分析、社内外のステークホルダーからのフィードバックに基づくプロセスの継続的な改善にも取り組んでいます。
本記事の後半では、Pacific Rim 活動の期間中にソフォスがプロセスを繰り返し改善する中で得た教訓を分析していきます。ネットワークアプライアンスに関して、効果的でスケーラブルな対応とはどのようなものなのかについての原則をお話します。その多くはソフォス自身が導入した、あるいは現在導入中のもので、実務担当者の間での議論の出発点となることを期待しています。
教訓
テレメトリ
すべては、デバイス自体の状態と変化をキャプチャする能力から始まります。ネットワークアプライアンスは、通常ネットワークトラフィックの「見えない」キャリアとしての役割を持つため、それ自体がデバイスであることは見逃されがちです。しかし、この区別はインシデント対応に不可欠なデバイス上の観測可能性を提供するための重要なステップです。
主な課題:
- ネットワークプレーンとコントロールプレーン。私たちはネットワーク (ネットワークプレーン) を監視したいわけではありません。一切です。しかし、ネットワークを管理するデバイス (コントロールプレーン) は監視する必要があります。この区別は多くの場合、物理的なものではなく論理的なものですが、お客様のプライバシーを確実に守る上で重要です。
- オンデバイスリソースの可用性。これらのアプライアンスは依然として小型デバイスであり、RAM と CPU リソースの可用性は限られています。テレメトリキャプチャ機能は、デバイスの主要な機能における不必要なサービス低下を避けるために合理化される必要があります。(とはいえ、リソース容量は近年増加しているため、残念ながら、攻撃者がノイズの中に隠れやすくなっています。ファイアウォールの動作が遅ネットワーク全体でいことに管理者が気付き、ハードリブートを実行することで偶然デバイスから攻撃者を一掃する、という状況が生じる可能性は低くなります。最近のファイアウォールは肥大化したソフトウェアも許容可能であり、同じような動作の鈍化を示すことはないためです。)
- ノイズの多いデータキャプチャ。ネットワークアプライアンスの構造はそれぞれ異なります。ユーザーエンドポイントでは /tmp フォルダはノイズが少なく、アクティブな監視に値するかもしれませんが、ネットワークアプライアンスではかなりノイズが多くなる可能性があります。テレメトリがノイズであふれないようにするには、調整が重要です。
ストリーミング
検出がデバイス上で行われる場合にも、バックエンドのデータレイク (詳細は後述します) で行われる場合にも、取得したテレメトリをデバイスから送信すべき地点が必然的に存在します。これらの原則の多くはセキュリティ監視の分野では文書化されていますが、ネットワークアプライアンスにはいくつかの課題があります。
主な課題:
- ホストの干渉/NIC セットアップ。ネットワークアプライアンスは、ネットワークインターフェイスの管理や、ホスト自体が伝送するトラフィックにどのような影響を与えるかに関して、すでに微妙な問題を抱えています。余分なデータストリーム出力を追加するには、多くの場合かなりの再設計が必要になります。インシデント対応とデバイス動作の間の防火線を確保するためには、干渉を最小限に抑える優れたテクノロジーの選択が不可欠です。OSQuery は、リソースへ影響を及ぼすリスクを低減しながら、ほぼリアルタイムのクエリをサポートできるテクノロジーの好例です。
- 収集と選択。ユーザーのネットワークトラフィック全体を収集することは、プライバシーに関する大きな懸念であると同時に、検知エンジニアリングの極めて非効率的な形態でもあります。(作成、編集、テスト、配信が可能な) ルールセットを使用して最も関連性の高いデータを「選択」することは、大量のデータ収集のための標準的な方法ですが、適切に機能させるには、十分に文書化された (そして監査された) 選択基準が必要です。この区別により、選択されたデータは長めに、収集されたデータは短めに、といった保存ポリシーの賢明な適用も可能になります。
トリガー、トリップワイヤー、検出
次の段階は、ノイズからシグナルを識別することです。サイバーセキュリティの専門家はしばしば、「正常の不在」と「異常の存在」を発見するように要求されますが、両者の定義はネットワークアプライアンスによって大きく異なります。
主な課題:
- テレメトリの選択 + ストリーミングの選択 = 盲点。収集する部分を意図的に選択することは必要ではありますが、継続的な再評価を必要とする空白地帯を生み出します。/tmp フォルダを収集対象から除外することはノイズを減らすための正しい行動かもしれませんが、このフォルダがマルウェアの絶好の中継地として残されることになります。防御者は、ファイル整合性の監視など綿密な「トリップワイヤー」を使って、これらの死角を監視する方法を見つける必要があります。
- 選択されたデータに検出を書き込む。データの一部を選択することは出発点としては適切ですが、それでも多くの場合、処理するにはノイズが過剰です。ソフォスはデータを選択した際、それらのデータに対して検出エンジニアリングのプラクティスを実装できることを発見しました。理想的には、他のセキュリティテレメトリと一緒に正規化されたスキーマでデータの切り替えを促進するために利用できます。
対応アクション
コアネットワークインフラストラクチャは、攻撃的な戦術にはあまり反応しません。ユーザーエンドポイントでは、不審なプロセスを終了させたり、デバイスをネットワークから隔離したりするのは当然かもしれませんが、ネットワークアプライアンスでそのいずれかを行うと、ユーザーネットワークの可用性に壊滅的な影響を与える可能性があります。ソフォスの経験上、この段階で期待される動作を設定し、対応活動がインシデントを悪化させるのを阻止するという堅牢なガードレールが非常に役に立ちました。
主な課題:
- ネットワークの可用性への影響。「電源を切って、また入れる」のは組織全体のインターネットアクセスにおいては違う意味を持ちます。スケーラブルな/自動化されたものであれ、そうでないものであれ、何らかの対応策を実施することは、大きな影響を与える可能性のあるビジネス上の変更として扱われ、変更管理プロセスに従わなければなりません。
- ネットワークプレーンとコントロールプレーン (再び) 。この問題はデータ収集の際にも、修復の際にも重要です。インシデント対応者およびネットワークユーザーの管轄範囲を把握することは、対応アクションを取れるエクスプロイトの限界と、有害な影響を受ける露出の限界を確実に知る上で不可欠です。
- 商業的および法的な制限。この点において、問題は技術的な対応を行う実務者だけでなく、より広範な対応チームのメンバー、特に法務部や経営陣の問題にもなります。これらのステークホルダーに提起すべき質問には、以下のようなものがあります。「対応措置によってネットワークが使用不能になった場合の責任は誰のものか？」「対応措置が取られず、ネットワークが脆弱なまま放置された場合の責任は誰のものか？」
結論
必要は発明の母です。Pacific Rim は、ネットワークアプライアンスのインシデント対応の分野に不足している部分を指し示してくれました。これらの基本原則を適用することで、ソフォスはこれまでにない水準でのお客様保護を実現しましたが、防御者が取り組むべきいくつかの重要な限界も明らかになりました。ある者は自組織で、ある者は各ベンダーの社内で、ある者は業界全体で取り組む必要があります。ネットワークの可用性、データのプライバシー、対応措置に関する責任の限界といったトピックに対しては、技術的なものだけでなく、商業的、法的な枠組みも必要となります。これらのトピックについての議論、ましてや実行は難しいかもしれませんが、脅威の進化に対応するために、多くの場面で検討する必要があります。
Sophos X-Ops は、状況に応じて他の組織と協力し、さらに詳細な IOC を共有したいと考えています。pacific_rim[@]sophos.com までお問い合わせください。
詳細については、こちらのランディングページをご覧ください: Pacific Rim: 中国の国家的攻撃者に対するソフォスの防御・反撃的オペレーション