Re: So, the security industry has given up on the principles of least privilege and separation?

[Andre Gironda <andreg () gmail com>]

On Sat, Feb 14, 2009 at 8:11 AM, Dave Korn <davek_throwaway () hotmail com> wrote:
>  There's a story from yesterday on ElReg, following up the ongoing issue with
> UAC in the win7 betas.  The exploit itself (not well explained in the article,
> but amply illustrated by the OPs referenced there) is interesting, as much
> from a political point of view (it appears to be a blatantly anti-competitive
> attempt to give MS' apps an advantage over all others in the ability to
> present a smooth and pleasant user experience uninterrupted by UAC popups) as
> from a technical one, but the thing that boggled me was a quote from Secunia:

Thanks for telling us about this story and the Secunia follow-up.  I
have seen a few articles lately such as:
http://www.cio.com/article/479228
"Removing Admin Rights Stymies 92% of Microsoft's Security Vulnerabilities
Nine of out 10 critical bugs reported by Microsoft last year could
have been made moot, or at least made less dangerous, if people ran
Windows without administrative rights, a developer of enterprise
rights management software claimed Tuesday".

The Secunia bit appears to be a backlash against the latest IT
security trend that has recently come into full maturity and adoption
(i.e. enlightenment): Role Management for Enterprises.  Business
owners know what it is, what's it's going to do for them, and how to
get there.

I believe this is for many good reasons, including the ones mentioned
above.  It is quite likely that compliance standards and regulations
(via controls based on the principles of "segregation of duties") have
allowed organizations to measure the success of RME for a few years
now.  The benefits appear to be greater than originally imagined
through early risk analysis predictions.

Not only does RME appear to be working, but the most recent standards,
such as PCI-DSS 1.2 (which came out in October, 2008 with a
pre-release of September 17th) have begun to add words such as "RBAC"
to many requirements as additional required controls.

> Thomas Kristensen ... No matter which security features
> have been built into the operating system, then the user should never run
> code, which they don't trust in the first place. Untrusted code should only be
> run on dedicated test systems."

This is probably due to the fact that Secunia has invested a lot of
resources into binary analysis (malware and COTS appsec research) and
classic vulnerability management based around network scanning and
patching - "Scan & Patch".

http://securitybuddha.com/2008/05/24/presenting-security-ideas-or-driving-agendas/
"It's difficult to get a man to understand something when his salary
depends on him not understanding it".

> That made me snort into my breakfast cereals, I can tell you.  Has the
> entire security industry abandoned all hope of using the principle of least
> privilege and limited user accounts, or just him?  It's been said time and
> again that actually having your users running under limited user accounts is
> in practice a very effective measure against an awful lot of malware, breaking
> a lot of its mechanisms for self-propagation, installation and infection.

Well there are two camps here.  The first, which is trying to make
least priv work without affecting usability.  The second, which puts
limitations on role management because they believe all security
affects usability.

> It's easy to say that the user must never get "untrusted" software on there
> machine, but that don't help Joe Sixpack much; how's he supposed to "trust" an
> impenetrable blob of binary?  He's not a reverse engineer, and can't be
> expected to be; so isn't it a good idea that there should be a way for him to
> run processes in a constrained fashion that won't give them the ability to
> modify the system?

Opening a Zip File shouldn't affect the registry or control panel.
There are many ways to teach users this fact, and other similar facts.
 One of those ways is through technology like UAC.

UAC is a free tool in the RME tool chest for organizations in need of
more refined user/app/process entitlements.  The Windows7 stuff
appears to be a call for OEM manufacturers to stop putting vulnerable
software on pre-pwned hardware.  For this situation, I don't see it
working very well, but I could be wrong.  Most users outside of the
tech field don't even know what applications are installed on their
computers or how they got installed.  This is probably the first
problem that we need to solve.

> I was surprised, anyway.  I thought (unauthorised) privilege escalation was
> an exploit and desirable to prevent; I didn't expect a security commentator to
> describe it as just one of the things you should expect from life as routine.
> Why did we spend all those years berating MS for installing everything with
> admin rights by default, if it was fine all along?  Why doesn't everyone just
> give all there *nix users root, if it doesn't matter?

Most installations will require some elevated privileges to complete
successfully even when the application runs with user privileges.
Therefore it is important to have an installation process that
provides only the necessary permissions and, ideally, in a way that is
transparent to the user.

This is not only true for new application installations, but also
application updates.

Users do not have the time to run FileMon, RegMon, and Tripwire every
time that they click a new button on a configuration panel.  Somebody
has to do all of the work ahead of time and ensure that the proper
application roles are in place with only the permissions necessary to
complete the task at hand.  If it's not going to be the COTS
application vendors, or the FOSS deployment teams - then it has to be
a job for somebody.  Perhaps application security?

Administrators fail for the same issues, and often worse, than users.
They will configure the application tier's interface to another tier
(message queue, database, grid, web services) with full permissions
using only one (default) role.  IT admins often cite reasons such as
"connection pooling" or other performance/architecture factors.  There
is no reason for a database user to have full table and view privs,
along with full execution permissions on every type of stored
procedure.

Any tools or infrastructure processes to make this task easier, I'm
all for.  Anyone play around in the RME market space?  The article
that I linked to mentioned BeyondTrust, which I know nothing about.
I'm more curious if there are any tools out there in the open-source
world, or if anyone is working on any?  I know that CISecurity, NSA
SNAC, IASE STIGs, and many other resources speak to the least
privilege principle, but it would be nice if someone had all of this
information available on solely just role management in one easy to
find place.

Cheers,
Andre
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave