Patch and Vulnerability Management

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

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

§  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?

§  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?

§  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?

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

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

Relationship
Risk Management
Information Security
Management
Vulnerability
Management

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

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

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

Monitor vulnerabilities
§  Some tools

§  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

§  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

Establish priorities
Likelihood
Consequence

Risk Quantification
Loss
Expectancy
Control
Cost
Exposure
Factor

Acceptable
Risk
Controlable
Risk
Unacceptable
Risk

Assets
Process or
system
Business
objective
Billing
e-Commerce Email

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

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

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

Test patch
Development
Environment
Testing
Environment
Prodution
Environment

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

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.

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)

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.

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

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

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.

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

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

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

§  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

§  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

§  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

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

§  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

§  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

§  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

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

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.

Patch and Vulnerability Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Patch and Vulnerability Management

Similar to Patch and Vulnerability Management (20)

More from Marcelo Martins

More from Marcelo Martins (6)

Recently uploaded

Recently uploaded (20)

Patch and Vulnerability Management