YARA 101

¿Qué es YARA?

Cuando se habla de detección de malware existen principalmente tres maneras de determinar si un fichero es dañino o no: firmas, heurística y string signatures.

La más extendida en los sistemas de detección antivirus es la detección en base a firmas, es decir, en base al resultado de calcular el HASH de un fichero, pasarlo por una base de datos de firmas y comprobar si este fichero ha sido detectado anteriormente como malware. Este tipo de firma es inútil para la detección de malware no conocido y para evadirlo basta con recompilar el código en un sistema diferente o cambiarle un solo bit.

Para tratar de parar estos métodos de evasión se utiliza el método heurístico. Este método se basa en el comportamiento del ejecutable y, de acuerdo a las acciones que realiza dentro del sistema, se decide si el fichero es malicioso o no. El principal problema de este método es que puede generar una gran cantidad de falsos positivos ya que muchos programas realizan acciones lícitas que pueden hacer saltar las alertas.

Por último, queda el método que atañe a este artículo, string signatures. Este método se basa en otro tipo de firmas diferente al comentado anteriormente. En lugar de usar firmas tipo HASH, utiliza cadenas de texto o binarias que identifican inequívocamente a un malware. De esta forma aunque se modifique el fichero, si este sigue conteniendo esas cadenas que conforman una firma, los analistas seguirán siendo capaces de detectar y clasificar ese malware.

[Read more…]

Diseñando Sistemas II: El diseño del sistema

Como ya indicaba en el anterior artículo de este ciclo, quiero recordar que estoy escribiéndolos basándome en mi propia (y dilatada) experiencia y reflejan tan solo ideas generales y prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado.

Así pues, continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez consideramos que la toma de requerimientos ha sido hecha y documentada adecuadamente y el cliente ha dado su visto bueno, comenzaremos con el diseño del sistema de tratamiento de la información. En esta etapa debemos asegurarnos de plasmar en el diseño todos aquellos requerimientos que hayamos sido capaces de conocer, aun cuando se dé el caso frecuente de que no va a ser posible implementar todas las funciones posibles ya que el cliente ha limitado el ámbito de actuación, solicitado un sistema más sencillo y de bajo coste y en este caso hay que recortar el desarrollo hasta donde sensatamente se pueda y limitarlo a la visión del cliente.

Es aquí donde la habilidad del responsable del proyecto debe mostrarse, definiendo las funciones esenciales, las que son convenientes —pero no son esenciales— y otras funciones posibles y deseables que, en una primera versión del sistema, tal vez no podrán implementarse, pero que muy posiblemente serán objeto de posteriores peticiones del cliente para ampliar la funcionalidad del sistema y si hemos sido capaces de prevenir estas circunstancias, será más sencillo satisfacerlas. De este modo, y tal como ya dije en mi artículo anterior, el clásico “esto no me lo habías contado y no está previsto”, quedará sustituido en la mayoría de las veces por “es posible integrar lo que me pides” y la inversión para implementar estas nuevas funcionalidades será menor y más rentable para el proveedor que lo tenía previsto que para aquel que necesita replantearse el diseño del sistema. Para ello, conviene dotar al diseño inicial de ciertos elementos de ajuste y flexibilización en la forma de procesar la información, que más adelante nos van a permitir implementar funciones y controles adicionales sin gran esfuerzo, rentabilizando así la inversión inicial.

