It did not surprise me that the second indictment after Bernie Madoff charged his software developers. To succeed as the wizard of lies, the title given to him by Diana B. Henriques in her new book, Madoff needed to create digital information that was accepted as evidence of the truth. No matter how gracious he could be as a salesman, investor or executive, the data had to be convincing. And we know the rest of the story. The software itself served up convincing presentations but was, itself, designed to deceive.
I have not had the time to fully investigate all of the fine reporting done by others; I look forward to doing so. But I am fairly confident that the SEC’s failure in this case, and a persistent weakness in continued operations, is the absence of rigorous rules-based review of software integrity. Software that is properly designed, with solid documentation, that can be evaluated by auditors, should be the essential requirement for doing business in a regulated space.
The shift being suggested is, perhaps, significant. The records of a business have long been the focus of regulatory supervision. But we have come a long way from the anecdotes of two sets of books under the counter—one for the accountant and one for the government. Instead, government, to serve the public mission, must develop rules for the systems themselves from which records originate. Focusing on security is useful, but Madoff and his developers demonstrated that the strongest perimeter cannot truly provide trusted records. Instead, we must recognize that the inability to see how systems are designed, to understand how code is authored, and to validate the integrity of the resulting reports and data—all of these current conditions degrade trust.
But, even without public sector regulation, our own business interests should compel the same result. Our businesses demand reliable and trustworthy data on which we can make business decisions. As cloud services continue to tempt companies, the reality is that the service providers themselves degrade trust by not taking seriously the need of their customers to be able to assure that their data, once mobile across the cloud, must retain the same trusted attributes as the data holds within a corporate system.
So, whether sourcing from cloud providers, software applications (commercial or home-grown), or yet-to-be-invented solutions offering further economic efficiency, we fail to discharge our obligation to our investors, shareholders and customers if we do not learn from the lessons of Madoff and insist upon greater transparency in knowing the structure and function of the systems and services from which the data is produced.
Earlier this week, I presented a webinar for ISACA and Searchcompliance.com on developing a cloud strategy. The central theme: demand that the service be performed against known rules, for which compliance is integrated into the contract. In other words, “trust . . . but verify.”
Over 1,200 people around the world were actively logged in. At the end of my remarks, I offered that if someone wanted the RitterMap I had used, send me an e-mail. Astonishing—over 250 requests, and from corporations and organizations whose names are immediately known, flooded in (in a good way)! So, if you would like to obtain the same RitterMap, send an email to email@example.com requesting the RitterMap on Developing a Cloud Strategy.