Guillem Alsina Gonzàlez
La iniciativa Secure by Design impulsada por la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA, por sus siglas en inglés) promueve que los fabricantes de software incorporen la protección en sus productos desde las primeras etapas de desarrollo y, para reforzar este objetivo, la misma CISA emitió hace unos meses, una guía titulada Product Security Bad Practices (Malas prácticas en la seguridad de los productos), la cual -y cómo su nombre explicita- propone un conjunto de medidas en el ámbito de la programación para mitigar los fallos de seguridad más corrientes que se cometen en la creación de aplicaciones.
Estas medidas fomentan la reducción de riesgos para los clientes a través de la priorización de la seguridad en cada fase de la vida útil de un producto. Aunque la orientación no es vinculante, se pone especial énfasis en aquellos casos en que el software se utiliza en infraestructuras esenciales o en funciones consideradas trascendentales para el país, aunque también puede aplicarse universalmente y no sólo en Estados Unidos.
Tres categorías de malas prácticas
Las malas prácticas descritas en el documento se dividen en tres grupos diferenciados: el primero se refiere a las características del producto, es decir, las propiedades de un software que pueden determinar la solidez de su protección. La segunda categoría se centra en las funcionalidades de seguridad que debe contemplar cualquier solución tecnológica. Finalmente, la tercera categoría consiste en los procesos y políticas organizativas que refuerzan la transparencia y la responsabilidad del proveedor.
Estas directrices pretenden cubrir los aspectos más peligrosos detectados en el panorama de amenazas actual. Aunque la lista no es exhaustiva y no incluye todas las prácticas cuestionables, las organizaciones autoras advierten que no contemplar otros riesgos no supone en modo alguno que resulten aceptables. Su recomendación se limita a un subconjunto de puntos que consideran críticos, con la intención de ayudar a los fabricantes a focalizar sus esfuerzos en las áreas más urgentes.
La puesta en marcha en los productores de software de estos criterios de seguridad voluntarios, puede contribuir a que los clientes y usuarios de sus productos perciban un mayor compromiso por parte de dicha compañía productora, ya que denota la voluntad de mantener unos estándares de protección altos, y de asumir la responsabilidad sobre los resultados en materia de ciberseguridad.
Actualizaciones en la nueva versión 2.0
Este pasado mes de enero, la CISA publicó la versión 2.0 de estas directrices, incorporando sugerencias recibidas a través de 78 comentarios públicos. Dicho proceso dio lugar a incorporar tres nuevas malas prácticas relacionadas con el uso de funciones de criptografía insegura, la presencia de credenciales embebidas y la definición de períodos de soporte del producto.
Además, también se ha añadido contenido específico sobre seguridad de la gestión de la memoria (memory safety), así como indicaciones para reducir vulnerabilidades relacionadas con SQL injection y command injection.
En la nueva versión también se han aclarado las pautas de actuación en torno a patching de Known Exploited Vulnerabilities (KEVs) y se incluyó información relacionada con la autenticación multifactorial (MFA), poniendo énfasis en entornos industriales.
Igualmente, se ha insistido en que los fabricantes deben facilitar phishing-resistant MFA, junto con otras modificaciones de redacción para mejorar la comprensión del texto.
Estas modificaciones, según destacan las organizaciones autoras, buscan que los proveedores de software asuman la responsabilidad de proteger los entornos de sus clientes. Aunque la guía sigue siendo de cumplimiento voluntario, se recalca su importancia en ámbitos delicados, como sistemas de control y servicios de misión crítica.
Con estos nuevos apartados, se pretende que los fabricantes refuercen la detección de potenciales errores y adopten un enfoque preventivo para evitar las malas prácticas descritas.