¿Cómo se puede llegar a esto? Adquiriendo conocimientos extra durante el diálogo con el cliente, intuyendo lo que no ha dicho y previniendo que suceda. Por ejemplo, identificando los elementos clave que pueden definir el modo de procesar la información y añadiéndolos al sistema como entidades gestionables individualmente. Cuando el interlocutor te dice, tenemos clientes y proveedores —por ejemplo— pero no ha definido clases dentro de ambos, debemos averiguar si hay clientes que requieren procesos específicos o funciones dedicadas a su situación o necesidad y en tal caso prevenir ya que van a haber categorías de clientes y seguramente también de proveedores, así como que clientes o proveedores tendrán ramificaciones en el interior de los procesos. Si nos dice que compran o prestan tal o cual servicio, averiguar cuantas particularidades corresponden a cada uno y cómo se aplican a los clientes y proveedores (tal vez se está haciendo manualmente y bajo la “cultura” de algún empleado experto) y así sucesivamente. Probablemente de pronto el sistema tenga definido un fichero de tipos de cliente, otro de tipos de proveedor, otro de tipos de servicio (distribución), otro de condiciones de facturación, etc., de tal modo que si surgen nuevas combinaciones no hay que tocar programas, solo combinar nuevas entradas en los ficheros. Será importante también establecer relaciones válidas entre los diferentes conceptos, que al final definan las transacciones posibles que el sistema va a ejecutar, de manera que sólo sea posible procesar aquellas combinaciones previamente definidas en tablas de control.

Por citar un ejemplo de lo que propongo, un cliente del sistema de salud no puede recibir un medicamento registrado si no es una farmacia. Por tanto un hospital ha de comprar estos medicamentos a través de su farmacia o de una farmacia externa, pero nosotros no podemos servir ni facturar estos medicamentos a un cliente que no es una farmacia. Las entradas de nuestras tablas reflejarán las relaciones válidas entre tipos de clientes (hospital, clínica, farmacia, etc.) y tipos de productos (producto hospitalario, medicamento no registrado, medicamento registrado, etc.) y de este modo el sistema dará un aviso e impedirá —si se desea— que se asigne inventario de un producto a un pedido de un cliente que legalmente no puede comprar ese producto, evitando errores en la transacción final, y lo que es más importante, riesgos legales. Crear un programa que sirva y facture cualquier producto a cualquier cliente es fácil, pero no hablamos de eso, sino de control, seguridad y valor añadido.

Del mismo modo, podremos actuar en la definición de funciones, habrá que esforzarse en que unas no dependan de otras y las puedan condicionar, sino que las condiciones estén gestionadas a través de elementos externos, de nuevo, en una tabla o veinte tablas de la base de parámetros de ajuste del sistema.

El análisis de los procesos reflejará con claridad las funciones a ejecutar y sus relaciones con las entradas de las tablas o ficheros citados, para que los técnicos puedan aplicar estos criterios y crear programas que gestionen transacciones basadas en los parámetros incluidos en las tablas de control citadas y también en los registros de datos, ya que en este último caso, por ejemplo, habrán sido añadidos al crear un cliente, definiendo su clase y validándola en la tabla de clases de clientes, el tipo de servicio que requiere, sus particularidades para facturarle, etc., tal como haya sido predefinido anteriormente por el usuario experto o el administrador del sistema.

Tal vez parezca que todo esto es obvio, pero pueden creerme si les digo que el mundo está lleno de sistemas y procesos que no entienden nada de esto y que requieren intervención —a veces intencionada— de soporte cada vez que algo nuevo afecta al proceso de la información, por no hablar aquí de las condiciones de explotación del sistema (ya lo hice en otro artículo “La Explotación de Sistemas Informáticos”). Definir nuevas transacciones de negocio debe convertirse en un problema de administración y ajuste del sistema, en lugar de una revisión y reprogramación del mismo. Como ya he indicado, habrá un usuario, o varios, expertos en la administración del sistema y en la definición y ajuste de los parámetros que componen las transacciones que ejecuta, y aunque esta tarea puede ser subcontratada externamente como parte de un servicio, es muy conveniente que quede dentro de la empresa usuaria.

Tal vez el cliente pueda sorprenderse de que se requiere hacer una definición inicial de todos los parámetros y se pierda en el concepto, pero verá sus resultados con cierta rapidez, en cuanto pueda definir sus propias funciones dentro de lo previsto y cambiar el modo en que se procesa la información en ciertas circunstancias (un cliente que inicia una nueva actividad o negocio, por ejemplo).

