Windows 7 RC Liberado para descarga pública

Bueno, eso, que Windows 7 versión RC está disponible para descarga pública en

http://www.microsoft.com/latam/windows/windows-7/download.aspx

Solo recalcar lo que indica Microsoft:

 RC estará disponible al menos hasta junio y no existe límite en la cantidad de descargas o claves de producto. Por lo tanto, cuentas con mucho tiempo.

Recuerda las fechas de expiración: Tanto Windows 7 Beta como Windows 7 RC tienen fechas de expiración. Cuando expire el software, el equipo dejará de funcionar por completo y puede resultar difícil recuperar los archivos. (Esto es muy diferente de los recordatorios persistentes que observarás si no activas el sistema operativo). Para Windows 7 Beta, la fecha de expiración es el 1 de agosto de 2009. Para Windows 7 RC, la fecha de expiración es el 1 de junio de 2010. Por ello, si ejecutas Windows 7 Beta, debes actualizarte a Windows 7 RC antes del 1 de agosto de 2009. Luego, deberás actualizarte a la versión final de Windows 7 antes del 1 de junio de 2010 o bien instalar una versión anterior de Windows.

Blogs sobre Windows 7 (Seguridad y Desarrollo)

Aprovechando la liberación de la versión RC de Windows 7 comparto con quienes les interese y no los conozcan, un par de blogs que no tienen desperdicio.

El primero es “Windows Security Blog” , donde encontraremos post hablando de temas como desmistificar la creencia que dice que solo los usuarios de un “windows genuine” pueden obtener todas las actualizaciones de seguridad o “parches de seguridad” de windows, hay post sobre las características de seguridad de Windows 7, etc. como dije 100% recomendado.

El Segundo es obviamente Windows 7 para desarrolladores, donde encontraremos una serie de post sobre las librerias de esta nueva versión de la plataforma de Microsoft, entre otros truquillos y cosas interesantes.

Como dije ambos recursos 100% recomendados!

Windows 7 RC disponible para descarga de suscriptores Technet Plus y MSDN

Solo eso, quería comentarles que la versión RC (Release Candidate) de Windows 7 ya está disponible para descarga de los suscriptores de Technet Plus y MSDN.

A ver si este fin de semana largo me doy un tiempo para instalarlo y a ver que tal anda, cualquier cosilla la estaré comentando por acá.

Grabación de los eventos de abril 2009

Como les comenté en un post anterior, a principios de abril se estuvo realizando la semana de la seguridad con diversas charlas Microsoft.

Las grabaciones Live Meeting de esas charlas y de otras que se dieron este mes están disponibles en el grupo de facebook de “Comunidades Técnicas Microsoft Chile” , pueden aprovechar de revisarlas pues siempre es bueno aprender un poco más.

Muchas gracias a los oradores de esas charlas y al equipo de comunidades técnicas Microsoft Chile que nos permiten difundir el conocimiento

Recomendaciones sobre validaciones de datos

Hace unos días un colega me preguntaba sobre consideraciones o recomendaciones de seguridad a la hora de diseñar una aplicación.

Aprovechando unos minutos de tiempo libre que tengo, me animo a plasmar un par de recomendaciones sobre la validación de datos, uno de los puntos sensibles en la seguridad de nuestras aplicaciones, sobre todo en las aplicaciones web.

Espero ir agregando material básico que demuestre los problemas que podría generar y también algunas formas de prevenir estos problemas de forma práctica. 

Validación de datos (de fuentes externas en general, como lo que ingresa el usuario, pero también de  datos que provengan, por ejemplo,  de otros sistemas)

·         NO confíe en la validación en el cliente, una de las premisas debe ser “la validación en el cliente no es validación” simplemente porque no se puede asegurar que esta se realice de forma adecuada, o incluso que se llegue a realizar. Hay que recordar que la mayoría de las validaciones en el cliente son hechas con lenguajes de script (javascript principalmente) el cual puede ser deshabilitado en los exploradores.

·         No confíe en los valores extraídos desde recursos susceptibles a ser modificados, esto incluye campos de formulario (como los hidden por ejemplo),  cookies, query strings, HTTP headers, etc.

·         Valide el tipo, formato, rango y largo de los datos. Es decir, si lo que va a ingresar es un email, que lo ingrese tenga la estructura de un email, sea de tipo string y un largo determinado (por ejemplo 50 caracteres). Si va a ingresar un entero, validar que el valor ingresado sea un entero y no un string.

·         Considere usar un sistema centralizado de validación de los datos. Muchas veces encontramos que los mismos puntos dentro de una aplicación son validados de maneras distintas y con distintos procedimientos. Unifiquemos los criterios de validación por ejemplo de fechas, rangos, formatos, etc.

