• Hanzito (unregistered)

    This would be funny if it didn't hit close to home. We get audited every year, and it's a circus. None of the auditors have any technical background. They're all focussed on regulations. The only effect of certification is giving money to certifiers. Talk about BS jobs.

  • Darren (unregistered) in reply to Hanzito

    We're in the same position when it comes to auditors. Even though we're using one of the big guns - whose name might be an anagram of CwP - the people they assign to check our IT position know absolutely nothing about IT.

    We recently had our DR process audited (which we think is actually really robust). Spent an age and half explaining the process, who takes responsibility for which parts, etc. They didn't get it.

    So they just put all their effort into our documentation. their 'complaint' was that we had several documents and it all needed to be in one master document. The reason there were several documents is that they covered different parts of the process and would be undertaken by different teams at different points in the process. All these documents were actually referenced - and hyperlinked - in a master, overall document. Which they didn't bother looking at properly.

    They also complained we didn't have the documentation backed up - even though we showed them that it was stored in three different locations, all backed up at least daily and an automated process in place to ensure that a change was propagated across all backup copies.

    And of course our directors all acquiesced to the auditors and their report. So rather than telling them to take their nonsense away with them and never darken our door, we've now got a massive document that contains a copy and paste of all the other documents and a manual task to save it every week into a backup location.

    We've literally created more work just to appease an auditor who isn't fit to do their job.

    Apologies for ranting, but auditors wind me right up.

  • (nodebb) in reply to Hanzito

    The only effect of certification is giving money to certifiers. Talk about BS jobs.

    ISO 9001 certification is somewhat similar, and I imagine that the process for these "secure practices" audits shares another characteristic with the ISO 9001 audits...

    It's a little "politically incorrect" to explain it this way, but let's just say that the other characteristics involves the number of ... um ... ladies (or gentlemen, perhaps) of "monetised disvirtue" that the audited company can provide for the auditors.

  • RLB (unregistered)

    In this case, though, Theresa might be able to speed the process up considerably by uttering the magic incantation "HIPAA violation" within earshot of a representative from Legal.

  • Vera (unregistered) in reply to Hanzito

    I always understood certification to be there for management. "Here is a (very expensive) piece of paper that says this company does this thing, and does it according to our rules."

    A couple years ago, there was a story on here about someone hooking up a barcode scanner to their computer, rather than manually typing out the code. That whole project got axed since it wasn't "according to certified procedures."

  • (nodebb) in reply to Vera

    That whole project got axed since it wasn't "according to certified procedures."

    Which was semi-reasonable. It shouldn't have passed the initial review, and presumably it got axed because ... well, probably because someone in the review committee had reason (e.g. a zit on his fundament) to not want the project to go ahead at all.

    And the project lead should have been proactive about referencing the certified procedures, so as to be able e.g. to say, "We are aware that the barcode reader is not according to certified procedures, and we will launch the project without it. In parallel with the initial phases of development and use, we will seek an update of the procedures to allow the reader."

  • Steve (unregistered) in reply to Hanzito

    Oh I love the technical incompetence of some auditors... I had to spend a long time explaining that the SQL Server Service account had system administrator privileges in SQL Server, because that's how the server is actually able to run SQL Server. And no, we can't disable its permissions, because that would make the database not work anymore.

  • (nodebb)

    The real thing here is that security is overrated and people take it WAY too seriously to the point of ludicrousness.

  • Darren (unregistered) in reply to Steve

    Once had an auditor suggest - and flag as a high risk - that we should remove Internet Explorer* from our Citrix environment because staff could use it to access the internet...

      • It was 2014 and we had lots of legacy stuff that would only run, or be supported by the supplier, in IE.
  • (nodebb)

    I worked for a healthcare company where I found all the production DB and server passwords were stored in a text file in the code repository in plain text, accessible to half the company. When I pointed out this was a terrible idea, I was told we pass all our audits, and the company trusted its employees. This also violated HIPAA rules. I didn't work there very long.

  • Roby McAndrew (unregistered)

    Years ago I had a double glazing salesman proudly tell me that his company was BS5750 compliant. He clearly had no idea what it was or meant. I told him that BS5750 was obsolete and had been replaced by ISO9000 several years back. His face was a picture as he suddenly realised I knew more than him...

  • (nodebb)

    Though it may take longer to glue together a new jig for the SSDs

    What about a lump hammer?

    Having a jig that allows you to drill through the drive in a fixed position is probably not ideal because the manufacturer might redesign the circuit board and move the chips around.

  • Conradus (unregistered) in reply to jeremypnet

    I'd vote for a hard drive shredder. I don't care what tech you're using, reducing it to 5 mm strips will severely cramp its style.

  • (nodebb)

    Technically, they are 100% in compliance. The regulations state there must be a process and the process must be followed and the process must be verified as having been followed. Check!

    If you read the fine print, there is nothing in the regulations that stipulates data must actually be destroyed. There are two WTFs here: 1- The language allows for a process that does not actually destroy data to be "compliant"; 2- Nobody at this company finds it necessary to review The Process periodically to verify it a) continues to be compliant and b) actually does what it's supposed to do.

  • Conradus (unregistered) in reply to Bananafish

    The Process is there to satisfy the certification requirements. Therefore, it is doing exactly what it's supposed to do.

  • Joe (unregistered) in reply to jeremypnet

    SSDs are so much smaller and lighter, and typically contain a much lower percentage of steel when compared to magnetic drives, a hammer is the first thing that comes to mind. It's only unsafe if you're not wearing eye protection. Sounds like fun, if I'm being honest.

  • (nodebb) in reply to Bananafish

    ISO 9001 is arguably worse. If you have a "quality manual" that specifies that you design and produce 95% +/- 2%points crap that can't even be reworked to make it good, and explains how to go about doing that, and you follow it, you're compliant.

    If, on a particular day, you produce 92% crap, you're out of compliance, and have to fix what you're doing that makes you produce too much good stuff, or you have to respecify and recertify your quality manual so that 92% is the new "average"...

  • (nodebb) in reply to Bananafish

    If you read the fine print, there is nothing in the regulations that stipulates data must actually be destroyed.

    So, regulatory compliance is a rat's nest of interworking things that sometimes so what they are supposed to do, and sometimes make things worse.

    However, there is some sanity. For example, today's most common auditing framework for technical activities is SOC (System and Organization Controls). SOC 2 is a report where the organization defines its own controls and a third party auditor verifies only that those controls are being executed. If you do a SOC 2 audit, you can claim that you hire a Voodoo expert to curse the hard drives so no one can make use of the data. If you make this your control, the auditor will simply look for the Voodoo vendor and the records that he performed his duties.

    However, a SOC 3 audit also has the auditing firm evaluate the effectiveness of your controls. In this case, dumb or outdated controls will be called out and the report will say so.

    Also, a SOC 2 report contains all the gory details. You use a SOC 2 by sharing the audit report with those who care that you are complying with the regulations. They can to see how stupid your controls are. SOC 3 reports are shorter and state the auditing firm is confident that your controls are effective.

  • Yazeran (unregistered) in reply to Conradus

    My favorite would be a pile of thermite - so much more vidually appealing to watch.

    Bonus points if you put the whole shebang on top of blocks of ice (for the last one, check mythbusters)

    Yazeran

  • Tim (unregistered) in reply to Conradus

    unless you have one of those dodgy SSDs that's just a micro-SD card in a big case - with a bit of luck it might pass between the blades unscathed ;-)

  • (nodebb) in reply to Steve_The_Cynic

    If you have a "quality manual" that specifies that you design and produce 95% +/- 2%points crap that can't even be reworked to make it good, and explains how to go about doing that, and you follow it, you're compliant.

    ISO 9001 was built on the premise that any sane organization would realize their processes are stupid by simply going through the exercise of writing them down and sharing them, then they would then fix them. That premise was shown to be severely faulty. SOC 2/3 took up the mantle of fixing that problem. SOC 2 by actually telling the reader of the report what the controls are, SOC 3 by adding an evaluation of effectiveness. For example this: https://www.ibm.com/downloads/documents/us-en/107a02e94bc8f778 , is IBM's SOC 3 report where PricewaterhouseCoopers attests that IBMs controls are effective.

  • Dev tool guy (unregistered)

    What should have been the savings grace here would be the phrase "encrypted at rest". Actually rendering the drive unreadable should be like the 4th or 5th layer of protection, not the first one.

  • (nodebb)

    The reality is that it's really hard to write regulations like these that cover every eventuality, especially technologies that didn't even exist when the regulation was written. Just as the company needed to update their processes when they switched to SSDs, the regulators needed to update the compliance standard to include new rules for SSDs.

    Audits are most valuable when you fail them. Passing the audit doesn't ensure that the overall goals are met, but failing means you certainly have a problem. We recently did a security audit, now I have a couple dozen tickets in my queue, with varying priority levels.

    These regulations also often force companies to think different about their processes. When I first started working here, our payment apppication processed credit card numbers directly. When PCI compliance became a thing, we read through the spec and saw that it would be impractical for our tiny operation to meet it on our own; we were using Stripe for CC processing, and we switched to using their web form to offload the input processing.

  • Ichabod (unregistered)

    Yep. We deal with one set of accounting auditors annually, and another set of auditors from the state insurance department every few years. None of them know anything about our IBM midrange or its homegrown software. As long as we give the expected answers to their checklists (e.g., how often do we change passwords, what do we do when an employee leaves), we're fine in that area.

    But things are going to get real interesting in a couple of years. The new manglement has decided to replace both the midrange and the document management system with a "highly configurable," integrated, cloud-based, buzzword-laden system from a company halfway across the country whose programmers are offshore. They have only one other customer who sells the specific kind of insurance we do. And their big selling point is "you won't need an IT department, we do it all."

    Can't wait to see how that first audit goes...

  • (nodebb) in reply to Barry Margolin

    When PCI compliance became a thing, we read through the spec and saw that it would be impractical for our tiny operation to meet it on our own

    I once worked for a $100 billion dollar company with 4000 people in IT and we wouldn't touch a project in the scope of PCI.

  • (nodebb) in reply to Barry Margolin

    The reality is that it's really hard to write regulations like these that cover every eventuality

    They don't try any longer. HIPAA doesn't say how to encrypt your data at rest, it says that you must. It doesn't say what encryption is sufficient, it asks you to choose a choose a standard to follow and your auditor tests that you follow it.

    BTW, the original article says that the company processed PII and PHI, so they were probably in the scope of HIPAA. The un-destroyed hard drives shouldn't be an issue since that data is required to be encrypted at rest. One of the main reasons that it's standard practice to destroy things being disposed of is to prevent insiders diagnosing good hardware as bad and selling them on the side.

  • (nodebb)

    SSDs often are self-encrypting (OPAL), so just doing a secure erase is often all that's needed. What it does is regenerate the encryption key the SSD uses, which has the side effect of rendering all data on the storage erased as the key to decrypt them no longer exists so it's just random noise. The SSD also takes the opportunity to mark all the blocks as unused so it won't move around garbage data.

    HDDs doing a secure erase will take hours. SSDs will take under a second because of it.

    Note that even self-encrypting SSDs can have data recovered if the controller is functional enough to access the encryption key and you do a raw NAND read.

  • (nodebb)

    Back in the Dark Ages I registered my organization for a Class C address block (back when that wasn't a huge deal.) Auditor found out about it and asked how we got the "domain." I still get shivers thinking about how many emails went back and forth about that.

  • (nodebb)

    So who audits the auditors?

  • (nodebb)

    It took me until today to discover ISO 3103. That said, HIPPA violations still occur, even if you didn't know it was a violation. On a related note, I now have boot-time bitlocker! Too bad it's before the DisplayPort driver loads.

  • (nodebb)

    I used to work at a company that used a degausser to securely erase hard drives.

  • Darren (unregistered) in reply to prueg

    As far as I can tell, nobody. They declare themselves to be experts and people who don't know any better (directors, chief execs, etc) all bow down to them and their self-defined expertise.

  • MaryD (unregistered)

    The last company I worked at was in computer security. They used a nine pound hammer. Old tech - low tech - effective.

  • (nodebb) in reply to Steve_The_Cynic

    The way my boss used to express it is that if your process says you have to go to the pub on Fridays and then you don’t …

  • (nodebb) in reply to Roby McAndrew

    Had you been reading The Twelve Tasks of Asterix, specifically The Place that Sends You Mad? Bonus points for telling them the replacement was via Permit A 39 as stipulated by Circular B 65.

  • (nodebb)

    For a really kafkaesque experience, try passing a security audit when the software is in a public github repo and the auditors checklist assumes most of the security is a moat filled with live sharks and electrified barbed wire surrounding the software.

  • Officer Johnny Holzkopf (unregistered)

    Checklist ballet - you get what you pay for, and effectively you let your customers pay for it...

  • (nodebb) in reply to Jaime

    HIPAA doesn't say how to encrypt your data at rest, it says that you must.

    That is incorrect.

    https://www.hhs.gov/hipaa/for-professionals/faq/2001/is-the-use-of-encryption-mandatory-in-the-security-rule/index.html

  • (nodebb) in reply to Tim

    unless you have one of those dodgy SSDs that's just a micro-SD card in a big case

    Those are easy - pull the SD card, tape it to a piece of paper, then run it through the shredder ;)

Leave a comment on “A Hole in Your Plan”

Log In or post as a guest

Replying to comment #695123:

« Return to Article