Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relacionados con el control de acceso

Control de Acceso y Seguridad Desarrollo
Ingeniería de Sistemas y Seguridad Informática
Mg. Ing. Jack Daniel Cáceres Meza, PMP
Sesión 08
Controles de la ISO/IEC 27002 relacionados
con el control de acceso

2
Mg, Ing. Jack Daniel Cáceres Meza, PMP
Servicios de Seguridad
 Autenticación: Asegura que el origen y destino son los que dicen ser.
 Control de acceso: Elimina el acceso no autorizado.
 Confidencialidad: Previene la lectura y copia de los datos.
 Integridad de los Datos: Previene la alteración de los datos.
 No Repudio: Firmas digitales
Lampson identifica autorización, autenticación
y auditoría como mecanismos esenciales para
la seguridad informática.

3
¿Qué es autenticación?
 Autenticación se refiere al proceso por el cual un usuario de una red
adquiere el derecho a usar una identidad dentro de la misma.
 Existen diferentes maneras de autenticar a un usuario:
 El uso de claves (Lo que se)
 Tokens (Lo que tengo)
 Biométricos (Lo que soy)
 Combinaciones de los Anteriores (factor 1, factor 2 …)

4
Control de acceso
 Se refiere a los mecanismos y políticas que
restringen el acceso a la computadora y sus
recursos.
 El desarrollo de un sistema de control de acceso
requiere la definición del reglamento o
reglamentación (políticas) según las cuales el
acceso debe ser controlado, y su
implementación como funciones ejecutables
por un sistema de computadora.
 Las políticas de control de acceso son por lo
general formalizadas por un modelo de
seguridad, declarado por un lenguaje de
especificación apropiada, y luego hechas
cumplir por el mecanismo de control de acceso
que hace cumplir el servicio de control de
acceso.
Personas
Sistemas
Recursos

5
Control de acceso
 La separación entre políticas y
mecanismos introduce por un lado
una independencia entre
requerimientos de protección que se
deben hacer cumplir y, por el otro, los
mecanismos que los hacen cumplir.
 Es posible entonces:
 Discutir las exigencias de protección
independientemente de su
realización
 Comparar políticas de control de
acceso diferentes así como
mecanismos diferentes que hacen
cumplir la misma política
 Diseñar mecanismos capaces de
hacer cumplir políticas múltiples

6
Control de acceso
 Este aspecto último es en particular importante: si un mecanismo está
ligado a una política específica, un cambio en la política requeriría el
cambio total del sistema de control de acceso; los mecanismos capaces
de hacer cumplir políticas múltiples evitan este inconveniente.
 La fase de formalización entre la definición de política y su realización
como mecanismo permite la definición de un modelo formal que
representa la política y su funcionamiento, haciendo posible definir y
demostrar propiedades de seguridad que disfrutarán los sistemas que
hacen cumplir el modelo.

7

8
Control de acceso
 En el control de acceso tenemos los siguientes sujetos:
 Usuario: un ser humano
 Asunto: un proceso en ejecución en nombre
de un usuario
 Objeto: un pedazo de datos o un recurso
Entidades (usuarios, grupos,
roles y procesos) que
modifican los objetos y en
consecuencia cambian el
estado del sistema.
Todas las entidades que son relevantes para el estado de
protección del sistema. Es decir que deben ser protegidas. Por
ejemplo: memoria, archivos o datos en dispositivos de
almacenamiento secundario, directorios, programas, dispositivos
de hardware, etc.
http://www.cs.cornell.edu/courses/cs5430/2011sp/NL.accessControl.html

9
Niveles de Seguridad
 El Departamento de Defensa de los Estados Unidos entre 1983 y 1985
publica una serie de documentos denominados Serie Arco iris
(Rainbow Series).
 Dentro de esta serie se encuentra el Libro Naranja (Orange Book),
