Introducción

Durante el último tiempo hemos tenido la oportunidad de evaluar un número importante plataformas de telemedicina 👨‍⚕️👩🏻‍⚕️ de distintas partes del mundo, tanto de Europa (🇪🇺), Norteamérica (🇺🇸) como también de Latinoamérica. Si bien por cuestiones lógicas no podemos revelar el nombre de cada una de las plataformas, este artículo reúne algunos aspectos que consideramos que podrían ser de valor, tanto para quien deba evaluar una plataforma de estas características como para quien diseñe o construya este tipo de productos (o esté pensando en hacerlo)🚀.

• Organización – Equipo de trabajo. Los equipos de trabajo que están detrás de estas plataformas generalmente son multidisciplinarios, administradores de sistemas, desarrolladores, analistas funcionales. Sin embargo, no es frecuente encontrar la posición de CISO o referente de seguridad. Cuando consultas sobre este rol, generalmente está “distribuido entre todos los roles, ya que la seguridad es un pilar de nuestro producto”. Sin embargo no tienen el rol específico de seguridad como posición, algo que es un requerimiento específico en los RFP o assessment de terceros.
• Metodología de trabajo. En todos los casos la metodología de trabajo está orientada a principios “ágiles”, aplicando #DEVOPS (y scrum). Esto es algo presente en todos los productos evaluados y podría considerarse una tendencia de aquellas empresas que buscan reducir fuertemente el “time to market” siguiendo principios ágiles y metodologías actuales.

<aside> ⚠️ Sin embargo, en ningún caso se está trabajando en #SECDEVOPS para incluir a la seguridad como parte fundamental del proceso de desarrollo del producto.

</aside>

El equipo #DEVOPS es quien consolida todas las funciones y quién determina qué, cómo y cuándo en materia de seguridad. Algunos aspectos de seguridad se ven favorecidos por la metodología empleada, ya que por ejemplo, el proceso de patch management está integrado generalmente por el proceso de delivery (diario o semanal) que consiste en desplegar paquetes actualizados de la plataforma, haciendo innecesario un proceso periódico, sin embargo, este “beneficio” no incluye el análisis de situaciones excepcionales, como la presencia de una amenaza de día cero. Es decir, las vulnerabilidades se consideran tales, siempre que exista un parche, para todo lo demás existe….riesgo 🚨. Formación en desarrollo seguro es algo inexistente, tal es el caso que ante la consulta sobre entrenamiento basado en OWASP TOP 10, suele recibirse una respuesta negativa. Pareciera que la formación descansa en los frameworks de desarrollo que son utilizados, sin considerar que quién desarrolla deba conocer cómo hacerlo en forma segura (al menos para entender un issue en un reporte posterior).

<aside> 💡 NOTA: Es importante mencionar que este punto es clave para interpretar todas las evidencias provistas por el proveedor, ya que en muchos casos confunden un test de intrusion con un escaneo de vulnerabilidades, o desconocen otros test como análisis dinámico o estático de código. Ni hablar de incluir aspectos de seguridad al momento de la toma de requisitos.

</aside>

• Métodos de despliegue. En todos los casos la plataforma está montada en una solución de cloud, Amazon y Azure llevan la delantera frente a otras opciones. El modelo de implementación generalmente es PaaS (las plataformas más inmaduras utilizan IaaS), algo que limita las responsabilidades respecto a la seguridad y la gestión de los servicios de IT. Sin embargo, al momento de solicitar una matriz de responsabilidades, generalmente no se ha definido y resulta complejo identificar quién es responsable por qué. El uso de plataformas de cloud ☁️, también favorece los aspectos de cumplimiento, ya que generalmente se muestran las certificaciones del proveedor como propias (pero no lo son). Por ejemplo, en el caso de una plataforma que deba cumplir PCI-DSS (💳), suelen mostrarse los certificados del proveedor de cloud y del gateway de pago, sin embargo, no incluyen los procesos propios del fabricante del producto, algo que resulta fundamental para lograr una certificación de la empresa (ya que PCI-DSS no certifica productos).

