Patch management is critical to reducing your attack surface and keeping your endpoints and business running smoothly. Unfortunately, it's also a process that must be repeated weekly, monthly, quarterly, and whenever critical fixes have been identified for your environment. The good news is: with the right tools and some advance planning, this process can run smoothly and leave your IT team with more time to support core business goals. Join us to learn about trends in patch management, including the latest ways Ivanti is helping Security and IT teams work together like a well-oiled machine.

1. OSB 130 – Patch Management Best Practices
Chris Goettl and Todd Schell

2. Our approach to security
Take actionProvide insightDiscover
Use best-in-breed tools to
act swiftly.
Clearly identify risk.
Easily find and quantify
the assets you need
secured.
Integrated, easy-to-use security offering

3. Discovery and Planning

4. Know the People Involved
 Immediate patch team
 Extended team
 Help desk
 Network support
 Application or desktop support
 Management
 Functional and organizational managers
 CISO or equivalent
 End users as needed
 Special use machines

5. Know your Environment
 System discovery
 Talk to IT resources
 Basic understanding of system use
 Operating systems and applications
 Network layout and access
 Network maps
 Scan the network
 Verify access
 Leverage existing procedures
 Be aware of restrictions and responsibilities

6. You’ve Identified the Operating Systems

7. You’ve Identified the Applications

8. Vendor Patch Release Models
 Operating systems
 Windows on famous Patch Tuesday
 Oracle has quarterly CPU (Critical Patch Updates)
 Others
 Different subscription/access models
 Publicly available, e.g. Microsoft
 Open with community account, e.g. Cisco
 License subscription by endpoint, e.g. Red Hat
 Applications
 In sync with Patch Tuesday, e.g. Adobe
 As needed/available (most companies)

9. Tracking Vendor Releases
 Ivanti Patch Tuesday Content
 Patch Tuesday Blog, Content, Webinar, Webinar playback and
presentations
 Ivanti Content Announcements
 Patch for Windows Patch Content
 Endpoint Manager Patch Content

10. Windows as a Service
 Phased rollout from engineering through production
 Feature updates
 March and September
 Aligned with Office 365
 Quality updates
 Monthly and cumulative
 Security and non-security
 Semi-Annual Channel
 Long-Term Service Channel
Source: Microsoft

11. Current Release Summary
 Windows 10
 1511 (November Update) – EOS 4/10/2018*
 1607 (Anniversary Update)
 1703 (Creators Update)
 1709 (Fall Creators Update)
 1803 (April 2018 Update)
 Server 2016
 10.0.14393 (September 26, 2016 @ Ignite)
 Windows Server
 1709
 1803
*Education and Enterprise

12. Legacy Operating System Service
 Support for Windows 7 through Windows Server 2012 R2
 Security Only Quality Update
 A Patch Tuesday release
 Security patches for a given month
 NOT cumulative month-to-month
 Security Monthly Quality Rollup
 Cumulative month-to-month from October 2016
 Includes reliability fixes in addition to security fixes
 Occasionally added security and reliability fixes older than October 2016
Source: Microsoft

13. Formulating an Initial Strategy
 Grouping systems
 Ownership or function
 Common patch policy
 Operational requirements
 Patch availability as a function of risk assessment
 Pre-deployment system impact and validation testing
 Maintenance windows
 Policy types
 Baseline under configuration control
 Continuous rollout as approved
 For Windows, security-only or monthly rollup

14. Configuring your Systems

15. Patch Data Flow
. . .
Step 1: Content Production
Content
(XML Metadata)
• Detection Rules
• Location of Binaries
• CVEs Addressed
• File Size
• . . .
Patch
Binaries

16. Patch Data Flow
. . .
Step 2: Content Distribution
Patch Server
Firewall

17. Patch Data Flow
Step 3: Scan and Detect Missing Patches
Patch Server

18. Patch Data Flow
. . .
Step 4: Obtain Patches
Patch System
Firewall

19. Patch Data Flow
Step 5: Deploy Missing Patches
Patch Server

20. Consider the ‘Big Picture’
 One or Multiple Patch Servers
 Scalability
 Network access to endpoints
 Geographic distribution
 Internet Access
 Content from Ivanti
 Binaries from vendors
 Patch Administrators
 Roles
 Responsibilities

21. Typical Test and Rollout Process
 Testing
 Representative target systems
 Success criteria
 Rollout
 All patch groups
 Multiple phased groups

22. Setting up Patch Groups

23. Patch Selection and Patch Management

24. Patch Selection and Patch Management

25. Patch Selection and Patch Management

26. Patch Scan and Deployment

27. Patch Scan and Deployment

28. Patch Scan and Deployment

29. Patch Scan and Deployment

30. Running Patch Operations

31. Steps in Patch Operations
 Standard Process
 Monitor content
 Build baselines and test (or)
 Test latest released patches
 Obtain configuration control approval if required
 Send notification to employees/users
 Scan, deploy, and patch
 Monitor results
 Emergency Patch
 Build response patch set
 Send notification to employees/users
 Scan, deploy, and patch

32. Communicating Patch Activity with Employees

33. Incident Response Plan
 More cross-team activity
 It’s not ‘if,’ it’s ‘when’ things go wrong.
 Things to consider
 Types of events and associated escalation procedures
 Insider versus outsider events and threats
 Standard procedures versus emergency procedures
 Public disclosure versus information control
 Perform regular tests to exercise and improve the plan.

34. Patch Exceptions include Additional Security Measures
 If you can’t remediate, mitigate.
 It’s all about control and containment.
 Reduce user privileges.
 Remove direct access to clientpurchase cardPII.
 Virtualize workloads.
 Reduce exposure to neighboring systems.
 Remove direct Internet access.
 Implement application whitelisting.
 Implement containerization in cases where removal of Internet access is not
an option.

35. Trends

36. Automate and Orchestrate for Efficiency
 Patching is one part of a service-oriented architecture.
 Application and OS provisioning
 Change management
 Start with the basics.
 Python, Ruby, PowerShell
 Go with the big boys.
 Terraform, Chef, Puppet, SaltStack
 Ivanti provides the patch APIs you need.

37. Vulnerability Scan Automation
 API Integration
 Vulnerability scan results
 Automated patch group creation
 Integration of RES Automate
 Make automation easy
 Close the response loop

38. Thank You