Earlier quoted context omitted.
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…
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 t…
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.