Seguridad Lógica Investigación

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 81

Seguridad Lógica.

La Seguridad Lógica consiste en la


aplicación de barreras lógicas y
procedimientos que resguarden el
acceso a los datos y sólo permitan
acceder a ellos a las personas
autorizadas para hacerlo.

Mantener un sistema seguro (o fiable)


consiste básicamente en garantizar tres aspectos:

1. Confidencialidad o Privacidad. Que la información sólo sea conocida por personas


autorizadas no convirtiendo esa información en disponible para otras entidades.

La Ley Federal de Protección de Datos Personales en Posesión de Particulares.

GDPR, por sus siglas en inglés (General Data Protection Regulation), o RGPD por sus siglas en español (Reglamento General
de Protección de Datos) es la nueva normativa que regula la protección de los datos de los ciudadanos que viven en la Unión
Europea.

2. Integridad. Hace que el contenido de la información permanezca inalterado a menos que


sea modificado por personal (sistemas) autorizado, y esta modificación sea registrada para
posteriores controles o auditorías.

3. Disponibilidad. Que la información esté siempre disponible para ser procesada por personal
autorizado. Esto requiere que dicha información se mantenga correctamente almacenada
con el hardware y el software funcionando perfectamente y que se respeten los formatos
para su recuperación en forma satisfactoria.

Los tres elementos principales a proteger en cualquier sistema informático son el software, el
hardware y los datos. Habitualmente los datos son el principal elemento, ya que es el más
amenazado y el más difícil de recuperar. Se deben conocer las amenazas a que los datos están
sometidos y las vulnerabilidades de los sistemas en los que residen, así como los principales tipos de
ataques para crear una buena política de seguridad que los proteja.

Los objetivos que se plantean en la seguridad lógica serán:

1. Restringir el acceso a los programas y archivos.


2. Asegurar que los operadores puedan trabajar sin una supervisión minuciosa y no puedan
modificar los programas ni los archivos que no les correspondan.
3. Asegurar que se estén utilizando los datos, archivos y programas correctos con el
procedimiento correcto.
4. Que la información transmitida sea recibida por el destinatario al que ha sido enviada y no a
otro.
5. Que la información recibida sea la misma que ha sido transmitida.
6. Que existan sistemas alternativos secundarios de transmisión entre diferentes puntos.
7. Que se disponga de pasos alternativos de emergencia para la transmisión de información.

Implementación.

La seguridad lógica está estandarizada de acuerdo a unos


niveles de seguridad. El estándar más utilizado
internacionalmente es el TCSEC (Trusted Computer System
Evaluation Criteria) Orange Book.

Los niveles describen diferentes tipos de seguridad y se


enumeran desde el mínimo grado de seguridad al máximo. Estos
niveles han sido la base de desarrollo de estándares europeos
(ITSEC/ITSEM, Information Technology Security Evaluation
Criteria / Methodology) y luego internacionales (ISO/IEC). Cada
nivel requiere todos los niveles definidos anteriormente.

Niveles:

D - Sistema sin seguridad.

C1 - Precisa de una identificación inicial del usuario.

C2 - Identificación inicial del usuario con contraseña y sistema de auditoría.

B1 - Debe cumplir los niveles de acreditación definidos por el DOD.

B2 - Garantiza la conexión entre el usuario y el sistema de seguridad y proporciona garantías de


que el sistema de acreditación no se degrada.

B3 - El sistema está definido por un modelo matemático.

A1 - El sistema está definido por un modelo matemático que puede ser demostrado.

Nivel D

Reservado para sistemas que no cumplen con ninguna


especificación de seguridad. Sin sistemas fiables, no hay
protección para el hardware, el SO es inestable y no hay autenticación con respecto a usuarios y
sus derechos de acceso a la información.

Un ejemplo.

PwC Estados Unidos, con la colaboración de CIOs y CSOs, realizaron la Encuesta Global del Estado de
la Seguridad de la Información 2017, en la que participaron más de 10,000 ejecutivos y directores de
Tecnologías de la Información en más de 133 países. La participación de México representó más de
4% de la participación total de este estudio.

87% de las empresas en México ha tenido incidentes de seguridad de la información.

A nivel global, en los 12 meses anteriores a la realización del estudio de PwC, el promedio de
ataques de seguridad a las empresas en México fue de 3,706 ataques por empresa. Sin embargo, la
cantidad de empresas que han sufrido ataques a sus tecnologías de la información es 13% mayor
que a nivel mundial, con 74% de las compañías internacionales afectadas.

44% de las empresas mexicanas dijeron haber sufrido ciberdelitos por parte de sus exempleados.

1 millón 581,641 dólares es el costo promedio de un incidente de seguridad en México. Lo cual


representa 32% del presupuesto que las empresas destinan a la seguridad de la información.

3.87% del presupuesto de Tecnologías de la Información se destina a la ciberseguridad en las


empresas mexicanas.
Caso sony y su archivo “contraseñas”

Conceptos Básicos.
Vulnerabilidad: Es una debilidad que potencialmente se puede explotar
para violar y acceder al sistema de información que la contiene.

Las Vulnerabilidades y exposiciones


comunes ( en inglés, Common Vulnerabilities and Exposures, siglas CVE)
Vulnerabilidades día cero.

Amenaza: Es una circunstancia, condición o evento que tiene el


potencial de causar daño a los recursos del sistema.

Tipos de Amenaza

Pasivo: La amenaza hacia la confidencialidad de los datos.

Activo: La amenaza es hacia la integridad de los datos, disponibilidad del


servicio.

Ataques Activos

Estos ataques implican algún tipo de modificación del flujo de datos transmitidos o la creación de un
falso flujo de datos. Se los pueden subdividir en varias categorías:

● Interrupción: Un ataque se clasifica como interrupción si hace que un objeto del sistema se
pierda, quede inutilizable o no disponible.
● Interceptación: Se tratará de una interceptación si un elemento no autorizado consigue un
acceso a un determinado objeto del sistema.
● Modificación: Si además de conseguir el acceso consigue modificar el objeto.
● Fabricación: Se dice que un ataque es una fabricación si se trata de una modificación
destinada a conseguir un objeto similar al atacado de forma que sea difícil distinguir entre el
objeto original y el ‘fabricado’.
● Destrucción: Algunos autores consideran un caso especial de la modificación la destrucción,
entendiéndose como una modificación que inutiliza al objeto afectado.
Ejemplo de Ataque conocidos :

Ingeniería Social

Ingeniería Social Inversa

Trashing

Ataques de Monitorización

● Shoulder Surfing.
● Decoy.
● Scanning
● Eavesdropping-Packet Sniffing.
● Snooping-Downloading

Ataques de Autenticación

● Spoofing-Looping.
● IP Spoofing.
● DNS Spoofing.
● Web Spoofing.
● IP Splicing-Hijacking.
● Utilización de puertas traseras (Backdoors).
● Utilización de Exploits.
● Obtención de Passwords.

Denegación de servicio (DoS – Denial of Service)

● Jamming o Flooding.
● Connection Flood.
● Net Flood.
● Land Attack.
● OOB (Out Of Band), Supernuke o winnuke.
● E-Mail Bombing – Spamming.

Ataques de Modificación-Daño

● Tampering o Data Diddling.


● Borrado de Huellas.
● Ataque mediante controles (componentes) de terceros.
● Vulnerabilidad en los Navegadores.

Errores de Diseño, Implementación y Operación de sistemas.

Virus Informáticos.

Sector de Arranque (Virus Anterior a la Carga del SO).

Virus Residente.

Virus de Macros.

Virus de Email.

Hoax, los Virus Fantasmas.

Gusanos.

Caballos de Troya.

Malware.

Ransomware.

etc.
Nivel C1: Protección Discrecional
El acceso a distinta información se realiza mediante
identificación de usuarios. Cada usuario maneja su
información privada y distingue entre usuarios y el
administrador del sistema, quien tiene control total de
acceso.

Los requerimientos mínimos que debe cumplir la clase C1 son:

● Acceso de control discrecional: Distinción entre usuario y recursos. Se podrán definir grupos
de usuarios y grupos de objetos sobre los cuales podrán actuar usuarios o grupos de ellos.
● Identificación y Autenticación: Un usuario debe identificarse antes de comenzar a ejecutar
acciones sobre el sistema. Los datos de un usuario no podrá ser accedido por un usuario sin
autorización o identificación.

Ejemplo

La creación de grupos de usuarios en los sistemas operativos.

Estados de la información.

La información puede estar en cuatro estados:

● Adquisición.
● Creación.
● Almacenamiento.
● Transmisión.

Y en cada uno de estos estados tiene cuatro propiedades de seguridad:

● Confidencialidad
● Integridad
● Autenticación
● Disponibilidad

No todas estas características deben estar vigentes simultáneamente, ni tienen


todas la misma importancia en todas las circunstancias.

Autentificación

Permite validar(autenticación) e identificar a los integrantes de un par en la comunicación.


Servicios de autenticación de par: Verificar que cada
elemento de la pareja es quien dice ser, al momento de la
conexión.

Servicios de autenticación de origen: Sirve para


solicitar el origen de quien está enviando datos. No
protege ni controla duplicación o modificación de las
unidades de datos.

Sirve para controles de acceso (Autorización) y


contabilidad (Trazabilidad).

Autorización: Es el proceso de concesión de derechos entre los cuales está el


control de acceso.

Trazabilidad: Es la propiedad de guardar traza de las operaciones efectuadas por


los pares.

Autentificación: Está formada por dos partes: la autenticación y la identificación.

La identificación. Es dar a conocer de manera exclusiva a un usuario del sistema, se da al momento


de que el usuario entra al sistema.

Autenticación. Verifica la identidad y se demuestra que el usuario es quien dice ser.

Por ejemplo.

La autenticación es la contraseña y la identificación es el user.

Política de contraseñas.

La contraseña o clave de un usuario es el mecanismo que utilizamos para


autenticarnos en todos los sistemas informáticos. Nos identificamos ante el
sistema utilizando el nombre de usuario y usamos nuestra contraseña para probar
nuestra identidad en el sistema. Las contraseñas continúan siendo, a pesar del
esfuerzo continuado, un eslabón débil dentro de la seguridad.
La calidad de la contraseña es un factor importante a ser considerado. Si las
contraseñas pueden adivinarse o robarse, alguien ingresando con un usuario válido
puede causar problemas a la institución o sus recursos. Por ello, la contraseña es
de uso personal e individual, no debe ser compartida con otras personas y debe ser
mantenida en forma segura.
¿Qué es considerado una contraseña? ¿Y una passphrase?

Una contraseña ('password') es una secuencia de caracteres (minúsculas,


mayúsculas, dígitos y caracteres especiales o de puntuación, excluyendo el carácter
de espacio en blanco) que se usa como mecanismo de seguridad.
Contraseñas cortas, con pocos tipos de caracteres, basadas en información del
usuario o en palabras de diccionarios son muy vulnerables a ataques de fuerza
bruta (también denominados cracking de contraseñas).

Es por ello que usualmente se establecen ciertas condiciones de complejidad


mínimas, para evitar estos tipos de riesgos.

Complejidad mínima de las contraseñas.

Las clases de caracteres utilizadas para las contraseñas son mayúsculas,


minúsculas, números y símbolos. La complejidad que deben tener las contraseñas,
en función de las clases de caracteres, dependerá del largo de las mismas.
Intuitivamente, a mayor cantidad de caracteres, se relaja la necesidad de tener
clases adicionales. Como mínimo, las contraseñas deberán tener al menos 10
caracteres. Luego, al ir creciendo en largo, se podrá usar menos clases de
caracteres.

Podríamos entonces resumirlo como:

a) El mínimo del largo de una contraseña es de 10 caracteres.


b) Si el largo de una contraseña es de 10 u 11 caracteres, debe tener elementos de las 4 clases
de caracteres.
c) Si el largo de una contraseña es de 12 a 19 caracteres, debe tener elementos de al menos 3
clases de caracteres.
d) Si el largo de una contraseña es de 20 a 25 caracteres, debe tener elementos de al menos 2
clases de caracteres.
e) Si el largo de una contraseña es de 26 o más caracteres, puede tener solamente elementos
de 1 clase de caracteres.

Contraseñas basadas en el nombre y/o apellido, o en palabras comunes de diccionarios tampoco se


