Publicada la nueva norma ISO 27001:2013

octubre 14, 2013 § Deja un comentario

Como adelantamos hace unos días, las nuevas normas ISO 27001:2013 e ISO 27002:2013 han sido publicadas. Las normas que ayudan a las empresas a gestionar la seguridad de la información fueron creadas por primera vez por BSI, la empresa de normas de negocio, con el nombre de BS 7799. Con la revisión de 2013, la norma internacional permitirá a las empresas de todos los tamaños y sectores adaptarse a la rápida evolución y la creciente complejidad de la gestión de la información y el continuo desafío que plantea la seguridad cibernética. La votación final fue lanzada principios de julio. Descargue la guía gratuita de Transición (inglés) y los cambios realizados, aquí, aquí y aquí.

El funcionamiento de los negocios de hoy en día difiere enormemente de la primera utilización de BS 7799 en 1995, los avances tecnológicos significan que las necesidades de seguridad de la información también han cambiado. Las revisiones ayudarán a las empresas a percibir los cambios en seguridad de la información y no solo limitarse a TI, e incluye elementos más amplios, como las personas. También tiene en cuenta las interacciones que pueden ocurrir entre otras normas de Sistemas de Gestión y cuestiones como la Gestión de Riesgos y Gestión de Continuidad del Negocio.

ISO 27001 Tecnología de la Información – Técnicas de Seguridad – Sistemas de Gestión de Seguridad de la Información – Requisitos especifica los requisitos para establecer, implementar, mantener y mejorar continuamente un Sistema de Gestión de Seguridad de la Información.

Cambios clave:

  • Se ha modificado para adaptarse a la nueva estructura de alto nivel utilizado en todas las normas de Sistemas de Gestión, lo que simplifica su integración con otros sistemas de gestión
  • Incorpora los comentarios de los usuarios de la versión 2005 y genéricamente tiene en cuenta la evolución del panorama tecnológico de los últimos 8 años

¿Cómo las empresas pueden beneficiarse de la norma ISO 27001?

  • Aumenta la reputación de los negocios que han implementado la norma
  • Protege a las empresas mediante la identificación de riesgos y estableciendo controles para gestionarlos o reducirlos
  • Ayuda a los grupos de interés y aumenta la confianza del cliente, teniendo sus datos protegidos
  • Aumenta las oportunidades de acceso a licitaciones mediante la demostración de cumplimiento y obteniendo un estatus como proveedor preferido

Fuente: BSI Group

Anuncios

ISACA Madrid presenta #CobIT 5 en español

septiembre 12, 2013 § 1 comentario

Tras varios meses de intenso trabajo, ISACA Madrid publica de CobIT 5 en español, una traducción del original en inglés que editó ISACA Internacional el año pasado, de la que el capítulo de Madrid de ISACA se ha encargado de los tres documentos principales: CobIT 5, CobIT 5 Procesos Catalizadores y CobIT 5 Implementación.

CobIT es una guía de mejores prácticas que se plasma como marco de negocio para el gobierno y la gestión de cualquier organización. La traducción ha sido realizada por un grupo de 45 asociados de Isaca de habla hispana, tanto españoles como iberoamericanos. CobIT 5 ayuda a empresas de todos los tamaños a:

  • Mantener información de alta calidad para apoyar decisiones empresariales.
  • Conseguir objetivos estratégicos y beneficios empresariales mediante el uso efectivo e innovador de las TI.
  • Conseguir la excelencia operativa mediante la aplicación fiable y eficiente de la tecnología.
  • Mantener el riesgo relacionado con las TI en un nivel aceptable.
  • Optimizar el coste de los servicios y la tecnología de las TI.
  • Apoyar el cumplimiento con leyes, regulaciones, acuerdos contractuales y políticas relevantes.

