アセット (Open Source)

組織 → アセット → エンゲージメント → テスト → 検出事項

概要#

アセットは、DefectDojoのオブジェクト階層においてセキュリティ業務がどのように整理されるかの中心に位置します。アセットは、セキュリティチームがテストしているあらゆるプロジェクト、プログラム、ソフトウェア、または物理的な資産を表し、そのテスト目標に関連するすべてのセキュリティ業務とテスト履歴を保持します。アセットの例には次のようなものがあります。

• ソフトウェアリリース
• サードパーティ製ソフトウェア
• 本番環境の仮想マシンまたは資産
• 単一のアプリケーション
• マイクロサービス
• API
• SaaSプラットフォーム
• モバイルアプリ
• 社内システム
• ビジネスサービス
• 顧客向けプラットフォーム
• クラウド環境またはインフラストラクチャドメイン

一般に、アセットはセキュリティ体制を長期的に追跡したい「対象」を表すべきものです。これには、その「対象」に関連するテスト履歴、検出事項、メトリクス、所有権、インテグレーション、修復ワークフローが含まれます。

アセットの例#

アセットは、組織のニーズに応じてさらに細かく分割することもできます。たとえば、次のようなシナリオでは、別々のDefectDojoアセットを作成することを検討してもよいでしょう。

• 「ExampleAsset」にWindows版、Mac版、クラウド版がある
• 「ExampleAsset 1.0」が「ExampleAsset 2.0」とはまったく異なるソフトウェアコンポーネントを使用しており、両方のバージョンが自社によって積極的にサポートされている
• 「ExampleAsset version A」の作業を担当するチームが「ExampleAsset version B」を担当するアセットチームとは異なり、その結果として異なるセキュリティ権限を割り当てる必要がある

これらの違いを単一のアセット内のエンゲージメントとして表現することもできますが、RBACはアセットまたは組織のレベルでしか設定できないため、そのように整理した場合、ユーザーが適切なエンゲージメント(およびそのエンゲージメント内のテストと検出事項)にアクセスできる範囲が制限される可能性があります。DefectDojoにおけるRBACと権限の詳細については、こちらをクリックしてください。

アセットデータ#

アセットには、常に次の項目が含まれます。

• 一意の名前
• 説明
• 組織
• SLA設定

オプションのアセットメタデータには、次のものが含まれます。

• タグ
• 担当者情報(例: アセットマネージャー、チームマネージャー、テクニカルコンタクトなど)
• 規制(例: HIPAA、GLBA、OPPAなど)
• ビジネス上の重要度
• プラットフォーム(例: API、デスクトップ、IoT、モバイル、Webなど)
• ライフサイクル(例: 構築、本番稼働、廃止など)
• 出所(例: サードパーティライブラリ、購入品、オープンソースなど)
• ユーザーレコード(すなわち、アセット内のユーザーレコードの推定数)
• 収益

このメタデータは、セキュリティプログラム全体にわたるフィルタリング、レポート作成、優先順位付けを向上させます。しかし何よりも重要なのは、アセットにはそのアセットを取り巻くテスト活動に関連するすべてのエンゲージメント、テスト、検出事項が含まれるという点です。テストから得られたすべての検出事項は、最終的にアセットレベルに集約され、長期的な追跡、トレンド分析、レポート作成を可能にします。

アセットへのアクセス#

アセットにはサイドバーからアクセスできます。サブメニューには、新しいアセットを作成するオプションも用意されています。

権限#

アセットには、ロールベースアクセス制御(RBAC)ルールを適用でき、チームメンバーがアセットを閲覧・操作できる範囲を制限できます。

権限は下位へと継承されます。つまり、あるアセットへのアクセス権を持つと、そのアセット内のすべてのオブジェクト(エンゲージメント、テスト、検出事項など)へのアクセス権も自動的に付与されます。

ユーザーロールの詳細については、ロールの紹介記事を参照してください。

アセットビュー#

アセットビューには、アセットのステータスを一目で把握するためのさまざまな表やグラフが含まれます。具体的には次のとおりです。

• メタデータ
  • 組織、ビジネス上の重要度、収益など、アセット設定から追加された詳細情報を含みます。
• メトリクス
  • アセット内の未対応の検出事項の一覧を、深刻度別にグループ化したもの
• 深刻度別のサービスレベルアグリーメント
  • 設定で定義されたアセットのSLA設定を、アセット内の検出事項に適用します。
• テクノロジー
  • 例: next.js、vue.js、npm v.1.2.3、Django、nginx、Hugo
• 規制
• ベンチマークの進捗
• メンバー
• グループ
• 連絡先
• 通知
  • 特定のイベント(例: エンゲージメントが追加または終了した場合)に応じて、通知のオン・オフを切り替えます。

アセットの操作#

アセットの作成#

新しいアセットを作成する方法は複数あります。

• 「すべてのアセット」一覧にあるアセットを追加ボタン

• 組織のビュー内にあるアセットテーブルのドロップダウンメニューから
  • この方法では、その組織内に自動的にアセットが作成されます。

• サイドバーにあるアセットを追加ボタン

アセットの編集#

アセットは、その設定から編集できます。設定には次の2つの方法でアクセスできます。

• 「すべてのアセット」ビューでアセットの左側にある⋮(縦三点)メニュー内の編集ボタン

• アセットのビューにある設定ドロップダウン内の編集ボタン

アセットの削除#

アセットを削除するオプションは、上記のアセットの編集セクションで説明したのと同じメニューの下部にあります。この操作は元に戻せません。アセットは、後でクローズして再度開くことはできません。

アセットを削除すると、次のものも削除されます。

• アセットに含まれるすべてのエンゲージメントとテスト
• 検出事項やインテグレーションを含む、関連するすべてのセキュリティ履歴
• リンクされているすべてのJira Epic
• アセットのエンゲージメントとテストに関連するすべてのメモとアップロードされたファイル

アセットの境界#

重複排除#

アセットは互いに「隔離」されており、他のアセットと影響し合うことはありません。重複排除などのDefectDojoのスマート機能は、単一のアセットの範囲内でのみ適用されます。異なるアセットにまたがる検出事項が自動的に重複排除されることはありません。

メトリクス#

ほとんどのレポートとメトリクスは、アセットレベルでデータを集計するため、アセットはリスクを測定・追跡するための主要な単位となります。

その結果、多くの主要なメトリクスがアセットごとに算出されます。例えば次のとおりです。

• 検出事項の総数(深刻度またはステータス別)
• 平均修復時間(MTTR)
• SLA遵守率および違反率
• 時間経過に伴うリスクの傾向

つまり、アセットの構造の取り方が、レポートの正確性と有用性に直接影響します。たとえば、複数の無関係なシステムを1つのアセットにまとめると、リスクの可視性が損なわれる可能性がある一方、アセットの構造を細かく分割しすぎると、レポートが分断され、より広範な傾向を把握しにくくなることがあります。

アセット固有のメトリクスには、選択したアセットのビューの上部バーにあるメトリクスボタンからアクセスできます。

CI/CDパイプライン#

CI/CDパイプラインは、スキャン結果のインポートを自動化します。連携方法にかかわらず、すべてのスキャンインポートはアセットに関連付けられる必要があり、アセットはパイプライン駆動のセキュリティデータの基点となります。

パイプラインがスキャン結果を送信する際は、次のいずれかを行う必要があります。

• 既存のアセット(および任意でエンゲージメント)を指定する、または
• 結果が常に正しいアセットにマッピングされるように設定する

インポートされたすべての検出事項は、所有権、権限、SLA設定、レポートの範囲を含むアセットのコンテキストを継承します。

実務上、アセットは、CI/CD内でシステムがどのように構築・デプロイされるかを反映するように定義し、セキュリティの結果が常に正しいアプリケーションやサービスに関連付けられるようにすべきです。

Jiraとの関係#

アセットは、Jiraプロジェクトに直接マッピングでき、それによりアセットの検出事項がJiraインスタンスにプッシュされます。

検出事項は親アセットからリスク、優先度、所有権を継承するため、アセットは実質的に、Jiraチケットやダウンストリームコネクタのワークフローに流れ込む修復コンテキストを決定します。

重要な点として、アセットは検出事項のSLA特性を決定する主要な要因でもあります。そのため、検出事項のSLAは、その親アセットのSLA設定に依存します。SLA設定の詳細については、こちらを参照してください。