Doxa 1497

Se vienen nuevas regulaciones de ciberseguridad. Aquí está cómo prepararse.

No espere para evaluar el impacto potencial en su organización.

Por Stuart Madnick

Ciberseguridad y privacidad digital

Harvard Business Review

#doxa #ciberseguridad #regulaciones #organización #evaluar #impacto #empresas #USA #tecnología #Web

Resumen. Un conjunto completo de nuevas regulaciones y aplicación de ciberseguridad está a la vista, tanto a nivel estatal como federal en los EE. UU. y en todo el mundo. Sin embargo, las empresas no necesitan simplemente sentarse y esperar a que se escriban las reglas y luego se implementen. Más bien, deben estar trabajando ahora para comprender los tipos de regulaciones que se están considerando actualmente, determinar las incertidumbres y los impactos potenciales y prepararse para actuar.

La ciberseguridad ha llegado a un punto de inflexión. Después de décadas de dejar que las organizaciones del sector privado se ocupen más o menos de los incidentes cibernéticos por su cuenta, la escala y el impacto de los ataques cibernéticos significa que las consecuencias de estos incidentes pueden extenderse a través de las sociedades y las fronteras.

Ahora, los gobiernos sienten la necesidad de “hacer algo”, y muchos están considerando nuevas leyes y reglamentos. Sin embargo, los legisladores a menudo luchan por regular la tecnología: responden a la urgencia política y la mayoría no tiene un conocimiento firme de la tecnología que pretenden controlar. Las consecuencias, los impactos y las incertidumbres en las empresas a menudo no se dan cuenta hasta después.

En los Estados Unidos, se avecina un conjunto completo de nuevas regulaciones y aplicación: la Comisión Federal de Comercio, la Administración de Alimentos y Medicamentos, el Departamento de Transporte, el Departamento de Energía y la Agencia de Seguridad de Infraestructura y Ciberseguridad están trabajando en nuevas reglas. Además, solo en 2021, 36 estados promulgaron nuevas leyes de ciberseguridad. A nivel mundial, existen muchas iniciativas, como los requisitos de localización de datos de China y Rusia, los requisitos de informes de incidentes CERT-In de India y el RGPD de la UE y su informe de incidentes.

Sin embargo, las empresas no necesitan simplemente sentarse y esperar a que se escriban las reglas y luego se implementen. Más bien, deben estar trabajando ahora para comprender los tipos de regulaciones que se están considerando actualmente, determinar las incertidumbres y los impactos potenciales y prepararse para actuar.

Lo que no sabemos sobre los ciberataques

Hasta la fecha, las reglamentaciones relacionadas con la seguridad cibernética de la mayoría de los países se han centrado en la privacidad en lugar de la seguridad cibernética, por lo que no es necesario informar la mayoría de los ataques de seguridad cibernética. Si se roba información privada, como nombres y números de tarjetas de crédito, debe informarse a la autoridad correspondiente. Pero, por ejemplo, cuando Colonial Pipeline sufrió un ataque de ransomware que provocó el cierre del oleoducto que proporcionaba combustible a casi el 50 % de la costa este de EE. UU., no estaba obligado a informarlo porque no se robó información personal. (Por supuesto, es difícil mantener las cosas en secreto cuando miles de estaciones de gasolina no pueden obtener combustible).

Como resultado, es casi imposible saber cuántos ataques cibernéticos hay realmente y qué forma toman. Algunos han sugerido que solo se informa el 25% de los incidentes de seguridad cibernética, otros dicen que solo alrededor del 18%, otros dicen que se informa el 10% o menos.

La verdad es que no sabemos lo que no sabemos. Esta es una situación terrible. Como dijo el gurú de la gestión Peter Drucker: “Si no puedes medirlo, no puedes administrarlo”.

¿Qué debe informarse, por quién y cuándo?

Los gobiernos han decidido que este enfoque es insostenible. En los Estados Unidos, por ejemplo, la Casa Blanca, el Congreso, la Comisión de Bolsa y Valores (SEC) y muchas otras agencias y gobiernos locales están considerando, buscando o comenzando a aplicar nuevas reglas que exigirían que las empresas informen sobre incidentes cibernéticos: especialmente las industrias de infraestructura crítica, como la energía, la atención médica, las comunicaciones y los servicios financieros. Bajo estas nuevas reglas, Colonial Pipeline estaría obligado a informar un ataque de ransomware.

Hasta cierto punto, estos requisitos se han inspirado en los informes recomendados para "casi accidentes" o "llamadas cercanas" para aeronaves : cuando las aeronaves están a punto de estrellarse, deben presentar un informe, para que las fallas que causan tales eventos puedan identificarse y evitarse en el futuro.

A primera vista, un requisito similar para la ciberseguridad parece muy razonable. El problema es que lo que debería contar como un "incidente" de seguridad cibernética es mucho menos claro que el "casi accidente" de dos aviones más cerca de lo permitido. Un “incidente” cibernético es algo que podría haber dado lugar a una infracción cibernética, pero que no tiene por qué haberse convertido en una infracción cibernética real: según una definición oficial, solo requiere una acción que “pone en peligro inminente” un sistema o presenta un “incidente inminente”. amenaza” de violar una ley.

