248928225-Bibliografia-04-ISO-27005.pdf

NORMA NORMA TÉCNIC TÉCNICA A PERUANA

NTP-IS NTP-ISO/I O/IEC EC 27005 27005 2009

Comisión de Normalización y de Fiscalización de Barreras Comerciales No Arancelarias - INDECOPI Calle de La Prosa 138, San Borja (Lima 41) Apartado 145 Lima, Perú

EDI. Tecnología de la información. Técnicas de seguridad. Gestión del riesgo en seguridad de la información EDI. Information technology. Security techniques. Information security risk management management (EQV. ISO/IEC 27005:2008 EDI. Information technology – Security techniques – Information security risk management)

2009-09-30 1ª Edición

R.029-2009/INDECOPI-CNB. Publicada el 2009-11-07 Precio basado en 95 páginas I.C.S: 35.040 ESTA NORMA ES RECOMENDABLE Descriptores: EDI, tecnología de la información, técnicas de seguridad, gestión del riesgo, seguridad de la información

ÍNDICE página ÍNDICE PREFACIO 1.

ALCANCE

1

2.

REFERENCIAS NORMATIVAS

1

3.

TÉRMINOS Y DEFINICIONES

2

4.

ESTRUCTURA DE ESTA NORMA TÉCNICA PERUANA

3

5.

BASES

5

6.

VISTA PANORÁMICA DEL PROCESO DE GESTIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

8

7.

DETERMINACIÓN DETERMINACIÓN DEL CONTEXTO

12

8.

EVALUACIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

17

TRATAMIENTO TRATAMIENT O DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

32

ACEPTACIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

39

COMUNICACIÓN COMUNICAC IÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

40

MONITOREO Y REVISIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

42

ANTECEDENTES

46

9. 10. 11. 12. 13.

i

ÍNDICE página ÍNDICE PREFACIO 1.

ALCANCE

1

2.


1

3.


2

4.


3

5.

BASES

5

6.

VISTA PANORÁMICA DEL PROCESO DE GESTIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

8

7.

DETERMINACIÓN DETERMINACIÓN DEL CONTEXTO

12

8.

EVALUACIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

17

TRATAMIENTO TRATAMIENT O DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

32

ACEPTACIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

39

COMUNICACIÓN COMUNICAC IÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

40

MONITOREO Y REVISIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN

42

ANTECEDENTES

46

9. 10. 11. 12. 13.

i

ANEXOS ANEXO A ANEXO B ANEXO C ANEXO D ANEXO E ANEXO F

47 56 73 76 82 92

ii

PREFACIO

A.

RESEÑA HISTÓRICA

A.1 La presente Norma Técnica Peruana ha sido elaborada por el Comité Técnico de Normalización de Codificación e intercambio electrónico de datos, mediante el Sistema 1 o de Adopción, durante el mes de agosto de 2009, utilizando como antecedente a la norma ISO/IEC 27005:2008 Information technology – Security techniques – Information security risk management. A.2 El Comité Técnico de Normalización de Codificación e intercambio electrónico de datos presentó a la Comisión de Normalización y de Fiscalización de Barreras Comerciales No Arancelarias –CNB-, con fecha 2009-08-25, el PNTP-ISO/IEC 27005:2009, para su revisión y aprobación, siendo sometido a la etapa de Discusión Pública el 2009-08-28. No habiéndose presentado observaciones fue oficializado como Norma Técnica Peruana NTP-ISO/IEC 27005:2009 EDI. Tecnología de la información. Técnicas de seguridad. Gestión del riesgo en seguridad de la información, 1ª Edición, el 07 de noviembre de 2009. A.3 Esta Norma Técnica Peruana es una adopción de la norma ISO/IEC 27005:2008. La presente Norma Técnica Peruana presenta cambios editoriales referidos principalmente a terminología empleada propia del idioma español y ha sido estructurada de acuerdo a las Guías Peruanas GP 001:1995 y GP 002:1995.

B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIÓN DE LA NORMA TÉCNICA PERUANA Secretaría

GS1 PERU

Presidente

Roberto Puyó

Secretaria

Mary Wong

ENTIDAD

REPRESENTANTE

DISTRIBUIDORA MAYORISTA SYMBOL S.A. Adela Barcenas Walter Equizabel iii

DROKASA PERU S.A.

Juan Aquije

E. WONG S.A.

Marcela Aparicio Rolando Bartra

FOLIUM S.A.C.

Roberto Huby

IBC SOLUTIONS PERU S.A.C.

Oscar Velásquez Daniella Orellana

ITS CONSULTANTS S.A.C.

Ricardo Dioses

OFICINA DE NORMALIZACION PREVISIONAL Roberto Puyó PONT. UNIV. CATOLICA DEL PERU

Viktor Khlebnikov Willy Carrera

PRESIDENCIA DEL CONSEJO DE MINISTROS

Max Lázaro Cesar Vílchez

PROCTER & GAMBLE DEL PERU S.A.

Javier Kameya

SUPERINTENDENCIA DE ADMINISTRACION Daniel Llanos TRIBUTARIA – SUNAT Flor Febres TECNOLOGÍA FLEXOGRAFICA S.A.

Luis Chávez Saavedra

TCI S.A.

Renzo Alcántara

UNILEVER ANDINA PERU S.A.

Rolando Rivadeneira Luis Villena

GS1 PERU

Tatiana Peña

---oooOooo---

iv

NORMA TÉCNICA PERUANA

NTP-ISO/IEC 27005 1 de 95

EDI. Tecnología de la información. Técnicas de seguridad. Gestión del riesgo en seguridad de la información 1.

ALCANCE

Esta Norma Técnica Peruana establece lineamientos para la gestión del riesgo en seguridad de la información. Esta Norma Técnica Peruana apoya los conceptos generales especificados en la norma ISO/IEC 27001 y está diseñado para asistir a la implementación satisfactoria de la seguridad de la información en base a un enfoque de gestión del riesgo. Es importante conocer los conceptos, modelos, procesos y tecnologías descritos en las normas ISO/IEC 27001 e ISO/IEC 27002 para entender cabalmente esta NTP. Esta Norma Técnica Peruana es aplicable a todo tipo de organizaciones (por ejemplo: empresas comerciales, dependencias gubernamentales, organizaciones sin fines de lucro) que tratan de administrar los riesgos que podrían comprometer la seguridad de la información de la organización.

2.


Las siguientes normas contienen disposiciones que al ser citadas en este texto, constituyen requisitos de esta Norma Técnica Peruana. Las ediciones indicadas estaban en vigencia en el momento de esta publicación. Como toda Norma está sujeta a revisión, se recomienda a aquellos que realicen acuerdos con base en ellas, que analicen la conveniencia de usar las ediciones recientes de las normas citadas seguidamente. El Organismo Peruano de Normalización posee la información de las Normas Técnicas Peruanas en vigencia en todo momento.



2.1

Normas Técnicas Internacionales

2.1.1

ISO/IEC 27001:2005

Information technology – Security techniques – Information security management systems – Requirements.

2.1.2

ISO/IEC 27002:2005

Information technology – Security techniques – Code of practice for information security management.

3.


Para los fines de esta NTP, se aplican los términos y definiciones que aparecen en las normas ISO/IEC 27001, ISO/IEC 27002 y los siguientes: 3.1

impacto: Cambio adverso en el nivel de objetivos empresariales logrados.

riesgo en la seguridad de la información: El potencial de que una 3.2 amenaza dada explote las vulnerabilidades de un activo o grupo de activos y cause así daño a la organización. NOTA: Se mide en términos de una combinación de la probabilidad de un evento y su consecuencia.

evitamiento del riesgo: Decisión de no involucrarse en una acción para 3.3 retirarse de una situación de riesgo. comunicación del riesgo: Intercambio o compartir información sobre el 3.4 riesgo entre quien toma las decisiones y otros interesados. estimación del riesgo: Proceso para asignar valores a la probabilidad y 3.5 consecuencias de un riesgo.



NOTA 1: En el contexto de esta NTP, el término “actividad” se utiliza en vez del término “proceso” para la estimación del riesgo. NOTA 2: En el contexto de esta NTP, el término “posibilidad” se utiliza en vez del término “probabilidad” para la estimación del riesgo.

identificación del riesgo: Proceso para encontrar, listar y caracterizar 3.6 elementos de riesgo. reducción del riesgo: Acciones que se toman para reducir la probabilidad, 3.7 consecuencias negativas o ambas asociadas con un riesgo. retención del riesgo: Aceptación de la carga de la pérdida o el beneficio de 3.8 la ganancia a partir de un riesgo en particular. NOTA: En el contexto de los riesgos para la seguridad de la información, sólo se consideran consecuencias negativas (pérdidas) para la retención del riesgo.

transferencia del riesgo: Compartir con otra parte la carga de la pérdida o 3.9 el beneficio de la ganancia respecto de un riesgo. NOTA: En el contexto de los riesgos para la seguridad de la información, sólo se consideran consecuencias negativas (pérdidas) para la transferencia del riesgo.

4.


Esta NTP contiene la descripción del proceso de gestión del riesgo en seguridad de la información y sus actividades. El capítulo 5 proporciona información sobre los antecedentes. El capítulo 6 proporciona una vista panorámica del proceso de gestión del riesgo en seguridad de la información.



Todas las actividades de gestión del riesgo en seguridad de la información que se presentan en el capítulo 6 se describen posteriormente en los capítulos siguientes:

-

Establecimiento del contexto en el capítulo 7,

-

Evaluación del riesgo en el capítulo 8,

-

Tratamiento del riesgo en el capítulo 9,

-

Aceptación del riesgo en el capítulo 10,

-

Comunicación del riesgo en el capítulo 11,

-

Monitoreo y revisión del riesgo en el capítulo 12.

En los anexos se presenta información adicional para las actividades de gestión del riesgo en seguridad de la información. El Anexo A (Definición del alcance y límites del proceso de gestión del riesgo en seguridad de la información) establece el contexto. El Anexo B se refiere a la identificación y valorización de los activos y evaluación de impacto (ejemplos para activos), el Anexo C se refiere a ejemplos de amenazas típicas y el Anexo D a ejemplos de vulnerabilidades típicas. En el Anexo E se presentan ejemplos sobre enfoques de evaluación del riesgo en seguridad de la información. El Anexo F presenta restricciones para la reducción del riesgo. Todas las actividades de gestión del riesgo tal como se presentan de el capítulo 7 al capítulo 12 se estructuran del modo siguiente:

Insumo: Identifica cualquier información requerida para realizar la actividad. Acción: Describe la actividad.



Guía de implementación: Provee guía sobre el desempeño de la acción. Parte de esta guía puede no ser conveniente en todos los casos y en consecuencia otras maneras de realizar la acción pueden ser más apropiadas. Producto: Identifica toda información derivada luego de realizar la actividad.

5.

BASES

Es necesario tener un enfoque sistemático sobre la gestión del riesgo en seguridad de la información para identificar las necesidades de la organización respecto de los requisitos de seguridad de la información y para crear un sistema eficaz de gestión de seguridad de la información (ISMS, por sus siglas en inglés). Este enfoque debería ser conveniente para el entorno de la organización y en particular debería estar alineado con la gestión general del riesgo de la empresa. Los esfuerzos de seguridad deben enfrentar los riesgos de manera eficaz y oportuna cuando y donde sea necesario. La gestión del riesgo en seguridad de la información debería ser parte integral de todas las actividades de gestión de seguridad de la información y debería aplicarse tanto a la implementación como a la operación en curso de un ISMS. La gestión del riesgo en seguridad de la información debe ser un proceso continuo. El proceso debe establecer el contexto, evaluar los riesgos y tratarlos utilizando un plan de tratamiento de riesgos para implementar las recomendaciones y decisiones. La gestión del riesgo analiza lo que puede ocurrir y cuáles serían las consecuencias posibles, antes de decidir qué debe hacerse y cuándo para reducir el riesgo a un nivel aceptable. La gestión del riesgo en seguridad de la información debe contribuir a lo siguiente:

-

Identificar los riesgos.

-

Evaluar los riesgos en términos de sus consecuencias para la empresa y la posibilidad de su ocurrencia.

-

La comunicación y comprensión de la posibilidad y consecuencias de estos riesgos.

-

El establecimiento de un orden de prioridades para el tratamiento del riesgo.



-

Priorización de acciones para reducir la ocurrencia de riesgo.

-

Participación de los interesados cuando se toman las decisiones de gestión del riesgo e información sobre la situación de la gestión del riesgo.

-

Eficacia del monitoreo del tratamiento del riesgo.

-

Monitoreo y revisión regulares de los riesgos y del proceso de gestión del riesgo.

-

Captación de información para mejorar el enfoque de gestión del riesgo.

-

Educación a gerentes y personal respecto a los riesgos y acciones que se toman para mitigarlos.

El proceso de gestión del riesgo en seguridad de la información puede aplicarse a la organización en su conjunto, a cualquier parte específica de la organización (por ejemplo: un departamento, una ubicación física, un servicio), a cualquier sistema de información, existente o planeado, o a aspectos particulares del control (por ejemplo: planeamiento de la continuidad del negocio).

6. VISTA PANORÁMICA DEL PROCESO DE GESTIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN El proceso de gestión del riesgo en seguridad de la información consiste en establecer el contexto (Capítulo 7), evaluar el riesgo (Capítulo 8), tratar el riesgo (Capítulo 9), aceptar el riesgo (Capítulo 10), comunicar el riesgo (Capítulo 11) y monitorear y revisar el riesgo (Capítulo 12).

NORMA TÉCNICA TÉCNICA PERUANA

NTP-ISO/I NTP-ISO/IEC EC 27005 27005 7 de 95

DETERMINACION DEL CONTEXTO

EVALUACION DEL RIESGO ANALISIS DEL RIESGO

O G S E I R L E D N Ó I C A C I N U M O C

IDENTIFICACION DEL RIESGO

ESTIMACION DEL RIESGO

EVALUACION DEL RIESGO DECISION SOBRE EL RIESGO DEL PUNTO 1 Evaluación de satisfacción

No

Si

O G S E I R L E D N Ó I C A U L A V E Y O E R O T I N O M

TRATAMIENTO DEL RIESGO DECISION SOBRE EL RIESGO DEL PUNTO 2 Tratamiento satisfactorio

No Si

ACEPTACION DEL DEL RIESGO FIN DE LA PRIMERA O SUBSIGUIENTES ITERACIONES

FIGURA 1 – Proceso de gestión del riesgo de seguridad de la información



Tal como lo ilustra la Figura 1, el proceso de gestión de seguridad de la información puede ser iterativo para la evaluación del riesgo y/o para las actividades de tratamiento del riesgo. Un enfoque iterativo para la conducción de la evaluación del riesgo puede incrementar la profundidad y detalle de la evaluación en cada iteración. El enfoque iterativo provee un buen balance entre minimizar el tiempo y el esfuerzo que se emplea en identificar los controles y a la vez asegurar que se evalúe apropiadamente los altos riesgos. Primero se determina el contexto. Luego se realiza una evaluación del riesgo. Si esto provee suficiente información para determinar efectivamente efectivamente las acciones requeridas para modificar los riesgos a un nivel aceptable, entonces la tarea está completa y sigue el tratamiento del riesgo. Si la información es suficiente, se conducirá otra iteración de la evaluación del riesgo con el contexto revisado (por ejemplo criterios de evaluación del riesgo, criterios de aceptación del riesgo o criterios de impacto) posiblemente en partes limitadas del alcance total (véase la Figura 1, Decisión sobre el Riesgo Capítulo 1). La eficacia en el tratamiento del riesgo depende de los resultados de la evaluación del riesgo. Es posible que el tratamiento del riesgo no conduzca inmediatamente a un nivel aceptable de riesgo residual. En esta situación, podría requerirse otra iteración de la evaluación del riesgo con parámetros de contexto cambiados (por ejemplo evaluación del riesgo, aceptación del riesgo o criterios de impacto), si fuera necesario, seguido de otro tratamiento del riesgo (véase la Figura 1, Decisión sobre el Riesgo Capítulo 2). La actividad de aceptación del riesgo tiene que asegurar que los gerentes de la organización acepten explícitamente los riesgos residuales. Esto es especialmente importante en una situación donde la implementación de controles se omite o pospone, por ejemplo debido al costo. Durante todo el proceso de gestión del riesgo en seguridad de la información es importante que los riesgos y su tratamiento se comuniquen a los gerentes apropiados y al personal operativo. Incluso antes del tratamiento de los riesgos puede ser muy valioso contar con información sobre los riesgos identificados para administrar los incidentes y puede ayudar a reducir el daño potencial. La conciencia de los gerentes y el personal respecto de los riesgos, la naturaleza de los controles empleados para mitigar los riesgos y las áreas de preocupación preocupación para la organización ayudan a tratar los incidentes y los eventos inesperados de la manera más eficaz. Deben documentarse los resultados detallados de toda actividad del proceso de gestión del riesgo en seguridad de la información y de los dos puntos de decisión sobre el riesgo.



La norma ISO/IEC 27001 especifica que los controles implementados dentro del alcance, límites y contexto del ISMS deben basarse en el riesgo. La aplicación de un proceso de gestión del riesgo en seguridad de la información puede satisfacer este requisito. Existen muchos enfoques por medio de los cuales se puede implementar exitosamente el proceso en una organización. La organización debe utilizar el enfoque que mejor se acomode a sus circunstancias para cada aplicación específica del proceso. En un ISMS, determinar el contexto, evaluar el riesgo, desarrollar un plan de tratamiento del riesgo y aceptar el riesgo son parte de la fase del “plan”. En la fase de “hacer” del ISMS, se implementan las acciones y controles requeridos para reducir el riesgo a un nivel aceptable de acuerdo con el plan de tratamiento del riesgo. En la fase de “verificar” del ISMS, los gerentes determinarán la necesidad de revisiones de la evaluación del riesgo y el tratamiento del riesgo a la luz de los incidentes y cambios en las circunstancias. En la fase de “actuar”, se realizan todas las acciones requeridas, incluyendo la aplicación adicional del proceso de gestión del riesgo en seguridad de la información. La tabla siguiente resume las actividades de gestión del riesgo en seguridad de la información relevantes a las cuatro fases del proceso del ISMS:

TABLA 1 – Alineamiento del ISMS y del Proceso de Gestión del Riesgo en Seguridad de la Información Proceso ISMS

Proceso de Gestión del Riesgo en Seguridad de la Información Determinar el contexto

Plan

Evaluar el riesgo Desarrollar el plan de tratamiento del riesgo Aceptar el riesgo

Hacer

Implementar el plan de tratamiento del riesgo Monitoreo y revisión continuos de los riesgos

Revisar Hacer

Mantener y mejorar el Proceso de Gestión del Riesgo en Seguridad de la Información


7.

DETERMINACIÓN DEL CONTEXTO

7.1

Consideraciones generales


Insumo: Toda la información sobre la organización que sea relevante para determinar el contexto de la gestión del riesgo en seguridad de la información. Acción: Se debería establecer el contexto para la gestión del riesgo en seguridad de la información, lo cual implica establecer los criterios básicos necesarios para la gestión del riesgo en seguridad de la información (7.2), definir el alcance y los límites (7.3) y establecer una organización apropiada que opere la gestión del riesgo en seguridad de la información (7.4). Guía de implementación Es esencial determinar el propósito de la gestión del riesgo en seguridad de la información, ya que esto afecta el proceso general y la determinación del contexto en particular. Este propósito puede:

-

Apoyar un ISMS.

-

Aplicar la ley y evidenciar diligencia debida.

-

Preparar un plan de continuidad del negocio.

-

Preparar un plan de respuesta al incidente.

-

Describir los requisitos de seguridad de la información para un producto, servicio o mecanismo.

En los capítulos 7.2, 7.3 y 7.4 se trata en más detalle la guía de implementación para establecer los elementos del contexto que se requieren para apoyar un ISMS.



NOTA: La norma ISO/IEC 27001 no utiliza el término “contexto”. Sin embargo, todo el capítulo 7 se refiere a los requisitos de “definir el alcance y límites del ISMS” [4.2.1 a)], “definir una política del ISMS” [4.2.1 b)] y “definir el enfoque de la evaluación del riesgo” [4.2.1 c)], especificados en ISO/IEC 27001.

Producto: La especificación de los criterios básicos, el alcance y los límites y la organización para el proceso de gestión del riesgo en seguridad de la información.

7.2

Criterios básicos

Dependiendo del alcance y objetivo de la gestión del riesgo se puede aplicar distintos enfoques. El enfoque también puede ser diferente para cada iteración. Se debe seleccionar o desarrollar un enfoque de gestión del riesgo apropiado que resuelva criterios básicos como: criterios de evaluación del riesgo, criterios de impacto, criterios de aceptación del riesgo. Además, la organización debe evaluar si se dispone de los recursos necesarios para: -

Una evaluación del riesgo y establecer un plan de tratamiento del riesgo.

-

Definir e implementar políticas y procedimientos, implementación de controles seleccionados.

-

Monitorear controles.

-

Monitorear el proceso de gestión del riesgo en seguridad de la información.

incluyendo

la

NOTA: Véase también la norma ISO/IEC 27001 (Capítulo 5.2.1) concerniente al suministro de recursos para la operación de implementación de un ISMS.



Criterios de evaluación del riesgo Los criterios de evaluación del riesgo deben desarrollarse para evaluar el riesgo de seguridad para la información de la organización considerando lo siguiente: -

El valor estratégico del proceso de información empresarial.

-

El carácter crucial de los activos de información involucrados.

-

Requisitos legales y regulatorios y obligaciones contractuales.

-

Importancia operativa y empresarial de la disponibilidad, confidencialidad e integridad.

-

Las expectativas y percepciones de los interesados así como las consecuencias negativas para el buen nombre y la reputación.

Adicionalmente, se puede utilizar los criterios de evaluación del riesgo para especificar prioridades para el tratamiento del riesgo.

Criterios de impacto Se debe desarrollar y especificar criterios de impacto en términos del grado de daño en costos para la organización causados por un evento contra la seguridad de la información considerando lo siguiente: -

Nivel de clasificación del activo de información impactado.

-

Infracciones a la seguridad de la información (por ejemplo pérdida de confidencialidad, integridad y disponibilidad)

-

Operaciones impedidas (internas o de terceros)

-

Lucro cesante y valor financiero.

-

Perturbación de los planes y plazos.



-

Daño a la reputación.

-

Infracciones de estipulaciones legales, regulatorias o contractuales.

NOTA: Véase también la norma ISO/IEC 27001 [Capítulo 4.2.1 d) 4] concerniente a la identificación de criterios de impacto para pérdidas de confidencialidad, integridad y disponibilidad.

Criterios de aceptación del riesgo Se debe desarrollar y especificar criterios de aceptación del riesgo. Los criterios de aceptación del riesgo a menudo dependen de los intereses, políticas, metas, objetivos de los interesados en la organización. Una organización debe definir sus propias escalas para los niveles de aceptación del riesgo. Durante el desarrollo se deben considerar los siguientes factores: -

Los criterios de aceptación del riesgo pueden incluir umbrales múltiples con un nivel objetivo deseado del riesgo, pero con advertencias para los altos gerentes referentes a aceptar riesgos por encima de este nivel en determinadas circunstancias.

-

Se puede expresar los criterios de aceptación del riesgo como la tasa de utilidad estimada (u otro beneficio empresarial) respecto del riesgo estimado.

-

Se puede aplicar distintos criterios de aceptación del riesgo a distintas clases de riesgo, por ejemplo, no se puede aceptar riesgos que podrían resultar en el incumplimiento de regulaciones o leyes, mientras que se puede permitir la aceptación de riesgos altos si esto se especifica como un requisito contractual.

-

Los criterios de aceptación del riesgo pueden incluir requisitos para un tratamiento adicional futuro, por ejemplo se puede aceptar un riesgo si existe aprobación y compromiso de accionar para reducirlo a un nivel aceptable dentro de un período definido.



Los criterios de aceptación del riesgo pueden diferir de acuerdo a por cuánto tiempo se espera que el riesgo exista; por ejemplo, el riesgo se puede asociar con una actividad temporal o de corto plazo. Se debe establecer los criterios de aceptación del riesgo considerando lo siguiente: -

Criterios empresariales Aspectos legales y regulatorios Operaciones Tecnología Finanzas Factores sociales y humanitarios

NOTA: Los criterios de aceptación del riesgo corresponden a “criterios para aceptar riesgos e identificar el nivel aceptable del riesgo”, según se especifica en la norma ISO/IEC 27001 Cápitulo 4.2.1 c) 2).

Se puede encontrar más información en el Anexo A.

7.3

El alcance y los límites

La organización debe definir el alcance y los límites de la gestión del riesgo en seguridad de la información. El alcance del proceso de gestión del riesgo en seguridad de la información debe definirse para asegurar que se tomen en cuenta todos los activos relevantes en la evaluación del riesgo. Además se tiene que identificar los límites [véase también la norma ISO/IEC 27001 Capítulo 4.2.1 a)] para enfrentar los riesgos que puedan surgir dentro de esos límites. Se debe recolectar información sobre la organización para determinar el entorno en el que opera y su relevancia para el proceso de gestión del riesgo en seguridad de la información. Cuando se definen el alcance y los límites, la organización debe considerar la información siguiente: -

Los objetivos, estrategias y políticas empresariales estratégicas de la organización.



-

Procesos de negocios.

-

Las funciones y estructura de la organización.

-

Los requisitos legales regulatorios y contractuales aplicables a la organización.

-

La política de seguridad de información de la organización.

-

El enfoque general de la organización respecto de la gestión del riesgo.

-

Activos de información.

-

Ubicaciones de la organización y sus características geográficas.

-

Restricciones que afecten a la organización.

-

Expectativa de los interesados.

-

Entorno socio-cultural.

-

Interfases (es decir, intercambio de información con el entorno).

Adicionalmente, la organización debe proporcionar justificación para cualquier exclusión del alcance. Algunos ejemplos del alcance de la gestión del riesgo pueden ser una aplicación de Tecnología de Información - TI, una infraestructura de TI, un proceso de negocio o una parte definida de una organización. NOTA: El alcance y límites de la gestión del riesgo en seguridad de la información se relaciona al alcance y límites del ISMS que se requiere en la norma ISO/IEC 27001 4.2.1a).

Se puede encontrar más información en el Anexo A.


7.4


Organización para la gestión del riesgo de seguridad en la información

Se debe establecer y mantener la organización y responsabilidades para el proceso de gestión del riesgo en seguridad de la información. Los siguientes son los roles y responsabilidades principales de esta organización: -

Desarrollo del proceso de gestión del riesgo en seguridad de la información conveniente para la organización.

-

Identificación y análisis de los interesados.

-

Definición de roles y responsabilidades de todas las partes tanto internas como externas a la organización.

-

Establecimiento de las relaciones requeridas entre la organización y los interesados, así como las interfases con las funciones de gestión del riesgo en las altas esferas de la organización (por ejemplo gestión del riesgo operativo), así como las interfaces con otros proyectos o actividades relevantes.

-

Definición de los caminos para el escalamiento de las decisiones.

-

Especificación de los registros que deben mantenerse.

Los gerentes apropiados de la organización deben aprobar esta estructura. NOTA: ISO/IEC 27001 requiere determinar y proveer los recursos necesarios para establecer, implementar, operar, monitorear, revisar, mantener y mejorar un ISMS [5.2.1 a)]. Se puede considerar la organización para las operaciones de gestión del riesgo como uno de los recursos requeridos por la norma ISO/IEC 27001.


8. EVALUACIÓN INFORMACIÓN


DEL

RIESGO

EN

SEGURIDAD

DE

LA

8.1 Descripción general de la evaluación del riesgo en seguridad de la información NOTA: La actividad de evaluación del riesgo se conoce como el proceso en la norma ISO/IEC 27001.

Insumo: Determinación de criterios básicos, el alcance y los límites, y la organización para el proceso de gestión del riesgo en seguridad de la información. Acción: Se debe identificar, cuantificar o describir cualitativamente, así como priorizar los riesgos contra los criterios y objetivos de evaluación del riesgo relevantes para la organización. Guía de implementación: Un riesgo es una combinación de las consecuencias que se seguiría de la ocurrencia de un evento no deseado y de la posibilidad de la ocurrencia del evento. La evaluación del riesgo cuantifica o describe cualitativamente el riesgo y permite a los gerentes priorizar los riesgos de acuerdo con la gravedad que perciben u otros criterios establecidos. La evaluación de riesgo consiste de las siguientes actividades: -

Análisis del riesgo (véase el apartado 8.2) que comprende: -

-

Identificación del riesgo (véase el apartado 8.2.1) Estimación del riesgo (véase el apartado 8.2.2) Evaluación del riesgo (véase el apartado 8.3)



La evaluación del riesgo determina el valor de los activos de la información, identifica las amenazas y vulnerabilidades aplicables que existen (o podrían existir), identifica los controles existentes y su efecto en el riesgo identificado, determina las consecuencias potenciales y finalmente prioriza los riesgos derivados y los ordena respecto del conjunto de criterios de evaluación del riesgo establecidos en la determinación del contexto. La evaluación del riesgo se conduce a menudo en dos (o más) iteraciones. Primero se realiza una evaluación de alto nivel para identificar riesgos potencialmente altos que implican una mayor evaluación. La siguiente iteración puede incluir otra consideración profunda de riesgos potencialmente altos revelados en la iteración inicial. Allí donde esto provea información insuficiente para evaluar el riesgo, se conducen más análisis detallados probablemente en partes del alcance total y posiblemente utilizando un método diferente. La organización debe decidir la selección de su propio enfoque para la evaluación del riesgo en base a los objetivos y la meta de evaluación del riesgo. El Anexo E presenta enfoques sobre evaluación del riesgo en seguridad de la información. Producto: Una lista de riesgos evaluados priorizados de acuerdo con criterios de evaluación del riesgo.

8.2

Análisis del riesgo

8.2.1

Identificación del riesgo

8.2.1.1

Introducción a la identificación del riesgo

El propósito de la identificación del riesgo es determinar qué podría suceder que cause una pérdida potencial y entender cómo, dónde y por qué podría ocurrir la pérdida. Los pasos escritos en los apartados que siguen al apartado 8.2.1 deben recolectar datos de insumos para la actividad de estimación del riesgo. NOTA: Las actividades descritas en los capítulos siguientes deben describirse en el siguiente orden dependiendo de la metodología aplicada.


8.2.1.2


Identificación de activos

Insumo: Alcance y límites para la evaluación del riesgo a conducirse, lista de interesados con propietarios, ubicación, función, etc. Acción: Se debe identificar los activos dentro del alcance establecido (se relaciona con la norma ISO/IEC 27001, apartado 4.2.1 d) 1)). Guía de implementación: Un activo es cualquier cosa que tenga valor para la organización y que por lo tanto requiera protección. Para la identificación de activos debe recordarse que un sistema de información es más que hardware y software. La identificación de activos debe realizarse a un nivel adecuado de detalle que proporcione suficiente información para la evaluación del riesgo. El nivel de detalle utilizado en la identificación de activos influenciará la cantidad general de información recolectada durante la evaluación del riesgo. El nivel puede refinarse en iteraciones posteriores de la evaluación del riesgo. Se debe identificar al propietario de un activo para cada activo, para determinar las disposiciones sobre responsabilidad y rendición de cuentas por el activo. El propietario del activo puede no tener derechos de propiedad sobre el activo, pero tiene responsabilidad sobre su producción, desarrollo, mantenimiento, uso y seguridad, según corresponda. El propietario del activo a menudo es la persona más apropiada para determinar el valor que el activo tiene para la organización (véase la valorización de activos en el apartado 8.2.2). El límite de revisión es el perímetro de activos de la organización que el proceso de gestión del riesgo en seguridad de la información debe administrar según definición. El Anexo B contiene más información sobre la identificación y valorización de activos relacionados con la seguridad de la información.



Producto: Una lista de activos a administrarse respecto de su riesgo y una lista de procesos de negocio relativos a activos y su relevancia.

8.2.1.3

Identificación de amenazas

Insumo: Información sobre amenazas obtenida a partir de la revisión de incidentes, propietarios de activos, usuarios y otras fuentes, incluyendo catálogos externos de amenazas. Acción: Se debe identificar las amenazas y sus fuentes (relativas a la norma ISO/IEC 27001, apartado 4.2.1 d) 2)). Guía de implementación: Una amenaza tiene el potencial de dañar activos como la información, los procesos y los sistemas y, por tanto, las organizaciones. Las amenazas pueden ser de origen natural o humano y pueden ser accidentales o deliberadas. Deben identificarse tanto las fuentes de amenazas accidentales como las deliberadas. Una amenaza puede surgir desde adentro o desde afuera de la organización. Se debe identificar las amenazas de manera genérica y por tipo (por ejemplo acciones no autorizadas, daño físico, fallas técnicas) y entonces cuando sea apropiado, las amenazas individuales dentro de la clase genérica identificada. Esto significa que no se desatiende ninguna amenaza, incluyendo las inesperadas, pero que el volumen de trabajo requerido es limitado. Algunas amenazas pueden afectar a más de un activo. En dichos casos, pueden causar distintos impactos dependiendo de qué activos sean afectados. Se puede obtener insumos respecto de la identificación de la amenaza y de la estimación de la posibilidad de ocurrencia (véase el apartado 8.2.2.3) que hacen los propietarios o usuarios de activos, del personal de recursos humanos, de la gerencia de planta y de los especialistas en seguridad de la información, expertos de seguridad física, departamento legal y otras organizaciones, incluyendo organismos legales, autoridades meteorológicas, compañías de seguros y autoridades del gobierno nacional. Se debe considerar aspectos de medioambiente y cultura cuando se enfrentan amenazas.



Se debe considerar la experiencia interna de incidentes y las evaluaciones de amenazas pasadas en la evaluación actual. Puede valer la pena consultar otros catálogos de amenazas (quizás específicos a una organización o empresa) para completar la lista de amenazas genéricas, cuando sea relevante. Se dispone de catálogos y estadísticas de amenazas en gremios industriales, gobiernos nacionales, organismos legales, compañías de seguros, etc. Cuando se usa catálogos de amenazas o evaluaciones de los resultados de amenazas pasadas, debemos ser conscientes de que hay un cambio continuo en las amenazas relevantes, especialmente si el entorno empresarial o los sistemas de información cambian. El Anexo C presenta más información sobre tipos de amenazas. Producto: Una lista de amenazas con la identificación del tipo y fuente de la amenaza.

8.2.1.4

Identificación de controles existentes

Insumo: Documentación de controles, planes de implementación de tratamiento de riesgos. Acción: Se debe identificar los controles existentes y planificados. Guía de implementación: Se debe identificar los controles existentes para evitar trabajo o costo innecesarios, por ejemplo en la duplicación de controles. Además, a la vez que se identifican los controles existentes, se debe hacer una verificación para asegurar que los controles están funcionando correctamente –una referencia a los informes de auditoría ya existentes sobre el ISMS limita el tiempo que se emplea en esta tarea. Si un control no funciona como se esperaba, esto puede causar vulnerabilidades. Se debe considerar la situación en la que un control (o estrategia) seleccionado falle y, por lo tanto se requieran controles complementarios para tratar de manera eficaz el riesgo identificado. En un ISMS, de acuerdo con ISO/IEC 27001, esto se logra gracias a la medición de la eficacia de los controles. Una manera de estimar el efecto del control es ver cómo reduce la posibilidad de amenaza y la facilidad de explotación de la vulnerabilidad o impacto del incidente. Las revisiones de la gerencia y los informes de auditoría también proporcionan información sobre la eficacia de los controles existentes.



Se debe considerar los controles que se ha planificado implementar de acuerdo con los planes de implementación de tratamiento de riesgo de la misma manera que aquellos que ya se implementaron. Un control existente y planificado puede identificarse como ineficaz, o no suficiente, o no justificado. Si no es justificado ni suficiente, se debe verificar el control para determinar si se le debe eliminar, si se le debe reemplazar por otro control más adecuado o si debería continuarse con el mismo, por ejemplo, por razones de costos. Las siguientes actividades pueden ser útiles para la identificación de controles existentes o planeados: -

