Corrección de vulnerabilidades en LATAM
- Inicio
- Seguridad de Aplicaciones
- Corrección de Vulnerabilidades
¿Cómo corregir vulnerabilidades?
Las vulnerabilidades reportadas por procesos automáticos de escaneo o por análisis manual pueden requerir diferentes prácticas para solucionarlas, dependiendo del tipo de riesgo podría ser responsabilidad del equipo de desarrollo, de infraestructura o inclusive de un tercero.
Tipos de vulnerabilidades
A continuación encontrarás la forma de cómo corregir los diferentes tipos de vulnerabilidades:
Infraestructura mal configurada
Cuando la infraestructura se encuentra mal configurada, podría existir la posibilidad de que alguien se aproveche de esto para ingresar por servicios inseguros expuestos en internet, consolas de administración o la falta de aplicar controles de seguridad suficientes, realizar éstas mejoras será responsabilidad de los equipos de DevOps o los encargados de administrar la infraestructura.
Plataformas desactualizadas
Las plataformas desactualizadas son un riesgo común, en muchos casos ya existe documentación de las vulnerabilidades conocidas para la mayoría de las plataformas más utilizadas, la corrección de estos problemas radica por lo general en realizar la actualización a la versión más reciente posible que el fabricante tenga disponible.
Dependencias vulnerables
Las herramientas de análisis de composición de software (SCA) reportan los riesgos asociados a las librerías de terceros que se utilizan en el software, esto es especialmente relevante dada la gran cantidad de ataques que han surgido que están relacionados con la cadena de suministros que para el contexto del software, son las relaciones o dependencias que tengamos con componentes o plataformas desarrolladas y mantenidas por terceros. Corregir estos hallazgos depende de la disponibilidad de nuevas versiones por parte de los fabricantes, esto podría ser un riesgo mayor en el caso de librerías de código abierto mantenidas por grupos de personas que no sean muy activos y se han visto muchos casos de librerías gratuitas que contienen software malicioso por lo que es de suma importancia tener un proceso para el análisis y aprobación de las dependencias antes de su uso.
Errores de diseño
Los errores de diseño pueden tener consecuencias importantes en la seguridad de cualquier plataforma, exponer funcionalidades que pueden ser abusadas por actores maliciosos o la falta de conceptos básicos de arquitectura segura del software podría causar que se tengan que hacer cambios drásticos en las aplicaciones que podrían tomar mucho tiempo y ser muy costosos. La capacitación en materia de desarrollo seguro es siempre la recomendación para poder tener bases sólidas y evitar que los problemas de diseño se den desde el inicio. Disponer de personal capacitado en ciberseguridad o apoyarse en asesores es crítico para reducir los costos asociados con el rediseño de las plataformas.
Riesgos en el código
Es común pensar que los "Frameworks" ya se encargan de "todo" en la tendencia de facilitar la generación de código, sin embargo los "Frameworks" son "cajas de herramientas" y la forma en como se usan es decisión de los desarrolladores, sin capacitación en desarrollo seguro se incrementan las probabilidades de cometer los errores más comunes que resultan en riesgos de seguridad. La gran mayoría de vulnerabilidades en el código están relacionadas con la forma en como se reciben datos no confiables y en cómo se interpretan o procesan a lo interno. También son comunes los errores a la hora de restringir el acceso a datos sensibles, la forma en como se podría burlar la lógica del negocio, el uso de algoritmos criptográficos inseguros y muchos más. Tener claros los principios básicos de seguridad es clave para prevenir estos riesgos.
Validación de las correcciones (retest)
Usualmente luego de que se implementan las correcciones, se solicita a los equipos de seguridad que validen y comprueben que los cambios funcionan de la forma esperada para resolver los hallazgos reportados, este proceso se conoce como "retest" y es importante que su equipo interno pueda realizarlo antes de solicitar la validación final a seguridad para evitar retrasos en caso de que la implementación sea rechazada.
