6 ms·

> The reason is simple - nothing really bad has happened that we can point at and say "ah, shit, let's all learn collectively". I know it sounds naive when I sa

> The reason is simple - nothing really bad has happened that we can point at and say "ah, shit, let's all learn collectively". I know it sounds naive when I say it, but there hasn't been a significantly consequential hack, leak, destruction, or anything related to cybersecurity where it led for concerns of people. How consequential does a hack need to be? Troy has collected literally billions of stolen credentials. Equifax has had high profile data leaks. Tens of millions of people have been directly compromised by ransomware (likely higher because that’s just the cases we know of) and you hear about state-sponsored hacks in the news all the time. The problem isn’t that computer security isn’t in the public consciousness. The problem is people are lazy and security often requires trading convenience. The problem is also that security isn’t free. So the business incentives just isn’t there. In other fields of engineering, people die when shortcuts are taken. Yet businesses will still take shortcuts, so governments have to legislate rules to save people’s lives. So why would you expect software companies to do better when the stakes are lower?

tokioyoyo 9d ago
> Tens of millions of people have been directly compromised by ransomware (likely higher because that’s just the cases we know of) and you hear about state-sponsored hacks in the news all the time. With no consequences. Everyone just churns along. It might be detrimental to the business a little bit, but from my personal experience, there's more effort in creating DR processes, rather than preventing an attack, exploit, leak and etc. I'm also not going to put much effort on stuff which has small returns in the worst case scenario. Like Equifax got hacked in 2017, and company is still doing fine. And that's like top tier data one could acquire.
- hnlmorg 9d ago
  Like I said, even in actual engineering companies will take shortcuts. And then what happens is the government has to step in. But there’s no appetite for government involvement in the tech sector in the US. And everyone moans when the EU does.
  - tokioyoyo 9d ago
    But why should the government should step in? Nothing of a big problem is happening. Like it all sounds bad and awful, in the end dilutes into a nothingburger and gets forgotten.
    - hnlmorg 9d ago
      As you started the conversation, companies never face consequences so are never incentivised. I’m not saying I’m in favour of regulation but if I were to answer your question: the reason one might argue for government intervention is precisely because of your point that self-regulation has failed to incentivise.
mike_hearn 9d ago
People aren't that lazy. The organizations getting hacked by ransomware aren't particularly lazy, they're often pretty productive within their domain. Hospitals, airports, etc. The actual problem is that computer security is a black hole. If you let it, it will suck in everything and destroy it. Nobody knows what works so you can spend infinite amounts of time and money on it, then still get popped by a teenager in Belarus. Your security team will accept no responsibility for this, there will be no falling on swords or personal liability, and they will just use it to demand even more money in an infinite spiral. So the average executive looks at this situation and says, OK, something we can put infinity effort into and still suddenly fail at without warning is a total non-starter. What are we obliged to do? How do we show we made an effort? And that's how you end up with a culture oriented around passing audits. It's not wrong, and it's not lazy. It's just really hard to do better because it's not clear how to set budgets without a concrete goal to aim for.
- hnlmorg 9d ago
  That’s not been my experience at all when working in DevSecOps. What actually happens in organisations is they define risks and then sign off what risks they’re willing to accept. Any business that looks at security as a binary value is running their business wrong. Period. And yes, people really are that lazy. There are countless studies that have shown just how lazy people are. It’s why shadow IT is a big problem in many orgs. And why consumers are constantly taken advantage of
  - mike_hearn 9d ago
    I think that's separate. You can define an obvious risk e.g. "we may be infected with ransomware" and the security spending / productivity costs to stop it are still unlimited because nobody knows how to solve it.
    - hnlmorg 8d ago
      You wouldn’t talk about ransomware like that for precisely the reasons you’d described: it’s a poorly defined open ended problem. You should tackle security in the same way you’d tackle any other kind of engineering initiative in IT. You break the problem down to identifiable tasks that can be easily marked as completed or not required (eg like developers track work in a KANBAN or sprint). So to take your ransomware example, instead of having a “ransomware” as a risk you’d instead talk about data loss as a risk. And the action items would be DR policies, automated backups, IaC tested in fresh environments, and so on. And the reason compliance standards like CIS and NIST can be valuable is because you then have a benchmark for code and infrastructure. And you’ll use their findings to define a plan of action. Some of their findings will be high risk and some of them won’t even be relevant to your specific architectural design. But that’s up to you as a business to review and decide. So you absolutely can know how much time and money to spend on these problems. And while it doesn’t provide guarantees (just like you don’t build houses in the UK to withstand hurricanes because nobody expects a hurricane in the UK but it’s not entirely impossible that one day such a weather phenomenon might occur), following the processes I’ve described does allow you to define how much effort to invest in security and what risks you’re willing to sign off. In a way, you already do this subconsciously when you make engineering decisions eg cloud agnostic / multi-cloud architectures vs on prem or which open source libraries to used based on community support. But the process I describe just documents the same decisions in a way that’s presentable to stakeholders.

