Administración de sistemas informáticos.

Universidad Nacional de Colombia sede

Manizales.
Auditoría de sistemas I.
Caso de aplicación
Docente: Francisco Javier Valencia Duque
La respiración artificial para un ERP
El escenario quizá te resulte familiar: tu empresa –u otra que conoces bien- ha caído
seducida por la idea de comprar un sistema ERP que integre todas las operaciones de la
compañía. El ERP te permitirá emplear una tecnología nueva y sexy, sea cliente/servidor, o
sea un conjunto de aplicaciones basadas en el Web, que sustituirán a todos esos sistemas
horrorosos, mainframes paquidérmicos que no pueden mantener el ritmo de tus
necesidades. Mejor aún, como se va a comprar, en vez de desarrollar internamente, son los
expertos funcionales de las áreas de negocio los que se pueden hacer cargo de la
implantación, en vez de los tecnócratas del departamento de TIC. Prescindiendo de los
servicios de TIC y su tediosa disciplina de desarrollo y prueba, las cosas van a ir mucho
más rápidas. Verás.
No te pienses que no vas a necesitar ayuda, por supuesto. Una tropa de choque de
consultores aterrizará para estos fastos –pero no customizarán el software, exactamente. Lo
que harán será reingeniería de tus procesos de negocio, para poder emplear las ventajas de
un sistema tan potente. Así, tan pronto como hayan configurado unas cuantas opciones aquí
y allá para recoger la idiosincrasia de tus operaciones, serán transportados lejos de allí, y tú
te verás catapultado hacia la tierra prometida de la eficiencia sin par.
Entonces, ¿qué es lo que falla?. Justo lo que viene después. El hecho desgraciado es que
muy pocas organizaciones operan de forma homogénea, aunque haya una clara tendencia
hacia la estandarización de procesos. De hecho, a menudo son esas idiosincrasias en los
procesos de negocio lo que da a una empresa su fuerza competitiva.
Pocos sistemas de empresa adquiridos pueden realmente reemplazar cada esquina y
cada atajo de tus aplicaciones hechas en casa, así que será inevitable tener que desarrollar
algo de código. Pocas implementaciones de ERP, si es que ha habido alguna, pueden
hacerse directamente solo con desenvolver el paquete en el que viene.
Hasta la última línea de configuración de procesos de negocio, o de customización del
software, debe desarrollarse y probarse antes de la implementación inicial, y además cada
vez que se instala en el sistema una nueva versión del ERP, o se hace un cambio en la
configuración, o se actualiza la infraestructura, o… . ¿Te das cuenta?. Pero entonces, los
consultores, sus conocimientos, y sus abultados honorarios, hará tiempo que han volado.
Contorsión de procesos de negocio
Imagínate un grupo industrial que piensa sustituir un sin fin de aplicaciones, que
funcionan desde tiempo inmemorial, por un sistema ERP totalmente integrado. La
compañía es plenamente consciente de la enormidad de la tarea, y de acuerdo con esto
presupuesta tiempo, dinero y consultores. Se invierten dos años en un exhaustivo análisis
de la realidad de los procesos de negocio existente, y un diseño reiterativo de tales proceso
“como debían ser”. Como resultado se llega a un conjunto destilado de reglas de negocio y
scripts de transacciones que se utilizan para configurar el ERP. Cerca de una docena de
aplicaciones antiguas que no tenían equivalente comercial se integran a través de una serie
de interfaces. Los usuarios de todo el mundo se forman en los nuevos procesos, y el equipo
de implementación, formado por consultores y selectos usuarios efectúan una serie de
pruebas costosas y minuciosas.
La fecha de arranque llega. ¡Estamos en directo!. Las primeras semanas fueron un poco
movidas…. El help desk estaba completamente desbordado, y los usuarios intentando
encontrar su responsabilidades en este nuevo orden de las cosas. La seguridad fue un
verdadero problema, con los niveles de autorización controlando el acceso a los procesos, y
muchos usuarios encontrándose con lo permisos denegados para efectuar sus trabajos.
Varios interfaces fallaron. Los servidores empezaron a chirriar, así que hubo que acometer
ampliaciones y upgrades de hardware.
En múltiples ocasiones hubo que efectuar envíos de producto por cargo aéreo, ya que la
coordinación entre producción, almacenes, y expedición tenía unos cuantos problemillas.
No menos de 60 consultores pululaban alrededor, con sus teléfonos móviles sonando
frenéticamente y sus buscapersonas echando humo, intentando tapar con sus manos las
grietas que se estaban produciendo en el dique. Fue necesario aprobar una ampliación del
presupuesto del proyecto, para mantener al equipo consultor más tiempo, y se produjeron
tensas negociaciones para mantener en el proyecto a personas clave que se había
planificado pasaran ya a otros proyectos.
Al fin parece que las cosas se calmaron un poco, pero era como estar en el ojo del un
huracán. Tres cosas ocurrieron en los meses posteriores:
En primer lugar se comenzó a formar un montón creciente de peticiones de cambios. La
mayoría de decisiones de procesos que parecían buenas sobre el papel, pero simplemente
fallaron en la realidad. Esto obligó a implementar temporalmente intrincadas vías para dar
salida a los problemas.
Estas nuevas peticiones de cambio se añadieron a la lista que se había formado desde la
implementación inicial. Según se acercaba la fecha límite, los requerimientos que no
pudieron ser atendidos fueron pospuestos “para más tarde”. Algunos de estos eran de
integración de sistemas que inicialmente habían sido “pegados con clips de papel y cinta
adhesiva”, ante la promesa de futuras eficiencias.
En segundo lugar, comenzaron a llegar las ampliaciones de equipos. Las necesidades de
almacenamiento de datos habían sido subestimadas. Fueron surgiendo archivos históricos
cada vez mayores, sin que nadie quisiera depurarlos. El rendimiento de los sistemas cayó
bajo mínimos en algunos trabajos, y aparecieron misteriosas e intermitentes caídas en las
redes.
Y finalmente, el vendedor anunció la disponibilidad de una nueva versión del ERP, con
muchas mejoras importantes (justo lo que faltaba por añadir al caos). Se hizo evidente, con
mucho dolor, que implementar un ERP es un proceso sin fin. El que se compre un sistema
en vez de desarrollarlo no significa que haya que olvidarse del tema de la calidad. En ese
caso, el desafortunado departamento TIC se habrá encontrado frente a una tarea de alto
riesgo: recablear la casa mientras las luces se mantienen encendidas, y con sólo una
fracción de los recursos que se emplearon en la implementación inicial. Puesto que la
configuración original y pruebas fueron efectuadas por consultores, el departamento de TIC
carecía del personal, de los procesos y de las habilidades para hacerlos eficaz y
eficientemente.
La lección que se puede extraer es que no existe el “gratis total”. Hay una clara razón
por la que existe un departamento de TIC y todas esas matracas (pero críticas) de
integración de software, y pruebas y aceptación de sistemas. El software, la infraestructura
y los procesos de negocio tienen que funcionar en el mundo real.
Más aún, hacer que el software encaje en el negocio hace inevitable la customización,
pero en el momento en que se ha cambiado algo de un ERP, no se puede aceptar nuevas
versiones del vendedor sin reimplementar los cambios (¡y volver a probar todo!). Los
consultores que hicieron los cambio originales se han ido hace ya tiempo, así que adivina
quién se va a comer el marrón en esta historia. Pues esa gente tan poco seria de TIC.
Ironías.
Finalmente, el viejo y humeante mainframe, que tienes que tirar para unirte al nuevo
orden tecnológico, ha sido sustituido por un sinnúmero de servidores, y tus costes de
soporte de sistemas se han multiplicado – en vez de dividirse.
El software es el software, lo compres o lo desarrolles, y lo que tienes que hacer es
asegurarte de encaja en todo lo que le rodea, y que tus usuarios pueden hacer su trabajo de
forma eficiente y a tiempo.
1. Con base en el caso, cuál cree usted que debe ser el rol que debe jugar el
auditor de sistemas en este tipo de situaciones:

