View Report - SANS Technology Institute

towerdevelopmentData Management

Dec 16, 2012 (4 years and 6 months ago)

320 views

Peter Leight and Richard Hammer


August 2006


Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
Role
-
Based Access Control (RBAC)
Approach for Defense
-
in
-
Depth

What is Role
-
Based Access Control (RBAC)?

What are the advantages to implementing
RBAC?

What are the challenges to implementing
RBAC?

How can RBAC be used as a framework for
defense in Depth?

How will the RBAC implementation standard
help?


Outcome Statement:

T
he student will
learn fundamental
concepts and terminology related to Role
-
Based Access
Control (RBAC)
, its strengths and weaknesses, and how it
can be
used as an appr
oach for Defense
-
in
-
Depth.

The
student will also be introduced to RBAC standards and
understand the importance of standards for emerging RBAC
technologies.

Peter Leight and Richard Hammer


August 2006


Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
What is RBAC?

Role
-
Based Access Control

Permission to perform an operation on an
object is assigned to roles, not to users

Users are assigned to roles

Roles are assigned permissions

Users acquire their permissions based on
the roles they are assigned


The key to understanding role
-
based access control is
realizing that users are not directly allowed to perform an
operation on an object. Instead, users are assigned to
roles based on their job duties. These roles are then
given permissions to perform operations on objects. So,
for a

user to access data, the user must be a member of a
role
that has permission to perform operations on the
object
.

Operation
al

choices are extensive and could include, among
others
:

read, write, execute, access, append,
and
update.

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC is Many
-
to
-
Many

Users may be assigned many roles

Roles may have many users assigned to them

Roles may be assigned to many other roles

Roles may be assigned many permissions

Permissions may be assigned to many roles

Permissions may be granted to perform many
different types of operations on an object


RBAC relationships are many
-
to
-
many in nature.


Users can be members of many different roles, and roles
may have many different users as members. For example,
Roberta may be a member of the “Generic Users” rol
e
and of the “Engineering” role, each giving her a
different set of permissions.

Roles may have many users and other roles as members, and
roles might be assigned to multiple other roles. For
example, the “Finance” role might have 100 finance
employees a
s members as well as the “Finance Manager”
role as a member. In turn, the “Finance Manager” role
might also be assigned to the “Generic Managers” role.

Roles may be assigned many different permissions, and the
same permissions may be assigned to many diffe
rent
roles. For example, the “Payroll” role may be assigned
the ability to read historical payroll documents, the
Peter Leight and Richard Hammer


August 2006

ability to change the current week’s payroll
documents, and the ability to read all time and
attendance files. The “Generic HR” role, the “CFO

role, and the “Generic Managers” role may also be
granted the ability to read all time and attendance
documents.


Permissions may be granted to perform many different types
of operations on an object. For example, permissions
to read the contents of a fi
le, change the content of
a file, and delete a file may all be given to the same
person, and different roles might have only one or two
of these options.


*** The above description of RBACS many to many
relationships is paraphrased from the NIST proposed
R
BAC Standard and expanded upon for illustrative
purposes.
Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC Flow Diagram
Role
:
Finance
Department
Role
:
Engineer

Financial
Data

Project
Data
Role
:
Engineer
Team
Leader
R
e
a
d
/
W
r
i
t
e
R
e
a
d
/
O
n
l
y
R
e
a
d
/
W
r
i
t
e
Joe
Mary
Sam
Jill
Jim
M
e
m
b
e
r
M
e
m
b
e
r
M
e
m
b
e
r
M
e
m
b
e
r
M
e
m
b
e
r
M
e
m
b
e
r
Role
:
Team
Leader
M
e
m
b
e
r


The diagram above shows RBAC data flow. This illustrates
the many
-
to
-
many nature of RBAC. Jim is a member of the
“Engineer Team

Leader” role and that role is a member of
the “Team Leader” role and the “Engineer” role. This
grants him the permissions of all 3 roles. This is an
example of how hierarchical RBAC works. Each member
inherits the permissions of the parent. Note that J
im could
have been granted memberships in both the “Team Leader” and
“Engineer” roles separately, but this is a cleaner, clearer
solution.
Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
What are the Advantages of
RBAC?

Once implemented RBAC simplifies
system administration

Strong support for separation of duties

Good auditing support

Considered best practice by many


