Seguridad y respuesta a incidentes

Llamamos incidente de seguridad a todo suceso que atente contra la confidencialidad, la integridad o la disponibilidad de los datos que conservamos. Esto abarca, en particular:

• Un acceso no autorizado: alguien consulta datos sin tener derecho a ello (cuenta comprometida, clave de acceso sustraída, vulnerabilidad explotada).
• Una pérdida de datos: determinados datos resultan irrecuperables, por supresión accidental o por fallo técnico.
• Una alteración: los datos se modifican sin autorización o de forma incontrolada.
• Una divulgación: los datos quedan visibles para personas que no deberían haberlos visto.

Esto vale tanto para los datos de los comerciantes que utilizan LIORA como para los de sus propios clientes, a los que la aplicación accede para funcionar.

Una interrupción del servicio que no haga inaccesible ningún dato, y que no lo exponga ni lo altere, corresponde al soporte y no a la presente política. En cambio, una avería que impida de forma duradera el acceso a sus datos sí constituye un menoscabo de su disponibilidad: esta sí se trata aquí.

Esta distinción determina todo lo que sigue y, en particular, a quién corresponde avisar a la autoridad de control.

• Sus datos de cuenta y de facturación: Hugo BILLAUX EI es el responsable del tratamiento. Las obligaciones de notificación le incumben.
• Los datos de los clientes de su tienda: Hugo BILLAUX EI actúa por cuenta de usted, en calidad de encargado del tratamiento. Usted sigue siendo el responsable del tratamiento y le corresponde a usted notificar a la autoridad de control si una violación así lo exige. Nuestro papel es alertarle y prestarle asistencia.

Escriba a direction@liora-eu.com describiendo lo que haya constatado y, si es posible, cómo reproducirlo. Esta dirección la consulta personalmente el empresario que explota LIORA.

Acusamos recibo, a más tardar, el día hábil siguiente a la recepción de su mensaje. Este compromiso se refiere al acuse de recibo, no a la resolución: el plazo de corrección depende de la naturaleza del incidente, y no fijamos de antemano un plazo que no pudiéramos cumplir.

Si es usted investigador de seguridad, puede comunicarnos una vulnerabilidad en esa misma dirección. No ofrecemos ningún programa de recompensas y no emprenderemos acción legal alguna contra quien nos comunique de buena fe un fallo sin haberlo explotado más allá de lo necesario para demostrarlo. Este compromiso solo vincula a Hugo BILLAUX EI y no puede obstaculizar el ejercicio de la acción penal pública.

La evaluación la realiza el empresario que explota LIORA, quien asume igualmente la responsabilidad técnica del servicio. No hay equipo de guardia: es la consecuencia de nuestro tamaño, y preferimos escribirlo antes que hacer creer en una organización que no existe.

Iniciamos la calificación en cuanto tenemos conocimiento de la comunicación y la llevamos a cabo con la mayor rapidez que el incidente permita. No fijamos ningún plazo: depende de lo que haya que examinar. Tres criterios la guían:

• La naturaleza de los datos afectados: datos de cuenta, datos de facturación, datos de los clientes de un comerciante.
• El alcance: una cuenta, varias o la totalidad del servicio.
• El riesgo para las personas: lo que alguien podría hacer con los datos en cuestión (suplantación de identidad, captación comercial, perjuicio económico).

Cada incidente se clasifica en uno de tres niveles de gravedad, que determinan la prioridad de la corrección:

• Nivel 1 — crítico: violación confirmada o seriamente sospechada de datos personales, compromiso de un acceso de administración o de un secreto, o menoscabo de datos de tienda obtenidos a través de Shopify. Contención inmediata, suspensión de cualquier otra tarea y notificaciones en los plazos descritos más abajo.
• Nivel 2 — alto: vulnerabilidad explotable sin indicio de explotación, o avería que impide de forma duradera el acceso a los datos. Corrección prioritaria y búsqueda de cualquier señal de explotación, que haría pasar el incidente al nivel 1.
• Nivel 3 — moderado: suceso sin menoscabo de los datos (intento bloqueado, defecto de configuración sin exposición, vulnerabilidad teórica). Corrección planificada.

