ISACA Journal
Volume 2, 2,018 

Translated Articles 

Arquitectura de seguridad de la información: Evaluación de brechas y priorización 

Rassoul Ghaznavi-Zadeh, CISM, COBIT Foundation, SABSA SCF, TOGAF 9 

Se puede usar un enfoque descendente de la arquitectura de seguridad empresarial para construir una arquitectura de seguridad impulsada por el negocio.1 Sigue un enfoque para priorizar los proyectos de seguridad que se identifican como parte de la evaluación de la arquitectura, al tiempo que se garantiza la alineación del negocio.

Los riesgos y atributos del negocio pueden usarse para identificar controles de seguridad relevantes y se puede realizar una evaluación de madurez para identificar el nivel de madurez actual y deseado de esos controles y crear un plan de acción. Los pasos se pueden resumir de la siguiente manera:2

  1. Seleccione un marco de seguridad que sea relevante para las empresas, como las desarrolladas por Payment Card Industry (PCI), el Instituto Nacional de Estándares y Tecnología de EE.UU. (NIST) o la Organización Internacional de Normalización (ISO).
  2. Comprender y documentar los objetivos y atributos del negocio.
  3. Identifique los controles del marco que son relevantes para el negocio y pueden ser verificados por el riesgo comercial.
  4. Ajuste y personalice los controles según los requisitos y la operación del negocio.
  5. Realice un análisis de brechas y una evaluación de madurez para identificar lo que falta o está incompleto.
  6. Desarrollar un programa para implementar los controles faltantes o incompletos.

La Figura 1 es un resumen de estos pasos y una representación visual del ciclo de vida de la arquitectura.

Marco de arquitectura y evaluación de brechas

El uso de marcos tales como COBIT o ISO 27001 puede ayudar a identificar una lista de controles de seguridad relevantes que se pueden usar para desarrollar una arquitectura de seguridad integral que sea relevante para las empresas.

COBIT 5 para Information Security3 cubre los servicios, la infraestructura y el habilitador de aplicaciones e incluye capacidades de arquitectura de seguridad que se pueden usar para evaluar la madurez de la arquitectura actual.

La Figura 2 ilustra un ejemplo de cómo las capacidades del servicio y las tecnologías de soporte en COBIT se pueden usar para construir un marco y controles de arquitectura de seguridad. Todos los controles identificados deben relacionarse con los riesgos y atributos del negocio.

Evaluación de madurez

Una vez que se desarrolla el marco de la arquitectura de seguridad y se identifican las brechas, el siguiente paso es crear un plan de implementación y especificar prioridades. Normalmente, este sería un programa a largo plazo, según el tamaño y el presupuesto de la organización. Este es un paso importante en el ciclo de vida de la arquitectura y debe realizarse cuidadosamente de acuerdo con los requisitos del negocio. La Figura 3 muestra un ejemplo del primer resultado de una evaluación de brechas y planificación de proyectos.

Los niveles de madurez se calculan en función de diversos factores, como la disponibilidad de los controles necesarios, la eficacia de los controles, el control de su funcionamiento e integridad y la optimización periódica.

La lista de controles especifica los proyectos y las tareas que deben realizarse una vez que se identifican las lagunas. Esta lista podría ser bastante larga, dependiendo del negocio, y la pregunta principal es cómo priorizar estas tareas y proyectos.

Gestión de riesgos

El riesgo comúnmente se clasifica en dos categorías: riesgo comercial y riesgo operacional. Si bien el negocio identifica el riesgo comercial y lo utiliza para definir los controles de la arquitectura de seguridad, el riesgo operacional incluye amenazas, vulnerabilidades y nuevos hallazgos de auditoría, y su administración puede complementar los controles que ya existen. La Figura 4 ofrece una vista de las fuentes de riesgo de seguridad de la información, incluido el riesgo comercial frente al riesgo operacional.

El riesgo de seguridad de la información normalmente se calcula utilizando métodos cualitativos o cuantitativos. Las técnicas de evaluación de riesgos, como The Open Group Open FAIR4, se pueden usar para evaluar la probabilidad y el impacto de un riesgo, calcular un puntaje de riesgo e identificar los controles de mitigación apropiados para remediar el riesgo (figura 5).

Sin entrar en una discusión profunda sobre las técnicas de gestión de riesgos y cómo se realizan, el objetivo es tener un diagrama de calor para las áreas de riesgo de seguridad, calcular un nivel de gravedad para cada uno y asignar un puntaje de riesgo a cada uno según el nivel de gravedad. Por ejemplo, un riesgo crítico tendría un puntaje de 5, un alto riesgo tendría un puntaje de 4, y así sucesivamente.

