¿CUÁLES SON REALMENTE LOS PRINCIPALES RIESGOS TECNOLÓGICOS DE NUESTRA EMPRESA?
Toda organización convive con riesgos tecnológicos.
El problema no es únicamente identificarlos, sino determinar cuáles pueden tener un mayor impacto sobre la actividad y cuáles deberían abordarse primero.
Vulnerabilidades, configuraciones, dependencias, obsolescencia, accesos, ausencia de redundancia o procedimientos no validados pueden representar riesgos muy diferentes según el entorno.
Por eso, conocer los principales riesgos tecnológicos de una empresa requiere analizar su infraestructura, entender sus dependencias y establecer prioridades basadas en información real.
NO TODOS LOS RIESGOS TIENEN LA MISMA IMPORTANCIA
Una infraestructura puede presentar decenas de aspectos susceptibles de mejora.
Sin embargo, intentar abordarlos todos simultáneamente no suele ser realista ni necesariamente eficiente.
Una vulnerabilidad crítica en un sistema aislado puede representar un riesgo menor que una configuración aparentemente menos grave en un servicio imprescindible para la organización.
Del mismo modo, un equipo antiguo no constituye automáticamente el principal riesgo si existen medidas que reducen su exposición y su impacto.
Por eso, identificar un problema es solo una parte del análisis.
Debemos valorar qué puede ocurrir, qué elementos pueden verse afectados y qué consecuencias tendría para la organización.
IDENTIFICAR UN PROBLEMA NO ES LO MISMO QUE DETERMINAR SU RIESGO
¿DE DÓNDE PUEDEN PROCEDER LOS RIESGOS?
Los riesgos tecnológicos no proceden exclusivamente de ataques externos.
También pueden originarse en la propia arquitectura, configuraciones, accesos, procesos operativos o dependencias que se han ido acumulando con el tiempo.
INFRAESTRUCTURA
• Obsolescencia
• Capacidad
• Puntos únicos de fallo
CONFIGURACIÓN
• Errores
• Excepciones
• Parámetros inadecuados
SEGURIDAD
• Vulnerabilidades
• Exposición
• Protección insuficiente
IDENTIDAD
• Privilegios
• Credenciales
• Accesos innecesarios
OPERACIÓN
• Procedimientos
• Dependencias
• Falta de validación
EL RIESGO TECNOLÓGICO NO DEPENDE DE UN ÚNICO ELEMENTO DE LA INFRAESTRUCTURA
RIESGO NO ES LO MISMO QUE VULNERABILIDAD
Una vulnerabilidad representa una debilidad que podría ser aprovechada o provocar una exposición.
El riesgo requiere además analizar la probabilidad o posibilidad de que se materialice y las consecuencias que tendría para la organización.
Por eso, una lista de vulnerabilidades no constituye por sí sola una priorización de riesgos.
Para decidir dónde actuar necesitamos incorporar contexto.
DEBILIDAD
¿Qué problema hemos identificado?
Vulnerabilidad, configuración, dependencia, obsolescencia, ausencia de control…
EXPOSICIÓN
¿En qué circunstancias puede materializarse?
Accesibilidad, usuarios afectados, controles existentes, dependencias…
VIGENCIA
¿Qué ocurriría si sucede?
Interrupción, pérdida de información, compromiso, impacto económico u operativo…
EL CONTEXTO ES LO QUE CONVIERTE UN HALLAZGO TÉCNICO EN UNA DECISIÓN DE RIESGO
EL IMPACTO DEBE ANALIZARSE DESDE EL NEGOCIO
Una infraestructura IT existe para soportar la actividad de la organización.
Por eso, la criticidad técnica de un elemento no siempre coincide con su importancia para el negocio.
Una incidencia puede afectar a un único sistema y detener un proceso crítico, mientras que otra puede afectar a numerosos dispositivos sin impedir que la organización continúe trabajando.
Para establecer prioridades debemos entender qué servicios soporta cada elemento y qué ocurriría si dejara de estar disponible, fuera comprometido o perdiera información.
DISPONIBILIDAD
¿Podemos seguir operando?
INFORMACIÓN
¿Podemos perder o comprometer datos?
OPERACIÓN
¿Qué procesos quedarían afectados?
IMPACTO
¿Qué consecuencias tendría para la organización?
LA CRITICIDAD DE LA TECNOLOGÍA DEPENDE DE LA ACTIVIDAD QUE SOPORTA
LAS DEPENDENCIAS PUEDEN OCULTAR EL RIESGO REAL
Un servicio raramente depende de un único elemento.
Puede necesitar servidores, almacenamiento, red, DNS, identidad, certificados, comunicaciones, aplicaciones, servicios Cloud o proveedores externos.
Analizar únicamente el componente visible puede hacer que pasemos por alto el elemento que realmente condiciona la disponibilidad del servicio.
USUARIO → APLICACIÓN → IDENTIDAD → RED → SISTEMA → DATOS → SERVICIO
Una dependencia aparentemente secundaria puede convertirse en un punto crítico cuando varios servicios necesitan de ella simultáneamente.
PARA ENTENDER EL RIESGO DE UN SERVICIO DEBEMOS CONOCER TODO AQUELLO DE LO QUE DEPENDE
LOS CONTROLES EXISTENTES TAMBIÉN FORMAN PARTE DEL ANÁLISIS
Detectar una debilidad no significa que la organización esté completamente expuesta a ella.
Pueden existir diferentes medidas que reduzcan la probabilidad de que ocurra una incidencia o limiten sus consecuencias.
Segmentación, MFA, EDR, backup, redundancia, monitorización, filtrado, procedimientos o restricciones de acceso pueden modificar significativamente el riesgo real.
Por tanto, no deberíamos preguntarnos únicamente:
«¿Existe esta vulnerabilidad?»
También:
«¿Qué mecanismos tenemos para prevenirla, detectarla, contenerla o recuperarnos si se materializa?»
PREVENIR
Reducir la posibilidad de que ocurra.
DETECTAR
Identificar rápidamente una anomalía.
RESPONDER
Limitar su alcance e impacto.
RECUPERAR
Restablecer la operación.
EL RIESGO DEBE ANALIZARSE TENIENDO EN CUENTA LAS MEDIDAS QUE YA EXISTEN
PRIORIDAD NO SIGNIFICA NECESARIAMENTE GRAVEDAD TÉCNICA
Una organización dispone de recursos, tiempo y presupuesto limitados.
Por ello, después de identificar los riesgos necesitamos decidir qué debemos abordar primero.
La prioridad puede depender de diferentes factores:
IMPACTO
¿Qué consecuencias tendría?
EXPOSICIÓN
¿En qué medida estamos expuestos?
PROBABILIDAD
¿Con qué facilidad podría materializarse?
CONTROLES
¿Qué medidas reducen actualmente el riesgo?
ESFUERZO
¿Qué necesitamos para corregirlo o mitigarlo?
Una acción relativamente sencilla puede reducir significativamente un riesgo importante, mientras que otras mejoras pueden requerir proyectos de mayor alcance.
PRIORIZAR SIGNIFICA DECIDIR DÓNDE UNA ACTUACIÓN PUEDE REDUCIR MÁS RIESGO
UNA FOTOGRAFÍA DEL RIESGO TAMBIÉN CADUCA
Las infraestructuras evolucionan.
Aparecen nuevos sistemas, usuarios, aplicaciones, sedes, servicios Cloud, proveedores, vulnerabilidades y formas de trabajar.
También cambian las amenazas y las necesidades del negocio.
Por eso, una evaluación realizada en un momento determinado describe una situación concreta, pero no garantiza que esa misma fotografía continúe siendo válida meses después.
El análisis debería repetirse periódicamente y especialmente cuando se producen cambios significativos en la infraestructura.
SI CAMBIA LA INFRAESTRUCTURA, TAMBIÉN PUEDE CAMBIAR EL RIESGO
SEÑALES DE QUE NECESITAMOS REVISAR NUESTROS RIESGOS TECNOLÓGICOS
VISIBILIDAD
• No existe un inventario actualizado
• Se desconoce qué sistemas soportan cada servicio
• Existen dependencias que no están documentadas
• No tenemos una visión global del entorno
PRIORIDAD
• Las mejoras se realizan principalmente cuando aparece una incidencia
• Todas las vulnerabilidades parecen tener la misma urgencia
• Las decisiones dependen más de percepciones que de información
• No existe un criterio común para priorizar actuaciones
EVOLUCIÓN
• La infraestructura ha cambiado significativamente
• Se han incorporado nuevos servicios sin revisar riesgos anteriores
• Existen medidas implantadas hace años que no se han reevaluado
• No podemos afirmar si nuestra situación ha mejorado o empeorado
«NO TENER INCIDENCIAS» NO SIGNIFICA NECESARIAMENTE «TENER LOS RIESGOS CONTROLADOS»
DEL DIAGNÓSTICO A LA ACCIÓN
Identificar riesgos únicamente aporta valor si esa información permite tomar decisiones.
El objetivo de una evaluación no debería ser generar una larga lista de hallazgos, sino obtener una visión suficientemente clara para determinar qué debemos corregir, qué debemos mejorar y qué debemos abordar primero.
En ORION Technology abordamos el diagnóstico de la infraestructura desde una perspectiva global, analizando conectividad, estabilidad y seguridad para identificar riesgos, establecer prioridades y definir acciones de mejora.
Nuestra metodología contempla 443 puntos de evaluación, pero el objetivo no es obtener 443 respuestas.
El objetivo es transformar la información obtenida en una visión comprensible de la situación y en prioridades sobre las que poder actuar.
DIAGNOSTICAR → PRIORIZAR → ACTUAR → REVISAR → MEDIR EVOLUCIÓN
Conoce nuestro enfoque de Consultoría y Diagnóstico IT →
El resultado de una evaluación debería permitir responder una pregunta mucho más sencilla:
¿CUÁLES SON AHORA LOS PRINCIPALES RIESGOS TECNOLÓGICOS DE NUESTRA ORGANIZACIÓN Y QUÉ VAMOS A HACER CON ELLOS?
CONOCER EL RIESGO ES EL PRIMER PASO PARA REDUCIRLO
No existe una lista universal de cinco riesgos que pueda aplicarse de la misma manera a todas las organizaciones.
Cada infraestructura tiene una arquitectura, unas dependencias, unas necesidades y una realidad operativa diferente.
Conocer esa realidad permite dejar de trabajar únicamente de forma reactiva y establecer una evolución basada en prioridades.
El objetivo no es eliminar absolutamente todos los riesgos.
Es conocerlos, entender su impacto y tomar decisiones conscientes sobre cuáles debemos reducir primero.