permiten.
Adicionalmente se debe tener en cuenta que si la contraseña cuenta con una única letra mayúscula
esta no puede ser la primera y si cuenta con un solo dígito no puede ser el último.
Cuanto más aplicamos esas condiciones tenemos una contraseña más
fuerte, pero también más difícil de recordar.

¿Qué hacemos?

¿Usamos una clave del tipo «jrD&;çv561w2/ª» ?


¿Seremos capaces de recordarla? Ni de teclearla bien a la primera.
¿Y una como «4ut08US€s» o «C0ntr4S3ñ4*9«? Menos difícil de recordar, pero
tampoco es imposible que se olvide algún carácter especial, alguna sustitución o
alguna mayúscula.

Lo anterior obliga a muchos usuarios a usar contraseñas débiles pero fáciles de


recordar:

El Centro Nacional de Ciberseguridad del Reino Unido ha publicado un listado de


las 100.000 contraseñas más usadas de Internet. Estos listados son usados por
cibercriminales para realizar ataques de diccionario.

Contraseñas más usadas 2019.

La lista sigue liderada por «123456», como todos los años. «qwerty» y «password» también siguen
en lo alto de las contraseñas más usadas. Al igual que «iloveyou», «monkey» o combinaciones como
«1q2w3e4r5t» que, aunque parezcan más complejas y por lo tanto más seguras, no son más que
caracteres que están juntos en el teclado. Así, aunque los usuarios creen que están utilizando una
combinación segura de números y letras, en realidad están cayendo en el mismo error que otros
miles de personas.

Con las contraseñas más usadas se perpetran ataques de diccionario.

Para resolver la situación muchos administradores de seguridad optan por las


contraseñas generadas automáticamente.

Las contraseñas generadas automáticamente son


difíciles de recordar, por lo que, en lugar de facilitarle la
vida a sus usuarios, lo hace más difícil y al mismo tiempo
alienta a escribir la contraseña en un Post-it, que puede
no ser lo mejor en términos de seguridad.

Es por esto que la mayoría de los sitios web que generan


tales contraseñas durante el registro las convierten en
contraseñas de un solo uso. En otras palabras, el usuario recibe un correo
electrónico con una contraseña aleatoria, pero una vez que lo usa para iniciar
sesión, el sitio web solicita inmediatamente la nueva contraseña elegida por el
usuario.

¿No puede una contraseña ser fuerte y fácil de recordar a la vez?

A una contraseña con dos o más palabras se le llama más propiamente frase o passphrase.
Una passphrase debe cumplir con los siguientes requerimientos:
1) Contener un mínimo de 4 palabras.
2) Tener un largo mínimo total de 16 caracteres.

Es posible adivinar las passphrase si el usuario no toma precauciones al crearlas.


Usando diccionarios de varios idiomas, listas recopiladas de palabras comunes,
nombres propios, nombres de lugares, nombres de artistas y personajes, etc., se
puede probar hasta acertar. Es un trabajo arduo, pero si se automatiza en una
computadora no lleva esfuerzo sino sólo tiempo.

3 consejos sobre las contraseñas de Edward Snowden.

El excontratista de la NSA dijo en una entrevista que los buenos


passwords están hechos de frases que combinen números y
letras. Las mejores contraseñas son aquellas que se conforman
por frases largas con números y signos, así lo dijo Edward
Snowden.

El excontratista de la Agencia de Seguridad Nacional de Estados Unidos (NSA), conocido por filtrar
documentos oficiales con información de espionaje militar, dijo a John Oliver, conductor del
programa “Last Week Tonight”, que las claves más débiles son las que constan de sólo una palabra o
secuencia de números.

El analista ofreció tres consejos para dar mayor protección a la información


personal que tenemos en las computadoras.
1) Claves fuertes. Las mejores contraseñas tienen oraciones que combinan símbolos, números,
letras mayúsculas y minúsculas y que a la vez sean fáciles de recordar por el usuario.
Snowden dijo que algo como “Margarettacheres110%SEXY” es un buen ejemplo de un
código complejo para máquinas pero sencillo para los humanos.

2) Que no te dé flojera cambiarlas. Snowden recomienda cambiar las contraseñas de las


herramientas digitales al menos cada seis meses y en las plataformas donde se guarda
información altamente sensible, como los servicios bancarios, al menos cada tres meses.

3) Combina contraseñas y servicios. Hay usuarios que usan la misma clave para todo. Esto es
especialmente preocupante pues si el password único se ve comprometido, pone en riesgo a
todos los servicios digitales de una persona. Snowden recomienda usar frases similares pero
con cambios ligeros, por ejemplo “Margarettacherses110%SEXYenFacebook”, para cada
servicio.

TENGO MUCHAS CONTRASEÑAS CÓMO HACER PARA RECORDARLAS


TODAS.

Gestor de contraseñas.

Un gestor de contraseñas o administrador de contraseñas es un programa de


cómputo que se utiliza para almacenar una gran cantidad de parejas
usuario/contraseña.

LLAVEROS DE CONTRASEÑAS (GESTORES DE CONTRASEÑAS) SOFTWARE.

Ventajas de usar un gestor de contraseñas.

● Facilidad para crear y usar grandes claves.


● Iniciar sesión automáticamente en nuestras cuentas.
● Guardar información más allá de contraseñas, como tarjetas bancarias.

Inconvenientes de utilizar un gestor de contraseñas.

● Es posible que el gestor de contraseñas que elijamos no sea compatible con todos los
sistemas.
● Muchos de estos administradores de contraseñas solo guardan la información en la nube.
Por lo que se necesita conexión a internet para usarlos.
● Contraseña maestra para lo bueno y lo malo. Perder u olvidar la contraseña maestra. Eso
significa que perdemos el control de acceso a todas las demás cuentas. Un problema que
puede agravarse si alguien logra robar de alguna manera esa clave.
● Posibles fallos. Puede ocurrir que ese programa o servicio deje de funcionar por algún
motivo. Bien sea un fallo momentáneo o bien algo más permanente. Podría afectar bastante
a las contraseñas y perder algunas en caso de no recordarlas.
Contar con un gestor de contraseñas puede ser muy positivo. Sin embargo también puede tener sus
problemas. Saber elegir un buen administrador de contraseñas es importante.

LLAVEROS DE CONTRASEÑAS (GESTORES DE CONTRASEÑAS) HARDWARE.

Existen también productos físicos como una llave USB que funciona como factor de autenticación
adicional. Obviamente su "desventaja" es que cuestan dinero, pero son mucho más cómodos que
tener que esperar e ingresar códigos manualmente cada vez que se quiere iniciar sesión. Con este
tipo de opciones todo lo que tenemos que hacer es conectar el dispositivo a un puerto USB para
confirmar nuestra identidad.

Los dispositivos hardware funcionan bajo la base de la autenticación en dos pasos.

Utilizar un dispositivo móvil como parte en la verificación de dos pasos puede


resultar muy conveniente. Es algo que el usuario siempre lleva consigo, es fácil de
usar. Ahora bien, utilizar los SMS para esto, no es la mejor manera de
aprovecharlo.

Los mensajes de texto suelen ser el paso más débil en la verificación en dos pasos,
son fáciles de interceptar y nunca debería asumirse su seguridad. Por ejemplo, con
simple ingeniería social un tercero malintencionado puede convencer al operador
de redirigir los mensajes a una tarjeta SIM diferente interceptando todos tus
códigos de acceso.

Aunque utilizar los SMS como un segundo paso es mejor que nada, en realidad no
puede clasificarse como un factor correcto para ser considerado verificación en dos
pasos. Un SMS no es ni algo que el usuario sabe, ni algo que tiene, ni algo que es .
Es solo información que llega a un dispositivo que posee, siempre y cuando el
operador los envíe a la persona correcta.

De hecho, a mediados de 2016, el Instituto Nacional de Estándares y Tecnología de


los Estados Unidos (NIST) declaró inseguros a los SMS como método de
autenticación en dos pasos y dicen que deberían ser prohibidos en el futuro.

Es muy fácil para cualquiera obtener un teléfono y el operador de un sitio web no


tiene forma de verificar que quien recibe el código a través de SMS sea la persona
correcta.

Todo esto sin contar el grave defecto en Signaling System Number 7 (SS7), el
protocolo que utilizan la mayoría de los operadores de telecomunicaciones para
conectarse unos a otros cuando se hacen llamadas, o envío de mensajes. Su
infraestructura es fácil de atacar y los hackers pueden redirigir llamadas y mensajes
a sus propios dispositivos.

Autenticación Multifactor.

La autenticación en dos pasos, abreviada 2FA (autenticación de dos factores) es un


tipo de autenticación multifactor que requiere la combinación de dos
componentes diferentes para confirmar la identidad.

Qué es la autenticación multifactor. Cualquier método en el que se dé acceso a un


sistema computacional solo cuando el usuario presente diferentes piezas de
evidencia de identidad, es considerado autenticación multifactor (MFA).

Esos factores se basan todos en la premisa de que sería muy difícil que un ente no
autorizado pueda hacerse con los dos al mismo tiempo. Pueden ser cosas como: un
objeto (memoria USB, tarjeta, llave, etc.), algo que solo sepa el usuario
(contraseña, PIN), algo que el usuario es (características biométricas como huellas,
voz, patrón de tecleado, iris del ojo, etc.)

Para suplir las debilidades propias de las contraseñas, se ha extendido el uso de la autenticación de
múltiples factores. El MFA ofrece una forma más segura de acceder a los sistemas corporativos, ya
que para ello, además de conocer la contraseña, se debe estar en posesión de un segundo factor de
autenticación, como puede ser una app en un dispositivo móvil, una tarjeta o token físico o
mediante biometría. Estos dispositivos Passwordless reemplazará el uso de contraseñas por
alternativas más seguras y amigables para el usuario.

FIDO Universal 2nd Factor (U2F).Protocolo universal de segundo factor (U2F).


El protocolo FIDO U2F permite un segundo factor para la seguridad del usuario final. La dependencia
de la parte que confía en las contraseñas se reduce. La contraseña puede incluso simplificarse a un
PIN de 4 dígitos. Los usuarios finales llevan un único dispositivo U2F que funciona con cualquier
parte confiable que admita el protocolo. El usuario obtiene la conveniencia de un solo dispositivo
'llavero'.

El usuario inicia sesión con un nombre de usuario y contraseña como antes. El servicio solicita al
usuario que presente un dispositivo de segundo factor. El segundo factor permite que el servicio
simplifique sus contraseñas (por ejemplo, PIN de 4 dígitos) sin comprometer la seguridad.

Durante el registro y la autenticación, el usuario presenta el segundo factor simplemente


presionando un botón en un dispositivo USB o tocando NFC o bluetooth (Bluetooth Low Energy BLE).
El usuario puede usar su dispositivo FIDO U2F en todos los servicios en línea que admiten el
protocolo aprovechando el soporte incorporado en los navegadores web.

WebAuth (Web Authentication).

Ofrece un estándar de seguridad mucho más elevado que los métodos anteriores y facilita el registro
en los servicios online. El nuevo estándar WebAuth pretende convertir a las contraseñas en algo del
pasado sin poner en peligro la seguridad de los datos sensibles.
El Consorcio de la World Wide Web, una unión de empresas de informática que publica
regularmente estándares para la web, en cooperación con la FIDO (Fast IDentity Online) Alliance,
que agrupa a varias empresas con el objetivo de desarrollar medidas homogéneas de autenticación.
Han desarrollado varias medidas de seguridad, entre ellas, el Client to Authenticator Protocol (CTAP)
y el nuevo estándar WebAuth.

El nuevo sistema de autenticación web aspira a convertirse en una forma única de verificación que,
en lugar de usar contraseñas, utilizará datos biométricos: el estándar prevé que los usuarios
confirmen su identidad por huella dactilar o reconocimiento facial. Además, el sistema es compatible
con el uso de tokens.

La nueva Web Authentication deberá funcionar en el futuro en todos los navegadores. Con este
método, las páginas web que han de verificar la identidad del usuario recurren a la API de
autenticación web en el navegador. El usuario, por su parte, confirma ser quien es en su propio
equipo con un escáner de huella dactilar o con un token conectado a su ordenador. Los datos
personales de identidad, como la huella digital, no abandonan el dispositivo. Es el navegador el que
envía la verificación de su identidad, cifrada por medio de una clave pública, al servicio web. El
usuario no ha tenido que introducir ni un nombre ni una contraseña.

La WebAuth es mucho más rápida y amigable que la MFA.

¿Qué es el CTAP?

