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…

Recuperación de desastres, una visita al infierno del software y como todo sale bien en SharePoint

La semana pasada fue semana de parches de Microsoft, y para mi, ha sido una semana en la que el infierno de Dante se me ha quedado chiquito. Mi servidor personal recibe los parches mensuales de Microsoft automáticamente, pero no los instala sin mi permiso. Al final de la semana, revisando sus registros (por pura curiosidad… siempre me llama la atención ver la cantidad de idiotas que pretenden crackear servidores), instalé los últimos parches llegados, y, sorpresa, sorpresa, el servidor no se pudo recuperar en el reboot: nada de nada, solo una pantalla azul de lo más bonita:

Después del pánico inicial, y de intentar todo lo que se me ocurrió (inclusive ni siquiera arrancaba en modo seguro), supuse que algo había salido muy mal en la instalación de los parches, pues el servidor lleva funcionando años sin poner ningún problema, y desde hace más de un año con Windows Server 2003 R2 sin protestar. El servidor tampoco tiene mucho: un servidor de mail (mDaemon), mi instalación personal de SharePoint (WSS 2007), mi deposito de código fuente (Subversion), y una serie de sitios en IIS (DotNet 1.1 y 2.0 y algunos sitios en HTML). Nada importante, dirían ustedes, pero si pierdes tu correo, toda la información que has guardado durante años en WSS y todo tu código fuente, tienes un problema de aquí al otro lado…

Pasado un día y tres nuevas instalaciones en otro servidor, eliminando todas las posibles variables del problema (hardware, software, el gato negro que pasó por debajo de la escalera, etc), las sospechas se confirmaron: si tienes instalado el FireWall ZoneAlarmPro versión 6.5.737.000 en un Windows Server 2003 R2, e instalas el parche MS07-058: Vulnerability in RPC Could Allow Denial of Service (933729), Windows Server 2003 R2 simplemente deja de funcionar, sin posibilidades de recuperación…

Update: Lo acabo de probar en otro servidor (Windows 2033 R2 acabado de instalar y ningún otro programa) con la última versión de ZoneAlarmPro (7.0.408) con los mismos resultados.

Afortunadamente todas las copias de respaldo estaban actualizadas y disponibles, así que no era “más que” instalarlo todo e intentar recuperar la información. Una vez más, SharePoint me ha sorprendido, esta vez favorablemente. Por supuesto que conocía la teoría de recuperación de desastres de WSS, me he leído documentos y documentos al respecto y, por supuesto, le he contestado preguntas a muchos clientes al respecto. Pero una cosa es hablar de caminar por la cuerda floja, y otra caminar por la cuerda floja, y en este caso era MI información la que estaba en peligro.

Pues bien: instalar SQL, hacer un attach de la Base de Datos de contenido de WSS, crear las cuentas de los usuarios de la misma forma que en el servidor viejo, instalar WSS en el mismo puerto que la instalación anterior, ir a la Administración Central -> Administración de aplicaciones -> Bases de datos de contenido, agregar la Base de Datos recuperada en SQL y… redoble de tambor… todo está allí de nuevo! No es necesario ni siquiera revisar los usuarios, todo funciona a la perfección; inclusive un par de manejadores de eventos que le he puesto están configurados y listos para funcionar (después de instalar los dlls en el GAC del nuevo servidor, por supuesto)… a veces te vas a la cama, a las tres de la mañana, después de 18 horas detrás del computador, con una sonrisa de oreja a oreja…

Para acabar rápido, la instalación y recuperación del correo también fue un trabajo de minutos, y después de un par de horas de lucha (por mi propia culpa, la configuración que estaba usando estaba equivocada), Subversion y mi código fuente también estaba listo para ser usado.

En cualquier caso, como me decía un amigo que me ayudo mucho en el trabajo, en estos días es mucho lo que he aprendido… tener copias de respaldo actualizadas de todo (siempre se lo recomiendas a todo el mundo, pero solo hasta que te pasa, entiendes porque son necesarias), mantener los servidores lo más limpios posible (nada de pruebitas de esto o de aquello, solo cosas que funcionan y que están probadas) y, lo que ahora estoy preparando pues nunca lo había hecho, tener una estrategia de recuperación de desastres (si te vuelve a pasar, poder estar de nuevo en el aire en cuestión de horas, no de días) que incluya documentación con los pasos detallados de instalación y configuración de todo. Y cruzar los dedos para que en los próximos parches no salgan sorpresas sorpresivas…

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

Porqué SharePoint Portal Server es Terrible

