Página Caso práctico de una auditoría de seguridad informática

53  565  Descargar (4)

Texto completo

(1)
(2)
(3)

Auditoría de sistemas

Tabla de contenido

Página

Caso práctico de una auditoría de seguridad informática 1

Ciclo de seguridad 1

Causas de realización de una auditoría de seguridad 3

Estrategia y logística del ciclo de seguridad 4

Ponderación de los sectores auditados 5

Operativa del ciclo de seguridad 7

Cálculos y resultados del ciclo de seguridad 10

Plan de trabajo de evaluación de controles 13

Planeamiento del trabajo a realizar 14

Investigación preliminar 15

Evaluación del sistema 16

Documentación del sistema 16

Procedimiento del sistema 17

Operatividad del sistema 17

Controles del sistema 18

Generación del dato 18

Ingreso del dato 18

La transmisión del dato 19

El procesamiento del dato 20

Actualización de archivos 21

Emisión de reportes y consultas 21

Integridad de los datos 21

Validez de los resultados 22

Seguridad del sistema 22

Seguridad de acceso a la información 22

Seguridad del sistema 23

(4)

Auditoría de sistemas Fascículo No. 8

Cambios a los programas de aplicación 23

Seguridades físicas 24

Seguridades ante combinación de virus 24

Sistema de respaldo 25

Auditabilidad del sistema 26

Efectividad del sistema 26

Modalidades de pruebas 27

Pruebas de rutas 28

Pruebas de especificación 28

Niveles de prueba 28

Pruebas parciales 28

Pruebas del sistema 29

Pruebas especiales de sistema 29

Prueba de carga máxima 29

Prueba de almacenamiento 29

Prueba de tiempo de ejecución 29

Pruebas de recuperación 30

Prueba de procedimientos 30

Pruebas de factores humanos 30

Tipos de datos de prueba 31

Control interno al servicio informático 31

Evaluación y control de la organización 32

Evaluación funcional 32

Desarrollo de sistemas 32

Operación de sistemas 33

Mantenimiento de sistemas 33

Soporte técnico 34

Soporte a equipos de cómputo 34

Control de sistemas 34

(5)

Auditoría de sistemas

Metodologías 35

Recursos humanos 36

Seguridad 37

De los servicios externos de computación 37

Planeamiento de sistemas 38

Definición de requerimientos de sistema 38

Definición de especificaciones de requerimientos 38

Elaboración de términos de referencia de la subcontratación

de servicios externos de computación 39

Control de los servicios externos 39

Control de sistemas 39

Glosario de términos 40

Resumen 44

Bibliografía recomendada 45

(6)

Auditoría de sistemas Fascículo No. 8

Copyright©1999 FUNDACION UNIVERSITARIA SAN MARTIN Facultad de Contaduría Pública. Sistema de Educación Abierta y a Distancia. Santa Fe de Bogotá, D.C.

Prohibida la reproducción total o parcial sin autorización por escrito del Presidente de la Fundación.

La redacción de este fascículo estuvo a cargo de JAVIER OSWALDO GUECHA MARIÑO Sede Santa Fe de Bogotá, D.C.

Diseño instruccional y orientación a cargo de MARIANA BAQUERO DE PARRA

Diseño gráfico y diagramación a cargo de SANTIAGO BECERRA SAENZ ORLANDO DIAZ CARDENAS

(7)

1

Auditoría de sistemas

Caso práctico de una

auditoría de seguridad

informática

La auditoría de seguridad informática cobra especial importancia en las empresas que cuenten con sistemas de redes y comunicaciones, cen-tros de cómputo, de desarrollo de software o de los procesos operativos en los usuarios finales.

A continuación se presenta un caso de Auditoría de área general para proporcionar una visión más desarrollada y amplia de la función audito-ra. Se trata de una Auditoría de Seguridad Informática que tiene como misión revisar, tanto la seguridad física del Centro de Proceso de Datos en su sentido más amplio, como la seguridad lógica de datos, procesos y funciones informáticas más importantes de aquél.

Al terminar el estudio del presente fascículo, el estudiante:

 Explica cuáles son los pasos para realizar una Auditoría de Seguridad

In-formática que permite a las organizaciones evaluar el nivel de riesgos y controles.

Ciclo de seguridad

El objetivo de esta Auditoría de seguridad es revisar la situación y las cuotas de eficiencia de la misma en los órganos más importantes de la estructura informática.

(8)

2

Auditoría de sistemas Fascículo No. 8

 El área auditada es la seguridad. El área a auditar se divide en:

seg-mentos.

 Los segmentos se dividen en: secciones.

 Las secciones se dividen en: subsecciones.

 De este modo la Auditoría se realizará en 3 niveles.

Los segmentos a auditar, son:

 Segmento 1: seguridad de cumplimiento de normas y estándares.

 Segmento 2: seguridad de sistema operativo.

 Segmento 3: seguridad de software.

 Segmento 4: seguridad de comunicaciones.

 Segmento 5: seguridad de base de datos.

 Segmento 6: seguridad de proceso.

 Segmento 7: seguridad de aplicaciones.

 Segmento 8: seguridad física.

Se darán los resultados globales de todos los segmentos y se realizará un tratamiento exhaustivo del segmento 8, a nivel de sección y subsec-ción.

Conceptualmente la auditoría informática, en general, y la de seguridad, en particular, han de desarrollarse en seis fases bien diferenciadas:

Fase 0. Causas de la realización del ciclo de seguridad.

Fase 1. Estrategia y logística del ciclo de seguridad.

Fase 2. Ponderación de sectores del ciclo de seguridad.

Fase 3. Operativa del ciclo de seguridad.

Fase 4. Cálculos y resultados del ciclo de seguridad.

Fase 5. Confección del informe del ciclo de seguridad.

(9)

3

Auditoría de sistemas

0. Comienzo del proyecto de Auditoría Informática. 1. Asignación del equipo auditor.

2. Asignación del equipo interlocutor del cliente.

3. Diligenciamiento de formularios globales y parciales por parte del cliente.

4. Asignación de pesos técnicos por parte del equipo auditor. 5. Asignación de pesos políticos por parte del cliente.

6. Asignación de pesos finales a segmentos y secciones. 7. Preparación y confirmación de entrevistas.

8. Entrevistas, confrontaciones y análisis y repaso de documenta-ción.

9. Cálculo y ponderación de subsecciones, secciones y segmentos. 10.Identificación de áreas mejorables.

11.Elección de las áreas de actuación prioritaria.

12.Preparación de recomendaciones y borrador de informe. 13.Discusión de borrador con cliente.

14.Entrega del informe.

Causas de realización de una auditoría de

seguridad

Esta constituye la FASE 0 de la Auditoría y el orden 0 de actividades de la misma. El equipo auditor debe conocer las razones por las cuales el cliente desea realizar el Ciclo de Seguridad. Puede haber muchas cau-sas: reglas internas del cliente, incrementos no previstos de costes, obli-gaciones legales, situación de ineficiencia global notoria, etc.

(10)

4

Auditoría de sistemas Fascículo No. 8

Estrategia y logística del ciclo de seguridad

Constituye la FASE 1 del ciclo de seguridad y se desarrolla en las activi-dades 1, 2 y 3: designación del equipo auditor, asignación de interlocu-tores, validadores y decisores del cliente y diligenciamiento de un for-mulario general por parte del cliente, para la realización del estudio ini-cial.

Con las razones por las cuales va a ser realizada la Auditoría (Fase 0), el equipo auditor diseña el proyecto de Ciclo de Seguridad con arreglo a una estrategia definida en función del volumen y complejidad del trabajo a realizar, que constituye la Fase 1 del punto anterior.

Para desarrollar la estrategia, el equipo auditor necesita recursos mate-riales y humanos. La adecuación de estos se realiza mediante un desa-rrollo logístico, en el que los mismos deben ser determinados con exac-titud. La cantidad, calidad, coordinación y distribución de los menciona-dos recursos determina, a su vez, la eficiencia y la economía del Proyec-to.

Los planes del equipo auditor se desarrollan de la siguiente manera:

1. Eligiendo, el responsable de la Auditoría, su propio equipo de traba-jo. Este ha de ser heterogéneo en cuanto a especialidad, pero com-pacto.

2. Buscando en la empresa auditada los nombres de las personas de la misma que han de relacionarse con los auditores, para las peticio-nes de información, coordinación de entrevistas, entre otras cosas. 3. Mediante un estudio inicial, del cual forma parte el análisis de un

(11)

5

Auditoría de sistemas

Según los planes marcados, el equipo auditor, cumplidos los requisitos 1, 2 y 3, estará en disposición de comenzar la "tarea de campo", la ope-rativa auditora del ciclo de seguridad.

Ponderación de los sectores auditados

Este constituye la Fase 2 del Proyecto y engloba las siguientes activida-des:

FASE 2. Ponderación de sectores del ciclo de seguridad.

4. Asignación de pesos técnicos. Se entienden por tales las ponde-raciones que el equipo auditor hace de los segmentos y seccio-nes, en función de su importancia.

5. Asignación de pesos políticos. Son las mismas ponderaciones anteriores, pero evaluadas por el cliente.

6. Asignación de pesos finales a los segmentos y secciones. El pe-so final es el promedio del pepe-so técnico y del pepe-so político. La subsecciones se calculan pero no se ponderan.

Se pondera la importancia relativa de la seguridad en los diversos sectores de la organización informática auditada.

Las asignaciones de pesos a Secciones y Segmentos del área de seguridad que se audita, se realizan del siguiente modo:

Pesos técnicos

Son los coeficientes que el equipo auditor asigna a los Segmen-tos y a las Secciones.

Pesos políticos

(12)

6

Auditoría de sistemas Fascículo No. 8

Ciclo de Seguridad. Suma Pesos Segmentos = 100

(con independencia del número de segmentos consideradas) Segmentos Pesos Técnicos Pesos

Políticos Pesos Finales Seg1. Normas y Estándares 12 8 10 Seg2. Sistema Operativo 10 10 10 Seg3. Software Básico 10 14 12 Seg4. Comunicaciones 12 12 12 Seg5. Bases de Datos 12 12 12 Seg6. Procesos 16 12 14 Seg7. Aplicaciones 16 16 16 Seg8. Seguridad Física 12 16 14 TOTAL 100 100 100

Pesos finales

Son el promedio de los pesos anteriores.

El total de los pesos de los 8 segmentos es 100. Este total de 100 puntos es el que se ha asignado a la totalidad del área de Seguir-dad, como podría haberse elegido otro cualquiera. El total de puntos se mantiene cualquiera que hubiera sido el número de segmentos. Si hubieran existido cinco segmentos, en lugar de 8, la suma de los cinco habría de seguir siendo de 100 puntos.

Suma Peso Secciones = 20

(con independencia del número de Secciones consideradas) Secciones Pesos Técnicos Pesos

Políticos Pesos Finales Secc1. Seg. Física de Datos 6 6 6 Secc2. Control de Accesos 5 3 4 Secc3. Equipos 6 4 5 Secc4. Documentos 2 4 3 Secc5. Suministros 1 3 2 TOTAL 20 20 20

(13)

7

Auditoría de sistemas

no los considera tanto, a la vez que prima, tal vez excesivamente, el Software Básico.

Del mismo modo, se concede a todos los segmentos el mismo valor total que se desee, por ejemplo 20, con absoluta indepen-dencia del número de Secciones que tenga cada Segmento. En este caso, se han definido y pesado cinco Secciones del Seg-mento de Seguridad Física.

Cabe aclarar que sólo se desarrolló un Segmento, a modo de ejemplo.

Operativa del ciclo de Seguridad

Una vez asignados los pesos finales a todos los Segmentos y Seccio-nes, se comienza la Fase 3, que implica las siguientes actividades:

FASE 3.Operativa del ciclo de seguridad

7. Preparación y confirmación de entrevistas.

8. Entrevistas, pruebas, análisis de la información, cruzamiento y re-paso de la misma.

Las entrevistas deben realizarse con exactitud. El responsable del equi-po auditor designará a un encargado, dependiendo del área de la entre-vista. Este, por supuesto, deberá conocer a fondo la misma.

(14)

8

Auditoría de sistemas Fascículo No. 8

Deben realizarse varias entrevistas del mismo tema, al menos a dos o tres niveles jerárquicos distintos. El mismo auditor puede, y en ocasio-nes es conveniente, entrevistar a la misma persona sobre distintos te-mas. Las entrevistas deben realizarse de acuerdo con el plan estableci-do, aunque se puede llegar a agregar algunas adicionales y sin planifi-cación.

La entrevista concreta suele abarcar Subsecciones de una misma Sec-ción tal vez una secSec-ción completa. Comenzada la entrevista, el auditor o auditores formularán preguntas a los entrevistados. Debe identificarse quien a dicho qué, si son más de una las personas entrevistadas.

Las checklist’s son útiles y en muchos casos imprescindibles. Termina -das las entrevistas, el auditor califica las respuestas del auditado (quien no debe estar presente) y procede al levantamiento de la información correspondiente.

Simultáneamente a las entrevistas, el equipo auditor realiza pruebas pla-neadas y pruebas sorpresa para verificar y cruzar los datos solicitados y facilitados por el cliente. Estas pruebas se realizan ejecutando trabajos propios o repitiendo los de aquél, que indefectiblemente deberán ser si-milares si se han reproducido las condiciones de carga de los Sistemas auditados. Si las pruebas realizadas por el equipo auditor no fueran consistentes con la información facilitada por el auditado, se deberá re-cabar nueva información y reverificar los resultados de las pruebas audi-toras.

(15)

9

Auditoría de sistemas

A continuación se presenta, un ejemplo de Auditoría de la Sección de Control de Accesos del Segmento de Seguridad Física:

Vamos a dividir a la Sección de Control de Accesos en cuatro Subsec-ciones:

1. Autorizaciones

2. Controles Automáticos 3. Vigilancia

4. Registros

En las siguientes checklists, las respuestas se calificarán de 1 a 5, sien-do 1 la más deficiente y 5 la máxima puntuación.

Control de Accesos: Autorizaciones

Preguntas Respuestas Puntos

¿Existe un único responsable de implementar la política de autorizaciones de entrada en el Centro de Cálculo?

Si, el Jefe de Explotación, pero el Director puede acceder a la Sala con acompañantes sin previo aviso.

4

¿Existe alguna autorización permanente de

estancia de personal ajeno a la empresa? Una sola. El técnico permanente de la firma suministradora. 5 ¿Quiénes saben cuáles son las personas

autorizadas? El personal de vigilancia y el Jefe de proceso. 5 Además de la tarjeta magnética de

identificación, ¿hay que pasar otra especial? No, solamente la primera. 4 ¿Se pregunta a las visitas si piensan visitar el

