Saltar al contenido
Axón Digital

Ejemplo con datos ficticios. La empresa, el RUT y los hallazgos están inventados para mostrar cómo es un informe real. No corresponde a ningún cliente.

// informe de revisión de seguridad

Informe de seguridad: Distribuidora Ejemplo SpA

Empresa
Distribuidora Ejemplo SpA (ficticia)
RUT
00.000.000-0
Fecha
15 de marzo de 2027
Preparado por
Equipo de Axón Digital

Resumen para la gerencia

58

de 100

La empresa tiene bases sólidas: el sitio usa HTTPS con renovación automática y el sistema se actualiza solo. Pero el correo del dominio puede ser suplantado con facilidad y faltan protecciones que se corrigen rápido. Con el plan de 30 días de este informe, la nota esperada sube de 58 a más de 85.

  • 1 hallazgo de severidad alta
  • 3 hallazgos de severidad media
  • 3 hallazgos de severidad baja

Qué se revisó

  • Sitio web www.ejemplo.cl (solo lo visible desde internet).
  • Protección del correo del dominio ejemplo.cl.
  • Orden de las cuentas y copias de seguridad, por entrevista con la persona a cargo.

Qué no se hizo

  • Pruebas que interrumpan el servicio.
  • Acceso a bases de datos o a información de clientes.
  • Sistemas de terceros.

Lo que ya está bien

  • El sitio usa HTTPS con un certificado válido que se renueva solo.
  • El sistema del sitio y sus complementos se actualizan automáticamente.
  • Cada persona accede solo a lo que necesita para su cargo.
  • Existe una copia de seguridad diaria, almacenada fuera del servidor.

Hallazgos

  1. H-01Severidad altaEsfuerzo estimado: 2 horas

    Cualquiera puede enviar correos como si fueran de la empresa

    Qué encontramos
    El dominio no tiene registro DMARC y su SPF permite enviar desde cualquier servidor (+all).
    Por qué importa
    Un estafador puede escribir a clientes y proveedores como «[email protected]» y pedir pagos a otra cuenta. No necesita entrar a ninguna cuenta de la empresa.
    Cómo corregirlo
    Reemplazar el SPF por uno que liste solo los servidores reales, activar la firma DKIM y publicar DMARC en modo de observación, para endurecerlo en unas semanas.
  2. H-02Severidad mediaEsfuerzo estimado: 1 hora

    La administración del sitio no tiene doble verificación

    Qué encontramos
    Según lo informado por la empresa, las tres cuentas administradoras entran solo con contraseña.
    Por qué importa
    Si una contraseña se filtra o se adivina, el atacante controla el sitio completo.
    Cómo corregirlo
    Activar la verificación en dos pasos en las tres cuentas y revisar quién necesita realmente ser administrador.
  3. H-03Severidad mediaEsfuerzo estimado: 3 horas

    La copia de seguridad nunca se ha probado

    Qué encontramos
    Hay copias diarias, pero nadie ha restaurado una para comprobar que funciona.
    Por qué importa
    Una copia que no se puede restaurar no sirve el día del problema, por ejemplo tras un ataque de secuestro de datos.
    Cómo corregirlo
    Restaurar una copia en un entorno de prueba, medir cuánto tarda y dejar el procedimiento por escrito. Repetirlo cada seis meses.
  4. H-04Severidad mediaEsfuerzo estimado: 3 horas

    El sitio no limita qué código puede ejecutar el navegador

    Qué encontramos
    No hay política de contenido (CSP) ni HSTS en las cabeceras del sitio.
    Por qué importa
    Si alguien logra inyectar código en una página, el navegador no lo frena. Sin HSTS, en una red pública se puede forzar la versión sin cifrar.
    Cómo corregirlo
    Agregar las cabeceras de seguridad en la configuración del servidor, empezando por una política de contenido permisiva y ajustándola.
  5. H-05Severidad bajaEsfuerzo estimado: 4 horas

    El formulario de contacto no informa cómo se tratan los datos

    Qué encontramos
    Pide nombre, correo y teléfono, pero no muestra aviso de privacidad junto al formulario ni guarda constancia del consentimiento.
    Por qué importa
    La Ley 21.719 exige informar al momento de recolectar los datos y poder demostrar que la persona aceptó.
    Cómo corregirlo
    Publicar la política de privacidad, agregar un aviso corto junto al formulario y registrar cuándo y qué aceptó cada persona.
  6. H-06Severidad bajaEsfuerzo estimado: 1 hora

    El sitio muestra qué programas y versiones usa

    Qué encontramos
    Las respuestas del servidor indican «PHP/7.4» y la versión del servidor web.
    Por qué importa
    Quien busca fallas conocidas sabe exactamente cuáles probar.
    Cómo corregirlo
    Ocultar esas cabeceras y actualizar PHP a una versión con soporte.
  7. H-07Severidad bajaEsfuerzo estimado: 15 minutos

    No hay un canal para avisar de una falla

    Qué encontramos
    El sitio no publica el archivo security.txt.
    Por qué importa
    Si un investigador encuentra una falla, no sabe a quién avisar y probablemente no lo haga.
    Cómo corregirlo
    Publicar security.txt con un correo de contacto.

Plan de acción a 30 días

  1. Semana 1

    • H-01: proteger el correo del dominio (SPF, DKIM y DMARC).
    • H-02: activar la doble verificación en las cuentas administradoras.

  2. Semana 2

    • H-03: probar una restauración completa de la copia de seguridad.
    • H-04: agregar las cabeceras de seguridad al sitio.

  3. Semanas 3 y 4

    • H-05: aviso de privacidad y registro del consentimiento.
    • H-06 y H-07: ocultar versiones y publicar security.txt.
    • Volver a revisar el sitio y comparar con este informe.

Alcance y límites de este informe

  • Este informe refleja el estado de lo revisado en la fecha indicada. Ningún análisis garantiza que un sistema sea completamente seguro.
  • Solo se evaluó lo que la empresa autorizó por escrito, dentro del alcance y de la ventana de tiempo acordados, conforme a la Ley 21.459.
  • No se descargó ni se usó información de terceros, ni se probaron fallas que pudieran interrumpir el servicio.

// siguiente paso

¿Quieres un informe así para tu empresa?

Empieza con una reunión gratuita de 30 minutos. Te explicamos qué revisaríamos en tu caso y cuánto demoraría. También puedes probar la revisión gratuita de tu página web.

Agenda una reunión gratis