Update beleid bedrijf geeft vraagtekens

[Fugitive2008]

Tweakers,

Ik werk bij een middelgroot bedrijf (450 werknemers) als mechanical engineer (dus geen IT-er) en heb wat vraagtekens bij het update beleid van software van ons bedrijf.
We hebben een applicatie beheer programma (liquit launcher) waarin voor iedereen software beschikbaar is die hij/zij nodig heeft, alleen de software die daar in staat wordt niet geupdate.
Als voorbeeld noem ik Notepad++, VLC en 7Zip dateren allen van 2023 of daarvoor en er is geen automatisch update beleid.
Nu las ik dit bericht: nieuws: Notepad++ onthult: 'Hackaanval was gerichte kaping door Chinese staat....

Hoe vatbaar is een organisatie doordat software niet up to date is? in principe gaat deze software niet het internet op zover ik weet maar ja security updates die daarin zitten worden ook niet geinstalleerd.
Kan iemand van jullie daar kort iets over zeggen. Dank.

[olafmol]

Wat denk je zelf? De vraag stellen is het antwoord geven

Interessanter is nu wat je nu kan/moet doen. Ik zou dit escaleren bij jullie ICT of risk/security afdeling.

[revolution-nl]

Dit is absoluut niet OK, tenzij er een geoorloofd nut is en er tegenmaatregelen zijn genomen, wat in dit geval zeer onwaarschijnlijk lijkt.

Als ik jou was zou ik een melding doen bij je leidinggevende en de security verantwoordelijke met je bevindingen.

[NiGeLaToR]

Het goede nieuws is dat men software beheert en deployed via een centraal management systeem. Nu is het alleen belangrijk dat men de aangeboden software ook blijft onderhouden. Het is ondertussen onderdeel van best practices om dit zo te doen: centraal beheer van software en deze up2date houden.

Bijval voor dit punt vind je oa op de volgende plekken:
- NCSC en verdieping sw updates
- NIST SP 800-40
- ISO 27001 patch management

Het updaten van je favo open source video speler is dus niet alleen 'slim', het is ook onderdeel van compliancy en standaard best practices anno 2026

Meld het aan je security officer of degene die dat in de portefeuille hebt - breng het als een 'het viel mij op dat' en voeg evt je zorg toe. Denk dat als ze beginnen over 'och loopt niet zo'n vaart' je bovenstaande linkjes erbij kan pakken om het punt 'och, das gek, ik las toch hier dat het wel sterk aangeraden wordt?'.

[Fugitive2008]

NiGeLaToR schreef op dinsdag 3 februari 2026 @ 09:22:
Het goede nieuws is dat men software beheert en deployed via een centraal management systeem. Nu is het alleen belangrijk dat men de aangeboden software ook blijft onderhouden. Het is ondertussen onderdeel van best practices om dit zo te doen: centraal beheer van software en deze up2date houden.

Bijval voor dit punt vind je oa op de volgende plekken:
- NCSC en verdieping sw updates
- NIST SP 800-40
- ISO 27001 patch management

Het updaten van je favo open source video speler is dus niet alleen 'slim', het is ook onderdeel van compliancy en standaard best practices anno 2026

Meld het aan je security officer of degene die dat in de portefeuille hebt - breng het als een 'het viel mij op dat' en voeg evt je zorg toe. Denk dat als ze beginnen over 'och loopt niet zo'n vaart' je bovenstaande linkjes erbij kan pakken om het punt 'och, das gek, ik las toch hier dat het wel sterk aangeraden wordt?'.

Ja heb een bericht gestuurd naar onze applicatie beheerder.
Dank voor deze reactie naar een uiteenzetting als deze was ik opzoek wat ook de inhoud zou mogen zijn. +3 als t zou kunnen

[SkiFan]

Deze applicaties kun je met een winget update --all toch makkelijk updaten, waarom zetten ze dat niet in een script?

[Will_M]

