Security through obscurity is dead, and AI delivered the fatal blow

The term "security through obscurity" describes an old idea that networks and systems will remain secure so long as their architecture, along with any vulnerabilities or other weaknesses, remains secret or hidden. It was never a sound strategy for protecting sensitive assets and systems, but many organizations leaned on it due …

[tiggity]

What idiot has PLCs accessible via the wider internet?

That's a problem just waiting, whether a human or "AI" finds the exploit

[Paul Crawford]

I was going to say exactly the same thing. A lot of control systems were never designed for security against any serious effort, and those that offer some security turn out to be piss-poor at that job anyway, so don't go there.

Seriously, trying to find and fix dozens of (possibly obsolete / unsupported / piss-poor supported) specialist hardware is a hiding to nothing. In that case you need to erect serious barriers to entry that can be supported, patched, and audited. And that is not just buying a Cisco, etc, "security appliance" as those have fallen time after time. Really, you need to look at multiple barriers and to consider the defence of the remote machines as well, as those (usually Windows laptops) have a far from stellar record against email phishing, attached image preview, etc, etc, over the years.

[Anonymous Coward]

I don't think it's an oversight though in most cases, it's the limit to the implementers knowledge / competence...and willingness to accept that there is actually a problem. In a few sectors, the egos are insane. There are sectors in tech that are quite cut off from regular folks being able to enter and they act like a kind of echo chamber...a lot of the people in think they're hot shit and untouchable because of who they are, their qualifications etc...

If there was a venn diagram with one circle representing those that implement security and one circle representing those that attack it, the circles wouldn't overlap, they wouldn't be close.

We've all been in meetings where "the questions" are raised..."What are the chances of that?" or "How many people out there would actually think of that?" etc...questions that at answered by reflecting back on themselves and observing the skills around them and working on the assumption that they are the leaders in a given field and particularly in their domain of market presence.

I've been on both sides of the fence, trying to secure things and attacking things to test them...I can see both perspectives...and it's much harder to get your point across on the defensive side because of pure ego sometimes. On the offensive side, there is much less ego and a team on that side tends to work more collaboratively and cohesively because you all have the same goal..."get in"...on the defensive side the goals are different...particularly the motivations...there is a pecking order on the defensive side, promotions to be had, payrises etc etc...

A classic example I regularly cite is a company I inadvertently tried to help with a serious problem. I was running an event with my wife, totally unrelated to tech, it was related to her profession which is in the healthcare field...we put on a small trade event where practitioners could come along and hear talks and industry suppliers could come along and demonstrate / promote their wares...really simple stuff...anyway, one of the companies that came to promote their product was a software house, they made a platform for managing patient records that sort of thing...bookings, note taking...you get the gist...I sat in on that demo, dude went to the front, plugged his laptop into the projector and proceeded with his presentation and then ended with a live demo of the software...one aspect of which was their customer portal, where you could login, manage your licenses, pay your fees etc etc...the URL for it was visible on his demo so I decided to take a quick look...my interest was piqued when I saw the main desktop application was written in what looked like Visual Basic...it had that kind of vibe to it...so I pretty quickly smelt "legacy" and I could just *sense* that the team behind the software was probably led by an older guy who likely had been dining out on this single product for a long time...it just had that musty dank smell to it...a lot of you know what I mean...this was an example of tech that came from a sector that usually requires academic access...you can't just apply for a job in it...a know a guy who knows a guy sector.

