En días de cambios, con nuevos dueños en Sun e incertidumbre para sus distintos equipos conformantes (algunos optimistas como los de OpenSolaris quienes lanzaron su nueva versión 2009.06, mientras los de MySQL tenían incierto su futuro - Monty Widenius, uno de sus fundadores originales, abandonó Sun anteriormente por la dirección que llevaba el proyecto) además del aparente juego con el futuro con otros de los proyectos de Sun (como el exhorto por parte de Larry Elisson, jefe ejecutivo de Oracle, a OpenOffice.org para que se adopte JavaFX), se realizó esta séptima reunión objeto de este resumen. El sábado 13 de junio pasado se dieron cita desarrolladores, programadores, ingenieros informáticos, en sistemas, en computación (muy interdisciplinario el asunto), técnicos, interesados y curiosos a estas dos interesantísimas ponencias: "Hablando en Scrum" y "Seguridad en Aplicaciones Java".

Todavía no eran las 10 de la mañana y ya habían llegado bastantes personas a la charla. Me atrevo a decir que en esta ocasión había más gente antes de las 10 que en cualquier otra (en otras reuniones la gente llega, como si tuvieran cronómetro en mano, en los primeros 10 minutos después de las 10) e inició la primera ponencia en puntito de las 10:04 (generalmente se inicia a las 10:10, como referencia). Para algunos era el regreso después de la influencia de la influenza, para otros, el motivo del tema, para los demás, el mostrar una vez más que la comunidad no sólo es muy ruidosa, sino puntual.

Sergio Acosta comenzó con una aseveración al inicio de su intervención, la cual dejó a más de uno desconcertado: Dijo que la presentación debería llamarse "Por qué SCRUM no funciona". No sabíamos si era una aseveración tipo socrático, un "falso final" (dirían los escritores o adaptadores de telenovelas) o la honesta conclusión de vida, ejercicio que sólo gente como Johannes Keppler (1571-1630) podría tan honestamente aseverar al final de su vida, diciendo sobre todo, la verdad al mundo científico.

Comenzó el Ing. Acosta con los antecedentes de los creadores del concepto de SCRUM, en 1986. Hirotaka Takeuchi (1946-), doctor en administración de negocios y decano de la Graduate School of International Corporate Strategy en la Universidad Hitotsubashi en Tokio, Japón, junto a Ikukiro Nonaka (1935-), profesor emérito de la misma universidad y muy galardonado, hicieron arduas investigaciones en empresas para determinar qué funcionaba y qué no en la administración de conocimiento empresarial. Su estudio "The New New Product Development Game" (1986) apunta que en mercados de tecnología, las empresas innovadoras tenían en común el cambio del paradigma de trabajo en favor de un enfoque holístico, englobador. Ellos acuñaron el término SCRUM al compararlo con el rugby, pues a diferencia del modo de trabajo en el siglo XX, a manera de relevos, donde cada fase es secuencial y separada, los innovadores empezaban a traslapar, y las más productivas a encimar las etapas de producción. Desde la plantación se fabricaban prototipos, es decir, los equipos trabajaban en paralelo. Cual equipo de rugby, todos empujaban poco a poco. Aunque no tenía nada que ver con el desarrollo de software, fue el origen para su aplicación posterior al campo.

Entre sus características, la creación de instancias internas, equipos auto-organizados, las fases traslapadas, el multiaprendizaje que incluye transferencia organizacional y control sutil. Se dirige hacia prácticas ágiles.

En 1993, en la industria del software, AT&T y Bell Labs fueron ejemplos del uso de estas técnicas. Asimismo, en su estudio los autores de este concepto llegaron al ejemplo de Borland. Se sorprendieron del proceso de desarrollo, en particular, de Quattro Pro para Windows: en tiempo récord se llegó a 1 millón de líneas de código, con 31 meses, 8 personas, retando a M$ Excel y Lotus 1-2-3. Su índice de productividad fue directriz para trabajos como Why Software Developers Refuse to Improve (1988, 31(4), 110-112).

Se encontraron en ATT prácticas como juntas de diseño constantes que permitieron mejor comunicación pues sabían qué sucedía en los demás procesos, integración en el equipo de trabajo, introspección, intercambio de ideas, prototipado intenso, equipos multidisciplinarios y especializados, que ahondaron aún más en la productividad.

Otra influencia fue la manera de manufacturación de Toyota (Toyota Motor Corporation). El Ing. Acosta presentó el famosísimo triangulo de proyecto (en inglés le llaman, además de project triangle, iron triangle como comparación al triángulo de acero utilizado como término político de funcionamiento similar, el cual demarca al congreso, la burocracia y el interés de la comunidad) que coloca características, tiempo y costo como vértices de un triángulo, señalando de manera análoga a la ventana de Yohari una premisa: "Elija dos vértices para trabajar durante el desarrollo". Es decir, entre los vértices, sólo se pueden elegir dos de los tres ideales: bueno, rápido y barato. Esos dos elegidos se premiarán en detrimento de la tercera variable. Toyota mostró que se podía ser más eficiente en los tres rubros. Para lograrlo consideran una variable fuera del triángulo, y la llamaron el desperdicio. Al eliminar desperdicio hacen crecer dicho triángulo. Ellos llaman a sus principios como "Mentalidad de reducción del desperdicio": crear calidad, eliminar desperdicio de especificaciones tempranas, respetar a la gente, entregar rápido, delegar y optimizar. A este camino inclusive le confirieron el nombre Kai Zen (camino para mejorar, mejora continua).

Todos estos ejemplos influyeron, para 1995, a Jeff Sutherland y Ken Schneider a escribir sus "reglas del juego" de SCRUM. Divide a los actores en el desarrollo de software como Scrum team (pigs), como quienes están comprometidos con el proyecto, y Team community (chickens), para quienes están involucrados indirectamente en el proyecto.

El Ing. Acosta describió enseguida en qué consiste el concepto de SCRUM. Habló del concepto Sprint como unidad de tiempo: un sprint dura unas 4 semanas, en ella se comienza con un sprint de planeación (4+4 horas), cada día hay un daily scrum de 15 minutos donde se resume qué hizo y qué hará el equipo, en comunicación constante, y al ir terminando, juntas de retrospectiva hablan de reflexión del proceso. Si no salen mejoras de estas juntas, no se hace scrum. La auto-organización sólo funciona si hay automejora.

En Scrum, entregable sólo es el producto. Cada iteración necesita un incremento "potencialmente liberable". El producto debe ser completo, no sólo código: manuales, capacitación. Terminado significa que el programador no debe preocuparse por cosa adicional. Como herramienta, scrum describe el Product backlog (pendientes): una lista de requerimientos con características ordenadas por importancia o valor de negocio, siendo responsabilidad del product owner que esté dicha lista al día.

En scrum debe quedar bien claro qué significa "Done", qué esperan de cada requerimiento los distintos actores en este desarrollo.

Por último, scrum habla de release plan, para acotar tiempos, y del impediment backlog (riesgos típicos del proyecto), con métricas: 1) burndown, 2) velocity, con un diagrama de líneas para demarcar el número de características que faltan por implementar entre el tiempo disponible.

Acto seguido, el Ing. Acosta mostró una lámina más con la leyenda "Scrum sí funciona", alegando la promesa de poder subir las 4 variables del triángulo y mostrando estadísticas donde los autores mostraban el incremento de la productividad en las empresas donde se implementaba este modelo de desarrollo.

Enseguida, otra lámina con la leyenda "Por qué no funciona (cuando no funciona)" donde, para no hacer todavía más extenso este autodenominado "resumen", se subrayará el meollo de este apartado: habla que el enemigo es Frederick Winslow Taylor (1856-1915), ingeniero mecánico y economista gringo, en su papel de padre de la administración. Cierto, su metodología es harto cuadrada, pues dice claramente que sólo los administradores deciden sobre el diseño y desarrollo, y los obreros ejecutan ciegamente.

El pionero de la organización científica del trabajo apuntaba que sólo a partir de la estandarización, la cooperación y adopción obligada se hacen las cosas. El expositor imputó a Taylor la idea que "Quienes forjan el hierro, por el hecho de tener la fuerza física, son estúpidos para entender cómo hacen su propia chamba. Quienes programan, análogamente, no tienen el conocimiento de esta chamba. Si quisieran pensar, estarían como proyect managers".

El expositor marcó que ya no estábamos en la era industrial, empero, todavía se seguían usando sus métodos de producción y desarrollo. Las tareas de hoy día son demasiado complejas. Debe cambiarse la percepción de quiénes saben y quiénes ejecutan. Mientras no se cambie esta mentalidad, scrum no es compatible con dicho contexto organizacional. En la industria del software todos saben. Los únicos ejecutores son los propios compiladores y ensambladores computacionales. Scheider habla de estructuras organizacionales como organismos vivos en The Reengineering Alternative. (1999).

Debe cambiarse el pensamiento: el CEO no es la cabeza, el que manda a los que mandan, sino quienes producen, quedando el CEO como el que sirven a los que sirven, quien ve por el equipo. Por ello el autor de scrum señala (convenientemente) que sólo el 30% de las empresas tendrán éxito en la implementación de scrum. El resto permanecerá en competencia outsourcing/offshoring. Sobretodo porque scrum implica responsabilidad, disciplina, colaboración, transparencia, autocrítica y retrospectiva individual y colectiva, detalles que no todos están dispuestos a dar.

Finalmente, el Ing. Acosta recomendó 3 presentaciones: "10 ways to screw up (with) despite scrum and XP", "10 tips for successfull agile transitions" y "Succeeding with agile: a guide to transitioning", concluyendo que si no existen las dependencias, no construya scrum. Los autores sólo presentaron profesionales altamente especializados como casos de éxito, nuestro expositor, una verdad a todas luces: "Scrum no hace nada: es un framework que ayuda que las disfuncionalidades del equipo sean evidentes".

La fase de preguntas y respuestas fue muy nutrida, con intervenciones muy buenas de parte de los asistentes, demarcando que se debe cambiar y sensibilizar a los vendedores y a los CEO y a los proveedores sobre las formas de actuar, con alternativas, a pesar de lo rígido, cuadrado e inflexible del proceder de las licitaciones gubernamentales. Acto último, el expositor invitó a los interesados a visitar la página http://comunidadscrum.wordpress.com/ para participar de estos temas y hacer comunidad.

---

Durante el breve receso, mientras los invitados compartían experiencias sobre sus lugares de trabajo, debido al confrontamiento de modos de ver y de la sensibilización comentada al cierre de la primera charla, me quedó manifiesto algo que ya sabía, pero no había quedado tan demostrado como al momento: el nivel de preparación de los asistentes a estas charlas es bastante elevado. La exposición presentó en más de la mitad de sus láminas contenido en inglés, y en más de 10 ocasiones apareció al menos una palabra en japonés, escrita en kanji. Hubo una lámina con una frase algo larga en japonés, donde me quedé, ignorante y aislado, pues lo único que vi fue "kono" y desconocí completamente el siguiente kanji. Todos los asistentes, salvo yo, entendieron a qué se refería la frase. Lo único que atiné a decir fue: "sou desu ka" (¿En verdad?) "kono kougi ga rikai dekina ikoto wo kangaerimasen." (Creo que ya no seré capaz de entender esta charla.) En estas líneas escribo mi admiración a Ustedes, profesionales de las ciencias de la computación, por prepararse tan a fondo para poder brindar soluciones de tanto nivel a sus clientes y empleadores. Y si Usted está entre quienes todavía no se animan a asistir a estas reuniones, vea este punto adicional: sorpréndase a sí mismo viendo cómo el código fuente le hace comprender cosas y culturas tan remotas: se verá, por ejemplo, entendiendo claro Japonés en una charla, o entendido de seguridad militar y gubernamental en la siguiente. Si eso no es multidisciplina, no sé qué pueda asemejarse.

