FAQ: Seguridad de Software

Lokad es, ante todo, un especialista en supply chain y nuestro objetivo principal es ofrecer decisiones superiores de supply chain a través de la genialidad tecnológica. Dicho esto, manejamos datos financieros importantes a diario, por lo que la seguridad de nuestra plataforma de software es una prioridad y la tratamos con la máxima seriedad. En lugar de abordar la seguridad como algo secundario que se gestiona mediante la burocracia, creemos firmemente en un enfoque basado en principios que enfatiza la planificación y la proactividad - evidenciado por nuestro diseño específico de software, las decisiones de contratación y las opciones de capacitación.

Público objetivo: El departamento de TI
Última modificación: 21 de septiembre de 2023

Principios de seguridad

Una de las ilusiones más dañinas en los círculos de software empresarial es la idea de que la seguridad se puede abordar con listas de verificación de cumplimiento, certificaciones y, más en general, todo tipo de trámites burocráticos. Desafortunadamente, los detalles de las preocupaciones de seguridad están siempre en cambio. Los problemas surgen cuando actores con malas intenciones se aprovechan del software o de las personas (o de ambos). Por lo tanto, la seguridad solo se puede abordar mediante la aplicación sensata de principios generales.

Más seguro por diseño

Creemos que el diseño es uno de los aspectos de la seguridad del software menos valorados. Aquí, el diseño abarca las decisiones fundamentales que se han tomado para desarrollar el software. Las decisiones de diseño que toma una empresa tienen enormes implicaciones en lo que respecta a la seguridad, particularmente en la superficie de ataque. Mediante un diseño sensato del software, Lokad ha eliminado categorías enteras de problemas de seguridad. Por ejemplo, Lokad no utiliza una base de datos SQL - sino un almacenamiento en blob simple - como una capa de almacenamiento estrictamente pasiva. Esta elección por sí sola previene grupos completos de problemas de seguridad, como los ataques de inyección SQL, ya que simplemente no existe una base de datos SQL para atacar. De manera similar, todas nuestras capas de persistencia son de solo anexado. Esto es como el control de versiones, donde los cambios se añaden al final de los datos existentes, en lugar de sobrescribir la totalidad de los datos. Todos los cambios quedan registrados y pueden revertirse. Este paso complica enormemente la eliminación de cualquier dato (por cualquier persona, incluidos los atacantes), así como la manipulación de los registros de Lokad.

La mayoría de los proveedores de software empresarial no reconocen el hecho de que las decisiones fundamentales de diseño son la base misma de sus productos de software. Como resultado, sus problemas de seguridad son interminables. Por ejemplo, si la configurabilidad - casi siempre un requisito para el software empresarial - se proporciona a través de un lenguaje de programación de propósito general (como Python o JavaScript), inevitablemente surgirán problemas de seguridad. Esto se debe a que es prácticamente imposible asegurar completamente un lenguaje de programación de propósito general. En contraste, Lokad tomó la decisión consciente de canalizar toda la configurabilidad a través de un DSL (lenguaje de programación específico de dominio) llamado Envision. Envision es mucho más seguro porque carece -por diseño- de la capacidad de interactuar directamente con el OS (sistema operativo) y sus subsistemas, como el sistema de archivos

Más seguro gracias a la cultura

Ninguna tecnología, y ciertamente ningún proceso, puede hacer que el software sea seguro si a la gente simplemente no le importa. Por ello, hacemos todo lo posible para que Lokad -tanto sus tecnologías como sus procesos- sea algo que merezca un cuidado genuino. En el contexto del software empresarial, esto es difícil, ya que el objeto de interés es abstracto y está desconectado de las perspectivas y motivaciones individuales de las personas¹.

Primero, Lokad alinea, en la medida de lo humanamente posible, sus mensajes de marketing con la realidad de su negocio. Lo hacemos tanto si nos gana simpatía como si recibe críticas. Esto contrasta radicalmente con muchos proveedores empresariales que hacen afirmaciones públicas irracionales (y a menudo fantasiosas) ². Cuando esto último ocurre, los empleados perspicaces -aquellos capaces de identificar la desconexión entre la realidad del negocio y lo que se comunica al exterior- dejan de interesarse. Esta indiferencia genera complacencia, y consecuentemente surgen problemas de seguridad. A menudo, esos empleados abandonan la empresa, dejando atrás a los “crédulos” -aquellos que no logran ver la desconexión. La credulidad, al igual que la indiferencia, no es un rasgo deseable en lo que respecta a la seguridad.

Segundo, Lokad fomenta entre sus empleados una mezcla de curiosidad y escepticismo saludable acerca de todos los aspectos de nuestro negocio, tanto técnicos como no técnicos, incluida la seguridad. Esto crea flexibilidad a la hora de revisar y actualizar prácticas, ya que los empleados son capacitados y se les anima a contribuir. Tal plasticidad es útil para anticipar a actores con malas intenciones, dado que se sabe que idean formas cada vez más creativas de ataque. Afortunadamente para Lokad, esta mentalidad también resulta altamente deseable para fines de supply chain, ya que las conductas adversas -aunque no necesariamente criminales- son comunes en supply chain ³.

Más seguro mediante la capacitación

Entrenamos activamente a todo nuestro personal para entender mejor las amenazas cibernéticas y cómo mitigarlas. A diferencia del diseño y la cultura, la capacitación en seguridad es en gran medida un proceso de arriba hacia abajo. Aunque el pensamiento de abajo hacia arriba tiene su lugar, este tipo de capacitación es inherentemente débil frente a la mayoría de los riesgos de seguridad informática. Dicho de manera sencilla, incluso si se entrena a las personas para que no hagan algo, Lokad no puede asumir que nadie hará esa cosa ⁴. Por ello, adoptamos un enfoque más estricto. Como parte de nuestra capacitación, desalentamos el uso de memorias USB y otros dispositivos USB que puedan comprometer las máquinas. Nos aseguramos de que se use la autenticación de dos factores siempre que sea posible. Entrenamos a nuestro personal para operar con la mínima cantidad de privilegios posible en sus estaciones de trabajo. Nos aseguramos de que todos sean conscientes de cómo funciona la ingeniería social, que puede utilizarse para engañar incluso a las personas más inteligentes.

Más en general, la capacitación en seguridad se centra en aumentar la conciencia sobre cómo el software y los procesos pueden ser reutilizados y corrompidos por actores con malas intenciones. Dado el alcance de la capacitación, la habilidad y el conocimiento necesarios para prevenir ataques tan matizados, Lokad generalmente cuenta con muy pocos pasantes, en comparación con la mayoría de las empresas de tamaño comparable en el sector. En resumen, preferimos apostar por un equipo estable y altamente capacitado a largo plazo.

Preguntas Frecuentes (FAQ)

1. Prácticas

1.1 ¿Tienen garantía de seguridad?

Sí. La garantía de seguridad es un término paraguas para una variedad de prácticas tales como el endurecimiento de seguridad, las pruebas de seguridad y la gestión de vulnerabilidades. El endurecimiento de seguridad, en Lokad, se aborda primordialmente a través del diseño. A través de elecciones de diseño específicas, eliminamos clases enteras de vulnerabilidades que, a su vez, eliminan la necesidad misma de endurecimiento. Por ejemplo, Lokad no depende de una capa de almacenamiento “programática” - como una base de datos relacional - sino de una simple tienda de clave-valor. Esto elimina todos los vectores de inyección SQL. Además, las pruebas de seguridad se abordan mediante un conjunto diverso de métodos; algunos automatizados y otros manuales, tales como pruebas de penetración de terceros. Para la gestión de vulnerabilidades, contamos con un programa de bug bounty y un proceso de gestión de lanzamientos extensamente automatizado para garantizar que las correcciones puedan desplegarse rápidamente.

1.2 ¿Cumplen con ISO 27001 (ISMS) y/o SOC 2?

No. Creemos firmemente que estas certificaciones son distracciones que hacen que las empresas de software sean menos seguras. Estos procesos de cumplimiento enfatizan una mentalidad burocrática que es lo opuesto a lo que se requiere para hacer el software seguro. Por ejemplo, estas certificaciones requieren que se produzca papeleo y que se formen comités. Francamente, la idea de que el papeleo y los comités aporten algo sustancial para la seguridad del software es profundamente debatible y no es algo que Lokad acepte en lo más mínimo.

En los círculos del software, la seguridad generalmente se logra haciendo menos, no más; al aprovechar los esfuerzos de los ingenieros de software que se especializan en la seguridad del software, en lugar de crear equipos adicionales de no especialistas. Como evidencia anecdótica, consideren algunas de las catástrofes de ciberseguridad más graves, como Heartbleed o Log4Shell. Es probable que estos desastres se hubieran prevenido si las miles de empresas de software “certificadas” hubieran optado por priorizar la revisión del código de terceros -a menudo la causa raíz de los problemas- en lugar de perseguir sellos arbitrarios de aprobación comercial.

En general, creemos que estas certificaciones son trucos de marketing que adormecen a las empresas, haciéndolas sentir una falsa sensación de seguridad (tanto en sentido figurado como literal).

1.3 ¿Siguen las prácticas de OWASP?

Sí. OWASP proporciona, a través de sus guías, una extensa lista de verificación contra las vulnerabilidades comúnmente encontradas en el software. Esta es una compilación extensa y de alta calidad que los ingenieros de Lokad utilizan para salvaguardar nuestro software de cualquiera de los problemas identificados por OWASP. Sin embargo, mediante sus elecciones de diseño, Lokad elimina en gran medida clases enteras de vulnerabilidades comunes destacadas por OWASP. Por ejemplo:

Gestión de contraseñas: Al delegar la autenticación a través de la funcionalidad SSO (inicio de sesión único, algo recomendado por Lokad), Lokad no tiene que “gestionar” contraseñas, haciendo irrelevante toda la lista de verificación relacionada con las contraseñas.

Registro: El diseño de event sourcing adoptado por Lokad registra todo por necesidad. Si una acción no es registrada, entonces, para el sistema, nunca ocurrió. Esto anula la mayoría de la lista de verificación de registro.

Seguridad de Base de Datos: La capa de persistencia de Lokad no incluye una base de datos relacional, sino dos componentes no programáticos; a saber, una fuente de eventos y una tienda de clave-valor. Esta elección de diseño anula por completo la lista de verificación de la base de datos.

En general, siempre que sea posible, preferimos evitar los patrones de diseño de ingeniería propensos a errores que crean la necesidad de tales listas de verificación en primer lugar.

1.4 ¿Cumple usted con el GDPR?

Sí. Sin embargo, la optimización de supply chain - tal como la ofrece Lokad - no requiere datos personales. Consideramos que los datos personales representan una responsabilidad en lugar de un activo. Por ello, recomendamos encarecidamente a nuestros clientes no transferirnos datos personales. Esta recomendación suele formar parte de nuestros acuerdos contractuales. Al no tener datos personales en custodia y, por lo tanto, no procesarlos, eliminamos en gran medida las preocupaciones y protocolos relacionados con su protección, como el GDPR u otras regulaciones similares.

1.5 ¿Cumplen todos los servicios/soluciones de terceros (que implican acceso a Personal Identifiable Information (PII)) en la solución de Lokad con los requisitos del Data Protection Officer (DPO)?

Sí. Sin embargo, como se indica en Practices 1.4, la optimización de supply chain - tal como la ofrece Lokad - no requiere datos personales. Por ello, recomendamos encarecidamente a nuestros clientes no transferirnos datos personales.

Cabe destacar que la solución de Lokad cuenta con una lista muy corta de terceros que tienen acceso a datos PII. A partir de enero de 2023, esta lista se limita a Microsoft Azure.

1.6 ¿Sigue usted las mejores prácticas de seguridad?

