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.

 

 

Autenticación doble en Microsoft 365 y Outlook.com

Autenticación doble en Microsoft 365 y Outlook.com

La autenticación de doble factor añade una seguridad adicional a nuestra cuentas siempre conectadas. No es infalible pero si necesaria para datos/operaciones críticas, el juego del gato y el ratón en seguridad es continuo, como Hesperbot.

Actualmente podemos:

La opción más ágil es a través de la aplicación Microsoft Authenticator, despues del baile de nombres que ha sufrido la app, esta disponible para Android, Windows y iPhone nos mostrará un código o un mensaje de aceptación según prefiramos.

En el caso de las cuentas de Microsoft, es necesario diferenciar las de Office 365 empresarial y las de Outlook/Live el proceso de configuración y creación de contraseñas para aplicaciones no compatibles es diferente a día de hoy:

Office 365 -> Configuración -> Seguridad y Privacidad -> «Actualice los número de teléfono que usa para la seguridad de la cuenta»

No es una opción muy destacada en la configuración, debería tener su propia sección o aparecer más claramente pero bueno…

En la parte superior aparecerá la opción «Contraseñas de aplicación» donde podemos dar un nombre para identificar donde hemos usado la contraseña. Una vez creada no es posible volver a verla, solo podremos eliminarla y volver a crear otra:

NOTA: En el caso de realizar la configuración de la app por primera vez, deberemos seguir el asistente inicial desde el botón «Configurar»

Con Office 365 nos permite dar nombre a las contraseñas:

NOTA: Si el dominio esta gestionado por un administrador, debes comprobar que la configuración global permita crear contraseñas de aplicación: Administración Microsoft 365 > Configuración > Configuración de la organización > Configurar multi-factor Authentication además de habilitar al usuario (si no todavía no estaba)

Captura de pantalla de la versión web de 2022

URL para Office 365: https://account.activedirectory.windowsazure.com/AppPasswords.aspx

URL para Outlook/live: https://account.live.com/proofs/AppPassword

Configuración MFA para usuarios: https://aka.ms/MFASetup