Vulnerability Management

1
Vulnerability Management

• Building the Right Team

2
Topics

• Challenges in Vulnerability Management
• Meeting those Challenges
• Building the Right Team
• Why the Team Approach
• Putting the Team to Work
• New Challenges

3
Wheres the Challenge?Technology

• Extremely complex environments
• Multiple networks based on function, with varying
  degree of value
• Multiple Operating systems and functions
• DNS/Routers
• Web Servers
• Proxy Servers
• FTP Drop Boxes
• VPN

4
Wheres the Challenge?Business Practices

• Large company with strong security practices
• De-centralized IT support
• Systems Support
• Network Support
• DNS Support
• Security not a partner in support process
• Not enough sharing of information
• Best practices, prioritization of patches
• High risk patches are not being installed quickly
  enough

5
Meeting Those Challenges

• Provide collaborative evaluation of known
  vulnerabilities from a corporate perspective.
• Determine impact that vulnerabilities may have
  on our Internet Gateway Hubs globally.
• Based on evaluation of vulnerabilities, provide
  recommended actions to eliminate exploits to our
  networked environments, globally.
• Monitor patch/fix implementation globally to
  ensure the elimination of vulnerabilities

6
Building the Team

• Facilitated by InfoSec - team included
• IT Support
• Network Operations
• Infrastructure Deployment
• Standard Kit builders
• Remote Access Services
• Anyone responsible for support/service in
  environment.

7
Why the Team Approach?

• Automated asset identification tool would not yet
  fully implemented
• They know the environment
• What hardware is installed/where
• What software is installed/where
• More apt to implement decisions they helped
  make/decide
• Involves all phases of system build (pre-install
  team as well).
• People actually begin to know each other

8
Putting the Team to WorkStep 1

• Team meets on a regularly schedule (weekly at
  minimum) to evaluate ALL security bulletins and
  advisories
• Sources include SANS, CERT, Symantec DeepSight
  (BugTraq), Cisco, etc.

9
Putting the Team to Work Step 2

• Team reviews notice of vulnerability and
  determines the rate of risk/severity levels by
  answering the following questions
• Does vulnerability apply to our environment (both
  hw sw)
• If so, to what extent
• Are the affected systems critical to our
  business
• Is vulnerability report based on theory or proven
  exploit

10
Putting the Team to Work Step 2 - Continued

• Is vulnerability widely known
• Is there a tool or published script for exploit
• Is vulnerability currently being widely exploited
• Can vulnerability be launched by us to attack an
  external entity
• Based on answers to those questions,
  vulnerabilities are then placed in one of the
  following Risk/Severity levels.

11
Risk/Severity Levels
12
Sometimes, You just DONT Know

• If the team can not properly evaluate a
  vulnerability, then they should use a life line
  for assistance
• Internet Router Admins (Cisco Advisories)
• Remote Access Services (VPN specifics)
• Etc.
• Based on their input, team determines risk level
  and continues with process.

13
Example of High Risk/Severity 1 Process
Time 1-3 Days
Time 1 Day
Time 1-3 Days
Time ½ Day
Team Receives Vulnerability Notification and
Eval. As HIGH
Qualify Patch on Std build orUnix Hardened box
Qualify Patch on Apps Environ. (I.e. IIS, etc)
InfoSec creates Master Ticket for Change
Mgmt Process
Senior IT Mgmt Approvals for Company wide
Implementation
- Provide feedback to vendor if necessary - Work
to get new patch
- Notify Company wide InfoSec IT Mgrs
- Provide feedback to vendor if necessary - Work
to get new patch
Time ½ Day
Time1 Day
Time 1-3 Days
Time 1-5 Days
Time 1 Day
Geo/Business unit Sub-tickets Created/Appproved
By mgmt.
Tickets received By Local IT Personnel
Patch Installation A.S.A.P. on ALL Systems
Close Ticket And notify InfoSec upon Completion
Local Testing Performed on std Build systems

• Provide feedback to team if issues are found
• Team to work with Vendor to resolve and issue new
  patch

- Continuous monitoring and tacking of
installations by Team.
Auditing of Patch Installation by Scanning
Prg
14
Example of Med. Risk/Severity 2 Process
Time 1 Week
Time 2 Days
Time 1 Week
Time 2 Days
Team Receives Vulnerability Notification and
Eval. As Medium
Qualify Patch on Std. build(s) or Unix Hardened
Box
Qualify Patch on Apps Environ. (I.e. IIS, etc)
InfoSec creates Master Ticket for Change
Mgmt Process
Senior IT Mgmt Approvals for Global Implementation
- Provide feedback to vendor if necessary - Work
to get new patch
- Notify Company Wide IM InfoSec Mgrs
- Provide feedback to vendor if necessary - Work
to get new patch
Time 2 Day
Time 1 Day
Time 1 Week
Time 4 Weeks
Time 1 Day
Geo Sub-tickets Created/Appproved By Directors
Tickets received By Local Personnel
Patch Installation on Systems
Close Ticket And notify Info Sec upon Completion
Local Testing Performed on Dev Systems

• Provide feedback to Team if issues are found
• Team to work with Vendor to resolve and issue new
  patch

• Local IT staff to notify InfoSec if there are any
  delays in installation of patch
• Patch installation should be scheduled at next
  regular maintenance/
• Downtime
• - Monitoring by Team

Auditing of Patch Installation by Scanning
Prg .
15
And Still, More Challenges

• Domain Reporting no single owner -
  accountability
• Applications require different configuration /
  versions of products to operate
• Many server upgrades are dependant on multiple
  applications
• Sometime many applications per server
• Business / Application responsiveness to planned
  outages
• Planning upgrades for third party hosted
  applications

16

• Questions?