SkiFan schreef op dinsdag 3 februari 2026 @ 09:45:
Deze applicaties kun je met een winget update --all toch makkelijk updaten, waarom zetten ze dat niet in een script?

Dan blijft het nog steeds wenselijk dat je óók je eigen distributiepunt bij werkt.

[SkiFan]

@Will_M Absoluut met je eens, maar je kunt al veel ondervangen door in ieder geval zo een oplossing te bieden.

[NiGeLaToR]

SkiFan schreef op dinsdag 3 februari 2026 @ 09:57:
@Will_M Absoluut met je eens, maar je kunt al veel ondervangen door in ieder geval zo een oplossing te bieden.

Er is uiteindelijk iemand nodig die de updates ook valideert en niet blind uitvoert. Idealiter doe je het in fases om te voorkomen dat je per abuis iets 'bricked' in jouw omgeving. De ellende is gewoon dat het enorm veel werk is en dat het allerbelangrijkste is om de sw-footprint zo klein mogelijk te houden op elk endpoint.

[CH4OS]

SkiFan schreef op dinsdag 3 februari 2026 @ 09:45:
Deze applicaties kun je met een winget update --all toch makkelijk updaten, waarom zetten ze dat niet in een script?

Als je local administrator bent en geen applicatie management hebt wel, maar in dit geval denk ik niet dat @Fugitive2008 local administrator rechten heeft, aangezien men met een programma werkt dat dit allemaal voor de gebruikers doet.

[Bezulba]

SkiFan schreef op dinsdag 3 februari 2026 @ 09:45:
Deze applicaties kun je met een winget update --all toch makkelijk updaten, waarom zetten ze dat niet in een script?

Omdat je daarmee nou net al die ellende van de laatste tijd krijgt. Lekker automatisch updaten en dan er achter komen dat je windows installatie helemaal naar z'n grootje is.

Dat is gelijk ook de reden waarom IT vaak dit soort niet belangrijke software totaal niet update na toevoeging aan Bedrijfsportal of welke tool dan ook, het kost ze te veel tijd om 1. bij te houden wanneer welke software een update heeft gekregen en 2. te testen of de nieuwe versie ten eerste werkt maar ten tweede ook nog steeds veilig is.

Dat je daarmee OOK risico loopt is voor veel IT afdelingen geen probleem "wat is de kans nou" etc etc.

[Fugitive2008]

Bezulba schreef op dinsdag 3 februari 2026 @ 10:26:
[...]

Omdat je daarmee nou net al die ellende van de laatste tijd krijgt. Lekker automatisch updaten en dan er achter komen dat je windows installatie helemaal naar z'n grootje is.

Dat is gelijk ook de reden waarom IT vaak dit soort niet belangrijke software totaal niet update na toevoeging aan Bedrijfsportal of welke tool dan ook, het kost ze te veel tijd om 1. bij te houden wanneer welke software een update heeft gekregen en 2. te testen of de nieuwe versie ten eerste werkt maar ten tweede ook nog steeds veilig is.

Dat je daarmee OOK risico loopt is voor veel IT afdelingen geen probleem "wat is de kans nou" etc etc.

Maar dan is het nog steeds toch onwenselijk om het NIET te doen, of begrijp ik je verhaal dan verkeerd?

[SkiFan]

CH4OS schreef op dinsdag 3 februari 2026 @ 10:18:
[...]
Als je local administrator bent en geen applicatie management hebt wel, maar in dit geval denk ik niet dat @Fugitive2008 local administrator rechten heeft, aangezien men met een programma werkt dat dit allemaal voor de gebruikers doet.

Ik was wat snel met --all, maar ze kunnen dat script natuurlijk ook gewoon met admin rechten laten draaien en per app met winget aangeven naar welke versie ze willen. --all is misschien wat lomp.

[dutchgio]

Fugitive2008 schreef op dinsdag 3 februari 2026 @ 10:28:
[...]


