back to article Equifax's disastrous Struts patching blunder: THOUSANDS of other orgs did it too

Thousands of companies may be susceptible to the same type of hack that recently struck Equifax. The Equifax breach was the result of a vulnerable Apache Struts component. Software automation vendor Sonatype warns that 3,054 organisations downloaded the same Struts2 component exploited in the Equifax hack in the last 12 months …

  1. wyatt

    Technical debt, so much of it about. Wonder what the cost to business would be to bring everything up to date or is it cheaper for a manufacturer to just abandon it?

    So many companies we have as clients have old applications that there is no way to move forward with. Problem is that the technology works well still, so there is little appetite to replace it.

    1. DropBear
      Facepalm

      In an ideal world, everyone would always develop for / deploy the latest version of all involved software, and it would all be supported, maintained and patched indefinitely and instantly when fixes come in.

      Well, this is the real world and that is never going to happen, not even close - in fact, I don't think it's feasible to get much closer to the ideal then what we have now, assuming reasonably diligent maintenance (clearly not at play though in this trainwreck of a case). Still, the issue is an architectural one - right now we all live in buildings constructed out of loosely stacked bales of hay, structurally speaking. No wonder anyone can blow them down if they bother trying at all. As such, it should be treated in kind - when bridges are failing, what we need to fix them is not "stronger steel" but "lattice beams"; something that can make do with what realistically exists through a better design.

      We should examine the way we create, maintain and assemble software and come up with something better, because what we have now is clearly inadequate and it will clearly only get worse - much worse as complexity only keeps going up in a very entropy-like fashion. No, I don't know what the solution is - but I don't see this getting looked into in earnest either, and that's a problem. You don't eliminate backlash in a mechanism by expecting perfect gears with zero tolerance - you invent an assembly that takes out the slop. So who is working on coming up with the software equivalent of that, and just how far along are they...?

      1. colinb

        Things are actually getting worse.

        Imagine a senior dev has left and he was partial to using Go for servers, node.js for UI, python for some algo, ZeroMQ plus numerous 3rd party github projects, the NoSQL flavor of the day.

        Then stuck it all into a microservice architecture. Not uncommon these days.

        His CV looks great but some poor mug(s) will have to support/make changes to all that once he's gone.

        The only way to really handle that is to have microservices that are immutable and you compile new versions running separately plus very good test frameworks, which could all be different per language of course.

        1. Doctor Syntax Silver badge

          "Imagine a senior dev has left and he was partial to using Go for servers, node.js for UI, python for some algo, ZeroMQ plus numerous 3rd party github projects, the NoSQL flavor of the day."

          A few days ago there was an article being somewhat snotty about enterprise architects. One role for the EA should be to make an informed choice of the technologies in use, minimising the uncontrolled dependencies and keeping up to date with them when they change.

          1. HmmmYes

            Yeah ...

            You audit everything that makes up a system

            You record any 3rd party deps - and their licensing.

            And, if producing a built system, yu make sure it can be built on a fresh build box, generating identical binaires i.e. exact same at the binary output level.

            Problem with 'Enterprise Architects' is most they are fly by night bandwagon jumping shyters

        2. Anonymous Coward
          Anonymous Coward

          The fix. Assume all code is a black box and insecure.

          That is not an unreasonable starting position - since o/s patches come out regularly to close holes in the o/s code that have been there for years, each product gets update with bug fixes to close holes, and 0-day exploits are regularly found by fuzzers and other discovery tools.

          So if we start from that principle - All code that takes input is exploitable - we can look at treating this as a quarantine and control issue, rather than forever searching for a cure.

          So - logically - the solution is to observer BEHAVIOUR of the code during it's operation at all times. What does it normally interact with (processes & threads, other code, registry values, open application ports) and then BASELINE this as acceptable. Then if the code DEVIATE from this - by calling code it does not normally use, or making calls that are outside of the baseline, then QUARANTINE it.

          Holistically, this approach seems to make more sense than the endless whack-a-mole of fixing security holes in code, and placing the onus on the developers and sysops to chase round their estate endlessly trying to keep up with these, only to know for certain more bugs are still in that new release.

          1. Anonymous Coward
            Anonymous Coward

            "So - logically - the solution is to observer BEHAVIOUR of the code during it's operation at all times. What does it normally interact with (processes & threads, other code, registry values, open application ports) and then BASELINE this as acceptable. Then if the code DEVIATE from this - by calling code it does not normally use, or making calls that are outside of the baseline, then QUARANTINE it."

            And if its behavior is NORMALLY random or scatterbrained, such that you CAN'T find a baseline pattern (which could distinctly be possible as more code is multi-threaded and multi-tasking)?

        3. tom dial Silver badge

          This is a management problem. Few managements have the stones to suppress deviant programmers and refuse permission to use the "latest and greatest" frameworks and languages (and to stomp them out ruthlessly when they show their faces). Even fewer, I suspect, have a clear conception of how the IT portfolio should be defined and managed.

      2. big_D Silver badge

        I met a production controller last night, she has a bunch of CNC machines on the factory floor, but because the controlling PCs use outdated Windows images, can't be updated because the supplier won't let them and they can't put on their own, controlled image, the CNC machines are all off-line.

        She said it drives the supplier nuts when they try and provide remote support. The first thing they always ask it to start TeamViewer. It usually takes the support tech at least 15 minutes before they accept that they won't get remote access to the device and have to use good old telephone diagnosis.

        And any patches to the CNC software need to be delivered by sneaker-net.

        1. keithpeter Silver badge
          Pint

          What are the rest doing?

          " The first thing they always ask it to start TeamViewer. It usually takes the support tech at least 15 minutes before they accept that they won't get remote access to the device and have to use good old telephone diagnosis."

          @big_D: One wonders what the other companies with CNC machines of similar vintage are doing if the default assumption is that the controller PCs are accessible via the Internet.

          Pint: for one company at least making a sensible short term compromise by isolating their machines.

          1. Anonymous Coward
            Anonymous Coward

            CNC machines

            All sorts of industrial/medical control systems tend to be running on very out of date Windows, or in some cases Unix. I saw a SunOS - not Solaris but SunOS! - GUI when I got a CT scan a couple years ago. A hospital isn't going to replace a $2 million piece of equipment just because the computer that drives it is out of date, they won't update it without manufacturer support, and manufacturers don't want have to be responsible for either delivering tested sets of Microsoft patches or test every Microsoft patch against their software.

            You could put such devices on an isolated segment that can't talk to any internal network, and can only talk to the internet. Firewall as tightly as you can, then disable the router port that network uses to communicate with the internet. When you need service, you enable the port to allow remote access, grabbing software updates, etc. and then you close it off again when you're done. This won't be a problem for e.g. PCI audits since it is an isolated network.

            1. skwdenyer

              Re: CNC machines

              There's a great guy (Ian Mapleson) whose sort-of-business is supplying SGI IRIX hardware to people who need it. Lots of CT scanners and their like still run by Octanes and their ilk, apparently. It is said there are still knitting machines run on SGI Indys.

              Obviously his business gets smaller every year, but equally the amount people are prepared to pay for working hardware may nonetheless be enough to make it just about tick over.

          2. JCitizen
            Go

            Re: What are the rest doing?

            @keithpeter - When I worked at Hein-Werner - we kept the entire plant off line because we knew it was hopeless to protect the network. At least managment was smart enough to realize that. You could only download a program for a CNC by manual switching and only for the seconds it took to load each program. then switch off. This network was completely isolated - everything else was 'sneaker net'. One good thing about it was, you never had to worry about a patch blowing up your programming; so it was darn well worth it, in my best estimation.

            Of course there was no Windows involved just G code and some paper tape conversions.

          3. skwdenyer

            Re: What are the rest doing?

            Surely the solution is easy - provide a network-accessible KVM. Either 1 per CNC machine, or 1 that can be plugged into the relevant CNC machine with ease. Turn it on when needed; turn it off when not. With proper access control, this is as secure as it needs to be for remote support purposes.

        2. HmmmYes

          Dont buy plant/expensive stuff with embedded Windows on it.

          I insist on stuff having CLI access only.

        3. Version 1.0 Silver badge

          As someone demonstrated with Stuxnet, sneakernet is not secure either.

          1. big_D Silver badge

            @Version 1.0 but the sneaker-net doesn't affect the rest of the network. If the unpatched, old PCs were on the corporate network, so they could get remote support, they could also be used as an attack vector into the rest of the network.

        4. Mike Pellatt

          I've looked after a (very) small engineering firm whose (sole) CNC machine tool is controlled by a Windows 95 PC. No way would that ever go near the internet. Sourced bits for all of it to have some hardware spares, except the multi-port serial card, the sight of which took me back to SCO Unix and green screen days :-)

      3. HmmmYes

        No you won't - new version and tools have their own bugs and errors in.

        There's no easy solution.

        You manage your software infrastructure, maintaining a list of versions deployed. You pay for maintenance - proper maintenance rather than a support payout that never delivers an update/fix.

        You either pay someone to support your working set of software or you employ someone to maintain it.

        1. Version 1.0 Silver badge

          "You either pay someone to support your working set of software or you employ someone to maintain it."

          And there's the problem - nobody wants to pay for something they think that they can get for free ...

          1. HmmmYes

            They are paying for it now.

            Looks like the cost is several orders of magnitude the cost of paying the developers.

            Live and learn. Or not.

            1. Anonymous Coward
              Anonymous Coward

              "Looks like the cost is several orders of magnitude the cost of paying the developers."

              But developers like to work on new-stuff not old-stuff so if you if you say doubled the developers you might just get more "innovation" and new services with a corresponding increase in the attack surface.

              Don't know the best solution but just throwing developers at the problem may not be it.

          2. RareToy

            And there's the problem - nobody wants to pay for something they think that they can get for free ...

            So many businesses think they can cut corners on the IT support. While you probably could let Joe in sales who bought a website template and runs it at home fix your production network, it is no substitute for a real experienced IT staff. Their education (and continuing education) is not cheap. Everyone has to pay somehow. The CTO has to decided when they are going to pay, now or later.

      4. Michael Habel

        So with this thought in mind... Tell us how you feel about MicroSoft force feeding their mostly untested, possibly unwanted 'Updates' on everyone.

        So Your 'Ideal World' kinda took a misstep. Namely clued in end-users Capable of maintaining their own Machines. So I said before. I would wonder how compliant these Organizations would all become, had there actually been some rather painful discomfort to their bottom lines. And, not merely the gentle massage of the Pinkie their usually accustomed to. Case in point such idiot outfits out there that still think using Windows XP, Three, and a half plus Years is still somehow a good idea. Till they get hit upside the head with Wannacry.

        1. HmmmYes

          My ideal world?

          I dont run Windows boxes on production machine.

          Its not 100% ideal but I dont get my company riddled with viruses and ransomware.

          You have to work out where your critical systems are and what the cost of those boxes failing are.

          1. colinb

            there is always one

            "I dont run Windows boxes on production machine."

            You know Struts runs on JAVA, runs on Linux and is open source, right?

            Equifax has run on Solaris in the past.

            http://toolbar.netcraft.com/site_report?url=www.equifax.com

        2. EnviableOne

          @Michael Habel - Except WannaCry didnt work on XP, at most it just BSOD the machine.

          plus if you were patched up to date, and like any normal person blocked NetBIOS over TCP/IP at the boundary, as advised by MS to mitigate "BadTunnel" it couldnt infect you.

          If you got to run XP, run it, but lock it down, proxy its connections and scan everything.

          Black Duck have been trying to flog me their Open Source vulnerability scanner for ages. but i'm not suprised, how many coders do you know that have out of date versions of libries stored in their own repo that never get updated and they have been using for years!

        3. Intractable Potsherd

          @Michael Habel

          Sorry, Michael - Win XP was hardly affected by Wannacry:

          http://www.wired.co.uk/article/wannacry-windows-7-xp

          https://www.theverge.com/2017/5/19/15665488/wannacry-windows-7-version-xp-patched-victim-statistics

          https://www.theverge.com/2017/5/30/15712542/windows-xp-wannacry-protect-ransomware-blue-screen

          It's time to put this myth to bed.

    2. Lysenko

      re: Problem is that the technology works well ...

      Not having fire insurance both works well and saves money 99% of the time. In fact for many (most?) companies fire insurance will be a pure overhead with zero utility for the entire lifetime of the organisation. Numbers can't lie. There is only one rational decision for a beancounter to make. ..... Oops.

      1. Amos1

        Re: re: Problem is that the technology works well ...

        Nailed it. The worst thing that happened to information security and data protection was this thing called "Risk Management". There is no such thing. When you have five holes in your boat, any one of which could sink it, you don't use "risk management" to "prioritize" fixing the holes or you will eventually sink.

        The unwritten "risk management" rule for many managers is this:

        "Almost any risk is acceptable until it happens to us, not someone else. And when it does happen, I probably will have moved on so it will be someone else's problem. That is acceptable risk."

        1. John Gamble
          Thumb Up

          Re: re: Problem is that the technology works well ...

          "The unwritten "risk management" rule for many managers is this:

          "Almost any risk is acceptable until it happens to us, not someone else. And when it does happen, I probably will have moved on so it will be someone else's problem. That is acceptable risk." "

          Ah, The Bottle Imp strategy of system management, without the moral self-examination.

      2. Loud Speaker

        Re: re: Problem is that the technology works well ...

        My brother's business burned down last week. He lost everything - value £50k (small business). He had no insurance.

        Why?

        Because his premiums were £300 pa before 9/11, and then they raised it to £3k. There has been 6 years since 9/11. If he had paid the insurance, with inflation (typically 20% in insurance if you are a buyer, not a regulator), the premiums would probably have cost him £50k anyway!

        The reality is, the insurance industry is eating itself with its greed!

        Better to put the £300 pa into bank shares. For example Barclays. Their scandal deployment department ensures frequent attractive buy opportunities.

    3. CMYanko

      It's cheaper than you think

      I can tell you from personal experience that keeping components up-to-fdate is cheaper than the current, manual, ineffective, processes. The core problem is most devs have no visibility because security info only goes to security people who themselves struggle to understand how it impacts development.

      1. big_D Silver badge

        Re: It's cheaper than you think

        @CMYanko Security info is publicly available to ANYONE, it doesn't just go to "the security people". Anybody working in IT should be watching at least a couple of IT based websites and if you are developing for a particular platform, then you should be subscribing to its newslists or RSS feeds, blogs etc.

        As a developer, I always kept track of issues with the tools I was using and often informed my management that we needed to apply patches. I often knew more than the ops and security team, when it came to locking down the specific tools I was developing with.

        1. Anonymous Coward
          Anonymous Coward

          Re: It's cheaper than you think

          You, sir are one in a million.

          From what I've seen over the past few years, most of the younger "devs" hired these days are not a lot more than "script kiddies" doing semi-legitimate work. They have no concept of security and are not interested in staying current. To them, security is just a major PITA that can cause them to deviate from their usual coding habits.

          And IA/Security? In the US Gov't jobs I've had over the past 15 years, I've not met one person who was even familiar with, much less knowledgeable of, either coding/dev or OS's. Most of the IA people I've had the misfortune to work with had zero technical training. Their jobs were to run scanning software and then throw the results over the wall and say "Fix it." They have zero idea how (or what), just that it HAS GOT TO BE FIXED. NOW." Makes me crazy.

          Sign me: Disgruntled old "get off my lawn" Sysadmin

  2. colinb

    Reality bites

    The quotes in the article seem to assume all code is maintained and there is someone readily able to do a new build.

    There are mountains of code that hasn't been changed in years and people have cold sweats about changing.

    This Struts issue is one of the drawbacks of libraries that ship in the folder with the code rather than patches applied at the OS level <missing>My X is better than your Y</missing>.

    The responsibility then lies with the developers and by extension management to make sure they have a supported code base which currently is very low on priorities and always has been.

    1. Amos1

      Re: Reality bites

      "This Struts issue is one of the drawbacks of libraries that ship in the folder with the code rather than patches applied at the OS level..."

      Correct and this is why the STRUTS and other problems are actually far, far more prevalent than companies believe. Vulnerability scanners just look in default locations unless you specify the correct path. Vulnerability scanner vendors are now listing a warning that they may only find vulnerable components if installed in default paths.

      But companies won't care because they can just blame the hack on their defective scanner. Less findings = less work.

      1. colinb

        Re: Reality bites

        Yep well the ability to place your head in the sand while still talking is required for all IT management.

  3. Anonymous Coward
    Thumb Up

    Your credit report. Free. Forever.

    Never before had an ad been so apt.

    1. BeakUpBottom

      Re: Your credit report. Free. Forever.

      Anyone, anytime, any place.

      1. Anonymous Coward
        Anonymous Coward

        Re: Your credit report. Free. Forever.

        Goodiiees, goody goody yum yum

  4. Doctor Syntax Silver badge

    "Over the years Struts versions have unsupported/broke features, plugins,"

    Backward compatibility. Nobody cares about it. Except the users, of course.

    I'm not familiar with Struts but a good policy, whether for free or commercial products, would be:

    If the major version number is the same we'll ensure it's backwards compatible. If we have to break compatibility we'll update the major version number but maintain the last major number for X months/years or as long as practical.

    From the users' point of view they can then choose who has the longest maintenance period, changes least often and best lives up to the policy They can also minimise the number of external dependencies.

    1. JSTY

      If you haven't heard of it, the versioning pattern you describe is similar to SemVer - see http://semver.org/ which can be used with anything exposing an API and is quite nice to work with.

      Some developers / maintainers do care about backwards-compat, see the lengths Debian, RedHat, ... maintainers will go to back-patch. We are sadly few and far between it seems.

      1. Doctor Syntax Silver badge

        "Some developers / maintainers do care about backwards-compat, see the lengths Debian"

        I've used Debian for many years. I also, however, remember libc6 undergoing radical changes (about the time of Linux kernel 2.6, I think) that broke previous application binaries. And if the application was commercial and no replacement was available -well, just too bad.

  5. HmmmYes

    File under 'Java bug'

    How I laugh when I read all those Java/Jini claims of 20 years ago.

    1. Destroy All Monsters Silver badge

      Maybe you should start to learn about that IT thing instead of being smug for no reason except total ignorance.

      Just a hint.

      As for laughing at Jini? Well yeah, agent architectures. So what? We have them.

      1. HmmmYes

        Read this:

        https://incubaid.wordpress.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/

        Come back and comment on Java after youve read it.

        Java/JINI just did not work. It got it all wrong, long after people had pointed out the RPC just doenst work when you gave states.

        Youll be pushing RPC next. Or Corbra.

  6. Anonymous Coward
    Anonymous Coward

    Shower

    What a veritable shower of shit this situation has become, not just Equifax and similar but the whole IT industry approach to security and patching. Boards and shareholders of companies must demand that the CIO has relevant and measurable security KPIs in his performance tagets, and that should extend to CEO as well. The time for ending this pussyfooting about is way overdue.

    1. Anonymous Coward
      Anonymous Coward

      Re: Shower

      I point you to the CEO of TalkTalk who not only got away with presiding over a clusterfuck of a security disaster, she also got away with lying to a Parliamentary Committee about it.

      Accountability is dead and buried 50 feet under these days.

      1. Teiwaz

        Re: Shower

        Accountability is dead and buried 50 feet under these days.

        I'd hardly expect the western powers to be concern with it's citizens private data, breached data likely hoovered up to add to the 'haystack'.

        got away with lying to a Parliamentary Committee about it.

        No need for them to punish someone who unwittingly aided the data fetish, committees and hearings are just pointless acts to be carried out in order to look like something is being done, and the government wasn't in enough danger for a scapegoating to be necessary.

  7. Aodhhan

    What a sad state of mind

    Equifax has shown us there are plenty of executives in charge of technical operations who have no business being in these positions. Looking through the LinkedIn Resumes and Equifax web site information on their technical executives tells me the executive board is made from the 'good ole boy' network.

    In addition to the CIO and security officer retiring, why isn't the CTO along with risk management and auditing executives cleaning out their desks? They failed to realize the importance of proper security policies and procedures. They also were a part of not understanding the threats facing their systems. Then there is the CEO... whose chief responsibility is to protect shareholders; obviously failed to do his job and should step down as well.

    I've heard so many excuses when it comes to patching over the years. It takes an experienced and knowledgeable InfoSec professional to inform executives of the risks facing their systems. When the risk of a vulnerability is a 7+; along with the exploit score of 10 and can be EASILY executed remotely.. this is a huge red flag where the CIO must convince everyone the patching must be done immediately. Inside 48 hours. If other responsible executives do not get this... then they don't have the background to be in their position.

    It will be interesting to finally see the entire InfoSec structure along with the experience and technical expertise of their personnel. Not to mention their policies and procedures in place to audit the established security policies; not just for patch management, but for all operations.

    1. Anonymous Coward
      Anonymous Coward

      Re: What a sad state of mind

      Simple. It costs less to pay out the lawsuits than to do things right. In that sense, the board IS protecting the shareholders and assuming fiduciary responsibility. Plus, since corporations by design deflect criminal responsibilities in order to encourage investment, this could be seen as Business As Usual.

    2. HmmmYes

      Re: What a sad state of mind

      Its not technical. Its business!

      Dont get into the silly game of CEO cannot program, so they do not understand the software.

      Its business continuity/risk. Pure + simple.

      Do Equifax run software - yes/no?

      Is that software supported and maintained - yes/no?

      1. Anonymous Coward
        Anonymous Coward

        Re: What a sad state of mind

        Now here's a bender for you:

        Which costs more? Maintaining the security of the software or paying off the occasional legal spat should things go wrong?

        1. Twilight

          Re: What a sad state of mind

          The real problem is with the credit agencies. Many companies consider lawsuits as "cost of business". However, this breach at Equifax exposed 143 million sets of PII that will be valuable to criminals for years/decades. Equifax (and the other credit bureaus) need to be held to a MUCH higher standard than Bob's Software Company. The damages assessed on Equifax from this breach should be WAY more than enough to bury the company permanently. Of course, I think the odds of that actually happening are pretty low. :(

    3. hoola Silver badge

      Re: What a sad state of mind

      What is happening is that so much of the data has been lifted by these miscreants, that it is reaching the point that there is very little personal information that cannot bought or found.

      What I just don't understand is why we have reached the state that so much of this is on publically accessible networks.

      Oh, that is it "Convenience" and the fact that the fines and responsibility for the people at the top mean nothing. Automatic custodial sentence for the execs would focus the mind, along with all the relevant licences the company needs to operate being withdrawn. Add an immediate cease and desist on their service provision so that impact is instant would help.

      But of course, all that would happen is the incidents would never be reported. This is a no-win situation whatever you do with the only losers being those who have had the data stolen, i.e the general public.

  8. Nimby
    Boffin

    Security should be commensurate with the consequences.

    I maintain a package of 3rd party software used in our company for development, so that all developers (and customers) have exactly the same versions of 3rd party components required by our software. It's simple enough in concept.

    In practice, so many times we choose not to update because of API changes that we don't have the manpower to port our code to match. Other times it is simply a lack of management approval for the time needed to test that a 3rd party update does not crash our software before updating our package.

    Heck, just ask NASA what their oldest operational computer still is, and why. So I totally understand intentionally not using the latest version of something.

    But then our level of security impact is pretty darn low. We aren't storing a database of millions (billions?) of customer data, including highly private information like social security numbers. If we were, we'd be darn stupid not to instantly jump on every security update.

    IMHO, to be blunt, if you want to play with Big Boy Data, then it's your balls on the chopping block if you don't properly secure it. If that's too difficult for your organization, then maybe your organization is in the wrong business. We need laws that punish with a severity based on impact. Maybe then a few more companies will take security seriously.

    1. Charles 9

      Re: Security should be commensurate with the consequences.

      "IMHO, to be blunt, if you want to play with Big Boy Data, then it's your balls on the chopping block if you don't properly secure it. If that's too difficult for your organization, then maybe your organization is in the wrong business. We need laws that punish with a severity based on impact. Maybe then a few more companies will take security seriously."

      You forget that one of the jobs of business (especially corporations, who do this by design) is to deflect risks. That includes legal risks. Laws? Pay off legislators to keep that from happening. If that doesn't work, play sovereignty against them and move to a more lax country. Extreme end, probably take the Shadowrun route and become sovereign. Same for financial risks: a little bribe can go a long way, and if persuasion doesn't work, move up to intimidation. And all this can likely be had for less than the cost of actually doing it right.

      1. ecofeco Silver badge

        Re: Security should be commensurate with the consequences.

        Sad but all too true.

  9. HmmmYes

    I guess accounting/tax is to blame too.

    Software needs to be written off when the hardware it runs off is.

    Or at least shipped with some sort of regression/acceptance test suite.

  10. Pirate Dave Silver badge
    Pirate

    numbers

    "Software automation vendor Sonatype warns that 3,054 organisations downloaded the same Struts2 component exploited in the Equifax hack in the last 12 months. "

    Out of my own ignorance, I ask - how does Sonatype know those were "organizations" downloading it, and not 3,053 hackers wanting to figure out how to work it into a payload? With the 3,054th organization being, naturally, Equifax...

  11. DerekCurrie
    FAIL

    Computer Security Professionals Vs Unprofessionals

    In this day and age, in the aftermath of Target Corporation's massive, tragic security breach in 2013 that affected 72 million victim customers, to have a company (or government) ignore and not immediately implement software security updates is irresponsible, irrational and unprofessional.

    This is the modern state of computer and Internet security.

    To those who cannot or will not catch up with the modern requirements of work in computer security, I suggest that you immediately leave the profession in order to make way for those who understand exactly what's at stake and who know how to perform the work with an up-to-date understanding and skill set. Otherwise, you're clearly a detriment to the people you work with and for.

    1. Charles 9
      FAIL

      Re: Computer Security Professionals Vs Unprofessionals

      Why not? Seems cheaper to pay off the lawyers than to do things right.

  12. Steve Jackson

    Expired Milk Analogy

    Expired milk shouldn't be on the shelf, so it's a bad analogy.

    Direct links to files should be discouraged, people should have access to a landing page with the latest version front and centre, retain the older patch levels by all means in an expandable list.

    Links should be clearly marked with the version/build and date, filenames should be the same and file details should be too.

    If people don't want to read the patch notes or test then that's on them, but the above should be the developers responsibility.

    I would sign in for support of a mission critical software update or upgrade, download via credentials even. If the developers can't maintain such a system then their whole process is brought into question.

  13. JCitizen
    FAIL

    It just goes to show...

    that even Apache Linux can fail when you get java involved! It's not just for Windows anymore!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like