El nivel asignado se eleva en cuanto los hechos lo exigen. Las notificaciones no dependen de él, sino de los hechos: una simple sospecha que afecte a datos obtenidos a través de Shopify basta para avisar a Shopify, sea cual sea el nivel.

En cuanto se confirma un incidente, y antes de buscar su causa, tratamos de detenerlo:

• Revocación de los accesos comprometidos: cierre de las sesiones afectadas, desactivación de las cuentas implicadas.
• Rotación de los secretos: renovación de las claves de acceso y de los tokens que hayan podido quedar expuestos, incluidas las credenciales de las que disponemos en nuestros proveedores técnicos.

Viene después la corrección, una vez detenida la hemorragia:

• Corrección: se identifica la causa, se corrige y después se despliega.
• Verificación: reproducimos el escenario del incidente para comprobar que ya no funciona.

Cortar un acceso comprometido prevalece siempre sobre la continuidad del servicio: si hay que interrumpir una funcionalidad para detener una fuga, la interrumpimos.

En cuanto se sospecha un incidente, y antes de cualquier corrección que pudiera borrarlos, preservamos los elementos que permiten establecer los hechos: registros, marcas de tiempo, archivos y mensajes en cuestión. Solo sirven para analizar el incidente y responder a las autoridades, y no se conservan más allá del tiempo durante el cual el incidente figura en el registro.

Cuando la violación de la seguridad de los datos personales afecta a datos de los que Hugo BILLAUX EI es responsable del tratamiento —cuenta, facturación—, la notificamos a la CNIL a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que entrañe un riesgo para los derechos y libertades de los interesados (artículo 33 del RGPD). Si en ese plazo no se dispone de toda la información, notificamos lo que sabemos y lo completamos después.

Cuando la violación afecta a los datos de los clientes de un comerciante, informamos a ese comerciante sin dilación indebida, conforme al artículo 33.2 del RGPD. Es entonces a él, responsable del tratamiento, a quien corresponde decidir sobre la notificación a la autoridad de control. Nuestro mensaje indica la naturaleza de la violación, las categorías de datos afectados, las consecuencias probables y las medidas ya adoptadas, para que pueda decidir con conocimiento de causa.

Cuando la violación pueda entrañar un alto riesgo para los interesados, estos son informados de ella (artículo 34 del RGPD). Tratándose de los datos de cuenta, esa comunicación nos incumbe. Tratándose de los clientes de un comerciante, incumbe al comerciante, único responsable del tratamiento y único que mantiene la relación con ellos: nosotros le facilitamos los elementos necesarios (artículo 28.3.f).

Cuando el incidente afecta, o puede afectar, a datos de tienda obtenidos a través de Shopify, avisamos a Shopify en las 24 horas siguientes al momento en que tenemos conocimiento de él, desde la simple sospecha y sin esperar al final de la calificación, como exigen sus condiciones de uso de la API.

No publicamos ningún anuncio público sobre un incidente mientras el fallo no esté corregido, para no indicar a otros cómo explotarlo. Esta reserva no retrasa ni la notificación a la autoridad de control, ni la información a los comerciantes, ni la de los interesados, ni la de Shopify.

Todo incidente se consigna en un registro interno, incluso cuando no da lugar a ninguna notificación. El registro indica la fecha de descubrimiento, los hechos, los datos afectados, la calificación adoptada, las medidas tomadas y, en su caso, las notificaciones enviadas —a la autoridad, a los comerciantes, a los interesados y a Shopify—, con su fecha.

Este registro se lleva en virtud del artículo 33, apartado 5, del RGPD, que obliga a documentar toda violación de la seguridad de los datos personales para que la autoridad de control pueda verificar el cumplimiento de estas obligaciones. Se pone a disposición de la autoridad de control cuando esta lo solicita.