Revisión de documentos que tienen información sobre los controles (por ejemplo, planes de implementación de tratamiento del riesgo). Si los procesos de gestión de seguridad de la información están bien documentados, se debe disponer de todos los controles existentes o planeados y de su situación de implementación;

-

Verificación de la seguridad de la información con las personas responsables (por ejemplo el funcionario encargado de la seguridad de la información y el funcionario encargado de la seguridad del sistema de información, el gerente de construcción o el gerente de operaciones) y los usuarios respecto de qué controles se implementan realmente para el proceso de información o el sistema de información que se está considerando;

-

Conducción de una revisión in-situ de los controles físicos, comparando los implementados con la lista de qué controles debería tenerse y verificando los implementados respecto de si están funcionando de manera correcta y eficaz, o

-

Revisión de resultados de auditorías internas.

Producto: Una lista de todos los controles existentes y planeados, su implementación y su condición de uso.

8.2.1.5

Identificación de vulnerabilidades

Insumo: Una lista de amenazas conocidas, listas de activos y controles existentes.



Acción: Se debe identificar las vulnerabilidades que las amenazas pueden explotar para causar daño a los activos o a la organización (se relaciona con la norma ISO/IEC 27001, apartado 4.2.1 d) 3)). Guía de implementación: Se puede identificar vulnerabilidades en las áreas siguientes: -

Organización Procesos y procedimientos Rutinas administrativas Personal Entorno físico Configuración del sistema de información Hardware, software o equipo de comunicaciones Dependencia de partes externas

La presencia de una vulnerabilidad no causa daño en sí misma, ya que se requiere una amenaza para explotarla. Una vulnerabilidad que no tiene amenaza correspondiente puede no requerir la implementación de un control, pero se debería reconocer y monitorear para observar sus cambios. Debe notarse que un control implementado de manera incorrecta o que funcione mal puede ser en sí mismo una vulnerabilidad. Un control puede ser eficaz o ineficaz dependiendo del entorno en el que opera. Inversamente, Inversamente, una amenaza que no tiene una vulnerabilidad correspondiente correspondiente puede puede no resultar en un riesgo. riesgo. Las vulnerabilidades se pueden relacionar con propiedades del activo que se pueden utilizar de una manera o por un propósito que el que se desea cuando se compró o hizo el activo. Se tienen que considerar vulnerabilidades que surgen de distintas fuentes, por ejemplo, las que son intrínsecas o extrínsecas al activo. En el Anexo D se puede encontrar ejemplos de vulnerabilidades y métodos para la evaluación de la vulnerabilidad. Producto: Una lista de vulnerabilidades en relación con los activos, amenazas y controles, una lista de vulnerabilidades que no se relaciona a ninguna amenaza identificada para su revisión.


8.2.1.6


Identificación de las consecuencias consecuencias

Insumo: Una lista de activos, una lista de procesos de negocios, y una lista de amenazas y vulnerabilidades donde sea apropiado en relación con los activos y su relevancia. Acción: Se debe identificar las consecuencias que pueden tener las pérdidas de confidencialidad, integridad y disponibilidad (véase la norma ISO/IEC 27001, apartado 4.2.1 d) 4)). Guía de implementación: Una consecuencia puede hacer perder eficacia, puede haber condiciones operativas adversas, lucro cesante, daño a la reputación, etc. Esta actividad identifica el daño o las consecuencias a la organización que un incidente podría causar. El escenario de un incidente es la descripción de una amenaza que explota una cierta vulnerabilidad o conjunto de vulnerabilidades en un incidente de vulnerabilidad de la información (véase la norma ISO/IEC 27002, Capítulo 13). El impacto de los escenarios del incidente debe determinarse considerando criterios de impacto definidos durante la actividad de determinación del contexto. Puede afectar a uno o más activos o a parte de un activo. De esta manera, los activos pueden tener valores asignados para su costo financiero y debido a las consecuencias para la empresa si se les daña o compromete. Las consecuencias pueden ser de naturaleza temporal o permanente como en el caso de la destrucción de un activo. NOTA: La norma ISO/IEC 27001 describe la ocurrencia de d e escenarios de incidentes como “fallas de seguridad”.

Las organizaciones deben identificar las consecuencias operativas de los escenarios de incidentes en términos de los siguientes elementos sin limitarse li mitarse a los mismos: -

Tiempo de investigación y reparación Tiempo (trabajo) perdido Oportunidad perdida Salud y seguridad física


-


Costo financiero de habilidades específicas para reparar el daño Reputación de la imagen y buen nombre

En B3, Evaluación de impacto, se puede encontrar detalles sobre la evaluación de vulnerabilidades técnicas. Producto: Una lista de escenarios de incidentes con sus consecuencias relacionadas a los activos y procesos de negocios.

8.2.2

Estimación del riesgo

8.2.2.1

Metodologías para la estimación del riesgo

Se debe realizar el análisis del riesgo en grados variables de detalle dependiendo del carácter crucial de los activos, extensión de las vulnerabilidades conocidas e incidentes previos que involucran a la organización. Una metodología de estimación puede ser cualitativa o cuantitativa o una combinación de ambas dependiendo de las circunstancias. En la práctica, práctica, se usa a menudo la estimación cualitativa cualitativa para obtener primero una indicación general del nivel de riesgo y para revelar los riesgos más importantes. Luego puede ser necesario realizar análisis más específicos o cuantitativos sobre los riesgos ri esgos más importantes porque a menudo es menos complejo y menos caro realizar análisis cualitativos que análisis cuantitativos. La forma del análisis debe ser consistente con los criterios de evaluación del riesgo desarrollados como parte de la determinación del contexto. A continuación se describe los detalles de las metodologías de estimación: (a) Estimación cualitativa: La estimación cualitativa usa una escala de atributos calificadores para describir la magnitud de las consecuencias potenciales potenciales (por ejemplo, baja, media y alta) y la posibilidad de que esas consecuencias ocurran. Una ventaja de la estimación cualitativa es su facilidad de comprensión por todo el personal relevante, mientras que una ventaja es la dependencia en una elección subjetiva de la escala.



Estas escalas pueden adaptarse o ajustarse para acomodarse a las circunstancias y se puede usar distintas descripciones para distintos riesgos. Se puede usar estimación cualitativa: -

Como una actividad de clasificación inicial para identificar los riesgos que requieran un análisis más detallado.

-

Donde este tipo de análisis sea apropiado para las decisiones.

-

Donde los datos numéricos o los recursos sean inadecuados para una estimación cuantitativa

El análisis cualitativo debe usar información fáctica y datos siempre que estén disponibles. (b) Estimación cuantitativa La estimación cuantitativa usa una escala con valores numéricos (más que escalas descriptivas que se utilizan en la estimación cualitativa) para las consecuencias y la posibilidad, utilizando datos de una variedad de fuentes. La calidad del análisis depende de la exactitud y completitud de los valores numéricos y de la validez de los modelos utilizados. En la mayoría de los casos la estimación cuantitativa usa datos de incidentes históricos, proveyendo la ventaja de que se puede relacionar directamente a los objetivos de seguridad de la información y a las preocupaciones de la organización. Una desventaja es la falta de dichos datos sobre nuevos riesgos o sobre las debilidades en la seguridad de la información, Una desventaja del enfoque cuantitativo puede ocurrir donde no se disponga de datos auditables, creando así una ilusión de valor y exactitud de la evaluación del riesgo. La manera en la que se expresan las consecuencias y la posibilidad y las maneras en las que se combinan para proporcionar un nivel de riesgo variarán de acuerdo al tipo de riesgo y al propósito para el cual se debe utilizar el producto de la evaluación del riesgo. Se debe considerar la incertidumbre y variabilidad de varias consecuencias y probabilidad en el análisis y comunicarse de manera eficaz.


8.2.2.2


Evaluación de consecuencias

Insumo: Una lista identificada de escenarios de incidentes relevantes que incluya la identificación de amenazas, vulnerabilidades, activos aceptados, consecuencias a los activos y procesos de negocio. Acción: Se debe evaluar el impacto empresarial sobre la organización que podría resultar de incidentes posibles o reales en torno a la seguridad de la información, tomando en cuenta las consecuencias de una infracción en la seguridad de la información tal como la pérdida de confidencialidad, integridad o disponibilidad de los activos (se relaciona con ISO/IEC 27001, Capítulo 4.2.1 e) 1)). Guía de implementación Luego de identificar todos los activos que se están revisando, se debe tomar en cuenta los valores asignados a estos activos a la vez que se evalúan las consecuencias. El valor de impacto sobre el negocio puede expresarse en formas cualitativas y cuantitativas, pero cualquier método de asignar valor monetario puede proveer generalmente más información para la toma de decisiones y por tanto facilitar un proceso de toma de decisiones más eficiente. La valorización de activos comienza con la clasificación de activos de acuerdo con su carácter crucial en términos de la importancia de los activos para satisfacer los objetivos de negocio de la organización. Entonces se determina el valor utilizando dos medidas: -

El valor de reemplazo del activo: el costo de una limpieza, de la recuperación y de reemplazar la información (si es posible), y

-

Las consecuencias para el negocio por pérdida o compromiso del activo, como consecuencias potenciales adversas para el negocio y/o legales o regulatorias debido a la divulgación, modificación, no-disponibilidad y/o destrucción de información, y otros activos de información.



Esta valorización se puede determinar desde el análisis de impacto en el negocio. El valor, determinado por la consecuencia para el negocio, es usualmente significativamente más alto que el simple costo de reemplazo, dependiendo de la importancia que tiene el activo para que la organización logre sus objetivos de negocio. La valorización del activo es un factor clave en la evaluación de impacto de un escenario de incidentes porque el incidente puede afectar a más de un activo (por ejemplo activos dependientes) o solamente a una parte de un activo. Las distintas amenazas y vulnerabilidades tendrán diferentes impactos en los activos, como una pérdida de confidencialidad, integridad o disponibilidad. La evaluación de consecuencias se relaciona entonces a la valorización de los activos en base al análisis de impacto sobre el negocio. Las consecuencias o el impacto sobre el negocio pueden determinarse modelando los resultados de un evento o conjunto de eventos o extrapolándolos de estudios experimentales o datos pasados. Se puede expresar las consecuencias en términos de criterios monetarios, técnicos o humanos u otros criterios relevantes a la organización. En algunos casos se requiere más de un valor numérico para especificar las consecuencias de distintos momentos, lugares, grupos o situaciones. Las consecuencias en el tiempo y las finanzas deben medirse con el mismo enfoque que se utiliza para la posibilidad de amenazas y la vulnerabilidad. Se tiene que mantener la consistencia sobre el enfoque cuantitativo o cualitativo. En el Anexo B se puede encontrar mayor información sobre la valorización de los activos y la evaluación de impacto. Producto: Una lista de consecuencias evaluadas de un escenario de incidentes expresada con respecto a los activos y a criterios de impacto.

8.2.2.3

Evaluación de la posibilidad de incidentes

Insumos: Una lista identificada de escenarios de incidentes relevantes, incluyendo la identificación de amenazas, los activos afectados, las vulnerabilidades explotadas y las consecuencias para los activos y los procesos del negocio. Además, listas de todos los controles existentes y planeados, su eficacia, implementación y condición de uso.



Acción: La posibilidad de los escenarios de incidentes debe evaluarse (se relaciona con la norma ISO/IEC 27001, apartado 4.2.1 e) 2)). Guía de implementación Luego de identificar los escenarios de incidentes, es necesario evaluar la posibilidad de que ocurra cada escenario e impacto utilizando técnicas de estimación cualitativa y cuantitativa. Esto debe tomar en cuenta cuán a menudo ocurren las amenazas y con qué facilidad se puede explotar las vulnerabilidades, considerando: -

la experiencia y las estadísticas aplicables para la posibilidad de amenazas.

-

para fuentes de amenazas deliberadas: la motivación y capacidades que cambiarán en el tiempo y los recursos disponibles a los posibles atacantes, así como la percepción de la atracción y la vulnerabilidad de los activos para un posible atacante.

-

para fuentes de amenazas accidentales: factores geográficos, por ejemplo proximidad a plantas químicas o petroleras, la posibilidad de condiciones climáticas extremas y factores que podrían influenciar los errores humanos y el malfuncionamiento de los equipos.

-

vulnerabilidades, tanto individualmente como de manera agregada.

-

controles existentes y cuán eficazmente reducen las vulnerabilidades.

Por ejemplo, un sistema de información puede tener una vulnerabilidad a las amenazas de suplantación de identidad de usuario y mal uso de recursos. La vulnerabilidad de suplantación de identidad de usuario puede ser alta debido a la falta de autentificación de usuario. Por otro lado, la posibilidad de un mal uso de recursos puede ser alta a pesar de la falta de autentificación de usuario porque las guías para utilizar mal los recursos son limitadas. Dependiendo de la necesidad de exactitud, los activos se pueden agrupar, o puede ser necesario dividir los activos en sus elementos y relacionar los escenarios a los elementos. Por ejemplo, a través de sitios geográficos la naturaleza de las amenazas a los mismos tipos de activos puede cambiar o puede variar la eficacia de los controles existentes.



Producto: Posibilidad de escenarios de incidentes (cuantitativos o cualitativos).

8.2.2.4

Nivel de estimación del riesgo

Insumos: Una lista de escenarios de incidentes con sus consecuencias relacionadas a activos y procesos del negocio y su posibilidad (cuantitativa o cualitativa). Acción: El nivel de riesgo debe estimarse para todos los escenarios de incidentes relevantes (se relaciona con la norma ISO/IEC 27001, apartado 4.2.1 e) 4)). Guía de implementación: La estimación del riesgo asigna valores a la posibilidad y a las consecuencias de un riesgo. Estos valores pueden ser cualitativos o cuantitativos. La estimación del riesgo se basa en las consecuencias evaluadas y en su posibilidad. Adicionalmente, puede considerar el beneficio del costo, las preocupaciones de los intereses y otras variables, según sea apropiado para la evaluación del riesgo. El riesgo estimado es una combinación de la posibilidad de un escenario de incidentes y sus consecuencias. En el Anexo E se pueden encontrar ejemplos de distintos métodos o enfoques de estimación del riesgo en seguridad de la información. Producto: Una lista de riesgos con niveles asignados de valor.

8.3

Evaluación del riesgo

Insumo: Una lista de riesgos con niveles asignados de valor y criterios de evaluación del riesgo. Acción: El nivel de riesgo debe compararse contra los criterios de evaluación del riesgo y los criterios de aceptación del riesgo (se relaciona con la norma ISO/IEC 27001, apartado 4.2.1 e) 4)).



Guía de implementación: La naturaleza de las decisiones que corresponden a la evaluación del riesgo y a los criterios de evaluación del riesgo que se utilizarán para tomar esas decisiones se decidirán cuando se establezca el contexto. Estas decisiones y el contexto deben volverse a revisar en más detalle en esta etapa cuando se sabe más sobre los riesgos particulares identificados. Para evaluar los riesgos, las organizaciones deben comparar los riesgos estimados (utilizando métodos o enfoques de selección tal como se menciona en el Anexo E) con los criterios de evaluación del riesgo definidos durante la determinación del contexto. Los criterios de evaluación del riesgo utilizados para tomar la decisión deben ser consistentes con el contexto de gestión del riesgo en seguridad de la información definido externa e internamente y se debe tomar en cuenta los objetivos de la organización y el punto de vista de los interesados, etc. Las decisiones que se toman en la actividad de evaluación del riesgo se basan principalmente en el nivel de riesgo aceptable. Sin embargo, también se debe considerar las consecuencias, posibilidad y grado de confianza en el riesgo, identificación y análisis. La agregación de múltiples riesgos bajos o medios pueden resultar en riesgos generales mucho más altos que requieren tratarse de manera correspondiente. Las consideraciones deben incluir: -

Propiedades de la seguridad de la información:

si un criterio no es relevante para la organización (por ejemplo pérdida de confidencialidad), entonces todos los riesgos que impactan a este criterio pueden no ser relevantes.

-

La importancia del proceso de negocio o actividad apoyada por un activo particular o conjunto de activos: si se determina que el proceso es de baja

importancia, los riesgos asociados con él deben recibir una consideración más baja que los riesgos que impactan a procesos o actividades más importantes. La evaluación del riesgo utiliza la comprensión del riesgo obtenida por el análisis del riesgo para tomar decisiones sobre acciones futuras. Las decisiones deben incluir: -

Si una actividad debe realizarse. Las prioridades para el tratamiento del riesgo considerando niveles estimados de riesgos.



Durante la etapa de evaluación del riesgo, los requisitos contractuales legales y regulatorios son factores que deben tomarse en cuenta además de los riesgos estimados. Producto: Una lista de riesgos priorizada de acuerdo con los criterios de evaluación del riesgo en relación con los escenarios de incidentes que llevan a esos riesgos.

9. TRATAMIENTO INFORMACIÓN 9.1

DEL

RIESGO

EN

SEGURIDAD

DE

LA

Descripción general del tratamiento del riesgo

Insumo: Una lista de riesgos priorizada de acuerdo con criterios de evaluación del riesgo en relación con los escenarios de incidentes que llevan a esos riesgos. Acción: Se debe seleccionar controles para reducir, retener, evitar o transferir los riesgos y un plan del tratamiento del riesgo definido. Guía de implementación Existen cuatro opciones disponibles para el tratamiento del riesgo: reducción del riesgo (véase el apartado 9.2), retención del riesgo (véase el apartado 9.3), evitamiento del riesgo (véase el apartado 9.4) y transferencia del riesgo (véase el apartado 9.5). NOTA: La norma ISO/IEC 27001 4.2.1,f) 2) usa el término “aceptar el riesgo” en vez de “retener el riesgo”.

La Figura 2 ilustra la actividad de tratamiento del riesgo dentro del proceso de gestión del riesgo en seguridad de la información tal como se presenta en la Figura 1.



RESULTADOS DE LA EVALUACION DEL RIESGO

EVALUACION SATISFACTORIA

Decisión sobre el riesgo punto 1 Tratamiento del riesgo OPCIONES DE TRATAMIENTO DEL RIESGO

REDUCCION

RETENCION

DEL RIESGO

DEL RIESGO

EVITAMIENTO TRANSFERENCIA DEL RIESGO

