Seguridad Informática y Continuidad de · PDF fileAnálisis de la Norma BCRA “A” 4609 Seguridad Informática y Continuidad de Procesamiento Módulo II: Fase Práctica Lic. Matías

Análisis de la Norma BCRA “A” 4609Seguridad Informática y

Continuidad de Procesamiento

Módulo II: Fase Práctica

Lic. Matías PagouapéLic. Matías Pagouapémpagouape@[email protected]

55 de de JunioJunio de de 20072007Buenos Aires Buenos Aires -- ARGENTINAARGENTINA

2

© 2007

BCRA “A” 4609 - Seguridad Informática y Continuidad de Procesamiento - Módulo II: Fase Práctica

Estrategia de implementaciónEstrategia de implementaciónRecomendacionesRecomendaciones

•Liderazgo: nombrar un líder “idóneo” para dirigir la implementación de la norma “A” 4609. Alternativa: tercerizar el liderazgo en consultores externos.

•Responzabilidades del líder: coordinar los esfuerzos de la entidad para cumplir en tiempo y forma con la normativa.

Estrategia de implementación

3

© 2007



•Metodología:

a) Gap Analysis

-Identificación de Requerimientos para el “estado deseado”.

-Relevamiento del “estado actual”. Determinación del Gap.

-Identificación de acciones necesarias para alcanzar el estado deseado.

b) Ejecución de Implementación

-Acciones: determinación de tiempos, presupuestos, recursos humanos y prioridades.

-Delegación de tareas a los distintos responsables.

-Seguimiento.

-Reporte a la alta gerencia.

4

© 2007



•Herramientas:

a) Matriz

-Eje Y: Items del Comunicado “A” 4609

-Eje X: Número de Item, Descripción, Estado de cumplimiento, Acción Requerida, Áreas involucradas, Presupuesto requerido, RRHH necesarios, Tiempo de implementación, Prioridad,Tareas Previas Requeridas, % de Avance.

b) Diagrama de Gantt

-MS Project u otros.

-Útiles para determinar la duración total del proyecto y seguimiento.

5

© 2007


Recomendaciones puntuales sobre Recomendaciones puntuales sobre puntos clave puntos clave

para el cumplimiento para el cumplimiento de la norma “A” 4609de la norma “A” 4609

Recomendaciones puntuales para el cumplimiento de la norma

6

© 2007


Seguridad de la InformaciónSeguridad de la Informaciónen el organigrama corporativoen el organigrama corporativo

Organigramas y Responsabilidades

(2.4, 2.5.3, 3.1.1)

Considerando que la norma establece:

•Áreas de Sistemas y Área de Seguridad de la Información independientes de otras áreas usuarias.

•Área de Seguridad de la Información independiente del Área de Sistemas o del Área de Auditoría.

•Segregación de funciones por contraposición de intereses.

Se podría ilustrar el siguiente organigrama modelo:

7

© 2007


Seguridad de la InformaciónSeguridad de la Informaciónen el organigrama corporativoen el organigrama corporativo


Análisis Funcional/Programación

Control de Calidad

Operaciones

Administración de Resguardos

Implementaciones

Data Entry

Administración de bases de datos

Administración de redes

Administración de comunicaciones

Administración de sistemas operativos

Mesa de Ayuda

Sistemas / Informática

Asignación de Perfiles

Definición e implementación de políticas, perfiles y accesos

Control y Monitoreo de seguridad informática

Seguridad de la Información Auditoría

Dirección General

Directorio / CEO

(2.4, 2.5.3, 3.1.1)

8

© 2007



•Crear un documento orgánico con las funciones, roles, misiones y responsabilidades del área y de cada uno de sus sectores (como mínimo se deberá contemplar los items de la A 4609).

•Contratar personal formado en implementación de controles y políticas de seguridad.

•Capacitar y actualizar al personal.

Seguridad de la InformaciónSeguridad de la InformaciónOrganización del áreaOrganización del área

(3.1.1, 3.1.5)

9

© 2007


Nuevas ResponsabilidadesNuevas ResponsabilidadesConcientizaciónConcientización


Sistemas - Seguridad de la Información - Auditoría

Estudio Completo de la Norma

Directorio - CEO

Presentación y Resumen que incluya los siguientes puntos

(incluidos todos los temas, no sólo seguridad)

1, 2.1, 2.2, 2.3, 3.1.4, 3.2, 4.1, 4.2, 5.4, 6.1, 7.2, 7.6, 7.7

