16 habilidades de seguridad crítica que necesitamos

16 habilidades de seguridad crítica que necesitamos

Pongámonos en situación

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

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

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

 

 

Entendamos primero el concepto de habilidad

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Preguntémonos, por ejemplo:

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

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

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

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

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

Conclusiones

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

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

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

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

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

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

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

Fuerzas impulsoras – Fuerzas de resistencia [restricción]

Pongámonos en situación

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

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

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

¿Buscamos que el negocio gane o que nosotros ganemos?

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

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

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

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

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

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

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

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

Podríamos empezar por preguntarnos:

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

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

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

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

A tener en cuenta

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

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

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

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

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

Segundo, evaluamos el esfuerzo

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

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

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

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

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

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

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

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

Formulemos nuestras estrategias de acción

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

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

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

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

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

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

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

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

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

Algunas tácticas

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

Probablemente necesitemos cambiar la cultura organizacional.

Conclusiones

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

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

Pongamos nuestra inteligencia emocional a trabajar.

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

Espacio para ¿mejorar? -para la mejora continua

A estas alturas de nuestro deambular entre los peligros de la inseguridad, ya debemos estar convencidos que siempre hay espacio para mejorar. Bueno, una palabra elegante para establecer que no nos quedamos estáticos; y en seguridad, no podemos darnos ese lujo.

Mejorar implica primero conocer. Según la RAE[1], conocer significa “averiguar por el ejercicio de las facultades intelectuales la naturaleza, cualidades y relaciones de las cosas”; “entender, advertir, saber, echar de ver a alguien o algo”; “percibir el objeto como distinto de todo lo que no es él”.

6W-2H ¿solamente?

Significa tener información y conocimiento, saber, entender, comprender, dominar lo que hacemos. Y para esto podemos ayudarnos con la aplicación de nuestra vieja conocida, la técnica 6W-2H[2] [3] [4]:

6w-2h

Luego podemos buscar dónde se encuentra la oportunidad para mejorar, y también podemos apoyarnos para esto en la técnica 6W-2H. Según la RAE, buscar significa “hacer lo necesario para conseguir algo”; “hacer algo para hallar a alguien o algo”. Significa hacer o decir algo para provocar una reacción; intentar localizar, conseguir, o encontrar. Bueno, una palabra sencilla para establecer que debemos ser proactivos. Según la RAE, proactivo significa “que toma activamente el control y decide qué hacer en cada momento, anticipándose a los acontecimientos”. Esto es, asumir la responsabilidad de hacer que las cosas sucedan –y no esperar a que algo suceda, es asumir el pleno control de una conducta activa, lo que implica tomar la iniciativa en el desarrollo de acciones creativas y audaces para generar mejoras, haciendo prevalecer la libertad de elección sobre las circunstancias del contexto[5]. Significa tener iniciativa y capacidad para anticiparse a lo que pueda suceder[6]. Desarrollar una conducta proactiva ayuda a afrontar problemas, prever consecuencias y orientarse a la innovación, de manera que cada persona pueda mejorar su competencia personal y profesional[7].

Mejoremos

Sin embargo, buscar oportunidades de mejora es algo que puede ser complicado. Hay muchos factores que contribuyen a esta dificultad y variables que alteran la percepción de las alternativas que podríamos formular o caminos que podríamos tomar, entre otros pero no limitados a: conocimiento y experiencia de quien formula las preguntas (análisis y evaluación de situación); el contexto en que ocurre la oportunidad de mejora (diagnóstico); los recursos y capacidades con las que contamos –o podríamos contar; la utilidad; la garantía; la productividad esperada; el rendimiento esperado en cumplimiento de la demanda comprometida; las ganancias esperadas; las metas estratégicas a lograr; la disponibilidad de métricas apropiadas y mediciones realizadas; el haber definido con anticipación y propiedad los factores críticos de éxito y sus correspondientes indicadores clave de rendimiento.

Así, encontramos en la literatura actual innovaciones interesantes a esta técnica:

  • With [what], con qué recursos se cuenta (materiales y dinero), se realiza[8].
  • Wins, beneficios a alcanzar, beneficios alcanzados[9], tangibles e intangibles.
  • Which are the objectives?, con el plan de acción propuesto ¿estamos asegurando el logro de los objetivos?[10]

Podemos buscar mejorar, con respecto a servicios y seguridad de la información, entre otros aspectos pero no limitados a el conocimiento, la capacitación, la confianza en los servicios provistos, el manejo y utilización de herramientas, el cumplimiento de políticas, el despliegue de herramientas avanzadas, la respuesta a incidentes, el planeamiento, los diseños, la gestión de configuraciones, la gestión de cambios, pases a producción, la operación, el monitoreo y control, la respuesta coordinada ante amenazas[11], y muchos otros.

En general, lo que buscamos es encontrar la causa raíz de aquello que nos está afectando o aquello que buscamos mejorar –y ¿por qué no?, ¿servirá también para evaluar riesgos, y gestionarlos?, ¿para establecer y afinar nuestros procesos?, ¿para diseñar e implementar nuestros servicios de TI, y gestionar estos servicios?, ¿para establecer los controles de seguridad informática que debemos implementar, y gestionar la seguridad de la información?

Claro que sí. Cualquier esfuerzo resulta ligero con el hábito –Tito Livio.

[1]      Fuente: http://www.rae.es/; disponible en junio de 2016

[2]      Fuente: https://enterprisezine.jp/iti/detail/812; disponible en junio de 2016

[3]      Fuente: http://president.jp/articles/-/3448; disponible en junio de 2016

[4]      Fuente: http://www.progressalean.com/5w2h-tecnica-de-analisis-de-problemas/; disponible en junio de 2016

[5]      Fuente: https://es.wikipedia.org/wiki/Proactividad; disponible en junio de 2016

[6]      Fuente: http://www.wikilengua.org/index.php/proactivo; disponible en junio de 2016

[7]      Fuente: http://www.csintranet.org/competenciaslaborales/index.php?option=com_content&view=article&id=164:proactividad&catid=55:competencias; disponible en junio de 2016

[8]      Fuente: https://empreendendoaprendendo.wordpress.com/tag/6w2h/; disponible en junio de 2016

[9]      Fuente: http://es.slideshare.net/VeraLessa1/ferramenta-6w2h; disponible en junio de 2016

[10]    Fuente: http://www.javeriana.edu.co/personales/hbermude/contrapartida/Contrapartida347.docx; disponible en junio de 2016

[11]    Fuente: http://docs.media.bitpipe.com/io_10x/io_102267/item_465972/Room-for-Improvement-Building-confidence-in-data-security.pdf; disponible en junio de 2016

Algo adicional sobre seguridad

Hablamos hace poco de Shadow IT. De hecho, esto no es nuevo.

¿Recuerdan cómo utilizábamos los diskettes? Para respaldo de datos por supuesto (¡!). Y luego evolucionamos en ese sentido (sí, claro) con el CD, DVD, correo electrónico en sus varios tipos, USB en sus varias formas, SD en sus varios tamaños y capacidades, y ahora tenemos una nueva forma, la nube (incluso gratis o casi gratis -¿alguien se ha preguntado quién financia todos esos servicios ‘gratuitos’ en nube? ¿Algún gobierno hipocondríaco o controlista?).

