Las nuevas directrices del NIST: Por qué la formación personalizada es esencial para crear software seguro

El 11 de junio de 2019, el Instituto Nacional de Estándares y Tecnología (NIST) publicó un libro blanco actualizado, en el que se detallan varios planes de acción para reducir vulnerabilidades de software y riesgo cibernético. Titulado Mitigar el riesgo de vulnerabilidades de software mediante la adopción de un marco de desarrollo de software seguro (SSDF), el NIST proporciona a las organizaciones directrices sólidas para evitar las consecuencias nefastas, por no hablar de las costosas, de una violación de datos.

Es importante tener en cuenta que la SSDF es deliberadamente genérica, no supone que todas las organizaciones tengan exactamente los mismos objetivos de seguridad del software ni prescribe un mecanismo exacto para lograrlos. El objetivo principal es implementar las mejores prácticas de seguridad. Como afirma la escritora Donna Dodson: «Si bien el deseo es que cada productor de seguridad siga todas las prácticas aplicables, la expectativa es que el grado de implementación de cada práctica varíe en función de las suposiciones de seguridad del productor. Las prácticas brindan flexibilidad a los implementadores, pero también son claras para evitar dejar demasiadas posibilidades de interpretación».

De particular interés para mí, por supuesto, fueron las inclusiones específicas en torno a la formación en seguridad del software para desarrolladores. Hace tiempo que sabemos que los desarrolladores necesitan una formación adecuada si quieren defender a una organización desde el principio del proceso de desarrollo de software... pero ¿qué es adecuado, ¿exactamente? Hay muchas opiniones diferentes por ahí. Sin embargo, creo que por fin se están ampliando los límites en una dirección que generará importantes resultados positivos.

Hay formación en seguridad... y hay una formación en seguridad eficaz.

He hablado extensamente sobre la necesidad de que la formación en seguridad del software se implemente de manera más eficaz, participe y se adapte a las necesidades del desarrollador. Incluso ahora, en muchas organizaciones, se trata, en el mejor de los casos, de un ejercicio que consiste en «marcar las casillas». Quizás haya que dedicar unas horas a la formación en vídeo, o incluso dedicarle un valioso tiempo a no utilizar las herramientas para aprender en el aula. El hecho de que se produzcan filtraciones de datos a gran escala cada dos días, perpetradas por atacantes que explotan vulnerabilidades conocidas (y, por lo general, fáciles de solucionar) demuestra que la formación en seguridad del software no es ni de lejos tan eficaz como debería ser. Y, quizás lo más importante, es que hay muy pocos medios para comprobar si la formación ha sido realmente eficaz: ¿se corrigen las vulnerabilidades con mayor rapidez? ¿Se están reduciendo las vulnerabilidades en el código? ¿Las personas han completado realmente la capacitación o simplemente han hecho clic en «Siguiente» para completarla?

Los desarrolladores son personas ocupadas que trabajan arduamente para cumplir con plazos estrictos. La seguridad es un inconveniente la mayor parte del tiempo, y rara vez cuentan con los conocimientos necesarios durante su formación para mitigar con éxito el riesgo cibernético. La palabra «seguridad» suele aparecer cuando un miembro del equipo de AppSec señala deficiencias en su trabajo, lo que genera una relación bastante fría y disfuncional. Un escenario de «tu bebé es feo, ve a arreglarlo».

¿Qué nos dice esto? Es una señal de alerta de hace décadas que no estamos haciendo lo suficiente para convencer a los desarrolladores en materia de seguridad; no están motivados para asumir la responsabilidad ni para buscar las herramientas que necesitan para crear un software que sea funcional y, al mismo tiempo, creado teniendo en cuenta las mejores prácticas de seguridad.

Los desarrolladores son inteligentes, creativos y les encanta resolver problemas. Es poco probable que ver un sinfín de vídeos sobre las vulnerabilidades de seguridad los entusiasme o los ayude a mantener el interés. Durante mi etapa como instructor de SANS, aprendí rápidamente que la mejor formación es la práctica, ya que los obliga a analizar y a enfrentarse a desafíos intelectuales, utilizando ejemplos del mundo real que ponen a prueba su cerebro y se basan en el aprendizaje previo. La gamificación y la competencia amistosa también son herramientas poderosas para que todos se familiaricen con los nuevos conceptos, sin dejar de ser útiles y prácticos en su aplicación.

Las directrices del NIST especifican: «Brindar capacitación específica para cada función a todo el personal que desempeñe funciones con responsabilidades que contribuyan a un desarrollo seguro. Revise periódicamente la capacitación específica para cada función y actualícela según sea necesario». Y más adelante: «Defina las funciones y responsabilidades del personal de ciberseguridad, los defensores de la seguridad, la alta dirección, los desarrolladores de software, los propietarios de productos y otras personas involucradas en el SDLC».