Anyway, I proceeded to find several SQL injection vulnerabilities on the client portal and from there I was able to get the installer and generate my own license...so I installed the software, activated my license and started to have a crack at that as well...it was again vulnerable to SQL injection and some other classic VB vulnerabilities (the classics, re-enabling disabled buttons to uncover actions, snadboys revelation...you know, the greatest hits)...by the time the dude had finished his talk...oh yeah, I did all of this during the presentation, it was 30-45 minutes of clattering this thing...he finished the talk and I approached him, showed him my findings and the dude was grateful for the findings and said he would go back to the developer and get them fixed. He was the sales director from the company. We exchanged numbers...and I heard nothing for a while...a few weeks later, I got a call inviting me to a meeting to discuss the issues I found and potentially coming in to help fix them...same guy, sales director...nice chap..so I agreed and we scheduled a meeting...when I finally got there (about a week later)...there was the sales director at the meeting room table, the lead dev (who was also the CTO/CEO and owner of the business) and a couple of other execs...I didn't bother dressing up for this as I was there in a voluntary capacity and didn't really think of this as potential opportunity for business, I thought I was just going in to demonstrate the bugs and show them how to repeat them and therefore test them in order to fix them...this was absolutely not the case, the CTO/CEO absolutely laid into me...he was on the defensive right from the get go...he spent a good 20 minutes trying to discredit me before I'd even said or done anything...I didn't rise to it, but I did make a mental note that the guy was a prick...after he'd attacked me, I decided to take a different approach to demonstrating the key problems...instead of using my own laptop, I opted to use the PC that was in the meeting room...they logged me in as a guest account, I couldn't install anything and I was restricted to basically just the browser and a copy of their tool running...I proceeded to demonstrate what I found during the talk plus a few other bugs I'd found since...well this CTO/CEO absolutely fucking lost it...after calling me a "scruffy tramp" and a "nobody" he proceeded with the classic "do you know who I am?" bullshit and how I must have faked my demo...and rattled off his PhDs and where he went for University (very prestigious, one of the big two) and all that crap...he then stormed out and disappeared somewhere...all while the other execs were laughing their tits off, one of them was laughing so hard, it was like he'd just seen the funniest thing ever...it turned out that the product was his University project from around 15 years in the past and he had in fact been dining out on it for a looooong time...the other execs were sick to death of him because he was difficult to work with, wouldn't allow anyone to touch the code without his direct oversight, there was no change management...the development was basically run like a bedroom hobby...it was a huge mess...CTO had a massive ego.

The other execs were very cordial and spoke to me about the possibility of helping with improving the code base, maybe upgrading it and a bunch of other stuff I didn't expect...reluctantly I might add (because I'd seen the CTO throw his toys out of the pram and storm off), they assured me he wouldn't be a problem and they'd sort him out. On the way out, I passed the CTO outside he was trying to light a cigarette, but he was shaking because he'd seen me...I think he was angry to the point he couldn't keep a fag steady...I'm pretty sure if he wasn't occupied with the fag, he'd have taken a swing at me. He looked "ready to go"...he had the body language of a guy that was staring straight at the guy that just fucked his wife. Absolutely boiling...I hadn't even gone that far...I probably could have got the reverse engineering tools out and gone a lot further, done a network audit...all kinds of potentially even scarier shit...perhaps that is why his piss was steaming, because he knew if I'd been granted permission to see the whole codebase and go further, I'd have found even more problems and possibly even worse problems...and he would have been ruined...by a "tramp".

Fast forward a month, I hadn't heard anything from any of them for a while...I got a call apologising for taking so long to get back to me and for the behaviour of the lunatic...they explained that they were struggling with the dude, he'd gone full turtle...locked down all access to the codebase, passworded everything that he could...he basically put up some massive walls with the intention of preventing anyone getting to the codebase and potentially working on it...apparently I'd rocked him hard and the guy went into some kind of breakdown...they were in the process of now getting rid of him and seizing control of everything...but were struggling. I didn't offer to help here, even though I probably could have...because I just didn't want to deal with this nutter.

After that, I never heard from them again...I did check in on the company site etc after a while, and they'd shut up shop...sold the customers etc to some other company and the software was gone. This was about 12 years ago at this point...up to that point, this was the craziest experience I'd had disclosing a bunch of bugs and security lapses, possibly the closest I've been to actually being punched...I'd like to say it was the last...but it wasn't...there have been many over the last 12 years...not quite as severe as the CTO here...but almost...it is always...*always*...academics as well...not once have I caused a non-academic CTO/lead dev to have an absolute meltdown...well there was one, but he dragged himself back in line again fairly quickly and reached a point of acceptance...he was eventually very friendly and grateful...once he grasped that I wasn't there to destroy him only to help.

These days I don't even bother disclosing anything, even though I find them everywhere...I'm so bored of the primadonnas, egos and the fucking legal threats, I'm too old for that shit now, I just haven't got the energy...I'm pretty sure there are lots like me...probably with similar experiences who just can't be arsed anymore because it's way too much effort trying to help these people, especially when they can't see that they need help and actively resist it...I think this is a contributing factor making cybersecurity worse...why fix things when you can just legally threaten someone, right?

[LateAgain]

What's more likely is a targeted attack on the windows desktop that runs all those control devices.

Avoid anything that alerts the end users and it'll just sit there.

[abend0c4]

What idiot has PLCs accessible via the wider internet?

