centralised patch management
play

Centralised patch management J. Barhorst & M. Pels July 5, - PowerPoint PPT Presentation

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


  1. Centralised patch management J. Barhorst & M. Pels July 5, 2005

  2. 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

  3. Existing systems Contents ➢ Activities ➔ Comparison ➢ Requirements ➢ Proof of Concept ➢ Conclusion Jul 5, 2005 Centralised patch management 3/12

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. Components Contents ➢ Activities ➢ Comparison ➢ Requirements ➔ Proof of Concept ➢ Conclusion Jul 5, 2005 Centralised patch management 10/12

  11. 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

  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

  13. Questions?

  14. Screenshots (1/3)

  15. Screenshots (2/3)

  16. Screenshots (3/3)

Recommend


More recommend