Information Security Matters: Are Software Flaws a Security Problem?

I suspect I share with many readers of the ISACA Journal an annoyance with customer service people who tell me that they cannot give me any information because the system is down. I am always tempted to yell at them, “That’s a terrible excuse! Your systems should not be down.” But, hey, the person on the phone is not at fault, so I keep my mouth shut.

But who is responsible? If a hacker caused customer-facing systems to crash, we would think he/she was a criminal. But if an employee in the programming department implements faulty code, we shrug and say, “Oh, well, that is the way computer systems work.”

In a recent article in this space that I called “Microwave Software,”¹ I stated that “ultimately, flawed software cannot be secured.” My point then was that antiquated software is often the weak spot where cyberattackers take advantage. The more I thought about nonmalicious system downtime, the more I became convinced that systems that fail are themselves insecure, regardless of the intent of the person responsible.

I cannot overstate the number of times I have seen program crashes that caused late-night phone calls, emergency patches and nervous vice presidents. I ruefully admit that I was a terrible programmer in my early career and often was the recipient of those phone calls. Was I a security threat? I would say that, yes, I was, and I resolved the problem by never coding for a living ever again. But what about all those who are still at it and are still putting broken programs into production? Many of the causes of unexpected downtime that I encounter are the same as those that lead to security breaches, as the term is more commonly understood.

Complexity

Edgar Dykstra, perhaps the greatest theorist of programming who ever lived, was famous for writing that it was impossible to prove that any but the simplest programs would work. “The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.”² If, indeed, Dykstra was correct, then any organization that implements enormous, highly complex systems is, in fact, introducing the possibility of error into its value chain. Application and infrastructure systems are engineered products, which are bound to fail at some point—the concept known as the mean time to failure (MTTF). I am not aware of any organization that attempts to calculate the MTTF of its systems prior to putting them into production. So the business users who rely on the systems are, in effect, involved in a crap shoot. To me, this is a security problem.

Ineffective Interfaces

Despite complexity, most applications and infrastructure software work as intended most of the time. That is because whoever wrote the programs (most often a software vendor these days) was able to test their functioning to a generally acceptable extent. (Please spare me the horror stories of vendors using customers for beta testing. That is simply bad practice and is inexcusable.) However, applications interact with other applications and infrastructure.

They require interfaces to exchange and jointly use data. It is extremely difficult for programmers (especially, but not only, software vendors) to know all the other systems with which their programs will interface, now or in the future. Since interfaces connect two disparate systems, the programmer of the interface may be insufficiently knowledgeable about one or the other systems, or both. When interfaces themselves are poorly designed or written, programs fail. Hackers know this and attack the interfaces.³ What difference does it make, in terms of security, if systems abort or mismanage data due to error rather than malice?

Failure to Understand the Data

When I was a young and very inept Cobol programmer, a mentor said to me, “Kid, get the Data Division right, and the Procedure Division will take care of itself.” Cobol has gone the way of the dodo bird, but his advice has not. Programs, like security, follow the data. When a programmer does not understand all the implications of the data that a program affects, the results can include database integrity failures, incorrect calculations or orphaned records. Any of these, and many other data errors,⁴ can cause a system to falter or stop.⁵ If a database can be infiltrated with errors in this manner, it is not secure.

Poor Change Control

Let us posit for a moment that a program might indeed be perfect at the time it was put into production. Then, it is changed. It is not particularly original to observe that poor change control leads to problematic programs. I would argue that it also leads to insecure programs. Perhaps it is in the nature of change control itself. In an excellent article, Edward Stickel suggests that change control by itself “is not sufficient to cover all the necessary factors and tasks in making well-advised decisions on changes and implementing them effectively.” Further, “because the value of the change control process is not apparent to the parties involved, it is seen as a superfluous, bureaucratic exercise and is not taken seriously, which results in poor compliance.”⁶ I would only add the words and security to the end of the previous sentence.

Change Management and Quality

Program failures and security breaches are related, but not equivalent, risk factors. The first stems from incompetence, the second from malign intent. They both can create damage. Is it worth arguing whether fools or felons do the most harm? From my perspective, it is sufficient to know that risk exists and to build safeguards to protect against both.

It has long been a programmer’s joke that users want systems to be developed fast, good and cheap; they can have two, but not all three. Who implements in haste repents at leisure, and it is always true that you get what you pay for. To my mind, both programs and security must be built with quality as the foremost design criterion.

Perhaps the best way to achieve quality in both systems and security would be to start fresh with totally new applications with all the latest security techniques. This is a luxury that is unavailable to any organization of which I am aware, except for start-ups (which usually have neither the time nor the money to afford quality). Since all new applications and safeguards must be introduced into existing environments, change management is the core of quality assurance.

I said earlier that one of the causes of flawed programs is poor change control. Change management is protection of a higher order. The first is a matter of procedure. Change management, however, begins with the rationale for change and, while including formal processes, promotes business benefit while minimizing the risk of disruption of services.⁷ Effective change management leads to higher quality in all endeavors, including both programming and information security.

Endnotes

¹ Ross, Steven J.; “Microwave Software,” ISACA Journal, vol. 1, 2015, http://h04.v6pu.com/resources/isaca-journal/issues. I was referring to software that is as old as my microwave—not as good as the new devices, but good enough for my needs.
² Dykstra, Edgar; Notes on Structured Programming, (EWD249), Section 3, April 1970, p. 7
³ For just one example, the Target cybertheft in 2013 occurred at the interface of programming on a point-of-sale device and on a server on the retailer’s network. One source states that “the average retailer has seven infections [presumably annually] communicating out from its network.” Lemos, Robert; “Target Breach Involved Two-Stage Cyber-Attack: Security Researchers,” eWeek, 21 January 2014, www.eweek.com/security/target-breach-involved-two-stage-cyber-attack-security-reseachers.html
⁴ See “What Data Errors You May Find When Building A Data Warehouse,” www.dwinfocenter.org/errors.html.
⁵ The most infamous such data error was the Y2K bug. Today, people think that the whole thing was a hoax. They do not realize the billions of staff hours that were required to make sure that the bug did not bite. Was that a security problem?
⁶ Stickel, Edward; “Change Control vs. Change Management: Moving Beyond IT,” Technology Executives Club, http://www.technologyexecutivesclub.com/Articles/management/artChangeControl.php
⁷ Ibid.

Steven J. Ross, CISA, CISSP, MBCP, is executive principal of Risk Masters Inc. Ross has been writing one of the Journal’s most popular columns since 1998. He can be reached at stross@riskmastersinc.com.