EDENOR

EDENOR

BANCO HIPOTECARIO

https://mail.google.com/mail/u/0/?ui=2&ik=3ab76eea9c&view=att&th=1648a6d4d6c2fa40&attid=0.1&disp=safe&zw

Se aprueba una guía para fortalecer la seguridad en el desarrollo de aplicaciones en el Estado

 El 11 de noviembre de 2021 se publicó en el Boletín Oficial de la Nación la Disposición 8/2021 (en adelante, la “DI 8/21”) de la Dirección Nacional de Ciberseguridad (en adelante, la “DNC”)[1], que aprueba la Guía Introductoria a la Seguridad para el Desarrollo de Aplicaciones Web[2]-[3].

 

La versión final de la guía fue elaborada por el Comité Asesor para el Desarrollo e Implementación de Aplicaciones Seguras (en adelante, el “Comité Asesor”)[4] con el objetivo de contribuir al desarrollo seguro de aplicaciones en organismos del Sector Público Nacional (en adelante, “SPN”)[5].

 

A continuación, describiremos sucintamente los tópicos más relevantes que aborda la DI 8/21:

 

  • Principales aspectos de la DI 8/21

La DI 8/21 es una norma compleja y con diversas definiciones técnicas que requieren de un conocimiento avanzado para su cabal comprensión[6]. Entre sus principales aspectos se destacan:

 

Modelo Simplificado de Ciclo de Desarrollo: la DI 8/21 propone un modelo simplificado consistente en 7 etapas: inicio, análisis de requerimientos, diseño del sistema, implementación, prueba, despliegue y mantenimiento. El modelo sugerido está basado en acciones tendientes a consolidar la seguridad en todo momento.

 

Comparativa: Actividades en Modelos de SDLC[7] Seguro: compara las actividades de seguridad a llevar a cabo en distintos modelos de desarrollo seguro (OWASP, ISC CSSLP, Microsoft SDL, NIST SP800-64) y en el modelo simplificado sugerido por la DI 8/21.

 

Consideraciones al Iniciar un Proyecto: se manifiestan premisas bajo las cuales debe operarse para incorporar un correcto enfoque de seguridad desde el inicio del proyecto, por ejemplo: “van a atacar la aplicación”, “algunos ataques van a funcionar por errores de diseño”, “la información de los usuarios una vez filtrada no volverá a ser privada”. Asimismo, se propone que las decisiones importantes cuenten con la intervención de miembros experimentados del equipo y que haya participación de un equipo de seguridad que ofrezca una visión especializada sobre los riesgos del desarrollo y prevención de fallas.

 

Durante el Análisis de Requerimientos: se listan actividades de seguridad que pueden integrar la etapa de análisis de requerimientos, a saber: clasificación de activos, requerimientos de seguridad y de privacidad, análisis de riesgos, entre otras.

 

Principios para un Diseño Seguro: se desarrollan principios para prevenir fallos por decisiones de diseño incorrectas: (a) minimizar la superficie de ataque, (b) diseñar para ser mantenido -arquitectura simple/ mantenimiento sencillo-; (c) el eslabón más débil; (d) seguridad por defecto; (e) mantener la usabilidad; (f) autorización para todo por defecto; (g) principio de mínimo privilegio; (h) separación de responsabilidades y roles; (i) defensa en profundidad; (j) los controles en el cliente no son suficientes; (k) ayudar a los administradores; (l) diseño sin secretos; y, (m) modelado de amenazas.

 

Seguridad en Procesos de Implementación: se establecen consideraciones que incrementan la seguridad en el proceso de implementación, a saber: seguridad de herramientas, los sistemas de control de versiones, la mantenibilidad y seguridad, el seguimiento de errores y fallos, la prudencia al confiar en terceros y la arquitectura de red.

 

Programación Segura: este apartado está basado en el documento “OWASP: Secure Coding Cheat Sheet”, publicado por Owasp Foundation[8]. Se establecen criterios de seguridad para incrementar la seguridad del código producido (validar todas las entradas, codificar apropiadamente todas las salidas, centralizar las rutinas de control, autenticación, control de accesos, entre otros).

 

