9 metas de todo gestor de proyectos

Cierto, lo primero que debemos hacer los gestores de proyectos es atender a las tres restricciones clásicas.

Así, deberíamos prestar fina atención al plan que establecimos para monitorear el cronograma con el fin de mantenerlo al día, y registrar lo planeado versus el progreso realizado y actuando rápido ante cualquier desviación. Es interesante ver esto desde la óptica de Deming.

Sería conveniente identificar (bueno, lo mejor posible) el real costo total de propiedad de un proyecto, relacionado con el personal (colaboradores) interno y externo, recursos materiales, proveedores, entre otros puntos a considerar, y buscar ‘balancear’ el gasto total (rastreando cualquier desviación del plan) para que no se nos escape de las manos el presupuesto asignado al proyecto –al menos no tanto.

Cierto, los cambios son inevitables –y hasta buenos, pero al menos tengamos al principio un conjunto de requisitos completo, claro, entendido, aceptado, con criterios claros de cómo estos requisitos serán evaluados y aceptados. Entendamos que hay que saber decir sí a la persona y no a la tarea. Evaluemos antes de señalar opciones. Todos los que deciden deben tener claro por qué y cuándo deciden por una alternativa.

No olvidemos el mantra “reunirse con todo el equipo y establecer metas por adelantado”. Es buena idea además porque podríamos establecer etapas para un proyecto “grande”, además de priorizar las tareas necesarias para cada etapa.

Nuestro cliente debe estar y quedar siempre contento con nuestro trabajo –digo, con el avance del proyecto. Seamos transparentes. Entendamos las expectativas de los clientes, stakeholder y sponsors. La apertura y la honestidad son siempre las mejores herramientas para lidiar con las expectativas de las personas. Cierto, debemos buscar una mejor comunicación y entendimiento con las personas, en general.

Y no olvidemos a nuestro equipo de trabajo. Siempre se nos repite que, con un equipo feliz y motivado, con el cual, y dentro del cual existe una comunicación fluida y transparente, puedes lograr cualquier cosa. Bueno, también sabemos que esto empieza por tener al equipo correcto, con el perfil y competencias correctas para la tarea. Esto es, los recursos humanos con las capacidades adecuadas. Sigue el que los miembros se sientan reconocidos y que forman parte de algo importante, con un objetivo importante –que sería ideal que lo hagan suyo. No trabajo cargando piedras para construir la catedral – construyo mi catedral.

Recordemos que debemos manejar al triada personas-procesos-tecnología. Así, es necesario identificar qué se necesita mejorar, adicionar o utilizar, para invertir en la medida que sea necesario, de acuerdo con la envergadura del proyecto y su necesidad de comunicación -o interrelación.

Lo anterior implica que debe haber una base sólida para trabajar, y esta viene construida desde la organización, no por independientes interesados con brío y ganas de hacer bien las cosas. Es necesario que exista una correcta identificación, evaluación y priorización de proyectos que aporten valor real al negocio –conociendo todos cuáles son las metas y objetivos que se espera alcanzar, y que se establezcan correcta y oportunamente los roles y las responsabilidades, que exista estandarización para un mejor y pleno entendimiento de por qué se hacen (o necesitan hacer) las cosas, con políticas documentadas, claras y consistentes, y que se cumplen, apoyadas por las normativas correspondientes, y que se cuenten con los recursos y capacidades necesarias para llevar a cabo estos proyectos.

Sabemos que debemos gestionar los riesgos. Así, es necesario realizar el control correspondiente a los parámetros del proyecto, monitorizar el avance, y medir. Debemos poder ser capaces de definir, capturar y rastrear las métricas que rodean cada proyecto. Nos ayudamos con las lecciones aprendidas de experiencias pasadas, establecemos líneas base, documentamos (¿lo hacemos?). Debemos medir el progreso.

Algunas ‘mejores prácticas’ de TI para el fracaso –y algunas ‘mejores prácticas’ para evitarlo

Así es, una mejor práctica no es una receta de cocina. La preparación que hagamos de un ‘platillo’ y su resultado depende de muchos factores referidos a las herramientas, nosotros mismos como çocineros’, de los ‘comensales’ y su entorno.

Una real mejor práctica es considerar la preparación del ‘platillo’ para garantizar su resultado. Así, intervienen el ecosistema tecnológico en operación –moderno, vigente, legacy, integrado, interconectado- plataforma tecnológica e infraestructura de soporte, la cantidad necesaria de especialistas con el perfil apropiado, la experiencia, competencias (conocimientos, aptitudes, actitudes), orientación técnica o de gestión, requisitos del negocio, apetito de riesgo, intereses personales, los recursos para la producción del servicio (en adición al ecosistema tecnológico y el personal de apoyo, se necesita información, aplicaciones, recursos financieros) y capacidades para asegurar el rendimiento esperado (modelo de gestión, organización implementada, procesos establecidos, conocimiento gestionado), ambos activos de servicio necesarios para entregar el servicio con el valor esperado (con la utilidad y la garantía de rendimiento esperada), aparte claro del presupuesto, coyuntura socio-económica, entorno regulatorio y legal, mercado (cultura, exigencias, demografía, restricciones, gobierno, importación/exportación).

Estamos propensos a decir sí o no a todo y esto varia como buena práctica de acuerdo a la cultura y clima organizacional, buscando no quedar mal –aunque esto es lo que ocurre al no cumplir si accedemos o no entregar si era posible y alguien después nos lo hizo ver.

Una real buena práctica es explicar qué debe hacer para satisfacer las solicitudes, luego de realizar el análisis previo correspondiente. Lo que sigue será una conversación más que una excusa.