Centro de Cálculo? No, vale la primera autorización. 3 ¿Se prevén las visitas al Centro de Cálculo

con 24 horas al menos? No, basta que vayan acompañados por el Jefe de Explotación o Director 3

TOTAL AUTORIZACIONES 24/30 80%

Control de Accesos: Controles Automáticos

Preguntas Respuestas Puntos

¿Cree Ud. que los Controles Automáticos son

adecuados? Sí, aunque ha de reconocerse que a pie puede llegarse por la noche hasta el edificio principal.

3

¿Quedan registradas todas las entradas y

(16)

10

Auditoría de sistemas Fascículo No. 8

número de entradas y salidas del personal de Operación?

¿Puede salirse del Centro de Cálculo sin

tarjeta magnética? Sí, porque existe otra puerta de emergencia que puede abrirse desde adentro

3

TOTAL CONTROLES AUTOMATICOS 14/20 70%

Control de Accesos: Vigilancia

Preguntas Respuestas Puntos

¿Hay vigilantes las 24 horas? Sí. 5 ¿Existen circuitos cerrados de TV exteriores? Sí. 5 Identificadas las visitas, ¿Se les acompaña

hasta la persona que desean ver? No. 2 ¿Conocen los vigilantes los terminales que

deben quedar encendidos por la noche? No, sería muy complicado. 2

TOTAL VIGILANCIA 14/20 70%

Control de Accesos: Registros

Preguntas Respuestas Puntos

¿Existe una adecuada política de registros? No, reconocemos que casi nunca, pero hasta ahora no ha habido necesidad. 1 ¿Se ha registrado alguna vez a una persona? Nunca. 1 ¿Se abren todos los paquetes dirigidos a

personas concretas y no a Informática? Casi nunca. 1 ¿Hay un cuarto para abrir los paquetes? Sí, pero no se usa siempre. 3

TOTAL REGISTROS 6/20 30%

Cálculos y resultados del ciclo de seguridad

Abarca la FASE 4 y las siguientes actividades:

FASE 4. Cálculos y resultados del ciclo de seguridad

1. Cálculo y ponderación de Secciones y Segmentos. Las Subsec-ciones no se ponderan, sólo se calculan.

(17)

11

Auditoría de sistemas

En el punto anterior se han realizado las entrevistas y se han puntuado las respuestas de toda la Auditoría de Seguridad. El trabajo de levanta-miento de información está concluido y contrastado con las pruebas. A partir de ese momento, el equipo auditor tiene en su poder todos los da-tos necesarios para elaborar el informe final. Sólo faltaría calcular el por-centaje de bondad de cada área; éste se obtiene calculando la sumato-ria de las respuestas obtenidas, recordando que deben afectarse a sus pesos correspondientes.

Una vez realizados los cálculos, se ordenarán y clasificarán los resulta-dos obteniresulta-dos por materias mejorables, estableciendo prioridades de actuación para lograrlas.

Cálculo del ejemplo de las Subsecciones de la Sección de Control de Accesos:

Autorizaciones: 80%

Controles Automáticos: 70% Vigilancia: 70%

Registros: 30%

Promedio de control de accesos: 62,5%

Cabe recordar, que dentro del Segmento de Seguridad Física, la Sec-ción de Control de Accesos tiene un peso final de 4.

Prosiguiendo con el ejemplo, se procedió a la evaluación de las otras cuatro Secciones, obteniéndose los siguientes resultados:

Ciclo de Seguridad: Segmento 8, Seguridad Física.

Secciones Peso Puntos

(18)

12

Auditoría de sistemas Fascículo No. 8

Conocidos los promedios y los pesos de las cinco Secciones, se proce-de a calcular y ponproce-derar el Segmento 8 proce-de Seguridad Física:

Seg. 8 = PromedioSección1 * peso + PromedioSecc2 * peso + PromSecc3 * peso + PromSecc4 * peso + PromSecc5 * peso / (peso1 + peso2 + peso3 + peso4 + peso5)

Seg. 8 = (57,5 * 6) + (62,5 * 4) + (70 * 5) + (52,5 * 3) + (47,2 * 2) / 20

Seg. 8 = 59,85%

A continuación, la evaluación final de los demás Segmentos del ciclo de Seguridad:

Ciclo de Seguridad. Evaluación y pesos de Segmentos

Segmentos Pesos Evaluación

Seg1. Normas y Estándares 10 61% Seg2. Sistema Operativo 10 90% Seg3. Software Básico 12 72% Seg4. Comunicaciones 12 55% Seg5. Bases de Datos 12 77,5% Seg6. Procesos 14 51,2% Seg7. Aplicaciones 16 50,5% Seg8. Seguridad Física 14 59,8% Promedio Total Área de Seguridad 100 63,3%

Proceso para el cálculo y evaluación del Ciclo de Seguridad:

a. Valoración de las respuestas a las preguntas específicas realiza-das en las entrevistas y a los cuestionarios formulados por escri-to.

b. Cálculo matemático de todas las Subsecciones de cada sección, como media aritmética (promedio final) de las preguntas específi-cas. Recuérdese que las Subsecciones no se ponderan.

(19)

13

Auditoría de sistemas

d. Cálculo matemático del Segmento. Cada una de las Secciones que lo componen se afecta por su peso correspondiente. El re-sultado es el valor del Segmento, el cual, a su vez, tiene asignado su peso.

e. Cálculo matemático de la Auditoría. Se multiplica cada valor de los Segmentos por sus pesos correspondientes, la suma total ob-tenida se divide por el valor fijo asignado a priori a la suma de los pesos de los segmentos.

Finalmente, se procede a mostrar las áreas auditadas con gráficos de barras, exponiéndose primero los Segmentos, luego las Secciones y por último las Subsecciones. En todos los casos se referenciarán res-pecto a tres zonas: roja, amarilla y verde.

La zona roja corresponde a una situación de debilidad que requiere acciones a corto plazo. Serán las más prioritarias, tanto en la exposición del Informe como en la toma de medidas para la corrección.

La zona amarilla corresponde a una situación discreta que requiere acciones a medio plazo, figurando a continuación de las contenidas en la zona roja.

La zona verde requiere solamente alguna acción de mantenimiento a largo plazo.

Plan de trabajo de evaluación de controles

Para efectuar el control, el especialista deber establecer su plan de tra-bajo, el cual debe basarse en pasos y etapas a ejecutar, en un plazo de-terminado y contemplar las etapas siguientes:

(20)

14

Auditoría de sistemas Fascículo No. 8

b. Investigación preliminar. c. Evaluación del sistema.

d. Planeamiento y diseño de las pruebas de control.

e. Ejecución y evaluación de los resultados de las pruebas. f. Confección del informe de auditoría del sistema.

g. Revisión y opinión del informe.

h. Seguimiento de las recomendaciones de auditoría.

Planeamiento del trabajo a realizar

Consiste en la estrategia que conduzca al logro de los objetivos concre-tos y a las expectativas de la Alta Dirección en el menor tiempo posible, para lo cual se elabora el plan de trabajo que permita medir el avance del trabajo en puntos claves y administrar eficientemente los recursos de tiempo y personal que sean asignados.

En el documento de planeación se debe considerar lo siguiente:

Objetivo general del trabajo a realizar. En forma concreta se plan-tean los objetivos del trabajo.

Alcances del trabajo a realizar. Se marcan los escenarios de ries-gos que deben ser examinados en el trabajo, pudiendo ser todos o solamente algunos.

