Gestión de seguridad ITIL
 | Este artículo necesita citas adicionales para su verificación . ( agosto de 2016 ) |
La gestión de seguridad de ITIL describe la integración estructurada de la seguridad en una organización. La gestión de la seguridad de ITIL se basa en el estándar ISO 27001. "ISO / IEC 27001: 2005 cubre todo tipo de organizaciones (por ejemplo, empresas comerciales, agencias gubernamentales, organizaciones sin fines de lucro). [1]ISO / IEC 27001: 2005 especifica los requisitos para establecer, implementar, operar, monitorear, revisar, mantener y mejorar un Sistema de Gestión de Seguridad de la Información documentado dentro del contexto de los riesgos comerciales generales de la organización. Especifica los requisitos para la implementación de controles de seguridad personalizados para las necesidades de organizaciones individuales o partes de las mismas. ISO / IEC 27001: 2005 está diseñado para garantizar la selección de controles de seguridad adecuados y proporcionados que protejan los activos de información y den confianza a las partes interesadas ".
Un concepto básico de la gestión de la seguridad es la seguridad de la información . El objetivo principal de la seguridad de la información es controlar el acceso a la información. El valor de la información es lo que debe protegerse. Estos valores incluyen confidencialidad , integridad y disponibilidad . Los aspectos inferidos son la privacidad, el anonimato y la verificabilidad.
El objetivo de la gestión de la seguridad se divide en dos partes:
- Los requisitos de seguridad definidos en los acuerdos de nivel de servicio (SLA) y otros requisitos externos que se especifican en los contratos de base, la legislación y las posibles políticas impuestas internas o externas.
- Seguridad básica que garantiza la continuidad de la gestión. Esto es necesario para lograr una gestión de nivel de servicio simplificada para la seguridad de la información.
Los SLA definen los requisitos de seguridad, junto con la legislación (si corresponde) y otros contratos. Estos requisitos pueden actuar como indicadores clave de rendimiento (KPI) que se pueden utilizar para la gestión de procesos y para interpretar los resultados del proceso de gestión de la seguridad.
El proceso de gestión de la seguridad se relaciona con otros procesos ITIL. Sin embargo, en esta sección en particular las relaciones más obvias son las relaciones con los de gestión de nivel de servicio , gestión de incidentes y de gestión del cambio procesos.
Gestion de seguridad
La gestión de la seguridad es un proceso continuo que se puede comparar con el Círculo de calidad de W. Edwards Deming ( Planificar, Hacer, Verificar, Actuar ).
Los insumos son requisitos de los clientes. Los requisitos se traducen en servicios de seguridad y métricas de seguridad. Tanto el cliente como el subproceso del plan afectan el SLA. El SLA es una entrada tanto para el cliente como para el proceso. El proveedor desarrolla planes de seguridad para la organización. Estos planes contienen políticas y acuerdos a nivel operativo. Los planes de seguridad (Plan) se implementan (Hacer) y luego se evalúa la implementación (Verificar). Después de la evaluación, se mantienen los planes y la implementación del plan (Act).
Las actividades, los resultados / productos y el proceso están documentados. Los informes externos se redactan y envían a los clientes. Luego, los clientes pueden adaptar sus requisitos en función de la información recibida a través de los informes. Además, el proveedor de servicios puede ajustar su plan o la implementación en función de sus hallazgos para satisfacer todos los requisitos establecidos en el SLA (incluidos los nuevos requisitos).
Control
La primera actividad en el proceso de gestión de la seguridad es el subproceso de "Control". El subproceso de Control organiza y gestiona el proceso de gestión de la seguridad. El subproceso de Control define los procesos, la asignación de responsabilidad por las declaraciones de política y el marco de gestión.
El marco de gestión de la seguridad define los subprocesos para el desarrollo, la implementación y las evaluaciones en planes de acción. Además, el marco de gestión define cómo se deben informar los resultados a los clientes.
| Ocupaciones | Sub-actividades | Descripciones |
|---|---|---|
| Control | Implementar políticas | Este proceso describe los requisitos y reglas específicos que deben cumplirse para implementar la gestión de la seguridad. El proceso termina con una declaración de política . |
| Configurar la organización de seguridad | Este proceso configura las organizaciones para la seguridad de la información . Por ejemplo, en este proceso se configura la estructura de responsabilidades. Este proceso finaliza con el marco de gestión de seguridad . | |
| Reportando | En este proceso, todo el proceso de focalización se documenta de una manera específica. Este proceso finaliza con los informes . |
El modelo de metaproceso del subproceso de control se basa en un diagrama de actividad UML y ofrece una descripción general de las actividades del subproceso de control. El rectángulo gris representa el subproceso de control y las formas de haz más pequeñas en su interior representan actividades que tienen lugar en su interior.
| Concepto | Descripción |
|---|---|
| Documentos de control | Control es una descripción de cómo se organiza la gestión de la seguridad y cómo se gestiona. |
| Declaraciones de poliza | Las declaraciones de política describen los requisitos o reglas específicos que deben cumplirse. En el ámbito de la seguridad de la información , las políticas suelen ser específicas de un punto y abarcan un área única. Por ejemplo, las políticas de "uso aceptable" cubren las reglas y regulaciones para el uso apropiado de las instalaciones informáticas. |
| Marco de gestión de seguridad | El marco de gestión de la seguridad es un marco de gestión establecido para iniciar y controlar la implementación de la seguridad de la información dentro de una organización y para gestionar la provisión de seguridad de la información en curso. |
El modelo de metadatos del subproceso de control se basa en un diagrama de clases UML . La figura 2.1.2 muestra el metamodelo del subproceso de control.
Figura 2.1.2: Subproceso de control del modelo de meta-proceso
El rectángulo CONTROL con una sombra blanca es un concepto complejo abierto. Esto significa que el rectángulo de Control consta de una colección de (sub) conceptos.
La figura 2.1.3 es el modelo de datos de proceso del subproceso de control. Muestra la integración de los dos modelos. Las flechas de puntos indican los conceptos que se crean o ajustan en las actividades correspondientes.
Figura 2.1.3: Subproceso de control del modelo de datos de proceso
Plan
El subproceso del Plan contiene actividades que, en cooperación con la gestión del nivel de servicio, conducen a la sección Seguridad (de la información) en el SLA. Además, el subproceso del Plan contiene actividades relacionadas con los contratos subyacentes que son específicos para la seguridad (de la información).
En el subproceso del Plan, los objetivos formulados en el SLA se especifican en forma de acuerdos de nivel operativo (OLA). Estos OLA pueden definirse como planes de seguridad para una entidad de organización interna específica del proveedor de servicios.
Además de la entrada del SLA, el subproceso del Plan también trabaja con las declaraciones de política del propio proveedor de servicios. Como se dijo anteriormente, estas declaraciones de política se definen en el subproceso de control.
Los acuerdos de nivel operativo para la seguridad de la información se establecen e implementan con base en el proceso ITIL. Esto requiere la cooperación con otros procesos de ITIL. Por ejemplo, si la administración de seguridad desea cambiar la infraestructura de TI para mejorar la seguridad, estos cambios se realizarán a través del proceso de administración de cambios . La administración de seguridad entrega la entrada (Solicitud de cambio) para este cambio. El administrador de cambios es responsable del proceso de gestión de cambios.
| Ocupaciones | Sub-actividades | Descripciones |
|---|---|---|
| Plan | Crear sección de seguridad para SLA | Este proceso contiene actividades que conducen al párrafo de acuerdos de seguridad en los acuerdos de nivel de servicio. Al final de este proceso, se crea la sección Seguridad del acuerdo de nivel de servicio. |
| Crear contratos de respaldo | Este proceso contiene actividades que conducen a contratos de respaldo. Estos contratos son específicos por seguridad. | |
| Crear acuerdos de nivel operativo | Los objetivos generales formulados en el SLA se especifican en los acuerdos de nivel operativo. Estos acuerdos pueden verse como planes de seguridad para unidades organizativas específicas. | |
| Reportando | En este proceso, todo el proceso de Crear plan se documenta de una manera específica. Este proceso finaliza con los informes. |
El plan consiste en una combinación de (sub) actividades ordenadas y desordenadas. El subproceso contiene tres actividades complejas que son todas actividades cerradas y una actividad estándar.
| Concepto | Descripción |
|---|---|
| Plan | Esquemas formulados para los acuerdos de garantía. |
| Sección de seguridad de los acuerdos de nivel de seguridad | El párrafo de acuerdos de seguridad en los acuerdos escritos entre un proveedor de servicios y el cliente (s) que documenta los niveles de servicio acordados para un servicio. |
| Contratos de respaldo | Un contrato con un proveedor externo que cubre la prestación de servicios que apoyan a la organización de TI en su prestación de servicios. |
| Acuerdos de nivel operativo | Un acuerdo interno que cubre la prestación de servicios que apoyan a la organización de TI en su prestación de servicios. |
Al igual que el subproceso de Control, el subproceso de Plan se modela utilizando la técnica de metamodelado. El lado izquierdo de la figura 2.2.1 es el modelo de metadatos del subproceso Plan.
El rectángulo del Plan es un concepto abierto (complejo) que tiene un tipo de relación de agregación con dos conceptos cerrados (complejos) y un concepto estándar. Los dos conceptos cerrados no se expanden en este contexto particular.
La siguiente imagen (figura 2.2.1) es el diagrama de datos de proceso del subproceso Plan. Esta imagen muestra la integración de los dos modelos. Las flechas punteadas indican qué conceptos se crean o ajustan en las actividades correspondientes del subproceso Plan.
Figura 2.2.1: Subproceso del plan del modelo de datos de proceso
Implementación
El subproceso de Implementación asegura que todas las medidas, como se especifica en los planes, se implementen correctamente. Durante el subproceso de Implementación no se definen ni cambian medidas. La definición o el cambio de medidas se lleva a cabo en el subproceso del Plan en cooperación con el Proceso de Gestión del Cambio.
| Ocupaciones | Sub-actividades | Descripciones |
|---|---|---|
| Implementar | Clasificación y gestión de aplicaciones informáticas | Proceso de agrupación formal de elementos de configuración por tipo, por ejemplo, software, hardware, documentación, entorno y aplicación. Proceso de identificación formal de cambios por tipo, por ejemplo, solicitud de cambio de alcance del proyecto, solicitud de cambio de validación, solicitud de cambio de infraestructura, este proceso conduce a documentos de control y clasificación de activos . |
| Implementar la seguridad del personal | Se adoptan medidas para dar seguridad y confianza al personal y medidas para prevenir un delito / fraude. El proceso finaliza con la seguridad del personal . | |
| Implementar la gestión de la seguridad | Se describen y documentan los requisitos de seguridad específicos y / o las reglas de seguridad que deben cumplirse. El proceso finaliza con políticas de seguridad . | |
| Implementar control de acceso | Se describen y documentan los requisitos específicos de seguridad de acceso y / o las reglas de seguridad de acceso que deben cumplirse. El proceso finaliza con el control de acceso . | |
| Reportando | Todo el implemento como proceso planificado se documenta de una manera específica. Este proceso finaliza con los informes . |
El lado izquierdo de la figura 2.3.1 es el modelo de metaproceso de la fase de implementación. Las cuatro etiquetas con sombra negra significan que estas actividades son conceptos cerrados y no se expanden en este contexto. No hay flechas que conecten estas cuatro actividades, lo que significa que estas actividades no están ordenadas y los informes se llevarán a cabo una vez que se hayan completado las cuatro actividades.
Durante la fase de implementación se crean y / o ajustan conceptos.
| Concepto | Descripción |
|---|---|
| Implementación | Gestión de seguridad realizada según el plan de gestión de seguridad. |
| Documentos de clasificación y control de activos | Un inventario completo de activos con responsabilidad asignada para garantizar que se mantenga una protección de seguridad efectiva. |
| Personal de Seguridad | Descripciones de trabajo bien definidas para todo el personal que describan los roles y responsabilidades de seguridad. |
| Políticas de seguridad | Documentos que describen los requisitos de seguridad específicos o las reglas de seguridad que deben cumplirse. |
| Control de acceso | Gestión de la red para asegurar que solo aquellos con la responsabilidad apropiada tengan acceso a la información en las redes y la protección de la infraestructura de soporte. |
Los conceptos creados y / o ajustados se modelan mediante la técnica de metamodelado. El lado derecho de la figura 2.3.1 es el modelo de metadatos del subproceso de implementación.
Los documentos de implementación son un concepto abierto y se amplían en este contexto. Consiste en cuatro conceptos cerrados que no se expanden porque son irrelevantes en este contexto particular.
Para aclarar las relaciones entre los dos modelos, la integración de los dos modelos se ilustra en la Figura 2.3.1. Las flechas de puntos que van de las actividades a los conceptos ilustran qué conceptos se crean / ajustan en las actividades correspondientes.
Figura 2.3.1: Subproceso de implementación del modelo de datos de proceso
Evaluación
La evaluación es necesaria para medir el éxito de la implementación y los planes de seguridad. La evaluación es importante para los clientes (y posiblemente para terceros). Los resultados del subproceso de Evaluación se utilizan para mantener las medidas acordadas y la implementación. Los resultados de la evaluación pueden generar nuevos requisitos y la correspondiente Solicitud de cambio . Luego, la solicitud de cambio se define y se envía a Gestión de cambios.
Los tres tipos de evaluación son la autoevaluación, la auditoría interna y la auditoría externa.
La autoevaluación se realiza principalmente en la organización de los procesos. Las auditorías internas son realizadas por auditores de TI internos. Las auditorías externas son realizadas por auditores de TI externos e independientes. Además de los ya mencionados, se realiza una evaluación basada en los incidentes de seguridad comunicados. Las actividades más importantes para esta evaluación son el monitoreo de seguridad de los sistemas de TI; verificar la legislación de seguridad y la implementación del plan de seguridad; rastrear y reaccionar ante el uso indeseable de suministros de TI.
| Ocupaciones | Sub-actividades | Descripciones |
|---|---|---|
| Evaluar | Auto evaluación | Examinar los acuerdos de seguridad implementados. El resultado de este proceso son los documentos de autoevaluación . |
| Auditoría interna | Examinar los acuerdos de seguridad implementados por un auditor interno de EDP. El resultado de este proceso es la auditoría interna . | |
| Auditoría externa | Examinar los acuerdos de seguridad implementados por un auditor externo de EDP. El resultado de este proceso es la auditoría externa . | |
| Evaluación basada en incidentes de seguridad | Examinar los acuerdos de seguridad implementados basados en eventos de seguridad que no son parte de la operación estándar de un servicio y que causan, o pueden causar, una interrupción o una reducción en la calidad de ese servicio. El resultado de este proceso son los incidentes de seguridad . | |
| Reportando | Documentar el proceso de implementación de Evaluar de una manera específica. Este proceso finaliza con los informes . |
Figura 2.4.1: Subproceso de evaluación del modelo de datos de proceso
El diagrama de datos de proceso ilustrado en la figura 2.4.1 consta de un modelo de metaproceso y un modelo de metadatos. El subproceso de Evaluación se modeló utilizando la técnica de metamodelado. Las flechas punteadas que van desde el diagrama de metaproceso (izquierda) hasta el diagrama de metadatos (derecha) indican qué conceptos se crean / ajustan en las actividades correspondientes. Todas las actividades de la fase de evaluación son actividades estándar. Para obtener una breve descripción de los conceptos de la fase de evaluación, consulte la Tabla 2.4.2 donde se enumeran y definen los conceptos.
| Concepto | Descripción |
|---|---|
| EVALUACIÓN | Implementación evaluada / verificada. |
| RESULTADOS | El resultado de la implementación evaluada. |
| DOCUMENTOS DE AUTOEVALUACIÓN | Resultado del examen de la gestión de seguridad por parte de la propia organización del proceso. |
| AUDITORÍA INTERNA | Resultado del examen de la gestión de seguridad por el auditor interno de EDP. |
| AUDITORÍA EXTERNA | Resultado del examen de la gestión de seguridad por el auditor externo de EDP. |
| DOCUMENTOS DE INCIDENTES DE SEGURIDAD | Resultados de la evaluación de eventos de seguridad que no forman parte de la operación estándar de un servicio y que causan, o pueden causar, una interrupción o una reducción en la calidad de ese servicio. |
Tabla 2.4.2: Subproceso de evaluación de conceptos y definiciones Gestión de la seguridad
Mantenimiento
Debido a los cambios organizativos y de la infraestructura de TI, los riesgos de seguridad cambian con el tiempo, lo que requiere revisiones de la sección de seguridad de los acuerdos de nivel de servicio y los planes de seguridad.
El mantenimiento se basa en los resultados del subproceso de evaluación y en el conocimiento de los riesgos cambiantes. Estas actividades producirán propuestas. Las propuestas sirven como insumos para el subproceso del plan y viajan a través del ciclo o pueden adoptarse como parte del mantenimiento de los acuerdos de nivel de servicio. En ambos casos, las propuestas podrían dar lugar a actividades en el plan de acción. Los cambios reales se realizan mediante el proceso de Gestión de cambios.
| Ocupaciones | Sub-actividades | Descripciones |
|---|---|---|
| Mantener | Mantenimiento de acuerdos de nivel de servicio | Esto mantiene los acuerdos de nivel de servicio en condiciones adecuadas. El proceso finaliza con acuerdos de nivel de servicio mantenidos . |
| Mantenimiento de acuerdos de nivel operativo | Esto mantiene los acuerdos de nivel operativo en condiciones adecuadas. El proceso finaliza con acuerdos de nivel operativo mantenidos . | |
| Solicitud de cambio de SLA y / o OLA | Se formula una solicitud de cambio en el SLA y / o OLA. Este proceso finaliza con una solicitud de cambio . | |
| Reportando | El proceso de políticas de seguridad implementado se documenta de una manera específica. Este proceso finaliza con los informes . |
La figura 2.5.1 es el diagrama de datos de proceso del subproceso de implementación. Esta imagen muestra la integración del modelo de metaproceso (izquierda) y el modelo de metadatos (derecha). Las flechas de puntos indican qué conceptos se crean o ajustan en las actividades de la fase de implementación.
Figura 2.5.1: Subproceso de mantenimiento del modelo de datos de proceso
El subproceso de mantenimiento comienza con el mantenimiento de los acuerdos de nivel de servicio y el mantenimiento de los acuerdos de nivel operativo. Después de que se llevan a cabo estas actividades (sin ningún orden en particular) y hay una solicitud de cambio, se llevará a cabo la solicitud de actividad de cambio y, una vez concluida la solicitud de actividad de cambio, comienza la actividad de informes. Si no hay una solicitud de cambio, la actividad de informes comenzará directamente después de las dos primeras actividades. Los conceptos del modelo de metadatos se crean / ajustan durante la fase de mantenimiento. Para obtener una lista de los conceptos y su definición, consulte la tabla 2.5.2.
| Concepto | Descripción |
|---|---|
| DOCUMENTOS DE MANTENIMIENTO | Acuerdos mantenidos en buenas condiciones. |
| ACUERDOS DE NIVEL DE SERVICIO MANTENIDOS | Los acuerdos de nivel de servicio (párrafo de seguridad) se mantienen en condiciones adecuadas. |
| ACUERDOS DE NIVEL OPERATIVO MANTENIDOS | Los acuerdos de nivel operativo se mantienen en condiciones adecuadas. |
| SOLICITUD DE CAMBIO | Formulario o pantalla que se utiliza para registrar los detalles de una solicitud de cambio en el SLA / OLA. |
Tabla 2.5.2: Concepto y definición Subproceso del plan Gestión de seguridad
Modelo completo de datos de proceso
Figura 2.6.1: Proceso completo de gestión de seguridad del modelo de datos de proceso
Relaciones con otros procesos ITIL
El proceso de gestión de la seguridad, como se indicó en la introducción, tiene relaciones con casi todos los demás procesos de ITIL. Estos procesos son:
- Gestión de relaciones con el cliente de TI
- Gestión del nivel de servicio
- Administración de disponibilidad
- Gestión de capacidad
- Gestión de la continuidad del servicio de TI
- Gestión de la configuración
- Gestión de la liberación
- Gestión de incidentes y mesa de servicio
- Gestión de problemas
- Gestión de cambios (ITSM)
Dentro de estos procesos se requieren actividades relacionadas con la seguridad. El proceso en cuestión y su administrador de procesos son responsables de estas actividades. Sin embargo, Security Management da indicaciones al proceso correspondiente sobre cómo estructurar estas actividades.
Ejemplo: políticas internas de correo electrónico
El correo electrónico interno está sujeto a múltiples riesgos de seguridad, que requieren el plan y las políticas de seguridad correspondientes. En este ejemplo, el enfoque de gestión de la seguridad de ITIL se utiliza para implementar políticas de correo electrónico.
Se forma el equipo de gestión de seguridad y se formulan y comunican las pautas del proceso a todos los empleados y proveedores. Estas acciones se llevan a cabo en la fase de Control.
En la siguiente fase de planificación, se formulan las políticas. Las políticas específicas para la seguridad del correo electrónico se formulan y agregan a los acuerdos de nivel de servicio. Al final de esta fase, todo el plan está listo para ser implementado.
La implementación se realiza de acuerdo con el plan.
Después de la implementación, las políticas se evalúan, ya sea como autoevaluaciones o mediante auditores internos o externos.
En la fase de mantenimiento, las políticas electrónicas se ajustan en función de la evaluación. Los cambios necesarios se procesan a través de Solicitudes de cambio.
Ver también
- Servicios de gestión de infraestructura
- ITIL v3
- Marco de operaciones de Microsoft
- Sistema de gestión de seguridad de la información
- COBIT
- Modelo de Capacidad de Madurez
- ISPL
Ver también
- Seguridad de información
Referencias
- ^ "ISO / IEC 27001: 2005 - Tecnología de la información - Técnicas de seguridad - Sistemas de gestión de seguridad de la información - Requisitos" .
Fuentes
- Bon van, J. (2004). Gestión de servicios de TI: una base operativa introductoria de ITIL. Publicación Van Haren
- Cazemier, Jacques A .; Overbeek, Paul L .; Peters, Louk M. (2000). Gestión de seguridad, Oficina de papelería.
- Gestión de seguridad . (1 de febrero de 2005). Microsoft
- Tse, D. (2005). Seguridad en las empresas modernas: modelo de evaluación de la seguridad para las prácticas de seguridad de la información. Hong Kong: Universidad de Hong Kong.
- ITIL
- La seguridad informática
