¿Problemas en TI?

Algunos indicios

Usualmente los problemas empiezan cuando somos los últimos en enterarnos de los cambios en la estrategia del negocio.

Los usuarios dejan de quejarse –porque han optado por el shadow IT, la organización está implementando mecanismos alternativos de soporte a usuarios, mecanismos alternativos de operación y, luego, posiblemente, ocurran despidos y rotación o traslado de personal.

Los usuarios dejan de llevarnos sus grandes ideas. Esto podría deberse a que el gerente de TI no fomentó una cultura de colaboración y experimentación, a una falta de madurez o mucho ego.

Ya no es copiado en los correos institucionales –mejor pensamos, las reuniones eran improductivas.

Seguramente hemos comenzado a ver personas extrañas circulando por la empresa, o se nos han asignado “ayudantes” para apoyarnos con la carga de trabajo.

Expectativas no aterrizadas sobre el ritmo esperado del cambio, o resistencia burocrática al cambio producto de un estancamiento de la organización a nivel alto.

No se evidencia una articulación con la estrategia. Se pide conexión con los clientes y generar ingresos, a la vez que se debe reducir costos y mejorar las eficiencias operativas.

Pero seguramente nosotros mismos somos parte de la ecuación –y lo negamos, ya sea consciente o inconscientemente

La deuda técnica y/o la obsolescencia técnica probablemente nos mantengan realizando los mismos trabajos, o resolviendo los mismos problemas, una y otra vez.

Nos escudamos en la falacia del costo perdido, del costo hundido, cuando la mejor solución es deshacerse de los viejos sistemas problemáticos y comenzar de cero con otros nuevos, capitalizando el conocimiento aprendido de esa [mala] experiencia.

De alguna manera estamos cautivos de algún proveedor. Tal vez nos encandiló una funcionalidad aún no [suficientemente] explotada, porque no estamos preparados para capitalizar esta funcionalidad [y, peor, tal vez nunca lo estaremos]. O porque buscamos [obtuvimos] el precio más bajo [CAPEX], sin considerar el [OPEX]. O porque era más fácil gestionar al proveedor que implementaba la “solución”, que [realmente] conocer dicha solución.

Consideramos que, como se habla de nubes híbridas, la nube puede ser una extensión de nuestro centro de datos. Debemos detenernos y considerar –bastante- que hay diferentes SLA (¿o la nube no nos cuesta diferente a nuestro centro de datos?).

Preparamos un caso de negocio “técnicamente sólido”. Pero perdemos de vista el objetivo –y, peor, no utilizamos el lenguaje- del negocio.

Aplicar metodología ágil a los sistemas centrales. Querer ser una bimodal 2.0 cuando tenemos que evaluar primero nuestra posición como bimodal 1.0. Tal vez si realizamos una evaluación previa y logramos acotar el alcance o conveniencia, con el correcto balance entre agilidad y estabilidad…

O los clásicos que argumentamos

Decir sí a todo –o a casi todo, sin buscar ser asertivo, para darnos tiempo de  realizar las evaluaciones correspondientes. Manejamos proyectos ¿verdad?

Pretender esconder los problemas, creyendo que se podrán resolver antes que nuestro superior se entere. Gestionamos las comunicaciones, y los cambios, como parte de la gestión de proyectos y de la gestión de servicios ¿verdad? O utilizando la técnica del oscurantismo.

Contratar [o no contratar] (por ego) o promover (por conveniencia) al candidato equivocado. Olvidar que la destreza ganada a través de la experiencia importará menos que la habilidad de aprender otras nuevas destrezas.

Mantener el dilema ético de ser juez y parte –y saber gestionar [sobrellevando y asumiendo] lo que viene después.

No identificar y menos ejecutar las acciones correctivas necesarias.

Conflictos de poder.

La tecnología es [siempre, o casi siempre] la culpable –pero no buscamos una real solución.

Esbozar que la innovación o búsqueda de la mejora continua no está en el manual de funciones por las que fuimos contratados.

Realizar tareas sólo por cumplimiento normativo, regulatorio, legal, ya sea local o internacional, dependiendo del ámbito de actuación de la organización.

Falta, pero empecemos por lo siguiente

Debemos sentirnos cómodos con abrazar el fracaso. Debemos enfrentarlo (somos profesionales) -y aprender (es nuestra habilidad innata).

De igual manera, debemos aceptar los resultados de una [real] auditoría de TI –y definir y ejecutar las acciones correctivas necesarias.

Evitando que sea el usuario final el que nos reporte un incidente.

Asegurar los SLA comprometidos.

50 principios y recomendaciones para tener éxito en implementar la seguridad de la información

Pongámonos en situación

Un principio es una idea fundamental [y/o ley] sobre la que se basa una teoría o a partir de la cual se puede formular un razonamiento.

Consideremos entonces los principios morales, como reflejo de nuestro comportamiento social, como la cultura y/o religión; y los principios éticos, que reflejan el comportamiento “adecuado” de personas y el uso de sus conocimientos específicos (que devienen de la ciencia) en áreas profesionales relevantes para la sociedad, como en las profesiones. Leamos este artículo con este contexto como base.

En un artículo previo, 16 habilidades de seguridad crítica que necesitamos, sugerimos de forma básica cómo empezamos a hacer algo a nuestro favor con respecto a la seguridad. De hecho, todo esto implica gestionar la seguridad de la información,(confidencialidad, integridad, disponibilidad, y sus relaciones con la privacidad, identificación y autenticación, no repudio, auditoría y responsabilidad), siempre apoyados en procesos y procedimientos de seguridad documentados, comprobados, y mantenidos.

