Telecomunicaciones

Analizar las propiedades físicas de la línea o medio de comunicación y las propiedades estadísticas del mensaje a fin de diseñar los mecanismos de codificación y decodificación más apropiados.

Project Management Professional

Conocimientos, experiencia y dominio de la terminología, basándose en una conducta intachable y ética. Responsable para el buen desempeño de la gestión de proyectos.

Seguridad Informática

Se enfoca en la protección de la infraestructura computacional y todo lo relacionado con esta. Para ello existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la información.

Diseño y Herramientas WEB

Aplicaciones web que facilitan el compartir información, la interoperabilidad, el diseño centrado en el usuario1 y la colaboración en la World Wide Web.

Gestión de los Servicios

Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe jugar una papel esencial en el mismo para restaurarlo según su SLA correspondiente.

10 recomendaciones de seguridad TI que en verdad funcionan

Las amenazas a la seguridad TI evolucionan constantemente.

Es tiempo de que los profesionales de la seguridad TI agudicen su ingenio

La seguridad de la red y de los  endpoints  podrían no ser el primer lugar ha poner a prueba. Después de todo, la protección de los sistemas y los datos de la compañía debería considerar todas aquellas acciones que podrían significar riesgo. Pero las amenazas a la seguridad evolucionan constantemente, y en ocasiones uno tiene que pensar con un enfoque nuevo para mantenerse un paso delante de los ingeniosos malhechores.

Algunas veces uno tiene que parecer un poco loco.

Charles Babbage, el padre de la computadora moderna, una vez dijo “proponga a un hombre cualquier principio, o un instrumento, y aunque éste sea admirable, observará que todos sus esfuerzos se dirigirán a encontrarle una dificultad, un defecto, o alguna imposibilidad en él. Si le cuenta que hay una máquina que puede pelar una papa, le dirá que es imposible: si pela una papa frente a él, dirá que es un instrumento inútil porque no sirve para cortar en rodajas una piña”.

El mundo de la seguridad de las redes no es distinto. Ofrezca un nuevo medio de defensa TI y con seguridad experimentará resistencia hacia él. Aun así, en ocasiones, ir contra la ola del pensamiento tradicional es la manera más segura de llegar al éxito.

En ese sentido, le ofrecemos 10 ideas de seguridad que han sido -y en muchos casos aún lo son- consideradas demasiado excéntricas para funcionar pero que funcionan muy efectivamente en la seguridad de los activos TI de la compañía. Las empresas que emplean estos métodos no se preocupan de convencer o aplacar a los pesimistas. Ellas ven los resultados y saben que estos métodos funcionan, y que funcionan bien.

Técnica de seguridad No. 1: Renombrar los‘admins’

Renombrar las cuentas con privilegios a algo menos obvio que“administrador” es considerado una pérdida de tiempo,“seguridad a través de la obscuridad”. Sin embargo, esta simple estrategia de seguridad funciona. Si el atacante aún no ha penetrado su red o  host , hay pocas razones para creer que podrán discernir los nuevos nombres de sus cuentas con privilegios. Si no saben los nombres, no pueden montar una campaña de ‘adivinación’ de contraseñas exitosa contra ellos.

¿Qué más? Nunca en la historia del  malware  automatizado -las campañas que usualmente se generan contra las estaciones de trabajo y servidores- un ataque ha intentado utilizar otra cosa que no sean los nombres de cuentas incorporados. Al renombrar las cuentas con privilegios, uno puede vencer a los  hackers  y al  malware  en un solo paso. Además, es más sencillo monitorear y alertar de los intentos de  log on  en los nombres originales de las cuentas con privilegios, cuando éstos ya no se encuentran en uso.

Técnica de seguridad No. 2:Deshacerse de los‘admins’

Otra recomendación es deshacerse de todas las cuentas masivas con privilegios:  administrator ,  domain admin , enterprise admin , y todas las demás cuentas y grupos que tengan incorporados permisos privilegiados y amplios por defecto.

