Ejemplo Practico – Cuando los testers no están capacitados… o al menos no lo suficiente

Este post esta adelantado a su tiempo  – porque tenia que salir antes otro post – , pero la situación lo amerita.

Antes que nada, estoy consiente de que este bug es algo difícil de encontrar, pero por el tamaño de la victima, es imperdonable.

 

Hace unos cuantos días salió un otro parche critico  al IE, este bug (súper critico) al parecer a estado unos 9 años en el mercado, solo que hace poco recién a sido sacado a la luz, lo cual  no dice desde cuando a podido ser explotado, ya que hasta donde se,  no todos los bugs son “públicos”, siempre hay algunos que se guardan (para así poder ser usados )…, igual y este no es el caso , igual y si…; aquí lo importante es que ya salió a la luz y de que ya hicieron el parche, para muchos allí queda todo, pero me puse a intentar leer sobre el tema (algunas veces trato de dar seguimiento a los bugs ) y me encontré información en la web  que me pareció por demás interesante :

  • Microsoft acepto que este bug no fue encontrado por sus “testers” o equipos de pruebas, por que “ no no están capacitados para hacer este tipo de pruebas” : me parece algo bueno que hayan aceptado  eso, lo que me parece importante aquí es que Microsoft es una de las mas grandes compañías de software a nivel mundial, así que no tienen la excusa de “no hay dinero” para no haber capacitado a sus equipos de pruebas, será que quizá ellos no tienen / no contratan  personal “realmente capacitado, para el puesto?” , para una empresa de su tamaño, es imperdonable que sus equipos de pruebas, el cual tienen que luchar contra los hackers del mundo y demás dacitos, no hagan todas las pruebas conocidas, por el impacto del producto ( en este caso Internet Explorer ),  y por la cantidad de ataques que recibe, el equipo de pruebas, debería ser de lo mejor, y debería estar capacitado en todos los tipos de ataques posibles, para así poder probarlos. Ojo aquí estoy separando, una cosa es que el equipo no haya encontrado el bug ( por error humano), y otra que no estén capacitados para encontrarlo. quizá debería hacer leer a los de Ms mi post anterior ??? jeje
  • Usar solamente “Herramientas automatizadas, no protege al 100%”  :  bueno para este tipo de casos, hay unas herramientas llamadas Fuzz, o fuzzing, pueden leer mas sobre eso aquí  o aquí tbm ( en este ultimo, salen un listado ), si bien a la hora de hacer pruebas, normalmente se tiene un “check list” de cosas a probar y como probarlas, la realidad es que esa lista no es “todo lo que hay que hacer”, hay que “salirse del libre” y comenzar a hacer pruebas aleatorias, o como dicen algunos “ por instinto”, si de esas que no son ordenadas, de esas que el listado de pruebas no indica ( me viene a la mente la aclaración de Jersson,  a mi ultimo post, que luego terminare de re-aclarar ) , esto es algo que comentare luego, si, muchos “ puristas” de los procesos y metodologías, siempre piden ( o  exigen) que uno siga el libreto establecido, pero en cuestiones de pruebas, seguir “solamente” el libreto, puede ser uno de los peores errores. Se que algunos  dirán “allí dice que no hay casos documentados para este tipo”- en referencia a lo que dice ms con respecto a este bug – , a lo cual les diría … no hay casos  documentados “públicamente”, quizá si los de MS entran tantito mas al IRC, podrían enterarse de mas casos  :) – bueno si, muchos grupos son privados-.

No puedo negar de que en los últimos  tiempos Microsoft se enfoco mas a la seguridad, pero estos 2 últimos bugs críticos ( si, aun no me olvido del otro que salió hace poco ), hacen pensar que quizá no están lo suficientemente capacitados, como se pensaba.

seria bueno que lean los artículos, que a su vez son las fuentes para este mini post:

y como ya puse antes, un listado de Fuzzers : http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html

 

pdta:  este solo es un ejemplo de las cosas que pueden pasar (de  los puntos que mencione en mi anterior post), en la siguiente entrada me explicare un poco mas.

 

Salu2  y nos leemos al rato…

 

Ddaz –Dacito Grinch -


:) Publicacion cruzada desde Geeks.ms :) http://geeks.ms/blogs/ddaz