Sí. Es decir, tomamos decisiones prudentes, ya que no existe un acuerdo universal en la industria sobre lo que constituyen “las mejores prácticas de seguridad del software”. Por su propia naturaleza, la seguridad del software existe en un estado de constante evolución, adaptándose a un entorno lleno de nuevas amenazas ingeniosas y vectores de ataque. Por ello, no nos remitimos categóricamente a terceros para determinar cuáles son las mejores prácticas de seguridad del software. En cambio, definimos lo que es mejor para nuestros clientes. Esto nos permite adoptar buenas prácticas cuando están disponibles, sin seguir rígidamente aquellas menos aconsejables solo porque son populares. Todo esto se traduce en prácticas de seguridad del software actuales, aplicables y efectivas.

1.7 ¿Realiza regularmente pruebas de penetración?

Sí. Tenemos tanto pruebas de penetración planificadas como no planificadas. Las planificadas son típicamente financiadas por nuestros grandes clientes, quienes pueden, según el acuerdo contractual firmado con ellos, contratar a empresas especializadas para realizar pruebas de penetración de sus proveedores clave de software, entre los que se incluye Lokad. Por lo general, existe cierto grado de coordinación entre el equipo de ingeniería de Lokad y esos especialistas en seguridad. Las pruebas no planificadas son, por lo general, parte de nuestro programa público abierto de bug bounty, donde especialistas freelance en seguridad pueden intentar encontrar una debilidad en nuestro sistema que sea susceptible a un potencial exploit.

1.8 ¿Realiza regularmente auditorías externas?

No. Dicho esto, estamos más que dispuestos a someternos a una auditoría externa si la operación es financiada por el cliente. Muchos de nuestros grandes clientes tienen disposiciones para tales auditorías en nuestros acuerdos contractuales. Sin embargo, a partir de enero de 2023, las pruebas de penetración realizadas por los clientes no han descubierto suficientes problemas como para justificar la realización de dichas auditorías.

1.9 ¿Dispone de un Plan de Continuidad del Negocio?

Sí. La mayor contingencia que Lokad ha abordado es la hipotética cesación de la propia compañía. Lokad opera como una solución SaaS; sin embargo, algunos de nuestros grandes clientes tienen disposiciones en sus acuerdos contractuales para poder solicitar instantáneas completas de nuestro codebase. Estas instantáneas se colocan en custodia con un tercero acordado, de modo que, en caso de que Lokad cesara sus operaciones, el cliente obtendría automáticamente acceso al codebase en custodia y una licencia permisiva para recrear su propia instancia del servicio de Lokad.

1.10 ¿Tienen un Plan de Comunicación de Crisis?

Sí. Para cada cliente disponemos de un punto de contacto identificado dentro de su organización. Por nuestra parte, hay al menos dos empleados en Lokad – un titular y un suplente (normalmente dos de nuestros supply chain scientists) – que se encargan de comunicar cualquier mensaje urgente al cliente. En la práctica, la gran mayoría de las crisis que enfrentamos no son problemas de seguridad de software, sino de supply chain – emergencias que Lokad identifica basándose en los datos que el cliente pone a nuestra disposición. En caso de un evento de seguridad, se utiliza este canal para asegurar que nuestros clientes estén informados de manera oportuna.

1.11 ¿Cómo aseguran que los sistemas de TI del cliente se mantengan seguros?

Recomendamos encarecidamente que Lokad no tenga acceso a los sistemas de TI de nuestro cliente; el sistema de TI del cliente solo debe enviar y recibir datos de Lokad. Este enfoque pretende mitigar la posibilidad de que un evento de seguridad en Lokad se propague al sistema de TI del cliente. Además, recomendamos firmemente utilizar un proceso de SSO (single sign-on), ya que elimina el escenario hipotético en el que una contraseña utilizada para acceder a Lokad sea interceptada (de alguna manera) y posteriormente empleada para comprometer uno de los sistemas de TI del cliente.

1.12 ¿Cómo aseguran su red?

Nuestro diseño adopta una arquitectura Zero Trust, lo que significa que solo se permite a las personas adecuadas acceder a los datos en un momento dado. El simple hecho de estar presente en nuestra red no proporciona automáticamente estatus ni privilegios (este punto se amplía en Authentication 2.1). Por lo tanto, aunque somos conscientes de la seguridad de la red, nos aseguramos –como primer paso– de que la superficie de ataque asociada a nuestras redes sea la más reducida posible.

Lokad utiliza dos redes notables. La primera es Microsoft Azure, que se utiliza para alojar nuestra solución. La seguridad de la red de Microsoft Azure se delega completamente a Microsoft. No usamos capacidades de red “avanzadas” – como las ofrecidas por Microsoft Azure – más allá de simples balanceadores de carga.

La segunda es la red local de nuestra sede en París. La seguridad de la red local es gestionada internamente por el equipo de ingeniería de Lokad. Nuestra red local no aloja ningún componente o sistema que contribuya al entorno de producción.

1.13 ¿Garantizan que todos los componentes (incluyendo los de terceros) y herramientas (incluyendo las de código abierto) integrados en la solución sean legalmente válidos para uso en desarrollo y producción?

Sí. En comparación con la mayoría de los proveedores de software empresarial, Lokad tiene muy pocas dependencias. Todas nuestras dependencias principales son proyectos de código abierto creíbles y ampliamente utilizados (ej.: .NET de Microsoft, React de Facebook). Esto hace que nuestro proceso de auditoría interna sobre este punto específico sea algo sencillo.

1.14 ¿Cómo gestionan los cambios importantes en la organización y procesos en términos de seguridad?

Dado que Lokad adoptó desde el principio decisiones y prácticas de seguridad sensatas, es raro que un cambio de cualquier magnitud (menor o mayor) impacte la seguridad (incluso hipotéticamente). En toda la historia de Lokad, solo hay 3 eventos que podrían considerarse verdaderamente significativos desde una perspectiva de seguridad: la migración a Microsoft Azure en 2010; la introducción de la autenticación delegada en 2012 (tanto para clientes como para empleados); y, internamente en Lokad, la migración de Google Authentication a Microsoft Azure AD en 2022.

Para cada uno de estos eventos, la migración había sido preparada con meses de antelación por el equipo de ingeniería de software de Lokad. Se implementaron materiales de capacitación relevantes y sesiones de entrenamiento antes del cambio programado, para asegurar la preparación de todos los empleados de Lokad. Finalmente, tras cada evento de migración, nos aseguramos de que se eliminara la “ruta” anterior, tal como es la práctica estándar en Lokad.

A enero de 2023, no tenemos planeados cambios mayores próximos. Si se introdujera tal cambio, casi con toda seguridad procederíamos de manera similar.

1.15 ¿Cómo gestionan el fin de un contrato?

Nuestros acuerdos detallan el proceso de terminación al final de un contrato, según lo acordado con el cliente. El proceso de terminación culmina con la eliminación definitiva de los datos del cliente. Dado que este proceso de terminación representa un riesgo de seguridad en sí mismo, este punto se discute con cada cliente y, por lo tanto, puede variar ligeramente según el caso. Desde una perspectiva de seguridad, un actor malintencionado podría intentar hacerse pasar por el cliente para desencadenar una terminación anticipada del contrato (y perturbar las operaciones del cliente). Para evitar esto, Lokad y el cliente se empeñarían conjuntamente en adoptar un proceso –contractualmente obligado– que no sea trivialmente vulnerable a un ataque de ingeniería social. Este proceso típicamente implica confirmaciones por escrito y un retraso obligatorio.

1.16 ¿Cuál es la estrategia de licencias de Lokad, el modelo de costos asociado y el modelo de costos anuales de mantenimiento?

Lokad generalmente cobra una tarifa mensual fija asociada al costo operativo de la plataforma, además de una tarifa mensual fija asociada al servicio proporcionado por los supply chain scientists dedicados al cliente (es decir, los ingenieros proporcionados por Lokad). Los detalles se negocian y se especifican en el contrato de servicio entre el cliente y Lokad. Estas dos tarifas representan un paquete “todo incluido” con Lokad. No existen tarifas adicionales de mantenimiento, tarifas de licencia, integradores de terceros, consultores externos, etc. El paquete viene con límites, tanto en alcance como en escala, que se negocian conjuntamente como parte del acuerdo contractual para el servicio.

1.17 ¿Pueden proporcionar los términos y condiciones de Lokad para la(s) licencia(s), servicio(s), soporte, mantenimiento y capacitaciones?

Sí, previa solicitud del cliente, podemos proporcionar una plantilla contractual que representa un acuerdo “base”. Sin embargo, las situaciones varían sustancialmente dependiendo de la escala de la iniciativa de supply chain, los países aplicables y el alcance de los servicios que Lokad espera proporcionar. Por lo tanto, si es posible, preferimos entablar una conversación inicial con un cliente prospecto para aclarar los detalles específicos de la iniciativa de supply chain que se está considerando. Esto nos ayuda a elaborar el marco contractual más relevante para la situación.

1.18 ¿Ofrecen capacitación (presencial/e-training)?

Sí, Lokad ofrece tanto capacitaciones presenciales como remotas. Los detalles de estas sesiones se negocian como parte del acuerdo contractual. Además, Lokad cuenta con una extensa documentación técnica pública y una serie detallada de conferencias de supply chain públicas. Estas conferencias abarcan la tecnología y la perspectiva de supply chain de Lokad.

1.19 ¿Cumple el sistema de Lokad con las normativas legales/locales relevantes (es decir, ISO)?

Sí, Lokad opera en línea con las normas relevantes. Sin embargo, Lokad ofrece optimización predictiva de la supply chain, y como tal, no controla directamente las operaciones. Nuestra influencia es en gran medida indirecta, típicamente a través de la optimización de la asignación de recursos. Por lo tanto, las normas ISO no son relevantes aquí (es decir, no son aplicables a Lokad).

1.20 ¿Existe protección contra malware integrada a nivel de red, por ejemplo en firewalls, dispositivos proxy y/o soluciones de red separadas?

Ver Practices 1.12

1.21 ¿Incluye el proceso de desarrollo de software una evaluación de amenazas integrada?

Sí. Esta es la razón principal por la que preferimos abordar las preocupaciones de seguridad “desde el diseño”. Al eliminar clases enteras de amenazas en la etapa de diseño, mantenemos la práctica general de evaluación de amenazas más manejable. La evaluación de amenazas también abarca “supply chain attacks”. Esta es otra razón por la que ponemos tan fuerte énfasis en minimizar la cantidad de dependencias de terceros en nuestro stack de software, ya que cualquier dependencia inherentemente aumenta la superficie de ataque.

1.22 ¿Se practica el proceso de gestión de incidentes al menos anualmente?

Sí. Existen muchos tipos diferentes de incidentes. Uno de los más frecuentes es que la propia empresa cliente sea vulnerada. En caso de ransomware, esto a veces conduce a que los datos de Lokad se conviertan accidentalmente en el único conjunto de datos aún accesible. En casos de robo de identidad, esto a veces lleva a intentos de acceder a la cuenta de Lokad mediante credenciales robadas. Los pormenores de los diversos procesos de gestión de incidentes se establecen conjuntamente con la empresa cliente y, normalmente, son supervisados por el supply chain scientist de Lokad encargado de la cuenta (para clientes que optan por una cuenta gestionada).

1.23 ¿Se revisa el mapeo de riesgos y amenazas al menos una vez al año?

Sí, aunque estas revisiones se realizan normalmente de manera regular a lo largo del año. Dichas revisiones suelen estar impulsadas por eventos significativos, como importantes brechas de seguridad en la industria del software.

1.24 ¿Se realiza la evaluación de riesgos también en funciones de soporte que puedan impactar la disponibilidad, calidad y/o seguridad de la solución?

Sí. Sin embargo, la plataforma de Lokad es esencialmente un monolito que no depende de ninguna “función de soporte” aparte de algunos fundamentos básicos, como el Blob Storage y las VMs Linux proporcionadas por Microsoft Azure.

1.25 ¿Se crean cuentas de sistema dedicadas – con solo los derechos de acceso requeridos – para ejecutar procesos del sistema?

