Saltar al contenido
MSSPRD

Marco de seguridad adoptado por MSSPRD

Última actualización: 2026-09-21 Alcance: MSSPRD, Proveedor de Servicios Gestionados de Tecnología, Ciberseguridad y Soporte, SRL como organización: su práctica de desarrollo de software y la protección de su infraestructura federada.

Este documento es de la organización, no de un producto. Se instancia una sola vez y los productos lo enlazan. Es público y está redactado para poder entregarse a un cliente, a su auditor o a su área de compras sin edición previa.

Declaración sobre certificaciones

MSSPRD, Proveedor de Servicios Gestionados de Tecnología, Ciberseguridad y Soporte, SRL NO declara estar certificada bajo ningún marco internacional de seguridad de la información.

Sí declara que adopta esos marcos en toda su práctica, de forma deliberada, documentada y verificable con evidencia interna.

Adoptar un marco y estar certificado en él son cosas distintas, y las mantenemos distintas a propósito. Un certificado es la opinión de un organismo acreditado tras una auditoría de tercera parte. La adopción es la decisión de operar conforme al marco y de poder demostrarlo. Nosotros hacemos lo segundo y no afirmamos lo primero.

Si en el futuro obtenemos una certificación, este documento indicará el organismo certificador, el número de certificado, el alcance exacto y la fecha de vencimiento. Sin esos cuatro datos, cualquier afirmación de certificación, nuestra o de un tercero debe considerarse no acreditada.

Decimos esto en primer lugar y no en una nota al pie porque somos una empresa de seguridad: la precisión sobre lo que uno es y no es forma parte del servicio.

1. Marcos que adoptamos

Marco Cómo lo usamos
ISO/IEC 27001:2022 Estructura de nuestro sistema de gestión de seguridad: gobierno, análisis de riesgo, declaración de aplicabilidad y ciclo de mejora
ISO/IEC 27002:2022 Catálogo de controles de referencia: seleccionamos, implementamos y evidenciamos contra sus 93 controles
ISO/IEC 27005 Metodología de apreciación y tratamiento del riesgo
NIST CSF 2.0 Lenguaje de madurez y comunicación con dirección y clientes, sobre las funciones Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar
CIS Controls v8.1 Prioridad de implementación: qué se hace primero cuando los recursos son finitos
OWASP ASVS Requisitos de verificación de seguridad de aplicaciones, por nivel
OWASP SAMM Medición de la madurez de nuestra práctica de desarrollo seguro
OWASP Top 10 / API Top 10 Riesgos de referencia en revisión de código y pruebas
MITRE ATT&CK Lenguaje común de técnicas adversarias en detección y respuesta
NIST SP 800-61 Ciclo de gestión de incidentes

Normativa aplicable, que no es marco voluntario sino obligación: Ley 172-13 (protección de datos), Decreto 230-18 (reglamento), Ley 53-07 (crímenes y delitos de alta tecnología) y Ley 126-02 (comercio electrónico y firma digital), todas de República Dominicana.

2. Cómo lo adoptamos en el desarrollo de aplicaciones

No describimos aquí buenas intenciones. Cada punto tiene una evidencia auditable, que es lo que distingue una práctica de una declaración.

2.1 Controles en la línea de entrega

Control Evidencia
Revisión de código por pares antes de fusionar Historial de pull requests con aprobación registrada
SAST: análisis estático Ejecución en cada cambio, con el resultado archivado
SCA: dependencias de terceros Auditoría de dependencias de producción que bloquea la entrega ante vulnerabilidad alta o crítica
Detección de secretos Barrido de cada cambio y del histórico; un secreto detectado bloquea la entrega
IaC scanning Análisis de la infraestructura declarada antes de aplicarla
SBOM Inventario de componentes por artefacto entregado
Pruebas automatizadas Suite ejecutada en cada cambio; la entrega no procede si falla
Ramas protegidas Fusión a la rama principal condicionada a que todos los controles pasen

2.2 Dos reglas propias, aprendidas en producción

Estas no vienen de ningún marco. Las incorporamos porque nos costaron incidentes reales, y las documentamos para que no se pierdan con la rotación de personal.

Un control que no distingue, no controla. Un gate que bloquea siempre deja de aportar información y se acaba rodeando. Nuestra auditoría de dependencias bloquea sobre las dependencias de producción, lo que se sirve al cliente, y reporta las de desarrollo sin bloquear. Un gate permanentemente en rojo no es más estricto: es ruido.

Compilar no es arrancar. Un artefacto que compila puede fallar al iniciarse. Nuestro criterio de aceptación exige arrancar el servicio y verificar su respuesta, no solo que la compilación termine sin error.

