Is Software Regulation Coming?

I've been struggling lately to understand why finance and technology seem so separate when they appear to be so related. While they are similar in many ways, one area that is very different is that finance is highly regulated–money comes with liability.

Some Similarities of Technology and Finance

• Both are highly technical
• Both have their own massive set of jargon
• There is a distinct set of professionals in each
• Rapidly evolving: From the outside, it doesn't look like finance moves fast, but think about how quickly hedge funds and the like have to move to keep up with stocks. Some trading methods depend on extremely low latency. It's a never-ending battle, everything in equities moves daily, hourly, down to the microsecond. In some technology companies we deploy software hundreds of times a day and have to deal with the visibility of applications on a per second basis.
• Disruption: Tech is constantly trying to disrupt the markets (though it has its fair share of regulatory capture as well) and while we may not think of finance as a disruptive area, they are constantly creating new financial instruments, some innovative, some dangerous–such as the highly complex mortgage-backed securities that caused the 2008 financial crisis.

Some Differences Between Technology and Finance

• Finance deals with money at all levels, technology typically does not, and in fact it is often far removed from the actual economics of the underlying business. People working in finance actually (actually!) deal with money, however abstract it may be in some cases, but software engineers often have no notion of where the money comes from or how the business works.
• The core skills are different. While finance may have "quants" who write extremely complicated pieces of software, and at the other end of the spectrum, highly advanced use of spreadsheets (which run the world), for the most part the core skills are very different...finance deals with economics, accounting, risk management, financial modelling and analysis, whereas technology deals with code, algorithms, servers, runtimes, etc. Having said that, technology certainly has components around economics and risk management, but they aren't typically a highly surfaces.
• The working environments are different. Finance is (historically) more buttoned-up, while technology has a more entrepreneurial, laissez-faire feel, at least at the higher levels (see Patagonia vests). That said, developers at banks and telcos may not seem all that different from those working in the depths of financial giants. This may be a wild generalization.
• Compensation: While software engineers are often highly (highly!) paid, the average pay and the model behind it is very different to many working in finance.

One Major Difference: Regulation

We know finance is highly regulated. We know money in most banks is safe because of regulation and insurance. And frankly most of us want it that way because we spend all of our lives trying to get money and we don't want lose it. We have to put it somewhere (banks) and we have to retire, i.e. put that money into the stock market to get compound interest, and we need the stock market to go up, not down.

Thus, finance is highly regulated, and (usually) if you don't follow the rules, you go to jail.

Sam Bankman-Fried was sentenced to 25 years in prison by a judge on Thursday for stealing US$8 billion from customers of the now-bankrupt FTX cryptocurrency exchange he founded, the last step in the former billionaire wunderkind’s dramatic downfall. - https://globalnews.ca/news/10389487/sam-bankman-fried-ftx-fraud-sentence/

