Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-1142PUBLISHED: 2023-03-27In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use URL decoding to retrieve system files, credentials, and bypass authentication resulting in privilege escalation.
CVE-2023-1143PUBLISHED: 2023-03-27In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use Lua scripts, which could allow an attacker to remotely execute arbitrary code.
CVE-2023-1144PUBLISHED: 2023-03-27Delta Electronics InfraSuite Device Master versions prior to 1.0.5 contains an improper access control vulnerability in which an attacker can use the Device-Gateway service and bypass authorization, which could result in privilege escalation.
CVE-2023-1145PUBLISHED: 2023-03-27Delta Electronics InfraSuite Device Master versions prior to 1.0.5 are affected by a deserialization vulnerability targeting the Device-DataCollect service, which could allow deserialization of requests prior to authentication, resulting in remote code execution.
CVE-2023-1655PUBLISHED: 2023-03-27Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to 2.4.0.
User Rank: Ninja
12/19/2014 | 11:40:40 AM
"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.
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.
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?
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".
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.
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!