Desde que comenzamos nuestra misión en 2015, siempre nos hemos centrado en facilitar una formación de codificación segura divertida, relevante y atractiva para los desarrolladores. Hace tiempo que reconocimos la importancia de dar a los desarrolladores los conocimientos y las herramientas para entender las mejores prácticas de seguridad, por qué son importantes y cómo pueden ayudar a fortificar el software de los ataques maliciosos mientras se escribe el código.

Sin embargo, la formación en seguridad no es un concepto nuevo. Ciertamente no fuimos los primeros en tomar la iniciativa, y las medidas de seguridad adecuadas han sido una consideración en el desarrollo de software durante mucho tiempo. Seguro que algunos tipos de formación son más eficaces que otros, pero el acceso a cierta formación en seguridad es relativamente fácil de encontrar, especialmente hoy en día.

... entonces, ¿por qué demonios tenemos tantas violaciones de datos? Hasta septiembre, más de cuatro mil millones de registros han sido expuestos a través de múltiples ciberataques solo en 2019.

Actualmente, muchas organizaciones están librando una batalla perdida para mantener a salvo nuestros datos, cada vez más valiosos. Los CISO y los CIO de todo el mundo tienen muy claro que "cambiar a la izquierda" todavía es demasiado tarde; debemos empezar por la izquierda con la seguridad en el SDLC, y eso significa que los desarrolladores deben tener los conocimientos de seguridad adecuados para corregir los fallos mucho antes de que el código se comprometa, y mucho menos que se haga público.

Los especialistas en seguridad de las aplicaciones no pueden ser los únicos guardianes de los conocimientos de seguridad.

En el pasado, la seguridad del software era el dominio de un grupo muy particular de frikis inteligentes, sin apenas interacción con los ingenieros que escribían el código. Su trabajo consistía en probar, romper y evitar que el código inseguro viera la luz. Si se cruzaban, lo más probable era que el especialista en seguridad señalara los fallos del código... algo que garantizaba una recepción fría por parte del desarrollador que había trabajado como un esclavo en su creación.

Si avanzamos hasta hoy, la situación es prácticamente la misma, salvo que ahora hay mucho más en juego. Casi todos los aspectos de nuestras vidas están digitalizados... todo, desde los álbumes de fotos en las redes sociales, los historiales médicos, las operaciones bancarias y nuestros documentos de identidad más valiosos. Una cosa era proteger el software y los sistemas operativos mayoritariamente fuera de línea y autónomos. Otra muy distinta es tener que defenderse de las amenazas a miles de millones de líneas de código, con cientos de millones de usuarios potencialmente en riesgo. Simplemente hay demasiado en juego para que un solo grupo de especialistas asuma toda la responsabilidad, y por eso debemos tender un puente entre AppSec y el equipo de desarrollo. Tienen que trabajar juntos, compartir conocimientos y operar como una unidad cohesionada y consciente de la seguridad.

Sólo hay un problema: los desarrolladores rara vez tienen la oportunidad de aprender habilidades de codificación segura de manera significativa. La mayor parte de la educación terciaria apenas aborda las mejores prácticas de seguridad, y la formación en el puesto de trabajo varía enormemente en calidad.

¿No es de extrañar que veamos grandes infracciones cada dos días? Descargue nuestra lista de comprobación de AppSec.

‍

Una "licencia para codificar".

A pesar del sombrío panorama actual, soy optimista sobre el futuro de la seguridad. Hay un cambio en el aire, y estoy muy animado por la inmensa cantidad de organizaciones que se toman en serio la codificación segura en este momento.

Cada vez es más evidente que los desarrolladores necesitan tener acceso a las herramientas y conocimientos adecuados para mitigar los riesgos de seguridad, y que una cultura floreciente de concienciación sobre la seguridad es vital en la lucha contra las violaciones de datos. Cuando los desarrolladores asumen la responsabilidad de la seguridad a medida que se escribe el código, es mucho menos fácil para los atacantes explotar fallos simples y obtener las llaves del castillo.

Siempre se ha dado el caso de que algunos desarrolladores son más conscientes de la seguridad que otros, y esto supone un verdadero reto para las organizaciones. Mientras que los equipos de desarrollo internos suelen tener cierto grado de formación y control de habilidades, las aguas se enturbian mucho cuando se introducen en la mezcla contratistas, autónomos y recién licenciados. ¿Actúan con una mentalidad de seguridad? ¿Pueden evitar con éxito fallos antiguos, como el cross-site scripting, que existen desde hace décadas? Es difícil saberlo, pero a menudo se les deja sueltos en partes vitales de una construcción de software. Vaya.

Afortunadamente, estamos viendo un aumento de las normas no negociables para los desarrolladores. Por ejemplo, algunas organizaciones están utilizando Secure Code Warrior como herramienta para evaluar las habilidades de desarrollo y emitir una "licencia para codificar". Si no superan las evaluaciones fundamentales de codificación segura, no podrán trabajar en ningún proyecto. Esto ha sido muy valioso para ayudar a los graduados y pasantes a ponerse al día con sus habilidades de seguridad, mientras que al mismo tiempo, inculcar un sentido de importancia para codificar de forma segura. Después de todo, la seguridad debe ser sinónimo de calidad cuando se trata de software.

La formación extracurricular está poniendo a las universidades en el punto de mira.

Cambiar la conversación en torno a la codificación segura requiere algo más que un artículo aquí, un discurso de apertura allá. Tiene que ser un movimiento que abarque a toda la comunidad, y es estupendo ver que tantas organizaciones de primer nivel toman nota y crean programas de seguridad de alto nivel con un nivel envidiable. Una de estas empresas es HSBC, cuyo formidable programa está garantizando que los recién licenciados y los nuevos contratados se pongan en marcha lo antes posible. Como director de la Academia de Tecnología de HSBC India, Sekhar Babu Tatavarti ha considerado que la formación en seguridad es imprescindible:

"En HSBC Technology, queríamos asegurarnos de que nuestra comunidad de desarrolladores comprendiera la importancia de la codificación segura para proteger al banco de las vulnerabilidades. En el Programa de Formación para Graduados que tuvimos este año, pensamos que era una gran oportunidad para atraparlos jóvenes y permitirles autoaprender y arraigar las mejores prácticas de codificación segura antes de que lleguen al piso y comiencen a codificar en sus respectivos proyectos.  

Elegimos la plataforma Secure Code Warrior por su maravilloso método de gamificación del aprendizaje para los graduados, y no desmintieron nuestras expectativas. Estamos encantados de que cada uno de ellos haya participado con entusiasmo en tournament , además de completar la certificación de cinturón blanco en diferentes tecnologías", afirmó.

Cada vez más organizaciones, como HSBC, consideran que las capacidades de codificación segura son esenciales a nivel de desarrollador. Y lo que esto ha hecho, en efecto, es arrojar luz sobre la educación terciaria en su conjunto. Los CISO y los CIO están empezando a preguntarse por qué los ingenieros recién graduados están completando su educación sin ninguna formación sólida en seguridad.

Innovación en la educación terciaria.

Mientras que la codificación segura debe convertirse en un componente obligatorio de la ingeniería de software a nivel terciario, algunas universidades están liderando la carga de proporcionar una formación de primera categoría y priorizar la seguridad como parte del proceso de desarrollo desde el principio, en lugar de ser el dominio de los escasos especialistas en AppSec sobre el terreno.

En la Universidad de Queensland (Australia), el profesor Ryan Ko está realizando importantes avances en la preparación de la próxima oleada de desarrolladores para protegernos de la inevitable avalancha de ciberataques:

"La mayoría de las vulnerabilidades del software se introducen en la fase de codificación, por lo que si podemos abordar esto en su origen (es decir, el programador), podríamos erradicar la mayoría de los problemas recurrentes que se encuentran hoy en la lista CVE. Dado que el software afecta a la vida y el sustento de la mayor parte de nuestra sociedad moderna, las universidades y las instituciones de formación tienen la responsabilidad moral y social de enseñar a todos los programadores noveles a codificar de forma segura", afirmó.

Se trata de una evolución emocionante con respecto al estándar courses, que ofrece muy poco en cuanto a conocimientos y habilidades de seguridad significativos. Y este es un "virus" que no me importaría propagar más. Para mi deleite, la Universidad Macquarie también está infectando a sus estudiantes con una mentalidad de seguridad primero, gracias a los esfuerzos de individuos como Christophe Doche:

"Lanzado en 2016, el Centro de Seguridad Cibernética de la Universidad Optus Macquarie es la primera iniciativa de este tipo en Australia, vinculando a los académicos en seguridad de la información, negocios, criminología, inteligencia, derecho y psicología junto con expertos en ciberseguridad de la industria y el gobierno.

