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.

Doxware, una variante del ransomware o del extortionware

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet de las cosas -IoT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Más sobre el marco de la computación en nube -cloudcomputing -Parte 1

Sabemos que cuando las organizaciones se ven impulsadas a invertir se preguntan primero ¿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?

Lo anterior funciona bien para tecnología convencional [claro, si queremos mantener la estadística de que días después de que algo entra en funcionamiento, ya está desactualizado, aparecen nuevas soluciones, nuevos parches, nuevas actualizaciones y así, como gerentes de TI, sólo nos mantenemos persiguiendo la curva de valor todo el tiempo –no muy buen porvenir ¿verdad?] pero, en cuanto a la nube, ¿sabemos si nuestra estrategia de negocio está lista para la nube?[1] –claro, y todas las demás preguntas.

¿Nos hemos preguntado si estamos pensando en la nube para ahorrar o para crecer, por un aspecto táctico o por una solución expresa y personalizada, está la infraestructura “completamente” o “en gran medida” optimizada para la estrategia de [nuestro] negocio? ¿Hemos definido los criterios para evaluar lo anterior? ¿No? bueno, deberíamos. Tengamos presente también que cuando existe una relación con uno o más proveedores externos, la transición a la nube [o de la nube] suele complicarse.

Sería bueno encontrar maneras en que las tecnologías de nube se ajusten a las necesidades y capacidades únicas de su organización [sincerando -alineando- la infraestructura de TI con los requerimientos del negocio y asegurando que la estrategia en nube evoluciona en consonancia]. Así, conviene adoptar la tecnología en nube con la misma seriedad que se aplica a los mecanismos de despliegue de TI más tradicionales. Atención, la madurez en la nube no significa abandonar las nubes privadas, sino el uso de la herramienta adecuada para la tarea y, en última instancia, el alineamiento de la estrategia en infraestructura y la gobernanza.

No olvidemos a los “nativos digitales” y su continua ansia por la nueva y menor tecnología que puedan comprar -¿alguien ha explotado todo lo que esta nueva tecnología puede hacer? ¿Recuerdan cuando La gente estaba acostumbrada a tener una mejor tecnología en el trabajo de la que tenía en casa [y estaban menos propensos a cuestionar el hecho]? Claro, BYOD –flexibilidad, agilidad, adaptabilidad, rendimiento, escalabilidad, rapidez[2], libertad… fomentando una cultura que hace uso seguro de la tecnología digital[3] [pero asegúrese de que la seguridad, la privacidad y el cumplimiento legal se abordan desde el principio –no olvide desarrollar las estructuras de gobierno exigidas por la nube, y adaptar o remodelar los procesos de gobierno para implicar más a los líderes]. La leyenda urbana dice que para ampliar el uso de la nube con responsabilidad y cosechar sus beneficios, las empresas deben ser capaces de utilizar la nube de forma segura.

Preparémonos para invertir más tiempo y esfuerzo en evaluar un número creciente de proveedores de nube (IaaS, PaaS, SaaS, XaaS para el caso) y soluciones puntuales –ojo con las soluciones “llave en mano” ya sean propietarias (Amazon y Microsoft entre otras) o de código abierto[4] (OpenStack). El entorno se complica cuando se involucra a otros grupos de interés internos como responsables de la conformidad (la aceptación de la implantación y la migración podría ser complicada por lo que debemos asegurar el cumplimiento legal y normativo), y líderes de negocio –seguramente habrán dudas en cuanto a la seguridad de la información. En última instancia, todos debemos prepararnos para la transición. Acuerde los detalles con sus proveedores actuales –no se olvide de exigir garantías, y aproveche toda su experiencia –hasta puede obtener orientación estratégica, busquemos socios que estén preparados para mantener una relación de colaboración y aprendizaje constantes (sería ideal compartir ideas sobre mejoras en la tecnología y la plataforma –y hasta tener la posibilidad de influir de forma innovadora en la del proveedor).