Antonio Ramos, presidente de ISACA Madrid, resumió con somero detalle la dimensión del proyecto en la presentación de la traducción de este documento, en el que se han abordado tres libros –CobIT 5, CobIT 5 Procesos Catalizadores y CobIT 5 Implementación– que contienen 402 páginas, 144.500 palabras, 42 gráficos y 75 tablas.

ISACA Madrid está actualmente a la espera de ser escogido por Isaca Internacional para traducir también el documento CobIT for Information Security.

Algunas de las principales novedades de la versión 5 de CobIT:

  • Tres volúmenes (no se veía desde CobIT 3).
  • Nueva representación gráfica (framework) que tiene en cuenta los resultados del proyecto “Taking Governance Forward”, ejecutado en 2010.
  • Nueva jerarquía de Áreas, Dominios, Procesos y Actividades: incorporación del modeloISO/IEC 38500 (sin mencionarlo explícitamente) y cambio en la nomenclatura de los dominios; cambios, también, en los procesos.
  • La cascada de sincronización/alineamiento Negocio-TI toma el protagonismo, pasando de ser un anexo en CobIT 4.1 a ser el punto clave de la filosofía CobIT 5.
  • Nuevas matrices RACI que amplian el enfoque de CobIT más allá del territorio CIO. Ya lo habían hecho ValIT (2006) y RiskIT (2009).
  • CobIT 5 se configura como un marco de referencia para el Gobierno Corporativo de TI. (Pero no el primero. ValIT: el Gobierno Corporativo de las TI es el proceso de toma de decisiones en torno a la aplicación y uso de las TI).
  • Nuevo programa de formación, certificación (de profesionales y empresas?) y acreditación (de instructores), a través del acuerdo con AMPG.
  • Nueva oferta (reducida) de certificados personales (actualmente) a sólo 1 (CobIT Foundation).
  • Nuevo modelo -aparecido previamente para CobIT 4.1 (2011)- de evaluación de la capacidad de los procesos.

La planificación de esta táctica está basada en tres horizontes: de 2012 a 2016, de 2016 a 2019 y de 2019 a 2020.

Fuente: Red Seguridad

Política de Seguridad de la Información modelo publicado por ONTI

septiembre 9, 2013 § Deja un comentario

La Oficina Nacional de Tecnologías de Información (ONTI) aprobó la actualización de la política de seguridad de la información para la administración pública nacional, con especial énfasis en la capacitación y compromiso de los usuarios ya sean funcionarios o técnicos.

La Disposición 3 de la ONTI (que reemplaza a la anterior Disposición ONTI Nº 6/2005) fija la “Política de seguridad de la información modelo” [PDF] que deberá ser aplicada en cada una de las oficinas, organismos y empresas del Estado nacional, con el objetivo de asegurar la continuidad del servicio al ciudadano.

Según cita la disposición, publicada hoy en el Boletín Oficial, los especialistas del Estado nacional entienden que el “incremento en cantidad y variedad de amenazas y vulnerabilidades que rodean a los activos de información” obliga a que esta “Política de Seguridad Modelo” sea “actualizada a fin de mantener su vigencia y nivel de eficacia”.

A su vez remarca que la “mera elaboración por parte de los organismos de políticas de seguridad no es suficiente para garantizar la seguridad de la información, la que permite a su vez garantizar la prestación continua e ininterrumpida de los diversos servicios públicos prestados por dichos organismos”.

Así como que “sólo a través de la efectiva implementación de las medidas contempladas en dichas políticas se podrá proteger acabadamente los recursos de información de los organismos como así también la tecnología utilizada para su procesamiento”.

Además, en el anexo, la ONTI considera que esta política de seguridad de la información “debe ser conocida y cumplida por toda la planta de personal del Organismo, tanto se trate de funcionarios políticos como técnicos, y sea cual fuere su nivel jerárquico y su situación de revista”.

Fuente: Telam

Bloomberg se disculpa por acceder a datos delicados de clientes

mayo 14, 2013 § Deja un comentario

Matthew Winkler, redactor jefe de Bloomberg News, pidió disculpas en lunes por permitir a sus periodistas acceso “limitado” a datos delicados sobre la forma en que los clientes usan los terminales de Bloomberg, calificándolo de “inexcusable”, pero aseguró que siempre se protegieron los datos importantes de los clientes.

Su comunicado llega después de que varios bancos centrales estudiaran posibles violaciones de la confidencialidad en el uso de los datos.

En Asia, el Banco de Japón dijo haber contactado con Bloomberg mientras que la Autoridad Monetaria de Hong Kong, el banco central de facto del territorio, dijo que estaba estudiando el asunto.

“Estamos hablando con Bloomberg y estamos en proceso de confirmar los hechos de la situación”, dijo a Reuters un portavoz del Banco de Japón.

El Banco Central Europeo, el brasileño y la Reserva Federal de Estados Unidos también han dicho que están estudiando el asunto, al igual que el Departamento del Tesoro de EEUU, según una fuente informada sobre la situación.

La práctica de dar a los periodistas acceso a algunos datos considerados exclusivos, como cuándo un cliente entra en ciertas categorías como valores y bonos, salió a la prensa la semana pasada. Como respuesta, la sociedad matriz, Bloomberg, dijo haber restringido ese tipo de acceso el mes pasado tras una queja de Goldman Sachs Group.

En un editorial colgado en Bloomberg.com, Winkler dijo: “Nuestros periodistas no deberían tener acceso a ningún dato considerado exclusivo. Siento que lo hiciera. El error es inexcusable”.

Goldman planteó el asunto ante Bloomberg después de averiguar que los periodistas tuvieron acceso a más información de lo que sabía y argumentó que la información era delicada y no debería haber sido vista por los reporteros.

La noticia desató el temor entre las empresas de Wall Street por la privacidad de los datos más delicados, así como en la Fed y en otros departamentos del Gobierno de EEUU que utilizan los terminales de Bloomberg.

En el editorial, Winkler trató de aclarar que información podían ver exactamente sus periodistas. Dijo que tenían acceso al historial de ‘login’ del usuario, así como a “tipos de funciones de usuario de alto nivel sobre una base agregada, sin capacidad de ver información especifica de seguridad”.

Dijo que esta costumbre se remontaba a los primeros días de Bloomberg News en los años 90, cuando los reporteros usaban el terminal para ver qué tipo de cobertura de noticias querían los clientes.

“Puesto que la privacidad de los datos se ha convertido en una preocupación central para nuestros clientes, deberíamos ir mucho más allá en la protección de los datos, especialmente cuando tenemos la apariencia de incorrección”, escribió Winkler. “Y por eso hemos hecho estos cambios recientes a lo que pueden acceder los periodistas.”

Este intento de controlar los daños sufrió un potencial revés el mismo lunes, cuando The Financial Times publicó que miles de mensajes privados enviados por los terminales de Bloomberg en 2009 y 2010 fueron subidos a una web que no era segura, al parecer por accidente.

Los mensajes, enviados entre operadores de algunos de los mayores bancos del mundo y sus clientes, contenían información confidencial sobre precios y actividad financiera, dijo el diario. Posteriormente fueron eliminados de la página.

The Financial Times citó a un portavoz de Bloomberg: “Este trabajo se hizo con el consentimiento de los clientes, en el que los correos electrónicos fueron reenviados explícitamente a nosotros a una cuenta de correo dedicada y publicados por la persona responsable del correo para que pudiéramos llevar a cabo pruebas internas para mejorar nuestra tecnología para el cliente”.

Un portavoz de la empresa no quiso hacer más comentarios al ser contactado por Reuters.

Fuente: Reuters

Clasificación de información e ISO 30301

mayo 3, 2013 § Deja un comentario

