Incorporando seguridad en el software program


Parte 1 de una serie de dos partes sobre cómo asegurar el aprendizaje automático.

Cada década más o menos, tenemos la oportunidad de construir seguridad a medida que un nuevo campo florece en el mundo. La seguridad móvil proporcionó una de esas oportunidades hace aproximadamente una década. Aunque se sabe que las personas de seguridad se quejan del estado de la seguridad de los teléfonos móviles en comparación con, por ejemplo, Home windows 95, eso es como comparar el día con la noche.

Avance rápido hasta hoy. Uno de los desarrollos técnicos más importantes que estamos experimentando actualmente en tiempo hiperreal es el «Renacimiento AI». La IA y, en unique, el aprendizaje automático (ML) han existido durante décadas, pero el resurgimiento de la tecnología de ML impulsada por un increíble poder de cómputo moderno y colecciones inimaginablemente grandes de datos bien organizados ha impresionado incluso a las barbas grises más escépticas.

Por supuesto, la seguridad tiene un papel importante que desempeñar en ML (no usar ML para seguridad, eso sí, pero más bien asegurar la tecnología ML en sí misma). En esta serie de dos partes, exploraré la seguridad de ML a través de la lente de la seguridad de la construcción. Comenzaremos con una actualización rápida sobre la seguridad del computer software.

7 puntos de contacto para la seguridad del software
En mi libro de 2007 Seguridad de program, Defino y analizo siete puntos de contacto para la seguridad del program. Los puntos de contacto se crearon intencionalmente con referencia a artefactos de software (piense en el código fuente o en los casos de prueba) en lugar de cualquier proceso individual para crear los artefactos. Como resultado, se desarrollan ciclos de vida como la metodología de cascada. De hecho, los puntos de contacto no son una metodología de software en absoluto están destinados a ser independientes del proceso.

Los puntos de contacto son una mezcla de actividades destructivas y constructivas. Las actividades destructivas son sobre ataques, exploits y software de última hora. Este tipo de cosas están representadas por el sombrero negro (delito). Las actividades constructivas son sobre diseño, defensa y funcionalidad. Estos están representados por el sombrero blanco (defensa). Ambos sombreros son necesarios:

Mi logotipo de sombreros de vaquero yin / yang anterior se basa en el entendimiento de que la buena seguridad combina ofensa y defensa en un equilibrio inextricable.

En el pasado distante, presenté los puntos de contacto de seguridad del program en orden de izquierda a derecha. Aunque eso funciona bien, un mejor enfoque pedagógico es ordenar los puntos de contacto por su utilidad purely natural y presentarlos en algún tipo de clasificación. Algunos puntos de contacto son por su propia naturaleza más poderosos que otros, y los más poderosos deben adoptarse primero.

Aquí están los puntos de contacto, en lo que considero el mejor orden de efectividad:

1. Revisión del código: Revisar el código fuente con una herramienta automatizada como Coverity, Fortify o SpotBugs es una excelente manera de llevar a cabo este punto de contacto. Este punto de contacto encuentra (y con suerte corrige) errores de seguridad.

2) Análisis de riesgo arquitectónico (ARA): A veces llamado incorrectamente «modelado de amenazas», ARA busca identificar, clasificar y mitigar defectos de diseño. Las fallas de diseño representan el 50% de los defectos de seguridad del application en la mayoría del software package.

3. Pruebas de penetración: Probar dinámicamente un sistema en ejecución para detectar problemas de seguridad es una actividad importante, pero a menudo ocurre después del hecho, lo que hace que las soluciones sean mucho más difíciles y costosas. Tenga en cuenta que las pruebas con lápiz definitivamente no deberían ser el primer y único punto de contacto que emplee.

4. Pruebas de seguridad basadas en el riesgo.: Las pruebas de funcionalidad de seguridad, las fallas de diseño identificadas en un ARA y las pruebas de regresión contra errores de seguridad constituyen pruebas de seguridad basadas en riesgos.

5) Casos de abuso: Muchos proyectos crean casos de uso para comprender cómo debe funcionar un sistema. Los casos de abuso ayudan a determinar qué hará un sistema cuando esté bajo ataque. Pensar en el mal uso antes de que ocurra es muy poderoso.

6) Requerimientos de seguridad: ¿Qué tan seguro debe ser su sistema? ¿Quién lo atacará y por qué? Y lo más importante, ¿cuánto puede permitirse hacer al respecto? Estas son preguntas abordadas en los requisitos de seguridad.

7. Operaciones de seguridad.: Incluso un sistema que está diseñado para la seguridad, probado correctamente con el lápiz y depurado durante el desarrollo estará sujeto a ataques. Vigilar un sistema en ejecución (y facilitar esa tarea) es parte de las operaciones de seguridad.

En el campo, los puntos de contacto han evolucionado con el tiempo en prácticas bien entendidas (algunas mejor entendidas y practicadas que otras). Muchos aspectos de los puntos de contacto se pueden encontrar, por ejemplo, en las 119 actividades definidas y medidas por el BSIMM.

Cuando una nueva ola de tecnología se extiende sobre la disciplina de seguridad, como la seguridad del código móvil, la seguridad de IoT o la seguridad de ML, un ejercicio importante es pensar en cómo se pueden aplicar los siete puntos de contacto para avanzar en la seguridad.

Cuando se trata de muchas tecnologías, el análisis del código fuente es el punto de contacto de seguridad más fácil de aplicar primero. Por qué ese es el caso debería ser obvio: independientemente del proceso que haya utilizado para obtener su código, su código puede estar sujeto a un análisis estático. Es decir, casi todos los proyectos de software program tienen código. Bueno, hasta cierto punto: el análisis estático de un ensamblaje dinámico de node.js puede no ser posible dependiendo de cuándo, dónde y cómo se ensambla el ensamblaje. De hecho, el cambio a lenguajes dinámicos está teniendo un profundo impacto en la efectividad básica de la revisión de código utilizando una herramienta de análisis estático.

Del mismo modo, un enfoque DevOps eleva la importancia de las operaciones de seguridad (punto de contacto 7), que ahora se define en el propio código. Los contenedores son código y la configuración del contenedor es código. ¡La orquestación de contenedores también es código! Por lo tanto, asegurar un sistema por diseño obviamente debe incluir aspectos operativos que pueden haberse dejado a los técnicos de TI en el pasado.

Todos los detalles a un lado, hay un acuerdo essential básico de que los puntos de contacto de seguridad del software tienen un papel essential que desempeñar en la protección del application (un campo a veces llamado seguridad de la aplicación).

En la segunda parte de este artículo, exploraremos estos puntos de contacto y la strategy misma de cómo la construcción en seguridad se aplica a ML.

Aprenda de los expertos de la industria en un entorno propicio para la interacción y la conversación sobre cómo prepararse para ese «día realmente malo» en ciberseguridad. Haga clic para más información y para registrarse.

Gary McGraw es cofundador del Berryville Institute of Machine Studying. Es una autoridad mundialmente reconocida en seguridad de computer software y el autor de ocho libros más vendidos sobre este tema. Sus títulos incluyen seguridad de software package, explotación de computer software, creación de application seguro, … Ver biografía completa

Lectura recomendada:

Más concepts





Enlace a la noticia initial