Below is a great discussion about the pros and cons of RBAC along with
some of the infrastructure issues that accompany its use. Bottom line:
RBAC is a great tool, but there's much more to using it than having an
application that supports it . . .
Cheers,
/g
-------- Original Message --------
Subject: Re: [SC-L] ZDNnet: Securing data from the threat within
[bybuying products]
Date: Wed, 19 Jan 2005 12:01:30 -0500
From: John Steven <jsteven@cigital.com>
To: Kenneth R. van Wyk <Ken@KRvW.com>, Crispin Cowan
<crispin@immunix.com>, Secure Coding Mailing List <SC-L@securecoding.org>
All,
I agree with Crispin in that: RBAC will not completely alleviate the
problem. Whether or not you have a handle on role-based access controls (No:
most people don't--they're still trying to figure out how to roll out
directory services) those authorized users within your circles of trust will
still unwittingly leak information and be socially engineered. Their
privilege may even be leveraged when a [potentially external] threat attacks
an organization's software by subverting authentication, client/server
access schemes, or more directly by subverting or forging: tokens / keys /
passphrases / [whatever].
There are a lot clients in my portfolio that are trying to adopt RBAC, code
signing/privilege, and other more advanced software controls. Are they going
to succeed wholesale throughout their organization: No, not for the next 3
years. Should they scrap this massive expenditure? I say no. Will it solve
the problem? (as we've said: No) It's beneficial though: Yes, here's why:
In the above attack scenarios having a detailed RBAC scheme deployed means
that when access is stolen authorization isn't all-encompassing. This
yields:
***RBAC Advantage #1: RBAC can reduce the impact (of access/auth) of a
successful attack. The attacker gains only the privileges of the victimized
user/role.
Organizations need not role out RBAC to the entire Enterprise to see value
from it. Start small with both roles AND applications.
***Guide: Start with that infrastructure and those applications that are
built on a platform supporting user, role, and code privilege: J2EE or .NET.
***Guide: Start with an application whose roles are well defined because
they're central to your organization's business. It's essential that users
fit within a single role well here too, as you don't want to try to tackle
delegation, entitlement, and all that in your pilot. It's ok if your target
application interacts with partners, it need not be entirely internal, as
long as you can associate roles easily with your partner's users.
***Avoid: those applications that interact with other applications (or
partners) through a conduit that authenticates host-to-host only...
Especially it's known that rich role structure should exist on top of
that--but currently doesn't.
In order for RBAC to succeed, an organization needs to begin tackling role
definition and data sensitivity classifications. This should be an essential
piece of software's development anyways.
*** RBAC Advantage #2: RBAC forces use case an organization to conduct
activities that help define sensitive classes of data and their mapping to
roles and privileges through workflows. Now the dev. organization has a
reason to think about data, roles, workflows, as part of use case creation
and requirements engineering. They even have an element of design to
characterize what might have otherwise have been trapped in use cases,
policy, <insert named stack of paper here> and ignored.
As an organization gets more experienced and capable at defining roles,
privilege, and sensitivity of data, they can start to make this more of an
Enterprise-wide pursuit.
***Avoid: trying to hold app teams responsible for things their
platform/toolkits don't support. It's still useful to have your C
programmers think about workflows, misuse, privilege, and so forth, but it's
ridiculous to try to have them hammer some RBAC-like nonsense into
production code. NOTE: I'm not advocating they ignore things like
authentication...
***Guide: As systems begin to interoperate, make sure that roles expand
based on real-life workflows. In cases where a role's privilege changes as
it moves between application contexts, handle that with programmatic and
declarative security mechanisms. Excellent, now you can use THOSE features
of the J2EE and .NET platforms too.
***Avoid: Allowing the overloading of role names, and roles gaining
disparate meaning in the vacuum of only a single app. When apps begin
interoperate the privilege isomorphism will break down and lead to very
inappropriate user privileges.
I'll stop here.... This has begun more a defense of RBAC as a pursuit than a
response to the original article. Still, I think RBAC _IS_ a valuable
thought tool facilitates development "building security in" to an
application, even if they're only changing what they think about when
they're conducting software development activities and not effectively using
all the whiz-bang RBAC capabilities of toolkit XYZ. As always:
***ULTIMATE 'TO AVOID': adopting SSO, RBAC, or other acronyms as 'features'
that will simply by inclusion (and your own ignorance) lead you to believe
that your software is more secure.
-----
John Steven
Managing Director, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 585 8659 - Cell
Cigital Inc. | jsteven@cigital.com
4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908
From: "Kenneth R. van Wyk" <Ken@KRvW.com>
Crispin Cowan wrote:
I completely disagree. I find the article to be timely and informative.
What Kenneth suggests (use of RBAC) will not solve the problem. First
of all, RBAC is not practical to deploy in most situations; companies
are still trying to cope with AV and firewalls, and just beginning to
think about host and application security. RBAC is completely beyond
them.
Well, my main objection to the article was its advocacy for addressing
the insider threat problem simply by buying security products. I
brought up RBAC simply as one example that people may consider as they
seek solutions.
Whether it be role-based, or a plain old-fashioned, group/ACL sort of
access control, coupled with good event logging and monitoring, I think
that most sites would be better served by exploring the access control
mechanisms that they currently have instead of just buying more security
products. That's not to say that there aren't products that may be
highly useful, but it is to say that the solutions should start with
well designed and implemented access control and logging. I stand by
that opinion.
----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged. The information contained herein is intended
solely for the recipient and use by any other party is not authorized. If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited. If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message. Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
