Just like all other standards and laws, forcing IT to come up with standards industry-wide will come when the “cost” is too high to ignore and someone is made a political scapegoat. Is this scapegoat Equifax?
In IT we use frameworks and libraries to streamline reusable work. It is like the plumbing industry today. The plumbers don’t make the pipe and fittings. They have come up with standards on materials, testing, and quality control standards so that materials can be mass produced and projects can be done in hours and not days. This is similar in IT. Frameworks, like Apache’s Struts and Pivotal’s Spring, help streamline the underlying coding infrastructure to allow IT to produce more projects at a faster rate. But unlike the plumbing industry, the IT industry makes assumptions that cause more harm than good.
For example, Equifax used Apache’s struts, which left their websites vulnerable to CVE-2017-5638 for at least four months after a fix had been issued. This would be the equivalent to a manufacturer recall on a water heater. The plumbing industry gets the notification and they work with customers who have the recalled water heater installed. Typically, if the paperwork has been filed with the manufacturer, they also contact the customer to let them know about the recall. If the consumer chooses to ignore the manufacturer and the installer and there is a catastrophic failure and the water heater explodes, at least the consumer made an informed decision not to fix the water heater. But unlike the plumbing industry, the IT industry does not necessarily know who is going to be affected. There has not been a monetary or reputation analysis for a breach.
Apache Software Foundation (ASF) issued a statement on September 9 regarding the breach at Equifax. Equifax is trying to patch, notify, and do damage control. Who is to blame? Staying with our plumbing example, the manufacturer and the plumber would work out the issue and share the cost of a fix, not necessarily equally. However, in IT, we play the blame game. If you take the time to read the post issued by the ASF, you will see that when the problem was identified they issued the Common Vulnerabilities and Exposures (CVE). This is only one part of a “recall” or CVE. We are missing defining standards on the action to a CVE. We need a standard to define a way to take a CVE, identify where the issues exist, and quickly fix or patch the problem areas.
Let’s talk a little about the two major distribution models. I will use Apache and Pivotal as the examples. This is not to say one is better than the other. I am not trying to start a flame war. They are just examples of each of the school of thoughts. I am going to use the ASF as an example of a non-commercial product model and Pivotal as a commercial product model. With the ASF model (non-commercial), the software is well documented and freely distributed without registration. This means that when there is an issue with the framework the issuance of a public CVE is about all that the ASF can do about notifications to the consumers of the framework. With the Pivotal model (commercial), the company has registrations of its product consumers. This means that the Pivotal company can communicate directly with their consumers of their framework. It is similar to the warranty cards that manufactures send with the products that we buy. We let them know how to contact us in case of issues with the products we buy. I am not saying either way is better or worse but we do need to come up with a standard that supports both delivery models.
Now that we have talked about the frameworks announcing issues and issuing fixes, we need to discuss the consumers of the frameworks’ responsibilities in fixing software using these frameworks. This would be like a plumber being notified that a hot water heater has a pressure value issue. The manufacturer has issued the problem and fix but now the plumber needs to do the work. As the plumbing company, we would have two possible actions. The first would be to go out and fix all of the issues with our customers. The second would be to ignore the problem and hope one of the hot water heaters did not explode on one of our customers. Most of us, would see how the second one, although a valid response, would not be morally and, more important to most companies, legally right. However, in the IT industry, we have not really addressed the elephant in the room. We have not set ourselves up to respond and quickly resolve issues in frameworks because of many reasons: we are to busy being reactive to the demands of our company; we see ourselves as victims of others code; we think the issue isn’t a big deal; we think it will just fix itself with our next release; and many more that just boil down to ignorance or laziness. We are at the point in IT where we need to come up with better ways to serve ourselves and our consumers.