• 516052 (unregistered)

    Over the too many decades that I lived the one thing that always astounds me is how far people are willing to go to stay working in places like this. How they happen is easy enough to see. That's not an issue. But the reason they stay like that for so long is only because workers, top to bottom are willing to put up with them and work around them just to get the job done. And that I do not understand.

    I understand staying in a place like that just long enough to find a better job. But that's it.

  • (nodebb)

    I work in a similar environment, and it's definitely annoying to deal with at times. It isn't nearly as bad as the article, though. If it takes that long to get anything done, the problem isn't really with the regulatory program, it's with your IT staff. Either the company doesn't have enough IT staff to manage the network and the new requests, or some manager is being a dick and refusing to approve the tools that the software engineers need. Where I work, it's mostly the former; we would definitely be better off with maybe another dozen or so IT staff, but stuff generally does get approved without much hassle once the request finally gets picked up by someone in IT.

  • (nodebb)

    could not add various hardware to the network (such as the company's own products, which made testing them awfully difficult) and so on

    They seriously didn't think of creating a separate QA network? That isn't the worst idea in the world in its own right, as it prevents traffic glitches in the main network from interfering in the QA process and vice versa.

  • (nodebb)

    "They seriously didn't think of creating a separate QA network?" I was in a firewall class, and the instructor's running joke was "You have a troublemaker on your staff? Someone who's always poking and prodding where they don't belong? Put them on an isolated network and have them do software testing."

    My "horror" story...I needed MS SQL tools (forgot the actual name, but you know so you can create databases and such?) so I downloaded MSwhatever.exe from Microsoft. Went to execute it...Access denied. I finally figured out that if I copied the file from to web space of my local instance of ISS (I was a developer, all of us had one for testing purposes) and downloaded from there, I could install the program just fine.

  • Darren (unregistered)

    This is less a failing with Cyber Essentials (which in the standard version is pretty much just a questionnaire and no further checks) and most definitely an issue with the consultancy and senior management just blindly implementing 'best practices'.

    An awful lot of companies forget that security and usability are on opposite sides of the seesaw. Increase one and the other suffers. The trick is finding that right balance (which is much easier to say than it is to do).

  • (nodebb)

    I once had an internship at a government facility, and they were prohibitively strict about what programs I could install on my computer. I asked my coworkers what to do and they said "Oh just install cygwin in user space, you can get whatever you want from that without ever needing the admin account."

  • Hmmmm 🤨 (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Darren

    consultancy and senior management just blindly implementing 'best practices'.

    The term "best practices" almost always signifies to me that someone doesn't want to do a lot of thinking. Often it works out, sometimes it doesn't.

    For example, preventing developers from running unapproved software almost always comes up as a point of contention. If it's framed as "security vs. usability" then the likely solution is to decide if the usability improvement is worth the security tradeoff. However, more direct solutions like trusting software signed with a particular signing key and configuring all of the build tools to sign every build created solves the problem with virtually no security tradeoff. You don't even have to secure the key very well as the main threat you're trying to protect from is rouge software choices. It's pretty far-fetched that some developer is going to download the Firefox source and sign a custom build just so they can run the browser of their choice.

  • (nodebb)

    It's pretty far-fetched that some developer is going to download the Firefox source and sign a custom build just so they can run the browser of their choice.

    It's utterly unheard of. Nobody would ever even think of such a thing, and you should report yourself to HR for allowing yourself to write words that might mean otherwise.

  • Guest (unregistered)

    At one place I worked they tried a security policy where all external drives and SD cards had to be fully bitlocker encrypted.

    Unfortunately our entire business was programming ancient handheld terminals for delivery drivers with the software delivered by SD card. Can you guess what the terminals didn't support? Policy still lasted a day or two somehow.

  • (nodebb)

    It's utterly unheard of.

    Have you ever built Firefox? It's not worth waiting for.

    On a more serious note, disallowing unauthorized software isn't really to prevent malware. We already use other methods of preventing that. Most threat actors nowadays "live off the land" and use already installed scripting packages rather than downloading pre-built binaries to circumvent this very protection.

    Disallowing unauthorized software has always been a method of controlling change rather than a pure security measure.

Leave a comment on “Securely Useless”

Log In or post as a guest

Replying to comment #705669:

Log Out

« Return to Article