GESTIÓN DE LA

SEGURIDAD DEL
SOFTWARE
Ms.C. Jhosep Valenzuela
Contenido
IV. Pruebas de seguridad en aplicaciones
1. Creación de un programa de evaluación y pruebas de seguridad
• Pruebas de seguridad
• Evaluaciones de seguridad
• Auditorías de seguridad
2. Realización de evaluaciones de vulnerabilidades
1. Análisis de detección de redes
2. Análisis de vulnerabilidades de red
3. Análisis de vulnerabilidades web
4. Análisis de vulnerabilidades de la base de datos
3. Flujo de trabajo de gestión de vulnerabilidades
4. Pruebas de penetración
5. Pruebas en software
6. Implementación de procesos de gestión de seguridad
7. Resumen
8. Preguntas de revisión
IV. Pruebas de seguridad en
aplicaciones
Creación de un programa de evaluación y
pruebas de seguridad
La actividad de mantenimiento fundamental para un equipo de seguridad de la información
es su programa de evaluación y pruebas de seguridad.
Este programa incluye pruebas, evaluaciones y auditorías que verifican regularmente que
una organización tiene controles de seguridad adecuados y que esos controles de
seguridad funcionan correctamente y protegen eficazmente los activos de información.
Los tres componentes principales de un programa de evaluación de seguridad
• Pruebas de seguridad
• Evaluaciones de seguridad
• Auditorías de seguridad
Pruebas de seguridad

Las pruebas de seguridad verifican que un control funciona correctamente.

Estas pruebas incluyen escaneos automatizados, pruebas de penetración asistidas por
herramientas e intentos manuales de socavar la seguridad.
Al programar controles de seguridad para su revisión, los administradores de seguridad de
la información deben tener en cuenta los siguientes factores:
• Disponibilidad de recursos de pruebas de seguridad
• Criticidad de los sistemas y aplicaciones protegidos por los controles probados
• Sensibilidad de la información contenida en los sistemas y aplicaciones probados
• Probabilidad de fallo técnico del mecanismo de aplicación del control
• Probabilidad de una configuración incorrecta del control que pondría en peligro la
seguridad
• Riesgo de que el sistema sea atacado
Pruebas de seguridad

• Tasa de cambio de la configuración de control

• Otros cambios en el entorno técnico que pueden afectar al rendimiento del control
• Dificultad y tiempo necesarios para realizar una prueba de control
• Impacto de la prueba en las operaciones comerciales normales
Después de evaluar cada uno de estos factores, los equipos de seguridad diseñan y
validan una estrategia integral de evaluación y pruebas. Esta estrategia puede incluir:
El análisis automatizado no requiere trabajo de los administradores una vez que está
configurado, por lo que es fácil de ejecutar con bastante frecuencia.
Es posible que el equipo de seguridad desee complementar esos escaneos
automatizados con una prueba de penetración manual realizada por un consultor
externo. Estas pruebas pueden ocurrir anualmente para minimizar los costos y la
interrupción del negocio
Evaluaciones de seguridad

Las evaluaciones de seguridad son revisiones exhaustivas de la seguridad de un sistema,

aplicación u otro entorno probado.
Las evaluaciones de seguridad normalmente incluyen el uso de herramientas de prueba de
seguridad, pero van más allá del escaneo automatizado y las pruebas de penetración
manual. También incluyen una revisión cuidadosa del entorno de amenazas, los riesgos
actuales y futuros, y el valor del entorno objetivo.
El principal producto de trabajo de una evaluación de seguridad es normalmente un informe
de evaluación dirigido a la dirección que contiene los resultados de la evaluación en un
lenguaje no técnico y concluye con recomendaciones específicas para mejorar la seguridad
del entorno probado.
Las evaluaciones pueden ser realizadas por un equipo interno, o pueden ser
subcontratadas a un equipo de evaluación de terceros con experiencia específica en las
áreas que se evalúan.
Auditorías de seguridad

Las auditorías de seguridad utilizan muchas de las mismas técnicas seguidas durante las
evaluaciones de seguridad, pero deben ser realizadas por auditores independientes.
Las auditorías, son evaluaciones realizadas con el propósito de demostrar la efectividad de
los controles a un tercero. El personal que diseña, implementa y monitorea los controles
para una organización tiene un conflicto de intereses inherente al evaluar la efectividad de
esos controles.
Los auditores proporcionan una visión imparcial e imparcial del estado de los controles de
seguridad. Escriben informes que son bastante similares a los informes de evaluación de
seguridad, pero esos informes están destinados a diferentes audiencias que pueden incluir
la junta directiva de una organización, los reguladores gubernamentales y otros terceros.
Hay tres tipos principales de auditorías: auditorías internas, auditorías externas y auditorías
de terceros.
Auditorías de seguridad

Auditorías Internas
Las auditorías internas son realizadas por el personal de auditoría interna de una
organización y generalmente están destinadas a audiencias internas. El director ejecutivo
de auditoría (CAE) podría reportar directamente a la junta directiva de la organización,
presidente, director ejecutivo (CEO) o un rol similar.
Auditorías Externas
Las auditorías externas son realizadas por una empresa de auditoría externa. Estas
auditorías tienen un alto grado de validez externa porque los auditores que realizan la
evaluación teóricamente no tienen conflicto de intereses con la propia organización.
Algunas de las llamadas cuatro grandes firmas de auditoría
• Ernst & Young
• Deloitte
• PricewaterhouseCoopers
• KPMG
Auditorías de seguridad

Auditorías de terceros
Las auditorías de terceros son realizadas por, o en nombre de, otra organización. Un
organismo regulador puede tener la autoridad para iniciar una auditoría de una empresa
regulada bajo contrato o ley.
En el caso de una auditoría de terceros, la organización que inicia la auditoría
generalmente selecciona a los auditores y diseña el alcance de la auditoría.
El Instituto Americano de Contadores Públicos Certificados (AICPA) publicó un estándar.
El documento 18 (SSAE 18), titulado Reporting on Controls, proporciona un estándar
común para ser utilizado por los auditores que realizan evaluaciones de organizaciones de
servicios con la intención de permitir que la organización realice una evaluación externa en
lugar de múltiples evaluaciones de terceros y luego comparta el informe resultante con
clientes y clientes potenciales.
Auditorías de seguridad

Fuera de los Estados Unidos, el Estándar Internacional para Compromisos de Atestación