Apuesto que creían que olvido al integrador. No es así. Debemos elegir un integrador, alguien que se haga cargo de la integración de los servicio de nube, ya sea un empleado o un consultor técnico de confianza[5]. Debemos asegurar que se orqueste adecuadamente nuestra red de [los mejores] proveedores –¿o considera sabio poner todos los huevos en la misma canasta?, sin olvidar el intercambio de datos y las diferencias entre los procesos de los distintos centros de datos. Como somos entendidos en la materia nos habremos dado cuenta que para garantizar el éxito de la adopción de la nube debemos establecer un plan de ruta para esta integración‑migración y que debemos gestionar este plan [apropiadamente] como un proyecto.

Además, en la vida diaria cosas malas suceden, y nos ocurrirán cuando y donde más nos afecte -¿recuerdan a Murphy? Las necesidades del negocio cambian y más vendedores aparecen (con ofertas más atractivas) o los actuales vendedores salen del mercado (local, lo que nos deja sin soporte apropiado, o simplemente quiebran y quedamos desamparados), a veces las relaciones de nube no duran (porque no obtuvimos del proveedor los servicios –funcionalidad y soporte- como nos ofreció, porque ¿la nube no estuvo a la altura de nuestras necesidades? –y no obtuvimos las ganancias financieras esperadas[6] [en parte quizá porque en primer lugar no estuvimos “preparados” para la nube], porque hubo pérdida de datos –improbable dicen algunos pero sin embargo posible, porque el proveedor está atrasado tecnológicamente, porque se impactó negativamente en alguno de los factores CID de la seguridad de la información, porque ocurrieron apagones de la nube y permanecen en la oscuridad la gravedad y el estado exacto de los trabajos de restauración[7] -y este oscurantismo medioeval no nos gusta, entre otros aspectos a considerar).

En fin, a veces tenemos que hacer un cambio, y a veces hay eventos fuera de nuestro control que lo hacen por nosotros; así, no podemos o logramos permanecer en un servicio que es “el más adecuado”. Bien pensado, tampoco queremos vernos “atados” a un proveedor. Cuando eso sucede, tener un plan [¿sería mejor considerar una estrategia de salida?] puede significar la diferencia entre un ligero contratiempo del cual la organización puede recuperarse rápidamente, o enfrentar caos, tiempo de inactividad y una interrupción importante para el negocio.

En otras palabras, la estrategia de salida de nube [“migración en reversa” o “uncloud”[8] o “de-cloud” si nos ponemos al día con la terminología –ajá, ¿cuántos hemos reconocido estos términos?] es la elaboración de un plan de acción para asegurar que cualesquiera sean los servicios de nube que apoyan las actividades actuales del negocio, estos [servicios de nube] se pueden reemplazar [se puede realizar la transición] sin una interrupción grave[9]. El objetivo es realizar la transición en el plazo más breve posible[10] así que, entre otras cosas, no olvidemos considerar herramientas, personal calificado, niveles de servicio acordados con terceros [¿nuestros clientes?], otras responsabilidades adquiridas, mapeo de dependencias, mapeo de aplicaciones con la plataforma tecnológica, las propias aplicaciones, pruebas.

Así, tengamos presente qué servicios en nube reemplazamos e igualmente importante, con qué servicios en nube los reemplazamos –las alternativas tecnológicas pueden ser hasta iguales, pero centrémonos en lo que el negocio requiere (seguramente hemos realizado o deberemos realizar un BIA para un BCP[11] por ejemplo); así también es importante el cómo estamos utilizando los [actuales] servicios en nube (costos, rendimiento, jugadores clave, características del servicio, tratamiento de datos, niveles de servicio, soporte, aspectos legales y de cumplimiento, gobierno, no olvidemos las necesidades de privacidad y trazabilidad[12], entre otros aspectos a considerar –¿ya mencioné los factores CID de la seguridad de la información?).

Un análisis de impacto en el negocio (BIA) es un proceso sistemático mediante el cual una organización reúne y analiza información sobre sus funciones esenciales [y sus prioridades] y procesos (aplicaciones, datos, redes, sistemas de información, instalaciones, etc.). Esta información se utiliza para determinar cómo se vería afectada la organización (impacto potencial y costos en casos de desastre/acontecimiento/suceso) si estas funciones y procesos fueron interrumpidos por un desastre[13]/acontecimiento/suceso. En otras palabras, es fundamental analizar cuál es la tolerancia de su negocio a la no disponibilidad de sus funciones críticas[14]. ITIL®[15] nos dice que el BIA define los requisitos de recuperación de los servicios de TI. Estos requisitos incluyen tiempos de recuperación objetivos, puntos de recuperación objetivos y los objetivos mínimos de nivel de servicio para cada servicio de TI.