The problem is that if you have a remote site, those PLCs will likely be accessible by something. In the old days, it might simply have been a modem that anyone could dial up if they had the number and, maybe, a password. Even if the remote site weren't on the Internet, the password and telephone number will likely be in a document on a computer that is reachable from the Internet, if only by some vulnerability. If you secure the link, the same, or some other, vulnerability may well give access to a system within the organisation that has access to the link - or to information that might enable you to get it.

The situation now is that, if you have a high-value target, it's feasible to find out a vast amount of information: architectural and engineering blueprints; personnel details; staff rosters; disaster recovery plans; security audit reports. If you can't get through the front door, there are plenty of alternative ways in and we now have the means to explore them all at an acceptable cost.

We have to think about critical systems more critically. That means engineering them to fail "safe" even if the remotely controllable components are compromised. It means better physical security. It means printing sensitive documents and keeping them in fire safes rather than on computer systems. It means simplifying systems so they can reasonably be monitored. It means shifting the balance between convenience and resilience so that there are multiple levels of air-gapped containment. It means starting with the assumption that the environment is fundamentally hostile.

It's not just the link to the remote site that's vulnerable: everything is vulnerable in our brave new world. It's not just PLCs, either. If you look at what happened to Marks & Spencer or Jaguar Land Rover you can see that the real danger is the tight integration of systems - it might be wonderful for logistics and the realtime management dashboard but the result is existential contagion when any one part of that conglomeration is breached. Whereas we're unlikely to go back to physically moving tapes from computer to computer, we are going to need something logically equivalent in its ability to ensure the input and output of subsystems is rigorously policed.

[Anonymous Coward]

The accountants.

Expensive : custom installed secured lines between the remote and monitored site, and/or permanent on site staff.

Cheap : remote internet monitoring with a redundant internet connection if its not too expensive.

You can see which one they will go for.

[Pete 2]

All security is temporary

> security through obscurity was never a winning strategy

Well, evidently it was. Up until we developed systems that can do all the fault finding, penetration testing and code analysis that developers either didn't have time (allocated) for, were not motivated to do or found too boring.

We know this as many of the systems that AI is now revealing shortcomings in, were not broken in to for decades before these tools became available.

And it is arguable that the most secure systems are the ones that nobody knows exist. Possibly because their owners understand they are far too important to ever put on the public internet. Security through lack of entry points is probably the ultimate in obscurity.

At best, all that security measures can ever do is slow down the rate of intrusions or leaks. Modern security standards are nothing to be smug about. In time they too, will fail.

[Blazde]

Re: All security is temporary

Security through lack of entry points is probably the ultimate in obscurity.

That's actual security.

We know this as many of the systems that AI is now revealing shortcomings in, were not broken in to for decades

With virtually everything having vulnerabilities in, anyone wanting to break into systems has been spoilt for choice and typically hasn't bothered with the obscure, less widely used stuff. That doesn't make it secure. You're just pitting insecure vs insecure and obscure. If we consider obscurity in isolation then it inarguably is a small help for security. The problem in practice is it instils false-confidence in the defenders and the moment someone determined does want to breach your stuff they are the ones that find all the holes. Not the defenders, their benign users, white-hat security outfits looking for a press release, etc

At best, all that security measures can ever do is slow down the rate of intrusions or leaks

Again, you've got it ass-backwards. All obscurity does is slow down an intrusion by increasing reconnaissance cost, now less than before. Actual security can raise barriers so high it completely stops attacks from a certain threat model, even if you can still conjure up ways someone could breach your security (like, the government with alien time-travel tech if nothing else will do it). Of course, actual security is much more costly than obscurity. Not just in time and money, but also in convenience let's not overlook.

Anyway, don't let the door hit you on the way out, S.T.O.!

[Pete 2]

Re: All security is temporary

> Actual security can raise barriers so high it completely stops attacks from a certain threat model,

That is a rather simplistic, not to say impractical, attitude. It denies the reality that attack vectors evolve, and security measures inevitably are always one step behind, sinceyou can't secure against a threat you are unaware of. It also fails to acknowledge that increased security - granting access to permitted use, while denying access to others - has a cost:. Current security systems merely increase the burden of proof for legitimate users. Complete security (as you suggest) has the effect of discouraging legitimate users, who will then either stop using an inconvenient system, or find ways around it. We know this as it is just human nature: passwords made public, security doors left open, etc.

