[nullindividual]

> why aren't those built on Linux or even OpenBSD

The vendor who makes the software has always written for Windows (or in reality, wrote for either DOS or OS/2 then transitioned to NT4). History, momentum, familiarity, cost, and ease of support all are factors (among others, I'm sure).

Security is a process, not a product.

And yes, distros require frequent updates, though more to your point, you can limit the scope of installed software. I'm sure airport displays don't need MPEG2, VP1 and so on codecs, for instance.

It's also important to remember that there is a lot of 'garageware' out there with these specialized systems. Want SAML/OIDC support? We only support LDAP over cleartext, or Active Directory at best. Want the latest and greatest version of Apache Tomcat? Sorry, the vendor doesn't know how to troubleshoot either, so they only "support" a three year old vulnerable version.

Ran into that more than a few times.

Given the hypothesis of what caused the BSOD with Crowdstrike (NUL pointer), using a safe language would have been appropriate -- it's fairly easy in this case to lay the blame with CS.

Microsoft supplies the shotgun. It's the vendors responsibility to point it away from themselves.

[pwg]

> I'm sure airport displays don't need MPEG2, VP1 and so on codecs, for instance.

They don't, until the day the airport managers are approached by an advertising company waving the wads of cash the airport could be 'earning' if only they let "AdCo" display, in the top 1/4 of each screen, a video advertising loop. At which point, those displays need the codecs for "AdCo's" video ads.

[westpfelia]

Boy do I sure hate you for saying that. I mean at some point you are right. That is the future. But god am I mad at you for reminding me this is the world we live in.

[prmoustache]

That is not the future but the present. I have already seen flights information panels alternating with ads every few seconds in some airports.

[nullindividual]

Absolutely (sigh)! But with a deployment of devices like that, the operator has a solid central management system from which they could push software as-needed.

[joe_the_user]

Wow,

Security is a process, not a product...

The vendor who makes the software has always written for Windows (or in reality, wrote for either DOS or OS/2 then transitioned to NT4). History, momentum, familiarity, cost, and ease of support all are factors (among others, I'm sure)...

That's starting the argument with "weight loss is about overall diet process, not individual choices" and then hopping to "ice cream for dinner is good 'cause it's convenient and I like it".

The statement "Security is a process, not a product." means you avoid shitty choices everywhere, not you make whatever choices are convenient, try to patch the holes with a ... product ... and also add an extra process to deal with the failures of that product.

[nullindividual]

The statement "Security is a process, not a product" refers to no _product_ can be a security strategy. _Processes_ are part of security. The security landscape keeps evolving and what was appropriate even 5 years ago may not be appropriate today. You have to evolve your strategy and countermeasures over time as part of your _processes_.

[joe_the_user]

The statement "Security is a process, not a product" refers to no _product_ can be a security strategy.

That's the negative part. The positive part is that security considerations have to run through an entire organization because every part of the organization is an "attack surface".

The whole concept of CrowdStrike is that it's there to prevent individual users from doing bad things. But that leaves the problem of CrowdStrike doing bad things. The aim of security as process is avoiding the "what-a-mole" situation that this kind of thinking produces.

[chii]

that's not what a CEO wants to hear.

They want to hear that they can pay $X dollars to this service provider, and tick all of the cover-your-ass boxes in the security checklist; where $X is the cheapest option that fits the bill.