opinión

No es una novedad que hoy estamos como sociedad muy conectados digitalmente a Internet, no solo a través de dispositivos móviles como smartphones y ipads, dispositivos fijos como computadores o terminales; la novedad es que las “cosas” comienzan a conectarse y a levantar muchísima más información de la que podríamos imaginar.

Esta cuarta revolución después de la aparición del vapor, la electricidad y los computadores, nos plantea dos desafíos muy importantes: ¿Qué hacer con esta información ? y ¿ Cómo proteger esta información ?.

No sólo los elementos domésticos básicos están conectados, como televisores, radios, cafeteras y refrigeradores, por nombrar algunos. También lo están nuestras actividades a través de nuestros comportamientos, al comprar por medios electrónicos en tiendas, al transitar en vehículos contratados por plataformas o al circular libremente por espacios públicos con cámaras conectadas a Internet.

Sin embargo lo más crítico son los sistemas de información conectados a Internet que controlan procesos críticos para nuestra subsistencia como por ejemplo los servicios eléctricos, sanitarios que nos proveen el agua, los servicios financieros, las comunicaciones o que nos dan apoyos de vida como los sistemas hospitalarios o logísticos e incluso los sistemas industriales, algunos de ellos de procesos complejos y que operados incorrectamente podrían producir tragedias a la población cercana a ellos o generar un déficit en la producción que genere pánico y descontrol.

En este nuevo entorno la sociedad debe avanzar para convertirse en una “sociedad digital”, entendiendo los beneficios que ello conlleva, pero comprendiendo los riesgos asociados. Por eso debemos avanzar decididamente hacia este nuevo escenario, pero de forma “segura”.

Es precisamente este concepto de seguridad el que debemos desarrollar colectivamente, para convertirnos en una “sociedad digital segura”, donde el conocimiento que es la fuente de inspiración, debe ser compartido de forma colaborativa y en red, para lograr a todos disfrutar los beneficios con los menores riesgos posible.

La gestión de riesgos a nivel personal es precisamente lo que inspira a las grandes corporaciones, instituciones y al gobierno, junto a toda la sociedad, pero se requiere de un marco regulatorio y jurídico nacional que garantice a todos reglas claras.

En tal sentido el reconocimiento constitucional a la protección de los datos personales en el artículo 19 y el trabajo legislativo que se realizará para actualizar la ley de datos personales a estándares homologables a lo que Europa ha definido en su reglamento europeo de protección de datos (GDPR) es uno de los pilares fundamentales de la nueva institucionalidad.

El segundo pilar es una nueva ley que permita la protección de la información crítica de la información, contribuyendo a crear el ambiente de colaboración para reporte e intercambio de información de incidentes graves que se clasifiquen como ciberataques.  Estos pilares se deben basar en una nueva institucionalidad con una organización que permita por un lado garantizar la protección de datos con la Agencia de Protección de Datos Personales y un centro de respuesta a incidentes cibernéticos nacionales, coordinando las áreas de infraestructura crítica del sector público uy el privado.

Finalmente se requiere como marco que contribuya a generar el cambio cultural para lo cual se ha propuesto por moción de los senadores de la comisión de defensa, designar al mes de octubre como el mes nacional de la ciberseguridad, para crear conciencia y poder desarrollar ejercicios nacionales que contribuyan a comprobar el nivel de conocimiento y preparación.

Lo más curioso es que todas estas iniciativas comenzaron agestarse a principios del mes de mayo de este año, el que vio nacer la iniciativa privada más notable de los últimos tiempos: La Alianza Chilena de Ciberseguridad, que a fines de mes convocó a los actores más relevantes que están construyendo esta nueva sociedad digital. Mayo de 2018 quedará grabado entonces en los anales de la nueva historia digital de Chile y en particular en las historias individuales de las primeras nueve organizaciones que dieron como Alianza el primer paso a lograr que esta nueva sociedad esté debidamente protegida.

No es un misterio que la cuarta revolución industrial conlleva el tratamiento masivo de datos personales, los cuales, asociados a las vulnerabilidades propias de los sistemas informáticos y la falta de políticas de seguridad, generan un riesgo constante de accesos no autorizados y filtraciones de datos. La explotación de esas vulnerabilidades por agentes malintencionados puede desencadenar un daño relevante tanto para los titulares de datos afectados, como para las instituciones o empresas involucradas.

Bajo este panorama, la seguridad de los datos personales que las empresas recolectan es de extrema relevancia, y así lo han entendido los reguladores alrededor del mundo, quienes han elaborado diversas iniciativas para promover y –en algunos casos- obligar a los responsables a adoptar medidas de seguridad y de reporte de vulneraciones a autoridades y a personas afectadas.

Los autores Stefan Laube y Rainer Böhme han señalado que las vulneraciones de seguridad no solo generan un costo a las instituciones directamente afectadas, sino que, en virtud de la interdependencia de los sistemas de información, estas pueden también llegar a afectar a otras entidades. Para ellos, este factor constituiría una externalidad negativa en la economía que justificaría la intervención del Estado (costo social) y, en consecuencia, las obligaciones de reporte de vulneraciones.

Para estos autores, las normas sobre notificación de vulneraciones a medidas de seguridad tienen dos objetivos principales: (i) otorgar información que permita a los individuos y empresas protegerse y así mitigar los efectos; y (ii) incentivar la inversión en seguridad de la información, en vista que esta clase de notificaciones pueden dañar la reputación de la empresa afectada y su valorización. Estos mismos propósitos son señalados por otros autores como Richard J. Sullivan y Jesse Leigh.

¿CÓMO SE HA REGULADO FUERA DE CHILE?

A nivel comparado, las obligaciones de reporte de este tipo no son novedad y constituyen un elemento común a la hora de establecer requisitos mínimos de seguridad involucrados en el tratamiento de datos personales.

En la Unión Europea, la obligación de notificación vulneraciones fue establecida por primera vez en la ePrivacy Directive para el área de telecomunicaciones, específicamente respecto de proveedores de un servicio de comunicaciones electrónicas. En el Reglamento General de Protección de Datos de la Unión Europea (el “RGPD”) que entró recientemente en vigor, la obligación de notificar vulneraciones de seguridad es ahora general para todos los responsables y mandatarios, independientes del sector de la industria al que pertenezcan. Según señala el RGPD, el objetivo de esta obligación es que se tomen a tiempo medidas que permitan evitar que las vulneraciones ocasionen daños a los titulares de los datos (considerandos 85 a 87 del RGPD).

Estados Unidos, por su parte, fue pionero en esta clase de obligaciones con la California S.B. 1386 que data del 2003. A la fecha, ya se han publicado leyes de este tipo en los 50 estados, incluyendo el Distrito de Columbia. Estas leyes norteamericanas sobre notificación de brechas de seguridad difieren en varios aspectos, como el plazo de notificación, la forma de la notificación y el contenido de las mismas; sin embargo, también coinciden en otros, como que la notificación sea por regla general a los sujetos afectados y, solo bajo ciertos parámetros, a las autoridades. En Estados Unidos también existen leyes federales que contienen obligaciones sobre reporte de vulneraciones, como por ejemplo, la Ley de Transferencia y Responsabilidad de Seguro Médico (“HIPPA”) y la Ley Gramm-Leach-Bliley o Ley de Modernización de Servicios Financieros (“GLBA”).

En este contexto, desde hace algún tiempo los reguladores en la Unión Europea y en Estados Unidos han entendido que la obligación de implementación de medidas de seguridad en el tratamiento de datos personales no es suficiente como mecanismo de seguridad y que, aparentemente, habría una relación entre la obligación de notificación de una vulneración de seguridad con una disminución de los perjuicios asociados.

LA OBLIGACIÓN DE REPORTAR VIOLACIONES A LAS MEDIDAS DE SEGURIDAD EN EL PROYECTO DE LEY

El Proyecto de reforma a la ley de protección de datos chilena incorpora una nueva obligación asociada a la seguridad de datos personales para los responsables y mandatarios: la obligación de reportar vulneraciones a medidas de seguridad. Esta obligación hasta el día de hoy es desconocida en nuestro ordenamiento jurídico. En este artículo analizamos en qué consiste, cómo ha sido aplicada en otras legislaciones y cuáles podrían ser los puntos donde el actual texto del Proyecto podría mejorar.

El texto propuesto por el Proyecto es el siguiente:

“Artículo 14 quinquies.- Deber de reportar las vulneraciones a las medidas de seguridad. El responsable de datos deberá reportar a la Agencia de Protección de Datos Personales, por los medios más expeditos posibles y sin dilaciones indebidas, las vulneraciones a las medidas de seguridad que ocasionen la destrucción, filtración, pérdida o alteración accidental o ilícita de los datos personales que trate o la comunicación o acceso no autorizados a dichos datos, cuando exista un riesgo razonable que con ocasión de estos incidentes se genere un perjuicio o afectación para los titulares.

El responsable de datos deberá registrar estas comunicaciones, describiendo la naturaleza de las vulneraciones sufridas, sus efectos, las categorías de datos y el número aproximado de titulares afectados y las medidas adoptadas para gestionarlas y precaver incidentes futuros. Cuando dichas vulneraciones se refieran a datos personales sensibles o datos relativos a obligaciones de carácter económico, financiero, bancario o comercial, el responsable deberá también efectuar esta comunicación a los titulares de estos datos. Esta comunicación deberá realizarse en un lenguaje claro y sencillo, singularizando los datos afectados, las posibles consecuencias de las vulneraciones de seguridad y las medidas de solución o resguardo adoptadas. La notificación se deberá realizar a cada titular afectado y si ello no fuere posible, se realizará mediante la difusión o publicación de un aviso en un medio de comunicación social masivo y de alcance nacional.”

La incorporación de una obligación de notificación de vulneraciones a medidas de seguridad constituye un hito en la legislación nacional por ser la primera norma de este tipo de aplicación transversal. El tratamiento de grandes volúmenes de datos y la creciente amenaza en ciberseguridad hacen que la entrada en vigor de esta obligación sea una prioridad para nuestro país. No solo los derechos de las personas dependen de ello, sino que incluso la confianza en la economía digital.

El enfoque adoptado por los autores del proyecto de ley toma ciertos elementos del RGPD para construir la obligación de reporte, y agrega otros nuevos.

Entre los elementos comunes con la RGPD, encontramos el hecho que la vulneración deba ser calificada previamente: solo las que constituyan un “riesgo de perjuicio” para titulares deba ser notificada; que la notificación por regla general se haga a la autoridad administrativa (Agencia); y que la notificación deba realizarse “sin dilaciones indebidas”.

Elementos novedosos, entre otros, son la causal de notificación a los titulares de datos cuando la afectación se presente respecto de datos sensibles o comerciales; y la ausencia de normas que configuren “puertos seguros”.

El panorama de seguridad de datos personales en el proyecto de ley no se agota con la obligación de reporte, sino que se ve complementado con disposiciones adicionales: (i) la incorporación del principio de seguridad con un contenido definido; (ii) una nueva obligación de adoptar medidas de seguridad; y (iii) cláusulas relativas al cumplimiento de las obligaciones y sanciones asociadas específicamente a las medidas de seguridad.

De la revisión de la redacción propuesta en el Proyecto y de algunos antecedentes comparados, estimamos que el actual texto del artículo 14 quinquies tiene algunos aspectos que podrían ser mejorados:

COMENTARIOS Y CRÍTICAS AL TEXTO PROPUESTO EN EL PROYECTO

1. Si tanto responsables de datos como mandatarios están obligados a la misma notificación, se pueden generar dificultades en la coordinación de respuestas frente a incidentes

La regulación de datos personales estructura su régimen de obligaciones según la calidad de los involucrados: como responsables de datos o terceros mandatarios. El responsable es el principal obligado y es quien decide acerca de “los fines y medios del tratamiento de datos personales”. Por su parte, el tercero mandatario es a quien se le ha encargado hacer un tratamiento de datos en nombre de un responsable (por ejemplo, el tratamiento de datos que hace la empresa encargada de la gestión del payroll de una empresa).

El artículo 15 bis del Proyecto extiende al mandatario la obligación de reportar vulneraciones, en idénticas condiciones que el responsable de datos; debiendo notificar las vulneraciones que sufran sus sistemas directamente a la Agencia o a los titulares según sea el caso.

Sin perjuicio que es deseable que exista mayor transparencia a la hora de existir vulneraciones (sobre todo frente a responsables de datos que no quieran cumplir su obligación de reporte), una obligación de reporte idéntica para responsable y mandatario muy probablemente generará conflictos en su aplicación.

El reporte de una vulneración requiere dos calificaciones: una calificación técnica (destrucción, filtración o alteración de datos) y una calificación jurídica (riesgo razonable de perjuicios al titular). La calificación de la existencia de un riesgo razonable de prejuicios al titular debe lógicamente hacerse en consideración al tipo y calidad de datos que han sido objeto de la brecha. El encargado, en ciertas ocasiones no tiene acceso efectivo al contenido procesado. Imponerle una obligación de notificación directa de la brecha implicaría en estos casos a obligarlo a examinar el contenido de la información que procesa, lo cual puede ser impracticable técnicamente.

La existencia de dos obligados a realizar estas calificaciones sobre un mismo evento puede generar graves inconvenientes y descoordinaciones en la Agencia y en los titulares de datos, quienes pueden verse enfrentados, por ejemplo, a notificaciones contradictorias o incoherentes entre sí respecto de un mismo hecho. A nuestro juicio, el único obligado a realizar estas notificaciones es quien está en mejor posición de calificar el impacto de una vulneración, y el único que siempre tiene acceso efectivo a los datos, o sea, el responsable de datos.

Es más, la notificación de la brecha puede involucrar (como analizamos en detalle en el punto 5) la descripción de “la naturaleza de las vulneraciones sufridas, sus efectos, las categorías de datos y el número aproximado de titulares afectados y las medidas adoptadas para gestionarlas y precaver incidentes futuros”. ¿Cómo puede un mandatario que, por ejemplo, provee servicios de hosting, cumplir con esa obligación sin tener acceso directo a los datos, circunstancia que muy probablemente tiene prohibida contractualmente?  

Una aproximación razonable para este caso es la solución del RGPD, que en su artículo 33 N°2 obliga al mandatario a notificar sin dilación indebida al responsable de datos las vulneraciones de seguridad de las que tiene conocimiento. El mandatario no notifica a la autoridad ni a los titulares de datos; el responsable es quien tiene la obligación última de notificarles a ellos.

2. El destinatario de la notificación: La notificación a la Agencia y la notificación al titular de datos

A nivel comparado, las notificaciones de brechas de seguridad tienen como destinatario a los titulares de los datos y a ciertas autoridades administrativas. La predilección por sobre uno u otro destinatario se puede ver reflejada en las diferencias que existen entre la Unión Europea y Estados Unidos. En Europa se prefiere a la autoridad de control como la entidad encargada de recibir las notificaciones, dejando las notificaciones al titular para los casos en que la vulneración implica un riesgo mayor. Por su parte, en Estados Unidos la regla general es la contraria, se prefiere la notificación al afectado que, en ciertos casos, se complementa con una notificación a alguna autoridad.

El Proyecto sigue el modelo europeo adaptado con ciertos matices, donde se establece como regla general la notificación a la Agencia de Protección de Datos Personales para cualquier vulneración. Solo cuando las vulneraciones involucren datos sensibles o datos de carácter económico, la notificación además debe efectuarse a los titulares afectados.

Esta aproximación asume que las más graves afectaciones a los titulares pueden derivar de una vulneración que involucra solo esas dos categorías de datos. Esto podría parecer a priori correcto; sin embargo, excluye casos de una vulneración que afecta datos personales no sensibles y no económicos pero que, por otros elementos ajenos al tipo de dato, igualmente suponen un grave riesgo de afectación a los derechos de los titulares.

Un ejemplo de esta filtración podría ser el caso del sitio web Ashley Madison, uno de los ciberataques más notorios en último tiempo. En este caso, por una brecha de seguridad se expusieron una cantidad importante de datos personales, incluyendo correos electrónicos, nombres, nombres de usuarios, direcciones y contraseñas que identificaban a usuarios de un sitio web para concertar citas extramaritales. Estos datos no caen en la calificación del proyecto de ley, sin embargo, difícil seria decir que su vulneración no implica un grave riesgo de afectación a los titulares y que no era relevante notificarles directamente. Con el proyecto de ley, un caso similar con ese tipo de datos no desembocaría en una notificación a los titulares.

En el caso del RGPD, la notificación a los titulares no distingue entre el tipo de dato afectado, sino que se aplica para cualquier categoría de dato personal. El hecho detonante, sin embargo, es que la vulneración entrañe un “alto riesgo” para los derechos y libertades de los titulares. A nuestro juicio, esta regulación podría servir para complementar la actual obligación de notificación a los titulares que se contiene en el proyecto de ley y que, finalmente, se traduciría en mayor protección a los afectados.

3. Falta la incorporación de hipótesis de “puerto seguro” que dote de razonabilidad y eficiencia a la norma

Tanto en Estados Unidos como en Europa existen ciertos casos donde el responsable, aun cuando ha sido afectado por una vulneración, no requiere hacer una notificación.

