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.

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.

Cómo la organización necesita capacitar a sus colaboradores en ciberseguridad

Las encuestas seguramente mostrarán que los trabajadores siguen violando las políticas de seguridad para seguir siendo productivos.

Las amenazas de información modernas vienen en muchas formas: de los hackers que buscan robar propiedad intelectual a los empleados inconscientes que no saben que están poniendo los datos en riesgo.

Cierto, los seres humanos somos el eslabón más débil –hasta que los hacemos un activo fuerte.

[Sin duda] la empresa capacita a sus colaboradores de acuerdo con su política de seguridad para inculcarles el papel crítico que desempeñan en mantener su lugar de trabajo seguro mediante una vigilancia más estrecha para proteger contraseñas personales y datos confidenciales, y en reconocer las amenazas (¿ransomware por ejemplo?).

Toquemos el punto de la capacitación y preguntémonos:

  • ¿cómo realizamos estas capacitaciones? Por ejemplo, en línea o presencial, otras formas
  • ¿en dónde realizamos estas capacitaciones? Por ejemplo, en un local especialmente acondicionado (interno o interno a la organización), en la oficina del jefe inmediato, en el módulo de trabajo del colaborador al cual reemplazará o con el cual trabajará, otros
  • ¿en qué oportunidades realizamos esta capacitación? Por ejemplo, el primer día/semana/mes de labores, tan pronto o luego que el colaborador ha ingresado, o antes que el colaborador se integre formalmente a la empresa, agrupamos los colaboradores ingresantes en un periodo determinado, una vez al año, por pedido expreso, por necesidad evidente [una re-capacitación por ‘afianzamiento’ tal vez], otras opciones
  • ¿cuál es el propósito de la capacitación? Por ejemplo, una inducción, la que esperamos no sea sólo de seguridad ocupacional, difundir la política institucional, difundir la política de seguridad, aclarar el acuerdo de confidencialidad que el colaborador firmará al ingresar a laborar y que le será recordado por el área competente al retirarse de la empresa, otros
  • ¿mantenemos un registro de las capacitaciones realizadas? Por ejemplo, en archivo texto, hoja de cálculo, archivos personales, base de datos, otros, y consideramos también las evaluaciones de entrada y de salida, tanto de colaboradores como de capacitadores
  • ¿cómo aseguramos la asistencia? Por ejemplo, por disposición normativa, coordinación con el jefe inmediato, obligación contractual, amenaza a la continuidad laboral por incumplimiento, otros
  • ¿cómo controlamos la asistencia y entrega/accedo al material correspondiente? Por ejemplo, identificación de la computadora desde donde realizamos la capacitación [dirección IP, nombre de máquina], identificación del usuario que ingresa al módulo en línea de capacitación, presencial con un supervisor, listado actualizado de participantes, otros
  • ¿mantenemos un historial de estas capacitaciones por cada colaborador? Por ejemplo, para emplearlas como insumo de la evaluación semestral o anual
  • ¿de qué manera aseguramos el resultado esperado –y continuo- de esta capacitación? Por ejemplo, evaluaciones inopinadas periódicas con registro de resultados en el archivo personal, resultados tangibles [objetivos] de labores realizadas registrados en el archivo personal, otros
  • ¿por qué realizamos estas capacitaciones? Por ejemplo, por mero cumplimiento normativo, porque así lo pidió el jefe [actual], o porque la empresa realmente ha interiorizado la necesidad, entre otros
  • Seguramente tenemos algunas otras inquietudes. Compártanlas por favor, en beneficio de todos.

Démonos cuenta [si aún no lo hemos hecho] de que la seguridad es un facilitador.

Crear una cultura de seguridad en una empresa puede ser complicado. En la organización la cultura implica una balanceada intersección entre personas y organización –es lo que hace únicas a las empresas, afecta la forma en que implementamos las cosas y lo que tiene sentido en el ecosistema de la organización.

