Security/Privacy Personnel, should they be the same?

-->

I have been on the peripheral of the discussion about Privacy and Security for awhile. The debate is concerning how Privacy personnel are not familiar with IT security process. And I believe its time to take the bull by the tail and face the situation, so to speak.

My thesis is that there needs to be a concerted effort to develop  a liaison group involving people that feel comfortable in both areas of Privacy and IT Security. These people should understand how data is used within the IT, and what expectations Privacy places on the organization.

SO let’s explore

In the vast majority of enterprises, (those that have a IT department and also are concerned by privacy, as all companies should be) there are Privacy officers that deal solely in the Privacy realm (Privacy policy, governance etc) and the IT personnel whose function it  is to enhance/maintain/deploy process to Secure the network assets from the 'bad guy'

But before we delve into this much further, let’s explore some of the foundations of these two organizations.

Privacy requirements come from various requirements, regulations, laws. They are formulated/created, either by gov't or professional organizations. Examples include: the PCI DSS, SOX, GLBA, PIPEDA,  EU Directive, to name but a few.

These regulations/laws, for the most part are drafted by lawyers, civil servants, professional committees. I transgress with a quick joke. What is a camel? A horse designed by a committee.
The point is that, as written, these regulations are not written for the 'common man'.  They deal with the legal aspects of privacy and as such, written in 'legalize'. So to be able to interpret them, create processes to address them, and ensure compliance with the same, it requires individuals that can understand those same rules. That is, one with expertise in the legal and/or regulator profession.

Security comes from the technical world, the idea of what kind of security appliances are needed to monitor/secure the systems/network/infrastructure that are in place within the organization. The understanding of networking protocols, threats and vulnerabilities etc. needs someone who understands the technical complicated the Security realm

So far so good.

We also understand that to have Privacy, one must have Security, or otherwise the organization’s public reputation, never mind its ability to function under gov't rules  and industry regulation oversight may be in jeopardy. (IE data breaches etc).

However, how many Privacy officers know anything about a 'DMZ' or DLP appliance (to name but two Technical Security phases/gobbledygook). That is the Security guy’s responsibility, right?

How many security personnel understand the ramifications of a stolen laptop with an encrypted disk, with PII from Customers in the US, or if the PII is from those customers that are located within the EU. That is the privacy department issue?

So that is the dilemma. Each department’s needs to 'use' the other’s expertise. But is there is no common language? One group doesn't know what it does not know and the other assumes that everything is addressed. This scenario is a problem waiting to happen.

So let’s take an example. But please note that the following example is only being used to highlight my point. It is an over simplification of the issues.

A new network is being developed to support an application that is being rolled out shortly. This application contains PII/PHI information. In one of the meetings the CPO makes it clear that this type of information needs to be protected/secured.  The Security guys go to the back room and incant some magic spells over a rack of computers/servers (sorry I could not help myself) and POOF, out comes a Security policy/procedure etc. plan for the roll out.

The plan contains the proper role based security rules(RBAC), checks, logs etc. The Security guys go out for a drink to celebrate the culmination of designing a 'fool proof' Security envelope (as  if there was such a thing).

The Privacy person figures out that the proposed process meets the needs and regulations and goes home with a smile on his/her face. The only people who are authorized to see the information will have the ability to view the PII/PHI info.

However, did anyone look at how support is going to done for this application? The Privacy professional is not a techie and does not know what the 'normal' infrastructure for support/maintenance development for an application is. And why should he/she? Right?


WRONG

The CPO has no idea that during the development and support phases of the project, that copies of the real data may be created to provide a more realistic test bed  for QA/ regression testing.(see my previous blog entry for a  further discussion concerning this issue).

Did anyone look at the possibility that there may be data leakage within the test/regression system? (PII info that can be emailed in the clear from a developer workstation)?  Did the person responsible for Privacy understand the need for a possible Security hardware deployment within the test environment to prevent data leakage. And where should that hardware be deployed?  How do third parties access the data for testing? Should they be able to see the test (or Production data)? Should this be considered with a BCP (business contingency planning) document?

The people responsible for Security understand the basic Security 'triad' (CIA. Confidentiality, Integrity and Availability) and have created a process that addresses these requirements. In this case the Security personnel, and may be the network administrator, have designed a comprehensive plan to secure the network where the new application will live on.

But what do they understand about issues like: if a disk drive goes missing, even if it is encrypted, they may still need to notify gov't authorities (EU directive)? And this must be detailed in any contingency planning.

Do they know that they need to talk to the Privacy department to look at how test data is used and abused?

The above mentioned questions are rather over simplified. And of course during the normal working day, the Security department and the Privacy department would talk to each other. BUT

The old adage is very relevant here. 'I don't know what I don't know' or in the case of the Security personnel they don’t know enough of the Privacy realm to make sure everything is addressed. And the Privacy officer does not know how the data is used, to the point that she/he would not know to look into areas that are not obvious IE Test Bed, Third party issues etc..

So what is the answer? Cross train personnel. (Easier said then done).

Have the security department take a course like the CIPP, offered by the International Association of Privacy Professionals. This will allow for the same individuals some insight into the issues pertaining to privacy.
 
Have the Privacy personnel take a certification course like the SECURITY+ offered by CompTIA. However this may be more problematic because there is an assumption that the person taking this course (or one that is similar) has some basic knowledge in networking and IT in general.