·         Esté atento a los posibles problemas de canonicalización. (** No tiene nada que ver con los santos ni el vaticano, si no sabes por dónde va este tema ya lo explicaré en un post futuro, paciencia)

Mil disculpas por lo resumido del aporte, pero ya lo iremos ampliando de a poco, paciencia 😉

Comentarios de servidor

Uno de los pilares de la seguridad es la confidencialidad, que en pocas palabras significa asegurar que solo la o las personas correctas (que tienen privilegios sobre ella) accedan a la información.

 Una práctica que he visto un par de veces en algunos colegas (bueno, casi todos la hemos hecho alguna vez) es poner comentarios en la vista html.

El gran problema que esto crea es que los comentarios de html son traspasados al cliente, ejemplo:

En la imagen inferior tenemos un comentario html común y corriente

Cuando nuestra página es renderizada al explorador cliente, si vemos el codigo html resultante  veremos que el comentario aparece ahí:

Ahora sustituiremos el comentario html por un comentario de servidor, verán que la diferencia radica en la sintaxis del comentario.

Comentario html:  <!– Recordar que el username es Pepito y la password es P@ssw0rd –>

Comentario de servidor : <%— Recordar que el username es Pepito y la password es P@ssw0rd —%>

la imagen de abajo nos muestra el comentario de servidor en nuestro visual studio

y ahora comprobaremos que nuestro comentario nunca llegó al cliente:

Como dije, la primera regla es no poner datos sensibles en los comentarios, unido a esto una buena barrera es utilizar los comentarios de servidor que evitarán que algún descuido genere alguna brecha de seguridad.

Fábrica de Software

Buscando, siguiendo links y navegando por el web un poco, dí con un portal bastante interesante, dedicado a la Ing de Software y en español (mejor dicho en Chile). http://www.fabricadesoftware.cl/index.php , más allá que su actividad en el último tiempo al parecer es baja, hay documentos y threads de discusión bastante interesantes, dense una vuelta si no lo conocen, 100% recomendado.

Seguridad, bendita eres entre todas las palabras

El día jueves 2 de abril entre 9 y 18 horas se realizó un evento presencial de Microsoft en el auditorio de New Horizons Chile, en el marco de la semana de la seguridad. En la jornada de la tarde (de 14 a 18 horas) estuvo dedicado al desarrollo de software. (si hacen click podrán ver las grabaciones de esos eventos, más otros que se han dado en otras fechas).

Lo que se habló y vio ese día me animó a volver un rato por los ruedos bloggeros para dar mi opinión sobre varios conceptos e ideas que se discutieron ese día.

La masificación de internet y el incremento en la complejidad e interacción entre las aplicaciones y los sistemas, a traído sobre el tapete el tema de la seguridad más seguido. Pero como en todo, el que se hable más de un tema no significa que tenga realmente mayor relevancia o que se haga más al respecto.

 La masificación de internet también ha dado más facilidades a los atacantes para conectarse a nuestras aplicaciones e intentar vulnerar la seguridad de esta.

Como dije, más allá que se habla mucho de seguridad, aún los roles envueltos en la mayoría de los proyectos de desarrollo de software hacen poco por asegurar realmente sus aplicaciones escudándose en que es un proceso altamente costoso o altamente dificultoso.

Planificación

A menudo, en el proceso de planificación del proyecto no se le asigna a la seguridad la relevancia necesaria debido a que muchas veces quienes participan en esta etapa no tienen, o tienen un limitado conocimiento, acerca de las vulnerabilidades que podría poner en riesgo la seguridad de su aplicación, como por ejemplo ataques organizacionales, ataques automatizados en busca de vulnerabilidades, ataques de fuerza bruta, denegación de servicio (DoS) y vulnerabilidades varias debidas a malas o deficientes prácticas de desarrollo.

También sucede que muchas veces están conscientes de las vulnerabilidades pero creen que su aplicación no va a ser afectada por estas o que su aplicación nunca será atacada. Esto es muy habitual cuando se desarrolla software para ambientes corporativos internos o intranets, donde se piensa que al no estar expuestas al mundo (internet) la aplicación está segura, olvidándose del enemigo interno y dejando la aplicación a merced de este.

Finalmente, el último escenario es que se esté consciente de las vulnerabilidades, se sepa que nuestra aplicación va a ser afectada, pero no se tome en cuenta el tema hasta el final (si es que queda tiempo) debido a las restricciones de tiempos en los proyectos (deadlines).  Es importante recalcar que al planificar nuestro proyecto debiésemos planificar con el tiempo necesario para poder realizar los pasos necesarios que aseguren un nivel de seguridad adecuado en nuestra aplicación. Pero además como todos los oradores dijeron ese día (recomiendo oir el material de las sesiones de ese día)  hay muchas técnicas que podemos usar para aumentar la seguridad de nuestra aplicación y que no significan un aumento en nuestros tiempos de desarrollo.

