MSDN Magazine > Inicio > Todos los números > 2006 > November >  Extensión de SDL: Documentación y eva...
Extensión de SDL
Documentación y evaluación de las garantías de seguridad de las aplicaciones
Mark Novak

En este artículo se analizan los siguientes temas:
  • Análisis de la seguridad en las características de las aplicaciones
  • Los requisitos de seguridad con más detenimiento
  • Una extensión de diseño de seguridad de arriba abajo para el ciclo SDL
  • Exposición de detalles para usuarios y expertos
En este artículo se utilizan las siguientes tecnologías:
Ciclo de vida de desarrollo de seguridad (SDL)
El diseño de software y el trabajo de desarrollo interno de Microsoft, denominado Ciclo de vida de desarrollo de seguridad (SDL, del inglés Security Development Lifecycle), está llegando a su madurez y empieza a difundirse y adoptarse fuera de la empresa. Esto es así en parte gracias al éxito del libro The Security Development Lifecycle (El ciclo de vida de desarrollo de seguridad), de Michael Howard y Steve Lipner (Microsoft Press®, 2006). El éxito de SDL está bien respaldado: un software desarrollado de acuerdo con las recomendaciones y requisitos estipulados por SDL es un software mucho mejor protegido contra posibles ataques. Aun así, a pesar del éxito, el software desarrollado según los requisitos de SDL sigue sin responder a una pregunta básica que muchos clientes se plantean: ¿qué características de seguridad ofrece realmente el producto?
En este artículo voy a presentar un caso práctico de una extensión de SDL, la cual, si se adoptase, se traduciría en un flujo de información mucho mejor entre los usuarios y los diseñadores de funciones de seguridad de los productos de software. Considero que es necesario reconocer que la seguridad del software no es sólo cuestión del cumplimiento de unas normas. Más bien, es un conjunto de características clave que se pueden y deben documentar, evaluar y usa a la hora tomar decisiones de compra. Las características de seguridad (me gusta llamarlas garantías de seguridad del software) son complejas y se presentan en muchos niveles. En un nivel más superficial, comprensible para la mayoría de los usuarios, deben describirse en el lenguaje comercial de trato con el cliente. Los detalles técnicos de nivel más interno, destinados a los expertos, deben estar disponibles para quienes estén deseosos de comprender la tecnología utilizada puedan examinarlos.

Análisis de seguridad
El análisis del software necesario para diseccionar sus garantías de seguridad lo realizarán, para estar seguros, tanto piratas informáticos malintencionados como investigadores de seguridad legítimos que inevitablemente le darán la vuelta al código para extraer sus propias conclusiones. Desgraciadamente, en el mercado actual de software la mayoría de los clientes sólo llegará a averiguar que su software es vulnerable si se descubre un error de diseño, se difunde y se aprovecha. Esta situación en la que se encuentra el sector de software se contrapone al principio fundamental denominado principio de Kerckhoffs (o máxima de Shannon), el cual dice que la implementación es pública: el cuerpo de seguridad depende íntegramente de la clave secreta que garantiza acceso sólo por partes autorizadas. Esto no quiere decir que la comunidad de desarrollo de software se apoye demasiado en el método de seguridad basado en el secretismo, o que todos los proveedores de software tienen que dar a conocer su tecnología como código abierto. El problema subyacente que quiero señalar es que el software de hoy en día se desarrolla y distribuye en gran medida de una manera más acorde con los dos principios siguientes:
  • Se usan prácticas de ingeniería de software lógicas durante la implementación
  • Se aplican revisiones ante las vulnerabilidades encontradas por los piratas informáticos una vez implementado el software
Sin embargo, hay un elemento clave que se pasa por alto. Se trata de reconocer que cada una de las características de seguridad y cada parte de su implementación diseñada para garantizar un producto más seguro debe hacer referencia bien a una característica explícita o a una garantía de seguridad implícita proporcionada por el producto. Esto es lógico, ya que universalmente se reconoce que cada componente del software se construye sobre la base de sus requisitos funcionales. Mi primera regla importante es esta:

Es necesario diseñar y desarrollar software acorde con los requisitos de seguridad que explícita e implícitamente buscan los usuarios.

Como profesional de la seguridad, presto especial atención a las garantías de seguridad del software. Hace poco tuve que elegir un paquete de software para hacer copias de seguridad de mis archivos. Como casi todos los usuarios, los datos del PC portátil de los que quería hacer las copias de seguridad contenían información confidencial, personalmente identificable y de carácter financiero (como archivos de Microsoft® Money). Los datos del equipo portátil están protegidos con el Sistema de cifrado de archivos (EFS), por lo que me siento bastante seguro en caso de que se perdiese o me lo robasen. No obstante, la idea de hacer copias de seguridad de mis datos en mi querido dispositivo de almacenamiento conectado a una red (NAS) (un hardware caro y fabuloso, objetivo muy atractivo para un posible ladrón) me preocupa. Me gustaría estar seguro de que un ladrón no pueda recuperar los datos almacenados en el dispositivo NAS. Así pues, el software que compre tendrá que ajustarse a mis requisitos de seguridad y también demostrarme que efectivamente los cumple.
Empecé por buscar en Web reseñas y comparaciones de diferentes paquetes de software. Descubrí sitios dedicados con prácticas tablas comparativas. Pude encontrar información sobre decenas de características relacionadas con la realización de copias de seguridad, como creación de imágenes de discos, tipos de copias de seguridad compatibles (incrementales, de reflejo...), tipos de medios compatibles (NAS, CD-ROM, etc.), expansión de unidades, copias de seguridad del Registro, uso de programaciones y acceso a archivos bloqueados.
No obstante, sobre el tema de la seguridad, encontré tan sólo dos líneas de información: protección de copias de seguridad mediante contraseña y cifrado de contraseñas para copias de seguridad. Veamos más en detalle por qué clasificaciones como esta, tan típicas de los proveedores de software a la hora de abordar las funciones de seguridad, harían fruncir el ceño a cualquier conocedor del tema de seguridad.
Para los recién llegados, ¿qué es exactamente "protección de copias de seguridad mediante contraseña"? Los autores del sitio de la reseña decían: "Software de copia de seguridad que le permite agregar una contraseña a la copia de seguridad para restringir el acceso." Todos y cada uno de los paquetes de software reseñados ofrecía esta supuesta característica. Pero ninguno de los paquetes explicaba qué quería decir esto realmente.
¿Qué grado de protección tengo si protejo mediante contraseña mi copia de seguridad en un dispositivo NAS? Lo más probable es que el esquema de protección se parezca al que se puede observar en la figura 1. Parece que el archivo estará protegido siempre que se utilice el software de copia de seguridad para tener acceso. En la ilustración, el usuario del equipo portátil debe proporcionar la contraseña al software de copia de seguridad, que la comprobará y recuperará la copia de seguridad para el usuario. Sin embargo, el atacante no tiene que molestarse con tan caballerosos modales: basta con que entre en la red cuando el archivo se esté transfiriendo o que robe el servidor de archivos (u obtenga acceso a él de otra forma) para poder tener acceso al archivo. Si el atacante tuviera acceso a la copia de seguridad sin cifrar, en realidad el sistema de protección mediante contraseña no ofrecería ningún tipo de seguridad adicional. Aunque suene cascarrabias, cuestiono el hecho de que los desarrolladores de software ni siquiera se molesten en diseñar este tipo de características.
figura 1 problemas con protegido mediante contraseña las copias de seguridad 
Por un lado, la solución de protección mediante contraseña no empeora las cosas, así que, ¿por qué preocuparse? Detengámonos un momento y pensemos en qué es lo que entiende el usuario. La noción de protección de copias de seguridad mediante contraseñas implica un sentido muy distinto con respecto a la garantía de seguridad de lo que se está proporcionando en realidad. Para la persona no iniciada, la protección mediante contraseñas significa que el que no conozca la contraseña no podrá recuperar los datos. En este caso, la característica de protección de copias de seguridad mediante contraseñas es engañosa, lo que me lleva a mi siguiente regla.

Evitar introducir características en el software que impliquen garantías de seguridad defendibles pero que no puedan proporcionar.