Conferencias Navaja Negra – Días 2 y 3

Continuamos con el resumen de la 3ª edición de Navaja Negra, al que asistimos José Vila (@jovimon) y un servidor los pasados días 3-5 de octubre.

En este segundo día, la primera charla fue a cargo de Marc Rivero (@Seifreed), en la que habló sobre la evolución del fraude en Internet. En ella, Marc comenzó haciendo un breve resumen sobre las amenazas más sonadas: phishing, troyanos, el virus de la Policía… así como de los kits disponibles en el mercado negro para facilitar la creación de los mismos.

Respecto a este tipo de amenazas, Marc también hizo hincapié acerca de las herramientas disponibles en ambos bandos ya sea para verificar que el malware es indetectable o bien para poder neutralizarlo. También se habló sobre las técnicas Man-in-the-Browser, en las que el atacante actúa de árbitro entre el cliente y el servidor, obteniendo en este caso las credenciales de acceso a la cuenta corriente de la víctima, para luego realizar pequeñas transferencias que puedan pasar desapercibidas.

Otros temas que se trataron en la charla fueron los de los muleros y el uso de servidores a prueba de balas, o servidores comprometidos, para alojar el malware y dificultar la identificación de los responsables.

[Read more…]

Conferencias Navaja Negra – Día 1

Hace unos días, mi compañero Joel (@jsevilleja) y yo asistimos a las charlas Navaja Negra, que tuvieron lugar en Albacete del 3 al 5 de octubre. Navaja Negra son unas charlas jóvenes (van por la tercera edición), pero a pesar de ello congregan a un montón de gente interesante, manteniendo un espíritu colaborativo y cercano. Podéis seguir lo que se ha escrito sobre ellas en los hashtag #nn3ed y #nn3d, o seguir su cuenta oficial de Twitter en @navajanegra_ab.

Las conferencias tuvieron lugar, después de un cambio de ubicación a última hora, en las instalaciones de la Universidad Popular de Albacete. Tras el acto de bienvenida, empezaron las charlas.

La primera de ellas corrió a cargo de Juan Carlos Montes (@jcmontes_tec), de Inteco, que nos habló de una herramienta que ha desarrollado, llamada Telepathy. Esta herramienta proporciona una gran versatilidad a la hora de analizar muestras de malware ya que permite al analista actuar en dos frentes: por una parte, permite cargar nuevas DLL en un proceso en ejecución y hacer que este proceso las utilice; por otra, permite lanzar la ejecución bajo demanda de cualquier función o fragmento de código incluida en un proceso en ejecución. Este segundo supuesto es muy útil por ejemplo en funciones de cifrado y descifrado de las comunicaciones del malware, ya que da la posibilidad al analista de obtener las órdenes que envía y recibe una muestra de código malicioso sin tener que hacer ingeniería inversa sobre dicha muestra.

[Read more…]

A stolen ringbuoy, a stolen life

Queridos lectores, si el título de la presente entrada les ha llamado la atención, les pido que nos acompañen durante cinco minutos. Voy procurar resumir en pocas líneas una reflexión que gira en torno a la publicidad, seguridad y concienciación, que hice a raíz de leer ese lema.

Hoy en día estamos saturados por la cantidad de información que recibimos de todo tipo. Siendo conscientes de este hecho, los publicistas hacen uso de su creatividad para conseguir llamar nuestra atención a través de elaboradas campañas publicitarias. Aunque no seamos publicistas (es posible que algunos de nuestros lectores sí lo sean), creo que debemos tomar ejemplo a la hora de comunicar aspectos relativos a la seguridad.