DEL RIESGO

RIESGOS RESIDUALES

TRATAMIENTO

Decisión sobre el riesgo punto 2

SATISFACTORIO

FIGURA 2 – Actividad de tratamiento del riesgo



Las opciones de tratamiento del riesgo deben seleccionarse en base al resultado de la evaluación del riesgo, el costo esperado de implementar esas opciones y el beneficio esperado de esas opciones. Cuando se puede obtener grandes reducciones en el riesgo con un gasto relativamente bajo, dichas opciones deben implementarse. Las opciones adicionales para mejoras pueden ser no económicas y se tiene que utilizar el criterio para decidir si son justificables. En general, las consecuencias adversas de los riesgos deben hacerse tan bajas como sea practicable razonablemente y sin importar criterios absolutos. Los gerentes deben considerar los riesgos poco frecuentes pero graves. En dichos casos, es posible que se tenga que implementar controles que no son justificables desde el punto de vista estrictamente económico (por ejemplo, controles a la continuidad del negocio considerados para cubrir riesgos altos específicos). Las cuatros opciones para el tratamiento del riesgo no se excluyen mutuamente. A veces la organización puede beneficiarse sustancialmente por una combinación de opciones como la reducción de la posibilidad de riesgos, la reducción de sus consecuencias, y la transferencia o retención de cualquier riesgo residual. Algunos tratamientos del riesgo pueden enfrentar eficazmente más de un riesgo (por ejemplo, la capacitación y concientización en seguridad de la información). Debe definirse un plan de tratamiento del riesgo que identifique claramente la prioridad ordenando en cuáles tratamientos del riesgo individual debe implementarse y su horizonte temporal. Se puede establecer prioridades utilizando varias técnicas, incluyendo puntajes de riesgo y análisis costo-beneficio. Es responsabilidad de los gerentes de la organización el decidir el equilibrio entre los costos de implementar controles y la asignación presupuestal. La identificación de controles existentes puede determinar que los controles existentes excedan las necesidades corrientes en términos de comparaciones de costos, incluyendo el mantenimiento. Si se considera eliminar los controles redundantes e innecesarios (especialmente si los controles tienen altos costos de mantenimiento), debe tomarse en cuenta la seguridad de la información y los factores del costo. Debido a que los controles pueden influenciar unos a otros, la eliminación de los controles redundantes puede reducir la seguridad general que existe. Además, puede ser más barato dejar en funcionamiento controles redundantes o innecesarios que eliminarlos.



Se debe considerar las opciones de tratamiento del riesgo tomando en cuenta: -

Cómo las partes afectadas perciben el riesgo.

-

Las maneras más apropiadas de comunicarse con esas partes.

El establecimiento del contexto (véase el apartado 7.2 – Criterios de valorización del riesgo) provee información sobre requisitos legales y regulatorios sobre los cuales la organización debe cumplir. El riesgo para las organizaciones es el no cumplimiento y deben implementarse las opciones de tratamiento para limitar esta posibilidad. Todas las restricciones –organizativas, técnicas, estructurales, etc. – que se identifiquen durante la actividad de determinación del contexto deben tomarse en cuenta durante el tratamiento del riesgo. Una vez que el plan de tratamiento del riesgo se ha definido, se tiene que determinar los riesgos residuales. Esto incluye una actualización o reiteración de la evaluación del riesgo, tomando en cuenta los efectos esperados del tratamiento propuesto del riesgo. Si el riesgo residual todavía no cumple con los criterios de aceptación del riesgo de la organización, puede ser necesaria una nueva iteración del tratamiento del riesgo antes de proceder a la aceptación del riesgo. Se puede encontrar más información en la norma ISO/IEC 27002, Capítulo 0.3. Producto: Plan de tratamiento del riesgo y riesgos residuales sujetos a la decisión de aceptación por parte de los gerentes de la organización.

9.2

Reducción del riesgo

Acción: El nivel de riesgo debe reducirse a través de la selección de controles de tal modo que el riesgo residual se pueda re-evaluar como aceptable.



Guía de implementación Se debe seleccionar controles apropiados y justificados para cumplir con los requisitos identificados por la evaluación y el tratamiento del riesgo. Esta selección debe tomar en cuenta los criterios de aceptación del riesgo así como los requisitos legales regulatorios y contractuales Esta selección también debe tomar en cuenta el costo y el horizonte temporal para la implementación de controle sobre los aspectos técnicos, ambientales y culturales. A menudo es posible reducir el costo total de la propiedad de un sistema con controles de seguridad de la información seleccionados apropiadamente. En general, los controles pueden proporcionar uno o más de los siguientes tipos de protección: corrección, eliminación, prevención, minimización del impacto, disuasión, recuperación, monitoreo y conciencia. Durante la selección del control es importante contrapesar el costo de adquisición, implementación, administración, operación, monitoreo y mantenimiento de los controles contra el valor de los activos que se están protegiendo. Además, se debe considerar el retorno sobre la inversión en términos de reducción del riesgo y del potencial de explotar nuevas oportunidades de negocio que los controles permitan. Adicionalmente, se debe considerar las habilidades especializadas que se pueden requerir para definir e implementar nuevos controles o modificar los existentes. La norma ISO/IEC 27002 provee información detallada sobre controles. Existen muchas restricciones que pueden afectar la selección de controles. Las restricciones técnicas como los requisitos de desempeño, administrabilidad, requisitos de apoyo operativo y cuestiones de compatibilidad pueden obstaculizar el uso de ciertos controles o inducir a error humano ya sea anulando el control, dando una falsa sensación de seguridad o incluso incrementando el riesgo más allá del control. Por ejemplo, el requerir claves complejas sin capacitación adecuada lleva a los usuarios a escribir las claves. Más aún, podría ser el caso que un control afecte el desempeño. Los gerentes deben tratar de identificar una solución que satisfaga los requisitos de desempeño y a la vez garantice suficiente seguridad de la información. El resultado de este paso es una lista de controles posible con su costo, beneficio y prioridad de implementación. Se debe tomar en cuenta varias restricciones cuando se selecciona controles y durante la implementación. Normalmente se consideran los siguientes: -

Restricciones de tiempo.



-

Restricciones financieras.

-

Restricciones técnicas.

-

Restricciones operativas.

-

Restricciones culturales.

-

Restricciones éticas.

-

Restricciones ambientales.

-

Restricciones legales.

-

Facilidad de uso.

-

Restricciones personales.

-

Restricciones para integrar controles nuevos y existentes,

En el Anexo F se puede encontrar más información sobre las restricciones a la reducción del riesgo.

9.3

Retención del riesgo

Acción: La decisión de retener el riesgo sin acciones ulteriores debe tomarse dependiendo de la evaluación del riesgo. NOTA: La norma ISO/IEC 27001, apartado 4.2.1 f) 2) “aceptar riesgos a sabiendas y de manera objetiva siempre y cuando cumplan claramente las políticas de la organización y los criterios para la aceptación de riesgos” describe la misma actividad.

Guía de implementación: Si el nivel de riesgo satisface los criterios de aceptación del riesgo no es necesario implementar controles adicionales y se puede retener el riesgo.


9.4


Evitamiento del riesgo

Acción: Se debe evitar la actividad o condición que ocasiona el riesgo particular. Guía de implementación: Cuando los riesgos identificados se consideran demasiado altos o los costos de implementar otras opciones de tratamiento del riesgo exceden los beneficios, se puede tomar la decisión de evitar el riesgo completamente, retirándose de una actividad o conjunto de actividades planeadas o existentes, o cambiando las condiciones bajo las cuales se opera la actividad. Por ejemplo, para riesgos causados por la naturaleza puede ser una alternativa más económica mudar las instalaciones de procesamiento de la información a un lugar donde el riesgo no exista o este bajo control.

9.5

Transferencia del riesgo

Acción: El riesgo debe transferirse a otra parte que pueda administrar más eficazmente el riesgo particular dependiendo de la evaluación del riesgo. Guía de implementación: La transferencia del riesgo involucra una decisión de compartir ciertos riesgos con partes externas. La transferencia del riesgo puede crear nuevos riesgos o modificar los riesgos existentes identificados. Por lo tanto, puede ser necesario el tratamiento adicional del riesgo. Se puede hacer la transferencia por medio de un seguro que soporte las consecuencias o subcontratando a un socio cuyo rol será monitorear el sistema de información y tomar acciones inmediatas para evitar un ataque antes de que logre un nivel de daño definido. Se debe notar que puede ser posible transferir la responsabilidad de administrar el riesgo, pero normalmente no es posible transferir los pasivos de un impacto. Los clientes atribuirán usualmente un impacto adverso a una falta de la organización


10. ACEPTACIÓN INFORMACIÓN


DEL

RIESGO

EN

SEGURIDAD

DE

LA

Insumo: El plan de tratamiento del riesgo y la evaluación del riesgo residual están sujetos a la decisión de aceptación de los gerentes de la organización. Acción: Debe tomarse y registrarse de manera formal la decisión de aceptar los riesgos y responsabilidades por esa decisión (esto se relaciona con la norma ISO/IEC 27001 apartado 4.2.1 h)). Guía de implementación: Los planes de tratamiento del riesgo deben describir cómo se deben tratar los riesgos evaluados para satisfacer los criterios de aceptación del riesgo (véase el apartado 7.2 – Criterios de aceptación del riesgo). Es importante que los gerentes responsables revisen y aprueben los planes de tratamiento del riesgo propuestos y los riesgos residuales resultantes y registrar cualquier condición que se asocie con dicha aprobación. Los criterios de aceptación del riesgo pueden ser más complejos que simplemente determinar si un riesgo residual cae o no por encima o por debajo de un umbral específico. En algunos casos el nivel de riesgo residual puede no cumplir con los criterios de aceptación del riesgo porque los criterios que se están aplicando no toman en cuenta las circunstancias prevalecientes. Por ejemplo, se puede argüir que es necesario aceptar riesgos debido a que los beneficios que acompañan a los riesgos son muy atractivos, o porque el costo de reducción del riesgo es demasiado alto. Dichas circunstancias indican que los criterios de aceptación del riesgo son inadecuados y se deberían revisar si fuera posible. Sin embargo, no siempre es posible revisar los criterios de aceptación del riesgo de manera oportuna. En dichos casos, quienes toman las decisiones pueden tener que aceptar los riesgos que no satisfacen los criterios de aceptación normal. Si esto es necesario, quien toma las decisiones debería comentar explícitamente los riesgos e incluir una justificación para que la decisión pueda pasar por encima de los criterios normales de aceptación del riesgo.



11. COMUNICACIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN Insumo: Toda la información del riesgo que se obtiene de las actividades de gestión del riesgo (véase la Figura 1). Acción: La información sobre el riesgo debe intercambiarse y/o compartirse entre quienes toman las decisiones y otros interesados. Guía de implementación: La comunicación del riesgo es una actividad para lograr acuerdos sobre cómo manejar los riesgos intercambiando y/o compartiendo información sobre el riesgo entre quienes toman las decisiones y otros interesados. La información incluye, pero no se limita a, la existencia, naturaleza, forma, posibilidad, gravedad, tratamiento y aceptabilidad de los riesgos. La comunicación eficaz entre los interesados es importante ya que esto puede tener un impacto significativo en las decisiones que se deben tomar. La comunicación asegurará que los responsables de implementar la gestión del riesgo y aquellos que tienen intereses particulares comprendan la base sobre la cual se toman las decisiones y las acciones particulares que se requieren. La comunicación es bi-direccional. Las percepciones del riesgo pueden variar debido a las diferencias en los supuestos, conceptos y a las necesidades, problemas y preocupaciones de los interesados según se relacionen ellos con el riesgo o los problemas en cuestión. Los interesados probablemente consideren la aceptabilidad del riesgo en base a su percepción del riesgo. Esto es especialmente importante para asegurar que las percepciones del riesgo de los interesados, así como sus percepciones de los beneficios se pueden identificar y documentar y las razones subyacentes se pueden entender y resolver de manera clara. Debe realizarse la comunicación sobre el riesgo de manera que se logre lo siguiente: Proporcionar aseguramiento del resultado de la gestión del riesgo de la organización.


-


Recolectar información sobre el riesgo.

Compartir los resultados de la evaluación del riesgo y presentar el plan de tratamiento del riesgo. Evitar o reducir la ocurrencia y consecuencia de las infracciones a la seguridad de la información debido a la falta de comprensión mutua entre quienes toman las decisiones y los interesados. -

Apoyar la toma de decisiones.

-

Obtener nuevo conocimiento sobre seguridad de la información.

Coordinar con otras partes y planificar las respuestas para reducir las consecuencias de cualquier incidente. Darle a los que toman las decisiones y a los interesados un sentido de responsabilidad sobre los riesgos. -

Mejorar la conciencia.

Una organización debe desarrollar planes de comunicación del riesgo para operaciones normales, así como para las situaciones de emergencia. Por lo tanto, la actividad de comunicación del riesgo debe realizarse de manera continua. La coordinación entre quienes toman las decisiones y los interesados más importantes debe lograrse por medio de la formulación de un comité donde se debata los riesgos, su priorización y su tratamiento apropiado y aceptación. Es importante cooperar con la unidad de relaciones públicas o comunicaciones concernida dentro de la organización para coordinar todas las tareas relacionadas con la comunicación del riesgo. Esto es crucial en el caso de acciones de comunicación de la crisis, por ejemplo en respuesta a incidentes particulares. Producto: La comprensión continua del proceso de gestión del riesgo en seguridad de la información de la organización y sus resultados.



12. MONITOREO Y REVISIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN 12.1

Monitoreo y revisión de factores del riesgo

Insumo: Toda la información sobre el riesgo que se obtiene a través de las actividades de gestión del riesgo (Véase la Figura 1). Acción: Se debe monitorear y revisar los riesgos y sus factores (es decir, valor de los activos, impactos, amenazas, vulnerabilidades, posibilidad de ocurrencia) para identificar cualquier cambio en el contexto de la información en una etapa temprana y para mantener una visión general de toda la imagen del riesgo. Guía de implementación Los riesgos no son estáticos. Las amenazas, vulnerabilidades, posibilidad o consecuencias pueden cambiar abruptamente sin ninguna indicación. Por lo tanto, es necesario el monitoreo constante para detectar estos cambios. Esto lo pueden apoyar servicios externos que provean información respecto a nuevas amenazas o vulnerabilidades. Las organizaciones deben asegurar que se monitoree continuamente lo siguiente: -

Nuevos activos que hayan sido incluidos en el alcance de la gestión del riesgo. La modificación necesaria de los valores de los activos, por ejemplo: debido a las necesidades cambiantes del negocio. Nuevas amenazas que podrían ser activas tanto fuera como dentro de la organización y que no se han evaluado. La posibilidad de que las vulnerabilidades nuevas o aumentadas permitan que haya amenazas que exploten estas vulnerabilidades nuevas o cambiadas. Vulnerabilidades identificadas para determinar las que se están exponiendo a amenazas nuevas o re-emergentes. El mayor impacto o las consecuencias de amenazas, vulnerabilidades y riesgos evaluados resultan en un nivel de riesgo inaceptable cuando se agregan. Incidentes de seguridad de la información.



Las nuevas amenazas, vulnerabilidades o cambios en las posibilidades o las consecuencias pueden incrementar los riesgos previamente evaluados como bajos. La revisión de riesgos bajos y aceptados debe considerar cada riesgo por separado y todos los riesgos como un agregado también para evaluar su impacto acumulado potencial. Si los riesgos no caen dentro de la categoría baja o aceptable, se les debe tratar utilizando una o más de las opciones consideradas en el Capítulo 9. Los factores que afectan las posibilidades y las consecuencias de que ocurran las amenazas pueden cambiar, así como pueden cambiar los factores que afectan la conveniencia o el costo de las distintas opciones de tratamiento. Los factores que afectan la posibilidad y consecuencias de las amenazas que ocurren pueden cambiar, como pueden hacerlo los factores que afectan la conveniencia o el costo de las distintas opciones de tratamiento. Los cambios importantes que afectan a la organización deben recibir una revisión más específica. Por lo tanto, las actividades de monitoreo del riesgo deben repetirse regularmente y las opciones seleccionadas para el tratamiento del riesgo deben revisarse periódicamente. El resultado de las actividades de monitoreo del riesgo pueden ser un insumo para otras actividades de revisión del riesgo. La organización debe revisar todos los riesgos de manera regular y cuando ocurren cambios importantes (de acuerdo con la norma ISO/IEC 27001, apartado 4.2.3)). Producto: El alineamiento continuo de la gestión del riesgo con los objetivos de negocio de la organización y con los criterios de aceptación del riesgo.

12.2

Monitoreo, revisión y mejoramiento de gestión del riesgo

Insumo: Toda la información sobre el riesgo que se obtiene de las actividades de gestión del riesgo (véase la figura 1). Acción: El proceso de gestión del riesgo en seguridad de la información debe monitorearse, revisarse y mejorarse continuamente según sea necesario y apropiado.



Guía de implementación: Se necesita monitoreo y revisión constante para asegurar que el contexto, el resultado de la evaluación y el tratamiento del riesgo, así como los planes de manejo sigan siendo relevantes y apropiados a las circunstancias. La organización debe asegurarse de que el proceso y gestión del riesgo de seguridad de la información y las actividades relacionadas sigan siendo apropiadas en las circunstancias presentes y se cumplan. Cualquier mejora acordada al proceso con las acciones necesarias para mejorar el cumplimiento con el proceso deben notificarse a los gerentes adecuados para asegurarse de que no se pase por alto o subestime ningún riesgo o elemento riesgoso y que se tomen acciones y decisiones necesarias para proveer una compresión realista del riesgo y para tener la capacidad de responder. Además, la organización debe verificar regularmente que los criterios utilizados para medir el riesgo y sus elementos siguen siendo válidos y consistentes con los objetivos, estrategias y políticas empresariales y que los cambios al contexto empresarial se toman en consideración de manera adecuada durante el proceso de gestión del riesgo en seguridad de la información. Esta actividad de monitoreo y revisión debe ocuparse de, aunque no limitarse a, lo siguiente:

− − − − − − − − −