Nuestra misión es posicionar a Australia como líder mundial en ciberseguridad a través de la educación, la investigación y las asociaciones. Un aspecto importante de esto es abordar la bien documentada brecha de habilidades en ciberseguridad, con proyecciones que muestran que es muy probable que 1,8 millones de puestos de trabajo no se cubran en todo el mundo en 2022.

Para solucionar este déficit de cualificación es necesario un enfoque múltiple, que implique el perfeccionamiento y la reconversión de la mano de obra existente, así como la formación de una nueva generación de especialistas en ciberseguridad", afirmó.

Su enfoque es increíble, ya que ofrece un aprendizaje de precisión con un alto grado de participación que ayuda a reducir las diferencias entre los departamentos y a crear un ritmo de concienciación de seguridad próspero. Están aprovechando el microaprendizaje en su estrategia, ofreciendo módulos de aprendizaje gamificados y del tamaño de un bocado con un alto índice de retención, compromiso y repetición. Estoy especialmente orgulloso de que podamos ayudarles a involucrar a sus estudiantes de forma creativa:

. "Un excelente ejemplo de este compromiso es la asociación con Secure Code warrior. Después de un tournament organizado por Secure Code Warrior y el Cyber Security Hub en agosto de 2019, ahora estamos estudiando la posibilidad de integrar la plataforma Secure Code Warrior en nuestro plan de estudios, especialmente en nuestra nueva unidad sobre Desarrollo de Aplicaciones Seguras", dijo Christophe.

Iniciativas como las de la Universidad Macquarie y la Universidad de Queensland son realmente pioneras en la codificación segura en el espacio educativo. Nuestro objetivo como profesionales de la seguridad de las aplicaciones, desarrolladores y comunidad de seguridad en general, debe ser incorporar la seguridad a todo lo que hacemos, y continuar con nuestro compromiso de empezar por la izquierda.

El 3 de septiembre, yo y algunos miembros del equipo asistimos a una impresionante conferencia de premios de seguridad, organizada por CSO Australia. Uno de los primeros de su tipo en Australia, los Premios a las Mujeres en la Seguridad 2019 fueron una increíble culminación de algunas de las mentes de seguridad más reconocidas de la industria. Fue una celebración de las contribuciones femeninas en la ciberseguridad, así como una plataforma muy necesaria para mostrar el increíble talento y la innovación aportada por las mujeres que a menudo están fuera de los focos y trabajan haciendo un trabajo increíble.

Me enorgullece decir que la vicepresidenta de éxito de clientes de Secure Code Warrior(también conocida como Chief Awesome), Fatemah Beydoun, formó parte de ese día. Presentó su charla, Mentoring for the future: Cómo podemos mejorar el fomento del talento femenino en ciberseguridad ante un público muy receptivo. Aunque doce minutos no son suficientes para revelar el impacto que ha tenido en nosotros y en la industria de la ciberseguridad en general, ha visto (por no decir que ha impulsado) un cambio positivo crítico.

Un enfoque más inclusivo.

"Cuando empecé mi carrera en este sector", dice Fatemah, "era una de las pocas mujeres en los equipos en los que me colocaban. Muchas de las oportunidades de establecer contactos también estaban centradas en los hombres, lo que me dificultaba participar, conocer a las personas adecuadas y demostrar un valor crítico para la empresa. Intenté cambiar esa dinámica, creando un espacio más inclusivo siempre que fuera posible.

Por ejemplo, a menudo asistía a eventos del sector y me encontraba con que muchos stands de empresas empleaban modelos promocionales para ayudar a llamar la atención sobre sus puestos. Eso está bien en teoría, pero a menudo me ignoraban porque claramente no era el mercado objetivo. Al principio de mi carrera me encargué de organizar eventos y me propuse que podíamos idear formas más inclusivas y divertidas de llamar la atención sobre nuestra propia oferta", explica.

Fatemah y yo hemos trabajado juntas durante mucho tiempo, y ella siempre ha defendido la inclusión y la diversidad en las empresas en las que hemos trabajado. Esto siempre ha dado lugar a más vías para las mujeres en el equipo, al reconocimiento de las contribuciones clave y a una cohorte que se ve reforzada por diferentes enfoques, opiniones y trayectorias vitales.

"Nadie quiere ser la mujer simbólica, por supuesto", dice Fatemah. "Sin embargo, el problema puede ser que algunos equipos ejecutivos menos diversos tienden a pasar el testigo del liderazgo a aquellos que son como ellos, con los que pueden relacionarse a nivel personal. Estos mismos ejecutivos podrían beneficiarse de la contribución de una mujer en función de sus méritos y habilidades, pero a menudo les resulta difícil conseguir una oportunidad. Si los equipos de dirección ejecutiva son conscientes de la fuerza que puede aportar la diversidad (y que va más allá del género), suelen estar bastante dispuestos a crear esas vías y empezar a elevar a las mujeres que están preparadas, dispuestas y son capaces de hacer un trabajo impresionante para su organización", dijo.

Flexibilidad en el lugar de trabajo: ingredientes clave para el éxito.

Al crear mi propia empresa aprendí muy pronto que el mejor trabajo se hace cuando los miembros del equipo tienen espacio para respirar. La flexibilidad es importante para todos, pero las políticas que ayudan a las familias trabajadoras pueden ser fundamentales para retener el talento vital.

Una de las primeras políticas que se introdujeron aquí fue la Política de Bebés en el Trabajo, que permite a las nuevas madres volver al trabajo antes con la flexibilidad necesaria para las citas y la posibilidad de llevar a los bebés al trabajo sin temor a ser juzgados.

"No quería elegir entre ser madre y mi carrera, y la posibilidad de llevar a mi hijo pequeño al trabajo fue algo tan positivo para que me siguiera sintiendo apoyada y valorada", afirma Fatemah. "Mis habilidades no desaparecen después del parto, y siendo miembro fundador de una startup, bueno, ¡sólo quieres volver a ella!".

Incluso ha hablado con ABC News sobre las ventajas del trabajo flexible:

¿Tiene una cultura de mentores próspera?

Para que cualquier persona comience una gran trayectoria profesional y mantenga su impulso, es una gran idea que tenga un mentor. En muchos campos de la informática, la ciberseguridad y los campos en los que predominan los hombres, hay un gran desequilibrio entre las mujeres de nivel ejecutivo en comparación con los hombres, por lo que puede ser un poco difícil.

Aunque es importante que las mujeres se vean "a sí mismas" en puestos de liderazgo, los hombres también pueden ayudar elevando a las mujeres inteligentes de sus equipos e interviniendo como mentores, siempre que sea posible.

"Los equipos de liderazgo pueden tener un enorme impacto en la diversificación de una organización, así como garantizar que las mujeres excepcionales obtengan el reconocimiento y las trayectorias profesionales que merecen tanto como cualquier otra persona. He visto esto en acción con la Jefa de Ciberseguridad de Jetstar, Yvette Lejins. Es una campeona de las mujeres y, a través de su propio éxito y de su duro trabajo, ha contribuido a que otras mujeres tengan la confianza necesaria para llegar a lo más alto", dijo Fatemah.

En estos momentos, Secure Code Warrior acaba de celebrar que ha llegado a los 100 empleados. Me enorgullece decir que tenemos más de un 50% de representación femenina en toda la empresa, y Fatemah es un modelo excepcional y un mentor para todos.

Todas las empresas pueden encontrar una inmensa fuerza en la diversificación de sus equipos. Un abanico de opiniones, de diferentes ámbitos, puede ser el ingrediente secreto necesario para convertir las buenas ideas en grandes ideas. Como siempre, todos somos más fuertes juntos.

El sector de la seguridad del software no es precisamente conocido por sus sentimientos cálidos y difusos, sus observaciones caprichosas y sus comentarios sobre la vida, pero, quizás a medida que envejezco, me encuentro reflexionando sobre el impacto que todos podemos tener en el mundo. Y, puede causar un efecto dominó positivo que se extiende mucho más allá de los límites de la ciberseguridad.

Gracias a la sugerencia de un miembro del equipo, hemos implantado el programa Warriors Give Back en toda la empresa. Esta iniciativa se ha diseñado para que nos impliquemos en el espíritu de "devolver" a las comunidades que nos rodean, trabajando activamente en equipo para hacer que el mundo sea un poco más brillante.