Puntos de Interés para este trabajo. Se registran los aspectos que requieren especial atención, de acuerdo con los antecedentes que se conozcan de la aplicación o de otras similares y de la información que se procesa con ella.

(21)

15

Auditoría de sistemas

Duración estimada. Comprende la suma de los tiempos estimados asignados a cada una de las etapas (desde la b) hasta la h)).

Fechas de inicio y terminación. Para el desarrollo completo de las actividades del proyecto.

Diagrama de actividades. Se coloca el tiempo estimado que va a durar cada una de las actividades.

Entrevista de iniciación de auditoría. Se realiza una reunión con el personal directivo de Sistemas en la cual se plantean los objetivos y el enfoque de trabajo a realizar y se establecen los mecanismos de comunicación a emplear en el desarrollo del trabajo.

Investigación preliminar

Se determinan las características técnicas y operativas de la aplicación objeto del trabajo y su importancia para los objetivos y metas de la Insti-tución.

Se debe conseguir la documentación del sistema, para que en el trabajo de gabinete pueda investigarse, en forma preliminar, el Sistema, con la siguiente información:

 Dependencias involucradas en el manejo de la aplicación.

 Inventario de documentos fuentes.

 Inventario de informe que produce.

 Normas legales e institucionales que rigen el funcionamiento de

 la aplicación.

 Interfases de la aplicación con otros sistemas.

 Procesos manuales y automatizados que realiza la aplicación.

 Perfil técnico de la aplicación.

 Personal clave para el manejo de la aplicación en cada dependencia

(22)

16

Auditoría de sistemas Fascículo No. 8

 Inventario de manuales de documentación existente.

 Información sobre fraudes que se hayan cometido.

Evaluación del sistema

Al evaluar el sistema también deben considerarse los riesgos, determi-nándose cuáles son las situaciones de riesgo y cuáles sus causas.

Para evaluar los controles existentes se debe utilizar una de las dos al-ternativas, o ambas: análisis de riesgo y/o cuestionarios de control.

Riesgos accidentales:

 Ingreso accidental vía en apertura.

 Falla imprevista que anula seguridad.

 Error en sistema de comunicación.

Aspectos a revisar

Los aspectos que deben ser revisados son: 1- La documentación del sistema.

2- El procedimiento del sistema. 3- La operatividad del sistema. 4- Controles del sistema. 5- Integridad de los datos. 6- Validez de los resultados. 7- Seguridad del sistema. 8- Sistema de respaldo. 9- Auditabilidad del sistema. 10- Efectividad del sistema.

Documentación del sistema

(23)

17

Auditoría de sistemas

además de tomar conocimiento escrito del mismo, revisar si se ha cum-plido con la metodología y estándares establecidos para el desarrollo de sistemas, anotando las falencias para su evaluación en los pasos si-guientes, ya que podrían ser causa de problemas del sistema en opera-ción.

Procedimiento del sistema

Todo sistema es un conjunto de procesos manuales y automatizados, cuya operacionalización debe estar definida en un Procedimiento del Sistema. Es imprescindible la existencia del procedimiento formal para efectos de poder operar eficientemente y con eficacia el sistema.

Operatividad del sistema

Una vez revisada la documentación del Sistema, se deber proceder a revisar su operatividad. Se revisa todo el ciclo del sistema:

 Generación del Dato.

 Ingreso del Dato al sistema.

 Transmisión del Dato.

 Procesamiento del Dato.

 Actualización de Archivos.

 Emisión de Reportes y Consultas.

Se debe verificar que el sistema efectúe, en cada etapa de su ciclo, las especificaciones establecidas en el Análisis y Diseño y se cumpla con el procedimiento aprobado para el sistema.

(24)

18

Auditoría de sistemas Fascículo No. 8

Controles del sistema

Generación del dato

Deben verificarse las condiciones en que se genera el dato, ya sea que exista externo o interno a la Institución, revisando que sea veraz y con-sistente y que refleje exactamente la operación realizada. Se podrá to-mar una muestra de datos para efectos de verificar su exactitud. El siste-ma debe contemplar, como uno de sus controles, el efectuar muestreos de calidad de los datos con una frecuencia preestablecida.

Ingreso del dato

Debe revisarse que el ingreso o digitación de los datos se efectúe cum-pliendo con controles básicos, tal como se indica:

 Si el sistema es descentralizado, que el dato sea ingresado por el

mismo que lo genera, para tener un mayor control sobre la calidad del ingreso del dato, ya que dicha persona es la que más conoce la información y es la responsable de la misma.

En el caso de que sean varias personas las que tengan que ingresar datos porque la organización establece responsabilidades diferen-ciadas, debe constatarse que el sistema registre de alguna forma el código del digitador del dato, para los controles del caso.

(25)

19

Auditoría de sistemas

 Que los programas de ingreso de datos tengan consistencia física y

lógica de datos. La consistencia física debe ser sobre el registro de datos en sí, donde deben existir datos obligatorios y opcionales y rangos de valores de los datos. La consistencia lógica debe ser con-tra los archivos maestros del sistema y concon-tra reglas de validación cruzadas que deba cumplir la información.

 Que los datos ingresados deban imprimirse como validación del

in-greso de datos, de la forma más conveniente, dependiendo de la na-turaleza del sistema. Si el ingreso de datos es desde terminales y en ventanillas de atención al público, debe efectuarse una revisión vi-sual previa y debe imprimirse el comprobante producto del ingreso del conjunto de datos y al final del turno o día de trabajo, debe emi-tirse un parte diario de comprobación y cuadre.

Si el ingreso de datos es desde terminales, pero en forma de proce-so en lotes, al final de cada lote debe imprimirse un listado de revi-sión visual y de cuadre para poder ser revisado con todos los docu-mentos fuentes, si el volumen de registros es manejable, o por técni-ca de muestreo, cuando existe una técni-cantidad considerable de regis-tros. Al final del día debe adicionalmente imprimirse un parte diario de los lotes ingresados.

La transmisión del dato

En un sistema en línea la transmisión del dato desde el terminal a la Ba-se de Datos Central es manejado por el Software de Comunicaciones, Software de Red y Software de Base de Datos, debiendo en este caso:

 El Sistema aplicativo debe tener rutinas programadas que controlen

(26)

termi-20

Auditoría de sistemas Fascículo No. 8

nal, si su configuración de equipo lo permite, y posterior transmisión y registro en la base de datos central.

 En un sistema de proceso en lotes, la transmisión del dato puede

ser vía disquetes o modems. En este caso debe verificarse:

- Que los disquetes sean probados previamente antes de su

remi-sión y que quede un medio de respaldo en el centro de ingreso de datos.

- Asimismo que se les coloque en modo protegido contra escritura

y esté claramente identificado, en su etiqueta, el número o núme-ros de lote y la cantidad de registnúme-ros que contiene.

 Para el caso de transmisión de datos vía modem, el archivo a

trans-mitir debe poseer un registro de encabezado de control que indique el número o números de lote y la cantidad de registros que contiene, debiendo el aplicativo leer dicha información y efectuar la verifica-ción de la informaverifica-ción del registro encabezado con los registros leí-dos.

El procesamiento del dato

Comprende los procesos manuales y automatizados que se realizan pa-ra producir los resultados previstos en las diferentes funciones que sa-tisface el sistema. Se da especial énfasis a los controles incluidos en el software de las aplicaciones para lograr exactitud y confiabilidad del proceso y de los resultados que produce.

(27)

21

Auditoría de sistemas