Trusted Computer Security Evaluation Criteria -TCSEC, el cual
suministra especificaciones de seguridad.
 Este libro se utilizó para evaluar, clasificar y seleccionar sistemas
computacionales que serían considerados para el procesamiento,
almacenamiento y recuperación de información sensible o clasificada.
 Los niveles describen diferentes tipos de seguridad del Sistema
Operativo 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) y luego internacionales (ISO/IEC).
TCSEC was replaced by the Common
Criteria international standard originally
published in 2005
http://redyseguridad.fi-p.unam.mx/proyectos/seguridad/TCSEC.php
https://www.cs.purdue.edu/homes/ninghui/courses/526_Fall12/handouts/526_topic18.pdf
DoD 5200.28-STD

10
 Se definen siete conjuntos de criterios de evaluación denominados
clases (D, C1, C2, B1, B2, B3 y A1). Cada clase de criterios cubre cuatro
aspectos de la evaluación: política de seguridad, imputabilidad,
aseguramiento y documentación.
 Cabe aclarar que cada nivel requiere todos los niveles definidos
anteriormente: así el subnivel B2 abarca los subniveles B1, C2, C1 y D.
 Nivel D
 Este nivel contiene sólo una división y está reservada para sistemas que
han sido evaluados y no cumplen con ninguna especificación de
seguridad.
 Sin sistemas no confiables, no hay protección para el hardware, el sistema
operativo es inestable y no hay autentificación con respecto a los usuarios
y sus derechos en el acceso a la información.
 Los sistemas operativos que responden a este nivel son MS-DOS y System
7.0 de Macintosh.

11
 Nivel C1: Protección Discrecional
 Se requiere identificación de usuarios que permite el acceso a distinta
información.
 Cada usuario puede manejar su información privada y se hace la
distinción entre los usuarios y el administrador del sistema, quien tiene
control total de acceso.
 Nivel C2: Protección de Acceso Controlado
 Este subnivel fue diseñado para solucionar las debilidades del C1.
 Cuenta con características adicionales que crean un ambiente de acceso
controlado.
 Se debe llevar una auditoria 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 acceso a ciertos archivos, permitir o denegar
datos a usuarios en concreto, con base no sólo en los permisos, sino
también en los niveles de autorización.

12
 Nivel B1: Seguridad Etiquetada
 Soporta seguridad multinivel.
 Se establece que el dueño del archivo no puede modificar los permisos de un
objeto que está bajo control de acceso obligatorio.
 Debe basarse en niveles jerárquicos y no jerárquicos.
 El control MAC sigue el modelo Bell-La Padula.
 Debe implementar DAC para mayor control de acceso.
 Los objetos deben ser etiquetados (asignados) a un dado nivel de seguridad.
 A cada objeto del sistema (usuario, dato, etc.) se le asigna una etiqueta, con un
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 de derecho de accesos
a los distintos objetos.

13
 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 mas elevado de seguridad en
comunicación con otro objeto a un nivel inferior. Así, un disco rígido será
etiquetado por almacenar archivos que son accedidos por distintos
usuarios.
 Se debe presentar un nivel superior verificable.
 El testing debe confirmar que el sistema implementa el diseño.
Addresses conformance with claims, resistance to penetration and correction of flaws
followed by retesting. A requirement to search for covert channels includes the use of
formal methods at higher evaluation levels.

14
 El principio de menor privilegio deber ser incluido en el diseño.
 Trusted Path –provides a communication path that is guaranteed to be
between the user and the Trusted Computing Base (TCB).
 The set of all hardware, software and procedural components that enforce the
security policy.
 In order to break security, an attacker must subvert one or more of them.
 The smaller the TCB, the more secure a system is.

15
Niveles de seguridad
 El control de acceso debe ser aplicado a objetos, individuos y dispositivos.
 El sistema es capaz de alertar a los usuarios si sus condiciones de
accesibilidad y seguridad son modificadas; y el administrador es el
encargado de fijar los canales de almacenamiento y ancho de banda a
utilizar por los demás usuarios.
 Configuration Management –increases for higher levels. This requirement