Aunque fue una oportunidad increíble para que muchos de nosotros nos uniéramos como equipo, fue un momento único para dar un paso atrás, examinar el terreno y ver lo que es verdaderamente importante con una claridad renovada. Como te dirá cualquiera que esté en una empresa emergente, puede ser súper agitado, con poco tiempo de inactividad... es gratificante, agotador y emocionante a la vez. Sin embargo, cuando vives y respiras tu negocio, puede ser demasiado fácil dejar de lado la vida que te rodea.

Una fuerza para el bien.

Lo más importante que esperábamos conseguir era hacer algo inmediatamente útil para la comunidad, no sólo posar para unas cuantas fotos para darnos una palmadita en la espalda. Se trataba de reconocer nuestro privilegio y actuar con gratitud. Todo el mundo, en cualquier sector, podría hacer un poco más de eso. Al fin y al cabo, nunca se puede difundir demasiada buena voluntad, ni ser demasiado humilde.

Para nuestro evento inaugural, decidimos trabajar juntos construyendo bicicletas para niños desfavorecidos, a través del programa Bikes for Tykes. Estoy seguro de que recordaremos este día con un grato recuerdo de nuestras habilidades mecánicas combinadas (o de la falta de ellas), y con muchas risas, pero la chispa de felicidad aportada a nueve niños muy especiales en el momento en que más lo necesitaban, es una recompensa que va mucho más allá del aspecto material de una bicicleta nueva. Este evento fue un pequeño gesto por nuestra parte, pero tengo la esperanza de que, por un momento, pudieran olvidar sus problemas y simplemente disfrutar de ser niños.

Devuelve, obtén más.

Un viejo refrán dice algo así como "la bondad es un regalo que todo el mundo puede permitirse". Eso es muy cierto, pero una cosa que la comunidad de la ciberseguridad, en particular, parece hacer bien, es la abundancia de intercambio de conocimientos gratuitos y recursos en línea para ayudar a la gente a entender, aprender y explorar. Naturalmente, organizaciones como OWASP dedican mucho tiempo a hacernos a todos más seguros, y veo constantemente la disposición de los demás a ayudar a responder preguntas después de las presentaciones y funciones de los eventos. Creo que si todos diéramos más, nos daríamos cuenta de que al final se nos devuelve diez veces.  

Vamos a continuar con nuestro empeño de retribuir, como hacen muchas otras empresas increíbles de todo el mundo. Seamos una fuerza para el cambio positivo, estemos donde estemos.

(Psst: nuestra biblioteca de recursos de aprendizaje para desarrolladores está siempre abierta para vosotros).

Los recientes informes sobre el investigador de seguridad adolescente, Bill Demirkapi, que ha sacado a la luz importantes vulnerabilidades en el software utilizado por su escuela, me han traído algunos recuerdos. Recuerdo ser el niño curioso que levantaba el capó del software para echar un vistazo por debajo y ver cómo funcionaba, y lo que es más importante, si podía romperlo. Durante décadas, los ingenieros de software han buscado la mejora continua y la fortificación de sus productos, y la comunidad de seguridad (aunque un poco descarada en su enfoque, a veces) desempeña un papel importante en el descubrimiento de defectos y desastres potenciales, con suerte antes de que un malvado haga lo mismo.

Sin embargo, la cuestión aquí es que en respuesta a sus descubrimientos, llevó una suspensión menor de la escuela. Y eso sólo ocurrió después de que agotara todas las vías para contactar con la empresa(Follett Corporation) de forma privada, optando finalmente por una explosión bastante pública para identificarse a sí mismo y su capacidad para violar su sistema. Sus repetidos intentos de advertir éticamente a Follett Corporation quedaron sin respuesta, mientras que el software seguía siendo vulnerable y las montañas de datos de los estudiantes quedaban expuestas con bastante facilidad, ya que gran parte de ellos estaban sin encriptar.

También buscó fallos en el software de otra empresa: Blackboard. Aunque los datos de Blackboard al menos estaban encriptados, los posibles atacantes podrían haber accedido a millones de registros más. Tanto este software como el producto de Follett estaban en uso en su escuela.

La narrativa del "hacker malvado" es problemática.

Demirkapi presentó sus descubrimientos en la DEF CON de este año, y los detalles más traviesos de sus travesuras fueron aplaudidos por el público. Con razón, en realidad: aunque al principio estuvo en la picota y tuvo que enfrentarse a muchos obstáculos para que se reconocieran sus descubrimientos, se dice que Follett Corporation agradeció sus esfuerzos y siguió sus consejos, haciendo finalmente su software más seguro y evitando la crisis de convertirse en otra estadística de violación de datos. Además, después de terminar el bachillerato, asistirá al Instituto Tecnológico de Rochester, por lo que está claro que va por el buen camino para convertirse en un especialista en seguridad muy demandado.

Como persona que se dedica a la seguridad, es difícil no criticar la forma en que se manejó esta situación. Aunque en este caso todo acaba bien, al principio se le trató como un molesto script kiddie que metía las narices donde no debía. Si se busca el incidente en Google, hay artículos que se refieren a él como un "hacker" (en la mente del profano en seguridad, esto lo sitúa como el villano en muchos sentidos), cuando en realidad su enfoque (y el de muchos otros) es lo que ayuda a mantener nuestros datos seguros.

Necesitamos personas inquisitivas, inteligentes y centradas en la seguridad que miren bajo el capó, y necesitamos que esto ocurra mucho más a menudo. Hasta julio, más de cuatro mil millones de registros han sido expuestos en violaciones de datos maliciosas sólo este año. Se pueden añadir otros cincuenta millones a esta cifra, gracias a la filtración de agosto de la marca de moda y estilo de vida Poshmark.

Cometemos los mismos errores y, lo que es más preocupante, a menudo son simples vulnerabilidades que nos hacen caer en la trampa.

El cross-site scripting y la inyección SQL no han desaparecido.

Tal y como informa WIRED, Demirkapi ha descubierto que el software Blackboards Community Engagement y el sistema de información estudiantil Folletts contienen errores de seguridad comunes como el cross-site scripting (XSS) y la inyección SQL, que han sido pelos en la lengua de los especialistas en seguridad desde la década de 1990. Hemos soportado su existencia durante mucho tiempo, y al igual que las camisetas Hypercolor y los disquetes, ya deberían ser un recuerdo lejano.

Pero no lo son, y está claro que no hay suficientes desarrolladores que demuestren una concienciación de seguridad adecuada para detener la introducción de los mismos en su código. Las herramientas de escaneo y las revisiones manuales del código no pueden hacer mucho, y hay problemas de seguridad mucho más complejos que el XSS y la inyección SQL, en los que estas medidas costosas y que consumen mucho tiempo podrían utilizarse mejor.

Personas como Bill Demirkapi deberían inspirar a los desarrolladores a crear un estándar de código más alto; con tan sólo 17 años, violó dos sistemas de alto tráfico mediante vectores de amenaza que deberían haber sido detectados y corregidos antes de que el código fuera comprometido.

Gamificación: ¿La clave del compromiso?

He escrito mucho sobre por qué los desarrolladores siguen sin comprometerse con la seguridad, y la respuesta corta es que no se está haciendo mucho a nivel organizativo, ni educativo, para fomentar desarrolladores conscientes de la seguridad. Cuando las empresas se toman el tiempo necesario para crear una cultura de seguridad que recompense y reconozca el compromiso, incluyendo la implementación de una formación que hable el lenguaje de los desarrolladores y les motive a seguir intentándolo, estas molestas reliquias de vulnerabilidad empiezan a desaparecer del software que utilizamos.

Demirkapi obviamente tiene un interés extracurricular en la seguridad, y se ha tomado el tiempo para aprender cómo hacer ingeniería inversa de malware, detectar fallos y, bueno, romper cosas que no parecen rotas desde el exterior. Sin embargo, al hablar con VICE (y a través de sus diapositivas de la DEF CON), hizo una interesante declaración sobre su autoeducación... la gamificó:

"Con el objetivo de encontrar algo en el software de mi escuela, fue una forma divertida "gamificada de enseñarme a mí mismo una cantidad significativa de pruebas de penetración. Aunque empecé mi investigación con la intención de aprender más, acabé descubriendo que las cosas eran mucho peores de lo que esperaba", dijo.

Aunque no todos los desarrolladores van a querer especializarse en seguridad, cada uno de ellos debería tener la oportunidad de tomar conciencia de la seguridad, con los fundamentos que sirven casi como una "licencia para codificar" dentro de una organización, especialmente aquellos que controlan masas de nuestros datos sensibles. Si los agujeros de seguridad más simples pueden ser parcheados por todos los desarrolladores antes de que se escriban, estaremos en una posición mucho más segura contra aquellos que buscan causar estragos.