Tampoco es una buena práctica blandir que se cumple con el acuerdo de nivel de servicio (SLA) aceptado por el cliente, o con el nivel de servicio organizacional (OLA) requerido y comprometido por las áreas internas de la empresa, cuando es evidente la existencia de reclamaciones al respecto, y tratamos de minimizar el impacto haciendo bromas a costa de clientes, usuarios –o peor, de nuestro soporte- ‘inexperto’. Puede haber un contrato en ambos casos, pero no es bueno mantener las relaciones a distancia.

Una real buena práctica es identificar y enfrentar cambios –incluso sustanciales, investiguemos con transparencia. Recuerde que las relaciones requieren confianza, que la confianza no sucede a menos que reconozca a los colegas y clientes como personas reales que, si les gusta, trabajarán con usted para arreglar lo que falla y que el propósito de los contratos no es definir las relaciones -es definir lo que sucede cuando no hay confianza y algo va seriamente mal.

Tomamos como buena práctica poner nombre a nuestros proyectos, desde hace poco incluso, no siempre ha sido así. Pero esta buena práctica de la dirección de proyectos la utilizamos para nombrar el proyecto como una implementación de software (y nos preocupamos de que el producto software funcione) y no como los resultados esperados por el negocio (no establecemos los requisitos y criterios de validación necesarios para el entregable). El trabajo de TI se realiza cuando el software satisface los requisitos y cumple con las especificaciones –se ha hecho el aseguramiento y control de calidad apropiados al producto software, su verificación. Entonces sabemos quién es culpable de no alcanzar los resultados esperados por el negocio ¿verdad?

Una real buena práctica implica identificar al real sponsor del proyecto. Me refiero no al que ha sido nombrado (otra ‘buena práctica’), sino al que le interesa el éxito del proyecto porque su reputación está en juego y actúa en beneficio del negocio, y no asume el encargo sólo por intereses personales. Otra es designar correctamente a alguien realmente encargado de realizar las validaciones oportunas, correctas y apropiadas.

Insistir en un retorno de inversión de la plataforma actual al instaurar la buena práctica del gobierno de TI es también una perjudicial para los proyectos donde la tecnología puede ayudar a los departamentos de negocios a ofrecer mejores resultados más rápido, o para aquellos proyectos que buscan ayudar a impulsar la satisfacción del cliente.

No podemos discutir que estos proyectos son críticos, por lo que una real buena práctica es que se necesita establecer correctamente los casos de negocio oportunos, necesarios y apropiados, y la organización debe implementar los cambios que sean identificados con prontitud.

El aumento de la eficacia de la misión y la eficiencia operativa son beneficios clave que se pueden lograr con el cloud computing. Recordemos la definición del NIST. Pero aplicar una estrategia al respecto es otra cosa, considerando por supuesto la seguridad en la nube. Tomamos como buena práctica la mera adopción de una solución comercial enfocada en IaaS, PaaS o SaaS. Sí hay orientaciones al respecto, pero dependerá de cada organización su definición y el éxito de su implementación ya que se deberá mantener las evaluaciones tecnológicas y las inversiones alineadas con las estrategias empresariales. Es una buena práctica reutilizar el recurso humano (exigirle más, por decirlo amablemente), pero debemos considerar que, probablemente, se requiera una reorganización de la organización de TI para ofrecer mayor agilidad empresarial y soporte a iniciativas empresariales clave.

Es una real buena práctica recordar que el ser humano es adaptable pero no es una máquina multitarea y tiene dignidad. Entonces conviene planificar –una buena práctica que muchas veces olvidamos por las presiones del mercado. Una buena planificación es muy importante porque en ella establecemos roles, responsabilidades, alcance del modelo de despliegue y servicios a emplear o entregar, controles, aspectos de diseño y de operación (que seguramente será necesario afinar), cumplimiento regulatorio y legal, integración de tecnología legacy con la nueva, cargas de trabajo, procesos establecidos, exposición al riesgo o apetito de riesgo, sponsor (real), ámbito de influencia, gobernabilidad, plazos, presupuestos, valor real para el negocio considerando las inversiones con base en su estrategia de negocio digital, entre otros muchos factores a considerar.  Otra real buena práctica es que todos los proyectos que se lancen deberían estar totalmente equipados, con “personal completo”, lo que significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Una buena práctica es emplear métodos ágiles, pero el pretender combinarla con la premisa de abaratar costos ya no lo es. La combinación es factible pero complicada en su control y gestión, y hasta contraproducente en cuanto a resultados esperados. Esto sólo si hablamos de contar con recursos y capacidades internas al país (on-shore); sin hablar de los recursos y capacidades que podrían verse interesantes fuera del país (off-shore).

Una real buena práctica es realizar una apropiada planificación tras reconocer que están implicados diferentes aspectos, no sólo el costo del recurso humano con el perfil adecuado, sino los costos de la tecnología a emplear y los mecanismos de seguridad necesarios, así como aspectos de locación, demográficos, culturares, idiomáticos, entre muchos otros.

Seis factores críticos para crear una mejor estrategia de seguridad de TI

¿Qué necesitamos para establecer una hoja de ruta funcional de la seguridad de las TI de la empresa?

Recordemos que un solo tipo y un solo nivel de seguridad de la información podría no ser suficiente para una determinada organización. ¿Qué modelo de defensa en profundidad adoptaría, de entre los varios que existen? Tampoco debemos olvidar la estrategia a seguir si ocurriera alguna brecha en esta seguridad de la información.

Pero, debemos empezar, y lo hacemos de la siguiente manera:

  1. Identificar, clasificar, y etiquetar los recursos, los activos de información, considerando su importancia –o implicancia en los procesos de la organización, ya sean estos recursos físicos o virtuales, tangibles o intangibles.

Debemos responder con certeza el por qué debo considerarlos.

¿Convendría que los mismos sistemas que se han puesto en marcha se actualicen automáticamente en una base de datos ad-hoc a medida que cambia el inventario de recursos?

Las organizaciones deben tener pleno conocimiento de lo que tienen, valorar lo que tienen y lo que no pueden permitirse perder, además de crear un plan integral para proteger estos activos críticos.

