セキュリティベースの Red Hat Insights ルールは、以下に挙げる方法でお使いのシステムのセキュリティーに影響を与える問題を分析、検出します。

• 注目度や優先順位が高い脆弱性やゼロデイ脆弱性を検出
• セキュリティーに影響する可能性のあるお使いのソフトウェアでの設定ミスを検出
• 期限切れ証明書など、セキュリティーに影響をもたらしかねない他の問題を検出

Red Hat セキュリティーレスポンスチームは、Red Hat Insights チームと密接に協力して最新かつアップデートされた有益なコンテンツをセキュリティールールに提供します。このブログ投稿では、最初のカテゴリーに該当するルールについて説明します。つまり、注目度の高い脆弱性と私たちが行う関連する背景となる作業についてです。

Customer Security Awareness (お客様セキュリティー認識)

Red Hat セキュリティーレスポンスチームは、Red Hat 製品に影響を与えるセキュリティー脆弱性について継続的に分析しています。なかには、非常に懸念されるものや、メディアの注目を集めることが予想されるものもあります。これらの問題は名前やロゴが付けられたり、Web サイトが作成されるなど、ブランド化されたり、出回るエクスプロイトで積極的に使用されたりすることがあります。また、コアパッケージや Red Hat 製品の機能に深刻な問題となります。

このような優先度の高い脆弱性が認識されると、Red Hat セキュリティーレスポンスチームは Customer Security Awareness (CSAw) と呼ばれるプロセスを開始します。CSAw の問題は、脆弱性が一般公開される前に、適切な修正が開発され、関係者によるリリースの準備ができるまで、しばらく非公開 (差し止め) にされることがよくあります。非公開の期間中、Red Hat セキュリティーレスポンスチームとエンジニアチームは、アップストリームパッケージメンテナーやセキュリティー研究者、他の Linux ベンダーのセキュリティーチームと協力して、最適な修正プログラムを作成します。ここでの目的は、利害関係者が修正プログラムに同時にアクセスできるようにすることで、潜在的な攻撃者が脆弱性の悪用方法を知り得る前に、できるだけ多くのエンドユーザーがフィクスにアクセスできるようにすることです。

脆弱性を詳細に分析するほかに、十分にテストされた修正プログラムを利用可能にし、問題についてのアーティクルを作成します。このようにして、Red Hat セキュリティーレスポンスチームと Red Hat Insights チームは、Red Hat Insights がセキュリティーを重視するお客様に高レベルの価値をもたらします。

準備作業

エクスプロイトの公開前に脆弱性の検出と修復を開発するという作業は、多くの場合は時間との戦いです。私たちは相当数のお客様がこれらの作業に依存していることを認識しており、問題に関するデータおよびコンテンツを最優先で取り扱っています。情報は秘密にする必要がありますが、さまざまな内部関係者や領域専門家と協力して対応策を作成する必要があります。そのために、私たちはプライベートレポジトリーを作成し、アクセスを必要最小限の人間に制限しています。チームのコーディネートが非常に重要になります。

以下に最近の CSAw 問題の例を 3 つ挙げます:

• Samba - Loading shared modules from any path in the system leading to Remote Code Execution (CVE-2017-7494)
• sudo: Privilege escalation via improper get_process_ttyname() parsing (CVE-2017-1000367)
• 複数のパッケージに影響するスタックガードページの回避 (CVE-2017-1000364 & CVE-2017-1000366)

これらの問題には、異なるエンジニアリングとテストグループが割り当てられました。それぞれの問題には、評価と修正を必要とする独自の技術的な差異と潜在的な影響があり、これらはすべて同時に対処する必要がありました。多くの場合、最大 4 人の開発者が最終的なソリューションを共同開発します。このように流動的な構成であることから、共同作業者間の良好なコミュニケーションが不可欠になります。

脆弱性パッケージの特定

差し止め用の共有ワークスペースがセットアップされたら、各エンジニアが独自の経験と知識を持ち寄り、脆弱性についての共同作業を行います。まず、脆弱なソフトウェアが含まれているパッケージを特定し、各チャネルでリリースされた脆弱なパッケージのリストを作成します。

Red Hat Insights がカバーする範囲は、CSAw イベントを開始した初期分析を超えるものです。
Red Hat Insights の対象範囲には旧バージョンやサポート外バージョンが含まれており、解決策ではこれらの旧バージョンをサポートする必要があります。

Red Hat Enterprise Linux では他の Linux ディストリビューションと同様に、バックポート と呼ばれるプロセスを使用しており、セキュリティー修正はパッケージに新機能や変更、予想外の動作をもたらす新規のアップストリームパッケージだけでなく、既存の安定したバージョンにも適用されます。このコンセプトについてあまりよく知らない場合は、Determining your risk のブログ投稿を参照してください。ここでは、商用のセキュリティースキャナーが当社の製品ではうまく機能しない理由を説明しています。

当社のバックポートポリシーにより、私たちはバージョンの比較には依存していません。より正確である必要があるため、脆弱性パッケージのバージョンツリーを作成します。Red Hat Insights が分析したシステムがある脆弱性パッケージバージョンを使用している場合、その旨を示すフラグが立てられます。

ルールの開発