Empecemos por lo básico –ya que, cuanto más cambian las cosas, más permanecen igual

  1. Implemente mecanismos para evitar el robo de nuestros activos físicos. Cadenas, candados, áreas [cerradas] restringidas y vigiladas, cámaras [infrarrojas], sensores de movimiento, sensores de consumo de energía [por encima o por debajo de umbrales pre establecidos como adecuados], entre otros, podrían ser útiles
  2. Así como un capitán conoce [perfectamente] su barco, así debemos conocer nuestra plataforma tecnológica. Consideremos responder preguntas importantes como qué necesito, dónde lo necesito, cuándo lo necesito, cómo lo necesito, cuánto necesito, cuánto costará, qué protejo, para qué protejo, a quién protejo, de qué protejo, durante cuánto tiempo protejo, quién debe proteger, quién debe asegurar que la protección sea efectiva, cuáles son los criterios y formas establecidas para verificar que la protección logra su cometido, cómo valido la continua necesidad de la protección, entre otros factores a considerar (proponga más, utilice su experiencia, su ingenio). Herramientas útiles podrían ser RACI, MoSCoW, 6W‑2H, SMART, KISS.
  3. Los sistemas operativos tienen fallas [no es raro –ni nuevo], o se actualizan [mejoran] –lo cual puede, potencialmente, ocasionar fallas. Parchar los sistemas operativos oportunamente es mandatorio, pero recordemos que los servicios actualmente en operación no deben verse alterados. Así, debemos considerar aspectos mínimos para la seguridad como: urgencia; exigencia; afectación; activo, vulnerabilidad; amenaza; riesgo; impacto; necesidad; ambiente de control; entre otros.
  4. Y con los sistemas operativos de las computadoras personales aparecieron los virus –que luego se extendieron a las computadoras de mayor nivel (llamados luego servidores) que están basados en tecnología similar. Luego se extendieron a otro tipo de dispositivos, con diferentes kernel.
  5. La protección luego comenzó a ampliarse a las herramientas, productos, o ‘servicios’ que utilizamos, como correo electrónico, sistemas de archivos, descargas desde Internet, entre otros.
  6. Además, la seguridad comenzó a combinarse [ampliando y complicando a la vez las cosas] con otras posibilidades de protección como firewall, anti‑phishing, anti‑keylogger, webcam, USB, entre otras.
  7. Respaldemos nuestros [los] datos, periódica y consistentemente. Esta actividad es un seguro (esperamos lo mejor), para cuando ocurra el evento que requiera los datos respaldados (preparándonos para lo peor).
  8. Reducimos el riesgo limitando el acceso (entregar los privilegios mínimos necesarios para realizar la tarea), acceso que debe estar vigente sólo durante el tiempo más breve necesario (luego del cual recuerde retirar los privilegios), y limitando los datos a los que se accede (reducir la superficie de ataque -compromiso), funciona de la mano con la prevención (evitando valores por defecto, ‘recomendaciones’ del fabricante o de empresas similares, implementando e implantando mecanismos para accesos, listas de control, autenticación, autorización, certificación, permisos, usuario y contraseña, MAC, DAC, RBAC, entre otros) y detección (análisis de logs, trazabilidad, herramientas apropiadas).
  9. Entrenamiento, capacitación, formación, educación, generar conciencia, fomentar una cultura positiva de seguridad. Nunca es suficiente, tampoco es una tarea que se realice sólo una vez. Se requiere constancia, perseverancia, continuidad, confirmación, conformidad, compromiso (la seguridad es tarea de todos), resultados, entre otros aspectos a considerar.
  10. Reduzcamos el riesgo de intrusos. Conocer quién se conecta a nuestra red desde el interior es bueno [usuarios autorizados], así como también desde el exterior (“¡bárbaros en la puerta!”).
  11. Permitimos entonces el acceso [utilizando mecanismos como firewall, VPN, IPS/IPS] sólo a aquellos [redes, usuarios] en quienes confiamos.
  12. Incrementemos la confiabilidad de los datos al validar su ingreso (restringir, rechazar y desinfectar los datos) a los sistemas de información (asegurar tipos, patrones y rangos válidos).

Ahora, incrementamos un poco nuestra preocupación por la seguridad

  1. Las medidas de seguridad apropiadas para una organización dependerán de sus circunstancias, sus objetivos institucionales, de entregar la calidad y valor que los interesados esperan, de proveer reportes de rendimiento con respecto a la seguridad conforme se ha establecido.
  2. Conviene entonces adoptar un enfoque basado en el riesgo para decidir qué nivel de seguridad se necesita: categorizar utilizando un sistema de información; seleccionar los controles de seguridad; implementar estos controles; valorar los controles; establecer las autorizaciones necesarias; monitorizar los resultados; y volver a empezar.
  3. Planifiquemos, establezcamos mecanismos, roles y responsabilidades, identifiquemos la tecnología necesaria, aseguremos que hagamos lo planeado.
  4. Monitoreo, control, supervisión, de las acciones planificadas (programadas y en ejecución, ya sean automatizadas o manuales) son temas evidentes que no pueden faltar –ni fallar.
  5. No olvidemos comprobar, asegurar los resultados, y de tomar la acción correctiva necesaria de forma oportuna (actualizar planes, procesos, procedimientos, formación, tecnología, proveedores, perfiles, otros).
  6. Implica identificar los activos de información (obviamente, esto incluye los datos), categorizarlos, tratarlos en consecuencia, analizar sus vulnerabilidades y amenazas, establecer los riesgos.
  7. No olvidemos resolver las brechas de seguridad de forma transparente –correctamente y rápido (reduciendo, por ejemplo, el tiempo entre detección y respuesta). La seguridad mediante el oscurantismo no es buena. De hecho, presuma mejor que sus secretos no son seguros.
  8. Ciertamente debemos saber quién se conecta a nuestra red, así como a qué redes nos conectamos. Necesitamos considerar [en el tiempo] la variada tecnología que podemos o debemos emplear –y gestionar. Es mandatorio gestionar la configuración interna y externa de nuestra plataforma tecnológica (la interrelación de los componentes mediante los que se entregan los servicios).
  9. Consideremos mecanismos adicionales para controlar [y asegurar] el acceso a nuestra plataforma tecnológica (HW, SW, software utilitario, motores de base de datos, sistemas de información), como separar los privilegios, jerarquizarlos, aislarlos.
  10. Diseñemos e implementos mecanismos de defensa en profundidad. Es una exigencia básica el cerrar las puertas traseras en nuestras redes -¿necesidad, cumplimiento normativo, regulatorio o legal, local o internacional? Tenemos entonces opciones como DLP, SIEM, UEM, entre otras. La tarea no tiene fin; así, debemos gestionar el cambio de forma continua.
  11. La cadena se rompe por el eslabón más débil. Es obvio que los ataques se dan contra los componentes que los hackers han identificado como menos seguros. Y no siempre es la tecnología el eslabón más débil; procesos, procedimientos, formación, proveedores, cultura organizacional, entre otros aspectos, son también de consideración.
  12. Podemos fallar, pero procuremos hacerlo de forma segura. Debemos planear para estos casos en que pueden/puedan ocurrir fallas. Esto implica gestionar la mejora continua. Lo que es evitable son los problemas de seguridad relacionados con la falla. Si la aplicación falla, aseguremos que los datos sensibles no queden sin protección –tras una falla, pasar a un modo seguro. El problema es que cuando muchos sistemas fallan de alguna manera, exhiben un comportamiento inseguro.
  13. No compartamos mecanismos de autenticación, a menos que confiemos en los usuarios de esos mecanismos. Aislamiento de objetos (cuyo acceso, individual y en cada momento, debe ser verificado por la autoridad necesaria para dicho acceso), independientemente de los rangos jerárquicos, y de los mecanismos utilizados para accederlos es una buena idea.
  14. Sin embargo, no es buena idea confiar demasiado. La confianza es transitiva –y eso puede ser un problema de seguridad. La confianza pasa por cinco niveles: valores compartidos, integridad, preocupación por otros, competencia (además carácter y comunicación, para un líder), confiabilidad/dependencia.

