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

Privacy and Security sometimes don't talk the same language.

 

In this blog, which may seem as a little rambling of sorts, I will try to first explain where I see the disjointedness between Security (where the IT people see it) and Privacy (where the Audit Privacy officers see it). I will then try to guide the reader to various resources on the web to offer help.

This will allow the reader, no matter which side of the fence they sit on, to at least understand the other side and understand what they are talking about. Some of these resources quoted below will be targeted for the IT techies, and the others for the Privacy gurus. By putting  them in one central location I hope to bring together, in some small part, the two groups so they can better understand each other.

So let's begin.


Privacy. According to the Webster online Dictionary: 'freedom from unauthorized intrusion <one's right to privacy> '

Security. According to the Webster online Dictionary: 'measures taken to guard against espionage or sabotage, crime, attack, or escape '


An explanation. Security is the process that is put in place to protect the Privacy of the information, whether it is Personnel Identifiable Information (PII), company's intellectual property etc.

We have a problem. The 'WE' in the previous sentence belongs to the IT personnel as well as  the Privacy Officers of an organization. Many times the Computer guys speaks in 'techy talk' (subroutines, C#, apache configuration etc) and the Compliance personnel talk in legalese (jurisprudence, PIPEDA, Opt in, Office of the Privacy Commissioner etc). So, it is no wonder that many organizations seem to have a disconnect between the two.

To address the need for privacy and security in our day to day computer lives, some measures were/are developed by people who may look at a issue  but see it in two different ways.

As an analogy, let's take a look at a square drawn on a piece of paper. The IT people see it as four lines connected at the corners, and the Privacy people see it as four corners connect by some lines. (I hope you get my meaning in this analogy I just presented). Both are right, but both don't see the entire picture either. And thus, this illustrates the issues that many organizations face.

Yes this disconnect is evolving. There are now certification/training sessions for people who are responsible for privacy policies and are not  technical (for more info go to https://www.privacyassociation.org/) but try to bridge the gap (CIPP/IT) And there is various integrated development environment (IDE)  to try to ensure that the code written can be tested for security (IE PENetration testing etc.) But as much as these two groups are trying to work and understand each other there can be some areas where they are miles apart.

If you have followed this series from the beginning, you would have remembered at least one very common example where there is a security/privacy hole big enough to drive a tractor trailer through. (see my previous blogs for more information) And I would bet my two weeks of pay(jar of peanuts) that most Compliance/office of privacy departments have yet to investigate the arena. This is a clear example where the lack of understanding of one department operations by another can lead to some very ominous problems.

Privacy Officials, for the most part do not understand the nuisances of coding, testing , developing applications etc. for the current market place. They do know the laws of the land, and do create compliance rules that all have to abide by.

IT professionals, again for the most part, do not understand the rules that governs Privacy. What is a Opt in or Opt out option? Why must Credit card numbers  be treated under some externally developed standards? What are those standards? (Well, maybe they do, but this is used only as a simplistic example). IT professionals know how to create a automated process to sell, bill, retrieve the widgets that the company makes, Yet the problem is that IT people (the techies) more often then not are not involved, nor understand the Privacy Realm.

Education on both sides is the only real answer. So in the following I will try to give some resources to the reader with some comments that may help understand the other side.

Please note I do not have any financial relationships with the organizations listed below. Nor do I recommend or agree with the statements contained within, though I have found these sites to contain valuable information. Whether you are a techie or privacy person I strongly suggest you take a look at all these resources to better understand the world we have to work in, so to speak.

The first resource that you may or may not be aware is the Privacy Rights Clearing House. (https://www.privacyrights.org/). A very useful web site, where among other items, is a list of all publicly disclosed data breaches since 2005. In fact according to the web site, as of when I started writing this blog, 607,472,154 DATA RECORDS WERE BREACHED. The number of breaches were 3,678 DATA BREACHES made public since 2005.

The type of breaches  that you will find there include 'dumpster diving', laptop/hard drive being misplaced, and SQL injection to name but three. Chances are that you or someone you know was a victim of at least one, if not more, of a data breach. In fact if you do the math, the number of records is about twice the entire population of the US. And this site is very light on breaches outside of the US.

The next resource  is Ponemon Institute (http://www.ponemon.org/). This site has  a wealth of research on the  who and how of privacy. Its stated purpose is 'to enable organizations in both the private and public sectors to have a clearer understanding of the trends in practices, perceptions and potential threats that will affect the collection, management and safeguarding of personal and confidential information about individuals and organizations.'


The next site I would like to point the readers to is the Verizon Security Blog. (http://securityblog.verizonbusiness.com). Basically a week by week analysis of what security issues are out there. Also, they have teamed up with various
International Law Enforcement organizations to issue a yearly report investigating the causes of data breaches. And the information would be a surprise to some. For example

97%  OF ATTACKS ARE AVOIDABLE BY SIMPLE OR INTERMEDIATE
CONTROL.

The latest report on this web site is a review of 2012, but the updated 2013 report is expected out very shortly.

Next is an organization called International Association of Privacy Professionals (https://www.privacyassociation.org).

I happen to have two certifications from them. They have two items I would recommend the reader to investigate. One is a blog they call Privacy Perspective, an interesting blog where various people talk about issues of the day. The other item  is their 'DASHBOARD' (They have one for US, Canada, Europe and ANZ). They gleam information from various sources and present them in a concise 'executive' brief type.


The above resources are just a tip of the iceberg. The problem with Privacy professionals and IT gurus understanding each other and thus being able to frame the issues/requirements/concerns, etc taking into account  each other's prospective is not something that can be done within a simple blog. But I hope that it will open some people's minds on what the issues are and some resources that will bridge the gap. Or at least have each side gain a better understanding of the other.

Next blog will continue along these same lines.

However the next blog will be in two weeks time.

Till then, if you have any comments or feel like you want to touch base, drop me a line at rgalambos@gmail.com

Data Privacy Project road map part Deux

-->

 

 Before we get started, let’s review some critical items that we covered last time.

The analysis phase of any Test Data Privacy Project (as all other IT projects) is the lynch pin, where you make or break the project. So to summarize this step you need the following:

1)    Identify the meta data of the application(s) in question

2)    ‘Marry” the meta data to the data stores (the field in the meta data that corresponds to underlying  table/file)

3)    Inspect the potential PII Fields/data to see if they are actual fields that need masking. A sample would be nice to show the SME, if there are any questions about the field contents.

Then we have the design step. The following is the continuation of the discussion from my pervious blog entry.

It is the SME who is the critical member of the project team in this phase. He/she will be asked questions like, how do these fields that were identified in the previous step as PII, interact with each other?  A simple example: is there an edit to make sure the city zip/postal code combination is valid?. The rules should be consistent throughout the environment. IE, if you age the birthday in one file in a certain way, you will need to age the birthday the same way in any other data store you have.

Now before we move on, I should address a question that should be brought up at this time. Are you going to need to sub-set the data while masking it? (see my blog Testing and Data Privacy, is there an issue (final post or is it)?  After you answer that question, the next one is HOW? (And as I mentioned before, my expectation is that you will answer YES to this question). Are you going to want to take a random set of customers (as an example) and mask all the related records of those customers? Or has the SME given you a list of branches that will be used for testing? So you need to also mask the customers of those branches, including the addresses of the customers of those chosen branches,  the SSN/SIN/Tax ID for those customers, and extract only those products that the target branches have to sell etc.  What this all means is that you will need to design the extract process at the same time as the masking process. This can be a large hurtle to be overcome, BUT the end results will more then make up for the effort. (this will be a subject of another blog entry in the future)

WARNING WARNING WARNING

I’ve got your attention, I hope. What I need to highlight here is that the sub-setting of data and the obfuscation of the data needs to be done at the same time. Failure to do this, may mean an increase chance of a data breach.  Now back to your regular scheduled program.

The actual masking rules do not only depend on the requirements, as defined by the SME and/or legal/privacy personnel (see above), but also is driven by the chosen tool set that you have. For example, if the toolset you are using, does not use >128 bit Strong encryption, should you still use that technique for masking? If you need to be able to reverse the obfuscation (if there is a legitimate reason) then that may restrict what kind of rules/code that can be used to mask the data in the first place.

Another aspect that needs to be considered, but many times forgotten, is how will the audit requirements be satisfied for this project? And make no mistake about it, there will be a need for audit reporting for this process. Why do I say that? It is because the masking process is most likely being driven by either regulatory requirements, or best practices. And in either case some sort of ‘proof of the pudding’ will be required. This also needs to be taken into account within the project.

Once the design phase is finished, we will then move on to the coding.  There is not much I can say here :

1)    Depending on the chosen toolset you will be using, it will indicate how one will code the rules, and the limitation of those same rules

2)    Try to reuse as much of the masking rules as you can. There is no need to reinvent the wheel, if one can help oneself. Some tolls allow for one rule to be applied to many different data sources. And for obvious reasons that is something I encourage you to do as much as possible

Next is the implementation phase. This should be the easiest step. I mean, isn’t this just another IT project? And don’t you implement IT projects ‘all the time’?  It should follow the same process, right?

Maybe. But to see if it is easy, one needs to ask a series of questions first. Some examples of questions are as follows;

1)             How often will the obfuscation needs to be run?

2)             Who is responsible for the running of the process? Will it be production support, or will the users themselves run the series of jobs in question?

