Robert's Law of security and technology progress

Robert's law of privacy & security.

"The number of advances in capabilities within the online world is proportional to the number of issues with privacy and security."

 A strong statement, some would gather, and something that would seem counterintuative. Would not technology improve security, or as some would say build a better mouse trap?

Let’s delve into this a little further.

We now have a number of cloud computing capabilities that improve the ability to share resources, DropBox, Google Drive, Dump Truck to name but three. These types of software/hardware allows us to share files among our peers within the 'Cloud', thus allowing a more seamless experience when trying to share presentations, school projects etc. Yet this year alone Drop Box (and I only use this as an example as some other cloud suppliers have had security concerns expressed about them as well) had a security issue. In a four(4) hour period, accounts were unlocked and accessible to the general public.

Let’s take another example.

Social media. It is in the forefront of most peoples minds right now. And, as we see, a lot of companies are embracing this new market place with vigor. It is seen, by some, to better connect or re-connect, with friends and family. I for one, keep in touch with relatives from Australia, Hungary and Michigan using a combination of Twitter, Facebook and LinkedIn. Companies are jumping on board as well,  seeing the opportunity to have another marketing vehicle in their arsenal,  providing enhanced customer service and differentiating themselves from the competition. Yet there have been a multitude of security and privacy issues with the social media suppliers. For example, there was the time a that a certain number of users  potentially exposed their personal identifiable information within Facebook. Twitter, another social media darling  had a number of issues concerning security as well.

And another

RFID = Radio Frequency IDentification.. We all use it. But what is it? It actually encompasses a lot of different devices and uses. They include the NEXIS card, issued by the US and Canadian governments to allow pre-screened passengers, speedier border crossings. It allows Jane Smith to tap her credit card on the gas pump reader to pay. it can be used to track merchandise in warehouses etc. Yet within a very short period of time after general deployment in the public arena security issues started to be asked/exploited in both the public as well as informed experts hands.

And finally within the last month (as of this is being written) the fingerprint recognition capability within the new iOS 7 had it’s security questioned. The new capability allows anyone with a new Iphone 5Sc  to buy songs etc., using their fingerprint, in the ITUNE store (more to follow I am sure). Yet within a very short period of time, concerns about the security of this capability surfaced.

So what does this all mean? Should we ban all new technology? While I am sure there maybe some people who would say yes (as there are still some people who believe the world is flat and Elvis is alive) that is not going to happen. If we would have banned technology then, no computers? Or if we waited and implemented the ban when transistors came about. or when the Arpnet/Internet was created, or when the WWW (world wide web) etc. where would we be now?

In reality as the human race continues to explore and innovate, technology will move forward.

So Am I advocating we just plow ahead full steam? Well.....

I think we need to recognize that with each innovation, invention etc the security privacy landscape changes. That when we embrace the new mouse trap, we should also realize that it brings with it potential security privacy issues that need to be addressed.

Let’s take the last example I used.  Apple introduced the new capability stating that Iphone 5S is an innovative way to simply and securely unlock your iPhone with just the touch of a finger. However, noticeably absent was any further discussion about the security component.  While I don't expect a detailed discussion, I do expect a phrase or two addressing the obvious concerns.

Why is it that security (and indirectly privacy) is such  an afterthought.  We introduce new ways to build a better mouse trap1 yet we do not look at what the implications for this new technology are and what changes need to be so it is implemented safely and securely. Companies jump on bandwagons all the time without fully engaging in a analysis of the various issues of concern. Apple introduces a finger scanner, yet a hack was published within the month. Banks introduced 'chip and pin' credit cards and then tried to deny any reimbursement for fraudulently used cards.

So what does this all mean? In all our dealings, whether it is building a new web site (Privacy by Design) or a new technology, we should be advocating Security by Design in what ever we do. It should not be an afterthought. We should expect that there will be issues and not wait for some smart hacker to point out the problems. We should take the bull by the tail and face the situation. Be proactive rather then reactive as we seem to be most of the time. If we do this, then we will hear less and less press releases on how some new technology was hacked and broken. And as a result, a fix had to be  developed and deployed. Never mind the PR issues that raise their head during this event.