Siempre es bueno revisar otros aspectos –que usualmente pasamos por alto, damos por descontados o, peor, creemos que estamos en lo correcto

  1. La seguridad de la información se establece desde el diseño de los servicios que vamos a prestar y por ello es vital gestionar este diseño.
  2. Los principios de seguridad en la nube.
  3. Los principios de seguridad provistos por marcos de trabajo reconocidos internacionalmente.
  4. Los principios o fórmulas o recomendaciones de seguridad de los proveedores de equipos y/o de software.
  5. Establecer la necesidad de cifrar nuestros datos sensibles.
  6. Analizar el contenido de los archivos de registro (log) que estamos almacenando. Protejamos los log.
  7. Balancee la protección necesaria (¿sistemas críticos primero?) a implementar (revise sus recursos, analice sus capacidades) con su utilidad (no olvide considerar el valor percibido por los interesados de esta implementación).
  8. No olvide registrar los eventos –y proteger los registros, en cumplimiento legal. Ahora importan los exitosos tanto como los no exitosos. Con la potencia y capacidad actual de la tecnología, ya no son válidos argumentos del siglo pasado como lentitud, disco lleno, necesidad adicional de administración, costos no contemplados, capacitación insuficiente, entre otros.
  9. ¿Realizamos auditorías? Claro que son necesarias, en todos los niveles
  10. Debemos identificar la existencia de excepciones (para lo cual la empresa primero debe definir qué significa para ella una excepción) y, una vez identificadas, ¿cómo las manejamos?
  11. Ejecutemos pruebas frecuentes. Hay diferentes formas. Busquemos las formas y programemos. Recuerde, un hacker no es un criminal –al menos no siempre, a diferencia de un cracker –y no hablo de galleta, que comúnmente sí.
  12. No estamos solos así que, si tenemos problemas, busquemos ayuda.
  13. Adoptemos nuevas formas de trabajo, como LEAN, SCRUM, DEVOPS.
  14. Entendamos que el SHADOW IT, y otras formas que “atentan” nuestro statu quo, es una realidad y debemos aceptarlas y, más bien, buscar la manera de integrarlas. Posiblemente no nos hemos dado cuenta –o no queremos darnos cuenta- y estamos en etapa de transformación de una empresa bimodal0 a una bimodal 2.0.
  15. Promueva la privacidad de la información de identificación personal –ya sabemos, cuando está almacenada, en tránsito, o procesándose. La información de identificación personal no sensible puede ser fácilmente obtenida de registros públicos, guías telefónicas, directorios de empresas y sitios web; la sensible es, por ejemplo, información biométrica, información médica, información financiera con identificación personal, e identificadores únicos tales como números de pasaporte, DNI, AFP.

Claro, ¿y qué hay del [apropiado] gasto en seguridad? Seguro necesitamos presupuesto, pero, sugerimos realizar primero las siguientes acciones

  1. Empecemos por establecer las prioridades de seguridad –tenga en cuenta los objetivos de la empresa; concéntrese en las aplicaciones de misión crítica.
  2. Analicemos la cultura organizacional con respecto a la seguridad de la información –podría haber inconsistencias/incongruencias/contradicciones que conviene identificar con anticipación.
  3. No olvidemos que al elefante nos lo comemos por tajadas.
  4. ¿Podemos automatizar, hasta qué punto?
  5. Estandaricemos cuando y cuanto sea posible. Posiblemente requiramos simplificación y centralización.
  6. Establecemos un balance entre acciones reactivas y proactivas (fomentando un mayor número de proactivas al implementar acciones que reduzcan las reactivas).
  7. Haga pruebas de penetración internas –obtenga primero la autorización.
  8. Planifique escenarios para lo peor
  9. Establezca el costo para el negocio de cada hora sin servicio. Hable con la alta dirección en sus términos (dinero).

Conclusiones

El mantra de siempre: la seguridad de TI es un trabajo desafiante que requiere atención al detalle (establecer lo éticamente correcto), al mismo tiempo que exige un mayor nivel de conciencia (establecer lo moralmente correcto).

Busquemos, de ser posible, primero la mayor adopción – interiorización (sujeto, claro, a la cultura organizacional)- para que, tras la implementación subsiguiente (sujeta a menor resistencia), obtengamos los resultados comprometidos/esperados de la seguridad (que técnicamente hemos establecido como alcanzables).

16 habilidades de seguridad crítica que necesitamos

16 habilidades de seguridad crítica que necesitamos

Pongámonos en situación

Seguramente este tema sobre seguridad es trillado para muchos, por lo [aparentemente] obvio del tema, a estas alturas.

Contamos con herramientas que seguramente dominamos. Esa es la parte tecnológica.

Pero no debemos dejar de lado que el ser humano ha desarrollado la tecnología con base en hechos científicos, como herramienta, para ayudarse en lo repetido, en lo meramente operativo y no pensante [bueno, otro tema son los continuos avances en inteligencia artificial].

 

 

Entendamos primero el concepto de habilidad

El concepto de habilidad se refiere a una capacidad y disposición para algo; hace referencia a la maña, el talento, la pericia o la aptitud para desarrollar alguna tarea. Es una aptitud innata.

En 1993 la División de Salud Mental de la Organización Mundial de la Salud (OMS) lanzó la Iniciativa Internacional para la Educación en Habilidades para la Vida en las Escuelas.

El propósito de esta actuación era difundir mundialmente la enseñanza de un grupo genérico de diez destrezas psicosociales, consideradas relevantes en la promoción de la competencia psicosocial de niñas, niños y jóvenes.

  1. Autoconocimiento
  2. Empatía
  3. Comunicación asertiva
  4. Relaciones interpersonales
  5. Toma de decisiones
  6. Solución de problemas y conflictos
  7. Pensamiento creativo
  8. Pensamiento crítico
  9. Manejo de emociones y sentimientos
  10. Manejo de tensiones y estrés

Estas diez habilidades psicosociales no son materia nueva. En cierta forma, son tan antiguas como la propia humanidad, porque todas tienen que ver con la manera en que manejamos las relaciones con nosotros mismos, con las demás personas y con el entorno social.

Es más, el Foro Económico Mundial en 2016, propuso en su artículo, 10 habilidades que se necesita para prosperar en la Cuarta Revolución Industrial, que hacia el 2020, se requerirán las siguientes habilidades:

  1. Solución de problemas complejos.
  2. Pensamiento crítico.
  3. Creatividad.
  4. Administración de personal.
  5. Coordinar a otros para trabajar en un fin común.
  6. Inteligencia emocional.
  7. Juicio y toma de decisiones.
  8. Orientado al servicio.
  9. Negociación.
  10. Flexibilidad cognitiva.

Y otro artículo, más reciente, Las habilidades más importantes del mañana, según cinco líderes mundiales, las siguientes habilidades adicionales:

  1. Habilidades blandas, como el trabajo en equipo, conocimiento de las herramientas digitales, la comprensión de las reglas y las regulaciones, la responsabilidad y el compromiso son las más relevantes.
  2. Explotar los torrentes de información que se generan a diario con una fuerte dosis de empatía.
  3. Habilidades que las computadoras nunca llegarán a dominar, y grandes maestros para enseñarlas.
  4. Olvidar el aprendizaje de memoria, y centrarse en habilidades transferibles como: pensamiento crítico, adaptabilidad, resolución de problemas, entre otras.
  5. Un espíritu emprendedor, y las habilidades para saber cómo aplicarlo.

Resulta importante considerar esto de la cuarta revolución industrial porque, en palabras del presidente ejecutivo de WEF, Klaus Schwab, cambiará “no sólo lo que hacemos sino lo que somos”, dado que “afectará nuestra identidad” en múltiples formas.

Más aún esta revolución se manifestará en nuestro sentido de privacidad, noción de propiedad, patrones de consumo, así como en la forma en la que cultivamos nuestro conocimiento e interactuamos con las personas.

Schwab está convencido que “[…] en el futuro, el talento, más que el capital, representará el factor crítico de la producción”.

Ciertamente son de importancia las habilidades consideradas en estos artículos.

Veamos, entonces, sabemos qué hacer en cuanto a seguridad