Sí, se utilizan cuentas de sistema dedicadas con los derechos de acceso apropiados para ejecutar procesos del sistema. Lokad utiliza demonios en forma de servicios systemd, que siempre se ejecutan como usuarios con el mínimo de privilegios posible.

Aunque Lokad no emplea una base de datos SQL, la plataforma utiliza un sistema basado en roles para definir los derechos de acceso a procesos programados y desencadenados. Estos procesos se categorizan como “userland” en lugar de procesos “de sistema”.

1.26 ¿Existe un plan de gobernanza de riesgos formalizado aprobado por la dirección que defina los requisitos del programa de Gestión de Riesgos Empresariales?

Sí, contamos con un plan de gobernanza de riesgos formalizado que ha sido aprobado por la alta dirección.

Este plan establece los requisitos y directrices para nuestro programa de Gestión de Riesgos Empresariales (ERM). Está diseñado para identificar, evaluar, gestionar y monitorear los riesgos en toda la empresa de manera estructurada y consistente.

Nuestro plan de gobernanza de riesgos se revisa y actualiza periódicamente para asegurar que siga siendo relevante y esté alineado con nuestros objetivos organizacionales y el panorama de riesgos en evolución. Además, la implementación y efectividad del programa ERM se reportan regularmente a la alta dirección y a las partes interesadas pertinentes para garantizar una supervisión y apoyo continuos.

1.27 ¿Existe un programa de seguridad física aprobado por la dirección, comunicado a los involucrados, y se ha asignado un responsable para mantenerlo y revisarlo?

Sí, contamos con un completo programa de seguridad física que ha sido aprobado por la alta dirección. Este programa ha sido comunicado exhaustivamente a todos los involucrados pertinentes para asegurar la conciencia y el cumplimiento.

Además, hemos designado a un responsable que se encarga de mantener, actualizar y revisar periódicamente el programa para asegurar su efectividad y relevancia. Este responsable colabora con varios equipos y departamentos para abordar cualquier preocupación emergente en materia de seguridad física y garantizar que el programa se alinee con las mejores prácticas y nuestros objetivos organizacionales.

1.28 ¿Se realizan evaluaciones de los peligros físicos y ambientales antes de establecer la ubicación o el sitio de una instalación donde residen los sistemas?

Sí, las evaluaciones de los peligros físicos y ambientales son una parte integral de nuestro proceso de toma de decisiones al determinar la ubicación o el sitio de una instalación para nuestros sistemas. Dado que nuestros sistemas residen en centros de datos de Microsoft Azure, nos beneficiamos del riguroso proceso de selección y evaluación de sitios de Microsoft. Microsoft Azure realiza evaluaciones extensas de los riesgos potenciales, incluidos los peligros físicos y ambientales, antes de establecer cualquiera de sus centros de datos. Su proceso de selección implica analizar factores tales como el potencial de desastres naturales, la accesibilidad, la estabilidad de la infraestructura, entre otros.

Al aprovechar los centros de datos de Azure, estamos seguros de que estas evaluaciones se han realizado de forma exhaustiva para garantizar los más altos niveles de seguridad física y resiliencia ambiental para nuestros sistemas.

1.29 ¿Existe un programa interno documentado de cumplimiento y ética?

Sí, aunque no creemos que la “ética” pueda imponerse de manera vertical. Este tipo de enfoque invariablemente produce resultados indeseables que contravienen los objetivos originales.

Famosamente, Enron tenía un código de ética escrito. Dicho código enfatizaba el respeto, la integridad, la comunicación y la excelencia. El escándalo de Enron, descubierto en 2001, reveló que la empresa había estado involucrada en un fraude contable masivo, lo que estaba –obviamente– en desacuerdo con los principios establecidos en su código de ética. Por lo tanto, existía una desconexión total entre la ética escrita y proclamada de Enron y las prácticas comerciales y la cultura corporativa reales.

Así, Lokad se centra en asegurarse de que los empleados tengan la oportunidad de preocuparse genuinamente por nuestros clientes. “¿Estamos haciendo lo correcto?” es uno de nuestros mantras. El cumplimiento y la ética son, a nuestro parecer, el subproducto de una cultura corporativa adecuada, y no el resultado de ningún programa en particular.

1.30 ¿Existe un departamento interno de auditoría, gestión de riesgos o cumplimiento, o una función similar de supervisión de la gestión, con la responsabilidad de hacer seguimiento a la resolución de problemas regulatorios o de cumplimiento pendientes?

Sí. Aunque Lokad no es lo suficientemente grande como para contar con un departamento independiente dedicado a realizar auditorías internas, gestión de riesgos o cumplimiento, ciertamente damos prioridad a estas áreas. Hemos designado a individuos con experiencia en estos ámbitos que están específicamente encargados de gestionar y supervisar estas responsabilidades críticas.

Estas personas reportan directamente a la alta dirección de Lokad, asegurando que la resolución de cualquier asunto pendiente de regulación o cumplimiento se trate con la mayor prioridad y reciba la supervisión necesaria al más alto nivel de nuestra organización.

1.31 ¿Existe una política inalámbrica o programa que haya sido aprobado por la dirección, comunicado a los constituyentes apropiados, y se le haya designado un responsable para mantenerlo y revisarlo?

Sí, Lokad cuenta con una política inalámbrica bien definida que ha sido aprobada por la dirección y comunicada a todos los constituyentes pertinentes para garantizar su cumplimiento. Esta política distingue entre dos redes Wi‑Fi independientes y aisladas: una dedicada para los empleados y otra específicamente para los invitados o visitantes. La distinción asegura que nuestras operaciones principales se mantengan seguras, incluso al proporcionar conectividad para invitados o visitantes.

Sin embargo, es importante señalar que nuestro modo principal de conexión es a través de Ethernet, priorizado debido a su rendimiento superior y mejorada seguridad. Las redes Wi‑Fi están implementadas principalmente para facilitar reuniones y ofrecer flexibilidad en ciertos escenarios.

Además, hemos designado un responsable para la política, quien se encarga de su mantenimiento y revisión periódica, garantizando que se mantenga actualizada y sea eficaz para abordar las necesidades y desafíos en evolución.

2. Autenticación

2.1 ¿Exiges autenticación para todos los accesos?

Sí. Acceder a los datos del cliente y/o a cualquier capacidad sustancial de la solución requiere autenticación previa. Sin embargo, por necesidad, algunos puntos de contacto no están sujetos a autenticación. Por ejemplo, acceder a la página de inicio de sesión no requiere autenticación previa (ya que la autenticación es el propósito mismo de esta página de inicio de sesión).

En general, muy pocos endpoints técnicos no requieren autenticación, y típicamente forman parte de la instrumentación de la plataforma (ej.: un endpoint usado únicamente para verificar que una máquina está activa). Cabe destacar que los endpoints sin autenticación no exponen ningún tipo de dato sensible, y mucho menos datos reales de clientes.

2.2 ¿Requieres que todos los accesos remotos estén seguros? ¿Exiges HTTPS para las conexiones web?

Sí. Asegurar los accesos remotos implica contar con la autenticación adecuada, la autorización correcta y la encriptación del canal de transporte en sí, todo lo cual exigimos. Esta disposición cubre tanto a los usuarios clientes como a los empleados de Lokad. Incluso para el equipo de ingeniería de Lokad, no existe ningún “acceso local no seguro” a nuestros sistemas de producción. No utilizamos ningún tipo de “localidad de red” como un mecanismo para evadir la seguridad.

2.3 ¿Ofreces SSO (inicio de sesión único)? ¿Soportas Active Directory (AD)?

Sí. Ofrecemos SSO (inicio de sesión único) a través del protocolo SAML. Active Directory soporta SAML y puede usarse para acceder a Lokad.

2.4 ¿Soportas la autenticación de dos factores, como EZToken, Google Authenticator o Microsoft Authenticator?

Sí. La autenticación de dos factores se logra mediante autenticación delegada a través de SAML. Por medio de SAML, Lokad no administra ni el primer factor de autenticación ni el segundo, ya que este proceso es delegado.

2.5 ¿Soportas el protocolo de autenticación OAuth2?

Por defecto, Lokad soporta el protocolo de autenticación SAML. Este protocolo es compatible con los principales sistemas de identidad federada, como Microsoft Office 365 o Google Workspace. El desafío de soportar OAuth2 es que OAuth2 no es en realidad un “protocolo de autenticación”, sino un conjunto de directrices muy extensas para diseñar “protocolos de autenticación” que pueden diverger en docenas de formas.

Como resultado, observamos que las diversas implementaciones de OAuth2 que existen en el ámbito del software empresarial tienden a ser en gran medida incompatibles. Así, si OAuth2 es un requisito absoluto, según el acuerdo contractual, podemos soportar una versión específica de OAuth2. Sin embargo, este arreglo requiere recursos dedicados para garantizar la compatibilidad con la variante de OAuth2 operada por la empresa cliente.

2.6 ¿Soportas la integración LDAP?

Sí, a través de un puente middleware que implementa SAML sobre LDAP. Sin embargo, la mayoría de los sistemas de identidad federada que soportan LDAP también soportan SAML. Por ello, recomendamos usar directamente SAML.

2.7 ¿Exiges la autenticación de dos factores?

Para los empleados de Lokad, sí. Para los empleados del cliente, lo recomendamos encarecidamente, pero en última instancia no podemos exigirlo (ya que la autenticación generalmente se delega a través de SSO). Este asunto está en manos del departamento de TI del cliente, no en las nuestras.

2.8 ¿Puedes exigir una complejidad mínima de contraseñas?

Sí, pero en un grado limitado. En lo que respecta a la seguridad del software, exigir una complejidad mínima en las contraseñas es ahora reconocido en gran medida como una mala práctica. Los usuarios finales responden de forma pobre (y predecible) a exigencias de complejidad de contraseñas demasiado estrictas, lo que causa que el nivel general de seguridad sufra. Además, consideramos tales exigencias de contraseñas como “bloatware” que aumentan la complejidad de una pieza de software crítica para la seguridad (gestión de contraseñas), exponiéndola (y a la solución completa) a riesgos indebidos. Consulta https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Recomendamos encarecidamente usar SSO en lugar de contraseñas/estrategias tradicionales. A través de SSO, no es necesario introducir ninguna contraseña dedicada a Lokad.

2.9 ¿Puedes exigir rotaciones de contraseñas programadas?

Podríamos, pero no lo hacemos. Al igual que la complejidad mínima de contraseñas (ver Authentication 2.8), la rotación programada de contraseñas es ahora reconocida en gran medida como una mala práctica de seguridad en el software. Los usuarios finales responden de forma pobre (y predecible) a las rotaciones de contraseñas programadas. La seguridad incluso puede debilitarse ya que los empleados a menudo realizan solo alteraciones menores en las contraseñas (para reducir la carga cognitiva asociada a rotaciones frecuentes). Al igual que la complejidad mínima de contraseñas, vemos la rotación de contraseñas como “bloatware” que aumenta la complejidad de una pieza de software crítica para la seguridad (gestión de contraseñas), exponiéndola (y a la solución completa) a riesgos indebidos. Consulta https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 ¿Hasheas y agregas sal a las contraseñas?

Sí. Usamos scrypt como nuestra función para hashear contraseñas. Como regla general, recomendamos encarecidamente usar SSO en lugar de contraseñas/estrategias tradicionales. A través de SSO, no es necesario introducir ninguna contraseña dedicada a Lokad.

2.11 ¿Habilita la solución de Lokad CAPTCHA después de un número determinado de fallos de autenticación?

Sí, aunque mediante delegación de autenticación (a través de SSO). Aunque los CAPTCHAs son un enfoque valioso para mitigar algunos vectores de ataque, se enmarcan en la categoría de componentes de software que es mejor dejar completamente fuera del alcance de una solución de optimización de supply chain como la de Lokad. Además, el valor añadido de los CAPTCHAs en el contexto del software empresarial es menos evidente que en el software B2C, especialmente en el freeware.

