El cumplimiento de FinServ depende de la seguridad del software

Publicado el 25 de abril de 2024
por Secure Code Warrior
ESTUDIO DE CASO

El cumplimiento de FinServ depende de la seguridad del software

Publicado el 25 de abril de 2024
por Secure Code Warrior
Ver recurso
Ver recurso

Las instituciones de servicios financieros tienen razones de peso para asegurarse de que el código de software que utilizan es seguro. Una motivación obvia, por supuesto, es la necesidad de proteger sus datos de una violación, que puede ser costosa en términos de información personal filtrada, gastos de limpieza, multas y restitución, y daños a la reputación de una organización. Otro motivo constante es la necesidad de cumplir toda una serie de normativas industriales y gubernamentales.

Como manejan tanta información sensible, personal y financiera, así como el dinero de la gente, los servicios financieros son un sector muy regulado. Dependiendo de los servicios que presten, las empresas deben cumplir una mezcla de normas y requisitos.

La Payment Card Industry Data Security Standard (PCI DSS) es bien conocida por sus normas de protección de datos de titulares de tarjetas, por ejemplo. Los requisitos de la Ley Sarbanes-Oxely regulan la gestión de los registros financieros. Las empresas que operan a escala internacional están familiarizadas con la Digital Operational Resilience Act (DORA), que es un marco vinculante de gestión de riesgos, y las normas mundiales para transferencias de fondos establecidas por la Society for Worldwide Interbank Financial Telecommunication, conocida como Swift.

Y leyes como la Ley de Privacidad del Consumidor de California (CCPA) y el Reglamento General de Protección de Datos (GDPR) de la UE establecen requisitos para proteger la privacidad y la información personal de los clientes. Hay otras, como las normativas establecidas por la Oficina del Interventor de la Moneda (OCC) de Estados Unidos y el Banco Central Europeo (BCE).

Por si fuera poco, la Estrategia Nacional de Ciberseguridad establece, entre otras cosas, que los fabricantes de software deben ser considerados responsables de la seguridad ineficaz de los programas informáticos. Y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), junto con 17 socios estadounidenses e internacionales, ha publicado orientaciones sobre los principios de Secure-By-Design para el desarrollo de software. 

Un hilo común para las empresas de servicios financieros es que el código seguro es un elemento crítico para ayudar a cumplir los objetivos de esas normativas que pueden facilitar la demostración de su cumplimiento. Y subraya por qué los desarrolladores necesitan formación y actualización para garantizar que la seguridad se aplica al código desde el principio del proceso de desarrollo.

Como ejemplo de cómo funciona, veamos la versión más reciente de PCI DSS.

La codificación segura (y la formación de los desarrolladores) es el núcleo de PCI DSS 4.0

La norma PCI DSS 4.0, que será obligatoria a partir del 1 de abril de 2024, incluye varias actualizaciones sustanciales con respecto a la norma PCI DSS 3.2.1, entre las que destaca el énfasis en el papel que desempeñan los desarrolladores a la hora de garantizar la seguridad del código de software.

La PCI reconoció hace tiempo la importancia del software seguro. La versión 2.0, que se publicó en 2017, incluía orientaciones para desarrolladores sobre cómo garantizar transacciones seguras en dispositivos móviles. Las directrices de la versión 4.0 hacen ahora hincapié en la aplicación de las mejores prácticas de seguridad al desarrollo de software e incluyen algunas orientaciones específicas sobre la formación de los desarrolladores. 

Los requisitos suelen establecerse a grandes rasgos, aunque las empresas pueden querer aplicar un enfoque más exhaustivo.

Por ejemplo, un requisito de la versión 4.0 afirma que "se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros". Una buena forma de asegurarse de que esto es así es que los desarrolladores reciban una formación precisa en los lenguajes de programación y marcos de trabajo que utilizan, con el fin de colmar cualquier laguna de conocimientos.

Otro requisito establece que los desarrolladores que trabajen con software a medida y personalizado deben recibir formación al menos una vez cada 12 meses, que cubra:

  • Seguridad del software pertinente para su función laboral y lenguajes de desarrollo.
  • Diseño de software seguro y técnicas de codificación. 
  • Cómo utilizar las herramientas de pruebas de seguridad -si se utilizan- para detectar vulnerabilidades en el software.

