Word Auditoria

Universidad Mariano Gálvez de Guatemala
Maestría en Seguridad Informática

Auditoria Informática
Ma. Ing. Brenda Amarilis Gramajo González
Proyecto
AUDITORIA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE,

APLICADA AL DEPARTAMENTO DE TECNOLOGIA DE LA EMPRESA
MOVILAND
Roby Andrés Maldonado Pineda 1793-17-11524

Moisés Adolfo Vicente Guzmán 1793-17-08774
Luis Alberto Cabrera Barrios 1793-16-11344
Francisca Eloina Carrillo García 1793-14-17322
Mauricio Ferdinand Morales Reyes 1793-06-09344
Rubens Alejandro Castillo Florian 1793-06-09280
Fin de Semana, sábado

Sección “A”
24 de marzo de 2023
ÍNDICE
INTRODUCCIÓN .................................................................................................... 1
1. MARCO CONCEPTUAL ..................................................................................... 2
1.1. Presentación de la empresa ............................................................... 2
2. MARCO TEÓRICO ............................................................................................. 3
2.1. Administración ..................................................................................... 3
2.2. Amenaza ............................................................................................. 3
2.3. Auditoría .............................................................................................. 4
2.4. Confiabilidad ....................................................................................... 4
2.5. Confidencialidad .................................................................................. 4
2.6. Controles ............................................................................................. 5
2.7. Disponibilidad ...................................................................................... 5
2.8. Gestión ................................................................................................ 6
2.9. Gobernanza ........................................................................................ 6
2.9. Impacto ............................................................................................... 7
2.10. Información ......................................................................................... 8
2.11. Informe ................................................................................................ 8
2.12. Integridad ............................................................................................ 9
2.13. Planificación de aseguramiento .......................................................... 9
2.14. Políticas de seguridad ......................................................................... 9
2.15. Proceso de Auditoría ......................................................................... 10
2.16. Riesgo informático ............................................................................ 11
2.17. Seguridad .......................................................................................... 11
2.18. Sistema ............................................................................................. 11
2.19. Vulnerabilidad ................................................................................... 12
3. RECURSOS TECNOLOGICOS ........................................................................ 13
3.1. Data Center Principal ........................................................................ 13
3.2. Gabinete de comunicaciones Bodega de llantas .............................. 14
4. METODOLOGÍA ............................................................................................... 15
4.1. Alcance ............................................................................................. 15
4.2. Definición Del Proceso De Auditoría De Sistemas ........................... 15
4.3. Ciclo De Vida Del Desarrollo De Software ........................................ 16
4.4. Plan Integral De Auditoria De Sistemas ............................................ 17
4.5. Inventario de Activos ...........................................................................
20
4.5.1. Criticidad de Activos .............................................................. 26
4.5.2. Criterio de Evaluación de Activos ......................................... 29
4.6. Análisis y Evaluación De Riesgos...................................................... 29
4.6.1. Identificación de amenazas ................................................... 29
4.6.2. Descripción de Amenazas ..................................................... 31
4.6.3. Matriz De Riesgo ................................................................... 38
3.6.4. Definición Del Plan De Tratamiento ...................................... 49
4.6.5. Cuadro Gerencial .................................................................. 52
4.7. Esquema De Auditoría (Presenciales, Remota, Otros) ..................... 53
4.8. Guías Y Checklist .............................................................................. 55
5. DESARROLLO DE AUDITORÍA ....................................................................... 72
5.1. Procedimiento ................................................................................... 72
5.2. Auditoría del entorno de desarrollo ................................................... 72
5.3. Auditoría de la fase de análisis ......................................................... 73
5.4. Auditoría de la fase de Diseño .......................................................... 73
5.5. Auditoría de la fase de desarrollo ..................................................... 74
5.6. Auditoría de la fase de implementación ............................................ 74
6. Formato del informe de auditorías .................................................................... 75
6.1. Informe de fase de análisis para tarea 1 ........................................... 75
6.2. Informe de tarea 2 de la fase de análisis .......................................... 77
6.6. Informe de tarea 1 de la fase de diseño ........................................... 83
6.11. Informe de tarea 1 de la fase de desarrollo ...................................... 89
6.18. Informe de tarea 1 de la fase de implementación.............................. 96
6.20. Informe de tarea 3 de la fase de implementación ............................. 98
6.22. Informe de tarea 5 de la fase de implementación............................ 100
6.23. Informe de tarea 1 de la fase de mantenimiento ............................ 101
6.24. Informe de tarea 2 de la fase de Mantenimiento ............................ 102
6.25. Carta de presentación para auditoría ............................................. 103
CONCLUSIONES ............................................................................................... 105
RECOMENDACIONES ....................................................................................... 106
ANEXO ............................................................................................................... 107
BIBLIOGRAFÍA ................................................................................................... 110
ÍNDICE DE GRÁFICOS
Gráfico No. 1 Ciclo de vida del Desarrollo de Software ........................................16

Gráfico No. 2 Matriz para A1 ................................................................................ 38
Gráfico No. 10 Matriz para A9 .............................................................................. 42
Gráfico No. 11 Matriz para A10 ............................................................................ 42
Gráfico No. 25 Organigrama de área IT ............................................................... 53
ÍNDICE DE TABLAS
Tabla No. 1 Listado de Activos Tecnológicos Data Center Principal .....................13

Tabla No. 2 Listado de Activos Gabinete de Bodega ........................................... 14
Tabla No. 3 Cronograma de Actividades .............................................................. 18
Tabla No. 4 Inventario de Activos ......................................................................... 20
Tabla No. 5 Valoración de Criticidad de Activos ................................................... 26
Tabla No. 6 Criterio de Evaluación ....................................................................... 29
Tabla No. 7 Identificación de Amenazas ............................................................... 30
Tabla No. 8 Medidas de Seguridad ....................................................................... 49
Tabla No. 9 Cuadro Gerencial .............................................................................. 52
Tabla No. 10 Matriz De Seguimiento A La Atención De Puntos De Auditoría ...... 65
Tabla No. 11 Informe de Auditorías ...................................................................... 75
Tabla No. 12 Informe de Auditoría en Fase de Análisis ........................................ 75
ÍNDICE DE CKECKLIST
Checklist No. 1 Proceso de Documentación .......................................................56

Checklist No. 2 Fase de Análisis .......................................................................... 57
Checklist No. 3 Fase de Diseño ........................................................................... 61
Checklist No. 4 Fase de desarrollo ...................................................................... 62
Checklist No. 5 Fase de Implementación ............................................................. 63
Checklist No. 6 Fase de Mantenimiento ...............................................................
64 ÍNDICE DE ANEXOS
Anexo No. 1 Tablero de Actividades TRELLO ................................................... 107

Anexo No. 2 Informe de Resultados Mediante SonarQube ............................... 107
Anexo No. 3 Captura de Problemas Hallados ................................................... 108
Anexo No. 4 Lista de Riesgos ............................................................................ 108
1
INTRODUCCIÓN
La auditoría del ciclo de vida de desarrollo de software es fundamental para

asegurar que los sistemas informáticos de una organización funcionen de manera
eficiente y segura, especialmente en un entorno empresarial cada vez más
dependiente de la tecnología. Moviland, como empresa líder en el sector,
reconoce la importancia de mantener sus sistemas de software actualizados y
protegidos. En este contexto, se ha decidido llevar a cabo una auditoría específica
en el departamento de tecnología de la empresa.
El objetivo principal de esta auditoría es evaluar y mejorar el proceso de

desarrollo de software en el departamento de tecnología de Moviland, utilizando
herramientas y técnicas especializadas para analizar la seguridad y los riesgos
asociados a su infraestructura informática. Este enfoque permite identificar áreas
de mejora y garantizar el cumplimiento de los requisitos de calidad y seguridad en
todas las etapas del ciclo de vida del software.
Los resultados de la auditoría serán documentados y compartidos con la

alta dirección de Moviland, proporcionando información valiosa para tomar
decisiones fundamentadas sobre cómo optimizar y proteger sus sistemas
informáticos. En última instancia, este proceso de auditoría contribuirá a asegurar
que los sistemas de software estén alineados con las necesidades y objetivos de
la empresa, y que se mantengan seguros y protegidos en todo momento.
2
1. MARCO CONCEPTUAL
1.1. Presentación de la empresa
Fundada en 2005, Moviland es una empresa Líder en la venta de

refacciones (Repuestos), en toda Guatemala, con una sucursal que distribuye en
todo el país, Nuestra misión es ofrecer productos de alta calidad y confiabilidad a
nuestros clientes, satisfaciendo las necesidades y siendo partícipes en ser
generador de ingresos para muchas familias guatemaltecas en el país. Dentro de
los valores fundamentales de nuestra empresa incluyen, la responsabilidad, el
compromiso, la humildad, la mejora continua, el respeto y la innovación.
La empresa formada por un grupo de colaboradores profesionales quienes

están comprometidos con la a brindar cada vez más un mejor servicio a nuestros
clientes, comprometidos con la atención, las ventas, la facturación y envíos a
todos nuestros clientes, de manera eficiente.
Dentro de la estructura de la empresa la tecnología es la parte fundamental

por el cual se realizan todas las tareas y se procede a ser más efectivos en la
distribución de nuestros servicios. Utilizamos un sistema de inventario, un sistema
de logística dentro de la operación, un manejo eficiente en cobros y pagos, un
método de respuesta inmediata a cada cliente. Toda gira a raíz de la atención de
la parte tecnológica de la institución, para lo que se cuenta con un Centro de
Datos el cual se resguarda la información y se tiene en constante atención, se
cuenta con un grupo capacitado para la realización y toma de requerimientos de
software, con la finalidad de poder mejorar cada proceso implementado en la
empresa, desde la toma de requerimientos hasta la funcionalidad del mismo en el
campo laboral. Por esta razón se ha realizado una auditoria de procesos de
desarrollo de software con el objetivo de detectar y mejorar falencias y dar
sugerencias de mejora dentro de la institución, por lo cual se han realizado análisis
de procesos, una serie de pruebas, entrevistas y checklist al personal de TI, con la
3
finalidad de comprender la manera en la que se opera dentro del departamento y

el rol de cada colaborador.
2. MARCO TEÓRICO
2.1. Administración
Para que la gestión determine y logre sus objetivos, se debe utilizar de

manera coordinada los recursos humanos, intelectuales, materiales, tecnológicos y
financieros disponibles. De esta manera, el trabajo gerencial implica el logro de
metas mediante la realización de un trabajo bajo la responsabilidad de otros.
La gestión se puede aplicar en instituciones formales e informales, las

instituciones formales son aquellas que se rigen por normas y leyes escritas para
que puedan funcionar como el estado de un país o empresa.
“La administración es el proceso que busca por medio de la planificación, la

organización, ejecución y el control de los recursos darles un uso más eficiente
para alcanzar los objetivos de una institución.
2.2. Amenaza
Tiene relación con un incidente nuevo o recién descubierto que tiene el

potencial de afectar un sistema o su compañía generalmente. Normalmente, en un
escenario hipotético, el atacante hace uso de la vulnerabilidad como puerta de
ingreso a un determinado sistema para tomar posesión de forma parcial o total del
activo empresarial. En el ámbito informático, las amenazas hacen referencia a
circunstancias o eventos de seguridad cibernética que pueden causar daños a una
organización objetivo. Las amenazas comunes son la ingeniería social, que en
otros casos es conocido como ataque de phishing que lleva a un atacante a
instalar un troyano o hurtar información de sus aplicaciones o sobrecargar el
centro de datos para denegar el servicio.
“son aquellas ocasiones en que piratas informáticos logran entrar en tus

computadoras, dispositivos y/o servidores con malas intenciones. Estos ataques,
4
dependiendo de cuál sea, pueden darse a través de e-mails engañosos, haciendo

clic en anuncios maliciosos, etc.” (Arroba System, 2021)
2.3. Auditoría
La tarea principal de una auditoría informática es evaluar los sistemas

informáticos de una organización en particular. En consecuencia, se debe producir
un informe de auditoría que muestre en qué medida operan con eficacia y brindan
la suficiente estabilidad a la información de la empresa u organización analizada,
teniendo en cuenta los objetivos definidos y la evaluación de los procesos
relevantes.
“La auditoría informática es una modalidad de auditoría que concierne a

la evaluación en profundidad de los recursos informáticos y tecnológicos de una
organización.” (economipedia, 2023)
2.4. Confiabilidad
Fiabilidad o Confiabilidad es, en un área particular del conocimiento, la

mayor o menor propensión al error en procesos definidos, especialmente los
relativos a la medición e investigación por medio de dispositivos o métodos. Al
contrario de otras características, la confiabilidad suele definirse por un tiempo de
evaluación: una ventana de tiempo en la que se evalúa la eficacia o precisión de
una herramienta ya sea una máquina, un sistema o un proceso, y en la que se
deben cumplir las funcionalidades requeridas.
“la confiabilidad puede entenderse como la posibilidad de confiar en algo,

entendida como una propiedad del objeto y no de quien confía.” (Concepto, 2023)
2.5. Confidencialidad
Los principios de confidencialidad y conservación están destinados a la

transmisión de datos independientemente de su forma, medio o finalidad.
Cualquier violación a estos principios, principalmente los relacionados con la
5
piratería electrónica, la transmisión ilegal de información de datos o la violación del

secreto profesional, será sancionada de conformidad con lo dispuesto en esta ley
y demás actos reglamentarios pertinentes.
Hace referencia a la privacidad de los datos pertenecientes a una entidad,

usuario o ente particular que forma parte del activo empresarial y que debe ser
protegido de usuarios no autorizados. Se considera un principio o norma de
seguridad que garantiza el nivel de secreto de la información.
“La confidencialidad, en informática, es un principio fundamental de la

seguridad de la información que garantiza el necesario nivel de secreto de la
información y de su tratamiento, para prevenir su divulgación no autorizada
cuando está almacenada o en tránsito.” (Santander, 2022)
2.6. Controles
En la teoría de la investigación económica y empresarial, el control

administrativo es considerado como una de las etapas que integran el proceso
laboral de las organizaciones. Con la ayuda de las funciones de control, varias
empresas buscan observar su gestión de tal manera, que puedan verificar el buen
funcionamiento de procesos en determinadas áreas, con el objetivo de identificar
posibles amenazas y realizar un plan de gestión para mitigar los riesgos.
“El control administrativo es la etapa de la gestión administrativa que se

refiere a la evaluación de procesos y del rendimiento administrativo, así como de
la identificación de desviaciones y posibles anomalías.” (economipedia, 2023)
2.7. Disponibilidad
Garantiza que los datos de la entidad estén a disposición de usuarios y

personal autorizados de forma inmediata las 24 horas del día, los 365 días del
año. Esto también aplica para los servicios en línea tales como es el caso de la
banca electrónica, que permite realizar transacciones fuera del horario de atención
en 4 agencias lo cual trae como beneficio que las personas por motivos de trabajo
6
o cualquier otro puedan realizar pagos desde la comodidad de sus hogares o en

horario de actividades cotidianas.
“Disponibilidad de la información implica la adopción de sistemas que

puedan garantizar el ingreso a las personas que cuenten con las credenciales
requeridas, así como a procesos, servicios y datos que la empresa posee en su
haber.” (DocuSign, 2022)
2.8. Gestión
Es un conjunto de proceso establecidos mediante un documento o conjunto

de documentos utilizado como referencia de diferentes entregables que se irán
realizando y actualizando durante un proyecto. Dicho plan no solo es utilizado para
gestionar proyectos, también tiene gran utilidad para gestionar riesgos y
amenazas que comprometan los activos de la organización en cuestión, es decir,
antes de enfrentar un incidente se debe contar con un procedimiento definido el
cual es aplicado con el objetivo de evitar un siniestro como puede ser la pérdida
de información de cientos de usuarios, daños materiales en las instalaciones
donde reside el mobiliario y otros activos de vital importancia para la organización.
“La Norma ISO 9000:2015 define al plan de gestión de la calidad como

aquel documento en el cual se establecen los procesos y recursos asignados,
se definen los responsables de su aplicación y el momento en el que se llevará
a cabo.” (PÚBLICA, 2020)
2.9. Gobernanza
El gobierno también se interpreta como un arte, que exige una relación

entre el líder y el pueblo. De esta forma, se busca generar un marco legal que
permita a la región lograr el cumplimiento en todos los espacios.
Otro aspecto clave que incluye la gobernanza es la sustentabilidad, ya que

busca sentar las bases para el desarrollo que se da en esa época.
7
“La gobernanza es un modo de dirigir un país o entidad buscando el

progreso económico, pero también el desarrollo social y el fortalecimiento de las
instituciones. Todo lo anterior, de forma sostenible en el tiempo.” (economipedia,
2023)
2.9. Impacto
Los costos derivados de pérdida de seguridad no son sólo costos

