Privacy for IT, Security for PO, Privacy by Design PdB.

So far I have tried to tackle how different professionals look at privacy differently and how stakeholders are an important piece of the pie

What I am going to try to address within this post is how technical ideas affect privacy and security, as well.

I will also attempt to provide some guidance concerning some of the issues I will discuss here.

Please  note, I have no relationships with any of the companies that I mention here, or any in any other posts that I have written. Also, it is up to the reader to do their own due diligence.

Now, the reader may have some level of knowledge of the 'tecky' stuff but I will try not to make any assumptions. What I want to do is to highlight some aspects, describe them for those who may not be as technically inclined, and provide some resources where more research can be done.

Some lay people use the words security and privacy interchangeable. While security is needed to maintain privacy, it can mean other things as well. For example, physical security of a public facing office (banks, insurance agents offices etc) is generally accepted that it need to be addressed,  to protect the employees (non privacy issue) and protect the companies customers from data breaches, which is a privacy concern.

What I am going to deal with here is security that is needed to protect Personal Identifiable Information (PII)

So lets get started.

Security

Hopefully, when a developer starts coding for a new application, or making enhancements to an existing application, he/she will know how to code to prevent security holes within the code. But as we all know, we are all human.

SO what can we do?

A new type of software is emerging that can help developers to highlight what they should be coding. This is in a form of questions/guidance that can be based on questions/queries from a knowledge base. The objective is to build into the design document (this is the document that concern how the programs work together and coded, given the requirements of the application being worked on). This would then place into the design document specifications of the required defences that need to be incorporated within the code.

The two software products that I am aware that falls within this category are:

1) SD Elements (http://www.sdelements.com)

2) Security Innovations (https://www.securityinnovation.com)

Both have there strength and weaknesses. They also tackle this aspect of security coding in a very different way.

As an analogy, let us use the example of your car (or your friends, car if you don't have one <S>), or boat, bike etc. Which is cheaper? Is it changing your oil every x KM/Miles, or waiting for the engine to seize when the oil can no longer do its job?

On average it costs about $4,000 to fix a vulnerability in an application (SD Elements). According to White Hat Security (https://www.whitehatsec.com/resource/stats.html) on average, there are 56 vulnerabilities per website (2012). So let's do some math, Shall we?

It will cost $4,000 times 56 on average to fix all the problems with security on a public facing websites, for a total of, and average of $224,000.

You can close your mouth now.

And to top it all off 85% of all websites White Hat tested had one vulnerability. And to make matters worse, it took, on average, 193 days from the date the issue was detected until it was resolved. Never mind that 61% of the White Hat tested websites that had vulnerabilities were never fixed in the first place.

In other words, the best practices, as well as the ROI,  demand that we need to try to nip this issue in the bud. It follows that company's policy should have security requirements and processes be part of the design phase of any project.

Privacy

At this point let me highlight a series of documents, white papers that have been produced by the Information & Privacy Commissioner of Ontario Canada. (IPCO) Dr Ann Cavoukian PH. D.

The premise advocated by the IPCO is that of Privacy by Design (PbD). It goes in to much more depth that is beyond the scope of this blog but I encourage you to head over there and explore.

There are two sides to the equation. Security for the professional IT people and Privacy for the legal 'minds'. How in essence they are complementary and how they must exists together.

As a note here, one of the white papers on the sir 'Privacy and Security by Design: A convergence of Paradigms' talks about what I am writing about here. It was released in Jan 2012.

I do have to make an admission to the reader. I started writing  these blogs, and this one in particular, before I had any notion of this white paper's existence. When i did discover the PbD white papers i realized the concepts, topics, and themes were similar to the issues I have explored in my blogs,

I will continue along this road next time. I will highlight examples of different forms of testing for security and ideas of privacy.