IMtrevista con GPI: Seguridad en Sitios Web Regionales
Qué tan seguros son los sitios Web creados en nuestra región? Esta pregunta es el tema de la siguiente IMtrevista realizada a Gustavo Guerra y Carlos Christian Molina de GPI Consultores. Si crees que la seguridad del código escrito por los equipos de desarrollo locales no es la ideal, no estás solo.
Fragmentos de la entrevista:
Qué tan seguros son los sitios Web creados en nuestra región? Esta pregunta es el tema de la siguiente IMtrevista realizada a Gustavo Guerra y Carlos Christian Molina de GPI Consultores. Si crees que la seguridad del código escrito por los equipos de desarrollo locales no es la ideal, no estás solo.
Fragmentos de la entrevista:
......
Ricardo J: Háblennos un poco sobre ustedes y su compañía.
Gustavo G: Bueno, mi nombre es Gustavo Guerra, tengo unos 12 años de experiencia en informática, y estos últimos 6 años con tecnologías Microsoft, actualmente soy el Gerente de Desarrollo de GPI Consultores, y también colaboro como arquitecto de algunas soluciones y otras veces como administrador de proyectos, en esta rama tengo una certificación de PMP del PMI.
Carlos C: Mi nombre es Carlos Christian Molina Vega, soy el Jefe de Arquitectos de Software de GPI Consultores. Tengo más de 9 años de experiencia en diferentes tecnologías y más de 5 años en desarrollos .NET. Me especializo en Arquitectura, integración de aplicaciones, desarrollos seguros y optimización de aplicaciones.
RJ: Gracias, entiendo que GPI Consultores se especializa en el tema de seguridad, nos podrían hablar un poco más de esto?
GG: Si, GPI Consultores es una empresa dedicada a brindar asesoramientos, soporte y consultorías en Tecnologías de Información, con el objetivo de maximizar el desempeño de la plataforma operativa de nuestros clientes y de poder incorporar nuevos productos y tecnologías a estas plataformas para hacerlas más productivas.
.........
Ricardo J: Háblennos un poco sobre ustedes y su compañía.
Gustavo G: Bueno, mi nombre es Gustavo Guerra, tengo unos 12 años de experiencia en informática, y estos últimos 6 años con tecnologías Microsoft, actualmente soy el Gerente de Desarrollo de GPI Consultores, y también colaboro como arquitecto de algunas soluciones y otras veces como administrador de proyectos, en esta rama tengo una certificación de PMP del PMI.
Carlos C: Mi nombre es Carlos Christian Molina Vega, soy el Jefe de Arquitectos de Software de GPI Consultores. Tengo más de 9 años de experiencia en diferentes tecnologías y más de 5 años en desarrollos .NET. Me especializo en Arquitectura, integración de aplicaciones, desarrollos seguros y optimización de aplicaciones.
RJ: Gracias, entiendo que GPI Consultores se especializa en el tema de seguridad, nos podrían hablar un poco más de esto?
GG: Si, GPI Consultores es una empresa dedicada a brindar asesoramientos, soporte y consultorías en Tecnologías de Información, con el objetivo de maximizar el desempeño de la plataforma operativa de nuestros clientes y de poder incorporar nuevos productos y tecnologías a estas plataformas para hacerlas más productivas.
.........
RJ: Y esto incluye Desarrollo de Software?
GG: exacto, desde el diseño de la solución tanto en software como en infraestructura y aplicando buenas prácticas en seguridad en todo el desarrollo e implantación de la solución.
RJ: Una de las mayores preocupaciones en Microsoft es cómo elevamos el conocimiento de los desarrolladores en la región para producir sitios web con código seguro, robusto, a prueba de ataques. Cuál ha sido su experiencia en esta área? Consideran que los sitios producidos en la región tienen un nivel aceptable de seguridad?
CC: Nuestra experiencia en esta área nos indica que lo adecuado es aplicar la seguridad desde la concepción del proyecto, se debe contemplar muy seriamente desde el diseño. Los involucrados en la solución deben conocer las mejores prácticas de seguridad e incluirlas en su codificación, estas deben ser parte de las políticas y controles de calidad de la empresa que desarrolla.
GG: Sinceramente en la región por investigación propia hemos encontrado que las empresas a la que más le debe interesar la seguridad como instituciones financieras, en las cuales en el subconsciente de las personas se asocia que en esos sitios hay acceso a dinero, no cumplen con la expectativa que se debería en cuanto a seguridad, especialmente en Centroamérica y algunos países de Suramérica.
GG: Esto principalmente sucede porque los programadores empujados por la premura del negocio no toman las decisiones adecuadas en sus soluciones, y aplican la seguridad al final, dejando huecos grandes de seguridad en el diseño.
GG: Y otras veces se hace una solución segura pero como el negocio evoluciona los cambios se aplican en caliente produciendo fallas de seguridad luego de la salida de la primera versión por asi decirlo, cuesta crear una cultura de desarrollo seguro.
RJ: Es un tema de una metodología defectuosa o de falta de conocimiento técnico?
GG: Ambas cosas, la metodología ayuda mucho ya que el tema del manejo de pruebas razonables en cuanto a seguridad, y aplicar la seguridad y la calidad durante todo el proyecto ayuda.
CC: Algunas empresas de desarrollo no invierten lo suficiente en capacitar a su recurso técnico, por lo cual no pueden exigir código seguro si ellos no lo saben. Se deben exigir controles de calidad adecuados que detecten estas deficiencias.
GG: El tema técnico es fundamental, porque muchas veces las herramientas tienen sus propias defensas ante ataques comunes, pero no pueden defendernos de programadores inadecuados es decir a veces el error lo comete el programador directamente.
RJ: Es decir, tanto los administradores de proyectos como los desarrolladores de software son responsables.
GG: Exactamente, y si tienen un departamento de QA de software ayuda mucho también.
RJ: Ustedes recomiendan alguna metodología en particular para aplicar la seguridad?
CC: Realmente la responsabilidad recae en los arquitectos de software, ya que como dijimos anteriormente la seguridad debe contemplarse desde el diseño de la aplicación.
GG: Si muy importante aplicar una metodología de proyectos en general, ya que no solo ve el tema de la solución técnica en sí, sino de los afectados por la solución y el efecto en el negocio lo cual se debe manejar muy bien para evitar principalmente ataques de ingeniería social.
GG: Pero también como dice Carlos la metodología de desarrollo es importante, para que desde el diseño se haga contemplando temas de seguridad.
CC: Algunas empresas no tienen siquiera los roles bien definidos.... no hay un arquitecto o alguien con experiencia y bien capacitado que guie la construcción de la solución.
RJ: Qué les parece el SDLC (Security Development Lifecycle) de Microsoft?
CC: Es una iniciativa adecuada de Microsoft para realizar un desarrollo seguro.
RJ: Consideran que es lo suficientemente genérica para ser aplicada sin importar la herramienta? O creen que está atada a Visual Studio .NET?
CC: Como toda metodología de Microsoft se orienta principalmente a sus desarrollos, pero es perfectamente aplicable a otros ambientes relacionados.
RJ: En la parte técnica, cuáles errores consideran que son los más comunes?
GG: Cross Site Scripting o conocido como XSS ya que es el que se utiliza generalmente para hacer ataques de phishing efectivos, osea se aprovecha del cliente y no de la seguridad del server.
GG: Aunque el principal es considerar que el input es el esperado. Me refiero a confiar en los ingresos al sistema, en que siempre se va a recibir lo que se espera del producto, de esto se derivan el XSS, la inyección de SQL, y principalmente alterar archivos de configuración y cookies o variables de la solución.
CC: Muchos errores de seguridad suceden por desconocimiento de los desarrolladores. Por ejemplo inyección de código en SQL. Ya existen muchas técnicas y librerías que evitan estos problemas (los application data blocks, por ejemplo). Algunos desarrolladores se han acostumbrado a programar en un único modelo y no aprovechan las fortalezas de los productos (por ejemplo Stored Procedures en SQL Server).
GG: Otro muy común es el manejo de excepciones ya que dejan evidencia de estructura de la solución, versiones, conexión a bases de datos y principalmente más información de la que se debe brindar.
CC: Muchos desarrollos no encriptan datos tan importantes como lo son las cadenas de conexión hacia la base de datos.
GG: Me refiero a cuando un desarrollador pone más información que la que debe en una excepción por ejemplo si falla la BD tira el error del SQL, y allí va información de la estructura de datos, objetos, conexión y en muchos casos login y password utilizados.
CC: Como lo menciona Gustavo Guerra, algo tan común como las excepciones pueden mostrar mucha información acerca de la aplicación.
CC: En muchos casos solamente muestran la excepción, cuando lo adecuado es "enmascarar" las excepciones y mostrar un mensaje amigable al usuario.
RJ: El error se logea en otra capa, no?
GG: Exacto, se le da un mensaje adecuado y el error para los programadores o la gente de operación de la solución se registra en otra capa como los eventos del sistema operativo o la base de datos, generalmente se combinan ambos.
CC: Una adecuada arquitectura debe de prever estas situaciones desde el inicio. Si se estructura adecuadamente, mensajes de error de una capa deberían llegar filtrados a las siguientes y con aun mas restricción al usuario final (en la capa de presentación).
CC: Aunque menciono muchas veces al usuario, al final la regla es que no llegue información de este tipo a la presentación. Si un web service lo consume un sistema... igual los errores deben ser muy controlados para que el consumidor del web service no tenga información de implementación de la solución.
RJ: No les pido que nos den ejemplos de sitios con estos problemas para no exponer a ningún cliente, pero que porcentaje de sitios consideran ustedes que tienen problemas serios?
GG: Bueno quizás la audiencia de esta nota ya tenga la respuesta, pero el índice es muy alto, es muy común que directamente el programador no maneje excepciones controladas y tire el típico error de ASP.NET donde podes tener información de la versión el framework, sistema operativo y demás, si el atacante averigua puede ver si tiene los últimos parches o esta desprotegida esa solución para comenzar a gestar otro ataque pero el porcentaje es algo diría que en un 80 a 90%, otro problema es por ejemplo tirar el error de la BD y allí hay información valiosa, otro es decir que el login fue erroneo porque el usuario no existe o en otros casos que el password es incorrecto, con esto sacamos un 50% del trabajo sé que si tengo un usuario valido solo debo intentar el password y la mayoría son ataques que no requieres muchos conocimientos técnicos para aprovecharlos.
RJ: Además de que realmente hay muchas aplicaciones disponibles para facilitar el trabajo de atacar a un sitio, cierto?
GG: Eso también, hay bastante aplicaciones disponibles, aunque los ataques más efectivos son los que se descubren sin estas aplicaciones, ya que estas aplicaciones también se usan para hacer análisis automáticos de vulnerabilidad, y serian los errores más comunes, pero los más efectivos son los que una persona decide que hacer.
RJ: Por otro lado hay algún sitio web que ustedes recomienden como caso de éxito en el área de seguridad? Algún sitio web con todas las políticas aplicadas efectivamente?
GG: En cuanto a los sitios seguros, diría que no los de "En construcción" se salvan porque si permiten inyectar código o utilizar su dominio para publicar información se puede hacer un ataque al negocio desprestigiando a la empresa. Pero como empresa que puedo nombrar esta Citi Group reconocido a nivel mundial y que tiene departamentos dedicados a prevenir ataques y asegurar sus aplicaciones, aun así, no están exentos que de vez en cuanto alguien les gane en la carrera.
GG: En este caso son empresas en que la industria se basa para temas de seguridad, y solo está la mayoría de los bancos mundiales deben estar protegidos, el mismo Microsoft es un sitio en el cual se cuida mucho la seguridad.
GG: Y no son muy conocidos casos de ataques exitosos.
CC: Aun cuando se apliquen todas estas recomendaciones, siempre habrá nuevas formas de ataque y algunas de ellas podrían conspirar contra la seguridad de un sitio. Sin embargo, lo más importante es la actualización continua. Se deben mantener siempre actualizados los sistemas operativos, los antivirus y siempre estar al día en cuanto a las mejores prácticas de seguridad e implementarlas.....
RJ: Nosotros liberamos hace un par de años Net Protector, una iniciativa para aprender a desarrollador código seguro de manera entretenida. Qué otros recursos pueden sugerirnos para los que estamos interesados en aprender seriamente cómo desarrollar código seguro?
GG: El Net Protector lo recomiendo, y principalmente estar al tanto de los ataques comunes y cómo.
GG: Aunque mi recomendación es evaluar las aplicaciones que uno hace y si es posible otra persona lo haga, ya que uno generalmente recorre caminos conocidos, evitar basar la seguridad en "lo que no se ve" como por ejemplo soluciones que pasan query string pero lo meten dentro de un frame o eframe para que no se vea lo que se manda, prevenirlos, los foros de seguridad son muy buenos para estar al tanto.
CC: Algunos libros excelentes de MS Press son Writing Secure Code, 2nd Edition asi como Code Complete.
RJ: En temas de foros de seguridad cuál frecuentan ustedes?
CC: Los centros de conocimiento de las empresas de software antivirus son una buena fuente de información, algunas son Panda, Symantec, etc.
RJ: Excelente, alguna otra recomendación?
GG: Encriptar la comunicación, el manejo de cookies manejarlos por objetos, ya que se encriptan y aseguran que alguien los altere, teniendo ataques verticales u horizontales en la solución.
GG: Desconfiar de todo input, y principalmente utilizar herramientas como .NET que ya sus controles implementan mejores prácticas de seguridad para evitar XSS y manipulación de variables en el cliente.
GG: Por último en el diseño manejar la seguridad en profundidad o mejor dicho desde el principio.
CC: La mayoría de las recomendaciones que hemos dado son propias de los productos y son adecuadas,, sin embargo, no descuidemos otros factores como lo son los usuarios.... la cultura en la empresa es la otra cara de la moneda.....
CC: Podemos tener el sitio más seguro del mundo que si un usuario escribe su clave en una nota y la pega en monitor (y te aseguro que hemos visto muchos casos de esto) con una ocurrencia tan inocente comprometen toda la seguridad.
CC: Las empresas deben concientizar y exigir que se apliquen las medidas de seguridad adecuadas por los usuarios....
CC: Aprovechando te menciono uno de los ataques más comunes a los cuales todo el mundo está expuesto..... y son los ataques de ingenieria social, como el phishing, el cual 80% de su prevención se realiza reforzando la cultura.....
CC: Al ser ingeniería social las mejoras ayudan pero no pueden detener completamente esos ataques.....
RJ: Creen que las mejoras en los navegadores de Internet ayudan a prevenir estos ataques?
GG: Si por supuesto, ayudan mucho, como así también los sistemas operativos modernos como Vista.
GG: Ya que traen las buenas prácticas configuradas por defecto, claro queda a criterio del usuario si las deshabilita.
CC: Algunos sitios que manejan datos muy delicados, como los bancos, deben contemplar soluciones no solo de software sino de hardware, que es lo único que realmente puede evitar estos ataques, una de las mejores tecnicas es Two Factor Authentication. En la cual no solo se depende de un usuario y una clave.
CC: Sino también de algún valor que solo se conozca en un momento... como los generadores de claves aleatorias.....y los tokens con certificados digitales...
RJ: Cuánto tiempo les tomaría a ustedes explotar un sitio web vulnerable?
CC: Uno de los principales errores es tratar de hackear un sitio. Eso no demuestra nada... solamente mi habilidad como hacker para ingresar...
RJ: Y se los pregunto porque quiero elevar el nivel de consciencia sobre este tema, realmente coincido con ustedes en que el tema de seguridad pasa desapercibido o relegado a un segundo plano en la mayoría de desarrollos de software.
GG: El tiempo depende de la solución, la tecnología que utilicen y la complejidad de la misma, pero son proyectos que van de dos a tres semanas en adelante ya que cada vez que se hacen las recomendaciones y se aplican las mejoras se debe volver a ejecutar las pruebas.
CC: Lo que nosotros utilizamos es lo que se conoce como "analisis de vulnerabilidades" que es básicamente utilizar muchas metodologías para asegurar que todos las recomendaciones dadas y otras no mencionadas estén implementadas adecuadamente.
GG: También recomendamos hacer el WSSRA Arquitectura de referencia en cuanto a ordenamiento de las aplicaciones, en el cual también se evalúa temas de seguridad tanto de hardware y software como social y cultural también si así se extiende.
RJ: Hay alguna prueba sencilla que podamos correr en un sitio web para determinar si podemos confiar nuestros datos ahí?
CC: Esta pregunta es compleja, ya que no conocemos lo que hay detrás... algunos sitios tienen hasta HTTPS activo y eso no significa que sea seguro...
CC: Como indica Gustavo, Microsoft nos ayuda.... con una metodología como WSSRA, que indica las mejores prácticas para distribuir los servidores en una red y no solo eso también las aplicaciones que se utilizan en ellos.
GG: En cuanto a una prueba sencilla es ver: Primero, basamos nuestra seguridad en "lo que no se ve" por ejemplo campos ocultos en el HTML, javascript que se puede alterar en el cliente, y query strings sin encriptar en frames.
GG: Segundo, no confiar en el input, ya que muchas veces confiamos en lo que se ingresa en el campo de un buscador y ese mismo texto lo copiamos tal cual en el HTML de la pagina de resultados, permitiendo allí la inyección de código y ataques por XSS.
GG: Tercero, manejar correctamente los errores, no dar más información de la que el usuario de esa solución necesita, la información técnica manejarla en otros repositorios más seguros para los programadores de la misma.
CC: Toda aplicación web debería verse como insegura hasta que una empresa dedicada a la seguridad le haga un análisis adecuado y de las recomendaciones del caso.
GG: Cuarto, ver cuáles son los ataques comunes en ese momento y ver si estamos expuestos a ellos.
GG: Quinto y ultima, volver a probarla...
RJ: Perfecto, me parece que ha sido muy provechosa la IMtrevista, me queda claro que la situación es más crítica de lo que a veces estamos dispuestos a aceptar. Les doy las gracias a ambos por el tiempo que nos han concedido, esperemos elevar un poco así el nivel de consciencia que hay detrás del tema de seguridad.
CC: Nuestra experiencia en esta área nos indica que lo adecuado es aplicar la seguridad desde la concepción del proyecto, se debe contemplar muy seriamente desde el diseño. Los involucrados en la solución deben conocer las mejores prácticas de seguridad e incluirlas en su codificación, estas deben ser parte de las políticas y controles de calidad de la empresa que desarrolla.
GG: Sinceramente en la región por investigación propia hemos encontrado que las empresas a la que más le debe interesar la seguridad como instituciones financieras, en las cuales en el subconsciente de las personas se asocia que en esos sitios hay acceso a dinero, no cumplen con la expectativa que se debería en cuanto a seguridad, especialmente en Centroamérica y algunos países de Suramérica.
GG: Esto principalmente sucede porque los programadores empujados por la premura del negocio no toman las decisiones adecuadas en sus soluciones, y aplican la seguridad al final, dejando huecos grandes de seguridad en el diseño.
GG: Y otras veces se hace una solución segura pero como el negocio evoluciona los cambios se aplican en caliente produciendo fallas de seguridad luego de la salida de la primera versión por asi decirlo, cuesta crear una cultura de desarrollo seguro.
RJ: Es un tema de una metodología defectuosa o de falta de conocimiento técnico?
GG: Ambas cosas, la metodología ayuda mucho ya que el tema del manejo de pruebas razonables en cuanto a seguridad, y aplicar la seguridad y la calidad durante todo el proyecto ayuda.
CC: Algunas empresas de desarrollo no invierten lo suficiente en capacitar a su recurso técnico, por lo cual no pueden exigir código seguro si ellos no lo saben. Se deben exigir controles de calidad adecuados que detecten estas deficiencias.
GG: El tema técnico es fundamental, porque muchas veces las herramientas tienen sus propias defensas ante ataques comunes, pero no pueden defendernos de programadores inadecuados es decir a veces el error lo comete el programador directamente.
RJ: Es decir, tanto los administradores de proyectos como los desarrolladores de software son responsables.
GG: Exactamente, y si tienen un departamento de QA de software ayuda mucho también.
RJ: Ustedes recomiendan alguna metodología en particular para aplicar la seguridad?
CC: Realmente la responsabilidad recae en los arquitectos de software, ya que como dijimos anteriormente la seguridad debe contemplarse desde el diseño de la aplicación.
GG: Si muy importante aplicar una metodología de proyectos en general, ya que no solo ve el tema de la solución técnica en sí, sino de los afectados por la solución y el efecto en el negocio lo cual se debe manejar muy bien para evitar principalmente ataques de ingeniería social.
GG: Pero también como dice Carlos la metodología de desarrollo es importante, para que desde el diseño se haga contemplando temas de seguridad.
CC: Algunas empresas no tienen siquiera los roles bien definidos.... no hay un arquitecto o alguien con experiencia y bien capacitado que guie la construcción de la solución.
RJ: Qué les parece el SDLC (Security Development Lifecycle) de Microsoft?
CC: Es una iniciativa adecuada de Microsoft para realizar un desarrollo seguro.
RJ: Consideran que es lo suficientemente genérica para ser aplicada sin importar la herramienta? O creen que está atada a Visual Studio .NET?
CC: Como toda metodología de Microsoft se orienta principalmente a sus desarrollos, pero es perfectamente aplicable a otros ambientes relacionados.
RJ: En la parte técnica, cuáles errores consideran que son los más comunes?
GG: Cross Site Scripting o conocido como XSS ya que es el que se utiliza generalmente para hacer ataques de phishing efectivos, osea se aprovecha del cliente y no de la seguridad del server.
GG: Aunque el principal es considerar que el input es el esperado. Me refiero a confiar en los ingresos al sistema, en que siempre se va a recibir lo que se espera del producto, de esto se derivan el XSS, la inyección de SQL, y principalmente alterar archivos de configuración y cookies o variables de la solución.
CC: Muchos errores de seguridad suceden por desconocimiento de los desarrolladores. Por ejemplo inyección de código en SQL. Ya existen muchas técnicas y librerías que evitan estos problemas (los application data blocks, por ejemplo). Algunos desarrolladores se han acostumbrado a programar en un único modelo y no aprovechan las fortalezas de los productos (por ejemplo Stored Procedures en SQL Server).
GG: Otro muy común es el manejo de excepciones ya que dejan evidencia de estructura de la solución, versiones, conexión a bases de datos y principalmente más información de la que se debe brindar.
CC: Muchos desarrollos no encriptan datos tan importantes como lo son las cadenas de conexión hacia la base de datos.
GG: Me refiero a cuando un desarrollador pone más información que la que debe en una excepción por ejemplo si falla la BD tira el error del SQL, y allí va información de la estructura de datos, objetos, conexión y en muchos casos login y password utilizados.
CC: Como lo menciona Gustavo Guerra, algo tan común como las excepciones pueden mostrar mucha información acerca de la aplicación.
CC: En muchos casos solamente muestran la excepción, cuando lo adecuado es "enmascarar" las excepciones y mostrar un mensaje amigable al usuario.
RJ: El error se logea en otra capa, no?
GG: Exacto, se le da un mensaje adecuado y el error para los programadores o la gente de operación de la solución se registra en otra capa como los eventos del sistema operativo o la base de datos, generalmente se combinan ambos.
CC: Una adecuada arquitectura debe de prever estas situaciones desde el inicio. Si se estructura adecuadamente, mensajes de error de una capa deberían llegar filtrados a las siguientes y con aun mas restricción al usuario final (en la capa de presentación).
CC: Aunque menciono muchas veces al usuario, al final la regla es que no llegue información de este tipo a la presentación. Si un web service lo consume un sistema... igual los errores deben ser muy controlados para que el consumidor del web service no tenga información de implementación de la solución.
RJ: No les pido que nos den ejemplos de sitios con estos problemas para no exponer a ningún cliente, pero que porcentaje de sitios consideran ustedes que tienen problemas serios?
GG: Bueno quizás la audiencia de esta nota ya tenga la respuesta, pero el índice es muy alto, es muy común que directamente el programador no maneje excepciones controladas y tire el típico error de ASP.NET donde podes tener información de la versión el framework, sistema operativo y demás, si el atacante averigua puede ver si tiene los últimos parches o esta desprotegida esa solución para comenzar a gestar otro ataque pero el porcentaje es algo diría que en un 80 a 90%, otro problema es por ejemplo tirar el error de la BD y allí hay información valiosa, otro es decir que el login fue erroneo porque el usuario no existe o en otros casos que el password es incorrecto, con esto sacamos un 50% del trabajo sé que si tengo un usuario valido solo debo intentar el password y la mayoría son ataques que no requieres muchos conocimientos técnicos para aprovecharlos.
RJ: Además de que realmente hay muchas aplicaciones disponibles para facilitar el trabajo de atacar a un sitio, cierto?
GG: Eso también, hay bastante aplicaciones disponibles, aunque los ataques más efectivos son los que se descubren sin estas aplicaciones, ya que estas aplicaciones también se usan para hacer análisis automáticos de vulnerabilidad, y serian los errores más comunes, pero los más efectivos son los que una persona decide que hacer.
RJ: Por otro lado hay algún sitio web que ustedes recomienden como caso de éxito en el área de seguridad? Algún sitio web con todas las políticas aplicadas efectivamente?
GG: En cuanto a los sitios seguros, diría que no los de "En construcción" se salvan porque si permiten inyectar código o utilizar su dominio para publicar información se puede hacer un ataque al negocio desprestigiando a la empresa. Pero como empresa que puedo nombrar esta Citi Group reconocido a nivel mundial y que tiene departamentos dedicados a prevenir ataques y asegurar sus aplicaciones, aun así, no están exentos que de vez en cuanto alguien les gane en la carrera.
GG: En este caso son empresas en que la industria se basa para temas de seguridad, y solo está la mayoría de los bancos mundiales deben estar protegidos, el mismo Microsoft es un sitio en el cual se cuida mucho la seguridad.
GG: Y no son muy conocidos casos de ataques exitosos.
CC: Aun cuando se apliquen todas estas recomendaciones, siempre habrá nuevas formas de ataque y algunas de ellas podrían conspirar contra la seguridad de un sitio. Sin embargo, lo más importante es la actualización continua. Se deben mantener siempre actualizados los sistemas operativos, los antivirus y siempre estar al día en cuanto a las mejores prácticas de seguridad e implementarlas.....
RJ: Nosotros liberamos hace un par de años Net Protector, una iniciativa para aprender a desarrollador código seguro de manera entretenida. Qué otros recursos pueden sugerirnos para los que estamos interesados en aprender seriamente cómo desarrollar código seguro?
GG: El Net Protector lo recomiendo, y principalmente estar al tanto de los ataques comunes y cómo.
GG: Aunque mi recomendación es evaluar las aplicaciones que uno hace y si es posible otra persona lo haga, ya que uno generalmente recorre caminos conocidos, evitar basar la seguridad en "lo que no se ve" como por ejemplo soluciones que pasan query string pero lo meten dentro de un frame o eframe para que no se vea lo que se manda, prevenirlos, los foros de seguridad son muy buenos para estar al tanto.
CC: Algunos libros excelentes de MS Press son Writing Secure Code, 2nd Edition asi como Code Complete.
RJ: En temas de foros de seguridad cuál frecuentan ustedes?
CC: Los centros de conocimiento de las empresas de software antivirus son una buena fuente de información, algunas son Panda, Symantec, etc.
RJ: Excelente, alguna otra recomendación?
GG: Encriptar la comunicación, el manejo de cookies manejarlos por objetos, ya que se encriptan y aseguran que alguien los altere, teniendo ataques verticales u horizontales en la solución.
GG: Desconfiar de todo input, y principalmente utilizar herramientas como .NET que ya sus controles implementan mejores prácticas de seguridad para evitar XSS y manipulación de variables en el cliente.
GG: Por último en el diseño manejar la seguridad en profundidad o mejor dicho desde el principio.
CC: La mayoría de las recomendaciones que hemos dado son propias de los productos y son adecuadas,, sin embargo, no descuidemos otros factores como lo son los usuarios.... la cultura en la empresa es la otra cara de la moneda.....
CC: Podemos tener el sitio más seguro del mundo que si un usuario escribe su clave en una nota y la pega en monitor (y te aseguro que hemos visto muchos casos de esto) con una ocurrencia tan inocente comprometen toda la seguridad.
CC: Las empresas deben concientizar y exigir que se apliquen las medidas de seguridad adecuadas por los usuarios....
CC: Aprovechando te menciono uno de los ataques más comunes a los cuales todo el mundo está expuesto..... y son los ataques de ingenieria social, como el phishing, el cual 80% de su prevención se realiza reforzando la cultura.....
CC: Al ser ingeniería social las mejoras ayudan pero no pueden detener completamente esos ataques.....
RJ: Creen que las mejoras en los navegadores de Internet ayudan a prevenir estos ataques?
GG: Si por supuesto, ayudan mucho, como así también los sistemas operativos modernos como Vista.
GG: Ya que traen las buenas prácticas configuradas por defecto, claro queda a criterio del usuario si las deshabilita.
CC: Algunos sitios que manejan datos muy delicados, como los bancos, deben contemplar soluciones no solo de software sino de hardware, que es lo único que realmente puede evitar estos ataques, una de las mejores tecnicas es Two Factor Authentication. En la cual no solo se depende de un usuario y una clave.
CC: Sino también de algún valor que solo se conozca en un momento... como los generadores de claves aleatorias.....y los tokens con certificados digitales...
RJ: Cuánto tiempo les tomaría a ustedes explotar un sitio web vulnerable?
CC: Uno de los principales errores es tratar de hackear un sitio. Eso no demuestra nada... solamente mi habilidad como hacker para ingresar...
RJ: Y se los pregunto porque quiero elevar el nivel de consciencia sobre este tema, realmente coincido con ustedes en que el tema de seguridad pasa desapercibido o relegado a un segundo plano en la mayoría de desarrollos de software.
GG: El tiempo depende de la solución, la tecnología que utilicen y la complejidad de la misma, pero son proyectos que van de dos a tres semanas en adelante ya que cada vez que se hacen las recomendaciones y se aplican las mejoras se debe volver a ejecutar las pruebas.
CC: Lo que nosotros utilizamos es lo que se conoce como "analisis de vulnerabilidades" que es básicamente utilizar muchas metodologías para asegurar que todos las recomendaciones dadas y otras no mencionadas estén implementadas adecuadamente.
GG: También recomendamos hacer el WSSRA Arquitectura de referencia en cuanto a ordenamiento de las aplicaciones, en el cual también se evalúa temas de seguridad tanto de hardware y software como social y cultural también si así se extiende.
RJ: Hay alguna prueba sencilla que podamos correr en un sitio web para determinar si podemos confiar nuestros datos ahí?
CC: Esta pregunta es compleja, ya que no conocemos lo que hay detrás... algunos sitios tienen hasta HTTPS activo y eso no significa que sea seguro...
CC: Como indica Gustavo, Microsoft nos ayuda.... con una metodología como WSSRA, que indica las mejores prácticas para distribuir los servidores en una red y no solo eso también las aplicaciones que se utilizan en ellos.
GG: En cuanto a una prueba sencilla es ver: Primero, basamos nuestra seguridad en "lo que no se ve" por ejemplo campos ocultos en el HTML, javascript que se puede alterar en el cliente, y query strings sin encriptar en frames.
GG: Segundo, no confiar en el input, ya que muchas veces confiamos en lo que se ingresa en el campo de un buscador y ese mismo texto lo copiamos tal cual en el HTML de la pagina de resultados, permitiendo allí la inyección de código y ataques por XSS.
GG: Tercero, manejar correctamente los errores, no dar más información de la que el usuario de esa solución necesita, la información técnica manejarla en otros repositorios más seguros para los programadores de la misma.
CC: Toda aplicación web debería verse como insegura hasta que una empresa dedicada a la seguridad le haga un análisis adecuado y de las recomendaciones del caso.
GG: Cuarto, ver cuáles son los ataques comunes en ese momento y ver si estamos expuestos a ellos.
GG: Quinto y ultima, volver a probarla...
RJ: Perfecto, me parece que ha sido muy provechosa la IMtrevista, me queda claro que la situación es más crítica de lo que a veces estamos dispuestos a aceptar. Les doy las gracias a ambos por el tiempo que nos han concedido, esperemos elevar un poco así el nivel de consciencia que hay detrás del tema de seguridad.
Fuente: Blog de RicardoJ
No hay comentarios:
Publicar un comentario