Security Is A Political Problem

Every now and then I meet a (usually) young and passionate security practitioner, uttering sentences like: “But this is just the bare minimum, we have to do (insert here: firewalls, phishing simulations, SAST, bcrypt, encryption at rest... pick one). We cannot work without it!“

I’m afraid I have bad news. We absolutely can work without it, even though we disagree. I know you don’t want to hear this, hell I remember I didn’t like hearing this, but here goes. Security is not a technical problem, security is a political problem that sometimes uses technical solutions.

I’m writing this article as a reference point. It is critical for me to get this argument right, because it underpins nearly every other effort in security.

I would be happy to include a good differentiating definition here, but I didn’t find one. The best I’ve found is this article from 1935!! Note on the Distinction between Political and Technical Questions (Pitman B. Potter). It writes cooperation with an umlaut! Coöperation! Here’s the relevant excerpt:

... “political” refers to policy or general principle or theory of action, “technical” to application in detail of previously adopted policy or law. To some extent the policy is purpose, technique the means to the end.

For me, a purely technical problem is completely disconnected from human behaviour and emotions. There’s an obstacle and it needs to be cleared out, but fortunately that obstacle doesn’t change behaviour based on how well it slept last night.

On the other end of the spectrum, you have purely political problems, where all that has to be done is to make a decision. The issue is, it’s usually not your decision to make and you have a preferred outcome¹.

As an example, hashing and salting passwords in the database is a technical solution. But the political decision underpinning the solution is to store the passwords locally. Other decisions could lead to an identity provider like Google or Microsoft.

Everybody knows™ that political decisions are made in accordance with values². You have your values that might or might not be aligned with the values of the decision maker. And you need to employ political tactics to influence them.

Of course, most problems exist on this spectrum somewhere. Going back to IT, even a minor feature change might be stopped by a senior engineer reviewing the code as it fails abstract requirements like “quality” or “security”. On the other hand, sometimes you need to take reality into account when making business decisions.

You cannot possibly make any security without risk management. At some point, somebody³ has to say “this is a problem” and on the other end they’ll say “eh, this is fine.” It’s not really relevant if this conclusion was made from a huge excel sheet or a flip of a coin.

What is relevant, that any argument along the lines “we absolutely have to do X” can be discarded immediately with “no, we can risk it and hope for the best.”

If you’re looking for some universal floor that all companies should be doing, we have it: it’s compliance backed by government regulations. And even those are up to discussion all the time. Regulatory language needs interpretation that allows different details to suit the various approaches.

Ideally, you map all of the risks, you try to provide some estimates of impacts and probabilities, you identify business priorities etc... Then you come to someone who can give you budget to implement fixes and then they’ll tell you “no, we’re not buying all of that, that’s way too expensive.”

That’s where security begins. And that is also a prototype of a political problem - how do we assign limited resources to address known issues? Is the risk bigger than not shipping a new feature that would secure a new contract? Discuss⁴.

If you are responsible for security, I recommend taking the most conservative approach. Ideally, someone high up the chain will take responsibility for that risk - make them sign it and store this signature as evidence. It might come handy later.

Technical solutions are still indispensable for security. Once a decision is made (policy is written) we need to enforce it. That’s where the tech folks come in, they create technical solutions to implement security decisions.

If you are responsible for such a solution, please realize that it only exists based on a managerial decision and any day that decision can be changed. I recommend that you are aware of costs and provided benefits of this solution.

This in turn “motivates” people holding the budget so that your solution survives another day. If you can express how much does the solution cost and how much losses it prevents, the finance people are generally listening and will help you out.

Sadly, security doesn’t have a Return On Investment (ROI), there is no profit to be brought. Security reduces losses, so we have to adjust the formula to get Return On Security Investment (ROSI):

Expected loss is the current cost you’re paying for not having any solution in place (if this is zero, then you don’t have to do anything). Mitigation ratio is measuring the effectiveness, how well the issues are addressed. And any solution has its cost, this time expressed in currency.

Quick example: Say your app is sometimes down due to DDoS and if you tally up the damage it comes to 20k annually. Say you buy a firewall plan for 10k that cuts this downtime to 10% (mitigation ratio 90%). Putting this together yields:

meaning it takes more than a year to recoup the value of the yearly subscription. You should bargain to pay at most 9k per year in this case to break even.

You need some good data to create a convincing argument for costs and benefits of your solution. This might be a problem, as there are not that many high-quality data sources for incidents we’re facing. Arson is here for thousands of years, computers are about 100 years old, Internet is over 40 years old and AI as we “know it” is 5 years old. There are just not enough cases to build solid models from.

ROSI is not a silver bullet, far from it. It’s also very difficult to get accurate data and keep them accurate over time. I’d still argue it is a major improvement over the “semaphor approach” (red risks, yellow risks, green risks) and we should strive to objectively measure risks and their mitigations (even if we’re not good at it).

Not going to lie, realizing all of the above made me sad. I thought everyone will see the need for doing things “right” and for only increasing security. I thought people would strive to have their solutions as secure as possible. And I definitely thought I’d be solving technical problems.

The job is simply to provide as much protection as possible given the constraints of the company. In a sense, the ethical element is present⁵. There are values worth protecting even if they conflict with increasing the shareholder value. I think it’s important somebody protects these values and I strive to be that person.

Well, now I’ve found out that in many cases it’s actually rational to let it go. Beware of the swing in the opposite direction. This doesn’t mean security is useless, far from it.

I just had to realize that I should propose efficient solutions. And if they get rejected, I need to voice the concerns, but then commit, refocus and try again. It’s not pleasant to abandon your great plan, far from it.

Accepting this reality is painful. But if you follow through to the other side, you’ll understand the people at the other end of the table. Next time, please ask yourself: is this the right trade off? What does the other side value that I should be protecting?