Seguridad de Aplicaciones I – Preludio y mi opinión sobre la realidad de las empresas y el Testing de Software.

Espero que este sea el primero de varios, sobre seguridad en aplicaciones ( y tantito en servers ), hay varios temas interesantes que tocar ( entre ellos uno de criptografía que me pidió sergio tarrillo, los cuales vendrán luego), tengo algunos post en la sección borradores, esperemos que luego puedan salir.

Preludio

un amigo me pidió que cuente algunas de mis experiencias… y eso me hizo recordar ciertas cosas… y bueno recordando viejos tiempos, cuando empecé a meterme “profesionalmente” a lo de informática ( no cuento lo de servers, eso es otra historia ), por allá en el 2001, empecé como “tester”, ya que era un simple estudiante de Ing.  Química, dentro de una empresa que hacia Software de Ingeniería ( Software especializado para Ingeniería de Procesos, lógicamente de los  Químicos), que solo sabia algo de pascal, assembler, RPL y algo de programación PLC –a excepción de assembler, lo demás nos lo dan en la carrera-, pero con ningún conocimiento formal sobre Ing. de Software, o procesos de desarrollo de software –lógicamente ya estoy cubriendo esa falencia –, empecé en esa empresa formada por ex alumnos de la facultad mi universidad (UNI ), curiosamente me metí a este mundo, por que por los cálculos avanzados de la carrera ( matemáticos y demás), se tenia que realizar simulación de procesos y la universidad solo tenia un “trial – limitado” de la versión actual y la versión full era demasiado antigua como para poder hacer las simulaciones ( la licencia pasaba de los USD $ 250,000.00 ), así que con unos compas empezamos a buscar el “crack”, pero como no existía ( casi no existen de software especializados, por suerte :)), nos pusimos a estudiar ensamblador, y finalmente pudimos usar la aplicación…, lógicamente, ya a estas alturas de mi vida, ya no promuevo el “crackeo ilegal” – si, de eso viene el otro post –, aunque eso hizo posible mi incursión en el mundo del software, ya que me acoplaron a una empresa de ex alumnos, cuando yo aun era alumno. Ya luego logre ver a .Net, me maravillo y comencé a programar allí, me fue gustando mas el mundo de la informática, así que poco a poco  que  termine alejándome del mundo de la  Ing. Química y me fui al software ( discúlpenme que no considere a la  “Ingeniería de software” una ingeniería de verdad – por mas que desde el 2004 “estudio formalmente sobre informática y/o sistemas”  y trabajo en cuestiones   de   software – , pero mi concepto de “ingeniería”  es muy diferente al de los informáticos tradicionales –por mi carrera base- y me es imposible – al menos por el momento- considerarlo una ingeniería. ), luego ya cuando vine a México, me metí al 100% a lo de software :)- en varios campos -, ….

 

Ahora si, ya entrando al tema de este post

Algo que se esta volviendo muy común, en las empresas de software, es que cada vez  están pensando – y ya muchas lo hacen – , el tener un  área de “control de calidad”, o área de pruebas,  (sobre este tema Miguel Llopis tiene varias entradas al respecto, coincido en muchas cosas – con respecto a este tema –, aunque en algunas otras… aun estoy algo escéptico; pero de todas maneras me parece interesante lo que pone ;), léanlo ).

Lógicamente hay muchas empresas que tienen bien estructurada  y organizada su área de pruebas, aunque de todas maneras se les escapan “bugs”, entre ellos tenemos a Microsoft, Google, etc; por lo que e visto en los betas  de MS que ando metido – empecé con el vs 2005 alpha – Microsoft a mejorado mucho su modo de tomar los errores, y como los recibe, desde Betaplace hasta ahora con Connect , y e visto que hablan que tienen sus tester  y demás, pero aun así, se les escapan bugs,  algunos gigantescos, lo bueno es que ahora los  encargados de los productos hacen mayor énfasis a recibir comentarios y sugerencias; pero si asi pasa con una empresa que invierte mucho dinero en pruebas, imagínense como es con las empresas con una mínima o nula inversión al respecto.

