How to create a Patch and Vulnerability Management process to keep the organization safe.

1. Patch and Vulnerability Management
Marcelo Martins
linkedin.com/in/marcelomartins

2. Agenda
§ Why does it matter?
§ Relationship
§ with Risk Management
§ with Penetration Test
§ Patch and Vulnerability Management
§ Establishing metrics
§ Planning ahead
§ Conclusion

3. § Assets
§ 1 – Business processes (or sub-processes) and activities,
for example:
§ Processes whose loss or degradation make it impossible to
carry out the mission of the organization
§ Processes that contain secret processes or processes involving
proprietary technology
§ Processes that, if modified, can greatly affect the
accomplishment of the organization's mission
§ Processes that are necessary for the organization to comply
with contractual, legal or regulatory requirements
Source: ISO/IEC 27005:2011 B.1
Why does it matter?

4. § Assets
§ 2 – Information
§ Vital information for the exercise of the organization's
mission or business
§ Personal information, as can be defined specifically in the
sense of the national laws regarding privacy
§ Strategic information required for achieving objectives
determined by the strategic orientations
§ High-cost information whose gathering, storage, processing
and transmission require a long time and/or involve a high
acquisition cost
Source: ISO/IEC 27005:2011 B.1
Why does it matter?

5. § Vulnerabilities: Software or configuration flaws
that weaken the security of an asset
§ Ex: Used to gain access to a system
§ Controls
§ Software patches
§ Configuration changes
§ Flawed software or service removal
§ Threats: Exploit vulnerabilities and cause damage to
the asset
§ Ex: exploit scripts, worms, viruses, rootkits e Trojan
horses
Why does it matter?

6. Vulnerabilities
Threats
(agents)
Controls
Risk
Assets
Impactexploit reduce
potencialize risk and
cause impact
affects
mitigate
Why does it matter?
are present are implemented

7. Why does it matter?

8. Why does it matter?

9. Why does it matter?

10. Why does it matter?

11. Why does it matter?

12. Why does it matter?

13. Why does it matter?

14. Why does it matter?

15. Why does it matter?
The more we
use…
The less we
need to use…
Vulnerability
Management
Changes
Management
Configuration
Management
Incident
Management
Business
Continuity
Management

16. Agenda
§ Why does it matter?
§ Relationship
§ with Risk Management
§ with Penetration Test
§ Patch and Vulnerability Management
§ Establishing metrics
§ Planning ahead
§ Conclusion

17. Relationship
Risk Management
Information Security
Management
Vulnerability
Management

18. Relationship
Vulnerability
Assessment
Pre-engagement Interactions
Intelligence Gathering
Threat Modeling
Vulnerability Analysis
Reporting
Penetration
Test
Pre-engagement Interactions
Intelligence Gathering
Threat Modeling
Vulnerability Analysis
Exploitation
Post Exploitation
Reporting

19. Relationship
Vulnerability
Assessment
Usually has a broader scope
than Penetration Test
Predictable, because network
adm is aware of the tools
being used
May include several false
postitives
Produces a report with
recommendations for risk
reduction
Penetration
Test
Exploits specific attack
vectors (services or assets)
May happen unannounced, to
test incident response
Trustworthy because provides
evidence of break in (root!)
Pen Testing = Proof of
Concept against
vulnerabilities
Produces a binary result: got
root or not

20. Agenda
§ Why does it matter?
§ Relationship
§ with Risk Management
§ with Penetration Test
§ Patch and Vulnerability Management
§ Establishing metrics
§ Planning ahead
§ Conclusion

21. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

22. Monitor vulnerabilities

23. Monitor vulnerabilities
§ Some tools

24. Monitor vulnerabilities
§ Some sources of alerts
§ NIST NVD
§ nvd.nist.gov
§ CVE
§ cve.mitre.org
§ US-CERT
§ us-cert.gov
§ CERT.BR
§ cert.br
§ Vendor site and e-mail lists

25. Monitor vulnerabilities
§ Scope Definition
§ Avoid the situation where the Organization is aware of a
serious security flaw. If there is awareness and no
patching, there is no due diligence
§ If a security incident is related to a known vulnerability not
patched by the Organization, it may open a possibility to
claims of damage
Vulnerability analysis without patching has little value
Little analysis and lots of patching is better than lots of
analysis and little patching

26. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

27. Establish priorities
Likelihood
Consequence

