3 ms·

You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffe

You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? You are breaking convention, reinventing the wheel and complicating an already simple system. This isn't fallacy it is reducing a businesses cognitive load.

vel0city 3y ago
McDonalds employs the most cooks. They must have the best food. Staffing count doesn't guarantee quality.
AdieuToLogic 3y ago
> You still have to do your diligence. My point exactly. > You established what is supposed be a secure system yet that system failed due to provider security. This makes no sense. By your own recommendation, "provider security" is an AWS offering. > AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? > You are breaking convention, reinventing the wheel and complicating an already simple system. Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? And what wheel did I "reinvent"? Finally, was my identification of the common practice which is moving sshd off of port 22 the complication to which you refer?
- Sparkyte 3y ago
  Yeaaah you're trying poke holes. Problem is that there are larger holes in a network if you're setting up and safe guarding a VPN so you can SSH. Moving ssh if even needed at all should be to the provider's secured tools. https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/ https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-in... I really don't recommend extending responsibility for creature comforts. However you want to do this so be it. > This makes no sense. By your own recommendation, "provider security" is an AWS offering. Are you stating your system is infaliable? So why would you want to bear the infaliable claim and not shift it to the company providing it? > What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? Tooling takes a team to support it. You think every company can afford a team to manage that tooling? And why should they? Not all businesses are tech companies but still need a digital footprint. They need to be selfconcious and choose provider practices to get the most out of them. > Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? Providers own the responsibility of their technology. In terms of failure if access is correctly configured and managed, yet their technology fails they owe your businesses it is very simple. > And what wheel did I "reinvent"? Implementing old security practices. Why wouldn't you move to be better pratices and prevent larger holes in your network? Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system.
  - landemva 3y ago
    This sums it up, "The convention of using a cloud platform is to use a cloud platform". If you rent compute space, then you trust them to responsibly use the hypervisor instead of snooping. If you trust that or not, you are all in and may as well cement over the external port 22.
    - Sparkyte 3y ago
      10000% on the money.
  - AdieuToLogic 3y ago
    > Yeaaah you're trying poke holes. No, I am trying to remind you of the topic which was under discussion. To wit: The Reluctant Sysadmin's Guide to Securing a Linux Server > Are you stating your system is infaliable? A straw man fallacy (sometimes written as strawman) is the informal fallacy of refuting an argument different from the one actually under discussion, while not recognizing or acknowledging the distinction.[0] > Tooling takes a team to support it. See above quote. > You think ... You do not know what I think nor my experiences, so please do not be so arrogant as to assume so. >> And what wheel did I "reinvent"? > Implementing old security practices. Again, please refer to the *article under discussion*. In the event it remains unclear, I will restate its title: The Reluctant Sysadmin's Guide to Securing a Linux Server > Why wouldn't you move to be better pratices and prevent larger holes in your network? See previous strawman definition and link below. > Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system. Again, see previous strawman definition above and link below. Note that the only ssh-related recommendation I proffered was: Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth. This is a well-known, albeit very small and insufficient by itself, part of helping to reduce attack vectors. As to "sketched up VPN and SSH system", I have no idea as to what you are referencing. Perhaps this is a recollection of a previous engagement wherein decisions made remind you of a bad situation similar to, but different than, this? HTH 0 - https://en.wikipedia.org/wiki/Straw_man https://en.wikipedia.org/wiki/Straw_man EDIT: corrected spelling from "waas" to "was"

vel0city 3y ago

McDonalds employs the most cooks. They must have the best food. Staffing count doesn't guarantee quality.

AdieuToLogic 3y ago

> You still have to do your diligence. My point exactly. > You established what is supposed be a secure system yet that system failed due to provider security. This makes no sense. By your own recommendation, "provider security" is an AWS offering. > AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? > You are breaking convention, reinventing the wheel and complicating an already simple system. Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? And what wheel did I "reinvent"? Finally, was my identification of the common practice which is moving sshd off of port 22 the complication to which you refer?

Sparkyte 3y ago
Yeaaah you're trying poke holes. Problem is that there are larger holes in a network if you're setting up and safe guarding a VPN so you can SSH. Moving ssh if even needed at all should be to the provider's secured tools. https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/ https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-in... I really don't recommend extending responsibility for creature comforts. However you want to do this so be it. > This makes no sense. By your own recommendation, "provider security" is an AWS offering. Are you stating your system is infaliable? So why would you want to bear the infaliable claim and not shift it to the company providing it? > What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services? Tooling takes a team to support it. You think every company can afford a team to manage that tooling? And why should they? Not all businesses are tech companies but still need a digital footprint. They need to be selfconcious and choose provider practices to get the most out of them. > Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention? Providers own the responsibility of their technology. In terms of failure if access is correctly configured and managed, yet their technology fails they owe your businesses it is very simple. > And what wheel did I "reinvent"? Implementing old security practices. Why wouldn't you move to be better pratices and prevent larger holes in your network? Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system.
- landemva 3y ago
  This sums it up, "The convention of using a cloud platform is to use a cloud platform". If you rent compute space, then you trust them to responsibly use the hypervisor instead of snooping. If you trust that or not, you are all in and may as well cement over the external port 22.
  - Sparkyte 3y ago
    10000% on the money.
- AdieuToLogic 3y ago
  > Yeaaah you're trying poke holes. No, I am trying to remind you of the topic which was under discussion. To wit: The Reluctant Sysadmin's Guide to Securing a Linux Server > Are you stating your system is infaliable? A straw man fallacy (sometimes written as strawman) is the informal fallacy of refuting an argument different from the one actually under discussion, while not recognizing or acknowledging the distinction.[0] > Tooling takes a team to support it. See above quote. > You think ... You do not know what I think nor my experiences, so please do not be so arrogant as to assume so. >> And what wheel did I "reinvent"? > Implementing old security practices. Again, please refer to the *article under discussion*. In the event it remains unclear, I will restate its title: The Reluctant Sysadmin's Guide to Securing a Linux Server > Why wouldn't you move to be better pratices and prevent larger holes in your network? See previous strawman definition and link below. > Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system. Again, see previous strawman definition above and link below. Note that the only ssh-related recommendation I proffered was: Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth. This is a well-known, albeit very small and insufficient by itself, part of helping to reduce attack vectors. As to "sketched up VPN and SSH system", I have no idea as to what you are referencing. Perhaps this is a recollection of a previous engagement wherein decisions made remind you of a bad situation similar to, but different than, this? HTH 0 - https://en.wikipedia.org/wiki/Straw_man https://en.wikipedia.org/wiki/Straw_man EDIT: corrected spelling from "waas" to "was"