En este caso el auditor de sistemas no intervendría en una auditoria sino que

prestaría los servicios como consultor, investigando sobre las causas que
generaron las fallas y como se podrían evitar en un futuro.
Asesoraría en la implementación de controles específicos relacionados con cada
riesgo potencial.

2. Identifique 5 activos tecnológicos, que usted considere se pueden encontrar

en una situación de este tipo.
 Servidores
 Computadores
 Bases de Datos
 Aplicativos
 La Red
 3. Establezca 2 amenazas por cada activo tecnológico.
 Servidores: Desastres Naturales: Incendios, inundaciones,
Sobre carga de usuarios, falla eléctrica
 Computadores: falla eléctrica, daño de disco duro sin respaldo.
 Bases de Datos: perdida de la información, redundancia de datos, caída del
sistema.
 Aplicativos: código malicioso (virus), falta de seguridad.
 La Red: falla eléctrica, manipulación ajena o un espía de la red.

4. Defina el riesgo
 Sobre carga de usuarios en servidores.
 Falla eléctrica en el suministro de energía de los servidores.
 Daño disco duro del computador.
 Falla eléctrica del computador.
 Perdida de la información de las bases de datos.
 Redundancia de datos en las bases de datos.
 Virus en aplicativos.
 Falta de seguridad en los aplicativos.
 Falla eléctrica en red.
 Espías en la red.

