D66 wil patchbrigades die bedrijven actief gaan helpen met dichten van lekken
D66 wil dat er "patchbrigades" in Nederland komen die bedrijven actief gaan helpen bij het dichten van bekende kwetsbaarheden. Daarvoor heeft D66-Kamerlid Van Ginneken een motie in de Tweede Kamer ingediend. Volgens het Kamerlid zoeken "hackers" actief naar bedrijven die geen beveiligingsupdates voor bekende kwetsbaarheden hebben geïnstalleerd.
Aanvallen op deze bedrijven en organisaties, ook al gaat het niet om vitale sectoren, zou tot maatschappelijke ontwrichting kunnen leiden. Daarom wil Van Ginneken dat niet-vitale sectoren zo snel mogelijk worden versterkt tegen digitale dreigingen. Ze vraagt minister Yesilgoz van Justitie en Veiligheid om brancheorganisaties, ondernemersverenigingen en andere sectorkoepels actief te stimuleren om "sectorale patchbrigades" uit te laten rukken die hun leden actief benaderen en helpen met het dichten van bekende kwetsbaarheden.
"Het doel is om private sectoren aan te jagen om meer te doen om hun aangesloten leden, om de bedrijven en organisaties binnen zo'n sector, te helpen en te ondersteunen. Het is een oproep aan de minister om de bedrijven- en sectororganisaties meer verantwoordelijkheid te laten nemen. Die kunnen — daar ben je een sector- of brancheorganisatie voor — collectief dingen doen voor leden", laat het D66-Kamerlid in een uitleg over de motie weten.
Volgens Van Ginneken moeten organisaties en ondernemingen actief worden geholpen met het patchen van hun systemen. "Wat ik terughoor — dat is ook een van de achtergronden van deze motie — is dat bedrijven soms aarzelen, omdat ze het niet goed weten. Ze moeten patches installeren en vragen zich dan af wat dat met hun systeemomgeving doet. Er is sprake van uitstelgedrag. Als er iets is wat we ons niet kunnen permitteren, is dat uitstelgedrag op dit vlak."
Het D66-Kamerlid stelt dat de patchbrigades meer moeten worden gezien als een soort vliegende adviesdienst, die organisaties kan helpen om toch die patches te gaan installeren en kan ondersteunen om de handelingsverlegenheid terug te dringen. "Het oproepen van een bewindspersoon om een aanjagende rol te vervullen, doen we op heel veel momenten en voor heel veel onderwerpen. Ik stel vast dat het voor dit onderwerp ook belangrijk is als de minister zich op die manier laat zien. Vandaar de motie", legde Van Ginneken verder uit.
Minister Yesilgoz laat in een reactie op de motie weten dat ze geen voorstander is om sectorale patchbrigades te moeten instellen. "Ik heb dat de vorige keer ook gezegd en dan is de motie ontraden. Als mevrouw Van Ginneken zegt dat het er echt om gaat om het gesprek aan te gaan en het belang extra onder de aandacht te brengen, als we het op die manier mogen invullen, dan kan ik ermee aan de slag."
Van Ginneken stelt aanvullend dat sectoren en brancheorganisaties niet moeten worden verplicht om patchbrigades uit te laten rukken. "Het dictum van de motie zegt ook "stimuleren", dus als de minister dit als suggestie en niet als verplichting, moratorium of wat dan ook met de sector- en brancheorganisaties wil delen, ben ik heel erg blij. Ik denk dat het haar positie als eindverantwoordelijke voor cybersecurity ook wel past om daarmee actief de boer op te gaan." De Tweede Kamer moet nog over de motie stemmen.
Reacties (43)
D66 wil patchbrigades die bedrijven actief gaan helpen met dichten van lekken.
Heel interessant natuurlijk d666, alleen werkt het niet zo in de praktijk. Vraag dat maar aan de eerste beste systeembeheerder. Die kunnen je er alles over vertellen.
21-04-2022, 12:01 door
gradje71
Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Daar kunnen we wat mee. Dank je voor deze bijdrage.
Zorg je dan ook dat alle software geschreven is voor Windows "even" wordt geport naar het superveilige Linux? Want ook daar kunnen net zo goed lekken in voorkomen als in Windows. Wordt altijd zo simpel overgedaan.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Behalve dan dat 9 op 10 datalekken en kwetsbaarheden niks met Windows van doen hebben en al helemaal niet met het OS zelf. Was het maar waar dan was ons werk een stuk makkelijker.Probleem opgelost.
Ben benieuwd hoe men de implementatie hiervan voor ogen heeft. Wordt de rekening voor deze patchbrigades dan ook bij de bedrijven neergelegd?
Als je dat niet doet, gaan bedrijven achterover leunen (lees: geen kosten maken voor ICT beveiliging) en als het misgaat, komt de overheid het kosteloos voor je oplossen. Dat kan ook niet de bedoeling zijn.
Als je dat niet doet, gaan bedrijven achterover leunen (lees: geen kosten maken voor ICT beveiliging) en als het misgaat, komt de overheid het kosteloos voor je oplossen. Dat kan ook niet de bedoeling zijn.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Want Linux hoef je niet te patchen? Niet alles is aan Windows te hangen.
Het is wel
Wat zeker geldt bij closed-software is dat er uiteindelijk vaak in de buidel getast zal moeten worden voor updates. Dat levert uitstelgedrag op ("dat is toch niet erg") en dat wordt een cultuur op zich ("hoe lang kan ik het rekken").
Conclusie: Bij closed source worden updates "belast" in plaats van "beloond". Dus dat moet omgekeerd worden.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Wat zeker geldt bij closed-software is dat er uiteindelijk vaak in de buidel getast zal moeten worden voor updates. Dat levert uitstelgedrag op ("dat is toch niet erg") en dat wordt een cultuur op zich ("hoe lang kan ik het rekken").
Conclusie: Bij closed source worden updates "belast" in plaats van "beloond". Dus dat moet omgekeerd worden.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Zo simpel is het niet meer. Ook andere OS en software zijn kwetsbaar tegenwoordig voor beveiligingslekken en bugs.
Gewoon meer audits met zwaardere straffen. Je moet het bedrijven heel helder maken dat ze meer geld verliezen als ze de zaakjes niet op orde hebben. De keuze om hier geen geld in te steken is volgens mij vaak te makkelijk gemaakt.
Als er geen biodiversiteit was ("Windows") zou dat misschien helpen.
Maar telewerkoplossing (n-leveranciers), administratie (m-leveranciers,x-versies), netwerken (o-leveranciers, y-versies), ... vraagt een onmogelijke kennisbasis van de brigades. En op het moment dat ze wegrijden wordt de volgende zero-day bekend ...
Eis betere software/productkwaliteit, testen voior uitrol en productaansprakelijkheid (kosten te declareren bij leverancier) dan ...
Dit soort moties heeft niemand wat aan; sterker nog de minister gaat niet over het private domein!
(afleiding door D66 van hun problemen met integriteit en vertrouwlijkheid? Beschikbaarheid en authenticiteit zijn de volgende kernaspecten ...
Maar telewerkoplossing (n-leveranciers), administratie (m-leveranciers,x-versies), netwerken (o-leveranciers, y-versies), ... vraagt een onmogelijke kennisbasis van de brigades. En op het moment dat ze wegrijden wordt de volgende zero-day bekend ...
Eis betere software/productkwaliteit, testen voior uitrol en productaansprakelijkheid (kosten te declareren bij leverancier) dan ...
Dit soort moties heeft niemand wat aan; sterker nog de minister gaat niet over het private domein!
(afleiding door D66 van hun problemen met integriteit en vertrouwlijkheid? Beschikbaarheid en authenticiteit zijn de volgende kernaspecten ...
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Doe niet zo raar. Als iedereen straks op bv linux werkt zal je een verschuiving zien van windows naar linux, simpelweg omdat de massa daar gebruik van maakt.
Gewoon een kwestie van goede afspraken en fatsoenlijk beheer.
Het probleem wordt wederom niet opgelost. Zo kennen we onze overheid weer.
Ondertussen meer gaan betuttelen. Past mooi bij D66.
Ga eens wat nuttigs doen.
Ondertussen meer gaan betuttelen. Past mooi bij D66.
Ga eens wat nuttigs doen.
Door Anoniem:
Daar kunnen we wat mee. Dank je voor deze bijdrage.
Zorg je dan ook dat alle software geschreven is voor Windows "even" wordt geport naar het superveilige Linux? Want ook daar kunnen net zo goed lekken in voorkomen als in Windows. Wordt altijd zo simpel overgedaan.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Daar kunnen we wat mee. Dank je voor deze bijdrage.
Zorg je dan ook dat alle software geschreven is voor Windows "even" wordt geport naar het superveilige Linux? Want ook daar kunnen net zo goed lekken in voorkomen als in Windows. Wordt altijd zo simpel overgedaan.
Ik ben bang dat er in de toekomst juist meer "malware"e.d. geschreven zl worden,want de "skriptkidddies 'en malware makers komen vooral uit de linuxhoek.
Dus ik denk dat windows juist veiliger zal blijken
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Goh, dat is nieuws voor al die gehackte Wordpress en Magento sites die op Linux draaien, dat hun probleem niet bestaat.
Door Anoniem: Het is wel
Wat zeker geldt bij closed-software is dat er uiteindelijk vaak in de buidel getast zal moeten worden voor updates. Dat levert uitstelgedrag op ("dat is toch niet erg") en dat wordt een cultuur op zich ("hoe lang kan ik het rekken").
Conclusie: Bij closed source worden updates "belast" in plaats van "beloond". Dus dat moet omgekeerd worden.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Wat zeker geldt bij closed-software is dat er uiteindelijk vaak in de buidel getast zal moeten worden voor updates. Dat levert uitstelgedrag op ("dat is toch niet erg") en dat wordt een cultuur op zich ("hoe lang kan ik het rekken").
Conclusie: Bij closed source worden updates "belast" in plaats van "beloond". Dus dat moet omgekeerd worden.
Onzin. Daar sluit je dan juist onderhoudscontracten of abonnementen voor af. En zeker voor je dure en/of bedrijfs-critische applicaties. Dus dat zijn jaarlijks terugkerende kosten waar je al rekening mee houdt bij de aanschaf.
En soms is goedkoop (bv gratis) duurkoop.
Vraagje:
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?
Open source is namelijk soms ook buggy. Kijk naar het recente Log4j debacle.
Bij die closed source bedrijfsapplicaties gingen de leveranciers juist rennen om hun sofware te controleren en waar nodig fixes uit te brengen. Dat voorwerk werd ons dus uit handen genomen. Wij konden ons richten op het tijdelijk extra beveiligen en afschermen van de kwetsbare plekken in het netwerk die hierdoor ontstaan waren.
Door Anoniem: Ben benieuwd hoe men de implementatie hiervan voor ogen heeft. Wordt de rekening voor deze patchbrigades dan ook bij de bedrijven neergelegd?
Als je dat niet doet, gaan bedrijven achterover leunen (lees: geen kosten maken voor ICT beveiliging) en als het misgaat, komt de overheid het kosteloos voor je oplossen. Dat kan ook niet de bedoeling zijn.
Als je dat niet doet, gaan bedrijven achterover leunen (lees: geen kosten maken voor ICT beveiliging) en als het misgaat, komt de overheid het kosteloos voor je oplossen. Dat kan ook niet de bedoeling zijn.
Als het misgaat ?
Als het misgegaan is en je bent gehacked, of geransomed , is er heel wat meer nodig dan patchen om de boel te herstellen .
Ik kan de gedachtengang wel begrijpen :
Er wordt te weinig gepatched wegens "moeilijk" , en dan komt het idee van een setje hulptroepen om te helpen "dat moeilijke ding" te doen .
Net zoals er zo af en toe van die initiatieven zijn vanuit de politie om hang-en sluitwerk te verbeteren, of fietsen te graveren en dat soort dingen.
Wat die voorstellers niet weten is dat het patchen zelf meestal niet moeilijk is - maar wel het inschatten van de gevolgen , en die fixen als de patch een probleem veroorzaakt .
En dat is wat het - ook voor erg ervaren mensen - lastig maakt om in een totaal nieuwe omgeving "gewoon" de patches "even" te doen - en wiens schuld is het als er dan dingen misgaan ?
Langskomen en klikken op 'install updates' is het simpele deel. Als je daarna de komende drie jaar de schuld krijgt van alles wat er "niet meer" werkt is het niet zo welkom meer.
Nu hebben een hoop mensen inderdaad gewoon koudwatervrees en worden de horrorverhalen van "alles kapot na een patch" nogal overdreven . Maar - het _kan_ misgaan, en dan is een rondje updates installeren opeens een heel grote klus geworden.
En is dat erg lastig in een onbekende - en natuurlijk ongedocumenteerde - omgeving.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
De maatschappij van 1994 probleem helemaal opgelost
Sectororganisaties bereiken vooral de grotere bedrijven. Het probleem zit hem vooral bij de kleinere bedrijven, de een-pitters.
Het is wettelijk verplicht om een boekhouding te hebben en om persoonsgegevens te beschermen. Laat de middenstandsdiploma terugkomen in een moderne vorm, die ondernemers basisvaardigheden bijbrengt en kennis laat maken met verplichtingen. Met een onafhankelijk tijdschrift dat voor nieuws zorgt. Niet aan de sector of de markt overlaten.
Het is wettelijk verplicht om een boekhouding te hebben en om persoonsgegevens te beschermen. Laat de middenstandsdiploma terugkomen in een moderne vorm, die ondernemers basisvaardigheden bijbrengt en kennis laat maken met verplichtingen. Met een onafhankelijk tijdschrift dat voor nieuws zorgt. Niet aan de sector of de markt overlaten.
Uit mijn ervaring blijkt dat er een aantal hoofdoorzaken zijn dat bedrijven niet gepatched zijn tegen lekken:
#1 er is geen patch van de leverancier (zero-day, fabrikant EOL, product EOL, support contract niet betaalbaar of niet betaald om kosten te beknibbelen (dat ding werkt toch al 5 jaar zonder probleem?))
#2 er is geen tijd om het te patchen (services waar de boterham mee verdient wordt kan simpelweg niet meer uit/down of in uitzonderlijke situaties, vaak na maanden productie, het patchen geeft klanten en leveranciers aan welk product je gebruikt en sommige willen dat niet aan hun klanten mededelen
#3 er is niemand die het overziet wat de consequenties zijn van het patchen (voorbeeld: VPN concentrator moet gepatched worden. weet IT welke VPN gebruikers er zijn en wat die doen, wanneer ze dat doen, wie de contactpersonen zijn, welke productiestromen er overheen gaan, wanneer die gaan, wanneer er batches zijn die absoluut niet verstoord mogen worden?)
#4 de kwaliteit van de patches is vaak bedroevend (patches maken meer stuk dan het probleem zou doen, patches zijn regelmatig niet alleen patches maar ook functionaliteitsveranderingen waardoor productieprocessen ineens niet meer werken).
Dus kort door de bocht, als updaten/patches uitrollen betrouwbaar ging, er genoeg mensen zijn die weten hoe en wat en wanneer en deze ook nog eens betaalbaar zijn voor iedereen die ze gebruikt en ze niet stiekem dingen veranderen op de achtergrond dan zou niemand problemen hebben met uitrollen patches...
Zorg daarvoor en dan zijn die D66 subsidiesponzen niet nodig... want dat is waar het waarschijnlijk om gaat bij D66.. vriendjes die IT bedrijven hebben die voor overheids subsidie het MKB nog wel erger de boot in gaat helpen.
#1 er is geen patch van de leverancier (zero-day, fabrikant EOL, product EOL, support contract niet betaalbaar of niet betaald om kosten te beknibbelen (dat ding werkt toch al 5 jaar zonder probleem?))
#2 er is geen tijd om het te patchen (services waar de boterham mee verdient wordt kan simpelweg niet meer uit/down of in uitzonderlijke situaties, vaak na maanden productie, het patchen geeft klanten en leveranciers aan welk product je gebruikt en sommige willen dat niet aan hun klanten mededelen
#3 er is niemand die het overziet wat de consequenties zijn van het patchen (voorbeeld: VPN concentrator moet gepatched worden. weet IT welke VPN gebruikers er zijn en wat die doen, wanneer ze dat doen, wie de contactpersonen zijn, welke productiestromen er overheen gaan, wanneer die gaan, wanneer er batches zijn die absoluut niet verstoord mogen worden?)
#4 de kwaliteit van de patches is vaak bedroevend (patches maken meer stuk dan het probleem zou doen, patches zijn regelmatig niet alleen patches maar ook functionaliteitsveranderingen waardoor productieprocessen ineens niet meer werken).
Dus kort door de bocht, als updaten/patches uitrollen betrouwbaar ging, er genoeg mensen zijn die weten hoe en wat en wanneer en deze ook nog eens betaalbaar zijn voor iedereen die ze gebruikt en ze niet stiekem dingen veranderen op de achtergrond dan zou niemand problemen hebben met uitrollen patches...
Zorg daarvoor en dan zijn die D66 subsidiesponzen niet nodig... want dat is waar het waarschijnlijk om gaat bij D66.. vriendjes die IT bedrijven hebben die voor overheids subsidie het MKB nog wel erger de boot in gaat helpen.
Ik hoor veel reclame voor linux, omdat dit besturingsprogramma zo geweldig goed is en geen patches nodig zou hebben, indien iedereen daarop zou overgaan zouden we daarvan zijn verlost. Maar welke van de 88 of meer Linux versies zou hiervoor geschikt zijn, dat weten de sympathisanten zelf niet, want ze gebruiken alleen maar de algemene omschrijving van deze ontelbare varianten dat Linux heet, waarvan aangenomen mag worden ook een groot deel in landen als Rusland en China worden ontwikkeld.
En patches op zich zijn natuurlijk al een eufemisme voor slecht en armoedig programmeren..
En patches op zich zijn natuurlijk al een eufemisme voor slecht en armoedig programmeren..
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
Naar linux zeker met dat geweldige permission management system. Ha ha.
Zullen we ons foccussen op dingen die echt helpen?
Een nationaal CERT of digibrandweer, - hoe je het noemen wil - lijkt me echt geen oplossing.
Die vinden het straks vast handig om op afstand in te kunnen loggen. Een nationaal exertise centrum hebben we al NCSC. Laten we dat uitbreiden en laat ze boetes opleggen aan bedrijven via AP aan bedrijven die beveiling niet serieus nemen.
Het DTC afschaffen en onderbrengen bij NCSC.
Door gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Probleem opgelost.
dussss... omdat mn Cisco firewall 30 versies achter ligt en een groot gapend gat is moet ik alle windows machines eruit gooien zo dat mn netwerk veilig is.... klinkt logisch... of mn IOT devices en PLC's zijn risico apparatuur maar zolang ik windows maar uit mn netwerk gooi lost het zichzelf op.... goed verhaal, wel lekker kort maar doen we helemaal niks mee.
Door waterlelie: Ik hoor veel reclame voor linux, omdat dit besturingsprogramma zo geweldig goed is en geen patches nodig zou hebben, indien iedereen daarop zou overgaan zouden we daarvan zijn verlost. Maar welke van de 88 of meer Linux versies zou hiervoor geschikt zijn, dat weten de sympathisanten zelf niet, want ze gebruiken alleen maar de algemene omschrijving van deze ontelbare varianten dat Linux heet, waarvan aangenomen mag worden ook een groot deel in landen als Rusland en China worden ontwikkeld.
En patches op zich zijn natuurlijk al een eufemisme voor slecht en armoedig programmeren..
En patches op zich zijn natuurlijk al een eufemisme voor slecht en armoedig programmeren..
Waarom heeft iedereen het hier over Linux? Het enige wat ik zei dat is: Gooi Windows eruit.
Ben je ook bekend met zoiets als *BSD? De grondlaag van OSX is ook BSD, maar OSX is dan wel weer een typisch voorbeeld van hoe het niet moet. Kijk bv hier eens in https://github.com/helloSystem/hello en scroll dan een keer omlaag.
Echt weer een oplossing van een mensen die geen idee hebben van de inhoud.
Er ontstaan ook steeds weer nieuwe sites en organisaties die ons adviseren en helpen. lijkt me meer een methode om ambtenaren aan het werk te houden.
Er ontstaan ook steeds weer nieuwe sites en organisaties die ons adviseren en helpen. lijkt me meer een methode om ambtenaren aan het werk te houden.
Ah ja, het ligt aan...
Windows, *nix er is altijd wel een vulnerability te vinden: https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally (voor het kijk eens naar *BSD argument).
Het is jammer dat security inmiddels staat voor geld binnenharken (getuige de vele bedrijven die iets met security van doen hebben). Misschien helpt het als we personeel fatsoenlijk opleiden, begeleiden en ons verzekeren dat ze affiniteit met het werk hebben, dan is mijn inziens het uitvoerende stuk wel te fixen. En dan de bovenliggende lagen nog.
Windows, *nix er is altijd wel een vulnerability te vinden: https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally (voor het kijk eens naar *BSD argument).
Het is jammer dat security inmiddels staat voor geld binnenharken (getuige de vele bedrijven die iets met security van doen hebben). Misschien helpt het als we personeel fatsoenlijk opleiden, begeleiden en ons verzekeren dat ze affiniteit met het werk hebben, dan is mijn inziens het uitvoerende stuk wel te fixen. En dan de bovenliggende lagen nog.
"Vraagje:
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?"
Ja hier wel maar dat neemt niet weg dat je nog wel beheer hebt en updates moet doen etc. maar daar komt dan wel een ander praktijk verschil om de hoek kijken, voor ons is RHEL/CentOS/Alma/Rocky zo stabiel dat alle updates die binnen komen meteen doorgevoerd kunnen worden live.
Alleen bij een nieuwe kernel moeten we even kijken of een reboot dan nog nodig is en dat kan dan ook nog eens een warm-reboot zijn die meteen de nieuwe kernel opstart via kexec ipv ook nog eens door de POST/BIOS te gaan. Vaak is de patch ook niet eens zo kritisch voor machines die niet direct benaderbaar zijn vanaf internet voor gebruikers dan die reboot vwb de kernel wel een weekje uitgesteld kan worden.
En zoiets doen we dan gemakkelijk voor een omgeving met ~500 machines.
Tja... hoe kan dat dan toch kun je je nu gaan afvragen...
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?"
Ja hier wel maar dat neemt niet weg dat je nog wel beheer hebt en updates moet doen etc. maar daar komt dan wel een ander praktijk verschil om de hoek kijken, voor ons is RHEL/CentOS/Alma/Rocky zo stabiel dat alle updates die binnen komen meteen doorgevoerd kunnen worden live.
Alleen bij een nieuwe kernel moeten we even kijken of een reboot dan nog nodig is en dat kan dan ook nog eens een warm-reboot zijn die meteen de nieuwe kernel opstart via kexec ipv ook nog eens door de POST/BIOS te gaan. Vaak is de patch ook niet eens zo kritisch voor machines die niet direct benaderbaar zijn vanaf internet voor gebruikers dan die reboot vwb de kernel wel een weekje uitgesteld kan worden.
En zoiets doen we dan gemakkelijk voor een omgeving met ~500 machines.
Tja... hoe kan dat dan toch kun je je nu gaan afvragen...
Door waterlelie: Ik hoor veel reclame voor linux, omdat dit besturingsprogramma zo geweldig goed [...]
Voor wie het Linux wereldje een beetje kent, is onderstaand schema duidelijk: er wordt goed geld mee verdiend.
project ondersteuning beoogde doelgroepen
-----------------------------------------------------------------
Fedora RedHat.com datacentra en grote ondernemingen
Debian Ubuntu.com onderwijs en grote ondernemingen
openSUSE Suse.com technisch midden- en kleinbedrijf
Dit is wat de grote middenmoot toepast. De aangegeven doelgroepen zijn slechts indicatief, omdat men Debian ook aantreft in bijvoorbeeld grote datacentra en Red Hat ook wel in het midden- en kleinbedrijf. RedHat is gebaseerd op Fedora en Ubuntu is gebaseerd op Debian. Het verschil zit in de wijze waarop de paketten worden beheerd en wat voor aanvullende beveiligingsmaatregelen zijn genomen, zoals het verschil tussen AppArmor versus SELinux.
Weer zo'n ad-hoc oplossing waar niet over nagedacht is: even een pleister plakken door te vertellen dat er groepen mensen zijn (patchbrigades) die bij jou wel eens de boel op orde komen brengen. Setup-for-failure want zonder kennis van je omgeving, onderlinge afhankelijkheden, architectuur, maatregelen etc.
Wat meer zou helpen is een basisniveau definieren waar iedereen aan moet voldoen, plus additionele eisen afhankelijk van grootte en/of maatschappelijke impact. En dan geen boetes (immers, wie gaat dat controleren), maar dat je bv. geen cybersecurity verzekering kan afsluiten. Of dat je accountants daarover moeten rapporteren in het jaarverslag.
Op die manier maak je het een bedrijfsleiding probleem ipv. een IT probleem.
Wat meer zou helpen is een basisniveau definieren waar iedereen aan moet voldoen, plus additionele eisen afhankelijk van grootte en/of maatschappelijke impact. En dan geen boetes (immers, wie gaat dat controleren), maar dat je bv. geen cybersecurity verzekering kan afsluiten. Of dat je accountants daarover moeten rapporteren in het jaarverslag.
Op die manier maak je het een bedrijfsleiding probleem ipv. een IT probleem.
Door Anoniem: Uit mijn ervaring blijkt dat er een aantal hoofdoorzaken zijn dat bedrijven niet gepatched zijn tegen lekken:
#1 er is geen patch van de leverancier (zero-day, fabrikant EOL, product EOL, support contract niet betaalbaar of niet betaald om kosten te beknibbelen (dat ding werkt toch al 5 jaar zonder probleem?))
#2 er is geen tijd om het te patchen (services waar de boterham mee verdient wordt kan simpelweg niet meer uit/down of in uitzonderlijke situaties, vaak na maanden productie, het patchen geeft klanten en leveranciers aan welk product je gebruikt en sommige willen dat niet aan hun klanten mededelen
#3 er is niemand die het overziet wat de consequenties zijn van het patchen (voorbeeld: VPN concentrator moet gepatched worden. weet IT welke VPN gebruikers er zijn en wat die doen, wanneer ze dat doen, wie de contactpersonen zijn, welke productiestromen er overheen gaan, wanneer die gaan, wanneer er batches zijn die absoluut niet verstoord mogen worden?)
#4 de kwaliteit van de patches is vaak bedroevend (patches maken meer stuk dan het probleem zou doen, patches zijn regelmatig niet alleen patches maar ook functionaliteitsveranderingen waardoor productieprocessen ineens niet meer werken).
Dus kort door de bocht, als updaten/patches uitrollen betrouwbaar ging, er genoeg mensen zijn die weten hoe en wat en wanneer en deze ook nog eens betaalbaar zijn voor iedereen die ze gebruikt en ze niet stiekem dingen veranderen op de achtergrond dan zou niemand problemen hebben met uitrollen patches...
Zorg daarvoor en dan zijn die D66 subsidiesponzen niet nodig... want dat is waar het waarschijnlijk om gaat bij D66.. vriendjes die IT bedrijven hebben die voor overheids subsidie het MKB nog wel erger de boot in gaat helpen.
#1 er is geen patch van de leverancier (zero-day, fabrikant EOL, product EOL, support contract niet betaalbaar of niet betaald om kosten te beknibbelen (dat ding werkt toch al 5 jaar zonder probleem?))
#2 er is geen tijd om het te patchen (services waar de boterham mee verdient wordt kan simpelweg niet meer uit/down of in uitzonderlijke situaties, vaak na maanden productie, het patchen geeft klanten en leveranciers aan welk product je gebruikt en sommige willen dat niet aan hun klanten mededelen
#3 er is niemand die het overziet wat de consequenties zijn van het patchen (voorbeeld: VPN concentrator moet gepatched worden. weet IT welke VPN gebruikers er zijn en wat die doen, wanneer ze dat doen, wie de contactpersonen zijn, welke productiestromen er overheen gaan, wanneer die gaan, wanneer er batches zijn die absoluut niet verstoord mogen worden?)
#4 de kwaliteit van de patches is vaak bedroevend (patches maken meer stuk dan het probleem zou doen, patches zijn regelmatig niet alleen patches maar ook functionaliteitsveranderingen waardoor productieprocessen ineens niet meer werken).
Dus kort door de bocht, als updaten/patches uitrollen betrouwbaar ging, er genoeg mensen zijn die weten hoe en wat en wanneer en deze ook nog eens betaalbaar zijn voor iedereen die ze gebruikt en ze niet stiekem dingen veranderen op de achtergrond dan zou niemand problemen hebben met uitrollen patches...
Zorg daarvoor en dan zijn die D66 subsidiesponzen niet nodig... want dat is waar het waarschijnlijk om gaat bij D66.. vriendjes die IT bedrijven hebben die voor overheids subsidie het MKB nog wel erger de boot in gaat helpen.
+ 5 (of eerder 0): IT-medewerkers hebben geen idee welke systemen er in het netwerk draaien, dus hebben geen idee wat er eigenlijk eventueel gepatcht zou moeten worden...
Volgens mij is er bij D66 zelf ook nog wel een en ander te patchen... misschien maar eens een brigade op zetten?
Door Anoniem: "Vraagje:
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?"
Ja hier wel maar dat neemt niet weg dat je nog wel beheer hebt en updates moet doen etc. maar daar komt dan wel een ander praktijk verschil om de hoek kijken, voor ons is RHEL/CentOS/Alma/Rocky zo stabiel dat alle updates die binnen komen meteen doorgevoerd kunnen worden live.
Alleen bij een nieuwe kernel moeten we even kijken of een reboot dan nog nodig is en dat kan dan ook nog eens een warm-reboot zijn die meteen de nieuwe kernel opstart via kexec ipv ook nog eens door de POST/BIOS te gaan. Vaak is de patch ook niet eens zo kritisch voor machines die niet direct benaderbaar zijn vanaf internet voor gebruikers dan die reboot vwb de kernel wel een weekje uitgesteld kan worden.
En zoiets doen we dan gemakkelijk voor een omgeving met ~500 machines.
Tja... hoe kan dat dan toch kun je je nu gaan afvragen...
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?"
Ja hier wel maar dat neemt niet weg dat je nog wel beheer hebt en updates moet doen etc. maar daar komt dan wel een ander praktijk verschil om de hoek kijken, voor ons is RHEL/CentOS/Alma/Rocky zo stabiel dat alle updates die binnen komen meteen doorgevoerd kunnen worden live.
Alleen bij een nieuwe kernel moeten we even kijken of een reboot dan nog nodig is en dat kan dan ook nog eens een warm-reboot zijn die meteen de nieuwe kernel opstart via kexec ipv ook nog eens door de POST/BIOS te gaan. Vaak is de patch ook niet eens zo kritisch voor machines die niet direct benaderbaar zijn vanaf internet voor gebruikers dan die reboot vwb de kernel wel een weekje uitgesteld kan worden.
En zoiets doen we dan gemakkelijk voor een omgeving met ~500 machines.
Tja... hoe kan dat dan toch kun je je nu gaan afvragen...
Hmm. Hier draaien ook linux-servers, naast windows machines.
Als het allemaal zo vlekkeloos gaat, waarom moet ik dan elke keer in het weekend komen opdraven om een stel bedrijfsapplicaties te testen, alleen omdat de linux-kernel van die servers een update krijgt.
Blijkbaar overziien niet alle systeembeheerders de impact van de updates die ze moeten uitrollen. Anders zou dat testen niet nodig zijn. (En ja, we vinden bij het testen na zo'n linux-update af en toe ook eens iets dat het niet meer goed doet)
Dus lekker "gemakkelijk" allemaal, dat updaten.
Even vloeken in de kerk:
Maar wil je de kwetsbaarheid verminderen, dan is een andere oplossing om de digitalisering en automatisering deels terug te draaien. Begin er maar mee om niet alles aan elkaar en het internet te willen koppelen. Dat verminderd een aantal risico's al.
Maar wil je de kwetsbaarheid verminderen, dan is een andere oplossing om de digitalisering en automatisering deels terug te draaien. Begin er maar mee om niet alles aan elkaar en het internet te willen koppelen. Dat verminderd een aantal risico's al.
Door Anoniem:
Hmm. Hier draaien ook linux-servers, naast windows machines.
Als het allemaal zo vlekkeloos gaat, waarom moet ik dan elke keer in het weekend komen opdraven om een stel bedrijfsapplicaties te testen, alleen omdat de linux-kernel van die servers een update krijgt.
Blijkbaar overziien niet alle systeembeheerders de impact van de updates die ze moeten uitrollen. Anders zou dat testen niet nodig zijn. (En ja, we vinden bij het testen na zo'n linux-update af en toe ook eens iets dat het niet meer goed doet)
Dus lekker "gemakkelijk" allemaal, dat updaten.
Het ligt vaak ook aan wat je infra precies voor functie heeft hoeveel ellende je meemaakt per week.Door Anoniem: "Vraagje:
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?"
Ja hier wel maar dat neemt niet weg dat je nog wel beheer hebt en updates moet doen etc. maar daar komt dan wel een ander praktijk verschil om de hoek kijken, voor ons is RHEL/CentOS/Alma/Rocky zo stabiel dat alle updates die binnen komen meteen doorgevoerd kunnen worden live.
Alleen bij een nieuwe kernel moeten we even kijken of een reboot dan nog nodig is en dat kan dan ook nog eens een warm-reboot zijn die meteen de nieuwe kernel opstart via kexec ipv ook nog eens door de POST/BIOS te gaan. Vaak is de patch ook niet eens zo kritisch voor machines die niet direct benaderbaar zijn vanaf internet voor gebruikers dan die reboot vwb de kernel wel een weekje uitgesteld kan worden.
En zoiets doen we dan gemakkelijk voor een omgeving met ~500 machines.
Tja... hoe kan dat dan toch kun je je nu gaan afvragen...
Bij jullie op het werk (aanname: jullie gebruiken alleen linux-omgevingen) daar hebben jullie geen commerciele licenties voor aangeschaft en onderhoudscontracten voor afgesloten? Daar gebruiken jullie de community versies voor?
Alles wat jullie daar gebruiken is open source én gratis?"
Ja hier wel maar dat neemt niet weg dat je nog wel beheer hebt en updates moet doen etc. maar daar komt dan wel een ander praktijk verschil om de hoek kijken, voor ons is RHEL/CentOS/Alma/Rocky zo stabiel dat alle updates die binnen komen meteen doorgevoerd kunnen worden live.
Alleen bij een nieuwe kernel moeten we even kijken of een reboot dan nog nodig is en dat kan dan ook nog eens een warm-reboot zijn die meteen de nieuwe kernel opstart via kexec ipv ook nog eens door de POST/BIOS te gaan. Vaak is de patch ook niet eens zo kritisch voor machines die niet direct benaderbaar zijn vanaf internet voor gebruikers dan die reboot vwb de kernel wel een weekje uitgesteld kan worden.
En zoiets doen we dan gemakkelijk voor een omgeving met ~500 machines.
Tja... hoe kan dat dan toch kun je je nu gaan afvragen...
Hmm. Hier draaien ook linux-servers, naast windows machines.
Als het allemaal zo vlekkeloos gaat, waarom moet ik dan elke keer in het weekend komen opdraven om een stel bedrijfsapplicaties te testen, alleen omdat de linux-kernel van die servers een update krijgt.
Blijkbaar overziien niet alle systeembeheerders de impact van de updates die ze moeten uitrollen. Anders zou dat testen niet nodig zijn. (En ja, we vinden bij het testen na zo'n linux-update af en toe ook eens iets dat het niet meer goed doet)
Dus lekker "gemakkelijk" allemaal, dat updaten.
Ik zou niet zonder Linux kunnen in onze hosting diensten het is stabiel het wordt adequaat ondersteund maar qua troubleshooting en patching is het echt wel een grotere uitdaging dan een Windows server die bijvoorbeeld domain controller als rol heeft.
Je vendors zitten overal en nergens want laten we eerlijk zijn ook al gebruik je een commerciel product met linux based OS je hebt altijd nog je beveiliging suite je monitoring diensten en heel scala aan hulpservices die allemaal weer afhankelijk zijn van kleinere libraries geschreven door enthousiastelingen universiteiten en of andere bedrijven. Je main vendor zal daar weer een eigen patch voor proberen uit te geven maar in praktijk zul je altijd toch nog de achtergrond info moeten vergaren van de originele devs.
Voor beeldvorming we ontvangen twee keer per dag patches op onze test servers en 1 keer per dag op de productie. Dat is als er geen kwetsbaarheden zijn gevonden in enig onderdeel wat neer komt op dat je meerdee keren per dag patches erdoor heen jaagt als het om acuut gevaar gaat.
Het grote voordeel wat al benoemd is meestal hoef je de servers niet te rebooten voor updates wat echter niet verteld wordt is dat de services op de server wel degelijk restarten voor de updates of je hebt er niks aan. Als je dus public facing diensten hebt is de kans kleiner dat klanten last ergens van hebben maar het kan nog steeds voorkomen.
En waar je je heel erg kan iriteren aan Microsoft die functies eruit gooit of introduceert heb je dit ook nog steeds Bij Linux OS vendors. Wij zitten met een heel stel grote datacenters momenteel in een vriendelijke argument over wat de beep ze hebben gedaan met onze interfaces in een nieuwe release. Maanden onderhandelingen compromis sluiten tijd die je vrij moet maken of anders riskeer je iets doorgedrukt te krijgen dat niet naar wensen is of gezeik geeft met hoeveelheid inkomende calls van je klanten omdat het ene knopje nu ineens rechtsstaat.
Daarnaast zijn commerciele Linux vendors ook berucht erop dat prijzen zeer wispelturig zijn je uitgaves kunnen binnen jaar enorm stijgen of van eenmalige aanschaf naar per maand per jaar model veranderen. Bedrijven worden opgekocht door andere spelers je vendor kan misschien ineens de zelfde stabiliteit van een bonus product niet meer garanderen.
Let wel dit is mijn kennis als 20+ jaar hosting netwerk professional op Linux based servers waar klanten ook zelf beheer kunnen doen over hun eigen Server enviro. Als je Linux enkel voor je eigen bedrijf runt zal deze ellende een stuk minder ziijn.
Linux is geen wonder software het is simpel software en ongeacht wat je gebruikt je hebt een uitdaging klaar liggen.
22-04-2022, 13:30 door
Reinder
"Hallo! Wij zijn de vliegende patchbrigade, wij komen u adviseren en helpen bij het uitrollen van patches!"
"Dat is geweldig! Vertel me, wat moet ik doen?"
'Nou, u klikt op update, en dan next next finish en dan reboot"
"Oh geweldig! Dank u vliegende patchbrigade!"
"Dat is geweldig! Vertel me, wat moet ik doen?"
'Nou, u klikt op update, en dan next next finish en dan reboot"
"Oh geweldig! Dank u vliegende patchbrigade!"
Door Reinder: "Hallo! Wij zijn de vliegende patchbrigade, wij komen u adviseren en helpen bij het uitrollen van patches!"
"Dat is geweldig! Vertel me, wat moet ik doen?"
'Nou, u klikt op update, en dan next next finish en dan reboot"
"Oh geweldig! Dank u vliegende patchbrigade!"
"Dat is geweldig! Vertel me, wat moet ik doen?"
'Nou, u klikt op update, en dan next next finish en dan reboot"
"Oh geweldig! Dank u vliegende patchbrigade!"
Voor een deel van de niet gepatchte systemen is het inderdaad zo simpel . De uitdaging zit hem in het andere deel.
Door Reinder: "Hallo! Wij zijn de vliegende patchbrigade, wij komen u adviseren en helpen bij het uitrollen van patches!"
Goedennacht, Welkom op onze Linux farm. Wij draaien hier een Ubuntu cluster met 256 watergekoelde CPUs.
"Dat is geweldig! Vertel me, wat moet ik doen?"
De volgende cronjob aanzetten en de Livepatch modus voor de kernels toepassen. Dat kan desgewenst ook grafisch.
apt update && apt upgrade
Nou, moet ik op update klikken, en dan next next finish en dan reboot?"
Dat hoeft niet, want het update en reboot proces verloopt ´s nacht vanzelf. De klanten merken daar niets van.
"Oh geweldig! Dank u vliegende Linux farm!"
Geen dank. Als u verder nog vragen mocht hebben, dan zijn wij altijd telefonisch 365/24/7 bereikbaar. Ook via Signal.
Hmm. Hier draaien ook linux-servers, naast windows machines.
Als het allemaal zo vlekkeloos gaat, waarom moet ik dan elke keer in het weekend komen opdraven om een stel bedrijfsapplicaties te testen, alleen omdat de linux-kernel van die servers een update krijgt.
Blijkbaar overziien niet alle systeembeheerders de impact van de updates die ze moeten uitrollen. Anders zou dat testen niet nodig zijn. (En ja, we vinden bij het testen na zo'n linux-update af en toe ook eens iets dat het niet meer goed doet)
Dus lekker "gemakkelijk" allemaal, dat updaten.
nah duidelijk geen RHEL/CentOS/Alma/Rocky in gebruik dan...
"Het grote voordeel wat al benoemd is meestal hoef je de servers niet te rebooten voor updates wat echter niet verteld wordt is dat de services op de server wel degelijk restarten voor de updates of je hebt er niks aan. Als je dus public facing diensten hebt is de kans kleiner dat klanten last ergens van hebben maar het kan nog steeds voorkomen."
heb je needs-restarting voor.
"En waar je je heel erg kan iriteren aan Microsoft die functies eruit gooit of introduceert heb je dit ook nog steeds Bij Linux OS vendors."
tja dan gebruik toch echt iets anders dan RHEL/CentOS/Rocky/Alma.
heb je needs-restarting voor.
"En waar je je heel erg kan iriteren aan Microsoft die functies eruit gooit of introduceert heb je dit ook nog steeds Bij Linux OS vendors."
tja dan gebruik toch echt iets anders dan RHEL/CentOS/Rocky/Alma.
IT is uitermate complex, van beheer tot programmeer en management. Niet voor iedereen! Maar voor velen wel. Het is een goed initiatief. Als je betere ideeen hebt laat je dan vooral (opbouwend) horen.
Ze willen voornamelijk het laag hangende fruit oplossen (lijkt me) en een basis leggen voor het veilig houden van alle IT. Bedenk je, dat de meest successvolle (sociale) projecten vaak een samenwerken tussen de overheid en de privaat sector zijn.
- Ramlatel
Ze willen voornamelijk het laag hangende fruit oplossen (lijkt me) en een basis leggen voor het veilig houden van alle IT. Bedenk je, dat de meest successvolle (sociale) projecten vaak een samenwerken tussen de overheid en de privaat sector zijn.
- Ramlatel
Door Anoniem: "Het grote voordeel wat al benoemd is meestal hoef je de servers niet te rebooten voor updates wat echter niet verteld wordt is dat de services op de server wel degelijk restarten voor de updates of je hebt er niks aan. Als je dus public facing diensten hebt is de kans kleiner dat klanten last ergens van hebben maar het kan nog steeds voorkomen."
heb je needs-restarting voor.
"En waar je je heel erg kan iriteren aan Microsoft die functies eruit gooit of introduceert heb je dit ook nog steeds Bij Linux OS vendors."
tja dan gebruik toch echt iets anders dan RHEL/CentOS/Rocky/Alma.
Het gaat niet om het niet weten wat wel en niet een herstart nodig heeft we weten dat dondersgoed voor we ooit op update klikken. Het is dan al een test proces doorlopen inclusief een berekening hoe lang ongeveer alle updates duren.heb je needs-restarting voor.
"En waar je je heel erg kan iriteren aan Microsoft die functies eruit gooit of introduceert heb je dit ook nog steeds Bij Linux OS vendors."
tja dan gebruik toch echt iets anders dan RHEL/CentOS/Rocky/Alma.
Het gaat erom dat sommige mensen denken dat je niet het systeem hoeft te herstarten voor updates bij Linux gebaseerde systemen zoals bij Windows het geval is. Dat is niet het eerlijke verhaal het ligt eraan wat voor update het is.
Het is verder zeer knap dat je kan afleiden dat wij geen bovenstaande genoemde systemen gebruiken, zonder dat je een netwerk scan hebt gedaan.
Ik neem aan dat ik niet in alle details het Redhat CentOS overname en downstream upstream debakel hoef te vertellen De snellere EOL van de 8 serie waardoor veel sneller geschakeld moest worden en de absolute hell die het was om 7 naar Alma of Rocky 8 te krijgen in de eerste half tot jaar van de aankondiging.
En ja we gebruiken RHEL, CentOS en Alma met DA of WHM/cPanel als bovenop draaiend afhankelijk van het cluster.
Ik zou het niet willen ruilen voor Windows servers maar probleem loos kunnen we het ook niet noemen.
Hier een voorbeeldje waar we al kleine 4 maand bezig mee zijn.
https://forums.cpanel.net/threads/102-edge-version-new-whm-theme.696921/
Zoals aangegeven zullen de ervaringen van een ieder verschillen en ik ben blij dat jullie omgeving blijkbaar minder strubbeling heeft dan sommige maar laten we niet doen alsof met RHEL based systemen alle zorgen weg zijn. Als je iemand wil overtuigen systemen te gebruiken kom dan met pro, cons anders verkoop je een sprookje waar zo doorheen geprikt wordt en kan je beter je beroep zoeken in sales, marketing.
Als je de nadelen, kanttekeningen niet kan benoemen dan heb je niet genoeg ervaring met het systeem opgebouwd en als je de nadelen en kantekeningen expres niet wil benoemen om wat voor reden dan ook dan is je advies incompleet.
Aannames maken is om problemen vragen.
@ Ramlatel,
Hoe willen ze dat dan gaan doen voor de brakke infrastructuur op gelikte websites, die voor goed geld zijn ontworpen (zo'n 6000 euro gemiddeld) en later geen onderhoud/updates krijgen. Veel voorbeelden van kwetsbare Word Press, Magento CMS e.d.
Veel verlaten code, bijvoorbeeld af te voeren javascript bibliotheken. Veel ondeugdelijke of verkeerd geconfigureerde CSP,
security header configuraties, plus allerlei voor hackers gevaarlijke info-proliferatie (bijvoorbeeld over de achterliggende server software) en hosters, die het niet uitmaakt waaraan ze verdienen. Ik doe iets dergelijks voor een forum, zogenaamde 3rd party cold reconnaisance website beveiliging en foutenjagen, dit als erom gevraagd wordt en heb in de afgelopen 14 jaar al zoveel broddel- en ronduit gevaarlijke website-code voorbij zien komen alsmede beginners-configuratie-fouten. Dat wil je liever niet geloven, maar het is erg, heel erg, m'n beste Ramlatel. Soms schrik je van wat je ziet in de developer's console.
luntrus
Hoe willen ze dat dan gaan doen voor de brakke infrastructuur op gelikte websites, die voor goed geld zijn ontworpen (zo'n 6000 euro gemiddeld) en later geen onderhoud/updates krijgen. Veel voorbeelden van kwetsbare Word Press, Magento CMS e.d.
Veel verlaten code, bijvoorbeeld af te voeren javascript bibliotheken. Veel ondeugdelijke of verkeerd geconfigureerde CSP,
security header configuraties, plus allerlei voor hackers gevaarlijke info-proliferatie (bijvoorbeeld over de achterliggende server software) en hosters, die het niet uitmaakt waaraan ze verdienen. Ik doe iets dergelijks voor een forum, zogenaamde 3rd party cold reconnaisance website beveiliging en foutenjagen, dit als erom gevraagd wordt en heb in de afgelopen 14 jaar al zoveel broddel- en ronduit gevaarlijke website-code voorbij zien komen alsmede beginners-configuratie-fouten. Dat wil je liever niet geloven, maar het is erg, heel erg, m'n beste Ramlatel. Soms schrik je van wat je ziet in de developer's console.
luntrus
Door Anoniem:
Jazeker wel. 95%!! . Windows trekt ransomware aan als een magneet zeggen ze: https://www.windowscentral.com/windows-ransomware-magnet-according-new-virustotal-reportDoor gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Behalve dan dat 9 op 10 datalekken en kwetsbaarheden niks met Windows van doen hebben en al helemaal niet met het OS zelf. Was het maar waar dan was ons werk een stuk makkelijker.Probleem opgelost.
Door Anoniem:
Ik heb het niet over ransomware ik heb het over datalekken en kwetsbaarhedenDoor Anoniem:
Jazeker wel. 95%!! . Windows trekt ransomware aan als een magneet zeggen ze: https://www.windowscentral.com/windows-ransomware-magnet-according-new-virustotal-reportDoor gradje71: Het is heel simpel, maar ze willen het niet horen: Gooi Windows eruit.
Probleem opgelost.
Behalve dan dat 9 op 10 datalekken en kwetsbaarheden niks met Windows van doen hebben en al helemaal niet met het OS zelf. Was het maar waar dan was ons werk een stuk makkelijker.Probleem opgelost.
Daar zit een heel groot verschil in je noemt nu een specifieke vector die in grotere mate bij Windows voorkomt.
Maar als we het hebben over datalekken dan hebben we het vaakst over toegang tot een versleutelde database.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
