Uno de los problemas a los que nos enfrentamos en organizaciones con una complejidad de red media o alta es la gestión de los permisos que implican a elementos de comunicaciones (switches, cortafuegos, routers, etc.); me gustaría esbozar algunas de las cosas hay que tener en consideración para que la gestión sea posible.

Primero de todo, ante la solicitud de una petición de acceso desde un servidor a otro por parte de algún responsable técnico de algún proyecto TIC de la compañía, hay que tener en consideración dos tipos de aspectos bien diferenciados:

• Aspectos funcionales: Si alguien solicita por ejemplo acceso al puerto de Oracle de un servidor de BBDD, lo primero que hay que evaluar es si desde el punto de vista de negocio, ese permiso debe de ser concedido. Este tipo de accesos deben ser validados por un responsable o autorizador funcional, que puede o no coincidir con el propietario del activo dentro de la organización. Es muy habitual que por agilidad en las gestiones, compañerismo mal entendido, o ausencia de procedimientos formales, este punto se pase por alto y se pase a los aspectos técnicos directamente, sin entrar a considerar la conveniencia de la solicitud desde el punto de vista del negocio.
• Aspectos técnicos: Una vez la autorización funcional ha sido concedida, hay que revisar los aspectos técnicos de los permisos solicitados, para detectar sus implicaciones técnicas sobre otros servicios, el perímetro de la red, problemas de seguridad, etc. Algunas de las cuestiones son: ¿la red origen esta controlada por la organización, o es una dirección externa ajena sobre la que no tenemos información? ¿El protocolo utilizado para la conexión es seguro? ¿Va cifrado? ¿Implica este acceso abrir accesos con redes no confiables? ¿Afectan a la DMZ? ¿Es posible utilizar soluciones alternativas? En cualquier caso, la recomendación es que si el cambio es de cierta relevancia, tiene que haber una auditoria, tanto de caja blanca como de caja negra; esto debería ser obligatorio para cualquier acceso externo a la red corporativa, como por ejemplo el de un nuevo proveedor.

Como todos los veranos, este año se ha celebrado la Black Hat, un conjunto de conferencias donde se desvelan las ultimas tendencias en seguridad, cubriendo con detalle la parte técnica aunque también cada vez mas la parte organizativa y social. Aunque desgraciadamente no he podido asistir a estas charlas, tantos los papers comos los slides están disponibles en la web en la parte de archivos Blackhat.

Muchos equipos investigadores esperan a este evento para desvelar sus descubrimientos, por lo que creo que son de lectura obligatoria para aquellos que quieren ver por dónde van las ultimas tendencias y el “state of the art” en el mundo de la seguridad.

Tras echar un vistazo a las presentaciones, uno tiene la impresión que nada es seguro, ya sean teléfonos móviles, parquímetros, infraestructuras eléctricas, medidas antihacking, certificados SSL, la virtualización, la nube, o cualquier tipo de hardware que puedan imaginar. Los malos pueden incluso leer tu teclado desde el enchufe de tu ordenador, así que la única opción parece ser volver a las cuevas. En fin, que para cualquier “maldad” que puedan imaginar ya hay quien se dedica a aplicarla… y en estas charlas se pueden ver muchas de ellas.

Después de ver los enemigos de los parches, esta vez toca hablar de los enemigos de la seguridad perimetral. En principio, todo apunta a que esto debería de ser una tarea muy sencilla, basada en la regla “sólo se deben de habilitar los permisos que sean necesarios”. Sin embargo, con rascar un poco sobre la superficie, es habitual ver grandes errores en la configuración y problemas en la gestión perimetral de las organizaciónes. En esta entrada vamos a comentar los enemigos técnico, estructurales y organizativos que hacen que aparezcan problemas en la seguridad perimetral de las organizaciones. En otras palabras, cómo es posible que se llegue, sin darse cuenta, a situaciones en las que la arquitectura de la red, o la reglas y ACLs implantadas no son correctas desde el punto de vista de la seguridad.

— Las prisas. Este es un problema típico de la seguridad en todos los niveles, y por tanto, también de la seguridad perimetral, que produce situaciones como “Esto tiene que salir a producción ya”, “Tú abre los puertos para que funcione para ver si es eso y luego ya veremos”, “Tú dale usuario y contraseña de la VPN y luego lo gestionamos como toca”, etc.

Solución: Debe considerarse la parte de comunicaciones y seguridad perimetral como una parte de cualquier proyecto de implantación.

El Nmap Scripting Engine (NSE) es una potente funcionalidad del Nmap que permite la ejecución de scripts, que además permite que los usuarios puedan escribir y compartir scripts para realizar multitud de tareas. El propio Nmap en sus últimas versiones incorpora varios scripts, algunos de los cuales me han resultado muy útiles últimamente. Las tareas que se pueden realizar con el NSE se agrupan en:

• Descubrimiento de red.
• Detección de versiones de servicios mejorada.
• Detección de vulnerabilidades.
• Detección de gusanos y backdoors.
• Explotación de vulnerabilidades.

El pasado 15 de Mayo dos miembros del equipo de seguridad lógica de S2 Grupo nos desplazamos a Barcelona para asistir al V OWASP Spain Meeting, donde como siempre pudimos asistir a conferencias de gran interés con ponentes de muy alta calidad:

1. Sintonizar la función de seguridad con el negocio (PDF). Alberto Partida, miembro del Advisory Board de SANS Institute y poseedor de un impresionante curriculum de certificaciones GIAC (entidad de certificación del SANS Institute), nos explicó la manera de compatibilizar los requisitos de seguridad con las necesidades del negocio, y nos explicó algunos trucos para aprender a mostrar la información a los directivos no tecnólogos de tal manera que entiendan a que riesgos se exponen, y nada mejor que ejemplificarlo con ejemplos de incidentes “sonados”. Una charla muy útil para cualquiera que se encuentre en una empresa no tecnológica o que ofrezcan servicios a empresas no tecnológicas.