Una vez cerrado el incidente, buscamos qué lo hizo posible, y no quién es responsable de él. La pregunta es siempre la misma: ¿qué permitió que esto ocurriera y qué impedirá que vuelva a ocurrir?

La corrección no se detiene, por tanto, en el defecto en sí: cuando es posible, añadimos un control automático que falla si el defecto reaparece, de modo que la misma causa no pueda producir dos veces el mismo incidente.

Estas son las medidas que protegen sus datos de forma permanente. Solo mencionamos las que están efectivamente implantadas.

• Cifrado en tránsito: todas las conexiones al sitio, a la aplicación y al servicio de inicio de sesión pasan por HTTPS, cuyo uso se impone a los navegadores (HSTS).
• Cifrado en reposo: la base de datos de la aplicación, que contiene también los archivos que usted sube a ella, está cifrada por su proveedor de alojamiento; los demás archivos de la aplicación se conservan en espacios de almacenamiento privados y cifrados. Los tokens de acceso a las tiendas Shopify están además cifrados por la propia aplicación (AES-256-GCM), con una clave conservada fuera de la base de datos.
• Compartimentación por empresa: en la base de datos de la aplicación, cada dato pertenece a una empresa, y es la propia base de datos la que se niega a mostrar a una empresa los datos de otra (seguridad a nivel de fila).
• Acceso restringido: la base de datos de la aplicación solo es accesible desde una lista de direcciones autorizadas, y la aplicación se conecta a ella con un rol de derechos limitados, distinto del que modifica su estructura.
• Contraseñas e inicio de sesión: las contraseñas se conservan con hash; la autenticación de dos factores se ofrece a cada cliente y se impone a cada miembro de nuestro equipo; el número de intentos de inicio de sesión está limitado; restablecer la contraseña cierra todas las sesiones abiertas en el sitio, pero no una sesión ya abierta en la aplicación, que termina por sí sola al expirar.
• Trazabilidad: cada acción de nuestro equipo sobre una cuenta de cliente queda registrada —autor, acción, fecha— y se conserva tres años; en la aplicación, el registro de actividad refleja quién ha hecho qué, y cada exportación de datos personales deja constancia en él.
• Copias de seguridad: su proveedor de alojamiento realiza automáticamente cada día una copia de seguridad de la base de datos de la aplicación, y estas copias están cifradas.
• Alojamiento en Europa: la aplicación y sus datos están alojados en Francia; el sitio se ejecuta en París y su base de datos se encuentra en Fráncfort.
• Organización: el acceso a las herramientas de administración está reservado a las personas habilitadas, cada una limitada a las pestañas necesarias para su cometido y en modo de solo lectura si no tiene que actuar; estas personas están sujetas a un deber de confidencialidad.

Los plazos de conservación y el papel de cada uno de nuestros proveedores se describen en nuestra Política de privacidad; los compromisos que asumimos respecto de los datos de sus clientes, en nuestro Acuerdo de encargo del tratamiento de datos.

Una política de seguridad vale por lo que cumple. He aquí, pues, lo que Hugo BILLAUX EI no tiene a día de hoy:

• Ninguna guardia 24/7: una comunicación enviada un domingo por la noche no se lee hasta el siguiente día hábil.
• Ningún centro de supervisión: no tenemos un equipo que vigile de forma permanente.
• Ninguna certificación: ni ISO 27001, ni SOC 2, ni equivalente. No reivindicamos ninguna.
• Ningún programa de recompensas: las comunicaciones de vulnerabilidades son bienvenidas, pero no se remuneran.
• Ninguna tasa de disponibilidad garantizada: estamos sujetos a una obligación de medios, sin tasa de disponibilidad, como precisan nuestras Condiciones generales de venta.

Lo descrito más arriba, en cambio, es lo que hacemos realmente. Esta página se actualizará si nuestros medios cambian.