Ataques Comunes: OWASP Top 10: se describen los ataques más prevalentes (dónde y cómo ocurren), por ejemplo, filtración de datos sensibles, ataque de inyección, XSS, entre otros. Además, se explica cómo pueden mitigarse y las amenazas que estos ataques acarrean.

 

Pruebas de Seguridad: en este apartado se establecen criterios para verificar si el diseño y la implementación de la aplicación cumplen con requerimientos de seguridad (por ejemplo, realizar revisiones de código entre pares, utilizar herramientas de escaneo estático, realizar auditorías manuales de código, entre otros).

 

Puesta en producción: se desarrollan buenas prácticas para el despliegue de la aplicación, ellas son: (a) segregación de ambientes y (b) hardenizado de equipos.

 

Mantenimiento: para mantener los niveles de seguridad durante el funcionamiento productivo de la aplicación se recomienda realizar: (a) protocolos de backups; (b) monitoreos periódicos de seguridad y alertas; (c) reportes de incidentes y vulnerabilidades; (d) ventanas de vulnerabilidades; (e) actualizaciones de seguridad; y, (f) descarte de la aplicación.

 

Introducción a OWASP Top Ten y a BSIMM[9]se agregan dos anexos con un mayor detalle de OWASP Top 10 y BSIMM para quienes quieran profundizar sus conocimientos en el tema.

 

Cabe destacar que la DI 8/21 recomienda a las entidades y jurisdicciones del SPN y a los proveedores que contraten con estas, implementar sus disposiciones tanto para desarrollos internos como para aquellos que se subcontraten.[10].

 

  • Breves comentarios sobre el fortalecimiento de la seguridad de la información en el Estado

Entendemos que resulta prudente la adopción de normas que incorporen principios y buenas prácticas de seguridad informática en el Estado. En efecto, el uso de tecnologías se ha tornado indispensable en el ámbito del SPN, tanto en lo referido a la gestión interna de los organismos como en lo relacionado a los servicios que se prestan a la sociedad.

 

En este contexto, para reducir las vulnerabilidades que aumentan el riesgo de ataques a las infraestructuras -digitales y críticas- del Estado y pueden comprometer los datos personales[11] de quienes utilizan estos sistemas, es necesario (i) mejorar la capacidad de prevención, detección, respuesta y recupero ante incidentes de seguridad informática, y (ii) incorporar parámetros de seguridad desde el inicio de todos los desarrollos de software.

 

La DI 8/2021 se enmarca en una serie de normas que tienen la finalidad de robustecer políticas de seguridad informática. Entre ellas, cabe mencionar a la Decisión Administrativa 641/2021 (en adelante, “DA 641/21”) de la Jefatura de Gabinete de Ministros[12], mediante la cual se aprobaron lineamientos para el fortalecimiento de la seguridad de la información que reciben, producen y administran las entidades y jurisdicciones del SPN. La DA 641/21 contempla entre sus directrices una sección especial referida a la adquisición, desarrollo y mantenimiento de sistemas de información, en la cual se señala que “la seguridad de la información debe contemplarse como una parte integral de los sistemas de información en todas las fases de su ciclo de vida, incluyendo aquellos que brinden servicios o permitan la realización de trámites a través de Internet”.

 

Estas normas marcan un incipiente interés del Estado en adoptar mejores prácticas y generar una cultura en seguridad de la información. Este objetivo requiere no sólo de una actualización constante en la regulación (dado que las mejores prácticas se van actualizando al ritmo de la tecnología) sino también de una correcta capacitación y concientización en todos los niveles involucrados.

 

En materia de seguridad informática, al igual que en otras áreas, el eslabón más débil de la cadena es el que determina el nivel de fortaleza del conjunto. En el ámbito público, suele ser difícil que la capacitación e implementación alcance a todos los niveles (o eslabones), y en ese aspecto deberá trabajarse sobre la base de las recomendaciones de la DI 8/21 y de las normas que la sucedan. Sólo así se generará la cultura en materia de seguridad informática a la que debe apuntar el Estado.