So no. All security is temporary - you cannot build barriers "high" enough. And you cannot guard against threats that have not been discovered. All you can ever do is reduce the chances of unauthorised access and limit the scope of breaches. Even if you did manage to build an impenetrable system, it is still vulnerable to DoS attacks!

[Blazde]

Re: All security is temporary

attack vectors evolve

Not really. Knowledge of attack vectors evolves though. That's why we've so long preached that you shouldn't rely on lack of knowledge (aka obscurity) to protect systems.

The argument comes in many flavours, for what it's worth. There was a time when people said "meh, heap errors are too complicated to exploit not a big deal". That's a form of obscurity. There was a time long before Spectre/Meltdown when the hypotheticals of CPU side-channel analysis were well known but people found it implausible anyone would go to lengths to abuse them. Again, relying on the obscurity of hardware knowledge. Both these assumptions failed. Threat models evolve, the potential avenues for attack are largely known and hoping your adversary doesn't know how to get through them is always a bigger risk than closing them off.

[Anonymous Coward]

Re: All security is temporary

This isn't a logical argument. An attack vector cannot exist without the knowledge of it existing somewhere as it is impossible until discovered. If the knowledge evolves then, by definition, so does the attack vector.

"There was a time..." - all of your examples refer to points in time where the knowledge existed and so the attack vector also existed even though they were not yet considered to be practical.

[doublelayer]

Re: All security is temporary

"It denies the reality that attack vectors evolve"

It doesn't. Security has to keep running to keep attackers out, but new attack methods don't make old ones reactivate. Those new methods might work against the existing system or they might not, but either way, the previous method you secured against still doesn't and you can focus your energy on the ones that do. Of course, as you're doing that, the system you're securing is also changing so it can become more vulnerable, and proper security involves checking for, preventing, and detecting that too.

"Even if you did manage to build an impenetrable system, it is still vulnerable to DoS attacks!"

DoS resistance is a well-trodden area of security. It depends what methods an attacker would have for trying a DoS against the system, but there are many things you can do to reduce the damage any individual DoS attempt causes so you can take more, and when many of those are implemented, it can make DoS attacks prohibitively large for the attacker to sustain. It's not a universal vulnerability. It's just another area of research and application.

The tradeoff between security and convenience is well-known to the point of cliche, and the person to whom you replied mentioned it as well, so I don't know why you think it's being ignored here. It's one of the many challenges faced by defenders, and there's no single right answer.

[doublelayer]

Re: All security is temporary

"We know this [that security through obscurity worked] as many of the systems that AI is now revealing shortcomings in, were not broken in to for decades before these tools became available."

We do not know this. If you don't know that there's a hole in the system, then it's either difficult or impossible to determine once you learn that it was there whether someone else found and used it. Logs may not cover that method, they might not provide enough data, or they might have been thrown away instead of kept for the last decade. It's somewhat frequent for places to know they were attacked but not how, and some attacks can succeed without the victim ever knowing they were attacked.

[elsergiovolador]

Hiring

I'd think hiring bottom of the barrel bums on seats stack overflow copy pasters is over.

[Yet Another Anonymous coward]

Re: Hiring

It will be replaced by the optimum uneducated programmer who has no idea what they are doing.

If AI is learning from best-in-class designs published in the literature and typically used in real world(tm) stuff from stackoverflow and Github.

Then our new "random monkeys" methodology where we hire idiots and don't tell them anything guarantees they produce never-seen-before bugs and flaws

[STOP_FORTH]

Re: Hiring

That's okay, then. No existing zero day exploit works on never-seen-before bugs and flaws that don't exist yet.

[elsergiovolador]

AGI

One more observation. Why we know we are far far far away from the mythical AGI?

Because there is currently no evidence of any frontier model engaging in prostitution.

They engage in primitive violence at best, but that is not a sign of intelligence. A bear can break into data centre and wreak havoc, doesn't make it intelligent.

[Yet Another Anonymous coward]

Re: AGI

>currently no evidence of any frontier model engaging in prostitution.

I thought one turned into a private equity firm?

[STOP_FORTH]

Security has been coughing up blood for a long time

Typing an MD5 into Google would often reveal the associated password if it was a commonly-used one.

No decryption required, people leave all kinds of stuff connected to the Web.

Or that's what a dodgy guy down the pub told me.

[Yet Another Anonymous coward]

Re: Security has been coughing up blood for a long time

What's more annoying is that typing MD5 "keyword" no longer gives you the MD5(keyword) instead the "AI" replies with a totally hallucinated MD5 string for keyword which it swears blind is true