Contexto legal y ambiental. Contexto competitivo. Enfoque de evaluación del riesgo. Valor y categorías del activo. Criterios de impacto. Criterios de evaluación del riesgo. Criterios de aceptación del riesgo. Costo total de propiedad. Recursos necesarios.

La organización debe asegurar que los recursos para la evaluación y el tratamiento del riesgo estén disponibles continuamente para revisar el riesgo, resolver amenazas o vulnerabilidades nuevas o modificadas, y para aconsejar a la gerencia de manera correspondiente.



El monitoreo de la gestión del riesgo puede resultar en la modificación o adición de enfoques, metodologías o herramientas utilizados dependiendo de: Cambios identificados. Integración de la evaluación del riesgo. Objetivo del proceso de gestión del riesgo en seguridad de la información (por ejemplo, continuidad del negocio, capacidad de recuperación ante los incidentes, cumplimiento). − Objetivo del proceso de gestión del riesgo en seguridad de la información (por ejemplo, organización, unidad empresarial, proceso de la información, implementación técnica, aplicación, conexión a la Internet). − − −

Producto: Relevancia continua del proceso de gestión del riesgo en seguridad de la información para los objetivos de negocio de la organización o la actualización del proceso.

13.

ANTECEDENTES

13.1.

ISO/IEC 27005: 2008

Information technology – Security techniques – Information security risk management



ANEXO A (INFORMATIVO)

DEFINICIÓN DEL ALCANCE Y LÍMITES DEL PROCESO DE GESTIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN A.1

Estudio de la organización

Evaluar la organización. El estudio de la organización nos recuerda los elementos característicos que definen la identidad de una organización. Esto tiene que ver con el propósito, negocio, misiones, valores y estrategias de esta organización. Se debe identificar estos elementos juntos con los que contribuyen a su desarrollo (por ejemplo, la subcontratación). La dificultad de esta actividad reside en comprender exactamente cómo está estructurada la organización. Identificar su estructura real proveerá una comprensión del papel e importancia de cada división en el logro de los objetivos de la organización. Por ejemplo, el hecho de que el gerente de seguridad de la información reporte a los altos gerentes en vez de a los gerentes de TI puede indicar la participación de la alta gerencia en la seguridad de la información.

El propósito principal de la organización. El propósito principal de una organización puede definirse como las razones por las que existe (su campo de actividad, sus segmentos de mercado, etc.). Su negocio. El negocio de la organización, definido por las técnicas y el know-how de sus empleados le permite lograr sus misiones. Es específico al campo de actividad de la organización y a menudo define su cultura.



Su misión. La organización logra su propósito cumpliendo con su misión. La misión, los servicios proporcionados y/o los productos manufacturados deben identificarse en relación con los usuarios finales. Sus valores. Los valores, los principios importantes o un código bien definido de conducta que se aplica al ejercicio de un negocio. Esto puede referirse al personal, a las relaciones con agentes externos (clientes, etc.), a la calidad de productos suministrados o servicios proporcionados. Tomar el ejemplo de una organización cuyo propósito es el servicio público, cuyo negocio es el transporte y cuyas misiones incluyen el transporte de niños a y de la escuela. Sus valores pueden ser la puntualidad y la seguridad del servicio durante el transporte.

Estructura de la organización. Existen distintos tipos de estructura: Estructura por divisiones: Cada división se coloca bajo la autoridad de un gerente de división responsable por las decisiones estratégicas administrativas y operativas que conciernen a su unidad. Estructura funcional: Se ejerce autoridad funcional sobre los procedimientos, la naturaleza del trabajo y a veces las decisiones o el planeamiento (por ejemplo, producción, TI, recursos humanos, marketing, etc.) Comentarios: Una división dentro de una organización con estructura por divisiones puede organizarse como una estructura funcional y viceversa. Se puede decir que una organización tiene una estructura de matriz si tiene elementos de ambos tipos de estructura. En cualquier estructura organizativa se pueden distinguir los siguientes niveles: -

El nivel de toma de decisiones (definición de orientaciones estratégicas); El nivel de liderazgo (coordinación y gestión); El nivel operativo (actividades de producción y apoyo).



Organigrama. La estructura de la organización se representa esquemáticamente en un organigrama. Esta representación debe destacar las líneas jerárquicas y la delegación de autoridad, pero también debe incluir otras relaciones, las que incluso si no se basan en ninguna autoridad formal, son no obstante líneas de flujo de la información. La estrategia de la organización. Esto requiere una expresión formal de los principios guía de la organización. La estrategia de la organización determina la dirección y el desarrollo que se necesitan para beneficiarse de los temas en juego y de los cambios importantes que están planeandos.

A.2

Lista de restricciones que afectan a la organización

Deben tomarse en cuenta todas las restricciones que afectan a la organización y determinan su orientación en seguridad de la información. Su fuente puede estar dentro de la organización, en cuyo caso tiene cierto control sobre ella o fuera de la organización y, por lo tanto, generalmente no es negociable. Las restricciones a los recursos (presupuesto, personal) y las restricciones de emergencia están entre las más importantes. La organización fija sus objetivos (respecto de su negocio, comportamiento, etc.) comprometiéndose con un cierto camino, posiblemente en un período largo. Define lo que quiere ser y los medios que necesitará para implementarlo. Cuando se especifica este camino, la organización toma en cuenta los desarrollos, la técnica y el know-how, los deseos que los usuarios, los clientes, etc. han expresado. Este objetivo se puede expresar en la forma de estrategias operativas o de desarrollo con la finalidad, por ejemplo, de cortar costos operativos, mejorar la calidad del servicio, etc. Estas estrategias probablemente incluyen información y el sistema de información (SI) que ayuda en su aplicación. Consecuentemente, las características concernientes a la identidad, misión y estrategias de la organización son elementos fundamentales en el análisis del problema, ya que el incumplimiento de un aspecto de la seguridad de la información puede resultar en repensar estos objetivos estratégicos. Además, es esencial que las propuestas respecto de las necesidades de seguridad de la información sigan siendo consistentes con las reglas, usos y medios vigentes en la organización.



La lista de restricciones incluye pero no se limita a: Restricciones de naturaleza política Estas pueden referirse a administraciones gubernamentales, instituciones públicas o más generalmente a cualquier organización que tenga que aplicar decisiones gubernamentales. Normalmente son decisiones que conciernen a la orientación estratégica u operativa que una decisión gubernamental u órgano de toma de decisiones realiza y deben aplicarse. Por ejemplo, la computarización de facturas o documentos administrativos introduce problemas de seguridad de la información.

Restricciones de naturaleza estratégica Las restricciones pueden surgir de los cambios planeados o posibles a las estructuras u orientación de la organización. Se expresa en los planes estratégicos u operativos de la organización. Por ejemplo, la cooperación internacional al compartir información delicada puede necesitar acuerdos concernientes al intercambio seguro.

Restricciones territoriales La estructura y/o el propósito de la organización pueden introducir restricciones específicas como la distribución de sitios en todo el territorio nacional o en el extranjero. Los ejemplos incluyen servicios postales, embajadas, bancos, subsidiarias de grandes grupos industriales, etc.



Las restricciones surgen del clima económico y político La operación de una organización puede cambiar profundamente debido a eventos específicos como huelgas o crisis nacionales o internacionales. Por ejemplo, algunos servicios pueden ser capaces de continuar incluso a pesar de una seria crisis.

Restricciones estructurales La naturaleza de la estructura de una organización (por divisiones, funcional u otra) puede llevar a una política de seguridad de la información especifica y a la organización de seguridad adaptada a la estructura. Por ejemplo, una estructura internacional puede ser capaz de reconciliar las necesidades específicas de seguridad para cada país.

Restricciones funcionales Las restricciones funcionales surgen directamente de las misiones generales o especificas de la organización. Por ejemplo, una organización que opera 24 horas al día debe asegurar que sus recursos estén continuamente disponibles.

Restricciones respecto al personal La naturaleza de estas restricciones varía considerablemente. Están ligadas al nivel de responsabilidad, reclutamiento, calificación, capacitación, conciencia de la seguridad, motivación, disponibilidad, etc.



Por ejemplo, todo el personal de una organización de defensa debe tener autorización para manejar información altamente confidencial.

Restricciones que surgen del calendario de la organización Estas restricciones pueden resultar de la reestructuración o el establecimiento de políticas nacionales o internacionales nuevas que imponen ciertos plazos. Por ejemplo, la creación de una división de seguridad.

Restricciones relacionadas a métodos Los métodos apropiados al know-how de la organización tendrán que imponerse para aspectos como el planeamiento, especificaciones, desarrollo, etc. de proyectos. Por ejemplo, una restricción típica de este tipo es la necesidad de incorporar las obligaciones legales de la organización a la política de seguridad.

Restricciones de naturaleza cultural En algunas organizaciones los hábitos de trabajo o el negocio principal han llevado a una cultura específica dentro de la organización que puede ser incompatible con los controles de seguridad. Esta cultura es el marco de referencia general del personal y se puede determinar por muchos aspectos, incluyendo la educación, la instrucción, la experiencia personal, la experiencia fuera del trabajo, las opiniones, la filosofía, las creencias, el estatus social, etc. Restricciones presupuestales Los controles de seguridad recomendados a veces pueden tener un costo muy alto. Mientras que no siempre es apropiado basar las inversiones en seguridad en la economía, generalmente se refiere a justificación económica del departamento financiero de la organización.



Por ejemplo, en el sector privado y en algunas organizaciones públicas, el costo total de los controles de seguridad no debería exceder el costo de las consecuencias potenciales de los riesgos. La alta gerencia debería por tanto evaluar y tomar riesgos calculados si desea evitar excesivos costos de seguridad.

A.3 Lista de las referencias legislativas y regulatorias aplicables a la organización Se deben identificar los requisitos regulatorios aplicables a la organización. Estos pueden ser leyes, decretos, regulaciones específicas en el campo de la organización o regulaciones internas/externas. Esto también se refiere a contratos y acuerdos y más generalmente a cualquier obligación de naturaleza legal o regulatoria.

A.4

Lista de restricciones que afectan el alcance

Al identificar las restricciones, es posible listar aquéllas que tienen un impacto en el alcance y determinar cuáles están no obstante dispuestas para la acción. Se añaden a las restricciones de la organización que se han determinado anteriormente y posiblemente las reforman. Los párrafos siguientes presentan una lista no exhaustiva de tipos posibles de restricciones. Restricciones que surgen de procesos no existentes Los proyectos de aplicación no necesariamente se desarrollan simultáneamente. Algunos dependen de procesos preexistentes. A pesar de que un proceso se puede desglosar en subprocesos, el proceso no está necesariamente influenciado por todos los subprocesos de otro proceso. Restricciones técnicas Las restricciones técnicas relacionadas a la infraestructura surgen generalmente de hardware y software instalados y de las habitaciones o lugares que albergan los procesos:



Archivos (requisitos concernientes a la organización, la gestión de medios, la gestión de reglas de acceso, etc.) La arquitectura general (requisitos concernientes a la topología (centralizada, distribuida, cliente servidor), arquitectura física, etc.) Software de aplicación (requisitos concernientes al diseño específico del software, estándares del mercado, etc.); Software en paquetes (requisitos concernientes a los estándares, nivel de evaluación, calidad, cumplimiento con las normas, seguridad, etc.) Hardware (requisitos concernientes a los estándares, calidad, cumplimiento con las normas, etc.) Redes de comunicación (requisitos concernientes a la cobertura, estándares, capacidad, confiabilidad, etc.) Construcción de infraestructura (requisitos concernientes a la ingeniería civil, construcción, altos voltajes, bajos voltajes, etc.) Restricciones financieras El presupuesto restringe a menudo la implementación de controles de seguridad con los que la organización puede comprometerse. Sin embargo, la restricción financiera debe ser la última consideración ya que la asignación de presupuesto para seguridad puede negociarse sobre la base del estudio de seguridad. Restricciones ambientales Las restricciones ambientales surgen del entorno geográfico o económico en el que se implementan los procesos: país, clima, riesgos naturales, situación geográfica, clima económico, etc.



Restricciones temporales El tiempo requerido para implementar los controles de seguridad debe considerarse en relación con la capacidad de mejorar el sistema de información. Si el tiempo de implementación es muy largo, los riesgos para los que se diseña el control pueden haber cambiado. El tiempo es un factor determinante para seleccionar las soluciones y prioridades. Restricciones relacionadas a los métodos Se debe utilizar métodos apropiados para el know-how de la organización en el planeamiento de proyectos, las especificaciones, el desarrollo y otros. Restricciones organizativas Varias restricciones pueden deducirse de las necesidades organizativas: Operación (necesidades referidas a los tiempos de espera, suministro de servicios, vigilancia, monitoreo, planes de emergencia, operación degradada, etc.) Mantenimiento (requisitos referidos a la solución de incidentes, acciones preventivas, corrección rápida, etc.). Administración de recursos humanos (requisitos concernientes a la capacitación de operadores de usuarios, calificación para puestos como el de administrador de sistemas o administrador de datos, etc.). -

Gestión administrativa (requisitos concernientes a responsabilidades, etc.)

Gestión del desarrollo (requisitos concernientes a herramientas de desarrollo, ingeniería de software asistida por computadora, planes de aceptación, organización a establecerse, etc.) Manejo de relaciones externas (requisitos concernientes a la organización de relaciones con terceros, contratos, etc.)



ANEXO B (INFORMATIVO)

IDENTIFICACIÓN Y VALORIZACIÓN DE ACTIVOS Y EVALUACIÓN DE IMPACTO B.1

Ejemplos de identificación de activos

Para realizar una valorización de activos, una organización necesita primero identificar sus activos (a un nivel apropiado de detalle). Se puede distinguir dos tipos de activo: -

Los activos primarios: -

Procesos y actividades del negocio Información

Los activos de apoyo (sobre los cuales descansan los elementos primarios del alcance) de todo tipo: -

B.1.1

Hardware Software Red Personal Sitio Estructura de la organización

Identificación de activos primarios

Para describir el alcance de manera más exacta, esta actividad consiste en identificar los activos primarios (procesos y actividades del negocio, información). Esta identificación se realiza por medio de un grupo de trabajo mixto que representa el proceso (gerentes, especialistas en sistemas informáticos y usuarios).



Los activos primarios son usualmente los procesos e información centrales de la actividad en cuestión. Otros activos primarios como los procesos de la organización también pueden considerarse, lo cual será más apropiado para diseñar una política de seguridad de la información o un plan de continuidad del negocio. Dependiendo del propósito, algunos estudios no requerirán un análisis exhaustivo de todos los elementos que conforman el alcance. En dicho caso, los límites del estudio se pueden restringir a los elementos clave del alcance. Los activos primarios son de dos tipos: 1.

Procesos (o subprocesos) y actividades del negocio, por ejemplo: Procesos cuya pérdida o degradación hace imposible llevar a cabo la misión de la organización. Procesos que contienen procesos secretos o procesos que involucran tecnología propietaria Procesos que, si se modifican, pueden afectar grandemente el logro de la misión de la organización Procesos que son necesarios para que la organización cumpla con los requisitos contractuales, legales o regulatorios.

2.

Información:

De manera más general la información primaria comprende principalmente: Información vital para el ejercicio de la misión o los negocios de la organización. Información personal que se puede definir específicamente en el sentido de las leyes nacionales respecto a la privacidad. Información estratégica necesaria para lograr los objetivos determinados por las orientaciones estratégicas



Información de alto costo cuya recolección, almacenamiento, procesamiento y transmisión requieren tiempo largo y/o involucran un alto costo de adquisición. Los procesos y la información que no se identifican como sensibles no tendrán luego de esta actividad clasificación en el resto del estudio. Esto significa que incluso si dichos procesos o información se encuentran comprometidos, la organización seguirá cumpliendo con la misión exitosamente. Sin embargo, a menudo heredarán controles implementados para proteger los procesos y la información identificados como sensibles.

B.1.2

Lista y descripción de activos de apoyo

El alcance consiste de activos que deben identificarse y describirse. Estos activos tienen vulnerabilidades que son explotables por amenazas que tienen como objetivo desactivar los activos primarios del alcance (procesos e información). Son de varios tipos: Hardware El tipo de hardware consiste de todos los elementos físicos que apoyan procesos. Equipamiento de procesamiento de datos (activo) El equipamiento automático de procesamiento de la información incluye los artículos requeridos para operar independientemente. Equipo portátil Equipo de cómputo portátil. Ejemplos: computadora laptop, Asistente Digital Personal (PDA).



Equipo fijo Equipo de cómputo utilizado en los locales de la organización. Ejemplos: servidor, microcomputadora usada como estación de trabajo. Periféricos de procesamiento Equipo conectado a una computadora por medio de un puerto de comunicación (serial, enlace paralelo, etc.) para ingresar, llevar o transmitir datos. Ejemplos: impresora, disco removible. Medio de datos (pasivo) Estos son medios para almacenar datos o funciones. Medio electrónico Un medio de información que puede conectarse a una computadora o a una red de computadoras para el almacenamiento de datos. A pesar de su tamaño compacto, estos medios pueden contener una gran cantidad de datos. Se pueden usar con equipo de cómputo estándar. Ejemplos: disco floppy, CD Rom, cartucho de respaldo, disco duro removible, memoria USB, cinta. Otros medios Medios estáticos no electrónicos que contienen datos.



Ejemplos: papel, diapositiva, transparencia, documentación, fax. Software El software consiste de todos los programas que contribuyen con la operación de un conjunto de procesamiento de datos. Sistema operativo Esto incluye todos los programas de una computadora que constituye la base operativa desde la cual se corren todos los demás programas (servicios o aplicaciones). Incluye un kernel y funciones o servicios básicos. Dependiendo de la arquitectura, un sistema operativo puede ser monolítico o estar conformado de un microkernel y un conjunto de servicios del sistema. Los elementos principales del sistema operativo son todos los servicios de administración del equipo (CPU. memoria, disco e interfases de red), servicios de administración de tareas o procesos y servicios de manejo de derechos de usuario. Software de servicio, mantenimiento o administración Software caracterizado por el hecho de que complementa los servicios del sistema operativo y no está directamente al servicio de los usuarios o aplicaciones (aunque usualmente es esencial o incluso indispensable para la operación global del sistema de operación). Software en paquetes o software estándar El software estándar o el software en paquetes son productos completos que se comercializan como tales (en vez de uno en su clase o desarrollos específicos) con medio, versión y mantenimiento. Proporcionan servicios a los usuarios y aplicaciones pero no están personalizados o son específicos como son las aplicaciones de negocios. Ejemplos: software de administración de bases de datos, software de mensajería electrónica, groupware, software de directorios, software para servidores de web, etc.



Aplicación empresarial Aplicación empresarial estándar Este es software comercial diseñado para dar a los usuarios acceso directo a los servicios y funciones que requieren de su sistema de información en su contexto profesional. Existe un rango de campos muy amplio, teóricamente ilimitado. Ejemplo: software de cuentas, software de control metalmecánico, software de atención al cliente, software de administración de competencias personales, software administrativo, etc. Aplicación empresarial específica Este es software en el que varios aspectos (principalmente el soporte, el mantenimiento, las mejoras, etc.) se han desarrollado específicamente para darle a los usuarios acceso directo a los servicios y funciones que requieren de su sistema de información. Existe un rango de campos muy amplio, teóricamente ilimitado. Ejemplos: administración de facturas de clientes de operadores de telecomunicaciones, aplicación de monitoreo en tiempo real para el lanzamiento de cohetes. Red El tipo red consiste de todos los dispositivos de telecomunicaciones que se usan para interconectar varias computadoras físicamente remotas o elementos de un sistema de operación.



Medio y soporte Las comunicaciones y los medios o equipos de telecomunicaciones se caracterizan principalmente por las propiedades físicas y técnicas del equipo (punto a punto, transmisión) y por los protocolos de comunicación (enlace o red – niveles 2 y 3 de modelo de capas OSI7). Ejemplos: Red de Telefonía Pública Conmutada (PSTN), Ethernet , GigabitEthernet , Línea Digital Asimétrica de Suscriptor (ADSL), especificaciones de protocolos inalámbricos (por ejemplo WiFi 802.11), Bluetooth o Wirefire. Relé pasivo o activo Este sub-tipo incluye todos los dispositivos que no son las terminaciones lógicas de las comunicaciones (visión IS), sino que son dispositivos intermedios o relés. Los relés se caracterizan por los protocolos de comunicación de red soportados. Además del relé básico, a menudo incluye el ruteo y/o funciones y servicios de filtrado, empleando conmutadores de comunicación y ruteadores con filtro. A menudo se pueden administrar remotamente y son usualmente capaces de generar registros. Ejemplos: puente, ruteador, hub, conmutador, intercambio automático. Interfaz de comunicación Las interfaces de comunicación de las unidades de procesamiento se conectan a las unidades de procesamiento pero se caracterizan por los medios y los protocolos soportados, por cualquier filtrado instalado, registro o funciones de generación de advertencias y sus capacidades y por la posibilidad y el requisito de la administración remota. Ejemplos: Servicio General de Radio por Paquetes (GPRS), adaptador de Ethernet.



Personal El tipo personal consiste de todos los grupos de personas involucradas en el sistema informático. Responsable de tomar decisiones Los responsables de tomar decisiones son los propietarios de los activos primarios (información y funciones) y los administradores de la organización o del proyecto específico. Ejemplos: altos gerentes, líderes de proyectos. Usuarios Los usuarios son el personal que maneja elementos sensibles en el contexto de su actividad y que tienen una responsabilidad especial en este sentido. Pueden tener derechos especiales de acceso al sistema de información para realizar sus tareas cotidianas. Ejemplos: gerente de recursos humanos, gerente financiero, gerente de riesgos. Personal de operaciones y mantenimiento Este es el personal que está a cargo de operar y mantener el sistema de información. Tienen derechos especiales de acceso al sistema de información para realizar sus tareas cotidianas. Ejemplos: administrador del sistema, administrador de datos, respaldo, escritorio de ayuda, operador de despliegue de aplicaciones, funcionarios de seguridad.



Desarrolladores Los desarrolladores están a cargo de desarrollar las aplicaciones de la organización. Tienen acceso a parte del sistema de operación con derechos de alto nivel pero no toman ninguna acción sobre los datos de producción. Ejemplos: desarrolladores de aplicaciones empresariales. Sitio El tipo sitio comprende todos los lugares que contienen el alcance o parte del alcance y los medios físicos requeridos para que opere. Ubicación Entorno externo Esto concierne a todos los lugares en los que los medios de seguridad de la organización no se pueden aplicar. Ejemplos: lugares del personal, locales de otra organización, ambientes fuera del sitio (área urbana, área de peligro). Locales Este lugar está delimitado por el perímetro de la organización que se encuentra directamente en contacto con el exterior. Este puede ser un lindero protector físico obtenido por la creación de barreras físicas o medios de vigilancia alrededor de los edificios. Ejemplos: establecimientos, edificios.



Zona Una zona está formada por un lindero protector físico que forma divisiones dentro del local de una organización. Se obtiene creando barreras físicas alrededor de las infraestructuras de procesamiento de información de la organización. Ejemplos: oficinas, zona de acceso reservado, zona segura. Servicios esenciales Todos los servicios requeridos para que opere el equipo de la organización. Comunicación Los servicios de telecomunicaciones y equipamiento que provee un operador. Ejemplos: línea telefónica, PABX, redes de telefonía internas. Servicios públicos Servicios y medios (fuentes y cableado) requeridos para proveer energía al equipo de tecnología de la información y periféricos. Ejemplos: suministro de energía eléctrica de bajo voltaje, inversor, cabecera de cable de circuito eléctrico. Suministro de agua. Disposición de residuos. Servicios y medios (equipo, control) para enfriar y purificar el aire.



Ejemplos: tuberías de agua enfriadas, equipo de aire condicionado. Organización El tipo referente a organización describe el marco organizativo, consistente de todas las estructuras de personal asignadas a una tarea y los procedimientos que controlan estas estructuras. Autoridades Estas son organizaciones desde las cuales la institución estudiada deriva su autoridad. Pueden estar afiliadas legalmente o ser externas. Esto impone restricciones en la organización estudiada en términos de regulaciones, decisiones y acciones. Ejemplo: órgano administrativo, oficina central de una organización Estructura de la organización Esta consiste de las distintas sucursales de la organización, incluyendo sus actividades funcionales trasversales, bajo el control de su gerencia. Ejemplos: gerencia de recursos humanos, gerencia de TI, gerencia de adquisiciones, gerencia de la unidad de negocio, servicio de seguridad de edificios, servicio contra incendios, gerencia de auditorías. Organización de proyecto o sistema Esto se refiere a la acción que se establece para un proyecto o servicio específico.



Ejemplo: nueva aplicación de un proyecto de desarrollo, proyecto de migración del sistema de información. Subcontratistas / Proveedores / Practicantes Estas son organizaciones que proveen a la organización con un servicio o recursos y que están ligadas a ella por contrato. Ejemplos: compañía de administración de locales, compañía subcontratista, compañías consultoras.

B.2

Valorización de activos

El siguiente paso luego de la identificación del activo es acordar la escala que se debe utilizar y los criterios para asignar una ubicación particular en esa escala a cada activo en base a la valorización. Debido a la diversidad de activos que se encuentra en la mayor parte de organizaciones, probablemente algunos activos que tienen un valor monetario conocido se valorizarán en la unidad de moneda local, mientras que a otros que tienen un valor cualitativo puede asignárseles un rango de valor, por ejemplo desde “muy bajo” a “muy alto”. La decisión de usar una escala cuantitativa versus una escala cualitativa es en realidad cuestión de preferencia de la organización, pero debe ser relevante a los activos que se están valorizando. Ambos tipos de valorización podrían utilizarse para el mismo activo. Los términos típicos que se utilizan para la valorización cualitativa de activos incluyen palabras como insignificante, muy bajo, bajo, medio, alto, muy alto y crucial. La elección y rango de los términos convenientes a una organización depende fuertemente de la necesidad que tiene una organización de seguridad, del tamaño de la organización y de otros factores específicos a la organización.



Criterios Los criterios utilizados como base para asignar un valor a cada activo deben escribirse en términos claros. Este es a menudo uno de los aspectos más difíciles de la valorización de activos ya que los valores de algunos activos tendrán que determinarse subjetivamente y debido a que muchos individuos probablemente harán la determinación. Los criterios posibles a utilizar para determinar el valor de un activo incluyen su costo original, su costo de reemplazo y re-creación o su valor puede ser abstracto, por ejemplo el valor de la reputación de una organización. Otra base para la valorización de activos son los costos incurridos debido a la pérdida de confidencialidad, integridad y disponibilidad como resultado de un incidente. También se debe considerar como apropiados el no-repudio, la rendición de cuentas, la autenticidad y la confiabilidad. Una valoración así proveería las dimensiones de elementos importantes para el valor del activo, además del costo de reemplazo, basándose en estimados de las consecuencias adversas al negocio que resultarían de incidentes de seguridad con un conjunto asumido de circunstancias. Se enfatiza que este enfoque da cuenta de las consecuencias que es necesario factorizar en la evaluación del riesgo. Muchos activos pueden, durante el curso de la valorización, tener varios valores asignados. Por ejemplo, un plan de negocios se puede valorizar en base a la mano de obra utilizada para desarrollar el plan, se puede valorizar sobre la mano de obra respecto de los insumos y se puede valorizar sobre su valor para un competidor. Cada uno de los valores asignados probablemente diferirá considerablemente. El valor asignado puede ser el máximo de todos los valores posible o puede ser la suma de uno o todos los valores posibles. En el análisis final se debe determinar cuidadosamente cuál valor o valores se asignan a un activo, ya que el valor final asignado entra en la determinación de los recursos que se emplearán para la protección del activo. Reducción a la base común Finalmente, todas las valorizaciones de activos tienen que reducirse a una base común. Esto puede hacerse con la ayuda de criterios como los que siguen. Los criterios que se pueden utilizar para evaluar las condiciones posibles que resultan de una pérdida de confidencialidad, integridad, disponibilidad, no-repudiación, rendición de cuentas, autenticidad o confiabilidad de los activos son:


-


Afectación del desempeño empresarial. Pérdida de buen nombre/ efecto negativo sobre la reputación. Infracción asociada con información personal. Puesta en peligro de la seguridad personal. Efectos adversos sobre la aplicación de la ley. Ruptura de la confidencialidad. Ruptura del orden público. Pérdida financiera. Interrupción de las actividades empresariales. Puesta en peligro de la seguridad ambiental.

Otro enfoque para evaluar las consecuencias podría ser: -

Introducción del servicio incapacidad de proveer el servicio

-

Pérdida de confianza por parte de los clientes pérdida de credibilidad en el sistema de información interna daño a la reputación

-

Interrupción de la operación interna interrupción en la organización misma costo interno adicional

-

Interrupción de la operación de un tercero interrupción en terceros que transan con la organización varios tipos de daño

-

Infracción de leyes/ regulaciones: incapacidad de cumplir con las obligaciones legales

-

Ruptura de contrato: incapacidad de cumplir con las obligaciones contractuales

-

Peligro a la seguridad del personal / usuario: peligro para el personal y/o los usuarios de la organización

-

-

-

-

Ataque a la vida privada de los usuarios

-

Pérdidas financieras


-


Costos financieros para emergencia o reparación: en términos del personal en términos del equipo en términos de los estudios, informes de expertos Pérdida de bienes/fondos/activos Pérdida de clientes, pérdida de proveedores Procesos judiciales y sanciones Pérdida de una ventaja competitiva Pérdida del liderazgo tecnológico/técnico Pérdida de eficacia/confianza Pérdida de reputación técnica Debilitamiento de la capacidad de negociación Crisis industrial (huelgas) Crisis gubernamental Despidos Daño material

Estos criterios son ejemplos de cuestiones a considerarse para la valorización de activos. Para llevar a cabo las valorizaciones, una organización tiene que seleccionar criterios relevantes para su tipo de negocio y necesidades de seguridad. Esto puede significar que algunos de los criterios listados anteriormente no sean aplicables y que otros puedan requerir añadirse a la lista. Escala Luego de establecer los criterios a considerarse, la organización deberá ponerse de acuerdo sobre una escala a ser utilizada en toda la organización. El primer paso es decidir sobre el número de niveles a utilizarse. No existen reglas respecto al número de niveles más apropiado. Si hay más niveles se provee una granularidad mayor, pero a veces una diferenciación muy fina hace que las asignaciones consistentes en toda la organización sean difíciles. Normalmente cualquier número de niveles entre tres (por ejemplo, bajo, medio y alto) y diez puede utilizarse siempre y cuando sean consistentes con el enfoque que la organización está utilizando para todo el proceso de evaluación del riesgo.



Una organización puede definir sus propios límites para la valorización de activos, como “bajo”, “medio”, o “alto”. Estos límites deben evaluarse de acuerdo con criterios seleccionados (por ejemplo, para pérdidas financieras posibles, deben darse en valores monetarios, pero para consideraciones como la puesta en peligro de la seguridad del personal, la valorización monetaria puede ser compleja y puede no ser apropiada para todas las organizaciones). Finalmente, depende completamente de la organización el decidir qué se considera como una consecuencia “baja” o “alta”. Una consecuencia que puede ser desastrosa para una organización pequeña puede ser “baja” o “insignificante” para una organización pequeña. Dependencias Cuanto más relevantes y numerosos sean los procesos empresariales apoyados por un activo, mayor será el valor de este activo. Deben identificarse las dependencias de los activos en los procesos empresariales y en otros activos también, ya que esto puede influenciar los valores de los activos. Por ejemplo, la confidencialidad de datos debe mantenerse a lo largo de su ciclo de vida, en todas las etapas, incluyendo el almacenamiento y el procesamiento, es decir, la seguridad necesita de almacenamiento y los programas y el procesamiento deben estar directamente relacionados con el valor que representa la confidencialidad de los datos almacenados y procesados. Además, si un proceso empresarial depende de la integridad de que un programa produzca ciertos datos, los datos insumo de este programa deben tener una confiabilidad apropiada. Además, la integridad de la información dependerá del hardware y el software que se utilice para el almacenamiento y el procesamiento. El hardware también dependerá del suministro de electricidad y posiblemente del aire acondicionado. De este modo, la información sobre las dependencias ayudará a identificar las amenazas y particularmente las vulnerabilidades. Por otro lado, ayudará a asegurar que se de a los activos el verdadero valor de los activos (a través de las relaciones de dependencias), indicando así el nivel apropiado de protección. Los valores de los activos de los que otros activos dependen se pueden modificar de la manera siguiente: -

Si los valores de los activos dependientes (por ejemplo datos) son más bajos o iguales a los valores del activo considerado (por ejemplo software), su valor sigue siendo el mismo.


-


Si los valores del activo dependiente (por ejemplo datos) es mayor, entonces el valor del activo considerado (por ejemplo software) debe incrementarse de acuerdo con: -

el grado de dependencia los valores de otros activos

Una organización puede tener algunos activos que estén disponibles más de una vez, como las copias de programas de software o del mismo tipo de computadora utilizado en la mayor parte de oficinas. Es importante considerar este hecho cuando se hace la valorización de activos. Por un lado, estos activos se desatienden fácilmente, por lo tanto se debe tener cuidado en identificar a todos ellos. Por otro lado, se les podría utilizar para reducir los problemas de disponibilidad. Producto El producto final de este paso es una lista de activos y sus valores relativos respecto de la divulgación (preservación de confidencialidad), modificación (preservación de la integridad, autenticidad, no-repudio y rendición de cuentas), no-disponibilidad y destrucción (preservación de la disponibilidad y confiabilidad) y costo de reemplazo.

B.3

Evaluación del impacto

Un incidente en la seguridad de la información puede impactar más que un activo o sólo una parte de un activo. El impacto se relaciona con el grado de éxito del incidente. Como consecuencia, existe una diferencia importante entre el valor del activo y el impacto que resulta del incidente. Se considera que el impacto tiene ya sea un efecto inmediato (operativo) o futuro (empresarial) que incluye consecuencias financieras y de mercado. El impacto operativo inmediato es ya sea directo o indirecto.



Directo: a)

El valor de reemplazo financiero de activos perdidos o parte de los mismos.

b)

El costo de adquisición, configuración e instalación del nuevo activo o respaldo.

c)

el costo de las operaciones suspendidas debido al incidente hasta que el servicio proporcionado por el (los) activo (s) se restaure.

d)

Resultados del impacto en una ruptura de la seguridad de la información.

Indirecto: a)

Costo de oportunidad (se tiene que usar recursos financieros para reemplazar o reparar un activo que podría haber sido utilizado en otro lugar.

b)

El costo de las operaciones interrumpidas.

c)

Un mal uso potencial de la información obtenida a través de una ruptura de la seguridad.

d)

Violación de obligaciones estatutarias o regulatorias.

e)

Violación de códigos de conducta éticos.

Como tal, la primera evaluación (sin controles de ningún tipo) estimará un impacto como muy cercano al (a los) valor (es) concernido (s) o a una combinación de los mismos. Para cualquier iteración siguiente sobre este (estos) activo (s), el impacto será diferente, normalmente mucho más bajo debido a la presencia y a la eficacia de los controles implementados.



ANEXO C (INFORMATIVO)

EJEMPLOS DE AMENAZAS TÍPICAS La siguiente tabla da ejemplos de amenazas típicas. La lista se puede usar durante el proceso de valorización de amenazas. Las amenazas pueden ser deliberadas, accidentales o ambientales (naturales) y pueden resultar, por ejemplo, en el daño o pérdida de servicios esenciales. La lista siguiente indica para cada tipo de amenaza donde D (deliberada), A (accidental), M (medioambiental) es relevante. D se utiliza para todas las acciones deliberadas que tienen como objetivos los activos de información. A se utiliza para todas las acciones humanas que pueden dañar accidentalmente los activos de la información y M se utiliza para todos los incidentes que no se basan en acciones humanas. El grupo de amenazas no está en orden de prioridad.

Tipo

Daño Físico

Eventos naturales

Pérdida de servicios esenciales Perturbación debido a radiación Compromiso de la información