Tendríamos, entonces, que pensar en un conjunto automatizado de herramientas para rastrear y clasificar los recursos.

  1. Proteger el acceso a los recursos, tratarlos conforme a su clasificación y prioridad establecida, de acuerdo a su impacto en el negocio (las consecuencias).

Claro, tenemos que sincerar el cómo realizaremos la protección para lo cual seguramente necesitaremos realizar primero un análisis de brecha. ¿Hemos realizado nuestro FODA?

Consideremos las nuevas tendencias para crear valor de TI, e incluso de los usuarios al emplear la tecnología como shadow IT o BYOD.

Tendríamos, entonces, que establecer una línea base correcta y sincerada –de todo, sin olvidar o menospreciar los recursos y capacidades existentes, desde el punto de vista del valor que se espera del servicio de TI.

El intercambio de información –correcta, completa, contextual, oportuna, clara- se vuelve crítico.

  1. Detectar amenazas y ataques, considerando el triángulo procesospersonas-tecnología, identificando riesgos en las operaciones que es donde se provee el valor de un servicio.

Tendríamos, entonces, que entender y asegurar que todos en la organización tengan claro que la detección de amenazas (un sospechoso siguiéndote a tu casa –bueno, tal vez una amenaza algo más sofisticada, especializada, escalable -¿que afecte la privacidad?, ¿porque el enemigo está adentro?), detección de vulnerabilidades (una ventana abierta –situación que se advierte con un escaneo de vulnerabilidades [y no debemos remitirnos solamente al perímetro]), y detección de ataques (el sospechoso metiéndose a tu casa por la ventana abierta) son tres cosas distintas.

De hecho, es crucial el dominio del tema, la provisión de la tecnología apropiada, y hacer y dejar hacer.

¿Recordamos los honeypot? De repente ya hemos sido víctimas de un hacker y aún no lo sabemos.

  1. Responder a las amenazas y ataques, considerando que posiblemente requiramos apoyo externo o una mayor capacitación y experiencia internas.

¿Cuáles serían las estrategias que adoptaríamos?

Tendríamos, entonces, que tomar medidas proactivas sobre un riesgo identificado y preparar las reactivas (de acción inmediata ante la ocurrencia del evento) –evitando acciones bomberiles.

Las medidas proactivas deberían ser pensadas, planeadas, diseñadas, implementadas, probadas, afinadas, y con responsabilidad asignada, con recursos y capacidades presupuestados, que den cumplimiento a normas internas y/o legales, que busquen evitar deudas, multas, pagos no presupuestados, litigios, pérdida de confianza y clientes, daños a la reputación y pérdida de confianza de las partes interesadas, publicidad negativa y pérdida de activos, entre otros aspectos negativos.

Es decir, una verdadera proactividad en una empresa con alto nivel de madurez, que está preparada para el cambio.

Realizar lo importante para evitar [en lo posible] las emergencias –o, al menos, reducir su frecuencia o impacto.

Ciertamente el error humano sigue siendo una amenaza para la seguridad, pero si trabajamos la cultura organizacional seguramente podremos compensar algunos riesgos de seguridad y privacidad de la información empresarial –los internos a la organización, por lo menos, concientizar al usuario.

  1. Es claro entonces que la educación en ciberseguridad debe ser parte integral de la cultura del lugar de trabajo, es hacer que la ciberseguridad sea tarea de todos. Sabemos que esta educación en ciberseguridad no significa asistir a un [solo] curso o seminario –por único que sea en su género, significa hacer de la seguridad una iniciativa cultural colaborativa y continua.

Es ayudar a todos en la empresa a comprender que los ciber delincuentes representan una amenaza no sólo para la empresa, sino también para ellos y sus familias, también (filtración de datos personales, por ejemplo, y las posibles amenazas que esto conlleva).

Sin embargo, cuando ocurra una brecha de seguridad, evitemos actitudes incorrectas en un líder o equipo de infosec porque pueden resultar en una peor violación de privacidad / seguridad y en una afectación negativa a la moral y motivación en el entorno laboral –lo que, potencialmente, podría conducir a la aparición de más riesgos o a elevar la graduación de los existentes.

La importancia de tener una actitud positiva y fuerte de seguridad y privacidad es tal que tanto los líderes como los empleados deben ver la privacidad como un valor que desean experimentar, promover, proteger y formar.

  1. Mejorar la analítica (para una mejora continua de todo el proceso).

Tendríamos, entonces, que realizar una labor analítica de predicción, porque nos dice dónde reforzar la protección –un poco de inteligencia de negocio siempre ayuda. Lo que implica un estado de cambio constante en los servicios y su gestión, lo que implica además gestionar proyectos.

Todo lo anterior es una tarea realizada de forma periódica (¿una auditoría particular o integrada?) o por demanda del mercado (¿tal vez necesidad?), siempre en evolución (nuevos hallazgos de día-cero, ahora además con la IoT –agregamos complejidad a lo complicado), un espacio, una oportunidad para mejorar.

Sigamos el ciclo de Deming, de mejora continua.

Tengamos presente que hemos pasado de un modelo donde se hacía hacking por diversión o fama, a la ciberguerra propiamente dicha, con objetivos claros y concretos, como destrucción, negación de un servicio, destruir la imagen de una empresa, incluso de monetizar la información obtenida.

 

Cómo crear un plan contra violación de datos en 9 pasos

Cómo crear un plan contra violación de datos en 9 pasos

Primero tengamos presente que se pueden considerar varios escenarios posibles en un plan contra violación de datos.

Esto porque no podemos anticiparnos a todas las situaciones posibles en que un determinado hackeo se puede desarrollar, y aun así este plan debe ser flexible, como un planeamiento para la recuperación de desastres y planificación de continuidad de negocio (la colaboración en lugar del aislamiento) –y veremos que es muy parecido. Interesante, varios proyectos pueden salir de este esfuerzo.

