3 ms·

Sometimes simple preventative measures aren't as simple as they might sound. How would you go about integrating yubikeys for login into multi-decade-old SCADA h

by Kalium 5y ago

Sometimes simple preventative measures aren't as simple as they might sound. How would you go about integrating yubikeys for login into multi-decade-old SCADA hardware systems? I'm a security specialist and I honestly wouldn't know where to begin.

chrisco255 5y ago
Is that the case with all of these hacks? How many would be prevented, is what I'm wondering? My mother's hospital was hacked this week and now they can't even clock in but they're not running SCADA
- Kalium 5y ago
  SCADA's a good example of systems that are difficult to secure for complex reasons. There are many others. You ask a very wise question. Unfortunately, I think it's unknownable. The best we know is that the answer is more than none and less than all. The more you get towards "all" the more prevention measures cost to implement. For instance, managing a mature backup and imaging operation at scale may be conceptually simple but is both complex in practice and far from free. Hospitals in particular are the scene of some interesting conflicts between security and usability. There are a lot of stories about health staff doing things like jamming open medication dispensing machines so that they could get on with the job instead of dealing with security measures they experienced largely as obstacles. Can you imagine throwing yubikeys into a scenario like that, where people already have an adversarial relationship with IT and security measures? What do you think is going to happen when someone forgets their key and can't send an x-ray to the remote radiology center? I have my guesses.
  - citrin_ru 5y ago
    Adversarial relationship with security are very often created by very annoying security requirements which do very little to improve security. Like requiring users to change all passwords ever 2 or 3 months and requiring a new password to have characters from every class (see also [1]). While all you need in the most cases is just minimum length requirement and some guidance how to choose a good password. If user will have to enter 16 charter password each time after HW key (like Yubikey) will be connected to a computer to unlock it, then users will leave it always inserted. Or password will be saved in a text file. If HW key will just work once inserted (or will require 4 digit pin) most users will comply. It is already 2nd factor in addition to some other password, it doesn't necessary need a strong password to use it. [1] https://passwordfromhell.com/ https://passwordfromhell.com/
    - chrisco255 5y ago
      Leaving a key inserted is still a vast improvement over the current situation. Yubikeys have to be pressed to generate a new code each time (as they expire after each use) and the situation you avoid is remote hacking especially via social engineering.
      - Kalium 5y ago
        Not all u2f keys require being touched. That's an optional hardware implementation detail, rather than a mandatory trait across all u2f devices. Yubikey sells keys that are commonly used by plugging them in, leaving them, and never again touching them. This effectively turns the computer itself into the second factor. Depending on the precise scenario, that may or may not represent an improvement. If the key is used as a second factor to authenticate to the network, then an infected Excel document will trivially ignore the involvement of a Yubikey as it uses the logged-in user's Kerberos ticket to spread. You're completely right, though. Even this would definitely cut down on phishing attacks that send users to fake websites pretending to be internal systems.
SilverRed 5y ago
We first start by moving all the non legacy stuff to MFA. There are so many easy targets in security that we can look in to first before declaring it impossible because of a handful of legacy apps.
- Kalium 5y ago
  You're absolutely right. There's often no shortage of low hanging fruit. I'm not suggesting we should declare anything impossible. Far from it! I'm merely trying to suggest that we should appreciate that not all things as easily fixed as they may seem at first blush. As all of us in software know, complexity can lurk in unexpected places.

by Kalium 5y ago

chrisco255 5y ago

Is that the case with all of these hacks? How many would be prevented, is what I'm wondering? My mother's hospital was hacked this week and now they can't even clock in but they're not running SCADA

Kalium 5y ago
SCADA's a good example of systems that are difficult to secure for complex reasons. There are many others. You ask a very wise question. Unfortunately, I think it's unknownable. The best we know is that the answer is more than none and less than all. The more you get towards "all" the more prevention measures cost to implement. For instance, managing a mature backup and imaging operation at scale may be conceptually simple but is both complex in practice and far from free. Hospitals in particular are the scene of some interesting conflicts between security and usability. There are a lot of stories about health staff doing things like jamming open medication dispensing machines so that they could get on with the job instead of dealing with security measures they experienced largely as obstacles. Can you imagine throwing yubikeys into a scenario like that, where people already have an adversarial relationship with IT and security measures? What do you think is going to happen when someone forgets their key and can't send an x-ray to the remote radiology center? I have my guesses.
- citrin_ru 5y ago
  Adversarial relationship with security are very often created by very annoying security requirements which do very little to improve security. Like requiring users to change all passwords ever 2 or 3 months and requiring a new password to have characters from every class (see also [1]). While all you need in the most cases is just minimum length requirement and some guidance how to choose a good password. If user will have to enter 16 charter password each time after HW key (like Yubikey) will be connected to a computer to unlock it, then users will leave it always inserted. Or password will be saved in a text file. If HW key will just work once inserted (or will require 4 digit pin) most users will comply. It is already 2nd factor in addition to some other password, it doesn't necessary need a strong password to use it. [1] https://passwordfromhell.com/ https://passwordfromhell.com/
  - chrisco255 5y ago
    Leaving a key inserted is still a vast improvement over the current situation. Yubikeys have to be pressed to generate a new code each time (as they expire after each use) and the situation you avoid is remote hacking especially via social engineering.
    - Kalium 5y ago
      Not all u2f keys require being touched. That's an optional hardware implementation detail, rather than a mandatory trait across all u2f devices. Yubikey sells keys that are commonly used by plugging them in, leaving them, and never again touching them. This effectively turns the computer itself into the second factor. Depending on the precise scenario, that may or may not represent an improvement. If the key is used as a second factor to authenticate to the network, then an infected Excel document will trivially ignore the involvement of a Yubikey as it uses the logged-in user's Kerberos ticket to spread. You're completely right, though. Even this would definitely cut down on phishing attacks that send users to fake websites pretending to be internal systems.

SilverRed 5y ago

We first start by moving all the non legacy stuff to MFA. There are so many easy targets in security that we can look in to first before declaring it impossible because of a handful of legacy apps.

Kalium 5y ago
You're absolutely right. There's often no shortage of low hanging fruit. I'm not suggesting we should declare anything impossible. Far from it! I'm merely trying to suggest that we should appreciate that not all things as easily fixed as they may seem at first blush. As all of us in software know, complexity can lurk in unexpected places.