See title.

Secure code costs time, money, resources, and better quality programmers.

I think part of the reason we're in this shitshow is because somewhere along the way it was decided that rather than making quality software, companies should just shovel out wherever crap appears to work, and release downloadable updates (maybe, if you can be bothered, etc) to patch over issues that arise, and keep up with this cycle of iteration. DevOps, essentially. Now it's starting to look like the cheap and quick and dirty approach isn't going to get a secure and quality product. Who'd have imagined?

So... I'm really not holding my breath.

Well see, the army of folks who actually make IT work were getting uppity and making too much money.

Can't have that, now can we?

Right now, the only potential "solution" I can see being proposed would be

* Closed source

* Locked down with certificates

* Developers having to pay to get code signed (or it cannot run at all)

* CRapp stores must get THEIR piece of the action

* Operating systems having internal certs built-in for signed code (which means stealing the master key is still possible)

Micros~1 has been trying this since Vista. 64-bit Win7 REQUIRED kernel components to be signed BY THEM. And of course "a moderate fee" is involved.

It's really just a matter of trusting the vendor, and limiting the scope of malware. Easy "administrator" access BY DEFAULT is STILL a problem, as is a 'sudo' derived security model that makes it too easy to just gain root access whenever you want it. Convenient, yes, but should NOT be :"the default".

So the REAL problem is still between chair and keyboard... and settling for "the default" even when it is a BAD idea.

You can't charge a substantial fee to force everyone signing their code since developers would simply flee to the next platform. Microsoft isn't going to risk that.

At best they'll throw up some pop-up dialog, but they'll never block you from running insecure code. That would be akin to suicide.

Wellllll, not true for kernel level stuff. Things on the level of NTFS.SYS, for example.

> Micros~1 has been trying this since Vista. 64-bit Win7 REQUIRED kernel components to be signed BY THEM. And of course "a moderate fee" is involved.

Of course they made it, Windows XP and all before allowed every shit to enter the kernel space. With Vista came a much stricter process isolation, including the kernel, which is still there in the newest insider builds.

As for drivers which require NO kernel space a signed driver is recommended as well.

As for the "fee", the certificate is the cost. If you want to release it to the public. But nothing is free.

And you can turn that driver signing off of course, if you want to test your own driver.

> So the REAL problem is still between chair and keyboard... and settling for "the default" even when it is a BAD idea.

That part is true, very true. Bad default settings in so many places, not just the Admin problem. Example? If you watch any administrator opening an MMC console, you will always see them moving the divider of the tree pane to the right. All of them. In every video. Wasting a few seconds on just that. Every freakin' time. Since Windows 2000.

Secure code is line a capture unicorn, a figment of the imagination.

Humans will always make flaws even when trying to produce secure code or in the tools used to produce or support the process.

True, but the industry isn't even trying to minimize it.

https://medium.com/@antweiss/learned-helplessness-in-software-engineering-648527b32e27

So much infrastructure and public and private organisations rely on software that was written once, a long time ago (*) and has not changed since. There are many perfectly reasonable explanations for this - (a) it costs a bunch of money to write software, (b) new software means new bugs, (c) people have forgotten (or never knew) what the original spec was for the software that already exists, so recreating it is actually quite a challenging task... and most importantly (d) the existing software 'just works' well enough to get on with your job.

So, yeah, call for secure software. But understand that the cost and time to provide end to end secure software in place of the stuff that's just sitting there already is astronomically high. Consider that Birmingham have spent nearly a billion dollars trying to replace their payroll system and you can get some idea of just how big the problem is.

(*) A long time ago being approximately three years - the half life of an average software developer in many organisations.

So much infrastructure and public and private organisations rely on software that was written once, a long time ago (*) and has not changed since. There are many perfectly reasonable explanations for this - (a) it costs a bunch of money to write software, (b) new software means new bugs, (c) people have forgotten (or never knew) what the original spec was for the software that already exists, so recreating it is actually quite a challenging task... and most importantly (d) the existing software 'just works' well enough to get on with your job.

"Works well enough" may be sufficient for the manufacturer. I work in a *very* regulated industry where we have SOP's for almost everything exept making a pot of coffee...

My $workplace acquired a multi-million dollar/euro/pound automation line. The machinery is reportedly fine and dandy but the software... Jesus wept.

- Multiple antivirus packages fired up the klaxons, but the manufacturer didn't want to do anything until $secops intervened and threatened to cancel the deal with $legal help. A clean AV scan was a requirement in the agreement.

- Ancient DOSBOX version was found running some ancient DOS software because they don't have the specs or can't be arsed ($$$) to compile code for anything recent. Probably both.

- Manufacturer somewhat recently moved from Windows to Linux to due to problems with updates (kinda understandable), because "Linux does not need updating". The systems are running already out-of-support distros and we are not allowed do anything about them (except firewall the bejesus out of them)

- Lots of security findings such as not supporting Secure LDAP; obsolete encryption standards etc etc etc

- Made in Germany by a very succesful company, consisting of "a bunch of mindless jerks who'll be the first against the wall when the revolution comes"