Para asegurar la integridad del procesamiento de los datos, en los siste-mas en línea debe contarse con las seguridades físicas tales como UPS y equipos de respaldo de energía eléctrica de tal forma que evite el trun-camiento del procesamiento y desincronización de su operación.

En los casos de los sistemas de procesamiento en lotes deben existir procedimientos computarizados para que los programas se ejecuten en la secuencia prevista y de acuerdo con las bifurcaciones establecidas.

Actualización de archivos

Debe verificarse que existan registros y rutinas de control que, con cier-ta frecuencia de tiempo o de período, determinen si existe coherencia entre la cantidad de registros y valores de los totales de los archivos. Por ejemplo, si se ha producido una cantidad de nuevas entidades debe reflejarse en un incremento del número de registros del archivo princi-pal. Al final del día debería producirse un reporte de integridad de archi-vos.

Emisión de reportes y consultas

Deben existir rutinas de control y procedimientos que permitan, al final de un período, cuadrar cifras entre reportes y consultas, que aseguren la integridad de los resultados emitidos. Cada sistema, según su natura-leza, tiene una lógica de cuadre entre reportes, la cual debe estar clara-mente definida en el procedimiento.

Integridad de los datos

(28)

22

Auditoría de sistemas Fascículo No. 8

Deben asimismo, en forma externa, establecerse procedimientos de comparación de la información producida por el sistema contra otras informaciones disponibles, para efectos de determinar la confiabilidad de la información. Dentro de este aspecto están las circularizaciones de comprobación de la información del computador con las áreas o perso-nas involucradas.

Validez de los resultados

El aspecto más importante de todo el sistema son los resultados, por lo que al revisar el sistema debe verificarse que los resultados cumplan con las especificaciones del diseño del sistema, lo cual debe compro-barse mediante juegos de datos de pruebas especialmente preparados, y que prueben todas las posibilidades de las entidades, datos y situa-ciones.

Seguridad del sistema

Debe comprobarse que el Sistema cuente con los siguientes tipos de seguridad: seguridad en el acceso a la información, seguridad del siste-ma y seguridades físicas.

Seguridad de acceso a la información

Debe existir, a nivel institución, un esquema global de seguridad de acceso a la información, donde deben existir para cada área y para ca-da funcionario, los perfiles de acceso a los sistemas, a las funciones dentro de cada sistema y a la base de datos, constituyendo una matriz de acceso para los usuarios versus sistemas-funciones donde el nivel de usuario es el código de cada funcionario.

(29)

23

Auditoría de sistemas

datos, procesamiento de los datos, consultas por niveles, emisión de re-portes.

Asimismo el sistema debe mantener un log de uso del sistema por se-sión de trabajo. Los niveles de acceso a la información pueden ser:

 Nivel de consulta de información no restringida.

 Nivel de mantenimiento de la información no restringida.

 Nivel de consulta incluyendo la información restringida.

 Nivel de mantenimiento de la información restringida.

Seguridad del sistema

Acceso y seguridad a los programas

El área de servicio informático debe ser la única que debe tener acceso sobre los programas fuentes, que deberán estar archivados en bibliote-cas especiales, bajo control de un Administrador de Sistemas.

Asimismo, los programas objetos también deben tener nombres sólo conocidos por el administrador del sistema, quien coloca los nombres claves una vez recibidos y compilados los programas fuentes.

En la medida de lo posible, dependiendo de la envergadura del Servicio Informático y de la naturaleza de los sistemas, se de-bería tratar de utilizar un Software de Resguardo Automático de Redes.

Cambios a los programas de aplicación

(30)

24

Auditoría de sistemas Fascículo No. 8

objetos debe tenerlo el Administrador de Sistemas, y cualquier cambio a los programas debe ser probado y sólo reemplazado, después de de-mostrarse la confiabilidad del mismo. Cuando se cambien los progra-mas fuentes deben documentarse en el programa con comentarios y re-gistrar las modificaciones en el Registro de Control de Cambios.

Asimismo el sistema debe contar con los elementos necesarios para po-der darle mantenimiento, por lo que debe disponer de:

- Manuales de análisis y diseño. - Manual de programación. - Programas fuentes.

- Originales de software de base.

- Personal de programación que conozca el sistema.

Seguridades físicas

Los ambientes donde se procesan los sistemas deben contar con un suministro de energía eléctrica de calidad, con pozo de línea a tierra, es-tabilizadores, UPS, equipos de reemplazo de energía eléctrica, y extinto-res contra incendio.

Debe también, en la medida de lo posible, disponer el acceso restringi-do al área restringi-donde se procesa la información, sea al ambiente de los digi-tadores o al centro de cómputo.

Seguridad ante contaminación de Virus

(31)

25

Auditoría de sistemas

Deben, establecerse disposiciones específicas que prohíban al personal de sistemas o usuarios, utilizar disquetes externos a la institución, para evitar la introducción de virus. En caso de recibir disquetes externos de trabajo oficial, deberán ser desinfectados antes de ser leídos por los equipos de cómputo.

Cuando sea factible, tal es el caso de sistemas que requieren sólo termi-nales, es preferible que éstos no tengan unidad de disquete para evitar la contaminación o infección. En lo posible también deber tratarse de utilizar Sistemas Operativos, que eviten la contaminación por virus.

Sistema de respaldo

Previendo posibles problemas con el hardware o el software es necesa-rio que el equipo central cuente con características técnicas de respaldo tales como:

- Sistema tolerante a fallas. - Tape-backup.

- Equipo de capacidad similar de respaldo.

Asimismo, debe contarse con elementos para ser cargados en el otro equipo de respaldo:

- Instalador del Sistema o Backup del Sistema.

- Backup de la Base de Datos por lo menos del turno anterior.

(32)

26

Auditoría de sistemas Fascículo No. 8

Los backups de la Base de Datos deben efectuarse por cada cambio de turno de trabajo o como mínimo al final del día, debiendo el sistema, in-clusive, haber sido programado para que exija efectuar el backup res-pectivo.

Una copia de respaldo de los programas fuentes y objetos de las aplica-ciones, de la plataforma de software y de las bases de datos completas de la Institución (hasta de tres períodos anteriores), debe guardarse en el local ad-hoc de la Institución e inclusive una copia adicional en otro local para afrontar siniestros o desastres que pudieran ocurrir.

Auditabilidad del sistema

Todo sistema debe tener la capacidad de poder ser auditado, para lo cual debe reunir una serie de características que lo permitan:

 Contar con la documentación completa.

 Disponer de una biblioteca de pruebas.

 Disponer de Log del Sistema.

 Contar con reportes de Auditoría del sistema.

 Contar con reporteadores de base de datos para producir reportes

de cruce de información.

Por lo tanto deber verificarse que el sistema disponga de los elementos antes indicados para poder facilitar su Auditoría y en caso de no contar con ellos exigir se disponga de ellos.

Efectividad del sistema

(33)

27

Auditoría de sistemas

 Efectuar visitas a los usuarios e indagar sobre su opinión respecto a:

su satisfacción de los resultados del sistema y el grado de confiabili-dad que le dan al sistema.

 Evaluar en forma independiente en qué magnitud los beneficios han

sido conseguidos y cuáles son las razones o limitaciones que impi-den que éstos se logren.

 Determinar si los costos de operación del sistema se encuentran

dentro de lo planificado y si son actualmente razonables para los be-neficios tangibles e intangibles obtenidos.

Se deben evaluar aspectos tales como:

- Qué mejoras se han obtenido en la reducción de costos de

opera-ción.

- Qué mejoras se han obtenido en las operaciones de la Institución.

