Secure Coding mailing list archives
Re: ZDNnet: Securing data from the threat within [bybuying products]
From: "John Steven" <jsteven () cigital com>
Date: Wed, 19 Jan 2005 20:39:16 +0000
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. | [EMAIL PROTECTED] 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908
From: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> 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. ----------------------------------------------------------------------------
Current thread:
- Re: ZDNnet: Securing data from the threat within [bybuying products] John Steven (Jan 19)