económicos directos, también afecta a la imagen y por ende el negocio, por lo que
cada vez más la seguridad de la información forma parte de los objetivos de las
organizaciones y, a pesar de la concienciación generalizada, muchas entidades no
lo toman en consideración.
Para evaluar el impacto de los ataques basados en la red y el "valor

preventivo", se determinan los ocurridos en el sistema informático:
a. Virus, troyanos, gusanos y otros tipos de programa maligno que pueden

poner fuera de servicio servidores y estaciones de trabajo o robar datos.
(Laboratorio).
b. Ataques distribuidos de denegación de servicio (DDoS) y flooding, que

pueden sobrecargar los servidores y poner páginas web fuera de servicio.
(Gerencia)
c. Desfiguración de sitios web. (Gerencia).
d. Reclamaciones internacionales, poniendo en riesgo la seguridad

nacional. (Repercusión internacional).
Los daños causados por los ataques, independientemente de la fuente, se

dividen en dos categorías principales: la filtración de datos y la pérdida de servicio.
Los ataques por denegación de servicio ponen como riesgo la

inoperatividad de los sistemas informáticos de redes extranjeras, generando
reclamaciones internacionales. El negocio se demora considerablemente por falta
8
de comunicación entre las partes y se encarece al utilizar medios ya obsoletos en

el mundo como la telefonía fija, correo postal, presencial etc. lo cual repercute
directamente en los ingresos y costos de forma negativa. Los procesos cotidianos
se interrumpieron y los empleados no pueden desempeñar sus tareas porque la
red está fuera de servicio. Poner en riesgo la información ya que se utilizan vías de
comunicación no autorizadas, por ejemplo, correos electrónicos no propiedad de la
entidad, páginas web alojadas en el exterior etc.
2.10. Información
Es un conjunto de datos interrelacionados con el objetivo de formar

oraciones, frases o argumentos de forma coherente para brindar explicación a un
determinado tema. También se le conoce así al conjunto de atributos que identifica
a un individuo, estos podrían ser: nombre, edad, dirección, entre otros.
“Como información denominamos al conjunto de datos, ya procesados y

ordenados para su comprensión, que aportan nuevos conocimientos a un
individuo o sistema sobre un asunto, materia, fenómeno o ente determinado.”
(Significados, 2023)
2.11. Informe
Es un proceso sistemático de revisión de las cuentas anuales de una

organización, con el objetivo de revisar si el informe refleja la verdadera imagen de
la organización. Existen varios factores a tener en cuenta para entender cómo
funcionan los informes de auditoría:
1. El auditor puede ser tanto una persona física

como jurídica. En este último caso, es una empresa dedicada
a la auditoría.
2. El auditor puede ser externo (si no forma parte

de la empresa) o interno (si forma parte de ella). Ambos tienen
9
la capacidad de elaborar informes de auditoría, pero los

informes realizados por los auditores externos son realmente
válidos.
3. El informe de auditoría expresa una crítica no

vinculante del auditor. Por tanto, este informe expresa la
percepción del auditor, es decir, ni siquiera es una verdad
absoluta y, por lo tanto, no es vinculante.
4. Versan sobre las cuentas anuales o estados

financieros. Los estados que se auditan son el balance, la
cuenta de resultados, el estado de cambios en el patrimonio
neto y el estado de flujos de efectivo.
“El informe de auditoría es un informe realizado por un auditor externo

donde expresa una opinión no vinculante sobre las cuentas anuales o estados
financieros que presenta una empresa.” (Economipedia, 2023)
2.12. Integridad
Esto hace referencia a la protección de la veracidad de la información

perteneciente a un usuario u organización en particular debido a que, al quedar
expuesta a un tercero, se corre el riesgo de que la información sea alterada con
fines particulares o políticos. Es por tal razón que debe brindarse importancia en
implementar mecanismos o políticas de seguridad que regulen este aspecto.
“La integridad de los datos o de la información garantiza la exactitud de los

datos transportados o almacenados, asegurando que no se ha producido su
alteración, pérdida o destrucción, ya sea de forma accidental o intencionada.”
(Santander, 2022)
10
2.13. Planificación de aseguramiento
Se considera el conjunto de medidas preventivas y reactivas de las

organizaciones y de los sistemas tecnológicos que permiten resguardar y proteger
la información buscando mantener la confidencialidad, la disponibilidad e
integridad de datos y de la misma.
“es un programa anual que determina el alcance de las actividades de

aseguramiento, las áreas de cobertura y la disponibilidad de recursos.”
(Diligent, 2023).
2.14. Políticas de seguridad
Son procesos establecidos por un grupo de personas encargados de velar

por la seguridad de la información a partir de amenazas detectadas mediante un
diagnóstico realizado por estos. Estas normas son creadas con el objetivo de
evitar que la información sea extraviada a causa de un fallo humano, un ataque
cibercriminal o cualquier evento que comprometa la integridad de los datos en
cuestión.
“Una política de seguridad se define a alto nivel, esto es, qué se debe
proteger y cómo, es decir, el conjunto de controles que se deben implementar.
Esta se desarrolla en una serie de procedimientos e instrucciones técnicas que
recogen las medidas técnicas y organizativas que se establecen para dar
cumplimiento a dicha política.” (Rioja, 2022)
2.15. Proceso de Auditoría
Son aquellas actividades o técnicas empleadas para llevar a cabo la

evaluación de auditoría y de esta forma determinar el nivel de eficiencia de las
organizaciones. Para lograrlo es necesario aplicar una metodología o modelo de
estudio que respalda el fundamento por el cual se hace uso de estos procesos.
11
Mediante la realización de un proceso de auditoría es posible para

empresas e instituciones la consecución de respuestas acerca de sus propias
características y aquellos puntos a mejorar en su actividad.
A través de una determinada metodología, un auditor indaga y verifica los

puntos clave atendiendo a la naturaleza de su trabajo. Es posible realizar
auditorías centradas en distintos aspectos como el contable o el de gestión, entre
otras. Todo proceso de este tipo, independientemente de dicha iniciativa debe
compartir una serie de etapas para considerar.
“El proceso de auditoría es un conjunto de técnicas y prácticas realizadas

de forma conjunta a la hora de evaluar y medir en profundidad las debilidades y
fortalezas de una empresa u organización.” (Economipedia, 2023)
2.16. Riesgo informático
Se define como la probabilidad de que un incidente suceda o no, en

particular un problema que se expone de forma no prevista. El concepto de riesgo
se ha forjado en el pensamiento occidental del capitalismo y la teoría económica,
haciendo a la economía una de las disciplinas pioneras en el cálculo del riesgo. El
peligro es por igual un criterio cualitativo que involucra un costo colectivo, por lo
cual no únicamente es dependiente del cálculo de posibilidad, sino además del
entorno social. Sin embargo, al igual que el concepto de riesgo, vulnerabilidad se
define como: capacidad respuesta daño de la sociedad ante un evento
potencialmente catastrófico, es decir, que surge como consecuencia de la
interacción de una serie de factores y características (internas y externas).
2.17. Seguridad
La ciberseguridad se caracteriza por ser un tipo de estabilidad intangible

que solemos asociar a programas antivirus o detectores de programa maligno,
entre otras cosas. Dicho de otra forma, se trata de un tipo de seguridad que se
12
encarga de prever y frenar amenazas de carácter digital, las cuales pueden afectar
al hardware o al software. En adición, la seguridad informática es muy conocida
por el término ciberseguridad.
“La seguridad informática es la seguridad que engloba la protección del

factor computacional en los dispositivos, normalmente electrónicos.”
(Economipedia, 2023)
2.18. Sistema
Ejemplos de hardware y software en un SI son los dispositivos periféricos,

el sistema operativo del dispositivo o las aplicaciones disponibles en él. La utilidad
de los sistemas informáticos los hace adaptables a casi cualquier sector o
actividad económica y se pueden utilizar sin restricciones. Esto es fundamental
para realizar cualquier tipo de actividad en las que se consideran la realización de
documentos, informes, entre otros. Así como también realizar transacciones
“Un sistema informático es aquel sistema que aúna por un lado la parte
física de la informática y por otra, la parte digital o no tangible de la informática.”
(Economipedia, 2023)
2.19. Vulnerabilidad
Es una debilidad existente en un sistema que puede ser utilizada por una
persona malintencionada para comprometer su seguridad. Las vulnerabilidades
pueden ser de varios tipos, pueden ser de tipo hardware, software,
procedimentales o humanas y pueden ser explotadas o utilizadas por intrusos o
atacantes.
Para entenderlo mejor, una vulnerabilidad puede ser:
a. Un servicio de un sistema de computación corriendo en un determinado

puerto lógico.
13
b. Sistemas y aplicaciones no actualizados o parcheados que presentan

múltiples vulnerabilidades.
c. Una red Wifi abierta.
d. Un puerto abierto en un firewall.
e. Un insuficiente o inexistente control de acceso físico a las instalaciones.
f. La no aplicación de una política de gestión de contraseñas.
Es el riesgo que una persona, sistema u objeto puede sufrir frente a

peligros inminentes, sean ellos desastres naturales, desigualdades económicas,
políticas, sociales o culturales. (Significados, 2023)
3. RECURSOS TECNOLOGICOS
A continuación, se identifican los siguientes recursos de tecnología que

actualmente están afectos a riesgos debido a algún fallo o desastre:
3.1. Data Center Principal
Este data center se encuentra ubicado en las instalaciones de la

bodega central de MOVILAND. Normalmente opera 7/6, de siete de la
mañana a 6 de la tarde (la hora de salida siempre se alarga).
Tabla No. 1 Listado de Activos Tecnológicos Data Center Principal
No Dispositivo
Servidor HPE Proliant DL20 - Gen10 – Servidor de aplicaciones,

1
ambiente de producción.
Servidor HPE Proliant DL20 - Gen10 – Servidor de base de datos

2
ambiente producción.
3 Servidor HPE Proliant DL20 - Gen10 – Planta Telefónica.
Servidor Dell PowerEdge T30 – Servidor de aplicaciones, ambiente de

4
desarrollo.
14
Servidor Dell PowerEdge T30 – Servidor de base de datos, ambiente de

5
desarrollo.
6 Cisco Meraki MX84 – Firewall.
7 Switch MikroTik Gigabit Ethernet Cloud Router.
8 Antena Ubiquiti powerbeam m5-400.
9 UPS para soporte eléctrico de servidores y equipo de cómputo.
10 DVR de Cámaras de video vigilancia central.
Componentes de Red:
a)Switches
b)Routers
c) Access Points
11 d)Tranceivers
e)Convertidores de Fibra Óptica (Monomodo y Multimodo)
f) Patchcords para Fibra Óptica (Monomodo y Multimodo)
g)Cableado UTP
h)Cableado de Fibra Óptica (Monomodo y Multimodo)
Fuente: elaboración grupo No. 3 MASI, Retalhuleu, 2023
3.2. Gabinete de comunicaciones Bodega de llantas
Este gabinete recibe comunicación por medio de cable UTP, desde el

centro de datos principal. Comunica a nivel de red a todos los nodos
conectados en bodega de llantas.
Los recursos tecnológicos afectos a riesgos son los siguientes:
Tabla No. 2 Listado de Activos Gabinete de Bodega

No Dispositivo
1 UPS para soporte eléctrico de servidores y equipo de cómputo.
2 DVR de cámaras de video vigilancia bodega de llantas.
15
Componentes de Red:
a)Switches
b)Router
c) Access Point
3 d)Patchcords para Fibra Óptica (Monomodo y
Multimodo)
e)Cableado UTP
4. METODOLOGÍA
4.1. Alcance
Se define que la profundidad de la auditoría tiene como objetivo evaluar el

ciclo de vida del desarrollo de software y todo lo que esto conlleve como lo son sus
fases, componentes, procesos y técnicas que la empresa distribuidora de
repuestos utiliza para el desarrollo de software; las metodologías empleadas para
el desarrollo es SCRUM. Los estándares que se utilizarán en la auditoría son
OWASP, ISO/IEC 15504 e ISO/IEC 33000.
a. Auditoría en fase de análisis – ISO/IEC 15504

b. Auditoría en la fase de diseño – ISO/IEC 15504
c. Auditoría en la fase de desarrollo – ISO 33000
i. Testing o verificación- OWASP
d. Auditoría en la fase de implementación – ISO 33000

e. Auditoría en la fase de mantenimiento – ISO 33000
4.2. Definición Del Proceso De Auditoría De Sistemas

La Auditoria tiene como primordial enfoque evaluar y calificar los procesos
que se realizan, en este caso aplicado al Desarrollo de Software, donde se
establecen requisitos para la evaluación de procesos y los modelos de evaluación
donde se comprenden:
16
a. Evaluar de procesos
b. Mejorar los procesos
c. Evaluar la capacidad y la madurez de los procesos
Realizar la exploración y planteamiento, en esta etapa se lleva a cabo un

estudio previo a la realización de la Auditoría de Software con el objetivo de
conocer detalladamente los rasgos de la empresa a auditar. Solo así se podrán
obtener las características para hacer un planteamiento del trabajo que se va a
desarrollar. Además, se deben conocer datos de la organización como su
estructura, flujo de producción o servicios que presta, así como otro tipo de
antecedentes.
4.3. Ciclo De Vida Del Desarrollo De Software
De acuerdo con las fases que lleva el Desarrollo de Software a continuación

se muestra de forma gráfica y los procesos a Auditar en cada una de las fases
para su mejor comprensión.
Gráfico No. 1 Ciclo de vida del Desarrollo de Software

a. Análisis: Evaluar los procesos para obtener información acerca de los

requerimientos del gerente en el software, es una de las fases muy
importantes del Desarrollo de Software, definir exactamente lo que se
requiera que el sistema realice, como también ante esta situación el
coste es menor del software que subsanarlo al final del proyecto y como
también la metodología de Desarrollo de Software a utilizar en el
proyecto. Verificar las herramientas que se utilizan para definir la
estimación de tiempo de los entregables del Desarrollo del Software.
b. Diseño: Evaluar los escenarios que se definieron en la etapa de Análisis
para la implementación del software que hay que construir, así como la
estructura general del mismo. El diseño es una etapa compleja y su
proceso debe realizarse de manera iterativa.
17
c. Desarrollo: Auditar y evaluar las herramientas adecuadas, en el entorno

de desarrollo del Software y el lenguaje de programación apropiado para
el tipo de sistema que se definió previamente. También hay que tener en
cuenta la adquisición de recursos necesarios para que el Desarrollo del
Software, como licenciamientos de los softwares a utilizar en el proceso,
cumplimiento de la metodología del Desarrollo del Software y control de
versiones del Software.
d. Implementación: Evaluar los entornos de despliegue del Software en
entornos de desarrollo y producción, ente fase es poner el software en
funcionamiento, por lo que hay que planificar el entorno teniendo en
cuenta las dependencias existentes entre los diferentes componentes de
este. Es posible que haya componentes que funcionen correctamente
por separado, pero que al combinarlos provoquen problemas. Por ello,
hay que usar combinaciones conocidas que no causen problemas de
compatibilidad.
e. Mantenimiento: Verificar el proceso que se realiza en las pruebas de
Desarrollo del Software tanto, pruebas unitarias y pruebas de
integración. Auditar cada proceso que se realiza y las herramientas que
se utilizan para realizarlos. En el mantenimiento del Software verificar
que se cumplan con respecto a la metodología del Desarrollo del
Software y si se utiliza otros procesos, para que el Software este
preparado ante cualquier evento tecnológico que perjudique la
información de los clientes del sistema.
4.4. Plan Integral De Auditoria De Sistemas
El plan de cronograma de actividades se describe a continuación, tomando

en cuenta las fases de Auditoria del Desarrollo de Software
18
Jan 31, 2023 Feb 7, 2023 Feb 14, 2023 Feb 21, 2023 Feb 28, 2023 Mar 7, 2023 Mar 14, 2023 Mar 21, 2023
Tabla No. 3
Cronograma de 7 8 9 10 11 14 15 16 17 18 28 1 2 3 4 6 14 15 16 17 21 22 23 24 25
Actividades 12 13 19 20 78 91 1 1 18 19 20 26 27
31 1 2 21 22 23 24 25 0 11 3
3 45 6 26 27 5 2
MT
# TASK PR STA M W F SS W SS W SS W SS W S S M T S M T
O R T M T M T M T M T S T F T F
GRE T END T F T F T F W TF W S W S
T T F
SS
A
u
di
to
ri
a
In
ic
ia
Tarea planificación de la 100 2/1/2 2/2/23