En la actualidad garantizar la operación no es una opción. Los clientes, proveedores y accionistas esperan respuesta sin importar lo que suceda en el exterior [sin importar las circunstancias que se presenten en el ecosistema donde se desarrolla la organización, sea ésta del tamaño que sea, pública, privada o entidad gubernamental]. La continuidad del negocio (BC) describe los procesos y procedimientos que una organización pone en marcha para garantizar que las funciones esenciales puedan continuar durante y después de un desastre/acontecimiento/suceso –esto no sólo involucra a TI y su Plan de recuperación ante desastres o DRP (¿alguno lo tiene? Como procedimiento documentado[16] quiero decir). La Planificación de la Continuidad del Negocio (BCP) trata de evitar la interrupción de los servicios de misión crítica (seguramente más de una vez caeremos) y restablecer el pleno funcionamiento de la forma más rápida y fácil que sea posible[17] (lo importante es levantarnos, cada vez). Usualmente los procesos críticos de negocio mantienen una íntima interdependencia con la tecnología; así, no consideremos que esto es un gasto sino más bien una inversión.

No esperamos –o deseamos- que nuestra relación con el o los proveedores de nube se vea interrumpida o falle. Pero prestemos atención al refrán: “cuando el río suena es porque piedras trae”. Otro refrán dice más o menos así: “esperamos lo mejor preparándonos para lo peor” –o que Dios nos coja confesados.

[1]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-cloud-maturity-curve-The-fundamental-five.pdf, mayo/2015

[2]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/02/CIOs-Cloud-Bound.pdf, febrero/2015

[3]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-Cloud-Maturity-Curve.pdf, mayo/2015

[4]      Fuente: http://www.channelbiz.es/2014/09/25/openstack-un-repaso-esta-alternativa-cloud-en-codigo-abierto/, setiembre/2014

[5]      Término acuñado, a mi mejor entender, por Garcerán Rojas de PQC.es

[6]      Fuente: http://searchcloudprovider.techtarget.com/tip/How-to-uncloud-Best-practices-for-exiting-the-public-cloud, noviembre/2015

[7]      Fuente: http://cioperu.pe/articulo/17264/como-utilizar-openstack/, noviembre/2014

[8]      Fuente: http://searchcloudprovider.techtarget.com/definition/uncloud-de-cloud, setiembre/2015

[9]      Fuente: http://searchcloudsecurity.techtarget.com/tip/Create-a-cloud-exit-strategy-to-prepare-for-the-unknown?utm_medium=EM&asrc=EM_NLN_49188871&utm_campaign=20151028_Dridex%20banking%20Trojan,%20botnets%20wreaking%20havoc%20again%20despite%20DOJ%20takedown_oeckerson&utm_source=NLN&track=NL-1820&ad=903816&src=903816, octubre/2015

[10]    Fuente: http://blogs.gartner.com/kyle-hilgendorf/2013/09/18/cloud-exit-strategies-you-do-need-them/, setiembre/2013

[11]    Fuente: http://searchdisasterrecovery.techtarget.com/essentialguide/Essential-guide-to-business-continuity-and-disaster-recovery-plans, 2015

[12]    Fuente: http://www.bbb.org/blog/2013/08/6-steps-for-de-clouding-yourself/, agosto/2013

[13]    Fuente: http://searchsecurity.techtarget.com/feature/Conducting-an-effective-business-impact-analysis, febrero/2003

[14]    Fuente: http://searchdatacenter.techtarget.com/es/opinion/BCP-y-DRP-El-arte-de-levantar-un-negocio-caido, noviembre/2013

[15]    Fuente: http://wiki.servicenow.com/index.php?title=File:ITIL_2011_Spanish_%28Latin_American%29_Glossary_v1.0.pdf#gsc.tab=0, junio/2012

[16]    Fuente: http://iso9001calidad.com/procedimientos-documentados-exigidos-por-la-norma-151.html, 2013

[17]    Fuente: http://searchdatacenter.techtarget.com/es/definicion/Continuidad-de-negocios-BC, setiembre/2013