次のステップは、Red Hat セキュリティーレスポンスチーム内でのは緊密な協力になり、特に Insights ルールを担当するエンジニアと脆弱性を分析するアナリストのグループ間での協業になります。時間との戦いで Insights ルールを開発する際には、技術アナリストやパッケージメンテナーと連絡をとり、入手可能な情報に関する最新情報を探します。CSAw での Insights ルールの開発は、並列かつ反復的なプロセスです。

Red Hat Insights のクライアントで (インストール済みパッケージや実行中のサービス、ソフトウェア設定などの) 必須データを頻繁に収集するように設定すると、影響範囲の分析が開始可能になります。Insights ルール担当の Red Hat セキュリティーレスポンスチームのエンジニアは、複数の成果物を開発します。たとえば、ルールサーバーのバックエンド論理、ルール web UI フロントエンドコンテンツ、検出スクリプト、Ansible Playbooks などです。

できるだけ速く Insights ルールのコンポーネント、スクリプト、および playbook をお客様に提供することが、私たちのゴールです。

これは複雑な作業で、新たな情報がもたらされるたびに何回も中断され、新たな検討や変更が必要になります。秩序立ったプロセスで見落としを防ぐために、私たちは詳細なチェックリストを使用しています。これは毎回必要に応じて更新、改善されるものです。これらのチェックリストを使用することで、高水準の機能を届けることができ、重要な詳細の見落としがなくなります。

チェックリストの 1 つでは特定のタイムラインに従っていることを確認します。これにより、脆弱性が予想より早く公開された場合、迅速かつ的確に対応できるようになります。別のチェックリストでは、チームメンバー全員が作業の状態を把握し、緊急時に対応できることを確認するようになっています。さらに別のチェックリストは、アナリストとのコミュニケーションを促進し、一貫性を持って分析を使用するためのものになっています。

カテゴリー分け

ルール開発時に私たちが自問することの 1 つは、「影響を受けるすべてのシステムをさらに多くのカテゴリーに分類できるか」というものです。柔軟性のあるものを構築し、修復に対するリスクベースのアプローチをお客様ができるようにするために、これは重要です。リソースが制限されていれば、お客様は最初に対処すべきシステムがすばやく分かります。

このカテゴリー分けの分かりやすい例は、別の CSAw 脆弱性である DROWN - Cross-protocol attack on TLS using SSLv2 (CVE-2016-0800) のルールでしょう。このケースでは、8 つのカテゴリー分けがなされています。こうすることで、お客様は各種のシステムに対する影響を簡単に把握することができます。つまり、単に脆弱なパッケージがインストールされているだけのシステムから、古いバージョンの OpenSSL を使用中に外部からアクセス可能なポートをリッスンするソフトウェアを稼働しているシステムまでを認識できます。後者の場合は、効果的なエクスプロイトに対して、システムが脆弱になってしまいます。

この実際の例では、お客様はアドレスに基づいて作業の優先順位付けができ、最も危険性の高い分野にフォーカスすることができました。危険性の低いシステムは後回しで、高リスクの修復を優先することができたのです。

軽減策

ほとんどの脆弱性は、影響を受けるパッケージに更新プログラムを適用することで修正できます。更新プログラムは脆弱性を修正するので、これが究極的にはベストの解決策になります。ただし、それが望ましくない場合や、修正プログラムがすぐに利用できない場合もあります。重要なシステムのダウンタイムをスケジュールするには、時間がかかり、複雑で、またその時点では実行不可能な場合もあります。

SELinux の使用やソフトウェア設定の変更、短いスクリプトの実行などの効果的な軽減策をアナリストが分かっており、Red Hat Insights フレームワークでこれらの使用時に検出できる場合は、ルールがそれらも提示します。いくつかの軽減策があると、危険にさらされる心配をせずに対応策を練ることができ、都合のよい時期に最終的な修正プログラムをデプロイすることが可能になります。

軽減策が修正プログラムと同じくらい効果的であると思われる場合は、Insights ルールは Red Hat Insights 通知リストからなくなります。効果的ではあるものの一時的な解決策でしかないと思われる場合は、重大度が下げられます。

いよいよ公開!

CSAw 脆弱性が公開される前に、実際の稼働データに対してルールを再確認します。この時点ではルールはまだ差し止め状態で、Red Hat 社内でもできるだけ少人数にしかアクセスできないようにしています。このため、ルールのバックエンドは、実稼働サーバーに帯域外でアップロードされます。実稼働サーバーへのアクセスも制限されているため、あるプライベート領域から別の領域に移動されます。

そして、すべてが全体として二重確認され、テストされます。テストが予定通りに進むと、CSAw 脆弱性公開時にルールの用意ができたことになります。ほとんどのものは、Red Hat Product Security Center のアーティクルと Red Hat Insights サービス自体で共有されます。同時に、脆弱性がメールリストと一般向けに公開され、脆弱性についてのアーティクルがカスタマーポータルに掲載されます。また、修正プログラムがリポジトリーから利用可能となり、ルールのステータスが「アクティブ」に変わります。

この時点でようやく多くの人たちの努力の結果が Red Hat Insights のお客様に利用可能となり、この結果、その時点で最も重要なことに注目していただけることになります。

Red Hat セキュリティーブログ