FIDO2 y WebAuth están destinados a reemplazar el sistema de contraseñas común. Con ellos, en
lugar de las claves de acceso habituales pueden usarse datos biométricos. También se puede recurrir
a lo que en el contexto FIDO se conocen como autenticadores, estos son, tokens de hardware. En
este mismo contexto, CTAP se constituye como el protocolo encargado de controlar la comunicación
entre el token y el sistema del usuario. De este modo, el protocolo determina cómo deben
comunicarse entre sí los dos componentes para que se lleve a cabo la autenticación y, en
consecuencia, se puede iniciar sesión.
OAuth

OAuth nació a raíz del desarrollo de OpenId para Twitter, se dieron cuenta que no
existía ningún estándar de software libre para poder delegar acceso a las diferentes
API. En el año 2007, se formó el grupo que hoy conocemos como OAuth. Su
función en aquel entonces no era otra que escribir un anteproyecto con todas las
ideas y propuestas para crear un protocolo gratuito y abierto, es decir, de software
libre para que cualquier empresa y usuario pudiera incorporarlo en sus webs o
servicios online.En octubre de 2007 salió definitivamente el borrador Oauth Core
1.0 creando un gran cambio en el acceso a los servicios.
OAuth hoy en día es un estándar abierto que permite la autorización segura
mediante el uso de un API. Básicamente va a permitir que compartamos
información de nuestra cuenta con terceros. Es habitual hacerlo con Google o
Facebook, pero también otras plataformas. Se considera un estándar seguro y
multiplataforma.

Cómo funciona OAuth 2.0

OAuth 2.0 es realmente un framework de autorización, que lo que hace es permitir


que las aplicaciones obtengan acceso limitado a las cuentas de usuario de algunos
servicios como Facebook, Google, Twitter y GitHub. Su funcionamiento
básicamente consiste en delegar el permiso de autenticación del usuario al servicio
que gestiona dichas cuentas, de modo que es el propio servicio el que otorga
acceso a las aplicaciones de terceros. Lo que hace, por ejemplo, en este caso
Twitter, Facebook o Google es verificar que realmente somos nosotros y ofrece
nuestros datos para de esta forma acelerar el proceso y poder acceder sin
problemas a una página web o a un determinado programa.

Cliente
Sería la aplicación que quiere acceder a la cuenta de usuario de un
determinado servicio, como Facebook, Twitter, Google, etc. Por ejemplo si
instalamos una aplicación en el móvil y nos solicita permisos para ver
nuestros datos en alguna de estas redes sociales o plataformas. Es un
proceso que servirá para ahorrar tiempo y también verificar la
autenticidad de un usuario. Simplemente con la cuenta de Facebook o
Twitter verificaremos que somos nosotros y esa aplicación, ese cliente en
definitiva, permitirá el acceso.

Usuario
El usuario es quien autoriza a la aplicación a acceder a su cuenta, mediante
una ventana emergente que pide autorización, y normalmente se incluye
información sobre los datos que se van a compartir al servicio nuevo.
Cuando intentamos vincular cualquier programa con Facebook o Twitter,
por ejemplo, tendremos que autorizar a la aplicación que pueda ceder esa
información. Es por tanto una parte importante en todo este proceso que
utiliza el protocolo OAuth 2.0.
Servidor
El servidor de autorización recibe las peticiones de acceso de aplicaciones
que desean usar el inicio de sesión de algunos de los servicios como
Facebook, Twitter o Google por ejemplo, para iniciar sesión en alguna
página web, juego, etc. Este servidor se encarga de verificar la identidad
del usuario y del servicio que solicita acceso, permitiendo o denegando el
acceso.

Lo primero que sucede es que la aplicación solicita autorización para


acceder a los datos del usuario mediante el uso de alguno de los servicios
que lo permiten. Seguidamente, si el usuario autoriza esa solicitud, la
aplicación recibe una autorización de acceso que tiene que validar
correctamente con el servidor y si es así, emite un token para la aplicación
que solicitaba acceso para que pueda acceder. En caso de que, en algún
paso, el usuario deniegue el acceso o el servidor detecte algún tipo de
error, la aplicación no podrá acceder y mostrará un mensaje de error.

Nivel C2: Protección de Acceso controlado.

Cuenta con características adicionales al C1 que


crean un ambiente de acceso controlado.

Se debe llevar una auditoría de accesos e


intentos fallidos de acceso a objetos.

Tiene la capacidad de restringir aún más el que


los usuarios ejecuten ciertos comandos o tengan
accesos a ciertos archivos.

Requiere que se audite el sistema. Esta auditoría es utilizada para llevar registros de todas las
acciones relacionadas con la seguridad, como las actividades efectuadas por el administrador y sus
usuarios. La auditoría requiere de autenticación adicional para estar seguro de que la persona que
ejecuta el comando es quien dice ser. Su mayor desventaja reside en los recursos adicionales
requeridos.

AUDITORIAS.
El estándar internacional ISO 27001, junto con todas las normas que componen su familia, generan
todos los requisitos necesarios para poder implementar un Sistema de Gestión de Seguridad de la
Información – SGSI -, especialmente si el propósito final es obtener la certificación ISO 27001.

¿Qué papel juega la política de control de acceso ISO 27001 en la auditoría interna?

Para proteger la información mediante las especificaciones técnicas, los requisitos legales o los
objetivos del negocio, además de una mayor complejidad y sofisticación de las operaciones, hacer
uso de expertos auditores en seguridad de la información que se convierte en algo crítico para las
empresas. Se puede realizar a través de personal cualificado interno o mediante una contratación
externa.

Auditoría interna ISO 27001

Una auditoría es un proceso de reunión para realizar una evaluación de las evidencias, es decir,
determinar el grado de cumplimiento de los diferentes criterios.

En concreto, para llevar a cabo una auditoría interna según la norma ISO 27001, los resultados nos
ayudan a responder a la dirección entre tres preguntas:

1. ¿La empresa cumple con todos los requisitos que se consideran pertinentes?
2. ¿Se encuentran definidas las garantías de seguridad de la información de una forma
correcta?
3. ¿Se consiguen los resultados esperados en cuanto a la seguridad de la información?

Al realizar las actividades de auditoría interna el auditor puede proporcionar beneficios como:

La mejora del plan de tratamiento de riesgos. Las personas que llevan a cabo el proceso pueden
actuar de manera preventiva mediante el plan de tratamiento de riesgos, es necesario evitar
problemas menores que se conviertan en los casos de incumplimiento.

Disminuir gastos de auditoría interna/externa.

Software ISOTools Excellence para ISO 27001

Los controles de acceso según ISO 27001 se encuentran en el Anexo A.9.1. El objetivo de este control
del Anexo A es limitar el acceso a la información y a las instalaciones de procesamiento de
información.

Los controles de acceso según ISO 27001 son el resultado del proceso de otorgar a los usuarios
autorizados el derecho a acceder a un servicio o a una información, en tanto que se impide el
acceso a otros usuarios no autorizados.

Ejemplo. Gestión de los controles de acceso según ISO 27001.


Los usuarios sólo deben tener acceso a la red y a los servicios para los que se les ha autorizado
específicamente para usar. El acceso debe ser controlado por un procedimiento de inicio seguro y
restringido, de acuerdo con la política de control de acceso.
A.9.1.1 Política de control de acceso

En pocas palabras, el control de acceso debe ser concedido de acuerdo con quién necesita saber,
quién necesita usar y a cuánto acceso requieren. Los controles de acceso según ISO 27001 pueden
ser de naturaleza digital y física: por ejemplo, restricciones de permisos en las cuentas de usuario,
así como limitaciones sobre quién puede acceder a ciertas ubicaciones físicas. Para ello, la política
debe tener en cuenta:

Los requisitos de seguridad de las aplicaciones comerciales y su alineación con el esquema de


clasificación de información en uso (A.8).

Aclarar quién necesita acceder, saber quién necesita usar la información, todo ello con base en
procedimientos documentados.

Gestión de los derechos de acceso y derechos de acceso privilegiados, incluyendo la adición de


cambios y las revisiones periódicas.

Reglas de control de acceso que deben estar respaldadas por procedimientos formales y
responsabilidades definidas.

Los controles de acceso según ISO 27001 deben revisarse en función del cambio de roles, y, en
particular, durante la salida, para alinearse con el Anexo A.7.

A.9.1.2 Acceso a redes y servicios de red

El principio de acceso mínimo es el enfoque general para la protección, en lugar de acceso ilimitado
y derechos de superusuario sin una cuidadosa consideración. Como tales, los usuarios sólo deberían
tener acceso a la red y a los servicios de red que necesitan usar o conocer para desarrollar su
trabajo.

Por lo tanto, la política debe abordar:

● Las redes y los servicios de red.


● Procedimientos de autorización para mostrar quién tiene acceso a qué y cuándo.
● Controles y procedimientos de gestión para evitar el acceso.

A.9.2.1 Registro de usuarios y anulación de registro.

Es preciso implementar un proceso formal de registro y cancelación de registro de usuarios. Un buen


proceso para la administración de ID de usuario incluye la posibilidad de asociar ID individuales a
personas reales y limitar las ID de acceso compartido, que deben probarse y registrarse donde se
haga.
Un buen proceso de incorporación y salida, se vincula con A7, para mostrar el registro, y evitar la re-
emisión de identificaciones antiguas. Una revisión periódica de las identificaciones ilustrará un buen
control y reforzará la gestión continua.

A.9.2.2 Aprovisionamiento de acceso de usuario

Se debe implementar un proceso – simple y documentado – para asignar o revocar derechos de


acceso para todos los tipos de usuarios, a todos los sistemas y servicios. El proceso de
aprovisionamiento y revocación debe incluir:

● Autorización del propietario del sistema o servicio de información para el uso de estos
activos.
● Verificar que el acceso otorgado sea relevante para el rol que se está realizando.
● Proteger contra el aprovisionamiento antes de que se complete la autorización.

El acceso de los usuarios siempre debe estar dirigido por la organización y basado en los requisitos
de la misma.

A.9.2.3 Gestión de derechos de acceso privilegiado

Se trata de administrar niveles de acceso privilegiados, más altos y más estrictos. La asignación y el
uso de los derechos de acceso privilegiado deben ser controlados en forma muy estricta, dados los
derechos adicionales que generalmente se transmiten sobre los activos de información y los
sistemas que los controlan.

A.9.2.4 Gestión de información secreta de autenticación de usuarios

La información secreta de autenticación es una puerta de acceso para llegar a activos valiosos. Por lo
general, incluye contraseñas y claves de cifrado, por lo que debe controlarse mediante un proceso
de gestión formal y debe ser mantenida en forma confidencial para el usuario.

Esto generalmente está vinculado a contratos de trabajo y procesos disciplinarios, y obligaciones de


proveedores.

A.9.2.5 Revisión de los derechos de acceso del usuario

Los propietarios de activos de la información deben revisar los derechos de acceso de los usuarios a
intervalos regulares, tanto en torno al cambio individual – incorporación, cambio de rol y salida -,
como a auditorías más amplias del acceso a los sistemas. Las autorizaciones para derechos de acceso
privilegiado deben revisarse a intervalos más frecuentes, dada su naturaleza de mayor riesgo.
A.9.2.6 Eliminación o ajuste de los derechos de acceso

Los derechos de acceso de todos los empleados y usuarios externos a las instalaciones de
procesamiento de información, deben concluir al finalizar el vínculo laboral, el contrato o el acuerdo.
Una buena política de salida garantizará que esto suceda.

A.9.3.1 Uso de información secreta de autenticación

Se trata simplemente de asegurar que los usuarios sigan políticas y asuman el compromiso de
mantener confidencial cualquier información secreta de autenticación.

A.9.4.1 Restricción de acceso a la información

El acceso a la información y las funciones del sistema deben estar vinculadas a la política de control
de acceso. Las consideraciones clave deben incluir:

● Control de acceso basado en roles.


● Niveles de acceso.
● Diseño de sistemas de menú, dentro de las aplicaciones.
● Leer, escribir, eliminar y ejecutar permisos.
● Limitación de la producción de información.
● Controles de acceso físicos y/o lógicos a aplicaciones, datos y sistemas sensibles.

El auditor verificará que se hayan hecho consideraciones para limitar el acceso dentro de los
sistemas y aplicaciones que soportan políticas de control de acceso, requisitos comerciales, niveles
de riesgo y segregación de funciones.

A.9.4.2 Procedimientos de inicio seguro

