V*

Capitulo 1

CONTROL INTERNO Y AUDITORIA DESISTEMAS DE INFORMACION

Gloria Sinchez Valriberas

1.1 INTRODUCCIONLa information que es tratada en una organization es un recurso critico que

deberia ser protegido, ya que la misma es la base de la mayoria de las decislonesque son adoptadas a lo largo del tiempo.

Para lener una seguridad razonable sobre si la information es exacta ycompleta, estar disponible cuando se necesita y ser confidential, la implementationde controles intemos infonnaticos es necesario y ademas ayudan a cumplir con lasexigencias legales en materias de Derecho Informatico y a asegurar que lossislemas automaticos de procesamiento de la informacion fiincionan de acuerdo alo que se espera de ellos.

Los esc&ndaios contables de principios de la decada ban provocado unaumento en la sensibilizacion, tanto de los reguladores como de las organizaciones(publicas y privadas) por el control intemo. La existencia de una nueva normativaal Tespecto (por ejemplo, la Saibannes Oxley Act, el informe COSO...), lasnecesidades de transparencia en la gestion como un activo mas de lasorganizaciones o la busqueda de la eficiencia en los procesos intemos ban actuadodurante los ultimos afios como catalizadores para la mejora de los mecanismos decontrol intemo en las organizaciones. '

4 AL'DtTQRiA D TECNQLOOiAS Y SISTF.MAS DE iNFQRMACiON RA-MA

Entramos asi en una fase de tnadurez tie las organrzacicnes, en las que lamejora de la eficiencia y el control de sus actividades cotnlenzan a ser una de iasnecesidades basicas.

Dentro de las diferentes actividades que componen la estrategia de controlinterno de las organizaciones, ei control sobre la gestion de los sistemas deinformacion dia a dia adquiere una mayor relevancia. Para ello podemos encontrar,de rnanera inmediata, algunas razones:

La creciente dependencia de las organizaciones y sus procesos (tantointemos como externos) respecto a sus sistemas de informacion.

9

Derivado de lo anterior, el aumento de la cornplejidad de los mismos,con entomos heterogeneos y abteuos, a la vez que integrados.

Ei exito de las estrategias de extemalizacidn de la gestidn de lossistemas de mformacion, coil los que la dependencia de los sistemas deinformacidn se refuerza con la dependencia de uno o variosproveedores de servicio.

La globalization.

La gestion de la calidad total (TQM- Total Quality Management).Prueba de la mayor importancia que el control sobre la gestion de los

sistemas de informacion gana dia a dia es el hecho de que, por ejemplo, lanormativa europea de autosizacidn de organismos pagadores dcline, como uno desus cuatro grandes crjterios de autorizacion, el del fomemo del uso de los sistemasde informacidn como soporte a todos sus procesos y ei del establecimiento de unSistema Integrado de Gestion de la Seguridad (SGSI), que no es mas que el reflejodel aumento del nivel de control sobre los Sistemas de Informacion.

Asi mismo se incorpora a las Organizaciones la luncion de auditonainfocmatici iniciaimente como apoyo a la auditona financiera y posteriormente,surgen nuevas funciones en cuyos principals impulsores, podemos encontrar:

* Los reguladores, que empezaron a generar normativa espectficaapiicable sobre los Sistemas de mformacion de las organizaciones y susprocesos de gestion. Los ejemplos m&s conocidos son la Ley Organicade Proteccion de Datos (LOPD en adelante en este documento),pendiente de desarrollo, estando subsistente el Reglamento de Medidasde Seguridad recogido en el Real Decreto 994/1999, que desarrollaba

c RA-MACAPiTCLO I. CONTROL INTERNO Y AUD1TORIA DE SiSTEMAS DE MFORMACION 5

la anterior Ley de Proteccion de Datos conocida como LORTAD, o laLey de Servicios de la Sociedad de la Informacion y de ComercioElectromco (LSS1), que ha sido eiaborada por la Secretaria de Estadode Telecomunicaciones y para la Sociedad de la Informacion delMinisterio de Ciencia y Tecnologia, en cumplimiento de lo dispuestoen el articulo 33 de la citada Ley.

* Los sistemas de comercio eiectrdnieo, tanto entre organizaciones(B2B), como orientada a clientes finales (B2Q, que han impulsado !amejora de los procesos de comerciahzacion de productos pero a la vezhan abierto la puerta a nuevos riesgos derivados de la necesidad de"abrir" los sistemas de informacion de las organizaciones a terceros.

* 1 aumento de la cornplejidad de los sistemas de informacion y ladependencia de las organizaciones respecto a los mismos.

1.2 LAS FUNCIONES 0E CONTROL INTERNO YAUOITORiA INFORMATICOS

1.2.1 Control Interno Informatico *EI Control Interno Informatico controla diariamente que todas las

actividades de sistemas de informacidn sean realizadas cumpliendo losprocedimientos, estandares y normas fijados por la Direction de la Organizationy/o la Direccidn de Informatica, asi como los requerimientos legales.

La mision del Control Interno Informatico es asegurarse de que lasmedidas que se obtienen de los mecartismos implantados por cada responsable seancorrectas y vdlidas.

Control Interno Informitico suele ser un drgano staff de la Direccion de!Departamento de Informatics y esta dotado de las personas y rnedios materialesproportionados a los cometidos que se le encomienden.

Como principals objetivos podemos indicar los siguientes:

* Controlar que todas las actividades se realizan cumpliendo losprocedimientos y normas fijados, evaluar su bondad y asegurarse de!cumplimiento de ias normas legales.

Asesorar sobre el conocimiento de las normas.

6 AUDHORIA PE TECNOLOGIAS Y SISTEMAS DE INFORMACION RA-MA

Coiaborar y apoyar el trabajo de Auditona Informatica, asi como de lasauditorias extemas al Grupo.

Definir, implantar y ejecutar mecanismos y controles para comprobarel logro de los grados adecuados del servicio informatico, lo cual nodebe considerarse como que la implantacion de los mecanismos demedida y la responsabilidad del logro de esos niveles se ubiqueexclusivamente en la funcion de Control Interno, sino que cadaresponsable de objetivos y recursos es responsable de esos niveles, aslcomo de la implantacion de los medios de medida adecuados.

Realizar en los diferentes sistemas (cenTrales, departamentales, redeslocales, PC, etc.) y entornos informaticos (produccion, desarrollo o pruebas) elcontrol de las diferentes actividades operativas sobre:

F.i cumplimiento de procedimientos, norm as y controles dictados.Merece resaltarse la vigilancia sobre el control de cambios y versiones

Controles sobre la produccidn diaria. Controles sobre la calidad y eficiencia del desarrollo y mantenimiento

del software y del servicio informatico.

Controles en las redes de comunicaciones.

Controles sobre el software de base. .

Controles en los sistemas microinformaticos. La seguridad informatica (su responsabilidad puede estar asignada a

control intemo o bien puede asignarsele la responsabilidad de controldual de la misma cuando esta encargada a otro organo):

o Usuarios, responsables y per files de uso de archivos y bases dedatos.

o Normas de seguridad.

o Control de informacion clasificada.

o Control dual de la seguridad informatica.

RA-MA CAPlTULO I. CONTROL INTERNO V AUD'TORIA DE SISTEMAS DE INFORMACION 7

Licencias y relaciones contractual con terceros. Asesorar y transmitir cultura sobre el riesgo informatico.

1.2.2 Auditona InformaticaLa Auditona Informatica es el proceso de recoger, agrupar y evaluar

evi'dencias parar determinar si un sistema informatizado salvaguarda los activos,mantiene la integridad de los datos, lleva a cabo eficazmente los fines de laorganizacion y utiliza eficientemente los recursos. De este modo la auditonainformatica sustenta y confirma la consecucion de los objetivos tradicionales de laauditona:

Objetivos de proteccion de activos e integridad de datos.

Objetivos de gestion que abarcan, no solaroente los de proteccion deactivos, sino tambien los de eficaciay eficiencia.

El auditor evalua y comprueba en determinados momentos de! tiempo loscontroles y procedimientos informativos mas compiejos, desarrollando y aplicandotecnicas mecanizadas de auditona, incluyendo el uso del software. En muchoscasos, ya no es posible veriftcar manualmente los procedimientos informatizadosque resumen, calculan y clasifican datos, por lo que se debera emplear software deauditona y otras tecnicas por ordenador.

El auditor es responsable de revisar e informar a la Direccion de laOrganizacion sobre el diseno y el funcionamiento de los controles irnpiantados ysobre la fiabilidad de la informacion suministrada.

Se pueden establecer tres grupos de funciones a realizar por un auditorinformatico:

Participar en las revisiones durante y despues del diseno, realizacidn,implantacion y explotacion de aplicaciones informativas, asi como enlas fases andlogas de realizacidn de cambios importantes.

Revisar yjuzgar los controles irnpiantados en los sistemas informativospara verificar su adecuacion a las ordenes e instrucciones de laDireccion, requisitos legales, proteccion de confidencialidad ycobertura ante errores y ftaudes.

8 AUBITORjA DE TECNOLOGtAS Y StSTEMAS DE INFORMAUON RA-MA

Revisar y juzgar el nivel de efieacia, utilidad, fiabilidad y seguridad delos equipos e information.

1.2.3 Control interne y auditoria informaticos: caraposanalogosLa evolution de ambas funciones ha sido espectacuiar durante la ultima

decada. Muchos controles internos fueron una vez auditores. De hecho, muchos delos actuales responsables de Control Interno Informdtico recibieron formation enseguridad informatica tras su paso por la formacidn en auditoria. Numerososauditores se pasan al campo de Control Interno In^rmatico debido a Ja similitud delos objetivos profesionales de control y auditoria, campos analogos que propicianuna transition natural.

Aunque ambas figuras tienen objetivos eomunes, existen diferencias queconviene matizar (vease figura 1.1).

IT'- ri'f..

SIMILITUDES

Personal intemo. .Conocimientos especializados en Tecnologia de la Information.Verification del cuinplimiftnto de controles internos, normativa yprocedimientos establecidos por la Direction de Informatica y laDirection General para los sistemas de information.

DIFERENCIAS

1

Analisis de los controles en e! dia adia.Infomia a la Direction delDepanamento de informdtica.S61o personal interno. .El alcance de sus funciones eslinicamente sobre el Departamentode Informatica.

Analisis de un mementoinformitico determinado.fnforma a la DirectionGeneral de la Organization.Personal interno y/o extemo.Tiene cobertura sobre todos1 los componentes de lossistemas de information de laOrganizacidn.

Figura 1,! Similitudes y diferencias. entre control interno y auditoria informaticos

S RA-MA CAPiTU'LO I. CONTROL INTERNO Y AUDiTORiA DE SISTEMAS DE INFORMAC1QN9

1.3 SlSTEMA 0E CONTROL INTERNO INFORMATICO

1.3.1 Defmicion y tipos de controles internosSe puede defmir el control interno como "cualquier actividad o action

manual y/o automaticamente jsara prevenir, corregir errores oafectarTTfuncionarniento de urTsTsterna para conseguir

Los controles cuando se diseften, desarrollen e implanten Kan de sef~aHmenos completes, simples, fiables, revisables, adecuados y rentables. Respecto aesto ultimo habra que nnalizac el coste-riesgo de su implantation.

Los controles internos que se utilizan en el entorno informatico continuanevolucionando hoy en dia a medida que los sistemas informaticos se vuelvencomplejos. Los progresos qqe se producen eri la tecnologta de soportes flsicos y desoftware han modificado de manera significative los procedimientos que seempleaban tradicionalmente para controlar los procesos de aplicaciones y paragestionar los sistemas de informacidn.

Para asegurar la integridad, disponibilidad y efieacia de los sistemas serequieren*^cOrnpiejos mecanismo.s de control, la mayoria de los cuales sonautomaticos. Resulfa interesante observar, sin embargo, que hasta en los sistemasservidor/cliente avanzados, aunque algunos controles son completamenteautomaticos, otros son completamente manuales, y muchos dependen de unacombination de eiementos de software y de procedimientos

Hisldricamente, los objetivos de los controles informaticos se banclasificados en las siguiemes categorias:

Controles preventives: para tratar de evitar e! hecho, como un softwarede seguridad que impida los accesos no autorizados al sistema.

Controles detectives: cuando fallan los preventivos para tratar deconocer cuanto antes el eyersto. Por ejemplo, el registro de interims deaccesos no autorizados, el registro de la actividad diaria para detectarerrores u omisiones, etc.

Controles correctivos: facilitan la vuelta a la normaJidad cuando se hanproducido incidencias. Por ejemplo, la recuperacidn de un ficherodanado apartir de las copias de seguridad.

10 AUDiTOR'A DE TbCNOLOGIAS Y SISTEMAS DE fNFORMACiON RA-MA

Como el concepto de controles se origino en la profesion de auditoria,resulta importante conocer la relation que existe entre los metodos de control, losobjetivos de control y ios objetivos de auditoria. Se trata de un tema diftcil por elhecho de que, bistdricamente, cada metodo de control ha estado asociadoumvocamente con un objetivo de control (por ejemplo, la seguridad de ficheros dedatos se conseguia sencillamenie manteniendo la sala de ordenadores cerrada conHave).

Sin embargo, a medida que los sistemas informaticos se han vuelto mascomplcjos, los controles informaticos han evolucionado hasta convertirse enprocesos integrados en los que se atenuan las diferencias entre las categoriastradicionales de controles informaticos. *

Por ejemplo, en los actuates sistemas intorrriaticos puede resultar dificil verla difercncia entre seguridad de los programas, de los datos y objetivos de controldel software del sistema, porque el mismo grupo de mdtodos de control satisfececasi totalmente los tres objetivos de control RA-MA

COBiT

. COBlT (Control Objectives for Information and Related Technology) es unmodelo/conjunto estructurado de buenas practicas y metodologi'as para suaplicaclon, cuyo objetivo es facilitar ei gobiemo de TL "

Ei Information Technology Governance Institute5 publicb recientemente !aedicion 4.0 de COBIT. Esta nueva edicibn enfatiza el cumplimiento de norm as ylegislacidn, sin invalidar los conceptos fundamentals de las versiones anteriores.Esta edicion 4.0, reaiizada como una actuaiizacion para reflejar el estado del arteen los temas del gobiemo de la tecnologia de la informacion (TI), incluyefundamentalmente mejoras y avances en esta actitidad, al mismo tiempo que tieneen cuenta un criterio de practicidad y facilidad para su implementacion.

COBiT apoya y sustenta el gobiemo de Tl, proporcionando un marco dereferenda que asegure que: ...... "

La tecnologia de la informacion esta alineada con el negocio,contribuyendo, al mismo tiempo, a la maximizacion de los beneficios.

Los recuxsos de TI (bumanos y tdcnicos) son utilizados de formaresponsible.

Los riesgos de TI son gestionados y dirigidos adecuadamente.Es decir, que primero se tiene en cuenta la actividad de una entidad, sus

objetivos, los riesgos y sus recursos y a partir de este conocimiento se puedenestablecer los objetivos de control que se quieren alcanzar.

La gran ventaja es que COBlT entiende a la tecnologia de la informacioncomo un TODO de servicio (entendiendo el servicio como un activo), y no deforma parcia!.

Otra acertada caracteristica de COBlT es su estructuracion o esquema depresentacidn. Esta estructurado con criterios practices en un orden logico y racionalde mayor nivei a menor nivel en la gestion y direccion de TI. Esta organizacion de

' El ITGl ssta estrecbamenie relaeionado con ia Information Systems Audit and Control Association (1SACA), detai forma que tos miembros de esta asociaeidn intemacional tambidfi lo son dei ITGl y timer! Jibre acceso a lasfmblieaciones del mismo. Este institute se creo en 1998, y es una organizacidn sin fines de lucro, cuyo objetivoprincipal es la investigacidn acerca dei gobiemo de las tecnologfas de ia informacidn, entre otros objetivos deinvest igation relacionados con las tecnologfas de la in funnacion . ww*. i fgi .org; www.isaca .O fg .

RA-MA C'APITULO 2. AIJ'DITORIA DE SI vs. NORMAS DF BUENAS PRACTICAS 37

las buenas practicas permite una mayor comprension del esquema, la graduacion ensu implantacion, su revision y actuaiizacion periodica sin tener que cambiar todo clesquema, a la vez que el enfoque de procesos permite una mayor adaptabilidad alos procesos de negocio y operatives de una organizacion. A su vez permitevisuaiizar la interrelation entre los objetivos de control de alto nivel y de detalle,dentro de cada dominio o proceso, segtin su agrupacion por actividades, y segunlos requerimtentos para estos controles.

Esta perspectiva es adecuada, ya que los controles intemos en TI, como encualquier otro aspecto de los procesos de una entidad, debet) relacionarse siempreentre si, en cuanto a sus objetivos, eficiencia y complementariedad en la mitigationde,riesgos, evit^do siTconsideraa'diTarslada. Lualqufer consideration aislada delos controles distorsiona la utilidad y resultados de un proceso de analisis yevaluation de riesgos.

