01
What RegistroCiberVE is
RegistroCiberVE is a public, bilingual registry of cybersecurity incidents affecting organizations, services, platforms, systems, data, and people linked to Venezuela. It brings dispersed information into a searchable structure with sources, dates, victims, actors, impacts, and confidence levels.
The project prioritizes traceability and correction. Each record should be reviewable, citable, and correctable when stronger evidence appears.
02
Summary
RegistroCiberVE uses the term cybersecurity incident for occurrences that compromise or threaten the confidentiality, integrity, or availability of systems or data, or that violate security policies. This definition follows National Institute of Standards and Technology (NIST) terminology and lets the registry document facts without presuming intent or authorship (National Institute of Standards and Technology, n.d.-a, n.d.-b).
RegistroCiberVE has a documentary function. It is outside the role of a Computer Security Incident Response Team (CSIRT), national authority, or official reporting channel. It collects public sources, separates facts from inferences, and preserves the confidence level attached to each data point.
03
Record unit
The primary unit is the incident. A cyberattack is recorded when the evidence supports a hostile action. Leaks, exposures, account compromises, service interruptions, and data publications are also recorded when they affect systems, data, people, or organizations linked to Venezuela.
Using incident avoids asserting intent, technical success, or authorship when public evidence does not support it. Attribution is stored separately in the incident-actor relationship. That relationship keeps the actor role, confidence level, attribution basis, and claim source when one exists.
04
Taxonomy and vector
The primary classification uses a category and subcategory structure inspired by the European Union Agency for Cybersecurity (ENISA), the Task Force Computer Security Incident Response Teams (TF-CSIRT) community, and the Reference Security Incident Taxonomy (RSIT). That framework helps organize cases by incident family, not only by common attack name (European Union Agency for Cybersecurity, n.d.).
The vector describes how the incident began or was observed. This field uses categories compatible with the Cybersecurity and Infrastructure Security Agency (CISA) and NIST, such as web, email or phishing, attrition or brute force, removable media, improper usage, impersonation, or unknown. When the source does not support an entry point, the vector remains unknown (Cybersecurity and Infrastructure Security Agency, n.d., 2017; Nelson et al., 2025).
05
Impact and severity
Impact is recorded by dimension. The schema distinguishes confidentiality, integrity, availability, data, people, systems, money, and service availability. It also keeps counts, exposed data types, file types, affected systems, Common Vulnerabilities and Exposures (CVE) identifiers, and an impact description when the source supports one. This separation prevents a general label from hiding the actual effect of the incident (Agrafiotis et al., 2018).
Severity is recorded as a composite assessment. It considers functional impact, information impact, recoverability, affected scope, critical service impact, and public confidence. The model borrows criteria from CISA, the National Cyber Incident Scoring System (NCISS), and NIST Special Publication (SP) 800-61, but it does not issue an official national risk score (Cybersecurity and Infrastructure Security Agency, n.d., 2017; Nelson et al., 2025).
06
Victims and actors
The victim is classified by kind, criticality, public service status, and role in the incident. This makes it possible to distinguish a directly affected organization, a data subject group, a platform used as infrastructure, or users affected indirectly.
NIST Cybersecurity Framework (CSF) 2.0 is used as supporting language to connect classification with risk management, recovery, communication, and service-impact outcomes. In this registry, it helps separate operational impact, scope, and public confidence; the victim definition remains in the model fields (Pascoe et al., 2024).
The actor is treated as a documented hypothesis. Actor type, form, motivation, attribution confidence, attribution basis, and claim source are stored separately. An actor claim remains a claim. A technical assessment, a victim statement, and a media report keep different evidentiary weight.
07
Evidence and traceability
Each source keeps its category, purpose, confidence level, and supported claims. A source may be primary, corroborating, contextual, attribution-related, impact-related, timeline-related, or contradictory. This prevents contextual material from being treated as primary proof and allows uncertainty, relevance, and conflicting evidence to be recorded.
The Forum of Incident Response and Security Teams (FIRST) and International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27035 are used as process guides. FIRST helps structure intake, triage, coordination, and related services. ISO/IEC 27035 contributes the cycle of preparing, detecting, reporting, assessing, responding, and learning from incidents (Forum of Incident Response and Security Teams, n.d.; International Organization for Standardization & International Electrotechnical Commission, 2023).
08
Corrections and reports
If someone finds an error about an incident, a victim, or an attacker, they can use the Report issue form on the corresponding record page. The form lets them explain what should be reviewed and add a source supporting the correction.
Reports are reviewed before the database is changed. This keeps the change traceable and avoids replacing one data point with an unsupported claim.
09
Application to the data model
The table summarizes how the methodology is translated into searchable fields. The current schema complements the incident with separate tables for classifications, vectors, impacts, severity, sources, verification, victims, and actors. This separation lets one dimension be corrected without changing the others.
| Dimension | Applied criterion | References |
|---|---|---|
| Identification | Title and description identify what happened. Category, subcategory, vector, and impact are documented as separate dimensions so observable facts are not mixed with analytical assessment. | NIST SP 800-61 |
| Dates and chronology | Public report date, actor claim date, primary chronology date, and ordered events separate discovery, compromise, exfiltration, publication, claim, disclosure, remediation, and updates. | ISO/IEC 27035; NIST SP 800-61 |
| Classification | Category, subcategory, taxonomy, version, source, and rationale live in their own table. Only one classification is marked primary. | ENISA/TF-CSIRT RSIT |
| Vector | The vector records the observed or inferred entry point. Detail, confidence, and source are stored to avoid confusing entry method with impact. | CISA NCISS; NIST SP 800-61 |
| Impact and severity | Impact dimensions, exposed data, affected systems, CVE identifiers, scope, recoverability, and public confidence are recorded as separate fields. | CISA NCISS; NIST SP 800-61; Agrafiotis et al. |
| Victim | Victim kind, criticality, public service status, and role are stored separately to distinguish the affected subject, infrastructure, and data subject group. | NIST CSF 2.0; CISA NCISS |
| Actor | Actor type, form, motivation, confidence, attribution basis, and claim source are stored as distinct fields. | CISA NCISS; NIST SP 800-61 |
| Evidence | Each source keeps purpose, category, confidence level, and the claims it supports. | ISO/IEC 27035; FIRST CSIRT Services Framework |
| Verification | Verification notes record whether an official statement exists, the strongest source, missing evidence, conflicting evidence, and analyst notes. | ISO/IEC 27035; FIRST CSIRT Services Framework |
10
Category guide
These categories correspond to the primary classification field. They describe the incident family. Subcategory, vector, impact, and severity are recorded separately to distinguish cause, technique, and consequence.
| Category | Meaning |
|---|---|
| Abusive content | Cases where the main harm lies in content that was published or distributed, such as spam, harassment, public extortion, or harmful material. |
| Malicious code | Incidents where malware, ransomware, trojans, malicious scripts, or other harmful code are the central mechanism. |
| Information gathering | Reconnaissance, enumeration, scanning, or prior data collection when documented as part of the incident. |
| Intrusion attempts | Actions intended to gain unauthorized access when intrusion is not confirmed or only attempted activity is observed. |
| Intrusions | Confirmed unauthorized access, account compromise, successful exploitation, or presence inside a system. |
| Availability | Service interruptions or degradation, including denial of service, website outages, or operational disruption. |
| Information content security | Unauthorized exposure, leakage, modification, deletion, or publication of information. |
| Fraud | Impersonation, deception, identity abuse, scams, or fraudulent use of systems and accounts. |
| Vulnerable | Exposed systems or relevant vulnerabilities when the record documents risk or exposure, not necessarily confirmed exploitation. |
| Other or undetermined | Verifiable cases that do not fit the previous categories or where evidence does not support a more precise classification. |
11
Scope and limits
- The registry uses public sources. When evidence is insufficient, the field remains unknown or low confidence.
- Severity expresses a documentary assessment by the registry, distinct from an official emergency declaration or national risk rating.
- Attribution remains separate from the incident. An actor claim, a victim statement, and a technical assessment carry different evidentiary weight.
12
References
Sources used for the definition and methodological structure (APA, 7th edition).
- Agrafiotis, I., Nurse, J. R. C., Goldsmith, M., Creese, S., & Upton, D. (2018). A taxonomy of cyber-harms: Defining the impacts of cyber-attacks and understanding how they propagate. Journal of Cybersecurity, 4(1), tyy006. https://doi.org/10.1093/cybsec/tyy006
- Cybersecurity and Infrastructure Security Agency. (n.d.). CISA National Cyber Incident Scoring System (NCISS). Retrieved July 8, 2026, from https://www.cisa.gov/news-events/news/cisa-national-cyber-incident-scoring-system-nciss
- Cybersecurity and Infrastructure Security Agency. (2017). Federal Incident Notification Guidelines. https://www.cisa.gov/federal-incident-notification-guidelines
- European Union Agency for Cybersecurity. (n.d.). Reference Security Incident Taxonomy. GitHub. Retrieved July 8, 2026, from https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force
- Forum of Incident Response and Security Teams. (n.d.). Computer Security Incident Response Team (CSIRT) Services Framework, version 2.1. Retrieved July 8, 2026, from https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1
- International Organization for Standardization & International Electrotechnical Commission. (2023). ISO/IEC 27035-1:2023 Information technology, Information security incident management, Part 1: Principles and process. https://www.iso.org/standard/78973.html
- Pascoe, C., Quinn, S., & Scarfone, K. (2024). The NIST Cybersecurity Framework (CSF) 2.0. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.29
- Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r3
- National Institute of Standards and Technology. (n.d.-a). Cyber incident. In Computer Security Resource Center glossary. Retrieved July 8, 2026, from https://csrc.nist.gov/glossary/term/cyber_incident
- National Institute of Standards and Technology. (n.d.-b). Incident. In Computer Security Resource Center glossary. Retrieved July 8, 2026, from https://csrc.nist.gov/glossary/term/incident
13
Authorship
Prepared by Kevin Bravo
Product engineer with 5 years of experience and student in the Master in Public Management at Instituto de Estudios Superiores de Administración (IESA).