¿Tiene curiosidad por la formación gamificada? Consulte nuestra serie Coders Conquer Security sobre XSS y inyección SQL.

Aunque VxWorks no es exactamente un nombre familiar para el consumidor medio, este producto de software beneficia inevitablemente a muchas personas como usted y yo, todos los días. Al ser el sistema operativo en tiempo real (RTOS) más popular del mundo, es el caballo de batalla en el que (por delegación) confiamos para alimentar las redes y los cortafuegos de las empresas, las interfaces aeroespaciales, los equipos industriales e incluso algunos dispositivos médicos, por nombrar sólo algunas aplicaciones de su uso generalizado.

Y ahora, nos enfrentamos a la posibilidad de que cientos de millones, si no miles de millones, de estos dispositivos, estén ahora comprometidos con al menos once vulnerabilidades. El arquitecto jefe de seguridad de Wind River, Arlen Baker, ha rebatido la cifra en un artículo de SearchSecurity, revelando que el alcance exacto no está confirmado y no se cree que sea tan elevado. A pesar de ello, ya sabemos que las violaciones de datos y los ataques se producen constantemente, pero esto es de nivel superior: los fallos confirmados son relativamente fáciles de explotar, y muchos de ellos abren la puerta y permiten a los atacantes controlar los dispositivos de forma remota a través de la transmisión de paquetes de red.

Por supuesto, Wind River ha publicado una serie de correcciones y parches para los clientes y asociados afectados. El problema radica en el gran número de dispositivos que requieren la actualización del parche: al igual que Thanos acaba con el mundo con un chasquido de dedos, es inevitable que muchos dispositivos queden sin parchear, y por tanto vulnerables, durante mucho tiempo.

La empresa de seguridad Armis está detrás de este gigantesco descubrimiento, y ha bautizado sus hallazgos como URGENT/11. Lo han calificado de grave, sin duda debido a la facilidad de ataque desde múltiples vectores y al potencial de infección extensa. La creación y el despliegue de un gusano en el software que alimenta todo, desde los escáneres de resonancia magnética y los productos VOIP, hasta las redes ferroviarias y los semáforos, es totalmente posible.

¿Es el momento de entrar en pánico?

Como alguien que ha hecho de la concienciación sobre la seguridad una misión crítica en su vida, veo muchos problemas potenciales de seguridad en el día a día. Me pasaría la mayor parte del día en estado de histeria si me permitiera entrar en pánico demasiado (después de todo, prefiero dedicarme a la tarea de intentar educar y ayudar a solucionar los fallos). Sin embargo, el alcance del hallazgo URGENT/11 es bastante aterrador. De las once vulnerabilidades encontradas, seis se consideran críticas. Como identifica The Hacker News, estos fallos han existido en dispositivos que ejecutan VxWorks desde la versión 6.5 (excluyendo las versiones diseñadas para la certificación, incluyendo VxWorks 653 y VxWorks Cert Edition), lo que significa que una tecnología vital ha estado bajo la amenaza de ataques de toma de control de dispositivos desde hace más de una década. No todos los dispositivos son vulnerables a los once fallos (y algunos sólo pueden ser explotados si el atacante está en la misma subred LAB), pero incluso un hacker mediocre sólo necesita una pequeña ventana de oportunidad.

Es importante señalar que Wind River ha actuado rápidamente y ha proporcionado asesoramiento detallado para mitigar los problemas, al igual que Armis. Además, el RTOS VxWorks está tan extendido porque es muy fiable y tiene una alta puntuación en cuanto a normas de seguridad del software; normalmente, los cazadores de bugs no se preocupan demasiado por él. Sin embargo, las empresas de seguridad y Wind River no pueden hacer mucho para resolver el problema... está en manos del usuario final descargar los parches, prestar atención a los consejos de seguridad y fortificar sus propios dispositivos, y ahí es donde la cosa se complica.

Tal vez no sea necesario que cunda el pánico todavía, pero podría hacer falta un pueblo para someter a esta bestia.

Las vulnerabilidades URGENT/11 explicadas

En este punto, cualquier dispositivo conectado a la pila TCP/IP IPnet de VxWorks comprometida desde la versión 6.5 podría estar afectado por al menos uno de los URGENT/11. (Para ver la lista completa de CVEs de Wind River, consulte aquí).

En su mayoría, estas fallas permiten la ejecución remota de código (RCE) y ataques de denegación de servicio, con un par de ellos que conducen a la exposición de información y problemas de lógica de negocio también. La ejecución remota de código es un problema especialmente delicado en este caso, ya que un atacante puede asumir el control de un dispositivo sin la interacción del usuario final. Nadie tiene que hacer clic accidentalmente en algo sospechoso, descargar algo o introducir sus datos... esto hace que los dispositivos VxWorks sean altamente "gusanos" y que el ataque adquiera una vida propia automatizada. ¿Recuerdas el gusano WannaCry de EternalBlue? URGENT/11 tiene un potencial similar, aunque más devastador, para darnos un dolor de cabeza global.

¿Qué podemos hacer al respecto?

Pues bien, en el momento de escribir estas líneas, las consecuencias de URGENT/11 siguen siendo desconocidas. Los medios de comunicación han sensibilizado a la industria, y Wind River está proporcionando claramente apoyo a los afectados. Los próximos meses revelarán si algún atacante decide explotar estos fallos conocidos de manera significativa, pero mientras tanto, la solución obvia es prestar atención a la plétora de consejos y parchear cualquier dispositivo relevante en su órbita.

A largo plazo, sigue siendo la misma misión: todo el mundo tiene que mejorar en lo que respecta a la seguridad del software. Las CVEs URGENTES/11 son, en general, puertas traseras preocupantemente sencillas de atravesar, y el hecho de que hayan permanecido sin descubrir durante muchos años es un testimonio de que la preocupación y la concienciación general de la industria son bastante bajas.

Cada desarrollador tiene la oportunidad de hacer su parte, y necesita el apoyo para aprender a asegurar el código desde el principio de la producción. Los equipos influyentes que los rodean, desde AppSec hasta los directivos, pueden garantizar que una cultura de seguridad positiva prospere en todos los puntos de contacto del software dentro de la empresa.

¿Quiere poner a prueba su propia conciencia de seguridad? Nuestra plataforma gamificada puede ofrecerte retos de código reales similares a algunos de los descubiertos en URGENT/11. Compruébelo y vea cómo le va:

• Desbordamiento de heap en el análisis de DHCP Offer/ACK en ipdhcpc (CVE-2019-12257)
  Corrupción de memoria - Desbordamiento de Heap
• DoS de conexión TCP a través de opciones TCP malformadas (CVE-2019-12258)
  Protección insuficiente de la capa de transporte: transporte desprotegido de información sensible
• Fallo lógico en la asignación de IPv4 por el cliente DHCP ipdhcpc (CVE-2019-12264)
  Fallos de lógica empresarial
• DoS a través de una desviación NULL en el análisis de IGMP (CVE-2019-12259)
  Corrupción de memoria - Dereferencia nula
• Fuga de información IGMP a través del informe de pertenencia específico de IGMPv3 (CVE-2019-12265)
  Exposición de información - Exposición de datos sensibles

Una versión de este artículo apareció en DevOps.comy ha sido retitulado y actualizado para incluir nueva información.

Si bien los CISO y los CIO tienen la poco envidiable posición de asumir la parte del león de la responsabilidad de la seguridad del software, especialmente en el caso de una vergonzosa violación de los datos de la empresa, también se les ofrece una oportunidad única de creciente relevancia: son los nuevos innovadores, y pueden ser muy influyentes con el enfoque correcto. Todas las organizaciones del planeta, tanto públicas como comerciales, luchan por conservar (y ganar) su espacio en el mercado en un mundo que se digitaliza rápidamente. Los clientes esperan una experiencia en línea sin fisuras tanto de los productos pasados como de los futuros, y un enfoque empresarial "digital-first" se está convirtiendo en algo obligatorio. Al fin y al cabo, si no se cumplen estas expectativas, es casi seguro que habrá un competidor dispuesto a aprovechar la oportunidad.

Entonces, ¿qué significa esto para el CISO o CIO moderno? Naturalmente, significa que están empleando equipos de desarrolladores, cada uno de los cuales crea línea tras línea del código que forma su producto o servicio digital. La ciberseguridad, aunque ha sido una consideración principal durante muchos años, es un factor de riesgo creciente a medida que se realizan cada vez más operaciones empresariales en línea y en el punto de mira de los atacantes. Las implicaciones de una brecha son enormes, pero optar por la digitalización no es una opción.