Maar dan is het nog steeds toch onwenselijk om het NIET te doen, of begrijp ik je verhaal dan verkeerd?

Ja vaak gaat het dan wel langzamer en dus eerst versie x testen voor je die vrijgeeft voor iedereen in het beheer programma, maar helemaal niet updaten is ook niet goed.

[Bezulba]

Fugitive2008 schreef op dinsdag 3 februari 2026 @ 10:28:
[...]


Maar dan is het nog steeds toch onwenselijk om het NIET te doen, of begrijp ik je verhaal dan verkeerd?

Yup.

Beide is slecht, maar het komt neer op hoeveel tijd (en dus geld) een IT afdeling heeft om dit soort dingen bij te houden na implementatie en dat is in bijna alle gevallen dat er nooit genoeg is.

[CH4OS]

SkiFan schreef op dinsdag 3 februari 2026 @ 10:29:
Ik was wat snel met --all, maar ze kunnen dat script natuurlijk ook gewoon met admin rechten laten draaien en per app met winget aangeven naar welke versie ze willen. --all is misschien wat lomp.

Dat dat allemaal kan is prima, maar lijkt me alsnog ongewenst. Een bedrijf gebruikt niet voor niets een "launcher" voor applicatie management op hun omgeving / infrastructuur. Dan is daar gewoon beleid voor. Het enige wat je dan dus kunt doen is signaleren, eventueel een issue ervoor aanmaken zodat het geregistreerd is. Als er dan een antwoord op komt vanuit de IT afdeling, of de outsourced IT afdeling, dan ligt het risico daar, de IT heeft dan immers besloten.

[MrNOnamE]

Je zou bijvoorbeeld ook kunnen zorgen dat je wel altijd patched maar 10 dagen achterloopt. Foute updates worden dan terug geroepen, voor de rest gaat het vanzelf.
Bij een groot lek kun je altijd nog adhoc een patch installeren.

Maar zoals gezegd, alles is beter dan niks doen.

[CH4OS]

MrNOnamE schreef op dinsdag 3 februari 2026 @ 11:36:
Je zou bijvoorbeeld ook kunnen zorgen dat je wel altijd patched maar 10 dagen achterloopt. Foute updates worden dan terug geroepen, voor de rest gaat het vanzelf.
Bij een groot lek kun je altijd nog adhoc een patch installeren.

Maar zoals gezegd, alles is beter dan niks doen.

Ook na bijvoorbeeld 10 dagen kan pas ontdekt worden dat er fouten in een package zitten, dus om alles blindelings te doen, ook al doe je dat vertraagd, is altijd een risico.

De VPN leverancier bij het bedrijf waar ik werk, trekt ook vaak conclusies als 'Dit lek is op jullie niet van toepassing, want jullie gebruiken deze functionaliteit niet (en staat dan ook uit)'. En zegt ook 'Maar jullie versie is ouder en niet vatbaar'. Dat een programma al 2 jaar niet bijgewerkt is, hoeft dus zeker niet per se slecht te zijn en hoeft ook niet automatisch te betekenen dat het vatbaar is voor lekken die heden ten dage gevonden worden.

Dat er partijen zijn die vervolgens in hun normen hebben staan wat zij vinden dat de best practice is, is vaak ook een meer algemeen ding en is ook om te zorgen dat iedereen eigenlijk een beetje op dezelfde manier te werk gaat. Dat hoeft niet te betekenen dat het in de praktijk er altijd zo aan toe zou moeten gaan, voor een ander bedrijf kan een andere werk- of zienswijze beter werken, wellicht is dat hier ook het geval.

Omdat in ISO 27K1 staat hoe patch- en softwaremanagement volgens hen het beste werkt of zou moeten werken, betekend niet automatisch dat dat voor iedereen zo werkt en geldt. Het is daarnaast ook geen verplichte werkwijze om de ISO 27K1 certificering binnen te halen. Het zijn niets meer dan adviezen.

