Emular llave de seguridad

Si bien estamos más acostumbrados a los números de serie asociados a un programa determinado, todavía existen soluciones de hardware para la protección y validación de software, lo vimos con el sistema operativo THEOS que utiliza una combinación de ambos para su instalación.

Aunque la tendencia a SaaS (software como servicio) está cada vez más presente debemos tener en cuenta, dentro del ciclo de vida del software, las implicaciones que pueda tener pasado el tiempo… volvemos a sistemas legacy.

Nos encontramos con un software totalmente obsoleto, incluso el fabricante del mismo ha desaparecido pero sigue siendo necesario para el control de maquinaria, no ha sufrido mucho cambio en… 20 años… Durante este tiempo se han ido sucediendo equipos compatibles, pero empieza a ser difícil convivir entre sistemas con tantas diferencias.

En este caso Windows NT asociado a un dongle HASP4 M1 1.1 en puerto paralelo (LPT), por limitaciones de software el máximo paso que podemos dar es a Windows XP (aunque el soporte finalizo en 2014). Después de prueba y error con varios software emuladores, lectores… encontramos las utilidades de Brain Studio.

Leer más
Seguridad y privacidad: TLS 1.3

Seguridad y privacidad: TLS 1.3

La guerra entre los navegadores más populares a día de hoy (Chrome, Firefox, Edge – El artista anteriormente conocido como Internet Explorer, Opera, Safari, Konqueror… tiene sus precuelas años atrás. Una de ellas tiene nombre propio: Netscape Navigator.

Si lo conoces, seguramente te tocó navegar por las primeras webs con módem analógico y su sonido característico.

Desde 1994, este navegador ya desaparecido, fue mejorando las especificaciones necesarias para implementar «el candadito» del navegador. No fue hasta su versión 3.0 y un par de vulnerabilidades después que haría pública y operativa pero sentó las bases del intercambio seguro de datos entre dos partes.

Leer más

Teletrabajo con entornos Windows y coronavirus

Si bien algunas empresas están ya habituadas a permitir a sus empleados realizar trabajo en remoto, con la pandemia del coronavirus muchas otras se han visto forzadas a utilizar recursos limitados para un gran número de trabajadores.

Lo primero de todo, debemos tener en cuenta los servicios nativos cloud, los cuales permiten realizar tareas desde cualquier sitio de forma habitual. Por otro lado, el acceso a recursos locales dentro de la empresa debe asegurarse de diferentes formas:

  • Sistemas de alimentación ininterrumpida deben proveer corriente a los servidores o equipos con disponibilidad, algo básico pero necesario.
  • Seguridad de red activa, abrir un puerto o varios para permitir un servicio (por ejemplo de conexión remota) debe conllevar su monitorización activa en busca de patrones o usos inadeacuados. Firewall dedicados o Azure Bastion por ejemplo.
  • Autenticación de doble factor, donde sea posible y factible, como punto de verificación de identidad de humanos frente a máquinas.
  • Sistemas operativos y antivirus actualizados, no debería llegar una pandemia para tener este punto mínimo cubierto.

Dentro de los entornos corporativos con recursos limitados, se han habilitado ordenadores para su acceso por escritorio remoto, si bien las soluciones RDS/VDI/WVD son muy capaces, para PYMES puede no ser una opción asequible en todos los casos. Por ello debemos tener en cuenta cuando habilitamos el acceso remoto:

  • Separar y securizar redes según los perfiles y requisitos de acceso
  • Establecer directivas de red suficientes
  • Monitorizar y controlar los usuarios permitidos

Si llegados a este punto permitimos el acceso remoto al puesto de trabajo habitual de un trabajador, deberemos tener en cuenta adicionalmente:

Debemos estar seguros lo que supone introducir un ordenador dentro de la red corporativa, así como tener en mente primero a las personas y luego a las máquinas.

 

 

Exportación de certificado X.509 codificado en PEM

La digitalización en la administración pública no lleva precisamente un ritmo rápido… y tampoco lo ponen fácil a usuarios finales…

Veremos como para dar de alta un proveedor en FACe, o gestionar su renovación, nos solicitan certificado en formato PEM. Por simplificar, tal como en un fichero de texto Word o una hoja de Excel tenemos diferentes formatos y versiones con los que podemos trabajar, con el certificado nos pasa lo mismo.

Leer más

Seudonimización y anonimización de datos personales en la RGPD

La utilización de técnicas de encriptación, índices alternativos y otros elementos de seguridad no garantizan la anonimización de datos mientras sea posible acceder a la misma información atravesando un camino más complejo, pese a ello permitiendo identificar indirectamente a la misma persona física o conjunto de datos.

Ninguna técnica de anonimización carece de deficiencias, aunque algunas de ellas permiten disociar la información suficiente como para no poner en peligro la privacidad suponen la alteración inherente de las fuentes.

En ciertos escenarios, con grandes valores de una muestra sería posible de manera eficiente suprimir los datos no relevantes identificativos de un individuo. Por ejemplo, la estadística de afección de una enfermedad cardiológica en una región no necesita mostrar el nombre del paciente.

Además de la eliminación de datos no relevantes, también es posible realizar su generalización. Por ejemplo, sustituimos la edad por un rango o la localidad por un código postal más amplio.

Estas técnicas de anonimización denominadas generalmente k-anonymity han ido evolucionando, introduciendo mejoras para evitar revertir el anonimato centrados en dos posibles factores:

  • La homogeneidad de la muestra, es decir, un valor sensible dentro de un conjunto determinado de registros en los que los valores son idénticos. Por ejemplo, el 99% de la muestra de pacientes obtenida en la micronesia no contiene haplogrupo de tipo M, con lo que sería más sencillo identificar ese 1% restante de origen indio.
  • Conocimientos genéricos, por ejemplo, conociendo un rango determinado de edad en la que los accidentes de tráfico son más frecuentes es posible extraer un grupo de datos reducido con ciertas características.

Al igual que sucede con los cifrados, el esfuerzo de tiempo/dinero debe ser lo suficientemente alto para que su realización no salga a cuenta por parte del atacante. El análisis de riesgos y la adopción de buenas prácticas, protocolos, formación del personal… definen la intención y diligencia del responsable del fichero.

Pese a todo ello, la identificación indirecta sigue siendo un riesgo difícil de abordar o proteger. Si varias empresas disponen de datos anonimizados independientemente, sería posible cruzarlos para llegar a identificar a una persona concreta. Por ejemplo, datos de movimientos de un banco, resultados médicos de una revisión, pólizas de seguros contratadas, datos demográficos de una localidad…

Tal vez ahora se vea más claro el valor y poder de la información que manejan algunas empresas nacidas de internet como Google, Linkedin, PayPal o Facebook por poner nombres a las bases de datos.

Deben analizarse los peligros de reidentificación según los objetivos y finalidad de la información anonimizada, teniendo claro el umbral de riesgo aceptable.

Una vez repasadas alguna de los conceptos de anonimización, podemos entrar en lo que los perfiles jurídicos denominan seudonimización: sustitución de un atributo (normalmente único) por otro en un registro; dentro de un perfil técnico que haya ideado una base de datos relacional lo denominaría: clave primaria, con su ejemplo más sencillo de utilizar un DNI como tal, un valor autonumérico o un GUID.

Si bien estas técnicas vienen aplicándose en cualquier base de datos relacional, las recomendaciones sugieren (si no se ha hecho todavía) la adición de una capa adicional de seguridad a los datos, a las claves u a ambos, de cifrado con clave secreta. Si además añadimos un valor aleatorio (salt) y funciones hash de cálculo para su comprobación, el coste efectivo frente a un ataque se incrementa.

Teniendo en cuenta el almacenamiento que suele realizarse de las claves y contraseñas, sería aconsejable utilizar técnicas adicionales mixtas. Por ejemplo, si en lugar de basarnos solo en las contraseñas utilizamos datos biométricos en un canal seguro, es decir, una lectura de iris, un patrón de voz o una huella dactilar es otro dato binario más al que podemos aplicar un hash determinado, pero si el canal de obtención es único y seguro podemos combinarlo con una autenticación doble, poniendo las cosas más difíciles en caso de intentos de acceso no autorizados a la información.