<aside> 📝 NOTA: Cuesta varias reuniones que entiendan que además del proveedor de cloud, el fabricante del producto también debería certificar sus procesos.

</aside>

• Cumplimiento. Todos los productos evaluados han presentado certificaciones, sin embargo, en su mayoría corresponden a plataformas de terceros, por ejemplo, el proveedor de cloud. Es decir, la empresa que ofrece el producto no está certificada, sino solo uno de sus partners. Al consultar respecto al “roadmap” de certificaciones, el mismo está principalmente orientado a las exigencies de los clientes, es decir, si nadie lo pide, no se hace. Las certificaciones más frecuentes que presentan son: PCI-DSS, SOC 1 & 2, ISO 27001, pero siempre de su proveedor de cloud o gateway de pago. En los casos en que han intentado obtener una certificación propia, los resultados han sido muy pobres, ya que se presentan “self-assessments” o reportes automatizados de herramientas, pero nada que represente una certificación de terceros acorde al estándar de la industria (una empresa reconocida, caminando y revisando cómo se hacen las cosas contra un estándar determinado). Como parte de los programas de seguridad en terceras partes, generalmente se utiliza un framework de referencia, por ejemplo ISO 27002, sin embargo, siendo un estándar ampliamente utilizado, son necesarias varias sesiones para que los equipos de trabajo interpreten los objetivos de control y sepan qué evidencia deben proveer. Es decir, no están familiarizados con los controles de seguridad más utilizados en el mercado. En este sentido, se suele hacer foco en lo que realmente impacta en el producto ofrecido, no siendo un requerimiento nunca el 100% de los controles implementados (sospechen si dicen que los tienen...).

