subscribe: Daily Newsletter

 

Risk management in government: Protecting government

0 comments

A few days ago, a friend told me what happened to her when she attempted to register on the Department of Labour’s UIF uFiling web site as an employer (www.ufiling.co.za), writes Andrew Stekhoven, MD of Escrow Europe. According to her, she just didn’t immediately ‘click’ with the site but was very ably assisted by the call centre when she phoned in for guidance.

“The site,” she says “is a revelation. The Department should be very proud of it. It works so quickly, and so smartly, too. All the while I was entering information here and watching calculations take place there, I couldn’t help thinking what brains the developers must have.
“And then I had a ‘Westworld’ moment – remember that 1973 movie in which Yul Brenner played a robot-cum-cowboy and nothing could ‘go wrong, go wrong, go wr……? What would happen to all that functionality and all that information if an undetected bug in the system (software is never bugfree or complete) causes it to crash.
“What would happen if the software developers were no longer available to effect critical fixes and get the system up and running again. This is not such an unlikely scenario as it may seem – think developer bankruptcy (look what happened with Fidentia), think developer gets bought out by a richer a competitor that refuses to continue maintenance of the software, etc.
“What then? What happens to those, for instance, who are depending on their unemployment payouts to live, how do those employers who have dutifully made their contributions year-in and year-out prove that they have?”
The fact is, no matter how well-designed or well-protected an information system is, there is always risk. And given that IT systems and the information they hold – never mind the hardware on which they reside and through which they can be accessed – are major assets, Government should do everything in its power to minimise the risk.
In Europe such initiatives are already well under way, for instance, Fedict, the Belgian Federal State Service for Information and Communication Technonolgy elected to utilise active software escrow to secure, in all circumstances, the use of the software it utilises to deliver e-Gov services.
And it is worth our South African Government’s while to investigate how it, too, could manage its risk by escrow.
Fedict’s software applications, as well as those developed by Fedict for other Federal Government Services, are today ultimately essential applications whose use in the e-government services must be guaranteed in all circumstances.
Continuity of e-gov services to citizens, civil servants and enterprises is very important. The escrow service is just one of the measures taken within a global framework to ensure continuity of these IT services.
In terms of the Fedict agreement, Escrow Europe’s Belgian operation , acts as a neutral, independent third party that, in certain circumstances, will release the latest version of licensed software held in escrow to Fedit to that their continued use of the software is guaranteed.
Currently, all software suppliers to the Federal Government are subject to this escrow arrangement – they cannot do business with FEdict unless a complete set of source code, with the relevant technical documentation, has been lodged in escrow nominating Fedict as the legally entitled escrow beneficiary.  In this way, Fedict is able to guarantee the continuity of its technology dependent services to its stakeholders – the taxpaying public.
A new booklet, available in PDF format from The South African Institute of Directors (IoD) or via email from info@za.escroweurope.com , highlights everything chief information officers – be they employed by Government or the commercial sector – need to know about IT governance and active software escrow.
Compiled by Escrow Europe with input from Michalsons Attorneys and senior lecturer in Private Law at the University of Pretoria, B Prozesky-Kuschke, the booklet is intended for CIOs, their boards of directors and senior management of organisations who are:
* Subject to, or embrace the provisions of, the King II report on corporate governance
* Obliged to be compliant with Sarbanes Oxley legislation (Section 404).
Its aim is to assist them identify what constitutes professional, or active, software escrow as well as why active software escrow is a very necessary business tool for all organisations that are dependent on information technology.
The booklet also provides hints on how to fast-track active software escrow and guidelines about the costs associated with it.
Possibly most important is the section providing four compelling reasons why active software escrow is a necessity in South Africa.
* Reason 1:   Active software escrow facilitates compliance with corporate governance imperatives. The objectives of active software escrow are rooted in promoting ICT good governance, and take cognisance of the fact that suppliers and their licensed end-user can be proactive in complying with current protocols and quality standards such as (King II, Basel lI, ISO9001, South African National Standard ISO/IEC17799, COSO, COBIT, ITIL, Sarbanes Oxley etc) etc.
* Reason 2:  South African law currently does not provide for the protection of, and access to, software source code in the event of software supplier insolvency. The Roman Dutch Law concept of ‘deposit’ (depostium) is part of South African law whereby a person delivers something to a third party for the purpose of safe custody and the latter either gratuitously or for reward undertakes to take care of the thing until certain circumstances agreed between the two principal parties occur.  According to B Prozesky-Kuschke BLC LLB, Senior Lecturer in Private Law at the University of Pretoria in her article “Depostium and Escrow: The Current Application Regarding Computer Source Code in South African Law”:
“The classic principles regarding depositum need to be adapted to suit the needs of the parties involved in an arrangement for the protection and access to source codes. As no case law or proper legislation is currently available to show the way, the best solution remains to regulate the relationships and provide for specific eventualities by concluding proper, watertight agreements in this regard.”
South African Courts have not yet dealt with the use of software beyond insolvency on the part of the software supplier. While an escrow agreement will not solve all the problems associated with the insolvency, it will allow the user an opportunity it would not otherwise have for continuing to make use of the software, that is the user would be able to continue to use the software based on the terms and conditions of the prevailing license agreement and, most importantly, be able to maintain and support the software for the purposes of business continuity in the absence of the software supplier.
* Reason 3:   Active software escrow bridges the source code-object code divide. When it comes to object code-source code, the issue is this: What would the impact be on your department if you spent R5-million to license some software that is integral to your business’s day-to-day, mission-critical operations but the company you paid closes shop leaving you with R5-million worth of “orphaned” software? Would you then be interested in the difference between object code and source code?
Simply put, when your department licenses software, it more often than not gets a licence to use the machine-readable ‘object code’ but not access to the ‘source code’, which programmers read and work in.
If the software supplier is unable to support your software for any reason, the only way you can fix any problems or make any enhancements you need is if you have guaranteed access to the source code via your active software escrow arrangement.
* Reason 4: Untested or passive escrow deposits are often useless when called upon to deliver what they promise – business continuity in the face of the software supplier’s inability to continue supporting its technology. The ‘passive’ approach to escrow or intellectual property custodianship involves simply ‘holding’ the material; active escrow involves both holding the material and verifying it to be usable in terms of the escrow agreement between the software supplier and the end-user.
Professional escrow agents offer several levels of technical verification and reporting depending on how mission critical the client considers the business application to be. A review of the need for verification completed by a leading international escrow agent, recently reported that nine out of every ten unverified deposits, that is, passive source code deposits, would have been useless.
The reason why nearly all these deposits failed to meet the verification criteria immediately is not because the lacking components are non-existent or that every software supplier makes a mess of the deposits, but because today’s software environments are complex and software suppliers are often too busy to spend the time that is really required for creating a quality deposit. In fact the main reason is that they simply forget and/or overlook the deposit of small but important components.
However, bearing in mind that these deposits were historically held in passive escrow, the findings are very frightening – they suggest that businesses making use of passive software escrow would have, at best, experienced severe difficulty in using the material released in keeping with the terms of the agreement should anything happen to force it into play. At worst, the deposit would be entirely useless. Without proper technical verification how would you know?
This essential guide shows that today’s CIOs need to carefully consider the points made above as, despite their diligence in insisting that escrow agreements are in place for all of their mission critical systems, the actual escrow deposits may be of little or no value.