The OpenSSL flaw named Heartbleed is pretty huge. Many of us in the computer security industry are prone to hyperbole when a big exploit in a popular piece of software is announced, but I can't put it any better than Bruce Schneier did when he said, "On the scale of 1 to 10, this is an 11."
OpenSSL is a very popular open source service implementation that uses the SSL and TLS protocols. It is the backbone for literally tens of thousands of other programs and services that allow SSL or TLS. It's used in Apache, Nginx, and most open source operating systems (such as Linux and BSD) distributions. OpenSSL probably runs on 60 percent or more of the websites that offer HTTPS connections and is used for many other popular services that use SSL-/TLS-based protocols, like POP/S, IMAP/S, and VPNs.
There's a very good chance that if you can connect to an SSL-/TLS-based service and it's not running Microsoft Windows or Apple OS X, it's vulnerable. This includes most VPN appliances, copy machines, and even most appliances. If you can connect to it using HTTPS, and it's not running on Microsoft Windows or OS X consider it vulnerable until proven otherwise.
Note: Even computers running Microsoft Windows or OS X (which are not vulnerable by default) could be running software or services that are.
The bug, named Heartbleed, because it has to do with a routine common feature known as a heartbeat, was first introduced in December 2011, and wasn't removed from the OpenSSL code base until April 7, 2014. If you have anything running OpenSSL versions 1.0.1 to 1.0.1f (inclusive), it's vulnerable. The best summary site can be found at Heartbleed.com. Here's a good example of how the bug could be exploited and the potential impact.
When this bug appeared and I confirmed how easy it was, I started calling friends who I knew had tons of OpenSSL. Interesting, most of them felt that they either had it under control or didn't understand the scope. If you think you've patched the few computers you have that use OpenSSL and have called it a day, you probably don't understand how pervasive OpenSSL is. It is probably the way you connect to your security appliances. It's probably the way you connect to your routers, gateways, and switches. It's probably the way you connect to many of your (non-Microsoft) cloud services. To thoroughly mitigate the OpenSSL bug means interrogating your own environment and researching those you connect to.
For OpenSSL under your control
Step 1: Find and inventory OpenSSL instances
Start by looking for all instances of OpenSSL in your environment. A quick way to do that is to conduct a TCP port scan for default SSL and TLS ports using your favorite port scanner, and rule out those that are running Microsoft Windows, OS X, or other non-OpenSSL products. SSH, on TCP port 22 and HTTPS on 443, is a good start, but there are literally dozens of protocols and ports that could be using OpenSSL.
I came up with this quick list: 22 (SSH), 26 (encrypted SMTP), 443 (HTTPS), 563 (NNTP encrypted), 636 (LDAP over SSL), 989 and 990 (FTP encrypted), 992 (Telnet encrypted), 993 (IMAPS), 994 (IRC encrypted), and 995 (POP3S). There are probably dozens of other protocols that could use OpenSSL for its SSL/TLS protection, and any of these services could ultimately be running on any port (if not configured to use the well-known default port). Don't forget to include all the websites hosted external from your company but owned or managed by your team.
Step 2: Determine if port is running a vulnerable version of OpenSSL
After you've located your IP addresses and ports potentially running OpenSSL, run a scanner that can do a test connection and return the answering connection string (which often returns the version). Many scanners, like the very popular and feature-rich Nmap scanner (nmap.org), can do the port scanning and identify the vendor and version number at the same time. Very handy.
Step 3: Prioritize vulnerable assets
Next, identify which assets are vulnerable and what risk they exposure your company to. An Internet-exposed service containing confidential information, logon creds, and other critical services should certainly be sent to the top of the list. I would add security appliances and network devices there as well.