1 Auditoria del Desarrollo % 3
del Software
Tarea Elaborar checklist, cuestionarios 100 2/2/2 2/3/23

2 y entrevistas para la Auditoria % 3
Tarea Definir herramientas 100 2/4/2 2/5/23

3 para la Auditoria de % 3
Sistema
Tarea Información y 100 2/6/2 2/7/23

4 documentación % 3
requerida de la empresa
Auditoria de Análisis
Tarea Evaluación acerca de los 100 2/8/2 2/9/23

1 conocimientos de los % 3
involucrados
Tarea Evaluar a los actores y 100 2/10/ 2/11/

2 roles principales en el % 23 23
Desarrollo del Software
Tarea Información 100 2/12/ 2/13/

3 acerca de la % 23 23
empresa
(procesos,
organigrama
s, recursos
con lo que
cuenta)
Tarea Evaluar los 100 2/14/ 2/15/

4 requerimientos de % 23 23
procesos del Desarrollo
de Software
Tarea Definición del Alcance de la 100 2/16/ 2/17/

5 Auditira del Desarrollo de % 23 23
Software
Auditoria de Diseño
Tarea Evaluación de las 100 2/18/ 2/19/

1 metodologías de % 23 23
Desarrollo de Software
(Metodologia grafica)
Tarea Evaluar el tipo de 100 2/20/ 2/21/

2 Desarrollo del Software % 23 23
S
19
Tarea 3 Evaluar las buenas practicas del Desarrollo del Software 100% 3/5/23 3/6/23
Tarea 4 Evaluación y monitoreo de avances de la estimación 100% 3/6/23 3/7/23
de tiempo en el Desarrollo de Software
Tarea 5 Planteamiento de soluciones a las inconsistencias detectadas 100% 3/8/23 3/9/23
Tarea 6 Evaluación de pruebas unitarias del Software 100% 3/10/23 3/12/23
Tarea 7 Control de calidad del Software 100% 3/13/23 3/15/23
Auditoria de Implementación
Tarea 1 Evaluación de las pruebas integrales del Desarrollo del 100% 3/16/23 3/16/23
Software
Tarea 2 Inspección de los componentes del entorno de 100% 3/17/23 3/17/23

Producción
Tarea 3 Revisión del proceso en cambios en Producción 100% 3/17/23 3/18/23
Tarea 4 Verificación de los planes de contingencia en Producción 100% 3/18/23 3/19/23
Tarea 5 Revisión de la entrega final de los artefactos del 100% 3/19/23 3/20/23
Auditoria de Mantenimiento
Tarea 1 Plan de mantenimiento y seguimiento del Software 100% 3/21/23 3/22/23
Tarea 2 Verificar el ciclo de vida del Software 100% 3/23/23 3/24/23
Auditoría final
Tarea 1 Crear informe final en borrador 100% 3/24/23 3/25/23
Tarea 2 Elaborar informe de hallazgos y evidencias de la 100% 3/25/23 3/26/23

Auditoria
Tarea 3 Elaborar recomendaciones de la Auditoria 100% 3/26/23 3/26/23
Tarea 4 Presentar informe final de la Auditoria del Desarrollo de 100% 3/27/23 3/27/23
Software

23
4.5. Inventario de Activos
Al realizar un estudio sobre los componentes de la organización Moviland,

se hallaron los siguientes activos de información:
Tabla No. 4 Inventario de Activos

ID Nombre del Activo Descripción del Activo Tipo de activo Contenedor
AI1 Centro Principal de Centro Principal de Instalaciones Data Center

Procesamiento procesamiento donde reside la del proveedor
infraestructura que soporta la
operación del negocio
AI2 Centro Alterno de Centro Alterno de Instalaciones Data Center

Procesamiento procesamiento que contiene la del proveedor
infraestructura para la
continuidad del negocio
AI3 Cuartos de Instalación física donde Instalaciones Cuartos de

comunicaciones residen los racks de rack
comunicaciones
AI4 Área administración Instalación física donde están Instalaciones Área

de plataforma ubicados los administradores administración
de plataforma de plataforma
AI5 Red LAN Red LAN corporativa de la Redes de Red LAN

entidad comunicaciones
AI6 Red WAN Red WAN de la entidad Redes de RED WAN

comunicaciones
AI7 Red WIFI corporativa Red Wifi utilizada por los Redes de Red LAN
equipos móviles para acceder comunicaciones
a los recursos de la red
corporativa de la entidad
24
AI8 Red WIFI invitados Red Wifi para invitados Redes de Red LAN
comunicaciones
AI9 Servidores de Servidores que soportan los Equipos Data Center

administración servicios bases de informáticos del proveedor
administración
AI10 Servidores de bases Servidores de producción que Equipos Data Center

de datos de soportan los motores e informáticos del proveedor
producción instancias de bases de datos
AI11 Servidores de Servidores de producción que Equipos Data Center

aplicaciones de soportan las aplicaciones y informáticos del proveedor
producción sistemas de información
AI12 Plataforma de Servidores que soportan la Equipos Data Center

Correo plataforma y servicio de correo informáticos del proveedor
corporativo

Pruebas ambientes de prueba de la informáticos del proveedor
entidad

Desarrollo ambientes de desarrollo de la informáticos del proveedor
entidad
AI15 SAN Unidades de almacenamiento Equipos Data Center

donde reside la información de informáticos del proveedor
la entidad
AI16 Solución de Backup Solución de Backup para el Equipos Data Center

respaldo de información del informáticos del proveedor
negocio
25
AI17 Dispositivos de red Equipos y dispositivos de red Equipos Cuartos de

activos (switch, router) informáticos rack
AI18 Computadores Computadores que utilizan los Equipos Área

Administradores administradores de plataforma informáticos administración
de plataforma
AI19 Computadores de Computadores de escritorio Equipos Computadores

escritorio usuarios asignados a los colaboradores informáticos
de la entidad
AI20 Portátiles Computadores portátiles de la Equipos Portátiles

entidad informáticos
AI21 Teléfonos Móviles Teléfonos móviles para cada Equipos Portátiles

trabajador de la empresa. Informáticos
AI22 Impresoras Impresoras de la entidad Equipos Impresoras

ubicada en diferentes áreas informáticos
AI23 Equipos de Equipos informáticos Equipos Equipos de

seguridad perimetral destinados a proteger la informáticos seguridad
seguridad de la entidad perimetral
AI24 Sistema Monitoreo Aplicaciones utiliza para Software Servidores de

de servicios monitorear el rendimiento y administración
disponibilidad de los servicios
de TI
AI25 Sistema de Control Sistema para controlar el Software Servidores de

de Acceso acceso a las áreas de la administración
entidad
AI26 Herramienta de Herramienta utilizada para la Software Servidores de

Virtualización virtualización de servidores administración
26
AI27 Sistema Gestor Sistema de gestión y Software Servidores de

Base de Datos administración de las bases de bases de datos
datos de la entidad
AI28 Antivirus Software de administración de Software Servidores de

seguridad para el control de administración
virus
AI29 Sistema Sistema para administrar la Software Servidores de

administración de la SAN administración
SAN
AI30 Sistema de control Sistema de administración Software Servidores de

de versiones para el control de administración
versionamiento de software
AI31 ERP Sistema integrado de gestión Software Servidores de

de la entidad aplicaciones
AI32 Aplicativos CORE Corresponde a los aplicativos Software Servidores de

del negocio que soportan el CORE del aplicaciones
negocio
AI33 Aplicativo de nomina Aplicativo para la gestión de Software Servidores de

recursos humanos aplicaciones
AI34 Sistema de Gestión Sistema de Gestión Software Servidores de

Documental documental de la entidad aplicaciones
AI35 Sistema de Gestión Aplicativo para el Sistema de Software Servidores de

de Calidad Gestión de Calidad aplicaciones
AI36 Aplicativo WEB Aplicativo web para la consulta Software Servidores de

transaccional y pago de las obligaciones de aplicaciones
cartera de los exempleados
27
AI37 Página WEB Página Web de la Entidad Software Servidores de

aplicaciones
AI38 Intranet Página Web de la Entidad Software Servidores de

aplicaciones
AI39 Aplicativos Página Web de la Entidad Software Servidores de

seguimiento aplicaciones
proyectos
AI40 CRM Aplicativo para la gestión Software Servidores de

relación con clientes aplicaciones
AI41 Terminales Aplicativo para el pago de las Software Otros bancos

empresariales obligaciones con terceros
AI42 Directorio activo Servicio establecido donde Servicios Servidores de

están los objetos tales como administración
usuarios, equipos o grupos,
con el objetivo de administrar
los inicios de sesión en los
equipos conectados a la red
AI43 Correo Electrónico Correo electrónico corporativo Servicios Plataforma de

de la entidad Correo
AI44 Bases de datos Bases de datos que Servicios Servidores de

almacenan la información bases de datos
de la entidad
AI45 Servidor de Almacenamiento de los Servicios Servidores de

documentos electrónicos que administración
Archivos
manejan las áreas de la
entidad
28
AI46 Video Conferencia Corresponde al servicio de Servicios Servidores de

videoconferencia de la entidad administración
AI47 Gestión de privilegios Corresponde al mecanismo Servicios Directorio

para la administración y activo
asignación de privilegios de
acceso a los recursos
tecnológicos y aplicaciones.
AI48 Identidad del Información que identifica a un Datos / Directorio

Usuario funcionario (nombre, cedula, Información activo
datos biométricos como la
huella, código del usuario, etc.)
AI49 Datos de Usuario y Contraseña que Datos / Directorio

autenticación utiliza los usuarios para activo
Información
ingresar a los recursos
tecnológicos y aplicaciones.
AI50 Usuarios genéricos Usuarios genéricos que utilizan Datos / Bases de datos
las aplicaciones para Información
conectarse a las bases de
datos
AI51 Log de evento de Log que contiene los registros Datos / Log de eventos
seguridad de los eventos de seguridad y Información
de los eventos de
administración sobre las
aplicaciones
AI52 Registro de Registro de incidentes de Datos / Bases de datos

incidentes de seguridad reportados por la Información
seguridad herramienta de mesa de ayuda
29
AI53 Manuales técnicos Corresponde a los Datos / File Server

de administración documentos, manuales y Información
procedimientos relacionadas
con la administración de la
plataforma
AI54 Bitácora de control Registro de acceso al centro de Datos / Carpetas

de acceso al centro computo Información
de computo
AI55 Documentos del Corresponde a los documentos Datos / Bases de datos

proceso del proceso que están Información
publicados en el sistema de
gestión de calidad
4.5.1. Criticidad de Activos

Con base al inventario de activos, se establece la valoración de criticidad
para determinar el nivel de importancia de estos y tomarlos en consideración para
la toma de decisiones en el caso de que ocurra un incidente.
Tabla No. 5 Valoración de Criticidad de Activos

ID Confidencialidad Integridad Disponibilidad Valor Nivel de
Total Criticidad
AI1 5 5 5 5.00 Alto
AI2 5 5 5 5.00 Alto
AI3 3 3 3 3.00 Medio
AI4 3 3 2 2.67 Medio
AI5 2 2 2 2.00 Bajo
AI6 3 3 3 3.00 Medio

30
AI7 4 3 5 4.00 Alto
AI8 4 3 5 4.00 Alto
AI9 4 4 3 3.67 Medio
AI10 5 5 5 5.00 Alto
AI11 5 5 4 4.67 Alto
AI12 4 4 4 4.00 Alto
AI13 4 4 3 3.67 Alto
AI14 4 4 4 4.00 Alto
AI15 5 5 5 5.00 Alto
AI16 4 5 5 4.67 Alto
AI17 4 5 5 4.67 Alto
AI18 5 5 5 5.00 Alto
AI19 5 5 5 5.00 Alto
AI20 5 5 5 5.00 Alto
AI21 4 5 5 4.67 Alto
AI22 3 3 4 3.33 Alto
AI23 4 4 4 4.00 Alto
AI24 3 4 5 4.00 Alto
AI25 5 5 5 5.00 Alto
AI26 5 5 5 5.00 Alto
AI27 5 5 5 5.00 Alto
AI28 5 5 5 5.00 Alto
AI29 5 5 5 5.00 Alto

31
AI30 5 5 4 4.67 Alto
AI31 5 5 5 5.00 Alto
AI32 4 5 4 4.33 Alto
AI33 5 5 4 4.67 Alto
AI34 5 5 5 5.00 Alto
AI35 5 5 5 5.00 Alto
AI36 5 5 4 4.67 Alto
AI37 5 5 5 5.00 Alto
AI38 5 5 5 5.00 Alto
AI39 5 5 5 5.00 Alto
AI40 5 5 5 5.00 Alto
AI41 5 5 5 5.00 Alto
AI42 5 5 5 5.00 Alto
AI43 5 5 4 4.67 Alto
AI44 5 5 5 5.00 Alto
AI45 5 5 5 5.00 Alto
AI46 5 5 4 4.67 Alto
AI47 4 5 4 4.33 Alto
AI48 5 5 4 4.67 Alto
AI49 5 5 4 4.67 Alto
AI50 5 5 5 5.00 Alto
AI51 5 5 5 5.00 Alto
AI52 5 5 5 5.00 Alto

32
AI53 3 5 5 4.33 Alto
AI54 5 5 5 5.00 Alto
AI55 4 4 4 4.00 Alto

4.5.2. Criterio de Evaluación de Activos
Tabla No. 6 Criterio de Evaluación

Criterio de Evaluación Valor criticidad Nivel
activo criticidad
La gestión del activo compromete en un alto grado la

integridad y/o confidencialidad y/o disponibilidad de la >3 a 5 Alto
información de la empresa.
La gestión del activo compromete en un nivel medio la >2a3 Medio

integridad y/o confidencialidad y/o disponibilidad de la
información.
La gestión del activo compromete en un nivel bajo la 1 a2 Bajo

integridad y/o confidencialidad y/o disponibilidad de la
información de la empresa.
4.6. Análisis y Evaluación De Riesgos

En esta sección se toma en consideración cada uno de los aspectos que
concierne para la identificación de amenazas y vulnerabilidades para establecer
un plan de gestión para mitigar los riesgos con el objetivo de reducir la
probabilidad de ocurrencia de incidentes. Al finalizar el proceso de análisis de
riesgos, se obtienen los siguientes resultados.
4.6.1. Identificación de amenazas
Se muestra en la siguiente tabla las amenazas halladas dentro de la

organización Moviland en las que se detalla mediante un identificador y la
descripción de estas, así como también se muestra la probabilidad de ocurrencia y
el impacto que puede tener en la organización si no se brinda la importancia
33
correspondiente. Cabe destacar que la ponderación es con base a estimación por

parte del grupo de trabajo de MASI, 2023.
Tabla No. 7 Identificación de Amenazas

Amenazas Probabilidad Impacto Riesgo
A1 Falta de inducción, capacitación y sensibilización 0.4 0.9 0.36

de riesgos
A2 Mal uso de sistemas y herramientas 0.3 0.9 0.27
A3 Utilización de programas no autorizados / software 0.3 0.9 0.27
pirata
A4 Falta de pruebas de software nuevo 0.5 0.9 0.45
A5 Pérdida de datos 0.5 0.9 0.45
A6 Infección de sistemas a través de unidades 0.4 0.9 0.36
portables sin escaneo
A7 Manejo inadecuado de datos críticos (Ej. No cifrar 0.6 0.9 0.54
datos, etc.)
A8 Unidades portables con información sin cifrado 0.7 0.8 0.56
A9 Transmisión no cifrada de datos críticos 0.6 0.6 0.36
A10 Manejo inadecuado de contraseñas (inseguras, 0.8 0.9 0.72
no cambiar, compartidas, BD centralizado)
A11 Compartir contraseñas o permisos a terceros no 0.4 0.9 0.36
autorizados
A12 Trasmisión de contraseñas por teléfono 0.2 0.7 0.14
A13 Exposición o extravío de equipos, unidades de 0.4 0.9 0.36
almacenamiento, etc.
A14 Sobrepasar autoridades 0.4 0.8 0.32
A15 Falta de definición de perfil, privilegios y 0.5 0.8 0.4
restricciones del personal
A16 Falta de mantenimiento físico (proceso, repuestos 0.5 0.9 0.45
e insumos)
A17 Falta de actualización de software (proceso y 0.5 0.8 0.4
recurso)
A18 Fallas en permisos de usuarios (acceso a 0.4 0.9 0.36
archivos)
A19 Acceso electrónico no autorizado a sistemas 0.4 0.9 0.36
externos
A20 Acceso electrónico no autorizado a sistemas 0.4 0.9 0.36
internos
A21 Red cableada expuesta para el acceso no 0.3 0.9 0.27
autorizado
A22 Red inalámbrica expuesta al acceso no autorizado 0.3 0.9 0.27
A23 Dependencia a servicio técnico externo 0.8 0.9 0.72

