INDICE 17.1. AUDITORIA DE LA SEGURIDAD. 17.2. AREAS QUE PUEDE CUBRIR LA AUDITORIA DE LA SEGURIDAD 17.3. EVALUACION DE RIESGOS. 17.4.

FASES DE LA AUDITORIA DE SEGURIDAD 17.5. AUDITORIA DE LA SEGURIDAD FSICA. 17.6. AUDITORIA DE LA SEGURIDAD LOGICA. 17.7. AUDITORIA DE LA SEGURIDAD Y EL DESARROLLO DE APLICACIONES. 17.8. AUDITORIA DE SEGURIDAD EN EL AREA DE PRODUCCION. 17.9. AUDITORIA DE LA SEGURIDAD DE LOS DATOS. 17.10. AUDITORIA DE LA SEGURIDAD EN COMUNICACIONES Y REDES. 17.11. AUDITORIA DE LA CONTINUIDAD DE LAS OPERACIONES. 17.12. FUENTES DE LA AUDITORIA. 17.13. EL PERFIL DEL AUDITOR. 17.14. TECNICAS, METODOS Y HERRAMIENTAS 17.15. CONSIDERACIONES RESPECTO AL INFORME. 17.16. CONTRATACION DE AUDITORIA EXTERNA 17.17. RELACION DE AUDITORIA CON ADMINISTRACION DE SEGURIDAD. 17.18. CONCLUSIONES. 17.1 AUDITORIA DE LA SEGURIDAD INFORMTICA Introduccin Para muchos la seguridad sigue siendo el rea principal a auditoria, hasta el punto de que algunas identidades se creo inicialmente la funcin de auditoria informtica para revisar la seguridad, aunque despus se hayan ido ampliado los objetivos. La nueva denominacin abarca globalmente los sistemas de informacin: desde la aplicacin, el alimento con la estrategia de las entidades, hasta los sistemas de informacin y el aprovechamiento de la tecnologa de la informacin.

La expresin de seguridad informtica, que es la mas usada, puede llegar a relacionarse solo con los equipos y entornos tcnicos, como si la informacin en otros soportes y ambiente no requiera proteccin, cuando son las propias operaciones de la entidad, el negocio de la entidades con animo de lucro, lo que requiere proteccin. Sino existen medidas y adecuada proteccin se puede perder informacin vital, o por lo menos no estar disponibles en el momento requerido, las decisiones se tomadas pueden ser errneas, o se pueden incumplir contratos ala propia legislacin, lo que puede traducirse en grandes multas o infracciones graves, o alo que es aun peor: la inmovilizacin de ficheros previstos. Debe de evaluarse en la auditoria si los modelos de seguridad estn en consonancia con las nuevas arquitecturas, las distintas plataformas y las posibilidades de las comunicaciones. Los auditores somos en cierto modo los ojos y odos de la direccin que a menudo no puede, o no debe, como realizar las verificaciones o evaluaciones, el sistema de control interno ha de basarse en las polticas y se implementan con apoyo de herramientas, si bien encontramos a menudo en la auditoria que lo que existe es mas bien implementacin parcial de controles de acceso lgico a travs de paquetes o sistemas basados en el criterio de los tcnicos, pero no sus tentada con normativa, o bien habiendo partido estas de los propios tcnicos. Finalmente queremos indicar que siempre es muy importante la seguridad de todo el equipo informtico, sea o no una auditoria. 17.2 REAS QUE PUEDEN CUBRIR LA AUDITORIA DE LA SEGURIDAD Se incluyen las que con carcter general pueden formar partes de los objetivos de una revisin de la seguridad, si bien esta puede abarcar solo partes de ella si as se ha determinado ante mano. En una auditoria de otros aspectos y por tantos en otros captulos de esta misma obra pueden seguir revisiones solapadas con la seguridad; as, ala hora de revisar las operaciones de desarrollo, normalmente se vera si se realizan en un entorno seguro y protegido y lo mismo ala hora de revisar la exploracin, o el rea tcnica de sistemas, la informtica de usuario final, las bases de datos y en general cualquier rea. Las reas generales citadas, algunas de las cuales se aplican des pues son: Lo que hemos denominado controles directivos, es decir los fundamentos de seguridad: polticas, planes, funcionesetc. El desarrollo de las polticas. Amenazas fsicas externas. Control de accesos adecuados tanto fsicos como los denominados lgicos. Proteccin de datos lo que fije la LORTAD y su reglamento. Comunicaciones y redes: topologas y tipos de comunicaciones, proteccin antivirus. El entorno de produccin, entendido como tal explotacin mas tcnica de sistemas y con especial nfasis en el cumplimientos de contratos. El desarrollo de aplicaciones en un entorno seguro, y que se incorporen controles en los productos desarrollados y que estos resulten auditables. 2

No se tratan de ares no relacionadas, sino que todas tienen puntos de en laces y por partes comunes: comunicacin control de accesos, cifrados con comunicaciones y soportes, datos con soportes y con comunicaciones, explotacin con varias de ellas, y as en otros casos. 17.3 EVALUACION DE DE RIESGOS Retrata de identificar los riesgos, cuantificar su probabilidad de impacto, y analizar medidas que eliminen lo que generalmente no es posible o que desminuya la probabilidad de que o curran los hechos o que mitiguen el impacto. Para evaluar riesgos hay que considerar, entre otros factores, el tipo de informacin almacenada procesada y transmitida, la criticidad de las aplicaciones, la tecnologa usada, el marco legal aplicable, el sector de entidad, la entidad misma y el momento. Para ello es necesario evaluar las vulnerabilidades que existen, ya que la cadena de proteccin se podr romper con mayor probabilidad por los eslabones mas dbiles que sern los que preferentemente intentaran usar de forma no autorizada. La proteccin no ha de basarse solo en dispositivos y medios fsicos, sino en informacin he informacin adecuada del persona, empezando por la mentalizacin de los directivos para que, en cascada afecte a todos los niveles de la pirmide organizativa. El factor humano es el principal a considerar, salvo en algunas situaciones de proteccin fsicas muy automatizadas, ya que es muy critico: si las personas no quieren colaborar de poco sirven los medios y dispositivos aunque sean caro y sofisticados. Es necesario una separacin de funciones: es muy peligroso que una misma persona realice una transaccin, la autorice, y revise despus los resultados, por que esta persona podra planificar un fraude o cubrir cualquier anomala. En un proceso de auditoria Se evaluara todos estos aspectos y otros, por ejemplo si la seguridad es realmente una preocupacin corporativa no es suficiente que exista presupuestos para ello, es necesario una cultura de seguridad y as haya un comit que fije y apruebe los objetivos correspondiente y en medida se alcanzan, que modelo de seguridad quieren implementar. Si la entidad auditada esta en medio de un proceso de implementacin de la seguridad, la evaluacin se centrara en los objetivos, los planes, que proyectos hay en cursos y los medios usados o previstos. La evaluacin de riesgos puede ser global: todos los sistemas de informacin centro y plataformas, que puede equivaler a un chequeo medico en generadle un individuo y que es habitual la primera vez que se realiza, amenud en la auditoria externa se trata de saber si la entidad, atraves de funciones como administracin de la seguridad o auditoria interna u otras si no exitieranlas anteriores. Al hablar de seguridad siempre se habla de sus tres dimensiones clsicas y son las siguientes: La Confidencialidad: se cumple cuando solo las personas autorizadas pueden conocer los datos o la informacin correspondientes. La Integridad: consiste en que solo el usuario autorizados pueden variar los datos. Deben quedar pistas para control posterior y para auditoria. 3

