32012

contenido

» opinión

» editorial

6 Prepararse para enfrentar incidentes de seguridad

10 El mundo de las bitácoras. (Parte 1: problemática)

14 SAP: una plataforma altamente funcional y altamente expuesta

32 Mejora continua: camino al éxito

34 Modelo de referencia de procesos en Cobit 5

36 Amenazas y vulnerabilidades Carrier Class

18 La seguridad y nuestros elefantes (segunda parte)

4 EditorialHéctor Acevedo Juárez

David Bernal Michelena

Omar Alcalá Ruiz

Esteban San Román Canseco

Diana Cadena Martínez

Ricardo Javier Ramírez Díaz

José Juan Cejudo Torres

Ulises Castillo Hernández

» conexiones

» misión: crítica

28

18

6

4Dirección General

Ulises Castillo Hernández

Editor en jefeHéctor Acevedo Juárez

EditoresGerardo Fernández Miranda

David Gutiérrez Jiménez

Consejo EditorialUlises Castillo Hernández

Priscila Balcázar HernándezHéctor Acevedo Juárez

Gerardo Fernández MirandaElia Fernández Torres

ColaboradoresHéctor Acevedo Juárez

Omar Alcalá RuizDavid Bernal MichelenaDiana Cadena Martínez

Ulises Castillo HernándezJosé Juan Cejudo TorresDavid Gutiérrez Jiménez

Eduardo Patricio Sánchez DíazRicardo Javier Ramírez Díaz

Esteban San Román Canseco

Marketing y ProducciónKarla Trejo Cerrillo

Correctora de estiloAdriana Gómez López

DiseñoSilverio Ortega Reyes

Magazcitum, revista trimestral de Scitum S.A. de C.V. Año 3, número 4, 2012. Editor responsable: Héctor Acevedo Juárez. Número de Certificado de Reserva otorgado por el Instituto de Derechos de Autor: 04-2010-071512010500-102. Número de certificado de Licitud de Título y Contenido: 14900, Exp.: CCPRI/3/TC/10/18827. Domicilio de la Publicación: Av. Paseo de la Reforma 373 piso 7, Col. Cuauhtémoc, delegación Cuauhtémoc, México DF 06500. Impreso en : Rouge & 21 S.A. de C.V. Av. Rómulo O’Farril # 520 int 5 Col. Olivar de los Padres México DF. Distribuida por Editorial Mexicana de Impresos y Revistas S.A. de C.V: Oaxaca 86-402 Col. Roma México DF. Magazcitum, revista especializada en temas de seguridad de la información para los profesionales del medio. Circula de manera controlada y gratuita entre los profesionales de la seguridad de la información. Tiene un tiraje de 5,000 ejemplares trimestrales. El diseño gráfico y el contenido propietario de Magazcitum son derechos reservados por Scitum S.A. de C.V. y queda prohibida la reproducción total o parcial por cualquier medio, sin la autorización por escrito de Scitum S.A. de C.V. Fotografías e ilustraciones son propiedad de Photos.com, bajo licencia, salvo donde esté indicado. Marcas registradas, logotipos y servicios mencionados son propiedad de sus respectivos dueños. La opinión de los columnistas, colaboradores y articulistas, no necesariamente refleja el punto de vista de los editores.

Para cualquier asunto relacionado con esta publicación, favor de dirigirse a contacto@magazcitum.com.mx

10AÑO 3, NÚMERO 4, 2012

28 Departamento de defensa La cédula de identidad personal, un reto magnífico para el gobierno

David Gutiérrez Jiménez

30 En el pensar de...Programas de concientización

Eduardo Patricio Sánchez Díaz

4

editorial

CISSP, CISA, CGEIT, ITIL y MCSEhacevedoj@scitum.com.mx

Fin de año,hora de recapitulación

Héctor Acevedo Juárez

Acaba el 2012 y, como siempre en época navideña, es hora de recapitular sobre las dificultades y los logros del año para empezar a vislumbrar lo que será el 2013.

En Magazcitum hemos tenido un año lleno de retos que, afortunadamente, hemos logrado superar; seguimos consolidándonos como una opción diferente de divulgación en el ámbito de la seguridad informática y tenemos planes muy ambiciosos para los siguientes meses. Muchas gracias a nuestros suscriptores, a los anunciantes y a todo el equipo de Scitum, sin cuya lealtad sería imposible mantener la versión impresa, que ya llegó a tres mil suscriptores, y el sitio Web de la revista.

Así las cosas, en ésta última edición del año tenemos una mezcla interesante de temas, que van desde cuestiones más o menos técnicas hasta temas relacionados con mejores prácticas y modelos de gobierno, sin dejar de tocar temas que incluso tienen que ver con la manera en que opera nuestro cerebro, todo desde el punto de vista de seguridad informática.

Nuevamente agradezco sus visitas y comentarios en el sitio Web de la revista (www.magazcitum.com.mx), siempre es un placer saber qué opinan de los temas tratados por nuestros colaboradores.

Muchas gracias por su atenta lectura ¡Feliz Navidad y un mejor 2013 para todos!

Héctor Acevedo Juárez

Ilustraciones: Silverio Ortega Reyes

52012

6

opinión

Prepararse para enfrentarincidentes de

seguridadGCFE, GCFA y ACE

David Bernal Michelena

En alguna ocasión tuve la oportunidad de responder a un incidente de seguridad en una importante organización que fue víctima de un atacante, quien logró realizar transacciones millonarias no autorizadas en la base de datos de esta empresa. Desafortunadamente la organización no estaba preparada para un evento de esta naturaleza y no fue posible identificar el origen del ataque. En este artículo explicaré las actividades de preparación que, de haberse realizado, hubieran proporcionado una mayor probabilidad de éxito en la investigación del incidente.

f.Bitácora de IDS/IPS: brinda información sobre actividad sospechosa del tipo de ataque que se haya presentado en la red. En caso de contar con la funcionalidad adicional de prevención de intrusiones, la bitácora debe indicar la acción realizada por el dispositivo.

g.Eventos de autenticación: en entornos empresariales que usan la tecnología de acceso mediante directorios, como directorio activo, es fundamental habilitar el registro de los eventos de autenticación exitosos así como de los fallidos. Estas bitácoras proporcionan indicios de que se realizó la autenticación desde una dirección IP y una cuenta de usuario en específico. Los intentos fallidos proveen indicios de ataques de adivinación de contraseña y fuerza bruta. Ejemplos: en el controlador de dominio de Windows el inicio y fin de sesión exitoso se registra en los eventos con ID 528 y 540 y los fallidos en los eventos con ID 529-537. En sistemas basados en UNIX los eventos de autenticación se registran en la bitácora auth o security logs, normalmente ubicados en el directorio /var/log.

h.Tecnologías de acceso remoto: en caso de utilizarse una tecnología de acceso remoto, como terminal services, VPN, escritorio remoto, alguna variante de VNC o TeamViewer, deben habilitarse las bitácoras que indiquen los eventos de acceso de usuarios con fecha y hora. Ejemplos: TeamViewerx_Logfile.log de la aplicación TeamViewer y bitácora de conexiones de terminal services.

i.Eventos de sistema operativo: proporcionan valiosa información sobre el uso de un equipo final. En sistemas operativos basados en Windows, esta información estará en las bitácoras de eventos, así como el registro de Windows3. En sistemas basados en UNIX, estará en las bitácoras del sistema manejadas por syslog.

Ejemplos: bitácoras de sistema, seguridad y aplicación en Windows. Bitácora del directorio /var/log para sistemas basados en UNIX y log de historial de comandos ejecutados por los usuarios (.bash_history para sistemas con bash).

3.Implementar repositorios centralizados de bitácoras.

En caso de que un atacante logre acceder a un sistema crítico y obtener privilegios de súperusuario, probablemente eliminará sus huellas de ese sistema. Si contamos con un repositorio centralizado de eventos, ya sea un servidor syslog o un correlacionador, se preservarán los indicios de esa actividad no autorizada para su posterior investigación. Es recomendable usar un canal cifrado para enviar la información a los repositorios a fin de proteger la confidencialidad de la información mientras se encuentra en tránsito. A continuación enlisto los mecanismos más comunes que se usan para la centralización de bitácoras:

1.Sincronizar los dispositivos de red y de host mediante el protocolo NTP.

El protocolo NTP (network time protocol) sincroniza los dispositivos de red como switches, ruteadores, firewalls, equipos de cómputo, etcétera. La sincronización se refiere a ajustar los tiempos de reloj de los dispositivos al mismo reloj de referencia. De no realizarse esta actividad de fácil implementación se puede entorpecer enormemente la investigación forense digital.

2.Habilitar y preservar bitácoras de auditoría.

En muchas ocasiones, los administradores de los servicios se conforman con que sus sistemas se encuentren operacionales, pero es importante ir más allá y asegurarse de garantizar la rastreabilidad de las operaciones ejecutadas, por lo menos en los equipos que son críticos para el negocio o bien en los que manejan información sensible del negocio. Las bitácoras pueden contener información confidencial, así que deben protegerse con controles tanto físicos como lógicos. A continuación enlisto las bitácoras de auditoría que, en términos generales, es más importante habilitar y preservar1:

a.Base de datos: bitácora transaccional y de conexiones directas a la base. Es necesario realizar un análisis de línea base para dimensionar qué tan rápido crecerán las bitácoras y definir los procedimientos para enviarlas a cintas o respaldos fuera de línea. Así mismo debe balancearse el costo, impacto y beneficios de las medidas de seguridad2, ajustar de forma granular la auditoría, considerando las operaciones críticas, por ejemplo la tabla de usuarios y contraseñas, o la tabla de saldos, en el caso de los sistemas financieros.

Ejemplos: bitácoras general y binaria en MySQL, bitácoras redo y listener en Oracle.

b.Servidor Web: habilitar las bitácoras del servidor Web, tanto de acceso como de error y asegurarse de registrar tanto el método POST como el método GET. Ejemplos: access.log y error.log de Apache y log de conexiones de IIS.

c.Bitácoras de DHCP: En caso de utilizarse el protocolo DHCP, que asigna de manera dinámica configuración IP a un dispositivo final, las bitácoras permiten asociar el

dispositivo físico, por medio de su dirección MAC, a la dirección IP asignada por el servidor DHCP.

Ejemplos: mensajes de asignación de configuración IP de DHCP (leases).

d.Bitácoras de firewall de red: almacenan información del tráfico entrante y saliente desde y hacia la red de datos, así como de las traducciones de direcciones IP (NAT) realizadas por el firewall y, en algunos casos, de las conexiones realizadas de forma remota mediante el protocolo VPN.Ejemplos: bitácora de conexiones del firewall de la organización. La mayoría de los fabricantes de este tipo de dispositivos proveen la funcionalidad y es solo cuestión de habilitarla.

e.Bitácoras de firewall de host: almacenan información del tráfico entrante y saliente desde y hacia un equipo final. Ejemplos: bitácora del firewall de Windows, bitácora de firewall iptables o packet filter en sistemas basados en plataforma UNIX.

72012

f.Bitácora de IDS/IPS: brinda información sobre actividad sospechosa del tipo de ataque que se haya presentado en la red. En caso de contar con la funcionalidad adicional de prevención de intrusiones, la bitácora debe indicar la acción realizada por el dispositivo.