Desacreditada así la opción de protección mediante contraseñas, ¿qué ocurre con la otra opción, el cifrado de las copias de seguridad? Si se implementa correctamente, esta opción puede proporcionar una garantía de seguridad sólida, aunque sigue habiendo muchas cosas que pueden fallar. Según la descripción de esta característica que hacían los proveedores de software de copia de seguridad, no pude determinar si realmente funcionaría o no (y prefiero no darle la vuelta al código del software para dar con la respuesta).
En mi trabajo con el equipo de Secure Windows® Initiative en Microsoft, siempre he mantenido que los desarrolladores que diseñan e implementan lógica que utiliza algoritmos criptográficos primero deben demostrar su capacidad para escribir código criptográfico correctamente. Lo que sigue es una lista incompleta de problemas que podrían surgir si no se implementan correctamente los esquemas de cifrado de copias de seguridad.
Peligro n.º 1 Usar criptografía débil. Un problema evidente que puede presentar un algoritmo débil, como el cifrado RC4 de 40 bits, es que se puede adivinar por fuerza bruta en un día con el hardware actual, y eso sin optimizaciones complejas. Naturalmente, me gustaría usar el algoritmo criptográfico más fuerte posible, como el estándar de cifrado avanzado (AES) de 256 bits, y (soñar es gratis) que el software se adapte perfectamente a los posibles sistemas de criptografía más seguros que vayan apareciendo en el futuro.
Peligro n.º 2 Usar criptografía segura incorrectamente. Supongo que hacer una copia de seguridad incremental de un conjunto voluminoso de archivos requeriría que el software de copia de seguridad tuviera acceso al contenido de la copia de seguridad existente de otra forma que no fuera secuencial. Una forma fácil (incluso tonta) de dar permisos de escritura y lectura de datos cifrados mediante acceso aleatorio consiste en desactivar la característica predeterminada de la mayoría de los cifrados de bloque que se denomina CBC (encadenado de bloques de cifrado). Este modo poco seguro, denominado ECB (libro de códigos electrónico), aparece ilustrado en la figura 2. Como se puede ver, la imagen del centro, donde se usa el cifrado con ECB, no oculta gran cosa. La verdad es que yo espero más protección de un software de copia de seguridad...
figura 2a texto sin formato 
figura 2b el cifrado de libro de códigos electrónico (ECB) 
figura 2c el cifrado de encadenado de bloques de cifrado (CBC) 
Peligro n.º 3 Uso incoherente de la criptografía. ¿Sería posible para un atacante obtener los nombres de los archivos y directorios de los cuales se está realizando la copia de seguridad? Incluso si los archivos están bien cifrados, se puede obtener mucha información de los nombres de los archivos y de los directorios que hay en la unidad. Si robase el archivo de copia de seguridad de un ejecutivo y encontrase un archivo cifrado llamado Plan de compra comparado para Contoso.xls, puede que no tenga que seguir leyendo, sólo el nombre ya revela mucha información.
La lista de posibles problemas de seguridad puede ser bastante larga. Si el software tiene una característica de actualización automática (como la mayoría de los productos de software), ¿cómo sería de fácil para un atacante anunciar una actualización falsa e instalar su código en la máquina del usuario? Se supone que el software obtiene las actualizaciones a través de un canal seguro, y que se comprueba que la actualización esté firmada por su autor antes de instalarla... Pero, ¿cuándo fue la última vez que se aseguró de que se hacía correctamente?
Ahora hablaré de mi regla tercera y última, para después pasar a proponer cómo creo que deben abordar estas tres reglas de forma colectiva los diseñadores de software.

Publicar información suficiente sobre el diseño de las características de seguridad para convencer a los usuarios de que se trata de un diseño sólido.

No todo el mundo podrá comprender esta información técnica, por lo que no necesariamente se tiene que incluir en la primera página del folleto comercial. Los proveedores de software no dudan a la hora de presentar a los usuarios voluminosos acuerdos de licencia, pero a menudo se olvidan de dar a conocer información igualmente importante acerca del diseño del sistema de seguridad del software. En la actualidad, no obstante, sólo hay dos maneras de evaluar las funciones de seguridad de un producto: consultar a otras fuentes, por ejemplo a los asesores del CERT, para saber cuáles son las vulnerabilidades conocidas, o recurrir a la ingeniería inversa del producto (infringiendo posiblemente así el acuerdo de licencia) para convencerse de que es sólido. Ninguna de las dos es una buena opción.

