2. Díaz Cuba, Harley

3. García Arias, Mariano

4. Guerrero Alfaro, Marco

7. CONTRASEÑADISPONIBILIDAD DEL SOFTWARE

9. CONTRASEÑASoftware Destinado Jefe de cada Área

10. DISPONIBILIDAD DEL SOFTWARE Software Manipulan Usuarios

11. CADUCACION DE LA CONTRASEÑA Y CAMBIO Software Password

12. Encriptar Software Software para encriptar: CryptoForge

13. Determinar Procedimientos para Controlar los Programas de Aplicación Adicionalmente a proteger sus programas de Aplicación como activos, es a menudo necesario establecer controles rígidos sobre las modificaciones a los programas, para estar seguros de que los cambios no causan daños accidentales o intencionados a los datos o a su uso no autorizado.

14. Implementación o Mantenimiento de Software AREA DE TI AREA DE DESARROLLO AREA DE REDES AREA DE SOPORTE CONTROL DE CALIDAD

16. Trámitedocumentario.

17. Rueda de negocios.1) ACTA DE INICIO DESIGNACION DEL EQUIPO DE DESARROLLO

18. 2) ACTA DE REQUERIMIENTO REUNIONES CON LOS USUARIOS IDENTIFICACION DE LA PLATAFORMA EN EL QUE SE DESARROLLARA EL SOFTWARE.

19. 3) ACTA DE CONTRUCCION FORMATOS DE DESARROLLO NTP Nro. 12277 DISEñO DE LA ARQUITECTURA - ESTRUCTURADA. - VISTA CONTROL. - P. EN CAPAS.

20. SISTEMA: ADMINISTRADOR DE LA INTRANET 1) Máster Page del sistema

21. 2) Arquitectura de la programación en capas

22. 3) Capa de Entidades (ejm: ClsArchivoEnt)

23. 4)Capa Lógica (ejm: ClsDocumentoLog)

24. 5) Capa de Acceso a Datos (ejm: ClsDoucmentoDat)

25. 6) UI – Interfaz de Usuario (ejm: adm_documentos.aspx)

26. 4) ACTA DE CONTROL DE CALIDAD PARTICIPANTES: - JEFE DE AREA DE TI - USUARIO LIDER - ENCARGADO DEL AREA DE CONTROL DE C. LOCACION: - SERVIDOR DE PRUEBAS.

27. 5) ACTA DE CIERRE O PASE A PRODUCCION SERVIDOR DE PRODUCCION. SOFTWARE / FECHA DE EJECUCION. MAUAL DE USUARIO. MANUAL DE INSTALACION.

28. PREPARAR PROCEDIMIENTOS DE CONTROL PARA EL USO DE LOS REPORTES

29. CASO: REPORTES DE BUSINESS INTELLIGENCE ACERCA DEL USO DE CAJEROS AUTOMATICOS.

33. Detrás de todos estos Reportes existen un conjuntos de Documentaciones, que se deben realizar como buenas practicas; dando claro alusión a los dominios del ISO 17799. Los reportes están supeditados al tipo de documento que son; por ejemplo tipo de reporte por estrategia.

34. PROCEDIMIENTOS DEFINIR CRITERIOS DE CONTROL DE DOCUMENTO CONTROL DE DOCUMENTOS INTERNOS ELABORACION DE REPORTES: IDENTIFICACION DE REPORTES: APROBACION DEL REPORTE: ACTUALIZACION DEL REPORTE: CONTROL DE DOCUMENTOS EXTERNOS Identificar los documentos externos aplicables. Mantener la última versión del documento. Distribuir a los usuarios que los necesiten.

35. CONTROL DE DOCUMENTOS INTERNOS: PROCEDIMIENTOS: ELABORACION DE REPORTES: IDENTIFICACION DE REPORTES: APROBACION DEL REPORTE: ACTUALIZACION DEL REPORTE:

36. ACTUALIZACION DEL REPORTE: En caso de que fuese necesaria la entrega de copia controlada de los documentos internos aprobados, el Encargado de la Distribución de cada Sistema, deberá llevar un control de dichos documentos, utilizando la planilla “Distribución de Documentos Internos” (ver Anexo 2). Para identificar y velar por los documentos relacionados con el SGC que se reciben físicamente en aquellas áreas donde no cuenten con intranet, cada área nombrará a un responsable que ocupará el cargo de Receptor de Documentos. Esta persona será la responsable de archivarlos, protegerlos del deterioro y facilitarlos para su uso.