Los CISOs y CIOs creativos están en una posición privilegiada para seguir forjando el camino de nuestros futuros digitales, junto con sus equipos de AppSec y de desarrollo. No cabe duda de que darán forma a la innovación a largo plazo de las empresas, los gobiernos y los servicios públicos en línea, pero tienen la gran responsabilidad de equilibrar los objetivos de rapidez de comercialización, la alta calidad del software y la mitigación de los riesgos de seguridad.

Este equilibrio ha sido, hasta la fecha, inmensamente difícil de alcanzar. Ha dado lugar a equipos de desarrollo que a menudo están fragmentados, con un enfoque principal general en la entrega de características y funciones, sin tener en cuenta las vulnerabilidades que podrían estar creando en el código que están produciendo tan rápidamente. Los especialistas en seguridad de las aplicaciones corrigen constantemente los mismos errores, mientras que la amenaza de una brecha por una puerta trasera relativamente sencilla que se deja abierta se cierne sobre ellos.

Si queremos que nuestros datos permanezcan seguros, los CISO y los CIO deben ser creativos con la forma en que sus equipos trabajan juntos, y forjar una cultura de seguridad positiva y responsabilidad compartida desde arriba hacia abajo. Basta con ver las catastróficas consecuencias a las que se enfrentó Marriott como resultado de su brecha de 2018: Una multa por el GDPR de más de 123 millones de dólares, más de 500 millones de registros robados y una reputación de seguridad en ruinas. Este desastre se produjo en gran parte como resultado directo de prácticas de codificación inseguras, con vulnerabilidades de inyección SQL descubiertas ya en 2014 en los servidores de Starwoods, una empresa adquirida por Marriott en 2016. Su uso posterior del software quedó claramente sin revisar desde la perspectiva de la seguridad de las aplicaciones. Esto dio a los atacantes maliciosos varios años para acceder y adquirir datos, mientras que otras vulnerabilidades, como las contraseñas débiles, dejaron más agujeros para explotar con el tiempo.

Los CIOs y CISOs necesitan considerar el estado de sus propios climas de seguridad de software muy cuidadosamente. ¿Cuánta conciencia de seguridad tiene el desarrollador medio? ¿En qué medida trabajan juntos los equipos de seguridad de aplicaciones y de desarrollo? No hay una solución "mágica", pero se puede trabajar y mejorar la cultura, la formación y el apoyo. Los equipos de desarrollo pueden pasar de ser la primera línea de riesgo de violación de datos en la organización, a ser los superhéroes de la seguridad que detienen el código malo antes de que pase a producción.

Comprobación de la salud de la codificación segura: ¿Está la suya con soporte vital?

¿Dónde encaja su propio equipo de desarrollo? He creado esta lista de comprobación de la codificación segura para ayudar a los CIO y CISO a identificar si sus equipos de desarrollo están realmente equipados para ser campeones de la codificación segura, ayudando a innovar con un código más rápido, mejor y más seguro (o, de hecho, si necesita una revisión del programa de seguridad):

1. ¿En qué medida le apoya el resto de su C-Suite? ¿Entienden que la seguridad tradicional de la red ya no es suficiente?

En el futuro del software, asegurar la capa de red utilizando medidas de seguridad anticuadas simplemente no es suficiente (y, seamos sinceros, rara vez tiene éxito de todos modos) incluso contra los hackers semiprofesionales. Entre muchos informes consistentes, el "2017 Data Breach Investigations Report" de Verizon cita que un asombroso 35 por ciento de las violaciones de datos hoy en día son causadas por vulnerabilidades de aplicaciones web.

La seguridad de las aplicaciones web es tan importante como la seguridad de la red; ignorar esto y no presupuestar e inculcar la capa de protección básica y fundamental de las medidas de AppSec podría dejarle muy expuesto a una brecha.

2. ¿Se desplaza lo suficientemente a la izquierda y lo hace con suficiente antelación?

El enfoque actual de la seguridad de las aplicaciones está bastante cargado de herramientas y se centra en ir de derecha a izquierda en el ciclo de vida del desarrollo de software (SDLC). Esto, por definición y diseño, reconoce que el proceso es defectuoso y apoya un resultado de detección y reacción. Los equipos de seguridad buscan y detectan vulnerabilidades en el código que ya está escrito, reaccionando para arreglar el código comprometido en lugar de asegurarse de que está libre de errores mientras se elabora. Según el Instituto Nacional de Estándares y Tecnología(NIST), es 30 veces más caro detectar y arreglar las vulner abilidades en el código comprometido que prevenirlas mientras se escriben en el IDE. Esto ni siquiera tiene en cuenta los retrasos en la producción, la doble manipulación y el tiempo empleado en remediar los mismos problemas de seguridad conocidos una y otra vez.

Una cultura de seguridad verdaderamente sólida insiste en empezar por la izquierda, inspirando a los campeones de la seguridad dentro de la cohorte de desarrolladores, al tiempo que da al equipo de desarrollo las herramientas y la formación adecuadas para crecer y actuar con una mentalidad de codificación segura. Hay un enfoque en el auto-desarrollo continuo, y la flexión de sus músculos de resolución de problemas para que puedan ser la primera línea de defensa en su organización, evitando que las vulnerabilidades comunes se produzcan en primer lugar.

3. ¿Se está esforzando por desarrollar habilidades prácticas de seguridad, o se limita a alimentar el conocimiento en un solo sentido?

La gran mayoría de las soluciones de formación en seguridad (online y CBT) se centran en la creación de conocimientos en lugar de habilidades prácticas que se relacionan directamente con sus trabajos. Para que los desarrolladores prosperen y se dediquen a escribir código seguro, necesitan tener acceso regular a un aprendizaje contextual y práctico que les anime activamente a seguir formándose y desarrollando sus habilidades en un entorno real. Necesitan aprender sobre las vulnerabilidades recientemente identificadas, con ejemplos de código real, y poder trabajar en sus lenguajes y marcos de trabajo preferidos. Esta experiencia de aprendizaje es eficaz para ayudarles a comprender cómo localizar, identificar y corregir las vulnerabilidades conocidas en el código en el que trabajan activamente en el curso de sus trabajos.

Aunque hay muchos profesores con conocimientos y mucha información sobre cómo solucionar las vulnerabilidades de seguridad, hojear libros de texto o ver horas de vídeo no consigue captar la mente de muchos desarrolladores creativos y resolutivos, y si el flujo constante de filtraciones de datos es una indicación, sigue siendo en gran medida ineficaz para evitar que las vulnerabilidades entren en el código.

4. ¿Estás midiendo tus habilidades de codificación segura con métricas en tiempo real?

Un paso fundamental para garantizar que el equipo de desarrollo adopte una mentalidad que dé prioridad a la seguridad es recopilar y revisar las pruebas. Esto no debe ser una suposición o un juego de adivinanzas: los desarrolladores tienen una mentalidad de seguridad o no la tienen.

Las métricas pretenden demostrar al desarrollador y a su organización que su duro trabajo está dando sus frutos, y que sus habilidades individuales de codificación segura están mejorando. No se puede mejorar lo que no se puede medir. Debe haber evaluaciones pertinentes, y estas deben ayudar a identificar el progreso de sus equipos de desarrollo en tiempo real, así como a comparar sus puntos fuertes y débiles en materia de codificación segura para una mejora continua.

Con demasiada frecuencia, la formación en materia de seguridad se convierte en un ejercicio de "marcar la casilla" para las organizaciones, sin hacer hincapié en garantizar que esta formación ha sido eficaz, que se ha comprometido con ella o incluso que la ha retenido.

5. ¿Sus proveedores subcontratados utilizan técnicas sólidas de codificación segura?

Muchas organizaciones deciden contratar el trabajo de desarrollo a agencias de terceros. Tanto si existen en el país como en el extranjero, sus capacidades y prácticas generales de codificación segura son un relativo misterio para su cliente. En el mejor de los casos, la única forma de garantía que recibirá una organización en relación con la seguridad es una declaración en el contrato que exige que el producto final sea "seguro". Muy pocas empresas toman medidas para verificar las habilidades de estas empresas de desarrollo por adelantado, por lo que corren el riesgo de que se les entregue un software que funcione tal y como se les informó, pero que ha sido construido sin seguir prácticas de codificación seguras. Peor aún, si la empresa compradora no es consciente de los fallos de seguridad inherentes a la aplicación, se arriesga a enviar un software vulnerable.

El escenario más común es que cualquier vulnerabilidad sea detectada por especialistas en seguridad dedicados (individuos que son difíciles de encontrar y que tienen un alto coste), usted se enfrenta a un retraso en la fecha de puesta en marcha, y a posibles discusiones contractuales sobre quién tiene que pagar por arreglar estas debilidades de seguridad. Sin embargo, si es inteligente por adelantado y evalúa las habilidades de seguridad de la aplicación de los desarrolladores que van a construir su próxima aplicación, se ahorrará muchos retrasos potenciales, frustración y dinero.

