Ostorlabによる効果的な脆弱性チケットシステムの運用

脆弱性を発見することは、セキュリティ修正を修復し、デプロイし、検証するという、しばしば長い道のりの始まりにすぎません。

この道のりは、プロセスを効率化し、検出・修復・修正の検証を修復管理のライフサイクルに統合するための適切なツールがなければ、すぐに骨の折れるものになりかねません。

従来のチケットシステムでは、新しい問題のトリアージ、重複の特定、誤検知の管理に多大な手作業を要することがよくあります。大規模な組織では、スキャナーからの検出結果をトリアージし、重複を確実に取り除くという作業だけに専念する担当者やチームを置いていることもあります。多くの人が心底うんざりする、華々しい作業です。

ServiceNowが実施した2022年の調査によると、組織は脆弱性管理の活動に週平均443時間を費やしており、これはおよそ11人のフルタイム従業員に相当します。

Ostorlabプラットフォームの中核的な機能の一つが、脆弱性管理向けに仕立てられた包括的なチケットシステムです。脆弱性修正のライフサイクルを扱ううえでの課題に対処するために、ゼロから構築・設計されています。

Ostorlabのチケットシステムは2021年10月にリリースされました。これにより、1万を超える組織が、セキュリティ脆弱性の管理と修復のプロセス全体を自動化・効率化できるようになりました。

Ostorlabのチケットシステムの中核的な機能には、次のものが含まれます。

• 新たに検出された脆弱性のチケットを自動生成し、種類、重大度、コンテキストといった詳細な情報を埋め込みます。
• 一意の識別子（DNA）を用いて、繰り返し発生する脆弱性を単一のチケットに集約します。
• 修正された脆弱性は再スキャンによって自動的に検証され、問題が効果的に解決されていることを確認します。
• 高重大度の問題を5日以内に解決するなど、サービスレベル目標（SLO）によってパッチ適用のポリシーを適用します。
• Jiraのようなツールとのシームレスな互換性により、組織は既存のワークフローの中で脆弱性を管理できます。

2024年には、Ostorlabの顧客の平均修復時間（MTTR）は17日で、クリティカルな問題はわずか5日、高セキュリティの問題は10日でした。

チケットシステムの初期バージョンは、一意のDNAに基づいてチケットを集約するという革新的なアプローチをもたらしましたが、継続的なユーザーからのフィードバックにより、開発者やセキュリティチームがさまざまな環境やプラットフォームにまたがって脆弱性を管理する際に直面する新たな課題が明らかになりました。

本日、当社はOstorlabチケットシステムV2のリリースをお知らせします。V2はこれらの課題に対処し、さまざまな環境やプラットフォームにまたがってチケットを集約する方法に、より高い柔軟性をもたらします。

課題

複数のバージョンやプラットフォームにまたがって脆弱性のステータスを追跡することは難しく、一貫性のない修復につながりかねません。

たとえば、AndroidとiOSにモバイルアプリケーションがある場合、そのアプリケーションの開発ライフサイクルは通常、開発版、ステージング、プレプロダクション、本番の4つのステップを持ちます。

このシナリオでは、単一の脆弱性が最大8件もの別々のチケット（2つのプラットフォーム×4つのライフサイクルステージ）を生成する可能性があり、問題を効果的に管理・修復しようとするセキュリティチームにとって、運用上の厄介ごとを生み出します。

この断片化したアプローチは、さまざまな環境やプラットフォームにまたがって脆弱性が一貫性なく修正される結果を招くことがよくあります。たとえば、あるクリティカルなセキュリティ上の欠陥が、Androidの本番バージョンではパッチ適用されても、iOSのステージング環境では見落とされる、といったことが起こり得ます。

OstorlabチケットシステムV2はこれらの問題をどのように解決するのか

チケットを集約するために事前定義されたロジックを使うのではなく、ユーザーは、さまざまなプラットフォームや環境にまたがって脆弱性をどのようにグループ化したいかを、自ら定義できるようになりました。

ユースケース1：

• AndroidとiOSにモバイルアプリケーションがあります。
• 開発版をスキャンするために、APKまたはIPAのファイルをアップロードします。
• 本番バージョンをスキャンするために、PlayStoreとAppStoreからスキャンします。

-> 環境とプラットフォームごとにチケットを持ちたいと考えています。

そのためには、プラットフォームごとのグループ化を定義し、各環境を別々のグループに設定します。

ユースケース2：

• AndroidとiOSにモバイルアプリケーションがあります。
• 開発版をスキャンするために、APKまたはIPAのファイルをアップロードします。
• 本番バージョンをスキャンするために、PlayStoreとAppStoreからスキャンします。

-> ストアまたはファイルからのAndroidのチケットをグループ化したいと考えています。iOSについても同様です。ただし、Androidのファイルで問題が修正されても、ストアバージョンで修正が得られるまで、チケットは開いたままにしておくべきです。

そのためには、プラットフォームごとのグループ化を定義し、各環境を別々のグループに設定します。

ユースケース3：

• AndroidとiOSにモバイルアプリケーションがあります。
• APKとIPAのファイルについて、異なる環境があります。
  • Dev: com.myapp.dev
  • QA: com.myapp.qa
  • Prod: com.myapp.prod
• 本番バージョンをスキャンするために、PlayStoreとAppStoreからスキャンします。

-> すべての環境のバージョンにまたがって、ストアまたはファイルからのAndroidのチケットをグループ化したいと考えています。iOSについても同様です。 ただし、Androidのファイルで問題が修正されても、すべてのバージョンで修正が得られるまで、チケットは開いたままにしておくべきです。

そのためには、アプリケーションIDごとのグループ化を定義し、各アプリケーションIDを一つのグループに設定します。

ユースケース4：

• AndroidとiOSで、モバイルアプリケーションをホワイトラベルで提供しています。
• APKとIPAのファイルについて、異なる顧客があります。
• Android: com.android.myapp.customer
• iOS: com.ios.myapp.customer

-> ホワイトラベルのアプリケーションからのAndroidのチケットを、一つのチケットにグループ化したいと考えています。

このユースケースは、すべてのアプリケーションIDを含む一つのグループを定義するだけで済むため、ユースケース3に似ています。たとえばここでは、顧客の正規表現を用いた一つのグループを追加します。

おわりに

OstorlabチケットシステムV2は柔軟性をもたらし、ユーザーが自社の内部フローに沿った集約ロジックを定義できるようにします。