- Cuánto ha mejorado la precisión de la información obtenida.

- Qué mejoras se han obtenido en disponer de la información

com-pleta requerida.

- Qué mejoras se han obtenido respecto a incluir controles en las

operaciones de la Institución.

- Qué incrementos se han obtenido en el número de operaciones

atendidas, mejorando el tiempo de atención a los usuarios.

- Qué incremento de productividad de la institución se ha obtenido.

- Qué mejoras se han producido en la organización de la tarea

invo-lucrada en el sistema.

Modalidades de pruebas

(34)

28

Auditoría de sistemas Fascículo No. 8

Pruebas de rutas

También es conocida como prueba de código. Examina la lógica del programa, para lo cual se desarrollan casos de prueba que fuercen a probar la ejecución de todas las instrucciones de cada módulo o ruta de un programa.

Como un sistema puede tener cientos de módulos, debe priorizarse cuáles son los más críticos de ser probados, de tal forma que se pueda probar dentro de plazos y costos razonables las rutas más importantes del sistema.

Pruebas de especificación

En éstas, se examina el sistema bajo diferentes situaciones. Que ejecute lo que indican las especificaciones, bajo casos de pruebas preparados para dicho fin.

En este caso se trata a los programas como si fueran cajas ne-gras, sólo siendo de interés que si se cumplen siempre las es-pecificaciones, el sistema no falla.

Niveles de prueba

Existen 2 niveles: pruebas parciales y pruebas de sistemas.

Pruebas parciales

Estas consisten en probar, independientemente, los módulos de un sis-tema que llevan a cabo una función específica. A su vez existen dos mé-todos para llevar a cabo estas pruebas:

(35)

29

Auditoría de sistemas

 Método descendente: van de los módulos superiores a los inferiores.

Pruebas del sistema

No prueba el detalle de cada módulo, sino más bien la integración de cada módulo en el sistema, buscando las discrepancias que ocurran y la falta de compatibilidad entre ellos.

Pruebas especiales de sistema

Existen 6 pruebas básicas: prueba de carga máxima, prueba de almace-namiento, prueba de tiempo de ejecución, prueba de recuperación, prueba de procedimientos, prueba de recursos humanos.

Prueba de carga máxima

Consiste en probar si el sistema puede manejar el volumen de activida-des que ocurren cuando el Sistema está en el punto más alto de su de-manda de procesamiento, tanto en número de transacciones, número de terminales y magnitud de los valores.

Prueba de almacenamiento

Determinar si el sistema puede almacenar una alta cantidad proyectada de datos, tanto en sus dispositivos de discos fijos y removibles, y según el diseño y configuración de los archivos.

Prueba de tiempo de ejecución

Determina el tiempo de máquina que el sistema necesita para procesar los datos de una transacción, si en su máxima carga (volumen de infor-mación y número de terminales simultáneos) el tiempo de respuesta es adecuado para las funciones de:

(36)

30

Auditoría de sistemas Fascículo No. 8

 Actualización.

 Transmisión.

 Proceso.

 Reordenamiento e indexación de archivos.

 Consultas.

 Impresiones de comprobantes y listados.

Pruebas de recuperación

Probar la capacidad del sistema para recuperar datos y restablecerse después de una falla. Para efectuar estas pruebas se deben previamen-te sacar copias de respaldo de los archivos reales.

Prueba de procedimientos

Evaluar la claridad, validez seguridad así como su facilidad de uso y sencillez de los manuales de procedimientos y operación respecto a la operación real del Sistema, haciendo que los usuarios lleven a cabo exactamente lo que el manual pide.

Los manuales deben contener una guía de respuestas ante mensajes de advertencia, error, o contingencia. Asimismo se debe verificar su ac-tualización y concordancia con la versión del software aplicativo al cual pertenecen.

Prueba de factores humanos

Se determina cómo utilizarán los usuarios el sistema al procesar datos o preparar informes.

(37)

31

Auditoría de sistemas

Evaluar, respecto a los usuarios: el nivel de capacitación, el grado de utilización del sistema, su correcta aplicación o uso.

Evaluar, respecto al personal de informática: el nivel tecnológico para operar el sistema y la disponibilidad de técnicos con capacidad de mantener el sistema.

Tipos de datos de prueba

Datos reales: los cuales permiten probar ocurrencias y casos reales que se presentan en la Institución, aunque no permiten probar otras rutas programadas pero que no han sido alcanzados por los usua-rios para las pruebas en el caso de sistemas en desarrollo, o que no ocurren actualmente en el período de prueba de los sistemas en fun-cionamiento.

Datos artificiales: son los que se crean artificialmente tratando de considerar todas las combinaciones y rutas posibles, debiendo, en lo posible, ser preparados por personas distintas de las que progra-maron el sistema.

Se recomienda contar con una Biblioteca de Pruebas que es un conjun-to de daconjun-tos preparados para probar conjun-todo el sistema en su conjunconjun-to y que se utiliza tanto cuando se desarrolla el sistema, como cuando se audita y se hacen modificaciones al software, debiendo archivarse en una biblioteca especialmente organizada para tal fin. Esto también per-mite que con la misma biblioteca puedan probarse los sistemas interre-lacionados.

Control interno al servicio informático

(38)

pue-32

Auditoría de sistemas Fascículo No. 8

de tener problemas que afectan al Sistema, por lo que también debe ha-cerse un "Control Interno al Servicio de Informática".

El Control Interno al Servicio de Informática debe contemplar:  La organización.

 Los procedimientos generales.

 Metodologías utilizadas.

 Recursos humanos.

 Seguridad.

Evaluación y control de la organización

Se debe verificar que por un concepto de integralidad, existan funciones claramente definidas que obligatoriamente deben efectuarse y que exis-tan grupos de trabajo diferenciados, que permiexis-tan delimitar responsabi-lidades y dinamizar la gestión de informática. Las funciones que deben existir son:

- Desarrollo de sistemas. - Operación de sistemas. - Mantenimiento de sistemas. - Soporte técnico.

- Soporte a equipos. - Control de sistemas.

La magnitud de la organización del servicio informático, depende tam-bién de la envergadura de la Institución. Sin embargo, debe existir la di-visión funcional que permita su adecuado desenvolvimiento.

Evaluación funcional

Desarrollo de Sistemas

(39)

33

Auditoría de sistemas

pos de personal con funciones que puedan desarrollarse independien-temente y en forma permanente, sin restringir la capacidad de desarro-llo por razones de carga operativa de trabajo.

Operación de sistemas

Esta debe ser efectuada por personal operativo, encargado de que los sistemas operen adecuadamente, tanto en el Centro de cómputo, como en las áreas usuarias descentralizadas.

Con el fin de realizar esta función deben existir, para cada sistema, los Manuales de Operación respectivos, los cuales deben contener:

 El proceso normal.

 Mensajes de advertencia y error.

 Recomendaciones para la solución a los mensajes presentados.

 Puntos de reinicio.

 Comunicación de problemas.

Mantenimiento de sistemas

La ubicación de la función de mantenimiento de sistemas, depende del estado evolutivo del área de servicio informático, es así que si recién se inicia un plan ambicioso de desarrollo de sistemas, es preferible no dis-traerlo en funciones de mantenimiento de sistemas y ubicarla como una unidad del área de Operación de Sistemas. Sin embargo si gran parte del desarrollo del sistema ya ha sido efectuado, es conveniente ubicar la función de mantenimiento de sistemas dentro del área de Desarrollo de Sistemas.

