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

 

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

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