10

© 2007


Reportes formales de Reportes formales de Seguridad y ContinuidadSeguridad y Continuidad

Reportes

(2.3, 3.1.5, )

Directorio-CEOAuditoría - Áreas usuarias

AnualReporte de pruebas de Continuidad de procesamiento

Gerencia General / Directorio-CEO

SeguridadSugerido: trimestralReporte Operativo(almacenado en CD/DVD, por 2 años, con hash).

Propietario de datos - Administrador

SeguridadEn caso de incidente de seguridad o vulnerabilidad

Incidente de Seguridad -Vulnerabilidad

Directorio-CEON/ASugerido: Seguridad-Gestión de Riesgos

N/ASugerido: anual

Análisis de Riesgos de Sistemas de Información

DestinoOrigenFrecuencia-MotivoReporte

11

© 2007


Análisis de Riesgos de SistemasAnálisis de Riesgos de Sistemas

Análisis de Riesgos de Sistemas

(2.3)

•Es la base para la toma de decisiones relacionadas con la seguridad. De él depende:

• Estrategia.

• Políticas de Seguridad.

• Plan de Continuidad de Procesamiento.

•El Directorio o CEO es responsable directo de la gestión de riesgos de sistemas.

•El Análisis de Riesgos de Sistemas debe ser actualizadoperiódicamente (sugerido anualmente).

12

© 2007


Análisis de Riesgos de SistemasAnálisis de Riesgos de Sistemas


(2.3)

•El análisis de riesgos tiene metodología estándar. Ej: COBIT, NIST, Octave (CERT).

•Debe ser realizado por personal experimentado en la metodología análisis, sistemas y seguridad.

•2 opciones de implementación:

1) Ejecución in house: designando personal capacitado en la materia.

2) Tercerización: mediante consultoras independientes

13

© 2007


Etapas generales de un Análisis Etapas generales de un Análisis de Riesgos de Sistemasde Riesgos de Sistemas


1. Identificación de activos informáticos

2. Clasificación de activos informáticos críticos

3. Determinación de la Matriz de Impacto

4. Determinación de la Matriz de Probabilidad de

Ocurrencia

5. Determinación de la Matriz de Riesgos

6. Identificación de Amenazas

7. Determinación de Riesgos Brutos y Riesgos Residuales

14

© 2007


Normativas de seguridad internas Normativas de seguridad internas EstrategiaEstrategia

Seguridad Informática – Normativas de seguridad internas

(3.1.2)

•Es el documento de más alto rango en la documentación de seguridad.

•Debe ser validada y aprobada por el Directorio o CEO.

•Se puede implementar a través de la redacción de un documento de aproximadamente 2 hojas.

•Es análoga al Preámbulo de la Constitución.

•Requiere conocimientos avanzados en management de seguridad.

•Debe mencionar el compromiso, alineación y equilibrio de la seguridad de la información con los objetivos de negocio.

15

© 2007


Estructura de la documentaciónEstructura de la documentación


(3.1.2, 3.1.4)

Procedimientos

Lineamientos

Standards/Checklists/Baselines

Normas

Políticas

Estrategia Preámbulo

Constitución

Leyes

Reglamentaciones

Comparable con:

16

© 2007


(3.1.4)

•El Directorio o CEO debe ser el principal interesado en las Políticas. Deben ser aprobadas directamente por él.

•Las “Políticas de Seguridad de la Información” pueden conformarse en un único documento. Típicamente poseen entre 15 y 25 páginas.

•Deben ser comunicadas a toda la compañía. Se recomienda ejecutar presentaciones para que cada gerencia entienda cual es su rol en el mantenimiento de la seguridad.

•Su redacción requiere conocimientos avanzados en management de seguridad.

•Buenas fuentes para usar como punto de partida para el desarrollo de políticas son: “A” 4609, ISO 17799 : 2005, ISO 27001:2005, Manual de Preparación al Exámen CISM.

•Deben ser revisadas periódicamente.


PolíticasPolíticas

17

© 2007


(3.1.4)

•Son documentos consecuentes y derivados de la Política.

•Son emitidas por el área de Seguridad de la Información.

•Los puntos mínimos a reglar están listados en el punto 3.1.4 del comunicado.

•Deben ser revisados periódicamente ante cambios tecnológicos o de procedimientos.

•Son documentos que requieren alta adaptación a la entidad.

•Se recomienda el esfuerzo en una redacción clara, sin ambigüedadesy con optimización de recursos y tiempos.


