Vulnerability Management

Transcription

1 Vulnerability Management When you just can t patch richard dahl founder and ceo

2 Agenda Who am I When Can t You Patch Typical Vulnerability Process Four Options Resource Characteristics

3 Agenda Control Inheritance Vulnerability Analysis Risk Analysis Remediating Controls Vulnerability Documentation

4 Who am I? Founder and CEO of cmplid:// Inc. Security Management Automation solution Security professional with more than 23 years in security First 5 years as Counterintelligence Agent in US Army Consulting experience with many industries Security management methodology zealot Passion for repeatable and consistent processes that produce high quality security programs

5 Sounds like: Counterintelligence Agent

6 Looks like: Counterintelligence Agent

7 When you just can t patch NOT When patching is difficult When patching is inconvenient When you assume you can t patch When patching interferes with you time

8 When you just can t patch

9 When you just can t patch

10 Patch When You Can Set very high-bar for not patching Document the specific criteria Consistently follow guidance

11 Criteria For Not Patching Just Say No Vendor comes from the Nancy Reagan School of Patch Management

12 Criteria For Not Patching Vulnerability is not relevant

13 Criteria For Not Patching Vulnerability is Mitigated through alternate means AND Affected system is functioning properly AND Affected system is not normally administered

14 Normal Vulnerability Response Process

15

16 got vuln?

17 Four Options 1. Work with vendor to support patching

18 Four Options 2. Upgrade and support production system yourself

19 3. Replace Vulnerable Product Four Options

20 4. Do nothing (and hope for the best) Four Options

21 Resource Characterization Technical Resources Hardware Software Source Code Networks Media

22 Resource Characterization Business Resources Information Locations Personnel Organizations

23 Resource Attributes Define the characteristics necessary to disposition security requirements WHEN requirements are necessary HOW requirements will be fulfilled

24 Security Objectives Technical statement of purpose for each security control within program Corellate to indicating attributes

25 Consequence of failure or absence of control Simple statement of effect

26 Vulnerability Defined A Vulnerability is essentially: a condition that allows a security control to be bypassed.

27 Control Inheritance Common controls are security controls whose implementation results in a security capability that is inheritable by one or more organizational information systems.

28 Control Inheritance Security controls are deemed inheritable [ ] when the systems or components receive protection from [ ] controls [that] are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the systems or components Security capabilities [ ] can be inherited from many sources including, for example, [ ] other information systems.

29 Inheritance Examples Hardware inherits protection from: Firewalls on the network Locked doors of cabinets/rooms Users (Personnel) Managing organizations

30 Inheritance Examples Software inherits protection from: Hardware installed on Users (Personnel) Managing organizations

31 Vulnerability Analysis Classification Remediation Process Mitigation

32 Classification CVSS Base Score Temporal Score Environmental Score Impact of Functionality Risk Informed

33 Scoring

34 Scoring

35 Scoring

36 Remediation Usually one of two processes: Reconfigure Software OR Patch Software Eliminates Vulnerability

37 Mitigation Usually relies on control inheritance or Absence of consequence Limits Effect of Vulnerability

38 Risk Provides context Must tie to business process or system function

39 Risk Analysis Methods Many defined Choose one Apply consistently Simpler is better, but only as simple as possible

40 Vulnerability Documentation Correlate vulnerability to affected resources within the context of: Affected business process or system function Affected security objectives/ consequence of exploitation Mitigating controls Executive approval

41 Summary Document patch criteria Know your resources Embrace control inheritance Consistently apply guidance Document analysis Get approval

42 Thank You Questions? Comments. Concerns!