Managing Vendor Required Browser Security Setting Risks

["Flynn, Gary" <flynngn () JMU EDU>]

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