De hecho, incluso el empleo de smartphones –que también es un factor de seguridad a considerar (¿recuerdan cuando los celulares se utilizaban sólo para nuestras comunicaciones telefónicas?), apoya al hecho de que los CIO buscan resultados[1] (donde la seguridad es considerada más bien una traba), y una manera es proporcionar una cierta ‘autonomía’ con la movilidad (o la infinita ubicuidad) de las personas. ¿Habrá alguna relación entre la rotación de personal y el stress de los empleados por esta ubicuidad? ¿Les interesa esta tesis para doctorado?

Total, esto sí nos ayuda para realizar el trabajo diario –y debido a esto no nos preocupamos por la seguridad de los datos que salen de la empresa o de la publicidad (en forma de adware[2] -o tal vez, spyware) que ingresa a la empresa. Tanto dependemos de estas ayudas que eliminarlas podría impactar negativamente nuestra operativa [funcionalidad] diaria[3]. Dolor de cabeza para TI –y la organización.

Si la seguridad atenta contra una funcionalidad crítica del negocio, o bloqueamos algún acceso a algún funcionario de alto nivel, el despido está garantizado[4], tanto como que hayamos ignorado un evento crítico de seguridad, hayamos utilizado datos reales en ambientes de prueba, o hayamos utilizado la clave del administrador en un ambiente inherentemente inseguro y no controlado.

Doy por descontado que el negocio sabe, entiende y está comprometida con la seguridad, y que no considera a la seguridad como problema sólo de TI –bueno, espero no estar equivocado. De hecho, si nuestras aplicaciones (legacy como cliente/servidor o nuevas app o SaaS) dejan puertas abiertas a los hackers[5], y eso que las ‘controlamos’ de la mejor manera posible, ¿qué podemos decir de las aplicaciones  en la nube?

Además, ¿quién [nos] controla? Estamos guardando datos privados podemos esbozar como defensa, si en caso. ¿Privados para quién? O que están seguros. ¿Seguros cómo? La seguridad proporciona protección para todo tipo de información, en cualquiera de sus formas, de manera que se mantienen su confidencialidad, integridad y disponibilidad. La privacidad asegura que la información personal (y a veces también la información confidencial corporativa) se recoge, procesa (usa), protege y destruye legal y justamente[6].

Bueno, si esta es una amenaza, ¿cómo la tratamos? En general, ¿cómo tratamos las amenazas? Supongo que las priorizamos sobre la base de criterios que el negocio considera pertinentes y apropiados. Buscamos claro que las medidas que adoptemos esta vez sí cierren las brechas de seguridad a los wannabe hackers. Sabemos que no es cuestión de si experimentaremos una intrusión, sino de cuándo esta se dará[7]. Parece paranoico el comentario anterior pero, preguntémonos si estamos realizando lo necesario y con los recursos y capacidades necesarios para reducir esta posibilidad –y sobre todo su impacto.

Sabemos que debemos proteger los sistemas de información desde su concepción, proteger en general los activos de información (que han sido identificados, catalogados y son tratados en concordancia ¿verdad?); detectar las brechas lo mejor posible (aunque algunas brechas pueden tomar más tiempo y esfuerzo que otras) mediante el monitoreo continuo de los incidentes que impactan nuestra seguridad; responder en concordancia al impacto ocasionado por una brecha y con la prioridad exigida por la misma, poniendo en acción los planes de respuesta (actuación) correspondientes –que ya hemos probado y afinado (por supuesto esto es evidente que realizamos de forma periódica); recuperar los servicios y dar cumplimiento a los parámetros de seguridad establecidos, aunque estemos luchando con una brecha, es una situación mandatoria –por lo que se pondrá en práctica un nivel de resiliencia importante seguramente ya analizado con anticipación y contemplado por la organización en sus planes de continuidad del negocio.

De ITIL® tomamos prestados los conceptos de recursos: gente (número de empleados); información (propia de la empresa); aplicaciones en uso (desarrolladas localmente o por terceros); infraestructura (edificaciones, centro de datos y sus áreas de soporte); capital financiero. Y de capacidades: gestión; organización establecida; procesos (implementados, con sus procedimientos documentados); base de conocimiento; gente (su experiencia, habilidades, relaciones).

Como medidas de calidad, mejora continua y gestión de proyectos, ¿medimos el impacto de las amenazas? Me refiero a correctamente [inteligentemente], poniendo en la balanza todos los factores (fear factor) relacionados que impactarían negativamente y directamente nuestro ecosistema para clasificarlos [y tratarlos] apropiadamente[8]. Primero, ¿ya retiramos todo aquello que no necesitamos –verdad? ¿Hemos desplegado alguna iniciativa [mejor práctica] para la gestión de configuraciones y gestión de cambios?, con el fin de mantener la consistencia de las configuraciones (relaciones entre los componentes tecnológicos que permiten al negocio prestar los servicios contratados) y la personalización de la tecnología. ¿Medimos de forma coherente e inteligente el éxito de las medidas desplegadas [algo de gobernabilidad no estaría demás]? ¿Tenemos establecida de forma férrea una línea base correcta, coherente, completa, difundida, aceptada, y confiable? ¿En base a qué evidencia tomamos qué acciones? Entonces, ¿enfocamos nuestro esfuerzo de forma apropiada (en lo que vale la pena –sabemos qué ¿verdad?[9]), empleamos las métricas apropiadas, medimos en los lugares apropiados, en los momentos apropiados, de la forma apropiada y con las herramientas apropiadas? ¿Conocemos (ojo con la palabra) qué riesgos tomar en cuenta? Cierto, a mano cae bien la técnica 6W-2H. Las empresas más seguras monitorean de manera agresiva y extensiva (dentro de un ecosistema bien definido) anomalías específicas (por ejemplo, creando una matriz de comparación de todas las fuentes de registro que se tienen y de lo que estas alertan, comparando esta matriz con su lista de amenazas, haciendo coincidir las tareas de cada amenaza que puede ser detectada por los registros o configuraciones actuales y luego afinando el registro de eventos para cerrar tantas brechas como sea posible), establecen alertas –y responden a ellas, que es lo más importante.

¿Hemos obtenido de las personas que trabajan con datos sensibles su compromiso para con la seguridad de estos datos? –claro considerando en todos los casos el paradigma del menor privilegio y manteniendo un control de acceso basado en roles. ¿Hemos logrado algún tipo de sinergia con proveedores estratégicos [o socios comerciales] con el fin de impulsar apropiadamente los esfuerzos en seguridad?