3)             Will there be a need to have user input before each run. (IE. Will the data sub-setting requirements change)

4)             How will change management be taken care of? In other words, if a file/field is changed or added, how will the masking process be updated? Who will do it? And how do you ensure nothing falls between the cracks.

5)             Make sure that the Audit reporting is implemented. Is it on request, or will some sort of reporting need to be done every time? Will the reports need to be secured?

And in all these steps, you should make sure you document EVERYTHING, in a concise and accurate manner. Only with this being done can one try to assure a successful ongoing, maintainable process. I would suggest setting up a Lotus/Excel worksheet to help with this.

The intention of this blog is not to replace due diligence. Each IT environment is different, with its unique challenges. My sole intention is to try to help the community to tackle this concern head on. Experience tells me that this is a big task, but does not have to be daunting.

As the many clients I have known can attest to, if one does this methodically, with foresight, one can achieve a successful conclusion.

If you have any questions about this or any other topic that I post, or you want me to explore some issue, drop me a line at rgalambos@gmail.com.

Till next time

Data Privacy Project road map

 


 --> As I am sure most people agree, and have experienced as well, the majority of projects either come in over budget, late, or even worse, they never finish at all. A critical project like Data Privacy is no exception. But then again failure is not an option because of the consequences.

Before I begin, lets talk about privacy and the foundation of the project.

