The Canadian Privacy Law Blog: Developments in privacy law and writings of a Canadian privacy lawyer, containing information related to the Personal Information Protection and Electronic Documents Act (aka PIPEDA) and other Canadian and international laws.

Search this blog

Recent Posts

On Twitter

About this page and the author

The author of this blog, David T.S. Fraser, is a Canadian privacy lawyer who practices with the firm of McInnes Cooper. He is the author of the Physicians' Privacy Manual. He has a national and international practice advising corporations and individuals on matters related to Canadian privacy laws.

For full contact information and a brief bio, please see David's profile.

Please note that I am only able to provide legal advice to clients. I am not able to provide free legal advice. Any unsolicited information sent to David Fraser cannot be considered to be solicitor-client privileged.

David Fraser's Facebook profile

Privacy Calendar

Archives

Links

Subscribe with Bloglines

RSS Atom Feed

RSS FEED for this site

Subscribe to this Blog as a Yahoo! Group/Mailing List
Powered by groups.yahoo.com

Subscribe with Bloglines
Add to Technorati Favorites!

Blogs I Follow

Small Print

The views expressed herein are solely the author's and should not be attributed to his employer or clients. Any postings on legal issues are provided as a public service, and do not constitute solicitation or provision of legal advice. The author makes no claims, promises or guarantees about the accuracy, completeness, or adequacy of the information contained herein or linked to. Nothing herein should be used as a substitute for the advice of competent counsel.

This web site is presented for informational purposes only. These materials do not constitute legal advice and do not create a solicitor-client relationship between you and David T.S. Fraser. If you are seeking specific advice related to Canadian privacy law or PIPEDA, contact the author, David T.S. Fraser.

Thursday, October 12, 2006

Incident: Hacker steals personal information from Brock University computers 

I have generally stopped reporting privacy and security incidents, since the sheer numbers are overwhelming. But I'll make an exception for this one, since it involves a Canadian university...

Hackers steal personal information from Brock University computers:

The personal information — including some credit card and bank account numbers — of about 70,000 people who gave money to Brock University has been stolen from the school's computers by a hacker.

Terry Boak, Brock's vice-president academic, said the digital intruder had the secret passwords needed to access the file listing of possibly every individual to ever donate to the university.

'It wasn't just someone who hacked in by playing around with it,' Boak said. 'So, you start thinking about how these passwords were obtained.'

Boak said the hacker tapped into the system on Sept. 22 at 5:27 p.m. ET, taking only four minutes to make off with the file containing thousands of names, birthdates and e-mail addresses.

About 90 credit card numbers and some 270 bank account details were also in the file.

Boak said those people were called within 24 hours, while the remaining thousands received a letter in the mail explaining what had happened.The personal information — including some credit card and bank account numbers — of about 70,000 people who gave money to Brock University has been stolen from the school's computers by a hacker.

Terry Boak, Brock's vice-president academic, said the digital intruder had the secret passwords needed to access the file listing of possibly every individual to ever donate to the university.

'It wasn't just someone who hacked in by playing around with it,' Boak said. 'So, you start thinking about how these passwords were obtained.'

Boak said the hacker tapped into the system on Sept. 22 at 5:27 p.m. ET, taking only four minutes to make off with the file containing thousands of names, birthdates and e-mail addresses.

About 90 credit card numbers and some 270 bank account details were also in the file.

Boak said those people were called within 24 hours, while the remaining thousands received a letter in the mail explaining what had happened.

Labels: ,

10/12/2006 06:37:00 PM  :: (7 comments)  ::  Backlinks
Comments:
An interesting fact about this story is that Brock went to considerable expense to move off of a secure mainframe environment that was "hacker proof" for some 30 years.
On Fri, April 15, 2005, the Brock University CIO Newsletter stated that:
"The Unisys conversion of our Student, Finance, Human Resources and Alumni application systems is scheduled for November 2005. We have finalized the contract with a vendor who will convert our application programs and data bases using their conversion software product. This conversion will move our applications and data bases from a Unisys mainframe to PC servers but they will continue to operate the same as before for students, staff and faculty."

Obviously, the security and privacy of their donor's information was an afterthought.
 
It is worth wondering if the benefits and projected savings they forecasted as the major justification for moving off the secure Unisys environment were ever realized. The combined costs of the conversion process, any staff retraining, the new PC platform, freezing application changes for the duration of the converesion, the loss of existing capabilities if the new environment did not support all the previous functionality, the additional cost of redeveloping any lost or broken functionality, and any other unknown area might have consumed all the potential savings and more. Also, there are additional costs for additional security capabilities, to handle the current security breach and any future breaches.
If possible, would migrating back to the Unisys environment be a prudent strategic action at this point to limit further risk and exposure?
 
