Centralised patch management J. Barhorst & M. Pels July 5, 2005
What did we do? Contents ➔ Activities ➢ Comparison ● Look at client update tools ➢ Requirements ● Create list of research topics ➢ Proof of Concept ➢ Conclusion ● Investigate three existing patch management systems ● Compose list of functional requirements for ideal patch management ● Build Proof of Concept Jul 5, 2005 Centralised patch management 2/12
Existing systems Contents ➢ Activities ➔ Comparison ➢ Requirements ➢ Proof of Concept ➢ Conclusion Jul 5, 2005 Centralised patch management 3/12
Ideal requirements (1/5) Contents ➢ Activities ➢ Comparison Patches: ➔ Requirements ● Acquire via existing mechanisms or a third party ➢ Proof of Concept ➢ Conclusion ● Rollback capability ● Verification (digital signature, checksum) ● Multi-platform ➔ Impossible to support everything ➔ Multiple PMS's is not a bad thing Jul 5, 2005 Centralised patch management 4/12
Ideal requirements (2/5) Contents ➢ Activities ➢ Comparison End users: ➔ Requirements ● Should not be able to reject or rollback patches ➢ Proof of Concept ➢ Conclusion ● Reboot options should be versatile: ➔ Warning ➔ Postpone ➔ Deadline ➔ After office hours Jul 5, 2005 Centralised patch management 5/12
Ideal requirements (3/5) Contents ➢ Activities ➢ Comparison Distribution: ➔ Requirements ● Agent & existing mechanisms ➢ Proof of Concept ➢ Conclusion ● Prioritization (based on risk / severity) ● Grouping of hosts (servers / workstations) ● “One, some, many” Administration: ● Approve / reject patches ● Custom patches / scripts Jul 5, 2005 Centralised patch management 6/12
Ideal requirements (4/5) Contents ➢ Activities ➢ Comparison User interface / Framework: ➔ Requirements ● User-friendliness ➢ Proof of Concept ➢ Conclusion ● Access control ● Backups / restore ● More information about patches (CVE) Infrastructure: ● Multicast / peer-to-peer / multiple servers ● Low / expensive bandwidth users ● Inventory building Jul 5, 2005 Centralised patch management 7/12
Ideal requirements (5/5) Contents ➢ Activities ➢ Comparison Reporting: ➔ Requirements ● Alerting (SMS, e-mail, etc) ➢ Proof of Concept ➢ Conclusion ● Reports ➔ Patches (succes, failure, new, rejected, etc) ➔ Hosts (completely patched, missing patches) ➔ Groups (hosts, approved patches) ➔ . . . Jul 5, 2005 Centralised patch management 8/12
Proof of Concept Contents ➢ Activities ➢ Comparison ● Why a Proof of Concept? ➢ Requirements ● Why APT? ➔ Proof of Concept ➢ Conclusion ● Why Ubuntu? Jul 5, 2005 Centralised patch management 9/12
Components Contents ➢ Activities ➢ Comparison ➢ Requirements ➔ Proof of Concept ➢ Conclusion Jul 5, 2005 Centralised patch management 10/12
APT module Contents ➢ Activities ➢ Comparison ● Synchronize ➢ Requirements ➔ Download Package & Release file ➔ Proof of Concept ➢ Conclusion ➔ Verify signature & checksums ➔ Store package info in database ● Build ➔ Retrieve package info from database ➔ Make new Package & Release file ➔ Create digital checksums & signature Jul 5, 2005 Centralised patch management 11/12
Conclusion Contents ➢ Activities ➢ Comparison ● Product investigation ➢ Requirements ● Ideal requirements ➢ Proof of Concept ➔ Conclusion ● Proof of Concept ● Future work Jul 5, 2005 Centralised patch management 12/12
Questions?
Screenshots (1/3)
Screenshots (2/3)
Screenshots (3/3)
Recommend
More recommend