En este ecosistema, los profesionales de la seguridad de la información debemos darnos cuenta que hemos evolucionado de siempre ser vistos como meramente tecnólogos, a gente de proceso, a ser verdaderamente un socio comercial y profesional de negocios -me incluyo ¿te incluyes?

En aras de afianzar esta cultura de ciberseguridad, por ejemplo, nada como ser transparente en qué estamos haciendo y cómo lo estamos haciendo los profesionales de la seguridad de la información, y explicarlo en el lenguaje del negocio -¿de qué manera lo haces tú?

Pero, también es obvio que la organización debe evolucionar, debe buscar un equilibrio entre proteger los datos y capacitar a los colaboradores para que sean productivos (no olvidemos la triada procesos-personas-tecnología), incorporando los altos ejecutivos del negocio en este esfuerzo de capacitación para que entiendan a cabalidad [y con esfuerzo y tiempo, también interioricen que no es sólo responsabilidad del departamento de TI] los requerimientos y necesidades de ciberseguridad [algo que ya no se puede ignorar].

La organización busca protegerse contra el mal comportamiento del usuario final, amenazas de día cero, sitios Web comprometidos y hacks entre equipos de escritorio y entre equipos de escritorio y servidores, seguramente empleará para esto alguna herramienta especializada (¿secure desktop as a serviceSDaaS?).

Bastante se ha hablado también que no es una cuestión de si vamos a ser atacados [o que vaya a violar nuestra seguridad], es una cuestión de cuándo esto ocurrirá, y que debemos estar preparados.

El problema seguramente es cómo lograr que tanto la organización como los colaboradores interioricen esta necesidad y objetivo –de manera continua porque, recordemos que la seguridad es un proceso, no un producto.

¿Cómo pueden las compañías asegurarse de que sus políticas y procesos de seguridad estén al día con las amenazas modernas? Una política de seguridad clara y bien entendida sería un inicio. Una sensibilización y formación [en contraposición (o complemento tal vez) a una capacitación] apropiadas, seguidas de las auditorias correspondientes, serian también aconsejables. El tipo de sensibilización [compromiso e interiorización posterior] que logremos en estos programas de formación es la clave. Enfrentamos entonces el cómo, cuándo, con qué, quién, para qué, formamos y hay un desafío en el contenido y orientación de la formación.

Como estado, es evidente que hay bastante más que hacer. Los esfuerzos de PCM-ONGEI podrían no ser suficientes y están lejos de ser completos.

En el ámbito educativo, algunas universidades contemplan carreras de ingeniería que incluyen cursos de ciberseguridad en su currículo, y otras ofrecen carreras especificas relacionadas con la seguridad informática; sin embargo, este interés en la seguridad de la información se centra aún –erróneamente- en carreras de ingeniería relacionadas con las tecnologías de la información.

Las certificaciones ayudan, pero, a pesar que hay un gran número de ellas, podrían no ser suficientes [en el tiempo] o apropiadas [orientación, alcance] para todo tipo de organización [deberemos tener en cuenta sus prioridades, objetivos y metas estratégicas, sus impulsores de valor].

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.

¿Quién desea una TI Bimodal?

¿Quién desea una TI Bimodal?

Según Gartner, bimodal es la práctica de la gestión de dos estilos distintos pero coherentes de trabajo: uno centrado en la previsibilidad; la otra en la exploración.

Revisemos:

  • El Modo 1 (más gobierno, menos cambio) está optimizado para las áreas que son más predecibles y son bien entendidas. Lidiamos aquí con, pero no limitados a, estabilidad, robustez, estándares, planificación cuidadosa, cumplimiento, gobierno, riesgos, eficiencia, seguridad, precisión, disponibilidad, presupuestos, niveles de servicio y requisitos.
  • El Modo 2 (menos gobierno, más cambio) es exploratorio [pero requiere un enfoque riguroso y disciplinado -para que las cosas no se escapen de las manos], experimentando para resolver nuevos problemas, agilidad centrada en el tiempo de lanzamiento al mercado [velocidad], la rápida evolución de la aplicación y, en particular, la estrecha alineación con las unidades de negocio.