Pensamos que sabemos todo sobre el tema. Nuestras certificaciones en seguridad, riesgos, continuidad, y otras más, nos acreditan, y nuestra experiencia en dichos campos nos avala. ¿No acabamos de certificarnos en Hacking Ético? -y seguramente ya nos consideramos hackers.

Bueno, no es así para todos, aunque parezca [o debería], y a ellos va dirigido esta contribución.

Mucho tiene que ver [y empezar] con reconocer [sinceramente] nuestras propias fortalezas y debilidades, nuestro propio accionar, nuestras costumbres.

No es raro que el ecosistema en que nos desenvolvemos también juega un papel importante en esto, ya que muchas veces nos arrastra –y nos dejamos arrastrar.

Pero, ¿cómo empezamos a hacer las cosas?

Preguntémonos, por ejemplo:

  1. ¿Cuántas veces no hemos hecho nuestra tarea previa antes de realizar la instalación, implementación, personalización, configuración de un servicio?
    1. ¿Hemos analizado la real necesidad para el negocio, de algún cambio o de una nueva implementación?
    2. ¿Hemos entendido a cabalidad la envergadura del cambio requerido?
    3. ¿Hemos analizado los pre-requisitos?
    4. ¿Hemos identificado todos los datos involucrados y contamos con los correctos y necesarios?
    5. ¿Hemos evaluado los pormenores de nuestras acciones y planeado la ejecución de la tarea?
    6. ¿Hemos evaluado los riesgos antes, durante, y después de la ejecución planeada?
    7. ¿Hemos asegurado que contamos con lo necesario antes de empezar la tarea?
    8. ¿Contamos con mecanismos de remediación/recuperación/reversión realmente probados?
  2. ¿Cuántas veces hemos ingresado valores por defecto?
    1. Y no nos hemos preocupado de analizar y evaluar antes cómo se vería afectada nuestra seguridad, que tanto cuidamos, por estos valores.
    2. Por apuro/cansancio [u otra excusa de su preferencia, mi estimado lector].
    3. Por desconocimiento y por no tener a quién preguntar [o no querer preguntar por vergüenza].
    4. Y los dejamos así, sin evaluar cómo se ve afectada nuestra seguridad, que ya descuidamos, por nuestra acción.
  3. ¿Cuántas veces nos limitamos a las pocas opciones que el proveedor ha implementado en la herramienta [antigua o nueva]?, y sobre las que nos ha capacitado, ambas cosas por puro cumplimiento, pero luego no buscamos o aprendemos más allá [con lo que desperdiciamos la herramienta]
  4. ¿Cuántas veces nos limitamos a una determinada plataforma, y no entendemos que nuestro conocimiento es aplicable a otras, por igual? ¿O sólo llegamos a manejar información?

Y, ¿entendemos realmente en dónde y cómo debemos enfocar la seguridad?

  1. ¿Cuáles son las características únicas del negocio, mercados, clientes, infraestructura, industria?
    1. Todos estos aspectos informan la política de seguridad y cada empresa tiene problemas diferentes.
    2. Antes de comenzar a adquirir herramientas, ¿quién entiende de seguridad en la empresa?
  2. ¿Reconocemos que las habilidades de gestión de proyectos centradas en la seguridad son extremadamente importantes?
    1. Necesitamos descubrir cómo integrar las diferentes soluciones de seguridad que hemos identificado como necesarias, con el resto de los sistemas, agregar capacitación, mantenimiento, actualizaciones, por nombrar algunas.
    2. Y todo esto, ¿cuánto tiempo tomará, sujeto a qué presupuesto, considerando qué resultados?
  3. Las empresas están aprovechando DEVOPS y la automatización para poder gestionar el panorama de amenazas. Recordemos que DEVOPS es una forma de pensar y un enfoque para el desarrollo de software y los procesos de lanzamiento, no una categoría de producto o certificación específica.
    1. ¿Qué debemos considerar para implementar DEVOPS o cualquier otra opción, apoyando la agilidad y flexibilidad?
    2. ¿De qué manera, si aceptamos lo anterior, impacta en nuestra TI [bimodal]?
  4. ¿Estamos empleando en realidad un pensamiento crítico para [realmente] evolucionar?
    1. ¿Ya actualizamos nuestro FODA situacional?
    2. ¿Contamos con un real FODA estratégico? ¿o sólo nos enfocamos en debilidades?
    3. ¿Ya identificamos lo que verdaderamente necesita el negocio para prosperar, y la seguridad relacionada?
    4. ¿Conocemos y entendemos realmente nuestro ecosistema?
    5. ¿Ya actualizamos nuestro análisis de brecha?
    6. ¿Ya hemos puesto en marcha nuestra estrategia para cerrar la brecha?

No olvidemos identificar primero lo que debemos mejorar, cuál es la mejora, qué buscamos obtener con la mejora, cuándo realizarla, con qué recursos y capacidades contamos para llevarla a cabo, el cómo la llevaremos a cabo, quién será responsable de llevarla a cabo, y quién será responsable de los resultados para el negocio

  1. ¿Hemos incrementado nuestras destrezas programando, enfocados en la automatización?
    1. ¿Aprendimos nuevos lenguajes de programación?
    2. ¿Ya nos habituamos al entorno de línea de comando (CLI)?
  2. ¿Ya aprendimos a utilizar las soluciones de seguridad que se han implementado?
    1. ¿Sabemos ya por qué falló nuestra reciente implementación de DLP o SIEM, u otras opciones?
    2. ¿Seguimos dependiendo del proveedor del servicio para los incidentes? ¿o seguimos llamando a todo ‘problemas’?
    3. ¿Reconocemos dónde erramos, y por qué erramos? Sí, nosotros erramos. La tecnología falla, y se puede corregir. ¿Podemos decir lo mismo nosotros?
  3. ¿Entendemos que la experiencia ganada no se puede perder?
    1. ¿Cómo garantizamos la permanencia del personal clave relacionado con la seguridad?
    2. ¿Cómo aseguramos que el conocimiento adquirido [en la empresa] no se vaya con el personal [junto con su experiencia]?
    3. ¿Hemos desarrollado alguna forma de gestión del conocimiento?
  4. ¿Estamos en capacidad de realizar una autopsia o investigación forense después de un, digamos, ‘incidente’?
    1. ¿Nos interesa, pero no tenemos tiempo o recursos o competencias?
    2. Luego de nuestro análisis y evaluación de vulnerabilidades, utilizando nuestro recientemente adquirido conocimiento en hackeo ético, ¿se nos pasó algo? Claro, sino, no hubiera ‘incidente’.
    3. ¿No sería bueno aplicar nuestros conocimientos de hacking para apoyar a cerrar la brecha? Cierto, eso lo hace otro especialista ¿o no pensamos así?
  5. ¿Cómo están de maduras nuestras habilidades blandas?
    1. Serían útiles para determinar posibles amenazas internas a la organización ¿no creen?
    2. Serían útiles para entender el comportamiento de los usuarios frente a los esquemas / perfiles de seguridad que se implementan
  6. ¿Hemos identificado que un punto importante en este tema de seguridad, así como en muchos otros, es la pasión por lo que se hace?
  7. ¿Reconocemos si somos capaces de afrontar la implementación de distintas normativas de seguridad, consolidarlas, y ser eficiente en la implementación de los controles, sin afectar las metas de negocio?
  8. ¿Reconocemos que aún nos falta recorrer mucho en cuanto a seguridad?
    1. Verdadera proactividad
    2. Verdadera previsión [anticipación]
    3. Verdadera innovación
    4. Lidiar con nuestra rigidez cognitiva en ciberseguridad
    5. Planeamiento consciente y consistente de la seguridad
    6. Controlar realmente, monitorizar y tomar acción rápida y efectiva ante cualquier incidente
    7. Valorar lo importante para el negocio, en cuanto a la seguridad
    8. Asegurar que el alineamiento / articulación entre el negocio y la tecnología sea real y efectivo, considerando la seguridad
    9. Establecer correctamente los factores críticos de éxito, sus indicadores clave de rendimiento y las métricas asociadas, en cantidad y propiedad correctas
    10. Evitar postergar lo importante
    11. Reducir las ‘emergencias’
    12. Adoptar la seguridad y la calidad como una forma de vida
    13. Implementar correctamente marcos de trabajo, gobierno, estándares, buenas prácticas
    14. Respetar políticas, normas, procedimientos
    15. Madurar procesos, personas, y tecnología –cierto, también la empresa en su conjunto
    16. Pruebas reales, orientadas, contextuales, personalizadas, controladas, completas
    17. Automatización al máximo, identificando las posibilidades reales de nuestra plataforma tecnológica, y utilizándola al máximo con apoyo de nuestras destrezas
    18. Aprender de nuestra experiencia
    19. Asegurar lo aprendido
    20. Mejora continua –incluyéndonos a nosotros mismos
    21. Gestionar el conocimiento
    22. Muchos otros