g.Eventos de autenticación: en entornos empresariales que usan la tecnología de acceso mediante directorios, como directorio activo, es fundamental habilitar el registro de los eventos de autenticación exitosos así como de los fallidos. Estas bitácoras proporcionan indicios de que se realizó la autenticación desde una dirección IP y una cuenta de usuario en específico. Los intentos fallidos proveen indicios de ataques de adivinación de contraseña y fuerza bruta. Ejemplos: en el controlador de dominio de Windows el inicio y fin de sesión exitoso se registra en los eventos con ID 528 y 540 y los fallidos en los eventos con ID 529-537. En sistemas basados en UNIX los eventos de autenticación se registran en la bitácora auth o security logs, normalmente ubicados en el directorio /var/log.

h.Tecnologías de acceso remoto: en caso de utilizarse una tecnología de acceso remoto, como terminal services, VPN, escritorio remoto, alguna variante de VNC o TeamViewer, deben habilitarse las bitácoras que indiquen los eventos de acceso de usuarios con fecha y hora. Ejemplos: TeamViewerx_Logfile.log de la aplicación TeamViewer y bitácora de conexiones de terminal services.

i.Eventos de sistema operativo: proporcionan valiosa información sobre el uso de un equipo final. En sistemas operativos basados en Windows, esta información estará en las bitácoras de eventos, así como el registro de Windows3. En sistemas basados en UNIX, estará en las bitácoras del sistema manejadas por syslog.

Ejemplos: bitácoras de sistema, seguridad y aplicación en Windows. Bitácora del directorio /var/log para sistemas basados en UNIX y log de historial de comandos ejecutados por los usuarios (.bash_history para sistemas con bash).

3.Implementar repositorios centralizados de bitácoras.

En caso de que un atacante logre acceder a un sistema crítico y obtener privilegios de súperusuario, probablemente eliminará sus huellas de ese sistema. Si contamos con un repositorio centralizado de eventos, ya sea un servidor syslog o un correlacionador, se preservarán los indicios de esa actividad no autorizada para su posterior investigación. Es recomendable usar un canal cifrado para enviar la información a los repositorios a fin de proteger la confidencialidad de la información mientras se encuentra en tránsito. A continuación enlisto los mecanismos más comunes que se usan para la centralización de bitácoras:

«Realizar las actividades descritas en

este artículo implica invertir tiempo, dinero y esfuerzo, pero

no realizarlas puede implicar una mayor pérdida, incluso también de

la reputación o hacerse acreedores a sanciones por incumplir regulaciones

oficiales»

8

a.Syslog: se basa en el protocolo de red Syslog, el cual se configura en los equipos donde se originan los eventos para enviarlos al equipo configurado como repositorio de bitácoras de eventos. Tiene una especificación de múltiples orígenes (llamados facilidades) incluyendo eventos de seguridad y autenticación así como niveles de severidad. En conjunto estos dos parámetros permiten identificar fácilmente la información de interés en una investigación forense de red.

b.Correlacionador de eventos:

además de almacenar los eventos, cuenta con capacidad de análisis de reglas, correlación y seguridad proactiva. Obtiene información de varios canales y normaliza las bitácoras en un formato estandarizado. Esta fuente de información es tan buena como las reglas desarrolladas por el analista que las configuró, así que es conveniente comparar los datos normalizados contra las bitácoras originales.

Realizar las actividades descritas en este artículo implica invertir tiempo, dinero y esfuerzo, pero no realizarlas puede implicar una mayor pérdida, incluso de la reputación, o hacerse acreedores a sanciones por incumplir regulaciones oficiales. Aplicar estas medidas es una tarea compleja y se debe realizar como un proyecto planeado, administrado y controlado, con el fin de impactar al mínimo las operaciones del negocio. En tales circunstancias la consultoría de una empresa externa especializada en seguridad informática incrementa el éxito de un proyecto de esta naturaleza.

4.Capacitar al personal.

Es fundamental contar con personal operativo con los conocimientos necesarios para contener el incidente y preservar las fuentes de información necesarias para realizar la respuesta inicial oportuna ante un incidente de seguridad. De no ser así, los indicios podrían sobrescribirse en cuestión de minutos u horas, dependiendo de su nivel de volatilidad, lo cual podría ser fatal para la investigación. Es importante que el personal lleve un registro escrito de todas las acciones realizadas durante la contención del incidente, así como la fecha y hora en que fueron realizadas.

5.Implementar controles.

Desarrollar controles normativos, tecnológicos y operativos que incluyan políticas y procedimientos, preferentemente a través de regulaciones de aceptación internacional, como el estándar ISO-27001 y a través de regulaciones en función del negocio como lo es PCI para organizaciones que manejan información de tarjetas de crédito, CNBV para el sector financiero, HIPPA para el sector salud y la Ley Federal de Protección de Datos Personal en Posesión de Particulares. Estos controles proveen el mejor soporte para casos con alcance legal y reducen los riesgos asociados al manejo del incidente. Además, los controles deben incluir actividades de auditoría para asegurar que los procesos y procedimientos se ejecuten correctamente.

1http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf2http://www.gartner.com/id=19507163http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/

Default.aspx

NetIQ, el logo NetIQ y Sentinel son nombres o marcas registradas de NetIQ Corporation, en los Estados Unidos. Todas las otras marcas, nombres comerciales o nombres de compañías son propiedad de sus respectivos dueños. © 2012 NetIQ Corporation y sus afiliados. Todos los derechos reservados.

NetIQ® Sentinel™ 7• Búsqueda dinámica y reportes con un solo clic

• Enriquecimiento de identidades y eventos

• Creador gráfico de reglas de correlación

• Detección de anomalías avanzada

• Empaquetado de dispositivos virtuales

Para obtener más información sobre Soluciones de Gestión de la

Seguridad de NetIQ, visite www.netiq.com.

Poderosamente Simple

Seguridad de la Información y la Gestión de Eventos

NetIQ_APAC_CSOBuyersGuideAd_SPA_f.indd 1 7/19/2012 2:24:24 PM

10

En esta ocasión quiero hablarles acerca de un problema que aqueja a muchas organizaciones respecto a la

información que se genera en las bitácoras (de lo que sea). En el presente artículo intentaré aclarar qué es una bitácora,

su importancia, tipos y retos alrededor de ellas. En una segunda entrega proveeré soluciones enfocadas a almacenar y explotar la información que en ellas se contiene.

opinión

El mundo de lasbitácoras

(parte 1: problemática)

CISSP, ISO-27001 y CCNAoalcala@scitum.com.mx

Omar Alcalá Ruiz

¿Qué es una bitácora?

En sí, la bitácora es un objeto marítimo que ayuda en colocar la aguja que apunta siempre al norte y orienta a la tripulación, nada que ver con registros. Lo que normalmente conocemos como bitácora se debe a una a contracción del nombre “cuaderno de bitácora”, en el que se guardan registros de los acontecimientos en una embarcación. Debo confesar que me sorprendí cuando supe la verdad sobre el origen de la palabra bitácora.

Por analogía, se le llama bitácora a un conjunto de registros de lo que sucede en proyectos, sistemas, etcétera. En TI se usa bitácora como traducción indistinta de log y log files, aunque en realidades la equivalencia del nombre “log” en inglés es “registro” y para “log files” o simplemente “logs” como plural es “bitácora”.

Importancia de las bitácoras

Ante una crisis, falla o suceso relevante de un dispositivo o sistema, todos queremos saber qué sucedió y es cuando surge la pregunta sobre la existencia de registros, y si existen, sobre quién los administra o incluso por cuánto tiempo se guardan.

Hay elementos de la vida cotidiana que no sabemos que son registrados, sin embargo, ante una catástrofe, la bitácora nos alecciona sobre lo que pasó y cómo podemos mejorar para que no cometamos los mismos errores, o para protegernos de lo que no controlamos. El ejemplo clásico es la caja negra de un avión: esta es una bitácora que registra, entre otras cosas, datos de la computadora de vuelo, todas las llamadas entre el avión y la torre de control, sonidos en la cabina, registros del estado operativo de todos los componentes del avión, itinerario, etcétera. Cuando por desgracia hay un accidente, la bitácora (caja negra) se encuentra almacenada en un recipiente que resiste los violentos impactos de una catástrofe aérea; recuperarla permite saber, a partir de un análisis forense, si hubo un error humano, una inclemencia del tiempo, una falla del avión o simplemente un evento desafortunado.

Así como la bitácora de un avión nos permite aprender sobre lo sucedido, una bitácora de sistemas debe permitirnos hacer lo mismo sobre las actividades en nuestro entorno, desde un simple “login” a una Intranet, hasta saber quién pudo haber cambiado tablas en la base de datos del sistema de facturación.

112012

Las bitácoras se vuelven elementos clave cuando tenemos que hacer frente a auditorías, donde todo debe comprobarse para obtener alguna certificación, o bien para cumplir con regulaciones que avalen a nuestras organizaciones. También son vitales para los análisis forenses, para los que se deben cumplir ciertos estándares de forensia digital para poderse catalogar como evidencia.

Elementos indispensables

Una bitácora deberá tener la característica de trazabilidad. A partir de ella, deberíamos obtener información que responda las cuatro preguntas básicas: ¿qué?, ¿quién?, ¿cuándo? y ¿a través de qué medio?

1. "¿Qué?” nos permite responder cuál fue el elemento manipulado.

2. "¿Quién?” apunta hacia la entidad que interactuó con el elemento de nuestro interés. Puede ser una persona, un sistema, un grupo o una dirección IP. Lo que debe ser contundente es que esta información nos proporcione el rastro al que queremos llegar. Por ejemplo, si obtenemos como respuesta el usuario genérico sadmin (suponiendo que este usuario es usado por varias personas de forma indistinta), no hemos logrado realmente contestar la pregunta.

3. “¿Cuándo?” nos dice el tiempo de lo sucedido. Entre más granular, mejor, ya que un evento suscedido en cierto momento puede ser normal, pero si ocurre dos minutos más tarde ya podría ser algo sospechoso. Una característica, necesaria para tener un marco adecuado de referencia del tiempo es la sincronía: se debe cuidar que las bitácoras se registren a un mismo tiempo. El acceso a un sistema que se registre una hora después de la modificación de privilegios de un usuario es inconsistente y no puede ser tomado como evidencia en un caso.

4. “¿A través de qué medio?” nos indica el o los vehículos que se usaron para realizar el evento. Podría ser que una tarea programada haya sido la encargada de cambiar la propiedad de un conjunto de archivos de un directorio, o que se accedió a un switch para habilitar un puerto dentro del centro de datos.

Es muy importante advertir al lector que lo antes dicho no significa que una bitácora deba tener cuatro campos y con esto se obtenga toda la información. Pueden requerirse muchos más datos, o estar divididos en unidades más granulares para el procesamiento. La intención de estas cuatro peguntas es darle al analista información suficiente para llegar a una determinación inicial e informar de manera contundente a los altos mandos, así como contar con datos que permitirán indagar más a fondo si es necesario.

Las bitácoras son tan relevantes en la investigación de eventos que no es de sorprender que una de las primeras metas de una prueba de penetración o de un hacker sea apagar las bitácoras, o al menos ocultar información de quién perpetró las actividades no autorizadas. La información contenida en las bitácoras debe clasificarse, ya que provee información vital acerca de los sistemas o los usuarios, y puede ser un requerimiento regulatorio. Por ello, no basta con tener bitácoras, es preciso salvaguardarlas y hacer que cumplan las regulaciones estipuladas.

Es muy importante clasificar las bitácoras, restringir el acceso a ellas, determinar si se requerirá alguna protección adicional, e incluso definir el método de destrucción o transferencia de información en caso de que un tercero las gestione.

