October 8th, 2009
A data breach is an unintended disclosure of information. Sometimes data may be outright stolen, which means that someone actively sought to obtain data they were not entitled to and succeeded in obtaining the data by thwarting data security. Another common type of data breach is the accidental exposure of privileged data through inadvertent publication, accidental disclosure or even insufficient disposal. Both types of disclosure are damaging and can result in corporate humiliation, angry customers and legal action.
A data breach represents the complete failure of an organization’s data governance policy. The key principle behind privacy laws is that the organization that possesses personal information must act as a steward for the data. In exchange for ensuring security the company is permitted to possess the data. To satisfy the minimum legal standard businesses implement processes and policies internally that define how data is managed and secured. When data is allowed to slip through the corporate cracks it demonstrates a failure of fiduciary duty and that a company is unable to secure its own assets.
Unintended disclosure of information is not just an embarrassing example of corporate incompetence but it also represents a serious threat to customers in the form of identity theft. A CBC article from September 2009 indicates that Phonebusters, a Canadian anti-fraud website, has published 2008 identity theft statistics that show 12,142 reported victims across Canada totaling over 9.5 million dollars in losses. The article segues quickly to a discussion of the 2007 data breach at TJX Cos. of 45.7 million debit and credit card numbers. While there is no evidence to suggest that the information from the TJX Cos. breach was used to steal any of the 12,142 identities the very structure of the article indicates how closely journalists and the public link data breaches and identity theft.
The online IT security magazine SC Magazine maintains a blog named The Data Breach Blog that compiles breaches published in major newspapers. Unfortunately, data breaches are becoming so common that the blog is updated multiple times a month and has a dishearteningly large archive. What is evident from the SC blog is that many organizations either don’t appreciate their duty under the law or they have systems that are outside of their control. Both of these excuses will find little sympathy with a public that has been exposed to identity theft and will hold little water in a court of law.
In the next post I will discuss what needs to be done when a data breach occurs.
Tags: Business Continuity, Data, Policy, Security
Posted in Best Practices | No Comments »
October 2nd, 2009
For some companies sharing data is a necessary part of operations. When that data is personal information gathered under the auspices of PIPEDA the act of sending data to a third party is a form of disclosure and requires extra vigilance to ensure that the partner company holds to the same data governance standards as the original. PIPEDA councils that a company that originally collects data must ensure that any third party partners observe the same stringent data protection policies as they do. In other words, data misuse by a third party company could land the original company in hot water.
For a bilateral exchange of personal information between two organizations a standard contract outlining the duties of both organizations usually covers it. During a negotiation both partners can develop a sense of trust that the other understands the centrality of data governance to a business’ success. When both parties negotiate data governance responsibilities it shows a respect for the importance of safeguarding personal information.
Companies will often ask to perform an audit of the partner’s data policies and safeguards as part of the contract. Process auditing is an important part of the continual assessment of data governance policies and being able to show how data is managed is a crucial aspect of understanding how data flows in and around a business. Auditing should be performed internally on a regular basis but also peridoically by an external agency in order to reveal potential blind spots. Auditing policies for business partners is a good way to learn from other organization’s expertise and to demonstrate the compliance of one’s own policies.
This is one the primary reasons why having documented data governance policies is critical. When faced with a choice of companies to partner with, the business with the clearly defined data governance policy is a more reliable and transparent choice. Being open to external audits shows a willingness to accommodate potential business partners and a confidence in one’s systems. Conversely, not having policies in place that demonstrate compliance with federal law and industry best practices can result in missed business opportunities.
For some companies sharing data is a necessary part of operations. When that data is personal information gathered under the auspices of PIPEDA the act of sending data to a third party is a form of disclosure and requires extra vigilance to ensure that the partner company holds to the same data governance standards as the original. PIPEDA councils that a company that originally collects data must ensure that any third party partners observe the same stringent data protection policies as they do. In other words, data misuse by a third party company could land the original company in hot water.
For a bilateral exchange of personal information between two organizations a standard contract outlining the duties of both organizations usually covers it. During a negotiation both partners can develop a sense of trust that the other understands the centrality of data governance to a business’ success. When both parties negotiate data governance responsibilities it shows a respect for the importance of safeguarding personal information.
Companies will often ask to perform an audit of the partner’s data policies and safeguards as part of the contract. Process auditing is an important part of the continual assessment of data governance policies and being able to show how data is managed is a crucial aspect of understanding how data flows in and around a business. Auditing should be performed internally on a regular basis but also periodically by an external agency in order to reveal potential blind spots. Auditing policies for business partners is a good way to learn from other organization’s expertise and to demonstrate the compliance of one’s own policies.
This is one the primary reasons why having documented data governance policies is critical. When faced with a choice of companies to partner with, the business with the clearly defined data governance policy is a more reliable and transparent choice. Being open to external audits shows a willingness to accommodate potential business partners and a confidence in one’s systems. Conversely, not having policies in place that demonstrate compliance with federal law and industry best practices can result in missed business opportunities.
Tags: Data, PIPEDA, Policy
Posted in Best Practices, PIPEDA | No Comments »
September 15th, 2009
Most companies’ data destruction policy can be summed up as “never do it”. This is often a knee-jerk reaction to the idea of deleting something that took effort to collect but there are examples where stale data can negatively impact a business.
I worked with a client who had been operating their website for many years. Over those years they had collected a large database of email contacts. Without my knowledge they initiated some email marketing campaigns with a database of a quarter million email addresses, some of which had been collected nearly seven years ago. The problem with the email campaign was that a large number of the people contacted had forgotten that they had opted to receive email. Modern email clients like Google Mail and Yahoo Mail make it simple for a user to mark an email as spam. Google and Yahoo take those spam emails and if they get enough complaints they blacklist the email senders, preventing anymore emails from coming through. This is a very bad thing to have happen to a business that relies on email. The lesson is that having a massive database of emails addresses is only valuable if the emails are recent and relevant.
What should this company have done? They should have taken the time to prune their data stores. Data has a shelf life and even the simplest data destruction policy would have prescribed the removal of data that is half a decade old. Expired data is a burden because it costs resources to manager information that is no longer useful but must still be protected from disclosure. A documented data destruction policy will put down in writing what data should be deleted and how frequently. Implementing the policy will ensure a systematic review and culling of unnecessary data and assure that the data store provides the most value.
Part of keeping on top of a data store means knowing when to jettison old data. Data destruction policies are a smart way to assure that an organization’s information resources remain relevant.
Tags: Data, Personal Information, Security
Posted in Best Practices | No Comments »
September 8th, 2009
Many organizations lack a critical piece of data security infrastructure: a data access policy for employees. I have worked with organizations that have compiled large databases full of valuable, relevant business data, encrypted the data to protect it in case of a data breach but then assigned a single username and password to the database and made those credentials available to everyone in the organization.
When using a single set of credentials everyone in the organization has complete access to the data set. This all-or-nothing approach can be rectified by defining roles that limit data access to predefined subsets of information. This type of control permits employees to access information on a need to know basis. This approach can be taken further by setting role permissions based on the current task an employee has been assigned and granting and suspending access based on need over time. The additional overhead of defining data access roles pays for itself when it prevents curious employees from snooping through the entire data set when they only need to be working with a subset of it.
In today’s business climate a data breach is as likely to come from inside the organization as outside. It may be a disgruntled worker causing havoc or a star employee who has been head hunted by the competition. When everyone who has access to the company’s data has their own set of credentials it is a simple matter to switch off access for a particular individual. For employees that are being fired or let go it makes sense to suspend access before their exit interview. For employees that resign data access can be terminated as soon as notice is given. Coupling individual data access credentials with limited data roles serves to mitigate the amount of data a departing employee can extract from an organization before their access is removed.
The point of this post is not to suggest that employees are not trustworthy but in industries with a lot of turn over such as IT and sales it makes sense to have strong policies in place to limit access to data. In an information economy the most valuable assets a business owns can be copied to a USB memory stick and walked out the door.
Tags: Data, Employees, Security
Posted in Best Practices | No Comments »
September 3rd, 2009
What is authentication?
Businesses often need to collect sensitive personal information, such as a driver’s license number, even after they have performed a detailed audit of their data requirements. Driver’s license numbers are frequently used by organizations as a form of authentication because the numbers are unique, they never change and it is uncommon for anyone but the owner to know the number. Authentication is just a fancy way of saying that a customer can prove they are who they say they are and access their account.
After the decision has been made to use sensitive personal information for authentication the next step is to determine the best way to store that information securely. A typical customer account is a row in a database that relates different fields together. Some fields such as name and address are needed to perform tasks like sending out billing invoices. However, for information used for authentication, such as a driver’s license number, it is prudent to store that information in the database in a form known as a hash.
A Hash?
A hash function is a mathematical way of turning a piece of text into a jumble of letters and numbers that is called a ‘hash’. Hashing a piece of text is similar to encrypting it except that with a hash there is no way to get the original text back. This means that there is no un-hash function: once a driver’s license number is turned into a hash it cannot be turned back into a driver’s license number.
When people first hear about hashes they wonder how such a tool can be helpful. The trick is best illustrated with an example. Instead of storing a driver’s license number as plain text a hash of the number is stored in a database. When a customer authenticates by entering their driver’s license number that freshly entered number is hashed. The comparison is then performed between the two hashes, the one in the database and the new one, and if they match then the customer is who they say they are. This approach works because of a special property of hashes: they are unique to the text that created them.
How does this help promote security?
The hashing process adds an extra step to data storage and authentication but the approach pays off if there is an incident and that the personal information database is breached. Without hashing, the database would contain a list of names, addresses and driver’s license numbers. With the hash the database contains a list of names, addresses and a jumble of letters and numbers, which are essentially useless to data thieves. While the release of the names and addresses is bad, it’s not as bad as a release of names, addresses and driver’s license numbers.
While hashing may seem like a technical topic it’s really about minimizing exposure in case of a data breach. Programmers are able to hash data easily but policies need to be in place that recognize the value of protecting data to the fullest extent possible. If sensitive personal information is a necessary part of a business’ operation it is worthwhile to investigate if the database could be made more secure with hashing.
Tags: Data, Personal Information
Posted in Best Practices | No Comments »
August 25th, 2009
An important aspect of business continuity is safeguarding data stores against loss or corruption by scheduling periodic backups. When a business relies on data the unexpected loss of that data can be devastating.
For companies that have online databases it is essential to implement a policy of automatic backups that creates a duplicate copy of the database at regular intervals. These intervals can be as short as every 6 hours depending on the frequency with which data is added to the system and how important that information is to keeping the business functioning.
Backing up data is only half the battle. It is also important that companies have procedures in place that dictate how critical systems are to be restored from a back up in case of an emergency. This means that there should be steps written down that say how a previous backup can be used to reinstate a downed system to a functioning state. It is critical that these policies be put in place before a crisis as an emergency is not the time to be experimenting with procedures.
Data backups extend beyond the corporate database to include the administrative information that helps a business operate. I have worked with organizations that kept all of their client contacts on a single laptop with no backup. If that computer was to ever be lost, stolen or otherwise made inactive there would be no record of the names, addresses and phone numbers of the companies clients! Information like this needs to copied and spread around an organization. A single point of failure is something that needs to be identified and fixed before disaster strikes.
If reporting services are used by a company I recommend that a schedule be set up for an administrator to export reports to a format such as Excel on a regular basis. A local copy of a report provides protection against database disasters and can serve as a proxy for the full data set depending on the nature of the report. These types of reports can be stored on a company’s network area storage (NAS) server as a second form of backup.
Other forms of information that should be collected and protected include usernames and passwords for corporate systems. These can include things like the credentials for a domain name account, a web host or an email server. This type of data can be gathered into a document that details each service the company subscribes too and the credentials needed to administer it. Of course, it is important not to leave this document lying around. I recommend that the document be printed and put in the corporate safe or strong box where only authorized employees may access it.
When a business depends on information to create value losing that information can imperil the future of the business. Putting in place policies and procedures before an emergency happens can mean the difference between a day of downtime and closing up shop. A good backup plan is like insurance and it should be part of every smart business’ operation.
Tags: Business Continuity, Data
Posted in Best Practices | No Comments »
August 17th, 2009
Forms on websites are a great way for organizations to gather information from their users. The problem new organizations face is that they see the data gathering potential of their web properties and go overboard in their data collection activities.
Here are several reasons why a company or business should carefully consider each piece of information that they solicit from their users:
- A large web form is daunting to users. Usability experts have known for years that when a user is confronted with a long and complex form they are less likely to take the time and effort to fill in all the requested data. Users are not willing to make the effort to submit all the details requested and will abandon the web site to search for what they want somewhere else. The end result of aggressive solicitation is that there will be fewer users submitting information and that translates into fewer customers.
- Asking for too much information is suspicious. The Internet has been around long enough to create expectations in the minds of users of what is and is not appropriate. I have worked with companies that have wanted to solicit information on a sign up form that would make most website visitors uneasy. Details such as driver’s license number and social insurance number raise alarm bells for users. The organizations’ intentions are never malicious but they fail to understand the optics of requesting information that users consider to be of a more private nature. Companies often do not spend the time upfront to really understand what data is critical to their goals. I always recommend that the stakeholders spend an hour writing down exactly what they hope to achieve and what information is critical to success. When the exercise is complete they have a list of the exact fields that should go on their web form.
- You need to explain what all the information is going to be used for. Under PIPEDA an organization that is collecting data is obligated to explain to the user exactly how the information will be used within the organization. This legislative hurdle is why the exercise I mentioned at the end of point 2 is so critical. It is imperative that a business be able to explain to users the reasons behind the information collection effort. It is much easier to explain fields that have been identified as critical and more difficult to explain the rationale behind a kitchen sink approach. This legal requirement is actually a boon for organizations because it forces them to clarify the goals of their data collection upfront and guides them towards best practices.
- Gathering reams of data puts a technological burden on an organization. There is a technological burden related to excessive data collection. Data takes up hard drive space and requires human capital to manage it. Depending on the scale of collection this may become a concern when the hard drives are full of data that was collected unnecessarily. This can result in unnecessary time and money being spent managing the data store.
- Gathering to much data makes it hard to derive value. An operational burden arises when collected data needs to be transformed into actionable information. Data is collected for a reason: to learn about users. If there is a large amount of superfluous data it makes it that much harder to filter and sort to find the valuable nuggets of information. Contrary to expectations more is not better in data collection; better is better.
- On organization is the steward of all the data it collects. Under PIPEDA organizations are responsible for the safe keeping of the personal information that they gather. If a business is gathering unnecessary personal information and their systems are breached they have opened themselves up to liability for zero gain. As an example, consider gathering the mailing addresses of users for the purpose of understanding the demographics of the user base. Most solutions work with the postal code and it suffices to gather only the customer’s postal code and not the full address. In a system that collected only what was necessary an accidental database disclosure would only reveal a series of postal codes and not full mailing addresses.
The key to success in web forms is to remember this rule of thumb: don’t gather information you don’t need.
Tags: Forms, Personal Information
Posted in PIPEDA, Websites | No Comments »
August 13th, 2009
Almost all businesses handle data of some sort and that means that almost all businesses need an employee designated as the company’s privacy officer. Most companies I speak to about this topic scoff at the idea that they are large enough to require a privacy officer. They feel that a title like Privacy Officer only belongs in Fortune 500 org charts. For most companies, hiring a full time privacy officer is overkill and what they need is an employee who, in addition to their regular duties, also takes on the privacy officer role.
A privacy officer needs to be someone with decision-making authority such as a manager or a director. The job requires that the employee familiarize themselves with the nature of the organization’s data and the policies in place to manage it. The privacy officer also needs to know what data is collected and why and how the data is protected internally and from external attacks.
Many organizations initially suggest that a member of the legal department take on the role of privacy officer. While this may seem like a good idea it is important to recognize that the privacy officer will need to play an interdepartmental role and while the legal team holds a key position in a company’s privacy framework it may not be appropriate to assign a lawyer all of the duties of a privacy officer. A privacy officer needs to be the front line employee when dealing with privacy questions from the public and the media. They must be well versed with the company’s policies and practices in order to intelligently respond to inquiries. Because of the media aspect of the job many organizations have found that senior members of corporate communications often make excellent privacy officers.
On a day-to-day basis the privacy officer should expect to field questions from the public related to inquiries about personal information. I recommend to companies that they set up a privacy@domain.com email address and place it prominently on all of their websites. Some companies go even further and put the privacy officer’s name and phone number in the website’s privacy policy. Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) lists as one of its guiding principles that customers should be able to review and request changes to any of their personal information held by an organization. The privacy officer will often find himself responding to these types of requests and directing customer’s requests for information to the correct department. As such, they should expect to set aside some time everyday to deal with privacy related work even if it is simply to touch base with the different departments to see what’s new.
PIPEDA also lists as a guiding principle that any organization that handles personal information should appoint an employee to handle privacy concerns and that employee should be easily identifiable by the public and their contact information be clearly posted. Beyond the legal requirements, a privacy officer is a smart move for any organization concerned about transparency and customer service.
Tags: PIPEDA, Privacy Officer, Privacy Policy
Posted in PIPEDA | No Comments »
August 12th, 2009
In Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) dictates how non-governmental organizations (there is other legislation for municipal, provincial and federal governments) must safeguard ‘personal information’ that is gathered through business operations. There are a number of competing ideas of what personal information actually is and it is important that an organization be aware of the definition adopted by the government through the PIPEDA legislation.
Some organizations take a broad interpretation of personal information and believe that only ‘truly’ personal information such as social insurance number, health card number and credit card numbers justify the effort of enhanced protection. These type of businesses often use the rationale that personal details such as a home address, telephone number and email address are available in telephone and online directories and therefore don’t fall under the auspices of PIPEDA.
In fact, beyond identifying numbers, documents such as financial, health and work records are marked for protection as are subjective evaluations such as opinions, comments, and disciplinary records. Factual information about an individual such as their age, weight, height, ethnicity, and blood type also fall under the umbrella of personal information. PIPEDA does make an exemption for a person’s name, business title, business address and business phone number. A good rule of thumb is that anything that would normally appear on a business card is not considered personal information by PIPEDA.
The definition for personal information in PIPEDA is deliberately broad and that allows the privacy commissioner interpretative leeway when considering a complaint. The safest approach is to anonymize and aggregate data if that serves the purpose of the data collection. If unique records need to be retained just remember that anything beyond name and business contact details is considered personal information and subject to PIPEDA.
Tags: Personal Information, PIPEDA
Posted in PIPEDA | No Comments »