Conclusiones

Sí, la seguridad parte del sentido común; es un compromiso, es algo que se adopta, se interioriza.

Reconozcamos que, en la seguridad, sí intervienen las habilidades tratadas, no sólo se trata de capacitarse [o certificarse].

Es y debe ser parte integral de la cultura del lugar de trabajo.

Es fácil encontrarnos con un ‘problema’ y decir que, con una nueva tecnología o herramienta, lo resolvemos. Esto es una falacia. ¿No será que encontramos un incidente [que es, además, repetitivo] y, dadas diferentes, digamos, situaciones, optamos por lo más fácil –y decimos que ‘transferimos’ el riesgo? Hagamos nuestra tarea primero, y bien.

Y sí, Deming con su PDCA está presente, incluso en la seguridad.

Una buena persona de seguridad tendrá una gran pasión por compartir, aprender y hacer crecer sus conocimientos todo el tiempo.

¿Coinciden conmigo en que las destrezas y habilidades antes presentadas tienen mérito de ser consideradas? ¿Y han considerado desde qué edades deben ser incorporadas en nuestro ADN? Interesante ver el resultado en unos años.

Fuerzas impulsoras – Fuerzas de resistencia [restricción]

Pongámonos en situación

Seguramente hemos enfrentado, en más de una oportunidad, resistencia al cambio.

¿Sabemos quiénes favorecen cambios en pro del negocio, y quiénes no?

¿Buscamos mejorar o no salir de la zona de confort [de mantener el statu quo]?

¿Buscamos que el negocio gane o que nosotros ganemos?

¿Cómo afectamos a la organización con nuestra decisión [o posición] al respecto?

Las anteriores son interrogantes importantes que debemos resolver. Sabemos que es importante que todos en la organización estemos alineados con los objetivos institucionales.

¿Dónde están establecidos los principios rectores para las decisiones anteriores? ¿Ética, moral, valores?

Apreciamos que están involucrados diferentes fuerzas de consideración: personas (conocimiento de nosotros mismos), hábitos, costumbres, actitudes, motivaciones.

Roosevelt (ex presidente de USA, 1939), nos invocaba a dejar de reaccionar ante los eventos y las emociones y aprender a elegir nuestra propia respuesta ante cualquier situación. Recordemos parte del célebre discurso de Kennedy (ex presidente de USA, 1961), y pongámoslo en contexto: “no pregunten qué puede hacer su país [la empresa] por ustedes, pregunten qué pueden hacer ustedes por su país [la empresa]”.

Si deseamos realizar cambios, primero identifiquemos los cambios y las fuerzas relacionadas

Significa que necesitamos caracterizar la naturaleza del cambio; esto es, identificar, clasificar y tratar con las fuerzas que están trabajando por y en contra de nosotros cuando estamos tratando de implementar cualquier tipo de cambio en la organización [o nuestro lugar de trabajo].

Sobre una organización, considerando que requiere realizar algún cambio (la expectativa, el deseo, la necesidad, el objetivo, el diferenciador), requerido por aspectos tan diversos como (fuerzas impulsoras):

Podríamos empezar por preguntarnos:

Tendríamos, por tanto, que identificar y evaluar las fuerzas de resistencia [restricción] que surgen por:

  • El temor a lo desconocido.
  • Estructuras organizativas existentes.
  • Actitudes ‘Así no es como lo hacemos aquí’.
  • Compromisos existentes con organizaciones asociadas.
  • Legislación o regulaciones gubernamentales.
  • Contratos previos.

Así que, podríamos continuar preguntándonos, buscando identificar:

Podemos considerar herramientas como la 6W-2H para caracterizar las opciones.

A tener en cuenta

Recordemos que, desde hace ya muchos años, vivimos en un estado de cambio. Este estado reemplazó la sensación de certeza, estabilidad y familiaridad a la que estábamos acostumbrados. Este tipo de entorno se puede describir utilizando el acrónimo “VUCA”, que significa “volátil”, “incierto”, “complejo” y “ambiguo”, por sus siglas en idioma inglés.

Tengamos en cuenta que una conciencia de las fuerzas representadas en el modelo VUCA y las estrategias para mitigar el daño que pueden causar son parte integral de la gestión de crisis y la planificación de la recuperación de desastres.

Para resolver las interrogantes anteriores, seguramente requeriremos la participación de otras personas, como los miembros del equipo o expertos dentro de nuestra organización, clientes, partes interesadas externas y personas de la industria, entre otros. Recordemos, no estamos solos. Seguramente habrá alguien más que comulgue con nuestras ideas. Démosles la oportunidad de aportar opciones y de fortalecer nuestros argumentos.

Sí, lo anterior es un impulsor, así como resulta ser un freno el ver que no existe compromiso, que no se evidencia una comunicación oportuna y suficiente, se observa incumplimiento en las actividades establecidas, existe una carencia de retro alimentación, entre otros factores. Importante tenerlos en cuenta.

Busquemos obtener, mediante procedimientos diversos, como lluvia de ideas, las fuerzas relacionadas con cada cambio identificado. Tratemos que no sean muchas [trabajemos tres o cinco] para cada caso, para no desviar demasiado la atención [diversificación y, por tanto, debilitamiento de fuerzas].

Segundo, evaluamos el esfuerzo

Debemos valorar la influencia de las fuerzas. Para ello, establezcamos primero los criterios con los que trabajaremos, definamos las escalas de valoración que utilizaremos.

Busquemos obtener el consenso [aceptación, aprobación, autorización] de estos criterios y escalas, a fin de evitar, en lo posible, “marchas atrás”, “arrepentimientos”, “claridad de ideas”, “re-enfoques”, “cambio de prioridades”, otros.