El acceso a los sistemas y aplicaciones debe controlarse mediante un procedimiento de inicio de


sesión seguro, para demostrar la identidad del usuario. Esto puede ir más allá del enfoque típico de
contraseña de múltiples factores, biometría, tarjetas inteligentes y otros medios de cifrado en
función del riesgo que se está considerando.

A.9.4.3 Sistema de gestión de contraseñas

El propósito de un sistema de administración de contraseñas es garantizar que estas sean de calidad,


cumplan con el nivel requerido y se apliquen de manera consistente. Los sistemas de generación y
gestión de contraseñas proporcionan una buena forma de centralizar el suministro de acceso, pero
como sucede con cualquier control, deben implementarse cuidadosamente para garantizar niveles
óptimos de seguridad y protección.
A.9.4.4 Uso de programas de utilidad privilegiada

Los programas informáticos que tienen la capacidad de anular controles del sistema y de las
aplicaciones, aunque resulten muy útiles, deben ser gestionados con mucha atención. Ellos pueden
ser un objetivo atractivo para atacantes maliciosos. El acceso a ellos debe restringirse al menor
número de personas.

A.9.4.5 Control de acceso al código fuente del programa

El acceso al código fuente de los programas debe estar restringido, al igual que a los elementos
asociados como diseños, especificaciones, planes de verificación y de validación. El código fuente de
los programas informáticos, puede ser vulnerable a ataques si no está protegido en forma adecuada.

IDENTIFICACIÓN Y AUTENTICACIÓN DE LOS USUARIOS.


La asignación de derechos y privilegios en un
sistema de controles de acceso es a través del
proceso de autorización que determina el perfil
de cada usuario.

Durante la implantación de los controles de acceso las empresas deben considerar los siguientes
aspectos:

1) Las políticas de seguridad lógica para la clasificación, autorización y distribución de la


información.

2) Las normas y obligaciones empresariales con respecto a la protección del acceso a la


información.

3) Auditoría de seguridad informática para verificar los procesos de los controles de acceso.

4) Mantener los registros de acceso por cada servicio (archivos de log) o sistema informático.

5) Los procedimientos para identificación de usuarios y verificación del acceso de cada usuario.

6) Los controles de acceso para seguridad informática deberán cubrir todas las fases del ciclo
de vida del acceso del usuario, desde el registro inicial de nuevos usuarios hasta la anulación
del registro de usuarios que no requieren más acceso a los sistemas informáticos.

7) Definir los recursos que deben ser protegidos con las soluciones de control de acceso.

Procesos y metodología de autorización utilizados por los controles de


acceso.

POLÍTICAS DE SEGURIDAD LÓGICA.

El objetivo primordial de las políticas de seguridad lógica es suministrar


orientación y ayudar a la dirección, de acuerdo con los requisitos empresariales y
con las normas de seguridad. Las políticas de seguridad lógica representan los
objetivos empresariales y compromiso a la seguridad informática. Las políticas de
seguridad lógica deben ser publicadas dentro de la empresa y ser comunicadas a
todos los empleados de la empresa.
Las políticas de seguridad lógica definen los recursos, cuales deben ser protegidos
y cuáles son los procedimientos de seguridad lógica. (Análisis de riesgos)

Las políticas de seguridad lógica en sí mismas no dicen cómo los recursos son
protegidos. Por cada política de seguridad lógica existen varias medidas y
procedimientos que le correspondan.

Dado que las políticas de seguridad lógica pueden afectar a todos los empleados es importante
asegurarse de tener el nivel de autoridad requerido para la implementación y desarrollo de la
misma.

Las políticas de seguridad lógica deben ser avaladas por los expertos con experiencia en
implementación de políticas de seguridad lógica y por la dirección de la empresa que tiene el
poder de hacerlas cumplir. Por ejemplo contratar Pentesters.

Políticas como de gestión de los incidentes, de respaldo de datos, de protección de datos personales
forman una parte integral de las políticas de seguridad lógica.
Servicios de seguridad.
¿Realmente sabemos qué queremos proteger?

Para poder elegir un mecanismos de seguridad primero tenemos que definir qué es lo que nos
interesa proteger, es decir que servicios de seguridad se necesitan y nos interesan.

Los servicios de seguridad son:

Arquitectura de seguridad OSI, ITU X.800, ISO 7498-2

Se compone de 5 clases de servicio de seguridad.

● Autentificación.
● Control de acceso.
● Confidencialidad.
● Integridad.
● No- rechazo.

● Autentificación: Confirmar la identidad de una o más de las entidades en conexión.


● Control de acceso: Protección ante el uso no autorizado de recursos.
● Confidencialidad: Protección de los datos de difusiones no autorizadas.
● Integridad de datos: Garantía de que los campos en los datos transmitidos o almacenados
no son modificados, borrados o reproducidos.
● No repudio (No-rechazo): Asociar la identidad de un individuo con su participación en un
proceso de comunicación. Esto es útil para probar que un mensaje fue generado por un
usuario concreto. O que un mensaje fue efectivamente recibido.

Estos servicios se implementan con los mecanismos de seguridad, que son las herramientas de
hardware/software de seguridad las cuales instalamos, configuramos y ejecutamos para proteger a
nuestro equipo.

Ejemplo.

Gestión de seguridad: Administrar las directivas globales de seguridad, los mecanismos de


seguridad específicos (por ejemplo, las claves criptográficas, los mecanismos de autenticación y
otros mecanismos de control), los sucesos de seguridad, las auditorías de seguridad y la
restauración de la seguridad.

