TecNoticias, tu portal de información

Las empresas que operan en el ámbito de los servicios financieros en la actualidad deben adherirse a una gran cantidad de estándares regulatorios complejos, lo cual tiene mucho sentido dado que tanto los activos como la información administrada por dichas empresas son valiosos y sensibles y, como resultado, son muy objeto de ataques informáticos sofisticados a diario .

Para agravar estos desafíos está el gran volumen de información de identificación personal (PII) que estas organizaciones también manejan, que está sujeta a una gran cantidad de estándares de la industria y al Reglamento general de protección de datos. Si bien algunas regulaciones son explícitas, como PCI-DSS, otras son más generales y simplemente indican que la PII debe protegerse contra ataques. Sin embargo, para cumplir con cualquier estándar regulatorio importante, las organizaciones deben tener visibilidad de los riesgos, las vulnerabilidades y los flujos de datos en su software. También deben tener sistemas y un plan para abordarlos.

Si bien las organizaciones de servicios financieros han sido históricamente sólidas cuando se trata de emplear herramientas de prueba de seguridad de aplicaciones, se puede hacer más para acelerar los esfuerzos y hacerlos continuos.

Entonces, ¿qué medidas específicas pueden tomar las empresas en este espacio para abordar la seguridad en el software que crean para el resto de 2022, y cómo las beneficiará esto a largo plazo?

Aplicaciones de clasificación de riesgo

Desde una perspectiva de riesgo empresarial, no todas las aplicaciones son iguales, por lo que el primer paso para reducir el riesgo debería ser cuantificar el riesgo inherente asociado con cada aplicación. Las organizaciones pueden lograr esto mediante el uso de una metodología de prioridad de riesgo para clasificar las aplicaciones en función del daño potencial a los objetivos comerciales de la empresa como resultado de un ataque exitoso.

Por ejemplo, la seguridad de una aplicación de banca en línea que permite a los clientes transferir fondos, realizar grandes transacciones y cambiar privilegios es fundamental para los objetivos comerciales de un banco. Una infracción de dicha aplicación podría causar un gran daño financiero, reglamentario y de reputación. Por el contrario, es probable que haya aplicaciones internas que no procesen información confidencial o que tengan una superficie de ataque limitada. En términos de valor comercial, estos son menos críticos y no justifican el mismo escrutinio desde el punto de vista de la seguridad.

La clasificación de riesgos es una buena práctica para ingresar y puede empoderar a los equipos de seguridad con tiempo y recursos limitados para aplicar los recursos adecuados a las aplicaciones con mayor riesgo, maximizando a su vez la eficiencia operativa. El resultado debe ser un inventario de aplicaciones con una clasificación de riesgo para cada aplicación. Luego, los recursos se pueden asignar según la clasificación de riesgo de cada aplicación comercial.

Establecer requisitos de seguridad claros

Para lograr verdaderas DevSecOps, los equipos deben acordar "métricas" para una seguridad adecuada. Esto requiere una comunicación y colaboración abiertas y continuas entre los equipos de desarrollo, seguridad y operaciones, ya que las métricas serán diferentes para varios tipos de aplicaciones. En el caso de los componentes de código abierto, estos requisitos deben incluir la comprensión de cada proyecto, que incluya qué tan bien cuenta con el respaldo de la comunidad, su historial de seguridad y cualquier requisito de licencia de código abierto. Para el código personalizado y la aplicación completa, es esencial contar con un acuerdo que indique explícitamente cuándo se realizarán las pruebas de seguridad y qué condiciones requerirán romper una compilación.

Por ejemplo, una organización puede (y debe) dictar que las aplicaciones no se pueden implementar si se identifica una vulnerabilidad "grave". El proceso de compilación automatizado de una aplicación debe detenerse si se aplica esa condición.

Identificación continua de vulnerabilidades

La seguridad debe integrarse en todas las fases del desarrollo de software para las organizaciones de servicios financieros. Este enfoque no solo mejorará la seguridad en los entornos DevOps (es decir, DevSecOps), sino que también acelerará el tiempo de comercialización y reducirá los costos de desarrollo, ya que las vulnerabilidades encontradas anteriormente suelen ser menos complicadas y requieren más tiempo de solucionar.

Las soluciones de pruebas de seguridad de aplicaciones estáticas (SAST) se pueden integrar en el SDLC desde el comienzo de la fase de código, a través del repositorio de código fuente cuando se registra un nuevo código fuente o se agregan a los procesos de compilación automatizados. El análisis de composición de software (SCA) se puede utilizar en las primeras versiones para identificar dependencias de código abierto y asignar componentes a vulnerabilidades divulgadas públicamente, continuando con la fase de prueba / control de calidad. Las pruebas de seguridad de aplicaciones integradas (IAST) se pueden realizar durante las pruebas funcionales automatizadas en la etapa de prueba / control de calidad.