(ISAE) 3402, Informes de Aseguramiento sobre Controles en una Organización de
Servicios.
Los compromisos SSAE 18 e ISAE 3402 se conocen comúnmente como auditorías de
controles de organización de servicios (SOC), y vienen en tres formas
 Compromisos SOC 1 Evalúe los controles de la organización que podrían afectar la
precisión de los informes financieros.
 Compromisos SOC 2 Evaluar los controles de la organización que afectan la
seguridad (Tríada de la CIA) y la privacidad de la información almacenada en un
sistema. Los resultados de la auditoría SOC 2 son confidenciales y normalmente solo
se comparten fuera de la organización bajo un NDA.
 Compromisos SOC 3 Evaluar los controles de la organización que afectan la
seguridad (Tríada de la CIA) y la privacidad de la información almacenada en un
sistema. Sin embargo, los resultados de la auditoría SOC 3 están destinados a la
divulgación pública.
Auditorías de seguridad

Existen dos tipos de informe SOC basados en la opinión proporcionada por el auditor,
ambos informes comienzan con proporcionar una descripción por parte de la gerencia de
los controles implementados
 Informes de tipo I Estos informes proporcionan la opinión del auditor sobre la
descripción proporcionada por la administración y la idoneidad del diseño de los
controles. Los informes de tipo I también cubren solo un punto específico en el
tiempo, en lugar de un período prolongado. Puede pensar en el informe de Tipo I
como una revisión de documentación en la que el auditor está verificando las cosas
en papel y asegurándose de que los controles descritos por la administración sean
razonables y apropiados.
 Informes de tipo II Estos informes van más allá y también proporcionan la opinión
del auditor sobre la eficacia operativa de los controles. Es decir, el auditor confirma
que los controles están funcionando correctamente. El informe de tipo II también
cubre un período prolongado de tiempo: al menos seis meses de funcionamiento.
Puede pensar en el informe de Tipo II como más parecido a una auditoría tradicional.
Los auditores no solo están revisando el papeleo; también están entrando y
verificando que los controles funcionen correctamente
Auditorías de seguridad

Normas de auditoría
Al realizar una auditoría o evaluación, el equipo que realiza la revisión debe tener claro el
estándar que están utilizando para garantizar que la organización implemente
adecuadamente los controles para cumplir con esos objetivos.
 Objetivos de Control de Tecnologías de la Información y Afines (COBIT). COBIT
describe los requisitos comunes que las organizaciones deben tener en torno a sus
sistemas de información. El marco COBIT es mantenido por ISACA.
 La Organización Internacional de Normalización (ISO).
 ISO 27001 es un estándar para establecer un sistema de gestión de seguridad
de la información
 ISO 27002 entra en más detalles sobre los detalles de los controles de seguridad
de la información.
 Estos estándares reconocidos internacionalmente son ampliamente utilizados dentro
