The 12 (+353) Days of Sysmas
Our plain-speaking duo celebrate Sysmas – because ’tis the season to be thankful for the Sysadmins, IT staff, and SOCstars everywhere who keep us safe, even in the holidays when many of us are busy with, well, with not being busy with cybersecurity 🎉
If the media player above doesn’t work in your browser,
try clicking here to listen in a new browser tab.
Find TALES FROM THE SOC on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app. Or download this episode as an MP3 file and listen offline in any audio or video player.
[FX: PHONE DIALS]
[FX: PHONE RINGS, PICKS UP]
ETHEREAL VOICE. Hello, caller.
Get ready for TALES FROM THE SOC.
[FX: DRAMATIC CHORD]
DUCK. Hello, everybody.
Welcome back to the TALES FROM THE SOC podcast.
I am Paul Ducklin, joined as usual by David Emerson, CTO and Head of Operations at SolCyber.
Happy “End of the Year Thing,” David!
DAVID. Hey there.
What is this, the 29th?
It *is* the very end of the year…
DUCK. Those of you who follow @SolCyber on LinkedIn…
(By the way, we’d love you to do so, because we have a fantastic weekly series on there called Amos the Armadillo’s Almanac, where we give light-hearted but serious short tips with a bit of fun in them.)
…Amos the Armadillo provided information [A SONG, IN FACT] about The 12 Days of Sysmas.
If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos even does seasonal songs (though he gets other people to sing, because his own voice is rather croaky) urging us not to forget those people who work through the holidays to keep us safe online:
Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
And I thought, David, that we could entitle this episode The 12 (Plus 353) Days of Sysmas. [12+353 = 365]
Things that were interesting in the past year, and that we probably need to know for the next year.
Where would you like to start?
DAVID. Radiation! [LAUGHS]
Let’s go with radiation.
DUCK. Yes!
Oh, by the way, we’ll refer here to stories that we’ve written up on the SolCyber blog in the course of the year.
So, when we put the transcript up on the website, I’ll make sure to include shownotes as you go along.
This is sort-of truth is stranger than fiction.
Cosmic rays, and the world’s weirdest patch.
Well, not cosmic rays, those are particles, but…
…Airbus grounded planes and required a software update, because they decided that solar radiation, electromagnetic interference, which gets worse as you get higher up in the atmosphere, had apparently caused misbehavior in the control surface computer of certain models of Airbus.
I think it was various A320s.
What do you say to that?
DAVID. Beware flying, I guess.
Except, “Not really”- the actual accident rate is so low.
DUCK. There was some software problem that meant that error correction between the pilot and what’s I believe is called the ELAC, the Elevator and Aileron Control Computer, got things… fortunately not catastrophically, but worryingly wrong.
It seems that the instructions were, “Before you can fly this plane again, once you’ve landed, you have to *downgrade* to the previous version of the software.”
Doesn’t that sound a bit weird?
What could have happened in the last update that meant that the hardware suddenly behaved differently?
DAVID. Clearly a regression.
I think it’s sensible.
DUCK. Well, a regression means you would have reintroduced a bug that you had before.
And yet, this thing had never happened before.
DAVID. It had never happened in production.
It doesn’t mean that they hadn’t considered the possibility of corruption, or that they hadn’t realized corruption would occur.
I would characterize it as a regression… at least in my most kind imagination for why this would occur.
DUCK. [LAUGHS]
DAVID. And then, in terms of rolling back to a previous version, it’s probably as simple as conservative engineering.
The likelihood is they didn’t want to thrash about and make more changes.
We see this in any number of practices.
DUCK. Well, you wouldn’t get approval quickly for a change that significant, would you?
DAVID. No, you shouldn’t.
And you know that the previous version worked.
You know, perhaps in this case, that it was not susceptible to this problem, whatever the problem may have been.
And I could think of any number of reasons that a software change could potentially change the performance of hardware.
Integration testing is a thing for a reason in the real world.
DUCK. Yes.
DAVID. It’s fully believable.
I think it makes sense as a story overall.
Sounds scary, but the reality is someone was probably pushing it, changed error correction or something in software, and realized that actually that had real-world effects of corruption that was unchecked.
DUCK. I wonder how you work out, when you look at the diffs [CODE DIFFERENCES] between this version and the last version, which is the likely one to cause a problem that is apparently as esoteric as this?
We’re in a time of major solar flare activity, aren’t we, in a period where there’s more interference than usual?
DAVID. Yes.
You know, I don’t think you’re going to see open-source aircraft software any time soon, but it would be a perfect argument for something like that.
I think the industry would probably be able to tolerate it.
The regulatory bodies would probably be able to tolerate it.
This is globally a surprisingly transparent industry, aviation.
That would actually be a really interesting thing to do.
Essentially, open-source the code that runs stuff like this, not only for observability, but also so that we have a common understanding of what good conservative engineering looks like from the aviation industry.
I think that would be sort of neat.
DUCK. It was certainly a fascinating story.
“All these planes need to have a software downgrade before they’re allowed to fly again,” which would be very cheery if you were on… I suppose if it’s an A320, it’s not like it can fly halfway around the world.
But, presumably, if you had Wi-Fi on the flight, you might actually see the story about “this needs patching” while you were in one of the affected planes, in the air. [LAUGHS]
DAVID. Yes!
DUCK. I guess you’d have to take comfort from the fact that it seems to be a pretty rare occurrence.
DAVID. I like that you take comfort from, “Oh, it can’t fly that far.” [LAUGHTER]
This is in the category of, “There are many, many people in cemeteries who had the right of way.”
DUCK. OK, David, moving on to another story, and that is CHRISTMAS EXEC, the world’s first mass-mailing malware.
Technically it wasn’t CHRISTMAS EXEC, it was CHRISTMA EXEC.
Anyone who used DOS, or this was IBM’s VM/CMS mainframe operating system, will remember that filenames were limited to eight characters, because who would *ever* need a longer filename?
To persuade non-technical people that they didn’t need to worry about this, it had a comment at the top, Browsing this message is boring. Just type the word CHRISTMAS.
And you didn’t need to type EXEC, just like you don’t need to type extensions on Windows to this day.
It didn’t matter that you types the extra S – it chops it off because filenames are eight characters, and it would run the message.
And, of course, it would just start sending email to everybody in your address list.
It basically shut down IBM networks in academia and business, including IBM’s own network, all over the world.
And, by the way… when you ran the program, to disguise the fact that it was doing all this email spamming in the background, it printed a little fir tree, a little Christmas tree, and had a message saying, My best wishes for Christmas and the next year.
It started at a university in Germany, I believe, and quickly went all the way around the world… *in 1987*.
So David, those who cannot remember the past are definitely condemned to repeat it, wouldn’t you say?
DAVID. I would say so.
This one was before my time, but I think the lesson is exactly that – there’s nothing new under the sun.
Ultimately, it boils down to the economics of threats.
What is the easiest thing to do?
You could do a sophisticated attack that might represent a zero-day exploit of some kind, even back then, or you could just compel someone, because they’re bored and have copy-and-paste functionality, to do the work for you.
One of those is more economical than the other, and it continues to this day in the form of email phishing.
It’s not that different.
So I think that, really, there is nothing new.
DUCK. Don’t take any action; don’t click any buttons; don’t download any files; and definitely do not execute any commands just because the sender told you to do so?
DAVID. That, I think, is the thing that’s hard for people to pick apart.
We could say, “Don’t click on anything,” but people have stuff to do, and they have a job, and whatever.
You have to click on some things.
You just have to be discriminating about the employment of some of these tactics, like urgency, confidentiality, rarity, and so on.
DUCK. And so the response is not technological, is it?
It’s just a little bit of, “If in doubt, don’t give it out”?
DAVID. Yes.
It is not technological; these are not sophisticated attacks.
They’ve never been sophisticated, even in the days of CHRISTMA [LAUGHTER].
It was not a sophisticated thing.
It was a social attack, essentially.
DUCK. Yes.
I guess back then it was just a student having fun…
DAVID. Yes.
DUCK. …although it all went a bit pear-shaped in the end.
Unfortunately, these days, it’s fun of a very different kind.
It might be “fun” for the criminals to get hold of your money.
It’s certainly not fun for you trying to recover from that.
So, as for examples of those who cannot remember the past, we had a couple of interesting and popular stories in the last few months, which I would call those who cannot remember the BS of the past will fall for it all over again.
Particular articles I’m thinking of…
One on juicejacking: “Oh, if you plug your phone into an unknown charging station, it’s the most obvious way you’ll get pwned by malware,” which turns out to be completely untrue.
And recently, a huge thing that I think started with a CBS News article that quickly spread all around the world, about ghost tapping.
Which is basically the idea that, “Well, what if you’re doing Christmas shopping in a crowded area, and trying to get the best deals, and you’re all crammed in, and someone sidles up to you and sort of rubs up against you with a payment terminal and tricks the credit card in your pocket into making a payment to their account that you don’t even realize is happening?”
And it turns out that, actually, this attack is difficult to pull off.
And the same with juicejacking.
“Oh, be very scared of plugging your phone in, even when it’s locked, to a charging station,” whereas, in fact, it’s when and where you unlock your phone, and who’s around when you do it, that is a much better precaution that you could take.
So why does this BS of the past keep cropping up, and why does it do so well, so often?
Is it all down to social media, making it easier to pitch this kind of garbage?
DAVID. [IRONIC TONE] Quality Content. [LAUGHTER]
I think it’s just a misunderstanding, no different than there being nothing new under the sun.
There is a misunderstanding that you can ‘educate’ your way out of cybersecurity concerns in a technical sense.
Unfortunately, that’s simply not true.
You see it in security awareness training.
Even our own security awareness training, in order to satisfy some requirements (which are compliance, regulatory compliance requirements), includes a nod to the notion that Wi-Fi in a cafe might be unreliable or unsafe.
It includes a nod to the notion that conducting business in public could potentially be unsafe.
At the end of the day, though, there is no litany that I could read you that would also keep you safe.
It is possible to do juicejacking; it is possible to do ghost tapping.
Is it likely that that’s going to happen to you?
No, and, in fact, it’s so unlikely that even the people who have an economic interest in that not happening, namely credit card companies, let’s say, in the case of ghost tapping…
…they don’t consider it that big of a vulnerability.
And so, my point here is not that it’s impossible, but more that it is so vanishingly unlikely that you are going to be the victim of one of these concerns (and that you would also be the victim of one of these concerns without recourse), that it’s probably not worth your time worrying about.
You are the custodian of your data, and you need to know what in your pocket is so valuable that a failure to protect that item would be unrecoverable for you.
Is someone ghost tapping my credit card unrecoverable for me?
No, it actually isn’t at all.
My credit card number gets stolen all the time; I call the credit card company; they issue me a new number.
They revoke two charges at a hair salon in Atlanta that I never went to, right?
And we move on.
DUCK. [LAUGHS LOUDLY] It’s all right, I shouldn’t laugh.
Our listeners aren’t, but I am, seeing you on the video.
The idea of you visiting a hair salon seems to be…
DAVID. [LAUGHING] Would not be a $450 visit, that’s what I know!
DUCK. [SLIGHT EMBARRASSMENT] …or even perhaps (I don’t want this to sound terrible), errrrr, necessary? [LAUGHTER]
DAVID. Oh, I’m not sensitive, it’s OK.
DUCK. [LAUGHS]
DAVID. [REFERENCING THE NEEDLESS HAIRCUTS] No, that is absolutely the case.
[SERIOUS AGAIN] You know, that’s the kind of thing that happens, and the whole system is built to allow this slack so that you aren’t constantly derailed by insecurity with regards to your credit card.
Again, if this is a national secret, if this is classified information, and it’s for some reason secured by an RFID token in your wallet?
OK, you need to take some precautions, because these things are technically possible.
Perhaps don’t plug in your FedRAMP high-scope, CMMC Level 3 phone… don’t plug that into a public charging outlet.
I completely agree with that.
But keep in mind what it is you’re protecting, and if it’s your everyday iPhone, charge your phone so that you’re safer, because you have a phone with juice in it when something happens, like you don’t know your way around in a foreign city.
DUCK. Or you need to phone the bank urgently to revoke your credit card. [LAUGHS]
DAVID. Right, exactly. [LAUGHS]
I think there’s probably far more harm in not having a functioning phone while you’re traveling than there is in the possibility that you’d be juicejacked as a result of using a public charger.
DUCK. I guess the problem is that people think that, by doing something very simple to protect from a minuscule risk, they kind-of think there are a whole load of other things that they should do that they don’t need to do now, because they’re safe against the sexy-sounding threats.
Do you think it boils down to that?
DAVID. Essentially, yes.
And, all the while, they’ve built this taxonomy of risk that absolves them of doing the actual critical thinking around what it is they’re trying to protect, and what the real risk to their data is.
My credit card number just isn’t that critical.
There’s an entire infrastructure around ensuring that, if I have a fraudulent charge on my credit card, it can be reversed.
There’s an entire infrastructure of permissions on your phone ensuring that malicious access to data is not likely to happen.
And I’m not talking about protecting state secrets against nation state-level attacks – I’m not talking about that.
I’m talking about on an everyday person’s phone – on an iPhone, on an Android, on any common phone today – you would absolutely get some kind of a permissions warning.
DUCK. What about the thrust in some quarters to do what you might call “closed-loop” automation?
In other words, let’s take all the humans and the humanity out of cyber security.
Let’s just let automatic systems do their best.
DAVID. Total automation… I don’t think protects you totally.
I’m not an opponent of automation where it’s appropriate.
I think that oftentimes people have a false sense of security about automation.
To the extent that automation might better define your business process, and the inputs and outputs of your business process, I actually think that could be a really healthy reason to do it.
But, at the end of the day, is that automation securing your business process?
No, not necessarily, but it’s more likely that your *definition* of your business process is what’s securing your business.
And in terms of pulling all the humanity out of it?
No, I actually don’t think that helps you at all.
In most cases, the reality is that the best defenses, for example for things like insider threats, are social in nature.
DUCK. Yes.
And the irony is, the more you automate things that used to take up the time of people who could have been doing what you like to call higher-order tasks…
DAVID. Yes.
DUCK. …the more of that sort of automation you have, the more humans, and humanity, and human-centered responsiveness, you can actually build into your organizational operation.
DAVID. Yes.
And for emergencies.
I would put breaches in the category of emergencies in many cases.
DUCK. Yes.
DAVID. Having the flexibility of a person in an emergency is actually often a benefit.
Certainly, it’s beneficial to have guardrails on your business processes; to have automation that provides efficiency for them.
But, at the end of the day, when everyone has a plan and they get hit in the face…
…all that’s important is that they had a plan of some kind, and now their actions from here on should be some kind of intelligent re-modification of that plan.
And that’s where you need people.
You’re fighting a fire at this point, and your automation isn’t going to save you, because the automation was a fair-weather friend.
DUCK. Indeed.
David, I’m conscious of time, so I’d like to finish with one last story.
This one is kind-of amusing when you first see it, but there’s actually nothing funny about it. (Fortunately, I don’t think anyone actually lost their life in this.)
When you talk about “fighting a fire” in the case of a cyber-emergency, this was a story about a Korean government cloud backup service that literally went up in smoke.
Public sector organizations had been encouraged for very many years to essentially standardize on this service, and not to worry about what you might call the backup of the backup.
There was quite literally no chance of recovery – it had turned to ashes.
And apparently the average cloud loss per person ran to about 30 gigabytes.
DAVID. I know that there’s a sysadmin somewhere that is feeling really vindicated by just having been ornery, and not using this cloud backup.
DUCK. [LAUGHS]
DAVID. [WRY] I feel like I may have been that person sometimes.
DUCK. Shadow IT to the rescue for once, you mean?
DAVID. Yes, right. [LAUGHS]
I don’t think the cloud is evil.
The cloud is not at fault for this.
DUCK. No.
DAVID. Humans are at fault.
I don’t know what to say, other than you have to have a backup for the backup.
You really do.
You actually have to test your backups; you actually have to have them.
And then you have to think about what would happen if some of them were unavailable.
That is the failure.
Could have been AWS though, right?
Like, AWS us-east-1 could fail one day – it has been off for a day at a time.
That isn’t going to make me never want to use AWS again.
What it is going to make me do, is have diversity in my operations.
To understand that at any given time, one of the core underlying systems for my platform may be down, or unavailable, or have some kind of degraded performance.
And I need to have a plan for that if it’s actually important to me.
Nothing new under the sun; this is kind-of the same as a lot of the other ones.
Don’t blame the cloud.
This could have happened with your on-prem Exchange server too. [LAUGHS]
I say that mostly because I do know a lot of sysadmins who, even in 2025, are convinced that their operations are more mature than Amazon Web Services.
And I actually don’t believe them… but what I do grant them is it’s good to have diversity.
It’s really, really good to have a secondary plan if something becomes unavailable.
DUCK. Yes, it’s not really an either/or situation, is it?
If you’re a very large business, obviously your backup rules and regulations and regimen may be very much more complicated.
But whenever you’re thinking about backup, whether it’s for business or just for your home stuff, which is for many people is even more important (mortgage data, tax returns), remember the 3-2-1 rule.
You should essentially always have *three* copies of everything, not merely two.
Ideally, you should have *two* different technologies for storing them, so having two copies of the same file in the same cloud service doesn’t satisfy that requirement.
And, ideally, *one* of them should be not only offsite, which cloud storage does satisfy, but offline.
Do you think that’s a doable thing for most small businesses?
DAVID. I do think it’s doable.
[WRY] I don’t think people are going to it, because there’s nothing to under the sun.
But yes, I do think it’s doable.
It’s something to aspire to; it’s a really good mnemonic device.
DUCK. Yes.
DAVID. At the end of the day, have an extra copy somewhere.
Don’t be all-in on any one service.
And I don’t mean having seven hot services running in seven different clouds… that’s overkill.
I just mean, keep in mind that some core elements of a platform can be degraded, and practice good engineering around those possibilities.
DUCK. And, just as importantly, although we glibly use the word “backup,” what we really mean is “backup and its corresponding restore.”
So, if you aren’t practicing your restoring, if you don’t know how to do it and how long it will take, then you’re really letting yourself down, aren’t you?
Even if that data is ultimately recoverable, if you can’t do it in a reliable, timely, and efficient fashion, then you could be in as much trouble as if you couldn’t get it back at all.
DAVID. Absolutely.
You’ve got to remember the recovery; you have to test it.
This is in any number of controls in various regulatory regimes, but it doesn’t make people learn it.
You just really have to make that a practice.
DUCK. Yes, it’s like fire drills, isn’t it?
Where you actually go down the fire escape.
And then, if there is a real fire, you’ll probably get out because you’ll know where the blind corners are; you know where the scary bits are; you know how far you are through the journey.
DAVID. Yes.
DUCK. And as always, practice makes perfect.
DAVID. You’ll know how that weird little counterbalance ladder works on the side of your building.
DUCK. [LAUGHS]
DAVID. My point being I don’t think anybody has actually practiced with that little ladder that’s probably been painted shut years and years ago.
DUCK. Yes, and when you get on it, will it snap off like it always does in the movies? [LAUGHTER]
DAVID. Yes, exactly.
DUCK. Because it’s been rusting since 1965.
DAVID. [LAUGHS] Exactly.
How even do we use this thing now that we’re here and the building’s blazing?
DUCK. So, to finish up, David, I think we can say: “Practice makes perfect,” and “The only backup you will ever regret is the one you did not make.”
David, thank you so much for your time, and for agreeing to have a little bit of fun to close out 2025.
Fun with a serious side.
Thanks to everybody who tuned in and listened.
Please subscribe to the podcast if you haven’t already, and please like and share us on social media.
Please join us as regularly as you can on https://solcyber.com/blog, where we have a good deal of fun, but we also present a great deal of news, opinion, advice, and research that I think you will find is well worth reading.
Community-centered, not your typical cybersecurity sales and marketing schpiel.
Once again, thanks for listening everybody and remember…
Until next time, stay secure.
DAVID. Bye, all.
[FX: CALL ENDS]
Catch up now, or subscribe to find out about new episodes as soon as they come out. Find us on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
