Navegando por la red, encontré una guía realmente útil para la externalización del correo electrónico, está en la Web de la empresa Postini, a día de hoy parte de Google. Este enlace os llevará directamente al documento A Guide to Understanding Hosted and Managed Messaging. No obstante, os aconsejo que miréis los otros Whitepapers que tienen en su Web.

Mi trabajo fue sencillo: traducir, adaptar y completar. Creo que el resultado puede ser muy útil:

Preguntas que debe realizarse el CIO (Chief Information Officer).

• ¿Es el correo electrónico una competencia que deseamos mantener dentro de la empresa?
• ¿Tenemos suficientes técnicos o podemos contratarlos para poder gestionar las necesidades del correo electrónico a día de hoy y a futuro? ¿Podría complementar otras tareas que de sistemas que aporten más valor al negocio?
• ¿Cuánto nos costará desarrollar las nuevas tecnologías o necesidades de seguridad, encriptación,.. etc en los próximos años?
• ¿Cuál es el coste total de mantener el correo electrónico dentro de nuestra organización incluyendo los costes de oportunidad?
• ¿Cuánto nos costará migrar a un nuevo sistema cuando sea necesario?

Capacidades debe ofrecernos el proveedor

• ¿Qué capacidades nos ofrece hoy el proveedor y cuales tiene en el roadmap?
• Servicios de mensajería
  • Archiving
  • Backup
  • Encriptación
  • Unificación de mensajería
  • Movilidad
  • Conferencias Web
  • Integración con directorio activo
• ¿Qué e-mail servers/plataformas están soportadas? ¿Qué versiones?
• ¿Qué clientes de correo están soportados?¿Con qué nivel de integración?
• ¿Incluye el servicio de escaneado anti-spam y anti-virus en tiempo real?
• ¿Hay algún prerrequisito Hardware/Software que deban cumplir los equipos de los usuarios?
• ¿Cuántos centros de datos tiene el proveedor? ¿Y de qué tipo?
• ¿Qué tipo de herramientas y servicios de migración me ofrece?
• ¿Con que frecuencia se realizan actualizaciones? ¿Implican paradas del sistema?
• ¿Qué tipo de informes están disponibles?
• ¿Tiene el proveedor algún contrato de soporte especial con sus proveedores de tecnología y comunicaciones?
• ¿Qué tipo de servicios de recuperación de desastres ofrece el proveedor?

Consideraciones de arquitectura

• ¿Qué arquitectura de red necesitamos para asegurar que no habrá retrasos en la entrega de los mensajes y que no será almacenarnos en capas intermedias que puedan suponer un riesgo?
• ¿Qué tráfico o cantidad de tráfico se generará? ¿Ancho de banda por cuenta de correo electrónico?
• ¿Se realizan todas las noches backup completos de la información? ¿Cuál es la política de Backups?
• ¿Qué tecnología se utiliza en los servidores? ¿Es propietaria o de un tercero?
• ¿Esta pensada la arquitectura del proveedor y las comunicaciones para poder asumir crecimientos futuros? ¿A qué coste?

Fiabilidad

• ¿Cuáles son los SLAs (Service Level Agreements)?
• ¿Cuánto tiempo ha estado interrumpido el servicio el pasado mes? ¿y en los últimos 6 meses? ¿Y en el último año?

Seguridad

• ¿Cómo de segura es la infraestructura?
• ¿Qué controles hay para el acceso a los datos del cliente?
• ¿Qué controles de detección de intrusos existen para proteger el centro de datos donde estará almacenados los mensajes?
• ¿Qué elementos redundantes existen? (procesos de backups, telecomunicaciones, etc…)

Gestión de datos

• ¿Los datos estarán en un servidor dedicado o compartido?
• ¿En qué países se almacenarán los datos?

Servicios Ofrecidos