del campo de la seguridad, y las organizaciones pueden optar por obtener la
certificación oficial como compatible con ISO 27001
Realización de evaluaciones de
vulnerabilidades
Descripción de vulnerabilidades
Los componentes del Protocolo de automatización de contenido de seguridad (SCAP) del
NIST incluyen:
• Vulnerabilidades y exposiciones comunes (CVE) proporciona un sistema de
nomenclatura para describir las vulnerabilidades de seguridad.
• Common Vulnerability Scoring System (CVSS) proporciona un sistema de puntuación
estandarizado para describir la gravedad de las vulnerabilidades de seguridad.
• Common Configuration Enumeration (CCE) proporciona un sistema de nomenclatura
para los problemas de configuración del sistema.
• Common Platform Enumeration (CPE) proporciona un sistema de nomenclatura para
sistemas operativos, aplicaciones y dispositivos.
• Extensible Configuration Checklist Description Format (XCCDF) proporciona un lenguaje
para especificar listas de comprobación de seguridad.
• Open Vulnerability and Assessment Language (OVAL) proporciona un lenguaje para
describir los procedimientos de prueba de seguridad
Realización de evaluaciones de
vulnerabilidades
Análisis de vulnerabilidades
Los análisis de vulnerabilidades sondean automáticamente sistemas, aplicaciones y redes,
en busca de debilidades que puedan ser explotadas por un atacante. Las herramientas de
escaneo utilizadas en estas pruebas proporcionan pruebas rápidas de apuntar y hacer clic
que realizan tareas que de otro modo serían tediosas sin requerir intervención manual. La
mayoría de las herramientas permiten el análisis programado de forma recurrente y
proporcionan informes que muestran las diferencias entre los análisis realizados en días
diferentes, lo que ofrece a los administradores una vista de los cambios en su entorno de
riesgo de seguridad.
Hay cuatro categorías principales de análisis de vulnerabilidades:
1. Análisis de detección de redes
2. Análisis de vulnerabilidades de red
3. Análisis de vulnerabilidades de aplicaciones web
4. Análisis de vulnerabilidades de bases de datos
Una amplia variedad de herramientas realizan cada uno de estos tipos de escaneos.
Realización de evaluaciones de
vulnerabilidades
1. Análisis de detección de redes
El escaneo de descubrimiento de red utiliza una variedad de técnicas para escanear un
rango de direcciones IP, buscando sistemas con puertos de red abiertos.
Los analizadores de detección de redes en realidad no sondean los sistemas en busca de
vulnerabilidades, sino que proporcionan un informe que muestra los sistemas detectados
en una red y la lista de puertos que están expuestos a través de los firewalls de red y
servidor que se encuentran en la ruta de red entre el analizador y el sistema analizado.
Los escáneres de detección de redes utilizan muchas técnicas diferentes para identificar
puertos abiertos en sistemas remotos. Algunas de las técnicas más comunes son las
siguientes:
TCP SYN Scanning Envía un solo paquete a cada puerto escaneado con el indicador SYN
establecido. Esto indica una solicitud para abrir una nueva conexión. Si el analizador recibe
una respuesta que tiene establecidos los indicadores SYN y ACK, esto indica que el
sistema se está moviendo a la segunda fase del protocolo de enlace TCP de tres vías y
que el puerto está abierto. El escaneo TCP SYN también se conoce como escaneo "medio
abierto".
Realización de evaluaciones de
vulnerabilidades
TCP Connect Scanning Abre una conexión completa al sistema remoto en el puerto
especificado. Este tipo de análisis se utiliza cuando el usuario que ejecuta el análisis no
tiene los permisos necesarios para ejecutar un análisis a medio abrir. La mayoría de los
otros tipos de escaneo requieren la capacidad de enviar paquetes sin procesar, y el
sistema operativo puede restringir al usuario el envío de paquetes hechos a mano.
TCP ACK Scanning Envía un paquete con el indicador ACK establecido, lo que indica que
forma parte de una conexión abierta. Este tipo de análisis se puede realizar en un intento
de determinar las reglas aplicadas por un firewall y la metodología del firewall.
UDP Scanning Performs un análisis del sistema remoto utilizando el protocolo UDP,
comprobando si hay servicios UDP activos. Este tipo de análisis no utiliza el protocolo de
enlace de tres vías, porque UDP es un protocolo sin conexión.
Xmas Scanning Envía un paquete con los indicadores FIN, PSH y URG establecidos. Se
dice que un paquete con tantas banderas configuradas está "iluminado como un árbol de
Navidad", lo que lleva al nombre del escaneo.
Realización de evaluaciones de
vulnerabilidades
La herramienta más común utilizada para el escaneo de descubrimiento de redes es una
herramienta de código abierto llamada nmap. Originalmente lanzado en 1997, nmap es,
sorprendentemente, todavía mantenido y en uso general hoy en día. Sigue siendo una de
las herramientas de seguridad de red más populares, y casi todos los profesionales de la
seguridad usan nmap regularmente o lo han usado en algún momento de su carrera.
Puede descargar una copia gratuita de nmap u obtener más información sobre la
herramienta en nmap.org.
Cuando nmap escanea un sistema, identifica el estado actual de cada puerto de red en el
sistema. Para los puertos donde nmap detecta un resultado, proporciona el estado actual
de ese puerto
Open El puerto está abierto en el sistema remoto y hay una aplicación que acepta
activamente conexiones en ese puerto.
Close El puerto es accesible en el sistema remoto, lo que significa que el firewall
permite el acceso, pero no hay ninguna aplicación que acepte conexiones en ese
puerto.
Filtered Nmap no puede determinar si un puerto está abierto o cerrado porque un
firewall está interfiriendo con el intento de conexión.
Realización de evaluaciones de
vulnerabilidades
Realización de evaluaciones de
vulnerabilidades
• Un atacante que lea estos resultados probablemente
haría algunas observaciones:
• Apuntar un navegador web a este servidor
probablemente daría una buena idea de lo que hace
el servidor y quién lo opera. Simplemente escribiendo
la dirección IP del sistema en la barra de direcciones
del navegador puede revelar información útil.
• Las conexiones HTTP a este servidor están cifradas.
Es probable que no sea posible espiar esas
conexiones.
• El puerto SSH abierto es un hallazgo interesante. Un
atacante puede intentar realizar un ataque de
contraseña de fuerza bruta contra cuentas
administrativas en ese puerto para obtener acceso al
sistema.
Realización de evaluaciones de
vulnerabilidades
2. Análisis de vulnerabilidades de red
Los análisis de vulnerabilidades de red son más profundos que los análisis de detección.
Continúan sondeando un sistema o red objetivo para detectar la presencia de
vulnerabilidades conocidas.
Estas herramientas contienen bases de datos de miles de vulnerabilidades conocidas, junto
con pruebas que pueden realizar para identificar si un sistema es susceptible a cada
vulnerabilidad en la base de datos del sistema.
Cuando el analizador prueba un sistema en busca de vulnerabilidades, utiliza las pruebas
de su base de datos para determinar si un sistema puede contener la vulnerabilidad.
• Falso positivo, el escáner puede no tener suficiente información para determinar de
manera concluyente que existe una vulnerabilidad e informa de una vulnerabilidad
cuando realmente no hay ningún problema.
• Falso negativo, cuando el analizador de vulnerabilidades omite una vulnerabilidad y
no alerta al administrador de la presencia de una situación peligrosa (informe de falso
negativo)
Realización de evaluaciones de
vulnerabilidades
De forma predeterminada, los analizadores de vulnerabilidades de red ejecutan análisis no
autenticados. Prueban los sistemas de destino sin tener contraseñas u otra información
especial que otorgue al escáner privilegios especiales.
Esto permite que el análisis se ejecute desde la perspectiva de un atacante, pero también
limita la capacidad del analizador para evaluar completamente las posibles
vulnerabilidades.
Una forma de mejorar la precisión del escaneo y reducir los informes de falsos positivos y
falsos negativos es realizar escaneos autenticados de los sistemas. En este enfoque, el
analizador tiene acceso de solo lectura a los servidores que se están analizando y puede
utilizar este acceso para leer la información de configuración del sistema de destino y
utilizar esa información al analizar los resultados de las pruebas de vulnerabilidad.
Realización de evaluaciones de
vulnerabilidades
Los resultados del escaneo son muy limpios y
representan un sistema bien mantenido.
No hay vulnerabilidades graves y solo dos
vulnerabilidades de bajo riesgo relacionadas
con el servicio SSH que se ejecuta en el
sistema analizado.
Es posible que el administrador del sistema
desee modificar la configuración de
criptografía SSH para eliminar esas
vulnerabilidades de bajo riesgo, pero este es
un muy buen informe para el administrador y
proporciona confianza en que el sistema está
bien administrado.
Realización de evaluaciones de
vulnerabilidades
3. Análisis de vulnerabilidades web
Las aplicaciones web representan un riesgo significativo para la seguridad empresarial. Las
aplicaciones que se ejecutan en servidores web son complejas y a menudo tienen acceso
privilegiado a las bases de datos subyacentes.
Los atacantes a menudo intentan explotar estas circunstancias utilizando la inyección SQL
y otros ataques que se dirigen a fallas en el diseño de seguridad de las aplicaciones web.
Los escáneres de vulnerabilidades web son herramientas de propósito especial que
rastrean las aplicaciones web en busca de vulnerabilidades conocidas. Desempeñan un
papel importante en cualquier programa de pruebas de seguridad porque pueden descubrir
fallas no visibles para los escáneres de vulnerabilidades de red.
Cuando un administrador ejecuta un análisis de aplicaciones web, la herramienta sondea la
aplicación web mediante técnicas automatizadas que manipulan las entradas y otros
parámetros para identificar vulnerabilidades web.
Luego, la herramienta proporciona un informe de sus hallazgos, que a menudo incluye
técnicas de corrección de vulnerabilidades sugeridas.
Realización de evaluaciones de
vulnerabilidades
Realización de evaluaciones de
vulnerabilidades
Es una buena práctica ejecutar análisis en las siguientes circunstancias
• Analice todas las aplicaciones cuando comience a realizar el análisis de vulnerabilidades
web por primera vez. Esto detectará problemas con las aplicaciones heredadas.
• Escanee cualquier aplicación nueva antes de moverla a un entorno de producción por
primera vez.
• Analice cualquier aplicación modificada antes de que los cambios de código pasen a
producción.
• Analice todas las aplicaciones de forma recurrente. Los recursos limitados pueden
requerir la programación de estos análisis en función de la prioridad de la aplicación
Es posible que se requiera el análisis de aplicaciones web para cumplir con los requisitos
de cumplimiento: PCI DSS.
OWASP proporciona una lista de herramientas comerciales y de código abierto
comúnmente utilizadas para el escaneo de vulnerabilidades de aplicaciones web.
Realización de evaluaciones de
vulnerabilidades
4. Análisis de vulnerabilidades de la base de datos
Las bases de datos contienen parte de la información más confidencial de una
organización y son objetivos lucrativos para los atacantes.
Aunque la mayoría de las bases de datos están protegidas del acceso externo directo
mediante firewalls, las aplicaciones web ofrecen un portal en esas bases de datos, y los
atacantes pueden aprovechar las aplicaciones web respaldadas por bases de datos para
dirigir ataques contra bases de datos, incluidos los ataques de inyección SQL.
Los analizadores de vulnerabilidades de bases de datos son herramientas que permiten a
los profesionales de la seguridad analizar tanto las bases de datos como las aplicaciones
web en busca de vulnerabilidades que puedan afectar a la seguridad de las bases de
datos.
Sqlmap es un analizador de vulnerabilidades de bases de datos de código abierto de uso
común que permite a los administradores de seguridad sondear las aplicaciones web en
busca de vulnerabilidades en las bases de datos.
Realización de evaluaciones de
vulnerabilidades
Flujo de trabajo de gestión de vulnerabilidades

