Es Modelación de Riesgos (“Threat Modeling”) aplicable a desarrollo para SharePoint?

Con toda seguridad, pero, hasta donde yo lo he visto, nadie lo hace: por las disculpas de siempre, no hay tiempo, el presupuesto no lo permite, tiene que estar listo y funcionando para ayer, o, peor aún, cuando le dices a uno de los “Managers” que se necesita tiempo, dinero y recursos para hacer “Threat Modeling” en un proyecto, se te quedan mirando con esos ojos de vaca embarazada, de tal forma que ya ves la pregunta que se te viene: “Threat qué?”

Para empezar por el final, cuando te salen con esa pregunta, puedes hacer varias cosas: te puedes levantar e irte, dando un portazo de esos que te limpian el cuerpo de toda la adrenalina almacenada; puedes rascarte la cabeza, pensar en el fin de semana que se acerca, y decir muy comedidamente: “olvídelo, cosas que me invento yo…”; o, recurriendo a toda la paciencia que hemos almacenado de tanto consultar el SDK de SharePoint 2007, podemos intentar explicarlo en una cuantas palabras:

“Threat Modeling es una descripción de los riesgos de seguridad que vamos a afrontar cuando nuestra aplicación sea liberada por este mundo lleno de crackers, bandidos, explotadores y aprovechadores, y a la vez (o complementariamente) es una enumeración de los posibles ataques que la aplicación va a tener que resistir. Es decir, poniéndonos el sombrero de un hacker, intentar ver cuáles son los puntos vulnerables y que medidas tenemos que tomar para evitar que tengan éxito. Threat Modeling toma algún tiempo, esfuerzo y recursos (tiempo, personal, dinero) para ser realizada, pero si partimos del precepto de que seguridad es un componente critico de la calidad de nuestra aplicación, y que nuestra reputación como empresa profesional, y los negocios que podamos hacer en el futuro dependen de ella, es imprescindible que lo hagamos”…

Poco a poco iremos viendo que los ojos de vaca preñada se van convirtiendo en ojos de vaca recién parida, y que aunque nuestro manager de pacotilla sigue sin entender ni pio, cuando mencionamos “los negocios que podamos hacer en el futuro” algunos rescoldos de inteligencia se pueden percibir escondidos muy en lo hondo.

Y ahora viene la parte difícil. Hay que explicarle a nuestro amigo el manager (o amiga, pues mujeres no están excluidas de seguir los caminos intrincados y obscuros del alto Management), que Threat Modeling no es una manera de escribir código, sino, por lo general, un documento “vivo”, que puede cambiar frecuentemente, y que enumera en columnas los escenarios peligrosos, la probabilidad de que ocurran, el daño potencial si tienen éxito, la prioridad o importancia que le asignaremos y en qué forma lo podríamos evitar. Además, aunque el documento es deseable de que sea creado por los desarrolladores del equipo, también es deseable que desarrolladores ajenos al proyecto participen pues ello(a)s pueden ver los problemas y riesgos desde otras perspectivas. Y lo difícil de explicar es que ese documento, que servirá como “línea de conducta” para el desarrollo del código mismo va a costar tiempo y dinero…

Como último argumento, cuando ya vamos viendo que no vamos a conseguir ni el tiempo ni el dinero necesarios, es comentar que Threat Management es una parte integral de proceso de desarrollo dentro de Microsoft mismo, dentro de su iniciativa de “Security Development Lifecycle”, y que el máximo gurú sobre el tema, Larry Osterman, trabaja para Microsoft, y tiene un Blog con información valiosísima al respecto (“Confessions of an Old Fogey”), y que Microsoft mismo mantiene un Blog (“Microsoft Application Threat Modeling Blog”) para divulgar el proceso y hacer que se aplique regularmente en proyectos de IT.

Y después de todo esto, después de nuestras sabias palabras y claras explicaciones, a que no saben que pasa… pues sí, tienen razón… nada de Threat Modeling pues no hay dinero ni tiempo ni recursos… a lo mejor la opción de salir tirando la puerta es la mejor…

Pero se me estaba olvidando comentar sobre SharePoint y Threat Modeling, que era de lo que se trataba el asunto. Pues bien, en muchos de los casos, Microsoft ya ha hecho el trabajo para nosotros, pues SharePoint es por sí mismo bastante seguro. Por ejemplo, no tenemos que preocuparnos de autenticación y autorización, pues WSS ya no lo da gratis y por nada. Además, si se aplican las pólizas de seguridad estrictas de CAS, inclusive las WebParts que reciban información desde el mundo exterior se pueden limitar de tal forma que no puedan dañar el sistema (apuesto mi salario del año pasado a que todos los que han desarrollado WebParts lo primero que hacen es poner el “trust level” de SharePoint en “Full”… a ver quien se atreva a tirar la primera piedra y que diga que no es cierto…). Pero de todas formas, un análisis de Threat Modeling en cada proyecto de SharePoint debería formar parte indispensable del diseño y codificación. Digan lo que digan los managers…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Un comentario en “Es Modelación de Riesgos (“Threat Modeling”) aplicable a desarrollo para SharePoint?”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *