Los programadores conquistan la infraestructura de seguridad como serie de códigos: criptografía insegura

Las organizaciones inteligentes están adoptando el concepto de infraestructura como código, y son los desarrolladores como usted los que pueden hacer importantes contribuciones a la creación de código seguro, incluso fuera de la creación de una aplicación. Al principio puede parecer un largo camino por recorrer, pero vale la pena hacerlo para destacar entre tus compañeros.

Antes de comenzar con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarlos a jugar un desafío gamificado sobre la vulnerabilidad del almacenamiento de datos confidenciales; juegue ahora y elija entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:

¿Cómo fue eso? Si tus conocimientos necesitan algo de trabajo, sigue leyendo:

Hoy en día, tener datos críticos como contraseñas, información personal y registros financieros codificados mientras están en reposo es la piedra angular de cualquier defensa de ciberseguridad. En muchos sentidos, actúa como última línea de defensa y también como uno de los mejores tipos de protección. Esto se debe a que, aunque un atacante sea capaz de romper otras defensas y obtener archivos críticos, siempre y cuando estén codificados y almacenados correctamente, no le servirá de mucho.

Esto también actúa como una sólida protección secundaria contra los intrusos malintencionados, ya que los archivos cifrados pueden tener claves o contraseñas independientes del resto de la red. En ese caso, alguien, como un administrador del sistema o un pirata informático, que haya puesto en peligro las credenciales de un administrador podría navegar hasta un directorio protegido, pero aun así no poder desbloquear los archivos cifrados que encuentre allí si la clave de cifrado se encuentra en otro lugar.

Por supuesto, todos los métodos de protección de cifrado se basan en tener estándares de cifrado sólidos que ni siquiera los ordenadores más potentes puedan romper.

¿Por qué es peligrosa la criptografía insegura?

En lo que respecta a la tecnología informática, la capacidad de crear algoritmos de cifrado sólidos y la capacidad de descifrarlos han estado en competencia durante mucho tiempo. En 1977, el gobierno federal de los Estados Unidos desarrolló el Estándar de Cifrado de Datos (DES), un algoritmo de 56 bits que en aquella época se consideraba seguro dada la relativa potencia de los ordenadores.

Sin embargo, las computadoras evolucionaron y las personas encontraron formas de conectarlas en red de forma colaborativa para aumentar aún más su potencia. En 1999, la Electronic Frontier Foundation y Distributed.net colaboraron para descifrar públicamente el cifrado de un documento protegido por el DES en tan solo 22 horas. De repente, cualquier documento protegido mediante el cifrado DES dejó de ser seguro.

Aunque no lo crea, algunas organizaciones siguen protegiendo sus archivos críticos con el algoritmo DES o con una protección de cifrado igualmente débil. Y si bien en 1999 se necesitó una red distribuida para romper el cifrado de 56 bits, hoy en día casi cualquier ordenador independiente lo suficientemente potente puede hacerlo con un mínimo de tiempo. Los piratas informáticos también han creado máquinas de descifrado especializadas construidas a partir de bancos de unidades de procesamiento gráfico (GPU). Esas GPU son excepcionalmente buenas para esa tarea y son relativamente baratas de obtener y de conectar en red localmente.

Si hoy decides proteger tus archivos críticos con un algoritmo criptográfico débil o inseguro, no pasará mucho tiempo antes de que la mayoría de los piratas informáticos puedan desglosar esos archivos y hacerlos legibles. Si sufre una violación de datos, debe asumir que los archivos eventualmente se verán comprometidos si no están suficientemente protegidos.

Por ejemplo, el siguiente fragmento de código de Kubernetes utiliza un algoritmo de cifrado débil para proteger la información en el nivel del controlador de ingreso de NGINX:

Versión de API: v1
tipo: ConfigMap
metadatos:
nombre: nginx-load-balancer-conf
espacio de nombres: kube-system
datos:
cifrados SSL: DES-CBC3-SHA
protocolos SSL: «TLSv1.2»

En ese ejemplo, el conjunto de cifrado DES se ha utilizado para proteger la información. Sin embargo, un atacante podría descifrarla fácilmente y acceder a información confidencial.

Se recomienda utilizar algoritmos de cifrado seguros. En el siguiente ejemplo de Kubernetes, se han utilizado conjuntos de cifrado seguros para proteger la información a nivel del controlador de ingreso de NGINX:

Versión de API: v1
tipo: ConfigMap
metadatos:
nombre: nginx-load-balancer-conf
espacio de nombres: kube-system
datos:
cifrados SSL: |
ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA256
protocolos SSL: «TLSv1.2»

En ese ejemplo, se ha utilizado un conjunto sólido de sistemas de cifrado para evitar que los atacantes tengan acceso potencial a información confidencial.

Protección de la información crítica con un cifrado sólido

Hoy en día existe un cifrado seguro que es casi irrompible. En 2001, el Instituto Nacional de Estándares y Tecnología (NIST) creó una nueva tecnología de cifrado para reemplazar al DES. Denominado estándar de cifrado avanzado (AES), utiliza tres longitudes de clave diferentes: 128, 192 o 256 bits. El cifrado AES de 256 bits es el más seguro, aunque los tres se consideran casi completamente irrompibles dada la tecnología actual. Las pruebas realizadas con superordenadores han demostrado que se necesitarían miles de años de trabajo constante para descifrar la mayoría de los documentos protegidos por AES.

Para proteger adecuadamente los archivos críticos, los desarrolladores deben identificarlos primero. No es necesario cifrar todo lo que hay en una red, ya que esto podría ralentizar las operaciones debido al constante proceso de cifrado y descifrado. Sin embargo, los archivos críticos, como los registros de personal, los datos de los clientes y la información financiera, necesitan una protección adecuada. Básicamente, se trata de lograr un equilibrio entre la seguridad y tener un sistema que funcione.

Y esos datos deben cifrarse según uno de los estándares AES, incluso con un cifrado de 256 bits para obtener información verdaderamente crítica que nunca debería caer en malas manos.

Otra cosa a tener en cuenta es el hecho de que agregar cifrado es como agregar más contraseñas a un sitio. Esto significa que los usuarios autorizados deberán realizar un seguimiento de las claves de cifrado. Para evitar que esto se convierta en un obstáculo en el flujo de trabajo, considere la posibilidad de implementar una plataforma de administración de claves para realizar un seguimiento de esas claves y mantenerlas seguras. Y aunque no acabes utilizando una administración de claves centralizada, asegúrate de que todas las claves y contraseñas estén protegidas para garantizar que los usuarios no autorizados se mantengan alejados de tus bóvedas de datos más seguras.

Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demostración de un desafío de iAC dentro de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.