La última encuesta de “pulso tecnológico” de EY informa que el 78% de los ejecutivos de tecnología están más preocupados por las amenazas de seguridad cibernética de hoy que las de hace un año. Los líderes de TI que dicen que están aumentando sus presupuestos de TI informan con mayor frecuencia que tienen un plan para priorizar la seguridad cibernética (74 %), según la encuesta en línea de 254 ejecutivos de TI.
El líder de seguridad cibernética de la región oeste de EY, Ayan Roy, dice que del 7% al 10% del presupuesto de seguridad cibernética se destina a mejorar la seguridad en el proceso de desarrollo de software, mientras que del 4% al 7% del presupuesto del equipo de desarrollo de software se gasta en mejorar la seguridad cibernética en el desarrollo. proceso.
Hay una buena razón por la que el gasto en seguridad cibernética está en aumento. El avance de la tecnología tiene un efecto positivo tanto en la productividad empresarial como en la capacidad de los piratas informáticos para mejorar la forma en que pueden atacar a organizaciones e individuos.
Tomemos, por ejemplo, la inteligencia artificial (IA) y el potencial de grandes modelos de lenguaje como ChatGPT. Al igual que muchos investigadores de seguridad, Max Heinemeyer, director de productos de Darktrace, está rastreando la aceleración de los ataques cibernéticos impulsados por IA. “Los atacantes pueden usar el aprendizaje automático para automatizar sus procesos y volverse más eficientes en la ampliación de sus ataques”, dice.
Pero la otra cara de la moneda de la IA que se utiliza para automatizar los ataques cibernéticos es el hecho de que las herramientas de prueba basadas en la IA pueden ayudar a los equipos de desarrollo de software a identificar problemas potenciales mucho más rápido que las pruebas manuales. Según la plataforma de pruebas colectivas Unguess, el 80 % de las pruebas consiste simplemente en reiterar las comprobaciones que ya tiene el software; la automatización de algunas de las tareas impulsadas por humanos puede ahorrar tiempo. Los errores se pueden identificar automáticamente y el sistema puede generar la lógica de prueba y realizar pruebas por sí mismo.
Gracias a los modelos predictivos, la IA también puede identificar varios parámetros de prueba y crear un plan de prueba. Es posible examinar una gran cantidad de datos, usar casos de prueba reutilizables y producir resultados de prueba completos mediante la automatización de pruebas con IA, según Edoardo Vannutelli, cofundador y líder de automatización de pruebas de Unguess.
“Los algoritmos de IA pueden analizar grandes volúmenes de datos, incluidas bases de código, entradas de usuarios e información histórica de pruebas, para generar conjuntos de datos inteligentes. Estos conjuntos de datos pueden cubrir una amplia gama de escenarios e identificar posibles vulnerabilidades, mejorando la cobertura y precisión de la prueba”, dice.
Cambiar la seguridad de nuevo a los codificadores
Los principios de seguridad por diseño ofrecen un punto de partida para la codificación segura. Roy de EY dice que la seguridad se está integrando en el desarrollo de software: “Desplazarse a la izquierda es una práctica líder, donde el objetivo es que los equipos de desarrollo de software incorporen la seguridad al principio del ciclo de vida, generalmente en la etapa de requisitos y diseño, y no como una ocurrencia tardía. ”
Por ejemplo, los desarrolladores de software deben verificar que cualquier entrada a una pieza de código solo pueda provenir de una fuente conocida y verificada. Cuando se desarrolla un código seguro, los datos de entrada que lee la aplicación están sujetos a una rigurosa verificación de límites y contenido, dice Petra Wenham, voluntaria en BCS, el Chartered Institute for IT. Si la entrada no es conforme, dice que los datos deben destruirse por completo.
Estas comprobaciones ayudan a minimizar los errores de desbordamiento del búfer. Esto ocurre cuando se inyecta código ejecutable en un campo de datos de entrada de una aplicación de software. Si la aplicación no valida los datos, puede fallar de tal manera que permita que el código inyectado realice acciones no autorizadas.
De manera similar, como señala Wenham, los resultados de un fragmento de código solo deben provenir del propio código. Los datos de salida solo deben enviarse a destinos verificados y no se les debe permitir usar memoria fuera de lo que se ha asignado.
Ella dice que el sistema operativo (SO) en el que se ejecuta el código es responsable de asignar, monitorear y controlar el uso de la memoria. Desde una perspectiva de seguridad, su función es evitar que una pieza de código viole la memoria asignada a otras piezas de código.
“El sistema operativo solo debe permitir que se ejecute el código verificado (certificado o marcado); el código no verificado debe ser aislado [and] no podía correr”, agrega Wenham.
El vínculo entre la digitalización y la codificación segura
Las Islas Feroe se han basado en los esfuerzos e iniciativas de digitalización en Dinamarca, Estonia e Islandia, lo que significa que su software cumple con todos los estándares de seguridad de la UE.
Janus Læarsson es arquitecto jefe del Programa Nacional de Digitalización de las Islas Feroe. La estrategia de digitalización de las Islas Feroe implica construir una infraestructura digital para modernizar los servicios gubernamentales y brindar mejores y más rápidas experiencias a sus ciudadanos. Con tiempo y presupuesto limitados que se suman al desafío existente de escasez de talento, Læarsson dice que el equipo de TI necesitaba un enfoque para el desarrollo de software que pudiera proporcionar una alternativa al código alto y permitir que los desarrolladores externos guíen y respalden el proceso de desarrollo.
OutSystems fue seleccionado como la plataforma de código bajo para permitir que los equipos de desarrolladores participen en el proceso de creación de un sistema que sea lo suficientemente complejo y seguro para impulsar la iniciativa de digitalización nacional de las Islas Feroe. Para Læarsson, uno de los beneficios de una plataforma de desarrollo de software low-code, como OutSystems, es que se actualiza periódicamente con parches de seguridad para las bibliotecas que utiliza al crear aplicaciones low-code.
Hablando sobre la codificación segura, Læarsson dice: “Desde la definición de los criterios hasta la codificación y el lanzamiento, nuestros procesos de control de calidad incluyen pruebas automáticas y manuales, lo que nos ayuda a garantizar que impulsamos y mantenemos altos estándares con cada aplicación y actualización que hacemos. El software que desarrollamos se prueba para los estándares de calidad tanto funcional como estructural, desde la eficacia con la que las aplicaciones se adhieren a las especificaciones de diseño básicas, hasta si cumple con todos los estándares de seguridad, accesibilidad, escalabilidad y confiabilidad”.
La revisión por pares se utiliza para ejecutar una revisión técnica y lógica detallada del código línea por línea para garantizar su calidad. Dentro del Programa Nacional de Digitalización, Læarsson dice: “Nuestros proyectos de desarrollo de código bajo se dividen en equipos scrum, donde cada equipo crea historias y tareas para cada sprint y define criterios específicos para estos”.
Estas historias permiten a las personas comprender el rol de una funcionalidad de software en particular. “Cuando las historias están hechas, son probadas por los mismos analistas que han especificado las historias. Como parte de las demostraciones, las partes interesadas también tienen voz y, en última instancia, pueden aprobar o rechazar detalles. Cuando se van a lanzar componentes importantes como el portal de ciudadanos o el portal de registro de empresas, las partes interesadas ejecutan casos de prueba, especificados por nuestros analistas”, dice Læarsson.
Partes interesadas en la seguridad
Involucrar a las partes interesadas es una parte clave para garantizar que los proyectos de desarrollo de software sean tan seguros como deben ser, según Ed Moyle, miembro del Grupo de Trabajo de Tendencias Emergentes de ISACA.
“Hay una gran cantidad de formas posibles para que las partes interesadas involucradas en cualquier etapa de este proceso introduzcan o mitiguen los riesgos según los procesos que sigan, su capacitación, su conciencia y muchos otros factores”, dice. “Siempre que sea posible, se debe diseñar un programa consciente del riesgo para reducir, administrar y mitigar el riesgo del software de una manera que tenga en cuenta las preocupaciones de todas las partes interesadas involucradas en el proyecto”.
Moyle recomienda que los líderes de TI apunten a reforzar las acciones que las partes interesadas requieren para favorecer los resultados de reducción de riesgos. Pero la codificación es solo un aspecto de una estrategia completa de seguridad de aplicaciones.
“Si bien la codificación es posiblemente el paso más visible en el proceso de desarrollo y lanzamiento de software, tampoco es el único lugar en el que debemos centrarnos”, agrega Moyle. “Los esfuerzos de gestión de riesgos deben incluir todo el ciclo de vida”.
Esto significa que los responsables de la seguridad en un proyecto de TI deben comprender y dar cuenta de todo el ciclo de vida de manera integral. Además de esto, recomienda llegar a más partes interesadas. “Amplíe su planificación para incluir áreas fuera del desarrollo que, sin embargo, tienen un interés. Incluya y delegue personal de pruebas, analistas comerciales, gerentes de proyectos y productos, equipos de soporte, ventas, marketing, RR.
Moyle también insta a los responsables de la toma de decisiones de TI que buscan fortalecer sus proyectos de desarrollo de aplicaciones contra los ataques cibernéticos a evaluar cuatro áreas del proceso de desarrollo de software:
- Madurez: asegúrese de que los procesos sean maduros para que sean resistentes al desgaste de los empleados y los resultados sean consistentes.
- Transparencia: garantizar la transparencia en la cadena de suministro de los componentes y bibliotecas de los que dependen nuestros productos (y ser capaz de proporcionar esa transparencia a los clientes).
- Cumplimiento: garantice el cumplimiento de las diversas licencias (comerciales y de código abierto) utilizadas en el desarrollo de software.
- Simplicidad de diseño: asegúrese de que el diseño se preste a ser entendido y evaluado fácilmente.
Sin embargo, dice que estas cosas son solo “la punta del iceberg” cuando se trata de las consideraciones que pueden y tienen un impacto en el riesgo del software como un asunto práctico, y agrega: “Podría incluir fácilmente cosas como: apto para el propósito, diseño rigor, capacidad de soporte, cobertura de pruebas, calidad del código, tiempo de comercialización y muchas otras cosas que afectan los riesgos asociados con la forma en que diseñamos, desarrollamos, probamos, implementamos, mantenemos, brindamos soporte y, en última instancia, retiramos nuestro software”.
Para aquellos involucrados en proyectos y programas de desarrollo de software, la seguridad debe consolidarse en la mentalidad de los equipos de desarrollo y operaciones de TI. Si bien las pruebas automatizadas y la IA se pueden usar para identificar errores de programación, comprender las implicaciones de agregar una nueva función o fuente de datos, o introducir una interfaz de programación de aplicaciones, no debe ser una ocurrencia tardía.