En la siguiente figura Gartner gráfica lo anterior:

Estas iniciativas a menudo comienzan con una hipótesis que se prueba y se adapta durante un proceso que implica iteraciones cortas, adoptando potencialmente un enfoque de producto viable mínimo (MVP) -experimentación.

Tengamos presente que un equipo de TI exploratorio no es fácil porque tienes que desafiar el pensamiento convencional [de las personas, claro], aceptar los riesgos [la empresa] y sentirte cómodo con un ritmo de cambio [motivación de todos] que es muy diferente de la forma actual en que opera TI.

Ninguna iniciativa es igual a otra, dadas las particularidades de cada negocio, mercado, o empresa. Cada empresa debe conocer su ecosistema, para adaptarse conforme convenga, e innovar rápidamente para responder a las amenazas y oportunidades.

Sabemos que, en el contexto empresarial, el estilo de trabajo, el modelo de decisión y la gobernanza, son los que hacen la diferencia; por tanto, cada empresa debe evaluar -a través de prueba y error- cómo enfrenta este paradigma, porque seguramente requerirá equipos multidisciplinarios [manpower], consultorías, nuevos contratos de soporte, nuevas negociaciones, nuevas herramientas, nuevos procesos, nuevas competencias, nuevas habilidades, nuevos conocimientos, nuevos recursos, y nuevas capacidades. No dejemos de lado el costo total de propiedad y los niveles de servicio acordados.

Seguramente deberemos considerar incluir cosas como aplicaciones móviles y su desarrollo, experiencia para el lado del cliente, IoT [Internet de las cosas] para obtener cierta experiencia en la captura de grandes flujos de datos y analizarlos desde diferentes dispositivos, ya sean estos dispositivos de consumo, dispositivos industriales, lo que se tenga a mano. Podría acabar ocurriendo que los ingenieros recién entrenados quieren usar nuevas técnicas en sistemas antiguos, y crear silenciosamente work-arounds en lo que se ha conocido como “shadow IT“. Trataríamos entonces de incorporar y estandarizar esta shadow IT y permitir a los innovadores innovar, pero dentro de la estructura corporativa. Esto implicaría una reingeniería de la gestión tecnológica y del papel de la empresa en su implementación.

Pero, tengamos presente que no por utilizar métodos ágiles o DevOps ya somos bimodales. La organización también está involucrada, no solo es un asunto de pura tecnología. Tampoco significa dedicarse a producir código porque se arriesga una mayor complejidad arquitectónica y de aplicación, lo que reduce la agilidad de la empresa. Recordemos que la cadena se rompe por el eslabón más débil, ¿o será que avanzaremos siempre al paso del más lento? [el impacto en los clientes, específicamente, es parte del segundo efecto secundario].

Ambos modos son esenciales, según Gartner, [tienen una relación simbiótica] para crear un valor sustancial, e impulsar un cambio organizativo importante, ninguno es estático y, probablemente, para el futuro tampoco sean suficientes. Combinar [y balancear] una evolución más predecible de productos y tecnologías (Modo 1) con lo nuevo e innovador (Modo 2) es la esencia de una capacidad bimodal empresarial. Ambos modos juegan un papel esencial en la transformación digital.

Sin embargo, el Modo 1 podría erróneamente considerarse negativo [¿desmotivación por creer que debe mantenerse con lo legacy (islamiento), con el día a día, aunque exista la nube?]. Y no vemos que se debería centrar en la explotación de lo que se conoce, pero renovando a la vez el entorno heredado a un estado que es apto para un mundo digital –renovar el core es la clave. De igual modo, el Modo 2 podría considerarse erróneamente positivo, (siempre iterando / ¿arriesgando, sobre simplificando, sin normas, con prácticas no lineales?), y siempre debería siempre estar ¿planeando para el futuro? [¿flexibilidad?, ¿motivación por mantenerse en lo nuevo?]. Capacidad de respuesta frente a estabilidad.