Autentificación.
La autenticación (también conocida como “identificación” conlleva la confirmación de las
identidades de una o más entidades.

Tipos de Autenticación

Basada en conocimiento: Está basada en un secreto compartido por el usuario y el


sistema de información. Y hay que protegerlo en ambos lugares.
Algo que el usuario conoce.
Ejemplos.
Password.

Basada en posesión:Están basadas en algo que el usuario posee. Y el sistema


sabe que es.
Algo que el usuario tiene.

Ejemplos:
▪ OTP (on time password)
▪ Tarjeta de código de barras
▪ Token
▪ Banda magnética
▪ Tarjeta con chip
▪ Tecnología óptica.

Basada en características físicas: Están fundamentadas en las características de


la persona.
Algo que el usuario es.
Ejemplos:
▪ Biométricos
▪ Reconocimiento facial
▪ Dimensiones del rostro.
▪ Reconocimiento de retina de iris
▪ Reconocimiento de huellas digitales.
▪ Voz
▪ Verificadores de firma.

Basadas en la posición. Fundamentadas en el lugar donde se encuentra el usuario.


Dónde está el usuario.
Ejemplo
▪ GPS
Autenticación fuerte. Combina lo que:
▪ Lo que sabe el usuario
▪ Lo que tiene el usuario
▪ Lo que es el usuario
▪ Lo que hace el usuario

Mecanismos usuales:

● Nombre de usuario y contraseña (criptografía).


● Tickets de acceso: Son identificadores temporales que son solicitados por el cliente a
un servidor.
● Certificados digitales: Es como una credencial la cual incluye información
estandarizada como la clave pública del propietario, nombre, fechas de caducidad,
firma de una autoridad certificadora, entre otros datos.
● Tarjetas inteligentes: Pueden contener claves privadas, certificados digitales u otra
información sobre la entidad. También pueden tener una protección mediante un
número de identificación personal.
● Tokens (Fichas): Las tarjetas Token están protegidas por pin o por otro mecanismo,
como la generación de números mediante los token de securid. Estos números son
conocidos por la tarjeta y el servidor de autenticación.
● Dispositivos biométricos: Estos dispositivos realizan análisis estadísticos de patrones
generados analizando una parte de una persona (retina, iris, rostro, huella dactilar,
voz, etc.) para establecer una identificación personal.

Servicios de control de acceso

Son los servicios que protegen los recursos del


sistema contra la utilización no autorizada.

Un usuario o proceso deberá autentificarse


antes de que los servicios de control de acceso
entren en acción.
Mediante el control de acceso se protege el uso no autorizado de los recursos.
Generalmente, hay un orden implícito, según el cual una entidad primero se identifica
y autentica, y a continuación se le proporciona el acceso o se le deniega. Cada entidad
tiene sus permisos de acceso a cada recurso especificado.

Mecanismos:

● Listas de control de acceso: Una lista de entidades, junto a sus permisos de acceso,
que tienen autorización para acceder al recurso.

● Etiquetas de seguridad: Una colección de atributos asociados con una entidad que
permiten la clasificación de la entidad en términos de nivel de seguridad.

● Roles o privilegios: Un atributo de privilegio que representa la posición o función que


representa un usuario que busca una autenticación. Un determinado ser humano puede
soportar diversos roles y de este modo requerir muchos atributos de privilegio.

● Barreras físicas: El acceso físico a dispositivos del sistema y la red debe limitarse
mediante habitaciones cerradas mediante llaves, contraseñas u otros mecanismos de
control de accesos, seguridad perimetral.

● Firewalls: Son funciones de filtrado y Proxy pueden evitar el acceso a determinados


recursos o direcciones de la red.

Confidencialidad.

Este servicio asegura que sólo las personas o


procesos autorizados tengan acceso a la
información.
Con ello se busca que un agente no autorizado no
pueda leer o copiar la información.
Protege que los datos sean examinados.
Clasificación de los servicios:

● Servicios orientados a conexión. Proporcionan confidencialidad a los datos


transmitidos durante la conexión.

● Servicios NO orientados a conexión. Proporcionan confidencialidad a las


unidades simples de datos.

● Campo selectivo. Proporcionan confidencialidad a ciertas unidades simples de


datos durante la transmisión. Ejemplo. Zip con contraseña.

● De Flujo de Tráfico. Proporcionan confidencialidad ante el análisis de tráfico.

● Servicio de confidencialidad de contenido: Se busca proteger el contenido de un


recurso del sistema. Este servicio puede proporcionar protección a todos los datos
transmitidos por un usuario durante una conexión o puede proteger sólo parte de
ellos por ejemplo sólo a los mensajes con información importante o incluso se
pueden proteger sólo algunos campos de un determinado mensaje.

● Servicio de confidencialidad del mensaje: busca ocultar el flujo de un mensaje


durante una conexión, para ello se cifra y se utiliza una técnica de envoltura con el
objetivo de que si un atacante está realizando un análisis de tráfico, no pueda
descubrir por ejemplo quien está enviando la información ni quien la recibe ni la
frecuencia con la que se envían los mensajes.

Mecanismos usuales:

● Criptografía: proporciona niveles más altos de confidencialidad ya que el mensaje no


viaja en claro.

● Esteganografía: Consiste en ocultar un mensaje secreto en otro mensaje que aparece


normal. Ha sido utilizado en el pasado, antes de la llegada de los ordenadores y las
redes. Hoy en día a veces se utilizan en conjunto con la criptografía.

Integridad
Protege los datos de modificaciones no autorizadas. Consiste en impedir que los datos
almacenados o transmitidos sean modificados, borrados o reproducidos.

● Servicios orientados a conexión


o Con recuperación
o Sin recuperación
● Servicios NO orientados a conexión
o Unidades de datos
o Campos seleccionados

Mecanismos Usuales:

● Checksums: Es un número que representa la suma de bloques del mensaje que se


envía junto con este, y al ser recibido el mensaje se calcula el checksums y se
compara con el que se recibió y si son iguales quiere decir que el mensaje no fue
alterado. Sin embargo existen escenarios de ataque.

● Control de redundancia cíclica: Consiste en una transmisión de datos que se divide


en paquetes. El emisor adjunta una secuencia de n-bits llamada secuencia de control
de paquete a cada paquete. El control de paquete contiene información redundante
sobre el paquete que permite al receptor detectar errores en dicho paquete, también
existe un escenario de ataque.

● Resúmenes de mensajes (Hash). Un resumen de mensaje es una cadena de bits que


fue calculado utilizando el mensaje como datos de entrada en una función de resumen
en un solo sentido. Llamado hash unidireccional que es fácil de procesar en un sentido
pero imposible invertir. Esto quiere decir que es imposible llegar al mensaje original a
partir de un hash. También dos o más mensajes no pueden tener el mismo hash.
También hay escenarios de ataque.

No-Rechazo

Sirven para protegerse contra el emisor de un mensaje o


acción que niega serlo, o bien contra el receptor de un
mensaje que niega haberlo recibido.

Servicios de no rechazo con prueba de origen y servicios de


no rechazo con prueba de destino.
Ejemplo.

Palomitas azules.

El no-repudio pretende demostrar la participación de un individuo en el cual un proceso se


relacione con la identificación de este, en otras palabras un emisor tienen la forma de
garantizar que el receptor no repudiará el mensaje donde el repudio consiste en negar la
autoría sobre un mensaje.

Uno de los mecanismos que se utilizan para este servicio es el certificado digital en otras
palabras firma digital.

La mayoría de estos servicios de seguridad pueden utilizar la criptografía como


mecanismos para cumplir con estos.
Estándares de seguridad mínimos según el National Institute for standard and
technology (NIST):

1. Mecanismos de identificación y autentificación


2. Derechos y permisos
3. Control de cuentas y auditoría
4. Control de uso de objetos
5. Controles contra corrupción de datos
6. Protección contra falla y pérdida de datos
7. Aseguramiento de los canales de comunicación
8. Medidas de seguridad física

Para implementar los 5 servicios se usan los mecanismos de seguridad.

Mecanismos Generales de seguridad OSI

1.- Funcionalidad de confianza. Que cualquier


mecanismo de seguridad debe ser de confianza.
2.- Etiquetas de seguridad. Son datos adicionales a los
datos transmitidos que indican el nivel de sensibilidad de
los datos.
3.- Detección de eventos. Detectar y registrar
violaciones a la seguridad.
4.- Auditoría de seguridad. Herramientas de análisis de
eventos de seguridad en un periodo de tiempo.
5.- Recuperación de seguridad. Acciones de seguridad
resultado de una serie de políticas y reglas.

Mecanismos Específicos de seguridad OSI


1. Cifrado. Para proteger la confidencialidad de las unidades de datos y la información
de un flujo de tráfico al no viajar en claro sino codificada.
2. Firmas digitales. Analogía digital a la firma manuscrita de un documento. No deben
ser falsificables. Deben ser verificables por los receptores. Los emisores no deben
poder rechazarlas.
3. Mecanismos de control de acceso. Deben ser capaces de rechazar y registrar los
intentos de acceso no autorizados..
4. Mecanismos de integridad. Protegen a las unidades de datos ya sea mediante un
mecanismo de ordenación, secuencia, marcado temporal, o encadenamiento
criptográfico.
5. Mecanismos de intercambio de autentificación. Verifica la supuesta identidad de
los pares. La recomendación es que esté basada en técnicas criptográficas.
6. Mecanismos de encaminamiento. Se usan para la selección dinámica de rutas
para la transmisión de datos.
7. Mecanismos de relleno de tráfico (contra Captura de paquetes). Protege contra
el análisis de tráfico enviando unidades de información falsa.
8. Mecanismos de certificación. Una tercera entidad de confianza da testimonio de la
autenticidad de los pares.

Nivel B1: Seguridad Etiquetada

A cada objeto del sistema (usuario,


datos, programas, equipos, etc) se le
asigna una etiqueta con nivel de
seguridad jerárquico (alto secreto,
secreto, reservado, etc) y con unas
categorías (contabilidad, nóminas,
ventas, etc). Cada usuario que accede a
un objeto debe poseer un permiso
expreso para hacerlo y viceversa. Es decir
que cada usuario tiene sus objetos
asociados. También se establecen
controles para limitar la propagación del
derecho de acceso a los distintos
objetos.

Niveles FIDO.
El objetivo de la FIDO Alliance (Fast Identity Online) es reducir la dependencia en
las contraseñas de las aplicaciones móviles y en línea, ofreciendo en su lugar un
ecosistema de autenticación interoperable basado en la criptografía de llave
pública.

Fue fundada conjuntamente por varias compañías tecnológicas, incluidas PayPal y


Lenovo. En los años siguientes, muchas más empresas se unieron a la alianza,
incluidos gigantes tecnológicos como Google, Microsoft y Amazon. FIDO también
cuenta con grandes fabricantes de hardware como Intel y Samsung entre sus
miembros, así como varias instituciones financieras como Visa, MasterCard y
American Express.

La primera especificación FIDO, publicada en diciembre de 2014, incluía dos


componentes: el Marco de Autenticación Universal (UAF) y el Segundo Factor
Universal (U2F).

U2F es el estándar para las claves de seguridad física que actúan como segundo
factor para las contraseñas de sus cuentas en línea. Los dispositivos (tokens) U2F
generalmente se conectan a su computadora a través de USB, pero también hay
modelos de comunicación de campo cercano (NFC) y Bluetooth de baja energía
(BLE) que se pueden usar para dispositivos móviles. Los dispositivos U2F utilizan el
esquema de clave de cifrado público para proteger su cuenta. La clave privada se
almacena exclusivamente en el dispositivo U2F y nunca la abandona, lo que lo hace
mucho más seguro que los métodos 2FA basados en SMS.

En abril de 2018, la alianza lanzó FIDO2. El componente principal de FIDO2 es Web


Authentication (WebAuthn) , desarrollado en colaboración con el World Wide Web
Consortium (W3C). WebAuthn estaba destinado a hacer que la autenticación FIDO
sea más accesible para los usuarios que usan una variedad de tecnologías. El
estándar es compatible con todos los navegadores populares.

Los autenticadores certificados de FIDO se clasifican en diferentes niveles , lo que


especifica su nivel de seguridad:

Nivel 1: Esto incluye todos los autenticadores de software y hardware que


implementan la especificación FIDO2, UAF o U2F. Esta es la implementación más
básica del autenticador FIDO y protege a los usuarios contra el phishing, las
infracciones del servidor y los ataques de hombre en el medio (MitM) .

Nivel 2: los autenticadores certificados de nivel 2 deben tener medidas de


seguridad adicionales que protejan las claves de seguridad contra ataques más
avanzados. Los autenticadores de nivel 2 son resistentes al malware que podría
querer extraer información al obtener acceso al sistema operativo del dispositivo.

Nivel 3 : los autenticadores FIDO de nivel 3 protegen las claves del usuario contra
ataques básicos de hardware. El dispositivo debe ser resistente a la manipulación
física o al menos mostrar signos claros si un pirata informático manipula el
hardware del dispositivo.

Nivel 3 +: este es el tipo más seguro de autenticador FIDO. Los autenticadores de


nivel 3 deben almacenar sus claves en un TPM (Trusted Platform Module), evitando
cualquier tipo de manipulación física o métodos de extracción de datos.
FIPS 140-2

Federal Information Processing


Standard (estándares federales de
procesamiento de la información),
publicación 140-2, es un estándar de
seguridad de computadoras del
gobierno de los Estados Unidos para
la acreditación de módulos
criptográficos.

CERTIFICACIÓN FIPS 140-2

Definido en cuatro niveles de


seguridad, los niveles 1 y 2 para el
cifrado del software, el nivel 3 (que incrementa la resistencia a ataques físicos en
base a una protección criptográfica eficaz y la utilización de llaves y claves de
autenticación), y nivel 4 (creado para dispositivos que operan en ambientes
desprotegidos físicamente).

Nivel 1

Requerimientos de seguridad: Sin requerimientos

Requerimientos de seguridad básica que se exigen para los módulos criptográficos; por ejemplo, al
menos un algoritmo de encriptación aprobado o una función de seguridad aprobada debe ser
utilizado. No se requieren mecanismos específicos de seguridad física. Un ejemplo de Seguridad
Nivel 1 en módulos criptográficos es una tarjeta de cifrado de una computadora personal (PC).

Los componentes de software y firmware del módulo criptográfico, pueden ser


ejecutados dentro de un sistema de cómputo de uso general utilizando un sistema
operativo no evaluado. La implementación de softwares criptográficos puede ser
más rentable que los correspondientes mecanismos basados en hardware,
permitiendo a las organizaciones seleccionar una solución criptográfica alternativa
para satisfacer los requerimientos de seguridad de los niveles más bajos.

Nivel 2
Requerimientos de seguridad: Al menos un algoritmo criptográfico o función de
seguridad implementados.

Mejora los mecanismos de seguridad física de los módulos criptográficos de nivel 1,


añadiendo el requerimiento para evidenciar manipulaciones indebidas, que incluye
el uso de revestimientos o sellos a prueba de inviolabilidad o cerraduras resistentes
en las cubiertas y puertas removibles del módulo. Estos recubrimientos o sellos, se
colocan en un módulo criptográfico de manera que, éstos deberán romperse para
obtener acceso físico a las llaves criptográficas de texto claro y a los Parámetros
Críticos de Seguridad (CSP) dentro del módulo. Los sellos de seguridad y las
cerraduras resistentes a la manipulación, se colocan en las cubiertas o puertas para
protegerlas contra el acceso físico no autorizado.

En nivel 2 de Seguridad requiere como mínimo una autenticación basada en roles


en la cual, el módulo criptográfico auténtica la autorización de un operador para
que pueda asumir un rol específico y le permita realizar el conjunto de servicios
que le corresponde.

Nivel 3

Requerimientos de seguridad:
● Al menos un algoritmo criptográfico o función de seguridad implementados
● Detección y respuesta a manipulaciones
● Protección mejorada de llaves secretas y privadas
● Autenticación basada en Identidad

Intenta evitar que el intruso obtenga acceso a los Parámetros Críticos de Seguridad
(CSP) contenidos en el módulo criptográfico.

Los mecanismos de seguridad física requeridos en el nivel 3 de Seguridad, fueron


creados para proporcionar una mayor probabilidad de detectar y responder a
intentos de acceso físico, uso o modificación del módulo criptográfico. Estos
mecanismos pueden incluir el uso de recintos fuertes y circuitos de detección/
respuesta de manipulación, que pone en cero todos los CSP de texto claro cuando
se abren las tapas/ puertas extraíbles del módulo criptográfico. El nivel 3 de
Seguridad, requiere mecanismos de autenticación basados en identidad,
mejorando la seguridad que proporcionan los mecanismos de seguridad basados
en roles especificados para el nivel 2. Un módulo criptográfico autentica la
identidad de un operador y verifica que el operador identificado esté autorizado
para asumir un rol específico y realizar el conjunto de servicios que le
correspondan.

Nivel 4

Requerimientos de seguridad:
● Al menos un algoritmo criptográfico o función de seguridad implementados
● Detección y respuesta a manipulaciones
● Protección mejorada de llaves secretas y privadas
● Autenticación basada en Identidad
● Resistencia a manipulaciones
● Protección contra fallos ambientales

Es el nivel más alto de seguridad definido en esta norma. En este nivel de seguridad, los mecanismos
de seguridad física suministran una completa capa de protección alrededor del módulo criptográfico,
con la intención de detectar y responder a todos los intentos no autorizados de acceso físico. Las
penetraciones del recinto del módulo criptográfico (desde cualquier dirección), tienen una muy alta
probabilidad de ser detectados, resultando en que todos los CSP de texto claro se pongan en ceros
inmediatamente (zeroization). Los módulos criptográficos con nivel 4 de Seguridad, son útiles para
operar en entornos desprotegidos físicamente. El nivel 4, también protege al módulo criptográfico si
la seguridad se ve comprometida debido a condiciones ambientales o variaciones de voltaje y
temperatura que se encuentren fuera de los rangos normales de funcionamiento del módulo. Los
atacantes pueden realizar movimientos intencionales fuera de los rangos operativos normales para
frustrar las defensas del módulo.

Controles a Implementar.
● Listas de control de acceso: Una lista de entidades, junto a sus permisos de acceso,
que tienen autorización para acceder al recurso.
● Etiquetas de seguridad: Una colección de atributos asociados con una entidad que
permiten la clasificación de la entidad en términos de nivel de seguridad.

● Roles o privilegios: Un atributo de privilegio que representa la posición o función que


representa un usuario que busca una autenticación. Un determinado ser humano puede
soportar diversos roles y de este modo requerir muchos atributos de privilegio.

Control de acceso basado en roles (RBAC).


Modelo de Roles RBAC.

Un rol es un tipo especial de cuenta de usuario desde la que puede ejecutar


aplicaciones con privilegios. Los roles se crean del mismo modo general que
las cuentas de usuario. Los roles tienen un directorio principal, una
asignación de grupo, una contraseña, etc. Los perfiles de derechos y las
autorizaciones otorgan al rol capacidades administrativas. Los roles no
pueden heredar capacidades de otros roles u otros usuarios. Los roles
discretos dividen las capacidades del superusuario y, por lo tanto, permiten
prácticas administrativas más seguras.

Un estudio realizado por NIST ha demostrado que RBAC aborda muchas necesidades de
organizaciones comerciales y gubernamentales. En 2000, NIST solicitó un estándar
unificado para RBAC, el NIST realizó revisiones y propuso un estándar nacional de los EE.
UU. En 2004, el estándar recibió la aprobación de la boleta y fue adoptado como INCITS
359-2004. En 2010, NIST anunció una revisión de RBAC, incorporando características de
control de acceso basado en atributos (ABAC) INCITS 359-2012 (R2017).

El control de acceso basado en roles (RBAC) es una función de seguridad


para controlar el acceso de usuarios a tareas que normalmente están
restringidas al superusuario. Mediante la aplicación de atributos de
seguridad a procesos y usuarios, RBAC puede dividir las capacidades de
superusuario entre varios administradores. RBAC es una alternativa al
modelo de superusuario

Por ejemplo, en los sistemas operativos convencionales, el usuario root,


también conocido como superusuario, es omnipotente. Los programas que
se ejecutan como root, o los programas con este setuid, son omnipotentes.
El usuario root puede leer y escribir en cualquier archivo, ejecutar todos los
programas y enviar señales de terminación a cualquier proceso. De hecho,
cualquier persona que puede convertirse en superusuario puede modificar
el cortafuegos de un sitio, modificar la pista de auditoría, leer registros
confidenciales y apagar toda la red. Un programa setuid usurpado puede
realizar cualquier tarea en el sistema.

El control de acceso basado en roles (RBAC) ofrece una alternativa más


segura al modelo de superusuario del tipo "todo o nada". Con RBAC, se
puede aplicar una política de seguridad en un nivel más específico. RBAC
utiliza el principio de seguridad del privilegio mínimo. Privilegio mínimo
significa que un usuario dispone exactamente de la cantidad de privilegios
necesaria para realizar un trabajo. Los usuarios comunes tienen privilegios
suficientes para utilizar sus aplicaciones, comprobar el estado de sus
trabajos, imprimir archivos, crear archivos nuevos, etc.

En el modelo RBAC, el superusuario crea uno o más roles. Los roles se basan
en perfiles de derechos. El superusuario luego asigna los roles a los usuarios
en los que confía para realizar las tareas del rol que pueden ejecutar
comandos administrativos restringidos.

El modelo RBAC introduce los siguientes elementos:

Autorización: un permiso para que un usuario o un rol realice una clase de


acciones que requieren derechos adicionales.

Privilegio: un derecho perfectamente definido que se puede otorgar a un


comando, un usuario, un rol o un sistema.

Atributos de seguridad: un atributo que permite a un proceso efectuar una


operación que, de lo contrario, está prohibida para los usuarios comunes.

Aplicación con privilegios: una aplicación o un comando que puede anular


los controles del sistema mediante la comprobación de atributos de
seguridad.

Perfil de derechos: una recopilación de capacidades administrativas que se


pueden asignar a un rol o a un usuario.
Un perfil de derechos puede constar de autorizaciones,
comandos con atributos de seguridad y otros perfiles de derechos. Los
perfiles de derechos ofrecen una forma práctica de agrupar los atributos de
seguridad.

Rol: una identidad especial para ejecutar aplicaciones con privilegios. Sólo
los usuarios asignados pueden asumir la identidad especial.

Aplicaciones con privilegios y RBAC.


Las aplicaciones y los comandos que pueden anular los controles del sistema
se consideran aplicaciones con privilegios.

Aplicaciones que comprueban UID y GID.

Las aplicaciones con privilegios que comprueban la existencia de root


(UID=0) o algún otro UID o GID especial se controlan con mecanismos de
perfiles de derechos y así aislar comandos que requieren un ID específico.

En lugar de cambiar el ID de un comando al que cualquiera puede acceder,


se puede colocar el comando con atributos de seguridad de ejecución en un
perfil de derechos. Un usuario o un rol con ese perfil de derechos luego
pueden ejecutar el programa sin tener que convertirse en superusuario.

Aplicaciones que comprueban privilegios.

Las aplicaciones con privilegios pueden comprobar el uso de privilegios. El


mecanismo de perfiles de derechos de RBAC permite especificar los
privilegios para comandos específicos. Un usuario o un rol con ese perfil de
derechos luego pueden ejecutar el comando sólo con los privilegios que el
comando necesita para una ejecución correcta.

Aplicaciones que comprueban autorizaciones.

Se comprueba el nivel de autorización dado por el perfil de derechos. Por


ejemplo, el usuario root tiene todas las autorizaciones. Por lo tanto, el
usuario root puede ejecutar cualquier aplicación.
Nivel B2: Protección Estructurada

Requiere que se etiquete cada objeto de nivel superior por ser padre
de un objeto inferior. La protección estructurada es la primera que
empieza a referirse al problema de un objeto a un nivel más elevado de
seguridad y comunicación con otro objeto a un nivel inferior.

Seguridad de jerarquía para controlar el acceso.

El modelo de seguridad de jerarquía es una extensión de los modelos de seguridad


existentes que usan unidades de negocio, roles de seguridad, recursos compartidos
y equipos. Usualmente se crean varias unidades de negocio y luego se agrega la
seguridad de jerarquía.
Modelos de seguridad de jerarquía de Administrador y de
Posición.

Dos modelos de seguridad se pueden usar para jerarquías: la jerarquía de


Administrador y la jerarquía de Posición.

Con la jerarquía de Administrador, un administrador debe estar dentro de la


misma unidad de negocio que el subordinado, o en la unidad de negocio primaria
de la unidad de negocio del subordinado, para tener acceso a los datos del
subordinado.

La jerarquía de Posición permite el acceso a los datos a través de unidades de


negocio.

Así, por ejemplo, si se trata de una organización financiera, sería preferible el modelo de
jerarquía de Administrador, para evitar que los administradores accedan a los datos fuera
de sus unidades de negocio. Sin embargo, en una organización de servicio al cliente donde
se desea que los administradores tengan acceso a casos gestionados por otras unidades de
negocio, la jerarquía de Posición puede funcionar mejor.

Jerarquía de administrador.

Con el modelo de seguridad de la jerarquía del Administrador, un administrador


tiene acceso a los registros propiedad del usuario o del equipo al que pertenece un
usuario, y a los registros que se comparten directamente con el usuario o equipo al
que un usuario pertenece. Para un subordinado directo, el administrador tiene
acceso de Lectura, Escritura, Actualización, Anexar. Para un subordinado no directo
en la misma cadena de administración del administrador, un administrador tiene el
acceso de sólo lectura a los datos del subordinado no directo.
Ejemplo.

El director general (CEO)puede leer o actualizar los datos del vicepresidente de


ventas y los datos del vicepresidente de servicio. Sin embargo, el director general
puede leer únicamente los datos del jefe de ventas y los datos del jefe de servicio,
así como los datos de ventas y soporte técnico.
Nota: Se puede restringir con mayor detalle la cantidad de datos accesibles para un jefe con
"Profundidad". La profundidad se usa para limitar el número de niveles de profundidad para los que
un administrador tiene acceso de solo lectura a los datos de sus subordinados.

Jerarquía de posición.

Un usuario no tiene que ser administrador de otro usuario para acceder a los datos
del usuario. Los usuarios de las posiciones más altas en la jerarquía tienen acceso a
los datos de los usuarios de las posiciones de nivel más bajo. Las posiciones
directas más altas tienen acceso de Lectura, Escritura, Actualización, Anexar. Las
posiciones no directas más altas tienen acceso de Solo lectura a los datos de las
posiciones inferiores.
Ejemplo.

La posición del Jefe de ventas tiene acceso a los datos de Ventas y Servicio, no
obstante, tiene acceso de lectura a datos de soporte técnico, que se encuentran en
la otra ruta de antecedentes. Lo mismo se aplica para la posición del Administrador
de servicio. Como en la jerarquía de Administrador, se puede limitar la cantidad de
datos accesibles por posiciones más altas con "Profundidad".

https://docs.microsoft.com/es-es/power-platform/admin/hierarchy-security

Control de acceso obligatorio.

El control de acceso basado en roles ( RBAC ) puede implementar control de acceso


obligatorio (MAC) o control de acceso discrecional (DAC).

El control de acceso obligatorio ( MAC ) mediante el sistema operativo se limita a la


capacidad de un sujeto o iniciador para acceder o generalmente realizar algún tipo
de operación en un objeto u objetivo . Cada vez que un sujeto intenta acceder a un
objeto, una regla de autorización impuesta por el núcleo del sistema operativo
examina estos atributos de seguridad y decide si el acceso puede tener lugar.

El control de acceso discrecional ( DAC ) es un medio de restringir el acceso a los


objetos en función de la identidad de los sujetos y / o grupos a los que pertenecen.
Los controles son discrecionales en el sentido de que un sujeto con un cierto
permiso de acceso es capaz de pasar ese permiso (quizás indirectamente) a
cualquier otro sujeto.

Control de acceso obligatorio [mandatory access control (MAC)]


Nota: No confundir con MAC (siglas en inglés de Media Access Control) o message authentication code (MAC).

Se refiere a un tipo de control de acceso mediante el cual el sistema operativo limita la capacidad de
un objeto iniciador para acceder a algún tipo de operación en un objeto destino. En la práctica se
trata usualmente de proceso thread o hilo; los objetos son construcciones software como archivos,
directorios, puertos TCP / UDP, segmentos de memoria compartida, dispositivos IO, etc.

Siempre que un sujeto intenta acceder a un objeto, una regla de autorización impuesta por el kernel
del sistema operativo examina estos atributos de seguridad y decide si el acceso puede tener lugar.

Cualquier operación realizada por cualquier sujeto en cualquier objeto se prueba con el conjunto de
reglas de autorización (también conocidas como política ) para determinar si la operación está
permitida.

En general cualquier sistema puede usar el control de acceso obligatorio, por ejemplo, un sistema de
gestión de bases de datos , en su mecanismo de control de acceso, también puede aplicar control de
acceso obligatorio; en este caso, los objetos son tablas, vistas, procedimientos, etc.

Los sistemas habilitados para MAC permiten a los administradores implementar políticas de
seguridad en toda la organización. Bajo MAC los usuarios no pueden anular o modificar esta política,
ya sea accidental o intencionalmente. Esto permite a los administradores de seguridad definir una
política central que se garantice (en principio) que se aplicará a todos los usuarios.

Ejemplos de implementación: SELinux o AppArmor para Linux y Mandatory Integrity Control para Windows.

Seguridad multinivel MLS.

Históricamente, MAC estuvo fuertemente asociado con la seguridad multinivel (MLS) como un
medio para proteger la información clasificada de los EE. UU. El Trusted Computer System Evaluation
Criteria (TCSEC), el trabajo fundamental sobre el tema, proporcionó la definición original de MAC
como "un medio de restringir el acceso a los objetos en función de la sensibilidad (representada por
una etiqueta) de la información contenida en los objetos. y la autorización formal (es decir,
autorización) de los sujetos para acceder a información de tal sensibilidad .