La disponibilidad: se alcanza si las personas autorizadas pueden acceder a tiempo a la informacin a la que estn autorizadas. 17.4. FASES DE LA AUDITORIA DE SEGURIDAD Con carcter general pueden ser: Concrecin de los objetivos y de limitacin del alcance y profundidad de la auditoria, as como el periodo cubierto en su caso. Anlisis de posibles fuentes y recopilacin de informacin: en el caso de los internos este proceso puede no existir. Determinacin del plan de trabajo y de los recursos y plazos en casos necesarios, as como en la comunicacin en la entidad. Adaptacin de cuestionarios, y a veces consideracin de herramientas o perfiles de especialistas necesarios, sobretodo en la auditoria externa. Realizacin de entrevistas y pruebas. Anlisis de resultados y valoracin de riesgos. Presentacin y discusiones del informe provisional. Informe definitivo. 17.5. AUDITORIA DE LA SEGURIDAD FSICA Se evaluaran las protecciones fsicas de datos, programas instalaciones, equipos redes y soportes, y por supuesto habr que considerar a las personas, que estn protegidas y existan medidas de evacuacin, alarmas, salidas alternativas, as como que no estn expuestas a riesgos superiores a los considerados admisibles en la entidad e incluso en el sector. AMENAZAS Pueden ser muy diversas: sabotaje, vandalismo, terrorismo accidentes de distinto tipo, incendios, inundaciones, averas importantes, derrumbamientos, explosiones, as como otros que afectan alas personas y pueden impactar el funcionamiento de los centros, tales como errores, negligencias, huelgas, epidemias o intoxicaciones. PROTECCIONES FSICAS ALGUNOS ASPECTOS A CONSIDERAR: ubicacin del centro de procesos, de los servidores locales, y en general de cualquier elemento a proteger. Estructura, diseo, construccin y distribucin de los edificios y de sus platas. Riesgos a los accesos fsicos no controlados. Amenaza de fuego, problemas en el suministro elctrico. Evitar sustituciones o sustraccin de quipos, componentes, soportes magnticos, documentacin u otros 4

activos. 17.6. AUDITORIA DE LA SEGURIDAD LOGICA Es necesario verificar que cada usuario solo pude acceder a los recursos que sele autorice el propietario, aunque sea de forma genrica, segn su funcin, y con las posibilidades que el propietario haya fijado: lectura, modificacin, borrado, ejecucin, traslado a los sistemas lo que representaramos en una matriz de accesos. En cuanto a autenticacin, hasta tanto no se abaraten ms y generalicen los sistemas basados en la biomtrica, el mtodo ms usado es la contrasea, Cuyas caractersticas sern acordes con las normas y estndares de la entidad, que podran contemplar diferencias para segn que sistemas en funcin de la criticidad de los recursos accedidos. Aspectos a evaluar respecto a las contraseas pueden ser: Quien asigna la contrasea inicial y sucesivas. Longitud mnima y composicin de caracteres. Vigencia, incluso puede haberlas de un solo uso o dependientes de una funcin tiempo. Control para no asignar las x ultimas. Numero de intentos que se permiten al usuario. Controles existentes para evitar y detectar caballos de Troya. 17.7. AUDITORIA DE LA SEGURIDAD Y EL DESARROLLO DE APLICACIONES Todos los desarrollos deben estar autorizados a distinto nivel segn la importancia del desarrollo a abordar, incluso autorizados por un comit si los costes o los riesgos superan unos umbrales. REVISION DE PROGRAMAS Por parte de tcnicos independientes, o bien por auditores, preparados, a fin de determinar la ausencia de caballos de Troya, bombas lgicas y similares adems de la calidad. PROTECCION DE LOS PROGRAMAS A menos desde dos perspectivas, de los programas que sean propiedad de la entidad, realizados por e personal propio o contratado d e su desarrollo a terceros, como el uso adecuado de aquellos programas de los que se tenga licencia de uso. 17.8. AUDITORIA DE SEGURIDAD EN EL AREA DE PRODUCCION Las entidades han de cuidar especialmente las medidas de proteccin en el caso de contratacin de servicios: desde el posible marcado de datos, proceso, impresin de etiquetas, distribucin, acciones comerciales, gestin de cobros, hasta el outsourcing mas completo, sin descartar que en el contrato se provea la revisin por los auditores, internos o externos, de las instalaciones de la entidad que provee el servicio. Tambin debe realizarse la proteccin de utilidades o programas especialmente peligrosos, as como el control 5