Desde el año pasado existe la norma ISO 30300 sobre la gestión documental que proporciona viento fresco a los que nos dedicamos a su protección. Cada día soy más consciente de que el término “información” engloba un conjunto de definiciones que aun siendo similares, representan conceptos diferentes y de relevancia distinta. Los que nos dedicamos a la “seguridad de la información” según el caso y el tipo de documento podemos ser los garantes del conocimiento y la sabiduría de una empresa. El nivel de comprensión y el contexto en el que son analizados los datos, van elevando su altura y relevancia.

Uno de los grandes retos de la seguridad de la información es que por desgracia, carecemos de cultura de gestión de la información y por tanto, algunas de las medidas a implantar como controles ISO 27002 son duros de llevar a la práctica porque implican un cambio organizativo y cultural importante. Como es un tema que sufro de forma continua he tratado de buscar referencias que pudieran ayudarme y el haber tenido una compañera documentalista ha sido un gran lujo porque me ha tenido siempre bien informado y me ha hecho ver el tremendo papel que juegan los documentalistas en toda organización. Hace meses me habló de la norma ISO 30301 que pretende ser para la gestión documental lo mismo que ISO 27001 es para la seguridad de la información. Además, tenemos la suerte de que esta norma se ha cocinado bastante en España y tenemos a grandes expertos de la materia haciendo difusión de esta norma.

Me han dado la oportunidad de contribuir como redactor en el blog www.iso30300.es y eso esta permitiendo intercambiar enfoques e impresiones respecto a cómo abordar aspectos comunes entre las normas ISO 27001 e ISO 30301 (de diciembre de 2011) Al fin y al cabo no puede haber “gestión de la documentación” sin seguridad, pero tampoco puede haber “seguridad de la información” sin gestión de la documentación. Mi primer articulo está enfocado a plantear cómo puede definirse un criterio de clasificación que contemple los requisitos legales establecidos y a la par sea algo manejable, aplicable y real para una implementación en cualquier tipo de organización. El post por largo ha sido dividido en trozos:

Todavía no hay respuesta en la búsqueda de este santo grial, pero seguro que una solución mixta entre el mundo de la gestión documental y la seguridad de la información será mas completa y acertada que desde una visión parcial donde la protección prima por encima de cuestiones operativas. Ambas normas, ISO 27001 e ISO 30301 deben resolver la cuestión y nos toca ahora plantear un cuadro de clasificación de documentación que pueda servir para resolver el tema. En lo que respecta al marco jurídico, la legislación tanto de protección de datos de carácter personal como de Administración electrónica ya ha puesto nombre y apellidos a los criterios de clasificación, puesto que define 3 niveles: Alto, Medio y Básico. Ahora toca establecer los requisitos para definir todo el ciclo de vida de la información: recogida, clasificación, tratamiento, almacenamiento, transporte, desclasificación y destrucción.

Aquí hay una selección de recursos de referencia sobre la Norma ISO 30300.

Fuente: Blog de Javier Cao Avellaneda

Plan para la Recuperación de Desastres de TI

marzo 25, 2013 § 1 comentario

Los planes de recuperación de desastres (RD) en tecnologías de la información (TI) proporcionan un enfoque estructurado para responder a los incidentes no previstos que ponen en peligro la infraestructura de TI, compuesta por hardware, software, redes, procesos y personas. Proteger las inversiones realizadas por su firma en la infraestructura tecnológica y garantizar la capacidad empresarial para ejecutar sus operaciones corporativas son las principales razones para poner en marcha un plan de recuperación de desastres en TI.

En esta guía conoceremos todo lo necesario acerca de la elaboración del plan. Aprenderemos a desarrollar paso por paso el plan de RD de TI y los aspectos más importantes a tener en cuenta durante su elaboración.

¿Qué es un plan de recuperación de desastres TI?