RBAC simplifies system administration once all

roles and
permissions are set up. Adding, modifying, or deleting
user permissions is as simple as changing the roles the
user is a member of. No longer will system administrators
have to go to each folder, directory or system and remove
the user’s acces
s. If a person changes jobs, only role
membership for the person needs to change.


RBAC has built
-
in support for separation of duties based on
role membership. Roles can be clearly defined to help
reduce the chances of fraud or conflict of interest. For
example, if the purchaser of an item cannot be the approver
of the same purchase, it reduces the possibility of a
conflict of interest.


Peter Leight and Richard Hammer


August 2006

RBAC has built
-
in auditing support called reviews. Reviews
can display all users or roles that have access to an
objec
t, or what users are assigned to a role. The built
-
in
reviews make auditing a much simpler task.


RBAC is considered by many to be a best practice for access
control.



Role
-
based
-
access
-
control (RBAC) is considered the most
effective and secured privileg
es management approach


---

Mr Dave Yip, President & Founder, Gamatech


“SOX does not provide details, nor does it prescribe a
solution as to how to achieve compliance. Section 404(a) of
the SOX act simply sets a deadline for establishing
“adequate in
ternal controls” around financial reporting and
its governance.

Role
-
Based Access Control (RBAC) is well
recognized as the best practice for setting such controls.”

From http://www.proatria.com/sox_sage_eurekify.pdf