¿Actualizamos nuestros planes y medidas de forma periódica? ¿Es la forma de protección que aprendimos o a la que estamos acostumbrados aún útil en la actualidad? Al menos actualicemos y mantengamos vigente nuestro control de acceso basado en roles ¿o ya nos embarcamos en IAM? En todo caso, no olvidemos la máxima en seguridad: el menor privilegio; y de evolucionar más allá de las ACL y adaptarnos a la evolución, sobre todo en los dominios de seguridad que establezcamos en nuestro ecosistema. Recordemos que cada dominio de seguridad debe tener su propio espacio de nombres, control de acceso, permisos, privilegios, roles, etc., y estos deben trabajar sólo en ese espacio de nombres[10]. Cada objeto y aplicación debe tener un propietario (o grupo de propietarios) que controla su uso y es responsable de su existencia. Conviene entonces trabajar con una matriz RACI, concepto prestado del PMBOK.

Debemos continuar la batalla, no importa dónde esta se dé, y no rendirnos, no importa cuán arduo sea el camino de la seguridad (inconsistencias en la plataforma tecnológica como su no estandarización, distribución imperfecta de las defensa que podamos desplegar, carencia de personal especializado y con experiencia tanto para el despliegue de las medidas de seguridad como para el monitoreo del cumplimiento, pérdida de enfoque en los riesgos reales, carencia de una solución eficaz dirigida a la verdadera raíz del problema, entre otros factores que podrían desalentarnos). No olvidemos la defensa en profundidad y los ataques múltiple vector (MVA) que los hackers pueden utilizar para intentar vulnerar nuestras defensas. La clave es preguntarse con cuánto daño podremos vivir si experimentamos (o sufrimos) una brecha de seguridad, la que permite a un intruso tener acceso total a un área determinada.

Entonces, ¿conocemos [realmente] las amenazas a nuestro ecosistema?[11] ¿Analizamos [realmente, y preferible con apoyo de herramientas de analítica] qué se nos pasó [falsos negativos], la causa raíz[12], o lamentamos lo que perdimos y seguimos midiendo lo bien que configuramos el firewall [cuántos bloqueos realiza]? ¿Seguimos pensando que los respaldos de datos son lo único confiable para garantizar la continuidad de los servicios o asumimos que nuestro ecosistema está comprometido, y desarrollamos una estrategia en torno a esa suposición? Así, tener una visión integral de riesgos es la base de un sólido enfoque a la seguridad[13].

[1]      Fuente: http://www.cio.com/article/3086690/careers-staffing/measure-your-employees-results-not-their-time.html?token=%23tk.CIONLE_nlt_cio_insider_2016-06-22&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Daily%202016-06-22&utm_term=cio_insider#tk.CIO_nlt_cio_insider_2016-06-22; disponible en junio/2016

[2]      Fuente: https://es.wikipedia.org/wiki/Adware; disponible en junio/2016

[3]      Fuente: http://www.csoonline.com/article/3075724/security/shadow-it-101-beyond-convenience-vs-security.html?upd=1465232115087; disponible en junio/2016

[4]      Fuente: http://www.infoworld.com/article/2846758/security/10-it-security-mistakes-that-will-get-you-fired.html#tk.ifw-rs; disponible en junio/2016

[5]      Fuente: http://resources.idgenterprise.com/original/AST-0163312_2574_AppSec_infographic_Rev1_v2.pdf; disponible en junio/2016

[6]      Fuente: http://www.cio.com/article/3075023/privacy/the-difference-between-privacy-and-security.html?token=%23tk.CIONLE_nlt_cio_security_2016-05-30&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Security%202016-05-30&utm_term=cio_security#tk.CIO_nlt_cio_security_2016-05-30; disponible en junio/2016

[7]      Fuente: http://engage.hpe.com/PDFViewer?ID={42266c61-20e2-4d39-a0d0-40291a9336c3}_HPE_Security_Buyers_Guide_Checklist; disponible en junio/2016

[8]      Fuente: http://www.infoworld.com/article/2987108/security/the-no-1-problem-with-computer-security.html; disponible en junio/2016

[9]      Fuente: http://www.cio.com/article/3076171/security/effective-it-security-habits-of-highly-secure-companies.html?token=%23tk.CIONLE_nlt_cio_leader_2016-06-02&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Leader%202016-06-02&utm_term=cio_leader#tk.CIO_nlt_cio_leader_2016-06-02; disponible en junio/2016

[10]    Fuente: http://www.cio.com/article/3076171/security/effective-it-security-habits-of-highly-secure-companies.html?nsdr=true&token=%23tk.CIONLE_nlt_cio_leader_2016-06-02&page=2; disponible en junio/2016

[11]    Fuente: http://www.infoworld.com/article/2989278/security/know-your-threats-before-you-deploy-defenses.html; disponible en junio/2016

[12]    Fuente: http://www.infoworld.com/article/3005594/security/7-keys-to-better-risk-assessment.html; disponible en junio/2016

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

Shadow IT

Shadow IT se refiere al comportamiento de los empleados que deliberadamente evitan las políticas de seguridad y controles con el fin de utilizar servicios, aplicaciones o software no autorizados[1].

Todo lo anterior incluso pueden ser soluciones especificadas y desplegadas en la empresa por departamentos distintos a TI (Stealth TI)[2], mayormente aplicaciones en nube[3], por su accesibilidad, flexibilidad y ubicuidad, entre otros atributos -aunque no limitados a estos.

shadowIT-01

Enfrentamos un probable incremento de costos, brechas en la seguridad de la información, pérdida o filtración de datos, ineficiencia operativa, duplicación de servicios, incapacidad para valorar apropiadamente el aporte de TI en los resultados de la organización, carencia de alineamiento de los servicios y soluciones de TI con los objetivos empresariales, impacto en las organizaciones cada vez más virtuales y distribuidas (oficinas remotas, teletrabajadores, socios comerciales, clientes).

Un peligro latente. Un sin número de amenazas. Un riesgo creciente. Todo esto en un marco de tiempo indeterminado –tal vez sepamos cuándo inició el servicio que causa todo esto pero difícilmente sabremos cuándo terminará. ¿Podremos analizar el comportamiento que conlleva al uso del Shadow IT? El costo de determinar, en estas condiciones, el origen de una violación, y tomar la acción correctiva puede ser grande, habría inseguridad para garantizar la continuidad del negocio conforme ha sido establecida por la organización, y el incumplimiento de los requisitos de cumplimiento puede tener serias consecuencias legales, incluyendo multas. Las brechas de seguridad pueden dañar la reputación de la empresa y la pérdida de confianza del consumidor del servicio.

Adivinaron, esto es porque las necesidades de TI de estos empleados no son satisfechas por los proveedores de TI en la empresa o por las soluciones con las que se cuenta. Claro, elaboramos como razones, pero no limitadas a, necesidad de cumplir objetivos; la falta de recursos y capacidades (tiempo, personal, equipos, presupuesto, conocimiento, experiencia, entre otros); prioridades, intereses, agenda personal; cultura organizacional; estructura de la organización (aparato burocrático); restricciones administrativas o presupuestarias para las adquisiciones; procesos internos engorrosos -para las adquisiciones, evaluaciones, autorizaciones, por ejemplo[4]; time-to-market; operaciones internas[5]; aspectos legales o de cumplimiento normativo; coyuntura económica, social o política; aversión o apetito de riesgo; demanda; consideremos que las soluciones que TI podría proporcionar tal vez no se ajusten a las necesidades actuales del negocio; necesidad de satisfacer las políticas corporativas (o de TI); no se considera de forma apropiada la perspectiva del negocio  y, más bien, se busca la facilidad de la administración (de TI).

