La ciberseguridad ha estado plagando a organizaciones e individuos desde hace un tiempo. 2020, especialmente, fue testigo de un aumento en la seguridad de TI debido a los mandatos de quedarse en casa inducidos por la pandemia. Esto dejó a muchas personas con una gran cantidad de tiempo libre en sus manos, que en su mayoría eligieron gastar en Internet, poniéndose, sin saberlo, a sí mismos y a sus negocios en un grave riesgo de ataque cibernético.
Las violaciones de datos expusieron más de 30 mil millones de registros en la primera mitad de 2020. Incluso los sitios web de empresas establecidas como Marriott, SolarWinds, Zoom y Twitter fueron pirateados y violados. Quizás el más innovador de todos estos ataques fue el de Twitter, que llevó a las cuentas comprometidas de personajes famosos como Barack Obama, Bill Gates, Ellon Musk y Kanye West. Claramente, las empresas necesitan un plan para frenar este tipo de ataques a Internet. Y ahí es donde entra en juego «Security by Design».
En este artículo analizamos qué es la seguridad por diseño, sus principios, beneficios, oportunidades y desafíos.
Indice
¿Qué es la Seguridad por diseño?
Security by Design es un enfoque estratégico y de iniciativa para la creación de software y hardware que busca minimizar el riesgo de ataque cibernético antes de que suceda a través de una monitorización, prueba e implementación consistentes de procedimientos de protección. Implica incorporar seguridad en los productos desde el inicio, para aumentar su inmunidad a todo tipo de ataques.
Los estudios de investigación han revelado que muchas empresas tienen prácticas de ciberseguridad porosas y datos inseguros. Por lo tanto, existe una necesidad urgente de incorporar la seguridad directamente en los productos en lugar de esperar hasta que se produzcan ataques importantes.
La seguridad por diseño es lo opuesto a la seguridad a posteriori: en lugar de probar la seguridad de un sistema cuando está terminado, la seguridad de la información está incorporada desde el principio. Esto reduce los costes y mitiga los riesgos porque:
- Resolver problemas de seguridad al principio es mucho más barato. Además de eso, la presión de las limitaciones de tiempo y presupuesto es particularmente pesada al final del proceso de desarrollo, no es el mejor momento para las mejoras pensadas. La seguridad por diseño da como resultado un sistema más resistente donde la seguridad está incorporada en lugar de agregarse apresuradamente como una solución.
- La implementación de una variedad de medidas de seguridad por diseño (conciencia, conocimiento, herramientas y verificaciones) permite eliminar las fallas de seguridad de manera más efectiva que mediante la prueba al final del desarrollo.
- Determinar exactamente qué errores se han cometido le permite adaptar el proceso de desarrollo para evitar más errores. Esto se aplica, por ejemplo, a las mejoras en la colaboración entre los desarrolladores y la operación de TI. Las colaboraciones cercanas y automatizadas se denominan DevOps; o SecDevOps con seguridad incorporada.
Enfoque
Security by Design (SbD) es un enfoque de seguridad que permite formalizar el diseño de la infraestructura y automatizar los controles de seguridad para que puedas incorporar seguridad en cada parte del proceso de gestión de TI. En términos prácticos, esto significa que tus ingenieros dedican tiempo a desarrollar software que controle la seguridad de tu sistema de manera constante las 24 horas del día, los 7 días de la semana, en lugar de dedicar tiempo a construir, configurar y parchear servidores individuales manualmente.
Este enfoque para el diseño de sistemas no es nuevo, pero el auge de la nube pública ha hecho que SbD sea mucho más simple de ejecutar. Amazon Web Services ha estado promoviendo activamente el enfoque y formalizándolo recientemente para la audiencia de la nube. Otros proveedores promueven conceptos similares o relacionados, a menudo llamados Secure DevOps o Security Automation o Security-as-Code o SecOps. La práctica se vuelve más importante a medida que su entorno se vuelve más complejo y AWS en realidad tiene muchos servicios nativos que, si se configuran y organizan de la manera correcta, crean un sistema que es más seguro que un entorno local configurado manualmente.
¿Significa esto que las empresas ya no necesitan profesionales de seguridad, solo ingenieros de DevOps capacitados en seguridad? Para nada. Cuando los profesionales de la seguridad adoptan este enfoque, tienen un impacto mucho mayor que en el pasado.
En realidad, esta es una oportunidad para que los profesionales de la seguridad obtengan lo que siempre han soñado: introducir la seguridad en una etapa más temprana del proceso de desarrollo. En lugar de aplicar retroactivamente las políticas de seguridad, y siempre estar atrasados, son parte del proceso de planificación de la arquitectura desde el primer día, pueden codificar las especificaciones deseadas en plantillas y siempre saben que se aplican las configuraciones deseadas. Ya no necesitan ser consultados sobre todos y cada uno de los cambios de infraestructura, solo necesitan ser consultados cuando las plantillas de infraestructura cambian de manera significativa. Esto significa menos trabajo repetitivo y más concentrado en problemas reales.
Principios
Los principios que guían el enfoque de seguridad por diseño pueden diferir de una organización a otra. Pero el Open Web Application Security Project (OWASP) enumeró algunos principios a los que los programadores deberían adherirse. Teniendo esto en cuenta, pueden diseñar productos seguros. A continuación se muestran cuatro principios de seguridad por diseño.
Principio de reducción de la superficie de ataque
Una superficie de ataque es la suma de todas las vulnerabilidades presentes en el software, las aplicaciones, los dispositivos o cualquier otro producto que pueda servir como puntos de entrada para los atacantes cibernéticos. Como tal, cada vez que se agrega una nueva característica o funcionalidad a un producto, la superficie de ataque se vuelve más ancha. En seguridad por diseño, el principio de reducir la superficie de ataque significa limitar el acceso del usuario a funciones y características específicas del producto para minimizar los riesgos.
Principio de privilegio mínimo
El principio de privilegio mínimo garantiza que los usuarios solo tengan la potencia mínima necesaria para completar una tarea en particular. Supón que un asistente virtual tiene un rol de editor en una plataforma de blogs. En ese caso, no debería poder realizar tareas administrativas, como agregar y eliminar usuarios y activar complementos.
Principio de valores predeterminados seguros
Desarrollar un producto siguiendo el enfoque de seguridad por diseño significa que el producto debe tener medidas de seguridad predeterminadas, independientemente de las preferencias del usuario. Estas medidas incluyen los requisitos de caracteres de la contraseña, la frecuencia con la que se solicita a los usuarios que cambien las contraseñas y los datos necesarios durante el proceso de registro del usuario.
Principio de defensa en profundidad
La defensa en profundidad (DiD) es un principio militar que tiene como objetivo retrasar a los enemigos poniendo tantos obstáculos en su camino como sea posible. Eso se traduce en incorporar más de una forma de hacer que un producto sea seguro desde el punto de vista de la ciberseguridad.
Por ejemplo, la transferencia de fondos en línea a través de la aplicación móvil de un banco requeriría que el usuario inicie sesión con un nombre de usuario y una contraseña. Además, los usuarios deben ingresar un pin de un solo uso (OTP) enviado a la dirección de correo electrónico o número de teléfono registrado del usuario. En el proceso, también se implementan una verificación de la dirección IP y la detección de fuerza bruta.
Cómo adoptar SbD
La seguridad por diseño es un enfoque para el desarrollo de software que integra las mejores prácticas de ciberseguridad a lo largo del ciclo de vida del desarrollo. Es la ciberseguridad proactiva en su máxima expresión, adoptando la idea de que diseñar y actualizar tus sistemas de seguridad es un proceso que nunca termina.
En el centro de este enfoque se encuentra la idea de desarrollo continuo. Implica que con cada paso del proceso de desarrollo se implementan nuevos sistemas y se prueban continuamente los sistemas antiguos. Cuanto antes se encuentre un exploit, más rápido se podrá parchear.
Si la idea es minimizar los errores que comprometen tu seguridad, entonces necesitas un conjunto de pautas y prácticas que ayuden a los desarrolladores a evitar esos errores y encontrarlos cuando inevitablemente uno pasa por alto. A continuación, se muestran algunos ejemplos de cómo adoptar la seguridad por diseño:
Tecnología de confianza utilizada
Es difícil resistir la tentación de utilizar la última tendencia para nuestro proceso de desarrollo, pero hay una razón por la que los bancos y los gobiernos son extremadamente lentos en la actualización de sus sistemas: confían en una tecnología de confianza que ha resistido la prueba del tiempo.
«De confianza» no significa necesariamente viejo, eso sí. Cuanto más tiempo esté algo en el mercado y más popular sea, mayores serán las probabilidades de llamar la atención de los ciberdelincuentes. En este sentido, por confiable nos referimos a tecnología que ha sido probada y verdadera, cuyos propietarios son abiertos sobre sus prácticas de seguridad y que tu equipo conoce de adentro hacia afuera.
Capacita a tu equipo
Un equipo de desarrolladores que esté al tanto de las amenazas y exploits que se encuentran en proyectos similares será más cuidadoso al crear software. Además, muchos desarrolladores que son creativos y muy talentosos, carecen de conocimientos en prácticas de seguridad. Como tal, enseñarles estrategias como los principios de OWASP SbD es una ganancia para ellos como profesionales y para tu negocio.
Privacidad al frente y al centro
GDPR cambió el panorama del desarrollo de software y ha traído un enfoque más consciente al manejo de datos personales. Una buena práctica es partir de la idea de que los datos personales son privados y desarrollar tu seguridad en torno a esa noción.
Crea controles de seguridad para acceder y compartir datos personales, asegúrate de que la base de datos esté lo más aislada posible y mantén el acceso al mínimo.
IA y comprobaciones manuales
Realiza comprobaciones de rutina en tu código, probando posibles vulnerabilidades. Existen excelentes herramientas que pueden verificar el código en busca de errores y exploits. Otro enfoque es hacer que tanto las pruebas internas como los consultores de seguridad revisen el proyecto para tratar de encontrar posibles riesgos de seguridad.
Buenas prácticas de diseño
El código espagueti, la tecnología heredada y las deudas técnicas hacen que los proyectos sean más difíciles de mantener y parchear cuando se detecta una brecha de seguridad. Mantener tu proyecto limpio y organizado ayuda a los desarrolladores a detectar posibles amenazas y corregir las vulnerabilidades que se encuentren en el futuro.
¿Cuáles son las oportunidades en Security by Design?
Además de proteger los datos, Security by Design ofrece excelentes beneficios y oportunidades para corporaciones y organizaciones.
- Security by Design ayuda a proteger los dispositivos conectados, los datos confidenciales y personales y la información de las empresas a medida que desarrollan nuevas aplicaciones y productos.
- SbD permite a las organizaciones identificar las vulnerabilidades existentes y los agujeros de seguridad en sus sistemas, dándoles suficiente tiempo para salvar la situación.
- En lugar de tomar medidas extremas para evitar riesgos, Security by Design permite que las organizaciones operen con confianza y emprendan proyectos innovadores sin el temor constante de un ataque cibernético.
- También permite y fortalece la confianza en los sistemas, datos e información de la empresa.
- Además, Security by Design anima a los líderes de TI a formalizar sus estrategias de ciberseguridad.
- SbD minimiza la necesidad de modificar el sistema o la configuración con cada pequeño cambio, excepto cuando se necesitan actualizaciones.
- Crear conciencia: informar a los desarrolladores sobre lo que se requiere y cuáles son las amenazas típicas para el software que desarrollan. Los ejemplos y demostraciones funcionan bien aquí. Involucrar a los desarrolladores en el modelado de amenazas aumenta su experiencia.
- Automatizar verificaciones: cada vez hay más herramientas de verificación disponibles para probar automáticamente ciertas vulnerabilidades de seguridad mediante el escaneo del código fuente o el comportamiento de prueba. No subestimes el esfuerzo necesario para utilizar correctamente estas útiles herramientas.
Desafíos asociados a la Seguridad por diseño
Sin lugar a dudas, SbD tiene un papel crucial en el software y el hardware, particularmente en la era de la inteligencia artificial, el aprendizaje automático e Internet de las cosas (IoT). Sin embargo, existen algunos desafíos que enfrenta el personal de seguridad.
La ciberseguridad continúa evolucionando a un ritmo vertiginoso que dificulta que los profesionales de TI se pongan al día. Esto se debe a que muchas organizaciones cambian continuamente su enfoque en lo que respecta a la informática, las aplicaciones, las redes, las bases de datos y los dispositivos. Los líderes de la empresa adoptan rápidamente nuevas herramientas y políticas de TI con la esperanza de reducir costes o acelerar el trabajo; desafortunadamente, esto dificulta las cosas para los equipos de seguridad.
Otra historia común es cuando las empresas esperan que el personal de seguridad se mantenga al día con los cambios de la industria sin brindarles apoyo con las tecnologías que necesitan.
El resultado suele ser el mismo: dispositivos inestables o productos que carecen de seguridad.
En lugar de evitar el riesgo por completo, Security by Design se trata de permitir la confianza en los sistemas, diseños y datos para que las organizaciones puedan asumir más riesgos, liderar cambios transformacionales e innovar con confianza.
En el campo en constante crecimiento de la Inteligencia Artificial (IA), por ejemplo, la necesidad de un enfoque de este tipo es cada día más clara. Las dos formas más comunes de aprendizaje automático (ML) que componen este campo, no supervisado y supervisado, son los principales objetivos de la subversión. Los resultados producidos por estos métodos dependen naturalmente de los algoritmos que les dan vida. Sin embargo, incluso los algoritmos de vanguardia conducirán a resultados corruptos si los datos que los alimentaron se manipulan.
En la actualidad, no se presta suficiente atención a la protección de la integridad de los datos que ingresan a los sistemas de aprendizaje automático en el corazón de cada vez más productos y servicios convencionales. Los ciberdelincuentes lo saben y, en principio, podrían atacar los sistemas agregando, eliminando o cambiando conjuntos de datos subyacentes. La mayoría de los sistemas digitales existentes en la actualidad ya corren el riesgo de sufrir este tipo de manipulaciones.
Sin embargo, a medida que la inteligencia artificial amplía el alcance de las decisiones automatizadas, también se amplían las oportunidades de hacer travesuras. Tomemos, por ejemplo, los sistemas de tráfico de vuelo programados para ajustar automáticamente la velocidad o altitud de la aeronave en función de datos potencialmente adulterados, o el software ML diseñado para detectar problemas médicos, donde los datos corruptos llevan a los algoritmos a ignorar los signos de cáncer. Estos resultados profundamente indeseables solo pueden evitarse mediante la implementación de protocolos adecuados de gestión de acceso, identidad y gobernanza de datos en el núcleo de los sistemas de IA.
Seguridad por diseño en la práctica
En la práctica, SbD se trata de codificar arquitecturas estandarizadas, repetibles y automatizadas para que sus estándares de seguridad y auditoría sigan siendo consistentes en múltiples entornos. Tus metas deben ser:
- Proceso de construcción controlado y estandarizado: diseño de arquitectura de código en una plantilla que puede construir un entorno de nube. En AWS, hace esto con CloudFormation. Luego, codifica las configuraciones del sistema operativo en una herramienta de administración de configuración como Puppet.
- Proceso de actualización controlado y estandarizado: coloca tus plantillas de CloudFormation y manifiestos de Puppet en una herramienta de administración de código fuente como Git que te permite versionar plantillas, revertir cambios, ver quién hizo qué, etc.
- Pruebas automatizadas de seguridad de código e infraestructura como parte de la canalización de CI / CD: integra pruebas de infraestructura y de nivel de código en el proceso de implementación de código, así como en el proceso de actualización de la gestión de la configuración.
- Configuraciones forzadas en producción: crea scripts de administración de configuración que se ejecuten continuamente en todos tus entornos para hacer cumplir las configuraciones. Por lo general, se aloja en un centro de administración central y requiere un enfoque de diseño de VPC de radios de concentrador.
- Herramientas de monitorización maduras con datos sujetos a evaluación humana inteligente y bien capacitada: en entornos compatibles, tus herramientas de monitorización generalmente son obligatorias y los registros deben estar sujetos a revisión humana.
- Poca o ninguna intervención humana directa en el medio ambiente: una vez que todas estas herramientas estén en su lugar, ya no deberías necesitar modificar directamente instancias o configuraciones individuales. En su lugar, deberías modificar la plantilla o el script para actualizar (o más idealmente, reiniciar) el entorno.
Cumplimiento + seguridad por diseño
Como puedes imaginar, el enfoque de SbD tiene impactos positivos significativos en los esfuerzos de cumplimiento. Lo más difícil de lograr en el cumplimiento de la infraestructura es no configurar las herramientas de seguridad y registro, sino mantener esos estándares a lo largo del tiempo.
En el viejo mundo, los sistemas cambiaban con poca frecuencia con largos plazos de entrega, y los equipos de GRC siempre podían pasar de 2 a 3 semanas evaluando y documentando los cambios manualmente (generalmente en una hoja de cálculo). En la nube, cuando el código se envía semanalmente y la infraestructura es escalable, este enfoque de cumplimiento manual puede limitar gravemente el éxito de los proyectos en la nube, ralentizar los equipos de DevOps y frustrar tanto a la empresa como al equipo TI.
La ejecución de aplicaciones en la nube requiere un nuevo enfoque de cumplimiento. Idealmente, necesitamos un sistema que permita a los desarrolladores e ingenieros trabajar de manera ágil sin dejar de mantener los estándares de seguridad y cumplimiento. Necesitamos una cadena de herramientas que:
- facilite la creación de entornos compatibles,
- proporcione medidas de seguridad para evitar que los ingenieros / desarrolladores lancen recursos fuera de los parámetros de cumplimiento, y
- proporcione documentación continua sobre la configuración de los recursos de infraestructura.
Las cadenas de herramientas que ya hemos descrito (plantillas, gestión de la configuración, supervisión) nos permiten lanzar nuevos entornos compatibles de forma trivial, garantizan un acceso muy limitado al entorno y una documentación completa sobre cada cambio. En conjunto, esto significa un riesgo muy reducido de cambios de configuración indocumentados,
Cuando los sistemas son complejos, debe haber un conjunto igualmente poderoso de herramientas y procesos de administración para hacer cumplir y mantener las configuraciones. El cumplimiento continuo solo es posible si tratas tu infraestructura como código. Si tu infraestructura se puede controlar mediante programación, sus parámetros de seguridad y cumplimiento son solo piezas de código, capaces de cambiarse de manera más flexible, versionarse en Git como cualquier pieza de software y automatizarse para autocorregir errores. Este es el futuro de cualquier tipo de seguridad en la nube.
Futuro de SbD
SbD permite a los clientes automatizar la arquitectura fundamental y, como dice AWS , «hacer que el incumplimiento de los controles de TI sea cosa del pasado».
Los anuncios recientes de AWS son particularmente interesantes. AWS lanzó una actualización importante para su herramienta EC2 Systems Manager, que es un servicio de administración que ayuda a recopilar automáticamente el inventario de software, aplicar parches del sistema operativo, crear imágenes del sistema y configurar los sistemas operativos Windows y Linux.
Básicamente, AWS está llenando los vacíos en tu cadena de herramientas SbD existente, uniendo muchos de los controles descritos anteriormente y permitiéndote definir y rastrear configuraciones del sistema, prevenir desviaciones y mantener el cumplimiento del software. Aunque EC2 Systems Manager fue eclipsado por varios lanzamientos más dignos de titulares, el servicio marcará una diferencia significativa para los equipos de cumplimiento en la nube.
En el futuro, espera que AWS y otras plataformas en la nube lancen herramientas más completas que faciliten a las empresas lograr SbD en la nube. Las herramientas existen actualmente; pero ensamblar estas herramientas en un marco sólido puede ser un desafío para la mayoría de los equipos de TI. Espera que las empresas se vuelvan hacia socios centrados en la seguridad para cubrir la brecha de habilidades.