The heartbleed vulnerability which results from an openssl bug related to handling DTLS heartbeat extension packets is easy to correct in a way that moving forward you are not vulnerable to *new attempts* to exploit the risk originated from this OpenSSL bug. In fact all major Linux OS distros support automated security updates and most likely your boxes are now patched with the latest openssl patches addressing the issue. However do make sure you restart services like apache after the fix is applied. To test you can use tools like heartbleeder for local services and external services but if all you want to test is your SSL website you can just go through SSLLabs which BTW should be run often as SSL vulnerabilities are nothing new and these guys do an excellent job about helping everybody know what "secured" (https) sites out there are strongly protecting users privacy and which ones are doing a poor job on it.
So we patched the vulnerability and the tools say we are not vulnerable anymore. We are done. Actually, we are not. What happens if someone already got let us say your site's private key thanks to a previous to the fix attack? Any traffic could be decrypted (this is true apparently only if your server is still vulnerable to FPS), your site might be target for communication eavesdropping (unless you also revoke the old SSL certificate), your site might have leaked some credentials. So what is next after openssl is patched and services are restarted?
Revoke existing SSL CertificatesA quick look into some major institution websites is telling me at the moment that while the fix has be deployed the certificates some of them are using are still old. So I assume those not changing certificates are not really using openssl. Let us hope so.
Force Password ChangeNobody complains about changing their LAN passwords every so often. However you see people hesitant to change web credentials every so often. Guess what? your local network is actually at a lower risk than your web tier, do the math. This is a good opportunity to develop if you still not have it a way to force password changes on the fly whenever something demands such measure. The heartbleed bug is such situation. After you revoke the old certificates and start using new ones you must change all your user passwords. Do not rely on them updating their passwords. You should have available a "Force Password Change" functionality for your authentication service.
Honest disclosureDepending on the nature of your business, regulations, privacy laws, board decision and many other factors you will end up sooner or later reaching your customers explaining that there might be a possibility that their data got compromised. You should assess exactly what kind of data could have been stolen.
How long my data could have been compromisedIf you use openssl in your website and you have not revoked the certificates then anybody who could have stolen your private key in the past will be able still to get even more information. While I cannot answer how long this has been known in small circles of hacker communities in looking at the current Google certificate (They co authored the discovery)it appears that they renewed their certificate not before March 12, 2014. So all I can say is that even those who discovered the vulnerabilities were vulnerable for almost the same period the rest of us are. However the more you wait to address all necessary steps the more vulnerable your services and clients are.
Things you should know as Internet userA vulnerability in OpenSSL used in most of the web servers around the globe was disclosed on April 7th. The vulnerability could allow an unauthenticated, remote attacker to retrieve an otherwise protected/private information held in small portions of the server memory. The retrieved memory could contain sensitive information like private keys (security certificate secret key) and user credentials. Exploits for this vulnerability are currently publicly available.
A compromised certificate secret key could allow the decryption of the otherwise secure network traffic either previously captured or real time. However attackers would require specific positions in the network which makes this exploit difficult for them.
A compromised private key could also be used to impersonate our portal service leading to Man In The Middle (MITM), phishing and spoofing attacks. This will need extra privileged network position as well, so while not impossible it is definitely a difficult exploit as well.
A compromised user/password combination could escalate to compromise other accounts while relying on other potential bugs at application layer. However, strong layered infrastructure and application security should mitigate the extent of a possible exploit.
Since portions of the memory might become available other more sophisticated attacks might happen if OpenSSL is left compromised. However most of the important systems relying on OpenSSL have been patched during this last week making this attack only possible if traffic was captured while the vulnerability was present and further analyzed with compromised private keys. Again the probabilities for such attack are really minimal although not zero for sure.
Things you should do as service providerOn April 7th OpenSSL.org security advisory (CVE-2014-0160) recognized the code bug in the OpenSSL project and on April 8 most of Linux distributions (at least) were patched. If you use automated patching you got the patches early which is good. Security patches should be automatically applied in all systems across the board, most companies guarantee to have tested them very well before delivering so worst case scenario there will be business disruption for a good purpose. Since that day you should have been working on revoking existing website certificates and planning for a mandatory password change for all of your users.
You should take security very seriously. You should have a person or third company in charge of Security (name that person Security Officer). The experience in security must be over 5 years at a minimum. The knowledge about the OS, protocols, application development, networking and beyond should be there. You should adopt security and privacy management systems already standardized (like ISO 27001 and SSAE 16) to follow best practices. Best practices include (but are not limited to) keeping track of security changes from Firewall rules changes all the way up to fixing Browser related vulnerabilities. Only restricted personnel should have access to production systems. Use a multi tiered security architecture which includes network intrusion detection, passwords stored encrypted and salted, sensitive information stored encrypted in databases, encrypted communication channels between all external and internal servers including email on TLS, SFTP, HTTPS and SSH. Use at three layers of application security (Controllers, Services and Data Access layer, train developers on best practices from OWASP, perform penetration tests in a test box regularly, establish browser support measures prohibiting the use of old and probably not patched client software. There is more to that list. You should be able to see real life examples and guidelines in this blog for a start however do subscribe to security lists and follow closely vulnerabilities related to the software you use. Have a roadmap with planned enhancements to increase protection for private information.
Have a safe browsing.