Los planes de recuperación de desastres TI proporcionan unos procedimientos detallados a seguir, paso a paso, para recuperar los sistemas y redes que han sufrido disrupciones y ayudar a resumir la normalidad en las operaciones. El objetivo de estos procesos es minimizar cualquier impacto negativo en las operaciones de la compañía. El proceso de recuperación de desastres identifica los sistemas y redes críticos de TI; fija las prioridades para su recuperación y dibuja los pasos necesarios para reiniciar, reconfigurar y recuperar dichos sistemas y redes. Todo plan integral de recuperación de desastres debería incluir también a todos los proveedores relevantes, las fuentes de experiencia para recuperar los sistemas afectados y una secuencia lógica de los pasos a seguir hasta alcanzar una recuperación óptima.

Asumiendo que hemos completado una evaluación de riesgos e identificado amenazas potenciales a nuestra infraestructura de TI, el siguiente paso será determinar qué elementos de dicha infraestructura son los más importantes para las operaciones corporativas. Además, asumiendo que todos los sistemas y redes TI funcionan con normalidad, nuestra empresa debería ser plenamente viable, competitiva y sólida desde el punto de vista financiero. Cuando un incidente —interno o externo— afecta negativamente a la infraestructura de TI, las operaciones corporativas pueden verse amenazadas.

Según la NIST SP 800-34 [PDF], Contingency Planning for Information Technology Systems (Planificación de contingencias para los sistemas de tecnologías de la información), del National Institute for Standards and Technology (NIST, o Instituto Nacional de Estándares y Tecnología) de los Estados Unidos, lo que viene a continuación resume la estructura ideal de un plan de recuperación de desastres TI.

1. Elaboración de la declaración de políticas para el plan de contingencia. Contar con unas directivas formales proporciona la autoridad y orientación necesaria para elaborar un plan de contingencia efectivo.

2. Realización del análisis de impacto sobre el negocio (BIA). El análisis del impacto sobre el negocio ayuda a identificar y priorizar los sistemas y componentes críticos de TI.

3. Identificación de controles preventivos. Medidas que reducen los efectos de las disrupciones al sistema y pueden aumentar su disponibilidad y reducir los costos de contingencia del ciclo de vida.

4. Desarrollo de estrategias de recuperación. Tener una estrategia integral garantiza que el sistema se recuperará de manera rápida y efectiva después de una disrupción.

5. Desarrollo de un plan de contingencia TI. El plan de contingencia debería contener orientaciones y procedimientos detallados para la restauración del sistema dañado.

6. Prueba, formación y ejecución del plan. La prueba del plan identifica lagunas en la planificación, mientras que la formación prepara al personal de recuperación para la activación del plan; ambas actividades mejoran la eficacia del plan y la preparación general de la entidad.

7. Mantenimiento del plan. El plan debería ser un documento vivo que se actualiza regularmente para mantenerlo al día con mejoras al sistema.

Desarrollo paso a paso del plan de recuperación de desastres TI

Utilizando la estructura apuntada en la publicación SP 800-34 del NIST, podemos ampliar esas actividades a la siguiente secuencia estructurada de actividades.

1. El equipo de desarrollo del plan debería reunirse con el equipo interno de tecnología, el equipo de aplicación y los administradores de redes, y establecer el alcance de la acción, como por ejemplo, elementos internos, activos externos, recursos de terceros y enlaces a oficinas/clientes/proveedores; debemos asegurarnos de informar a la dirección del departamento de TI sobre dichas reuniones para que estén bien informados.

2. Recopilar todos los documentos relevantes de la infraestructura de redes, como los diagramas de las redes, la configuración de los equipos y bases de datos.

3. Obtener copias de los planes de recuperación de redes y de TI existentes; si no los hay, proceder con los siguientes pasos.

4. Identificar las amenazas contra la infraestructura de TI que la dirección considere más preocupantes: por ejemplo, incendios, errores humanos, apagones de energía, fallo de los sistemas.

5. Identificar aquello que la dirección considera que son las principales vulnerabilidades de la infraestructura: por ejemplo, inexistencia de sistemas de respaldo en caso de apagón eléctrico, copias de bases de datos obsoletas.

