La Comisión Nacional de Valores (CNV) de Argentina se ha convertido en el último objetivo de un sofisticado ataque informático que ha dejado sus operaciones en una situación terminal.
El miércoles 7 de junio, el organismo detectó la presencia de un código malicioso del tipo ransomware conocido como “Medusa”, que se infiltró en los equipos informáticos de la CNV y provocó la desconexión de sus plataformas.
El ataque, llevado a cabo por actores desconocidos, demuestra una vez más la creciente sofisticación y audacia de los ciberdelincuentes en su búsqueda de objetivos de alto perfil. La CNV, encargada de regular y supervisar el mercado de valores argentino, ha respondido rápidamente al incidente y ha tomado medidas para contener y mitigar los daños causados.
El ransomware “Medusa” es conocido en la comunidad de seguridad cibernética por su capacidad para tomar el control de sistemas informáticos y cifrar los archivos almacenados en ellos, exigiendo un rescate para su desbloqueo.
En este caso, los atacantes exigieron un rescate de 500,000 dólares estadounidenses a cambio de no filtrar aproximadamente 1.5 terabytes de información confidencial de la CNV.
A pesar del impacto inicial del ataque, las autoridades de la CNV dicen haber actuado con prontitud para aislar y controlar la situación. SItuación que nos genera muchas dudas.
Utilizando medidas de seguridad avanzadas y un equipo especializado en respuesta a incidentes, lograron contener el avance del ransomware y evitar una mayor propagación dentro de su infraestructura.
Como resultado de estas acciones, las plataformas en línea de la CNV permanecen temporalmente fuera de línea mientras se realizan las investigaciones y las labores de limpieza para garantizar la integridad de los sistemas.
Mientras tanto, el personal de la CNV continúa trabajando arduamente para restablecer completamente las operaciones y minimizar cualquier impacto en los participantes del mercado financiero.
Fuentes cercanas al caso han confirmado la gravedad del incidente bajo condición de anonimato, destacando la complejidad del ataque y la urgencia de fortalecer aún más las medidas de seguridad en todas las entidades financieras del país.
Las autoridades de la CNV están cooperando estrechamente con las fuerzas de seguridad y expertos en ciberseguridad para identificar a los responsables del ataque y garantizar que se tomen las acciones legales correspondientes. Además, se ha instado a otras entidades financieras locales a estar en alerta y fortalecer sus defensas ante posibles amenazas similares.
Este incidente subraya la importancia crítica de la ciberseguridad en un mundo cada vez más interconectado. Las organizaciones tanto públicas como privadas deben invertir en tecnologías y recursos especializados para proteger sus sistemas y datos contra las crecientes amenazas cibernéticas.
A medida que evolucionan las tácticas de los delincuentes cibernéticos, se vuelve fundamental para las entidades financieras y organizaciones en general mantenerse a la vanguardia de las mejores prácticas de ciberseguridad. Esto implica implementar medidas proactivas, como auditorías regulares de seguridad, pruebas de penetración y capacitación constante del personal en la identificación de amenazas.
Además, es crucial contar con planes de respuesta a incidentes bien definidos y actualizados.
Estos planes deben incluir procedimientos claros para el aislamiento y contención de ataques, así como la restauración de sistemas y la comunicación efectiva con las partes involucradas, incluidos los clientes y las autoridades reguladoras.
A nivel gubernamental, este incidente resalta la necesidad de una mayor cooperación y coordinación entre las agencias encargadas de la seguridad cibernética y las instituciones financieras.
La colaboración activa, el intercambio de información y la implementación de medidas de seguridad estandarizadas pueden ayudar a mitigar los riesgos y fortalecer la resiliencia del sector financiero frente a las amenazas digitales.
En última instancia, la protección contra ataques de ransomware y otras formas de ciberdelincuencia requiere un enfoque integral que combine tecnología avanzada, capacitación del personal, buenas prácticas de seguridad y una cultura de ciberseguridad sólida en toda la organización.
Solo a través de esfuerzos colectivos y una vigilancia constante se podrá enfrentar de manera efectiva el panorama en constante evolución de la ciberdelincuencia y proteger los activos críticos de las instituciones financieras y la confianza de sus clientes.
Cuál es la importancia de seguir las normativas de seguridad en una entidad como la Comisión Nacional de Valores?
El cumplimiento de las normativas de seguridad cibernética en una entidad como la Comisión Nacional de Valores (CNV) es de vital importancia por varias razones:
- Protección de datos confidenciales: La CNV maneja y almacena una gran cantidad de datos sensibles y confidenciales relacionados con el mercado financiero, las instituciones y los inversores. Cumplir con las normativas de seguridad ayuda a garantizar la integridad y confidencialidad de estos datos, protegiéndolos de accesos no autorizados y posibles filtraciones.
- Mantener la confianza del público: La CNV es responsable de regular y supervisar el mercado de valores, lo que implica mantener la confianza del público y los inversores en la integridad y seguridad del sistema financiero. El incumplimiento de las normativas de seguridad podría socavar esta confianza y tener un impacto negativo en la reputación de la CNV y en la percepción de la seguridad del mercado.
- Prevenir ataques y ciberdelincuencia: El cumplimiento de las normativas de seguridad ayuda a mitigar el riesgo de ataques cibernéticos, como el ransomware, las violaciones de datos y otras formas de ciberdelincuencia. Al implementar controles de seguridad adecuados, se reducen las vulnerabilidades y se dificulta el acceso no autorizado a los sistemas de la CNV.
- Cumplimiento legal y regulatorio: Las entidades financieras, incluida la CNV, están sujetas a una serie de leyes y regulaciones relacionadas con la protección de datos y la seguridad cibernética. Cumplir con estas normativas es un requisito legal y regulatorio, y el incumplimiento puede tener consecuencias legales y sanciones financieras significativas.
- Resiliencia y continuidad del negocio: Las normativas de seguridad también se enfocan en la planificación de la continuidad del negocio y la capacidad de respuesta ante incidentes de seguridad. Establecer medidas de seguridad adecuadas y contar con planes de respuesta a incidentes ayuda a garantizar la resiliencia de la CNV frente a posibles interrupciones y permite una recuperación rápida y efectiva en caso de un incidente de seguridad.
Seguir las normativas de seguridad en una entidad como la CNV es fundamental para proteger la confidencialidad, integridad y disponibilidad de los datos, mantener la confianza del público y los inversores, prevenir ataques cibernéticos y cumplir con las obligaciones legales y regulatorias. Además, contribuye a la resiliencia y continuidad del negocio frente a posibles amenazas y garantiza la estabilidad del mercado financiero.
Si un organismo como la CNV mantiene todas sus claves en formato digital en el mismo ambientes en el que procesa sus operaciones ¿Cómo deberían valorar la gestión operativa a nivel tecnológico y cuál sería su nivel de respeto hacia los inversores que les confían datos críticos?
Si un organismo como la CNV mantiene todas sus claves en formato digital en el mismo ambiente en el que procesa sus operaciones, esto plantea preocupaciones significativas desde una perspectiva de gestión operativa y seguridad tecnológica. Al evaluar esta situación, es importante considerar los siguientes aspectos:
- Gestión operativa: La gestión operativa de la CNV debería valorar la implementación de una estrategia de gestión de claves sólida. Esto implica adoptar prácticas adecuadas de gestión de claves, como el almacenamiento seguro de las claves en una ubicación separada y protegida, la implementación de políticas de rotación y actualización regular de claves, y el acceso controlado y restringido a las claves.
- Seguridad tecnológica: Mantener todas las claves en el mismo ambiente donde se procesan las operaciones puede aumentar el riesgo de compromiso de las claves y, por lo tanto, de acceso no autorizado a datos críticos. La CNV debería considerar una arquitectura de seguridad en capas, donde las claves se almacenen en entornos seguros y separados, y se implementen mecanismos de protección adecuados, como cifrado robusto y autenticación de múltiples factores.
- Protección de datos críticos: Los inversores confían en la CNV para proteger sus datos críticos. Si la gestión de claves no se realiza adecuadamente, existe un riesgo considerable de que los datos puedan ser comprometidos y utilizados de manera fraudulenta. La falta de una gestión adecuada de claves podría minar la confianza de los inversores en la CNV y en el sistema financiero en general.
- Cumplimiento normativo: Además de los aspectos técnicos y de seguridad, es importante tener en cuenta los requisitos normativos y regulatorios relacionados con la gestión de claves y la protección de datos en el ámbito financiero. La CNV debe asegurarse de cumplir con todas las regulaciones y directrices aplicables, tanto en términos de protección de datos como de seguridad cibernética.
En general, la falta de una adecuada gestión de claves en un entorno donde se procesan las operaciones puede ser considerada como una práctica de seguridad deficiente y poco confiable. Esto puede generar dudas sobre la competencia y responsabilidad de la CNV para proteger los datos críticos de los inversores y mantener la integridad del sistema financiero.
Por lo tanto, es esencial que la CNV valore y priorice una gestión adecuada de claves y demuestre un alto nivel de respeto hacia los inversores mediante la implementación de medidas sólidas de seguridad tecnológica y operativa.
Tomando en cuenta la Resolución General 704-E/2017 Normas (N.T. 2013 y mod.). Modificación. Ciudad de Buenos Aires, 24/08/2017 ¿Qué debería hacer el gobierno para corregir estos problemas?
La Resolución General 704-E/2017 establece normas relacionadas con la gestión de claves y la protección de datos en el ámbito financiero en Argentina. Si el gobierno identifica que la Comisión Nacional de Valores (CNV) no cumple con estas normas y presenta problemas en su gestión de claves, puede tomar diversas medidas para corregir la situación. Algunas acciones que el gobierno podría considerar son las siguientes:
- Auditoría y evaluación: El gobierno podría llevar a cabo una auditoría exhaustiva de los sistemas y procesos de la CNV para evaluar la situación actual en términos de gestión de claves y protección de datos. Esta evaluación permitiría identificar las áreas problemáticas y los posibles riesgos asociados.
- Capacitación y concientización: Es importante que el gobierno brinde capacitación y concientización a la CNV y a su personal sobre las mejores prácticas de gestión de claves y seguridad cibernética. Esto puede incluir programas de formación en seguridad, actualización sobre las regulaciones y directrices aplicables, y la promoción de una cultura de seguridad dentro de la organización.
- Implementación de medidas de seguridad: El gobierno puede requerir que la CNV implemente medidas específicas de seguridad para corregir los problemas identificados. Esto puede incluir la adopción de soluciones de gestión de claves robustas, la mejora de la arquitectura de seguridad en capas, la implementación de controles de acceso adecuados y el fortalecimiento de las políticas y procedimientos de seguridad en general.
- Supervisión y cumplimiento: El gobierno debe establecer un mecanismo de supervisión continuo para asegurar que la CNV cumpla con las normas establecidas en la Resolución General 704-E/2017 y otras regulaciones aplicables. Esto puede incluir inspecciones regulares, informes de cumplimiento y sanciones en caso de incumplimiento.
- Cooperación y colaboración: El gobierno puede fomentar la cooperación y colaboración entre las entidades regulatorias, las agencias de seguridad cibernética y la CNV para abordar los problemas de gestión de claves y protección de datos de manera más efectiva. Esto implica el intercambio de información y mejores prácticas, la colaboración en investigaciones y la promoción de estándares de seguridad comunes.
En resumen, para corregir los problemas identificados en la gestión de claves de la CNV, el gobierno debe tomar medidas que incluyan auditorías, capacitación, implementación de medidas de seguridad, supervisión y cumplimiento, y fomentar la cooperación y colaboración.
Estas acciones ayudarán a garantizar que la CNV cumpla con las normas establecidas y proteja de manera efectiva los datos críticos de los inversores.
Recomendaciones del Editor
Este informe detalla el análisis realizado el grupo de Análisis de IT CONNECT LATAM sobre la filtración de datos ocurrida en la Comisión Nacional de Valores (CNV) de Argentina.
A través de un examen exhaustivo del filetree (árbol de ficheros) publicado por el actor de ransomware, se identificaron volúmenes que abarcaban información confidencial y crítica para el organismo.
Además, se detectaron prácticas de seguridad informática inadecuadas, como el almacenamiento de contraseñas en archivos de texto plano.
Estos hallazgos resaltan la necesidad de mejorar la gestión de la seguridad y proteger los datos sensibles en entidades gubernamentales y financieras.
Descripción del incidente: Analizando el filetree, se identificaron ocho volúmenes de información filtrada. Uno de ellos, denominado “CNS_MAIN”, contiene directorios y archivos que abarcan información financiera, de recursos humanos, escaneos de documentos y planos en formato CAD.
Los volúmenes etiquetados como “SQL” revelaron bases de datos relacionadas con varios aspectos de la CNV, como el BackOffice de Prensa, Bolsa de Reportes, CAFirmantes, Calificadoras, Fideicomisos, Fondos Comunes, Invertir, RRHH, Registro, RESOL, CNV y CNVWeb, todos ellos identificados como entornos de producción.
En otros volúmenes, se encontraron directorios que mencionan Informes de la DyEMC, Intranet de la CNV, Comité de Seguridad,
Comunicación Interna, Denuncias, Directorio de Prensa, Fichas de Sociedades, GDE (habría comprometido en cierta forma la infraestructura del Sistema de Expedientes de Gobierno), mesa Fintech, Mercosur e incluso información sobre CEDEARS.
Es importante destacar que uno de los volúmenes contiene información crítica de seguridad relacionada con la infraestructura, incluyendo logs de firewalls y proxies, con mención específica a uno ubicado en la DMZ de ARSAT.
Además, se descubrió una carpeta denominada “hola” que contenía archivos en formato de texto plano (DOC, PDF, Excel) que albergaban contraseñas del organismo. Esta práctica representa una grave falta de seguridad informática y pone en riesgo la integridad de los sistemas y la confidencialidad de los datos.
En base a los hallazgos mencionados, recomiendo encarecidamente a la CNV y al gobierno argentino que tomen las siguientes medidas para corregir los problemas identificados y mejorar la seguridad de los datos:
- Auditoría de seguridad: Realizar una auditoría exhaustiva de los sistemas de la CNV para evaluar la magnitud del incidente y determinar el alcance de la filtración de datos.
- Mejora de la gestión de claves: Implementar una estrategia sólida de gestión de claves que cumpla con las mejores prácticas de seguridad. Esto implica almacenar las claves en entornos seguros y separados, realizar rotaciones periódicas de claves, y aplicar políticas de acceso y control estrictas.
- Reforzamiento de la seguridad de la infraestructura: Evaluar y fortalecer las medidas de seguridad en la infraestructura de la CNV. Esto incluye implementar firewalls robustos, sistemas de detección de intrusiones, protección contra malware y soluciones de monitoreo de red para identificar y prevenir ataques cibernéticos.
- Educación y concientización sobre seguridad: Brindar capacitación y concientización a todo el personal de la CNV sobre las mejores prácticas de seguridad cibernética. Esto incluye la importancia de utilizar contraseñas fuertes, no almacenarlas en archivos de texto plano y estar alerta ante posibles amenazas de phishing y malware.
- Evaluación de proveedores y terceros: Realizar una evaluación exhaustiva de los proveedores y terceros que tienen acceso a la infraestructura y los sistemas de la CNV. Asegurarse de que sigan prácticas sólidas de seguridad y cumplimiento normativo.
- Implementación de controles de acceso y autenticación sólidos: Establecer políticas de acceso y autenticación que requieran la utilización de autenticación de múltiples factores, contraseñas robustas y control de privilegios para limitar el acceso a información sensible y sistemas críticos.
- Monitoreo y detección de amenazas: Implementar soluciones de monitoreo y detección de amenazas en tiempo real para identificar patrones y comportamientos anómalos en los sistemas y la red de la CNV. Esto permitirá una respuesta rápida ante posibles ataques y minimizar el tiempo de exposición a las amenazas.
- Continuidad del negocio y planes de recuperación ante desastres: Desarrollar y probar regularmente planes de continuidad del negocio y recuperación ante desastres para garantizar que la CNV pueda recuperarse de manera rápida y efectiva en caso de un incidente de seguridad o interrupción del servicio.
- Estas recomendaciones ayudarán a la CNV a fortalecer su postura de seguridad, proteger los datos críticos de los inversores y mejorar la confianza en el sistema financiero. Es esencial que el gobierno argentino y la CNV aborden estos problemas de manera prioritaria y asignen los recursos necesarios para implementar medidas de seguridad sólidas y efectivas.
Haz lo que yo digo, pero no lo que yo hago! Aquello que la CVN propone y NO CUMPLE!
COMISIÓN NACIONAL DE VALORES
Resolución General 704-E/2017
Normas (N.T. 2013 y mod.). Modificación.
Ciudad de Buenos Aires, 24/08/2017
VISTO el Expediente Nº 1657/2017 caratulado “PROYECTO DE RG S/ CIBERSEGURIDAD Y RESILIENCIA CIBERNÉTICA” del registro de la COMISIÓN NACIONAL DE VALORES, lo dictaminado por la Gerencia de Servicios Centrales, la Subgerencia de Verificaciones de Agentes y Mercados, la Subgerencia de Agentes y Calificadoras de Riesgo, la Gerencia de Agentes y Mercados, la Gerencia General de Mercados, la Subgerencia de Asesoramiento Legal, la Gerencia de Asuntos Jurídicos y la Gerencia General de Asuntos Jurídicos, y
CONSIDERANDO:
Que de acuerdo a las atribuciones otorgadas por el artículo 19 inciso g) de la Ley Nº 26.831, la COMISIÓN NACIONAL DE VALORES se encuentra facultada para dictar las normas a las cuales deben ajustarse los Mercados, los Agentes registrados y las demás personas físicas y/o jurídicas que por sus actividades vinculadas al Mercado de Capitales, y a criterio de la Comisión Nacional de Valores queden comprendidas bajo su competencia.
Que resulta conveniente adoptar estándares internacionales con respecto a la seguridad informática y atender a las recomendaciones de la ORGANIZACIÓN INTERNACIONAL DE COMISIONES DE VALORES (IOSCO, por sus siglas en inglés) sobre los principios de ciberseguridad y resiliencia cibernética.
Que el Comité de Sistemas de Pago y Liquidación (CPSS) del Banco de Pagos Internacionales (BIS) y el Comité Técnico de IOSCO establecen a través de los “Principios Básicos para Infraestructuras de Mercado Financiero” que las “Infraestructuras de Mercado Financiero” cumplen un rol crítico en el sistema financiero y en la economía en general.
Que los principios mencionados enumeran las principales categorías de riesgos identificados y proporcionan orientación a las “Infraestructuras de Mercado Financiero” y a las autoridades competentes sobre la identificación, monitoreo, mitigación y administración de estos riesgos.
Que asimismo, definen los riesgos operacionales como la posibilidad de que deficiencias en los sistemas de información y en los procesos internos, errores humanos y/o fallas por eventos externos, resulten en la reducción, deterioro o interrupción de los servicios proporcionados por una “Infraestructura de Mercado Financiero”.
Que la interoperabilidad de las infraestructuras críticas del Mercado de Capitales posibilitaría la propagación y ampliación de los efectos de los ciberataques, así como las vías de acceso de amenazas, aumentando el riesgo sistémico.
Que al respecto, el Comité de Pagos e Infraestructuras de Mercado (CPMI – ex CPSS) del BIS junto con el Directorio de IOSCO elaboraron una “Guía sobre la Resiliencia Cibernética para las Infraestructuras de Mercado Financiero”, con la finalidad de proporcionar orientación a las “Infraestructuras de Mercado Financiero” para mejorar su gestión sobre los riesgos cibernéticos, destacando que el nivel de respuesta a los incidentes de seguridad contribuye a conservar su capacidad operativa.
Que el mencionado documento proporciona recomendaciones tendientes a ampliar la capacidad de resiliencia cibernética de las “Infraestructuras de Mercado Financiero”, alineadas con los controles y buenas prácticas definidas por el estándar de la familia ISO 27000, como estrategias utilizadas internacionalmente para mitigar los riesgos relativos a la ciberseguridad.
Que, adicionalmente, el desarrollo asimétrico respecto a las tecnologías de la información de los distintos actores del Mercado de Capitales, torna necesario un plan de implementación diferenciado según el grado de madurez de los mismos.
Que la presente Resolución General se dicta en ejercicio de las atribuciones conferidas por el artículo 19 inciso g) de la Ley N° 26.831.
Por ello,
LA COMISIÓN NACIONAL DE VALORES
RESUELVE:
ARTÍCULO 1°.- Incorporar como Sección VII del Capítulo III del Título VI de las NORMAS (N.T. 2013 y mod.), el siguiente texto:
“SECCIÓN VII.
CIBERSEGURIDAD Y CIBERRESILIENCIA CRÍTICAS DEL MERCADO DE CAPITALES.
ARTÍCULO 20.- El órgano de administración de los Mercados, Agentes de Depósito Colectivo, Cámaras Compensadoras y Agentes de Custodia, Registro y Pago, deberá, antes del 1° de enero de 2018, aprobar las “Políticas de Seguridad de la Información” elaboradas conforme los lineamientos de la norma ISO 27000, según el Anexo del presente Capítulo, titulado “Ciberseguridad y Ciberresiliencia de las Infraestructuras Críticas del Mercado de Capitales”.
ARTÍCULO 21.- Dentro de los DOS (2) meses de aprobadas, por el órgano de administración, las “Políticas de Seguridad de la Información”, los sujetos mencionados en el artículo anterior deberán elaborar un “Plan de Implementación de las Políticas de Seguridad de la Información del Mercado de Capitales” a través de procedimientos que incorporen un criterio de mejora continua.
ARTÍCULO 22.- Las “Políticas de Seguridad de la Información” deberán aplicarse a los activos informáticos y a los procesos relacionados a la prestación de servicios esenciales.
ARTÍCULO 23.- Los sujetos mencionados en el artículo 20 deberán antes del 1° de marzo de 2018, adoptar medidas, de resiliencia cibernética, siguiendo los lineamientos de la “Guía sobre la Resiliencia Cibernética para las Infraestructuras de Mercado Financiero” de la CPSS – IOSCO.
ARTÍCULO 24.- El informe de auditoría externa anual de sistemas que deben remitir los sujetos mencionados en el artículo 20, adicionalmente deberá contener la opinión del auditor respecto del “Plan de Implementación de las Políticas de Seguridad de la Información del Mercado de Capitales”, incluyendo el grado de avance en el desarrollo del mismo y de cumplimiento de los objetivos de control requeridos en el Anexo titulado “Ciberseguridad y Ciberresiliencia de las Infraestrucuturas críticas del Mercado de Capitales”.
ARTÍCULO 2°.- Incorporar como Anexo del Capítulo III del Título VI de las NORMAS (N.T. 2013 y mod.), el siguiente texto:
“ANEXO
Ciberseguridad y Ciberresiliencia de las Infraestructuras críticas del Mercado de Capitales.
CONTENIDO.
SECCIÓN I
Políticas de tecnología de la información, comunicaciones y seguridad.
Orientación de la Dirección para la seguridad de la información.
Políticas de seguridad y gestión de la información.
Revisión de las políticas.
Comité de tecnología/seguridad con participación del Directorio.
Plan y presupuesto de seguridad y ti.
SECCIÓN II
Roles y responsabilidades.
Responsabilidad de la Dirección.
Roles y responsabilidades de seguridad de la información.
Segregación de funciones.
Contacto con las autoridades.
Contacto con grupos de interés especial.
Seguridad de la información en la gestión de proyectos.
SECCIÓN III
Capital Humano.
Evaluación previa al ingreso.
15.1. Investigación de antecedentes.
15.2. Términos y condiciones de empleo.
Seguimiento de la relación laboral.
16.1. Responsabilidades de la Dirección.
16.2. Concientización, educación y capacitación en seguridad de la información.
Finalización del vínculo laboral.
17.1 Responsabilidades en la desvinculación o cambio de puesto.
SECCIÓN IV
Activos de la información.
Identificación.
Inventario de los activos.
Propiedad de los activos.
Uso aceptable de los activos.
Retorno de los activos.
Clasificación de la información.
Metodología para el análisis de riesgos informáticos.
Manipulación de los activos.
SECCIÓN V
Usuarios de la información.
Política de control de accesos.
Requisitos del negocio para el control de accesos a los sistemas y las aplicaciones.
Acceso a las redes y a los servicios de red.
Gestión de accesos del usuario.
Alta y baja de registros de usuario.
Gestión de los derechos de acceso privilegiado.
Revisión de los derechos de acceso del usuario.
Remoción o ajuste de los derechos de acceso.
Procedimientos seguros de inicio de sesión.
Sistema de gestión de autenticación.
SECCIÓN VI
Seguridad de la infraestructura.
Áreas Seguras.
38.1. Perímetro de seguridad física.
38.2. Controles físicos.
38.3. Aseguramiento de oficinas, recintos e instalaciones.
38.4. Protección contra amenazas externas y del entorno.
Equipamiento.
39.1. Ubicación y protección del equipamiento.
39.2. Mantenimiento del equipamiento.
39.3. Retiro de activos.
39.4. Disposición final segura o reutilización del equipamiento.
Dispositivos móviles y teletrabajo.
40.1. Política de dispositivo móvil.
40.2. Teletrabajo.
SECCIÓN VII
Gestión de operaciones.
Procedimientos operativos documentados.
Gestión de la capacidad.
Controles contra código malicioso.
Resguardo de la información.
Registro de eventos.
Protección de la información de los registros.
Control de las vulnerabilidades técnicas.
SECCIÓN VIII
Gestión de comunicaciones.
Gestión de la seguridad de la red.
52.1. Controles de red.
52.2. Seguridad de los servicios de red.
52.3. Segregación en redes.
SECCIÓN IX
Gestión de plataformas productivas.
Generalidades.
Gestión de requerimientos y requisitos de seguridad/controles.
Desarrollo seguro.
Separación de entornos de desarrollo, prueba y producción.
Pruebas.
Paquetes de software y desarrollo tercerizado.
SECCIÓN X
Relaciones con proveedores.
Seguridad de la información en las relaciones con los proveedores.
Política de seguridad de la información para las relaciones con los proveedores.
Tratamiento de la seguridad en los acuerdos con los proveedores.
Cadena de suministro de las tecnologías de la información y las comunicaciones.
Gestión de la entrega de servicios prestados por los proveedores.
Seguimiento y revisión de los servicios prestados por los proveedores.
SECCIÓN XI
Monitoreo.
Responsabilidades y procedimientos.
Presentación de informes sobre los eventos de seguridad de la información.
Presentación de informes sobre las vulnerabilidades de seguridad de la información.
Evaluación y decisión sobre los eventos de seguridad de la información.
Respuesta a los incidentes de seguridad de la información.
Aprendizaje a partir de los incidentes de seguridad de la información.
Recolección de la evidencia.
SECCIÓN XII
Gestión de continuidad del negocio
Gestión de la continuidad.
Planificación de la continuidad del negocio.
Implementación de plan de contingencia.
Implementación de la continuidad del negocio.
Prueba del plan de continuidad.
Verificación, revisión y valoración de la continuidad del negocio.
Redundancias.
SECCIÓN XIII
Relación con otras partes interesadas.
Ecosistema.
Canal de contacto.
Documentación de interconexiones.
Identificación de riesgos.
Pruebas conjuntas.
Ambiente de pruebas.
Control de cambios.
Acuerdos de intercambio de información.
Detección de vulnerabilidades.
Respuestas ante incidentes.
Sincronización de relojes.
SECCIÓN I
POLÍTICAS DE TECNOLOGÍA DE LA INFORMACIÓN, COMUNICACIONES Y SEGURIDAD.
ORIENTACIÓN DE LA DIRECCIÓN PARA LA SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 1º.- La Dirección debe establecer el marco de gobierno de resiliencia de ciberseguridad en el que se establezcan los lineamientos para la gestión de la tecnología, las comunicaciones y la seguridad de la información, con el objetivo de asegurar el negocio y la continuidad de operaciones de los Mercados, Agentes de Depósito Colectivo, Cámaras Compensadoras, y Agentes de Custodia, Registro y Pago (CMI “capital market integration”).
ARTÍCULO 2º.- El marco de resiliencia de la ciberseguridad debe estar alineado con los requisitos del negocio y orientado a formalizar el apoyo de parte de la Dirección. Este apoyo debe ser tomado como referencia por todo el personal involucrado en el diseño, implementación y revisión del proceso.
La Dirección debe definir la tolerancia de riesgo y es responsable de aprobar periódicamente el marco de resiliencia de la ciberseguridad, para asegurar que el riesgo definido es consistente con los objetivos de negocio.
POLÍTICAS DE SEGURIDAD Y GESTIÓN DE LA INFORMACIÓN
ARTÍCULO 3º.- Se debe contar con políticas de seguridad y gestión de la información aprobada por la Dirección.
Las políticas deben ser publicadas y conocidas por todos los miembros de la organización; y deben definir y asignar claramente las responsabilidades de los distintos sectores sobre los activos informáticos, considerando las siguientes premisas:
– Los requisitos de negocio y funcionales de los sistemas de información serán definidos por los usuarios propietarios de los datos.
– La gestión de los activos tecnológicos que soportan la automatización de los procesos críticos será de exclusiva responsabilidad de las áreas de TI:
Activos físicos: equipos de procesamiento, comunicaciones y almacenamiento de la información, y su infraestructura relacionada.
Activos de software de base: sistemas operativos, motores de bases de datos, herramientas de desarrollo, etc.
ARTÍCULO 4º.- El responsable de Seguridad de la Información debe tener suficiente autoridad, independencia, recursos y acceso al Directorio. Dicho ejecutivo debe poseer la experiencia y los conocimientos necesarios para planificar y ejecutar las iniciativas de resiliencia de ciberseguridad, de manera competente, adicionalmente será responsable de la gestión de los activos relacionados con su función.
ARTÍCULO 5º.- Para la implementación de cualquier nuevo aplicativo, las áreas usuarias y técnicas (TI y Seguridad Informática) deberán trabajar coordinadamente para encontrar la solución adecuada (ya sea un paquete de software de terceros o una aplicación desarrollada internamente) que satisfaga los requisitos de negocio definidos por los usuarios y cumpla simultáneamente los estándares tecnológicos y de seguridad determinados por los responsables técnicos.
REVISIÓN DE LAS POLÍTICAS
ARTÍCULO 6º.- Las políticas de seguridad de la información deben ser revisadas al menos una vez por año (o antes si ocurren cambios significativos) para validar que continúan siendo apropiadas, adecuadas y eficaces en relación a los objetivos del negocio.
COMITÉ DE TECNOLOGÍA/SEGURIDAD CON PARTICIPACIÓN DEL DIRECTORIO
ARTÍCULO 7º.- Se debe conformar un comité de tecnología/seguridad en el cual la Dirección sea responsable de establecer, aprobar y velar por la actualización de un marco para fortalecer la ciberseguridad, incluyendo la responsabilidad por la toma de decisiones para la gestión de riesgos cibernéticos, incluso en situaciones de emergencia y de crisis.
La alta gerencia debe supervisar estrechamente la aplicación de su marco de resiliencia de la ciberseguridad como así también las políticas, procedimientos y controles que lo soportan.
PLAN Y PRESUPUESTO DE SEGURIDAD Y TI.
ARTÍCULO 8º.- De acuerdo con las metas y planes estratégicos, se deben elaborar planes operativos que contemplen los factores críticos para un efectivo control sobre los sistemas y la seguridad de la información, junto con las actividades del negocio que respaldan. Dichos planes tendrán en cuenta las tareas a realizar con su correspondiente asignación de tiempos y recursos, los presupuestos, las prioridades y la precedencia de cada una de ellas.
SECCIÓN II
ROLES Y RESPONSABILIDADES.
RESPONSABILIDAD DE LA DIRECCIÓN.
ARTÍCULO 9º.- La Dirección es responsable de promover una adecuada administración de la seguridad de la información y establecer un marco gerencial para iniciar y controlar su implementación, así como para la distribución de funciones y responsabilidades.
ROLES Y RESPONSABILIDADES DE SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 10.- Se deben definir y asignar claramente las responsabilidades relativas a la seguridad de la información.
SEGREGACIÓN DE FUNCIONES.
ARTÍCULO 11.- Las funcionalidades y responsabilidades en conflicto deben estar separadas con el fin de reducir los riesgos de modificaciones no intencionales o no autorizadas, o el mal uso de activos de información.
CONTACTO CON LAS AUTORIDADES.
ARTÍCULO 12.- Se deben mantener los contactos apropiados con las autoridades pertinentes. CONTACTO CON GRUPOS DE INTERÉS ESPECIAL.
ARTÍCULO 13.- Se deben mantener contactos apropiados con los grupos de interés especial u otros foros de seguridad especializados y asociaciones profesionales.
SEGURIDAD DE LA INFORMACIÓN EN LA GESTIÓN DE PROYECTOS.
ARTÍCULO 14.- La seguridad de la información se contempla en la dirección de proyectos, independientemente del tipo de proyecto.
SECCIÓN III CAPITAL HUMANO.
EVALUACIÓN PREVIA AL INGRESO.
ARTÍCULO 15.- Se debe asegurar que los empleados y contratados entiendan sus responsabilidades y sean idóneos para los roles para los cuales se los contrata.
15.1. INVESTIGACIÓN DE ANTECEDENTES.
Se debe realizar la verificación de antecedentes de todos los candidatos para el empleo de acuerdo con las leyes, regulaciones y reglas éticas pertinentes. Dicha verificación debe ser proporcional a los requisitos de seguridad de la organización, a la clasificación de la información a ser accedida y a los riesgos potenciales percibidos.
15.2. TÉRMINOS Y CONDICIONES DE EMPLEO.
Los contratos con empleados y contratados deben establecer sus responsabilidades y las de la organización para con la seguridad de la información.
SEGUIMIENTO DE LA RELACIÓN LABORAL.
ARTÍCULO 16.- Se debe asegurar que los empleados y contratados sean conscientes de sus responsabilidades con respecto a la seguridad de la información y las cumplan. Los recursos humanos deben mantenerse técnicamente capacitados e informados conforme a la evolución de los requerimientos, normas y tecnologías de los sistemas de seguridad adoptados por las organizaciones.
16.1. RESPONSABILIDADES DE LA DIRECCIÓN.
La Dirección y las gerencias deben requerir a todos los empleados y contratados que apliquen la seguridad de la información de acuerdo con las políticas y procedimientos establecidos por la organización.
16.2. CONCIENTIZACIÓN, EDUCACIÓN Y CAPACITACIÓN EN SEGURIDAD DE LA INFORMACIÓN.
Todos los empleados de la organización y, cuando sea pertinente los proveedores, deben recibir una concientización, educación y capacitación apropiada como así también actualizaciones regulares sobre las políticas y procedimientos organizacionales relativos a su tarea.
FINALIZACIÓN DEL VÍNCULO LABORAL.
ARTÍCULO 17.- Se deben proteger los intereses de la organización como parte del proceso de desvinculación o cambio de puesto.
17.1 RESPONSABILIDADES EN LA DESVINCULACIÓN O CAMBIO DE PUESTO.
Se deben definir, comunicar y hacer cumplir, al empleado o contratado, las responsabilidades y obligaciones relativas a la seguridad de la información que continúen vigentes luego de la desvinculación o cambio de puesto. Se debe verificar que las asignaciones, atribuciones y accesos a la información se actualicen debidamente ante cambios de funciones o desvinculaciones.
SECCIÓN IV
ACTIVOS DE LA INFORMACIÓN. IDENTIFICACIÓN.
ARTÍCULO 18.- La organización debe tener un conocimiento preciso sobre los activos que posee, logrando y manteniendo una apropiada protección de los mismos.
Se define como activo a la información crítica de negocio y todas aquellas plataformas que procesan, almacenan y transmiten dicha información.
INVENTARIO DE LOS ACTIVOS.
ARTÍCULO 19.- La organización debe identificar los activos relevantes en el ciclo de vida de la información e inventariarlos para su control. El inventario deberá ser actualizado ante cualquier modificación de la información registrada y revisado con una periodicidad al menos anual.
PROPIEDAD DE LOS ACTIVOS.
ARTÍCULO 20.- Se debe implementar un proceso para la asignación de un propietario de los activos organizacionales. La propiedad debe ser asignada ante la creación, desarrollo o adquisición de los mismos. El propietario debe ser responsable de la gestión adecuada de un activo durante todo su ciclo de vida y responsable de su clasificación.
USO ACEPTABLE DE LOS ACTIVOS.
ARTÍCULO 21.- La autoridad relevante deberá identificar, documentar e implementar reglas para el uso aceptable de la información y los activos asociados.
Los empleados y usuarios externos que utilicen o tengan acceso a los activos de la organización deberán estar informados de los requisitos de seguridad de la información, de los activos de la organización asociados con las instalaciones, recursos y procesamiento de información.
RETORNO DE LOS ACTIVOS.
ARTÍCULO 22.- Todos los empleados y usuarios externos deben devolver todos los activos de la organización en su poder al finalizar su empleo, contrato o acuerdo. El proceso de terminación debe formalizarse para incluir la devolución de todos los activos físicos y electrónicos pertenecientes a la organización.
CLASIFICACIÓN DE LA INFORMACIÓN.
ARTÍCULO 23.- Con el objetivo de asegurar que la información reciba un nivel de protección apropiado, la misma debe ser clasificada para indicar la necesidad, prioridades y grado de protección esperado en su gestión.
Las clasificaciones y los controles de protección asociados a la información deben tener en cuenta las necesidades del negocio de compartirla o restringirla, así como los requisitos legales.
Los resultados de la clasificación deben ser actualizados de acuerdo con los cambios de su valor, sensibilidad y criticidad a través de su ciclo de vida.
ARTÍCULO 24.- Para clasificar un activo de información, se deben evaluar las tres características de la información en las cuales se basa la seguridad: confidencialidad, integridad y disponibilidad.
Se considera críticos como mínimo a aquellos activos de la información relacionados con las operaciones, saldos, movimientos, cuentas, comitentes y garantías de sus Mercados como así también de otros Mercados.
METODOLOGÍA PARA EL ANÁLISIS DE RIESGOS INFORMÁTICOS.
ARTÍCULO 25.- Se debe evidenciar la existencia de análisis de riesgos formalmente realizados y documentados sobre los sistemas de información, la tecnología informática y sus recursos asociados.
Los resultados de los análisis mencionados y sus actualizaciones periódicas deben ser formalmente reportados al Comité de Tecnología/Seguridad, que será el responsable primario de darle tratamiento a las debilidades que expongan a los CMI a un riesgo mayor al aceptable.
MANIPULACIÓN DE LOS ACTIVOS.
ARTÍCULO 26.- Para cada uno de los niveles de clasificación, se deben definir los procedimientos de manejo seguro, incluyendo las actividades de procesamiento, almacenamiento, transmisión, clasificación y destrucción.
SECCIÓN V
USUARIOS DE LA INFORMACIÓN.
POLÍTICA DE CONTROL DE ACCESOS.
ARTÍCULO 27.- Se debe formalizar una política de control de accesos alineada a los requisitos del negocio acorde a la clasificación de activos definida en los ARTÍCULOS 23 y 24.
REQUISITOS DEL NEGOCIO PARA EL CONTROL DE ACCESOS A LOS SISTEMAS Y LAS APLICACIONES.
ARTÍCULO 28.- La organización debe basar las restricciones de acceso a la información en los requisitos de las aplicaciones individuales y de acuerdo con la política de control de acceso.
Con el objetivo de proteger la información relativa al negocio, se debe limitar al mínimo el acceso a la información crítica.
ACCESO A LAS REDES Y A LOS SERVICIOS DE RED.
ARTÍCULO 29.- Se debe permitir el acceso solamente a aquellos usuarios que cuenten con la debida autorización y hayan sido apropiadamente capacitados. La autorización debe ser acorde al rol desempeñado en el negocio.
GESTIÓN DE ACCESOS DEL USUARIO.
ARTÍCULO 30.- Se debe asegurar el acceso solamente a los usuarios autorizados, teniendo en cuenta las funciones de desarrollo, procesamiento y operación de los sistemas afectados, manteniendo siempre los principios de confidencialidad, integridad y disponibilidad.
ALTA Y BAJA DE REGISTROS DE USUARIO.
ARTÍCULO 31.- Se debe implementar un proceso formal de alta, baja y modificación de roles y permisos del usuario, formalizando el proceso de asignación de accesos. En la medida de lo posible, se debe establecer una línea base de configuración de seguridad y forzarla en todos los sistemas críticos.
GESTIÓN DE LOS DERECHOS DE ACCESO PRIVILEGIADO.
ARTÍCULO 32.- Se deben identificar los grupos de usuarios con permisos elevados en los diferentes dispositivos y sistemas críticos, para luego controlar la asignación y utilización de sus derechos de acceso sobre los mismos.
ARTÍCULO 33.- Debe restringirse, controlarse rigurosamente y segregarse adecuadamente el uso de herramientas con privilegios que podrían ser capaces de anular los controles en los sistemas, o que permitan el alta, baja o modificación de datos operativos por fuera de las aplicaciones.
REVISIÓN DE LOS DERECHOS DE ACCESO DEL USUARIO.
ARTÍCULO 34.- Se debe establecer un proceso de revisión periódica de los accesos otorgados a los usuarios para los dispositivos, herramientas y sistemas críticos, en el cual deben participar los propietarios de los activos y responsables del negocio. Este proceso debe realizarse como mínimo una vez por año, o antes si existiera alguna situación que lo justifique.
REMOCIÓN O AJUSTE DE LOS DERECHOS DE ACCESO.
ARTÍCULO 35.- En el caso de cambio de roles o desvinculación de usuarios, se deben revisar y ajustar los derechos de acceso a los servicios y sistemas a los cuales tenía acceso, y luego aplicar los cambios que sean necesarios. Este proceso debe estar validado por los propietarios de activos o responsables del negocio.
PROCEDIMIENTOS SEGUROS DE INICIO DE SESIÓN.
ARTÍCULO 36.- El procedimiento para iniciar sesión en un sistema o aplicación debe ser diseñado para reducir al mínimo la oportunidad de que ocurra un acceso no autorizado, incluyendo la selección de técnicas de autenticación adecuadas para demostrar la identidad alegada de un usuario. La cantidad y fortaleza de los métodos de autenticación empleados debe ser acorde con el tipo de información a proteger y los riesgos identificados. En particular, las organizaciones deben establecer fuertes controles sobre accesos privilegiados mediante su limitación y supervisión estricta.
Cuando el nivel de riesgo lo amerite, se analizará el empleo de más de un método de autenticación como contraseñas, tarjetas inteligentes, tokens o medios de reconocimiento biométricos.
Para los accesos iniciados desde ubicaciones externas a la infraestructura de la organización, ya sean propias o contratadas a un tercero, se deberá considerar más de un mecanismo de autenticación para el inicio de sesión.
SISTEMA DE GESTIÓN DE AUTENTICACIÓN.
ARTÍCULO 37.- La administración de la información para la autenticación debe considerar los siguientes aspectos:
– Cambiar los datos de autenticación por defecto de todos los productos instalados.
– Evitar el uso de cuentas genéricas, imponiendo identificadores de usuario y datos de autenticación individuales con el objetivo de posibilitar la rendición de cuentas y los análisis forenses.
– Proteger el almacenamiento y la transmisión de los datos de autenticación a través de algoritmos criptográficos reconocidos internacionalmente.
– Solicitar a los usuarios su autenticación luego de 15 minutos de inactividad.
– En caso de extravío del medio de autenticación debe existir un proceso de bloqueo del utilizado y validación para la entrega del nuevo medio.
Adicionalmente, si el medio de autenticación utilizado es a través de contraseñas se deben considerar los siguientes aspectos:
– Obligar a los usuarios a cambiar sus contraseñas en la primera conexión.
– Permitir a los usuarios seleccionar y cambiar sus propias contraseñas, considerando las siguientes características: longitud mínima de 8 caracteres cuya composición debe incluir caracteres numéricos, alfanuméricos y especiales, evitando la reutilización de las últimas 12 contraseñas.
– Forzar cambios periódicos de contraseña como mínimo cada 90 días.
– Implementar medidas técnicas para mitigar ataques del tipo “diccionario” o “fuerza bruta” tales como bloqueo de cuenta luego de una cierta cantidad de intentos fallidos de inicio de sesión, captchas, delays o requerimiento de autenticación de 2 factores.
SECCIÓN VI
SEGURIDAD DE LA INFRAESTRUCTURA.
ÁREAS SEGURAS
ARTÍCULO 38.- Se deben proteger las instalaciones e infraestructuras de procesamiento contra daños y accesos no autorizados.
38.1. PERÍMETRO DE SEGURIDAD FÍSICA.
Se deben utilizar perímetros de seguridad para proteger áreas que contengan información e instalaciones de procesamiento de información sensibles o críticas. El Directorio o autoridad equivalente, es el responsable primario por la existencia de distintos niveles de seguridad física en correspondencia con el valor, confidencialidad y criticidad de los recursos a proteger y los riesgos identificados.
38.2. CONTROLES FÍSICOS.
Deberán protegerse las áreas seguras mediante controles apropiados, por lo que se deben considerar, entre otras, las siguientes medidas de prevención y control:
– Instalaciones para equipamientos de apoyo, tales como equipos de aire acondicionado, grupos generadores, llaves de transferencia automática, UPS, baterías, estabilizadores y tableros de distribución de energía y de telecomunicaciones.
– Instalaciones de montaje apropiadas para los sistemas de telecomunicaciones.
– Instalaciones de montaje apropiadas para los sistemas de suministro eléctrico, tanto primario como secundario.
– Iluminación de emergencia.
– Sistemas de monitoreo y control de las utilidades críticas del centro de procesamiento de datos.
– Controles de acceso, por medio de los cuales se permita sólo el ingreso al área de procesamiento de datos a personal autorizado.
Todos los accesos, de rutina o de excepción, deben ser registrados por mecanismos que permitan la posterior revisión de al menos los siguientes datos: nombre completo, relación (interno o externo), en caso de ser externo deberá constar quién ha autorizado el acceso, motivo, hora de ingreso y hora de egreso.
Los sistemas de prevención contra incendios en los ambientes de procesamiento de datos deben posibilitar alarmas preventivas, que tengan la capacidad de ser disparadas automáticamente ante la presencia de partículas características en el recalentamiento de materiales eléctricos y otros materiales combustibles presentes en las instalaciones.
Los materiales combustibles deben ser minimizados dentro del área del centro de procesamiento de datos. La mampostería, muebles y útiles deben ser constructivamente no inflamables, y preferentemente ignífugos.
Para el caso de que este servicio sea provisto por terceros se deberá solicitar al proveedor cumplir con lo exigido en la sección X.
38.3. ASEGURAMIENTO DE OFICINAS, RECINTOS E INSTALACIONES.
Deben diseñarse y aplicarse controles de seguridad física para oficinas, recintos e instalaciones, proporcionales a su criticidad y a los riesgos identificados.
38.4. PROTECCIÓN CONTRA AMENAZAS EXTERNAS Y DEL ENTORNO.
Se deben diseñar y aplicar medidas de protección física contra desastres naturales, ataques intencionales o accidentes.
EQUIPAMIENTO.
ARTÍCULO 39.- Se debe proteger el equipamiento (de procesamiento de la información y de soporte) de la organización contra daño, pérdida o robo.
39.1. UBICACIÓN Y PROTECCIÓN DEL EQUIPAMIENTO.
Se debe proteger el equipamiento de manera tal que se reduzcan los riesgos por amenazas y peligros del entorno, y las oportunidades de acceso no autorizado.
Dicho equipamiento se debe proteger de fallas causadas por el suministro eléctrico o de otras interrupciones ocasionadas por fallas en elementos de soporte.
39.2. MANTENIMIENTO DEL EQUIPAMIENTO.
El equipamiento debe recibir un mantenimiento correcto y oportuno para asegurar su continua disponibilidad e integridad.
39.3. RETIRO DE ACTIVOS.
Debe evitarse el retiro sin previa autorización del equipamiento o información en diferentes medios, tanto digitales como físicos, utilizados en las oficinas como en los centros de procesamiento. En caso de tratarse de datacenters de terceros el personal autorizado a retirar equipamiento deberá registrarlo para su posterior control.
Se deben aplicar medidas de seguridad a los activos en tránsito o fuera de la organización, considerando los diversos riesgos de operar fuera de sus instalaciones.
39.4. DISPOSICIÓN FINAL SEGURA O REUTILIZACIÓN DEL EQUIPAMIENTO.
Se deben verificar todos los componentes del equipamiento que contengan medios de almacenamiento para asegurar que, antes de su disposición final o reutilización, se haya eliminado o sobrescrito de manera segura cualquier dato sensible y software licenciado.
DISPOSITIVOS MÓVILES Y TELETRABAJO.
ARTÍCULO 40.- Se deben considerar los riesgos específicos del teletrabajo y la utilización de dispositivos móviles.
40.1. POLÍTICA DE DISPOSITIVO MÓVIL.
Se debe adoptar una política de soporte y medidas de seguridad para gestionar los riesgos introducidos mediante el uso de dispositivos móviles.
40.2. TELETRABAJO.
Se debe adoptar una política de soporte y medidas de seguridad destinadas a proteger la información accedida, transferida o almacenada en los sitios de teletrabajo.
SECCIÓN VII
GESTIÓN DE OPERACIONES.
PROCEDIMIENTOS OPERATIVOS DOCUMENTADOS.
ARTÍCULO 41.- Se debe contar con procedimientos operativos documentados, autorizados y comunicados a todos los usuarios que los necesiten. Los procedimientos deben incluir los procesos a ejecutar, los controles a realizar, la modalidad de registración de las actividades tanto satisfactorias como fallidas y los mecanismos de escalamiento de problemas.
GESTIÓN DE LA CAPACIDAD.
ARTÍCULO 42.- Previa consideración de la criticidad de los activos informáticos, se debe desarrollar un informe de análisis de capacidad de los activos más importantes, y luego efectuar un monitoreo periódico para evaluar el grado de cumplimiento del citado informe.
CONTROLES CONTRA CÓDIGO MALICIOSO
ARTÍCULO 43.- Se deben implementar mecanismos de protección contra código malicioso para prevenir, detectar, responder, contener y recuperarse rápidamente de cualquier incidente. Se debe restringir la instalación de software no autorizado y promover actividades periódicas de capacitación para las áreas técnicas y de concientización a los usuarios.
Se deben controlar los archivos intercambiados a través del correo electrónico o cualquier otro medio.
Los controles deberán implementarse en todos los ambientes de procesamiento y en las copias de resguardo; y deberá prestarse especial atención a las soluciones de alta disponibilidad que, si bien contribuyen a la recuperación de las operaciones en caso de contingencia, también se convierten en un medio de propagación de software malicioso y/o datos dañados.
Las herramientas utilizadas para detectar y eliminar código malicioso deben mantenerse actualizadas contra nuevas amenazas. En caso de contagio deben mantenerse informadas todas las partes interesadas, tal como se determina en la Sección XIII.
RESGUARDO DE LA INFORMACIÓN
ARTÍCULO 44.- Debe desarrollarse una estrategia de resguardo y recuperación de información que permita hacer frente a los requisitos de disponibilidad de la misma, considerando las necesidades del negocio y las disposiciones legales, reglamentarias y/o contractuales aplicables.
Se debe contar con procedimientos formalmente documentados, autorizados y comunicados que describan los aspectos salientes de dicha estrategia. Se deben definir claramente las responsabilidades de los involucrados, tanto de los propietarios de los datos como de las áreas técnicas.
ARTÍCULO 45.- Deben resguardarse datos, programas, sistemas operativos y todo activo de información que se considere relevante. La organización debe mantener inventarios permanentemente actualizados de los resguardos y demás registros de utilidad para su control y eventual restauración.
ARTÍCULO 46.- A partir de un análisis de riesgo, se deben determinar las estrategias y las prioridades de resguardo, el tipo de soporte a utilizar (por ejemplo: resguardo en medios de almacenamiento magnéticos/ ópticos, esquemas de alta disponibilidad con redundancia de datos, etc.).
La cantidad de copias a mantener, la ubicación física de los resguardos (se deberá demostrar que la ubicación del servicio de contingencia o resguardo de la información no será alcanzado por los mismos riesgos en forma simultánea), los períodos de retención, y la frecuencia y modalidad de las pruebas de restauración.
Las copias de resguardo de los datos deben contar con medidas de seguridad equivalentes a las de los datos originales.
El período de retención no podrá ser inferior a lo requerido por legislación y reglamentación vigente. Al menos se deberá contar con un juego de resguardos fuera del lugar donde la CMI procesa la información.
REGISTRO DE EVENTOS.
ARTÍCULO 47.- Se deben producir, conservar y revisar periódicamente los registros de eventos en los cuales se registren las actividades de los usuarios, las excepciones, los errores y los eventos de seguridad de la información, prestando especial atención al registro y revisión de las actividades ejecutadas por los titulares de las cuentas de usuarios privilegiados, usuarios de emergencia y con accesos especiales.
ARTÍCULO 48.- A partir de los registros de eventos, se deben conducir investigaciones forenses de incidentes cibernéticos y producir información de utilidad para el esclarecimiento de los hechos y la prevención de ataques futuros.
PROTECCIÓN DE LA INFORMACIÓN DE LOS REGISTROS.
ARTÍCULO 49.- Los registros de eventos deben ser protegidos contra accesos no autorizados, borrado y manipulación. Deben contar con una estrategia de resguardo que los preserve en caso de contingencia y garantice su disponibilidad durante los plazos exigibles.
CONTROL DE LAS VULNERABILIDADES TÉCNICAS
ARTÍCULO 50.- Se deben conocer las vulnerabilidades técnicas de los activos informáticos, evaluar la exposición a las vulnerabilidades y tomar las medidas apropiadas para mitigar los riesgos asociados.
Partiendo de un inventario completo y actualizado de los activos, se deben implementar mecanismos eficaces de gestión de las vulnerabilidades de seguridad con el objetivo de prevenir su explotación externa y/o interna.
Para la detección temprana de las vulnerabilidades se pueden emplear diferentes técnicas como por ejemplo los test de intrusión que, simulando un ataque real, ayudan a identificar vulnerabilidades en las redes, los sistemas, los procesos o en el comportamiento de las personas.
ARTÍCULO 51.- Una vez identificadas vulnerabilidades de seguridad que afecten los sistemas y que puedan estar siendo explotadas, deben probarse y aplicarse los parches críticos, o tomar otras medidas de protección, tan rápida y extensamente como sea posible.
Se debe establecer un proceso para priorizar y solucionar los problemas identificados y realizar una validación posterior para evaluar si se han abordado completamente las brechas de seguridad.
SECCIÓN VIII
GESTIÓN DE COMUNICACIONES. GESTIÓN DE LA SEGURIDAD DE LA RED.
ARTÍCULO 52.- Se debe asegurar la protección de la información crítica en las redes y sus instalaciones de procesamiento de información.
52.1. CONTROLES DE RED.
Se deben implementar controles para garantizar la seguridad de la información en las redes y la protección de los servicios conectados contra el acceso no autorizado.
52.2. SEGURIDAD DE LOS SERVICIOS DE RED.
Los mecanismos de seguridad, los niveles de servicio y los requisitos de gestión de los servicios de red deben identificarse y ser formalizados en acuerdos de servicios.
Se deben contemplar los servicios provistos desde redes internas, que son consumidos por usuarios internos y externos.
52.3. SEGREGACIÓN EN REDES.
Los grupos de servicios, usuarios y sistemas de información crítica deben ser segregados en redes.
El acceso entre redes está permitido, pero debe ser controlado en el perímetro. Los criterios para la segregación de redes y el acceso permitido deben basarse en una evaluación de los requisitos de seguridad de acceso a la información crítica.
SECCIÓN IX
GESTIÓN DE PLATAFORMAS PRODUCTIVAS.
GENERALIDADES.
ARTÍCULO 53.- Se debe contar con procedimientos documentados y comunicados de gestión del cambio en la infraestructura, software de base y aplicaciones, que regulen el proceso de cambio o instalación de nuevos elementos desde los entornos de desarrollo hasta la puesta en producción.
Se deben asignar claras responsabilidades para todos los intervinientes en el proceso y se contará con mecanismos de registro y control de los cambios efectuados.
ARTÍCULO 54.- Las modificaciones deben realizarse a partir de una justificación técnica o de negocio válida y deben contar con su respectiva autorización.
Cualquier cambio debe considerar la evaluación de los impactos potenciales, incluyendo los impactos en la seguridad de la información y los riesgos cibernéticos.
ARTÍCULO 55.- Tanto para el desarrollo de nuevos aplicativos como para el mantenimiento de los existentes, debe definirse el ciclo de vida del proceso de desarrollo considerando aspectos como la separación de ambientes; la segregación de funciones entre los distintos responsables del proceso; el estricto control de versiones de programas y de la correspondencia entre los programas fuente y los ejecutables.
Los procedimientos deben contemplar pruebas, controles y validaciones tanto para los desarrollos propios como para los tercerizados.
ARTÍCULO 56.- Se debe disponer de procedimientos planificados de vuelta atrás para la recuperación de la situación ante situaciones imprevistas o cambios que resulten fallidos.
ARTÍCULO 57.- Se debe contar con procedimientos de cambio de emergencia para permitir la aplicación rápida y controlada de los cambios necesarios para resolver un incidente.
En estos procedimientos se debe detallar el mecanismo de obtención y modificación del código fuente, y los controles detectivos a realizar con posterioridad al cambio por parte de personal independiente.
GESTIÓN DE REQUERIMIENTOS Y REQUISITOS DE SEGURIDAD/CONTROLES
ARTÍCULO 58.- Los requisitos legales, reglamentarios, contractuales y de negocio deben contemplarse desde el inicio de las tareas de adquisición, desarrollo o mantenimiento de los sistemas de información, considerando los riesgos inherentes y las necesidades de protección de los activos de información, incluyendo su integridad, disponibilidad y confidencialidad.
ARTÍCULO 59.- Los requerimientos de seguridad deben evaluarse desde la misma fase de diseño, ya que la incorporación temprana de medidas de seguridad y controles en las aplicaciones, reduce el riesgo de introducción involuntaria o malintencionada de vulnerabilidades en el entorno productivo.
Los aspectos relativos a la ciberseguridad deben también considerarse en etapas tempranas del desarrollo de los sistemas, aplicando medidas de protección contra las amenazas más frecuentes y diseñando controles detectivos y correctivos que faciliten la respuesta a incidentes y permitan restablecer las operaciones críticas en caso de ataque, preservando la integridad de las transacciones y los datos.
Dado el carácter interconectado del mercado de capitales, deben establecerse oportunamente los requisitos de resiliencia frente a ciberataques, que aseguren la disponibilidad de las interconexiones necesarias para la prestación de los servicios críticos.
ARTÍCULO 60.- En cuanto a los requerimientos funcionales de los aplicativos nuevos o modificados, se deberán adoptar las mejores prácticas en materia de control interno.
Incorporando desde el inicio validaciones y controles automatizados que reduzcan hasta un nivel aceptable para el negocio los riesgos de errores, duplicaciones, faltantes o alteraciones en el ingreso, procesamiento, transmisión, almacenamiento y conciliación de los datos.
ARTÍCULO 61.- Debe existir una clara y documentada vinculación entre las nuevas versiones de los elementos desarrollados y los requerimientos que le dieron origen.
ARTÍCULO 62.- Cuando las aplicaciones a adquirir o desarrollar trascienden los límites de las redes locales y atraviesen redes públicas, se deben tomar medidas adicionales de protección acordes con el nivel de los riesgos identificados y documentados.
Entre los controles a considerar, se valorará el cifrado de la información transmitida; la implementación de métodos de autenticación seguros; la utilización de tecnologías que garanticen la integridad, confidencialidad y no repudio de la información compartida (por ejemplo, a través del uso de criptografía de clave pública y firmas digitales).
ARTÍCULO 63.- Se deben establecer los acuerdos de nivel de servicio entre los participantes, especialmente en lo referido a la autorización de las transacciones que atraviesan redes públicas con el objetivo de minimizar el riesgo de litigios entre las partes.
DESARROLLO SEGURO.
ARTÍCULO 64.- Deben incorporarse prácticas de codificación segura que resulten pertinentes a la infraestructura tecnológica utilizada, debiendo mantenerse las mismas actualizadas para incluir oportunamente medidas que mitiguen las nuevas amenazas.
Los desarrolladores y los testers deben recibir capacitación continua sobre las vulnerabilidades conocidas a cada momento y sobre las prácticas de codificación segura que la industria vaya publicando y promoviendo (por ejemplo: OWASP Guide, Cert Secure Coding Standard, etc.).
Estas prácticas aplican tanto para las tareas de desarrollo internas como para las realizadas por terceros.
SEPARACIÓN DE ENTORNOS DE DESARROLLO, PRUEBA Y PRODUCCIÓN.
ARTÍCULO 65.- Se deben separar los entornos de producción de los de desarrollo y pruebas, de forma tal que los productivos sean totalmente independientes de los restantes; promoviendo una adecuada segregación de funciones entre el personal dedicado al desarrollo/mantenimiento de los sistemas y los responsables de la operación de los mismos.
Los encargados de los despliegues en el ambiente productivo deben ser independientes de las áreas a cargo del desarrollo.
Para reforzar la separación, se deben establecer controles de acceso específicos (físicos y/o lógicos) para cada ambiente, en función de las actividades a cargo de los distintos responsables del proceso (desarrolladores, testers, implementadores, administradores, operadores, usuarios, proveedores, etc.)
PRUEBAS.
ARTÍCULO 66.- Los sistemas de información nuevos y sus modificaciones, tanto para los desarrollos propios como para los productos de terceros, deben ser probados en un ambiente de prueba en forma previa a su pasaje al entorno de producción.
Las pruebas deben diseñarse para determinar que el sistema funcione como se espera y cumple con los requisitos funcionales, de integración con otros sistemas y de seguridad que dieron origen al desarrollo/mantenimiento.
La naturaleza y alcance de las pruebas debe quedar documentado en base a la evaluación realizada por el área de desarrollo y el usuario aprobador del requerimiento.
Se valorará que las pruebas consideren aspectos tales como funcionalidad, usabilidad, integración con otras piezas de software y ciberseguridad.
ARTÍCULO 67.- Las pruebas deben realizarse en entornos destinados a tal fin y que representen razonablemente los entornos productivos. Deben tomarse los recaudos para evitar que los datos personales y/o confidenciales (tanto datos maestros como información que agregada resulte crítica) sean utilizados en ambientes distintos al entorno de producción.
Si fuera necesario utilizar información personal o de carácter confidencial para propósitos de prueba, todos los datos sensibles deberán ser protegidos mediante su enmascaramiento u otras medidas de protección que impidan su divulgación a personal distinto al estrictamente autorizado en los ambientes productivos.
ARTÍCULO 68.- Las pruebas, especialmente las que abarcan los aspectos de ciberseguridad, deben ser llevadas a cabo por personal técnico con la capacitación adecuada y actualizada.
Los propietarios de los datos deben participar en las pruebas de aceptación final, con el objetivo de validar que los sistemas cumplen con los requerimientos de negocio que motivaron el desarrollo.
PAQUETES DE SOFTWARE Y DESARROLLO TERCERIZADO.
ARTÍCULO 69.- En el caso de utilizar paquetes de software de terceros para operaciones definidas críticas para el negocio, se deben contemplar procedimientos para el acceso a los programas fuentes en caso de que el proveedor no pueda responder a las exigencias locales.
En la medida de lo posible, los sistemas de terceros deben utilizarse tal como son provistos por su fabricante.
Se deben definir contractualmente los derechos y obligaciones de cada parte en lo relativo al mantenimiento del sistema, tomando los recaudos contractuales pertinentes para asegurar el sostenimiento del paquete de software en caso de que el fabricante se vea imposibilitado de dar el soporte necesario.
Los cambios propuestos por el fabricante deben ser probados en un ambiente de prueba y homologados por la organización en forma previa a su implementación.
ARTÍCULO 70.- En los casos en que se decida delegar en terceros las actividades de desarrollo de los sistemas, las organizaciones mantienen la responsabilidad por el producto final, tanto en lo relativo al cumplimiento de los requisitos de negocio, contractual y legal, como en lo referido a las medidas de seguridad, controles adoptados y documentación de los aplicativos.
ARTÍCULO 71.- Las organizaciones y sus proveedores de servicios de desarrollo de software deben establecer contratos que determinen al menos:
– Los derechos de propiedad intelectual de los aplicativos.
– La propiedad del código fuente.
– Las garantías para el cumplimiento del contrato y las penalidades en caso de incumplimiento.
– Los criterios de aceptación de los entregables.
– Los requisitos de documentación.
– El derecho de la organización y de sus entes de contralor para realizar auditorías sobre los procesos de construcción/prueba de software del proveedor.
– La obligatoriedad del proveedor de software de comunicar en forma fehaciente, con al menos 3 (tres) años de anticipación, la fecha prevista de caducidad de la versión instalada y/o sus servicios de soporte.
– La obligatoriedad del proveedor/propietario del software de comunicar en forma fehaciente, con al menos 5 (cinco) años de anticipación, la decisión de discontinuar el producto, otorgando en dicha circunstancia la posibilidad de entregar a la organización los programas fuente, sin derecho de comercialización.
– La obligatoriedad del proveedor de adherir a las prácticas de desarrollo seguro, las metodologías de prueba y las medidas adoptadas en materia de ciberseguridad por la organización, sometiéndose a las revisiones y validaciones que la organización considere pertinentes para controlar el cumplimiento de lo requerido y la calidad del software.
ARTÍCULO 72.- Las organizaciones deberán monitorear las medidas de protección utilizadas por el proveedor contra las vulnerabilidades conocidas y realizar pruebas del software en forma previa a su pasaje al ambiente de producción.
SECCIÓN X
RELACIONES CON PROVEEDORES.
ARTÍCULO 73.- Un CMI podrá tercerizar el desarrollo, la homologación, el procesamiento y la explotación de la totalidad o una parte de sus plataformas productivas, como así también la totalidad o parte de la infraestructura principal o de contingencia.
La estrategia de tercerización de la CMI deberá estar contemplada en el marco de resiliencia de seguridad, de manera tal que los riesgos derivados de dicha tercerización se encuentren en los niveles aceptados por la Dirección.
El CMI deberá solicitar al proveedor del servicio un informe de cumplimiento sobre lo requerido por el presente documento por parte de un profesional independiente, tales como ISAE del tipo II o SOC del tipo II, o permitir el acceso del auditor de la CMI para una revisión in situ.
SEGURIDAD DE LA INFORMACIÓN EN LAS RELACIONES CON LOS PROVEEDORES.
ARTÍCULO 74.- Se deben asegurar aquellos activos de la organización que son accedidos por proveedores y externos.
Es de suma importancia que todos los participantes comprendan los objetivos de recuperación y que puedan tomar acciones preventivas, ya que un incidente puede afectar a todo el ecosistema.
POLÍTICA DE SEGURIDAD DE LA INFORMACIÓN PARA LAS RELACIONES CON LOS PROVEEDORES.
ARTÍCULO 75.- Se deben acordar con los proveedores y formalizar los requisitos relativos a la seguridad de la información, detallando los posibles riesgos y sus respectivas medidas mitigantes.
TRATAMIENTO DE LA SEGURIDAD EN LOS ACUERDOS CON LOS PROVEEDORES.
ARTÍCULO 76.- Acuerdos de confidencialidad.
Se deben formalizar las condiciones y obligaciones de parte de los proveedores en relación al tratamiento de la información de los clientes. Los acuerdos deben detallar los métodos de recuperación en caso de que un incidente comprometa la confidencialidad o integridad, para asegurar que la información pueda ser recuperada en tiempo y forma, acorde a los plazos definidos.
En caso de transmitir, procesar o almacenar por medios lógicos o físicos compartidos con terceros, el proveedor deberá demostrar las medidas aplicadas para asegurar la confidencialidad de la información.
CADENA DE SUMINISTRO DE LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES.
ARTÍCULO 77.- Los acuerdos con los proveedores deben incluir requisitos para tratar los riesgos asociados al suministro de tecnologías y comunicaciones, considerando (pero no limitándose) a los procesos de otros mercados, cámaras compensadoras, proveedores de energía, etc.
ARTÍCULO 78.- Se debe solicitar que cada participante establezca su tiempo de recuperación ante incidentes, para poder medir el impacto en la propia infraestructura.
Si los tiempos de recuperación fueran mayores a los propios, se deben establecer medidas mitigantes o exigir al participante que establezca un tiempo -como mínimo- igual o menor al de la propia organización.
Los acuerdos deben asegurar que todos los interesados puedan tener acceso a la información necesaria para tratar el riesgo de cada participante.
GESTIÓN DE LA ENTREGA DE SERVICIOS PRESTADOS POR LOS PROVEEDORES.
ARTÍCULO 79.- Las CMI deben asegurarse que la prestación de servicios de los proveedores que resulten críticos se realice en los términos y condiciones pactados.
La revisión de los servicios de los proveedores debe asegurar que se respeten y mantengan vigentes los términos y condiciones de los acuerdos asumidos a lo largo de la contratación.
Para lo cual se debe requerir la documentación actualizada solicitada al momento de la contratación y si se necesitara adquirir nuevos servicios para una nueva funcionalidad, documentación que compruebe la capacidad del proveedor para dar dicho servicio.
SEGUIMIENTO Y REVISIÓN DE LOS SERVICIOS PRESTADOS POR LOS PROVEEDORES.
ARTÍCULO 80.- Las CMI deben revisar y auditar periódicamente la prestación de servicios de los proveedores que resulten críticos.
Deberá solicitar al proveedor del servicio un informe de cumplimiento sobre lo requerido por el presente documento por parte de un profesional independiente, tales como ISAE del tipo II o SOC del tipo II, o permitir el acceso del auditor de la CMI para una revisión in situ.
SECCIÓN XI
MONITOREO.
ARTÍCULO 81.- La Dirección debe promover un enfoque coherente y eficaz para la gestión de incidentes de seguridad de la información, incluida la comunicación sobre debilidades, eventos de seguridad y su temprana detección;
Manteniendo una actividad proactiva mediante un adecuado monitoreo de las condiciones de seguridad que permitan montar contramedidas oportunas y apropiadas ante los incidentes.
RESPONSABILIDADES Y PROCEDIMIENTOS.
ARTÍCULO 82.- Se deben establecer las responsabilidades y los procedimientos para asegurar una respuesta rápida, eficaz y ordenada a los incidentes de seguridad de la información.
PRESENTACIÓN DE INFORMES SOBRE LOS EVENTOS DE SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 83.- Los eventos de seguridad de la información se deben informar a través de los canales apropiados, tan pronto como sea posible.
PRESENTACIÓN DE INFORMES SOBRE LAS VULNERABILIDADES DE SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 84.- Se debe requerir a los empleados y contratistas usuarios de los sistemas de información de la organización, que informen cualquier vulnerabilidad de seguridad de la información observada o sospechada en sistemas o servicios.
Se deben realizar análisis exhaustivos para determinar la naturaleza y extensión de los incidentes así como el daño infligido.
Mientras la investigación está en curso, se deben tomar medidas inmediatas para contener la situación con el objetivo de prevenir daños adicionales y comenzar los esfuerzos de recuperación para restaurar las operaciones basadas en su planificación de respuesta.
EVALUACIÓN Y DECISIÓN SOBRE LOS EVENTOS DE SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 85.- Se deben evaluar los eventos de seguridad de la información y decidir si se los debe clasificar como incidentes de seguridad de la información y asegurar la recolección de información para el proceso de investigación forense.
RESPUESTA A LOS INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 86.- Se debe responder a los incidentes de seguridad de la información de acuerdo con procedimientos documentados.
Al registrar los incidentes, se deben documentar como mínimo:
• Equipo, usuario, servicio o aplicación afectada
• Ubicación física, horario y día
• Síntomas detectados
• Acciones realizadas
• Cualquier otra información que se considere de relevancia
APRENDIZAJE A PARTIR DE LOS INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN.
ARTÍCULO 87.- Se debe utilizar el conocimiento obtenido del análisis y resolución de los incidentes de seguridad de la información para reducir la probabilidad o el impacto de incidentes futuros.
Debe asegurarse de que todo el personal, ya sea permanente o temporal, reciba capacitación para desarrollar y mantener una conciencia apropiada y las competencias necesarias para detectar y abordar los riesgos de seguridad.
RECOLECCIÓN DE LA EVIDENCIA.
ARTÍCULO 88.- La organización debe definir y aplicar procedimientos para la identificación, recolección, adquisición y preservación de la información que se pueda utilizar como evidencia.
Y debe tener la capacidad de asistir o llevar a cabo investigaciones forenses de incidentes cibernéticos y establecer políticas de registro relevantes que incluyan los tipos de evidencias que se deben mantener y sus períodos de retención.
SECCIÓN XII
GESTIÓN DE CONTINUIDAD DEL NEGOCIO.
GESTIÓN DE LA CONTINUIDAD.
ARTÍCULO 89.- Se debe incorporar la continuidad del negocio como parte de los sistemas de gestión de la organización.
El Directorio/Comité es el responsable de aprobar la identificación, la valorización, la gestión y el control de los riesgos relacionados con la continuidad del negocio.
Debe asegurar la existencia y la provisión de los recursos necesarios para la creación, mantenimiento y prueba de un plan de recuperación del procesamiento de información automática.
La CMI debe asegurarse de que:
a) Se defina una estructura de gestión del Plan de Continuidad del Negocio acorde con el detalle de sus funciones y responsabilidades relacionadas con esta gestión.
b) Se identificarán las diferentes tipologías de incidentes que alcanzará a la infraestructura de la CMI.
c) Se identifique el personal de respuesta a incidentes con la responsabilidad necesaria, autoridad y competencia para gestionar un incidente y mantener la seguridad de la información;
d) los planes de procedimientos documentados, respuesta y recuperación sean desarrollados y aprobados, que detallen cómo la organización gestionará un evento perjudicial y mantendrá su seguridad de la información a un nivel predeterminado.
De acuerdo con los requisitos de continuidad seguridad de la información, la organización debe establecer, documentar, implementar y mantener controles de seguridad de la información dentro de los procesos de continuidad de negocio o de recuperación de desastres.
Se deben identificar toda la legislación aplicable a su organización con el fin de cumplir con los requisitos para la CMI.
PLANIFICACIÓN DE LA CONTINUIDAD DEL NEGOCIO.
ARTÍCULO 90.- La continuidad del procesamiento de datos automático, que en definitiva posibilita la continuidad de los negocios, deberá evidenciar que se han identificado los eventos que puedan ocasionar interrupciones en sus procesos críticos.
Es responsabilidad del Comité/Directorio aprobar la evaluación de riesgos para determinar el impacto de distintos eventos, tanto en términos de magnitud de daño como del período de recuperación y la vuelta a la normalidad.
Estas actividades deben llevarse a cabo con la activa participación de los propietarios de los procesos y recursos de negocio.
La evaluación considerará todos los procesos de negocio alcanzados por esta norma y no se limitará sólo a las instalaciones de procesamiento de la información, sino también a todos los recursos relacionados.
Los resultados de la evaluación deben ser el soporte para la selección de mecanismos alternativos de recuperación y adopción de medidas preventivas para la confección del plan de recuperación y vuelta a la normalidad del procesamiento de datos.
IMPLEMENTACIÓN DE PLAN DE CONTINGENCIA.
ARTÍCULO 91.- Las instalaciones alternativas de procesamiento de datos deben atender los requisitos mínimos establecidos por estas normas, pudiendo ser propias o de terceros.
El equipamiento de las instalaciones de procesamiento alternativo debe contemplar la capacidad de administración y gestión de todos los procesos de negocios clasificados como críticos para asegurar mantener la actividad mínima definida por la CMI.
La instalación alternativa debe prever la existencia de equipamiento destinado a las telecomunicaciones para acceder al servicio mínimo que brinda.
En caso de un siniestro o suceso contingente que torne inoperantes las instalaciones principales, la localización de las instalaciones alternativas deberá ser tal que no sean alcanzadas por el mismo evento.
Además, deberán tornarse totalmente operacionales en condiciones idénticas, en una ventana de tiempo tal que no afecte la operación.
La selección de la localización antes mencionada deberá estar soportada por la evidencia documental de la existencia de un análisis de riesgo de eventos simultáneos, que están fehacientemente expresados en el mismo.
IMPLEMENTACIÓN DE LA CONTINUIDAD DEL NEGOCIO.
ARTÍCULO 92 – Se debe evidenciar la existencia de un procedimiento escrito, aprobado formalmente, para atender a la continuidad del procesamiento actividades vinculadas, en el caso que se presenten contingencias o emergencias.
El documento deberá basarse en el mismo análisis de riesgo efectuado para determinar la localización de las instalaciones alternativas de procesamiento de datos, enunciando todos los posibles escenarios que harían que el plan entrará en funcionamiento.
El mismo deberá, como mínimo, contener lo siguiente:
• Procedimientos de emergencia que describan las acciones a emprender una vez ocurrido un incidente. Estos deben incluir disposiciones con respecto a la gestión de vínculos eficaces a establecer con las autoridades públicas pertinentes, por ej.: entes reguladores, policía, bomberos y otras autoridades.
• Los datos de contacto del personal clave.
• Las aplicaciones críticas y su prioridad con respecto a los tiempos de recuperación y regreso a la operación normal.
• El detalle de los proveedores de servicios involucrados en las acciones de contingencia / emergencia.
• La información logística de la localización de recursos claves, incluyendo: ubicación de las instalaciones alternativas, de los resguardos de datos, de los sistemas operativos, de las aplicaciones, los archivos de datos, los manuales de operación y documentación de programas / sistemas / usuarios.
PRUEBA DEL PLAN DE CONTINUIDAD.
ARTÍCULO 93.- El plan de continuidad de procesamiento de datos debe ser probado periódicamente, como mínimo una vez al año.
Las pruebas deben permitir asegurar la operatoria integral de todos los sistemas automatizados críticos a efectos de verificar que el plan está actualizado y es eficaz.
Las pruebas también deben garantizar que todos los miembros del equipo de recuperación y demás personal relevante estén al corriente del plan mencionado.
Deberá evidenciarse la existencia de un cronograma formal de pruebas que indicará cómo debe probarse cada elemento del plan, y la fecha en la cual cada una de las pruebas deberá ser efectuada.
En las pruebas deben participar las áreas usuarias de los procesos de negocio, quienes deben verificar los resultados de las mismas.
Se deberá documentar formalmente su satisfacción con el resultado de la prueba como medio para asegurar la continuidad de los procesos de negocio en caso de que ocurra una contingencia.
La auditoría interna de la entidad también deberá conformar la satisfacción por el resultado de las mismas a tal efecto.
El informe realizado por las áreas usuarias y de auditoría interna deberá ser tomado en conocimiento por el Comité/Directorio.
VERIFICACIÓN, REVISIÓN Y VALORACIÓN DE LA CONTINUIDAD DEL NEGOCIO.
ARTÍCULO 94.- Los cambios organizativos, técnicos, de procedimiento y de procesos, ya sea en un contexto operacional o de continuidad, pueden conducir a cambios en los requisitos de continuidad seguridad de la información. En tales casos, la continuidad de los procesos, procedimientos y controles para la seguridad de la información debe ser revisada en contra de estos requisitos que han cambiado.
Las organizaciones deben verificar su información de gestión de la continuidad para la revisión de la validez y eficacia de las medidas de continuidad de seguridad de la información, cuando los sistemas de información, procesos de seguridad de la información, procedimientos y controles o procedimientos de gestión de recuperación de gestión / desastre de continuidad de negocio y soluciones cambian.
REDUNDANCIAS.
ARTÍCULO 95.- Las organizaciones deben identificar los requisitos para la disponibilidad de los sistemas de información. Cuando la disponibilidad no puede ser garantizada mediante la arquitectura de los sistemas existentes, componentes o arquitecturas redundantes deben ser considerados.
Los sistemas de información redundantes deben ser probados para asegurar la conmutación por error de un componente a otro según lo previsto.
SECCIÓN XIII
RELACIÓN CON OTRAS PARTES INTERESADAS.
ECOSISTEMA.
ARTÍCULO 96.- Las partes interesadas (mercados, proveedores de servicio y cualquier otra organización asociada) conforman un ecosistema, con sistemas interconectados y objetivos en común. Con esta premisa, los objetivos de negocio de cada una de las partes deben estar alineados a poder cumplir con los tiempos de recuperación establecidos para el ecosistema en conjunto.
CANAL DE CONTACTO.
ARTÍCULO 97.- Las partes interesadas deben definir un canal de contacto que permita comunicar de forma fehaciente e inmediata cualquier mensaje que las mismas consideren de relevancia.
DOCUMENTACIÓN DE INTERCONEXIONES.
ARTÍCULO 98.- Las partes interesadas deben identificar e inventariar todos los componentes, servicios y sistemas asociados a la plataforma de interconexión. Este inventario debe ser revisado y actualizado al menos una vez por año, o cada vez que la organización lo considere necesario.
IDENTIFICACIÓN DE RIESGOS.
ARTÍCULO 99.- Las partes interesadas deben identificar los riesgos inherentes asociados a cada uno de los componentes que componen el inventario mencionado en el artículo anterior, o que puedan derivar de incidentes ocurridos en plataformas externas.
PRUEBAS CONJUNTAS.
ARTÍCULO 100.- Se deben realizar pruebas en conjunto, y si existiera conflicto de intereses, el ente regulador debe intervenir para arbitrar, supervisar o dar consistencia a los objetivos buscados.
AMBIENTE DE PRUEBAS.
ARTÍCULO 101.- Las partes interesadas deberán tener disponibles ambientes de pruebas funcionalmente equivalentes a los ambientes productivos, que permitan validar el correcto funcionamiento de eventuales cambios en forma previa a la puesta en producción de los mismos.
CONTROL DE CAMBIOS.
ARTÍCULO 102.- En caso de que se planifique o detecte un cambio en las plataformas y servicios de uso compartido o asociadas a la interconexión, la organización responsable debe enviar un aviso a todo el ecosistema en tiempo y forma, a fin de permitirle al resto de las entidades realizar las adecuaciones y pruebas necesarias, utilizando el canal de contacto definido.
ACUERDOS DE INTERCAMBIO DE INFORMACIÓN.
ARTÍCULO 103.- Todo sistema o servicio que represente una plataforma de interconexión debe estar respaldado por un acuerdo de intercambio de información que contemple las acciones a tomar en caso de incidentes que atenten contra la confidencialidad, integridad o disponibilidad de la información afectada.
DETECCIÓN DE VULNERABILIDADES.
ARTÍCULO 104.- En el caso de que alguna de las partes interesadas detecte una amenaza o situación que pueda afectar a la integridad, disponibilidad o confidencialidad de la información en la plataforma de interconexión, deberá dar un aviso al ente regulador, utilizando el canal de contacto establecido anteriormente.
RESPUESTAS ANTE INCIDENTES.
ARTÍCULO 105.- En caso de ocurrencia de incidentes, las partes interesadas involucradas deben colaborar solidariamente brindando información que pueda servir para tareas forenses.
SINCRONIZACIÓN DE RELOJES.
ARTÍCULO 106.- Se debe definir un servicio de sincronización de relojes, utilizando servidores NTP reconocidos en el mercado, a fin de lograr la sincronización exacta de todos tiempos y relojes críticos utilizados para la interconexión”.
ARTÍCULO 3°.- La presente Resolución General entrará en vigencia a partir del día siguiente al de su publicación en el Boletín Oficial de la República Argentina.
ARTÍCULO 4°.- Regístrese, comuníquese, publíquese, dese a la Dirección Nacional del Registro Oficial, incorpórese al sitio web del Organismo en www.cnv.gob.ar, agréguese al texto de las NORMAS (N.T. 2013 y mod.) y archívese. — Patricia Noemi Boedo, Vicepresidenta. — Carlos Martin Hourbeigt, Director. — Martin Jose Gavito, Director.
e. 29/08/2017 N° 62164/17 v. 29/08/2017
Fecha de publicación 29/08/2017
Por Marcelo Lozano – General Publisher IT CONNECT LATAM
Lea más sobre Ciberseguridad en;
Deepfakes: la amenaza creciente para las organizaciones del siglo 21
PyMEs 2023: así cazan los estafadores a los emprendedores
Traceable AI anuncia la 1ra arquitectura de referencia de seguridad de API
Kimsuky 2023 la Inteligencia la señala como la Oficina General de Reconocimiento de Corea del Norte
Gigabyte: descubren 1 ejecutable en su firmware
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,
Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores, Comisión Nacional de Valores,