Comment by hnlmorg | Hacker News Reader

Comment by hnlmorg | Hacker News Reader

Parent Full thread

> 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?

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.

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

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.

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.

Isn't that just sidestepping the issue? Setting up backups isn't a security task, it's just normal IT which businesses do indeed spend on because there are clear goals and predictable budgets. But just being able to restore data isn't the same thing as not getting ransomware. As you say, you can't define the latter as a goal exactly because it's a security goal, and so will turn into an infinitely long checklist of things you could potentially do with no guarantee of payoff.

> Isn't that just sidestepping the issue?

No. It’s addressing the risks of the issue.

> Setting up backups isn't a security task, it's just normal IT which businesses do indeed spend on because there are clear goals and predictable budgets.

All IT security issues are just normal IT.

And the processes I described are how you get clear goals and budgets.

> But just being able to restore data isn't the same thing as not getting ransomware.

The backups are an example. It’s not an exhaustive list of countermeasures.

My point is “not getting ransomware” is a vague and undefined goal like “improve performance”, “add monitoring”, “improve UX”, etc. Any initiative in IT needs to have clearly defined objectives that can be broken down and marked as completed when done. It doesn’t matter if that initiative is software development, UI design or security.

> As you say, you can't define the latter as a goal exactly because it's a security goal, and so will turn into an infinitely long checklist of things you could potentially do with no guarantee of payoff.

Exactly. And that’s why my examples are not sidestepping the issue. They’re just definable subtasks around the risk you’ve identified.

> 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.

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.

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.

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.

Reply on news.ycombinator.com