User Prompt for AI with Mission "Analyze through the Lens of the TLCTC"

TLCTC Enhanced Prompt for AI Analysis

A ready‑to‑paste prompt that instructs an AI to analyze any Security Report, Cyber Incident Report, or similar document through the lens of the Top Level Cyber Threat Clusters (TLCTC) framework. This prompt ensures structured, defensible output aligned with strategic risk management and operational security.
How to Use This Prompt

Copy the prompt: Click the "Copy Prompt" button below to copy the entire prompt to your clipboard
Paste to AI: Paste this prompt into your AI tool (ChatGPT, Claude, etc.)
Add your report: Follow the prompt with your security report, incident report, or threat intelligence document
Get structured analysis: The AI will analyze your document through the TLCTC framework and provide structured output including attack paths, control failures, and recommendations
TLCTC AI Analysis Prompt (v1.2)
                            
Goal: Analyze cybersecurity incidents detailed in the provided Radar report. First, create a structured table summarizing each incident and mapping them to Top Level Cyber Threat Clusters (TLCTC), including attack paths. Second, generate a summary in German. Third, produce a JSON output suitable for a cyber threat radar visualization based on the analysis.

Input:

Security Report: Input from User
TLCTC Definitions: (Provided below)
Additional Mapping Rules: (Provided below)
Output Language:
Table Kurzbeschreibung des Vorfalls column: German.
Summary section: German.
All other analysis, table columns, and JSON output: English.
Task Breakdown:

Part 1: Incident Analysis and Table Creation

Incident Identification:

Scan the specified report.
Identify individual incidents. Treat each numbered subsection detailing a specific event (e.g., sections 3.2, 3.3, 4.1 in a typical report) as a distinct incident.
Table Creation: Create a table with the following columns:

Nummer: Sequential number.
Region: "CH" if the incident explicitly mentions Switzerland or a Swiss location. Otherwise, "ROW".
Betroffenes Institut: List all affected institutions named. If none, state "Not Specified".
Kurzbeschreibung des Vorfalls: Concise summary (1-2 sentences) in German based only on the report.
TLCTC Mapping: Perform TLCTC analysis as per definitions and rules. List TLCTC numbers. Use '->' for described attack paths (e.g., #9 -> #4). Use commas for independent clusters (e.g., #1, #4). If insufficient info, state "Insufficient Information for Mapping".
Part 2: Summary Generation (German)

After processing all incidents, provide a brief summary section in German:
Allgemeine Aussage ROW: Summarize incident types or prevalent TLCTC clusters for "ROW" based only on analyzed incidents.
Allgemeine Aussage CH: Summarize incident types or prevalent TLCTC clusters for "CH" based only on analyzed incidents.
Allgemeine Aussage CH-Finanzsektor: If Swiss Financial Sector targets identified, summarize those incidents/TLCTCs. If none, state "Keine spezifischen Vorfälle im CH-Finanzsektor identifiziert".
Part 3: JSON Output for Cyber Threat Radar

Based on the entire analysis of the report, generate a JSON object.
The root of the JSON object should contain one key: "sectors".
The "sectors" key will hold an array of two sector objects, one for "CH" and one for "ROW".
Each sector object (for "CH" and "ROW") must have the following structure:
id: (string) "sector_CH" or "sector_ROW".
name: (string) "CH" or "ROW".
color: (string) Assign a default color (e.g., "blue" for CH, "green" for ROW).
backgroundColor: (string) Assign a default translucent color (e.g., "rgba(0,0,255,0.1)" for CH, "rgba(0,128,0,0.1)" for ROW).
activeThreats: (object) Map of TLCTC IDs (string "1" to "10") to boolean true (assume all defined TLCTCs are potentially active for monitoring).
values: (object) Map of TLCTC IDs (string "1" to "10") to a numerical value (0-100). This represents the current threat level for each TLCTC in this sector, derived from your analysis of the current report. Use the following guidelines for assigning values:
0: No incidents reported or TLCTC not mentioned for this sector in the report.
1-30 (Low): Few mentions, 1-2 minor incidents, or generally low concern indicated for this TLCTC in this sector.
31-70 (Medium): Several incidents, some significant incidents, or moderate concern indicated.
71-100 (High): Many incidents, critical incidents, or the TLCTC is highlighted as a dominant/major concern for this sector in the report.
oldValues: (object) Map of TLCTC IDs (string "1" to "10") to a numerical value (0-100). This represents a qualitative baseline or previous state assessment for each TLCTC in this sector. Derive these values using a "best effort" qualitative interpretation of the current report's overall context for each TLCTC within the sector, applying the following mapping:
If the TLCTC is not mentioned at all in the analyzed incidents for the sector: 0 (Latent).
If the TLCTC is mentioned only once or rarely for the sector: 5 (Low).
If the TLCTC is mentioned moderately or with average frequency/impact for the sector: 20 (Medium).
If the TLCTC is a dominant theme or frequently mentioned with high impact for the sector in the report: 70 (High).
zoneLimits: (object) Map of TLCTC IDs (string "1" to "10") to an object defining zone thresholds. Use the default: {"latent": 0, "low": 5, "medium": 35, "high": 100} for each TLCTC.
toBeReported: (object) Map of TLCTC IDs (string "1" to "10") to a boolean. Set to true if any incident analyzed for that specific TLCTC in that sector involved a financial institution as a target. Otherwise, set to false.
riskToleranceCrashed: (object) Map of TLCTC IDs (string "1" to "10") to a boolean. Default to false for all, unless an incident explicitly states risk tolerance was exceeded.
[TLCTC Definitions]
#1 Abuse of Functions
Definition: An attacker abuses the logic or scope of existing, legitimate software functions, features, or configurations for malicious purposes. This manipulation occurs through standard interfaces using expected input types (data, parameters, configurations, sequence of actions), but in a way that subverts the intended purpose or security controls.

Generic Vulnerability:
The scope, complexity, or inherent trust placed in legitimate software functions, features, and configurations. More scope/complexity can create a larger attack surface.

Context: This threat addresses the manipulation of the functional domain itself – what the software is designed to do. The attacker misuses capabilities intentionally built into the system, often exceeding implicit boundaries or leveraging overly permissive designs via standard interfaces using expected input types (data, parameters, configurations, sequence of actions). Crucially, this does not involve executing foreign Malware Code (unlike #7), nor does it rely on exploiting specific implementation flaws/bugs (unlike #2/#3 Exploiting Server/Client). When initiated via Social Engineering (#9), this often involves tricking a user into enabling, disabling, or misconfiguring legitimate, existing features (e.g., enabling RDP access, creating firewall exceptions, changing security settings), rather than installing new software (which would facilitate #7).

Sub-Threats Examples: Data Poisoning, Abuse of document sharing functions, BGP Hijacking, Misuse of API functionalities, Parameter Tampering (exploiting logic), Enabling insecure configurations

Control Examples:
Input validation (for logic), Strong configuration management, Least privilege for functions/APIs, Feature usage monitoring, Business logic checks, Multi-step approvals for sensitive configurations

Attacker's View:
"I abuse a functionality, not a coding issue."

Asset Type: Software (Its functions and configuration)

#2 Exploiting Server
Definition: An attacker targets and leverages flaws originating directly within the server-side application's source code implementation. These vulnerabilities (e.g., improper input handling, insecure API usage, resource leaks, logic errors introduced during coding) allow manipulation of server behavior or unauthorized access using Exploit Code.

Generic Vulnerability:
The presence of exploitable
flaws within the server-side source code implementation
and its resulting logic, stemming from insecure coding practices.

Context: This cluster isolates vulnerabilities that are fundamentally mistakes made by developers during coding on the server side. It addresses the direct consequences of insecure software development practices related to how code handles data, manages resources, or implements application logic. An attacker uses Exploit Code to trigger these specific code-level bugs. This focus on source code implementation flaws distinguishes it from:
- #1 Abuse of Functions, which misuses the intended design and logic of correctly coded functions.
- #7 Malware, which executes malicious code via a designed execution capability, not a bug in the application code.
- #3 Exploiting Client, which targets flaws in the client-side source code implementation.

Sub-Threats Examples: SQL Injection (coding flaw in query building), Buffer Overflows (coding flaw in memory handling), RCE via Deserialization (coding flaw in data processing), SSRF (coding flaw in URL processing), XXE Injection (coding flaw in XML parsing), Stored/Reflected XSS (coding flaw in handling output)

Control Examples:
Secure Coding Training & Standards
, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Manual Code Review, Input Validation/Sanitization Libraries, Output Encoding,
Content Security Policy (CSP)
, Secure Component Usage, Patching, WAF

Attacker's View:
"I abuse a
flaw in the application's source code
on the server side."

Asset Type: Software (Specifically, the server-side application source code implementation)

#3 Exploiting Client
Definition: An attacker targets and leverages flaws originating directly within the source code implementation of any software acting in a client role (requesting/processing data from a server or resource). These vulnerabilities (e.g., improper handling of responses or local data, insecure interaction with local resources, logic errors introduced during coding) allow manipulation of client behavior, unauthorized access to client resources, or information disclosure using Exploit Code, often when the client interacts with malicious content, servers, or manipulated local state.

Generic Vulnerability:
The presence of exploitable
flaws within the source code implementation of software acting as a client
, stemming from insecure coding practices related to processing external data/responses, rendering UI, or managing client-side state and resources.

Context: This cluster isolates vulnerabilities that are fundamentally mistakes made by developers during coding within any software component performing a client function – receiving and processing data/responses. Examples include web browsers, mobile apps, desktop applications, document readers, command-line clients (SSH, SQL), client libraries (e.g., HTTP, database connectors), API consumers, and background services acting as clients. It addresses insecure development practices in how this client code handles data, interacts with APIs, or renders information. An attacker uses Exploit Code to trigger these code-level bugs. This focus on client-role source code implementation flaws distinguishes it from:
- #1 Abuse of Functions, which misuses the intended design and logic.
- #7 Malware, which executes malicious code via a designed execution capability.
- #2 Exploiting Server, which targets flaws on the server side.

Sub-Threats Examples: DOM-Based XSS (client script coding flaw), Client Library Buffer Overflows (e.g., in libcurl handling responses), Insecure Deserialization in Client/API Consumer, Command-line Client argument/response handling flaws, Exploits targeting browser/plugin rendering engines.

Control Examples:
Secure Coding Training & Standards (Client-Side Focus)
, SAST/DAST for client code/libraries, Framework/Library Protections, Secure handling of data from all external sources (servers, files, URLs, APIs), Avoiding dangerous functions, Keeping all client software/libraries patched.

Attacker's View:
"I abuse a
flaw in the source code
of software acting as a client." (Often triggered by crafted input/data/response)

Asset Type: Software (Specifically, the source code implementation of software acting in a client role)

#4 Identity Theft
Definition: An attacker targets weaknesses in identity and access management processes or credential protection mechanisms to illegitimately acquire, steal, or misuse authentication credentials (e.g., passwords, tokens, keys, session identifiers, biometrics) to impersonate a legitimate identity (human or technical).

Generic Vulnerability:
Weak Identity Management Processes and/or inadequate credential protection mechanisms throughout the identity lifecycle (issuance, storage, transmission, validation, revocation), allowing credentials to be illegitimately acquired or misused.

Context: This cluster focuses specifically on the compromise of the authentication process itself through the theft or unauthorized acquisition/use of credentials. It includes the technical mechanisms designed solely to capture credentials, such as credential harvesting websites (phishing forms). While the delivery of such a form often relies on #9 Social Engineering (to trick the user into visiting and trusting the form), the form itself represents an attack targeting the credential acquisition process and thus falls under #4. The subsequent use of captured credentials is also #4. This focus on credential compromise distinguishes it from:
- #1/#2/#3 Exploiting Functions/Server/Client: Where credentials might be exposed secondarily due to function abuse or code flaws.
- #7 Malware: Which might be a tool used to steal credentials (e.g., keylogger), facilitating #4.
Note: Bypassing authentication without compromising credentials typically maps to #1 or #2.

Sub-Threats Examples: Credential Stuffing, Password Spraying, Session Hijacking, Pass-the-Hash/Ticket attacks, Stealing API Keys/Secrets, Credential Harvesting Forms/Websites

Control Examples:
Multi-Factor Authentication (MFA), Strong password policies, Credential rotation, Secure credential storage, Session management, Anti-phishing training (#9) & technical controls (URL filtering, browser warnings against known #4 harvesting sites), Monitoring for credential abuse

Attacker's View:
"I abuse credentials, the mechanisms designed to steal them, or the processes managing them to operate as a legitimate identity."

Asset Type: Software (Identity/Access Management Systems, Credential Harvesting Mechanisms), Data (Credentials)

#5 Man in the Middle (MitM)
Definition: An attacker intercepts, eavesdrops on, modifies, or relays communication between two parties without their knowledge or consent, by exploiting a privileged position on the communication path. This position might be gained locally (e.g., on shared Wi-Fi) or by leveraging control over existing network intermediaries.

Generic Vulnerability:
The lack of sufficient control, integrity protection, or confidentiality over the communication channel/path, including the implicit trust placed in local networks (like public Wi-Fi) and intermediate network infrastructure in standard IP networking.

Context: This cluster describes attacks enabled by an attacker controlling a point on the communication path. Common examples familiar to end-users include attackers on the same public Wi-Fi network intercepting traffic, or potentially a compromised VPN service acting maliciously. More broadly, in standard Internet (IP) communication, intermediaries (routers, ISPs) always exist, creating potential MitM points if compromised (e.g., via BGP hijacking - #1). #5 focuses on the actions possible from this intermediary position (local or remote): eavesdropping, modification, injection, replay, protocol downgrades. This cluster is distinct from the methods used to initially gain the position (which fall under #1, #8, etc.). Network architectures like SCION aim to mitigate vulnerabilities in intermediate path infrastructure.

Sub-Threats Examples: Public Wi-Fi Eavesdropping/Injection, SSL/TLS Interception (via rogue AP or compromised intermediary), Session Hijacking (via intercepted cookies on insecure networks), DNS Spoofing from local network attacker, Malicious VPN Traffic Manipulation, Modifying data via compromised router

Control Examples:
End-to-End Encryption (E2EE), Using trusted VPNs, Transport Layer Security (TLS) with strong validation (HSTS, Cert Pinning), Avoiding untrusted public Wi-Fi for sensitive tasks, Network path monitoring, Data integrity checks, Architectures providing path control (e.g., SCION)

Attacker's View:
"I abuse my position (on the local network or via control over an intermediary) between communicating parties."

Asset Type: Network/Communication Channel & Path Infrastructure (including local networks)

#6 Flooding Attack
Definition: An attacker intentionally overwhelms system resources or exceeds capacity limits through a high volume of requests, data, or operations, leading to disruption, degradation, or denial of service for legitimate users.

Generic Vulnerability:
Finite
capacity limitations
inherent in any system component (e.g., network bandwidth, CPU, memory, storage, database limits, application quotas, API rate limits, process/thread pools).

Context: This cluster covers attacks whose primary goal is to exhaust a specific, limited resource required for service operation. While often associated with network-level Distributed Denial of Service (DDoS), it generically applies to overwhelming any capacity constraint. This includes application-level attacks like flooding databases with excessive posts/data, exhausting API rate limits, filling log storage, or triggering computationally expensive operations en masse. The attack leverages volume or intensity, often via legitimate protocols or application functions (sometimes scaled via #1 Abuse of Functions), rather than exploiting specific code flaws (#2/#3) or executing malware (#7). The outcome is typically Loss of Availability.

Sub-Threats Examples: Network DDoS (SYN Flood, UDP Flood, Amplification Attacks), Application Layer DDoS (HTTP Flood, Slowloris), Database Storage Exhaustion via excessive writes, Log Volume Attacks filling disk space, API Rate Limit Flooding, Computationally Expensive Request Flood

Control Examples:
Network Traffic Filtering/Scrubbing (DDoS Mitigation Services), Rate Limiting (Network & Application Level), Resource Quotas (Disk, DB storage, API calls), Efficient Resource Management in Code, Connection Pooling Limits, Input validation to prevent overly large/complex requests, Scalable Infrastructure Design, Anomaly Detection (Volume-based)

Attacker's View:
"I abuse the circumstance of always limited capacity in software and systems."

Asset Type: Software, Network, Hardware (Their finite resources/capacity)

#7 Malware
Definition: An attacker abuses the inherent ability of a software environment to execute foreign executable content, including inherently malicious Malware Code or legitimate tools/scripts used for malicious purposes ("dual-use" / LOLBAS).

Generic Vulnerability:
The software environment's
designed capability
to execute potentially untrusted 'foreign' code, scripts, or binaries.

Context: This cluster deals with unauthorized execution achieved via an environment's intended execution capabilities. This includes running inherently malicious Malware Code AND the malicious use of legitimate "dual-use" tools or scripts (e.g., PowerShell, PsExec, legitimate remote admin tools) introduced or invoked by the attacker. In both cases, the attacker leverages the design of the software environment to run executable content for malicious ends. When initiated via Social Engineering (#9), this often involves tricking a user into downloading and executing new, foreign software/scripts, rather than just reconfiguring existing system features (which would be #1). This is distinct from:
- #2/#3 Exploiting Server/Client, which utilize Exploit Code targeting implementation flaws.
- #1 Abuse of Functions, which manipulates the logic of existing functions using data/parameters, without executing foreign code/scripts/binaries.

Sub-Threats Examples: Ransomware, Trojans, Malicious Macros, Execution via PowerShell scripts, Use of PsExec for lateral movement, Malicious use of legitimate Remote Desktop tools (when installed by attacker/victim)

Control Examples:
Blocking file types, Application control/allow-listing (critical for dual-use tools), Anti-malware scanners, Script/macro execution policies, Behavioral analysis (detecting legitimate tools used abnormally), Sandboxing, PowerShell Constrained Language Mode

Attacker's View:
"I abuse the environment's designed capability to execute Malware Code, malicious scripts, or legitimate tools for my purposes."

Asset Type: Software (The execution environment, Dual-Use Tools)

#8 Physical Attack
Definition: An attacker gains unauthorized physical interaction with or causes physical interference to hardware, devices, facilities, or data transmission media (including wireless signals).

Generic Vulnerability:
The physical accessibility of hardware, facilities, and communication media (cabling, wireless spectrum), and the exploitability of Layer 1 (Physical Layer) communications and hardware interfaces.

Context: This cluster covers threats involving manipulation or disruption at the physical level. It encompasses two main types based on the interaction required:
1. Direct Physical Access Attacks: Require the attacker to physically touch or interact directly with the hardware, device, or its immediate secure environment (e.g., tampering, theft, connecting unauthorized devices, physical intrusion into facilities).
2. Indirect Physical Access Attacks: Exploit physical properties or emanations without requiring direct contact with the core device (e.g., electromagnetic eavesdropping like TEMPEST, signal jamming, environmental disruption, acoustic attacks).
Physical access can often bypass logical security controls and may be a precursor to other attacks (e.g., installing malware via USB - #7, stealing devices with credentials - #4).

Sub-Threats Examples: Hardware Tampering, Port Access (e.g., unauthorized USB/network connection), Physical Device Theft, Facility Intrusion, TEMPEST attacks, Signal Jamming, Wireless Interception (passive), Cutting Cables, USB Baiting

Control Examples:
Physical access controls (locks, guards, secure facilities), Device security (cable locks, port security), Data encryption at rest, Tamper detection/seals, Shielding against emanations (for TEMPEST), Wireless security protocols & monitoring, Secure hardware disposal

Attacker's View:
"I abuse the physical accessibility or properties of hardware, devices, and signals."

Asset Type: Physical (Hardware, Facilities, Media, Signals)

#9 Social Engineering
Definition: An attacker psychologically manipulates individuals into performing actions counter to their or their organization's best interests, such as divulging confidential information, granting access, executing code, or bypassing security procedures.

Generic Vulnerability:
Human psychological factors: gullibility, trust, ignorance, fear, urgency, authority bias, curiosity, or general compromisability.

Context: This cluster focuses exclusively on exploiting the human element through deception, manipulation, or influence. It leverages psychological triggers rather than technical vulnerabilities in code or systems. Social Engineering is very often the initial vector for more complex attacks, tricking users into actions that enable other threat clusters:
- Tricking a user to reveal credentials used in #4 Identity Theft.
- Tricking a user to install/run malicious code, enabling #7 Malware.
- Tricking a user to misconfigure systems or enable features, facilitating #1 Abuse of Functions.
Crucially, technical vulnerabilities (e.g., CVEs) are never mapped to this cluster; #9 is purely about human manipulation leading to an unsafe action.

Sub-Threats Examples: Phishing (lure/deception phase), Pretexting, Baiting, Quid Pro Quo, Tailgating, Spear Phishing, Whaling, Vishing, Smishing, Water holing (luring users to a compromised site)

Control Examples:
Security Awareness Training, Phishing Simulations, Clear procedures for handling requests (esp. for sensitive info/actions), Multi-person approvals for critical actions, Technical anti-phishing controls (email/URL filtering), Caller ID / Sender verification

Attacker's View:
"I abuse human trust and psychology to deceive individuals."

Asset Type: Human

#10 Supply Chain Attack
Definition: An attacker compromises systems by targeting vulnerabilities within an organization's supply chain. This involves compromising third-party software components, hardware, services, or distribution/update mechanisms that are trusted and integrated into the organization's own environment or products.

Generic Vulnerability:
The necessary reliance on, and implicit trust placed in, external suppliers, vendors, components, libraries, hardware, services, and their associated development or distribution processes.

Context: This cluster focuses on attacks where the initial vector leverages the trust relationship with external entities whose products or services are incorporated into the target's systems or development lifecycle. It's distinct from merely using a compromised third-party platform for attacks (e.g., using a compromised cloud server for C2 is not #10 unless the cloud service itself delivered malware via its trusted updates). Key vectors include:
1. Development Vector (Pre-Deployment): Compromising source code repositories, build systems, testing environments, or injecting vulnerabilities into third-party libraries/components before they are integrated by the target.
2. Update Vector (Post-Deployment): Compromising legitimate update mechanisms or distribution channels to deliver malicious updates for software, firmware, or hardware already in use.
3. Hardware Vector: Compromising hardware components or manufacturing processes.
A successful #10 attack often leads to #7 Malware deployment or other cluster activities within the target environment via the trusted channel.

Sub-Threats Examples: Compromised Software Updates (e.g., SolarWinds), Malicious Code in Third-Party Libraries/Dependencies (e.g., Log4j scenario if intentionally malicious), Backdoored Hardware Components, Compromised Build/CI/CD Pipelines injecting code, Tampered installation media.

Control Examples:
Third-Party Risk Management (TPRM), Software Composition Analysis (SCA), Software Bill of Materials (SBOM), Secure CI/CD pipeline practices, Code signing & verification of updates/dependencies, Hardware integrity checks, Vendor security assessments

Attacker's View:
"I abuse the trust in third-party components, services, or vendors incorporated by the target."

Asset Type: Software, Hardware, Services (Specifically, the third-party elements and distribution mechanisms integrated by the target)

[Important additional TLCTC mapping rules (for Part 1):]

Foreign software (e.g., add-ins, extensions, plugins) introduced by an attacker or unsafely installed by a user is generally considered #7 Malware.
Brute-force attacks targeting credentials (access data) map to #4 Identity Theft.
Any misuse of compromised or stolen credentials (access data) maps to #4 Identity Theft.
If attackers successfully gain access to credentials (access data), it maps to #4 Identity Theft (even if not used yet).
If company/institution names are available regarding an incident, all mentioned names must be listed in the Betroffenes Institut column.
Identify attack paths (multiple TLCTC clusters used in sequence) only if the incident description clearly indicates a sequence or chain of events. Use '->' notation (e.g., #9 -> #7). Do not invent paths if the description doesn't support it.
[TABLE OUTPUT FORMAT EXAMPLE (for Part 1)]

Nummer Region Betroffenes Institut Kurzbeschreibung des Vorfalls TLCTC Mapping
1 ROW Oracle Datenleck bei Oracle Cloud, 6 Mio. Datensätze exfiltriert. #1, #4
2 CH Gemeinde Gondiswil Cyberangriff führte zur Nichtverfügbarkeit von ICT-Systemen. #7 (Implied Ransomware)
3 ROW Synnovis, London Hospitals Ransomware-Angriff auf Dienstleister Synnovis beeinträchtigte Spitäler. #10 -> #7

Export to Sheets
[JSON OUTPUT EXAMPLE STRUCTURE (for Part 3)]

JSON

{
  "sectors": [
    {
      "id": "sector_CH",
      "name": "CH",
      "color": "blue",
      "backgroundColor": "rgba(0,0,255,0.1)",
      "activeThreats": { "1": true, "2": true, "3": true, "4": true, "5": true, "6": true, "7": true, "8": true, "9": true, "10": true },
      "values": {
        "1": 0, "2": 25, "3": 0, "4": 60, "5": 0, "6": 10, "7": 75, "8": 0, "9": 40, "10": 15
      },
      "oldValues": {
        "1": 0, "2": 5, "3": 0, "4": 20, "5": 0, "6": 0, "7": 70, "8": 0, "9": 20, "10": 5
      },
      "zoneLimits": {
        "1": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "2": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "3": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "4": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "5": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "6": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "7": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "8": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "9": {"latent": 0, "low": 5, "medium": 35, "high": 100},
        "10": {"latent": 0, "low": 5, "medium": 35, "high": 100}
      },
      "toBeReported": {
        "1": false, "2": false, "3": false, "4": true, "5": false, "6": false, "7": false, "8": false, "9": false, "10": false
      },
      "riskToleranceCrashed": {
        "1": false, "2": false, "3": false, "4": false, "5": false, "6": false, "7": false, "8": false, "9": false, "10": false
      }
    },
    {
      "id": "sector_ROW",
      "name": "ROW",
      "color": "green",
      "backgroundColor": "rgba(0,128,0,0.1)",
      "activeThreats": { "1": true, "2": true, "3": true, "4": true, "5": true, "6": true, "7": true, "8": true, "9": true, "10": true },
      "values": { /* ... similar data for ROW ... */ },
      "oldValues": { /* ... similar data for ROW ... */ },
      "zoneLimits": { /* ... similar data for ROW ... */ },
      "toBeReported": { /* ... similar data for ROW ... */ },
      "riskToleranceCrashed": { /* ... similar data for ROW ... */ }
    }
  ]
}