En un mundo digitalizado, el riesgo de robo de datos es cada vez mayor. Dado que las grandes organizaciones actúan como guardianes de nuestra valiosa información, muchas reconocen la necesidad de aplicar estrictas normas de seguridad.

Gran parte de las iniciativas en torno al "giro a la izquierda", es decir, la introducción de la seguridad en una fase mucho más temprana del proceso de desarrollo, simplemente no mueven la aguja lo suficiente. Esto implica que seguimos comenzando el proceso de forma incorrecta y que, en última instancia, retrocedemos para lograr el resultado de un software más seguro. Debemos empezar por la izquierda, promulgando un cambio cultural que involucre positivamente a los equipos de desarrollo y los arme con los conocimientos de los que actualmente carecen. Sin embargo, no todas las formaciones y herramientas son iguales.

En este artículo, exploramos las formas en que los líderes clave, como los responsables de seguridad y desarrollo, pueden empoderar realmente a su cohorte de desarrolladores, transformándolos en la primera línea defensiva contra los costosos ciberataques.

Desplazamiento a la izquierda vs. inicio a la izquierda: Una distinción importante.

En la era de las frecuentes filtraciones de datos que afectan a algunas de las organizaciones más fiables del mundo, los líderes de las empresas han recurrido al sector de la seguridad para que les oriente sobre cómo evitar el desastre financiero, de reputación y de espectáculo que supone un ataque con éxito.

Durante bastante tiempo, los especialistas en seguridad de aplicaciones (entre los que me incluyo) han aconsejado que debemos "cambiar a la izquierda". En consonancia con las mejores prácticas de DevOps, así como con los mejores resultados de la seguridad del software, muchos de nosotros aconsejamos que la parte de seguridad de una construcción de software debe venir antes en el ciclo de vida de desarrollo de software (SDLC). No debería ser el último y costoso paso, sino que debería acercarse más al inicio del proceso, con la participación de los equipos de seguridad de las aplicaciones en las primeras fases de los proyectos de software.

No es un mal consejo, y ciertamente es mejor que la antigua forma de hacer las cosas (que, si la cantidad de datos robados y la antigüedad de las vulnerabilidades utilizadas para robarlos son una indicación, no está funcionando de todos modos). Sin embargo, si empezáramos realmente por la izquierda, los resultados en materia de seguridad serían mucho más positivos.

Desplazamiento a la izquierda, inicio a la izquierda... ¿cuál es la diferencia? La diferencia radica en la forma de involucrar a su equipo de desarrollo. Verdaderamente, ellos son la clave para entregar un software más seguro, mucho más barato de lo que pueden gestionar las cadenas de herramientas de ciclo posterior y la revisión manual del código. En un mundo ideal, todos los desarrolladores que escriben software tendrían los conocimientos y las herramientas para codificar de forma segura desde el principio. Detectarían los posibles fallos y los mitigarían antes de que se comprometan (y, por tanto, sean mucho más caros de eliminar y arreglar). Se reducirían drásticamente los fallos de seguridad que hemos visto durante décadas y que siguen siendo los responsables de que los atacantes entren por la puerta de atrás. Se cerrarían esas ventanas de oportunidad en forma de inyección SQL, cross-site scripting y autenticación rota.

Sin embargo, en este momento, simplemente no hay suficiente énfasis en la seguridad a nivel profesional, y la formación en codificación segura en el trabajo varía mucho. Como resultado, los desarrolladores rara vez tienen lo que necesitan para que una organización comience a salir. Ha llegado el momento de que quienes ocupan puestos de liderazgo colaboren y aboguen por una mayor concienciación en materia de seguridad, ya que su conocimiento y contacto directo con los desarrolladores es vital para impulsar programas que funcionen. Al fin y al cabo, los responsables de desarrollo estuvieron una vez en su puesto, sobre las herramientas y con el espacio de seguridad difícil de navegar en el mejor de los casos.

Los desarrolladores no adoran la seguridad (todavía)... pero usted puede cambiar la conversación.

Ya sabes lo que pasa: si mencionas la palabra "seguridad" a un desarrollador típico, lo más probable es que se te mire con cara de asombro, en el mejor de los casos, o con perplejidad, en el peor. Por lo general, todo el tema de la seguridad se ve como un problema de otros.

Un desarrollador tiene la responsabilidad principal de construir un software que sea funcional, rebosante de características innovadoras y que se entregue dentro de un apretado calendario de proyectos. La seguridad no suele ser una prioridad a nivel de codificación, e incluso puede considerarse un tedioso obstáculo para la entrega rápida y la creatividad. El departamento de seguridad de las aplicaciones tiene la tarea de comprobar meticulosamente el código, realizar pruebas de penetración y, a continuación, informar de las malas noticias: la presencia de vulnerabilidades de seguridad en un código que, a menudo, ya está comprometido y que, por lo demás, funciona bastante bien. Se trata de un proceso costoso en un entorno que a menudo tiene pocos recursos y tiempo, y cuya configuración está destinada a provocar una ruptura entre dos equipos que, en última instancia, tienen el mismo objetivo, pero que hablan idiomas completamente diferentes.

Ahora, en este clima, es probable que la recepción de la formación obligatoria en seguridad sea bastante fría. Pero el poder de encender una mentalidad de seguridad en cada desarrollador no es una quimera. Con la formación y el apoyo adecuados, pueden empezar a incorporar la seguridad a su software y asumir la responsabilidad de los resultados de seguridad que pueden controlar. Si los propios desarrolladores pueden ocuparse de los errores comunes, eso libera a los costosos especialistas para que solucionen los problemas verdaderamente complejos. Y si usted está en la posición de dirigir un equipo de desarrollo, puede ser fundamental para ayudar a cerrar esta brecha y ayudar a su equipo a ver los beneficios.

No toda la formación es igual.

¿Cuándo fue la última vez que se entusiasmó por aprender algo nuevo? Cuando lo hiciste, probablemente no te vinieron a la cabeza palabras como "obligatorio", "cumplimiento" o "diecisiete horas de vídeo".

Los desarrolladores no son diferentes. Son inteligentes, creativos y les encanta resolver problemas. Es bastante improbable que ver interminables vídeos sobre vulnerabilidades de seguridad vaya a engancharles, que el contenido sea memorable o que acabe siendo específico para sus funciones y responsabilidades diarias. En mi tiempo como instructor de SANS, se hizo evidente muy pronto que la mejor formación es la práctica, obligando a los participantes a analizar y a 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 todo el mundo asuma los nuevos conceptos, sin dejar de ser útiles y prácticos en su aplicación.

Otro factor que asusta es que gran parte de la formación en seguridad no está supervisada. A nadie le gusta tener la sensación de que el Gran Hermano está mirando, pero ¿de qué sirve gastar tiempo, dinero y esfuerzo en la formación si nadie comprueba si es pertinente?

La solución adecuada puede hacer que la codificación segura sea divertida, relevante, atractiva y medible. Desafíe a sus desarrolladores, trátelos bien y conviértalo en un evento especial. La formación gamificada enciende los centros de recompensa del cerebro y ofrece un incentivo para seguir aprendiendo, superar los límites del conocimiento y, sencillamente, construir un software de mayor calidad.

Chequeo de la cultura de seguridad:¿Estála suya consoportevital?

Crear un software seguro en un entorno con una cultura de seguridad deficiente es como intentar ganar una maratón con una roca encadenada al tobillo: prácticamente imposible, e innecesariamente difícil.

La formación gamificada, el cara a cara en tournaments y el compromiso de ayudar a los desarrolladores en su crecimiento en materia de seguridad ayudan enormemente a impulsar una cultura de seguridad positiva, ya que los equipos de seguridad de las aplicaciones y los equipos de desarrollo adquieren mucha más información sobre el trabajo diario del otro. Las relaciones crecen y prosperan, y el (a menudo limitado) presupuesto de seguridad no se agota en arreglar un "Día de la Marmota" con los mismos pequeños y molestos errores una y otra vez.