Y el porcentaje es alto, aunque usted no lo crea, como lo muestra la gráfica que responde a la pregunta: ¿Conoce el número de aplicaciones Shadow IT que se utilizan en su empresa?[6]

shadowIT-02

Cabría preguntarse, ¿Cómo se asegura la continuidad del servicio (disponibilidad de plataforma/equipo, respaldo, transferencia de conocimiento)? ¿Qué acciones se deben seguir en caso unas credenciales se vean comprometidas (recuperación del control del servicio, modificación de credenciales)? ¿Cómo se plantea realizar el soporte técnico de la solución Shadow IT (será local y la persona tendrá la disponibilidad necesarias, o será externo y sujeto a contratación)? ¿De qué manera la solución Shadow IT podría comprometer la plataforma de TI de la organización (operación inadecuada o factores externos)? ¿Se puede integrar Shadow IT (algunas aplicaciones o servicios o hasta dispositivos) a los activos de TI e instalarles las medidas de seguridad apropiadas?[7] Si los clientes/usuarios claramente sienten que necesitan una determinada solución para compartir documentos de forma rápida o utilizar servicios en línea, ¿se puede incluir esto en la política de TI de la empresa?

Pero también son fuente de innovación y hasta pueden convertirse en prototipos de nuevos y futuros servicios de TI, siempre que estén alineados con los objetivos de la organización.

Detener esta ‘iniciativa’ será casi imposible –una razón es la “consumerización de TI”; implementar mecanismos para demorar su ‘aparición’ en la empresa, difícil –ya no es sólo una “inconveniencia”[8]. No tratemos de desafiar la fuerza de la gravedad. ‘Sobrevivir’ a ella es algo más plausible. No nos convirtamos en el enemigo. Negarla pensando que –aún- somos “lo máximo” es contraproducente, además de irresponsable.

Diversos autores nos brindan sus sugerencias –y muchas son evidentes, desde el punto de vista de la mejora continua o de la aplicación de marcos de trabajo o adopción de mejores prácticas en la industria:

  • Cambiar nuestro chip de la configuración por defecto “control” a la de “habilitador”.
  • Determinar dónde ocurre (¿limitaciones geográficas?) y por qué (¿apoyan realmente a los objetivos del negocio?); cómo ocurre (¿infraestructura controlada?); averiguar qué se utiliza sin autorización[9] (utilizar sniffers, gosip, otros); entender exactamente qué recursos se utilizan, con cuánta frecuencia, y quién los usa, qué datos están involucrados; qué aplicaciones y cuáles opciones son las que se utilizan –utilizar la propuesta 6W-2H para responder las preguntas anteriores.
  • Reducir los tiempos de evaluación –adoptemos recomendaciones de calidad y mejora continua.
  • Agilizar los procesos de implementación –apliquemos recomendaciones del PMI por ejemplo.
  • Proveamos mejores servicios que los obtenidos utilizando aplicaciones Shadow IT.
  • La nube no es un enemigo –pero no olvide crear mecanismos de autenticación, autorización y contabilidad adecuados.
  • Ser [verdaderamente] proactivos. Prioricemos la experiencia del cliente/usuario.
  • Reforzar lo que no será tolerado cuando se trata de proyectos Shadow IT. Implica que deberá buscarse la visibilidad suficiente para que las políticas específicas que deben aplicarse puedan ser aplicadas.
  • Priorizar los riesgos, bloquear en lo posible lo que sí es altamente riesgoso o restringir el uso de aplicaciones potencialmente dañinas.
  • Ofrecer alternativas.
  • Cuidar el presupuesto (flexibilidad, elasticidad) –porque Shadow IT no siempre está presupuestado.
  • Supervisar el consumo del servicio –contar con un análisis de tendencias para tomar decisiones.
  • Gestionar el servicio y, por supuesto, la seguridad del mismo, la que ofrece, y la que los clientes/usuarios necesitan en cumplimiento de las políticas de seguridad de la empresa. Si nuestros datos se replican (por las interesantes opciones de respaldo de muchas aplicaciones), ¿dónde terminarán? ¿quién los verá? ¿cómo serán utilizados?
  • Involucrarse con las unidades de negocio externas a TI –debemos buscarlas porque ya pasaron los días en que estas unidades buscaban a TI.
  • Aprobar las operaciones de Shadow TI de corto plazo –las aplicaciones ya están en operación y ayudaría el tomar un mejor conocimiento al explorar la tecnología para una solución de largo plazo. Los clientes/usuarios y el equipo de TI deben trabajar juntos para integrar estas herramientas y procesos, desarrollando un método para la adopción de soluciones futuras.

Eliminemos el oscurantismo -ya desde hace tiempo en muchas organizaciones el control que TI ejercía se ha venido erosionando, porque se ha perdido la confianza o porque nuevas [e interesantes] aplicaciones aparecen cada vez más rápido y son más fáciles de utilizar además de ser “justo lo que requerimos”, entre otras razones. Ya no sólo se trata de decirle al cliente/usuario si puede o no utilizar su Smartphone/tablet [personal] ni qué aplicaciones está autorizado a descargar o utilizar (LOL). Sí, sobre el dispositivo corporativo algo podemos hacer –e invertir[10].

Así, sería conveniente convertirse en un verdadero y proactivo proveedor de soluciones. Apliquemos un poco de inteligencia emocional y seamos los aliados que buscan resolver problemas tecnológicos –desde la perspectiva de los clientes/usuarios (apoyo en la creación de valor), aunque la solución no sea la más barata –pero seguramente más segura. Implica crear un sentido de cambio en cómo TI es –o será- vista dentro de la organización[11].

Mostremos cómo y por qué se hacen las cosas como se hacen, expongamos los motivos de la seguridad requerida por la organización, revisemos cómo el servicio Shadow IT apoya o apoyará  la política de seguridad de la empresa. Sinceremos nuestros recursos y capacidades para hacer frente a nuevos requerimientos del negocio.

Cambiemos la relación entre TI y las unidades de negocio. Esto requiere comunicación y entendimiento de ambas partes para no verse como obstáculo, una de la otra. Mejoremos la relación entre TI y los clientes/usuarios e incorporemos TI en las acciones y procesos de innovación de los clientes/usuarios –que potencialmente requerirán alguna solución Shadow IT. Hagamos que TI sea un recurso disponible para ayudar a los clientes/usuarios a maximizar el potencial de su tecnología porque esta relación es esencial para construir equipos fuertes.

La asociación entre TI y los clientes/usuarios comienza con la creación de la cultura adecuada y garantizar que los procesos hacen que trabajar con IT sea altamente eficiente [mi experiencia personal en RCP, MINEDU, y no soy el único].

Si la experiencia del cliente/usuario es segura y sin problemas, no van a tener necesidad de ir a Shadow IT para encontrar soluciones que les ayuden a ser más productivos[12]. Apoyemos una política de TI de puerta abierta para nuevos proyectos, asesoramiento y ayudar a proporcionar orientaciones para el diseño y la implementación de nuevos proyectos[13]. Tenga presente que su cliente es la empresa –y que la tecnología está cada vez más al alcance de todos[14] los clientes/usuarios –los que a su vez tienen cada vez más conocimiento técnico.