Begrijp mij niet verkeerd, mijn Ubuntu laptop werk ik ook elke dag, meermaals bij. Ik weet dus ook wel wat het belang is, maar ik zie ook dat andere bedrijven (zeker outsourced IT partijen doen dat in mijn ervaring) er een andere kijk op hebben. Dat hoeft zeker niet per se "beter" te zijn, maar ook niet per definitie (want 'best practices zeggen wat anders') "slechter".

[ Voor 22% gewijzigd door CH4OS op 03-02-2026 11:51 ]

[dutchgio]

CH4OS schreef op dinsdag 3 februari 2026 @ 11:41:
[...]
Ook na bijvoorbeeld 10 dagen kan pas ontdekt worden dat er fouten in een package zitten, dus om alles blindelings te doen, ook al doe je dat vertraagd, is altijd een risico.
[...]

Maar als je die 10 dagen 'achter' loopt is die fout in dat package wellicht al weer opgelost en kun je bij problemen upgraden naar een recentere versie.
Als je altijd direct naar de recentste versie gaat moet je wachten tot die problemen opgelost zijn of zelfs terugdraaien naar een oudere versie, dat gaat lang niet altijd zo makkelijk.

[CH4OS]

dutchgio schreef op dinsdag 3 februari 2026 @ 12:04:
[...]

Maar als je die 10 dagen 'achter' loopt is die fout in dat package wellicht al weer opgelost en kun je bij problemen upgraden naar een recentere versie.
Als je altijd direct naar de recentste versie gaat moet je wachten tot die problemen opgelost zijn of zelfs terugdraaien naar een oudere versie, dat gaat lang niet altijd zo makkelijk.

Dat kan zeker, maar een fout hoeft niet per se uitsluitend binnen de 10 dagen gevonden te worden, dat was meer mijn punt. Je kunt jezelf ermee dus tot op zekere hoogte indekken, maar garanties geeft het ook niet.

[Jazzy]

Het is een risico-afweging. En zoals gezegd, iets doen is beter dan niets doen.

Ben benieuwd hoe dit wordt opgepakt op je werk, @Fugitive2008. Goed dat je aan de bel trekt, je hebt echt een goed punt hier.

[Fugitive2008]

Jazzy schreef op dinsdag 3 februari 2026 @ 12:09:
Het is een risico-afweging. En zoals gezegd, iets doen is beter dan niets doen.

Ben benieuwd hoe dit wordt opgepakt op je werk, @Fugitive2008. Goed dat je aan de bel trekt, je hebt echt een goed punt hier.

Ja ik ben door hobby wel wat bekwaam met pc's en software (pc's samengesteld voor onze specifieke toepassing van engineering) maar over software beheer etc en afwegingen daarin heb ik geen kennis en ben blij met al de reacties op dit topic zeker van mr/mevr. @NiGeLaToR .
Heb op de locatie van ons bedrijf wel admin rechten en hier lokaal regel ik best wat omtrend IT. ik ben engineer maar heb de meeste kennis hier (=niet het hoofdkantoor) van IT zaken, maar we hebben al vaker geklaagd dat het fijn is wanneer er een IT-er af en toe op onze locatie aanwezig kan zijn.

[DjoeC]

Hmm, als ik de Liquit software zoek krijg ik dit: "Liquit is now Recast Software Visit us at recastsoftware.com".

Misschien is dat al een indicatie? Maar, ik ken de software als zodanig niet MAAR als dit een produkt is dat software opstart in een afgegrendelde werkomgeving en/of een afgeschermde VM waardoor deze niet rechtstreeks aan de buitenwereld gekoppeld is zie ik geen enkele reden dat software als Notepad++, 7Zip e.d. altijd op de laatste versie zou moeten zitten. Sterker, veel origanisatie laten veel updates en soms ook upgrades lopen omdat het uittesten voor een (grotere) organisatie tijd (=geld) kost. Waarom kloten aan iets dat het goed doet en dat toch afgeschermd draait?