2.12 ¿Tienes una política general de seguridad para las contraseñas? ¿Cuentas con un proceso para hacerla cumplir?

Sí. Nuestra política general de seguridad para las contraseñas es “no passwords”. Recomendamos encarecidamente SSO, lo cual elimina la necesidad de introducir contraseñas dedicadas a Lokad.

2.13 ¿Centralizas la gestión de usuarios?

Sí. Lokad tiene su propia gestión centralizada de usuarios para la solución que operamos. Este subsistema fue implementado por Lokad y también cubre los accesos de los empleados de Lokad, incluidos nuestros equipos de ingeniería.

2.14 ¿Permites cuentas de usuario genéricas/compartidas?

No. Lokad impone una relación uno a uno entre empleados y usuarios (tal como se ve en la plataforma de Lokad). Desaconsejamos encarecidamente el uso de cuentas de usuario compartidas. De hecho, una de las razones por las que no cobramos por usuario es para evitar incentivar a nuestros clientes a compartir cuentas de usuario entre sus empleados. Sin embargo, existen algunos casos en los que es aceptable tener una cuenta de usuario que no tenga un empleado correspondiente. Esto ocurre típicamente en el servicio de “robot upload” del lado del cliente, encargado de enviar datos a Lokad. Como parte de nuestro RBAC (Control de Acceso Basado en Roles), contamos con un rol dedicado (llamado “uploader”) que proporciona derechos mínimos para este único caso de uso.

2.15 ¿Ofreces conexiones VPN seguras?

No. Las conexiones de los usuarios finales se realizan a través de canales encriptados (típicamente TLS).

2.16 ¿Permites que los usuarios inicien sesión desde múltiples dispositivos?

Sí, dentro de ciertos límites. En general, el límite máximo es de 6 dispositivos por usuario (no cobramos por permitir múltiples dispositivos). Cada sesión se restringe a una única dirección IP. Sin embargo, Lokad se reserva el derecho de cambiar este límite para contrarrestar algunas amenazas potenciales y/o abusos.

2.17 ¿Tiene la solución la capacidad de bloquear y/o cerrar la sesión de un usuario de forma forzosa (si se considera malicioso)?

Sí. Esta funcionalidad requiere derechos de acceso de “Owner” dentro de la cuenta de Lokad.

2.18 ¿Cierra el sistema automáticamente la sesión de un usuario inactivo después de una cantidad especificada de tiempo de inactividad?

Sí, aunque la “inactividad” no es el factor determinante. Lokad cierra automáticamente la sesión de los usuarios después de una cantidad especificada de tiempo. Los usuarios no pueden posponer el cierre de sesión mediante su “actividad”; una vez transcurrido el tiempo especificado, deben re-autenticarse.

2.19 ¿Está prohibido el uso de cuentas compartidas y/o credenciales de acceso, y se monitorea el cumplimiento de estas políticas?

Sí. Consulta Authentication 2.14.

2.20 ¿Se comunican/distribuyen los IDs de usuario y contraseñas mediante medios separados (por ejemplo, correo electrónico y teléfono)?

Sí, priorizamos la seguridad de las credenciales de usuario y nos aseguramos de que se comuniquen de una manera que se alinee con las mejores prácticas. Internamente, nuestros sistemas aprovechan Azure Active Directory para la autenticación de usuarios. Cuando se distribuyen los IDs de usuario y las contraseñas iniciales, Azure Active Directory sigue sus patrones predeterminados, diseñados con la seguridad en mente. Además, exigimos la autenticación de dos factores para nuestro Azure AD, añadiendo una capa adicional de seguridad al proceso de autenticación.

Externamente, para los empleados de los clientes que se conectan a nuestros sistemas, recomendamos encarecidamente el uso de Single Sign-On (SSO) y sistemas de identidad federada. Estos sistemas, por diseño, soportan las mejores prácticas en la gestión de credenciales, asegurando que las credenciales se comuniquen de forma segura, a menudo involucrando canales o métodos de comunicación separados para los IDs de usuario y los mecanismos de autenticación.

Vale la pena señalar que no recomendamos la autenticación de un solo factor, ya sea para usuarios internos o externos, si el objetivo es mantener un alto estándar de seguridad.

2.21 ¿Se deshabilitan y eliminan los IDs de usuario inactivos de los constituyentes después de períodos definidos de inactividad?

Sí, gestionamos y monitoreamos activamente los IDs de usuario para garantizar la seguridad. Para los empleados de Lokad, nuestra política exige que todos los derechos de acceso sean revocados en su último día de empleo, asegurando que no haya acceso posterior al empleo para exempleados.

Para nuestros clientes, abogamos por el uso de Single Sign-On (SSO) y sistemas de identidad federada. Este enfoque agiliza la gestión de accesos. Por ejemplo, cuando un cliente elimina a un empleado de su sistema de identidad, el acceso a Lokad se termina simultáneamente. Este método no solo mejora la seguridad, sino que también garantiza la eficiencia en la gestión de usuarios.

Nota: los detalles respecto a la terminación del acceso de los usuarios se especifican en nuestros acuerdos contractuales con cada cliente. Lokad reconoce firmemente el potencial impacto operativo de desactivar prematuramente una cuenta y toma medidas activas para evitar tales escenarios. Para evitar interrupciones inadvertidas, los términos de la terminación del acceso de usuario se establecen explícitamente, ya sea en el contrato o en un procedimiento acordado conjuntamente, asegurando que las medidas de seguridad de Lokad se alineen con las necesidades operativas de nuestro cliente.

3. Autorización

3.1 ¿Proporciona la solución derechos de acceso granulares?

Sí. La solución de Lokad incluye un subsistema granular de RBAC (Control de Acceso Basado en Roles). Esto permite al cliente controlar qué “Projects” y “Files” son accesibles (y por quién) en la cuenta de Lokad. El RBAC tiene su propia interfaz web (dashboard). Está disponible para todos los usuarios con la designación de “Owner” dentro de la cuenta de Lokad. Consulta nuestra documentación user roles and permissions para más información.

3.2 ¿Permite la solución que el cliente configure los accesos de acuerdo con el principio de privilegio mínimo (PoLP)?

Sí. La solución de Lokad incluye un subsistema granular de RBAC (Control de Acceso Basado en Roles) que puede utilizarse para implementar el PoLP. Sin embargo, a través de Envision (el DSL de la solución), Lokad va mucho más allá que la mayoría del software empresarial en lo que respecta a este principio.

Mediante Envision, Lokad ha eliminado conjuntos completos de privilegios del sistema que son simplemente irrelevantes para la optimización de supply chain. Lo que queda es simplificado, aunque aún ampliamente configurable. De manera similar, el sistema de archivos a medida ofrecido por Lokad también elimina grupos enteros de privilegios del sistema innecesarios.

3.3 ¿Exiges derechos de acceso de privilegio mínimo?

Sí, aunque lo que constituye el privilegio “mínimo aceptable” es, en última instancia, decidido por nuestros clientes. Lokad no puede determinar unilateralmente quién se beneficia de la designación de “Owner” en el personal de nuestros clientes. Sin embargo, podemos ofrecer orientación al respecto. En la práctica, para nuestros clientes “managed” —aquellos que cuentan con el apoyo del equipo de Supply Chain Scientists de Lokad— clarificamos (por escrito) la organización deseada y los correspondientes derechos de acceso.

3.4 ¿Tiene la solución la capacidad de ocultar una entidad particular en el sistema de los usuarios designados?

Sí. Esto es una forma de implementación del PoLP y se aborda en las respuestas 3.1, 3.2 y 3.3.

3.5 ¿Tienes una clasificación establecida para los datos (niveles de sensibilidad) y controles ajustados de acuerdo con esta clasificación?

Sí. Como elemento incorporado, Lokad restringe, por defecto, todos los datos administrativos (como la lista de usuarios con una cuenta) a los “Owners” de la cuenta. Esta designación es la más alta y privilegiada dentro del RBAC (Control de Acceso Basado en Roles). Todos los demás datos dentro de la cuenta de Lokad pueden segmentarse de acuerdo con una clasificación de sensibilidad definida por el usuario. Esta clasificación definida por el usuario puede aplicarse tanto a los datos originales (tal como fueron subidos por el cliente) como a los datos transformados (el resultado de las transformaciones de datos realizadas dentro de la plataforma de Lokad).

Para más información sobre controles de acceso y designaciones, consulta las respuestas 3.1, 3.2 y 3.3.

3.6 ¿Puede la solución autorizar o bloquear usuarios/roles/transacciones en tiempo real?

Sí, aunque “en tiempo real” requiere una aclaración en el contexto de un sistema informático distribuido (como la solución Lokad). Las actualizaciones al RBAC (Control de Acceso Basado en Roles) se realizan de forma síncrona, lo que significa que las actualizaciones se activan en cuestión de segundos (generalmente menos). No hay retrasos notorios (como una espera de una hora o un día).

En cuanto a interrumpir transacciones, esto no es relevante ya que Lokad no cuenta con una base de datos transaccional. Dicho esto, Lokad puede interrumpir operaciones asíncronas de larga duración (denominadas en Lokad como “Project runs”). Cuando se activa una interrupción, se garantiza de forma inmediata (de manera síncrona) que el procesamiento no afectará al sistema, por ejemplo, sobrescribiendo archivos. Sin embargo, detener el procesamiento es asíncrono y normalmente tiene efecto en un plazo de 20 segundos.

3.7 ¿Restringe la solución el acceso a la Información de Identificación Personal (PII) solo a usuarios con el nivel de permiso adecuado?

Sí, aunque la solución no está destinada a contener ningún dato PII (más allá de los identificadores de autenticación de los empleados con acceso a la solución). Este es el caso tanto para Lokad como para el cliente. Dentro de la solución, solo los empleados con designación “Owner” tienen acceso a la lista de usuarios. Para fines de optimización de supply chain, Lokad no necesita (ni se beneficia) de datos PII, y tenemos estipulaciones contractuales a tal efecto (explicadas en Practices 1.4 & Practices 1.5).

Para más información sobre controles de acceso y designaciones, consulte las respuestas 3.1, 3.2 y 3.3.

3.8 ¿Permite la solución que los filtros de búsqueda de datos de Información de Identificación Personal (PII) excluyan búsquedas con comodines?

Sí. Sin embargo, un usuario con designación “Owner” dentro de una cuenta de Lokad puede acceder a todos los usuarios (incluido el personal del cliente) que están autorizados a acceder a la cuenta. Lokad no puede restringir esta capacidad ya que nuestros clientes deben poder auditar, en su totalidad, la lista de usuarios con acceso a su propia cuenta.

3.9 ¿Está el sistema equipado con tecnología WAF (Firewall de Aplicación Web)?

No. El WAF es un diseño inherentemente peligroso ya que viola el principio de seguridad de “mínimo privilegio”: a un componente se le otorgan enormes privilegios para operar como un “hombre en el medio”. Esto convierte al WAF en un objetivo primordial para los atacantes, y extiende enormemente la superficie de ataque de la plataforma. Sin embargo, Lokad monitorea de cerca su tráfico web y los comportamientos anómalos de los usuarios en nuestra propia plataforma. Estas capacidades, no obstante, son parte de la plataforma misma y, por lo tanto, no se delegan a componentes de software aislados y privilegiados de terceros.

Consulte también Employees 6.6.

3.10 ¿Está la red equipada con tecnología IPS (Sistema de Prevención de Intrusiones)?

No. El IPS es un diseño inherentemente peligroso ya que viola el principio de seguridad de “mínimo privilegio”: a un componente se le otorgan enormes privilegios para operar como un “hombre en el medio”. Esto convierte al IPS en un objetivo primordial para los atacantes, y extiende enormemente la superficie de ataque de la plataforma. Para endurecer la plataforma de Lokad contra intrusiones, nuestro diseño comienza minimizando el área de superficie de ataque. Creemos que es mucho más seguro eliminar por diseño las vías de intrusión, en lugar de intentar “prevenirlas” como una ocurrencia tardía.

