Re: Managing Vendor Required Browser Security Setting Risks

[Kevin Shalla <kshalla () UIC EDU>]

I'm also involved in accessibility concerns on our campus, and it
seems that the issues are much the same - Application development,
marketing and buyers remain blissfully ignorant of accessibility and
security requirements, and only focus on features (for those with
good vision, a big screen, and a mouse, who regularly run with
Windows administrator rights, and all security disabled).  We
typically set Trusted Sites as our entire university domain, plus
perhaps a few others.  But... people often use Firefox, so I'm not
sure how effective managing trusted sites is anyway.

It would add more value to IE if Microsoft was convinced to add
per-domain rights (not simply Internet, Local Intranet, Trusted
sites, and Restricted sites) - but then again that might become an
administrative headache too.

We've been able to add accessibility requirements to our contract
language, and I think it does help, but still if there's no product
that meets all feature and accessibility requirements, then we make do.

At 10:10 AM 5/20/2010, Flynn, Gary wrote:
> 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