Inicio/Guías prácticas/Ciberseguridad

Ciberseguridad

Build a practical cybersecurity baseline

How do you build a useful cyber defence? Connect protected assets, access paths, detection signals and actual restoration capability. This guide provides six checks to turn an inventory into an action plan. The expected output is a dated register covering the asset, exposure, business consequence, control, evidence, owner and next check. Examples describe working protocols, not completed audit results.

CVECERTZero Trust
Sala nocturna de operaciones de inteligencia cibernética, sin personal
Ilustración editorial generada con IA

Lista de acciones

  1. 01

    Map what needs protection

    Inventory accounts, devices, applications, data and external dependencies. Assign an owner to each asset and identify the services whose disruption would matter most. Distinguish a discovered asset from an attributed asset: a domain resembling your brand does not prove you administer it. Record each service’s owner, environment, data and business dependency. Retain the discovery date and method so the inventory can be reproduced.

  2. 02

    Protect identities

    Enable phishing-resistant authentication where available, separate administrator accounts and remove unnecessary access. Test account recovery before a device is lost. Include service accounts, API tokens and support recovery procedures. Strong authentication loses value if uncontrolled recovery bypasses it. Evidence should combine a login test, rejection of prohibited access and supervised account recovery.

  3. 03

    Prioritise remediation

    Combine Internet exposure, asset criticality and evidence of active exploitation. Alert catalogues and CISA KEV help prioritise; a CVSS score alone does not describe your risk. CVSS describes technical severity; EPSS estimates exploitation probability within its own model. Neither replaces an assessment of local exposure. Document why each item is prioritised and verify remediation on the service people actually use.

  4. 04

    Prove you can restore

    Keep isolated, monitored backups. Restore a representative service in a controlled environment, measure the actual recovery time and document what is missing. A successful backup job does not demonstrate that a service can restart. Check key access, dependencies, restored data integrity and a business journey. Separate technical restoration duration from the total time needed to resume the service.

  5. 05

    Make events observable

    Centralise useful logs, synchronise clocks and test an alert end to end. Define who receives a signal, who decides and how long evidence should be retained for your context. Trigger an authorised test event, follow it through collection and verify that someone can make a decision. Record blind spots: missing sources, clock drift, ownerless alerts or retention too short for investigation.

  6. 06

    Rehearse response

    Prepare contacts, containment decisions and alternative communications. Run a tabletop exercise, preserve evidence and check local obligations with the relevant authorities. Choose a bounded scenario, such as suspected email account compromise. Rehearse who approves containment, preserves evidence and confirms recovery. Close an action only after checking its outcome.

    Worked example: an Internet gateway has a reported vulnerability, but its installed version and enabled component are unknown. Check both with the administrator first. If affected, record exposure reduction, remediation and a working-service retest. An absence of log alerts cannot establish an absence of compromise when collection did not cover the relevant period.

Referencias: datos, usos y límites

Documentación consultada el .

Las notas detalladas de esta edición están disponibles en inglés.

Vulnerability: three complementary viewsCVE · Identify. CVSS · Technical severity. EPSS · Probability. KEV · Known exploitation. Affected version and product. Score from 0.0 to 10.0. 30-day horizon. Official CISA catalogue. Local decision: exposure, impact, evidence and remediation checks.Vulnerability: three complementary viewsCVE · IdentifyAffected version and productCVSS · Technical severityScore from 0.0 to 10.0EPSS · Probability30-day horizonKEV · Known exploitationOfficial CISA catalogueLocal decision: exposure, impact, evidence and remediation checks
Vulnerability: three complementary views
Referencias: datos, usos y límites
Fuente y finalidadDato o referencia verificadaCómo utilizarlaLímite que debe conservarse
FIRST · CVSS

Describe technical vulnerability severity using an explicit method and vector.

CVSS 4.0 scores run from 0.0 to 10.0. Base, Threat, Environmental and Supplemental metric groups serve different purposes. Retain the score version, vector and date. Compare it with the installed version, access paths and business consequences before ordering remediation.

Profundizar en el método →

A high score is not evidence of exploitation; a low score does not mean a service has no risk.
FIRST · EPSS

Estimate exploitation probability for a published CVE.

The model looks ahead 30 days. Its score is a probability; its percentile ranks that score relative to other CVEs. Record the data date and distinguish probability from percentile. Add asset exposure and confirmed exploitation evidence.

Profundizar en el método →

The model does not predict harm to your organisation. Low probability does not cancel a critical exposure.
CISA · Known Exploited Vulnerabilities