En Estados Unidos, algunos estados no requieren que las empresas notifiquen vulneraciones si los datos afectados estaban encriptados, y las llaves de encriptación no fueron comprometidas. Ciertos estados no requieren notificación si la empresa está regulada por HIPPA o la GLBA, que contemplan requisitos propios de notificación. Por último, en ese mismo país la mayoría de las leyes sobre notificación de filtraciones de datos personales permiten a las empresas dilatar la notificación al titular si ello podría perjudicar una investigación criminal en curso.

En el caso de la Unión Europea, el RGPD establece que la notificación al titular de datos no será requerida si: (i) el responsable ha adoptado medidas de protección apropiadas y estas se han aplicado a los datos afectados, por ejemplo, encriptación; o (ii) si el responsable ha tomado medidas que garanticen que ya no existe la probabilidad de que se concrete el alto riesgo para los derechos y libertades del titular.

El Proyecto de ley no contempla escenarios de puerto seguro como los arriba señalados. De las hipótesis comentadas, se puede advertir que existen ciertos eventos donde efectivamente una notificación puede no constituir un mecanismo necesario o apropiado para combatir una vulneración a medidas de seguridad. Por ejemplo, el caso de otras regulaciones especiales que contemplen medidas de notificación similares, o aquellos casos donde el responsable ha tomado precauciones que disminuyen o eliminan el riesgo para los titulares, como cuando los datos han sido encriptados previamente.

Bajo nuestra perspectiva, la incorporación al texto del proyecto de ley de hipótesis como las señaladas podría dotar a nuestra norma de razonabilidad y eficiencia, evitando gastos innecesarios y premiando aquellos responsables que han tomado medidas de resguardo sobre los datos personales con anterioridad. Esto, considerando -sobre todo- el hecho que la aplicación de la ley de datos personales es transversal tanto para personas naturales como jurídicas, empresas de gran tamaño y Pymes.

4. ¿Bajo qué parámetros se configura la “imposibilidad de notificación al afectado” que autoriza la notificación a través de un medio de comunicación masivo?

La imposibilidad de notificación a cada afectado puede tener varios matices según la óptica desde donde se observe: puede ser una imposibilidad económica en el sentido que notificar a cada afectado puede implicar un costo prohibitivo para el responsable, o puede ser una imposibilidad fáctica por no tener datos de contacto suficientes donde dirigir las notificaciones. En este sentido, la actual redacción del artículo deja abierta la puerta a la interpretación sobre cuándo existe realmente esta “imposibilidad”.

Estamos de acuerdo con que la ley no puede ni debe contemplar el detalle de todas las obligaciones que establece, para ello existe el mecanismo del reglamento y la jurisprudencia. En este caso, nuestra sugerencia es optar por un criterio mixto: que la ley establezca ciertas hipótesis amplias de imposibilidad para dar mayor claridad y precisión a la norma, y que la Agencia complemente o genere nuevas hipótesis de imposibilidad derivadas del caso a caso y de los cambios tecnológicos.

Por último, y asociado a los costos de notificar, creemos que sería adecuado establecer expresamente la posibilidad de efectuar notificaciones por medios electrónicos en la medida que fuera posible contactar a los afectados por ese medio. Esto permitirá reducir considerablemente los costos de esta gestión, pudiendo alcanzar un gran número de titulares en un plazo reducido de tiempo.

5. Inciso segundo del artículo 14 quinquies ¿contenido de la notificación o contenido del registro de la notificación?

De la lectura del artículo que dispone la obligación de reporte entendemos que el primer inciso establece la hipótesis que gatillará la notificación de la vulneración, y el segundo, la obligación de llevar un registro de las notificaciones. Si esto dispone el legislador, es válido preguntarse entonces ¿qué información tiene que contener la notificación a la Agencia?, ¿la información que el inciso segundo dice que se debe registrar?, ¿una información diferente? en este último escenario ¿cuál?

Dado que no hay una mención clara al contenido, lo más lógico sería estimar que la notificación debería contemplar la información que señala el inciso segundo; sin embargo, esta norma señala “El responsable de datos deberá registrar estas comunicaciones”, lo cual en estricto español nos lleva a pensar en que este registro es posterior y distinto al evento “notificación”.

El contenido de la notificación en una vulneración de seguridad es un elemento esencial que debe estar claramente definido con anterioridad. Si la intención del legislador era que la notificación comprendiere los elementos de inciso segundo y que -al mismo tiempo- el responsable mantenga un registro de ello para verificaciones posteriores, nuestra sugerencia es un texto que lo diga expresamente. Una alternativa podría ser la siguiente:

El contenido de esta notificación será una descripción sobre la naturaleza de las vulneraciones sufridas, sus efectos, las categorías de datos y el número aproximado de titulares afectados y las medidas adoptadas para gestionarlas y precaver incidentes futuros. El responsable deberá llevar en un registro los antecedentes contenidos en cada notificación.

Ahora bien, en cuanto al contenido propiamente tal, creemos que hay algunos elementos que podrían incorporarse para mejorar la información que reciba a la Agencia. En el caso estadounidense, el contenido habitual de las notificaciones involucra información de contacto del responsable y la fecha o fechas de la vulneración. En el caso específico del Estado de California, la notificación requiere, entre otras cosas, adjuntar un modelo de notificación para los titulares de datos, la fecha en que la vulneración fue descubierta, la fecha de notificación a los titulares, señalar si la vulneración se ha comunicado a la prensa, señalar si la vulneración se ha comunicado o no a las policías, etc.

A nuestro juicio, estos podrían ser elementos útiles a considerar a la hora de sistematizar los mecanismos de notificación de vulneraciones, una tarea que necesariamente deberá efectuar la Agencia una vez se encuentre constituida.

CONCLUSIONES