Yep, you describe the Real World. You cannot imagine how much SMB1 traffic I stumble upon during pre-check for Server 2022 Domain Controller upgrades and the "we need hardening! NOW!" screams. Even some Cisco products, with the newest software, try to create NTLM from 1993 within an SMB2 package, and the server says [1]"no" of course. This [2]techcommunity blog post is the exact identical situation, albeit a different vendor of course - fiasco products are not the only affected.

[1] https://www.youtube.com/results?search_query=computer+says+no

[2] https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-is-dead-long-live-smb/ba-p/1185401

- Ancient DOSBOX version was found running some ancient DOS software because they don't have the specs or can't be arsed ($$$) to compile code for anything recent. Probably both.

I've seen this EVERYWHERE. From factory floors to accounting.

Moving all desktops to Linux Mint would help a lot too.

I believe Capability Based Computing (essentially fine grained memory access protection) will reduce or even eliminate the hacking of computers. And the rest could be fixed with laws mandating strong passwords, 2FA, no default passwords in devices etc. etc.

Wouldn't

The only reason they dont target linux mint is because it is far less used in the commecial world than windows.

If mint was in use by 90% of the world's companies and government services they'd be trying to find the holes in it 24/7 and then exploiting them.

The other points are perfectly valid, but that will add cost to the products...

And it would never get rid of the primary cause of infection : the users, who would cheerfully click on a link from a friends e.mail saying "watch thiz fer lolz" 5 mins after watching a colleague being crucified for clicking on an unknown link in a spam e.mail.

Since Linux is the most used operating system in the world on servers, mobiles and embedded devices do you think they aren't looking for security holes in it 24/7? Think again I'd say. It's just that they can't find any (or very few).

Also, configuration plays a big part in the security of Linux. A well configured, locked-down Linux system is virtually impregnable.

"A well configured, locked-down Linux system is virtually impregnable."

- I think you've spelt unusable wrong there.

"Since Linux is the most used operating system in the world on servers, mobiles and embedded devices do you think they aren't looking for security holes in it 24/7? Think again I'd say. It's just that they can't find any (or very few)."

Yes, they are, and they find them. The main reason why desktops would be different is that, to hack into a server, you generally have to find something wrong with the configuration. And they do. Put out a Linux system on the public internet and within an hour you'll have had a thousand attempts to get into it. If there are vulnerabilities in that that are already known, those thousand will try them. It's not just trying basic passwords in SSH even though those are very common. But still, you have to find your own door in. The number of Linux-compatible ransomware strains, specifically designed because there are a lot of Linux servers and that's the most valuable thing to encrypt demonstrates this.

With a desktop, you have the other method of trying to get a user to do something for you. Email them a shell script and tell them to run it. The shell script downloads a binary and runs it. No vulnerabilities needed, you now have access to that user's privileges just as much as if that was a Windows box. Of course the admins can configure the box to make that more difficult, but they can do that to a Windows machine too and they don't. If you think anything is impregnable, you do not understand security.

You can't fix the user.

All current OSs are based on 40+ year old tech. Most security is made to protect the pathetic MS OSs weaknesses and over complexity to obscure issues and bloating the OS to the point that the security fixes use more RAM than the OS needs to run.

There is no fixing everything wrong with these, they were great in the day, that day is not today.

It is time for a new OS, built from scratch, based on security, 100% modular.

Unfortunately, 'tradition' trumps doing the right thing, so lets just bloat the next version of winblows and harvest more data.

Or they could rewrite Windows to a microkernel. Idem for Linux.

I wonder how much work it would be to get Windows or Linux running on top of a seL4 microkernel.

The CADT model is what got us into this mess.

I thought Windows NT is just around 31 or 32 years. Dave Cutler (well, probably not he alone...) made the genius choice to make the OS object oriented and let the process communication be object oriented as well instead of the POSIX "everything is a file + pipes must speak text between processes to transfer information" (with the exception of binary pipes of course, but then they are just bit stream, not an object).

But of course, everything has a big shoulder they stand upon, therefore you ought to say "100+ year old tech".

Forget demanding your "New OS", unless you start to make you own OS it won't happen.

As long as the same memory is used for both code and data there will be weakness. Ideally, all code should be in ROM, or at least in physically write protected RAM. But this makes any update/extension process rather painful, it also makes systems less flexible, and more expensive - so it's not likely to happen any time soon

The primary source of the malware infestation is that Click-and-Install OS running on x86 hardware. What's needed is a [1]Manhattan Project to design a replacement.

“ [2]Harvard architecture refers to a memory structure in which the processor is connected to two independent memory banks via two independent sets of buses”

[1] https://medium.com/lessons-from-history/the-manhattan-project-fffc8bc38646

[2] https://www.sciencedirect.com/topics/engineering/harvard-architecture

> a memory structure in which the processor is connected to two independent memory banks via two independent sets of buses

Which most modern CPU do. And interleave them for higher performance if you have more than one RAM Module.

With DDR5 it moved to interleave for every RAM Module for consumer hardware, so four busses are the lowest default now. And then take a look at current AMD EPYC with their 12 RAM channels (effectively 24, since every DDR5 module....).