addresses the identification of configuration items, consistent mappings
among all documentation and code, and tools for generating the Trusted
Computing Base (TCB).

16
 Nivel B3: Dominios de Seguridad
 Refuerza a los dominios con la instalación de hardware: por ejemplo el
hardware de administración de memoria se usa para proteger el dominio
de seguridad de acceso no autorizado a la modificación de objetos de
diferentes dominios de seguridad.
 Este nivel requiere que la terminal del usuario se conecte al sistema por
medio de una conexión segura. Además, cada usuario tiene asignado los
lugares y objetos a los que puede acceder.
 Existe un monitor de referencia que recibe las peticiones de acceso de
cada usuario y las permite o las deniega según las políticas de acceso que
se hayan definido.
Three required properties for reference monitors:
 tamper-proof
 non-bypassable (complete mediation)
 small enough to be analyzable

17
 Nivel B3: Dominios de Seguridad
 Se debe contar con diseño de alto nivel: completo y conceptualmente
simple (testing extensivo). Debe existir un argumento fuerte que
demuestre que el sistema implementa el diseño.
 Todas las estructuras de seguridad deben ser lo suficientemente
pequeñas como para permitir análisis y pruebas ante posibles violaciones.
 La implementación debe utilizar: capas, abstracción y ocultamiento de
información.
 Funciones de seguridad a prueba de interferencias.
 Auditoría: requerida y debe identificar violaciones de seguridad
inminentes. Addresses the existence of an audit mechanism as well as
protection of the audit data. This define what audit records must
contain and what events that must be audited.
 System Architecture –mandates modularity, minimization of complexity,
and other techniques for keeping the TCB as small and simple as possible.
The TCB must be a full reference validation mechanism

18
 Nivel A1: Protección Verificada
 Es el nivel más elevado, incluye un proceso de diseño (verificado), control
y verificación, mediante métodos formales (matemáticos) para asegurar
todos los procesos que realiza un usuario sobre el sistema.
 An formal top-level specification (FTLS) must be produced.
 The FTLS of the TCB must be shown to be consistent with the model by
formal techniques where possible (i.e., where verification tools exist) and
informal ones otherwise.
 The TCB implementation (i.e., in hardware, firmware, and software) must be
informally shown to be consistent with the FTLS.
 Formal analysis techniques must be used to identify and analyze covert
channels. Informal techniques may be used to identify covert timing
channels.

19
 Nivel A1: Protección Verificada
 El software y el hardware son protegidos para evitar infiltraciones ante
traslados o movimientos del equipamiento.
 Trusted Distribution – addresses the integrity of the mapping between
masters and on-site versions of the software as well as acceptance
procedures for the customer.

20
Information Technology Security Evaluation Criteria. ITSEC
 Conformado principalmente por Francia, Alemania y Reino Unido, crearon su
propio estándar de seguridad, al principio de los 90’s, este se conoce como el
Libro Blanco (White Book).
 La correspondencia que se pretende entre los criterios ITSEC y las claves TCSEC
es la siguiente:
Criterios ITSEC Claves TCSEC
E0 D
Functionality-C1, E1 C1
F-C2, E2 C2
F-B1, E3 B1
F-B2, E4 B2
F-B3, E5 B3
F-B3, E6 A1
http://www.ssi.gouv.fr/site_documents/ITSEC/ITSEC-uk.pdf
Se definen siete niveles de
evaluación, denominados E0 a
E6, que representan una
confianza para alcanzar la meta
u objetivo de seguridad. E0
representa una confianza
inadecuada. E1, el punto de
entrada por debajo del cual no
cabe la confianza útil, y E6 el
nivel de confianza más elevado.
There is no functionality class F-A1 as the functionality requirements
of TCSEC class A1 are the same as for class B3

21
ITSEC
 Systems and Products: ITSEC differentiate between systems and