Politics. Yes I said it. And I am not talking about the govt type of politics, but the ones that all organizations have.

The first step that needs to be addressed is to get upper management sponsorship for a Data Privacy project. This is critical for the success of the project. Someone has to make the decision to bite the bullet to start funding and make sure that all department heads understands that  is mandated from the top.

This proposed project is  cost centered. It will not generate any revenue. It wouldn't make the widget run faster, nor get more customers. So getting funding for these type of projects is harder to get. One needs to make sure that upper management understand the business need, the ROI etc..

The data in question can span many applications which means many different departments are involved. A number of application owners are the stake holders in a project of this sort. So unless there is  someone high up giving directions, most likely roadblocks may appear that could be insurmountable.

This can be very daunting. I suggest that you start with a pilot project, unless you are in a small IT shop. Ideally choose a relatively isolated application, if possible. Start small to be able to learn where the road blocks/pit falls are. It is easier to learn from a mistake now then  to tackle more then you can chew.

Who owns the data? Who will decide how  the data be scrubbed? How much data will be scrubbed? Who will maintain the process once it is developed? These  will be questions that need asking.

Who will lead the project? What resources will be brought to bear on the project? Will the SME of the applications be used as reference, or will they be actually part of the project team?

Who will maintain the process after it is complete?

Ok, we can start, Right? Well not exactly. The next step is to determine  what 'methodology'/process/expertise will be used. Are you going to develop something in house? Or are you going to purchase something? The company may already have the tools  in place  that are capable to obfuscate data. Then all you have to do you is to deploy them.

The next item is determining what exactly needs masking/scrubbing. There are a lot of factors that need consideration. Some examples are, but not limited to, the PCI DSS standard (ie. if you retain/use Credit card information). If you have EU customers/locations/presence then one must be sure to adhere to the EU Privacy Directive. Or if you operate in Canada then one must make sure the company abides by PIPEDA, and so on. Most likely the answer to these questions will come from your legal, privacy or audit departments. So consultation is in order.

So we now have all our ducks in a row.  Like most IT projects there are basically four steps for a successful project. They are: analysis, design, coding and implementation, each building on the previous success.

The most critical step, is as you can imagine,  is the analysis. In fact I would expect that at least 50% of the time that you spend on  the project will be in this first critical phase.

Analysis.  In this first step your objectives are:

1 ) Identify all the data stores that have Personnel Identifiable Information (PII).

2) Take all the meta data and scan them for tell tale signs that they contain PII, for example a field that is labeled 'ADDRESS'. That in itself is not enough just to find those fields so named. You will also need to marry the meta data to the actual data store (where the data resides. ie. DB, flat files etc). This should be enough, but trust me it isn't.

The after these two exercises are finished, one needs to actually look at the data and see, if that ADDRESS field is actually PII. It could be the address of your branch office in which case it would probably not be PII, and outside the scope of the project.

Then there are the data field labels that do not reflect what is stored. An example could be a field that is labeled 'NUMBER'. This could be a phone number, a reference number, or the number of times the customer has ordered from your company. You will need to inspect the files, that you have identified (see above)  and make sure you  have a list of all the data fields, and the data stores that need obfuscating.

This is time consuming to be sure. But if the analysis is not done completely and thoroughly then the project is doomed for problems further down the road.

The results of this phase are a list of files that contain PII, and the fields within those files that need to be worked on..

Design. In this step your objective is to design the various techniques needed to obfuscate the data.

Taking the information developed in the previous step, a systematic approach will prevail.

You need to categorize the various data items that were discovered. For example, all the names should be grouped together and then masked the same way.. They all need to be masked the same way to maintain consistency and interoperability between the different applications. IE you need to make sure that Robert that is scrubbed to Oliver in application A. Then, if Robert appears in application B, it will also be scrubbed to Oliver in that application. This is crucial to the long-term success of this process.

The SME needs to determine the business rules that are applicable to the various groups of data. Are there edits on addresses to make sure that the masked address is located in the specified city? The birthdays of customers are important to be maintained because of insurance rates etc?

The masking rules that are being created against the various data fields need to take all business logic into account. And then to add to the complexity of the situation. the project team may be also be mandated to sub-set the data while copying from the production system. (see one of my previous blogs with a short explanation of various forms of testing that are normally inherent within an IT department).

In the next post I will continue to explore the design stage and then delve into the next two stages of Privacy project.

and as always if you have any questions drop me a line at

rgalambos@gmail.com

Robert Galambos CIPP/C CIPP/IT