Ciberseguridad y Riesgo Tecnológico del Sector Público

Por qué esto importa para el valor público

Cuando los sistemas de un hospital son cifrados por un atacante, los clínicos no pueden ver los historiales de medicación, se desvían las ambulancias, y se cancelan las operaciones. Cuando se comprometen los sistemas de control de una empresa de agua, lo que está en juego para el valor público no es una interrupción de servidor sino la seguridad del agua potable. Cuando se vulnera la base de datos de una agencia de beneficios, las personas más expuestas a menudo son las personas menos capaces de absorber las consecuencias: un pago retrasado, una identidad robada, una familia que no puede probar quién es ante el estado que le debe apoyo. La seguridad informática, comúnmente llamada ciberseguridad, es la práctica de proteger sistemas informáticos, redes, y datos del acceso no autorizado, la interrupción, o el daño. En las instituciones públicas, esa práctica se sitúa directamente en el camino entre el estado y el ciudadano al que sirve.

Esta es la razón por la que el tema enmarca el riesgo cibernético como una pregunta de valor público, no solo una técnica. La legitimidad y el apoyo dependen de que los ciudadanos crean que se puede confiar en que las instituciones que sostienen sus datos y ejecutan sus servicios esenciales mantendrán ambos seguros (véase el Tema 1.2 — El Triángulo Estratégico: Legitimidad, Valor, y Capacidad). Una única brecha bien publicitada puede hacer daño duradero a esa confianza, de la misma forma que lo hace una emergencia mal manejada, porque los ciudadanos juzgan a las instituciones por cómo se comportan bajo ataque tanto como por cómo funcionan día a día (véase el Tema 3.12 — Gestión de Crisis, Emergencias, y Resiliencia, que trata los incidentes cibernéticos como una categoría dentro de la disciplina más amplia de la resiliencia). La ciberseguridad también es inseparable de la gobernanza de datos: una institución no puede proteger lo que no sabe que sostiene, y la interoperabilidad y apertura que crean valor público a partir de los datos también amplían la superficie que puede explotar un atacante (véase el Tema 5.4 — Datos del Sector Público, Interoperabilidad, y Datos Abiertos).

El problema de recursos es agudo y específico de los sectores público y social. Las agencias nacionales grandes cada vez más tienen equipos de seguridad dedicados y presupuestos empresariales; la junta de agua que sirve a un pueblo pequeño, el fideicomiso hospitalario regional, y la organización sin ánimo de lucro local que dirige un refugio contra la violencia doméstica típicamente no los tienen, a pesar de sostener datos cuya sensibilidad rivaliza o excede la de cualquier banco. Los atacantes saben esto. Los organismos públicos infrafinanciados no son un caso extremo en este tema; están cerca de su centro, porque la institución pública mediana que enfrenta este riesgo hoy no es un ministerio nacional sino una autoridad local pequeña, una empresa de servicios públicos regional, o una organización benéfica con un puñado de personal de tecnología de la información y ningún especialista en seguridad en absoluto.

Finalmente, este es un problema vivo y que empeora, no uno hipotético. Las campañas de ransomware cada vez más apuntan a gobiernos locales, hospitales, escuelas, y organizaciones del sector social precisamente porque combinan datos sensibles, servicios esenciales, baja tolerancia al tiempo de inactividad, y defensas comparativamente débiles —una combinación que los hace más propensos a pagar y menos propensos a haber prevenido el ataque en primer lugar. Tratar la ciberseguridad como un complemento especializado en lugar de un compromiso de valor público a nivel de gobernanza es, para esta clase de organización, cercano a una invitación.

Conceptos fundamentales

La infraestructura crítica es el conjunto de sistemas y activos —energía, agua, transporte, salud, finanzas, comunicaciones— tan esenciales que su incapacidad o destrucción tendría un efecto debilitante sobre la seguridad, la economía, o la confianza pública. La protección de infraestructura crítica es la disciplina de asegurar estos sistemas contra amenazas físicas y digitales por igual; importa aquí porque muchos de los incidentes cibernéticos del sector público más consecuentes no son ataques a datos abstractos sino ataques a la tecnología operativa que mantiene funcionando la infraestructura física, distinta de la tecnología de la información que mantiene registros y procesa transacciones.

Un actor de amenaza es cualquier individuo, grupo, o estado que pueda intentar comprometer un sistema; en el sector público estos van desde grupos criminales motivados financieramente hasta actores patrocinados por estados que persiguen espionaje o disrupción, y la misma institución puede enfrentar a ambos simultáneamente con objetivos muy diferentes. El ransomware es software malicioso que cifra los datos o sistemas de una organización y exige pago por su liberación; se ha convertido en la amenaza dominante para los organismos públicos precisamente porque los servicios esenciales no pueden tolerar un tiempo de inactividad prolongado, lo que aumenta la presión para pagar (véase Ransomware). El phishing es una forma de ingeniería social en la que los atacantes engañan al personal para que revele credenciales o instale malware, típicamente mediante correo electrónico engañoso, y sigue siendo la forma más común en que un atacante primero gana un punto de apoyo, porque se dirige a las personas en lugar de a la tecnología (véase Phishing).

Una brecha de datos es el acceso, divulgación, o pérdida no autorizados de información, ya sea mediante un ataque externo, un interno, o un simple error humano como una base de datos mal configurada dejada abierta a internet. Un ataque a la cadena de suministro compromete a una organización indirectamente, apuntando a un proveedor menos seguro, un vendedor de software, o un proveedor de servicios gestionados en el que confía la organización objetivo; estos son especialmente peligrosos para el sector público porque tantos organismos públicos comparten el mismo puñado de proveedores de software, lo que significa que el compromiso de un vendedor puede propagarse en cascada a cientos de instituciones simultáneamente.

La higiene cibernética es el conjunto de prácticas rutinarias —parchear el software rápidamente, exigir autenticación fuerte, limitar quién puede acceder a qué, respaldar los datos y probar la restauración de esos respaldos— que previenen la gran mayoría de los ataques exitosos sin requerir herramientas exóticas. La mayoría de las brechas explotan vulnerabilidades conocidas y sin parchear o credenciales débiles en lugar de técnicas novedosas, así que la brecha entre la higiene cibernética real de una organización y su política declarada usualmente es un mejor predictor de su riesgo que la sofisticación de las amenazas que nombra en su registro de riesgos.

La arquitectura de confianza cero es un principio de diseño de seguridad que sostiene que ningún usuario o dispositivo debería confiarse por defecto, incluso dentro de la propia red de una organización, y que cada solicitud de acceso debe verificarse independientemente de dónde se origine (véase Arquitectura de confianza cero). Se ha vuelto influyente en la orientación del sector público porque se ajusta a cómo realmente ocurre el trabajo gubernamental moderno —personal, contratistas, y ciudadanos accediendo a servicios desde muchos dispositivos y ubicaciones— mejor que un modelo más antiguo que confiaba en cualquier cosa ya dentro del perímetro.

La gestión de incidentes de seguridad informática, usualmente llamada respuesta a incidentes, es el proceso organizado de detectar, contener, erradicar, y recuperarse de un incidente de seguridad, seguido de una revisión de qué permitió que ocurriera. Una obligación de divulgación es un deber legal o regulatorio de notificar a las personas afectadas, los reguladores, o el público cuando se han comprometido datos personales o servicios críticos, dentro de un tiempo especificado y a un estándar especificado, sobre la lógica de que los ciudadanos y los organismos de supervisión tienen derecho a saber cuándo se han puesto en riesgo sus datos o sus servicios esenciales, y que la divulgación oportuna permite a las personas protegerse.

Mejores prácticas

