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

Publicado el 02 de diciembre de 2019
por Pieter Danhieux
ESTUDIO DE CASO

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

Publicado el 02 de diciembre de 2019
por Pieter Danhieux
Ver recurso
Ver recurso

El 11 de junio de 2019, el Instituto Nacional de Normas y Tecnología(NIST) publicó un libro blanco actualizado, en el que se detallan varios planes de acción para reducir las vulnerabilidades del software y el riesgo cibernético. Bajo el título Mitigar el riesgo de las vulnerabilidades del software mediante la adopción de un marco de desarrollo de software seguro (SSDF), el NIST ofrece a las organizaciones unas directrices sólidas para evitar las desagradables -por no decir costosas- consecuencias de una violación de datos.

Es importante señalar que el SSDF es deliberadamente genérico, no supone que todas las organizaciones tengan exactamente los mismos objetivos de seguridad del software, ni prescribe un mecanismo exacto para alcanzarlos. El objetivo principal es aplicar las mejores prácticas de seguridad. Como afirma la autora, Donna Dodson: "Aunque el deseo es que cada productor de seguridad siga todas las prácticas aplicables, se espera que el grado de aplicación de cada práctica varíe en función de los supuestos de seguridad del productor. Las prácticas proporcionan flexibilidad a los ejecutores, pero también son claras para evitar que queden demasiado abiertas a la interpretación".

Por supuesto, me interesaron especialmente las inclusiones relacionadas con la formación en seguridad del software para los desarrolladores. Hace tiempo que sabemos que los desarrolladores necesitan una formación adecuada para defender a una organización desde el principio del proceso de desarrollo de software... pero ¿qué es lo adecuado, exactamente? Hay muchas opiniones divergentes. Sin embargo, creo que por fin se está empujando el sobre en una dirección que encenderá resultados positivos significativos.

Hay formación en seguridad... y hay formación en seguridad efectiva.

He hablado largo y tendido sobre la necesidad de que la formación en seguridad del software se aplique de forma más eficaz, se comprometa y se adapte a las necesidades del desarrollador. Incluso ahora, en muchas organizaciones, es un ejercicio de "marcar la casilla" en el mejor de los casos. Tal vez haya algunas horas de formación en vídeo, o incluso un tiempo precioso dedicado a las herramientas para algún aprendizaje basado en el aula. El hecho de que cada dos días se produzcan filtraciones de datos a gran escala, perpetradas por atacantes que explotan vulnerabilidades bien conocidas (y, por lo general, fácilmente corregibles), es una prueba de que la formación en seguridad del software no es ni de lejos todo lo eficaz que debería ser. Y, tal vez lo más importante, hay muy poco para verificar si la formación fue efectiva en absoluto: ¿se arreglan las vulnerabilidades más rápido? ¿se reducen las vulnerabilidades en el código? ¿la gente ha completado realmente la formación, o simplemente ha hecho clic en "siguiente" para completarla?

Los desarrolladores son personas ocupadas, que trabajan duro para cumplir con plazos estrictos. La seguridad es un inconveniente la mayor parte del tiempo, y rara vez están equipados con el conocimiento durante su educación para mitigar con éxito el riesgo cibernético. La palabra "seguridad" suele surgir cuando un miembro del equipo de AppSec señala defectos en su trabajo, lo que da lugar a 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 alarma de hace décadas que no estamos haciendo lo suficiente para ganarnos a los desarrolladores en materia de seguridad; no están motivados para asumir responsabilidades, ni buscan las herramientas que necesitan para crear software que sea funcional, pero hecho con las mejores prácticas de seguridad en mente.

Los desarrolladores son inteligentes, creativos y les encanta resolver problemas. Es muy poco probable que ver interminables vídeos sobre vulnerabilidades de seguridad les entusiasme o les ayude a seguir comprometidos. En mi tiempo como instructor de SANS, aprendí muy rápidamente que la mejor formación es la práctica, obligándoles a analizar y ser desafiados intelectualmente, utilizando ejemplos del mundo real que ponen a prueba su cerebro y se basan en el aprendizaje previo. La ludificación y la competición amistosa son también herramientas poderosas para que todos los participantes se comprometan con los nuevos conceptos, sin dejar de ser útiles y prácticos en su aplicación.