Amenazas Incendio Daño por agua Contaminación Accidente mayor Destrucción del equipo o los medios Polvo, corrosión, congelación Fenómeno climático Fenómeno sísmico Fenómeno volcánico Fenómeno meteorológico Inundación Fallas del sistema de aire acondicionado o del suministro de agua Pérdida del suministro de electricidad Falla del equipo de telecomunicaciones Radiación electromagnética Radiación térmica Pulsos electromagnéticos Intercepción de señales de interferencia comprometedoras Espionaje remoto Interceptación de comunicaciones Robo de medios o documentos Robo de equipos Hallazgo de medios reciclados o

Origen A, D, M A, D, M A, D, M A, D, M A, D, M A, D, M M M M M M A, D A, D, M A, D A, D, M A, D, M A, D, M D D D D D D


Fallas técnicas

Acciones no autorizadas

Compromiso de funciones


descartados Divulgación Datos de fuentes no confiables Adulteración del hardware Adulteración del software Detección de posición Falla del equipo Mal funcionamiento del equipo Saturación del sistema de información Mal funcionamiento del software Ruptura de la mantenibilidad del sistema de información Uso no autorizado del equipo Copia fraudulenta del software Uso de software falsificado o copiado Corrupción de datos Procesamiento ilegal de datos Error en el uso Abuso de derechos Falsificación de derechos Negación de acciones Ruptura en la disponibilidad del personal

A, D A, D D A, D A A A, D A A, D D D A, D D D A A, D D D A, D, M

Se debe dar atención particular a las fuentes de amenazas humanas. Estas se desglosan en la tabla siguiente: Origen de la amenaza Hacker, cracker

Criminal informático

Terrorista

Motivación Desafío Ego Rebelión Estatus Dinero Destrucción de información Revelación de información ilegal Ganancia monetaria Alteración no autorizada de datos

Chantaje Destrucción

Consecuencias posibles - Hacking - ingeniería social - intrusión en el sistema, incursiones - acceso no autorizado al sistema - Crimen informático (acoso cibernético) - Acto fraudulento (reproducción de archivos, suplantación, intercepción) - Soborno informático - Falsificación o usurpación de la dirección - Intrusión en el sistema - Bomba/Terrorismo - Equipo de guerra informático



Explotación Venganza Ganancia política Cobertura mediática Ventaja competitiva Espionaje económico Espionaje industrial (inteligencia, compañías, gobiernos extranjeros, otros intereses gubernamentales)

Gente de adentro de la institución (empleados mal capacitados, resentidos, maliciosos, negligentes, deshonestos o despedidos)

Curiosidad Ego Inteligencia Ganancia monetaria Venganza Errores y omisiones no intencionales (por ejemplo error en el ingreso de datos, error en la programación)

- Ataque al sistema (por ejemplo negación distribuida del servicio) - Penetración en el sistema - Adulteración del sistema - Ventaja de defensa - Ventaja política - Explotación económica - Robo de información - Intrusión en la privacidad personal - Ingeniería social - Penetración en el sistema - Acceso no autorizado al sistema (acceso a información clasificada, propietaria, y/o relacionada con tecnología) - Asalto a un empleado - Chantaje - Búsqueda de información propietaria - Abuso informático - Fraude y robo - Soborno por información - Ingreso de datos falsificados o corruptos - Intercepción - Códigos maliciosos (por ejemplo virus, bomba lógica, caballo troyano) - Venta de información personal - Disfunciones del sistema (bugs) - Intrusión en el sistema - Sabotaje al sistema - Acceso no autorizado al sistema



ANEXO D (INFORMATIVO)

VULNERABILIDADES Y MÉTODOS PARA LA EVALUACIÓN DE LA VULNERABILIDAD D.1

Ejemplos de vulnerabilidades

La siguiente tabla da ejemplos de vulnerabilidades en varias áreas de seguridad, incluyendo ejemplos de amenazas que pueden explotar estas vulnerabilidades. Las listas pueden proveer ayuda durante la evaluación de amenazas y vulnerabilidades para determinar escenarios de incidentes relevantes. Se enfatiza que en algunos casos otras amenazas también pueden explotar estas vulnerabilidades. Tipos

Hardware

Software

Ejemplos de vulnerabilidades Mantenimiento insuficiente / instalación fallida de medios de almacenamiento Falta de esquemas de reemplazo periódicos Susceptibilidad a la humedad, al polvo y a la suciedad Sensibilidad a la radiación electromagnética Falta de control eficiente del cambio de configuración Susceptibilidad a variaciones de voltaje Susceptibilidad a variaciones de temperatura Almacenamiento no protegido Falta de cuidado al descartarlo Copia no controlada Pruebas al software inexistentes o insuficientes Errores conocidos en el software No hacer ‘logout’ cuando se sale de la estación de trabajo Disposición o reutilización de medios de almacenamiento sin borrar apropiadamente Falta de evidencias de auditoria

Ejemplos de amenazas Ruptura de la mantenibilidad del sistema de información Destrucción de equipo o medio Polvo, corrosión, congelamiento Radiación electromagnética Error en el uso Pérdida de suministro eléctrico Fenómeno meteorológico Robo de medios o documentos Robo de medios o documentos Robo de medios o documentos Abuso de derechos Abuso de derechos Abuso de derechos Abuso de derechos Abuso de derechos


Asignación equivocada de derechos de acceso Software ampliamente distribuido Aplicar programas de aplicación a datos incorrectos en términos del tiempo Interfaz de usuario complicada Falta de documentación Seteo incorrecto de parámetros Fechas incorrectas Falta de mecanismos de identificación y autentificación como la autentificación de usuarios. Tablas de claves no protegidas. Mala administración de claves. Habilitación de servicios innecesarios. Software inmaduro o nuevo. Especificaciones no claras o incompletas para los desarrolladores. Falta de control de cambios eficaz. Descarga y uso incontrolado de software. Falta de copias de respaldo. Falta de protección física del edificio, puertas y ventanas No producir informes de gestión Falta de prueba de envío o recepción de un mensaje Líneas de comunicación no protegidas Tráfico delicado no protegido Juntas malas en el cableado Punto de falla único. Red

Personal

Falta de identificación y autentificación de destinador y destinatario. Arquitectura de red insegura. Transferencia de claves en claro. Gestión inadecuada de la red (capacidad de recuperación del ruteo). Conexiones no protegidas de la red pública. Ausencia de personal. Procedimientos inadecuados de reclutamiento. Capacitación de seguridad insuficiente. Uso incorrecto del software y hardware.


Abuso de derechos Corrupción de datos Corrupción de datos Error en el uso Error en el uso Error en el uso Error en el uso Falsificación de datos Falsificación de datos Falsificación de datos Procesamiento ilegal de datos Mal funcionamiento del software Mal funcionamiento del software Mal funcionamiento del software Adulteración del software Adulteración del software Robo de medios o documentos Uso no autorizado del equipo Mediación de acciones Intercepción Intercepción Falla del equipo de telecomunicaciones Falla del equipo de telecomunicaciones Falsificaciones de derechos Espionaje remoto Espionaje remoto Saturación del sistema de información Uso no autorizado del equipo Ruptura de la disponibilidad del personal Destrucción de equipo o medios Error en uso Error en uso


Sitio

Organización


Falta de conciencia de seguridad. Falta de mecanismos de monitoreo. Trabajo no supervisado del personal externo o de limpieza. Falta de políticas para el uso correcto de medios de telecomunicaciones y mensajería. Uso inadecuado o negligente del control de acceso físico a edificios y habitaciones. Ubicaciones en un área susceptible a las inundaciones.

Error en uso Procesamiento ilegal de datos Robo de medios o documentos

Red inestable de energía eléctrica.

Pérdida de suministro de electricidad Robo de equipos

Falta de protección física del edificio, puertas y ventanas. Falta de un procedimiento formal para el registro y baja de los usuarios. Falta de proceso formal para revisar el derecho de acceso (supervisión). Disposiciones inexistentes o insuficientes (respecto de la seguridad) en contratos con clientes y / o terceros. Falta de procedimiento de monitoreo de las instalaciones de procesamiento de la información. Falta de auditorias regulares (supervisión). Falta de procedimientos de identificación y evaluación del riesgo Falta de informes de fallas registradas en los registros del administrador y del operador. Respuesta inadecuada del mantenimiento del servicio Inexistencia o insuficiencia de acuerdo sobre el nivel del servicio Falta de procedimiento de control de cambios Falta de procedimiento formal para el control de la documentación del ISNS Falta de procedimiento formal para la supervisión del registro del ISNS Falta de proceso formal para autorización de información pública disponible

Uso no autorizado del equipo Destrucción de equipo o de medios Inundación

Abuso de derechos Abuso de derechos Abuso de derechos Abuso de derechos Abuso de derechos Abuso de derechos Abuso de derechos Ruptura de la mantenibilidad del sistema de información Ruptura de la mantenibilidad del sistema de información Ruptura de la mantenibilidad del sistema de información Corrupción de datos Corrupción de datos Datos de fuentes no confiables


Falta de asignación apropiada de responsabilidades de seguridad en la información Faltad de planes de continuidad Falta de una política de uso de correos electrónicos Falta de procedimientos para introducir software en sistemas operativos Faltas de registros en los historiales del administrador y del operador Falta de procedimientos para manejo de la información clasificada Falta de responsabilidades sobre la seguridad de la información en las descripciones de puestos Ausencia o insuficiencia de disposiciones (concernientes a la seguridad de la información en contratos con empleados) Falta de proceso disciplinario definido en caso de incidentes en la seguridad de la información Falta de política formal sobre el uso de computadoras portátiles Falta de control de activos que se encuentran fuera del local Inexistencia o insuficiencia de la política de “Escritorio despejado y pantalla despejada” Falta de autorización al acceso a las instalaciones de procesamiento de la información Falta de mecanismos de monitoreo establecidos para las rupturas de la seguridad Falta de revisiones regulares de la gestión Falta de procedimientos para reportar debilidades en la seguridad Falta de procedimientos sobre el cumplimiento de disposiciones respecto de derechos intelectuales.


Negación de acciones Falla del equipo Error en uso Error en uso Error en uso Error en uso Error en uso Procesamiento ilegal de datos

Robo de equipos Robo de equipos Robo de equipos Robo de medios o documentos Robo de medios o documentos Robo de medios o documentos Uso no autorizado del equipo Uso no autorizado del equipo Uso de software falsificado o copiado


D.2


Métodos para evaluar las vulnerabilidades técnicas

Se puede usar métodos proactivos como la verificación del sistema de información para identificar vulnerabilidades que dependen del carácter crucial de la información del sistema de tecnología de información y comunicaciones (TIC) así como los recursos disponibles (por ejemplo: fondos asignados, tecnología disponible, personas con experiencia para conducir la prueba). Los métodos de prueba incluyen los puntos siguientes: -

Herramienta automatizada para el escaneo de vulnerabilidades. Pruebas y evaluación de seguridad. Prueba de penetración. Revisión del código.

La herramienta automatizada para escanear la vulnerabilidad se usa para escanear un grupo de anfitriones o una red de servicios vulnerables conocidos (por ejemplo el sistema permite un protocolo de transferencia de archivos (STP) anónimo, y hacer relés en el envío de correos). Debe notarse sin embargo, que algunas de las vulnerabilidades potenciales identificadas por la herramienta automatizada de escaneo pueden no representar verdaderas vulnerabilidades en el contexto del entorno del sistema. Por ejemplo, algunas de estas herramientas de escaneo dan puntaje a vulnerabilidades potenciales sin considerar el entorno y necesidades del sitio. Algunas de las vulnerabilidades que el software automatizado de escaneo muestra con alertas, en realidad puede no ser vulnerable para un sitio en particular, sino que están consideradas de esa manera porque el ambiente así lo requiere. Por tanto, este método de pruebas puede producir falsos positivos. Otra técnica que se puede utilizar para identificar vulnerabilidades en el sistema TIC durante el proceso de evaluación del riesgo es la prueba de seguridad y evaluación (STE, por sus siglas en ingles). Incluye el desarrollo y ejecución de un plan de pruebas (por ejemplo libreto de la prueba, procedimientos de la prueba y resultados esperados de la prueba). El propósito de las pruebas al sistema de seguridad es comprobar la eficacia de los controles de seguridad de un sistema TIC tal como se han aplicado en un entorno operativo. El objetivo es asegurar que los controles aplicados cumplan con la especificación aprobada de seguridad para el software y hardware e implementen la política de seguridad de la organización o satisfagan los estándares de la industria.



La prueba de penetración puede utilizarse para complementar la revisión de los controles de seguridad y asegurar que los distintos factores del sistema TIC cuenten con seguridad. Cuando se usa en el proceso de evaluación del riesgo, la prueba de penetración puede utilizarse para evaluar la capacidad que tiene un sistema TIC de soportar intentos intencionales de evitar cumplir con los sistemas de seguridad. Su objetivo es probar el sistema del TIC desde el punto de vista de una fuente de amenazas e identificar las fallas potenciales en los esquemas de protección de los sistemas TIC. La revisión del código es la manera más exhaustiva de evaluación de vulnerabilidad, pero también puede ser la más cara. Los resultados de estos tipos de pruebas de seguridad ayudaran a identificar las vulnerabilidades de un sistema. Es importante notar que las herramientas y técnicas de penetración pueden dar resultados falsos salvo que se explote con éxito la vulnerabilidad. Para explotar vulnerabilidades particulares uno tiene que saber cuáles son los parches de sistema-aplicación exactos instalados en los sistemas que se prueban. Si esos datos no son conocidos en el momento de realizar las pruebas, puede no ser posible explotar con éxito vulnerabilidades particulares (por ejemplo adquiriendo un remote reverse shell ). Sin embargo, todavía es posible averiar o reiniciar un proceso o sistema probado. En tal caso, el objeto probado debe considerarse también como vulnerable. Los métodos pueden incluir las siguientes actividades: -

Entrevistas a personas y usuarios. Cuestionarios. Inspección física. Análisis de documentos.



ANEXO E (INFORMATIVO)

ENFOQUES DE EVALUACIÓN DEL RIESGO EN SEGURIDAD DE LA INFORMACIÓN E.1

Evaluación del riesgo en seguridad de la información de alto nivel

La evaluación de alto nivel permite la definición de prioridades y de la cronología en las acciones. Por varias razones, como el presupuesto, puede no ser posible implementar todos los controles simultáneamente y sólo se pueden resolver los riesgos cruciales a través del proceso de tratamiento del riesgo. Asimismo, puede ser prematuro comenzar a hacer una gestión detallada del riesgo si se avizora que la implementación se debe realizar luego de uno o dos años. Para alcanzar este objetivo, la evaluación de alto nivel puede comenzar con una evaluación de las consecuencias de alto nivel en vez de comenzar con un análisis sistemático de amenazas, vulnerabilidades, activos y consecuencias. Otra razón de comenzar con la evaluación de alto nivel es sincronizar otros planes relacionados con la gestión del cambio (o continuidad el negocio) por ejemplo, no hay que asegurar completamente un sistema o aplicación si se planea tercerizar en el futuro cercano, aunque quizás todavía vale la pena hacer la evaluación del riesgo para definir el contrato de tercerización. Las características de la iteración de la evaluación del riesgo del alto nivel pueden incluir las siguientes: La evaluación del riesgo de alto nivel puede dirigirse a una visión más global de la organización y de sus sistemas de información, considerando los aspectos de la tecnología como independientes de las cuestiones empresariales. Al hacer esto, el análisis del contexto de concentra más en el negocio y el entorno operativo que en los elementos tecnológicos. La evaluación del riesgo de alto nivel puede resolver una lista más limitada de amenazas y vulnerabilidades agrupadas en dominios definidos o para hacer el proceso más expeditivo, puede centrarse en los escenarios de riesgo o ataque en vez de sus elementos.



Los riesgos que se presentan en una evaluación del riesgo de alto nivel frecuentemente son dominios de riesgo más generales que los riesgos específicos identificados. Como los escenarios o los riesgos se agrupan en dominios, el tratamiento del riesgo propone listas de controles. En este campo, las actividades de tratamiento del riesgo tratan entonces primero de proponer y seleccionar controles comunes que sean válidos en todo el sistema. Sin embargo la evaluación del riesgo de alto nivel, como pocas veces se refiere a detalles de tecnología, es más apropiada para proveer controles organizacionales y no técnicos y aspectos de gestión de los controles técnicos o salvaguardas técnicas clave y comunes como los respaldos y los antivirus. Las ventajas de una evaluación del riesgo de alto nivel son las siguientes: La incorporación de un enfoque simple inicial probablemente gane aceptación del programa de evaluación del riesgo. Debe ser posible construir una imagen estratégica de un programa de información organizacional, es decir actuará como una buena ayuda a la planificación. Se puede aplicar recursos y dinero allí donde sean más beneficiosos y se tratará primero los sistemas que tengan una mayor necesidad de protección. Como los análisis de riesgo inicial están en un alto nivel y son potencialmente menos exactos, la única desventaja potencial es que pueda no identificarse que algunos procesos o sistemas no empresariales requieren una segunda evaluación detallada del riesgo. Esto se puede evitar si existe una información adecuada sobre todos los aspectos de la organización y su información y sistemas, incluyendo información adquirida a partir de la evaluación de incidentes de seguridad de la información. La evaluación del riesgo de alto nivel considera los valores empresariales de los activos de información y los riesgos desde el punto de vista del negocio de la organización. En el primer punto de decisión (véase la figura 1) varios factores ayudan a determinar si la evaluación de alto nivel es adecuada para tratar los riesgos. Estos factores pueden incluir los siguientes:



Los objetivos de negocio a lograrse utilizando varios activos de información. El grado en el cual el negocio de la organización depende de cada activo de información, es decir que funciones que la organización considera cruciales para su supervivencia o para el control eficaz del negocio dependen de cada activo o de la confidencialidad, integridad, disponibilidad, no repudio, rendición de cuentas, autenticidad y confiabilidad de la información almacenada y procesada en este activo. El nivel de inversión en cada activo de información en términos de desarrollo, mantenimiento o reemplazo del activo y los activos de información para los cuales la organización asigna valor directamente. Cuando se evalúa estos activos, la decisión se hace más fácil. Si los objetivos de un activo son extremadamente importantes para la conducción del negocio de una organización, o si los activos están en grave riesgo entonces se debe conducir a una segunda evaluación detallada del riesgo para el activo de información particular (o parte del mismo). Una regla general que debe aplicarse es si la falta de seguridad en la información puede resultar en consecuencias adversas significativas para la organización, sus procesos empresariales o sus activos, luego se hace necesaria una segunda iteración de la evaluación del riesgo a nivel más detallado para identificar los riesgos potenciales.

E.2

Evaluación detallada del riesgo en seguridad de la información

El proceso de evaluación detallada del riesgo en seguridad de la información incluye una identificación y valorización profunda de los activos, la evaluación de amenazas a esos activos y la evaluación de vulnerabilidades. Los resultados de esas actividades se utilizan entonces para evaluar los riesgos y luego identificar el tratamiento del riesgo. El paso detallado generalmente requiere mucho tiempo, esfuerzo y experiencia y por lo tanto debe ser conveniente para sistemas de información en alto riesgo. La etapa final de la evaluación detallada del riesgo en seguridad de la información es evaluar los riesgos generales, lo cual es materia de este anexo.



Se puede evaluar las consecuencias de varias maneras, incluyendo el uso de medidas cuantitativas, por ejemplo monetarias, y cualitativas (las que se pueden basar en el uso de adjetivos como moderado o grave), o una combinación de ambas. Para evaluar la posibilidad de la ocurrencia de amenazas, se debe establecer el horizonte temporal sobre el cual el activo tendrá valor o requiera protección. La posibilidad de que ocurra una amenaza específica depende de lo siguiente: La atracción del activo, o el posible impacto aplicable cuando se considera una amenaza humana deliberada. La facilidad de conversión que explota una vulnerabilidad del activo en recompensa, aplicable si se considera una amenaza humana deliberada. Las capacidades técnicas del agente de la amenaza aplicables a amenazas humanas deliberadas, y La susceptibilidad de la vulnerabilidad a la explotación aplicable tanto a vulnerabilidades técnicas como no técnicas. Muchos métodos utilizan tablas y combinan las medidas subjetivas y empíricas. Es importante que la organización utilice un método con el que esté cómoda, en el que la organización tenga confianza y que produzca resultados repetibles. A continuación se dan algunos ejemplos de técnicas basadas en tablas:

E.2.1

Ejemplo 1 Matriz con valores predefinidos

En los métodos de evaluación del riesgo de este tipo, se valoriza los activos físicos, reales o propuestos en términos de los costos de reemplazo o reconstrucción (es decir, medidas cuantitativas). Estos costos se convierten entonces a la misma escala cualitativa que la que se utiliza para la información (véase a continuación). Se valorizan activos de software reales o propuestos de la misma manera que los activos físicos con costos de compra o reconstrucción que se identifican y luego se convierten a la misma escala cualitativa que se utiliza para la información. Adicionalmente, si se encuentra que cualquier software de aplicación tiene sus necesidades intrínsecas de confidencialidad o integridad (por ejemplo si el código fuente por sí mismo es delicado comercialmente) se valoriza de la misma manera que para la información.



Los valores para la información se obtienen entrevistando a gerentes empresariales seleccionados (los “propietarios de los datos”) que pueden hablar con autoridad sobre los datos, para determinar el valor y sensibilidad de los datos que están verdaderamente en uso o que se deben almacenar, procesar o a los que se tiene que tener acceso. Las entrevistas facilitan la evaluación del valor y la sensibilidad de la información en términos de los escenarios del peor caso que se podría esperar razonablemente ocurra debido a consecuencias adversas sobre el negocio por divulgación no autorizada, modificación no autorizada, no disponibilidad para períodos variables y destrucción. La valorización se logra utilizando lineamientos de valorización de la información que cubren cuestiones como: -

Seguridad personal. Información personal. Obligaciones legales y regulatorias. Aplicación de la ley. Intereses comerciales y económicos . Pérdida financiera/ interrupción de actividades. Orden público. Política y operaciones empresariales. Pérdida de buen nombre. Contrato o acuerdo con un cliente.

Los lineamientos facilitan identificación de los valores en una escala numérica como la escala de 0 a 4 que se muestra en la matriz del ejemplo a continuación, permitiendo así el reconocimiento de valores cuantitativos donde sea posible y lógico y de valores cualitativos donde los valores cuantitativos no sean posibles, por ejemplo si se pone en peligro la vida humana. La siguiente actividad importante es completar las parejas de cuestionarios para cada tipo de amenazas, para cada agrupamiento de activos a los que se relaciona un tipo de amenaza, para permitir la evaluación de los niveles de amenazas (probabilidad de ocurrencia) y los niveles de vulnerabilidades (facilidad de explotación por las amenazas para causar consecuencias adversas). Cada respuesta a una pregunta implica un puntaje. Estos puntajes se acumulan a través de una base de conocimientos y se comparan con rangos. Esto identifica niveles de amenaza en una escala de alta a baja y niveles de vulnerabilidad de manera similar, tal como se muestra en la matriz del ejemplo siguiente, diferenciando entre los tipos de consecuencias como relevantes. La información para completar los cuestionarios debe reunirse a partir de entrevistas con personal técnico apropiado y las



personas concernidas, así como inspecciones de la ubicación física y revisiones de la documentación.

TABLA E.1 a) Posibilidad de ocurrencia – amenaza Facilidad de explotación Valor del Activo

0 1 2 3 4

Baja

Media

Alta

L

H

M

L

H

M

L

H

M

0 1 2 3 4

1 2 3 4 5

2 3 4 5 6

1 2 3 4 5

2 3 4 5 6

3 4 5 6 7

2 3 4 5 6

3 4 5 6 7

4 5 6 7 8

Los valores de los activos y los niveles de amenaza y vulnerabilidad relevantes para cada tipo de consecuencias se hacen corresponder en una matriz como la que se muestra a continuación de modo que se identifique para cada combinación la medida relevante de riesgo en una escala de 0 a 8. Los valores se colocan en la matriz de manera estructurada. A continuación se proporciona un ejemplo: Para cada activo, se consideran las vulnerabilidades relevantes y sus amenazas correspondientes. Si hay una vulnerabilidad sin amenaza correspondiente, o una amenaza sin vulnerabilidad correspondiente, actualmente no hay riesgo (pero se debe tener cuidado en el caso en que esta situación cambie). Ahora la fila apropiada en la matriz se identifica por el valor del activo y la columna apropiada se identifica por la posibilidad de que ocurra la amenaza y la facilidad de explotación. Por ejemplo, si el activo tiene el valor 3 la amenaza es “alta” y la vulnerabilidad “baja”, la medición de riesgo es 5. Asumamos que un activo tiene un valor de 2, por ejemplo para modificación, el nivel de amenaza es “bajo” y la facilidad de explotación es “alta”, entonces la medida del riesgo es 4. El tamaño de la matriz, en términos del número de categorías con posibilidad de amenaza, facilidad de categorías de explotación y número de categorías de valorización de activos se puede ajustar a las necesidades de la organización. Las columnas y filas adicionales necesitarán medidas de riesgo adicional. El valor de este enfoque está en la calificación de los riesgos a resolverse.



Una matriz similar como la que se muestra en la matriz E.1 b) resulta de la consideración de la posibilidad de un escenario de incidentes, mapeado contra el impacto estimado sobre el negocio. La posibilidad de un escenario de incidentes está dada por una amenaza que explota una vulnerabilidad con una cierta posibilidad. La tabla mapea esta posibilidad contra el impacto sobre el negocio relacionado al escenario de incidentes. El riesgo resultante se mide en una escala de 0 a 8 que se puede evaluar contra los criterios de aceptación del riesgo. Esta escala de riesgos puede también mapearse a un puntaje general de riesgo, por ejemplo del modo siguiente: -

Riesgo bajo: 0-2 Riesgo medio: 3-5 Riesgo alto: 6-8

TABLA E.1 b)

Impacto sobre el negocio

E.2.2

Posibilidad de escenario de incidentes Muy bajo Bajo Medio Alto Muy alto

Muy baja (Muy poco probable) 0 1 2 3 4

Baja (Probable)

Mediano (Posible)

Alta (Probable)

Muy Alta (Frecuente)

1 2 3 4 5

2 3 4 5 6

3 4 5 6 7

4 5 6 7 8

Ejemplo 2 Calificación de las amenazas por mediciones del riesgo

Se puede utilizar una matriz o tabla como la que se muestra en la tabla E.2 para relacionar los factores de consecuencia (valor de activos) y la posibilidad de ocurrencia de las amenazas (tomando en cuenta los aspectos de vulnerabilidad). El primer paso es evaluar las consecuencias (valoración de activos en una escala predefinida, por ejemplo de 1 a 5, de cada activo amenazado (columna “b” en la tabla). El segundo paso es evaluar la posibilidad de la ocurrencia de amenazas en una escala predefinida, por ejemplo 1 a 5, de cada amenaza (columna “c” en la tabla). El tercer paso es calcular la medida del riesgo por medio de la multiplicación (b x c). Finalmente se puede calificar las amenazas en orden de su medida del riesgo asociada. Nótese que en este ejemplo se toma 1 como la consecuencia más baja y como la posibilidad más baja de ocurrencia.



TABLA E.2 Descriptor de la amenaza (a) Amenaza A Amenaza B Amenaza C Amenaza D Amenaza E Amenaza F

Valor de la consecuencia (activo) (b) 5 2 3 1 4 2

Posibilidad de la ocurrencia de amenaza (c) 2 4 5 3 1 4

Medida del riesgo (d) 10 8 15 3 4 8

Calificación de la amenaza (e) 2 3 1 5 4 3

Tal como se muestra arriba, éste es un procedimiento que permite comparar distintas amenazas con diferentes consecuencias y probabilidades de ocurrencia y colocarlas en orden de prioridad tal como se muestra aquí. En algunas instancias será necesario asociar valores monetarios con las escalas empíricas que se utilizan aquí.

E.2.3 Ejemplo 3 - Evaluación del valor para la probabilidad y las consecuencias posibles de los riesgos En este ejemplo, se enfatiza las consecuencias de los incidentes en seguridad de la información (es decir escenario de incidencias) y el determinar a cuál sistema se debe dar prioridad. Esto se hace evaluando dos valores para cada activo y riesgo, lo cual en combinación determinará el puntaje para cada activo. Cuando todos los puntajes activos para el sistema se suman, se determina una medida de riesgo para ese sistema. Primero, se asigna un valor a cada activo. Este valor se relaciona a las consecuencias adversas potenciales que pueden surgir si se amenaza el activo. Para cada amenaza aplicable al activo, este valor del activo se asigna al activo. Luego se evalúa el valor de probabilidad. Esto se evalúa a partir de una combinación de la probabilidad de que la amenaza ocurra y la facilidad de explotación de la vulnerabilidad. Véase la tabla E.3 que expresa la probabilidad de un escenario de incidentes.



TABLA E.3 Probabilidades de la amenaza Niveles de Vulnerabilidad Valor de vulnerabilidad de un escenario de incidentes

Baja

Media

Alta

L

M

H

L

M

H

L

M

H

0

1

2

1

2

3

2

3

4

Luego, se asigna un puntaje de activo/amenaza encontrando la intercepción del valor del activo y el valor de probabilidad en la tabla E.4. Los puntajes de activo/amenaza se totalizan para producir un puntaje total de activos. Esta figura se puede utilizar para diferenciar entre los activos que forman parte de un sistema.

TABLA E.4 Valor del activo Valor de la probabilidad 0 1 2 3 4

0

1

2

3

4

0 1 2 3 4

1 2 3 4 5

2 3 4 5 6

3 4 5 6 7

4 5 6 7 8

El paso final es totalizar todos los puntajes totales del activo para los activos del sistema, produciendo un puntaje del sistema. Esto se puede utilizar para diferenciar entre sistemas y para determinar a que protección del sistema debería dársele prioridad. En los siguientes ejemplos se elige todos los valores de manera aleatoria. Supongamos que el sistema S tiene tres activos A1, A2 y A3. También supongamos que hay dos amenazas T1 y T2 aplicables al sistema S. Digamos que el valor de A1 es 3, de manera similar digamos que el valor del activo de A2 sea 2 y que el valor del activo de A3 sea 4.



Si para A1 y T1 la probabilidad de amenaza es baja y la facilidad de la explotación de la vulnerabilidad es media, entonces el valor de probabilidad es 1 (véase la tabla E.3). El puntaje de activo/amenaza A1/T1 se puede derivar de la tabla E.4 como la intercepción del valor 3 del activo y el valor de probabilidad 1, es decir 4. De manera similar, para A1/T2 digamos que la probabilidad de la amenaza es media y la facilidad de explotación de la vulnerabilidad es alta, dado un puntaje A1/T2 de 6. Ahora el puntaje total del activo A1T se puede calcular, es decir, 10. El puntaje total del activo se calcula para cada activo y amenaza aplicable. El puntaje total del sistema se calcula añadiendo A1 T + A2 T + A3 T para dar ST. Ahora se puede comparar diferentes sistemas para establecer prioridades y distintos activos dentro de un sistema también. El ejemplo de arriba se plantea en términos de sistemas de información. Sin embargo, se puede aplicar un enfoque similar a los procesos empresariales.



ANEXO F (INFORMATIVO)

RESTRICCIONES PARA LA REDUCCIÓN DEL RIESGO Cuando se consideran las restricciones para la reducción del riesgo, se debe tomar en cuenta las siguientes restricciones:

Restricciones de tiempo Pueden existir muchos tipos de restricciones de tiempo. Por ejemplo, se debe implementar controles dentro de un período aceptable para los gerentes de la organización. Otro tipo de restricción de tiempo es si se puede implementar un control dentro del tiempo de vida de la información o sistema. Un tercer tipo de restricción de tiempo puede ser el período que los gerentes de la organización deciden que es un período aceptable para exponerse a un riesgo en particular.

Restricciones financieras Los controles no deben ser más caros de implementar o mantener que el valor de los riesgos que van a proteger, excepto donde el cumplimiento sea obligatorio (por ejemplo con la legislación). Se debe hacer todos los esfuerzos para no exceder presupuestos asignados y lograr ventaja financiera a través de los controles. Sin embargo, en algunos casos puede no ser posible lograr la seguridad deseada y el nivel de aceptación del riesgo debido a las restricciones del presupuesto. Por lo tanto, esto se convierte en una decisión de los gerentes de la organización para la resolución de esta situación. Se debe tener mucho cuidado si el presupuesto reduce el número o calidad de los controles a implementarse ya que esto puede llevar a la retención implícita de un mayor riesgo del que se había planeado. El presupuesto establecido para los controles debe utilizarse como un factor limitante solamente con mucho cuidado.



Restricciones técnicas Se puede evitar fácilmente problemas técnicos como la compatibilidad de los programas o de hardware si se toman en cuenta durante la selección de controles. Además, a menudo las restricciones técnicas retrasan la implementación retrospectiva de controles a un proceso o sistema existente. Estas dificultades pueden mover el equilibrio de controles hacia los aspectos de procedimiento y físicos de la seguridad. Puede ser necesario revisar el programa de seguridad de la información para lograr objetivos de seguridad. Esto puede ocurrir cuando los controles no satisfacen los resultados esperados en la reducción de riesgos sin reducir la productividad.

Restricciones operativas Las restricciones operativas como la necesidad de operar 24 horas al día por 7 días a la semana requiere realizar respaldos y puede resultar en una implementación de controles compleja y costosa salvo que estén incorporados en el diseño desde el inicio.

Restricciones culturales Las restricciones culturales a la selección de controles pueden ser específicas a un país, un sector, una organización o incluso un departamento dentro de una organización. No se puede aplicar todos los controles en todos los países. Por ejemplo, puede ser posible implementar búsquedas en carteras en partes de Europa, pero no en partes de Medio Oriente. Los aspectos culturales no se pueden ignorar porque muchos controles se basan en el apoyo activo del personal. Si el personal no comprende la necesidad del control o no lo encuentra culturalmente aceptable, el control se hará ineficaz con el tiempo.

Restricciones éticas Las restricciones éticas pueden tener implicaciones importantes sobre los controles ya que la ética cambia en base a las normas sociales. Esto puede impedir la implementación de controles como el escaneo de correos electrónicos en algunos países. La privacidad de la información también puede cambiar dependiendo de la ética de la región o del gobierno. Esto puede preocupar más en algunos sectores industriales que en otros, por ejemplo el gobierno y la atención de salud.



Restricciones ambientales Los factores ambientales pueden influir la selección de controles como la disponibilidad de espacio, las condiciones climáticas extremas, la geografía natural y urbana circundantes. Por ejemplo, se puede requerir en algunos países que las construcciones sean anti-sísmicas, pero esto será innecesario en otros.

Restricciones legales Los factores legales como la protección de los datos personales o las disposiciones del código penal para el procesamiento de la información pueden afectar la selección de controles. El cumplimiento legislativo regulatorio puede obligar a ciertos tipos de control incluyendo la protección de datos y la auditoria financiera. También pueden impedir el uso de algunos controles, por ejemplo la encriptación. Otras leyes y regulaciones como la legislación de las leyes laborales, el departamento de bomberos, la salud y la seguridad, así como las regulaciones del sector económico, etc. podrían afectar también la selección de controles.

Facilidad de uso Una mala interfaz humano-tecnología resultará en error humano y puede hacer que el control sea inútil. Los controles deben seleccionarse para proveer facilidad óptima de uso a la vez que se logra un nivel aceptable de riesgo residual al negocio. Los controles que son difíciles de usar impactarán su eficacia, ya que los usuarios pueden tratar de evitarlos o ignorarlos tanto como sea posible. Los controles de acceso complejo dentro de una organización pueden alentar a los usuarios a encontrar métodos de acceso alternativos y no autorizados.

Restricciones del personal El costo de la disponibilidad y de los salarios de personal especializado para implementar los controles y la capacidad de movilizar personal entre lugares en condiciones operativas adversas es algo que debe considerarse. Es posible que los expertos no estén disponibles de inmediato para implementar controles planificados o que dichos expertos sean demasiado costosos para la organización. Otros aspectos que pueden tener implicaciones importantes para las políticas y prácticas de seguridad son la tendencia de cierto personal de discriminar

248928225-Bibliografia-04-ISO-27005.pdf

Recommend Documents