Tip of the Day: Protect the Single Points of Compromise

Published: 2006-08-25
Last Updated: 2006-08-25 20:03:14 UTC
by John Bambenek (Version: 1)
0 comment(s)
Automation is a great thing in large environments. If an organization has to maintain thousands of laptops roving around the country, it either needs to hire lots of traveling IT guys, or use automated tools to handle patching, software loads, and installation. Manual processes on a large scale almost ensure there will be patches missed and systems compromised.

However, tools that automate installation, patching, and software installation comes with a risk. Namely, the machine or machines that control software being pushed out to machines becomes the single point of compromise in an environment.

As an example, imagine an RIS, Kickstart, Jumpstart, or other automated install server. If someone compromised this server and added a small package that included a rootkit, you would be quietly putting compromised machines on a network. For machines that push out patches or software, it wouldn't take much to quietly push out a trojan the next time Patch Tuesday comes around.

It would probably have to be an inside job, but most information intrustions are inside jobs. In the case of corporate sabotage or espionage, custom-written malware would be very likely to pass by virus scanners and spyware scanners who have to react to new malware being sent to them. If no one has ever seen it before, odds are it isn't detected.

The point? By all means, keep using automation to keep control of workstations and laptops (or even servers). However, beware that the systems you use for that automation are a single point of compromise and need to be excessively hardened and monitored for even the slightest bit of tampering. Examing and auditing what those machines put out into your environment is a must.

John Bambenek
bambenek /at/ gmail /dot/ com
Keywords: ToD
0 comment(s)


Diary Archives