Deeply Insecure

It takes 20 years to build a reputation and a few minutes of cyber-incident to ruin it.
― Stephane Nappo

This series explores the common, but painful, issue of companies that have lost control over Engineering. In the previous post, I introduced an example project that collapsed under its own weight (or at least, the weight of real user data). In this post, we’ll introduce our final example – let’s look inside our last natural disaster…

The Insecure Application

Very frequently, the news trumpets a story about a website or application that has been hacked, often resulting in the theft of user data such as credit card numbers or health information. The app or website is often a mature one and everyone involved is surprised at the oversight. Let’s look at a classic example…

The Engineering team had been working hard to get the new self-service application working on the web, as well as on mobile devices. They spent a lot of time on the User Experience (UX) design and choosing various “responsive design” models. After weeks of debate, they settled on Google’s Material Design model and implemented it using a framework called Polymer. The application worked great on all devices and was a work of art. The team was tremendously proud of their creation, but the focus on the visual aspects of the application left little time for less exciting pursuits like how to store the user data. The team decided to use a modern database called MongoDB which was easy for them to set up and didn’t require any special database knowledge. The young engineers, who didn’t know anything about old-school relational databases and SQL, were delighted about the ease-of-use of the new database.

Late in the project, the team realized that they needed to find a cloud hosting provider that could host the system. They looked into the industry leading hosting provider and found the costs a little pricey [1].  They chose a cheaper alternative that was popular with Developers because they offered free developer accounts.

A few days after the system went live, the company started to get complaints that accounts were being accessed without their users’ knowledge. Upon further investigation, it became clear that someone had accessed the database and its data, which included credit card information. The company didn’t quite know the extent of the breach, but it became clear that they had a big problem on their hands.

It turned out that one of the Engineers had posted a file on a popular Developer site to solicit help getting the system running at the bargain cloud hosting site. Unfortunately, the login credentials were stored in the uploaded code. On top of that, further analysis uncovered that the database was put into production with the default Administrator user password. The system was ripe for pillaging by any semi-skilled hacker and the only miracle was that it took as long as a few days.

Suffice it to say that the application and the company both took a severe reputational hit – one from which it took them years to recover.

What went wrong?

In this project, the team was fixated on making a beautiful application and paid for it by having a security breach. One might chalk this up to bad luck or a failure of people outside the Engineering team (such as the Compliance or Information Security teams). It seems to have had nothing to do with missed customer requirements.

On closer inspection, however, it’s not the case at all. Customers have an implied requirement (and a really important one) which is this: “Don’t expose the data I put into your system. If I think you would, I will never use your system.” This should have been part of the documented user requirements (the same “Non-Functional Requirements” we discussed in the last post). This is shown in a modified version of the Customer Membrane:

Because security was such a fundamental user expectation, the Engineering team failed the user by focusing only on the beauty of the system. I hope this example and the three prior ones have been helpful to better understand the Flow model, the Order of Operations and the Customer Membrane. Please add your comments below.

In the next post, I’ll cover some common objections, as well as showing a completely different way of arriving at the same conclusion.

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] When I say “pricey”, they were thinking of it as if they had to pay for it themselves. In fact, the difference in price from the industry leader to cheaper providers was not a material amount to the company. We often get confused as Engineers about money because we assess things based on what we consider personally affordable.