[1]      Fuente: https://www.armor.com/resources/newsroom/how-to-prevent-shadow-it/; disponible en mayo/2016

[2]      Fuente: https://en.wikipedia.org/wiki/Shadow_IT; disponible en mayo/2016

[3]      Fuente: http://www.delcor.com/resources/blog/how-to-handle-and-prevent-the-use-of-shadow-it-by-association-staff; disponible en mayo/2016

[4]      Fuente: http://relus.com/how-to-handle-shadow-it/; disponible en mayo/2016

[5]      Fuente: http://www.informationweek.com/strategic-cio/it-strategy/shadow-it-8-ways-to-cope/d/d-id/1319535; disponible en mayo/2016

[6]      Fuente: https://downloads.cloudsecurityalliance.org/initiatives/surveys/capp/Cloud_Adoption_Practices_Priorities_Survey_Final.pdf; disponible en mayo/2016

[7]      Fuente: http://www.cio.com/article/2380960/byod/6-tips-to-help-cios-manage-shadow-it.html; disponible en mayo/2016

[8]      Fuente: http://www.pomeroy.com/docs/default-source/white-papers/how-to-avoid-being-overrun-by-shadow-it.pdf; disponible en mayo/2016

[9]      Fuente: http://www.networkcomputing.com/applications/how-control-shadow-it/883700879; disponible en mayo/2016

[10]    Fuente: http://www.tomsitpro.com/articles/preventing-shadow-it,2-932.html; disponible en mayo/2016

[11]    Fuente: https://jumpcloud.com/blog/help-clients-prevent-shadow/; disponible en mayo/2016

[12]    Fuente: https://www.citrix.com/news/citrix-in-the-news/feb-2016/cso-online–how-to-prevent-shadow-it.html; disponible en mayo/2016

[13]    Fuente: http://www.csoonline.com/article/3032209/security/how-to-prevent-shadow-it.html#slide3; disponible en mayo/2016

[14]    Fuente: https://www.informatica.com/potential-at-work/shadow-it-fight-it-embrace-it-or-adapt-to-it.html#fbid=iOx6H05NHnZ; disponible en mayo/2016

Gestión del presupuesto de seguridad de TI

¿Presupuesto de seguridad de TI?

¿Recuerdan cuando los mayores llamaban a los pequeños para darles un caramelo y que se vayan a jugar a otra parte sin fastidiar? Claro hablo de los abuelos –y (cualquier semejanza con la realidad es pura coincidencia) de la actitud  de algunas organizaciones con respecto a la seguridad de TI [felizmente con tendencia decreciente según las estadísticas], a pesar de la interconexión global que hoy vivimos y de las noticias de exposición pública [no autorizada] de una variedad de datos sensibles del tipo personal, financiero, y de propiedad intelectual[1] [de la propia empresa y, más aún y con mayor razón, de nuestros clientes por estar sujetos a normativas y regulaciones de carácter legal y con responsabilidad penal], además de estrategias de negocio, entre otros.

Sí, la seguridad de TI no es una actividad colateral o complementaria, menos es un absoluto; tampoco se trata de considerar una sola tecnología ni de invertir en una herramienta en particular, ni de realizar una inversión única [sin considerar su sostenibilidad], ni aislada [ya que atañe a toda la organización]. Se trata de definir los niveles aceptables de riesgo para el negocio con el fin de estar en condiciones de justificar el gasto en consecuencia[2].

Entonces, si el negocio desea conocer cuál es el retorno de su inversión en seguridad, ¿cómo podemos demostrar esto? Una evaluación de la seguridad de la empresa por un tercero (estable y con permanencia en el mercado) podría ser una alternativa –para tener cierto grado de credibilidad porque nadie es profeta en su tierra reza el dicho. Claro obtenemos probablemente un informe situacional frío y resultado de una foto del momento, con algunas conclusiones [todo marcha según lo planeado; mejor; o peor y aquí recién accionamos] y recomendaciones del estado del arte de la tecnología de seguridad vigente. No nos engañemos pretendiendo tapar el sol con un dedo.

¿Ya utilizamos esta opción? Bueno. Otra alternativa podría ser demostrando un modelo de negocio legítimo [entender primero la cultura organizacional, lo que le es importante al negocio, y el negocio mismo] para las medidas de seguridad que se está buscando implementar [qué es importante, la disponibilidad, la confidencialidad, o la integridad de los datos –y centrar el caso sobre ello encontrando aliados que respalden la propuesta], y cómo estas medidas son inversiones a largo plazo para la organización [las comparaciones son malas dicen algunos pero, si a alguien le pasó algo malo por no adoptar las medidas de seguridad apropiadas y a tiempo, ¿por qué debemos nosotros contribuir con la estadística?], desarrollando un caso de negocio que incluya la financiación de funciones cruzadas y una fuerte cooperación en la empresa entre la seguridad, la planificación de la continuidad del negocio, recuperación de desastres, convergencia para una alineación más cercana de la seguridad física, seguridad de la información, seguridad operacional, y seguridad del personal –que podrían estar separadas en la organización pero proporciona la oportunidad de un aumento significativo de la eficiencia, la eficacia y reducción de costos, legal, otros.

De hecho, en cada vez más empresas, la junta directiva quiere saber qué iniciativas de seguridad están en marcha o se están planeando[3]. Pero aún más importante que la cantidad de dinero que se gasta es dónde y cómo se gasta ese dinero[4]; después de todo, nadie quiere gastar más de lo necesario [muchas empresas ya han pagado por un software pero no lo usan o no utilizan todas sus características de protección]. Según IDC[5], hay cuatro clases de empresas:

  • Derrotistas, completamente reactivas, invierten en seguridad de TI sólo del 5 al 6% de su presupuesto.
  • Negacionistas, dedicadas a satisfacer requisitos de cumplimiento –sin preocuparse mayormente de la sostenibilidad, invierten alrededor del 8% de su presupuesto en seguridad.
  • Realistas, han evolucionado hasta el punto en que la tienen los procesos de seguridad, personal capacitado y tecnología de todo en el equilibrio adecuado, invierten alrededor del 14% de sus presupuestos en materia de seguridad.
  • Egoístas, invierten aproximadamente el 12% de su presupuesto en medidas de seguridad, pero tienden a tener un exceso de confianza en sus sistemas de seguridad.

¿En cuál categoría cree que se encuentra su organización? Con respecto a niveles de madurez en seguridad de TI, el artículo dice que los realistas estarían entre los niveles de madurez tres (proceso formal de riesgo en toda la organización para la aplicación de tecnologías, políticas, habilidades, respuesta a incidentes, entre otros aspectos) y cuatro (visibilidad consistente para medir el rendimiento contra métricas de riesgo para las tecnologías, las políticas, capacitación técnica, seguridad, habilidades, ente otros aspectos).

