Al igual que muchos en la profesión de seguridad de TI, agradecí los comentarios recientes hechos por el jefe de CISA saliente Jen Easterly, en el que señaló que hacer que el software sea más seguro puede no ser fácil o barato, pero es la única forma de proteger realmente los sistemas de TI.
La comparación de Easterly de la industria del software actual con la industria automotriz “antes de los cinturones de seguridad” de la década de 1960 me pareció particularmente apto. Inseguro a cualquier velocidad, Publicado en 1965 por Ralph Nader, precipitó el cambio transformador en la industria automotriz, argumentando mientras los fabricantes de automóviles pudieran autorregularse, continuarían priorizando el estilo, el costo, el rendimiento y la obsolescencia calculada sobre la seguridad y los mejores intereses del consumidor.
También continuarían con culpa a las víctimas cuando se tratara de accidentes, lanzando a los conductores en el papel de “la nuez detrás del volante”, en lugar de asumir la responsabilidad de los autos inherentemente mal diseñados.
Sesenta años después, hay paralelos claros con productos de software modernos. Con los desarrolladores en la búsqueda de estilo, la velocidad y otras prioridades, los errores y las vulnerabilidades persisten. Y también hay una buena cantidad de señales de dedos a los usuarios. Se nos dice que no saben cómo usar estos sistemas de manera segura o protegerlos adecuadamente. Esta narrativa conveniente transmite el mensaje de que, con usuarios como estos, ¿es de extrañar que se produzcan ‘accidentes’ como ataques de ransomware y violaciones de datos?
Pero como Easterly ha señalado, eso no es justo. No podemos seguir aceptando un software peligroso y necesitamos profundizar en los problemas y defectos que conducen a infracciones. El trabajo que CISA está haciendo con la iniciativa Secure By Design es un paso increíblemente importante y constructivo para responsabilizar a la industria del software.
Pero como clientes, también necesitamos jugar nuestro papel en presionar por el cambio. En el año más o menos después de la publicación del libro de Nader, Estados Unidos adoptó dos leyes de auto-seguridad y estableció la Agencia Nacional de Seguridad del Tráfico. A lo largo de las décadas desde entonces, la presión del cliente ha ayudado a impulsar la introducción generalizada de los cinturones de seguridad, los frenos antibloqueo y las airbags.
Exigiendo mejor de los proveedores
Como compradores de software, las organizaciones deben exigir mejor a los proveedores, y el equipo de seguridad de TI debe desempeñar un papel activo en todas y cada una de las negociaciones con ellos. De hecho, debe participar desde las primeras etapas, intervenir durante el proceso de adquisición y defender el mensaje de seguridad.
Sin esa participación, el riesgo es que una pieza inherentemente insegura de software corporativo se compre e instale, lo que luego resulta en una pila completa de problemas para la seguridad de TI: muchos parches, muchas actualizaciones, muchas simulacros de incendio y respuestas de emergencia. En resumen, tiene una pieza de software que representa un drenaje significativo en los recursos y una fuente consistente de interrupciones para el equipo de seguridad de TI. En términos de la analogía del automóvil, acabas de comprar un limón.
Después de todo, no es desconocido que un equipo ejecutivo tome una decisión de adquisición de software basada en lo que otras organizaciones están haciendo, lo que el producto se considera “líder en el mercado”, una relación existente entre la organización y un proveedor particular, o muchas otras consideraciones, pero todo a la exclusión de lo que es realmente mejor para el entorno de la organización y su seguridad.
En realidad, el CISO y su equipo son responsables de asegurarse de que cada pieza de tecnología traída a la organización se alinee con su postura de riesgo y sus controles de seguridad bien definidos. En resumen, deben determinar si esta compra propuesta cumplirá con los mismos requisitos que se espera que cada otro software cumpla.
En mi experiencia, aquí es donde una solicitud formalizada ‘ciega’ del proceso de propuesta (RFP) puede pagar dividendos, asegurando que las decisiones de adquisición de software no sean influyadas por la reputación de la marca o la influencia de marketing. A partir de ahí, el equipo de seguridad de TI debe participar activamente en la prueba de conceptos (POC) que implican probar elementos del nuevo software dentro del entorno actual, asegurarse de que funcionen e identificando cualquier problema potencial, tomando el software para una “prueba de manejo”, si lo desea.
Esto le dará al equipo de seguridad de TI una base sólida para involucrar a colegas de otras partes del negocio en una sólida conversación sobre el riesgo. Raramente (si alguna vez) es un caso del equipo de seguridad de TI que intenta vetar una compra. Se trata más de que ayuden a la organización a comprender cómo mitigar los riesgos identificados, o aceptarlos, si la organización se siente cómoda con esos riesgos. Sobre todo, se trata de comprender el apetito de riesgo dentro de la organización y cómo se desarrolla dentro del contexto de lo que el negocio está tratando de lograr.
Comprador Cuidado
Pero, sobre todo, el equipo de seguridad de TI debe ser parte de un esfuerzo organizacional más amplio para esperar más de los proveedores, nuestro propio esfuerzo para insistir en ‘seguro por diseño’, dentro del microcosmos de una compra individual.
En pocas palabras, el panorama de riesgos que enfrentan los equipos de TI hoy, con sus muchas violaciones y ataques de datos, es el resultado directo de no esperar más, de simplemente aceptar que las regulaciones y los requisitos de cumplimiento a su alrededor se deben ser necesariamente asumir los consultores de software, y no sus creadores.
Que debe cambiar. Debemos aumentar nuestras expectativas y la responsabilidad del cambio, porque hasta que eso suceda, los clientes continuarán asumiendo el trabajo después de la implementación de que las compañías de software no llevan a cabo cuando diseñan productos. Si los clientes no tenían ese trabajo que hacer, entonces podrían pasar más tiempo mirando cómo podrían administrar mejor sus entornos, proporcionar mejores experiencias de los clientes y ayudar a las empresas a alcanzar sus objetivos financieros de alto e inferior.
Para la industria automotriz, la primera prioridad tenía que ser un automóvil más seguro y a prueba de accidentes. Para nosotros, debe ser un software más seguro y a prueba de incumplimiento.