6 ms·

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

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.

mike_hearn 8d ago
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.
- hnlmorg 8d ago
  > 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.

mike_hearn 8d ago

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.

hnlmorg 8d ago
> 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.