We should favor positive strategies over punishments in achieving security gains. We should use punishments mostly where we can see intent to harm security or incentives are misaligned (for instance a weapons manufacturer intentionally leaking a weapon design resulting in a near peer adversary where none existed before in order to force a need for new weapons to be developed).

Cybersecurity and Infrastructure Security Agency (CISA) recently indicated they were pursuing liability against software developers to improve security performance in the USA. I interpret this as CISA saying they have exhausted options in dealing with specific corporate entities (hopefully in rare cases and not in the case of individual software developer persons). This comes from a space of concern about the security of the systems that are important to citizens from hard working CISA leadership.

CISA leadership have already clarified that they were talking about corporations not individuals having punitive liability for security problems with regard to Chinese incursion into critical infrastructure. Certainly individual engineers are unlikely to be able to overrule corporate leadership without a radical change in collective organization among software engineers. But what alternatives might make this security problem solvable other than individual liability or corporate liability? Should we even consider them as a matter of national policy?

I decided to write this article because I often use the tactic of "making it easier" for my teams when I am responsible for measured improvements in large infrastructures. I wanted to consider additional positive strategies available to nation state level administrators solving this problem out of sympathy for developers, administrators and security folks who face what is actually an important and difficult problem together. While many raised questions about how liability would work, I think its important to look at what alternatives could be useful to the administrator in addition.

Some alternatives

• Make it easy:

  •    build tools that help developers

  •    provide positive coaching and assistance

  •    provide training and automated test diagnostics that uncover problems early when cost and embarrassment are low

• Pay people for their efforts: Redirect a small percentage of cash in the federal national security budget to open source patching and security programs - a few billion dollars in direct payments to developers in linux etc

• Lionize our team: publicly praise and provide status acknowledgment to those who do this work

• Just do it: use federal staff and US Digital Corps to help supplement critical items patching and keep a standing team of rapid reaction staff with bandwidth to handle some portion of this

• Bolster surrounding software infrastructure: for instance make automated testing easier and supply standardized templates for various forms of testing infrastructure

• Science it: Fund academic research programs and add significantly (2x or 3x) to tenured well paid research positions in the USA university system - the USA spends almost nothing on science and research despite this being the single biggest contributer to progress and wellbeing in modern America in my humble opinion

• Do politics: use a windfall tax on profits from low security investment to build large scale repairs - in this way profitable companies pay for not investing while individual developers are not deterred from entering the market as a new entrant with an idea.

This shifts the paradigm from punishing teams that are hurting, to a cost of business that is consistently applied to profitable corporations who avoid national security work and costs.

A windfall profit has the benefit of not destroying an organization and avoiding deterring innovation because it is a tax on profits.

• Deter foreign advanced persistent threats: apply a price to those who exploit issues by changing the rules of engagement on foreign actors attacking national security items

• Harm reduction: work to limit the harms of a breach by down mixing data, rapid restoration of infrastructure after a compromise etc etc.

Why do I say we should have alternatives to a punitive approach

• Punishment doesn't work that well: corporations and certainly individuals are not rational actors - the myth of punishment being vital is perhaps made more clear by comparing Norwegian recidivism rates (22 percent) to American recidivism rates (75 percent) - harsher punishment in the USA isn't actually super effective (although both Norway and USA support having police as a national capability broadly, Norway is much stronger on changing the circumstances in which crime occurs and doesn't expect police officers to be effective on all social ills, whereas America has very high demands of the police staff effectiveness on all social ills and low investment in social safety nets, counseling, rehabilitation etc)

• Punishment nonetheless deters individuals of high competence from entering the field - they'll go into finance and other types of engineering instead

• Punishment moves investments in software and R&D to allied or hostile nations where these punishments don't exist

• It may be inaccurate - for instance punishing individual developers or corporations may not adequately identify the actual root causes of low performance which may be beyond an individual in many cases or a corporations direct control in some cases

• It may damage a capability which is nearly able to pace: taking a punitive action may damage a capability, whereas a small change in the circumstance that was positive may push that capability towards a much bigger improvement - harm vs help may lead to outsized declines in performance that was near to achieving significant paradigm changing progress for security

•  Liability is often hedged or insured against - meaning it becomes bundled as a low operational expenditure rather than a lump sum punishment for corporations

• We are already doing punishment via market forces and current liability structures which exist for products: Current liability is approximately 10 to 15 percent of shareholder value for a major incident in terms of actual market impacts without a national policy on punishment. I don't see federal staff being able to apply penalties at near this value impact in the current climate - its likely unreasonable to expect the civil service to exert this kind of forcing function in the current political climate where the civil service is under significant pressure to step down its influence.

• It may lead to lower transparency from corporates and the defense industrial base

• It creates a negative backlash against national leadership and disjunction in communication and cooperation

• The cost of punishment may not serve as well as positive strategies on the nation state level - all things being equal if we can choose between positive strategies and punishment, positive strategies may pay better in terms of improvements net net just because of the lowered cost of compliance and lower inefficiencies on business inherent in centralizing the positive strategies in a reusable way (utility effect of centralization)

In general the idea of punishment suites a frustrated perspective, but there is not super strong evidence that applying harsh punishment to people is necessarily the most effective method to achieve compliance and change. Just because corporates don't like it doesn't make it the most performant way forward. That having been said the police power is useful in situations where you need to take immediate emergency action to reduce a situation. If the situation is not an emergency and non-punitive measures have been exhausted a punishment might be the only thing left to try - in that case harshness isn't required, but timeliness and reliability would be of more importance if the potential losses were serious such as loosing control of infrastructure such as nuclear or water infrastructure elements. In my opinion that should be directed at a corporation, since individual engineers are likely overridden by management and retaliation against individual developers is commonplace.

So when is punishment of use in security performance in my opinion? Typically only as part of a mixed strategy where other items of positive reinforcement have already been attempted in my opinion. In those cases reliability and timeliness are more important than being harsh when positive means and harm reduction have failed. So harsh punishments are not important in my strategies around this. A mixed strategy of deterrence and reward may actually be quite agreeable to both corporates, individual software engineers and academia and produce alignment in principle at least. 

My wish is that we can tackle this really quite difficult problem together and achieve new records on assurance and new positive capabilities never seen before from our corporate, open source and national security administrators in a way that supports our success and progress as a nation and as individuals. Perhaps a mixed strategy with an emphasis on positive rewards might help to make this agreeable and useful for administrators, citizens and software corporations. In general I would prefer our federal staff to find they are mostly seen as allies and a powerful resource in tackling these problems and preferably rarely a punitive element. I think that maintains our federal staff morale and creates cooperation more positively where its possible to select that option and its within our power to secure the infrastructure using positive methods.