Las directrices del NIST especifican: "Proporcionar formación específica para cada función a todo el personal con responsabilidades que contribuyan al desarrollo seguro. Revise periódicamente la formación específica de cada función y actualícela según sea necesario". Y más adelante: "Definir las funciones y responsabilidades del personal de ciberseguridad, los campeones de seguridad, la alta dirección, los desarrolladores de software, los propietarios de los productos y otros involucrados en el SDLC".

Esta declaración, aunque no es específica sobre el tipo de formación, está ayudando a desplazar a las organizaciones hacia la izquierda y a mantener las mejores prácticas de seguridad en primera línea. Vuelve a poner en manos de la empresa la responsabilidad de encontrar soluciones de formación eficaces y más específicas, y es de esperar que esto dé lugar a que los desarrolladores se armen con las herramientas y los conocimientos adecuados para tener éxito.

La cultura: el eslabón perdido.

Aunque una organización dedique tiempo y recursos a la formación de los desarrolladores y otro personal clave, haciendo hincapié en su papel en la prevención de las vulnerabilidades y la reducción del riesgo de seguridad, el esfuerzo a menudo puede resultar inútil si la cultura de seguridad de una organización sigue estando fundamentalmente rota.

Cuando las personas reciben una formación eficaz, con objetivos establecidos y expectativas claras, les resulta mucho más fácil entender su lugar en el panorama de la seguridad y asumir la responsabilidad cuando corresponda. En el caso de los desarrolladores, especialmente, se les dan las herramientas y los conocimientos para escribir código seguro desde el principio. Sin embargo, la mejor manera de orquestar esto es en un entorno de seguridad positivo, donde hay menos doble manipulación, señalamientos y trabajo de proyecto 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 significará que los presupuestos son adecuados para desplegar una formación divertida y atractiva que utilice las vulnerabilidades del código del mundo real, y la aceptación de toda la organización para mantener el impulso. En este panorama digital en constante evolución, la formación debe ser tan continua como la entrega. Si le han dicho en el pasado que la formación en materia de cumplimiento de la normativa "una sola vez" o "lista y olvidada" es adecuada o eficaz, esto es una falacia.

Aunque este nuevo marco del NIST no articula específicamente el requisito de alimentar una cultura de seguridad positiva, adherirse con éxito a sus directrices requerirá sin duda una. No obstante, 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 ser útil considerar 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?
  • ¿Todo el mundo tiene claro el papel que desempeña en su consecución?
  • ¿La formación es frecuente y se evalúa?
  • ¿Son sus desarrolladores conscientes del enorme papel que pueden desempeñar en la eliminación de errores de seguridad comunes antes de que se produzcan?

Ahora bien, esta última parte depende, como he dicho, en gran medida de la organización y de la formación que elija. Debe ser pertinente, frecuente y atractiva. Hay que encontrar una solución que pueda aplicarse a su trabajo diario y construir contextualmente sus conocimientos.

¿Y ahora qué?

Es probable que una inmersión en estas nuevas directrices sea bastante abrumadora; realmente se necesita un pueblo para crear, verificar y desplegar el software seguro de hierro que la mayoría de las empresas necesitan, de la manera más segura posible. Tampoco se trata sólo de la formación. Hay que tener en cuenta las directrices cuando se utiliza software de terceros( después de todo, eluso de componentes con vulnerabilidades conocidas sigue estando en el Top 10 de OWASP), sugerencias en torno a 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, cadenas de herramientas adecuadas y todo lo demás. En el modelo BSIMM del Dr. Gary McGraw, al que se hace referencia en todo el documento del NIST, se pueden encontrar ideas útiles para todo el panorama.

Sin embargo, la victoria más rápida se puede lograr si sus desarrolladores cuentan con las herramientas y los conocimientos adecuados para lograr realmente la creación de un software seguro desde el principio. Es más barato para la empresa (y más rápido en general) evitar que las vulnerabilidades comunes aparezcan en etapas posteriores del SDLC, una y otra vez. Aproveche sus puntos fuertes y ofrézcales un incentivo para que se involucren en la parte de seguridad de la organización. Realmente puede ser divertido, y ellos pueden ser los héroes justo a tiempo que necesitas para mantener a los malos fuera, y nuestros datos seguros.

