Patch and Vulnerability Management

Patch and Vulnerability Management

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

D5620264291804156c700573a3585317?s=128

Marcelo Martins

January 20, 2018
Tweet

Transcript

  1. Patch and Vulnerability Management Marcelo Martins exploitedbunker.com

  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 Impact exploit 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 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.
  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.