Cuando esto se sugiere, la mayoría de los administradores de red sonríen y protestan, la misma respuesta que los expertos en seguridad enfrentaron cuando recomendaron que se desactiven las cuentas de Administrador local en las computadoras con Windows. Luego Microsoft siguió esta recomendación y deshabilitó las cuentas de Administrador local por defecto en todas las versiones de Windows desde Vista/Server 2008 y posteriores. Cientos de millones de computadoras después, el mundo no se ha detenido.

Es verdad, Windows aún le permite a uno crear una cuenta de Administrador alterna; pero en la actualidad, los más corajudos defensores de la seguridad de las computadoras recomiendan deshacerse de todas las cuentas incorporadas con privilegios. Aun así, muchos administradores de red ven esto como una medida excesiva, una medida exageradamente draconiana que no va a funcionar. Bueno, al menos una de las empresas de la lista Fortune 100 ha eliminado todas las cuentas incorporadas con privilegios, y está trabajando sin problemas. La compañía no presenta evidencia de haber sido comprometida por una amenaza avanzada persistente ( advanced persistent threat  - APT). Y nadie se queja por la falta de acceso privilegiado, ya sea del lado de los usuarios o de TI. ¿Por qué lo harían? Nadie los está ‘hackeando’.

Técnica de seguridad No. 3: Honeypots

Los  honeypots  de las computadoras modernas nos han acompañado desde los días del “Huevo del Cucú” de Clifford Stoll, pero aún no son lo suficientemente respetados o utilizados como se debería. Un  honeypot  es cualquier activo computacional que ha sido establecido con el único propósito de recibir un ataque. Los  honeypots  no tienen un valor en la producción. Simplemente están ahí esperando, y son monitoreados. Cuando un  hacker  o un  malware  los toca, envían una alerta a un administrador de tal forma que el contacto puede ser investigado. Los  honeypots  proporcionan poco ruido y mucho valor.

Las organizaciones que usan  honeypots,  rápidamente reciben notificaciones de los ataques activos. De hecho, nada mejor que un  honeypot  para recibir alertas tempranas -excepto, claro, un grupo de  honeypots , que recibe el nombre de honeynet . Aun así, los colegas y clientes generalmente se muestran incrédulos cuando saco a luz este tema. Mi respuesta es siempre la misma: tómese un día para instalar uno, y me dice como se siente dentro de un mes. En ocasiones lo mejor que uno puede hacer es probar.

Técnica de seguridad No. 4: Usar puertos nondefault

Otra técnica para minimizar los riesgos de seguridad es instalar servicios en puertos  nondefault . Al igual que cuando se renombra cuentas con privilegios, esta táctica de‘seguridad por obscuridad’ es efectiva. Cuando las amenazas se instrumentalizan mediante gusanos, virus y otros, éstas siempre -y solamente- atacan los puertos por  default . Este es el caso de las inyecciones SQL, gusanos HTTP, descubridores SSH, y otros.

Recientemente, pcAnywhere de Symantec y Remote Desktop Protocol de Microsoft sufrieron de  exploits  remotos. Cuando estos  exploits  se convirtieron en armas, fue una carrera contra el reloj para los defensores el aplicar parches o bloquear los puertos antes de que los gusanos llegaran. Si alguno de los servicios hubiera estado corriendo en un puerto  nondefault , la carrera ni siquiera hubiera tenido que comenzar. Esto porque en la historia del  malware  automatizado, éste siempre ha atacado el puerto por defecto.

Los críticos de este modelo de defensa afirman que es fácil para un atacante encontrar a dónde se ha trasladado el puerto por  default , y es cierto. Todo lo que se requiere es un escáner de puertos, como Nmap, o una aplicación que encuentre su huella, como Nikto, para identificar la aplicación que está corriendo en el puerto  nondefault . En realidad, la mayoría de los ataques son automatizados usando  malware , el cual -como se dijo- solo atacan los puertos por  default , y la mayoría de los hackers  no se toman la molestia de buscar los puertos nondefault . Ellos encuentran muchas ‘frutas a la mano’ como para molestarse con un esfuerzo adicional.