Una Torre de Babel

Por lo general, las bitácoras se clasifican de acuerdo a su orientación:

» Aplicación: indican los sucesos que están activados para registrarse en una aplicación.

» Seguridad: orientadas a dar información de seguridad.

» Sistema: registran actividades del sistema (usualmente donde reside la aplicación).

Así, cualquier aplicación, sistema o pedazo de software o hardware específico puede producir una bitácora. Lo importante es que cada elemento de acción genere una.

Hasta aquí todo suena muy sencillo, parecería que las bitácoras son fácilmente manejables y que todo podría registrarse y ubicarse fácilmente en pocos segundos, entonces, ¿dónde están los retos?

12

Imaginemos una arquitectura de sistemas donde tenemos elementos de diferentes fabricantes: sistemas operativos Linux, Oracle, Windows y AS400 montados para correr aplicaciones diversas como bases de datos Oracle, SQL Server, servidores Web Apache, IIS, sistemas de negocio como SAP, correo Lotus o desarrollos propios. Alrrededor de ellos están, por supuesto, sistemas de redes y seguridad como switches, routers y firewalls. Adicionalmente, hay sistemas de monitoreo de servidores, redes o sistemas físicos, como accesos al site o datos de UPS.

Hay muchos elementos que no están homologados entre todas esas estructuras, y uno de ellos son las bitácoras. No hay un estándar oficial que indique lo que una bitácora debe contener. Existen intentos en la industria, como el formato CEE (common event expression) el cual es el más apoyado para unificar las bitácoras bajo un mismo tipo. Un sistema de facto usado para la generación de bitácoras es el envío de registros Syslog, un programa que nació como bitácoras para sistemas de correo electrónico a principios de los años 80 y que pronto se propagó a otros elementos de los sistemas UNIX para generar registros. En términos computacionales ya es arcaico, pero aún así es lo más usado en la actualidad. También hay varios tipos de bitácoras que se clasifican de acuerdo con la forma en que se generan:

» Archivos: los sistemas como Linux generan bitácoras en archivos (tipo FILE). Aquí se recolecta el archivo para procesar las bitácoras desde ahí.

» Base de datos: varias aplicaciones, en especial las desarrolladas en casa, generan bitácoras que se almacenan en bases de datos. La extracción de estas bitácoras usualmente sucede mediante conexiones ODBC/JDBC.

» Windows Event Log: bitácora de eventos del sistema operativo de Microsoft.

» Check Point Log: btácora específica de Check Point extraíble mediante conexiones propietarias LEA.

» Y otros más como por ejemplo SDEE, Mainframe y CEF.

Con el paso de los años, cada vez surgen más tecnologías y sin una estandarización en la industria, cada programador y fabricante se las ingenia a su modo para generar registros, lo que representa un gran problema para quienes deben lidiar con las bitácoras.

La aguja en el pajar (¡y vaya pajar!)

Hacer cosas cerca de la velocidad de la luz (electrones en una tarjeta madre) hace que en un segundo pasen muchísimos acontecimientos. Para muestra, el siguiente párrafo:

Si consideramos que un firewall mediano podría generar veinte eventos por segundo en promedio (dependiendo del número de reglas activas, tamaño de la red, nivel de registro en las reglas y sistema, nivel de uso a lo largo del día, etcétera), estamos hablando de 51.8 millones de registros generados mensualmente. Si requiero guardar las bitácoras de veinte dispositivos a una tasa similar, habré generado en un mes mil millones de eventos. Buscar una bitácora en veinte sistemas diferentes para luego tomar una decisión se vuelve una tarea titánica, además de tediosa.

Ahora el tamaño: un registro típico de Syslog puede medir alrededor de 250 bytes. Sin compresión, los mismos mil millones de registros se vuelven 260 GB de información para guardar cada mes. Sin embargo, un registro de tipo base de datos puede medir 1 KB, o de Windows 500 bytes. Como puede verse, aunque los logs son pequeños, su generación tan rápida consume mucho espacio en disco.

Muchos retos, ¿qué sigue?

Las bitácoras son parte esencial para conocer nuestro entorno, son un elemento esencial de la seguridad como parte de información de medidas preventivas y correctivas, por lo que la seguridad de las mismas también es esencial. Recuerdo la película “Training Day”, con Denzel Washington, donde este le comenta a su aprendiz (Ethan Hawke): “It’s not what you know, it’s what you can prove” (no es lo que sabes, sino lo que puedes probar). Estas palabras son determinantes a la hora de considerar por qué las bitácoras son importantes.

Curiosamente, las bitácoras son piezas que parece que la industria tampoco considera valiosas, porque ni siquiera existe un estándar oficial. Analizando un poco la actuación de otras personas, los hackers tienen un interés muy poderoso en las bitácoras a la hora de penetrar un sistema, pues eliminan los rastros ¿Es que solo ellos pueden apreciar el poder de las bitácoras?

Por ahora aquí me detengo. En la siguiente entrega hablaré de estas y otras consideraciones como los sistemas de gestión de bitácoras, y daré algunos datos de dimensionamiento que espero puedan ayudarlos en la gestión de este enjambre de información.

Continuará...

14

En nuestro medio el nombre de SAP suele ser sinónimo de un sistema de planeación

de recursos empresariales (ERP, por sus siglas en inglés). La enorme variedad de soluciones de

este fabricante lo han convertido en el corazón de la operación empresarial de casi tres cuartas partes de las

corporaciones más importantes del mundo, sobrepasando los 120 mil clientes. Derivado de lo anterior, la necesidad de llevar seguridad a todos los recursos de información de las organizaciones ha provocado que los esfuerzos para robustecer este conjunto de herramientas se hagan cada vez mayores. Por ejemplo, en el año 2002 se lanzó la solución GRC (Governance, risk and compliance) con el fin de brindar seguridad lógica al negocio y prevenir ataques desde el interior de la organización; en 2008 se dio otro salto importante con la auditoría de código a través de ABAP (Advanced business application programming) que previene la aparición de ataques desde las etapas de desarrollo.

En los últimos años las amenazas a nivel aplicativo se han multiplicado y SAP se ha mantenido muy involucrado para actuar en respuesta, sobre todo por la visibilidad que tiene al ser la herramienta base de la operación de muchas corporaciones. Así pues, los ataques que más se han dado sobre esta plataforma son los siguientes1:

1. Escalado de directorios (Directory Traversal).

2. Cross-Site Scripting / Modificación no autorizada de datos.

3. Falta de verificación de autenticaciones.

4. Divulgación de información.

5. Uso no autorizado de funcionalidades de la aplicación.

Existe un mito que establece que los ataques a los sistemas SAP solamente se podrían dar desde adentro de la organización, un aspecto nada despreciable si sabemos que 80% de los ataques cibernéticos a una empresa provienen de su interior. Sin embargo, mientras las organizaciones tengan algún tipo de conexión a Internet, siempre habrá forma de llegar a los servidores de SAP, incluso mediante el apoyo de buscadores Web o programas como Nmap. Como ejemplo, ponga la siguiente expresión en el buscador Google:

Inurl:/irj/portal

Y obtendrá acceso a diferentes organizaciones que tienen publicada su plataforma SAP. Si adicionamos a este escenario algo que se pudiera haber obtenido a través de ingeniería social, o si de casualidad el que está utilizando este comando es un exempleado cuyos permisos no han sido revocados, hay un muy alto nivel de probabilidad de que ocurra un incidente en una de las plataformas más críticas de la organización.

opinión

SAP: una plataforma altamente funcional y altamente

expuesta

CISSP, CISA, CEH, ITIL y CRISCesanroman@scitum.com.mx

Esteban San Román Canseco

152012

Enumero a continuación las diez principales vulnerabilidades en SAP detectadas durante los años 2011 y 2012, en orden ascendente de criticidad. Esta información ha sido presentada en conferencias de seguridad de la información como la de Kuwait en mayo de este año:

Denegación de servicios a través de scripts en la interfaz gráfica.

El manejo de scripts en la interfaz gráfica de SAP mejora las capacidades para ambientes Windows y Java, reduciendo, a través de la automatización, tareas repetitivas de los usuarios finales, tal cual lo hacemos con

las macros que existen en aplicaciones tan populares como Excel.

Desde el punto de vista de seguridad, el problema es que los scripts generados tendrán los mismos derechos del usuario que los ejecuta, además de que los mensajes de seguridad que se muestran al usuario se pueden apagar en el registro de la estación de trabajo. Así pues, es posible realizar un ataque DoS utilizando un script sencillo, lo que constituiría un sabotaje con un riesgo de negocio alto.

Denegación de servicios a través de paquetes mal formados de XML.

Con el fin de generar aplicaciones para los usuarios finales que utilicen ambiente Web en la intranet o Internet y acceder a datos de SAP, existe la interfaz de Gateway WebRFC como herramienta de desarrollo.

Las aplicaciones WebRFC permiten publicar reportes estándar de SAP en la Web y cualquier usuario puede tener acceso a estas aplicaciones.

NetWeaver, una aplicación orientada a servicio, es vulnerable a ataques de XML, haciendo posible la materialización de un ataque con scripts e

inclusive correr estos a través de Internet.

Este ataque se manifiesta como un sabotaje que constituye un riesgo crítico de negocio.

Inyección de scripts en BAPI (business application program interface) / Robo de Hash

Los BAPI son el estándar de comunicaciones para aplicaciones

de negocio. En un ambiente SAP, BAPI es la interfaz que da acceso a

procesos y datos en sistemas SAP y no-SAP invocados a través de aplicaciones

externas u otros programas.

En estas transacciones se presenta una falla al tratar de “sanitizar” la entrada de datos, lo que hace posible inyectar código Java

script o llevarlo a un servidor SMB falso. Los clientes de SAP utilizan sus accesos y estos van a dar al host del atacante.

Este tipo de ataques se presentan como espionaje, sabotaje o fraude que

representa un riesgo alto para el negocio.

10

9

8

16

Cifrado pobre de la interfaz gráfica de usuario (GUI) de SAP.

Todas las aplicaciones en un ambiente cliente-servidor tienen una interfaz hacia el usuario, el front-end, y una serie de recursos orquestados por un código que lo soporta, el back-end.

El front-end de SAP puede salvar las contraseñas cifradas en atajos que se guardan en un archivo con la extensión .sap; esa contraseña utiliza el algoritmo de XOR con una llave secreta que tiene el mismo valor para cada instalación de la interfaz gráfica de SAP. Con acceso a dicho archivo y las herramientas adecuadas, obtener la contraseña puede tomar menos de un segundo.

Un ataque al GUI puede traducirse en espionaje o fraude, lo que representa un riesgo alto para el negocio.

Escaneo remoto de puertos por medio de JSP (Java server pages).

La tecnología JSP le permite a los desarrolladores crear páginas Web dinámicas basadas en HTML, XML u otros documentos. La plataforma Java brinda la interfaz y el ambiente para desarrollar y correr software

incluyendo servicios Web y de red.

Las redes internas pueden ser escaneadas desde Internet porque no se requiere autenticación, y el motor de Java J2EE que utiliza SAP Netweaver es vulnerable.

Los ataques que se pueden dar como espionaje o sabotaje representan un riesgo medio para el negocio aunque la explotación de esta vulnerabilidad puede darse fácilmente.

Robo del identificador de la sesión de Java (JSESSIONID) de la consola de administración de Microsoft (MMC) de SAP.

