Ostorlab修復システム

この包括的なガイドは、重要な手順を説明するように構成されており、Ostorlabの修復システムの多面的な機能を効率的にナビゲートして活用できるようにします。

修復 (Remediation)

Ostorlabは、特定された脆弱性を緊急かつ迅速に、そして効率的に修正するための修復機能を提供します。これらの機能は、すべての脆弱性をチケットに集約して関連付けるチケットシステムを通じて管理されます。

修復システムは、スタンドアロンシステムとして使用することも、Jiraなどのサードパーティのチケットシステムとシームレスに統合することもできます。

修復システムは以下の機能を提供します。

• 脆弱性のライフサイクルを自動的に管理し、修正が検証されたことを確認し、進行状況を追跡できるようにします。
• 優先順位の設定、所有者（Owner）の割り当て、ステータスの更新を行うチケット管理機能を提供します。
• 同じ組織内のチームメンバーと共同作業を行うか、ユーザーを組織に招待して共同作業を行います。
• パッチがタイムリーに適用されるようにポリシー（Policies）を設定し、見逃された修正を検出して追跡およびエスカレーションを行います。
• セキュリティプログラムの健全性に関するメトリクスを収集し、データに基づいた戦略的な意思決定を可能にします。

チケットのライフサイクル

Ostorlabは、検出された脆弱性にリンクされたチケットのライフサイクルを自動化します。チケットのライフサイクルは、以下の機能と保証を提供します。

• 新たにセキュリティ上の問題が検出された場合、チケットが自動的に作成されます。チケットの詳細には、脆弱性に関する情報が含まれています。

• プラットフォームは、同じ脆弱性の将来の発生を同じチケットに集約します。集約はチケットの詳細によって行われます。たとえば、すべてのSQLインジェクションには単一のチケット、または各脆弱性を一意に識別するDNAと呼ばれる内部属性があります。DNAは、脆弱性が一意に識別されるように、脆弱性の種類に基づいて計算されます。

• チケットは修正済み（Fixed）としてマークできます。

修正されたチケットについて、将来のスキャン（Scan）で脆弱性が実際に存在しない場合、プラットフォームは自動的にチケットを検証済み（Verified）としてマークします。

または、同じチケットを再オープンします。

• チケットは例外（Exception）または誤検知（False Positive）としてマークできます。例外や誤検知としてマークされたチケットは、同じ脆弱性の新たな発生が見つかった場合でも、そのまま保持されます。

手動で作成されたチケットも、脆弱性がチケットに割り当てられている場合は、同じチケット管理機能の恩恵を受けます。

チケット管理

チケットには、緊急性、優先度、所有権、または検索やフィルタリングのしやすさを反映する複数の設定があります。

チケットのすべての編集はアクティビティセクションで追跡され、誰がいつ何をしたかを確認できます。

緊急度と優先度

チケットには、P0からP3までの優先度設定があります。P0が最も緊急度が高く、P3が最も緊急度が低くなります。

オーナーシップ

手動で作成されたチケットには報告者（Reporter）が含まれます。さらに、通常は脆弱性が修正されたことを確認する所有者を割り当てることができます。

すでに組織の一部である既存のユーザー、または外部のメールアドレスにチケットを割り当てることができます。 メールアドレスがプラットフォームにない場合、組織への参加を促す招待状が送信されます。

組織の招待を承認できるのはADMINのみです。これを行うには、組織（Organisation）/ 招待（Invitation）セクションに移動します。

ユーザーがアカウントを作成して招待が承認されると、チケットは自動的にそのユーザーに割り当てられます。

タグ

チケットには複数のタグ（Tags）を割り当てることができます。タグには名前と値の両方があります。タグ名と値を分離することで、チケットに意味を追加できます。たとえば、prod、qa、testなどの値を持つenvタグを追加したり、featureXYZなどの値を持つworkstreamタグを追加したりします。

検索

修復セクションには、複数の検索機能が用意されています。検索は、検索値にマッピングされたサポート対象のキーワードを指定することによって実行されます。

サポートされているキーワードは以下のとおりです。

• 優先度（Priority）による検索、値はP0からP3までです。

• チケットステータスによる検索、値は OPEN、REOPEN、FIXED、FIXED VERIFIED、EXCEPTION、FALSE POSITIVE です。

• 割り当てられたメールアドレスまたは報告者のメールアドレスによる検索。

• ブール値のショートカットによる検索で、自分に割り当てられたチケットまたは自分が報告したチケットを見つけます。値は true と false です。

• タグ名とタグ値による検索。

• 作成日、変更日、開始日、終了日による検索。

修復では、組織全体のコラボレーションが提供されます。組織内のすべてのものは、同じ組織のすべてのメンバーがアクセスし、表示できます。これには、スキャンへのアクセス、脆弱性データへのアクセス、チケットデータへのアクセスなどが含まれます。

チケットでのコラボレーションは、コメントセクションを使用して行うことができます。コメントは更新または削除できます。アクションの痕跡はアクティビティセクションに記録されます。

複数のチーム間で一部のデータを共有できない場合は、専用の組織を作成して、すべての相互作用を同じ組織内に限定することができます。これは通常、アプリケーションの1つが外部のサードパーティによって構築され、他のアプリケーションが内部で構築される場合に適用されます。

これを行うには、ダッシュボード（Dashboard）に移動して設定（Settings）をクリックして展開し、アクセス（Access）を選択します。

組織の追加（Add organisation）をクリックし、組織の情報を入力します。

ユーザーを追加するには、3つのドットをクリックし、ユーザーの追加（Add user）オプションを選択します。

そして、ユーザーのメールアドレスを入力します。

また、自律的なセキュリティの5つの柱の1つはポリシー（Policies）です。

次のような複数のポリシータイプがあります。

• 異なる重大度の脆弱性が修正されるタイミングを定義するパッチ適用ポリシー（Patching policy）。

• 本番環境で実行されているソフトウェアやハードウェアの古さを定義する鮮度ポリシー（Freshness policy）。

• 危険なシステムを隔離または切断できる条件を定義する施行ポリシー（Enforcement policy）。

これらは修復ポリシーのほんの一例です。現段階では、Ostorlabはパッチ適用ポリシーの設定と適用のみをサポートしています。

パッチ適用ポリシーでは、確認済みの脆弱性とハードニング（Hardening）の推奨事項を処理するためのSLO（Service Level Objectives）を定義します。例として、重大度が高い（High）問題を5日以内に修正することが挙げられます。

ポリシーはチケットシステムによって適用され、チケット作成時間と定義されたポリシーに照らした脆弱性の最も高い重大度を比較します。

チケットシステムは日常の業務を管理し、問題が修正されて破棄されないようにするのに役立ちますが、セキュリティプログラムのパフォーマンスを全体的に把握するには不十分です。

このため、チケットシステムは、自律的セキュリティプログラムの第5の柱であるメトリクスおよびダッシュボードの柱で補完されています。

メトリクスモジュールは、重大度が高い問題の数や修正された問題の数などの時間ベースのメトリクスや、再オープン率や安全なアセットの割合などのグローバルなメトリクスを収集します。これらのメトリクスには、組織のダッシュボードでアクセスできます。

チケット関連のすべてのメトリクスについてさらに詳しく理解するには、次のリンクにあるドキュメントを参照してください。