Академический Документы
Профессиональный Документы
Культура Документы
SANTO TOMS
ARICA
METODOLOGA
PARA REALIZAR UNA AUDITORA
DE SEGURIDAD INFORMTICA
PROYECTO DE TTULO PARA OPTAR AL TITULO
PROFESIONAL DE: INGENIERIA (E) EN INFORMATICA
ALUMNO:
JOHNNY SEGUNDO MAITA ZARZURI
PROFESOR GUA:
SR. CESAR VALDENEGRO ORTIZ
ARICA 2015
DEDICATORIA
Primeramente a Dios por haberme permitido llegar hasta este punto de mi vida, lleno
de batallas y continuas luchas que obtuve en mi etapa como estudiante, por su infinito amor, por
haberme dado vida y salud, logrando as todos mis objetivos.
AGRADECIMIENTOS
Agradezco a los Profesores del rea de Informtica de este Instituto Profesional, Sr.
Juan Stanovich, Sr. Edward Villar, Sr. Boris Gutirrez, Sr. Eugenio Gana y Sra. Gloria Tarque,
por transmitir sus conocimientos en las horas de clases, por el gran apoyo y motivacin que me
entregaron para la culminacin de mis estudios, por los malos ratos que les hice pasar junto con mis
compaeros, por su dedicacin y entrega para formar buenos profesionales y por sus consejos que
siempre fueron recibidos de buena manera y a quienes recordare por siempre.
DEDICATORIA.............................................................................................................. II
AGRADECIMIENTOS...................................................................................................III
NDICE DE TABLAS....................................................................................................VI
NDICE DE FIGURAS.................................................................................................VII
GLOSARIO................................................................................................................ VIII
RESUMEN.................................................................................................................... X
I.
II.
FUNDAMENTOS..................................................................................................1
I.1
INTRODUCCIN.....................................................................................1
I.2
II.1.1
II.1.2
II.1.3
II.1.4
II.1.5
II.2
III.
LA AUDITORIA INFORMTICA...............................................................7
III.1.1
III.1.2
III.1.3
III.2
III.2.1
Los Cuestionarios..................................................................12
III.2.2
Entrevistas........................................................................... 13
III.2.3
Checklist.............................................................................. 13
III.2.4
III.2.5
Software De Interrogacin.......................................................18
III.3
III.3.1
Auditora Interna....................................................................20
III.3.2
Auditora Externa...................................................................20
III.3.3
III.4
III.4.1
III.4.2
Tipos de Auditoria...................................................................24
III.4.3
III.4.4
III.4.5
Planificacin de la Auditoria.....................................................26
III.4.6
III.4.7
III.4.8
Informe de Auditora...............................................................32
III.4.9
III.4.10
III.4.11
36
III.4.12
Procesos de Auditora.............................................................48
III.4.13
Evaluacin de la Seguridad......................................................52
III.5.
INFORME FINAL..................................................................................70
III.5.1
IV.
PRODUCTO FINAL............................................................................................74
AUDITORA DE SEGURIDAD INFORMATICA REALIZADA A LA SECCIN O.S.7 ARICA
75
V.
ASPECTOS COMPLEMENTARIOS...................................................................87
V.1
CONCLUSIN........................................................................................87
V.2
BIBLIOGRAFA.......................................................................................88
V.3
ANEXOS................................................................................................89
ANEXO 1............................................................................................................ 89
ANEXO 2............................................................................................................ 90
ANEXO 3............................................................................................................ 91
NDICE DE TABLAS
Tabla 1. ESTRUCTURA DE PROGRAMA DE AUDITORA........................................29
NDICE DE FIGURAS
Figura 1. UBICACIN DE LA SECCION O.S7 ARICA.................................................3
Figura 2. FOTOGRAFA DE LA SECCIN O.S.7 ARICA.............................................3
Figura 3. LOGO DE CARABINEROS DE CHILE.........................................................4
Figura 4. LOGO DE LA SECCIN O.S.7......................................................................4
Figura 5. JEFE DE SECCIN.......................................................................................5
Figura 6. JEFE AREA DE INTELIGENCIA OPERATIVOS...........................................5
Figura 7. ORGANIGRAMA O.S.7 ARICA.....................................................................5
Figura 8. SISTEMAS DE CARABINEROS...................................................................6
Figura 9. PARTICIPANTES DE UNA AUDITORA........................................................7
Figura 10. PLAN DE CONTINGENCIA PARA UN BACKUP......................................11
Figura 11. HERRAMIENTAS Y TECNICAS DE UNA AUDITORA.............................12
Figura 12. SELECCIN DE UNA AUDITORA...........................................................19
Figura 13. AUDITORA INTERNA...............................................................................20
Figura 14. AUDITORA EXTERNA.............................................................................20
Figura 15. ESTANDARES DE SEGURIDAD DE AUDITORA....................................25
Figura 16. CARTA GANTT DE UNA AUDITORA INFORMATICA.............................30
GLOSARIO
Aplicacin: Aunque se suele utilizar indistintamente como sinnimo genrico de programa es
necesario subrayar que se trata de un tipo de programa especficamente dedicado al proceso de una
funcin concreta dentro de la empresa.
Archivo de datos: Cualquier archivo creado dentro de una aplicacin: por ejemplo, un documento
creado por un procesador de textos, una hoja de clculo, una base de datos o un grfico. Tambin
denominado Documento.
Archivo de programa:
Auditor: Persona que efecta una auditora.
Auditora: Examen de las operaciones de una empresa por especialistas ajenos a ella y con objetivos
de evaluar la situacin de la misma.
Cliente: Cliente o 'programa cliente' es aquel programa que permite conectarse a un determinado
sistema, servicio o red.
Confidencialidad: Se refiere a que la informacin solo puede ser conocida por individuos
autorizados.
Costos estimados: Son los clculos anticipados de los gastos que predominarn en el futuro (mano
de obra, material, etc), dentro de un periodo dado, con la intencin de pronosticar un costo total.
Datos: Trmino general para la informacin procesada por un ordenador.
Factibilidad: Es la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas
sealadas, sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello
tomar la mejor decisin.
Gobernabilidad de TI:
Hardware: Conjunto de dispositivos de los que consiste un sistema. Comprende componentes tales
como el teclado, el Mouse, las unidades de disco y el monitor.
Integridad: La habilidad de determinar que la informacin recibida es la misma que la informacin
enviada.
10
Servidor o server: Ordenador que ejecuta uno o ms programas simultneamente con el fin de
distribuir informacin a los ordenadores que se conecten con l para dicho fin. Vocablo ms conocido
bajo su denominacin inglesa 'server'.
Sistema de informacin: Se denomina Sistema de Informacin al conjunto de procedimientos
manuales y/o automatizados que estn orientados a proporcionar informacin para la toma de
decisiones.
Software: Componentes inmateriales del ordenador: como los programas, sistemas operativos, etc.
T.I: Tecnologas de la Informacin.
Tcnicas: Conjunto de procedimientos de una ciencia los cuales nos ayudan a solucionar problemas.
RESUMEN
INSTITUTO PROFESIONAL SANTOTOMAS
INGENIERIA DE EJECUCIN EN INFORMATICA
ARICA
2 SEMESTRE DEL AO 2015
AUDITORA DE
SEGURIDAD INFORMTICA
Autor
Profesor Gua
11
I.
I.1
FUNDAMENTOS
INTRODUCCIN
12
El auditor debe realizar un anlisis profundo de todos los componentes que integran el
sistema informtico, velar por la correcta utilizacin de los recursos que la empresa pone en juego
para disponer de un eficiente y eficaz sistema de informacin. Claro est que para la realizacin de
una auditoria de seguridad y que esta pueda resultar, se debe entender a la empresa en su ms
amplio sentido, ya que esta sea pblica o privada, todas utilizan a la informtica para gestionar sus
negocios de forma rpida y eficiente con el fin de obtener beneficios econmicos y reduccin de
costos, ya que un sistema mal diseado puede resultar muy peligroso y perjudicial para la empresa.
I.2
13
Que la empresa ha diseado controles eficaces para resolver sus requisitos de cumplimiento y
que no hay errores en el diseo.
Que la empresa aplica consistentemente los controles diseados y que no existen deficiencias
operativas.
II.
II.1
: Carabineros de Chile
Seccin O.S.7 Arica.
Direccin Arica
RUT
: 66.505.000-K
Telfono
: (58) 2458061
Correo electrnico
: os7.arica@carabineros.cl
Pgina web
: http://www.carabineros.cl
14
II.1.2
de la Repblica, Coronel de Ejrcito Don Carlos Ibez del Campo, en virtud del D.F.L. N 2.484, que
fusion la Polica Fiscal con el Cuerpo de Carabineros, instituciones policiales existentes a la fecha y
cuya historia, naturaleza y carcter explican los slidos fundamentos que tiene Carabineros de Chile.
La Seccin O.S.7 Arica depende de la Zona Norte Control Drogas e Investigacin
Criminal perteneciente a Carabineros de Chile (Polica de carcter militar y con presencia en todo el
territorio chileno), y fue creada el 11 de febrero del ao 1977, como la 3 Seccin Control Drogas y
Estupefacientes de Arica y tena por misin cumplir las funciones contempladas en la ley 17.934.
15
N 20.000
II.1.3
II.1.4
SECCION
16
II.1.5
II.2
computadores como a todo elemento que forma parte de l. Entindase impresoras, proyectores,
UPS, dispositivos de conectividad, etc. lo que conlleva a que todo el sistema tanto computacional
como tecnolgico funcione al 100%.
17
Adems pude participar en la supervisin de los sistemas actuales que mantiene esa
Institucin y capacitacin a la mayora los funcionarios, en relacin a uso y cuidado de los elementos
tecnolgicos e computacionales. Adems pude participar en la planificacin, desarrollo y
programacin de un proyecto Informtico, como lo es el Sistema R A.C. (Registro y Anlisis
Carretero), cuyo objetivo es registrar en el sistema a todos los vehculos que ingresen a la Zona Norte
y mantener una estadstica actual, para as evaluar e identificar posibles delitos.
Figura 8.
SISTEMAS DE CARABINEROS
III.
III.1
LA AUDITORIA INFORMTICA.
18
El trabajo de campo del auditor consiste en lograr toda la informacin necesaria para la
emisin de un juicio global objetivo, siempre amparado en hechos demostrables, llamados tambin
evidencias.
III.1.1
III.1.2
19
auditora interna existe por expresa decisin de la empresa, o sea, que puede optar por su disolucin
en cualquier momento.
Por otro lado, la auditora externa es realizada por personas afines a la empresa
auditada; es siempre remunerada. Se presupone una mayor objetividad que en la auditora Interna,
debido al mayor distanciamiento entre auditores y auditados.
La auditora en informtica interna cuenta con algunas ventajas adicionales muy
importantes respecto de la auditora externa, las cuales no son tan perceptibles como en las
auditorias convencionales. La auditora interna tiene la ventaja de que puede actuar peridicamente
realizando revisiones globales, como parte de su Plan Anual y de su actividad normal. Los auditados
conocen estos planes y se habitan a las auditorias, especialmente cuando las consecuencias de las
recomendaciones habidas benefician su trabajo.
Una Empresa o Institucin que posee auditora interna puede y debe en ocasiones
contratar servicios de auditora externa. Las razones para hacerlo suelen ser:
Necesidad de auditar una materia de gran especializacin, para la cual los servicios propios
no estn suficientemente capacitados.
20
Contrastar algn Informe interno con el que resulte del externo, en aquellos supuestos de
emisin interna de graves recomendaciones que chocan con la opinin generalizada de la
propia empresa.
Servir como mecanismo protector de posibles auditorias en informtica
decretadas por la misma empresa.
externas
III.1.3
Las empresas acuden a las auditorias en informtica cuando existen sntomas que son
claramente perceptibles y que indican debilidad. Estos sntomas pueden agruparse en clases:
21
No se cumplen en todos los casos los plazos de entrega de resultados peridicos. Pequeas
desviaciones pueden causar importantes desajustes en la actividad del usuario, en especial
en los resultados de aplicaciones crticas y sensibles.
Planes de Contingencia:
Por ejemplo, la empresa sufre un corte total de energa o de aluna forma sufre una
explosin, Cmo sigo operando en otro lugar?, Lo que generalmente se pide es que se hagan
Backups de la informacin diariamente y que aparte, sea doble, para tener un Backup en la empresa
y otro afuera de sta.
22
Una empresa puede tener unas oficinas paralelas que posean servicios bsicos (luz,
telfono, agua) distintos de los de la empresa principal, es decir, si a la empresa principal le provea
telfono la compaa Entel y a las oficinas paralelas la compaa Telefnica. En este caso, si se
produce una inoperancia de Sistemas en la empresa principal, se utilizara el Backup para seguir
operando en las oficinas paralelas. Los Backups se pueden acumular durante dos meses, o el tiempo
que estipule la empresa, y despus se van reciclando a travs del tiempo.
III.2
23
III.2.1
Los Cuestionarios.
III.2.2
Entrevistas.
24
preestablecido de antemano
III.2.3
Checklist.
El auditor profesional y experto es aqul que elabora muchas veces sus cuestionarios
en funcin de los escenarios auditados. Tiene claro lo que necesita saber y por qu. Sus
cuestionarios son vitales para el trabajo de anlisis, cruzamiento y sntesis posterior, lo cual no quiere
decir que haya que someter al auditado a unas preguntas innecesarias que no conducen a nada. Muy
por el contrario, el auditor conversar y har preguntas "normales", que en realidad servirn para la
complementacin sistemtica de sus Cuestionarios..
Hay opiniones que descalifican el uso de las Checklists, ya que consideran que leerle
una pila de preguntas recitadas de memoria o ledas en voz alta descalifica al auditor informtico. El
profesionalismo pasa por un procesamiento interno de informacin a fin de obtener respuestas
coherentes que permitan una correcta descripcin de puntos dbiles y fuertes. El profesionalismo
pasa por poseer preguntas muy estudiadas que han de formularse flexiblemente.
25
a. Checklist de rango:
Contiene varias preguntas que el auditor debe puntuar dentro de un rango
preestablecido (por ejemplo, de 1 a 5, siendo 1 la respuesta ms negativa y el 5 el valor ms positivo)
Ejemplo de un Checklist de rango:
26
4. Aceptable.
5. Correcto.
Se figuran posibles respuestas de los auditados. Las preguntas deben sucederse sin
que parezcan encorsetadas ni clasificadas previamente. Basta con que el auditor lleve un pequeo
guin. La complementacin del Checklist no debe realizarse en presencia del auditado, como se
muesra a continuacion:.
Existe personal especfico de vigilancia externa al edificio?
No, solamente un guarda por la noche que atiende adems otra instalacin adyacente.
<Puntuacin: 1 >
Para la vigilancia interna del edificio, Hay al menos un vigilante por turno en los
aledaos del Centro de Clculo?
S, pero sube a las otras 4 plantas cuando se le necesita. <Puntuacin: 2>
Hay salida de emergencia adems de la habilitada para la entrada y salida de
mquinas?
S, pero existen cajas apiladas en dicha puerta. Algunas veces las quitan. <Puntuacin: 2>
El personal de Comunicaciones, Puede entrar directamente en la Sala de
Computadoras?
No, solo tiene tarjeta el Jefe de Comunicaciones. No se la da a su gente salvo causa muy
justificada, y avisando casi siempre al Jefe de Explotacin. <Puntuacin: 4>
El resultado sera el promedio de las puntuaciones: (1 + 2 + 2 + 4)= 9 / 4 = 2,25 Que sera
deficiente.
b. Checklist Binaria:
Esta opcin est constituida por preguntas con dos respuestas nicas y excluyente: Si
o No. Aritmticamente, equivalen a 1 (uno) o 0(cero), respectivamente.
Ejemplo de Checklist Binaria:
Se supone que se est realizando una Revisin de los mtodos de pruebas de programas en el
mbito de Desarrollo de Proyectos.
27
Existe Normativa de que el usuario final compruebe los resultados finales de los programas?
<Puntuacin: 1>
Conoce el personal de Desarrollo la existencia de la anterior normativa? <Puntuacin: 1>
Se aplica dicha norma en todos los casos? <Puntuacin: 0>
Existe una norma por la cual las pruebas han de realizarse con juegos de ensayo o copia de
Bases de Datos reales? <Puntuacin: 0>
No existen checklists estndar para todas y cada una de las instalaciones informticas
a auditar. Cada una de ellas posee peculiaridades que hacen necesarios los retoques de adaptacin
correspondientes en las preguntas a realizar.
III.2.4
28
Con frecuencia, el auditor informtico debe verificar que los programas, tanto de los
sistemas como del usuario se realizan exactamente las funciones previstas, y no otras. Para ello se
apoya en productos Software muy potentes y modulares que, entre otras funciones, rastrean los
caminos que siguen los datos a travs del programa.
Del mismo modo, el Sistema genera automticamente una exacta informacin sobre el
tratamiento de errores de la maquina central, perifricos, etc. (La auditora financiero-contable
convencional emplea trazas con mucha frecuencia. Son programas encaminados a verificar lo
correcto de los clculos de nminas, primas, etc.).
*Log:
El log vendra a ser un historial que informa que fue cambiando y cmo fue cambiando
(informacin). Las bases de datos, por ejemplo, utilizan el log para asegurar a lo que llamamos las
transacciones. Las transacciones son unidades atmicas de cambios dentro de una base de datos;
toda esa serie de cambios se encuadra dentro de una transaccin, y todo lo que va haciendo la
Aplicacin (grabar, modificar, borrar) dentro de esa transaccin, queda grabado en el log. La
29
transaccin tiene un principio y un fin, cuando la transaccin llega a su fin, se vuelca todo a la base
de datos. Si en el medio de la transaccin hubo una interrupcin por alguna razn, lo que se hace es
volver para atrs. El log te permite analizar cronolgicamente que es lo que sucedi con la
informacin que est en el Sistema o que existe dentro de la base de datos.
III.2.5
Software De Interrogacin.
Cabe recordar, que en la actualidad casi todos los usuarios finales poseen datos e
informacin parcial generada por la organizacin informtica de la Compaa.
Efectivamente, conectados como terminales al "Host", almacenan los datos
proporcionados por este, que son tratados posteriormente en modo PC. El auditor se ve obligado
(naturalmente, dependiendo del alcance de la auditora) a recabar informacin de los mencionados
usuarios finales, lo cual puede realizar con suma facilidad con los polivalentes productos descritos.
Con todo, las opiniones ms autorizadas indican que el trabajo de campo del auditor informtico debe
realizarse principalmente con los productos del cliente.
30
III.3
III.3.1
Auditora Interna.
31
III.3.2
Auditora Externa.
III.3.3
32
33
III.4
34
Una vez obtenidos los resultados, se detallan, archivan y reportan a los responsables
quienes debern establecer medidas preventivas de refuerzo y/o correccin siguiendo siempre un
proceso secuencial que permita a los administradores mejorar la seguridad de sus sistemas
aprendiendo de los errores cometidos con anterioridad.
Las auditoras de seguridad informtica permiten conocer en el momento de su
realizacin cul es la situacin exacta de sus activos de informacin en cuanto a proteccin, control y
medidas de seguridad.
III.4.1
35
III.4.3
36
III.4.4
Se requieren varios pasos para realizar una auditora. El auditor de sistemas debe
evaluar los riesgos globales y luego desarrollar un programa de auditoria que consta de objetivos de
control y procedimientos de auditoria que deben satisfacer esos objetivos.
El proceso de auditoria exige que el auditor de sistemas rena evidencia, evale
fortalezas y debilidades de los controles existentes basado en la evidencia recopilada, y que prepare
un informe de auditora que presente esos temas en forma objetiva a la gerencia. Asimismo, la
gerencia de auditoria debe garantizar una disponibilidad y asignacin adecuada de recursos para
realizar el trabajo de auditoria adems de las revisiones de seguimiento sobre las acciones
correctivas emprendidas por la gerencia.
III.4.5
Planificacin de la Auditoria.
Al planificar una auditoria, el auditor de sistemas debe tener una comprensin de suficiente del
ambiente total que se revisa. Debe incluir una comprensin general de las diversas prcticas
comerciales y funciones relacionadas con el tema de la auditoria, as como los tipos de sistemas que
se utilizan. El auditor de sistemas tambin debe comprender el ambiente normativo en el que opera el
negocio. Por ejemplo, a un banco se le exigir requisitos de integridad de sistemas de informacin y
de control que no estn presentes en una empresa manufacturera. Los pasos que puede llevar a
cabo un auditor de sistemas para obtener una comprensin del negocio son: Recorrer las
instalaciones del ente. Lectura de material sobre antecedentes que incluyan publicaciones sobre esa
industria, memorias e informes financieros. Entrevistas a gerentes claves para comprender los temas
comerciales esenciales. Estudio de los informes sobre normas o reglamentos. Revisin de planes
estratgicos a largo plazo. Revisin de informes de auditoras anteriores.
III.4.5.2
37
Se puede definir los riesgos de auditoria como aquellos riesgos de que la informacin
pueda tener errores materiales o que el auditor de sistemas no pueda detectar un error que ha
ocurrido. Los riesgos en auditoria pueden clasificarse de la siguiente manera:
Riesgo inherente: Cuando un error material no se puede evitar que suceda por que no
existen controles compensatorios relacionados que se puedan establecer.
Riesgo de Control: Cuando un error material no puede ser evitado o detectado en forma
oportuna por el sistema de control interno.
Riesgo de deteccin: Es el riesgo de que el auditor realice pruebas exitosas a partir de un
procedimiento inadecuado.
El auditor puede llegar a la conclusin de que no existen errores materiales cuando en
realidad los hay. La palabra "material" utilizada con cada uno de estos componentes o riesgos, se
refiere a un error que debe considerarse significativo cuando se lleva a cabo una auditoria.
En una auditoria de sistemas de informacin, la definicin de riesgos materiales
depende del tamao o importancia del ente auditado as como de otros factores. El auditor de
sistemas debe tener una cabal comprensin de estos riesgos de auditoria al planificar. Una auditoria
tal vez no detecte cada uno de los potenciales errores en un universo. Pero, si el tamao de la
muestra es lo suficientemente grande, o se utiliza procedimientos estadsticos adecuados se llega a
minimizar la probabilidad del riesgo de deteccin.
De manera similar al evaluar los controles internos, el auditor de sistemas debe percibir
que en un sistema dado se puede detectar un error mnimo, pero ese error combinado con otros,
puede convertir en un error material para todo el sistema. La materialidad en la auditoria de sistemas
debe ser considerada en trminos del impacto potencial total para el ente en lugar de alguna medida
basado en lo monetario
III.4.5.3
38
III.4.6
III.4.6.1
Procedimientos de Auditora.
III.4.6.2
39
PROCEDIMIENTOS DE
AUDITORIA
LUGAR
PAPELES
TRABAJO
REFERENCIA
HECHO
POR FECHA:
40
polticas o procedimientos son eficaces, esto se puede registrar en el avance del cumplimiento del
Programa (Ver el Anexo 2).
III.4.6.3
41
Los recursos deben comprender tambin las habilidades con las que cuenta el grupo
de trabajo de auditoria y el entrenamiento y experiencia que estos tengan. Tener en cuenta la
disponibilidad del personal para la realizacin del trabajo de auditoria, como los perodos de
vacaciones que estos tengan, otros trabajos que estn realizando, etc.
III.4.7
42
III.4.8
Informe de Auditora.
Los informes de auditora son el producto final del trabajo del auditor de sistemas, este
informe es utilizado para indicar las observaciones y recomendaciones a la gerencia, aqu tambin se
expone la opinin sobre lo adecuado o lo inadecuado de los controles o procedimientos revisados
durante la auditoria, no existe un formato especfico para exponer un informe de auditora de sistemas
de informacin, pero generalmente tiene la siguiente estructura o contenido:
Introduccin al informe, donde se expresara los objetivos de la auditoria, el perodo o alcance
cubierto por la misma, y una expresin general sobre la naturaleza o extensin de los
procedimientos de auditoria realizados.
Observaciones detalladas y recomendaciones de auditoria.
Respuestas de la gerencia a las observaciones con respecto a las acciones correctivas.
Conclusin global del auditor expresando una opinin sobre los controles y procedimientos
revisados.
III.4.8.1
43
III.4.8.2
Objetivos.
44
Alcance.
Estructura Orgnico-Funcional del rea
Informtica.
El conjunto de disposiciones metdicas: Cuyo fin es vigilar las funciones y actitudes de las
empresas y para ello permite verificar si todo se realiza conforme a los programas adoptados,
rdenes impartidas y principios admitidos.
III.4.9
Controles Preventivos: Son aquellos que reducen la frecuencia con que ocurren las causas
del riesgo, permitiendo cierto margen de violaciones.
Ejemplos: Letrero "No fumar" para salvaguardar las instalaciones o actualizar el
sistemas de claves de acceso.
Controles Detectivos: Son aquellos que no evitan que ocurran las causas del riesgo sino que
los detecta luego de ocurridos. Son los ms importantes para el auditor. En cierta forma sirven
para evaluar la eficiencia de los controles preventivos.
Ejemplo: Archivos y procesos que sirvan como pistas de auditoria y los procedimientos
de validacin.
Controles Correctivos: Ayudan a la investigacin y correccin de las causas del riesgo. La
correccin adecuada puede resultar difcil e ineficiente, siendo necesaria la implantacin de
controles detectivos sobre los controles correctivos, debido a que la correccin de errores es
en s una actividad altamente propensa a errores.
III.4.9.1
Existen Controles particulares tanto en la parte fsica como en la parte lgica. Los
cambios de las claves de acceso a los programas se deben realizar peridicamente. Normalmente los
usuarios se acostumbran a conservar la misma clave que le asignaron inicialmente. El no cambiar las
claves peridicamente aumenta la posibilidad de que personas no autorizadas conozcan y utilicen
claves de usuarios del sistema de computacin.
45
Para redefinir claves es necesario considerar los tipos de claves que existen:
Individuales: Pertenecen a un solo usuario, por tanto es individual y personal. Esta clave
permite al momento de efectuar las transacciones registrar a los responsables de cualquier
cambio.
Confidenciales: De forma confidencial los usuarios debern ser instruidos formalmente
respecto al uso de las claves.
No significativas: Las claves no deben corresponder a nmeros secuenciales ni a nombres o
fechas.
Verificacin de datos de entrada: Incluir rutinas que verifiquen la compatibilidad de los datos
mas no su exactitud o precisin; tal es el caso de la validacin del tipo de datos que contienen
los campos o verificar si se encuentran dentro de un rango.
Conteo de registros: Consiste en crear campos de memoria para ir acumulando cada
registro que se ingresa y verificar con los totales ya registrados.
Totales de Control: Se realiza mediante la creacin de totales de lnea, columnas, cantidad
de formularios, cifras de control, etc., y automticamente verificar con un campo en el cual se
van acumulando los registros, separando solo aquellos formularios o registros con diferencias.
Verificacin de lmites: Consiste en la verificacin automtica de tablas, cdigos, lmites
mnimos y mximos o bajo determinadas condiciones dadas previamente.
Verificacin de secuencias: En ciertos procesos los registros deben observar cierta
secuencia numrica o alfabtica, ascendente o descendente, esta verificacin debe hacerse
mediante rutinas independientes del programa en si.
Dgito auto verificador: Consiste en incluir un dgito adicional a una codificacin, el mismo
que es resultado de la aplicacin de un algoritmo o formula, conocido como MODULOS, que
detecta la correccin o no del cdigo. Tal es el caso por ejemplo del digito verificador del RUT
en la cdula de identidad Chilena.
46
III.4.10
Controles de Preinstalacin
Controles de Organizacin y Planificacin
Controles de Sistemas en Desarrollo y Produccin
Controles de Procesamiento
Controles de Operacin
Controles de uso de Microcomputadores.
III.4.10.1
Controles de Preinstalacin.
Acciones a seguir:
47
III.4.10.2
Disear un sistema
Elaborar los programas
Operar el sistema
Control de calidad
Se debe evitar que una misma persona tenga el control de toda una operacin. Es
importante la utilizacin ptima de recursos mediante la preparacin de planes a ser evaluados
continuamente.
Acciones a seguir:
La unidad informtica debe estar al ms alto nivel de la pirmide administrativa de manera que
cumpla con sus objetivos, cuente con el apoyo necesario y la direccin efectiva.
48
III.4.10.3
Se debe justificar que los sistemas han sido la mejor opcin para la empresa, bajo una
relacin costo-beneficio que proporcionen oportuna y efectiva informacin, que los sistemas se han
desarrollado bajo un proceso planificado y se encuentren debidamente documentados.
Acciones a seguir:
Los usuarios deben participar en el diseo e implantacin de los sistemas pues aportan
conocimiento y experiencia de su rea y esta actividad facilita el proceso de cambio
El personal de auditoria interna/control debe formar parte del grupo de diseo para sugerir y
solicitar la implantacin de rutinas de control.
49
debidamente
documentados
actualizados.
La
Informe de factibilidad
Diagrama de bloque
Diagrama de lgica del programa
Objetivos del programa
Listado original del programa y versiones que incluyan los cambios efectuados con
antecedentes de pedido y aprobacin de modificaciones.
Formatos de salida
Resultados de pruebas realizadas
Implantar procedimientos de solicitud, aprobacin y ejecucin de cambios a programas,
formatos de los sistemas en desarrollo.
El sistema concluido ser entregado al usuario previo entrenamiento y elaboracin de los
manuales de operacin respectivos
III.4.10.4
Controles de Procesamiento.
50
Acciones a seguir:
Validacin de datos de entrada previo procesamiento debe ser realizada en forma automtica:
clave, dgito auto verificador, totales de lotes, etc.
Preparacin de datos de entrada debe ser responsabilidad de usuarios y consecuentemente
su correccin.
Recepcin de datos de entrada y distribucin de informacin de salida debe obedecer a un
horario elaborado en coordinacin con el usuario, realizando un debido control de calidad.
Adoptar acciones necesarias para correcciones de errores.
Analizar conveniencia costo-beneficio de estandarizacin de formularios, fuente para agilitar la
captura de datos y minimizar errores.
Los procesos interactivos deben garantizar una adecuada interrelacin entre usuario y
sistema.
Planificar el mantenimiento del hardware y software, tomando todas las seguridades para
garantizar la integridad de la informacin y el buen servicio a usuarios.
III.4.10.5
Controles de Operacin.
51
Las instalaciones deben contar con sistema de alarma por presencia de fuego, humo, as
como extintores de incendio, conexiones elctricas seguras, entre otras.
Instalar equipos que protejan la informacin y los dispositivos en caso de variacin de voltaje
como: reguladores de voltaje, supresores pico, UPS, generadores de energa.
52
Contratar plizas de seguros para proteger la informacin, equipos, personal y todo riesgo que
se produzca por casos fortuitos o mala operacin.
III.4.10.6
III.4.11
III.4.11.1
Planificacin de la Auditoria.
53
III.4.11.2
54
55
III.4.11.4
56
III.4.11.5
57
III.4.12
Procesos de Auditora.
58
59
Puede que no haya procedimientos documentados disponibles para algunos de los procesos
horizontales.
Por lo tanto, el auditor tendr que concentrarse en aspectos como:
III.4.12.1
Entradas
Salidas
Controles
Mecanismos
Resultados
Situar la escena:
Introduccin y explicaciones informales para:
Relajar al auditado.
Informar al auditado del proceso de auditora.
2.
3.
Para determinar.
Estructura de organizacin.
Asignacin de responsabilidades.
Estado del sistema documentado.
Competencia y formacin de personal.
Establecer el proceso:
60
Volver a comprobarlo:
6.
Cierre.
Agradezca la cooperacin.
Resuma las conclusiones hasta el momento.
Informe al auditado de lo que va a ocurrir a continuacin.
Es normal que los auditores dividan el proceso en pequeas partes para facilitar el
trabajo. Esto significa que las etapas 3,4 y 5 pueden repetirse varias veces en un mismo proceso, ej.
En lugar de examinar todo un proceso de inspeccin final dentro de una empresa. Se puede dividir
en:
Ensayo del producto final
Salida del producto de reas de despacho
Producto en rea de envo
Este ciclo tambin se puede repetir a un pequeo nivel en cada paso del proceso. Este
sistema puede resultar especialmente til para las situaciones siguientes:
El auditor posee un conocimiento limitado del proceso que se va a auditar.
No existe un procedimiento documentado del proceso que se va a auditar.
Finalmente, las listas de comprobacin estructuradas y recopiladas de manera
apropiada, aseguran que la auditora est estructurada de manera que evita la evaluacin limitada y
superficial de un proceso.
61
III.4.13
Evaluacin de la Seguridad.
En primer lugar se repasan los principales estndares (ISO 27001) y las legislaciones,
que nos ayudarn a tener una visin global de los elementos que intervienen en la infraestructura de
seguridad y los controles que pueden establecerse.
A continuacin se repasan los principios bsicos y los requisitos que se han de cumplir
respecto a la seguridad.
III.4.13.1
Imagnese que, por una u otra razn, la base de datos de un banco sea destruido o
usados inapropiadamente, cunto tiempo pasara para que esta organizacin estuviese nuevamente
en operacin? La informacin de una empresa puede ser el activo ms valioso y al mismo tiempo el
ms vulnerable.
En la situacin actual de criminologa, los delitos de "cuello blanco" han incluido la
modalidad de los delitos hechos mediante la computadora o los sistemas de informacin de los
cuales el 95% de los detectados han sido descubiertos por accidentes y la gran mayora no han sido
divulgados para evitar dar ideas a personas mal intencionadas. Es as como la computadora ha
modificado las circunstancias tradicionales del crimen; muestra de ello son los fraudes, falsificaciones
y venta de informacin hechos a las computadoras o por medio de computadoras.
Durante mucho tiempo se consider que los procedimientos de auditora y seguridad
eran responsabilidad de la persona que elabora los sistemas sin considerar que son responsabilidad
del usuario y del departamento de auditora interna.
Entre los crmenes ms conocidos (muchos de ellos no son identificados o divulgados
para evitar repercusiones) estn el del Banco Wells Fargo Co. ($21.3 millones de dlares), en el cual
se evidenci que la proteccin de los archivos es todava inadecuada, y la publicada el 17 de
septiembre de 1987 en la que dos alemanes entraron a los archivos confidenciales de la NASA. Otro
de los delitos que se han cometido en los bancos estn en insertar mensajes fraudulentos o bien
transferir dinero de una cuenta, otra, con la consecuente ganancia de los intereses.
Existe tambin el caso de un muchacho de 15 aos que entr a la computadora de la
Universidad de Berkeley en California y destruy los archivos, y el estudiante de la escuela Dalton en
Manhattan que entr a la red canadiense, identificndose como un usuario de alta prioridad y tom el
control de los sistemas de una embotelladora de Canad. Ejemplos como stos existen muchos y la
mayora de ellos no se dan a conocer para no dar ideas a personas que puedan cometer delitos o
bien para evitar problemas de publicidad negativa.
62
En chile tenemos un caso reciente en donde una joven de 19 aos fue condenada por
sabotaje informtico ya que fue investigada por la Fiscala de Chilln debido a que, tras acceder a la
plataforma digital del DEMRE, cancel la solicitud de postulacin universitaria de una estudiante.
La indagatoria dirigida por la fiscal Paulina Valdebenito, quien permiti determinar que
la imputada cancel desde su computador la postulacin universitaria de la estudiante perjudicada,
quien egres de un colegio de la capital de uble, y que aspiraba a ingresar a estudiar a una
universidad de Santiago.
Segn se inform, la vctima, tras recibir los resultados de la PSU, postul a la carrera
de Derecho de la Pontificia Universidad Catlica. Su puntaje le alcanzaba para ingresar a la carrera,
sin embargo, cuando se publicaron las listas de seleccionados ella no apareca. En la universidad le
expusieron que nunca se haba hecho la postulacin, a lo que replic exhibiendo el comprobante que
otorga la plataforma digital en la que se realiza el trmite.
Revisando el sistema, le indicaron que si bien su postulacin ingres, ms tarde fue
cancelada. Se hizo la denuncia a la Brigada del Cibercrimen de la PDI, quienes despus de una
investigacin obtuvieron la direccin IP desde donde se efecto la cancelacin.
Finalmente se logr dar con la joven responsable, instancia en la que revel que
obtuvo los datos personales de la vctima a travs de una fotografa que esta public en Instagram,
en la que se exhiba la cartola de postulacin.
63
64
Se considera que hay en cuatro factores que han permitido el incremento en los delitos
cibernticos. Estos factores son:
1. El aumento de personas que se encuentran estudiando Computacin.
2. El aumento del nmero de empleados que tienen acceso a los equipos.
3. La facilidad en el uso de los equipos de computacin.
4. El incremento en la concentracin del nmero de las aplicaciones y consecuentemente, de la
informacin.
.
En la actualidad las compaas cuentan con grandes dispositivos para seguridad fsica
de las computadoras y se tiene la idea que los sistemas no pueden ser violados si no se entra al
65
66
Se debe evaluar el nivel de riesgo que puede tener la informacin para poder hacer un
adecuado estudio costo/beneficio entre el costo por prdida de informacin y el costo de un sistema
de seguridad, para lo cual se debe considerar lo siguiente:
Clasificar la instalacin en trminos de riesgo (alto, mediano, pequeo) identificar aquellas
aplicaciones que tengan un alto riesgo.
Cuantificar el impacto en el caso de suspensin del servicio en aquellas aplicaciones con un
alto riesgo
Formular las medidas de seguridad necesarias dependiendo del nivel de seguridad que se
requiera.
Una vez que hemos definido el grado de riesgo, hay que elaborar una lista de los
sistemas con las medidas preventivas que se deben tomar, as como las correctivas en caso de
desastre sealndole a cada uno su prioridad.
67
Un ejemplo de alto riesgo puede ser la informacin confidencial de tipo nacional o bien
la informacin sobre el mercado y la publicidad de una compaa.
Un ejemplo de riesgo medio es la nmina, la cual puede ser hecha a mano, utilizar
procedimientos alternos o bien un adecuado sistema de respaldos.
Un ejemplo de bajo riesgo pueden ser los balances, los cuales pueden ser
reestructurados con cierta facilidad, salvo el caso de los das de presentacin con fines fiscales.
68
Para cuantificar el riesgo es necesario que se efecten entrevistas con los altos niveles
administrativos que sean directamente afectados por la suspensin en el procesamiento y que
cuantifiquen el impacto que les puede causar este tipo de situaciones.
III.4.13.2
Seguridad en el Personal.
Seguridad Fsica.
69
interrumpible, tanto
En cuanto a los extintores, se debe revisar en nmero de stos, su capacidad, fcil acceso,
peso y tipo de producto que utilizan. Es muy frecuente que se tengan los extintores, pero
puede suceder que no se
encuentren recargados o bien que sean de difcil acceso de un
peso tal que sea difcil el utilizarlos.
Estos es comn en lugares en donde se encuentran trabajando hombre y mujeres y los
extintores estn a tal altura o con un peso tan grande que una mujer no pueda utilizarlo.
Otro de los problemas es la utilizacin de extintores inadecuados que pueden provocar mayor
perjuicio a las mquinas (extintores lquidos) o que producen gases txicos.
Tambin debe ver si el personal sabe usar los equipos contra incendio y si ha habido prcticas
en cuanto a su uso.
70
Se debe verificar que existan suficientes salidas de emergencia y que estn debidamente
controladas Para evitar robos por medio de estas salidas.
Los materiales ms peligro son las cintas magnticas que, al quemarse producen gases
txicos y el papel carbn es altamente inflamable.
III.4.13.4
Seguros.
Los seguros de los equipo en algunas ocasiones se dejan en segundo trmino, aunque
son de gran importancia. Existe un gran problema en la obtencin de seguros ya que a veces el
agente de seguros es una persona que conoce mucho de seguros, riesgos comerciales, riesgos de
vida, etc. Pero muy poco sobre computadoras, y el personal de informtica conoce mucho sobre
computacin y muy poco sobre seguros.
Se tiene poco conocimiento de los riesgos que entraa la computacin, ya que muchas
veces el riesgo no es claro para los vendedores de seguros, debido a lo nuevo de la herramienta y la
poca experiencia existe sobre desastres.
Como ejemplo de lo anterior tenemos las plizas de seguro contra desastres, ya que
algunos conceptos son cubiertos por el proveedor del servicio de mantenimiento, lo cual hace, que se
duplique el seguro o bien sobrevienen desastres que no son normales en cualquier otro tipo de
ambiente.
Se debe verificar las fechas de vencimiento de las plizas, puede suceder que se tenga
la pliza adecuada pero vencida, y que se encuentre actualizada con los nuevos equipos.
El seguro debe cubrir todo el equipo y su instalacin, por lo que es probable que una
sola pliza no pueda cubrir todo el equipo con las diferentes caractersticas (existe equipo que pueda
ser unidades de disco duro) por lo que tal vez convenga tener dos o ms plizas por separado, cada
una con las especificaciones necesarias.
Debemos tomar en cuenta que existen riesgos que son difciles de evaluar y de
asegurar como el caso de negligencia.
El costo de los equipos puede variar, principalmente en aquellos pases que tienen
grandes tasas de inflacin o de devaluacin, por lo que los seguros deben estar a precio de compra
(valor de adquisicin de nuevo equipo con iguales caractersticas) y no a precio al momento de
contratacin del seguro.
El seguro debe cubrir tanto daos causados por factores externos (terremoto,
inundacin, etc.) como por factores internos (daos ocasionados por negligencia de los operadores,
daos debidos al aire acondicionado, etc.). Tambin se debe asegurar la prdida de los programas
(software), de la informacin, de los equipos y el costo de recuperacin de lo anterior.
71
En la actualidad los programas y los equipos son altamente sofisticados y slo algunas
personas dentro del centro de cmputo conocen al detalle el diseo, lo que puede provocar que
puedan producir algn deterioro a los sistemas si no se toman las siguientes medidas:
1. Se debe restringir el acceso a los programas y a los archivos.
2. Los operadores deben trabajar con poca supervisin y sin la participacin de los
programadores, y no deben modificar los programas ni los archivos.
3. Se debe asegurar en todo momento que los datos y archivos usados sean los adecuados,
procurando no usar respaldos inadecuados.
4. No debe permitirse la entrada a la red a personas no autorizadas, ni a usar las terminales.
5. En los casos de informacin confidencial debe usarse, de ser posible, en forma codificada o
criptografiada.
6. Se debe realizar peridicamente una verificacin fsica del uso de terminales y de los reportes
obtenidos.
7. Se debe monitorear peridicamente el uso que se les est dando a las terminales.
8. Se deben hacer auditoras peridicas sobre el rea de operacin y la utilizacin de las
terminales.
9. El usuario debe ser responsable de los datos, por lo que debe asegurarse que los datos
recolectados sean procesados completamente. Esto slo se lograr por medio de los
controles adecuados, los cuales deben ser definidos desde el momento del diseo general
del sistema.
10. Debe existir una perfecta divisin de responsabilidades entre los capturistas de datos y los
operadores de computadora, y entre los operadores y las personas responsables de las
libreras.
72
11. Deben existir registros que reflejen la transferencia de informacin entre las diferentes
funciones de un sistema.
12. Debe controlarse la distribucin de las salidas (reportes, cintas, etc.).
13. Se deben guardar copias de los archivos y programas en lugares ajenos al centro de cmputo
y en las instalaciones de alta seguridad; por ejemplo: los bancos.
14. Se debe tener un estricto control sobre el transporte de discos y cintas de la sala de cmputo
al local de almacenaje distante.
15. Se deben identificar y controlar perfectamente los archivos.
16. Se debe tener estricto control sobre el acceso fsico a los archivos.
17. En el caso de programas, se debe asignar a cada uno de ellos, una clave que identifique el
sistema, subsistema, programa y versin. Esto nos servir para identificar el nmero de veces
que se ha compilado o corrido un programa, y nos permitir costear en el momento que se
encuentre un sistema en produccin.
Tambin evitar que el programador ponga nombres que no signifiquen nada y que
sean difciles de identificar, lo que evitar que el programador utilice la computadora para trabajos
personales.
Otro de los puntos en los que hay que tener seguridad es en el manejo de informacin;
por ejemplo, existe un gran robo de informacin confidencial por medio de fotocopiado, se da el caso
de compaas en que sus competidores han conocido los planes confidenciales por medio del
desperdicio de papel o bien el caso de una compaa que elabor una serie de polticas de personal
sumamente confidenciales y en que los operadores y, consecuentemente, toda la compaa conoci
la informacin al momento de obtener los listados por medio de la computadora. Lo ms drstico en
este caso es que los listados que se obtuvieron eran planes, que servirn como alternativas de
solucin, pero que no haban sido autorizados.
confidencial.
procesos con
73
III.4.13.6
74
procedimientos que permitan eliminarlos al mximo y, en caso que ocurran, poder reparar el dao y
reanudar la operacin lo ms rpidamente posible.
En una situacin ideal, se deberan elaborar planes para manejar cualquier
contingencia que se presente.
Analizando cada aplicacin se deben definir planes de recuperacin y reanudacin,
para asegurarse que los usuarios se vean afectados lo menos posible en caso de falla o siniestro.
Las acciones de recuperacin disponibles a nivel operativo pueden ser algunas
de las siguientes:
En algunos casos es conveniente no realizar ninguna accin y reanudar el proceso.
Mediante copias peridicas de los archivos se puede reanudar un proceso a partir de una
fecha determinada.
El procesamiento anterior complementado con un registro de las transacciones que afectaron
los archivos permitir retroceder en los movimientos realizados a un archivo al punto de tener
la seguridad del contenido del mismo y a partir de l reanudar el proceso.
Analizar el flujo de datos y procedimientos y cambiar el proceso normal por un proceso
alterno de emergencia.
Reconfigurar los recursos disponibles, tanto de equipo y sistemas como de comunicaciones.
75
1. Las correcciones de programas deben ser debidamente autorizadas y probadas. Con esto se
busca evitar que se cambien por nueva versin que antes no ha sido perfectamente probada y
actualizada.
2. Los nuevos sistemas deben estar adecuadamente documentados y probados.
3. Los errores corregidos deben estar adecuadamente documentados y las correcciones
autorizadas y verificadas.
III.4.13.7
76
Las revisiones al plan se deben realizar cuando se haya efectuado algn cambio en la
configuracin del equipo o bien en periodos semestrales. Una de las principales objeciones al plan de
emergencia es su costo; pero como en el caso de
un seguro contra incendio, slo podemos evaluar sus ventajas si desafortunadamente el desastre
ocurre.
El plan de emergencia, una vez aprobado, se distribuye entre personal responsable de
su operacin, por precaucin es conveniente tener una copia fuera de la direccin de informtica. En
virtud de la informacin que contiene el plan de emergencia, se considerar como confidencial o de
acceso restringido.
Para la preparacin del plan se seleccionar el personal que realice las actividades
claves del plan. El grupo de recuperacin en caso de emergencia debe estar integrado por personal
de administracin de la direccin de informtica (por ejemplo, el jefe de operacin, el jefe de anlisis y
programacin y de auditora interna). Cada uno de ellos debe tener tareas especficas como la
operacin del equipo de respaldo, la interfaz administrativa, de logstica; por ejemplo, el proporcionar
los archivos necesarios para el funcionamiento adecuado. Cada miembro del grupo debe tener
asignada su tarea con una persona de respaldo para cada uno de ellos. Se deber elaborar un
directorio que contenga los nombres, direcciones y nmeros telefnicos.
Los desastres que pueden suceder podemos clasificarlos as:
a) Completa destruccin del centro de informtica.
b) Destruccin parcial del centro de informtica.
c) Destruccin o mal funcionamiento de los equipos auxiliares del centro de cmputo
(electricidad, aire acondicionado, etc.).
d)
e)
f)
g)
El plan en caso de desastre debe considerar todos los puntos por separado y en forma
integral como sistema. La documentacin estar en todo momento tan actualizada como sea posible,
77
ya que en muchas ocasiones no se tienen actualizadas las ltimas modificaciones y eso provoca que
el plan de emergencia no pueda ser utilizado.
Cuando el plan sea requerido debido a una emergencia, el grupo deber:
Asegurar que todos los miembros sean notificados.
Informar al director de informtica.
Cuantificar el dao o prdida del equipo, archivos y documentos para definir qu parte del
plan debe ser activada.
Determinar el estado de todos los sistemas en proceso.
Notificar a los proveedores del equipo cul fue el dao.
Por otro lado, se debe establecer una coordinacin estrecha con el personal de
seguridad a fin de proteger la informacin.
III.5.
INFORME FINAL.
78
III.5.1
III.5.1.1
79
El informe debe incluir solamente hechos importantes. La inclusin de hechos poco relevantes
o accesorios desva la atencin del lector.
El Informe debe consolidar los hechos que se describen en el mismo. El trmino de "hechos
consolidados" adquiere un especial significado de verificacin objetiva y de estar
documentalmente probados y soportados.
La consolidacin de los hechos debe satisfacer, al menos los siguientes criterios:
1.
2.
3.
4.
80
III.5.1.3
1. Hecho encontrado.
Ha de ser relevante para el auditor y para el cliente.
Ha de ser exacto, y adems convincente.
No deben existir hechos repetidos.
2. Consecuencias del hecho.
Las consecuencias deben redactarse de modo que sean directamente deducibles del
hecho.
3. Repercusin del hecho.
Se redactar las influencias directas que el hecho pueda tener sobre otros aspectos
informticos u otros mbitos de la empresa.
4. Conclusin del hecho.
No deben redactarse conclusiones ms que en los casos en que la exposicin haya sido
muy extensa o compleja.
5. Recomendacin del auditor informtico.
Deber entenderse por s sola, por simple lectura.
Deber estar suficientemente soportada en el propio texto.
Deber ser concreta y exacta en el tiempo, para que pueda ser verificada su
implementacin.
La recomendacin se redactar de forma que vaya dirigida expresamente a la persona o
personas que puedan implementarla.
Carta de introduccin o presentacin del informe final:
La carta de introduccin tiene especial importancia porque en ella ha de resumirse la
auditora realizada. Se destina exclusivamente al responsable mximo de la empresa, o a la persona
concreta que encargo o contrato la auditora.
81
As como pueden existir tantas copias del informe final como solicite el cliente, la
auditora no har copias de la citada carta de introduccin.
IV.
PRODUCTO FINAL
INSTITUTO PROFESIONAL
SANTO TOMS
ARICA
82
INFORME
FINAL
AUDITORA DE SEGURIDAD INFORMATICA
REALIZADA A LA SECCIN O.S.7 ARICA
AL SEOR
JEFE DE LA SECCIN O.S.7 ARICA
TTE. CORONEL ESTEBAN F. DAZ URBINA
84
1.- ORGANIZACIN.
1.1.-
85
1.2.-
1.3.-
Aplicaciones.
86
87
88
89
90
91
CONCLUSIONES:
1.- En mrito de lo expuesto, la autoridad deber dar efectivo
cumplimiento a las medidas enunciadas en los numerales 1.2; 1.3 y; 5 del presente informe,
tendientes a solucionar las observaciones planteadas, cuya efectividad ser comprobada en una
futura visita que se realice a esa unidad de Carabineros de Chile.
2.- Respecto de lo sealado en los puntos 3 y 4, cabe sealar
que, considerando que en su oportunidad se dispuso de informacin que se encontraba en proceso
de cambio, segn se advierte de la respuesta al Preinforme respectivo, las observaciones
inicialmente planteadas sern evaluadas en una prxima auditora.
92
V.
V.1
ASPECTOS COMPLEMENTARIOS
CONCLUSIN.
93
V.2
BIBLIOGRAFA.
[1].
[2].
[3].
[4].
[5].
94
[6].
RADIO BIOBIO, Condena por Saboteo Informtico Noticia Publicada por Gerson Guzmn,
01 de Marzo de 2014.
Link: http://www.biobiochile.cl/2014/03/01/condenan-a-joven-que-saboteo-la-postulacion-a-launiversidad-de-una-estudiante-en-chillan.shtml
V.3
ANEXOS.
ANEXO 1.
95
96
ANEXO 2.
97
ANEXO 3.
98
99