Hace años, como experimento, trasladé mi puerto RDP del 3889 al 50471 y ofrecí una recompensa a la primera persona que encontrara el nuevo puerto. Dos personas descubrieron el puerto, lo cual no me sorprendió; ya que les dije lo que hice, es fácil descubrir el lugar correcto. Lo que me sorprendió es que decenas de miles de potenciales  hackers , que escanearon mi sistema buscando el nuevo puerto usando Nmap, no se dieron cuenta que Nmap, si se le deja en su configuración por  default , no busca en los puertos  nondefault . Esto demostró que realizando un simple cambio de puerto, uno puede reducir significativamente los riesgos.

Técnica de seguridad No. 5: Instalar en directorios personalizados

Otra defensa de ‘seguridad por obscuridad’ es instalar las aplicaciones en los directorios  nondefault .

Esto no funciona tan bien como solía hacerlo, dado que la mayoría de los ataque se producen en la actualidad a nivel del archivo de la aplicación, pero aún tiene algún valor. Al igual que las recomendaciones anteriores, instalar las aplicaciones en directorios personalizados reduce los riesgos -los  malwares automatizados casi nunca buscan en otro lugar que no sea en los directorios por  default . Si el  malware  se encuentra en la capacidad de explotar su sistema o aplicación, intentará manipular el sistema o aplicación buscando los directorios por default . Instale su sistema operativo o aplicaciones en un directorio  nondefault  y engañará al código malicioso.

En muchos de mis  honeypots , instalo el sistema operativo en las carpetas  nondefault , digamos en C:/Win7 en lugar de C:/Windows. Generalmente creo carpetas ‘falsas’ que simulan ser las verdaderas, cuando mis computadoras son atacadas, es fácil encontrar copias completas y aisladas del  malware  en la carpeta C:/Windows/System32.

Cambiar las carpetas por  default  no tiene el impacto que las otras técnicas mencionadas aquí, pero engaña a gran parte del malware , y eso significa reducir el riesgo.

Técnica de seguridad No. 6: Tarpits

Mi primera experiencia con un producto tarpit fue LaBrea Tarpit. Fue desarrollado durante la aparición del gusano Code Red IIS del 2001. Los gusanos se replican en cualquier sistema que les permita sus capacidades de  exploit . LaBrea trabajó respondiendo a los intentos de conexión para direcciones que aún no se habían asignado a máquinas legítimas. Luego respondería y le diría al gusano que se conecte, luego gastaría el resto del tiempo intentando ralentizar al gusano, usando varios trucos del protocolo TCP: timeouts  prolongados, retransmisiones múltiples, y cosas por el estilo.

En la actualidad, muchas redes -y  honeypots - tienen la funcionalidad tarpit, la cual responde a cualquier intento de conexión no válido. Cuando intenté penetrar estas redes a manera de test, mis ataques y ataques de escaneo de redes se ralentizaron -no se podían usar, lo cual era exactamente el propósito. Lo único malo: los tarpits pueden causar problemas con los servicios legítimos si los tarpits responden prematuramente si el servidor legítimo está lento. Recuerde afinar el tarpit para evitar falsos positivos y disfrute de los beneficios.

Técnica de seguridad No. 7: Análisis del flujo de tráfico de la red

Con la abundancia de  hackers  extranjeros, una de las mejores formas de descubrir el robo masivo de los datos es mediante un análisis del flujo de la red. Para ello se dispone de software gratuito y comercial que mapea los flujos de la red y establece líneas de base de lo que debería estar transitando. De esa forma, si ve repentinamente que cientos de gigabytes de datos están saliendo al extranjero, uno puede investigar. La mayoría de los ataques APT que he investigado podrían haber sido reconocidos con meses de anticipación, si la víctima hubiera tenido una idea de hacia donde se deberían dirigir los datos.

