En la primera parte de esta serie nos enfocamos a revisar algunos términos importantes y, sobre todo, a comentar acerca de los conocimientos y habilidades que un CISO (recordemos que así llamaremos al responsable de seguridad) debe tener. Ahora nos concentraremos en dar recomendaciones concretas sobre la forma de convencer a la organización para apoyar los esfuerzos de seguridad y, particularmente, asegurar el patrocinio de los ejecutivos; entendiendo este patrocinio no sólo como un apoyo económico a las actividades de seguridad, sino como un compromiso de ayudar a que la organización tenga un manejo de riesgos de la información de acuerdo a los requerimientos del negocio. 

En esta sección analizaremos las principales causas de la falta de apoyo, después estudiaremos algunas herramientas para convencer a empleados y ejecutivos para que apoyen los esfuerzos de seguridad y, por último, incluiremos algunas recomendaciones para el CISO en la implementación de estas herramientas.

Posibles causas de la falta de apoyo 

Aunque existen muchas razones para las que los empleados y ejecutivos de una organización no apoyen los esfuerzos de seguridad, las razones que aquí se enumerarán son las que resultaron más relevantes después de dos sesiones de discusión que se tuvieron con varios especialistas de SCITUM. Con base en dichas causas, se detallan algunas acciones concretas para lograr el apoyo de todos los involucrados.

  • Percepción distinta de los riesgos: Durante las sesiones se encontró que una de las principales causas por la que los ejecutivos no apoyan los esfuerzos de seguridad es que su percepción del riesgo es muy diferente de la del CISO.  Cuando a estos ejecutivos se les presentan varios casos de problemas de seguridad en empresas similares, o incluso se les muestran las vulnerabilidades de seguridad que tienen en su organización(1), la respuesta más común es: “sí, pero el riesgo es muy bajo; nunca ha pasado nada grave”. La causa raíz más común en este tipo de actitud es la ignorancia sobre los verdaderos riesgos o una subvaluación de  las probabilidades de ocurrencia (2).
  • No existe una visión clara de la solución: En ocasiones, los ejecutivos pueden identificar claramente la necesidad de la seguridad, pero pueden no tener así de clara la forma de solucionar esos problemas. Por ejemplo, un ejecutivo podría pensar más en términos tecnológicos (“implementemos un firewall”) y otro podría ver la solución más en términos normativos (“necesitamos primero un análisis de riesgos y luego un conjunto de políticas”).
  • Percepción de resultados pobres o inadecuados en el pasado. Puede ser que los ejecutivos estén reticentes a apoyar los esfuerzos de seguridad debido a que previamente no se obtuvieron, desde su perspectiva,  los resultados esperados. En las reuniones mencionadas, se identificaron dos causas raíz de esta problemática:
    • Los ejecutivos solicitaron algo inalcanzable o fuera de contexto. La actitud más típica es suponer que la seguridad es un estado binario, que se tiene o no se tiene. La oración “estamos aprobando $100,000 dólares (o cualquier cantidad), queremos seguridad” es representativa de este tipo de percepción. El problema es similar al anterior ¿cuál?, pues en el fondo significa que los ejecutivos no han entendido que la seguridad tiene que ver con el manejo de riesgos y que no es un estado binario. El CISO no generó un reporte enfocado a que los ejecutivos pudieran medir el avance en los esfuerzos de seguridad. En otras palabras, nunca tuvieron indicadores claros sobre el beneficio de las inversiones en seguridad (3).
    • Percepción de que la estrategia de seguridad no está alineada al negocio. Si los ejecutivos no perciben que la estrategia de seguridad apoya los objetivos del negocio, pueden deducir que no es clave para el éxito de la organización. Bajo esta situación, será muy difícil que den su apoyo a las iniciativas de seguridad. Atrás de dicha situación pueden encontrarse varias causas raíz: el CISO no desarrolló la estrategia pensando realmente en los objetivos de la organización; la estrategia de seguridad no se ha actualizado a la velocidad de cambio de la empresa; la estrategia sí está alineada al negocio, pero el lenguaje o forma de presentación de dicha estrategia no es clara para los ejecutivos; o el CISO no ha hecho adecuadamente los esfuerzos de comunicación de dicha estrategia.