de generacin y cambios posteriores de todo el software de sistemas, y de forma especial el de control de accesos. 17.9. AUDITORIA DE LA SEGURIDAD DE LOS DATOS La proteccin de los datos puede tener varios enfoques respecto a las caractersticas citadas: la confidencialidad, disponibilidad e integridad. Puede haber datos crticos en cuanto a su confidencialidad, como datos mdicos u otros especialmente sensibles para la LORTAD(sobre religin, sexo, raza) otros datos cuya criticidad viene dada por la disponibilidad: si se pierden o se pueden utilizar a tiempo pueden causar perjuicios graves y, en los casos mas extremos poner en peligro la comunidad de la entidad y finalmente otros datos crticos atendiendo a su integridad, especialmente cuando su perdida no puede detectarse fcilmente o una vez detectada no es fcil reconstruirlos. Desde el origen del dato, que puede ser dentro o fuera de la entidad, y puede incluir preparacin, autorizacin, incorporacin al sistema: por el cliente, por empleados, o bien ser captado por otra forma, y debe revisarse como se verifican los errores. Proceso de los datos: controles de validacin, integridad, almacenamiento: que existan copias suficientes, sincronizadas y protegidas. Salida de resultados: controles en transmisiones, en impresin, en distribucin. Retencin de la informacin y proteccin en funciona de su clasificacin: destruccin de los diferentes soportes que la contengan cuando ya no sea necesaria, o bien desmagnetizacin. Designacin de propietarios: clasificacin de los datos, restriccin de su uso para pruebas, inclusin de muescas para poder detectar usos no autorizados. Clasificacin de los datos e informacin: debe revisarse quien la ha realizado y segn que criterios y estndares; no suele ser prctico que haya mas de cuatro o cinco niveles. Clienteservidor: es necesario verificar los controles en varios puntos, y no solo en uno central como en otros sistemas, y a veces en plataformas heterogneas, con niveles y caractersticas de seguridad muy diferentes, y con posibilidad de transferencia de ficheros o de captacin y exportacin de datos que pueden perder sus protecciones al pasar de una plataforma a otra. 17.10. AUDITORIA DE LA SEGURIDAD EN COMUNICACIONES Y REDES En las polticas de entidad debe reconocerse que los sistemas, redes y mensajes transmitidos y procesados son propiedad de la entidad y no deben usarse para otros fines no autorizados, por seguridad y por productividad, talvez salvo emergencias concretas si all se ha especificado y mas bien para comunicaciones con voz. Los usuarios tendrn restriccin de accesos segn dominios, nicamente podrn cargar los programas autorizados, y solo podrn variar las configuraciones y componentes los tcnicos autorizados. Se revisaran especialmente las redes cuando existan repercusiones econmicas por que se trate de transferencia de fondos o comercio electrnico. Puntos a revisar: Tipos de redes y conexiones Tipos de transacciones.

 Tipos de terminales y protecciones: fsicas, lgicas, llamadas de retorno. Transferencia de ficheros y controles existentes. Consideracin especial respecto a las conexiones externas a travs de pasarelas (gateway)y encaminadotes(routers). Internet e Intranet: separacin de dominios e implantacin de medidas especiales, como normas y cortafuegos(firewall), y no solo en relacin con la seguridad sino por acceso no justificados por la funcin desempeada, como a paginas de ocio o erticas, por lo que pueden suponer para la productividad. Correo electrnico: tanto por privacidad y para evitar virus como para que el uso del correo sea adecuado y referido ala propia funcin, y no utilizado para fines particulares. Proteccin de programas: y tanto la prevencin del uso no autorizado de programas propiedad de la entidad o de los que tengan licencia de uso. Control sobre las paginas Web: quien puede modificarlo y desde donde, finalmente preocupan tambin los riesgos que pueden existir en el comercio electrnico. 17.11. AUDITORIA DE LA CONTINUIDAD DE LAS OPERACIONES. Es uno de los puntos que nunca se deberan pasar por alto en una auditoria de seguridad, por las consecuencias que puede tener el no haberlo revisado o haberlo hecho sin la suficiente profundidad: no basta con ver un manual cuyo titulo sea plan de contingencia o denominacin similar, sino que es imprescindible conocer si funcionaria con las garantas necesarias y cubrir los requerimientos en un tiempo inferior al fijado y con una duracin suficiente. En una auditoria de seguridad, las consecuencias que puede tener el no haberlo revisado o haberlo hecho sin la suficiente profundidad: no basta con ver un manual cuyo titulo sea plan de contingencia o denominacin similar, sino que es imprescindible conocer si funcionaria con las garantas necesarias y cubrira los requerimientos en un tiempo inferior al fijado y con una duracin suficiente. PLAN DE CONTINGENCIA O PLAN DE CONTINUIDAD Frente a otras denominaciones que en principio descartamos como Recuperacin de Desastres o Plan de Desastres ( si nos parece adecuada Plan de Recuperacin ante desastres , pero las incidencias a prever son tambin de otros niveles). En la auditoria es necesario revisar si existe tal plan, completo y actualizado, si cubre los diferentes procesos, reas y plataformas, si existen planes diferentes segn entornos, evaluar en todo caso su idoneidad, los resultados de las pruebas que se hayan realizado, y si permiten garantizar razonablemente que en caso necesario y a travs de los medios alternativos, propios o contratados, podra permitir la reanudacin de las operaciones en un tiempo inferior al fijado por los responsables del uso de las aplicaciones, que a veces son tambin los propietarios de las mismas pero podran no serlo. Si las revisiones no nos aportan garantas suficientes debemos sugerir pruebas complementarias o hacerlo constar en el informe, incluso indicarlo en el apartado de limitaciones. Es necesario verificar que la solucin adoptada es adecuada; centro propio, ajeno compartido o no..y que existe el oportuno contrato si hay participacin de otras entidades aunque sean del mismo grupo o sector. NO esta de mas revisar si en el caso de una incidencia que afectara a varias entidades geogrficamente prximas la solucin prevista dara el servicio previsto a la auditada. Un punto fundamental en la revisin es la existencia de copias actualizadas de los recursos vitales en un lugar 7