Técnica de seguridad No. 8: Salvapantallas

Los salvapantallas protegidos con contraseña son una técnica muy simple para minimizar el riesgo a la seguridad. Si el dispositivo se encuentra inactivo por mucho tiempo, es bueno tener un salvapantallas con contraseña. Criticado por parte de los usuarios que los consideran una molestia para su trabajo legítimo, ahora son un producto principal de todos los dispositivos de computación, desde  laptops  hasta teléfonos móviles.

Recuerdo una ocasión en la que dejé mi teléfono inteligente en el taxi, luego de discutir con el taxista por el pago del servicio. Inmediatamente consideré perdido el teléfono. Estaba preocupado porque acababa de chatear con mi esposa, así que el teléfono estaba abierto y expuesto. Guardaba mis contraseñas y otra información personal en el teléfono, aunque con algunas modificaciones de tal manera que si alguien las veía no sabría directamente las contraseñas o números. Estaba preocupado por la información de contacto de mi esposa, hijas, y otros seres queridos. Afortunadamente, sabía que mi salvapantallas se activaría pronto. Nunca encontré el teléfono, pero tampoco recibí llamadas extrañas y cobros del mismo tipo.

Técnica de seguridad No. 9: Deshabilitar la navegación por Internet en los servidores

La mayor parte del riesgo de las computadoras se debe a las acciones que realizan los usuarios en Internet. Las organizaciones que deshabilitan la navegación en Internet -o todo el acceso a Internet de sus servidores que no necesitan las conexiones- reducen de manera significativa el riesgo de ese servidor ante el código malicioso. Uno no quiere que los administradores estén revisando su correo o posteando en las redes sociales mientras esperan a que baje un parche. En cambio, bloquee lo que no se necesita. Para las empresas que usan servidores Windows, considere deshabilitar el UAC ( User Account Control ), ya que el riesgo para la  desktop  que ese UAC minimiza no se produce. El UAC puede causar algunos problemas de seguridad, así que deshabilitarlo es una buena medida para muchas organizaciones.

Técnica de seguridad No. 10: Desarrolle pensando en la seguridad

Cualquier organización que produce código a la medida debería integrar prácticas de seguridad en su proceso de desarrollo, asegurándose que la seguridad del código será revisada e incorporada desde el primer día de cualquier proyecto de creación de código. Hacerlo reduce sin lugar a dudas el riesgo de que aparezcan  exploits  en su entorno.

Esta práctica, en ocasiones conocida como SDL ( Security Development Lifecycle ), difiere de educador en educador, pero generalmente incluye los siguientes principios: el uso de lenguajes de programación seguros; el no uso de funciones de programación que se saben inseguras: revisión del código; testeo de penetración; y una lista de otras mejores prácticas que apuntan a reducir la probabilidad de producir código con bugs .

Microsoft, por ejemplo, ha podido reducir de manera significativa el número de  bugs  de seguridad en todos los productos que se despachan desde la institución del SDL. Ofrece lecciones aprendidas, herramientas gratuitas, y guías en su sitio  web  de SDL.

Gracias a: Roger A. Grimes, InfoWorld (EE. UU.)

KPI - No se puede evaluar lo que no se puede medir

No se puede evaluar lo que no se puede medir

No se puede evaluar lo que no se puede medir

...y, para poder medir un proceso se debe contar con algún tipo de indicadores.
Los KPI ("Key Performance Indicators", o indicadores claves del desempeño) son métricas orientadas a cuantificar el grado de cumplimiento de un objetivo de negocio, por parte de un proceso.
La mayoría de las métricas que se utilizan en seguridad desafortunadamente no cumplen con esta definición. Típicamente usamos indicadores de efectividad técnica u operativa que no podemos relacionar directamente con el cumplimiento de objetivos de negocio.
Además, la mayoría de estos indicadores son específicos para cada control (no describen un proceso, que es otro requerimiento para considerar como clave a un indicador).
Algunos ejemplos de indicadores que usamos típicamente en seguridad:
  • Número de ataques prevenidos/detectados (FW, IPS, etc.)
  • Número de programas maliciosos detectados (antivirus, antispyware, etc.)
  • Número de incidentes de seguridad reportados y atendidos (equipos de respuesta ante incidentes)
  • Número de actualizaciones de seguridad
  • Tiempo de respuesta para atender incidentes
  • Tiempo promedio de distribución de parches de seguridad
