Peter Leight and Richard Hammer
August 2006
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?
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
Outcome Statement:
The 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 approach 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
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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.
Operational choices are extensive and could include, among
others: read, write, execute, access, append, and update.
Peter Leight and Richard Hammer
August 2006
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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” role
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 as 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 different
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 file, 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
RBAC Standard and expanded upon for illustrative
purposes.
Peter Leight and Richard Hammer
August 2006
RBAC Flow Diagram
Financial
Data
Read
M
em
be
r
Member
Role:
Engineer
Mary
Member
Role:
Engineer
Team
Leader
Member
Joe
ber
Mem
Member
Role:
Finance
Department
Role:
Team
Leader
r
Membe
/Write
a d/
Re
Read/Write
ly
On
Project
Data
Sam
Jill
Jim
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
The diagram above shows RBAC data flow.
the many-to-many nature of RBAC.
This illustrates
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.
grants him the permissions of all 3 roles.
example of how hierarchical RBAC works.
This
This is an
Each member
inherits the permissions of the parent. Note that Jim 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
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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 access.
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
object, 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 privileges 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 internal 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 providing 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 including 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_Access_Control
Peter Leight and Richard Hammer
August 2006
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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
user 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 utilize
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 UID 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
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)
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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 support 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 changes 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 example, 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 from 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
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 !
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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 sensitive 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
groups 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
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
RBAC cannot be implemented 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 and 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 work 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 not 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
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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, and
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 extended 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
controlled by role creation, the assignment of
operations/permissions for objects, and the assignment of
subjects to roles.
Peter Leight and Richard Hammer
August 2006
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 wireless
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)
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
Many vendors now support RBAC, allowing RBAC to be used as
a multi-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 support 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 on who or what can access network
resources, and in what manner.
RBAC is the only DiD
framework discussed that can provide these types of multitiered 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 subjects, 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 restricted 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 be 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 becomes a subject.
Peter Leight and Richard Hammer
August 2006
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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 specifies
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 administrative 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.
Roles 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 RevokePermission 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 controls.
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
given 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 assigned 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);
—RoleOperationsOnObject (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.
Because of this problem, Version 0.1 of a Draft for a NIST
Role Based Access Control Implementation Standard was
released in January of 2006.
Peter Leight and Richard Hammer
August 2006
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
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 standard 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
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
Security Leadership Essentials – Defense-in-Depth – © 2006 SANS
RBAC is a great model for defense-in-depth.
model that defines access based on roles.
It is the only
It does require
a clear policy and a lot of up-front work before
implementation, but the return on investment, in reduced
administration 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 been
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, “Proposed NIST
Standard for Role-Based 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/rbac/draft-rbac-implementation-stdv01.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 Group 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.
http://csrc.nist.gov/rbac/
url:
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/Wed_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/support/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.
http://docs.sun.com/app/docs/doc/8177501/6mmql74bk?l=de&a=view
url:
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 Computing 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-BIOS 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 position 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 assign 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
d.)
August 2006
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-inDepth ?
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 defined in the proposed standard ?
a.)
Administrative
b.)
Audit
c.)
Supportive System
d.)
Review
Answer:B
Peter Leight and Richard Hammer
Slide 13 – no question
Slide 14 – Conclusion
August 2006