Diseño de seguridad de arriba abajo
¿Qué se puede hacer entonces al respecto? A la solución que propongo la llamo "extensión de SDL del diseño de seguridad de arriba abajo". Mi método toma como punto de partida el comienzo del ciclo de desarrollo, que es el momento de determinar los requisitos funcionales. En el caso de la creación un producto de software que realice copias de seguridad, los diseñadores pueden determinar varios requisitos, no todos relacionados explícitamente con la seguridad. El desglose de los requisitos funcionales puede ser algo parecido a lo que se muestra en la figura 3.

Ejemplos de requisitos funcionales
Compatibilidad con diferentes tipos de copias de seguridad Incremental
Reflejo
Sistema completo
Compatibilidad con diferentes tipos de medios Sistema de archivos local
NAS
Servicio web en línea
CD y DVD
Compatibilidad con copias de seguridad cifradas Elección por parte del usuario del nivel de seguridad del cifrado y algoritmo
Compatibilidad con custodia de claves
Compatibilidad actualizaciones en línea A petición
Compatibilidad con programación de copias de seguridad Programadas
El paso siguiente consiste en examinar esta lista con ojo crítico para ver las garantías tanto explícitas como implícitas. La mejor manera de comprender este paso es preguntándose lo siguiente: "¿qué características de seguridad inclinarían al cliente a comprar mi producto?" Es aquí donde resulta útil contar con experiencia en el ámbito de la seguridad, y también donde la especificación de las funciones debe coincidir con el modelado de amenazas, un vínculo crítico que se está pasando por alto. En la figura 4 se amplía la lista de características especificando consideraciones de seguridad para un subconjunto de cada característica. Para ello agregué una columna nueva con requisitos que demandaría el usuario final y las consideraciones de diseño de nivel superior que los habilitarían. Las consideraciones se priorizan según su importancia en el contexto global de seguridad de los productos. Por ahora las incluyo informalmente en tres categorías: Alta, media y baja. "Alta" significa que la característica es clave y debe estar presente en el producto. "Media" significa que se trata de una característica importante que el usuario debe conocer y tiene que poder utilizar. "Baja" significa que se puede omitir, ya que el nivel de protección adicional es en realidad insuficiente o poco práctico.