La nueva obligación de reportar vulneraciones a las medidas de seguridad adoptadas para el tratamiento de datos constituye una incorporación normativa importante y necesaria. El contexto tecnológico y de amenazas de ciberseguridad hacen que la promulgación de una norma de este tipo sea sumamente apremiante.

De acuerdo a lo observado, hay varios elementos que fueron tomados por el legislador de lo que hizo su par europeo en el RGPD, y que nos parecen constituir un buen punto de partida.

Ahora bien, hay elementos que podrían ser mejorados o precisados para tener una mejor y más clara obligación. Dada la novedad que esta norma constituye en nuestro ordenamiento y la importancia que reviste para responsables, mandatarios y titulares, es necesaria una obligación clara y realista.

El ataque informático que afectó al Banco de Chile demostró la importancia de la ciberseguridad. Esta institución habría experimentado una filtración en sus sistemas de parte de una banda delictiva de hackers internacionales, haciendo que rápidamente se activaran los protocolos de contingencia respectivos. Se bajaron los sistemas para proteger a los clientes del banco, acción que mostró los avanzados resguardos informáticos de esta organización. Sin embargo, el supuesto ataque fue mucho más sofisticado y operó como una pantalla para despistar el verdadero objetivo, que no era otro que las reservas financieras del banco, dinero que usualmente se invierte en otros países. Una operación delictiva de esta magnitud nunca se había visto en Chile, lo que nos obliga a plantearnos nuevos desafíos sobre la ciberseguridad.

Recientemente, un estudio de la OEA señaló que estos “ataques” en México implican un costo de entre US$ 3 mil y US$ 5 mil millones anuales. Es tal la magnitud de este tipo de hechos delictivos, que el Banco de México anunció la creación de la Dirección de Ciberseguridad para fortalecer el desarrollo seguro de sus sistemas.

Es importante señalar que Chile ocupa el puesto 81 en el ranking de países preparados para enfrentar ciberataques. Este listado, realizado por la Unión Internacional de Telecomunicaciones (UIT) de la ONU, evaluó a 165 países, tomando atención en temas como la estabilidad de instituciones jurídicas y técnicas, además de sus redes de intercambio de información. Desde otra visión, el informe “Civilidad, Seguridad e Interacción Online”, aplicado por Microsoft en 23 países, reveló que en 2017 tres de cada cuatro chilenos han experimentado algún tipo de riesgo virtual, es decir, el 73% de los usuarios de internet en Chile.

Los esfuerzos para promover la ciberseguridad como un tema a nivel país deben enfocarse desde una prioridad que no sólo atañe al sector privado, sino también al Estado y a todos los ámbitos de la sociedad. Un ejemplo de ello es la reciente creación de la Alianza Chilena de Ciberseguridad, que busca promover el desarrollo de la ciberseguridad en el país a través del uso responsable de las tecnologías, además de incentivar esfuerzos para posicionar a Chile como un referente latinoamericano en esta materia.

Chile, según la Subsecretaría de Telecomunicaciones, tiene la mayor tasa de penetración de internet (70%) en América Latina. Esto significa que más de 12 millones de personas están en riesgo de experimentar fraudes informáticos. Este antecedente demuestra que la ciberseguridad tiene que ser un tema prioritario y para ello son esenciales acciones como la incorporación de nuevas obligaciones de seguridad en la Ley de Protección de Datos Personales. Esta norma, en discusión en el Senado, introduce importantes obligaciones en temas de ciberseguridad relacionadas con el establecimiento de mayores estándares en la protección de datos. En resumen, se exige que las empresas adopten medidas de seguridad sobre sus sistemas que sean coherentes con el tipo de datos que tratan y el riesgo de su pérdida o filtración; además de notificar a la autoridad (y en ciertos casos a los propios titulares) la violación de dichas medidas.

Estamos viviendo importantes cambios a partir de nuevos paradigmas, los que también están modernizando la forma en que operan las organizaciones delictuales. Por ello, la ciberseguridad también debe ser nuestro norte. Debemos continuar la incorporación de regulaciones, procesos, personal y tecnología necesarios para hacer frente a las amenazas que hoy son una posibilidad concreta en el terreno de la ciberseguridad.

Con el auge de Internet y la capacidad de los criminales de aprovecharse de nuevas y sofisticadas herramientas tecnológicas, la ciberseguridad ha dejado de ser un tema exclusivo de grandes corporaciones, para convertirse en un asunto de seguridad nacional, afectando a los ciudadanos y empresas de todo tamaño.

Si bien los gobiernos de algunos países ya habían puesto sus ojos en los ataques cibernéticos desde mucho antes que Internet fuese tan popular, hacía falta un tratado internacional que permitiera conocer contra qué podemos vernos enfrentados. El objetivo principal de este tratado es armonizar todas las legislaciones internas para que tipifiquen de manera similar las mismas conductas delictivas y establecer formas eficaces de actuar en conjunto; pues como bien sabemos, el cibercrimen no tiene fronteras.

Bajo esa premisa nació el Convenio de Budapest, también llamado Convenio sobre la Ciberdelincuencia. Hoy conoceremos su origen, en qué consiste, sus objetivos y qué  tanto importa en Latinoamérica el tema de la ciberseguridad.

Orígenes y objetivos

Aunque el Convenio de Budapest se firmó en noviembre de 2001, podemos remontar los intentos de la lucha contra la ciberdelincuencia a 1996, cuando el Comité Europeo para los Problemas Criminales decidió crear un equipo especializado que se dedicara a una nueva rama de crímenes: los delitos informáticos.

El tratado que resultó es la primera herramienta en el mundo en establecer lineamientos claros para enfrentar delitos a través de Internet y aunque nació como una iniciativa europea, nunca fue excluyente, impulsándola a ser aceptada en todo el mundo.