(40)

34

Auditoría de sistemas Fascículo No. 8

Soporte técnico

Todo Servicio de Informática debe también desarrollar funciones de so-porte técnico, por el continuo avance tecnológico. Dependiendo de la magnitud de la Institución ésta puede ser desarrollada desde un solo especialista hasta contar con una unidad especializada, donde se dé soporte a las plataformas que se utilicen o que se tengan que imple-mentar en la Institución en el ámbito de Sistema Operativo, Base de Da-tos, Comunicaciones y equipos de cómputo.

Para fines de soporte técnico es muy importante que exista un registro de fallas y solicitudes, así como de atención de sopor-tes técnicos brindados.

Soporte a equipos de cómputo

Dependiendo también de la envergadura de la Institución debe realizar-se la función de atención a los problemas de los equipos de cómputo; debe existir una persona o una unidad que se encargue de dicho aspec-to, ya sea dando atención directa o administrando un servicio externo de mantenimiento y solución de problemas de los equipos de cómputo.

Deben existir registros de:  Equipos existentes.

 Software instalado en cada equipo.

 Mantenimientos realizados a cada equipo firmados por el proveedor,

soporte técnico y usuario.

Control de sistemas

(41)

35

Auditoría de sistemas

su funcionamiento. Que efectúe coordinaciones para evaluar la satisfac-ción del usuario, control a los planes y presupuestos y seguimiento de las observaciones a los sistemas.

En pequeñas empresas puede ser llevado a cabo por la Jefatura del Servicio Informático. En medianas, por un Especialista Contralor, o una unidad para los casos de Empresas de envergadura.

Procedimientos

Debe verificarse que existan normas y procedimientos precisos para la realización de sus funciones, de tal forma que se apliquen estándares y metodologías comunes que den integralidad a las actividades.

Las normas que deberían disponer son:  Norma de análisis de sistemas.

 Norma de diseño de sistemas.

 Norma de programación de sistemas.

 Norma de implantación de sistemas.

 Norma de operación de sistemas.

 Norma de mantenimiento de sistemas.

 Norma de control de sistemas.

Los procedimientos que debieran estar disponibles son:  Procedimientos de Operación de todos los Sistemas.

 Procedimiento General de Seguridad.

 Procedimiento General de Respaldo de la Información.

 Procedimientos ante Contingencias.

Metodologías

(42)

36

Auditoría de sistemas Fascículo No. 8

 Planeamiento de Sistema

 Análisis de Sistemas :

- Entrevistas.

- Diagrama de flujo de datos (D.F.D.). - Modelación de datos.

- Diagrama de estructura de datos (D.E.D.). - Historia de vida de la entidad (H.E.V.). - Análisis de costo-beneficio (A.C.B.). - Prototipeo.

 Diseño de Sistemas

- Diseño estructurado.

- Diagrama de estructura de cuadros. - Optimización del diseño físico. - Diseño de pruebas.

- Prototipeo.  Programación

- Programación estructurada. - Pruebas unitarias.

- Pruebas de integración. - Prueba del sistema.

 Implantación de Sistemas

- Capacitación.

- Creación de archivos iniciales. - Proceso en paralelo.

Recursos humanos

(43)

37

Auditoría de sistemas

recursos humanos por área, de tal forma que no existan desequilibrios que afecten el desempeño del Servicio Informático en su conjunto.

Debe analizarse si los tiempos utilizados para la obtención de resulta-dos en cada uno de los tipos de actividades son los adecuaresulta-dos y se efectúan dentro de los plazos razonables.

Seguridad

Debe comprobarse que el área de Servicios Informáticos cuente con los siguientes tipos de seguridad:

 Seguridad en el acceso a la información.

 Seguridad de los sistemas.

 Seguridades físicas.

De los servicios externos de computación

Dependiendo de la política de la Institución puede ser encargado el de-sarrollo, la implantación y la operación de uno o varios sistemas a servi-cios externos de computación. En estos casos también deben aplicarse los mismos controles y verificaciones indicados en la presente norma, donde el área de Informática de la Institución deber efectuar permanen-temente la tarea de fiscalización de los Servicios Externos de Computa-ción.

En estos casos se deben reforzar, en el área de Informática, las siguien-tes funciones:

 Planeamiento de sistemas.

 Definición de requerimientos de sistemas.

 Especificación de requerimientos.

 Elaboración de términos de referencia de subcontratación de

(44)

38

Auditoría de sistemas Fascículo No. 8

 Control de los servicios externos.

 Control de sistemas.

Cuando se realicen actividades de Auditoría del área de Infor-mática debe evaluarse el desempeño de las funciones antes mencionadas ya que son de primordial importancia cuando se trabaja bajo subcontrataciones.

Planeamiento de sistemas

Es preferible que el Planeamiento de Sistemas lo realice el área de Infor-mática de la propia Institución, ya que el personal se encuentra involu-crado con sus objetivos y metas, y experimenta permanentemente las vivencias de su organización. Sin embargo, muchas veces el trabajo Planeamiento de Sistemas es encargado a un Servicio Externo; en todo caso, éste debe tomarse como una Asesoría y la participación del área de Informática considerarse fundamental.

Definición de requerimientos de sistema

Es conveniente que la definición de requerimientos de sistema por parte de las diferentes áreas de la Institución, sea determinado por el área de Informática, ya que permite efectuar una priorización del desarrollo y mantenimiento de sistemas desde el punto de vista institucional, y plan-tear la subcontratación de los servicios externos de computación en la medida de las necesidades.

Definición de especificaciones de requerimientos

(45)

39

Auditoría de sistemas

minos de referencia de las subcontrataciones de Servicios Externos de Computación.

Elaboración de términos de referencia de la

subcontratación de servicios externos de

computación

En los Términos de Referencia de Subcontratación de Servicios Exter-nos de Computación, deben establecerse claramente las normas, meto-dologías y plataformas que se utilizarán para mantener estándares e In-tegralidad dentro de la Institución. También debe quedar claramente es-pecificado que estarán sujetos a los mecanismos de control estableci-dos en las presentes normas, tanto durante el desarrollo de sistemas, como durante su funcionamiento si así fuera del caso.

Control de los servicios externos

Los Servicios Externos de Computación deben ser controlados con ba-se en la función subcontratada aplicando, para cada caso, la parte co-rrespondiente de las normas y controles establecidos en el presente do-cumento.

Control de sistemas

(46)

40

Auditoría de sistemas Fascículo No. 8

8.1

Utilizando el levantamiento y análisis de riesgos de una empresa, ela-bore el cuadro de evaluación de los controles respectivos.

Análisis de costo beneficio: es una técnica utilizada en el Análisis de Sistemas que tiene como objetivo fundamental proporcionar una medida de los costos en que se incurre en la realización de un pro-yecto informático y, a su vez, comparar dichos costos previstos con los beneficios esperados en la realización de dicho proyecto.

Análisis de sistemas: es el proceso mediante el cual se estudian e interpretan los hechos del sistema actual, con el fin de especificar los requerimientos y especificaciones funcionales del nuevo sistema a desarrollar.

Confiabilidad del sistema: se define que un sistema es confiable cuando posee los controles y las seguridades del caso, permitiendo que sus resultados sean exactos y que su operación sea estable y segura.

Diseño estructurado: es una técnica utilizada en el Diseño de Siste-mas, para obtener la estructura modular y los detalles de proceso del sistema, partiendo solamente de la información obtenida en la fa-se de análisis de sistemas. En esta fa-se define cómo debe estructurar-se el sistema utilizando herramientas gráficas.