• Algunos aspectos técnicos. Al momento de profundizar sobre aspectos técnicos de las plataformas bajo evaluación, surgen nuevos hallazgos que podrían ser de valor si están iniciando una actividad similar. Por ejemplo:

  • Cifrado en tránsito: TLS 1.2 o superior no está 100% desplegado, siendo posible encontrar conexiones que son aceptadas con protocolos inseguros, por cuestiones de compatibilidad. En algunos casos está permitido solo TLS 1.2, pero con suites de cifrado inseguras.

  • Cifrado en reposo: No está implementado como línea base, sino que depende del requerimiento del cliente (aunque estamos hablando de datos sensibles). En los casos en que está implementado, es AES 256. Sin embargo, se evidencian debilidades en el manejo de llaves, falta de procesos formales e independencia de llaves entre entornos. Es decir, el cifrado y todo lo que ello significa no está maduro.

  • Contraseñas: Si bien las plataformas bajo evaluación aceptaban la integración con otros mecanismos reconocidos, facilitando la “federación”, en general el método de autenticación más utilizado es “autenticación local”, tanto para medicos, pacientes, como para técnicos. No se ha implementado autenticación con mayor complejidad para acceso privilegiado o a datos sensibles, por ejemplo, 15.3. El doble factor es un requerimiento que no está considerado en ningún caso como parte de la solución estándar, dado que se considera “incómodo para el medico y/o el paciente”. Cabe señalar que los estándares actuales en la materia, establecen la autenticación de doble factor como un MUST en sistemas con información sensible o directamente expuestos a internet.

  • Captcha: En la version web se puede encontrar Captcha como control adicional al momento de la autenticación, sin embargo, no estuvo presente en el 100% de las plataformas evaluadas. Al momento de argumentar acerca de la ausencia de dicho control, se menciona que el medico suele requerir “acceso dinámico” y por ello este requisito adicional es muy criticado (es importante tener en cuenta que si los médicos no utilizan estos productos, el objetivo de negocio de la plataforma pierde su sentido).

  • Webservices: Todas las plataformas evaluadas cuentan con webservices que permiten integración con otras plataformas, así como consultas a distintos módulos desde sus clientes mobile (android o IOS). Sin embargo, al momento de profundizar en los métodos permitidos, así como si requieren autenticación, o filtrado e incluso la existencia de un test de intrusion para validar el funcionamiento de dichos webservices, en pocos casos se ha incluido dentro del set de pruebas. Por lo tanto, podemos concluir que incluso en los casos en donde se ha evaluado la seguridad de la plataforma, no se han incluido todos los componentes (se pierden vectores posibles de ataque).

  • Monitoreo: Como toda plataforma que maneja datos sensibles, el monitoreo de la actividad de los usuarios y/o servicios es un requerimiento mandatorio en los tiempos que corren, sin embargo, en las plataformas evaluadas, la generación de pistas de auditoria no ha sido considerado parte de la propuesta estándar, es decir, si quieres auditoria es considerado un “requerimiento especial”. La oferta técnica cuando se requiere auditoria no es muy flexible, generalmente ofrecen registros de auditoria en una tabla o archivo, que luego se debe extraer y consolidar del lado del cliente. La posibilidad de visualizar en un reporte o en una consola disponible para fines de auditoria no forma parte de la oferta estándar. Por cierto, los eventos se deben obtener directamente desde su origen y estandarizarse fuera del producto (todo indica que no están muy enfocados en el control y monitoreo, si tú lo quieres hacer, suerte!).

  • SDLC: Si bien las plataformas evaluadas cuentan con procesos de desarrollo ágil, principalmente soportados por la metodología scrum y conformación de equipos DEVOPS, en ningún caso los aspectos de seguridad fueron considerados desde el inicio del proyecto, o bien, consideran que la “seguridad” es el test de intrusion que realizan antes del “Go Live”. Sin embargo, en algunos casos el “test de intrusion”, no es más que un escaneo de vulnerabilidades sin autenticar (se imaginan el nivel de detalle de los findings). Es preocupante que empresas jóvenes, con mentalidad abierta y orientados hacia la eficiencia, no hayan nacido con la seguridad como parte del negocio, siendo que utilizan tecnología y datos sensibles como parte fundamental de la plataforma que comercializan. Otro aspecto importante es la ausencia de documentación de buena calidad, algo que resulta muy importante para poder cubrir un proceso de seguridad de terceras partes y demostrar cómo se trabaja. Algunos ejemplos son: metodología de desarrollo con muy bajo nivel de detalle o directamente sin documentación de soporte (como documentación también se entiende una wiki o cualquier otro medio de documentación online).

  • Seguridad de los datos: El uso de plataformas cloud permite muchas variantes al momento de seleccionar el lugar adecuado para almacenar los datos de los clientes, sin embargo, en ningún caso esta posibilidad ha sido ofrecida como una opción del servicio. La ubicación de los datos, se basa principalmente en la región la que la plataforma de cloud ofrece los costos más bajos y/o la mejor funcionalidad. Este punto es crítico al momento de evaluar la factibilidad de la solución, ya que considerando el marco regulatorio actual, la participación del rol del DPO para la toma de decisiones es un requerimiento mandatorio en cualquier proyecto corporativo en los tiempos que corren. La confidencialidad entre clientes es otro punto que no está maduro, ya que si bien existen muchas posibilidades para desplegar bases de datos en muchas geografías, la arquitectura de las plataformas y el modelo de datos, no fue desarrollado considerando independencia total entre clientes, por lo tanto, comparten recursos o en el peor de los casos, residen en la misma base.

    <aside> 💡

    NOTA: La integración de las plataformas de telemedicina con otras plataformas, como farmacias digitales o centros de estudios medicos, es una tendencia en alza. Los laboratorios están ofreciendo a través de su propia “estrategia digital”, la integración con estas plataformas incluyendo bonificaciones que incrementan la rentabilidad del negocio de la salud digital.

    </aside>

  • Respuesta a incidentes y notificación de brechas Considerando que las plataformas se venden como un servicio y su arquitectura comprende distintos proveedores y/o terceras partes, es muy importante saber cómo se va a responder al momento de que exista un problema, ya sea un incidente interno, externo, o cualquier otra situación que pudiera afectar la prestación del servicio y la seguridad de los datos. Sobre este aspecto, las plataformas evaluadas no presentan un esquema formal de respuesta a incidentes y notificación de brechas, si bien existen canales formales para registrar requerimientos (sistema de tickets), ante un compromiso de la plataforma o de los datos, no se han definido protocolos de notificación y respuesta ágil. Aquellos que residen en la UE están más familiarizados con el tema, pero no por ello presentan un proceso establecido y maduro.

