Unidad 4.

1 Comunicaciones inalámbricas, control de acceso y diseños de red

4.1.1 Protocolos wifi, vulnerabilidades en wifi y medidas de protección en wifi

Uno de los medios de comunicación más utilizados son las redes inalámbricas, ya sea
en nuestros hogares y oficinas, o en establecimientos públicos. El estándar 802.11
define las características de las WLAN (wireless local area network), es decir, de las
redes inalámbricas de alcance local. Este estándar tiene varias derivaciones. Intel
hace un pequeño resumen de los protocolos en la siguiente tabla:
Tabla 1: Resumen de protocolo de wi-fi IEEE 802.11

Ancho del MIMO Velocidad de

Protocolo Protocolo canal datos máxima
(teórico)
802.11ac wave2 5 GHz. 80, 80+ 80, Usuario múltiple 1.73 Gbps.
160 MHz. (MIMO-MU).
802.11ac wave1 5 GHz. 80 MHz. Un solo usuario 866.7 Mbps.
(SU-MIMO).
802.11g 2.4 GHz. 20 MHz. No se aplica. 54 Mbps.
802.11a 5 GHz. 20 MHz. No se aplica. 54 Mbps.
802.11b 2.4 GHz. 20 MHz. No se aplica. 11 Mbps.
Tradicional 2.4 GHz. 20 MHz. No se aplica. 2 Mbps.
802.11
Fuente: Intel Latin America, 2017, https://goo.gl/dn3CVN
Dentro de la comunicación inalámbrica, la arquitectura o el diseño de red más
frecuentemente utilizado es el modo infraestructura, que viene por defecto configurado
en los AP (access point) o router inalámbrico. De acuerdo con este modo, los clientes
o usuarios, para poder estar en la red, deben conectarse al AP (access point) o router
inalámbrico, que permite que puedan comunicarse entre todos los dispositivos
conectados a él.

Hay que tener en cuenta que las redes inalámbricas son redes de medios
compartidos. Esto quiere decir que el ancho de banda del medio es compartido con
todos los integrantes de la red, bien sea para la comunicación entre los participantes
de esa red, o para comunicaciones con otras redes, como Internet. En las redes
inalámbricas, no solo debemos cuidar el ancho de banda, sino también otros recursos
que se encuentren expuestos en las redes accesibles desde esta red. Es por ello que
existe una gran variedad de protocolos que sirven para autenticar a los usuarios que
desean conectarse a estas redes wifi. A continuación, describiremos los protocolos
usados para dicha protección:

• WEP (Wired Equivalent Privacy): este sistema de cifrado fue el primer

protocolo de cifrado incluido en el estándar 802.11, y en su momento contaba
con algoritmos de cifrado RC4, que podían tener llaves de 64 bits o 128 bits de
 longitud para cifrar la información que se transmitía. Este protocolo posee poca
seguridad, debido al uso de su vector de inicialización de 24 bits. Utiliza una
clave maestra estática, que es la configurada en los routers o AP (access
point).
• WPA (Wifi Protected Access): este protocolo surge de forma temporal, con la
idea de subsanar las deficiencias que tenía el sistema WEP. Mantiene el uso
del algoritmo de cifrado RC4, pero introduce cuatro vectores de inicialización
más grandes, en conjunto con una clave de 256 bits. Posee dos tipos de
implementaciones:
o WPA-Personal: para este, se utilizan claves precompartidas. Se lo
suele denominar WPA-TKIP.
o WPA-Enterprise: para este, se requiere un servidor de autenticación y
se hace uso de protocolos como 802.1x y EAP.
• WPA2: protocolo que surge con el estándar 802.11i. Sustituye RC4 y TKIP con
CCMP, e incorpora el algoritmo AES (Advanced Encryptation Standard), con el
fin de fortalecer la autenticación y el cifrado usados. Al igual que WPA, también
puede implementárselo de dos formas:
o WPA2-Personal;
o WPA2-Enterprise.

4.1.2 Autenticación de personas y control de acceso lógico: fundamentos de