Como referencia, en KPI library pueden encontrar cientos de indicadores adicionales de diversos tipos. (Ej. information+security, Outsourcing)
Las 2 preguntas que queremos responder en este artículo son: 
  • ¿Cuáles de estos indicadores técnicos realmente nos sirven? 
  • ¿Cómo podemos generar indicadores de seguridad de la información, que sean realmente claves para el negocio, a partir de ciertos indicadores técnicos?

Indicadores técnicos

Debemos distinguir entre indicadores técnicos que son útiles y aquellos que son meramente informativos y no aportan datos concretos sobre la efectividad de un control.
Los indicadores que son útiles miden cosas que están bajo nuestro control y no dependen del entorno.
Ejemplos de malos indicadores técnicos:
  • Controles:
    • Número de virus detectados
    • Número de cambios en configuración
    • Número de parches aplicados en el mes
    • Número de intentos de ataque detectados
    • Número de cintas de respaldo generadas en un mes
  • Procedimientos:
    • Número de solicitudes atendidas
    • Horas invertidas en solución de problemas
Ejemplos de buenos indicadores:
  • Controles:
    • Porcentaje de virus detectados y eliminados oportunamente
    • Porcentaje de ataques prevenidos
    • Porcentaje de parches críticos aplicados en el mismo mes de su liberación
  • Procedimientos:
    • Tiempo promedio de restauración de un sistema a partir de un
    • Tiempo de respuesta promedio para solución de un incidente
    • Costo promedio de solución por incidente (horas hombre + recursos materiales)
De los ejemplos anteriores, es claro que los buenos indicadores son el resultado de una ponderación entre acciones ejecutadas correctamente y acciones incorrectas (siendo las acciones incorrectas la suma de falsos positivos y faltos negativos). También son buenos indicadores las métricas de niveles de servicio (tiempo) y costo, relacionadas únicamente con variables locales.