(47)

41

Auditoría de sistemas

Diagrama de estructura de datos (DED): es una técnica utilizada en el Análisis de Sistemas para la modelación de datos, la cual re-presenta un conjunto de datos relacionados entre sí y describe en forma colectiva un componente del sistema.

Diagrama de flujo de datos (DFD): proporciona una representación del sistema a nivel lógico y conceptual, describiendo el movimiento de los datos en el sistema, ya sea manual o automático, incluyendo procesos y lugares para almacenar datos.

Diagramas de Gantt: son herramientas que se utilizan en la planifi-cación de un proyecto o etapa del mismo, y que consiste en el regis-tro de lo planificado y de lo ejecutado a través de barras de diferente diseño en dos ejes: una de actividades y la otra de la variable tiem-po.

Diseño de pruebas: es una técnica utilizada en el Diseño de Siste-mas que consiste en definir un programa de pruebas, para asegurar la confiabilidad del diseño y de que no existen errores en los progra-mas que se especifiquen.

Diseño de sistemas: es el proceso de definición de la arquitectura de software: componentes, módulos, interfaces, procedimientos de pruebas y datos de un Sistema que se crean para satisfacer unos re-querimientos específicos.

Entrevistas: es una técnica que se utiliza en el Análisis de Sistemas para buscar la información verbal, a través de una serie de preguntas que propone el analista. Esta, a su vez, es imprescindible para obte-ner información cualitativa, relacionarse con los usuarios y recoger un conjunto de hechos y/o requerimientos de información necesaria para el estudio.

(48)

identifi-42

Auditoría de sistemas Fascículo No. 8

cados y descritas en los Diagramas de Estructura de Datos (DED) y en las transacciones o eventos del sistema identificado en el Diagra-ma de Flujo de Datos (DFD). También constituye un poderoso instru-mento para verificar la exactitud de los dos modelos antes mencio-nados y garantizar la coherencia entre las tres versiones del sistema.

Implantación de sistemas: es el proceso por el cual se instala un sistema, se crean los archivos maestros, se capacita al personal in-volucrado, se procesa un período de información, se efectúan ajus-tes al sistema y se inicia la producción del sistema.

Integración de sistemas: es el proceso por el cual se analizan, dise-ñan y programan las interfases entre diferentes aplicaciones, subsis-temas y sissubsis-temas, de tal forma que no se desarrollen sissubsis-temas aisla-dos, sino más bien interconectados que compartan archivo y base de datos comunes y se transfieran información entre ellos.

Integridad de la información: consiste en que los valores de los da-tos se mantengan tal como fueron puesda-tos intencionalmente en el Sistema. Las técnicas de integridad sirven para prevenir que existan valores errados en los datos provocados por el software de la Base de Datos o por fallas de programas o del sistema. El concepto de in-tegridad abarca la precisión y la fiabilidad de los datos, así como la discreción que se debe tener con ellos.

Integridad del sistema: es una característica que deben poseer los sistemas computarizados. Consiste en que se deben tener las segu-ridades de que el software no puede ser alterado ni la información producida puede ser accesada por personas no autorizadas, para lo cual deben existir los controles y seguridades del caso.

(49)

43

Auditoría de sistemas

Optimización del diseño físico: es una técnica utilizada en el Dise-ño de Sistemas para optimizar el modelo de datos elaborado en la fase de Análisis de Sistemas, permitiendo obtener la estructura física del sistema, así como la representación óptima de la información.

PERT-CPM: es una técnica que se utiliza en la planificación de proyectos o etapas del mismo, y que consiste en el registro de las actividades, recursos y costos planificados, así como los ejecutados realmente mediante representación gráfica de nodos y fechas de de-pendencia de actividades.

Plataforma de hardware: es el conjunto de equipos que se utiliza para desarrollar y operar un sistema o todos los sistemas de una or-ganización, comprendiendo el Computador Central, las estaciones de trabajo tales como terminales, equipos de microcomputación, im-presoras, así como equipos de comunicación local en Red o remo-tas.

Plataforma de software: es el conjunto de software de base y apli-cativos de uso general que se utiliza para un sistema determinado o para toda la organización, compuesto por los sistemas operativos, sistemas de bases de datos, sistemas de redes, sistemas de comu-nicaciones y sistemas generales de automatización de oficinas.

Proceso en paralelo: es una técnica utilizada en la implantación de sistemas, que consiste en permitir que se siga utilizando el sistema anterior, mientras se procesa paralelamente el nuevo sistema, de tal forma que se puedan comparar resultados y efectuar el reemplazo necesario con la seguridad de la correcta operatividad y confiabili-dad del nuevo sistema.

(50)

44

Auditoría de sistemas Fascículo No. 8

Programación de sistemas: es el proceso por el cual el diseño de un sistema se transcribe a un lenguaje de programación que pueda ser interpretado por el computador, para que éste ejecute instruc-ciones que realicen las funinstruc-ciones, especificadas para el nuevo siste-ma.

Prototipeo: es una técnica utilizada en el Análisis de Sistemas y Di-seño de Sistemas, que permite desarrollar, con rapidez, un sistema de trabajo computarizado para posibilitar la prueba del diseño ante el usuario en un software provisional que permite analizar, en forma física, el ingreso de los datos, el procesamiento y la emisión de re-sultados, y efectuar los ajustes necesarios para el diseño definitivo.

Pruebas de integración: son las que deben realizarse para probar la integración entre los componentes del sistema y asegurarse que encajen correctamente.

Pruebas del sistema: son las que deben realizarse para probar el sistema globalmente.

Pruebas unitarias: son las que deben realizarse para probar todos los componentes del sistema que se desarrollan individualmente.

Respaldo de la información: es la información que se archiva en un medio alternativo al del almacenamiento de un computador con el fin de disponer de una copia de seguridad por si ocurriesen pérdidas del sistema o la información.

(51)

45

Auditoría de sistemas

sas tienen toda su información estructurada en Sistemas Informáticos, de aquí la vital importancia que los sistemas de información funcionen correctamente. La empresa de hoy, debe informatizarse.

El éxito de una empresa depende de la eficiencia de sus sistemas de in-formación. Una empresa puede tener un staff de gente de primera, pero también un sistema informático propenso a errores, lento, vulnerable e inestable; si no hay un balance entre estas dos cosas, la empresa nunca saldrá adelante. En cuanto al trabajo de la Auditoría en sí, podemos re-saltar que se precisa de gran conocimiento de Informática, seriedad, ca-pacidad, minuciosidad y responsabilidad; la Auditoría de Sistemas debe hacerse por gente altamente capacitada, una Auditoría mal hecha pue-de acarrear consecuencias drásticas para la empresa auditada, princi-palmente en el aspecto económico.

Hernández Hernández, Enrique. Auditoría en Informática. México: Edito-rial CECSA, 2000.

(52)

46

(53)

47

Auditoría de sistemas

AAAuuutttoooeeevvvaaallluuuaaaccciiióóónnnfffooorrrmmmaaatttiiivvvaaa

Auditoría de sistemas - Fascículo No. 8

Nombre_____________________________________________________________________ Apellidos ________________________________________ Fecha ____________________ Ciudad _________________________________________ Semestre __________________

1. ¿Cuáles son las fases de una auditoría de Seguridad?

2. ¿Cuál es el plan de trabajo para evaluar controles?

Figure

Tabla de contenido Página

Tabla de

contenido Página p.3

Referencias

Actualización...