1. Trate la ciberseguridad como una responsabilidad del órgano de gobierno, no una función técnica delegada. Las juntas directivas, los consejos, y los equipos ejecutivos deberían recibir informes regulares y en lenguaje llano sobre el riesgo cibernético y aprobar directamente el presupuesto para ello, en lugar de dejarlo negociarse dentro de una línea presupuestaria de tecnología de la información más amplia donde es lo más fácil de recortar.
2. Inventaríe qué sostiene y qué depende de ello antes de decidir cómo protegerlo. Una organización no puede asegurar datos o sistemas que no ha mapeado; un inventario actual de activos y datos, cruzado con el trabajo de interoperabilidad y gobernanza de datos cubierto en otra parte (véase el Tema 5.4 — Datos del Sector Público, Interoperabilidad, y Datos Abiertos), es la precondición para cada otra práctica en esta lista.
3. Aplique lo básico en todas partes antes de gastar en cualquier cosa avanzada. La gestión de parches, la autenticación multifactor, los respaldos probados, y el control de acceso de privilegio mínimo detienen la abrumadora mayoría de los ataques del mundo real; un organismo público sin esto en su lugar no debería priorizar suscripciones de inteligencia de amenazas o herramientas de monitoreo a medida.
4. Adopte un marco reconocido en lugar de inventar uno a medida. Marcos como el Cybersecurity Framework del Instituto Nacional de Estándares y Tecnología dan un vocabulario y estructura compartidos —identificar, proteger, detectar, responder, recuperar— que una organización pequeña puede adoptar en forma simplificada y una grande puede adoptar completamente, sin reinventar la taxonomía básica.
5. Agrupe recursos entre organizaciones pequeñas en lugar de que cada una compre sola. Un servicio compartido de operaciones de seguridad, un fondo regional de respuesta a incidentes cibernéticos, o un marco de contratación de todo el sector pueden dar a un grupo de autoridades locales pequeñas u organizaciones sin ánimo de lucro protección que ninguna de ellas podría permitirse individualmente —la respuesta única más directa al problema de infrarrecursos en el que se centra este tema.
6. Escriba el plan de respuesta a incidentes antes del incidente, y ensáyelo. Un plan redactado por primera vez durante un ataque en vivo es un plan mal redactado, bajo pánico, por personas que nunca han probado si realmente funciona; un plan ejercitado al menos anualmente convierte una primera hora caótica en una secuencia ensayada de pasos conocidos (véase el Tema 3.12 — Gestión de Crisis, Emergencias, y Resiliencia para la disciplina más amplia de la que se apoya esto).
7. Decida la política de divulgación y pago de antemano, no durante el incidente. Si la organización considerará pagar un rescate, quién tiene la autoridad para tomar esa decisión, y cómo y cuándo se informará a las personas afectadas debería ser una política aprobada por la junta, no una decisión improvisada tomada bajo la presión de una demanda de extorsión en vivo.
8. Segmente las redes de modo que un compromiso no pueda convertirse en todos los compromisos. Mantener la tecnología operativa que controla la infraestructura física separada de la tecnología de la información de oficina general, y separar los sistemas de alta sensibilidad de los de menor sensibilidad, limita cuán lejos puede viajar un intruso que entra por un punto débil.
9. Gestione el riesgo de terceros y cadena de suministro tan rigurosamente como el riesgo interno. Exija garantías de seguridad, cláusulas de derecho a auditoría, y obligaciones de notificación de incidentes en los contratos con vendedores de software y proveedores de servicios gestionados, ya que una parte creciente de los incidentes importantes del sector público se origina con un proveedor de confianza en lugar de un ataque directo.
10. Invierta en personas, no solo herramientas. La formación regular y realista —incluyendo ejercicios simulados de phishing— reduce mediblemente los ataques exitosos de ingeniería social, y retener incluso uno o dos empleados de seguridad capacitados en una organización pequeña usualmente vale más que un gasto equivalente en licencias de software adicionales.
11. Informe los incidentes honestamente y use los cuasi-incidentes como lecciones gratuitas. Una cultura que castiga al personal por informar una sospecha de brecha garantiza que la próxima se informe tarde o no se informe en absoluto; las organizaciones que mejoran más rápido son las que tratan cada cuasi-incidente como evidencia de la que aprender en lugar de una razón para asignar culpa.
12. Incorpore la resiliencia cibernética en las condiciones de contratación y subvención, no solo en la política interna. Los financiadores y organismos comisionadores pueden exigir un nivel base de práctica de seguridad de las organizaciones que financian o contratan, extendiendo el alcance de la buena práctica a socios de entrega más pequeños que de otro modo no tendrían presión externa para invertir en ella (véase el Tema 3.7 — Contratación Pública y Encargo de Servicios de Servicios).

Preguntas para discutir con su equipo

