To avoid that in the first place couldn't those systems just yank Java out of the setup completely? I mean is Java "that" freaking important? And if it's a RAT or any malware made with Java it can't do a thing if the landing ground (target) doesn't support it to begin with right?
It would definitely be used by aerospace enterprises since CAD/CAM, etc. like applications use it heavily.
They sure do. I guess at the end of the day outfits like this are going need to ramp up auditing and setting security provisions for every single possible programming language such as that app and others to avoid getting taken by even scripto kiddies.
You're not wrong: but not for "every single programming language". The sad fact is that the best possible vector is PEBKAC, since most humans (read: "employees") work for their own convenience and insist that Somebody Else should look after threats. And I wonder how many business boxes have holes for sticks, disks, cards ... ? My fave email app, Gammadyne Clyton, is auto-set to strip problematic attachments from messages, but OTOH this is the sort of thing that should be done on the company server and all in-bound emails should be served to the user's (employee's) desktop rather than the user having a local email client. So I have very little sympathy left for institutions that won't swallow a tea-spoon of cement powder, (wo)man up and take security seriously.
Can anyone possibly explain (as regards to emails especially) why such organizations/institutions BY NOW or BEFORE, never even considered something as stupid simple as having those open in a virtual containment array/sandboxie etc. at the very least to dodge infecting the actual system. I'm not as sure if the same would help where concerns the network channel itself. But couldn't agree more that if windows is the preferred system of choice, there has been infinite even very FREE protections created and distributed for a very long time now that would no doubt stave off RAT intruders dumping their payload etc. At a loss to understand why they let such systems hang out like a wet rag.
Stand-alone sandboxing the likes of Sandboxie, etc.. are problematic for most corps., that is why they are not used. Today most of these attacks are spear phishing where the attacker has researched in depth his target. They are quite deceptive and as recent events have shown, are quite effective. There is a solution. Receive all e-mail in text format and refuse to accept attachments; instructing the sender to include attachment detail in the e-mail itself. Again, not practical for many corps.. So, just use a security solution such as Eset that can scan e-mail for malware in most popular e-mail clients. It detected a "DHL" malicious one for me a couple of days ago.
In regards to corp. e-mail attacks, I will mention this for folks not aware of the situation. Corps. are much more vulnerable to e-mail attacks than individual users. Individuals use an e-mail provider that as a rule scans all incoming e-mail for malware. Corps. on the other hand use an e-mail server to receive e-mail directly from the Internet and distribute it internally. As such, corps. are entirely dependent on their internal security solutions and proper configuration thereof for protection.