Esta declaración, si bien no especifica el tipo de capacitación, sigue ayudando a las organizaciones a inclinarse a la izquierda y a mantener las mejores prácticas de seguridad en primer plano. Está devolviendo a la empresa la responsabilidad de encontrar soluciones de formación eficaces y más específicas, y es de esperar que esto dé como resultado que los desarrolladores cuenten con las herramientas y los conocimientos adecuados para tener éxito.

La cultura: el eslabón perdido.

Incluso si una organización dedica tiempo y recursos a capacitar a los desarrolladores y otro personal clave, haciendo hincapié en su papel a la hora de prevenir las vulnerabilidades y reducir los riesgos de seguridad, el esfuerzo a menudo puede desperdiciarse si la cultura de seguridad de una organización sigue siendo fundamentalmente deficiente.

Cuando las personas reciben una formación eficaz, con los objetivos establecidos y las expectativas claras, les resulta mucho más fácil comprender su lugar en el panorama de la seguridad y asumir la responsabilidad cuando corresponde. Especialmente en el caso de los desarrolladores, se les proporcionan las herramientas y los conocimientos necesarios para escribir código seguro desde el principio. Sin embargo, la mejor forma de organizarlo es en un entorno de seguridad positivo, en el que haya menos trabajo en proyectos con doble manipulación, señalamientos con el dedo y en silos.

La seguridad debe ser una prioridad para toda la organización, con un compromiso de apoyo y colaboración para ofrecer un software excelente y seguro. Esto implicará que los presupuestos sean suficientes para impartir una formación divertida y atractiva que aproveche las vulnerabilidades de los códigos del mundo real, y para que toda la organización apoye la iniciativa. En este panorama digital en constante evolución, la formación debe ser tan continua como la impartición. Si en el pasado le han dicho que la capacitación sobre cumplimiento «única» o «configurar y olvidar» es adecuada o eficaz, se trata de una falacia.

Si bien este nuevo marco del NIST no articula específicamente el requisito de fomentar una cultura de seguridad positiva, el cumplimiento exitoso de sus directrices sin duda lo requerirá. Sin embargo, señalan que las organizaciones deben «definir políticas que especifiquen los requisitos de seguridad que debe cumplir el software de la organización, incluidas las prácticas de codificación segura que deben seguir los desarrolladores».

Lo anterior es vital para escalar y perfeccionar las habilidades de seguridad dentro de los equipos, y puede resultar útil tener en cuenta lo siguiente al evaluar sus propias políticas y el clima actual de AppSec:

• ¿Están claramente definidas las directrices y expectativas de seguridad del software?
• ¿Todos tienen claro el papel que desempeñan para lograrlos?
• ¿La capacitación es frecuente y evaluada?
• ¿Sus desarrolladores son conscientes del importante papel que pueden desempeñar a la hora de eliminar los errores de seguridad más comunes antes de que ocurran?

Ahora, esa última parte, como he dicho, depende en gran medida de la organización y la formación que elijan. Debe ser relevante, frecuente y atractiva. Encuentre una solución que pueda aplicarse a su trabajo diario y desarrolle sus conocimientos contextualmente.

¿Ahora qué?

Es probable que profundizar en estas nuevas directrices sea bastante abrumador; realmente se necesita un pueblo para crear, verificar e implementar el software seguro y férreo que la mayoría de las empresas necesitan, de la manera más segura posible. Tampoco se trata solo de formación. Hay pautas que se deben tener en cuenta al usar software de terceros (uso de componentes con vulnerabilidades conocidas todavía se encuentra en el Los 10 mejores de OWASP, al fin y al cabo), sugerencias sobre la verificación, las pruebas de penetración y la revisión del código, así como directrices para el mantenimiento de registros de seguridad, las cadenas de herramientas adecuadas y todo lo demás. En el libro del Dr. Gary McGraw puede encontrar información práctica sobre el panorama general Modelo BSIMM, al que se hace referencia en todo el documento del NIST.

Sin embargo, la ganancia más rápida se puede lograr si sus desarrolladores cuentan con las herramientas y los conocimientos adecuados para tener éxito en la creación de software seguro desde el principio. Resulta más barato para la empresa (y, en general, más rápido) evitar que las vulnerabilidades más comunes aparezcan en las etapas posteriores del SDLC, una y otra vez. Aproveche sus puntos fuertes y ofrézcales un incentivo para que se involucren en el aspecto de la seguridad de la organización. Puede ser muy divertido y pueden convertirse en los héroes que llegan justo a tiempo para mantener alejados a los malos y proteger nuestros datos.

Referencias:

1. MITIGAR EL RIESGO DE VULNERABILIDADES DEL SOFTWARE MEDIANTE LA ADOPCIÓN DE UN SSDF (11 DE JUNIO DE 2019), Página 2.
2. MITIGAR EL RIESGO DE VULNERABILIDADES DEL SOFTWARE MEDIANTE LA ADOPCIÓN DE UN SSDF (11 DE JUNIO DE 2019), Página 5.
3. MITIGAR EL RIESGO DE VULNERABILIDADES DEL SOFTWARE MEDIANTE LA ADOPCIÓN DE UN SSDF (11 DE JUNIO DE 2019), Página 4.