The Weakest Link

  • Comments posted to this topic are about the item The Weakest Link

  • The interesting thing with these types of breaches is the bigger picture impact on the business too.
    Even if it later turns out that it wasn't as bad as potentially thought, the damage of having to notify is already done. Pretty sure I read that within a day, most of the key clients were assuring their potential employees that they were no longer using PageUp and had terminated their contracts.
    Many businesses are still not getting the level of pain that they might be in, if a breach occurs and they have to notify. Or if they will still have a viable business left at all.
    I've been saying for a while that it'll just take a few CEOs being BBQ'd on Four Corners (here in Australia, or Sixty Minutes or whatever elsewhere) after a breach, before other CEOs start asking about how they can avoid being BBQ'd themselves.
    Regards,
    Greg Low

  • This is why a layer security approach is a good design principle - especially when the attack surface expands. Similar to how we would look at availability issues with adding redundancy.

  • .. If you used a password to apply for a job that you use on other sites, change it. ..


    Good point. If we use different passwords for each website, then a break in one account is far less likely to leveraged a break in other accounts. I don't store full passwords in my password manager app, and I don't opt to use FaceBook or Google for cross-website single sign in. That way, security isn't a chain that be broken by a single link.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Jeff Mlakar - Thursday, August 23, 2018 9:05 AM

    This is why a layer security approach is a good design principle - especially when the attack surface expands. Similar to how we would look at availability issues with adding redundancy.

    The challenge is though that many current development frameworks and directions (including the ones pushed by Microsoft) target simplicity over security. How many apps do you see that use a single highly-privileged connection to a database, and can access anything in it at all? Or some, anything on the server? I was working at an ISV that was building apps for large financials. One of the requirements to install their app was "security admin" privileges on the server. That's just ridiculous.

  • GregLow - Thursday, August 23, 2018 6:35 PM

    The challenge is though that many current development frameworks and directions (including the ones pushed by Microsoft) target simplicity over security. How many apps do you see that use a single highly-privileged connection to a database, and can access anything in it at all? Or some, anything on the server? I was working at an ISV that was building apps for large financials. One of the requirements to install their app was "security admin" privileges on the server. That's just ridiculous.

    Right. We wouldn't grant an onsite programming contractor access to the server room simply because they request it, so why bend over for the ISV when they request full control of the server? Frankly, a lot of these old school vendors should be thankful that corporations and governments are still willing to shell out $$$,$$$ or even $,$$$,$$$$ a year for poorly engineered and rusty applications that havn't seen a meaningful upgrade in years. One approach to this situation is to initially grant the application admin membership so it's there during the installation, but then remove the account from this role once the application is up and running. If the application stops working, or if the vendor is onsite for maintenance, then temporarily add it back again. However, that's strictly my personal opinion, and I'll admit I'm a much better problem solver and engineer than I am a diplomat.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell - Friday, August 24, 2018 7:42 AM

    Right. We wouldn't grant an onsite programming contractor access to the server room simply because they request it, so why bend over for the ISV when they request full control of the server? Frankly, a lot of these old school vendors should be thankful that corporations and governments are still willing to shell out $$$,$$$ or even $,$$$,$$$$ a year for poorly engineered and rusty applications that havn't seen a meaningful upgrade in years. One approach to this situation is to initially grant the application admin membership so it's there during the installation, but then remove the account from this role once the application is up and running. If the application stops working, or if the vendor is onsite for maintenance, then temporarily add it back again. However, that's strictly my personal opinion, and I'll admit I'm a much better problem solver and engineer than I am a diplomat.

    Greg - I'll see your security admin and raise you sysadmin 🙂 Unfortunately, I have seen this way too much!
    One funny thing I have seen a lot is when a company puts up super strict change control procedures and then I catch them reading passwords (usually with sysadmin) from a notepad file. Unencrypted on the server.

  • GregLow - Thursday, August 23, 2018 6:35 PM

    The challenge is though that many current development frameworks and directions (including the ones pushed by Microsoft) target simplicity over security. How many apps do you see that use a single highly-privileged connection to a database, and can access anything in it at all? Or some, anything on the server? I was working at an ISV that was building apps for large financials. One of the requirements to install their app was "security admin" privileges on the server. That's just ridiculous.

    I've seen this as well, but when I've dug in, most of the time the needed security privileges were for the app to add users (and logins) only. I worked around this in a few apps, by creating the login and user and then having the app pick it up.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply