Why Patching Software Is Hard: Organizational Challenges

Second of a two-part post.

My last article about why patching is hard explained some of the technical challenges related to patching software in large organizations. That people don't patch software isn't purely a technical problem, however.

In instances like the Equifax breach, it's understandable to try to assign blame, but the reality is there are many organizational challenges preventing best practices. To solve the problem and not just point fingers, companies should look at the teams and individuals involved with patching and identify potential blockers. The following is a list of the roles that may be involved in patching, and what challenges they may face.

The CISO
CISOs have a hard job. They must push for security, but not too hard because the company may let the CISO go if requirements are "blocking business initiatives." On the other hand, when a breach occurs, the company blames and fires the CISO (or the CISO leaves knowing that getting fired is inevitable). When executives hire CISOs, they may ask questions to make sure the CISO is "reasonable" when it comes to security, meaning that he or she won't be too insistent on stringent security policies. I doubt the CISO failed to tell the company to patch software. The question is, did the CISO document the recommendation and the company's response to that recommendation?

The Security Team
At many companies, the security team makes policies and recommendations but may have no authority to enforce them. Security professionals often handle security appliances and act as auditors but cannot make any changes to networks or systems that run applications. If the security team didn't recommend that the business install the latest software patches, or had the authority to enforce or implement patching and didn't do it, then perhaps they were to blame. Often this is not the case.

The IT Team
Some have suggested the system administrator should have just installed the patch. At a large company, system administrators can't just install software to production whenever they want. They must follow a change control process that includes steps and levels of approval that vary depending on the activity and affected systems. Requirements may include scheduling a deployment window and defining a rollback plan if the change introduces the risk of downtime. Compliance and federal regulations mandate this process in some industries.

Software Developers
The security team and system administrators may not have been aware of what software versions the developers were installing. The team that deployed the original application may have been working on a different project when the creators of the flawed software released the patch. Some developers don't know what a CVE is (that is, a common vulnerability exposure), let alone every software release for libraries in their applications. Development teams are usually under a lot of pressure to release projects quickly. They must implement the prioritized tasks assigned to them by product managers and business owners. They won't want to risk creating a production bug that creates considerable losses, delays the project, and puts their job at risk.

Product Managers and Business Owners
Assignments to create or change software starts with approval from a group of people who review the list of proposed projects and decide which ones get funded. Often this group is devoid of security professionals and consists of businesspeople focused on revenue-generating or cost-saving business goals. The rewards this group receives are based on delivery of projects in a specified timeline and budget, and the faster the better. Deploying new software versions delays deliverables, so they have no incentive to prioritize this work.

The CEO
Did the CEO know the status of patched software and system inventory throughout the company? He should have. CEOs look at all types of financial and operational reports. Just as CEOs need to understand financials, they should review internal and external reports to understand cybersecurity metrics. Understanding the top threats, defenses, and detection mechanisms will help CEOs create business goals that ensure the company is performing essential security tasks, like patching software. CEOs, top executives, and board members can take cybersecurity classes from experienced and qualified cyber organizations or individuals.

Security Is a Matter of Priority
Do businesses know that patching software is critical? They do now. Why aren't they doing it? Patching needs to be a priority. It takes time and money from other important projects that offer more immediate and visible value compared to protection against a potential threat. Companies praise teams for completing projects quickly, despite obvious security problems. When is the last time you heard a CEO stand up and praise a team in front of the whole company for patching software? Companies need to do more than talk about security; they need to implement measurable business processes that truly make it a top priority.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.