---

Tras esta charla parecería que nada podría igualar el nivel de interés. Pues para sorprendernos llegó Enrique Zamudio con la segunda charla, en parte continuación de la charla que nos ofreció hace algunas reuniones, o bien, una serie práctica a manera de recomendaciones puntuales a considerar respecto a seguridad para desarrollar aplicaciones Java. Comenzó enlistando los tipos de protección de aplicaciones, pues su clasificación coincide con la de seguridad de bienes, mencionando una caja fuerte: protección (candado, chasis), detección (guardias vigilando la caja fuerte), reacción (alarma para llamar a los guardias).

Esta charla se centró en puntos específicos a proteger en una aplicación: la autentificación (login), las contraseñas, SQL, sockets, datos y recomendaciones generales. Enumeró vectores de ataque como el suplantar (impersonate, en inglés) a otro usuario, con técnicas tales como el "password crack" mediante fuerza bruta o ataques de diccionario, el interceptar teclados o usando ingeniería social, como el caso del famoso "phishing".

Otro ataque "clásico" mencionado fue la negación de servicio (DoS, DDoS) inundando de "requests" un sitio, la inyección de SQL, los Botnets (virus que esperan comandos desde o a un servidor de IRC), o los ataques de los llamados "script kiddies".

Para evitar los ataques de autentificación (login) el Ing. Zamudio recomendó rutinas para bloquear al usuario tras un número dado de intentos equivocados, el ignorar intentos de login en un rango de segundos, el bloqueo de IP, uso de campos ocultos o mal nombrados (es decir, que el campo no se llame username o password, por ejemplo), los "captchas", la autentificación de 2 factores (algo que tienen y algo que saben), el ponderar estatus de usuarios (que en un sistema de foros, por ejemplo, los usuarios nuevos sólo puedan hacer ciertas cosas), el message digest spam control (similar a un captcha: con una rutina de javascript se pide un algoritmo que haga cálculos muy largos para penalizar un atacante con ciclos de CPU).

Para las contraseñas, el expositor recomendó nunca almacenar en claro, y mucho menos transmitir en claro; digerir, no cifrar la contraseña (md5, sha-1 o sha-256 como opciones), o el forzar a los usuarios el uso de contraseñas seguras pero no muy complicadas.

En el terreno del SQL, usar PreparedStatement siempre con parámetros y el filtrar consultas potencialmente largas (con demasiados resultados) para protegerse.

Para los sockets, filtrar por fuera de la aplicación, un Firewall dedicado, usar paquetes como iptables (componente de Netfilter e incorporado, entre otros, al núcleo Linux) o sistemas de detección de intrusos, validar las conexiones tan pronto como sea posible (comprobar que el usuario sea legítimo antes que cualquier otro método o paso), evitar protocolos propietarios (si ya existe la rueda y el hilo negro...), pero de no ser posible, integrar handshake y autentificación al inicio de la conexión (para legitimar al usuario); recordar que SSL no es la única opción, existen, por ejemplo, VPN, SSH (¡Con llave pública!) o Stunnel.

Tocante a datos, el cifrar datos confidenciales, el manejo de llaves, sea un token o contraseña que el usuario deba suministrar, una llave que necesite el software para descifrar o una llave almacenada localmente para controlar el acceso a producción.

Sobre las aplicaciones, la seguridad debe contemplarse desde el diseño inicial: en cualquier etapa posterior complicará sobremanera el proyecto de no tomarse en cuenta. Deben identificarse los posibles vectores de ataque, el paisaje de vulnerabilidad puede ayudar en el tema. Hacerse de la práctica de dejar logs para post-mortem es buena idea, en texto o base de datos para detectar condiciones anormales con análisis humano o con programas como Splunk (con versión libre y ampliada para deducir patrones de esos logs), alarmas y monitoreo vía correo electrónico, SMS, chat, etc.

Tocante a las aplicaciones Web, considerar a los botnets: hay que validar todos los datos en el servidor además que en el cliente, no valerse de AJAX o del navegador, pues muchos programas pueden emular una petición de navegador; usar alguna capa de protección en HTTP (con Apache/IIS con plugins, etc.), recordando el dicho "zapatero a tus zapatos": JBoss y Tomcat no son Web servers. con JK, parte de Yakarta, Apache, se delegan las distintas funciones. Ellos sólo requieren una medianamente sencilla configuración, y a partir del servidor se puede mandar la parte que le corresponda a JBoss, e incluso pueden mandarlo a distintas instancias en servidores diversos, con ello se gana seguridad, se divide el trabajo y se agiliza la respuesta, pues cada componente hace lo que mejor sabe hacer.

En el terreno Web además, verificar que las pátinas internas no puedan visualizarse por fuera, es decir, que queden disponibles a usuarios no registrados e identificados. Es muy importante no dejar contraseñas predeterminadas de los distintos paquetes o contraseñas en blanco para los componentes (servidor, base de datos, administrador del contenedor,etc.), y obviar las contraseñas como "admin", "root", "sysadmin" o el clásico "12345".

Acto seguido, el Ing. Zamudio ahondó sobre el paisaje de vulnerabilidad, dividiéndolo en 4 aspectos: el mundo físico (la factibilidad que una persona llegue a los equipos tangibles y pueda manipular de cualquier forma su operación), el mundo virtual, el modelo de confianza (quiénes tienen acceso y qué podrían hacer con tal acceso) y el ciclo de vida del sistema (desde su diseño hasta el desplegado existen o no posibilidades de intervención ajena o de "backdoors", por mencionar algunos).

Esta última parte se centró en el mundo virtual. Se mostró un paisaje de vulnerabilidad, un diagrama ondulado, con valles y montañas entre defectos y soluciones: a la inyección de SQL, PreparedStatements parametrizados; al Cross-site scripting, validar, filtrar y codificar entradas; a la ubicación predecible de recursos, buena configuración del servidor Web y contenedor; a la fuga de información, el personalizar las páginas de error, el cifrado de datos y el control de accesos.

En el stacktrace de excepciones a veces se muestran demasiados datos de error al usuario. El usuario no tiene por qué ver stacktrace alguno. Esa es información demasiado sensible y susceptible de prácticas malintencionadas.

Como literatura, el Ing. Zamudio recomendó:

1. Kevin Mitnick: The art of intrusion
2. Bruce Schneier: Secrets & lies (llamado por el ponente como el Chuck Norris de la seguridad tecnológica)
3. Michael Howard: Writing secure code
4. Gary McGraw: Securing Java

Como conclusiones, se mostraron casos individuales sobre ataques y protecciones. Bien se apuntó al señalar que no hay recetas predefinidas para todo, cada aplicación necesita su propio diseño, según su alcance (Internet, una Intranet), el número de usuarios esperados, su tipo (en el más grande de los sentidos), el valor de la información que se maneja, el valor de sus transacciones (entre más es más atractiva para los atacantes), el daño potencial que pueda recibir y hacer una lista exhaustiva para verificarse antes de salir a producción.

Como ejemplo de Dos (Denial of Service, en inglés negación de servicio) se mostró un protocolo simple de 2 bytes de longitud con contenido que podía recibirse parcialmente y con posibilidad de enviar eco de lo recibido. El ataque, abrir tantas conexiones como sea posible, mandar encabezados de mensaje muy largo y enviar pocos datos en intervalos largos de tiempo.

Como ejemplo de SQL, el login de usuario que no usa parámetros. Su ataque, secuestrar la cuenta de administrador, hacer daño a la base de datos y secuestrar todas las cuentas de usuario.

El ejemplo de XSS, el campo de captura simple. Su ataque, el meter HTML o Javascript en los campos.

Mientras el Ing. Zamudio explicaba los ataques, a más de uno dejó serio la facilidad conque se procedía. Particularmente en el ataque de SQL, el ingresar como contraseña ' OR '' = ' en el formulario la aplicación regresaba el mensaje de bienvenida para el primer usuario en la base de datos.

