Are You Prepared For More High-Impact Vulnerabilties?
•Download as PPTX, PDF•
1 like•715 views
When Heartbleed hit, many thought that it was a one of a kind. As new high-impact vulnerabilities such as Shellshock, POODLE and, to a lesser degree, GHOST have continued to appear, many IT organizations are realizing that this is the new normal. High impact vulnerabilities will continue to be discovered, and businesses must be able to quickly detect, patch and remediate vulnerabilities that affect an enormous number of systems. These massive vulnerabilities raise a number of challenges for IT organizations. Tripwire Security Analyst, Ken Westin, discusses: - Steps you can take today to minimize risk and exposure before the next high impact vulnerability is announced - How to develop a rapid response plan that will reduce the time required to identify new vulnerabilities on traditional operating systems as well as network and security devices - Key steps required to quickly identify potentially exploited systems so you can contain and remediate specific threats
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (20)
Similar to Are You Prepared For More High-Impact Vulnerabilties?
Similar to Are You Prepared For More High-Impact Vulnerabilties? (20)
More from Tripwire
More from Tripwire (20)
Recently uploaded
Recently uploaded (20)
Are You Prepared For More High-Impact Vulnerabilties?
- 10. CVSS v2
- 12. 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 Vulnerability Trends # Vulnerabilities
- 16. HIGH IMPACT VULNERABILITY RISK MANAGEMENT
- 20. Automated Exploit 46 7 12 14 32 46 42 Easy 32 3 13 10 19 34 23 Moderate 6 4 0 4 10 12 13 Difficult 25 26 19 36 71 130 54 Extremely Difficult 8 29 16 60 28 39 53 No Known Exploit 92 41 60 140 90 153 285 Exposure Local Availability Local Access Remote Availability Remote Access Local Privileged Remote Privileged
- 21. NIST 800-53 Controls CA–07 Continuous Monitoring CM–08 Information System Component Inventory IA–03 Device Identification and Authentication SA–04 Acquisition Process SC–17 Public Key Infrastructure Certificates SI–04 Information System Monitoring PM–05 Information System Inventory
- 22. NIST 800-53 Control CA–07 Continuous Monitoring CM–02 Baseline Configuration CM–08 Information System Component Inventory CM–10 Software Usage Restrictions CM–11 User–Installed Software SA–04 Acquisition Process SC–18 Mobile Code SC–34 Non–Modifiable Executable Programs SI–04 Information System Monitoring PM–05 Information System Inventory
- 24. NIST 800-53 Control CA–07 Continuous Monitoring CM–02 Baseline Configuration CM–03 Configuration Change Control CM–05 Access Restrictions for Change CM–06 Configuration Settings CM–07 Least Functionality CM–08 Information System Component Inventory CM–09 Configuration Management Plan CM–11 User–Installed Software MA–04 Nonlocal Maintenance RA–05 Vulnerability Scanning SA–04 Acquisition Process SC–15 Collaborative Computing Devices SC–34 Non–Modifiable Executable Programs SI–02 Flaw Remediation SI–04 Information System Monitoring
- 25. NIST 800-53 Control CA–02 Security Assessments CA–07 Continuous Monitoring RA–05 Vulnerability Scanning SC–34 Non–Modifiable Executable Programs SI–04 Information System Monitoring SI–07 Software, Firmware, and Information Integrity
- 26. NIST 800-53 Control AC–04 Information Flow Enforcement CA–03 System Interconnections CA–07 Continuous Monitoring CA–09 Internal System Connections CM–02 Baseline Configuration CM–03 Configuration Change Control CM–05 Access Restrictions for Change CM–06 Configuration Settings CM–08 Information System Component Inventory MA–04 Nonlocal Maintenance SC–24 Fail in Known State SI–04 Information System Monitoring
- 32. Detection: Precursors and Indicator Sources Alerts IDP/IPS SIEM/Log Intelligence Antivirus File Integrity Monitoring Third Party Threat Intelligence Malware file hashes IP addresses Mutex Registry Logs Operating systems, services and application Network device Network flow People Employees & Contractors Business partners Customers & External parties Media
- 38. March 21 10:23 – Google Security finds vulnerability March 31- Cloudflare patches April 1 - Google Security notifies OpenSSL a April 7 – Open SSL patch available April 12 – Exploits appear April 16 – FBI releases Snort signatures
- 41. Exploit Actions & Alerts Reporting Vulnerable Host Intrusion Detection
- 42. Intrusion Detection Exploit Vulnerable Host Actions & Alerts • Vulnerabilities of attacked host • Business value of target asset
- 43. Exploit Vulnerable Host Actions, Alerts & Reporting Intrusion Detection
Editor's Notes
- Hello my name is Ken Westin, I am a Security Analyst here at Tripwire. Today we will discussing high impact vulnerabilities such as Heartbleed, Shellshock and others we have seen over the past year. When Heartbleed hit many people thought it was a one off, a freak occurance, however then ShellShock, POODLE and others hit and we are now realizing that in many respects these high impact vulnerabilities are the new norm. Some analysts expect to see at least one of these types of vulnerabilities hitting per quarter. As such organizations need to establish strategies to deal with these types of vulnerabilities in their environments, both taking preventitive measures as well as a developing response plans for detection and remediation.
- So one good place to start is to define specifically what is a high impact vulnerability? To differentiate it from other vulnerabilities we define a high impact vulnerability as one that has both a wide distribution paired with a high risk of exploitation, usually something that is remotely exploitable. Many of these vulnerabilities are being discovered to have been present for decades and only now have been discovered. This causes a great deal of challenges as these libraries are widely distributed not only in tradiitional operating systems but also in embedded devices which are difficult or even imposslbe to update. The scary thing about these vulnerabiliites is that most people in the security industry including researchers believe that this is just the tip of the iceberg when it comes to these types of vulnerabilities. A few examples are Heartbleed, Shellshock and POODLE.
- Heartbleed is a vulnerability that was discovered by security researchers that affected OpenSSL. The vulnerability was in the heartbeat step of TLS The vulnerability opened the door for the creation of active exploits that could. Steal OpenSSL private keys Steal OpenSSL secondary keys Retrieve up to 64kb of memory from the affected server As a result, decrypt all traffic between the server and client(s)
- Shellshock was another high impact vulnerability that quickly had an exploit available. The exploit itself allowed remote code execution which is a little different from Heartbleed which was more about stealing keys and credentials. The advantage however was that there were traces of the exploits in log files. Tripwire actually released content to detect traces of Shellshock exploit attempts in log files.
- Another challenge with high impact vulnerabilities is how to score them. What is surprising is how a number of vulnerabilities are receiving the highest score of 10 while they have less of an impact to businesses than Heartbleed for example. This reveals some of the challenges of how these vulnerabilities are scored. It is important to note that even if a vulnerability is widespread it doesn’t always mean it will have a significant impact on the enterprise. Tyler Reguly - Vulnerability and Risk Scoring: What Ratings Really Mean at the RSA Conference
- Tripwire vulnerability scoring looks at the actual outcome of a vulnerability covering 4 of the 6 base metrics of CVSS, as well as providing more detail regarding the outcome. CVSS looks at the CIA Triangle – It’s difficult to judge what these really mean. The lack of clarity here has led some companies to create addendums to CVSSv2 IP360 looks at the impact of available exploits. Weaponized exploits, known malware, canned attacks all increase the score. CVSS looks at the difficulty in pulling off the attack and doesn’t account for tools that ease this process. IP360 Scores range from 0 to 60,000, providing for a great deal of granularity. CVSS Scores range from 1 to 10, with a heavy skew to small set of values within that range. IP360 Scoring allows scores to be tweaked to meet environmental needs at scan time using ASPL-Based Scoring. CVSS requires you sit down and calculate Environmental scores on a case by case basis.
- Tripwire's Vulnerability and Exposure Research Team (VERT) is dedicated no only helping our customers manage vulnerabilities, but also to provide additional context and information regarding high impact and other vulnerabilities. You can sign up for free VERT Threat Alert notfications where you will be sent data on any new high impact vulnerabilities, as well as a monthly update of other vulnerabilities you should be paying attention to in your environment.
- So why are we seeing these high impact vulnerabiliites now. Looking at the number of vulnerabilities we can see that there is an increase in vulnerabilities, but that does not tell us much as the actual severity of these vulnerabilities is still evenly distributed.
- As I mentioned earlier we are going to see more high impact vulnerabilities. The reason for this is frankly there are more security teams, both black and white hat looking for them. There is also a lot more money involved in finding these vulnerabilities, either thorugh legitimate research or selling of zero day exploits to governments or criminal syndicates. Security is a top target so we will continue to see more SSL vulnerabilities as well as more research into other security tools and utilities. Also like OpenSSL more libraries will be targeted as they are integrated into most applications. OpenSSL had the greatest ROI to exploit as it is everywhere and embedded in everything from web servers, mail servers, VPN and other tools.
- So some of you might think we are looking into space at a far away galaxy. What we are actually looking at is a mapping of packages in a typical Linux distribution, in this case Ubuntu. Not only are we looking at the packages themselves, but also their dependencies. Source: Thomi Richards
- If we zoom in a bit we can see things a little clearer with regards to depencies. A single line of bad code can have a cascading effect with regards to security. These dependencies reveal another key challenge for developers and researchers when they rush to patch these vulnerabilities, as there is a chance for introducing additional vulnerabilites or failure into these systems if not properly implemented and tested. So my question to you is have you hugged an open source developer lately? You should they deserve it.
- So how can we prepare for the next big one? In many respects I view high impact vulnerabilities like earthquakes or what the insruance industry refers to as an ”act of god” which by definition is an instance of uncontrollable natural forces in operation, the natural force in this case being human human fallibility. But for our purposes those responsible for managing the security of enterprise environments these vulnerabilities are largely outside of our control.
- Keeping with the theme of natural disasters a good place to go for us to understand risk mitigation is FEMA. FEMA defines risk as the sum of three factors, hazard, exposure and vulnerability. This same formula works in information where we simply replace hazard with hacker. As a slight diversion I found it interesting that FEMA’s Preparedness cycle almost exactly mirrors defense in depth cyles.
- When dealing with the risk of earthquakes FEMA utilizes hazard maps extensively, which are essentially heat maps highlighting areas of risk measured as the likelihood of experiencing earthquake shaking of various intensities. This allows them to understand where to focus their resources to make the biggest impact in reducing risk. What if we could do the same with our IT environments, where we can just as easily identify what systems are most at risk and identify and score hazards?
- If we could create a hazard map identifying what systems are most at risk when a high impact vulnerability hits, it might look something like this. Where our front end systems might have more exposure to the outside world, things like web servers, mail servers and other systems critical to our customers and employees. But then some of our backend systems may house sensitive data that if compromised could have a significant impact on our so we want to flag those as critical assets as well. One of the core foundational things organizations need to do in order to mitigate risk is to take an inventory of their IT assets both hardware and software. You cannot secure what you can’t see. The next step is to apply business context to those assets. Tripwire provides this type of scoring of assets at a very granular level, either groups of assets, or individual assets allowing IT organizations to identify what is important in the organization as well as what is most at risk when vulnerabilities strike. When a vulnerability hits the investment you make here goes a long ways to increase operational efficiency as your IT staff are able to focus on patching and remediating critical assets first that are most at risk, or if compromised pose the greatest risk to the organization.
- Similarly to scoring our assets, we can score our hazards. This is how the actual scoring screen is laid out in Tripwire IP360. It allows organizations to identify the most critical vulnerabilities in their environment, they can then drill in and see the devices and business context.
- One of the best ways to mitigate risk in your environment whether we are dealing with high impact vulnerabilities or not is throuth the application of the 20 Critical Security Controls, which are essentially a abstracted derivative of NIST 800-53 which a more almost prescriptive guide for those in the trenches. The 20 Critical Security Controls are a great tool for executives to understanding security best practices and communicate with security teams with regards to what needs to be done. Where I find the NIST 800-53 provides the more granular details that security and IT teams need to implement them thoroughly. At the end of this presentation I prepared a “High Impact Vulnerability Survival Guide” that includes a spreadsheet that maps the full CSC 20 to NIST 800-53 controls. I won’t go through them all here in the presentation, but wanted to list them out as we have both business and more technical leaders in this webcast today. So the first Critical Security Controls deals a bit with what we were talking about a few slides ago, taking inventory of what is in our environment. This not only includs
- CM-8: Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location.
- embarcadero building san francisco
- Many times you have heard the phrase in security, “it’s not a matter of if you have been breached, but when”. I would like to add to that, it is also important to identify how long you have been exposed, or simply being able to detect if you have been breached in the first place. The enterprise threat gap is a model that helps us illustrate the amount of time that passes through three critical phases. The detection gap indicates the amount of time it takes to discover an actual compromise and identify it’s scope. The remediation gap indicates the time between that detection and the amount of time it takes to limit the damage. Then we have the preventive gap which is the measure of time it takes to avoid repeated or similar attacks. This process allows you to answer three key questions to the business: Have we been breached? How bad is it? Can we avoid this happening again?
- http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
- I would like to illustrate how these rules work in more detail. For example, if an exploit attempt is made against a network…
- The intrusion detection system can now identify the attack signature and pass this information to Tripwire Log Center
- Tripwire Log Center can then initiate various actions, from sending alerts, opening a help desk ticket, to initiating scripts which may kick off remediation processes. In addition reports can be quickly generated for sharing across the organization for more in depth analysis of exploit patterns.
- To take this a step further, given the widespread availability and use of Heartbleed exploits for active exploitation as well as simply testing if systems are vulnerable, the number of intrusion detection alerts can become quite noisy, making it difficult for organizations to identify real threats. By leveraging the tight integration that Tripwire Log Center has with Tripwire’s Vulnerability Management solution IP360, we are able to correlate these exploit attempts with vulnerability information on that host. If an active exploit hits the host we can see if that host is running a vulnerable version of OpenSSL, if it has already been patched or is not vulnerable the exploit attempt may be reported on, but may not trigger an alert. However, if the exploit hits the system and it is vulnerable we would want to trigger an alert, or initiate other actions. Polll To better understand how Tripwire IP360 identifies vulnerabilities related to Heartbleed and OpenSSL I am going to hand the presenation over to Ed Smith. Thank You
- Tripwire Enterprise tells you what changed.