Patch and Vulnerability Management

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

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.