COBlT 4.0 estructura en 34 objetivos de control de alto nivel para losprocesos de TI, que estan agrupados en 4 dominios de actividades tipicas delgobiemo de TI (o que cualquier gobiemo de Tl deberia incluir para ser realista yeficiente).

Los 4 dominios de actividades. son los siguientes6:

PLANIFICAR y ORGANIZAR (PO)7

ADQUIRIR e IMPLEMENT AR (Al)1

ENTREGAR y DAR SOPORTE (D$)9

MONITORIZAR y EVALUAR (ME)10

6 Tod as las traducciones ban sido realizadas con un criterio de mantener la mayor fidetidad postbk al texto eningles, pero al mismo tiempo tratando de lograr una equivalentia a los tirminos utilizados gcneralmente enesparto], para su mayor comprension.

' PO: Plan and Organise, en ingles.

* Al: Acquire and Implement, en ingles.

? DS: Deliver and Support, en ingles.

10 ME: Monitor anC Evaluate, en ingles. .

38 AUDITORIA DE TECNOLOGIAS Y S1STEMAS DE INFORMACION RA-MA

Es decir, se empieza planificando y organizando TODAS las actividades deTI, y no un area en especial (Desarrollo, explotacibn, etc.) o un aspccto en concrete(la continuidad de los servicios, por ejemplo).

Por cada uno de los procesos, y por cada uno de los objetivos de control dealto nivel, COBiT 4.0 proporciona los objetivos de control de detalle o del nivelsiguiente. En total son 215 objetivos de control de detalle.

Todos los objetivos de control, tanto los de alto nivel como los de detalle,estan debidamente fundamentados y contienen en explicaciones de sus propositos yalcanees.

*

Pero la estructuracion y mera descripcion de los objetivos de control pordominios no es suficicnte para implaritar adecuadamenle un gobierno de TI yasegurar que estas buenas practicas logren el objetivo previsto.

For esta razon, COBIT inciuye ademas otros elementos a considerar queestan relacionados con los requerimientos del negocio con tespecto a los serviciosy recursos de TI:

Requerimientos del Negocio con respecto a TI: Efectividad oEficacia; Eficiencia; Confidencialidad; Integridad; Disponibiiidad;Cumplimiento y Confiabilidad. -

Recursos de TI afectados: Aplicaciones; Information; Infraestructuray Personal.

Areas Centrales para el Gobierno de TI: Alineacion Estrat6gica;Entrega y Servicio que anada valor; Gestion de los Recursos; Gestiondel Riesgo y Medicion del Rendimiento.

Objetivos de Control de Detalle: enumeration de los Objetivos deDetalle con sus oportunas explicaciones sobre su proposito y alcance,por objetivo de alto nivel.

Directrices de Gestion: guia sobre las interrelaciones con otrosDominios y Objetivos de Control de Alto Nivel, seftalando tanto larelation de recepcibn (input) de otros objetivos de control e inclusiveextemos al esquema COBIT, como la entrega (output) hacia otros.

RA-MA CAPITULO 2. AUDITORtA DE SI vs. NORMAS DE BUENAS PRACTICAS 39

Responsabilidades por los distintos niveles de Direcci6n yGerencia: incluyen tanto la Alta Gerencia, como a unidades denegocio, hasta la Auditoria de TI.

Cuadro de objetivos y metricas aplicables: objetivos y metricasaplicables para el objetivo de control de que se trate, y asi mismo losindicadores para la respectiva medicion

Modelo de Madurez: criterios para considerar en cada nivel.En su planteamiento COBIT tiene presente el tradicional esquema que

diferencia entre los controles generales de TI (Desarrollo de Sistemas, Gestion deCambios, Seguridad, Produccion, entre otros) y Sos controles de las Aplicacionesde Negocio (Totalidad, Exactitud; Validez; Autorizacion y Segregation deFunciones, entre otros).

En cuanto a la evaluation de! riesgo, COBIT no proporciona ningunaherramienta especifica al respecto, y referencia de forma primordial al EnterpriseRisk ManagementIntegrated Framework, 2004, del Committee of SponsoringOrganisations of the Treadway Commission (COSO). Pero si considera que elriesgo de TI debe estar en consonancia, si existe, con el Modelo de Evaluacion delRiesgo de Negocio.

Existen otras normas para TI con las que el modelo COBlT 4.0 estarelacionado, que son complementarios a este modelo. La ISACA y el ITGI hanpublicado y continuan publicando distintos documentos para facilitar laimplantation practica de esta complementariedad. Por ejemplo: con ITIL, ISO/I EC27000, etc.

COBlT 4.0 es una herramienta critica que abarca la gestion integral de TI, yque puede verse complementada con esas otras normas para profiindizar enaquellos controles de este modelo, es decir, pasar del "debe hacerse", al "como se

En estos momentos, despues de varios aflos de andadura del COBIT, ya nose le confunde con una metodoiogia de auditoria de SI. Por lo tanto, el objetivo deesta seccion es definir el marco de actuacibn de los auditores de SI en relacidn aeste modelo.

40 AUPlTORtA DE TF.CNOLOGIAS Y SI'STEMAS DE fNPOR.MAC!QN RA-MA

Esta confusion se debfa, quizds, a la estrecha relacion de COBIT con laISACA. Por io tanto, tanto COBJT como las normas, directrices y procedimientosque comparten el mismo lengtiaje, y esta es, en ocasiones, una facilidad para Josauditores de TI.