6. ¿Sus desarrolladores conocen los puntos débiles de seguridad más comúnmente explotados?

Más del 85 por ciento de las vulnerabilidades de las aplicaciones web explotadas se atribuyen a sólo 10 vulnerabilidades conocidas "las 10 principales de OWASP". Como mínimo, la formación en seguridad de sus aplicaciones debe cubrirlas, además de muchos otros tipos de vulnerabilidades. Los retos de formación a los que se enfrentan sus desarrolladores deben ser revisados y actualizados regularmente, con nuevos retos para nuevos marcos de codificación o nuevos tipos de vulnerabilidad.

La formación de precisión utilizando escenarios de codificación segura del mundo real debería ser la norma; un conocimiento general vago simplemente no es eficaz. (¿Se pregunta cómo podrían ser estos escenarios de codificación segura? Echa un vistazo a nuestra serie de blogs Coders Conquer Security; hay un reto jugable en cada entrada).

7. ¿Dispone de campeones de seguridad internos?

Todas las organizaciones con gran número de desarrolladores deberían invertir en un campeón de seguridad: alguien que se responsabilice de mantener un alto nivel de seguridad dentro del equipo de desarrollo. Su propósito es ser un punto de contacto de apoyo para cualquier persona que tenga preguntas sobre la seguridad, así como convertirse en el principal defensor de seguir las mejores prácticas de seguridad.

Son una pieza vital del rompecabezas de la cultura de la seguridad; un gran campeón de la seguridad puede mantener el impulso de la formación intensiva, asegurarse de que todos los miembros del equipo tienen lo que necesitan y seguir abogando por el apoyo.

8. ¿Ha invertido en herramientas para que sus desarrolladores faciliten la codificación segura?

Si en su organización se practica el desarrollo ágil, o de hecho se enfrenta a frecuentes actualizaciones de las aplicaciones creadas por la empresa, la automatización de partes de la seguridad es una de las únicas formas de seguir el ritmo frenético y el volumen de trabajo.

Hay herramientas disponibles en cada etapa del SDLC que servirán como asesores, guardianes de la calidad o herramientas de detección. Además, algunas herramientas ejecutan pruebas automatizadas sobre el código, simulando intentos de piratería una vez que el software está en producción. Todas tienen sus propias ventajas y dificultades, y ninguna puede garantizar al cien por cien que no existan amenazas de seguridad en la aplicación. La principal medida preventiva que se puede emplear es que cuanto antes se pueda detectar el punto débil, más rápido y barato será remediarlo con el menor impacto posible en la empresa.

El siguiente paso para los CISO con visión de futuro

¿Qué tal le fue a su organización con respecto a la lista de control anterior?

Si bien los CISO y los CIO se ven obligados a desarrollar de forma agresiva sus capacidades empresariales de DevOps y DecSecOps, eso no significa que no haya tiempo para considerar e implementar las herramientas y la formación adecuadas en todos los equipos. Las habilidades de codificación segura serán un arma -no un obstáculo- para la innovación, y renunciar a ellas podría significar la destrucción absoluta de la reputación y los datos de la empresa. Estas habilidades representan capacidades críticas y una solución mucho más barata a largo plazo para reducir las vulnerabilidades y mitigar el riesgo.

Un CISO brillante e innovador tiene el poder de orquestar una cultura de seguridad saludable desde arriba hacia abajo; asegúrese de que su personal tiene lo que necesita para ejecutar las mejores prácticas de seguridad con eficacia.

Pieter Danhieux es un experto en seguridad y el cofundador de Secure Code Warrior.

Una versión de este artículo se publicó originalmente en Revista Digital Transactions.

Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo este proceso ha cambiado con el tiempo, lo que requiere un replanteamiento de las normas de seguridad que se establecieron mucho antes de que la mayoría de nuestras vidas se digitalizaran rápidamente.

Esto es una prueba clara de que nuestro sector se compromete más con la idea de unas directrices adaptables -que evolucionan con nuestras necesidades cambiantes-, así como con las exigencias de un panorama de ciberseguridad que podría salirse rápidamente de control si seguimos siendo poco estrictos en nuestros procesos de desarrollo seguros. Naturalmente, el Consejo de Normas de Seguridad de la Industria de la Tarjeta de Pago (PCI), que actúa como organismo rector del sector bancario y financiero (es decir, establece las normas de seguridad del software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y en los puntos de venta), conlleva un gran riesgo y tiene una enorme motivación para reducirlo.

Aunque estas normas mejoran sin duda la versión anterior y contribuyen en cierta medida a tapar el agujero que tenemos en el desarrollo de funciones rápidas e innovadoras que también dan prioridad a la seguridad como parte de su calidad general assessment, es una realidad algo decepcionante comprobar que aún nos queda mucho camino por recorrer.

No, no soy yo quien da un "¡bah, humbug!" a esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos hacen avanzar lo suficiente hacia la izquierda.

Seguían obsesionados con las pruebas (y las hacían demasiado tarde).

Un problema evidente que encontré en el Marco de Normas de Seguridad de la PCI es su aparente dependencia de las pruebas. Por supuesto, el software debe seguir siendo probado (y el proceso SAST/DAST/IAST sigue teniendo su lugar), pero seguimos cayendo en la misma trampa y esperando un resultado diferente.

¿Quién escribe línea tras línea de código para crear el software que conocemos, amamos y en el que confiamos? Los desarrolladores de software.

¿Quién tiene la poco envidiable posición de probar este código, ya sea con herramientas de escaneo o con la revisión manual del código? Los especialistas en seguridad de las aplicaciones.

¿Qué siguen descubriendo estos especialistas? Los mismos fallos que nos han perseguido durante décadas. Cosas sencillas que hemos sabido arreglar durante años: Inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el día de la marmota para estos tipos. Pasaron su tiempo encontrando y arreglando violaciones de código que los propios desarrolladores han tenido el poder de arreglar durante años, excepto que la seguridad no se ha convertido en una prioridad en su proceso " especialmente ahora, en la era del desarrollo ágil donde la entrega de características es el rey, y la seguridad es el Grinch que roba el proceso creativo y el triunfo de la finalización del proyecto.

No se trata de un comentario negativo en assessment sobre ninguno de los dos equipos; tanto los desarrolladores como los profesionales de la seguridad de las aplicaciones tienen un trabajo extremadamente importante que hacer, pero siguen entorpeciendo el camino del otro. Esta situación sólo perpetúa un SDLC defectuoso, en el que los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro, que luego tiene que ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. El departamento de seguridad de las aplicaciones apenas tiene tiempo para arreglar los problemas verdaderamente complejos, porque está muy ocupado con los pequeños problemas recurrentes que podrían suponer un desastre para la empresa si no se controlan.

Estamos perdiendo tiempo, dinero y recursos al permitir que las pruebas sean el cajón de sastre para las debilidades de seguridad en el código. Y con las violaciones masivas de datos cada dos días, es evidente que este método no funciona de forma óptima, si es que lo hace. Estas nuevas normas siguen evaluando el estado de un producto final (quizás suponiendo que todos los desarrolladores son conscientes de la seguridad, lo que no es el caso): es decir, uno que ya está construido. Esta es la etapa más cara y difícil de corregir los defectos; es como construir una casa nueva y lujosa, sólo para traer un equipo de seguridad para comprobar cualquier peligro el mismo día que te mudas. Si algo va mal en los cimientos, imagínese el tiempo, el coste y el enorme dolor de cabeza que supone llegar a esa zona para empezar a solucionar los problemas. A menudo es más fácil y más barato simplemente empezar de nuevo (y qué proceso más insatisfactorio es ese para todos los que construyeron la primera versión).

Debemos trabajar absolutamente desde la base: haciendo que el equipo de desarrollo se comprometa con las mejores prácticas de seguridad, dándoles los conocimientos necesarios para codificar eficazmente de forma segura, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.

¿Es una curva de aprendizaje? Claro que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser un trabajo aburrido. Los métodos de formación que apelan directamente a los rasgos creativos y de resolución de problemas de los desarrolladores ya han tenido un inmenso éxito en el sector bancario y financiero, si la experiencia de Russ Wolfes en Capital One sirve de indicación.

Todavía estamos buscando el "estado final" perfecto.