Normas y resto de documentaciónNormas y resto de documentación

18

© 2007


Para cumplir las metas de seguridad es necesario preveer los recursos necesarios. Por lo que se recomienda:

•Establecer en las Políticas de Seguridad la ejecución de un presupuesto anual para el Área de Seguridad que contemple dinero y personal necesario para alcanzar las metas de seguridad.

•Establecer en las Políticas de Seguridad que todo nuevo proyecto informático debe contemplar los requerimientos de seguridad desde el inicio del ciclo de vida.

Planeamiento de RecursosPlaneamiento de Recursos(3.1.3)

Seguridad Informática – Planeamiento de recursos

19

© 2007


(3.1.4.1)

Se recomiendan los siguientes pasos:

•Redactar la Norma de Clasificación de Datos. En esencia, la misma contendría la definición de niveles y el tratamiento de cada nivel.

•Niveles típicos: Público, Interno, Confidencial, Estrictamente Confidencial.

•Clasificar toda la información que maneja la entidad en un anexo de la norma.

•Se aconseja validar con el Directorio o CEO.

•La administración de accesos debe ser coherente con la clasificación.

Seguridad Informática – Clasificación de Datos y Niveles de Seguridad

Clasificación de Datos y Niveles Clasificación de Datos y Niveles de Seguridadde Seguridad

20

© 2007


Seguridad Informática – Control de accesos y Actualización

(3.1.4.2)Control de Accesos y ActualizaciónControl de Accesos y Actualización

•El contenido de la primera parte del punto 3.1.4.2 debería ser parte de una Norma de Control de Accesos (salvo actualización y parches).

•La mayoría de esos puntos están pensados para aplicaciones y sistemas operativos de red, por lo que es razonable la no implementación de algunos puntos en ciertos dispositivos (ej, registro histórico de contraseñas en un print server, bloqueo de cuentas en un access point por intentos fallidos, etc).

•Se aconseja emitir una norma de Administración de Actualizacionespara tratar el tema parches.

•El resto del punto 3.1.4.2 son buenas prácticas recomendadas aunque no obligatorias.

21

© 2007


Seguridad Informática – Control de accesos y Actualización

(3.1.4.3, 5.6)

Acceso de bajo nivel a bases de datosAcceso de bajo nivel a bases de datos

•El acceso de bajo nivel a los datos es altamente riesgoso. Dado que las aplicaciones encargadas de resguardar la integridad, confidencialidad y disponibilidad de los mismos sufren un bypass.

•El punto 3.1.4.3 y 5.6 debería ser tratado especialmente en la Norma de Control de Accesos.

•Se debe impedir el acceso a datos por fuera de las aplicaciones a personas o software utilitario.

•La cantidad de personal que posee este tipo de privilegios deber ser mínimo, sus acciones registradas y vigiladas.

22

© 2007


Registros de auditoría (logs) y Registros de auditoría (logs) y alertasalertas

Seguridad Informática – Logs y alertas

Si10 añosNo reutilizableTransacciones y gestión de claves en e-Banking, m-banking y phone banking

6.4, 6.5,6.6

Si10 añosNo reutilizableSistema de Administración de POS6.3

Si10 añosNo reutilizableSistema de Administración de Cajeros Automáticos

6.2

N/A10 añosNo reutilizable(no papel term.)

Actividad de Cajeros Automáticos6.2

3.1.4.4

3.1.4.4 5.6

3.1.4.4 8.2

3.1.4.3 5.6

Punto

Si10 añosNo reutilizableRegistros Operativos de usuarios en aplicaciones

Si10 añosNo reutilizableExcepciones y actividades críticas en plataforma

Si10 añosNo reutilizableActividad de Control de Accesos y usuarios privilegiados.

Si10 añosNo reutilizable (ej CD/DVD)

Actividad de bajo nivel con datos

Monitoreo y Alertas?

Tiempo de conservación

Medio de almacenamiento

Descripción

23

© 2007


Alertas de SeguridadAlertas de Seguridad(3.1.4.5)

•La “A” 4609 exige implementar “funciones” de detección y alerta de accesos sospechosos a los sistemas así como monitoreo constante de los accesos. Aunque no exige que sean automatizados.

•Sin embargo, recomienda la automatización para reducir costosoperativos de la seguridad (IDSs/IPSs y herramientas de análisis de logs).

Seguridad Informática – Logs y alertas

24

© 2007