Security of the mainframe environment is indeed often understated and taken for granted. Unlike many other systems where security is an afterthought, Unisys ClearPath MCP mainframes were designed from the beginning with security as a core element.
For example:
- 48-bit memory words have a system-protected 4-bit tag field that indicates the word usage (i.e. code, data, or stack)
- this prevents data from being executed, eliminating a major factor in the spread of viruses.
- Data accesses are bounds-checked, preventing memory corruption due to faulty or malicious code and eliminating the risk of buffer overflow attacks.
- No assembly language – programming must be done in a high-level language – the operating system prevents programs from having unrestricted access to the machine.
- Code generation is restricted – only code generated by a program designated as an authorized compiler can generate executable code.
Built upon this solid foundation, the MCP supports:
- A variety of authentication mechanisms. All points of access into the system are secured by one or more authentication mechanisms.
- An extensive access control structure, allowing administrators to control who can access which programs or data, and who can submit particular transactions.
- Extensive auditing and monitoring capabilities. All security violation attempts are audited.
- Encryption and cryptography capabilities.
- Secure Web access, given the inherent protections from viruses and worms that are enforced by the system.
- A Secure JAVA environment.
 
In the St. Catharines Standard version of this story several alumni were interviewed and comments like: "These things do happen.", "Unfortunately, that's the reality of today's world.", "These things happen. There's no perfect system," and "If you're going to get upset, you might as well get upset about something you can do something about."

The spin that “there was nothing we could do to prevent this” is shocking. Would these people be so charitable if it was their bank, hospital or government databases that were so easily hacked?

Brock University had a system that was significantly more secure than the collection of PC servers they migrated their application to. The Unisys MCP system is in widespread use around the world in financial institutions, government agencies, and yes colleges and universities. The MCP operating system and the underlying system architecture were designed from the ground up to provide a set of features to prevent both accidental and deliberate attempts to corrupt or steal information.

In the article Dr. Boak said “So, you start thinking about how these passwords were obtained." (to access the donor file). Maybe Dr. Boak should visit http://www.rootkit.com – this site describes a rootkit (Winlogonhijack) that can be used to capture every logon to a Windows system in plaintext.

Rootkits are powerful tools to compromise computer systems without detection. They are so easy to obtain and modify they can be used by relative neophytes, known as “script kiddies”.

It’s too bad Brock got rid of their Unisys system which would have prevented this kind of attack.
 
As one of the 90 Alumni who trusted Brock to secure their personal and credit card information, I was appalled by this breach. Having been a computer science student at Brock, I was aware that the then Burroughs (which became Unisys) system, which we did some of our academic work on, was used for administration. In appreciation of the experience I had at Brock, I felt it was only right to give something back. For years regular automatic donations were made simple through the use of my credit card. Now a very short time after the conversion off of the mainframe, that trust has been broken. This is not something I hold against Brock as a whole, but I do blame those few individuals who only looked at their own personal interests or agenda’s to put us at risk in the first place. Taking a simplistic view of the value of applications as being just the hard costs does not provide the true value of the service the application provides. I hope that those who made the decision are personally held accountable for their actions, my future donations will count on it!

BTW – You really don’t realize how much you depend on your credit card until it’s stolen! I am sure the other charity groups and institutions that had their regular donation/payment flow interrupted would like to thank those individuals responsible as well. I am sure we will never know the true cost of this.
 
I’m not at all surprised by the “security breech” reported in the press. During my time at Brock, there were a number of breeches of “non-critical” systems; such as the email servers and web servers – which run on UNIX and Linux. Viruses and Denial-of-Service attacks were a common nuisance; but the most worrisome attacks involved “key loggers” which infiltrated servers with weak protection mechanisms and quietly harvested userids and passwords.

The only incident I recall regarding the ClearPath administrative system was a virus attack on the underlying Windows Operating system which supported the MCP as a virtualized environment. This resulted in availability issues, but information security was never compromised. We logically disconnected the Windows Operating system from the network and only allowed the MCP environment to process network traffic. We had no problems with viruses on the administrative system after that.

For many years Brock ran without a firewall to protect the administrative system because it was not required. The Unisys ClearPath MCP architecture will not allow introduction of arbitrary code into the system, and will prevent the execution of data, as well as buffer overflows which are the most common means of introducing code.

I was involved in planning for the Windows, SQL Server and LION application environment that was going to replace the Unisys MCP, DMSII and EAE application environment. I had produced an architecture I believed would be required to secure the administrative system assets. It incorporated multiple zones with firewalls to protect the database servers, the application servers and the web front-ends. The development systems were isolated completely from the production environment, and I proposed a Quality Assurance Test Environment for integration and testing of Microsoft Security Updates, Hot Fixes, and Service Packs prior to deploying them on the live production environment.

Obviously, that architecture never got off the “drawing board”. It surely would have driven the cost of the ‘new and improved’ administrative system well beyond the price Unisys had proposed to update the aging MCP server with a state-of-the-art ClearPath system.
 
As reported by Unisys at their European Users Conference, Future Matters, in Antwerp Belgium (May 2006).

Unisys engaged Symantec to attempt to breach a ClearPath MCP Server using standard exploitation techniques.

“Symantec consultants analyzed the system from the perspective of an attacker and applied the traditional exploitation method to the MCP environment without success.”

“The system enforces memory protection, for each word of memory, by assigning tags to the memory location that describe the types of operations allowed for that particular piece of memory. This protection exceeds the current state-of-the-art in systems designed to meet the needs of the commodity computing market.”
 
Post a Comment

Links to this post:

Create a Link

This page is powered by Blogger. Isn't yours? Creative Commons License
The Canadian Privacy Law Blog is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Canada License. lawyer blogs