Autoconocimiento señores [descubrir activos de información, identificados, catalogados y tratados en consecuencia] –y sinceramiento de nuestro nivel [superficie] de exposición [detectar vulnerabilidades] a las amenazas, reconociendo que no toda brecha de seguridad podrá ser cerrada[6]. Dieron en el clavo: riesgos y su [continua] gestión.

Si bien el informe mantiene que los empleados [su poca o ninguna capacitación sobre todo[7]] son aún una fuente alta de problemas de seguridad, no descartemos a priori lo demás.

idc

Ya descubrimos y detectamos, ahora no olvide que después debe identificar [determinar] las necesidades, priorizar y evaluar opciones –reconociendo fortalezas y debilidades en cuanto a recursos y capacidades la existencia de [y tal vez mejora de] procesos (o su carencia) –me refiero además a controles y contramedidas –que se deben desplegar, y la tecnología (desplegada, por desplegar, o carente). Y todo esto siguiendo el ciclo interminable de la re-evaluación [o mejora continua si les parece mejor] para asegurar la sostenibilidad y sustentabilidad de las contramedidas implementadas. Así es, la gestión de riesgos.

Los recursos (materia prima –aquí aplicamos el 6W-2H[8]) y capacidades (representan las habilidades desarrolladas a lo largo del tiempo para transformar los recursos en valor a través de la gestión, la organización, los procesos y el conocimiento[9] -el diferenciador clave son las habilidades) son activos del servicio de seguridad de la información que se presta. La siguiente figura[10] muestra esta relación.

activo de servicio

El mantra común es que la única manera de conseguir el presupuesto que desea es sufrir primero algún tipo de vulneración. Suena mal ¿verdad? ¿Cómo podemos conseguir presupuesto para la seguridad de TI? Aquí algunas sugerencias:

  • Influencie, influencie, influencie, no busque mandar y controlar –probablemente le hayan delegado la función pero probablemente no le han entregado el poder suficiente.
  • Hoy por hoy la seguridad de TI afecta no sólo a TI sino a TODA la organización. Céntrese en los esfuerzosque apoyan las iniciativasdel negocio [alineamiento, articulación son palabras clave aquí], ya que estos esfuerzos encuentranmásapoyo, y ayudan aconseguirapoyo interno [la literatura de gestión habla de identificar campeones, sponsors, que son gente de alto nivel que haya comprado la iniciativa y tenga el poder para apoyar en su ejecución].
  • Asegure que se entienda el valor [no sólo la necesidad] para el negocio [en todos los estamentos de la organización] –por supuesto no olvide al gerente de finanzas [no lo considere un enemigo pero, si es así, recuerde a Tzun Tsu: “mantén a tus amigos cerca y a tus enemigos aún más cerca”].
  • No caiga en la desesperación por conseguir presupuesto; no utilice tácticas de miedo vaticinando eventos apocalípticos porque, si no pasa nada, perderá credibilidad –y muy rápido.
  • No pida más presupuesto de lo que efectivamente será capaz de ejecutar[11]. Pronostique, priorice, con sentido y ciencia –cualifique y cuantifique [y no olvide poner en la ecuación de valor sus recursos y capacidades].
  • No descuide su ecosistema (otros proyectos, otros equipos de trabajo, otras unidades de negocio, el entorno interno y externo, la cultura, entre otros aspectos) porque puede afectar su capacidad paraejecutar y entregar -¿usted es el gestor verdad?
  • Deje el corazón de lado; no se trata de usted en cuanto a tecnología [lo que quiere, le falta, le interesa, o le parece mejor (porque es más nuevo, tiene más funciones, y otras excusas)]; se trata [siempre y en primer lugar] de lo que la organización necesita [demanda]. Recuerde, “Buscad primero el reino de Dios y su justicia y todo lo demás se os dará por añadidura” (Mt 6:33)”.
  • Hable con otras unidades de negocio dentro de la empresa para captar sus necesidades, preocupaciones y criterios de éxito; su participación contribuirá a garantizar que la empresa vea valor en su propuesta. Y cuando la empresa ve valor, todo el mundo gana.

No olvidemos la rotación de personal y la deserción. Ambos temas también ocasionan problemas en el presupuesto de seguridad de TI[12] -¿recuerdan los recursos y capacidades? Perder a un miembro experto de la fuerza laboral de seguridad de TI presenta un riesgo mayor para toda la organización. ¿Tiene una estrategia de retención?

[1]      Fuente: http://www.cio.com/article/3031644/leadership-management/how-to-convince-the-cfo-of-the-budgetary-security-need.html?token=%23tk.CIONLE_nlt_cio_security_2016-02-12&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Security%202016-02-12&utm_term=cio_security#tk.CIO_nlt_cio_security_2016-02-12; marzo/2016

[2]       Fuente: http://searchsecurity.techtarget.com/Advice-on-IT-security-budget-management; marzo/2016

[3]      Fuente: http://www.securityweek.com/security-budgets-are-are-we-spending-wisely; marzo/2016

[4]      Fuente: http://www.gtec.ca/it-security-where-should-the-money-go/; marzo/2016

[5]      Fuente: http://www-03.ibm.com/industries/ca/en/healthcare/documents/IDC_Canada_Determining_How_Much_to_spend_on_Security_-_Canadian_Perspective_2015.pdf; marzo/2016

[6]      Fuente: http://www.securityweek.com/enterprises-overly-reliant-perimeter-based-defenses-survey; marzo/2016

[7]      Fuente: http://www.business.com/internet-security/ctos-and-cfos-are-finally-seeing-eye-to-eye-on-cyber-security-spending/; marzo/2016

[8]      Fuente: http://fullvirtue.com/%E6%9C%80%E8%BF%91%E4%BC%81%E7%94%BB%E6%9B%B8%E3%82%92%E6%9B%B8%E3%81%84%E3%81%A6%E3%81%84%E3%81%A6%E3%82%8F%E3%81%8B%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%9F%E3%81%93%E3%81%A8/; marzo/2016

[9]      Fuente: http://itilv3.osiatis.es/estrategia_servicios_TI/introduccion_objetivos_activos_servicio.php; marzo/2016

[10]    Fuente: http://www.slideshare.net/jack_caceres/itil-slc-fundamentos-59542559; marzo/2016

[11]    Fuente: https://community.rapid7.com/community/infosec/blog/2015/11/02/security-budget-tips-from-cisos-for-cisos; marzo/2016

[12]    Fuente: http://www.gtec.ca/managed-security-service-provider-strategy-mitigates-cyber-risk-created-by-cybersecurity-workforce-and-technology-gap/; marzo/2016

SLA en el marco de la computación en nube -cloudcomputing

La mayoría de las transiciones a una solución de cloud computing implican un cambio de una solución gestionada técnicamente (“yo lo construyo, yo lo mantengo”) a una solución administrada por contrato (“alguien más está haciendo esto por mí, ¿cómo puedo asegurarme de que están haciendo lo que se supone deben hacer? “).

Este cambio requiere una mayor capacidad de negociación del contrato de TI para establecer los términos de la relación (“¿Qué obtengo?”) Y habilidades de gestión de proveedores para mantener la relación (“¿Cómo puedo asegurarme de que lo obtenga?”)[1]. Esto implica identificar primero los requerimientos del negocio y establecer los indicadores clave de rendimiento esperados[2]. No olvidemos que hablamos de un servicio –y lo necesitamos para proveer servicios.