products.
 A "system" is a combination of hard- and software tailored to the needs
of a specific operational environment.
 A "product" is a piece of standard hard- and/or software that can be
incorporated into systems.
 The main difference regarding security is:
 For a system the operational environment is known,
 For a product usually not.
 Systems and products are commonly referred to as "Target Of
Evaluation" (TOE)
http://www.ssi.gouv.fr/site_documents/ITSEC/ITSEC-uk.pdf

22
Target Of Evaluation -TOE
 Examples of TOE include:
 A software application;
 An operating system;
 A software application in combination with an operating system;
 A software application in combination with an operating system and a
workstation;
 An operating system in combination with a workstation;
 A smart card integrated circuit;
 The cryptographic co-processor of a smart card integrated circuit;
 A Local Area Network including all terminals, servers, network equipment
and software;
 A database application excluding the remote client software normally
associated with that database application.

23
Information Technology Security Evaluation Criteria -ITSEC
 Evaluation and Certification:
 The basis of an evaluation is the "security target" that consists of specific
security objectives, threats, a definition of security enforcing functions,
and all security mechanisms employed by a TOE.
 If security enforcing functions are individually specified it is
recommended to present them under the following "generic headings“:
1. Identification and Authentication
2. Access Control
3. Accountability
4. Audit
5. Object Reuse
6. Accuracy
7. Reliability of Service
8. Data Exchange
Fuente: Michael Gehrkea, Andreas Pfitzmannb, and Kai Rannenberg. Information
Technology Security Evaluation Criteria (ITSEC) –a Contribution to Vulnerability?
Assurance is divided into confidence in
the "correctness" of the implementation
of security enforcing functions and
mechanisms and confidence in their
"effectiveness".

24
Common Criteria for Information Technology Security
Evaluation (Common Criteria or CC)
 Los CC nos ofrecen una norma internacional para evaluar la
seguridad de los productos de tecnología de la información. Se
puede pensar en tres diferentes perspectivas desde las cuales los
podemos abordar:
 Como consumidores proveen criterios que determinan las necesidades
de seguridad que deben cumplir los productos que se deseen adquirir.
 Como desarrolladores proveen criterios que permite cubrir
requerimientos de seguridad en diferentes niveles.
 Como evaluadores proporcionan los productos de seguridad que deben
ser cubiertos por los desarrolladores.
ISO/IEC 15408
CCMB-2012-09-001
• Canadá
• Francia
• Alemania
• Reino Unido
• Estados Unidos
• Australia
• Nueva Zelanda
• Finlandia
• Grecia
• Italia
• Holanda
• Noruega
• España

25
Roadmap to CC
Introduction
and general
model
Security
functional
components
Security
assurance
components
CCMB-2012-09-001

26
Conceptos de seguridad y relaciones
CCMB-2012-09-001

27
Conceptos de evaluación y relaciones
CCMB-2012-09-001

28
Requerimientos funcionales
 Contains eleven classes of functional requirements:
 Each contains one or more families
 Elaborate naming and numbering scheme
 Classes:
1. Security Audit,
2. Communication,
3. Cryptographic Support,
4. User Data Protection,
5. Identification and Authentication,
6. Security Management,
7. Privacy,
8. Protection of Security Functions,
9. Resource Utilization,
10. TOE Access,
11. Trusted Path
Families:
• Authentication Failures,
• User Attribute Definition,
• Specification of Secrets,
• User Authentication,
• User Identification, and
• User/Subject Binding -vinculación

29
Requerimientos de aseguramiento
 Ten security assurance classes
 Classes:
1. Protection Profile Evaluation
2. Security Target Evaluation
3. Configuration Management
4. Delivery and Operation
5. Development
6. Guidance Documentation
7. Life Cycle
8. Tests
9. Vulnerabilities Assessment
10. Maintenance of Assurance