Consulte también Employees 6.6.

3.11 ¿Utiliza el servicio tecnología de protección contra DoS (Denegación de Servicio)?

Sí. Lokad utiliza ReCaptcha, límites de tasa en nginx y nuestros propios componentes específicos (como fallo temprano cuando la autenticación es inválida).

3.12 ¿Se realiza todo el acceso administrativo al entorno de producción a través de jump hosts o bastion servers?

Sí. Contamos con un sistema que es esencialmente similar a ‘Teleport’. Esto ofrece no solo una trazabilidad completa de todos los accesos, sino que también facilita la revocación segura de los derechos de acceso de los empleados.

3.13 ¿Existe un proceso de autorización claro para conceder acceso administrativo (y que produzca una pista de auditoría confiable)?

Sí. Vea Logging and Monitoring 5.1 y 5.11.

3.14 ¿Existe un proceso sistemático y regular de revisión de derechos de acceso (realizado por una persona autorizada), en el que se verifican los derechos de acceso administrativos en relación con cualquier cambio en roles y funciones?

Sí. Hay dos niveles de derechos de acceso administrativos.

Primer nivel: los derechos administrativos para soportar la infraestructura de Lokad. Estos derechos son otorgados y monitoreados por la división de TI de Lokad.

Segundo nivel: los derechos de acceso administrativos dentro de cada cuenta de Lokad. Estos derechos son otorgados y monitoreados por el Supply Chain Scientist a cargo de la cuenta – para nuestras cuentas gestionadas. Alternativamente, estos derechos son otorgados y monitoreados por la propia empresa cliente si la cuenta no es gestionada directamente por Lokad/un Supply Chain Scientist.

3.15 ¿Sigue su política de restricción de acceso el principio de “mínimo privilegio”, donde solo se permite el tráfico necesario y aprobado?

Sí. Aplicamos el principio de mínimo privilegio (PoLP) a todos los niveles de acceso de nuestra infraestructura, incluido el tráfico de red. La severidad de las restricciones de acceso varía según el caso de uso. Por ejemplo, para algunos accesos, solo se permite un usuario específico y autenticado desde una dirección IP determinada. En otros escenarios, cualquiera en cualquier lugar puede acceder, como es el caso del contenido de nuestra CDN (Content Delivery Network).

Consulte también Authorization 3.3.

3.16 ¿Están restringidas las conexiones salientes desde el entorno de producción?

No, las conexiones salientes desde el entorno de producción no están restringidas de manera universal. Mientras que algunos servidores especializados, como los balanceadores de carga, tienen restricciones de salida, la mayoría de nuestros servidores no las tienen.

Nuestras VMs de producción requieren acceso a múltiples APIs externas. Una gran parte de estas APIs están alojadas en Microsoft Azure, con algunas excepciones como letsencrypt.org. Hemos determinado que mantener una lista blanca rigurosa de direcciones IP introduciría complejidades que podrían contrarrestar los beneficios. Restringir las conexiones salientes podría ofrecer ventajas de seguridad limitadas, pero también podría introducir complicaciones que potencialmente menoscaben la seguridad de nuestro entorno de producción.

3.17 ¿Existe una forma de comunicación con personal asignado (p. ej., correo electrónico, formulario web, teléfono, etc.) disponible para clientes/usuarios 24/7/365 para reportar incidentes de seguridad?

Sí, hemos implementado el estándar security.txt para facilitar el reporte de incidentes de seguridad.

El enfoque security.txt es un patrón ampliamente reconocido en la seguridad web donde se coloca un archivo de texto específico en el sitio web. Este archivo detalla cómo reportar vulnerabilidades de seguridad.

Nuestro archivo security.txt se puede encontrar en https://www.lokad.com/.well-known/security.txt y describe el proceso actualizado para reportar incidentes de seguridad. Esto garantiza que cualquier persona, ya sea un cliente, usuario o investigador de seguridad, pueda encontrar fácilmente los detalles de contacto pertinentes y las pautas sobre cómo reportar preocupaciones de seguridad a nosotros.

Tenga en cuenta que, si bien el proceso detallado en el ‘security.txt’ puede ser revisado, la información más actual y precisa siempre estará disponible en ese punto final. Aseguramos que los canales de comunicación mencionados en el archivo, ya sean correo electrónico, formulario web u otro medio, cuentan con personal asignado y están disponibles 24/7/365 para atender rápidamente los reportes de seguridad.

4. Gestión de Datos

4.1 ¿Dónde se alojan y procesan los datos?

Nuestra plataforma SaaS (Software as a Service) está alojada al 100% en Microsoft Azure; más precisamente, se aloja en el centro de datos Europe North de Microsoft Azure (con sede en Dublín). Nuestras copias de seguridad se almacenan en el centro de datos Europe West de Microsoft Azure (con sede en Ámsterdam). En caso de una falla importante en el centro de datos, contamos con planes de contingencia para migrar la plataforma a Dublín. Desde nuestra migración a Microsoft Azure en 2010, nunca hemos enfrentado esta situación. Todos los datos de nuestros clientes residen en Europa, donde permanecerán incluso ante una falla importante en el centro de datos.

4.2 ¿Quién es el propietario de los datos?

Nuestros clientes siguen siendo los únicos propietarios de todos los datos que cargan en Lokad. Nuestros clientes también son los únicos propietarios de todos los datos que generan, a través de su cuenta de Lokad, en la plataforma Lokad. Lokad no utiliza internamente los datos de los clientes para ningún propósito, aparte de aquellos que contribuyen directamente a las tareas que nuestros clientes nos han encargado realizar. Lokad no (re)vende el acceso a los datos de nuestros clientes a ningún tercero. Lokad no comparte el acceso a los datos del cliente, salvo para los pocos proveedores de alojamiento que contribuyen directamente a la tarea en cuestión (por ejemplo: alquilar máquinas virtuales de una plataforma de computación en la nube para ejecutar los cálculos según lo solicitado por nuestros clientes).

4.3 ¿Se gestiona la base de datos internamente o de forma externa?

La gestión de la capa de datos de Lokad es realizada por los equipos de ingeniería de Lokad. Como se mencionó anteriormente, la plataforma central de Lokad no incluye una base de datos transaccional (ver Authorization 3.6), ya que Lokad utiliza en su lugar un almacén de eventos. Este almacén de eventos es implementado y operado en su totalidad por Lokad.

4.4 ¿Tiene la solución la capacidad de cambiar entre una base de datos RDBMS (PostgreSQL, Oracle, MySQL) y una base de datos No-SQL (Cosmos)?

Teóricamente, sí, pero esto es irrelevante ya que la solución de Lokad no utiliza RDMBS. La capa de persistencia de datos de la solución de Lokad utiliza un almacén de eventos y un almacén de clave-valor. Este enfoque difiere sustancialmente del diseño CRUD (Create-Read-Update-Delete) que se encuentra comúnmente en el software empresarial. Dado que Lokad es una solución SaaS, asumimos la plena responsabilidad de la persistencia de datos y la compatibilidad futura (para asegurar que los datos antiguos sigan siendo accesibles).

4.5 ¿Hay terceros involucrados en la operación de la solución?

Sí, sobre todo la plataforma de computación en la nube subyacente que Lokad utiliza - Microsoft Azure. La lista de terceros involucrados en la operación de la solución es muy corta y se restringe al alojamiento de infraestructura de bajo nivel. Lokad no utiliza terceros para desarrollar, administrar u operar su propia solución. En particular, tanto nuestros equipos de ingeniería como nuestros equipos de soporte técnico son internos.

4.6 ¿Separa capas (redes, servidores y aplicaciones)?

Sí, sin embargo, la gestión de bajo nivel de redes y servidores se delega a la plataforma de computación en la nube subyacente que utiliza Lokad - Microsoft Azure. Por lo tanto, la separación de las capas de red y servidor se encuentra en gran medida fuera del perímetro gestionado por Lokad. Dentro de la solución de Lokad, restringimos fuertemente los privilegios otorgados a las capas aplicativas para que no puedan administrar su propia infraestructura (por ejemplo: las capas aplicativas no tienen acceso de escritura a la gestión del DNS).

4.7 ¿Tiene un proceso para asegurar la eliminación permanente de datos?

Sí, aunque puede tomar varias semanas completar todos los pasos. El proceso implica realizar una solicitud formal por escrito - emitida por una parte autorizada dentro de la organización del cliente - para que los datos correspondientes sean eliminados de forma permanente. En la práctica, disposiciones específicas para tales solicitudes se incluyen en el acuerdo contractual entre Lokad y sus clientes. Primero se eliminarán los datos de nuestro sistema de producción principal y luego del sistema de copias de seguridad. La última etapa es la causa de la relativa “lentitud” de la operación. Esta es una elección de diseño, ya que una vez que los datos se eliminan de nuestro sistema principal, no se pueden acceder de nuevo (salvo mediante procesos extraordinarios de recuperación ante desastres).

Por defecto, la solución de Lokad asegura que todas las operaciones estándar de eliminación sean borrados suaves (es decir, eliminaciones no permanentes). Este diseño es necesario para evitar clases enteras de problemas de seguridad, como la eliminación accidental de datos por parte de un empleado del cliente, o la eliminación maliciosa por un atacante. Además, se requiere un proceso intencionadamente lento de eliminación permanente para mitigar ataques de ingeniería social, como en un escenario en el que un atacante se hace pasar por un empleado de un cliente.

4.8 ¿Tiene la solución la capacidad de realizar borrados suaves de datos?

Sí. La solución de Lokad adopta un diseño de event sourcing. Como tal, todo se versiona por defecto, tanto las entradas de los usuarios como los cambios realizados en el sistema de archivos de Lokad. Por lo tanto, todas las eliminaciones de software son eliminaciones suaves, y estas pueden ser rastreadas y revertidas, según se desee.

4.9 ¿Ofrecen acceso directo a la base de datos?

Sí, en el sentido de que el sistema de archivos - parte de la solución de Lokad - puede ser accedido a través de protocolos como FTPS y SFTP. Este acceso es extenso, ya que todos los datos, ya sea que se utilicen como entradas o se produzcan como salidas, se almacenan en este sistema de archivos.

Sin embargo, dado que Lokad no tiene una base de datos transaccional, no existe una base de datos subyacente que pueda hacerse “accesible”. El equivalente más cercano en la arquitectura de Lokad es nuestro almacén de eventos y no ofrecemos acceso directo al flujo de eventos. No obstante, se podrían hacer provisiones en el acuerdo contractual si un cliente solicitara extracciones específicas de este flujo de eventos (suponiendo que exista un caso de uso válido).

4.10. ¿Cómo integra la solución datos externos?

La solución puede utilizar varios protocolos para integrar datos externos, siendo FTPS y SFTP los más destacados. También está disponible una interfaz de usuario web para cargar archivos manualmente. La solución de Lokad puede integrar cualquier dato razonablemente tabular. Para más información sobre las capacidades de integración externa de datos de Lokad, consulte Go to IT Perspective on Lokad 2.15.

4.11 ¿Tiene el sistema la capacidad de manejar captura de datos de cambios (CDC) de fuentes de datos en tiempo real?

Sí, bajo la estipulación de un acuerdo contractual específico con el cliente. La captura de datos de cambios es un patrón de diseño de software - no un estándar de datos específico ni un protocolo de transferencia de datos - y las expectativas de “tiempo real” pueden variar desde latencias de sub-milisegundo hasta sub-minuto. Las características en este ámbito deben evaluarse desde una perspectiva de supply chain. En nuestra experiencia, las fuentes de datos en tiempo real rara vez son relevantes para abordar problemas de supply chain.

4.12 ¿Se pueden exportar todos los datos dentro de la solución?

Sí, todos los datos accesibles a través del sistema de archivos dentro de la cuenta de Lokad pueden ser exportados mediante protocolos como FTPS o SFTP.

4.13 ¿Ofrece la solución herramientas para exportar datos?

Sí, la solución de Lokad ofrece un DSL (lenguaje específico de dominio) llamado Envision, hecho a la medida para análisis de supply chain. Envision ofrece amplias capacidades para reformatear los datos dentro de la cuenta de Lokad.

4.14 ¿Cuál será el formato de los datos exportados?

La plataforma de Lokad soporta todos los formatos tabulares comunes, incluyendo CSV y XLS (Microsoft Excel). La plataforma soporta numerosas opciones respecto al formato de números, fechas, delimitadores, codificación de texto, encabezados, etc.

4.15 ¿Tiene la solución cifrado transparente de datos (TDE) de datos de información personal identificable (PII) en el almacenamiento móvil y de back-end?

El cifrado transparente de datos se utiliza tanto en el almacenamiento de back-end de Lokad (mediante la encriptación de Azure Storage para datos en reposo) como en los dispositivos emitidos por Lokad (a través de BitLocker). Lokad no almacena PII en dispositivos sin TDE habilitado.

4.16 ¿Están todas las contraseñas y secretos utilizados dentro de la aplicación cifrados y no accesibles en formato de texto plano en el código fuente, archivos de configuración, parámetros de compilación, etc.?

Sí. Todos los secretos a nivel de plataforma se almacenan en Key Vault, un servicio ofrecido por Microsoft Azure. Las contraseñas de los usuarios se salan y se hashean internamente con Scrypt según las prácticas estándar.

4.17 ¿Tiene la solución la capacidad de restringir las cargas de archivos según el tipo y tamaño de los archivos, y de escanear en busca de contenido malicioso?

Sí, hasta cierto punto. En lo que respecta al tamaño de los archivos, la optimización de supply chain frecuentemente requiere que se procesen archivos grandes. Estos tamaños de archivo reflejan la extracción de los datos históricos de negocio que finalmente procesamos (ej: órdenes de venta históricas). Dada esta realidad, la plataforma de Lokad soporta tamaños de archivo de hasta 100GB.

En lo que respecta al tipo de archivo, tenemos una lista blanca de extensiones conocidas y formatos esperados. En el caso de que exista un caso de uso válido, este parámetro podría ajustarse. Este ajuste se reflejaría en nuestro acuerdo contractual.

En lo que respecta a la capacidad de escanear en busca de contenido malicioso, Lokad no cuenta con esta característica. Nuestra solución enfatiza compartir contenido generado por la plataforma. Además, el diseño que hemos adoptado asegura que los archivos generados en Lokad sean seguros, incluso si los archivos de entrada no lo son. Por el contrario, mediante su diseño, la solución de Lokad desincentiva el compartir contenido subido por los usuarios a través de Lokad.

4.18 ¿Cuál es el período de retención de datos recomendado?

Lokad es SaaS, por lo que asumimos la responsabilidad de elegir el período de retención de datos adecuado, y esta duración varía dependiendo del tipo de datos. Los datos históricos transaccionales, transmitidos a Lokad por el cliente a través de la canalización de extracción de datos, se conservan típicamente durante la duración del servicio de Lokad. De hecho, los datos históricos generalmente vale la pena conservarlos durante períodos arbitrariamente largos (fuera de los límites del servicio de Lokad). En el otro extremo del espectro, están los datos de instrumentación, que reflejan el rendimiento de nuestra plataforma a nivel muy granular. Estos datos son útiles únicamente para solucionar ralentizaciones inesperadas dentro de la plataforma. Estos datos son extremadamente detallados y generalmente no se conservan por más de unas pocas semanas.

4.19 ¿Proporcionan documentación de la estructura de datos?

Sí, como parte del “Joint Procedure Manual”. Cabe señalar que Lokad no utiliza una base de datos relacional, a diferencia de la mayoría del software empresarial. En su lugar, utilizamos un paradigma de event sourcing. Sin embargo, las estructuras de datos de interés (para la empresa cliente) no se encuentran en la fuente de eventos, sino en los archivos planos producidos mediante scripts de Envision dentro de la plataforma de Lokad. Estos archivos planos están diseñados para coincidir con los requisitos específicos de la empresa cliente. La documentación de estos archivos se incluye en el “Joint Procedure Manual” - que es uno de los entregables en una iniciativa típica de Lokad.

4.20 ¿Es la segmentación de datos de otros clientes parte del diseño del sistema?

Sí, aunque Lokad es una aplicación multi-inquilino, los datos se separan a nivel de diseño entre los inquilinos, es decir, las cuentas de cliente. Este particionamiento es una prioridad en el diseño de nuestro back-end. Este diseño previene errores de programación que podrían exponer los datos de un inquilino a otro, al tiempo que se desarrollan características rutinarias dentro de la plataforma. El almacenamiento subyacente principal utilizado por Lokad – Blob Storage de Microsoft Azure – facilita este tipo de particionamiento estricto a nivel de diseño.

4.21 ¿Se toman medidas efectivas para asegurar que ningún dato de cliente se utilice en los entornos de desarrollo y pruebas?

Sí, por defecto, el equipo de ingeniería de software no tiene acceso directo a los datos de los clientes. Hemos desarrollado amplios entornos de datos ‘mock’ y conjuntos de datos ‘mock’ para permitir que el equipo de ingeniería opere sin inconvenientes sin acceder a los datos de los clientes. Lokad también utiliza internamente su propia plataforma para procesamiento de datos (ej: analizando el consumo detallado de computación en la nube obtenido de Microsoft Azure). Esta práctica de ‘dogfooding’ asegura que Lokad cuente con un abundante suministro de datos no críticos para usar en desarrollo y pruebas.

Sin embargo, hemos diseñado una canalización restringida especial para acceder a fragmentos mínimos (de solo lectura) de datos de clientes con fines diagnósticos. Esta canalización asegura automáticamente una minimización estricta y totalmente automatizada de los datos que se recuperan. Esta canalización también asegura la eliminación automática de los datos al final de la operación diagnóstica. Ver 4.22 para más detalles sobre esta canalización restringida.

4.22 Si el desarrollo o las pruebas requieren el uso limitado de datos de clientes, ¿existe un proceso definido para asegurar la destrucción segura y completa de los datos en los entornos de desarrollo y pruebas?

Sí, hemos diseñado una canalización de datos especial (de solo lectura) dedicada al uso excepcional de datos de clientes para fines diagnósticos - usualmente pruebas de rendimiento. Esta canalización de datos es accesible únicamente para una porción restringida del equipo de ingeniería de software.

Esta canalización de datos ha sido diseñada para minimizar automáticamente el fragmento de datos de cliente que se recupera para el diagnóstico de interés. Esta capacidad nos permite operar con lo que típicamente equivale a una fracción muy pequeña de los datos originales (tal como se encuentran en la cuenta del cliente). Además, elimina la necesidad de que el equipo de ingeniería seleccione manualmente qué datos recuperar.

Finalmente, esta canalización de datos elimina automáticamente los datos recuperados al final de la operación diagnóstica.

4.23 ¿Están todas las ubicaciones físicas de los datos de los clientes conocidas y documentadas, incluyendo sistemas de respaldo y alta disponibilidad?

Sí. Todos los datos de los clientes se almacenan en los centros de datos físicamente seguros de Microsoft Azure, incluyendo los respaldos. No guardamos datos de clientes localmente (es decir, en las instalaciones de Lokad), ni se almacenan en los dispositivos de los empleados.

4.24 ¿Está el acceso a las ubicaciones físicas de los servidores limitado a los empleados que lo requieren para realizar su trabajo?

Sí, aunque los datos de los clientes de Lokad se almacenan en los centros de datos seguros de Microsoft Azure - una ubicación a la que Lokad no tiene acceso físico. La ubicación física de los centros de datos de Microsoft es de conocimiento público, y la elección de centros de datos de Lokad está documentada públicamente.

4.25 ¿Se almacena el Número de Cuenta Principal (PAN) solo si es absolutamente necesario para fines comerciales legítimos?

Lokad no recibe, almacena ni gestiona ningún PAN de cliente.

El PAN (Primary Account Number) usualmente se refiere al número principal en una tarjeta de crédito o débito. Es la secuencia de números en relieve o impresa en el frente de una tarjeta y se utiliza para identificar de forma única la cuenta bancaria asociada a la misma.

Para procesar pagos, confiamos exclusivamente en terceros que gestionan los PAN para nosotros. Sin embargo, cabe señalar que la mayoría de las transacciones recibidas por Lokad se ejecutan mediante transferencia bancaria, eliminando por completo el problema de la gestión de los PAN.

Tenemos algunos PANs – para las tarjetas propias de Lokad – que gestionamos de forma segura, siguiendo las directrices proporcionadas por los propios bancos.

4.26 ¿Nunca se envían los PANs (Primary Account Numbers) sin cifrar a través de tecnologías de mensajería para el usuario final (por ejemplo: por correo electrónico, mensajería instantánea y chat)?

Sí, los PANs sin cifrar (Primary Account Numbers) nunca se envían a través de canales inseguros como el correo electrónico. Lokad ofrece un canal de comunicación seguro incorporado en su plataforma, que es una alternativa superior para transmitir materiales sensibles. Recomendamos este canal siempre que el uso de un canal inseguro represente un riesgo comercial significativo.

Nota: Por diseño, Lokad no recibe, almacena ni gestiona ningún PAN de cliente. Por lo tanto, no existen transferencias de PAN sin cifrar.

Ver también el almacenamiento de los PANs

4.27 ¿Tienen un contrato con su(s) proveedor(es) de servicios de computación en la nube y contiene este contrato cláusulas relacionadas con los acuerdos de seguridad de la información del(los) proveedor(es) de servicios de computación en la nube?

Sí, Lokad tiene un Acuerdo Empresarial (EA) establecido con Microsoft para los servicios de computación en la nube de Azure. El Acuerdo Empresarial típicamente incluye diversos términos y condiciones relacionados con el uso de los servicios, incluyendo compromisos sobre la seguridad del entorno de la nube.

Microsoft Azure, como uno de los proveedores líderes de servicios en la nube, pone un alto énfasis en la seguridad. Azure cuenta con un conjunto integral de características y prácticas de seguridad para proteger los datos en la nube, y estas a menudo se reflejan en sus acuerdos contractuales con clientes empresariales.

Aunque no podemos divulgar públicamente los detalles específicos de nuestro acuerdo contractual, después de más de una década de colaboración con Microsoft, estamos satisfechos de que este acuerdo cumple con nuestros requisitos y estándares de seguridad.

4.28 ¿Participa algún subcontratista en el procesamiento de los detalles/datos del cliente?

No, Lokad no subcontrata el procesamiento de los detalles o datos de los clientes. En lo que respecta a la plataforma de Lokad, compramos recursos de computación – mayormente máquinas virtuales y blob storage – de Microsoft Azure, pero aparte de eso no intervienen terceros en lo que se refiere a los datos de los clientes.

En cuanto a la provisión de los servicios profesionales de Lokad, solo los empleados de tiempo completo de Lokad (en este caso, los supply chain scientists) tienen acceso a los detalles o datos de los clientes. Lokad ocasionalmente cuenta con algunos pasantes (aunque muchos menos que la mayoría de las empresas comparables) para pasantías a largo plazo, pero operan bajo la supervisión directa y estricta de un senior supply chain scientist.

Nota: Los pasantes están sujetos a los mismos acuerdos de confidencialidad que los full-time supply chain scientists.

5. Registro y monitoreo

5.1 ¿Ofrecen logs de acceso (usuario, fecha, última fecha de conexión, etc.)?

Sí. Lokad proporciona logs de acceso formateados como archivos CSV. En este momento, estos logs pueden solicitarse al personal de soporte de Lokad. La extracción de logs se colocará en la cuenta de Lokad en un lugar accesible solo para usuarios con designación de “Owner”. Planeamos introducir un método de acceso más directo - a través de una interfaz web dedicada - al rastro de auditoría completo que ya existe en el back-end de la plataforma de Lokad.

5.2 ¿Centralizan los logs de todos los componentes en la solución?

Sí. El diseño de event sourcing de Lokad centraliza no solo los logs, sino todos los cambios de estado que ocurren en la solución. Los logs, junto con otros cambios de estado, se centralizan en una pequeña colección de flujos de eventos, gestionados por el mismo almacén de eventos. Internamente, los logs que no afectan el estado de la solución se segregan de aquellos que sí lo hacen.

Desde una perspectiva puramente técnica, hay algunos logs relacionados con el rendimiento que intencionadamente no se centralizan dentro del almacén de eventos. Estos logs incluyen mediciones de rendimiento a nivel fino, como las producidas por la instrumentación interna de perfilado de rendimiento de Lokad (ej: cuántos milisegundos se invierten en cada llamada a función durante la ejecución de un script de Envision). Estos logs de rendimiento no contienen nada que se califique como material “relacionado con la seguridad”.

5.3 ¿Registran los cambios y operaciones realizados en la aplicación? ¿Llevan un seguimiento de todas las transacciones?

Sí. Debido al diseño de event sourcing de Lokad, todo se registra por necesidad. De hecho, la solución en sí es la suma de la colección de eventos registrados dentro de la misma. Por lo tanto, el registro es un aspecto fundamental de la arquitectura de la solución. Este diseño de event sourcing previene la omisión accidental de un log que refleje un cambio de estado. Bajo tal marco de event sourcing, no existen transacciones, al menos no en el sentido habitual de una base de datos transaccional (ej: MySQL, Oracle, etc.). Estas transacciones son reemplazadas por eventos que contienen toda la información asociada con un cambio de estado.

5.4 ¿Normalizan los formatos de los logs de los diversos componentes para fines forenses?

Sí. Los “logs”, desde el punto de vista de auditoría y/o seguridad, son las transformaciones de los eventos subyacentes. Los eventos son técnicamente objetos serializados. Para obtener logs, la solución de Lokad convierte y compila estos eventos en archivos CSV. Normalizamos los formatos de fecha, formatos numéricos y identificadores de usuario que se utilizan en la extracción a CSV.

5.5 ¿Ofrecen exportaciones de logs a terceros a través de algún protocolo de consulta?

Sí, bajo la condición de un acuerdo contractual con el cliente.

5.6 ¿Rastrean todas las excepciones generadas en su solución?

Sí. El diseño de event sourcing de Lokad nos permite rastrear todas las excepciones generadas en nuestra solución y reproducir las condiciones que llevaron al problema en primer lugar. Una vez identificadas, el equipo de ingeniería de Lokad elimina todas las excepciones observadas. Hemos creado herramientas dedicadas para este propósito específico, y mantenemos un backlog muy limitado de excepciones sin corregir.

5.7 ¿Tiene la solución la capacidad de monitorear la salud de los diferentes componentes/servicios en tiempo real?

Sí. Nuestros subsistemas han sido diseñados con endpoints de monitoreo dedicados a chequeos de salud. Contamos con herramientas de monitoreo, accesibles únicamente - a partir de enero de 2023 - para los equipos de ingeniería de Lokad que consolidan de forma continua la información proporcionada por dichos endpoints de monitoreo. Como se mencionó anteriormente, “en tiempo real” es bastante vago cuando se trata de sistemas distribuidos. Para propósitos de monitoreo de la salud del sistema, la latencia esperada varía desde unos pocos segundos hasta aproximadamente un minuto.

5.8 ¿Tiene la solución la capacidad de integrar herramientas de monitoreo de terceros? ¿Soporta la solución SNMP o JMX, o la capacidad de enviar eventos SNMP y JMX a soluciones de monitoreo de terceros?

Sí, en virtud de un acuerdo contractual dedicado.

5.9 ¿Tiene la solución la capacidad de monitorear trabajos por lotes que no se iniciaron según el cronograma y monitorear su finalización?

Sí. La solución Lokad tiene su propio programador de tareas interno (llamado “Runflow”) para orquestar tareas de larga duración dentro de la plataforma Lokad - típicamente la ejecución de scripts Envision. Este programador puede ser configurado, a través de una interfaz web, para especificar un cronograma y un marco temporal de ejecución para cualquier secuencia de trabajos.

5.10 ¿Tiene la solución la capacidad de generar alertas proactivas? ¿Tiene la capacidad de correlacionar y analizar errores, y luego tomar acciones proactivas?

Sí. Runflow, el programador de tareas de la solución, puede alertar al cliente/Lokad de que una secuencia de ejecución en curso se está demorando. La alerta puede enviarse antes de la finalización de la secuencia. La solución Lokad ofrece amplias capacidades a través de Envision (su DSL) para analizar y autodiagnosticarse de situaciones a fin de tomar una acción proactiva. Si bien la plataforma Lokad proporciona esta capacidad, aún se requiere que un ingeniero implemente - a través de Envision - la lógica real, ya que las situaciones de supply chain que se califican como “errores” pueden variar.

5.11 ¿Tiene la solución capacidades de retención de datos de auditoría? ¿Se archivan y eliminan los datos en una base de datos MIS para auditar la actividad de los usuarios?

Sí. A través de su diseño de event sourcing, la solución Lokad preserva un extenso rastro de auditoría; mucho mayor que lo obtenido mediante diseños más convencionales que típicamente aprovechan una base de datos transaccional en lugar de un almacén de eventos. La solución Lokad no aísla un Sistema de Información de Gestión (MIS) como un subsistema separado. De hecho, el flujo de eventos es el rastro de auditoría. Más en general, Lokad retiene los datos de producción durante la duración del servicio con el cliente. Al terminar el servicio, lo cual depende de los términos contractuales negociados, los datos del cliente se eliminan, aunque la eliminación final dentro del sistema de respaldo podría ocurrir unos meses después del fin del contrato.

5.12 ¿Integra su sistema un mecanismo de auto-monitoreo (técnico y funcional)?

Sí, la plataforma Lokad integra múltiples mecanismos de auto-monitoreo en varios niveles.

La plataforma alojada en la nube es monitoreada por los equipos de ingeniería de software de Lokad. Dado que la plataforma Lokad es multicliente, este monitoreo se realiza en gran medida con una mentalidad de “sistema”, asegurando que las capacidades de la plataforma (incluyendo su perfil de rendimiento) cumplan con los estándares. Hemos diseñado nuestra propia capa de instrumentación para este propósito. El monitoreo “funcional” es típicamente específico del cliente, ya que depende de las particularidades del supply chain dado. Este monitoreo es típicamente proporcionado por los equipos de supply chain scientists (los ingenieros proporcionados por Lokad), según lo estipulado en el contrato.

Los supply chain scientists de Lokad se especializan típicamente en una clase particular de cuenta de cliente (por ejemplo, aeroespacial). Ellos diseñan instrumentación de monitoreo hecha a la medida utilizando la cuenta Lokad. Este monitoreo incluye asegurarse de que los números entregados por Lokad sean correctos, no solo en un sentido técnico, sino también desde la perspectiva del negocio del cliente.

5.13 ¿Se revisan y analizan los logs de manera oportuna y sistemática, para detectar anomalías e indicios de brechas?

Sí. Revisar la actividad en curso de la plataforma Lokad es parte de nuestra rutina diaria. El diseño de nuestra plataforma facilita este proceso.

Ver también Logging and Monitoring 5.2.

5.14 ¿Son los sistemas de gestión de logs administrados por personas que no están involucradas en la administración de los otros sistemas (es decir, segregación de funciones)?

Sí. La supervisión de los logs y la actividad general de la plataforma es realizada por Supply Chain Scientists, mientras que la administración general de nuestra infraestructura es llevada a cabo por empleados específicos dentro de nuestra división de IT.

5.15 ¿Se realizan escaneos de vulnerabilidades a nivel de aplicación de forma periódica y sistemática?

Sí, aunque dichos escaneos son una parte muy pequeña de nuestros procesos de seguridad. Ver Employees 6.6.

5.16 ¿Existe un proceso definido para la revisión periódica de las reglas de firewall efectivas?

Sí, nuestra máquina de producción viene con reglas muy estrictas, como la apertura de un número muy limitado de puertos (configurados a través de Microsoft Azure). La configuración de nuestra infraestructura está automatizada mediante scripts, y su evolución sigue nuestro usual proceso de revisión de código. Esta práctica no solo facilita las revisiones periódicas, sino que también mitiga la necesidad de revisar manualmente las reglas desde el principio.

5.17 ¿Está la red equipada con tecnología IDS (Sistema de Detección de Intrusiones)?

No. IDS es un diseño inherentemente peligroso ya que viola el principio de seguridad de “mínimos privilegios”: a un componente se le otorgan enormes privilegios para operar como un “hombre en el medio”. Esto convierte al IDS en un objetivo principal para los atacantes, y extiende enormemente la superficie de ataque de la plataforma. Sin embargo, Lokad monitorea de cerca su tráfico web, y los comportamientos anómalos de usuarios en nuestra propia plataforma. Estas capacidades, sin embargo, son parte de la plataforma en sí y, por lo tanto, no se delegan a componentes de software aislados y con privilegios especiales de terceros.

Ver también Employees 6.6.

6. Empleados

6.1 ¿Tienen los empleados acuerdos de confidencialidad (NDAs)?

Sí, todos los empleados de Lokad están sujetos a una cláusula de NDA en sus contratos de empleo.

6.2 ¿Reciben los empleados capacitación en concienciación y formación en seguridad?

Sí, se proporciona capacitación en concienciación y formación en seguridad a los empleados de Lokad que están en contacto con datos confidenciales y/o sistemas de ingeniería que manejan datos confidenciales. Para más información sobre este punto, la conferencia Cybersecurity for Supply Chain está dedicada a los supply chain scientists, las personas que manejan datos confidenciales de los clientes.

6.3 ¿Quién tiene acceso a los datos del cliente en Lokad?

El cliente define explícitamente una lista de usuarios que tienen acceso a su cuenta de Lokad. Estos usuarios, dependiendo de sus derechos de acceso configurados dentro de la cuenta de Lokad, pueden tener acceso a varias clases de datos del cliente. Existe una aplicación web dentro de la solución Lokad dedicada a gestionar los permisos (llamada “Hub”).

Por parte de Lokad, para cada cuenta de cliente existe una breve lista de empleados que tienen acceso. Ante todo, esta lista incluye a los supply chain scientists (los ingenieros proporcionados por Lokad) que implementan y mantienen la solución de optimización de supply chain. Se espera que estos supply chain scientists accedan a los datos del cliente diariamente. Internamente, Lokad restringe el acceso a la cuenta del cliente únicamente a los supply chain scientists asignados a dichas cuentas. Es decir, Supply Chain Scientist A no puede acceder a la Cuenta de Cliente B a menos que A haya sido asignado explícitamente para gestionar esta cuenta (según lo acordado con el cliente).

En segundo lugar, esta lista incluye al equipo de ingeniería encargado de la administración del sistema de nuestra plataforma. En términos generales, el acceso directo a los datos del cliente es poco frecuente y se limita a investigar situaciones reportadas ya sea por los propios clientes o por sus supply chain scientists de soporte. Lokad no comparte el acceso a los datos del cliente con ningún tercero, con la excepción de la plataforma de computación en la nube.

6.4 ¿Cómo aseguran los puestos de trabajo de los empleados?

Excepto el equipo de ingeniería de software, los empleados de Lokad operan sin privilegios administrativos en sus dispositivos proporcionados por la empresa. Todos los puestos de trabajo están configurados con cifrado de disco completo para proteger contra el robo de datos que podría ser causado por la pérdida, robo o confianza en terceros (por ejemplo, para reparaciones) del hardware.

