¿Cómo reducir la brecha entre seguridad e innovación?

Durante años se ha concebido la seguridad como un freno a la innovación. Seguridad establece políticas y protocolos que restringen la elección y la libertad, sobre todo cuando se trabaja un enfoque que es resultado de soluciones puntuales aisladas y silos operativos. Este enfoque fragmentado añade complejidad, lo que supone una mayor carga de trabajo para los equipos de seguridad, que a su vez se vuelven más defensivos a la hora de gestionar el riesgo.

Esta realidad se enfrenta a un nuevo panorama: hoy en día los equipos de DevOps quieren liberarse, explorar su creatividad y adoptar tecnologías nativas de la nube, como contenedores, Kubernetes, PaaS, arquitecturas orientadas a eventos y arquitecturas serverless. Este cambio se observa en la oferta de programas de software comercial, el 99% de ellos incluyen al menos un componente de código abierto.

Sin embargo, esta ubicuidad convierte a los programas de software comercial en un objetivo para los ciberatacantes. No es de extrañar, entonces, que en 2021 se produjera un aumento del 650% interanual en los ataques a la cadena de suministro de software dirigidos a los puntos débiles de las comunidades de código abierto.

Además, existe otro factor que está influyendo en el incremento del número de ataques, que es el aumento de los dispositivos conectados y del volumen de datos. Estos sistemas son un punto adicional de vulnerabilidad y son atacados para robar o encriptar los datos y pedir un rescate con el consiguiente impacto en el negocio y la reputación de la empresa. Esta es la razón por la que se está haciendo un mayor refuerzo a la seguridad de los datos.

Es muy fácil hablar de cómo gestionar los recursos para atacar estos riesgos, pero no tanto llevar estas medidas a la práctica

Una única vulnerabilidad puede costar millones de dólares en multas y mucho más en pérdida de confianza. Por ello es importante que las organizaciones sean conscientes de qué software han desplegado, de cómo lo están gestionando activamente y de tener métodos para auditar el código independientemente del fabricante. El software de código abierto permite auditar el código de una forma independiente, ofreciendo transparencia, libertad y autonomía a la hora de saber que se está ejecutando y cómo se están ejecutando las tareas que dan soporte al negocio.

Es muy fácil hablar de cómo gestionar los recursos para atacar estos riesgos, pero no tanto llevar estas medidas a la práctica. La gestión de la seguridad es interna, por lo tanto, no se debe subestimar la inversión en conocimientos ni en personal. “¿Sabemos qué software se está ejecutando en la organización? ¿Es compatible con la seguridad de la infraestructura? ¿Tenemos capacidad para identificar vulnerabilidades? ¿Podemos solucionar los problemas que encontremos?” Estas son sólo algunas de las preguntas básicas que un equipo de seguridad debería responder con soltura y confianza.

Debería de empezar a valorar su estrategia de seguridad, y en esta valoración es posible que esté pensando en dejar de utilizar código abierto, pero esa opción puede ser igual de arriesgada para la organización en términos de negocio. En 2021, se introdujeron seis millones de nuevas versiones de software de código abierto, que ayudaron a las organizaciones a impulsar la innovación y, por lo tanto, los beneficios.

¿Por qué utilizar código abierto?

Todavía hoy en día existe la falsa creencia de que el software que no es de código abierto es más seguro que el software de código abierto ya que al no tener acceso al código fuente es más difícil descubrir las vulnerabilidades y por ello es más seguro. Esta creencia es falsa, cuando existe una vulnerabilidad tarde o temprano va a ser descubierta. Cuando esta vulnerabilidad es descubierta por alguien que quiere explotarla no va a ser publicada haciendo que nuestro software sea vulnerable. En el software que no es código abierto se conoce como seguridad por oscuridad.

En cambio, como en el software de código abierto, el código fuente está disponible existe la posibilidad de auditarlo y estudiarlo. Multitud de usuarios a lo largo de todo el planeta tienen a su disposición el código, para contribuir a mejorarlo, auditarlo, etc. Esto trae como consecuencia que los fallos de seguridad como norma general se descubran, se reporten y se parcheen con más rapidez que en el software que no es de código abierto.

Esto no significa que el software de código abierto sea más seguro que su contrapartida por el mero hecho de ser de código abierto. El ser software de código abierto trae como consecuencia una mayor adaptabilidad y evolución que se manifiesta en todas las facetas del ciclo de vida del software, una de ellas la seguridad.

Seguridad que dice “sí”