En las últimas vacaciones vi un lema que me impactó tal y como lo hacen dichas campañas publicitarias. Sobre la frase “A stolen rinbuoy, a stolen life” que vendría a ser algo como “Un salvavidas robado, una vida robada”, se hallaba uno de los múltiples aros salvavidas que están a lo largo del río Corrib en su desembocadura en Galway (Irlanda).

[Read more…]

Incidente con Malware de posicionamiento en buscadores, SEO

Recientemente detectamos en un servidor una extraña conexión hacia un servidor que hizo saltar la alarma por un posible compromiso del mismo. La petición que se detectó desde dicho servidor fue únicamente la que se muestra a continuación:

GET /system/mngr.php?id=a5f99b82b662d6e2b98b30e3077606ba&md5=9e5d6df936986f0b4d5fd4794807824f HTTP/1.0
Host: manka11.com

Como única respuesta se recibió la palabra UNCHANGED.

Tras analizar las peticiones que recibe el servidor, no se aprecia ninguna sospechosa que pudiera indicar alguna webshell desde la que lanzar esa petición, ni ninguna orden dirigida a un recurso sospechoso o pasada como parámetro que llamase la atención, lo que nos hizo analizar el registro del servidor para ver qué actividad hubo.

Antes de pasar a analizar el log, buscamos los últimos ficheros modificados en el directorio del servidor y, por tratarse de un posible servidor web comprometido, especialmente aquellos ficheros con funciones que utiliza habitualmente el malware para ofuscarse (base64_decode, preg_replace, eval, error_reporting(0), etc.). En este caso ya empezamos a ver indicios que nos llevaban en la dirección correcta: unas carpetas que parecen ser módulos de Joomla! creados en fechas diferentes que contienen algunas de las funciones buscadas:

[Read more…]

“Núcelar”. La palabra es “nuu-ce-lar” (*)

Recientemente leí un artículo publicado por Joseph M. Weiss en su blog Unfettered blog. El título reza “The system is still broken. The failure of a cyber-sensitive substation device affecting a nuclear plant” y puede consultarse aquí. El título es bastante elocuente y capta inmediatamente la atención del lector. Y ello, en mi opinión, ocurre por la combinación de tres palabras: failure + cyber + nuclear. Toda época tiene sus miedos y la nuestra, como recuerdo de la guerra fría y la posibilidad cierta de una catástrofe atómica, lo tiene al holocausto nuclear. Este terror es reforzado de tanto en tanto, de forma que nunca deja de estar presente. Tras el fin de la guerra fría vino Chernóbil, y ahora tenemos Fukushima. La bestia atómica ha actuado contra su creador en tres ocasiones: a causa de un acto de guerra en Hiroshima y Nagasaki, a causa de la incompetencia y el mal diseño en Chernóbil y, finalmente, a causa de la Tectónica de placas en Fukushima. ¿Qué será la próxima vez? En la era de las TIC un acto de ciberguerra, ciberterrorismo o ciber-mala suerte se postula como candidato para abrir la puerta del terror nuclear.

Planta de generación de energía eléctrica de Didcot (UK)(1)

Ahora bien, tras captar nuestra atención con semejante título, ¿qué hay en el texto? Pues, básicamente, se describe un incidente reportado en una central nuclear. Según se refiere en el artículo, un cambiador de tomas falló tras estar operando de forma continuada durante un intervalo de tiempo demasiado largo. Este tipo de dispositivos se emplean en los transformadores de potencia para regular automáticamente la tensión en los devanados de salida manteniendo ésta dentro de límites prefijados. Puesto que estos dispositivos tienen capacidad de conectarse y gobernarse de forma remota, se especula con la posibilidad de que haya sido víctima de un ciberataque. Y nada más. ¿Pudo haberlo sido? Quizá sí, quizá no. ¿Cuál fue la afección sobre la central? Pues posiblemente ninguna. Como bien se dice en el texto, estos dispositivos se emplean en muchos puntos de la red eléctrica y no constituyen un componente exclusivo de una central nuclear. De hecho, hay muchos otros lugares donde un fallo de este tipo de dispositivos es, potencialmente, más dañino.

