Daniel Dresner explores the fallout from the Ashley Maddison hack.

Whether or not the Ashley Madison incident is a technical hack or the work of an insider with too much access and an axe to grind, web site hacks are a daily occurrence. In fact we are probably becoming desensitised to the main gist of a headline unless a familiar brand appears in it. So over the last few weeks itchy thumbs have been found among the customers of Carphone Warehouse as well as Ashley Maddison. And when we look into the latter in particular, we find a potpourri of moral and ethical questions about responsibilities and rights. The debatable questions extend far beyond the technology…

• Are the bonds of trust to be universally observed in every society where monogamous marriage is the norm?
• If someone breaks those bonds are they fair game for all the repercussions society can throw at them?
• Are there limitations to those repercussions? Should we care if they ‘can’t face the music’ and take their own lives?
• Should infidelitors’ be protected, not for their sake but for the sake of the disruption to their families and friends?
• Should the puppeteers of emotions who entice people with free stuff (such as the opportunity to register) be allowed to prey further on those emotions and take advantage of despair to charge for deregistration?
• If the national laws do not match up to your moral agenda can you break other laws to strive for your morality to become the status quo?
• Should the designers of platform which allow the exfiltration of such information be held liable for their products?
• Are those who design the services obligated – we’re talking morals and ethics remember, not regulation – to authenticate the identity of their users.

Eight questions and only two question the morality of the technology. It’s that which I shall home in on. The idea that technology should not be created trustworthy is lamentable and probably counterintuitive to all but spies. There may be a place for a risky prototype to prove a concept. However, temptation to reach the market first and early is likely to persuade many that if surrounded – note ‘surrounded’ – by sufficient safeguards then that prototype can be version 1.0. It has been observed that part of the problem with today’s software is that it has attained a Frankenstein level of complexity by being built on supporting layers of reused and repurposed old software. Software which will almost doubtless have been created with good intentions, but with intentions based on functionality. One speaker at the annual Manchester BSides conference  spoke about a feature which must have had some good reason for being introduced – even though no one could suggest one – but its effect is to open a path for criminals to have the highest privileges on your system. Features are kings and queens. Non-functional requirements are the luxury of luck or a procurement officer who knew how to craft a requirements specification. Computer systems are not secure because of what controls are piled upon them; they are secure when they measure up to what is needed to mitigate risk.

Trust – like that handshake which clinched a deal – has entered into the lexicon of computer science. Research by the Trustworthy Software Initiative defines trustworthiness to be manifest in 5 non-functional attributes: availability, resilience, safety, reliability, and security. When the Anglican Church assigned a minister to observe ethics in computing, the incumbent reported software as ‘invisible, intangible, intolerant, indispensable, and totally amoral. Which makes it bloody dangerous.’ Software is like the most unfortunate kind of human being and yet we expect it to do human tasks. Like people’s behaviour, bad traits (or characteristics) written into the software are hard to change. And changing software brings its own risks: 17% of correction attempts fail. It’s rather better not to develop bad characteristics in the first place. So laudable coding clubs and Computing GCSE syllabus writers take note: instil the habits of trustworthy programming from the start, not as a later, corrective measure.

The characteristics of a piece of software must be considered at the time of its conception; they are software’s genome. Without them, we give these rarely deterministic routines a bad start in life. We expect people to act legally, morally, decently, ethically, and truthfully. Similarly, software must be created with five attributes: availability, resilience, safety, reliability, and security. Design in the good stuff and test out the defects.

The Ashley Madison affair leaves us with one more morally-agnostic lesson to learn: there is a big difference between deleting data and destroying data. The proliferation of data – master data, back-ups, personal ‘just-in-case’ copies, e-mail attachments, cut-and-paste extracts, and who-knows-where-in-the-cloud (a term I used for its popularity) – means that even using the delete function on a computer does not guarantee the erasure of that data. Let’s call it data destruction. Again, the term ‘trustworthy’ rears its head; the ubiquitous delete function will rarely – if ever – really do what you are asking it to. Time for everyone to consider their own inventory of the information they curate.

In conclusion, I reiterate I am not calling for the societal introspection of the Ashley Madison site’s purpose. My lament is that under the shadow of this human tragedy, the quality of software development and configuration work will be overlooked, endangering other people in the future. I’ll leave you with five actions to make systems safer:

1. Look at the risks to successful operation of what you want the system to do…make sure that the system can do it (possibly even whilst under attack).
2. Procure a trustworthy system that will be true to all its stakeholders. (And this isn’t just hardware and software…consider where people interact with it.)
3. Configure the system so that it will continue to be true to all its functional and non-functional requirements.
4. Keep the configuration of the system – from its core to its boundaries – up to date.
5. Manage the privileges of who has access to what. Monitor activity and don’t let anomalies go unchallenged or left without action.

In the words of a colleague…where IT governance is lacking, ‘people will die or go to jail’.