Tag Archives: Security

The Cult of Security/Privacy By Design

I have been reading a lot of privacy literature lately and the more I read, the more I got frustrated with the “Privacy by Design” motto. It somehow was not right, and made me realise that “Security by Design” motto is similarly hyped and is just as misguided. Let me explain.

Why security/privacy wasn’t baked in at the start

First of all, the basics: “X by Design” means that security/privacy is baked into the product from the inception and design through to implementation,  and all the way to operation. This of course sounds great, and one can easily see that trying to retroactively implement security or privacy features/requirements into an already existing product is a lot harder than baking it in all from the start. Where I think this starts to fall apart is that often, the reason for something being only “an afterthought” is not that it wasn’t actually considered while e.g. conceptualizing the product. It’s because it was considered but either:

  1. There weren’t any people available who could help i.e. the security/privacy personnel were busy, expensive or too complicated to acquire/hire/consult or
  2. It wasn’t considered important to involve the right people/team because the project/product was supposed to be small/unimportant and security/privacy-irrelevant but over time it grew to be important/large

In other words, it was either resource constraints or legitimate business reason not to spend resources on something (that was meant to be) small/irrelevant.

Reminiscing of the past

What I see in a lot of these “X by Design” discussions is a set of technical people reminiscing about how awesome it would have been if e.g. Google built their search engine in 1998 with security/privacy in mind. Yes, it would have been, but the engineers writing the code had no idea if it would take off and had neither the time nor the money to spend on expensive consultants and long consultation periods to bake security/privacy in. The same can be said of many other startups’ products and of most projects in large companies that grow to become products of their own.

If security and privacy engineers would have to be involved in all smaller projects then innovation would seriously suffer, because there are simply too few of us and we would  take too long to take a sufficiently good look at everything (that might not take off anyway). So, since we cannot be involved at the beginning of every project, the best we can hope for is to fix it afterwards — there is no point in reminiscing in how awesome it would have been if we were there when Twitter started in 2006. We weren’t there, it now took off and they are offering value to their customers, bringing in revenue which they are (hopefully) using to fix their security/privacy issues. I think it’s too optimistic to assume they could have afforded the delay-to-market and the price attached to doing it “right” from the start. Most probably, they couldn’t.

Living in the present

All in all, I think a most of the “X by Design” is wishful thinking with some sermons attached to it, telling long tales of how things could have been so much better, had the right security/privacy people been consulted. What these tales often forget to tell is that when the idea was born, and the project/product was created, the situation was not even remotely amenable to such an intervention. Hence, I think it’s time to let go for the most part — we should concentrate on doing what needs to be done. We should make sure we have solid processes and good, flexible patterns for fixing already existing products.

IT Security Differently

Compliance and regulations are one way to achieve IT security. If one looks at industries that have been around for a very long time, and have very high stakes, for example commercial airline travel, mining, oil&gas, etc., one can find compliance and regulations everywhere. It’s how safety is managed in these environments. I have always been fascinated with safety incidents and read a lot of reports around them — these are almost always free to read and very detailed, unlike IT security incident reports. See for example the now very famous Challenger Accident Report (“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”) or the similarly famous, and more recent AF-447 accident report. These are fascinating reads and if you are willing to read between the lines, they all talk about systems issues — not a single person making a single mistake.
Continue reading

Testing and pentesting, a road to effectiveness

I have been involved in computer security and security testing for a while and I think it’s time to talk about some aspects of it that get ignored, mostly for the worse. Let me just get this out of the way: security testing (or pentesting, if you like) and testing are very closely related.

The Testing Pyramid

What’s really good about security testing being so close to testing is that you can apply the standard, well-know and widely used techniques from testing to the relatively new field of security testing. First of all, this chart:

Continue reading

On Testing and Security Engineering

I have been working in a large organization for quite a while now where I have seen a lot of testing going on. As an information security engineer, I naturally aligned more with testing and indeed, information security assurance does align well with testing: It’s done on a continuous basis, its results usually mean work for developers, operations people, system architects, etc. and not caring about it is equivalent to accepting unknown risks. Since I have been working in an environment where testing was paramount, I have been digging more and more into the testing literature.

Continue reading

Setting up encrypted mail in Chrome and Gmail

The use of Gmail is now ubiquitous. Unfortunately, it’s easy to read email in transit and some national governments abuse their power to read email in transit. I have always been using PGP to encrypt email, and today I thought I’d put down how to communicate with me, or with your friends, using signed and encrypted mail. I think the biggest reason email encryption is not being used is because it’s hard to set up. So, here is a simple, step-by-step tutorial that is easy to follow.

Installing and creating a key

  1. Install Mailvelope . Click “add to chrome”, pop-up appears, click “add”
  2. little padlock icon appears on the top right of your Chrome
  3. Click little padlock icon, click “Options”
  4. At the bottom, click “Generate key”
  5. Fill in Name (you can put fictitious name, it’s good!), Email (the email you want to use, e.g. Jon.Doe@gmail.com), put in a password that you will remember. This password is never sent anywhere. It’s used so that when you want to read email that is encrypted to you, the encryption keys can be accessed.
  6. Click submit, wait for the generation to finish.
  7. Setup is done!

Continue reading