CyberForces CWPP の仕組み How CyberForces CWPP works

接続の流れHow onboarding works

実際のプロバイダ接続は、おおむね次の 6 ステップです。最短で同日に横断運用を開始できます。Connecting a provider is roughly six steps — you can be operating across providers the same day.

1. 1

   コネクタを作成Create a connector

   プロバイダ（Vision One / Cloud One / CrowdStrike）を選び、その API 認証情報を登録します。Vision One は API トークン＋リージョン、Cloud One は api-secret-key、CrowdStrike は OAuth2 クライアント認証情報。認証情報はテナント単位で安全に保管します。Pick a provider (Vision One / Cloud One / CrowdStrike) and register its API credentials — Vision One: API token + region, Cloud One: api-secret-key, CrowdStrike: OAuth2 client credentials. Credentials are stored securely per tenant.

2. 2

   接続テストTest the connection

   登録した認証情報でプロバイダ API への疎通を確認します。以降、同期ヘルスはコネクタ単位で継続的に追跡されます。A connection test verifies access to the provider API with the registered credentials. From then on, sync health is tracked per connector.

3. 3

   初回同期（在庫と検知）Initial sync (inventory & detections)

   エンドポイント在庫と検知を取得し、統一スキーマへ正規化。endpoint_id を <provider>:<native_id> で名前空間化し、重大度・ステータスを共通 enum に揃えます。オンデマンド同期も可能です。Endpoint inventory and detections are pulled and normalized into the unified schema — endpoint_id is namespaced <provider>:<native_id> and severity/status mapped to common enums. On-demand sync is available too.

4. 4

   グループスコープを設定Scope to groups

   コネクタを特定のグループにスコープすると、そのチームだけがコネクタと派生するエンドポイント・検知を見られます。サーバ側でアクセストークンのグループクレームから強制されます。Scope a connector to specific groups so only that team sees the connector and its derived endpoints/detections. This is enforced server-side from the access token's group claims.

5. 5

   AI トリアージを有効化Enable AI triage

   検知ごとの AI 分析・推奨アクション・日次ブリーフィングを有効化。Bedrock（Claude）は Lambda の IAM ロールで認証され、ページや設定に API キーは存在しません。Turn on per-detection AI analysis, recommended actions and daily briefings. Bedrock (Claude) authenticates via the Lambda's IAM role — there is no API key in the page or config.

6. 6

   運用開始Operate

   横断ダッシュボードで検知をトリアージし、必要なエンドポイントを隔離、関連検知をインシデントへ束ね、対応を追跡タスクへ昇格。状態を変える操作はすべて監査可能です。Triage detections in a cross-provider dashboard, isolate endpoints where needed, group related detections into incidents, and promote responses into tracked tasks — every state-changing action is auditable.

接続後も基盤の EDR/EPP は置き換えません。コネクタはいつでも削除でき、削除しても各プロバイダ側の保護やデータには影響しません。Even after connecting, we never replace the underlying EDR/EPP. A connector can be removed at any time, and removing it does not affect protection or data on the provider side.

同期基盤と可視化Sync pipeline & observability

正規化モデル（イメージ）Normalized model (illustrative)

いずれもプロバイダ差を吸収した統一表現です。endpoint_id は名前空間付き、enum は共通語彙に揃えます。Each is a unified representation that absorbs provider differences — endpoint_id is namespaced and enums use a common vocabulary.

{
  endpoint_id:
    "visionone:abc123",
  provider: "visionone",
  hostname: "web-01",
  status: "online" |
    "offline" | "isolated"
}

{
  endpoint_id: "...",
  severity: "critical" |
    "high" | "medium" |
    "low" | "info",
  status: "new" |
    "in_progress" |
    "resolved" |
    "false_positive"
}

{
  detections: [ ... ],
  ai_summary: "...",
  timeline: [ ... ],
  attack: { technique,
    tactic } // MITRE
}

データモデルと定期実行Data model & scheduled jobs

データストア（DynamoDB）Data stores (DynamoDB)

定期実行ジョブScheduled jobs

AI と応答のメカニズム（詳細）AI & response mechanisms (in detail)