Como se observa en los párrafos anteriores, todas las causas mencionadas están asociadas con la percepción de empleados y ejecutivos (1,3 y 4), y con tener objetivos poco claros o desalineados con el negocio (2,4). Si queremos lograr apoyos importantes para los esfuerzos de seguridad, es muy importante que el CISO tome en cuenta esas brechas y desarrolle una estrategia para cerrarlas; sólo así podrá garantizar el apoyo tan anhelado. La siguiente sección brinda algunas herramientas para esta importante labor.

Algunas herramientas útiles 

Una vez que el CISO haya entendido el estilo de su audiencia y las razones para la falta de apoyo a los esfuerzos, podrá desarrollar una estrategia completa para vender la idea a los distintos involucrados.

Esta sección presenta algunas herramientas que le pueden ayudar al CISO en esa labor. Sin embargo, es importante que el CISO no se limite a las opciones aquí presentadas, sino que, con base en su experiencia, en la investigación que haga y en el contexto particular de su organización, determine las acciones que sean más apropiadas y que revise continuamente la estrategia para actualizarla y mejorarla. La tabla 1 presenta las herramientas mencionadas, las causas que atacan y una breve descripción.

Herramienta o actividad sugerida Causa asociada Descripción
Desarrollar escenarios de riesgo 1, 2, 3 Un escenario de riesgo presenta dos vistas: La situación actual y la situación deseada. En la “situación actual” se presentan gráficamente las amenazas, los riesgos asociados (junto con sus impactos) y la forma en que pueden explotar las vulnerabilidades existentes (en la tecnología, los procesos o la gente). En la “situación deseada” se presentan las medidas de seguridad necesarias para manejar adecuadamente los riesgos del escenario (4).En las últimas partes de esta serie de artículos expondremos con detalle la forma de crear y exponer “escenarios de riesgo”.
Calcular y dar a conocer el retorno de inversión en seguridad (Return on Security Investment,  ROSI) 1, 3, 4 El ROSI se calcula restando el costo del control a implementar de los beneficios esperados por implementarlo(5). Si el ROSI resulta positivo, entonces quiere decir que financieramente conviene implementar dicho control.En el último artículo de la serie se presentarán algunos cálculos del ROSI.
Presentar noticias y artículos relevantes de revistas, sitios Web y periódicos 1 El objetivo de estas noticias es generar más conciencia sobre las amenazas y los riesgos asociadas. El CISO deberá tener cuidado de no exagerar en la presentación de estas noticias, evitando algún tipo de técnica “FUD” (6).
Crear y presentar una visión completa (holística) de la seguridad de la información, acompañarla de un plan general de implementación (Road Map) 2, 3, 4 Es importante que todos los involucrados perciban el aseguramiento de la información (IA) como un esfuerzo completo, que abarca a toda la empresa y que tiene que ver con todo tipo de riesgos en la información; para ello, es recomendable que el CISO desarrolle una visión holística sobre la estrategia de Information Assurance, acompañada de una hoja de ruta que desglose los proyectos que se realizarán a través del tiempo para llegar a esa visión.
Presentar vulnerabilidades o incidentes de seguridad asociados con la organización 1 Presentar a los ejecutivos los resultados de un análisis de riesgos, de una prueba de penetración  (puede incluir ingeniería social) o de un análisis de vulnerabilidades puede ayudar a concientizarlos sobre los riesgos existentes.Es importante no reducir el problema a la parte tecnológica o a la solución de un problema muy específico.
Difundir información accesible para ejecutivos (por ejemplo artículos de Magazcitum) 1 En muchos sitios Web existen diversos artículos (a veces llamados «white papers«) que están orientados a educar a los ejecutivos sobre los riesgos en su información. Al final de la serie daremos algunos ejemplos.
Organizar un taller de manejo de riesgos con los ejecutivos del negocio 1, 2, 3, 4 El taller tiene el objetivo de concienciar a los ejecutivos sobre los riesgos de la información. Es recomendable cubrir los siguientes temas:Conceptos de seguridad y riesgos (7).Tipos de controles.Presentar los resultados de análisis de riesgos.Ponderar durante el taller el impacto de los riesgos (muy importante).

