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.”