¿Sabemos qué datos y sistemas realmente sostenemos, y cuáles de ellos harían daño a alguien si se comprometieran? Muchas organizaciones descubren la verdadera extensión de sus posesiones de datos solo durante una investigación de brecha, que es el peor momento posible para aprenderlo. Recorra sus servicios importantes y pregunte, para cada uno, qué datos personales u operativamente sensibles toca y qué le pasaría a una persona real si esos datos fueran robados, alterados, o dejados no disponibles. Si la respuesta honesta es 'no estamos seguros', esa incertidumbre es en sí misma el hallazgo, y cerrarla es el primer elemento en su agenda. Esta pregunta importa más para organizaciones que han crecido mediante adquisición, fusión, o sistemas heredados acumulados, donde se ha diluido la memoria institucional de lo que existe.

Si nos golpeara el ransomware mañana, ¿podríamos restaurar desde un respaldo sin pagar? El valor de un respaldo no es que exista sino que se ha probado que realmente restaura, lo suficientemente rápido, desde una versión lo suficientemente reciente para importar. Pregunte cuándo se probaron por última vez los respaldos con un ejercicio de restauración real, no solo un registro de finalización, y cuánto tiempo tomaría una restauración completa frente a cuánto tiempo puede tolerar su organización una interrupción. Si esos números no coinciden, tiene una decisión de recursos que tomar ahora, no durante un incidente. Este también es el momento de discutir si los propios respaldos están aislados de la red a la que también podría llegar un atacante que alcance sus sistemas principales.

¿Quién tiene la autoridad para decidir si pagamos un rescate, y lo hemos discutido alguna vez antes de que se nos pregunte? Esta es una de las decisiones de mayor riesgo que puede enfrentar un equipo ejecutivo, a menudo requerida dentro de horas y con información incompleta sobre lo que realmente tiene el atacante. Decidir el proceso, los individuos autorizadores, y los principios de antemano —incluso si la decisión final todavía depende de los detalles del incidente— previene una decisión improvisada tomada bajo presión de extorsión. Discuta qué dice la ley de su jurisdicción y las condiciones de sus financiadores sobre el pago de rescate, y a quién necesitaría notificar.

¿Son nuestros socios y proveedores más pequeños un riesgo mayor para nosotros del que somos para nosotros mismos? Una organización central bien asegurada aún se puede comprometer mediante un proveedor, contratista, o socio de entrega mal asegurado con acceso legítimo a sus sistemas o datos. Mapee a los terceros que pueden alcanzar sus sistemas o sostener sus datos, y sea honesto sobre cuánta garantía realmente tiene sobre sus prácticas de seguridad frente a cuánta garantía asume que tiene. Decida qué estándar mínimo exigirá de ellos en adelante, y cómo lo verificará en lugar de simplemente pedir una garantía escrita.

¿Sabríamos si nos hubieran vulnerado, y con qué rapidez? Algunos de los incidentes más dañinos no son los que ocurren rápido sino los que pasan meses sin detectarse, durante los cuales un atacante ha explorado silenciosamente, escalado privilegios, y exfiltrado datos. Discuta cómo realmente detectaría actividad inusual hoy, quién la vigila, y si ese monitoreo funciona fuera del horario laboral, ya que muchos ataques se lanzan deliberadamente de noche o durante un fin de semana festivo cuando la respuesta es más lenta. Si la detección depende completamente de que un ciudadano u organización socia le diga que algo está mal, esa es una brecha crítica.

¿Entiende nuestra junta directiva u órgano de gobierno este riesgo lo suficientemente bien como para gobernarlo, o hemos silenciosamente externalizado ese juicio al equipo de tecnología de la información? Las decisiones de riesgo cibernético involucran compensaciones reales entre coste, continuidad de servicio, y protección ciudadana que propiamente son asunto del órgano de gobierno, no un asunto técnico delegado que aprobar con la cabeza. Discuta cómo se informa actualmente el riesgo cibernético a su junta o consejo, si está en un lenguaje sobre el que un no especialista realmente puede actuar, y si el presupuesto para ello se decide con el mismo rigor que cualquier otro riesgo importante. Si su órgano de gobierno actualmente no pudiera explicar los tres principales riesgos cibernéticos de su organización con sus propias palabras, esa es la brecha que cerrar primero.

En la práctica: un ejemplo de valor público

