Metodología de una auditoría de apoyo.

Existen diversas metodologías de auditorías de apoyo y todas dependen de lo que

se pretenda revisar o analizar, pero como estándar analizaremos las cuatro fases
básicas de un proceso de revisión:

 Estudio preliminar:

Incluye definir el grupo de trabajo, el programa de auditoría, efectuar visitas a

la unidad informática para conocer detalles de la misma, elaborar un
cuestionario para la obtención de información para evaluar preliminarmente
el control interno, solicitud de plan de actividades, Manuales de política,
reglamentos, Entrevistas con los principales funcionarios de la Organización y
de la Departamento de Informática.

 Revisión y evaluación de controles y seguridades:

Consiste de la revisión de los diagramas de flujo de procesos, realización de

pruebas de cumplimiento de las seguridades, revisión de aplicaciones de las
áreas críticas, revisión de procesos históricos (backups), revisión de
documentación y archivos, entre otras actividades.

 Examen detallado de áreas críticas:

Con las fases anteriores el auditor descubre las áreas críticas y sobre ellas hace
un estudio y análisis profundo en los que definirá concretamente su grupo de
trabajo y la distribución de carga del mismo, establecerá los motivos,
objetivos, alcance y recursos que usará, definirá la metodología de trabajo, la
 duración de la auditoria, presentará el plan de trabajo y analizará
detalladamente cada problema encontrado con todo lo anteriormente
analizado.

 Comunicación de resultados:

Se elaborará el borrador del informe a ser discutido con los ejecutivos de la

empresa hasta llegar al informe definitivo, el cual se presentará
esquemáticamente en forma de matriz, cuadros o redacción simple y concisa
que destaque los problemas encontrados, los efectos y las recomendaciones
de la Auditoría.

El informe debe contener lo siguiente:

Motivos de la auditoría.

Objetivos.

Alcance.

Estructura Orgánico-Funcional del área Informática.

Configuración del Hardware y Software instalado.

Control Interno.

Resultados de la Auditoría.

Auditoría de aplicaciones.
Las empresas normalmente incluyen en su sitio Web pequeñas aplicaciones
(Applets, CGIs, ActiveX, etc.) que ayudan a gestionar los datos enviados por los
usuarios (datos personales, pedidos, pagos online, control de acceso, etc.). Existen
también otras empresas que utilizan su sitio Web para realizar una gran variedad
de operaciones con sus clientes/proveedores/personal (p.e. portales corporativos,
brokers/banking online, e-commerce, extranets, etc.) y esto implica la utilización de
una compleja aplicación que se ejecuta en el servidor Web o de aplicaciones y que
gestiona todas estas operaciones.

Las actuaciones que se llevan a cabo para realizar la Auditoría de Aplicación,

siguen la filosofía de caja negra, es decir, en ningún momento se audita el código
fuente de la aplicación. El motivo de esta metodología de trabajo es la de simular la
actuación real de un atacante malicioso que, a través de las aplicaciones auditadas
y sin disponer de su código fuente, intente realizar un ataque al sistema, bases de
datos, entre otros.

El proceso de auditar aplicaciones está planificado en las fases que se presentan a

continuación:

 Análisis funcional.

Se realiza un estudio general de la aplicación, adquiriendo una visión global

de las funcionalidades que proporciona con el fin de plantear las actuaciones
y procedimientos óptimos que se llevan a cabo en el Análisis Técnico.

 Análisis Técnico.

Se realiza un análisis de la aplicación de manera que se pueda decidir a qué

tipos de ataques es sensible.
  Diseño de Pruebas.

En esta fase se diseñan las pruebas a realizar para explotar aquellas

deficiencias de seguridad que puedan aparecer en la aplicación auditada.

 Desarrollo de las Pruebas.

Se programarán las pruebas a ejecutar, y se determinará el orden en el que se

llevarán a cabo.

 Realización de las pruebas.

Durante esta fase se llevan a cabo todas las pruebas sobre la aplicación
auditada, se analizan los resultados obtenidos y en el caso de detectar nuevas
vulnerabilidades a explotar se vuelve a la fase de diseño para intentar
explotarlas.

Ámbito de las pruebas.

Nuestra metodología nos permite llevar a cabo una exhaustiva revisión sobre las
aplicaciones auditadas cubriendo los siguientes aspectos de seguridad:

Recopilación de información:

Antes de auditar una aplicación es necesario determinar el ámbito sobre el que se

realizará la revisión de seguridad con ciertos aspectos clave sobre esta y que
consiste, entre otros, en estos:

 Descubrimiento de aplicaciones.
  Identificación de puntos de entrada a la aplicación.
 Análisis de códigos de error.
 Identificación de plataformas.

Ingeniería Inversa de Protocolos:

Los ataques que pueden realizarse a las aplicaciones, se pueden iniciar a través del
análisis de los protocolos implementados por estas. A veces pueden no
implementarse controles de seguridad lo suficientemente robustos, y otras veces,
implementar librerías propietarias de protocolos estándar de forma incorrecta que
implican también vulnerabilidades de seguridad en el sistema.

Análisis de la configuración en la infraestructura:

El análisis de la infraestructura y la topología de la arquitectura pueden revelar

información como por ejemplo el código fuente, métodos HTTP soportados,
funcionalidades de administración, métodos de autenticación o configuraciones de
la infraestructura. En este punto se desarrollan las siguientes pruebas:

 Pruebas sobre SSL/TLS.

 Pruebas sobre la gestión de la configuración en la infraestructura.
 Pruebas sobre la gestión de la configuración en la aplicación.
 Pruebas sobre el manejo de extensiones de archivos.
 Identificación de ficheros antiguos, de backup o no referenciados.
 Acceso a interfaces de administración.
 Pruebas sobre métodos HTTP y XST.
 Análisis del esquema de autenticación
Autenticación: “es el acto de establecimiento o confirmación de algo (o alguien)
como auténtico”. Un ejemplo de este proceso es el proceso de inicio de sesión,
para realizar este análisis se realizan las siguientes pruebas:

 Transmisión de credenciales a través de un canal cifrado.

 Pruebas de enumeración de usuarios.
 Pruebas de identificación de cuentas de usuario previsibles.
 Pruebas de fuerza bruta
 Pruebas para sobrepasar el esquema de autenticación.
 Pruebas de finalización de sesión.
 Pruebas sobre implementaciones de CAPTCHA.
 Pruebas de autenticación basadas en múltiples factores.
 Pruebas de condiciones de carrera.

Análisis de gestión de sesiones:

En el núcleo de cualquier aplicación basada en web se encuentra la forma en que

mantiene el control de estado y, por tanto, la interacción con el usuario. En el
sentido más amplio, la gestión de sesiones abarca todos los controles sobre un
usuario, desde la autenticación hasta la salida de la aplicación.

 Pruebas del esquema de gestión de sesiones.

 Pruebas sobre los atributos de las cookies.
 Pruebas de fijación de sesión.
 Pruebas sobre exposición de variables de sesión.
 Pruebas de CSRF.
Análisis del esquema de autorización:

Autorización: “Es el concepto de permitir el acceso a los recursos únicamente a

aquellos permitidos a utilizarlos”. Lo que se pretende analizando el esquema de
autorización es entender su funcionamiento y con esa información intentar evadir
el mecanismo de autorización. Para ello realizamos las siguientes pruebas:

 Pruebas de acceso a recursos protegidos.

 Pruebas para sobrepasar el esquema de autorización.
 Pruebas de elevación de privilegios.

Análisis de las reglas de negocio:

Las reglas de negocio pueden incluir reglas que expresen políticas de negocio
(como productos, precios o ubicaciones) o workflows basados en tareas ordenadas
de transmisión de datos de un participante (una persona o un componente
software) a otro.

 Pruebas sobre las reglas de negocio.

 Pruebas de abuso de funcionalidad.

Análisis del mecanismo de validación de datos:

El principal problema que nos encontramos en las aplicaciones, es que no se

realizan adecuadamente las validaciones de los datos de entrada antes de usarlos,
esto provoca que la mayoría sean sensibles a ataques contra el sistema de ficheros
o ataques de desbordamiento de buffer entre otros, al verse afectadas por
vulnerabilidades. Para llevar a cabo este análisis se realizan las siguientes pruebas:

 Pruebas de XSS (stored, reflected y basados en el DOM).

 Pruebas de Cross Site Flashing.
 Pruebas de inyección de código SQL.
  Pruebas de inyección LDAP.
 Pruebas de inyección ORM.
 Pruebas de inyección XML.
 Pruebas de inyección SSI.
 Pruebas de inyección XPATH.
 Pruebas de inyección IMAP/SMTP.
 Pruebas de inyección de código.
 Pruebas de inyección de comandos de sistema operativo.
 Pruebas de desbordamiento de memoria.
 Pruebas de HTTP Splitting/Smuggling.

Análisis de negación de servicio:

La negación de servicio (DoS) tiene como objetivo impedir que un sistema

proporcione la actividad habitual a los usuarios. Estos ataques maliciosos pueden
producirse privando a un sistema de recursos críticos, explotando vulnerabilidades
o mediante un abuso de funcionalidad.

Lo que se pretende en este punto es verificar si el sistema resulta vulnerable a

este tipo de amenazas, para ello se llevan a cabo las siguientes pruebas:

 Pruebas de bloqueo de cuentas de usuario.

 Pruebas sobre escritura en disco.
 Pruebas sobre liberación de recursos.
 Pruebas de consultas SQL intensivas de CPU.

Análisis de Web Services:

Se llevará a cabo un análisis sobre los Web Services implementados para intentar
detectar deficiencias. Se revisarán controles de acceso y seguridad a nivel IP, la
configuración, fugas de información motivada por deficiencias en la gestión de
errores y excepciones, filtros de validación implementados, así como la existencia
de controles de auditoría y logging.

 Pruebas de recopilación de información.

 Pruebas sobre la estructura XML.
 Pruebas de parámetros GET de HTTP y REST.
 Pruebas de datos adjuntos en SOAP.
 Pruebas de repetición en Web Services.

Controles internos.

Se define el control interno como el proceso diseñado, implementado y mantenido

por los responsables del gobierno de la entidad, la dirección y otro personal, con la
finalidad de proporcionar una seguridad razonable sobre la consecución de los
objetivos de la entidad relativos a la fiabilidad de la información financiera, la
eficacia y eficiencia de las operaciones, así como sobre el cumplimiento de las
disposiciones legales y reglamentarias aplicables.

Un control es la combinación de métodos, políticas y procedimientos que

garantizan la protección de los activos de la organización, la precisión y la
confiabilidad de sus registros, y el cumplimiento las directrices de la dirección en la
consecución de dichos objetivos.

Las actividades de control o controles internos pueden estar totalmente

automatizadas (circunstancia habitual en los actuales sistemas informáticos de
gestión), pueden ser manuales dependientes de las TIC (bastante frecuentes
también) o completamente manuales (cada vez más escasos).

En una auditoría financiera se considerará que un sistema de control interno es

efectivo si los controles son respetados y dan una seguridad razonable de que no
habrá errores o irregularidades que afecten de manera significativa a los estados
financieros.

Controles en aplicaciones.

Los controles de aplicación permiten asegurar la completitud, exactitud, precisión,

validez e integridad de los datos, en el procesamiento de las transacciones a través
de las aplicaciones informáticas. Estos controles se implementan en las etapas de
entrada, procesamiento y salida de los sistemas informáticos.

Están diseñados para evitar que se ingresen al sistema datos erróneos, es decir
que son primeramente controles preventivos. También permiten detectar y corregir
errores que fueron ingresados al sistema con anterioridad.

Los controles de aplicación se establecen para proporcionar una seguridad

razonable de que los objetivos que la gerencia establece sobre las aplicaciones, se
alcanzan. Consisten en actividades manuales y/o automatizadas que aseguran que
la información cumple con ciertos criterios, los que COBIT refiere como
requerimientos de negocio para la información. Estos criterios son:

 Efectividad
 Eficiencia
 Confidencialidad
 Integridad
 Disponibilidad
 Cumplimiento
 Confiabilidad.
Los controles de aplicación se establecen para proporcionar una seguridad
razonable de que los objetivos que la gerencia establece sobre las aplicaciones, se
alcanzan. Estos objetivos se articulan típicamente a través de funciones específicas
para la solución, la definición de las reglas de negocio para el procesamiento de la
información y la definición de procedimientos manuales de soporte. Ejemplo de
ello son:

 Totalidad (Integridad)
 Exactitud
 Validez
 Autorización
 Segregación de funciones

Es necesario asegurarse de que existen suficientes controles para mitigar los

riesgos y que están operando con la efectividad necesaria para proveer
información confiable. Durante el ciclo de vida de los sistemas, diversas partes de la
organización realizan actividades, responsabilidades y roles asociados con los
controles de aplicación.

Dependencia de los Controles Generales de TI:

Los controles generales de TI son aquellos que tienen que ver con el ambiente de
proceso de TI en el cual operan los controles de aplicación. Entre los controles
generales están por ejemplo:

 Control de cambios a programas

 Controles de acceso físico
 Controles de acceso lógico
 Controles de continuidad operativa
El hecho de que los controles generales sean adecuados, no garantiza que los
controles de aplicación serán adecuados. Pero si los controles generales son
deficientes, los controles de aplicación muy probablemente lo serán también.

Tipos de controles de aplicación:

1. Controles de aplicación Manuales.

Son controles ejecutados sin la asistencia de sistemas automatizados.
Ejemplos:
 Autorizaciones escritas, como firmas en cheques.
 Reconciliación de órdenes de compra con los formatos de recepción
de mercancías.

2. Controles de aplicación Automatizados.

Son controles que han sido programados e integrados en una aplicación
computacional. Ejemplos:
 Validaciones de edición y contenido de datos de entrada.
 Dígitos verificadores para validar números de cuenta.

3. Controles de aplicación Configurables.

Son controles automatizados que están basados y por lo tanto son
dependientes de la configuración de parámetros dentro de la aplicación.
Ejemplo:
 Un control en un sistema de compras automatizado, que permite
órdenes hasta un límite de autorización, es dependiente de controles
sobre los cambios en los límites pre configurados de autorización.
 En muchos casos, las aplicaciones comerciales o desarrolladas en casa, son
altamente dependientes de la configuración de varias tablas de parámetros.

Es apropiado considerar el diseño del control sobre las tablas como un

elemento separado.