El lineamiento más importante consiste en que cada país miembro debe implementar leyes para combatir ciberdelitos como la piratería, la pornografía infantil, y la violación de propiedad intelectual, entre otros, así como también exige acciones concretas por parte de las autoridades —como la policía— para perseguir a los criminales. Los países miembros deben estar dispuestos también a cooperar con otros para que la lucha sea más efectiva, fomentando el intercambio de información y pruebas.

El Convenio, a septiembre de 2018, lo han ratificado ya 61 estados, destacándose la mayoría de los estados europeos y América del Norte. Sin embargo, varios países han mostrado reticencia en hacer parte de un organismo como éste. Entre ellos están Brasil, India y Rusia, alegando que una de las bases del tratado, la de compartir información, viola su soberanía.



Aun así, tanto India como Brasil han mostrado la disposición de aceptar estas condiciones, a diferencia de Rusia, país que suele ser reticente para colaborar con autoridades internacionales en investigaciones relacionadas con el cibercrimen.

En 2006 se agregó un Protocolo Adicional en el que se requiere la criminalización de amenazas e insultos difundidos en Internet que tengan origen en el racismo y la xenofobia, así como de quienes distribuyan material de este tipo.

¿Cómo están la leyes de ciberseguridad en América Latina?

Sólo seis países de la región son miembros del Tratado de Budapest (Argentina, Chile, Costa Rica, Paraguay, República Dominicana y Panamá), en otros tres ya lo han ratificado, pero no han formalizado aún su ingreso (Colombia, México y Perú) y varios más están buscando ingresar, como es el caso de El Salvador y Uruguay.

En cuanto a la legislación, en Chile ya había una ley de delitos informáticos, creada en 1993, que sanciona cuatro tipos de conductas: la destrucción de sistemas informáticos, la interceptación o acceso sin permisos, la destrucción de datos de un sistema informático y la difusión de datos privados. Desde su publicación esta ley no ha sufrido modificaciones. Chile adhirió al Convenio de Budapest en abril de 2017; y se encuentra pendiente su obligación de ajustar a nuestra legislación interna los compromisos ahí adquiridos. Esta adaptación debiera cumplirse en las próximas semanas con el envío al Congreso del proyecto de ley que modifica la Ley de Delitos Informáticos, cuyo envío ha sido anunciado como inminente por el Ministerio del interior -trámite que se vio acelerado a raíz de las numerosas filtraciones de datos sensibles que hemos vivido en los últimos meses.

En Colombia, el Congreso ratificó el ingreso del país al convenio en junio pasado y sólo hace falta la firma del Presidente y el visto bueno de la Corte Constitucional. Además, para adecuarse a los lineamientos del tratado, el país ha propuesto la creación de una red operativa que permita la identificación y persecución efectiva de cibercriminales.

Cabe destacar, que aunque muchos países de la región no estén en el convenio, América Latina siempre ha estado, en su mayoría, muy dispuesta a la colaboración internacional en temas de ciberseguridad debido a la influencia de Estados Unidos. Pero si el cibercrimen es en realidad una cuestión de seguridad nacional, formalizar el ingreso de los países de la región a este convenio es una prioridad que nos permitirá estar mejor parados frente a ataques internacionales.

Entendiendo que la ciberseguridad es un tema que abarca a personas, procesos y tecnologías, en un esfuerzo continuo para disminuir el riesgo de un ciberataque, los controles y herramientas tradicionales ya no son suficientes en el actual entorno de digitalización.

Vemos así como las organizaciones han empezado a idear enfoques integrales que les permiten planificar el accionar de sus equipos de trabajo en diversas áreas, adaptarlos a las necesidades tecnológicas y, de igual manera, proteger la infraestructura crítica del negocio.

En esta oportunidad abordaremos la Ciber Resiliencia, uno de los enfoques clave dentro de una estrategia de ciberseguridad proactiva.

¿Qué es la Ciber Resiliencia?

La Ciber Resiliencia es un enfoque de ciberseguridad que consiste en la planificación y medición de acciones cuyo objetivo es permitir el correcto funcionamiento de los servicios y la infraestructura de una organización durante una crisis de seguridad.

Por definición, la Ciber Resiliencia tiene en cuenta todo lo que pasa antes, durante y después de una emergencia; esta ayuda a evitar problemas como las caídas reportadas de varios portales de ecommerce durante el Ciberlunes el año pasado en EEUU, la falta de cumplimiento en la entrega de servicios ante una falla en la base de datos, o la falta de facturación debido a un ransomware que afecte el ERP.

Es por tales razones que, para que sea efectivo al momento de lidiar con una brecha de seguridad, este enfoque necesita partir de un entendimiento profundo de los riesgos potenciales que enfrenta la organización que a su vez están basados en la comprensión misma de la empresa. Para ello es clave el análisis detallado de todos los procesos que hagan uso de la tecnología, así como de las personas que la manejan.

La planificación llevada a cabo requiere hacer un análisis de los procesos fundamentales que permiten el correcto funcionamiento del negocio y las áreas en donde los riesgos pueden impactar de manera perjudicial la disponibilidad de servicios, la protección de datos y la integridad de la infraestructura.

El objetivo es permitir el correcto funcionamiento de los servicios y la infraestructura de una organización durante una crisis de ciberseguridad.
Mediante el conocimiento de estos procesos, necesidades y riesgos, la organización que adopta un enfoque de Ciber Resiliencia tiene la capacidad de conocer qué tecnologías debe implementar en un mediano o largo plazo. Adicionalmente, la compañía puede comprender la importancia de equipos especializados para la prevención de ciberataques como son los CSIRT y SOC, además de obtener información y recursos de equipos CERT.

Si quieres conocer más sobre ellos, en este artículo explicamos con mayor detalle las implicaciones de estos equipos en una organización.

Herramientas tradicionales vs. Ciber Resiliencia

La mayoría de las empresas observa la seguridad de una forma focalizada, por lo que sus principales preocupaciones se centran en la adquisición de soluciones de software para afrontar ciberataques.