Una autoridad de tránsito regional de tamaño medio —ficticia, ilustrativa de un patrón en lugar de un informe de ninguna organización real— ejecutaba sistemas envejecidos de programación y pago que se habían parcheado fragmentariamente durante una década en lugar de modernizarse. Su equipo de tecnología de la información era de tres personas, responsables de todo desde tickets de mesa de ayuda hasta seguridad de red, y la ciberseguridad nunca había tenido su propia línea en el presupuesto; vivía dentro de una asignación general de 'mantenimiento de sistemas' que no había crecido en términos reales durante años.

Un atacante obtuvo acceso mediante un correo electrónico de phishing enviado a un funcionario de finanzas, usando una factura falsificada de un proveedor que la autoridad genuinamente usaba. Una vez dentro, el atacante pasó seis semanas moviéndose silenciosamente por la red antes de desplegar ransomware que cifró el sistema de programación, la plataforma de pago de tarifas, y los respaldos de la autoridad, que nunca se habían aislado de la red principal. Los autobuses siguieron funcionando con la memoria de los conductores de sus rutas el primer día, pero las tarifas no se pudieron cobrar electrónicamente, las pantallas de información en tiempo real se oscurecieron, y los sistemas financieros de la autoridad quedaron inutilizables para la nómina.

El equipo ejecutivo enfrentó la decisión de rescate sin ninguna política preacordada: nadie había decidido de antemano quién tenía autoridad para aprobar un pago, cuál era la posición legal, o qué les dirían a los pasajeros. La restauración desde respaldo no era una opción, porque los respaldos estaban cifrados junto con todo lo demás. Después de nueve días de disrupción, restauración parcial de servicio, y un pago que la junta de la autoridad más tarde describió como la opción menos mala disponible en ese momento, la autoridad encargó una revisión independiente.

Los hallazgos de la revisión eran poco glamorosos y completamente consistentes con el patrón que describe este tema: ninguna autenticación multifactor en los sistemas financieros, ninguna segmentación de red entre los sistemas de oficina y la infraestructura de pago, ninguna restauración de respaldo probada en más de dos años, y ninguna visibilidad a nivel de junta directiva sobre el riesgo cibernético en absoluto antes del incidente. La respuesta de la autoridad fue igualmente poco glamorosa —un plan por fases para arreglar lo básico, un arreglo compartido de monitoreo de seguridad con dos autoridades de tránsito vecinas para dividir el coste de cobertura especializada que ninguna de ellas podía permitirse sola, y un elemento permanente de agenda de junta sobre riesgo cibernético. Nada de esto era caro según los estándares de un programa mayor de tecnología de la información; todo se había omitido durante años porque nunca había sido el trabajo claramente asignado de nadie insistir en ello.

Cuatro lentes sectoriales

Gobierno local

Las autoridades locales se sitúan en una intersección incómoda: sostienen datos altamente sensibles —registros de atención social, información de vivienda y beneficios, registros electorales— y ejecutan servicios de los que los ciudadanos no pueden prescindir fácilmente, pero típicamente tienen los presupuestos de seguridad más pequeños y el menor personal especializado de cualquier nivel de gobierno. Un ministerio nacional grande puede construir un centro de operaciones de seguridad interno; un pequeño consejo de distrito usualmente no puede, lo que hace de los servicios compartidos, la agrupación regional, y los programas de apoyo nacional la ruta práctica hacia una protección adecuada en lugar de un extra opcional. Los funcionarios electos locales también a menudo están menos equipados, de cualquier nivel de gobierno, para interrogar un informe de riesgo técnico, lo que hace del informe en lenguaje llano a los miembros electos un desafío de gobernanza distinto a este nivel.

Gobierno nacional

Los gobiernos nacionales generalmente tienen los recursos para construir agencias de ciberseguridad dedicadas y marcos nacionales —organismos como el National Cyber Security Centre (Centro Nacional de Seguridad Cibernética) del Reino Unido o la Cybersecurity and Infrastructure Security Agency (Agencia de Ciberseguridad y Seguridad de Infraestructura) de Estados Unidos existen para fijar estándares, coordinar la respuesta, y apoyar a organismos públicos con menos recursos dentro de su jurisdicción. El desafío distintivo a nivel nacional trata menos sobre la higiene básica y más sobre actores de amenaza patrocinados por estados y altamente capaces, la interdependencia de la infraestructura nacional crítica a través de sectores y operadores privados, y las dimensiones diplomáticas y legales de la atribución y respuesta, que rara vez aparecen a nivel local u organizacional.