[STOP_FORTH]

Re: Security has been coughing up blood for a long time

See? AI keeps the wily hackers away. I knew it must be good for something.

[doublelayer]

Re: Security has been coughing up blood for a long time

Rainbow tables are not new. That's why proper systems salt passwords as well as hashing them, often not with MD5. Security is not failing because people can publish hashes.

[STOP_FORTH]

Re: Security has been coughing up blood for a long time

I know they are not new, that's why I wrote "long time".

I wasn't talking about proper systems, I was talking about MS operating systems.

There's no real point in telling anyone here about salting passwords. Tell people like LinkedIn.

I read The Cuckoo's Egg, which has a good description of salting, some time in the early 80s. Much good it has done me. None of the coding monkeys creating the bulletin boards, applications and operating systems seem to have read it. (Not you UNIXy, LINUXy, BSD people, everybody else.)

[Yet Another Anonymous coward]

Re: Security has been coughing up blood for a long time

Interesting that salts are still necessary/work.

You get so used to finding out that the thing you've been doing for a decade doesn't work anymore or makes things less secure!

[STOP_FORTH]

Re: Security has been coughing up blood for a long time

Depends on how you generate the salt. If it's a fixed value or based on the username or e-mail, it's not really secure.

[Yet Another Anonymous coward]

Re: Security has been coughing up blood for a long time

It would seem that anything beyond using rnd() or the last byte of time_t when the password is created is almost more effort to do it wrong

[Stephen Wilkinson]

Re: Security has been coughing up blood for a long time

Thanks for the reminder of The Cuckoo's Egg. I read it at university, absolutely fascinating.

[rgjnk]

Mixed messages

This seems to be mixing lots of ideas - like that you can have an obscure proprietary system that hackers couldn't touch, but you can set an AI to magically learn about it and then you're stuffed - how is it going to learn about it if no-one else can?

Bulk automation will get you some places, code scanning and probing others, but it isn't magic.

If something is actually obscure as opposed to just not widely known then tooling won't magically break it because there are no more options than originally existed, just accelerators.

Obviously 'obscure' is not 'secure' but some of this is leaping 20 steps ahead then extrapolating from the softest targets.

[Blazde]

Re: Mixed messages

If it's useful obscure never stays secret. It leaks or is discovered or whatever, and when it does it can't be cheaply replaced to regain whatever security you were relying on it for. Compartmentalise your obscurity into passwords/keys/whatever so that you have the power to replace them and thereby keep them secret. That's the key.

Mere secrecy also has a bad rap nowadays if it is copyable, for much the same reasoning. It might leak, and although you've engineered an ability to replace it, if you don't know it leaked - because your copy of it seems fine - you might neglect to do that.

[doublelayer]

Re: Mixed messages

The people who think security by obscurity works are not very smart about security. In my experience, that also means they aren't that smart about obscurity either. Most of the time, information about the system was easier to find than those intent on keeping it obscure thought it was. The manual which was supposed to only be available to admins had been posted to a Reddit thread six years back, but nobody knew that because the thread only had three posts because nobody cared. Binary firmware updates were supposed to be retrieved from the manufacturers' servers, but they weren't as good as they thought they were at authenticating access to those servers and they assumed that a stripped binary would put off attackers if they did get one. The motivated attacker would do a lot of research to find that.

LLMs don't change that, but they can sometimes be more persistent at finding things. It lowered the bar to obtaining information useful to gaining access, but that bar was already low enough that it could be cleared manually. Complete obscurity kind of helps, but it's often more difficult to have that than complete security, and mostly secure is pretty good whereas mostly obscure is already broken.

[Sproggit]

Only Scratching The Surface

As we continue to see more and more vulnerability patches [and zero days and/or exploits] come to light, it would be nice if we could have a sensible conversation around a few more basic, fundamental principles of keeping technology secure...

For example, when in the past I've documented "Standard Builds" [for example for Windows Server 2025 - or it's ancestor versions ] then the build would *always* be stripped down to the bare minimum needed to "get the job done". There are several reasons for this:-

1. Less Bloat == Faster Machine - you typically find that installed software wants to run some kind of housekeeper thread or background service on a server, so even if the package is not being used for anything useful, it's still taking up a bit of RAM and some CPU cycles...

2. Less Code == Less Patching - if you don't have software installed on your machine, you're not going to have to patch it when the next vulnerability is found....