Sin embargo, con el auge y uso masificado de tecnologías disruptivas como la Inteligencia Artificial e Internet de las Cosas, los criminales encuentran vulnerabilidades más fácilmente, afectando la infraestructura crítica directamente y haciendo que las soluciones tradicionales sean incapaces de enfrentarlos.

Varios ejemplos de la incapacidad de las soluciones de ciberseguridad tradicionales se han hecho particularmente visibles con los ataques de NotPetya, un virus que inactivó cajeros automáticos y cajas de supermercados en toda Ucrania en 2016 y 2017. El hecho fue de tal magnitud que se especula que fue un ataque coordinado desde Rusia. Otro ejemplo es el ransomware WannaCry, que dejó una buena cantidad de centros de salud y hospitales en el Reino Unido sin acceso a los datos de sus pacientes.

Y es que aunque los firewalls, anti-malware y sistemas anti-intrusiones siguen siendo necesarios para proteger la integridad de las infraestructuras de TI, no son suficientes. Así un enfoque de Ciber Resiliencia cobra relevancia no solo para centralizar los esfuerzos de la compañía por mantener fuera a los cibercriminales, sino para que, asumiendo su capacidad para vulnerar un sistema, disminuya el impacto de los ataques y se asegure la supervivencia de la organización.

La importancia de las copias de seguridad

Los ciberataques en Ucrania y el Reino Unido, también han puesto en evidencia la importancia de las copias de respaldo, una de las herramientas de las que se vale la Ciber Resiliencia para permitir la continuidad de las operaciones. Las copias de seguridad, tan reconocidas que muchas veces se pasan por alto, permiten la restauración de datos en un tiempo relativamente corto para que los servicios sigan activos mientras se soluciona la emergencia.

Si bien una empresa se ve beneficiada directamente mediante la Ciber Resiliencia, ésta puede considerarse como un bien común, pues teniendo en cuenta que una organización aprende con las experiencias de otra, las colaboraciones y alianzas son un elemento clave dentro de este enfoque.

A modo de ejemplo, en Soluciones Orión acabamos de firmar una alianza estratégica con Rubrik, empresa especializada en Cloud Data Management, que permitirá fortalecer la Ciber Resiliencia de las empresas con ayuda de Inteligencia Artificial. Cabe destacar que la importancia de estas alianzas y su impacto, pueden ser de carácter privado o darse entre empresas, entes reguladores y el Gobierno.

Por último, tanto el Directorio como el Gerente General deben ser los encargados de que la organización cuente con estrategias de Ciber Resiliencia, ya que aunque estas iniciativas pueden surgir desde las áreas de TI o soporte, es muy difícil que allí se generen estrategias para enfrentar ciberriesgos de una manera oportuna y efectiva.

Fuentes:

Luego de los incidentes de ciberseguridad que han afectado a la industria financiera en Chile, la Superintendencia de Bancos e Instituciones Financieras (SBIF) modificó los Capítulos 20-8 y 1-13 de la RAN el pasado 31 de agosto, con el objetivo de contar con más y mejor información sobre incidentes, y elevar los estándares de seguridad del sistema financiero.

Los Capítulos 20-8 y 1-13 ya contenían normas relativas a la gestión de la ciberseguridad por parte de las instituciones reguladas por la SBIF, las que fueron establecidas en enero de este año. En esa modificación se incluyeron ciertos lineamientos mínimos en ciberseguridad, como la exigencia de generar y mantener una base de incidentes a disposición de la Superintendencia.

Modificaciones al Capítulo 20-8 sobre Información de incidentes operacionales

La modificación al Capítulo 20-8 implica un robustecimiento de la actual obligación de comunicación de incidentes a la SBIF; el establecimiento de una nueva obligación de comunicación de incidentes a clientes y a la industria; y la eliminación de la actual sección N°2 que hasta ahora regulaba la base de incidentes de ciberseguridad.