También hay otro poderoso subproducto: el descubrimiento de los campeones de la seguridad que no sabías que tenías. Una formación adecuada que involucre a todo el mundo, al tiempo que permite una exhaustiva assessment, puede descubrir a aquellos que no sólo tienen una aptitud para la seguridad, sino que muestran activamente una pasión por ella. Estos campeones son vitales para mantener el impulso y actuar como punto de contacto entre los equipos, supervisar a los compañeros y mantener las políticas de mejores prácticas. Poner en marcha un sólido programa de campeones, que incluya el reconocimiento y el apoyo de los directivos, es un orgullo para la organización, además de quedar muy bien en el currículum de la persona y reforzar su futura carrera.

Cuando uno se compromete con una cultura de seguridad positiva, la responsabilidad es compartida y se puede alcanzar un mayor nivel de excelencia en el software seguro. En última instancia, cada persona del ciclo de vida del desarrollo de software debe adherirse a un sencillo mantra: si no es un software seguro, no es un buen software.

Corre la voz.

Las mejores prácticas de ciberseguridad han sido un tema candente durante más de una década, debatido con frecuencia a nivel gubernamental en la mayoría de las regiones de todo el mundo. Los ciberataques son esencialmente una realidad diaria, y cualquier entidad que almacene datos privados valiosos en línea es un objetivo potencial. Sólo en Alemania, el Ministerio Federal de Educación e Investigación estima que el 96% de todas las pequeñas y medianas empresas han sufrido ya un incidente de seguridad informática. El mismo informe subraya la necesidad urgente de investigación, legislación y concienciación en materia de ciberseguridad, con un llamamiento definitivo a la inclusión de una formación más sólida en materia de seguridad en los campos de la informática y las tecnologías de la información.

Con la llegada del GDPR, así como una estrategia revisada tras un ataque de varias etapas que expuso los datos sensibles de muchas figuras públicas -así como los servidores del gobierno federal alemán-, está claro que la concienciación y la acción en materia de ciberseguridad son prioritarias para los líderes de la región DACH. El hackeo de finales de 2018 fue ejecutado por un estudiante de 20 años de edad con una habilidad relativamente baja, y su principal punto de acceso a información altamente sensible fue posible mediante la simple adivinación de contraseñas. Aunque se trató de un exploit de autenticación extremadamente preocupante, puso de manifiesto la necesidad de una concienciación de seguridad mucho mayor a nivel gubernamental, empresarial y social. Un informe de 2019 destacó que Alemania se estaba quedando atrás en términos de iniciativas de defensa de la ciberseguridad, confiando en la legislación como táctica principal. Sin embargo, con la llegada de DevSecOps como metodología de desarrollo ideal, muchas empresas han reconocido la necesidad de formación práctica, creación de software seguro por diseño y programas de concienciación de seguridad en toda la empresa.

El latido de la seguridad del software en DACH

Organizaciones como OWASP y MITRE publican clasificaciones con datos verificados de las vulnerabilidades más frecuentes. En todos los lenguajes, la inyección SQL ocupa el primer lugar y, a pesar de tener décadas de antigüedad, es un fallo común y a menudo explotado con consecuencias desastrosas.

El software bancario suizo BPC, SmartVista, fue alertado de una vulnerabilidad SQLi por SwissCERT, sin embargo, permaneció sin parchear durante meses a pesar de su potencial para exponer datos sensibles de los clientes, incluyendo números de tarjetas de crédito. La inyección de SQL puede conducir, y de hecho lo hace, a peligrosas infracciones, como la que se produjo en 2017 en múltiples departamentos gubernamentales y universidades de Estados Unidos y Reino Unido. Muchos de estos incidentes son causados por procesos de validación de entrada poco rigurosos, lo que permite a un atacante insertar código malicioso desde el front-end de una aplicación. Otra fuente común de vulnerabilidad es el uso de código de proveedor inseguro que no se revisa para detectar fallos de seguridad, y así se introducen los defectos en un entorno de producción previamente escaneado y autorizado. Ninguno de estos puntos de acceso es específico de la región DACH, sino que son ejemplos globales de malas prácticas de seguridad que no pueden continuar a medida que el mundo produce más código.

Es imperativo parchear los problemas tan pronto como se descubran, y la decisión de SmartVista de dar largas al asunto podría haber sido un desastre. Aunque DACH ha tenido su cuota de infracciones, unas directrices y un apoyo más centrados en la concienciación y la formación en materia de seguridad podrían evitar que los posibles problemas a nivel organizativo se les fueran de las manos, y esto requerirá una legislación mucho más específica a la hora de impulsar una formación evaluada para los desarrolladores.

No toda la formación en código seguro es igual.

Muchas directivas de ciberseguridad de todo el mundo son cada vez más completas, pero siguen siendo poco específicas a la hora de definir una formación eficaz en materia de seguridad. La directiva NIS de la UE incluye el requisito de "concienciación, formación y educación" a nivel nacional, pero precipitarse en una solución de formación puede no tener el resultado deseado de una reducción tangible del riesgo si carece de elementos clave que impulsen a los desarrolladores de competencias y el cambio organizativo.

Las soluciones educativas varían, y la formación debe ser específica para el trabajo diario del desarrollador (incluyendo la capacidad de aprender en su lenguaje y marco preferidos), así como seguir siendo atractiva y medible a lo largo del tiempo.

Las soluciones de formación estática, como la formación en vídeo por ordenador, suelen ser demasiado genéricas y rara vez se revisan o se evalúan en función de su éxito a la hora de impulsar la concienciación y la habilidad para evitar que las vulnerabilidades entren en el código mientras se escribe. La formación dinámica, sin embargo, es vital para mejorar las habilidades de los desarrolladores con ejemplos contextuales, además de proporcionar métricas que influyen en los procesos de mitigación del negocio. Se actualiza con frecuencia, promueve un alto nivel de retención de conocimientos y forma parte de la creación de desarrolladores conscientes de la seguridad que contribuyen a una cultura de seguridad positiva en su lugar de trabajo.

Secure Code Warrior datos de los pilotos de DACH:

Secure Code Warrior Ema Rimeike, Directora de Ventas (MSc in Cyber Security) ha estado trabajando estrechamente con organizaciones en la región DACH, llevando a cabo programas piloto para desarrolladores para medir la competencia interna de codificación segura entre los desarrolladores, su compromiso con las mejores prácticas de seguridad, así como la cultura general de seguridad de la empresa. Utilizando una formación en código seguro dinámica y gamificada, sus principales conclusiones revelan un futuro brillante cuando los desarrolladores reciben los conocimientos y las herramientas que fomentan la reducción de la vulnerabilidad con éxito desde el inicio del SDLC.

Durante sus programas piloto, recopiló estadísticas basadas en una media de 90 minutos invertidos por usuario en la plataforma Secure Code Warrior (SCW), en la que jugaron a 15 retos de codificación segura(lecciones de tamaño reducido, gamificadas y a su propio ritmo):

Los usuarios emplearon una media de 5,5 minutos en completar un reto, frente a los 3 minutos de media de otros pilotos globales de SCW.

• Precisión frente a confianza: Los pilotos de DACH registraron un porcentaje medio de entre el 88 y el 92% de confianza en sus respuestas a los retos, pero la precisión de estas respuestas se situó entre el 53 y el 66%
• Más del 75% de los participantes encuestados prefieren los métodos de formación gamificados -o dinámicos-, en contraste con los enfoques estáticos como la formación basada en ordenador (CBT).
• Entre las vulnerabilidades más frecuentes, observamos fallos de inyección, errores de configuración de la seguridad, secuencias de comandos en sitios cruzados (XSS), uso inadecuado de la plataforma, control de acceso, autenticación, corrupción de la memoria, falsificación de solicitudes en sitios cruzados, protección insuficiente de la capa de transporte y redireccionamientos y reenvíos no validados.

