The Cause

Found I develop free software because of CUNY and Blackboard following the Blackboard security issues story. It is a really good blog post. This conclusion made me smile. I am certain there are plenty of people in the system I support who strongly agree. I just wish there was an easier way of finding and applauding them.

As long as our IT departments are dominated by Microsoft-trained technicians and corporate-owned CIOs, perhaps the best way to advance the cause – the cause of justice in the way that student money is spent – is to create viable alternatives to Blackboard and its ilk, alternatives that are free (as in speech) and cheap (as in beer). This, more than anything else, is why I develop free software, the idea that I might play a role in creating the viable alternatives. In the end, it’s not just about Blackboard, of course. The case of Blackboard and CUNY is a particularly problematic example of a broader phenomenon, where vulnerable populations are controlled through proprietary software. Examples abound: Facebook, Apple, Google. (See also my Project Reclaim.) The case of Blackboard and its contracts with public institutions like CUNY is just one instance of these exploitative relationships, but it’s the instance that hits home the most for me, because CUNY is such a part of me, and because the exploitation is, in this case, so severe and so terrible.

The training plan is to make me one of those “Microsoft-trained technicians”. It makes me feel stupider just thinking about it.

Blackboard Security

Interesting articles accusing Blackboard of being lax about security. A Black Eye for Blackboard Over Its Response to Major Security Flaws which is about Millions of student exams, tests and data exposed. I saw the security bulletins, but I was not aware of the back story leading to why it was announced. We run an unaffected product, so I mostly ignored it. After reading the stories a couple times and the security bulletins again, my general read is still: overblown.

Blackboard’s practice is to work with the reporting client to determine the nature of the issue, whether it is being exploited, and test the fix. On the occasion where I was the reporting client, I was asked not to publish information about it as that would allow malicious individuals to exploit it before other clients implemented the fix. As I recall, the time from my reporting it to getting a patch was about a month. Plus, what I reported was pretty specific, Blackboard took that and looked more broadly and fixed everything they found. Then again, I reported a single issue not 16. Also, I tend to report such things to John Porter directly as I trust him to seriously address them. Someone opening a low priority ticket to the Tier I helpdesk, not providing the data Bb requests, or even worse incomprehensible data can get stuck in the Blackhole (where support tickets go to die). Every client needs to read Blackboard’s information on how to report security issues.

A problem with Blackboard only talking to the reporting client(s) is other individuals might already be aware of the exploit. The idea of keeping mum will prevent others from finding out fails to consider Newton invented Calculus at the same time as Gottfried Leibniz. Security by hoping no one else finds out… isn’t secure. Clients not provided ways of detecting whether the exploit is being used cannot report to Blackboard that their systems were compromised.

“We are not aware of any institution’s academic or student data having been compromised in any way by these issues,” Tan said.

In this statement, “any institution” means the clients who discovered this vulnerability not all clients. Blackboard is reassuring that the problem is minor and clients applying the patches quickly will keep it minor. Calling this a zero-day security vulnerability implies attack code is out there available to be used. So attackers potentially have information while defenders do not? Unfair. Epic fail. But only when it leaks to the attackers or they independently figure it out.

More interesting is the vulnerability claims Blackboard considered invalid because they “were due to misconfigured security settings.” So if an administrator sets an incorrect configuration the problem does not exist? For example, an administrator does not set Secure HTTP on the login, so a malicious person in a coffee shop snatches passwords and uses it to alter grades. (Or worse a 9 year-old compromises his teacher’s password.) Yes, it is the administrator’s negligence, but as a partner Blackboard should be helping administrators not be negligent. Keep this in mind: When a Blackboard system is compromised, only Blackboard cares whether it was administrator negligence or Blackboard code.

As a defender, I want all the information I can to protect my users from attackers. Whenever I talk about this with other clients, I hear the same thing. Instead I am left with fear, uncertainty, and doubt. Not that I expect any other vendor to provide me more information than Blackboard. This is why I like the idea of open source.