FOOTNOTE

1 The actual saying goes like this 'If a man has good corn or wood, or boards, or pigs, to sell, or can make better chairs or knives, crucibles or church organs, than anybody else, you will find a broad hard-beaten road to his house, though it be in the woods' Ralph Waldo Emerson. I prefer the modern version for brevity, if for no other reason.

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.

Robert Galambos's Updated Resume

Robert Galambos Mobile: 416-876-2979 · Email: rgalambos@gmail.com
Career Profile: Over seventeen years of experience as presales engineer and consultant in the software industry, combining high-level sales and marketing knowledge with deep operational experience, technical savvy and cross-functional communication abilities. Extensive experience supporting sales initiatives, managing customer relationships, handling customer service calls and consultations, and maximizing client ROI on software solutions.
Areas of Strength
Data Privacy Client Relations Market Analysis Industry Research Security	Client & C-Level Presentations Executive Communications Staff Training & Development Data Optimization & Management Oracle/SQLServer/DB2	Solution Selling Customer Service Product Demonstrations Technical Consulting DB2/IMS/VSAM
Professional Experience

COMPUWARE                                                                                                                    1996 to 2013

Leading provider of IT software, services and best practices to deliver peak performance for technologies worldwide.

Sales Engineer & Consultant

• Provided technical analysis concerning Data Privacy to facilitate completion of RFI and RFP responses for various clients, with 85 percent success ratio.
• Delivered high-impact presentations to clients leveraging strong technical skills.
• Managed interoperability and alliance between software solutions and customers’ strategic business plans.
• Helped potential clients understand, compare and contrast several IT solutions.
• Collaborated with sales to develop cost justifications, business proposals and responses to RFI/RFPs.
• Engaged and coordinated post-sales implementation engagements.
• Helped close a minimum $2 million dollar sales 13 years in a row.
• Anointed to learn, support and sell two entire product lines, due to the unique requirement of both English and French support and sales.
• Contributed to a team that achieved a minimum 97 percent maintenance renewal.
• Liaised with Product Development and Marketing departments, perform client sales management, and report on industry/market trends, competition, and needs.
• Maintained extensive and specialized knowledge of COMPUWARE’s products, customers and competition, to enhance customer service ability and stay current on company offerings.
• Produced detailed phone support, personal product demonstrations and on-site evaluations of clients’ current software solutions.
• Responded to requests for information or pricing in an efficient manner and prepared sales package proposals.
• Trained and lectured clients, staff and executives on various solutions, including Data Privacy and Application Auditing.
• Facilitated customers and partners, as well as on-site professional services support such as installations and configurations upon deployment of software.
• Created, updated and disseminated training materials for 10 different software products on both mainframe and mid-tier/distributed environments.

• Served as Project Manager/Team Lead developing and updating training material with a specific timeline and with the participation of 10 team members.
• Gained proficiency in MS Windows, MS Office, Salesforce.com, and Data Privacy Solution Mainframe.
• Was one out of two people chosen (out of 24) to be a mentor for the Professional Development Program, training non-IT professionals to be support personnel.
• Worked in various realms, including ETL, Data Privacy in the testing space, Data Management and Data Optimization for both short-term and long-term sales cycles.

MONTREAL TRUST / BANK OF NOVA SCOTIA                                                  1984 to 1996

Premier financial institution providing personal, commercial, corporate and investment banking services to individuals, small and medium-sized businesses, corporations and governments.

Principal Analyst & Team Lead

• Oversaw the team responsible for financial systems, including general ledgers, accounts receivable and accounts payable within the Trust Unit.
• Apprised management of more efficient methodologies to ensure better business decisions.
• Provided guidance, instruction, direction and leadership to the team to achieve key results for clients.
• Coached and matured the skill level of direct reports in order to continue their long-term development and ensure solid succession planning and departmental success.
• Liaised with Payroll, HR and Executive Offices as a subject matter expert.
• Gained proficiency in COBOL, IDMS, and IBM Multiple Virtual Storage
• Created “What if” scenarios and provided support for non-technical end-users.
• Designed major conversion project for Pension Plan Changes/Acquisition (BNS).
• Worked with the Finance Team to determine the ongoing business needs and requirements for the reporting of all assets, sales, redemptions, management fees, trailer fees, and advisory fees.