AAA
AAA (Authentication, Authorization and Accounting) implica la aplicación de un
conjunto de protocolos que brinden estas características de seguridad de manera
integrada y como un solo sistema. A continuación, definiremos cada una de estas
características que conforman el AAA, tal como lo define el RFC3539:
Autenticación
En su “RFC 3539”, el IETF (2003) define la autenticación como: “The act of verifying a
claimed identity, in the form of a pre-existing label from a mutually known name space,
as the originator of a message (message authentication) or as the end-point of a
channel (entity authentication)” (p. 3). Esto se traduce como “El acto de verificar una
identidad reivindicada, en forma de una etiqueta preexistente de un espacio conocido
mutuamente, como originador de un mensaje (autenticación de mensajes) o punto final
de un canal (autenticación de entidad)” (traducción propia). Por eso, se lo puede
entender como el mecanismo utilizado para validar la identidad de una entidad ante
otra. Comúnmente, la primera entidad es un cliente (usuario, ordenador, etc.) y, la
segunda, un servidor (ordenador). El proceso de autenticación se puede sintetizar en
los siguientes pasos:

• Entrega de credenciales del usuario que se va a autenticar.

• Verificación de las credenciales en la base de datos de usuarios.
• Aceptación o denegación de acceso al usuario a los servicios solicitados.

Autorización
En su “RFC 3539”, el IETF (2003) define la autorización como: “The act of determining
if a particular right, such as access to some resource, can be granted to the presenter
of a particular credential” (p. 3). Esto se traduce como “El acto de determinar si un
derecho particular, como acceso a algún recurso, se puede conceder al presentador
de una credencial particular” (traducción propia). Entonces, decimos que la
autorización se entiende como el otorgamiento de privilegios o permisos a un usuario
para que este efectúe acciones dentro de un sistema.
Las autorizaciones a un sistema también pueden establecerse mediante la aplicación
de restricciones, tales como:

• restricciones horarias;
• la geolocalización del usuario solicitante;
• la limitación de la cantidad de sesiones simultáneas con un mismo usuario.

Contabilización (Accounting)
En su “RFC 3539”, el IETF (2003) define la contabilización de la siguiente manera:
“The act of collecting information on resource usage for the purpose of trend analysis,
auditing, billing, or cost allocation” (p. 2). Esto se traduce como “La recopilación de
información sobre el uso de los recursos objetivo de análisis de tendencias, auditoría,
facturación o asignación” (traducción propia)

Entendemos que, al hablar de accounting (contabilización), se hace referencia al

registro de las acciones efectuadas en el sistema.
Lista de protocolos AAA:

• RADIUS;
• Kerberos;
• LDAP/OpenLDAP.

4.1.3 Fundamentos de Kerberos

Kerberos fue creado por el Massachusetts Institute of Technology o MIT, que lo define
de la siguiente manera:
Kerberos is a network authentication protocol. It is designed to provide strong
authentication for client/server applications by using secret-key cryptography. A free
implementation of this protocol is available from the Massachusetts Institute of
Technology. Kerberos is available in many commercial products as well... Kerberos
was created by MIT as a solution to these network security problems. The Kerberos
protocol uses strong cryptography so that a client can prove its identity to a server (and
vice versa) across an insecure network connection. After a client and server has used
Kerberos to prove their identity, they can also encrypt all of their communications to
assure privacy and data integrity as they go about their business. (P. 1).
De acuerdo con la cita del MIT, podemos decir que el protocolo Kerberos fue diseñado
con la finalidad de brindar un proceso de autenticación de usuario en la red que sea
seguro. Kerberos trabaja bajo un modelo cliente/servidor y hace uso de la criptografía
de clave secreta. La versión actual del protocolo es la versión 5, descrita en “RFC
4120” (2005). Varias implementaciones gratuitas de este protocolo están disponibles y
cubren una amplia gama de sistemas operativos. En resumen, Kerberos es una
solución a sus problemas de seguridad de red. Proporciona las herramientas de
autenticación y una fuerte criptografía sobre la red, para ayudarle a asegurar sus
sistemas de información a través de su empresa entera. Esperamos que encuentre a
Kerberos tan útil como lo ha sido para nosotros. En MIT, Kerberos ha sido invaluable
para nuestra arquitectura de Información/Tecnología
Cómo funciona Kerberos
En el “RFC 4120” del IETF (2005), se describe de forma general cómo funciona el
protocolo Kerberos:
The basic Kerberos authentication process proceeds as follows: A client sends a
request to the authentication server (AS) for "credentials" for a given server. The AS
responds with these credentials, encrypted in the client's key. The credentials consist
of a "ticket" for the server and a temporary encryption key (often called a "session
key"). The client transmits the ticket (which contains the client's identity and a copy of
the session key, all encrypted in the server's key) to the server. The session key (now
shared by the client and server) is used to authenticate the client and may optionally be
used to authenticate the server. It may also be used to encrypt further communication
between the two parties or to exchange a separate sub-session key to be used to
encrypt further communication...

There are two basic methods by which a client can ask a Kerberos server for
credentials. In the first approach, the client sends a cleartext request for a ticket for the
desired server to the AS. The reply is sent encrypted in the client's secret key. Usually
this request is for a ticket-granting ticket (TGT), which can later be used with the ticket-
granting server (TGS). In the second method, the client sends a request to the TGS.
The client uses the TGT to authenticate itself to the TGS in the same manner as if it
were contacting any other application server that requires Kerberos authentication. The
reply is encrypted in the session key from the TGT. Though the protocol specification
describes the AS and the TGS as separate servers, in practice they are implemented
as different protocol entry points within a single Kerberos server. (P. 6).
Esto se traduce como:
El proceso básico de autenticación de Kerberos procede de la siguiente manera: Un
cliente envía una solicitud al servidor de autenticación (AS) con credenciales para un
servidor determinado. El AS responde con estas credenciales, cifradas en la clave del
cliente. Las credenciales consisten en un "ticket" para el servidor y una clave de
cifrado temporal (a menudo llamada "clave de sesión"). El cliente transmite el ticket
(que contiene la identidad del cliente y una copia de la clave de sesión, todas
encriptadas en la clave del servidor) al servidor. La clave de sesión (ahora compartida
por el cliente y el servidor) se utiliza para autenticar al cliente y opcionalmente puede
usarse para autenticar el servidor. También puede usarse para cifrar la comunicación
adicional entre las dos partes o para intercambiar una clave de sub-sesión separada
que se utilizará para cifrar la comunicación adicional.

Existen dos métodos básicos por los cuales un cliente puede solicitar a un servidor
Kerberos credenciales. En la primera aproximación, el cliente envía una petición de
texto claro para un ticket para el servidor deseado al AS. La respuesta se envía cifrada
en la clave secreta del cliente. Por lo general, esta solicitud es para un ticket de
concesión de billetes (TGT), que puede utilizarse posteriormente con el servidor de
concesión de billetes (TGS). En el segundo método, el cliente envía una solicitud al
TGS. El cliente utiliza el TGT para autenticarse en el TGS de la misma manera que si
estuviera en contacto con cualquier otro servidor de aplicaciones que requiera la
autenticación Kerberos. La respuesta se cifra en la clave de sesión del TGT. Aunque la
especificación del protocolo describe el AS y el TGS como servidores separados, en la
práctica se implementan como diferentes puntos de entrada de protocolo dentro de un
único servidor Kerberos. (traducción propia).
En resumen, se puede decir que el protocolo Kerberos está basado en el protocolo de
autenticación Needham y Schroeder, pero con cambios que lo ajustan a las
necesidades del entorno para el que se desarrolló. Entre estos cambios se encuentran
el uso de marcas de tiempo, que reduce el número de mensajes necesarios para la
autenticación básica, la adición de un servicio de "concesión de boletos", para
respaldar la autenticación posterior sin volver a ingresar la contraseña de un director, y
la autenticación entre realidades (autenticación de un principal registrado con un
servidor de autenticación diferente del verificador).
Figura 1: Cómo trabaja Kerberos

Fuente: Sonck, 2014, https://goo.gl/UPtbLU

