El reloj de las 72 horas: lo que la Ley de Privacidad y las normas de notificación de brechas de Nueva Zelanda exigen realmente a las pymes

Una base de datos de clientes queda expuesta. Un atacante obtiene acceso a su aplicación web. Un empleado descubre que es posible que se haya descargado información personal sin autorización.

En ese momento, ya no se enfrenta solo a un incidente de ciberseguridad. Es posible que también tenga una brecha de privacidad que debe notificarse según la Ley de Privacidad de 2020 de Nueva Zelanda.

La Oficina del Comisionado de Privacidad espera que le notifique en un plazo de 72 horas desde que tenga conocimiento de que una brecha es notificable. Es posible que deba actuar mientras su investigación técnica aún está en curso, antes de saber exactamente qué sucedió, cuántas personas se vieron afectadas o si el atacante accedió, copió o retuvo información personal.

Esto crea un entorno operativo difícil, especialmente para una pequeña o mediana empresa con recursos legales, de privacidad y de seguridad limitados.

Por lo tanto, debe comprender dos cosas antes de que ocurra un incidente:

1. Lo que la Ley de Privacidad realmente le exige hacer.
2. Cómo las pruebas de seguridad proactivas pueden reducir la probabilidad de que tenga que tomar esas decisiones bajo presión.

‍

¿Son las 72 horas un plazo legal en Nueva Zelanda?

La Ley de Privacidad exige que una organización notifique al Comisionado de Privacidad tan pronto como sea posible después de tener conocimiento de que se ha producido una brecha de privacidad notificable. La Oficina del Comisionado de Privacidad, o OPC, espera la notificación en un plazo de 72 horas.

El periodo de 72 horas es una guía de la OPC, no un plazo fijo escrito en la Ley. Sin embargo, no debe tratarse como un permiso para esperar. "Tan pronto como sea posible" puede requerir una notificación antes si la gravedad de la brecha ya está clara.

‍

‍

No notificar a la OPC sin una razón justificada es una infracción, con una multa máxima actual de 10.000 NZ$. Una petición ante el Parlamento propone aumentar la multa máxima a 100.000 NZ$, aunque el cambio propuesto aún no se ha convertido en ley. Una brecha también puede causar daños a los clientes, problemas contractuales, daños a la reputación e interrupciones del servicio.

La guía oficial está disponible a través de los recursos sobre brechas de privacidad de la OPC, su explicación sobre cómo funciona el plazo de 72 horas, y la sección 114 de la Ley de Privacidad de 2020.

Leer más: Blacklock Security obtiene la acreditación CREST

‍

¿Qué brechas de privacidad deben notificarse?

Una brecha de privacidad puede implicar información personal que se ha perdido, a la que se ha accedido, que se ha divulgado, alterado o tratado de otro modo sin autorización. Puede ser el resultado de un ciberataque, la pérdida de un dispositivo, un correo electrónico enviado a la dirección incorrecta o el acceso inapropiado por parte de un empleado.

Sin embargo, no todo incidente de seguridad constituye una brecha de privacidad notificable. La notificación es obligatoria cuando la brecha ha causado, o es probable que cause, daños graves a la persona afectada.

Factores utilizados para evaluar los daños graves

Las consideraciones relevantes incluyen:

• La sensibilidad y el volumen de la información
• Si se trata de datos de identidad, financieros, de salud, de autenticación, laborales u otros datos confidenciales
• Quién obtuvo la información o quién podría obtenerla
• Si la información estaba cifrada, era recuperable o seguía bajo el control de la organización
• El potencial de fraude, robo de identidad, pérdida financiera, discriminación, humillación o daño físico o psicológico
• La eficacia de las medidas de contención
• Cualquier consideración cultural que afecte a la gravedad del daño

OPC Proceso de evaluación de NotifyUs ayuda a las organizaciones a evaluar estos factores

‍

¿Cuándo comienza el plazo de 72 horas?

El plazo de 72 horas no comienza necesariamente cuando un atacante accede por primera vez a un entorno. Comienza cuando la organización tiene conocimiento de que el incidente es una brecha de privacidad notificable.

Algunos casos son evidentes de inmediato, como cuando existen pruebas de que un atacante descargó una base de datos de clientes sin cifrar. Otros requieren investigaciones iniciales para determinar si se vio afectada información personal y si es probable que se produzca un daño grave.

Las organizaciones pueden investigar antes de decidir si es necesaria la notificación. No deben esperar a obtener un informe forense completo cuando las pruebas disponibles ya indican la probabilidad de un daño grave.

El conocimiento de la organización puede originarse fuera del equipo de privacidad

El conocimiento de la brecha que tengan los empleados o agentes puede considerarse como conocimiento de la organización. El plazo no espera necesariamente a que el asunto llegue al director ejecutivo, al responsable de privacidad o al asesor legal. Por lo tanto, un proceso de escalada eficaz debe garantizar que:

