Our digital lives are more or less governed by very few providers of products and services. Our desktop computing is almost invariably based on Microsoft Windows, our document collaboration is most likely based on either Google Docs or on O365, our instant messaging is either Whatsapp or Slack, our video collaboration is either Teams or Zoom, etc. Given the prevalence of digital life and work, you would expect more options to exist. However, all those large pies seem to each be divided into just a few thick slices each. Those lucky providers that won their dominance did so by catering to the needs of the masses while serving their own agendas, or more accurately: by serving their own agendas while giving enough to make their products preferable by the masses.

Customers appreciate ease of deployment and ease of use, and all of the dominant products excel in that. However, customers never said anything too explicit about security and customers never demanded data sovereignty. Those properties are also very non-compelling for some providers, either because they increase cost, because they prevent lock-in, or because they hinder business models that rely on using customer data. The vast majority of customers never really required, and hence never really got, anything more than ease of use and ease of deployment, along a few key functional features. For most customers, this is enough, but customers who also require security, privacy, and/or data sovereignty, face a challenge when working out alternatives.

But alternatives do exist, for desktop computing, for collaboration and for messaging and video communication. Those alternatives play an important role in our digital ecosystem, even if most people never care to use them.

In a previous post I wrote about cases in which machine-learning adds little to the reliability of security tools, because it often does not react well to novel threats. In this post I will share a thought about overcoming the limitation of machine-learning, by properly augmenting it with other methods. The challenge we tackle is not that of finding additional methods of detection, as we assume such are already known and deployed in other systems. The challenge we tackle is of how to combine traditional detection methods with those based on machine-learning, in a way that yields the best overall results. As promising as machine-learning (and artificial intelligence) is, it is less effective when deployed in silo (not in combination with existing technologies), and hence the significance of properly marrying the two.

I propose to augment the data used in machine-learning with tags that come from other, i.e., traditional, classification algorithms. More importantly, I suggest distinguishing between the machine-learning-based assessment component and the decision component, and using the tagging in both components, independently.

I recently came across this study titled “Unknown Threats are The Achilles Heel of Email Security”. It concludes that traditional e-mail scanning tools, that also utilize machine-learning to cope with emerging threats, are still not reacting fast enough to new threats. This is probably true, but I think this conclusion should be considered even more widely, beyond e-mail.

Threats are dynamic. Threat actors are creative and well-motivated enough to make threat mitigation an endlessly moving target. So aren’t we fortunate to have this new term, “machine learning”, recently join our tech jargon? Just like many other buzzwords, the term is newer than what it denotes, but nonetheless, a machine that learns the job autonomously seems to be precisely what we need for mitigating ever-changing threats.

All in all, machine-learning is good for security, but yet in some cases it is a less significant addition to our defense arsenal. Why? – Because while you learn, you often don’t do the job well enough; and a machine is no different. Eventually, the merits of learning-while-doing are to be determined by the price of the resulting temporary imperfectness.

Years ago, we did not trust cloud service providers, or we trusted them only when we had no choice. Then, consumers started using web-mail and other such services, and finally companies also moved into replacing their own IT with cloud applications. By now, we trust our service providers sufficiently, for the most part. We model our risks, we consider the benefits, and we usually decide that it’s worth it. But often enough, our trust in service providers still does not cause us the necessary warm and fuzzy feeling that is required for us to hand off all our data to the cloud and live a truly digital life. As it seems, thinking you are secure is one thing, and feeling you are sufficiently secure, even with your most critical data, is something else.

What do we do for now? – Use the cloud, but not for everything…

SSH is one of the best security protocols out there. It is used by anyone remotely logging into servers, as well as for secure connection to Git servers, and for secure file transfers via SFTP. One of the key promises of SSH is protection against active man-in-the-middle attacks. This makes SSH the best choice when connecting to a server over a hostile network, such as over a public hotspot. However, some SSH clients (particularly on mobile phones) void this protection by not caching server keys. Can you do anything about it? Yes, use private-keys instead of passwords for client authentication. Read more (also) for the technical details.

Tor is typically used to attain anonymity and preserve privacy online. This is by far the most common and appealing use for it. Most people without such concerns are not likely to ever install a Tor browser on their workstations, and it’s a pity; Tor has at least one additional use-case which is applicable to a much larger audience. This use-case is the prevention of certificate injection when using untrusted network connections.

It has been a while since Truecrypt was discontinued. While it still works on most platforms, including new Windows machines (except for the full-disk-encryption on some of them), and while there still is no evidence to indicate that it is insecure, users of Truecrypt find the situation bothersome; and for a good reason. By now it seems obvious than an alternative has to be found.

Shodan is a search engine for computers. It allows to search for hosts on the Internet not by the text they serve but by their technical properties as they reflect in responses to queries. The crawler Shodan uses to build its index does not read text that websites emit when visited, but instead it reads the information that the machine provides when probed.

Like most other technologies, this is another dual-use technology. It has both legitimate and malicious uses. The tool can be used for research, but it can be, and indeed has been, used for vicious purposes. Shodan will readily map and report Internet-accessible web-cams, traffic lights, and other IoT devices, including those with lax protection, such as those using default passwords or no passwords for log-in.

So is Shodan bad? Not at all. Those are exactly the forces that make us all more secure.

Snapchat is in the headlines again for allegedly leaking out nude photos of users. They strictly deny that there was any breach of their servers, and blame third party applications for leaking this data. This might be the case, but it is not enough to take them off the hook, especially given that their product is mostly about confidence. There are more and better instant-messaging apps out there, and whoever uses Snapchat uses it exactly so such events do not happen, whatever the excuse is.

I have no idea what exactly happened, if at all, but if a third party app got to access Snapchat data, then this Snapchat data was either

• obtained by the third-party app on the user device, or

• obtained by the third party app by impersonating the legitimate Snapchat app against the Snapchat server.

On a typical (i.e., un-rooted) Android or iOS device, apps can store their data so it is not readily available to other, unauthorized, apps; it would have been careless to leave such photos behind for the asking. On the other hand, Snapchat were accused several months ago for improperly authenticating their clients by the server, allowing easy impersonation of Snapchat client apps. I was quoted in USA Today yesterday addressing the need to properly authenticate clients.

Lastly I will add that there is also the possibility that no breach has ever occurred, and that the entire image dump is a hoax. Time will tell.

It has been a while since the announcement of the demise of TrueCrypt (which I reported), and an equivalent replacement for all those people who rely on it is not yet evident. TrueCrypt did not revive yet, but the situation is not time-wise critical as it may have seemed. There are a few options, for the time being.