A mi parecer, en muchos casos aun veo algunos detallitos al como se aplica la parte de pruebas en las empresas, dentro del desarrollo de software, lógicamente hay empresas que si aplican muy bien esto, y el % de errores que se les escapa es “mínimo”, veamos algunos que pude lograr ver.

 

  • Personal no Especializado  El detalle aquí es que en la mayoría de veces se pone “solamente” a las personas con menos experiencia,  o mejor dicho personas no especializadas en el tema (no estaría mal, que si el equipo tuviera una parte de un tipo y otra del otro tipo ),  o también a personas con un nivel bajo o nulos  conocimientos de programación, los ponen a “usar la aplicación”, si bien al estar considerados como “Usuarios comunes y silvestres” saldrán varios “detallitos”, pero quizá no los mismos que podría sacar alguien con algo mas de conocimientos – aunque como siempre, hay casos que rompen la regla, esos con dones “destructivos”, en los cuales todo lo que tocan falla :) –, pero el detalle aquí es que la cantidad de errores descubiertos, puede ser mínima, comparando con los que realmente tiene  la aplicación, por eso es bueno tener gente especializada, si bien quizá no todo el equipo, pero no debería de faltar alguien especializado,al respecto  también a escrito hace algún tiempo Joel Spolsky  sobre este tema en su articulo Las Cinco Principales Razones (Equivocadas) por las Cuales no tienes Ingenieros de Prueba, aunque el a su vez aclara que es difícil conseguir buenos, y en algunos casos solo podamos ir rotando gente sin experiencia.
  • Tienen un área de pruebas, pero nadie les hace caso :  E visto esto en varias empresas,  donde los programadores, se podría decir que casi ignoran los tickets enviados por los de pruebas, y dicen “ luego los arreglo” – algo que nunca pasa –, es algo ilógico tener un área de pruebas y  que casi nunca se les haga caso, esto en algunos casos es por la mala planeación y  que los programadores estén “contra el reloj” terminando funcionalidad y “no tengan tiempo para corregir”, aunque en otras es culpa de los programadores, pueden ser muchos los posibles motivos,  aunque parezca  algo loco, lo e visto  :);  hasta me  a llegado a pasar ya un par de veces con los team de MS, enviaba bugs y hubo casos en que se demoraban hasta meses para tan solo revisar el error – imagínense en repararlo – , por suerte ya esta mejorando esto, jeje y bueno también tengo un usuario “moderador” en Connect.
  • Poco o nulo énfasis a la seguridad – (este será el foco de los siguientes post) los encargados de pruebas, en la mayoría de casos, se dedican a ver que la aplicación funcione “ como debe”, el detalle aquí es que en muchos casos se limitan a dar unos cuantos clics, a la aplicación y piensan que con eso eso la aplicación esta libre de problemas y que es segura,  lógicamente hay varios niveles de seguridad, dependiendo de la solución, puede ser algo básico o  niveles extremos como los que usa la NASA – así le dice Jerson -  ( sobre esto creo que mejor no me extiendo por ahora y lo dejo para un siguiente post), lógicamente ya muchos pensaran, pero hay programas ( de terceros) que hacen esto, a lo cual les diría, que esos programas, si bien es cierto que ayudan en muchos casos, no nos dan una seguridad al 100% (lógicamente también depende de la solución y del nivel de seguridad que necesitemos); otros dirán “ Visual Studio” trae herramientas muy potentes, lo cual es en extremo cierto, pero no para “análisis automático” allí también hay que programar pruebas :), personalmente me parece una herramienta muy potente y algunas de las veces que me han pedido que haga “pruebas” e usado al VS como herramienta de trabajo –a ver si mas adelante escribo algo de esto-. La seguridad es un mundo no es posible tocarlo en un solo post, todo dependerá de que tanto queremos
  • Los encargados de pruebas, tienen flojera  : No puedo negar que es algo tedioso y en algunos casos algo aburrido estar “probando aplicaciones” , y muchas veces e visto  a tester’s que  por lo mismo, y pro zafarse del trabajo (para luego poder seguir googleando), le dan una revisada “al vuelo” y no concienzudamente, aunque también, hay quienes pueden estar trabajando todo el día buscando errores y encontrar unos cuantos mientras hay quienes solo con 40 minutos, puedes sacar una gran cantidad de errores; lógicamente si detectamos personas que no hacen bien su trabajo, no merecen menos que el despido.
  • No se tiene un buen control del historial de “bugs” : por mas que tenga buenos encargados de pruebas,  si no lo hago de un modo ordenado, todo eso se volvería un caos, existen múltiples programas, entre free y de paga ( hasta un starter kit de aspnet 1.0) con el que podemos tener bien registrados los errores.
  • No se Integra desde la etapa de diseño la seguridad :  mucho se habla de esto, aunque quizá no muchos lo apliquen, en la etapa del diseño de la aplicación debería integrarse la parte de seguridad, lamentablemente es muy difícil conseguir un programador y un diseñador que sepa de seguridad (saber de verdad), la mayoría no piensa en seguridad, o en su defecto, tienen un conocimiento empírico, saben que tienen que poner seguridad, pero en la realidad no aplican seguridad…, y luego cuando empiezan los problemas ( lógicamente no en todos los sistemas aparecen) , tienen que comenzar a “parchar”, lo cual hace que se pierda mas tiempo, al menos por eso lo que suelo recomendar  es que el diseño pase por un análisis previo de seguridad, este entra al de funcionalidad.

 

