El coste oculto del código inseguro: algo más que filtraciones de datos

Cuando se producen filtraciones significativas como las de Equifax o Uber, es fácil centrarse en el enorme daño financiero y para la reputación que suponen todos esos datos de usuario comprometidos. Sin duda, esos costes son enormes.

La realidad es que el código de riesgo tiene un segundo coste insidioso más allá de las propias infracciones. Todas esas vulnerabilidades persistentes y las correcciones rápidas hechas bajo presión crean una deuda técnica masiva que sigue acumulándose.

Antes de que te des cuenta, todo tu equipo está empantanado luchando contra un fallo tras otro. Pasan meses tratando de arreglar el último fallo. Además, las facturas de infraestructura siguen aumentando debido a los sistemas hinchados que nadie se atreve a refactorizar. Y todos esos apasionados proyectos paralelos acumulan polvo porque mantener las luces encendidas requiere ahora toda tu energía.

El código inseguro actúa como un impuesto silencioso que desvía tiempo, dinero y moral a través de las organizaciones de ingeniería, grandes y pequeñas. Esos costes de combustión lenta no aparecen en los titulares como las brechas significativas, pero se acumulan a su manera silenciosa. Si no se aborda, esa deuda técnica pronto se convierte en su propia montaña inamovible que bloquea la innovación.

Al cuantificar la lenta sangría de la deuda técnica, abogamos por incorporar una mejor seguridad del código desde el primer día. Es la única forma de mantener una velocidad de ingeniería sólida a largo plazo.

Cuando los ‘exploits’ atacan: calcular los costes tangibles

Supongamos que un hacker identifica una vulnerabilidad en el código que le da acceso a datos confidenciales de una base de datos. Pueden filtrar los datos de los usuarios y usted se ve obligado a hacer frente a las consecuencias de la brecha. En el peor de los casos, una empresa se enfrenta inmediatamente a una larga lista de gastos de recuperación claramente definidos:

• Investigación de la filtración: Para comprender el alcance total del ataque, tendrá que iniciar una investigación forense exhaustiva que abarque los sistemas de almacenamiento, las redes, el código de las aplicaciones, etc. Dependiendo de la complejidad, estas evaluaciones pueden costar entre seis y siete cifras, dependiendo del tamaño de la empresa.
• Recuperación y corrección: Ahora empieza el duro trabajo de restaurar y parchear los entornos comprometidos. Los costes aumentan rápidamente a medida que se audita el código, se despliegan parches de seguridad, se restablecen las credenciales de usuario en todos los entornos y, potencialmente, se notifica a las partes afectadas por la pérdida de datos.
• Gastos legales y normativos: Dependiendo de los datos perdidos y de dónde opere, las empresas pueden enfrentarse a multas considerables por incumplimiento de GDPR, HIPAA o PCI. La brecha de Uber en 2018 resultó en un acuerdo de 148 millones de dólares por no revelar el impacto de manera oportuna.
• Pérdida de negocio de los clientes: Podría decirse que lo más perjudicial es la pérdida permanente de la confianza del cliente y, por extensión, de los ingresos después de los incidentes de seguridad. Muchos clientes preocupados por la seguridad abandonan la empresa después de un incidente de seguridad. Esta pérdida de clientes y el impacto negativo en la marca provocan una considerable pérdida de negocio.

Dado su alcance, es obvio por qué las violaciones de datos dominan las conversaciones sobre el coste del código inseguro. Los daños financieros y el impacto en los clientes son inmediatos y sustanciales. Pero incluso antes de que se produzcan los ataques, el código vulnerable y endeudado va activamente en contra de los desarrolladores y, de forma más sutil, reduce la productividad de los ingenieros.

El continuo pago de intereses de la deuda técnica

En última instancia, el código inseguro genera deuda técnica, el coste implícito del trabajo adicional necesario para adaptarlo a los estándares de producción en el futuro.

Piense en cada caso de deuda técnica como una pequeña deuda con su propio pago de intereses. A medida que estos problemas se acumulan por la presión del calendario, las bibliotecas obsoletas, las pruebas inadecuadas, etc., también lo hacen los ‘intereses’ mensuales que se pagan por cargar con esa deuda.

Sin ni siquiera darse cuenta, las organizaciones se quedan atascadas malgastando valiosos recursos de ingeniería y dinero para hacer frente a los impactos posteriores de un código deficiente:

• Ralentización del desarrollo de características: Los ciclos de ingeniería se ven absorbidos continuamente por el ‘pago de intereses’ de la deuda técnica. Esto afecta directamente a la velocidad, ya que los equipos luchan por mantener el ritmo mientras hacen malabarismos con los problemas heredados.
• Las facturas de la nube aumentan: La deuda técnica derivada de un código ineficiente también se manifiesta en facturas en la nube más elevadas. El uso subóptimo de la infraestructura subyacente significa que se paga por un exceso de capacidad que afecta directamente a los resultados.
• Más errores y problemas de fiabilidad: El código inseguro es naturalmente de menor calidad. Por tanto, las aplicaciones se enfrentan a más defectos, problemas de rendimiento y problemas de estabilidad que afectan a los usuarios finales. El resultado es una pérdida de productividad y frustración.
• Oportunidades de ingresos retrasadas o perdidas: El dinero, el tiempo y la atención necesarios para gestionar el código inseguro restan tiempo a las iniciativas empresariales que, de otro modo, podría impulsar la ingeniería. Los necesitados sistemas heredados reducen significativamente su ancho de banda para la innovación.

Al igual que ocurre con las deudas de las tarjetas de crédito, los pagos de intereses parecen pequeños al principio, y es fácil tirar la casa por la ventana. Pero si no se gestionan, los intereses compuestos provocan una improductividad galopante que puede paralizar las organizaciones. En su mayor parte, los datos confirman que los niveles insanos de deuda técnica frenan espectacularmente la producción. Como un motor desvencijado, las organizaciones malgastan valiosos recursos luchando por mantener los sistemas antiguos sobre raíles.

Incluso si se evitan las brechas de alto perfil, el código vulnerable y desordenado sigue encontrando formas de degradar silenciosamente la productividad de ingeniería, la eficiencia de la nube y la satisfacción de los desarrolladores con el paso del tiempo.

La muerte por mil cortes no deja de ser una muerte.

Cerrar la brecha requiere un cambio desde dentro

Dados los crecientes costes directos e indirectos, el código inseguro supone una amenaza existencial en múltiples frentes. Entonces, ¿qué medidas proactivas pueden tomar los desarrolladores para corregir el rumbo día a día?

1. 1. Adoptar flujos de desarrollo orientados a la seguridad

• Convierta las revisiones de seguridad en una fase obligatoria del SDLC antes de pasar a producción.
• Introducir una exploración ligera como parte de las pruebas automatizadas existentes para descubrir vulnerabilidades en una fase temprana en la que sea más fácil corregirlas.
• Exija a los desarrolladores que realicen una formación periódica sobre seguridad de las aplicaciones para estar al día de las últimas amenazas y técnicas de mitigación.
• Realice pruebas de penetración de producción más rigurosas y retrasadas en las rutas críticas trimestrales para detectar problemas antes de su lanzamiento público.

2. 2. Desarrollar las capacidades mediante la formación continua

• Haga que los fundamentos de la codificación segura sean de aprendizaje obligatorio para todos los miembros de la organización de ingeniería. Refrescar los conocimientos anualmente.
• Ofrecer almuerzos de formación en los que se repasen los 10 principales riesgos a los que se enfrentan los desarrolladores y las técnicas de prevención que pueden aplicar directamente.
• Enviamos anualmente a los principales arquitectos y a los principales responsables de la toma de decisiones a campamentos de codificación segura intensivos y de inmersión para que transmitan sus aprendizajes e informen sobre las normas.

3. Incentivar y potenciar la excelencia en seguridad

• Elogie públicamente las mejores prácticas de codificación segura en reuniones y boletines informativos. Reconozca y recompense a los que hayan evitado problemas importantes.
• Dedique un tiempo mensual presupuestado a que los ingenieros refuercen directamente la seguridad del código de la aplicación con la aprobación del director.
• Inculque la propiedad vinculando la calidad del código y los resultados de las pruebas de penetración al rendimiento de todos los equipos durante la revisión anual.

Palabras finales

Transformar los procesos organizativos requiere mucho esfuerzo. Pero dados los costes multifacéticos del código vulnerable que se extrae a diario de las empresas, asegurar nuestras bases de desarrollo es sencillamente innegociable.

Cuanto antes reorientemos los flujos de trabajo para detectar los problemas en la creación del código, menos intereses pagaremos por la deuda técnica en el futuro. Al igual que la salud financiera, la aplicación sistemática de las mejores prácticas preventivas crea memoria muscular de seguridad con el tiempo.

Aunque ningún enfoque elimina el riesgo por completo, incorporar prácticas de seguridad rigurosas a nuestro ADN contribuye en gran medida a evitar infracciones catastróficas. Y lo que es más importante, ayuda a liberar todo el potencial empresarial de la ingeniería.