Las organizaciones que adoptan un sistema de gestión de vulnerabilidades también deben

desarrollar un enfoque de flujo de trabajo para gestionar las vulnerabilidades. Los pasos
básicos de este flujo de trabajo deben incluir los siguientes
Detección: La identificación inicial de una vulnerabilidad normalmente tiene lugar
como resultado de un análisis de vulnerabilidades.
Validación: Una vez que un analizador detecta una vulnerabilidad, los administradores
deben confirmar la vulnerabilidad para determinar que no se trata de un informe de
falso positivo.
Corrección: Las vulnerabilidades validadas deben corregirse (parche de seguridad,
configuración, WAF u otros controles)
El objetivo de un enfoque de flujo de trabajo es garantizar que las vulnerabilidades se
detecten y resuelvan de manera ordenada.
El flujo de trabajo también debe incluir pasos que prioricen la corrección de
vulnerabilidades en función de la gravedad de la vulnerabilidad, la probabilidad de
explotación y la dificultad de la corrección.
Pruebas de penetración

La prueba de penetración va más allá de las técnicas de prueba de vulnerabilidad porque

en realidad intenta explotar los sistemas.
Los análisis de vulnerabilidades simplemente investigan la presencia de una vulnerabilidad
y normalmente no toman medidas ofensivas contra el sistema objetivo. Los profesionales
de la seguridad que realizan pruebas de penetración, por otro lado, intentan derrotar los
controles de seguridad e irrumpir en un sistema o aplicación objetivo para demostrar la
falla.
Las pruebas de penetración requieren una atención enfocada de profesionales de
seguridad capacitados, en una medida mucho mayor que los escaneos de
vulnerabilidades.
Al realizar una prueba de penetración, el profesional de la seguridad generalmente se
dirige a un solo sistema o conjunto de sistemas y utiliza muchas técnicas diferentes para
obtener acceso.
NIST define el proceso de pruebas de penetración como el que consta de las cuatro fases:
planificación, recopilación y descubrimiento de información, búsqueda de ataques e
informes.
Pruebas de penetración

Planning incluye un acuerdo sobre el alcance de la prueba y las reglas de enfrentamiento.

Esta es una fase extremadamente importante porque garantiza que tanto el equipo de
pruebas como la gerencia estén de acuerdo sobre la naturaleza de la prueba y su
autorización.
Information gathering and discovery utiliza herramientas manuales y automatizadas
para recopilar información sobre el entorno de destino. Esto incluye realizar un
reconocimiento básico para determinar la función del sistema (como visitar sitios web
alojados en el sistema) y realizar análisis de descubrimiento de red para identificar puertos
abiertos. Los evaluadores también utilizan herramientas automatizadas durante esta fase
para sondear las debilidades del sistema mediante análisis de vulnerabilidades de red,
análisis de vulnerabilidades web y análisis de vulnerabilidades de bases de datos.
Attack seeks utilizar herramientas de explotación manuales y automatizadas para intentar
derrotar la seguridad del sistema. Este paso es donde las pruebas de penetración van más
allá del análisis de vulnerabilidades, ya que los análisis de vulnerabilidades no intentan
explotar realmente las vulnerabilidades detectadas.
Reporting resume los resultados de las pruebas de penetración y hace recomendaciones
para mejorar la seguridad del sistema.
Pruebas de penetración
Pruebas de penetración

Los probadores de penetración

comúnmente usan una herramienta llamada
Metasploit Framework para ejecutar
automáticamente exploits contra sistemas
específicos.
Metasploit Framework, utiliza un lenguaje
de scripting para permitir la ejecución
automática de ataques comunes, ahorrando
a los probadores (¡y hackers!) bastante
tiempo al eliminar muchos de los tediosos
pasos rutinarios involucrados en la
ejecución de un ataque.
Pruebas de penetración

Las pruebas normalmente se clasifican en tres grupos:

White-Box Penetration Test Proporciona a los atacantes información detallada sobre los
sistemas a los que se dirigen. Esto evita muchos de los pasos de reconocimiento que
normalmente preceden a los ataques, acortando el tiempo del ataque y aumentando la
probabilidad de que encuentre fallas de seguridad. Estas pruebas a veces se denominan
pruebas de "entorno conocido".
Gray-Box Penetration Test También conocidas como pruebas de conocimiento parcial, a
veces se eligen para equilibrar las ventajas y desventajas de las pruebas de penetración de
caja blanca y negra. Esto es particularmente común cuando se desean resultados de caja
negra, pero los costos o las limitaciones de tiempo significan que se necesita algún
conocimiento para completar la prueba. Estas pruebas a veces se denominan pruebas de
"entorno parcialmente conocido".
Black-Box Penetration Test No proporciona a los atacantes ninguna información previa al
ataque. Esto simula un atacante externo que intenta obtener acceso a información sobre el
entorno empresarial y técnico antes de participar en un ataque. Estas pruebas a veces se
denominan pruebas de "entorno desconocido".
Pruebas de penetración

Las organizaciones que realizan pruebas de penetración deben tener cuidado de

asegurarse de que entienden los peligros de las pruebas en sí.
Las pruebas de penetración buscan explotar las vulnerabilidades y, en consecuencia,
pueden interrumpir el acceso al sistema o corromper los datos almacenados en los
sistemas.
Esta es una de las principales razones por las que es importante delinear claramente las
reglas de compromiso durante la fase de planificación de la prueba, así como tener una
autorización completa de un nivel de alta gerencia antes de comenzar cualquier prueba.
Comprobaciones de cumplimiento

Las organizaciones se encuentran sujetas a una amplia variedad de requisitos de

cumplimiento.
Las organizaciones inteligentes crean y mantienen planes de cumplimiento que
documentan cada una de sus obligaciones regulatorias y las asignan a los controles de
seguridad específicos diseñados para satisfacer cada objetivo.
Las verificaciones de cumplimiento son una parte importante de las pruebas de seguridad y
los programas de evaluación para las empresas reguladas. Estas comprobaciones verifican
que todos los controles enumerados en un plan de cumplimiento funcionen correctamente y
cumplan efectivamente con los requisitos reglamentarios.
Realizar estas comprobaciones de forma periódica mantiene la salud del programa de
cumplimiento de la organización y evita problemas regulatorios imprevistos.
Pruebas en software

El software es un componente crítico en la seguridad del sistema.

Piense en las siguientes características comunes a muchas aplicaciones en uso en toda la
empresa moderna:
• Las aplicaciones de software a menudo tienen acceso privilegiado al sistema
operativo, hardware y otros recursos.
• Las aplicaciones de software manejan rutinariamente información confidencial,
incluidos números de tarjetas de crédito, números de Seguro Social e información
comercial patentada.
• Muchas aplicaciones de software se basan en bases de datos que también contienen
información confidencial.
• El software es el corazón de la empresa moderna y realiza funciones críticas para el
negocio. Las fallas de software pueden interrumpir las empresas con consecuencias
muy graves.
Pruebas en software

Revisión y pruebas de código

Uno de los componentes más críticos de un programa de pruebas de software es la
realización de revisiones y pruebas de código.
Estos procedimientos proporcionan revisiones de terceros del trabajo realizado por los
desarrolladores antes de mover el código a un entorno de producción.
Las revisiones y pruebas de código pueden descubrir fallas de seguridad, rendimiento o
confiabilidad en las aplicaciones antes de que se activen y tengan un impacto negativo en
las operaciones comerciales
• Code Review
• Static Testing
• Dynamic Testing
• Fuzz Testing
Code Review

La revisión de código (pares) es la base de los programas de evaluación de software.

Los desarrolladores que no sean los que escribieron el código lo revisan en busca de
defectos.
Las revisiones de código pueden dar lugar a la aprobación del traslado de una aplicación a
un entorno de producción, o pueden enviar el código de vuelta al desarrollador original con
recomendaciones para la reelaboración de los problemas detectados durante la revisión.
Los procesos de revisión de código más formales, conocidos como inspecciones Fagan,
siguen un riguroso proceso de revisión y prueba con seis pasos
1. Planificación
2. Visión general
3. Preparación
4. Inspección
5. Reanudación
6. Seguimiento
Code Review

El nivel de formalidad de inspección de Fagan

normalmente se encuentra solo en entornos altamente
restrictivos donde las fallas del código pueden tener un
impacto catastrófico.
La mayoría de las organizaciones utilizan procesos menos
rigurosos, utilizando medidas de revisión por pares de
código que incluyen lo siguiente
• Desarrolladores que recorren su código en una
reunión con uno o más miembros del equipo
• Un desarrollador senior que realiza una revisión
manual del código y firma todo el código antes de
mover el código a producción
• Uso de herramientas de revisión automatizada para
detectar fallos comunes de la aplicación antes de
mover el código a producción
Static Testing

Las pruebas de seguridad de aplicaciones estáticas (SAST) evalúan la seguridad del

software sin ejecutarlo analizando el código fuente o la aplicación compilada.
El análisis estático generalmente implica el uso de herramientas automatizadas diseñadas
para detectar fallas comunes de software, como desbordamientos de búfer.
En entornos de desarrollo maduros, los desarrolladores de aplicaciones tienen acceso a
herramientas de análisis estático y las utilizan durante todo el proceso de diseño,
compilación y prueba.
Dynamic Testing

Las pruebas dinámicas de seguridad de aplicaciones (DAST) evalúan la seguridad del

software en un entorno de tiempo de ejecución y, a menudo, son la única opción para las
organizaciones que implementan aplicaciones escritas por otra persona. En esos casos, los
evaluadores a menudo no tienen acceso al código fuente.
Un ejemplo de pruebas dinámicas de software es el uso de herramientas de escaneo de
aplicaciones web para detectar la presencia de secuencias de comandos entre sitios,
inyección SQL u otras fallas de aplicaciones web.
Las pruebas dinámicas en un entorno de producción siempre deben coordinarse
cuidadosamente para evitar una interrupción involuntaria del servicio.
Las pruebas dinámicas pueden incluir el uso de transacciones sintéticas para verificar el
rendimiento del sistema. Estas son transacciones programadas con resultados esperados
conocidos. Los evaluadores ejecutan las transacciones sintéticas con el código probado y,
a continuación, comparan la salida de las transacciones con el estado esperado. Cualquier
desviación entre los resultados reales y esperados representa posibles fallas en el código y
debe investigarse más a fondo.
Fuzz Testing