Ejemplos de requisitos funcionales Consideraciones de seguridad
Compatibilidad con diferentes tipos de copia de seguridad Incremental,
Reflejo,
Sistema completo
Media Cuando los usuarios restauran copias de seguridad, pueden estar seguros de que los datos no se han manipulado. Saben que los datos confidenciales no se verán comprometidos si caen en las manos equivocadas.
Compatibilidad con diferentes tipos de medios Todos los tipos Las consideraciones son necesariamente específicas del tipo de medio en cuestión.
Sistema de archivos local Los datos de los que se ha hecho copia de seguridad estarán tan seguros como los originales. Por ejemplo, el software avisará a los usuarios si se intentan guardar copias de seguridad de los archivos en ubicaciones a las que pueden tener acceso otros usuarios.
Alta Se permite a los usuarios averiguar si el destino tiene acceso controlado estrictamente mediante listas, especialmente si varios usuarios utilizan el equipo.
Media Es posible la compatibilidad con cifrado, pero sólo será relevante si los datos originales están protegidos mediante EFS, ya que coexisten en el mismo sistema de archivos.
NAS Los datos de usuario estarán protegidos de ser difundidos y manipulados incluso si el atacante ha obtenido acceso al dispositivo de almacenamiento remoto o al tráfico de red.
Media La transferencia de datos es segura en caso de manipulación e interceptación. Esto resulta menos preocupante si los datos están ya cifrados, dependiendo del algoritmo elegido.
Alta Los datos se cifran para defenderlos de posibles accesos en transferencias de red o dispositivos NAS.
Baja Es posible utilizar listas de control de acceso, pero probablemente no sean muy confiables, ya que el hardware remoto puede estar bajo control administrativo diferente.
Servicio web en línea Los usuarios saben con qué servicio remoto se están comunicando. El servicio tiene acceso sólo a texto cifrado y no hay texto sin formato. Así, los servidores no pueden pasar datos de un usuario a otro, ni por mandato judicial. El software ayudará a los usuarios a elegir una contraseña segura. El servicio no permitirá el acceso a nadie que no sea un usuario autorizado, ni tampoco permitirá que se actualicen o eliminen sus archivos.
Alta La autenticación del servidor sería obligatoria para realizar transferencias de forma segura.
Alta Ningún dato debe salir del equipo sin ser cifrado previamente en caso de que los datos de los que se ha realizado la copia de seguridad pasen a personas no autorizadas o incluso en caso de mandato judicial.
Alta Una autenticación segura garantiza que los datos sólo estén disponibles únicamente para la parte autora.
CD y DVD Los datos estarán a salvo incluso si el CD o el DVD con la copia de seguridad del usuario se pierde o es sustraído.
Media Los usuarios son conscientes de las implicaciones de seguridad en caso de perder los medios de copia de seguridad.
Alta Los usuarios pueden crear copias de seguridad cifradas.
Compatibilidad con cifrado de copias de seguridad El usuario elige el algoritmo criptográfico y el nivel de seguridad de la clave El algoritmo elegido puede variar según el destino de la copia de seguridad. Por ejemplo, podría ser necesario establecer diferentes mecanismos de equilibrio entre rendimiento y funcionalidad para el sistema de archivos local frente a las copias de seguridad en línea.
Alta Garantiza que la clave se administre correctamente (por ejemplo, que no se almacene con el archivo de copia de seguridad).
Media Información de usuario sobre el nivel de seguridad de la contraseña o la clave elegida.
Alta El posible atacante no puede recuperar información de metadatos acerca de los archivos de los que se han hecho las copias de seguridad (por ejemplo, nombre, atributos o secuencias alternativas). Se aplica el mismo nivel de seguridad de cifrado tanto al contenido como a los metadatos.
Alta El nivel de seguridad de la protección criptográfica no se reduce debido a la necesidad de acceso aleatorio de alto rendimiento a los datos.
Baja Según avanza el campo de la seguridad van apareciendo nuevos algoritmos.
Compatibilidad con custodia de claves Los usuarios pueden recuperar archivos incluso si olvidan la contraseña que utilizaron para cifrarlos.
Alta No es posible recuperar la clave de la custodia si no se dispone de información que sólo conoce el usuario.
Compatibilidad con actualizaciones en línea Programadas, A petición A la hora de actualizar el software de copia de seguridad, los usuarios pueden estar seguros de que las actualizaciones proceden de una fuente de confianza.
Alta El atacante no puede anunciar actualizaciones falsas o código malintencionado en el equipo del usuario.
Alta A menos que vayan firmadas por el editor original, las actualizaciones no se instalarán.
Baja Las actualizaciones se limitan al software; no modifican ninguna otra parte del entorno operativo.
Alta El atacante no puede manipular el algoritmo de programación para impedir que se realicen copias de seguridad.
Alta El atacante no puede reducir el nivel de seguridad de la operación de copia de seguridad (por ejemplo, manipulando la configuración).
Compatibilidad con copias de seguridad programadas Programadas, a petición Los usuarios tienen pleno control sobre la programación de las copias de seguridad. Un atacante no puede manipular la configuración de la función de copia de seguridad para reducir la eficacia de las protecciones seleccionadas por los usuarios.
Media El atacante no puede manipular el algoritmo de programación para impedir que se realicen ciertas copias de seguridad.
Alta El atacante no puede reducir el nivel de seguridad de la operación de copia de seguridad (por ejemplo, manipulando la configuración).
La larga lista de la figura 4 no es en absoluto exhaustiva, pero ilustra el concepto de que las consideraciones y garantías de seguridad pueden aplicarse a muchas características del software, incluso las superficiales que no son esencialmente características de seguridad. Tener en cuenta los requisitos, conjuntamente con las garantías de seguridad asociadas, resulta clave para comprender cuál es el abanico total de protecciones que ofrece el software. Si fuese a evaluar paquetes de software, ¿no cree que contar con este tipo de lista de garantías de seguridad le ayudaría a decidirse a la hora de comprar el producto? ¿No decantaría la balanza en favor de un producto en lugar de otro? Yo creo que sí.