De hecho, conviene realizar un análisis de los procesos de negocio y las necesidades de continuidad, sin olvidar las necesidades de seguridad de la información, algo que cada empresa debe emprender, y dependerán de los objetivos de la organización sobre el punto de recuperación (RPO) y el tiempo de recuperación (RTO).

Bueno, al grano –y con anticipación porque es importante, de modo que podamos reducir las urgencias o el riesgo durante las urgencias.

  1. Sabemos que debemos empezar con una evaluación de riesgos, para priorizar qué sistemas recuperar y restaurar primero (establecer los componentes esenciales –inventario de por medio del hardware necesario y del software requerido para restaurar la producción; los datos, su tipo y sensibilidad, almacenado/procesados/transportados haciendo uso de estos componentes) –porque ponernos a pensar durante la emergencia podría ser contraproducente. Conviene realizar un análisis de impacto sobre el negocio (BIA) para identificar los procesos críticos (con sus procedimientos por supuesto) y priorizarlos de acuerdo con su impacto en la organización.
  2. No olvidemos implementar controles preventivos (con sus procesos estandarizados, normalizados, documentados), como primer paso tras analizar las brechas, de seguridad de la información, y de recursos y capacidades existentes (financieros, organizacionales, de personal, competencias, experiencia, entre otros).
  3. Conviene establecer umbrales y adecuarlos a los niveles correspondientes de respuesta que hayamos establecido –o que podamos establecer, así como los criterios de evaluación correspondientes al tipo de datos que se verían comprometidos, con base en nuestros recursos y capacidades internos o los que podamos conseguir.
  4. Así como los médicos en la sala de urgencias seleccionan y clasifican a los pacientes para evaluar la prioridad de su atención de acuerdo con sus posibilidades de supervivencia y recursos disponibles, igual debemos realizarlo nosotros, determinando el alcance de ese impacto, cuáles son los sistemas más importantes (misión crítica) y datos (más importantes) y que, por lo tanto, necesitan atención en primer lugar, cómo aislar y proteger los datos (nivel de seguridad necesario para los datos y aplicaciones, ubicación), y cuánto tiempo se espera que dure la interrupción –antes de activar otros medios de continuidad.
  5. De hecho, debemos construir flexibilidad de modo que la empresa pueda responder de la manera que, coyunturalmente (no siempre contará con los recursos y capacidades suficientes o apropiados), le convenga (para no incurrir en problemas legales por incumplimiento con la ley de protección de datos personales, por ejemplo).
  6. Es muy importante establecer, difundir, y mantener vigente la matriz RACI correspondiente, y que ésta sea lo más granular posible, para asegurar que los roles, funciones, y responsabilidades (del personal clave tanto interno como externo, y de apoyo, considerando su disponibilidad y la capacidad de su ubicación oportuna) sobre un conjunto de actividades sean conocidas, claras, justas, entendidas, asumidas, adoptadas, interiorizadas, comprometidas, evitando una situación de juez y parte. Por ejemplo, habría que identificar las personas en la organización que tienen la autoridad para declarar un desastre y por ende, colocar el plan en efecto.
  7. No olvidemos detallar cuándo y cómo invertir en el equipo ejecutivo de gestión de crisis para que se cumplan los requisitos legales y normativos adecuados con respecto a las infracciones de datos. Las personas de relaciones públicas de la compañía pueden ayudar a informar adecuadamente a los clientes y consumidores.
  8. El negocio deberá establecer sistemas alternativos, como decidir cuál de las funciones de la organización son esenciales, y repartir el presupuesto disponible conforme a este criterio, o a establecer acciones manuales (considerando por supuesto la sensibilidad de los datos) que se disparan ante un evento, en la medida que sea posible lo que requeriría posiblemente un esfuerzo de capacitación adicional.
  9. Por supuesto, debemos ejecutar simulacros [lo más reales posibles] de eventos basados en tipos específicos de desastres [no idea, sino realidad], incluyendo brechas de seguridad. Así, la organización deberá proveer los recursos necesarios, establecer si necesita ayuda externa, planificar y programar los simulacros (al elefante nos lo comemos por tajadas), difundir su realización, establecer las estrategias de recuperación, diseñar los escenarios, priorizarlos, evaluar cada qué tiempo realizarlos y obtener la autorización del cuándo realizarlos (no vaya a ser que programemos una prueba justo cuando existe en el mismo día un evento crucial para la organización), cómo los va a realizar (la creación previa de plantillas de verificación ayuda a simplificar este proceso), afinar los planes y mantenerlos vigentes (como dijo Dwight ‘Ike’ Eisenhower, “el plan es nada, la planificación lo es todo”), entre otros factores.

¿Gestionas el cambio como un experto?

¿Gestionas el cambio como un experto?

Ya habíamos hablado de gestionar el cambio en una entidad pública. De hecho, también de limitaciones para un apropiado cambio, y máxime si se trata de proyectos.

Tenemos el know-how pero carecemos de la madurez para afrontar el cambio y reconocer dónde empezar.

Muchas veces esto está condicionado por el ambiente y la cultura de la empresa, lo que nos hace fallar y pensar que utilizamos una herramienta o contratamos el personal inadecuado o contratamos un consultor inexperto, y hasta que fuimos estafados –claro, fácil es echarle la culpa al otro ¿verdad?

Las organizaciones deben adaptarse a los cambios de escenario con proyectos cada vez más complejos, y entornos de gran incertidumbre y volatilidad. En toda empresa se realiza periódicamente un esfuerzo por determinar la mejor dirección para el negocio.

La cultura organizacional, su estructura, sus procesos, políticas, procedimientos y hasta sus valores pueden no estar en sintonía con ese cambio que se nos avecina y que demandará una nueva forma de interactuar, de pensar, de actuar.

El establecer controles que antes no existían ocasionará que, en la mayoría de los casos, las personas se resistan y respondan sólo por obligación a las exigencias de la organización.

De hecho, la cultura organizacional cambiará en la medida que cambien las personas y la posición que estas personas adopten frente al cambio, ya que son las personas las que hacen el cambio sostenible en el tiempo.

Una vez identificados los cambios que debemos realizar para asegurar esa dirección (entendiendo la necesidad del cambio y beneficios luego del cambio en el ecosistema de la organización), debemos establecer el valor del cambio y priorizar los principales ajustes (en procesos nuevos -o actualizándolos o complementándolos, procesos que pueden ser medidos, verificados y por ende adaptados en pro de la mejora continua, roles, estructura organizativa si es necesaria), entender a quién alcanza el cambio y cómo le beneficia (a clientes y stakeholders), establecer el compromiso e involucramiento de los participantes (recursos provistos en la oportunidad y cantidad requerida, personal suficiente, apropiado, capacitado, motivado), realizarlos (aplicando las 6W-2H), y mejorarlos.

Es sabido que el trabajo colaborativo genera pertenencia, nos permite apropiarnos del conocimiento, las habilidades y las actitudes que nos hace falta desarrollar para lograr los objetivos planteados. Es necesario entonces un poco de inteligencia emocional en el momento oportuno y de la manera apropiada y personalizada para sensibilizar a las personas ante lo que está por venir y así canalizar sus emociones –o motivación. Es importante entonces desarrollar una estrategia de comunicación y monitorizar la comunicación porque es clave para realizar ajustes cuando sea necesario.

Doxware, una variante del ransomware o del extortionware

Doxware, ¿es una evolución, una variante de malware, una nueva tendencia, o sólo un nuevo nombre? –porque nos gustan los nombres nuevos, sobre todo para lo que resulte amenazante[1].

Según la RAE, secuestrar es “Retener indebidamente a una persona para exigir dinero por su rescate, o para otros fines”; extorsión es “Presión que se ejerce sobre alguien mediante amenazas para obligarlo a actuar de determinada manera y obtener así dinero u otro beneficio”.

Ransomware suele instalarse en un sistema a través de un archivo adjunto de correo electrónico malicioso [usualmente de modalidad phishing], una descarga de software infectado y / o visitando un sitio o enlace malicioso. Cuando el sistema (independiente de la víctima) está infectado con ransomware, se bloquea, se cifran los archivos del usuario o se restringe el acceso del usuario a las funciones clave del equipo[2]. No se necesita mover datos, sólo cifrarlos[3]. Para evitar ataques, no sólo de ransomware, asegúrese de que todos los sistemas y software estén actualizados, proteja su red con tantas capas de seguridad como su presupuesto lo permita, cifre los datos sensibles, trate de no poner todos los huevos en la misma canasta, prevenga, eduque. El Grupo Smartekh nos ofrece un análisis gratuito de riesgo por ransomware.

Haciendo un poco de historia, la palabra doxxing; doxxing o doxing es un derivado de la palabra “docs” [“documentos” en idioma inglés]; el término es una versión abreviada de “dropping dox”, un método de venganza (algo así como dejar datos de alguien en el baño) que se remonta a la cultura hacker (y no tan hacker) de principios de los años 90[4].

Cuando doxxing y ransomware se combinan, esta combinación letal se conoce como Doxware[5]. Doxware entonces es el término usado para la técnica de acoso de encontrar, [secuestrar, extraer] y luego publicar información personal sensible de un usuario, incluyendo direcciones, números de teléfono e incluso números de Seguro Social[6].

Doxware normalmente escanea los archivos buscando frases clave que indican que son comunicación privilegiada, confidenciales o privados; así, el alcance de los archivos que doxware tiene como objetivo es menor que el ransomware ordinario, que se dirige a los discos duros completos[7].

Más preocupante es que los ciber delincuentes pueden tener acceso permanente a los datos personales y pueden exigir un rescate más de una vez. Incluso si se cede al chantaje, no hay ninguna garantía de que los archivos que han exfiltrado se eliminarán (apareció el extortionware). Los ataques basados en extorsión probablemente no aumentarán para el público en general, pero puede ser preocupante para los objetivos de alto valor, conocidos por tener datos valiosos. Con doxware el ataque es más personal, más selectivo, busca los blancos más atractivos, los que rindan más beneficios, los que maximicen el ROI. Es más, doxware puede exponer a las víctimas a acoso y humillación, pero también puede dejarlas vulnerables al robo de identidad[8].

El shadow IT, las redes sociales, el autoservicio de TI, hummmm. De hecho, preocupa a más de uno.

Confiamos en que evitamos la pérdida de los datos con los respaldos que realizamos, y en que recuperamos los servicios desde ahí, pero, en adición al tiempo y esfuerzo relacionados con el retorno real a la operación (dependiendo de la plataforma tecnológica desplegada, las capacidades existentes, y el tamaño del recurso comprometido), y del costo total de propiedad inherente, ¿qué fue de la pérdida de privacidad de los datos, no sólo por en dónde estaban sino, además, de quién son? ¿qué hay de un usufructo no alcanzado u oportunidades perdidas? ¿qué hay de los datos que son publicados y/o de posibles acciones legales por exposición no autorizada? ¿qué hay de la confianza perdida?, entre muchas otras interrogantes.

Recordemos, la ignorancia no es una defensa y el anonimato percibido no es un escape[9].

[1]       Fuente: http://searchdatacenter.techtarget.com/es/cronica/Doxware-Nueva-amenaza-de-ransomware-o-solo-extortionware-renombrado; disponible en marzo/2017

[2]       Fuente: https://www.techopedia.com/definition/4337/ransomware; disponible en marzo/2017

[3]       Fuente: http://www.networkworld.com/article/3174678/security/the-latest-ransomware-threat-doxware.html; disponible en marzo/2017