(One might ask what could a piece of fraudulent software even be. I'm not sure, other than some kind of virus/trogjan.)

But underlying all our banks, all our money transfers, the stock market, the bond market, all the financial tools...is regulation, and what's more, infrastructure built on that regulation.

These diagrams look familiar, and complicated.

That said, it is a relatively recent invention.

Banking regulation and supervision has emerged mostly in the 19th century and especially the 20th century, even though embryonic forms can be traced back to earlier periods. Landmark developments include the inception of U.S. federal banking supervision with the establishment of the Office of the Comptroller of the Currency in 1862; the creation of the U.S. Federal Deposit Insurance Corporation as the first major deposit guarantee and bank resolution authority in 1934; the creation of the Belgian Banking Commission, Europe's first modern banking supervisor in 1935; the start of formal banking supervision by the Bank of England in 1974... - https://en.wikipedia.org/wiki/Banking_regulation_and_supervision

But one big difference is that we've been dealing with money, or some form of barter, for thousands of years, and software for maybe ninety years. We haven't had the same period of time to create and deal with the software market as we have with the financial market before it was regulated. Even so, what we can do in a few years is very different from what we could do in a few years a thousand years ago. Our rate of change has increased enormously. For example, software is moving much faster than finance ever did–recent advances in artificial intelligence are a case in point.

Slowly but surely we are making our way to software regulation that looks like financial regulation.

Many in my industry are rooting for [software regulation]; they want strict liability for software vendors, they’d like to see professional licensing, and they’d love blanket bans or mandates for specific tech. The argument is simple: if the finance industry can thrive in the face of expansive regulation, so can Big Tech. - https://lcamtuf.substack.com/p/im-not-cheerleading-for-the-cisa

However, some areas of technology are regulated, such as personal information and privacy, with each country having its own requirements. However, when it comes to software quality and software liability, there is a little bit of regulation in that area. So when we talk about software regulation, what we really mean is are companies liable for their software. They have to produce quality software.

So...IS Software Regulation Coming?

Dan Geer seems to think so. Below his talk from waaaay back in 2014 is referenced in another recent talk by Daniel Woods.

Making secure software does cost more. It's a trade off. There's no doubt about it. And we need it desperately.

One recent advancement in this area is the CISA Secure by Design pledge.

On the one hand, the pledge is relatively generic and is of course "toothless," as Nate Nelson of Darkreading writes. There are no repercussions to not complying, even after signing. However, is this a step, or half-step, towards real software regulation?

"I think the Secure By Design pledge is a really interesting approach through private and government partnership to try to drive not regulation, but change what the expectation is for 'reasonable.'" Henderson says. "If you're a product that offers multi-factor authentication (MFA) or single sign-on (SSO), but it's behind a paywall, and one of your clients gets breached because they weren't paying for that, well, now are you negligent?" - https://www.darkreading.com/cybersecurity-operations/rsa-2024-cisa-secure-design-pledge-necessary-toothless

In their post, Cybersecurity gadabout lcamtuf ponders the fact that 68 companies signed the pledge. Well worth the quick read.

I’m not cheerleading for the CISA pledge

Earlier this week, the Cybersecurity & Infrastructure Security Agency (CISA) announced that 68 tech companies — notably including heavyweights such as Google and Microsoft — signed the agency’s voluntary information security pledge. The pledge compels the signatories to pursue a number of security improvements, from enabling two-factor authentication to rooting out

lcamtuf’s thinglcamtuf

Sections of the CISA Pledge:

The CISA pledge has the following pledges:

⏩ Multi-factor authentication (MFA): Increase adoption of MFA to defend against password-based attacks.

⏩ Eliminate default passwords: Reduce use of default passwords that enable easy access.

⏩ Remove entire classes of vulnerabilities: Decrease prevalence of vulnerability classes across products such as SLQ injection.

⏩ Automated patching: Increase installation of security patches by customers, potentially through automation.

⏩ Vulnerability disclosure: Publish vulnerability disclosure policies, authorize customer testing, provide reporting channels, and publicly disclose vulnerabilities per best practices.

⏩ Vulnerability transparency: Ensure accurate Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) fields in all CVE records for products.

⏩ Evidence collection: Increase ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer's products

While "generic" pledges, if these vendors could actually accomplish what they agreed to do, that would overall be a Good Thing™.

OK, If So, Then When?

I think that software will eventually be regulated in terms of quality, especially security quality, and that there will be consequences for non-compliance. However, I also think that this is likely decades away. Dan Geer's talk was ten years ago. The idea of software regulation will come up every year or two and then fade away into the ether. But I suspect that the original bankers didn't think there would be regulation either; that any regulation would put a stranglehold on profits. Yet, that didn't turn out to be true. Financial regulation has been useful: a stabiliser, a confidence builder, and a hedge against the total accidental destruction of financial markets.

It would be fascinating and strange to see a time when developers have to be registered and pass tests to write code, and that might not be as worrying as it sounds, as small pieces of software could still be like small businesses (big businesses = big regulation). It would be too heavy a burden for developers to have a limited company to produce open source code– the impact on OSS would be substantial without some sort of agreement and model to allow this to continue in a straightforward and simple manner. On the other hand we really need more secure software, which is an extremely difficult, perhaps impossible, effort.