A continuación, por cada cambio identificado, contrastemos ambas fuerzas y valoremos su influencia, utilizando los criterios y escalas antes establecidos.

Ordenemos, evaluemos, y prioricemos, teniendo presente que, a veces, es más fácil reducir el impacto de las fuerzas restrictivas que fortalecer las fuerzas impulsoras.

Conviene, por tanto, una vez identificado el cambio a trabajar, realizar un análisis de brecha, con el fin de determinar a fin de gestionar, con mayor detalle, entre otros aspectos clave, los plazos, presupuestos, recursos, capacidades, el valor esperado del cambio.

Para ello, un análisis FODA podría ser de mucho interés, para responder a las situaciones siguientes, entre otras:

  • ¿Cómo se desempeña actualmente mi área/unidad/organización?
  • ¿Cuáles son nuestras fortalezas y cómo podemos capitalizarlas?
  • ¿Hay alguna debilidad en el rendimiento general de nuestra área/unidad/organización?
  • ¿Dónde podemos mejorar?
  • ¿Cuáles son los factores externos o internos que están impactando nuestro futuro?
  • ¿Cuál es el posible impacto en las personas/en el negocio de las perspectivas futuras actuales?

Recordemos darle el tiempo apropiado y oportuno a lo importante, para que lo [realmente] urgente no nos abrume.

Formulemos nuestras estrategias de acción

¿Dónde están establecidos los principios rectores decidir nuestro comportamiento frente a las diferentes fuerzas?

¿No están claros los objetivos, no han sido apropiada y oportunamente difundidos e interiorizados, o no existen?

¿No son apropiados nuestros enfoques o formas de abordar la evaluación de opciones para decidir la alternativa más apropiada?

¿Tenemos forma de decidir cuál de las fuerzas tiene cierta flexibilidad para el cambio?

¿Tenemos forma de identificar sobre cuál de las fuerzas se puede influir?

Si hemos calificado cada fuerza, pensemos [planeemos] ¿cómo se puede [primero] reducir las amenazas que presentan las fuerzas restrictivas, [segundo] aumentar las posibilidades de las fuerzas impulsoras, o ambos?, [tercero] actuemos en consecuencia.

Podríamos, por ejemplo, considerar establecer un sentido de urgencia, con el fin de que la organización entienda por qué el cambio ya no es opcional, y apoye a que se realice, porque desea incrementar [sino, al menos, mantener] su valor.

Este sentido de urgencia puede impulsar el cambio, y reunir a las personas correctas [esperamos que en la oportunidad correcta] que aportarían al cambio de forma efectiva.

Recordemos que debemos definir las acciones que se requiere sean completadas con el fin de cumplir con el cambio propuesto, y de establecer un plan de acción [las acciones enumeradas en este plan de acción deben comenzar con un verbo] para el cumplimiento correspondiente [operativo y de gestión, de acuerdo con la envergadura del cambio]; y de asignar una persona responsable para cada acción y una fecha concreta para su conclusión [podríamos apoyarnos con una matriz RACI y, además, con un cronograma].

Algunas tácticas

  • Pongamos sobre la mesa las consecuencias de la inacción
  • Comuniquémonos, de forma constante y transparente
  • Utilicemos nuestro lenguaje corporal para transmitir el sentido de urgencia
  • No temamos al diálogo [no sólo pongamos a disposición –o presionemos- informes]
  • Interesémonos en conseguir los resultados esperados [comprometidos]
  • Emponderemos [correctamente] las [buenas y correctas] acciones
  • Respaldemos nuestras palabras con hechos [lideremos con el ejemplo]
  • Ayudemos a evitar [eliminar] la cultura del “nosotros conocemos mejor”
  • Reconozcamos las complacencias [y trabajemos para erradicarlas]
  • Identifiquemos [tempranamente] y enfrentemos [con argumentos] a aquellos que siempre están trabajando duro para obstaculizar el cambio
  • Busquemos establecer una cultura centrada en los resultados (en lugar de enfocada en la tarea).

Probablemente necesitemos cambiar la cultura organizacional.

Conclusiones

No olvidemos que todo esto es subjetivo y, por tanto, aspectos relacionados con la salud o la seguridad de las propias personas podrían prevalecer [consciente o inconscientemente, y hasta ser esbozadas por conveniencia].

¿Necesitamos establecer que todo esto forma parte de la mejora continua [ciclo PDCA]?

Pongamos nuestra inteligencia emocional a trabajar.

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.

8 maneras de sortear [asumir] fallas

Todo profesional relacionado con las TI ha oído hablar de la ley de Murphy. Algunos creen no haberla experimentado; otros dicen no haberla experimentado; otros niegan haberla experimentado. Tal vez [aún] no se han dado cuenta.

Sabemos que un error es causa de una falla, y ambos pueden ocurrir por diferentes razones -pero, como dijo Churchill, por ni una sola excusa; y que una falla (que, dependiendo del impacto, podríamos considerar como problema), puede conducir a uno o más incidentes. Con una adecuada formación en gestión de servicios podremos determinar los ámbitos de actuación de cada uno de estos términos.

Siguiendo a Deming, luego que resolvemos la condición negativa que se presentó [y que impactó el servicio o la seguridad de la información relacionada], ¿tomamos alguna acción? ¿Evaluamos los resultados de los cambios implementados en el valor de los servicios que se entregan, y/o en la seguridad de la información? Verificar el éxito del cambio ejecutado para [al menos] mantener la calidad del servicio entregado o su seguridad es bueno pero, en adición, debemos validar que la necesidad del cambio haya sido satisfecha, desde el punto de vista de la entrega de valor del servicio (SLA, clientes) como para los stakeholder (beneficios, cumplimiento, reguladores, regulaciones, evitar demandas o pago de moras, entre otros aspectos a considerar).

La tecnología juega un papel importante en todo esto, como también lo hace la cultura [organizacional, de servicio, de calidad, de seguridad, …].

En lugar de tratar con una, digamos, oportunidad de mejora, de forma individual -y hasta aislada, ¿realmente aprendemos de esta(s) tras aplicar mecanismos sistémicos apropiados y de manera oportuna y correcta? ¿está nuestra cultura [institucional] lo suficientemente madura para esto? ¿somos realmente un referente en esto –o al menos buscamos estar en camino de serlo? ¿utilizamos herramientas apropiadas para analizar la causa raíz de las oportunidades de mejora? ¿Son estas herramientas utilizadas por colaboradores competentes? ¿Gestionamos apropiadamente el triángulo procesos-personas-tecnología? ¿Qué tan proactivos somos al respecto? ¿Están clara y completamente identificados todos los involucrados, así como los límites, restricciones, expectativas, y presiones relacionados? ¿Hay vacas sagradas o el cliente es nuestra meta, no sólo de palabra sino con acciones concretas, duela a quien le duela? ¿Entendemos que habrá efectos negativos si hacemos mal las cosas?

¿Aprendemos de los errores de los demás? A propósito de las últimas noticias sobre ransomware. ¿Están los procesos establecidos y son seguidos? ¿Tienen las evidencias necesarias –ya mismo?

¿Sabemos qué información está disponible para las personas que trabajan en resolver problemas y qué tan rápido pueden obtenerla, para que puedan desarrollar pautas claras para evitar complicar el problema debido al estrés, la confusión o la fatiga? Información contextual, oportuna, clara, correcta, vigente, y completa, así como, objetividad y enfoque en la tarea, son condiciones primordiales en estos casos.

Tal vez nos centramos en buscar culpables, primero y siempre, afectando la moral –y perdiendo tiempo valioso, sin que nos importe nuestro cliente. Evitamos, consciente (limitaciones, presiones, carencias, inexperiencia, otros) o inconscientemente (confiamos ciegamente que la acción correctiva evaluada, elegida, y llevada a cabo es la definitiva), responder a la pregunta: si asumimos que podría ocurrir nuevamente, ¿cómo responderíamos mejor esta vez? ¿Son nuestros reportes del tipo ‘lecciones aprendidas’ (en sentido positivo) o del tipo ‘post mortem’ (en sentido negativo)?

Claro, errar es humano, y las estadísticas nos dicen que el ‘error humano’ bordea el 70% como causa de accidentes de tránsito en Lima. Bueno, tenemos factores como condiciones físicas del conductor (estado de alerta/lucidez, velocidad de reacción, ingestión de elementos alucinógenos o de bebidas alcohólicas, fatiga-cansancio-somnolencia), atención a la tarea –y no al celular, a la radio, al copiloto(a), exceso de confianza, temeridad, condiciones del vehículo, velocidad, estado de las vías, [des]conocimiento del reglamento de tránsito, señalización adecuada (bueno, si ‘Pepe el vivo’ las respeta porque ‘no hay policía que me vea’ ‑cuando el policía debía estar dentro nuestro), estilos de conducta en contextos de tráfico en relación a las variables: edad cronológica; estado civil; grado de instrucción; lugar de procedencia; pertenencia del vehículo; la conducción como ocupación principal; tiempo en la conducción; accidentes de tránsito; papeletas recibidas por infracciones; problemas de salud; problemas auditivos; problemas de motricidad; problemas familiares y problemas emocionales, entre otros. Nos damos cuenta que hay fallos activos (errores y violaciones, actos inseguros que tienen un impacto directo y son cometidos por los trabajadores que operan el ‘sistema’), y condiciones latentes (resultado de decisiones de los diseñadores y gerentes, las que se expresan en las condiciones del entorno, la política y cultura organizacional; influyendo así el desempeño de los trabajadores). Listo, introduje la palabra ‘sistema’ así que no nos salvamos y aplicamos el caso a las TIC. El verdadero problema son las herramientas y los procesos que no impiden (o al menos emiten advertencias sobre) los errores inevitables que la gente hace, o la falta de automatización que significa, en primer lugar, que alguien está haciendo una labor manual –posiblemente propensa a errores y con errores en la fuente. Por ejemplo, podría haber carencia u obsolescencia de documentación, procesos, procedimientos; tal vez exista un desconocimiento del ecosistema tecnológico en la empresa; podría no existir o ser inadecuado o estar mal programado el monitoreo, control, supervisión; podría no haber auditoría interna de seguimiento o ser aceptados y trabajados sus resultados; podrían no darse de manera oportuna y completa, o no sustentarse apropiadamente las inversiones necesarias desde el punto de vista del valor para el negocio; entre otros factores de consideración.

Tengamos presente que los errores podrían ser tolerados, pero no el ocultarlos o encubrirlos. Entendamos que hay valor en invertir en el desarrollo y el fomento de una cultura en la que los colegas reconozcan errores y errores de juicio, y apoyarlos para que reporten aquellas cosas que casi originaron una falla. Tratar la TI y la seguridad como un servicio del negocio en lugar de un punto de control ayuda a crear ese tipo de cultura.

No olvidemos la deuda técnica -el costo y los intereses a pagar por hacer mal las cosas (presión en el cronograma, escasez o carencia de recursos apropiados o suficientes, entre otros factores, que obligan a saltarse pasos [o funcionalidad]) –y que no se ven desde fuera, pero causan daño dentro –no nos engañemos con la falacia del “costo hundido”. La famosa filosofía “si funciona, no lo toques”, puede ser un grave error. La modernización tecnológica (de los activos críticos del servicio) y su seguridad ([in]cumplimiento, riesgos para el negocio si el activo se ve comprometido) es algo mandatorio en estos tiempos; sin embargo, es necesario planificar esta modernización.

Recordemos que la información resultante debe transparentarse, difundirse, utilizarse, proactivamente. Evitemos reinventar la rueda. Avancemos. Contribuyamos con el conocimiento. ¿Somos lo suficientemente maduros verdad? Se nos mide por lo que hacemos, no por lo que decimos que hacemos.

ITIL®, COBIT®, PMBOK®, entre otros frameworks

Sabemos que para gestionar las TI existen diferentes framework o marcos. Están también los viejos conocidos como COBIT® y el PMBOK®.

Recordemos que un marco es una estructura real o conceptual destinada a servir como un soporte o guía para la construcción de algo que expande dicha estructura en algo útil. Es necesaria para evitar re-inventar la rueda (la tecnología, y su eficiencia) y enfocar esfuerzos (recursos, capacidades, presupuestos, entre otros) en las reglas del negocio. La necesidad de emplear un marco es variable, y hasta cierto punto. No olvidemos que hay que adoptar y adaptar las cosas a nuestra realidad.

Por ejemplo, ayer un exalumno estaba esperando rendir su examen de certificación en ITIL® Fundamentos, el cual aprobó, y me contó mientras esperaba, que recién con el curso que le di entendió todo lo que en su empresa existía desplegado referente a ITIL®.

Bueno, lo cierto es que ITIL® estaba desplegado, implantado, pero no estaba interiorizado, no había sido adoptado. Este mismo exalumno lo reconoció. Los usuarios internos no tienen conciencia de por qué hacen las cosas; simplemente las hacen -cumplen. Los que apoyan o administran los servicios, tampoco, ya que se preocupan por que sus ‘indicadores’ no arrojen resultados negativos. En general, la empresa no entiende lo que es una apropiada gestión de servicios –y este ex alumno me comenta que hay varios certificados en ITIL. Esto último es una mala propaganda y por ello muchas empresas no confían en las buenas prácticas de ITIL (no ahondaré si es la empresa la que ocasiona esto con su cultura o es producto de una adecuada aplicación). Los usuarios utilizan las herramientas principalmente para controlar tickets. Aparte de utilizarla mal, encima desconocen las verdaderas capacidades de la herramienta. Los nuevos usuarios no son capacitados; la capacitación utiliza el método Inca (de boca en boca); y otras situaciones que me enteré. Una pena, por la empresa y por sus clientes –mi opinión, ya que no importa cuán brillante es el producto o si hace mil cosas; si no estamos proporcionando el resultado que el usuario final espera (el valor del servicio que está pagando), estamos fracasando. Una noticia al respecto aquí (ojo, no es la empresa de la que hablo) que generan costos innecesarios de compensación y remediación, querellas judiciales, pago de moras, auditorías inopinadas, pérdida de beneficios, demandas judiciales, entre otros aspectos negativos. No es de extrañar saber de proyectos ‘de éxito reservado’, por asignación inadecuada o inoportuna de recursos, plazos excesivamente agresivos –algunas veces exigidos sin base o beneficio para el negocio, costos subestimados, requisitos olvidados –o mal identificados, complicaciones imprevistas –que no faltan, un mal gobiernos, y los [consabidos y omnipresentes] errores humanos como código defectuoso.

