Blog posts by Alexei Balaganski
It really didn’t take long after my last blog post on SCADA security for an exciting new development to appear in the press. Several security vendors, including Symantec and F-Secure, have revealed new information about a hacker group “Dragonfly” (or alternatively “Energetic bear”) that has launched a massive cyber-espionage campaign against US and European companies mainly from the energy sector. Allegedly, the most recent development indicates that the hackers not just managed to compromise those companies for espionage, but possess the necessary capabilities for sabotage, disruption and damage to energy grids of several countries.
Previous reports show that the group known as “Energetic bear” has been operating since at least 2012, having highly qualified specialists based somewhere in Eastern Europe. Some experts go as far as to claim that the group has direct ties with Moscow, operating under control of the Russian secret services. So, it’s quite natural that many publications have already labeled Dragonfly as the next Stuxnet.
Now, as much as I love bold statements like this, I personally still find it difficult to believe it. I admit that I have not seen all the evidence yet, so let’s summarize what we do know already:
- A hacker group “Energetic Bear” has been active in the cyber-espionage scene since at least 2011. Their previous targets, besides manufacturing and energy companies, include as diverse organizations as Asian universities, US healthcare providers, European IT organizations, etc.
- The group often uses a remote access tool dubbed Havex, which appears to be their own custom development, but relies on other tools readily available on the black market as well.
- Experts have analyzed multiple variations of the Havex tool and, judging by activity patterns, concluded that its developers are operating within the Eastern European time zone.
- Until recently, the malware has been primarily distributed over “traditional” channels, such as spam mails and exploit kits.
Since the sites belonged to notable vendors of programmable logic controllers used in managing wind turbines and other critical equipment, there could not be any other conclusion than “Russia is attacking our energy infrastructure”, right? Or could it?
Quite frankly, I fail to see any resemblance between Stuxnet and Dragonfly at all.
Stuxnet has been a highly targeted attack created specifically for one purpose: destroy Iranian nuclear enrichment industry. It contained modules developed specifically for a particular type of SCADA hardware. It has been so complex in its structure that experts are still not done analyzing it.
Dragonfly, on the other hand, is based on existing and widely used malware tools. It’s been targeting a wide array of different organizations – current reports show that it’s managed to compromise over 1000 companies. Also, the researchers that have discovered the operation could not find any traces of PLC-controlling payloads, the only purpose of the tool appears to be intelligence gathering. The claims of ties to the Russian secret services seem to be completely unsubstantiated as well.
So, does this all mean that there is not threat to our energy infrastructures after all? Of course, it does not! If anything, the whole Dragonfly story has again demonstrated the abysmal state of information security in the Industrial Control Systems around the world. Keep in mind, this time the cause of the attack wasn’t even weak security of an energy infrastructure. Protecting your website from hacking belongs to the basic “security hygiene” norms and does not require any specialized software, a traditional antivirus and firewall would do just fine. Unfortunately, even SCADA software vendors seem to share the relaxed approach towards security typical for the industry.
The fact that the Dragonfly case have been publicized so much is actually good news, even if not all publications are up to a good journalism standard. If this publicity leads to tighter regulations for ICS vendors and increases awareness of the risks among ICS end users, we all win at the end. Well, maybe except the hackers.
Office 365 is a popular cloud-based office productivity service built around Microsoft Office platform. Initially released in 2011, it has gone through a major upgrade in 2013 and is currently offered with different plans for home, small business, midsize and enterprise customers. Internally, Office 365 platform uses Microsoft Azure Active Directory for identity management and, with the exception of home and small business plans, offers three identity models for different user management scenarios. Recommended approach is to always start with the simplest model and transition to the more complicated one (or back) any time as requirements change. Let’s have a quick look at these models.
This is the simplest identity model and also the only one available for home and small business users. It’s typically used when an organization has no existing on-premise directory. In this case, user's details are stored in the cloud directory only and can be managed using the standard Office 365 admin portal, which supports individual account management, as well as rudimentary batch processing using CSV files. Administrators can also reset user passwords or assign certain users (such as helpdesk staff) to perform this for other users. There is no way for a user to reset their own password.
Microsoft also provides a set of modules for Windows PowerShell to enable automation of common administration tasks. Another convenient option is using the Azure AD Graph API, which is a RESTful programming interface for developers to easily build applications integrating with Azure Active Directory.
The majority of organizations that already have an on-premise directory will definitely choose this model, which relies on several tools to synchronize existing user accounts with the cloud directory. Since Microsoft has introduced password hash sync in 2013, this model can also provide a “single sign-on” user experience with the same password on-premises and in the cloud without the complexity of identity federation.
Microsoft provides several different tools for directory synchronization, starting with the old and proven DirSync tool suitable for organizations that have a single Active Directory. In the simplest case DirSync can be installed directly on the domain controller and does not require any additional infrastructure.
Next-generation Azure AD Sync tool is being designed to replace DirSync with many new functions including support for other directories such as LDAP or SQL. More complex scenarios are possible using Microsoft Forefront Identity Manager and different connectors (currently this is still the only solution to synchronize with non-AD directories).
It should be noted that identity synchronization with Office 365 has several limitations. For example, synchronizing a single on-premise directory with several cloud tenants leads to multiple problems and is actively discouraged by Microsoft. Therefore, an organization having several Office 365 subscriptions should consider merging them into one using third party tools before setting up synchronization.
Since Synchronized Identity model covers the vast majority of use cases with significantly less administration effort, organizations should really consider deploying the federation infrastructure only for certain complex scenarios, for example:
- An ADFS infrastructure is already in place or there are existing third party identity providers;
- Special technical requirements, like smartcard authentication or support for password reset via Office 365 portal;
- Special policy requirements, like login auditing requirement or regulations prohibiting password synchronization.
Important note: one should not forget that federation still requires user accounts to be synchronized with the on-premise directory, so one should never jump directly to federated model without setting up synchronization first. Azure Active Directory currently supports multiple protocols for identity federation with Active Directory Federation Services 2.0 or other third party Security Token Services. The most recent addition to this list has been SAML 2.0, which was announced in March 2014.
Microsoft has established “Works with Office 365 – Identity program”, which is a qualification for third party identity providers for federation with Office 365. A list of qualified providers is maintained here.
Unfortunately, current versions of Office desktop applications have a major incompatibility with many third party identity providers, since they only support the so called active authentication, which can only be accomplished using WS-Trust protocol. Until an update is released later in 2014, Microsoft officially only supports federation with AD FS 2.0 or with qualified third party providers from the list above.
Microsoft has gone a long way since the initial release of Office 365. Current generation of the Azure Active Directory enables different identity models that support nearly all possible usage scenarios. While there are still several major interoperability issues the company has to solve, unless you have a really unusual on-premise identity environment, you should be covered by one of the options above.
This article was originally published in the KuppingerCole Analysts' View Newsletter.
If you have attended our European Identity and Cloud Conference this May, you have probably noticed that, as opposed to the previous years, a significantly bigger part of the agenda and a substantial number of expo stands has been devoted to practical “down to earth” aspects of IT security. Multifactor authentication, encryption technologies, source code analysis, even backup - many of those topics have been previously looked down upon by strategists as boring tasks for IT engineers.
Well, times have changed. Explosive growth of computing power and networks, continued erosion of enterprise perimeters, development of more and more complicated Advanced Persistent Threats – all these trends are bringing good old Information Security back to the front pages. Before Snowden revelations, not many have given serious thought to encrypted communications. Before Heartbleed, not many people actually knew what “static code analysis” means.
There is however one topic that I personally consider extremely important, which has not received enough limelight in the recent years. This, of source, is Industrial Control System security, more often referred to as SCADA security.
In layman’s terms, SCADA (supervisory control and data acquisition) is a system for monitoring and controlling industrial processes of different kinds. Over decades, SCADA systems have evolved into large-scale systems operating complexes of equipment over large distances. SCADA systems are widely utilized in manufacturing, oil and gas refining, power generation and distribution, water treatment, and also for controlling facilities like heating and air conditioning in buildings or ships. In other words, SCADA systems control a significant part of every nation’s critical infrastructure, which makes them an important target for that nation’s enemies.
Unfortunately, SCADA systems have historically never been designed with security in mind. Early systems were monolithic physically isolated systems without any network connectivity. Later generations were based on proprietary LAN protocols that usually lacked any kind of transport security or authentication. Modern (or I should rather say “current”) SCADA systems have evolved into large-scale decentralized systems with increased number of network connections. They are gradually shifting from proprietary protocols to open standards and becoming increasingly interconnected with office networks and the Internet. Many workstations and human-machine interfaces (HMI) are actually standard Windows PCs often running outdated and unpatched software. Programmable Logic Controllers (PLC), the actual components controlling physical processes, are even more vulnerable, since their software and network protocols historically lack any security. Until recently, both SCADA vendors and enterprises deploying the systems gave little consideration to security issues, more or less relying on security by obscurity.
Discovery of Stuxnet malware in 2010 has shattered that false feeling of safety. A piece of software on a USB drive planted at the Iranian nuclear facility by US and Israeli intelligent services was able to disrupt the PLCs that controlled nuclear material enrichment centrifuges and ultimately physically destroy them. This case was widely publicized four years ago and naturally has led to establishment of standards and guidelines for prevention of such incidents both in the public and private sectors in many countries.
However, it somehow failed to grab the general public’s attention as much as Snowden and Heartbleed did later. Sure, the press regularly reports about new vulnerabilities found in different ICS systems, like this one (from last week!) or this. Check out my favorite quote:
The poor security of such software was revealed by a project Mr Rios and a colleague undertook in which they sought to find 100 Scada bugs in 100 days.So, what makes SCADA systems so difficult to secure? Many reasons, actually, that require completely different approaches to address them.
"We ended up finding over 1,000 bugs in 100 days," he said. "Scada software security simply hasn't kept up with modern times. The security of software like iTunes is much more robust than the software supporting our critical infrastructure."
- As I already mentioned above, current SCADA systems have evolved into distributed systems based on open network standards and commodity software, so they are theoretically vulnerable to the same attack vectors as other corporate networks. However, their design has historically never addressed security and identity issues at all.
- Although many components of SCADA systems run Windows, standard endpoint protection solutions are not particularly suitable for them, because even a minor latency spike caused by malware database update may lead to a disruption of the manufacturing process. Addressing process continuity in anti-malware software requires substantial changes in its logic.
- Traditional detection and blocking techniques are obviously not applicable for specialized systems like PLCs. Development of specialized solutions for their protection requires tight collaboration with PLC vendors. The same is true for integration with existing control and monitoring modules of SCADA systems.
- The newest trend in SCADA development is following the current trends in IT in general: growing adoption of Cloud services, introducing the “Internet of Things” approach to system design, etc. This leads to rapid growth of complexity, since number of modules and connections between them increases exponentially. Of course, this enables even more new attack vectors.
- Growing political tensions between both developed countries and global terrorist organizations mean that critical infrastructures will more likely to become targets of cyber-attacks with expected catastrophic outcomes.
Yes, until now we have not experienced a successful cyber-attack on a critical infrastructure that would lead to an industrial disaster with human casualties. But can we be sure that it won’t happen tomorrow? Not really. Luckily, both government organizations and security vendors are already working on different approaches to address this threat – both in short-term and long-term perspectives. And I firmly believe that EIC could be a good meeting place for these specialists to discuss this topic. Maybe, next year already?
If you’re looking for more information on this topic, check out these KuppingerCole’s published research documents:
Last Wednesday, eBay Inc. has announced that their user database has been compromised, and hackers were able to get away with “encrypted passwords and other non-financial data” of more than 145 million of eBay customers. eBay has informed us that financial information has not been affected and that they have not detected any increased fraudulent activity on their platform. Still, just in case, you should change your password and they are very sorry for this inconvenience.
Quite frankly, for any person working in the field of information security, this announcement raises a lot of inconvenient questions.
Apparently, the breach has occurred over two months ago, sometime in late February or early March. Yet, the official acknowledgement of the incident has only been made public last week. What took them so long? Does it mean that the hack went unnoticed for weeks if not months? In fact, both US and EU have security breach notification laws, and if the eBay case is not a direct violation of these laws, then in my opinion the laws have to be strengthened to avoid similar situations in the future.
It has been reported that the attackers managed to compromise employee log-in credentials, gain access to eBay corporate network and then proceed stealing customers’ emails, phone numbers, addresses, birthdates, and encrypted passwords. To me, this is a clear indication of a wildly inadequate security infrastructure or possibly of serious deficiencies of their service platform. The fact that eBay employees have complete access to their customer database strongly reminds of a similar case involving a certain intelligence agency and an idealistic system administrator. Apparently, eBay security team has never heard about Edward Snowden :)
Yet, what I find most disturbing is that by labeling this incident a mere inconvenience that only requires a password change as a precaution, eBay is actively downplaying the privacy-related implication of the hack. Hackers have managed to get away with enough personal information of millions of people from around the world to be able to use it for nearly any kind of cybercrimes on a massive scale: spamming, phishing, spreading malware, identity theft and so on. And, of course, if you’ve used the same credentials on another website, it will potentially be compromised as well.
Yet, even after a long chain of high-profile corporate security breaches (eBay, AOL, Target and, of course, the Heartbleed bug) general public still seems not to fully realize the extent of both security- and privacy-related consequences of these events. After hearing people saying something like “oh no, I have to come up with another strong password again” or “I already changed my password after reading about Heartbleed, isn’t it not enough?” I decided to try to make a list of measures every user has to take to protect themselves against past and future security breaches like eBay’s. Feel free to leave your suggestions in the comments if you believe I forgot something.
1. Think twice before giving an online service too much of your personal information. Does an obscure online game really need to know your birthdate or mother’s maiden name? A hacker might use this knowledge to impersonate you and get access to your online banking, for example. Life Management Platforms may be the future, but unfortunately we are not there yet, so protecting your personal information is still your personal responsibility.
2. Whenever possible, try to avoid using password authentication at all. Quite many online services already offer stronger alternatives to passwords, most often some kind of two-factor authentication. Google has their own 2-step verification platform, Facebook and Twitter support SMS-based verification codes, Dropbox even goes a step further and lets you choose from several different strong authentication methods. You’ll find a comprehensive list here, for example. Also look for buttons or logos of third-party strong authentication services like MYDIGIPASS, M-Pin or Duo Security. Surprisingly, eBay still doesn’t support strong authentication, yet its subsidiary PayPal does, and I strongly recommend starting using it ASAP.
3. Never, never, NEVER use the same password on different websites. Also never trust a password strength indicator on any website. The only truly strong password is a long randomly generated password, unique for each online service you’re using. And, by the way, never try to create a random password manually, humans are really bad at that. Use a specialized program or online service for that purpose.
4. Obviously, nobody can possibly remember all those complex unique passwords for many online services, but the worst mistake is to write it down and stick it to your monitor. Use a password management software instead. A modern password manager is more than just a secure encrypted storage for your passwords. It will offer many additional features like generating new secure passwords, automatically filling in login forms in browsers, storing secure notes and even warning you when a website you have an account on gets hacked and letting you change the password immediately. The most popular example seems to be LastPass and for a good reason. Besides offering all of the above for free, for a reasonable fee it provides access from mobile devices, a number of multifactor authentication methods, and other useful features.
5. When choosing a password manager, one has to take privacy implications into account as well. It’s not enough to protect your password vault from hackers, one has to consider the possibility that your entire list of passwords may be handed over to government authorities after a court order or simply land in one of NSA data centers. Therefore, always choose a solution that has a strong master encryption key that is only known to you. You may even opt for a standalone program like 1Password or KeePass and use third-party tools to synchronize its database, but this is less convenient.
6. Last but not the least: keep educating yourself about the latest developments in security software. Vote with your wallet for the developers that integrate privacy-enhancing measures into their products. Put pressure on your local lawmakers. After all, the future of information security depends on you as well.
A few days ago, while announcing their new Advanced Threat Protection initiative, Piero DePaoli, Symantec’s director of product marketing has made a provocative statement, proclaiming that ‘AV is dead’. His colleague Brian Dye said that antivirus software only catches around 45% of malware attacks, and that the company is shifting its focus towards responding to attacks instead of protecting against them.
Making such bold claims to promote new products or technologies is a common marketing tactic, we have even done something like that ourselves a couple of years ago, quite successfully. However, is there any substance behind this claim? Does it mean that, even armed with the modern IT security solutions, we’re still left unprotected from attackers and our only salvation is the future product from Symantec?
First, let’s clarify an simple terminology issue. A modern endpoint protection product is no longer just an antivirus. In fact, it would be safe to say that traditional signature-based antivirus programs (which first appeared over 20 years ago) are already dead for ages, since nobody makes traditional computer viruses (that is, self-replicating pieces of code that spread by embedding into other programs, boot sectors or data files) anymore.
Modern attacks against IT security have evolved into Advanced Persistent Threats, which are complex combinations of different attack vectors, including infected media, network exploits, software vulnerability attacks and social engineering. “Traditional” malware, such as Trojan programs and worms, still plays a central role in those attacks, however.
Modern IT security solutions have obviously evolved as well. Even ordinary users using a modern consumer antivirus program know very well that it includes not just a malware detection engine, but a firewall for protection from network attacks, some form of application control to stop Trojans, device control to prevent data leaks and so on. They also rely on cloud-based reputation services for application black- or whitelisting. We simply keep calling this kind of software an “antivirus”, just as we still call those powerful little computers in our pockets “phones”.
Yes, an antivirus alone is not capable of protecting against modern security threats. The only viable approach for developing efficient IT security is a multi-layered design combining endpoint protection, firewalls (although these are becoming less important since modern IT no longer has a rigid perimeter), database and application security, identity management and information rights management. Security experts have been talking about it years ago. And for years, security vendors have been working on developing more sophisticated, more versatile, more integrated solutions to fight those threats.
The latest trend in this evolution is the so-called Real-time Security Intelligence, where security solutions are becoming a mix of software and services, relying heavily on big data analytics and external sources of real-time security information, such as zero day attacks. For more information have a look at this blog post. The topic will also be prominently featured at the EIC 2014, and there is an in-depth report on it in the works.
As advanced persistent threats become more advanced and persistent coordinated, another aspect of a security application suite becomes more important: it’s no longer enough to offer protection against different attack vectors separately. A more integrated solution with tighter coupling between different modules and with centralized management and monitoring will necessarily provide more reliable detection and protection against those threats. In this regard, Symantec is actually lagging behind many other vendors that already offer technologies like sandboxing or reputation analysis, and in better-integrated packages. A notable example here would be Kaspersky Lab, which offers a single-vendor solution with the level of integration nearly impossible to achieve by technology acquisitions or partnerships.
So, is Antivirus really dead? Yes, and it’s been buried many times in the past.
Should we worry about it? Not really, since it keeps resurrecting with new technologies and functions, while somehow still keeping its familiar name. So, don’t be fooled by bold marketing claims, but look for multi-layered and tightly-coupled security solutions, they are still relevant and won’t go away any time soon.
Two weeks have passed since the day the Heartbleed Bug has been revealed to the world, and people around the world are still analyzing the true scale of the disaster. We’ve learned quite a lot during these two weeks:
- After Cloudflare initially expressed doubt that the bug can really leak SSL private keys, they were quickly proven wrong by security researchers. Unfortunately, there is no way to avoid reissuing and revoking all existing SSL certificates;
- A week ago, Bloomberg has reported that NSA may have known about the vulnerability for years and used it to gather critical intelligence. The agency has of course quickly denied having any previous knowledge about the bug. Yet many researchers have pointed out that NSA’s long standing practice of storing information it cannot decrypt for later analysis would theoretically allow it to steal a web site’s private key after April 7th and use it to crack the old data from its archives. Unfortunately, only a small fraction of web servers currently uses the “forward secrecy” technique that would have rendered this type of attack impossible.
- Although, thanks to a well-organized awareness campaign (giving the bug a catchy name and a logo was a brilliant idea, attracting attention of people outside of IT to the problem), most major web services have acted quickly, patching the vulnerability; however, not all of them were agile enough. For example, the web site of Russian Railways remained unpatched for a week after the bug discovery, which reportedly allowed hackers to steal over 200.000 credit card numbers.
The Internet is unfortunately not as safe and reliable as many people, even among IT experts, tend to believe, and only a joint effort can fix it.
Sure, we’ve known about data leaks, malware attacks, phishing, etc. for years. However, there is a fundamental difference between being hacked because of ignoring security best practices and being hacked because our security tools are flawed. One thing is forgetting to lock your door before leaving, the other is locking it every time and one day discovering that the lock can be opened with a fingernail. An added insult in this particular case was that people still using outdated OpenSSL versions were not affected by the bug.
As I wrote in my previous post, the Hearbleed bug has exposed a major flaw in the claim that Open Source software is inherently more secure because anyone can inspect its source code and find vulnerabilities. This claim does not just come from hardcore OSS evangelists; for example, BSI, Germany’s Federal Office for Information Security, is known for promoting Open Source software as a solution for security problems.
Although I believe that in theory this claim is still valid, in reality nobody will do a security audit just out of curiosity. Even the project developers themselves, often outnumbered and underfunded, cannot be blindly expected to maintain the security standard high enough. It’s obvious that a major intervention is needed to improve the situation: both as financial support from corporations that use open source software in their product and as more strict government regulations.
In fact, the Heartbleed accident may have acted as a catalyst: Germany’s SPD party is currently pushing for government support for Open Source security, above all in form of formal security audit carried out by BSI and funded by the government. TrueCrypt, another widely used OSS encryption software, is currently undergoing a public audit supported by crowdfunding. I can only hope that corporations will follow the suit.
For software developers (both commercial and OSS) an important lesson should be not to rely blindly on third party libraries, but treat them as a part of critical infrastructure, just like network channels and electrical grid. Security analysis and patch management must become a critical part of development strategy for every software and especially hardware vendor. And of course, no single approach for security is ever going to be reliable enough – you should always aim for layered solutions combining different approaches.
One of those approaches, unfortunately neglected by many software vendors, is hardening applications using static code analysis. Surely, antimalware tools, firewalls and other network security tools are an important part of any security strategy, but one has to understand that all of them are inherently reactive. The only truly proactive approach to application security is making applications themselves more reliable.
Perhaps unsurprisingly, code analysis tools, such as the solution from Checkmarx or more specialized tools my colleague reviewed earlier, don’t get much hype in media, but there have been amazing advances in this area since the years when I’ve personally been involved in large software development projects. Perhaps they deserve a separate blog post.
As just about every security-related publication has reported today, a critical vulnerability in OpenSSL has been discovered yesterday. OpenSSL is a cryptographic software library, which provides SSL/TSL encryption functionality for network traffic all over the Internet. It’s used by Apache and nginx web servers that serve well over half of the world’s web sites, it powers virtual private networks, instant messaging networks and even email. It’s also widely used in client software, devices and appliances.
Because of a bug in implementation of TLS Heartbeat extension, remote attackers are potentially able to trigger a memory leak on an affected server and obtain different kinds of sensitive information including server’s private keys. The most embarrassing part of this is that the bug has been discovered in past OpenSSL releases dating back to 2012. Specifically, all OpenSSL versions from 1.0.1 to 1.0.1f are vulnerable. The bug has been fixed in the version 1.0.1g, released yesterday.
Needless to say, potential consequences of this vulnerability are huge. Any remote attacker can theoretically leak a server’s private key and then easily decrypt any past or future SSL-encrypted traffic from that server without leaving any traces of an attack. This means that simply patching the vulnerability is not enough; all services involved in handling sensitive information also have to change their private keys and reissue their SSL certificates.
If your server is compromised, the first step should be updating OpenSSL to 1.0.1g – all major Linux and *BSD distributions have already made updates available. If it’s not possible, you can recompile OpenSSL from the source code with heartbeat support disabled.
Unfortunately, it’s not possible to detect whether your server has already been attacked using this bug. So, to be on the safe side, you should consider reissuing your SSL certificates with new private keys.
One rather sad consequence of the whole Heartbleed debacle is that it delivered a serious blow to a major claim of open source proponents that open source software is inherently more secure because more people can inspect its source code and find possible vulnerabilities. While potentially it is true, in reality not many people would do that for such a large-scale project like OpenSSL just out of curiosity. I can only hope that finally someone will have a good reason to sponsor a proper security audit for OpenSSL and other open source security software.
This is also a good opportunity for service providers to upgrade their SSL key length to ensure more reliable encryption.
Since the documents leaked last year by Edward Snowden have revealed the true extent of NSA powers to dig into people’s personal data around the world, the topic of protecting internet communications has become of utmost importance for government organizations, businesses and private persons alike. This is especially important for email, one of the most widely used Internet communication services.
One of the oldest Internet services still in use (SMTP protocol has been published in 1982), email is based on a set of inherently insecure protocols and by design cannot provide reliable protection against many types of attacks. Hacking, eavesdropping, forged identities, spam, phishing – you name it. Yes, there have been numerous developments to improve the situation over the years: transport layer security, anti-spam and anti-malware solutions, even text encryption. However, all of them are considered optional add-ons to the core set of services, since maintaining backwards compatibility with decades-old systems prevents us from enforcing new security-aware standards and protocols.
For the same reason we cannot just abandon email and switch to new, more secure communication services: most of our correspondents still use email only. Companies providing secured email services have existed for over a decade, but their adoption rates have always been low. Security experts have been fighting this inertia for years, educating the public, developing new protocols and services and pushing for stronger regulations. Alas, people are lazy; they always tend to choose convenience over security.
At least, it was like that until last year. Thanks to Snowden, people suddenly realized that their confidential communications are not just theoretically vulnerable to hacking or other illegal activities. In fact, nearly all their communications are routinely siphoned to huge government datacenters, where they are stored, analyzed and matched to other sources of private information. Even worse, all this is completely legal under current laws, and Internet communications providers are forced to silently cooperate with intelligence services – no hacking required.
Finally, people started to take notice. Finally, not just corporate IT managers, but informed consumers have come to understand that the only reliable protection against all kinds of eavesdropping is end-to-end encryption. Unfortunately, it seems that not everyone understands what exactly “end-to-end encryption” is.
The reason that motivated me to write this post was an article titled “Google encrypts all Gmail communications to protect users from NSA snooping”. Several German email providers like GMX and web.de used the same rhetoric when they have announced similar functionality as well. Even De-Mail, which is a paid service from German government, does not offer mandatory encryption.
Of course, this statement cannot be further from reality. Yes, forcing all users to use encrypted SSL connection to a webmail service is good news. In fact, I would even recommend using a tool like HTTPS Everywhere to enable SSL automatically on many major websites, because it makes browsing more secure and provides protection against man in the middle attacks, which can steal your passwords.
However, when it comes to email, SSL will only protect the “first mile” of your message’s journey to its destination. As soon as it reaches your provider’s mail server, it will be stored on the disk in a completely unencrypted format, open for snooping to server administrators, secret services or hackers. When the message is relayed to the next mail server, chances are that the transport channel won’t be encrypted, too, simply because the other server does not support it. On its way, your mail will be read and analyzed by multiple servers and other devices (anti-spam services, antimalware appliances, firewalls with deep packet inspection and so on). Any of these devices can store a copy for later use or simply collect metadata in form of logs.
For companies like Google, being able to snoop through your emails is even fundamental for their business model: they need to serve you the most relevant ads, increasing their revenues. They can do it legitimately, because it’s part of their TOS. They will even share collected information with third parties. No kind of transport encryption will change that.
Companies building their business model on trust and aiming to provide a truly secure service, both in technical and legal terms, face a different kind of problem. They can simply be forced to hand all master keys over to the government, rendering all encryption useless. Thanks to Ladar Levison of Lavabit, we now know that, too.
Therefore, in my opinion, the only reasonable method of secure email currently available is to use a desktop mail program with a form of public key encryption to encrypt all outgoing mails directly on your computer and to decrypt them directly on the recipient’s computer. Unfortunately, several protocols currently in use (most common are S/MIME and OpenPGP) are incompatible and most mail programs require third party add-ons to implement them. In addition, before you’ll be able to encrypt your messages, you need to exchange encryption keys with the other party over a secure channel (not email!). And, of course, you should always keep in mind that merely the fact that you are using encryption may attract the attention of secret services: an honest man has nothing to hide, doesn’t he? Unfortunately, the way email works it cannot provide any kind of plausible deniability, since message metadata are never encrypted. That’s probably one of the reasons for the recent surge in popularity of ephemeral messaging services like Threema or Telegram, which at least claim not to keep any traces of your messages on their servers. Whether you should trust these claims is, of course, another difficult question…
By the way, the future of encryption and privacy-enabling technologies will be a big topic during our upcoming European Identity & Cloud Conference. Leading experts will join Ladar Levison himself to discuss technical, political and legal challenges. You should be there as well!
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.
AI for the Future of your Business: Effective, Safe, Secure & Ethical Everything we admire, love, need to survive, and that brings us further in creating a better future with a human face is and will be a result of intelligence. Synthesizing and amplifying our human intelligence have therefore the potential of leading us into a new era of prosperity like we have not seen before, if we succeed keeping AI Safe, Secure and Ethical. Since the very beginning of industrialization, and even before, we have been striving at structuring our work in a way that it becomes accessible for [...]