El ticket de Kerberos
El cliente y el servidor no comparten inicialmente una clave de cifrado. Cada vez que
un cliente se autentica a un nuevo verificador, se basa en el servidor de autenticación
para generar una nueva clave de cifrado y distribuirla de forma segura a ambas partes.
Esta nueva clave de cifrado se llama clave de sesión. Además, se utiliza
el ticket Kerberos para distribuirlo al verificador. El ticket Kerberos es un certificado
emitido por un servidor de autenticación, cifrado mediante la clave del servidor. Entre
otras informaciones, este boleto contiene la clave de sesión aleatoria que se utilizará
para la autenticación del principal para el verificador, el nombre del principal a quien se
ha emitido la clave de sesión, y un tiempo de caducidad después del cual la clave de
sesión ya no es válida. El ticket no se envía directamente al verificador, sino que se
envía al cliente que lo remite al verificador como parte de la solicitud de aplicación.
Dado que el ticket está encriptado en la clave del servidor, conocido solo por el
servidor de autenticación y el verificador previsto, no es posible que el cliente lo
modifique sin ser detectado.
4.1.4 Fundamentos de RADIUS
RADIUS es un protocolo de red que proporciona administración centralizada de
autenticación, autorización y contabilidad (AAA) para los usuarios que conectan y
utilizan un servicio de red. Debido al amplio respaldo y al carácter omnipresente del
protocolo RADIUS, los proveedores de servicios de Internet (ISP) y las empresas
suelen utilizarlo para gestionar el acceso a Internet o a redes internas, redes
inalámbricas y servicios integrados de correo electrónico. RADIUS es un protocolo
cliente/servidor que se ejecuta en la capa de aplicación y puede utilizar TCP o UDP
como transporte. Los servidores de acceso a la red, es decir, las pasarelas que
controlan el acceso a una red, normalmente contienen un componente de cliente
RADIUS que se comunica con el servidor RADIUS. RADIUS es también, a menudo, el
back-end de elección para la autenticación 802.1X.

De acuerdo al “RFC 2865” (IETF, 2000b), las características clave de RADIUS son:
Key features of RADIUS are:

Client/Server Model:
A Network Access Server (NAS) operates as a client of RADIUS. The client is
responsible for passing user information to designated RADIUS servers, and then
acting on the response which is returned. RADIUS servers are responsible for
receiving user connection requests, authenticating the user, and then returning all
configuration information necessary for the client to deliver service to the user. A
RADIUS server can act as a proxy client to other RADIUS servers or other kinds of
authentication servers.

Network Security:
Transactions between the client and RADIUS server are authenticated through the use
of a shared secret, which is never sent over the network. In addition, any user
passwords are sent encrypted between the client and RADIUS server, to eliminate the
possibility that someone snooping on an unsecure network could determine a user's
password.

Flexible Authentication Mechanisms:

The RADIUS server can support a variety of methods to authenticate a user. When it is
provided with the user name and original password given by the user, it can support
PPP PAP or CHAP, UNIX login, and other authentication mechanisms.

Extensible Protocol:
All transactions are comprised of variable length Attribute-Length-Value 3-tuples. New
attribute values can be added without disturbing existing implementations of the
protocol. (P. 4).
Si traducimos y resumimos el contenido de este texto, tenemos que las principales
características de RADIUS son:
Modelo cliente/servidor

• El cliente es quien se encarga de enviar los datos del usuario a los RADIUS
servidores.
• Los servidores reciben las solicitudes, efectúan el proceso de validar las
credenciales y, luego, devuelven al cliente información de configuración
necesaria.
 • Un servidor RADIUS también puede actuar como un cliente proxy para otros
servidores RADIUS o para otros tipos de servidores de autenticación.

Seguridad de la red
Las operaciones de autenticado entre el cliente y el servidor RADIUS son efectuadas
mediante el uso de claves secretas compartidas. Las credenciales de los usurarios se
envían de manera cifrada entre el cliente y el servidor RADIUS.
Mecanismos flexibles de autenticación
El protocolo RADIUS soporta diversidad de métodos para realizar el proceso de
autenticación de usuarios. Algunos de los métodos más comúnmente utilizados son
PA o CHAP, del protocolo de interconexión PPP (Point-to-Point-Protocol).
Protocolo extensible
Todas las operaciones de autenticación se componen de longitud variable Atributo-
Longitud-Valor 3-tuplas. También es posible agregar nuevos valores de atributo, sin
perturbar las implementaciones existentes del protocolo.
Figura 2: Operación de servidor RADIUS en ambiente Wireless
Fuente: Microsoft, 2007, https://goo.gl/KB22dk
Video conceptual 1
Unidad 4.2 Arquitectura de seguridad

