TR member appeals to Canadian government to reorganize IT and go open source

TechRepublic member Jaqui submitted a "Letter to the Editor," which in this case is actually a reprint of a letter that he wrote to a Member of Parliament about why the Canadian government should reorganize IT and go open source.

This post was written by TechRepublic member Jaqui and is published here in the spirit of a "Letter to the Editor," which in this case is actually a reprint of a letter. It is his individual opinion and does not reflect the opinions of TechRepublic or CBS Interactive.

I sent the following letter to my M.P. (Member of Parliament). I figure that since the Obama administration is pushing for more internet-based services from the U.S. Government, it can help remind everyone to be active and avoid serious flaws in security. This doesn't just apply to U.S. members though. Every government could easily implement a service online with as badly flawed security as this.

As we discussed in our meeting, the Epass Canada service is a severe failure in ensuring security with regards to accessing personal information via Government Web Access. This is a direct result of the use of client side scripting technologies. Specifically, in this case, client side Java.

Epass Canada, used to secure access to all participating Government of Canada web services, uses client side Java to create an encrypted communications tunnel between the person accessing the service and the service itself. While an encrypted tunnel is an excellent idea, and the only viable option to secure the access, the use of active client side scripting to create this tunnel is an insanely bad idea.

All someone with criminal intent needs to do is to go to the LOGIN page of an Epass secured service, then open the cache for their browser and copy the .js, .java and .jar files from the cache to a different location on their computer. All three of these files can readily be opened and viewed in HUMAN READABLE FORM.

"For each project, its source folders and referenced libraries are shown in the tree. You can open and browse the contents of both internal and external JAR files. Opening a Java element inside a JAR opens the CLASS file editor, and if there is a source attachment for the JAR file, its corresponding source is shown." The Eclipse Integrated Development Environment for Java's help files are available online.

The .jar file(s) will contain the 'codebook' used to encrypt the communication between the systems. Simply by having this(these) file(s), someone with criminal intent has the information required to craft a 'bot' to brute force break the service's administrator access.

The technical staff overseeing the service would see only a DDOS (Distributed Denial Of Service) attack on the service. With millions of bots each sending 1000 logins a second for the administrator account until they manage to get logged in the service would be straining under the load.

Once the login was compromised, the person running the bot net can then choose to get a database dump during this DDOS attack or to make use of it at a later time to do so. Doing it during the DDOS attack would bury the actual breach within a mountain of data (the proverbial needle in a haystack of needles).

Just imagine, Epass Canada has given criminally-minded people the data required to compromise the Canada Revenue Agency's database for ALL Canadian Business and Individuals they have a record for.

We can't really hold Epass Canada 100% responsible for this breach of security though - not in a fair manner. They do have to take 50% of the blame. During the period when the bids on providing this service was open, I happened across the website with Software Requirements Specification documents for the bids.

I actually really liked the detailed quality of these documents, very well written. The CONTENT of them show that the committee that set these documents up are 50% responsible for this breach of security. They had a REQUIREMENT that the Epass service be done with Java. That concept should not have lasted any longer than 10 seconds. The organizations bidding to provide the software / service gain their share of the blame because they should have ALL made it abundantly clear to the committee that the use of client side executable code was absolutely the least secure option available.

The Epass service, for effective securing of access, only needs to use the https protocol (Secure Socket Layer for the Hyper Text Transport Protocol, shortened to HTTP ). This would also address the second issue with access to government web services - namely, accessibility. Right now, there is very limited accessibility to these services because if the person visiting the site has even the slightest different in system configuration than what the Epass service likes, THEY CANNOT ACCESS their own information.

There are 14 different operating systems and 15 different web browsers. Epass Canada supports three operating systems and two browsers. One of the operating systems has over 300 different configurations available, yet Epass only supports two of those.

It would seem to me that Parliament needs to create a new Government Agency / Office. One with the mandate to ensure that all government of Canada Information Technology implementations for ALL agencies follows a best practices policy. Such a body could have shut down the use of Java for Epass Canada service before it was even made public.

Such a body could make sure that the Government of Canada's Information Technologies were as secure as possible for any system that is accessible via the internet. Such a body could seriously examine the costs to the Canadian Taxpayer for the IT used. The Government of Canada could conceivably reduce expenses for their IT by migrating to Free Software / Open Source Software. [A note about the FSF - to many people, it's leader, Dr. Richard M. Stallman, is a fringe radical. The stated policies of the FSF are none the less a valid goal.]

One of the biggest arguments against Free Software / Open Source Software is the perceived insecurity in the availability of the source code. However, there is effective proof of that not being the case. If the FBI with trained investigators, skilled at breaking encryption, couldn't break a Truecrypt encrypted drive -- Truecrypt being a Free Software / Open Source Software tool to encrypt folders, files, drive partitions or entire hard drives -- when they had access to the Truecrypt source code, that Free Software / Open Source Software is no less secure than Proprietary Software such as Microsoft Windows.

I will go one step further about the suggested oversight office, in that the standard practice of both appointing leaders and hiring based on specific qualifications may not provide such an office with the best people to perform its duties as proposed. Many of the details in those duties require thinking 'outside the box,' which isn't really endorsed by any of the 'certifications' available. All of the proposed responsibilities require a technical knowledge and a mindset that is not common. The Obama administration in the United States has implemented such an office for the U.S. government, but its efficacy and leadership have yet to be proven.


Jaqui Greenlees