En esta ocasión trataremos el Modelado de amenazas (Threat Modeling [1]), que enlaza con el tema expuesto en el número anterior de la serie: Seguridad en el diseño. Ésta es sin duda una de las actividades de seguridad más importante de todo el SDL, ya que si el diseño de seguridad no es capaz de identificar los posibles riesgos y mitigarlos, las demás actividades (auditorías de código, pruebas de seguridad, implantación segura, etc.) serán de poca utilidad.

A lo largo de esta serie de artículos sobre SDL, hasta ahora nos hemos enfocado a proporcionar una sólida base en desarrollo seguro de aplicaciones mediante la introducción a los conceptos, metodologías y recursos necesarios, por lo que nos encontramos en una buena posición para entrar en aspectos más técnicos. En esta entrega vamos a tratar la seguridad en el diseño de una aplicación, la primera etapa del SDL-LOB.

En artículos anteriores, hemos introducido y analizado el Security Development Lifecycle (SDL) y sus tres variantes (SDL, SDL-LOB y SDL-Agile) para entender en qué consiste, sus fases, complicaciones, y sobre todo sus beneficios para la organización. En este artículo y sucesivos iremos profundizando en las distintas fases del SDL; en este número, concretamente, trataremos la formación y la gestión del talento, ya que de nada sirve intentar implantar un SDL si no contamos con las personas adecuadas.

En esta entrega, continuamos con nuestra exposición sobre el SDL de Microsoft, centrándonos principalmente en el desarrollo seguro de aplicaciones .NET, aunque en algún artículo futuro también haremos referencia a desarrollos en código nativo (C++) bajo Windows.

Este artículo da inicio a una sección dedicada al desarrollo de aplicaciones .NET seguras basándonos en SDL (Security Development Lifecycle) de Microsoft.

Este artículo presenta los resultados del análisis de cientos de revisiones de seguridad realizados por el equipo ACE Team/Information Security (INFOSEC) de Microsoft en todo el mundo entre 2008 y 2009.

Es un hecho contrastado que la Web está en constante evolución, llevando consigo un grado de sofisticación de las aplicaciones Web cada vez mayor y, en definitiva, una tendencia mayor de hacer de la Web una aplicación de escritorio. Paralelamente, el mayor nivel de complejidad de la Web da lugar a una serie de vulnerabilidades asociadas a estas nuevas funcionalidades.

En ocasiones es necesario tener un control exhaustivo de los accesos que se producen a nuestros servicios Web (quién accede, a dónde y cuántas veces), tanto por seguridad como para mantener la calidad del servicio. En este artículo veremos cómo podemos cumplir estos requisitos interceptando las llamadas realizadas por los clientes a nuestra plataforma de servicios Web.

En una entrega anterior (dotNetManía nº 41) presentamos los fundamentos de la Seguridad de acceso a código (Code Access Security, CAS) en .NET Framework, y describimos cómo el CLR determina los permisos del código y cómo se pueden manipular desde las herramientas administrativas los permisos concedidos a cada ensamblado. En esta entrega veremos cómo se pueden solicitar, manipular y limitar estos permisos desde dentro de nuestro código.

Una consulta frecuente entre los desarrolladores de aplicaciones .NET se refiere al hecho de que un programa que funcionaba perfectamente mientras se encontraba en desarrollo deja de funcionar cuando se pasa a producción por el método de copiarlo a una carpeta en un servidor y ejecutarlo desde ella. En este artículo examinamos la forma en que .NET determina los permisos de los ejecutables y cómo éstos se pueden modificar para resolver casos como el indicado. En un futuro artículo detallaremos cómo podemos aprovechar estos mecanismos de seguridad desde nuestro código.

En este artículo se presentan los conceptos generales relacionados con la seguridad desde el punto de vista de Windows Communication Foundation (WCF), para luego presentar en detalle dos de sus características fundamentales: la autenticación y la autorización.

La criptografía nos permite proteger los datos de forma tal, que la visualización o modificación de los mismos solo sea posible para aquellos que conozcan la forma en que han sido encriptados. Esto es aplicable no solo a la comunicación entre dos puntos, sino también al contenido de nuestros ficheros. Además de proteger la información, también podemos utilizar la criptografía para garantizar que los datos no han sido alterados y que provienen de una fuente fiable.