Los sistemas de decepción de intrusos siempre me han parecido muy interesantes de cara a garantizar la seguridad de una organización; si bien los más complejos, las honeynets, no suelen implantarse con frecuencia salvo en entornos grandes y/o especialmente concienciados en temas de seguridad (digamos que los beneficios obtenidos del sistema no suelen cubrir el coste asociado a la implantación y al mantenimiento del mismo), los sistemas sencillos, los honeypots, tienen, bajo mi punto de vista, una buena relación coste/beneficio.

Dentro de los honeypots, los sistemas más triviales son los honeytokens: elementos que simplemente por “tocarlos”, por acceder a ellos, generan una alarma que puede proporcionar información muy valiosa a la organización: intentos de intrusión, intentos de robo de información, etc. Este subconjunto es particularmente interesante, porque a cambio de una inversión mínima —existen honeytokens muy sencillos, y su mantenimiento una vez implantados es casi inexistente— obtenemos una información de alto valor.

Como indicamos el pasado viernes en nuestro twitter, el pasado 5 de mayo llegó a la lista pen-test de Securityfocus el anuncio de la liberación de la version 1.0 de la herramienta VoIP Hopper, una herramienta para sistemas Unix/Linux, escrita en C y licenciada como GPL3, que nos va a ser muy útil para securizar nuestra red, concretamente la capa dos (muchas veces olvidada), debido a que está basada en la tecnica conocida como Vlan Hopping con la cual podemos ser capaces de saltar a una Vlan del switch a la que no pertenecemos.

Con la aparición de esta nueva versión de la herramienta, se amplía la lista de herramientas dedicadas exclusivamente a auditoría de redes de Voz sobre IP, como pueden ser SIPVicious, Voiper, sipdump/sipcrack, VoipPong, etc.

Puesto que cada día son más las empresas que llevan a cabo una unificación de sus comunicaciones, partiendo con la implantación de una red Voz usando su propia red local, y finalizando con la unificación total de sus comunicaciones (Voz sobre IP, mensajería unificada, servicio de presencia, etc.), la seguridad de la red se convierte en un aspecto crítico a tener muy en cuenta a la hora de realizar dicha integración, para garantizar, no solo la calidad del servicio, sino también la disponibilidad, confidencialidad e integridad de la informacion que atraviesa el sistema. Por lo tanto, en caso de disponer de sistemas VoIP en nuestra red, debe ser una buena práctica de seguridad llevar a cabo un plan de auditoría de vulnerabilidades específico contra los servicios que forman parte de dichos sistemas.

Es incuestionable que uno de los activos más valiosos de una empresa son sus datos, y como tal es imprescindible que estemos preparados para poder recuperar el servicio lo más rápido posible. Esta fórmula se aplica desde un simple fichero hasta la restauración de toda la infraestructura de un negocio.

Desde siempre, el método preferido para salvaguardar toda la información han sido nuestros amigos los llamados cartuchos o cintas. La diferencia de capacidad de almacenamiento entre estos dispositivos secuenciales y los discos duros de nuestras máquinas siempre ha sido bastante amplia, y prueba de ello es que para este mismo año se espera el lanzamiento de las cintas LTO5, con una capacidad nativa de 1,6Tb y comprimida de 3,2Tb. Y para el 2010/2011 las LTO6, doblando las características de las anteriores (¡¡hasta 6,4Tb en un solo cartucho!!).

Desde hace un tiempo, es de notoria actualidad la problemática que supone la pérdida y robo de equipos portátiles, con los consiguientes problemas al respecto de la información corporativa albergada en ellos; hasta una organización como el FBI llega a perder más de un centenar y medio, y aun peor, el Departamento de Energia de EEUU cifra en aproximadamente 1,400 los portátiles perdidos durante 6 años. En base a esto, hoy vengo a comentarles una técnica de protección presente en muchos portátiles, pero desconocida, y destinada a proteger la información de sus discos duros.

Todos los discos duros (según el estándar ATA de la Wikipedia) disponen de un mecanismo de protección mediante contraseña, que bloquea el acceso al disco si éste no recibe la contraseña adecuada al arrancar. Dicha opción está disponible en la BIOS del ordenador, normalmente identificada como HDD Password.

A menudo las organizaciones securizan su dominio protegible implantando una serie de controles tecnológicos que permiten impedir o en todo caso minimizar el impacto de actividades ilícitas por parte de terceras personal, o incluso las realizadas por el propio personal corporativo. Instalación de cortafuegos perimetrales, software de detección y eliminación de malware, proxys, sistemas de detección de intrusos y un largo etcétera, serían algunas de las medidas empleadas.

En este momento el responsable de TI de la organización siente una falsa sensación de seguridad, ya que descuida, entre otras cosas, las posibles vulnerabilidades latentes en el software de los servicios de DMZ. Normalmente estos servicios perimetrales (servidores de correo, DNS…) se sustentan en software de amplia distribución y con un soporte de actualizaciones de seguridad pero, ¿qué ocurre con la pagina web corporativa? Estos sites que ofrecen la imagen y la marca de la organización al resto del mundo son desarrollados de forma personalizada, sin un soporte, muchas veces, de actualizaciones de seguridad. Si quieres que corrija estos errores, paga el esfuerzo que requiere ese desarrollo adicional. Sí, esta frase es bastante común, dado que este tipo de situaciones no se contemplaron en el alcance del proyecto, ni se requirió que el desarrollo siguiera un marco de trabajo de desarrollo seguro.