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.

Time To Rethink Patching Strategies
Threaded  |  Newest First  |  Oldest First
User Rank: Ninja
12/19/2014 | 11:40:40 AM
Rethinking Patching Strategies
@Kevin E. Greene...

"It becomes nearly impossible for organizations to patch anywhere near 100% when you take into account zero-day vulnerabilities, manual patching, ineffective patch management solutions, the inability to patch critical systems that can't be taken offline, and other factors that impact the operations of IT system environments from heterogeneous environments "
I know that everyone has different challanges, but in my very humble opinion, that statement is the exact reason(s) that patching is not taken as seriously as it should be.

First a comment about CVE that security admins need to know. In January the MITRE is changing the Syntax, or format of the CVE listings to be able to handle the more than 10,000 vulnerabilities expected to come in a single year, as your opening statement pointed out. So I would deficiently recommend looking into that I would add a link but I don't think that's allowed.

So, I want to comment on your statement one point at a time.
  • It becomes nearly impossible for organizations to patch anywhere near 100%

I've been in IT since 1998 and Information Security since 2003 and from my experience nobody expects to get 100% coverage, most do not even try.

  • when you take into account zero-day vulnerabilities

Zero-Day... this is the unknown, and if you're going to patch anything you most likely should consider patching this, wouldn't you agree?

  • manual patching, ineffective patch management solutions

Still, none of these are an excuse or a reason for not patching. If you're doing manual patching on more than 500 systems (and that's way too many) I recommend looking for a new job because you're setting yourself up for failure and use as a scape goat. As for ineffective solutions, I would recommend a solution where the prime and proven focus is patching and not the 10 other functions that come as bundled "features".

  • the inability to patch critical systems that can't be taken offline

Why can't a system be taken offline? If a system is really that critical then most likely you'll have another as backup because if it's contiunally running and never getting ANY maintenance then it will soon decide on its own to stop working, nothing runs forever. And "can't be taken offline" only means that who ever makes the decisions has decided that the business is more important than what makes the business run and really has not considered what will inevitably will happen.
  • and other factors that impact the operations of IT system environments

Other factors, my favorite subject. Senior IT and management folks who do not want to hear about system downtime, how certain users complain because an update may require a reboot, how AV does not catch all of the malware that they allow onto their machines. Are those the "other factors" you speak of?

Again, in my opinion, there should be no reason why an organization should not be able to patch over 90% of laptops or desktop computers and at least 75% of servers. And that takes into account that on a server you mostly are only patching the OS and maybe an application because I do understand that patching a web server or some DB does require more coordination and support from multiple sources, but it can be done... it has to be.

At the organization level where I sit, I can't be concerned with why large software vendors release bad code... I have enough problems trying to get people to understand that we have to protect our systems and our data and a part of that is patching.

"It should be noted that I'm not advocating abandoning patching strategies. However, I am encouraging organizations to put a greater emphasis on developing better quality software."

For companies that develop their own specialized applications I would definitely agree, and hopefully they'll get the right people to do that and respect the results of an audit or QA assessment before rushing to put something into production.

Nice article!
User Rank: Author
12/19/2014 | 1:34:47 PM
Re: Rethinking Patching Strategies
@ODA155 ---Thanks for your comments and response. You make some valid and interesting points. Consider this... what if liability could be assign to software vendors who write bad code. I think companies who acquire software through the software supply chain should care about the software they purchase. Why bring in bad software into your environment? I think it's prudent and imperative to work with software vendors to ensure they are taking the necessary steps to build and design secure systems. With the adoption of open-source, the notion of proprietary software is becoming obsolete because all products have some open-source library, component, or module some where in the code base. Thanks again.. good points!!!
User Rank: Ninja
12/19/2014 | 1:58:55 PM
Re: Rethinking Patching Strategies
@KevGreene_Cyber,... I think liability or holding a commercial company responsible for "their" products would be awesome... it has been done in other industries, automobile manufacturing (GM and Cheverolet have been sued), Smith & Wesson and Bushmaster have been successfully sued for deaths cause by their products, so the only question is who would be the governing\enforcement body?

If we leave it up to those companies would it be tough enough, probably not... and think of the amount of hissy-fits that would happen every minute if the government decided to regulate software development. I believe that it would have to be something like a cross between OWASP, NIST and PCI, and it would need to be fair enough that a small gaming company would be treated as fairly as a Microsoft or Oracle.

User Rank: Author
12/19/2014 | 2:04:02 PM
Re: Rethinking Patching Strategies
Check out Dan Geer's keynote from Blackhat. So...it's being discussed. 😄
User Rank: Ninja
12/19/2014 | 1:13:16 PM
I wonder
I wonder if this sort of strategy, if implemented, will trickle down into game development? There's a real issue in game making at the moment with horrendously buggy products, vulnerabilities, flaws and problems that are coming along with the increase in game complexity and size. Despite years of work, they're releasing as broken messes. 

Do you think a more robust focus on secure practices in the original development would help alleciate problems there like it would with less fun software? 
User Rank: Author
12/19/2014 | 1:29:15 PM
Re: I wonder
@Whoopty ... Thanks, I appreciate your comments. I tend to look at software development as software development, whether it's mobile, web, or gaming for that matter. I definitely believe there should be a more assertive focus on secure coding practices, given that perimeter security disappearing right before our eyes with wearable devices and IoT. There is no silver bullet to security, however, reducing the attack surface and ways in which a system can be compromised starts with secure coding and development. Thanks again KevEG
User Rank: Ninja
12/22/2014 | 12:25:50 PM
Re: I wonder
Thanks for replying. I hope there are some major improvements in security, especially when the potential for damage is so high if someone were to begin infecting IOT devices on a large scale. That and privacy concerns are some of the reasons I just don't touch wearables yet. I'm waiting for the one that champions my privacy over everything else. 
User Rank: Author
12/23/2014 | 8:35:53 AM
Re: I wonder
@Whoopty -- you and me both.  I'm encouraged though.  I know with my Software Assurance program, I'm trying to address the issues by provide technologies, capabilities, tools, and infrastructure to those who are responsible with all aspects of software development. #thereIShope   :)
User Rank: Ninja
12/19/2014 | 1:53:16 PM
Re: I wonder
As a full stack developer turned security professional, I have to admit that much of the problem with secure coding practices is the classic "are you done yet" problem.

Many times, I would give an estimate of completion of a product, to design specs, with security and operations testing.  The management would give a blessing to the project upon those estimates.
Inevitably, a manager (or worse - marketing) person would tap me on the shoulder a third or half way through the project and ask if the timelines could be "compressed". 
In some cases, we would be half way through a project and the product manager would arbitrarily decide to push for a release of the project for a quick market win of some kind.

No matter how much I would jump up and down saying "NOOOOOOO", the decision for an earlier release would go forward with the expectation that any bugs would be resolved in a later patch release.

"Time to market" decision making has a colorful history of applying discounted attention to testing practices, including security testing.

(Disclaimer: This is assuming a development team that knows anything about secure design and coding practices.  I am certain there is a large number of developers out there that do not get proper training/education regarding secure development concepts.)
User Rank: Apprentice
12/19/2014 | 4:50:56 PM
Operating systems need to have built-in mechanisms
Windows has software restriction policies, just as GNU/Linux has SELinux.  People need to start using these technologies to help fight malware.  It's easier to shortcut or disable these security mechanisms, but admins need to take the time to learn them and use them as designed.  This will help prevent the spread of malware at the OS level.  Operating systems are better than ever, but will only help to fight malware if we use them and set them up properly.
User Rank: Author
12/20/2014 | 10:21:52 AM
Re: Operating systems need to have built-in mechanisms
@Chris_Clay -- that would definitely help.  Access control policies, configuration management, and system hardening are all strategies that should be implemented correctly to fight against malware.  But keep in mind that there are other attack vectors as well that try to exploit poorly developed software.  Thanks for you comments 
User Rank: Ninja
12/22/2014 | 12:11:24 PM
This is not the first request for better quality in software with the goal of better security. Yet, when looking at all the trendy IT jobs lists and predictions for 2015 and pay rates of IT jobs and whatever else gets analyzed and listed, one profession and area is always absent: Quality Assurance!

Plenty of companies consider it more important to release features than quality. When it comes down to cutting implementing a new feature or properly testing an already implemented feature, testing will ALWAYS be cut.

Any manager can easily make the case for hiring more developers, hiring more QA or BA (those who should request secure systems in the first place!) positions is much more difficult. Top management comprehends that more developers will crank out more code with more features that sales can sell to make money with. What they often do not comprehend is that it will cost a lot to fix all the untested stuff once it is deployed. It is as if the gazillion papers, studies, and books written about testing and fixing early in the process just do not exist.

Why is that? Well, there are two reasons:

- customers value features more than quality

- companies consider dealing with breaches to be less expensive than keeping quality and security high

Demanding that software vendors make better quality software should always come with the acceptance that there will be either less features or higher prices. Anything else is just wishful thinking. As long as customers are not willing to make that sacrifice and rather keep patching the patches I do not want to hear any complaints about quality and security. If you, the customer, do not value quality and security, then why should we, the vendors, spend time and money on it? There is just no return on investment and in the end we only make software so that we can sell it for cash (or in case of FOSS sell services).

As long as even massive breaches like those at TJ Maxx, Home Depot, Sony, Staples, etc. are nothing more than headlines for a few weeks and a blip in the footnotes of the quarterly report absolutely nothing will change. With revenue in the tens of millions spending a few million on apologies, free credit monitoring, and some petty fines is nothing else than cost of doing business, like renting retail space or paying for online ads.

I don't even think that legislation such as mandatory software warranties will change much. As long as the masses of customers embrace mediocre applications and consider a text based user name / password combo 'security' any well-meant demands for better quality are pointless, if not ridiculously removed from reality.
User Rank: Author
12/23/2014 | 8:33:19 AM
Re: Quality?
 @moarsauce123-- you  bring up both good and interesting points.  When a software breach hits home, meaning when our personal lives are impacted, you will start to see this mindshift... Actually, we are starting to see some signs of things shifting.. There has to be a greater emphasis on improving software quality, improving software development, and improving the tools that are used to analyze software for security and quaility issues.  They all go hand in hand.. Thanks for your response.   enjoy the holidays!!!
User Rank: Apprentice
12/26/2014 | 2:31:22 AM
Excellent Perspective of Patching
A well written article with a entirely fresh and different perspective of Patch Management , a pain point of many organizations. It is time we think of unconventional and out of the box strategies to close the gap between discovering a vulnerability and patching it up. 

In some cases internal fixing can also be recommended , instead of waiting for a fix by the Vendor themselves

I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file