Con la version 3 se editd una guia de auditoria para COBlT. Sin embargoesta guia no constituia una metodologia de auditona, ni normas m directrices deauditoria. En principio, establecia un marco de actuacibn de ios auditores de SI,basados en la metodologia de auditoria de 2a ISACA.

"...los auditores como requerimiento genera! deben proporcionar unagarantia (assurance) y recomendaciones en relacfbn a Ios control es en una entidad:

Proporcionar una garantia razonable de que se alcanzaran con losobjetivos de control.

Identificar si existen debilidades significative en estos controies. Sustanciar el riesgo que puede estar asociado a estas debilidades.

Recomendar o asesoras a la Gerencia sobre las acciones correcttvasque deberian ser tomadas".

Esta referenda en COBlT 3 a la auditoria de SI indicaba concretamente los

siguientes fiindamentosdeTa fiincion de kauditona de TI, en consonancia con losde la ISXCA:

Obtencion de un conocimiento: las tareas de auditoria que deben serrealizadas para conocer y "documentar objetivos de negocio, riesgos

' respectivos y medidas de control relevantes, asi como las actividadesque dan fundarnento a los objetivos de control asi como las necesariaspara identificar las medidas y procedimientos de control establecidos, yque se llevan a cabo.

jvaluaci6n de la adecuac*6n: las tareas de auditoria que deben serrealizadas en la apreciaci6rfHe"la eficacia de los mecanisraos de control-que se llevan a cabo o del grado hasta el cual el objetivo de control esalcanzado, Es decir, basicamente, decidir qud, en qud oportunidad y

r .d'cdmarealizarlaspruebas.

tlvaluaciQn del cumplimiento: las tareas de auditoria que deben ser. . realizadas para asegurar que los mecanisroos de control establecidos

RA-MACAHTULO 2. AUOtTORtA OE St vs. NORMAS PR BUt-.NAS PRACTICAL 41

estan funcionando tai como se establecio, consistentemente y de formacontinuada, para poder emitir una conclusion sobre la adecuacion delentomo de control.

" Fundamentar el riesgo; las tareas de auditoria que deben realizarsepara fiindamentar o "sustanciar" el riesgo de un objetivo de control queno se cumple, utilizando tdcnicas analiticas y/o consuitando fuentesaltemativas. El objetivo es soportar una opin/bn y provocar que laDirection tome acciones. No obstante, esta guia sigue siendo muyvalida ya que contiene una descripcibn amplia y detallada de comorealizar ia auditoria de ios controies de alto nivel y de detalle,jndicando tipo de pruebas, posibles riesgos en caso de deficiencias,etc.11

En definitive el auditor de Sj_ debe actuar jronje^ajin^m^ntacjbn deCOBtT, como en cualquier otra auditoria. No se lirmtara a contestar a uncuestTonanbdesTejustToW)^detemdnadoicontrol]

* AnaUzara los riesgos dentro del alcance y objetivo de la auditoria encuestion. ' '

Identificara cl modeig_y_ios consoles que supuestamente mitigan losriesgos identificados.

Realizara sus pruebas sobre los controles_y el impactp de lasdeficiencias de control. "

* Qbtendra sus conclusiones y emitira su informe^ o dictamenindependiente, indicando _ flmdarnentalrnente tos riesgos para elrffigoda."' " " " " " "

ITGI cstfc pteparando una nueva guia de auditoria para facilitar y mejorar laeficiencia de los auditores de SI que deban revisar distintos aspectos de TI, en unaorganization que ha implantado COBfT.

COBIT 4 indica en su documento de entorno ("framework") que losauditores de TI deben apficar su metodologia y sus gufas de auditoria. Laorientation de COBIT es fbndamentalmente el "negocio", es decir, la actividad de

11 En CoaiT 4:0 hay un anexo cun las teferencfas errtrt los control de esta version y los de COWT 3.

42 AUDITOKiA DE TECNOLOGiAS Y SISTEMAS PE INFOR.MAC10N RA-MA

una entidad, pero no se puede negar su gran utilidad tambien para los auditores,como sustentacion del modelo de control de TI a evaluar. El auditor de T1 tiene queopinar sobre los riesgos de TI, no limitarse a indicar que determinado control delmodelo fue implantado o no.

A lo largo de todo ei documento COBlT, la auditorfa de TI esta presente yes aludida en distintas circunstancias, no como mera comprobacion del modelo,sino como un elemento activo en la ayuda a la implantation de este modelo y en sumejora.

Por cada control de alto nivel, dentro de cada dominio, COBlT, en lasreferencias a las responsabilidades relacionades, incluye una referencia a laauditoria.

Por ejemplo en el Dominio de Planificacion y Organization, en e! controlde alto niyel sobre la Planificacion de un plan estrategico de Tf, se indica a laAuditoria con la responsabilidad de:

Identification de dependencias criticas y rendimiento12 actual: elauditor debe ser consultado.

u.

Construction de un plan estrategico para TI: el auditor debe serconsultado. .

Construccion de planes tacticos para TI: el auditor debe ser informado.En estas tablas de referencia debe tenerse en cuenta que auditoria ha sido

incluida en el mismo apartado que "Cumplimiento Legal"13, Riesgos y Seguridad(como conceptos globales). En estas dos ultimas funciones, si es posible que, endeterminados casos, sean "responsables" de una action determinada, sin embargonunca debe serlo el auditor, para mantener su independencia. Por lo tanto, estastablas, tal y como indica COBlT, son guias, no "obligaciones" mandatorias.

Tambien la funcion de auditoria esta reflejada en otros mecanismosrelevantes de COBlT, como por ejemplo en las metricas. Entre las referencias deeste tipo, se puede ilustrar con la del Dominio de Adquisicion e Implementacidn,en e! control de alto nivel de Instalacion y Acreditacidn de soluciones y cambios,

1

5

P

e

r

f

RA-MA CAPITUI.Q 2.. AUDITOR!A DE S! vs. NORMAS DE BUENAS PRACTICAS 43

donde se considera, como un indicador, los errores o deficiencias indicados eninformes de auditoria interna o externa.

Otro ejemplo se encuentra en el Dominio de Monitorizacion y Evaluation,en los objetivos de control de detalle para el control de alto nivel: monitorizacion yevaluacion del control interne, donde existe otra referencia a la auditoria de TI. Elcontrol de detalle ME2.5 - Aseguramiento del Control Intemo indica que deberlaobtenerse un aseguramiento independiente sobre el control intemo, a traves deauditoria interna o externa.

En este mismo dominio, en el objetivo de control de alto nivelmonitorizacion y evaluacion del control intemo, menciona entre las actividades quedeben implantarse la evaluacion del rendimiento de las revisiones y auditoriasindependientes. .

La auditoria de TI no carnbia en la aplicacion de.sus normas, metodologiay procedimientos porque este implantado el modelo COBlT, mas bien, estasituacion es una ayuda, ya que contara con mejores evidencias, y dispondra deregistros mas fiables sobre la realizacion de los controles.

Por ejemplo, las normas de auditoria de TI stguientes son totalmenteaplicables dentro de un contexto COBlT:

S I - E s t a t u t o d e A u d i t o r i a

S2 - Independencia

S3 - Etica Profesional y normas aplicables

S4 - Competencia Profesional

S5 - Planificacion

86 - Realizacion del Trabajo de Auditoria

o Supervision, Evidencia, y Documentacidn

S7 - Informes S8 - Actividades de Seguimiento

* S9 - Irregularidades y actos ilegales

44 AUDITORJA DE TECNOLGGlAS Y SISTEMAS DF. INFORMACION RA-MA

S! 0 - Gobierno de TI

S11 - Uso de Evaiuacion dei Riesgo cn ia planificacion de auditoria

S12 - Materialidad

S13 - Uso de! trabajo de expertos

S14 - Evidencia de AuditoriaDe la misma forma que son aplicables muchas de las directrices de

auditon'a de SI: G4: Extemalizacion de las actividades de TI a otrasorganizaciones; G6: Conceptos de Materialidad para la auditoria de SI; GIO:Muestreo estadi'stico; G16: Impacto de terceras partes en los controles de TI de laorganization; G31: Privacidad; G36: controles biometricos; entre otras.

2.3 AUDITORIA DE LOS SISTEMAS DE GESTION ENLAS TECNOLOGIAS DE LA INFORMACION YCOMUNIC ACIONES -TICS-

2.3.1 Introduction "Nuestro planteamiento acerca de los Sistemas de Gestion pretende

centrarse en el anaiisis de los mismos desde la perspectiva de !a Gestion delConocimiento.

Podemos afirmar que el ciclo de Demittg -con el acronimo PDCA- es uncicio de mejora continua, donde cabe distinguir las siguientes feses:

Plan: planificacibn de objetivos y procesos necesarios para alcanzarlos resultados de acuerdo a las politicas de la empresa.

DO: implantation de ios procesos.

Check: revision y monitorizacion de los procesos.

Act: ejecutar acetones para mejorar continuamente los procesos.Los ambitos donde el PDCA puede considerarse como el autentico motor y

el conocimiento de las TIC es muy variado: va desde !a Seguridad de los Sistemas

o RA-MACAPi'iULO-. AODITORIA DE SI VS. NORMAS DE BUENAS PRACTICAS 45

de Information, pasando por la ingenieria del Software, hasta la calidad en losservicios TIC, etc.

E! conocimiento vendria a ser la guia de buenas practicas que, desde laperspectiva de los Sistemas de Informacion, lo definimos como repositorio o basede datos de controles. (Vease figura 2.1).

Figures 2.1. Sistemas de gestion de TIC

Los dos sistemas de Gestion de! sector de las TIC que estan siendo masimplantados por las cmpresas ya sean grandes corporaciones o PYMES son losdenominados SGSI y SGSTI, que pasamos a definir:

* SGSI -S istema de Gestion de la Seguridad de la Informacion: -basadoen la Norma UNE ISO IIEC 27001: 2007 (Motor -PDCA-) y en iaNorma UNE ISO /IEC 27002 (Conocimiento-Gura de buenaspracticas-Repositorio de Controles para la seguridad en TIC).

SGSTI -Sistemas de Gestion del Servicio de Tecnologias de laInformacion-: basado en la Norma UNE ISO/ TEC 20000- 1: 2005(Motor -PDCA-) y en la Norma UNE ISO/1EC 20000 - 2(Conocimiento-Cddigo de buenas practicas-Repositorio de controles).

La principal ventaja que presentan estos sistemas de Gestion en las TIC laconstituye su capacidad de integration con otros sistemas ya muy difundidos en lasempresas, como son el Sistema de Gestion de Calidad (UNE ISO 9001) y elsistema Medioambiental (UNE ISO 14000), etc. Por este motivo, con su

46 AUDITORiA DE TECN'GLOGiAS Y SISTEMAS DE INFORMACION RA-MA

implementation se logra que las TIC queden integradas yprocesos del negocio.

otros

2.3.2 La implantation de un Sistema de Gestion en las TIC

Definir politico de sejundodEstabiecer alcance a! SGSI

RealiiaronaiiSisde riesgos

Seleeoonar los eontroies

Implanter ftode gestion de riesgos

Implanto* ei SGSI

Implsntar tos controies

Adaptor lot aecioMt eorrectivas