Pero, en realidad, una vez al año no es suficiente para abordar los principales problemas de seguridad y acabar con los malos hábitos de codificación. La formación debe ser continua y mesurada, con un proceso de verificación de las competencias para garantizar que se hace un buen uso de ella.

PCI DSS 4.0 incluye más de media docena de otros requisitos que abordan áreas como la prevención y mitigación de diversos tipos de ataques, la documentación de componentes de software de terceros, la identificación y gestión de vulnerabilidades y otras medidas de seguridad. En todos los casos, las organizaciones harían bien en aplicar a fondo esas medidas. La formación sobre vectores de ataque debe ser frecuente, no anual. Los componentes de terceros, que suelen ser una fuente de vulnerabilidades, deben inventariarse cuidadosamente mediante un programa de lista de materiales de software (SBOM). Y las organizaciones deben asegurarse de tener funciones claramente definidas para gestionar las vulnerabilidades.

La nueva versión también ofrece a las organizaciones cierta flexibilidad a la hora de cumplir sus requisitos, centrándose en los resultados más que en marcar casillas, al tiempo que añade nuevos requisitos para los controles de autenticación, la longitud de las contraseñas, las cuentas compartidas y otros factores. 

La conformidad comienza al principio del SDLC

Lo que estas normativas tienen en común es que intentan establecer normas estrictas para proteger los datos y las transacciones en el sector de los servicios financieros. Y, como en el caso de la última versión de la PCI DSS, hacen cada vez más hincapié en la importancia de un código seguro al principio del ciclo de vida de desarrollo del software (SDLC). La Estrategia Nacional de Ciberseguridad y los principios Secure by Design de CISA también responsabilizan de la seguridad a los creadores de software -antes de que se distribuya-, de modo que incluso las empresas que no se rigen directamente por la normativa de servicios financieros deben cumplirla.

Las organizaciones necesitan salvar la brecha que existe entre los equipos DevOps (que se centran en la velocidad de desarrollo) y los equipos AppSec (que se apresuran a introducir la seguridad en el proceso) formando a los desarrolladores para que la seguridad sea inherente a su enfoque. Sin embargo, esto requiere un complejo conjunto de habilidades que implican más de lo que pueden ofrecer las sesiones de formación anuales o los programas educativos estándar y estancados. La formación debe ser continua y ágil, diseñada para involucrar a los alumnos con escenarios activos del mundo real e impartida en pequeñas sesiones que se adapten a sus horarios de trabajo.

Las empresas de servicios financieros necesitan garantizar la seguridad tanto para protegerse contra las infracciones como para cumplir la normativa, cada vez más estricta. Los costes del incumplimiento pueden ser tan perjudiciales como una violación en términos de impacto en la reputación de una empresa y costes monetarios. El Informe de IBM sobre el coste de una violación de datos en 2023, por ejemplo, descubrió que las organizaciones con un alto nivel de incumplimiento se enfrentaban, de media, a multas y otros costes por un total de 5,05 millones de dólares, medio millón más que el coste medio de una violación de datos real.

El continuo crecimiento de los entornos basados en la nube y las transacciones digitales ha hecho que la seguridad del software en el sector de los servicios financieros sea de vital importancia, algo que reconocen normativas como PCI DSS. La mejor manera de garantizar un software seguro es mediante una codificación segura al inicio del SDLC. Y la forma de conseguirlo es formando eficazmente a los desarrolladores en prácticas de codificación segura. 

Para obtener una visión completa de cómo la codificación segura puede ayudar a garantizar el éxito, la seguridad y los beneficios de las empresas de servicios financieros, puede leer el libro electrónico recién publicado Secure Code Warrior : La guía definitiva de las tendencias de seguridad en los servicios financieros.

Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas y saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.

Ver recurso
Ver recurso

Autor

Secure Code Warrior

