Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10/25/2017
10:30 AM
Teri Radichel
Teri Radichel
Commentary
50%
50%

Why Patching Software Is Hard: Organizational Challenges

The Equifax breach shows how large companies can stumble when it comes to patching. Organizational problems can prevent best practices from being enforced.

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.

 

Teri Radichel is CEO of 2nd Sight Lab, providing pen testing, security assessments, and research. Her career started in telecommunications and networking in 1994. She gravitated to software programming, having learned BASIC from a book in grade school. After obtaining a ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12512
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated reflected POST Cross-Site Scripting
CVE-2020-12513
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated blind OS Command Injection.
CVE-2020-12514
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a NULL Pointer Dereference that leads to a DoS in discoveryd
CVE-2020-12525
PUBLISHED: 2021-01-22
M&M Software fdtCONTAINER Component in versions below 3.5.20304.x and between 3.6 and 3.6.20304.x is vulnerable to deserialization of untrusted data in its project storage.
CVE-2020-12511
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to a Cross-Site Request Forgery (CSRF) in the web interface.