Las primeras implementaciones de MAC como SCOMP de Honeywell, USAF SACDIN, NSA Blacker y MLS LAN de Boeing se
centraron en MLS para proteger los niveles de clasificación de seguridad orientados al ejército con una aplicación sólida.
Nota:

En algunos sistemas, los usuarios tienen la autoridad para decidir si otorgan acceso a cualquier otro
usuario. Esto no es necesariamente cierto en un sistema MLS.

También tenemos:

Control de acceso basado en atributos ( ABAC )

Define un paradigma de control de acceso mediante el cual se otorgan derechos de acceso a los
usuarios mediante el uso de políticas que combinan atributos. A diferencia del control de acceso
basado en roles (RBAC), que emplea roles predefinidos que llevan un conjunto específico de
privilegios asociados a ellos, en ABAC el concepto de políticas expresan un conjunto complejo de
reglas booleanas. que puede evaluar muchos atributos diferentes, en la que las reglas contienen
declaraciones "SI, ENTONCES" sobre quién realiza la solicitud, el recurso y la acción. Por ejemplo: SI
el solicitante es un administrador, ENTONCES permita el acceso de lectura / escritura a datos
confidenciales.

El marco NIST introduce los conceptos principales de ABAC como sus entidades, es decir, PAP (Punto
de administración de políticas), PEP (Punto de aplicación de políticas), PDP (Punto de decisión de
políticas) y PIP (Punto de información de políticas).

El control de acceso basado en el contexto ( CBAC )