5. Establezca parámetros de probabilidad, parámetros de impacto y

parámetros de calificación del riesgo.

 Parámetros de probabilidad:
1: probabilidad de ocurrencia entre 1% a 30%
2: probabilidad de ocurrencia de 30% a 60%
3: probabilidad de ocurrencia 60% a 99%
 Parámetros de impacto:
1: Impacto Bajo
2: Impacto Medio
3: Impacto Alto
 Parámetros de clasificación del Riesgo

  Probalilidad (1-3)      
  Impacto (1-3)      
           
  Riesgo= Probabilidad*Impacto    
           
  Aceptable (1-3)      
  Preocupante  (4)      
  Riesgo Alto  (6)      
  Inaceptable  (9)      
     
 3

2
  1
3 6 9
  1 3    

ABI
2

LID
OB

AD
PR 2 4 6
     
1 IMPACTO
2 3
     
           
           
           

6. Establezca el riesgo inherente

Sobrecarga de usuarios en servidores:

           
  Sobrecarga De usuarios Probabilidad 2
 
  Impacto 2
        Riesgo 4
  3 6 9    
  2 4 6    
  1 2 3    
           
           
           

3
Falla eléctrica en el suministro de energía de los servidores.
2
           
1 Falla eléctrica en el suministro
  Probabilidad 2
de energía de los servidores
  Impacto 2
        Riesgo 4
  3 6 9    
  2 4 6    
  1 2 3    
      1     2   3
      IMPACTO
     
           
ABI
LID
AD
OB
PR

Daño disco3duro del computador.

2

1
1 2 3
           
  Probabilidad 1
Daño disco duro del computador

ABI
LID
AD
OB
PR
  Impacto 3
        Riesgo 3
  3 6 9    
  2 4 6    
  1 2 3    
           
           

Falla eléctrica del computador.

           
  Falla eléctrica del computador. Probabilidad 1
 
  Impacto 2
        Riesgo 2
  3 6 9    
  2 4 6    
  1 2 3    
           
  3          
IMPACTO
  2          
1

Perdida de la
3 información de las bases de datos.

  2          
  Perdida de la información Probabilidad 1
1
de las bases de datos. 3
  1 Impacto 2 3
        Riesgo 3
  3 6 9    
  2 4 6    
  1 2 3    
      1     2  
            3
ABI
LID
AD
OB
PR

           
IMPACTO
ABI
LID
AD
OB
PR

1
Redundancia de datos en las bases1 de datos. 2 3

       
IMPACTO    
  Redundancia de datos Probabilidad 1

ABI
LID
AD
OB
PR
en las bases de datos.
  Impacto 3
        Riesgo 3
  3 6 9    
  2 4 6    
  1 2 3    
           
           
           

Virus en aplicativos.
3

  2          
  Virus en aplicativos. Probabilidad 2
1
 
  Impacto 2
        Riesgo 4
  3 6 9    
  2 4 6    
  1 2 3    
           
      1     2   3
           
IMPACTO
ABI
LID
AD
OB

Falta de seguridad en los aplicativos.

PR

  2          
  Falta de seguridad en los aplicativos. Probabilidad 3