[4]       Fuente: http://computer.howstuffworks.com/what-is-doxxing.htm; disponible en marzo/2017

[5]       Fuente: https://www.topsec.com/it-security-news-and-info/what-is-doxware-ransomware; disponible en marzo/2017

[6]       Fuente; https://www.merriam-webster.com/dictionary/dox; disponible en marzo/2017

[7]       Fuente: https://www.techopedia.com/definition/32411/doxware; disponible en marzo/2017

[8]       Fuente: https://www.quora.com/What-is-Doxware-Malware; disponible en marzo/2017

[9]       Fuente: http://www.independent.co.uk/life-style/gadgets-and-tech/news/online-abuse-internet-sexting-doxxing-trolling-new-legal-guidelines-crime-prosecution-service-a7353536.html; disponible en marzo/2017

Internet de las cosas -IoT

Según Gartner, el “Internet de las cosas (IoT) es la red de objetos físicos que contienen tecnología incorporada para comunicarse y detectar o interactuar con sus estados internos o con el entorno externo”[1]; y añade que “el valor real del Internet de las cosas va más allá de los dispositivos interconectados”[2][3].

La interacción crea más datos (más complejidad en su tratamiento, más aplicaciones, mejores y más seguras que los traten, mayor necesidad de almacenamiento y procesamiento); la comunicación acarrea más riesgos que deben ser apropiadamente gobernados, una necesidad de mayor y mejor gestión de servicios (decisiones de toda índole más difíciles, para usuarios y operadores); las condiciones actuales y posibilidades futuras requieren recursos y capacidades diferenciados para asegurar que se mantiene el valor de los servicios (que promulga ITIL®) que entregamos –la sostenibilidad operativa.

Todos estamos involucrados y somos responsables del buen o mal uso que hagamos del IoT, en todo nivel. Además, debemos considerar que hay muchas cosas que considerar[4]: capacitación, público objetivo, requisitos de construcción, servicios incorporados, dispositivos (tipos, compromiso de seguridad, manipulación no autorizada[5], otros), disponibilidad, aplicaciones, redes, conectividad, plataforma tecnológica, ecosistema, riesgos directos e indirectos, actualizaciones de firmware o de software, aplicaciones que incorporen la seguridad desde el diseño, la arquitectura de las aplicaciones a este respecto, cifrado de datos, protección de datos personales, categorización de datos, datos sensibles en general, control de acceso, normativas, regulaciones, estándares, metadatos de los dispositivos, sistemas de monitorización y de protección contra intrusiones y ataques, tanto a nivel individual como colectivo[6], monitoreo continuo, localización de los datos porque lo que es delito informático en un país puede no serlo en otro, resiliencia[7], confidencialidad, integridad y disponibilidad, entre muchas otras posibilidades.

IoT no es una cosa; es la integración de varias cosas en una solución de negocio, es el corazón del negocio digital –bueno, cuando ya no sea una buzzword y realmente se de una transformación digital y contemos con tecnología concreta utilizable hasta en nuestros hogares[8] y por todos (refrigeradoras que podrán avisar a sus dueños cuando no haya alimento en ellos[9] es la promesa ¿recuerdan?). Sería bueno saber cuántos y cuáles dispositivos están accediendo a nuestra red local, y algo ‘raro’ como deshabilitar el bluetooth y las funciones que los dispositivos no usan todo el tiempo[10]. No queremos que “alguien” nos haga “gastar” más electricidad de lo habitual. Ya conocemos las deficiencias de seguridad existentes, que no nos pesquen desprevenidos, por ellas al menos[11].

[1]       Fuente: http://www.gartner.com/it-glossary/internet-of-things/; disponible en marzo/2017

[2]       Fuente: http://www.gartner.com/technology/research/internet-of-things/?s=1; disponible en marzo/2017

[3]       Fuente: http://view.ceros.com/gartner/iot/p/1; disponible en marzo/2017

[4]       Fuente: https://ricveal.com/blog/10-retos-seguridad-iot/; disponible en marzo/2017

[5]       Fuente: http://aunclicdelastic.blogthinkbig.com/el-reto-de-la-seguridad-en-iot/; disponible en marzo/2017

[6]       Fuente: http://www.csuc.cat/es/internet-of-things-un-reto-para-la-seguridad; disponible en marzo/2017

[7]       Fuente: http://www.ibm.com/developerworks/ssa/library/iot-trs-secure-iot-solutions1/index.html; disponible en marzo/2017

[8]       Fuente: http://techcetera.co/el-reto-para-la-seguridad-para-el-internet-de-las-cosas/; disponible en marzo/2017

[9]       Fuente: http://www.nacion.com/tecnologia/informatica/Seguridad-principal-reto-Internet-Cosas_0_1571442852.html; disponible en marzo/2017

[10]     Fuente: http://techcetera.co/tiene-el-internet-de-las-cosas-iot-algun-riesgo-para-su-hogar/; disponible en marzo/2017

[11]     Fuente: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/insecurity-in-the-internet-of-things.pdf; disponible en marzo/2017

Gestión de proyectos en la gestión pública

Ya antes habíamos comentado sobre los proyectos fallidos.

De hecho, mucho se habla hoy sobre este tema de que en la gestión pública se deben gestionar proyectos o, al menos, de que deberíamos emplear técnicas de gestión de proyectos en la gestión pública.

Interesante propuesta, e ideal desde todo punto de vista, pero ¿y la acción?

Hace un tiempo se pretendió utilizar una herramienta para gestionar proyectos en una entidad del estado. Obviamente esta iniciativa fracasó. Los motivos fueron, entre otros, pero no limitados a, la expectativa de alcanzar los beneficios siempre promulgados por una eficiente gestión de proyectos, además de una pronta toma de decisiones informada, pero sin tener en cuenta las restricciones y plazos de ley para ciertas actividades, las ocurrencias producto de una deficiente formulación de los expedientes técnicos, y formalismos establecidos, pero no estandarizados, de los diferentes actores. Hay aquí una relación e integración interesante de gobierno, riesgos, y cumplimiento, y se comprueba que todo proyecto debe ser continuamente monitorizado para validar que se mantiene entregando el valor esperado.