Así pues, la sensación tras leer el artículo es que nos encontramos con la descripción de un caso tipo “alguien ha matado a alguien”. La adición del factor nuclear actúa como multiplicador para dar entidad al caso.

Esto es sólo un ejemplo de cuán automática es la asociación de las palabras “Infraestructuras críticas” y “energía nuclear”. Y esta asociación, por tópica, acaba por diluir el riesgo real ya que, a fin de cuentas, la mayor parte de las infraestructuras críticas no son centrales nucleares y la mayor parte de los ciberataques no buscan (o buscarán) provocar un síndrome de China. Y es que una cosa es provocar la indisponibilidad de una central de generación (de cualquier tipo) y otra cosa es hacer volar un reactor nuclear. ¿Cuál es la diferencia (más allá de un impacto local) de provocar la indisponibilidad de un tipo de planta u otro? A efectos comparativos, la participación en la generación total durante el año 2012 del parque nuclear español fue del 22,1%, mientras que las centrales de carbón produjeron un 19,3% (2). Alguien podría argüir: “de acuerdo, pero Francia sí que tiene gran cantidad de generación nuclear, por lo que, ya que adquirimos gran cantidad de energía de nuestro vecino, la indisponibilidad de sus centrales sí que nos afectaría”. De nuevo hay una falacia aquí. El saldo de energía intercambiada con Francia durante 2012 fue de 1.524 GWh. El consumo total de España de 251.710 GWh (3). Por cierto que este año no fue una excepción: eléctricamente, la península es una isla a causa de la escasa capacidad de intercambio con el resto de Europa.

Hemos de tener cuidado, pues, con estas cosas. Los mensajes catastrofistas suelen ser contraproducentes, ya que la sociedad termina por insensibilizarse.

Especialmente cuando pasa el tiempo y el Juicio Final no parece llegar tal y como se anunció.

NOTA FINAL: la imagen que acompaña este artículo no es de una central nuclear. Pero es curiosa la tendencia de los medios de comunicación a asociar imágenes de torres de refrigeración, no exclusivas de este tipo de centrales, con noticias sobre energía atómica. O con noticias sobre emisión de CO2, pese a que lo que sale por ellas es vapor de agua.

(*) Simpson, Homer J.
(1) Imagen tomada de Wikipedia. Autor: Owen Cliffe.
(2)(3) Informe sobre el sistema eléctrico español. Año 2012. Red Eléctrica de España.

Veil – Evasión de Antivirus

Hace un tiempo, por necesidades en el trabajo buscaba algo que me permitiera encapsular un payload de Metasploit y que éste no fuese detectado por los antivirus. En otras ocasiones he usado los “requetecifrados” con las múltiples opciones que permiten las herramientas msfpayload y msfencode. Otras veces me ha valido con las diversas herramientas que facilita SET (Social Engineering Toolkit) de Metasploit. Sin embargo, tras realizar varias pruebas, un antivirus actualizado detectaba el troyanete que iba dentro y saltaba enseguida. Quizás no elegía correctamente las opciones…

Así que buscando por Internet herramientas de evasión de antivirus enseguida me topé con VEIL. Si, lo sé, hemos estado todo el verano oyendo (y huyendo) de él, pero no, no es ese Veil…
Veil es una aplicación que cumple el propósito buscado: Empaquetar un payload de Metasploit y que los Antivirus no lo detecten. Está implementada en Python y, desde hace poco, está incluida en la distribución Kali Linux. Vamos con ella:

Descarga

Veil, desarrollada por @christruncer, se puede descargar desde la web del proyecto o puede hacerse un clonado de todos los ficheros mediante git:

#git clone https://github.com/veil-evasion/Veil.git

Instalación