6. Examinar el historial previo de apagones y disrupciones, y cómo fueron gestionados por la empresa.

7. Identificar los activos TI que la dirección considera de importancia crítica. Por ejemplo: centro de llamadas, granjas de servidores, acceso a internet.

8. Determinar el tiempo máximo de apagón eléctrico que está dispuesta a aceptar la dirección en caso de indisponibilidad de los equipos TI.

9. Identificar los procedimientos operativos que se utilizan actualmente para responder a los apagones críticos.

10. Determinar cuándo se probaron estos procedimientos para validar si siguen siendo adecuados o no.

11. Identificar el/los equipo/s de respuesta de emergencia para todas las disrupciones de la infraestructura crítica de TI; determinar su nivel de conocimientos y preparación para manejar los sistemas críticos, especialmente en casos de emergencia.

12. Identificar las capacidades de respuesta de los proveedores en casos de emergencia; si se han utilizado alguna vez; si funcionaron correctamente; cuánto paga la compañía por estos servicios; el estado del contrato de servicio; la existencia del acuerdo de nivel de servicio (SLA) y si se usa alguna vez.

13. Recopilar los resultados de todas las evaluaciones en un reporte de análisis de carencias que identifique lo que se está haciendo frente a lo que debería hacerse, con recomendaciones sobre cómo lograr el nivel requerido de preparación y las inversiones necesarias para ello.

14. Lograr que la dirección lea el repote y acuerde tomar las acciones recomendadas.

15. Preparar un plan de recuperación de desastres IT que cubra los sistemas y las redes esenciales de TI.

16. Realizar pruebas de los planes y activos de recuperación de sistemas para validar su operatividad.

17. Actualizar la documentación del plan de RD para que recoja los cambios efectuados.

18. Programar la próxima revisión/auditoría de capacidades de recuperación de desastres TI.

Aspectos clave a considerar al planificar la recuperación de desastres TI

  • Apoyo de la alta gerencia. Asegúrese de tener el apoyo de la alta gerencia a fin de lograr alcanzar los objetivos del plan.
  • Tomarse en serio el proceso de planificación de RD de TI. Aunque la recopilación y análisis de los datos para el plan de RD de TI puede llevar mucho tiempo, no es necesario que tenga docenas de páginas. Los plantes simplemente necesitan la información correcta, y esa información debería ser actual y precisa.
  • Disponibilidad de estándares. Entre los estándares relevantes que podemos usar a la hora de desarrollar los planes de RD de TI están los siguientes: NIST SP 800-34, ISO/IEC 24762 y BS 25777.
  • La sencillez es un grado. Es esencial reunir y organizar la información correcta.
  • Estudiar los resultados con las unidades de negocio. Una vez finalizado el plan de recuperación de desastres, debemos cotejar sus conclusiones con los líderes de las unidades de negocio para comprobar que nuestras premisas son correctas.
  • Flexibilidad. La plantilla sugerida en este artículo puede ser modificada en lo que sea necesario para conseguir nuestros objetivos.

Análisis de la plantilla del plan de RD de TI

A continuación, examinaremos el índice de la plantilla, señalando las cuestiones clave a tratar y las actividades a desarrollar.

1. Declaración de intenciones del departamento de TI — Marca la pauta y dirección del plan.

2. Declaración de políticas — Es muy importante incluir una declaración aprobada con las políticas relativas a la provisión de servicios de recuperación de desastres.

3. Objetivos — Principales metas del plan.

4. Información de contacto del personal clave — Muy importante tener la información clave de contacto cerca del comienzo del plan. Es la información más susceptible de ser utilizada de inmediato y debería ser fácil de ubicar.

5. Visión general del plan — Describe los aspectos básicos del plan, como la actualización.

6. Respuesta de emergencia — Describe lo que hay que hacer inmediatamente en caso de incidente.

7. Equipo de recuperación de desastres — Miembros y datos de contacto del equipo de RD.