En los ambientes de cómputo, el identificador de sesión es una porción de la información que se utiliza en comunicaciones a través de la red (típicamente HTTP) para llevar un recuento preciso de las sesiones que se van

abriendo para cada usuario.

La consola de administración permite el manejo remoto de la plataforma SAP pero, por omisión, muchos de los comandos se realizan sin autenticar y esto facilita la divulgación no autorizada de información.

En este ataque, los riesgos para el negocio son variables, siendo el espionaje el más crítico.

Ejecución remota de comandos en el módulo TH_GREP

En un sistema SAP existen módulos de función de manejo de tareas o TH (task handler) que se encargan de cargar o descargar los contextos de la sesión de usuario, al principio y al final de cada paso en la sesión.

El propósito del módulo de función TH_GREP es buscar una cadena en un conjunto de archivos de bitácoras de SAP llamando a la función grep del sistema operativo. En este módulo hay una falla que no ha sido adecuadamente parchada y que se puede saltar en el ambiente Windows.

Para este ataque los riesgos para el negocio son altos, especialmente el espionaje y el fraude.

5

4

7

6

172012

Desbordamiento del buffer (buffer overflow) en el kernel de ABAP

En seguridad informática un desbordamiento de buffer es un error de software que se produce cuando un programa no controla adecuadamente la cantidad de datos que se copian sobre un área de memoria reservada

a tal efecto (buffer), de forma que si dicha cantidad es superior a la capacidad preasignada los bytes sobrantes se almacenan en zonas de memoria adyacentes, sobrescribiendo su contenido original. Esto constituye una falla de programación.

Para SAP se presenta un desbordamiento de buffer en la función C_SAPGPARAM cuando el campo de nombre excede los 108 caracteres.

Los riesgos de negocios para este ataque son críticos a nivel espionaje, sabotaje y fraude.

Invocación de Servlet para saltarse el proceso de autenticación

Un Servlet es una clase del lenguaje de programación Java que se utiliza para extender las capacidades de un servidor; un Servlet puede ser llamado desde la aplicación, aun si no está declarado en web.xml.

El archivo web.xml contiene información sobre la aplicación Web que es utilizada por el contenedor del servidor de Java, para montar y ejecutar la aplicación.

Un ataque de este tipo es muy fácil de perpetrar y representa un alto riesgo para el negocio a nivel de espionaje, sabotaje o fraude.

Manipulación de verbos

La manipulación de verbos en HTTP (verb tampering) es un ataque que explota vulnerabilidades en los mecanismos de control de acceso y autenticación del verbo de HTTP (también conocido como método

HTTP). Muchos mecanismos de acceso solamente limitan el acceso a los métodos comunes de este protocolo, permitiendo acceso a recursos restringidos por otros métodos.

Sin necesidad de autenticarse, y de manera remota, se pueden realizar modificaciones de partes importantes de un script, por ejemplo usar HEAD en lugar de GET, o correr tareas de administración de la central de configuración técnica (CTC) como añadir usuarios, correr comandos del sistema o manipular el motor de J2EE.

Este ataque, aun con parches aplicados, puede ser exitoso con el uso de la invocación de un Servlet, provocando riesgos críticos al negocio por espionaje, sabotaje o fraude.

Conclusión

SAP es uno de los ambientes de desarrollo más usados y reconocidos en la industria por su poder, estabilidad y flexibilidad. Sin embargo esas mismas características lo hacen atractivo para los atacantes. Los sistemas SAP utilizan protocolos propietarios como RFC (remote function call) y DIAG (dynamic information and action gateway) que de manera nativa no cifran la información, pero existe un toolkit que puede manejar la comunicación entre servidores. Las versiones más recientes ya incorporan tecnología de manejo de identidades y accesos, además de bibliotecas criptográficas que se apoyan en protocolos SSL. Sugiero, a usted que utiliza esta solución, que:

» Mantenga una colaboración estrecha con el fabricante y sus proveedores, actualizando constantemente las versiones de los aplicativos y consultando la documentación que SAP libera acerca de su plataforma.

» Realice regularmente evaluaciones de seguridad, sobre todo de seguridad aplicativa.

» Incorpore esquemas de monitoreo de seguridad, en sitio o con el apoyo de un proveedor de servicios administrados.

» Realice revisiones de código (ABAP, NetWeaver, etcétera)

» De acuerdo a lo que exista en su organización, implante, verifique o asegure que el esquema de segregación de tareas se lleva a cabo adecuadamente.

A diferencia de aplicativos de propósito específico que son prácticamente propietarios, SAP está muy difundido y para él hay una gran cantidad de herramientas y vulnerabilidades conocidas. Una buena estrategia integral de seguridad ayudará a blindarlo.

1Si usted estimado lector, desea entender mejor la terminología que se utiliza en SAP, le recomiendo consultar la siguiente referencia:http://www.learnersparadise.com/courses/srini.m9/public/doc/SAP_Termiologies.pdfA

3

2

1

18

misión:crítica

Recuerde que la metodología propuesta por los Heat se basa en tres dimensiones o aristas:

1.Darle mensajes claros al jinete (el cerebro racional),

2.Motivar al elefante sobre el cual va el jinete (el cerebro emocional) y

3.Pavimentar el camino para que sea más fácil para el elefante y para el jinete tomar esa nueva dirección.

La vez anterior desglosé algunas técnicas para la primera dimensión y quedamos en concluir la segunda dimensión correspondiente a cómo modificar nuestros paradigmas.

Además de explicar esa técnica, revisaré también algunas formas de lograr la tercera dimensión (pavimentar el camino) y finalizaré compartiendo con

ustedes la estrategia de Chanchis.

Modificar nuestros paradigmas

Un paradigma es la forma en que vemos al mundo en relación a un tema en particular. Por ejemplo, cuando yo era adolescente practicaba Judo. Cuando me tocaba competir, trataba de concentrarme y hacer mi mejor esfuerzo, pero bastaba con que mi competidor tuviera ojos rasgados para que lo considerara mejor que yo, casi sin importar el color de su cinta. En pocas palabras, mi paradigma me decía “si tiene ojos rasgados, es japonés. El judo se inventó en Japón. Luego entonces él tiene un mejor nivel de judo que yo”. Así son nuestros paradigmas, son patrones mentales que tenemos, basados en la realidad o no, bajo los cuales percibimos el mundo y tomamos decisiones.

Parece que el origen de que nuestro cerebro funcione a través de patrones o paradigmas tiene que ver con la evolución, pues una vez obtenido un patrón mental son mucho más rápidas nuestras decisiones. Sin embargo, en el mundo moderno no siempre nuestros paradigmas juegan a nuestro favor.

Los hermanos Heat enfocan el tema de los paradigmas tomando como base el trabajo de la Dra. Carol S. Dweck, investigadora de la Universidad de Stanford, sobre la forma en que las personas perciben el resultado de sus acciones: por sus talentos innatos o por el esfuerzo que han puesto en lograr una habilidad.

La Dra. Dweck investigó las dos actitudes principales con las que los niños manejan el fracaso, como puede ser reprobar un examen: por un lado, hay niños que se frustran sintiéndose poco valiosos (“no soy bueno para matemáticas”) o le echan la culpa a otros factores (“el maestro no me quiere”, “ese día estaba distraído”, etcétera), mientras que, por otro lado, hay niños que toman una actitud muy positiva: “necesito estudiar más” o “voy a practicar más para volverlo a intentar”. A esas dos posturas mentales les llamo mentalidades (mindset en inglés), y denominaré a la primera como mentalidad fija (fixed mindset) y a otra la nombraré la mentalidad de crecimiento (growth mindset).

En la primera parte de este artículo expuse el caso de Chanchis, responsable de seguridad en Acme S.A., quién comenta con Cuco, un buen amigo suyo, sus frustraciones por no encontrar “eco” en sus esfuerzos por mejorar la seguridad de la información de la empresa. Cuco, basado en el libro “Switch: How to Change Things When Change Is Hard” de los hermanos Heat, le comparte varios conceptos sobre cómo hacer posibles cambios importantes.

MSIA, CISSP, CISM y CISAucastillo@scitum.com.mx

Ulises Castillo Hernández

La seguridad y nuestros elefantes(segunda parte)

192012

misión:crítica

Las personas que tienen una mentalidad fija:

» Creen que la inteligencia o las habilidades se deben a la genética, “Pepe tiene una habilidad innata para las matemáticas”, y –por tanto- piensan que esas habilidades son fijas y la gente que las posee no tiene que esforzarse.

» No aceptan fácilmente la retroalimentación.

» Les cuesta mucho aceptar el fracaso y no son tan abiertos al aprendizaje, o, al menos, no lo asocian con el fracaso.

En cambio, las personas con mentalidad de crecimiento:

» Creen que las habilidades son, fundamentalmente, el resultado del esfuerzo. “Gigi es buena para la música pues

ha practicado duro desde los cinco años”.

» Aceptan la retroalimentación.

» Consideran el fracaso como parte del aprendizaje.

Cuando Cuco le compartió estas ideas a Chanchis, ella lo miró con cara de interrogación y le comentó “Lo que dices suena muy interesante y lo puedo aplicar a mi vida personal pero, ¿qué relación tiene con mi reto de seguridad?”

Cuco le preguntó “¿Los altos ejecutivos de tu empresa entienden la seguridad como un esfuerzo permanente y como un camino en el que se aprende día a día y, por tanto, existen errores, o –más bien- creen que la seguridad es cuestión de invertir y responsabilidad solamente tuya?

Cuco le sugirió un par de ideas:

» Los líderes con mentalidad fija no aceptan los errores como parte del aprendizaje, pero en seguridad informática cada día aparecen nuevas amenazas. Hay que hacer cambios y correcciones sobre lo que tenemos: reconfigurar algún dispositivo de seguridad, implementar o reforzar una política, o definir un nuevo control. Entonces hay una enorme ventaja en el enfoque de los proyectos de seguridad cuando existe una mentalidad de crecimiento.

» Los resultados son producto del esfuerzo. Las empresas que tienen mejores niveles de seguridad son las que han sumado mejor los esfuerzos de todos, no necesariamente las que han invertido más dinero.

Además, Cuco agregó “¿Piensas que tus usuarios son muy necios y no entienden la importancia de la seguridad?” Cuando Chanchis respondió afirmativamente Cuco comentó “Creo que estás actuando con una mentalidad fija hacia ellos. No es que sean necios, aunque su actitud puede no ser la adecuada frente a la seguridad. Trata de ver qué tienes que hacer para mover sus modelos mentales o paradigmas, y que perciban la seguridad como una necesidad de la empresa y una ventaja para ellos. Si te sientes frustrada, entonces dejas de aprender, ya no intentas entender qué te hace falta y le echas la culpa a los usuarios”.

Cuco, sin quererlo, le acababa de dar a su amiga una de las mayores lecciones de su vida.

La seguridad y nuestros elefantes(segunda parte)

20

misión:críticaTécnicas para pavimentar el camino

Hemos visto cómo dirigirnos al cerebro racional (el jinete) a través de lineamientos claros, y cómo motivar al cerebro emocional (el elefante) provocando sentimientos, como la identidad, o moviendo creencias (el mindset). El tercer elemento en la metodología propuesta por los hermanos Heat es pavimentar el camino, en otras palabras, hacer el cambio más fácil para las personas involucradas. Para ello, los autores nos proponen tres estrategias principales.

a. Modificar el medio ambiente.