Por un lado, Kristin Knapp, editor del sitio de SearchCloudComputing, nos recuerda que los acuerdos de nivel de servicio (SLA) establecen confianza; los usuarios quieren seguridad de que su proveedor le garantiza un cierto nivel de servicio.

Tenemos que ser capaces de articular nuestras expectativas cuando se está negociando el acuerdo con el proveedor –y no es sólo mirarlo a los ojos cuando buscamos una respuesta, ni conviene acelerar su proceso. Un SLA no es una solución de una sola parte[3] [sabemos que en todo SLA existen dos partes]. Una de las partes -el proveedor de servicio en la nube, por ejemplo- no debe imponer decisiones acerca de cómo deben hacerse las cosas, sobre todo cuando la otra parte -el cliente de servicios de nube, por ejemplo- tiene diferentes expectativas sobre cómo debería formularse el SLA. Existe un impacto tecnológico y legal, especialmente cuando buscamos utilizar una nube pública[4].

Ninguno de nosotros desea que un proveedor simplemente reconozca el problema –luego que nosotros como usuarios asentamos la reclamación correspondiente primero. Debe haber un vínculo con la cura – como un tiempo de respuesta de una media hora para los problemas de servicio de mayor gravedad.

También es importante entender lo que el SLA cubre en términos de lo que recibirás y cómo va a recibirlo si el proveedor incumple el acuerdo. Así, igual de importante, deseamos la seguridad de que nuestro proveedor deberá pagar (o reembolsar) si no se cumplen las garantías acordadas[5] -pero no sólo con crédito, que los usuarios en general podríamos aplicar a nuestra factura de nube o para la compra de otro servicio en la nube, ya que rara vez se compensa la pérdida financiera o de negocio que puede ocurrir después de una interrupción (o degradación) en el servicio.

De hecho, no [siempre] se trata de dinero, se trata de la capacidad de ofrecer un servicio. No es de extrañar que los precios de los servicios en nube bajen con el tiempo y así, la elección de un proveedor se va a centrar todo sobre la prestación del servicio y el mayor tiempo de actividad que ofrezca.

Por otro lado, los clientes deben estar a la altura, por sanidad. Y una de las mejores maneras de hacerlo es construir aplicaciones en la nube que son resistentes, tolerante a fallos y diseñadas específicamente para la nube. Y realmente se necesita diseñar contra fallos por cuanto los proveedores cuentan con [se apoyan en] esto para proporcionar sus servicios “diferenciados”. No olvidemos que ya existe la ISO/IEC 27017 aplicada a la seguridad en nube, y que la CSA está tras este punto.

Un SLA de nube debe incluir términos más granulares alrededor de la respuesta del proveedor y el tiempo de recuperación. En concreto, los SLA de nube deben incluir términos que abarcan el “ciclo de gestión de fallos” completo de un servicio en la nube, sugirió Jason Andersen de Stratus Technologies. Esto incluye cinco fases clave de fallo de un servicio en la nube:

  1. Darse cuenta de que hay un hecho/problema ocurrido
  2. Localizar el hecho/problema
  3. Aislar el hecho/problema
  4. Recuperación del hecho/problema
  5. Recuperación completa del hecho/problema

Muchos términos del SLA sólo hablan de la disponibilidad en nube en términos de un servicio que está “operativo” o “caído” –lo que hace atemorizante y confusa la tarea de establecer un SLA, y no tienen en cuenta los distintos niveles de desempeño que siempre existen entre ambos. ¿Cuánta degradación es requerida para que un servicio se considere ‘caído’? ¿Cuál es el tiempo de resolución ofrecido (el tiempo que tarda un proveedor de nube para resolver completamente un problema con su servicio)? En la granularidad de los términos utilizados está el asunto –el diablo está en los detalles (definiciones y terminología entre otros).

Por lo anterior, Tom Nolle de CIMI Corporation[6] nos sugiere establecer un SLA en nube como un pequeño proyecto.

Uno de los desafíos de establecer un SLA en la nube es que la experiencia entregada por una aplicación en nube depende de varios aspectos o zonas de servicio por lo que la primera tarea es desarrollar un mapa de entidades que muestre quién provee qué porción del servicio en nube y cómo esta porción transita entre estas entidades.

Por ejemplo, las comunicaciones empleadas, si son accesos locales o remotos, los dispositivos empleados, las cargas de trabajo exigidas, los flujos de trabajo generados –que son en última instancia la base de los SLA.

Para una buena gestión del SLA y decisiones de su política, es necesario medir el comportamiento de cada uno de los proveedores de las diferentes zonas que componen el servicio en nube. Podemos comenzar con mecanismos para medir el tiempo de respuesta y pasar de eso a las condiciones de medición en los puntos de frontera de estas diferentes zonas. Un buen inicio es medir en el punto de conexión del usuario. Para la observación de la zona frontera alguna forma de supervisión de tráfico o protocolo es difícil de superar.

Sin la consideración y herramientas adecuadas, incluso un buen SLA probablemente fallará porque no se sabrá que está siendo violado ni por qué. Recopile datos en un repositorio de forma natural. Esta recopilación de datos le permite ejecutar consultas para analizar el rendimiento y las condiciones en el tiempo y establecer líneas de base para un comportamiento normal, así como los umbrales de lo que se considera que son violaciones al SLA. La analítica de red puede ser una base sólida para basar las decisiones alrededor de los acuerdos de nivel de servicio de computación en nube.

Para que el SLA de computación en nube y los servicios que ofrece tengan éxito es fundamental tomar un enfoque organizado para el SLA y las decisiones que surgen de su cumplimiento.

Así que la pregunta es, entonces, ¿Qué estás haciendo para monitorear el servicio [de tu proveedor en nube] y qué estás haciendo para asegurarte de que estás [el servicio que ofreces está] disponible?