Software maliciosoSoftware malicioso(3.1.4.6)

•Antivirus / Antispyware en las plataformas propensas a infección o tráfico (desktops, gateways de correo, etc).

•Programa de Concientización de usuarios. (charlas, carteleras, mails de alerta).

Seguridad Informática – Software malicioso

25

© 2007


El objetivo planteado es proteger físicamente los activos de información, que incluyen a:

•Personas (en primera instancia)

•Hardware

•Software

•Datos productivos

•Archivo (Papeles, backups, registros de seguridad, etc)

Seguridad Informática – Seguridad física

Seguridad físicaSeguridad física(3.2)

26

© 2007



Construcción y localización de Construcción y localización de instalacionesinstalaciones

(3.2.1)

•Destacable: el comunicado sugiere bajo perfil para la ubicación del centro de cómputos (recordar crisis de 2001). Esta medida puede reducir en gran medida el riesgo de “conmoción popular” en nuestro país.

27

© 2007



Acceso físico al centro de Acceso físico al centro de cómputoscómputos

(3.2.2)

•El control de acceso físico puede implementarse a través de un sistema automatizado, o bien manualmente (ej. través de un guardia).

•Es obligatorio el registro de las entradas al centro de cómputos (automatizadamente o manualmente).

28

© 2007


Continuidad del procesamiento Continuidad del procesamiento (y del negocio)(y del negocio)

(4)

Seguridad Informática – Continuidad del procesamiento

El BCP es un proyecto que requiere:El BCP es un proyecto que requiere:

•Compromiso por parte de la Dirección de la empresa para que sea efectivo y pueda ser desarrollado con éxito.

•Conciencia del tamaño del Proyecto.

•Inversiones (Hardware, Software, Lugar físico, Consultoría, Recursos humanos, Contratos, etc).

•ES UN PROYECTO DE NEGOCIOS, NO SÓLO TECNOLÓGICO.

• La A 4609 exige la implementación de un Business Continuity Plan (BCP).

29

© 2007



Componentes Metodológicos del BCPComponentes Metodológicos del BCP

30

© 2007



•Obtener recursos Presentar al Directorio o CEO la necesidad de elaborar el plan de recuperación con el fin de:

- mitigar los riesgos identificados en el Análisis de Riesgos,

- mitigar el “riesgo” de no cumplir con la normativa del BCRA,

- cumplir con las Políticas de Seguridad internas de la entidad.

•Asignar un área o sector encargado de crear, mantener y probar el BCP. Sugerencia: crear un Comité de coordinación con miembros del Directorio, Sistemas, Seguridad, Auditoría y Dueños de procesos.

Continuidad del procesamiento Continuidad del procesamiento Pasos NecesariosPasos Necesarios

(4.1)

31

© 2007


Pasos necesarios:

•Llevar a cabo un:


Análisis de Impacto al negocio Análisis de Impacto al negocio (BIA)(BIA)

- Se utiliza metodología standard. Ej: COBIT, NIST, Octave (CERT).

- Alcance Todos los procesos de negocio, no sólo los informáticos.

- Trabajo en equipo con los dueños de procesos.

- Objetivo final del análisis es determinar qué procesos son críticos, y para cada proceso crítico:

Punto de Recuperación (RPO)

Tiempo de Recuperación (RTO)

- Los resultados constituyen la base para la implementación de los mecanismos de continuidad.

(4.2)

32

© 2007


Pasos necesarios:

•Elaborar y documentar un


Plan de ContinuidadPlan de Continuidad- El plan debe basarse en el Análisis de Riesgos y en el de Impactos.

- Debe preveerse y enunciarse los posibles escenarios de desastreque activarían el plan (inundación, incendio, conmoción popular, etc).

- El BCP cubre las contingencias que se definan durante el desarrollo del mismo. Mientras más abarcativo sea el BCP, más costosa es su implementación y mantenimiento. Se debe llegar al Punto de Equilibrio y la empresa debe definir qué riesgos desea aceptar.

- El Plan deber prever las estrategias técnicas a implementar:

- ubicación del site alternativo.

- tipo de disponibilidad: cold site, warm site, hot site, mirroredsite.

(4.4)

33

© 2007



Contenidos mínimos del Plan de Contenidos mínimos del Plan de ContinuidadContinuidad

•“Procedimientos de emergencia que describan las acciones a emprender una vez ocurrido un incidente. Estos deben incluirdisposiciones 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 nombres, direcciones, números de teléfono y "localizadores" actuales 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.”

(4.4)

34

© 2007



Contenidos mínimos del Plan de Contenidos mínimos del Plan de ContinuidadContinuidad

•“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.

•Los procedimientos de emergencia que describan las acciones a emprender para el traslado de actividades esenciales a las ubicaciones transitorias alternativas, y para el restablecimiento de los procesos de negocio en los plazos requeridos.

•La inclusión de los planes de reconstrucción para la recuperación en la ubicación original de todos los sistemas y recursos.”

(4.4)

35

© 2007


Instalaciones alternativas de Instalaciones alternativas de procesamiento de datosprocesamiento de datos

(4.3)

•Es posible utilizar instalaciones propias o de terceros.

•Objetivos primarios que establece la norma:

- No estar alcanzado por los mismos riesgos que la instalación central (según el Análisis de Riesgos).

- Alojar y proveer disponibilidad a los sistemas críticos.

- Proveer servicios a sucursales Telecomunicaciones.

- Tiempo de Recuperación que no afecte la atención de los clientes ni deje a la entidad fuera de compensación.

- No estar alcanzado por eventos que pueden darse simultáneamente (ej inundación y corte de suministro eléctrico).


36

© 2007


Mantenimiento y actualización del Mantenimiento y actualización del BCPBCP

(4.5)

•Eficacia permanente del BCP Actualizacíón del Plan.

•Establecer y documentar procedimientos para actualizar el BCP con cada cambio en los sistemas y procesos de negocio.

•Asignar un responsable de actualización y revisión periódica.

•Si existen cambios en el BCP, la información le debe llegar a cada uno de los responsables involucrados en el mismo.


37

© 2007



Prueba del BCPPrueba del BCP(4.6)

•La A 4609 establece la prueba anual del BCP para verificar la efectividad del plan y de su mantenimiento.

•Las pruebas deben garantizar que todos los miembros del equipo de recuperación conocen sus funciones.

•Confeccionar un cronograma de pruebas definiendo el cómo y el cuándo para cada elemento del plan.

• Áreas usuarias y Auditoría deben ser los certificadores de los resultados de la prueba. Deben elevar un informe al Directorio o CEO con los resultados de la prueba.

•Este informe debe ser guardado en archivo ya que sería controlado por BCRA.

38

© 2007


Seguridad Informática – Inventario

Inventario tecnológicoInventario tecnológico(5.2)

•Si bien es responsabilidad del Área Sistemas/Informática la creación y mantenimiento del Inventario Tecnológico, es muy importante que el área de Seguridad lo controle y utilice.

•No es posible aplicar efectivamente controles de seguridad sobre recursos que no se encuentran registrados en ninguna parte.

•Elementos a ser inventariados: hardware, software, recursos de información, activos físicos y servicios descentralizados de terceros.

39

© 2007


•Debe realizarse un Análisis de Riesgos para cada uno de los canales y los servicios por ellos ofrecidos.

•Se debe garantizar confidencialidad, integridad y disponibilidad en el medio en que se transmiten los datos Uso de Encriptación standard.

• Debe aplicarse a estos medios todos los requerimientos de seguridad de la norma + la sección 6.

Seguridad Informática – Banca electrónica

Banca Electrónica por diversos Banca Electrónica por diversos mediosmedios

(6, 6.1)

40

© 2007


Control en cajeros automáticosControl en cajeros automáticos(ATMs)(ATMs)

(6.2)

Requerimientos de Seguridad:

(estas prácticas ya son aplicadas por los grandes administradores de cajeros):

•Identificación con tarjeta y clave.

•Encriptación y Control de Acceso en lugares de alojamiento.

•Control de Accesos en algoritmos de generación de claves.

•Separación de funciones en generación de tarjetas y claves.

•No visibilidad de claves o datos de tarjetas.

•No entrega simultánea de tarjeta y clave.


41

© 2007


Tarjetas de Débito y POSTarjetas de Débito y POS(6.3)

Requerimientos de Seguridad:

•Se debe requerir Documento de Identidad al usuario.

•Se debe requerir la clave al usuario y una firma en el ticket.

•Debe “permitir” una clave distinta para realizar compras.

•Restricción de operación luego de 3 intentos fallidos.


42

© 2007


ee--BankingBanking(6.4)

Canal con alto nivel de Canal con alto nivel de riesgoriesgo

•Proteger a la red interna con Firewalls, IDS (del tipo de red y de host en servidores) y antivirus.

•“Se valorizará que todo dispositivo de control de tráfico de red y de detección cuente con capacidad de registro de actividad. Dicho registro deberá evidenciar la realización de controles por los responsables designados para tal fin”.

•El e-Banking debe poseer las mismas medidas de seguridad física y lógica que el resto de la instalación expresada en la A 4609. Se “valorará” la incorporación de medidas adicionales según el riesgo.


43

© 2007



•La página debe enunciar claramente:

• La “política de seguridad con la que la entidad opera”. Ej, Terminos y Condiciones, Ley de Habeas Data, Comunicación A 4609, otras normas de seguridad del banco de conocimiento público.

• Ventana de tiempo de utilización e inactividad.

• Informar al usuario sobre no responsabilidad sobre links que guían a páginas externas.

•Se “valorizará” el uso de entidades certificadoras.

•El e-banking debe utilizar usuario/clave distintas a otros medios. Cómo mínimo debe respetar las exigencias de 3.1.4.2.


44

© 2007



•Se “valorizará” que los usuarios deban utilizar: certificados digitales, tarjetas inteligentes, dispositivos biométricos, teclados virtuales.

•El e-banking debe estar incluido en el BCP.

•Se “valorizará” la implementación de duplicación de componentes (Non stop service).

•En casos de Hosting o Housing el banco es responsable de exigir implementación y prueba por parte del ISP de planes de continuidad con especificaciones del punto 4 Incluir en SLAs.


45

© 2007


mm--Banking Banking (celulares como terminales)(celulares como terminales)

Canal con alto nivel de Canal con alto nivel de riesgoriesgo

•Debe contemplar los mismos requerimientos de seguridad del e-Banking del punto 6.4.


•Debe implementarse encriptación extremo a extremo.

•No deben existir gateways que realicen desencriptación-encriptación

(6.5)

WAP 1 NO

WAP 2 OK

46

© 2007


Phone BankingPhone Banking(6.6)

•Los operadores no deben conocer las claves de los usuarios utilización de IVRs.

•El usuario debe conocer su número de transacción.

•En caso de atención personalizada el usuario debe conocer con quien habló.

•Se “valorizará” la grabación de la comunicación.


47

© 2007


Otros medios / Futuros mediosOtros medios / Futuros medios(6.7)

•Se deberá informar al Directorio o CEO sobre los riesgos de la nueva tecnología para que el mismo tome las medidas de seguridadnecesarias.

•Se deberá remitir un informe con la descripción del proyecto a la Gerencia de Auditoría Externa de Sistemas de la Superintendencia de Entidades Financieras y Cambiarias con 90 días de antelación a su implementación.


48

© 2007


Delegación de Actividades Propias Delegación de Actividades Propias de la Entidad en Tercerosde la Entidad en Terceros

(7.2)

•Directorio-CEO Responsable máximo.

•Se requiere Análisis de Riesgos para la actividad a delegar.

•Se deben redactar políticas de seguridad acordes al riesgo, tamañoy complejidad de las tareas delegadas.

•El Directorio o CEO debe estar al tanto del riesgo y las políticas, y aprobar formalmente la delegación.

•Firmar contratos (o SLA) que incluyan servicios, responsabilidades y acuerdos sobre confidencialidad y no divulgación.

•La administración de las utilidades de seguridad se debe realizar con RRHH propios (remotamente o en las instalaciones del tercero).

Seguridad Informática – Terceros

49

© 2007


Delegación de Actividades Propias Delegación de Actividades Propias de la Entidad en Tercerosde la Entidad en Terceros

(7.6)

•Se debe normar sobre el plan de controles a ejecutar en las actividades delegadas.

•Se debe documentar todas las solicitudes de mejoras enviadas al proveedor en caso de incumplimientos.

•Debe existir un BCP para las actividades delegadas en terceros debe figurar en las Políticas y Normas.

•El proveedor debe contar con un BCP propio coherente con el nivel de riesgo de la entidad contratos / SLA.

•El BCP del proveedor debe ser probado anualmente, con resultados documentados y vigilados por la “gerencia”.

Seguridad Informática – Terceros

50

© 2007


Gracias por su atención!!!Gracias por su atención!!!

www.cybsec.com

Documents

Seguridad Informática y Continuidad de · PDF fileAnálisis de la Norma BCRA “A” 4609 Seguridad Informática y Continuidad de Procesamiento Módulo II: Fase Práctica Lic. Matías