Vulnerability Management is more than patching your systems. A programmatic approach to risk reduction is critical, but often under-performing. This talk provides insight on how to implement a functional program.

1. Minimizing
Exposure
Strategies and Tactics for Effectively Managing
Vulnerabilities in Diverse Environments

2. / Who am I?
• Founder “Down the Security Rabbithole Podcast”
• Celebrating 10 years and nearly 500 episodes
• VP, Chief Security Strategist @ Lightstream Managed Services
• ~25 years in cyber-security, building, advising, at scale
• Lead strategy
• Board Member, Security Advisor Alliance
• Organization of CISOs in service to tomorrow’s generation

3. My slides are a little different

4. use these slides as a guide

5. Why are we still talking about
Vulnerability Management?
Regulations and Realities

6. Background

7. vulnerability management is fundamental

8. vulnerability management is more than
patching / patch management

9. sources of vulnerabilities:

10. 1. patches

11. 2. misconfigurations

12. 3. penetration testing results

13. 4. bug bounties program (if you have one)

14. all these together are vulnerabilities

15. vulnerability scanners are ancient tech

16. finding vulnerabilities is easy’ish

17. but then what?

18. who here still uses spreadsheets?

19. “then what?” is a 25+yr old problem

20. vulnerability management is not scanning

21. what is the goal?

22. programmatic reduction of risk

23. Technology

24. mid/late 90’s scanners showed up

25. remote scanning: auth & un-auth

26. local and distributed scanning

27. agent-based vulnerability scanning

28. cloud … more on that in a minute

29. basically – identification tech isn’t lacking

30. Technical Debt (aka, legacy drag)

31. technical debt is risk increase over time

32. minor issues today…

33. …are massive breaches in later

34. technical debt has 2 main causes:

35. business-feature dependence

36. accountability failures

37. *both are preventable

38. technical debt can bankrupt an IT org

39. Cloud Computing

40. cloud changes everything

41. more scale

42. more velocity

43. more options

44. also, more risk

45. Unresolved Issues

46. creating a culture of accountability

47. effectively communicating risk

48. identifying unknowns in the environment

49. reducing legacy technical debt

50. 3 key things you’ll want to know
practical knowledge, for application

51. // The 3, 2, 1 Principle

52. 3 risk tiers (priorities)

53. Suggestion: P1, P2, P3

54. P1: Critical (must fix) - SLA

55. predictable, direct critical business impact

56. options: fix

57. short SLA (fix time)

58. accountability at executive level

59. no* exceptions

60. P2: Important (should fix) - SLA

61. possible, or non-critical business impact

62. options: fix, or defer

63. reasonable SLA (fix time)

64. reported as part of security metrics

65. allowable exceptions

66. P3: Informational (should fix) - SLA

67. low or non-operational business impact

68. options: fix, defer, accept

69. long-term SLA

70. reported as part of security metrics

71. allowable exceptions

72. some things to remember -

73. determine a risk formula for deciding priority

74. simple formula = better acceptance

75. key: simplify risk tiers/levels

76. less is more

77. mistake: having too many “levels”

78. why? confuses the situation

79. simplicity is important

80. 2 points of follow-up

81. technical & business follow-up

82. advise & track at both levels

83. business needs to understand

84. technical needs to do the work

85. coordinate between the two effectively

86. communication is key, at both levels

87. 1 point of accountability

88. who is accountable?

89. work with your legal team – identify owners

90. ensure owners understand accountability

91. track, report, follow-up

92. must be an executive who can accept risk

93. // Vulnerability Management Lifecycle

94. yes Virginia, it’s a lifecycle

95. identify > triage > decision >
assign > track > report

96. most functional orgs track pending fixes

97. 3 options: fix, defer, accept

98. FIX is easy, and easy to track

99. create protocol to confirm a fix

100. fix == remediate

101. fix can be a compensating control

102. effectiveness of compensating control

103. DEFER means “fix at a later date”

104. needs to be tracked, reviewed, accepted

105. determine life of deferment

106. track and raise risk on expiration

107. ACCEPT is permanent

108. …unless things change?

109. accept is forever, but not really

110. accepted risks must be regularly reviewed

111. vulnerabilities do not grow old gracefully

112. // Decreasing Friction, Gaining Adoption

113. vulnerabilities show up in 3 places:

114. as technical debt/legacy

115. in pipeline

116. in project development

117. where should you start?

118. many would start at legacy – that’s wrong

119. start with new projects

120. less likely to ‘break something’

121. projects under development = resources

122. “stop adding to the pile”

123. then attack pipeline

124. fix while project is in development

125. lastly – go for the tech debt/legacy

126. most difficult, most likely to break

127. slowest and requires bureaucracy

128. Making It Work
Anecdotes on successful VM programs

129. this is a lot harder than it sounds

130. there are far too many tools

131. tech is helpful, not a solution

132. people make the program work

133. develop a program, that drives an outcome

134. think vulnerabilities, not patches

135. don’t be afraid to ask for help

136. Contact me
Rafal Los
• Email: Rafal.Los@Lightstream.tech
• Twitter: @Wh1t3Rabbit
• Podcast: https://ftwr.libsyn.com
• LinkedIn: https://www.linkedin.com/in/rmlos/
• Company: www.Lightstream.tech