Failing that, Have the people in the CPO office at least try to get the basis of Security down, so the next time the two groups meet they can at least talk a common language. And this would help in reducing the chance of something being missed, and projects coming in on time.

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.

Stakeholder/Privacy/Security Oh My

 


To continue with the theme I presented last time in which I discussed the differences between privacy (first pillar) and security (second pillar), I want to add a third pillar, that of the stakeholder. 

It seems obvious that he/she should also be included in any discussion along these lines. And yet stakeholders can only add complexity to the equation.  But before I begin, here are a couple of notes. I received a number of comments concerning the previous post. Some people commented about the fact that any discussion should include other interested groups as well. And as you will see, that is exactly what I will be doing here.   Yet I would be remiss unless I addressed another issue that was also brought up. 

What I 'd like to do, and only you, the reader, will be able to determine if I am successful, is to highlight the 'human' factor in this equation. As we move more and more to depending on, exploring, and exploiting the technology we use/rely on, we have had to develop tools to manage and control the reliance on the same technology. We have tools to check the code for security holes. We have tools to make sure we develop compliance processes. We have tools to help the auditors to verify systems, etc. 

Yet the one aspect that is forgotten in this mix is the human factor. He/she is the coder, the report writer, the auditor who verifies the results. etc. No system is fool proof and no human is perfect, except you the reader.   So why bring this up? I do so because some of the comments I received include the following: 'a security/privacy system that is put in place will address the wide divide between humans and technology/compliance'.

In response to this I say that tools are important, but we must realize that the tools are not the entire solution to this quandary. We need to understand entire eco system so we can successfully address the issues of Security, Privacy, Regulation, and Compliance. That being both the technology we use, and the tools we use to control/enhance it. 

So let's begin My objective in the previous blog was to highlight some of the inherent issues that prevail within the privacy/security domain. Here I want to explore the added complexity by adding the involvement of the stakeholder to this process.  Let define some terms. A stakeholder is the 'outsider'. The person who ultimately gains from the process being discussed. For a lack of a better way of definition, the owner/holder of the data in question. This can be a VP of the product line, the director of the stores, the sales manager etc. He/she is the one who can say, without question, 'the buck stops here". 

Generally speaking he just wants good end results. Most stakeholders see the added cost of implementing a well defined privacy policy/practice in place as an overhead that needs to be controlled. 

They want to make sure their data is safe but ask them if they think the added cost of security systems in place is, for example, worthwhile to prevent internal development personnel from having access to the real data, they would balk. (Note this is a generic over simplified statement, but I use it to make a point). To address this issue I point to a number of organizations that rely on non disclosure agreements (NDA)  the only protection to address the above mentioned issue. This is 'cheap' to implement and easy to maintain. Yet I hope you, the reader, understands that this solution is like having your teenager promise they will clean up the room. A good idea but without any other incentive probably doomed to failure.

The problem here is that we all have different views on the same situation. We come with different experiences, responsibilities, education. While the stakeholder is ultimately the person responsible (For further info along these lines read about the SOX act that was passed in the US), she/he may not know how a truly good governance regulation compliance (GRC) process is created. And in fact he might not even know why the company needs one in the first place.

So taking the analogy I used in my previous post(how security personnel and privacy professionals look at a 'square' and see it differently), the stakeholder is the owner of the 'square'. He holds the square but has no idea how it is constructed but only knows how the square is used, IE. not how the WEB application works. Only that a customer can sign in and order the widget.  So what can we to do? The answer I suggest is fairly simple. Education. 

The privacy officer must educate the interested parties. These parties include the stakeholders, the IT personnel Given that there is a privacy officer already in place means that the first step has been taken. The people who work on security need to educate everyone on what needs to done and what it takes to get it done.

The security personnel need to interpret the requirements and educate the parties on how this is implemented. Why does it extend the software development cycle. So in other words by educating the parties they can justify the time and materials that will be needed to produce eco systems that achieve the goals set out by all the interested parties within a manageable framework.

So to help the reader, I am suggesting a couple of different resources that can be used to help. 

1) A short piece on how to explain HIPAA to the layman (Stakeholder). It also provides some additional reading that may be of interest.

http://www.ehow.com/info_7778811_laymans-guide-hipaa-compliance.html

2) A very interesting website that targets NON lawyers with information concerning privacy. There are a lot of very good additional links that can be of some help. Please note that this site deals mostly with US laws.

http://www.eprivacy.com/lectures/toc.html#toc

3) Another good resource for educational purpose is the Electronic Privacy Information Center website. Once again, mostly US information.

http://epic.org/privacy/

4) On the consumer side of the debate, a list of resources can be found at 

http://www.privacyrightsnow.com/affiliates.htm

5) And finally, two studies that come out yearly. 

       A) One is the Telus security group yearly that looks at the state of Canadian companies security. It has 5 recommendations as well as pointers on how to try to make security more prevalent in the workplace. Registration is required.

http://promo.telus.com/securitystudy/

        B) The other one is the Verizon security's 2013 Data Breach Investigation Report. This report is a yearly report that encompasses expertise and information from various international organizations responsible for the reporting and investigation of data breaches. If you do not look at any  other resources listed here, then this is the one to read.

http://www.verizonenterprise.com/DBIR/2013/insider/

Please note the opinion of the individual authors/websites are their own, and I do not advocate, agree or dis-agree with the opinion expressed.

And this is just a sample of various resources that are available to help with the issues described above. But ultimately it is up to the individual to make sure they adhere to the best practices within their industry and Country.

Till next time