Certifications

Security+                                                                                                                                                   

• Knowledge of security concepts, tools, and procedures to react to security incidents, to ensure that security personnel are anticipating security risks and guarding against them.

CIPP/C: Certified Information Privacy Professional/Canada                                 

• Demonstrates understanding and application of Canadian information privacy laws, principles and practices at the federal, provincial and territorial levels.
• Requires completion of Certification Foundation Exam and CIPP/C Exam.

CIPP/IT: Certified Information Privacy Professional/IT                                                    

• Entails understanding privacy and data protection practices in the development, engineering, deployment and auditing of IT products and services.
• Necessitates completion of Certification Foundation Exam and CIPP/IT Exam.

IBM Certified Database Administrator – DB2 9 DBA for z/OS                                           

• Validates capability of performing intermediate to advanced tasks related to database design and implementation, operation and recovery, security and auditing, performance, and installation and migration/updates specific to the z/OS operating system.

Education

Concordia University, Montreal, Québec

Bachelor of Commerce, Accounting (1979)

Robert Galambos Visual Resume

In the world where presentations can make or break a sale, a project, or a policy, I thought it would be a great idea to create something to showcase my MS PowerPoint skill set.

 Visual Resume

Musing of Big Data and Privacy

Big Data and Privacy. Or should a Big Box store figure out if someone is pregnant?  

Is that Private?

So what is Big Data? Is it the latest 'fashion statement' from the IT world? A bunch of numbers, letters, that represent something or someone? Something of an asset?

All the above and more. Basically it is the information, or data, that is generated by everyone and everything.  Examples of Big Data include this particular blog entered on the web, the decoding of the human genome, the buying habits for your customers, your credit score etc.

 Its 'stuff'. 

Google’s CEO Eric Schmidt stated: “From the dawn of civilization until 2003, humankind generated five exabytes of data. Now we produce five exabytes every two days…and the pace is accelerating.”

SO that is Big Data. But how does it concern privacy? Before we go there, lets reflect this issue. 

Companies are generating great mounds of data. Everything from what you purchase in grocery items (those Customer loyalty cards) to what credit cards you use and where. 

This is an asset to the company. It is something that can be analyzed, inspected, and reported on, all for the purpose to get the upper edge from their competitors,  a better understanding of the customers,how to market/target them to get the best results, What tickles their fancy so to speak? Maybe get that same customer to buy milk from your company as well as  the clothing that they buy now.

While doing the research for this blog I came across an interesting case study concerning this  issue.

A major Big Box chain’s (not Wal-Mart) department of thinkers (not a real department but could have well been named that) got together to try to see if they could 'predict' which of their  customers were pregnant. 

The reason was if they can get that pregnant customer to start buying the 'stuff' needed for the happy occasion, they could influence their buying patterns in the future. A better 'bottom' line (pun intended).

They had all this raw data about their clients and their buying habits. They can mine the information (Big Data) and determine if there were any patterns. And the results were, to say the least, eye opening. 

Now, this blog is not the place to have a detailed discussion about this, but needless to say the mathematical model that was developed was successful in more the 87% to predict, based solely on buying habits, which of their clients were pregnant. They were then able to target  the pregnant customers with  coupons, flyer's, etc in hopes getting them to buy more ‘STUFF’, 

This was done without the a client filling out a form letting the company know they were expecting, Ms Jane Doe customer had yet to buy a single diaper etc. The mining of this client’s information from the company database which indicated her buying habits, was the only determining factor. 

That is what Big Data is, and what it can do.

Can you see the issues in privacy in all this? Actually, there are really three different issues when dealing with Big Data.

Is what the company doing legal?

Is it ethical?

Is it acceptable to the general public? 

Let tackle the legality first. 

It’s not a simple answer. There are a lot of variables involved. Where does the customer live? Did he/she give permission to the company to use the data collected for internal (and maybe external) use? These are but two questions that privacy officers need to deal with, address and ultimately sign off on. 