8. Alerta de emergencia, escalada y activación del PRD — Pasos a seguir en las primeras fases del incidente hasta que se activa el plan de RD.

9. Medios — Consejos para tratar con los medios de comunicación.

10. Seguro — Resume la cobertura de seguros asociada con el entorno TI y otras políticas relevantes.

11. Cuestiones legales y financieras — Acciones a tomar para administrar las cuestiones legales y financieras.

12. Ejecución del PRD — Subraya la importancia de ejecutar el plan de recuperación de desastres.

13. Apéndice A — Plantillas del plan de recuperación de desastres tecnológicos — Plantillas modelo para una variedad de recuperaciones por incidentes tecnológicos; es útil tener disponible la documentación técnica de algunos proveedores selectos.

14. Apéndice B — Formularios recomendados — Formularios listos para usar que ayudarán a facilitar la finalización del plan.

Teniendo en cuenta las inversiones que las empresas realizan en infraestructuras TI, sería conveniente que inviertan también tiempo y recursos para proteger dichas inversiones de acontecimientos no previstos y potencialmente destructivos.

Articulos Relacionados

Acerca del autor: Paul Kirvan, CISA, CISSP, FBCI, CBCP, tiene más de 20 años de experiencia en gestión de continuidad del negocio como consultor, autor y educador. Además, es secretario del Instituto de Continuidad del Negocio, capítulo de EE.UU.

Fuente: Search Data Center

Cambios en la nueva ISO 27001 2013 Draft (III)

febrero 14, 2013 § 1 comentario

En el post anterior se ha analizado los cambios entre la antigua ISO 27001 (publicado en 2005) y el proyecto de 2013. Naturalmente, los controles de la ISO 27001 Anexo A no pueden cambiar sin cambiar la ISO 27002 porque la esencia de estas dos normas deben estar alineadas.

Ahora, echemos un vistazo a los cambios que se proponen en la norma ISO 27002, según el sitio web de BSI). Como siempre es importante hacer notar que, dado que esto es sólo una versión DIS (Draft), la versión final de la norma ISO 27002:2013, diferirá un poco. Aquí me centraré principalmente en la forma en que los controles están estructurados, y no tanto en su descripción.

Número de secciones: como era de esperar, el número de secciones ha aumentado de 11 secciones que contienen los controles en el viejo estándar a 14 en el nuevo. De esta manera, el problema en la norma antigua, donde algunos controles se insertaban “artificialmente” en ciertas áreas adonde no pertenecían, ahora se ha resuelto.

Número de controles: sorprendentemente, el número de controles ha disminuido de 133 a sólo 113. Esto es debido a la eliminación de algunos controles que eran demasiado específicos o anticuados.