34
4.6.2. Descripción de Amenazas
A1 Falta de capacitación y sensibilización de riesgos. Para A1 se

identifica la falta de inducción o capacitación acerca de los riesgos, esto trae como
consecuencia que algunos elementos del personal puedan proporcionar
información acerca de la organización o de usuarios, sin que ellos sepan que
están siendo víctimas de ingeniería social.
A2 Uso incorrecto de sistemas. Para esta amenaza se estima un

porcentaje bajo de probabilidad debido a que la mayoría de las organizaciones
cuentan con un plan de capacitación para el personal con respecto al
funcionamiento de sus sistemas. No obstante, un importante porcentaje de
empresas no cuentan con plan de capacitaciones debido a que le restan
importancia o consideran que no es necesario capacitar al personal porque su
sistema es relativamente fácil de entender y manipular. Esto da como paso a la
exposición de pérdida de información al no manipular de forma coherente una
base de datos, tomando como ejemplo para este caso, por lo que se considera
que tendrá un alto impacto en la organización.
A3 Uso de programas no autorizados. Para esta parte se considera un

bajo porcentaje de probabilidad de ocurrencia debido a que una importante
cantidad de organizaciones cuentan con las licencias respectivas el cual respalda
la garantía de usabilidad de sus sistemas, lo que significa que los datos
contenidos en él están resguardados de forma segura y legal. Sin embargo, aún
existen entidades que hacen caso omiso a este aspecto y no consideran la
magnitud del impacto al perder información de forma parcial o permanente al no
utilizar sistemas con licencia.
A4 Insuficiencia de pruebas de software nuevo. Se considera un

importante porcentaje de probabilidad de ocurrencia para este tipo de amenaza
debido a varios factores, una de ellas es que las organizaciones no cuentan con el
tiempo suficiente para llevar a cabo las pruebas de software nuevo previo a ser
implementado en producción. Esto trae como consecuencia posibles fallas en
35
transacciones o cualquier otro tipo el cual sea de impedimento para la continuidad

del negocio.
A5 Pérdida o extravío de datos. La pérdida de datos es algo que ha

afectado en gran medida a la mayoría de las organizaciones a nivel global en los
últimos años, debido a que en muchas de estas empresas no cuentan con
políticas de seguridad y planes de gestión para la identificación de vulnerabilidad
el cual les permita determinar las áreas de mayor riesgo. Esto ha dado paso a los
cibercriminales para aplicar métodos y técnicas para tomar posesión de
información de miles de usuarios, por lo que se debe brindar prioridad a este caso.
A6 Infección de sistemas mediante unidades portables sin escaneo.

Esta amenaza en algunas ocasiones pasa por desapercibido debido a que
subestiman el daño que este puede ocasionar. Entre los daños que causa los tipos
de virus están desde ocultar los archivos del ordenador hasta eliminarlos de forma
permanente, independientemente de la magnitud del daño ocasionado, es
importante considerar los escenarios de este tipo para realizar un plan de gestión
para reducir la probabilidad de ocurrencia e impacto en la organización. Aunque
parezca un riesgo de baja categoría, se considera que el impacto que puede tener
en la organización es alto, por lo que no se descarta la materialización de un
evento de este tipo.
A7 Uso inadecuado de datos críticos. Todas las organizaciones tienen

bajo posesión información sensible acerca de la entidad y de los usuarios que
forman parte de esta, así como también posee información del personal y de
entidades asociadas, por lo que queda expuesto ante los cibercriminales que
están a la orden del día para hurtar o alterar esta información. No obstante, al
principio se consideraba que no era necesario hacer uso de un mecanismo de
seguridad que protegiera la integrad de la información debido a que los casos de
hurto o alteración de datos era un tema que no tenía un gran impacto. En la
actualidad, las organizaciones peligran por el hecho que, la información que tienen
bajo posesión es sensible, haciendo referencia a cuentas de bancos de clientes y
36
corporaciones. Es por esta razón que se necesita un plan de seguridad que

permita proteger la integridad de estos datos.
A8 Unidades portables con información sin un tipo de cifrado. Esta

amenaza, similar a la anterior posee un grado mayor de riesgo debido a que la
información sensible es transportada mediante una unidad de almacenamiento
que está expuesto a extravíos o hurto por parte de terceros. Al no poseer un
mecanismo de cifrado, la probabilidad de ocurrencia para el acceso a terceros
aumenta de forma significativa, lo cual es alarmante para cualquier organización.
A9 Transmisión no cifrada de datos críticos. Esta amenaza según su

mapa de calor se cataloga como una amenaza critica o de alto riesgo ya que
existe gran cantidad de información confidencial que sirve para gestionar y
almacenar ya que es un activo importante para la empresa, y al momento de no
contar con un cifrado o encriptación se encuentra expuesta para los
ciberdelincuentes y por ello es de alto riesgo.
A10 Manejo inadecuado de contraseñas. Se considera una de las

amenazas que ha causado gran daño a las organizaciones, debido a la
paupérrima seguridad de las contraseñas para el personal que hace uso de los
sistemas. Por otra parte, para los cibercriminales ha sido una puerta de acceso sin
límite en algunas ocasiones debido a que, las contraseñas son comunes, lo que
hace que sea predecible para cualquier persona. En otras ocasiones se hace uso
de ingeniería social para obtener datos sin dejar sospecha alguna, por lo que es
importante implementar una política de seguridad en la que se establezca un
formato para las contraseñas, así como para capacitar al personal para mostrar
las formas en que los cibercriminales pueden obtener información sin dejar rastro.
A11 Compartir contraseñas o privilegios a terceros no autorizados.

Esta amenaza si bien es cierto que la probabilidad es relativamente baja, el
impacto negativo sigue siendo alto y no se descarta la posibilidad de sufrir un
incidente por negligencia del personal al brindar acceso a usuarios que no forman
parte de la organización para suplir el puesto por algunas horas o por temas de
37
fuerza mayor. Aunque sea alguien de confianza, no es recomendable realizar este

tipo de acciones por seguridad tanto de la información de clientes como
información sensible de la organización para la que se labora.
A12 Trasmisión de contraseñas por teléfono. Para esta amenaza si bien

es cierto que la probabilidad de ocurrencia en menor en comparación a las otras
amenazas identificadas, la posibilidad de materializarse sigue latente, a tal punto
en que varios usuarios han sido víctimas de estafas debido que los cibercriminales
haciendo uso de herramientas para tomar información sensible se hacen pasan
por encargados de marcas reconocidas indicando que han sido seleccionados
para un sorteo en el que el premio es una casa o cualquier otro bien, con el
objetivo de adquirir información confidencial, háblese de dirección de domicilio,
cuentas de banco, No de identificación, entre otros. Es por tal razón que debe
considerarse un plan de gestión para advertir a los usuarios sobre estos peligros y
reducir la tasa de víctimas de estafa.
A13 Extravío de equipos, unidades de almacenamiento, entre otros.

Algunas organizaciones proporcionan dispositivos para la realización de
actividades que compete al trabajo, por lo que estos quedan bajo responsabilidad
del personal correspondiente. Sin embargo, se han presentado casos en los que
varios de estos dispositivos han sido extraviados mediante robo o pérdida por
negligencia de parte del personal, perdiendo de esta forma información
relacionada al trabajo y de cientos de usuarios que forman parte del sistema. Si
bien es cierto que la probabilidad es relativamente baja, el impacto es alto debido
a la información contenida en los dispositivos. Algunas corporaciones han tomado
cartas en el asunto y han decidido contratar los servicios de la nube para tener
respaldo de su información en caso de extraviar el dispositivo. No obstante, varios
de estos dispositivos no cuentan con mecanismos de seguridad de acceso, por lo
que un tercero puede ingresar de forma fácil.
A14 Sobrepasar autoridades. Esta amenaza representa peligro para la

organización debido a que, al tener un conflicto entre personal y encargado, puede
38
llegar al extremo de despedir a parte del personal por un inconveniente de

cualquier índole. En algunos casos, el personal despedido cuenta con acceso a
información de la entidad por lo que existe la probabilidad de realizar cambios en
algunos procesos o tomar posesión de información para proporcionarla al
competidor. Independientemente de las acciones que se realicen, estas son
llevadas a cabo con el objetivo de perjudicar a la organización, por lo que se
requiere conveniente desvincular el acceso a información para el personal
despedido.
A15 Falta de definición de perfil del personal. Esta amenaza se

caracteriza por reclutar personal que son asignados a puestos en los que no
cuentan con la experiencia suficiente para desempeñar el trabajo correspondiente,
teniendo como consecuencia fallas en algunos procesos donde el personal no
cuenta con pericia para solventar estos inconvenientes. Además, algunos puestos
de trabajo no poseen jerarquía para el acceso a información, para ejemplo de este
caso ponemos en comparación el acceso a información por parte de un usuario de
tipo administrador con un usuario de tipo cliente. Si bien es cierto que ambos son
usuarios que tienen acceso al sistema de información, pero cada uno cumple un
rol en el que no comparten los mismos permisos, situación que algunas entidades
pasan por alto.
A16 Falta de mantenimiento físico. Es importante que las organizaciones

desarrollen un plan de gestión para establecer fechas de mantenimiento y servicio
al hardware que es utilizado para llevar a cabo la prestación de sus servicios. No
obstante, algunas entidades restan importancia a este caso por temas de costo de
mantenimiento y consideran que los equipos deben duran tiempo indefinido para
laborar, cuando la realidad es otra. Con el paso del tiempo los dispositivos
acumulan suciedad, aunque a simple vista no sea notorio, pero, internamente los
componentes necesitan revisión y limpieza para garantizar el buen desempeño.
A17 Falta de actualización de software. Esta amenaza hace referencia,

que, con el pasar del tiempo los programas se vuelven obsoletos y con ello van
quedando sin soporte y esto provoca decaída de software, es decir, un deterioro
39
de forma lenta con un desempeño de baja calidad con el paso del tiempo mostrará
una decreciente capacidad de respuesta y se volverá de forma eventual
defectuoso, inusable, inseguro y obsoleto. Por lo que es necesario actualizar
(mantenimiento) debido que, esto proporciona una mejor calidad en el software y
sus recursos.
A18 Fallas en permisos de usuarios (acceso a archivos). Esta amenaza

representa relativamente baja probabilidad de ocurrencia, debido a que, el intento
de tener acceso por medio del usuario a sus archivos o al software no siempre
produce una falla, por lo que se pondera en un riesgo medio, ya que, estas fallas
surgen por credenciales vencidas, error inesperado del sistema, ingreso de forma
errónea al teclear la contraseña, entre otros factores.
A19 Acceso electrónico no autorizado a sistemas externos. Dentro de

esta amenaza se considera el ataque de spoofing y sniffing, es decir, el robo o
usurpación de identidad, esto surge cuando un tercero obtiene datos biométricos o
cualquier otro medio de autenticación del usuario víctima para acceder a sus
sistemas. Relativamente la probabilidad de ocurrencia es baja, no obstante, el
impacto que este puede tener en la organización es alta, debido a que el
cibercriminal obtiene acceso a la información.
A20 Acceso electrónico no autorizado a sistemas internos. Para esta

amenaza se considera la situación en que un usuario de alto rango brinde acceso
a un usuario de menor rango (usuario admón. y usuario invitado) para llevar a
cabo una tarea o por alguna falla del usuario invitado, esto implica que el usuario
invitado siga haciendo uso de las credenciales de acceso del usuario admón. Y
este produzca un error de inicio de sesión y el sistema bloquee a dicho usuario,
poniendo en riesgo la información contenida en él.
A21 Red cableada expuesta para el acceso no autorizado. Con base a

la gráfica, se determina un nivel medio de riesgo para esta amenaza, tomando en
consideración el siguiente caso: se diseña la estructura de red con capacidad de
50 ordenadores, de los cuales solo se utilizan 45, dejando expuestos 5 puertos.
40
Según la estructura de la red, al momento de la implementación de los servicios,

quedaron expuestos cables UTP (cables trenzados) lo cual implica un riesgo a
nivel físico, debido a que, estos cables pueden sufrir deterioro de forma parcial o
total. Además, un tercero puede conectarse haciendo uso de cualquiera de los
puestos a disposición, teniendo acceso a la red de la organización.
A22 Red inalámbrica expuesta al acceso no autorizado. El WIFI sin un

método de seguridad para el acceso a la red es un tema sensible, debido a que
cualquier usuario puede ingresar de forma sencilla. Esto trae como consecuencia
la exposición de información confidencial, lo cual es de beneficio para los
cibercriminales que pueden tomar posesión de dicha información para obtener un
tipo de remuneración económica. A diferencia de las organizaciones que
proporcionan WIFI de forma gratuita para navegar.
A23 Dependencia a servicio técnico externo. Para ejemplo de esta

amenaza se encuentra la dependencia de un ISP (Proveedor de Servicios de
Internet) del cual se contrata un servicio fundamental para el desempeño de la
organización. Esto trae como consecuencia depender de la estabilidad y calidad
del servicio adquirido, esto se ve reflejado en su afluencia o tráfico de red. Por lo
que se considera una amenaza de alta probabilidad de ocurrencia con un gran
impacto en la organización.
4.6.3. Matriz De Riesgo
Gráfico No. 2 Matriz para A1

41
Cabe considerar el hecho que la probabilidad y el impacto están

expresados en porcentaje (%) para así calcular el riesgo. También se toma en
consideración que la probabilidad de ocurrencia es de un 40 % tomando como
fundamento que en los últimos 10 años se han venido desarrollando mecanismos
de seguridad en los que se ha tratado de capacitar al personal con la finalidad de
advertir acerca de las distintas formas que los cibercriminales usan para obtener
información confidencial. Por lo que, al brindar información sensible, tiene un
impacto en las organizaciones de un 90 % debido a que los cibercriminales al
tener posesión de estos activos pueden exigir un tipo de remuneración o en
algunos casos la información es extraviada de forma permanente.

Con base a la gráfica se considera una amenaza de Riesgo medio debido a
la estimación ponderada, por lo que es importante considerar la implementación
42
de un plan que pueda gestionar dicha amenaza con el objetivo de disminuir el

nivel de riesgo.
Con base al gráfico, se determina que la amenaza se categoriza de riesgo

medio debido a la ponderación de probabilidad e impacto. No obstante, es
importante diseñar un plan de gestión para sistemas futuros con licencia en el
caso que la organización así lo requiera.

La gráfica cataloga esta amenaza de alto riesgo con base a la ponderación
de probabilidad e impacto, por lo que se requiere el diseño e implementación de
un plan que pueda brindar solución a esta problemática de tal manera que permita
43
laborar a las organizaciones y que garantice la disponibilidad de información y

servicios para con sus clientes.
La gráfica muestra el alto riesgo con base a la probabilidad de ocurrencia e

impacto ponderados. Para reducir la tasa de impacto y probabilidad es necesario
implementar políticas de seguridad en las que se deba capacitar al personal y
advertirles sobre el peligro latente en sus sistemas.

Con base a la ponderación, se determina que esta amenaza se encuentra
en categoría de Riesgo a nivel medio. No obstante, este tiende a convertirse en un
riesgo de magnitud alta debido al impacto que puede tener en la organización en
el caso de que se materialice.
44
Con base al gráfico, se determina que esta amenaza es de alto riesgo

debido a la sensibilidad de la información, por lo que se requiere implementar un
plan de gestión de seguridad para proteger la integridad de los datos, así como
también se requiere disminuir la probabilidad de ocurrencia de este tipo de
incidentes.

Con base a la ponderación de probabilidad de ocurrencia, se determina que
la amenaza se ubica en alto riesgo, debido a la confidencialidad de la información
dentro de la unidad de almacenamiento físico portátil. Para reducir la probabilidad
de ocurrencia, es necesario desarrollar un mecanismo de encriptación para
proteger la integridad de información, así como también para bloquear el acceso a
terceros en caso de perder la unidad de almacenamiento portátil.
45
Se recomienda cifrar toda información que la empresa considere relevante

o de suprema importancia ya que esto permite una transmisión de información
más segura y confiable al momento de manipular o tener almacenado dicho activo.
Es imperativo fomentar el cifrado de la información e ir de la mano junto a los
avances tecnológicos y evitar que la seguridad se vuelva obsoleta.

Con base a la gráfica se determina que la amenaza se cataloga de alto
riesgo debido a la alta probabilidad de ocurrencia e impacto en la organización en
el caso de que se materialice un evento de este tipo.

46
Si bien es cierto que la probabilidad es media, se recomienda implementar

una serie de normas para regular este tipo de acciones y evitar incidentes en el
futuro por bien de la organización y del personal.
Aunque el gráfico indique que es una amenaza de bajo riesgo, no debe

pasar por desapercibido debido que los cibercriminales aprovechan la falta de
conocimiento de algunos usuarios para hurtar información y obtener beneficios
particulares.
47
Gráfico No.
14 Matriz para A13
El gráfico refleja que la amenaza es de nivel medio, por lo que se debe

tener en consideración el diseño de políticas para el correcto uso dispositivos
corporativos.
Con base a la ponderación, se determina que es una amenaza de medio

riesgo, por lo que es necesario realizar un plan de seguridad en el que se
establezca la desvinculación de aquellos usuarios que no forman parte de la
organización para evitar incidentes de este tipo.
16 Matriz para A15

48
Gráfico No.
La gráfica representa la amenaza en categoría de riesgo medio por lo que

no debe pasar por desapercibido esta situación.
Con base a la gráfica, se determina que esta amenaza es de alto riesgo si

no se desarrolla un plan de mantenimiento para el hardware de la organización. 18
Matriz para A17
49
Gráfico No.
La gráfica representa un nivel medio de riesgo para esta amenaza, por lo

que es necesario diseñar un plan de mantenimiento (actualización) para el
software y sus recursos con el objetivo de garantizar la disponibilidad y seguridad
de información de la organización y sus usuarios.
Para evitar este tipo de incidentes es recomendable verificar el formato de

credenciales de acceso y verificar la fecha de vencimiento de las credenciales. 20
Matriz para A19
50
Gráfico No.
Según el análisis, se considera una amenaza de riesgo medio, por lo que es

necesario realizar políticas de seguridad con el objetivo de concientizar al personal
sobre este tipo de ataques y evaluar otras formas de autenticación, esto para
reducir la tasa de probabilidad de ocurrencia.
La matriz define esta amenaza de nivel de riesgo medio, quedando

expuesto a convertirse en alto riesgo. Para reducir la tasa de probabilidad de
ocurrencia, es necesario determinar políticas de seguridad que regulen este tipo
de procesos que pone en riesgo la integridad de la información, así como también
la seguridad digital de los usuarios.
51
Gráfico No.
22 Matriz para A21
Para reducir la probabilidad de ocurrencia es necesario realizar un estudio

de forma exhaustiva, de tal manera que la estructura de red se acople a la
cantidad de ordenadores solicitados. En el caso de que haya un puerto libre, este
deberá ser reportado para deshabilitarlo de forma inmediata.
Para reducir la probabilidad de ocurrencia, es necesario asegurar los

puertos de conexión mediante un firewall que controle el tráfico en la red,
permitiendo detectar y bloquear el ingreso a intrusos maliciosos.
24 Matriz para A23

52
Gráfico No.
Al ser una amenaza de alto riesgo, es necesario considerar la contratación

de un segundo ISP para tener un respaldo y balance de carga en sus
transacciones en el caso de que alguno de los ISP pueda presentar fallas en sus
servicios. Cabe resaltar el hecho que, los servicios contratados deben ser
corporativos, debido a que el tráfico de red es simétrico, en comparación a un
servicio residencial que es asimétrico.
3.6.4. Definición Del Plan De Tratamiento

Para disminuir la probabilidad de ocurrencia de las amenazas antes
identificadas, se consideran las siguientes medidas de seguridad:
Tabla No. 8 Medidas de Seguridad

No Amenaza Tratamiento
Desarrollar un plan de capacitación para que una vez al mes, el

T1 A1 personal se reúna para la adquisición de conocimiento sobre los
riesgos latentes de robo de información.
Desarrollar un plan de capacitación para que una vez al mes, el
T2 A2 personal se reúna para la adquisición de conocimiento sobre el uso los
sistemas.
T3 A3 Desarrollar una política en la que se establezca el uso exclusivo de
programas autorizados para el desempeño laboral.
53
Desarrollar un documento en el que se establezca los tiempos y

T4 A4 parámetros de prueba correspondiente para evaluar la funcionalidad del
software.
Desarrollar políticas de seguridad enfocados a la protección de

T5 A5 información de usuarios de personal y usuarios cliente. Estos pueden
considerar un formato para contraseñas, ingeniería social, entre otros.
Implementar una política enfocada al análisis de dispositivos de

T6 A6 almacenamiento portátil previo al acceso de información contenida en
esta.
Implementar un mecanismo de seguridad enfocado a cifrado
T7 A7 (Encriptación) con el objetivo de garantizar la integridad de la
información tanto de usuarios cliente como de usuarios de personal y
de la organización.
T8 A8 (Encriptación) para dispositivos de almacenamiento portátil con la
finalidad de garantizar la integridad de la información de usuarios
cliente, usuarios de personal y de la organización.
T9 A9 (Encriptación) para que durante la transmisión los datos no puedan ser
descifrados por terceros no autorizados.
Desarrollar una política de seguridad enfocado a contraseña en el que

T10 A10 se establezca un formato. Establecer normas para el uso de
contraseñas.
Desarrollar una política de seguridad en la que se prohíba compartir las
T11 A11 credenciales de acceso entre compañeros de trabajo y terceros no
autorizados, a excepción en casos especiales.
Implementar un plan de concientización en el que se determine que,

T12 A12 queda prohibido compartir información acerca de credenciales de
acceso.
Determinar normas o procedimientos de seguridad que resguarde el

T13 A13 hardware de accidentes.
Desarrollar un plan de seguridad para establecer la desvinculación de

T14 A14 aquellos usuarios que no forman parte de la organización para evitar
incidentes.
Definir mediante un documento cada una de las características

T15 A15 requeridas previo al reclutamiento de personal, esto para evitar
confusiones al momento de desempeñar el puesto de trabajo.
54
Desarrollar un cronograma de mantenimiento preventivo para los

T16 A16 dispositivos de hardware de forma semestral para garantizar la
funcionalidad de estos activos.
Asignar personal de TI para el monitoreo de actualizaciones en el

T17 A17 software de uso de la organización.
Debido a la baja probabilidad de ocurrencia, aún no se cuenta con un

T18 A18 plan de gestión para este caso. No obstante, no se pasa por
desapercibido por lo que se espera en el corto plazo el desarrollo de un
plan de respuesta.
Desarrollar una política en la que se establezca el uso exclusivo de un

T19 A19 antivirus para la protección de los canales de transmisión de paquetes
de información.
Desarrollar una política en la que se establezca el uso exclusivo de un

antivirus para la protección de los canales de transmisión de paquetes
T20 de información.
A20
Configurar el Activy Directory para la administración de dispositivos
conectados a red.
Es necesario realizar un estudio de la organización, de tal manera que,
la estructura de red se acople a la cantidad de ordenadores solicitados.
T21 A21 En el caso de que haya un puerto libre, este deberá ser reportado para
deshabilitarlo de forma inmediata.
Es necesario asegurar los puertos de conexión mediante un firewall que
T22 A22 controle el tráfico en la red, permitiendo detectar y bloquear el ingreso a
intrusos maliciosos.
Es necesaria la contratación de un segundo ISP para tener un respaldo

T23 A23 y balance de carga en transacciones en el caso de que alguno de los
ISP pueda presentar fallas en sus servicios.

52
4.6.5. Cuadro Gerencial

Tabla No. 9 Cuadro Gerencial
57
4.7. Esquema De Auditoría (Presenciales, Remota, Otros)
Realizar la Auditoria de Desarrollo del Software, por medio de reuniones

presenciales, con la finalidad de conocer el tipo de conocimientos que tiene cada
integrante del equipo del desarrollo del Software, respecto al organigrama de la
empresa, que se muestra a continuación.
Gráfico No. 25 Organigrama de área IT
Para obtener la información requerida para poder realizar la Auditoria

del Desarrollo del Software, es importantes tener las herramientas para
obtener la información requerida y que permita llevar a cabo las acciones
definidas en el cronograma de actividades por lo que se listan a continuación:
a. Cuestionarios: realizar diferentes tipos de cuestionarios de acuerdo con

las áreas con preguntas cerradas y abiertas con respecto a los roles a
evaluar del personal de la empresa, también recabar información
acerca del análisis del Desarrollo del Software.
58
b. Entrevistas: obtener información acerca de cómo se hace el

seguimiento de las metodologías empleadas en el Desarrollo de
Software.
c. Checklist: conjuntos de preguntas respondidas oralmente, destinados
al personal técnico, por tal motivo se deben realizar en forma ordenada,
coherente y clasificados por materias.
d. Herramientas de Auditoria en Software: utilizar diferentes tipos de
software que permite realizar una auditoría del software, verificar la
calidad de este, validar que cumpla con lo requerido y prevenir
vulnerabilidades del software.
e. Pruebas de caja Blanca: se realiza estas pruebas con acceso al
código del software y la estructura de este, para la ejecución de las
pruebas es necesario que el téster o la persona encargada que valla a
realizar, tenga los amplios conocimientos de la tecnología y arquitectura
usada para desarrollar el programa.
f. Pruebas de caja Negra: esta prueba se realiza desde el punto de vista
de las entradas y salidas que recibe o respuestas que produce, sin
tener en cuenta el funcionamiento interno del software.
g. Plataformas colaborativas: estas plataformas permitirán poder
desarrollar de una manera más centralizada la información que se
obtiene en los diferentes departamentos y encargados de este, en la
cual se mencionan las siguientes a usar:
I. Office 365: Permite llevar la información requerida acerca de la

Auditoria del Software en formato de Word, Excel, Power Pont,
como también mantiene al alcance la información requerida por
el auditor en cualquier momento.
II. Telegram: esta herramienta permite él envió de diferentes tipos
de archivos multimedia mediante la web, de una manera fácil,
segura y rápida.
III. Email Outlook: ayuda a colaborar con documento críticos y
proporciona la bandeja de entrada prioritarios, muestra primeros
59
los mensajes importantes y mejora la productividad.
Con todas las notas recopiladas de las entrevistas y el análisis de

primera mano del entorno, se procede al análisis de toda la información
recabada. Este análisis contrastará la normativa de referencia la
documentación y políticas de la entidad, con la realidad hallada. Es
conveniente que el marco normativo de referencia quede claramente
determinado en los informes que se generen, para que el auditado pueda
tener una imagen concreta y real de la situación y de esta forma, poder
tomar decisiones adecuadas.
Una vez terminado el análisis, se genera el informe de auditoría y el plan

de acción. El informe de auditoría representará la situación real contrastada
con el marco normativo de referencia. El plan de acción propondrá las medidas
correctoras necesarias para solucionar las incidencias que se estén
produciendo en el desarrollo de Software. Estos documentos serán
presentados a la gerencia de la entidad, para que, con su debido impulso, se
tomen las medidas correctoras adecuadas.
4.8. Guías Y Checklist
A continuación, se listan los diferentes tipos de checklist, las cuales

permitirá obtener la información requerida para poder evaluar los mismos y
presentar hallazgos de los resultados e informe final.
Checklist No. 1 Proceso de Documentación

60
Checklist: Proceso de Documentación
Identificación de la auditoria
Proyecto: Fase del ciclo de vida de desarrollo
Iniciador
Análisis Diseño
Implementación Mantenimiento
Desarrollo
Tipo de auditoría
Interna
Auditor
Nombre de auditor
Email Teléfono
Checklist
¿Existen estándares definidos para preparar la documentación SI NO

de desarrollo del Software?
¿La documentación existente se ajusta a dichos estándares? SI

NO
¿Existen procedimientos documentados para asegurar la SI

adherencia a estos estándares? NO
¿Estos procedimientos distinguen los cambios a los documentos

bajo control de configuración del software? ¿Este tipo de SI NO
cambios es revisado?
¿El contenido de la documentación del software es clara, SI

concisa, completa y comprensible? NO
¿Los miembros de las revisiones de esta

documentación se encuentra lo
suficientemente familiarizados con ella como SI
NO
para detectar inconsistencias fácilmente?
¿Existen suficientes copias de los documentos? SI NO

61
¿La documentación es desarrollada paralelamente a las otras

actividades del desarrollo del Software? ¿Refleja el estado real
del proyecto y de los productos del trabajo? SI NO

Checklist No. 2 Fase de Análisis
Checklist de ciclo de vida del desarrollo de software
Checklist: Fase de Análisis
1.Identificación de la auditoria
Institución Auditado:
Proyecto:
Iniciador:
2.Auditor
Nombre:
Email: Telefono:
3.Checklist
Objetivo: Los usuarios y responsables establecerán los requisitos.
Actividad: Deben participar usuarios de todas las SI NO
unidades a las que afecta el sistema.
Existe un documento aprobado por el gerente en el que

se determina el grupo de usuarios que participan en el
proyecto.
Existe un documento aprobado por el gerente en el que

se determina el grupo de usuarios que participan en el
proyecto.
Los usuarios son suficientemente representativos.

Se ha comunicado a los usuarios su
participación, su responsabilidad y su dedicación
estimada.
Actividad: Deben participar usuarios de todas las

unidades a las que afecta el sistema. SI NO
Existe un plan consensuado con el gerente que

detalla para cada entrevista la fecha, hora y lugar,
tipo de entrevista y un guion.
62
Se entrevista a todos los usuarios y a todos los

responsables.
Se remite el guion de la entrevista con tiempo

suficiente a los entrevistados para que puedan
prepararla o aportar documentación.
El guion incluye cuestiones para

obtener información sobre las funciones del
entrevistado y los problemas que necesita resolver
Actividad: A partir de las entrevistas se debe

documentar el sistema actual, así como sus
problemas. Debe obtenerse también un catálogo
con los nuevos requisitos. SI NO
Se ha realizado un modelo físico del

sistema actual, incluyendo objetivos, funciones y flujos
de entrada y salida.
Se han catalogado los problemas del sistema actual.

Se han realizado el modelo lógico de datos y el
de procesos del sistema actual.
Existe el catálogo de requisitos que están justificados.
Los requisitos son concretos y cuantificables.

Cada requisito tiene una prioridad y está clasificado en
funcional o no funcional.
El catálogo de requisitos ha sido

revisado y aprobado por el gerente y por los usuarios.
63
Actividad: Debe existir un procedimiento formal para

registrar cambios en los requisitos del sistema por
SI NO
parte de los usuarios.
El procedimiento existe y está aprobado.

Es coherente con el procedimiento de control de cambio
general.
Objetivo: Se utiliza la alternativa más favorable para que el sistema cumpla los
requisitos.
Actividad: Debe definirse las alternativas de

construcción con sus ventajas e inconvenientes. Se
selecciona la más adecuada.
Existe un documento en el que se describen las

alternativas.
Hay más de una alternativa, o por el contrario sólo

existe 1 real.
Cada alternativa está descrita desde el punto de vista

lógico y es coherente con los requisitos.
Si existe en el mercado algún producto que cumpla

con unas mínimas garantías los requisitos, una de las
alternativas debe ser su compra.
Si no lo impiden las características del proyecto una de

las alternativas debe ser el desarrollo del sistema por
una empresa externa.
Se ha evaluado las ventajas e inconvenientes de

cada alternativa de forma objetiva, así como sus
riesgos.
64
El gerente ha seleccionado una alternativa y es la mejor
Especificación Funcional del Sistema

Objetivo: El nuevo sistema debe especificarse SI
completamente desde el punto de vista
funcional y aprobado por los usuarios. NO
Debe realizarse un modelo un modelo logico de

procesos (MLP) y un modelo logico de
datos(MLD)
Debe existir el diccionario de datos o repositorio.
Debe definirse la forma en la que el nuevo

sistema interactuará con los usuarios.
La especificación del nuevo sistema incluye requisitos

de seguridad y rendimiento.
Debe especificarse las pruebas que el nuevo sistema

debe superar para ser aceptado.
La actualización del plan de proyecto seguirá los

criterios comentados.

65
66
Checklist No.
3 Fase de Diseño
Checklist: Fase de Diseño
Proyecto:
Iniciador: Diseño tecnico del sistema
2.Auditor
Nombre:
Email: Telefono :
3.Checklist
Objetivo: Debe definirse una arquitectura física para el sistema coherente
con la especificación funcional y el entorno tecnológico.
Actividad: Diseño Técnico del Sistema SI NO
El entorno tecnológico debe estar definido de forma
clara y conforme a los estándares.
Identificar todas las actividades físicas a realizar y
descomponerlas modularmente.
Debe diseñarse la estructura física de datos
adaptándola al entorno tecnológico.
Debe diseñarse un plan de pruebas que permita la
verificación de los distintos componentes del sistema,
los subsistemas y el sistema.
La actualización del plan de proyecto seguirá los criterios
comentados.

4 Fase de desarrollo
Checklist: Fase de desarrollo
Proyecto:
Iniciador: Desarrollo de los componentes del Sistema
2.Auditor
Nombre:
Email: Teléfono:
3.Checklist
67
Checklist No.
Objetivo: Los componentes o módulos deben desarrollarse utilizando
técnicas de programación correctas.
Actividad: Desarrollo de los componentes del sistema SI NO
Debe prepararse el entorno de desarrollo y de pruebas,
así como los procedimientos de operación.
Debe programarse, probar y documentar cada uno de
los componentes.
Deben realizarse las pruebas de integración para
asegurar que las interfaces entre los componentes o
módulos funcionan.
5 Fase de Implementación
Checklist: Fase de Implementación
Proyecto:
2.Auditor
Nombre:
Email: Teléfono :
3.Checklist
Objetivo: El sistema debe ser aceptado formalmente por los usuarios
antes de ser puesto en explotación.
Deben realizarse las pruebas del sistema que se
especificaron.
Debe revisarse el plan de implementación y aceptación
para adaptarlo al final del proyecto.
Debe aceptarse el sistema por los usuarios antes de
ponerse en explotación.
68
Checklist No.
69
Checklist No. 6 Fase de Mantenimiento

Checklist: Fase de mantenimiento
Proyecto:
2.Auditor
Nombre:
Email: Teléfono:
3.Checklist
Objetivo: El sistema se pondrá en explotación formalmente y pasará a estar
en mantenimiento sólo cuando haya sido aceptado y esté preparado.

Deben instalarse todos los procedimientos
de explotación.
El sistema nuevo se pondrá en
explotación de forma coordinada con
la retirada del antiguo (si existe)
migrando los datos si es necesario.
Debe firmarse el final de la

implementación por parte de los
usuarios.
Debe supervisarse el trabajo
de los usuarios durante las
primeras semanas.
Para terminar el proyecto se pondrá
en marcha el
mecanismo de mantenimiento.

70
Tabla No. 10 Matriz De Seguimiento A La Atención De Puntos De Auditoría

Puntos de Auditoría Actividad de auditoria Instrumento Responsable Acciones o participantes
Deben participar usuarios

Evaluar el cumplimiento Entrevistas y de todas las unidades que
de procedimiento, normas checklist Auditor conforman la organización
y controles.
Verificar si existe un orden
en la aprobación del
proyecto que defina
Evaluar el control de Entrevistas y Auditor claramente los objetivos,
cambios y versiones checklist restricciones y las
del software. unidades afectadas.
Auditoria del Verificar si existe un
entorno de Evaluar controles sobre la Entrevistas y responsable del proyecto
Auditor
desarrollo producción diaria. checklist
Evaluar controles sobre la Entrevistas y Verificar que los

calidad y eficiencia del checklist Auditor responsables de cada
desarrollo y mantenimiento unidad participe en la
del software y del servicio Verificación del trabajo
informático. realizado.
Evaluar y verificar que las

redes cumplan con los
Evaluar controles en las Entrevistas y requisitos mínimos de
redes de comunicaciones. checklist Auditor seguridad
71
Verificar que la organización

Evaluar la seguridad Entrevistas y cuente con la protección y
informática: checklist Auditor resguardo de la
información.
Verificar que el personal

Usuarios, responsables y Entrevistas y este informada de los
perfiles de uso de archivos checklist Auditor riesgos y vulnerabilidades.
y bases de datos.
Verificar que la organización

Entrevistas y Cuente con normas de
Normas de seguridad checklist Auditor seguridad informática
Verificar que todas las

actividades relacionadas a
los sistemas de
información automatizados
Control dual de la seguridad Entrevistas y se
Auditor
informática checklist realicen cumpliendo las
normas, estándares,
procedimientos y
disposiciones legales
establecidas
Auditoría en la fase Evaluación acerca de Deben participar usuarios
de análisis los conocimientos de los de todas las unidades a las
involucrados Checklist Auditor que afecta el sistema.
72
A partir de las entrevistas

se debe documentar el
Evaluar a los actores y roles sistema actual, así como
principales en el sus problemas. Debe
obtenerse también un
Desarrollo del Software Checklist Auditor catálogo con los nuevos
requisitos.
Debe definirse las

alternativas de construcción
Información acerca de la
con sus ventajas e
empresa (procesos,
inconvenientes.
organigramas, recursos con Checklist Auditor
lo que cuenta)
Se selecciona la más
adecuada.
Verificar que se
comprende
Evaluar los requerimientos de correctamente los
procesos del Desarrollo de Checklist Auditor requerimientos
solicitados.
Software
73
Evaluación de las metodologías

de
Auditoría en la fase Verificar la
de diseño Desarrollo de Software adopción correcta de
Checklist Auditor
(Metodología grafica) la metodología de desarrollo
Evaluar el tipo de Verificar que el lenguaje de

programación satisface los
Desarrollo del Software Checklist Auditor requerimientos
Evaluación de los registros Verificar que se utiliza algún

que permitan el seguimiento software para la
Automatización de
de la metodología de comunicación y la gestión
Checklist Auditor
Desarrollo de de tareas.
Software
Verificar que se
elige
Evaluación de la Arquitectura correctamente la
del Software, procesos, Checklist Auditor arquitectura según
guías, etc. los requerimientos
Verificar si utiliza
alguna herramienta
Auditar las tareas de para automatizar
cada desarrollador en la Checklist Auditor tareas de
construcción del Software desarrollo
74
Verificar que se utiliza

correctamente los IDE
Definir las herramientas para según sea la arquitectura
evaluar el entorno del Checklist Auditor para desarrollar
Auditoría en la
fase de desarrollo Verificar el licenciamiento Verificar si los IDE
de programas para la cuentancon
construcción del Software Checklist Auditor licenciamiento o es de
software libre.
Verificar que todo el

código fuente cumpla con
Evaluar las buenas prácticas las buenas prácticas de
del Desarrollo del Software Checklist Auditor desarrollo
Evaluación y monitoreo de Verificar que si el líder del

avances de la estimación proyecto cumple con la
Checklist Auditor verificación y monitoreo
de
de tiempo en el Desarrollo de las actividades

de desarrollo.
Software
Planteamiento de soluciones a Checklist Auditor Verificar si cuenta con

las inconsistencias detectadas plan de contingencia en
caso de desastres.
75
Verificar si todo el
desarrollo cuenta con
Evaluación de pruebas Checklist Auditor pruebas unitarias y
unitarias del Software pruebas de integración
Control de calidad del Verificar que la empresa

cumple con los estándares
Software Checklist Auditor
de calidad
Auditoría en la fase Evaluación de las pruebas Verificar que se realizan

de implementación integrales del Desarrollo del pruebas manuales y
Checklist Auditor automatizadas
Software
Verificar que el entorno de

producción sea compatible
Inspección de los componentes con la arquitectura del
del entorno de Checklist Auditor sistema
Producción
Revisión del proceso en Verificar que existan

cambios en Producción procedimientos para la
Checklist Auditor realización de cambios
Verificar que el plan de

contingencia este bien
76
Verificación de los planes de

contingencia en Producción Checklist Auditor
definido y claro para

todos
Revisión de la entrega final de los Verificar que lo

artefactos del Desarrollo de solicitado en los
Checklist Auditor requerimientos se
Software
cumplieron
satisfactoriamente
Plan de mantenimiento y Revisar el plan

seguimiento del Software de
Auditoría en la fase de Checklist Auditor
mantenimiento mantenimiento
Verificar el ciclo de vida del Revisar y de ser necesario

replantear el ciclo de vida
Software Checklist Auditor del software.

77
5. DESARROLLO DE AUDITORÍA
En la auditoría se debe tomar en cuenta todos los aspectos del ciclo de vida
en el desarrollo de software y así poder emitir un juicio y decidir el alcance de los
procedimientos de la auditoría y evaluar la confiabilidad, eficiencia e integridad de
los resultados obtenidos.
5.1. Procedimiento
El Procedimiento se debe analizar cualitativa y cuantitativamente la

eficiencia de un proceso, una tarea o un sistema
a. Planeación De La Auditoría
Para conocer la organización primero se requiere recopilar información

general de lo que se va a evaluar, hacer una investigación preliminar, realizar
entrevistas con el personal involucrado en el desarrollo de software y hacer un
cronograma de trabajo.
b. Definir La Lista De Verificación
Una lista de verificación es una herramienta que permite extraer

información primaria en forma de preguntas que se responden de forma binaria: lo
que tiene o no tiene.
c. Evaluación
5.2. Auditoría del entorno de desarrollo
Se evalúa todo los sistemas y entornos de desarrollo y el control de las

diferentes actividades
a. Evaluar el cumplimiento de procedimiento, normas y controles.

b. Evaluar el control de cambios y versiones del software.
c. Evaluar controles sobre la producción diaria.
d. Evaluar controles sobre la calidad y eficiencia del desarrollo y
mantenimiento del software y del servicio informático.
78
e. Evaluar controles en las redes de comunicaciones.

f. Evaluar la seguridad informática:
g. Usuarios, responsables y perfiles de uso de archivos y bases de datos.
h. Normas de seguridad
i. Control de información clasificada
j. Control dual de la seguridad informática
k. Evaluar las licencias y relaciones contractuales con terceros.
5.3. Auditoría de la fase de análisis
Con esta evaluación se pretende obtener un conjunto de

especificaciones formales que describan las necesidades de información que
deben ser cubiertas por el nuevo sistema de una forma independiente del
entorno técnico. Se identifican los requisitos del nuevo sistema, distinguiendo
su importancia y prioridad. Se determinan las posibles soluciones alternativas y
se elige la más adecuada.
a. Evaluación acerca de los conocimientos de los involucrados

b. Evaluar a los actores y roles principales en el Desarrollo del Software
c. Información acerca de la empresa (procesos, organigramas, recursos con lo
que cuenta)
d. Evaluar los requerimientos de procesos del Desarrollo de Software
e. Definición del Alcance de la Auditoria del Desarrollo de Software
5.4. Auditoría de la fase de Diseño
Evaluar si se elaborará un conjunto de especificaciones físicas del

nuevo sistema y también se evalúa si se diseña la arquitectura del sistema y el
esquema externo de datos.
a. Evaluar la metodología de Desarrollo de Software

b. Evaluar el tipo de Desarrollo del Software
c. Evaluar el registro de seguimiento de la metodología de Desarrollo de
Software
79
d. Evaluar la Arquitectura del Software, procesos, guías, etc

e. Evaluar las tareas de cada desarrollador en la construcción del Software
5.5. Auditoría de la fase de desarrollo
Evaluar si se programan y si se aprueban los distintos componentes y si

se ponen en marcha los procedimientos para que los usuarios puedan trabajar
con el sistema y se evalúa si se desarrollan los distintos componentes, se
prueban individualmente como integrados y se desarrollan los procedimientos
de operación.
a. Verificar el licenciamiento de programas para la construcción del Software

b. Evaluar las buenas prácticas del Desarrollo del Software
c. Evaluación y monitoreo de avances de la estimación de tiempo en el
d. Planteamiento de soluciones a las inconsistencias detectadas
e. Evaluación de pruebas unitarias del Software
f. Control de calidad del Software
5.6. Auditoría de la fase de implementación
Evaluar la aceptación del sistema por parte de los usuarios y las

actividades de puesta en marcha. Se verifica que el sistema cumple con los
requisitos establecidos.
a. Evaluación de las pruebas integrales del Desarrollo del Software

b. Inspección de los componentes del entorno de Producción
c. Revisión del proceso en cambios en Producción
d. Verificación de los planes de contingencia en Producción
e. Revisión de la entrega final de los artefactos del Desarrollo de Software
80
6. Formato del informe de auditorías
Tabla No. 11 Informe de Auditorías

Dominio/Proceso:
Subdominio:
Responsable
Objetivo:
Alcance:
Descripción del hallazgo:
Riesgos:
Conclusiones en Función al Riesgo:
Recomendaciones:
Firma del Auditor Firma del Líder de Auditoría
Nota. Este es el diseño de reporte de auditoría para cada una de las tareas que
se crearon para cada fase del ciclo de vida de desarrollo del software
6.1. Informe de fase de análisis para tarea 1
Tabla No. 12 Informe de Auditoría en Fase de Análisis

Dominio/Proceso: Auditoria de fase de análisis
Subdominio: Evaluación acerca de los conocimientos de los
involucrados
Responsable Roby Andrés Maldonado Pineda
Objetivo: Verificar si los involucrados en la planeación,
desarrollo, implementación y soporte
del proyecto tienen los conocimientos
necesarios para su área de trabajo.
Alcance: Área de planeación
81
La información obtenida por medio de una entrevista realizada a uno de los

empleados de la empresa, el cual tiene como puesto ser ingeniero de
desarrollo. El personal conoce la metodología con la que se trabaja y la
comprende; también conoce que tipos de tecnologías se utilizan para el
desarrollo de software; conocen que tipos de desarrollos realiza la empresa.
Previo a contratar a un candidato a cualquier puesto, se hace una evaluación
para medir los conocimientos que tiene del área al que está aplicando,
también se da un meses en los cuales se le capacita y se mide su desempeño
y adaptación a los procesos de la empresa.
Riesgos:
Que exista resistencia al cambio por parte de empleados, en caso de que se
quiera cambiar la metodología de desarrollo u otros procesos.

Que se evalué al candidato a un puesto es una estrategia excelente y adecuada
para conocer sus conocimientos y habilidades.
Recomendaciones:
Como parte del proceso de evaluación, se recomienda agregar una prueba que
muestre si este candidato se resiste al cambio o se adapta y evoluciona junto
con los objetivos de la empresa.

82
6.2. Informe de tarea 2 de la fase de análisis

Dominio/Proceso Auditoria de fase de análisis
Subdominio: Evaluar a los actores y roles principales en el Desarrollo
del Software

Objetivo: Evaluar los conocimientos, capacidades, habilidades y
carácter del personal y de candidatos a puestos dentro
de la empresa.
Alcance: Área de recursos humanos y equipo de IT

Previo a contratar a un prospecto, se evalúan sus habilidades, capacidades y
conocimientos dependiendo al puesto que este aplicando.
Riesgos:
Puede existir un prospecto sobre calificado para el puesto, con exigencias
salariales no adecuadas para el puesto en beneficio de sus conocimientos. Los
ingenieros de desarrollo tiendan a conformarse y al momento de migrar a otras
tecnologías no tengan los conocimientos requeridos.

Las evaluaciones periódicas a los empleados actuales son importantes por que
reflejan si se siguen preparando y actualizando, debido a que, en el área de
desarrollo, los ingenieros de desarrollo deben estar en constante capacitación.
Recomendaciones:
Promover e impulsar la preparación de los ingenieros de desarrollo.

83
Subdominio: Información acerca de la empresa (proceso, recursos con

los que cuentan)

Objetivo: Conocer procedimientos, con que recursos cuentan, que
tecnologías implementan y con que marcas trabaja la
empresa.

Servicios de desarrollo de
software.
- Aplicaciones cliente servidor.
- Aplicaciones web.
- Integración de sistemas a través de servicios SOAP, WCF, REST.
- Servicio de afinación (tunning) de bases de datos (SQL SERVER,
MYSQL).
- Outsourcing de personal para desarrollo de aplicaciones.
- Sistemas de administración de imágenes.
Tecnologías con las que desarrollan:
- HTML.
- CSS3.
- LARAVEL
- JAVASCRIPT.
- REACT JS
- REACT NATIVE
84
- C#
- AWS.
Marcas con las que trabajan:
- Canon.
- Dell.
- HP.
- Huawei.
- AWS.
- CISCO.
- EPSON.
- Microsoft.
- Vmware.
- ZEBRA TECHONOLOGIES.
- Samsung.
A cada colaborador se le brinda el equipo necesario para poder hacer uso tanto
en la oficina como en home office. Brindando una laptop de marca DELL con las
características correspondientes a cada puesto del colaborador, periféricos
correspondientes y un dispositivo celular proporcionado por SAMSUNG.
Riesgos:
Uso inapropiado del equipo que se le brinda a los colaboradores.
Posible robo de información o código.

La empresa auditada tiene un excelente registro de funciones
85
Recomendaciones:
Tener control y monitoreo sobre la información que sale y entra en cada equipo
perteneciente a la empresa.

Subdominio: Evaluar los requerimientos de procesos del Desarrollo de
Software

Objetivo: Comprobar que el proceso de levantamiento de
requerimientos se realiza de la manera más adecuada.
Alcance: Área de planeación y área de desarrollo

El gerente de TI se reúne y se comunica con el Gerente General de la empresa
y empieza a tomar los requerimientos en conjunto con el Project manager y el
Ingeniero de desarrollo para poder tener 3 puntos de vista diferentes por medio
de una reunión presencial. Luego de la reunión con el Gerente General entran
en juego el Gerente del departamento, el ingeniero desarrollador, esto con la
finalidad de determinar el tiempo (horas) en que se desarrollará el proyecto y las
tareas que se le asignaran a los ingenieros de desarrollo. Se programa una
reunión con el gerente general por semana hasta concluir el proyecto, cada
módulo desarrollado entra en
una fase de pruebas antes de poder integrarlo al software y después de, una
vez finalizado al cliente se le brinda una reunión para capacitar al personal que
estará haciendo uso del software, así como el seguimiento a las dudas que
existan en post venta.
Riesgos:
Dificultad para conseguir participación del gerente general.
Dificultad para que el gerente general adopte y permita cambios para conseguir
un proyecto exitoso
86

El método que se emplea para obtener los requerimientos de parte del cliente
parece ser muy efectiva, siempre y cuando exista participación del gerente,
mostrando su interés en las reuniones semanales para revisión de avances y
mejoras al proyecto.
Recomendaciones:
Se recomienda que en contrato se establezca con el representante y pueda
asistir a las reuniones semanales para evitar conflictos de horario y agenda del
cliente.

Subdominio: Definición del Alcance de la Auditoría del Desarrollo del
Software
87
Objetivo: Evaluar hasta que nivel de profundidad se hará la

auditoría.
Cuando se planeó el proceso de auditoría, se decidió y estableció en la
planificación auditar únicamente el ciclo de vida del desarrollo del software en
sus fases de análisis, diseño, desarrollo, implementación y mantenimiento
Riesgos:
No se evaluó ningún protocolo físico debido al tipo de auditoría.
Se espera que los resultados de la auditoría reflejen un resultado satisfactorio
para la empresa, considerando que se está verificando y comprobando que los
procesos de desarrollo son los adecuados y correctos.
Recomendaciones:

88
6. Informe 1
Dominio/Proceso Auditoria de fase de diseño
Subdominio: Evaluación de las metodologías de Desarrollo de Software
Objetivo: Comprobar que la metodología que se usa para el
desarrollo de software se está cumpliendo y si funciona

Alcance: Áreas de desarrollo y diseño
La empresa trabaja con la metodología SCRUM, donde el Project manager y un
ingeniero de software por medio de una reunión presencial, se reúnen con el
gerente general para la toma de requerimientos; Luego de la reunión con el
cliente entra en juego el Gerente de proyectos, gerente de departamento,
ingeniero de desarrollo, tester para determinar el tiempo (horas) en que se
desarrollará el proyecto y las tareas que se le asignaran a los ingenieros de
software.
Se programa una reunión con el gerente por semana hasta concluir el proyecto.
Riesgos:
Que, en las reuniones semanales con el Gerente General, este adjunte

nuevos requerimientos o características al desarrollo que se ha realizado,
como resultado se pueden agregar más tareas, se extienden las horas de
tareas, rehacer tareas que ya estaban realizadas, doble esfuerzo en tareas.
Se acuerda con el gerente que los requerimientos levantados desde la primera

sesión de levantamiento de requerimientos serán los que se cumplirán durante
el proceso de desarrollo, dando un margen de 1 semana, hasta la primera
reunión
89
6. de tarea de la fase de diseño

para que el cliente agregué o quite requerimientos al desarrollo.
Recomendaciones:
Que se firme un contrato donde se establezca que, durante todo el proceso de

desarrollo, pasando la semana de margen, no se aceptarán cambios en el
desarrollo para evitar rediseñar todo lo planeado.

90
7. Informe 2
Dominio/Proceso: Auditoria de fase de diseño
Subdominio: Evaluar el tipo de desarrollo del software
Objetivo: Comprobar que el proceso de desarrollo funciona
Alcance: Área de diseño y desarrollo
El proceso de asignación de tareas a los ingenieros de desarrollo bajo la
metodología SCRUM es una buena elección para entregas semanales de
avances, se organiza de mejor manera la asignación de tareas y las horas que
cada una de ellas tardará en realizarse.
Riesgos:
Riesgo de incumplimiento por parte de algún ingeniero de desarrollo.
El sistema home-office puede generar ciertos problemas si no se controla el
horario de trabajo de los ingenieros de desarrollo

La metodología de desarrollo es la adecuada para el tipo de trabajos que se les
encarga a los ingenieros de desarrollo, se tienen un control adecuado sobre las
tareas asignadas y el tiempo de entrega.
Recomendaciones:
Control sobre el trabajo que realizan los ingenieros de desarrollo mientras están
en la empresa.

91
de tarea de la fase de diseño

6.8. Informe 3
Subdominio: Evaluación de los registros que permiten el seguimiento

de la metodología de desarrollo del software
Objetivo: Comprobar que el sistema de registros se cumple con el

seguimiento de la metodología empleada para el
desarrollo del software
Alcance: Área de desarrollo
El registro de hitos permite a la empresa evaluar el desempeño que se tuvo
durante el tiempo de desarrollo del proyecto, se tiene registros de que
ingenieros tienen mejor desempeño al trabajar bajo una metodología de
desarrollo ágil.
Riesgos:
Que la metodología restrinja a los encargados del proyecto, Project manager e
ingenieros de desarrollo, a innovar, tener más creatividad y desarrollar propias
metodologías de desarrollo que impulsen el trabajo de manera óptima.

Llevar un registro de hitos es una excelente estrategia para evaluar el
desempeño de todas las áreas involucradas en el desarrollo del proyecto.
Recomendaciones:
Comparar registro de hitos con otros proyectos similares y comprobar que, si
se obtuvo un mejor resultado con el proyecto recién finalizado o se obtuvieron
mejores resultados en tareas similares en otro proyecto, puede que exista un
factor de cambio en ambos proyectos.

92
9. Informe 4
Subdominio: Evaluación de la arquitectura del software, procesos y
guías.

Objetivo: Comprobar que la arquitectura, procesos y guías
del software son las más adecuadas al tipo de
negocio
Alcance: Área de diseño y desarrollo

El departamento de Soluciones TI Corporativas orientado a implementar
soluciones corporativas de tecnología que facilitan y agregan valor a la
conducción de otros negocios, actividades profesionales y recreativas
Los servicios de desarrollo que realiza la empresa son: aplicaciones
cliente/servidor, aplicaciones web, integración de sistemas a través de
servicios SOAP, WFC, REST; Servicio de afinación (tunning) de base de datos
(SQL SERVER, MYSQL), Outsorcing de personal para desarrollo de
aplicaciones, sistemas de administración de imágenes.
Esta es la evidencia que la arquitectura actual que se usa para el desarrollo de
aplicaciones empleadas es la adecuada, debido a la alta demanda que la
empresa tiene a su área de IT.
Riesgos:
Otras empresas que están actualizando sus servicios, metodologías de
desarrollo, migrando a servicios en la nube y descentralizando sus operaciones.

La empresa ha estado trabajando desde hace 15 años en la distribución de
repuestos, se ha ganado una reputación en la industria y ha expandido su
negocio a otros países.
Recomendaciones:
Evaluar el negocio, innovar e ir creciendo junto con las nuevas tecnologías que
van apareciendo y pueden ser usados para el tipo de negocio.
93
6. de tarea de la fase de diseño

6.10. Informe de tarea 5 de la fase de diseño

Subdominio: Auditar las tareas de cada desarrollador en la
construcción de software

Objetivo: Comprobar que los desarrolladores cumplen con las
tareas asignadas en el tiempo asignado, la calidad del
trabajo desarrollado
Alcance: Área de desarrollo y diseño

Por medio Microsoft Azure, se tienen el control de versiones, commits
realizados por el ingeniero de desarrollo, conflictos que puedan existir en
código, errores y calidad de código, se lleva un control de tareas asignadas, el
tiempo que tiene para cumplir las tareas y él está de las tareas.
Riesgos:
Generar código desordenado, enviar comentarios dentro de código,
generar doble carga de procesos.

Se tiene un control adecuado sobre el trabajo del ingeniero de desarrollo
comprobando la calidad del código desarrollado antes de aprobar el commit y
enviarlo a producción.
Recomendacione
s:
Sin recomendaciones.

94
6. de tarea de la fase de desarrollo

11. Informe 1
Dominio/Proceso Auditoria de fase de desarrollo
Subdominio: Definición de la herramienta para el entorno de
desarrollo
Responsable: Luis Alberto Cabrera Barrios
Objetivo: Verificar que se tienen actualizados los IDE de
desarrollo según sea el diseño
del sistema.
Los desarrolladores necesitan, escribir, probar, implementar y documentar el
código, comunicarse con el equipo y dar un seguimiento del progreso del
proyecto. Mediante el checklist se verifico que si se cumplen con el uso
correcto de las herramientas y ser verifico que las herramientas están
actualizadas.
Riesgos:
Es muy importante que al momento de la construcción del proyecto se
comunique y que haga saber las razones por las cuales la ha seleccionado la
herramienta si soporta múltiples lenguajes, además si es software libre o
necesita licenciamiento.
Una vez tengamos implantada la solución permite una automatización que
liberará a los desarrolladores de tareas repetitivas y permitirá un gran ahorro de
tiempo, asegurando además un mayor nivel de calidad del software.
Recomendaciones:
No debemos caer en el error de confundir la calidad de una herramienta con sus
características

95

12. Informe 2
Dominio/Proceso: Auditoria de fase de desarrollo
Subdominio: Verificación de licenciamiento de programas
Objetivo: Verificar que las herramientas de desarrollo son de
software libre o de licenciamiento.

Mediante la verificación de la documentación de las herramientas se revisó los
términos y condiciones establecidos y se verifico que hay herramientas con
licenciamiento y también cuentan herramientas de software libre cada uno con
sus limitaciones.
Riesgos:
Es muy importante que al momento de que se elija la herramienta para la
construcción del software se comunique y que se haga saber las razones por
las cuales la ha seleccionado, esta labor es estar básicamente de acuerdo en
costos que pueda generar por licenciamiento, soporte que el proveedor pueda
ofrecer, aceptación de esta, compatibilidades, etc.
Es importante hacer una tabla comparativa con alguna otra herramienta
Recomendaciones:
No utilizar herramientas sin licenciamiento o utilizar software libre

13. Informe 3
Subdominio: Verificación las buenas prácticas de desarrollo
96

Objetivo: Crear un software bien estructurado aplicando
estándares y buenas prácticas.

La implementación de buenas prácticas para el desarrollo de software, son
una compilación de métodos o técnicas que permiten llevar a cabo de manera
óptima el conjunto de actividades que comprenden el desarrollo de un
sistema. Se verifico si se realiza pruebas al sistema en todo momento en el
desarrollo y si se permite adaptarte fácilmente a los cambios y asegura que las
herramientas cumplan las necesidades para las cuáles fueron diseñadas.
Riesgos:
El software de mala calidad siempre representa riesgos. Las causas que
afectan la calidad de software son resultado de malas prácticas que aparecen
desde la concepción del sistema.
Es elemental tener en cuenta los modelos que se adapten para un proyecto
requerido, para obtener como producto de ello una funcionalidad óptima del
producto. Las mejores prácticas para un desarrollo de software se encontrarán
ligadas hacia la finalidad del proyecto que requiera de dicho producto.
Recomendaciones:
Se debe estandarizar los controles y requisitos, mediante guías y formularios.

14. Informe 4
Subdominio: Evaluación y monitoreo de avances de la estimación
del
tiempo en el Desarrollo de Software
Responsable: Moisés Adolfo Vicente Guzmán
97

Objetivo: Cumplir con la planificación del tiempo para el
desarrollo
del software
Cumplir con el tiempo estimado para el desarrollo es importante y tomar en
cuenta el tiempo de holgura, no contar con tiempos reales, hace que el costo
del desarrollo aumente. Se verificó que se cuenta con metodología que verifica
los avances con las tareas de desarrollo de software, tomando como guía la
estimación de tiempo del proyecto.
Riesgos:
No considerar una buena estimación de tiempo para los entregables del
proyecto hace que aumente el costo del desarrollo en la cual la empresa lo
debe asumir por no considerar
Es importante poder contar con herramientas que ayuden a poder monitorear
los avances de las tareas del desarrollo del software como también la
estimación de tiempo de los entregables del proyecto y así evitar costos
innecesarios absorbidos por la empresa desarrolladora
Recomendaciones:
Se debe tener documentos necesarios para la estimación de tiempo y monitoreo
de los avances de las tareas del proyecto de desarrollo de software.

15. Informe 5
Subdominio: Planteamiento de soluciones a las
inconsistencias
detectadas
98

Objetivo: Verificar que se cuente con procedimientos para las
soluciones en el desarrollo del Software

Mediante la verificación de la documentación de se revisó acerca de los
planes que se tiene con respecto a las inconsistencias detectadas en el
desarrollo del software se encontró los procedimientos a seguir en las
inconsistencias detectadas antes, durante y después del desarrollo del
software.
Riesgos:
El no tener una documentación a seguir en las inconsistencias encontradas en
el desarrollo del software, hace que la calidad de software disminuya.

Cuando no se detecta las inconsistencias antes de llegar al cliente hace
perder la confianza de este y pueda tener vulnerabilidades que puede ser
aprovechadas para sabotear el software como también el tiempo sea mucho
más de lo planificado.
Recomendaciones:
Contar con documentación a seguir, respecto a las buenas prácticas en el
desarrollo del software y como solucionar inconvenientes que puedan surgir,
hace que la calidad de software no se pierda.

16. Informe 6
Subdominio: Evaluación de pruebas unitarias del Software
Objetivo: Comprobar que se tenga procedimientos adecuados
para
las pruebas unitarias del software
99

Se cuenta con herramientas necesarias para poder realizar las pruebas
unitarias y con los procedimientos establecidos para realizar la misma
Riesgos:
Que el software no realice correctamente las operaciones según la lógica de
negocio del cliente, puede afectar con las inconsistencias de información.
El no evaluar las pruebas unitarias de los módulos del software que se está
desarrollando puede afectar los cambios realizados en todos los módulos del
software y los procesos de la empresa.
Recomendaciones:
Que los encargados de las pruebas unitarias tengan conocimientos de todo el
funcionamiento del software y así poder ejecutar correctamente las pruebas
unitarias.
17. Informe 7
Subdominio: Control de calidad del Software
Objetivo: Evaluar el correcto cumplimiento de los requerimientos
del desarrollo del Software.
100

El control de calidad del software se tiene documentado desde en análisis de
requerimientos hasta la entrega del Software, cumpliendo con los
requerimientos solicitados del gerente.
Riesgos:
El software no cumpla con la eficiencia, seguridad, integridad y consistencia de
la información del cliente
El no cumplir con los requerimientos del sistema que el Gerente General
solicitó, no se está cumpliendo con la calidad de software
Recomendaciones:
Sin recomendaciones

101
6. de tarea de la fase de implementación

18. Informe 1
Dominio/Proceso Auditoria de fase de implementación
Subdominio: Evaluación de las pruebas integrales del Desarrollo del
Software

Objetivo: Evaluar las pruebas integrales del desarrollo del
software y su correcto funcionamiento
Alcance: Área de implementación

Para las pruebas integrales del Desarrollo del Software se cuenta con
documentación y seguimientos de las pruebas unitarias
Riesgos:
No detectar los errores o mal funcionamiento del todo los módulos del Software
hace que la calidad del software sea baja
El mal funcionamiento de un módulo del sistema de Software hace que todo el
sistema no cumpla con los requerimientos y la información del sistema sean
incongruentes.
Recomendaciones:
Sin recomendaciones
19. Informe 2
Subdominio: Inspección de los componentes del entorno de
Producción
102

Responsable: Francisca Eloína Carrillo
Objetivo: Verificar que los componentes del entorno de
producción cuenten con las buenas prácticas.

Dependiendo del tipo de software que el cliente desea, la empresa tiene los
entornos de producción, cada uno con su entorno de stage y producción. Cada
tipo de entorno con sus características necesarias.
Riesgos:
Se debe considerar los requisitos mínimos para el entorno de producción y
poder escalar respecto al crecimiento del Gerente.
En el desarrollo del software es importante que se pueda escalar y evitar que el
software quede obsoleto
Recomendaciones:
Siempre tomar en cuenta el escalar de las aplicaciones del desarrollo del
software
20. Informe 3
Subdominio: Revisión del proceso en cambios en producción
Responsable: Francisca Eloína Carrillo
103

Objetivo: Verificar los procesos que se realizan cuando el
software este en producción y cómo afrontar los
inconvenientes que puedan surgir.

No se cuenta documentado bien los procesos que se deben realizar cuando
surjan cambios en el entorno de producción.
Riesgos:
Al no tener en cuenta los cambios del entorno de producción se tiene el riesgo
que los requisitos que necesite el software no sea los necesarios y que el
software no pueda seguir con los procesos normales en el negocio.
Siempre considerar los cambios en el entorno de producción y como escalarlo
para que se pueda dar lo más pronto posible una solución.
Recomendaciones:
Se recomienda tener los procesos a seguir bien documento y que tenga acceso
el departamento y/o persona encargada del mismo para los cambios en el
entorno de producción.
21. Informe 4
Subdominio: Verificación de los planes de contingencia en Producción
Responsable: Rubens Alejandro Castillo Florian
104

Objetivo: Comprobar que los planes cuenten con las mejores
prácticas
Se cuenta con planes de contingencia en Producción con otros proveedores de
los servicios y/o escenarios de producción
Riesgos:
No contar con los planes de contingencia hace que el cliente deje inoperativos
sus procesos por el tiempo que se lleve para corregir los servicios necesarios
del Software.
De acuerdo con los planes se puede mitigar el riesgo que pueda surgir y hacer
que el sistema del software siga operando con los procesos más críticos del
mismo.
Recomendaciones:
Sin recomendaciones
22. Informe 5
Subdominio: Revisión de la entrega final de los artefactos del
Desarrollo del Software
105

Responsable: Rubens Alejandro Castillo Florian
Objetivo: Comprobar que los artefactos a entregar al gerente
cumplan el fácil uso del Software y facilitar al mismo.

Se comprobó que los artefactos esenciales que se entregan al Gerente por el
desarrollo del Software son los siguientes: manual de usuario, manuales
administrativos, capacitaciones divididas por departamentos o según lo
requiera el sistema.
Riesgos:
El no hacer conciencia a los usuarios del sistema y capacitación, hace que se
pueda filtrar información sensible como la dificultad del manejo del software.
Si no se cuenta con los procesos adecuados para la entrega de los artefactos
finales del desarrollo del software y la conciencia de este hace que los
procesos de la empresa sean mucho más tardados y no rentables.
Recomendaciones:
Se recomienda crear material audiovisual también para poder capacitar a los
usuarios en el uso del software, dividido en las áreas importantes del negocio.

106
6. de la fase de
23. Informe tarea 1 de mantenimiento
Dominio/ Auditoria de fase de mantenimiento
Proceso :
Subdominio: Plan de mantenimiento y seguimiento del software
Responsable Mauricio Ferdinand Morales Reyes
Objetivo: Verificar que se les da un soporte a las soluciones
desarrolladas y que se analiza el rendimiento de este.
Alcance: Área de desarrollo y soporte

Se da un seguimiento a todos los proyectos desarrollados por el grupo de
ingenieros de desarrollo, mientras que, el mantenimiento se brinda a los
usuarios que lo solicitan.
Riesgos:
Que el Gerente al solicitar mantenimiento o soporte de algún módulo
quiera pasar un requerimiento nuevo como parte del soporte, cuándo este debe
ser solicitado como tal y tendrá un costo diferente al soporte.

Por medio del seguimiento y mantenimiento que se da a las soluciones
desarrolladas, se obtiene Feedback por parte del Gerente y se agrega al libro
de registros para historial de hitos y fallos encontrados. Con el fin de mejorar
ciertos aspectos, actualizar herramientas de trabajo y proporcionar un trabajo
que cumple con los estándares de calidad.
Recomendaciones:
Sin recomendaciones

107
6.
24. Informe tarea 2 de Mantenimiento
Dominio/Proceso: Auditoria de fase de mantenimiento
Subdominio: Verificar el Ciclo de vida del software
Responsable Mauricio Ferdinand Morales Reyes
Objetivo: Comprobar que al finalizar un proyecto se haga una
revisión completa de hitos, fracasos, fallos, beneficios y
cumplimientos en cada fase del ciclo de vida del
software
Alcance: Área de desarrollo y soporte
Durante el proceso de desarrollo del software, cada fase es importante y se
lleva un registro de tareas que deben cumplirse antes de pasar a la siguiente
fase. La obtención de requerimientos, análisis, diseño, desarrollo y testing,
implementación y mantenimiento son las fases que la empresa debe seguir en
orden para el desarrollo de una solución.
El equipo de ingenieros de desarrollo debe completar las tareas asignadas
previo a continuar a la siguiente fase, esto se establece en la planificación y se
lleva un control con la metodología SCRUM.
Riesgos:
Al contar con muchos proyectos a los cuales se ha acordado dar
Mantenimiento y soporte, puede existir una sobre carga de tareas al equipo de
mantenimiento y soporte.
El equipo de desarrollo cumple con cada una de las fases del ciclo de vida del
software, iniciando con el análisis y levantamiento de requerimientos, diseño,
desarrollo y testing, implementación y manteamiento.
Recomendaciones:
El equipo de desarrollo y soporte hace una revisión completa para informar al
jefe del proyecto acerca de del % de éxito que se obtuvo en cada fase del
ciclo de vida del desarrollo del software.
Para evitar sobrecarga al área de mantenimiento y soporte, se puede capacitar
al grupo de IT del cliente para que comprenda el funcionamiento del sistema.

108
6. de la fase de
25. Carta de presentación para auditoría
Retalhuleu, 20 de marzo del 2023
Estimados Señores de Moviland S.A.
Por medio de la presente, nos complace presentarnos como estudiantes de

la Maestría en Seguridad Informática de la Universidad Mariano Gálvez. Estamos
interesados en llevar a cabo una auditoría en el área de informática de [nombre de
la empresa o institución] como parte de nuestro programa de estudios y en
beneficio de su organización.
Nuestro grupo de estudiantes está compuesto por profesionales altamente

capacitados en el campo de la seguridad informática y cuenta con una sólida
formación académica y práctica en el análisis de riesgos, políticas de seguridad,
protección de datos y buenas prácticas en el uso de la tecnología de la
información.
El objetivo de nuestra propuesta es realizar una auditoría integral del área

de informática de su empresa o institución, identificando áreas de mejora y
oportunidades de crecimiento en términos de seguridad y eficiencia. Nuestra
metodología incluye la revisión de políticas y procedimientos, análisis de sistemas
y redes, así como la identificación de posibles vulnerabilidades que puedan poner
en riesgo la integridad y confidencialidad de la información.
109
6.
110
Entendemos que la seguridad informática es un aspecto fundamental en el

mundo actual y que las organizaciones deben mantenerse protegidas y
actualizadas frente a las constantes amenazas y desafíos que enfrentan. Por esta
razón, nos comprometemos a trabajar de manera ética y responsable,
garantizando la confidencialidad de la información y el respeto a las políticas
internas de su empresa o institución.
Agradecemos de antemano su atención y consideración a nuestra

propuesta. Estamos a su disposición para ampliar detalles y responder a cualquier
inquietud que pueda surgir en relación con nuestro proyecto. Por favor, no dude en
ponerse en contacto con nosotros a través de [teléfono] o [correo electrónico].
Atentamente,
Grupo No. 3 de MASI sede Retalhuleu
______________________________ ______________________________
Maldonado Pineda, Roby Andrés Cabrera Barrios, Luis Alberto
Auditor Líder de la sociedad Auditora Gerente Administrativo de la sociedad
auditor
111
CONCLUSIONES
Por lo tanto, el auditor evalúa y comprueba los controles y procedimientos

en del desarrollo de software, desarrollando y aplicando técnicas mecanizadas de
auditoría, incluyendo el uso del software y la verificación procedimientos de forma
manual y también puede emplear software de auditoría y otras técnicas asistidas
por una computadora.
El auditor revisa los controles internos definidos en cada ciclo de vida de

desarrollo de software y el cumplimiento de la normativa interna y externa, de
acuerdo con los objetivos definidos por la alta gerencia de la organización.
Informará de los hechos observados y recomendará acciones que minimicen
los riesgos que pueden producirse.
Actualmente una auditoría es sumamente importante, porque gracias a

ello se observa el adecuado desempeño en los procesos en el desarrollo de
software, constatar que los controles sean los adecuados y necesarios para
que los sistemas de la empresa conlleven a una alta confiabilidad, así mismo a
un alto nivel en seguridad.
112
RECOMENDACIONES
Definir objetivos claros antes de comenzar una auditoría de sistemas, es

importante definir claramente los objetivos y los requisitos del proyecto. De esta
manera, los auditores pueden enfocarse en los aspectos críticos de la auditoría y
evitar perder tiempo en áreas no esenciales.
Los auditores de sistemas deben identificar y evaluar los riesgos y controles

de seguridad asociados con los sistemas de la organización. Esto incluye la
evaluación de la confidencialidad, integridad y disponibilidad de la información, así
como la evaluación de los procesos y procedimientos para proteger los sistemas.
Verificar el cumplimiento de leyes y regulaciones ya que los auditores de

sistemas deben verificar que la organización cumpla con las leyes y regulaciones
aplicables. Esto incluye leyes y regulaciones de privacidad, seguridad de datos,
cumplimiento financiero, entre otras.
Evaluar la gestión de cambios en los sistemas pueden tener un impacto

significativo en la seguridad y la eficiencia de los mismos. Por lo tanto, es
importante evaluar cómo la organización gestiona los cambios en sus sistemas.
Los auditores de sistemas deben documentar todos los hallazgos y

recomendaciones de la auditoría en un informe. Este informe debe presentar una
evaluación clara y objetiva de los sistemas de la organización, así como
recomendaciones para mejorar la seguridad y la eficiencia.
113
ANEXO
Anexo No. 1 Tablero de Actividades TRELLO
Anexo No. 2 Informe de Resultados Mediante SonarQube
Fuente: elaboración grupo No. 3 MASI, Retalhuleu, 2023 Anexo No. 3 Captura de
Problemas Hallados
114
Anexo No. 4 Lista de Riesgos

Esta tabla muestra el número de alertas de cada tipo de alerta, junto con el nivel de
riesgo del tipo de alerta.
Tipo de alerta Risk Count

Falta el encabezado anti-clickjacking Medio 82
Tipo de alerta Risk Count

Biblioteca JS vulnerable Medio 1
Divulgación de errores de aplicación Bajo 10
Cookie sin bandera segura Bajo 4

115
Inclusión de archivos fuente JavaScript entre Bajo 953

dominios
Las páginas seguras incluyen contenido mixto Bajo 6
Divulgación de información Informativo 99

Comentarios sospechosos
Incompatibilidad de caracteres Informativo 16
Conjunto de encabezados de control de caché Informativo 130

incompleto o nulo
Tipo de alerta Riesgo Contar
Total 9
Fuente: elaboración grupo No. 3 MASI, Retalhuleu, 2023 BIBLIOGRAFÍA
(2023). Obtenido de Concepto: https://concepto.de/confiabilidad/
(2023). Obtenido de economipedia:

https://economipedia.com/definiciones/controladministrativo.html
(2023). Obtenido de economipedia:

https://economipedia.com/definiciones/gobernanza.html
Arroba System. (04 de 02 de 2021). Obtenido de

https://arrobasystem.com/blogs/blog/que-son-las-amenazas-informaticas-
ycomo-protegerte-de-ellas
AUREN. (2019). Obtenido de https://auren.com/mx/blog/importancia-de-

lasauditorias-en-las-empresas/
116
Diligent. (07 de 03 de 2023). Diligent HighBond. Obtenido de

https://help.highbond.com/helpdocs/highbond/es/Content/projects/planning_
projects/defining_assurance_plans.htm
DocuSign. (15 de 09 de 2022). Obtenido de

https://www.docusign.mx/blog/disponibilidad-de-lainformacion#:~:text=El
%20t%C3%A9rmino%20de%20disponibilidad%20de
economipedia. (2023). Obtenido de

https://economipedia.com/definiciones/administracion.html
economipedia. (2023). Obtenido de

https://economipedia.com/definiciones/auditoria-informatica.html
Economipedia. (2023). Obtenido de

https://economipedia.com/definiciones/informe-de-auditoria.html
ISOTools Excellence. (18 de Enero de 2018). Obtenido de ISOTools Excellence

MALO, G. (2018). Estudio de Innovación. Obtenido de
https://aplicacionesytecnologia.com/como-hacer-una-auditoria-de-software/
OWASP. (2023). Fundación OWASP. Obtenido de https://owasp.org/
Portal ISO. (2022). Obtenido de https://www.iso33000.es/
PÚBLICA, C. D. (2020). CEGEP. Obtenido de

https://cegepperu.edu.pe/2021/01/31/plan-de-gestion-de-la-calidad/
Rioja. (2022). UNIR. Obtenido de

https://www.unir.net/ingenieria/revista/politicasseguridad-informatica/
Santander. (2022). Obtenido de

https://www.bancosantander.es/glosario/confidencialidad-
informacion#:~:text=La%20confidencialidad%2C%20en%20inform%C3%A1
Significados. (2023). Obtenido de https://www.significados.com/informacion/

117
Significados. (2023). Obtenido de https://www.significados.com/vulnerabilidad/

Word Auditoria

Cargado por

Copyright:

Formatos disponibles

Word Auditoria

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Word Auditoria

Cargado por

Copyright:

Formatos disponibles

Universidad Mariano Gálvez de Guatemala

Maestría en Seguridad Informática

AUDITORIA AL CICLO DE VIDA DE DESARROLLO DE SOFTWARE,

Roby Andrés Maldonado Pineda 1793-17-11524

Fin de Semana, sábado

Gráfico No. 1 Ciclo de vida del Desarrollo de Software ........................................16

Tabla No. 1 Listado de Activos Tecnológicos Data Center Principal .....................13

Checklist No. 1 Proceso de Documentación .......................................................56

Anexo No. 1 Tablero de Actividades TRELLO ................................................... 107

La auditoría del ciclo de vida de desarrollo de software es fundamental para

El objetivo principal de esta auditoría es evaluar y mejorar el proceso de

Los resultados de la auditoría serán documentados y compartidos con la

1.1. Presentación de la empresa

Fundada en 2005, Moviland es una empresa Líder en la venta de

La empresa formada por un grupo de colaboradores profesionales quienes

Dentro de la estructura de la empresa la tecnología es la parte fundamental

finalidad de comprender la manera en la que se opera dentro del departamento y

Para que la gestión determine y logre sus objetivos, se debe utilizar de

La gestión se puede aplicar en instituciones formales e informales, las

“La administración es el proceso que busca por medio de la planificación, la

Tiene relación con un incidente nuevo o recién descubierto que tiene el

“son aquellas ocasiones en que piratas informáticos logran entrar en tus

dependiendo de cuál sea, pueden darse a través de e-mails engañosos, haciendo

La tarea principal de una auditoría informática es evaluar los sistemas

“La auditoría informática es una modalidad de auditoría que concierne a

Fiabilidad o Confiabilidad es, en un área particular del conocimiento, la

“la confiabilidad puede entenderse como la posibilidad de confiar en algo,

Los principios de confidencialidad y conservación están destinados a la

piratería electrónica, la transmisión ilegal de información de datos o la violación del

Hace referencia a la privacidad de los datos pertenecientes a una entidad,

“La confidencialidad, en informática, es un principio fundamental de la

En la teoría de la investigación económica y empresarial, el control

“El control administrativo es la etapa de la gestión administrativa que se

Garantiza que los datos de la entidad estén a disposición de usuarios y

o cualquier otro puedan realizar pagos desde la comodidad de sus hogares o en

“Disponibilidad de la información implica la adopción de sistemas que

Es un conjunto de proceso establecidos mediante un documento o conjunto

“La Norma ISO 9000:2015 define al plan de gestión de la calidad como

El gobierno también se interpreta como un arte, que exige una relación

Otro aspecto clave que incluye la gobernanza es la sustentabilidad, ya que

“La gobernanza es un modo de dirigir un país o entidad buscando el

Los costos derivados de pérdida de seguridad no son sólo costos

Para evaluar el impacto de los ataques basados en la red y el "valor

a. Virus, troyanos, gusanos y otros tipos de programa maligno que pueden

b. Ataques distribuidos de denegación de servicio (DDoS) y flooding, que

c. Desfiguración de sitios web. (Gerencia).

d. Reclamaciones internacionales, poniendo en riesgo la seguridad

Los daños causados por los ataques, independientemente de la fuente, se

Los ataques por denegación de servicio ponen como riesgo la

de comunicación entre las partes y se encarece al utilizar medios ya obsoletos en

Es un conjunto de datos interrelacionados con el objetivo de formar

“Como información denominamos al conjunto de datos, ya procesados y

Es un proceso sistemático de revisión de las cuentas anuales de una

1. El auditor puede ser tanto una persona física

2. El auditor puede ser externo (si no forma parte

la capacidad de elaborar informes de auditoría, pero los

3. El informe de auditoría expresa una crítica no

4. Versan sobre las cuentas anuales o estados

“El informe de auditoría es un informe realizado por un auditor externo