Revisar los controles sugeridos.

La experiencia de SCITUM es que después del taller se tiene un lenguaje común (lingua franca) y, además, se tienen percepciones mucho más homogéneas sobre los esfuerzos de IA que se están haciendo.
Crear un tablero de control con métricas de seguridad y publicarlo periódicamente. 3, 4 En el siguiente artículo detallaremos varias métricas útiles para establecer.Si ya se ha implementado un tablero de control, es importante concienciar a los ejecutivos sobre la naturaleza de cada métrica y cómo tomar decisiones con base en él.
Difundir las necesidades de cumplimiento de regulaciones.Alinear la estrategia de IA a las regulaciones. 1,4 Todo empleado debe ejecutar adecuadamente su trabajo. En este sentido, es responsabilidad de los ejecutivos el cumplir y hacer cumplir las regulaciones existentes en la empresa, sean internas o externas.El incumplimiento de una regulación es un riesgo para una organización, que puede tener impactos muy serios (incluyendo el cierre de la empresa). El CISO debe asegurar que los esfuerzos de seguridad ayudan al cumplimiento de esas regulaciones, y esas regulaciones pueden ayudar al CISO a que exista un mayor apoyo para los proyectos de seguridad de la información.

Tabla 1. Herramientas sugeridas para convencer a los ejecutivos y empleados.

  

Recomendaciones generales

Si usted es el responsable de vender las ideas de seguridad y, por tanto,  usted será el que utilice las herramientas anteriores y desarrolle las distintas actividades para implementarlas (presentaciones, programa de concientización en seguridad, juntas y sesiones con ejecutivos y empleados, etc.), a continuación encontrará algunas ideas que pueden serle útiles:

  1. Enfóquese a transmitir los conceptos de forma sencilla. Cuide el tipo de lenguaje a usar y apóyese en gráficas e ilustraciones. Si va a presentar varios elementos o ideas y va a usar Power Point o un software similar, utilice la animación para que aparezca un elemento a la vez y usted pueda explicarlo más fácilmente. Evite tecnicismos. Si requiere usarlos, explíquelos primero y, de preferencia, hágalo de una forma muy gráfica(8).
  2. Busque generar emociones positivas y evitar las negativas. Entendiendo las motivaciones, creencias, hábitos y costumbres de los involucrados (es decir entendiendo sus paradigmas mentales) es posible particularizar las herramientas de apoyo para generar empatía en ellos.
  3. Por ejemplo, si el CISO utiliza un escenario divertido, fácil de entender, en el que se vean los beneficios de los controles propuestos y las situaciones presentadas son similares a las que se tienen en la organización (sin atacar a ninguna persona o departamento de la empresa), es mucho más probable que la audiencia sea empática con los mensajes y con la estrategia de seguridad.
  4. Comunique hacia los distintos tipos de audiencias. Existen algunos modelos de referencia que tipifican los estilos de pensamiento de cada persona. Uno de ellos se denomina “el modelo de los sombreros de Bono”, pues su autor, Edward Bono, escribió un libro en el que explica los seis tipos de pensamientos. Por ejemplo, las personas asociadas con el “sombrero blanco” están orientadas a hablar sobre hechos, cifras, cosas concretas. Las de “sombrero rojo”, en cambio, son emotivas por naturaleza, ven las cosas como motivantes, retadoras, emocionantes, alegres, etcétera.
  5. El modelo de Bono puede ser una buena guía para considerar los distintos tipos de audiencia; así, para los “sombreros blancos” puede usar herramientas como estadísticas(9) hechos recientes(10) y el cálculo del ROSI.
  6. Céntrese siempre en los riesgos para el negocio. Ese debe ser el objetivo común. No se distraiga con otro tipo de justificaciones racionales, datos estadísticos u otras cosas.
  7. Traduzca las cosas a su organización. Para los escenarios, los ejemplos, los controles a implementar, y lo que vaya a comunicar, utilice las áreas y los procesos de su empresa, la infraestructura tecnológica que tiene la organización y su lenguaje particular.
  8. El objetivo es que todos los involucrados sientan que la seguridad está pensada en sus necesidades y las de la organización; que no lo vean como algo ajeno a su realidad. Por ejemplo, en una organización le pueden llamar SIA (Sistema Integral de Administración)  a la implementación de su ERP, aunque el producto que estén utilizando sea SAP. En este caso, en vez de referirse genéricamente a un “ERP” o incluso a “SAP”, es mejor llamarle igual que como lo hace la organización: “SIA”.
  9. Aproveche adecuadamente los apoyos externos. Las herramientas son para aprovecharlas, no para limitarnos o hacer que nuestros proyectos se ajusten a ellas. Aproveche a los consultores, los marcos de referencia (p.ej. ISO-27000) y las regulaciones para desarrollar una mejor estrategia, pero no se aferre irracionalmente a ellos (12).
  10. Genere material de apoyo enfocado a los distintos públicos. Vender la idea de seguridad no es algo que se haga una sola vez; más bien es un esfuerzo continuo. Para ello, es recomendable ir creando un conjunto básico de presentaciones, documentos, referencias, cuadros de ROSI, etc., que puedan ser reutilizados para convencer a las distintas audiencias.

