Hacia una Cultura de la Seguridad

La Internet, entendida en su conjunto como un ecosistema conformado por estándares, protocolos, tecnologías y servicios, no sólo se ha consolidado en pocos años como una pieza fundamental en los modelos de negocio; es también ya una parte vital en el desarrollo y crecimiento socio-económico de las naciones y es un recurso crítico del entramado que conforma y da soporte a los gobiernos en todo el mundo.

De acuerdo al reporte que la UIT publica anualmente, en 2011 un tercio de la población mundial total ya es parte de este gran ecosistema. Esto representa más de 2,000 millones de clientes potenciales a los que los negocios ofrecen sus productos y servicios a través de medios de comunicación electrónicos. También representa más de 2,000 millones de ciudadanos que son beneficiarios de las llamadas iniciativas de gobierno electrónico.

En el artículo “La Internet de las Cosas: cómo la siguiente evolución de Internet está cambiando todo” [1], Dave Evans anticipa que en menos de una década la Internet alcanzará al 60% de la población mundial. En este escenario, para el año 2022 estarán interconectados más de 50,000 millones de dispositivos y objetos físicos. De ser acertadas estas predicciones, en la próxima década la Internet alterará para siempre y de manera irremediable el estatus quo en materia social, política y económica.

En este contexto tecnológico, cada vez más complejo y permanentemente cambiante, se hace patente la necesidad de establecer un entorno de trabajo propicio para garantizar que aquellos requerimientos no funcionales tales como la modularidad, la escalabilidad y la seguridad, sean incorporados de manera sistemática durante las etapas de diseño, desarrollo, pruebas y despliegue de cualquier sistema o servicio informático.

El presente artículo aborda brevemente una de las aristas de este problema: el aspecto de la seguridad durante el desarrollo de los sistemas. Y dentro del universo de la seguridad, en el presente artículo sólamente me abocaré al análisis de riesgos y establecimiento de escenarios de amenazas.

El cristal con el que se mira

Bruce Schneier comenta en su ensayo “La psicología de la seguridad” [2], que la seguridad es tanto una realidad como una percepción. La decisión de implementar o no una salvaguarda se basa en un sistema de criterios que nos lleva a tomar de decisiones en materia de seguridad y que se ve fuertemente influenciados por la naturaleza humana.

De manera inconsciente, tomamos decisiones en materia de seguridad todo el tiempo. Por ejemplo: decidimos cuál es la ruta más segura para llegar al trabajo, hacemos uso del bastón inmovilizador del volante al estacionar el automóvil en una zona que no nos es familiar y optamos por no usar un ascensor que tiene una aspecto viejo y descuidado. La evolución ha dotado a nuestro cerebro con los circuitos necesarios para que no tengamos que hacer un gran esfuerzo para ponderar el riesgo y elegir entre todas estas opciones. Sin embargo, la zona en donde reside este firmware orgánico es una región del cerebro muy primitiva y desafortunadamente es inútil en muchas de las situaciones que nos presenta la modernidad.

Modelado de amenazas

Prácticamente todos los estándares y buenas prácticas en materia de seguridad de la información establecen que cualquier iniciativa para fortalecimiento de la seguridad da inicio con la identificación, evaluación y tratamiento de los riesgos asociados a un sistema o servicio informático.

La organización Software Assurance Forum for Excellence in Code (SAFECode, por sus siglas) en su publicación “Fundamental Practices for Secure Software Development” [3] reporta que la práctica más comúnmente utilizada es el modelado de amenazas. Esta actividad consiste en llevar a cabo un ejercicio durante la fase de diseño del proyecto, en donde el flujo de datos es analizado por un equipo de personas con el objeto de identificar los puntos débiles del sistema y establecer los escenarios en los que estos puntos pudieran ser explotados por un potencial atacante.

A continuación explico algunas de las técnicas más utilizadas para el modelado de amenazas.