En in de context van Notepad++ wordt dat eigenlijk nog meer duidelijk: Het probleem zat bij het omleiden van het update kanaal waardoor je - bijvoorbeeld - zomaar een nieuwe versie vol met bewuste lekken zou kunnen krijgen. Updaten als individuele gebruiker is sowieso onwenselijk, kloten daarmee zou in mijn organisatie minimaal een zeer ernstig gesprek en/of een afscheid opleveren.

Dat allemaal gezegd hebbend: OP basis van deze zin "Liquit is now Recast Software Visit us at recastsoftware.com" vraag ik me af of men de beheer kant goed op order heeft. Deze overname/fusie is al uit 2023 en het produkt heet tegenwoordig (vermoed ik) "Application Workspace".

[Fugitive2008]

DjoeC schreef op dinsdag 3 februari 2026 @ 12:44:
Hmm, als ik de Liquit software zoek krijg ik dit: "Liquit is now Recast Software Visit us at recastsoftware.com".

Misschien is dat al een indicatie? Maar, ik ken de software als zodanig niet MAAR als dit een produkt is dat software opstart in een afgegrendelde werkomgeving en/of een afgeschermde VM waardoor deze niet rechtstreeks aan de buitenwereld gekoppeld is zie ik geen enkele reden dat software als Notepad++, 7Zip e.d. altijd op de laatste versie zou moeten zitten. Sterker, veel origanisatie laten veel updates en soms ook upgrades lopen omdat het uittesten voor een (grotere) organisatie tijd (=geld) kost. Waarom kloten aan iets dat het goed doet en dat toch afgeschermd draait?

En in de context van Notepad++ wordt dat eigenlijk nog meer duidelijk: Het probleem zat bij het omleiden van het update kanaal waardoor je - bijvoorbeeld - zomaar een nieuwe versie vol met bewuste lekken zou kunnen krijgen. Updaten als individuele gebruiker is sowieso onwenselijk, kloten daarmee zou in mijn organisatie minimaal een zeer ernstig gesprek en/of een afscheid opleveren.

Dat allemaal gezegd hebbend: OP basis van deze zin "Liquit is now Recast Software Visit us at recastsoftware.com" vraag ik me af of men de beheer kant goed op order heeft. Deze overname/fusie is al uit 2023 en het produkt heet tegenwoordig (vermoed ik) "Application Workspace".

Hmm volgensmij start deze software niet in een afgeschermde VM/werkomgeving maar direct op onze windows11 pc's net als de rest van onze software. Ik werk direct op de pc waarop alle software draait naja ik heb van dit soort dingen dan weer minder kennis.

Daarnaast wordt deze applicatie nog wel ondersteund dacht ik (laatste versie is van december https://download.liquit.com/)

[ Voor 3% gewijzigd door Fugitive2008 op 03-02-2026 14:32 ]

[nicjongen]

Recast Application Workspace werkt zeker niet met een afgeschermde omgeving.
Recast Application Workspace (oud Liquit Workspace Control) is feitelijk een distributiepunt waar je software van kan deployen naar meerdere machines tegelijk, of software via de agent aan kan bieden, net als bijv, Microsoft Store. De applicatie (bijv. notepad ++) is beschikbaar gesteld en wordt daadwerkelijk op de client geïnstalleerd en daar dus ook opgestart.
Het is ook mogelijk om snelkoppelingen aan te bieden naar gepubliceerde applicaties en of websites, maar hier zal Notepad++ vast niet onder vallen bij jullie.

Maar als je de software op distributiepunt niet bijwerkt dan zal de agent/client ook de software niet (altijd) updaten, tenzij het updatebeleid lokaal geregeld is maar dat lijkt me niet als je een centraal management platform als Recast gebruikt.

[ Voor 2% gewijzigd door nicjongen op 03-02-2026 13:37 . Reden: foutjes ]