distante y en condiciones adecuadas tanto fsicas como de proteccin en cuanto a accesos; entre dichos recursos estarn: bases de datos y ficheros, programas (mejor si existen tambin en versin fuente), JCL (Job Control lenguaje) o el equivalente en cada sistema, la documentacin necesaria, formularios crticos y consumibles o garantas de que se serviran a tiempo, documentacin, manuales tcnicos, direcciones y telfonos, los recursos de comunicaciones necesarios; datos y voz cualesquiera otros requeridos para funcionar con garantas. Otros aspectos que hemos encontrado como debilidades a veces debilidades a veces son: que exista copia del propio plan fuera de las instalaciones primarias, que est previsto ejecutar determinado software en un equipo alternativo, con identificacin especifica diferente de la del equipo que es el inicialmente autorizado; y que se tenga copia accesible del contrato, tanto para demostrar algo al proveedor como para verificar los trminos pactados. Es necesario en la auditoria conocer las caractersticas del centro o sistema alternativo, y debe revisarse si la capacidad de proceso, la de comunicacin y la de almacenamiento del sistema alternativo son suficientes, as como las medidas de proteccin. Debe existir un manual completo y exhaustivo relacionado con la continuidad en el que se contemplen diferentes tipos de incidencias y a que nivel se puede decidir que se trata de una contingencia y de que tipo. 17.12. FUENTES DE LA AUDITORIA. Las fuentes estarn relacionadas con los objetivos, y entre ellas pueden estar: Polticas, estndares, normas y procedimientos. Planes de seguridad. Contratos, plizas de seguros. Organigrama y descripcin de funciones. Documentacin de aplicaciones. Descripcin de dispositivos relacionados con la seguridad. Manuales tcnicos de sistemas operativos o de herramientas. Inventarios: de soportes, de aplicaciones. Topologas de redes. Planos de instalaciones. Registros: de problemas, de cambios, de vistas, de accesos lgicos producidos. Entrevistas a diferentes niveles. Ficheros. Programas.

 La observacin no figura en los manuales para la consideramos importante. Actas de reuniones relacionadas. Documentacin de planes de continuidad y sus pruebas. Informes de suministradores o consumidores. 17.13. EL PERFIL DEL AUDITOR. El perfil que se requiere para llevar a cabo auditorias de sistemas de informacin no esta regulado, pero es evidente que son necesarias una formacin y sobre todo una experiencia acordes con la funcin, e incluso con las reas a auditar seguridad fsica, sistemas operativos concretos, determinamos gestores de bases de datos o plataformas, e incluso lenguajes si hubiera que llegar a revisar programas, adems de ser imprescindibles en el perfil otras caractersticas o circunstancias comunes, como independencia respecto a los auditados, madurez, capacidad de anlisis y de sntesis, e intereses no meramente econmico. En el seno de la citada ISACA existe un certificado relacionado: CISA (Certified Information Systems Auditor). A la hora de crear la funcin de auditoria interna de sistemas de informacin se suele plantear si se forma a auditores ya expertos en otras reas: auditoria de cuentas normalmente, o si se forma a tcnicos del rea de informtica, o si se contrata a auditores de otra entidad, ya experimentados; cada opcin tiene sus ventajas e inconvenientes, entre los que se pueden estar: Los auditores de otras reas sern expertos en tcnicas generales como entrevistas, y en redactar informes, pero desconocern las particularidades y riesgos de las tecnologas de la informacin. Los informticos y expertos en reas relacionadas, no sern expertos en tcnicas generales y en control (salvo que provengan de administracin de seguridad), puede ser mas fcil aprendan estos aspectos que ensear, y especialmente mantener al da a un auditor general respecto a novedades tecnolgicas. Quien venga de otra entidad puede no tener ni unos inconvenientes ni otros, e incluso puede conocer el sector, y hay una ventaja mas: no conoce a las personas que tendr que entrevistar, lo cual es positivo, pero no siempre se quieren incorporar recursos externos. QU PUEDEN/DEBEN HACER LOS AUDITORES Ser independientes y objetivos. Recomendar. Ser competentes en la materia (seguridad). Basar sus informes en verificaciones y evidencias. Verificar que se evalan peridicamente riesgos o bien evaluarlos. Conocer perfiles de usuarios. Conocer criterios y prcticas sobre contraseas. Verificar que las aplicaciones se desarrollan y QU NO DEBEN HACER LOS AUDITORES Actuar en beneficio propio por encima del inters del cliente. Obligar, forzar, amenazar. Asumir encargos para los que no estn preparados. Basarlos en suposiciones. Revisar la seguridad da a da o administrarla (son funciones de otros). Realizar gestin perfiles de usuarios. Gestin/asignacin contraseas o conocerlas. Realizar funciones de anlisis o gestionar proyectos.