“Most attractive solution for providin
g security features
in multi
-
domain digital government infrastructure,” [Joshi
et al. 2001b, on page 226 of NIST document


The use of RBAC to manage user privileges within a single
system or application is widely accepted as a best
practice. Systems includ
ing
Microsoft

Active Directory
,
SELinux
,
Solaris
,
Oracle DBMS
,
PostgreSQL 8.1
,
SAP R/3

and
many others effectively implement some form of RBAC.

From
http://en.wikipedia.org/wiki/Role
-
Based_Acc
ess_Control

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC Simplifies System Administration

When a user changes positions

Her roles are changed to reflect her new position

Her replacement is assigned her old roles

No need to remove user’s old access on each
object

If roles are well defined, the system administrator
only needs to add a user to their assigned roles and
the user has access to all the resources they require
to complete their job


RBAC simplifies system administration by reducing the
number of operations the system administrators must perform
when users change positions or leave the company. If a
use
r changes positions in the company, all the system
administrator must do is change her roles. Her replacement
is then assigned her roles and will have full access to all
resources required to perform the new position. Since
users are not assigned direct
access to objects there will
be no need to touch each object and remove permissions.
No
longer will we see dead Security Identifiers (SID) or User IDs (UID) having access to
directories or files.


Remember, humans prefer names like Joe, but computers util
ize
numbers.


Windows assigns users a unique SID and Unix systems assign users a unique
UID that the system uses to identify the user.


If Joe was granted access to hundreds of
files and leaves the company; Joe would be deleted as a user, but his SID or UI
D would
still be a valid number and show up as still having access to the files Joe had access to.


The danger is that another user will be added and inadvertently assigned Joe's old SID or
Peter Leight and Richard Hammer


August 2006

UID, giving the new person access to all the files Joe had access
to.


RBAC eliminates
this issue by assigning Joe membership in various roles. We then only need to remove
Joe from those roles when he leaves the company This is far simpler than removing Joe’s
access to hundreds or thousands of objects one at a time.
Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
Separation of Duties

Manages conflict of interest policy

Reduces chances of fraud

Spreads critical duties across roles and
in turn users

RBAC has built
-
in support for:

Static Separation of duties (SSD)

Dynamic Separation of duties (DSD)



Separation of Duties reduces a company’s exposure to fraud
and conflict of interest. It also insures that critical
business functions do not rely on a single person.


RBAC has built
-
in s
upport for separation of duties. Roles
determine what operations a user can and can not perform.
You can enforce a policy that states that a role cannot be
both a purchaser and an approver of the same product, or
that the person implementing firewall cha
nges cannot audit
those same changes.


RBAC supports two type of separation of duties; static
separation of duties (SSD) and dynamic separation of duties
(DSD).

Peter Leight and Richard Hammer


August 2006

Static Separation of Duties defines role memberships that
are mutually exclusive. For examp
le, RBAC can ensure that
users cannot be members of both the purchasing role and the
approving role. That is how SSD ensures that the same
person cannot purchase and approve the purchase.


Dynamic Separation of Duties allows the same person to be
in the

purchasing role and the approving role, but they
would be prohibited from approving their own purchase.
They would only be able to approve the purchases of others.
Another example would be restricting the person who made
firewall configuration changes f
rom auditing and approving
those same changes.


In the SSD model, a user may not be members of both roles.
In the DSD model, a user could be a member of both roles,
but could not function in both capacities for the same
linked transactions.
Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC Improves Auditing

User, role, and permission reviews are
built into RBAC

Much easier to determine if an object
should be accessed from a role instead
of a person

Should Jane access the payroll object? ???

Should the hotdog vendors role access the
payroll object? NO !



RBAC has built in support for reviews. These reviews allow
an auditor to quickly get a report of all users or roles
that have access to an object. Reviews exist for looking
at all permissions that

a role has or what users are
assigned to a role. Reviews exist for viewing separation
of duties as well.


The use of these audit functions provides a powerful tool
for immediately determining access control statuses.


For example, let us envision a sensi
tive corporate document
stored on a server. If we assign 12 different managerial
roles different types of access to the document, this is
what we would see when we went to audit the document. We
would then have to determine the memberships of all those
Peter Leight and Richard Hammer


August 2006

gro
ups and calculate the real permissions that individuals
were granted. However, with RBAC functions, we could
immediately determine who had access to the document.
Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
Challenges Implementing RBAC

Policy must be clearly defined or RBAC breaks
down completely

Roles must be created that reflect business needs

Permissions for roles to access objects must be
determined

Membership is each role must be determined

Up
-
front work requires a lot of time and effort

RBAC standards have not resulted in
compatible vendor implementations


RBAC cannot be implement
ed without having security policy
clearly defined. System administrators should not be the
people determining what roles users should be assigned to,
or what roles need to perform an operation on an object.
Users, roles, and permissions must be defined a
nd a
mechanism for assigning them must be determined. Of all
the approaches to defense
-
in
-
depth, RBAC is the only one
that forces an organization to define policy so granularly
before implementation can begin.


Implementing RBAC takes a lot of up front wo
rk in order to
define a policy and its resultant RBAC schema, however, in
the long run, RBAC will reduce maintenance costs and
improve security and auditing functions.


Peter Leight and Richard Hammer


August 2006

Although there is an ANSI standard for RBAC, products that
claim to support RBAC are no
t necessarily interoperable.
Luckily, there is an RBAC implementation standard in its
first draft, and there is promise that this will facilitate
interoperability. We will discuss the standards later in
this module.

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC as a
DiD
Framework

Extend the concept of a user to include:

Computers or networks

Agents (ex. Web front end accessing a
database)

Permission is approval to access or perform
some action on an object

Objects extended to include:

Data, databases or information container

Computers, networks or network resources

Programs or applications


To make RBAC a complete Defense
-
in
-
Depth framework some
modifications to the earlier definition must be made. The
definition of a user must be extended beyond a human, or
user account, to include computer systems, networks, a
nd
program agents. We also need to expand our definition of
objects to include data, databases, information containers
(folders, directories, drives, etc.), computer systems,
networks, printers, scanners, and applications. Once these
definitions are exte
nded RBAC can be used as a true
Defense
-
in
-
Depth framework allowing varied network
resources to be members of roles and have permissions to
perform a variety of operations on many other network
resources. All of these operations can then be potentially
co
ntrolled by role creation, the assignment of
operations/permissions for objects, and the assignment of
subjects to roles.

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC for Network Design

Use RBAC as the access mechanism for your entire network
infrastructure

Routers

Firewalls

VPNs

VLANS

Servers

Granular access controls can ensure all parameters are correct
before access is granted

Joe might have access to financial data, but not from the wirele
ss
VLAN (Sensitive finance data should only be accessible from the
office VLAN)

Sally might have access to all external Internet sites, but only
from
her assigned IP address (HR determines lewd content of website
but not from out in the cubicles)


Many vendors now support RBAC, allowing RBAC to be used as
a mult
i
-
tiered defense
-
in
-
depth methodology. Cisco has
included RBAC support in their router, VLAN, VPN and
firewall products. Secure Computing includes RBAC support
in their Enterprise product line. Windows, Solaris, HP,
AIX, and several flavors of Linux sup
port RBAC in their
operating systems as well. This range of vendor products
will allow network protections to be designed using the
RBAC framework for defense
-
in
-
depth.


Having the ability to use RBAC in multiple capacities will
allow redundant checks o
n who or what can access network
resources, and in what manner. RBAC is the only DiD
framework discussed that can provide these types of multi
-
tiered access checks on what types of access subjects will
have.

Peter Leight and Richard Hammer


August 2006


By utilizing VLAN’s or IP addresses as subje
cts, RBAC could
be used to limit where people are allowed to perform
operations. For instance, Joe might be able to access
sensitive Human Resources data from the office, but not
from any of the wireless devices throughout the company.
So, Joe could be re
stricted to his office VLAN by utilizing
RBAC. Here, the VLAN becomes a subject.


Additionally, Sally might need to check websites for adult
content, so she could be granted unfiltered internet
access. This could present potential problems, so RBAC
could b
e used to ensure that she doesn’t visit questionable
sites in public view from “cubicle
-
land” where passers
-
by
might be offended. Instead, Sally would only be
“unfiltered” from the specific IP address of her office
desktop machine. Here, the IP address bec
omes a subject.

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
Server Access Control

RBAC allows granular access control to
server resources based on roles

Servers can use RBAC to control access

Documents or document containers

Resources (Printers, CDs, USB Ports, etc.)

Applications (Database, WWW, FTP, etc.)

Applications can restrict what data or
reports a role can access



Implementing RBAC allows for granular access control of all
server resources. Roles can be assigned restrictive
permissions since users can be assigned too many roles.

Security policy can be followed exactly by assigning access
to documents and directories on a strict need
-
to
-
know
basis. Control of network resources can be finely
controlled by roles. Applications can use roles and
separation of duties to restrict what

type of access or
reports are allowed.

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
RBAC Standards

Proposed NIST Standard for Role
-
Based Access
Control (2001)

Users, roles, permissions, operations, objects

Core and Hierarchical RBAC

Separation of duties

Administrative functions, supportive System
functions, review functions

ANSI/INCITS 359
-
2004

Draft NIST Role Based Access Control
Implementation Standard
-
2006


The 2001 proposed NIST standard defined RBAC model elements
as well as functional requirements. It set out to define
users, roles, operations and

objects. It defined core,
hierarchical, and constrained RBAC elements. It should be
noted that our earlier definition and explanations of RBAC
include the NIST hierarchical and constrained features as
well as core RBAC features. Hierarchical RBAC speci
fies
roles as being permitted to be members of other roles.
Constrained RBAC defines how separation of duties can be
implemented. NIST also includes a scaled
-
down core RBAC
model with a smaller set of requirements.


The proposed standard defined administ
rative functions that
must be included in a product, such as adding users and
roles; defined supporting system functions such as how
sessions are added and removed; and defined review
Peter Leight and Richard Hammer


August 2006

functions such as displaying all users that are members of
a role.


Rol
es can be added and removed with the AddRole and
DeleteRole functions. Users can be added and removed with
the AddUser and DeleteUser functions. The AssignUser and
DeassignUser functions handle user memberships in roles,
and GrantPermission and RevokePerm
ission functions assign
or take away permissions from roles.


Now let’s look at some supporting system functions and
their related commands: When a user initiates a session
(CreateSession), a default set of active roles is defined.
During a session a user

can add a role (AddActiveRole) or
drop a role (DropActiveRole), as well as check whether the
subject is able to perform a specific action on an object
(CheckAccess). These commands allow user sessions to be
dynamic instead of static in regards to access c
ontrols.


RBAC’s audit commands provide a powerful tool for access
control evaluation. Below are listed functions from the
proposed standard:

Mandatory (M) and Optional (O) review functions are:


AssignedUsers (M): returns the set of users assigned to a
gi
ven role;


AssignedRoles (M): returns the set of roles assigned to a
given user;


RolePermissions (O): returns the set of permissions
granted to a given role;


UserPermissions (O): returns the set of permissions a
given user gets through

his or her assigne
d roles;


SessionRoles(O): returns the set of active roles
associated with a session;


SessionPermissions (O): returns the set of permissions
available in the session

Peter Leight and Richard Hammer


August 2006

(i.e., union of all permissions assigned to sesssion’s
active roles);


RoleOperationsOnOb
ject (O): returns the set of operations
a given role may

perform on a given object; and


UserOperationsOnObject (O): returns the set of operations
a given user may

perform on a given object (obtained either directly or
through his or her

assigned roles).


(Above standards information taken from NIST ,p.242
-
243)


In 2004, ANSI adopted the 359
-
2004 RBAC standard based on
the above
-
mentioned NIST proposal. However, vendors
continued deploying their products without a clear
commitment to interoperability.


Bec
ause of this problem, Version 0.1 of a Draft for a
NIST
Role Based Access Contro
l Implementation Standard was
released in January of 2006.



Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
How the Standard Will Help

It will give vendors a common model
and language

Will supply functional requirements that
vendors must implement to become
RBAC compliant

Will help consumers choose products

Will help products become interoperable


Without an approved implementation standard,

vendors are
implementing RBAC in their own unique ways. While the ANSI
standard defines a common model, language, and library of
functions, different vendor implementations of RBAC
continue to proliferate. It is hoped that the proposed
implementation st
andard will enable true “Defense
-
in
-
Depth
RBAC” to flourish.


. This will in turn give consumers the ability to pick
products that will work together, and further drive the
vendors towards a common model.

Peter Leight and Richard Hammer


August 2006



Security Leadership Essentials

Defense
-
in
-
Depth

© 2006 SANS
Conclusion

RBAC is a great defense in depth model

RBAC requires policy to be clearly defined
before implementation

RBAC does reduce system administration
duties once implemented

RBAC improves auditing and facilitates
separation of duties

An implementation standard is required
before RBAC can fully realize its potential as a
approach to defense
-
in
-
depth


RBAC is a great model for defense
-
in
-
depth. It is the only
model that defines access based on roles. It does require
a clear policy and a lot of up
-
front work before
implementation, but the return on investment, in reduced
administrat
ion and increased security, are well worth the
effort. Separation of duties and the rich auditing features
are keys to this increased security.


Finally, the biggest obstacle to the proliferation of
integrated RBAC as an approach to Defense
-
in
-
Depth has be
en
the lack of a fully fleshed
-
out implementation standard.
The new NIST standard hopes to remedy this problem.


Peter Leight and Richard Hammer


August 2006

References:


1.

DAVID F. FERRAIOLO, RAVI SANDHU, SERBAN GAVRILA, D.
RICHARD KUHN and RAMASWAMY CHANDRAMOULI,

Propos
ed NIST
Standard for Role
-
Ba
sed
Access Control
”, 2001. url:

http://csrc.nist.gov/rbac/rbacSTD
-
ACM.pdf


2.

Draft

NIST RBAC Implementation Standard

, January 2006.
url:

http://csrc.nist.gov/rb
ac/draft
-
rbac
-
implementation
-
std
-
v01.pdf


3.

US Navy,

Enterprise Dynamic Access Control

, March 2006.
url:

http://csrc.nist.gov/rbac/EDACv2overview.pdf


4.

Michael P. Gallaher, Ph.D., Alan C. O’Connor, B.A., Brian
Kropp,
Ph.D.,
RTI, “
The Economic Impact of Role
-
Based
Access Control”, March 2002. Url:

http://www.rti.org/pubs/Role
-
Based_Access.pdf



5.

Rick Kuhn, NIST, “
Proposal for INCITS CS1 to Establish a
Task G
roup on Role Based Access Control (RBAC)”, May 24,
2005
. url:

http://www.incits.org/tc_home/CS1/2005docs/cs1050010.pdf




6.

NIST, “Role Based Access Control” homepage. url:

http://csrc.nist.gov/rbac/


7.

Link to
ANSI/INCITS 359
-
2004

url:

http://www.techstreet.com/cgi
-
bin/detail?product_id=1151353



8.

Wikipedia

http://en.wikipedia.org/wiki/Role
-
Based_Access_
Control

Peter Leight and Richard Hammer


August 2006

Vendors that support RBAC:


1.

Prof. Ravi Sandhu, “Role
-
Based Access Control (RBAC) with
SingleSignOn.Net's Secure Identity Appliance”. url:

http://www.acsac.org/2001/case/We
d_C_1330_Sandhu_SSN.pdf#
se
arch=%22rbac%20pki%22


2.

Bhold Company. url:

http://www.bholdcompany.com/subsub.asp?page=3&det=14


3.

Dell OpenManage Security. url:

http://support.dell.com/suppo
rt/edocs/software/smsom/4.4/en
/ug/security.htm


4.

HP
-
UX 11i Identity Management Integration. url:

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo
.do?productNumber=IdMIntegration


5.

Sun Cluster Geographic Edition Software and RBAC
. url:

http://docs.sun.com/app/docs/doc/817
-
7501/6mmql74bk?l=de&a=view


6.

Cisco Administrative Policy Engine. url:

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cap
e/admin_gd/ovrvw_ad.htm#xtocid4


7.

Secure Compu
ting Enterprise Solutions. url:

http://www.securecomputing.com/index.cfm?sKey=939


8.

Watson SCS, Identity Management. url:

http://www.watsonscs.com/report/identitycontrol.html


9.

Dave McPherson, Microsoft Corporation, “Role
-
Based Access
Control for Multi
-
tier Applications Using Authorization
Manager”, July 31, 2004. url:

http://technet2.microsoft.com/WindowsServer/en/library/72b5
5950
-
86cc
-
4c7f
-
8fbf
-
3063276cd0b61033.mspx?mfr=true


10.

Yuichi Nakamura,

“SELinux Policy Editor RBAC(Role
Based Access Control)

guide (for Ver 2.0))”, 07
-
05
-
2006.
url:

http://seedit.sourceforge.net/doc/2.0/rbac_guide/



Peter Leight and Richard Hammer


August 2006


Exam Questions


Slide 1


Intro Slide


Slide 2


RBAC is an acronym for ?

a.)

Rule
-
Based Access Control

b.)

Random
-
BIOS Access Control

c.)

Role
-
Based Access Control

d.)

Real
-
BI
OS Access Control

Answer:C


Slide 3


Which of the following is NOT true ?

a.)

Users may be assigned to many roles

b.)

Roles may contain many users

c.)

The same permission may be granted to many roles

d.)

None of the above

Answer:D


Slide 4


Flow Diagram


Slide 5


Which

of the following statements is not TRUE
concerning RBAC ?

a.)

Great auditing features

b.)

Easy Implementation

c.)

Separation of Duties

d.)

Considered a Best Practice by Many

Answer:B





Peter Leight and Richard Hammer


August 2006

Slide 6
-

Which of the following is true about RBAC?

a.) When a user leaves a positi
on the system
administrator must remove their access from every
object

b.) When changing positions the system administrator
changes the roles that the user is a member of

c.) When a user leaves an organization their role is
deleted

d.) Separation of duties

mandates the restriction of
users to one role

Answer:B


Slide 7


Which of the following is not a proposed RBAC
method of Separating Duties ?

