contenido » editorial » opinión » misión: crítica » conexiones Dirección General Editor en jefe Editores Consejo Editorial Colaboradores

Transcripción

1

2

3 contenido 10 AÑO 3, NÚMERO 4, 2012 Dirección General Ulises Castillo Hernández Editor en jefe Héctor Acevedo Juárez Editores Gerardo Fernández Miranda David Gutiérrez Jiménez Consejo Editorial Ulises Castillo Hernández Priscila Balcázar Hernández Héctor Acevedo Juárez Gerardo Fernández Miranda Elia Fernández Torres Colaboradores Héctor Acevedo Juárez Omar Alcalá Ruiz David Bernal Michelena Diana Cadena Martínez Ulises Castillo Hernández José Juan Cejudo Torres David Gutiérrez Jiménez Eduardo Patricio Sánchez Díaz Ricardo Javier Ramírez Díaz Esteban San Román Canseco Marketing y Producción Karla Trejo Cerrillo Correctora de estilo Adriana Gómez López Diseño Silverio Ortega Reyes Magazcitum, revista trimestral de Scitum S.A. de C.V. Año 3, número 4, Editor responsable: Héctor Acevedo Juárez. Número de Certificado de Reserva otorgado por el Instituto de Derechos de Autor: Número de certificado de Licitud de Título y Contenido: 14900, Exp.: CCPRI/3/TC/10/ Domicilio de la Publicación: Av. Paseo de la Reforma 373 piso 7, Col. Cuauhtémoc, delegación Cuauhtémoc, México DF 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 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 » editorial» opinión 4 Editorial Héctor Acevedo Juárez 6 Prepararse para enfrentar incidentes de seguridad David Bernal Michelena 10 El mundo de las bitácoras. (Parte 1: problemática) Omar Alcalá Ruiz 14 SAP: una plataforma altamente funcional y altamente expuesta Esteban San Román Canseco 32 Mejora continua: camino al éxito Diana Cadena Martínez 34 Modelo de referencia de procesos en Cobit 5 Ricardo Javier Ramírez Díaz 36 Amenazas y vulnerabilidades Carrier Class José Juan Cejudo Torres» misión: crítica 18 La seguridad y nuestros elefantes (segunda parte) Ulises Castillo Hernández» conexiones 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 Fin de año, hora de recapitulación Héctor Acevedo Juárez CISSP, CISA, CGEIT, ITIL y MCSE hacevedoj@scitum.com.mx 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 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. Ilustraciones: Silverio Ortega Reyes 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 ( 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 4

5 2012 5

6 opinión Prepararse para enfrentar incidentes de seguridad David Bernal Michelena GCFE, GCFA y ACE 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. 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 preservar 1 : 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 seguridad 2, 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). 6 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.

7 «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» 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 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 Windows 3. 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:

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. 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 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. 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 Default.aspx 8

9 Poderosamente Simple Seguridad de la Información y la Gestión de Eventos 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 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 NetIQ Corporation y sus afiliados. Todos los derechos reservados.

10 opinión El mundo de las bitácoras (parte 1: problemática) Omar Alcalá Ruiz CISSP, ISO y CCNA oalcala@scitum.com.mx 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. 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. 10

11 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. 12 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á...

13

14 opinión SAP: una plataforma altamente funcional y altamente expuesta Esteban San Román Canseco CISSP, CISA, CEH, ITIL y CRISC esanroman@scitum.com.mx 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 siguientes 1 : 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. 14

15 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: 10 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. 9 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. 8 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

16 7 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. 6 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. 5 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. 4 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. 16

17 3 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. 2 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. 1 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. 1 Si usted estimado lector, desea entender mejor la terminología que se utiliza en SAP, le recomiendo consultar la siguiente referencia:

18 isión:crítica La seguridad y nu (segunda parte) Ulises Castillo Hernández MSIA, CISSP, CISM y CISA ucastillo@scitum.com.mx 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. Modificar nuestros paradigmas 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. 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). 18

19 estros elefantes 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 tantopiensan 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? misión:crítica 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

20 isión:crítica Té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. 20