Sector social y sin ánimo de lucro

Las organizaciones sin ánimo de lucro y las ONG a menudo sostienen algunos de los datos más sensibles de cualquier sector —registros de salud, registros de sobrevivientes de violencia o persecución, gestión de casos de refugiados y asilo— mientras operan con los presupuestos de seguridad más delgados de cualquier tipo de organización en este libro, porque los financiadores rara vez destinan dinero a la seguridad y las condiciones de subvención rara vez lo exigen. Muchas organizaciones del sector social también dependen de voluntarios y alta rotación de personal, lo que hace más difícil sostener la formación de seguridad consistente y el control de acceso que en una organización estable y con personal profesional; un incidente de seguridad puede ser existencial para una organización benéfica pequeña de una forma en que rara vez lo es para un departamento gubernamental, porque el daño reputacional y la pérdida de confianza del donante pueden terminar la organización por completo (véase el Tema 3.8 — Gestión del Sector Social y Organizaciones Sin Ánimo de Lucro).

Multilateral e internacional

Los organismos multilaterales e internacionales operan a través de jurisdicciones con diferentes leyes de divulgación, diferentes definiciones de infraestructura crítica, y diferentes niveles de capacidad cibernética nacional, lo que hace de la propia coordinación un problema distinto: los propios sistemas de un organismo internacional pueden estar bien protegidos mientras sus agencias miembro nacionales varían enormemente, y un organismo como la Organización para la Cooperación y el Desarrollo Económicos o la Agencia de la Unión Europea para la Ciberseguridad juega tanto un rol de fijación de estándares y construcción de capacidad como uno operativo. La lente multilateral también es donde más importan la respuesta a incidentes transfronteriza y los arreglos de intercambio de información, ya que un ataque que comienza en la infraestructura de un país puede propagarse en cascada a la de otro dentro de horas, más rápido de lo que están construidos para moverse la mayoría de los mecanismos de coordinación internacional.

Modos de fallo comunes

Teatro de seguridad sin sustancia operativa. Una organización adopta un documento de política que se ve impresionante, un certificado de cumplimiento, o una única herramienta cara, y trata la casilla como marcada, mientras la higiene básica —parcheo, autenticación multifactor, respaldos probados— permanece inconsistente. Esto cuesta dinero real por la apariencia de seguridad en lugar de la propia seguridad, y a menudo solo se descubre que fue teatro después de que un incidente expone la brecha entre la política y la práctica.

El riesgo sin propietario. Se asume que la ciberseguridad es el trabajo de alguien más —el del equipo de tecnología de la información, un vendedor, un regulador— y no existe ningún propietario individual responsable a nivel de órgano de gobierno. Esto produce un riesgo que se discute en todas partes y se decide en ninguna, y es precisamente el patrón que deja a las organizaciones incapaces de responder preguntas básicas sobre su propia exposición cuando se les pregunta.

Infrainversión justificada por la ausencia de un incidente previo. Debido a que un programa de seguridad bien ejecutado no produce ningún evento visible cuando tiene éxito, es fácil desfinanciarlo en una ronda presupuestaria ajustada en favor de algo con un producto visible, y la ausencia de una brecha hasta ahora se confunde con evidencia de protección adecuada en lugar de evidencia que aún no se ha probado. Esto refleja la misma lógica presupuestaria que socava la inversión en resiliencia más ampliamente (véase el Tema 3.12 — Gestión de Crisis, Emergencias, y Resiliencia).

Sistemas heredados mantenidos en funcionamiento más allá de su vida soportable. Los organismos públicos frecuentemente ejecutan software o hardware mucho después de que un vendedor ha dejado de emitir parches de seguridad para él, porque el reemplazo es caro, disruptivo, o políticamente impopular, y el sistema 'todavía funciona'. Un sistema sin parchear y sin soporte no es un inconveniente heredado; es una puerta abierta que no le cuesta nada a un atacante atravesar.