1
 
  Impacto 2
        Riesgo 6
  3 6 9    
  2 4 6    
  1 2 3    
           
      1     2   3
           
IMPACTO
ABI
LID
AD
OB
PR

1
 2
Falla eléctrica en red. 1 3

           
IMPACTO
  Falla eléctrica en red. Probabilidad 2

ABI
LID
AD
OB
PR
 
  Impacto 2
        Riesgo 4
  3 6 9    
  2 4 6    
  1 2 3    
           
           
           

Espías en la3 red.

  2          
  Espias en la red. Probabilidad 2
1
 
  Impacto 3
        Riesgo 6
  3 6 9    
  2 4 6    
  1 2 3    
           
      1     2   3
           
IMPACTO
ABI
LID
AD
OB
PR

2
7. Identifique 2 controles por cada riesgo, que ustedes consideren que podrían llegar
a 1tener cada uno de los riesgos identificados.
8. Establezca el riesgo residual

1 2 3
IMPACTO
 Sobre carga de usuarios en servidores.
Control 1: Servidores (dependiendo la empresa)
ABI
LID
AD
OB
PR
 Control 2: Realizar pruebas de Sobrecarga

           
  Sobre carga de usuarios Probabilidad 1
en servidores
  P Impacto 2
  R       Riesgo 2
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    
IMPACTO      
  A          
D
 Falla eléctrica en el suministro de energía de los servidores.
Control 1: UPS
Control 2: Corta Picos

           
  Falla eléctrica Probabilidad 1
en servidores
  P Impacto 2
  R       Riesgo 2
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    
IMPACTO      
  A          
D
 Daño disco duro del computador.
Control 1: Backups
Control 2: Espejo en la WEB

           
  Daño disco duro Probabilidad 1
Computador
  P Impacto 1
  R
3       Riesgo 1
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
LI  Falla 3
1 eléctrica del2 computador.
D Control 1: IMPACTO
UPS
A
D
 Control 2: Espejo en la WEB

           
  Falla Electrica Probabilidad 1
Computador
  P Impacto 1
  R       Riesgo 1
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    
IMPACTO      
A  Perdida de la información de las bases de datos.
D Control 1: Backups
Control 2: Varios servidores

           
  Perdida de la información Probabilidad 1
Bases de datos
  P Impacto 1
  R       Riesgo 1
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    
IMPACTO      
A  Redundancia de datos en las bases de datos.
D Control 1: Buen Diseño de bases de datos
Control 2: Planeación y mantenimiento BD

           
  Redundancia Probabilidad 1
Bases de datos
  P Impacto 2
  R
3       Riesgo 2
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
D  Virus en aplicativos.
IMPACTO
A Control 1: Antivirus
D
 Control 2: Firewall

           
  Virus Probabilidad 1
Aplicativos
  P Impacto 2
  R       Riesgo 2
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    
IMPACTO      
A  Falta de seguridad en los aplicativos.
D Control 1: Protección de puertos
Control 2: Encriptamiento

  Falla seguridad Probabilidad 2

Aplicativos
  P Impacto 2
  R       Riesgo 4
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    IMPACTO      
A
D
 Falla eléctrica en red.
Control 1: Soporte Redes
Control 2: Actualización de Redes si fuere necesario

  Falla electrica Probabilidad 1

RED
  P Impacto 2
  R       Riesgo 2
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    IMPACTO      
A
D
 Espías en la red.
 Control 1: Software anti espía
Control 2: Encriptamiento de información

  Espias Probabilidad 1
RED
  P Impacto 3
  R       Riesgo 3
3
  O 3 6 9    
B 2 2 4 6
     
A 1
  1 2 3    
BI
  LI   1   2   3    
  D    IMPACTO      
A
D

10.Elaboré un plan de mitigación de riesgos.

Al realizar el estudio de análisis de riesgos varios controles en todos los riesgos concidieron
y unos no aca están numerados los controles mas necesarios para realizar en orden de
prioridad:
a. UPS para toda la empresa.
b. Copias de seguridad tanto en la empresa como en la nube.
c. Antivirus, anti espías
d. Mantenimiento a Bases de datos.

Estas son las mas importantes a tener en cuenta en la mitigación de riesgos.