Al integrar lo anterior en la orquestación de integración continua (CI), los equipos pueden automatizar procesos y realizar escaneos incrementales solo del código que ha cambiado. Por el contrario, las soluciones que requieren horas para escanear la compilación de una aplicación completa no se adaptan bien a los entornos DevOps.

Capacitar a los desarrolladores para que codifiquen de forma segura desde el principio

Es importante que los equipos de seguridad asuman un papel activo en la participación y la colaboración con sus homólogos de DevOps desde el principio. La educación aquí es de gran importancia.

Los equipos de seguridad en las organizaciones de servicios financieros deben capacitar a los equipos de DevOps en métodos de ataque específicos y técnicas de piratería populares, proporcionando las herramientas necesarias para identificar vulnerabilidades mientras escriben código. También deben actuar como caja de resonancia durante todo el proceso. Al proporcionar comentarios continuos y estar disponible para responder preguntas de codificación segura a pedido, los equipos de seguridad pueden reducir en gran medida el tiempo necesario para corregir las vulnerabilidades, lo que se traduce en una mejor seguridad y una entrega de software más predecible.

Al establecer las mejores prácticas y hacer de la Educación de codificación segura (SCE) un proceso continuo, los equipos de seguridad pueden facilitar que los desarrolladores codifiquen de forma segura desde el principio. Los desarrolladores también pueden ser más receptivos a la capacitación cuando es relevante, retener las lecciones aprendidas más fácilmente y, en última instancia, convertirse en mejores campeones de seguridad para la organización. También puede ser útil identificar específicamente a los campeones de seguridad en los equipos de desarrollo, de modo que conviértase en la persona de referencia de ese equipo con respecto a las cuestiones de seguridad y que tenga un vínculo más cercano con el equipo de seguridad en comparación con el resto del equipo de desarrollo.

Recordar la seguridad de las aplicaciones no es una tarea de una sola vez

Los componentes y marcos de código abierto ofrecen claras ventajas, incluida la reducción de los costos de desarrollo y la aceleración del tiempo de comercialización. Sin embargo, para mantener una seguridad sólida, deben analizarse durante las fases de codificación y creación. Y no termina ahí.

Es fundamental continuar monitoreando el software de código abierto en busca de vulnerabilidades recientemente reveladas en todo el SDLC. Algunas vulnerabilidades como ShellShock (CVE-2014-6271) solo se descubrieron décadas después de que se introdujera la vulnerabilidad original. Sin visibilidad tanto de la versión del componente de código abierto como de su ubicación en la base de código, es muy difícil encontrar y corregir vulnerabilidades. Hoy en día, la seguridad efectiva de las aplicaciones debe ser continua.

Trazando un rumbo para el éxito de la seguridad

Hoy en día, los actores malévolos entregan PII utilizada para el robo de identidad en grandes cantidades, mientras que el impacto de las violaciones de datos ahora va mucho más allá de la simple vergüenza para una empresa. Los ataques ahora resultan en pérdida de reputación, valor para los accionistas y, en algunos casos, el despido de líderes corporativos. Y eso es antes de multas significativas, investigaciones legislativas intensificadas y desconfianza pública constante.

La forma en que las organizaciones de servicios financieros construyen software hoy en día es radicalmente diferente a hace una década, con nuevos modelos de desarrollo que ayudan a entregar software más rápido que nunca.

Si bien las organizaciones de servicios financieros han tenido un buen historial hasta la fecha, necesitan intensificar los esfuerzos y hacer que estos sean continuos desde el principio del SDLC, integrando diferentes herramientas de prueba en una perspectiva holística con una combinación de resultados de SAST, SCA e IAST. En un mercado tan competitivo, simplemente ya no es una opción ofrecer algo que no se haya probado para detectar problemas de seguridad durante todo el proceso de desarrollo. Los riesgos son simplemente demasiado grandes.

Dependemos tanto del software como de su seguridad para completar miles de millones de transacciones todos los días. Ha llegado el momento de garantizar que la seguridad esté integrada desde el inicio del SDLC. Esto solo ayudará a las empresas en el campo a administrar, medir y abordar mejor los riesgos, empoderar a los equipos de desarrollo y garantizar la entrega segura de software a la velocidad de DevOps.

¿Quiere aprender sobre DevOps de parte de los líderes en el espacio? Consulte la Cumbre DevOps-as-a-Service, que tendrá lugar el 7 de octubre de 2022, donde los asistentes conocerán los beneficios de crear colaboración y asociaciones en la entrega.
Etiquetas: desarrollo, servicios financieros, seguridad, seguridad de software