30
Evaluation Assurance Levels 1 – 4
 EAL 1: Functionally Tested
 Review of functional and interface specifications
 Some independent testing
 EAL 2: Structurally Tested
 Analysis of security functions, incl. high-level design
 Independent testing, review of developer testing
 EAL 3: Methodically Tested and Checked
 More testing, Some dev. environment controls;
 EAL 4: Methodically Designed, Tested, Reviewed
 Requires more design description, improved confidence that TOE will not
be tampered

31
Evaluation Assurance Levels 5 – 7
 EAL 5: Semiformally Designed and Tested
 Formal model, modular design
 Vulnerability search, covert channel analysis
 EAL 6: Semiformally Verified Design and Tested
 Structured development process
 EAL 7: Formally Verified Design and Tested
 Formal presentation of functional specification
 Product or system design must be simple
 Independent confirmation of developer tests

32
Control de acceso mandatorio (MAC)
 En seguridad informática, MAC es una estrategia de seguridad en la
que sólo el administrador gestiona los controles de acceso.
 El administrador define el uso y acceso a la política, indicará quién tiene
acceso a qué programas y archivos.
 Se aplica estrictamente por el sistema operativo (OS) o de seguridad
del kernel, y no puede ser modificada o cambiada por los usuarios.
 Todos los utilitarios de los usuarios, programas y scripts deben trabajar