Supongamos que estamos trabajando en un entorno de autenticación en que se utilizan diversos datos biométricos (análisis de retina, huellas dactilares, análisis de voz, etc.), y tras aplicar una función sobre ellos se obtiene un identificador solo conocido por el sistema. Cualquier persona que quisiera suplantar nuestra identidad debería conocer todos estos datos para plantear un ataque con éxito, puesto que con un solo error en alguna de las variables el identificador resultante no sería válido. En este artículo veremos cómo plantear este escenario en nuestras aplicaciones ASP.NET imitando el modelo del protocolo Kerberos.

Prácticamente cualquier aplicación que creemos va a necesitar seguridad en el acceso a sus diversas secciones. Lo habitual es tener apartados a los que sólo pueden acceder miembros registrados o una zona de administración restringida a los gestores del sistema. ASP.NET 2.0 ofrece multitud de novedades en este aspecto que nos van a simplificar mucho el trabajo.

En este artículo se describe paso a paso cómo conseguir e instalar un certificado digital SSL en un equipo con la versión 5.0 o 6.0 de Microsoft Internet Information Server (IIS) para conseguir que nuestro sitio Web transmita datos confidenciales de forma segura.Es una de las preguntas mas frecuentes de los foros de IIS en microsoft.public.es.iis.

Mucho se ha hablado de la seguridad de las páginas ASP.NET. Pero más importante aún es el hecho de asegurar nuestros servicios de negocio. Veremos como proteger nuestros servicios con modelos de autenticación / autorización y cómo escribir nuestros clientes para diseñar entornos distribuidos seguros.

El desarrollo de aplicaciones seguras es un proceso realmente complejo, y que en la mayor parte de las aplicaciones no se tiene en cuenta en su conjunto. Los programadores estábamos acostumbrados, hasta no hace no mucho tiempo, a no pensar en esto, y dejar los temas de la seguridad en mano de los administradores de sistemas. Sin embargo, cada vez son más los agujeros de seguridad que explotan los códigos maliciosos, ocasionados por malas prácticas de programación. En este artículo se describe la utilización de una herramienta, Microsoft Application Verifier, que puede ser un buen primer paso para el testeo de la seguridad de nuestras aplicaciones.

En las anteriores entregas de esta serie de artículos hemos tocado los grandes grupos temáticos relacionados con la seguridad de IIS. Todavía nos quedan por ver, sin embargo, algunos que no se pueden clasificar de forma tan clara y que vamos a tratar ahora para terminar.

En las dos anteriores entregas de esta serie hemos aprendido a fortalecer la seguridad de IIS aprovechando las características propias del sistema operativo. Además de esto Microsoft pone a nuestra disposición algunas herramientas gratuitas pensadas para proteger a IIS y que conviene conocer.

La autenticación de usuarios es tan sólo una pequeña parte de los problemas que debemos resolver en la seguridad de nuestro servidor IIS. Otro de ellos es la autorización.

Muchos programadores tienden a considerar la seguridad de sus aplicaciones únicamente desde el punto de vista del código (si piensan en ella en absoluto). En realidad hay muchos otros ámbitos que proteger. En el caso de las aplicaciones Web que se ejecutan bajo IIS, la adecuada configuración de éste es fundamental para asegurar la protección de aquellas, y por ende, la de todo el sistema.

En este artículo encontrará una guía sencilla, paso a paso, de cómo configurar un sitio web seguro en IIS 6 con certificado de clientes.

Leyendo el pasado número de dotnetmanía me encontré con el estupendo artículo “El poder de la reflexión en .NET”, donde se explicaba la potencia del espacio de nombres System.Reflection y su aplicación a la factorización de clases .NET. En el último apartado del artículo y utilizando la misma técnica se mencionaba un agujero de seguridad en el entorno de ejecución de .NET e incluso se proporcionaba el código fuente para explotarlo. Después del susto inicial me disponía a reproducirlo en mi máquina cuando me di cuenta del error que cometía el artículo, ¿qué detalle se pasó por alto?