Dan Sullivan[7] nos recuerda que si bien no existe precisamente una plantilla [proporciono un ejemplito[8]], hay puntos que no debemos olvidar –aunque nos parezcan obvios ahora pueden escapársenos en el momento:

  • Suacuerdo de nivel deservicio en la nube(SLA) debe especificar los nivelesmínimos derendimiento paracada servicio, codificadocon parámetros específicos –insisto, debemos ser específicos, y no aceptar generalidades[9].
  • Tenga en cuenta losrequisitospara documentaruna interrupcióny el tiempo quetiene para presentaruna reclamación.
  • Esvital entenderlos procedimientos de documentaciónde interrupciónantes de usar cualquierservicio en la nube.
  • Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros –y que nuestros datos permanezcan siendo nuestros [o definir a priori la manera de recuperarlos].
  • Seguridad de los datos en la nube –lo que es una responsabilidad compartida: proveedor-usuario[10]; todos esperan que alguien [usted] sea responsable.
  • Gobierno de la nube -de probar procesos internos a comprobar el cumplimiento de su proveedor con las regulaciones.
  • Contratos firmados –locales e internacionales (buen viaje).
  • Tarifas y costos ocultos.
  • Dependencias con terceros.
  • Retención de datos.
  • Servicios de datos –controles de seguridad por ejemplo.
  • Versiones, versiones, versiones –de todo y para todo.
  • Licencias, licencias, licencias –de todo y para todo.
  • Estándares empleados –porque heredamos las certificaciones.
  • No olviden lo básico[11]:
    • Codifica losparámetros específicosy los nivelesmínimos requeridospara cada elementodel servicio [y busquemos utilizar las mejores prácticas que encontremos para que no olvidemos ninguno, ITIL® por ejemplo], así como los recursospor incumplimiento deesos requisitos.
    • Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros, afirmar la propiedad de nuestra institución de sus datos almacenados en el sistema del proveedor de servicios [y que nuestros datos permanezcan siendo nuestros], y especifica sus derechos para recuperarla [definiendo a priori la manera de recuperarlos].
    • Detalles dela infraestructura del sistemay las normasde seguridadque deben mantenersepor elproveedor de servicios, junto con sus derechospara auditarsu cumplimiento o al menos teneracceso a susinformes de auditoríaescritos porun tercero de confianza –de verdad, no es broma.
    • Especificasus derechos ycosto paraseguirydejar de utilizar el
  • Ni tampoco olvidar que debe existir un balance entre seguridad y riesgos[12] [redundancia, disponibilidad, continuidad, resiliencia, y otros términos relacionados], comprender la noción de niveles “aceptables” de riesgo[13], y los riesgos de firmar un contrato estándar[14] porque importa:
    • Tiempo de actividad / inactividad.
    • Periodo de tiempo de inactividad (inactividad recurrente en un periodo pre-establecido).
    • Rendimiento y tiempo de respuesta –niveles máximos de latencia aceptados, QoS, entre otros aspectos.
    • Tiempo de inactividad programado.
    • Tiempo de corrección de errores.
    • Infraestructura /

Para garantizar un modelo de responsabilidad compartida en nube -o un enfoque por el que tanto el proveedor de la nube y sus clientes son responsables de ciertos aspectos de la seguridad- las empresas deben definir claramente sus propias responsabilidades, junto con las del proveedor de la nube. Por tanto, debe establecerse una línea clara [que podría llegar a ser muy delgada] que indique cuál de las partes es responsable no sólo de ciertos aspectos de la seguridad de los datos, sino además de la seguridad de las aplicaciones, máquinas virtuales, interfaces, configuraciones de servicio y más en la nube. “La infraestructura de nube ofrece la capacidad de escalar una aplicación horizontalmente, pero sólo si la aplicación posee una arquitectura para aprovechar esa capacidad”, dijo Ed Featherston, Senior Enterprise Architect and Director en Collaborative Consulting. Si la aplicación no escala debido a un defecto de diseño, el proveedor puede seguir cumpliendo con los requisitos del SLA[15]. De ahí que convenga separar la nube de la aplicación; TI debe ser capaz de distinguir los problemas potenciales de infraestructura de problemas de la aplicación.

“Va a ser dependiente del contrato, pero está en nosotros como empresa, asegurar de que está muy claramente indicado en el contrato dónde está dicha línea”, dijo Peter Keenan, Director de Seguridad de la Información en Lazard, una firma de asesoría y gestión de activos financieros en Nueva York. “Creo que se va a realizar caso por caso y servicio por servicio”.

No olvide asegurarse de tener un seguimiento continuo del ecosistema de su proveedor porque las cosas cambian diariamente. Claro, es aconsejable utilizar herramientas especializadas e integradas lo mejor posible para nuestro ecosistema de nube.

De igual forma, cuanta más supervisión regulatoria enfrente tu empresa, más tienes que preocuparte por cuestiones de jurisdicción de datos. Consulta con tus propios auditores de gobierno, asegúrate de saber si existen regulaciones estatales o locales que podrían aplicarse a los datos almacenados en la nube, y asegúrate de que sabes dónde almacenará los datos tu proveedor de nube[16].

Probablemente si aplicamos la herramienta 6W-2H nos ayude a determinar cosas importantes como: estado, acceso, tiempo de respuesta, tiempo de caducación, versionamiento, fallo, entre otros. ¿Cuántos nueves deseamos de disponibilidad? ¿Quién es culpable de qué, cuándo y por qué?…

Sugiero al lector [si aún está interesado] revisar la exhaustiva información de la Comisión Europea sobre Acuerdos de Nivel de Servicio en Cloud Computing[17].

[1]      Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[2]      Fuente: http://searchcloudcomputing.techtarget.com/tip/Defining-the-right-cloud-SLA-requirements-up-front, junio/2012

[3]      Fuente: http://www.ibm.com/developerworks/cloud/library/cl-slastandards/, enero/2013

[4]      Fuente: http://searchcloudcomputing.techtarget.com/tip/Embrace-these-cloud-service-level-agreement-best-practices, setiembre/2015

[5]     Fuente: http://searchcloudcomputing.techtarget.com/news/4500252585/IT-pros-crave-a-new-kind-of-cloud-SLA, agosto/2015

[6]     Fuente: http://searchcloudapplications.techtarget.com/tip/Avoid-the-cloud-computing-SLA-trap?utm_medium=EM&asrc=EM_NLN_48206904&utm_campaign=20151002_How%20will%20microservices%20impact%20the%20cloud?_fchurchville&utm_source=NLN&track=NL-1806&ad=903291&src=903291, setiembre/2015

[7]      Fuente: http://searchcloudcomputing.techtarget.com/answer/Sidestep-problems-be-your-own-cloud-SLA-watchdog, julio/2014

[8]      Fuente: http://clkrep.lacity.org/onlinecontracts/2009/C-116359_c_11-20-09.pdf, noviembre/2009

[9]      Fuente: http://searchcloudapplications.techtarget.com/answer/When-cloud-providers-fail-Recovering-from-an-SLA-violation, octubre/2013

[10]    Fuente: http://searchcloudcomputing.techtarget.com/news/4500256467/Cloud-security-requires-shared-responsibility-model, octubre/2015

[11]    Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[12]    Fuente: http://lts.lehigh.edu/services/explanation/guide-evaluating-service-security-cloud-service-providers, 2015

[13]    Fuente: http://searchcloudcomputing.techtarget.com/tip/Cloud-data-security-outside-the-vacuum-Find-acceptable-levels-of-risk, noviembre/2013

[14]    Igual que Nota 1.

[15]    Igual que Nota 4.

[16]    Fuente: http://searchcloudcomputing.techtarget.com/tip/Dont-let-governance-methods-die-after-a-cloud-migration, enero/2014

[17]    Fuentes (entre otras):
https://ec.europa.eu/digital-agenda/en/cloud-select-industry-group-service-level-agreements
https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-standardisation-guidelines
https://ec.europa.eu/digital-agenda/en/news/cloud-computing-service-level-agreements-exploitation-research-results
https://ec.europa.eu/digital-agenda/en/news/study-report-standards-terms-and-performances-criteria-service-level-agreements-cloud-computing , octubre/2015