No es ningún secreto que, en general, muchos en la región DACH valoran una fuerte ética de trabajo y el enfoque en la precisión, y los desarrolladores que prueban el programa piloto no son una excepción. Estos datos hablan de su desconocimiento de este tipo de entrenamiento, pero también del deseo de seguir jugando, de mejorar su puntuación y de evitar el uso de la función de "pista" disponible. Su deseo de aprender y mejorar es evidente, pero también muestra que hay que trabajar más para implantar una formación y concienciación eficaces dentro de la propia organización.

Una buena formación que reduzca el riesgo y frustre las vulnerabilidades no es un ejercicio puntual, y es algo más que el cumplimiento. Los directivos y el personal de AppSec deben esforzarse por poner en marcha un programa de concienciación en materia de seguridad con una estrategia y un apoyo que reflejen los objetivos principales de seguridad y traten de mantenerlos a largo plazo. Esta es, en efecto, la columna vertebral de un proceso DevSecOps exitoso con desarrolladores conscientes de la seguridad.

¿Qué revela un programa piloto a una organización?

Los programas piloto deSecure Code Warrior son una herramienta increíblemente valiosa para ofrecer a las empresas una instantánea de su estado actual de seguridad (normalmente entre el 65 y el 75 %), así como de las áreas de mejora inmediata. Revelan:

• Claridad en cuanto a las vulnerabilidades que deben abordarse de forma prioritaria, así como si esta dirección debe aplicarse a un equipo, una unidad de negocio o un lenguaje de programación concretos
• Un alcance preciso y más amplio de la inteligencia sobre los factores de riesgo de ciberseguridad dentro de su SDLC, abarcando el factor humano del desarrollo de software.
• Al aprovechar la plataforma SCW, las organizaciones podrían predecir el resultado potencial de las pruebas de penetración y tener la oportunidad de mitigar esos riesgos por adelantado, preparando a los equipos incluso antes de que se les asigne un proyecto específico.

En las organizaciones que han empezado a poner en marcha programas de seguridad completos y eficaces, normalmente se aprueban de 1 a 1,5 horas semanales de desarrollo profesional a nivel de dirección, para ayudar a sus desarrolladores a actualizar sus conocimientos de codificación segura. Sin embargo, estamos observando que las organizaciones están dejando de centrarse en el "tiempo dedicado a la plataforma" para centrarse en "qué equipos de desarrollo de software suponen el mayor y el menor riesgo para la empresa". Esto está estrechamente vinculado a la certificación formalizada/el cinturón, el descubrimiento de campeones de seguridad y los programas de tutoría para obtener los mejores resultados. La asignación de tiempo, además de la constructiva y positiva assessment es absolutamente clave para crear desarrolladores conscientes de la seguridad que no sólo les guste la seguridad, sino que reduzcan de forma medible el riesgo para la empresa.

¿Cómo utilizan ya las organizaciones Secure Code Warrior?

Varias empresas ya están utilizando Secure Code Warrior para concienciar, desarrollar las habilidades de los desarrolladores y ampliar una cultura de seguridad positiva.

Por ejemplo, en un caso de uso, un equipo de formación en la plataforma utilizó el SCW para revelar sus puntos fuertes y débiles en materia de seguridad:  

Acción de los desarrolladores: Los desarrolladores pudieron ver sus propios resultados, mostrando las áreas en las que debían centrarse y capacitarse para autodirigirse, y seguir el ritmo de la formación para mitigar vulnerabilidades específicas o lagunas de conocimiento que les ayudarán en futuras construcciones de software.

Acción de gestión: Analizaron los puntos fuertes y débiles generales a nivel de equipo, y pudieron prescribir un enfoque gamificado que aborda las áreas específicas de preocupación. Esto creó una vía educativa bidireccional que construye conocimientos relevantes rápidamente.

Resultado: Una vez que se realiza el pentesting a nivel de equipo, cualquier vulnerabilidad es visible, y la comparación de los resultados anteriores facilitó la validación de si la formación había sido eficaz para reducir los errores de seguridad más comunes.

Esto nos lleva de nuevo a las etapas iniciales del desarrollo de software, en las que los objetivos del equipo de formación previa de mejora continua y la introducción de las mejores prácticas de seguridad al principio pueden ser eficaces, fáciles de desplegar y ahorrar tiempo en todo el ámbito del desarrollo.

Equipos de proyectos DevSecOps

En un entorno ideal de DevSecOps, varias unidades de negocio están representadas en un equipo de proyecto para decidir y ofrecer resultados básicos, uno de los cuales son las mejores prácticas de seguridad.

En cuanto a la investigación y planificación previas al proyecto, la plataforma SCW puede evaluar las habilidades de seguridad del equipo de desarrollo propuesto antes de que comience a trabajar, prediciendo los posibles resultados de las pruebas de pentesting y los retrasos relacionados con la seguridad en el SDLC con tiempo más que suficiente para prepararse adecuadamente para ellos. Se puede crear una formación específica para el código y la estructura del proyecto para que el equipo trabaje, incluyendo un proceso de assessment/certificación que verifique las habilidades generales de concienciación sobre la seguridad, requiriendo una nota de aprobación preestablecida antes de que se les deje libres en los entregables del proyecto.

Esto ofrece un enfoque de inmenso valor empresarial para reducir el coste de la corrección de vulnerabilidades, mitigar los riesgos de seguridad, ahorrar tiempo en las pruebas de pentesting, reducir el coste de los costosos programas de recompensas y mejorar la capacitación de la cohorte de desarrollo de forma centralizada, sostenible, escalable y unificada.

Conclusión:

Existe una mayor presión sobre las empresas para que den prioridad a la seguridad, mantengan nuestros datos a salvo y cumplan con una normativa cada vez más estricta a nivel mundial, pero especialmente para las organizaciones que comercian en la UE bajo las estrictas directrices del GDPR.

Para las empresas de la región DACH, está claro que están haciendo vías de seguridad viables al conectar el esfuerzo y los resultados de la formación con las actividades del mundo real relacionadas con la prevención de riesgos, incluida la reducción de vulnerabilidades comunes en el código que producen.

Para construir un caso empresarial verdaderamente cuantificable para aumentar los presupuestos de seguridad, la concienciación y el cumplimiento general, la formación debe ser atractiva para los desarrolladores, consistente, adaptable y medible. El seguimiento de las etapas actuales de la capacidad para adaptar la formación adecuada, el descubrimiento de los campeones de la seguridad y la medición del rendimiento del equipo a lo largo del tiempo son iniciativas vitales, y muchas empresas con visión de futuro en toda la región de Dach se están dando cuenta de los beneficios después de un piloto completo de SCW.

Muchas empresas luchan con métricas de rendimiento de seguridad que son demasiado genéricas. Con un uso consistente y a largo plazo de la plataforma SCW, las empresas podrían utilizar evaluaciones de precisión, courses, y métricas de gestión para descubrir:

• Reducción de las vulnerabilidades a lo largo del tiempo
• Reducción de los costes para solucionar las vulnerabilidades a lo largo del tiempo
• Desarrollo de habilidades individuales y de equipo a lo largo del tiempo
• Reducción de costes y tiempo en la fase de pentesting

¿Qué métricas sigue actualmente su organización, con qué frecuencia se vuelven a medir y han mostrado una notable mejora con el tiempo? ¿En qué medida están integradas sus iniciativas de formación en el flujo de trabajo de los desarrolladores?

El enfoque dinámico, lúdico e integral del SCW se considera una parte crucial del flujo de trabajo del ciclo de vida del desarrollo de software seguro. Las empresas están equipando a sus desarrolladores con las herramientas y la formación adecuadas, además de incorporar el SCW como parte de su flujo de trabajo del SSDLC.

Este artículo apareció originalmente en Information Security Buzzy fue recogido por otros medios. Se ha actualizado para su distribución aquí.

A finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos de la CWE que afectaron al mundo en 2019. Esta lista no se basa en una opinión, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como el NIST, así como los datos publicados de Common Vulnerabilities and Exposures (CVE). Para determinar los "principales" defectos, se atribuye una puntuación basada en su gravedad, capacidad de explotación y prevalencia en el software actual. No es el tipo de lista que va a ganar ningún elogio positivo, eso es seguro.

Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista han aparecido antes... una y otra vez. Si ésta fuera la lista de los Billboard Hot 100, sería como si Britney Spears'Baby One More Time y los Backstreet Boys'I Want It That Way aparecieran cada año desde su lanzamiento inicial. ¿Y por qué he elegido esas canciones? Pues porque tienen unos veinte años de antigüedad (¿te sientes ya antiguo?), al igual que algunos de esos peligrosos errores de software que siguen asolándonos en 2020 a pesar de haber sido descubiertos hace décadas.

¿Por qué siguen siendo tan peligrosos los viejos bichos? ¿No sabemos cómo solucionarlos?

El número seis de la lista actual del MITRE es el CWE-89, más conocido como inyección SQL (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos nuestras preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, sigue siendo una de las técnicas de hacking más utilizadas en 2019. El informe de Akamai Estado de Internet reveló que SQLi fue el culpable de dos tercios de todos los ataques a aplicaciones web.

En cuanto a la complejidad, la inyección SQL está lejos de ser un exploit de nivel genio. Es una solución sencilla para un desarrollador web, y sabemos sin ninguna duda cómo evitar que esta vulnerabilidad exponga datos valiosos a un atacante... el problema es que para muchos desarrolladores, incluso hoy en día, la seguridad no es una prioridad. Puede que esto fuera más fácil hace veinte años, pero con el enorme volumen de software que se está creando hoy y en el futuro, esto ya no puede seguir siendo la norma.

Los desarrolladores operan en un sistema roto (la mayor parte del tiempo).

Es demasiado fácil sentarse y culpar a los desarrolladores por entregar un código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. Al equipo de desarrollo medio se le pide que haga un software bonito y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad asegura que los equipos de desarrollo ya están sobrecargados, y la seguridad no es una consideración primordial; después de todo, ¿no es por eso que existen los especialistas en seguridad de aplicaciones? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad: sólo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su duro trabajo.

En el otro lado de la valla, los especialistas en seguridad de aplicaciones están hartos de arreglar errores de hace décadas que siguen apareciendo en cada análisis y revisión manual del código. Estos especialistas son caros y escasos, y su tiempo está mucho mejor invertido en fallos de seguridad complejos en lugar de aplastar errores conocidos una y otra vez.

Existe una cultura tácita de señalamiento entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: un software seguro. Los desarrolladores operan en un entorno que rara vez les da la mejor oportunidad de éxito en términos de codificación segura; las mejores prácticas de seguridad rara vez se enseñan como parte de su educación terciaria, y la formación en el trabajo es a menudo demasiado infrecuente, o completamente ineficaz. Hay una clara falta de énfasis en la concienciación sobre la seguridad y en la educación en profundidad y relevante, y el resultado es el coste astronómico de arreglar viejos fallos en el código comprometido, además de la amenaza inminente de una violación de datos que acabe con la reputación.

El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen más seguros nuestros datos?"

Otro problema que aparece con frecuencia es que, en lugar de la formación, se pone un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software sea liberado en la naturaleza. El conjunto de herramientas de escaneo y protección de aplicaciones(SAST/DAST/RASP/IAST) puede ciertamente ayudar a la producción de software seguro, pero vienen con sus propios problemas. Depender completamente de ellas no garantiza la seguridad, porque:

• Ninguna herramienta puede buscar todas las vulnerabilidades, en todas las estructuras y en todos los casos de uso.
• Pueden ser lentos, especialmente cuando se ejecutan en tándem para proporcionar un análisis de código estático y dinámico
• Los falsos positivos siguen siendo un problema; a menudo detienen la producción y requieren una revisión manual innecesaria del código para dar sentido a las alertas
• Crean una falsa sensación de seguridad, ya que la codificación segura no tiene prioridad con la expectativa de que estas herramientas detecten cualquier problema.

Las herramientas ciertamente descubrirán fallos de seguridad que pueden ser parcheados, pero ¿encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante sólo necesita una puerta abierta para entrar y arruinarle el día.

Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que entra en juego en las vulnerabilidades del software. La mayoría de los desarrolladores no están adecuadamente formados para la codificación segura, y su conciencia general de seguridad es baja. Sin embargo, se encuentran al principio del ciclo de vida del desarrollo de software y están en una posición privilegiada para evitar que las vulnerabilidades lleguen al código comprometido. Si codificaran de forma segura desde el principio, serían la primera línea de defensa contra los devastadores ciberataques que nos cuestan miles de millones cada año.

Los desarrolladores deben tener la oportunidad de prosperar, con una formación que hable su idioma, que sea relevante para su trabajo y que los entusiasme activamente con la seguridad. Un código sin errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente genial te hará ganar el respeto de tus compañeros.

Un programa de seguridad moderno debe ser una prioridad empresarial.

Los equipos de desarrollo no pueden ponerse de pie por sí mismos y promulgar una conciencia de seguridad positiva en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad al proceso de desarrollo de software desde el principio.

Está claro que los viejos métodos de formación no funcionan si la lista de MITRE sigue mostrando tantos fallos de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:

• Práctica; a los desarrolladores les gusta "aprender haciendo", no viendo cabezas parlantes en vídeos
• Relevante; no les hagas entrenar en C# si están usando Java todos los días
• Atractivo; el aprendizaje por bocados es fácil de digerir y permite a los desarrolladores seguir ampliando sus conocimientos previos
• Medible; no se limita a marcar una casilla y seguir adelante. Garantizar la eficacia de la formación y crear vías de mejora
• Diversión; mira cómo puedes crear conciencia de seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un ambiente de equipo cohesivo.

La seguridad debería ser una prioridad para todos los miembros de la organización, y el CISO debería ser visible y transparente en los esfuerzos realizados en todos los niveles para mantener nuestros datos más seguros. ¿Quién quiere escuchar la misma canción de siempre? Es hora de tomarse en serio lo de aplastar los viejos fallos para siempre.

Cuando ves "crecimiento" en un contexto empresarial, casi siempre se relaciona con métricas, ingresos, financiación, número de empleados... todo eso en lo que no tenía que pensar hace una década.

Podría haber empezado este artículo con todos esos datos y cifras; son innegablemente impresionantes y la trayectoria de nuestra empresa en curso es sólida. Sin embargo, para mí, estos números no reflejan lo que más me enorgullece de 2019. La realidad es que hemos construido un equipo verdaderamente espectacular de personas que se preocupan mucho más allá de las meras métricas financieras. Hemos experimentado un "estirón", uno que ha dado forma al enorme corazón de esta empresa ahora y en el futuro.

Permítame demostrarlo, querido lector:

‍

Creamos el programa Warriors Give Back, una iniciativa benéfica global de todos los empleados que impulsó más de 10 eventos durante 12 meses en Sidney, Boston, Londres y Brujas:

• 50 Guerreros construyeron bicicletas con la organización Bikes for Tykes, entregándolas a niños desfavorecidos de Sidney
• 9 Guerreros de Boston se ofrecieron como voluntarios en la fábrica de donaciones de Cradles to Crayons, clasificando y empaquetando donaciones para los niños locales necesitados
• Los miembros del equipo apoyaron a las personas sin hogar, a la vez que experimentaron una pequeña porción de lo que es hacer las compras para las comidas de una semana, con sólo diez dólares en la mano y sin calefacción ni refrigeración
• En Brujas, los Warriors ayudaron a 100 niños con actividades de CyberSkool, como la construcción de robots, la piratería informática y la apertura de cerraduras.
• Los guerreros compraron artículos para las cestas de Navidad, así como juguetes para los niños necesitados con Wesley City Connect
• Nuestros Warriors, con sede en Londres, patrocinaron el equipamiento de una escuela primaria local y se unieron al equipo medioambiental de la escuela para limpiar sus campos de juego.
• Nos hemos asociado con TechLadies + the WING, proporcionando ayuda gratuita para el curriculum vitae y asesoramiento profesional individual.
• Como parte de nuestra celebración de fin de año, compramos regalos navideños para familias locales necesitadas, en colaboración con el programa ABCD Adopt a Family. Su servicio pone en contacto a familias necesitadas con personas, organizaciones sin ánimo de lucro y empresas que quieren ayudar a una familia durante las fiestas o a lo largo del año.

Y, con una de las peores temporadas de incendios forestales registradas en Australia, nos unimos para hacer una donación al Servicio de Bomberos Rurales y a WIRES justo antes de que el año llegara a su fin. Es una crisis continua en la que nada parece suficiente, pero me conmovió la empatía mostrada por todo nuestro equipo mundial.

Estos eventos de Warriors Give Back nos recuerdan con regularidad que la vida es algo más que métricas, y que todos estamos más cimentados por hacer el esfuerzo de caminar en los zapatos de otros menos afortunados. La humanidad y la humildad son fundamentales para mantener una cultura positiva, y nuestro equipo la defiende en cada oportunidad.

¿Sigues aquí por los números?

En cuanto a nuestro producto, hemos creado 1727 nuevos retos de codificación segura en 2019, a través de diez nuevos marcos de lenguaje. Se trata de un logro gigantesco para nuestro equipo de ingeniería, que produce una media de 144 nuevos retos al mes, más que cualquier año anterior hasta la fecha. En cuanto a nuestros usuarios, también surgieron algunas cifras interesantes:

• El lenguaje/marco más popular fue Java: Spring, con 455.973 retos de codificación segura completados
• El pseudocódigo fue una superestrella inesperada, con 295.763 desafíos jugados
• La categoría de vulnerabilidad más popular es la de fallos de inyección, lo cual no es una sorpresa. Es la número uno en el Top 10 de OWASP, y la número uno para nosotros.

Nuestra gente en números.

Cuando puse en marcha esta empresa, dejé muy claro que la diversidad iba a ser fundamental para nuestro éxito futuro. No quiero estar atrapado en una cámara de eco de gente como yo; la diferencia de opinión, cultura, género, dietas y raza es parte de la magia en una startup global. A partir de ahora, nuestro equipo representa:

• 17 nacionalidades diferentes
• 53% de hombres, 47% de mujeres
• Al menos 9 requisitos dietéticos diferentes (ha habido ocasiones en las que lo único que podíamos comer con seguridad eran palomitas)
• Múltiples confesiones en cada lugar del mundo.

Estoy inmensamente orgulloso de nuestro vibrante equipo, y eso se nota en todo lo que hacemos.

Ah, y sí, hemos aumentado los ingresos en más de un 100%, hemos completado nuestra ronda de financiación de serie B (que representa la mayor inversión de la historia en EE.UU. en una empresa australiana de ciberseguridad), hemos ampliado rápidamente nuestro equipo a 120 personas y hemos abierto nuevas oficinas en Portland y Singapur.

Es nuestro quinto cumpleaños, y aunque la empresa tiene la misma edad que mi hija, las similitudes entre sus trayectorias han terminado. Por suerte, aún me quedan algunos años para verla convertirse en una adulta feliz y sana. En el caso de los niños, estos años pasan en un abrir y cerrar de ojos, pero Secure Code Warrior ya no es el niño descarado. Más rápido de lo que podría haber imaginado hace cinco años, hemos tenido que alcanzar la mayoría de edad y mudarnos por nuestra cuenta. Estamos preparados para recorrer el camino del hipercrecimiento que tenemos por delante, pero todavía me estoy acostumbrando a la idea de que el adulto que manda soy yo.

Este artículo fue publicado originalmente en DevOps.com. Ha sido actualizado y modificado.

Al igual que "blockchain", "big data" y "disrupción digital", el término "DevOps" es otra de las palabras de moda que se lanzan actualmente en los departamentos de TI de las grandes organizaciones.

Muchos han identificado (correctamente) la necesidad de ciclos de vida de desarrollo de software más rápidos; un proceso más preciso que esté estrechamente alineado con los objetivos de negocio, permitiendo un flujo de trabajo más claro y la colaboración entre los equipos de desarrollo y de operaciones. DevOps es esencialmente el desarrollo "ágil", todo crecido y listo para asumir las necesidades de innovación constante y despliegue rápido de la empresa moderna. Para los profesionales de la seguridad, es una iniciativa fantástica: podemos inyectar la seguridad en el proceso mucho antes, reduciendo el coste de la corrección de errores y evitando posibles catástrofes en el futuro.

El problema es que pocas empresas tienen verdadero éxito en su implementación de DevOps. Sin el apoyo, el fomento y la comprensión adecuados en toda la empresa, puede convertirse rápidamente en un elefante blanco... ya sabes, uno de esos proyectos "no menciones la guerra".

Entonces, ¿cuál es el problema? Es un debate interesante, y hay algunas maneras de enfocar DevOps que creo que harán que la navegación sea mucho más suave. Un programa eficaz va más allá de unas cuantas herramientas nuevas y elegantes, títulos y reuniones de equipo. No siempre va a ser fácil, pero tomarse el tiempo para arreglar una estrategia rota (o implementarla de la manera correcta al principio) va a ser mucho menos doloroso a largo plazo. Y, en última instancia, va a dar lugar a un software de mayor calidad y más seguro.

Vamos a desglosarlo:

Suelta las amarras del delantal "Ágil".

Existe la idea errónea de que una organización debe elegir entre Agile o DevOps, y emprender un camino u otro para no volver a mirar atrás.

La cuestión es que el proceso de desarrollo funciona mejor cuando ambos se consideran e implementan como uno solo. DevOps no es una reinvención del desarrollo ágil, sino una extensión del mismo. Las ruedas tienden a caerse cuando se espera que el proceso sea exactamente como Agile, o completamente diferente de Agile.

Agile apoya el principio de los equipos interfuncionales, reuniendo a diseñadores, probadores y desarrolladores desde el principio y comprometiéndose a mantener líneas de comunicación abiertas a lo largo de un proyecto. Su objetivo es acabar con la entrega en silos y reducir la doble manipulación, ventajas ambas del proceso DevOps también. Sin embargo, DevOps va un paso más allá, introduciendo sistemas, seguridad y operaciones en la mezcla para ofrecer un sólido conjunto de habilidades de extremo a extremo que tiene como objetivo final la entrega de software completo y funcional al cliente.

Durante los inevitables puntos de dolor al pasar a un proceso más centrado en DevOps, el riesgo de desarrollo en silos puede surgir de nuevo. A menudo se puede tener al equipo original de Agile trabajando juntos, con las adiciones de seguridad y operaciones todavía encontrando su camino en la máquina; nadie está muy seguro de cómo incluirlos, lo que deberían estar haciendo y sus objetivos generales.

DevOps no funciona sin unos objetivos claramente definidos, una incorporación interfuncional y una comunicación directa con todas las partes. Habrá un período de ajuste que requerirá una gestión cuidadosa del cambio, sin duda, pero conseguir que todos estén de acuerdo con las mejoras que aportará la funcionalidad de DevOps es la mitad de la batalla.

Cada vez más (gracias a Dios), DevOps está poniendo énfasis en las mejores prácticas de seguridad como parte del proceso también, desmitificando ese paso y cerrando la brecha entre el equipo de seguridad y, bueno, todos los demás. Como he dicho antes, todavía tenemos un largo camino que recorrer para capacitar a los desarrolladores para codificar de forma segura desde el principio, pero la implementación exitosa de las metodologías DevOps es una excelente base sobre la que se pueden construir habilidades de seguridad dentro del equipo de desarrollo.

La automatización no lo es todo (y no es lo más seguro).

Otra característica de la metodología DevOps es, hasta cierto punto, la automatización del proceso de desarrollo de software. Los principios de integración continua y entrega continua (CI/CD) son las piedras angulares de este concepto y, como probablemente se puede adivinar, dependen mucho de las herramientas.

Las herramientas son increíbles, realmente lo son. Pueden aportar una velocidad sin precedentes al proceso de entrega de software, gestionando el repositorio de código, las pruebas, el mantenimiento y los elementos de almacenamiento con una facilidad relativamente perfecta.

Sin embargo, aunque los robots podrían quitarnos todos los puestos de trabajo y encarcelarnos algún día, definitivamente aún no han llegado. La gran dependencia de las herramientas y la automatización deja una ventana abierta a los errores. Es posible que los análisis y las pruebas no lo detecten todo, que el código quede sin revisar y que eso plantee enormes problemas de calidad (por no hablar de seguridad) en el futuro. Un atacante sólo necesita una puerta trasera que explotar para robar datos, y renunciar al elemento humano en el control de calidad y seguridad puede tener consecuencias desastrosas.

El "término medio" es asegurarse de tener un equilibrio entre personas y herramientas. Las herramientas deben servir de ayudantes de un equipo en el que confíes para cumplir los objetivos del proyecto. Deberían:

• Asignar el tiempo suficiente para que el personal se familiarice con la cadena de herramientas DevOps elegida
• Centrarse en la colaboración eficaz (y en cómo las herramientas pueden apoyarla)
• Abordar cualquier carencia en el proceso, ya sea de habilidades/conocimientos o de herramientas.

En resumen, no te limites a "ponerte las pilas" y esperar lo mejor.

DevOps no es una palabra de moda, es una cultura. Estás haciendo crecer la tuya?

La gestión del cambio es difícil en el mejor de los casos. El miedo a lo desconocido puede impedir que incluso los miembros más brillantes del equipo hagan crecer sus habilidades y amplíen sus horizontes.

Verás, decir simplemente "vamos a hacer DevOps" y hacer que el equipo de operaciones cambie de mesa no va a implementar mágicamente un proceso exitoso. Muchos se sentirán confundidos, y los miembros del equipo que llevan mucho tiempo en él se sentirán descontentos. La comunicación de las expectativas es crucial, al igual que "andar el camino". DevOps representa un movimiento cultural tanto como una metodología de desarrollo, y un equipo debe vivir y respirar una mentalidad interfuncional y colaborativa.

¿Cómo es una gran cultura DevOps?

• Los individuos están capacitados para aportar su experiencia a un proceso, no sólo los líderes
• Comunicación abierta, honesta y respetuosa entre los equipos
• Cada persona asume la responsabilidad del objetivo general de incorporar la calidad y la seguridad en el proceso de desarrollo
• Todo el mundo está en la misma página con la definición de DevOps en la empresa, la hoja de ruta y el cómo/qué/por qué del papel de cada persona.

Durante años he hecho hincapié en la importancia de crear culturas de seguridad positivas en los equipos de desarrollo, y DevOps no es diferente.

Las herramientas, los conocimientos y el apoyo adecuados son imprescindibles para lograr las mejores prácticas de seguridad, ver un descenso en las vulnerabilidades descubiertas y abrir los ojos del equipo a la importancia de proteger nuestros datos. Con DevOps, hay que sentar las bases culturales para un cambio positivo: asegurarse de que todo el mundo entiende su papel, su valor y sus expectativas, los objetivos generales del proyecto y los pasos del proceso.

¿Lo dominas? Muy bien. Ahora, cambiemos la aguja, marquemos el aspecto de la seguridad y hagamos de DevSecOps el plan definitivo para la excelencia del software.

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.

A principios de este mes, tuve la oportunidad de asistir al OWASP AppSec Day 2019 en la hermosa Melbourne. Estos eventos centrados en los desarrolladores están entre mis favoritos del calendario; proporcionan un humilde recordatorio de la comunidad que trabaja incansablemente para educar y empoderar a los ingenieros y especialistas de software para defender la seguridad en su trabajo.

El cartel de invitados fue sensacional -por no hablar de su refrescante diversidad- y es una gran sensación que, incluso después de todos estos años en el sector, yo también pueda salir inspirado. Personas como Tanya Janca, Toni James y Teri Radichel ofrecieron presentaciones increíbles, mientras que Wireghoul'Eldar Marcussen puso a prueba a todo el auditorio con desafíos de codificación segura en el acto, pero fue genial ser testigo de tanta conciencia de seguridad entre los asistentes.

Este año, Secure Code Warrior fue un patrocinador platino del evento. Tuve que sonreír al recordar que hace sólo cuatro años, era el equipo detrás de OWASP AppSec Day el que ayudaba a nuestra startup de arranque con un stand gratuito y promoción. Fue un momento de orgullo al ver lo lejos que habíamos llegado como empresa, y un momento para agradecer que exista una comunidad tan generosa de gente increíble.

Toni James: La seguridad desde la perspectiva del desarrollador

Si hay algo que debemos cultivar más en este mundo, es la empatía. Y cuando se trata de hacer que el software sea más seguro en todos los ámbitos, es esencial comprender la difícil situación del desarrollador.

Me gustó mucho la presentación de Toni, y estoy seguro de que todos los desarrolladores pudieron identificarla al instante. Hay mucho más en la historia que simplemente "escribir código seguro", y aunque ciertamente creo que los desarrolladores formados eficazmente en seguridad son nuestra mejor oportunidad en la lucha contra las vulnerabilidades, es imperativo considerar sus desafíos diarios.

El trabajo de un desarrollador de software puede estar a la vista de millones de usuarios, dar soporte a infraestructuras críticas y ser la fuerza motriz de servicios que damos por sentado. La creación de características, la ejecución de innovaciones empresariales y el cumplimiento de plazos de entrega ajustados suponen una gran presión, y eso antes de que un equipo de AppSec se asome a su trabajo. Toni habló de cómo es la vida en este entorno, y de cómo una buena dosis de empatía por parte de todos puede conducir a procesos y resultados de seguridad mucho mejores. Me complace mucho ver que se están dando pasos tan saludables para salvar la brecha entre los desarrolladores y los equipos de AppSec; al fin y al cabo, este es un elemento crítico en una cultura de seguridad positiva y próspera, y Toni es un excelente ejemplo de que este proceso funciona increíblemente bien.

Tanya Janca y Teri Radichel: Superhéroes de la seguridad

No es que sea una competición, pero las contribuciones de Tanya Janca y Teri Radichel a la conferencia estuvieron entre mis favoritas. A los diez minutos de su tutorial sobre evaluaciones de seguridad en la nube DIY, se puso de manifiesto su increíble amplitud de experiencia, cualificaciones y conocimientos, pero también su genuina calidez y deseo de compartir conocimientos y apoyar a la comunidad de desarrolladores. Juntos, presentaron acciones realistas y ejecutables para garantizar que las implementaciones de Azure fueran seguras, incluyendo consejos prácticos para establecer políticas de seguridad y medidas de mínimo privilegio.

Una rápida búsqueda en Google le dirá todo lo que necesita saber sobre su dedicación a apoyar a los desarrolladores a nivel de base, con una gran cantidad de recursos gratuitos, oportunidades de tutoría y entrevistas para promover el lado divertido y atractivo de la seguridad del software. Son campeones inspiradores y vitales de nuestra comunidad; si intervienen en la próxima conferencia de seguridad a la que asistas, estarías loco si te perdieras su sesión.

Clientes en el gran escenario

Fue brillante ver a tantos de nuestros clientes no sólo en la asistencia, sino también siendo dueños del escenario y compartiendo sus inmensos conocimientos de seguridad con la audiencia.

Conseguimos ver a Andrew Bailey, de Telstra, dando una importante charla, "Añadiendo el "Sec" a DevOps". Su gran experiencia como ingeniero de software senior, ahora centrado en la seguridad de las aplicaciones y la codificación segura, fue una perspectiva excelente para destacar. Dio consejos de principio a fin sobre cómo inyectar la seguridad en cada etapa del SDLC (incluyendo, por supuesto, justo al principio, formando a más desarrolladores en la codificación segura).

Ken Johnson forma parte del equipo de seguridad de GitHub, y me encantó verlo unirse al panel de expertos al final de la conferencia. Él, junto con los demás panelistas, estuvo encantado de responder a las preguntas urgentes del público, incluidas aquellas que no reciben necesariamente la atención que merecen en los medios de comunicación. Además de varias ideas del sector, hizo que el panel hablara de la importancia del bienestar y del equilibrio entre el trabajo y la vida privada, algo muy importante en esta época de agotamiento de los desarrolladores.

Me gustaría extender un enorme agradecimiento a Julian Berton y a todo el equipo de OWASP Melbourne por otra increíble conferencia. Nos vemos el año que viene (con más pegatinas).

Da la sensación de que el "cumplimiento de la ciberseguridad" es una tendencia desde hace años, con un sinfín de artículos, iniciativas y comités que debaten sobre la mejor manera de afrontar la enorme bestia de múltiples amenazas que es la ciberdelincuencia.

El problema es que no parece que hayamos avanzado tanto. A nivel mundial, el coste de las filtraciones de datos ha aumentado constantemente, un 12% en cinco años para establecerse en aproximadamente 3,92 millones de dólares por filtración en 2019. A medida que nuestro uso de Internet se disparó en tan solo un par de décadas, muchas empresas simplemente se vieron obligadas a luchar sin armadura mientras se conectaban rápidamente, se establecían y lidiaban con las consecuencias de un software inseguro, recursos limitados de AppSec y, en algunos casos, el abuso de la confianza de los clientes.

Hoy en día, somos irrefutablemente más maduros. Comprendemos y debatimos ampliamente el alcance de la amenaza, las empresas son muy conscientes del impacto que un ciberataque puede tener en la opinión de los clientes, su reputación y sus resultados, y muchos lugares buscan activamente mejorar la seguridad del software a través de la formación en materia de cumplimiento, la contratación de personal cualificado y, cada vez más, las iniciativas de DevSecOps. A pesar de estos enormes saltos, no estamos ganando la lucha, ni siquiera cerca. Se han robado al menos cuatro mil millones de registros en violaciones de datos solo en 2019.

Un ingrediente que faltaba ha sido un goteo algo lento (a nivel gubernamental) sobre las normas de ciberseguridad, las expectativas y las consecuencias de una violación. La llegada del GDPR ha hecho que algunas cabezas empiecen a rodar, al menos en Europa, pero muchos organismos gubernamentales solo se están poniendo al día ahora, y la repentina necesidad de acatar rápidamente las iniciativas de cumplimiento recién florecidas podría tener algunos efectos no deseados en el futuro.

Los tontos se precipitan (a la formación equivocada)

Las sólidas directrices del NIST, la nueva normativa del Estado de Nueva York y la creación del Consejo de Ciberseguridad del Reino Unido han sido victorias monumentales para los que luchan por mantener nuestros datos seguros. Reconocen los problemas en el desarrollo de software actual y toman medidas para orientar a las organizaciones sobre las normas que deben cumplir ahora para ser consideradas éticas y conformes, en términos de mejores prácticas de seguridad.

Lamentablemente, en este momento, algunos de los elementos más importantes están demasiado abiertos a la interpretación. Por ejemplo, uno de los mandatos de la legislación del Consejo de Ciberseguridad del Reino Unido es:

"Crear una lista definida de certificaciones y un marco fácil de entender sobre cómo se relacionan entre sí y qué capacidades transmiten, basándose en el trabajo de itinerarios profesionales ya realizado".

Aunque sus iniciativas sin duda mejorarán y crecerán con el tiempo, si las organizaciones ya están pulsando el botón del pánico y saltando a la formación ahora, podrían encontrarse mal equipadas para el futuro.

Las exigencias de ciberseguridad de una organización cambian rápidamente, y es poco probable que las soluciones de formación estática frenen el flujo de software inseguro al ritmo necesario. El panorama cambia más rápido de lo que un curso tradicional puede actualizar, lo que puede hacer que algunos lugares caigan en la trampa del ejercicio de cumplimiento de "marcar la casilla"; los desarrolladores, contratistas y otros profesionales de la seguridad no reciben la formación adecuada, y volvemos a ser blancos fáciles.

La formación estática y las herramientas estáticas sufren los mismos problemas

Las herramientas de análisis estático son una parte integral del SDLC, haciendo su trabajo como caballos de batalla para los escasos y sobrecargados especialistas de AppSec que se encuentran en la mayoría de las grandes organizaciones. Hacen un buen trabajo, pero hay un defecto: ninguna herramienta puede escanear todas las vulnerabilidades, soportando la enorme gama de marcos de programación existentes. También es un proceso lento, y basta con que un solo fallo de seguridad se cuele entre las grietas para dejar una puerta abierta a un atacante.

En el caso de la formación estática, existe un problema similar. Si los desarrolladores reciben la formación en seguridad como un curso rígido, "de una sola vez", es muy poco probable que se haya mantenido al día con los problemas de seguridad más prevalentes en ese período de tiempo. Sirve como una instantánea del momento en que se escribió, y rara vez se revisa lo suficiente, se imparte en el lenguaje y el marco de trabajo preferidos por el estudiante, ni es contextual a las vulnerabilidades a las que probablemente se enfrenten en su trabajo diario. Imagina que intentas recordar una pieza de información relevante de un vídeo que viste hace meses, mientras intentas cumplir con los plazos de entrega y sacar el código por la puerta... es poco probable que suceda.

Los métodos tradicionales de educación están siendo reevaluados en muchas industrias, pero cuando se trata de la formación en seguridad para desarrolladores, sólo hay que ver el gran volumen de violaciones de datos que todavía experimentamos (especialmente aquellas que pueden ser atribuidas a vulnerabilidades que hemos sabido evitar en la codificación durante décadas, como la inyección SQL) para darse cuenta de que debemos intentar una manera diferente.

Necesitamos una formación que vaya más allá de los límites de un curso único y lineal, que pueda flexibilizarse y adaptarse a las necesidades siempre cambiantes de las mejores prácticas de ciberseguridad.

Entrenamiento dinámico: el estándar de oro

Al ofrecer a los desarrolladores una solución de formación dinámica, que puede adaptarse rápidamente a la empresa, al nivel de habilidad individual y a los movimientos generales de la industria, les está proporcionando la mejor base para codificar de forma segura, manteniendo la seguridad en primer plano y actuando con una mentalidad consciente de la seguridad.

Una formación única, que nunca se revisa y que no es atractiva en primer lugar, será una completa pérdida de tiempo y, por desgracia, eso significa que podría acabar comprando por impulso un programa ineficaz en aras del cumplimiento. Podría quedar obsoleto antes de que lo ponga en marcha, o apenas se puede relacionar con las necesidades de su trabajo diario.

La formación dinámica es una herramienta viva, que se actualiza constantemente, que se adapta a las necesidades cotidianas, que involucra a los usuarios con el pensamiento crítico y que realmente les permite aprender habilidades y solucionar problemas.

Entonces, ¿cómo es un programa de formación dinámico en un contexto de seguridad?

Lo será:

• En trozos: Los desarrolladores pueden aprender habilidades en trozos manejables que son mucho más fáciles de recordar (y, lo que es más importante, de aplicar) que los largos mazos de formación y los vídeos
• Es relevante: ¿De qué sirve una formación genérica en materia de seguridad en la que los ejemplos están en, por ejemplo, C#, cuando el desarrollador codifica principalmente en Java? Cualquier formación debería aplicarse directamente a su función, permitiéndoles ver lo que deben encontrar y corregir (e, idealmente, evitar en primer lugar) mientras codifican.
• Actual: Esto parece obvio, pero a menudo no lo es. El panorama de la ciberseguridad cambia constantemente, y con más código viene más responsabilidad. Para que los desarrolladores sean su primera línea de defensa, necesitan una formación que se mantenga al día con las mejores prácticas de seguridad modernas.
• Atractivo: No es ningún secreto que los desarrolladores pueden encontrar la "seguridad" como una tarea, especialmente si interfiere con su flujo creativo. La formación adecuada les mostrará el poder que tienen en la resolución de problemas de seguridad cotidianos que pueden convertirse en grandes riesgos, creando una cultura de responsabilidad y conciencia de seguridad.
• Divertido: La formación dinámica rara vez es aburrida; se supone que debe ser al menos algo emocionante por su diseño. Piensa en lo que les gusta a los desarrolladores: resolver problemas, competir con sus compañeros y, como a muchos de nosotros en el trabajo, las recompensas y el reconocimiento. Aproveche sus puntos fuertes y concéntrese en obtener los mejores resultados.

Es un momento emocionante para ser ingeniero de software; desempeñan un papel integral en la innovación digital, ayudan a crear empresas increíbles e incluso toman el mundo por sorpresa con sus propias creaciones. Sin embargo, ahora que los organismos gubernamentales y las grandes empresas son conscientes del papel que deben desempeñar en el establecimiento de normas de seguridad del software, es importante apoyarlos con soluciones de formación eficaces y dinámicas que fomenten el amor por la codificación segura, y no un ejercicio burocrático de marcar casillas.

La frase "se necesita una aldea" es un antiguo proverbio africano, que abarca muchas culturas africanas diversas, dialectos y ubicaciones geográficas. Aunque el lenguaje utilizado para transmitir esta perla de sabiduría puede ser diferente, el sentimiento es el mismo: se necesita la aportación de toda la comunidad para crear un entorno seguro, positivo e instructivo para criar a las futuras generaciones en adultos bien formados.

Puede parecer un arco muy largo de dibujar, pero realmente, la comunidad de desarrolladores ha prosperado durante décadas sobre este mismo principio. La noción del friki antisocial y "lobo solitario" detrás de un ordenador es como la mayoría de los estereotipos: exagerada y no es la mejor manera de saber cómo funcionamos. Hay desarrolladores de todo tipo, de todas las clases sociales, y siempre ha habido un sentido de comunidad en todo lo que hacemos.

Mucho antes de que Internet se convirtiera en la norma, estábamos en los tablones de anuncios compartiendo consejos, resolviendo los problemas de los demás y discutiendo sobre las mejores prácticas (y, ciertamente en mi lado de la valla, trabajando duro para romper cosas). Este sentimiento no ha cambiado. Internet es ahora una bestia diferente, con más trolls bajo el puente y mucho más ruido, pero un rápido salto a lugares como Reddit y Stack Overflow te dará una sensación inmediata de voluntad de ayuda, camaradería y una gran cantidad de información.

Sin embargo, algo que todos podríamos apoyar son esas conexiones en el mundo real con personas que pasan por lo mismo. Hay una nueva capa de significado cuando se interactúa en el mundo real, y facilitar una comunidad "IRL" puede acelerar el intercambio de conocimientos, la clarificación y ampliar los horizontes de manera maravillosa.

¿Cómo apoya la comunidad de desarrolladores la seguridad?

Organizaciones como OWASP están haciendo un trabajo increíble en la comunidad de seguridad, con abundantes recursos gratuitos sobre vulnerabilidades, noticias y alertas críticas. Fuera de línea, hay capítulos de OWASP en ciudades de todo el mundo, que organizan eventos regulares para que la gente se reúna, hable de seguridad y comparta consejos para hacer nuestro software más seguro. Es realmente impresionante, y para mí, es lo que significa la comunidad de desarrollo.

Una de las cosas que estas comunidades, ya sean en línea o en persona, ayudan a resolver es la brecha de habilidades y conocimientos entre los desarrolladores. Muchos desarrolladores experimentados están encantados de transmitir información, ayudar a alguien a empezar o indicarle la dirección correcta (cualquier buen Jedi sabe que necesita ayudar a un padawan de vez en cuando).

Por eso, siempre es un verdadero placer cuando nos asociamos con ellos para organizar cosas como la codificación segura tournaments. Hasta ahora, hemos apoyado encuentros en Australia, Inglaterra, India y Estados Unidos, y espero que haya muchos más por venir.

¿Cómo es una reunión de OWASP tournament ? Echa un vistazo a este vídeo de un OWASP tournament celebrado en Londres en los emblemáticos estudios de la BBC:

Estos eventos contribuyen sin duda a la concienciación, y este impulso puede aprovecharse dentro de las organizaciones cuando apoyen estas iniciativas de base, introduzcan una formación de codificación segura completa y se comprometan a operar con una cultura de seguridad positiva.

¿Cómo ayudan la gamificación y tournaments a crear desarrolladores más seguros?

Los encuentros de OWASP se basan en la socialización, el intercambio de conocimientos y la discusión de ideas con una amplia gama de personas conscientes de la seguridad. Sin embargo, para aquellos que son nuevos en el mundo de la seguridad (o que aún no tienen interés en ella), estos eventos pueden pasar desapercibidos.

Cuando las organizaciones desempeñan un papel activo en la concienciación sobre la seguridad y despiertan un interés real entre la cohorte de desarrolladores, esto puede tener el efecto positivo de inculcar una búsqueda permanente de conocimientos sobre seguridad en el interior, del tipo que necesitamos para que todo el mundo se tome más en serio la codificación segura.

Los métodos típicos de formación no suelen motivar mucho (piense en sentarse en un aula mientras las tareas de su trabajo se acumulan, o en tratar de mantenerse despierto viendo vídeos interminables), pero encender un sentido de competencia, diversión y gamificación del proceso puede hacer que el aprendizaje sea mucho menos pesado. Los métodos de aprendizaje gamificado hacen que el conocimiento técnico (y, a veces, árido) sea mucho más digerible, dividiéndolo en trozos más pequeños que son contextuales, memorables y fomentan la repetición del aprendizaje. Secure Code Warrior se construyó sobre una base de accesibilidad, permitiendo a los desarrolladores seguir añadiendo a sus aprendizajes anteriores paso a paso, de una manera que habla de su creatividad e instinto general para resolver problemas.

Las evaluaciones ayudan a mantener a todo el mundo en el buen camino y a identificar las áreas de mejora, pero una codificación segura tournament puede servir como catalizador para la concienciación sobre la seguridad de la organización y para un cambio positivo, así como para que los participantes muestren sus sólidas habilidades. Al fin y al cabo, cuando se ve una tabla de clasificación de tournament que se actualiza en tiempo real, uno se siente motivado para seguir esforzándose por conseguir más puntos y demostrar realmente su destreza en materia de seguridad.

¿Qué aspecto tiene un tournament de éxito?

El objetivo de nuestros encuentros con OWASP es siempre invertir en la salud continua de la comunidad de seguridad, ayudándoles a promover el concepto de que aprender sobre seguridad puede ser realmente divertido.

La codificación segura tournaments es una opción obvia cuando se trata de involucrar a los desarrolladores, ayudándoles a perfeccionar y realizar sus habilidades en un entorno social con personas de ideas afines. Ayudan a derribar los muros artificiales que pueden existir en torno a la idea de "seguridad", quizás por una experiencia poco agradable en el trabajo o la educación.

Un verdadero gran tournament suele consistir en lo siguiente:

• Un poco de fanfarria en la organización; que la gente fuera de los equipos de desarrollo sepa lo que está pasando y por qué
• Un entorno libre de juicios de valor, que apoya a los desarrolladores de todos los niveles
• Unas cuantas ventajas especiales; pide comida y bebida, dale un tema y fomenta la autoexpresión
• Recompensas y reconocimiento; a los desarrolladores nos encanta el botín, y los premios para los ganadores son un extra: recuerde que sus futuros campeones de seguridad podrían ser descubiertos durante este proceso
• Un sentido de comunidad y camaradería.

Nos estamos convirtiendo en un mundo de DevSecOps, y con la seguridad finalmente enfocada desde el principio de los proyectos de desarrollo de software, los desarrolladores necesitan participar desde el principio con una formación eficaz. Son parte integral de la protección de una organización contra las vulnerabilidades desde el momento en que se escribe el código, y en una cultura de seguridad próspera, todo el mundo puede estar más tranquilo.