build-threat-catalog

Generate schema-validated threat catalogs for FINOS Common Cloud Controls.

85|80|Updated Jul 26, 2023
One-click install
npx skills add https://github.com/finos/common-cloud-controls --skill build-threat-catalog
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: build-threat-catalog
Source: https://github.com/finos/common-cloud-controls/tree/main/skills/build-threat-catalog
Command: npx skills add https://github.com/finos/common-cloud-controls --skill build-threat-catalog

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Manually creating consistent, framework-mapped threat catalogs for cloud services in the FINOS Common Cloud Controls (CCC) standard is time-consuming and prone to errors, risking non-compliance with CCC schema requirements and incomplete mapping to standard cybersecurity frameworks.

Core Features & Use Cases

  • Core Threat Reuse: Automatically imports applicable pre-defined CCC core threats to avoid duplication of generic risks.
  • Service-Specific Threat Mapping: Defines unique threats for a cloud service's capabilities, grounded in real-world adversary behavior and CSP security advisories.
  • Framework Alignment: Maps each threat to external standards including MITRE ATT&CK, MITRE D3FEND, CISA KEV, CWE, and OWASP, with strict gating based on declared metadata references.
  • Use Case: A cloud security engineer onboarding a new IaaS service to the CCC repository can use this skill to generate a complete, schema-validated threats.yaml file that aligns with CCC standards and maps service-specific risks like misconfigured access controls to relevant MITRE ATT&CK techniques.

Quick Start

Use the build-threat-catalog skill to generate a validated threats.yaml file for the AWS S3 service catalog in the CCC repository.

Frequently Asked Questions about build-threat-catalog

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a schema-validated cloud threat catalog for new cloud services?

Generate a schema-validated cloud threat catalog by importing pre-existing CCC core threats and mapping service-specific risks to frameworks like MITRE ATT&CK and CWE. This process outputs a validated threats.yaml file aligned with the FINOS Common Cloud Controls standard.

Do I need existing metadata files to build a CCC threat catalog?

Yes, building a CCC threat catalog requires pre-existing metadata.yaml and capabilities.yaml files for the target cloud service. These files provide the declared metadata references needed to enforce mapping gates and validate the final output against the official CCC threats schema.

How do I map cloud service threats to MITRE ATT&CK and CWE frameworks?

Map cloud service threats to MITRE ATT&CK and CWE frameworks by defining service-specific risks grounded in adversary behavior and CSP advisories. The catalog generation process enforces strict framework alignment based on declared metadata references for each threat.

What is the best way to onboard an IaaS service into the FINOS CCC repository?

Onboard an IaaS service into the FINOS CCC repository by generating a complete threats.yaml file that aligns with CCC standards. This involves reusing applicable core threats and mapping unique service capabilities to external cybersecurity frameworks like MITRE D3FEND and CISA KEV.

Why does my CCC threat catalog fail schema validation during generation?

CCC threat catalog schema validation fails when output does not meet official CCC threats schema requirements or mapping gates. Validation errors often stem from incomplete framework mappings or missing declared metadata references required for external standards like OWASP and MITRE ATT&CK.

Can I reuse pre-defined CCC core threats when generating a cloud security catalog?

Yes, you can reuse pre-defined CCC core threats during cloud security catalog generation to avoid duplicating generic risks. The process automatically imports applicable core threats while focusing service-specific definitions on unique capability risks mapped to external frameworks.