Cultura de incidentes que culpa primero. Cuando el personal que informa una sospecha de brecha o un error es disciplinado en lugar de apoyado, los incidentes futuros se informan tarde, se minimizan, o no se informan en absoluto, y la organización pierde la señal de alerta temprana que proporciona el informe oportuno. Este modo de fallo agrava cada otro en esta lista, porque ninguno de los arreglos anteriores funciona si la organización no puede ver sus propios problemas honestamente.

Modelo de madurez

Lista de verificación

• Un individuo o comité nombrado a nivel de órgano de gobierno posee el riesgo cibernético e informa sobre él regularmente, en lenguaje llano.
• Existe un inventario actual de qué datos y sistemas sostiene la organización, y cuáles son los más sensibles o más críticos para un servicio.
• Se exige la autenticación multifactor en todos los sistemas que sostienen datos sensibles o controlan servicios críticos.
• Los respaldos se toman regularmente, se almacenan aislados de la red principal, y la restauración se ha probado dentro de los últimos doce meses.
• El software y los sistemas se parchean en un calendario definido, y cualquier sistema que ya no se pueda parchear tiene un plan documentado para reemplazarlo o aislarlo.
• Existe un plan de respuesta a incidentes escrito, nombra quién tiene autoridad para tomar decisiones clave, y se ha ensayado mediante un ejercicio realista en el último año.
• Existe una política aprobada por la junta sobre el pago de rescate y sobre cómo y cuándo se notificará a las personas afectadas, los reguladores, y el público.
• Los contratos con vendedores de software y proveedores de servicios gestionados incluyen garantías de seguridad y obligaciones de notificación de incidentes.
• El personal recibe formación de seguridad regular y realista, incluyendo ejercicios simulados de phishing.
• Informar una sospecha de incidente o cuasi-incidente se trata como información valorada, no motivo de culpa.
• Se han explorado arreglos de seguridad compartidos o agrupados con organizaciones pares de tamaño y presupuesto similares.
• El riesgo cibernético aparece explícitamente en la planificación más amplia de crisis y resiliencia de la organización, no como un plan separado y desconectado.

Fuentes clave

Este tema se apoya en el Cybersecurity Framework del Instituto Nacional de Estándares y Tecnología como el marco estructurado líder para organizar la práctica de ciberseguridad; la misión y orientación publicadas de la Agencia de la Unión Europea para la Ciberseguridad sobre lograr un nivel común de ciberseguridad en toda la Unión Europea; el trabajo de política de seguridad digital de la Organización para la Cooperación y el Desarrollo Económicos, que enmarca la seguridad digital como un asunto de gestión de riesgo económico y social en lugar de puramente técnico; y la orientación operativa publicada por agencias nacionales de ciberseguridad como el National Cyber Security Centre del Reino Unido y la Cybersecurity and Infrastructure Security Agency de Estados Unidos, ambas de las cuales proporcionan orientación gratuita específicamente dirigida a organismos públicos con pocos recursos.

Referencias

1. Computer security — Wikipedia — https://en.wikipedia.org/wiki/Computer_security
2. Critical infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Critical_infrastructure
3. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
4. Phishing — Wikipedia — https://en.wikipedia.org/wiki/Phishing
5. Data breach — Wikipedia — https://en.wikipedia.org/wiki/Data_breach
6. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
7. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
8. Computer security incident management — Wikipedia — https://en.wikipedia.org/wiki/Computer_security_incident_management
9. National Cyber Security Centre (United Kingdom) — Wikipedia — https://en.wikipedia.org/wiki/National_Cyber_Security_Centre_(United_Kingdom)
10. Cybersecurity and Infrastructure Security Agency — Wikipedia — https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency
11. Cybersecurity Framework — National Institute of Standards and Technology — https://www.nist.gov/cyberframework
12. Who we are — European Union Agency for Cybersecurity (ENISA) — https://www.enisa.europa.eu/about-enisa/who-we-are
13. Digital security — Organisation for Economic Co-operation and Development (OECD) — https://www.oecd.org/en/topics/digital-security.html
14. What we do at the NCSC — National Cyber Security Centre (United Kingdom) — https://www.ncsc.gov.uk/section/about-ncsc/what-we-do
15. About CISA — Cybersecurity and Infrastructure Security Agency (United States) — https://www.cisa.gov/about