Writing software for a malicious world
edA-qa mort-ora-y May 30 '17
How do we write software that survives in a world of malware? Is it just a matter of writing safer code or do some of our core assumptions need to be modified? Will we, as users, have to change the way we use our computer? Unfortunately, in the realm of security, there is lots of uncertainty. There are only two things we know for sure: our data is valuable, and we're not doing a good job of keeping the bad guys away.
Everything is valuable
Security measures are often weighed against the value of the data they protect. The more valuable something is, the more effort is justified in protecting it. We buy a safe for our passport, yet leave our books on a shelf. We put our money in the bank but put our socks in a drawer. In the offline world, we're relatively good at defending our valuables or at least understanding their worth.
We're still struggling in the online world though. We underestimate the value of intangible data and fail to foresee how we can be exploited.
The taking of an email and password to a social media site can be ruinous. An author's new book, a student's thesis, or a band's new song can be ransomed back to their owner. The history of a user's Facebook postings can be used to manipulate their emotions.
Malefactors are ever finding more creative ways to exploit small caches of data. And they're always being given new ways to access it.
Consider the issue of scale. Much of our core software is installed on billions of devices. Virtually all devices use the reference library for loading PNG images. Vulnerabilities in this code, which have been numerous, can affect everyone. A simple fad app, of no real interest, suddenly becomes installed on millions of devices. The theft of millions of emails from one service can be used to attack others, or even used to affect policy change with mass identity fraud.
Minor security breaches turn into major raptures when applied to millions of people. Uninteresting data becomes extremely seductive when captured in bulk.
As our world becomes increasingly connected, the abuse becomes ever more likely. As developers, we have to stop regarding things as apps, devices, and protocols. These are all gateways to a person's life -- something we should handle with utmost care.
The problem of a high-fence
Our first reaction to any vulnerability is to repair the breach. While necessary, this does little in the long-term fight against the attackers. They'll find a new hole. They always do.
We need to assume that somebody has broken through the first line of defences, perhaps even the second line. Pretend that a malicious worm is ever present in our computer systems. What do we do?
Simple conveniences are our downfall here. We enjoy that an increasing number of devices can talk to each other. We prefer not having to enter passwords to open a document or send an email. We consider it essential that our messaging apps can share contact information. We like watching movies, or playing games, at the click of a button.
How much of this convenience do we have to give up to have a secure system? The answer is unfortunately not zero. At some point, we, as users, must face the reality that our computing experience will need to change in the name of safety.
What do we do?
The big question is how we get from where we are now to a safer place. There are countless things that developers can do to improve security, but who is going to invest the resources? Why even bother when our competitors get only a slap on the wrist for mass data breaches.
What does a safer computer experience even look like? It's difficult to impose change on users as they frequently balk at any inconvenience. Are our current operating systems even capable of reaching the security we need?
In this web of uncertainty one things remains clear: we must assume the attackers are always there. We need to treat our software as the vehicles of people's lives and strive to provide those people safe voyage.
This week I want to talk about something that I have used for a excuse quite a few times. Before I finally started getting a schedule going. And that is saying the excuse I don’t have time to learn blank.