¿Y si cambiamos el ejemplo de los corredores a las velocidades de una bicicleta de carrera? ¿o de blanco y negro al espectro de colores? ¿cuán segregada/dividida/segmentada podrían estar TI? Esto sugiere que este modelo bimodal podría ser una sobre simplificación de lo realmente requerido. Por ejemplo, una mejor alternativa, según John C. McCarthy, analista de Forrester, es que las organizaciones trabajen más para entender sus desafíos y hacer “los cambios necesarios para conducir la simplicidad”. El enfoque en los clientes, más que la velocidad o una disciplina en particular, es el diferenciador crítico en las empresas que están teniendo éxito.

También debemos tener cuidado y considerar que los modos podrían competir inevitablemente por los fondos, recursos, habilidades y la atención de la dirección, sin dejar de lado estándares, disciplina, reducir complejidad, gestionar riesgos, en todo momento. Ambos conceptos pueden funcionar mejor cuando son compartidos por los elementos front-end y back-end del ecosistema de TI. Iterar es bueno, pero con la verificación y la metodología de las TI tradicionales de back-end.

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

Gobierno, riesgo, seguridad [de la información]

“Se requiere mantener la seguridad de la información de la plataforma tecnológica utilizada para proveer los servicios de TI”. Sí, sí, frase trillada –pero, ¿controlamos la seguridad de la información? ¿Qué significa mantener segura nuestra plataforma tecnológica en el creciente y cambiante entorno de las amenazas a las que está expuesta?

Bueno, es el mantra de la seguridad en nuestros días pero, ¿cuánta seguridad es necesaria o apropiada, cuándo aplicarla, en dónde aplicarla, cómo aplicarla, porqué aplicarla, a quién le interesa -o afecta…? [Sí, 6W-2H].

¿La seguridad debería o podría ser implementada por demanda?[1]; implica que las organizaciones de TI cuentan con la flexibilidad de ajustar su postura de seguridad mediante la adición de la funcionalidad que sea necesaria y posible, acorde con las exigencias crecientes y cambiantes de las necesidades del negocio y de los entornos de las amenazas a las que a diario [bueno, bueno, a cada instante -dramático ¿no?] estamos expuestos -o experimentamos. Cualquier ajuste implica monitorizar para evaluar, priorizar y controlar, con la visibilidad necesaria para el negocio. Lo que pueda ser posible de implementar estará en función de la capacidad de adaptación de la organización, para una fácil y rápida implementación –recordemos que el modelo actual de la seguridad es aditivo. Las cada vez cambiantes amenazas seguramente requerirán capacidades avanzadas de seguridad [lo que desde ya es un constante desafío, el contar con defensas que respondan apropiadamente a las actuales amenazas –la dinámica de la seguridad de la información], y estaremos más o menos expuestos por nuestras [posibles] limitadas habilidades de seguridad.

No olvidemos que el costo de un dispositivo móvil robado es nada en comparación con el valor de los datos perdidos[2]. Ya hemos tratado esto varias veces antes. Fatal si el dispositivo es propio [personal] pero si el dispositivo es propiedad de una empresa –en el afán de facilitar la usabilidad (o tal vez la ubicuidad)- deberemos tener cuidado con nuestras acciones al respecto –trabas a la usabilidad- porque está involucrada la intimidad de las personas –la privacidad de los empleados (seguridad de la información de por medio). Así, las organizaciones deberán, entre otras acciones pero no limitadas a las siguientes: implementar la tecnología necesaria [o cuando menos las políticas] para asegurar que los empleados no puedan descargar aplicaciones de repositorios no autorizados o no oficiales -gestión de aplicaciones móviles (MAM); la tecnología apropiada para crear entornos autenticados y cifrados de confianza, para almacenar, utilizar y compartir los datos empresariales –contenedores; buscar aislar los datos corporativos de los datos personales y de cualquier amenaza que pudiera estar presente en el dispositivo móvil – gestión de contenidos móviles (MCM); realizar análisis de reputación de aplicaciones para evaluar y responder a las vulnerabilidades y amenazas de aplicaciones móviles que pudieran poner en peligro los datos de negocios; incluso aplicar políticas de seguridad de aplicaciones móviles basadas en la identidad autenticada del usuario