En el libro se comentan ejemplos en los que se alteró uno o más elementos del medio ambiente. Tal es el caso de un ejecutivo que tenía la mala, malísima, diría yo, costumbre de contestar sus correos en la computadora mientras hablaba con sus empleados. Cuando se dio cuenta, hizo un cambio muy simple en el ambiente: colocó la computadora a un lado del escritorio (en vez de enfrente de él) de manera que ya le resultaba muy incómodo estar contestando correos mientras hablaba con la gente. Asunto arreglado.

Hablando de mejorar la seguridad informática y dado que la técnica no se basa en atacar el problema en sí ¿Podríamos lograrlo haciendo más efectiva la seguridad física? Pues se ha visto que el reforzar la seguridad física tiene resultados muy visibles a corto plazo y ayuda a que los empleados tomen mayor conciencia sobre la necesidad de implementar diversos tipos de controles.

O bien, ¿Podríamos lograr que las computadoras nuevas que se asignan a los usuarios ya vengan preconfiguradas con antivirus y con la política de cambio de contraseña cada tres meses? Así, el usuario no tendría que acordarse de mandarle instalar el antivirus y, de forma automática, el sistema operativo le recordaría cambiar la contraseña del equipo.

212012

misión:crítica

b. Crear hábitos.

Una de las formas más efectivas de generar un cambio es crear hábitos. Los científicos han descubierto que el cerebro invierte mucho en tomar decisiones y, por tanto, de una forma u otra evadimos esta tarea. Un hábito nos evita tomar decisiones pues hacemos de manera automática lo que el hábito nos manda, sea bueno o malo,

Los autores del multicitado libro proponen una técnica de “disparadores” mentales muy eficiente para crear hábitos (la palabra inglesa que usan es triggers). La idea es que ante un escenario futuro nos imaginemos a nosotros mismos tomando la acción apropiada.

El requisito es que la situación sea relevante y que estemos convencidos de que queremos tomar esa acción apropiada. De esta forma, cuando tal evento se presenta, nuestro cerebro ha creado el hábito de tomar dicha acción, y lo más probable es que sea la que realicemos.

Un ejemplo: para que los alumnos de un profesor universitario tuvieran una mejor calificación, tenían la opción de entregar un breve escrito de cómo fue su reunión familiar de Navidad. El reto verdadero era que lo tenían que entregar un día después de la Navidad, cuando el tiempo que deberían dedicar a esta tarea competiría con la desvelada del día anterior y los momentos de diversión familiar. Solo una tercera parte de los estudiantes lograba cumplir con la tarea, y eran aquellos que, previamente, habían visualizado el momento y el ambiente en donde desarrollarían su escrito. En otras palabras, la decisión difícil de en qué momento y lugar harían la tarea, la habían tomado desde días antes a través de este ejercicio mental, y era lo que terminaban haciendo; los demás no lograron tomar la decisión de crear ese ambiente.

Algunos ejemplos de buenos hábitos en seguridad informática podrían ser: que los usuarios tengan presente la seguridad cuando están abriendo sus correos. Que cambien sus contraseñas de forma periódica, y que dichas contraseñas sean robustas. Y que todos los usuarios hablen al área de seguridad cuando se topen con algún incidente o situación sospechosa (un correo “raro” o una persona que está haciendo mal uso de la información, incluyendo navegar a sitios no autorizados). Con la técnica de los disparadores mentales, ¿se le ocurre cómo podríamos ir creando esos hábitos en nuestros usuarios? En la última sección del artículo, veremos que Chanchis utilizará –entre otras- esta técnica.

22

misión:crítica

c. Guíar a la manada.

Aunque el título de esta técnica puede parecer agresivo, recuerde que los elefantes son nuestros cerebros emocionales por lo que esta técnica se enfoca a invocar nuestro instinto gregario y hacer que todo mundo se comporte de cierta forma.

En muchas situaciones de nuestra vida personal o laboral verificamos qué están haciendo los demás y hacemos lo mismo. Esa es la razón por la que muchos mexicanos no tiramos basura ni violamos las señales de tránsito cuando cruzamos la frontera hacia Estados Unidos, a pesar de que sí lo hacemos en nuestro país.

Una técnica en esta categoría es informar a “la manada” sobre alguien que esté haciendo lo adecuado. Por ejemplo, un coordinador financiero estaba cansado de que muchas áreas no enviaran sus reportes mensuales a tiempo, hasta que decidió hacer dos cosas: (1) Informar a todas las áreas acerca del porcentaje de cumplimiento, para lo cual empezó a enviar mensualmente un mensaje que decía así: “El 78% de las áreas cumplen a tiempo. Esperamos que tú también lo puedas lograr”; y (2) hablar personalmente con las áreas que se retrasaban, mostrarles los resultados de las que cumplían, y preguntarles qué necesitaban para comprometerse con una fecha. Con estas dos medidas logró prácticamente 100% de los reportes a tiempo.

En el caso de su empresa, imagínese que tiene implementado un servicio de filtrado de contenido Web, y cada mes envía a los gerentes y directivos de cada área un reporte como el siguiente:

REPORTE DE CUMPLIMIENTO DE LA POLÍTICA DE NAVEGACIÓN WEB

Área Número de usuarios en cumplimiento Porcentaje

Finanzas 18 85%

Sistemas 6 55%

Operaciones 67 94%

¿Cree que el reporte anterior ayudaría a que se creara una sana competencia entre áreas relacionada a cuál de ellas logra primero un cumplimiento del 100%?

232012

misión:crítica

Conclusión: la estrategia de Chanchis

Después de la plática con Cuco, Chanchis quedó muy pensativa y bastante motivada, sobre todo por contar con técnicas específicas para actuar. Al cabo de pocas semanas había logrado, por fin, que los altos ejecutivos de la empresa apoyaran los esfuerzos de seguridad y además había empezado a convencer a los usuarios de la importancia de dichos esfuerzos y de la necesidad del apoyo colectivo.

La tabla siguiente muestra, de forma resumida, las acciones que tomó Chanchis en esas primeras semanas.

Reto o problemática Acciones implementadas Comentarios

Convencer a los ejecutivos de la necesidad de invertir en la administración de los riesgos de la información.

Chanchis consiguió darles una presentación de 30 minutos a los directivos. Después de algunas cifras y datos relevantes, les planteó un par de escenarios de riesgo específicos con los cuales la audiencia quedó muy impresionada y todos pensaron: “Hasta ahora entendemos lo que puede suceder y el impacto que tendría en la empresa”

[Motivar al elefante: encuentre el sentimiento]

Los altos ejecutivos “sintieron” el impacto de no tener una protección adecuada para su información, y les movió la identidad: “Por Dios, es la información de la empresa y de nuestros clientes ¡No podemos quedarnos con los brazos cruzados!”

Los altos ejecutivos no saben cómo atacar el problema ni tienen claridad respecto al rol que ellos mismos deben desempeñar.

En la misma presentación, Chanchis les explicó los principales escenarios de solución, haciendo explícito el apoyo que requeriría de cada persona y departamento para hacer posibles los cambios.

[Instrucciones al jinete, apuntar al destino]

Los directivos entendieron todo lo que se podría lograr, para cuándo, y cuál sería el precio, no solo en dinero sino en compromiso de cada quién.

Los ejecutivos son escépticos respecto a poder realmente lograr algo importante respecto a la seguridad.

Para cada escenario mencionó algunas historias de éxito (emular a los puntos brillantes) o expuso un posible mapa de ruta (road-map) para llegar al resultado.

[Apuntar al destino]

El escepticismo de la alta dirección cambió bastante cuando conocieron las historias de éxito y la forma en que podrían “aterrizar” esa experiencia dentro de Acme.

Los ejecutivos no están dispuestos a tener errores en los proyectos e ir aprendiendo sobre la marcha (mentalidad fija).

Para finalizar la presentación Chanchis explicó a los ejecutivos, en forma breve y elocuente, los dos tipos de mentalidad que existen y los convenció para que arrancara la estrategia de seguridad.

[Motivar al elefante. Mover los paradigmas]

Los ejecutivos se convencieron de iniciar la estrategia de seguridad cuando entendieron que, a pesar de la buena planeación y cuidado que se tengan, todo proyecto puede tener errores, y que la empresa debería APRENDER de dichos errores e ir corrigiéndolos.

24

misión:críticaReto o problemática Acciones implementadas Comentarios

Los usuarios no están interesados en la seguridad informática.

Chanchis hizo cambios importantes al programa de concientización: grabó al Director General comunicando a toda la empresa la importancia de la seguridad …

[Pavimentar el camino: cambio en el ambiente]

… y dentro de los talleres, los usuarios ahora “viven” algunos escenarios de riesgo.

[Motivar al elefante: encuentre el sentimiento]

Al ver al director en los videos, los empleados concedieron importancia a los esfuerzos de seguridad.

Adicionalmente, a través de los ejercicios prácticos se están dando cuenta de lo que significa para la empresa, para los clientes, y para ellos mismos, no contar con seguridad.

Los usuarios no tienen buenos hábitos de seguridad (por ejemplo, dejan sus PC sin protección mientras se van a comer).

En el mismo taller de concientización, empezó a formar un par de hábitos con la técnica de disparadores mentales.

[Pavimentar el camino: formar hábitos]

Los dos hábitos con los que ha iniciado Chanchis son:

a) Poner un protector de pantalla cuando se abandone el puesto de trabajo y

b) cambiar contraseñas cada tres meses. Al finalizar el taller, el participante hace una autoevaluación de qué tanto considera que ha internalizado los hábitos.

No todos los usuarios se apegan a las políticas de seguridad.

Chanchis también contrató un servicio de filtrado de contenido Web. Premió simbólicamente a las áreas cuyos usuarios cumplían con la política de navegación Web y lo difundió a toda la empresa.

[Pavimentar el camino: guiar a la manada]

Como era de esperarse, en cuanto se conocieron las cifras de cumplimiento, la mayoría de las personas han estado cambiando comportamientos y “contagiándose” positivamente unos a otros.

Con la sinergia lograda en estos primeros meses, Chanchis está muy motivada y su credibilidad interna ha mejorado notablemente. La estrategia

de seguridad es –hoy por hoy- todo un éxito.

Aunque el caso de Chanchis es imaginario, creo que ilustra de forma muy concreta algunas maneras en que las técnicas que se explican en el libro “Switch…” se pueden aplicar a los retos de la seguridad informática, sobre todo para venderle a ejecutivos y usuarios la importancia de ésta para la empresa y –como dice el título del artículo- tomar en cuenta a nuestros elefantitos.

Mucha suerte y ojalá que le sirvan las técnicas expuestas en esta serie de dos artículos. Hasta la próxima.

continúa de la página 23

26

c ·o ·n ·e ·x · i ·o ·n ·e · s

Departamento de Defensa

David Gutiérrez JiménezCISSP y CISA

dagutierrez@scitum.com.mx

La cédula de identidad personal, un reto magnífico para el gobierno

Según mi perspectiva, una cédula de identidad cuyo propósito sea única y específicamente establecer la identidad de un individuo, era una cuestión impostergable en México por varios factores sociales y de seguridad pública.

Es necesario admitir que la credencial para votar emitida por el Instituto Federal Electoral (autoridad en materia electoral federal dentro de México) sirvió bastante bien para el propósito y por mucho tiempo, pero los tiempos han cambiado y factores como la evidente falla, desde el punto de vista de manejo de identidades, de que los menores de 18 años no pueden contar con una, la han dejado obsoleta para las necesidades de identificación actuales.