Esperamos que con las recomendaciones anteriores el CISO pueda tener más y mejores herramientas para vender y convencer a sus distintas audiencias, no olvidando que hay que completar sus conocimientos técnicos con diversas habilidades adicionales, y siempre alinear la estrategia de seguridad a la del negocio.

Continuará…

[email protected]

[1] Pueden ser en su infraestructura, en la gente o en sus procesos.

[2]  Esta ignorancia no es sólo responsabilidad de los ejecutivos. El CISO deberá tomar una actitud abierta y propositiva, y nunca de arrogancia o desdén hacia ellos. Por otro lado, tampoco hay que eliminar la posibilidad de que la verdadera causa raíz sea que el CISO está sobrevalorando los riesgos, u otras causas que el CISO deberá identificar.

[3]  Puede ser que el CISO haya generado ciertos reportes, el punto es que, de alguna manera,  no logró transmitir los beneficios a los ejecutivos.

[4]  Es importante recalcar que “manejar adecuadamente” un riesgo puede significar distintas cosas: eliminarlo (si esto es posible), minimizar las probabilidades de ocurrencia o su impacto, transferirlo o, incluso, aceptarlo.

[5]  Los beneficios se miden calculando la pérdida esperada una vez implementando el control, y restándole la pérdida esperada cuando no se ha implementado ningún control.

[6] FUD significa: fair, uncertainty and doubt. Fue una técnica muy usada en los años 70 por algunos fabricantes de equipo de cómputo.

[7] Explicar la terna amenaza, vulnerabilidad y riesgo.

[8] Por ejemplo, para explicar que un IPS (Intrusion Prevention System) instalado dentro de una red no protege los tráficos que no pasan por los segmentos de red a los que está conectado, SCITUM ha utilizado exitosamente una lámina de Power Point en la que todo el tráfico que pasa por el IPS es de color verde (indicando que es tráfico válido), el tráfico que es rechazado por el IPS es de color rojo (tráfico que no está permitido) y el tráfico que no pasa por el IPS es de color morado (indicando que es tráfico que no sabemos si es válido o no).

[9]  Como la famosa estadística anual del CSI y el FBI.

[10] Nada mejor que “INFOSEC Year in Review” que cada año publica el Profr. Kabay.

[11]  SAP es la marca de un software muy popular del tipo Enterprise Resource Planning o ERP.

[12]  Por ejemplo, un cliente de SCITUM estaba tratando de implementar rigurosamente todos los controles de ISO-27001, sin haber hecho una priorización de los mismos, y malinterpretando la propia recomendación del estándar al desarrollar su “declaración de aplicabilidad” (Statement of Applicability, SOA).