3. Less Code == Less Attack Surface Area - if you don't have software installed on your machine [with a caveat - see below], you're typically presenting an attacker with a smaller attack surface that makes it harder for them to breach your host's perimeter and gain access. The exception to this rule is, of course, security software. Sometimes you just have to bite the bullet and install e.g. a local iptables based firewall, or, for *nix families of hosts, the sort of password synchronization functionality that you get from freeIPA or Red Hat idM...

Unfortunately, we seem to be a long, long, *long* way from there. For example, Microsoft Office 2024 will typically demand at least 4Gb of disk space at installation - and that's before you start loading in optional features. A typical installation of Office 95 used just 55Mb. That's nearly 75 times more disc space for a later-generation version of something that, for 95% or more of users, the original '95 version would deliver everything they need. I make the point not to rail against bloat for the sake of storage [though given the current prices for SSDs, that's probably fair] but for the fact that those 4Gb contain many, *many* more lines of code, each of which could potentially contain a vulnerability.

We should give the same advice to developers for writing software as we should be giving them to handling audit interviews. ("When asked a question by an auditor, give precisely the shortest, simplest answer - no more, no less - and then *shut up*!")

I'm not convinced that telling people to move past "security through obscurity" is going to be enough.

I think a complete rethink of the relationship between "features vs. risk" is required.

[Jou (Mxyzptlk)]

Re: Only Scratching The Surface

> For example, when in the past I've documented "Standard Builds" [for example for Windows Server 2025 - or it's ancestor versions ]

Care to share? I created a "Sever Security Baseline" script (+ GPO set, but the script creates *UNDO*.reg files) which does a lot of security, but not EVERY STIG etc recommendation since they can cause problems as well. Those are later fixed by additional GPOs once the rest of the environment has been updated to handle it.

[Sproggit]

Re: Only Scratching The Surface

Can't - sorry - all done for an employer - it's their IP as they paid for me to do the work.

Having said that - there are lots of good guides on line, for all the popular OS and Distros.

[coderguy]

Shocked I tell you, shocked

This is a direct consequence of migrating everything to the cloud. At least with on-prem you have a chance of protecting the crown jewels.

In the event of something you can't fix "right now", you could always yoink the ethernet cable as a last resort.

[Jou (Mxyzptlk)]

Re: Shocked I tell you, shocked

or the power cable (and battery, if you laptop has an accessible one - my laptops do).

[Rogerborg 2.0]

Open source is more secure because all the eyeballs on it mean any bugs and vulnerabilities get found and fixed faster.

Right?

Riiiiiiight?

[Anonymous Coward]

Relative to ciosed-source software, yes.

In absolute terms, no.

So open-sourcers (of which I am one) had damned-well better get off their high horses, if they are riding them.

[LateAgain]

Definitely bug reporting and visibility on patches is better than closed code.

Have you ever tried reporting a bug against any closed software. ?

[Charlie Clark]

Bugs are likely to be found fastest in the most used software. If it's open source this can make it easier to fix and it certainly makes it easier to verfiy any fix.

[kurios]

Better title

Delete "through obscurity" for a more accurate title.

[Jou (Mxyzptlk)]

Thanks for the article!

I never believed in Security Through Obscurity, but I am guilty I applied it a few times myself. Like RealVNC on an obscure port and forwarded from my router via DynDNS for my private stuff. I switched that to VPN a while ago since it felt more and more weird and dirty...

All that stuff popping up now is technical debt, either not enough time to do it better since some have a life beside coding, or not enough time for the lack of the company to give.

[deaglecat]

I don't think the article is quite fully true.

I mean...Yes, perhaps. if the underlying software is commercially available (and most is based on COTS) and is internet connected.

But some software just isn't like that. Especially in sensitive domains like military or nuclear.

Wanna hack a Patriot PAC4 interceptor missile ?...good luck finding out how that is engineered or what the software stack is (even if bits of it might contain vulnerabilities). And if you can find an example unit to work on and want to exploit then it just doesn't provide an Attack Surface for AI to exploit...it isn't internet connected and any RF links to an inflight missile are already encrypted and often use custom radio waveforms.

Same for a well engineered Nuclear reactor. If you put that on the internet then you are insane.

So yes, Security through obscurity still has its uses. It is another layer or protection. But it also has it's limitations and AI isn't helping....

Definitely don't rely on it for internet connected devices.

[Anonymous Coward]

Root Cause

At the root, computer security problems come from failed, embedded organisational culture ("Just make it work! We're shipping it today!").

