República Argentina - Poder Ejecutivo Nacional

2017 - Año de las Energías Renovables

 

Resolución General

 

Número: RESGC-2017-704-APN-DIR#CNV

 

 

                                                                                                                                                                                                                                                                                                        CIUDAD DE BUENOS AIRES

                                                                                                                                                                                                                                                                                                             Jueves 24 de Agosto de 2017

 

 

Referencia: Expediente 1657/2017 “PROYECTO DE RG S/ CIBERSEGURIDAD Y RESILIENCIA CIBERNÉTICA”

 

 

 

VISTO  el  Expediente   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 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 26.831.

 

 

 

 

Por ello,

 

LA COMISIÓN NACIONAL DE VALORES RESUELVE:

ARTÍCULO .- 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 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 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 .- 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 .- 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 .- 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.