El gerente general deseaba conocer realmente el portafolio de proyectos de la institución. Deseaba dejar un portafolio de proyectos ordenado, organizado, y controlado. En la fecha de la presentación oficial del producto desarrollado, se dio cuenta este gerente que no iba a inaugurar una determinada obra -estratégica- durante su vigencia en el cargo. Los sub-gerentes se excusaron, adujeron carencia de información oportuna, apareció un sin número de actividades extra, y atacaron el producto. El ejercicio sirvió al gerente para tomar una decisión referente a la inauguración, y para corroborar, según él, que efectivamente no se le informaba ni oportuna ni apropiadamente, y que las gerencias no trabajaban en equipo.

El producto no tenía nada de malo. Se había desarrollado en conjunto con el personal asignado como un producto dinámico, de alcance holístico para la tarea. Este dinamismo permitía reducir, lo mejor posible, la incertidumbre y el riesgo[1], pero era necesario dedicarle –constantemente-un tiempo; no es que me pueda limitar horas antes a completar el cuadro, de forma aislada, para presentarlo en la fecha prevista, apoyándome en “mi experiencia pasada”. El alcance era holístico por cuanto involucraba todas las gerencias, desde la concepción de la idea hasta la inauguración del proyecto una vez terminado. Un problema es que los sub-gerentes lo consideraron un mero plan estático, y no un producto sujeto de continua actualización (¿una de las excusas del momento?). El compromiso de apoyo se dio, puntualmente para el momento y por exigencia del gerente general, atendiendo a únicamente su ámbito de competencia, y falló la comunicación interna, y la continuidad del compromiso (genuino) para las actualizaciones pertinentes y constantes, el sinceramiento de reconocer que se necesita y de adoptar una herramienta de control.

Si lo anterior se corrigiera, entendiendo que se requiere un cambio de real[2] contenido (estructura, procesos de negocios, sistemas de gestión, tecnología, cultura, las propias personas, etc.), seguramente mejoraríamos la calidad de los proyectos y obtendríamos mejores resultados, sobre todo, sostenibles en el tiempo.

[1]       Fuente: http://salineropampliega.com/2014/11/gestion-de-proyectos-en-la-administracion-publica.html

[2]       Fuente: http://salineropampliega.com/2017/02/entrevista-a-akira-bloise-sobre-como-implementar-la-direccion-de-proyectos-en-una-organizacion-12.html

Las limitaciones del ¿qué debo hacer? –o el por qué y qué debo aprender

Hace unos seis años trabajaba como supervisor de la implementación en un proyecto importante para el estado peruano cuyo producto recién en este año está siendo considerado y se busca utilizarlo –bueno, parte del ‘éxito’ es que, aunque su uso había sido declarado obligatorio en esa época, recién se está ejerciendo presión.

En ese entonces la empresa que había sido contratada para la implementación tenía serios problemas. Se observaban deficiencias y se informaban, con oportunidad y suficiencia. Pronto nos dimos cuenta que el “diseñador” de la solución era “responsable” de la implementación; hablo de persona. Lamentablemente, las observaciones no eran levantadas y, el responsable simplemente se sentaba en las reuniones de avance y preguntaba al equipo supervisor “¿qué debo hacer?” Con el cuento de que todos queremos un bien para el Perú, “a pedido” de la gerencia, resolvíamos como cliente los problemas del proveedor. Obviamente hubo retrasos pero ignoro si alguna multa hubo de por medio.

En otra institución, los desarrolladores de software buscaban rápidamente que el líder usuario les indicara qué hacer para comenzar a hacer –menos mal no empezaban a hacer antes de saber qué hacer, como en el cuento. Muchas veces, cuando lo que comenzó a hacerse era entregado, no terminaba siendo lo que se había solicitado. Bueno, esto lo hemos escuchado muchas veces. Una razón es que los requisitos no estuvieron bien definidos y, por ende, los requerimientos tampoco.

En los casos anteriores es evidente que se buscaba un mero cumplimiento, “¿qué debo hacer?”, implicando que la responsabilidad es de otro, no del que recibe el encargo. Luego, el resto es historia, sobre todo cuando las cosas salen mal; alguien se hará cargo; alguien será el títere y otro el titiritero; no es mi culpa, hice lo que me dijeron; entre otras excusas.

Lo verdaderamente malo es que no aprendemos de nuestros errores y, como dicen, quien no conoce su historia, está condenado a repetirla. Aquí viene la segunda parte, por qué debo aprender y, sobre todo, qué debo aprender[1], para evitar repetir errores. Mucho se ha hablado de esto también, pero poco se hace, y poco hacemos –o logramos hacer. El propósito no es sólo tener datos; es usar la información que esos datos nos proporcionan[2]. Se requiere una organización que aprenda[3]. Por el momento tendremos que lidiar con la cultura de la empresa, con el “aquí se hace así” o con el “siempre se ha hecho así”. Pero empecemos el cambio. Yo termino el año con aportes. A pesar del miedo de mis colaboradores, y de otros colaboradores, en el último mes he logrado hacer que, al menos, el área competente evalúe nuevos formatos de procedimientos, y que re-evalúen el contenido de otros procedimientos. Veremos cómo termina esto.

[1]  Fuente: http://theleanthinker.com/2016/11/12/its-what-must-we-learn-not-what-should-we-do/; disponible en dic/2016

[2]  Fuente: http://www.qualitydigest.com/inside/quality-insider-column/two-questions-get-you-nowhere.html; disponible en dic/2016