Secure Code Warrior crea una cultura de desarrolladores orientados a la seguridad, dotándoles de las habilidades necesarias para codificar de forma segura. Nuestro buque insignia es Agile Learning Platform , que ofrece itinerarios basados en habilidades relevantes, prácticas en missions y herramientas contextuales para que los desarrolladores aprendan, desarrollen y apliquen rápidamente sus habilidades para escribir código seguro a gran velocidad.

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

El cumplimiento de FinServ depende de la seguridad del software

Publicado el 25 de abril de 2024
Por Secure Code Warrior

Las instituciones de servicios financieros tienen razones de peso para asegurarse de que el código de software que utilizan es seguro. Una motivación obvia, por supuesto, es la necesidad de proteger sus datos de una violación, que puede ser costosa en términos de información personal filtrada, gastos de limpieza, multas y restitución, y daños a la reputación de una organización. Otro motivo constante es la necesidad de cumplir toda una serie de normativas industriales y gubernamentales.

Como manejan tanta información sensible, personal y financiera, así como el dinero de la gente, los servicios financieros son un sector muy regulado. Dependiendo de los servicios que presten, las empresas deben cumplir una mezcla de normas y requisitos.

La Payment Card Industry Data Security Standard (PCI DSS) es bien conocida por sus normas de protección de datos de titulares de tarjetas, por ejemplo. Los requisitos de la Ley Sarbanes-Oxely regulan la gestión de los registros financieros. Las empresas que operan a escala internacional están familiarizadas con la Digital Operational Resilience Act (DORA), que es un marco vinculante de gestión de riesgos, y las normas mundiales para transferencias de fondos establecidas por la Society for Worldwide Interbank Financial Telecommunication, conocida como Swift.

Y leyes como la Ley de Privacidad del Consumidor de California (CCPA) y el Reglamento General de Protección de Datos (GDPR) de la UE establecen requisitos para proteger la privacidad y la información personal de los clientes. Hay otras, como las normativas establecidas por la Oficina del Interventor de la Moneda (OCC) de Estados Unidos y el Banco Central Europeo (BCE).

Por si fuera poco, la Estrategia Nacional de Ciberseguridad establece, entre otras cosas, que los fabricantes de software deben ser considerados responsables de la seguridad ineficaz de los programas informáticos. Y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), junto con 17 socios estadounidenses e internacionales, ha publicado orientaciones sobre los principios de Secure-By-Design para el desarrollo de software. 

Un hilo común para las empresas de servicios financieros es que el código seguro es un elemento crítico para ayudar a cumplir los objetivos de esas normativas que pueden facilitar la demostración de su cumplimiento. Y subraya por qué los desarrolladores necesitan formación y actualización para garantizar que la seguridad se aplica al código desde el principio del proceso de desarrollo.

Como ejemplo de cómo funciona, veamos la versión más reciente de PCI DSS.

La codificación segura (y la formación de los desarrolladores) es el núcleo de PCI DSS 4.0

La norma PCI DSS 4.0, que será obligatoria a partir del 1 de abril de 2024, incluye varias actualizaciones sustanciales con respecto a la norma PCI DSS 3.2.1, entre las que destaca el énfasis en el papel que desempeñan los desarrolladores a la hora de garantizar la seguridad del código de software.

La PCI reconoció hace tiempo la importancia del software seguro. La versión 2.0, que se publicó en 2017, incluía orientaciones para desarrolladores sobre cómo garantizar transacciones seguras en dispositivos móviles. Las directrices de la versión 4.0 hacen ahora hincapié en la aplicación de las mejores prácticas de seguridad al desarrollo de software e incluyen algunas orientaciones específicas sobre la formación de los desarrolladores. 

Los requisitos suelen establecerse a grandes rasgos, aunque las empresas pueden querer aplicar un enfoque más exhaustivo.

Por ejemplo, un requisito de la versión 4.0 afirma que "se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros". Una buena forma de asegurarse de que esto es así es que los desarrolladores reciban una formación precisa en los lenguajes de programación y marcos de trabajo que utilizan, con el fin de colmar cualquier laguna de conocimientos.