Al asumir que el formulario rellenará la siguiente instrucción SELECT * from US WHERE U='+' AND p='<campo>'OR''='; se pueden ingresar comandos como UPDATE U set p='. Las posibilidades se abrían ante los ojos de los espectadores. Eso por no sanear de alguna manera los mensajes recibidos.

La moraleja que quedó es rayar ligeramente en la paranoia cuando sea preciso: cualquier campo, incluso la barra de direcciones, si no se cuida, puede conducir a una ventana para trasgredir la seguridad de nuestra aplicación Web.

---

Con esto quedó terminada la reunión. Para cerrar con broche de oro, en la hora del refrigerio (del cual mencionaré que no fueron pizzas en esta ocasión, sino baguetes medianos tirándole a grandecitos generosamente preparados con jamón, queso, más queso, aguacate, jitomate, cebollita, crema y todavía más queso) se realizó la rifa de un libro proporcionado por Rodolfo Velasco: un ejemplar de "Beyond Fear: thinking about security in an uncertain world" (ISBN 0387026207, 9780387026206), escrito por Bruce Schneier, hablando no sólo de seguridad y de amenazas a ella, sino de maneras como puede exhortarse a pensar en ella en las agencias de reforzamiento, de los negocios de todos tamaños, nuestros gobiernos y milicias. Una pieza que hizo a más de uno brillar sus ojos. Mientras conversábamos sobre las dos pláticas y la relación con el quehacer de los desarrolladores, experiencias y peripecias, se iba entretejiendo el proceder para la repartición del citado libro. La verdad sucedida en ese proceso tal vez nunca la sepamos. Pero que fue motivo para extender la conversación, lo fue. Y si la gente asistente sabe de debilidades del código, las expresiones se hicieron patentes. Y más cuando se supo quién fue el ganador. Caprichos de la informática. Independientemente de eso, fue un momento extremadamente divertido, al ver qué tanto salía de las bocas de los comensales, con frases como "Se va a caer el sistema del IFE", "Mejor yo confío en los papelitos" y "Entre bomberos no nos pisamos la manguera"

Como se extendió el tiempo de las alegatas, hubo personas que me incitaron a ahondar en este último punto; yo pienso que "palo dado...". Empero, dejo a consideración de Usted, apreciable lector, si vale o no la pena reconstruir los hechos alrededor de este singular evento. De recibir retroalimentación a favor, dedicaré un post. De lo contrario, cierro este resumen dejando esa pregunta al aire, porque siempre existirá alguna pregunta sin resolver. Eso es parte de la vida. Así como esta reunión fue una pequeña porción de la vida muy interesante, divertida y emocionante.

Hacemos referencia a las entradas que publicó Enrique Zamudio, las cuales están en JavaMexico.org:

Ejemplo de ataque de negación de servicio
Ejemplo Cross-Site Scripting
Ejemplo de Inyección de SQL

A manera de advertencia Los dos párrafos anteriores a este reflejan únicamente el punto de vista (más cómico, hilarante o psicópata producto de no tener perro qué pasear (remitirse al epílogo del podcast de Grails.org.mx ep. 7, temp. 0) de quien escribe estas líneas. En ningún momento el staff de sh, grails o javaMexico hacen acusación alguna al proceder del sorteo. La única atribución que puedo hacerles es la de haberse divertido con tanta ocurrencia comentada en ese momento. Pero si desean que enumere todas esas posibles fallas, tengo el código fuente del programa objeto de este último análisis. Ante todo, la transparencia, al fin y al cabo esta reunión se hizo en tiempos electorales.

Fe de erratas Originalmente este texto incluía kanji (ideogramas japoneses) para intentar transmitir la sensación de las láminas que el Ing. Acosta proporcionó con algunas piezas de escritura compleja. En la versión previa se veían, pero no sé por qué ya no se visualizaron en la versión enviada. Pido disculpas si se me hayan escapado kanjis sin arreglar. Hice trasliteración Helpburn en el comentario central. Sírvanse corregir de haberme equivocado.