Escribir procedimientos. Aceptar presiones de sus jefes o clientes y que el informe no sea veraz. Garantizar que no se puedan realizar/haber realizado Evaluar riesgos e informes. delitos, fraudes o errores. Sustentar riesgos e informes. Enzarzarse en discusiones de diferencias de opiniones. Estar al da en cuanto a avances, riesgos, Auditar con tcnicas, mtodos o recomendaciones metodologas. obsoletos. 17.14. TECNICAS, METODOS Y HERRAMIENTAS En cada proceso de auditoria se fijan los objetivos, mbito y profundidad, lo que sirve para la planificacin y para la consideracin de las fuentes, segn los objetivos, as como de las tcnicas, mtodos y herramientas mas adecuados. El factor sorpresa puede llegar a ser necesario en las revisiones, segn lo que se quiera verificar. Como mtodos y tcnicas podemos considerar los cuestionarios, las entrevistas, la observacin, los muestreos, las CAAT (Computer Aided Auditing Techniques), las utilidades y programas, los paquetes especficos, las pruebas, la simulacin en paralelo con datos reales y programas de auditor o la revisin de programas. 17.15. CONSIDERACIONES RESPECTO AL INFORME. En el se harn constar los antecedentes y los objetivos, para que quienes lean el informe puedan verificar que ha habido una comunicaron adecuada, as como que metodologa de evaluacin de riesgos y estndares se ha utilizado, y una breve descripcin de los entornos revisados para que se pueda verificar que se han revisado todas las plataformas y sistemas objeto de la auditoria. Debe de incluirse un Resumen para la Direccin en trminos no tcnicos. Dependiendo de los casos ser preferible agrupar aspectos similares; seguridad fsica, seguridad lgica.o bien clasificar los puntos por centros o redes, especialmente en entidades grandes si existen responsables diferentes: en caso de duda ser un punto a comentar previamente con quienes van a recibir el informe, ya que con frecuencia prefieren entregar a cada uno la parte que mas le afecte, as como planificar y controlar rea por rea o por departamentos la implantacin de medidas. Cada punto que se incluya debe explicarse porque es un incumplimiento o una debilidad, as como alguna recomendacin, a veces abarcando varios puntos. El informe ha de ser necesariamente revisado por los auditados, as como discutido si es necesario antes de emitir el definitivo. En muchos casos, bien en el propio informe o en otro documento, se recogen las respuestas de los auditados, sobre todo cuando la auditoria es interna. La entidad decide que acciones tomar a partir del informe, y en el caso de los auditadotes internos estos suelen hacer tambin un seguimiento de las implantaciones. 10