Otro requisito establece que los desarrolladores que trabajen con software a medida y personalizado deben recibir formación al menos una vez cada 12 meses, que cubra:

  • Seguridad del software pertinente para su función laboral y lenguajes de desarrollo.
  • Diseño de software seguro y técnicas de codificación. 
  • Cómo utilizar las herramientas de pruebas de seguridad -si se utilizan- para detectar vulnerabilidades en el software.

Pero, en realidad, una vez al año no es suficiente para abordar los principales problemas de seguridad y acabar con los malos hábitos de codificación. La formación debe ser continua y mesurada, con un proceso de verificación de las competencias para garantizar que se hace un buen uso de ella.

PCI DSS 4.0 incluye más de media docena de otros requisitos que abordan áreas como la prevención y mitigación de diversos tipos de ataques, la documentación de componentes de software de terceros, la identificación y gestión de vulnerabilidades y otras medidas de seguridad. En todos los casos, las organizaciones harían bien en aplicar a fondo esas medidas. La formación sobre vectores de ataque debe ser frecuente, no anual. Los componentes de terceros, que suelen ser una fuente de vulnerabilidades, deben inventariarse cuidadosamente mediante un programa de lista de materiales de software (SBOM). Y las organizaciones deben asegurarse de tener funciones claramente definidas para gestionar las vulnerabilidades.

La nueva versión también ofrece a las organizaciones cierta flexibilidad a la hora de cumplir sus requisitos, centrándose en los resultados más que en marcar casillas, al tiempo que añade nuevos requisitos para los controles de autenticación, la longitud de las contraseñas, las cuentas compartidas y otros factores. 

La conformidad comienza al principio del SDLC

Lo que estas normativas tienen en común es que intentan establecer normas estrictas para proteger los datos y las transacciones en el sector de los servicios financieros. Y, como en el caso de la última versión de la PCI DSS, hacen cada vez más hincapié en la importancia de un código seguro al principio del ciclo de vida de desarrollo del software (SDLC). La Estrategia Nacional de Ciberseguridad y los principios Secure by Design de CISA también responsabilizan de la seguridad a los creadores de software -antes de que se distribuya-, de modo que incluso las empresas que no se rigen directamente por la normativa de servicios financieros deben cumplirla.

Las organizaciones necesitan salvar la brecha que existe entre los equipos DevOps (que se centran en la velocidad de desarrollo) y los equipos AppSec (que se apresuran a introducir la seguridad en el proceso) formando a los desarrolladores para que la seguridad sea inherente a su enfoque. Sin embargo, esto requiere un complejo conjunto de habilidades que implican más de lo que pueden ofrecer las sesiones de formación anuales o los programas educativos estándar y estancados. La formación debe ser continua y ágil, diseñada para involucrar a los alumnos con escenarios activos del mundo real e impartida en pequeñas sesiones que se adapten a sus horarios de trabajo.

Las empresas de servicios financieros necesitan garantizar la seguridad tanto para protegerse contra las infracciones como para cumplir la normativa, cada vez más estricta. Los costes del incumplimiento pueden ser tan perjudiciales como una violación en términos de impacto en la reputación de una empresa y costes monetarios. El Informe de IBM sobre el coste de una violación de datos en 2023, por ejemplo, descubrió que las organizaciones con un alto nivel de incumplimiento se enfrentaban, de media, a multas y otros costes por un total de 5,05 millones de dólares, medio millón más que el coste medio de una violación de datos real.

El continuo crecimiento de los entornos basados en la nube y las transacciones digitales ha hecho que la seguridad del software en el sector de los servicios financieros sea de vital importancia, algo que reconocen normativas como PCI DSS. La mejor manera de garantizar un software seguro es mediante una codificación segura al inicio del SDLC. Y la forma de conseguirlo es formando eficazmente a los desarrolladores en prácticas de codificación segura. 

Para obtener una visión completa de cómo la codificación segura puede ayudar a garantizar el éxito, la seguridad y los beneficios de las empresas de servicios financieros, puede leer el libro electrónico recién publicado Secure Code Warrior : La guía definitiva de las tendencias de seguridad en los servicios financieros.

Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas y saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.