Se aprueba una guía para fortalecer la seguridad en el desarrollo de aplicaciones en el Estado
Por J. Darío Veltani & Macarena Belén Mansilla
AVOA Abogados

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.

 

 

AVOA Abogados
Ver Perfil
Citas

[1] Disponible en https://www.boletinoficial.gob.ar/detalleAviso/primera/252690/20211111. Fecha de última consulta: 15/11/2021.

[2] Conf. art. 1 de la DI 8/21.

[3] La Guía Introductoria a la Seguridad para el Desarrollo de Aplicaciones Web también se encuentra disponible en GitHub, https://github.com/cpeic/Desarrollo-Seguro. Fecha de última consulta: 16/11/2021.

[4] El Comité Asesor fue creado en abril de 2021 por la Disposición 6/2021 (en adelante, “DI 6/21”) de la DNC con el fin de brindar asesoramiento a la Subsecretaría de Tecnologías de Información y las Comunicaciones y a la propia DNC, en la elaboración de guías y protocolos de principios y buenas prácticas relacionadas con la seguridad en el desarrollo, contratación e implementación de aplicaciones informáticas utilizadas por los organismos del Sector Público Nacional. En efecto, la DNC solicitó al Comité Asesor, la generación de guías y lineamientos básicos para asistir a los organismos públicos en los procesos de desarrollo propio o subcontratado de aplicaciones y sistemas web. La DI 6/21 se encuentra disponible en https://www.boletinoficial.gob.ar/detalleAviso/primera/242883/20210412. Fecha de última consulta: 15/11/2021.

[5] De acuerdo con la Ley 24.156 de Administración Financiera y de los Sistemas de Control del Sector Público Nacional, el SPN está integrado por: “art. 8: (…)  a) Administración Nacional, conformada por la Administración Central y los Organismos Descentralizados, comprendiendo en estos últimos a las Instituciones de Seguridad Social; b) Empresas y Sociedades del Estado que abarca a las Empresas del Estado, las Sociedades del Estado, las Sociedades Anónimas con Participación Estatal Mayoritaria, las Sociedades de Economía Mixta y todas aquellas otras organizaciones empresariales donde el Estado nacional tenga participación mayoritaria en el capital o en la formación de las decisiones societarias; c) Entes Públicos excluidos expresamente de la Administración Nacional, que abarca a cualquier organización estatal no empresarial, con autarquía financiera, personalidad jurídica y patrimonio propio, donde el Estado nacional tenga el control mayoritario del patrimonio o de la formación de las decisiones, incluyendo aquellas entidades públicas no estatales donde el Estado nacional tenga el control de las decisiones; d) Fondos Fiduciarios integrados total o mayoritariamente con bienes y/o fondos del Estado nacional. (...)”.

[6] Tal vez hubiera sido conveniente que la norma siga el criterio de las leyes 25.326 de Protección de Datos Personales y 25.506 de Firma Digital, debido a que estas definen términos esenciales respecto de la materia que le compete a cada una. En consecuencia, explicar qué se entiende por los principales términos relevantes daría más precisión en la materia dejando de lado las definiciones equivocas que dan lugar a ambigüedades y vaguedades.

[7] Acrónimo de Systems Development Life Cycle (ciclo de vida de desarrollo de un sistema).

[8] La Open Web Application Security Project trabaja para mejorar la seguridad del software a través de proyectos de código abierto. Más información en: https://owasp.org/. Fecha de última consulta: 18/11/2021

[9] Acrónimo de Building Security In Maturity Model (metodología para el desarrollo de software seguro).

[10] Conf. art. 2 de la DI 8/21.

[11] La Ley 25.326 de Protección de Datos Personales define -conf. art. 2- el término “dato personal” como “información de cualquier tipo referida a personas físicas -hoy humanas- o de existencia ideal determinas o determinables”.

[12] Disponible en https://www.boletinoficial.gob.ar/detalleAviso/primera/246104/20210628. Fecha de última consulta 15/11/2021.

Opinión

El nuevo art. 245 bis de la LCT y la reedición de viejos errores del pasado
Por Lucas J. Battiston
PASBBA
detrás del traje
Diego Palacio
De PALACIO & ASOCIADOS
Nos apoyan