Desarrollo

Así como en la planificación se falla muchas veces en reconocer las vulnerabilidades de seguridad,  otras tantas los desarrolladores fallamos en implementar código seguro por diversas causas.

Así como los planificadores, los desarrolladores muchas veces tampoco son conscientes de las vulnerabilidades potenciales, muchas veces debido a la falta de capacitación y de información con respecto a este tema.

Otro inconveniente habitual es que a menudo los desarrolladores no son capaces de implementar código seguro debido a que la seguridad de la aplicación depende de la cooperación entre los desarrolladores y los administradores de sistemas (nuestros amigos de infraestructura), y eso habitualmente no sucede porque nuestra práctica habitual nos indica que la seguridad es una responsabilidad individual. Si estamos trabajando en una aplicación que funciona en red entonces esperamos que la seguridad sea vista por el administrador del sistema por que la red es concernencia de la gente de infraestructura, lo cual nos lleva a olvidar que una aplicación más segura es responsabilidad de todos los roles que se vean envueltos en el normal funcionamiento de esta (Administradores de sistemas, Arquitectos de solución, Arquitectos de infraestructura, analistas, desarrolladores, etc.)

También como dijimos en el punto de planificación, tal vez los desarrolladores estén conscientes de las vulnerabilidades, pero las restricciones de tiempo o de presupuesto no le permiten implementar al menos la seguridad básica. Mencioné las restricciones de presupuesto pues muchas veces se piensa en que los costos de implementar seguridad son elevados y los beneficios poco palpables o claros, aunque realmente los costos altos se producen al no implementar seguridad, pues si una aplicación no es asegurada adecuadamente y un usuario malicioso posteriormente  explota y/o expone esta vulnerabilidad, los costos de desarrollar parches de seguridad para esta vulnerabilidad incluyen básicamente: los desarrolladores deben arreglar el código, los testers deben aplicar las diversas pruebas de rigor al parche de seguridad y debemos dar aviso al cliente y publicar el parche (con el costo de pérdida de credibilidad asociado).

En resumen descubriremos que los costos mencionados anteriormente serán más altos que agregar características de seguridad en etapas como la de diseño o desarrollo.

 Espero ir habitualmente entregando tips, experiencias, how to, que demuestren lo dicho en este post y que nos ayuden a mejorar nuestra conciencia de seguridad en el desarrollo de software.

Ineta LatAm, el poder de las comunidades

El mayor valor del conocimiento es su capacidad para ser compartido y difundido. Sin esta capacidad, y sin que las personas la hubiesen practicado, no hubiese existido ningún avance en nuestra civilización.

Me fortalece ver como muchos siguen esta premisa (por ejemplo en Geeks.Ms todos comparten su conocimiento y experiencia), pero hoy quiero hacer un alto y poner el enfasis en una labor que se ha realizado por mucho tiempo pero que habitualmente queda oculta o en segundo plano, y me refiero a la labor que realizan todos los voluntarios de la International .NET Association INETA LatAm.


Si no sabes que es Ineta LatAm te invito a que leas una descripción haciendo click aquí


En INETA LatAm la esencia de la frase que puse en un principio se hace realidad de muchas formas, por ejemplo:


– Comité de oradores, quienes brindan apoyo técnico a nuestros afiliados, poniendo a su disposición oradores internacionales, Regionales y Academicos de la talla de David Garza, Daniel Seara, Fernando Guerrero, Guillermo Som “El Guille”, Adolfo Wiernik, Pep Lluis Bano, Haaron Gonzalez, Hadi Hariri, Matias Iacono, José Luis Manners, Salvador Ramos, Percy Reyes, entre muchos otros oradores de gran nivel como los nombrados.


Si quieres ver el listado completo de oradores visita nuestra página de oradores en esta página


– Comité Web y Contenido que son quienes hacen posible que nuestro sitio esté en funcionamiento y actualizado con la información que los líderes y adminsitradores de los grupos de usuarios nos entregan .


– Comité de noticias quienes elabran el boletín mensual de Ineta LatAm, dando a conocer las actividades de los grupos (Al menos las que nos informan), las actividades de nuestra organizació, junto con artículos de interés, entrevistas a miembros importantes de la comunidad, etc.