if the social interaction works. Proven for many thousands of years before computer existed. Proven even by many animal species which have been on earth much longer than humans.

https://medium.com/@antweiss/learned-helplessness-in-software-engineering-648527b32e27

It is easy to say we need it - (like we need anti gravity drives) give us some new ideas and tell us how to do it.

You have to range from

developer stupidity - leaving userids and passwords in the code - or shipping with default passwords

to difficult problems where a code path didn't do something

will signing code really help? - and when the bad guys get a valid certificate.. ?

You get code blind - if you wrote the code, you assume that what you wrote is what is written. It is the old principle of getting someone else to check it.

Requiring browser controls like no cross site scripting is allowed would be a good start.

Enforce TLS

...

Lots of solutions are know - just not used.

There are a number of suggestions in these comments that advocate ripping out something that has existed for a long time and writing it from scratch. It's not that this wouldn't make something better if you could accomplish it, because a new OS, written from the ground up would probably be better than what we have now. There are two problems: you can't do it and it wouldn't be perfect. We do not have an environment where starting massive things from scratch is feasible. People don't want to have an operating system released four years from now to account for all the development effort required to get it working in all the places that Linux does which will need new software written to use it. They won't buy it, they won't run it. Even if they did, there is no infrastructure that will entirely prevent vulnerabilities. It's important not to let the perfect be the enemy of the good, but it is also important not to praise the good as perfect or it will end up looking bad when it arrives.

We will have to work on securing things at multiple levels. It is more work, and it is a lot more painful, but it is not something we can avoid. No secure hardware design will prevent an insecure operating system from existing. No secure operating system will prevent an insecure application from existing. No secure application will prevent an insecure administration from existing. Only by getting security at all of these levels will we get anywhere. It is not possible to do that worldwide, but we can focus on making sure the parts we interact with are as close to that as possible. This means that IT people cannot ignore their requirements to make and enforce security policies and maintain their equipment by blaming the software for allowing something insecure to exist and that software writers cannot rely on the administrators to work around the parts they didn't want to write securely.

I realize that this sentiment is as broad and difficult to implement as Ms. Easterly's statements, but I still think it's worth keeping in mind. We will not solve this problem in one single leap. We will likely not solve this problem at all, but we can at least improve our position.

So after computers have been around for over 80 years, suddenly people are going to start writing bug free code?

The only solution that will work AND is possible in the real world is making ransomware payments illegal.

Fools are far, far too ingenious.

All you can do is separate the fools from the clueful and only allow those with clues to access corporate computers. Which will never work because it would remove computers from the desks of middle and upper management.

Another option is to unplug all ordinary users from the Internet at large. Only allow the clueful to use computers on the Internet-connected section of the corporate network. I'm in favo(u)r of this, as the vast majority of corporate users have absolutely no reason to access the Internet while at work. This is not a panacea, however (see: middle and upper management).

Whatever happens, DON'T PAY THE VERMIN! As in animal and child training, rewarding bad behavio(u)r is contraindicated. (You do have a proper, verified off-site backup system in place, right?)

Everyone keeps saying cannot be done etc etc .... with lots of supporting stories .

BUT .... think of the cost to date of allowing all the crappy code to persist .... never-ending fixes, fudges and re-writes.

Is that cost *anywhere* near to the cost of *trying* to write better code that is secure by design !!!

I think it is worth trying, to establish the true scale of the problem .... instead of simply stating it cannot be done.

This is *not* like asking for a backdoor in some encryption, code does not need to be insecure or badly written; it is simply the standard we have been willing to accept.

So, try upping the standard that is acceptable !!!

:)

We don't want tech to be controlled by the state. The USSR route is a bad route to take.

By all means lock down critical infrastructure (it does not need and should not have a connection to the public internet) and mandate air gapping for data that needs to remain secure. But if people are not going to be allowed to write code and release it freely for others to use, without some form of state sanction and paid process, then we will need a rebel alliance helping to develop unsanctioned code on unsanctioned platforms operating beyond state control or tech development will end. If the last ten years in the UK have taught us anything, it is that the state is toxic to technology, innovation and pretty much every other pie it sticks its fingers in. There are ways to operate infrastructure securely and handle data securely without switching to a tech dictatorship and operating computing like the CCCP.

Instead, design out the problems. We should be switching to distributed systems with data held on people's own devices, rather than in honey pots on central servers. We can run secure social media sending encrypted data packets user to user via old fashioned e-mail with a quasi-distributed topology. Hold less ID about people - so that if you lose it, you lose as little of it as possible. Don't use biometrics (you can change your password but not your corneas). And use less tech. Some processes (as Birmingham Council and Edinburgh U have found out) would be better using a mix of simple tech and paper. Some things - hotel door locks, reporting energy usage, paying for things in shops - are simply more secure and more resilient when the physical, tangible and human element is retained.

'National security' covers a wealth of toxic political abuse. Don't let 'data security' be used in the same way to allow a state grab for control of tech by people you do not like and do not trust.