Sin embargo, esto deja a las empresas navegando por un área gris. Por ejemplo, si alguien intenta iniciar sesión en su sistema pero se le niega porque la contraseña es incorrecta. ¿Es eso una “amenaza inminente”? ¿Qué pasa con un correo electrónico de phishing? ¿ O alguien que busca una vulnerabilidad común conocida, como la vulnerabilidad log4j, en su sistema? ¿Qué sucede si un atacante realmente entró en su sistema, pero fue descubierto y expulsado antes de que se produjera algún daño?

Esta ambigüedad requiere que las empresas y los reguladores logren un equilibrio. Todas las empresas están más seguras cuando hay más información sobre lo que intentan hacer los atacantes, pero eso requiere que las empresas informen incidentes significativos de manera oportuna. Por ejemplo, según los datos recopilados de los informes de incidentes actuales, aprendimos que solo 288 de las casi 200 000 vulnerabilidades conocidas en la base de datos nacional de vulnerabilidades (NVD) se están explotando activamente en ataques de ransomware. Saber esto permite a las empresas priorizar el abordaje de estas vulnerabilidades.

Por otro lado, usar una definición demasiado amplia podría significar que una gran empresa típica podría estar obligada a informar miles de incidentes por día, incluso si la mayoría eran correos electrónicos no deseados que fueron ignorados o rechazados. Esta sería una carga enorme tanto para la empresa que produce estos informes como para la agencia que necesitaría procesar y dar sentido a tal avalancha de informes.

Las empresas internacionales también deberán navegar por los diferentes estándares de informes en la Unión Europea, Australia y otros lugares, incluida la rapidez con la que se debe presentar un informe, ya sea seis horas en India, 72 horas en la UE bajo GDPR, o cuatro días hábiles en los Estados Unidos y, a menudo, muchas variaciones en cada país, ya que hay una avalancha de regulaciones que surgen de diversas agencias.

Lo que las empresas pueden hacer ahora

Asegúrese de que sus procedimientos estén a la altura de la tarea.

Las empresas sujetas a las reglamentaciones de la SEC, que incluyen a la mayoría de las grandes empresas de los Estados Unidos, deben definir rápidamente la "relevancia" y revisar sus políticas y procedimientos actuales para determinar si se aplica la "relevancia", a la luz de estas nuevas reglamentaciones. Es probable que necesiten revisarlos para agilizar su operación, especialmente si tales decisiones deben tomarse con frecuencia y rapidez.

Mantenga las políticas de ransomware actualizadas.

También se están formulando regulaciones en áreas como la notificación de ataques de ransomware e incluso tipificar como delito el pago de un rescate. Las políticas de la empresa con respecto al pago de ransomware deben revisarse, junto con los posibles cambios en las políticas de ciberseguro.

Prepárese para la "Lista de materiales de software" requerida para examinar mejor su cadena de suministro digital.

Muchas empresas no sabían que tenían la vulnerabilidad log4j en sus sistemas porque ese software a menudo se incluía con otro software que se incluía con otro software. Se están proponiendo regulaciones para exigir a las empresas que mantengan una lista de materiales de software (SBOM) detallada y actualizada para que puedan conocer de forma rápida y precisa todas las diferentes piezas de software integradas en sus complejos sistemas informáticos.

Aunque un SBOM también es útil para otros fines, puede requerir cambios significativos en las formas en que se desarrolla y adquiere el software en su empresa. El impacto de estos cambios debe ser revisado por la gerencia.

¿Qué más debe hacer?

Alguien, o probablemente un grupo en su empresa, debería revisar estas regulaciones nuevas o propuestas y evaluar qué impactos tendrán en su organización. Estos rara vez son solo detalles técnicos que se dejan en manos de su equipo de tecnología de la información o seguridad cibernética: tienen implicaciones en toda la empresa y cambios probables en muchas políticas y procedimientos en toda su organización. En la medida en que la mayoría de estas nuevas reglamentaciones aún sean maleables, es posible que su organización quiera influir activamente en las direcciones que toman estas reglamentaciones y cómo se implementan y se hacen cumplir.

Reconocimiento: Esta investigación fue financiada, en parte, por fondos de los miembros del consorcio Cybersecurity at MIT Sloan (CAMS).

Stuart Madnick es profesor John Norris Maguire (1960) de Tecnologías de la Información en la Escuela de Administración Sloan del MIT, Profesor de Sistemas de Ingeniería en la Escuela de Ingeniería del MIT y Director de Ciberseguridad en el MIT Sloan (CAMS): el Consorcio Interdisciplinario para Mejorar los Infraestructura Ciberseguridad. Ha estado activo en el campo de la ciberseguridad desde que fue coautor del libro Computer Security en 1979.