mantienen segn normas y se incorporan controles. Revisar modificacin de programas (seguridad y calidad) y las pruebas realizadas, o bien probarlos. Verificar que siguen los procedimientos. Responsabilizarse del contenido de sus informes.

Codificar programas.

Los auditados siempre buscan un informe lo mas benigno posible, mientras que los auditadotes nos proponemos llegar a un informe veraz y til; estos diferentes puntos de vista a veces crean conflictos en el proceso de auditoria y en la discusin del informe. En algunos casos los informes se han usado para comparar la seguridad de diferentes delegaciones, sucursales, o empresas de un mismo grupo, o bien filiales de una multinacional, pero si los entornos no son homogneos las comparaciones pueden no ser muy tiles y llegar a distorsionar. 17.16. CONTRATACION DE AUDITORIA EXTERNA Algunas consideraciones pueden ser: La entidad auditora ha de ser independiente de la auditada en el caso de una auditoria externa: si esta ofreciendo otros servicios a la vez, o piensa ofrecerlos en el futuro, o incluso a veces si ha sido proveedora en el pasado, a menudo puede encontrar dificultades internas para entregar un informe veraz y completo. En ocasiones los propios auditores lo han llegado a comunicar, por tica. Las personas que vayan a realizar un trabajo han de ser independientes y competentes, segn el objetivo: sistemas operativos o plataformas concretas, por lo que no esta de mas examinar sus perfiles e incluso mantener alguna entrevista, sin descartar preguntar por sorpresa en una reunin que aspectos revisaran y que tcnicas usaran en el entorno que se les describa. No es tan comn pedir referencias de otros trabajos similares como en el caso de consultora pero se puede hacer, aunque para ello los auditores debieran pedir permiso previo a sus clientes. La auditoria ha de encargarse a un nivel suficiente, normalmente Direccin General o Consejero Delegado, y a este nivel recibir los informes, porque si no a veces no se cuenta con el respaldo suficiente en las revisiones, y se ha perdido el dinero y a veces la oportunidad. Finalmente, a titulo de curiosidad, en una ocasin se nos pidi que no figurara la palabra auditoria en el informe final, porque haba aversin por el trmino, por asociarse en la entidad a los auditores con los verdugos: no es un caso aislado y es impropio. Recordemos que puede ser necesario dar a mostrar a los auditores todo lo que necesiten para realizar su trabajo, pero nada mas, e incluso lo que se les muestre o a lo que se les permita acceder puede ser con restricciones: solo parte de una base de datos, epgrafes de algunas actas, o simplemente mostrarles documentacin, que no pueden copiar o no pueden sacar de las instalaciones del cliente: se puede exigir una clusula de confidencialidad, y raramente se les deben mostrar datos reales confidenciales de clientes, proveedores, empleado u otros, aunque se haga en la prctica con frecuencia. En caso de duda o de conflicto puede decidir un comit de auditora o el propio de Direccin. 17.17. RELACION DE AUDITORIA CON ADMINISTRACION DE SEGURIDAD. Hemos encontrado en mas de una ocasin que la misma persona tenia las funciones de administracin de seguridad y auditoria (informtica) interna, lo cual puede parecer bien a efectos de productividad, pero no es admisible respecto a segregacin de funciones, siendo preferible, si la entidad no justifica que dos personas cumplan en exclusiva ambas funciones, que se cubra solo una, o bien que la persona realice otras funciones complementarias pero compatibles, como ser algunas relacionadas con calidad. 11