Revelación de detalles
Creo que es importante mencionar un par de puntos más: el trabajo no termina aquí, y documentar las garantías de seguridad no significa necesariamente dar a conocer los secretos comerciales.
Está claro que explicar cuáles son las garantías de seguridad es bueno, pero se hace primordialmente para formar al personal de ventas y producir material de marketing. Al pasar de la fase de diseño a la de implementación, es fundamental que las decisiones adicionales no invaliden las garantías de seguridad ya indicadas en el nivel de los requisitos.
De hecho, la programación de copias de seguridad puede realizarse a través de un servicio dedicado. Esto da lugar a más consideraciones: ¿está este servicio de programación adecuadamente aislado de otro software, potencialmente malintencionado, que se pueda estar ejecutando? Si funciona junto con otros procesos del mismo servicio, ¿qué rutas de elevación adicionales se presentan? ¿Qué nuevos caminos abre esto a posibles ataques? Por ejemplo, alguien con capacidad para definir la hora del sistema podría cambiar la programación de las copias de seguridad. ¿Es eso importante? No hay duda de que habría de tenerse en cuenta y se deberían dar a conocer sus efectos, por lo menos para poder contar con esta información en el futuro, en caso de que cambie el panorama de la seguridad. ¿Qué mecanismos de comunicación entre procesos está abriendo? ¿Cómo se aseguran estos canales? ¿Existen prácticas recomendadas para implementar de un modo seguro lo que usted desea?
En este punto, también puede estudiar la solución propuesta y decidir si incluye garantías de seguridad adicionales. Por ejemplo, se puede dedicar el software de copia de seguridad a detectar archivos del sistema y otros archivos críticos que hayan sido manipulados desde que se realizó la última copia de seguridad, y alertar al usuario de los incidentes ocurridos.
Consideremos ahora cómo coexiste este método con el aspecto de los secretos comerciales. A medida que se van analizando con mayor detenimiento las características de seguridad (desde los requisitos hasta la implementación, pasando por el diseño), van surgiendo más y más detalles técnicos. Podría interesarle patentar su algoritmo criptográfico para realizar copias de seguridad cifradas incrementales de alto rendimiento. Seguramente desee mantener en secreto u ocultos los sistemas de protección de custodia de claves (no es una buena opción, aunque se trata más bien de una decisión empresarial). Un investigador o un revisor técnico podría considerar que se trata de una función crítica y hacerle más preguntas. Nada en este enfoque de ingeniería de seguridad puede impedirle decidir que el algoritmo debe estar disponible para los revisores que estén dispuestos a firmar un acuerdo de no difusión. También puede optar por contratar a empresas de investigación sobre seguridad para que revisen su solución y ofrezcan su aprobación pública en cuanto a la capacidad de su diseño e implementación. Los clientes podrían entonces confiar en su producto basándose en la reputación de la empresa de investigación, en lugar de en un conocimiento propio del funcionamiento interno de la solución.
En resumen, el método aquí presentado es lo que yo entiendo como el vínculo que falta en SDL: unir un diseño e implementación seguros del software directamente a las especificaciones de las características de seguridad, de forma comprensible por los clientes, independientemente del nivel de profundidad que requieran (siempre que lo permitan los términos de la licencia). En mi opinión, este es un avance prometedor en el diseño de software seguro.

Mark Novak es jefe de desarrollo de seguridad de Microsoft. Pustilnik, que empezó a trabajar con Microsoft en 1995, ha dedicado los últimos años a diferentes aspectos en materia de seguridad de software. Si lo desea, puede ponerse en contacto con Mark en la dirección markpu@microsoft.com. Mark agradece a Adam Shostack sus sugerencias, así como la revisión del presente artículo.

Page view tracker