Slashdot Mirror


Report: Evidence of Healthcare Breaches Lurks On Infected Medical Devices

chicksdaddy writes: Evidence that serious and widespread breaches of hospital- and healthcare networks is likely to be hiding on compromised and infect medical devices in clinical settings, including medical imaging machines, blood gas analyzers and more, according to a report by the firm TrapX. In the report, which will be released this week, the company details incidents of medical devices and management stations infected with malicious software at three, separate customer engagements. According to the report, medical devices – in particular so-called picture archive and communications systems (PACS) radiologic imaging systems – are all but invisible to security monitoring systems and provide a ready platform for malware infections to lurk on hospital networks, and for malicious actors to launch attacks on other, high value IT assets.

Malware at a TrapX customer site spread from a unmonitored PACS system to a key nurse's workstation. The result: confidential hospital data was secreted off the network to a server hosted in Guiyang, China. Communications went out encrypted using port 443 (SSL), resulting in the leak of an unknown number of patient records. "The medical devices themselves create far broader exposure to the healthcare institutions than standard information technology assets," the report concludes. One contributing factor to the breaches: Windows 2000 is the OS of choice for "many medical devices." The version that TrapX obtained "did not seem to have been updated or patched in a long time," the company writes.

42 comments

  1. Not Just That Machine by KermodeBear · · Score: 2

    It's not just the outdated OS that is the problem. One must wonder why a medical image storage server is allowed by the network to make outbound network requests all the way to China.

    --
    Love sees no species.
    1. Re:Not Just That Machine by Anonymous Coward · · Score: 2, Informative

      If I'm understanding the story right, it didn't. The medical image server got infected somehow but didn't have outbound network access. From that server, they then infected a work station, that DID have outside network access. From there, they sent data to China.

      The root issue is ultimately government regulations, which prevent these devices from being patched. You can't simply patch a medical device because then it loses its FDA certification. And it's only going to get worse, since part of Obamacare is requiring everything to be stored digitally. We're moving from good ol' paper records (that anyone can read) to a digital mess that requires special proprietary software to read and can't be patched without months of government red tape.

      Of course, the people stealing medical records don't have to carry about the insane licensing fees necessary to get software that can read the records they steal - they just steal the software, too.

    2. Re:Not Just That Machine by Anonymous Coward · · Score: 1

      That is an easy one. Because that would require have competent IT and especially network staff to make sure that there are working vlans.
       
      One of the challenges that hospitals face is that their benefits packages suck, really really suck. They tend to work with other hospitals and providers in a region to make sure that salary and benefits are similar between institutions. This is to minimize clinical personnel to move between places.
       
        This is tolerated because medical instutions are usually exempt from labor protection laws.

        IT usually has these crap benefits. i.e. NO HOLIDAY TIME OFF. If you want a holiday off, you have to take a personal day. Personal days- In my area you only get 15 personal days a year and you must give several days notice. Holiday pay - non-existent since IT is exempt. Medical benefits- Great as long as you use the company store and do not live in an area that does not have the company store.

      Now add to that, industry average pay at best, it is no wonder why medical data systems are in bad shape.

    3. Re:Not Just That Machine by alen · · Score: 1

      something like 10 years ago i would joke that we should block all traffic at work from china and eastern europe. doesn't take a genius to do that

    4. Re: Not Just That Machine by ArmoredDragon · · Score: 1

      Not only that, but I have to wonder why any hospital or scada network doesn't have some sort of ip block whitelist. In fact, dare I say, any ip connected network that isn't intended for its users to access Facebook should have some kind of autonomous system number whitelist in its bgp tables.

    5. Re:Not Just That Machine by TheCarp · · Score: 3, Informative

      > The root issue is ultimately government regulations, which prevent these devices from being patched.
      > You can't simply patch a medical device because then it loses its FDA certification.

      No. The issues are far deeper than that and have ALOT to do with the overall fragmentation of the entire medical industry and the culture of vulchers that fly around the clinical medical industry looking for ways to get their feet in the door to steady profits.

      Here is what i saw from spending too long on thos front lines:

      They are all trying to build an embeded solution they can charge for support on, they will generally work directly with the clinics, bypassing central IT as much as possible, and bring them in only at the end, and try to position them as the road blocks on the project because.... they want to keep all the support to themselves.

      Then when IT patches all their systems and sees "hey this is an out of date linux box" the vendors sit on their thumbs and cry about FDA certification, as if the responsible thing to do wasn't to immediately contact the FDA about re-certifying. Oh no but that would cut into their profits!

      Hell if they really cared, they would fix it, and tell the FDA that if they even try to levy a fine, they are going public with exactly what level of risk and vulnerabilities the FDA is effectively forcing people to accept. Who do you think would look bad after that exchange? "We fixed this problem to protect our patients in spite of the FDA trying to make us not" you think that isn't the kind of issue that would get an FDA head called before congress?

      It is, but it never happens, because the profiteering industry likes the regulations the way they are because they don't like having to patch, its a bother.

      --
      "I opened my eyes, and everything went dark again"
    6. Re:Not Just That Machine by Anonymous Coward · · Score: 0

      Why do you think that would be effective? The Chinese (or Russians or whomever) would simply buy a VPS in the United States (or other non-blocked country) and then siphon the data back to the homeland.

    7. Re:Not Just That Machine by Anonymous Coward · · Score: 0

      An open source security patch breaks a medical device running Ubuntu Linux resulting in the death (or indirect death) of a patient. Who does the patient's estate sue? The hospital? The IT department in the hospital? The company who made the product? Ubuntu? The developer who wrote the patch? The developer who introduced the bug? (The answer is of course all the above.)

      I get you have a boner to blame the device manufacturing companies, but your desire to blame them seems to be biasing you...just a tad. If the FDA slaps them with an injunction or worse, a recall, and they have to wait for months while the FDA/congress/lawyers sort it out (perhaps going bankrupt in the meantime), your solution suddenly looks a lot more risky. If the FDA *were* to cow-tail and let people patch it, and the *patch* did kill someone, then the FDA gets to be named in the lawsuits as well.

      It is about money, but it's not just about profits, it's also about not losing your business to lawyers. Unless you're ready to let people die because a security patch killed somebody, then you should probably simmer down about the companies trying to control the process.

    8. Re:Not Just That Machine by TheCarp · · Score: 1

      So it is ok to let them die because some script kiddie owned the box, because in that case you are not liable.
      Makes perfect business sense.

      Yes, testing patches is part of the fucking process, maybe they should have figured that into the business plan up front.

      --
      "I opened my eyes, and everything went dark again"
    9. Re:Not Just That Machine by Anonymous Coward · · Score: 0

      "cow-tail"?

    10. Re:Not Just That Machine by Anonymous Coward · · Score: 0

      Worker in medical IT here - currently 32 vacation days, 8 holidays, all fully paid. Health insurance at different rates depending whether you use just the companys chain of clinics or you want to go elsewhere. Pretty much the same pay and benefits as the other providers.

      So my anecdote cancels out yours.

  2. Meanwhile, HIPAA fines will skyrocket by Tony+Isaac · · Score: 5, Informative

    HIPAA imposes fines for each patient's record lost through security breaches, even if the medical provider "did not know (and by exercising reasonable diligence would not have known)" https://kb.iu.edu/d/ayzf that there was a breach. These kinds of punitive rules have scared the entire industry to death, and yet the open secret is that nobody is safe from breaches, or these fines. This story illustrates how the law has done little, if anything, to actually protect privacy.

    Most providers react to HIPAA in one of two ways:
    1) They over-react, creating stupid policies like refusing to tell even a patient's own spouse the details of a patient's medical condition, unless the proper paperwork has been filed, or
    2) They under-react, blissfully ignoring any privacy concerns.

    If we're going to try to regulate privacy in the medical industry, how about let's focus on the device and software makers with certification programs, and let hospitals and physicians get back to doing what they do best: treating illnesses.

    1. Re:Meanwhile, HIPAA fines will skyrocket by ColdWetDog · · Score: 2

      No, we don't do that. At least not any more. Most places have figured out the ins and outs of HIPAA by now. And no, your spouse cannot access your records without permission - that is by design. You can give your spouse permission but you can also block it. Think about it - that's the way you would like the default.

      This isn't a HIPAA issue at all. It's a technology problem and, FWIW, I'm not so sure it's as big a problem as TFA would have you believe. I've yet to see a PACS run on WIndows 2000 (certainly 'most of them' do not')- they're typically Linux these days. None of the ones I've seen have non password protected access. I'm sure there are some little ones that are running something obscure like Windows CE but again, TFA gives one example and then conflates it to a general issue. Sounds a bit like FUD to me. The example of the open PCA pump is real enough - we covered it not too long ago - but again, pics or it didn't happen. Sure it CAN happen and it's a vector that needs to be considered.

      --
      Faster! Faster! Faster would be better!
    2. Re:Meanwhile, HIPAA fines will skyrocket by Anonymous Coward · · Score: 0

      How about letting the software industry tackle this problem and let us all get back to doing productive work? Get out that typewriter.

      I don't own computers anymore because they're more trouble than they're worth. I regret setting them up for people when I was younger and I regret insisting that my parents have one. I've done nothing but maintain them since then and it's getting harder to do from the other side of the world. It's also expensive to replace operating systems every time they're compromised. It's also expensive to keep replacing perfectly functional components just because someone decided the change the shape of the plug, or make X a bit bigger, or Y a bit smaller, or Z a little bit less supported today.

      I could suggest doing things in the cloud but I know that's going to be an even bigger brainfuck sprinkled with its own clusterfuck of perils. I've given up on the ideals of computers and automation now - I've seen how the industry works (or doesn't) and I'm embarrassed to be part of this problem. We build things until they barely work and then leave the bugs for the world to sort out for us, just so we can move on to some more interesting problem - repeat ad nausium.

  3. Dude! You got a Dell by Anonymous Coward · · Score: 0

    Infected by Dell is more like it. Notice all the health (sick) companies use Dell. Notice that.

  4. FDA Certification Part of the Problem by eth1 · · Score: 4, Informative

    The reason a lot of these devices use outdated OSes is that it has to be FDA approved. I used to work on some hospital networks, and not only were some of these systems running out-dated operating systems, they couldn't have any security updates applied without losing their FDA approval. We kept these systems locked in solitary confinement behind firewalls (with no Internet access), but you still have to be able to get to them over the network to actually use them (and worse, occasionally by remote radiologists coming in over a VPN from who knows where).

    1. Re:FDA Certification Part of the Problem by Anonymous Coward · · Score: 1

      I used to work for several hospital and the vendors used to tell me I could not patch systems until they got FDA approval.. I asked the FDA about this and they said that was untrue. The FDA unofficial statement is the vendors do not what to go though the process of testing things and there for blame it on the FDA.

    2. Re:FDA Certification Part of the Problem by Rich0 · · Score: 1

      The reason a lot of these devices use outdated OSes is that it has to be FDA approved. I used to work on some hospital networks, and not only were some of these systems running out-dated operating systems, they couldn't have any security updates applied without losing their FDA approval. We kept these systems locked in solitary confinement behind firewalls (with no Internet access), but you still have to be able to get to them over the network to actually use them (and worse, occasionally by remote radiologists coming in over a VPN from who knows where).

      Yup. I've seen the same sort of thing firsthand. The mountain of paperwork needed to make changes means that fixes of any kind are only made if they're absolutely critical (and sometimes not even then). On the other hand, I doubt the virus propagating over the network bothers to file a change control form and get 3 pre-approvals.

      Even in non-regulated areas vendors get touchy about installing software like antivirus on systems. At my workplace we ended up coming up with a standardized windows image for vendor-provided systems that was designed to be as close to vanilla windows as possible, with only remote patching and antivirus installed. This cut down on vendor complaints, but probably only because we were a large purchaser. Even then we still deal with unsupported OSes and try to firewall them as best we can.

    3. Re:FDA Certification Part of the Problem by jbmartin6 · · Score: 2

      Vendors like to claim this, but the FDA clarified over 10 years ago that vendors are expected to apply security patches and other updates outside of the core clinical software. Re-certification is not required, the vendor merely has to certify that they tested the update for any effect on clinical function.

      --
      This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
    4. Re:FDA Certification Part of the Problem by Bacon+Bits · · Score: 1

      the vendor merely has to certify that they tested the update for any effect on clinical function.

      So, it's exactly like he said and no updates are allowed to be installed.

      ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.

      Honestly, I hope some hospital gets the balls to sue an ISV for failing to act in a timely manner for perpetually ignoring security like we all know they do. It's not going to change until someone holds them accountable. They'll just hide behind their EULAs until then, and hospitals will get the bill for letting people die because of security holes.

      --
      The road to tyranny has always been paved with claims of necessity.
    5. Re:FDA Certification Part of the Problem by mike.mondy · · Score: 3, Insightful

      Vendors like to claim this, but the FDA clarified over 10 years ago that vendors are expected to apply security patches and other updates outside of the core clinical software. Re-certification is not required, the vendor merely has to certify that they tested the update for any effect on clinical function.

      So, it's exactly like he said and no updates are allowed to be installed.

      ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.

      Honestly, I hope some hospital gets the balls to sue an ISV for failing to act in a timely manner for perpetually ignoring security like we all know they do. It's not going to change until someone holds them accountable. They'll just hide behind their EULAs until then, and hospitals will get the bill for letting people die because of security holes.

      From the linked FDA page:

      4. Who is responsible for ensuring the safety and effectiveness of medical devices that incorporate OTS software?

      You (the device manufacturer who uses OTS software in your medical device) bear the responsibility for the continued safe and effective performance of the medical device, including the performance of OTS software that is part of the device.1

      If the device manufacturers are forcing hospitals to run without OS patches, the manufacturers are not doing what the FDA says they should do. Maybe the FDA should change should to required. Even so, I have to wonder if there's anything preventing the manufacturers from simply maintaining a patch compatibility web page and telling the hospitals that they're responsible for the OS patches... I seriously doubt either party is innocent, but have to wonder if the hospitals are the bigger culprit.

    6. Re:FDA Certification Part of the Problem by Rich0 · · Score: 1

      In practice I've yet to hear the FDA go after anybody for failing to patch security problems on their devices.

      If somebody actually reported an adverse event with a device caused by a virus, I'm sure the device vendor would issue a tested update that closed that particular hole. However, beyond that I've yet to hear of the FDA cracking down on this, despite whatever might happen to be on their website.

      The fact that malware is being found in hospital equipment in the wild just seems to support that.

    7. Re:FDA Certification Part of the Problem by Anonymous Coward · · Score: 0

      Vendors like to claim this, but the FDA clarified over 10 years ago that vendors are expected to apply security patches and other updates outside of the core clinical software. Re-certification is not required, the vendor merely has to certify that they tested the update for any effect on clinical function.

      So, it's exactly like he said and no updates are allowed to be installed.

      ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.

      Honestly, I hope some hospital gets the balls to sue an ISV for failing to act in a timely manner for perpetually ignoring security like we all know they do. It's not going to change until someone holds them accountable. They'll just hide behind their EULAs until then, and hospitals will get the bill for letting people die because of security holes.

      From the linked FDA page:

      4. Who is responsible for ensuring the safety and effectiveness of medical devices that incorporate OTS software?

      You (the device manufacturer who uses OTS software in your medical device) bear the responsibility for the continued safe and effective performance of the medical device, including the performance of OTS software that is part of the device.1

      If the device manufacturers are forcing hospitals to run without OS patches, the manufacturers are not doing what the FDA says they should do. Maybe the FDA should change should to required. Even so, I have to wonder if there's anything preventing the manufacturers from simply maintaining a patch compatibility web page and telling the hospitals that they're responsible for the OS patches... I seriously doubt either party is innocent, but have to wonder if the hospitals are the bigger culprit.

      The problem is that the FDA is requiring that the patches/updates be 'tested the update for any effect on clinical function'--knowing how FDA testing can and often runs, this probably in practice translates to 'not at all.'

      If the tests are limited purely to the ones relevant and necessary, it'd be one thing, but the FDA has a well-earned rep for requiring tests that are antique and/or irrelevant. This is approximately like having somebody in upper management decide that any change whatsoever to the computers can only be done after huge, time-consuming & expensive battery of tests, and that you cannot skip any step under any circumstances whatsoever, even if you would like to know exactly how 'applying humorous sticker to monitor stand' could possibly result in software issues.

    8. Re:FDA Certification Part of the Problem by nickweller · · Score: 1

      "The reason a lot of these devices use outdated OSes is that it has to be FDA approved"

      What were the names of these 'out-dated operating systems' and what terms of the FDA prevented them applying security updates?

    9. Re:FDA Certification Part of the Problem by clodney · · Score: 1

      The problem is that the FDA is requiring that the patches/updates be 'tested the update for any effect on clinical function'--knowing how FDA testing can and often runs, this probably in practice translates to 'not at all.'

      If the tests are limited purely to the ones relevant and necessary, it'd be one thing, but the FDA has a well-earned rep for requiring tests that are antique and/or irrelevant. This is approximately like having somebody in upper management decide that any change whatsoever to the computers can only be done after huge, time-consuming & expensive battery of tests, and that you cannot skip any step under any circumstances whatsoever, even if you would like to know exactly how 'applying humorous sticker to monitor stand' could possibly result in software issues.

      It is not nearly that clear cut. Testing requirements vary depending on the risk classification level. Things like a pacemaker or insulin pump are Class III devices, and the requirements for that are indeed very strict. But PACS systems are Class II, which is not nearly as onerous. And both the FDA and the IEC-62304 standard are starting to acknowledge that not taking software updates is likely more risky than taking them, precisely because of the huge numbers of bugs and vulnerabilities found.

      But vendors also have no interest in patching old software. The company I work for is good about updating our OTS/SOUP with new releases, and doing a risk analysis and testing of the update, but we do that for new releases, not something we released 2 years ago. We want our customers to take the update (most are on maintenance, so it is free), rather than spend our time releasing updates to 4 or 5 different versions of software.

    10. Re:FDA Certification Part of the Problem by Anonymous Coward · · Score: 0

      We had a standalone system and we assumed that the same was true here: it turns out the approval was for exactly the opposite, an "up to date" system, not a hundreds-of-updates out-of-date snapshot. Risk-averse assumptions are a reason for slow change.

  5. Re:Dude! You got a Dell by bobbied · · Score: 3, Insightful

    Infected by Dell is more like it. Notice all the health (sick) companies use Dell. Notice that.

    Seriously? If you don't load your own image on the corporate computer you purchased from Dell, you've got a problem, not Dell. I don't know of *any* corporate customer of any reasonable size that doesn't have their own commissioning process that involves wiping the disk and starting over so they can be sure that the system is 100% what they want, and nothing else.

    Heck, one of the first things I do even with retail equipment is re-install everything to get rid of all the vender supplied bloat and "free" offers and get to a minimum install set. I do it for two reasons.. Clean out the junk and verify I have everything I need to recover the system in the future.

    --
    "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  6. PACS Systems Analyst here... by Anonymous Coward · · Score: 0

    Here's the long skinny.... and I'm working at one of the better, or 'leading' hospital systems in the US. (I use the term leading loosely there...). Possibly top 10...?

    With regard to the environment? Be afraid. Be VERY afraid. This OS and APP environment is half a decade behind on nearly every front, with the exception being AV, UserRoles and SecOps policy. Want the 'latest'? Pony up $$$! And you still won't be on the edge!

    A LOT of it, is vendors who do not follow the edge when it comes to security and maintenance. The other half of the equation is yes, FDA approval. Once a piece of gear is in place, it may not be updated for a year. Possibly ever. Or, unless you want to pony up $$$. I'm looking at you General Embelishment, as well as a WHOLE lot of others. BIG names here, and you've heard of them...

    Oh yea... Here's a kicker. You'd be amazed at how much of the kit here, is entirely built with FOSS!!!
    Various Linux dists? Yup
    Old openssl? Yup! pre-Heartbleed? Yup! Developed entirely using QT? Yup!

    I could go on, but I've stopped bothering to look....

    Money's pretty good though.... Cost of living is pretty low where I am, so the bank account is filling up nicely!

    I'm on the east coast, if you were wondering...

    1. Re:PACS Systems Analyst here... by Anonymous Coward · · Score: 0

      Our GE PACS runs entirely on Windows, and uses Java. I'd rather it be OSS, regardless of how secure it is. At least that way we could use something other than Java to display the images.

  7. There's an app for that by ArhcAngel · · Score: 3, Interesting

    The secure medical device market is heating up. It's why BlackBerry bought into NantHealth and partnered with them to deliver a secure mobile monitoring service.

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
  8. Viruses by Anonymous Coward · · Score: 0

    Clearly we need doctors for medical devices. Oooh, think of the insurance opportunities!

  9. Win2k by Rick+Zeman · · Score: 1

    "One contributing factor to the breaches: Windows 2000 is the OS of choice for "many medical devices." The version that TrapX obtained "did not seem to have been updated or patched in a long time," the company writes."

    Well DUH. I'd have been rather surprised if they had since Win2k was EOL'd 5 years ago.

  10. Hey Soulskill (and/or chicksdaddy), a little advic by Anonymous Coward · · Score: 0

    Subject verb object. Subject verb object.

    Until you master that, probably best to avoid trying to write sentences with multiple clauses ;-)

  11. Malware lurks on infected medical devices? by nickweller · · Score: 1

    "In the report, which will be released this week, the company details incidents of medical devices and management stations infected with malicious software at three, separate customer engagements."

    Wouldn't it be safer to run these medical devices on a dedicated Real Time Operating System (RTOS). That isn't susceptible to acquiring malware through normal operation ref.

  12. Vendors lie about FDA certification by slincolne · · Score: 1
    The story that vendors spin their customers about FDA approval an security updates is untrue.

    The main reason they put it out is that it helps reduce their costs.

    If you read the FDA advice at http://www.fda.gov/RegulatoryI... and at http://www.fda.gov/MedicalDevi...

    The key piece of advice is If manufacturers chose to use OTS software in their devices and vulnerabilities in OTS software can affect the safety and effectiveness of their networked devices, they have to act to keep their devices safe and effective.

    Locking their devices away behind firewalls is great, but you should also provide copies of the above documentation to the vendor and ask them how they act to "keep their devices safe and effective". Make sure your legal staff are involved in asking the question, and see how quickly their advice changes.

    Oh - and if you want bonus points in this - make sure that your purchasing people are across this issue and the question is asked during all procurement exercises, and that the contracts and specifications stipulate that the vendors are accountable for doing so.

  13. Windows XP is also prevalent in medical devices by slincolne · · Score: 1
    There is still a problem with medical devices running Windows XP Embedded.

    What's needed is an industry standard on how to partition and isolate these devices, while allowing appropriate inter-system communications to occur. Then at least there is something that people can hold vendors to and drive the level of technical maturity in the right direction. The sad thing is that these companies are locked in the 1990's mindset, and unless there us a blowtorch applied to their feet they will keep on selling equipment to their customers that is technically obsolete.

    1. Re:Windows XP is also prevalent in medical devices by l0n3s0m3phr34k · · Score: 1

      another question is...does MS even have a newer "embedded" OS? I've seen some beta embedded on MSDN, but nothing that had the adoption rate and support of XP. Pretty much guarantee that zero of those devices running XPE even have a MS path for upgrades for that hardware. Some startup could make a killing with an embedded OS that directly supports the hardware for upgrading all those devices.

    2. Re:Windows XP is also prevalent in medical devices by wbo · · Score: 1

      another question is...does MS even have a newer "embedded" OS?

      Yes, they do. There are several versions of Windows Embedded 7, Windows Embedded 8 and Windows Embedded 8.1 available depending on the needs/requirements.

      If I remember correctly there was an embedded version based around the Vista kernel as well although I never saw it used on any actual devices.

    3. Re:Windows XP is also prevalent in medical devices by l0n3s0m3phr34k · · Score: 1

      Since I think you know more about this than me, do you think any of these would work very well on my Samsung Q1? Too bad my MSDN sub doesn't have Embedded "Automotive"...I'm in the process of installing the Q1 in my Jeep and that sounds interesting. I guess I'll have to read over their HALs...

  14. Re:Dude! You got a Dell by John_Sauter · · Score: 1

    Heck, one of the first things I do even with retail equipment is re-install everything to get rid of all the vender supplied bloat and "free" offers and get to a minimum install set. I do it for two reasons.. Clean out the junk and verify I have everything I need to recover the system in the future.

    I do the same thing, and for the same two reasons. I once returned a server because I could not get it to work from the CDs they sent with it, after wiping the hard drive. When the vendor returned the server, the set of CDs was complete.

  15. Not Microsoft SQL by Anonymous Coward · · Score: 0

    In addition to running on unpatched Windows 2000 systems, the NOVA CCX devices use default SQL database administrator (DBA) permissions to protect access to the device’s back-end database, which holds patient data.

    This sounded fishy to me as Microsoft SQL Server doesn't have such a thing as "default SQL database administrator permissions." After digging through the actual report you eventually discover that the Nova CCX devices use SAP's SQL Anywhere v7.