Es una característica del software de firewall , que filtra de manera inteligente los paquetes TCP y
UDP en función de la información de sesión del protocolo de capa de aplicación . Se puede usar para
intranets , extranets e internets.

El control de acceso basado en gráficos ( GBAC )

Los derechos de acceso se otorgan a objetos como archivos o documentos, pero también a objetos
comerciales como una cuenta. Las organizaciones se modelan como un tipo específico de gráfico
semántico que comprende las unidades organizativas, los roles y funciones, así como los agentes
humanos y automáticos (por ejemplo, personas, máquinas).

El control de acceso basado en la red ( LBAC )

Es un modelo de control de acceso complejo basado en la interacción entre cualquier combinación


de objetos (como recursos, computadoras y aplicaciones) y sujetos (como individuos, grupos u
organizaciones).

En este tipo de modelo de control de acceso se utiliza una red para definir los niveles de seguridad
que puede tener un objeto y al que un sujeto puede tener acceso.
El control de acceso basado en la organización ( OrBAC )

Es un modelo de control de acceso donde los sujetos se abstraen en roles. Un rol es un conjunto de
temas a los que se aplica la misma regla de seguridad. Del mismo modo, una actividad es un
conjunto de acciones a las que se aplica la misma regla de seguridad. Y, una vista es un conjunto de
objetos a los que se aplica la misma regla de seguridad. A partir de las tres entidades abstractas
( roles, actividades, vistas ), se definen los privilegios abstractos. Y de estos privilegios abstractos, se
derivan privilegios concretos.

Otros más son:

● Modelo Bell – LaPadula


● Control de acceso basado en reglas (RSBAC)
● Seguridad basada en capacidad
● Autenticación basada en la ubicación
● Autenticación basada en riesgos
● Modelo de Clark – Wilson
● Modelo de Graham-Denning

Nivel B3: Dominios de Seguridad


Refuerza los dominios con las instalación de hardware. Este nivel requiere que el terminal del
usuario se conecte al sistema por medio de una conexión segura. Cada usuario tiene asignado los
lugares y objetos a los que puede acceder.

Ejemplos:

Distribución de claves

KDC
Key (Software)
Distribution
Center 2
1
3
2
1
A 3 B A B
4
Modelo Modelo
PULL PUSH

Modelo PULL. A se quiere


comunicar con B. A le solicita al KDC
(Key Distribution Center) una clave
para comunicarse con B.

Modelo PUSH. A se contacta


con B. B solicita al KDC una llave para
comunicarse con A.
Servidores

Principal:
Puede ser Persona, Sistema, Red

El objetivo de los KDC es permitir que un principal pruebe su identidad a un


servicio, sin tener que enviar datos sensibles que se presten a una posible
suplantación.

Tanto el AS como el TGS pueden ser servicios separados en máquinas


independientes.

Para saber que un principal tiene derechos a usar un servidor, hay una lista de
control de acceso (ACL).

Además las aplicaciones deben ser programadas para soportar este esquema de
acceso. Para esto existen API´s como por ejemplo GSS-API (Generic Security
Service) del IETF (Internet Engineering Task Force)
Ejemplos.
Kerberos 5-1/2
NETSP/Krypto-Knight
SPX
TESS
SESAME

OAuth
OAuth 2 es un framework de autorización que permite a las aplicaciones obtener acceso a un servicio de red.
OAuth 2 proporciona flujos de autorización para aplicaciones web y de escritorio; y dispositivos móviles.

Roles de OAuth
OAuth define cuatro roles:

● Propietario del recurso


● Cliente
● Servidor de recursos
● Servidor de autorización

Propietario del recurso: Usuario


El propietario del recurso es el “usuario” que da la autorización a una aplicación, para acceder a su cuenta.

Servidor de Recursos / Autorización: API


El servidor de recursos aloja las cuentas de usuario protegidas, y el servidor de autorizaciones verifica la identidad
del usuario y luego genera tokens de acceso a la aplicación.

Cliente: Aplicación
El cliente es la aplicación que desea acceder a la cuenta del usuario.
1. La aplicación solicita autorización para acceder a los recursos de servicio del usuario
2. Si el usuario autoriza la solicitud, la aplicación recibe la autorización
3. La aplicación solicita al servidor de autorización (API), presentando la autenticación de su
identidad y la autorización otorgada La aplicación solicita al servidor de autorización (API) un
token de acceso presentando la autenticación de su propia identidad y la autorización
otorgada
4. Si la identidad de la aplicación es autenticada y la autorización es válida, el servidor de
autorización (API) emite un token de acceso a la aplicación. La autorización finaliza
5. La aplicación solicita el recurso al servidor de recursos (API) y presenta el token de acceso
para autenticarse
6. Si el token de acceso es válido, el servidor de recursos (API) provee el recurso a la aplicación
Kerberos
Kerberos es un protocolo de seguridad que usa una criptografía de claves simétricas
(tickets) para validar usuarios con los servicios de red, evitando así tener que enviar
contraseñas a través de la red.
Al validar los usuarios para los servicios de la red por medio de Kerberos, se frustran los
intentos de usuarios no autorizados que intentan interceptar contraseñas en la red.
Seguridad perimetral (de la red) (Dual, Screened – Subnet)

Servidores de seguridad que sean diferentes Tecnologías y marcas.

Esquema Bastión
Three – Legged (Tres patas)

DMZ

Una zona desmilitarizada (conocida también como DMZ, sigla en inglés de demilitarized zone)
o red perimetral es una red local que se ubica entre la red interna de una organización y una
red externa.

Sirve sobre todo para a programas acceder a la red interna desde el exterior.

Configuración Dual
Seguridad perimetral. Conceptos.

Firewall Bloquea puertos, sockets, avisa que una aplicación se quiere


comunicar, filtra URL, IP, antivirus, Red, aplicación. (ngfw)

Proxy Protección de IP internas, recibe peticiones y da salida a una sola IP a


Internet, revisa tráfico de URL, puertos, caché, internet.

Proxy´s

HTTP: Protocolo HTTP solo esto es lo que ven. Fácil de configurar, oculta IP
internas. Desconfía de Flash y Java Script. HTTP va sin encriptar, configurar
a cada cliente para salir a internet.

SOCK´s: Permite todo tipo de tráfico POP, HTTP, HTTPS, configurar


cada servicio por separado es más lento que HTTP, actualmente se utiliza el
SOCK´s 5.

Diseño del servidor de seguridad perimetral.

1. Presupuesto$: prestaciones Vs. Nivel de Seguridad.


a. Clases de servidores de seguridad
i. Servidores de seguridad personales (Equipo principal, económicos)
ii. Servidores de seguridad enrutador (Solo se activa, bajo costo)
iii. Servidores de seguridad hardware inferiores (Soluciones económicas)
iv. Servidores de seguridad hardware superiores (Alto costo y
configuración)
v. Servidores de seguridad de servidores Software de seguridad se
integra al S.O)
2. Revisión de funcionalidad existente (Routers con opción de seguridad y QoS)
3. Disponibilidad:
a. Redundancia de Componentes.
b. Duplicación de dispositivos ($$$$$, Líneas de transmisión doble, software de
cambio de linea, balanceo de cargas)
4. Escalabilidad
a. Rendimiento (Bits p paquetes por segundo)
i. Vertical
ii. Horizontal
5. Tipos de Filtrado.
a. Filtrado de adaptador de red. (Cabeceras IP, UDP, GRE (Protocolo de VPN,
encapsulación de rutas genéricas))
b. Filtrado de paquetes estáticos (bit, ask)
c. Traducción de direcciones de red. (NAT, para saber a quién le pertenece)
d. Inspección con estado (tráfico que coincida con las solicitudes de salida,
evita suplantación de IP)
e. Inspección de circuitos (se filtran las sesiones DOS)
f. Proxy (Ocultar la estructura de la red interna)
g. Filtrado de aplicaciones (analiza el paquete y verifica que sea de la
aplicación)
6. Reglas del servidor de seguridad perimetral
a. Configuración
7. Mejoras de rendimiento
a. Giga Ethernet
b. Proxy inverso
c. Descarga SSL/TSL
d. Descarga IPSEC
8. Protocolos
a. IPV4
b. IPV6
c. GRE
d. PPTP
e. DNS
f. SOCKS
g. SSL
h. RPC
i. H.323
j. TCP/IP
9. Certificación
a. ICSA

Envió de archivos seguros (Claves asimétricas)


Identificar la identidad del emisor.
Identificar la identidad del receptor.
Garantizar la integridad del mensaje.

Entidad certificadora se requiere de un 3º que valide la identidad del emisor (a)

Certificado de clave pública: ITU X.509

Protección del enlace de comunicaciones en red.

Ejemplo.
SSL / TLS

Secure Sockets Layer / Transport Layer Security

SSL (Capa de socket segura) fue sustituida por TLS RFC- 5246 (IETF Internet Enginnering
Task Force)

Fase I: Negociación El cliente solicita una conexión (Algoritmos de cifrado).

Cliente Servidor
TLS TLS
Solicitud de
Conexión
(Algoritmos de cifrado) DSA, RSA, DIFFIE- HELLMAN, AES

Cifrado seleccionado

Autenticación de servidor
X.509
Número aleatorio

Encriptado con llave pública


del servidor

Llave simétrica

Conexión segura

Aplicación Protocolos TCP

HTTP HTTPS

POP POPS

SMTP SMTPS

FTP FTPS

Secure Shell acceder a máquinas remotas

SSH sustituye al Telnet

Implementaciones: OpenSSL, GNUTLS, NSS

--------------------

Conexiones seguras VPN


Virtual Private Network

A. Autenticación Password, X.509 IPSec Fase I Conexión Deffie-Hellman,


IKE
Internet Key
Exchange Protocol

Fase II Transmisión Modo Túnel


Modo Transporte

B. Encriptación punto a punto SSL/TSL Aplicaciones SSL


Túneles SSL

Túnel
IP Paquete Encriptado

Transporte
---
--- Solo la Cabecera

Comunicaciones Inalámbricas

WI-Fi

Wired Equivalent Privacy (RC4 40-104 Bits)

WiFi Protected Access (Temporal Key Integrity Protocol) TKIP

WPA Version 2 AES

● Modo Personal (Service Set Identifier (SSID) + Password)


● Modo Empresarial
PPP -> Point to Point

RADIUS -> Remote Authentication Dial in User Server

EAP -> Extensible Authentication Protocol


Conjunto de librerías que soporta varios protocolos conexión
cifrada

NAS -> Network Access Server. Servidor de acceso a la red

Soluciones de Autenticación

PAP
CHAP
LPT2
IPsec

Federaciones de Autenticación Organizaciones solventadas por


por los sitios WEB
Estándares
SAML (Security Assertion Markup Languaje) servicios WEB RADIUS
Information Cards
XACML
WS-Federation/WS-Trust
Open Id
OAUTH

Aplicaciones de Encriptación

DNS SEC

ZSK (Zone Signing Key) 1024 bits RSA


KSK (Key Signing Key) 2048 bits RSA

Hardware Security Modules (HSM)

Certificaciones:

FIPS 140-2 Standard (NIST) Level 1- level 4

CC- EAL (Common Criteria Evaluation Assurance Levels)

Level 1 – level 7
Empresas:

AEP
IBM
Oracle
Safenet
Thales

TPM (Trusted Platform Module) ISO/IEC 11889-1:2015

Algoritmo de encriptación RSA 2048 bits

Se recomienda usar algoritmos públicos

Redes Distribuidas (GRID Computing)

DCE (Distributed Computing Environment) del OSF (Open Software Foundation)

Servicios Básicos:

1) Servicios de directorios
Ubica recursos asignándoles un UUID (Universal Unique ID) y hay un CDC (Cell
Directory Services) y un GDS (Global Directory Service)
La operación está basada en el estándar X.500 del ITU (International
Communication Union) con arboles LDAP (Lightweight Directory Access Protocol)

2) Servicio de Tiempo Distribuido.


Sincroniza los relojes dentro de una celda

3) Servicios de Seguridad
a. Autenticación de los principales autorizados en cada
celda.
i.
RPC

XML

TCP/IP

Persona, Sistema, Red, Celda.

4) Servicio de Autorización

Puntos base de la tecnología Cloud Computing

Problemas de seguridad en la nube

● Vulnerabilidades BGP (Border Gateway Protocol)