Tampoco olvidemos los temas referidos a seguridad de la información -¿cumplimiento tal vez?- sobre el paradigma de computación en nube que tratamos antes, como agente disruptivo, paradigma que resumimos en la siguiente figura:

gráficos 01

Fuente: Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. ” Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Este paradigma es también una consideración de riesgo porque ¿cuáles son los objetivos de negocio que la organización espera alcanzar?, ¿cómo encajan estos objetivos dentro de la estrategia global de la organización?, dentro del marco de la seguridad de la información por supuesto. Así, la figura siguiente presenta algunos de los riesgos identificados para la adopción del modelo de computación en nube, y también presenta algunos marcos de trabajo y normas que, correctamente aplicados, nos ayudan a gestionar estos riesgos:

Fuente:          Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. " Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Fuente:          Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. ” Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Muchas organizaciones se esfuerzan por implementar el software, hardware, y servicios que les permitan identificar y reducir los riesgos. Pero pocos involucran a su gente – las mismas personas que crean y utilizar la información que está siendo protegida e incluso la excluyen por desconfianza[3]. Bueno, sabiendo que el nuevo modelo de seguridad tiene cinco dimensiones, a saber:

  1. Enfocar la seguridad de la información en los activos críticos, nucleares –un enfoque basado en riesgos (lo que puede ser difícil para muchas organizaciones) para establecer el “mejor esfuerzo” podría ser más racional.
  2. Proteger los activos clave con varias capas de sistemas de defensa. Asumir que la empresa ya está comprometida (ya sea por los delincuentes cibernéticos, los competidores, o el gobierno – ¿para los paranoicos?), y desarrollar una estrategia en torno a esa suposición. Comprender que hay muchas fuentes de compromiso, no sólo el centro de datos, computadora personal o dispositivo móvil.
  3. Involucrar a las personas que utilizan la información para proteger los activos [de información] con los que trabajan –especialmente el personal ejecutivo y personal operativo que hemos identificado como claves. “Hazlo o no. No intentes”, ¿recuerdan?
  4. Formar equipo con socios comerciales para impulsar su (y sus) sistemas inmunológicos. Porque todo no se puede proteger de la misma manera. Así, habrá que desarrollar una declaración de aplicabilidad –sí, ayuda el 6W-2H, especialmente en este moderno ecosistema digital. De seguro recuerdan estas palabras: “El miedo es el camino hacia el lado oscuro. El miedo lleva a la ira. La ira lleva al odio. El odio lleva al sufrimiento”[4].
  5. Hacer de la seguridad un problema del negocio – no sólo un problema de TI, porque las posibles alternativas de solución no son siempre tecnológicas. Es hora de pensar en un modelo de seguridad holístico, donde se utilizan múltiples tecnologías y técnicas de gestión, con una amplia aceptación de las medidas estratégicas y tácticas a implementar y rendición de cuentas del valor obtenido de esta implementación –entra el gobierno corporativo de TI (COBIT), en capas y adaptado al riesgo [identificado, evaluado (evaluar los datos y sistemas; identificar los riesgos para dichos sistemas; evaluar los riesgos[5] para la probabilidad, gravedad e impacto (las variables no solo han cambiado, sino que se han multiplicado[6]); y la identificación de los controles[7], salvaguardias y medidas correctivas), y gestionado (el residual por supuesto, luego de haber realizado nuestro trabajo previo de mitigación y/o transferencia) –porque conocemos realmente el riesgo[8]] y el valor que han sido estimados. Sin olvidar, claro, que es igual de importante mantener el ojo en los cambios internos a través de la evaluación continua de la política de riesgos, tolerancia al riesgo, y los indicadores clave de riesgo; pruebas de control y de evaluación de resultados; e informar sobre las actividades de garantía, incluida la auditoría interna, gestión de control y cumplimiento[9]. La gestión del riesgo influye en muchas áreas de la compañía. Su correcta aplicación e involucramiento en la empresa permite que la organización sea más flexible, medible y rentable[10].

Surge entonces la necesidad de integrar [para evitar solapamiento de funciones] gobierno corporativo, gestión de riesgos y cumplimiento corporativo, tres pilares que trabajan en conjunto con el fin de garantizar que la organización cumple sus objetivos –obtiene el valor que sus stakeholders esperan (la idea que compraron y los hizo invertir). Recordemos que gobernar (estructuras, políticas, procesos y controles de la dirección y la gerencia ejecutiva[11]) es asegurar unos objetivos (controlar que se logren), en base a la estrategia empresarial acordada, a partir de la administración de unos recursos determinados y manteniendo el riesgo a niveles aceptables[12].

La figura siguiente muestra una base de esta integración –compleja evidentemente[13]. Por supuesto que existen diversas opciones comerciales pero su elección depende de nuestro correcto –y previo- entendimiento de los objetivos del negocio[14]. Para una adecuada implementación es necesario que existan definidas las metas estratégicas, los planes tácticos para alcanzar estas metas, y las actividades operativas necesarias y apropiadas para la realización de dichos planes.

Fuente:          http://www.slideshare.net/jack_caceres/curso-control-de-acceso-y-seguridad-05-gestin-de-riesgos-2

Fuente:          http://www.slideshare.net/jack_caceres/curso-control-de-acceso-y-seguridad-05-gestin-de-riesgos-2

El cumplimiento puede ser complicado (¿no es el actual ambiente de negocios cada vez más complejo y regulado?[15]), así como buscar reducir las pérdidas y mejorar la toma de decisiones[16], considerando los riesgos planteados en la figura anterior, además de la ciberdelincuencia, las redes sociales, las tecnologías emergentes, los partner o socios de negocio, estrategias más agresivas por parte de los competidores, necesidad de innovación permanente, necesidad de formación continuada y de valor, o disponer de asesoramiento externo experto en múltiples ámbitos, debido al entorno cambiante, mayor gradiente de obsolescencia en los modelos de negocio, entre otros factores a considerar. ISACA nos señala que la seguridad de la información es un componente central en el modelo GRC[17]. La siguiente figura muestra los factores que han propiciado la aparición de la GRC:

Motivos-GRC

La OCEG nos proporciona en la siguiente figura una vista de componentes del Modelo de Capacidad de GRC que esta promulga.

gráficos04

Cada Elemento que se muestra incluye un análisis de los controles y acciones de gestión y aborda consideraciones del diseño y la implementación. Los Elementos definen los aspectos centrales de las capacidades efectivas y pueden servir como un punto de arranque para la evaluación del estado actual del enfoque de una organización. Los Elementos pueden ser aplicados en todos los niveles de la organización para direccionar objetivos empresariales, capacidades departamentales o acciones o controles en áreas críticas. ¿Le son interesantes los elementos considerados? Yo creo que sí.

[1]       Fuente: http://resources.idgenterprise.com/original/AST-0165708_Level3QuickPulse.pdf; disponible en julio/2016

[2]       Fuente: http://searchdatacenter.techtarget.com/es/cronica/Cinco-formas-de-impulsar-la-seguridad-de-aplicaciones-moviles?utm_medium=EM&asrc=EM_EDA_60596204&utm_campaign=20160711_Cinco%20formas%20para%20impulsar%20la%20seguridad%20de%20las%20apps%20m%C3%B3viles_&utm_source=EDA; disponible en julio/2016

[3]       Fuente: http://core0.staticworld.net/assets/media-resource/17273/infoworld-new-security.pdf; disponible en julio/2016