a.)

Mandatory Separation of Duties (MSD)

b.)

Static Separation of Duties (SSD)

c.)

Dynamic Separation of Duties (DSD)

d.)

None of

the Above

Answer:A


Slide 8


no question


Slide 9


Which of the following is true ?

a.)

Successful implementation of RBAC need not take
security policy into consideration

b.)

One advantage of RBAC is that you can loosely define
your security policy and then ass
ign permissions
directly to the individual based on an immediate
business need

c.)

Successful RBAC implementation requires substantial
up
-
front work defining your security policy

Peter Leight and Richard Hammer


August 2006

d.)

RBAC is an efficient replacement for written
security policies

Answer:C


Slide 10



Which of the following would not be considered
an extension of valid RBAC subjects for Defense
-
in
-
Depth

a.)

Computers

b.)

Networks

c.)

Agents

d.)

Users

Answer:D

(note to test
-
developers: users are the original subject,
DiD extends this to the other 3 choices)


Slide 11



Which of the following could not be integrated
into a defensive posture utilizing RBAC for Defense
-
in
-
Depth ?

a.)

VLAN’s

b.)

Routers

c.)

Firewalls

d.)

None of the Above

Answer:D


Slide 12


no question


Slide 13


Which of the following is not a set of RBAC
functions d
efined in the proposed standard ?

a.)

Administrative

b.)

Audit

c.)

Supportive System

d.)

Review

Answer:B

Peter Leight and Richard Hammer


August 2006

Slide 13


no question


Slide 14


Conclusion