4.2.1 Diseños de red

El diseño de red depende de varios factores. Aunque las redes puedan tener
similitudes, no deberían ser iguales, ya que el propósito principal del negocio varía, y
esto influye en la toma de decisiones y políticas de la configuración de la red. A pesar
de cada red es única, existen recomendaciones generales que ayudan a dimensionar
e inventar arquitecturas de red que permitan crear buenos diseños y mejoren el
desempeño, la seguridad y otros factores que necesite la red. Para un buen diseño de
la red, se recomienda seguir un modelo de red jerárquico, con la finalidad de lograr
una alta disponibilidad. En un diseño jerárquico, la capacidad, las características y la
funcionalidad de un dispositivo específico se optimizan para su posición en la red y
para el papel que desempeña. Esto promueve la escalabilidad y la estabilidad. Si la
base de la red no es sólida, el rendimiento de las aplicaciones que dependen de los
servicios de red, como la telefonía IP, el video IP y las comunicaciones inalámbricas,
sufrirá en el futuro.

Desde el punto de vista del diseño, existen tres capas fundamentales en el modelo de
red jerárquico:

• Capa de acceso: es usada para brindarle o darle acceso de red a los

dispositivos. Esta capa de acceso puede tener varios enfoques, dependiendo
de si es una red de campus, una red WAN o una red LAN. En una red campus,
la capa de acceso incorpora switches LAN con puertos que proveen
conectividad a estaciones de trabajo y servidores. En un ambiente WAN la
capa de acceso en un sitio remoto puede proveer acceso a redes corporativas
a través de tecnologías WAN.
• Capa de distribución: la capa de distribución une cuartos de cableado y usa
switches para segmentar estaciones de trabajo y separar o aislar problemas de
red.
• Capa core o central: esta capa es diseñada para conmutar paquetes lo más
rápido posible. Debe proveer alta disponibilidad, ya que este es un punto crítico
para la afectación de la red, y debe tener aceptación de cambios de manera
rápida.

Figura 3: Diseño de red jerárquico

Fuente: Tomaszewski, 2013, https://goo.gl/odYqPm

Por otro lado, en el diseño de red también hay tipos de áreas que son definidas según
su funcionalidad:

• Área funcional de campus: contiene los módulos necesarios para construir

una red de campus jerárquica y altamente robusta, que ofrezca rendimiento,
escalabilidad y disponibilidad. Esta área contiene los elementos de red
necesarios para una operación independiente dentro de un solo campus, como
el acceso de todos los lugares a servidores. El área funcional de campus no
ofrece conexiones remotas o acceso a Internet.
• Área funcional de extremo o edge: agrega la conectividad de los diversos
recursos externos a la red de la empresa. A medida que el tráfico llega al
campus, esta área filtra el tráfico desde los recursos externos y lo encamina al
área funcional del campus empresarial. Contiene todos los elementos de red
para una comunicación eficiente y segura entre el campus de la empresa y las
ubicaciones remotas, los usuarios remotos e Internet. La empresa edge
reemplazaría a la zona desmilitarizada (DMZ) de la mayoría de las redes.
• Área funcional de extremo proveedores de servicio: esta área funcional
representa conexiones a recursos externos al campus, y facilita la
comunicación con la WAN y el proveedor de servicios de tecnologías de
Internet.

Dentro de las áreas funcionales existen subdivisiones por módulos, por ejemplo, para
el área funcional del campus se incluye:

• Módulo de campus de infraestructura: incluye los submódulos de

