Host and Application SecurityLesson 22: Patch Management

On to more managerial things The two biggest issues for most users are:

Configuration We have secure software, but the host is configured

insecurely… example? Patch management

We have insecure software because we are running an old version

Versioning In principle, very simple Audit the software you have Keep it all up to date

Vulnerability LifecycleSoftware Released

Vulnerability Found

Exploit released

Workaround developed

Patch developed

Not as easy as it sounds Patching isn’t always benign Patching needs to be validated Knowing what you’re running

Patching isn’t benign Ever tried to upgrade a kernel in gentoo? Better yet, ever tried to upgrade a module in

perl in gentoo with a heavily patched kernel? RIGHT! Patching, even when given a good

patch is sometimes lots of work

Patching needs to be validated You’re running software on an Airbus A330 You want to make a change to deal with a

vulnerability… What are the tradeoffs? How can we validate?

Audit Figuring out what you need to patch isn’t easy

either

Solution: Autoupdate? What are the implications?

Benefits? Disadvantages?

Solution: Patch Tuesday? Microsoft has a pretty predictable patch

schedule Benefits? Disadvantages?

Something you can do Secunia – wonderful piece of software!

Scaling issues Managing a single machine versus managing

a LOT of machines…

Penguins versus whatever ms-logo is… There are fundamental differences between

open and closed source Oses currently with regard to patching Discuss

To Do Taking your own machine as an example,

figure out what software is on it, what version and what version is current. For each thing found that is out of date, what are the vulnerabilities associated with it? Come up with your own plan for managing software on your machine and document it.