Estructura de secciones: criptografía se ha convertido en una sección separada (#10) y ya no es (lógicamente) parte del dominio de “Desarrollo y adquisiciones de sistemas”. Algo similar ha sucedido con las “relaciones con los proveedores” y se han convertido en una sección aparte (#15). El dominio “Gestión de comunicaciones y operaciones” se dividió en “Operaciones de seguridad” (#12), y “Comunicaciones de seguridad” (#13). Las secciones ahora son:

  • 5 Security Policies
  • 6 Organization of information security
  • 7 Human resource security
  • 8 Asset management
  • 9 Access control
  • 10 Cryptography
  • 11 Physical and environmental security
  • 12 Operations security
  • 13 Communications security
  • 14 System acquisition, development and maintenance
  • 15 Supplier relationships
  • 16 Information security incident management
  • 17 Information security aspects of business continuity
  • 18 Compliance

Reubicación de controles

  • El control de dispositivos móviles y teletrabajo, previamente en el control de acceso, ahora es parte de la sección 6.2 Organización de la seguridad de la información.
  • Manipulación de los medios de comunicación que anteriormente era parte de Gestión de comunicaciones y operaciones, ahora forma parte de la gestión de activos 8.3.
  • El Control de acceso al sistema operativo, las aplicaciones y el control de acceso a la información, se han fusionado en el Sistema de control de aplicaciones y acceso (9.4).
  • El Control del software operativo, anteriormente un único control en el Sistema de información de la adquisición, desarrollo y mantenimiento, es ahora una categoría aparte 12.5 en la sección de Operaciones de seguridad.
  • Las consideraciones de Auditoría sistemas de información han pasado desde el dominio de Cumplimiento a la sección 12.7 de Seguridad de operaciones.
  • La categoría de acceso a la red se ha ido, y algunos de sus controles se han trasladado a la sección 13 la Seguridad en las comunicaciones.
  • La transferencia de información (anteriormente llamado Intercambio de información) es ahora parte de la sección 13.2 Seguridad en las comunicaciones.
  • La categoría controversial sobre el procesamiento correcto de información  en las aplicaciones, se ha ido.
  • Los servicios de comercio electrónico se fusionaron en el dominio 14.1 sobre Requisitos de seguridad de sistemas de información.
  • Dos categorías de la sección de Gestión de Incidentes se han unido en una sola.
  • En la sección de continuidad de negocio se ha agregado una nueva categoría, la 17.2 sobre la redundancia de datos.

Nuevos controles

  • 14.2.1 Política de desarrollo seguro – Reglas para el desarrollo de software y sistemas de información
  • 14.2.5 Los procedimientos del sistema de desarrollo – Principios para la ingeniería de sistemas
  • 14.2.6 entorno de desarrollo seguro – establecer y proteger el entorno de desarrollo
  • 14.2.8 Sistema de pruebas de seguridad – las pruebas de funcionalidad de seguridad
  • 16.1.4 Evaluación y decisión de los eventos de seguridad de información – esto es parte de la gestión de incidentes
  • 17.2.1 Disponibilidad de instalaciones de procesamiento de información – lograr redundancia

Controles que se han ido

  • 6.2.2 Abordar la seguridad al tratar con los clientes
  • 10.4.2 Controles contra código móvil
  • 10.7.3 Procedimientos de manejo de la información
  • 10.7.4 Seguridad de la documentación del sistema
  • 10.8.5 Sistemas de Información Empresarial
  • 10.9.3 Información pública
  • 11.4.2 Autenticación de usuario para conexiones externas
  • 11.4.3 Identificación de los equipos en las redes
  • 11.4.4 remoto puerto de diagnóstico y configuración de protección
  • 11.4.6 Red de control de la conexión
  • 11.4.7 Red de control de encaminamiento
  • 12.2.1 Validación de datos de entrada
  • 12.2.2 Control de procesamiento interno
  • 12.2.3 Integridad del mensaje
  • 12.2.4 Salida de validación de datos
  • 11.5.5 Tiempo de sesión
  • 11.5.6 Limitación del tiempo de conexión
  • 11.6.2 Aislamiento del sistema Sensitive
  • 12.5.4 Filtración de información
  • 14.1.2 Continuidad del negocio y evaluación de riesgos
  • 14.1.3 Desarrollo e implementación de planes de continuidad de negocio
  • 14.1.4 Continuidad del negocio marco de planificación
  • 15.1.5 Prevención del uso indebido de las instalaciones de procesamiento de información
  • 15.3.2 Protección de las herramientas de auditoría de sistemas de información

Dado que la estructura de la norma ISO 27002 está completamente alineada con los controles de la ISO 27001, todos estos cambios también son válidos para las nuevas ISO 27001 anexo A.

A primera vista, hay muchos cambios pero la mayoría de los mismos no son realmente fundamentales sino que muchos de ellos se han adaptado en una nueva estructura y se han añadido controles que faltaban desde el principio. Para concluir, la aplicación de esta nueva norma va a ser más fácil de implementar.

Cristian de la Redacción de Segu-Info

¿Dónde estoy?

Actualmente estás explorando la categoría politicas en Seguridad Informática.