De zeven doodzonden van systeembeheerders
Systeembeheerders spelen een belangrijke rol bij het voorkomen van aanvallen op hun organisatie. Geregeld komen er echter aanvallen in het nieuws waarbij er bijvoorbeeld kwetsbaarheden zijn gebruikt om het bedrijfsnetwerk te infiltreren waarvoor al jarenlang updates beschikbaar waren.
De beveiligingsupdates waren echter niet geïnstalleerd, zodat werknemers door het openen van een document of bezoeken van een website besmet raakten. Het gaat dan om oude kwetsbaarheden in bijvoorbeeld Microsoft Office en Java die regelmatig het doelwit zijn. Onder andere van gerichte spionageaanvallen. Iets waar onlangs ook de FBI voor waarschuwde. Daarnaast zijn er nog andere zaken die een systeembeheerder op orde moet hebben, of anders loopt de organisatie risico. Reden voor beveiligingsbedrijf GFI Software om een overzicht van de zeven doodzonden van systeembeheerders te maken, waarbij het niet installeren van beveiligingsupdates als eerste wordt genoemd.
De overige doodzonden zijn het gebruik van standaardconfiguraties en wachtwoorden, het werken met adminrechten, het niet documenteren van veranderingen, IP-adressen en licentiesleutels, het niet bekijken van logbestanden, het delen van wachtwoorden en als laatste het vragen van wachtwoorden. Vaak waarschuwen systeembeheerders eindgebruikers voor phishingaanvallen en vertellen dat ze nooit hun wachtwoord moeten delen, om vervolgens zelf aan de gebruiker zjin wachtwoord te vragen als er een probleem is. Eindgebruikers moeten dan ook nooit om hun wachtwoord worden gevraagd, aldus de uitleg van de laatste doodzonde.
Reacties (19)
Ik mis de context van dit artikel een beetje. Wat is de aanleiding. Verder gebrek aan software updates is zo'n beetje issue nr 1.
Het doorvoeren van updates op een live omgeving is helaas een nog grotere doodzonde.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
15-08-2015, 13:19 door
karma4
Voor nummer 1 software updates dat ligt vaak niet aan de systeembeheerder. Hij krijgt geen toestemming daarvoor omdat anders applicaties kunnen omvallen. Daar zit meer achter dan in zijn invloedssfeer zit.
Door Anoniem: Het doorvoeren van updates op een live omgeving is helaas een nog grotere doodzonde.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Veel organisaties in het MKB hebben niet eens een OTAP straat, omdat dat te duur gevonden wordt. Geeft wel aan op welk niveau de maturity van veel bedrijven ligt als het gaat om informatiebeveiliging.Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Door Anoniem: Ik mis de context van dit artikel een beetje. Wat is de aanleiding.
Als dat een vraag is, dan mis ik iets. Verder is de context eenvoudig en duidelijk: Gewoon een blogje van een kompjoetersekjoeritiebedrijf. Dat is voor security.nl genoeg reden er een stukje aan te wijden. Hoe meer stukjes, hoe meer vreugd. Inhoud is verder niet belangrijk. Zie ook: webwereld.Door Anoniem: Het doorvoeren van updates op een live omgeving is helaas een nog grotere doodzonde.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Het punt is, dat ze uiteindelijk helemaal niet worden doorgevoerd zoals keer op keer blijkt.
Ik zie weinig verschillen met de doodzonden van de gemiddelde gebruiker eerlijk gezegd.
Geeft wel aan hoe het werkelijk gesteld is bij veel organisaties.
Geeft wel aan hoe het werkelijk gesteld is bij veel organisaties.
15-08-2015, 14:06 door
johanw
Door karma4: Voor nummer 1 software updates dat ligt vaak niet aan de systeembeheerder. Hij krijgt geen toestemming daarvoor omdat anders applicaties kunnen omvallen. Daar zit meer achter dan in zijn invloedssfeer zit.
Ja, want sommige IT beheerders snappen niet dat ze een ondersteunende rol hebben. Het bedrijf heeft er weinig aan als de systemen goed beveiligd zijn maar de medewerkens er niks mee kunnen omdat bedrijfsapplicaties het niet meer doen. Dat komt dan weer omdat veel programmeurs erg modegevoelig blijken en veel modes van 10 jaar geleden nu niet meer goed voldoen, maar dat is weer een ander verhaal.Lol, veel van de genoemde problemen liggen buiten de invloedssfeer van de individuele IT-er.
Vaak genoeg bepaalt het management dat patches niet of pas veel later geinstalleerd hoeven te worden, terwijl systeem beheerders waarschuwen voor de risico's die dat met zich meebrengt. Managers zijn vaak bereid risico's te accepteren, enkel en alleen om kosten en tijd te besparen. Zonder inhoudelijk zich in de risico's te verdiepen.
Bij het reviewen van logs spelen soortgelijke problemen; vaak wordt er op geen enkele manier rekening gehouden dat dergelijke zaken inderdaad moeten gebeuren, en wordt het werkschema van beheerders zodanig belast met projecten en andere zaken, waardoor ze voor dit soort taken helemaal geen tijd overhouden.
De problemen zijn er, maar de oorzaak en verantwoordelijkheid ligt zeker niet altijd bij de individuele medewerkers, zeker wanneer die geen toestemming krijgen om tijd te besteden aan dit soort essentiele taken, ''door andere prioriteiten''.
Last but not least, soms worden onveilige methodes, zoals het verstrekken van wachtwoorden aan helpdesk medewerkers, voorgeschreven in interne policies en procedures. Waarbij, zeker in grote organisaties, input of kritiek vanuit individuele beheerders of beveiligers op dergelijke problemen, volstrekt worden genegeerd.
Voor de gemiddelde manager zijn policies en procedures heilig. Zelfs als deze mankementen vertonen, en onveilig gedrag voorschrijven.
Vaak genoeg bepaalt het management dat patches niet of pas veel later geinstalleerd hoeven te worden, terwijl systeem beheerders waarschuwen voor de risico's die dat met zich meebrengt. Managers zijn vaak bereid risico's te accepteren, enkel en alleen om kosten en tijd te besparen. Zonder inhoudelijk zich in de risico's te verdiepen.
Bij het reviewen van logs spelen soortgelijke problemen; vaak wordt er op geen enkele manier rekening gehouden dat dergelijke zaken inderdaad moeten gebeuren, en wordt het werkschema van beheerders zodanig belast met projecten en andere zaken, waardoor ze voor dit soort taken helemaal geen tijd overhouden.
De problemen zijn er, maar de oorzaak en verantwoordelijkheid ligt zeker niet altijd bij de individuele medewerkers, zeker wanneer die geen toestemming krijgen om tijd te besteden aan dit soort essentiele taken, ''door andere prioriteiten''.
Last but not least, soms worden onveilige methodes, zoals het verstrekken van wachtwoorden aan helpdesk medewerkers, voorgeschreven in interne policies en procedures. Waarbij, zeker in grote organisaties, input of kritiek vanuit individuele beheerders of beveiligers op dergelijke problemen, volstrekt worden genegeerd.
Voor de gemiddelde manager zijn policies en procedures heilig. Zelfs als deze mankementen vertonen, en onveilig gedrag voorschrijven.
Tussen snel security updates installeren en het garanderen van de continuïteit van de dienstverlening zit een spanningsveld. Echter wil ik hier wel even wat kanttekeningen bij plaatsen:
1. Er zijn ook grote risico's aan het niet uitrollen van beveiligingsupdates voor lekken die remote exploitabel zijn
2. De meeste bedrijven hebben niet zodanige testsuites dat ze daadwerkelijk de compatibiliteit kunnen testen
3. Door goede segmentatie van je applicaties kun je probleemgevallen isoleren
4. De meeste systemen zijn niet zo kritisch dat de risico's van uitval of niet correct functioneren onacceptabel zijn
Ik heb zelf al jaren geleden het wekelijks toepassen van security updates ingevoerd bij het bedrijf waar ik toen werkte, we hebben welgeteld 1x een enkele patch terug moeten draaien. Door goede monitoring en logging van de systemen en een goede Back-up was dat met minimale downtime gerealiseerd. Het grote voordeel van wekelijks toepassen van updates was dat de individuele wijzigingen klein zijn en je bij problemen gericht kunt zoeken. Daarnaast was updaten hierdoor volledig automatisch en kan de systeembeheerder zich met andere dingen bezighouden.
1. Er zijn ook grote risico's aan het niet uitrollen van beveiligingsupdates voor lekken die remote exploitabel zijn
2. De meeste bedrijven hebben niet zodanige testsuites dat ze daadwerkelijk de compatibiliteit kunnen testen
3. Door goede segmentatie van je applicaties kun je probleemgevallen isoleren
4. De meeste systemen zijn niet zo kritisch dat de risico's van uitval of niet correct functioneren onacceptabel zijn
Ik heb zelf al jaren geleden het wekelijks toepassen van security updates ingevoerd bij het bedrijf waar ik toen werkte, we hebben welgeteld 1x een enkele patch terug moeten draaien. Door goede monitoring en logging van de systemen en een goede Back-up was dat met minimale downtime gerealiseerd. Het grote voordeel van wekelijks toepassen van updates was dat de individuele wijzigingen klein zijn en je bij problemen gericht kunt zoeken. Daarnaast was updaten hierdoor volledig automatisch en kan de systeembeheerder zich met andere dingen bezighouden.
Door Anoniem: Het doorvoeren van updates op een live omgeving is helaas een nog grotere doodzonde.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Kijk en daar gaat het in al uw wijsheid mank.
Heeft u geen back-up systeem wat parallel loopt en bij problemen de zaak overneemt? Zonde, het had zoveel ellende op de wereld kunnen schelen.
Hard- en soft-ware kosten veel geld daar kan je op bezuinigen terwijl het in deze tijd de pijler van een bedrijf is
In de tijd dat u uitgetest bent heeft men u al bij uw vestje. Jan Crimineel heeft tegenwoordig wel veel geld en is sneller dan u.
Vandaar dat men langzaam maar zeker overgaat op updates en upgrades zonder uw medeweten zodat u als trage gebruiker geïsoleerd raakt.
Door Anoniem:
Door Anoniem: Het doorvoeren van updates op een live omgeving is helaas een nog grotere doodzonde.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Veel organisaties in het MKB hebben niet eens een OTAP straat, omdat dat te duur gevonden wordt. Geeft wel aan op welk niveau de maturity van veel bedrijven ligt als het gaat om informatiebeveiliging.Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Nee, geeft aan in welke treurige staat de informatietechnologie verkeert. Het is uiteraard de verantwoording van de systeem
leverancier om te zorgen dat updates geen problemen geven en in uitzonderingsgevallen eenvoudig terug gedraaid kunnen
worden. Als de gebruiker dat allemaal moet testen en valideren ben je wel sneu bezig.
Stel je voor dat als je een reparatie aan je dakgoot wilt laten doen de loodgieter komt met de mededeling dat deze eerst
in een testomgeving moet worden uitgevoerd en pas na goedkeuring van de klant in de echte dakgoot??? Belachelijk.
Paula Januszkiewicz heeft lang geleden al 10 dodelijke zonden bedacht: https://www.youtube.com/watch?v=6VpDEdS_1vw en nummer 1 is nog altijd de "single point of knowledge". Oftewel die collega die op vakantie is en toen ging er iets mis...
Door Anoniem: [Nee, geeft aan in welke treurige staat de informatietechnologie verkeert. Het is uiteraard de verantwoording van de system leverancier om te zorgen dat updates geen problemen geven en in uitzonderingsgevallen eenvoudig terug gedraaid kunnen worden. Als de gebruiker dat allemaal moet testen en valideren ben je wel sneu bezig.
Mooi mooi, ik hoorde 30 jaar geleden al dat de monteur op de stoep vond reparatie omdat de machine had gemeld dat er iets stuk was. Dat was op OS/hardware niveau. Lijkt me dat je er geen probleem mee hebt dat de leverancier dat doorgestuurd krijgt. Je wenst het zelf zodat hij uit eigen initiatief actie gaat ondernemen,
Als ik nu alle reacties over dat Windows 10 data terugstuurd naar de cloud dat zoiets vreselijk is. Dan mis ik het inzicht over telemetry, het zijn twee kanten van de zelfde vraag. Zie Microsoft als de leverancier van je systeem waar updates op komen. Andere leveranciers zetten er andere zaken op.
Nee het lost nog niets op want de "applicaties" komen niet van de zelfde ene leverancier, er ziijn hele kettingen waarbij meerdere leveranciers van elkaar afhankelijk zijn. Je hebt er niets aan als de boel plat ligt en ze staan naar elkaar te wijzen dat het die ander zijn fout is.Niet belachelijk, het is realiteit.
Dat zie je ook met grotere bouwprojecten met vele aannemers. Even een brugdeel inhijsen (Alphen).
16-08-2015, 13:02 door
Mysterio
Door Anoniem:
Een OTAP straat is ook wel heel heftig. Een paar testmachines is al voldoende en dat hoeft echt niet ingrijpend te zijn.Door Anoniem: Het doorvoeren van updates op een live omgeving is helaas een nog grotere doodzonde.
Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Veel organisaties in het MKB hebben niet eens een OTAP straat, omdat dat te duur gevonden wordt. Geeft wel aan op welk niveau de maturity van veel bedrijven ligt als het gaat om informatiebeveiliging.Updates dienen eerst in een OTAP omgeving grondig getest te worden en kunnen dus nooit direct worden doorgevoerd.
Door Mysterio: Een OTAP straat is ook wel heel heftig. Een paar testmachines is al voldoende en dat hoeft echt niet ingrijpend te zijn.
Welke OTAP straat bedoel je?1- Die waar je het OS en network en de hardware mee valideert
2- Die waar je alle tools communicatie (ftp & bussen) en DBMS systemen mee valideert
3- Die waar je business logica en die processing mee opbouwd / valideert.
deze a.u.b. wel met gescheiden externe koppeling en faked testdata van de business data bij OTA
Dan is er ook nog de vraag van interacties tussen verschillende business-onderdelen.
Op zich ben ik met je het eens het hoeft wat hardware (bare-iron) betreft niet te veel machines kosten.
Maar niet ingrijpend?
Door karma4:
1- Die waar je het OS en network en de hardware mee valideert
2- Die waar je alle tools communicatie (ftp & bussen) en DBMS systemen mee valideert
3- Die waar je business logica en die processing mee opbouwd / valideert.
deze a.u.b. wel met gescheiden externe koppeling en faked testdata van de business data bij OTA
Dan is er ook nog de vraag van interacties tussen verschillende business-onderdelen.
Op zich ben ik met je het eens het hoeft wat hardware (bare-iron) betreft niet te veel machines kosten.
Maar niet ingrijpend?
Voor dat laatste heb je medewerking van alle andere afdelingen nodig. Ieder proces moet ook worden uitgevoerd in de OTA. Als je mazzel heb krijg je dat soort medewerking tijdens de voorbereidingen van een grote migratie. En zelfs dan klaagt het management van andere afdelingen over de last die dit veroorzaakt. Voor gewone beheerwerkzaamheden? Vergeet het maar.Door Mysterio: Een OTAP straat is ook wel heel heftig. Een paar testmachines is al voldoende en dat hoeft echt niet ingrijpend te zijn.
Welke OTAP straat bedoel je?1- Die waar je het OS en network en de hardware mee valideert
2- Die waar je alle tools communicatie (ftp & bussen) en DBMS systemen mee valideert
3- Die waar je business logica en die processing mee opbouwd / valideert.
deze a.u.b. wel met gescheiden externe koppeling en faked testdata van de business data bij OTA
Dan is er ook nog de vraag van interacties tussen verschillende business-onderdelen.
Op zich ben ik met je het eens het hoeft wat hardware (bare-iron) betreft niet te veel machines kosten.
Maar niet ingrijpend?
Die updates is makkelijk praten. wat al eerder is aangegeven vooral bij grote organisaties moeten die updates eerst door de ota straat voor deze naar productie kan. Dit omdat metname maatwerk software hier vervelend op kan reageren.
Dat betreft heeft de aanvaller altijd de gunstige factor van de voorsprong.
wel is het een interessante casus af te vragen of bijvoorbeeld elke server in je netwerk daadwerkelijk bijvoorbeeld office of java nodig heeft. dit scheelt in je update cyclus
Dat betreft heeft de aanvaller altijd de gunstige factor van de voorsprong.
wel is het een interessante casus af te vragen of bijvoorbeeld elke server in je netwerk daadwerkelijk bijvoorbeeld office of java nodig heeft. dit scheelt in je update cyclus
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.