Las pruebas Fuzz son una técnica de prueba dinámica especializada que proporciona
muchos tipos diferentes de entrada al software para enfatizar sus límites y encontrar fallas
previamente no detectadas.
El software de prueba Fuzz proporciona entradas no válidas al software, ya sea generadas
aleatoriamente o especialmente diseñadas para desencadenar vulnerabilidades de
software conocidas.
Luego, el probador de fuzz monitorea el rendimiento de la aplicación, observando fallas de
software, desbordamientos de búfer u otros resultados indeseables y / o impredecibles.
Hay dos categorías principales de pruebas de fuzz:
Mutation (Dumb) Fuzzing Toma los valores de entrada anteriores del funcionamiento real
del software y lo manipula (o muta) para crear una entrada borrosa. Puede alterar los
caracteres del contenido, anexar cadenas al final del contenido o realizar otras técnicas de
manipulación de datos.
Generational (Intelligent) Fuzzing Desarrolla modelos de datos y crea nuevas entradas
difusas basadas en la comprensión de los tipos de datos utilizados por el programa.
Fuzz Testing
El archivo de entrada de después de ejecutarse
Archivo de entrada de prefuzzing que contiene una serie de 1s a través de la herramienta de pelusa de mutación zzuf
Pruebas de interfaz

Las pruebas de interfaz son una parte importante del desarrollo de sistemas de software
complejos. En muchos casos, varios equipos de desarrolladores trabajan en diferentes
partes de una aplicación compleja que deben funcionar juntas para cumplir con los
objetivos comerciales.
Se deben probar tres tipos de interfaces durante el proceso de prueba de software:
Application Programming Interfaces (APIs) Ofrecer una forma estandarizada para que
los módulos de código interactúen y puedan estar expuestos al mundo exterior a través de
servicios web.
User Interfaces (UIs) Los ejemplos incluyen interfaces gráficas de usuario (GUI) e
interfaces de línea de comandos. Las interfaces de usuario proporcionan a los usuarios
finales la capacidad de interactuar con el software. Las pruebas de interfaz deben incluir
revisiones de todas las interfaces de usuario para verificar que funcionen correctamente.
Physical Interfaces Algunas aplicaciones que manipulan maquinaria, controladores
lógicos u otros objetos en el mundo físico. Los probadores de software deben prestar
mucha atención a las interfaces físicas debido a las posibles consecuencias si fallan.
Pruebas de casos de uso indebido

En algunas aplicaciones, hay ejemplos claros de formas en que los usuarios de software
pueden intentar hacer un mal uso de la aplicación.
Por ejemplo, los usuarios de software bancario pueden intentar manipular las cadenas de
entrada para obtener acceso a la cuenta de otro usuario. También pueden intentar retirar
fondos de una cuenta que ya está sobregirada.
Los probadores de software utilizan un proceso conocido como prueba de casos de mal
uso o pruebas de casos de abuso para evaluar la vulnerabilidad de su software a estos
riesgos conocidos.
En las pruebas de casos de uso indebido, los evaluadores primero enumeran los casos de
uso indebido conocidos. Luego intentan explotar esos casos de uso con técnicas de ataque
manuales y / o automatizadas.
Análisis de cobertura de pruebas

Las pruebas son una parte importante de cualquier proceso de desarrollo de software,
pero desafortunadamente es imposible probar completamente cualquier pieza de
software.
Simplemente hay demasiadas formas en que el software puede funcionar mal o sufrir un
ataque. Los profesionales de pruebas de software a menudo realizan un análisis de
cobertura de pruebas para estimar el grado de pruebas realizadas contra el nuevo
software.
La cobertura de la prueba se calcula utilizando la siguiente fórmula:

Por supuesto, este es un cálculo altamente subjetivo.

Calcular con precisión la cobertura de las pruebas requiere enumerar los posibles casos de
uso, lo cual es una tarea excepcionalmente difícil.
Análisis de cobertura de pruebas

Por lo tanto, cualquier persona que use cálculos de cobertura de prueba debe tener
cuidado de comprender el proceso utilizado para desarrollar los valores de entrada al
interpretar los resultados.
La fórmula de análisis de cobertura de la prueba puede adaptarse para utilizar muchos
criterios diferentes. Aquí hay cinco criterios comunes:
Branch coverage: ¿Se ha ejecutado cada declaración if bajo todas las condiciones de si y
de otro?
Condition coverage: ¿Se han ejecutado todas las pruebas lógicas en el código bajo todos
los conjuntos de entradas?
Function coverage: ¿Se ha llamado a todas las funciones del código y se han devuelto
resultados?
Loop coverage: ¿Se ha ejecutado cada bucle en el código en condiciones que causan la
ejecución de código varias veces, solo una vez, y no en absoluto?
Statement coverage: ¿Se han ejecutado todas las líneas de código durante la prueba?
Monitoreo de sitios web

Este tipo de monitoreo viene en dos formas diferentes