• ¿Cómo de integrados están los servicios ofrecidos? Por ejemplo, correos electrónicos, mensajería instantánea, LDAP,….
• ¿Qué productos complementarios hay disponibles?
• ¿Cuál es el tipo de soporte?
• ¿Cuántos niveles de soporte hay? ¿son todos 7×24? sino ¿en que horarios trabaja cada nivel y que cubre cada uno de ellos?
• ¿Tendremos un Account Manager después de la venta?
• ¿Podemos externalizar también DNS, páginas y aplicaciones Web?
• ¿Podemos revender el servicio? ¿En qué condiciones? ¿Con qué capacidad de gestión?
• ¿Qué tipo de herramientas son proporcionadas? ¿Incluyen Web Services o un API para poder integrar herramientas de terceros?
• ¿Cómo se gestionan las políticas de los diferentes canales de comunicación? (integradas en un solo sitio o son independientes.
• ¿Puede realizarse una administración distribuida? (por ejemplo, los administradores de IT regionales pueden controlar sólo un subconjunto de usuarios).
• ¿Pueden los usuarios finales controlar su propia configuración?
• ¿Los mensajes son almacenados en un disco y luego reenviados a nuestros clientes?

El proveedor

• ¿Es el proveedor financieramente valido?
• ¿Cuánto tiempo lleva el proveedor gestionando servicios de negocio o hosting?
  (seguridad, archiving, mensajeria, encriptación…)
• ¿A cuántos clientes da soporte el proveedor? ¿Cuál es su rotación? ¿Crece/Decrece el número?
• ¿Qué tipo y tamaño de clientes tiene el proveedor?
• ¿Puede el proveedor presentarnos a clientes suyos que tengan una organización similar a la nuestra?
• ¿Cuál es el volumen de mensajes que está soportando ahora mismo el proveedor y cuál es la evolución esperada? ¿Qué implicaciones tendrá en el rendimiento?
• ¿Qué y cuántas certificaciones tienen los empleados del proveedor?
• ¿Qué certificaciones y auditorias realizar el proveedor?

Migración fuera del proveedor

• ¿Cuáles son las condiciones para la terminación del contrato?
• ¿Cómo puede ser los datos exportados/migrados a otra solución diferente o a otro proveedor?

Otras preguntas

• ¿Ofrece el proveedor servicios profesionales? ¿Qué experiencia tienen?
• ¿Quién será el propietario de la información almacenada?
• ¿Para cumplir el SLA quien debe dar de alta las nuevas cuentas de usuarios?
• ¿Cómo afectan las migraciones de plataforma al servicio?

Compártelo

Tal y como ya habia anunciado Sun se ha presentado la versión open source del sistema operativo Solaris, OpenSolaris, con soporte mundial .

Artículo completo

Más información sobre OpenSolaris

Compártelo

Wombat (Worldwide Observatory of Malicious Behaviors and Attack Threats), que traducido al español es Observatorio Mundial de Comportamientos Maliciosos y Amenazas de Ataque, es un proyecto, que cuenta con la financiación de la Unión Europea (bajo el Séptimo Programa Marco), para unificar los departamentos de investigación de entidades con enfoques muy distintos, con la finalidad de obtener una perspectiva global, cada vez más necesaria a la hora de afrontar los retos de la seguridad en infraestructuras TI.

Básicamente, WOMBAT pretende recolectar grandes cantidades de información sobre elementos maliciosos que puedan afectar tanto a empresas como a los ciudadanos de a pie. Realizado en tiempo real, no se pretende solamente tener una visión más real de lo que realmente sucede en Internet, sino modelar dichos comportamientos en la medida de lo
posible. Todo esto es necesario si queremos tratar la seguridad atacando la raíz de los problemas, en vez de intentar aliviar los efectos . 

En la lista de participantes en este proyecto podemos por ejemplo contar con la participación de la Universidad Técnica de Viena y la gente que desarrolló Anubis. También participa la Universidad de Vrije (Ámsterdam), que entre otras cosas aportará su experiencia en diversos tipos de honeypots. La Politécnica de Milán aportará también su conocimiento en
estas lides, que incluye aspectos tan interesantes como las tecnologías IDS. Por parte de los CERT, contamos con la inestimable experiencia de NASK (Polonia), y también contamos con la perspectiva de los ISPs gracias a la colaboración del departamento de I+D de France Telecom (Orange). Desde Hispasec colaboraremos con nuestra experiencia en
el mundo del malware, y con la perspectiva que nos da mantener en funcionamiento VirusTotal.

Recientemente se ha realizado unworkshop con otras entidades que pueden estar interesadas en colaborar
en este proyecto, y que incluyen nombres como el SANS ISC, Honeynet Project, Universidad de Kyoto, Universidad Nacional de Yokohama, ENISA o la Universidad de Carolina del Norte.

Fuente: hispasec.com

Más información:

• Vombatidae
• Worldwide Observatory of Malicious Behaviors and Attack Threats
• Anubis: Analyzing Unknown Binaries
• VirusTotal

Compártelo

Siguiendo con el tratamiento del software libre, en esta ocasión nos centraremos en las herramientas de gestión de contenidos.

Si bien ya se ha escrito en otras ocasiones para explicar sus funcionalidades y para comentar alguna en concreto, Drupal; en este post se muestra una web dedicada a comentar y comparar las diferentes herramientas de gestión de contenidos (CMS) de software libre: www.cmsmatrix.org

Es una web creada por y para los usuarios de la comunidad de software libre, pues se realimenta de los comentarios realizados por sus propios usuarios.

Aparte de una serie de enlaces y foros de discusión, recoge un listado, bastante completo, de todos los CMS existentes. Pero, sin duda, su herramienta más potente es una tabla comparativa que muestra los requisitos del sistema, las funcionalidades de seguridad, gestión, soporte y rendimiento de los CMS seleccionados.

Compártelo

ActiveX es una tecnología propia de Microsoft que con el tiempo ha sido clasificada prácticamente de maldita en cuestión de seguridad. Los numerosos problemas tanto en la tecnología en sí como en los programas que la han usado, han hecho que se gane esta fama a pulso. ¿Cuáles son los riesgos y problemas de seguridad que presenta ActiveX realmente? ¿En realidad es tan peligrosa?

¿Qué es?

ActiveX es una librería (básicamente un ejecutable) con funciones, como otro cualquiera, con la peculiaridad de que implementa una interfaz llamada IDispatch que permite al “objeto” interactuar de una forma concreta (más abstracta) con el programa que lo aloja (llamado contenedor). Por tanto no son programas “independientes” y suelen crearse con cualquier lenguaje que admita el modelo COM. “Físicamente” tienen forma de librería DLL o OCX. Internet Explorer o Office son programas contenedores que admiten esta tecnología.

Un componente ActiveX es pues, código ejecutable (desarrollado por y para Microsoft) encapsulado en un objeto desarrollado mediante esos estándares. De esta forma al tener este código encapsulado, se facilita su portabilidad y reutilización. Así, es posible usar un objeto ActiveX (llamar a sus funciones) insertándolo en cualquier aplicación que lo soporte, independientemente del lenguaje con el que haya sido creado el control ActiveX. Un ejemplo común es usarlos para interactuar con Internet Explorer y el sistema, llamándolos a través de JavaScript.

Donde existe una relación única entre el código CLSID y el archivo OCX o DLL. Los análisis antivirus a través de web (sin necesidad de instalar el producto) suelen hacerse a través de un ActiveX registrado, las barras complementarias de Internet Explorer (Yahoo!, Google…) son ActiveX registrados, el programa de instalación de Windows Update y otros muchos que pasan desapercibidos para el usuario son todos ActiveX registrados. Pero también existen de serie muchos ActiveX instalados en Windows para el propio uso del sistema operativo, que no están pensados en ningún momento para tener nada que ver con la web o redes sino que aprovechan más su portabilidad y capacidad de ser reutilizados. Por último, muchos programas no basados en web que necesitan interactuar con otros contenedores registran sus propios controles ActiveX.

¿Es igual que los applets de Java?

ActiveX, de hecho, fue en parte la respuesta de Microsoft a los applets de Java, pero con importantes diferencias en las formas aunque con una filosofía parecida. Tanto los applets de Java como los ActiveX son en una buena parte programas descargados y ejecutados en local. Los creadores de la JRE ((Java Runtime Enviroment, el entorno donde se ejecutan los applets) supieron que esto supondría un riesgo desde el principio y por eso los applets se ejecutan “encerrados” en una sandbox virtual que impide que el código tenga acceso a otras partes del sistema (excepto si aprovechan vulnerabilidades del JRE para escaparse de la sandbox).

¿Por qué pueden resultar peligrosos?

Si nos centramos en la seguridad, el problema se puede presentar por varias vías:

• Un ActiveX, al contrario que un applet encerrado en la sandbox, tiene vía libre para acceder al sistema con los permisos del usuario que lo ejecute. Tiene el mismo efecto que ejecutar un programa cualquiera.
• En el modelo actual, un ActiveX instalado (registrado) por un usuario administrador está disponible para el resto. Está expuesto para todos y si contiene un problema de seguridad, afectaría a todos los usuarios.
• Muchos de los ActiveX, en el fondo, no son más que programas que se descargan e instalan desde Internet Explorer. Por tanto, por un lado, heredan los riesgos lógicos de la descarga y ejecución indiscriminada de cualquier otro programa. Pueden ser usados para distribuir malware en forma de ActiveX aunque no es el caso mayoritario.
• Pero la razón más importante por la que un control ActiveX puede resultar peligroso es por la misma que cualquier otro programa. No es más que una pieza de código programada por un ser humano y por tanto tendente a errores. El problema básico es que un fallo de seguridad en un componente ActiveX “se paga más caro” en ellos que en otras aplicaciones.
• Se paga más caro porque, aunque esté alojado en el sistema, ese OCX o DLL es a veces accesible a través de Internet Explorer. El navegador, como contenedor habitual, puede en ocasiones llamar a sus funciones y si estas tienen un fallo, explotarlo. A efectos prácticos, si tenemos un ActiveX (una DLL, por ejemplo) en el sistema para que funcione un programa cualquiera que nada tiene que ver con la web, una página que visitemos podría llamar (invocar) a esa DLL y explotar el fallo. Básicamente, una puerta abierta a ejecutables del disco duro desde Internet. De ahí su mayor peligro. La mezcla entre el diseño excesivamente tolerante (responsabilidad de Microsoft) y programas vulnerables mal diseñados (responsabilidad de los programadores del ActiveX) han hecho que la tecnología sea considerada insegura. Pero obviamente Microsoft ha impuesto buenos e importantes mecanismos para mitigar estos riesgos. La firma de código, la programación de los propios ActiveX donde se les dice qué pueden hacer, los kill bits, la configuración del propio navegador… muchos métodos han servido para hacer que los ActiveX no sean tan poderosos como su propio concepto les permite, aunque a veces las medidas no han sido suficientes.

Fuente: Hispasec.com

Compártelo