Referencias:

  1. MITIGAR EL RIESGO DE LAS VULNERABILIDADES DEL SOFTWARE MEDIANTE LA APROBACIÓN DE UN FONDO DE SEGURIDAD (11 DE JUNIO DE 2019), Página 2.
  2. MITIGAR EL RIESGO DE LAS VULNERABILIDADES DEL SOFTWARE MEDIANTE LA APROBACIÓN DE UN FONDO DE SEGURIDAD (11 DE JUNIO DE 2019), Página 5.
  3. MITIGAR EL RIESGO DE LAS VULNERABILIDADES DEL SOFTWARE MEDIANTE LA APROBACIÓN DE UN FONDO DE SEGURIDAD (11 DE JUNIO DE 2019), Página 4.
Ver recurso
Ver recurso

Autor

Pieter Danhieux

Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

¿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

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

Publicado el 02 de diciembre de 2019
Por Pieter Danhieux

El 11 de junio de 2019, el Instituto Nacional de Normas y Tecnología(NIST) publicó un libro blanco actualizado, en el que se detallan varios planes de acción para reducir las vulnerabilidades del software y el riesgo cibernético. Bajo el título Mitigar el riesgo de las vulnerabilidades del software mediante la adopción de un marco de desarrollo de software seguro (SSDF), el NIST ofrece a las organizaciones unas directrices sólidas para evitar las desagradables -por no decir costosas- consecuencias de una violación de datos.

Es importante señalar que el SSDF es deliberadamente genérico, no supone que todas las organizaciones tengan exactamente los mismos objetivos de seguridad del software, ni prescribe un mecanismo exacto para alcanzarlos. El objetivo principal es aplicar las mejores prácticas de seguridad. Como afirma la autora, Donna Dodson: "Aunque el deseo es que cada productor de seguridad siga todas las prácticas aplicables, se espera que el grado de aplicación de cada práctica varíe en función de los supuestos de seguridad del productor. Las prácticas proporcionan flexibilidad a los ejecutores, pero también son claras para evitar que queden demasiado abiertas a la interpretación".

Por supuesto, me interesaron especialmente las inclusiones relacionadas con la formación en seguridad del software para los desarrolladores. Hace tiempo que sabemos que los desarrolladores necesitan una formación adecuada para defender a una organización desde el principio del proceso de desarrollo de software... pero ¿qué es lo adecuado, exactamente? Hay muchas opiniones divergentes. Sin embargo, creo que por fin se está empujando el sobre en una dirección que encenderá resultados positivos significativos.

Hay formación en seguridad... y hay formación en seguridad efectiva.

He hablado largo y tendido sobre la necesidad de que la formación en seguridad del software se aplique de forma más eficaz, se comprometa y se adapte a las necesidades del desarrollador. Incluso ahora, en muchas organizaciones, es un ejercicio de "marcar la casilla" en el mejor de los casos. Tal vez haya algunas horas de formación en vídeo, o incluso un tiempo precioso dedicado a las herramientas para algún aprendizaje basado en el aula. El hecho de que cada dos días se produzcan filtraciones de datos a gran escala, perpetradas por atacantes que explotan vulnerabilidades bien conocidas (y, por lo general, fácilmente corregibles), es una prueba de que la formación en seguridad del software no es ni de lejos todo lo eficaz que debería ser. Y, tal vez lo más importante, hay muy poco para verificar si la formación fue efectiva en absoluto: ¿se arreglan las vulnerabilidades más rápido? ¿se reducen las vulnerabilidades en el código? ¿la gente ha completado realmente la formación, o simplemente ha hecho clic en "siguiente" para completarla?

Los desarrolladores son personas ocupadas, que trabajan duro para cumplir con plazos estrictos. La seguridad es un inconveniente la mayor parte del tiempo, y rara vez están equipados con el conocimiento durante su educación para mitigar con éxito el riesgo cibernético. La palabra "seguridad" suele surgir cuando un miembro del equipo de AppSec señala defectos en su trabajo, lo que da lugar a 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 alarma de hace décadas que no estamos haciendo lo suficiente para ganarnos a los desarrolladores en materia de seguridad; no están motivados para asumir responsabilidades, ni buscan las herramientas que necesitan para crear software que sea funcional, pero hecho con las mejores prácticas de seguridad en mente.

Los desarrolladores son inteligentes, creativos y les encanta resolver problemas. Es muy poco probable que ver interminables vídeos sobre vulnerabilidades de seguridad les entusiasme o les ayude a seguir comprometidos. En mi tiempo como instructor de SANS, aprendí muy rápidamente que la mejor formación es la práctica, obligándoles a analizar y ser desafiados intelectualmente, utilizando ejemplos del mundo real que ponen a prueba su cerebro y se basan en el aprendizaje previo. La ludificación y la competición amistosa son también herramientas poderosas para que todos los participantes se comprometan con los nuevos conceptos, sin dejar de ser útiles y prácticos en su aplicación.

Las directrices del NIST especifican: "Proporcionar formación específica para cada función a todo el personal con responsabilidades que contribuyan al desarrollo seguro. Revise periódicamente la formación específica de cada función y actualícela según sea necesario". Y más adelante: "Definir las funciones y responsabilidades del personal de ciberseguridad, los campeones de seguridad, la alta dirección, los desarrolladores de software, los propietarios de los productos y otros involucrados en el SDLC".

Esta declaración, aunque no es específica sobre el tipo de formación, está ayudando a desplazar a las organizaciones hacia la izquierda y a mantener las mejores prácticas de seguridad en primera línea. Vuelve a poner en manos de la empresa la responsabilidad de encontrar soluciones de formación eficaces y más específicas, y es de esperar que esto dé lugar a que los desarrolladores se armen con las herramientas y los conocimientos adecuados para tener éxito.

La cultura: el eslabón perdido.

Aunque una organización dedique tiempo y recursos a la formación de los desarrolladores y otro personal clave, haciendo hincapié en su papel en la prevención de las vulnerabilidades y la reducción del riesgo de seguridad, el esfuerzo a menudo puede resultar inútil si la cultura de seguridad de una organización sigue estando fundamentalmente rota.

Cuando las personas reciben una formación eficaz, con objetivos establecidos y expectativas claras, les resulta mucho más fácil entender su lugar en el panorama de la seguridad y asumir la responsabilidad cuando corresponda. En el caso de los desarrolladores, especialmente, se les dan las herramientas y los conocimientos para escribir código seguro desde el principio. Sin embargo, la mejor manera de orquestar esto es en un entorno de seguridad positivo, donde hay menos doble manipulación, señalamientos y trabajo de proyecto 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 significará que los presupuestos son adecuados para desplegar una formación divertida y atractiva que utilice las vulnerabilidades del código del mundo real, y la aceptación de toda la organización para mantener el impulso. En este panorama digital en constante evolución, la formación debe ser tan continua como la entrega. Si le han dicho en el pasado que la formación en materia de cumplimiento de la normativa "una sola vez" o "lista y olvidada" es adecuada o eficaz, esto es una falacia.

Aunque este nuevo marco del NIST no articula específicamente el requisito de alimentar una cultura de seguridad positiva, adherirse con éxito a sus directrices requerirá sin duda una. No obstante, 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 ser útil considerar 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?
  • ¿Todo el mundo tiene claro el papel que desempeña en su consecución?
  • ¿La formación es frecuente y se evalúa?
  • ¿Son sus desarrolladores conscientes del enorme papel que pueden desempeñar en la eliminación de errores de seguridad comunes antes de que se produzcan?

Ahora bien, esta última parte depende, como he dicho, en gran medida de la organización y de la formación que elija. Debe ser pertinente, frecuente y atractiva. Hay que encontrar una solución que pueda aplicarse a su trabajo diario y construir contextualmente sus conocimientos.

¿Y ahora qué?

Es probable que una inmersión en estas nuevas directrices sea bastante abrumadora; realmente se necesita un pueblo para crear, verificar y desplegar el software seguro de hierro que la mayoría de las empresas necesitan, de la manera más segura posible. Tampoco se trata sólo de la formación. Hay que tener en cuenta las directrices cuando se utiliza software de terceros( después de todo, eluso de componentes con vulnerabilidades conocidas sigue estando en el Top 10 de OWASP), sugerencias en torno a 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, cadenas de herramientas adecuadas y todo lo demás. En el modelo BSIMM del Dr. Gary McGraw, al que se hace referencia en todo el documento del NIST, se pueden encontrar ideas útiles para todo el panorama.

Sin embargo, la victoria más rápida se puede lograr si sus desarrolladores cuentan con las herramientas y los conocimientos adecuados para lograr realmente la creación de un software seguro desde el principio. Es más barato para la empresa (y más rápido en general) evitar que las vulnerabilidades comunes aparezcan en etapas posteriores del SDLC, una y otra vez. Aproveche sus puntos fuertes y ofrézcales un incentivo para que se involucren en la parte de seguridad de la organización. Realmente puede ser divertido, y ellos pueden ser los héroes justo a tiempo que necesitas para mantener a los malos fuera, y nuestros datos seguros.

Referencias:

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

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.