• El monitoreo pasivo analiza el tráfico de red real enviado a un sitio web
capturándolo a medida que viaja a través de la red o llega al servidor. Esto
proporciona datos de monitoreo del mundo real que brindan a los administradores
información sobre lo que realmente está sucediendo en una red. El monitoreo de
usuarios reales (RUM) es una variante del monitoreo pasivo donde la herramienta de
monitoreo vuelve a ensamblar la actividad de usuarios individuales para rastrear su
interacción con un sitio web.
• El monitoreo sintético (monitoreo activo) realiza transacciones artificiales contra
un sitio web para evaluar el rendimiento. Esto puede ser tan simple como solicitar
una página del sitio para determinar el tiempo de respuesta, o puede ejecutar un
script complejo diseñado para identificar los resultados de una transacción
Estas dos técnicas se utilizan a menudo en conjunto entre sí porque logran resultados
diferentes.
Implementación de procesos de gestión de
seguridad
Además de realizar evaluaciones y pruebas, los programas sólidos de seguridad de la
información también incluyen una variedad de procesos de gestión diseñados para
supervisar el funcionamiento efectivo del programa de seguridad de la información.
Estos procesos son un ciclo de retroalimentación crítico en el proceso de evaluación de la
seguridad porque proporcionan supervisión de la administración y tienen un efecto
disuasorio contra la amenaza de ataques internos.
Las revisiones de administración de seguridad que satisfacen esta necesidad incluyen
• Revisiones de registros
• Gestión de cuentas
• Verificación de copia de seguridad
• Indicadores clave de rendimiento y riesgo
Cada una de estas revisiones debe seguir un proceso estandarizado que incluya la
aprobación de la administración al finalizar la revisión.
Implementación de procesos de gestión de
seguridad
Revisiones de registros
La información de seguridad y los paquetes de gestión de eventos (SIEM) desempeñan un
papel importante en estos procesos, automatizando gran parte del trabajo rutinario de
revisión de registros. Estos dispositivos recopilan información utilizando la funcionalidad
syslog presente en muchos dispositivos, sistemas operativos y aplicaciones. Algunos
dispositivos, incluidos los sistemas Windows, pueden requerir que clientes de terceros
agreguen compatibilidad con syslog. Los administradores pueden optar por implementar
directivas de registro a través de objetos de directiva de grupo (GPO) de Windows y otros
mecanismos que pueden implementar y aplicar directivas estándar en toda la organización.
Los sistemas de registro también deben hacer uso del Protocolo de tiempo de red (NTP)
para garantizar que los relojes estén sincronizados en los sistemas que envían entradas de
registro al SIEM, así como al propio SIEM. Esto garantiza que la información de múltiples
fuentes tenga una línea de tiempo consistente.
Los administradores de seguridad de la información también deben realizar revisiones
periódicas de registros, particularmente para funciones sensibles, para garantizar que los
usuarios privilegiados no abusen de sus privilegios.
Implementación de procesos de gestión de
seguridad
Gestión de cuentas
Las revisiones de administración de cuentas aseguran que los usuarios solo conserven los
permisos autorizados y que no se produzcan modificaciones no autorizadas. Las revisiones
de administración de cuentas pueden ser una función del personal de administración de
seguridad de la información o auditores internos.
1. Los administradores piden a los administradores del sistema que proporcionen una lista
de usuarios con acceso privilegiado y los derechos de acceso privilegiado. Pueden
supervisar al administrador a medida que recuperan esta lista para evitar la manipulación.
2. Los administradores piden a la autoridad de aprobación de privilegios que proporcione
una lista de usuarios autorizados y los privilegios que se les deben asignar.
3. A continuación, los administradores comparan las dos listas para garantizar que solo los
usuarios autorizados conserven el acceso al sistema y que el acceso de cada usuario no
exceda su autorización.
Las organizaciones que no tienen tiempo para llevar a cabo este proceso exhaustivo
pueden utilizar el muestreo en su lugar.
Implementación de procesos de gestión de
seguridad
Formación y sensibilización
Los programas de capacitación y concientización juegan un papel crucial en la preparación
de la fuerza laboral de una organización para apoyar los programas de seguridad de la
información.
Estos esfuerzos educan a los empleados sobre las amenazas actuales y los asesoran
sobre las mejores prácticas para proteger la información y los sistemas bajo su cuidado de
los ataques.
Debe comenzar con la capacitación inicial diseñada para proporcionar conocimientos
fundamentales a los empleados que se unen a la organización o se mudan a una nueva
Los esfuerzos recurrentes de capacitación y concientización deben llevarse a cabo durante
todo el año, recordando a los empleados sus responsabilidades y actualizándolos sobre los
cambios en el entorno operativo de la organización y el panorama de amenazas.
Muchas organizaciones utilizan simulaciones de phishing para evaluar la efectividad de sus
programas de conciencia de seguridad. Los usuarios que hacen clic en el enlace o
responden de otra manera a los ataques simulados son redirigidos a recursos de
capacitación para ayudarlos a identificar mejor la actividad sospechosa.
Implementación de procesos de gestión de
seguridad
Indicadores clave de rendimiento y riesgo
Los gerentes de seguridad también deben monitorear los indicadores clave de rendimiento
y riesgo de forma continua. Las métricas exactas que monitorean pueden incluir las
siguientes:
• Número de vulnerabilidades abiertas
• Es hora de resolver las vulnerabilidades
• Vulnerabilidad/recurrencia de defectos
• Número de cuentas comprometidas
• Número de fallos de software detectados en el escaneo de preproducción
• Repetir los resultados de la auditoría
• Intentos del usuario de visitar sitios maliciosos conocido
Es posible que los gerentes deseen desarrollar un panel que muestre los valores de estas
métricas a lo largo del tiempo y mostrarlo donde tanto los gerentes como el equipo de
seguridad lo verán regularmente.
Resumen

Los programas de evaluación y prueba de seguridad desempeñan un papel fundamental

para garantizar que los controles de seguridad de una organización sigan siendo efectivos
a lo largo del tiempo. Los cambios en las operaciones comerciales, el entorno técnico, los
riesgos de seguridad y el comportamiento del usuario pueden alterar la efectividad de los
controles que protegen la confidencialidad, integridad y disponibilidad de los activos de
información. Los programas de evaluación y prueba supervisan esos controles y destacan
los cambios que requieren la intervención del administrador. Los profesionales de la
seguridad deben diseñar cuidadosamente su programa de evaluación y pruebas y revisarlo
a medida que cambian las necesidades comerciales.
Las técnicas de prueba de seguridad incluyen evaluaciones de vulnerabilidad y pruebas de
software. Con las evaluaciones de vulnerabilidad, los profesionales de la seguridad realizan
una variedad de pruebas para identificar configuraciones erróneas y otras fallas de
seguridad en sistemas y aplicaciones. Las pruebas de detección de redes identifican
sistemas en la red con puertos abiertos. Los análisis de vulnerabilidades de red descubren
fallas de seguridad conocidas en esos sistemas. Los análisis de vulnerabilidades web
sondean el funcionamiento de las aplicaciones web en busca de vulnerabilidades
conocidas.
Resumen

El software desempeña un papel fundamental en cualquier infraestructura de seguridad

porque maneja información confidencial e interactúa con recursos críticos. Las
organizaciones deben utilizar un proceso de revisión de código para permitir la validación
por pares del código antes de moverlo a producción. Los rigurosos programas de pruebas
de software también incluyen el uso de pruebas estáticas, pruebas dinámicas, pruebas de
interfaz y pruebas de casos de mal uso para evaluar sólidamente el software.
Los procesos de gestión de la seguridad incluyen revisiones de registros, administración de
cuentas, verificación de copias de seguridad y seguimiento de indicadores clave de
rendimiento y riesgo. Estos procesos ayudan a los gerentes de seguridad a validar la
efectividad continua del programa de seguridad de la información. Se complementan con
auditorías internas y externas formales realizadas por terceros con menos frecuencia.
Preguntas de revisión

1. ¿Cuál de las siguientes herramientas se utiliza principalmente para realizar análisis de