Those orgs will either transform themselves for the better, or they will die.

[herberts ghost]

Obscurity is not dead and should not die. But it is not proof against mass probing.

Well I will be more convinced of your argument when the NSA open sources all of its encryption algorithms. Obscurity has never been a panacea, but some things are still best not advertised because open source gives bad guys more info to defeat your security quickly. The biggest hole is human, typically.

[Jou (Mxyzptlk)]

Re: Obscurity is not dead and should not die. But it is not proof against mass probing.

Huh? They do open source the algorithm. Have been doing that for decades. Note that it does not mean to open source the implementation in various languages in various OS-es.

[fg_swe]

Proven Correct Security

There exist systems, which have been proven correct in the mathematical sense.

https://de.wikipedia.org/wiki/L4_(Mikrokernel)

https://en.wikipedia.org/wiki/CompCert

This is the light in the dark space of "quick and dirty world of applied computer science".

Too many systems have very little to no serious quality control efforts applied. Despite the V-Model existing since 1979. There seems to be a never-ending supply of "hackers", who make rookie mistakes again and again. Because honest engineering would require much better funding and other petty reasons.Some of these rookies have become fantastically rich on their shoddy work. Because you know, MOAR IS BETTA.

We know how to build secure systems. We just do not have the funding and discipline to actually do it.

https://di-fg.de/RobusteSoftware.html

[fg_swe]

Securing Water And Electric Utilities

We already had this discussion, plus a proper solution

https://forums.theregister.com/forum/all/2026/08/07/202615/#c_5311783

It's a $40 Raspberry PI plus a competent Linux Admin.

Like hiring a Plumber to fix a dripping pipe.

[Anonymous Coward]

Re: Securing Water And Electric Utilities

Sure, for simples minds who dont know shit

[fg_swe]

Yeah

Naysaying without argument or counter-proposal. How very dark-age of you.

[Taliesinawen]

Re: Securing Water And Electric Utilities

> We already had this discussion, plus a proper solution

It’s déjà vu all over again Yogi :o

Sep 2012: “Why don't they run these SCADA units over a VPN circuit run on embedded hardware?”

[fg_swe]

Crap VPNs: NOT

During the last few years we had tons of remote exploits for SSL based VPNs. Because these systems are bloated, because SSL itself is bloatware by design principle. 400 000 loc C.

What we need is 2000 loc of symmetric cipher, reviewed by NSA, CESG, BSI and the like.

[Jou (Mxyzptlk)]

Re: Crap VPNs: NOT

> What we need is 2000 loc of symmetric cipher

We already have (though not 2000 loc? Check AES256), and you DON'T WANT symmetric cipher in communication. You really really want asymmetric cipher, i.e. different keys for encoding and decoding, and a different pair for each sender on both sides.

Usually the key exchange is done this way only, and the cipher for the data itself is symetric, though you can use different keys for the directions.

Check Wireguard.

[fg_swe]

Symmetric Ciphers

There is nothing wrong with Symmetric Ciphers, as opposed to Public Key.

TYPEX and SIGABA were symmetric ciphers and they worked very well.

ENIGMA was also a symmetric cipher, but the Rotor Key Space was too small.

Also, I use the term "cipher" here to mean a full Cipher Protocol.

SSL/TLS rolls Public Key and Symmetric Cipher into one Huge Hairball. That is why it is insecure, as it is too big.

When you need to exchange keys for a Symmetric Cipher, either use a Courier(plane), KryptoMittel Verteiler Zentrale(KVZ) or (less secure) use GNUpg.

[Jou (Mxyzptlk)]

Re: Symmetric Ciphers

Muss ich fliegen? Auto oder Bahn gehen doch auch!

If the computing overhead would not be so insanely large, everyone would use asymmetric even for the data stream. Which we might have to for really important data, since the Quatum computers will "soon" decipher all AES256 transmissions within a few megabytes of data, maybe even faster! Though the definition of "soon" is a moving target.

[fg_swe]

One More FAIL

AES-256 and other 256 bit key symmetric ciphers are NOT affected by Quantum Decryption.

Most Publicy Key (RSA, DH) IS affected.

[Ramlen]

Re: Securing Water And Electric Utilities

Proper Solution?

Fucking please stop with this hobbyist shit

[fg_swe]

Re: Securing Water And Electric Utilities

Also non- argument. Ssh is rock solid technology, much better than SSL based cr4p VPNs.

What is your solution ? Enlighten us !

