Patch and Vulnerability Management

by Marcelo Martins

Slide 1

Slide 1 text

Patch and Vulnerability Management Marcelo Martins exploitedbunker.com

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Why does it matter?

Slide 8

Slide 8 text

Why does it matter?

Slide 9

Slide 9 text

Why does it matter?

Slide 10

Slide 10 text

Why does it matter?

Slide 11

Slide 11 text

Why does it matter?

Slide 12

Slide 12 text

Why does it matter?

Slide 13

Slide 13 text

Why does it matter?

Slide 14

Slide 14 text

Why does it matter?

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Relationship Risk Management Information Security Management Vulnerability Management

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Monitor vulnerabilities

Slide 23

Slide 23 text

Monitor vulnerabilities §  Some tools

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Establish priorities Likelihood Consequence

Slide 28

Slide 28 text

Establish priorities Risk Quantification Loss Expectancy Control Cost Exposure Factor

Slide 29

Slide 29 text

Establish priorities Acceptable Risk Controlable Risk Unacceptable Risk

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Establish priorities

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Test patch Development Environment Testing Environment Prodution Environment

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Implement patch Reduce Risk •  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. Transfer Risk •  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. Accept Risk •  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.

Slide 41

Slide 41 text

Implement patch

Slide 42

Slide 42 text

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)

Slide 43

Slide 43 text

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.

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

§  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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

§  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

Slide 55

Slide 55 text

§  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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

§  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

Slide 58

Slide 58 text

§  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

Slide 59

Slide 59 text

§  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

Slide 60

Slide 60 text

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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.