39. CONTROL DE DOCUMENTOS EXTERNOS: Para el caso de los reportes del tipo de documentación externa, se da en casos (o situaciones) donde empresas clientes o asociadas, piden informes, reportes, análisis a otra organización a través del uso de BI también. Cada área elegirá el mejor método para revisar y mantener actualizados los documentos externos, dada la naturaleza y origen de los mismos. Sin embargo, al menos, se deberá tener presente las siguientes consideraciones: 1) Identificar los documentos externos aplicables. 2) Mantener la última versión del documento. 3) Distribuir a los usuarios que los necesiten.

41. ESTABLECER PROCEDIMIENTOS E INSTRUCCIONES PARA LOS OPERADORES DEL SISTEMA

42. INSTRUCCIONES DE TRABAJO: Son guías detalladas y escritas, que establecen el método de trabajo a seguir paso a paso para la realización de una tarea concreta o grupo de tareas desde su comienzo hasta su finalización, recogiendo los riesgos que existen en cada uno de los pasos y las medidas a adoptar para eliminarlos o reducirlos. PROCEDIMIENTOS DE TRABAJO: Son un conjunto de reglas escritas, más generales que las Instrucciones de trabajo, de obligado cumplimiento que marcan pautas de conducta laboral en la realización de tareas

43. INSTRUCCIÓN Y PROCEDIMIENTO DE TRABAJO ELABORACION 1.1 CODIGO 1.2 DENOMINACION Se indicará el trabajo que la Instrucción normaliza 1.3 SECUENCIA DEL TRABAJO 1.4 RIESGOS POTENCIALES 1.5 MEDIDAS A TOMAR

44. 2. APROBACION 3. DIFUSION Las Instrucciones han de ser comentadas con cada empleado por parte del Responsable de Área en el momento de su contratación o en un posible cambio de puesto. 4. REVISION

45. CASO PRACTICO

46. El 80% del downtime no planificado es causado por operaciones mal ejecutadas o aplicaciones mal administradas

47. USE RASTROS DE AUDITORÍAS O REGISTROS CRONOLÓGICOS (LOGS) DE TRANSACCIÓN COMO MEDIDAS DE SEGURIDAD.

48. Definición LOG es un registro oficial de eventos durante un rango de tiempo en particular

49. Importancia de un LOG La importancia de los LOGs es que te permite: La Recuperación ante incidentes de seguridad La Detección de comportamiento inusual Información para resolver problemas Evidencia legal

51. Los registros se almacenan de acuerdo a unaclasificación Desventajas • Se requiere de mas equipo.

52. CasoPráctico Tenemos una tabla en la base de datos, la cual no tiene campos de auditoria por la cual no se sabe que fecha se han registrado esos usuarios para cualquier evento no deseado que se pueda suscitar por parte de cualquiera de estos usuarios

53. CasoPráctico Donde: id_usuario: es el usuario que realiza la acción. acción: es la acción que se realiza, ya sea de loguear, actualizar, insertar, eliminar, etc. tabla: la tabla afectada tras la acción realizada por el usuario. fecha: la fecha en que se realizo la acción. hora: la hora en que se realizo la acción.

54. CONCLUSIONES Existen gran número de aplicaciones para empaquetar nuestro programa, hay bastantes gratuitos pero siempre hay que leerse las condiciones de uso. Conforme a la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco más fácil y así mismo mejor control para controlar nuestros cambios a nuestros datos. Generar data de auditoría en una base de datos es una ventaja y a la vez un problema ya que acarrea costos en espacio de almacenamiento y tiempo en manejarla. Pero aún así es necesaria en ciertas actividades, especialmente la financiera. Según la experiencia de Foundstone, la mayoría de las fallas de seguridad son causadas porque a los desarrolladores y a otras partes interesadas del ciclo de vida de desarrollo de software no les han dicho lo que deben y no deben hacer. Esto se logra de mejor manera mediante el uso de políticas y procedimientos.

55. RECOMENDACIONES Al momento de desarrollar un software se deben tener en cuenta los Estándares internacionales o nacionales para el uso de las buenas prácticas de desarrollo para tener la certeza de que nuestros aplicativos cumplan con los objetivos propuestos. La auditoría debería realizarse a ciertas tablas de una base de datos y no a todas, ya que complicaría aún más el proceso de administración. Las Organizaciones deben estar acorde en al ISO 17799, en cuanto al control del uso de reportes; y el Sector Bancario debe regirse a la Circular G140. Las empresas deben dar a conocer a sus empleados los procedimientos e instrucciones que ellos deben aplicar en el área en el cual se van a desenvolver dando a conocer también las sanciones si estos (procedimientos e instrucciones) no fuesen cumplidos.

56. GRACIAS….!!!