¿Qué necesitan los desarrolladores de un entrenamiento de Codificación Segura?

Comparte este artículo

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp

Los desarrolladores están ansiosos por conocimiento, especialmente cuando se trata de aprender a escribir código seguro por diseño.

Sin embargo, carecen de las habilidades necesarias para realizar este trabajo correctamente, ya que a menudo los piratas informáticos tienen la ventaja del tiempo.

La capacitación en seguridad es generalmente una operación de baja prioridad, aunque se espera que los desarrolladores y DevOps sean totalmente compatibles y estén al tanto de cómo escribir aplicaciones seguras.

Sin embargo, no tiene por qué ser así, ya que cada vez más organizaciones reconocen la importancia de la formación en codificación segura; especialmente cuando hay tanta demanda.

Sigue leyendo para conocer algunas opiniones personales sobre cómo la formación en codificación segura representa una experiencia valiosa y profunda para los desarrolladores.

Publicar Software Seguro

La opinión personal e informada del autor es que el software inseguro no solo es impráctico, sino también dañino. Los desarrolladores deben utilizar lo mejor de sus habilidades y conocimientos disponibles para ofrecer productos seguros.

Si consideran que carecen de las habilidades o la capacitación necesarias para lograr esos objetivos básicos, entonces deben tener acceso a la capacitación y el apoyo de expertos de la industria.

Deben estar completamente habilitados para evitar liberaciones o fallas de seguridad no reveladas en los servicios restantes.

Si son conscientes de que no están capacitados (o están insuficientemente capacitados) para cumplir con esta responsabilidad, esencialmente están exponiendo a la organización al riesgo de manera constante y consciente.

Pero, ¿qué constituye un software inseguro y cómo pueden los desarrolladores adquirir las habilidades necesarias para poder eevitarlo?

El software inseguro es ese tipo de software que tiene principalmente formas obvias y menos obvias pero factibles de explotar.

Dadas esas formas explotables, no hay formas alternativas o separadas de evitar que los actores malintencionados provoquen daños catastróficos, pérdidas de información financiera o confidencial o eventos que pongan en peligro la vida.

El software inseguro es realmente fácil de producir, por lo que existe una necesidad aún mayor de que los desarrolladores comprendan que deben pecar de cautelosos.

Si eres un desarrollador, aquí hay algunas recomendaciones personales sobre las formas en que puede cubrir las necesidades de los fundamentos de la codificación segura.

Y la mejor parte es que no perderás mucha velocidad al ofrecer nuevas funciones a los clientes, incluso dentro de los plazos de entrega.

A continuación, se muestra una lista de recomendaciones personales para un entorno de codificación seguro básico:

  • Uso de frameworks de seguridad auditados: el uso de marcos estándar de la industria como Ruby On Rails puede ayudarte a escribir software seguro por diseño. Esto se debe a que muchas organizaciones utilizan esos frameworks. Por lo tanto, muchos hackers intentan explotarlos o encontrar formas de romper sus defensas, lo que lleva a que las vulnerabilidades se solucionen tan pronto como se descubren. El uso de un framework estándar de la industria ayuda a los desarrolladores a evitar los mecanismos de seguridad básicos, ya que están integrados. Naturalmente, de vez en cuando el framework llega a producir código inseguro; por ejemplo, React dangerouslySetInnerHTML. Pero esos casos están bastante documentados y son bien conocidos.
  • Uso de bibliotecas criptográficas examinadas: hay un dicho conocido en la ingeniería de software: “No utilices tu propia biblioteca criptográfica”. Esta es la decisión más racional que debe tomar constantemente como desarrollador. La verdad real es que incluso para requisitos simples, la criptografía es desesperadamente difícil de hacer correctamente de forma predeterminada. Si lanzas tus propias bibliotecas de cifrado, siempre expones tu software a riesgos. Afortunadamente, hay varias bibliotecas de cifrado buenas y seguras disponibles, como libsodium o Bouncy Castle. Seguir esta recomendación evitará que expongas tu aplicación a fallas de implementación.
  • Realización de revisiones de seguridad periódicas: por último, deberás realizar revisiones de seguridad externas de tu aplicación con regularidad. Esto se debe a que esas revisiones expondrán con frecuencia fallos y consideraciones de seguridad inusuales. A medida que se exponen más y más vulnerabilidades cada día, los piratas informáticos pueden aprovecharlas de más formas. Por lo tanto, tener esas revisiones en su lugar reduce en gran medida las posibilidades de inseguridad.

Incluso con la presencia de estos frameworks y revisiones, los incidentes de seguridad aún ocurren a intervalos regulares. La razón principal por la que esto sucede es la falta de conocimiento de las prácticas de implementación inseguras al desarrollar software. Para mitigar esos escenarios, los equipos de desarrolladores, deben asistir a sesiones de capacitación más profundas y atractivas a lo largo de sus horas de operación. Proponemos el siguiente itinerario formativo ideal para llenar este vacío.

Pequeñas victorias Vs Éxitos puntuales

Si participaste en sesiones de capacitación sobre codificación segura como parte de Compliance, puedes comprender lo tediosas que pueden ser.

En un caso de mi experiencia, tuve que leer presentaciones fechadas sobre codificación segura, todo de una vez, de principio a fin.

Las preguntas de opción múltiple al final de la sesión fueron escritas para engañarlo en lugar de desafiar sus conocimientos. Cuando finalmente terminé este entrenamiento, me alegré de no tener que volver a hacerlo.

Este entrenamiento para marcar la casilla de la lista no solo es engañoso, sino también peligroso. ¿Podemos hacerlo mejor? Sí, mediante la realización de lecciones interactivas pequeñas y breves en lugar de extensas y tediosas.

De esa manera, obtienes pequeñas ganancias y las conviertes en recompensas más sustanciales. Por ejemplo, en lugar de navegar a través de una larga lista de diapositivas tratando de comprender XSS, sería mejor que trabajara con un marco de su elección como Django o Rails para resolver pequeños desafíos.

Al mismo tiempo, está aprendiendo las formas generales de defenderse de las vulnerabilidades XSS. De esa manera, la experiencia de aprendizaje es más atractiva, interesante, relevante y fructífera.

Conciencia organizacional y más allá

En términos de una conciencia de seguridad general dentro de una organización, también hay que realizar una formación continua que concierne a todo el personal; no solo los desarrolladores.

Esto se debe a que los actores malintencionados pueden explotar cosas como la ingeniería social y los correos electrónicos de phishing para exponer a la organización a riesgos.

En tales casos, es apropiado retener un esfuerzo colectivo utilizando capacitación especializada breve y concisa que se entregue al personal a intervalos frecuentes. Repetidamente enfatizamos que esta capacitación debe ser regular y actualizada, porque los malos actores prueban continuamente nuevos métodos de ataque.

Conclusión

¿Cómo podemos concluir un artículo tan breve de formación en codificación segura cuando hay tantas cosas en juego? Siguiendo estas recomendaciones de tutoriales, los desarrolladores obtendrán una idea esencial de por qué escribimos software seguro. Además de las recomendaciones de este artículo, las herramientas de capacitación constante y regular relacionadas con las pautas de código seguro son esenciales.

Esos cambian todos los días a medida que los piratas informáticos descubren formas creativas de explotar los sistemas. Para cubrir todas esas necesidades, le recomendamos que vea CxCodebashing con su solución completa de tutoriales de capacitación del tamaño de un bocado para una codificación segura. Puede consultar esos materiales en su sitio web en Checkmarx.com.

Ebook: 5 razones por las que la Seguridad del Software es más crítica que nunca