• Los empleados sepan cómo informar sobre sospechas de incidentes de privacidad.
• Las alertas de seguridad lleguen a alguien autorizado para investigar.
• El responsable de privacidad participe con prontitud.
• Los proveedores de servicios tengan obligaciones claras de notificación de incidentes.
• Los hallazgos tengan fecha y hora.
• Se asigne la responsabilidad de la decisión de notificación.

Toda empresa u organización de Nueva Zelanda debe contar con un responsable de privacidad. La OPC ofrece más orientación sobre las responsabilidades de privacidad de la organización.

La información puede proporcionarse de forma gradual

Es posible que una organización no conozca el alcance total en 72 horas. OPC permite una notificación inicial que contenga la información verificada disponible de manera razonable, seguida de actualizaciones a medida que se identifiquen más sistemas, registros y personas.

‍

¿Qué se debe hacer tras descubrir una posible brecha de seguridad?

Una respuesta inicial práctica debe cubrir siete pasos:

1. Contener el incidente. Deshabilitar las cuentas comprometidas, aislar los sistemas afectados, revocar las credenciales expuestas, preservar las pruebas y evitar una mayor divulgación.
2. Activar el equipo de respuesta. Involucrar a los responsables de seguridad, privacidad, gestión, legal, comunicaciones y a los propietarios de los sistemas afectados.
3. Establecer qué información se vio afectada. Determinar qué información personal estaba presente, si fue accedida o extraída, y quiénes podrían verse afectados.
4. Evaluar el daño grave. Considerar la sensibilidad de la información, las protecciones disponibles, las posibles consecuencias y las medidas de contención.
5. Notificar a la OPC cuando sea necesario. Utilizar NotifyUs tan pronto como sea posible en lugar de esperar a que finalice toda la investigación.
6. Notificar a las personas afectadas cuando sea necesario. Explicar qué sucedió, qué información estuvo involucrada, qué está haciendo la organización y qué deben hacer las personas afectadas.
7. Continuar con la investigación y la documentación. Mantener un cronograma, proporcionar actualizaciones, subsanar la vulnerabilidad y registrar las decisiones clave.

‍

Por qué las pymes tienen dificultades durante el periodo de notificación

La evaluación legal depende de información técnica fiable. Esto se complica cuando la organización no puede responder rápidamente a:

• ¿Qué sistemas expuestos a internet se vieron afectados?
• ¿Qué información personal almacenaba o procesaba la aplicación?
• ¿Pudo el atacante moverse más allá del punto de entrada inicial?
• ¿La vulnerabilidad afectó a una aplicación, API, servidor, servicio en la nube o componente de terceros?
• ¿Existen vulnerabilidades similares en otros lugares?
• ¿Se ha corregido y vuelto a probar la vulnerabilidad?

Cuando los registros de activos están incompletos, los escaneos son irregulares, los resultados de las pruebas de penetración están desactualizados o no hay pruebas de la corrección, gran parte del periodo de notificación puede perderse reconstruyendo información que ya debería estar accesible.

Un plan de respuesta a incidentes puede ayudar a una organización a contener los daños, coordinar decisiones, preservar pruebas y cumplir con sus obligaciones de notificación de manera eficiente. Sin embargo, sigue siendo un control reactivo. 

No identifica las debilidades que permitieron que el incidente ocurriera en primer lugar. Por eso, la preparación ante brechas debe ir acompañada de pruebas de seguridad proactivas diseñadas para encontrar y corregir debilidades explotables antes de que los atacantes puedan aprovecharlas.

‍

La prevención y la preparación ante brechas están conectadas

El Principio 5 de Privacidad de la Información de la Ley de Privacidad exige que las organizaciones utilicen medidas de seguridad razonables según las circunstancias para proteger la información personal contra pérdidas, acceso no autorizado, divulgación, modificación y otros usos indebidos.

Lo que se considera razonable depende de la información que se posea, las amenazas a las que se enfrenta y los sistemas involucrados. La OPC ofrece más detalles en su guía sobre el Principio 5 de Privacidad de la Información.

Las pruebas proactivas ayudan a determinar si esas medidas de seguridad funcionan según lo previsto.

‍

‍

Aunque las pruebas no pueden evitar todas las brechas, su papel es fundamental. Reducen la exposición evitable, mejoran la visibilidad y proporcionan a los equipos mejor información cuando ocurre un incidente.

‍

Cómo apoya Blacklock las pruebas de seguridad proactivas

Blacklock combina el escaneo automatizado de vulnerabilidades con pruebas de penetración manuales dirigidas por expertos, lo que permite a las organizaciones evaluar sus sistemas de forma continua y obtener una validación más profunda cuando es necesario.