STRIDE
suplantación de identidad (spoofing), modificación maliciosa de datos (tampering), no reconocimiento de una acción (repudiation), revelación de información (information disclosure), negación de servicio (denial of service) y elevación de privilegios (elevation of privilege).
Esta técnica consiste en revisar uno por uno cada componente del sistema y determinar si es vulnerable a una amenaza de alguno de estos grupos: Spoofing (suplantación de identidad), Tampering (modificación maliciosa de datos), Repudiation (no reconocimiento de una acción), Information disclosure (revelación de información), Denial of service (negación de servicio), Elevation of privilege (elevación de privilegios). Como se podrán dar cuenta, las siglas STRIDE se forman con la primer letra del nombre de cada grupo.
Por ejemplo, consideremos un sistema ficticio en el que se hace uso de firma electrónica para autorización de pagos. Después de que el grupo encargado de realizar el análisis STRIDE ha revisado los casos de uso del sistema, identificó lo siguiente:
Amenaza #1: El sistema es vulnerable a Repudiation, ya que un usuario con acceso legítimo al sistema puede negar que autorizó una transacción, ya que las bitácoras que genera el sistema sólo consideran el ID de la sesión y no se almacena el identificador del usuario.

Casos de mal uso
Esta metodología ayuda a entender cómo los atacantes podrían vulnerar el sistema. Estos casos se derivan de los requerimientos del sistema y los casos de uso asociados, y muestran cómo un potencial atacante puede evadir o inhabilitar las medidas de protección existentes.

Mientras que un caso de uso describe típicamente cierta funcionalidad que debe realizarse a través del sistema, mediante el caso de mal-uso se define una secuencia de acciones que deben ser completadas para provocar daño al sistema.

La figura 1 muestra un diagrama UML que ejemplifica un caso de mal-uso. [4]

Figura 1. Diagrama UML de un caso de mal uso.

La desventaja de esta metodología es que requiere que el grupo de desarrollo cuente con la asesoría de un experto en materia de seguridad; dicho experto generalmente toma el rol de moderador y facilitador, guiando las discusiones para optimizar los tiempos y las actividades. Otra consecuencia es que esta metodología también suele requerir un tiempo y esfuerzo considerable ya que requiere la participación de otros involucrados además del equipo de desarrollo.

No obstante, al aplicar este tipo de metodología se garantiza que los resultados obtenidos serán:

• Susceptibles a ser comparados en una nueva versión del proyecto,
• Reproducidos en otro punto del proyecto, aún cuando los miembros del equipo original hayan cambiado,
• Incluidos en una construcción de software que esté orientado a procesos.

No siempre contamos con todos los recursos necesarios para aplicar metodologías con toda la formalidad requerida; entonces podemos echar mano de las siguientes herramientas:

Lluvia de ideas
En el caso de organizaciones que no tengan recursos o experiencia en el modelado de amenazas, se recomienda por lo menos tener una sesión de lluvia de ideas donde los miembros del equipo de desarrollo que están a cargo de la arquitectura y diseño comenten y evalúen las potenciales vulnerabilidades que presenta el sistema.

Es importante hacer notar que los resultados de esta dinámica no pueden considerarse exhaustivos, por carecer de una identificación sistemática de las amenazas, principales activos y riesgos asociados. Tampoco es una actividad cuyos resultados sean repetibles, porque depende en gran parte de la experiencia de los miembros del equipo que se integren a la reunión.

Catálogo de amenazas
Contar con un diccionario o catálogo de amenazas es bastante útil, especialmente para que las personas que no son expertas en seguridad puedan entender mejor el tipo de vulnerabilidades a las que pueden estar sujetos sus aplicaciones. Algunos diccionarios de este tipo disponibles públicamente son CWE [5], OWASP [6] y CAPEC [7]. Haciendo uso de estos recursos, podemos aprovechar el conocimiento generado por la comunidad y la industria en materia de seguridad.

Conclusión

En este artículo he listado algunas de las técnicas más comunes para modelar amenazas y así reconocer las vulnerabilidades que pueden tener nuestros sistemas, de manera que podamos actuar para evitarlas o resolverlas. Espero que esta información les sea de utilidad para desarrollar sistemas más seguros.

Referencias
[1] D. Evans. “The Internet of Things: How the Next Evolution of the Internet is Changing Everything”. http://swgu.ru/sg40r4
[2] B. Schneier. “The Psychology of Security”. http://swgu.ru/sg40r5
[3] Autores varios. “Fundamental Practices for Secure Software Development”. SAFECode, 2011. http://swgu.ru/sg40r6
[4] “Misuse case”. Wikipedia. http://swgu.ru/sg40r7
[5] CWE - Common Weakness Enumeration. http://cwe.mitre.org
[6] OWASP - The Web Application Security Project. https://www.owasp.org
[7] CAPEC - Common Attack Pattern Enumeration and Classification. http://capec.mitre.org