lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <405FCABB.1040900@bastille-linux.org> From: jay at bastille-linux.org (Jay Beale) Subject: When do exploits get used? Luke Scharf wrote: >On Mon, 2004-03-22 at 17:13, Jay Beale wrote: > > >>You may find this discussion academic. But the exploit writers and the >>worm writers are getting faster. And that's what should scare us into >>moving beyond patches. That's what should get us moving to better >>network and host configurations. That's what should get us to evaluate >>patching as, at most, the easy, but most critical, 50%. >> >> > >I would say that we could all agree that not patching is a recipe for >disaster -- and that it's very easy to keep up to date. > > Yes. This is obvious. If we don't patch, we're just left vulnerable. The windows of vulnerability end only at O/S upgrades! >But, my 90% figure comes from the accidental plugging of unpatched >Windows machines into the open network. Every time I do that, the >machine is running msblast in a few minutes. And as near as I tell, >it's not my machines that are doing it (except for that one unpatched >machine that I spend an hour rebuilding)... > > Well, I still worry that you've oversimplified things with the 90% figure. In trying to convince people this way that they should deploy patches quickly, you're setting up the expectation that there won't be any more compromises when everyone patches. The purpose of my previous explanation was to show that you're still a slave to timing -- you may not be able to patch enough, either because you've got a previously unknown vuln (0-day), because your vendor isn't fast enough, or because the attacker/worm arrives and begins exploiting systems too quickly for your regular periodic patching practice. In the latter case, you might patch every day, but the worm could hit systems 6 hours after your last patch cycle, 18 hours before you'll be deploying the patch against the worm's vuln. What I'm trying to argue here is that we should be patching, but that we should also begin locking down hosts. NSA's Information Assurance Directorate found that you could use well-known best practices to remove or mitigate over 90% of the vulnerabilities in Windows 2000. Kerry Steele, working on behalf of the Center for Internet Security, found a similar over-90% mitigation rate on Red Hat Linux. The critical thing to understand is that you tweak the security setttings on the system _before_ the vulnerabilities are discovered and get that success rate. It's not precognition -- you're simply configuring the machine for better security, based on an understanding of what the machine's function is. It's very effective. The techniques have been well understood for years. And very few organizations make this a priority for their sysadmins. BTW, I'm not just arguing for patching and hardening, I'm also arguing that we should start considering better network architecture and access control. Internal router rulesets or firewalls could go a long way toward slowing the propagation of a worm on the LAN. Worms spread throughout an organization amazingly quickly in large part because we're still in the "crunchy outer shell, chewy center" model of firewall deployment. This isn't necessary -- engineering and accounting workstations rarely need to communicate with each other with LAN-based protocols. They tend to interact through central servers. The internal router/firewall policy should reflect this. But that's a whole new can of worms. - Jay
Powered by blists - more mailing lists