Los puestos de trabajo utilizados por nuestros empleados no contienen los datos de nuestros clientes. Dependiendo de la tarea en cuestión, un empleado puede descargar unas cuantas hojas Excel en su máquina -para hacer una presentación, por ejemplo- pero nuestra política es mantener estrictamente todos los datos del cliente seguros en la nube.

6.5 ¿Cómo aseguran los smartphones de los empleados?

Los empleados de Lokad no tienen smartphones emitidos por la empresa. Los datos no críticos, como los recordatorios del calendario, pueden enviarse a través de dispositivos personales (no emitidos por la empresa), pero los smartphones, al igual que los puestos de trabajo, no contienen los datos de nuestros clientes.

6.6 ¿Utilizan un antivirus?

Sí, nuestros puestos de trabajo tienen Microsoft Defender, según las configuraciones de Microsoft Windows 10+. No utilizamos otro antivirus además de Microsoft Defender, pero nuestra postura es que esta clase de herramienta tiende a hacer más daño que bien (en términos de seguridad informática). A título anecdótico, el hackeo de SolarWinds de 2020 es considerado una de las mayores catástrofes en seguridad informática de todos los tiempos, y fue causado por un software que se suponía que mejoraría la seguridad desde el inicio. En términos generales, casi todos los productos de software destinados a fines de seguridad requieren privilegios del sistema bastante altos. Como resultado, estos productos se convierten en sus propios vectores de ataque. Nuestra perspectiva sobre la seguridad informática es que menos es más, y que agregar piezas tecnológicas muy complejas a nuestro panorama aplicativo casi invariablemente lo hace menos seguro, no más seguro.

6.7 ¿Se capacita periódicamente a los desarrolladores de software para utilizar métodos de evaluación de amenazas, estándares de codificación segura, listas de verificación de seguridad conocidas y marcos de trabajo?

Sí. Sin embargo, la mayoría de las listas de verificación conocidas reflejan principalmente arquitecturas que son “inseguras por diseño”. Siempre que es posible, preferimos eliminar la fuente de los problemas de seguridad en la etapa de diseño. Ver también Employees 6.2.

6.8 ¿Incluyen todos los contratos con los subcontratistas/plantilla externa de Lokad un Acuerdo de Confidencialidad (NDA)? ¿Cubre este NDA la información de los clientes?

Sí a ambos, aunque Lokad - al momento de redactar - no depende de subcontratistas/una plantilla externa. Los equipos de ingeniería de software y de supply chain scientists de Lokad están compuestos completamente por personas bajo empleo directo y permanente y la supervisión de Lokad.

Sin embargo, si Lokad considerara necesario contratar a un subcontratista, este estaría sujeto a los mismos términos de Propiedad Intelectual (IP) y NDA que nuestros empleados permanentes. Estos acuerdos incluyen términos relacionados con la información sobre los clientes de Lokad.

6.9 ¿Ha recibido toda la plantilla externa de Lokad la formación de inducción en información interna y seguridad de Lokad (y la formación continua relevante)?

Lokad - al momento de redactar - no depende de subcontratistas/una plantilla externa. Los equipos de ingeniería de software y de supply chain scientists de Lokad están compuestos completamente por personas bajo empleo directo y permanente y la supervisión de Lokad.

Sin embargo, si Lokad considerara necesario contratar una plantilla externa, este sería un requisito. Todos los subcontratistas/trabajadores externos estarían sujetos a los mismos procesos de seguridad y requisitos de formación que nuestros empleados permanentes.

Como se indicó anteriormente, actualmente Lokad no depende de una plantilla externa, por lo que no se realiza dicha formación.

Ver también Employees 6.8

6.10 ¿Incluyen todos los contratos con las empresas que proveen la plantilla externa de Lokad (cualquiera y todos los contratistas, consultores, etc., que participan en la prestación de los servicios de Lokad) que los trabajadores externos sean sometidos a verificación de antecedentes? ¿Están estas verificaciones de antecedentes de acuerdo con el nivel correspondiente de acceso a la información y la criticidad del rol del empleado?

Lokad - al momento de redactar - no depende de subcontratistas/una plantilla externa. Los equipos de ingeniería de software y de supply chain scientists de Lokad están compuestos completamente por personas bajo empleo directo y permanente y la supervisión de Lokad.

Sin embargo, si Lokad considerara necesario contratar una plantilla externa, este sería un requisito. Todos los subcontratistas/trabajadores externos estarían sujetos a los mismos procesos de seguridad, verificaciones de antecedentes y requisitos de formación que nuestros empleados permanentes.

Nota: Hablando históricamente, muchos de los incidentes más grandes - y peores - (como el ciberespionaje) han sido cometidos por personas con historiales impecables. Esto, entre otras razones, es por lo que Lokad se muestra reacio a depender de una plantilla externa y prefiere firmemente contratos de empleo directos y de duración indefinida.

6.11 ¿Se deshabilitan o eliminan automáticamente las cuentas administrativas al finalizar el empleo?

Sí. Todos los empleados de Lokad reciben sus derechos de acceso a través de un proveedor de identidad federada (Microsoft Azure Active Directory). Al finalizar su empleo, si corresponde, este acceso es revocado, deshabilitando así automáticamente todos los derechos administrativos asociados.

Nota: A la mayoría de los empleados de Lokad nunca se les otorgan derechos administrativos, ya que no son necesarios para la ejecución de sus funciones.

6.12 ¿Realizan verificaciones de antecedentes penales a todo el personal que tiene acceso a datos sensibles, datos financieros, datos bancarios, datos de tarjetas de pago, etc.?

Sí, se realizan verificaciones de antecedentes de forma estricta de acuerdo con los requisitos del trabajo desempeñado.

Se debe notar que Lokad no gestiona internamente los datos de tarjetas de pago; estos son gestionados por terceros. Por lo tanto, el personal de Lokad no tiene acceso a ningún dato de tarjeta de pago de nuestros clientes.

6.13 ¿Qué precauciones toma Lokad para asegurar que el personal no autorizado no pueda acceder a las instalaciones donde se realiza el trabajo?

A nivel de edificio, Lokad opera en un edificio de oficinas que cuenta con vigilancia de terceros las 24 horas del día, los 7 días de la semana, con seguridad con personal en el sitio. En el nivel de la oficina, las instalaciones de Lokad tienen sus propios puntos de acceso seguros, independientes de los del edificio. Esta última capa impide que empleados de otras empresas dentro del edificio accedan a las oficinas de Lokad.

Nota: cualquier visitante excepcional (como clientes, posibles candidatos, etc.) debe ser recibido físicamente y se le debe permitir el acceso por miembros del personal de Lokad.

6.14 ¿Se permite la entrada de visitantes en la instalación?

Si “facility” significa “el lugar donde se almacenan y procesan los datos del cliente”, entonces no. Los datos del cliente se almacenan en los centros de datos de Microsoft Azure. Estos centros de datos no están abiertos al público - Lokad mismo no puede acceder a ellos.

Sin embargo, Lokad ocasionalmente da la bienvenida a visitantes en su sede corporativa. Nuestras oficinas no están abiertas al público, pero en ocasiones surgen circunstancias excepcionales, como visitas de clientes, candidatos a empleo esperando una entrevista, etc. Tales visitas se planifican con antelación y dichos visitantes van acompañados en todo momento por miembros del personal de Lokad mientras se encuentran en nuestras oficinas.

6.15 ¿Se almacenan registros de datos en papel (y medios electrónicos extraíbles que contienen datos) en gabinetes ignífugos seguros durante la noche?

Lokad no opera con registros de datos en papel, ni tampoco utiliza medios electrónicos extraíbles. Dado que no tenemos registros físicos para almacenar, Lokad no necesita gabinetes ignífugos.

Aunque en ocasiones podamos imprimir un documento (Lokad imprime muy pocos documentos, si es que imprime alguno), también contamos con una trituradora junto a la impresora. La política predeterminada de Lokad es no imprimir ningún documento sensible, pero si teóricamente tuviera que hacerse, nuestra política por defecto es destruir el documento impreso inmediatamente después de su uso.

6.16 ¿Existe una política de escritorio despejado? En caso afirmativo, ¿hasta qué punto?

Sí, Lokad opera con una política de escritorio despejado estrictamente implementada. Esta política se aplica “by design” a través de nuestro entorno digital.

Excepto por unos pocos documentos que estamos legalmente obligados a imprimir, o documentos ocasionales que se imprimen por necesidad (por ejemplo, un cartel para una feria comercial, aunque incluso esto normalmente se subcontrata), el entorno de trabajo de Lokad es estrictamente digital.

Así, al final del día, los empleados de Lokad no tienen nada que despejar. Una vez que la sesión informática del empleado se ha bloqueado -una política que aplicamos de forma estricta- el escritorio en cuestión se considera despejado.

6.17 ¿Dónde llegan los faxes y quién podría tener acceso a ellos?

Lokad nunca ha tenido una máquina de fax, ya sea física o virtual. No conocemos ningún caso de uso convincente que justifique un cambio en nuestra postura respecto a esta tecnología.

6.18 ¿Existe un proceso para verificar la devolución de los activos constituyentes (computadoras, teléfonos móviles, tarjetas de acceso, tokens, tarjetas inteligentes, llaves, etc.) tras la terminación?

Sí, no solo contamos con un proceso establecido, sino también con un software de gestión de activos informáticos que respalda este esfuerzo y minimiza la cantidad de errores administrativos.

Sin embargo, hemos diseñado deliberadamente la seguridad de Lokad para no depender de la devolución oportuna de los activos constituyentes. Lokad asume que existe una probabilidad razonable de que cualquiera de estos activos se pierda o sea robado, sin importar lo disciplinados y capacitados que puedan estar nuestros empleados. En la práctica, esto ocurre muy raramente, pero desde una perspectiva de ingeniería, asumimos lo contrario. Por esta razón, los activos constituyentes pueden ser deshabilitados de forma remota. Además, aplicamos cifrado completo de disco siempre que es aplicable.

Más generalmente, el entorno de trabajo ha sido diseñado para no requerir almacenamiento persistente de datos del cliente en estaciones de trabajo, portátiles o teléfonos móviles. Este diseño alivia considerablemente la criticidad de los activos constituyentes en el caso de que fallaran nuestras otras medidas preventivas.

6.19 ¿Son aprobadas las políticas y/o procedimientos de Recursos Humanos (HR) por la dirección y comunicadas a los interesados, y se designa un responsable para mantenerlas y revisarlas?

Sí, nuestras políticas y procedimientos de Recursos Humanos han sido formalmente aprobados por la alta dirección. Ponemos un fuerte énfasis en la comunicación clara, y como tal, estas políticas y procedimientos han sido difundidos minuciosamente a todos los interesados relevantes para garantizar una comprensión y cumplimiento completos.

Además, hemos designado a un responsable que se encarga del mantenimiento continuo, las actualizaciones y la revisión regular de las políticas y procedimientos. Esto asegura que nuestras prácticas se mantengan actuales, relevantes y alineadas tanto con los estándares de la industria como con nuestros objetivos organizacionales.

6.20 ¿Existen dispositivos móviles personales (BYOD), en lugar de dispositivos de la empresa, utilizados por individuos asociados con su organización que tienen acceso a los datos del cliente?

No, Lokad no permite el acceso a los datos del cliente en dispositivos móviles personales (BYOD). Proveemos a nuestros empleados hardware de alta calidad, propiedad de la empresa, eliminando la necesidad de dispositivos personales. Esta disposición aborda el escenario común en el que los empleados recurren al uso de sus propios dispositivos debido a la insatisfacción con el hardware deficiente de la empresa.

Además, nuestros protocolos operativos están diseñados de tal manera que, incluso en nuestros dispositivos de propiedad de la empresa, los datos del cliente no se almacenan de forma permanente. Todo el procesamiento de datos ocurre dentro de nuestra plataforma basada en la nube. En los dispositivos del empleado, los datos del cliente (si es que se accede a ellos) se manejan de forma transitoria y solo en segmentos mínimos, garantizando la máxima seguridad.

Notas