• taladar@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    11
    ·
    23 days ago

    To be fair encryption at rest is one of those checkbox requirements that - in the absence of checks how it is implemented - is just implemented as a key next to the file that is encrypted.

    • sylver_dragon@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      23 days ago

      Ya, I know that’s exactly what’s going to happen. But, you have to start somewhere. Just getting management used to the idea that data must be encrypted is a start. That will then push the software vendors in the space to make fundamental changes, which will hopefully improve things a bit.

      I actually have a pretty good example from my time in the US FedGov space. We were required (by our checkbox security) to enforce FIPS-140 compliance on all our systems. When working to setup a server for a new product, it just would not run with FIPS-140 in enforcement mode; so, I started digging into the product and found that they were still using the MD5 algorithm in their user password hashing process. Given how much the vendor really wanted our business (we were their “foot in the door” for more FedGov money), I sent an email to our customer service rep essentially saying “ya, MD5 as part of the password hashing is a deal breaker”. A couple weeks later a new version of the product dropped and surprise, surprise, MD5 was no longer part of the password hashing process.

      The reliance on checkboxes sucks; but, they can be a useful club to make improvements. A shift to real security takes time and a lot of effort. But, that journey starts with a first step.

      • taladar@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        23 days ago

        True, compliance can be helpful to pressure vendors into doing what they should have been doing in the first place.