As the story and forensics behind the Equifax breach continues to unfold, directors can dissect what went wrong, who knew and what could have been done about it. What questions should you be asking at your next board meeting?
At the top of the list, “are we a target?” The truth is some companies are bigger targets than others. Equifax would certainly fall into the category of a big target because of the sensitive and valuable information it keeps about so many people. Other companies in finance, energy, health care and e-commerce based business are all also in a tier one target zone, meaning they are a likely target because hacking their systems can cause mass disruption to society or allow the greatest ability to commit fraud and transfer funds from the hack based upon the information those companies house in their systems.
However, every company should be concerned about not just if, but when an cyber attack occurs. We know that sixty percent of most cybersecurity breaches are small enough that they are never reported to senior management. But, a small break in is just a symptom that a big one could be coming because hackers may be testing your system for weaknesses or laying the ground work for a larger attack. We’ve now learned that Equifax had already experienced breaches and not taken appropriate measures or informed the public. While the ethics of that decision should surely be debated, let’s focus for now on what caused the breach.
The Equifax breach was a result of a failure to patch open source code that was used for one of their major systems. This would not have occurred if a fully functioning open source compliance and patching program was in place. In case you are unfamiliar with open source code, open source is a type of software code made available to the public so that the developer community can share, use the code and build upon it freely and without licenses. It is typically designed to provide a greater good in software development. Most major technology companies put out open source and use open source. Without going too deep, there are many rules that govern how open source code is used. But, the number one cybersecurity rule to use open source is that you have to monitor patches of the corrections to bugs that are discovered. Because open source code is public and open to use, hackers access the code and start finding weaknesses. Usually the good guys out there also find those weaknesses and post “patches” or code that fixes the weaknesses. It’s an endless ongoing, never ending cycle that absolutely must be critically and painstakingly maintained. This is the starting point in learning from this event. Consider the following questions to ask of your executive leaders:
· Does your company use open source code?
· If so, for what types of activities?
· Is there an open source compliance program?
· Who enforces the program?
· Who checks the enforcement of the program?
· Is the use of open source tracked?
· How frequently are you patching bugs?
· Who is responsible for monitoring the daily updates for any open source used?
· Were other means available to accomplish the same objectives without using open source code?
· Why was the decision made to use open source code? Does the benefit outweigh the risk?
These are just a few questions you might want to be asking of your senior executives. And, you should not just ask your Chief Information or Technology Officer. You should be cross checking senior leadership by also asking your Chief Legal Officer how the legal department monitors and enforces compliance with open source code. You should also ask your head of digital or marketing, depending upon how your organization is structured, because many times development of digital activities may occur independent of your technology or IT group. This is where the gaps can occur or form across the organization. It is not uncommon for one part of the company to potentially be using and deploying open source code for a specific project with other parts of the company completely unaware. Sometimes projects are formed in small subsets of the company and they may be using the same open source code as a different group in some other part of the company and may or may not be managing it the same way. Are they tracking it in the same way? Are they sharing resources? You may be surprised when you start asking these questions.
Beyond ensuring your company has an open source compliance program there are many best practices to consider to evaluate the health of your organization’s cybersecurity readiness. Much like you have an independent audit of the financials, an independent audit of cybersecurity exposure points is essential. I cover this in more detail in chapter three of my book, Digital in the Boardroom, including a complete audit checklist.
If you are interested in learning more about Digital Oversight for Boards and what questions to ask about cybersecurity risk or digital threats, contact Jen Wolfe at jwolfe@consultwolfe.com.