Re: Managing Vendor Required Browser Security Setting Risks

[Brian Desmond <brian.desmond () MORANTECHNOLOGY COM>]

> - Initialize and script ActiveX controls not marked as safe for scripting
> - Download unsigned ActiveX controls

I don't remember what triggers the first one offhand (it is likely a
function of #2), but, for the second one, we're talking about <$500/yr for
the vendor to get a code signing cert from a CA and a miniscule amount of
time to sign the package as part of their build signoff process. I have a
code signing cert in my name - it wasn't hard to get and when I leave stuff
behind at customers, depending on how it's going to be used I sometimes sign
the package if that gives you an idea of the simple-factor here.

Personally, given the option, I'd tell them to pound sand if it was me. I'd
probably think about some sort of sandboxed delivery mechanism, (Citrix, app
streaming, TS remote apps, etc) before I went and unchecked those two boxes
across the org.

--brian



Thanks,
Brian Desmond
brian.desmond () morantechnology com

w - 312.625.1438 | c - 312.731.3132

Active Directory, 4th Ed - http://www.briandesmond.com/ad4/
Microsoft MVP - https://mvp.support.microsoft.com/profile/Brian
-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Flynn, Gary
Sent: Thursday, May 20, 2010 8:11 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Managing Vendor Required Browser Security Setting Risks

Some functionality in our RMS Housing application makes use of ActiveX
controls. After moving the desktops to the domain and thereby applying
standard campus IE policies, the application broke.

The vendor gave us a list of necessary IE settings which basically disables
all security functionality in the ActiveX section. I'm particularly
concerned about:

Enabled:
- Initialize and script ActiveX controls not marked as safe for scripting
- Download unsigned ActiveX controls

I have concerns about configuring a desktop with these settings even if only
for the Trusted Sites zone which is becoming more of an oxymoron every day.
We also allow users to self-populate the Trusted Sites zone and users
sometimes assess risk and necessity differently than we do.

If you use this application, have you found a way to make it work without
those settings? The calendar function appears to be the major functionality
requiring these settings.

This is not the first time an application has forced us to lower our
security standards though the required settings for the other two
applications didn't concern me as much as this one does. In this age of web
drive by compromises, 3rd party browser add-on exploits, and infection
exposure on major media sites through ads and other means, the last thing I
want to do is increase browser risk. Am I over reacting?

In general, if you manage IE policies:

- What policies and practices do you have about the approval process for
lowering security posture for applications? We have a security questionnaire
we attach to RFPs and I'm going to try and get that modified to include
non-standard browser and desktop setting requirements to catch this kind of
issue in the procurement cycle. But we'll never catch all of them and we've
had some applications release a 'new and improved version' requiring similar
changes.

- How do you manage different browser and/or desktop policies for different
campus organizations and application users to keep settings required for one
vendor's development practices from putting unassociated computers at
additional risk? There is some concern here about the administrative
overhead of maintaining many different granular configurations.

Thanks for any thoughts,

Gary Flynn
Security Engineer
James Madison University