[4]       Fuente: http://www.govinfosecurity.com/blogs/7-star-wars-day-cybersecurity-lessons-p-2121?rf=2016-05-05-eg&mkt_tok=eyJpIjoiTkdVME9HWTJaRFZpTW1ZeiIsInQiOiI2NUNwMGZqQnhuaUpzaU1udTNPT0xiU2NcL1ZMSk5MSEJrTlZQUklBYlBGZFduUmZwSHgydW9RZ1RIYjV4ZVZNcFJQRHlIRlBqb1d6UG1WN1VCK052YVZsbkZZUVdnQVlVbmNGYnJleEc2WkU9In0%3D; disponible en julio/2016

[5]       Fuente: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf; disponible en julio/2016

[6]       Fuente: http://www.pwc.es/es/soluciones/auditoria/grc-suite.html; disponible en julio/2016

[7]       Fuente: http://www.sans.edu/research/security-laboratory/article/security-controls; disponible en julio/2016

[8]       Fuente: http://www.cio.com/article/3065048/security/how-to-perform-a-risk-assessment.html?token=%23tk.CIONLE_nlt_cio_security_2016-05-06&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Security%202016-05-06&utm_term=cio_security#tk.CIO_nlt_cio_security_2016-05-06; disponible en julio/2016

[9]       Fuente: http://www.oceg.org/resources/building-blocks-grc/; disponible en julio/2016

[10]     Fuente: http://www.deloitte.com.mx/agrc/grc.htm; disponible en julio/2016

[11]     Fuente; http://www2.deloitte.com/content/dam/Deloitte/mx/Documents/risk/mx(es-mx)ServiciosGRC.pdf; disponible en julio/2016

[12]     Fuente: http://www.aspectosprofesionales.info/2014/08/la-responsabilidad-penal-corporativa-el.html; disponible en julio/2016

[13]     Fuente: http://searchdatacenter.techtarget.com/es/definicion/Software-de-GRC-gobernanza-gestion-de-riesgos-y-cumplimiento; disponible en julio/2016

[14]     Fuente: http://searchdatacenter.techtarget.com/es/cronica/La-seleccion-de-herramientas-de-GRC-comienza-entendiendo-los-objetivos-de-negocio; disponible en julio/2016

[15]     Fuente: http://www.epicor.com/lac/solutions/enterprise-risk-management.aspx; disponible en julio/2016

[16]     Fuente: https://www-01.ibm.com/software/es/analytics/rte/an/risk-compliance/; disponible en julio/2016

[17]     Fuente: http://www.isaca.org/chapters7/Monterrey/Events/Documents/20101206%20Uniendo%20al%20Gobierno%20(GRC).pdf; disponible en julio/2016

Algo sobre ciberseguridad

Cierto, la ciberseguridad nos preocupa[1] y por ello debemos ocuparnos en entender nuestros propios ambientes de operación y por controlar las puertas y ventanas abiertas en el plano digital de nuestro ecosistema, identificar los riesgos y determinar el verdadero impacto que un incidente podría tener para nuestro negocio.

