Los codificadores conquistan la infraestructura de seguridad como serie de código: Criptografía insegura

Las organizaciones astutas están adoptando el concepto de infraestructura como código, y son los desarrolladores como usted los que pueden hacer contribuciones significativas en la elaboración de código seguro, incluso fuera de la construcción de una aplicación. Puede parecer un camino largo al principio, pero el viaje merece la pena para destacar entre tus compañeros.

Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:

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

Hoy en día, tener los datos críticos como las contraseñas, la información personal y los registros financieros protegidos con hash mientras están en reposo es una 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, incluso si un atacante es capaz de romper otras defensas y obtener archivos críticos, mientras estén correctamente cifrados y almacenados, eso no les 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 separadas del resto de la red. En ese caso, alguien como un administrador del sistema o un hacker que haya comprometido las credenciales de un administrador podría ser capaz de navegar en un directorio protegido, pero aún así no podría desbloquear los archivos cifrados que encuentre allí si la clave de cifrado se mantiene en otro lugar.

Por supuesto, todos los métodos de protección por encriptación se basan en tener estándares de encriptación fuertes que no puedan ser rotos ni siquiera por los ordenadores más potentes.

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

En lo que respecta a la tecnología informática, la capacidad de crear algoritmos de encriptación fuertes y la capacidad de romperlos han estado en competencia durante mucho tiempo. Ya en 1977, el gobierno federal de Estados Unidos desarrolló el Estándar de Cifrado de Datos (DES), un algoritmo de 56 bits que se consideraba seguro en aquel momento dada la potencia relativa de los ordenadores.

Pero los ordenadores evolucionaron y la gente encontró la forma de conectarlos en red para aumentar su potencia aún más. En 1999, la Electronic Frontier Foundation y Distributed.net colaboraron para romper públicamente el cifrado de un documento protegido por DES en sólo 22 horas. De repente, cualquier documento protegido por el cifrado DES dejó de ser seguro.

Lo creas o no, algunas organizaciones todavía protegen sus archivos críticos con el algoritmo DES o con una protección de cifrado similarmente débil. Y mientras que en 1999 se necesitó una red distribuida para descifrar el cifrado de 56 bits, hoy en día casi cualquier ordenador independiente lo suficientemente potente puede hacerlo con un poco de tiempo. Los piratas informáticos también han creado máquinas dedicadas a descifrar, construidas a partir de bancos de unidades de procesamiento gráfico (GPU). Estas GPU son excepcionalmente buenas en esa tarea, son relativamente baratas de obtener y de conectar en red localmente.

Si eliges proteger tus archivos críticos con un algoritmo criptográfico inseguro o débil hoy en día, entonces no pasará mucho tiempo antes de que la mayoría de los hackers puedan romper esos archivos y hacerlos legibles. Si usted sufre una violación de datos, entonces tiene que asumir que los archivos se verán eventualmente comprometidos si no estaban 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 entrada de NGINX:

apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: DES-CBC3-SHA
ssl-protocols: "TLSv1.2"

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

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

apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: |
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
ssl-protocols: "TLSv1.2"

En ese ejemplo, se ha utilizado un sólido conjunto de claves para evitar que los atacantes puedan acceder a información sensible.

Proteger la información crítica con un fuerte cifrado

Hoy en día se dispone de un cifrado fuerte que es casi irrompible. En 2001, el Instituto Nacional de Estándares y Tecnología (NIST) creó una nueva tecnología de cifrado para sustituir al DES. Denominada Advanced Encryption Standard (AES), utiliza tres longitudes de clave diferentes, de 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 romper la mayoría de los documentos protegidos con AES.

Para proteger adecuadamente los archivos críticos, los desarrolladores deben identificarlos primero. No es necesario cifrar todo en una red, ya que eso podría ralentizar las operaciones con el constante proceso de cifrado y descifrado. Pero los archivos críticos, como los registros de personal, los datos de los clientes y la información financiera, necesitan una protección adecuada. Esencialmente, se trata de un acto de equilibrio entre la seguridad y un sistema viable.

Y esos datos deberían estar encriptados según uno de los estándares AES, llegando incluso a una encriptación de 256 bits para la información verdaderamente crítica que no debería caer nunca en manos equivocadas.

Otra cosa que hay que tener en cuenta es el hecho de que añadir encriptación es como añadir más contraseñas a un sitio. Eso significa que los usuarios autorizados tendrán que hacer un seguimiento de las claves de cifrado. Para evitar que esto se convierta en un cuello de botella en el flujo de trabajo, considere la posibilidad de implementar una plataforma de gestión de claves para realizar un seguimiento de esas claves y mantenerlas seguras. E incluso si no acabas utilizando la gestión centralizada de claves, asegúrate de que todas las claves y contraseñas están protegidas para garantizar que los usuarios no autorizados se mantienen fuera de tus bóvedas de datos más seguras.

Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos de seguridad. También puede probar una demostración de un reto de IaC dentro de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.