– Comité de mercadeo, cuya función es (y la hacen muy bien) conseguir sumar “amigos” a nuestra causa [;)]  ( Si te quedó la duda que son o quienes son nuestros “amigos” pues visita el siguiente link http://www.inetalatam.org/Mostrar.aspx?Item=Amigos.htm)


– Comité Academia, el cual se concentra en brindar soporte y asistencia a las comunidades y grupos de usuarios académicos, con foco en la tecnológía .Net; formados por estudiantes, docentes e investigadores de las universidades e instituciones educativas de toda Latinoamérica.


Más información en http://www.inetalatam.org/Mostrar.aspx?Item=Academia.htm


– Comité de relación con grupos de usuarios, donde estamos junto a los delegados de cada pais o zona trabajando (o intentando hacerlo) junto a los grupos de usuarios directamente.


¿Porque dije “Intentado”?


En estos momentos en Latinoamérica hay 58 grupos de usuarios repartidos en 12 páises que están afiliados a nuestra organización (si quieres saber cuales son los grupos de tu país que están afiliados puedes verlo en http://www.inetalatam.org/GrupoMiembro.aspx) y contamos con delegados en 9 países o zonas (puedes ver el listado de ellos en http://www.inetalatam.org/Mostrar.aspx?Item=Delegados.htm).


A pesar de estas cifras, la participación efectiva de los grupos es muy baja aún. Para nosotros es muy importante  poder transmitirles a todos y cada uno de los líderes, admnistradores y miembros de cada grupos que  Ineta LatAm no es un ente ajeno, si no más bien, es una extensión de sus propios grupos. Una extensión que permite que nuestra labor de compartir conocimientos se vea multiplicada varias veces y a la vez conocida en muchos lados. Como reza el dicho: “Una gota de agua puede parecer poco, pero muchas juntas son un mar” ( y también que dentro de cada gota habita un oceano entero).


Tenemos muchos desafíos e ideas que queremos concretar para ayudar a las comunidades de Latinoamérica, pero todos estos desafíos se hacen imposibles de lograr si no contamos con el apoyo de todos quienes participan en grupos que son afiliados a Ineta LatAm. ¿Y en que consiste este apoyo?, en nada de otro mundo, en cosas muy simples, pero para nosotros de suma importancia como por ejemplo responder las comunicaciones y mails que los delegados les envían, visitar continuamente el sitio público (http://www.inetalatam.org/)  y el area privada (solo los lideres de grupo) del website de Ineta Latam (http://www.inetalatam.org/), etc.


Espero haberles dado una idea de lo que se hace en nuestra organización y del trabajo de todos nuestros voluntarios (http://www.inetalatam.org/Voluntarios.aspx) quienes hacen esta labor de forma no remunerada, destinando parte de su tiempo libre solo con el objetivo de compartir y difundir el conocimiento.


Vaya mi respeto, mis saludos y mis agradecimientos a todos ellos que con su actitud de entrega me permiten seguir soñando  en una Latinoamérica mas justa y más hermana.


Espero a ustedes haberles incentivado a conocer mas de Ineta LatAm visitando su sitio, hay muchas cosas interesantes y recursos valiosos que podrán descubrir.


Si no los descubren se los contaré yo en un próximo post (espero algo mas corto que este [;)])

The "Revenge" of the BSOD

El día viernes pasado (19 de Octubre) algo hizo que me acordara de viejos tiempos e incluso de no tan viejos.


Mi colega “Master” Mori, terminaba su labor de testing cuando de pronto, oh! sorpresa! un BSOD en su Windows Vista Business (licenciado legalmente, actualizado con todos sus parches y sin programas extraños instalados, salvo Virtual PC que fue el que al parecer causó el problema)


BSOD The Revenge     


    The BSOD Revenge


Bueno aqui unas imagenes del evento, pueden ver a mi colega (en la imagen inferior) lanzando violentamente el mouse contra el suelo a fin de liberar la frustración del hecho (no, esto es broma [:D]).


Luego de un vistazo podemos llegar también a la conclusión que Vista se mareó debido al desorden del escritorio de mi compañero, lo cual podría ser aceptado como un argumento válido.


Sea cual sea el motivo (que investigaremos el lunes) no deja de ser “reconfortante” que a pesar del tiempo transcurrido y los avances tecnológicos, nuestra BSOD siga acompañandonos haciendónos sentir como en los viejos tiempos. [A]


P.S: Esto no deja de ser un comentario, miren que he visto cosas de este estilo en linux también (no voy a decir que en una capacitacion en un centro donde usaban plataforma linux se me “pegaba” CentOS cada 5 minutos. Como no lo voy a decir, no lo vayan ustedes a leer).


 Asi es que, por favor,  no vayan a pensar que es un post “religioso” [:P]