Manejo de indicadores técnicos
Es claro que generar cientos de indicadores a nivel técnico no es sinónimo de un mejor control o de mayor precisión. Tenemos que utilizar la cantidad mínima necesaria de indicadores técnicos para armar los indicadores clave de despempeño que requiere el negocio, pero además tenemos otros problemas:
  • La medición de eventos prevenidos - medir eventos reales (incidentes) con un impacto al negocio es relativamente fácil. Basta con revisar la lista de reportes de la mesa de servicio, pero existen una gran cantidad de controles que no documentan eventos prevenidos con éxito (Ej. ¿cuántos incidentes previno el candado de una laptop? ¿Cuántos incidentes previno la desactivación de servicios no indispensables en un servidor?
  • El empalme de controles - Cuando hay controles que trabajan en conjunto (en diferentes capas usualmente) es difícil medir la eficacia de cada uno de ellos. Por ejemplo, el hecho de que un firewall por su configuración haya evitado que cierto tráfico de propagación de un virus nuevo pasara hacia la red interna, no asegura que un antivirus o un IPS detrás de este firewall hubieran podido actuar eficazmente sobre este evento.
Si no podemos medir con toda certeza falsos positivos y negativos, no podemos determinar un indicador de efectividad a nivel de un control particular.

Por otro lado, si no podemos saber con certeza la reacción de un control ante un evento que en teoría debería prevenir pero que detuvo otro control, tampoco tenemos métricas de falsos positivos y negativos confiables.

Parecería que es imposible poder medir la eficacia de todo tipo de controles y procedimientos que tenemos, sin embargo ¿realmente necesitamos llegar a este nivel de detalle para generar indicadores clave de desempeño?

La respuesta es no. Sin embargo, es importante aclarar que los indicadores técnicos y operativos no son inútiles y debemos generar todos aquellos que se puedan, para cada control y procedimiento.

La diferencia es que no los vamos a usar para generar los indicadores clave, sino como herramienta de diagnóstico para determinar qué controles y procedimientos debemos reemplazar cuando los indicadores clave de desempeño nos indiquen que debemos mejorar algo.

Indicadores clave y técnicos que requerimos
Sólo necesitamos 2 tipos de indicadores (uno técnico y otro de negocio) para generar los indicadores clave:
  • Costo estimado de la solución por día = (Costo de la solución de seguridad anualizado + costo de incidentes reales en el año) / 365
  • Costo anualizado incluye:
  • Costo de controles y su mantenimiento +
  • Sueldos de personal a cargo +
  • Costo de servicios tercerizados
  • Costo de incidentes reales en el año incluye eventos de pérdida documentados con costos asociados al negocio
  • Costo promedio por incidente (sin considerar controles)
  • Es el costo de un evento antes de considerar controles (los controles afectan probabilidad de ocurrencia o impacto en este costo), es decir, el costo puro como lo percibe el negocio
  • Se recomienda separar por tipo de evento:
  • Integridad
  • Confidencialidad
  • Disponibilidad
  • Autenticidad
  • Si no se tienen datos históricos suficientes para determinar este dato, se pueden usar promedios de la industria, aunque evidentemente puede haber variaciones significativas con respecto al negocio (ej. el estudio de costos por fuga de información del Instituto Ponemon).
Dado que no podemos asegurar el contar con indicadores de eficacia para todos los controles, vamos a estimar el costo de protección por evento y compararlo contra el costo promedio de cada evento.

En este caso, es razonable asumir que se puede generar un evento potencial en un día cualquiera del año (no sabemos cuántos en el año pero asumimos que al menos se generará uno por año) y que el costo de protección de un día es cercano al costo de protección de un evento, considerando que para la mayoría de los casos, las empresas agrupan eventos  de un mismo tipo en un incidente por día; es decir, si por ejemplo no tuviéramos un antivirus instalado y sufriéramos en consecuencia la caída de varios equipos por infecciones, la mayoría de las empresas tratarían la situación como un único incidente en el mismo día (con varios elementos afectados), en vez de distinguir entre los eventos generados por cada tipo de malware que participó.

Dado lo anterior, también es razonable asumir que el costo promedio de protección por un día debería ser menor al costo promedio de un tipo de incidente determinado. Como seguramente ya habrán adivinado, este balance constituye nuestra propuesta de indicador clave de desempeño:
  • KPI para una solución de seguridad = costo estimado de la solución por día - costo promedio de incidente
Para ser costo-efectiva, la solución deberá producir un resultado negativo en el KPI.

Indicades de Gestion - norma UNE 66175:2003

Indicades de Gestion - norma UNE 66175:2003

Indicadores de Gestión (norma UNE 66175:2003)

Los indicadores de gestión proporcionan valiosa información  precisamente sobre dicha gestión, así como para la toma de decisiones. En  cualquier escrito acerca de indicadores, es común ver la frase “la calidad de  las decisiones está directamente relacionada con la calidad de la información  utilizada”. Gran Verdad
  Por este motivo, la gestión de los indicadores es factor  vital para el correcto desarrollo de cualquier sistema de gestión, haciendo  extensiva la frase a Sistemas de Gestión de Seguridad de la Información ISO  27001, de Calidad ISO 9001, Ambiental ISO 14001, de Seguridad y Salud  Ocupacional OHSAS 18001, Seguridad Alimentaria ISO 22000.

Para el correcto diseño de un Sistema de Indicadores, debemos  partir de una serie de datos y conceptos.

Para empezar, deberíamos determinar:
  • Áreas y/o  líneas principales de actuación de la organización 
  • Necesidades  o requisitos de la misma 
  • Indicadores/métricas  preexistentes 
  • Cuadros  de mando preexistentes 
  • Feedback  de la toma de decisiones respecto de los indicadores implantados 
  • Otros
Partiendo de estas entradas, las cuáles conforman la base de  desarrollo o despliegue de nuestro sistema de indicadores, debemos establecer  el marco en el que tendrán desarrollo los mismos, estableciendo la relación  entre los objetivos, los indicadores y el propio cuadro de mando.
 En la etapa de diseño, tendremos en cuenta, la definición de  todos los parámetros vinculados con la definición del mismo, así como las  tareas a acometer para su formalización e integración en el funcionamiento  normal de la organización.
  • Denominación  del indicador 
  • Temporalidad  asociada: diaria, semanales, mensual, anual 
  • Medio de  recolección de datos/Fuentes de información 
  • Metodología  de cálculo: %, ratio, conteo 
  • Unidad utilizada:  ítems, S/, $, horas, 
  • Propietario  y otras responsabilidades asociadas: recogida, análisis, comunicación 
  • Umbrales  y objetivos: límite inferior y/o superior, objetivos 
  • Forma de  representación: gráficos, diagramas, colores asignados, 
  • Persona  que lo aprueba
Una vez en fase de implantación, habrá que impartir la  formación necesaria a todas las personas relacionadas con la captación,  tratamiento y mantenimiento de los datos que vamos a analizar para la toma de  decisiones. Aquí es un factor muy importante el motivar y fomentar la toma de  conciencia de los implicados con el sistema de indicadores y sus prácticas. De  nada sirve tener un muy buen sistema conceptual, si luego las prácticas  asociadas a todo el proceso de gestión de un determinado indicador no se  desarrollan conforme a lo planificado.
Tras la implantación, sólo falta analizar la bondad del  indicador a partir de parámetros como la satisfacción de lo usuarios y la  calidad de la toma de decisiones en función de cómo afectan al desarrollo de  una determinada actividad, área de negocio, línea de actuación, gama de  productos, etc.
Siempre que hablamos de indicadores surge el término Cuadro  de Mando. Mucha gente se pregunta realmente qué es un cuadro de mando (Balanced Scorecard). Un cuadro de mando es una herramienta de gestión  ampliamente utilizada, que facilita de sobremanera la toma de decisiones en los  estamentos aplicables de cada organización. Básicamente consiste en recopilar  un conjunto coherente de indicadores para mostrar una visión clara de cómo  funciona la organización en su conjunto o un determinado área en particular.  Con los resultados obtenidos, se facilita la toma de decisiones respecto de los  mismos, así como permite focalizar los recursos necesarios para solventar  posibles desviaciones de funcionamiento de determinados procesos, sobre todo,  alineado con la estrategia de la organización.

¿Qué características tienen los indicadores?

Permiten analizar información de un área, actividad, …,  importante o crítica
 
  • Están directamente relacionados con el concepto evaluado 
  • Son representativos del criterio a medir 
  • Suministran resultados cuantificables: dato numérico o  valor de clasificación
  • Beneficio de su uso > inversión para captura y  tratamiento de datos
  • Son comparables en el tiempo, proporcionando evoluciones o  tendencias
  • Deben proporcionar confianza sobre la validez de las  medidas obtenidas
  • Deben ser fáciles de establecer, mantener y utilizar
  • Deben ser compatibles con el resto de indicadores de la  organización

  • Obsolescencia de indicadores Un indicador puede pasar a ser obsoleto cuando:
  • Se han modificado los objetivos de la organización o algún  parámetro estratégico
  • Se han modificado propietario, cliente del indicador o el  cuadro de mando
  • Se han evolucionado la expectativas
  • La naturaleza de lo que mide ya no es significativa o no procede: no es útil


  •