El documento analiza un ataque cibernético a una compañía de procesamiento de tarjetas de crédito en India, donde hackers infiltraron el sistema y aumentaron los límites de retiro en cuentas de débito, culminando en el robo de 5 millones de dólares. Se destacan fallos en los controles de seguridad, tanto de software como de hardware, y la falta de previsión ante vulnerabilidades. Además, propone una serie de mecanismos de prevención y control para mitigar riesgos en el ciclo de vida de las aplicaciones.

1. JuanAstudillo, Exequiel Gómez

2. HackingCorporativo
ContextoPrincipal,casoreal

3. HackingCorporativoControldeAplicaciones
Contexto Principal
Fase 1: infiltración y aumento límite de retiro de las cuentas de
débito
En el primer robo, los hackers pudieron infiltrar el sistema de
una compañía de procesamiento de tarjetas de crédito india que
maneja las tarjetas de débito prepagadas Visa y MasterCard. Los
hackers procedieron a elevar los límites de retiro en las cuentas de
débito MasterCard prepagadas que son emitidas por el Banco
Nacional de Ras Al-Khaimah, con sede en los Emiratos Árabes
Unidos.

4. HackingCorporativoControldeAplicaciones
Fase 1: infiltración y aumento límite de retiro de las cuentas de
débito

5. HackingCorporativoControldeAplicaciones
Fase 2: distribución y clonación de tarjetas
Al eliminar los límites de retiro, “incluso unos pocos números de
cuentas bancarias comprometidas pueden significar enormes pérdidas
financieras para la institución víctima”, señala el documento.
Con cinco números de cuenta a mano, los hackers distribuyeron la
información a individuos en 20 países, quienes luego codificaron la
información en tarjetas con huincha magnética.

6. HackingCorporativoControldeAplicaciones
Fase 2: distribución y clonación de tarjetas

7. HackingCorporativoControldeAplicaciones
Fase 3: utilización tarjetas clonadas
El 21 de diciembre, los “equipos del efectivo” hicieron 4.500
transacciones en los cajeros automáticos en todo el mundo, con lo que
robaron US$ 5 millones.

8. HackingCorporativoControldeAplicaciones
Fase 3: utilización tarjetas clonadas

9. HackingCorporativo
ControldeAplicaciones
desdeelpuntodevistadeAuditoriaComputacional

10. HackingCorporativoControldeAplicaciones
Los Controles de aplicación son aquellos controles que son aplicables
para un determinado proceso de negocio o aplicación, entre ellos podemos
encontrar la edición de registros, segregación de funciones, totales de control,
logs de transacciones y reportes de errores.
El objetivo principal de los controles de aplicación es asegurar:
•Que el ingreso de los datos es exacto, completo, autorizado y correcto
•Que los datos son procesos en tiempo oportuno
•Los datos son almacenados de forma adecuada y completa
•Que las salidas del sistema son adecuadas y completas
•Que registros son mantenidos para realizar un seguimiento de las entradas y
eventuales salidas del sistema.

11. HackingCorporativoControldeAplicaciones
En este sentido pueden existir distintos tipos de controles de aplicación como ser:
Controles de Ingreso: Los cuales son utilizados para mantener la integridad de los datos que
son ingresados al sistema.
Controles de Procesamiento: Estos controles, principalmente automáticos proveen una
manera automática de asegurar que el procesamiento de las transacciones es completa,
adecuado y autorizado.
Controles de salida: Básicamente estos controles direccionan a que operaciones fueron
realizadas con los datos. Y comparando también básicamente las salidas generadas con los
ingresos realizados.
Controles de integridad: Estos controles permitan verificar la integridad y consistencia de
los datos procesados.
Logs: Principalmente utilizados como “Audit Trail”, permiten a la gerencia identificar hechos
inusuales para posterior investigar los mismos.