Lo anterior nos hace preguntarnos ¿para qué me servirá aplicar el marco tal o cual? Ojo, aplicar, no imponer. Resulta obvio revisar nuestra necesidad concreta y el enfoque de nuestra necesidad, alternativas –reales- de solución, compromiso con la adopción correctamente elegida, no mero cumplimiento –o moda.

Recordemos que hay una herramienta correcta para cada necesidad, la cual debe utilizarse en el momento preciso y por quien conoce cómo utilizarla –desde la primera vez.

Al igual que con cualquier proyecto, siempre se debe mantener las líneas de comunicación abierta entre las distintas partes, medir y monitorear el progreso de la implementación y buscar ayuda externa si es necesario.

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.

13 fuerzas que dan forma al futuro de la TI

La tecnología siempre nos sorprende, ya sea por sus saltos cuánticos (en China, en cifrado de datos, memoria, nanotecnología) o, al menos, por una constante evolución y socialización (desde las primeras herramientas de la Edad de Piedra, hasta las supercomputadoras de hoy). La fuerza impulsora es variada, desde la supervivencia hasta más allá del mero conocimiento o descubrimiento, pasando por guerras y riquezas.

Con respecto a las tecnologías de la información, las fuerzas son varias. En ese sentido apoyan las nuevas formas del Centro de Datos, el empleo de la computación social (redes sociales), de nuevos dispositivos (smartphones, superficies inteligentes, IP-TV, 3D) o formas de trabajo (BYOD seguras), o de nuevas formas de lugar de trabajo (autenticidad, transparencia, confianza, cultura, cambios demográficos, virtual, entre algunas formas).

Algunas ya son conocidas. Tenemos, por ejemplo, (1) automatización de las tareas comunes (pero controladas), que decanta en (2) velocidad para tomar decisiones y desarrollar estrategias que tengan un impacto directo en el negocio, (3) agilidad entre departamentos estableciendo habilidades blandas y colaboración eficiente, y (4) flexibilidad requerida para hacer frente a la competitividad globalizada  y siempre cambiante de nuestro mundo actual (coyuntura, mercado, gustos, preferencias, servicios, entre otros factores a considerar), que genera una (5) hipercompetición la cual conduce a acuerdos de menor costo en el mercado de compradores de servicios TI, siendo la amenaza real la sostenibilidad de estos acuerdos, la (6) consumerización porque el comportamiento de los consumidores tiene el poder de redefinir el modo en que las empresas de TI trabajan, sin olvidar que todo eso acarrea problemas de (7) seguridad y privacidad, tanto en la identificación de los agujeros en la seguridad como en la búsqueda de talento para hacerles frente, y la necesidad de que el (8) gasto en TI esté más gobernado que antes.

Otras son innovadoras en su planteamiento. Tenemos, por ejemplo, una mayor (9) colaboración entre TI y otras unidades de negocio, además que la nube proporciona más opciones que antes (controlando aspectos de nivel de servicio, seguridad en la transmisión y almacenamiento de datos, localización de datos, entre otros a considerar), siendo su utilización muchas veces resultado de decisiones estratégicas y tácticas para la tecnología impulsadas por las unidades de negocio no-TI, o la creación de una (10) simbiosis entre la automatización, que provee los datos suficientes y patrones repetibles, y la inteligencia artificial para impulsar el proceso, de modo que, considerando (11) la información correcta, en el momento y lugar adecuados (ubicuidad de la información), se podría acelerar el desarrollo y la puesta en marcha de nuevos servicios.

Otras son resultado de la (12) acumulación de datos, y la necesidad inherente de aplicar (13) analítica. No perdamos de vista que los servicios financieros también serán alterados radicalmente –no sólo por el ransomware, lo que acarreará también mayores innovaciones en las TI.

Varias maneras de mejorar tu SLA

Es importante revisar cómo este tema avanza y, aunque lo vemos a diario ya que las bases están cubiertas, aún no lo interiorizamos apropiadamente.

Ya hemos conversado sobre la importancia que reviste un SLA apropiado para colocar servicios en la nube, aunque los proveedores de servicios en nube son (normalmente) reticentes a cualquier modificación en sus SLA estándar.

También hemos comentado cómo para una TELCO 2.0, un SLA correctamente ideado e implementado es un diferenciador importante, y una garantía de éxito.

Has contratado un servicio que establece lo que está comprendido en él y lo que no (alineado con los objetivos del negocio –estando articulados TI y el negocio en primer lugar –objetivos, expectativas, planificación, rediseño de procesos pueden ser factores previos importantes de considerar), y su vigencia.

El servicio contratado contempla recursos y capacidades que se deben entregar, está sujeto a restricciones, a plazos, a una calidad en la prestación, disponibilidad comprometida, responsabilidades de cada parte, procedimientos de escalamiento, pago, compensaciones, entre otros factores. Decir que se entrega algo que ha sido contratado no es lo mismo que evidenciarlo. Lo que buscamos son evidencias de dicho cumplimiento. Para ello gestionamos el servicio al establecer los estándares de medición, procedimientos para los reportes (contenido, frecuencia, entre otros aspectos a considerar), procesos para resolver controversias, cláusulas de indemnización en caso de incumplimiento por propios o terceros, mecanismos de actualización del SLA sobre todo cuando cambian los requisitos del servicio por cambios en la coyuntura socio-económica-cultural, modernización de la tecnología subyacente, cambios en las cargas de trabajo, existen mejoras en los procesos y herramientas de medición, o los recursos o las capacidades del proveedor del servicio (interno, y lo llamamos OLA o nivel de servicio organizacional, o externo, los SLA).

Chris Drumgoole, de Terremark, nos dice que “todo el mundo sabe que las cosas se rompen – es la naturaleza de la vida. Es cómo responder a las cosas que se rompen lo que te diferencia como proveedor de servicios en la nube”.

Entonces, resulta razonable establecer criterios para desarrollar las métricas que ambas partes deberán utilizar para realizar sus mediciones. Comúnmente medimos la disponibilidad del servicio, la tasa de defectos, la calidad técnica (incluyendo precisión y exactitud), tiempo de respuesta del personal de soporte, nivel de seguridad, velocidad, capacidad de respuesta y la eficiencia. Todo esto y más dependiendo del servicio contratado. Es más, podríamos considerar como SLA los resultados del negocio, una evolución más para reflejar la adición de nuevos servicios. Lo importante es que estas métricas hayan sido definidas con cuidado, sean periódicamente revisadas y actualizadas, sean las realmente necesarias, puedan realmente obtenerse (si es automático, mejor), estén controladas, tengan sentido, y motiven un comportamiento apropiado de ambas partes.

No debemos olvidar nuestro ecosistema tecnológico, el que controlamos normalmente (independiente de nuestro modo de operación), y el que aparece con el Shadow IT el cual también debe ser apropiadamente gobernado. Es evidente debemos incluir la Shadow IT en la Gestión de eventos, incidentes, problemas y solicitudes y, por ende, estaría representada esta gestión en los contratos con terceros o UC según ITIL®, y formaría parte del sistema de reportes de rendimiento y cuadros de mando.

Esto ayuda a incrementar el reconocimiento del valor que entrega IT al negocio como un todo.