Headlines have been spreading like wildfire this week about Heartbleed, a recently discovered bug affecting online encryption software OpenSSL, used for securing up to 70 percent of online communications. Canada's Revenue Agency even took its tax filing site offline to safeguard taxpayer data that may have been exposed as a result of Heartbleed.
Chicago-based Prescient Solutions works with customers in state and local government, including public safety and dispatch centers. Prescient CIO Jerry Irvine (pictured at left), a member of the National Cyber Security Task Force, talked to Government Technology to break down the Heartbleed threat, and offer some advice.
We need to start with SSL, which stands for “secure socket layer.” This is the way that most everybody communicates with secure websites. When you see “https” in the top of your Web browser, it means you’re doing a secure socket later connection to an http or Web server. This is how we normally communicate when we do online banking, use our credit cards or transfer personally identifiable information.
Open SSL is software that companies install in their file servers to allow users to log in to their server with SSL to encrypt your data and securely connect to their servers. Between 60 and 70 percent of all SSL servers that are being used today on the Internet are using Open SSL, and Open SSL has a bug in it. This bug was recently found, although it has really been out there since about 2011. I’m sure there are a number of people who have already had their data stolen as part of this. But now that it’s a known issue, it’s really important for organizations to address this.
Heartbleed allows unauthorized users to access communications between end users and secure servers at the server level. This is a server-based problem, not a user-based problem. Generally viruses or malicious applications that are causing problems exist at the user level. Since this is a server-based problem, the only way to fix it is for the company with the Open SSL server to install the new version and install new encryption credentials to resolve the problem.
It wasn’t a documented error, so the company that developed Open SSL didn’t know about it, or didn’t specifically tell anybody about it if they did know about it. It’s not something that hackers or other white hat type individuals had found and documented. Because there was little known about it, it just continued to exist in the wild. Quite honestly, it’s not unusual for bugs, viruses and things of that nature to exist in the wild for a while before they are actually detected and a definitive resolution is determined.
No, not necessarily. But it is very widespread because of the number of people using it and because of the potential loss of data. It puts companies, organizations and government agencies at an extreme liability risk, especially now that it’s a known issue. It’s a very nasty bug.
We have to look at it from two standpoints. First, as a government or public-sector user who is going out to other websites, it’s extremely important that we test the environments that we’re logging into. We have our banks, our vendors, our carriers, our partners that we log into using SSL. If we log into them and they are not patched, we’re giving all our data to the hackers. It’s extremely important that before we do anything on anyone else’s servers, we check to make sure those servers are patched. Then once it’s all fixed, go in and change all your user IDs and passwords because you don’t know if any of your data was corrupted or breached. Go in and create different user IDs and different passwords for those accounts that were held in that unsecure environment. Delete your old user IDs and passwords and create new ones after it’s been confirmed that it’s resolved.
For any organization that has their own internal websites, their own client-based VPN solutions – client- based VPN solutions are based on https, that SSL type of communication, that can be established in an Open SSL sever. Anybody who uses SSL in their own environment needs to check their own servers and make sure their IT department has installed the new version of software and tested it to make sure it is current.
I would suggest that should be necessary across all forms. Years ago, when Web communication became more prevalent, user IDs were often the same as your email address. And yet, user ID and password are two forms of authentication. For you to have a user ID that everybody knows eliminates half of your protection. Rather than using your email address or the same user ID that somebody can figure out, it’s important, especially for mission-critical servers that hold your personally identifiable information, financial information, Social Security numbers, that those user IDs are different, separate and unique. That way, a hacker or any other type of malicious user can’t go in and find out personal information about you. Having a unique user ID and a unique password gives me a fighting chance of being secure.
Absolutely. They should be checking and looking at their systems.
The Department of Homeland Security’s US-cert.gov tells you the top 10 things to do to secure yourself or Internet connectivity. No. 1 is always to have anti-virus installed on your device and have it updated. Most people don’t have anti-virus on their cellphone, which is a computer, the most used and most vulnerable computer in the world. We’re already not doing that. That’s the No. 1 thing you should do, have an anti-virus program.
The second thing is to have an automated patch management and update management solution in place. If organizations that have Open SSL were automatically updating their system, they would already have the most current version and this bug wouldn’t be a problem. If you are implementing policies, processes and standards that align with industry best practices, these issues go away. The predominance of bugs and hacks are a result of unpatched equipment or viruses.
Most organizations have some form of vulnerability. The problem is you get so many servers and nowadays with virtual servers, you have multiple servers on any one machine. And documentation isn’t always the best in any organization, public or private. Maintaining that level of standards and policies across multiple environments and devices is very difficult. That’s why it’s suggested that you have written policies and processes and procedures that document automated recurring events that provide a check and balance to those processes and policies.
Editor’s Note: This Q&A has been edited for length.
NEW ON THE PODCAST