La instalación no es muy enrevesada pero, como siempre, tenemos que andar con ojo con las dependencias. En este caso, Veil dispone de un instalador que permite la descarga e instalación de las dependencias (Wine, Python, PyInstaller, etc) en un Siguiente, Siguiente. Para ello se debe ejecutar el fichero /ruta_elegida/Veil/setup/setup.sh y responder a lo que nos vaya preguntando (son preguntas triviales). Cuando nos proponga descargar e instalar una serie de módulos, le diremos que sí.

Uso

Una vez instalado, vamos a hacernos un troyanete sencillo. Arrancamos Veil:

#python /ruta_elegida/Veil/Veil.py

y accedemos a la pantalla principal.

Las opciones son bastante simples y están explicadas, así que no hay escusa para no probarlas. Ahora vamos con el asunto principal, así que seleccionamos use.

A continuación se muestra la lista de payloads que hubiese aparecido si hubiésemos elegido la opción list. En ella se distinguen 18 payloads diferentes, agrupados por el lenguaje empleado para programarlo (c, c#, python…) y una valoración sobre la “calidad” del payload (poor, normal o excellent).

Vamos a elegir uno de los Excellent, ¿no? Y ya que estamos en un entorno Python y es un lenguaje que nos gusta, vamos a elegir el payload python/AESVirtualAlloc (opción 10).

La siguiente pantalla nos muestra las opciones del payload, que vamos a dejar tal y como están. Luego tenemos otra lista de opciones también muy básica.

Seleccionamos la opción que nos interesa: generate.

En la siguiente pantalla dejamos la opción por defecto para elegir el shellcode que queremos: msfvenom (opción 1) que según parece es una conjunción de los ya nombrados msfpayload y msfencode y seguimos.

Ahora toca elegir el payload que queremos que se ejecute. Por defecto nos ofrece nuestro gran amigo Meterpreter, pero puede seleccionarse cualquiera de los disponibles. Presionando el tabulador, se van mostrando las diferentes opciones. No os compliquéis, el seleccionado (windows/meterpreter/reverse_tcp) funciona muy bien. Si por cualquier causa os falla al probarlo, simplemente probad suerte con otro.

Bien, ya vamos acabando. Una vez elegido el payload, nos pedirá la IP y el puerto de LHOST, el equipo que recibirá la conexión inversa con Meterpreter. Luego nos dará la opción de añadir algún parámetro opcional de msfvenom, pero lo dejaremos como está. Pulsamos de nuevo enter y comienza la generación del shellcode.

Nos da la opción de ponerle un nombre al fichero resultante. Por ahora lo dejaremos con el nombre por defecto, luego ya se lo cambiáis si queréis (nominas2013.exe es mi preferido ;)

La siguiente pantalla ya es la última. Se nos ofrece la opción de usar Pyinstaller, el cual hemos instalado antes y con el que se genera un paquete .exe con todas las dependencias; o usar Py2Exe, el cual genera los tres ficheros necesarios para luego empaquetar el ejecutable.

Como hasta ahora, no nos complicamos y que lo haga él. Seleccionamos la opción 1 y finalizamos. En este momento empiezan a salir varios mensajes por consola mientras genera el ejecutable y finalmente, muestra un resumen de todo. En este se puede ver la ruta en la que ha dejado el resultado.

Cabe destacar el mensaje que se muestra al finalizar el proceso: No lo subas a una web de scanners antivirus (tipo VirusTotal). Estas Webs suelen mandar una firma de todos los archivos que se analizan a las casas de Antivirus, así que no os autotroleéis…

Pruebas

Vamos a ser rápidos. Probaremos en un precioso Windows7 con AVG actualizado a ver qué pasa…

Para la prueba debemos poner a escuchar nuestro equipo. Una forma sencilla que ya conocéis es mediante el handler de Metasploit. No hace falta añadir ninguna opción ya que el puerto por defecto es el 4444/TCP. Tampoco necesitamos ningún payload, ya va empaquetado en el ejecutable que hemos preparado. Lo lanzamos y esperamos…

Ejecutamos nuestro regalito en el Windows 7. Simplemente crea un proceso payload13.exe que no hace nada y no aparece ningún mensaje del Antivirus.

¡Tachán! Ya tenemos nuestro Meterpreter ejecutándose y controlado desde nuestra máquina.

Lanzamos el comando shell como prueba de que estamos ejecutándolo en la máquina Windows 7.

Diseñando Sistemas I: La toma de requerimientos

Antes que nada, quiero decir que este artículo como los que le seguirán en esta serie, estarán basados en la experiencia que he acumulado desde 1971, año en el que comencé a estudiar y trabajar en los sistemas de tratamiento de la información, antes de que tuviera la posibilidad de obtener una titulación oficial que entonces no existía. Reflejaré tan solo ideas generales, sin entrar en metodologías concretas, (he tenido que aprender y utilizar distintas metodologías, según la empresa para la que trabajé), sino tan solo en las prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado, la base ha sido siempre muy similar.

Una de las labores más gratificantes o frustrantes que el profesional de la informática puede llevar a cabo es el diseño de un sistema de proceso de información, tanto si es autónomo (el sistema) o forma parte de otra aplicación de mayor ámbito con la cual deberá integrarse.

Captar las necesidades del proceso, decidir cómo realizarlo y plasmar estas ideas en un diseño, tiene bastante de creativo y personal, aún cuando haya que aplicar metodologías y normas, e incluso haya que integrar otras herramientas en él. Personalmente, a lo largo de mi carrera como informático, me he sentido feliz cada vez que un sistema salido de mis manos daba el resultado esperado y permanecía activo largo tiempo sin requerir un soporte significativo o dar problemas. Debo añadir que también he tenido experiencias frustrantes (afortunadamente pocas veces), generalmente por no haber dedicado el tiempo necesario a analizar un problema y resolverlo correctamente, atendiéndolo con urgencia —y coste mínimo por supuesto—, lo que normalmente acaba volviéndose en nuestra contra, generando un problema aún mayor.

Llevo bastante tiempo sin realizar esta labor por lo que intuyo y digo “intuyo”, que las herramientas de desarrollo actuales, con bases de datos pre-definidas, lenguajes de alto nivel, etc., facilitan mucho el trabajo de desarrollo, pero estoy seguro de que sigue existiendo la posibilidad de ser creativo en la etapa de diseño, durante el proceso de análisis y definición de las necesidades del usuario final, entendiendo lo que se necesita hacer y sugiriendo soluciones, aunque sea a nivel funcional, para que orienten al equipo que después va a desarrollar estas ideas durante la programación.

Mi primera recomendación antes de diseñar un sistema es procurar comprender el proceso, pero no como algo aislado que hay que resolver sino como parte de una entidad mayor, ya sea un sistema informático más complejo o tal vez una actividad de negocio. Esto que parece obvio, no siempre se hace, porque entender el proceso es entender de qué forma parte, donde se integra, de dónde le llega la información, qué hace con ella, qué se espera obtener como resultado y dónde va a ser utilizado éste y para qué. Es decir, entender el antes y después del proceso, antes de entrar en los detalles del mismo.

Esto sin duda requerirá más tiempo dedicado tanto a la recogida de información como al análisis de la misma, añadiendo coste al proyecto, pero nos permitirá comprender ciertas particularidades del proceso exigidas no sólo por nuestro cliente, sino por las características de su negocio, por la legislación vigente o por prácticas del mercado o el entorno en el que se mueve. Con ello, además de obtener una motivación y una experiencia extra, nos convertimos en un interlocutor más efectivo frente al usuario que nos va a describir sus necesidades, en su lenguaje propio y con unos límites de visión que tal vez no nos convengan. También estaremos en condiciones de hacer preguntas de mayor calado y detectar puntos de posible riesgo o conflicto en el tratamiento de la información. Si somos capaces de hacer esto, en mi opinión, no solo podremos hacer un diseño más ajustado a las necesidades del cliente, sino que estaremos en condiciones de prevenir otras necesidades no descritas inicialmente, que se van a dar una vez puesto en marcha nuestro sistema.

El clásico “esto no me lo habías contado y no está previsto” debería quedar minimizado o anulado y por lo contrario, responder con “es fácil integrar lo que me pides” da confianza y satisfacción al cliente y crea un vínculo más sólido con su proveedor, ya que piensa que no sólo se le entiende sino que empezamos a tener una buena experiencia en su negocio y le vamos a servir de apoyo.
Con bastante frecuencia, los requerimientos de un sistema no reflejan solamente las necesidades de los procesos de la compañía donde va a ser instalado, sino que también incluye ciertas exigencias de sus clientes, principalmente de aquellos que deben seguir normativas y protocolos establecidos (clientes de la gestión y administración de la salud o de la alimentación, por ejemplo) que pueden requerir formatos de documentación específicos, con otros adjuntos y firmados que no forman parte del proceso en sí, pero que el sistema debe controlar su existencia y seguir unos ciclos específicos de aprobación, etc., y que complican bastante la forma de gestionar algo que en la empresa de al lado es bastante estándar y sencillo.

Si además, toda esa “cultura” está en la cabeza de dos o tres empleados “expertos” que la gestionan manualmente, por lo que no forma parte del flujo de información y conocimiento de la empresa, eso supone un alto riesgo para esta última, y una buena solución es diseñar un sistema automatizado y bien documentado que aporte dicha gestión de un modo ágil y claro, que pueda ser ejecutada con personal menos “culto” o bien que esa culturilla pueda divulgarse en todo el equipo de trabajo.

Plasmar los requerimientos en un documento ordenado y claro es muy importante, para presentarlo al cliente y que dé su aprobación antes de seguir adelante con el análisis funcional del sistema. Para ello, es conveniente adoptar una metodología de trabajo adecuada entre las existentes, o como mínimo adoptar un formato de documentación en el que indiquemos el nombre del proyecto, el cliente, la fecha, autor, el tema o sujeto del documento, etc. y apliquemos un código dentro de nuestra librería de documentos, para facilitar su localización, consulta y actualización. Una buena organización de la documentación es esencial para facilitar el desarrollo de cualquier proyecto.

En cuanto al mencionado incremento de coste, si no ha sido adecuadamente previsto en los presupuestos del proyecto, debería ser considerado —dentro de unos límites claro está— como una inversión de la empresa proveedora en beneficio de futuras colaboraciones con este cliente o en competiciones con otros clientes del mismo ámbito de actividad. Tener un “equipo experto” en el tema a solucionar dará un gran valor añadido a la propuesta de servicios que se presente ante cualquier otro cliente posible, además de fidelizar a los ya existentes.

Métodos de identificación

Aunque muchas cosas han cambiado en la seguridad en internet en los últimos 10 años, sin embargo otras han permanecido igual, como es el caso de la identificación mediante contraseñas alfanuméricas. Éstas siguen siendo la forma de autenticación dominante: según estudios el 97% de las organizaciones las utilizan.

Sin embargo, a pesar de ser la forma de autenticación más extendida, la identificación mediante contraseña alfanumérica tiene algunos inconvenientes bastante destacados, como son el olvido y el robo de las mismas. Los fallos en la autenticación de usuarios pueden causar muchos daños técnicos y además tener un gran coste económico. En 2007 se cuantificaron en 3200 millones de dólares las pérdidas debidas a suplantación/robo de la identidad (phishing).

Todo esto ha llevado a la investigación en formas alternativas de identificación de los usuarios, que tienen como objetivo principal evitar los problemas actuales de las contraseñas alfanuméricas y dotar a los sistemas de una forma de identificación más segura.

[Read more…]