Hacer y mantener la infraestructura de TI de una empresa a salvo de intrusiones no autorizadas o acciones maliciosas siempre ha sido un desafío. Con el mayor uso de la computación en la nube, junto con la necesidad de seguir desarrollando nuevas funciones a un ritmo cada vez mayor mediante el uso de tecnologías ágiles, mantener una buena seguridad se ha vuelto aún más complejo.
Al comprar software y servicios de software de terceros, lo que el comprador necesita es una lista de verificación de los requisitos clave desarrollados a partir de una comprensión de las necesidades comerciales, técnicas y operativas que impulsarán la investigación de productos y servicios potenciales.
Una vez que se ha desarrollado una lista de posibles proveedores y productos/servicios, se puede emitir una solicitud de información (RFI) o equivalente y en función de los requisitos clave identificados de la empresa.
Las respuestas a esa RFI ayudarán a refinar la lista de proveedores y productos o servicios a unos pocos candidatos adecuados, de modo que se pueda emitir una solicitud de cotización basada en un conjunto detallado de requisitos.
El final del juego es el contrato de arrendamiento con el proveedor seleccionado, donde el propio contrato articula los requisitos de la empresa en detalle. Esos requisitos probablemente serían destinatarios como anexos al contrato principal, lo que permitiría cambios futuros sin la necesidad de renegociar el contrato principal. Este proceso puede parecer largo y difícil de manejar, pero en última instancia, su objetivo es la seguridad y podría estar apostando el futuro de su empresa si no cubre todas las bases.
Los principios generales descritos aquí se pueden aplicar dentro de una organización grande donde hay un grupo o grupos de desarrollo interno. En esencia, sería un contrato entre el área de negocios y los grupos de desarrollo y operación.
De principios a mediados de la década de 1990, estaba realizando una auditoría interna de TI en Europa para un importante banco internacional y descubrí que la auditoría no se incluía en un proyecto hasta que se puso en marcha o, a menudo, después de que se puso en marcha.
El grupo de seguridad de TI era un pequeño grupo de dos personas ubicado en una oficina central a muchos miles de kilómetros de distancia. Venía de una experiencia en redes y TI y pude reunir varios documentos relacionados con la práctica de seguridad, auditoría y software para crear un documento pequeño y conciso para los grupos de desarrollo en Europa.
La resistencia inicial pronto se evaporó y la auditoría comenzó a ser bienvenida en los proyectos de software durante el ciclo de desarrollo, abriendo la puerta a una retroalimentación temprana y significativa.
Fue un resultado beneficioso para todos, ya que tanto el desarrollo como la auditoría ahorraron tiempo y se desperdiciaron menos recursos. Por supuesto, hoy tenemos DevSecOps, una extensión de DevOps, y esto garantiza que los requisitos de seguridad, junto con las pruebas periódicas y los comentarios, se integren en el ciclo de desarrollo de software, lo que lleva a un menor desperdicio de recursos.
Aunque DevSecOps puede verse como un factor importante para mejorar la postura de seguridad general de la infraestructura de TI de una empresa, no significa que se pueda prestar menos atención a los aspectos básicos, como parches y mecanismos de autenticación y acceso bien pensados.
Por supuesto, no todas las empresas tienen sus propios equipos de desarrollo internos, y prefieren comprar aplicaciones o servicios listos para usar.
Cuando se compran los servicios, los procesos de seguridad no están bajo el control directo de la empresa compradora, es decir, la empresa compradora depende de que el producto o servicio sea seguro.
Esta confianza se basa principalmente en lo que cubre el contrato de compra, y aquí el diablo está definitivamente en los detalles.
Por ejemplo, podría pensar que exigir la certificación ISO27001 y las pruebas anuales cubriría sus necesidades, pero a menos que haya especificado qué cláusulas se requieren y a qué nivel de especificación (alcance y declaración de aplicabilidad), no puede estar seguro del nivel de seguridad.
Cuando compre software, considere si el contrato cubre el análisis de código por parte de expertos en seguridad, si los requisitos de seguridad de su empresa están establecidos y si son completos.
En un entorno de rápido movimiento, necesitará acceso a personas capacitadas para definir los requisitos de seguridad donde se encuentra la computación en la nube y el desarrollo de software de terceros. Estas personas necesitarán habilidades de análisis de riesgos y amenazas, incluida una buena comprensión de los riesgos comerciales porque articulan lo que es clave para proteger en una empresa.
Los anexos del contrato son la mejor manera de manejar estas necesidades contractuales, ya que pueden actualizarse según sea necesario sin tener que someterse a una renegociación total del contrato.