Si se consideran las normas de seguridad de la PCI actualizadas en el contexto para el que fueron concebidas, es decir, si su producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para lograr una seguridad óptima, entonces están absolutamente bien. Sin embargo, en mi opinión, todas las empresas -financieras o de otro tipo- tendrían la mejor oportunidad de alcanzar un estado final del software que sea representativo tanto de la calidad de las características como de un alto nivel de seguridad, si dieran un paso atrás y se dieran cuenta de que es mucho más eficiente hacerlo desde el principio del ciclo.

¿Ese estado final perfecto? Ya sabe, ¿el que se produce cuando un producto se escanea, se revisa manualmente y sale perfecto y sin errores? Todavía lo estamos buscando. En este momento, es un unicornio.

¿Por qué es tan difícil de alcanzar? Hay varios factores:

• Se confía en las herramientas de escaneo, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y que hace perder tiempo, al igual que el hecho de que incluso juntos, los escaneos DAST/SAST/PCI simplemente no pueden identificar y revelar todas las posibles vulnerabilidades en la base de código. Claro que pueden dar el visto bueno, pero ¿realmente buscan todo? Un atacante sólo necesita explotar una vulnerabilidad para acceder a algo que crees que está protegido.
• Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos entre los desarrolladores en torno a la seguridad y no hay "recetas de código seguro" (patrones de código buenos y seguros) que sean conocidos y estén documentados.
• No se hace hincapié en la creación de una cultura de seguridad positiva y de colaboración.
• Los desarrolladores necesitan contar con las herramientas adecuadas para incorporar la seguridad a los productos que escriben, sin interrumpir sus procesos creativos y metodologías de desarrollo ágiles.

Estas directrices son una poderosa lista de verificación de las normas de seguridad que debe cumplir el software, pero el mejor proceso para conseguir que el software llegue a ese estado es objeto de debate.

No tenemos software inseguro porque nos falten escáneres, tenemos software inseguro porque los desarrolladores no disponen de herramientas de seguridad fáciles de usar y de entender que les sirvan de guía.

Ahora mismo estamos en una época de evolución. La seguridad del software en general, durante muchos años, era opcional. Hoy en día, es esencialmente obligatoria, sobre todo para los guardianes de la información sensible (financiera, médica, de la seguridad social... ya te haces una idea).

El PCI Security Standards Council está ayudando a establecer el punto de referencia, pero me encantaría verles -con toda su estima e influencia en la industria- trabajar para incluir directrices prácticas para los desarrolladores, haciendo hincapié en una formación y unas herramientas adecuadas y positivas. Por el momento, no hay presión para que las organizaciones se aseguren de que sus equipos de desarrollo sean conscientes de la seguridad y la cumplan, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de arreglar, cuando son explotados por quienes buscan hacer daño.

Como es de esperar con cualquier cosa que valga la pena en la vida, realmente se necesita una aldea para promulgar un verdadero cambio. Y el cambio en el aire va a arrastrarnos (esperemos) a todos hacia la izquierda.

Parece casi cómico que en 2019 estemos hablando de trabajar con un lenguaje informático que se inventó en 1959. Hoy en día no hay demasiados seminarios o convenciones dedicados al arte de volver a enhebrar máquinas de coser Singer clásicas, o a cambiar el cárter de aceite de una Chevrolet Parkwood o una Triumph Herald. La mayoría de esas viejas herramientas hace tiempo que se jubilaron y se actualizaron con modelos nuevos y más eficientes. Sin embargo, aquí, en el país de la tecnología, que se supone que está a la vanguardia en comparación con otras industrias, seguimos trabajando con lenguajes como el COBOL, que salió al mercado por la misma época.

Por supuesto, hay muy buenas razones para ello. Puede que el Lenguaje Común Orientado a los Negocios (COBOL) tenga 60 años, pero estaba tan bien construido que sigue siendo relevante y de uso generalizado en la actualidad.

COBOL se creó como una forma relativamente sencilla, utilizando un lenguaje sencillo agrupado en frases y sintaxis específicas, de programar sistemas de fondo para realizar tareas matemáticas y fórmulas. ¿Por qué sigue existiendo hoy en día? Sencillamente, porque es muy bueno en su trabajo. En cierto sentido, se ha convertido en parte del tejido informático de muchos sistemas mainframe y core en industrias tan diversas como el sector financiero y la fabricación.

A lo largo de los años se han producido actualizaciones graduales de COBOL, sobre todo en 2002, cuando se convirtió en un lenguaje orientado a objetos para que la programación de nuevas aplicaciones fuera un poco más fluida. Pero, en su mayor parte, COBOL sigue siendo lo que era entonces: un héroe olvidado y un lenguaje de programación que funciona en el back-end para sustentar muchas aplicaciones modernas a nivel de mainframe.

¿Cómo de seguro es COBOL?

Desafortunadamente, no había mucho en el camino de las consideraciones de seguridad cuando COBOL fue creado por primera vez. Por ejemplo, muchas aplicaciones COBOL tienen un programa de contraseñas que las protege, pero casi nunca están reforzadas contra cosas como la protección de fuerza bruta para evitar el cracking. Si unimos esto al hecho de que muchas herramientas de seguridad modernas que supervisan el tráfico de la red no saben cómo tratar o evaluar las funciones que se producen dentro de los programas escritos en lenguajes empresariales como COBOL, tenemos un verdadero problema a punto de producirse. Un buen número de infracciones modernas han tenido éxito debido a la falta de supervisión de la seguridad de los sistemas que ejecutan lenguajes informáticos clásicos. En 2015, los datos de más de cuatro millones de empleados federales estadounidenses quedaron expuestos cuando la Oficina de Gestión de Personal (OPM) fue hackeada, y la culpa recayó en su uso de COBOL, citando la incapacidad de implementar medidas de seguridad modernas en un sistema tan arcaico.

Hace años, la seguridad corría a cargo de un ejército de programadores que conocían COBOL y otros lenguajes de moda de la época. En los años sesenta, COBOL era como el Java o el .Net de hoy, y los que lo conocían eran las estrellas del rock de sus departamentos. En 2019, es probable que esas personas se hayan retirado hace tiempo, aunque los sistemas que protegían no lo hayan hecho.

Ampliación de la primera línea de defensa de COBOL

Algunos de los llamados "barbas grises" volvieron a sus organizaciones como contratistas para defender los mismos mainframes en los que trabajaban antes. En más de un lugar, existían como una especie de anomalía: una cábala secreta de hechiceros envejecidos en algún rincón de la oficina, con su extraña vestimenta (corbatas anchas y trajes de tres piezas) y sus modales extrañamente educados que no encajaban con todos los modernos hipsters que lucían vaqueros ajustados y moños. Sin embargo, eran absolutamente necesarios, porque pocos programadores modernos escriben código en COBOL y otros lenguajes antiguos. Lamentablemente, incluso estos últimos centinelas de la magia se están desvaneciendo, y finalmente han renunciado al fantasma y se han trasladado a Boca Ratón, disfrutando de una verdadera jubilación.

Por lo tanto, hay una gran necesidad de personas que entiendan los lenguajes antiguos y las vulnerabilidades de seguridad que contienen. Incluso si los más jóvenes no saben escribir código en lenguajes clásicos, deberían al menos entender cómo funcionan y sus posibles vulnerabilidades. Porque mientras el desarrollo de COBOL ha permanecido relativamente estático, las amenazas que se ciernen sobre las redes han seguido evolucionando. Tratar de utilizar antiguas técnicas de ciberseguridad programadas hace sesenta años, como la mencionada aplicación de contraseñas COBOL, para defender un mainframe contra los atacantes modernos es como desplegar una falange de lanceros para luchar contra un pelotón de marines espaciales: si no se produce un milagro al estilo de Hollywood, la cosa acabará mal para los tipos de las lanzas.

No importa si es viejo o nuevo, también debe ser seguro.

Por eso creemos en la importancia de un sistema de formación avanzado que cubra una amplia gama de lenguajes y marcos de programación. Verás, uno de los problemas más evidentes de muchas opciones de formación en seguridad es que la información es simplemente demasiado genérica, o peor, completamente irrelevante en el trabajo diario del desarrollador que participa en ella. Pasar medio día aprendiendo sobre vulnerabilidades que sólo se aplican a Java no va a ayudar a un desarrollador de COBOL a fortificar su sistema, y sólo perpetúa la idea de la "seguridad" como un ejercicio de marcar la casilla para olvidarse de ella una vez que se ha completado el curso obligatorio. Podría añadir que formar a alguien en los fallos de seguridad de Java no siempre es aplicable para un desarrollador de Java Spring. La codificación segura es simplemente diferente en cada lenguaje, incluso hasta el nivel de framework.