En entidades grandes la funcin consta adems de corresponsales funcionales o autonmicos. FUNCION DE ADMINISTRACION DE SEGURIDAD Ser interlocutora en los procesos de auditoria de seguridad, si bien los auditores no podemos perder muestra necesaria independencia, ya que debemos evaluar el desempeo de la funcin de administracin de seguridad, desde si sus funciones son adecuadas y estn respaldadas por algn documento aprobado a un nivel suficiente, hasta el cumplimiento de esas funciones y si no hay conflicto con otras. La funcin de auditoria de sistemas de informacin y la de administracin de seguridad pueden ser complementarias, si bien sin perder su independencia: se trata de funciones que contribuyen a una mayor y mejor proteccin, y resultan como anillos protectores, como se muestra en la figura. Ambas funciones han de mantener contactos peridicos y prestarse cierta asistencia tcnica. Normalmente Administracin de seguridad habr de implantar las recomendaciones de los auditores una vez fijadas las prioridades por la Direccin de la entidad. Administracin de Seguridad puede depender del rea de Sistemas de Informacin, sobre todo si existe Auditoria de S.I. interna, pero si puede estar en peligro su desempeo quiz sea preferible que tenga otra dependencia superior, o al menos una dependencia funcional de reas usuarias como puede ser de direccin de Operaciones o similar; la existencia de un comit de Seguridad de la Informacin, o bien de una funcin de Seguridad Corporativa puede resultar til. En ocasiones los administradores de seguridad tienen casi exclusivamente una funcin importante pero que solo forma una parte de su cometido: la administracin del paquete de control de accesos: RACF, Top SEcret, u otros, con frecuencia por haber sido tcnicos de sistemas, y en ocasiones porque siguen sindolo, lo que representa una gran vulnerabilidad y no siempre bien aceptada cuando la hemos recogido en los informes de auditoria. 17.18. CONCLUSIONES. Aunque las implantaciones de la seguridad van siendo ms sofisticados y llegando a reas o aspectos casi desconocidos hace aos, esto no implica que estn plenamente resueltos lo mas bsicos: encontramos bastantes deficiencias en controles fsicos, no tanto porque no existan cuanto por las brechas o descuidos que se pueden encontrar. La auditoria en sistemas de informacin no esta suficientemente implantada en la mayora de las entidades espaolas, si bien supondra una mayor garanta de que las cosas se hacen bien y como la entidad quiere: en general hay coincidencia entre ambos puntos. Como funcin aporta al auditor un conocimiento privilegiado del rea de Sistemas de Informacin con una perspectiva muy amplia. La forma de realizar el trabajo va variando y se esta llegando a aplicar el control por excepcin y la teleauditora. En cuanto a nuevas reas, surge el auge del comercio electrnico, el control de paginas WEB: la revisin de quien autoriza, vara y controla los contenidos: en las entidades por seguridad y productividad, y en los hogares, aunque esto se sale de la auditoria y queda en el control para evitar que los menores accedan a contenidos con violencia o pornografa.

12

BIBLIOGRAFA: Auditoria en informtica un enfoque practico. Mario G. piattini, Emilio del peso Edit. Computec. ENTORNO PROTEGIDO

13