Identify vulnerabilities listed by CISA as known to be exploited.

The catalogue includes CVE, product, date added and required action. Its official repository also provides the data schema. Check applicability to your products and retain the access date. Review the requested action and vendor advisory before confirming remediation.

Profundizar en el método →

Absence from the catalogue does not establish safety. Administrative deadlines in it are not automatically binding on every organisation.
CVE Program

Link discussions to the same vulnerability record.

A JSON schema defines the CVE record format. An identifier and the published contents of its record are distinct things. Open the record and references; check its state, described affected versions and supplier information. Keep the identifier in action tracking.

Profundizar en el método →

A CVE identifier is neither a severity score nor proof that your installation is affected.

Identidad: factores, sesiones y recuperación

Las notas detalladas de esta edición están disponibles en inglés.

Identity protection continues after sign-in

A phishing-resistant factor alone does not address new-authenticator binding, recovery or existing sessions. Describe these paths for accounts controlling critical services.

  • Separate user presence (UP) and user verification (UV) evidence.
  • Document syncable methods and their recovery account.
  • Test loss, revocation and existing sessions with observable outcomes.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

Incidentes cibernéticos: decisiones y pruebas

Las notas detalladas de esta edición están disponibles en inglés.

Prepare the decisions connecting response and recovery

Response capability is tested through the connection between signal, authority, evidence and usable service.

  • Link provisional triage to facts and a planned reassessment.
  • Exercise recovery initiation and the two integrity checks, before and after restoration.
  • Retain closure criteria, decision maker and residual actions.

Explore NIST outcomes and the timeline →

References reviewed · NIST SP 800-61r3 · pp. 27–29, 34–35 · CSF 2.0 · Appendix A

security.txt y divulgación

Las notas detalladas de esta edición están disponibles en inglés.

Check that an external report reaches a team

Cyber exposure also includes the ability to receive a useful report. A security.txt file can make the contact discoverable, but its presence alone establishes neither channel availability nor case follow-through.

  • Check /.well-known/security.txt, HTTPS, Contact fields and exactly one Expires.
  • Preserve the exact host, redirects and policy link; do not extend scope to subdomains by default.
  • Assign a publication owner and a report handler; distinguish receipt, assessment and remediation.

Read the security.txt reference and disclosure cases →

Sources checked on · IETF · RFC 9116 · §2.5, §3, §5

CVSS, EPSS, KEV y VEX

Las notas detalladas de esta edición están disponibles en inglés.

Preserve the facts justifying remediation order

An exposure review is more useful when each vulnerability connects to an instance and decision. Keep generic scores identifiable and dated, then relate them to the exposed service.

  • Separate CVSS severity, EPSS probability, KEV listing and VEX applicability assertions.
  • Establish product, version, access paths and owner before declaring local exposure.
  • Record decision, interim control and verification evidence; an available patch is not a deployed fix.

Read the CVSS, EPSS, KEV and VEX reference →

Sources checked on · FIRST · CVSS 4.0 Specification · FIRST · EPSS Frequently Asked Questions · CISA · KEV official data schema · OpenVEX · Specification v0.2.0

Cronologías: UTC y zonas horarias

Las notas detalladas de esta edición están disponibles en inglés.

Reconcile logs without inventing their order

A later-received record can describe earlier activity. Clock changes and collection retries add ambiguity; sorting local strings does not produce a reliable incident timeline.

  • Reconcile UTC instants while retaining received representations.
  • Test repeated time, missing time and inconsistent offsets.
  • Isolate conflicting identifiers and preserve every dated analysis snapshot.

Read the 12 cases and three dated snapshots →

Sources reviewed on · IETF · RFC 3339 · Python · PEP 495 · Python 3.12 · zoneinfo · IANA · Time Zone Database 2026e · IANA · 2026e Europe rules · OpenTelemetry · Logs Data Model

Archivos: cuarentena y retirada

Las notas detalladas de esta edición están disponibles en inglés.

Include late tasks in file acceptance tests

Acceptance tests should trigger withdrawal or replacement while analysis is running. Expected behavior concerns final state and actual access, beyond the task’s own success status.

  • Test failure, incomplete checks and retry.
  • Change version or policy during a task and verify rejection.
  • Withdraw access before a derivative returns, then replay permitted and forbidden reads.

View the three journeys and late task results →

Sources reviewed on · OWASP · File Upload Cheat Sheet · OWASP · Authorization Cheat Sheet · WHATWG · HTML input accept · PostgreSQL 18 · Transaction isolation