Generally speaking, we can assume, when a customer signs up for a loyalty card, there would be some form of authorization to use the data. Or at least best practices demands such sort of disclosure, if nothing else. And this may be the easiest of the three questions.

Is it ethical? 

PHD theses have been written about this very question for 'years'. There is no gov't review panel to determine if it is or not ethical, but the question is still very valid.  One education site states that ' ethics refers to standards of behavior that tell us how human beings ought to act in the many situations..'  

http://www.scu.edu/ethics/practicing/decision/framework.html

While there is no stand fast rules on what is and is not ethical, one can, if for no other reason,  look into the mirror and ask the question? Is this ok?

Is it then acceptable? 

Going back to the story above, let’s see what happened. After the store created the model, they started sending flyer's, coupons that would target the would be moms. Examples, like diapers coupons , flyer's featuring cribs etc.  were sent out to the targeted group. 

Well, you can imagine what happened next. Many irate customers wondered, first of all, how did this company know they were expecting. Even more damaging to the company’s reputation was the fact that they were sending baby oriented coupons to non pregnant clients. And what if those target accounts were teenagers, and/or single,  and/or religious?

A public relations nightmare. In fact, while doing the research, I was surprised that this had not been thought out more thoroughly in the marketing department of the company.

All these factors play in the realm of Big Data. And privacy is just one of those factors.

Ultimately, the people responsible for privacy need to assure themselves that the use of the data is within legal constraints. 

It can be more complicated if that data  being analyzed is sent out to another company. There are 'mounds' of companies whose only job is to message the data and make sense of it. They can then market to those clients with targeted campaigns  as successfully as possible(the pregnant ladies from the above example), to get the best return on the data. (the Big Data).

Big Data means being able to see trends and patterns, not determining individuals buying habits per say. 

No one in Costco cares if the individual named Robert will buy a steak or a bottle of milk. What they do care about is influencing the group that Robert ‘belongs to’ so they can somehow how influence that targeted group to buy both products (as an example).  

 So an argument concerning privacy can go something like this:

Its not the PII information of a particular person that is being used (for the most part) for this type of analysis, but that a customer bought an item and he is middle aged, 6 foot, lives in a middle class area, Etc. And he belongs to a statistical group that represents 25% of the customer base in a particular region.

Maybe. But then again is that the only usage of these great mounds of data?

The debate on Big Data, how to handle it, and the ramifications on privacy will continue. What we need to do, is have the dialog, ask the questions, figure out what can and should be done. 

The concerns won't go away, and ignoring the issues will only make it worse.  We all need to first understand the issues and then try to make 'a go at it.' And at same time making sure we don't shot ourselves in the foot.

Testing, in the black box (ATV), Security & Privacy

How Automate Testing Vehicles (ATV) should include Pentesting.

Why should privacy officers get involved in development, regression testing process?

Why does IT need to improve their testing strategies?

Pitfalls in Testing, Security/Privacy concerns is what drives people to have nightmares. Privacy officers need to have a better understanding of the environment they work in. The IT people need to embrace the notion that Privacy/Security starts from the beginning. So in that way the chances of being on a front page of a newspaper because of a breach and/or a failure will be minimized. NO ONE wants to phone the CIO about a problem like this. It is a team effort.

I do have to warn you, the reader, that some of the material may be a  little IT oriented. But in an organization where one needs to satisfy a number of different objectives, I would suggest at least a basic knowledge of the IT process is needed. And that the IT personnel need to understand the present compliance/regulator landscape.

Some definitions are warranted before I begin.

ATV or Automated Testing Vehicle. What is it? Why do I care? And is it a 'best practice'? (one of the most over used phrase at present).

The idea is fairly simple. Having a set of scripts (automated) that can be run to test the system in question. The objective is to test the system before any changes are implemented. The process should set up  the files that will be used for testing(see one of my previous blog posts concerning using data for testing),  then run the test scripts, and afterwards run the comparison reports and highlight items of concern from the test just executed. All this is done in an automated fashion. Rather simple concept, but one that can be 'processes' changing in a good way.

Well there is more to this. But let me define another term or two first.

IT systems that are down cost money in lost revenue, and good will to the enterprise.  As an example, in 2012 Google had an outage.
Google June 2012 down for 10 min.

The ball park figure cost that Google suffered was calculated at about $750,000. And that was for 10 minutes.  Now I am not suggesting all downtime costs are that much. It depends on the circumstances, but I am sure no one would like to find out for their own companies.

Another good example of the costs is sited at costs of web down time per industry

This site allows you to calculate the cost of a web site being down per industry/application. Its an eye opener to say the least.

In another 'word', downtime is BAD/EXPENSIVE *Yea  I know that is two words*. But joking aside we need to reduce unavailability as much as possible.

PenTesting. Wikipedia link  The Information Systems Audit and Control Association(ISACA) defines Penetration Testing as  "A test of the effectiveness of security defences through mimicking the actions of real-life attackers."

(For the reader who is more concerned with Privacy/Security, please read on)

So now let's proceed. When an application change happens IT personnel (or a designated organization) tests the changes (IE regression testing). They test the change to see if it works. Now depending on the process that is followed, a user may also test/approve the same series of changes to the application for user approval. Fine, right? Do you notice something missing in the above? In fact, there is more then one item here that needs to be defined/explored.

For many organizations testing to maintain the basic functions within an application does happen in a haphazardly way.  Sure the change is tested and to get to the enhancements, some basic functions are tested as well, But, based on my anecdotal experiences, on many occasions, the entire core functions of the changed application are not testing on a consistent bases.  A test of the all the basic core functions should also be completely tested whenever there is a change.

As an example, if the application in question is some public facing web application (a web store as an example), basic function testing should also be done. Test for example, the ability to add/change a Credit card information and make sure that the update still works. Test adding an item to the shopping cart etc.

So if the new function within the application fails, you have verified that the basic core functions, the one you need to keep the doors open, will still operate.

Imagine if an error occurs at your bank, yet the basic functions were tested successfully with the 'improved mobile bank portal' (the change that will be implemented).  Then logic would dictate that the basic functions should still work (you can still pay bills) even if the enhancement of the bank's mobile app does not. Corrections can be retested and implemented with minimal cost/embarrassment to the organization.

I am therefore advocating that there should be standard testing scripts that confirm, even with the changes that are going to be implemented,  that ALL the core functions still are accessible.

So to implement a process like this, you first need to map out the basic functions that you can not live without. Once that is done and scripts are created, an automated process should be created. When ready, a series of script can be executed with little human intervention. (less change for human error). The 'Best Practice' (there is that phase again) would be something along the lines of submitting the scripts and going home. When you get into the office the following day the results are ready for analysis/correction etc.

This should ensure that at even if the new change fails. You, the customer, can still do business with the organization in question. This is what some people call a ATV (see above). This process can be called your insurance policy.

However, lets' takes this further. Why just test  the basic functionality of the application? Should we also test for Security/Privacy issues?  Should the company's Privacy/Security office ensure that this type of testing, verification is also included within an ATV and executed whenever anything changes?

Absolutely!

A process that includes PenTesting (see above) is something one should consider adding to the above mentioned ATV. With any change there is always a chance that a vulnerability is created that may not have been there before.

Any failure can by it's very nature, cause the potential to expose sensitive information. It can be business secrets, and/or Personnel Identifiable Information (PII) to name but two potential headaches.

There is software in the marketplace that has the capability to engage/test/analyze applications for vulnerabilities. Some of the software I have previously mentioned as well as others which are available with the capabilities needed.

So I suggest that one creates an ATV process that includes the basic functionality of the application/system in question as well as additional testing for security/privacy. All  this should be automated so that more extensive testing can be executed as well as reducing the chance for human error.

Privacy officers need to ensure that any changes that are implemented will not cause exposure that may be costly. IT people need to make sure that the basic systems functions still run, no matter what is changed.

Finally, while no one can claim in absolute terms that there will be no issues, following these basic concepts can help reduce the chance that the CIO needs to be called because of an issue.

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.