[LateAgain]

Evil people can run AI ?

OMG who allowed that.

Next thing you know random black hats will be training AI on "how to break in to... "

[STOP_FORTH]

Re: Evil people can run AI ?

Just train your AI with security articles from The Register.

[James O'Shea]

Ah, security

Many years ago, I worked for an electrical utility. I was part of the SCADA team; SCADA controlled everything, from the generators to reclosers at the substations. We had very simple security: our signals went by power-line carrier. 138,000 volt power-line carrier. SCADA ran on three Harris H800 superminis, which were totally disconnected from all other company networks. Go ahead, try to access the system. We also had encryption, 1980s-level encryption. The old systems lasted 20 years and were replaced by newer, far cheaper, far better systems with 2000s-level encryption, and still using power-line carrier. Those machines are due to be replaced by newer, faster, better systems with 2020s-level encryption, running on power-line carrier. The company has great faith in 138kV's ability to fry those who mess with it.

[STOP_FORTH]

Re: Ah, security

Security through Corona discharge?

(Sorry, couldn't find a rhyme.)

[Fido]

The bugs were not found by the maintainers, because debugging is boring. The bugs were not found by the criminals, because they were busy with more profitable activities. The bugs were not exploited by hostile foreign governments, because the time was not right.

This does not mean those systems with the security bugs were secure.

[DS999]

The good news is

That the number of bugs is finite. There will be a period of pain, which we now in, but it, too, will be finite. Because after this period of chaos, where AI is helping vendors find and fix bugs and helping bad guys find and exploit bugs, there will still be a finite number of bugs but that finite number will be a lot smaller than what we started with.

So things will eventually calm down. There will be processes in place to have AI check code for security issues before release, which will reduce the number of new bugs introduced. The number of old bugs will continue to decrease, but at a much slower rate once the ones current AI can find are found and fixed. Yes over time improvement in AI may uncover harder bugs but they will be fewer in number, and perhaps more complex to exploit - and hopefully more costly for the bad guys to find.

In a couple years we may look back at this period and say "wow that really was worth the pain, because the security situation is much better now". Well at least for systems that actually get updates. For ones that don't they'll have to either be placed behind a proper firewall with proper access controls, or retired and replaced. That's where we really need to focus, because that's not a problem that applying 974 fixes a month from Microsoft or whatever vendor is going to correct.

[Anonymous Coward]

> safe drinking water pours from faucets

the actress?

[Will Godfrey]

Isolation

As far as I'm concerned that is the only way to actually secure a system. I was part of a team that designed and installed a control system for a plastics molding company. It was a completely self contained, with only one terminal for access. It ran for many years with no incidents at all - self managing machine faults with safe shutdowns and notification.

The system ran for about 10 years, stopping only briefly at Christmas.

During that time there was a management change, and the new boss wanted us to provide access for his office computer. We refused, one of my colleagues giving a very detailed account of all the very destructive (and expensive) ways this could go wrong. It was left alone :)

[Death_Ninja]

Re: Isolation

Seem to remember some Iranians imagining that might work too

[Will Godfrey]

Re: Isolation

That system was not properly isolated. It allowed access to external media. Ours didn't. It had a standard wired alphanumeric keyboard, an RS485 serial port and a 7pin display port.

[Linux Bint]

AI has also blown-up the 'many eyes' mantra of open source. Many eyes, but not could spot the security flaws.

[45RPM]

Reckon my ZX81 is still pretty secure.

[fg_swe]

False

If there is sufficient money to extort, a cyber criminal will remember his Z80 skills.

There are probably 10000 engineers around, who still can do Z80 assembly.

One of them is me.

[fg_swe]

Hide Behind Minimalist Cipher System

A large class of remote control applications can be secured by minimalist cipher system. 2000 loc of verified cipher system code can secure millions of lines of insecure contraptions. Satellites, Utilities, Routers, PLCs,...

https://di-fg.de/MinimalesChiffrierSystem.html

[bernmeister]

Obscure really was secure, not now.

I worked for companies with internet connected control equipment. They needed usernames and passwords for access.. We thought was secure but obviously not.

[Fluffy Cactus]

Yes indeed, How come A I is never used to fix software leaks and holes, while it is constantly available to those who want to take advantage of any security problem.

There is something entirely wrong with the way things are going.

Has MSFT, Apple, Google, META, Samsung, etc EVER used AI to make anything safer?

I ask because I don't know. Does anyone her actually KNOW something?