A continuación, un breve análisis de estos nuevos elementos:

  1. Comunicación de incidentes operacionales a la SBIF
    Se precisan los tipos de incidentes operacionales que deben ser comunicados; y se detalla su oportunidad, contenido y mecanismos de comunicación.

    Qué se debe reportar. Deberán reportarse a la SBIF los incidentes operacionales que afecten o pongan en riesgo la continuidad del negocio, los fondos o recursos de la entidad o de sus clientes, la calidad de los servicios o la imagen de la institución. También deberán informarse los incidentes que afecten a un grupo de clientes que puedan impactar la imagen y reputación de la entidad en forma inmediata, o con posterioridad a ocurrido un determinado evento1. Cuándo se debe reportar. La primera comunicación a la SBIF, la ocurrencia de un incidente operacional, debe efectuarse en un plazo máximo de 30 minutos.

    Cómo se debe reportar. En relación al acto de comunicación del incidente, se reemplaza la actual comunicación única al correo electrónico de la SBIF por una obligación más detallada que considera dos comunicaciones a la casilla habilitada por la SBIF en su Extranet, una al inicio del incidente y otra al momento de su cierre.

    Qué debe incluir el reporte. La modificación detalla las materias que debe contener esta comunicación2, requiriendo: (i) número único identificador del incidente (asignado por la SBIF); (ii) nombre de la entidad informante; (iii) descripción del incidente; (iv) fecha y hora de inicio del incidente; (v) causas posibles o identificadas; (vi) productos o servicios afectados; (vii) tipo y nombre de proveedor o tercero involucrado (si corresponde); (viii) tipo y número estimado de clientes afectados; (ix) dependencias y/o activos afectados (si corresponde); (x) medidas adoptadas y en curso; y (xi) otros antecedentes.

    Si bien estos son los requisitos mínimos que han de incluirse en la comunicación del incidente, la misma norma señala que, para efectos de poder cumplir con el plazo, no contar con la información requerida “no debe ser impedimento para el envío de la comunicación dentro del plazo definido”.

    La comunicación de cierre del incidente debe hacer referencia a los mismos aspectos requeridos para la comunicación de inicio, agregado solamente la “fecha de cierre del incidente”.

    Vigencia. Por último, de acuerdo a las disposiciones transitorias establecidas en la Circular N° 3.640 de la SBIF del 31 de agosto de 2018 (la “Circular 3.640”), el envío de información sobre incidentes operacionales a través de la Extranet rige a partir del 16 de octubre de 2018. En el intertanto, deberán seguir utilizando el correo electrónico habilitado para ese fin.

  2. Comunicación de incidentes a los clientes o usuarios

    Se establece una nueva obligación de reporte hacia los clientes de las instituciones afectadas, respecto de cierta clase de incidentes.

    Qué se debe reportar. El “tipo” de incidente que la gatilla la obligación de reporte a los clientes es distinta que el incidente que genera una obligación de reporte a la SBIF. Para que la institución esté obligada a notificar al usuario, el incidente debe necesariamente “afectar la calidad o continuidad de los servicios a los clientes o se trate de un hecho de público conocimiento”. Luego, ante incidentes que generen efectos de naturaleza diversa, la institución puede llegar a tener la obligación de comunicar tanto a la SBIF como a sus clientes.

    En la Circular 3640 se establece que la notificación a los usuarios también deberá efectuarse cuando los incidentes afecten “la seguridad de los datos personales de los clientes”, circunstancia que finalmente no fue contemplada en el texto actualizado del capítulo 20-8.

    Si bien el texto primitivo del capítulo 20-8 ya contemplaba como un tipo de incidente a reportar a SBIF las “fugas de información del banco o de clientes”, donde puede entenderse comprendida la frase en comento, la referencia expresa a la seguridad de los datos personales de los clientes nos parece más adecuada, y además obliga a los bancos a notificar a los clientes afectados por el incidente en cuestión. Para efectos de seguridad jurídica, puede ser adecuado que la SBIF aclare esta inconsistencia.

    Cuándo se debe reportar. La norma establece que la institución será responsable de informar “oportunamente” a los usuarios. Por último, se establece una obligación adicional de ir actualizando la información disponible hasta el momento en que el incidente sea superado.

    Cómo se debe reportar. En la práctica, será relevante entender si es suficiente para cumplir esta obligación realizar un aviso general al público, o se requerirá que cada usuario sea notificado individualmente; y si esta comunicación podrá ser efectuada a través de Internet o tendrá que efectuarse a través un medio físico, como una carta a un domicilio.

    Qué debe incluir el reporte. Se debe informar a los usuarios sobre la ocurrencia del evento, actualizando la información disponible hasta el momento en que el incidente sea superado.

  3. Comunicación de incidentes a la industria bancaria.
    La modificación establece que los incidentes asociados a ciberseguridad han de ser compartidos por los bancos afectados con el resto de la industria; con el objetivo de prevenirlos de las amenazas en ciberseguridad y disminuir la probabilidad de que impactos negativos se propaguen en el sistema financiero nacional.

    Para este fin, la norma indica que los bancos deben mantener un “sistema de alertas de incidentes” en el que se deberá reportar “en el más breve plazo posible”, como mínimo: (i) una descripción del tipo de amenazas; (ii) los canales o servicios afectados; y, cuando la información se encuentre disponible, (iii) la caracterización o identificación del software malicioso utilizado y de los mecanismos de protección que se hayan identificado. El sistema implementado debe considerar el acceso por parte de la SBIF a la información compartida.

    De acuerdo a las disposiciones transitorias de la Circular N° 3.640, los bancos deberán tener habilitado su sistema de intercambio de información a más tardar el 5 de noviembre de 2018.

  4. Se elimina la sección N°2 sobre base de incidentes de ciberseguridad

    Las modificaciones publicadas prescinden de la mantención de una base de incidentes como lo hacía la norma antes de estas modificaciones. A este respecto, la Circular N° 3.640 señala que los elementos que se evalúan en el ámbito de riesgo operacional se traspasan al Capítulo 1-13 de la RAN.

    Por su parte, las variables mínimas a considerar en la elaboración de una base de incidentes ahora serán parte de un archivo del Manual de Sistema de Información, el que se encuentra en consulta pública en el sitio web de la SBIF hasta el 5 de octubre de 2018.

Modificaciones al Capítulo 1-13 sobre Clasificación de gestión y solvencia

Estas modificaciones se agregan a las ya establecidas en el Capítulo 1-13 de la RAN en su Letra C) del Numeral 3.2 del Título II Sobre Administración Del Riesgo Operacional. Sin embargo, de acuerdo a lo señalado anteriormente, estas agregaciones obedecen principalmente a elementos que ya estaban anteriormente considerados en el Capítulo 20-8 de la RAN y que fueron introducidos en enero del 2018.

La principal novedad corresponde a que ahora, un elemento que revela una buena gestión del riesgo, corresponde al hecho que la entidad cuenta con una base de incidentes de ciberseguridad que contempla los campos solicitados en el archivo del Manual de Sistema de Información de la SBIF. Este Manual es aquel al cual nos referimos anteriormente y que se encuentra en consulta pública hasta el 5 de octubre de 2018.


1 Se agrega también una enumeración no taxativa de incidentes que entran en esta categoría, incluyendo, entre otros, fallas en el servicio de proveedores críticos o problemas tecnológicos que afecten la seguridad de la información.

2 El Capítulo 20-8 de la RAN requería originalmente los siguientes datos: (i) nombre de la entidad informante; (ii) datos de persona encargada; (iii) fecha y hora de inicio del evento; (iv) explicación del incidente; (v) proveedores involucrados; y (vi) estimación de tipo y número de clientes afectados.

otras opiniones