distribución y acceso. Conecta a los usuarios que están dentro del campus con
la granja de servidores y con el módulo de distribución de bordes o extremos
(edge). El módulo de infraestructura de campus se compone de uno o más
pisos o edificios, conectados al submódulo del backbone del campus.
• Módulo de gestión de red: realiza el registro y la autenticación del sistema,
así como el monitoreo de la red y funciones generales de administración y
configuración.
• Módulo de la granja de servidores: contiene servidores de correo electrónico
y corporativos que proporcionan aplicaciones, archivos, impresión, correo
electrónico y sistemas de nombres de dominio (DNS) a los usuarios internos.
• Módulo de distribución de bordes: agrega la conectividad de los distintos
elementos al área funcional de edge empresarial y las rutas del tráfico en la
columna vertebral del campus submódulo.

El módulo de infraestructura de campus conecta a los usuarios con el módulo de

distribución de bordes y con la granja de servidores. Un módulo de infraestructura de
campus incluye estos submódulos:

• Building access (también conocido como capa de acceso): contiene el usuario

final, estaciones de trabajo, teléfonos IP y switches de acceso de capa 2. La
capa de acceso realiza servicios tales como soporte para VLAN múltiples,
VLAN privadas, y el establecimiento de enlaces troncales entre las capas de
distribución del edificio.
• Módulo de distribución (también conocido como capa de distribución):
 1. realiza el enrutamiento;
2. el QoS;
3. y el control de acceso.

Figura 4: Red jerárquica por módulos

Fuente: Elaboración propia

4.2.2 Adquisición de equipos
Al momento de adquirir cualquier dispositivo para nuestra red, debemos contemplar y
evaluar un conjunto de criterios que pueden ayudarnos a tomar la decisión sobre qué
categoría y marca comprar:

1. Características del dispositivo: podemos crear una matriz o tabla

comparativa entre los dispositivos que queremos evaluar y las características
que deseamos que tenga el equipo que quisiéramos comprar. Por ejemplo,
para el caso de un firewall de nueva generación, habría que evaluar si posee
inspección de paquetes, funciones de IDS/IPS, filtrado web, etcétera.
2. Desempeño: debido a que los equipos de red y de seguridad traen varias
funcionalidades, es recomendable evaluar y comparar el desempeño que los
dispositivos estudiados tienen al activar determinadas funcionalidades. Esto es
de mucha importancia, ya que muchas veces, se suele comprar un dispositivo
con algún fin y luego se le agregan otras funcionalidades estando en
producción. Tras realizar estos cambios, se suele observar lentitud en la red.
3. Manejabilidad: también es bueno tomar en cuenta este criterio, ya que nos
indica qué tan fácil podría ser la incorporación del equipo a nuestra red, y cuán
fácil es su uso en relación con nuestro equipo de trabajo. Si se incorpora un
dispositivo que presenta buenas características y un buen desempeño, pero
 nuestro equipo no está capacitado para operarlo, realmente no estamos
aprovechando la nueva adquisición.
4. Precio: no menos importante, esto es algo a lo que siempre se le da una alta
prioridad al momento de adquirir un equipo. Sin embargo, para saber si adquirir
este equipo significa o no un aporte, es bueno tomar en cuenta la criticidad o el
impacto que implicaría para nuestro negocio no adquirirlo.
5. Soporte: siempre es bueno contar con un soporte para los equipos que
poseemos, porque siempre surgen mejoras y actualizaciones de los softwares
en los equipos, que ayudan a mitigar las vulnerabilidades y bugs que, con el
tiempo, se van presentando.

4.2.3 Centralización de eventos o logs

Syslog
En sus términos más simplistas, el protocolo syslog proporciona un transporte para
permitir que una máquina envíe mensajes de notificación de eventos a través de las
redes IP a los recopiladores de mensajes de sucesos, también conocidos como syslog
servidores. Dado que cada proceso, aplicación y sistema operativo está escrito de
manera algo independiente, hay poca uniformidad en el contenido de los mensajes
syslog. Por esta razón, no se hace ninguna suposición sobre el formato o el contenido
de estos. El protocolo es simplemente diseñado para transportar estos mensajes de
eventos. En todos los casos, hay un dispositivo que origina el mensaje. El proceso
syslog en esa máquina puede enviar el mensaje a un colector. No se hace constar el
acuse de recibo. Uno de los principios fundamentales del protocolo y del proceso
syslog es su sencillez. No se requiere coordinación estricta entre transmisores y
receptores. De hecho, la transmisión de syslog pueden iniciarse con mensajes desde
un dispositivo sin que sea configurado, o incluso físicamente presente. Por el contrario,
es mucho más probable que los dispositivos puedan recibir mensajes sin configuración
o definiciones. Esta sencillez ha ayudado mucho la aceptación y el despliegue de
syslog.