¿Sería bueno esforzarnos en realizar un FODA de nuestra seguridad de la información? No sólo situacional sino, además, estratégico. ¿Mantenemos actualizados nuestros activos de información? ¿Qué dejamos de proteger y por qué? ¿Qué nos falta por hacer o mejorar? ¿Qué recursos y capacidades están involucrados, han sido desplegados y han sido comprometidos en los servicios que entregamos[2]? ¿Existen limitaciones o restricciones, cuáles y por cuánto tiempo lo serán? ¿Hemos implementado algún tipo de ‘ciber’ defensa como los antiguos honey pot ¿los recuerdan?, con la finalidad de conocer el comportamiento de algún atacante dentro de nuestra plataforma tecnológica así como las técnicas que podría utilizar? ¿Es mejor invertir en herramientas de seguridad, o en la construcción de sistemas –no sólo de información- con un menor número de vulnerabilidades? ¿Cuáles herramientas, cuáles sistemas? ¿Empezamos?, ¿con qué empezamos? ¿Hemos desarrollado algún cronograma para realizar las evaluaciones? ¿Qué hay de las acciones de monitoreo y control? ¿Cuáles son los sistemas críticos para la operación de la empresa, de su día a día? ¿Qué servicios de TI que ya gestionamos o estamos todavía diseñando son los primeros que debemos considerar en nuestra evaluación de su seguridad de la información? ¿Cuáles serán los criterios de aseguramiento de calidad y de control de calidad que estableceremos para esa evaluación? ¿Consideramos la mejora continua en todos los casos? ¿Cómo han sido personalizados y configurados estos servicios cuya información debe permanecer segura? ¿Estamos gestionando los cambios a los servicios que podrían afectar la seguridad del ecosistema actual? ¿Estamos gestionando las configuraciones de los servicios en cuanto a la seguridad de la información? Humm.

No nos es extraño que cuanta mayor y mejor tecnología exista, más elaborados son los ataques y en mayor cantidad, y que no precisamente son realizados por gurús. Además, cada vez es más complicado y toma tiempo identificar el punto de entrada y el número de registros o dispositivos que se han visto comprometidos. Seguramente ya pasamos por el mantra de: conocer dónde se encuentran los datos, sobre todo los identificados, catalogados y tratados como sensibles –sin olvidar cómo, dónde y con qué se procesan o transmiten (no olvidemos a dónde y de qué manera); monitorizar el ciclo de vida de los datos; otorgar permisos según la política consabida de necesidad de conocer, gestionando identidades y autorizaciones según corresponda –recordemos el concepto IAM[3]; protegernos del malware; utilizar apropiadamente (adoptar y adaptar) el concepto BYOD; utilizando las capacidades integradas de los dispositivos móviles; aislando y ocultando dispositivos terminales según sea necesario o prudente; educación, interminable, constante, continua, actualizada, personalizada, activa y de calidad, entre otros atributos; concientizar; comunicar; entender para prevenir, descuidos y comportamientos de los usuarios con relación a la seguridad de la información.

Entonces, entendiendo nuestra organización, qué se debe proteger, y los riesgos que enfrenta, debemos enfocar lo mejor posible nuestros esfuerzos en cuanto a gestionar el riesgo a fin de motivar la adopción de una postura acorde con el grado de exposición y lo crítico de una situación porque sabemos que existen muchas variables a considerar de forma responsable, entre otras, las operativas, humanas, funcionales y tecnológicas. No olvidemos que los riesgos permanecen en cambio constante, más con el grado actual de globalización el cual incrementa el entorno de las amenazas modernas alterando –por decirlo gentilmente, y si está vigente, cualquier plan de respuesta a incidentes.

Es decir, debe existir una estrategia de seguridad exhaustiva con objetivos de seguridad y medidas alineadas con las estrategias empresariales y metas, donde la seguridad sea una prioridad en la mente de todos y sujeta a una evaluación y reevaluación continua, con alternativas de análisis de datos de calidad que ayuden a proteger información confidencial –para que funcionen realmente opciones como DLP y SIEM, y que podamos determinar cuáles posturas de seguridad que se han adoptado han sido las más efectivas.

[1]      Fuente: http://docs.media.bitpipe.com/io_13x/io_131511/item_1334211/HB_Consejos%20de%20ciberseguridad%20para%20las%20empresas%20de%20hoy_final.pdf; disponible en julio/2016

[2]      Fuente: http://learn.alienvault.com/5-security-controls-or-an-effective-soc/home; disponible en julio/2016

[3]      Fuente: http://www.itnews.com/article/3088084/security/gartner-s-top-10-security-predictions.html?token=%23tk.ITN_nlt_ITnews_Daily_2016-06-24&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=ITnews%20Daily%202016-06-24&utm_term=ITnews_Daily; disponible en julio/2016