Deben hacerse dos comentarios importantes sobre las evaluaciones de riesgos de seguridad de la información:

  1. En última instancia, todo el riesgo de seguridad de la información debe correlacionarse con el riesgo comercial. Cualquier riesgo de seguridad de la información que no se pueda relacionar con un riesgo comercial relevante no es válido y no se consideraría crítico para la empresa.
  2. Aunque seguiría la misma lógica para priorizar el riesgo operativo, este artículo se centra y cubre solo la priorización de los controles de seguridad que se identificaron como parte de la evaluación de la brecha de la arquitectura de seguridad. Estos controles se usarían para remediar el riesgo comercial de alto nivel y normalmente se tomarían de marcos estándar tales como COBIT o aquellos desarrollados por ISO o NIST.

Arquitectura prioridad de controles

El método utilizado para identificar prioridades implica un registro de riesgos comerciales. Cada empresa tiene (o debería tener) un registro de riesgos en su lugar. Normalmente, un registro de riesgos comerciales captura el riesgo comercial general, su probabilidad e impacto en los negocios, y una estrategia de mitigación.

En la figura 6 se muestra un ejemplo de registro de riesgo comercial estándar.

A continuación, se genera un diagrama de calor utilizando el riesgo comercial capturado en el registro de riesgos y un puntaje asignado a cada riesgo, como se explicó anteriormente (figura 7).

Para poner esto en contexto, los dos ejemplos de riesgo enumerados en la figura 6 tendrán los puntajes de riesgo que se muestran en la figura 8.

Como se explicó anteriormente, cualquiera de los controles identificados como parte de la evaluación de la arquitectura de seguridad se correlaciona con un riesgo comercial relevante y un riesgo de seguridad de la información relevante. El puntaje de riesgo comercial y el puntaje de riesgo de seguridad de la información se usan para calcular el puntaje de riesgo general, de la siguiente manera:

Puntuación general de riesgo = puntaje de riesgo empresarial x puntuación de riesgo de seguridad de la información

Este cálculo se usa para priorizar la implementación.

Para explicar esto con un ejemplo, usando la tabla de registro de control que se muestra en la figura 3, la figura 9 representa la vinculación de los controles con el riesgo comercial con puntuaciones ya identificadas. Además, suponiendo que el control no está en su lugar, el puntaje de riesgo de seguridad de la información se calcula por separado. Por ejemplo, si la protección contra malware del punto final no está en su lugar, el riesgo de robo de IP es bastante alto (5).

Debe tenerse en cuenta que esta es una explicación muy simple y las técnicas de gestión de riesgos como Open FAIR pueden requerir un poco más de esfuerzo para calcular el puntaje de riesgo, pero el enfoque sería el mismo.

Al usar este método, es fácil priorizar los controles o proyectos y planificar su implementación correctamente. Esta es una experiencia útil en la gestión del ciclo de vida de la arquitectura. Garantizará la alineación de las prioridades de seguridad y comerciales y las justificará automáticamente.

En el ejemplo que se muestra en la figura 9, la prioridad de implementar un sistema de protección contra malware de punto final es mucho más alta que tener una solución de DLP en su lugar.

Conclusión

El uso de un registro de riesgos comerciales para priorizar los proyectos de seguridad es un enfoque apropiado que no solo justifica la gestión del ciclo de vida de los proyectos de seguridad, sino que también garantiza la alineación comercial y minimiza el impacto potencial.

Los pasos esenciales necesarios para garantizar que los controles de seguridad y los proyectos estén alineados con las prioridades comerciales incluyen:

  1. Asignación de controles de seguridad con escenarios de riesgo empresarial
  2. Identificar el puntaje de riesgo de seguridad de la información si el control no está en su lugar
  3. Identificar el puntaje de riesgo del negocio para el control relevante
  4. Cálculo del puntaje de riesgo general utilizando la fórmula: puntaje de riesgo general = puntaje de riesgo comercial x puntaje de riesgo de seguridad de la información
  5. Priorizar proyectos basados en el puntaje de riesgo general

Notas finales

1 Ghaznavi-Zadeh, R.; “Enterprise Security Architecture: A Top-Down Approach,” ISACA Journal, vol. 4, 2017, www.isaca.org/Journal/archives/Pages/default.aspx
2 Ibid. See the previous article for more details on this process.
3 ISACA, COBIT 5 for Information Security, USA, 2013, www.isaca.org/cobit/pages/info-sec.aspx
4 The Open Group, The Open Group Open FAIR Certification Program, www.opengroup.org/certifications/openfair

Rassoul Ghaznavi-Zadeh, CISM, COBIT Foundation, SABSA SCF, TOGAF 9
Ha sido consultor de seguridad de TI desde 1999. Comenzó como profesional de seguridad y redes informáticas y desarrolló su conocimiento sobre negocios empresariales, arquitectura de seguridad y gobierno de TI. Ghaznavi-Zadeh es un mentor y entrenador de seguridad informática y ha escrito libros sobre arquitectura de seguridad empresarial y hacking y penetración éticos.

 

Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.