dentro de las restricciones de las reglas de acceso proporcionadas por
los módulos de políticas de seguridad que han sido seleccionados.
(https://www.freebsd.org/doc/handbook/mac-planning.html)
 MAC es la más utilizada en sistemas en los que se da prioridad a la
confidencialidad (instalaciones gubernamentales y militares).
 El modelo Bell-LaPadula describe métodos para asegurar la
confidencialidad de los flujos de información. Biba desarrolló un método
similar orientado a la integridad de la información –menos utilizado.

33
Example
objectsubjectsecurity level
Telephone Lists
Activity Logs
E-Mail Files
Personnel Files
UlaleyUnclassified
ClaireConfidential
SamuelSecret
TamaraTop Secret
• Tamara can read all files
• Claire cannot read Personnel or E-Mail Files
• Ulaley can only read Telephone Lists
CS 460 Cyber Security Lab, Spring ‘11
– “Reads up”
disallowed, “reads
down” allowed
– “Writes up” allowed,
“writes down”
disallowed

34
 Antes de implementar cualquier política de MAC, se recomienda una
fase de planificación. Durante las etapas de planificación, un
administrador debe considerar los requerimientos de implementación
y objetivos, como:
 ¿Cómo clasificar la información y los recursos disponibles en los sistemas
destino?
 ¿A qué información o recursos se restringirá el acceso, junto con el tipo
de restricciones que se deben aplicar?
 ¿Qué módulos MAC se requerirán para lograr este objetivo?
 Ejemplo: Security-Enhanced Linux (SELinux).
 Su arquitectura se enfoca en separar las decisiones de las aplicaciones de
seguridad de las políticas de seguridad mismas y racionalizar la cantidad
de software encargado de las aplicaciones de seguridad.
http://es.wikipedia.org/wiki/SELinux

35
 Key terms (https://www.freebsd.org/doc/handbook/mac-inline-
glossary.html)
 El modelo de MAC se basa en etiquetas de seguridad.
 A los sujetos se les da una autorización de seguridad [security clearance]
(secreto máximo, secreto, confidencial, etc.), y a los objetos de datos se
les da una clasificación de seguridad [security classification] (secreto
máximo, secreto, confidencial, etc.).
 La autorización y clasificación de los datos se almacenan en las etiquetas
de seguridad, las cuales están vinculadas a los sujetos específicos y
objetos.
 El sistema asocia una etiqueta de sensibilidad con todos los procesos que
se crean para ejecutar programas.
 Al aplicar una etiqueta, el administrador debe entender sus implicaciones
a fin de evitar un comportamiento inesperado o no deseado del sistema.
(https://www.freebsd.org/doc/handbook/mac-understandlabel.html)

36

37
Consideraciones
 Cuando el sistema está haciendo una decisión de control de acceso,
intenta hacer coincidir la autorización del sujeto con la clasificación del
objeto.
 Por ejemplo, si un usuario tiene una autorización de seguridad de
secreto, y él pide un objeto de datos con una clasificación de seguridad
de secreto máximo, se le negará el acceso al usuario debido a que su
autorización es inferior a la clasificación del objeto.
 En general, los procesos no pueden almacenar información o
comunicarse con otros procesos, a menos que la etiqueta del destino
sea igual a la etiqueta del proceso.
 La política de MAC permite que los procesos lean datos de objetos en la
misma etiqueta o de objetos en una etiqueta inferior.
 Sin embargo, el administrador puede crear un entorno etiquetado en el
que haya disponibles pocos objetos de nivel inferior, o ninguno.
(http://docs.oracle.com/cd/E24842_01/html/E22521/ugintro-14.html)

38
 La arquitectura proporciona un mecanismo para hacer cumplir la
separación de información basado en exigencias de integridad y
confidencialidad.
 La flexibilidad del sistema permite que la política que sea modificada y
ampliada para personalizar la política de seguridad según sea necesario
para cualquier instalación dada.
(https://www.nsa.gov/research/selinux/index.shtml)
 Esto permite abordar amenazas de manipulación (tampering) y la
elusión (bypassing) de mecanismos de seguridad en la aplicación, y
permite el confinamiento de los daños que pueden ser causados por
aplicaciones maliciosas o defectuosas.
(https://www.nsa.gov/research/selinux/index.shtml)
(https://www.nsa.gov/research/selinux/policy.shtml)

39
Control de acceso discrecional (DAC)
 En seguridad informática, DAC es un tipo de control de acceso en el
que un usuario tiene un control completo sobre todos los programas
que posee y ejecuta, y también determina los permisos que otros
usuarios tendrán sobre esos archivos y programas –quién y cómo.
 Debido a que DAC requiere permisos que se asignarán a los que
necesitan tener acceso, DAC es comúnmente descrito como un modelo
de acceso a la "necesidad de conocer".
 DAC is also called identity-based access control (IBAC) or authorization-
based access control
 Ejemplos:
 Passwords for file access
 Capability list
 Owner/Group/Other
 Access control lists (ACL) Sadeghi, Cubaleska @RUB, 2008 - 2009
• Flexible y adaptable a muchos sistemas y
aplicaciones.
• Ampliamente usado, especialmente en
ambientes comerciales e industriales.

40
Ejemplos
 Ejemplo 1:
 Procesos proc1, proc2
 Archivos arch1, arch2
 Permisos r=read, w=write, x=execute, a=append, o=own
 Ejemplo 2:
 Usuarios alice, bob
 Archivos memo.doc, edit.exe, fun.com
 Permisos r = read, w = write, x = execute

41
Lista de control de acceso (ACL)
 Una ACL es un conjunto de datos que informa al
Sistema operativo de la computadora qué
permisos, o derechos de acceso, tiene un usuario o
grupo sobre un objeto específico, como un
directorio o archivo.
 Cada objeto tiene un atributo único de seguridad
que identifica a los usuarios que pueden acceder a
este objeto, y la ACL es una lista de cada objeto y
privilegios de acceso dados al usuario como
lectura, escritura o ejecución.
 En redes informáticas, ACL se refiere a una lista de
reglas que detallan puertos de servicio o nombres
de dominios (de redes) que están disponibles en
un terminal u otro dispositivo de capa de red, cada
uno de ellos con una lista de terminales y/o redes
que tienen permiso para usar el servicio.
 Eficiencia y lentitud.
Un Sistema de Control
de Accesos, administra
el ingreso a áreas
restringidas, y evita así
que personas no
autorizadas o
indeseables tengan la
libertad de acceder a la
empresa. Así mismo
con un Sistema de
Control de Accesos se
puede tener
conocimiento de la
asistencia del personal,
horarios de ingreso y
salida, y también
poder tener un control
histórico de entradas
de personas a todas las
áreas (para poder
tener en cuenta
quienes podrían ser los
posibles responsables
de algún siniestro).

42

43
Control de acceso basado en roles -RBAC
 Propuesto por Ferraiolo y Kuhn en 1992.
 Es un enfoque para restringir acceso al sistema a usuarios autorizados.
 Combina aspectos de DAC y de MAC, pero con una visión más
orientada a la estructura organizacional.
 RBAC es referido algunas veces como seguridad basada en roles.
 Básicamente consiste en la creación de roles para los trabajos o funciones
que se realizan en la organización.
 Los miembros del staff se asignan a roles y a través de estos roles
adquieren permisos para ejecutar funciones del sistema.
 Los sujetos acceden a los objetos en base a las actividades que (los
sujetos) llevan a cabo en el sistema.
Conjunto de acciones y responsabilidades asociadas con una actividad
en particular
ANSI/INCITS 359-2004

44
Control de acceso basado en roles
 Para implementar RBAC se necesitan
mecanismos que permitan:
 Identificar los roles en un sistema y
asignar los sujetos a los roles
definidos.
 Establecer los permisos de acceso a
los objetos para cada rol.
 Establecer permisos a los sujetos para
que puedan adoptar roles.
 Características:
 Administración de autorizaciones
 Jerarquía de roles
 Menor privilegio
 Separación de responsabilidades
Dificultad de
establecer los roles y
definir sus alcances
Ejemplos:
• Sun Solaris
• Microsoft Active
Directory
• Base de datos
Oracle
• Base de Datos MS
Sql Server
http://www-2.dc.uba.ar/materias/seginf/material/Clase02-Unidad2_vf.pdf

45
 Administración de autorizaciones
 La asignación de permisos a usuarios tiene dos partes:
 asociar usuarios a roles
 asignar permisos para objetos a roles.
 Si un usuario cambia de tareas, solo basta con cambiarle el rol.
 Jerarquía de roles
 Los roles también poseen relaciones de jerarquía.
 Pueden heredar privilegios y permisos de otros roles de menor
jerarquía, simplificando la administración de las autorizaciones

46
 Menor privilegio
 Permite implementar la política del menor privilegio posible.
 Si una tarea no va a ser ejecutada por un usuario, entonces su rol no
tendrá los permisos para hacerla, de esta manera se minimizan riesgos de
daños.
 Separación de responsabilidades
 Se basa en el principio de que ningún usuario tenga suficientes privilegios
para usar el sistema en su propio beneficio.
 Por ejemplo, una persona encargada de autorizar un pago no debe ser el
beneficiario de ese pago.
 Se puede establecer de dos formas:
 Estáticamente: definiendo los roles excluyentes para un mismo usuario;
 Dinámicamente: realizando el control al momento de acceso.

47
Métodos o modos de acceso
 …
 …
¿Aportes?

48
Trabajo práctico
 Una software factory local contrata su empresa de seguridad para que
analice y evalúe el nivel de seguridad de la información que ha logrado
implementar para sus entregables (Dominio: Control de acceso)
 ¿Cómo plantearía realizar esta consultoría?
 Grupos de tres.
 30 minutos.

49
Revisar
 https://partner.microsoft.com/spain/40053431

Mg. Ing. Jack Daniel Cáceres Meza, PMP
jack_caceres@hotmail.com
Gracias por su atención
¿Preguntas?

Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relacionados con el control de acceso

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relacionados con el control de acceso

Similar to Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relacionados con el control de acceso (20)

More from Jack Daniel Cáceres Meza

More from Jack Daniel Cáceres Meza (20)

Recently uploaded

Recently uploaded (20)

Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relacionados con el control de acceso