Adopter las acciones preventives

Reviser internamente ei SGSI

Reotizar auditorial internes del

sssr

Figura 2.2. Implantation SGSI (ISO 27001)

Su implantation Jleva aparejada la implementation de las fases de unPDCA (v^ase figura 2.2), siguiendo los puntos de la Norma UNE ISO/IEC 27001:2007 desde el apartado 4 al 8 de la Norma antes indicada.

Se hace un especial entasis en el analisis y gestion de los riesgos y laasignacidn de controies que minimicen estos riesgos, utilizando una de las muchasmetodologias de analisis de riesgos que existen en el mercado, y aplicando loscontroies que se estimen adecuados de la UNE ISO 27002 (Conocimiento).

2.3.3 Auditoria InternaEn el apartado 6 de la Norma UNE ISO 27001 se define el concepto de

Auditoria Interna del SGSI; se define como una revision independiente del SGSI.Dicha independencia supone obviamente la exigencia de que la persona que lleve acabo ia Auditoria Interna no puede estar vinculada en forma alguna a laimplantation ni a la gestion del SGSI.

RA-MA CAPlTULOa. AUDITORIA DE SI vs.NORMAS D fiUENAS PRACTIC'AS 47

Si utilizamos el concepto de Motor - Conocimiento, la auditoria interna sepodria definir como ia revision del motor y de los controies implementados(conocimiento).

Para esta revision independiente o Auditoria de SGSI se podra utilizar lametodologia que recomienda uno de los gurus de la Auditoria de Sistemas deInformacion, RON VVELER, denominada Risk-based approach, que cita en sulibro Conceptual Foundations and Practice; version espahola adaptada; por losautores EDR-Evaluacion de Riesgos.

Dicha metodologia consiste en realizar Pruebas de Cumplimiento; es decir,comprobar que los controies estan implementados, funcionan adecuadamente ycumplen los objetivos para los cuales jfueron implementados, tanto para losprocesos del PDCA -Motor- como para los controies implantados del repositorio -Conocimiento-.

No obstante y como complemento a las Pruebas de cumplimiento que Serealicen, existe la posibilidad adicional de ampliation de pruebas -PruebasSustantivas- con el objetivo de constatar con una mayor certeza el cumplimiento delos controies.

2.3.4 El proceso de Certification de los Sistemas de Gestionde las TICSc puede considerar el proceso de certification como el reconocimiento

formal por parte de un tercero independiente de un determinado sistema deGestion. (Vease en la figura 2.3),

La certification de un sistema de Gestion de las TIC no es obligatoria, perolo cierto es que las empresas que optan por certificarse mantienen sus sistemas degestion con una mayor dedication en e! ciclo de mejora continua y en su busquedapor alcanzar la excelencia.

El esquema de certification sigue la secuencia especificada en la figura 2.3que detallamos brevemente:

Presentation de solicitud formal ante e! organismo de certification,adjuntando la informacion solicitada por e! organismo en dichasolicitud.

* Revision del Manual del sistema de Gestion y los procedimientos porel Auditor extemo del organismo certificador.

48 AUPITOftiA DE TECNOLOGiAS Y SISTEMAS DE tNFORMACIONO RA-MA

Visita Previa del Auditor extemo del organismo Certificador (Pre-Auditon'a en las instalaciones de la empresa cliente). Para realizar estaPre-Auditor(a, el auditor extemo revisara el Motor del Sistema deGestion y emitird un Informe con observaciones al respecto.

Pasado un tiempo prudenciai el auditor de la certificadora reaiizara laAuditon'a del Sistema de Gestion, revisando el Motor y eiConocimiento con la metodologia EDR anteriormente aludida.

CUMTIONARIO 1

MCLtMINAR y SOLICITUO

AuoiTcxjii asMNqvAeroM

AHALtStS 68 Ul..

FROCSDIMtENTOS)

RESXSTROSISTEMA OE SESTldNSERVIdOS

INFORMS

INFORME

FUN Rl ACCIONUCOBRSCTORAS1 RCS .

^ Au&rfdftuIXTftAQRSIWABI.4

Figura 2.3. Modelo de certification de sistemas de gestion de TIC

El resultado de dicha Auditon'a quedara plasmado en un informe deAuditoria Inicial con no conformidades. En case de existir no conformidades deimportancia, la certificacion podna quedar suspendida pendiente de rectificacion.

Para el caso de detectarse no conformidades "menores", se emitira unacertificacion con reservas, quedando pervdientes las oportunas rectificaciones cuyasubsanacion debera ser constatada por el Auditor en la auditoria de seguimiento.

Una vez otorgada la certificacidn, el organismo certificador llevara a caboanualmente Auditorias de seguimiento para detertninar si su sistema de Gestion delas TIC sigue cumpliendo con las Normas (Motor).

RA-MA CAPiTULQ2. AUDI'IORIA DE Si vs. NORMAS DE BUENAS PRACTICAS49

E3 tiempo de la Certificacion es de ties anos, realizandose al tercer ano laAuditoria de Renovacidn que es similar a la Auditon'a Iniciai.

Como se puede apreciar en estas nuevas auditorias de Sistemas de Gestionde TIC, se sigue el proceso de la Auditoria de Sistemas de Informacidn, salvedadhecha de la inclusion del novedoso concept de Motor-Conocimiento, que hemosintentado resumir al maximo en este capitulo.

2.4 CONCLUSIONESLa impiantacion de normas y modelos de gestion de TI puede coiaborar y

ayudar a las entidades a lograr sus objetivos de negocio, aumentando la confianzaque pueden depositar en sus sistemas y tecnologias de la informacion.

La auditoria de SI se vera beneficiada con la impiantacion de estas normasen que tendra mejores evidencias y sustentacion de los controies implantados en unentomo de TI.

No obstante, es necesario tener en cuenta el objetivo de la auditoria. si esdentro del marco de la certificacion de una norma (en muchos casos lacomprobacibn de ia aplicacion de los requisites establecidos en la normarespectiva), o como un dictamen independiente con un alcance y objetivodetertninado, para informar a ia Direccion de una entidad, o por rcquerimientosextemos, si existen deficienctas en la gestion de TI, en su acepcion mas global,para el negocio, en el presents o en un futuro cercano.

2.5 REFERENCES Y BIBLIOGRAFIA

www.itgi.org

www.isaca.org

COBIT 4

IT Assurance Framework Draft - Agosto 2007

http://europa.eu.int/eur_ex/lex/JOHtml.do?uri=OJ:L:2005:077:SOM:EN:H

TML

Information Security HarmonisationClassification of Global Guidance -www.isaca.org

50 AUDITORIA DE TECNOLOGIAS Y SISTEMAS DE INFORMACION ORA-MA

Sarbanes-Oxley Act Compliance - Strategies for Implementing an AuditCommittee Complaints Procedure - By Mathias Strasser y Edgar WeippI - Journal- Volume 5 - 2006 - www.isaca.org

Security standards and frameworks - Bob Violino -bviolino@optonline.nei. - COMPUTERWORJLD

Challenges of compliance - The Cobif bridge Kenneth Liew -COMPUTER-WORLD - Vol.12 - Junio 2006

Alphabet Soup: Cobit, IT1L and ISO - www.csoonline.com - Febrero 2006

COBIT MAPPING: MAPPING OF ISO/lEC 17799:2000 WITH COBIT, Ved. - www.isaca.org - www.itgi.org

COBIT MAPPING: OVERVIEW OF INTERNATIONAL ITGUIDANCE, 2a ed.- www.isaca.org - www.itgi.org

COBIT MAPPING: MAPPING OF SENS CMM FOR SOFTWARE WITHCOBIT4.0- ITGI 2006 - www.isaca.org - wwwitgi.org

Convergent Security Risks in Physical Security Systems and - ITInfrastructures - (Informs donde participan las -siguientes organizaciones: ASISInternational (ASIS), Information Systems Security Association (ISSA) y laISACA. - 2005

IT Control Objectives for Sarbanes-Oxley, 2J ed. - Septiembre 2006 -www.isaca.org - wwwitgi.org

Guidance on Aligning COBIT, ITIL and ISO 17799 - By Gary HardyJournal on line - 2006 - www.isaca.org

ITGI Issues Val ITNew IT Value Framework www.isaca.org -www.itgi.org

Control Practices14 - www.isaca.org - www.itgi.org

Governance of Outsourcing - ITGI. 2005 - www.itgi.org

" E.ste docurotnto cxpandc la presentation de los centrales, con una vision mas ptactica y ton mayor information.

RA-MA CAPi rULQ 2. AUDITORIA DE S! vs. NORMAS DE BUENAS PRACT1CAS 51

COBIT MAPPING: MAPPING OF PMBOK WITH COBIT 4.0 - ProjectManagement Institutet A Guide to the Project Management Body of Knowledge(PMBOK Guide) Third Edition - 2006

Information Risks: - Whose Business - Are They? - ITGI - 2006

2.6 CUESTIONES DE REPASO1. Defina brevemente qud es el Ciclo de Doming. ^De que fases consta?

- ORGANIZACION", v solamente de un pfanteamiento correcto de los mismos,^ y T e a K s t a s . ^ ^ 1

) : .. LOS PROCEDIMIENTOS DE CONTROL- son los procedimientos: operatives de las distintas areas de la Empresa, obtenidos con una "metodoTogia

* apropiadaTpara la corisecucionde" u~no ITvanos" oBjetivos de control y por tanto^ debet! estar documentados y aprobados porfO^ireccIonT " " ~

* La tendencia habitual de los informaticos es a dar mas peso a la\j herramienta que al "control o contramedida" pero no debemos olvidar que "una

herramienta nunca es una solution sino una ayuda para conseguir un control1 mejor '. Sin la existencia de estos procedimientos, las herramientas de control son-y solamente una anecdota.

) Dentro de TECNOLOGIA DE SEGURIDAD,. estan todos los.elemcntos,^ ya_sean hardware" 6 software, que ayudan a controlar un riesgo informattco.

Dentro oe este concepto estin los cifradores, autentificadores, equipos "tolerantes) al failo", las herramientas d^confi^^etcT^*' * " '

Jv LAS HERRAMIENTAS DE CONTROL son eiementos software que

) permiteV defmir uno o yarios--procedimientos de control, para cumplir unanonnativa y un objetivo de control. " *" J 1 '

) --1-------_j Todos estos factores estan relacionados entre si y la calidad de cada uno

esta relacionada con la de los demas. Cuando se evalua el nivel de Seguridad de1 Sisiemas en una institution, se estan evaluando todos estos factores (piramide) y

) se plar.tea un Plan de Seguridad nuevo, que mejore todos los factores, aunque! conforms vayamos realizando los distintos proyectos del plan, no iran mejorando; > todos por igual. Al finalizar e! plan se habra conseguido una situacion nueva en la

j que el nivel de control sea superior al anterior.

