Where Cybersecurity is Broke(n)

The title of this piece was adapted from a section heading in Dr. Gary McGraw’s article with the title “The New Killer App for Security: Software Inventory.” McGraw’s article originally appeared in IEEE Computer, Vol. 51, No. 2, 2018, and was reprinted in the June 2018 issue of IEEE Computer Edge magazine. He used the term “broke” in its light-hearted slang context to mean broken. But there is perhaps reason to use the term in its other meaning, namely, bankrupt. No, the industry is not going bankrupt—far from it. It prospers with each data breach. But it may be bankrupt with respect to creating new, effective means to control the explosive increase in successful cyberattacks.

But let’s return to the McGraw article and add a little personal background. Gary McGraw is undoubtedly a leading pioneer in the field of secure coding, a.k.a. application software security. I first met him in the mid-1990s. A salesman from Cigital, where McGraw served as its Chief Technical Officer, was on my case about the importance of application security. Having managed many security-critical software development projects, I was sympathetic to his pitch, and we agreed that we should set up a meeting with Dr. McGraw. Unfortunately, the topic generated very little interest among developers at that time. A few years later, application security became a much hotter area and a subsequent training session held by Ken van Wyk, another application-security luminary, played to a packed house with groups logging into the webinar from India and Europe. What made the difference? Funnily enough, it was because firms for whom we did trade processing were asking us to demonstrate that our applications, which they used directly or which we used on their behalf, were secure. They, in turn, were under pressure from U.S. financial regulators, particularly the OCC (Office of the Comptroller of the Currency), to show that they had performed due diligence regarding the application security of their suppliers.

Also, in December 2001, OWASP (Open Web Application Security Project) was formed with its vibrant, rapidly-expanding membership and ground-breaking projects, validating the emergence of application security as a key area of concern.

While I was promoting application security within my own organization, I was also active in the banking and financial services sector’s SIA (Securities Industry Association), now SIFMA (Securities Industry and Financial Markets Association). SIFMA absorbed the Financial Services Technology Consortium, to which I consulted. Our Software Assurance Initiative (SAI) was tasked with establishing an industry-sponsored lab to test, and possibly certify, popular application and system software packages. However, the concept didn’t gain much traction as larger financial firms and security vendors did not support an idea that threatened the comparative advantage of the former and the revenues of the latter. Nevertheless, it remains an important concept whose time has still to come, but surely will, as evidence builds on the increasing vulnerability of software.

There was a subsequent project sponsored by the financial services industry (FSSCC-FBIIC) and run by the Supply Chain Working Group. Dr. McGraw was an advisor to that project, which attempted to inventory all software, hardware and services used by firms to determine leading-edge security practices that could be adopted universally. The initial surveys, which received good responses, asked for internal data that was readily obtainable by senior security staff. The data covered the following areas:

  • Internally-developed software
  • Software developed by a third party
  • Software purchase off the shelf
  • Hardware, firmware, appliance

However, the project hit a roadblock when firms were asked to list their own software and services, the inventories of which were not readily available in most cases, and those of their third-party providers, who didn’t see why they should share such information if they weren’t obliged to. In many cases, firms had compiled accurate and comprehensive software inventories as part of their Y2K mitigation projects but had unfortunately not kept the inventories up-to-date. Shame on them!

So, where does all this background stuff fit in? It goes back to the McGraw article, mentioned above, in which he encourages the building of software inventories as an important way to improve cybersecurity. After all, to paraphrase Lord Kelvin’s quotation on metrics, you can’t be expected to fix that which you don’t know exists. Of course, that makes perfect sense. Except for one thing. It is well nigh impossible to list all software and services within not only your own domain but especially within the domains of your suppliers … and their suppliers, too! Believe me, I went through it and I know of what I speak.

In one sense, I am surprised that it took Dr. McGraw as long as it did to formally recognize the need for accurate, complete, up-to-the-minute software (and firmware and hardware and services) inventories since, besides his involvement in the above financial-services initiatives, he was so instrumental in developing BSIMM (Build Security In Maturity Model) into a treasure trove of information about the leading security practices of major companies. But I’m glad that he has now stated in print how valuable such inventories can be. Still, we need to find a way to collect the data that is cheap and anonymous and yet accurate and complete and which serves to enhance the security of those who need it most—which is essentially everybody.

McGraw concludes his article with the following sentence:

“Unless you want to be the next data breach headline, develop and maintain an inventory of all the software, including open source packages, that your organization uses.”

Brave words, indeed, and an appropriate call to arms. But you also must recognize the need to know what software your suppliers use. They likely will not want to share such information, so that a trusted third party will have to be recruited to collect, manage and secure such data. But just think of how far ahead we would be with such information readily at hand.

There are a couple of prospective approaches that could take us much further along the path to full knowledge of all the software that might affect an organization. Some I have discussed before in presentations and articles, especially with respect to software supply chains. Others are new. Innovative approaches may be greatly enhanced by recent advances in big data and analytics technologies. But more on that another time.

Post a Comment

Your email is never published nor shared. Required fields are marked *