Conclusiones: Ha sido muy interesante la posibilidad de evaluar plataformas de telemedicina, una tendencia en alza y que entre otros beneficios, busca acercar el servicio de salud a cualquier parte, solo accediendo a una web o utilizando una aplicación en un smartphone. Sin dudas es un mercado que seguirá creciendo, incorporando interacción con otras plataformas y sumando formas de venta diversa, crecimiento de coberturas, médico por uso, etc. Sin embargo, no se debe dejar de lado que estas plataformas realizan un tratamiento de datos sensibles (datos de salud) y que los mismos tienen la mayor presión regulatoria y necesidad de confidencialidad e integridad. Al menos en lo que a este artículo se refiere, las plataformas evaluadas están en un nivel inicial de madurez en temas de seguridad, si bien son startups (algunas ya fueron adquiridas por grandes jugadores del mercado), ya tienen un despliegue sobre distintos países y con miles de usuarios activos, por lo tanto, que sean startups no justifica que no hayan considerado la seguridad en el ADN de la empresa. Pero suele ser la respuesta que ellos brindan, al momento de consultarlos acerca de mejoras en seguridad o la ausencia de tal o cual tema.

Recomendaciones (y algunos tips): A continuación comparto algunos puntos que podrían ser de utilidad tanto para quien esté pensando en montar una empresa en este mercado o bien deba analizar una plataforma:

• El organigrama es una buena radiografía, es el esqueleto de los roles y responsabilidades dentro de la organización. Indaguen sobre el significado de las siglas.
• El job description 📄 de la persona encargada de la seguridad (si existe) es un buen punto para identificar madurez. Lean qué responsabilidades tiene, a quién reporta, quién es.
• La documentación 📑 es un buen termómetro de madurez y recursos, soliciten la documentación y leanla. Analicen si con coherentes entre los documentos, cómo están confeccionados, cuándo fueron revisados por última vez. Utilicen puntos de la documentación en las charlas (verán si realmente saben lo que tienen escrito). Consulten sobre procedimientos, guías, ante documentación de muy alto nivel (hecha solo para cumplir) deberían existir documentos con detalle para llevar a cabo lo definido en el nivel superior.
• Reportes de test de intrusion 🚦 , escaneos de vulnerabilidades, soliciten copia o al menos que los muestren en una sesión remota. Analicen el alcance (muchas veces es sobre una URL de pre-prod incomprobable), consulten sobre los findings y qué plazos manejan para remediar (tomar de referencia el CVSS es una forma de clarificar la criticidad sin entrar a discutir metodologías). Si estás en 2021 y el ultimo reporte es de mayo 2018, claramente no tiene implementado un proceso contínuo, algo inaceptable para los tiempos que corren. Indaguen sobre la metodología para realizer los test de seguridad, soliciten certificados de entrenamiento actuales.
• Si están certificados, soliciten copia de los certificados, revisen alcance, indaguen sobre cómo han sido certificados, si tienen certificación PCI-DSS, verifiquen el QSA, consulten a la empresa acerca del método que han aplicado (sobre todo para nivel 2 a 4). Si están certificados en ISO 27001, soliciten la declaración de aplicabilidad, indaguen sobre los “N/A” y si existen controles compensatorios. Duden siempre.