Los mensajes de los eventos deben tener una clasificación para indicar su origen
(facility) y una categorización para expresar el tipo de mensaje (severy). La
clasificación es numérica y se expresa como se indica acorde al “RFC 3164” (IETF,
2001):
Numerical Facility

Code

0 → mensajes de kernel

1→ mensajes a nivel de usuario

2 → mensajes de sistema de correo

3 → mensajes de sistemas de demonios o servicios

4 → mensajes de seguridad y autorización

5 → mensajes generados internamente por el syslog

6 → mensajes de línea del subsistema de impresión

7 → mensajes de subsistema de redes de noticias

8→ mensajes de UUCP

9 → mensajes de clock daemon

10 → mensajes de mensaje de seguridad y autorización

11 → mensajes de demonio de FTP (File Transfer Protocol)

12 → mensajes de demonio de NTP (Network Protocol)

13 → mensajes log de auditoría

14 → mensajes log de alerta

15→ mensajes clock daemon

16 → mensajes de uso local 0 (local 0)

17 → mensajes de uso local 1 (local 1)

18 → mensajes de uso local 2 (local 2)

19 → mensajes de uso local 3 (local 3)

20 → mensajes de uso local 4 (local 4)

21 → mensajes de uso local 5 (local 5)

22 → mensajes de uso local 6 (local 6)

23 → mensajes de uso local 7 (local 7)

Table 1. syslog Message Facilities.

Numerical Severity

Code

0 Emergency: system is unusable

1 Alert: action must be taken immediately

2 Critical: critical conditions

3 Error: error conditions

4 Warning: warning conditions

5 Notice: normal but significant condition

6 Informational: informational messages

7 Debug: debug-level messages.

Table 2. syslog Message Severities. (P. 9).

SIEM:
Security information and event management (SIEM) son soluciones de seguridad
que se encargan de recoger los registros de varios dispositivos (servidores, firewall,
routers, etc.). Además, correlacionan los datos, proporcionan una mejor capacidad de
análisis, y muestran los resultados de forma organizada, con clasificación de eventos.
Los sistemas SIEM tienen la capacidad de procesar un gran número de eventos y, de
acuerdo con las configuraciones que posean, envían notificaciones sobre los fallos de
seguridad encontrados. Revisar manualmente y de manera continua los registros de la
búsqueda de actividad sospechosa no solo es molesto, sino que es casi imposible
tener éxito. Los formatos de registro son diferentes, según el tipo y el proveedor. Los
sistemas de dispositivos de red Juniper crean registros en un formato diferente al de
los firewall Palo Alto y Barracuda. Uno de los objetivos de los SIEM es homologar la
salida de los eventos para poder efectuar un entendimiento más rápido de lo que pasa,
sin importar el origen de los datos.

Las herramientas más populares en esta área son:

OSIM

• Suite elastic:
o Kibana;
o Logtash;
o Elastisearch;
• Splunk.
• HP ArcSight Logger.
• McAfee Security Manager.
• RSA enVision.
• Novell Sentinel.
• Trustwave SIEM.
• IBM Tivoli.

Figura 5: Herramientas para manejo de eventos

Fuente: [Imagen sin título sobre herramientas SIEM], (s. f.). Recuperada de
https://goo.gl/9xhezW
4.2.4 Generación de métricas efectivas
Si hacemos referencia a la generación de métricas, es porque deseamos realizar una
medición del estado actual de la seguridad. Las métricas que podrían representar
nuestro estado actual de manera generalizada son:

• Seguridad de aplicaciones: se puede medir realizando un inventario de las