1 Llamaremos PLAN PE SEGURIDAD a una estrategia planificada de ( acciones*\ proyectos que lleven ~a~un sistema de infonnacir6ny a sus centros de;;I

/

RA-MA CAP!! Ui.O 3. MHTODOLOOiAS DE CONTROL INTERNO, SEGURIDAD... 57

de una situacion inicial deterrninada (y a mejorar) a una situacion rncjorada(vease en la figura 3.2).

Cornite de Seguridad tieInformation

Seguridad Corporatr

56 AUDITORIA DE TECNOLOGIAS Y SISTEMAS DE rNFORMACIQN RA-MA.

pero nunca sin personas. Son estas [as que realizan los procedimientos ydcsarrolian los Planes (Plan de Seguridad, Plan de Contingencias, auditorial etc.)-

( A LAS METODOLOGjAS gon necesarias para realizar cualquier proyectoquen^s'prdpd'ngambs de manera ordenaday eficaz. ' ........ ......

LOS OBJETIVOS DE CONTROL son los objetivos a_cump!ir en elcontrol,de los procesos. Este concepto es el tnasjmpqrtante despues de "LAORGANIZATION- y soiamente de un planteamiento correcto de los mismos,saldran unos procedimientos eficaces y realistas.........

LOS PROCEDIMIENTOS DE CCOTROU son los procedimientosoperatiyoS" de las distintas dreas de !a Ertipresa, obtcnidos con una metodbTogiaapropTada', para ia consecucion de"uno~o'"vandro6Ietivos ~de control y poTtantodeb^estar documentadosyaprobados porta*Direcci6nr *" ' "

La tendeneia habitual de los informaticos es a dar mas peso a laherramienta que ai "control o contramedida" pero no debemos olvidar que "unahenramienta nunca es una solucion sino una ayuda para conseguir un controlmejor".-Sin la existencia de estos procedimientos, las herramientas de control sonsoiamente una aner.dota. ,

Dentro de TECNOLOGl A DE SEGURIDAD^ eatan todos los.elementos,ya sean hardware o software, que ayudan a controlar un riesgo, informatico.Pootrq de este concepto estan los cifradores, autentificadores, equipos "tolerantesal fallo", las herramientas de conffdl, eUn~ *"~ * ~ .......

V LAS HERRAMIENTAS DE CONTROL .son elementos software quepermiteri^ definir uno o varios -procedimientos de control, para cumplir unanormativa y un objettvo de control. " -

Todos estos factores estan relacionados entre si y la calidad de cada unoesta reiacionada con la de los demas. Cuando se evalua el nivel de Seguridad deSistemas en una institution, se estan evaluando todos estos factores (piramide) yse plantea un Plan de Seguridad nuevo, que tnejore todos Los factores, aunqueconforme vayamos realizando los distintos proyectos del plan, no iran mejorandotodos por igual. Al finalizar el plan se habra conseguido una situacion nueva en laque el nivel de control sea superior al anterior.

Llamaremos PLAN DE SEGURIDAD a una estratcgia pianificada deacciones y proyectos "que lleveh a~un sisTema de informacTon v a sus centres de

ERA-MA__CAPiTULQ.3. METODOLOGjAS DECONTROL 1NTERNQ. SEGURIDAD... 57

nmceso de una situacion inicial determinada (y a mejorar) a una situacion mejorada(vease en la figura 3,2).

gj Co mite tie Segurid.nl deInformation

Seguridad Cprporsft'wa. Control Intemo

Dptode Informatica Dptos de Usuarios Direction del Plan de Seguridad

Co nt r o l I r t fo r nr it ico Responsable de Fichero Controles GeneratesInformaticos

AuditoriaInformatica

Plan Auditor* Dictamenes

Figura 3,2. Organization de la seguridad de sistemas en las organizaciones

Eh la figura 3.2 se muestra la organization de la seguridad de sistemas enla empresa. Por una parte un comity que serla el director de la estrategia y de laspoliticas. Y por otra parte control intemo y auditoria informaticos. La funcion decontrol intemo se ve involucrada en la realization de los procedimientos de controly es una labor de dia a dia. La funcion de auditoria informatica esta centrada en laevaluation de los distintos aspectqs[ que designe su PLAN A^JDtT^R, con unascaracteristicas de trabajo que son las visitas concretas al centro, con objetfvosconcretos yUaslefnmwTu fr^aj6,'fa"pr^entaci6n del informe de resultaHos. Portanto las caracteristicas de su foncion son totalmente distintas. Lbgicamentetambien sus metodos de trabajo.

Queda pues decir que ambas funciones deben ser independientes de lainformatica, dado que por la disciplina laboral, la labor de las dos funcionesquedaria mediatizada y comprometida. Esto es lo que se llama "segregation defunciones" entre estas y la informatica. Nos quedaria decir que en organizacionesmuy grandes, incluso con dependence multinacionales, se tiende a estructurasorganizativas mas complejas. As! mismo por la tendeneia a descentralizar lafuncion o crear figuras paralelas. Pero tenemos que decir que no son mas quevariantes de las dos funciones clasicas, auditoria y control o seguridad. Asi es quehasta dentro de las organizaciones profesionales .existen las dos funcionesdiferenciadas en sus credenciaies y certificaciones.

58 AUDlTORtA DETRCNOLOOUS Y SISTEMAS DE INFORMATION t RA-MA

i

' iW > it

i

>4*

Tambien conviene aclarar que, aunque en algunos foros se utiliza eleoncepto seguridad integral tratando de urtir dos sectores absolutamentediferenciados como son el de la seguridad de la information y la seguridad fisica (oseguridad electronica), nada mas lejos de la realidad que este topico que se haescuchado desde hace muchos anos, y que no es nada objetivo. Porque que en unsistema de videovigilancia en IP se protejan los datos con una VPN' no significaque sean dos sectores convergentes. EJ sector de la seguridad fisica tiene cochesblindados y no significa que confluyan este sector y el del automovil.

Las metodologias que se usan en el mundo de la seguridad de sistemas sontodas las necesarias para realizar un plan de seguridad y ademas tardiTauditoriainformatica. ~"

w> i

Las dos metodologfas de evaluation de sistemas por antonomasia son lasde ANALISIS DE RIESGOS yjas de AUfflTORIA INFORMATICA, con 'dosenfoques distintos. La auditoria informatica solo" identifies* el riivei de "exposition"por la falta de controles, mientras que el analisis de riesgos facilita la "evaluacion"de los riesgos, y recomienda acciones en base'al costo-beneficio de las misinas.

Introduzcamos una serie de definiciones para profundizar en estas

) k

.AMENAZA: una(s) persona(s) o cosa(s) vista como posible fueate depelifiriTb catastrofe. ^^^lqswnundacion^ncendio, robo de datos,sabotaje, agujeros publicados, falta de procedi"mientqs"de emergencia,divulgation de datos, impiicacipnes con la ley, aplicaciones"maldisenadas, gastos incontroiados, etc.

^^.NERABILIDADTja situation creada, por la falta de uno o varioscontroles, con, la . que la amenaza pudiera acaecer y asi afectar a!entomo inforiitico. Ejemplos: falta de control de acceso logico, falta decontrol de versiones, inexistencia de un control de soportesmagneticos, falta de separation de entomos en el sistema, falta de

I

RA-MACAPITULO 3. METODOLOGIAS DE CONTROL 1NTERNO, SEGURIDAD... 59

* R1ESQQ: la probabilidad de que una amenaza llegue a acaecer por laexistencia "de una vul'nerabilidad. Ejemplo: los datos estadlsticos decada evento de una base de datos de incidentes.

" EXPOSICION O IMPACTO: la evaluacion del efecto del riesgo.Eieml?Io:~"es'"ffecuente evaluar el irnpacto en terminos economicos,aunque no giempre lo es, como vidas humanas. imagen de la empresa,honor, defensa national, etc.

Las amenazas reales se presentan de forma compleja y son dificiles depredecir. Ejemplo; por varias causas se rompen las dos entradas de agua e inundanLi fas lineas telefdnicas (pues existe un poro en el cable) y hay un cortocircuito, y sequema el transfonnador de la central local. En estos casos la probabilidadresultante es muy dificii

60 AUDITQR-IA PH. TECNOi-OGIAS Y SISTEMAS DEINPORMAC1QN C RA-MA

Todas las_ mejodoiogias existentes en seguridad de_ sistemas vanencaminadas a establecer y mcjorar un entramadu de conlramedidas que garanticenque fa probabilidad de que las amenazas se materialmen en Hechos (por falta decontrol) sea lo mas baja posibie o al menos quede reduclda de una forma razonableen costo-beneficio.

3.2.2 Tipos de metodoiogiasTodas las metodologfas existentes desarrolladas y utilizadas en la auditoria

y el control informaticos se pueden agrupar en dos grandes familias. Estas son:

Cuantitativas: basadas en un modefo matematico num^rico quejiyudaala realizacion del trabajo.

Cualitativas: basadas en el criterio y raciocinio humano capaz dedeflnir un proceso de trabajo y seleccionar en base la experienciaacumulada. " ' " " ............ '

3.2.2,1 METODOLOGIA CUANTITATIVAS

Disenadas para producir una lista de riesgos que_pueden compararse entresi con facilidad por tener asignadqs unos valores numericos. Estosvalores en eLcaso deTnetodolagios de analisis de riesgos o de planes de contingencias son datosde probabilidad de ocurrencia (riesgo) de un evento, y que se deben extraer de unregistro de incrdencias donde el numero de incidencias tienda al infinite o seasuficientemente grande. Esto no pasa en la practica y se aproxima ese valor deforma subjetiva restando ast rigor cientitico al calculo. Pero dado que el calculo sehace para ayudar en el metodo a elegir entre varias contramedidas podriamosaceptarlo.

Hay varios coeficientes que conviene definir:

ALE .^(Annualized Loss Expen tacy): rnultipliear ia perdida maximaposibie de cada bien/recurso por la amenaza con probabilidad ms alta.

Reduction del ALE (Annualized Loss Expectancy): es el cocienteentre el coste anualizado de la instalacion y el mantenimiento de lamedida contra el valor total del bien/recurso (activo) que se estaprotegiendo, en tanto por ciento.

15 RA-MA___CAP1TLH.Q 3. Ml.TODOLOGIAS DE CONTROL INTERNO, SEGURIDAD... 6!

Retomo de la inversion (ROI): ALE original menos ALE reducido(como resultado de la medida), dividido por el coste anualizado de lamedida.

Todos estos coeficientes y otros disenados por los autores de lasmetodoiogias son usados para el juego de simulation que permite elegir entrevarias contramedidas en el analisis de riesgos. Esto es, en el proceso metodologicodel analisis de riesgos, tras identificar activos, amenazas, debilidades, siemprebabra entre varias opciones de plan de contramedidas a elegir. El modeloo juegode ensayo que me permite elegir el mas apropiado en cada caso se llama "que pasasi", y cada metodologia uSa uno distinto que la caracteriza.

Por tanto vemos con claridad dos grandes inconvenientes de estasmetodoiogias, que son por una parte !a debilidad de los datos, de la probabilidad deocurrencia, por los pocos registros de incidentes y la poca significacibn de losinismos a nivel mundial. Y ademas la imposibilidad o dificultad de evaluareconomicamente todos los impactos que pueden acaecer.

Frente a la ventaja de poder usar un modelo matematico para el analisis.

3.2.2.2 METODOLOGIA CUALITATIVA / SUBJETIVAS

Basadas en metodos estadisticos y logica borrosa. Precisan de unprofesional experimentado. Pero requieren menos recursos humanos/tiempo que lasmetodoiogias cuantitativas.

La tendencia de uso de ia realidad es la mezcla de ambas. En la figura 3.3se observa un cuadro comparativo entre ambas.

3.2.3 Metodoiogias mas comunesLas metodoiogias mas comunes que podemos encontrar de evaluation de

sistemas son de analisis de riesgos o de diagnosticos de seguridad, las de plan decontingencias y las de auditoria de controles generales.

3.2.3.1 METODOLOGLAS ANALISIS DE RIESGOS

Estan desarrolladas para la identification de la fafta de controles y elestablecimiento de un plan de contramedidas.

Existen dos tipos: las cuantitativas y las cualitativas. Existen gran cantidadde ambas clases y cifaremos.algunas de ellas.

62 AUDITORJA DE TECNQLQCHAS Y S1STEMAS PE [NFORMACitiN RA-MA

** " 'T i!L El esquema basico de una metodologia de analisis de riesgos es en esencia el representado en ia figura 3.4.

3.2,3.2 COMPARACIONr

CUANTITATfVA CUALITATIVA

PROS Enfoca pensamientosmediante el uso de numeros.

Enfoque lo ampiio que sedesee.

Faeilita ia comparacion devulnerabilidades muvdistintas.

Proporciona una cifrajusiificantc para cadacontramedida.

Plan de trabajo flexible yreactivo.

Se concentra en laidentifieacion. de eventos.

Incluye factores intangibles.

CONTRAS Estimacion de probabilidadde estadfsticas fiabiesinexistentes.

Depende fuertemente de lahabilidad y calidad delpersona! involucrado.

Estimacion de las perdidaspotenciales solo si sonvalores cuantificable's.

Metodologia estandares.

Pueden excluir riesgossignificantes desconocidos(depende de la capacidaddel profesional para usar elcheck-list/guia).

i

Diftcrles de manterter omodificar.

Dependencia de unprofesional.

Identificacion de eventosreales mas elaros 4 no tenerque aplicarlesprobabilidades complejas decaicuiar.

Dependencia de unprofesional.

Figura 3:3. Tipos de metodologias para el ond/isis de riesgo

RA-MA CApiTULO 3. METODOLOGIAS DE CONTROL iNTERNO, SEGURJDAD... 63

Funcionamiento esquematico basico de cualquierpaquete:

Cuestionario

T

Idsntiflcaf los riesgos I

Caicuiar el impacto

Identificar (as contramedidas y el cost

Simulaciones

Creadon de fos informes I

Etapa 1

Etapa 2

Etapa 3

-v Etapa 4

Etapa 5

I" Etapa 5

Figura 3.4. Funcionamiento del software del analisis de riesgo

En base a unos cuestionarios se identifican vulnerabilidades y riesgos, seevalua el impacto, para mas tarde identificar las contramedidas y el coste. Lasiguiente etapa es la mas importante pues mediante un juego de simulacidn (quellamaremos "r,que pasa si?...") analizamos e! efecto de las distinta contramedidasen la disminucion de los riesgos analizados, eligiendo de esta manera un plan decontramedidas (plan de seguridad), que compondra el inforrne final de laevaluacidn.

De forma generics las metodologias existentes se diferencian en:

Si son cuantitativas o cualitativas, o sea si para el "Que pasa si...."utilizan un modeio matematico o algun sistema cercano a la eleccionsubjetiva. Aunque bien pensado a! aproximar las probabilidades poresperanzas matematicas subjetivamcnte, las metodologiascuantitativas, aunque utilicen aparatos matematicos en sussimulaciones, tienen una gran componente subjetiva.

Y ademas se diferencian en el propto sistema de simulacidn.

En e! INFOSEC'92 proyecto S2G14 se identificaron 66 metodologias dc lascuales por limitaciones de tiempo se analizaron solo 12 con sus respectivos

64 AUDlTORiA DE TECNOLOGlAS Y S1STEMAS DE INFORMACSON RA-MA

paquetes y asl el informe de este trabajo acabo siendo un contraste de lasprestacioncs de dichos paquetes segun los fabricantes y la opinion de losconsultores del equipo. Estos metodos analizados eran: NALIZY, BDSS, BISRISK ASSESOR, BUDDY SYSTEM, COBRA, CRAMM, DDIS MARION AP+,MELISA, RISAN, RISKPAC, RISKWATCH.

Despues de estas metodologias ban nacido muchas otras, como porejemplo la MAGERIT (desarrollada por la administracidn

IA, etc.

En la figura 3.5 se muestran las metodologias mas destacabies en laactualidad. 9

Figura 3.5. Principales tmiodos de ana lis is y gesiion de riesgos

riesgos informaticos con

Es un compendio de metodologias espanolas desarrolladas entre los anos1990 y la actualidad con un enfoaue subjetivo.

Sus caracteristicas esenciales son:

Cubrir las necesidades de ios profesionales que desarrollan cada uno delos proyectos necesarios de un plan de seguridad.

Facilmente adaptable a cualquier tipo de herramienta. Posee cuestionarios de preguntas para la identificacion de deSlIidades o

RA-MA CAPiTULO 3. METOPOLOGiAS DE CONTROL 1NTER.NO. SEGURIDAD... 65

Posee listas de ayuda para los usuarios menos experimentados dedebilidadcs, riesgos y contramedidas (sistema de ayuda).

Permite facilmente la generacion de informes finales.

Las "Listas de ayuda" y los cuestionarios son abiertos y por tanto esposible introducir informacion nueva o cambiar la existente. De ahi laexpresidn Abierta de su nombre.

Tiene un 'Yque pasa si...?" cualitativo pero al tener capacidad deaprendizaje con su uso posee en su base de conocimiento una base oregistro de incidentes que van variando las esperanzas rnatematicas departida y adaptandose a los entomos de trabajo.

En lasPRIMA.

3.6 y 3.7 se expone la m de analisis de riesgos

4TOMA OE

DATOS

PONOERACION

DE8IUDADES

VALORACB

N

ECONOMICA

RfESGO

PRIORIDAO

ACCIONESCORRECTQRAS

OURACldN

COSTO

PLAN 9E

ACCIONES

PLAN BE

PROYECTO

S

Figura 3- 6. Conceptos basicos de la metodologia PRIMA

66.AUDITOR/A DK lECNOLOGIAS Y SiSTEMASDE INFORMACION C RA-MA

#AmenazaslVu!nerabilidades

Figura 3.7. Fases de la metodologia PRIMA

3.2.3.3 PLAN DE CONTINGENCIES

El auditor defae conocer perfectamente Ios conceptos de un plan decontingencias para poder auditarlo.

Hay varias formas de liamarlo pero conviene no confundir Ios conceptosque se manejan alrededor de Ios nombres.

El plan de contingencias y de recuperation de negocio es lo mismo, perono asi ei plan de restauracion intemo. Este va enfocado hacia la restauracion delC.P.D., pero sobre eventos que suceden dentro del entorno (caidas del sistema,roturas leves, etc.)> y que su duracion no afecta gravemente a la contvnuidad delnegocio,

Tambien se manejan a veces los conceptos de plan de contingenciasinfonndtico y plan de contingencias corporativo, cuyos conceptos son solo dealcance. El corporativo cubre no solo la informatica sino todos los departamentosde una entidad, y puede incluir tambien el informdtico como un departamento mas.Frecuentemente se realiza el informatico.

El Plan de Contingencias es una estrategia planificada constituida por unconjunto de recursos dc respaldo, una organization de ernergencia y unos

RA-MA CAPITUI.O 3. MF. IODQLOGiAS DE CONTROL (NTERNO, SECUMPAD. . . 67

procedimientos de actuation. encaminada a conseguir una restauracionprogresiva y agil de fos servicios de negocio afectados por una paralizacion total oparcial de la capacidad operativa de la empresa,

Esa estrategia materializada en un manual es el resultado de todo unproceso de anaiisis y definiciones que es de lo que existen metodologias. 0 sea lasmetodologias que existen versan sobre el proceso necesario para obtener dichoplan.

Es muy importante tener en cuenta que el coneepto a considerar es "lacontinuidad en el negocio"; estudiar todo lo que puede paralizar la actividad yproducir pcrdidas. Todo lo que no considere este criterio no sera nunca un plan decontingencias.

FASES DE UN PLAN. Las fases de un plan son las siguientes:

FASE I: ANALISIS Y DISENO. Se estudia la problematics, lasnecesidades de recursos, altemativas de respaldo y se analiza ei coste/beneficio delas mismas. Esta es la fase mas importante pudiendo llegarse al final de la mismaincluso a la conclusion de que no es viable o es muy costoso el seguir. En la formade desarrollar esta fase, se diferencian las dos familias metodologicas:

Las de Risck Anaiisis se has an en el estudio de los posibles riesgosdesde el punto de vista de probabilidad de que los mismos sucedan.Los registros de incidentes al igual que hablamos en las metodologiasde anaiisis de riesgos son escasos y poco fiables, aun asi es mas facfiencontrar este tipo de metodologias que las segundas.

Las tareas de esta fase en las metodologias de Risck AnAlisis son lassiguientes;

1. Identification de amenazas.

2. Anaiisis de la probabilidad de materialization de la amenaza.

3. Selection de amenazas.

4. Identificacion de entomos atnenazados.

5. Identificacion de servicios afectados.

6. Estimation de! impacto economico por paralizacion de cada servicio.

68 AUDITOFUA DE TECNOLOGIAS Y SISTEMAS DE INFORMATION RA-MA

7. Seleccion de los servicios a cubrir.

8. Seleccion final del ambito del Plan.

9. Identification de alternativas para los entornos.

10. Seleccidn de altemativas.

11. Diseno de estrategias de respaldo.

12. Seleccion de la estrategia de respaldo.*

* Las de Bussines Impact se basan en el estudio del impacto (perdidaeconomica o de imagen) que ocasiona la falta de algiin recurso de losque soporta la actividad del negocio. Estas metodologias son masescasas pero tienen grandes ventajas como es el mejor entcndimientodel proceso, o el menor empleo de tiempo de trabajo por ir masdirectas al problems.

Las tareas para las de Bussines Impact son las siguientes:

1. ldentificacion de servicios finales.

2. Analisis del impacto. En estas metodologias se evaluan los dafios

economicos y de imagen y otros aspectos no economicos, lo que les dauna ventaja en los casos en los que intervienen otros vaiores que no seanlos economicos.

3. Seleccion de servicios criticos,

4. Determinacion de recursos de soporte.

5. ldentificacion de alternativas para entornos.

6. Seleccidn de altemativas.7. Diseno de estrategias globales de respaldo.

8. Seleccion de la estrategia global de respaldo.

Como puede verse e! enfoque de esta segunda es mas practice y directo yse va mas directo a las nccesidades reales de la entidad sin tener que justificar condatos de probabilidades que aportan poco por la pobreza de los datos. Estas se

RA-MA CAPiTUt.0 3. METOOOLOGiAS DE CONTROL INTERNO, SEGURJDAD... 69

basan en hechos ciertos, que se analizan y se justifican economicamente. Permitenpor tanto hacer estudios costo/beneficio que justifican las inversiunes con mas rigorque los estudios de probabilidad que se obtienen con los analisis de riesgos.

Hay un factor importante a determinar en esta fase que es el "Time Frame",o tiempo que la empresa puede asumir con paralizacion de la actividad operativeantes de incurrir en perdidas significativas. Este factor marcara las estrategias derecuperacion y se extraera del analisis del impacto.

FASE II: DESARROLLO DEL PLAN. Esta fase y la terccra sonsimilares en todas las metodologias. En ella se desarrolla la estrategia seleccionada,implantandose hasta el final todas las acciones previstas. Se definen las distintasorganizaciones de emergencia y se desarrollan los procedimientos de actuaciongenerando asi la docuinentacion de! plan.

Es en esta fase cuando se analiza la vuelta a la normalidad dado que pasarde la situacion normal a la "altemativa" debe concluirse con la recontraccion de lasituacion inicial antes de la contingencia, y esto es lo que no todas las metodologiasincluyen.

FASE III: PRUEBAS Y MANTENJMiENTO. En esta fase se definenlas pruebas, sus caracteristicas, sus ciclos y se realiza la primera prueba comocomprobacion de todo el trabajo realizado y mentalizar al personal implicado.

As! mismo se define la estrategia de mantenimiento, la organizaciondestinada a ello y la normatrva y procedimientos necesarios.para llevarlo a cabo.

HERitAMIENTAS. En este caso como en todas las metodologias laherramienta es una anecdota y lo importante es tener y usar la metodoiogiaapropiada y mds tarde desarrollar la herramienta que se necesite.

3.3 LAS METODOLOGIAS DE AUDITORIAINFORMATICA

Las unicas metodologias que podemos encontrar en la auditorlainformatica son dos familias distintas: las auditorias de controles generales comoproducto estandar de las companias auditoras profesionales, que son unahomologacion dc las mismas a nive! internacional, y las metodologias de losaudiiores intemos.

71) AULMIORIA DE TECNOLOGlAS Y SISTEMAS Of. INEORMACION 0 RA-MA

El objeiivo tie las auditorias de cQntroles generales es "dar una opinionsobre ia fiabilidad de los datos del ordenador para !a auditoria finaneiera". E!resuUado extemo es un cscucto informe como parte del informe de auditoria, dondese destacan lasvuinerabiiidades encontradas.

Estan basadas en pequefios cuestionarios estandares, que dan comoresultado informes muy generalitas. Tienen apartados para definir "pruebas" yanotar sus resuitados. Esta es una caracterfstica clara de la diferencia con lasmetodologias de evaluacion de la consultoria como las de anaiisis de riesgos queno las tienen, aunque tambien tratan de identificar vulnerabilidades o falta decontroles. 0 sea la reaiizacion de pruebas es consustancial a la auditoria, dado queel trabajo de consultoria como el analisiS de riesgos espera siempre de lacolaboracion del anaiizado, y por el contrario la auditoria debe demostrar conpruebas todas sus afirmaciones, y por ello siempre debe contener el apartado de laspruebas, llegando al exiremo de que hay auditorias que se basan solo en pruebascomo la "auditoria de integridad".

Estas metodoiogi'as estan muy desprestigiadas pero no porque sean malasen si mismas, sino porque dependen mucho de la experiencia de ios profesionaiesque las usan y existe una practica de utiiizarlas profesionaies sin ningunaexperiencia. Ninguna de esta metodoiogi'as usa de ayudas de contramedidas,llegandose a la aberracion de que se utilizari metodoiogi'as de anaiisis de riesgospara hacer auditorias. .

Todas estas anomalias nacen de la dificultad que tiene un profesional sinexperiencia que asume la foncidn auditora y busca una formula facil y rapida que lepermita empezar su trabajo rapidamente. Esto es una Utopia. E! auditor informaticonecesita de una larga experiencia tutelada y una gran formacidn tanto auditoracomo informatica. Y esta formation debe ser adquirida mediante el estudio y iapractica tutelada.

Llegamos al punto en el que es necesario decir que la metodologia deauditor intemo debe ser disenada y desarrollada por el propio auditor y esta sera Iasignification de su grado de experiencia y habilidad.

Por tanto entre las dos metodologias de evaluacion de sistemas (anaiisis deriesgos y auditoria) existen similitudes y grandes diferencias. Ambas tienen papelesde trabajo obtenidos del trabajo de campo tras el plan de entrevistas, pero loscuestionarios son totalmente distintos. Los de la figura 3.6 son de anaiisis deriesgos y son preguntas dirigidas a la identification de la falta de controles. Se vendirigidas a consultores por la planificacion de los tiempos, y por ser preguntas masconcretas.

RA-MA CAPi rUt .O 3. METOOOLOOiAS DE CONTROL INTERNO, SEGURJDAD... 71

En el punto 3 se expone un ejemplo real de una metodologia de auditorintemo necesaria para revisar cualquier aplicacion. Como se ve en el ejemplo estaformada por recomendaciones de plan de trabajo y de todo el proceso que debeseguin Tambien define el objetivo de la misma, que habra que describirlo en elmemorandum de apertura al auditado. Asi mismo describe en forma decuestionarios genericos, con una orientation de los controles a revisar.

En este caso del auditor intemo informatico le servira de guia paraconfeccionar el programa real de trabajo de la auditoria. El auditor debera hacer loscuestionarios mas detallados si asi |o estima oportuno y definir cuantas pruebasestime oportunas. Asi mismo si cuando empieza una auditoria, el auditor detectavias alteruarivas a revisar, su deber es seguirlas cambiando el plan de trabajo. Portanto el concepto de las metodologias de anaiisis de riesgos de "tiempos medidos"es mas bien para consultores profesionaies que para, audilores intemos. Estas,aunque deben planificar sus tiempos, en principio no debe ser nunca su factorprincipal, dado que su funcion es vigilancia y esta se cumple si e! auditado se siente

El auditor intemo debe hacerse sus metodologias necesarias para auditarlos distintos aspectos o areas que defvna en el plan auditor que veremos en elsiguientc punto.

El esquema metodoiogico del auditor esta definido por el plan auditor quevemos a continuation.

3.3.1 Ejemplo metodologia auditoria de una aplicacionMETODOLOGIA DE TRABAJO

REVISION DE CONTROLES SOBRE APLICACIONES

OBJETIVO: determinar que los sistemas producen informacionesexactas y completas al moment oportuno. Este area de trabajo es lai vez el masimportante en el trabajo de auditorias informaticas.

3.3.1.1 PROGRAMA DE LA REVISION

1. identificar el irea a revisar (por ejemplo a partir del calendario derevisiones), notificar al responsable del area y prepararse utiiizando papelesde trabajo de auditorias anteriores.2. Identificar las informaciones necesarias para la auditoria y para laspruebas.

72 AUDITQ1UA Dfi TECNOLOGiAS V S1STKMAS DE rNFORMACION RA-MA

3. Obtener infonnaciones generales sobre el sistema operacional. En estaetapa, se defmcn los objetivos y ei aicance de la auditoria, y se identificanlos usuarios especi'ficos que estarian afectados por la auditoria (plan deentrevistas); el auditor aprende en que consiste el entomo a revisar, yexpliea por que se bace la auditoria.

4. Obtener una compression detaiiada de la apJicacion/sistema. Aquf, sepasan entrevistas con los usuarios y el persona! implicado en el sistema arevisar; se examina (a documentation de usuarios, de desarrollo, deoperation, se identifican los aspectos mas importantes del sistema (entrada,tratamiento, salida de datos), la periodicidad de procesos, los programasfuerrtes, caracteristicas y estructuras de ficheros de datos; y pistas deauditoria.

5. Identificar los puntos de contro! criticos en el sistema operacional.Utilizando organigram as de flujos de informaciones, identificar los puntosde control criticos en entrevistas con los usuarios y el personal operacional,y con e! apoyo de la documentacion sobre el sistema. El auditor tiene queidentificar los peligros y los riesgos que podriao surgir en eada panto. Lospuntos de control criticos son aquellos puntos donde el riesgo es masgrave, es decir, donde ia necesidad de un control es mas import ante. Amenudo, son necesarios controles en los puntos de interface entreprocedimientos manuales y autom&ticos

6. Diseno y elaboration de los procedimientos de la auditoria.

7. Ejecucion de pruebas en los puntos criticos de control. Se podria incluirla determination de las necesidades de herramientas informaticas de ayudaa la auditoria no informdtica. Una revision del cumplimiento de losprocedimientos se hace para verificar el buen seguimiento de estandares yprocedimientos formales, y de los procesos descritos por ios organigramasde flujos. Asi se verifican los controles internos del cumplimiento de a)planes, politicas, procedimientos, estandares, b) la etica del trabajo de iaorganization, c) requerimientos legates, d) principios generales decontabiiidad y e) practicas generales de informatica.

Se hacen revisiones sustantivas y pruebas, como resultado de la revision delcumplimiento de procedimientos. Si las conclusiones de la revision decumplimentacion eran generalmente positivas, se podrian limitar lasrevisiones sustantivas. Dentro de este punto del programa de la revisidnpodriamos analizar si existen los siguientes controles.

RA-MA CAPiTULO.3. METODOLOGlAS DECONTROL INTERNO, SEGURJDAD... 73

8. Evaluation de la revision y/o resuitados de pruebas. En esta etapa seidentifican y se evaluan los puntos fuertes y debiles de los procedimientos ypracticas de control intemo en relacion con su adecuaciori, eficientia yefectividad. Cuando se identifique una debilidad, se determinant su causa.

Se elaboran las conclusiones basadas sobre la evidencia; lo que debera sersuficiente, reievante, fiable, disponible, comprobable y util.

9. Preparacion del informe. Recomendaciones.

3 J. 1.2 Revisar procedimientos escritos para iniciar, autorizar, recogcr,

preparar y aprobar los datos de entrada, en la forma de un manual deusuario. Verificar que los usuarios entienden y siguen estosprocedimientos.

Que se de la formation del "uso del Terminal" necesaria a los usuarios.

Revisar los documentos fiiente u ctros documentos para determinar sison numerados. Tambidn revisar codigos de identification detransacciones y otros campos de uso frecuentes, para determinar si soncodificados previamente para mimmizar errores en los procesos depreparacion, entrada y conversion de datos.

Cuando sea necesario^verificar que todos los datos de entrada en unsistema pasan por validation y registro antes de su tratamiento.

Determinar si los usuarios preparan totales de contro! de los datos deentrada por terminales. Comprobar la existencia de una reconciliationde los totales de entrada con totales de salida.

Comprobar la existencia y seguimiento de calendarios de entrada dedatos y de distribution de informes (listados).

Determinar si el arcbivo y retention de documentos fuente y otrosformularios de entrada es logica y accesible, y que cumple las normas

y

Revisar !os procedimientos de correction de errores.

74 AUDLTOPJA DE TECNOLOGIAS Y SISTEMAS DEIWFORMACIQN RA-MA

, Comprobar la existencia de periodos para document* Rentes y. soportes magn^ticos-

CONTROLES DE ENTRADA DE DATOS

EstaMecer los procedimientos de entrada y control de dates, queexpiican las revisiones necesarias de entradas y salidas, con fechalimits, criterios de validacion de datos tie entrada; codigos, mensajes ydeteccion de errores; la correction de errores y la reentrada de datos.

Para sistemas interactivos, verificar el uso de metodos preventives paraevitar la entrada incorrecta de. date* funciones de ayuda a !a pantalla,formatos fijos, el uso de menus y mensajes para e! operador.

Para sistemas interactivos, determinar la grabacion de datos de entradacon fecha y hora actual, asi corno con una identification delusuario/terminal y ubicacion.

Revisar los logs de acceso por lineas de telecomunicaciones paradetemiinar posibles accesos y entradas no autorizados.

Revisar los programas para determinar si conticneri procesos internosde validacion de datos (por ejcmplo chequeos de digitos, testrazonables, numero de cuentas, etc.). Evaluar su exactitud.

Comparar, validar, apuntar y recalcular campos o elementos de datoscriticos, por metodos manuales o automaticos.

Para sistemas interactivos, determinar que los datos se verifican a!momento de su entrada en el sistema.

Comprobar que los usuarios revisan regulannente las tablas intern asdel sistema para validar sus contenidos.

Revisar funciones matematicas que redondean calculos para ver sitienen implicaciones negativas.

Determinar que existen pistas de auditoria adecuadas en el diccionariode datos. Identificar 3a interrelation entre los programas y los datospara dejar la posibilidad de seguir la pista de datos dentro deprogramas y sistemas errores.

RA-MA_CAPITULO 3. METODOLOGiAS DE CONTROL tNTERNO, SEGURJDAP... 75

Revisar los procedimientos de correction de errores. Identificar con los usuarios cualquier codigo de errores criticos que

deberian aparecer en momentos especificos, pero que nunca surgen.^Se han desactivado los codigos o mensajes de error?

CONTROLES DE TRATAMIENTO Y ACTUALIZACION DEDATOS

Ver si hay establecidos controles internos automatizados de proceso,tales como rutinas de validacion, al momento de la actualizacion de losficheros de transaction, referencia y maestro.

Identificacion de transacciones por codigos de transaction y otrosindicadores.

Revision del log de transacciones para identificar problemasencontrados por el operador y las medidas seguidas.

Restriccidn de la posibilidad de pasar por encima de procesos devalidacion.

Aceptacion por los usuarios finales de todas las transacciones ycalculos de la aplicactdn.

Revisar los totales de control de entrada de datos. Verificar que existen totales de control para confirmar la buena

interface entre tareas o programas,

Comprobar que existen validaciones entre totales de control, manualesy automaticos, en puntos del interface entre procesos manuales yautomatizados.

Verificar que los logs de actividad de sistemas se revisan por losresponsables operacionales para investigar accesos y manipulacionesno autorizados.

Ver los controles sobre la entrada de datos.

76 AUDrTORlA DE TECNQLOfilAS Y SISTEMAS DE (NFORMACidN SA-MA

CONTROLES DE SALIDA DE DATOS

Determinar si los usuarios comparer* totaies de control de Ios datos deentrada con totaies control de datps de saiida.

Determinar si control de datos revisa los informes de saiida (iistados)para detectar crrores evidentes tales como; campos de datos que faltan,valores no razonables o formatos incorrectos.

Verificar que se hace una identification adecuada sobre ios informes,por ejemplo nombre y niimero de informe, fecha de saiida, nombre dearea/departamento, pagina y totaies} control si son necesarios.

Comparer la lista de distribucidn de informes cor los usuarios que losreciben en reaiidad. ^Hay personas que reciben el informe que nodeberian recibirlo?

Verificar que los informes que pasan de aplicabilidad se destruyen, yque no pasan simplemente a la basura, sin seguridad de destruccidn.

Revisar la justification dc informes, que exists una petition escrita* para cada uno y que se utilizan realmente y que esta autorizada la

peticion. .

Verificar la existencia de periodos de retention de informes y susuflciencia.

Revisar los procedimientos de correction de los datos de saiida.

CONTROLES DE DOCUMENTACI6N

Verificar que dentro de las actividades de desarrollo y mantenimientode aplicaciones se producen documentation de sistemas, programas,operaciones y funciones y procedimientos de usuario.

Existencia de un persona especlfica encargada de !a documentacion yque mantiene un archivo de documentos ya distribuidos y a quepersonas.

Comprobar que Ios jefes de area se informen de faltas dedocumentacion adecuada para sus empieados.

Destruction de toda la documentacion de antiguos sistemas.

Que no se aceptan nuevas aplicaciones por los usuarios sin unadocumentacion completa.

Actualizacidn de la documentacion al mismo tietnpo que los cambios ymodificaciones en los sistemas.

La existencia de documentacion de sistemas, de programas, deoperacidn y de usuario para cada aplicacidn ya implantada.

CONTROLES DE BACKUP Y REARRANQUE

Existencia de procedimientos de backup y rearranque documentados ycomprobados para cada aplicacidn en uso actualmente.

Procedimientos escritos para la transferencia de materiales ydocumentos de backup entre el C.P.D. principal y el sitio de backup(centro altemativo). Mantenimiento de un inventario de estosmateriales.

Existencia de un plan de contingencia.

Identification de aplicaciones y ficheros de datos criticos para el plande contingencia.

Revisar los contratos del plan de contingencia y backup paradeterminar su adecuacion y actualizacion.

Pruebas de aplicaciones criticas en el entomo de backup, con los

documentacion, personal, etc.).

Determination de cada aplicacidn que se revisa si es un sistema critieoy deberia incluirse en el plan de contingencia.

Grabacion de todas las transacciones ejecutadas por teleproceso, cadadia; para facilitar la reconstruction de ficheros actualizados durante eldia en caso de falio del sistema.

Existencia de proccsos manuales para sistemas criticos en ei caso delfailo de contingencia.

78 AUDJTORiA DE TECNOLOGIAS Y StSTEMAS DE INfORMACiON RA-MA

Actualizacion del plan de contingencia cuando es necesarlo; pruebasanuales.

C0NTROLES SOBRE PROGRAMAS DE AUDITORIA

Distribution de politicas y procedimientos escritos a auditores yresponsabJe de areas sobre la adquisicion, desarrollo y uso de softwarede auditoria.

Uso de software de auditona unicamente por personas autorizadas.

Participacion del auditor en la adquisicion, modification/adaptation,instalacion de paquetes de software de auditoria.

Participacion por el auditor en ia pianificacion, diseno, desarrollo eimplantation de software de auditoria desarrollado internamente.

Formation apropiada para IDS auditores que manejan software deauditona.

Participacion por el auditor en todas las modificaciones y adaptacionesdel software de auditoria, que sea de fuera o propio. Actualization dela documentation de software.

Verification de que los programas de utilidad se utilizan correctamente(cuando no se puede utilizar el software de auditoria auditoria).

Rcvisibn de tablas de contraseftas para asegurar que no se guardanidentificaciones y contrasefias de personas que han causado baja.

CONTROLES DE LA SATISFACTION DE LOS USUARIOS

Disponibilidad de politicas y procedimientos sobre el acceso y uso dela informacidn.

Resultados fiables, completos, punruales y exactos de las aplicaciones(integridad de datos).

Utilidad de la informacion de salida de la aplicacidn en la toma dedecision por los usuarios.

RA-MA CAPiTULO 3. MF.TODOi.OGiAS DE CONTROL INTERNO, SbGURiDAD - 79

Comprension por los usuarios desalida de las aplicaciones.

informes e informaciones de

Satisfaction de ios usuarios con ia informacion que produce laaplicacion.

Revision de ios controles de recepcion, archivo, proteccion y acceso dedatos guardados sobre todo tipo de soporte.

Participacion activa de los usuarios en la elaboracidn de requerimientosde usuarios, especificaciones de diseno de programas y revision deresuitados de pruebas.

Controles por ei usuario en !a transferencia de informaciones porintercambio de documentos.

Resolution feci! de problemas, errores, irregularidades y omisiones porbuenos contactos entre usuarios y el personal del C.P.D.

Revisiones rcgulares de procesos que podrtan mejorarse porautomatization de aspectos p articular es o reforzamientos de procesosmanuales.

3.3.U INFORMESLas recomendaciones son razonables, verificablcs, iriteresantes

economicamente y tienen en cuenta el tamano de la organization.

Para ser efectivo, el irtfotme da credito a! personal del area tevisadocuando se corrigen por ellos debilidades encontradas.

fuertes.

Ei informe tiene un tono constructivo. Si es apropiado se anotan los puntos

El lenguaje utilizado deberia contener un minimo de terminos tecnicos. Notardardn mas que cuatro semanas como maximo, despuds de las visitas al arearevisada. Para su distribucidn, se preparara un resumen del informe.

Despues de la revision del informe final con los responsables del &rearevisada se distribuira a las otras personas autorizadas.

80 AUDITORJA DE TECNQLOOiAS Y SlSTEMAS DE fNFORMAClON RA-MA

El area tiene la posibilidad de aceptar o rechazar cada punto de control.Todos los puntos rechazados se explicaran por escrito. El area acepta ios riesgosimplicitos de la debilidad encontrada por el auditor.

Se hace un seguimiento de la implantacidn de las recomendaciones, paraasegurarse que el trabajo-.de revision produce resultados concretes.

3.4 EL PLAN AUDITOR INFORMATICOEs el esquema metodologico mas importante del auditor informatico. En

este docurnento se debe describir todo sobre esfe funcion y el trabajo que realiza enla entidad. Debe estar en sintom'a con el plan auditor de! resto de los auditores de laentidad.

Las partes de un plan auditor informatico deben ser al menos las siguientes:

Funciones. Ubicacion de la figura en el organigrama de la empresa.Debe existir una clara segregation de funciones con la Informatica y decontrol interno informatico y este debe ser auditado asf mismo. Debendcscribirse las funciones dc forma precisa, y (a organization interna deldepartamento, con todos sus recursos.

Procedimientos para las distintas tareas de las auditorias. Entre ellosestan el procedimiento de apertura, el de entrega y discusidn dedebilidades, entrega de inibrme prelirninar, cierre de auditoria,redaction de informe final, etc.

Tipos de auditorias que realiza. Metodologias y cuestionarios de lasmismas. Ejemplo: revision de la aplicacion de facturacion, revisidn dela LOPD, revision de seguridad fisica, revision de control interno, etc.Exister ties tipos de auditorias segun su alcance, la Full o completa deuna area (ejemplo: control interno, informatica), limitada a un aspecto(ejemplo: una aplicacion, la seguridad iogica, el software de base, etc.),la Corrective Action Review (CAR) que es la comprobacion deacciones correctivas de auditorias anteriores.

Sistema de evaluation y los distintos aspectos que evalua.Independientemente de que exista un plan de acciones en el informefinal, debe hacerse el esfuerzo de definir varios aspectos a evaluarcomo nivel de gesticm economics, gestion de recursos humanos,cumplimiento de normas, etc. y realizar una evaluacidn global de

Q RA-MA CAPlTUt.O 3. METODOLOGIAS DE CONTROL INTERNO, SEGURIDAD... 81

resumen para toda la auditoria. Esta evaluacion en nuestro pais suelehacerse en tres niveles que son "Bien, Regular, o Mai", significando lavision de grado de gravedad. Esta evaluacidn final nos servira paradefinir la fecha de repetition de ia misma auditoria en el future segun.1 el nivel de exposition que se le haya dado a este tipo de auditoria en

cuestidn. (Veas