o PREFIX HIJACKING
o Route HIJACKING
Por ejemplo pakistan ordenó a su ISP PCCW que bloqueara a
youtube con la IP 208.65.152.0/24 que es mas especifica y por lo
tanto preferible para el protocolo BGP que la usual de youtube
208.65.152.0/22 asi que routers de todo el mundo eligieron a PCCW
como ruta para llegar a youtube. El resultado es la caída de youtube.
Tarea. Las posibles soluciones SBGP.
● Nubes falsas (Servicios no reales)
● Ataques VM a VM (Servicios compartidos)
● API´s de los proveedores(Programas propios, librerías API´s)
● Empleados del proveedor (Confianza del personal – Proveedor)
● Service HIJACKING (Secuestro de servicios) cliente falso
● RANSOMWARE (Malware evita acceso a servicios)

SSH

RSA 2048 Bits


DSA 1024 Bits

SSH – Agent SSHD


Authentication Agent

Agente SSH Control de acceso Agente


Amenazas IPC
Cliente SSH Agentes crackeados

SSH (Secure Shell)


SSH – Keygen
RSA 2048
DSA 1024

Debilidades

1) Cliente SSH
IPC Internet – Process Communication
Agente SSH

2) Control de acceso al agente


3) Riesgo de agentes hackeados
4) El agente no verifica la identidad del cliente SSH
5) SSH Ver1 (no usar)
Nivel A: Protección Verificada.
Es el nivel más elevado, incluye un proceso de diseño,
control y verificación, mediante métodos formales
(matemáticos) para asegurar todos los procesos que realiza
un usuario sobre el sistema. El diseño requiere ser
verificado de forma matemática y también se deben realizar
análisis de canales encubiertos y de distribución confiable.

Un canal encubierto (del inglés covert channel), es un canal que puede ser
usado para transferir información desde un usuario de un sistema a otro,
usando medios no destinados para este propósito por los desarrolladores
del sistema. Para que la comunicación sea posible suele ser necesario un
preacuerdo entre el emisor y el receptor que codifique el mensaje de una
forma que el receptor sea capaz de interpretar. Está muy relacionado con
la esteganografía. En oposición a los canales encubiertos, se encuentran
los canales legítimos o canales abiertos (en inglés overt channel) que
comprenden las vías de comunicación diseñadas a tal fin.

Si existen personas o procesos a los que se les puede negar el acceso a cualquiera de los datos en el
entorno del sistema, entonces se debe confiar en el sistema para hacer cumplir MAC. Dado que
puede haber varios niveles de clasificación de datos y autorizaciones de usuario, esto implica una
escala cuantificada de robustez. Por ejemplo, se indica más robustez para entornos de sistema que
contienen Top Secret que uno con información secreta o uno con nivel Confidencial.
Para promover la coherencia y eliminar la subjetividad en los grados de robustez, un análisis
científico extenso y una evaluación de riesgos del tema produjo una estandarización de referencia
histórica que cuantifica las capacidades de robustez de la seguridad de los sistemas y las asigna a los
grados de confianza garantizados para varios entornos de seguridad. El resultado se documentó en
CSC-STD-004-85.

Dicha arquitectura evita que un usuario o proceso autenticado en una clasificación o nivel de
confianza específico acceda a información, procesos o dispositivos en un nivel diferente. Esto
proporciona un mecanismo de contención de usuarios y procesos, tanto conocidos como
desconocidos

Algunas implementaciones de MAC, por ejemplo son:


Un proyecto de investigación de la NSA llamado SELinux agregó una arquitectura de control de
acceso obligatorio al kernel de Linux , que se fusionó con la versión principal de Linux en agosto de
2003. Utiliza una característica del kernel de Linux llamada LSM (interfaz de módulos de seguridad
de Linux). Aunque SELinux es capaz de restringir todos los procesos en el sistema, la política de
destino predeterminada en RHEL confina los programas más vulnerables del dominio no confinado
en el que se ejecutan todos los demás programas. RHEL 5 incluye otros 2 tipos de políticas binarias:
estricta, que intenta implementar el privilegio mínimo , y MLS , que se basa en estrictas y agrega
etiquetas MLS . RHEL 5 contiene mejoras adicionales de MLS y recibió 2 certificaciones LSPP /
RBACPP / CAPP / EAL4 + en junio de 2007. Otra alternativa es TOMOYO Linux es una implementación
MAC ligera para Linux y Linux Embedded , desarrollada por NTT Data Corporation . Se ha fusionado
en la versión 2.6.30 de la línea principal del Kernel de Linux en junio de 2009. A diferencia del
enfoque basado en etiquetas utilizado por SELinux, TOMOYO Linux realiza un control de acceso
obligatorio basado en el nombre de ruta , separando los dominios de seguridad según el historial de
invocaciones del proceso, que describe el comportamiento del sistema. La política se describe en
términos de nombres de ruta. Un dominio de seguridad se define simplemente mediante una
cadena de llamadas de proceso y se representa mediante una cadena. Hay 4 modos: deshabilitado,
aprendizaje, permisivo, forzoso. Los administradores pueden asignar diferentes modos para
diferentes dominios. TOMOYO Linux introdujo el modo de "aprendizaje", en el que los accesos
ocurridos en el kernel se analizan y almacenan automáticamente para generar la política MAC: este
modo podría ser el primer paso de la redacción de políticas, lo que facilita la personalización
posterior. SUSE Linux y Ubuntu 7.10 han agregado una implementación MAC llamada AppArmor .
AppArmor utiliza una función del kernel de Linux llamada LSM (interfaz de módulos de seguridad de
Linux). LSM proporciona una API de kernel que permite que los módulos de código de kernel
controlen ACL (listas de control de acceso).

Microsoft a partir de Windows Vista y Server 2008, incorpora el control de integridad obligatorio ,
que agrega niveles de integridad (IL) a los procesos que se ejecutan en una sesión de inicio de sesión.
MIC restringe los permisos de acceso de las aplicaciones que se ejecutan bajo la misma cuenta de
usuario y que pueden ser menos confiables. Se definen cinco niveles de integridad: Bajo, Medio,
Alto, Sistema e Instalador de confianza. Los procesos iniciados por un usuario regular obtienen un IL
Medio; los procesos elevados tienen IL alta. Si bien los procesos heredan el nivel de integridad del
proceso que lo generó, el nivel de integridad se puede personalizar para cada proceso. Windows
controla el acceso a los objetos basados en IL, así como para definir el límite de los mensajes de
ventana a través del aislamiento de privilegios de la interfaz de usuario . Los objetos con nombre ,
incluidos archivos , claves de registro u otros procesos y subprocesos , tienen una entrada en la ACL
que rige el acceso a ellos que define el IL mínimo del proceso que puede usar el objeto. MIC obliga a
que un proceso pueda escribir o eliminar un objeto solo cuando su IL es igual o mayor que el IL del
objeto. Además, para evitar el acceso a datos confidenciales en la memoria, los procesos no pueden
abrir procesos con un IL más alto para el acceso de lectura.

Trusted Solaris de Sun utiliza un mecanismo de control de acceso (MAC) obligatorio y aplicado por el
sistema, en el que se utilizan autorizaciones y etiquetas para hacer cumplir una política de seguridad.
El marco MAC Mac OS X de Apple es una implementación del marco MAC TrustedBSD. La función de
línea de comandos sandbox_init proporciona una interfaz limitada de espacio aislado de alto nivel.

Oracle Label Security es una implementación de control de acceso obligatorio en Oracle DBMS .

BAE Systems. XTS-400

El XTS-400 es un sistema operativo de computadora seguro multinivel . Es multiusuario y multitarea


que utiliza programación multinivel en el procesamiento de datos e información. Funciona en
entornos de red y admite Gigabit Ethernet e IPv4 e IPv6 .

Proporciona seguridad de alta garantía y fue el primer sistema operativo de propósito general con
una calificación de nivel de garantía de Criterios Comunes de EAL5 o superior. El XTS-400 puede
albergar, y ser de confianza para conjuntos de datos, usuarios y redes separados, múltiples y
simultáneos a diferentes niveles de sensibilidad.

El XTS-400 proporciona un entorno no confiable para el trabajo normal y un entorno confiable para
el trabajo administrativo y para aplicaciones privilegiadas. El entorno que no es de confianza es
similar a los entornos Unix tradicionales .Este entorno que no es de confianza incluye una GUI del
sistema X Window , aunque todas las ventanas de una pantalla deben tener el mismo nivel de
sensibilidad.

Para respaldar el entorno confiable y varias características de seguridad, proporciona un conjunto de


API patentadas a las aplicaciones. Para desarrollar programas que utilicen estas API propietarias, se
necesita un entorno de desarrollo de software especial (SDE).

La evaluación EAL5 + incluyó el análisis de canales encubiertos y análisis y pruebas de vulnerabilidad


adicionales por parte de la Agencia de Seguridad Nacional .

Los usuarios normales (es decir, que no son de confianza) no tienen la facultad de cambiar los
niveles de sensibilidad o integridad de los objetos. Los modelos formales de Bell – LaPadula y Biba
son la base de estas políticas.

Tanto las políticas de confidencialidad como las de integridad se aplican a todos los usuarios y todos
los objetos del sistema. Proporciona 16 niveles de sensibilidad jerárquica, 64 categorías de
sensibilidad no jerárquica, 8 niveles de integridad jerárquica y 16 categorías de integridad no
jerárquica. La política de confidencialidad obligatoria aplica el modelo de clasificación de
confidencialidad de datos del Departamento de Defensa de los Estados Unidos (es decir, "Sin
clasificar", "Secreto", "Máximo secreto"), pero se puede configurar para entornos comerciales.

Otras características de seguridad incluyen:


● Control de acceso discrecional (DAC), que aparece igual que en Unix , incluida la presencia
de listas de control de acceso en cada objeto; la función set-id se admite de forma
controlada;
● Un obligatoria subtipo política, que permite a algunas de las funcionalidades de los sistemas
de confianza que soportan una completa aplicación de tipo o de la aplicación del tipo de
dominio de políticas;
● Auditoría de todos los eventos relevantes para la seguridad y herramientas confiables para
permitir a los administradores detectar y analizar posibles violaciones de seguridad;
● Ruta confiable , que permite al usuario estar seguro de que está interactuando directamente
con las funciones de seguridad confiables (TSF) durante operaciones sensibles; Esto impide,
por ejemplo, un caballo de Troya de spoofing el proceso de inicio de sesión y robar la
contraseña de un usuario;
● Aislar el código del sistema operativo y los archivos de datos de la actividad de usuarios y
procesos que no son de confianza que, en particular, evita que el malware corrompa o
afecte el sistema de otra manera;
● Separación de procesos entre sí (para que un proceso / usuario no pueda alterar los datos
internos y el código de otro proceso);
● Funcionalidad del monitor de referencia , de modo que ningún acceso pueda eludir el
escrutinio del sistema operativo;
● Fuerte separación de roles de administrador, operador y usuario utilizando la política de
integridad obligatoria;
● Mecanismos de información residual (es decir, reutilización de objetos) para evitar la
búsqueda de datos;
● Herramientas confiables y evaluadas para configurar el sistema, administrar datos críticos
para la seguridad y reparar sistemas de archivos;
● Autocomprobación de los mecanismos de seguridad, bajo demanda;
● Exclusión de los servicios de red de capa superior de la TSF, de modo que la TSF no sea
susceptible a las vulnerabilidades conocidas públicamente en esos servicios.

Para mantener la confiabilidad del sistema, el XTS-400 debe ser instalado, arrancado y configurado
por personal confiable. El sitio también debe proporcionar protección física de los componentes de
hardware. El sistema y las actualizaciones de software se envían desde BAE Systems de forma
segura.

Para los clientes que los deseen, XTS-400 admite una unidad criptográfica de soporte de misión
(MSCU) y tarjetas Fortezza . La MSCU realiza criptografía de tipo 1 y ha sido examinada por separado
por la Agencia de Seguridad Nacional de los Estados Unidos .

Hardware
La evaluación CC obliga a utilizar hardware particular en el XTS-400. Aunque esto impone
restricciones a las configuraciones de hardware que se pueden utilizar, son posibles varias
configuraciones. El XTS-400 utiliza solo componentes estándar de PC, comerciales listos para usar
(COTS), a excepción de una unidad criptográfica de soporte de misión (MSCU) opcional.
Otros sistemas a este nivel son:

GEMSOS Security Kernel RTOS


Boeing Secure Network Server (SNS)

También podría gustarte