5 ms·

IMO, a big issue is conflating monitoring with management. Management is always going to have access, so maybe you should not enable remote management access o

by labawi 5y ago

IMO, a big issue is conflating monitoring with management. Management is always going to have access, so maybe you should not enable remote management access of everything to a centralized system? Make it lean and secure, possibly segmented, dual-factor, use HSM etc. Monitoring - there is no good reason why it should have access to anything. Make it ingest only (use firewalls and reasonable protocols), and you've cut out most of the "monitoring and management" vulnerabilities.

gostsamo 5y ago
There are trade offs there as well. Now you've decreased the attack surface, but still every foreign agent is a legalized rce. Observe that the case of Kaseya is not direct hacking of the agent, but a compromised update where firewall rules won't help. As I said, the next level of the argument is that this rce is dangerous and what it lacks is a privilege escalation. At the same time, you don't have a way to solve a problem that your monitor has alerted you for. Every solution proposed includes either a person at the location who does the job manually or a way to connect to the network from the outside which is vulnerable to similar attacks as before with added costs and possibilities to mismanage keys and passwords. Security vs convenience is a well-known dilemma that people very often love to solve in the most absolutist way.
- labawi 5y ago
  If the software used a one-way protocol, then unless you updated the closed-source agents, which are the parts I have the biggest issue with, there wouldn't be RCE. As for remote management. I'm saying you should wisely choose what needs to be remotely managed, what doesn't, what are the foundations for your security and then balance it with reasonable methods to secure access. Which would probably not be "Kaseya VSA Remote Monitoring and Management" for all your systems and devices. Yes, make sure you don't need on-site personnel to restart your web server, but maybe also don't expose management of your switch that you never reconfigure to your monitoring SW, and maybe use separate HSMs¹ or at least HSMs instead of the enterprise management system for the most important parts. ¹ e.g. FIDO2 ed25519 for ssh
  - gostsamo 5y ago
    So, now you have one hardware key that you have to manage either for all networks and therefore is both a single point of failure and constraint on availability, or you need to manage multiple keys with the ensuing chaos. Kaseya was hacked through a patch so the type of protocol does not matter and you are trading convenience for management overhead that you have to deal with because all of your clients and likely many of your employees are not in your HQ. I have the bad feeling that this achieves security through unavailability.
    - labawi 5y ago
      What are you actually arguing for? For the record, I think none of your points apply.

by labawi 5y ago

gostsamo 5y ago

There are trade offs there as well. Now you've decreased the attack surface, but still every foreign agent is a legalized rce. Observe that the case of Kaseya is not direct hacking of the agent, but a compromised update where firewall rules won't help. As I said, the next level of the argument is that this rce is dangerous and what it lacks is a privilege escalation. At the same time, you don't have a way to solve a problem that your monitor has alerted you for. Every solution proposed includes either a person at the location who does the job manually or a way to connect to the network from the outside which is vulnerable to similar attacks as before with added costs and possibilities to mismanage keys and passwords. Security vs convenience is a well-known dilemma that people very often love to solve in the most absolutist way.

labawi 5y ago
If the software used a one-way protocol, then unless you updated the closed-source agents, which are the parts I have the biggest issue with, there wouldn't be RCE. As for remote management. I'm saying you should wisely choose what needs to be remotely managed, what doesn't, what are the foundations for your security and then balance it with reasonable methods to secure access. Which would probably not be "Kaseya VSA Remote Monitoring and Management" for all your systems and devices. Yes, make sure you don't need on-site personnel to restart your web server, but maybe also don't expose management of your switch that you never reconfigure to your monitoring SW, and maybe use separate HSMs¹ or at least HSMs instead of the enterprise management system for the most important parts. ¹ e.g. FIDO2 ed25519 for ssh
- gostsamo 5y ago
  So, now you have one hardware key that you have to manage either for all networks and therefore is both a single point of failure and constraint on availability, or you need to manage multiple keys with the ensuing chaos. Kaseya was hacked through a patch so the type of protocol does not matter and you are trading convenience for management overhead that you have to deal with because all of your clients and likely many of your employees are not in your HQ. I have the bad feeling that this achieves security through unavailability.
  - labawi 5y ago
    What are you actually arguing for? For the record, I think none of your points apply.