One chestnut from my history in lottery game development:

While our security staff was incredibly tight and did a generally good job, oftentimes levels of paranoia were off the charts.

Once they went around hot gluing shut all of the “unnecessary” USB ports in our PCs under the premise of mitigating data theft via thumb drive, while ignoring that we were all Internet-connected and VPNs are a thing, also that every machine had a RW optical drive.

  • body_by_make@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    Often times you’ll find that the crazy things IT does are forced on them from higher ups that don’t know shit.

    A common case of this is requiring password changes every x days, which is a practice that is known to actively make passwords worse.

    • xkforce@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      The DOD was like this. And it wasn’t just that you had to change passwords every so often but the requirements for those passwords were egregious but at the same time changing 1 number or letter was enough to pass the password requirements.

    • ditty@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      For our org, we are required to do this for our cybersecurity insurance plan

      • Natanael@slrpnk.net
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        Tell them NIST now recommends against it so the insurance company is increasing your risks

        • Hobo@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          The guideline is abundantly clear too with little room for interpretation:

          5.1.1.1 Memorized Secret Authenticators

          Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

          https://pages.nist.gov/800-63-3/sp800-63b.html

  • neveraskedforthis@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    Banned open source software because of security concerns. For password management they require LastPass or that we write them down in a book that we keep on ourselves at all times. Worth noting that this policy change was a few months ago. After the giant breach.

    And for extra absurdity: MFA via SMS only.

    I wish I was making this up.

    • JackGreenEarth@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Banning open source because of security concerns is the opposite of what they should be doing if they care about security. You can’t vet proprietary software.

      • DKP@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        It’s not about security, it’s about liability. You can’t sue OSS to get shareholders off your back.

    • Hobart_the_GoKart@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Care to elaborate “MFA via SMS only”? I’m not in tech and know MFA through text is widely used. Or do you mean alternatives like Microsoft Authenticator or YubiKey? Thanks!

      • Funwayguy@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        Through a low tech social engineering attack referred to as SIM Jacking, an attacker can have your number moved to their SIM card, redirecting all SMS 2FA codes effectively making the whole thing useless as a security measure. Despite this, companies still implement it out of both laziness and to collect phone numbers (which is often why SMS MFA is forced)

        • jaybone@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          To collect numbers, which they sell in bulk, to shadey organizations, that might SIM Jack you.

  • Punkie@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Worked a job where I had to be a Linux admin for a variety of VMs. To access them, I needed an VPN that only worked inside the company LAN, and blocked internet access. it was a 30 day trial license on day 700somthing, so it had a max 5 simultaneous connection limit. Access was from my heavily locked down laptop. Windows 7 with 5 minutes locking Screensaver. The ssh software was an unknown brand, “ssh.exe” which only allowed one connection at a time in a 80 x 24 console window with no ability to copy and paste. This went to a bastion host, an HPUx box on an old csh shell with no write access to your home directory due to a 1.4mb disk quota per user. Only one login per user, ten login max, and the bastion host was the only way to connect to the Linux VMs. Default 5 minute logout for inactivity. No ssh keys allowed. No scripting allowed, was like typing over 9600 baud.

    I quit that job. When asked why, I told them I was a Linux administrator and the job was not allowing me to administrate. I was told “a poor carpenter always blames his tools.” Yeah, fuck you.

  • Illecors@lemmy.cafe
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Hasn’t made life hell, but the general dumb following of compliance has left me baffled:

    • users must not be able to have a crontab. Crontab for users disabled.
    • compliance says nothing about systemd timers, so these work just fine 🤦

    I’ve raised it with security and they just shrugged it off. Wankers.

  • countflacula@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Removed admin access for all developers without warning and without a means for us to install software. We got access back in the form of a secondary admin account a few days later, it was just annoying until then.

    • glad_cat@lemmy.sdf.org
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      I had the same problem once. Every time I needed to be an admin, I had to send an email to an outsourced guy in another country, and wait one hour for an answer with a temporary password.

      With WSL and Linux, I needed to be admin 3 or 4 times per day. I CCed my boss for every request. When he saw that I was waiting and doing nothing for 4 hours every day, he sent them an angry email and I got my admin account back.

      The stupid restriction was meant for managers and sales people who didn’t need an admin account. It was annoying for developers.

    • Nicadimos@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      As a security guy - as soon as I can get federal auditors to agree, I’m getting rid of password expiration.

      The main problem is they don’t audit with logic. It’s a script and a feeling. No password expiration FEELS less secure. Nevermind the literal years of data and research. Drives me nuts.

  • al177@lemmy.sdf.org
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Oh man. Huge company I used to work for had:

    • two separate Okta instances. It was a coin toss as to which one you’d need for any given service

    • oh, and a third internally developed federated login service for other stuff

    • 90 day expiry for all of the above passwords

    • two different corporate IM systems, again coin toss depending on what team you’re working with

    • nannyware everywhere. Open Performance Monitor and watch network activity spike anytime you move your mouse or hit a key

    • an internally developed secure document system used by an international division that we were instructed to never ever use. We were told by IT that it “does something to the PC at a hardware level if you install the reader and open a document” which would cause a PC to be banned from the network until we get it replaced. Sounds hyperbolic, but plausible given the rest of the mess.

    • required a mobile authenticator app for some of the above services, yet the company expected that us grunts use our personal devices for this purpose.

    • all of the above and more, yet we were encouraged to use any cloud hosted password manager of our choosing.

    • Hogger85b@kbin.social
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I’ll.go one further with authenticator. Mobile phones were banned in the data center and other certain locations (financial services). Had to set up landline phone…but to do that needed to request it…approve it on my phone then enter data center security door run and answer the phone line with 60s like something in the matrix.

  • aredditimmigrant@endlesstalk.org
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Worked at a medium sized retail startup as a software engineer where we didn’t have root access to our local laptops, under the guise of “if you fuck it up we won’t be able to fix it” but we only started out with a basic MacBook setup. so every time I wanted to install a tool, ide, or VM I had to make a ticket to IT to come and log in with the password and explain what I was doing.

    Eventually, the engineering dept bribed an IT guy to just give us the password and started using it. IT MGMT got pissed when the number of tickets dropped dramatically and realized what was going on.

    We eventually came to the compromise that they gave us sudo access with the warning “we’re not backing anything up. If you mess up we’ll have to factory reset the whole machine”. Nobody ever had to factory reboot their machine because we weren’t children… And if there was an issue we just fixed it ourselves

  • Merwyn@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    They forbid us to add our ssh keys in some server machines, and force us to log in these servers with the non-personal admin account, with a password that is super easy to guess and haven’t been changed in 5 years.

  • Jeena@jemmy.jeena.net
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    There was a server I inherited from colleagues who resigned, mostly static HTML serving. I would occasionally do a apt update && apt ugrade to keep nginx and so updated and installed certbot because IT told me that this static HTML site should be served via HTTPS, fair enough.

    Then I went on parental leave and someone blocked all outgoing internet access from the server. Now certbot can’t renew the certificate and I can’t run apt. Then I got a ticket to update nginx and they told me to use SSH to copy the files needed.

  • GissaMittJobb@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Access to change production systems was limited to a single team, which was tasked with doing all deploys by hand, for an engineering organisation of 50+ people. Quickly becoming overloaded, they limited deploy frequency to five deploys per day, organisation-wide.

    Bit of a shit-show, that one.

  • AstralWeekends@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Made me write SQL updates that had to be run by someone in a different state with pretty much no knowledge of SQL.

  • _haha_oh_wow_@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    I used to work with a guy who glued the USB ports shut on his labs. I asked him why he didn’t just turn them off in BIOS and then lock BIOS behind a password and he just kinda shrugged. He wasn’t security, but it’s kinda related to your story.

    ¯\_(ツ)_/¯

    Security where I work is pretty decent really, I don’t recall them ever doing any dumb crazy stuff. There were some things that were unpopular with some people but they had good reasons that far outweighed any complaints.