Blacklock también es un proveedor aprobado en el mercado Pae Hokohoko del Gobierno de Nueva Zelanda, dentro de la categoría de código fuente, revisión de aplicaciones y pruebas técnicas. Sus servicios incluyen pruebas de penetración, escaneo de vulnerabilidades para aplicaciones web, API e infraestructura, pruebas de seguridad de aplicaciones estáticas y análisis de componentes de software.

Más información disponible en el anuncio de Blacklock sobre su incorporación al mercado del Gobierno de Nueva Zelanda.

‍

Escaneo continuo de vulnerabilidades

Garantía y supervisión de seguridad continua de Blacklock admite escaneos programados, bajo demanda y activados por CI/CD en aplicaciones, API, infraestructura y otros sistemas expuestos a internet.

Esta capacidad es especialmente útil para las organizaciones que realizan despliegues frecuentes, ya que una prueba de penetración puntual no puede evaluar las vulnerabilidades introducidas por versiones posteriores. El escaneo continuo de Blacklock ayuda a mantener la visibilidad entre las evaluaciones manuales, al tiempo que centraliza los hallazgos, el progreso de la corrección, el historial de escaneos y las pruebas de reevaluación.

‍

Pruebas de penetración de aplicaciones web

Las aplicaciones web suelen procesar datos de clientes, empleados, financieros y de autenticación, lo que las convierte en una vía común de acceso a sistemas sensibles. Por tanto, las vulnerabilidades en la autenticación, los controles de acceso, la gestión de sesiones, el manejo de entradas o la lógica empresarial pueden crear un camino directo hacia una brecha de privacidad.

El servicio de pruebas de penetración de aplicaciones web de Blacklock combina el escaneo automatizado con pruebas manuales certificadas por CREST para evaluar las aplicaciones web y sus API asociadas.

Las herramientas automatizadas identifican vulnerabilidades comunes en aplicaciones web, configuraciones inseguras y componentes expuestos. Los evaluadores manuales utilizan técnicas de caja negra y caja gris para examinar la autenticación, los controles de acceso, la lógica de negocio, las solicitudes HTTP, los parámetros, los campos ocultos y los puntos finales de API desde la perspectiva de un atacante, siguiendo metodologías reconocidas como OWASP y OSSTMM. Los hallazgos se priorizan según el riesgo y van acompañados de una guía de remediación.

‍

Pruebas de penetración de infraestructura y servicios bajo demanda

Las pruebas de penetración de infraestructura evalúan la infraestructura pública y privada en busca de servicios expuestos, configuraciones inseguras, software vulnerable, puertos abiertos y posibles rutas de ataque.

A través de pruebas de penetración manuales bajo demanda, las organizaciones también pueden solicitar un servicio con certificación CREST alineado con un lanzamiento, un requisito de garantía del cliente o un calendario de cumplimiento.

‍

Lista de verificación de preparación práctica

Antes de que ocurra un incidente, una organización debería poder responder afirmativamente a las siguientes preguntas:

• ¿Se ha designado un responsable de privacidad?
• ¿Saben los empleados cómo informar sobre una posible brecha de seguridad?
• ¿Existe un inventario de los sistemas que almacenan o procesan información personal?
• ¿Se prueban regularmente las aplicaciones, las API y la infraestructura expuestas a internet, así como después de cambios importantes?
• ¿Se utilizan pruebas de penetración manuales cuando el escaneo automatizado es insuficiente?
• ¿Está clara la responsabilidad de la remediación y se vuelven a probar las correcciones posteriormente?
• ¿Se pueden recuperar rápidamente el historial de escaneos, las pruebas y los informes?
• ¿Se puede notificar a la OPC y a las personas afectadas antes de que se complete la investigación exhaustiva?

‍

No espere a que el reloj empiece a correr

El peor momento para descubrir las obligaciones de notificación de una brecha es después de que un atacante ya haya accedido a información personal.

Una vez identificada una posible brecha que deba notificarse, la organización puede disponer de muy poco tiempo para contener el incidente, evaluar los daños graves, notificar a la OPC, comunicarse con las personas afectadas y continuar con la investigación.

Esas responsabilidades no pueden eliminarse, pero sí puede reducirse la probabilidad de tener que afrontarlas sin preparación.

Al combinar un proceso establecido de gestión de brechas de privacidad con pruebas de seguridad continuas, la corrección de vulnerabilidades y pruebas de penetración periódicas, las organizaciones pueden identificar más debilidades antes de que se conviertan en puntos de entrada para una brecha.

Puede iniciar una prueba de 14 días de Blacklock o ponerse en contacto con Blacklock para analizar las aplicaciones, las API y la infraestructura que deben evaluarse.

Este artículo ofrece información general y no constituye asesoramiento jurídico. Las organizaciones deben obtener el asesoramiento profesional adecuado para sus circunstancias específicas.