De todos estos puntos que puse, en el que quiero especificar es en el de la seguridad y especialización, lógicamente sin olvidar sobre el performance, ya que como dicen algunos “intentar poner seguridad de manera desmedida, sin tomar en cuenta el impacto en el performance es malo”.

En el siguiente post, espero tocar una pregunta que en algunos casos es controversial… “saber técnicas de hacking y/o cracking, es malo?”, intentare explicar, el por que creo que no es malo, mas bien por el contrario, es imprescindible.”, ya luego vendría uno de criptografía :) , si, la respuesta al post de Sergio Tarrillo

Para terminar – por ahora – quiero dejarles algo para que piensen…  “el mejor ataque, es cuando la victima no se a dado cuenta que a sido atacada, y que están dentro del sistema” ( la idea es evitar esto, ya que no es necesario que nos modifiquen una pagina, o que nos pongan una foto, para que “estén dentro” ) .

 

Salu2

 


:) Publicacion cruzada desde Geeks.ms :) http://geeks.ms/blogs/ddaz

Una Cortita (link sobre linq) “Is Linq to SQL Dead? Yes, but.…”

Este articulo me lo paso Jersson , lo leí y me pareció demasiado interesante, así que se los comparto, vean tbm los hipervínculos( referencias ), ya que llevan a información de blogs “msdn”  :) , esto sobre Linq2SQL, sobre el muerto que no esta muerto :), anda de parranda  :).

http://www.stephenforte.net/PermaLink,guid,bc1bc043-3cdc-4ac2-8b46-3c72ad1d61cf.aspx 

 

Salu2

Ddaz


:) Publicacion cruzada desde Geeks.ms :) http://geeks.ms/blogs/ddaz

noticia – Salió Live Grupos

Para los que tengan la web de sus comunidades en MSN Groups, seguro ya saben que para el otro anio ese servicio desaparecerá, MicroSoft a dado 2 propuestas, la primera fue en Multiply, donde daban la opción de migrar los mensajes, y luego invitar a los miembros a que se vuelvan a registrar, personalmente el servicio en multiply, no fue de mi agrado, ya que la web tenia muchos problemas de programación ( fallos en la sesiones, y en la web en general), otra opción eran los “Live Groups” el detalle en esta opción es que  aquí seria inicio desde cero, ya que no dan la opción de migración.

el día de ayer salió ( groups.live.com ) me parece una propuesta interesante, bueno no le vi la opción de agregar paginas con noticias o algún grafico extra,  pero el echo de usar el “live id” es muy cómodo, además de que para grupos pequeños ( hasta 20 ) dan la opción para manejarse vía MSN ( lógicamente hay que usar el live messenger 9) .

lo que me gusta  de este servicio es la integración con el live id; en la comunidad aquí en zacatecas “Barreteros.Net”  estábamos pensando migrar a un foro que venga de un CMS, pero con esta opción, lo mas seguro es que migremos a http://barreteros.groups.live.com .

este servicio de live groups, se ve muy interesante, y mas aun ya que los msn groups hace muchos tiempo había sido olvidado por el tío Bill, ojala que este servicio no le pase lo mismo.

 

Salu2

 

Ddaz


:) Publicacion cruzada desde Geeks.ms :) http://geeks.ms/blogs/ddaz