En nuestra misión de capacitar a todos los desarrolladores para que se conviertan en superhéroes de la seguridad, no vamos a pasar por alto un lenguaje informático válido que todavía se utiliza en algunas de las instalaciones más específicas y críticas del mundo. Al explorar nuestra plataforma, encontrará retos y formación modernos y prácticos relacionados con COBOL que se ofrecen junto con algunas de las herramientas de programación más modernas disponibles en la actualidad, como Googles Golang. Esta flexibilidad garantiza que la formación sea relevante para un individuo y contextual, imitando su entorno de trabajo para lograr el máximo compromiso y eficacia. Después de todo, la creación de una cultura de seguridad sólida es primordial en la lucha contra las ciberamenazas, por lo que la formación debe ser práctica (y divertida, por supuesto).

Queremos que nuestro sector llegue a la fase en la que no importe si las amenazas a la seguridad se producen contra sistemas que ejecutan lenguajes antiguos o contra las aplicaciones de movilidad más modernas. Queremos que todos los desarrolladores estén armados con la mejor información sobre esas vulnerabilidades, las herramientas y técnicas que utilizan los atacantes para explotarlas y cómo detenerlas en frío. Nunca nos rendiremos ni claudicaremos ante las amenazas de ciberseguridad. No importa lo modernas que sean las amenazas o las vulnerabilidades, siempre se puede recurrir a Secure Code Warrior para aprender a derrotarlas, siempre.

PD: ¿Cree que un lenguaje antiguo escapa a la susceptibilidad de la inyección SQL? Piénselo de nuevo. Vea si puede localizar y arreglar una en COBOL ahora mismo.

Publicado originalmente en La era de la información. Esta es una versión actualizada que corrige el posicionamiento en torno al soporte de seguridad actual de Wind River Systems para su producto de sistema operativo en tiempo real, VxWorks.

Un informe reciente del Centro de Evaluación de Ciberseguridad de Huawei del Reino Unido identificó importantes problemas de seguridad dentro de los procesos de ingeniería de software de Huawei. Aunque gran parte de las noticias sobre este informe crítico se centran en los problemas no resueltos del año anterior, el problema más peligroso y que se pasa por alto es la clara falta de directrices y prácticas de codificación seguras empleadas por Huawei. Pero es un problema que puede solucionarse.

Las noticias, para el gigante chino de las telecomunicaciones Huawei, siguen empeorando. Mientras que Estados Unidos ha prohibido rotundamente que la empresa trabaje en el futuro para el gobierno, el Reino Unido ha aceptado mejor el hecho de que muchos de los fallos subyacentes en los dispositivos y el código de Huawei son corregibles. El Reino Unido creó en 2010 el Centro de Evaluación de la Ciberseguridad de Huawei (HCSEC) para evaluar y abordar los problemas de seguridad de los productos de Huawei, y elaborar un informe anual sobre ellos. Sin embargo, este año el informe ha sido especialmente condenatorio.

Gran parte de la atención sobre el informe HCSEC de 2019 en las noticias ha estado relacionada con el hecho de que casi no se ha abordado ningún fallo de seguridad del año anterior. Esto incluye el uso de una versión más antigua del sistema operativo en tiempo real VxWorks de Wind River que pronto llegará al final de su vida útil. Huawei ha prometido arreglar ese problema (y recibirá apoyo continuo de Wind River Systems), pero sigue siendo un componente básico en gran parte de la infraestructura de telecomunicaciones del Reino Unido.

Un factor crítico que parece haber sido pasado por alto por la mayor parte de la prensa generalista consiste en lo que podría ser un proceso fundamentalmente roto, existente dentro del desarrollo y despliegue de nuevo software y hardware de la compañía. El informe señala "problemas técnicos significativos" en la forma en que Huawei maneja sus métodos de ingeniería interna.

Veamos algunos ejemplos de esos problemas técnicos señalados en el informe. Hay que decir que una de las mejores cosas que ha hecho Huawei ha sido crear unas directrices de codificación segura para ayudar a sus ingenieros y programadores a desplegar nuevo código. Esas directrices abarcan una amplia gama de buenas prácticas, como el uso de versiones seguras conocidas de funciones y procesos del sistema procedentes de bibliotecas de confianza y, desde luego, no de variantes con alguna vulnerabilidad conocida. En teoría, es algo estupendo, pero una evaluación en el mundo real de un sistema de producción de Huawei en el Reino Unido descubrió que esas directrices nunca se comunicaban a los programadores, eran ignoradas por ellos o simplemente no se aplicaban.

El informe examinó funciones específicas de manejo de memoria dentro de aplicaciones de cara al público, en este caso un conjunto de tableros de mensajes donde se invitaba a los usuarios, como función del programa, a añadir entradas. Dado que las áreas de entrada de los usuarios nunca deben ser tratadas como "de confianza", se esperaba que esas áreas contuvieran sólo código seguro, según las directrices internas de Huawei. En concreto, los encargados de las pruebas examinaron la invocación directa de las funciones de manejo de memoria memcpy(), strcpy() y sprintf() dentro de esos sistemas de producción, conocidas por provocar potencialmente graves problemas de seguridad como el desbordamiento del búfer desde 1988.

Sorprendentemente, hubo 5.000 invocaciones directas de 17 funciones seguras conocidas de memcpy(), pero también 600 usos de 12 variantes inseguras. La proporción es prácticamente la misma con las demás funciones. Hubo 1.400 invocaciones seguras de strcpy(), pero también 400 malas con vulnerabilidades conocidas. Y se encontraron 2.000 usos seguros de sprintf() frente a 200 inseguros. Aunque es bueno que la mayoría de los usos de esas funciones fueran seguros, eso sigue dejando un 20% del código total vulnerable a ataques conocidos. Se trata de una enorme superficie de ataque, y además sólo tiene en cuenta las invocaciones directas de las tres funciones de manejo de memoria, no los casos de su uso indirecto a través de punteros de función. Aunque los auditores sólo examinaron esas funciones específicas, es poco probable que las tres funciones de manejo de memoria elegidas sean las únicas con problemas.

Aunque es bueno que Huawei haya creado una guía de buenas prácticas para sus programadores, está claro que hay que hacer más. Es un paso para definir las expectativas de seguridad, pero sólo son efectivas si esas directrices se siguen activamente y son conocidas por la cohorte de desarrollo. Huawei podría dar pasos importantes en la mejora de su seguridad comprometiéndose a formar a sus programadores de forma eficaz, y no limitándose a dar las nociones básicas sobre cómo seguir sus directrices internas de Huawei. Deben dar un paso más para demostrar cómo codificar de forma más segura en general. Los programadores deben recibir una formación suficiente sobre los patrones de codificación buenos (seguros) y malos (inseguros) y tener la responsabilidad de practicar lo que su empresa predica, en todo momento.

Muchos de los problemas específicos de codificación señalados en el informe HCSEC se abordan y se aplican como parte de la Secure Code Warrior que capacita a los programadores y a los equipos de ciberseguridad para desplegar y mantener siempre un código seguro. Conceptos como no confiar nunca en la entrada del usuario, extraer siempre funciones de bibliotecas establecidas, sanear toda la entrada antes de pasarla a un servidor y muchas otras prácticas de codificación seguras se demuestran constantemente dentro de la plataforma. También se analizan vulnerabilidades muy específicas y se muestra, paso a paso, cómo evitarlas y mitigarlas.

Además de la formación especializada, las empresas como Huawei podrían hacer uso de las soluciones DevSecOps. Estas soluciones añaden formación en tiempo real directamente en el IDE, utilizando recetas de codificación seguras que se adaptan a las directrices de seguridad de la empresa, actuando como el ayudante del desarrollador en la "cocina" de la codificación mientras escribe su código. Este enfoque podría ayudar a los programadores de Huawei de todos los niveles de habilidad a escribir mejor el código y reconocer las posibles vulnerabilidades, al tiempo que permite a los expertos en seguridad de Huawei crear un "libro de cocina" de recetas que se adhieren a sus políticas y ayudan a ejecutar los comandos.

Una lección fundamental de los problemas de Huawei debería ser que la creación de directrices de codificación segura no tiene sentido si los programadores no las conocen, o simplemente no saben cómo seguir las buenas prácticas de codificación. En este caso, las directrices de buenas prácticas internas resultaron ser el propio zhilaohu de Huawei; lo que en Occidente se llamaría "un tigre de papel". Era un documento con mucho estilo, pero sin sustancia. Para dotarlo de un contenido real se necesitarían las herramientas prácticas adecuadas y un programa de formación real, que adoptara un enfoque práctico y creara conocimientos y habilidades continuas.