En otros países el debate ha sido constante entre las personas que están a favor de la emisión de una tarjeta nacional de identificación y las que consideran que los beneficios no justifican el costo, monetario y en términos de privacidad, de su implementación. Ambos bandos tienen puntos interesantes y bastante sólidos para respaldar sus posturas. En México no ha habido una iniciativa formal para recoger

y contrastar las opiniones de la ciudadanía, por lo que sería muy aventurado decir si la mayoría apoya o rechaza esta medida.

El gobierno federal de México ha tomado la decisión de implementar, a partir del año 2012, la emisión de tarjetas de identidad ciudadana para menores entre 4 y 18 años de edad, la cual no tiene carácter de obligatoria. Al momento de la publicación de este número, decenas de miles de niños ya habrán pasado por el trámite e inclusive ya contarán con su cédula de identidad personal.

Haciendo momentáneamente a un lado el debate de factores sociales y económicos, es absolutamente necesario entrar en la discusión seria de las medidas de protección a la información colectada en el

proceso de enrolamiento y aquella que se queda impresa en la tarjeta.

De acuerdo con la página de preguntas frecuentes sobre la cédula de identidad personal1, los datos recolectados se almacenarán de forma centralizada en una base de datos del Registro Nacional de Población (RENAPO),

llamada Servicio Nacional de Identificación Personal (SNIP). Según la información dentro de la propia página de preguntas frecuentes, la base de datos del SNIP cuenta con las más altas medidas de seguridad “que la hacen inviolable”.

Estoy seguro de que se tomaron muchas medidas de seguridad para proteger los datos, pero me gustaría que se profundizara en este tema; y no en el sentido de exponer públicamente cuáles fueron los controles

que se implementaron, pero sí me parece importante que se conduzca (si es que no se ha realizado, y no hay información oficial sobre este hecho en particular) una revisión por alguna entidad independiente

reconocida como autoridad en la materia, en el mismo esquema que la UNAM auditó el código de sistema de resultados electorales preliminares (PREP).

Los datos que contiene la cédula de identidad son2:

1. Nombre completo del menor.

2. CURP.

3. Nombre completo de los padres o tutores.

4. Fecha de nacimiento.

5. Vigencia.

6. Fotografía.

7. Registro del iris de un ojo.

8. Número único de cédula de identidad.

26

272012

No es claro si todos los datos que se contienen en la cédula van a parar a la base de datos del SNIP, lo cual también estimo relevante proporcionar dentro de la información oficial, ya que el manejo de datos biométricos debe tener un cuidado muy especial por el hecho de que las características físicas, en este caso el iris, son prácticamente imposibles de cambiar, a diferencia de, por ejemplo, una contraseña. Para el caso de la información impresa en la tarjeta física, se incluirán dos códigos de barras que contienen la información del iris. Uno solo puede esperar que esta información impresa en código de barras sea una suerte de hash3 y no los datos del iris como tales (no se aclara el tema en la página de preguntas frecuentes), ya que en este último caso, cualquiera que tuviera un lector de barras podría robarse los datos biométricos y guardarlos para buscar la manera de falsificar una lectura.

En Holanda, los datos del iris no se almacenan en una base de datos centralizada y los lectores biométricos que se usan para validar la identidad tampoco guardan tales datos, sino que únicamente comparan la lectura con la información biométrica impresa en la tarjeta4, lo cual brinda un nivel aceptable de protección sin perder la funcionalidad de identificación requerida.

Como un control adicional y muy necesario, el IFAI necesita tomar un rol activo en la revisión y sanción del cumplimiento de la legislación aplicable al RENAPO y al SNIP, apoyado en sus facultades como garante de la protección de datos personales, de forma que los ciudadanos tengamos una entidad sólida que cuide nuestros intereses en términos del manejo de este tipo de información.

El estado mexicano está a muy buen tiempo para revisar, y corregir si es necesario, los controles de seguridad que habiliten la correcta implementación de esta iniciativa tan importante para el país.

1http://www.renapo.gob.mx/swb/swb/RENAPO/FaqCEDI#faq272http://www.renapo.gob.mx/swb/swb/RENAPO/FaqCEDI#faq273http://es.wikipedia.org/wiki/Funci%C3%B3n_Hash4http://tcf.org/publications/pdfs/pb284/National_ID_Card.pdf

28

c ·o ·n ·e ·x · i ·o ·n ·e · s

En el pensar de...

Eduardo P. Sánchez DíazCISSP, CISM, GCIH, GWAPT,

CEH y CHFIepsanchez@scitum.com.mx

Programas de concientización

En las últimas semanas he tenido la oportunidad de compartir con varios colegas del ámbito de la seguridad de la información, diversos puntos de vista respecto a los programas de concientización (awareness). Este intercambio de ideas surgió por dos artículos de personas muy respetadas en temas de seguridad.

El primero es de Richard Bejtlich1 y la idea principal con la que me quedo es “Los programas de concientización no eliminan las vulnerabilidades humanas, ya que existen muchos riesgos los cuales no pueden ser tratados mediante entrenamiento”. También existe una segunda idea: “Los profesionales de seguridad confundimos programa de concientización con educación”.

El segundo artículo es de Dave Aitel2, en el cual la idea principal es “No malgastes tu dinero en programas de concientización, debes prepararte mejor pensando en que siempre un usuario dará clic en ese archivo malicioso”, y la segunda idea, que sustenta a la anterior, es que “Los ataques hoy son sofisticados y no podemos esperar que nuestros usuarios puedan detectarlos, esto es responsabilidad del área de seguridad que debe garantizar un espacio de seguridad”.

Si nos quedáramos con estas visiones tanto de Richard como de Dave podríamos llegar a pensar que un programa de concientización no sirve más que para pasar una auditoría. En lo personal comparto casi en su totalidad la visión de ambos y me gustaría exponer lo que pienso:

Muchos especialistas ven la seguridad en tres grandes niveles que trabajan en conjunto:

Gente

Procesos Tecnología

292012

Sin embargo no sé por qué en el rubro de gente se llega a pensar que se encuentran todas las personas de una organización, y es aquí donde detecto uno de los primeros problemas. Es cierto que las organizaciones cuentan con controles basados en tecnología, los cuales son operados por personas mediante una serie de procesos y procedimientos, ¿pero qué pasa con aquellas personas que no tienen injerencia en la operación directa de esta tecnología? Por ejemplo, los usuarios de una red de servicio o la alta gerencia de una organización.

¿Qué pasa si Pepito trabaja en Contabilidad y recibe un correo electrónico de su jefe inmediato, que contiene un archivo y le pide que lo abra para validar unas cifras? Como cualquier otro empleado Pepito hace su trabajo y abre el archivo el cual, en realidad, no fue enviado por su jefe y además contiene incrustado código malicioso que permite que un atacante externo tome control de su equipo de cómputo.

Vienen a mi mente un par de preguntas: ¿Pepito es culpable de abrir el archivo? ¿Por qué Pepito recibió el archivo? De acuerdo con mi experiencia, la mayoría de las organizaciones podrían culpar a Pepito por este descuido, y peor aún cuando hace menos de un mes recibió su capacitación de concientización en temas de seguridad. Yo no podría culpar a Pepito y buscaría entender cómo es posible que mi área de seguridad permita que la organización no esté libre de este tipo de problemas y por qué no ha probado que nuestros controles funcionen correctamente.

Siguiendo con el ejemplo, supongamos que el área de seguridad sí logro detectar que la máquina de Pepito fue comprometida. Pepito es llamado a Recursos Humanos y se le indica que se le está investigando, ya que una acción suya hizo que información sensible

quedara expuesta. A partir de entonces Pepito decide que antes de abrir cualquier otro archivo adjunto primero validará su procedencia. Aparentemente ya mejoramos la seguridad, pero es muy probable que al pasar las semanas Pepito vuelva a confiar en los archivos anexos pues la naturaleza del ser humano es relajarse cuando no está en crisis. Lo que convertirá a Pepito en un eslabón débil para la organización en temas de seguridad.

¿Qué podemos aprender de este ejemplo hipotético? El programa de concientización no sirvió, sin embargo después de que el usuario fue expuesto a un incidente de seguridad donde incluso su trabajo estuvo en riesgo, dicho usuario estuvo más consciente de la problemática de seguridad de la información en correo electrónico, pero solo por un tiempo.

Más de una vez me ha tocado validar en diversas organizaciones que sus programas de concientización sean útiles y hoy les puedo decir que los usuarios siguen dando información confidencial por teléfono, siguen dejando pasar personas a sus lugares de trabajo, e incluso siguen dando clic a los archivos adjuntos que se les envían. También he participado en la respuesta a incidentes de seguridad donde, al finalizar el proceso, los usuarios involucrados tienen más conciencia de su entorno y de los riesgos informáticos a los cuales están expuestos.

30

c ·o ·n ·e ·x · i ·o ·n ·e · s

¿Sabías que

es el únicoCentro de Entrenamientoautorizado en México?

Por lo que ahora puedes:

1.- Tomar el Seminario Oficial de CISSP de (ISC)2 del 8 al 12 de abril del 2013 en Scitum, a un precio de $1,650.00 Dlls. más IVA.

2.- Presentar el examen de certificación con costo de $599.00 Dlls. a través de uno de los centros autorizados.

La sede del seminario es:Torre Telmex, Oficinas de Scitum, Cd. de México.

Av. Insurgentes Sur No. 3500, colonia Peña Pobre, C.P. 14060, delegación Tlalpan.

Más informes, comuníquense al 9150.7496, lunes a viernes de 9:00 a 18:00 hrs. o bien al correo electrónico: capacitacion-isc2@scitum.com.mx

La fecha límite de inscripciones es el 20 de marzo de 2013.

C

M

Y

CM

MY

CY

CMY

K

Seminarios_ISC2_.pdf 1 12/13/12 6:03 PM

Con esto no quiero decir, aunque me gustaría, que los mejores proyectos de concientización incluyen someter a los usuarios a incidentes de seguridad reales y estresantes, pero tampoco significa que los planes de concientización funcionan y cumplen sus objetivos al 100%.

Si alguien me preguntara ¿Recomiendas un plan de concientización?, yo comentaría los siguientes puntos:

» Si tienes que cumplir con alguna auditoría interna y te lo exigen, hazlo pero no esperes un cambio radical.

» No diseñes un plan de concientización general para toda la organización, tiene que estar enfocado a la cultura de cada área y sus responsabilidades. Me ha tocado ver muchas veces que cuando capacitan al personal de vigilancia en estos temas, son más conscientes de los riesgos que un usuario normal o incluso que algunos directivos.

» Fortalece tus esquemas de seguridad primero, crea redes de servicios seguras para tus usuarios, prepárate pensando en que los usuarios siempre van a fallar; esto te mantendrá más alerta.

» No hay que confundir concientizar con educar y siempre hay que probar nuevos métodos (por ejemplo los expuestos por Ulises Catillo3 en un artículo del número anterior de Magazcitum).

Sé que este tema es ríspido y algunos podrán no estar de acuerdo, sin embargo, siempre hay que contemplar las diversas aristas para encontrar otros vértices que pueden ser más eficaces.

1BEJTLICH Ricard, The Importance of Security Awareness, Mandiant. Octubre 18 de 2012, https://blog.mandiant.com/archives/3592

2AITEL Dave, Why you shouldn't train employees for security awareness, CSO online. Julio 18 de 2012, http://www.csoonline.com/article/711412/why-you-shouldn-t-train-employees-for-security-awareness

3CASTILLO Ulises, La seguridad y nuestros elefantes. Septiembre 29 de 2012, http://www.magazcitum.com.mx/?p=1858

