Real life impact of outdated Software components?
BWC
Cybersecurity Overlord ✭✭✭
Hi,
while doing some research, I (not being a security researcher) came to a point asking myself, how harmful it would be to run commercial software built on outdated software. There are a few research ariticles out there, but how about real world impact?
Is it OK from a technical (security-wise) or legal standpoint (liability as an implementer or seller) to lets say (as a hypothetical example) run a system with a Linux Kernel 3.1.0 providing some form of Web Services publically available? Considering the fact this Kernel is becoming 10 years old and is EOL since January 2012 (9 years ago). Not mentioning any other parts of the solution who became, let's stay, a bit dusty. Due to the lack of technical knowledge I can't say if any known issue since than got backported into this.
Common sense and experience raises alarms, but I would like to know what the rest of the security minded Community is thinking about it.
All the best, stay safe and secure.
--Michael@BWC
P.S.: Happy anniversery to me, 1 Year SonicWall Community as of today 🍾
Comments
Happy anniversary @BWC :)
Hi all,
maybe to put my question a bit in perspective and to fuel your opinion making process. I would really love to hear.
--Michael@BWC
Ah, stirring the pot, are we?
There are undoubtedly hundreds of obsolete OS versions running scores of applications that are never, ever, going to be patched.
Is it safe to run those apps? No.
Will people continue to use those devices and apps? Yes.
Will miscreants invest the time and energy to identify, locate, and build the requisite attack vectors to harm those who use those systems? Maybe. But only if it is profitable or can cause sufficient disruption.
Another question to ask: Who benefits by continuing to use vulnerability-ridden software? Hypothetically, of course!
What a delightfully loaded question!
First, define harmful. Who is receiving the harm? Does harm include risk?
Is it OK from technical or legal liability standpoint?
NIST's CSF and plenty of other security frameworks would help you decide.
Really it sounds like you want advice if you should take the project / client. Say no.
I often say "'No and I dont know' are acceptable answers."
Just say no.
Hi @Larry @TKWITS
the graphic covers it really good. This usually happens when function/pricing/simpilicity is weighted over security, which might work to a certain point.
The "flaws" are not on public display, having a look under the hood can be mind-boggling. Knowing these shortcomings could be a simple way to determine the attack vector and the impact because of the wide usage could be high.
#Sidebar: It's not related to a
newproject/client, it's about having this kind of stuff in the field and the vendor does not seem to give a bit.I contacted the vendor of the (you probably guessed it, not so) hypothetical solution and will evaluate depending on the answer. But the direction where this is heading seems to be clear.
--Michael@BWC
"it's about having this kind of stuff in the field and the vendor does not seem to give a bit"
Even if you are forced to work with said vendor YOU can put processes and policies in place to limit the impact it will have to you. Sometimes you have to force others peoples hand by locking things down and making them realize their mistakes. 'My companies policy is not allow this type of connection'...
I have no problem telling others how it is, and thats why I am considered sometimes 'rough' or 'unprofessional'.