2.3 Diseño seguro

  • Fail-closed por defecto. Ante configuración ausente o inválida, el sistema se niega a operar en lugar de continuar con un valor supuesto. Un valor por defecto silencioso convierte un error de configuración en una brecha.
  • Validación por lista de permitidos, no de prohibidos. Enumerar lo malo nunca termina.
  • Rechazar lo que habría que normalizar. Si un valor de configuración debe corregirse para ser usable, es un error, no algo que arreglar en silencio.
  • Mínimo privilegio en cada componente, incluidos los procesos de la propia línea de entrega.
  • Cabeceras de seguridad y CSP estricta en toda superficie web, sin unsafe-inline.
  • Cifrado en tránsito (TLS 1.2+) y en reposo para datos sensibles; secretos y segundos factores cifrados con clave gestionada aparte.

2.4 Verificación independiente

Todo cambio atraviesa una cadena de revisión con responsabilidades separadas (diseño, implementación, ejecución de pruebas, calidad, seguridad y operación) donde cada etapa puede detener la entrega. La separación no es ceremonia: cada etapa detecta una clase de defecto distinta, y la que aprueba no es la que implementa.

3. Cómo protegemos la infraestructura federada

MSSPRD opera una arquitectura federada y soberana: nodos propios con funciones separadas, sobre infraestructura contratada a un proveedor certificado, sin delegar el tratamiento de datos de clientes en plataformas de terceros.

3.1 Principios de arquitectura

  • Soberanía del dato. Los datos de clientes residen en infraestructura bajo nuestro control. No empleamos servicios de terceros como procesadores de datos de clientes salvo excepción documentada, con base contractual y registrada en el Registro de Actividades de Tratamiento.
  • Segregación por función. Correo y colaboración, monitorización, automatización y aplicaciones de cliente residen en nodos distintos. El compromiso de uno no concede el siguiente.
  • Aislamiento por inquilino. En los servicios multi-inquilino, la separación se aplica en la capa de datos y se prueba de forma negativa: se verifica que un inquilino no pueda alcanzar los datos de otro, incluida la manipulación de identificadores.
  • Sin confianza lateral por defecto. La red no es plana.

3.2 Controles operativos

Ámbito Control
Acceso Autenticación con segundo factor en todo acceso administrativo; llaves por persona, no compartidas
Perímetro Cortafuegos con denegación por defecto; bloqueo automático de intentos de intrusión
Superficie Ningún servicio de datos expuesto directamente a Internet; acceso a través de proxy con terminación TLS
Certificados Emisión y renovación automatizadas, con vigilancia de vencimiento
Registro Registro centralizado de accesos y eventos, con reloj sincronizado y retención definida
Detección Monitorización de seguridad continua sobre la flota, con correlación y escalado
Respaldo Copias periódicas, probadas mediante restauración; una copia sin restauración ensayada es una suposición
Configuración Infraestructura declarada en repositorio con control de cambios; la deriva manual se detecta y bloquea la entrega
Vulnerabilidades Gestión con plazos por criticidad y verificación de cierre efectivo

3.3 Verificación desde fuera

Un control se verifica desde la perspectiva de quien lo atravesaría, no desde dentro del sistema que lo implementa. Comprobar un servicio desde su propio servidor no demuestra que sea alcanzable, ni que su cadena de TLS, sus cabeceras o su política de contenido funcionen para un usuario real.

Nuestros criterios de aceptación exigen comprobación externa, por nombre público y con TLS, y, donde hay interfaz, en un navegador real, porque una política de contenido mal formada no se detecta con una petición simple.

3.4 Respuesta a incidentes

Operamos sobre el ciclo de NIST SP 800-61: preparación, detección y análisis, contención, erradicación, recuperación y lecciones aprendidas. Cada incidente relevante genera un análisis posterior sin atribución de culpa, orientado a corregir la condición que lo permitió.

Cuando un incidente afecte a datos personales de un cliente y suponga un riesgo, se le notifica sin dilación indebida con la naturaleza del incidente, los datos afectados y las medidas adoptadas.

4. Personas

  • Acuerdos de confidencialidad con todo el personal y los colaboradores con acceso.
  • Formación continua y credenciales profesionales vigentes en el equipo técnico.
  • Revocación de accesos en el mismo día de la desvinculación.
  • Segregación de funciones en las operaciones críticas.

5. Terceros

Los proveedores con acceso a datos o a infraestructura se evalúan antes de su incorporación, se rigen por acuerdo contractual con obligaciones de seguridad y confidencialidad, y se registran en el Registro de Actividades de Tratamiento con el dato que reciben y su ubicación. Las transferencias fuera de República Dominicana exigen base contractual documentada.

6. Qué puede pedirnos un cliente

Bajo acuerdo de confidencialidad, y sin necesidad de justificar la petición:

  • Nuestra declaración de aplicabilidad de controles y su estado.
  • Evidencia de los controles de la línea de entrega para el producto que le prestamos.
  • El inventario de componentes (SBOM) del artefacto desplegado.
  • El resultado de la última evaluación de seguridad del servicio contratado.
  • El registro de tratamientos que le afecten.
  • Nuestro plan de respuesta a incidentes y de continuidad.

Si necesita algo que no está en esta lista, pídalo: preferimos decir que no lo tenemos a dar una respuesta ambigua.

7. Contacto