1. Estimados Alumnos, el presente material fue
elaborado por alumnos del semestre II/2010.
Espero les sirva !!!
2. Auditoria de sistemas.- Es el conjunto de técnicas,
actividades y procedimiento, destinadas a analizar,
para recomendar en asuntos relativos a la
planificación, control eficacia, seguridad y
adecuación del servicio informático en la empresa.
Auditor de Sistemas.- además de tener
conocimientos informáticos debería conocer
aspectos relacionados a:
Contabilidad
Procesos significativos del negocio
Aspectos administrativos financieros
3. El Auditor de Sistemas debería poseer
competencias profesionales, es decir además
conocimientos mencionados anteriormente. Debe
tener la habilidad de manejar recursos varios, para
apoyar a su revisión
Herramientas informáticos
Planillas de trabajo
Planes de trabajo.
El Auditor de Sistemas también debe conocer estándares a
disposion tales como :
COBIT
ISO
ITIL
OTROS.
4.
5. Tipos de Auditoria.- son:
Auditoria Externa e Interna
En la Auditoria Interna existe un vínculo laboral
entre el auditor y la empresa, mientras que en
la Auditoria Externa la relación es de tipo civil.
En la Auditoria Interna el diagnóstico del auditor, está
destinado para la empresa; en el caso de la Auditoria
Externa este dictamen se destina generalmente para
terceras personas, es decir, ajena a la empresa.
6. Riesgo/Control
RIESGO
“La incertidumbre que ocurra un evento que
podría tener un impacto en el logro de los
objetivos”. se denomina errores, irregularidades
u omisiones, los cuales pueden generar una
pérdida monetaria o información, de la empresa
o incumplimiento de normativa externa.
CONTROL
Son medidas, normas y procedimientos que se
disponen para proteger los recursos contra las
amenazas a que están expuestos y contra los
riesgos que éstas podrían generar.
7. Muestreo .- es analizar a una parte del universo. significa las
partidas individuales que constituyen un universo. Por ejemplo,
listado de altas o bajas de Usuarios,etc.
Muestreo tiene las siguientes características:
a) selección al azar de una muestra; y
b) uso de teoría de la probabilidad para evaluar los resultados de
la muestra, incluyendo medición de riesgos de muestreo.
c) Un enfoque de muestreo que no tenga las características (a) y
(b) se considera un muestreo.
Evidencia.- es un respaldo para demostrar de que una auditoria
sea efectiva en análisis de datos de información. Las evidencias
pueden ser: físicas(papel), pantallas(point), Archivos(txt, doc, xls
y otros), Emails.
Fraude.- es un engaño hacia un tercero, abuso de confianza,
simulación, etc. El término "fraude" se refiere al acto intencional
de la Administración, personal o terceros, que da como resultado
una representación equivocada de los estados financieros,
pudiendo implicar:
8. Política.-Las políticas de una compañía por objeto orientar
la acción, por la cual sirven para formular, interpretar y
suplir las normas concretas
Norma.- Regla que se debe seguir o a que se deben
ajustar las conductas, tareas, actividades
Tecnicas.- Son los métodos prácticos de investigación y
prueba que utiliza el auditor para obtener la evidencia
necesaria que fundamente sus opiniones y conclusiones,
su empleo se basa en su criterio o juicio, según las
circunstancias.
Procedimiento.- Explicar clara y detalladamente cuáles son
los pasos a seguir para llevar a cabo la aplicación correcta
de la política en cuestión para lo cual es necesario seguir
una secuencia cronológica de todos los hechos que
forman el proceso.
9. Auditoría Forense
“Es una auditoría especializada en descubrir,
divulgar y atestar sobre fraudes y delitos en el
desarrollo de las funciones públicas y privadas”.
“La auditoría forense es aquella labor de auditoría
que se enfoca en la prevención y detección del
fraude financiero; por ello, generalmente los
resultados del trabajo del auditor forense son
puestos a consideración de la justicia, que se
encargará de analizar, juzgar y sentenciar los
delitos cometidos (corrupción financiera, pública o
privada).”
10. Ethical Hacking o Hacking Ético. Una disciplina de la
seguridad de redes que se sustenta en el hecho de
que para estar protegido se debe conocer cómo
operan y qué herramientas y técnicas usan los
hackers.
Entonces se explotan las vulnerabilidades que existan
en el sistema “objetivo” para ganar acceso y
“demostrar” que un sistema es violable.
El hacker ético intentará penetrar desde fuera de la
red de la compañía, o sea desde internet. O podría
realizar la prueba simulando ser un hacker interno
desde dentro.
.
11. SQL Injection.- es una vulnerabilidad
informática en el nivel de la validación de las
entradas a la base de datosde una aplicación.
El origen es el filtrado incorrecto de las
variables utilizadas en las partes del
programa con código SQL. Es, de hecho, un
error de una clase más general de
vulnerabilidades que puede ocurrir en
cualquier lenguaje de programación o de
script que esté incrustado dentro de otro.
12.
13. Las solicitudes de cambio pueden provenir de
cualquier usuario o interesado, en cualquier
punto del ciclo del software, e incluir una
solución propuesta, prioridad e impacto, el
cual debe ser analizado, aprobado y
rastreado formalmente a través de Email,
formularios físicos o WorkFlow
Las solicitudes deben ser realizadas por alguien con
grado jerárquico en la Empresa y las autorizaciones
por TI
14. El objetivo de este control es verificar que los
usuarios finales realizaron pruebas al
aplicativo, revisando evidencias formales
como ser: la conformidad, rechazo u
observaciones enviadas ya sea por Email,
Formularios físicos o Workflow.
Este aspecto puede presentar 2 escenarios
distintos
15. Ambiente de Ambiente de
Desarrollo y Producción
Pruebas
Ambiente de Ambiente de Ambiente de
Desarrollo Pruebas Producción
16. Se verifica si hubo una autorización para que
se realiza el pase a producción y se chequea
las personas involucradas en esta tarea, las
cuales podrían ser:
Encargado de Infraestructura de red +
Auditor de Sistemas u otra persona externas
al área de Sistemas, que tengan acceso al
ambiente de producción con un usuario
privilegiado con contraseña Dual.
17. El monitoreo de cambios a programas se
realiza para garantizar que todos los
procedimientos a cambios de a programas se
realizo correctamente en un periodo de
tiempo.
Para ello se solicita a la empresa que nos
proporcionen ya sea (Documentación ,emails
o workflows) del periodo de tiempo a
analizar.
18. Luego se toma una muestra de muestra
universo de casos a analizar, ayudándonos de
algún tipo de software para ello (IDEA, ACL) y
se comienza a verificar si se cumplió
realmente los procedimientos de cambios a
programas en ese periodo de tiempo.
19. Cada empleado de la empresa debiera
realizar actividades que les corresponde
según su cargo; y no otra actividad!!!
Un contador no puede realizar actividades de
ventas por ejemplo.
Un desarrollador de software no debiera
realizar operaciones contables.
Un desarrollador de software no debieran
trasladar los objetos de desarrollo de
software a un ambiente de producción, etc.
20. TAREAS CARGOS
SOLICITUD Jefe/Gerente de área
DESARROLLO Personal de Desarrollo
PRUEBAS Usuarios Finales
AUTORIZACION PASE A Usuarios, jefe/gerente
PROD.
PASE A PRODUCCION Encargado de redes +
Auditor de Sistemas
MONITOREO Auditor de Sistemas
CIRUJIA DE DATOS DBA / OSI/ ASI
21. Se refiere a cambios hechos directamente a
una tabla de la BD, se lo realiza cuando un
usuario del aplicativo comete un error al
registrar los datos y el aplicativo no permita
su modificación, se procede a hacer el
cambio en un nivel mas bajo directamente en
la BD.
Este procedimiento se tiene que llevar a cabo
previa solicitud y autorización explicando el
motivo de la modificación, a que tabla y que
campo se modificara.
22. La cirugía de datos la puede realizar
Un DBA
Un DBA + personal externo al área de
sistemas
Para garantizar que no se comentan cambios
indebidos en la BD y evitar cualquier
conducta maliciosa.
23. Cambiar los puestos de todos los
vendedores (SALESMAN) por „MARKET
REP‟
SQL> UPDATE EMP
SET JOB=‟MARKET REP‟
WHERE JOB=‟SALESMAN‟;
24. Tipos de Parche
◦ Críticos: Probar las Actualizaciones en un
ambiente de prueba
◦ No Críticos: No son necesarios las pruebas en
ambientes de prueba
25.
26. DumpSec SomarSoft es un programa de
auditoría de seguridad para Microsoft
Windows ® NT/XP/200x. Vuelca los permisos
(DACL) y la configuración de auditoría (SACL)
para el sistema de archivo, registro,
impresoras y recursos compartidos en un
formato conciso, legible, de modo que los
agujeros en la seguridad del sistema son
evidentes. DumpSec también vertederos de
usuario, grupo e información de replicación.
27. DumpReg SomarSoft es un programa para
Windows que descarga el registro, lo que
hace que sea fácil encontrar las claves y
valores que contiene una cadena. Las
entradas del Registro se pueden ordenar por
orden inverso al de la última vez modificada,
por lo que es fácil ver los cambios realizados
por el software instalado recientemente, por
ejemplo.
28. Se Verifica como esta configurada la
plataforma tanto (Sistema operativo,
Aplicativo y Base de Datos). En este control se
contempla los planes de trabajo en 2 niveles :
Sistema Operativo
Plan de trabajo SO Windows controlador de Dominio
Plan de trabajo SO Windows aplicativo
Plan de trabajo SO Windows Base de Datos
Base de Datos
Plan de trabajo BD (Oracle, Sql server, Mysql)
29. Se chequea como es la configuración de
accesos de los usuarios. Se verifica que
personal de la empresa tiene cuentas
privilegiadas y se verifica que esa cuenta
corresponda en función al cargo de la
persona.
Se verifica las cuentas privilegias en los 3
niveles (SO, Aplicativo y BD)
Para ello nos podemos ayudar de la
Herramienta DumpSec para verificar las
cuentas a nivel SO.
30.
31.
32. Se cheque la configuración de las contraseñas
a nivel SO y Aplicativo revisando la longitud
de la contraseña, que la contraseña expire en
el tiempo y que se pida cambio de contraseña
en el primer logueo.
Adicionalmente se tienen que realizar algunas
pruebas.
33. Prueba 1: Solicitar la creación de un usuario a
la empresa, loguearse con ese usuario y
verificar si el aplicativo o SO, nos pide
cambio de contraseña al primer logueo.
34. Prueba 2: comprobar la longitud de las
contraseña, lo recomendable es que la
longitud sea >= 8, verificando que el
aplicativo no acepte una contraseña menor al
tamaño recomendado.
XXXXXXXX XXX
Longitud = 8 Longitud = 3
35. Prueba 3: comprobar la complejidad de las
contraseñas.
abc1235x 12345678
Ar12-34XaB abcdefg
36. Prueba 4: comprobar la frecuencia de
intentos fallidos al aplicativo y verificar que
este no solo se cierre al los 3 intentos fallidos
si no verificar que se bloque el acceso por un
tiempo limitado
38. Se comprueba que los gerentes de área hagan
una validación periódica de los perfiles de
acceso de los usuarios, con el hecho de
verificar que usuarios no calificados tengan
acceso a lugares que no les corresponde.
Si no se hace esta validación periódica se se
solicita un listado de los usuarios y sus
perfiles y se procede a la validación de estos
según el cargo q tengan asignado en la
empresa.
39. El objetivo de este control es verificar que
solamente personal autorizado tenga acceso
al CPD y verificar los procedimientos de
seguridad que tiene el CDP.
40. Los controles de acceso físico se diseñan para
proteger contra la entrada o acceso no
autorizado. Accediendo a un CPD se podría tener
acceso no autorizado al sistema, a los recursos
de información, sin conseguir una adecuada
seguridad de los datos de nuestra organización,
que debe ser uno de los objetivos básicos de la
misma. Los controles de acceso físico al CPD
restringen la entrada y salida del personal, y a
menudo, los equipos y los medios respecto del
mismo. Hay muchos tipos de controles de acceso
físico, que incluyen tarjetas de identificación,
tarjetas inteligentes, llaves etc.
41. Los principales aspectos que se deben tener en cuenta en relación con la
seguridad física de un CPD son los siguientes:
• Ubicación del CPD: se recomienda que esté ubicado entre la primera o
segunda planta del edificio, para evitar los riesgos de las plantas altas y
bajas (inundaciones, goteras etc.), que su ubicación no esté señalizada,
que no tenga ventanas etc.
• Falso suelo: se recomienda que exista un falso suelo o suelo técnico
por donde suele discurrir el cableado, suelo que debe ser de material
ignífugo o difícilmente inflamable y guardar cierta distancia respecto del
suelo real. Asimismo se recomienda limpiar debajo del mismo, que
tenga detectores de humedad, un sistema de detección de incendios
etc.
• Falso techo: se recomienda que sea de material ignífugo o difícilmente
inflamable, que tenga instalado un sistema de detección de incendios
etc.
42. • Configuración interior: se recomienda que el aislamiento
interior sea ignífugo, que la puerta de acceso sea
resistente al fuego etc.
• Sistema de cableado de voz y datos: se recomienda que
la electrónica de red y los sistemas de cableado dispongan
de las mismas medidas de protección que el CPD o que se
sitúen en la misma sala o en una sala anexa de similares
características. Asimismo, que el cableado de datos tenga
cierta categoría, que los armarios de cableado y
electrónica estén en un centro único etc.
• Instalación eléctrica: se recomienda la instalación de un
SAI (sistema de alimentación ininterrumpida), generadores
de electricidad alternativos (grupo electrógeno), línea
eléctrica exclusiva etc.
43. • Climatización: se recomienda controlar la temperatura y la
humedad y realizar el mantenimiento adecuada de los equipos
de climatización.
• Sistemas contra incendios: deben existir suficientes extintores
manuales cerca del mismo y una BIE. Asimismo se recomienda
que exista un sistema de extinción automática de incendios,
detectores de humo, alarmas contra incendios etc.
• Control de accesos: debe existir algún sistema de control de
acceso al CPD, por ejemplo, cerraduras etc. En cumplimiento del
artículo 19 del Reglamento de Medidas de Seguridad 994/99,
para ficheros de nivel medio, se debe utilizar un sistema que
garantice el control de acceso físico al CPD.
• Sistema de vigilancia: hay que evaluar la posibilidad de instalar
cámaras de vigilancia, sensores de control de presencia etc.
44. Lo realiza alguien externo al área de
sistemas, el objetivo es garantizar el
cumplimiento de los controles de acceso
lógico y físico, el cual tendría que ser
realizado por un auditor de Sistemas.
45. Cada empleado de la empresa debiera
realizar actividades que les corresponde
según su cargo; y no otra actividad!!!
Un contador no puede realizar actividades de
ventas por ejemplo.
Un desarrollador de software no debiera
realizar operaciones contables.
Accesos al Sistema de ventas debieran estar
restringidos a un empleado que realiza la
contabilidad, etc.
46. Se requiere determinar que usuarios tienen
accesos a estos utilitarios y verificar la
racionalidad de estos.
Comprobando quienes tienen acceso a
carpetas importantes o a archivos .Bat que se
utilizan para la migración de datos entre
aplicaciones.
47.
48. Es el proceso de revisar el código de una
aplicación para encontrar errores en tiempo de
diseño.
Motivos para auditar el código de una aplicación
◦ La auditoría de código es parte del ciclo de vida en el
desarrollo de Software.
◦ Dejar la revisión de código para el último momento es
mucho más costoso en tiempo y en recursos que
realizarlo como un proceso continuo.
◦ Es una forma sencilla de „educar‟ al equipo de desarrollo
viendo por qué no se deben realizar ciertas
codificaciones.
◦ Fomenta el uso de buenas prácticas.
◦ Mejora la calidad y minimiza el mantenimiento del
código que realizamos.
49. Los entornos integrados comprueban la sintaxis
del código, pero no se ocupan de otros aspectos
como:
El código muerto: Código que no es llamado
desde ningún lugar.
Las convenciones de nombrado de variables:
Forma de escritura tipo Camel Case o la que se
decida.
La visibilidad innecesaria de un atributo o clase.
Código duplicado: Ha de ser evitado, ya que es
fuente de incontables errores.
50. HP Código Asesor (cadvise)
◦ HP Código Advisor es una herramienta de análisis
estático para C y C + +. HP Código Asesor informes
de varios errores de programación en el código
fuente. Esta herramienta permite a los
programadores a identificar los posibles errores de
codificación, las cuestiones de portabilidad y
vulnerabilidades de seguridad. HP Código Asesor
aprovecha las capacidades de análisis avanzado de
HP C y aC + + compiladores disponibles en los
sistemas HP Integrity.
51. Project Analyzer es una base de revisión de
código de Visual y herramienta de control de
calidad. En otras palabras, el análisis de
código estático para VB. Detección de fallas
por la lógica de revisión de código
automático. Realizar análisis de impacto
antes de escribir los cambios. Entender mal
documentado el código heredado. Aplicar
ingeniería inversa a los proyectos existentes
de Visual Basic en diagramas y la
documentación.
52. ReSharper 5
Desarrollo Web : inspecciones de código, completado de
código, navegación, plantillas, y muchas más
características para ASP.NET y ASP.NET MVC.
Análisis de código : Visualización y eliminación de todos
los problemas en la solución de
una ventana única herramienta, el flujo de llamadas de
seguimiento de valor y el método; actualización bucles
para LINQ.
Proyecto de Mantenimiento : nivel refactorizaciones
proyecto, el paquete de localización, búsqueda
estructurales y reemplazar, la navegación a las fuentes de
la biblioteca.
Visual Studio 2010 : ReSharper sim-viene con el nuevo
Visual Studio. En la actualidad trabaja con VS 2005, 2008 y
2010!
53. “Cualquier organización, en algún instante de
tiempo, se deberá enfrentar a una situación
anómala que amenace su actividad”.
Un Plan de Continuidad de Negocio tiene como
objetivo el mantenimiento de estos servicios y
procesos críticos, así como la reducción de
impactos ante imprevistos de indisponibilidad o
desastres para en un plazo razonable y con
un coste acotado.
Este servicio está orientado a la obtención de un
plan global que garantice la cobertura técnica y
organizativa adecuada de las áreas críticas de
negocio.
54. Los objetivos del plan de continuidad de negocio
son:
Salvaguardar los intereses de sus clientes y
socios además del negocio y la imagen de la
organización.
Identificar los puntos débiles en los sistemas de
la organización.
Analizar las comunicaciones e infraestructuras.
Conocer la logística para restablecer los
servicios, independientemente de los sistemas.
Ofrecer alternativas viables a todos los procesos
críticos de negocio.
55. Análisis de Impacto de Negocios y/o Business
Impact Analysis (BIA). BIA se constituye asi en el
pilar sobre el que se va construir el Plan de
Recuperación de Negocios. El BIA será la guía que
determine que necesita ser recuperado y el
tiempo que tarde dicha recuperación, actividades
que en el Plan de Continuidad de Negocios se
convierten quizás en las más difíciles y criticas
por realizar adecuadamente. El apoyo del BIA es
invaluable para identificar que esta en riesgo una
vez se presente un riesgo permitiendo así
justificar los gastos que se requieran en
protección y capacidad de recuperación.
56. Los RTO y RPO, son parámetros específicos que
están íntimamente relacionados con la
Recuperación de Desastres y tienen que ser
tomados en consideración para que un plan de
este tipo pueda ser
implementado. El RTO (Recovery Time Objective)
es el Tiempo objetivo de recuperación, en otras
palabras cuanto puede permanecer la
Organización sin ejecutar una actividad, el uso de
una aplicación (hardware y/o software) o
información relevante. Frecuentemente es
asociado con el tiempo máximo de inactividad. El
RTO se utiliza para decidir cada cuanto se deben
realizar respaldos de información o backups
57. El RPO es ligeramente diferente. Este
parámetro nos dice que cantidad de
información puede la Organización perder. En
otras palabras, si su organización realiza
respaldos nocturnos de información todos los
días a las 7:00 PM y el sistema colapsa al día
siguiente a las 4:00 PM, toda actualización
que se realice desde su último respaldo se
perderá. El RPO para este contexto será el
respaldo de información que haya realizado
en el día anterior.
58. Maximum Tolerable Downtime (MTD) o Maximum
Tolerable Outage (MTO) Tal como suena, es el
tiempo máximo de inactividad que la
organización puede tolerar la ausencia o no
disponibilidad de una función o proceso.
Work Recovery Time (WRT) Tiempo de trabajo en
Recuperación. Este segmento comprende el
máximo tiempo de inactividad posible o MTD. Si
su MTD es de 3 días, probablemente el día 1 sea
el RTO y los dias 2 y 3 pueden ser los WRT. Como
es de esperar, toma tiempo hacer que las
funciones criticas de la Organización estén
nuevamente operando (hardware, software,
configuraciones necesarias, etc)
61. Se toman en cuenta las siguientes
verificaciones
◦ Limite
◦ Rango
◦ Razonabilidad
◦ duplicidad
62. El objetivo es ver si aplicativo valida los datos
que el usuario ingresa para identificar :
Errores de Datos
Datos incompletos
Incongruencias entre ítems que estén
relacionados
63. Las técnicas de auditoría asistidas por
computadora son de suma importancia para el
auditor de TI cuando realiza una auditoría.
CAAT (Computer Audit Assisted Techniques)
incluyen distintos tipos de herramientas y de
técnicas, las que más se utilizan son los
software de auditoría generalizado, software
utilitario, los datos de prueba y sistemas
expertos de auditoría.
66. A través de la herramienta IDEA, se puede
disminuir costos de análisis, realzar la calidad del
trabajo y adquirir nuevos roles. Con esta
herramienta se puede leer, visualizar, analizar
datos; llevar a cabo muestreos y extraer archivos
de datos desde cualquier origen ordenadores
centrales a PC, incluso reportes impresos.
IDEA es reconocido en todo el mundo, como un
estándar en comparaciones con otras
herramientas de análisis de datos, ofreciendo
una combinación única en cuanto a poder de
funcionalidad y facilidad de uso.
67. ACL es una potente herramienta que se utiliza
para analizar procesar y preparar reportes en BD
De todas las herramientas de análisis de datos
que existen, es de las mas fáciles de usar y
entender.
Ayuda a analizar datos en forma rápida, efectiva
y eficiente
ACL permite:
Análisis de datos para un completo
aseguramiento.
Localiza errores y fraudes potenciales.
Identifica errores y los controla.
68. Una descripción del trabajo realizado,
seguimiento y las conclusiones acerca de los
resultados de los CAAT deben estar registrados
en los papeles de trabajo de la auditoría.
Las conclusiones acerca del funcionamiento del
sistema de información y de la confiabilidad de
los datos también deben estar registrados en
los papeles de trabajo de la auditoría.
El proceso paso a paso de los CAAT debe estar
documentado adecuadamente para permitir que
el proceso se mantenga y se repita por otro
auditor de sistemas de información.
69. Específicamente los papeles de trabajo deben contener la
documentación suficiente para describir la aplicación de los
CAAT incluyendo los detalles que se mencionan en los
párrafos siguientes:
Planificación
Los objetivos de los CAAT
Los CAAT a utilizar
Los controles a implementar
La documentación debe incluir:
Los procedimientos de la preparación y la prueba de los
detalles de las pruebas realizadas por los CAAT.
Evidencia de auditoría: (ejemplo: archivos log, reportes).
Conclusiones de la auditoría.
Las recomendaciones de la auditoría.