Friday, March 15, 2013

IEBC Bug: Expanding the scope

Picking up from where we left last time, the 'buggy code' in the IEBC vote tallying system seems to have gone the way of the dodo. No one is actively pursuing that angle anymore.
Nonetheless, let me put into perspective what the above 'hitch' could mean for our ICT landscape.

Kenya is well known for innovation in the mobile space. Most if not all banks are now running different mobile banking solutions which have among other benefits, make banking convenient. Since majority of the banks contract 3rd party vendors to execute their mobile banking strategies, the end customer has very little or no knowledge of what checks and balances have been employed by their bank. It is all a trust based on the fact that "since my bank always takes care of my finances, this solution shouldn't be any different." Banks will probably enforce their information security procedures (PCI/DSS or ISO 27001) to ensure the mobile banking platform meets the baseline requirements. If at all they exist anyway because I know just a handful of banks are ISO 27001 compliant. However, this leaves a gap in ensuring that the said bank also ensures the vendor also has a minimum baseline requirement to handle the customers data. This leaves every other vendor running off to develop and deploy their own solution based on their own understanding of what "security" is. The bank could also contract an external audit firm be for go live just to ensure that all loop holes are sealed. However this presents an interesting challenge. Locally, most audit firms come from a financial background and therefore perform systems audits based on templatized methodologies which are not exhaustive enough. Mobile banking hasn't been in the scene for a very long time so some of these audits barely look at the entirety of the ecosystem and the players involved and instead focuses on a few facets perceived to be risk factors. With this in mind, I know some banks which have paid dearly for failing to perform an exhaustive risk assessment prior to go live and interestingly enough, the compromises have all been internal.

To tie it all together, if the above system isn't open for scrutiny from a holistic risk approach, taking into consideration all the dynamics introduced by mobile commerce, then you can see how compounded the IEBC "multiply by 8" factor could cost financial institutions. It also paints a rather tainted picture of how Kenya's software development ethic is highly in question.

However, the Government hasn't turned a blind eye to this and after a successful launch of the National Cyber Security Master Plan
 http://www.cio.co.ke/news/main-stories/kenya-launches-national-cyber-security-strategy-and-master-plan I can comfortably say that standards in development methodologies will be harmonized.  The CBK also introduced stringent measures for banks
 http://www.centralbank.go.ke/index.php/news/245-issuance-of-revised-prudential-guidelines-and-risk-management-guidelines-for-banks which came to effect in January. This means that most software houses will have no choice but to adopt existing Information Security standards.

As I conclude, I seemingly have a rather skeptical feeling that banks will embrace the above standards because from my interaction with some of the key banks around, only 3-5 are receptive. This applies to the Internet banking frontier as well. I have performed closed disclosures to some banks and they simply brushed it aside probably citing falsified assessments or otherwise. However, others have been very receptive and I guess it is just a matter of time before we can see any substantive progress in that direction.

So the IEBC bug isn't new to the infosec scene. It just metamorphosed into a national scale butterfly.

-ty 

Monday, March 11, 2013

IEBC: Security Compromise or Poor Project Management discipline

I remember reading this article while in a hotel somewhere in the far east http://www.nation.co.ke/News/politics/IEBC-to-invite-hackers-to-invade-its-systems/-/1064/1449152/-/uko5x7z/-/index.html. I thought to myself, "Hmmm, this is interesting. Challenge accepted, maybe?"

This led me to ask a dozen questions on how prepared we are in running a system of national interest under such a short period of time. In light of what Kenya has experienced in terms of cyber security exposure within the last one year, I cringed at the bold assertion by Oswago "We are confident that our system is tamper-proof. However, sometime in November we will invite those who think they can hack into the system to do it. "

You don't make such a proclamation unless you are 100% +1 sure of what you are talking about. I have audited lots of systems and even after go live, I still have the nudge to continuously test and retest for any loop holes I may have missed. My deepest fear is being blind sided by that 0-day exploit, a stray misconfiguration which leads to compromise. Perhaps Mr Oswago knew something I didn't know; after all he is the CEO. However, I felt that was an ambitious remark and if they indeed would invite "hackers" I would be most humbled to give it a go at the system which would be used in our election.

Many months later, the invite hadn't been sent out. Constantly, I would visit the IEBC website just incase they posted the invite there. So incidentally a few months before the above "invite", IEBC had put out a job advertisement for very specific roles, found here http://www.kenyancareer.com/2012/03/latest-government-jobs-iebc.html
  • Information Systems Auditor
  • Operation Systems Auditor
  • Compliance Risk Officer
Very specific roles in ensuring that a system of this nature is well audited and that every cog moves in sync with all other operational tasks. So question 1: Can the people who filled the above roles please stand up?


In slightly above 30 days to the general election, IEBC now invites "IT Experts" from the various parties to come and assess the system to their satisfaction. Here again not only dont we see a lapse in project management skills but also a clear indication that the system albeit having been tested, wasn't really pushed to it's breaking point. A paramount question is where is the evidence of any sign offs from the above "experts" of course assuming this was run with the project management discipline as we know it? Even more interesting, they commissioned the system for go-live having satisfactorily tested it. So where does the question of "server crashed due to load" come into play?

Let's move to the 20th-22nd Feb. I recall seeing a snippet in the Daily Nation regarding the IEBC having contracted an independent information security auditing firm to conduct one last audit of the system. In an interesting rejoinder to the interviewer I guess, IEBC preferred to keep the name of the firm and/or the auditor secret due to the nature of the task. Bear in mind this is just under 11 days to the polls. 

March 4th and the system is seemingly working flawlessly up until there was a slight glitch. Numbers stopped moving, the rain was hampering the transmission of feeds to the media houses, tension! In a presser held by the Hassan, chairman of the IEBC, he stated that yes there was a technical issue with  the server but they had resolved the issue. However, 3 days later, the chairman was on stage once again, admitting that there was indeed a bug in the system which was purportedly multiplying rejected votes by a factor of 8! How that line of code found it's way into the system is any ones guess. So let us take a step back. When was this line of code discovered? When was it introduced? Did they have an iron clad change management system which forbid anyone from accessing the production system? If the auditors called in on the between the 20th-23rd Feb did their job, were they so unqualified to miss a rogue line of code? Where are the audit results?

As you ponder on these facts, i'll be back with part two of how this affects both you and I in ways we cannot escape with real examples right here at home...

-ty