protecting systems using alternative methods besides applying hot fixes

All- I work in an area where the operational folks do not like when IE patches are applied to servers since we have a lot of customized code in our web applications that can be impacted. Many of these patches come out due to Remote Code Execution vulnerabilities. As I understand it, this vulnerability can only be drawn out if a user browses to a web site that will bring out this vulnerability. Therefore, another proposed option is to block all out-going Internet requests at the firewall for the servers that we do not want to patch. Does anyone see any issues that could still arise with this fix action? -Matt

Answer Wiki

Thanks. We'll let you know when a new response is added.

Is the servers reachable from the Internet?
Even if the servers are not reachable directly from the Internet, then you probably have other servers that are. If attackers find their way in through these servers, then you’re vulnerable, and if users receive email with code that exploits vulnerability then you’re probably better of implementing the patches. There is always a tradeoff between functionality and security.

Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Solutions1
    The strategy of defending a hardened periphery with a firewall, while retaining a soft interior is becoming unsound, if it ever was sound. Unpatched servers are at risk from internal threats (probably 70% of your substantive business risk) and as another respondent pointed out, from ricochet effects from outside. Your company probably needs to 1) acquire a vulnerability test software suite to begin proactively identifying and eliminating vulnerabilities, and 2) establish a "drop dead date" policy commitment that states "after xxx/xxx/06 the appropriate patches will be applied regardless of impact." Otherwise you can never turn off the bubble machine - new vulnerabilities will propagate.
    0 pointsBadges:
  • DDekreon
    I agree strongly with previous comment about hardened periphery & soft interior: there's been at least three incidents in major organizations here where infected laptops were connected to internal networks, resulting in a wildfire infection incident. One of the organizations segmented its internal network with firewalls between departments; another installed personal firewalls on every pc (expensive and cpu intensive). Using IE centric coding methods that happen to also be the hallmark of web-based attacks is a bad idea and must be eliminated, no matter how painful it will be. The alternative is a guaranteed infrastructure meltdown sometime in the near future...
    15 pointsBadges:
  • Bud8N2K6
    I agree with all previous posts that your internal network is at risk even if you use firewalls, proxys, SMTP relays and all the other Defense in Depth technologies available. Here's the bigger issue and the question you have to ask the "Operators". Would you rather have a network with a "few" minor issues that may cause you a little bit of extra time to do your job or would you prefer to use the phone or snail mail? When, not if, the network is attacked and they lose the ability to communicate this will all come back on the IT staff. If you are some types of industries like military, Federal government, banking, etc you may also have regulatory compliance issues that will dictate that all vulnerabilities are remediated or you can lose the ability to connect your network to outside resources. Good Luck because I know you are going to need it!!!
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: