• 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
    Comment held for moderation.
  • Joe (unregistered) in reply to jeremypnet
    Comment held for moderation.
  • (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
    Comment held for moderation.
  • Tim (unregistered) in reply to Conradus
    Comment held for moderation.
  • (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)
    Comment held for moderation.
  • (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.

Leave a comment on “A Hole in Your Plan”

Log In or post as a guest

Replying to comment #:

« Return to Article