[3]  Fuente: http://www.qualitydigest.com/inside/quality-insider-article/engine-and-fuel-quality-improvement.html; disponible en dic/2016

Revisemos lo de cultura de productividad

Una de las premisas de la propuesta lean es que se debe fallar rápido. Ojo, no bastante, que es lo que veo cuando reviso los reportes de QC de la organización donde laboro. No se preocupen, como en otra entidad donde hace unos años hubo oportunidad de realizar mejoras, ya estoy involucrándome aquí.

Este concepto de fallar rápido (o probar temprano) también se asocia con las diferencias entre los enfoques de cascada (que propicia una entrega final y completa, y que funciona bien cuando la demanda es [o era] estable[1]) y ágiles (que propicia entregas incrementales, y donde se requiere personal con versatilidad y agilidad de aprendizaje) para el desarrollo de software[2]. Inherentemente, propugna que el conocimiento obtenido de un intento fallido en realidad aumenta la probabilidad de un eventual éxito.

Claro, debemos tener en cuenta las especializaciones, certificaciones, cultura organizacional, apetito por el riesgo, orientación, vocación, necesidades propias de la empresa, demanda de ciertas habilidades (encontrar el candidato perfecto con exactamente las calificaciones adecuadas, la educación y las expectativas salariales puede ser una tarea desalentadora – si no imposible[3]), preponderancia de género[4], esquemas de reclutamiento, línea de carrera, motivación, incentivos, entre otros, y no sólo de la empresa, importante considerar al diferenciador clave por sus capacidades individualizadas: el colaborador comprometido.

Al respecto, hoy escuché que si alguien está interesado por la calidad, aporta a ella. Es un buen pensamiento. Lo lamentable es que el equipo de calidad tuvo que ser llamado por ese alguien porque ninguno había  comenzado a trabajar. Lo peor, en mi opinión, es que ese alguien evidenció que la calidad le interesaba por motivos egoístas de ganar un premio –como ya lo había hecho antes. Bueno, todos trabajaremos en disque mejorar la productividad de unos pocos para satisfacer el ego de un alguien que muy pronto se retira de la institución y desea dejar a su sucesor sólo la tarea de presentar la documentación para la evaluación del premio. Me pregunto si habrán pensado en la sostenibilidad y sustentabilidad futuras.

El departamento de TI debe cambiar su conjunto de habilidades[5], no sólo por el advenimiento de la nube y su posible [o ya existente] adopción, sino porque los cambios exigidos por el entorno serán cada vez más frecuentes y diversos e impactarán incluso en la seguridad de la información o, por lo menos, en cómo la manejamos, incluso cuando vivimos hoy una cultura global de movilidad y cuya gestión no puede permanecer estática[6]. De hecho, Gartner nos informa que en 2017[7], cada organización tenderá a contar con una mezcla de cinco plataformas tecnológicas digitales: Sistemas de información, experiencia del cliente, análisis e inteligencia, Internet de las Cosas y ecosistemas empresariales. Debemos tomar en serio la gestión del riesgo de TI (no sólo el riesgo cibernético y el cumplimiento). Tengamos presente que las organizaciones están desarrollando iniciativas de transformación digital para mejorar los procesos de negocios, servicio al cliente[8], entre otras. Así, resulta vital asegurarnos que nuestro equipo de TI esté comprometido con la estrategia digital de la organización[9].

Como dijimos, el tema es aprender, transformar información en verdadero conocimiento y éste en sabiduría. Lo único constante es el cambio (Heráclito)[10]. Algunas mejores prácticas apoyan en esto del cambio a través de la formulación y operación de servicios; otras mejores prácticas permiten lograrlo a través del desarrollo de proyectos.

[1]  Fuente: http://searchcio.techtarget.com/tip/CIO-outlook-2017-Five-elements-of-the-new-IT-operating-model?utm_medium=EM&asrc=EM_NLN_70027032&utm_campaign=20161221_CIO%20outlook:%20Five%20imperatives%20for%202017&utm_source=NLN&track=NL-1808&ad=911795&src=911795; disponible en dic/2016

[2]  Fuente: http://whatis.techtarget.com/definition/fail-fast; disponible en dic/2016

[3]  Fuente: http://searchcio.techtarget.com/definition/IT-skills-gap-information-technology-skills-gap; disponible en dic/2016

[4]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Industria-de-datacenter-enfrenta-crisis-de-habilidades-al-reemplazar-a-ingenieros; disponible en dic/2016

[5]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Diez-tendencias-de-la-nube-para-2017-segun-Tableau; disponible en dic/2016

[6]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Los-administradores-de-servicios-de-TI-ven-un-rol-para-ITIL-en-la-transformacion-digital-del-negocio?utm_medium=EM&asrc=EM_EDA_69283048&utm_campaign=20161207_El%20rol%20crucial%20de%20ITIL%20en%20la%20transformaci%C3%B3n%20digital&utm_source=EDA; disponible en dic/2016

[7]  Fuente: http://www.gartner.com/smarterwithgartner/gartners-top-10-technology-trends-2017/; disponible en dic/2016

[8]  Fuente: http://searchdatacenter.techtarget.com/es/cronica/Las-iniciativas-de-transformacion-digital-cosechan-valor-de-negocios; disponible en dic/2016

[9]  Fuente: http://searchdatacenter.techtarget.com/es/consejo/Cuatro-formas-de-crear-impulsores-de-valor-para-la-tecnologia-digital?utm_medium=EM&asrc=EM_EDA_69897476&utm_campaign=20161219_Principales%20tendencias%20de%20almacenamiento%20de%20datos%20para%202017&utm_source=EDA; disponible en dic/2016

[10]                Fuente: http://www.asesoriaterapeutica.com/blog/187-%E2%80%9Clo-%C3%BAnico-constante-es-el-cambio%E2%80%9D-her%C3%A1clito.html; disponible en dic/2016