Otro Blog, otra controversia. Esta vez estamos hablando sobre otro blogger que se ha dedicado a crear audiencia para su blog por el conocido, reconocido y últimamente muy utilizado método de despotricar contra SharePoint (lo que significa que SharePoint se ha convertido en algo importante… “arboles altos atrapan mucho viento”).

Ahora se trata de un artículo de Miguel Angel Carrasco (no me pregunten quien es, pues no tengo ni idea) llamado “Why SharePoint Portal Server is Terrible”, al que me llevó la gente de Datys, con la que estuve una semana hablando intensivamente sobre SharePoint, software y como arreglar el mundo al calor de un mojito bien frio (o, mejor dicho, de litros y litros de mojitos).

Nuestro amigo Carrasco da cuatro razones para calificar a SharePoint como terrible:

1 – Es demasiado complejo para instalar, configurar y personalizar.

2 – Se vende como una solución para organizar compañías desorganizadas. Se vende como un sistema para definir procesos en organizaciones que no tienen procesos definidos.

3 – La manera de usar HTML es brutal, junto a sus archivos CSS

4 – Es una de las aplicaciones mas inflexibles que he usado (él, no yo)

Pues bueno, de nuevo no es mucho lo que hay para decir al respecto. Precisamente cuando estábamos hablando con los amigos de Datys, comentábamos lo fácil que es instalar SharePoint (en realidad, como ejercicio lo hemos hecho en 10 minutos, y eso porque el instalador tiene que crear Bases de Datos y cosas de esas, en donde no es necesaria ninguna intervención humana, pero que toman tiempo). Y la configuración también es bastante difícil: todo funciona directamente out-the-box.

En cuanto a personalización, el autor del blog nos sale con una lista de tecnologías (13 en total) que un desarrollador debe conocer para personalizar a SharePoint. Si, es cierto, y qué? Quien ha dicho que personalizar servidores complejos es fácil? Por algo existen personas como nosotros, que nos dedicamos a ese trabajo tan aburridor…

En cuanto al segundo punto, no tiene en realidad nada que ver con SharePoint. SharePoint es un martillo con el cual puedes construir una casa: si es una casa fea o bonita, no tiene nada que ver con el martillo. Si la organización es desorganizada, SharePoint es la herramienta para organizar información, no para crear los procesos que definen como debe ser organizada.

Tengo que reconocer que el tercer punto es cierto: las hojas de estilo de SharePoint son terribles, y siempre lo han sido. Una de las formas para optimalizar SharePoint es purificar el archivo “core.css”, pero Microsoft nunca lo ha hecho. Hay que decir que SharePoint es terrible por eso?

Finalmente, el cuarto punto dice más sobre el autor que sobre SharePoint. Todas las personas que han trabajado un poco intensivamente con SharePoint precisamente se pierden entre las miles de maneras posibles para hacer cosas. Por no hablar sobre el Modelo de Objetos, que nos permite meternos por todas partes y modificar hasta lo inmodificable. Parodiando al autor del blog, yo diría que SharePoint es terrible porque es tan increíblemente flexible; muchas veces yo quisiera que algunas cosas no se pudieran hacer.

Finalmente, nuestro amigo Carrasco le indica a Microsoft que es lo que tiene que hacer para mejorar a SharePoint (un poco arrogante, pienso yo: él es el poseedor de la verdad, y las cinco mil y pico personas del grupo de trabajo de SharePoint en Microsoft están equivocadas):

1 – Mejorar el motor de búsqueda (pero no nos dice que hay que mejorarle)

2 – No utilizar listas jerárquicas, y enseñar a los usuarios a utilizar nombres correctos para los documentos (es esto un problema que SharePoint tiene que mejorar?)

3 – Hacer la instalación más fácil (mas fácil? Chistoso, pero a lo largo de todo el posting nunca dijo porque era difícil)

4 – Hacer el desarrollo más fácil (en lugar de eso yo le diría a Microsoft: Haga el SDK más completo, probablemente se me está pegando su arrogancia…)

5 – Hacer entrenamiento más fácil (es entrenamiento también un problema de SharePoint?)

6 – Crear estándar XHTML; mejorar los 4MB+ de archivos CSS (bueno, de nuevo, tiene razón, aunque el equipo de trabajo de SharePoint en Microsoft está trabajando fuertemente para integrar AJAX en el producto)

7 – Hacerlo “moldeable” (aunque nunca dice que quiere decir con eso)

Bueno, de nuevo una controversia sobre nuestro producto favorito de nuestro monopolista favorito. A ver qué piensan ustedes…

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