detección de redes
A. Nmap
B. OpenVAS
C. Marco metasploit
D. lsof
Preguntas de revisión

2. Adam ejecutó recientemente un análisis de puerto de red de un servidor web que se

ejecuta en su organización. Ejecutó el escaneo desde una red externa para obtener la
perspectiva de un atacante sobre el escaneo. ¿Cuál de los siguientes resultados es la
mayor causa de alarma
A. 80/abierto
B. 22/filtrado
C. 443/abierto
D. 1433/abierto
Preguntas de revisión

3. ¿Cuál de los siguientes factores no se debe tener en cuenta al planificar un programa

de pruebas de seguridad para un sistema en particular
A. Sensibilidad de la información almacenada en el sistema
B. Dificultad para realizar la prueba
C. Deseo de experimentar con nuevas herramientas de prueba
D. Conveniencia del sistema para los atacante
Preguntas de revisión

4. ¿Cuál de las siguientes opciones no se incluye normalmente en una evaluación de

seguridad
A. Análisis de vulnerabilidades
B. Evaluación de riesgos
C. Mitigación de vulnerabilidades
D. Evaluación de amenaza
Preguntas de revisión

5. ¿Quién es el público al que va dirigido un informe de evaluación de seguridad?

A. Administración
B. Auditor de seguridad
C. Profesional de la seguridad
D. Cliente
Preguntas de revisión

6. Wendy está considerando el uso de un escáner de vulnerabilidades en su

organización. ¿Cuál es la función adecuada de un escáner de vulnerabilidades?
A. Analizan activamente en busca de intentos de intrusión.
B. Sirven como una forma de tentación.
C. Localizan agujeros de seguridad conocidos.
D. Reconfiguran automáticamente un sistema a un estado más seguro.
Preguntas de revisión

7. Alan ejecutó un análisis nmap contra un servidor y determinó que el puerto 80 está
abierto en el servidor. ¿Qué herramienta probablemente le proporcionaría la mejor
información adicional sobre el propósito del servidor y la identidad del operador del
servidor?
1. SSH
2. Navegador
3. Telnet
4. Señal
Preguntas de revisión

8. ¿Qué puerto se utiliza normalmente para aceptar conexiones administrativas mediante

la utilidad SSH?
A. 20
B. 22
C. 25
D. 80
Preguntas de revisión

9. ¿Cuál de las siguientes pruebas proporciona la información más precisa y detallada

sobre el estado de seguridad de un servidor?
A. Análisis no autenticado
B. Escaneo de puertos
C. Escaneo semiabierto
D. Análisis autenticado
Preguntas de revisión

10. ¿Qué tipo de análisis de detección de redes solo utiliza los dos primeros pasos del
protocolo de enlace TCP?
A. Análisis de conexión TCP
B. Exploración de Navidad
C. Análisis TCP SYN
D. Análisis TCP ACK
Preguntas de revisión

11. A Matthew le gustaría probar los sistemas en su red para detectar vulnerabilidades de
inyección SQL. ¿Cuál de las siguientes herramientas sería la más adecuada para esta
tarea?
A. Escáner de puertos
B. Analizador de vulnerabilidades de red
C. Analizador de detección de redes
D. Analizador de vulnerabilidades web
Preguntas de revisión

12. Badin Industries ejecuta una aplicación web que procesa pedidos de comercio
electrónico y maneja transacciones con tarjeta de crédito. Como tal, está sujeto al
Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS). La
compañía realizó recientemente un escaneo de vulnerabilidad web de la aplicación y
no tuvo hallazgos insatisfactorios. ¿Con qué frecuencia debe Badin volver a escanear
la aplicación?
A. Sólo si la aplicación cambia
B. Al menos mensualmente
C. Al menos una vez al año
D. No hay ningún requisito de reescaneo
Preguntas de revisión

13. Grace está realizando una prueba de penetración contra la red de un cliente y le
gustaría usar una herramienta para ayudar a ejecutar automáticamente exploits
comunes. ¿Cuál de las siguientes herramientas de seguridad satisfará mejor sus
necesidades?
A. nmap
B. Marco metasploit
C. OpenVAS
D. Nadie
Preguntas de revisión

14. A Paul le gustaría probar su aplicación contra versiones ligeramente modificadas de la

entrada utilizada anteriormente. ¿Qué tipo de prueba tiene pablo la intención de
realizar?
A. Revisión de código
B. Revisión de vulnerabilidades de aplicaciones
C. Fuzzing de mutaciones
D. Fuzzing generacional
Preguntas de revisión

15. Los usuarios de una aplicación bancaria pueden intentar retirar fondos que no existen
de su cuenta. Los desarrolladores son conscientes de esta amenaza y el código
implementado para protegerse contra ella. ¿Qué tipo de prueba de software
probablemente detectaría este tipo de vulnerabilidad si los desarrolladores aún no la
han remediado?
A. Pruebas de casos de uso indebido
B. Pruebas de inyección SQL
C. Fuzzing
D. Revisión de código
Preguntas de revisión

16. ¿Qué tipo de prueba de interfaz identificaría fallas en la interfaz de línea de comandos
de un programa?
A. Pruebas de interfaz de programación de aplicaciones
B. Pruebas de interfaz de usuario
C. Pruebas de interfaz física
D. Pruebas de interfaz de seguridad
Preguntas de revisión

17. ¿Durante qué tipo de prueba de penetración el probador siempre tiene acceso a la
información de configuración del sistema?
A. Prueba de penetración de caja negra
B. Prueba de penetración de caja blanca
C. Prueba de penetración de caja gris
D. Prueba de penetración de caja roja
Preguntas de revisión

18. ¿Qué puerto suele estar abierto en un sistema que ejecuta un servidor HTTP sin cifrar?
A. 22
B. 80
C. 143
D. 443
Preguntas de revisión

19. Robert recientemente completó un compromiso SOC para un cliente y está preparando
un informe que describe la opinión de su empresa sobre la idoneidad y efectividad de
los controles de seguridad después de evaluarlos durante un período de seis meses.
¿Qué tipo de informe está preparando?
A. Tipo I
B. Tipo II
C. Tipo III
D. Tipo IV
Preguntas de revisión

20. ¿Qué tarea de administración de seguridad de la información garantiza que los

requisitos de protección de datos de la organización se cumplan de manera efectiva?
A. Gestión de cuentas
B. Verificación de copia de seguridad
C. Revisión de registros
D. Indicadores clave de rendimiento