aplicaciones que utiliza la organización. De este inventario, se debe obtener el
porcentaje de aplicaciones críticas, y levantar información de cuántas de estas
aplicaciones tienen una cobertura de gestión de riesgo o de gestión ante
desastre. Además, se debe tener un reporte de cuál es la cobertura de pruebas
de seguridad para las aplicaciones.
• Gestión de incidentes: aquí se miden tiempos de descubrimiento de
incidentes, tasa de incidentes por mes, porcentaje de incidentes detectados por
los controles internos, tiempo transcurrido entre incidentes de seguridad y
tiempo transcurrido para la recuperación.
• Gestión de parches: aquí debemos de contar con reportes que nos indiquen
el cumplimiento de las políticas de parches, la cobertura de la gestión de
parches, y los tiempos para la aplicación de los parches.
• Gestión de configuraciones/controles de cambio: busca medir el control en
los tiempos para completar las ventanas de cambio, el porcentaje de cambios
con revisiones de seguridad y el porcentaje de excepciones de seguridad.
• Gestión de vulnerabilidades: se miden la cobertura de los escaneos de
vulnerabilidades, el porcentaje de sistemas sin vulnerabilidades conocidas, el
tiempo que lleva mitigar vulnerabilidades y el número de vulnerabilidades
conocidas en los equipos.
• Financiera: también es importante medir qué inversión se está aplicando en el
sector de seguridad. Para eso, se puede tomar el presupuesto de seguridad
como porcentaje de IT (Information Technology) y la distribución del
presupuesto del departamento o grupo de seguridad de la información.

Video conceptual 2
Referencias
Álvarez Martin, C., y González Pérez, P. (2014). Hardening de servidores
GNU/Linux. Madrid, ES: Oxword.

Campos, I. (2014). Midiendo la efectividad de su programa de seguridad de

información. Recuperado
de https://www2.deloitte.com/content/dam/Deloitte/mx/Documents/risk/CISO/5.Security
-Metrics-Presentacion.pdf

Cisco System. (2013). Guía de diseño de seguridad para campus enterprise.

Recuperado
de https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/SAFE_RG/SAF
E_rg/chap5.html

[Imagen sin título sobre diseño de red jerárquica por módulo]. (s. f.). Recuperado
de Cisco System Guide Building Cisco Multilayer Switched Networks Volume1. 2007

[Imagen sin título sobre herramientas SIEM]. (s. f.). Recuperado

de https://es.slideshare.net/cruetic2015/el-impacto-de-las-tecnologas-bigdata-en-los-
procesos-de-analtica-y-seguridad-en-universidades

Intel Latin America. (2017). Diferentes protocolos de Wi-Fi y velocidades de datos.

Recuperado
de https://www.intel.la/content/www/xl/es/support/articles/000005725/network-and-i-
o/wireless-networking.html

Internet Engineering Task Force (IETF). (2000b). RFC 2865. Remote Authentication
Dial In User Service (RADIUS). Recuperado de https://tools.ietf.org/html/rfc2865

Internet Engineering Task Force (IETF). (2001). RFC 3164. The BSD syslog
Protocol. Recuperado de https://tools.ietf.org/html/rfc3164

Internet Engineering Task Force (IETF). (2003). RFC 3539. Authentication,

Authorization and Accounting (AAA) Transport Profile. Recuperado
de https://tools.ietf.org/html/rfc3539

Internet Engineering Task Force (IETF). (2005). RFC 4120. The Kerberos Network
Authentication Service (V5). Recuperado de https://tools.ietf.org/html/rfc4120

Massachusetts Institute of Technology (MIT). Kerberos: The Network Authentication

Protocol. Recuperado de http://web.mit.edu/kerberos/

Microsoft. (2007). Wireless Deployment technology and component overview

[Imagen]. Recuperada de https://i-technet.sec.s-msft.com/dynimg/IC124882.gif

Sonck, D. (2011). Kerberos negotiations [Imagen]. Recuperado

de https://upload.wikimedia.org/wikipedia/commons/thumb/4/4e/Kerberos.svg/2000px-
Kerberos.svg.png

Tomaszewski, R. (2013). [Imagen sin título sobre diseño de red

jerárquico]. Recuperado de http://rtomaszewski.blogspot.com.ar/2013/05/