Like clockwork, administrators predictably scramble to see what, if any, dangers the latest published vulnerabilities pose to their network. Then there's the seemingly interminable wait for a patch and/or complex task of implementing work-arounds that won't break your current setup. This was especially true in 2004.
|Did a sudden torrent of security bulletins turn your daily routine into an overwhelming task? A little foresight and preparedness can make it a walk in the park.|
It turns out that with a little research, administrators needn't put themselves at the mercy of technology vendors, in this case Microsoft. While the engineers in Redmond toil to stamp out the latest crop of bugs, a few policy changes and user management tweaks will render all but the most complex problems a non-issue.
Note: The opinions expressed below are solely those of the individual posters on the AntiOnline forums.
This Week's Spotlight Thread:
Network Security Made Easy?
Tiger Shark is of the belief that corporate networks and end-user systems needn't float around in limbo until an official patch is developed.
As the result of a comment made here earlier this week, to which I responded, that there is always a technique to mitigate a threat until a patch is available I thought it would be of interest to look at all the security bulletins for 2004 and extract those that pertain to "normal" systems, survey them and determine what basic things we can learn from the vulnerabilities in 2004. I decided to do this because it struck me that throughout all of last year, I really didn't worry too much about the patches to internal machines after I had seen the advisories.After some analysis, the risks boiled down to:
There were 45 Security Bulletins issued by Microsoft in 2004, of which 12 were not applicable due to them referring specifically to software such as ISA server, Exchange, etc., leaving 33 bulletins to be assessed. Some Bulletins addressed multiple vulnerabilities so the total vulnerabilities to be assessed are 68.
Of the 55 remaining vulnerabilities all were mitigable with one of the following techniques:But wait, here's the kicker:
- Disable ActiveX and Active Scripting in IE security, (links to the next one)
- Raise the security level of the Internet and/or local zone in IE security to high
- Read email in plain text
- Disable connector in the registry
- Unregister the component
- Good firewall practices
So the upshot is that four skills are required to enable a Network Administrator to mitigate more than 80% of all vulnerabilities that occurred in 2004:Can just a handful of skills really put that much of a dent in your security woes? Sound off here.
I would suggest that those skills would serve you well in the years to come.
- The ability to manipulate the behavior of IE through Group Policy.
- The ability to create a .reg file and run it through a login or startup script.
- The ability to script an unregister a component through a login or startup script.
- The ability to properly manipulate their firewall.