Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Patch and Vulnerability Management

Patch and Vulnerability Management

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

Marcelo Martins

January 20, 2018
Tweet

More Decks by Marcelo Martins

Other Decks in Technology

Transcript

  1. Agenda §  Why does it matter? §  Relationship §  with

    Risk Management §  with Penetration Test §  Patch and Vulnerability Management §  Establishing metrics §  Planning ahead §  Conclusion
  2. §  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?
  3. §  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?
  4. §  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?
  5. Vulnerabilities Threats (agents) Controls Risk Assets Impact exploit reduce potencialize

    risk and cause impact affects mitigate Why does it matter? are present are implemented
  6. 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
  7. Agenda §  Why does it matter? §  Relationship §  with

    Risk Management §  with Penetration Test §  Patch and Vulnerability Management §  Establishing metrics §  Planning ahead §  Conclusion
  8. 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
  9. 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
  10. Agenda §  Why does it matter? §  Relationship §  with

    Risk Management §  with Penetration Test §  Patch and Vulnerability Management §  Establishing metrics §  Planning ahead §  Conclusion
  11. Patch and Vulnerability Management Monitor vulnerabilities Establish priorities Manage knowledge

    Test patch Implement patch Verify implementation Improve the process
  12. 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
  13. 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
  14. Patch and Vulnerability Management Monitor vulnerabilities Establish priorities Manage knowledge

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

    Test patch Implement patch Verify implementation Improve the process
  16. 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
  17. Patch and Vulnerability Management Monitor vulnerabilities Establish priorities Manage knowledge

    Test patch Implement patch Verify implementation Improve the process
  18. 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
  19. 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
  20. Patch and Vulnerability Management Monitor vulnerabilities Establish priorities Manage knowledge

    Test patch Implement patch Verify implementation Improve the process
  21. Implement patch Risk Treatment Risk modification Implement controls Risk avoidance

    Cancel the operation Risk sharing Buy insurance Risk retention “I’m feeling lucky”
  22. 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.
  23. 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)
  24. 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.
  25. 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
  26. 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
  27. 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.
  28. Patch and Vulnerability Management Monitor vulnerabilities Establish priorities Manage knowledge

    Test patch Implement patch Verify implementation Improve the process
  29. 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
  30. Patch and Vulnerability Management Monitor vulnerabilities Establish priorities Manage knowledge

    Test patch Implement patch Verify implementation Improve the process
  31. 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
  32. Agenda §  Why does it matter? §  Relationship §  with

    Risk Management §  with Penetration Test §  Implementing Patch and Vulnerability Management §  Establishing metrics §  Planning ahead §  Conclusion
  33. §  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
  34. Agenda §  Why does it matter? §  Relationship §  with

    Risk Management §  with Penetration Test §  Implementing Patch and Vulnerability Management §  Establishing metrics §  Planning ahead §  Conclusion
  35. §  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
  36. §  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
  37. 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
  38. §  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
  39. §  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
  40. §  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
  41. Agenda §  Why does it matter? §  Relationship §  with

    Risk Management §  with Penetration Test §  Implementing Patch and Vulnerability Management §  Establishing metrics §  Planning ahead §  Conclusion
  42. 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
  43. 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.