Hay otra forma de mitigar los riesgos de seguridad inherentes al software de código abierto sin desplegar importantes recursos internos para hacer frente a los desafíos. Se trata de otra manera en la que la seguridad no tiene que ser igual a un “no” cuando alguien dice: “Quiero probar esto, quiero trabajar con esta herramienta”. Más bien, la seguridad debería convertirse en la razón por la que se puede decir “sí”.

La seguridad es fundamentalmente una cuestión de cultura. Más concretamente, de una cultura abierta. En una cultura abierta, la innovación y la seguridad no están en lados opuestos. Se convierten en intercambiables. Es seguridad y desarrollo: DevSecOps.

La sguridad ya no está aislada en un equipo específico en la fase final del desarrollo. Con los rápidos ciclos de lanzamiento de hoy en día, la seguridad debe ser shift left e integrarse en los flujos de trabajo de DevOps, en lugar de atornillarse cuando la aplicación está a punto de desplegarse en producción.

Esto suele requerir un cambio dentro de la organización, diferentes prácticas de trabajo y un reajuste cultural.

Según el estudio El Estado de la Seguridad de Kubernetes de 2022 de Red Hat, el 78% de las organizaciones entrevistadas tienen una iniciativa de DevSecOps; y el 27% están integrando y automatizando la seguridad en todo el ciclo de vida de sus aplicaciones.

Pero la seguridad del código abierto va más allá de la dinámica interna. Es una quiniela: nosotros contra los atacantes. Los atacantes piensan como los desarrolladores. Así es como planean sus ataques. Así que cuantos más desarrolladores estén de nuestro lado, buscando fallos y vulnerabilidades en el código, más seguro será ese código y más dificultades tendrán los atacantes.

La transparencia es clave. Hace que la seguridad deje de ser algo secreto para convertirse en algo compartido. Todo el mundo es dueño de ella, y todo se hace público. El código abierto significa que hay más personas que identifican una vulnerabilidad, más personas que investigan, más personas que desarrollan y prueban el parche, y más usuarios finales conscientes y capaces de tomar medidas.

Las vulnerabilidades se valoran. Hay que encontrarlas con rapidez, solucionarlas y aprender de ellas. Es un esfuerzo de grupo y un círculo virtuoso, en el que una mayor participación y apertura mejora las cosas. En el software de código abierto cualquiera, con conocimientos, puede ayudar a parchear una vulnerabilidad. Siempre habrá alguien para el que una vulnerabilidad sea lo suficientemente importante como para ayudar a sacar el parche. En el software que no es de código abierto el número de desarrolladores es limitado y eso hace que las vulnerabilidades se vayan corrigiendo en función de la prioridad asignada. Si una vulnerabilidad que nos afecta y en la que estamos necesitados de encontrar solución tiene baja prioridad para el fabricante estaremos expuestos hasta que esa vulnerabilidad se arregle dado que el código fuente no se encuentra disponible. Con el software de código abierto la probabilidad de que se arregle en un tiempo razonable es alta y siempre existen alternativas como pagar a un desarrollador para arreglarla o establecer un programa de bug bounty con el que se premia a quienes reportan fallos de seguridad. Compara esto con una visión propietaria de la seguridad (seguridad por oscuridad), que en última instancia depende de la conciencia y las habilidades de unos pocos.

El gran reto de seguridad del código abierto es, en realidad, que las herramientas y tecnologías DevOps -piensen en contenedores, Kubernetes, microservicios- son altamente personalizables, con varias opciones de configuración que pueden afectar el enfoque de seguridad de una aplicación. Una incorrecta configuración es una amenaza para la seguridad. La automatización de la gestión de la configuración, para que la tecnología (y no los humanos) proporcione las barreras de protección, disminuye estos problemas.

Conocer el origen

La procedencia es importante. Saber de quién se obtiene el código abierto es la primera línea de defensa. Una de las cosas más maravillosas del código abierto es que cualquier organización de cualquier tamaño puede adoptar y utilizar libremente tecnologías de código abierto. El inconveniente es la inversión que hay que hacer para asegurarse de que estos proyectos son revisados, examinados y asegurados por sus propios desarrolladores antes de ponerlos en producción.

Como alternativa, se puede buscar software de código abierto de proveedores que realicen las comprobaciones de seguridad y las actualizaciones. Cuantos menos proveedores le proporcionen el software, menos partners tendrá que confiar o acceder a la asistencia técnica. Menos sistemas significa también menos complejidad y, por tanto, menos trabajo que hacer. La lista de la compra debería incluir:

• Software que se obtiene de redes de distribución vetadas y seguras y que se firma para comprobar su autenticidad;
• Código que se almacena en repositorios internos seguros;
• Paquetes que están firmados y con fuertes salvaguardas contra la manipulación.