28. Establish priorities
Risk Quantification
Loss
Expectancy
Control
Cost
Exposure
Factor

29. Establish priorities
Acceptable
Risk
Controlable
Risk
Unacceptable
Risk

30. Establish priorities
Assets
Process or
system
Business
objective
Billing
e-Commerce Email

31. Establish priorities

32. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

33. Manage knowledge
§ Maintaining a database
§ Manually maintained databases should contain
instructions on removing vulnerabilities by installing
patches or performing workarounds, as well as the actual
patches when applicable
§ Linking resources
§ While the creation of a database is recommended,
resource constraints may limit an organization to listing
only Web sites or specific Uniform Resource Locators
(URL) for each patch

34. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

35. Test patch
§ Many vendors provide mechanisms of authentication
§ Patches should have their authenticity verified, using PGP or
digital certificates
§ Antivirus software should scan all patches before
installation
§ And before that, make sure the antivirus and its signature
database are updated
§ Patches e configuration changes should be tested in the
testing environment, they can bring unexpected results
§ Some patches are extremely complicated and largely affect the
operating system by replacing files and changing system
settings

36. Test patch
§ Uninstallation option (undo) must be seriously taken
into consideration
§ Even though, sometimes the uninstallation process
cannot bring the system back to its previous state

37. Test patch
Development
Environment
Testing
Environment
Prodution
Environment

38. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

39. Implement patch
Risk Treatment
Risk modification
Implement
controls
Risk avoidance
Cancel the
operation
Risk sharing Buy insurance
Risk retention “I’m feeling lucky”

40. Implement patchReduceRisk
• There is no
“zero risk”.
• To cancel the
operation avoids
the risk but may
not be the best
option.
• The objective is
to make money
with adequate
risks.
TransferRisk
• Insurance won’t
transfer risk. It
will only transfer
risk of financial
losses.
• Health
insurance won’t
transfer death
risk. Life
insurance? Not
a chance.
• Control cost is
the cost of
insurance.
AcceptRisk
• May not be so
bad. Depends
on factors and
costs.
• A soccer coach
knows there is
about 50/50
chance of
winning the
match, even
managing the
stronger team.
• Risk is inherent
to business.

41. Implement patch

42. Implement patch
§ Threat exposure
§ Determinate the real meaning of the threat or vulnerability
and which systems are vulnerable or exposed, focusing
on critical systems
§ Determinate the risk of applying the patch and if the patch
affects the functionality of other applications and services
(should also be addressed in Changes Management)

43. Implement patch
§ Recent backup
§ Before making any changes, it is better to make sure
there is a recent backup copy. This way, it is easier to
restore the environment
§ Many assets
§ Patch implementation gets very hard when there are
thousands of assets. Automated solutions (EPM –
Enterprise Patch Management) may be the answer.

44. Implement patch
§ Delay of patch implementation must be carefully
considered
§ Threat level
§ Internet accessible assets, many systems to be patched
§ Exploitation risk
§ If the vulnerability may be easily exploited, the patch (or virtual
patch) should be immediately installed
§ Exploitation consequences
§ Critical systems or systems containing sensitive information
should be patched as soon as possible

45. Implement patch
§ Possible problems
§ The instalation agent may reduce performance or make
the systems uninstable
§ Patches may be incompatible with other softwares
§ User may lose informatgion when the agents reboots the
system to install the patch
§ EPM agent may be itself another security threat
§ Mobile users may have problem when EPM tries to install
a large amount of patches as the user logs on

46. Implement patch
§ Determinate root cause
§ Many vulnerabilities are the result of poorly formed
system configuration or user administration policies, and
inadequate provisioning or change management
processes.
§ Eliminating root causes requires improvements in the
policies and processes that are used to provision,
configure and change systems, and administer users.

47. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

48. Verify implementation
§ Verify that files and settings were changed as
specified by the vendor
§ Run a vulnerability scanner
§ Make sure patches were installed by log review
§ Make use of penetration testing services to make
sure that the vulnerability was patched

49. Patch and Vulnerability Management
Monitor
vulnerabilities
Establish
priorities
Manage
knowledge
Test patch
Implement
patch
Verify
implementation
Improve the
process

50. Improve the process
§ Training
§ Automated patch management solutions
§ Enterprise patch management
§ Learned lessons
§ Implementation flaws
§ Slow bandwidth and processing power
§ User permissions
§ Best date and time

51. Agenda
§ Why does it matter?
§ Relationship
§ with Risk Management
§ with Penetration Test
§ Implementing Patch and Vulnerability Management
§ Establishing metrics
§ Planning ahead
§ Conclusion

52. § Every organization should consistently measure the
effectiveness of its patch and vulnerability management
program and apply corrective actions as necessary.
§ Without such a capability, even the best-designed security
architectures can be susceptible to penetration or other
forms of exploit.
Establishing metrics
Metric Name (Example) Units
Vulnerability ratio Vulnerabilities/Host
Unapplied patches ratio Patches/Host
Network services ratio Services/Host
Response time for vulnerability and patch
identification
Time
Patch response time (critical) Time

53. Agenda
§ Why does it matter?
§ Relationship
§ with Risk Management
§ with Penetration Test
§ Implementing Patch and Vulnerability Management
§ Establishing metrics
§ Planning ahead
§ Conclusion

54. § Acting before the infection
§ For any single vulnerability for which a widespread worm
will be created, manual monitoring and patching is much
more cost-effective than responding to a worm infection
§ Enterprise Patch Management (EPM)
§ Given that patches are constantly released, manual
patching becomes prohibitively expensive unless the
operating environment consists of only a few software
packages (thus decreasing the total number of patches
needed)
Planning ahead

55. § Enterprise patch management
§ All moderate to large-size organizations should be
using EPM
§ Even small organizations should be migrating to
some form of automated patching tool
§ Manual patching is becoming ineffective as the
number of patches grows and as attackers develop
exploit code more rapidly
§ Only uniquely configured computers and appliance-
based devices should continue to be patched
manually
Planning ahead

56. Planning ahead
§ Types of EPM
§ There are two primary categories of enterprise patch
management tools
§ those that use agents
§ those that do not
§ Some products support both approaches and allow the
administrator to choose the approach that is most efficient
for the environment

57. § New acquisitions
§ Consider less complicated products. More code, features,
and services can mean more bugs, vulnerabilities, and
patches
§ Delay implementing recently released major operating
systems or applications until the experiences of others
can be included in the decision-making process
§ Consider software validated by independent testing. For
the greatest assurance, the software’s source code
should be evaluated
§ Use only versions of software that are currently
supported. Obsolete software beyond its lifecycle often
has flaws that are only addressed in the newer, supported
versions
Planning ahead

58. § Standardization
§ The standard configuration will likely include the following
items
§ Hardware type and model
§ Operating system version and patch level
§ Major installed applications (version and patch level)
§ Security settings for the operating system and applications.
§ In many cases, these standardized configurations can be
maintained centrally, and changes can be propagated to
all participating IT resources.
Planning ahead

59. § Post incident patching
§ Patching after a security compromise is significantly more
complicated than merely applying the appropriate patch
§ The vulnerability that was exploited must be patched
§ It will not eliminate rootkits, backdoors, or most other changes
that might have been introduced by the intruder
§ For example, the Code Red II worm placed backdoors on
compromised systems, and later the Nimda worm
exploited those backdoors
§ A compromised system should be reformatted and
reinstalled or restored from a known safe and trusted
backup
Planning ahead

60. Agenda
§ Why does it matter?
§ Relationship
§ with Risk Management
§ with Penetration Test
§ Implementing Patch and Vulnerability Management
§ Establishing metrics
§ Planning ahead
§ Conclusion

61. Conclusion
§ There must be a Vulnerability Management process
§ Little analysis and lots of patching
§ Network administration must be kept informed of
disclosed vulnerabilities
§ The environment should be standardized and well-documented
§ All changes must go through Changes Management
§ Every change must be tested at the testing environment
§ An automated process of patch installation may have the
best cost/benefit

62. References
§ NIST
§ SP 800-40
§ Creating a Patch and Vulnerability Management Program
§ SP 800-115
§ Technical Guide to Information Security Testing and Assessment
§ CVE
§ http://measurablesecurity.mitre.org/directory/areas/
vulnerabilitymanagement.html
§ ISO/IEC 29147:2014
§ gives guidelines for the disclosure of potential vulnerabilities in
products and online services. It details the methods a vendor
should use to address issues related to vulnerability disclosure.
§ ISO/IEC 30111:2013
§ gives guidelines for how to process and resolve potential
vulnerability information in a product or online service.