«Los programas de concientización no eliminan las vulnerabilidades humanas, ya que existen muchos riesgos los cuales no pueden ser tratados mediante entrenamiento»

¿Sabías que

es el únicoCentro de Entrenamientoautorizado en México?

Por lo que ahora puedes:

1.- Tomar el Seminario Oficial de CISSP de (ISC)2 del 8 al 12 de abril del 2013 en Scitum, a un precio de $1,650.00 Dlls. más IVA.

2.- Presentar el examen de certificación con costo de $599.00 Dlls. a través de uno de los centros autorizados.

La sede del seminario es:Torre Telmex, Oficinas de Scitum, Cd. de México.

Av. Insurgentes Sur No. 3500, colonia Peña Pobre, C.P. 14060, delegación Tlalpan.

Más informes, comuníquense al 9150.7496, lunes a viernes de 9:00 a 18:00 hrs. o bien al correo electrónico: capacitacion-isc2@scitum.com.mx

La fecha límite de inscripciones es el 20 de marzo de 2013.

C

M

Y

CM

MY

CY

CMY

K

Seminarios_ISC2_.pdf 1 12/13/12 6:03 PM

32

Mejora continua: camino al éxito

opinión

MCP, MCSE: Security, RUP e ITILv3: OSAdcadena@scitum.com.mx

En realidad poco tiempo ha pasado desde la generación de métodos y modelos para la gestión de TI ya sea a través de marcos de referencia, marcos normativos y de medición; hoy en día no solo basta con el cumplimiento de objetivos y metas, sino que

se busca la proactividad y la optimización de los servicios brindados a través de técnicas que permitan perfeccionar la entrega de resultados y competir en el mercado con niveles de servicio más agresivos y tiempos de respuesta menos holgados, y lo anterior bajo la premisa de asegurar, garantizar y mantener su calidad.

Todos buscamos el progreso o incremento de eficiencia en nuestra área u organización a través de una administración controlada de servicios, consistente y con el menor riesgo posible en su ejecución. Esto puede ser alcanzable siempre y cuando tomemos en cuenta que los servicios cambian constantemente, tanto por cuestiones tecnológicas como por la gente alrededor de ellos: las actividades varían y damos la bienvenida a métodos más prácticos para responder lo antes posible con el menor impacto posible, por lo tanto la mejora continua es un sinónimo de cambio y optimización.

Existen muchos criterios y definiciones de mejora, sin embargo todos nos conducen al mismo fin: el éxito. Si bien existe una cantidad innumerable de objetivos para cumplir este ideal llamado éxito, es importante identificar qué rubros en particular son valiosos y requeridos para lograr dicho propósito en el área u organización.

Partiendo de la administración de procesos para la gestión de TI a través del cumplimiento de metodologías y mejores prácticas como ITIL, Cobit, ISO o CERT, la mejora continua se obtiene a partir de una mejora permanente que considera que:

» Existe una clara definición de métricas de negocio orientadas a la generación de requerimientos que redunden en la mejora de los procesos y procedimientos.

» Las métricas de calidad evolucionan en términos de productividad y beneficios a la organización.

» El dueño del proceso y el equipo responsable de su ejecución se encuentran directamente involucrados en la optimización.

Diana Cadena Martínez

332012

El resultado de lo anterior se mide a través de la obtención del nivel de madurez de los procesos, en términos de su cumplimiento y la interacción entre todos los roles involucrados, así como del resultado de los indicadores de desempeño, puntos de control y factores críticos de éxito. ITIL cuenta con herramientas muy útiles para detectar en qué estado se encuentra una organización o área de TI a través de evaluaciones predefinidas con base en una serie de criterios puntuales y particulares de cada proceso.

La metodología de procesos en la organización debe estar sujeta a la adecuación y actualización acorde a la demanda del negocio; estos controles deben estar bien definidos por medio de un control de versiones y el resguardo centralizado de esta información, lo que conforma un ciclo de metas y objetivos orientados al beneficio común, por lo tanto, la mejora continua es alcanzable pero nunca termina. Por ello esta metodología debe estar alineada a los servicios de la organización y su mantenimiento de acuerdo a las mejores prácticas, y debe estar asignada a personas dedicadas a esta función para evitar ser juez y parte en la auditoría de resultados. Por ejemplo: el escenario en el que el mismo administrador de redes valida y aprueba sus propios cambios en la infraestructura no es la mejor opción pues, a pesar de que fuese una mente maestra, se pierde la preservación de la imparcialidad y objetividad en la gestión del proceso.

No es fácil lograr la mejora continua, pero tampoco es imposible. Primero se debe identificar en dónde estamos (punto de partida) y hacia donde queremos llegar, estableciendo metas reales a corto, mediano y largo plazo, definiendo claramente a los responsables de cada tarea.

No dude en pedir ayuda, hay empresas especializadas en la implantación y transferencia metodológica de procesos y procedimientos creados a partir de las mejores prácticas de gestión de la información, que facilitarán sustancialmente la generación de los resultados que tanto espera.

“La mejora continua es un CICLO constante, nunca termina”

34

Modelo de referencia de procesos en Cobit 5

CISA, ITIL y MCPricardo.diaz@scitum.com.mx

opinión

En el artículo anterior mencioné los cambios más representativos de la nueva versión de Cobit y ahora me concentraré en el modelo de referencia de procesos que propone para el gobierno empresarial de TI, el cual puede consultarse

en un producto de la familia de documentos de Cobit titulado “Enabling Processes”, que forma parte de las guías habilitadoras.

Como parte del esfuerzo de posicionar a Cobit como el marco de referencia preferido, en su diseño se toman conceptos de:

» COSO.

» ISO 9001.

» ISO 20000.

» ISO 27001.

» ISO 27002.

» ISO 31000.

» ISO 38500.

» King III.

» Los principios de gobierno corporativo de la OECD.

» The Open Group Architecture Forum TOGAF 9.

» ITIL v3 2011.

» Skills Framework for the Information Age SFIA.

» PMBOK.

» PRINCE2.

» La guía NIST SP800-53 Rev. 1.

Lo que conocíamos como objetivos de control de alto nivel ahora se llaman “procesos” y los objetivos de control detallados ahora son identificados como “prácticas”, ya sea de gobierno o de administración, dependiendo del dominio que, como mencioné antes, son cinco para esta nueva versión: el primero corresponde a gobierno y los siguientes cuatro a administración.

Es importante resaltar que ahora para cada “práctica” se detallan las entradas y salidas, que son los productos de trabajo que toman de otras prácticas, y los entregables que produce o genera dicha práctica, que van hacia otras prácticas de otros procesos respectivamente. En la versión anterior de COBIT solo se definían las entradas y salidas por proceso, lo cual ahora proporciona un desarrollo más detallado de las actividades que se tienen que realizar y sus correspondientes productos a generar.

En esta versión de Cobit los consultores y auditores de sistemas vamos a utilizar mucho el modelo de referencia de procesos pues en él se encuentran explicados con detalle los 37 procesos, con un apartado que describe lo siguiente para cada proceso: identificación, descripción, declaración de propósito, cascada de metas, metas y métricas, matriz RACI, actividades, prácticas, guía relacionada, entradas y salidas.

Ricardo Javier Ramírez Díaz

352012

» Identificación del proceso: que se forma a partir del prefijo del dominio (EDM = evaluate direct and monitor; APO = align, plan and organize; BAI = build, acquire and implement; DSS = deliver, service and support o MEA = monitor, evaluate and assess, y el número de proceso. Así pues, por ejemplo, el segundo proceso del dominio EDM se identifica como “EDM02 – ensure benefits delivery”.

También se incluye una breve descripción del proceso, indicando el tema principal del proceso y el área del proceso, ya sea gobierno o administración.

» Descripción del proceso: visión general de qué es lo que hace el proceso y cómo logra su propósito.

» Declaración de propósito del proceso: contiene la descripción del objetivo principal a alcanzar por el proceso

» Cascada de metas: indica cuáles de las 17 metas relacionadas con la tecnología de información dan soporte o apoyo a este proceso. Cabe señalar que en la versión anterior el número de metas de TI eran 28, por lo cual podemos deducir que se seleccionaron las más representativas. También se listan las métricas que se pueden utilizar para medir el logro de los objetivos relacionados con la tecnología de la información, recordando que solo son sugerencias y no debemos tomarlo como algo obligatorio.

» Metas y métricas del proceso: en esta sección se presenta un conjunto de objetivos de proceso, que dicho sea de paso se seleccionan de los 17 objetivos con que cuenta esta versión de COBIT. Adicionalmente se lista un número reducido de métricas para cada objetivo de gobierno.

No debemos confundir las metas del proceso y las metas de las tecnologías de información, ya que debido a que son el mismo número, puede hacernos dudar.

» Matriz RACI: una de las herramientas que más nos ayudan para definir responsabilidades en la estructura organizacional de las empresas es lo que corresponde a la matriz RACI, que en esta versión cuenta con 26 diferentes roles o estructuras (la versión anterior de COBIT solo proponía 11). Para cada práctica de gobierno o administración, se define quiénes pueden ser los responsables de ejecutar las prácticas, quién es el responsable final o auditable, a quién se le debe consultar y, por último, a quién se debe informar.

Debemos recordar que es solo una guía y que depende de la estructura organizacional de la empresa a la que le estemos realizando el análisis, qué puestos corresponden a qué perfiles o estructuras.

» Prácticas del proceso, entradas y salidas: una vez que las prácticas del proceso se han listado en la matriz RACI, en esta sección Cobit proporciona el nombre y la descripción de cada práctica con sus respectivas entradas y salidas, indicando el origen y el destino de los productos de trabajo de las prácticas involucradas en el proceso en particular.

» Actividades: ya casi al final se describen las actividades correspondientes que deben realizarse para efectuar dicho proceso.

» Guía relacionada: al final de cada proceso se encuentra la guía de documentos que utilizaron para definir cada una de las diferentes secciones de especificación del proceso, como objetivo, propósito, roles, métricas, entradas, salidas y actividades.

Otro de los cambios importantes respecto a las versiones anteriores de Cobit está en el modelo de nivel de madurez de cada proceso, el cual, como mencionamos en el artículo anterior, ahora toma como referencia a ISO/IEC 15504 en lugar del CMM. Para poder identificar el nivel de madurez de cada práctica de gobierno o de administración, se debe utilizar otro documento de ISACA llamado “process assessment model (PAM) using COBIT 4.1”, que, a pesar de estar orientado a COBIT 4.1, como es genérico se puede ocupar para COBIT 5.

En resumen, la nueva versión de Cobit busca ser el referente principal para procesos de tecnologías de información, ayudando a diseñar procesos, definir responsabilidades, establecer prácticas y actividades, así como a definir los entregables. Todo con el propósito de contar con una correcta administración de servicios de tecnología de información, proporcionando con esto una calidad mejorada en la entrega de servicios de TI vía procesos.

36

Amenazas y vulnerabilidades Carrier Class

jjcejudo@scitum.com.mx

José Juan Cejudo Torres

opinión

Los usuarios de servicios de telecomunicaciones a menudo asumimos que el entorno que nos ofrecen los proveedores está protegido. Seamos realistas, no nos hemos

ocupado de corroborarlo o nos importa poco; reflexionemos acerca de cómo estas redes son estructuradas e instaladas.

En repetidas ocasiones hemos escuchado de acontecimientos noticiosos donde se vulnera la confidencialidad de las llamadas, donde alguien recibe un mensaje

escrito con supuestas ofertas, promociones, premios y dádivas en tono de regalo, que se aprovechan de la nobleza de la gente que termina siendo presa de fraudes.

Evidentemente muchos sucesos de este estilo son culminados y fructifican tras una ingeniería social efectiva (no sé si llamarle el “eslabón más débil” pero la actuación

de ese actor en el proceso de comunicación ha sido indispensable para conformar las alarmantes estadísticas en fraudes exitosos).

Quienes ya han tomado mayores previsiones y quienes a través del tiempo han realizado esfuerzos serios y constantes son los clientes empresariales, dado que sus activos son más críticos en términos del negocio y el ser “indiferente” resulta muy costoso. Algunos se preguntarán: ¿Si mi proveedor me da el acceso y servicios de Internet – por ejemplo – no podría entregármelos con más controles de seguridad?, ¿acaso no están ellos y su negocio demasiado expuestos a estas amenazas? La respuesta es que sí lo están y habrán de hacer esfuerzos para mantenerse fuera de las listas negras como país generador de spam o con el mayor número de direcciones IP marcadas con actividad sospechosa, etcétera.

Hoy en día la oferta de los proveedores de servicios (carriers) es tan poderosa que los ámbitos a proteger se multiplican ampliamente. Los proveedores de servicios tendrán la particularidad de ofertar servicios masivos pero -aún más antagónico a esta concepción- tendrán la necesitad de ofrecer una seguridad específica o con la granularidad necesaria para servir como recursos fidedignos en una persecución legal por ejemplo, y sin transgredir la confidencialidad de la información de los afiliados.

Indudablemente la velocidad de las tecnologías y la forma en la que se están esparciendo alrededor del mundo, y los entornos de aprovechamiento de las mismas nos amplían las ofertas a través de la convergencia… lo que antes solo se ofrecía para empresas ahora es de interés para los usuarios finales; lo que solo se concebía como servicios en entornos fijos ahora se ven fortalecidos con plataformas que brindan movilidad y características de ubicuidad de gran alcance.

Seguridad en el ruteo IP de los proveedores de servicios

BGP (border gateway protocol) forma parte del ADN de cualquier proveedor de servicios y proteger este protocolo de ruteo es primordial.

El protocolo BGP envía mensajes, hace decisiones de ruteo o comparte atributos. Los mensajes pueden ser anuncios acerca del origen del paquete, avisos de ruteo o retiro de ruteo y, con base en estos, realiza las decisiones del mejor camino para llevar la información entre sistemas autónomos. Sin entrar en gran detalle acerca del funcionamiento de BGP, centrémonos en las principales causas de fallas, amenazas y problemáticas de este protocolo de ruteo.

Es bien sabido que Internet está dividido en sistemas autónomos (AS) y que todos los hosts en un AS tienen un solo control administrativo. El ruteo interdominios es solamente completado vía BGP. De esta manera los AS se informan de manera cooperativa uno a otro, para cada dirección IP acerca de dónde o en cuál AS se encuentra y cómo llegar a ella. Dado que BGP es un protocolo basado en políticas, cada AS elige entre múltiples rutas que se reciben para el mismo prefijo de acuerdo a su propio criterio. Asimismo un AS puede aplicar una política cuando exporta una ruta de forma que se envía al vecino solo si este está dispuesto a aceptar y reenviar tráfico al prefijo desde su vecino. Los ruteadores de frontera entonces colaboran en esta comunicación.

372012

Quizá el mayor problema sigue siendo la configuración errónea del protocolo y esta no solo puede ser a causa de la poca experiencia o errores humanos, sino también puede ser provocada por un atacante. De acuerdo a un estudio realizado por la Universidad de Washington1 las configuraciones erróneas se presentan sobre todo en:

» Errores (bugs) de inicialización del ruteador: son sometidos a investigación con fabricantes.

» Confianza en filtrado hacia proveedor superior: algunos AS confían o asumen que el proveedor superior los conoce, pero pudiera no ser visible de manera global.

» Configuraciones antiguas sin actualizar.

» Redistribución de rutas.

» Errores en la comunidad BGP.

» Hijack: ocasionalmente un AS no relacionado anuncia espacio de direcciones perteneciente a otro sistema autónomo. A pesar de que el potencial de hacer esto es una falla mayor de seguridad, la causa más común de esto es un problema de escritura (“error de dedo”) cuando el AS con error en configuración se hace dueño de prefijos que son similares a los prefijos “secuestrados”.

» Filtro olvidado en la configuración: cuando un ISP responde aceptando una configuración errónea olvidando filtrar estas rutas.

Ataques a la plataforma con BGP

Los errores arriba mencionados pueden derivar en afectaciones importantes, entre ellas las siguientes:

» Sobrecarga en el ruteo: incrementan la carga en el ruteo, generando actualizaciones innecesarias de BGP. Con el tamaño actual de Internet cualquier cambio afecta a toda la comunidad.

» Interrupción de la conectividad, tanto local como global.

» Violación de la política: anuncios erróneos de ruteo pueden ser elegidos como validos y transitar inadvertidamente a otros sistemas autónomos.

» Hoyos negros en Internet: lugares dentro de la red donde los paquetes son descartados sin informar a la fuente de la causa. Tal vez el caso canónico más representativo es el conocido como Incidente AS70072.

A pesar de los años que han transcurrido desde la realización del mencionado estudio, le sorprendería al lector lo mucho que se siguen observando estas fallas. Por ejemplo, el 20 de agosto pasado la empresa rusa de telecomunicaciones Link Telecom envió un comunicado informando que su red había sido presa de un ataque y por ello el sistema autónomo AS-31733 había sido secuestrado en cinco prefijos. Lo que es más sorprendente es que dicho secuestro había comenzado en abril de 20113.

Entonces, ¿cuáles son los ataques más comunes a BGP?:

» Ataques de origen: pueden derivarse de errores humanos y desestabilizan la operación desde el anuncio de los prefijos.

• Prefix Hijaking.

• Prefix destabilization (principal causante de hoyos negros junto con el siguiente ataque).

• Self-deaggregation.

• Unauthorized use. » Ataques de ruta: son usados para trastornar el ruteo y sesgar la forma en

que los paquetes viajan a través del sistema autónomo.

• Path modification.

• Path forgery.

• Policy modification.

• AS forgery. » Ataques de timing.

• Mensaje “OPEN spoofed” durante la fase de negociación.

• Ataque TCP SYN.

• Alteración de timers BGP.

• Mensajes KEEPALIVE falsos mientras los ruteadores peer se estén conectando.

38

» Ataques de disponibilidad.

• En protocolo. » Mensajes NOTIFICATION falsos.

» Errores de sintaxis en mensajes BGP.

» Forzar que una inundación de ruteo ocurra.

» Paquetes TCP RST falsos.

• Enlaces físicos. » Provocar la reinicialización del ruteador para ganar control de él. Por ejemplo, ejecutando un

desbordamiento de buffer a través de un ataque SNMP.

» Afectar directamente el enlace.

Finalmente proveeré algunas de las sugerencias más comunes para evitar los ataques en la infraestructura BGP:

» Considerar la arquitectura y tecnología de ruteo como parte del portafolio de seguridad.

» Realizar el endurecimiento de configuraciones (hardening) a la infraestructura.

» Para un ataque contra DDoS BGP: cuidar el control de políticas, ya sea a través de CoPP (Control Plane Policing) o LTPS (local packet transport protocol).

» Asegurar la correcta asociación de ruteadores peer: autenticación de ruteadores vecinos a través de MD5 o keychain/TCP-OA (object autentication) y protección con IPSec a las sesiones TCP de BGP.

» Centralizar el modelo de seguridad a través de BGP Flow-Spec.

» Contra tráfico DDoS enviado hacia la red atacando la infraestructura: emplear recursos como RTBH (remote triggered black holes), Blacklist VRF, Sinkhole Routing y FlowSpec

» Para evitar la conexión de falsos BGP peers: habilitar la protección a través del máximo valor de TTL (time to live) – GTSM (generalized TTL security mechanism) -, LPTS (local packet transport protocol), MD5 o keychain/TCP-OA (object autentication) para la validación de anuncios.

» Contra inyección de información de ruteo falso por un partner: instrumentar autorización de orígenes y SIDR para autenticar rutas.

» Ataques con políticas de ruteo y atributos de ruteo BGP: Flexible RPL, BGP attribute filtering y BGP error handling.

» Para evitar que el secuestro de direcciones dirija a clientes a falsos sitios Web: instrumentar autenticación de AS origen y emplear SIDR (secure interdomain routing).

» Instrumentar RPKI (resource public key infrastructure) para verificar criptográficamente las asociaciones de sistemas autónomos y sus direcciones IP.

» Optimizar el filtrado de lo conocido como BOGONS: un BOGON es una dirección IP falsa, y un nombre informal para un paquete IP sobre el Internet público que “reclama” ser de un área de direcciones IP reservadas, pero no son delegadas o asignadas por IANA o por un delegado regional (RIR–regional Internet registry), las áreas de espacios de direcciones sin asignar son llamadas bogon spaces. La mayoría de los ISP y firewalls de usuarios finales filtran estos espacios de direcciones dado que no tienen un uso legítimo.

Conclusión

Aunque el entorno analizado en este artículo suele estar fuera del alcance del análisis de ambientes empresariales comunes, quise llamar la atención sobre el hecho de que las aplicaciones empresariales suelen descansar, al menos en parte, en la infraestructura del proveedor de servicios. Por ello no debe dejarse de lado el análisis de seguridad en el carrier y, como usuarios finales, debemos pedir a nuestros proveedores que se preocupen y nos informen de la parte que a ellos compete.

1Proceeding. SIGCOMM '02 Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications Pages 3-16

ACM New York, NY, USA ©20022http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html 3http://www.symantec.com/threatreport/topic.jsp?id=spam_fraud_activity_trends&aid=future_

spam_trends

POLÍTICASPOLÍTICAS que apoyan  las necesidades del usuario yla transformación de la seguridad dentro del proceso del negocio.

PERSONASSeguridad que educa y compromete a las PERSONAS en ladefinición de políticas, concientización y la solución de incidentes.

CUMPLIMIENTOVisibilidad y  control en todos los niveles de seguridad - red,aplicaciones y datos-.

w w w . c h e c k p o i n t . c o m

Check Point 3D seguridad, combina políticas, personas y aplicaciones de protección inmejorables.

C

M

Y

CM

MY

CY

CMY

K

CHKPNT_3d-security-ad.pdf 1 2/7/12 12:40 PM

Copyright © 2011 Hewlett-Packard Development Company, L.P.

Para más información visite: www.hpenterprisesecurity.com.

Protección avanzada contraamenazas avanzadas.

No se puede detener las amenazas si no las puede detectar. Esto es por lo que HP Enterprise Security ofrece soluciones probadas que ofrecen amplia visibilidad en riesgos de seguridad. No hay mejor manera de detectar de forma proactiva problemas de seguridad y manejar conscientemente la situación a través de sus aplicaciones, operación e infraestructura. La Inteligencia de seguridad de HP y la plataforma de gestión de riesgos ofrece correlación integrada, protección de aplicaciones y defensas de la red que pueden dar seguridad moderna en entornos TI con amenazas sofisticadas.

¿PUEDES VER EN TODAS PARTES A LA VEZ?

TU PUEDES.

C

M

Y

CM

MY

CY

CMY

K

HPESP_SeeEverything_Spanish.pdf 1 6/5/12 9:11 AM