tokioyoyo 9d ago

> Tens of millions of people have been directly compromised by ransomware (likely higher because that’s just the cases we know of) and you hear about state-sponsored hacks in the news all the time. With no consequences. Everyone just churns along. It might be detrimental to the business a little bit, but from my personal experience, there's more effort in creating DR processes, rather than preventing an attack, exploit, leak and etc. I'm also not going to put much effort on stuff which has small returns in the worst case scenario. Like Equifax got hacked in 2017, and company is still doing fine. And that's like top tier data one could acquire.

hnlmorg 9d ago
Like I said, even in actual engineering companies will take shortcuts. And then what happens is the government has to step in. But there’s no appetite for government involvement in the tech sector in the US. And everyone moans when the EU does.
- tokioyoyo 9d ago
  But why should the government should step in? Nothing of a big problem is happening. Like it all sounds bad and awful, in the end dilutes into a nothingburger and gets forgotten.
  - hnlmorg 9d ago
    As you started the conversation, companies never face consequences so are never incentivised. I’m not saying I’m in favour of regulation but if I were to answer your question: the reason one might argue for government intervention is precisely because of your point that self-regulation has failed to incentivise.

mike_hearn 9d ago

People aren't that lazy. The organizations getting hacked by ransomware aren't particularly lazy, they're often pretty productive within their domain. Hospitals, airports, etc. The actual problem is that computer security is a black hole. If you let it, it will suck in everything and destroy it. Nobody knows what works so you can spend infinite amounts of time and money on it, then still get popped by a teenager in Belarus. Your security team will accept no responsibility for this, there will be no falling on swords or personal liability, and they will just use it to demand even more money in an infinite spiral. So the average executive looks at this situation and says, OK, something we can put infinity effort into and still suddenly fail at without warning is a total non-starter. What are we obliged to do? How do we show we made an effort? And that's how you end up with a culture oriented around passing audits. It's not wrong, and it's not lazy. It's just really hard to do better because it's not clear how to set budgets without a concrete goal to aim for.

hnlmorg 9d ago
That’s not been my experience at all when working in DevSecOps. What actually happens in organisations is they define risks and then sign off what risks they’re willing to accept. Any business that looks at security as a binary value is running their business wrong. Period. And yes, people really are that lazy. There are countless studies that have shown just how lazy people are. It’s why shadow IT is a big problem in many orgs. And why consumers are constantly taken advantage of
- mike_hearn 9d ago
  I think that's separate. You can define an obvious risk e.g. "we may be infected with ransomware" and the security spending / productivity costs to stop it are still unlimited because nobody knows how to solve it.
  - hnlmorg 8d ago
    You wouldn’t talk about ransomware like that for precisely the reasons you’d described: it’s a poorly defined open ended problem. You should tackle security in the same way you’d tackle any other kind of engineering initiative in IT. You break the problem down to identifiable tasks that can be easily marked as completed or not required (eg like developers track work in a KANBAN or sprint). So to take your ransomware example, instead of having a “ransomware” as a risk you’d instead talk about data loss as a risk. And the action items would be DR policies, automated backups, IaC tested in fresh environments, and so on. And the reason compliance standards like CIS and NIST can be valuable is because you then have a benchmark for code and infrastructure. And you’ll use their findings to define a plan of action. Some of their findings will be high risk and some of them won’t even be relevant to your specific architectural design. But that’s up to you as a business to review and decide. So you absolutely can know how much time and money to spend on these problems. And while it doesn’t provide guarantees (just like you don’t build houses in the UK to withstand hurricanes because nobody expects a hurricane in the UK but it’s not entirely impossible that one day such a weather phenomenon might occur), following the processes I’ve described does allow you to define how much effort to invest in security and what risks you’re willing to sign off. In a way, you already do this subconsciously when you make engineering decisions eg cloud agnostic / multi-cloud architectures vs on prem or which open source libraries to used based on community support. But the process I describe just documents the same decisions in a way that’s presentable to stakeholders.