12. HackingCorporativoControldeAplicaciones
Respondiendo las preguntas respecto al Contexto
1.- ¿Qué fallo?
En la primera fase está claro que fallaron los sistemas de la empresa procesadora
de tarjetas de crédito.
El software fue el elemento clave en el ataque de los hackers, inclusive más
importante que el hardware, ya que los sistemas están preparados y construidos con
requerimientos funcionales desde las propias empresas.
También al no existir controles de consistencia de datos es casi imposible poder
demostrar empíricamente y en un corto periodo de tiempo que se está en una situación de
riesgo en la información o en una situación de ataque o en una víspera de uno. Al contar con
mecanismos que se permita prever con anticipación un ataque, mayor seguridad se aporta a
la organización y a su modelo de negocio.
Otros:
•No existieron controles de cambio y validación de los sistemas.
•Baja seguridad tanto a nivel de Software (1) como de Hardware (2) .

13. HackingCorporativoControldeAplicaciones
2.- ¿Por qué fallo?
Fallo por que los proveedores de software y hardware internos como externos
fueron incapaces de ver comportamientos poco previstos con frecuencia en las etapas 1 y 2.
El exceso de confianza en sistemas críticos puede pasar la cuenta. No verse
vulnerable es el gran error grave dentro del desarrollo de software y que no es considerado
por la Ingeniería de Sistemas Clásica.
Otros:
•Esto sumado a terror a las consecuencias por el fallo, impidió la correcta comunicación entre
las partes, permitiendo otro ataque.
•Falta la previsión y posterior al ataque también se nota la larga brecha entre el ataque y la
reparación de errores.
•Cuando se construye un software se pueden ver los comportamientos que se desea tener a
nivel de ingeniería de software en su ingeniería de requerimientos y ver cómo se comporta
con respecto a un usuario que lo ocupa.
•Existen diversas formas de analizar la información a este nivel, para ello existe el control de
aplicación, y debió haberse ocupado de forma modular en todo el ciclo de vida del negocio
desde un punto de vista ingenieril haciendo todas las pruebas necesarias.

14. HackingCorporativoControldeAplicaciones
3.- ¿Mecanismos de prevención y control que se debiesen implantar?
Una buena práctica de prevención y control debería ser el uso de Controles
generales del ambiente de cómputo, tanto para Hardware como para Software, en todas las
infraestructuras que involucren el ciclo de vida del negocio a auditar:
•Procedimientos y protocolos de contingencia.
•Protocolos de comunicación y reparación.
•Controles y definición de responsabilidad.
•Protocolos de control de riesgos.
•Acceso lógico sobre infraestructura, aplicaciones y datos.
•Controles sobre el desarrollo y ciclo de vida de los aplicativos.
•Controles sobre cambios a programas.
•Controles sobre seguridad física en los centros de cómputos.
•Backup de sistemas y controles de recuperación de datos.
•Controles relacionados con operaciones computarizadas.

15. HackingCorporativoControldeAplicaciones
1.Para una evaluación de Riesgo completa debemos definir el universo Hardware, Software, Aplicaciones,
bases de datos y tecnología de soporte que utilizan los
controles de aplicación.
2.Como un segundo paso definir los factores de riesgo asociados con cada aplicación. Por ejemplo:
¿Es control clave?
¿El diseño es efectivo?
¿Es un software pre configurado o bien desarrollo propio?
¿La aplicación soporta más de un proceso crítica?
¿Cuál es la frecuencia de los cambios de la aplicación?
¿Cuál es la complejidad de los cambios?
¿Cuál es el impacto financiero?
¿Cuál es la efectividad de los controles generales?
Todos estos elementos ponderados terminarán dando para cada aplicación un total que
determinará el ranking del nivel de riesgo para cada aplicación, considerando tanto factores cuantitativos
como cualitativos, como por ejemplo:
-Controles con Bajo, medio o alto impacto ó
Por ejemplo 1= Control fuerte a 5= inadecuado control
Una vez rankeadas todas las aplicaciones, y evaluado los resultados, debemos generar un plan
de acción basado en la evaluación de riesgos enunciada anteriormente, que tienda a mitigar los riesgos
asociados con las aplicaciones que tuvieron un mayor score en el ranking.

16. Conclusiones
Este trabajo para nosotros a sido muy importante, ya que nos ayuda concretamente en
nuestros proyectos informáticos, haciéndonos participar del aprendizaje de una auditoria real y concreta
de software o hardware. Incluso podemos incorporar este tema del control de aplicaciones en nuestro
trabajo, en nuestros proyectos de estudio o práctica profesional.

17. Gracias