NORMA IRAM-ISO/IEC ARGENTINA 27002 Primera edicion 2008-08-15. Tecnologia de la informacién Técnicas de seguridad Codigo de practica para la gestion de la seguridad de la informacion Information technology Security Techniques. Code of practice for information security management * La presente reemplaza a la norma IRAMISO/EC 17799: 2002. Referencia Numérica: IRAM-ISONEC 27002:2008: A DDOCUMENTO PROTEGIDO POR EL DERECHO DE PROPIEDAD INTELECTUAL Ram 2000-06-15, No esta permiida la reproduction de ninguna de las partes de esta publicacion por cualquier medio, Incuyende olocopiado y microfimacion, sn permiso exert del RAM,Prefacio IRAM EI Instituto Argentino de Normalizacién y Certificacién (IRAM) es. tuna asociacién civil sin fines de lucro cuyas finalidades especificas, en su caracter de Organismo Argentino de Normalizacién, son establecer normas técnicas, sin limitaciones en los ambitos que abarquen, ademas de propender al conocimiento y la aplicacion de la normalizacién como base de la calidad, promoviendo las actividades de certificacién de productos y de sistemas de la calidad en las empresas para brindar seguridad al consumidor. IRAM es el representante de la Argentina en la Intemational Organization for Standardization (ISO), en la Comision Panamericana de Normas Técnicas (COPANT) y en la Asociacion MERCOSUR de Normalizacién (AMN). Esta norma IRAM es el fruto del consenso técnico entre los diversos sectores involucrados, los que a través de sus representantes han intervenido en los Organismos de Estudio de Normas correspondientes. La presente reempiaza a la norma IRAM-ISO/IEC 17799: 2002. Esta norma es una adopcion idéntica de la norma ISO/IEC 27002:2005, Se han agregado dos anexos informativos referidos a la bibliogratia ylalista de integrantes del organismo de estudio correspondiente. IRAM-ISO/IEC 27002:2008IRAM-ISO/IEC 27002:2008 Prefacio ISO 1SO (Organizacién Intemacional de Normalizacién) e IEC (Comisién Electrotécnica intemacional) constituyen el sistema especializado para la normalizacién a nivel mundial. Los organismos nacionales que son miembros de ISO o IEC participan en el desarrollo de normas intemacionales a través de comités técnicos establecidos por las organizaciones respectivas para realizar acuerdos en los, ‘campos especificos de la actividad técnica. Los comités técnicos de ISO e IEC colaboran en los campos de interés mutuo. tras organizaciones internacionales, gubernamentales y no gubernamentales, en colaboracién con ISO e IEC, también toman parte en el trabajo. En el campo de la tecnologia de la informacién, ISO e IEC han establecido un comité técnico conjunto, el denominado ISO/IEC JTC 1. Las normas internacionales se elaboran de acuerdo a las reglas dadas en las Directivas de ISO/IEC, parte 2. La tarea principal de! comité técnico conjunto es la de preparar normas internacionales. Los proyectos de normas internacionales adoptadas por el comité técnico conjunto son circulados a los organismos nacionales y sometidos a votacién. La publicacién como Norma Intemacional requiere la aprobacién de al menos e! 75% de los organismos nacionaies. Es importante sefialar la posibilidad de que algunos elementos de esta norma internacional pueden estar sujetos a derechos de patente. ISO e IEC no son responsables de la identificacién de alguno 0 todos de esos derechos de patentes. La norma ISO/IEC 27002 fue preparada por el comité técnico conjunto ISO/IEC JTC1, Tecnologia de la Informacién, subcomité SC 27, Técnicas de seguridad en Tl Esta segunda edicién cancelas y reemplaza a la primera edicion (ISONEC17799:2002) la que ha sido técnicamente revisada. Dentro del ISOMEC JTC 1/SC27 se esta desarrollando una familia de normas internacionales sobre Sistemas de Gestién de ‘Seguridad de la Informacién (ISMS). Esta familia incluye normas internacionales los requisitos del sistema de gestion de la seguridad de la informacién, la gestién de riesgos, las métricas y mediciones la guia de implementacién. Esta familia adoptaré un esquema de numeracién que utiliza la serie de numeros 27000 y los subsiguientes. A partir del 2007 se ha propuesto incorporar la nueva edicién de la ISO/IEC 17799 dentro de este nuevo esquema de numeracién como ISOMEC 27002.IRAM-ISO/IEC 27002:2008 Indice Pagina 0 INTRODUCCION ss 9 0.1 ZQué es la seguridad de la informacion? se oe 0.2 {Por qué es necesaria la seguridad de la informacién? ..., eee 9 0.3 Como establecer los requerimientos de Seguridad .....n.n.n Snonsnnnnnaes 9 (0.4 Evaluacion de os riesgos en materia de seguridad... ee to 0.5 Seleccién de los controles cnn 10 0.6 Punto de partda para la seguridad de ia informacion oo 10 0.7 Factores critcos 66 E10 nnn oat 0.8 Desarrollo de directrices propias a 4 1 OBJETO 1 2, TERMINOS Y DEFINICIONES. ec sussososnsnnnsnnininnnnnsinnnnsnannenonnnnnn 12 3 ESTRUCTURA DE ESTA NORMA eee 14 4 EVALUACION Y TRATAMIENTO DE RIESGOS. 15 4.1 Evaluacién de los riesgos de seguridad 18 4.2 Tratamiento de riesgos de seguridad — nn 16 5 POLITICA DE SEGURIDAD. 5.1. Politica de seguridad de la informacién... 5.1.1 Documentacién de la politica de seguridad 7 Revisién de la politica de seguridad de la informacién... 18 6 ORGANIZACION DE LA SEGURIDAD. 19 6.1. Organizacién Interna. a soe 19 6.1.1 Compromiso gerencial hacia la seguridad de la informaciOn 0.1. 19 Coordinacién de la seguridad de la informacion... — 20 6.1.3 Asignacién de responsabilidades en materia de seguridad de la informacion. 24 6.1.4 Procedimiento de autorizacién para instalaciones de procesamiento de informacion 22 6.1.5 Acuerdos de confidencialidad wn... 22 6.1.6 Contacto con autoridades 23 6.1.7 Contacto con grupos de interés especial. 23 6.1.8 Revisién independiente de la seguridad de la informacién. pee 4 62 Terceras Partes 25 6.2.1 Identificacién de riesgos relacionados con las terceras partes. 25 6.2.2 Asignacién de seguridad cuando se trata con clientes. 27 6.2.3 Asignacién de la seguridad en acuerdos con terceras partes 28 7 GESTION DE ACTIVOS. . 34 7.4. Responsabilidad por los activos =e ee sl 7.1.1 Inventario de activos 3t 7.1.2 Propiedad de los activos 32 7.1.3 Uso aceptable de los activos.. 33 7.2 Clasificacién de la informacion ... 33 7.2.4 Directrices para la clasificacién 33 7.2.2 Rotulado y manejo de la informacién... 34IRAM-ISO/IEC 27002:2008 8 SEGURIDAD DE LOS RECURSOS HUMANOS, 8.1. Antes de la incorporacion o empleo.. 8.1.1 Roles y responsabilidades 8.1.2 Seleccién... 8.1.3 Términos y condiciones de empleo. 82 Durante el empleo. 8.2.1 Responsabilidades de la direccién. 822 Concientizacién, educacin y entrenamionto en seguridad de la informacion. 8.2.3 Proceso disciplinari, 8.3 Desvinculacién o cambio de puesto 8.3.1 Responsabilidades de la desvinculacion... 8.3.2 Retomo de activos. a 8.3.3 Remocidn de derechos de acceso. 9 PROTECCION FISICA Y AMBIENTAL, 9.1 Areas seguras. ar 9.1.1 Perimetro de seguridad fisica 9.1.2 Controles de acceso fisico 9.1.3 Aseguramiento de oficinas, recintos @ instalaciones.. 9.1.4 Proteccién contra amenazas externas y del ambiento . 9.1.5 Trabajo en éreas protegidas 8.1.6 Areas de acceso piblico, de entrega y de carga 9.2 Seguridad del equipamiento 9.2.1 Ubicacién y proteccién del equipamiento... 9.2.2 Elementos de soporte... es 9.2.3 Seguridad del cableaddo. 9.2.4 Mantenimiento del equipamiento . 9.2.5 Seguridad del equipamiento fuera del ambito de la organizacion. 9.2.6 Disposicién final o reutilizacién segura del equipamiento. 9.2.7 Retiro de bienes 10 GESTION DE COMUNICACIONES Y OPERACIONES 10.1. Procedimientos y responsabilidades operativas, 10.141 Documentacién de los procedimientosoperatvos. 10.1.2 Gestion de cambios... aes 10.1.3 Segregacién de funciones. 10.1.4 Separacién de las instalaciones de desarrollo, de pruebas y operacionales 10.2 Gestion de la entrega de servicios por terceras partes 10.2.1 Provision de servicio. 10.2.2 Seguimiento y revisién de los servicios de las terceras partes. 10.2.3 Gestién del cambio de los servicios de terceras partes. 10.3 Planificacién y aceptacion de sistemas 10.3.1 Gestion de la capacidad..... 10.3.2 Aceptacién del sistema, 10.4 Proteccién contra cédigo malicioso y cédigo mévil 10.4.1 Controles contra cédigo malicioso 10.4.2 Controles contra cédigo movil. 10.5 Resguardo. 10.5.1 Resguardo de la informacién 10.6 Gestion de la seguridad de le red 10.6.1 Controles de red@S .r.rnn 10.6.2 Seguridad de los servicios de red. 10.7 Manejo de los medi08 ....n 10.7.1 Gestién de medios removibles.. 10.7.2 Eliminacion de medios. 10.7.3 Procedimientos para el manejo de la informacién 10.7.4 Seguridad de la documentacién de! sistema ..IRAM-ISO/IEC 27002:2008 10.8 Intercambio de ia informacion. : a ac 10.8.1 Politicas y procedimientos de intercambio de fa informacion... oe 66 10.8.2 Acuerdos de intercambio. or 10.8.3 Medios fisicos en transito. 68 10.8.4 Mensajeria electronica : 69 10.8.5 Sistemas de informacion del negocio... 70 10.9 Servicios de comercio electrénico 70 10.1 Comercio electrénico..... 1 10.9.2 Transacciones en linea......... . vs vevenssveees TR 10.9.3 Informacién publicamente disponible. 73 10.10 Seguimiento y control 7 73 10.10.1 Registro de auditoria....... 74 10.10.2 Seguimiento de! uso del sistema .. 7 10.10.3 Proteccién de la informacion de los registro de actividad (‘ogs’) 76 10.10.4 Registos de actividad de administrador yoperador. 76 10.10.5 Registro de acciones fallidas 7 10.10.6 Sincronizacién del reloj oe zi 7 11 CONTROL DE ACCESOS «0 11.1, Requerimientos para el control de accesos. 11.1.1 Politica de contro de accesos. 11.2 Gestion de accesos de usuarios. 11.2.1 Registro de usuarios. 11.2.2 Gestion de privilegios. 11.2.3 Gestion de las contrasenias de usuario. 11.2.4 Revision de los derechos de acceso... 11.3. Responsabilidades del usuario... 11.3.1 Uso de contrasenias 11.3.2 Equipamiento de usuario que se deja desatendido. 11.29 Poles de pantati y escrtorolinpio 11.4 Control de acceso a la red 11.4.4 Politica de utilizacién de los servicios de red. 11.4.2 Autenticacién de usuarios para conexiones externas... 11.4.3 Identificacién del equipamiento en fa red... 11.4.4 Proteccién de los puertos de diagndstico y eenigurecion remotos 11.45 Separacién en redes 11.4.6 Control de conexién a la red... 11.4.7 Control de enrutamiento de red 11.5 Control de acceso al sistema operativo... 11.5.1 Procedimientos seguros de inicio de sesién (‘iog-on'). 11.5.2 Identificacion y autenticacién de usuaris... 11.5.3 Sistema de administracién de contrasefias 11.5.4 Uso de utiltarios de sistema 11.5.5 Expiracion de la sesion 11.6 Control de acceso a las aplicaciones y a la informacién 11.6.1 Restriccién de acceso a la informacién. 11.6.2 Aislamiento de sistemas sensibles 11.7 Computacién movil y teletrabajo, 11.7.4 Computacién y comunicaciones méviles 11.7.2 Teletrabajo .. 12. ADQUISICION, DESARROLLO Y MANTENIMIENTO DE SISTEMAS DE INFORMACION. 99 12.1 Requerimientos de seguridad de los sistemas de informacién..... 99 12.11 Analisis y especifiaciones de os requerimentos de seguridad 99 12.2 Procesamiento correcto en las aplicaciones .. . 100 12.2.1 Validacion de los datos de entrade .n.nninsninnnnnsnnnn or 100 12.22 Controles de procesamiento interno... ———— 101 12.2.3 Integridad del mensaje. 102IRAM-ISO/IEC 27002:2008 12.2.4 Validacién de los datos de salida. nnn 102 12.3 Controles criptograficos 103 12.1 Police do utizacion de controls eitogrces 103 12.3.2 Gestion de claves..... : 12.4 ‘Seguridad de los archivos de sistema 12.4.1 Control del software operacional 12.4.2 Proteccidn de los datos de prueba del sistema 107 12.4.3 Control de acceso al cédigo fuente de programa... 108 12.5. Seguridad en los procesos de desarrollo y soporte. 109 12.5.1 Procedimientos de control de cambios. 109 12.5.2 Revisiones técnicas de las aplicaciones luego de cambios en el sistema operative 110 12.5.3 Restriccién de cambio en los paquetes de SOMWAE. rn soo 110 12.5.4 Fuga de la informacién. Sone E "1 12.5.5 Desarrollo tercerizado de software. 12 12.6 Gestion de vulnerabilidades técnicas nnn 112 12.6.1 Control de fas vulnerabllidades técnicas. : 112 19. GESTION DE LOS INCIDENTES DE LA SEGURIDAD DE LA INFORMACION 114 18.1 Informe de los eventos y debilidades de la seguridad de la informacion 114 13.1.1. Reporte de los eventos de la seguridad de fa informacion. 114 13.1.2 Reporte de las debilidades de la SegUTIdA 0. 18.2 Gestion de los incidentes y mejoras de la seguridad de la informa eB 13.2.1 Responsabilidades y procedimient0S.... sone, 116 13.2.2 Aprendizaje a partir de los incidentes de la seguridad de la informacion... 118 116 13.2.3 Recolecci6n de evidencia.... 118 14 GESTION DE LA CONTINUIDAD DEL NEGOCIO. 119 14.1. Aspectos de la seguridad de la informacion en la gestion de la continuidad del negocio... 119 14.1.1 Inclusién de la seguridad de la informacién en e! proceso de gestién de la continuidad det negocio .. eee 120 14.1.2 Continuidad del negocio y evaluacion de los riesgos 124 14.1.3 Elaboracién e implementacion de planes de continuidad que incan la scoured dela Informacion enn oro) 14.1.4 Marco para la planificacion de la continuidad de! negocio. poamant 22, 14.1.5 Pruebas, mantenimiento y reevaluacin de los planes de continuidad del negocio... 123 15 CUMPLIMIENTO... 125 15.1. Cumplimiento de requerimientos legales..... : senneee 125: 15.1.1 Identificacion de la legislacién aplicable. 125 15.1.2 Derechos de propiedad intelectual (DP). . vee 125 15.1.3 Proteccin de los registros de la organizacién. sn 126 15.1.4 Proteccién de los datos y privacidad de la informacién personal se 127 15.1.5 Prevencién contra ef mal uso de las instalaciones de procesamiento de la informacion... 128 15.1.6 Regulacién de los controles criptograficos. 129 15.2 Cumplimiento con las politicas y normas de seguridad, y el cumplimiento tecnico... 129 15.2.1 Cumplimiento de las politicas y normas de Seguridad ....n senses 130 15.2.2 Verficacién del cumplimiento técnico eee — 130 45.3 Consideraciones de auditorias de sistemas de informacion 131 15.3.1 Controles de auditoria de! sistema de informacién eam 131) 15.3.2 Proteccién de las herramientas de auditoria de los sistemas de informacion. 132 ‘Anexo A (Informativo) Bibliografia de la ISO/IEC 27002:2008. 133 ‘Anexo B - IRAM (Informativo) Bibliografia IRAM.. 135 ‘Anexo C - IRAM (Informativo) Integrantes de los organismos de « studio .IRAM-ISO/IEC 27002:2008 Tecnologia de la informaci6én Técnicas de seguridad Cédigo de practica para la gestion de la seguridad de la informaci6n 0 INTRODUCCION 0.1 Qué es la seguridad de la informacin? La informacion es un recurso que, como otros importantes activos comerciales, tiene valor para una or- ganizacién y por consiguiente debe ser debidamente protegida, Esta es especialmente importante en el ambiente de negocios cuya interconexién va creciendo dia a dia. Como resultado de este incremento de la interconectividad, la informacién ahora esta expuesta a un numero creciente y una variedad de ame- nazas y vulnerabilidades (ver también las guias para sistemas de seguridad de la informacién y redes de la Organization for Economic Cooperation and Development - OECD). La informacion puede existir en muchas formas. Puede estar impresa o escrita en papel, almacenada electrénicamente, transmitida por correo postal 0 utilizando medios electrénicos, presentada en peli- culas 0 transmitida verbalmente en una conversacién. Cualquiera sea la forma que adquiera la informacién, 0 los medios por los cuales se distribuye 0 almacena, siempre debe estar protegida en forma adecuada, La seguridad de la informacién es la proteccién de la informacién de una amplia variedad de amena- zas, con el objeto de asegurar la continuidad del negocio, minimizar los riesgos y maximizar el retorno de la inversion y las oportunidades de negocio. La seguridad de la informacién se logra implementando un conjunto adecuado de controles, que in- cluye politicas, procesos, procedimientos, estructuras organizacionales y funciones del software y del hardware. Estos controles se deben establecer, implementar, supervisar, revisar y mejorar, cuando sea necesario, para garantizar que se alcancen los objetivos especificos de seguridad y los objetivos de negocio de la organizacién. Esto debe realizarse en conjunto con los otros procesos de la gestién del negocio. 0.2 ZPor qué es necesaria la seguridad de la informacion? Muchos sistemas de informacién no han sido disefiados para ser seguros. La seguridad que puede lograrse por medios técnicos es limitada y debe ser respaldada por una gestion y procedimientos adecuados. Se recomienda que la identificaci6n de los controles a ser implementados se planifique en forma cuidadosa y con atencién a todos los detalles. La gestién de la seguridad de la informacion requiere como minimo de la participacién de todos los empleados de la organizacién. Puede también requerir de la participacién de los accionistas, proveedores, terceras partes, clientes u otras partes externas. También puede necesitarse del asesoramiento especializado de organizaciones externas. 0.3 Cémo establecer los requerimientos de seguridad Una de las fuentes proviene de evaluar los riesgos que afronta la organizacién, teniendo en cuenta la estrategia global del negocio y los objetivos de la organizacién. Mediante la evaluacion de riesgos, seIRAM-ISO/IEC 27002:2008 identifican las amenazas a los activos, se evalian sus probabilidades de ocurrencia y las vulnerabili- dades y se estima el impacto potencial. 0.4 Evaluacién de los riesgos en materia de seguridad Los resultados de esta evaluacién ayudarén a orientar y a determinar la adecuada accion de la direc- cién y las prioridades para gestionar los riesgos concemnientes a la seguridad de la informacion y para implementar los controles seleccionados a fin de brindar proteccién ante dichos riesgos. Es conveniente que la evaluacién de los riesgos se repita periddicamente, para abarcar todos los cambios que podrian influenciar los resultados de dicha evaluacion, 0.5 Seleccién de los controles Una vez identificados los requerimientos de seguridad y los riesgos, y tomadas las decisiones para e! tratamiento de estos riesgos, es conveniente seleccionar e implementar los controles apropiados para garantizar que los riesgos se reduzcan a un nivel aceptable. Los controles se pueden seleccionar sobre la base de este documento, o de otro conjunto de controles, 0 se pueden disefiar nuevos controles para satisfacer necesidades especificas segiin coresponda. La seleccién de los controles de seguridad de- pende de las decisiones de la organizacién, basadas en los criterios de aceplacién de los riesgos, las opciones para el tratamiento de los riesgos, y la gestion general de riesgos aplicada por la organizacion, y es recomendable que dicha seleccién esté sujeta a todas las regulaciones y legislaciones nacionales e internacionales correspondientes. Aigunos controles de este documento pueden considerarse como principios guia para la gestién de la seguridad de la informacion, aplicables a la mayoria de las organizaciones. Se explican con mayor grado de detalle en el siguiente pérrafo, bajo el titulo de "Punto de partida para la seguridad de la in- formacion. 0.6 Punto de partida para la seguridad de la informacion Algunos controles pueden considerarse como un buen punto de partida para implementar la seguri- dad de la informacion, Estos estan basados en requerimientos legales fundamentales, o bien se consideran como una practica comin concemiente a la seguridad de la informacién. Los controles que se consideran necesarios para una organizacién, desde el punto de vista legal ‘comprenden, dependiendo de la legislacién aplicable: a) la proteccién de los datos y la privacidad de la informacién personal (véase 15.1.4); b) la proteccién de los registros de la organizacién (véase 15.1.3); ©) derechos de propiedad intelectual (véase 15.1.2) Estos controles que se consideran una practica comtin en la seguridad de la informacion incluyen: a) documentos de la politica de seguridad de la informacién (véase 5.1.1); b) _asignacién de las responsabilidades de seguridad de la informacion (véase 6.1.3); ©) concientizacién respecto de la seguridad de la informacién, educacién y capacitacion (véase 8.2.2); d) procesamiento correcto de las aplicaciones (véase 12.2); 10IRAM-ISO/IEC 27002:2008 €) _gestién de las vulnerabilidades técnicas (véase 12.6); f) gestion de la continuidad del negocio (véase 14); 9) _gestién de los incidentes y mejoras de la seguridad de la informacion (véase 13.2). Estos controles se pueden aplicar a la mayoria de las organizaciones y ambientes. 0.7 Factores criticos de éxito La experiencia ha demostrado que los siguientes factores a menudo resultan criticos para la imple- mentacién exitosa de la seguridad de la informacién dentro de una organizacion: a) politica de seguridad de la informacién, objetivos, y actividades que reflejen los objetivos del negocio; b) un enfoque y marco de trabajo para la implementacién, mantenimiento, seguimiento y control, y mejora de la seguridad de la informacién que sea consistente con fa cultura de la organizacién; ©) apoyo y compromiso comprobables de todos los niveles gerenciales; d) un claro entendimiento de los requerimientos de seguridad de la informacién, de la evaluacion de los riesgos y de la gestion de ésto: e) un efectiva promocién de la seguridad de la informacién dirigida a todos los gerentes, emplea- dos y otras partes interesadas, para fomentar la toma de conciencia; f) distribucién de guias sobre politicas y normas de seguridad de la informacién a todos los em- pleados y partes interesadas; 9) provisi6n de recursos para sustentar las actividades de la gestion de la seguridad de la infor- macion; h) promover la concientizacién apropiada, capacitacién y educacién; i) _establecimiento de un proceso efectivo de gestion de incidentes relacionados con la seguridad de la informacién; i) implementacién de un sistema de medicién" que se utilice para evaluar el desempefio de la ‘gestion de la seguridad de la informacion y para brindar sugerencias tendientes a mejorario. 0.8 Desarrollo de directrices propias Este cédigo de practica puede ser considerado como un punto de partida para el desarrollo de direc- trices especificas, aplicables a la organizacién. No todas las directrices y controles de este codigo de practica resultarén aplicables. Mas ain, es probable que puedan requerirse controles adicionales que no estén incluidos en este documento. Ante esta situacién puede resultar util incluir referencias cru- zadas que faciliten la realizacion de pruebas de cumplimiento por parte de auditores y socios. 1 OBJETO Esta norma establece directrices y principios generales para iniciar, implementar, mantener y mejorat la gestion de la seguridad de la informacién en una organizacion. Los objetivos sobresalientes en es- Se hace notar que las mediciones de la seguridad de la informacién estén fuera del alcance de esta norma. "1IRAM-ISO/IEC 27002:2008 ta norma proporcionan una guia general sobre los objetivos cominmente aceptados de la gestion de la seguridad de la informacion. Los objetivos de control y controles de esta norma deben ser implementados para satisfacer los re- querimientos identificados a través de la evaluacién de riesgos. Esta norma puede servir como una guia practica para elaborar normas de seguridad de la organizacion y para desarrollar practicas efec- tivas de la gestién de la seguridad, brindando asimismo, confianza en las actividades llevadas a cabo entre las organizaciones. 2 TERMINOS Y DEFINICIONES Allos efectos de este documento se aplican los siguientes términos y definiciones: 24 activo aquello que tiene valor para la organizacion [ISONEC 13335-1:2004] 22 control medio para gestionar el riesgo, incluyendo politicas, procedimientos, directrices, practicas o estructu- ras organizacionales, las cuales pueden ser de naturaleza administrativa, técnica, de gestion, 0 legal NOTA, Control es también utiizado como sinénimo de salvaguarda o de contramedida. 23 directriz tuna descripcién que clarifica qué es lo que se recomienda hacer, y como, para alcanzar los objetivos especificados en las politica, [ISONEC 13335-1:2004) 24 sstalaciones para el procesamiento de la informacion todo sistema de procesamiento de la informacion, servicio 0 infraestructura, o el lugar fisico donde se alojan 25 seguridad de la informacion preservacion de la confidencialidad, integridad y disponibilidad de la informacién: adicionaimente puede involucrar otras propiedades, tales como la autenticacién, la asignacién de responsabilidades, e11no repudio, y la confiabilidad 26 evento de seguridad de la informacién ‘suceso identificado en un sistema, servicio o estado de red que indica una posible brecha en la politi- ca de seguridad de la informacién o falla de salvaguarda, 0 una situacién previa desconocida que puede ser relevante en cuanto a seguridad [ISONEC TR 18044:2004] 2IRAM-ISO/IEC 27002:2008 27 incidente de seguridad de la informacién incidente de la seguridad de la informacién indicado por uno o una serie de eventos de seguridad de la informacion no deseados 0 no esperados que pueden tener una probabilidad significativa de com- prometer las operaciones del negocio y amenazar la seguridad de la informaci6n USO/EC TR 18044:2004] propésitos y directivas generales formaimente expresadas por la direcci6n 29 riesgo combinacién de la probabilidad de ocurrencia de un evento y sus consecuencias [ISONEC Guide 73:2002] 2.10 a de riesgo uso sistematico de la informacién para identificar fuentes y estimar el riesgo [ISOMEC Guide 73:2002] 2a evaluacién de riesgos (risk assessment) proceso global de anélisis de riesgos y valoracién de riesgos [ISOMEC Guide 73:2002] 212 valoracién de riesgos (risk evaluation) proceso de comparacién de los riesgos estimados con respecto a los criterios de riesgo establecidos para determinar la magnitud del riesgo [ISONEC Guide 73:2002] 2.13 gestion de riesgos actividades coordinadas para dirigit y controlar una organizacién en lo que concieme al riesgo NOTA. La gestiin de riesgos usuaimente incluye la evaluacién de riesgos, el tratamiento de riesgos, la aceptacion de ries- {0s y a comunicacin de rlesgos. [ISONEC Guia 73:2002} 2.14 tratamiento de riesgos proceso de seleccién e implementacién de medidas para modificar el riesgo {ISO/IEC Guia 73:2002] NOTA IRAM. Estas defniciones relacionadas al riesgo se corresponden con las definiciones de la norma IRAM 17550 Sistema de gestion de lesgos - Directvas generales. 245 tercera parte persona u organizacion que es reconocida como ente independiente de las partes involucradas, a la ‘cual le concierne el tema en cuestion [ISO/IEC Guide 2:1996] 13IRAM-ISO/IEC 27002:2008 2.16 amenaza una causa potencial de un incidente no deseado, el cual puede ocasionar dafios a un sistema u or- ganizacién {ISO/IEC 13335-1:2004] 247 vulnerabilidad una debilidad de un activo o grupo de activos que puede ser explotada por una amenaza. [ISONEC 13335-1:2004] 3 ESTRUCTURA DE ESTA NORMA Esta norma contiene 11 capitulos de controles de seguridad que comprenden un total de 39 catego- rias principales de seguridad y un capitulo introductorio acerca de la evaluacién de riesgos y su tratamiento. 3.1 Capitulos Cada capitulo contiene un numero de categorias principales de seguridad. Los once capitulos (acompafiados por el ntimero de categorias principales de seguridad incluidas en cada capitulo) son: a) Politica de seguridad (1); b)Organizacién de la seguridad de la Informacién (2); ©) Gestién de los activos (2); @) Seguridad de los recursos humanos (3); @) Seguridad fisica y ambiental (2); f)_ Gestién de las comunicaciones y de las operaciones (10); 9) Control de accesos (7); h) Adquisicién, desarrollo y mantenimiento de sistemas de informacién (6); i) Gestién de los incidentes de seguridad de la informacién (2); i) Gestién de la continuidad del negocio (1); Kk) Cumplimiento (3). bios puscon ser mporants: orto ano ae rcamienda gue aan orgenzaron que apique esa norma enue oo capitules aplicables, qué tan importantes son éstos y su aplicacion a los procesos de negocio individuales. Se hace notar {ue todo lo mencionado en esta norma no sigue un orden de prioridades, a menos que asi esté indicado. 3.2 Categorias pri ipales de seguridad Cada categoria principal de seguridad contiene: a) _un objetivo de contro! que indica lo que se tiene que lograr; y 4IRAM-ISO/IEC 27002:2008 b) uno 0 mas controles que se pueden aplicar para lograr el objetivo de control. Las descripciones de control se estructuran de la siguiente forma: Control Define la declaracion de control especifica para satisfacer el objetivo de control, Guia de implementacién Proporciona informacion mas detallada para dar soporte a la implementacién del control y alcanzar el objetivo de control. Algunos puntos de esta guia pueden no ser aplicables en todos los casos, por lo ‘cual podrian ser mas adecuados otros medios para implementar el control. Informacién adicional Proporciona informacion mas amplia que puede ser considerada, por ejemplo: consideraciones lega- les y referencias a otras normas. 4 EVALUACION Y TRATAMIENTO DE RIESGOS 4.1 Evalua in de los riesgos de seguridad Se recomienda que la evaluacion de riesgos identifique, cuantifique, y priorice los riesgos, en funcién de los criterios de aceptacién de riesgos y de los objetivos de control relevantes para la organizacién. Se recomienda que los resultados guien y determinen la apropiada accién de la direccién y las priori- dades para gestionar los riesgos de seguridad de la informacién y para la implementacién de controles seleccionados para protegerse contra estos riesgos. Puede ser necesario ejecutar mas de una vez el proceso de evaluacion de riesgos y la seleccién de los controles para cubrir diferentes par- tes de la organizacién o sistemas de informacion particulares. Es conveniente que dicha evaluacién incluya el enfoque sistemdtico de estimacién de la magnitud de los riesgos (analisis de riesgos) y el proceso de comparacién de los riesgos estimados contra los cri- terios de riesgo a fin de determinar la importancia de éstos (valoracién de riesgos). A su vez se recomienda efectuar la evaluacion de riesgos periédicamente, para tratar los cambios en los requerimientos de seguridad y en las situaciones de riesgo, por ejemplo: cambios producidos en activos, amenazas, vulnerabilidades, impactos, valoracién de riesgos. También se recomienda que se efectle la evaluacién cada vez que ocurran cambios significativos. Es conveniente que estas eva- luaciones de riesgos se tleven a cabo de una manera metédica capaz de producir resultados comparables y reproducibles. Se recomienda que la evaluacién de riesgos de seguridad de la informacién tenga un alcance defini- do para que sea efectiva y que incluya relaciones con las evaluaciones de riesgos en otras areas, si asi corespondiese El alcance de una evaluacién de riesgos puede incluir a toda la organizacién, partes de la organiza- cién, un sistema de informacién particular, componentes especificos de un sistema, 0 servicios, donde ésta sea factible, practica, y de ayuda. Los ejemplos de metodologias de evaluacién de ries- gos se indican en ISO/IEC TR 13335-3 Information Technology - Guidelines for the Management of IT Security: Techniques for the Management of IT Security. 5IRAM-ISO/IEC 27002:2008 4.2 Tratamiento de riesgos de seguridad Antes de considerar el tratamiento de un riesgo, es conveniente que la organizacion decida los crite- rios para determinar si los riesgos pueden, o no, ser aceptados. Los riesgos pueden ser aceptados si por ejemplo: se evalué que el riesgo es bajo 0 que el costo del tratamiento no es econémicamente viable para la organizacién. Se recomienda que tales decisiones se documenten debidamente. Para cada uno de los riesgos identificados durante la evaluacién de riesgos, se necesita tomar una decisién para su tratamiento. Las posibles opciones para el tratamiento de riesgos incluyen: a) la aplicacién de controles apropiados para reducir los riesgos; b) la aceptacién objetiva y conciente de los riesgos, siempre y cuando éstos satisfagan claramen- te la politica y los criterios de aceptacién de riesgos de la organizacién; ) el evitar los riesgos, no permitiendo acciones que podrian causar la ocurrencia de estos; 4) [a transferencia de los riesgos asociados a otras partes interesadas, por ejemplo: compafiias de seguro 0 proveedores. Para aquellos riesgos donde la decisién ha sido la de aplicar controles apropiados para su tratamien- to, se recomienda que estos controles se seleccionen @ implementen teniendo como objetivo alcanzar los requerimientos identificados por la evaluacién de riesgos. Se recomienda que los contro- les aseguren que los riesgos estén reducidos a un nivel aceptable, teniendo en cuenta lo siguiente: a) los requerimientos y restricciones de legistaciones y regulaciones nacionales e internacionales; b)__los objetivos organizacionales; ¢) los requerimientos y restricciones operativos; ) el costo de implementacion y operacién en relacién directa a los riesgos reducidos, y propor- cionales a los requerimientos y restricciones de la organizacion; e) la necesidad de equilibrar las inversiones en la implementacién y operacién de los controles contra el dafio que podria resultar de las fallas de seguridad Los controles pueden ser seleccionados de esta norma o de otro conjunto de controles, o se pueden establecer nuevos controles para satisfacer necesidades especificas de la organizacién. Es necesa- rio reconocer que algunos controles pueden no ser aplicables a todo sistema de informacion o a su ambiente, y podrian no ser aplicables en todas las organizaciones. Como ejemplo, el apartado 10.1.3 describe cémo podrian segregarse las responsabilidades para prevenir fraude y error. Puede no ser posible para las organizaciones mas pequefias segregar todas las responsabilidades y pueden ser necesarias otras vias para lograr el mismo objetivo de control. Como otro ejemplo, el apartado 10,10 describe cémo se puede controlar el uso del sistema y recolectar la evidencia. Los controles descrip- tos, por ejemplo: el registro de eventos, podria entrar en conflicto con legislaciones aplicables, como ser la proteccién de la privacidad de los clientes o en el lugar de trabajo. ‘Se recomienda que en la especificacién de los requerimientos de los proyectos o de los sistemas y en la etapa de disefio se consideren los controles de seguridad de la informacién. El fracaso en llevar a cabo estos controles puede ocasionar costos adicionales y soluciones menos efectivas, y quizas, en el peor de los casos, la imposibilidad de lograr la seguridad adecuada. Se recomienda que se recuerde que ningiin conjunto de controles puede alcanzar la seguridad abso- luta, y que se recomienda implementar una actividad gerencial adicional para hacer el sequimiento, control, evaluacion y mejorar la eficiencia y efectividad de los controles de seguridad que dan soporte a los objetivos de la organizacién. 16IRAM-ISO/EC 27002:2008 5 POLITICA DE SEGURIDAD 5.1 Politica de seguridad de la informacion Objetivo: Proporcionar direccién y apoyo de la alta direcoién para la seguridad de la informacién de} ‘acuerdo con los requerimientos de! negocio y las leyes y regulaciones correspondientes, Se recomienda que la alta direccién establezca una politica de direccién clara de acuerdo con los lobjetivos de! negocio y demuestre apoyo y compromiso con respecto a la seguridad de la informa- ‘cién, mediante la formulacién y mantenimiento de una politica de seguridad de la informacion ‘comin a toda la organizacién. 5.1.1 Documentacién de la politica de seguridad de la informa Control Se recomienda que los responsables de la alta direccién aprueben un documento que contenga la politica de seguridad de la informacién, lo publiquen y comuniquen a todos los empleados y a terceras partes relevantes. Guia de implementacién Se recomienda que el documento de la politiaa de seguridad de la informacion establezca el ‘compromiso de la alta direccion y el enfoque de la organizacién a la gestion de la seguridad de la informacién. Se recomienda que el documento de la politica contenga declaraciones relativas a: a) una definicién de seguridad de la informacién, sus objetivos y alcance generales y la importancia de la seguridad como un mecanismo que permita compartir la informacion (ver introduccién); b) una declaracién del propésito de los responsables de la alta direccién, en apoyo de las metas y principios de la seguridad de la informacion alineada con las estrategias y objetivos del negocio; ¢) un marco para establecer los objetivos de control y los controles asociados, incluyendo la es- tructura de evaluacién y gestién de riesgos; 4d) una breve explicacion de las politicas, principios, normas y requerimientos a cumplir en materia de seguridad, que son especialmente importantes para la organizacion, incluyendo: 1) _cumplimiento de requerimientos legales, regulatorios y contractuales; 2) los requerimientos de educacién, capacitacién y concientizacién respecto de la seguridad; 3) gestion de la continuidad del negocio; 4) consecuencias de las violaciones de la politica de seguridad de la informacién; e) una definicién de las responsabilidades generales y especificas en materia de gestion de la se- guridad de la informacion, incluyendo la comunicacién de los incidentes relativos a ésta; ) referencias a documentos que puedan respaldar la politica, por ejemplo: normas y procedi- mientos de seguridad mas detallados para sistemas de informacion especificos 0 reglas de seguridad que se recomienda que los usuarios cumplan. "7IRAM-ISO/IEC 27002:2008 Se recomienda que esta politica de seguridad de la informacion se comunique a través de la organi- zacion a los usuarios de manera pertinente, accesible y comprensible. Informacién adicional La politica de seguridad de Ia informacién podria ser una parte de un documento de la politica general. Si la politica de seguridad de la informacién se distribuye fuera de la organizacion, se recomienda tener cuidado de no divulgar informacién sensible. Para mas informacién ver la norma ISONEC 13335-1:2004. 5.1.2 Revi ién de la politica de seguridad de I Control Se recomienda que la politica de seguridad de la informacién se revise a intervalos planificados, o si curren cambios significativos para asegurar que continiia siendo conveniente, adecuada y efectiva. Guia de implementacién ‘Se recomienda que la politica de seguridad de la informaci6n tenga un propietario” al que se le asigne la responsabilidad gerencial para el desarrollo, revision y valoracién de la misma. Se recomienda que la revisiOn incluya la evaluacién de las oportunidades de mejora de ia seguridad de la informacién y el en- foque hacia la gestién de la seguridad de la informacion en respuesta a los cambios en el entoro de la organizacién, gestién de negocios, las condiciones legales o la infraestructura tecnologica. Se recomienda que la revisién de la politica de seguridad de la informacién tenga en cuenta los resul- tados de las revisiones de la alta direccién, asi como también que estén definidos los procedimientos de revision de la alta direccién, incluyendo una agenda o periodo de revisién. Se recomienda que las revisiones gerenciales incluyan informacién acerca de: a) retroalimentacién de las partes interesadas; b) resultados de revisiones independientes (ver 6.1.8); ©) estado de acciones correctivas y preventivas (ver 6.1.8 y 15.2.1); 4) resultados de revisiones previas realizadas por la direccién; ) _cumplimiento con ia politica de seguridad de la informacion y el desempeno del proceso; f) cambios que pueden afectar el enfoque de la organizacién hacia la gestion de la seguridad de la informacién, incluyendo cambios en el entorno organizacional, gestién de! negocio, disponibilidad de los recursos, condiciones contractuales, reglamentarias, y legales, o la infraestructura tecnolé- gica; 9) tendencias relacionadas con amenazas y vulnerabilidades; h)__incidentes informados sobre la seguridad de la informacién; i) recomendaciones provistas por autoridades relevantes (ver 6.1.6). 2) 1 término propietario identifica a un individuo o entidad que tiene probada responsabilidad de gestion para controlar la produccién, desarrollo, mantenimiento, uso y seguridad del activo. El término propietario no se refiere a que la persona Teaimente tiene aigin derecho de propiedad sobre el activo, 18IRAM-ISO/IEC 27002:2008 ‘Se recomienda que los informes de la revision por la direccién incluyan algunas decisiones y accio- nes para: a) mejorar el enfoque de la organizacién respecto de la seguridad de la informacion y sus procesos; b) mejorar los objetivos de control y los controles asociados; )_ mejorar la asignacién de recursos ylo responsabilidades. Se recomienda mantener un registro de la revisién por la direccién. Se recomienda que se obtenga la aprobacién de la alta direccién de la revisién de la politica. 6 ORGANIZACION DE LA SEGURIDAD 6.1 Organizacién Interna Objetivo: Gestionar la seguridad de la informacién dentro de la organizacién: ‘Se recomienda que se establezca un marco de gestién para iniciar y controlar la implementacion de la seguridad de la informacion dentro de la organizacién, Se recomienda que la alta direccién apruebe la politica de seguridad de la informacién, asigne fun- ciones de seguridad y coordine y revise la implementacién de la seguridad en toda la organizacion. Si resulta necesario, se recomienda que se establezca y esté disponible dentro de la organizacién, una fuente de asesoramiento especializado en materia de seguridad de la informacién. Se reco- mienda desarrollar contactos con especialistas externos en materia de seguridad, incluyendo las autoridades competentes, para estar al corriente de las tendencias de la industria, hacer un segui- miento de las normas y métodos de evaluacién y proveer puntos de enlace adecuados cuando se afrontan incidentes de seguridad. Se recomienda promover un enfoque multidisciplinario para la seguridad de la informacién. 6.1.1 Compromiso gerencial hacia la seguridad de la informacion Control Se recomienda que la alta direccién de soporte activo a la seguridad de la informacion dentro de la organizacién a través de una direccién clara, compromiso demostrado, asignacién ex} conocimientos de las responsabilidades de seguridad de la informacién Guia de implementacion Se recomienda que la atta direccion: a) asegure que los objetivos de seguridad de la informacion estan identificados, que cumplen con los requerimientos de la organizacién y que estan integrados en los procesos correspondientes; b) formule, revise, y apruebe la politica de seguridad de la informacién; ©) revise la efectividad de Ia implementacién de la politica de seguridad de la informacion; 19IRAM-ISO/IEC 27002:2008 d) provea una clara direccién y un soporte gerencial visible a las iniciativas de seguridad; ) provea los recursos necesarios para la seguridad de la informacion; f) apruebe la asignacién de roles especificos y responsabilidades para la seguridad de la informacién en toda la organizacion; 9) _nicie planes y programas para mantener la conclentizacion sobre la seguridad de la informacion; h) _asegure que la implementacién de los controles de seguridad de la informacion estan coordinados en toda la organizacién (ver 6.1.2). Se recomienda que la alta direccién identifique las necesidades por medio de especialistas internos 0 ‘externas a la organizacién, y revise y coordine los resultados de las recoendaciones a través de toda la organizacién. Dependiendo de la dimensién de la organizacion, tales responsabilidades podrian ser manejadas por un foro de direccién para ese fin o por un cuerpo de direccién existente, como ser la junta directiva. Informacién adicional Para mayor informacién ver ISO/IEC 13335-1:2004, 6.1.2 Coordinacién de la seguridad de la informacién Controt Se recomienda que las actividades de seguridad de la informacion se encuentren coordinadas por representantes de diferentes partes de la organizacién con roles y funciones de trabajo correspon- dientes. Guia de implementacién Normaimente, la coordinacién de la seguridad de la informacién involucra la cooperacién y la colabo- racién de directores, usuarios, administradores, disefiadores de aplicaciones, auditores y personal de seguridad y especialistas con capacidades en areas como temas legales, recursos humanos, TI o gestion de riesgos. ‘Se recomienda que esta actividad: a) asegure que las actividades de seguridad se ejecutan en cumplimiento con la politica de segu- ridad de la informacion; b)__identifique como manejar las no conformidades; ©) apruebe metodologias y procesos de seguridad de la informacion, por ejemplo: evaluacién de riesgos, clasificacion de la informacion; 4) identifique cambios significativos y las amenazas que estos producen en la exposicién de la in- formacién y en las instalaciones del procesamiento de la informacién; ) evaliie la adecuacién y coordine la implementacién de los controles de la seguridad de la in- formacion; f)_promueva en forma efectiva la educacién, entrenamiento y la concientizacion sobre la seguri- dad de la informacién a lo largo de fa organizacién; 20IRAM-ISO/IEC 27002:2008 9) _evalie la informacion recibida desde el seguimiento y la revisién de los incidentes de seguridad de {a informacién, y recomiende las acciones apropiadas en respuesta a los incidentes de se- guridad de la informacion identificados. Si la organizacién no posee un grupo multidisciplinario, por ejemplo: porque dicho grupo no es apro- piado para la dimension de la organizacién, se recomienda que las acciones descriptas anteriormente se leven a cabo por otro cuerpo de direccién conveniente, o por un director individual. 6.1.3 Asignacién de responsabilidades en mat de seguridad de la informa Control Es recomendable que se definan claramente todas las responsabilidades de la seguridad de la infor- macién. Guia de implementaci Se recomienda que la asignacién de las responsabilidades de la seguridad de la informacion se realice en conformidad con la politica de la seguridad de la informacion (ver capitulo 4). Es recomendable que se identifiquen claramente las responsabilidades por la proteccién de los activos individuales y por llevar a cabo procesos especifioos de seguridad. Se recomienda que se complement, cuando sea necesario, con una guia més detallada para sitios ¢ instalaciones especificos para el procesamiento de la infor- macién. Se recomienda que estén claramente definidas las responsabilidades locales para la proteccién de los activos y para llevar a cabo procesos de seguridad especificos, como ser la planificacion de la continuidad del negocio. Las personas que tienen asignadas responsabilidades de seguridad pueden delegar tareas de seguri- dad en otras personas. Sin embargo, ellos mantienen la responsabilidad y es conveniente que se compruebe que toda tarea delegada haya sido desempefiada correctamente. Es conveniente que se definan claramente las éreas de responsabilidad a cargo de los individuos; en Particular se recomienda lo siguiente: a) _identificar y definir claramente los activos y procesos de seguridad asociados con cada sistema particular; b) _asignar la entidad responsable por cada activo 0 proceso de seguridad y documentar los detalles de esta responsabilidad (ver también 7.1.2); ©) definir y documentar los niveles de autorizacién. Informacién adicional En muchas organizaciones, se designa a un administrador o gerente de seguridad de la informacién pa- ra tomar la responsabilidad total por el desarrollo e implementacion de la seguridad y para dar soporte a la identificacion de los controles. No obstante, la responsabilidad por la provisién de los recursos e implementacién de los controles, a menudo la mantendrén los responsables. Una practica comiin es designar a un propietario para cada activo, que se haga responsable de su proteccion en el dia a dia, aIRAM-ISO/IEC 27002:2008 iento de autorizacién para instalaciones de procesamiento de informacion 6.1.4 Proces Control Se recomienda establecer e implementar un proceso para autorizar nuevas instalaciones de proce- ‘samiento de la informacién. Guia de implementacién Se recomienda que se consideren las siguientes pautas para el proceso de autorizacion: a) que las nuevas instalaciones se aprueben adecuadamente por la direccién usuaria, autorizando Su propésito y uso, y ademas que también se obtenga la aprobacién del gerente responsable del mantenimiento del entorno de seguridad del sistema de informacién local, a fin de asegurar que se cumplen con todas las politicas y requerimientos de seguridad pertinentes; b) que cuando corresponda, se verifique el hardware y software para garantizar que son compati- bles con los componentes de otros sistemas; ©) que se identifquen los controles necesarios para el uso de recursos personales de procesa- miento de informacién, como por ejemplo: computadoras méviles (laptops), computadoras personales o de mano, para el procesamiento de la informacién del negocio, ya que podria in- ‘roducir nuevas vulnerabilidades. 6.1.5 Acuerdos de confidencialidad Controt Se recomienda que se identifiquen y revisen periédicamente los requerimientos de confidencialidad o acuerdos de no divulgacién que reflejen las necesidades de proteccién de la informacion de la orga- nizacion. Guia de implementacién Se recomienda que los acuerdos de confidencialidad 0 de no divulgacién abarquen los requerimien- tos de proteccién de la informacién confidencial usando téminos legales aplicables. Para identificar los requerimientos para los acuerdos de confidencialidad 0 de no divulgacién, se recomienda que se consideren los siguientes elementos: a) _una definici6n de la informacién a ser protegida (por ejemplo: informacion confidencial); ») duracién esperada de un acuerdo, incluyendo casos donde la confidencialidad podria mante- nerse indefinidamente; ©) _acciones requeridas cuando un acuerdo finaliza ; 4) responsabilidades y acciones de las partes firmantes para evitar la divulgacién no autorizada de la informacién; €) propiedad de la informacién, secretos comerciales y propiedad intelectual, y su relacién con la proteccién de la informacién confidencial; f) el uso permitido de informacién confidencial, y los derechos de las partes firmantes para usar la informaci6n; 9) el derecho para auditar y supervisar actividades que involucren informacién confidencial; h) _procesos de notificacién e informe de la divulgacién no autorizada o de violaciones de la confi- dencialidad de la informacién; 22IRAM-ISO/IEC 270022008 i) _términos para que la informacién se devuelva o destruya al finalizar el acuerdo; y })_acciones esperadas a llevarse a cabo en caso de incumplimiento de este acuerdo. Basandose en los requerimientos de seguridad de una organizacién, pueden llegar a ser necesarios otros elementos en los acuerdos de confidencialidad o de no divulgacién Se recomienda que los acuerdos de confidencialidad y de no divulgacién cumplan con todas las le- yes y regulaciones aplicables para la jurisdiccién en la cual se apliquen (ver también 15.1.1). Se recomienda que los requerimientos para los aouerdos de confidencialidad y no divulgacién se revisen periédicamente, asi como también cuando ocurran cambios que influyan sobre dichos requerimientos, Informacién adicional Los acuerdos de confidencialidad y no divulgacién protegen la informacién de la organizacién e in- forman a las partes firmantes sobre su responsabilidad de proteger, utilizar y revelar la informacion de una manera responsable y autorizada. En distintas circunstancias, podria llegar a existir la necesidad que la organizacién utilice diferentes formas de acuerdos de confidencialidad o de no divulgacién. 6.1.6 Contacto con autoridades Control Se recomienda que se mantengan contactos apropiados con las autoridades pertinentes. Guia de implementacién Se recomienda que las organizaciones tengan procedimientos que especifiquen cuando y a qué au- toridades contactar (por ejemplo: responsables legales, departamento de bomberos, supervisores) y cémo reportar oportunamente los incidentes de seguridad de la informacién identificados, de una manera oportuna, si se sospecha que se ha infringido la ley. Las organizaciones que estén bajo ataque a través de Internet pueden necesitar de terceras partes (por ejemplo: de un proveedor de servicios de Internet o de un operador de telecomunicaciones) para tomar accién contra la fuente del ataque. Informacién adicional Mantener estos contactos puede ser un requerimiento para dar soporte a la gestion de incidentes de seguridad de la informacion (13.2) 0 al proceso de planificacién de contingencias y de la continuidad del negocio (14). Los contactos con entidades regulatorias son también utiles para anticiparse y pre- pararse para futuros cambios en leyes o regulaciones, los que tienen que ser seguidas por la organizacion. Los contactos con otras autoridades incluyen empresas de servicios piblicos, servicios de emergencias, salud y seguridad, por ejemplo: el departamento de bomberos (en relacién con la continuidad de! negocio), los proveedores de telecomunicaciones (en relacién con la disponibilidad y el enrutamiento de lineas), los proveedores de agua (en relacién con las instalaciones de refrigera- cién del equipamiento). 6.1.7 Contacto con grupos de interés especial Control Se recomienda que se mantenga los contactos adecuados con grupos de interés especial u otras asociaciones de profesionales y foros de especialistas en seguridad. 23IRAM-ISO/IEC 27002:2008 Guia de implementacién A Se recomienda que se considere la ser miembros de grupos de interés especial o foros como un me- dio para: a) mejorar el conocimiento acerca de las mejores practicas y mantenerse actualizado acerca de la informacién de seguridad pertinent b) asegurar que el entendimiento del entorno de seguridad de la informacién esté actualizado y completo; c) recibir mensajes de alerta temprana, avisos de precaucién, y parches (ver nota IRAM) para pre- venir ataques y vulnerabilidade: d) obtener el acceso a asesoramiento de especialistas en seguridad de la informacién; ©) compartir e intercambiar informacion acerca de nuevas tecnologias, productos, amenazas o vulnerabilidades; f) prover puntos de enlace adecuados cuando se trate con incidentes de seguridad de la infor- macién (ver también 13.2.1). Informacién adicional Se pueden establecer acuerdos para compartir informacién con el objeto de mejorar la cooperacién y la coordinacién de los temas de seguridad. Se recomienda que tales acuerdos identifiquen requer'- mientos para la proteccién de la informacion sensible. NOTA IRAM. Parche es una seccién de cédigo que se introduce en un programa para sustituir cbdigos erréneas, agregar funcionalidad al programe, aplicar una actualizacion, etc 6.1.8 Revision independiente de la seguridad de la informacion Control! Se recomienda que el enfoque de la organizacion para la gestion de la seguridad de la informacion y su implementacién (por ejemplo: objetivos de control, controles, politicas, procesos y procedimientos para la seguridad de la informacién) se revise en forma independiente a intervalos planificados o cuando ocurran cambios significativos en la implementacion de la seguridad. Guia de implementacién Se recomienda que la revisién independiente se inicie por la alta direcci6n. Esta revisién indepen- diente es necesaria para asegurar una correcta continuidad, adecuacién y efectividad del enfoque de la organizaci6n para administrar la seguridad de la informacién. Se recomienda que la revisién inclu- ya la evaluacién de las oportunidades de mejora y la necesidad de cambios en el enfoque de la seguridad, incluyendo la politica y los objetivos de control. Se recomienda que esta revisién se lleve @ cabo por personas independientes del area bajo revisién, Por ejemplo: para la funcién de auditoria interna, un gerente independiente o una tercera parte espe- cializada en tales revisiones. Se recomienda que las personas que lleven a cabo estas revisiones posean las capacidades y la experiencia adecuadas. ‘Se recomienda que los resultados de la revision independiente se registren e informen a la direccién que inicié la revision y que se mantengan estos registros. ‘Se recomienda que la alta direccién considere acciones correctivas en caso de que la revision inde- Pendiente identifique que el enfoque de la organizacion para gestionar la seguridad de la informacionIRAM-ISO/IEC 27002:2008 y su implementacion es inadecuado 0 no cumple con las directivas para la seguridad de la informa- cién establecida en el documento de la politica de seguridad de la informacién (ver 5.1.1). Informacién adicional El area que se recomienda que se revise periédicamente por los directores (ver 15.2.1), también puede revisarse en forma independiente. Las técnicas de revisién pueden incluir entrevistas con la di- recoién, la verificacién de los registros o la revisién de los documentos de la politica de seguridad. La IRAM-ISO 19011, Directrices para la auditoria de los sistemas de gestion de la calidad y/o ambiental, también puede proporcionar una guia de ayuda para llevar a cabo la revision independiente, inclu- yendo el establecimiento e implementacién de un programa de revision. El apartado 15.3 especifica ios principales controles para la revision independientes de los sistemas de informacion operaciona- les y el uso de las herramientas de auditoria de sistemas. 6.2 Terceras Partes Objetivo: Mantener la seguridad de la informacion de la organizacion y las instalaciones de proce- samiento de informacion que son accedidas, procesadas, comunicadas o gestionadas por terceras partes. Se recomienda que la seguridad de la informacién de la organizacién y de las instalaciones de pro- cesamiento de informacién no se vean afectadas por la introduccién de productos o servicios de terceras partes. Se recomienda que se controle cualquier acceso de terceras partes a las instalaciones, al procesa- miento 0 a la comunicacién de la informacién de la organizaci6n. En caso de que exista una necesidad de negocio de trabajar con terceras partes que pueda requerir el acceso a la informacién de a organizacién y a las instalaciones de procesamiento de la informa- ién, 0 en el caso de la obtencién o provision de un producto o servicio de, o para una tercera parte, ‘se recomienda que se realice una evaluacién de riesgos para determinar las implicancias de seguri- dad y los requerimientos de control; asimismo que se establezcan y definan en un acuerdo con la tercera parte. 6.2.1 Identificacién de riesgos relacionados con las terceras partes, Control Se recomienda que se identifiquen los riesgos para la informacién de la organizacién y para las insta- laciones de procesamiento de la informacién de los procesos de negocios que involucren terceras partes, y que se implementen los controles apropiados antes de conceder el acceso. Guia de implementacion Cuando existe la necesidad de permitir el acceso a una tercera parte a las instalaciones de procesa- miento de la informacién o a la informacion de la organizacién, se recomienda que se lieve a cabo una evaluacién de riesgos (ver también capitulo 4) a fin de identificar los requerimientos de controles especificos. ‘Se recomienda que la identificacién de los riegos relacionados con el acceso de terceras partes ten- ga en cuenta los puntos siguientes: 1a) las instalaciones de procesamiento de la informacion a las cuales una tercera parte requiere acceder; 25IRAM-ISO/IEC 27002:2008 b) el tipo de acceso de las terceras partes sobre la informacion y las instalaciones de procesamiento de la informacion, por ejempio: 1. acceso fisico (a oficinas, salas de cmputos, armarios, etc.); 2. acceso légico (a las bases de datos, sistemas de informacién de la organizacién, etc.); 3. la conectividad de redes entre la(s) red(es) de la organizacion y de terceras partes (conexién permanente, acceso remoto, etc); 4, tener en cuenta si el acceso se esta llevando a cabo dentro o fuera del lugar; ©) el valor y la sensibilidad de la informacién involucrada, y su criticidad para las operaciones de negocios; 4) os controles necesarios para proteger la informacion que no ha sido prevista que sea accesible por terceras partes; ) el personal de la tercera parte involucrada en el acceso a la informacion de la organizacién; f) el modo de identificacién de la organizacién o del personal autorizado a tener acceso, la verificacién de la autorizacién y la frecuencia con que ésta necesita ser reconfirmada; @) los diferentes medios y controles utilizados por las terceras partes cuando almacenan, procesan, comunican, comparten ¢ intercambian informacién; h)_ @1 impacto resultante frente a la no disponibilidad del acceso de las terceras partes cuando se requiera, o que la tercera parte reciba informacién inexacta 0 engafiosa; i) précticas y procedimientos para tratar con incidentes de seguridad de la informacién y datos otenciales, y los términos y condiciones para la continuidad del acceso de terceras partes en el caso de un incidente de seguridad de la informacién; i) requerimientos legales y regulatorios y otras obligaciones contractuales correspondientes a las terceras partes que es recomendable que se tengan en cuenta; k) _cémo pueden estar afectados los intereses de alguna otra parte interesada por los acuerdos. Se recomienda que no se otorgue acceso a la informacién de la organizacion a terceras partes antes de implementar los controles apropiados, y cuando sea factible, se firme un contrato definiendo los términos y las condiciones para la conexién 0 acceso y el acuerdo de trabajo. Generalmente, en un acuerdo con jas terceras partes se ven reflejados todos los requerimientos de seguridad resultantes de trabajar con terceros y los requerimientos de los controles internos (ver 6.2.2 y 6.2.3) Se recomienda que la organizacién se asegure de que la tercera parte esta consciente de sus obligaciones, y que acepta las responsabilidades y las obligaciones involucradas en el acceso, procesamiento, comunicacién, o manejo de la informacién de la organizacién y las instalaciones de procesamiento de la informacién. Informacién adicional Con una inadecuada administracién de la seguridad, la informacion podria ser puesta en riesgo por las terceras partes. Se recomienda que los controles se identifiquen y apliquen para administrar el acceso or terceras partes a las instalaciones de procesamiento de la informacién. Por ejemplo, si hay una ecesidad especial de confidencialidad de la informacién, podrian ser utilizados acuerdos de no divulgacién 26IRAM-ISO/IEC 27002:2008 Si se aplica un alto grado de tercerizacién, 0 hay muchas terceras partes involucradas, las organizaciones podrian enfrentar los riesgos asociados con los procesos, la administracion y la ‘comunicacién interorganizacionales. Los controles 6.2.2 y 6.2.3 cubren diferentes acuerdos de terceras partes. Incluyen por ejemplo: a) proveedores de servicio, como los proveedores de servicios de Intemet, proveedores de redes, de servicios telefénicos, servicios de mantenimiento y de soporte; b) servicios de seguridad gestionados; ©) clientes; d) tercerizacién de instalaciones y/o operaciones, por ejemplo: sistemas de TI, servicios de recoleccién de datos, operaciones de centro de atencién telefénica; ) consultores y auditores de gestion y del negocio; 1) desarrolladores y proveedores, por ejemplo: productos de software y sistemas de TI; 4) _limpieza, provisi6n de alimentos, y otros servicios de soportes tercerizados; h) personal provisorio, estudiantes que realizan pasantias, y otras designaciones no formales a corto plazo. Tales acuerdos pueden ayudar a reducir los riesgos asociados con terceras partes. 6.2.2 Asignacién de seguridad cuando se trata con clientes, Controt Se recomienda que se aclaren todos los requerimientos de seguridad identificados antes de otorgarles a los clientes el acceso a la informacién o a los activos de la organizacion. Guia de implementacién Se tecomienda que se consideren los términos indicados a continuacién para tratar la seguridad antes de otorgar acceso a los clientes @ cualquiera de los activos de la organizacién (dependiendo del tipo y la extensién del acceso dado, no todos ellos podrian aplicarse) a) _proteccién de actives, que contengan: 1) procedimientos para proteger los activos de la organizacién, incluyendo informacién y software, ylla gestion de vulnerabilidades conocidas; 2) procedimientos para determinar si se han visto comprometidos los activos, por ejemplo si ha cocurrido pérdida o modificacién de datos; 3) integridad; 4) restricciones para copiar y divulgar informacion; b) _descripcién del producto o servicio a ser provisto; ) [as diferentes razones, requerimientos, y beneficios para el acceso de clientes; aIRAM-ISO/IEC 27002-2008 4) politica de control de acceso, que contemple: 1) métodos de acceso permitidos, y el control y uso de identificadores unicos tales como identificadores de usuarios (‘user ID") y contrasefias; 2) proceso de autorizacion para el acceso y privilegios de usuarios; 3) clausula que determine que todo acceso que no esté explicitamente autorizado, esta prohibido; 4) proceso para la revocacién de derechos de acceso o para la interrupoién de la conexién entre sistemas; ©) acuerdos para reportar, notificar, e investigar las inexactitudes de informacién (por ejemplo: detalles personales), incidentes de seguridad de la informacién y brechas de seguridad; f) una descripcién de cada servicio que esta disponible; @) el nivel de servicio esperado y los niveles inaceptables; h) el derecho de seguir, controlar, y revocar, cualquier actividad relacionada con los activos de la organizacién; i) las obligaciones respectivas de la organizacion y del cliente; j) _responsabilidades en materia legal y c6mo se asegura que se cumpian los requerimientos legales, por ejemplo: legislacién de proteccién de datos, especialmente teniendo en cuenta diferentes sistemas legales nacionales si e! acuerdo involucra cooperacién con clientes en otros paises (ver también 15.1); k) derechos de propiedad intelectual (DPI) y asignacién de derechos de autor (ver también 15.1.2) y la proteccién de cualquier trabajo en colaboracién. (ver también 6.1.5). Los requerimientos de seguridad relacionados con los clientes que acceden a activos de la organizacién pueden variar considerablemente, dependiendo de las instalaciones de procesamiento de informacion y de la informacion que es accedida. Tales requerimientos de seguridad pueden ser establecidos utilizando acuerdos con los clientes, los cuales contienen todos los riesgos y los requerimientos de seguridad (ver 6.2.1) Los acuerdos con terceras partes también pueden involucrar a otras partes. Se recomienda que los acuerdos que concedan acceso a terceras partes incluyan permisos para la designacién de otras partes deseables y las condiciones para su acceso e involucramiento. 6.2.3 Asignacién de la seguridad en acuerdos con terceras partes Control Se recomienda que los acuerdos con terceras partes que involucren el acceso, procesamiento, ‘comunicaci6n o gestion de la informacion de la organizacién o de las instalaciones de procesamiento de la informacion, 0 el agregado de productos o servicios a las instalaciones de procesamiento de informacién, cubran todos los requerimientos de seguridad correspondientes. Guia de implementacién ‘Se recomienda que el acuerdo asegure que no existan ambigledades entre la organizacién y la tercera parte. Se recomienda que las organizaciones queden satisfechas respecto de la indemnizacién de las terceras partes.IRAM-ISO/IEC 27002:2008 Se recomienda que se consideren los siguientes términos para su inclusién en el acuerdo, a fin de satisfacer los requerimientos de seguridad identificados (ver 6.2.1): a) b) ¢) ¢) e) 9 » i la politica de seguridad de la informacion; los controles que aseguren la proteccién de los actives, que incluyan: 41) procedimientos para proteger los activos de la organizacién, incluyendo informacion, software y hardwat 2) cualquier control o mecanismo de proteccién fisica requerido: 3) controles para asegurar la protecci6n en contra de software maligno (ver 10.4.1): 4) procedimientos para determinar la ocurrencia de hechos (por ejemplo: si ha ocurrido pérdida o modificacién de la informacién, software y hardware) sobre cualquiera de los activos ‘comprometidos; 5) los controles para asegurar el retomo 0 destruccién de la informacién y los activos al final del acuerdo, 0 en un punto establecido en el tiempo, durante el acuerdo; 6) confidencialidad, integridad, disponibilidad, y cualquier otra propiedad relevante de los activos (ver 2.1.5); 7) restricciones en cuanto a copiar y divulgar informacion, y usar acuerdos de confidencialidad (ver 6.1.5); entrenamiento de usuarios y administradores en métodos, procedimientos y seguridad; asegurar la concientizacion de usuarios hacia las responsabilidades y temas de la seguridad de la informacién; provision para la transferencia del personal, en aquellos casos en que se lo considere apropiado; responsabilidades con respecto al mantenimiento e instalacién de hardware y software; Una estructura de reporte clara y formatos de reporte acordados; Un proceso claro y especificado de gestion de cambios; una politica de control de acceso, que incluya: 1) las diferentes razones, requerimientos, y beneficios que hacen necesario al acceso por la tercera parte; 2) métodos de acceso permitidos, y el control y uso de identificadores Unicos tales como identificadores de usuarios (‘user ID") y contraseftas; 3) un proceso de autorizacién para acceso de usuario y privilegios; 4) un requerimientos para mantener una lista de individuos autorizados para utilizar los servicios, que estén disponibles y cuales son sus derechos y privilegios con respecto a su uso; 5) una deciaracién que especifique que todo acceso que no esté explicitamente autorizado esta prohibido; 6) un proceso para la revocacién de derechos de acceso 0 la interrupcién de la conexién entre sistemas; acuerdos para el reporte, notificacién, e investigacién de incidentes de la seguridad de la informacion y rupturas de la seguridad, asi como también violaciones de requerimientos ‘especificados en el acuerdo; 29IRAM-ISO/IEC 27002:2008 k) una deseripcién del producto o servicio que se va a prover, y la descripcién de la informacién que se halle disponible asi como su clasificacion de seguridad (ver 7.2.1); }) elnivel de servicio al que se apunta y los niveles inaceptabies de servicio; m) a definicion de criterios verificables de desempefio, su seguimiento, control y reporte; n) el derecho a seguir, controlar, y revocar, cualquier actividad relacionada con los activos de la organizacién; ©) el derecho a auditar las responsabilidades definidas en el acuerdo, para que esas auditorias sean llevadas a cabo por una tercera parte, y para enumerar los derechos de los auditores establecidos en los estatutos; p) el establecimiento de un proceso escalonado para la resolucién de problemas; @) requerimientos de continuidad del servicio, inciuyendo medidas para la disponibilidad y la confiabilidad, en concordancia con las prioridades del negocio de la organizacién; 1) las obligaciones respectivas de las partes hacia el acuerdo; s) las responsabilidades en materia legal y cémo se asegura ef cumplimiento de los requerimientos legales (por ejemplo legislacién de proteccién de datos) especialmente teniendo en cuenta los sistemas legales de diferentes naciones si el acuerdo envuelve la cooperacién con organizaciones ‘en otros paises (ver también 15.1); 1) los derechos de propiedad intelectual (DPI) y asignacién de los derechos de reproduccion (oopyright’) (ver 15.1.2) asi como la proteccién de cualquier trabajo en colaboracién (ver también 6.1.5); ) el involucramiento de la tercera parte con subcontratistas, y los controles de seguridad que estos subcontratistas necesitan implementar, v) las condiciones para la renegociaciéniterminacién de los acuerdos; 1) se recomienda adoptar un plan de contingencia en caso de que alguna de las partes quisiera terminar la relacién antes del final del acuerdo; 2) renegociacién de los acuerdos si cambian los requerimientos de seguridad de la organizacién; 3) documentacién actualizada de la lista de activos, licencias, acuerdos 0 derechos relacionados con ellos, Informacién adicional Los acuerdos pueden variar considerablemente para organizaciones diferentes y entre diferentes tipos de terceras partes. Por consiguiente, se recomienda que se tenga cuidado al incluir en los acuerdos todos los riesgos identificados y los requerimientos de seguridad (ver 6.2.1). Cuando sea necesario, los controles y los procedimientos requeridos se pueden extender en un plan de gestién de la seguridad Si la gestién de la seguridad de la informacién se terceriza, es recomendable que los acuerdos determinen cémo la tercera parte garantizara una adecuada seguridad, como ser la definida en la evaluacién de riesgos, cémo seré mantenida y adaptada la seguridad para identificar y manejar los ambios en los riesgos. Algunas de las diferencias entre la tercerizacién y otras formas de provisién de servicios de terceras partes incluyen el tema de la confiabilidad, la planificacién del periodo de transicién e interrupcion otencial de operaciones durante este periodo, los acuerdos de planificacién de contingencias, y de las 30IRAM-ISO/IEC 27002:2008 debidas diligencia de revisién, asi como la recoleccién y la gestién de los incidentes de la seguridad de ta informacion. Por lo tanto, es importante que la organizacion planifique y administre la transicion a un acuerdo de tercerizacion y tenga establecidos procesos adecuados para manejar los cambios y la renegociaciOn o terminacién de los acuerdos. Es necesario considerar en el acuerdo los procedimientos para el procesamiento continuo para evitar cualquier demora en el arregio de servicios de reempiazo en el caso de que la tercera parte se declare incapaz de prover sus servicios. Los acuerdos con terceras partes pueden incluir a otras partes. Se recomienda que los acuerdos que otorguen el acceso a terceras partes incluyan permiso para la designacién de otras partes elegibles y las condiciones para su acceso e involucramiento. Generalmente los acuerdos son desarrollados por la organizacion. Pueden existir ocasiones en algunas circunstancias donde un acuerdo puede ser desarroliado e impuesto a la organizacion por una tercera parte. La organizacién necesita asegurar que su propia seguridad no es impactada innecesariamente por los requerimientos, estipulados en los acuerdos impuestos por la tercera parte. 7 GESTION DE ACTIVOS 7.1 Responsabilidad por los activos Objetivo: Alcanzar y mantener una adecuada proteccién de los activos de la organizacién. Se recomienda que se identifique a los propietarios de todos los activos y que se asigne la respon-| sabilidad del mantenimiento de los controles apropiados. La implementacién de controles| especificos puede ser delegada por el propietario cuando sea apropiado, pero el propietario conti-| tia siendo responsable por la correcta proteccién de los activos. 7.1.1 Inventario de activos Controt ‘Se recomienda que se identifiquen claramente todos los actives y que se realice y mantenga un in- ventario de los activos mas importantes. Guia de implementacion Se recomienda que la organizacién identifique todos los activos y documente su importancia. Se re- comienda que el inventario de activos incluya toda la informacion necesaria para poder recuperarse frente a un desastre, incluyendo el tipo de activo, formato, ubicacién, informacion de copia de seguri- dad, informacion de la licencia, y un valor de negocio. Se recomienda que el inventario no duplique otros inventarios de forma innecesaria, pero es conveniente que se asegure que su contenido se en- cuentra alineado, Asimismo, se recomienda que la propiedad (ver 7.1.2) y la clasificacién de la informacién (ver 7.2), se encuentre acordada y documentada para cada uno de los activos. Basado en la importancia de los activos, su valor para el negocio y su clasificacién de seguridad, se recomienda que se identifiquen niveles de proteccién de acuerdo con la importancia del activo (para mayor informacién sobre como valorizar los activos para representar su importancia se puede encontrar en ISO/IEC TR 13335-3). 4IRAM-ISO/IEC 27002:2008 Informacién adicional Existen muchos tipos de activos, que incluyen: a) informacion: bases de datos y archivos de datos, contratos y acuerdos, documentacion de siste- mas, informacion de estudios, manuales de usuario, material de entrenamiento, procedimientos operacionales 0 de soporte, planes para la continuidad del negocio, disposiciones relativas a sis- temas de emergencia para la reposicién de informacién perdida (fallback’), pistas de auditorias, € informacién archivada; b) activos de software: software de aplicaciones, software de sistemas, herramientas de desarro- llo, y utiltarios; ©) activos fisicos: equipamiento de computacién, equipamiento de comunicaciones, medios remo- vibles y otros equipamientos; d) servicios: servicios de cémputo y de comunicaciones, servicios generales, por ejemplo: cale- faccién, iluminacién, energia, y aire acondicionado; e) personas, y sus calificaciones, capacidades y experiencia; f) _activos intangibles, tales como la reputacién y la imagen de la organizacién. Los inventarios de activos ayudan a asegurar que se lleva a cabo una efectiva proteccién de los acti- vos, y puede también ser requerido para otros propésitos de negocio, tales como de salud y seguridad, de aseguramiento 0 financiacién (gestion de activos). El proceso de armado de un inven- tario de activos es un importante prerrequisito de una gestion de riesgos (ver también capitulo 4). 7.1.2 Propiedad de los activos Control Se recomienda que toda la informacién y los activos asociados con las instalaciones de procesa- miento de la informacién sean de propiedad de una parte designada de la organizacién. Guia de implementacion ‘Se recomienda que el propietario de un activo se haga responsable de: a) asegurar que la informacién y los activos asociados con las instalaciones de procesamiento de la informacion estén apropiadamente clasificados; b) definir y revisar periédicamente las restricciones y clasificaciones de acceso al activo, teniendo en cuenta las politicas de control de acceso aplicables, La propiedad podrian asignarse a a) _un proceso de negocios; b) un conjunto definido de actividades; ©) una aplicacién; 0 4) un conjunto de datos definido. Informacién adicional Las tareas de rutina pueden ser delegadas, por ejemplo, se da a un empleado de seguridad la custo- dia de un activo en forma diaria, aunque la responsabilidad le pertenezca al duefto,IRAM-ISO/IEC 27002:2008 En sistemas de informacién complejos puede resultar itl designar grupos de activos, los cuales actuan juntos para prover una funcién particular como "servicios". En este caso, el propietario del servicio es responsable por la prestaci6n del servicio, incluyendo el funcionamiento de los activos que lo proven. 7.1.3 Uso aceptable de los activos Control Se recomienda que se identifiquen, documenten e implementen reglas para el uso aceptable de la in- formacién y de los activos asociados con las instalaciones de procesamiento de la informacion Guia de implementacién Es conveniente que todos los empleados, contratistas y usuarios de terceras partes sigan las reglas para el uso aceptable de la informacién y de los activos asociados con las instalaciones de procesa- miento de ésta, incluyendo: a) _reglas para el uso del correo electronico e Internet (ver 10.8); b) guias para el uso de dispositivos méviles, especialmente para el uso fuera del establecimiento © instalaciones de la organizacién (ver 11.7.1). Es recomendable que las reglas especificas asi como las g petente. 3S sean provistas por la direccién com- Se recomienda que se concientice a los empleados, contratistas y usuarios de terceras partes que uusen 0 tengan acceso a los activos de la organizacion, de los limites existentes sobre la utilizacion de la informacién de la organizacién y de los activos y/o recursos asociados con las instalaciones de procesamiento de la informacién Se recomienda que ellos se responsabilicen por la utilizacién de la informacién de la organizacion, como asi también por el uso de los activos y/o recursos asociados con las instalaciones de procesa- miento de la informaci6n: 7.2 Clasificacin de la informacién Objetivo: Garantizar que la informacién reciba un apropiado nivel de protecoién. Se recomienda que se clasifique la informacién, para indicar la necesidad, las prioridades, y el gra- do de proteccién esperado para cuando se trabaje con ella La informacién tiene grados diversos de sensibilidad y oriticidad. Algunos items pueden requerir un ni- [vel de protecci6n adicional o un tratamiento especial. Se recomienda que se utlice un esquema de lasificacién de la informacion para definir un conjunto apropiado de niveles de proteccién adecuados y para comunicar la necesidad de la implementacion de medidas especiales para su manejo. 7.24 Directrices para la clasificacion Control Es conveniente que la informacion se encuentre clasificada en términos de su valor, requerimientos legales, sensibilidad, y la crticidad para la organizacion. 33IRAM-ISO/IEC 27002:2008 Guia de implementacion Se recomienda que la clasificacién y controles de proteccién asociados a la informacién tengan en cuenta las necesidades especificas de! negocio para compartir o restringir informacién y los impactos asociados a tales necesidades. Es conveniente que las directrices para la clasificacion incluyan pautas para la clasificacién inicial y la reclasificacién a través del tiempo, en concordancia con una politica de control de acceso predeterminada (ver 11.1.1). Se recomienda que el propietario del activo (ver 7.1.2) se responsabilice por definir su clasificacion, la revise periédicamente, y asegure que se mantiene actualizada y en el nivel apropiado. Es conveniente que la Clasificacién tenga en cuenta el efecto de agregacion mencionado en 10.7.2. Se recomienda que se establezcan consideraciones sobre el numero de categorias de clasificacion y sobre los beneficios que se obtendran de su uso. Esquemas demasiado complejos pueden volverse ‘engorrosos, impracticos 0 econémicamente no viables. Es conveniente que se tenga cuidado al interpretar los rétulos de clasificacién de los documentos de otras organizaciones, las cuales pueden tener definiciones diferentes para r6tulos iguales o similares, Informacién adicional EJ nivel de proteccién puede determinarse analizando la confidencialidad, integridad y disponibilidad y cualquier otro requerimiento para la informacién considerada. Con frecuencia la informacion deja de ser sensible o critica después de un cierto periodo de tiempo, por ejemplo cuando la informacion se hace pibblica. Se recomienda que éstos aspectos se consideren, ya que la sobreciasificacién puede conducir a la implementacién de controles innecesarios que resultan en tun gasto adicional. ‘Cuando se asignan niveles de clasificacién, el tratamiento de documentos con similares requisitos de seguridad en forma conjunta, facilta la tarea de clasificacién. En general, la clasificacién dada a la informacion es una forma répida de determinar el modo en que tiene que ser manejada y protegida. 7.2.2 Rotulado y manejo de la informacién Control! Se recomienda que se desarrolle e implemente un apropiado conjunto de procedimientos para rotular y manipular la informacion, en concordancia con el esquema de clasificacién adoptado por la organi- zacién. Guia de implementacion Los procedimientos para el rotulado de la informacién necesitan abarcar los activos de informacién en formato fisico y electrénico. Se recomienda que la salida de los sistemas que contienen informacién clasificada como sensible 0 critica, leven un adecuado rotulo de clasificacién (en la salida). Es conveniente que el rotulado refleje la clasificacién de acuerdo con las reglas establecidas en 7.2.1. Los elementos a considerar incluyen reportes impresos, pantallas, medios grabados (por ejemplo cintas magnéticas, discos, CD), mensa- jes electrénicos, y transferencia de archivos.IRAM-ISO/IEC 27002:2008 Es recomendable que se definan para cada nivel de clasificacién, procedimientos de manejo que in- cluyan el procesamiento seguro, almacenamiento, transmisién, desclasificacion, y destruccién. Es conveniente que esto también inciuya los procedimientos para la cadena de custodia y registro de cualquier evento de seguridad relevante. Se recomienda que los acuerdos con otras organizaciones que incluyan compartir informacién, esta- blezcan procedimientos para identificar la clasificacion de dicha informacién y para interpretar los rétulos de clasificacién de otras organizaciones. Informacién adicional El rotulado y el manejo seguro de la informacién clasificada, es un requerimiento clave para los acuerdos en relacién al intercambio de informacion. Los rétulos fisicos son una forma comin de iden- tificacion. De todas maneras, algunos activos de informacién, como documentos en soporte digital, no pueden ser rotulados fisicamente y se hacen necesarios medios de identificacién digital. Por ejemplo un rétulo de notificacién podria mostrarse en la pantalla o visor. Donde no es factible el rotu- lado, se podran aplicar otros medios para designar la clasificacién de la informacion, por ejemplo, via procedimientos o via metadatos. 8 SEGURIDAD DE LOS RECURSOS HUMANOS Objetivo: Asegurar que los empleados, contratistas y usuarios de las terceras partes entiendan sus responsabilidades, sean adecuados para los roles para los cuales son considerados, y para reducir 1 riesgo de hurto, fraude o el mal uso de las instalaciones. ‘Se recomienda que se asignen las responsabilidades de seguridad con anticipacion a la incorpora- cién de acuerdo con la descripcién del puesto de trabajo y con los términos y condiciones laborales. Es conveniente que todos los candidatos para el puesto, contratistas, y usuarios de terceras partes se seleccionen correctamente, especialmente para trabajos sensibles. Se recomienda que los empleados, contratistas y usuarios de terceras partes de las instalaciones de procesamiento de la informacién, firmen un acuerdo sobre sus roles y responsabilidades de seguri- dad. 8.1.1 Roles y responsabilidades Controt Se recomienda que se definan y documenten los roles y responsabilidades de seguridad de los em- pleados, contratistas y usuarios de terceras partes en concordancia con la politica de seguridad de la informacion de la organizacién 5) xpicacién: a palabra emplear se utliza aqul para cubrir todas las situaciones siguientes: Emplear a gente (de forma temporal o de una duracién mayor) asignacién de roles de trabajo, cambio de roles de trabajo, ‘asignacién de contralos, la terminacion de cualquiera de éstos arregis. 35IRAM-ISO/IEC 27002:2008 Guia de implementacién Es conveniente que los roles y responsabilidades de seguridad incluyan requerimientos para: a) implementar y actuar en concordancia con las politicas de seguridad de la informacién de la or- ganizacion (ver 5.1); b) la proteccién de activos contra accesos no autorizados, divulgacién, modificacién, destruccion o interferencia; ¢c) la ejecucién de actividades 0 procesos de seguridad particulares; d) asegurar que se haga responsables a los individuos por sus acciones; €) reportar eventos de seguridad o eventos potenciales u otros riesgos de seguridad de la organi- zacion. Se recomienda que se definan y comuniquen claramente los roles y responsabilidades de seguridad a los candidatos para e! puesto de trabajo durante el proceso de preseleccién. Informacién adicional Se pueden usar las descripciones de puestos para documentar los roles y las responsabilidades de seguridad. Se recomienda que se definan y comuniquen claramente los roles y las responsabilidades de seguridad a las personas que no fueron contratadas via el proceso de reclutamiento de la organi- zacién, por ejemplo: las personas contratadas por parte de una organizacién de tercera parte, 8.1.2 Seleccién Controt Se recomienda que la verificacién de antecedentes de los candidatos para el puesto, contratistas, y usuarios de terceras partes, se registre y lieve a cabo en concordancia con las leyes correspondien- tes, regulaciones y reglas éticas, y sean proporcionales a los requerimientos del negocio, a la clasificacién de la informacién a ser accedida, y a los riesgos detectados. Guia de implementacién Se recomienda que el control de los antecedentes se lleve a cabo teniendo en cuenta toda la legisla- cién relevante basada en la privacidad, en la proteccién de los datos personales y en el empleo, y, donde se permita, incluya lo siguiente: a) [a disponibilidad de referencias de cardcter satisfactorio, por ejemplo: una de negocio y una personal; b) un control (tanto en integridad como en precision) de! curriculum vitae del aspirante; )_ la confirmacién de las calificaciones académicas y profesionales presentadas; 4) la verificacién de la identidad (pasaporte o documento de identidad); e) verificaciones mas detalladas, tales como verificaciones crediticias 0 de registros criminales. ‘Se recomienda que la organizacién considere verificaciones mas detalladas cuando un trabajo, ya ‘sea una incorporacién inicial 0 promocién incluye que la persona tenga acceso a las instalaciones de procesamiento de la informacion, y en particular si esto es acerca del manejo de informacién sens ble, por ejemplo: informacién financiera o altamente confidencial.IRAM-ISO/IEC 27002:2008 Es conveniente que los procedimientos definan criterios y limitaciones para las averiguaciones, por ejemplo: quién sera el responsable de la seleccién del personal, y cémo, cuéndo y por qué las verif caciones son llevadas a cabo. Es conveniente que el proceso de seleccién también pueda ser llevado a cabo para contratistas y usuarios de terceras partes. En el caso en que una agencia provea los contratistas, es conveniente que el contrato con la agencia especifique claramente las responsabilidades de seleccion que tiene la agencia y los procedimientos de notificacién que ellos necesitan seguir si el proceso de seleccién no ha sido completado o si el resultado causa duda 0 preocupacién. Del mismo modo, se recomienda que el acuerdo con la tercera parte (ver 6.2.3) especifique claramente todas las responsabilidades y los procedimientos de notificacién para la seleccién de personal Se recomienda que la informacién de todos los candidatos que estan siendo considerados para las posiciones dentro de la organizacién, se recolecte y maneje en concordancia con la legislacién exis- tente en la jurisdiccién correspondiente. Dependiendo de la legisiacién aplicable, se recomienda que se les informe a los candidatos de antemano acerca de las actividades de selecci6n. 8.1.3 Términos y condiciones de empleo Control Como parte de sus obligaciones contractuales, se recomienda que los empleados, contratistas y usuarios de tercera parte estén de acuerdo y firmen los términos y condiciones de sus contratos de empleo, los cuales se recomienda que refiejen sus responsabilidades y las de la organizacién para con la seguridad de la informacién. Guia de implementacién Se recomienda que los términos y condiciones de empleo reflejen la politica de seguridad de la in- formacién de la organizacién ademas de clarificar y definir: a) que todos los empleados, contratistas y usuarios de terceras partes a quienes se les ha dado acceso a la informacién sensible firmen un acuerdo de confidencialidad o de no divulgacién an- tes de tener acceso a las instalaciones de procesamiento de la informacién; b) las responsabilidades y derechos legales de empleados, contratistas, y cualquier otro usuario, por ejemplo: leyes con respecto al “copyright” o Ia legislacién de proteccién de los datos (ver también 15.1.1 y 15.1.2); ©) las responsabilidades de Ia clasificacién de la informacién y para la gestién de los activos de la organizacién asociados con sistemas de informacién y con servicios manejados por el emplea- do, contratista 0 usuario de tercera parte (ver 7.2.1 y 10.7.3); d) las responsabilidades de! empleado, contratista, o usuarios de tercera parte para el manejo de la informacién recibida de otras compafiias o de terceras partes; €) las responsabilidades de la organizacién para el manejo de informacién personal, incluida la in- formacién del personal creada como resultado, 0 en el curso de la vinculacién con la organizacién (ver también 15.1.4); f) las responsabilidades que se extienden fuera de las instalaciones de la organizacién y mas alla de los horarios normales de trabajo, por ejemplo: en caso de trabajo en el hogar (ver también 9.2.5 y 11.7.1), 9) acciones a ser llevadas a cabo si el empleado, contratista o usuario de tercera parte no cumple los requerimientos de la seguridad de la organizacién (ver 8.2.3). 37IRAM-ISO/IEC 27002:2008 ‘Se recomienda que la organizacién asegure que los empleados, contratistas y usuarios de tercera parte estén de acuerdo con los términos y condiciones concernientes a la seguridad de la informa- cién, adecuados a la naturaleza y extension del acceso que tendran a los activos de la organizacion asociado con los sistemas y servicios de informacién Cuando sea apropiado, se recomienda que las responsabilidades contenidas dentro de los términos y condiciones del empleo contintien por un periodo definido de tiempo luego de la finalizacién del ‘empleo (ver también 8.3), Informacién adicional Se puede utilizar un cédigo de conducta para que cubra las responsabilidades de los empleados, contratistas 0 usuarios de tercera parte con respecto a la confidencialidad, proteccién de datos, re- glas éticas, uso apropiado del equipamiento e instalaciones de la organizacién, asi como también de practicas honorables esperadas por la organizacién. El contratista 0 usuario de tercera parte puede estar asociado a una organizacién externa a la cual se le puede requerir que realice arregios contrac- tuales en nombre del individuo contratado. 8.2 Durante el empleo Objetivo: Asegurar que se concientice a los empleados, contratistas y usuarios de tercera parte de las amenazas y preocupaciones de la seguridad de la informacion, sus responsabilidades y obliga- ciones, y estén preparados para respaldar las politicas de seguridad organizacional en el curso de su trabajo normal, y para reducir el riesgo de error humano. Se recomienda que las responsabilidades de la gestién se definan para asegurar que la seguridad es aplicada por todos y cada uno de los empleados dentro de la organizacion Se recomienda que se provea a todos los empleados, contratistas y usuarios de tercera parte de un adecuado nivel de concientizacién, educacién, y entrenamiento tanto en procedimientos de seguridad como en el correcto uso de las instalaciones de procesamiento de la informacién, para minimizer los posibles riesgos de seguridad. Se recomienda que se establezca un proceso disciplinario formal para manejar brechas de seguridad. 8.2.1 Responsabilidades de la direccién Control Se recomienda que la direccién requiera a los empleados, contratistas y usuarios de terceras partes que apliquen la seguridad en concordancia con las politicas y procedimientos establecidos por la orga- nizacion. Guia de implementacién Se recomienda que la gestién de las responsabilidades asegure que los empleados, contratistas y usuarios de terceras partes: a) estén adecuadamente informados de sus roles y responsabilidades respecto de la seguridad de la informacién antes que se les otorgue el acceso a informacién sensible o a los sistemas de informacion; b) estén provistos de guias para establecer las expectativas de seguridad de su rol dentro de la organizacién; c) estén motivados para cumplir con las politicas de seguridad de la organizacién; 38IRAM-ISO/IEC 27002:2008 d) alcancen un nivel de conciencia sobre la seguridad acorde con sus roles y responsabilidades dentro de la organizacién (ver también 8.2.2); ) cumplan con las condiciones y términos del empleo, los cuales incluyen las politicas de segur- dad de la informacion de la organizacién y métodos adecuados de trabajo; )_se mantengan con las capacidades y calificaciones adecuadas. Si los empleados, contratistas y usuarios de terceras partes no estén al tanto de sus responsabilida- des de seguridad, pueden causar dafios considerables a la organizacién. Un personal motivado probabiemente es mas confiable y causa menos incidentes de seguridad de la informacion. Una gestién pobre puede causar que el personal se sienta desvalorizado resultando en un impacto negativo para la seguridad de la organizacién. Por ejemplo, una gestion pobre podria condueir a que la Seguridad se descuide o al potencial uso impropio de los activos de la organizacién. 8.2.2 Concientizacién, educacién y entrenamiento en seguridad de la informacién Control Se recomienda que todos los empleados de la organizacién y, cuando sea pertinente, los contratistas y usuarios de terceras partes reciban una apropiada concientizacién y actualizaciones regulares en jas politicas y procedimientos organizacionales, que sean importantes para su tarea. Guia de implementacién Se recomienda que el entrenamiento de conocimientos se inicie con un proceso formal de inducci6n disefiado para introducir las politicas y expectativas de la seguridad de la organizacién antes de que se oforgue el acceso a la informacién 0 a los servicios. Se recomienda que el entrenamiento continuo incluya los requerimientos de seguridad, las respon- sabilidades legales y controles de! negocio, asi como también entrenamiento en el correcto uso de Jas instalaciones de procesamiento de la informacion, por ejemplo, el procedimiento de ingreso al sis- tema ("log-on"), uso de paquetes de software e informacion sobre el proceso disciplinario (ver 8.2.3). Informacién adicional Se recomienda que los conocimientos de seguridad, la educacién, y las actividades de entrenamiento sean adecuadas y correspondan al rol de la persona, responsabilidades y capasidades, y es conve- niente que incluya informacién sobre amenazas conocidas, a quién contactar para asesoramiento mas extenso sobre seguridad, y los canales adecuados para el reporte de incidentes de seguridad de la informacion. El entrenamiento para reforzar los conocimientos tiene la intencién de permitir a los individuos reco- nocer los problemas e incidentes de seguridad de la informacion, y responder de acuerdo con las necesidades de su rol de trabajo. 8.2.3 Proceso disciplinario Control Se recomienda que exista un proceso disciplinario formal para los empleados que hayan generado un incidente de seguridad. 39IRAM-ISO/IEC 27002:2008 Guia de implementacion Se recomienda que el proceso disciplinario no se inicie sin la previa verificacion de que ha ocurrido una brecha en la seguridad (ver también 13.2.3 para la recoleccién de evidencia). Es conveniente que el proceso disciplinario formal asegure un correcto y justo tratamiento de los em- pleados de los que se sospecha que han cometido algun incidente de seguridad. Se recomienda que el proceso disciplinario formal garantice una respuesta adecuada, la cual debe tener en considera~ cién factores como la naturaleza y gravedad del incidente, y su impacto en el negocio, si es la primera infraccién o si es repetitva, si el infractor ha sido 0 no ha sido apropiadamente entrenado, la legislacién pertinente, contratos de negocios, y cualquier otro factor que se requiera. En casos serios de mala conducta, se recomienda que el proceso permita la remocién urgente de las obligaciones, derechos de acceso y privilegios, asi como la escolta inmediata fuera de las instalaciones, en caso de ser necesario. Informacién adicional Es conveniente que el proceso disciplinario se utilice como impedimento y para prevenir que los em- pleados, contratistas y usuarios de tercera parte violen las politicas y procedimientos de seguridad de la organizacién, y cualquier otra brecha de seguridad. 8.3 Desvinculat no cambio de puesto ‘Onjetivo: Asegurar que los empleados, contratistas y usuarios de terceras partes abandonen la orga- nizacién o cambien de empleo de una manera ordenada. Se recomienda que existan responsabilidades para asegurar la desvinoulacién de los empleados, contratistas, 0 usuarios de terceras partes, de la organizacién, y asegurar el retorno de todo el equi- pamiento asi como la revocacién de los derechos de acceso de manera completa. Es conveniente que los cambios de responsabilidades y empleo dentro de una organizacién se ma- nejen como la terminacién de una responsabilidad o empleo respectiva, en linea con esta seccién, y se recomienda que cualquier otro nuevo empleo se maneje como se describe en 8.1 8.3.1 Responsabilidades de la desvinculacién Control Se recomienda que las responsabilidades para realizar la desvinculacién del empleo 0 cambio de puesto estén claramente definidas y asignadas. Guia de implementacién Se recomienda que la comunicacién de las responsabilidades de desvinculacién incluya los requeri- mientos de seguridad y responsabilidades legales consecuentes y, cuando sea apropiado, las responsabilidades contenidas dentro de cualquier acuerdo de confidencialidad (ver 6.1.5), y los tér- minos y condiciones de empleo (ver 8.1.3) con continuidad por un periodo definido de tiempo luego de la finalizacién del trabajo del empleado, contratista o usuario de tercera parte. Se recomienda que las responsabilidades y obligaciones que siguen siendo vélidas luego de la ter- minacién del empleo estén contenidas en el contrato con el empleado, contratista 0 usuario de tercera parte. Se recomienda que los cambios de responsabilidad 0 empleo se manejen como ia terminacién de la responsabilidad respectiva 0 empleo, y es conveniente que la nueva responsabilidad o empleo se controle como se describe en 8.1 40IRAM-ISO/IEC 27002:2008 Informacién adicional El sector de Recursos Humanos es generalmente responsable del proceso general de desvinculacién y trabaja en conjunto con el gerente o supervisor de la persona que se esté marchando para manejar los aspectos de seguridad de los procedimientos pertinentes. En el caso de un contratista, este proceso de responsabilidad de terminacién puede ser encargado a la agencia responsable por el contratista, y en el caso de otro usuario esto podria ser manejado por su organizacion. Puede ser necesario informar a empleados, clientes, contratistas, o usuarios de tercera parte de los cambios de personal y medidas operativas. 8.3.2 Retorno de activos Controt Se recomienda que todos los empleados, contratistas y usuarios de terceras partes devuelvan todos los activos de la organizacién en su poder tras la terminacién de su empleo, contrato, o acuerdo. Guia de implementacién Se recomienda que el proceso de desvinculacién esté formalizado para incluir el retorno de todo software, documento corporativo y equipamiento entregado previamente. También es necesario que se devuelvan otros activos organizacionales como dispositivos de computacion méviles, tarjetas de crédito, tarjetas de ingreso, software, manuales e informacion almacenada en medios electronics En los casos donde un empleado, contratista 0 usuario de tercera parte compra el equipamiento de la organizacién 0 usa equipamiento propio, se recomienda que se sigan procedimientos para asegurar que toda la informacién relevante se transfiera a la organizacién y elimine de forma segura del equi- pamiento (ver también 10.7.1) En los casos en que un empleado, contratista 0 usuario de tercera parte tiene informacién que es im- portante para las operaciones en curso, se recomienda que esa informacion se documente y transfiera a la organizacién. 8.3.3 Remocién de derechos de acceso Control Se recomienda que se revisen los derechos de acceso de todos los empleados, contratistas y usua- rios de tercera parte a las instalaciones de procesamiento de la informacién tras la finalizaoién de su empleo, contrato 0 acuerdo, o adaptados tras algin cambio. Guia de implementacién Se recomienda que se revisen los derechos de acceso de un individuo a los activos asociados con los sistemas y servicios de informacién tras la desvinculacién. Esto determinara si es necesario re- mover los derechos de acceso. Es conveniente que los cambios de empleo se encuentren refiejados ‘en la remocion de todos los derechos de acceso que no fueron aprobados para el nuevo empleo. Es conveniente que los derechos de acceso que son removidos 0 adaptados incluyan acceso légico fisico, llaves, tarjetas de identificacién, instalaciones de procesamiento de la informacion (ver tam- bién 11.2.4), suscripciones, y remocién de cualquier documentacién que lo identifique como un miembro corriente de la organizacién. Si un empleado, contratista 0 usuario de tercera parte que se esta desvinculando tiene conocimiento de contrasefias para cuentas que permanecen activas, se re- comienda que éstas se cambien tras la finalizacién o cambio de empleo, contrato 0 acuerdo. a“IRAM-ISO/IEC 27002:2008 Se recomienda que se reduzcan o eliminen los derechos de acceso a los activos de la informacion y a las instalaciones de procesamiento de la informacion antes de que el empleo termine o cambie, dependiendo de la evaluacién de factores de riesgos, tales como: a) sila terminacién o cambio es iniciado por el empleado, contratista o usuario de tercera parte, 0 por la gestion y la razén de la finalizacion; b) las responsabilidades actuales de! empleado, contratista o cualquier otro usuario; ) el valor de los activos accesibles corrientemente. Informacién adicional En ciertas circunstancias los derechos de acceso pueden ser asignados sobre la base de que son acce- sibles para mas personas ademas de! empleado, contratista 0 usuario de tercera parte que esta desvinculdndose, por ejemplo: Identificaciones de grupos. En tales circunstancias, se recomienda que los individuos que estén desligandose se remuevan de cualquier lista de acceso grupal y es conveniente que se realicen arreglos para advertir a todos los demas empleados, contratistas y usuarios de terceras partes involucrados para que no continiien compartiendo la informacién con la persona en cuestién. En caso que la desvinculacién se inicie por la organizacién, empleados, contratistas o usuarios de terceras partes disgustados, podrian corromper deliberadamente la informacion o sabotear las insta~ laciones de procesamiento de la informacién. En caso de personas que renuncian, los mismos podrian verse tentados a recolectar informacién para uso futuro. 9 PROTECCION FISICA Y AMBIENTAL 9.1 Areas seguras Objetivo: Impedir accesos fisicos no autorizados, dafios e interferencia a las instalaciones e infor- macién de la organizacién, Se recomienda que las instalaciones de procesamiento de informacién critica o sensible estén ubi- cadas en dreas seguras, protegidas por un perimetro de seguridad definido, con barreras de seguridad y controles de acceso apropiados. Se recomienda que estén fisicamente protegidas de accesos no autorizados, dafios e interferencia, Es conveniente que la proteccién provista sea proporcional a los riesgos identificados. 9.1.1 Perimetro de seguridad fisica Control Se recomienda que se utilicen perimetros de seguridad (barreras tales como paredes, puertas de en- trada controladas por tarjetas 0 escritorios de recepcién atendidos por personas) para proteger areas que contengan informacién e instalaciones del procesamiento de informacién Guia de implementacién Se recomienda que cuando sea apropiado se consideren e implementen para los perimetros de se- guridad fisicos, las directrices siguientes: a) que los perimetros de seguridad se encuentren claramente definidos, se recomienda que el lu- gar de asentamiento y la fuerza de cada perimetro dependa de los requerimientos de seguridad de los activos dentro del perimetro y de los resultados de la evaluacién de riesgos;IRAM-ISO/IEC 27002:2008 b) que el perimetro de un edificio o area que contenga las instalaciones de procesamiento de in- formacién se explore fisicamente (por ejemplo: se recomienda que no existan aberturas en el perimetro 0 areas donde pueda ocurrir fécilmente una irrupcién); es conveniente que las pare- des externas del area sean de construccién sdlida y se recomienda que todas las puertas externas estén adecuadamente protegidas con mecanismos de control contra accesos no auto- rizados, por ejemplo: barras, alarmas, cerraduras, etc.; se recomienda que las puertas y ventanas estén trabadas cuando queden sin atencion y es conveniente que se considere una proteccion externa para las ventanas, particularmente al nivel del suelo; ©) que exista un area de recepcién atendida por personas u otros medios de control de acceso fi- sico al érea o edificio; es conveniente que el acceso a las distintas areas y edificios se ‘encuentre restringido exclusivamente al personal autorizado; d) que se construyan barreras fisicas, donde sea necesario, para prevenir el acceso fisico y la con- taminacion ambiental; ) que todas las puertas de incendio en un perimetro de seguridad, tengan alarma, se sigan, con- trolen y prueben en conjunto con los muros para establecer el nivel requerido de resistencia de acuerdo con la regién adecuada, normas nacionales e internacionales; es conveniente que se ‘opere en concordancia con el cédigo de incendios local de una manera segura; f) que se instalen los sistemas de deteccién de intrusos segun normas nacionales, regionales 0 internacionales y se prueben regularmente para cubrir todas las puertas externas y ventanas accesibles; se recomienda que las areas desocupadas estén equipadas con alarmas todo el tiempo; se recomienda que se provea la cobertura para otras éreas, por ejemplo: la sala de ‘computacién 0 la sala de comunicaciones; 9) que las instalaciones de procesamiento de la informacién administradas por la organizacién se encuentren fisicamente separadas de aquellas administradas por terceras partes. Informacién adicional La proteccién fisica se puede alcanzar a través de la creacién de una o més barreras fisicas alrede- dor del terreno de la organizacién y las instalaciones de procesamiento de la informacién. El uso de miitiples barreras brinda proteccién adicional, donde la falla de una barrera no significa que la segu- ridad esté inmediatamente comprometida Un drea segura puede ser una oficina que se pueda cerrar o muchas habitaciones rodeadas por una barrera continua de seguridad interna. Las barreras y perimetros adicionales para controlar el acceso fisico pueden llegar a Ser necesarias entre areas con diferentes requerimientos de seguridad dentro del perimetro de seguridad Se recomienda que se tenga especial consideracion hacia la seguridad del acceso fisico en los edifi- cios donde se hospedan miittiples organizaciones. 9.1.2 Controles de acceso fisico Control ‘Se recomienda que las 4reas seguras se resguarden con controles de acceso adecuados que garan- ticen que sélo se permite e! acceso a personal autorizado. Guia de implementacién Se recomienda que se tenga en cuenta las directrices siguientes:IRAM-ISO/IEC 27002:2008 b) ¢) 4) que se registre la fecha y hora de entrada y salida de los visitantes, y se recomienda que se supervise a todos los visitantes a menos que su acceso haya sido aprobado previamente; se recomienda que ellos s6lo tengan acceso para propésitos especificos y autorizados, y se re- comienda que se les provea de instrucciones en requerimientos de seguridad del area y en procedimientos de emergencia; que se controle y restrinja el acceso a las areas donde se realice el procesamiento 0 almace- namiento de informacién sensible solo a personas autorizadas; controles de autenticacion, por ejemplo: se recomienda que se utilicen tarjetas de control de acceso mas un numero de identi- ficacién personal (PIN), para autorizar y validar todos los accesos; se recomienda que se mantenga de forma segura un registro auditado de todos los accesos; que se le exija a todos los empleados, contratistas y usuarios de terceras partes y visitas el uso de alguna forma visible de identificaci6n y se recomienda que se notifique de forma inmediata al personal de seguridad si encuentran visitas sin escolta 0 alguien que no utilice una identifica- cién visible; que se le otorgue acceso restringido al personal de servicio de soporte de tercera parte a areas seguras 0 instalaciones de procesamiento de informacién sensible solamente cuando se re- quiera; se recomienda que este acceso se autorice, siga y controle; que los derechos de acceso para areas seguras se revise y actualice regularmente, y revoque cuando sea necesario (ver 8.3.3) 9.4.3 Aseguramiento de oficinas, recintos e instalaciones Control Se recomienda que se disefie y aplique seguridad fisica para oficinas, recintos e instalaciones. Guia de implementacién Se recomienda que se consideren las siguientes directrices para la proteccion de oficinas, recintos e instalaciones: a) se recomienda que se tomen en cuentas la regulaciones y normas de salud y seguridad co- rrespondientes; b) se recomienda que las instalaciones clave se ubiquen de modo tal de evitar que las mismas puedan ser accedidas por el pibiico. ©) donde sea aplicable, se recomienda que los edificios sean discretos y otorguen la minima indi- cacién posible de su propésito, sin sefiales obvias, tanto fuera como dentro del edificio, identificando la presencia de actividades de procesamiento de informacién; 4) se recomienda que los directorios y listados intemos de teléfonos que identiican la ubicacién de instalaciones de procesamiento de informacién sensible no sean de iectura accesible al publico. 9.1.4 Protecci6n contra amenazas externas y del ambiente Control Se recomienda que se disefie y aplique medios de proteccién fisica contra dafios potenciales causa- dos por fuego, inundacién, terremoto, explosion, disturbios civiles y otras formas de desastre natural © provocado por el hombre.IRAM-ISO/IEC 27002:2008 Guia de implementacion Se recomienda que se considere cualquier amenaza de seguridad que se presente por los terrenos vecinos, por ejemplo: un incendio en un edificio vecino, goteo de agua desde el techo 0 en pisos que se encuentren por debajo del nivel del suelo 0 una explosién en la calle. Para evitar dafio de fuego, inundacién, terremoto, explosion, movimiento civil, y otras formas de de- sastre natural 0 hecho por el hombre, se recomienda a) que los materiales peligrosos o combustibles se mantengan a una distancia apropiada del area segura, y que las provisiones de gran volumen, tales como articulos de oficina no se almace- nen dentro de un area segura; b) que el equipamiento para casos de emergencia, y medios de respaldo se ubique a una distan- cia segura para evitar dafios ante un desastre que afecte a la ubicacién principal; ©) que se provea y se ubique adecuadamente el apropiado equipamiento para casos de incendio. 9.4.5 Trabajo en dreas protegidas Control Se recomienda que se disefie y aplique proteccién fisica y las directrices para el trabajo en areas pro- tegidas. Guia de implementacion Se recomienda que se consideren las siguientes directrices: a) se recomienda que el personal sélo tenga conocimiento de la existencia de un drea protegida, 0 de las actividades que se llevan a cabo dentro de la misma, segun el criterio de que exista necesidad que se conozca; b) se recomienda que se evite el trabajo no supervisado en areas protegidas tanto por razones de ‘seguridad como para evitar la posibilidad de que se leven a cabo actividades maliciosas; ) se recomienda que las areas protegidas desocupadas se bloqueen fisicamente e inspeccionen periddicamente; d) se recomienda que no se permitan equipos de fotografia, video, audio u otro tipo de equipamien- to de grabacién, tales como camaras en dispositives méviles, salvo autorizacion pertinent, Los arregios para el trabajo en areas seguras inoluyen controles para los empleados, contratistas y usuarios de terceras partes que trabajan en el area segura, como también actividades de terceras partes que se desarrollen all, 9.1.6 Areas de acceso publico, de entrega y de carga Control Se recomienda que se controlen los puntos de acceso, como las areas de entrega y carga y otros pun- tos donde personas sin autorizacién pueden llegar a entrar a las instalaciones y, de ser posible, se aislen de las instalaciones de procesamiento de la informacion para evitar el acceso no autorizado. Guia de implementacin Se recomienda que se consideren las directrices siguientes:IRAM-ISO/IEC 27002:2008 a) que el acceso a un rea de entrega y carga desde el exterior del edifcio, esté limitado a perso- nal identificado y autorizado; b) que el area de entrega y carga se disefie de manera tal que los suministros puedan ser des- cargados sin que el personal que realiza la entrega acceda a otros sectores del edificio; ©) que las puertas exteriores de un drea de entrega y carga se aseguren cuando se abren las puertas internas; d) que el material entrante se inspeccione para evitar amenazas potenciales (ver 9.2.1 d) antes de que se traslade desde el area de entrega y carga hasta el lugar de uso; ) que el material entrante se registre en concordancia con los procedimientos de gestion de los activos (ver también 7.1.1 ) antes de entrar al edificio; f) que, en la medida en que sea posible, los envios entrantes y salientes se encuentren fisica- mente separados 9.2 Seguridad del equipamiento (Objetivo: Impedir pérdidas, dafios, robos 0 exposiciones al riesgo de los activos asi como impedir la interrupcién de las actividades de la empresa. Se recomienda que el equipamiento se encuentre del ambiente. icamente protegido de las amenazas fisicas y| Es necesaria la proteccién del equipamiento (incluyendo el que se utiliza en forma externa, y el retiro de la propiedad) para reducir el riesgo de acceso no autorizado a la informacién y para prevenir las pérdidas 0 dafios. Se recomienda que también se considere la ubicacién y disposicién del equipa- miento. Pueden requerirse controles especiales para protegerse contra amenazas fisicas y para Cuidar las instalaciones de apoyo, tales como el suministro eléctrico y la infraestructura de cableado. 9.2.1 Ubicacién y proteccién del equipamiento Contro! Se recomienda que el equipamiento se ubique y proteja de tal manera que se reduzcan los riesgos ‘ocasionados por amenazas y peligros ambientales y oportunidades de accesos no autorizados. Guia de implementacién Se recomienda que se tengan en cuenta las directrices siguientes: a) que el equipamiento se ubique de modo de minimizar el acceso innecesario a las areas de trabajo; b) que las instalaciones de procesamiento de informacion que manejan datos sensibles, se ubi- quen con un Angulo de visibilidad restringido para reducir el riesgo de que la informacion sea vista por personas no autorizadas durante su uso, asi como también que las instalaciones de almacenamiento estén aseguradas para evitar su acceso no autorizado; ‘¢) que los items que requieran de proteccién especial estén aislados para reducir el nivel general de protecoién requerida; d) que se adopten controles para minimizar el riesgo de amenazas fisicas potenciales, por ejem- plo: robo, incendio, explosivos, humo, agua (0 falta de suministro), polvo, vibraciones, efectos quimicos, interferencia en el suministro de energia eléctrica, interferencia en las comunicacio- nes, radiaciones electromagnéticas y vandalismo; 46IRAM-ISO/IEC 27002:2008 e) que se establezcan directrices en cuanto a comer, beber y fumar en las proximidades de las instalaciones de procesamiento de informacion; f) que las condiciones ambientales, como la temperatura y la humedad, se supervisen y controlen para evitar que estas condiciones puedan afectar de manera adversa la operacién de las insta- laciones de procesamiento de informacién: ) que se aplique proteccién luminosa en todos los edificios y que los ftros de proteccién lumino- sa se adapten a todas las lineas entrantes de energia y de comunicacién; h) que para el equipamiento en ambientes industriales se considere el uso de métodos especiales de proteccién, como cubiertas de teclado; i) que el equipo que procesa informacién sensible se proteja para minimizar el riesgo de fuga de informacién debido a emanaciones. 9.2.2 Elementos de soporte Control! ‘Se recomienda que el equipamiento se encuentre protegido con respecto a posibles falas en el su- ministro de energia u otras fallas en los elementos de soporte. Guia de implementacién Se recomienda que todas las utilidades de soporte, tales como electricidad, provision de agua, cloa- cas, calefacciéniventilaci6n y aire acondicionado sean adecuados para los sistemas para los que estan brindando soporte. Se recomienda que las utiidades de soporte se inspeccionen regularmente y prueben apropiadamente para asegurar su funcionamiento adecuado y para reducir cualquier ries- go producto de su maifuncionamiento o falla. Se recomienda que se provea de un suministro de corriente eléctrica adecuado que cumpla con las especificaciones del fabricante del equipamiento. ‘Se recomienda contar con una unidad de energia ininterrumpida (UPS) para dar soporte a un apaga- do ordenado o Ia ejecucién continua del equipamiento que sustenta las operaciones criticas de la organizacién. Se recomienda que los planes de contingencia contemplen las acciones que han de ser tomadas ante una falla de la UPS. Se recomienda que se considere disponer de_un generador de respaldo en el caso de que se produzca una falla de energia eléctrica prolongada y el procesa- miento de la informaci6n deba continuar. Se recomienda que se mantenga una adecuada provision de combustible para asegurar que el generador pueda trabajar por un periodo prolongado. Se reco- mienda que la/las UPS y los generadores se inspeccionen periddicamente para asegurar que tienen la capacidad requerida y han sido probados de acuerdo con las recomendaciones del fabricante. ‘Ademds, se pueden hacer consideraciones para utilizar miitiples fuentes de energia, 0, si el sitio es grande, una subestacién separada de energia Se recomienda que se ubiquen interruptores de corte de energia de emergencia cerca de las salidas de emergencia en salas de equipamiento para faciitar el rapido corte de energia en caso de una emergencia. Se recomienda que se provea de iluminacién de emergencia en caso de una falla de la energia principal. Se recomienda que el abastecimiento de agua sea estable y adecuado para abastecer a los equipos de aire acondicionado, los equipos de humidificacién y los sistemas de extincién de fuego (cuando se utilicen). Ei funcionamiento defectuoso del sistema de abastecimiento de agua puede dafar el equi- pamiento 0 impedir que la extincidn de fuego acttie de manera efectiva. Se recomienda, en caso que ‘se requiera, que se evalde e instale un sistema de alarma para detectar funcionamientos defectuosos en las utiidades de soporte. a7IRAM-ISO/IEC 27002:2008 Se recomienda que los equipos de telecomunicaciones se encuentren conectados con el proveedor del servicio a través de al menos dos rutas distintas para prevenir que fallas en una via de conexion suprima servicios de voz. Se recomienda que los servicios de voz sean adecuados para cumplir con los requerimientos legales locales para las comunicaciones de emergencia. Informacién adicional Las opciones para alcanzar la continuidad de la provisién de electricidad incluyen multiples alimenta- ciones para evitar un punto Unico de falla en la provision de electricidad 9.2.3 Seguridad del cableado Control! Se recomienda que el cableado de energia y de telecomunicaciones que transporte datos 0 de so- porte a servicios de informacién estén protegidas contra interferencias o dafios. Guia de implementacion Para la seguridad del cableado se recomienda que se consideren las directrices siguientes: a) que las lineas de energia y telecomunicaciones que se encuentran dentro de las instalaciones de procesamiento de la informacién estén instaladas bajo tierra, donde sea posible, 0 sujetas a adecuadas alternativas de proteccién; b) que el cableado de red se proteja contra intercepciones no autorizadas 0 dafios, por ejemplo: Utlizando un conducto o evitando rutas que atraviesen areas publicas; ©) que los cables de energia estén separados de los cables de comunicacién para prevenir inter- ferencias; d) que se utilicen cables claramente identificables y marcas en los equipos para minimizar el ma- nejo erréneo, como el armado erréneo de los cables de red; ) [a.utilizacién de una lista documentada de conexiones para reducir la posibilidad de errores; f)_considerar para los sistemas sensibles o criticos controles adicionales que incluyan: 1) _instalacién de conductos blindados y recintos 0 cajas con cerradura en los puntos termina- les y de inspeccion; 2) uso de rutas 0 medios de transmisién alternativos que provean una seguridad apropiada; 3) uso de cableado de fibra éptica; 4) uso de proteccién electromagnética para proteger el cableado: 5) realizacin de barrdos técnicos e inspecciones fisicas para buscar dispositivos que hayan ‘sido acoplados a los cables sin autorizacién; 6) acceso controlado a los paneles de conexién y a las salas de cableado; 9.2.4 Mantenimiento del equipamiento Control ‘Se recomienda que el equipamiento reciba el correcto mantenimiento para asegurar su disponibilidad @ integridad continuas. 48IRAM-ISO/IEC 27002:2008 Guia de implementacién Se recomienda que para el mantenimiento del equipo se consideren las directrices siguientes: a) que el equipamiento se mantenga de acuerdo con los intervalos y especificaciones de servicio recomendados por el proveedor; b) que sélo el personal de mantenimiento autorizado lleve a cabo reparaciones y revisiones del equipamiento; ©) que se lleven registros de todas las fallas sospechadas 0 reales, y de todo el mantenimiento preventivo y correctivo; 4) que se implementen los controles apropiados cuando esté programado el mantenimiento de! ‘equipamiento, teniendo en cuenta si este mantenimiento es realizado por personal de la em- presa o extemo a la organizacién; cuando sea necesario, se recomienda que se elimine la informacion sensible del equipamiento, 0 se le aciare ésto al personal de mantenimiento de forma suficiente; ) que se cumpla con todos los requerimientos impuestos por las politicas de seguridad. 9.2.5 Seguridad del equipamiento fuera del ambito de la organizacion Control! Se recomienda que se aplique la seguridad al equipamiento que esté fuera del émbito de la organi- zacién teniendo en cuenta los diferentes riesgos de trabajar fuera del ambito de la organizacion. Guia de implementacién Sin tener en cuenta quien sea el propietario, se recomienda que el uso de cualquier equipamiento de procesamiento de informacién fuera del ambito de la organizacion esté autorizado por la gerencia Se recomienda que para la proteccién del equipamiento que se encuentra fuera del area se conside- re las directrices siguientes: a) que el equipamiento y dispositivos retirados del ambito de la organizacion no permanezcan desatendidos en lugares publicos; se recomienda que las computadoras personales se trans- porten como equipaje de mano y de ser posible enmascaradas, durante los viajes; b) que se observen siempre las instrucciones del fabricante para proteger el equipamiento, por ‘ejemplo: proteccién a la exposicion de campos electromagnéticos potentes; ©) que se determinen los controles de trabajo en el hogar por una evaluacién de riesgos y controles adecuadamente aplicados, por ejemplo: gabinetes que se puedan cerrar con llave, politicas de es- critorio limpio, controles de acceso a computadoras y comunicacién segura con la oficina (ver tam- bién ISO/IEC 18028 “Information Technology - Security techniques - IT network security part 1-5"); d) que se establezca una adecuada cobertura de seguro para la proteccién del equipamiento fue- ra de las instalaciones. Los riesgos de seguridad, por ejemplo: ef dafio 0 robo, pueden variar considerablemente segtin las ubicaciones y se recomienda que se tengan en cuenta al determinar los controles mas apropiados, 49IRAM-ISO/IEC 27002:2008 Informacién adicional EI almacenamiento de la informacion y el equipo de procesamiento incluyen todas las formas de ‘computadoras personales, organizadores, teléfonos méviles, tarjetas inteligentes, papel u otra forma, la cual se pueda adoptar para trabajar en el hogar o para ser transportada fuera de la ubicacién nor- mal de trabajo. Mayor informacién acerca de otros aspectos de la proteccién de equipamiento movil se puede encon- traren 11.7.1 9.2.6 Disposicién final o reutilizacién segura del equipamiento Control! Se recomienda que se verifiquen todas las partes de los equipos que contengan un medio de alma- cenamiento, para asegurar que cualquier dato sensible y licencia de software ha sido removido 0 sobrescrito previo a la disposicién. Guia de implementacién ‘Se recomienda que los dispositivos que contengan informacién sensible se destruyan fisicamente o que la informacion se destruya, borre o sobrescriba usando técnicas para hacer que la informacién original ‘sea imecuperable en lugar de la utiizacion de la forma normal de borrado o la funcién de formateo. Informacién adicional Los dispositivos dafiados que contengan datos sensibles pueden requerir una evaluacién de riesgos para determinar si es conveniente que sean destruidos fisicamente en lugar de ser enviados para repa- racién 0 descarte. La informacién puede estar comprometida si el equipamiento es dispuesto sin cuidado o bien, es re- utilizado (ver también 10.7.2) 9.2.7 Retiro de bienes Control ‘Se recomienda que el equipamiento, la informacién o el software no se retiren de las instalaciones sin previa autorizacién, Guia de implementacién Se recomienda que se sigan las directrices siguientes: a) que el equipamiento, la informacion o el software no se retiren del predio sin previa autorizacion; b) que los empleados, contratistas y usuarios de terceras partes quienes tienen autoridad para Permitir la remocién de los activos fuera de la organizacion estén claramente identificados; ©) que se establezcan los tiempo limites para la remocién del equipamiento y que se verifique su devolucion; d) que, cuando sea necesario y apropiado, se deje constancia de que el equipamiento fue retira- do de la organizacién y se deje constancia de su devolucién. Informacién adicional Los puntos de verificacién, desarrollados para detectar el retiro no autorizado de bienes, pueden también ser desarroliados para detectar dispositivos de grabacién sin autorizacion, armas, etc. y pre- venir su entrada al sitio. Se recomienda que tales puntos de verificacién se leven a cabo enIRAM-ISO/IEC 27002:2008 concordancia con la legislacién y las regulaciones correspondientes. Se recomienda que los indivi- duos estén al tanto de que se estan llevando a cabo verificaciones, y se recomienda que las verificaciones se realicen con autorizacién apropiada segiin los requerimientos legales y regulatorios. 10 GESTION DE COMUNICACIONES Y OPERACIONES 10.1 Procedimientos y responsabilidades operativas (Objetivo: Garantizar el funcionamiento correcto y seguro de las instalaciones de procesamiento de la informacion. Se recomienda que se establezcan responsabilidades y procedimientos para la gestién y funcio- namiento de todas las instalaciones de procesamiento de informacion. Esto incluye el desarrollo de procedimientos apropiados de funcionamiento. ‘Se recomienda que se implemente la segregacién de funciones, cuando corresponda, a fin de reducir el riesgo del uso negiigente 0 el deliberado mal uso del sistema. 10.1.1 Documentacién de los procedimientos operativos Control Se recomienda que los procedimientos operalivos se documenten, mantengan y encuentren disponibles para todos los usuarios que los necesiten. Guia de implementacién Se recomienda que se preparen procedimientos documentados para las actividades de los sistemas asociados con las instalaciones de procesamiento de informacién y de comunicacién, tales como los procedimientos de inicio y apagado de la computadora, copias de resguardo, mantenimiento de los equipos, manejo de los medio, sala de computacién y gestion de manejo de correo, y seguridad. Se recomienda que los procedimientos operacionales especifiquen las instrucciones para la ejecu- cién detallada de cada tarea, incluidas: a) procesamiento y manejo de informacion; b) copias de seguridad (ver 10.5); ) requerimientos de tiempos, incluyendo interdependencias con otros sistemas, comienzos tempra- 1N0S de inicio de tareas y finalizacion tardia de tareas; 4d) instrucciones para el manejo de errores u otras condiciones excepcionales que podrian surgir du- rante la ejecucién de tareas, incluyendo restricciones en el uso de utiidades del sistema (ver 95.5); @) contactos de soporte en caso de dificultades operativas 0 técnicas imprevistas; {)_instrucciones especiales para el manejo de salidas y medios , como el uso de papeleria especial 0 la gestion de salida de resultados confidenciales, incluyendo procedimientos para la eliminacion segura de las salidas de resultados de tareas fallidas (ver 10.7.2 y 10.7.3); 9g) procedimientos para el reinicio del sistema y procedimientos de recuperacion para utilizar en caso de producirse fallas en el sistema; 51IRAM-ISO/IEC 27002:2008 h) la gestién de hallazgos de auditoria e informacion de registros del sistema (ver 10.10). Se recomienda que los procedimientos operativos y los procedimientos documentados para las acti- vidades de! sistema se traten como documentos formales y los cambios sean autorizados por la gerencia, Cuando sea técnicamente viable, se recomienda que los sistemas de informacion se mane- jen consistentemente, usando los mismos procedimientos, herramientas y utiidades. 10. 2 Gestién de cambios Control Se recomienda que se controien los cambios en los sistemas e instalaciones de procesamiento de in- formacién. Guia de implementacién Se recomienda que los sistemas operacionales y el software de aplicacién estén sujetos a una estric- ta gestion de control de cambios. En particular, se recomienda que se consideren los puntos siguientes: a) _identificacién y registro de cambios significativos; b) _planificacién y pruebas de cambios; c) evaluacién de impactos potenciales, incluyendo los impactos de seguridad de tales cambios; 4) procedimiento formal de aprobacién para los cambios propuestos; ) comunicacién del detalle de cambios a las personas correspondientes; f)_ procedimientos para el retroceso ("fall back’), incluyendo procedimientos y responsabilidades. para la suspensién y recuperacién de cambios no exitosos y de eventos imprevistos. Se recomienda que se encuentre establecida la gestién formal de responsabilidades y los procedi- mientos para asegurar el control satisfactorio de todos los cambios de! equipamiento, software o procedimientos. Cuando se realicen cambios, se recomienda que se guarde un registro de auditoria que contenga toda la informacién relevante. Informacién adicional Un inadecuado contro! de cambios de las instalaciones de procesamiento de informacién y de los sis- temas es una causa comin de fallas de los sistemas 0 de la seguridad. Los cambios del ambiente ‘operacional, especialmente cuando se transfiere un sistema de la etapa de desarrollo a la etapa ope- racional, puede impactar en la confiabilidad de las aplicaciones (ver también 12.5.1) Se recomienda que los cambios en los sistemas operacionales se realicen tinicamente cuando hay una razén valida del negocio, tal como un inoremento en el riesgo del sistema. Los sistemas de ac- tualizacion con las tiltimas versiones del sistema operativo o aplicaciones, no son siempre del interés del negocio ya que esto puede introducir mas vulnerabilidades e inestabilidad que las versiones co- trientes. Puede también existir la necesidad de un entrenamiento adicional, costos de licencia, soporte, mantenimiento, y administracién por sobre todo, ast como también nuevo hardware espe- cialmente durante la migracién.IRAM-ISO/IEC 27002:2008 10.1.3 Segregacién de funciones Control Se recomienda que las funciones y las areas de responsabilidad se encuentren segregadas para re- ducir las oportunidades de modificaciones sin autorizacién o no intencionales, 0 una mala utilizacion de los activos de la organizacién. Guia de implementacién La segregacién de funciones es un método para la reduccién de riesgos del mal uso accidental o deli- berado de los sistemas. Se recomienda que se cuide que ninguna persona pueda acceder, modificar, 0 usar los activos sin autorizacién o deteccién. Se recomienda que la iniciacin de un evento se enouen- tre separada de su autorizaci6n. Se recomienda que cuando se disefien los controles se considere la posibilidad de colusién Las organizaciones pequefias pueden encontrar que la segregacién de funciones es dificil de alcan- Zar, pero se recomienda que el principio se aplique tanto como sea posible y practicable. Cuando sea dificil separar, se recomienda que se consideren otros controles tales como seguimiento y control de actividades, auditorias y gestién de la supervision. Es importante que la auditoria de seguridad conti- nue independiente. 10.1.4 Separacién de las instalaciones de desarrollo, de pruebas y operacionales Control Se recomienda que las instalaciones de desarrollo, de pruebas y de operacién se encuentren sepa- radas para reducir los riesgos de accesos no autorizados o cambios en los sistemas operacionales. Guia de implementacién Se recomienda que el nivel de separacién entre los ambientes operacionales, de pruebas, y de desa- rrollo, que sea necesario para prevenir los problemas operacionales, se encuentre identificado y se implementen los controles apropiados. Se recomienda que se consideren los elementos siguientes: a) que se definan y documenten las reglas para la transferencia de software del estado de desa- rrollo al estado operacional; b) que el software de desarrollo y el software operacional corran en diferentes sistemas 0 proce- sos de computacién y en diferentes dominios o directorios; ©) que los compiladores, editores, y otras herramientas de desarrollo o utiidades de sistema no se accedan desde sistemas operacionales cuando no se requiera; d) que el ambiente de prueba del sistema emule el ambiente operacional de! sistema tanto como sea posible; €) que los usuarios utilicen distintos perfiles de usuario para los sistemas operacionales y de prueba, y se recomienda que los meniies muestren mensajes de identificacién apropiados para reducir el riesgo de error, f) que los datos sensibles no se copien al ambiente de prueba del sistema (ver 12.4.2).IRAM-ISO/IEC 2700: 008 Informacién adicional Las actividades de desarrollo y de prueba pueden causar serios problemas, por ejemplo: modifica- cién no deseada de archivos o del ambiente del sistema, o falla del sistema. En este caso, hay una necesidad de mantener un ambiente conocido y estable en el cual se ejecuten pruebas significativas yy 8e prevenga el acceso inapropiado del desarrollador. Cuando el personal de desarrollo y pruebas tienen acceso al sistema operacional y a su informacién, éstos pueden introducir cédigo sin autorizacién y que no ha sido probado, o alterar datos operaciona~ les. En algunos sistemas esta capacidad puede ser utilizada para cometer fraude, o para la introduccién de cédigo no probado 0 malicioso, el cual puede causar serios problemas operacionales. Los desarrolladores y el personal de pruebas también representan una amenaza a la confidenciali- dad de la informacién operacional. Las actividades de desarrollo y pruebas pueden causar cambios no intencionales al software o a la informacion si es compartida por el mismo ambiente informético. Es deseable que se encuentren separadas las instalaciones de desarrollo, de pruebas y operaciona- les para reducir el riesgo de cambio accidental o acceso no autorizado al software operacional y a los datos del negocio (ver también 12.4.2 sobre la proteccién de los datos de prueba). 10.2 Gestion de la entrega de servicios por terceras partes ‘Objetivos: Implementar y mantener el nivel adecuado de seguridad de informacion y la provision de servicio en linea con los acuerdos de entrega de servicio por terceras partes. Se recomienda que la organizacién verifique ta implementacién de los acuerdos, el seguimiento de! cumplimiento con los acuerdos y gestione los cambios para asegurar que los servicios provistos ‘cumplen con todos los requerimientos acordados con la tercera parte. 10. 1 Provision de servicio Control Se recomienda que se asegure que los controles de seguridad, las definiciones de servicio y niveles incluidos en el acuerdo de provision de servicio de la tercera parte sean implementados, operados, y mantenidos por la tercera parte. Guia de implementacién Se recomienda que el servicio brindado por una tercera parte incluya los acuerdos de seguridad arreglados, definiciones de servicio, y aspectos de la gestién del servicio. En el caso de acuerdos de tercerizacion, se recomienda que la organizacion planee las transiciones necesarias (de la informa- ién, de las instalaciones de procesamiento de informacion, y cualquier otra cosa que necesite ser trasladada), y que asegure que se mantiene la seguridad a lo largo del perlodo de transicion Se recomienda que la organizacién se asegure de que la tercera parte mantiene suficiente capacidad de servicio junto con los planes disefiados para asegurar que se mantengan los niveles de continui- dad de servicio acordados, a pesar de fallas mayores del servicio o desastre (ver 14.1). 10.2.2 Seguimiento y revisién de los servicios de las terceras partes Control Se recomienda que los servicios, reportes y registros provistos por la tercera parte se sigan, controlen y revisen de manera regular, como asi también que se lleven a cabo auditorias de manera regular.IRAM-ISO/IEC 27002:2008 Guia de implementacién Se recomienda que el seguimiento, control y revision de los servicios de las terceras partes aseguren que se encuentren adheridos a los términos de seguridad de la informacién y las condiciones de los acuerdos, y que los incidentes de seguridad de la informacion y los problemas se manejen en forma apropiada. Se recomienda que ésto involucre una relacién y un_ proceso de gestion de servicios en- tre la organizacion y la tercera parte para: a) seguir y controlar los niveles de desempefio de servicio para verificar la adhesién a los acuerdos; b) _revisar los reportes del servicio producido por la tercera parte y concertar las reuniones regula res de progreso como las requeridas por los acuerdos; ©) prover informacién sobre los incidentes de seguridad de la informacion y revisiones de esta in- formacién por la tercer parte y la organizacién, como las requeridas por el acuerdo y las directrices 0 procedimientos de apoyo; d) _revisar los hallazgos de auditoria de la tercera parte y el registro de eventos de seguridad, pro- blemas operacionales, fallas, hallazgos de defectos y rupturas relacionadas con el servicio entregado; e) resolver y gestionar los problemas identificados. Se recomienda que la responsabilidad de la gestién de la relacién con una tercera parte se asigne a tuna persona 0 equipo de gestién del servicio. Ademés, se recomienda que la organizacién asegure que la tercera parte asigna responsabilidades para la verificacién del cumplimiento y el respeto de los requerimientos de los acuerdos. Es conveniente que se disponga de las capacidades _y recursos técnicos suficientes para el seguimiento y control de los requerimientos del acuerdo (ver 6.2.3), en particular que se cumplan los requerimientos de seguridad de la informacién. Se recomienda que se realicen las acciones apropiadas cuando se observen deficiencias en el servicio entregado. Se recomienda que la organizacién mantenga un control suficiente y la visibilidad general de todos los aspectos de seguridad para la informacién sensible 0 critica, o de las instalaciones de procesa- miento de informacion accedidas, procesadas o gestionadas por una tercera parte. Se recomienda que la organizacién asegure que se mantenga la visibilidad de las actividades de seguridad como gestién de cambios, identificacion de vulnerabilidades y reporte/respuesta de incidentes de seguridad de informacién a través de un proceso de reportes claro y definido, con formato y estructura. En el caso de tercerizaciones, la organizacién necesita estar consciente de que la responsabilidad Ul- tima por la informacién procesada por una parte tercerizada, es de la organizacién. 10.2.3 Gestion del cambio de los servicios de terceras partes Control Se recomienda que los cambios en la provision de los servicios, incluyendo el mantenimiento y las mejoras de las politicas, procedimientos y controles de seguridad de la informacion existentes, se gestionen teniendo en cuenta la crticidad de los sistemas y procesos del negocio involucrados y la reevaluacién de los riesgos. 55IRAM-ISO/IEC 27002:2008 Guia de implementacién El proceso de gestién del cambio de un servicio de tercera parte necesita tener en cuenta: a) Los cambios realizados por la organizacién para implementar, 41) mejoras a los servicios corrientes ofrecides; 2) desarrollo de cualquier aplicaciones y sistemas nuevos; 3) modificaciones o actualizaciones de las politicas y procedimientos de la organizacion; 4) nuevos controles para resolver los incidentes de la seguridad de la informacién y para me- jorar la seguridad; b) cambios en los servicios de las terceras partes para implementar: 1) cambios y mejoras de las redes; 2) uso de nuevas tecnologias; 3) _adopcién de nuevos productos o nuevas versiones/publicaciones; 4) nuevas herramientas de desarrollo y ambientes; 5) cambios de las ubicaciones fisicas de las instalaciones de servicio; 6) cambio de los vendedores. 10.3 Planificacién y aceptacién de sistemas ‘Objetivo: Minimizar el riesgo de fallas de los sistemas. Se requiere una planificacién y preparacién anticipada para garantizar la disponibilidad de capacidad y recursos adecuados a fin de entregar el desemperio requerido del sistema. Se recomienda que se realicen proyecciones de requerimientos futuros de capacidad, a fin de reducir el riesgo de sobrecarga del sistema. ntos operacionales de Se recomienda que se establezcan, documenten y prueben los requerit nuevos sistemas antes de su aprobacion y uso. 10.3.1 Gestion de la capacidad Control Se recomienda que se controle y ajuste el uso de recursos y que se realicen proyecciones de futuros requerimientos de capacidad, para asegurar el desempefio requerido de los sistemas Guia de implementacin Para cada actividad nueva y en curso, se recomienda que se identifiquen los requerimientos de ca- Pacidad. Se recomienda que la afinacién y el seguimiento del sistema se apliquen para asegurar, y, cuando sea necesario, mejorar la disponibilidad y eficiencia de los sistemas. Se recomienda que se establezcan los controles de deteccién para indicar problemas en el tiempo debido. Se recomienda que las proyecciones de futuros requerimientos de capacidad tengan en cuenta los nuevos requeri- mientos del negocio y de los sistemas, y las tendencias corrientes y proyectadas en las capacidades de procesamiento de informacién de la organizacién. 56IRAM-ISO/IEC 27002:2008 Se necesitaré poner particular atencién en cualquier recurso que demande mucho tiempo adquirir o alto costo, por lo que se recomienda que los administradores realicen un seguimiento y control de la utiizaci6n de los recursos clave del sistema. Se recomienda que ellos identifiquen tendencias en el Uso, particularmente en relacién de la aplicacién del negocio o con ta gestion de herramientas de los sistemas de informacion. Se recomienda que los gerentes utilicen esta informacion para identificar y evitar potenciales cuellos de botella y la dependencia del personal clave que podria significar una amenaza a la seguridad 0 para los servicios del sistema, y un plan de accién apropiados. 10.3.2 Aceptaci6n del sistema Control Se recomienda que se establezcan criterios de aceptacién de nuevos sistemas de informacién, actuali- zaciones y nuevas versiones, asi como también llevar a cabo pruebas adecuadas para los sistemas durante el desarrollo y previas a la aceptacion. Guia de implementacién Se recomienda que los gerentes garanticen que los requerimientos y criterios de aceptacién de nue- vos sistemas estén claramente definidos, acordados, documentados y probados. Se recomienda que los nuevos sistemas de informacién, las actualizaciones, y las nuevas versiones solamente se migren a produccién después de que se obtenga la aceptacién formal. Se recomienda que antes de que se realice la aceptacién formal se consideren los puntos siguientes: a) requerimientos de capacidad y desempefio de las computadoras; b)_recuperacion ante errores y procedimientos de reinicio, y planes de contingencia; ©) preparacién y prueba de procedimientos operativos de rutina segin normas definidas; d) conjunto acordado de controles de seguridad establecidos; ) procedimientos manuales eficaces; )_acuerdos para la continuidad de los negocios (ver 14.1); 9) evidencia de que la instalacién del nuevo sistema no afectara negativamente los sistemas exis- tentes, especialmente en los periodos pico de procesamiento, como por ejemplo durante los Ultimos dias del mes; h) _evidencia de que se ha tomado en consideracién al efecto que tiene el nuevo sistema en la se- guridad global de la organizacién; i) entrenamiento en la operacion 0 uso de nuevos sistemas; ) facilidad de uso, cémo esto afecta el desempefio del usuario y cémo evita el error humano. Para los desarrollos nuevos, se recomienda que se consulten las funciones y usuarios de operacio- nes en todas las etapas del proceso de desarrollo para garantizar la eficiencia operacional del diseio del sistema propuesto. Se recomienda que se lleven a cabo pruebas apropiadas para confirmar que todos los criterios de aceptacién fueron totalmente satisfechos. Informacién adicional La aceptacién puede incluir un proceso de certificacién y acreditacion formal para verificar que se han alcanzado adecuadamente los requerimientos de seguridad. 57IRAM-ISO/IEC 27002:2008 10.4 Proteccién contra cédigo malicioso y cédigo mévil ‘Objetivo: Proteger la integridad del software y la informacion. Es necesario tomar precauciones para prevenir y detectar la introduccién de cédigo malicioso y c6- digo mévil sin autorizacién. El software y las instalaciones de procesamiento de informacion son vulnerables a la introduccién de cédigo malicioso como, virus informaticos, gusanos de red, troyanos y bombas ldgicas. Se reco- mienda que se alerte a los usuarios acerca de los peligros del codigo malicioso. Es recomendable que los directivos, cuando corresponda, establezcan controles para prevenir, detectar, y quitar cédi- go malicioso y controlar el cédigo mévil 10. 1 Controles contra cédigo malicioso Control Se recomienda que se implementen los controles de deteccién y prevencién para la proteccién contra software malicioso, y procedimientos adecuados de concientizacién de los usuarios. Guia de implementacién Se recomienda que la proteccién contra el cédigo malicioso se base en software para la deteccién y reparacién de cédigo malicioso, conciencia de la seguridad, y de sistemas de acceso y controles para la gestién de cambios apropiados. Se recomienda que se considere la siguiente guia: a) establecer una politica formal que prohiba el uso de software no autorizado (ver 15.1.2); b) establecer una politica formal para proteger contra los riesgos asociados con la obtencién de archivos y software, ya sea desde 0 a través de redes externas, 0 por cualquier otro medio, in- dicando qué medidas protectivas se recomienda tomar; ©) conducir revisiones periédicas det contenido de software y datos de los sistemas que sustentan procesos criticos de la empresa; se recomienda que se investigue formalmente; la presencia de archivos no aprobados o correcciones no autorizadas; )_instalacién y actualizaci6n periédica de la deteccién del cddigo malicioso y el software de repa- racién para escanear las computadoras y los medios como control de precaucién, o una rutina basica; se recomienda que las verificaciones llevadas acabo incluyan: 1) [a verificacién de cualquier archivo, tanto en medios electrénicos 0 medios épticos, y los archivos recibidos a través de las redes, antes de ser usado, en busqueda de cédigo mali- cioso; 2) a verificacién de los adjuntos de correos electrénicos y las descargas en busqueda de cd- digo malicioso antes de su uso; se recomienda que esta verificacién se lleve a cabo en diferentes lugares, por ejemplo: en servidores de correo electrénico, computadoras de es- critorio, y cuando se ingrese a la red de la organizacién; 3) la verificacién de las paginas de Internet en busqueda de cédigo malicioso; ) definir procedimientos y las responsabilidades gerenciales para trabajar con la proteccién contra cédigo malicioso en los sistemas, entrenandose en su uso, informando y recuperandose frente a ataques de cédigos maliciosos (ver 13.1 y 13.2); 58IRAM-ISO/IEC 27002:2008 1) preparar adecuados planes de continuidad de! negocio para la recuperacién de ataques de oé- digo malicioso, incluyendo todos los datos necesarios y el software de copias de seguridad y los acuerdos de recuperacién (ver 14); 4) implementar procedimientos para recolectar informacién de forma regular, tal como la suscrip- cién a listas de correo ylo la verificacién de los sitios de Internet que brindan informacion acerca de nuevo cédigo malicioso; h)impiementar procedimientos para verificar la informacién relacionada con oddigo malicioso, y ‘asegurar que los boletines de alerta sean exactos e informativos; se recomienda que los gerentes garanticen que se utilizan fuentes calificadas, por ejemplo: publicaciones acreditadas, sitios de In- temet de confianza 0 proveedores que producen software de proteccion contra oddigo maiicioso, para diferenciar entre engarios y codigo maliciosos real; se recomienda que se haga consciente a todos el personal de los problemas de los virus falsos ("hoax") y de qué hacer al recibirlos. Informacién adicional El uso de dos o més productos de software de diferentes vendedores, que protegen contra el codigo malicioso a través del ambiente de procesamiento de la informacién, puede mejorar la efectividad de la proteccién contra el eddigo malicioso. Se puede instalar software para la proteccién en contra de cédigo malicioso que provea actualizacio- nes automaticas de los archivos de definicién y de los motores de busqueda, para asegurar que la proteccién esta actualizada. Ademas, este software puede ser instalado en cada escritorio para llevar ‘a cabo verificaciones automaticas. Se recomienda que se tengan cuidados para la proteccién en contra de la introduccién del cédigo malicioso durante los procedimientos de mantenimiento y los procedimientos de emergencia, los cua- les pueden evadir los controles normales de proteccién contra el cédigo malicioso. 10.4.2 Controles contra cédigo movil Control Cuando el uso de cédigo mévil esté autorizado, se recomienda que la configuracién asegure que el cédigo mévil autorizado opera de acuerdo a una politica de seguridad claramente definida, y que se prevenga que se ejecute el cddigo mévil no autorizado, Gula de implementacion ‘Se recomienda que para la proteccién en contra de las acciones de la ejecuci6n no autorizada del ‘cédigo mévil se consideren las acciones siguientes: a) @jecucién del cédigo mévil en un ambiente légicamente aislado; b) _bloqueo del uso de cédigo mévil; ¢) bloqueo de la recepcién de cédigo movi d) activacién de medidas técnicas disponible en un sistema especifico para asegurar la gestion del cédigo mévil ) control de los recursos disponibles para el acceso del cddigo mévil; f) _controles criptograficos para autenticar de forma univoca el cédigo movil.IRAM-ISO/IEC 27002:2008 Informacién adicional El cédigo mévil es el cédigo de software que se transfiere de una computadora a la otra y luego se eje- outa autométicamente y realiza una funcion especifica con poca o ninguna interaccién de los usuarios. El cédigo mévil esta asociado con un niimero de servicios de la capa intermedia ("middleware"). Ademés, para asegurar que el cédigo mévil no contenga cédigo malicioso movil, el control del codigo mévil es esencial para evitar el uso no autorizado o la ruptura de los recursos del sistema, de las re- des o de las aplicaciones y otras brechas de la seguridad de la informacion. 10.5 Resguardo ‘Objetivo: Mantener la integridad y la disponibilidad de la informacion y de las instalaciones del proce- samiento de la informacién, Se recomienda que se establezcan procedimientos de rutina para llevar a cabo la politica y estrategia de resguardo acordada (ver también 14.1) para realizar copias de resguardo de los datos y ensayar su restablecimiento en tiempo. 10.5.1. Resguardo de la informacion Controt Se recomienda que las copias de resguardo de la informacion y del software se realicen y prueben regularmente en concordancia con la politica acordada de resguardo. Guia de implementacién Se recomienda que se provean instalaciones de resquardo adecuadas para asegurar que toda la in- formacion y el software esencial pueda ser recuperado luego de un desastre 0 una falla del medio. ‘Se recomienda que se consideren los siguientes puntos de la informacién de resguardo: a) que se defina el nivel necesario de la informacién de resguardo; b) que se produzcan registros precisos y completos de las copias de resguardo y procesos de res- tauracion documentados; ©) que se refieje en los requerimientos de negocio de la organizacién la extensién (por ejemplo: resguardo completo o diferencial) y la frecuencia de los resguardos los requerimientos de se- guridad de la informacién involucrados y la criticidad de la informacion para la continuidad operativa de la organizacion; d) que las copias de resguardo se almacenen en una ubicacién remota, a una distancia suficiente para escapar de cualquier dario producido por un desastre en el sitio principal; ) que se le otorgue a la informacién de resguardo un adecuado nivel de proteccin fisica y de ambiente (ver capitulo 9) consistente con las normas aplicadas al sitio principal; se recomienda que los controles aplicados al medio en el sitio principal se extiendan para cubrir el sitio de res- guardo; f) que se prueben los medio de resguardo regularmente para asegurar que se puede confiar en ellos en casos de emergencia, cuando sea necesario;IRAM-ISO/IEC 27002:2008 9) que los procedimientos de resguardo se verifiquen y prueben regularmente para asegurar que son efectivos y que pueden ser completados dentro del tiempo asignado en los procedimientos operacionales para la recuperacion; h) en situaciones donde la confidencialidad es de importancia, se recomienda que el resguardo se proteja por medios de encriptacion. Se recomienda que el procedimiento de resguardo para los sistemas individuales se pruebe regular- mente para asegurar que cumple con los requerimientos de los planes de continuidad del negocio (ver capitulo 14). Para los sistemas criticos, se recomienda que los acuerdos de resguardo cubran toda Ia informacion de sistemas, aplicaciones, y los datos necesarios para la reconstruccién del sis- tema completo en un evento de desastre. Se recomienda que se determine el periodo de retencién de la informacién esencial de negocio, asi como también cualquier requerimiento para archivar copias que deben ser guardadas permanente- mente (ver 15.1.3). Informacién adicional Los procedimientos de resguardo pueden estar automatizados para facilitar el proceso de resguardo y de recuperacién. Se recomienda que tales soluciones automatizadas estén suficientemente proba- das, previas a su implementacién y a intervalos regulares. 10.6 Gestion de la seguridad de la red ‘Objetivo: Garantizar la seguridad de la informacion en las redes y la protecci6n de la infraestructura de soporte. La gestién segura de las redes, las cuales pueden abarcar los limites organizacionales, requieren consideraciones cuidadosas para el flujo de datos, implicaciones legales, seguimiento y proteccion. Pueden requerirse controles adicionales para proteger la informacion sensible que circule por redes piiblicas. 10.6.1 Controles de redes Control Se recomienda que las redes estén adecuadamente gestionadas y controladas, para protegerias de amenazas, y para mantener un ambiente seguro para los sistemas y las aplicaciones que las utilizan, incluyendo la informacién en transito. Guia de implementacion Se recomienda que los administradores de red implementen controles para asegurar la seguridad de la informacion en las redes, y la proteccién de los servicios conectados contra acceso no autorizado. En particular, se recomienda que se considere los puntos siguientes: a) que la responsabilidad operacional para las redes se encuentre separada de las operaciones de computadoras, segin corresponda (ver 10.1.3); b) que se establezcan los procedimientos y responsabilidades para la gestién del equipamiento remoto, incluyendo los equipos en las areas de usuarios; 6IRAM-ISO/IEC 27002:2008 ) que se establezcan controles especiales para salvaguardar a confidencialidad e integridad de los datos que pasan a través de redes publicas, y para proteger los sistemas conectados (ver 11.4 y 12.3); también pueden requerirse controles especiales para mantener la disponibilidad de los servicios de red y de las computadoras conectadas; d) la aplicacién de un método de identificacién apropiado, asi como de seguimiento para permitir que se lleve un registro de las acciones relevantes de seguridad; e) que las actividades gerenciales se encuentren estrechamente coordinadas tanto para optimizar el servicio de red para la organizacién como para garantizar que los controles se aplican con- sistentemente a través de toda la infraestructura de procesamiento de informacién. Informacién adicional En la ISO/IEC 18028, Information technology — Security techniques — IT network security, puede en- contrarse informacién adicional acerca de seguridad de redes. 10.6.2 Seguridad de los servicios de red Controt Se recomienda que se identifique e incluya en cualquier acuerdo de servicios de redes las caracteris- ticas de seguridad, niveles de servicio y requerimientos de gestién de todos los servicios de redes, tanto los servicios provistos por la organizacién como tercerizados, Guia de implementacién ‘Se recomienda que se determine y controle regularmente la capacidad del proveedor de servicio de red para gestionar los servicios acordados en un modo seguro, y que se acuerde el derecho de auditarlo. Se recomienda que se identifiquen los acuerdos de seguridad necesarios para servicios particulares, tales como caracteristicas de seguridad, niveles de servicio y los requerimientos de gestion. Se reco- mienda que la organizacién asegure que los proveedores de servicios de redes implementan estas medidas. Informacién adicional Los servicios de red incluyen la provisién de las conexiones, servicios de red privados, y redes de va- lor agregado, y soluciones de seguridad en redes, tales como “firewalls” y sistemas de deteccién de intrusos. Estos servicios pueden variar desde un simple ancho de banda no administrado hasta ofer- tas complejas de valor agregado. Las caracteristicas de seguridad de los servicios de redes pueden ser: 1a) tecnologia aplicada para la seguridad de servicios de red, tales como autenticacién, encripta- Cién, y controles de conexién a redes; b) pardmetros técnicos requeridos para una conexién segura con los servicios de red en concor- dancia con las reglas de seguridad y de conexién a la red; ©) procedimientos para el uso del servicio de red para restringir el acceso a los servicios o aplica- ciones de red, cuando corresponda.IRAM-ISO/IEC 27002:2008 10.7 Manejo de los medios ‘Objetivo: Prevenir la divulgacion, modificacion, remocion o destruccion no autorizada de los activos, y la interrupcion de las actividades de! negocio. Se recomienda que los medios de almacenamiento se controlen y protejan fisicamente. Se recomienda que se establezcan procedimientos operatives apropiados para proteger documentos, medios de almacenamiento (por ejemplo: cintas, discos), datos de entrada/salida y documentacion del sistema contra divulgacién, modificacién, remocién y destruccién no autorizados. 10.7.1 Gestion de medios removibles Control Se recomienda que para la gestién de los medios informaticos removibles existan procedimientos. Guia de implementacién ‘Se recomienda que se consideren las siguientes directrices para la gestion de medios removibles: a) siya no se requieren, que los contenidos de cualquier medio reusable que esta por ser elimi- nado de la organizacién se hagan irrecuperables; b) cuando sea necesario y practico, que se requiera la autorizacién para la eliminacién de los me- dios informaticos de la organizacién y que se lleve un registro de tales eliminaciones para mantener la trazabilidad para una auditoria; ©) que todos los medios se almacenen en un ambiente seguro y protegido, de acuerdo con las especificaciones de los fabricantes; d) que la informacién almacenada en medios, la cual necesite estar disponible més tiempo que el de la vida uti! de! medio (en concordancia con las especificaciones del fabricante) también se almacenen en otro medio para evitar la pérdida de la informacién por el deterioro del medio; ) que se considere llevar un registro de los medios removibles para limitar la oportunidad de pér- dida de datos; f) que las unidades de medios removibles s6lo se encuentren activas si existe una raz6n para ello. ‘Se recomienda que todos los procedit documentados. ntos y los niveles de autorizacién se encuentren claramente Los medios informaticos removibles incluyen cintas, discos, memorias portatiles, discos rigidos re- movibles, CD, DVD, y medios impresos. 10.7.2 Eliminacién de medios Control Se recomienda que se eliminen los medios de forma segura y protegida utilizando procedimientos formales cuando no se los necesite mas. 63IRAM-ISO/IEC 27002:2008 Guia de implementacion Se recomienda que los procedimientos formales para la disposicién segura de los medios minimice el riesgo de una fuga de informacién sensible a personas no autorizadas. Se recomienda que los pro- cedimientos para la disposicién segura del medio que contenga informacién sensible se encuentren en proporci6n con la sensibilidad de esa informacién. Se recomienda la consideracién de los puntos siguientes: a) que los medios que contengan informacion sensible se encuentren almacenados y eliminados de manera segura, por ejemplo: incinerandolos 0 rompiéndolos en pequefios trozos, o elimi- nando los datos para evitar que se utilicen por otra aplicacién dentro de la organizacion; b) que se establezcan procedimientos para identificar los articulos que podrian requerir disposi- cién segura; c) puede resultar ms sencillo disponer que todos los medios se recolecten y eliminen de manera segura, en lugar de intentar separar los articulos sensibles; d) muchas organizaciones offecen servicios de recolecoién y eliminacién de papeles, equipos y medios. Se recomienda que se seleccione cuidadosamente a un contratista que cuente con controles y experiencia adecuados; ) cuando sea posible, se recomienda que se lieve registro de la eliminacién de articulos sensi- bles para mantener la trazabilidad para la auditoria. Cuando se acumulen medios para su eliminacin, se recomienda que se considere el efecto de agregacién, el cual puede causar que la acumulacién de una gran cantidad de informacién no sensi ble pueda volveria sensible. Informacién adicional La informacién sensible podria ser divulgada a través de una disposici6n descuidada de los medios (ver también 9.2.6 para tener informacion sobre la disposicién de equipos).. 10.7.3 Procedimientos para el manejo de la informacién Control Se recomienda que se establezcan procedimientos para el manejo y almacenamiento de la informa- cién, para protegerla contra su uso inadecuado 0 divulgacién no autorizada. Guia de implementacién Se recomienda que se establezcan los procedimientos para el manejo, procesamiento, almacena- miento y comunicacién de la informacién consistente con su clasificacién (ver 7.2). Se recomienda que se consideren los puntos siguientes: a) manejo y rotulado de todos los medios seguin su nivel de clasificaci6n; b) _restricciones de acceso para prevenir el acceso de personal no autorizado; ©) mantenimiento de un registro formal de los receptores autorizados de datos; 4) garantizar que los datos de entrada son completos, que el procesamiento se completa correc- tamente y que se valida la salida; ) proteccién de los datos que se encuentren en cola de espera de salida en un nivel consistente con su sensibilidad;IRAM-ISO/IEC 27002:2008 1) almacenamiento de los medios en concordancia con las especificaciones del fabricante; ) mantener la distribucion de datos en un nivel minimo; h) marcado claro de todas las copias de medios a fin de que el receptor autorizado las advierta; i) revision a intervalos reguares do los istados de dstibucién y los Iistados de receptors auton zados. Informacién adicional Estos procedimientos se aplican a la informacién existente en documentos, sistemas de computa- cién, redes, computacién mévil, comunicaciones méviles, correo, correo de voz, comunicaciones de voz en general, multimedia, instalacionesiservicios postales, uso de una maquina de fax y cualquier otro item sensible, por ejemplo: cheques en blanco, facturas. 10.7.4 Seguridad de la documentacién del sistema Control Se recomienda que la documentacion del sistema esté protegida contra accesos no autorizados. Guia de implementacién Para la seguridad de la documentacién del sistema, se recomienda que se tenga en cuenta los pun- tos siguientes: a) que la informacién del sistema se almacene en forma segura; b) que el listado de acceso a la documentacién del sistema se mantenga al minimo y autorizado or el propietario de la aplicacién; ©) que la documentacién del sistema almacenada en una red publica, o suministrada a través de Una red piblica, se proteja de manera adecuada Informacién adicional La documentacién del sistema puede contener una variedad de informacién sensible, por ejemplo: descripciones de los procesos de las aplicaciones, procedimientos, estructuras de los datos, proce- sos de autorizacién. 10.8 Intercambio de la informacion (Objetivo: Mantener la seguridad de la informacion y el software intercambiados dentro de una organi- zacién y con cualquier entidad externa. Se recomienda que los intercambios de informacién y software entre organizaciones se basen en una Politica formal de intercambio, llevada a cabo en linea con los acuerdos de intercambio, cumpliendo con la legislacién correspondiente (ver 15). ‘Se recomienda que se establezcan los procedimientos y normas para proteger la informacién y el medio fisico que contiene la informacion en transito. 65IRAM-ISO/IEC 27002:2008 10.8.1 Politicas y procedimientos de intercambio de la informacién Control Se recomienda que se establezcan politicas, procedimientos y controles formales para proteger el in- tercambio de informacién a través del uso de todos los tipos de instalaciones de comunicacion. Guia de implementacién Se recomienda que los procedimientos y controles @ seguir cuando se utilizan las instalaciones de comunicacién electronica para el intercambio de la informacion consideren los siguientes puntos: a) procedimientos disefiados para proteger la informacién intercambiada de la intercepci6n, copia, ‘modificacién, mal direccionamiento y destruccién; b) procedimientos para la deteccién de y la proteccién contra el c6digo malicioso que puede ser transmitido a través del uso de comunicaciones electronicas (ver 10.4.1); ©) procedimientos para la proteccién de la informacién electronica sensible comunicada que se ‘encuentra en forma de adjunto; 4) politicas o directrices que den lineamientos sobre el uso aceptable de las instalaciones de co- municacién electronicas (ver 7.1.3); e) procedimientos para el uso de comunicaciones inalambricas, teniendo en cuenta los riesgos particulares involucrados; f)_responsabilidades de! empleado, contratista y cualquier otro usuario de no comprometer a la ‘organizacién, por ejemplo, a través de la difamacién, hostigamiento, suplantacién de identidad, reenvio de cadenas de cartas, compras no autorizadas, etc.; 9) uso de técnicas criptogréficas, por ejemplo, para proteger la confidencialidad, integridad y la autenticidad de la informacién (ver 12.3); h) directrices de retencion y eliminacién para toda la correspondencia del negocio, incluyendo men- ‘sajes, en concordancia con las leyes y regulaciones correspondienttes, locales y nacionales: i) no dejar la informacion critica o sensible en las instalaciones de impresién, por ejemplo: copia- doras, impresoras, y equipos de fax, que pueden ser accedidos por personal no autorizado; J) establecer controles y restricciones asociadas a las instalaciones de reenvio de comunicacién, or ejemplo: reenvio automatico de correo electrénico a direcciones externas; k) recordar al personal que deben tomar las precauciones adecuadas, por ejemplo: de no revelar informacion sensible para evitar que por casualidad se escuche o intercepte cuando se realiza una llamada telefénica por: 1) gente en su cercania inmediata, particularmente cuando se utiliza teléfonos méviles; 2) intervenciones del cableado, y otras formas de indiscreciones a través del acceso fisico al ‘equipo telefonico o a la linea telefénica, 0 usando dispositivos de busqueda; 3) gente al lado del receptor; ) no dejar mensajes que contengan informacién sensible en contestadores automatticos debido a que pueden ser reproducidos por personas no autorizadas; almacenadas en los sistemas co- munes, 0 incorrectamente, como resultado de un error de discado;IRAM-ISO/IEC 27002:2008 m) recordar al personal acerca de los problemas del uso de equipos de fax, como ser: 1) el acceso no autorizado a {a casilla de almacenamiento de mensajes para la recuperacion; 2) la programacién deliberada o accidental de equipos para enviar mensajes a nlimeros es- pecificos; 3) envio de documentos y mensajes al nimero equivocado por haber discado mal o por haber utilizado un nimero almacenado equivocado; n) recordar al personal que no se registren datos demogréficos, tales como direcciones de correo electrénico u otra informacion personal, en cualquier software para evitar su recuperacién para un uso no autorizado ©) recordar al personal que los modernos equipos de fax y las fotocopiadoras tienen memoria pa- ra guardar paginas en caso de falla de papel o de la transmisién, la cual sera impresa una vez que la falla haya sido solucionada. ‘demas, se recomienda que se recuerde al personal que no mantengan conversaciones confidencia- les en lugares piblicos u oficinas abiertas asi como tampoco en lugares de reunién sin paredes a prueba de sonido. Se recomienda que las instalaciones de intercambio de informacion cumplan con los requerimientos legales correspondientes (ver 15). Informacién adicional El intercambio de la informacion puede ocurrir a través del uso de diferentes tipos de instalaciones de comunicacién, incluyendo correo electrénico, voz, fax, y video El intercambio del software puede ocurrir mediante un numero distinto de medios, ya sea descargan- dolo desde Internet hasta adquiriéndolo de vendedores que venden productos enlatados. Se recomienda que se consideren las implicancias comerciales, legales, y de seguridad asociadas con el intercambio de electronico de datos, comercio electronico, comunicaciones electronicas y los requerimientos para los controles de éstos. La informacién puede verse comprometida debido a una carencia del cuidado, politicas 0 procedi- mientos para el uso de las instalaciones de intercambio de informacién, por ejemplo, que se escuche de casualidad utilizando un teléfono mévil en un lugar publico; envio equivocado de un mensaje de correo electronico; que se escuchen los contestadores automaticos, acceso no autorizado a llamar a los sistemas de correo de voz 0 el envio accidental de un fax a un equipo de fax equivocado. Las operaciones comerciales pueden verse interrumpidas y la informacion puede verse comprometi- da si las instalaciones de comunicacién fallan, estan sobrecargadas 0 interrumpidas (ver 10.3 y 14). La informacion puede verse comprometida si es accedida por usuarios no autorizados (ver 11). 10.8.2 Acuerdos de intercambio Control Se recomienda que se establezcan acuerdos de intercambio de informacion y de software entre la organizacion y las terceras partes. 67IRAM-ISO/IEC 270022008 Guia de implementacién Se recomienda que los acuerdos de intercambio consideren las condiciones de seguridad siguientes: a) responsabilidades gerenciales para controlar y notificar la transmisién, envio y recepcién; b) _procedimientos para notificar al emisor de la transmisién, envio y recepcion; c) procedimientos para asegurar la trazabilidad y el no repudio; d)_normas técnicas minimas para el empaquetado y la transmisi6n; ) acuerdos de fideicomiso; ) _normas de identificacion de los servicios de mensajeria; 9) las responsabilidades y obligaciones en caso de incidentes de seguridad de informacion, tales como pérdida de datos; h) uso de un sistema de rotulado acordado para la informacion sensible o critica, que asegure que 1 significado de los rotulados se entienda inmediatamente y que la informacién se proteja ade- ‘cuadamente; i) la propiedad y las responsabilidades por la proteccién de datos, “copyright", cumplimiento de las licencias de software y consideraciones similares (ver 15.1.2 y 15.1.4); j) _normas técnicas para el grabado y la lectura de la informacion y del software; k) cualquier control especial que pueda ser requerido para proteger articulos sensibles, como las claves criptograficas (ver 12.3) Se recomienda que las politicas, procedimientos, y normas se establezcan y mantengan para prote- ger la informacién y medios fisicos en trénsito (ver también 10.8.3), y se recomienda que se encuentren referenciados en tales acuerdos de intercambio Se recomienda que el contenido de seguridad de cualquier acuerdo refieje la sensibilidad de la infor- macién comercial involucrada Informacién adicional Los acuerdos pueden ser por via electronica o manual, y pueden tomar la forma de contratos forma- les © condiciones de empleo. Para informacion sensible, se recomienda que los mecanismos especificos utilizados para el intercambio de tal informacién sean consistentes para todas las organi- zaciones y los tipos de acuerdos. 10.8.3 Medios fisicos en transito Control Se recomienda que los medios que contengan informacion estén protegidos contra el acceso no au- torizado, mal uso o corrupcién durante el transporte mas alld de los limites fisicos de la organizacion. Guia de implementacion Para proteger los medios de informacién que estan siendo transportados entre sitios, se recomienda que se consideren las directrices siguientes: a) que se utilicen medios de transporte o servicios de mensajeria confiables; b) que se acuerde con la gerencia una lista de servicios de mensajeria autorizados;IRAM-ISO/IEC 27002:2008 c) que se desarrollen procedimientos para la verificacion de la identificacin de los servicios de mensajeria; d) que el embalaje sea suficiente para proteger el contenido contra cualquier daho fisico que pue- da ocurrir durante el transito y en concordancia con cualquier especificacién del fabricante (por ejemplo, para el software), la protecci6n en contra de cualquier factor ambiental que pueda re- ducir la efectividad de recuperacién del medio, tal como la exposicién al calor, humedad, 0 campos electromagnéticos; e) que se adopten controles, cuando sea necesario, para proteger la informacién sensible de la divulgacién 0 modificacién no autorizada; los ejemplos incluyen: 1) uso de contenedores cerrados; 2) entrega en mano; 3) embalaje que revele si ha sido manipulado (el cual delata cualquier intento de acceso); 4) en casos excepcionales, dividiendo el envio en mas de un paquete y envidndolos por dife- rentes rutas. Informacién adicional La informacién puede ser vulnerable al acceso no autorizado, mal uso 0 corrupcién durante el transpor- te fisico, por ejemplo cuando se realiza el envio mediante el servicio postal o servicio de mensajeria. 10.8.4 Mensajeria electronica Control Se recomienda que se proteja de forma adecuada la informacion involucrada en los mensajes elec- tronicos. Guia de implementacion Se recomienda que los mensajes electrénicos incluyan las consideraciones de seguridad siguientes: a) proteccién de mensajes contra el acceso no autorizado, modificaciones o denegacién de servicio; b) la correcta asignacién de la direccién y el transporte del mensaje; ©) confiabilidad y disponibilidad general del servicio; d) consideraciones legales, por ejemplo, requerimientos de las firmas electrénicas; e) obtencién de aprobacién previa al uso de los servicios piblioos exteros tales como mensajeria instantanea o archivos compartidos; f) _niveles altos de controles de autenticacion para los accesos desde las redes publicamente accesi- bles. Informacién adicional La mensajeria electronica como el correo electrénico, el intercambio de datos electronicos (EDI), y la mensajeria instantanea juegan un rol cada vez més importante en las comunicaciones de negocios. La mens@jeria electrénica tiene diferentes riesgos que las comunicaciones basadas en papel.IRAM-ISO/IEC 27002:2008 10.8.5 Sistemas d formacién del negor Control ‘Se recomienda que se desarrollen e implementen politicas y procedimientos para proteger la infor- maci6n asociada con la interconexién de los sistemas de informacién del negocio. Guia de implementacién Se recomienda que la consideracién que se de a la seguridad y a sus implicancias en el negocio al interconectar dichas instalaciones incluyan: a) vulnerabilidades conocidas en los sistemas administrativos y contables cuando la informacion se encuentra compartida entre diferentes partes de la organizacién; b) vulnerabilidades de la informacién en los sistemas de comunicacién del negocio, por ejemplo llamadas telefonicas o llamadas en conferencia grabadas, confidencialidad de las llamadas, almacenamiento de faxes, apertura del correo, distribucién del correo; ©) politicas y controles apropiados para gestionar cémo se comparte la informacién; 4) categorias excluyentes de informacién sensible del negocio y documentos clasificados, si el sistema no provee un nivel adecuado de proteccion (ver 7.2); e) restricci6n de acceso a la informacién diaria relacionada a individuos seleccionados, por ejem- plo, trabajo personal en proyectos sensibles; f) _categorias del personal, contratistas 0 socios de negocios que tienen permitido el uso del sis- tema y de las instalaciones desde las cuales se puede acceder (ver 6.2 y 6.3); 9) restriccién de las instalaciones seleccionadas a categorias especificas de usuario; h)__identificacién de! nivel de los usuarios, por ejemplo, empleados de la organizacién 0 contratis- tas en directorios para el beneficio de otros usuarios; i) retencién y el resguardo de la informacion mantenida en el sistema (ver 10.5.1); j)requerimientos y acuerdos de recuperacién (ver 14), Informacién adicional Los sistemas de informacién de oficina son oportunidades para diseminar y compartir la informacion de negocios de forma mas rapida, que utilizan una combinacién de: documentos, computadoras, computadoras méviles, correo, correo de voz, comunicaciones de voz en general, multimedia, servi- cios/instalaciones postales y equipos de fax. 10.9 Servi ios de comercio electronica ‘Objetivo: Garantizar la seguridad de los servicios de comercio electronico, y su uso seguro, ‘Se recomienda que se consideren las implicancias de seguridad asociadas con el uso de los servi- cios de comercio electrénico, inciuyendo transacciones en linea, y los requerimientos de control También se recomienda que se considere la integridad y la disponibilidad de la informacion electré- nica publicada a través de sistemas publicamente disponibles. 70IRAM-ISO/IEC 27002:2008 10.9.1 Comercio electrénico Control Se recomienda que la informacién involucrada en el comercio electrénico que pasa por las redes pu- blicas se encuentre protegida de actividades fraudulentas, disputas de contrato, divulgaciones o modificaciones no autorizadas. Guia de implementacion Se recomienda que las consideraciones de seguridad para el comercio electrénico incluyan lo si- guiente: a) el nivel de confidencialidad que requiere cada parte de las otras partes, exigiendo su identifica- cién, por ejemplo, a través de autenticacion; b) _procesos de autorizacién asociados con quien puede definir los precios, emisiOn o firma de los principales documentos comerciales; ©) asegurar que los socios comerciales estan completamente informados de sus autorizaciones; d) determinar y cumplir requerimientos de confidencialidad, integridad, prueba de envio y recep- cién de documentos importantes y el no repudio de los contratos, por ejemplo, asociados con los procesos de licitacién y contractos; ) elnivel de confianza requerido en la integridad de la lista de precios informada; f) la confidencialidad de cualquier dato o informacién sensible; 9) [a confidencialidad e integridad de cualquier transaccién de orden, informacion de pago, deta- lles de direcciones de envio, y confirmacién de recepciones; h) el grado de la verificacion apropiada de la informacion de pago provista por un client i) seleccionar fa forma mas apropiada de liquidacién de pagos para prevenirse del fraude; j) el nivel de proteccién requerido para mantener la confidencialidad e integridad de la informa- cién de las ordenes; k)__evitar la pérdida o duplicacién de la informacion de transacciones; |) responsabilidades asociadas con cualquier transaccién fraudulenta; m) requerimientos de seguros. Muchas de la consideraciones antes mencionadas pueden ser alcanzadas por la aplicacién de con- troles criptograficos (ver 12.3), teniendo en cuenta el cumplimiento de los requerimientos legales (ver 15.1, especialmente 15.1.6 sobre la ley de la criptografia), Se recomienda que los acuerdos de comercio electronico entre los socios comerciales se sustenten en un acuerdo documentado, en el cual ambas partes cumplan los términos de comercio acordados, incluyendo los detalles de autorizacién (ver b) arriba). Pueden ser necesarios otros acuerdos con proveedores de servicios de informacion y de redes. Se recomienda que los sistemas piblicos de comercio hagan conocer los términos de! negocio a los clientes. nIRAM-ISO/IEC 27002:2008 ‘Se recomienda que se considere la resistencia del servidor empleado para el comercio electrénico frente a un ataque, y las implicaciones de seguridad de cualquier interconexion de red requerida para ta implementacion de los servicios de comercio electrénico (ver 11.4.6). Informacién adicional El comercio electronico es vulnerable a un gran numero de amenazas de red que pueden resultar en actividades fraudulentas, disputas de contrato, y la divulgacién 0 modificacién de la informacion. El comercio electrénico puede hacer uso de métodos de autenticacién seguros, por ejemplo usando criptografia de clave publica y firmas digitales (ver también 12.3) para reducir los riesgos. También pueden ser utilizadas terceras partes confiables, cuando tales servicios sean necesarios. 10: 2 Transacciones en linea Controt Se recomienda que Ia informacién involucrada en las transacciones en linea se encuentre protegida para prevenir transacciones incompletas, que se direccionen erréneamente, alteraciones no autoriza- das de mensajes, divulgaciones no autorizadas, duplicacién o repeticion no autorizada de mensajes. Guia de implementacién Se recomienda que las consideraciones de seguridad para las transacciones en linea incluyan lo si- guiente: a) el uso de firmas electrénicas para cada una de las partes involucradas en la transaccion; b) todos los aspectos de Ia transaccién, esto es para asegurar que: 1) las credenciales de los usuarios de todas las partes se validen y verifiquen; 2) la transaccién se mantenga confidencial; y 3) se mantenga la privacidad asociada con todas las partes involucradas; ©) que los caminos de las comunicaciones entre las partes estén encriptados; 4) que se utilicen protocolos seguros para la comunicacién entre todas las partes involucradas; €) que se asegure que el almacenamiento de los detalles de las transacciones estén ubicados fuera de cualquier ambiente publicamente accesible, por ejemplo sobre una plataforma de al- macenamiento existente en la Intranet organizacional, y no mantenida y expuesta sobre un medio de almacenamiento directamente accesible desde Internet; f) que cuando se utilice autorizacién segura (por ejemplo para los propésitos de emitir y mantener firmas digitales y/o certificados digitales) la seguridad esté integrada y embebida a través de todo el proceso de gestién de certificacion/firma, de punta a punta Informacion adicional La extensién de los controles adoptados necesitara ser proporcional al nivel de riesgo asociado con cada forma de transaccién en linea. Las transacciones pueden necesitar cumplir con leyes, reglas, y regulaciones en la jurisdiccion en la cual la transaccién es generada, procesada, completada, y/o almacenada. Existen muchas formas de transacciones que pueden ser realizadas en linea, por ejemplo, contrac- tual, financiera, etc. 2IRAM-ISO/IEC 270022008 10.9.3 Informacién publicamente disponible Controt Se recomienda que la integridad de la informacién que esta disponible publicamente se encuentre protegida para prevenir modificaciones no autorizadas. Guia de implementacion Se recomienda que el software, los datos y otra informacion que requiere un alto nivel de integridad, que se haga disponible en un sistema publicamente disponible, esté protegida por mecanismos ade- cuados, por ejemplo, firma digital (ver 12.3). Se recomienda que el sistema de acceso publico se pruebe contra debilidades y fallas antes de que se haga disponible la informacién. Se recomienda que exista un proceso formal de aprobacién antes de que la informacién esté dispo- nible en forma publica. Ademés, se recomienda que se verifiquen y aprueben todas las entradas provistas del exterior hacia el sistema. Se recomienda que los sistemas de publicacién electrénicos, especialmente aquellos que permiten la retroalimentacién y el ingreso directo de informacion, se encuentren cuidadosamente controlados para que: a) la informaci6n que se obtenga cumpla con cualquier legislacion de proteccién de datos (ver 15.1.4); b) a informacién ingresada y procesada por el sistema de publicacion se procese completamente y de forma exacta de manera puntual; ¢c) la informacién sensible se proteja durante la recopilacién, procesamiento y almacenamiento; d) el acceso al sistema de publicacién no permita acceso no intencional a las redes a las cuales estd conectado el sistema. Informacién adicional La informacién en un sistema piblicamente disponible, por ejemplo, la informacién en un servidor de red accesible via Internet, puede necesitar cumplir con leyes, reglas, y regulaciones en la jurisdiccién en la cual se encuentre ubicado el sisterna donde se esté lievando a cabo el intercambio o donde re- side el duefio. Las modificaciones no autorizadas de la informacion publicada puede dafiar la reputacion de la organizaci6n que publica, 10.10 Seguimiento y control Objetivo: Detectar las actividades no autorizadas de procesamiento de informacion. Se recomienda que los sistemas se sigan y controlen y se lleve un registro de los eventos de seguri- dad de la informaci6n. Se recomienda que se lleven registros de las actividades ("log") de los operadores y registro de las acciones fallidas para asegurar que se identifiquen los problemas de los sistemas de informacion. Se recomienda que la organizacién cumpla con todos los requerimientos legales que se apliquen a sus actividades de seguimiento, control y registro. ‘Se recomienda que el seguimiento y control del sistema se utilice para verificar la efectividad de los, controles adoptados y para verificar la conformidad con un modelo de politica de acceso. 73IRAM-ISO/IEC 27002:2008 10.10.1 Registro de auditoria Controt Se recomienda que se produzcan y mantengan registros de auditoria en los cuales se registren las actividades, excepciones, y eventos de seguridad de la informacién de los usuarios, por un periodo acordado para ayudar en futuras investigaciones y en el seguimiento del control de acceso. Guia de implementacion Se recomienda que las auditorias de las sesiones incluyan, cuando corresponda: a) _identificacién de los usuarios; b) fechas, tiempos, y detalles de los eventos principales, por ejemplo, inicio y cierre de sesion; ¢) la identidad de la computadora o la ubicacién si es posible; 4) registros de intentos de acceso al sistema exitosos y rechazados; ) registros de intentos de acceso a los datos u otro recurso, exitosos y rechazados; f) cambios en la configuracién del sistema; 9) uso de privilegios; h) uso de utilitarios y aplicaciones de sistemas; i) archivos accedidos y el tipo de acceso; i) direcciones de redes y protocolos; k) _alarmas ejecutadas por el sistema de contro! de accesos; |) activacién y desactivacién de los sistemas de proteccién, tales como sistemas antivirus y sis- temas de deteccién de intrusos. Informacién adicional Las auditorias de sesi6n pueden contener datos personales confidenciales. Se recomienda que se tomen las medidas de proteccién de privacidad adecuadas (ver también 15.1.4). Cuando sea posible, se recomienda que los administradores del sistema no tengan permiso para borrar o desactivar los registros de sus propias actividades (ver 10.1.3). 10.10.2 Seguimiento del uso del sistema Control Se recomienda que se establezcan procedimientos para supervisar el uso de las instalaciones de procesamiento de informacion y que se revisen de forma regular los resultados de las actividades de seguimiento, Guia de implementacion Se recomienda que el nivel requerido de! seguimiento de las instalaciones individuales se determine or una evaluacion de riesgos. Se recomienda que una organizacién cumpla con todos los requeri- mientos aplicables para sus actividades de seguimiento. Es conveniente que se consideren las areas siguientes: 4a) b) a) e) IRAM-ISO/IEC 27002:2008 acceso autorizado, incluyendo detalles tales como: 1) [a identificacién del usuario; 2) la fecha y hora de eventos clave; 3) los tipos de eventos; 4) los archivos que fueron accedidos; 5) las utiidades y programas utilizados; todas las operaciones de privilegio, como: 1) _utiizacién de cuentas privilegiadas, por ejemplo, supervisor, usuario raiz, administrador; 2)_ inicio y detencién del sistema; 3) dispositivos de entrada o salida adjuntados 0 removidos; intentos de acceso no autorizados, como: 1) acciones de usuarios fallidas o rechazadas; 2) acciones fallidas o rechazadas que involucran datos y otros recursos; 3) violaciones a la politica de accesos y notificaciones de las entradas a la red y cortafuegos; 4) _alertas de los sistemas de deteccién de propietarios intrusos; alertas 0 fallas del sistemas, tales como: 1) alertas o mensajes de la consola; 2) _excepciones de las sesiones del sistema; 3) alarmas de la gestién de redes: 4) alarmas activadas por el sistema de control de accesos; cambios, 0 intentos de cambio, de los controles y de la configura‘ ridad. n de los sistemas de segu- Se recomienda que la frecuencia con que se revisan los resultados de las actividades de seguimiento, dependa de los riesgos involucrados. Se recomienda que los factores de riesgo a ser considerados in- cluyan a) la ctiticidad de los procesos de aplicacién; b)_ el valor, la sensibilidad, y la gravedad de la informacién involucrada; ©) la experiencia pasada de infitraciones y mala utiizacién del sistema, y la frecuencia con que se han explotado las vulnerabilidades; d) la extensi6n de la interconexién del sistema (particularmente las redes publicas); €) las instalaciones de registros que han sido desactivadas. Es necesario el uso de procedimientos de seguimiento y control para asegurar que los usuarios reali- cen solamente las actividades para las cuales han sido explicitamente autorizados. 5IRAM-ISO/IEC 27002:2008 Una revisién de los registros involucra el entendimiento de las amenazas enfrentadas por el sistema y la manera en la cual esto puede activarse. En 13.1.1 se dan ejemplos de los eventos que pueden requerir mayor investigacién en caso de incidentes de seguridad de la informaci6n. 10.10.3 Proteccién de la informacién de los registro de actividad (“logs”) Control! . Se recomienda que las instalaciones de registro y la informacion de registro estén protegidas contra la manipulacién y procesos no autorizados. Guia de implementacién Se recomienda que los controles apunten a la proteccién contra cambios no autorizados y problemas operacionales con las instalaciones de registro de sesién, incluyendo: a) _alteraciones de los tipos de mensajes que son grabados; b) que los archivos de sesién se editen 0 eliminen; ¢) que la capacidad de almacenamiento del medio del archivo de sesién se exceda, resultando en la falla para registrar los eventos o sobrescribiendo eventos registrados en el pasado. Algunos registros de auditoria pueden requerir ser archivados como parte de la politica de retencion de registros 0 a causa de requerimientos de recolectar y retener evidencia (ver también 13.2.3). Informacién adicional Los sistemas de registro de sesién contienen un gran volumen de informacién, mucha de la cual es ex- trafia al seguimiento y control del sistema. Para ayudar a identificar los eventos significativos para propésitos de seguimiento de la seguridad, se recomienda que se considere el copiado automattico de los tipos de mensajes apropiados a un segundo registro de sesién, ylo el uso de utilitarios de sistema adecuados o herramientas de auditoria para realizar la investigacién y racionalizacion de los archivos. Los registros de sesién del sistema necesitan ser protegidos, debido a que si los datos pueden ser modificados o los datos de éstos pueden ser borrados, su existencia puede crear una falsa sensacion de seguridad. 10.10.4 Registros de actividad de administrador y operador Controt Se recomienda que se lleve registro de las actividades del administrador del sistema y del operador del sistema. Guia de implementacién Se recomienda que los registros incluyan: a) fecha y hora en el cual ocurre un evento (éxito 0 falla); b) la informacién acerca del evento (por ejemplo, los archivos manipulados) o la fallas (por ejem- plo, los errores ocurridos y las acciones correctivas tomadas); ) qué cuenta y qué administrador u operador estuvo involucrado; d) qué procesos fueron involucrados. 76IRAM-ISO/IEC 27002:2008 Se recomienda que se revisen periédicamente los registros del administrador del sistema y del ope- rador de sistema. Informacién adicional Se puede utilizar un sistema de deteccién de intrusos gestionado, fuera del control de los administra- dores del sistema y de redes, para el seguimiento y control de las actividades de administracion det sistema y de la red. 10.10.5 Registro de acciones fallidas Control Se recomienda que se lleve un registro de las acciones fallidas, que las mismas se analicen y que se tomen las acciones apropiadas. Guia de implementacién Se recomienda que se lleve registro de las fallas reportadas por los usuarios 0 por los programas del sistema relacionadas a problemas con los sistemas de procesamiento 0 comunicacién de la informa- ci6n. Se recomienda que existan reglas claras para el manejo de faltas reportadas, incluyendo: a) la revisién de los registros de fallas para garantizar que las fallas han sido satisfactoriamente resueltas; b) Ia revisién de las medidas correctivas para garantizar que no han sido comprometidos los con- troles y que la accién que se ha tomado esta completamente autorizada. Se recomienda que se asegure que el registro de errores se encuentre activado, si esta funcién esta disponible. 10.10.6 Sincronizacién del reloj Control Se recomienda que los relojes de todos los sistemas de procesamiento de informacién dentro de una organizacién 0 dominio de seguridad se encuentren sincronizados de acuerdo con una fuente de tiempo precisa previamente convenida. Guia de implementacién Cuando un dispositivo informético 0 de comunicaciones tiene la capacidad de operar un reloj de tiempo real, se recomienda que se establezca este reloj segiin una norma acordada, por ejemplo: Tiempo Universal Coordinado (UTC) 0 normas de horario local. Como algunos relojes son conocidos por fiuctuar con el tiempo, se recomienda que exista un procedimiento que verifique y corrija cual- Quier variacién significante. La interpretacién correcta del formato de fecha/hora es importante para garantizar que la visualiza- cién de la fecha y hora refieja la fecha y hora actuales. Es conveniente que las especificaciones locales (por ejemplo, el horario de verano) se tengan en cuenta. Informacién adicional La correcta configuracién de los relojes de las computadoras es importante para garantizar la preci- sin de los registros de auditoria, las cuales pueden ser requeridos como evidencia en investigaciones de casos legales o disciplinarios. Registros de auditoria imprecisos pueden dificultar tales investigaciones y dafar la credibilidad de tales evidencias. Se puede usar como reloj principal para los sistemas de registro un reloj vinculado a una transmisién radial en tiempo real de un relojIRAM-ISO/IEC 27002:2008 ‘atémico nacional, Se puede utilizar un protocolo de tiempo de red para mantener todos los servidores en sincronizacién con el reloj principal. 11 CONTROL DE ACCESOS 14.1 Requerimientos para el control de accesos ‘Objetivo: Controlar el acceso a la informacion. Se recomienda que se controle el acceso a la informacién, a las instalaciones de procesamiento de la informacién y a los procesos de negocios, sobre la base de los requerimientos de seguridad y de los negocios. Se recomienda que las regias de control de acceso tengan en cuenta las politicas de autorizacion y de difusién de la informacion. 14.1.1 Pol a de control de accesos Control Se recomienda que se establezca, documente y revise una politica de control de accesos basada en los requerimientos de acceso de seguridad y del negocio. Guia de implementacién Se recomienda que se determinen claramente, en la politica de control de accesos, las reglas y dere- cchos del control de accesos para cada usuario 0 grupo de usuarios. Los controles de acceso son légicos y fisicos (ver también el capitulo 9) y se recomienda que se consideren en forma conjunta. Se recomienda que se entregue a los usuarios y a los proveedores de servicio una definicion clara de los requerimientos del negocio que deben cumplir los controles de acceso. Se recomienda que la politica tenga en cuenta lo siguiente: a) requerimientos de seguridad de las aplicaciones comerciales individuales; b)__identificacién de toda la informacién relacionada con las aplicaciones comerciales y de los ries- gos a los cuales se enfrenta la informacion; ©) _politicas de divulgacion y autorizaci6n de informacién, por ejemplo, la necesidad de conocer los principios y niveles de seguridad y la clasificacién de la informacion (ver 7.2); 4) consistencia entre las politicas de control de acceso y de clasificacin de Ia informacién de los diferentes sistemas y redes; ) legislacién aplicable y cualquier obligacién contractual con respecto a la proteccién del acceso a datos 0 servicios (ver 15.1); f) _perfiles de acceso de usuarios normales para puestos de trabajo comunes dentro de la organi- zacion; 9) gestion de los derechos de acceso en un ambiente distribuido y de red que reconoce todos los tipos de conexiones disponibles; 78IRAM-ISO/IEC 27002:2008 h) _separacién de los roles de control de acceso, por ejemplo, pedidos de acceso, autorizacién de acceso, administracién del acceso; i) requerimientos de autorizaci6n formal de los pedidos de acceso (ver 11.2.1); j) _ tequerimientos para las revision periédica de los controles de acceso (ver 11.2.4); k)_remoci6n de los derechos de acceso (ver 8.3.3). Informacién adicional Se recomienda que al especificar las reglas de control de acceso se tenga cuidado al considerar: a) la diferenciacién entre las regias que siempre deben imponerse y las directrices que son optati- vas 0 condicionales; b)_establecer reglas basadas en la premisa Todo esta prohibido a menos que esté expresamente permitido, antes que en la regla mas débil Todo esté permitido a menos que esté expresamen- te prohibido; c) cambios en los rétulos de informacion (ver 7.2) que son iniciados autométicamente por las ins- talaciones de procesamiento de informacion y aquellos iniciados segin la discrecién de un usuario; d) cambios en los permisos de usuario que son iniciados automaticamente por el sistema de in- formacién y aquellos iniciados por el administrador, e) reglas que requieren aprobacién especifica antes de entrar en vigencia y aquellas reglas que no. ‘Se recomienda que las reglas de control de acceso tengan el soporte de procedimientos formales y las responsabilidades claramente definidas (ver, por ejemplo, 6.1.3, 11.3, 10.4.1, 11.6). 11.2 Gestién de accesos de usuarios ‘Objetivo: Asegurar el acceso a los usuarios autorizados y prevenir el acceso no autorizado a los sis- temas de informacion. Se recomienda que se encuentren establecidos procedimientos formales para controlar la asignacion de los derechos de acceso a los sistemas y servicios de informacion, Se recomienda que los procedimientos cubran todas las etapas del ciclo de vida del acceso de usua- fio, desde el registro inicial de nuevos usuarios hasta la eliminacién final de los registros de los usuarios quienes ya no requieren acceso a los sistemas y servicios. Se recomienda especial aten- cién, cuando corresponda, a la necesidad de controlar la asignacién de derechos de acceso privilegiados, que permiten a los usuarios sustituir los controles del sistema. 11.2.1 Registro de usuarios Control! Se recomienda que exista un procedimiento formal de registro de alta y baja de usuarios para otorgar y revocar el acceso a todos los sistemas y servicios de informacion. Guia de implementacién Se recomienda que los procedimientos de control de acceso, para el alta y baja de registros, incluya 79IRAM-ISO/IEC 27002:2008 a) la utilizacion de identificaciones Unicas de usuario para permitir que los usuarios estén vincula- dos a sus acciones y asuman responsabilidad por las mismas; se recomienda que el uso de identificaciones grupales solo se permita cuando sean necesarias por razones de negocio u operacionales, y se recomienda que estén aprobadas y documentadas; b) la verificacién de que el usuario tiene autorizacién del duefio de! sistema para el uso del siste- ma 0 servicio de informacién; también puede resultar apropiada una aprobacién particular de derechos de acceso por parte de la gerencia; ©) a verificacién de que el nivel de acceso otorgado es adecuado al propésito de! negocio (ver 11.1) y es consistente con la politica de seguridad de la organizacién, por ejemplo, que no compromete la separacién de las tareas (ver 10.1.3); 4) entregar a los usuarios una declaracién escrita de sus derechos de acceso; ) requerir que los usuarios firmen tas declaraciones indicando que comprenden las condiciones de acceso; f) garantizar de que los proveedores de servicio no otorguen acceso hasta que se hayan comple- tado los procedimientos de autorizacion; 9) el mantenimiento de un registro formal de todas las personas registradas para utilizar el servicio; h) el retiro 0 bloqueo inmediato de los derechos de acceso de los usuarios que cambiaron sus ro- les 0 tareas o se hayan desvinculado de la organizacién; i) la verificacién periédica por eliminacién o bloqueo de identificaciones de usuarios 0 cuentas re- dundantes (ver 11.2.4); j) garantizar que las identificaciones de usuarios redundantes no se asignen a otros usuarios. Informacién adicional Se recomienda que se preste consideracién para establecer los roles de acceso de usuarios basados en los requerimientos de la actividad que resuman un niimero de derechos de acceso en los perfiles tipicos de acceso de usuario. Los pedidos de acceso y las revisiones (ver 11.2.4) son mas sencillos de administrar a nivel de tales roles que a nivel de derechos particulares. Se recomienda que se preste consideracién a la inclusion de cléusulas en los contratos del personal y en contratos de servicio que especifiquen sanciones si el personal o agentes de servicio intentan acceder sin autorizacion (ver también 6.1.5, 8.1.3 y 8.2.3) 11.2.2 Gestion de privil legios Control Se recomienda que la asignacion y uso de los privilegios esté restringido y controlado. Guia de implementacién Se recomienda que los sistemas multiusuario que requieren de proteccién contra accesos no autori- zados, controlen la asignacién de privilegios mediante un proceso formal de autorizacién. Se recomienda que se tengan en cuenta los pasos siguientes: a) que se identifiquen los privilegios de acceso asociados a cada producto del sistema, por ejem- Plo, sistema operativo, sistema de administracién de bases de datos y de cada aplicacion, y los Usuarios que necesiten estar asignados a ellos;IRAM-ISO/IEC 27002:2008 b) que se asignen los privilegios a los individuos sobre las bases de necesidad de uso y de evento por evento, en linea con la politica de control de accesos (11.1.1), por ejemplo, el requerimiento minimo para su rol funcional s6lo cuando sea necesario; c) que se mantenga un proceso de autorizacién y un registro de todos los privilegios asignados. Se recomienda que los privilegios no se otorguen hasta que se haya completado el proceso de autorizacion; d) que se promueva el desarrollo y uso de rutinas del sistema para evitar la necesidad de otorgar Privilegios a los usuarios; €) que se promueva el desarrollo y el uso de programas, que eviten la necesidad de ser ejecuta- dos con privilegios; f) que los privilegios se asignen con una identificacién de usuario diferente de aquella utiizada en las actividades normales. Informacién adicional El uso inadecuado de los privilegios de administracion del sistema (cualquier caracteristica o instala- cién de un sistema de informacion que permita al usuario sobrescribir controles del sistema o de la aplicacién) puede ser el factor mas importante que contribuya a fallas o brechas de los sistemas. 11.2.3 Gestion de las contrasefias de usuario Control Se recomienda que la asignacién de contrasefias se controle mediante un proceso formal de gestién Guia de implementacién Se recomienda que el proceso incluya los requerimientos siguientes: a) que se requiera a los usuarios que firmen una deciaracién por la cual se comprometen a man- tener sus contrasefias personales en secreto y las contrasefias de los grupos de trabajo exclusivamente entre los miembros del grupo; ésta declaracién firmada podria incluirse en los términos y condiciones de empleo (ver 8.1.3); b) que cuando se requiera a los usuarios que mantengan sus propias contrasefias, se les provea inicialmente de una contrasefia temporal (ver 11.3.1), la cual se obligue a cambiar inmediata- mente; )_establecer procedimientos para verificar la identidad de un usuario antes de proveerle de una contrasefia nueva, reemplazo o contrasefia temporaria; d) que las contrasefias temporales se entreguen a los usuarios de una manera segura; se reco- mienda que se evite el uso de terceras partes 0 mensajes de correo electrénico no protegides (texto plano); e) que las contrasefias temporales sean Unicas para una persona, y que no sean adivinables; f) que los usuarios tengan recibo de recepcién de contrasefias; 9g) que las contrasefias nunca se almacenen en sistemas informaticos de forma no protegida; h) que las contrasefias por defecto que otorga el vendedor se cambien luego de la instalacién de los sistemas 0 del software. aIRAM-ISO/IEC 27002:2008 Informacién adicional Las contrasefias son medios comunes para la verificacién de la identidad de un usuario antes de que se le oforgue acceso al sistema o servicio de informacién de acuerdo con la autorizacién del usuario, Se recomienda que se consideren otras tecnologias para la identificacion y autenticacion de usua- rios, como las biométricas, por ejemplo, verificacién de huellas digitales, verificacién de firma, y el uso de dispositivos fisicos, por ejemplo, tarjetas inteligentes. 11.2.4. Revision de los derechos de acceso Contro! Se recomienda que la alta direccién revise los derechos de acceso de los usuarios a intervalos regu- lares utiizando un proceso formal. Guia de implementacién Se recomienda que las revisiones de los derechos de acceso consideren las directrices siguientes: a) que los derechos de acceso de los usuarios se revisen a intervalos regulares, por ejemplo, con periodos de 6 meses, y después de cualquier cambio, tales como un ascenso, descenso o fina- lizacién de un empleo (ver 11.2.1); b) que se revisen y reasignen los derechos de acceso de los usuarios cuando se realice el trasla~ do de un puesto a otro, dentro de la misma organizacion; c) que se revisen, a intervalos mas frecuentes, las autorizaciones para los privilegios de derecho de acceso especiales (ver 11.2.2), por ejemplo, con periodos de 3 meses; d) que se verifiquen las asignaciones de privilegios a intervalos regulares para asegurar que no se han obtenido privilegios no autorizados; @) que se lleve registro de los cambios a cuentas privilegiadas, a través de revisiones periddicas. Es necesario revisar periédicamente los derechos de acceso de usuarios para mantener un control efectivo sobre el acceso a los datos y a los servicios de informacion. 11.3 Responsabilidades del usuario Objetivo: Prevenir el acceso de usuarios no autorizados, de modo que se comprometa o sustraiga la informacion o las instalaciones de procesamiento de la informacién La cooperacién de los usuarios autorizados es esencial para que la seguridad sea efectiva. Se recomienda que se concientice a los usuarios de sus responsabilidades para el mantenimiento efectivo de controles de acceso, particularmente los relacionados con el uso de contrasefias y la se- guridad del equipamiento de! usuario, Se recomienda que se implemente una politica de mantener el escritorio y la pantalla limpios para educir el riesgo del acceso no autorizado o dafio a papeles, a los medios y a las instalaciones de procesamiento de informacién. 82IRAM-ISO/IEC 27002:2008 11.3.1 Uso de contrasefias Control Se recomienda que se solicite a los usuarios que sigan las buenas practicas de seguridad en la se- leccién y uso de contrasefias. Guia de implementacién Se recomienda que se de aviso a los usuarios para que: a) mantengan las contrasefias en forma confidencial; b)__eviten mantener un registro (por ejemplo papeles, archivos de software o dispositivos portatiles) de contrasefias, a menos que pueda ser almacenado de forma segura y que el método de al- macenamiento haya sido aprobado; ©) cambien de contrasefias ante la posibilidad de que un sistema o contrasefia se encuentren comprometidos; 4d) _seleccionen contrasefias de calidad con la longitud minima suficiente y que sean’ 1) faciles de recordar; 2) no basadas en algo que otra persona pueda adivinar u obtener facilmente utilizando infor- macién relacionada con la persona, por ejemplo nombres, numeros telefénicos y fechas de nacimiento, etc.; 3) no vulnerable a ataques de diccionario (por ejemplo, que no consista de palabras incluidas en los diccionarios); 4) libre de caracteres consecutivos idénticos, en caracteres todos numéricos o todos alfabéti- cos; e) cambien de contrasefias a intervalos regulares o basadas en el niimero de accesos (se reco- mienda que las contrasefias para cuentas privilegiadas se cambien con mds frecuencia que la contrasefias normales), y evitar el re uso 0 el uso ciclico de viejas contrasefias; ) _cambien las contrasefias temporarias en el primer ingreso al sistema; 9) No incluyan las contrasefias en procesos autométticos de ingreso, por ejempio almacenadas en tuna funcién macro o funciones principales; h) no compartan contrasefias de usuario individual; i) nousen la misma contrasefia para propésitos de la actividad y extra de la actividad. Si los usuarios necesitan acceder a multiples servicios, sistemas o plataformas, y se requiere que mantengan miltiples contrasefias separadas, se recomienda que se haga conocer a los usuarios que pueden usar una contrasefia Unica, de calidad (ver d) anterior) para todos los servicios donde el Usuario esté seguro de que se ha establecido un nivel razonable de proteccién para el almacena- miento de la contrasefia dentro de cada servicio, sistema o plataforma. Informacién adicional La gestiOn del sistema de mesa de ayuda que trata con la pérdida u olvido de contrasefias necesita de Un cuidado especial, ya que esto puede ser un medio de ataque a las contrasefias del sistema. 83IRAM-ISO/IEC 27002:2008 11.3.2 Equipamiento de usuario que se deja desatendido Control Se recomienda que los usuarios se aseguren que el equipamiento desatendido tenga proteccin adecuada. Guia de implementacién Se recomienda que se haga consciente a todos los usuarios, de los requerimientos y procedimientos de seguridad para la proteccién del equipamiento desatendido, asi como también de sus responsabi- lidades para la implementaci6n de tales protecciones. Se recomienda que se dé aviso a los usuarios para que: a) finalicen las sesiones activas cuando hayan terminado, a menos que se puedan asegurar con un adecuado mecanismo de cierre, por ejemplo un protector de pantalia protegido por contrasefia; b) se realice el cierre de sesién de computadoras centrales, servidores y computadoras de escri- torio cuando la sesién local esta finalizada (por ejemplo no sélo apagar la pantalla o terminal de la. computadora); ©) se aseguren las computadoras de escritorio o terminales del uso no autorizado mediante una traba que necesite de una clave o un control equivalente, por ejemplo contrasefia de acceso, cuando no estén en uso (ver también 11.3.3). Informacién adicional El equipamiento instalado en las areas de usuario, por ejemplo estaciones de trabajo, servidores de archivos, pueden requerir proteccién especifica contra el acceso no autorizado cuando se deja des- atendido por un periodo extendido. 1. .3 Politica de pantalla y escritorio limpio Control Se recomienda que se adopte una politica de escritorio limpio para los papeles y medios de almace- namiento removibles y una politica de pantalla limpia para las instalaciones de procesamiento de la informacion. Guia de implementacin Se recomienda que la politica de pantalla y escritorio limpio tenga en cuenta las clasificaciones de la informacién (ver 7.2), requerimientos legales y contractuales (ver 15.1), y los correspondientes riesgos y aspectos culturales de la organizacién. Se recomienda que se consideren las directrices siguientes: a) se recomienda que la informacién comercial sensible 0 critica, por ejemplo, en papel o en un medio de almacenamiento electrénico, se almacene bajo llave (idealmente en una caja fuerte 0 gabinete u otras formas de mobiliarios seguros) cuando no se utilice, especialmente cuando la oficina esta desocupada; b) se recomienda que se cierre la sesién de las computadoras y las terminales o que se las proteja ‘con un mecanismo de bloqueo de pantalla y teclado controlados por una contrasefa, dispositivo ‘© mecanismo de autenticacion de usuarios similar cuando se deja desatendida y se recomienda que se protejan por cerraduras, contrasefias u otros controles cuando no estén en uso; ¢) se recomienda que se protejan los puntos de correo entrantes y salientes y los equipos de fax desatendidosIRAM-ISO/IEC 27002:2008 d) se recomienda que se prevenga el uso no autorizado de fotocopiadoras y otras tecnologias de reproduccién (por ejemplo escéneres, camaras digitales); @) se recomienda que los documentos que contienen informacién sensible o clasificada se retiren de las impresoras inmediatamente. Informacién adicional Una politica de escritorio/pantalla limpia reduce el riesgo de accesos no autorizados, pérdida o dafio de la informacién durante y fuera del horario normal de trabajo. Las cajas fuertes u otras formas de instalaciones de almacenamiento seguros pueden también proteger a la informacién almacenada en contra de desastres tales como fuego, terremoto, inundacién o explosion. Considerar el uso de impresoras con cédigo numérico de identificacién personal, de modo que los usuarios que originan el pedido de impresién sean los Unicos que puedan obtener sus salidas impre- sas, y solamente cuando se encuentren cerca de la impresora. 11.4 Control de acceso a la red Objetivo: Prevenir el acceso no autorizado a los servicios de red. ‘Se recomienda que se controle el acceso a los servicios de red, tanto internos como externos. Se recomienda que los accesos de usuario a la red y servicios de red no comprometan la seguridad de los servicios de red, asegurando que: a) existen interfaces apropiadas entre la red de la organizacién, las redes que son propiedad de otras organizaciones, y las redes piiblicas; b)_se aplican mecanismos de autenticacién adecuados, para los usuarios y el equipamiento; c)_se cumple con los controles de acceso de los usuarios a los servicios de informacién, 11.4.1 Politica de utilizacién de los servicios de red Control Se recomienda que se provea a los usuarios sélo el acceso a los servicios para los cuales han sido ‘especificamente autorizados. Guia de implementacién Se recomienda que se formule una politica concemiente al uso de la red y los servicios de red. Se recomienda que la politica comprenda: a) las redes y servicios de red a los cuales se permite el acceso; b) procedimientos de autorizacién para deter redes y servicios de red; 1ar qué personas tienen permiso de acceso a qué ) controles y procedimientos de gestion para proteger el acceso a las conexiones y servicios de red; 4) los medios utiizados para acceder a las redes y los servicios de red (por ejemplo las condicio- nes para permitir el acceso via teléfono a un proveedor de servicios de Internet o a sistemas remotos). 85IRAM-ISO/IEC 27002:2008 Se recomienda que la politica acerca del uso de servicios de red sea coherente con la politica de control de accesos de la organizaci6n (ver 11.1) Informacién adicional Las conexiones no autorizadas 0 inseguras a los servicios de red pueden afectar a toda la organiza- cién. Este control es particularmente importante para las conexiones de red a las aplicaciones de Regocio que son sensibles o criticas, o para los usuarios en ubicaciones de alto riesgo, por ejemplo, reas externas o piblicas que se encuentran fuera del control y gestién de la seguridad de la organi- zacién. ore 2 Autenticacién de usuarios para conexiones externas Control! Se recomienda que se utilicen métodos de autenticacién apropiados para el control de acceso de usuarios remotos. Guia de implementacién La autenticacién de usuarios remotos se puede alcanzar utilizando, por ejemplo, una técnica basada en criptografia, dispositivos de hardware, un protocolo de pregunta/respuesta. Las posibles imple- mentaciones de tales técnicas se pueden encontrar en varias soluciones de redes privadas virtuales (VPN). También pueden utlizarse lineas privadas dedicadas para proveer seguridad sobre el origen de la conexién. Los procedimientos y controles de llamada revertida (“dial back”), por ejemplo, que utiizan “modems” de llamada revertida, pueden brindar proteccién contra conexiones no autorizadas y no deseadas a las instalaciones de procesamiento de la informacion de la organizacién. Este tipo de control autentica a los usuarios que intentan establecer una conexién con una red de una organizacién desde locaciones remotas. Al aplicar este control, se recomienda que la organizacién no utilice servicios de red que in- cluyan desvio de llamadas 0, si lo hacen, que inhabiliten el uso de dichas herramientas para evitar las debilidades asociadas. Asimismo, es importante que el proceso de devolucién de llamada ("call-back") garantice que se produzca la desconexién real del lado de la organizacién. De otro modo, el usuario remoto podria mantener la linea abierta fingiendo que se ha llevado a cabo la verificacién de devolu- cién de llamada. Se recomienda que los procedimientos y los controles de devolucién de llamada estén probados exhaustivamente contra esta posibilidad. La autenticacién de nodos puede servir como un medio alternativo de autenticacién de grupos de usuarios remotos, cuando éstos estan conectados a una instalacion informatica segura y compartida Las técnicas criptogréficas, por ejemplo aquellas basadas en certificados de las maquinas, pueden utiizarse para la autenticacién de los nodos. Esto es parte de muchas soluciones basadas en redes virtuales privadas (VPN). Se recomienda que se implementen controles de autenticacién adicionales para controlar el acceso a las redes inalémbricas. En particular, se necesita cuidado especial en la seleccién de los controles, para las redes inalambricas debido a que existen mayores oportunidades para la intercepcién y la in- sercién no detectadas del tréfico de red. Informacién adicional Las conexiones externas brindan posibilidades para los potenciales accesos no autorizados a la in- formacién de la empresa, por ejemplo, accesos mediante discado telefénico. Existen diferentes métodos de autenticacién, algunos de los ouales brindan un mayor nivel de proteccién que otros, por ejemplo los métodos basados en el uso de técnicas criptograficas proporcionan una autenticacion 86IRAM-ISO/IEC 27002:2008 mas estricta. Es importante determinar mediante una evaluacién de riesgos el nivel de proteccién re- querido. Esto es necesario para la seleccién adecuada del método de autenticacién, Un recurso para la conexién automatica a una computadora remota puede proveer un modo de ob- tencién de acceso no autorizado a una aplicacién comercial. Esto es especialmente importante si la conexién utiliza una red que esta fuera del control de la gestién de seguridad de la organizacion. 11.4.3 Identificacién de! equipamiento en la red Control Se recomienda que se considere la identificacion automética de equipamiento como un medio para autenticar conexiones de ubicaciones y equipamiento especificos. Guia de implementacién Se puede utilizar la identificacién de! equipamiento si es importante que la comunicacion pueda ser solamente iniciada desde una locacién o equipamiento especificos. Se puede utilizar un identificador dentro 0 adjunto al equipamiento para indicar si el equipamiento esta autorizado a conectarse a la red. Se recomienda que estos identificadores muestren claramente a qué red el equipamiento tiene permitido conectarse, si existe mas de una red y particularmente si estas redes difieren en su sensibi- lidad. Puede ser necesario considerar la proteccién fisica del equipamiento para mantener la seguridad de! equipamiento identificador. Informacién adicional Estos controles pueden ser complementados con otras técnicas para autenticar @ los usuarios del equipamiento (ver 11.4.2). La identificacién del equipamiento puede ser aplicada adicionalmente a la autenticacién de usuario 11.4.4 Proteccién de los puertos de diagnéstico y configuracién remotos Control Se recomienda que se controle el acceso fisico y l6gico a los puertos de diagnéstico y de configuracién. Guia de implementacién Los controles potenciales para el acceso a los puertos de diagnéstico y de configuracién incluyen el uso de un bloqueo de clave y procedimientos de soporte para controlar el acceso fisico al puerto. Un ejemplo para tal procedimiento de soporte es garantizar que los puertos de diagnéstico y de configu- racién son solamente accesibles en base a acuerdos entre el gerente del servicio informatico y el personal de soporte de hardware/software que requieran el acceso. ‘Se recomienda que los puertos, servicios, y recursos similares instalados en una computadora 0 en un recurso de red que no estén especificamente requeridos para la funcionalidad de la actividad, se deshabiliten o retiren Informacién adicional Muchos sistemas informaticos, sistemas de redes, y sistemas de comunicaciones estan instalados con un recurso de diagnéstico 0 configuracién remotos para que los utilicen ingenieros de manteni- miento. Si se dejan desprotegidos, estos puertos de diagnéstico proveen un medio de acceso no autorizado, 87IRAM-ISO/IEC 27002:2008 14.4.5 Separacién en redes Control Se recomienda que los grupos de servicios de la informacién, usuarios y sistemas de informacion se subdividan en redes. Guia de implementacién Un método para controlar la seguridad de redes amplias es dividirlas en dominios légicos de red se- parados, por ejemplo, dominios de red internos y dominios de red externos a una organizacién, cada Uno protegido por un perimetro de seguridad definido. Se puede aplicar un conjunto graduado de controles en diferentes dominios de redes légicas para separar ain mas los ambientes de seguridad de la red, por ejemplo sistemas piblicamente accesibles, redes intermas y activos criticos. Se reco- mienda que los dominios se encuentren definidos en base a una evaluacién de riesgos y a diferentes requerimientos de seguridad dentro de cada dominio. Tal perimetro de red puede ser implementado mediante Ia instalacién de una puerta de enlace ("gateway") segura entre dos redes que serdn interconectadas para controlar el acceso y el flujo de la informacién entre los dos dominios. Se recomienda que este pasaje se configure para filtrar el trafico entre estos dominios (ver 11.4.6 y 11.4.7) y para bloquear el acceso no autorizado en concordancia con la politica de control de acceso de la organizacién (ver 11.1). Un ejemplo de este tipo de puerta de enlace es el que comunmente se conoce como “firewall”. Otro método de dividir los dominios légi- cos separados es la restriccion al acceso de redes utlizando redes privadas virtuales para grupos de usuarios dentro de la organizacién. Las redes también pueden ser divididas usando funcionalidades de los dispositivs de red, por ejem- plo conmutacién de IP (IP Switching). Los dominios separados pueden implementarse por el control del flujo de datos de red usando capacidades de conmutacién (‘switching’) y enrutamiento (“routing”), tales como listas de control de accesos. Se recomienda que el criterio para la subdivisi6n de redes en dominios se base en la politica de con- trol de acceso y los requerimientos de acceso (ver 10.1), y también se tenga en cuenta el costo relativo y el impacto de desemperio de la incorporacién de un adecuado enrutamiento o tecnologia de puerta de enlace (‘gateway’) de red (ver 11.4.6 y 11.4.7) Se recomienda ademas que la subdivision de redes se base en el valor y la clasificacion de la infor- macién almacenada o procesada en la red, niveles de confiabilidad, o lineas de negocio, para reducir el impacto total de la interrupcién de servicio. Se recomienda que se considere la separacién de redes inalambricas de las redes internas y priva- das. Como los perimetros de redes inalémbricas no estan bien definidos, se recomienda que se lleve ‘a cabo una evaluacién de riesgos en tales casos para identificar controles (por ejemplo autenticacion estricta, métodos criptograficos, y seleccién de la frecuencia) para mantener la subdivision de redes. Informacién adicional Las redes estan extendiéndose cada vez mas, mas alld de los limites organizacionales tradicionales, como resultado de la formacién de sociedades comerciales que pueden requerir de interconexién o de compartir las instalaciones de redes y de procesamiento de la informacién. Tales extensiones pueden incrementar el riesgo de acceso no autorizado a sistemas de informacion existentes que uusen las redes, algunos de los cuales pueden requerir de proteccién de otros usuarios de red por causa de su sensibilidad o gravedad.IRAM-ISO/IEC 27002:2008 11.4.6 Control de conexién ala red Control Para redes compartidas, especialmente aquellas que se extienden a través de los limites de la orga- nizacién, se recomienda que se restrinja la capacidad de los usuarios para conectarse a la red, en 1ea con la politica de control de acceso y con los requerimientos de las aplicaciones de la actividad (ver 11.1). Guia de implementacin Se recomienda que los derechos de acceso de red de los usuarios se mantengan y actualicen segin lo requiera la politica de control de acceso (ver 11.1.1), La capacidad de conexién de los usuarios puede ser restringida mediante pasajes de red que filtren el trafico por medio de tablas o regias predefinidas. A continuacién se enumeran ejemplos de las aplicaciones a las cuales se recomienda que se apliquen restricciones: a) _mensajeria, por ejemplo correo electrénico; b) transferencia de archivos; ©) acceso interactivo; d) acceso a aplicaciones. Se recomienda que se considere vincular los derechos de acceso de red a momentos definidos de dias o fechas. Informacién adicional La politica de control de acceso para redes compartidas, especialmente para aquellas que se extien- den a través de los limites de la organizacién, puede requerir la incorporacién de controles para restringir la capacidad de conexién de los usuarios 11.4.7 Control de enrutamiento de red Control Se recomienda que se implementen en las redes controles de enrutamiento para garantizar que las conexiones informaticas y los flujos de informacién no violen la politica de control de acceso de las aplicaciones del negocio. Guia de implementacién Se recomienda que los controles de enrutamiento se basen en mecanismos de verificacién de direc- cién de origen y destino. ‘Se pueden usar puertas de enlace ("gateways") seguras para validar las direcciones de origen y destino en puntos de control de la red internos y externos si se emplean tecnologias de traduccién de direcciones de red y/o tecnologias “proxy”. Se recomienda que los encargados de la implementacion estén advertidos de las fortalezas y debilidades de los mecanismos desplegados. Se recomienda que los requerimientos para el control de enrutamiento de redes se basen en la politica de control de acceso (ver 11.1). Informacién adicional Las redes compartidas, especialmente aquellas que se extienden a través de los limites organizaciona- les, pueden requerir controles de enrutamiento adicionales. Esto es particularmente aplicable cuando las redes son compartidas con usuarios de terceras partes (no pertenecientes a la organizacion).IRAM-ISO/IEC 27002:2008 11.5 Control de acceso al sistema operative Objetivo: Prevenir el acceso no autorizado a los sistemas operativos. Se recomienda que se utilicen las instalaciones de seguridad para restringir el acceso a los sistemas operativos sélo a los usuarios autorizados. Se recomienda que los recursos sean capaces de lo si- guiente: a) autenticar a los usuarios autorizados, en relacién con la politica de control de acceso definida; b) registrar los intentos de autenticacién del sistema, exitosos y fallidos ©) registrar el uso de privilegios especiales de sistema; 4) emitir alarmas cuando se violen las politicas de seguridad del sistema; e) prever medios apropiados para la autenticaci6n; f) cuando sea apropiado, restringir el tiempo de conexién de los usuarios. .5.1 Procedimientos seguros de inicio de sesién (“log-on’ Control Se recomienda que el acceso a los sistemas operativos se controle por un procedimiento seguro de inicio de sesién. Guia de implementacion Se recomienda que el procedimiento para el inicio de sesién en el sistema operativo se disefie para minimizar la oportunidad de acceso no autorizado. Se recomienda que el procedimiento de inicio de sesién muestre el minimo de informacion acerca del sistema, para evitar proveer a un usuario no au- torizado de cualquier asistencia innecesaria. Para contar con un buen procedimiento de ingreso, se a) no muestre en pantalla identificadores de sistema o de aplicacién hasta que el proceso de inicio de sesién haya sido exitosamente completado; b) muestre una nota general advirtiendo que se recomienda que la computadora s6lo sea accedi- da por usuarios autorizados; ©) no provea mensajes de ayuda durante el ingreso al sistema que puedan ayudar a un usuario no autorizado; 4) _valide la informacién de inicio solamente cuando se haya completado el ingreso de todos los datos de entrada. Si aparece una condicién de error, se recomienda que el sistema no indique qué parte de los datos de ingreso es correcta 0 incorrecta; €) limite el nimero permitido de intentos fracasados permitidas, por ejemplo a tres intentos, y 1) _registre los intentos exitosos y fallidos; 2) fuerce un tiempo de retraso antes de que se permitan nuevos intentos de inicio de sesién 0 rechace cualquier futuro intento sin autorizacion especifica; 3) se desconecte de las conexiones de vinculos de datos 4) envie un mensaje de alarma a la consola del sistema si se alcanza el maximo numero de intentos de ingreso;IRAM-ISO/IEC 27002:2008 5) configure el nimero de reintentos de ingreso de contrasefias en conjuncién con el largo minimo de la contrasefia y el valor del sistema que esté siendo protegido; 4) limite el tiempo maximo y minimo permitido para el procedimiento de ingreso al sistema. Si este tiempo es excedido, se recomienda que el sistema termine el ingreso al sistema; 9) al completarse un ingreso exitoso, muestre la siguiente informacion: 1) fecha y horario del ingreso anterior exitoso; 2) detalles de cualquier intento de ingreso fallido desde el ultimo ingreso; h) no muestre la contrasefia que ha sido ingresada u oculte la contrasefia de caracteres por sim- bolos; i) no transmita contrasefias en formato de texto limpio sobre la red. Informacién adicional Si las contrasefias son transmitidas en texto plano durante el inicio de sesién sobre una red, ésta po- dria ser capturada por un programa que husmee continuamente la red. 11.5.2 Identificacién y autenticacién de usuarios Control Se recomienda que todos los usuarios tengan un tnico identificador (identificador de usuario) para su uso personal, y que se elija una técnica adecuada de autenticacién para sustentar la identidad segu- ra del usuario. Guia de implementacién Se recomienda que este control se aplique para todos los tipos de usuarios (incluyendo personal de soporte técnico, operadores, administradores de red, programadores de sistema, y administradores de bases de datos). Se recomienda que se utilicen los identificadores de usuario para trazar las actividades del individuo responsable. Se recomienda que las actividades de usuarios regulares no se desempefien desde cuentas privilegiadas. En circunstancias excepcionales, donde hay un claro beneficio comercial, pueden utilizarse identifica- dores compartidos de usuarios para grupos de usuarios 0 para un trabajo especifico. Se recomienda que se documente la aprobacién de la gerencia para tales casos, Se pueden requerir controles adicio- rales para mantener la asignacién de responsebilidades. Se recomienda que los identificadores genéricos que van a ser usados por un Unico individuo solo se permitan cuando las funciones accesibles 0 las acciones llevadas a cabo por el identificador no ne- cesiten ser rastreadas (por ejemplo acceso de sélo lectura), 0 cuando se encuentren establecidos otros controles (por ejemplo contrasefias para un identificador genérico que solamente se emita a un Cuando se requiera una autenticacién estricta y la verificacién de identidad, se recomienda que se utilicen métodos alternativos a las contrasefias, tales como los medics criptograticos, tarjetas inteli- gentes, fichas de memoria ("tokens") 0 medios biométricos. 1IRAM-ISO/IEC 27002:2008 Informacién adicional Las contrasefias (ver también 11.3.1 y 11.5.3) son una forma comin de prover identificacion y auten- ticacion basados en un secreto que sélo el usuario conoce. Lo mismo puede ser alcanzado a través de medios criptograficos y protocolos de autenticacion. Se recomienda que la fortaleza de la identificacién y autenticacion de usuario esté de acuerdo con la sensibilidad de la informacion a ser accedida, Los objetos tales como las fichas de memorias 0 las tarjetas inteligentes que los usuarios poseen pueden también usarse para la identificacién y la autenticacién. Las tecnologias de autenticacion biométricas que usan las caracteristicas o atributos Unicos de una persona pueden también usarse para autenticar la identidad de una persona. Una combinacién de tecnologias y mecanismos segu- ramente vinculados resultara en una autenticacién més estricta, 11.5.3 Sistema de administracién de contrasefias Controt Se recomienda que los sisterias que administran contrasefias sean interactivos y garanticen contra- sefias de calidad. Guia de implementacién Se recomienda que un sistema de administracion de contrasefias: a) imponga el uso de identificadores de usuarios y contrasefias individuales para mantener la asignacién de responsabilidades; b) permita que los usuarios seleccionen y cambien sus propias contrasefias e incluya un procedi- miento de confirmacién para contemplar errores mientras se las escriben; ©) imponga la eleccién de contrasefias de calidad (ver 11.3.1); 4d) imponga cambios de contrasefias (ver 11.3.1); €) obligue a los usuarios a cambiar las contrasefias temporarias en su primer ingreso al sistema (ver 11.2.3); f)_ mantenga un registro de las contrasefias previas del usuario y evite la reutilizacién de las mis- mas; 9) no muestre las contrasefias en pantalla cuando se las ingresa; h) almacene en forma separada los archivos de contrasefias y los datos del sistema de aplicacién; i) almacene y transmita las contrasefias en forma protegida (por ejemplo, cifradas 0 *hashed’). Informacién adicional Las contrasefias constituyen uno de los principales medios de validacién de la autoridad de un usua- rio para acceder a un servicio informatico. Algunas aplicaciones requieren que las contrasefias de usuario sean asignadas por una autoridad in- dependiente; en tales casos, los puntos b), d) ye) de la guia anterior no se aplican. En la mayoria de los casos las contrasefias son seleccionadas y mantenidas por los usuarios. Para mayores linea- mientos en el uso de contrasefias, ver 11.3.1 92IRAM-ISO/IEC 27002:2008 11.5.4 Uso de utilitarios de sistema Controt Se recomienda que el uso de programas utilitarios que pudiesen ser capaces de pasar por alto los controles de las aplicaciones o del sistema esté restringido y controlado de cerca. Guia de implementacién Se recomienda que para el uso de utiltarios de sistema se consideren las directrices siguientes: a) uso de procedimientos de identificacién, autenticacién y autorizacién para los utiltarios del sis- tema; b) segregacion de las utilidades de! sistema de las aplicaciones del software; )__limitacién del uso de utiitarios de sistema al minimo numero practico de usuarios de confianza, autorizados (ver también 11.2.2); 4) autorizacién para el uso “ad-hoc” de los utilitarios de sistema; ©) limitacién de la disponibilidad de los utilitarios de sistema, por ejemplo, para la duracién de un cambio autorizado; f) registro de todo uso de los utiltarios de sistema; 9) definicién y documentacién de los niveles de seguridad de los utiitarios de sistema; h) _remocién o desactivacién de todo software innecesario basado en software utiitario y de sistema; i) no haciendo disponibles tos utilitarios de sistema a usuarios que tienen acceso a aplicaciones en sistemas donde se requiera la segregacién de tareas. Informacién adicional La mayoria de las instalaciones de computadoras tienen uno 0 mas programas de sistemas utiitarios que podrian ser capaces de pasar por alto los controles de sistema y aplicaciones 11.5.5 Expiracion de la sesién Controt Se recomienda que las sesiones inactivas se clerren luego de un periodo definido de inactividad. Guia de implementacién Se recomienda que un recurso de expiracién limpie la pantalla de sesion y también, més tarde, cierre tanto las sesiones de aplicaciones como las sesiones de red después de un periodo definido de inac- tividad. Se recomienda que el lapso antes de la expiracién refieje los riesgos de seguridad del area, la clasificacién de la informacion que se maneja y las aplicaciones que se usan, y los riesgos relacio- nados con los usuarios del equipamiento. Una forma limitada de! recurso de expiracién puede ser provista por algunos sistemas, que limpian la pantalla y previenen accesos no autorizados pero no cierran las sesiones de aplicaciones 0 las se- siones de red. 93,IRAM-ISO/IEC 27002:2008 Este control es particularmente importante en locaciones de alto riesgo, las cuales incluyen areas piblicas o externas por afuera de la gestion de seguridad de la organizacién. Se recomienda que se cierren las sesiones para prevenir el acceso a personas no autorizadas y ataques de negacion de servicio, 11.5.6 Limitaciones del tiempo de conexién Control Se recomienda que se utilicen restricciones acerca del tiempo de conexién para brindar seguridad adicional a las aplicaciones de alto riesgo. Guia de implementacin Se recomienda que se consideren controles de tiempo de conexién para las aplicaciones informati- cas sensibles, especialmente de locaciones de alto riesgo, por ejemplo areas publicas o externas que estan afuera de la gestién de seguridad de la organizacion. Entre los ejemplos de tales restricciones encontramos: a) el uso de intervalos de tiempo predeterminado, por ejemplo, para la transmisién de archivos en lote, 0 sesiones regulares interactivas de corta duracion; b)__restriccién de los tiempos de conexién a los horarios normales de oficina sino hay requerimien- tos de tiempo extra 0 por operaciones de horas extendidas; ¢)_consideracién de la reautenticacién a intervalos regulares. Informacién adicional Limitando el periodo durante el cual se permiten las conexiones a los servicios informdticos, se redu- ce la ventana de oportunidad de acceso no autorizado. Limitando la duracién de las sesiones activas se previene a los usuarios de mantener las sesiones abiertas para prevenir la reautenticacién. 11.6 Control de acceso a las aplicaciones y a la informacién Objetivo: Prevenir el acceso no autorizado a la informacién contenida en los sistemas de aplicacién. Se recomienda que se utilicen los recursos de seguridad para limitar tanto el acceso a los sistemas de aplicacion como a su estructura interna. Se recomienda que se limite el acceso légico al software de aplicacién y a la informacién sélo a los usuarios autorizados. Es conveniente que los sistemas de aplicacién a) controlen el acceso de usuarios a la informacion y a las funciones de los sistemas de aplica- ion, de acuerdo con la politica de control de acceso definida; b) _brinden proteccién contra el acceso no autorizado de cualquier utiitario, software del sistema operativo y software malicioso que tengan la capacidad de pasar por alto los controles de los sistemas 0 de las aplicaciones c) no comprometan otros sistemas con los que se comparten recursos de informacién; 94IRAM-ISO/IEC 27002:2008 11.6.1 Restriccién de acceso a la informacion Control Se recomienda que se restrinja el acceso a la informacién y a las funciones de los sistemas de apli- cacién a los usuarios y al personal de soporte, de acuerdo con una politica de contro! de acceso definida, Guia de implementacién Se recomienda que las restricciones de acceso se basen en los requerimientos individuales de cada aplicacién comercial. Es conveniente que la politica de control de acceso sea consistente con la poli- tica de acceso de la organizacién. Se recomienda que se considere la aplicacién de las directrices siguientes, para brindar apoyo a los requerimientos de limitacion de accesos: a) provisién de meni para controlar el acceso a las funciones de los sistemas de aplicacién; b) control de los derechos de acceso de los usuarios, por ejemplo, lectura, escritura, eliminacién y ejecucié c) control de los derechos de acceso de otras aplicaciones; d) asegurar de que las salidas de los sistemas de aplicacién que manejan informacion sensible, contengan sélo la informacién que resulte pertinente para el uso de la salida y se envie sola- mente a las terminales y ubicaciones autorizadas; se recomienda que esto incluya revisiones Periédicas de dichas salidas a fin de garantizar la remocién de la informacién redundante. 11.6.2 Aislamiento de sistemas sensible Control Se recomienda que los sistemas sensibles se encuentren en un ambiente informatico dedicado (aistado). Guia de implementacién Se recomienda que se consideren los siguientes puntos para el aislamiento de los sistemas sensibles: a) que la sensibilidad de un sistema de aplicacién esté claramente identificada y documentada por el propietario de la aplicacion (ver 7.1.2); b) que, cuando una aplicaci6n sensible ha de ejecutarse en un ambiente compartido, el propieta- ‘io de la aplicacién sensible identifique y acepte los sistemas de aplicacién con los cuales ésta compartira recursos, y el riesgo correspondiente. Informacién adicional Algunos sistemas de aplicacion son suficientemente sensibles a pérdidas potenciales que requieren un tratamiento especial. Se recomienda que la sensibilidad pueda indicar que el sistema de aplicacion: a) se ejecute en una computadora dedicada; 0 b) _s6lo comparta recursos con fos sistemas de aplicacién confiables. El aistamiento puede lograrse utilizando métodos fisicos y légicos (también ver 11.4.5). 95IRAM-ISO/IEC 27002:2008 44.7 Computacién mévil y teletrabajo ‘Objetivo: Garantizar la seguridad de la informacion mientras se utilizan dispositivos de computacion mévil e instalaciones de teletrabajo. Se recomienda que la proteccién requerida sea proporcional a los riesgos que originan estas formas especificas de trabajo. Es conveniente que, mientras se utiliza computacion movil en un ambiente desprotegido, se consideren los riesgos que esto implica y se impiemente la proteccién adecuada. En el caso de! teletrabajo, se recomienda que la organizacion implemente proteccién en el sitio remoto de teletrabajo y garantice que se toman las medidas adecuadas para este tipo de trabajo. 11.7.1 Computacién y comunicaciones méviles Control Se recomienda que se establezca una politica formal y que se adopten medidas de seguridad ade- cuadas para protegerse contra los riesgos del uso de dispositivos de computacién e instalaciones de comunicacion méviles, Guia de implementacién Cuando se utilizan computacién e instalaciones de comunicacién méviles, por ejemplo “notebooks”, “paimtops’, “laptops”, tarjetas inteligentes, y teléfonos méviles, se recomienda que se tenga especial cuidado en garantizar que no se comprometa la informacién de la empresa. Se recomienda que la politica de computacién mévil tome en cuenta los riesgos que implica trabajar con equipamientos in- formaticos méviles en ambientes no protegidos. Es conveniente que la politica de computacion mévil incluya los requerimientos para la proteccién fi sica, controles de acceso, técnicas criptograficas, copias de respaldo, y proteccién de virus. Se Fecomienda que la politica también incluya las reglas y avisos acerca de conectar los recursos movi les a redes y guias en lugares puiblicos. Se recomienda que se tome recaudos al utilizar dispositivos informaticos méviles en lugares publicos, salas de reuniones y otras areas no protegidas fuera de la sede de la organizaci6n. Es conveniente que se establezca proteccién para evitar el acceso no autorizado o divulgacién de la informacién almace- nada y procesada por éstos dispositivos, por ejemplo, mediante técnicas criptograficas (ver 12.3). Es conveniente que los usuarios de los recursos de computacién méviles en lugares piblicos tengan cuidado para evitar los riesgos de ser espiados por personas no autorizadas. Se recomienda que se establezcan procedimientos contra el cédigo malicioso de software y que se los mantenga actualiza- dos (ver 10.4). Se recomienda que se realicen copias de respaldo de a informacion critica en forma periddica. Es conveniente que el equipamiento esté disponible para permitir la copia de respaldo de la informacion rapida y facilmente. Se recomienda que se dé proteccién adecuada a éstas copias de seguridad contra, por ejemplo, hurto, 0 pérdida de informacion. Es conveniente que se brinde proteccién adecuada para el uso de dispositivos méviles conectados a redes. Se recomienda que el acceso remoto a la informacion de la empresa a través de redes publicas utiizando dispositivos informaticas méviles, sélo tenga lugar luego de una identificacion y autenticacion exitosas, y con los mecanismos adecuados de control de acceso implementados (ver 11.4). Es conveniente que los recursos informéticos méviles también se encuentren fisicamente protegidos en contra de hurto, especialmente cuando son dejados, por ejemplo, en automéviles u otras formas 96IRAM-ISO/IEC 27002:2008 de transporte, habitaciones de hoteles, centros de conferencia, y lugares de reunion. Se recomienda que se establezca un procedimiento especifico que tenga en cuenta los requerimientos legales, de Seguros y otros requerimientos de seguridad de la organizacién para casos de hurto 0 pérdida de los recursos informaticos méviles. Es conveniente que no se deje desatendido el equipamiento que {ransporta informacién importante de la actividad, sensible y/o critica y, cuando resulte posible, se re- comienda que esté fisicamente resguardado bajo llave, o que se utilicen cerraduras especiales para asegurar el equipamiento (ver 92.5) Es conveniente que se brinde entrenamiento al personal que utiliza computacién mévil para incre- mentar su conocimiento de los riesgos adicionales ocasionados por esta forma de trabajo y de los controles que se recomienda que implementen. Las conexiones méviles de redes inalambricas son similares a otros tipos de conexiones de red, pero tienen importantes diferencias que es conveniente que se consideren cuando se identifican los con- troles. Las diferencias tipicas son: a) algunos protocolos de seguridad inalémbricos no estén maduros y tienen debilidades conocidas: b) puede no hacerse copia de resguardo de la informacién almacenada en computadoras moviles debido a los limitados anchos de banda de red y/o debido a que el equipamiento movil puede ‘no estar conectado en el momento en que ése, encuentra programada la copia de seguridad. 11.7.2 Teletrabajo Control Se recomienda que se desarrollen e implementen una politica, planes y procedimientos operaciona- les para las actividades de teletrabajo. Guia de implementacién Es conveniente que las organizaciones sélo autoricen actividades de teletrabajo si han comprobado satisfactoriamente que se han implementado disposiciones y controles adecuados en materia de se- guridad y que estos cumplen con la politica de seguridad de la organizacién. ‘Se recomienda que el sitio de teletrabajo tenga proteccién adecuada contra de, por ejemplo, el hurto del equipamiento e informacién, la divulgacién no autorizada de la informacién, el acceso remoto no autorizado a los sistemas interios de la organizacién 0 uso indebido de las prestaciones. Es conve- niente que las actividades de teletrabajo sean autorizadas y controladas por la gerencia, y que la alta direccién se asegure que se establezcan acuerdos adecuados para esta forma de trabajo, Es conveniente que se consideren los temas siguientes: a) la seguridad fisica existente en el sitio de teletrabajo, tomando en cuenta la seguridad fisica del edificio y del ambiente local; b) el ambiente de teletrabajo propuesto; ) los requerimientos de seguridad de comunicacién, tomando en cuenta la neoesidad de acceso remoto a los sistemas intemos de la organizacién, la sensibilidad de la informacién a la que se accedera y que pasara a través del vinculo de comunicacién y la sensibilidad del sistema interno; d) la amenaza de acceso no autorizado a la informacién o los recursos por parte de otras perso- ‘nas que utilizan el lugar, por ejemplo, familiares y amigos; 97IRAM-ISO/IEC 27002:2008 e) 9) hy) i) el uso de redes hogarefias y los requerimientos 0 las restricciones de la configuracion de los servicios de red inalambricos; politicas y procedimientos para prevenir disputas concernientes a los derechos de propiedad in- telectual desarrollada en equipamiento privado; e acceso a equipamiento privado (para verificar la seguridad de la maquina o durante una in- vestigacién), lo que puede estar impedido por la legislacién; acuerdos de licencias de software que estan establecidas de tal manera que las organizaciones pueden volverse responsables de las licencias de software cliente en las estaciones de trabajo que son propiedad privada de los empleados, contratistas 0 usuarios de terceras partes; requerimientos de proteccién antivirus y de cortafuegos ("firewall") Se recomienda que las directrices y acuerdos a ser considerados incluyan: a) b) a) e) 9) ») d la provision de equipamiento adecuado y de muebles para el almacenamiento para las activi- dades de teletrabajo, donde no se permita el uso de equipamiento de propiedad privada que no se encuentre bajo el control de la organizacion; una definicién del trabajo permitido, el horario de trabajo, la clasificacion de la informacion que puede ser manejada y los sistemas y servicios intemnos a los cuales el trabajador remoto esta autorizado a acceder; la provisién de un adecuado equipamiento de comunicacién, incluidos los métodos para asegu- rar el acceso remoto; seguridad fisica; reglas y orientacién en cuanto al acceso de familiares y visitas al equipamiento e informacién; la provisién de soporte y mantenimiento de hardware y de software; la provision de seguros; los procedimientos para las copias de respaldo y para la continuidad de! negocio; auditoria y seguimiento y control de la seguridad: revocacion de la autoridad y de los derechos de acceso, y la devolucién del equipo cuando fi- nalicen las actividades remotas. Informacién adicional El trabajo remoto usa tecnologias de comunicacién para permitir al personal trabajar en forma remota desde una ubicacién fia fuera de su organizacién.IRAM-ISO/IEC 27002:2008 12_ADQUISICION, DESARROLLO Y MANTENIMIENTO DE SISTEMAS DE INFORMACION 12.4 Reque jentos de seguridad de los sistemas de informacién (Objetivo: Garantizar que la seguridad sea una parte integral de los sistemas de informacion. Los sistemas de informacién incluyen sistemas operativos, infraestructura, aplicaciones de negocio, productos enlatados (‘off-the-shelP), servicios y aplicaciones desarrolladas por el usuario. El disefio ¢ implementacién del sistema de informacion que da soporte a los procesos de negocio puede ser cru- cial para la seguridad. Se recomienda que los requerimientos de seguridad se identifiquen y acuerden antes del desarrollo e implementacién de los sistemas de informacion. Es conveniente que se identifiquen todos los requerimientos de seguridad en la fase de requerimien- tos de un proyecto y se justifiquen, acuerden y documenten como parte de la actividad del sistema de informacién. 12.1.1 Anilisis y especificaciones de los requerimientos de seguridad Control Se recomienda que las declaraciones de requerimientos de la actividad para nuevos sistemas de in- formacién, o mejoras de los sistemas de informacién existentes, especifiquen las necesidades de controles de seguridad. Guia de implementacién Se recomienda que las especificaciones para los requerimientos de control consideren los controles automaticos a incorporar al sistema de informacién asi como la necesidad de controles manuales de apoyo. Es conveniente aplicar consideraciones similares al evaluar paquetes de software, desarrolla- dos 0 comprados, para las aplicaciones de la actividad. Es conveniente que los requerimientos y controles de seguridad reflejen el valor para el negocio de los activos de informacién involucrados (ver también 7.2), y el dafio potencial al negocio que podria ser el resultado de una falla o ausencia de seguridad. Se recomienda que los requerimientos de los sistemas para la seguridad de la informacion y los pro- cesos para la implementacién de la seguridad, se integren en las etapas tempranas de los proyectos de seguridad de la informacion. Los controles introducidos en la etapa de disefio son significativa- mente mas baratos de implementar y mantener que aquellos incluidos durante o después de la implementacién. Si los productos son comprados, es conveniente que se siga un proceso formal de pruebas y de adqui- sicién, Se recomienda que los contratos con el proveedor apunten a los requerimientos de seguridad identificados. Cuando la funcionalidad de seguridad en un producto propuesto no satisfaga los reque- rimientos especificados, se recomienda que Se reconsideren el riesgo que se introduce y los controles asociados en forma previa a la compra del producto. Cuando se provea de funcionalidad adicional y cause un riesgo de seguridad, se recomienda que ésta se desactive o se revise la estructura de control propuesta para determinar si se puede tener ventajas de esa mejora de la funcionalidad.IRAM-ISO/IEC 27002:2008 Informacién adicional Si se considera apropiado, por ejemplo por razones de costo, la alta direccién puede desear hacer uso de productos certificados y evaluados independientemente, mas informacion acerca de los crite- rios de evaluacién para los productos de seguridad de tecnologias de informacion puede encontrarse en la ISO/IEC 15408 0 en otras normas de certificacion 0 evaluacién, segin corresponda. La ISO/IEC TR 13335-3 provee guias en el uso de procesos de gestion de los riesgos para identificar los requerimientos de los controles de seguridad, 12.2 Procesamiento correcto en las aplicaciones Objetivo: Prevenir errores, pérdidas, modificaciones no autorizadas 0 mal uso de la informacién en las aplicaciones. Es conveniente que se disefien los controles apropiados en las aplicaciones, incluyendo las aplicacio- nes desarrolladas por los usuarios para asegurar el procesamiento correcto. Se recomienda que estos controles incluyan la validacién de los datos de entrada, procesamiento interno, y datos de salida Se pueden requerir controles adicionales para los sistemas que procesan 0 tienen un impacto sobre la informacion sensible, valiosa o critica. Es conveniente que se determinen tales controles sobre la base de los requerimientos de seguridad y la evaluacién de los riesgos. 12: 1 Validacién de los datos de entrada Controt Se recomienda que los datos de entrada de las aplicaciones se validen para asegurar que son co- rrectos y apropiados. Guia de implementacién Es conveniente que los controles se apliquen a las entradas de las transacciones de negocio, datos permanentes (por ejemplo, nombres y direcciones, limites de crédito, nimeros de referencia del Gliente) y tablas de parametros (por ejemplo, precios de venta, tasa de impuestos, indice de conver- sion de dinero). Se recomienda que se consideren las directrices siguientes: a) controles de entrada duales u otros controles de entrada tales como verificacién de limites 0 campos limitantes para especificar los rangos de los datos de entrada, para detectar los errores siguientes: 1) valores fuera de rango; 2) caracteres invalidos en campos de datos; 3) datos faltantes o incompletos; 4) _vollimenes de datos que exceden los limites superiores e inferiores; 5) controles de datos no autorizados o inconsistentes; b)__revisién periddica del contenido de campos clave o archivos de datos para confirmar su validez e integridad; ¢)_inspeccién de los documentos de entrada para detectar cambios no autorizados (es convenien- te que se autoricen todos los cambios en los documentos de entrada); 400IRAM-ISO/IEC 27002:2008 d) _procedimientos para responder a errores de validacién; ) procedimientos para determinar la veracidad de los datos; f) definicion de las responsabilidades de todo el personal involucrado en el proceso de entrada de datos; 9) creacién de un registro de las actividades involucradas en el proceso de entrada de los datos (ver 10.10.1).. Informacién adicional ‘Se puede considerar la examinacién y la validacién automatica de los datos de entrada, segtin co- rresponda, para reducir el riesgo de errores y para prevenir ataques, incluyendo el desbordamiento del "buffer* (‘buffer overflow’) y la inserci6n de cédigo (“code injection”). 12.2.2 Controles de procesamiento interno Control Se recomienda que las verificaciones de validacién se incorporen a las aplicaciones para detectar cual- quier caso de corrupcién de la informacién, a través de errores del procesamiento 0 actos deliberados. Guia de implementacién Es conveniente que el disefio e implementacién de las aplicaciones asegure que se minimicen los riesgos y las fallas de procesamiento que conduzcan a una pérdida de la integridad. Las areas espe- cificas a considerar incluyen: a) el uso de funciones de agregado, modificacién y de borrado para implementar cambios en los datos; b) los procedimientos para prevenir la ejecucién de programas en un orden equivocado 0 que co- rran luego de una falla de un procesamiento previo (ver también 10.1.1); ©) el uso de programas apropiados para recuperarse de fallas que asegure el correcto procesa- miento de los datos; 4d) proteccién contra ataques que usen desbordamiento del "butter". Se recomienda que se prepare una lista de verificacién apropiada. Se recomienda que las activida- des documentadas y los resultados se guarden de forma segura. Los ejemplos de verificaciones que se pueden incorporar incluyen lo siguiente: 1a) sesiones o controles por lotes, para reconoiliar los balances de los archivos de datos después de las actualizaciones de transaccién; b) _controles de balance, para verificar balances abiertos contra balances previos cerrados, es decir: 1) controles corrida a corrida, 2) totalizaciones de las actualizaciones de los archivos, 3) controles programa a programa; c) _validacién de los datos de entrada generados por el sistemas (ver 12.2.1); d)_verificaciones de la integridad, autenticidad 0 cualquier otra caracteristica de seguridad de los datos 0 software descargados 0 cargados entre computadores centrales y remotas; 101IRAM-ISO/IEC 270022008 e) totales de verificacién mediante la funcién “hash’ de los registros y archivos; f) _verificaciones para asegurar que los programa de aplicacién se ejecutan en el tiempo correcto; 9) verificaciones para asegurar que los programas se estén ejecutando en el orden correcto y terminan en caso de falla, y que el procesamiento posterior se detiene hasta que el problema se resuelva; h) _creacién de un registro de las actividades involucradas en el procesamiento (ver 10.10.1). Informacién adicional Los datos que han sido correctamente ingresados pueden ser corrompidos por errores de hardware, errores de procesamiento 0 a través de actos deliberados. Las verificaciones de validacion que se requieran dependeran de la naturaleza de la aplicacién y el impacto que ocasiona en el negocio de fa corrupcién de los datos. 12.2.3 Integridad del mensaje Controt Se recomienda que se identifiquen os requerimientos para asegurar la autenticidad y para proteger la integridad del mensaje de las aplicaciones, asi como que se identifiquen e implementen controles apropiados. Guia de implementacién Se recomienda que se lleve a cabo una evaluacién de los riesgos de seguridad para determinar si se requiere la integridad de! mensaje y para identificar el método mas apropiado de implementacién Informacién adicional Las técnicas criptogréficas (ver 12.3) pueden usarse como un medio apropiado de implementacion de la autenticacién de mensajes. 12.2.4 Validacién de los datos de salida Controt Es conveniente que se valide la salida de datos de una aplicacién para garantizar que el procesa- miento de la informacién almacenada sea correcto y adecuado a las circunstancias. Guia de implementacién La validacién de los datos de salida puede incluir a) comprobaciones de la plausibilidad para probar si los datos de salida son razonables; b) conciliacién de cuentas de control para asegurar el procesamiento de todos los datos; ©) provision de informacién suficiente, para que un lector o sistema subsiguiente de procesamien- to, determine la exactitud, completitud, precisién y clasificacion de la informacién; 4) procedimientos para dar respuesta a las pruebas de validacién de salidas; ) definicién de las responsabilidades de todo el personal involucrado en el proceso de salida de datos; f) _creacién de un registro de actividades en el proceso de validacién de los datos de salida. 102IRAM-ISO/IEC 27002:2008 Normalmente, los sistemas y las aplicaciones se construyen sobre la presuncién de que habiendo emprendido Ia validacién, verificacion, y pruebas adecuadas, las salidas siempre resultaran correc- tas. De todos modos, esta presuncién no siempre es valida, por ejemplo, atin los sistemas que han sido probados pueden producir salidas incorrectas bajo algunas circunstancias. 12.3 Controles criptograficos Objetivo: Proteger la confidencialidad, autenticidad, y la integridad de la informacion por medios crip- tograficos. Es conveniente desarrollar una politica en el uso de controles criptograficos. Se recomienda que se establezca la gestién de claves para dar soporte al uso de técnicas criptograficas., 12.3.1 Politica de utilizacién de controles criptograficos Controt Se recomienda desarrollar e implementar una politica para el uso de controles criptograficos para la proteccién de la informacién. Guia de implementacién Es conveniente que cuando se desarrolle una politica criptogréfica se considere lo siguiente: a) el enfoque gerencial respecto del uso de controles criptograficos en toda la organizacion, in- luidos los principios generales segin los cuales se recomienda que se proteja la informacion (ver también 5.1.1); b) que se identifique, en base a una evaluacién de riesgos, el nivel requerido de proteccién te- niendo en cuenta el tipo, medida, y la calidad del algoritmo de encriptacion requeridi c) el uso de la encriptacién para la proteccién de informacién sensible transportada por un medio mévil o removible, dispositivos, 0 a través de lineas de comunicacién; d) el enfoque respecto de la administracion de claves, incluidos los métodos para administrar la proteccion de las claves criptograficas y la recuperacién de la informacién cifrada en caso de pérdida, compromiso 0 dafo de las claves; e) roles y responsabilidades, por ejemplo, quién es el responsable por: 1) la implementacién de la politica; 2) la administracién de las claves, incluyendo la generacién de las claves (ver también 12.3.2); f) las normas que han de adoptarse para la implementacién eficaz en toda la organizacién (qué soluciOn se aplica a qué procesos de negocio); g) el impacto del uso de informacién cifrada en controles que se basan en inspeccién de conteni- do (por ejemplo, deteccién de virus). ‘A\ implementar la politica criptografica de la organizacién, se recomienda que se consideren las nor- mas y restricciones nacionales que podrian aplicarse al uso de técnicas criptograficas en diferentes 103IRAM-ISO/IEC 27002:2008 partes del mundo, y las cuestiones relativas al flujo de informacién cifrada a través de fronteras (ver también 15.1.6). Los controles criptograficos se pueden usar para lograr diferentes objetivos de seguridad, por ejemplo: a) confidencialidad: empleando la encriptacion de la informaci6n para proteger la informacion sen- sible 0 critica, tanto almacenada como transmitida; b)_ integridad/autenticidad: usando firmas digitales o cédigos de autenticacién de mensajes para proteger la autenticidad y la integridad de la informacion sensible o critica, almacenada o trans- mitida; c) no repudio: usando técnicas criptograficas para obtener pruebas de la ocurrencia 0 no ocurren- cia de un evento 0 accién. Informacién adicional La toma de la decision acerca de si una solucién criptografica es la apropiada, es conveniente que se vea como parte de un proceso mas amplio de evaluacién de riesgos y seleccion de controles. Esta evaluacién puede ser usada para determinar si un control criptografico es apropiado, qué tipo de con- trol se recomienda aplicar y para qué propésites y procesos del negocio. Es necesario tener una politica para el uso de controles criptogréficos para maximizar los beneficios minimizar los riesgos del uso de técnicas criptogréficas, y para evitar el uso inapropiado o incorrec- to. Cuando se usan firmas digitales, es conveniente que se considere la legisiacién correspondiente, en particular la legisiacién que describe las condiciones bajo la cual una firma digital es legalmente vinculante (ver 15.1). Se recomienda que se busque el consejo de especialistas para identificar el nivel apropiado de pro- teccién y para definir especificaciones adecuadas que proveeran la proteccion requerida y el soporte de [a implementacién de un sistema de gestién de ciftado seguro (ver también 12.3.2). El ISO/IEC JTC1 SC27 ha desarrollado varias normas relacionadas con el control criptografico. Se puede encontrar mas informacién en IEEE P1363 y en OECD Guidelines on Cryptography. 12.3.2 Gestion de claves Control Se recomienda que se establezca la gestién de claves para dar soporte al uso organizacional de téc- nicas criptograficas. Guia de implementacion Se recomienda que todas las claves criptogréficas estén protegidas contra modificacién, pérdida y destruccién. Ademés, las claves secretas y privadas necesitan proteccién contra divulgacién no auto- rizada. Es conveniente que se provea de proteccién fisica al equipamiento utiizado para generar, almacenar y archivar claves. Se recomienda que un sistema de gestién de claves esté basado en un conjunto acordado de nor- mas, procedimientos y métodos seguros para a) generar claves para diferentes sistemas criptograficos y diferentes aplicaciones; b) generar y obtener certificados de clave piiblica; 104IRAM-ISO/IEC 27002:2008 ©) distribuir claves a los usuarios que corresponda, incluyendo cémo es conveniente que se acti- ven las claves cuando se reciben; 4) almacenar claves, incluyendo cémo obtienen acceso a las claves los usuarios autorizados; @) cambiar o actualizar claves incluyendo reglas sobre cuando es conveniente que se cambien las claves y cémo se llevara a cabo; f) _ocuparse de las claves comprometidas; 9) revocar claves incluyendo cémo se recomienda que se las retiren 0 desactiven, por ejemplo cuando las claves han sido comprometidas 0 cuando un usuario se desvincula de la organiza- cin (en cuyo caso también es conveniente que las claves se archiven); fh) recuperar claves que han sido perdidas o alteradas como parte de la gestion de la continuidad del negocio, por ejemplo para la recuperacién de la informacién encriptada; i) _archivar claves, por ejemplo para la informacién archivada o resguardada; i) destruir claves; k) registrar y auditar las actividades relativas a la gestion de claves. A fin de reducir la probabilidad de que las claves se vean comprometidas, se recomienda que tengan fechas de entrada y fin de vigencia, definidas de manera que s6lo puedan ser utilizadas por un perio- do limitado de tiempo. Es conveniente que este periodo de tiempo dependa de las circunstancias bajo las cuales se aplica el control criptografico, y del riesgo percibido. En adicién a la gestion segura de las claves secretas y privadas, se recomienda que también se con- sidere la autenticacién de las claves piblicas. El proceso de autenticacion puede ser llevado a cabo utiizando certificados de clave publica, los cuales normalmente son emitidos por una autoridad de certiicacién, la cual es conveniente que sea una organizacién reconocida, con adecuados controles y procedimientos implementados, para ofrecer el nivel de confianza requerido. Se recomienda que los contenidos de los acuerdos o contratos de nivel de servicio con proveedores externos de servicios criptograéficos, por ejemplo, con una autoridad de certificacién, comprendan los t6picos de responsabilidad legal, confiabilidad de servicio y tiempos de respuesta para la prestacion de los servicios (ver 6.2.3). Informacién adicional La gestion de claves criptograficas es esencial para el uso efectivo de técnicas criptogréficas. La ISO/IEC 11770 provee mayor informacién acerca de la gestion de claves. Los dos tipos de técnicas criptogréficas son: a) técnicas de clave secreta, donde dos o més partes comparten la misma clave y esta clave se utiliza tanto para cifrar informacion como para descifrarla. Esta clave tiene que mantenerse en secreto dado que cualquier persona que tenga acceso a la misma podré descifrar toda la in- formacién cifrada con dicha clave, o introducir informacién no autorizada usando la clave; b) técnicas de clave publica, donde cada usuario tiene un par de claves: una clave publica (que puede ser revelada a cualquier persona) y una clave privada (que debe mantenerse en secre- to). Las técnicas de clave publica pueden utilizarse para el cifrado y para producir firmas digitales (ver también ISO/IEC 9796 e ISO/IEC 14888). 105IRAM-ISO/IEC 27002:2008 Existe la amenaza de que una persona falsifique una firma digital reemplazando la clave publica de un usuario. Este problema es abordado mediante el uso de un certificado de clave publica. Las técnicas criptograficas pueden también usarse para proteger las claves criptograficas. Se pueden considerar procedimientos para el manejo de pedidos legales para el acceso a claves criptograficas, por ejemplo: puede ser necesaria informacién cifrada en una forma no cifrada como evidencia en un caso de juicio. 12.4 Seguridad de los archivos de sistema Objetivo: Garantizar la seguridad de los archivos de sistema. Se recomienda que se controle el acceso a los archivos del sistema y al cédigo fuente del programa, y que los proyectos de tecnologia de informacién y las actividades de soporte se conduzcan de ma- era segura, Es conveniente tener cuidado para evitar la exposicién de los datos sensibles en e! ambiente de pruebas. 12.4.1 Control del software operacional Control Es conveniente que existan procedimientos para controlar la instalacion de software en sistemas operacionaies. Guia de implementacién A fin de minimizar el riesgo de alteracién de los sistemas operacionales, se recomienda que se ten- gan en cuenta las siguientes directrices para controlar los cambios: a) que la actualizacién de software operacional, aplicaciones y de las bibliotecas de programas solo la realicen administradores entrenados bajo autorizacién apropiada de la gerencia (ver 12.4.3); b) que los sistemas operacionales s6lo guarden el cédigo ejecutable aprobado, y no cédigo en desarrollo 0 compiladores; c) que el software de aplicaciones y de sistema operative se implementen luego de una prueba extensiva y exitosa; se recomienda que las pruebas incluyan pruebas de uso, de seguridad, de efectos en otros sistemas y de cudn amigable es al usuario, y es conveniente que se lleven a cabo en sistemas separados (ver también 10.1.4); se recomienda que se asegure que todas las bibliotecas correspondientes al programa fuente hayan sido actualizadas; d) que se use un sistema de control para mantener el control de todo el software implementado asi como de la documentacion del sistema; e) que se establezca una estrategia de vuelta atrs antes que se implementen los cambios; f) que se mantenga un registro de auditoria de todas las actualizaciones de las bibliotecas de programas operacionales; 9) que se retengan las versiones previas del software de aplicacién como una medida de contin- gencia; 106IRAM-ISO/IEC 27002:2008 h) que las versiones viejas del software se archiven, junto con toda la informacién requerida, los Parémetros, los procedimientos, los detalles de configuracion, y el software de soporte como asi también que se retengan los datos en archivos. Es conveniente que el software provisto por un vendedor, que es usado en sistemas operacionales se mantenga en un nivel en el que el proveedor les de soporte. A través de tiempo, los vendedores de software cesaran de dar soporte a las viejas versiones de software. Se recomienda que la organi- zaci6n considere los riesgos de depender de software que no tiene servicio de soporte, Se recomienda que cualquier decision de actualizar una nueva versi6n tenga en cuenta los requeri- mientos de la actividad, y la seguridad de la versién, por ejemplo la introduccién de una nueva funcionalidad de seguridad o el nlimero y severidad de los problemas de seguridad que afectan esta version. Es conveniente que los parches de software sean aplicados cuando éstos ayuden a eliminar © reducir las debilidades de la seguridad (ver también 12.6.1), Es conveniente que el acceso fisico 0 ldgico sélo se de a los proveedores con fines de soporte, y con aprobacién de la gerencia. Se recomienda que se sigan y controlen las actividades del proveedor. El software puede depender de médulos y software provistos externamente, que se recomienda que se sigan y controlen para evitar cambios no autorizados, que puedan introducir debilidades de seguridad. Es conveniente que los sistemas operativos sélo se actualicen cuando existe un requerimiento para hacerlo, por ejemplo, si la version corriente del sistema operativo no brinda mas soporte a los reque- rimientos del negocio. Se recomienda que las actualizaciones no se realicen sélo porque esté disponible una nueva versién del sistema operativo. Las nuevas versiones de los sistemas operativos pueden ser menos seguras, menos estables, y menos comprendidas que los sistemas en curso. 12.4.2 Proteccién de los datos de prueba del sistema Controt Es conveniente que se seleccionen cuidadosamente, se protejan y controlen los datos de prueba. Guia de implementacién Es conveniente que se evite el uso de las bases de datos operacionales que contengan informacion personal o cualquier otra informacion sensible para propésitos de prueba. Se recomienda que si la in- formacién personal o sensible es usada para propésitos de prueba, se eliminen o modifiquen todos los detalles y contenido sensibles para que sean irreconocibles, antes de su uso. Es conveniente que se apliquen las directrices nombradas a continuacion para proteger los datos operacionales, cuando se usen con propésitos de prueba: a) que los procedimientos de control de accesos, que se aplican a los sistemas de aplicacién en operacién, también se apliquen a los sistemas de aplicacion de prueba; b) que exista una autorizacién particular por cada vez que se copie informacion operativa a un sis- tema de aplicacion de pruebas; c) que se borre la informacién operativa de un sistema de aplicacién de prueba inmediatamente después de completada la prueba; d) que se lleve registro de la copia y el uso de informacién operacional a fin de suministrar un sendero de auditoria. 107IRAM-ISO/IEC 27002:2008 Informacién adicional Las pruebas de sistema y de aceptacién usualmente requieren volmenes sustanciales de datos de prueba que sean tan semejantes como sea posible a los datos operacionales. 12.4.3 Control de acceso al cédigo fuente de programa Control Se recomienda que se restrinja el acceso al cédigo fuente de programa. Guia de implementacién Es conveniente que el acceso al cédigo fuente de programa y a los items asociados (tales como di- sefio, especificaciones, planes de verificacién y planes de validacién) esté estrictamente controlado, para prevenir la introduccién de funcionalidad no autorizada y para evitar cambios no intencionales. Esto puede lograrse por un almacenamiento central controlado de tal cédigo, preferentemente en bi- bliotecas de fuentes de programa. Se recomienda que se consideren las directrices siguientes (ver también 11) para controlar el acceso a dichas bibliotecas de programas fuente para reducir la poten- cial corrupcién de los programas de computadora: a) cuando sea posible, que las bibliotecas de programas fuente no se mantengan en los sistemas operacionales; b) que el cédigo fuente del programa y las bibliotecas de cédigo de programas se gestionen de acuerdo a procedimientos establecidos; ©) que el personal de soporte no tenga acceso irrestricto a las bibliotecas de programas fuente; 4) que las actualizaciones de bibliotecas de programa fuente y los items asociados, y la distribu- cién de los programas fuente a los programadores se lleve a cabo después de que se otorgue la autorizacién apropiada; €) que los listados de programas se almacenen en un ambiente seguro (ver 10.7.4); f) que se mantenga un registro de auditoria de todos los accesos a las bibliotecas de programas fuente: 9) que el mantenimiento y la copia de las bibliotecas de programas fuente se encuentre sujeta a procedimientos estrictos de control de cambios (ver 12.5.1). Informacién adicional El programa fuente es un cédigo escrito por programadores, que se compila (y vincula) para crear ejecutables. Ciertos lenguajes de programacién no distinguen formaimente entre cédigo fuente y eje- cutables porque los ejecutables son creados en el momento en que son activados. Las normas ISO 10007 e ISO/IEC 12207 proveen mayor informacién acerca de la gestion de configu- racion y el proceso del ciclo de vida. 108IRAM-ISO/IEC 27002:2008 12.5 Seguridad en los procesos de desarrollo y soporte Otjetivo: Mantener la seguridad del software y la informacion del sistema de aplicacién. Se recomienda que se controlen estrictamente los ambientes de proyectos y de soporte. Es conveniente que los gerentes responsables de los sistemas de aplicacién también se responsabi- licen de la seguridad del ambiente de proyecto o de soporte. Se recomienda que ellos garanticen la revision de todos los cambios propuestos para el sistema, a fin de comprobar que no comprometen la seguridad del sistema o del ambiente operativo. 12.5.1 Procedimientos de control de cambios Control Es conveniente que la implementacién de cambios se controle mediante el uso de procedimientos formales de control de cambios, Guia de implementacién A fin de minimizar la alteracién de los sistemas de informacién, se recomienda que se documente y se ponga en vigor un proceso formal de control de cambios. Es conveniente que la introduccién de nuevos sistemas y de cambios grandes en los sistemas existentes sea seguida de un proceso formal de documentacion, especificaci6n, pruebas, control de calidad, e implementacién gestionada. Es conveniente que este proceso incluya una evaluacién de riesgos, un andlisis de los impactos de los cambios, y las especificaciones de los controles de seguridad necesarios. Se recomienda que es- tos procesos garanticen que no se hayan alterado los procedimientos de seguridad y control existentes, que los programadores de soporte sélo tengan acceso a aquellas partes del sistema ne- cesarias para el desemperio de sus tareas, y que se obtenga un acuerdo y aprobacién formales para cualquier cambio, Siempre que resulte factible, es conveniente que los procedimientos de control de cambios operati- vos y de las aplicaciones se encuentren integrados (ver también 10.1.2). Se recomienda que los procedimientos de cambio incluyan: a) mantenimiento de un registro de los niveles de autorizacién acordados; b) garantia de que los cambios son propuestos por usuarios autorizados; c) controles de revision y los procedimientos de integridad para garantizar que no seran compro- metidos por los cambios; 4) _identificacién de todo el software, la informacion, las entidades de bases de datos y el hardware que requieran correcciones; e) aprobacién formal para las propuestas detalladas antes de que comiencen las tareas; f) garantia de que los usuarios autorizados aceptan los cambios antes de su implementacion; 9) garantia de que el conjunto de la documentacién del sistema se encuentra actualizada cada vez que se completa un cambio y de que se archiva o elimina la documentacién vieja; h)_mantenimiento de un control de versiones para todas las actualizaciones de software; 109IRAM-ISO/IEC 27002:2008 i) mantenimiento de una huella de auditoria de todas las solicitudes de cambios; j) garantizar que la documentacién operativa (ver 10.1.1) y los procedimientos de usuarios se modifiquen segun las necesidades para que se mantenga adecuada k) garantia de que la implementacién de los cambios tenga lugar en el momento adecuado y no altere los procesos comerciales involucrados. Informacién adicional El software que cambia puede tener impacto en el ambiente operacional. La buena practica incluye las pruebas de un nuevo software en un ambiente separado de los ambien- tes de produccién y desarrollo (ver también 10.1.4). Esto provee una forma de tener control sobre un nuevo software y permite proteccién adicional de la informacion operacional que es usada con pro- pésitos de prueba. Se recomienda que esto incluya parches, paquetes de servicio, y otras actualizaciones. Es conveniente que las actualizaciones automaticas no se realicen sobre sistemas criticos ya que algunas actualizaciones pueden hacer que las aplicaciones criticas fallen (ver 12.6). 12.5.2 Revisiones técnicas de las aplicaciones luego de cambios en el sistema operative Control! Cuando se realizan cambios en los sistemas operativos, se recomienda que se revisen y prueben las aplicaciones criticas del negocio para garantizar que no se produzca un impacto adverso en las ope- raciones 0 la seguridad organizacionales Guia de implementacién Es conveniente que este proceso cubra: a) la revision de procedimientos de integridad y control de aplicaciones para garantizar que éstos no hayan sido comprometidos por los cambios del sistema operativo; b) la garantia de que el plan y presupuesto de soporte anual contemple las revisiones y las prue- bas del sistema como consecuencia del cambio en el sistema operativo: ©) la garantia de que se notifiquen los cambios del sistema operativo en tiempo, para permitir que se leven a cabo pruebas y revisiones apropiados antes de la implementacién; 4) la garantia de que se realicen los cambios apropiados a los planes de continuidad de! negocio (ver capitulo 14) Es conveniente que un grupo especifico o un individuo tenga la responsabilidad del seguimiento y con- trol de las vulnerabilidades y las publicaciones de parches y reparaciones de parte de los vendedores (ver 12.6). 12.5.3 Restriccién de cambio en los paquetes de software Control Es conveniente que se desalienten las modificaciones a los paquetes de software y se limiten a los cambios necesarios. Se recomienda que se controlen estrictamente todos los cambios. 110IRAM-ISO/IEC 27002:2008 Guia de implementacién En la medida de lo posible, y de lo viable, es conveniente que los paquetes de software suministra- dos por proveedores se utilicen sin modificaciones. Se recomienda que, cuando sea necesario modificar un paquete de software, se consideren los siguientes puntos: a) el riesgo de que se comprometan los procesos de integridad y controles incorporados; b) _sies conveniente la obtencién del consentimiento del proveedor; ©) la posibilidad de obtener los cambios requeridos a través del proveedor en forma de actualiza- ciones normales de programas; d) el impacto que se produciria si la organizacion se hace responsable de! mantenimiento futuro del software como resultado de los cambios. Si los cambios se consideran necesarios, se recomienda que se retenga el software original y se apliquen los cambios a una copia claramente identificada. Es conveniente que se implemente un pro- ceso de gestion de actualizacién del software para garantizar que se instalen los parches aprobados y las actualizaciones de aplicaciones mas actualizadas para todo el software autorizado (ver 12.6). ‘Se recomienda que todos los cambios se prueben y documenten completamente, de manera que puedan aplicarse nuevamente, de ser necesario, a futuras actualizaciones de software. En caso de ser necesario, se recomienda que las modificaciones sean probadas y validadas por un ente evalua- dor independiente. 12.5.4 Fuga de la informacion Control ‘Se recomienda que se prevengan las oportunidades de fuga de la informacién. Guia de implementacién Es conveniente que para limitar el riesgo de fuga de la informacién, por ejemplo, a través del uso y explotacién de los canales encubiertos, se considere lo siguiente: a) exploracién de las comunicaciones y medios de salida en busca de informacién oculta; b) enmascaramiento y modulacién del comportamiento de los sistemas y las comunicaciones para reducir la probabilidad de que a una tercera parte le sea posible deducir la informacién de tal ‘comportamiento; ©) uso de sistemas y software considerados como de alta integridad, por ejemplo usando produc- tos evaluados (ver la ISO/IEC 15408); 4d) seguimiento de manera regular de las actividades del personal y del sistema, cuando ésto se permita conforme a las legislaciones 0 a las regulaciones existentes; 2) seguimiento del uso de los recursos de los sistemas informaticos. Informacién adicional Los canales encubiertos son caminos que no apuntan a conducir flujo de informacion, pero que sin embargo pueden existir en un sistema o en una red. Por ejemplo, la manipulacién de los bits en los paquetes de los protocolos de comunicacién puede usarse como un método oculto de sefializacién. Por su naturaleza, la prevencién de la existencia de todos los posibles canales puede ser dificultosa, sino es imposible. Sin embargo, la explotacién de tales canales es con frecuencia llevada a cabo por 1IRAM-ISO/IEC 27002:2008 cédigo troyano (ver también 10.4.1). La toma de medidas para protegerse del cédigo troyano reduce el riesgo de la explotacién de los canales encubiertos. La prevencién del acceso no autorizado a las redes (11.4), asi como las politicas y los procedimien- tos para prevenir el mal uso de los servicios de informacién por parte del personal (15.1.5), ayudaré a la proteccién contra los canales encubiertos. 12.5.5 Desarrollo tercerizado de software Control Se recomienda que la organizacién supervise, siga y controle el desarrollo externo del software. Guia de implementacion Es conveniente que cuando se terceriza el desarrollo del software, se consideren los puntos siguientes: a) acuerdos de licencias, propiedad de cédigo y derechos de propiedad intelectual (ver 15.1.2); b) _certificacién de la calidad y precisién del trabajo llevado a cabo; ©) acuerdos de custodia (“escrow”) en caso de falla de la tercera parte: d) derechos de acceso para auditar la calidad y precision del trabajo realizado; @) requerimientos contractuales con respecto a la calidad y a la seguridad funcional del codigo; )_realizacion de pruebas previo a la instalacion, para detectar cédigo troyano y malicioso. 12.6 Gestién de vulnerabilidades técnicas Objetivo: Reducir el riesgo resultante de la explotacién de vulnerabilidades técnicas publicadas. Se recomienda que la gestion de las vulnerabilidades técnicas se implemente en una forma efectiva, sistematica y repetible, con mediciones que confirmen su efectividad. Es conveniente que estas con- sideraciones incluyan a los sistemas operativos, y cualquier otra aplicacién en uso. 12.6.1 Control de las vulnerabilidades técnicas Controt Se recomienda que se obtenga informacion oportuna acerca de las vulnerabilidades técnicas de los sistemas de informacion que son utilizados; que se evalle la exposicidn de la organizacién a tales vulnerabilidades, y que se tomen las medidas adecuadas para tratar los riesgos asociados. Guia de implementacién La realizacién de un inventario actualizado y completo de los activos (ver 7.1) es un prerrequisito pa- ra una efectiva gestion de vulnerabilidades técnicas. La informacion especifica necesaria para dar soporte a la gestion de las vulnerabilidades técnicas incluye al vendedor de software, numeros de versi6n, estado actual del desarrollo (por ejemplo, qué software esta instalado en qué sistemas), y las personas de la organizacién responsables por el software. 112IRAM-ISO/IEC 27002:2008 Se recomienda que se tome una accién oportuna en respuesta a la identificacién de las vulnerabili- dades técnicas potenciales en forma apropiada. Es conveniente que se sigan las siguientes directrices para establecer un proceso de gestién efectivo de las vulnerabilidades técnicas: a) b) °) 4) °) o) 9) h) i) Informa que la organizacién defina y establezca los roles y responsabilidades asociados con la gestion de vulnerabilidades técnicas, incluyendo seguimiento de la vulnerabilidad, evaluacién de los riesgos de la vulnerabilidad, parches, rastreo del activo, y cualquier responsabilidad de coordi- nacién requerida; que se identifiquen por software y otras tecnologias, basadas en la lista de inventario de activos (ver 7.1.1) los recursos de informacion que serdn usados para identificar las vulnerabilidades técnicas relevantes y para mantener la conciencia sobre ellas; es conveniente que estos recur- 0s de informacion se actualicen en base a los cambios en el inventario, 0 cuando se encuentren otros recursos nuevos o utiles; que se defina una linea de tiempo para reaccionar ante las notificaciones de las vulnerabilida- des técnicas potencialmente relevantes; una vez que se ha identificado una potencial vulnerabilidad técnica, que la organizacién identi- fique los riesgos asociados y las acciones a llevar a cabo; tales acciones pueden involucrar la introduccién de un parche a los sistemas vulnerables y/o las aplicacién de otros controles; dependiendo de la urgencia con la que se debe atender la vulnerabilidad técnica, que la accién tomada se lleve a cabo de acuerdo con los controles relacionados con la gestién de cambios (ver 12.5.1) 0 siguiendo los procedimientos de respuesta a incidentes de seguridad de la infor- macién (ver 13.2); si hay un parche disponible, que se atiendan los riesgos asociados a la instalacién del parche (se recomienda que se comparen los riesgos presentados por la vulnerabilidad contra los ries- gos de la instalaci6n del parche); que se prueben y evaliien os parches antes de instalarlos para garantizar que son efectivos y que no tienen como resultado efectos secundarios que no puedan ser tolerados; si no existe un parche disponible, es conveniente que se consideren otros controles, tales como: 1) desactivacion de los servicios o las capacidades relacionados con la vulnerabilidad; 2) adaptacién o adicién de controles de acceso, por ejemplo, “firewalls” de las fronteras de las redes (ver 11.4.5); 3) incremento de! seguimiento para detectar o prevenir ataques; 4) aumento de la conciencia acerca de las vulnerabilidades; se recomienda que se mantenga un registro de auditoria para todos los procedimientos em- prendidos; se recomienda que el proceso de gestion de las vulnerabilidades técnicas se siga y evaliie re- gularmente para garantizar su efectividad y eficiencia; se recor jienda que se atiendan primero los sistemas de alto riego. n adicional EI correcto funcionamiento del proceso de gestién de las vulnerabilidades técnicas de una organiza- cién es para muchas organizaciones un proceso critico, por lo que es conveniente que se realice un seguimiento en forma periédica. Es esencial tener un inventario exacto para garantizar que se ide! fican las vulnerabilidades técnicas potencialmente relevantes. 113,IRAM-ISO/IEC 27002:2008 La gestion de las vulnerabilidades técnicas puede ser vista como una subfuncién de la gestin de cambios y como tal puede tomar ventaja de los procesos y procedimientos de la gestion de cambios (ver 10.1.2 y 12.5.1) Los vendedores estan con frecuencia bajo la presién significativa de publicar parches tan pronto co- mo sea posible. Debido a esto, los parches pueden no tratar el problema de forma adecuada y pueden ocasionar efectos colaterales negativos. También, en algunos casos, la desinstalacién de un parche puede no ser facil, una vez que se ha aplicado el parche. Sino es posible una adecuada prueba de los parches, por ejemplo, debido a los costos 0 carencia de recursos, se puede considerar una demora en la aplicacién de los parches para evaluar los riesgos asociados, en base a la experiencia reportada por otros usuarios. 13 GESTION DE LOS INCIDENTES DE LA SEGURIDAD DE LA INFORMACION 13.1 Informe de los eventos y debilidades de la seguridad de la informacion Objetivo: Garantizar que los eventos de seguridad de la informacién y las debilidades asociados a los sistemas de informacién se comuniquen de forma tal que se apliquen las acciones correctivas en el tiempo correcto, Se recomienda que se establezcan procedimientos formales de intensificacion y reporte de eventos. Es conveniente que todos los empleados, contratistas y usuarios de terceras partes tengan concien- cia de los procedimientos para el reporte de los diferentes tipos de eventos y debilidades que Podrian tener un impacto en la seguridad de los activos de la organizacion. Se recomienda que ellos reporten cualquier evento o debilidad de seguridad de la informacién, tan pronto como sea posible, al punto de contacto designado. 13.1.1. Reporte de los eventos de la seguridad de la informacién Control Se recomienda que los eventos de seguridad de la informacion se reporten mediante canales de ges- tién apropiados tan pronto como sea posible. Guia de implementacién Es conveniente que se establezca un procedimiento de reporte formal de eventos de seguridad de la informacién, junto con un procedimiento de respuesta a incidentes y escalonamiento, especificando la accién a realizar cuando se reciba un reporte de un evento de seguridad de la informacién. Se re- comienda que se establezca un punto de contacto para el reporte de eventos de seguridad de la informacién. Es conveniente que se asegure que este punto de contacto se conozca a través de la organizacién, que se encuentre siempre disponible y que tenga la capacidad de brindar soluciones adecuadas y’a tiempo. Se recomienda que todos los empleados, contratistas y usuarios de terceras partes tengan concien- cia de su responsabilidad de reportar cualquier evento de seguridad de la informacién tan pronto sea posible. Es conveniente que ellos tengan conciencia del procedimiento para el reporte de los eventos de seguridad de la informacién y del punto de contacto. Se recomienda que los procedimientos de reporte incluyan: 114IRAM-ISO/IEC 27002:2008 a) procedimientos de retroalimentacién adecuados para garantizar que se notifique a aquellas Personas que reportan eventos de seguridad de la informacién de los resultados después de que el tema haya sido atendido y cerrado; b) formularios de reporte de eventos de seguridad de la informacién para dar soporte a la accién reportada, y para ayudar a la persona que reporta, a recordar todas las acciones necesarias en caso de un evento de la seguridad de la informacion; ©) cual es el comportamiento correcto en caso de un evento de seguridad de la informacion, por ejemplo: 1) tomar nota de todos los detalles importantes (por ejemplo tipo de no cumplimiento o bre- ccha, mal funcionamiento ocurrente, mensajes en la pantalla, comportamiento inusual) en forma inmediata; 2) no llevar a cabo ninguna accion en forma propia, sino reportar en forma inmediata al punto de contacto; d) buscar referencias de un proceso formal disciplinario establecido para tratar con los emplea- dos, contratistas o usuarios de terceras partes que cometan violaciones de seguridad. En ambientes de alto riesgo, se proveera una alarma de coaccién“ por la cual una persona bajo co- accién pueda indicar tales problemas. Se recomienda que los procedimientos para responder a las alarmas de coaccién refiejen las situaciones de alto riesgo que las alarmas estan indicando. Informacién adicional Los ejemplos de eventos e incidentes de la seguridad de la informacion son: a) pérdida de servicio, equipamiento o instalaciones; b)_ mal funcionamiento 0 sobrecarga del sistema; ©) errores humanos; 4) no cumplimientos con tas politicas o directrices; e) Violaciones de acuerdos de seguridad fisica; f) cambios no controlados en el sistema; 9) mal funcionamiento del software o del hardwai h)__violaciones de acceso. Con el cuidado debido de los aspectos de confidencialidad, los incidentes de la seguridad de la in- formacién pueden usarse para el entrenamiento de concientizacién de los usuarios (ver 8.2.2) como ejemplo de qué puede ocurrir, cémo responder a tales incidentes, y cémo evitarlos en el futuro. Para tener la capacidad de atender los eventos e incidentes de la seguridad de la informacién en forma adecuada podria ser necesario recolectar evidencia tan pronto como sea posible luego de que hayan ocurtido (ver 13.2.3). EI mal funcionamiento u otras anomalias en el comportamiento del sistema pueden ser indicadores de un ataque de seguridad o una violacién de la seguridad actual y se recomienda que siempre se reporte como un evento de la seguridad de la informacion. 4) Una alarma de coaccién es un método para indicar secretamente que se esta llevando a cabo una accion bajo coaccin. 115IRAM-ISO/IEC 27002:2008 Mayor informacion acerca del informe de eventos de seguridad de la informacion y la gestion de los incidentes de seguridad de la informacién puede encontrarse en la ISO/IEC TR 18044. 13.1.2 Reporte de las debilidades de la seguridad Controt Es conveniente que se requiera que todos los empleados, contratistas y usuarios de terceras partes de los sistemas y servicios de informacién tomen nota y reporten cualquier accién sospechosa que observen o consideren que esté relacionada con las debilidades de seguridad de los sistemas 0 de los servicios. Guia de implementacion Se recomienda que todos los empleados, contratistas y usuarios de terceras partes reporten estos temas, a su gerente o directamente a su proveedor de servicio tan pronto como sea posible para pre- venir incidentes de seguridad de la informacion. Es conveniente que los mecanismos de reporte sean faciles, accesibles, y estén disponibles en la mayor medida que sea posible. Se recomienda que se informe a los empleados, contratistas y usuarios de terceras partes que no intenten, bajo ninguna cir- cunstancia, probar una sospecha de debilidad, Informacién adicional Es conveniente que los empleados, contratistas y usuarios de terceras partes estén sobre aviso de no intentar probar las debilidades a la seguridad sospechadas. Probar las debilidades podria ser interpre- tado como un potencial mal uso del sistema y puede también causar dafo al sistema o servicio de la informacién y resultar en un problema de responsabilidad legal para la persona que realice la prueba. 13.2 Gestién de los jentes y mejoras de la seguridad de la informacion Objetivo: Asegurar que se aplique un enfoque consistente y efectivo a la gestién de incidentes de seguridad de la informacién Se recomienda que se establezcan las responsabilidades y procedimientos para manejar efectiva- mente los eventos y las debilidades de seguridad de la informacién una vez que hayan sido reportados. Es conveniente que se aplique un proceso de mejora continua para la respuesta, se- guimiento, evaluacion, y gestion general de los incidentes de seguridad de la informacién. Cuando se requieran evidencias, se recomienda reunirias para garantizar el cumplimiento con los requerimientos legales. 13.2.1 Responsabilidades y procedimientos Controt Se recomienda que se establezca una gestion de las responsabilidades y procedimientos para garan- tizar una respuesta répida, efectiva y ordenada de los incidentes de seguridad de la informacién. Guia de implementacion En adicién al reporte de los eventos y debilidades de seguridad de la informacién (ver también 13.1), se recomienda el uso de seguimiento de los sistemas, alertas y vulnerabilidades (10.10.2) para de- tectar los incidentes de seguridad de la informacion. Es conveniente que se consideren los siguientes Puntos en los procedimientos de la gestidn de fos incidentes de seguridad de la informacion: 116IRAM-ISO/IEC 27002:2008 a) se recomienda que se establezcan los procedimientos para manejar los diferentes tipos de in- cidentes de seguridad de la informacion, incluyendo: 1) fallas de los sistemas de informacién y pérdidas del servicio; 2) cédigo malicioso (ver 10.4.1); 3) _negacién de servicio; 4) errores a causa de datos comerciales incompletos o inexactos; 5) _violaciones de la confidencialidad y de la integridad; 6) mal uso de los sistemas de informacion; b) ademas de los planes de contingencia normales (ver 14.1.3), se recomienda que los procedi- mientos también cubran: 1) _andlisis e identificacién de la causa del incidente; 2) contencién; 3) planificacién e implementacion de la accién correctiva para prevenir la recurrencia, en caso de ser necesario; 4) comunicacién con las partes afectadas o involucradas con la recuperacién de los incidentes; 5) reporte, de la accién, a la autoridad apropiada; ©) se recomienda que se recolecten y aseguren los senderos de auditoria y evidencias similares (ver 13.2.3), seguin corresponda, para: 1) _analisis de problemas internos; 2) uso como prueba forense en relacién a la violacién potencial de contrato 0 requerimiento regulador o en el evento de procedimientos civiles 0 criminales, por ejemplo, el mal uso de la computadora o de la legislacién de proteccién de datos; 3) negociacién para la compensacién de los proveedores de software y servicios; 4) se recomienda que se controlen cuidadosa y formalmente las acciones para la recuperacién de las violaciones de seguridad y las fallas al sistema; es conveniente que los procedimientos ga- ranticen que’ 1) solamente el personal claramente identificado y autorizado tenga permitido el acceso a los sistemas y a los datos en vivo (ver también 6.2 para acceso extemno); 2) todas las acciones de emergencia llevadas a cabo se documenten en detalle; 3) las acciones de emergencia se reporten a la gerencia y se revisen de forma ordenada; 4) se confirme la integridad de los sistemas y controles de! negocio con el minimo retraso. Es conveniente que los objetivos de la gestién de seguridad de la informacion se acuerden con la ge~ rencia, y que se asegure que aquellas personas responsables por la gestion de incidentes de seguridad de la informacion comprendan las prioridades de la organizacién para el manejo de los in- cidentes de seguridad de la informacién. 17IRAM-ISO/IEC 27002:2008 Informacién adicional Los incidentes de seguridad de la informacién podrian trascender los limites organizacionales y na- cionales. Para responder a tales incidentes existe una necesidad creciente de coordinar la respuesta y compartir informacién acerca de estos incidentes con organizaciones externas seguin corresponda. 43.2.2 Aprendizaje a partir de los incidentes de la seguridad de la informacion Control ‘Se recomienda que existan mecanismos para permitir que se cuantifiquen y supervisen los tipos, vo- lamenes, y costos de los incidentes de la seguridad de la informacion. Guia de implementacion Es conveniente que la informacién obtenida de la evaluacién de los incidentes de seguridad de la in- formacién se utilice para identificar los incidentes recurrentes 0 de alto impacto. Informacién adicional La evaluacién de los incidentes de seguridad de la informacion puede indicar la necesidad de mejorar © adicionar controles para limitar la frecuencia, dafio, y costo de futuras ocurrencias, 0 para que se tengan en cuenta en el proceso de revision de la politica de seguridad (ver 5.1.2). 13.2.3 Recoleccién de evidencia Control Cuando se lleve a cabo un seguimiento sobre una persona u organizacién luego de que haya ocurri- do un incidente de seguridad de la informacion que involucre acciones legales (ya sea civil o criminal), se recomienda que se recolecte, retenga y presente evidencia para cumplir con los reque- rimientos legales en la jurisdicci6n que corresponda. Guia de implementacién Se recomienda que se desarrollen y sigan procedimientos intemos cuando se recolecta y se presenta evidencia con el propésito de manejar un accién disciplinaria dentro de una organizacién. En general, las reglas para la evidencia consideran: a) admisibilidad de la evidencia: si la evidencia puede o no ser usada en la corte; b) peso de la evidencia: la calidad y la completitud de la evidencia. Para lograr la admisibilidad de la evidencia, se recomienda que la organizacién garantice que sus sis- temas de informacion cumplen con una norma publicada o con el cbdigo de practica para la produccién de evidencia admisible. ‘Se recomienda que el peso de la evidencia provista cumpla con los requerimientos aplicables. Para lo- grar el peso de la evidencia, se recomienda que la calidad y la completitud de los controles usados para la correcta y consistente proteccién de la evidencia (por ejemplo evidencia de control de procesos) or el periodo que la evidencia a ser recuperada se almacene y procese, se demuestre por un fuerte rastro de evidencia. En general, tales rastros pueden ser establecidos bajo las condiciones siguientes: a) documentos en papel: el original se guarda en forma segura con un registro de la persona que en- contré el documento, dénde fue encontrado el documento, cudindo fue encontrado y qué personas presenciaron el descubrimiento; es conveniente que se asegure mediante una investigacion que los originales no han sido modificados; 118IRAM-ISO/IEC 27002:2008 ) informacion en medios informaticos: se recomienda que las imagenes espejo 0 copias (depen- diendo de los requerimientos aplicables) de cualquier medio removible, la informacién en los discos rigidos o en memoria se guarde para asegurar su disponibilidad; es conveniente que se mantenga registro de todas las acciones realizadas durante el proceso de copiado y se testif que el proceso; se recomienda que se mantengan en forma segura e intacta el medio original y el registro (si no es posible, al menos una imagen espejo o una copia). Se recomienda que los trabajos forenses se realicen sobre copias de la evidencia material. Es con- veniente que se proteja la integridad de toda evidencia material. Se recomienda que la copia del material de evidencia sea supervisado por personal confiable y se lieve registro de la informacion so- bre cuando y dénde fue ejecutado el proceso de copiado, quien realizé las actividades de copiado y qué herramientas y programas han sido utilizados. Informacién adicional Cuando se detecta por primera vez un evento de seguridad, puede no ser obvio si el evento resultaré © no en una accién legal. Por consiguiente, existe el peligro que la evidencia necesaria se destruya intencional o accidentalmente antes que se perciba la seriedad del incidente Es aconsejable involu- crar en forma temprana a un abogado 0 a la policia ante cualquier accién legal contemplada y asesorarse sobre la evidencia requerida La evidencia puede trascender los limites organizaciones y/o jurisdiccionales. En tales casos, se reco- mienda que se asegure que la organizacién se encuentre autorizada a recolectar la informacion requerida como evidencia. Es conveniente que también se consideren los requerimientos de diferentes jurisdicciones para maximizar las posibilidades de admisién a través de las jurisdicciones correspon- dientes. 14 GESTION DE LA CONTINUIDAD DEL NEGOCIO 14.1 Aspectos de la seguridad de Ia informacién en la gestién de la continuidad del negocio ‘Objetivo: Contrarrestar las interrupciones de las actividades de la organizacién y proteger los proce- 08 criticos de! negocio de los efectos de las fallas significativas de los sistemas de informacién o desastres y asegurar su reanudacién oportuna. Se recomienda que se implemente un proceso de gestién de la continuidad del negocio para minimi- zar el impacto en la organizacién y para recuperarse de las pérdidas de los activos de informacion (los cuales pueden ser el resultado de por ejemplo: desastres naturales, accidentes, fallas en el equipamiento 0 acciones deliberadas) a un nivel aceptable mediante una combinacién de controles preventivos y de recuperaci6n. Es conveniente que este proceso identifique los procesos criticos de Negocios e integre los requerimientos de la gestién de seguridad de la informacion para la continui- dad de! negocio con otros requerimientos de continuidad relacionados con aspectos tales como ‘operaciones, recursos humanos, materiales, transporte e instalaciones. Se recomienda que las consecuencias de desastres, fallas de seguridad, pérdidas de servicio y de disponibilidad de servicio, se encuentren sujetas a un analisis de impacto en el negocio. Es conve- niente que se encuentren desarrollados e implementados los planes de continuidad del negocio para asegurar la reanudacién oportuna de las operaciones esenciales. Se recomienda que la seguridad de la informacién sea una parte integral del proceso general de continuidad del negocio, y de otros procesos de gestion dentro de la organizacién. 119IRAM-ISO/IEC 27002:2008 Es conveniente que la gestion de la continuidad del negocio incluya controles destinados a identif- car y reducir riesgos, en adicién al proceso general de evaluacién del riesgo, limitando las consecuencias de los incidentes perjudiciales y asegurando que la informacion requerida por los procesos del negocio se encuentre prontamente disponible. 14.1.1 Inclusion de la seguridad de la informacién en el proceso de gestidn de la continuidad del negocio Controt Se recomienda que se desarrolle y mantenga un proceso de gestion que dirja los requerimientos de seguridad de la informacién necesarios para la continuidad de la actividad de la organizacién. Guia de implementacién Se recomienda que el proceso retina los siguientes elementos principales de la gestion de la conti- nuidad de! negocio: a) comprensién de los riesgos que la organizacién est enfrentando en términos de probabilidad e impacto en el tiempo, incluyendo una identificacién y priorizacién de los procesos criticos del negocio (ver 14.1.2); b) identificacién de todos los activos involucrados en los procesos criticos de negocios (ver 7.1.1); ©) comprensién del impacto que las interrupciones causadas por los incidentes de seguridad de la informacién puedan tener en el negocio (es importante encontrar las soluciones que manejarén tanto los incidentes que causen menor impacto, como los incidentes graves que puedan amena- zar la viabiidad de la organizacién), y establecer los objetivos de las instalaciones de procesamiento de la informacién; 8) consideracién de la contratacién de seguros adecuados que puedan formar parte del proceso general de continuidad del negocio, como también formar parte de la gestion de riesgo operacio- nal; e) _identificacién y consideracién de la implementacién de controles adicionales preventivos y miti- gantes; 4) identificacién de los recursos financieros, organizacionales, técnicos, y ambientales suficientes para manejar los requerimientos de seguridad de la informacién identificados; 9) garantia de la seguridad del personal y la proteccién de las instalaciones del procesamiento de la informacion y de la propiedad de la organizacion; h) formutacion y documentacién de planes de continuidad del negocio que conduzcan los reque- rimientos de seguridad de la informacién en linea con la estrategia de continuidad de negocios acordada (ver 14.1.3); i) _ pruebas y actualizaciones periédicas de los planes y los procesos en operacién (ver 14.1.5); j) garantia de que la gestién de continuidad de! negocio esta incorporada en los procesos y la es- tructura de la organizacién. Se recomienda que la responsabilidad del proceso de gestién de continuidad del negocio se asigne a un nivel apropiado dentro de la organizacién (ver 6.1.1), 120IRAM-ISO/IEC 27002:2008 14.1.2 Continuidad del negocio y evaluacién de los riesgos Controt Se recomienda que se identifiquen los eventos que puedan causar interrupciones de los procesos de! negocio, junto con la probabilidad y el impacto de tales interrupciones y sus consecuencias en la se- guridad de la informacion. Guia de implementacién Es conveniente que los aspectos de seguridad de la continuidad del negocio estén basados en la identificacion de eventos (0 secuencia de eventos) que puedan causar interrupciones de los procesos comerciales de la organizacién, por ejemplo, fallas en el equipamiento, errores humanos, robo, in- cendio, desastres naturales y actos de terrorismo. Se recomienda que ésto se siga por una evaluacion de los riesgos para determinar la probabilidad y el impacto de tales interrupciones, en terminos de tiempo, escala de dafios y periodo de recuperacién. Es conveniente que la evaluacién de los riesgos de la continuidad del negocio se lleve a acabo con total participacién de los propietarios de los recursos y de los procesos del negocio. Se recomienda que esta evaluacién considere todos los procesos del negocio y no se limite a las instalaciones de procesamiento de la informacién, pero incluya los resultados especificos de la seguridad de la infor- macién. Es importante vincular los distintos aspectos de los riesgos en forma conjunta, para obtener tuna imagen completa de los requerimientos de la continuidad de los negocios de la organizacién. Es conveniente que la evaluacién identifique, cuantifique y otorgue prioridad a los riesgos contra los cri- terios y objetivos correspondientes de la organizacién, incluyendo recursos criticos, impacto de las interrupciones, tiempos de parada disponible y prioridades de recuperacién. Dependiendo de los resultados de la evaluacién, se recomienda que se desarrolle una estrategia pa- ra la continuidad del negocio para determinar el enfoque global con el que se abordard la continuidad de los negocios. Una vez que se ha creado este plan, es conveniente que éste sea aprobado por la gerencia, y se cree y sustente un plan para implementar esta estrategia 14.1.3 Elaboracién e implementacién de planes de continuidad que incluyan la seguridad de {a informacion Control Es conveniente que se desarrollen e implementen planes para mantener o restablecer las operacio- nes y asegurar la disporibilidad de la informacién en el nivel y en las escalas de tiempo requeridas luego de la interrupcion o falla de los procesos criticos del negocio. Guia de implementacion Se recomienda que el proceso de planificacién de continuidad de los negocios incluya: a) identiicacion y acuerdo con respecto a todas las responsabilidades y procedimientos de conti- nuidad de los negocios; b) identificacion de la pérdida aceptable de informacién y servicios; ©) implementacién de los procedimientos para permitir la recuperaci6n y restauracién de las opera- ciones de negocio y disponibilidad de la informacién en las escalas de tiempo requeridas; se recomienda que se dedique especial atencién a la evaluacién de las dependencias externas temas de la actividad y a los contratos vigentes; d) procedimientos operacionales para seguir los pasos pendientes para completar la reconstruc- cién y la restauracién; 124IRAM-ISO/IEC 27002:2008 e) documentacién de procedimientos y procesos acordados; f) _apropiada instruccién al grupo de trabajo segun los procedimientos y los procesos acordados, incluyendo la gestion de la crisis; 9) pruebas y actualizaciones de los planes. Es conveniente que el proceso de planificacién se enfoque en los objetivos de negocio requeridos, por ejemplo: la restauracién de los servicios de comunicacién especificos con los alientes, en un pe- iodo de tiempo aceptable. Se recomienda que los servicios y los recursos que faciltan esto se encuentren identificados, incluyendo el personal, recursos no relacionados con el procesamiento de la informacién, asi como también la reposicién de informacién perdida (‘fallback’) para las instalacio- nes de procesamiento de informacién. Tales acuerdos de retroceso pueden incluir acuerdos con terceras partes en la forma de acuerdos reciprocos, o servicios de suscripcién comerciales. Es conveniente que los planes de continuidad de los negocios atiendan las vulnerabilidades de la or- ganizacién y por consiguiente pueden contener informacién sensible que necesite ser protegida en forma adecuada. Se recomienda que las copias de los planes de continuidad de los negocios se alma- cenen en una ubicacién remota, a suficiente distancia como para escapar de algtin dafio producido por un desastre en la sede principal. Es conveniente que la alta direccién asegure que las copias de los planes de continuidad de los negocios se encuentren actualizadas y protegidas con el mismo nivel de seguridad que se aplica en el sitio principal. Se recomienda que todo otro material necesario para eje- cutar los planes de continuidad de los negocios también se almacene en la ubicacién remota. Si se utlizan ubicaciones temporarias alternativas, es conveniente que el nivel de los controles de seguridad implementado en estas locaciones sea equivalente al del sitio principal Informacién adicional Se recomienda que se haga notar que los planes y las actividades de gestién de la crisis [ver 14.1.3 f)] pueden ser diferentes de la gestién de la continuidad de los negocios; es decir, puede ocurrir una crisis que puede ser atendida por los procedimientos de gestién normales. 14.1.4 Marco para la planificacién de la continuidad del negocio Control Se recomienda que se mantenga un marco Unico de planes para la continuidad del negocio, para ga- rantizar que todos los planes son consistentes, cumplir con los requerimientos de seguridad de la informacién de forma consistente, e identificar las prioridades de las pruebas y el mantenimiento, Guia de implementacién Se recomienda que cada plan de continuidad de los negocios describa al enfoque de la continuidad, or ejemplo: el enfoque para garantizar que la informacién o los sistemas de informacién estan dis- ponibles y seguros. Es conveniente también que cada plan especifique el plan de escalonamiento y las condiciones para su activacién, como también las personas responsables para la ejecucién de cada componente del plan. Cuando se identifican nuevos requerimientos, se recomienda que cual- quier procedimiento de emergencia existente, por ejemplo los planes de evacuacién o los acuerdos de retroceso, se corrijan segtin corresponda. Es conveniente que los procedimientos estén incluidos dentro del programa de gestién de cambios de la organizacién para garantizar que los temas de con- tinuidad de los negocios se lleven siempre en forma apropiada. Es conveniente que cada plan tenga un propietario especifico. Se recomienda que los procedimien- tos de emergencia, los planes de retroceso manual y los planes de reanudacién se encuentren entre 122IRAM-ISO/IEC 27002:2008 las responsabilidades de los propietarios de los recursos 0 procesos de negocio pertinentes. Los acuerdos de retroceso para servicios tecnicos alternativos, como instalaciones de comunicaciones 0 de procesamiento de la informacién, normalmente se cuentan entre las responsabilidades de los pro- veedores de servicios. Es conveniente que el marco de planificacién de la continuidad de los negocios alcance los requeri- mientos de seguridad de la informacién identificados y tenga en cuenta lo siguiente: a) las condiciones para activar los planes que describen el proceso @ seguir (por ejemplo: como evaluar la situacién, qué personas estaran involucradas) antes de ponerlos en marcha; b) procedimientos de emergencia que describan las acciones a emprender una vez ocurrido un incidente que ponga en peligro las operaciones de la empresa y/o la vida humana; c)_procedimientos de retroceso que describan las acciones a emprender para el traslado de acti- vidades esenciales de la empresa o de servicios de apoyo a ubicaciones transitorias alternativas, y para el restablecimiento de los procesos de negocio en los plazos requeridos; d) procedimientos operacionales temporarios para seguir la finalizacion de la reconstruccién y la restauracién; e) procedimientos de reanudacién que describan las acciones a emprender para restablecer las, ‘operaciones normales de la empresa; f) un cronograma de mantenimiento que especifique cémo y cuando seré probado el plan, y el proceso para el mantenimiento de éste; 9) actividades de concientizacion, educacién e instruccién que estén disefiadas para crear el en- tendimiento de los procesos de continuidad del negocio y garantizar que los procesos sigan siendo efectivos; h) las responsabilidades de las personas que describen quién es el responsable de la ejecucion de cada componente del plan. Se recomienda que se mencionen altemnativas cuando corresponda; i) los activos y los recursos criticos que se necesitan para ejecutar los procedimientos de emer- gencia, de fallas y de reanudacién. 14.1.5 Pruebas, mantenimiento y reevaluacién de los planes de continuidad del negocio Controt ‘Se recomienda que los planes de continuidad de! negocio se prueben y actualicen periédicamente para garantizar que se encuentran al dia y continuan siendo efectivos. Guia de implementacion Es conveniente que las pruebas de los planes de continuidad del negocio garanticen que todos los miembros del equipo de recuperacién estén concientes de los planes y de sus responsabilidades pa- ra la continuidad de los negocios y la seguridad de la informacion y conozcan sus roles cuando se invoque un plan. Se recomienda que el cronograma de pruebas para los planes de continuidad del negocio indiquen como y cuando es conveniente que se pruebe cada elemento del plan. Se recomienda probar con frecuencia cada uno de los componentes del plan. 123IRAM-ISO/IEC 27002:2008 Es conveniente que se ullcen diversas técnicas para garantizar que los planes funcionardn en la vi- da real. Se recomienda que éstas incluyan: a) pruebas de discusion de varios escenarios (discutiendo medidas para la recuperacién del ne- gocio utilizando ejemplos de interrupciones); b) _simulaciones (especialmente para entrenar al personal en el desempefio de sus roles de ges- tion posterior a incidentes o crisis); c) pruebas de recuperacién técnica (garantizando que los sistemas de informacién puedan ser efectivamente restablecidos); 4) pruebas de recuperacién en un sitio alternativo (ejecutando procesos de negocios en paralelo ‘con operaciones de recuperacién fuera del sitio principal); e) pruebas de instalaciones y servicios de proveedores (garantizando que los productos y servi- Cios provistos externamente cumplan con el compromiso contraido); f)ensayos completos (que prueben que la organizacién, el personal, el equipamiento, tas instala- ciones y los procesos pueden afrontar las interrupciones).. Estas técnicas pueden ser utilizadas por cualquier organizacién. Se recomienda que se apliquen de forma que se correspondan con el plan de recuperacién especifico. Es conveniente que se lleve re- gistro de los resultados de las pruebas y que se lleven a cabo acciones para mejorar los planes, cuando sea necesario. Se recomienda que se asigne la responsabilidad por las revisiones periddicas de cada uno de los planes de continuidad del negocio. Es conveniente que la identificacién de cambios en los acuerdos de negocio atin no reflejadas en los planes de continuidad sea seguida por una adecuada actualiza- cién del plan. Se recomienda que este proceso formal de control de cambios garantice que se distribuyan los planes actualizados y que se imponga el cumpiimiento de éstos mediante revisiones periédicas de todo el plan. Casos en los que se recomienda que se considere la actualizacién de los planes de continuidad del negocio son, por ejemplo, la adquisicién de nuevo equipamiento, o la actualizacién de los sistemas operacionales y los cambios de: a) personal; b) direcciones o nimeros telefénicos; ©) estrategia de negocios; 4) _ubicacién, instalaciones y recursos; fe) legislacién; 1) contratistas, proveedores y clientes clave; 9) procesos, 0 procesos nuevos/eliminados; h) _riesgos (operacionales y financieros). 124IRAM-ISO/IEC 27002:2008 15 CUMPLIMIENTO 15.1. Cumplimiento de requerimientos legales Objetivo: Impedir infracciones y violaciones de cualquier obligacién legal, regiamentaria, reguladora © contractual, y de cualquier requerimiento de seguridad. El disefo, operacién, uso y gestion de los sistemas de informacion pueden estar sujetos a requeri- mientos de seguridad obligatorios, normativos y contractuales. Se recomienda que se busque asesoramiento sobre requerimientos legales especificos por parte de los asesores juridicos de la organizacién, 0 de abogados convenientemente calificados. Los reque- rimientos legales varian segiin el pais y pueden variar en relacién a la informacién que se genera en un pais y se transmite a otro (por ejemplo: flujo de datos a través de fronteras). 15.1.1 Identificacién de la legislacién aplicable Control! Se recomienda que todos los requerimientos legales, reguladores y contractuales pertinentes, asi como el enfoque de la organizacion para cumplir con estos requerimientos, estén definidos y docu- mentados y se mantengan actualizados para cada sistema de informacion y para la organizacién Guia de implementacién Es conveniente que los controles especificos y las responsabilidades individuales para cumplir con estos requerimientos estén definidos y documentados en forma similar. 15.1.2 Derechos de propiedad intelectual (DP!) Control Es conveniente que se implementen los procedimientos apropiados para garantizar el cumplimiento con los requerimientos legislativos, regulatorios y contractuales sobre el uso del material sobre el cual puede existir un derecho de propiedad intelectual y sobre el uso de productos de software pro- pietarios. Guia de implementacién Se recomienda que para proteger cualquier material que pueda considerarse como propiedad intelec- tual, se consideren las directrices siguientes: a) publicacién de una politica de cumplimiento del derecho de propiedad intelectual que defina el Uso legal de productos de informacion y software; b) compra de software solamente a través de fuentes conocidas y con reputacion, para garantizar que no se viole el derecho de propiedad intelectual ("copyright"); c)_ mantenimiento de la concientizacién respecto de las politicas para la proteccién de los derechos de propiedad intelectual y notificacién de la determinacién de tomar acciones disciplinarias contra el personal que incurra en el incumplimiento de elias; 1d) mantenimiento de adecuados de registros de activos, ¢ identificacién de todos los activos con requerimientos de proteccién de los derechos de propiedad intelectual; 125IRAM-ISO/IEC 27002:2008 ) mantenimiento de prueba y evidencia de la propiedad de las licencias, discos maestros, ma- nuales, etc.; )_ implementacién de controles para garantizar que no se exceda el maximo numero de usuarios permitidos; 9) realizacion de verificaciones de que se instalen solamente software y licencias de productos autorizados; h) _establecimiento de una politica para el mantenimiento de las condiciones apropiadas de la licencia; i) establecimiento de una politica para la disposicién o transferencia de software a otros; |) utllzacion de herramientas de auditoria apropiadas; k)_cumplimiento de los términos y condiciones con respecto al software e informacion obtenidos de redes piblicas; 1) impedir duplicaciones 0 conversiones a otro formato o extraccién de grabados comerciales (pe- liculas, audio) u otros que no estén permitidos por derechos de copiado; m) impedir la copia total o parcial de libros, a permitidos por los derechos de copiado. los, reportes, u otros documentos, mas que los Informacién adicional Los derechos de propiedad intelectual incluyen software o documentos con derechos de copiado, de- rechos de disefio, marcas registradas, patentes, y licencias de cédigo fuente. Los productos de software propietarios se proven normalmente bajo un acuerdo de licencia que es- pecifica los términos y las condiciones de licencia, por ejemplo, la limitacién del uso de los productos a maquinas especificas 0 la posibilidad del copiado solamente para la creacién de copias de res- guardo. La situacién de los derechos de propiedad intelectual (DP!) del software desarrollado por la organizacion es necesario que sea clarificada con el equipo de trabajo. Los requerimientos legisiativos, regulatorios, y contractuales pueden conducir a restricciones en el copiado del material con restricciones de copiado. En particular, se puede requerir que sélo se use el material que es desarrollado por la organizacién, o que pueda usarse bajo licencia o suministrado por el desarrollador. Las violaciones de derecho de copiado pueden conducir a acciones legales, que pueden involucrar procedimientos delictivos. 15.1.3 Proteccién de los registros de la organizacion Control Es conveniente que los registros importantes estén protegidos contra pérdida, destruccién y falsifica- cién, en concordancia con los requerimientos legales, regulatorios, contractuales y comerciales. Guia de implementacién Se recomienda que los registros se clasifiquen en diferentes tipos, por ejemplo, registros contables, registros de base de datos, registros de transacciones, registros de auditoria y procedimientos opera~ tivos, cada uno de ellos detallando los periodos de retencién y el tipo de medios de almacenamiento, por ejemplo: papel, microfichas, medios magnéticos u épticos. Se recomienda que cualquier material de clave criptogréfica asociadas con archivos cifrados o firmas digitales (ver 12.3), se guarden tam- bién para permitir el descifrado de los registros durante el tiempo que se mantengan los registros. 126IRAM-ISO/IEC 27002:2008 Se recomienda considerar la posibilidad de deterioro de los medios utilizados para el almacenamien- to de los registros. Se recomienda que los procedimientos de almacenamiento y manipulacién se implementen de acuerdo con las recomendaciones del fabricante. Para el almacenamiento a largo plazo, es conveniente que se considere el uso de papel y microfichas. Cuando se seleccionen medios de almacenamiento electrénicos, se recomienda que se incluyan pro- cedimientos para garantizar la capacidad de acceso a los datos (tanto legibilidad de formato como del medio) durante todo el periodo de retencién, a fin de salvaguardarlos contra eventuales pérdidas ocasionadas por futuros cambios tecnolégicos. Se recomienda que se seleccionen los sistemas de almacenamiento de datos de modo tal que fos datos requeridos se recuperen en un marco de tiempo y formato aceptable, dependiendo de los re- querimientos que se deben cumplir. Es conveniente que el sistema de almacenamiento y manipulacién garantice una clara identificacion de los registros y de su periodo de retencién definido por leyes 0 normas nacionales o regionales, si es aplicable. Se recomienda que este sistema permita una adecuada destruccién de los registros una vez transcurrido dicho periodo, si ya no resultan necesarios para la organizacion. ‘A fin cumplir con estas obligaciones, es conveniente que dentro de la organizacién se consideren los pasos siguientes: a) que se emitan directrices para la retencién, almacenamiento, manipulacién y eliminaci6n de re- gistros e informacién; b) que se prepare un cronograma de retenci6n, identificando los registros, y el periodo durante el cual deben ser retenidos; ) que se mantenga un inventario de fuentes de informacién clave; d) que se implementen controles adecuados para proteger los registros y la informacion contra pérdida, destruccion y falsificacién. Informacién adicional Puede ser necesario retener algunos registros en forma segura para cumplir con los requerimientos legales, regulatorios 0 contractuales, asi como también para dar soporte a las actividades comercia- les esenciales. Los ejemplos incluyen registros que pueden ser requeridos como evidencia de que una organizacién opera dentro de las regias legales o regulatorias, para garantizar una defensa ade- cuada en contra de potenciales acciones civiles 0 penales, o para confirmar el estado financier de una organizacién con respecto a los accionistas, partes extemas y auditores. El periodo de tiempo y el contenido de los datos para la retencién de la informacion pueden estar definidos por leyes 0 regu- laciones nacionales. Mayor informacién acerca de Ia gestion de los registros organizacionales puede encontrarse en la ISO 15489-1 15.1.4 Protecci6n de los datos y privacidad de la informacién personal Control Es conveniente que la proteccién y privacidad de los datos esté garantizada seguin se requiera en las legislaciones y regulaciones relevantes, y si es aplicable, en las clausulas contractuales, 127IRAM-ISO/IEC 27002: 008 Guia de implementacién Se recomienda que se desarrolle e implemente una politica de proteccion y privacidad de los datos organizacionales. Es conveniente que esta politica se comunique a todas las personas involucradas en el procesamiento de la informacién personal. EI cumpiimiento con esta politica y con todas las leyes y regulaciones de proteccion de los datos co- rrespondientes requieren una estructura y control de gestion apropiados. Con frecuencia esto se logra con el compromiso de una persona responsable, tal como un oficial de proteccién de los datos, quien proveerd las directrices a los gerentes, usuarios, y proveedores de servicios acerca de sus responsabilidades individuales y los procedimientos especificos que se recomienda que se lleven a cabo. Es conveniente que la responsabilidad para el manejo de la informacion personal y el asegu- ramiento de la concientizacién sobre los principios de la proteccién de los datos se manejen en concordancia con las regulaciones y leyes correspondientes. Se recomienda que se implementen las medidas técnicas y organizacionales apropiadas para proteger la informacién personal. Informaci6n adicional Varios paises han introducido leyes que dan lugar a controles acerca de la recoleccion, procesamiento y transmisién de datos personales (generalmente informacién de personas vivas quienes pueden ser identificados a través de dicha informacién). Dependiendo de las leyes nacionales respectivas, tales controles pueden imponer obligaciones en aquellas personas que recolectan, procesan, y diseminan in- formacion personal, y pueden restringir la capacidad de transferir esos datos a otros paises. 15.1.5 Prevencién contra el mal uso de las instalaciones de procesamiento de la informacion Control Es conveniente disuadir a los usuarios de utilizar las instalaciones de procesamiento de la informa- ci6n para propésitos no autorizados. Guia de implementacién Se recomienda que la gerencia autorice el uso de as instalaciones de procesamiento de la informa- cién. Se recomienda que cualquier uso de estos recursos sin la autorizacién de la gerencia (ver 6.1.4), 0 para cualquier propésito no autorizado, se considere como uso indebido de las instalacio- nes. Si se identifica cualquier actividad no autorizada mediante seguimiento y control u otros medios, se recomienda que esta actividad se lleve a la atencién del gerente interesado para que se tomen las acciones disciplinarias 0 legales que correspondan. Es conveniente tener asesoramiento legal antes de la implementacién de los procedimientos de se- guimiento y control. Se recomienda que todos los usuarios tomen conciencia del alcance preciso de su permiso de acce- s0 y del seguimiento establecido para detectar el uso no autorizado. Esto puede lograrse otorgando a los usuarios una autorizacién escrita, quedando una copia (firmada por el usuario) retenida de forma ‘segura por la organizacién. Es conveniente que se dé aviso a los empleados de una organizacién, contratistas y usuarios de terceras partes de que ningun acceso esta permitido, excepto que tengan autorizacién Al inicio de sesién, se recomienda que se presente un mensaje de alerta para indicar que los recur- sos de procesamiento de la informacién a los que ingresa son propiedad de Ia organizacién y que no se permite el acceso no autorizado. El usuario tiene que aceptar y reaccionar adecuadamente al mensaje en la pantalla para continuar con el proceso de inicio de sesion (ver 11.5.1) 128IRAM-ISO/IEC 27002:2008 Informacién adicional Las instalaciones de procesamiento de la informacién apuntan primariamente 0 exclusivamente a los, propésitos de la actividad La deteccién de intrusos, la inspeccién de contenido, y otras herramientas de seguimiento pueden ayudar a detectar y prevenir ef mal uso de las instalaciones de procesamiento de la informacion. Muchos paises tienen leyes para protegerse en contra del mal uso de las computadoras. Puede ser Una infraccién criminal usar una computadora para propésitos no autorizados. La legalidad del seguimiento de! uso de los recursos mencionados varia segiin el pais y puede re- querir que la gerencia advierta a los empleados de dichas actividades ylo que se obtenga el consentimiento de los mismos. Cuando se ingresa a un sistema que es de acceso piiblico (por ejem- plo: un servidor de Internet publica) y esta sujeto a seguimiento de seguridad, se recomienda que se muestre un mensaje. 15.1.6 Regulaci6n de los controles criptograficos Control! Se recomienda que los controles criptograficos se utilicen cumpliendo con todos los acuerdos, leyes, y fegulaciones vigentes. Guia de implementacién Es conveniente que para cumplir con los acuerdos, leyes, y regulaciones correspondientes, se consi- deren los puntos siguientes: a) restricolones sobre la importacién y/o exportacién del hardware y el software de computadoras para el desemperio de funciones criptograticas; b) _restricciones sobre la importacién y/o exportacién del hardware y el software de computadoras, que esta disefiado para tener funciones criptograficas agregadas; ©) _restricciones sobre el uso de la encriptacion; d) métodos obligatorios o discretos de acceso de las autoridades de los paises a la informacién ci- frada por el hardware o el software para proveer confidencialidad al contenido. Se recomienda que se busque asesoramiento legal para asegurar el cumpiimiento con las leyes y re- gulaciones nacionales. Antes de que la informacién cifrada 0 los controles criptograficos pasen a otros paises, es conveniente que también se busque asesoramiento legal. 15,2 Cumplimiento con las politicas y normas de seguridad, y el cumplimiento técnico Objetivo: Garantizar el cumplimiento de los sistemas con las politicas y normas de seguridad de la organizacion. Se recomienda que se revisen los sistemas de seguridad de la informacién periédicamente. Es conveniente que tales revisiones se realicen basadas en las politicas de seguridad apropiadas, y que las plataformas técnicas y los sistemas de informacion se auditen para asegurar el cumplimiento con las normas de implementacion de seguridad aplicables y los controles de seguridad documentados. 129IRAM-ISO/IEC 27002:2008 15.2.1 Cumplimiento de las politicas y normas de seguridad Controt Se recomienda que los responsables garanticen que se lleven a cabo correctamente todos los pro- cedimientos de seguridad dentro de su area de responsabilidad para alcanzar el cumplimiento con las politicas y normas de seguridad. Guia de implementacion Es conveniente que los gerentes revisen periédicamente el cumplimiento del procesamiento de la in- formacién que esta dentro de su area de responsabilidad, con las politicas y normas de seguridad y cualquier otro requerimiento de seguridad adecuados. Si se encuentra cualquier no cumplimiento como resultado de una revisién, se recomienda que los gerentes: a) determinen las causas del no cumplimiento; b)_evalien la necesidad de realizar acciones para garantizar que no ocurra el no cumplimiento; c) _determinen e implementen las acciones correctivas apropiadas; @) _revisen las acciones correctivas tomadas. Se recomienda que se lleve registro de los resultados de las revisiones y las acciones correctivas lle- vadas a cabo por los administradores y se mantengan estos registros. Es conveniente que los administradores reporten los resultados a las personas que llevan a cabo las revisiones independien- tes (ver 6.1.8), cuando se lleve a cabo la revision independiente en el area de su responsabilidad. Informacién adicional El seguimiento operacional del uso del sistema esta cubierto en el apartado 10.10. 15.2.2 Verificacién del cumplimiento técnico Controt Se recomienda que se verifiquen periédicamente los sistemas de informacién para garantizar que cumplan con las normas de implementacién de seguridad, Guia de implementacién Es conveniente que la verificacién del cumplimiento técnico se realice, ya sea manualmente (sopor- tada por herramientas de software adecuadas, de ser necesario) por un ingeniero de sistemas con experiencia, y/o con la asistencia de herramientas automaticas, las cuales generan un reporte técnico para la subsiguiente interpretacién realizada por un especialista técnico. Si se usan pruebas de penetracién o evaluacién de las vulnerabilidades, se recomienda que se tenga cuidado debido a que tales actividades pueden conducir a un compromiso de la seguridad del siste- ma. Es conveniente que tales pruebas estén planeadas, documentadas y sean repetibles. Es conveniente que cualquier verificacion técnica de cumplimiento sea llevada a cabo solo por una autoridad competente, personas autorizadas, o bajo la supervision de tales personas. 130IRAM-ISO/IEC 27002:2008 Informacién adicional LLa verificacién de cumplimiento técnico comprende examinar los sistemas operacionales para asegu- rar que los controles de software y hardware han sido implementados en forma correcta. Este tipo de verificacion de cumplimiento requiere del conocimiento técnico de especialistas. La verificacién del cumplimiento también abarca, por ejemplo, las evaluaciones de penetracién y las evaluaciones de vulnerabilidades, las cuales podrian llevarse a cabo por especialistas independien- tes con experiencia, especialmente contratados para este propésito. Esto puede ser de utilidad para detectar vulnerabilidades en el sistema y para verificar qué tan efectivos son los controles para la prevencién de los accesos no autorizados debidos a estas vulnerabilidades. Las pruebas de penetracién y las evaluaciones de vulnerabilidades proveen una fotografia de un sis- tema en un estado especifico en un tiempo dado. La fotografia esté limitada a aquellas porciones del sistema realmente probadas durante el intento de penetracion. Las pruebas de penetracién y las eva- luaciones de vulnerabilidades no son un sustituto de las evaluaciones de riesgo. 15.3 Consideraciones de auditorias de sistemas de informacion Objetivo: Maximizar la efectividad y minimizar la interferencia hacia y desde el proceso de auditoria del sistema de informacion. Es conveniente que existan controles que protejan los sistemas operacionales y las herramientas de auditoria durante el transcurso de las auditorias de sistemas de informacion. Asimismo, se requiere una proteccién adecuada para salvaguardar la integridad y evitar el uso in- adecuado de las herramientas de auditoria. 15.3.1 Controles de auditoria del sistema de informacion Control ‘Se recomienda que los requerimientos y las actividades de auditoria que involucran verificaciones de los sistemas operacionales se planifiquen y acuerden cuidadosamente a fin de minimizar el riesgo de interrupcién de los procesos de negocio. Guia de implementacion Es conveniente que se contemplen las directrices siguientes: a) que los requerimientos de auditoria se acuerden con la gerencia que corresponda; b) que se acuerde y controle el alcance de las verificaciones; c) que las verificaciones se encuentren limitadas a un acceso de sélo lectura, al software y a los, datos; d) que cualquier acceso que no sea de sélo lectura solamente se permita a copias aisladas de ar- chivos del sistema, las cuales es conveniente que se eliminen una vez finalizada la auditoria, o se le otorgue proteccién adecuada si existe una obligacién de mantener dichos archivos como requerimientos de documentacién de auditoria; ) que se identifiquen claramente y se dispongan los recursos para llevar a cabo las verificaciones; f) que se identifiquen y acuerden los requerimientos de procesamiento especial o adicional, 131IRAM-ISO/IEC 27002:2008 9) que se sigan y controlen todos los accesos, y se lleve registro de ellos para producir un sende- ro de referencia; se recomienda que se considere el uso de referencias de tiempo para los sistemas 0 datos criticos; h) que se documenten todos los procedimientos, requerimientos y responsabilidades; i) que las personas que leven a cabo la auditoria sean independientes de las actividades a auditer. 15.3.2 Proteccién de las herramientas de auditoria de los sistemas de informacién Control Es conveniente que se proteja el acceso a las herramientas de auditoria de los sistemas de informa- cién a fin de evitar cualquier mal uso 0 el compromiso de éstas. Guia de implementacién Se recomienda que las herramientas de auditoria de sistemas de informacién, por ejemplo: archivos de datos o software, estén separadas de los sistemas operacionales y en desarrollo y que no se mantengan en bibliotecas de cintas o en areas de usuarios, a menos que se les otorgue un nivel adecuado de proteccién adicional. Informacién adicional Si las terceras partes estén involucradas en las auditorias, esto podria ser un riesgo de mal uso de las herramientas de auditoria por estas terceras partes, y la informacién podria ser accedida por es- tas terceras partes. Se pueden considerar controles como los indicados en 6.2.1 (para la evaluacién de los riesgos) y 9.1.2 (para la restriccién del acceso fisico) para manejar estos riesgos y cualquier consecuencia, tales como el cambio inmediato de las contrasefias entregadas a los auditores. 132IRAM-ISO/IEC 27002:2008 Anexo A (Informativo) Bibliografia de la ISO/IEC 27002:2005 Iso - IEC - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION INTERNATIONAL ELECTROTECHNICAL COMMISSION ISO/IEC Guide 2:1996 - Standardization and related activities - General vocabulary. ISO/IEC Guide 73:2002 - Risk management - Vocabulary - Guidelines for use in standards. ISO/IEC 13335-1:2004 - Information technology - Security techniques - Management of information and communications technology security - Part 1: Concepts and models for information and communications technology security management, ISO/IEC TR 13335-3:1998 - Information technology - Guidelines for the Management of IT ‘Security - Part 3: Techniques for the management of IT Security. ISO/IEC 13888-1:1997 - Information technology - Security techniques - Non-repudiation - Part 1: General. ISO/IEC 11770-1:1996 - Information technology - Seourity techniques - Key management - Part 1: Framework. ISO/IEC 9796-2:2002 - Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms ISO/IEC 9796-3:2000 - Information technology - Security techniques - Digital signature schemes giving message recovery - Part 3: Discrete logarithm based mechanisms. ISO/IEC 14888-1:1998 - Information technology - Security techniques - Digital signatures with appendix - Part 1: General. ISONIEC 15408-1:1999 - Information technology - Security techniques - Evaluation Criteria for IT seourity - Part 1: Introduction and general model. ISO/IEC 14516:2002 - Information technology - Security techniques - Guidelines for the use and management of Trusted Third Party services. ISO 15489-1:2001 - Information and documentation - Records management - Part 1: General. ISO 10007:2003 - Quality management systems - Guidelines for configuration management. ISO/IEC 12207:1995 - Information technology - Software life cycle processes. ISO 19011:2002 - Guidelines for quality and Jor environmental management systems auditing. ‘OECD Guidelines for the Security of Information Systems and Networks: ‘Towards a Culture of Security’, 2002 OECD Guidelines for Cryptography Policy, 1997. IEEE P1363-2000 - Standard Specifications for Public-Key Cryptography. ISO/IEC 18028-4 - Information technology - Security techniques - IT Network security - Part 4: Securing remote access. ISO/IEC TR 18044 - Information technology - Security techniques - Information security incident. 133IRAM-ISO/IEC 27002:2008 Anexo B - IRAM {Informativo) Bibliografia IRAM En el estudio de esta norma se ha tenido en cuenta la bibliografia siguiente: ISO- INTERNATIONAL ORGANIZATION FOR STANDARDIZATION IEC - INTERNATIONAL ELECTROTECHNICAL COMMISSION ISO/IEC 27002:2005 - information technology - Security techniques - Code of practice for information security management. 134IRAM-ISO/IEC 27002:2008 Anexo C -IRAM (Informative) Integrantes de los organismos de estu El estudio de esta norma ha estado a cargo de los organismos respectivos, integrados en la forma siguiente: ‘Subcomité de Seguridad en tecnologia de la informacién Integrante Representa a: Lic. Alberto David AIRALA MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS Sr. Gustavo ALDEGANI CONSULTOR INDEPENDIENTE Ing. Eduardo Antonio ALONIO BOLSA DE COMERCIO DE BS. AS Sra. Gladis Alicia BARCA CISA Lic. Juan de Dios BEL ADACSI ~ ASOC. DE AUDITORIA Y CTROL. DE SIST. DE LA INFORMACION Sr. Ratil Eduardo CABRERA CONSULTOR INDEPENDIENTE Ing. Carlos A. CACICI QFD CONSULTORES CQE Jorge M. CANALE CITEFA - ISTITUTO DE INVESTIGACIONES CIENTIFICAS Y TECNICAS PARA LA DEFENSA Ing. Paul CASTRO WERNER INVITADO ESPECIAL Ing. Jorge Luis CEBALLOS CONSULTORA EMPRENDER Sr. Ricardo CIUFFA ‘AySA - AGUA Y SANEAMIENTO ARGENTINO Lic. Adriana DE ROSE CONSULTOR INDEPENDIENTE Sr. Guillermo Eduardo DIAZ ‘SECCURACY Ing. Maria Laura DUEK CESS! - CAMARA ARGENTINA DE EMPRESAS DE SOFTWARE Y SERVICIOS INFORMATICOS, Ing. Norberto ESARTE GATECH S.R.L Sr. Jorge ETEROVIC CAJA DE VALORES S. A. St. Gabriel GORDON MICROSOFT DE ARGENTINA S.A. Ing. Gustavo GUINAZU BANCO DE LA PROVINCIA DE BS. AS. Lic. Fernando LORENCES METROGAS S. A. Sra. Teresita Maria MICHETTI RED LINK S.A. Ing. Liliana Rosa MIRA LMIRA CONSULTORES Lic. Gisella MORODER KHU TECHNOLOGIES S.A. Sr. Andrew OTEIZA TELEFONICA DE ARGENTINA S.A. Sr. Marcos PASSARELLO INVITADO ESPECIAL Ing. Osvaldo PEREZ IEEE ARGENTINA Sr. Mauro PINTOS TELECOM ARGENTINA S.A, Sr. Femando RADICCHI BNA - BANCO DE LA NACION ARGENTINA Ing. Pablo Miguel ROMANOS MINISTERIO DE JUSTICIA Y DERECHOS HUMANOS Sr. Gabriel SANCHEZ BARBEITO —-ADACS - ASOC. DE AUDITORIA Y CTROL. DE SIST. DE LA INFORMACION Dr. Rodolfo STALANICH FACPCE - FEDERACION ARGENTINA DE CONSEJOS PROF. DE CS. ECONOMICAS, Sr. Diego TAICH PRICE WATERHOUSE COOPERS Sr. Mariano UCHA TELEFONICA DE ARGENTINA 135IRAM-ISO/IEC 27002:2008 Integrante Dr. Juan Carlos ZAMPATTI MAIDA Sr. Ariel ZAREMBER Mg. Paula ANGELER| Lic. Marta RAINONI de BARBIERI Lic. Pedro Claudio COSTA Lic. Domingo DONADELLO Ing. Sergio Fabian ROJAS. Comité General de Normas (C.G.N.) Integrante Dr. José M. CARACUEL Lic. Alberto CERIN Ing. Ramiro FERNANDEZ Dr. Federico GUITAR Ing. Jorge KOSTIC Ing. Jorge MANGOSIO 136 Representa a: FACPCE ~ FEDERACION ARGENTINA DE CONSEJOS PROF. DE CS. ECONOMICAS TELE! IRAM IRAM IRAM IRAM IRAM FONICA DE ARGENTINA S.A. Integrante Too. Ing Ing Sr. Ing Hugo D. MARCH ‘Samuel MARDYKS Tulio PALACIOS Angel TESTORELLI Raul DELLA PORTAIRAM-ISO/IEC 27002:2008IRAM-ISO/IEC 27002:2008IRAM-ISO/IEC 27002:2008IRAM-ISO/IEC 27002:2008 Ics 35,040 * CNA 00.00 + Corresponde a Casicaion Nacional de Abastecilento asignada pr el Serio Nacional de Calsogacn dl Minisode Dafa