Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Universiteit Maastricht update 5
30-12-2019, 15:44 door RosaMystica, 87 reacties
Het onderwijs aan de UM kan op 6 januari worden hervat. Enkele belangrijke systemen die daarvoor nodig zijn, zijn vanaf 2 januari weer online beschikbaar. Het gaat daarbij met name om informatiesystemen voor studenten rond roostering (alleen inzage), studiematerialen (Blackboard/ELEUM) en het UM Student Portal. Hierbij is wel sprake van beperktere functionaliteit. Studenten zullen bovendien vanaf een externe locatie, dus buiten het UM WiFi netwerk, al hun wachtwoorden moeten wijzigen.
Meer informatie hier:
https://www.maastrichtuniversity.nl/nl/nieuws/update-5-cyberaanval-um
Meer informatie hier:
https://www.maastrichtuniversity.nl/nl/nieuws/update-5-cyberaanval-um
Reacties (87)
Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ze zullen allereerst, net als de Uni in Gothenburg, alle selfdeclared directeurtjes (de professoren) moeten aanpakken. Ik spreek uit ervaring dat elke professor met z'n eigen budget van alles uithaalt op het netwerk en schijt heeft aan de rest.
Dit veroorzaakt lek na lek en kan alleen met een goed IT regime tegengegaan worden.
Gothenburg (ZW) en Regensburg (DL) zijn goede voorbeelden hoe het wél kan.
30-12-2019, 17:51 door
souplost
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ik vrees dat het niet meer dan een restore en reboot is. Op naar het volgende incident.Door souplost:
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ik vrees dat het niet meer dan een restore en reboot is. Op naar het volgende incident.Dat kan toch niet waar zijn, zo dom is niemand. Als er een hack geweest is en op die manier ransomware binnen is gekomen dan hoop ik dat ze weten via welke weg ze binnen gekomen zijn. Dat kan een zwakke Linux machine zijn maar evengoed een applicatie of een Windows machine. Als het een phishing mail geweest is zal het lastiger zijn als niet alle systemen gepatched zijn.
Is een volledig gepatchte Windows 10 computer zonder admin rechten (die vraag zag ik al eerder voorbijkomen van iemand) kwetsbaar of niet?
Door Anoniem:
Ze zullen allereerst, net als de Uni in Gothenburg, alle selfdeclared directeurtjes (de professoren) moeten aanpakken. Ik spreek uit ervaring dat elke professor met z'n eigen budget van alles uithaalt op het netwerk en schijt heeft aan de rest.
Dit veroorzaakt lek na lek en kan alleen met een goed IT regime tegengegaan worden.
Gothenburg (ZW) en Regensburg (DL) zijn goede voorbeelden hoe het wél kan.
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ze zullen allereerst, net als de Uni in Gothenburg, alle selfdeclared directeurtjes (de professoren) moeten aanpakken. Ik spreek uit ervaring dat elke professor met z'n eigen budget van alles uithaalt op het netwerk en schijt heeft aan de rest.
Dit veroorzaakt lek na lek en kan alleen met een goed IT regime tegengegaan worden.
Gothenburg (ZW) en Regensburg (DL) zijn goede voorbeelden hoe het wél kan.
let op, het kan ook andersom. ik zit met een IT partij aan een uni in nl die meer kwaad dan goed doet op het vlak van security en continuiteit van onderwijs en wetenschap. beleid zorgt ervoor dat std [m/h]bo ITers vaak een flinke vinger in de pap hebben vwb de IT van de gehele uni. deze mensen komen met ladingen commerciele certificeringen en zogenaamde best practices die ze blind zonder afwegingen en bedenkingen afdwingen. ze hebben geen ervaringen met MRI of een of andere dure spectrometer van enkele miljoenen maar dwingen wel af dat het OS dat dit soort apperatuur aanstuurt, perse hun specifieke win10 moet zijn en anders gaat het van het net af en kun je met usb stikies heen en weer gaan. het antwoord dat je dan krijgt als het niet werkt is vaak 'dan koop je maar een nieuw MRI / spectrometer'.
de werkelijk oplossingen liggen (in mijn ogen) in de combinaties va monitoring, config mangement, segmentering en vlugge nieuwe uitrollen uit kunnen voeren zodat damage contained minimaal is en de uni in control. ook het OS dat je daarbij gebruikt kan een flinke impact in de risico analyse hebben.
30-12-2019, 19:07 door
The FOSS
Door Sjef van Heesch:
Dat kan toch niet waar zijn, zo dom is niemand. Als er een hack geweest is en op die manier ransomware binnen is gekomen dan hoop ik dat ze weten via welke weg ze binnen gekomen zijn. Dat kan een zwakke Linux machine zijn maar evengoed een applicatie of een Windows machine. Als het een phishing mail geweest is zal het lastiger zijn als niet alle systemen gepatched zijn.
Door souplost:
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ik vrees dat het niet meer dan een restore en reboot is. Op naar het volgende incident.Dat kan toch niet waar zijn, zo dom is niemand. Als er een hack geweest is en op die manier ransomware binnen is gekomen dan hoop ik dat ze weten via welke weg ze binnen gekomen zijn. Dat kan een zwakke Linux machine zijn maar evengoed een applicatie of een Windows machine. Als het een phishing mail geweest is zal het lastiger zijn als niet alle systemen gepatched zijn.
Dat is inderdaad de eerste vraag die men beantwoord moet hebben alvorens een herhaling van dit incident voorkomen kan worden. Er is recent ingebroken dus het zou ook van binnenuit kunnen zijn gebeurd.
https://www.observantonline.nl/Home/Artikelen/articleType/ArticleView/articleId/17487/Harde-schijven-gestolen-bij-inbraak-UNS-60
30-12-2019, 19:07 door
Erik van Straten
Door Sjef van Heesch: Is een volledig gepatchte Windows 10 computer zonder admin rechten (die vraag zag ik al eerder voorbijkomen van iemand) kwetsbaar of niet?
Ja en nee. Er zijn minstens 3 problemen:1) Vanuit een gehacked account kunnen geloofwaardige kwaadaardige e-mails worden verzonden en/of verhulde malware op shares worden geplaatst;
2) Als de user feitelijk wel admin is, maar diens privileges zijn verlaagd, zijn UAC-bypasses een koud kunstje;
3) Ook al is een systeem up-to-date met Windows patches, bij third-party software is dat zelden het geval, waardoor EOP (Elevation of Privilege) aanvallen succesvol kunnen zijn.
Daarnaast kan via het gehackte account al een boel verkenning van de netwerkomgeving plaatsvinden. Eventuele opgeslagen wachtwoorden voor bijv. e-mail accounts van de gebruiker kunnen door de malware worden achterhaald.
De malware probeert zich aanvankelijk "horizontaal" (lateral movement) door het netwerk te verplaatsen, desnoods aanvankelijk met minimale gebruikersprivileges. Vroeger of later wordt daardoor een account gecompromitteerd met hogere privileges, van daaruit slaat de malware dan verder toe.
30-12-2019, 19:12 door
Erik van Straten
Door The FOSS: Dat is inderdaad de eerste vraag die men beantwoord moet hebben alvorens een herhaling van dit incident voorkomen kan worden. Er is recent ingebroken dus het zou ook van binnenuit kunnen zijn gebeurd.
Assume compromise. Als je denkt calamiteiten te kunnen uisluiten door elk incident te voorkomen, wens ik je veel succes. Vooral in een universitaire omgeving met heel veel buitenlanders die de Nederlandse taal niet machtig zijn.
30-12-2019, 21:06 door
The FOSS
Door Erik van Straten:
Door The FOSS: Dat is inderdaad de eerste vraag die men beantwoord moet hebben alvorens een herhaling van dit incident voorkomen kan worden. Er is recent ingebroken dus het zou ook van binnenuit kunnen zijn gebeurd.
Assume compromise. Als je denkt calamiteiten te kunnen uisluiten door elk incident te voorkomen, wens ik je veel succes. Vooral in een universitaire omgeving met heel veel buitenlanders die de Nederlandse taal niet machtig zijn.Alvorens een herhaling van dit incident op deze manier voorkomen kan worden.
Door Erik van Straten:
1) Vanuit een gehacked account kunnen geloofwaardige kwaadaardige e-mails worden verzonden en/of verhulde malware op shares worden geplaatst;
2) Als de user feitelijk wel admin is, maar diens privileges zijn verlaagd, zijn UAC-bypasses een koud kunstje;
3) Ook al is een systeem up-to-date met Windows patches, bij third-party software is dat zelden het geval, waardoor EOP (Elevation of Privilege) aanvallen succesvol kunnen zijn.
Daarnaast kan via het gehackte account al een boel verkenning van de netwerkomgeving plaatsvinden. Eventuele opgeslagen wachtwoorden voor bijv. e-mail accounts van de gebruiker kunnen door de malware worden achterhaald.
De malware probeert zich aanvankelijk "horizontaal" (lateral movement) door het netwerk te verplaatsen, desnoods aanvankelijk met minimale gebruikersprivileges. Vroeger of later wordt daardoor een account gecompromitteerd met hogere privileges, van daaruit slaat de malware dan verder toe.
Door Sjef van Heesch: Is een volledig gepatchte Windows 10 computer zonder admin rechten (die vraag zag ik al eerder voorbijkomen van iemand) kwetsbaar of niet?
Ja en nee. Er zijn minstens 3 problemen:1) Vanuit een gehacked account kunnen geloofwaardige kwaadaardige e-mails worden verzonden en/of verhulde malware op shares worden geplaatst;
2) Als de user feitelijk wel admin is, maar diens privileges zijn verlaagd, zijn UAC-bypasses een koud kunstje;
3) Ook al is een systeem up-to-date met Windows patches, bij third-party software is dat zelden het geval, waardoor EOP (Elevation of Privilege) aanvallen succesvol kunnen zijn.
Daarnaast kan via het gehackte account al een boel verkenning van de netwerkomgeving plaatsvinden. Eventuele opgeslagen wachtwoorden voor bijv. e-mail accounts van de gebruiker kunnen door de malware worden achterhaald.
De malware probeert zich aanvankelijk "horizontaal" (lateral movement) door het netwerk te verplaatsen, desnoods aanvankelijk met minimale gebruikersprivileges. Vroeger of later wordt daardoor een account gecompromitteerd met hogere privileges, van daaruit slaat de malware dan verder toe.
1) Snap ik maar kan je als niet administrator door op zo'n link te klikken heel je Windows 10 PC encrypten?
2) Daarvoor weet ik te weinig van Windows, je bent eigenlijk admin maar door verlaagde rechten toch weer niet?
Dat is wel een vreemd mechanisme mits ik het goed begrepen heb.
3) Die third party software moet dan toch wel als administrator draaien en een lek hebben wat te misbruiken is?
30-12-2019, 23:43 door
Erik van Straten
Door Sjef van Heesch: 1) Snap ik maar kan je als niet administrator door op zo'n link te klikken heel je Windows 10 PC encrypten?
Nee, maar het laatste dat de criminelen willen is dat jouw PC niet meer werkt! Ze moeten je immers de boodschap kunnen laten zien dat jouw bestanden versleuteld zijn, en er moet een OS draaien om jouw bestanden te kunnen herstellen (anders vangen ze nooit geld). Dus meestal beperkt ransomware zich tot het versleutelen van foto's, Office files, zip-files, e-mails en dergelijke (en maakt back-ups en restore-points onbruikbaar).Sterker, sinds kort is er een versie van de Ryuk ransomware die door WSL (Linux subsysteem onder Windows) gebruikte directories ontziet (zie [1], overigens gemeld door Vitali Kremez, dezelfde analyst die vermoedt dat Russen achter de Clop ransomware zitten).
Maar wat ik zojuist beschreef geldt voor ransomware gericht op individuen, en dat is zooo 2018; de nieuwe targets zijn organisaties en het primaire doel daarbij is het, via maakt-niet-uit hoeveel omwegen, verkrijgen van domain admin rechten (malware zoals Emotet wordt daarvoor gebruikt). Dan kunnen de criminelen de feitelijke ransomware pushen naar elke server en elk werkstation, en gelijktijdig opstarten.
Door Sjef van Heesch: 2) Daarvoor weet ik te weinig van Windows, je bent eigenlijk admin maar door verlaagde rechten toch weer niet?
Exact. Als je Windows zelf installeert is "jouw" account (het eerste dat wordt aangemaakt), automatisch lid van de groep Administrators. Elke keer als je inlogt, worden (voordat je iets kunt doen) jouw privileges beperkt. Je kunt dit zien door in een command prompt te starten: whoami /priv (meer info: [2], bron: [3]). Zodra je iets doet dat meer privileges vereist, krijg je (standaard, met de UAC-slider op positie 3 van 4, slechts in een deel van de gevallen) een UAC melding (UAC = User Account Control). Echter, Microsoft stelt dat UAC geen security boundary vormt, maar slechts bedoeld is om (al dan niet domme) gebruikersfouten te voorkomen, zoals het per ongeluk wissen van Windows- of programmabestanden.Als ik voor mezelf of voor een ander Windows op een privé-PC installeer, noem ik het account dat tijdens de installatie gemaakt wordt AdminErik of zo. Zodra Windows operationeel is, maak ik een nieuw account voor dagelijks gebruik dat lid is van de groep Users (en niet van Administrators). Als je met zo'n account een UAC-prompt krijgt, moet je een adminwachtwoord invoeren. Veiliger (maar omslachtiger en tijdrovender) is natuurlijk account-switchen.
Door Sjef van Heesch: 3) Die third party software moet dan toch wel als administrator draaien en een lek hebben wat te misbruiken is?
Inderdaad. Notabene virusscanners en andere beveiligingssoftware zijn er berucht om dat er regelmatig privilege escalation lekken in worden gevonden. Ik herinner me nog de tijd dat McAfee al haar registry entries en notabene een low-level system driver de rechten eveyone:full control gaf. Kaspersky zette haar private key passende bij het CA rootcertificaat voor SSL/TLS inspectie onversleuteld in een map die door iedereen met een account op de PC gelezen kon worden. Veel van dit soort software blijkt kwetsbaar voor "binary planting" doordat ze DLL's niet met absolute paden laden, en ga zo maar door. Als er nog resten van ondertussen door een ander product vervangen software draaien, is de kans groot dat die oude software niet meer geüpdated wordt.Een aanvaller heeft maar één gat nodig, dus zul jij ze allemaal moeten dichten - een in de praktijk vaak onmogelijke opgave. En voor aanvallers liggen de tools (vaak geschreven door pentesters) voor het oprapen. Het gebruik van dat soort tools om je eigen systeem te inspecteren is helaas nog ongebruikelijk, en een tool die alles afdekt, ken ik niet.
Computers met hun vaak gigabytes aan software en de vele draaiende services zijn zeer complex geworden, en daarbij knipperen harddisk/netwerk ledjes dat het een lieve lust is, waardoor ook specialisten niet snel uitsluitsel kunnen geven of een systeem (of slechts een account daarop) gecompromitteerd is of niet. Virusscanners zijn kansloos bij verse malware (die pas wordt "verscheept" als deze zodanig getuned is dat de meeste virusscanners de malware niet detecteren; bijvoorbeeld het in [3] genoemde kwaadaardige powershell script om UAC te bypassen wordt momenteel door 4 van 58 scanners gedetecteerd, zie [4]). Symptomen waar je op kunt letten zijn virusscanners die niet meer worden bijgewerkt, maar houd er rekening mee dat krachtige malware jou kan laten zien wat de criminelen willen dat jij ziet.
Vandaar het pleidooi van steeds meer security-specialisten om niet meer van een "trusted network" uit te gaan, maar juist dat er zich gecompromitteerde devices in dat netwerk kunnen bevinden. De kunst is dan wel om die infectiebronnen zo snel mogelijk te detecteren (inlogpogingen op onverwachte servers vanaf die PC, draaien van tools als Responder, ARP-attacks en andere anomalies), te isoleren en "in bad" te doen. Daarnaast moet je er voor zorgen dat op geen enkel device hergebruikte beheerwachtwoorden of hashes daarvan te vinden zijn (gebruik dus iets als Microsoft LAPS).
[1] https://www.bleepingcomputer.com/news/security/ryuk-ransomware-stops-encrypting-linux-folders/
[2] https://www.who-ami.net/how-to-bypass-uac-in-newer-windows-versions/
[3] https://isc.sans.edu/forums/diary/Bypassing+UAC+to+Install+a+Cryptominer/25644/
[4] https://www.virustotal.com/gui/file/c5ec59f873fe31025703855a2406845199d2da221738d3c76daa3b9996c6cd14/detection
Door Erik van Straten: Assume compromise. Als je denkt calamiteiten te kunnen uitsluiten door elk incident te voorkomen, wens ik je veel succes. Vooral in een universitaire omgeving met heel veel buitenlanders die de Nederlandse taal niet machtig zijn.
De website van de Universiteit Maastricht is tweetalig. Men hoort in de wandelgangen dagelijks zo'n zeven wereldtalen, dus laten we hopen dat de onderwijzende staf, medewerkers en de studenten goed Engels kunnen lezen:
IMPORTANT! Don’t use the systems!
It is of the utmost importance at this moment that students and staff do not perform any actions on UM computers or systems. This applies to both inside and outside the university. This is to avoid any risk for research and repair work and for data retention.
It is of the utmost importance at this moment that students and staff do not perform any actions on UM computers or systems. This applies to both inside and outside the university. This is to avoid any risk for research and repair work and for data retention.
https://www.maastrichtuniversity.nl/news/update-5-um-cyber-attack
Door The FOSS:
Dat is inderdaad de eerste vraag die men beantwoord moet hebben alvorens een herhaling van dit incident voorkomen kan worden. Er is recent ingebroken dus het zou ook van binnenuit kunnen zijn gebeurd.
https://www.observantonline.nl/Home/Artikelen/articleType/ArticleView/articleId/17487/Harde-schijven-gestolen-bij-inbraak-UNS-60
Door Sjef van Heesch:
Dat kan toch niet waar zijn, zo dom is niemand. Als er een hack geweest is en op die manier ransomware binnen is gekomen dan hoop ik dat ze weten via welke weg ze binnen gekomen zijn. Dat kan een zwakke Linux machine zijn maar evengoed een applicatie of een Windows machine. Als het een phishing mail geweest is zal het lastiger zijn als niet alle systemen gepatched zijn.
Door souplost:
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ik vrees dat het niet meer dan een restore en reboot is. Op naar het volgende incident.Dat kan toch niet waar zijn, zo dom is niemand. Als er een hack geweest is en op die manier ransomware binnen is gekomen dan hoop ik dat ze weten via welke weg ze binnen gekomen zijn. Dat kan een zwakke Linux machine zijn maar evengoed een applicatie of een Windows machine. Als het een phishing mail geweest is zal het lastiger zijn als niet alle systemen gepatched zijn.
Dat is inderdaad de eerste vraag die men beantwoord moet hebben alvorens een herhaling van dit incident voorkomen kan worden. Er is recent ingebroken dus het zou ook van binnenuit kunnen zijn gebeurd.
https://www.observantonline.nl/Home/Artikelen/articleType/ArticleView/articleId/17487/Harde-schijven-gestolen-bij-inbraak-UNS-60
Door Anoniem:
let op, het kan ook andersom. ik zit met een IT partij aan een uni in nl die meer kwaad dan goed doet op het vlak van security en continuiteit van onderwijs en wetenschap. beleid zorgt ervoor dat std [m/h]bo ITers vaak een flinke vinger in de pap hebben vwb de IT van de gehele uni. deze mensen komen met ladingen commerciele certificeringen en zogenaamde best practices die ze blind zonder afwegingen en bedenkingen afdwingen. ze hebben geen ervaringen met MRI of een of andere dure spectrometer van enkele miljoenen maar dwingen wel af dat het OS dat dit soort apperatuur aanstuurt, perse hun specifieke win10 moet zijn en anders gaat het van het net af en kun je met usb stikies heen en weer gaan. het antwoord dat je dan krijgt als het niet werkt is vaak 'dan koop je maar een nieuw MRI / spectrometer'.
de werkelijk oplossingen liggen (in mijn ogen) in de combinaties va monitoring, config mangement, segmentering en vlugge nieuwe uitrollen uit kunnen voeren zodat damage contained minimaal is en de uni in control. ook het OS dat je daarbij gebruikt kan een flinke impact in de risico analyse hebben.
Door Anoniem:
Ze zullen allereerst, net als de Uni in Gothenburg, alle selfdeclared directeurtjes (de professoren) moeten aanpakken. Ik spreek uit ervaring dat elke professor met z'n eigen budget van alles uithaalt op het netwerk en schijt heeft aan de rest.
Dit veroorzaakt lek na lek en kan alleen met een goed IT regime tegengegaan worden.
Gothenburg (ZW) en Regensburg (DL) zijn goede voorbeelden hoe het wél kan.
Door Sjef van Heesch: Ik ben zo benieuwd wat er aan maatregelen genomen is om herhaling te voorkomen.
Ze zullen allereerst, net als de Uni in Gothenburg, alle selfdeclared directeurtjes (de professoren) moeten aanpakken. Ik spreek uit ervaring dat elke professor met z'n eigen budget van alles uithaalt op het netwerk en schijt heeft aan de rest.
Dit veroorzaakt lek na lek en kan alleen met een goed IT regime tegengegaan worden.
Gothenburg (ZW) en Regensburg (DL) zijn goede voorbeelden hoe het wél kan.
let op, het kan ook andersom. ik zit met een IT partij aan een uni in nl die meer kwaad dan goed doet op het vlak van security en continuiteit van onderwijs en wetenschap. beleid zorgt ervoor dat std [m/h]bo ITers vaak een flinke vinger in de pap hebben vwb de IT van de gehele uni. deze mensen komen met ladingen commerciele certificeringen en zogenaamde best practices die ze blind zonder afwegingen en bedenkingen afdwingen. ze hebben geen ervaringen met MRI of een of andere dure spectrometer van enkele miljoenen maar dwingen wel af dat het OS dat dit soort apperatuur aanstuurt, perse hun specifieke win10 moet zijn en anders gaat het van het net af en kun je met usb stikies heen en weer gaan. het antwoord dat je dan krijgt als het niet werkt is vaak 'dan koop je maar een nieuw MRI / spectrometer'.
de werkelijk oplossingen liggen (in mijn ogen) in de combinaties va monitoring, config mangement, segmentering en vlugge nieuwe uitrollen uit kunnen voeren zodat damage contained minimaal is en de uni in control. ook het OS dat je daarbij gebruikt kan een flinke impact in de risico analyse hebben.
Bij Gothenburg en Regensburg zijn de bestaande losse IT eilandjes allemaal samengevoegd en in een samenhangende IT organisatie gestopt, zonder verlies van kennis *en affiniteit*. Vanuit de bestaande pool werd een nieuwe organisatie gevormd met gedegen kennis van het netwerk zonder de daadwerkelijke knelpunten uit het oog te verliezen.
"Ik moet een nieuwe Wifi hotspot want ik wil met mijn telefoon de MRI scans kunnen zien" wordt vertaald naar een werkbare oplossing, zonder security én werkbaarheid uit het oog te verliezen.
Als je een 3e partij zoals ATOS loslaat op je organisatie wordt je management zand in de ogen gestrooid, ga je vér over budget én haal je je doelen niet. Neem een goede manager in dienst die z'n baan verliest als ie niet presteert.
DAT is wat die 2 UNI's zo uniek maakt. En dat kost een hoop inzet, tot aan het bevriezen van de budgetten van die professoren totdat ze gaan meedenken. Maar dus wel met een organisatie erachter die meedenkt en snapt wat er speelt.
Volgens onze Limburger (Dagblad de Limburg) was het Ze Russianz.
https://www.limburger.nl/cnt/dmf20191230_00139034/onderwijs-universiteit-maastricht-ondanks-hack-maandag-weer-van-start
Het computersysteem van de UM is vlak voor kerst gehackt, volgens de New Yorkse cyberexpert Vitali Kremez waarschijnlijk door Russische criminelen die opereren onder de naam TA505. Het systeem is geïnfecteerd met de gijzelsoftware Clop, die via phishingmails het Maastrichtse netwerk is binnengedrongen en zich vervolgens door het systeem heeft verspreid.
Iemand zei al zoiets op security.nl vorige week (ook uit Limburg? ;-) maar de post verdween heel gauw. En voila opeens staat het in de krant. Ik las het bij tante Mien met een stuk vlaai. Ik lees haar altijd de krant voor want ze kan slecht lezen met haar linkeroog blind.
Lees ook: Spoor cyberhack Universiteit Maastricht leidt naar Rusland
https://www.limburger.nl/cnt/dmf20191229_00138968/spoor-cyberhack-universiteit-maastricht-leidt-naar-rusland
De cyberhack die de Universiteit Maastricht (UM) nog altijd in de greep houdt, is vrijwel zeker het werk van Russische criminelen, bekend onder de naam TA505.
https://www.limburger.nl/cnt/dmf20191230_00139034/onderwijs-universiteit-maastricht-ondanks-hack-maandag-weer-van-start
Het computersysteem van de UM is vlak voor kerst gehackt, volgens de New Yorkse cyberexpert Vitali Kremez waarschijnlijk door Russische criminelen die opereren onder de naam TA505. Het systeem is geïnfecteerd met de gijzelsoftware Clop, die via phishingmails het Maastrichtse netwerk is binnengedrongen en zich vervolgens door het systeem heeft verspreid.
Iemand zei al zoiets op security.nl vorige week (ook uit Limburg? ;-) maar de post verdween heel gauw. En voila opeens staat het in de krant. Ik las het bij tante Mien met een stuk vlaai. Ik lees haar altijd de krant voor want ze kan slecht lezen met haar linkeroog blind.
Lees ook: Spoor cyberhack Universiteit Maastricht leidt naar Rusland
https://www.limburger.nl/cnt/dmf20191229_00138968/spoor-cyberhack-universiteit-maastricht-leidt-naar-rusland
De cyberhack die de Universiteit Maastricht (UM) nog altijd in de greep houdt, is vrijwel zeker het werk van Russische criminelen, bekend onder de naam TA505.
Door Erik van Straten:
Sterker, sinds kort is er een versie van de Ryuk ransomware die door WSL (Linux subsysteem onder Windows) gebruikte directories ontziet (zie [1], overigens gemeld door Vitali Kremez, dezelfde analyst die vermoedt dat Russen achter de Clop ransomware zitten).
Maar wat ik zojuist beschreef geldt voor ransomware gericht op individuen, en dat is zooo 2018; de nieuwe targets zijn organisaties en het primaire doel daarbij is het, via maakt-niet-uit hoeveel omwegen, verkrijgen van domain admin rechten (malware zoals Emotet wordt daarvoor gebruikt). Dan kunnen de criminelen de feitelijke ransomware pushen naar elke server en elk werkstation, en gelijktijdig opstarten.
Als ik voor mezelf of voor een ander Windows op een privé-PC installeer, noem ik het account dat tijdens de installatie gemaakt wordt AdminErik of zo. Zodra Windows operationeel is, maak ik een nieuw account voor dagelijks gebruik dat lid is van de groep Users (en niet van Administrators). Als je met zo'n account een UAC-prompt krijgt, moet je een adminwachtwoord invoeren. Veiliger (maar omslachtiger en tijdrovender) is natuurlijk account-switchen.
Een aanvaller heeft maar één gat nodig, dus zul jij ze allemaal moeten dichten - een in de praktijk vaak onmogelijke opgave. En voor aanvallers liggen de tools (vaak geschreven door pentesters) voor het oprapen. Het gebruik van dat soort tools om je eigen systeem te inspecteren is helaas nog ongebruikelijk, en een tool die alles afdekt, ken ik niet.
Computers met hun vaak gigabytes aan software en de vele draaiende services zijn zeer complex geworden, en daarbij knipperen harddisk/netwerk ledjes dat het een lieve lust is, waardoor ook specialisten niet snel uitsluitsel kunnen geven of een systeem (of slechts een account daarop) gecompromitteerd is of niet. Virusscanners zijn kansloos bij verse malware (die pas wordt "verscheept" als deze zodanig getuned is dat de meeste virusscanners de malware niet detecteren; bijvoorbeeld het in [3] genoemde kwaadaardige powershell script om UAC te bypassen wordt momenteel door 4 van 58 scanners gedetecteerd, zie [4]). Symptomen waar je op kunt letten zijn virusscanners die niet meer worden bijgewerkt, maar houd er rekening mee dat krachtige malware jou kan laten zien wat de criminelen willen dat jij ziet.
Vandaar het pleidooi van steeds meer security-specialisten om niet meer van een "trusted network" uit te gaan, maar juist dat er zich gecompromitteerde devices in dat netwerk kunnen bevinden. De kunst is dan wel om die infectiebronnen zo snel mogelijk te detecteren (inlogpogingen op onverwachte servers vanaf die PC, draaien van tools als Responder, ARP-attacks en andere anomalies), te isoleren en "in bad" te doen. Daarnaast moet je er voor zorgen dat op geen enkel device hergebruikte beheerwachtwoorden of hashes daarvan te vinden zijn (gebruik dus iets als Microsoft LAPS).
[1] https://www.bleepingcomputer.com/news/security/ryuk-ransomware-stops-encrypting-linux-folders/
[2] https://www.who-ami.net/how-to-bypass-uac-in-newer-windows-versions/
[3] https://isc.sans.edu/forums/diary/Bypassing+UAC+to+Install+a+Cryptominer/25644/
[4] https://www.virustotal.com/gui/file/c5ec59f873fe31025703855a2406845199d2da221738d3c76daa3b9996c6cd14/detection
bedankt voor de duidelijke uileg nu snap ik het een beetje.groetjes dibbieDoor Sjef van Heesch: 1) Snap ik maar kan je als niet administrator door op zo'n link te klikken heel je Windows 10 PC encrypten?
Nee, maar het laatste dat de criminelen willen is dat jouw PC niet meer werkt! Ze moeten je immers de boodschap kunnen laten zien dat jouw bestanden versleuteld zijn, en er moet een OS draaien om jouw bestanden te kunnen herstellen (anders vangen ze nooit geld). Dus meestal beperkt ransomware zich tot het versleutelen van foto's, Office files, zip-files, e-mails en dergelijke (en maakt back-ups en restore-points onbruikbaar).Sterker, sinds kort is er een versie van de Ryuk ransomware die door WSL (Linux subsysteem onder Windows) gebruikte directories ontziet (zie [1], overigens gemeld door Vitali Kremez, dezelfde analyst die vermoedt dat Russen achter de Clop ransomware zitten).
Maar wat ik zojuist beschreef geldt voor ransomware gericht op individuen, en dat is zooo 2018; de nieuwe targets zijn organisaties en het primaire doel daarbij is het, via maakt-niet-uit hoeveel omwegen, verkrijgen van domain admin rechten (malware zoals Emotet wordt daarvoor gebruikt). Dan kunnen de criminelen de feitelijke ransomware pushen naar elke server en elk werkstation, en gelijktijdig opstarten.
Door Sjef van Heesch: 2) Daarvoor weet ik te weinig van Windows, je bent eigenlijk admin maar door verlaagde rechten toch weer niet?
Exact. Als je Windows zelf installeert is "jouw" account (het eerste dat wordt aangemaakt), automatisch lid van de groep Administrators. Elke keer als je inlogt, worden (voordat je iets kunt doen) jouw privileges beperkt. Je kunt dit zien door in een command prompt te starten: whoami /priv (meer info: [2], bron: [3]). Zodra je iets doet dat meer privileges vereist, krijg je (standaard, met de UAC-slider op positie 3 van 4, slechts in een deel van de gevallen) een UAC melding (UAC = User Account Control). Echter, Microsoft stelt dat UAC geen security boundary vormt, maar slechts bedoeld is om (al dan niet domme) gebruikersfouten te voorkomen, zoals het per ongeluk wissen van Windows- of programmabestanden.Als ik voor mezelf of voor een ander Windows op een privé-PC installeer, noem ik het account dat tijdens de installatie gemaakt wordt AdminErik of zo. Zodra Windows operationeel is, maak ik een nieuw account voor dagelijks gebruik dat lid is van de groep Users (en niet van Administrators). Als je met zo'n account een UAC-prompt krijgt, moet je een adminwachtwoord invoeren. Veiliger (maar omslachtiger en tijdrovender) is natuurlijk account-switchen.
Door Sjef van Heesch: 3) Die third party software moet dan toch wel als administrator draaien en een lek hebben wat te misbruiken is?
Inderdaad. Notabene virusscanners en andere beveiligingssoftware zijn er berucht om dat er regelmatig privilege escalation lekken in worden gevonden. Ik herinner me nog de tijd dat McAfee al haar registry entries en notabene een low-level system driver de rechten eveyone:full control gaf. Kaspersky zette haar private key passende bij het CA rootcertificaat voor SSL/TLS inspectie onversleuteld in een map die door iedereen met een account op de PC gelezen kon worden. Veel van dit soort software blijkt kwetsbaar voor "binary planting" doordat ze DLL's niet met absolute paden laden, en ga zo maar door. Als er nog resten van ondertussen door een ander product vervangen software draaien, is de kans groot dat die oude software niet meer geüpdated wordt.Een aanvaller heeft maar één gat nodig, dus zul jij ze allemaal moeten dichten - een in de praktijk vaak onmogelijke opgave. En voor aanvallers liggen de tools (vaak geschreven door pentesters) voor het oprapen. Het gebruik van dat soort tools om je eigen systeem te inspecteren is helaas nog ongebruikelijk, en een tool die alles afdekt, ken ik niet.
Computers met hun vaak gigabytes aan software en de vele draaiende services zijn zeer complex geworden, en daarbij knipperen harddisk/netwerk ledjes dat het een lieve lust is, waardoor ook specialisten niet snel uitsluitsel kunnen geven of een systeem (of slechts een account daarop) gecompromitteerd is of niet. Virusscanners zijn kansloos bij verse malware (die pas wordt "verscheept" als deze zodanig getuned is dat de meeste virusscanners de malware niet detecteren; bijvoorbeeld het in [3] genoemde kwaadaardige powershell script om UAC te bypassen wordt momenteel door 4 van 58 scanners gedetecteerd, zie [4]). Symptomen waar je op kunt letten zijn virusscanners die niet meer worden bijgewerkt, maar houd er rekening mee dat krachtige malware jou kan laten zien wat de criminelen willen dat jij ziet.
Vandaar het pleidooi van steeds meer security-specialisten om niet meer van een "trusted network" uit te gaan, maar juist dat er zich gecompromitteerde devices in dat netwerk kunnen bevinden. De kunst is dan wel om die infectiebronnen zo snel mogelijk te detecteren (inlogpogingen op onverwachte servers vanaf die PC, draaien van tools als Responder, ARP-attacks en andere anomalies), te isoleren en "in bad" te doen. Daarnaast moet je er voor zorgen dat op geen enkel device hergebruikte beheerwachtwoorden of hashes daarvan te vinden zijn (gebruik dus iets als Microsoft LAPS).
[1] https://www.bleepingcomputer.com/news/security/ryuk-ransomware-stops-encrypting-linux-folders/
[2] https://www.who-ami.net/how-to-bypass-uac-in-newer-windows-versions/
[3] https://isc.sans.edu/forums/diary/Bypassing+UAC+to+Install+a+Cryptominer/25644/
[4] https://www.virustotal.com/gui/file/c5ec59f873fe31025703855a2406845199d2da221738d3c76daa3b9996c6cd14/detection
Geen Local Admin beperkt alleen de schade op je Windows systeem, maar voorkomt Ransomware activatie niet.
Ransomware heeft dezelfde rechten als de gebruiker die het activeert.
Dus kan jij bij jouw bestanden, dan kan de Ransomware dit ook, geldt dus tevens voor netwerk locaties.
Er zijn ingebouwde features in Windows die Ransomware nog verder kunnen beperken, zoals Microsoft Applocker (whitelisten van applicaties).
Applocker alleen is niet voldoende, maar bv. in combinatie met geen Local Admin maakt het al stuk sterker.
Scripts/EXE's kunnen niet meer op alle locaties starten, behalve waar jij dit configureert.
Ransomware heeft dezelfde rechten als de gebruiker die het activeert.
Dus kan jij bij jouw bestanden, dan kan de Ransomware dit ook, geldt dus tevens voor netwerk locaties.
Er zijn ingebouwde features in Windows die Ransomware nog verder kunnen beperken, zoals Microsoft Applocker (whitelisten van applicaties).
Applocker alleen is niet voldoende, maar bv. in combinatie met geen Local Admin maakt het al stuk sterker.
Scripts/EXE's kunnen niet meer op alle locaties starten, behalve waar jij dit configureert.
@Erik van Straten
Bedankt voor deze uitgebreide uitleg, zeer helder.
Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
Bedankt voor deze uitgebreide uitleg, zeer helder.
Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
31-12-2019, 10:15 door
The FOSS
Door Sjef van Heesch: Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
Inderdaad. Maar er hoort natuurlijk een groot verschil te zijn tussen het versleuteld worden van de bestanden waar jouw account bij kan (vandaar een apart user restricted account), op je eigen computer en het versleuteld worden van alle bestanden voor alle gebruikers in een netwerk.
31-12-2019, 10:24 door
DLans
Door Sjef van Heesch: @Erik van Straten
Bedankt voor deze uitgebreide uitleg, zeer helder.
Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
Bedankt voor deze uitgebreide uitleg, zeer helder.
Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
Daarom ben ik fan van bijvoorbeeld Palo Alto Traps. Een applicatie die weinig updates vereist, maar middels behavioral security kijkt naar wat een applicatie doet. Wij draaide Traps bij mijn vorige werkgever i.c.m. een reguliere antivirus, en dat werkte voor ons uitstekend. Dan nog hebben we een keer een ransomware infectie gehad (onduidelijk waarom beide oplossingen niet ingrepen), maar de schade was beperkt tot wat mappen op een netwerklocatie. De users zijn immers géén admins en de malware kan op de lokale systemen absoluut geen domain admin credentials vinden ;-) Dus PC gewoon vernietigd onder de pers (ja echt ^^) en een backup voor de getroffen mappen teruggezet.
Maar de zwakste schakel blijft toch echt de mens. We hebben een nep email verstuurd om de organisatie te testen, zo van "we zijn gehackt test hier je wachtwoord sterkte". 17% vulde een wachtwoord in, ruim 30% heeft de link geopend. Andere logo's, andere fonts + de organisatie was nooit geinformeerd over een hack. Dan verwacht je toch dat mensen even nadenken, maar een idioot teste ook nog even 10+ privé wachtwoorden haha.
Door DLans: Door Sjef van Heesch: @Erik van Straten
Maar de zwakste schakel blijft toch echt de mens.
Helemaal als je hem of haar ook nog eens uitrust met een zwak systeem.Maar de zwakste schakel blijft toch echt de mens.
Door Sjef van Heesch: Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Zoals anderen ook al aangaven: malware die jij opstart mag wat jij mag. Uit dat oogpunt is het op z'n minst opmerkelijk te noemen dat:1) Elk willekeurig programma jouw .doc/.docx bestanden mag wijzigen;
2) Het gebruikelijk is dat op fileshares (gedeelde bestanden op servers), iedereen die bestanden mag lezen, ze ook mag wijzigen (alleen al omdat dit vaak per ongeluk gebeurt, is het vreemd dat hier zelden maatregelen tegen genomen worden).
Maar zodra we die problemen tekkelen, staat de volgende issue alweer voor de deur: malwaremakers zullen dan bestanden kopiëren en dreigen ze te publiceren (dat is een trend waar je nu al de voortekenen van ziet, omdat steeds meer organisaties van offline back-ups gebruik gaan maken; zie bijv. https://www.security.nl/posting/636761/Criminelen+achter+Maze-ransomware+publiceren+gestolen+data).
We onkomen er m.i. niet aan om informatie zorgvuldig te classificeren op ten minste de volgende aspecten:
A) Vertrouwelijkheid: hoe erg is het voor de organisatie en voor "klanten" als informatie in verkeerde handen valt;
B) Integriteit: hoe erg is het als informatie onbedoeld en/of ongeautoriseerd gewijzigd wordt;
C) Onmisbaarheid: hoe erg is het als informatie, die niet onmiddellijk beschikbaar hoeft te zijn, verloren gaat;
D) Bereikbaarheid: hoe erg is het als we, vaak tijdkritische, informatie niet op tijd kunnen benaderen.
Ik knip beschikbaarheid altijd bewust op in C en D omdat dit vaak verschillende aspecten zijn. Denk aan filemeldingen waar je een paar uur later niks meer aan hebt en anderszijds contracten of financiële gegevens bijv. voor de belastingdienst (waarbij het zelden een probleem is als je die pas een dag later kunt overleggen).
Als je met classificeren begint, kom je er al snel achter dat je ook aan lifecycle-management moet doen. Immers zodra een nieuwe versie van een belangrijk document wordt goedgekeurd, verandert meestal de "Sollwert" (zou-moeten-zijn-waarde) van de classificatie van de vorige versie. En bijv. sollicitatiegegevens mag je maar beperkte tijd bewaren, en zodra een persoon overlijdt, vervalt een deel van de vertrouwelijkheid van gegevens van die persoon.
Aan de hand van de vastgestelde classificatie, samen met life-cycle attributen, kunnen verstandige opslag-, back-up- en archiverings-strategiën worden gekozen (en ook worden bepaald aan welke eisen o.a. transport en vernietiging van informatie moeten voldoen).
Een ander aspect is de hoeveelheid online (binnen de organisatie bedoel ik) informatie met een hoge classificatie in één of meer van de bovenstaande categoriën. Met name de toegang tot grote hoeveelheden vertrouwelijke informatie zullen we, ook voor geautoriseerde gebruikers, lastiger moeten maken (of alarmbellen laten afgaan) om toekomstige "leakransomware" te pareren.
Voorbeeld: dat een fout (of opzet) van 1 persoon ertoe leidt dat vertrouwelijke "big-data" gegevens van 2,4 miljoen mensen 3 weken door iedere internetter te benaderen zijn, moet door de informatie-"bezittende" organisatie onmogelijk zijn gemaakt. En als ze dat vertikken, moet dat zwaar worden bestraft (vooral als ze vervolgens ook nog de boodschapper verwijten dat deze het lek niet onder "responsible disclosure" aan hen heeft gemeld - om "reputatieschade te voorkomen" - zie https://www.security.nl/posting/637052/Smarthomefabrikant+Wyze+lekt+data+2%2C4+miljoen+gebruikers, en er mogelijkerwijs meer stinkt, zie met name Part 2 in https://blog.12security.com/wyze-essay-2-aresflare/; disclaimer: ik heb geen idee of het klopt wat daar staat).
De huidige besturingssystemen en toepassingssoftware bieden nog veel te weinig handvatten hiervoor, waardoor iedereen zelf, meestal halfbakken, oplossingen gaat bedenken (of niets doet, met alle risico's van dien). Met de extreem gedaalde prijs van opslag en de onbedwingbare verzamelwoede van informatie (ook ik maak me daar schuldig aan) is het m.i. de hoogste tijd dat we met z'n allen informatiebeveiliging grondiger en goed doordacht gaan aanpakken, en bijtijds anticiperen op cybercrime en andere (informatiebeveiliging-gerelateerde) maatschappij-ondermijnende praktijken.
Ik gebruik een applicatie firewall en die geeft bij iedere applicatie die een netwerkverbinding wil maken een pop-up om verkeer al dan niet toe te staan. Daar kan ik dus per applicatie instellen welke verbinding toegestaan is, tijdelijk maar ook permanent.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
31-12-2019, 12:17 door
DLans
Door souplost:
Door DLans: Door Sjef van Heesch: @Erik van Straten
Maar de zwakste schakel blijft toch echt de mens.
Helemaal als je hem of haar ook nog eens uitrust met een zwak systeem.Maar de zwakste schakel blijft toch echt de mens.
Oh een Windows hater, hallo. Als ik een website open waar ik mijn wachtwoord moet invullen, beschermt Linux mij dan? Wordt mijn account dan niet gehackt? Kan er dan geen misbruik gemaakt worden?
31-12-2019, 12:26 door
karma4
Door Erik van Straten:...
De huidige besturingssystemen en toepassingssoftware bieden nog veel te weinig handvatten hiervoor, waardoor iedereen zelf, meestal halfbakken, oplossingen gaat bedenken (of niets doet, met alle risico's van dien). Met de extreem gedaalde prijs van opslag en de onbedwingbare verzamelwoede van informatie (ook ik maak me daar schuldig aan) is het m.i. de hoogste tijd dat we met z'n allen informatiebeveiliging grondiger en goed doordacht gaan aanpakken, en bijtijds anticiperen op cybercrime en andere (informatiebeveiliging-gerelateerde) maatschappij-ondermijnende praktijken.
Prachtig vanuit de eisen van de organisatie kijken naar de betreffende informatie en pas daarna naar de techniek kijken.De huidige besturingssystemen en toepassingssoftware bieden nog veel te weinig handvatten hiervoor, waardoor iedereen zelf, meestal halfbakken, oplossingen gaat bedenken (of niets doet, met alle risico's van dien). Met de extreem gedaalde prijs van opslag en de onbedwingbare verzamelwoede van informatie (ook ik maak me daar schuldig aan) is het m.i. de hoogste tijd dat we met z'n allen informatiebeveiliging grondiger en goed doordacht gaan aanpakken, en bijtijds anticiperen op cybercrime en andere (informatiebeveiliging-gerelateerde) maatschappij-ondermijnende praktijken.
Met die halfbakken oplossingen ben ik het niet direct eens. Je moet ergens beginnen om met die eisen wat te gaan invullen.
Die eisen op een rijtje zetten vanuit de eigen organisatie zal nooit vanuit een techniek gedreven moeten zijn.
Step je naar anderen om het uitgevoerd dan wel ingevuld te krijgen, dan loop je vrij snel tegen de muur van het onbegrip aan dat het niet allemaal zo zou moeten en dat ….. .
Door DLans:
Oh een Windows hater, hallo. Als ik een website open waar ik mijn wachtwoord moet invullen, beschermt Linux mij dan? Wordt mijn account dan niet gehackt? Kan er dan geen misbruik gemaakt worden?
Oh een Windows hater, hallo. Als ik een website open waar ik mijn wachtwoord moet invullen, beschermt Linux mij dan? Wordt mijn account dan niet gehackt? Kan er dan geen misbruik gemaakt worden?
Er zit natuurlijk wel een kern van waarheid in, als een systeem niet in staat is om gebruikers in bescherming te nemen moeten er maatregelen getroffen worden. Waarmee ik NIET wil zeggen dat Windows onveilig is, dat geldt evengoed voor Linux, BSD of macOS.
Vroeger waren er machines op de werkvloer waar je met je vingers tussen kon komen, later zijn daar hekjes om geplaatst maar die werden al gauw vastgezet. Vervolgens worden er schakelaars toegevoegd die met 2 handen bediend moeten worden en interlocks. Zo maak bescherm je gebruikers tegen 'dommigheden'.
31-12-2019, 12:46 door
souplost
Door DLans:
Oh een Windows hater, hallo. Als ik een website open waar ik mijn wachtwoord moet invullen, beschermt Linux mij dan? Wordt mijn account dan niet gehackt? Kan er dan geen misbruik gemaakt worden?
Ik gebruik geen zwakke systemen. Is dat ook goed zonder een hater te zijn? Ik had het niet over Linux maar blijkbaar gaat dat wel door voor een sterk systeem in jouw ogen. Dat heeft Linux waarschijnlijk te danken aan dat het in de basis multi/processing/user is opgezet (met dank aan de mainframe wereld) en gebouwd is met kleine stukjes software die elkaar ondersteunen en waar de GUI niet vervlochten is tot spagetthi in de kernel. Windows is in dat opzicht 1 container. 1 gat en het hele schip zinkt. Dat zie je terug in de maandelijkse kritieke updates (topje van de ijsberg omdat de software gesloten is). Veel processen draaien met admin rechten. Onder Linux is dat zeer ongebruikelijk. Windows update is alleen MS software en geen third party (weer aparte software nodig om dit onder te faciliteren), Het aanvalsvlak is ook veel kleiner omdat de hoeveelheid disk (software) gebruik 10 tot 20 keer kleiner is en zo kan ik nog wel een tijdje doorgaan.Door souplost:
Door DLans: Door Sjef van Heesch: @Erik van Straten
Maar de zwakste schakel blijft toch echt de mens.
Helemaal als je hem of haar ook nog eens uitrust met een zwak systeem.Maar de zwakste schakel blijft toch echt de mens.
Oh een Windows hater, hallo. Als ik een website open waar ik mijn wachtwoord moet invullen, beschermt Linux mij dan? Wordt mijn account dan niet gehackt? Kan er dan geen misbruik gemaakt worden?
Een Linux desktop heeft het grote voordeel dat een driveby download niet werkt en windows malware ook niet.
Door Sjef van Heesch: Ik gebruik een applicatie firewall en die geeft bij iedere applicatie die een netwerkverbinding wil maken een pop-up om verkeer al dan niet toe te staan. Daar kan ik dus per applicatie instellen welke verbinding toegestaan is, tijdelijk maar ook permanent.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Er zijn hier mogelijkheden voor. Applock of eventueel third party software. Maar implementaties zijn vaak lastig, complex en gebruikers onvriendelijk. Maar vergeet niet dat word bijvoorbeeld ook in de temp directory files wilt aanmaken of tijdelijke bestanden.Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Maar dit is allemaal gelimiteerd mogelijk met de standaard Windows mogelijkheden (applocker). Hiermee is al heel veel ellende voor voorkomen. Zelfs met een paar basis regels. Zoals geen .exe (of js) files laten uitvoeren in de temp map.
Ik heb diverse uitbraken met mcafee hiervoor al voorkomen. Gewoon de exploits tegenhouden met een paar regels beveiligingen.
Nadeel is dat het een tijdrovende en gebruikers vaak hinder kunnen ondervinden (ondanks pilot uitrollen) en hierdoor vaak tegengehouden door het managent of de business. Die zitten hierop niet te wachten, want gebruikers zijn ontevreden en beginnen te klagen. Dus is IT de gebeten hond.
Maar de Universiteit uitbraak had zeer gemakkelijk gelimiteerd kunnen worden.
Bij Gothenburg en Regensburg zijn de bestaande losse IT eilandjes allemaal samengevoegd en in een samenhangende IT organisatie gestopt, zonder verlies van kennis *en affiniteit*. Vanuit de bestaande pool werd een nieuwe organisatie gevormd met gedegen kennis van het netwerk zonder de daadwerkelijke knelpunten uit het oog te verliezen.
"Ik moet een nieuwe Wifi hotspot want ik wil met mijn telefoon de MRI scans kunnen zien" wordt vertaald naar een werkbare oplossing, zonder security én werkbaarheid uit het oog te verliezen.
mooi maar hier bij ons aan een uni in NL is precies dit dus mislukt. bij ons zien we dat alles wat centraal gaat altijd gepaard is gegaan met achteruitgang in suppoort / mogelijkheden / flexibiliteit maar meer buraucratie op het bord van docenten en wetenschappers. de 'gemanagde processen' gaan als stroop en links weet niet wat rechts een jaar ervoor heeft afgesproken omdat er ook steeds maar externen binnen gehaald worden. bij ons zal er centraal niet genoeg kennis en door samenvoegen is dat beetje expertise verwaterd geraakt in de poel. daar kun je geen onderzoek op bazeren of studenten hun onderwijs op bouwen. daar is continuiteit en stabiliteit voor nodig.
Door Sjef van Heesch: Ik gebruik een applicatie firewall en die geeft bij iedere applicatie die een netwerkverbinding wil maken een pop-up om verkeer al dan niet toe te staan. Daar kan ik dus per applicatie instellen welke verbinding toegestaan is, tijdelijk maar ook permanent.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben tot bepaalde systeemobjecten of netwerkomgevingen. Access control lists worden doorgaans toegepast op bestandstructuren (bestanden/ mappen) of netwerkstructuren (poortnummers/ ip adressen). - https://www.marqit.be/access-control-list.aspx
de heren hierboven zouden eens 'man umask' en 'man pam_umask' eens moeten bekijken. op een unix systeem kun je afdwingen dat default geen files executable zijn als die gedownload worden. daarom is het net een stapje lastiger om via het klikken van een linkje een randomware als gebruiker te starten. en zo zijn er wel meer dingen...
Door DLans:
Daarom ben ik fan van bijvoorbeeld Palo Alto Traps. Een applicatie die weinig updates vereist, maar middels behavioral security kijkt naar wat een applicatie doet. Wij draaide Traps bij mijn vorige werkgever i.c.m. een reguliere antivirus, en dat werkte voor ons uitstekend. Dan nog hebben we een keer een ransomware infectie gehad (onduidelijk waarom beide oplossingen niet ingrepen), maar de schade was beperkt tot wat mappen op een netwerklocatie. De users zijn immers géén admins en de malware kan op de lokale systemen absoluut geen domain admin credentials vinden ;-) Dus PC gewoon vernietigd onder de pers (ja echt ^^) en een backup voor de getroffen mappen teruggezet.
Maar de zwakste schakel blijft toch echt de mens. We hebben een nep email verstuurd om de organisatie te testen, zo van "we zijn gehackt test hier je wachtwoord sterkte". 17% vulde een wachtwoord in, ruim 30% heeft de link geopend. Andere logo's, andere fonts + de organisatie was nooit geinformeerd over een hack. Dan verwacht je toch dat mensen even nadenken, maar een idioot teste ook nog even 10+ privé wachtwoorden haha.
Door Sjef van Heesch: @Erik van Straten
Bedankt voor deze uitgebreide uitleg, zeer helder.
Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
Bedankt voor deze uitgebreide uitleg, zeer helder.
Dus een volledig gepatched systeem, met volledig gepatchte software is ook NIET bestand tegen ransomware?
Immers als een normale gebruiker een malafide programmatje download kan deze al beginnen met zijn/haar bestanden te versleutelen. Dat zou al een for/next loopje kunnen zijn van een "Winzip" met wachtwoord op de zip files.
Daarom ben ik fan van bijvoorbeeld Palo Alto Traps. Een applicatie die weinig updates vereist, maar middels behavioral security kijkt naar wat een applicatie doet. Wij draaide Traps bij mijn vorige werkgever i.c.m. een reguliere antivirus, en dat werkte voor ons uitstekend. Dan nog hebben we een keer een ransomware infectie gehad (onduidelijk waarom beide oplossingen niet ingrepen), maar de schade was beperkt tot wat mappen op een netwerklocatie. De users zijn immers géén admins en de malware kan op de lokale systemen absoluut geen domain admin credentials vinden ;-) Dus PC gewoon vernietigd onder de pers (ja echt ^^) en een backup voor de getroffen mappen teruggezet.
Maar de zwakste schakel blijft toch echt de mens. We hebben een nep email verstuurd om de organisatie te testen, zo van "we zijn gehackt test hier je wachtwoord sterkte". 17% vulde een wachtwoord in, ruim 30% heeft de link geopend. Andere logo's, andere fonts + de organisatie was nooit geinformeerd over een hack. Dan verwacht je toch dat mensen even nadenken, maar een idioot teste ook nog even 10+ privé wachtwoorden haha.
"... Bedankt voor deze uitgebreide uitleg, zeer helder."
Daar sluit ik mij graag bij aan: goede vragen en duidelijke antwoorden, zo leest security.nl prettig.
"... Dan nog hebben we een keer een ransomware infectie gehad (onduidelijk waarom beide oplossingen niet ingrepen).."
https://docs.paloaltonetworks.com/traps/tms/traps-management-service-admin/get-started-with-tms/migrate-esm-to-tms.html
Palo Alto Traps lijkt mij een commercieel multi-platform (Windows, MacOS, Linux) IPS (Intrusion Preventing System).
Een multi-platform en open-source (volledig FOSS) IPS is "Snort".
https://nl.wikipedia.org/wiki/Snort
Zowel Traps als Snort zijn gebaat bij goede "regels", daar zouden ook "best practices" voor ontwikkeld kunnen worden. Daarbij is jouw opmerking: "... onduidelijk waarom beide oplossingen niet ingrepen ..." van groot belang, want ook hier geldt dat iedereen van zijn fouten kan leren. Of beter gezegd, wij leren graag van de door jou ontdekte zwakheden. En vice versa.
Je zou dus berichten verwachten zoals deze: "Geachte forumleden, onze Snort regels (...) hebben niet kunnen voorkomen dat wij met malware XYZ zijn besmet. Graag opmerkingen en suggesties."
"... De users zijn immers géén admins en de malware kan op de lokale systemen absoluut geen domain admin credentials vinden ;-) ..."
Oeps, als een hacker "domain admin credentials" kan vinden op lokale systemen, dan is er of iets volledig mis met het systeem ontwerp, of de admin is roekeloos bezig. De sleutel zit in de voordeur, en de inbreker hoeft hem alleen om te draaien??
Door The FOSS:
Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben tot bepaalde systeemobjecten of netwerkomgevingen. Access control lists worden doorgaans toegepast op bestandstructuren (bestanden/ mappen) of netwerkstructuren (poortnummers/ ip adressen). - https://www.marqit.be/access-control-list.aspx
Door Sjef van Heesch: Ik gebruik een applicatie firewall en die geeft bij iedere applicatie die een netwerkverbinding wil maken een pop-up om verkeer al dan niet toe te staan. Daar kan ik dus per applicatie instellen welke verbinding toegestaan is, tijdelijk maar ook permanent.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Is er zoiets vergelijkbaars voor het wijzigen/schrijven van bestanden?
Dan mag alleen programma WORD in directory /user/gebruiker/documenten bestand pietjepuk.txt schrijven.
Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben tot bepaalde systeemobjecten of netwerkomgevingen. Access control lists worden doorgaans toegepast op bestandstructuren (bestanden/ mappen) of netwerkstructuren (poortnummers/ ip adressen). - https://www.marqit.be/access-control-list.aspx
Dat is niet erg gebruiksvriendelijk, zo'n pop-up systeem op gebruikers niveau lijkt me veel handiger en toch veilig.
Waar jij naar verwijst is meer SELinux achtig denk ik.
31-12-2019, 14:40 door
Erik van Straten
Door The FOSS: Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben ...
Daar heb je, in de basis, niets aan om te bepalen welk programma bestanden van een bepaald type mag wijzigen, want een ACE (Access Control Entry) bepaalt (zoals je zelf ook schrijft) wat een gebruiker (of een groep gebruikers) mag met een bestand (of ander object).Onder Linux kun je nog wat pielen door per applicatie een unieke groep te maken en met sgid trucs uit te halen, maar besturingssystemen zijn hier gewoonweg niet voor ontworpen (dat soort maatregelen zijn gecompliceerd en ondoorzichtig); uitgangspunt bij het ontwerp van besturingssystemen was altijd dat de gebruiker, en de software die hij/zij start, te vertrouwen is v.w.b. informatie waar die gebruikers zelf bij moeten kunnen (het onderscheid beheerder/gebruiker bestaat al langer, maar dat is vooral bedoeld om systemen zelf te beschermen).
Daar komt bij dat als we dit fixen, we er nog lang niet zijn; veel an sich betrouwbare software kan kwaadaardig worden door injectie van code, kwaadaardige macro's of gecompromitteerde updates. Daarbij kunnen gebruikers welliswaar niet alle soorten software zelf installeren, maar veel software is in een "portable" vorm beschikbaar of bestaat uit een losse executable (of script). En soms is dat nuttig (wellicht niet voor elk type gebruiker): als je een .docx bestand op kwaadaardige macro's wilt controleren, kun je zo'n file openen in een unzipper of de tools van Didier Stevens er op loslaten (zie bijv. https://blog.didierstevens.com/programs/oledump-py/). Onder Linux zou ik tools als grep e.d. niet willen missen, en al die tools whitelisten wordt ook een rommeltje en kan worden misbruikt.
Vandaar de oproep voor mijn uitgangspunt: assume compromise. Hou rekening met kwaadaardige werknemers, en met werknemers die wellicht goed zijn in hun werk, maar minder security-aware dan je zou willen (monitor op anomalies), maar ook die -menselijke- fouten maken (vereis bijv. bij mailings naar klanten minstens 4 ogen die checken of de juiste bijlage is bijgesloten en geadresseerden uitsluitend in het Bcc veld staan). Classificeer in elk geval die informatie die, indien deze ongeautoriseerd of onbedoeld gelekt-, vernietigd- of gewijzigd wordt, tot relevante schade leidt voor jou en/of jouw klanten (dit kan andere dan privacy-gevoelige informatie betreffen). En behandel (opslaan, transporteren, back-uppen en vernietigen) die informatie zoals past bij de vastgestelde classificatie.
Door Erik van Straten:
Door The FOSS: Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben ...
Daar heb je, in de basis, niets aan om te bepalen welk programma bestanden van een bepaald type mag wijzigen, want een ACE (Access Control Entry) bepaalt (zoals je zelf ook schrijft) wat een gebruiker (of een groep gebruikers) mag met een bestand (of ander object).Ik had niet goed gelezen inderdaad; hij had er programma bij staan. Constructies met chroot maar die zijn ook ingewikkeld.
31-12-2019, 16:03 door
souplost
Door Erik van Straten:
Onder Linux kun je nog wat pielen door per applicatie een unieke groep te maken en met sgid trucs uit te halen, maar besturingssystemen zijn hier gewoonweg niet voor ontworpen (dat soort maatregelen zijn gecompliceerd en ondoorzichtig); uitgangspunt bij het ontwerp van besturingssystemen was altijd dat de gebruiker, en de software die hij/zij start, te vertrouwen is v.w.b. informatie waar die gebruikers zelf bij moeten kunnen (het onderscheid beheerder/gebruiker bestaat al langer, maar dat is vooral bedoeld om systemen zelf te beschermen).
Daar komt bij dat als we dit fixen, we er nog lang niet zijn; veel an sich betrouwbare software kan kwaadaardig worden door injectie van code, kwaadaardige macro's of gecompromitteerde updates. Daarbij kunnen gebruikers welliswaar niet alle soorten software zelf installeren, maar veel software is in een "portable" vorm beschikbaar of bestaat uit een losse executable (of script). En soms is dat nuttig (wellicht niet voor elk type gebruiker): als je een .docx bestand op kwaadaardige macro's wilt controleren, kun je zo'n file openen in een unzipper of de tools van Didier Stevens er op loslaten (zie bijv. https://blog.didierstevens.com/programs/oledump-py/). Onder Linux zou ik tools als grep e.d. niet willen missen, en al die tools whitelisten wordt ook een rommeltje en kan worden misbruikt.
Vandaar de oproep voor mijn uitgangspunt: assume compromise. Hou rekening met kwaadaardige werknemers, en met werknemers die wellicht goed zijn in hun werk, maar minder security-aware dan je zou willen (monitor op anomalies), maar ook die -menselijke- fouten maken (vereis bijv. bij mailings naar klanten minstens 4 ogen die checken of de juiste bijlage is bijgesloten en geadresseerden uitsluitend in het Bcc veld staan). Classificeer in elk geval die informatie die, indien deze ongeautoriseerd of onbedoeld gelekt-, vernietigd- of gewijzigd wordt, tot relevante schade leidt voor jou en/of jouw klanten (dit kan andere dan privacy-gevoelige informatie betreffen). En behandel (opslaan, transporteren, back-uppen en vernietigen) die informatie zoals past bij de vastgestelde classificatie.
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama. Op een gegeven moment zit toch iedereen in elke groep.Door The FOSS: Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben ...
Daar heb je, in de basis, niets aan om te bepalen welk programma bestanden van een bepaald type mag wijzigen, want een ACE (Access Control Entry) bepaalt (zoals je zelf ook schrijft) wat een gebruiker (of een groep gebruikers) mag met een bestand (of ander object).Onder Linux kun je nog wat pielen door per applicatie een unieke groep te maken en met sgid trucs uit te halen, maar besturingssystemen zijn hier gewoonweg niet voor ontworpen (dat soort maatregelen zijn gecompliceerd en ondoorzichtig); uitgangspunt bij het ontwerp van besturingssystemen was altijd dat de gebruiker, en de software die hij/zij start, te vertrouwen is v.w.b. informatie waar die gebruikers zelf bij moeten kunnen (het onderscheid beheerder/gebruiker bestaat al langer, maar dat is vooral bedoeld om systemen zelf te beschermen).
Daar komt bij dat als we dit fixen, we er nog lang niet zijn; veel an sich betrouwbare software kan kwaadaardig worden door injectie van code, kwaadaardige macro's of gecompromitteerde updates. Daarbij kunnen gebruikers welliswaar niet alle soorten software zelf installeren, maar veel software is in een "portable" vorm beschikbaar of bestaat uit een losse executable (of script). En soms is dat nuttig (wellicht niet voor elk type gebruiker): als je een .docx bestand op kwaadaardige macro's wilt controleren, kun je zo'n file openen in een unzipper of de tools van Didier Stevens er op loslaten (zie bijv. https://blog.didierstevens.com/programs/oledump-py/). Onder Linux zou ik tools als grep e.d. niet willen missen, en al die tools whitelisten wordt ook een rommeltje en kan worden misbruikt.
Vandaar de oproep voor mijn uitgangspunt: assume compromise. Hou rekening met kwaadaardige werknemers, en met werknemers die wellicht goed zijn in hun werk, maar minder security-aware dan je zou willen (monitor op anomalies), maar ook die -menselijke- fouten maken (vereis bijv. bij mailings naar klanten minstens 4 ogen die checken of de juiste bijlage is bijgesloten en geadresseerden uitsluitend in het Bcc veld staan). Classificeer in elk geval die informatie die, indien deze ongeautoriseerd of onbedoeld gelekt-, vernietigd- of gewijzigd wordt, tot relevante schade leidt voor jou en/of jouw klanten (dit kan andere dan privacy-gevoelige informatie betreffen). En behandel (opslaan, transporteren, back-uppen en vernietigen) die informatie zoals past bij de vastgestelde classificatie.
Ik denk dat we voor gewone gebruikers geklooi op netwerklaag niet meer moeten toestaan, anders wordt het wel heel moeilijk om kwaadaardige werknemers te beteugelen. Dat betekent alleen nog maar toegang op applicatielaag en geen desktop meer faciliteren. BYOD inprikken is prima maar het netwerk wordt behandeld als kwaadaardig internet.
Door souplost:
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Valt wel mee. Daarvoor hebben ze AD uitgevonden en is daar erg krachtig in.Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Op een gegeven moment zit toch iedereen in elke groep.
Valt wel mee. Je moet eigenlijk wel heel goed nadenk over de setup. Functionele rechten vs specifieke rechten.Ik denk dat we voor gewone gebruikers geklooi op netwerklaag niet meer moeten toestaan, anders wordt het wel heel moeilijk om kwaadaardige werknemers te beteugelen.
Hoe zie je netwerklaag? Uiteindelijke staat alle data ergens op het netwerk.Dat betekent alleen nog maar toegang op applicatielaag
Wat zie jij als applicatie laag? Want data moet toegankelijk zijn voor applicaties. En dit kunnen verschillende applicaties zijn. Zowel een DMS, Office, of een SAP achtige applicatie.en geen desktop meer faciliteren. BYOD inprikken is prima maar het netwerk wordt behandeld als kwaadaardig internet.
Uiteindelijk moet men ergens mee gaan werken om de data te verwerken of de applicaties op te starten. BYOD device hoef je hiervoor inderdaad niet te vertrouwen, maar hoe/waar gebruikt men dan de applicaties en benaderd men de data? Ergens moet er toegang en toegangs rechten zijn.Door souplost:
Ik denk dat we voor gewone gebruikers geklooi op netwerklaag niet meer moeten toestaan, anders wordt het wel heel moeilijk om kwaadaardige werknemers te beteugelen. Dat betekent alleen nog maar toegang op applicatielaag en geen desktop meer faciliteren. BYOD inprikken is prima maar het netwerk wordt behandeld als kwaadaardig internet.
Door Erik van Straten:
Onder Linux kun je nog wat pielen door per applicatie een unieke groep te maken en met sgid trucs uit te halen, maar besturingssystemen zijn hier gewoonweg niet voor ontworpen (dat soort maatregelen zijn gecompliceerd en ondoorzichtig); uitgangspunt bij het ontwerp van besturingssystemen was altijd dat de gebruiker, en de software die hij/zij start, te vertrouwen is v.w.b. informatie waar die gebruikers zelf bij moeten kunnen (het onderscheid beheerder/gebruiker bestaat al langer, maar dat is vooral bedoeld om systemen zelf te beschermen).
Daar komt bij dat als we dit fixen, we er nog lang niet zijn; veel an sich betrouwbare software kan kwaadaardig worden door injectie van code, kwaadaardige macro's of gecompromitteerde updates. Daarbij kunnen gebruikers welliswaar niet alle soorten software zelf installeren, maar veel software is in een "portable" vorm beschikbaar of bestaat uit een losse executable (of script). En soms is dat nuttig (wellicht niet voor elk type gebruiker): als je een .docx bestand op kwaadaardige macro's wilt controleren, kun je zo'n file openen in een unzipper of de tools van Didier Stevens er op loslaten (zie bijv. https://blog.didierstevens.com/programs/oledump-py/). Onder Linux zou ik tools als grep e.d. niet willen missen, en al die tools whitelisten wordt ook een rommeltje en kan worden misbruikt.
Vandaar de oproep voor mijn uitgangspunt: assume compromise. Hou rekening met kwaadaardige werknemers, en met werknemers die wellicht goed zijn in hun werk, maar minder security-aware dan je zou willen (monitor op anomalies), maar ook die -menselijke- fouten maken (vereis bijv. bij mailings naar klanten minstens 4 ogen die checken of de juiste bijlage is bijgesloten en geadresseerden uitsluitend in het Bcc veld staan). Classificeer in elk geval die informatie die, indien deze ongeautoriseerd of onbedoeld gelekt-, vernietigd- of gewijzigd wordt, tot relevante schade leidt voor jou en/of jouw klanten (dit kan andere dan privacy-gevoelige informatie betreffen). En behandel (opslaan, transporteren, back-uppen en vernietigen) die informatie zoals past bij de vastgestelde classificatie.
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama. Op een gegeven moment zit toch iedereen in elke groep.Door The FOSS: Jazeker: Een Access Control List (ACL) is een tabel met regels (ACEs - Access Control Entries) die de rechten (permissions) bepalen. Deze regels hebben betrekking op de toegang die gebruikers hebben ...
Daar heb je, in de basis, niets aan om te bepalen welk programma bestanden van een bepaald type mag wijzigen, want een ACE (Access Control Entry) bepaalt (zoals je zelf ook schrijft) wat een gebruiker (of een groep gebruikers) mag met een bestand (of ander object).Onder Linux kun je nog wat pielen door per applicatie een unieke groep te maken en met sgid trucs uit te halen, maar besturingssystemen zijn hier gewoonweg niet voor ontworpen (dat soort maatregelen zijn gecompliceerd en ondoorzichtig); uitgangspunt bij het ontwerp van besturingssystemen was altijd dat de gebruiker, en de software die hij/zij start, te vertrouwen is v.w.b. informatie waar die gebruikers zelf bij moeten kunnen (het onderscheid beheerder/gebruiker bestaat al langer, maar dat is vooral bedoeld om systemen zelf te beschermen).
Daar komt bij dat als we dit fixen, we er nog lang niet zijn; veel an sich betrouwbare software kan kwaadaardig worden door injectie van code, kwaadaardige macro's of gecompromitteerde updates. Daarbij kunnen gebruikers welliswaar niet alle soorten software zelf installeren, maar veel software is in een "portable" vorm beschikbaar of bestaat uit een losse executable (of script). En soms is dat nuttig (wellicht niet voor elk type gebruiker): als je een .docx bestand op kwaadaardige macro's wilt controleren, kun je zo'n file openen in een unzipper of de tools van Didier Stevens er op loslaten (zie bijv. https://blog.didierstevens.com/programs/oledump-py/). Onder Linux zou ik tools als grep e.d. niet willen missen, en al die tools whitelisten wordt ook een rommeltje en kan worden misbruikt.
Vandaar de oproep voor mijn uitgangspunt: assume compromise. Hou rekening met kwaadaardige werknemers, en met werknemers die wellicht goed zijn in hun werk, maar minder security-aware dan je zou willen (monitor op anomalies), maar ook die -menselijke- fouten maken (vereis bijv. bij mailings naar klanten minstens 4 ogen die checken of de juiste bijlage is bijgesloten en geadresseerden uitsluitend in het Bcc veld staan). Classificeer in elk geval die informatie die, indien deze ongeautoriseerd of onbedoeld gelekt-, vernietigd- of gewijzigd wordt, tot relevante schade leidt voor jou en/of jouw klanten (dit kan andere dan privacy-gevoelige informatie betreffen). En behandel (opslaan, transporteren, back-uppen en vernietigen) die informatie zoals past bij de vastgestelde classificatie.
Ik denk dat we voor gewone gebruikers geklooi op netwerklaag niet meer moeten toestaan, anders wordt het wel heel moeilijk om kwaadaardige werknemers te beteugelen. Dat betekent alleen nog maar toegang op applicatielaag en geen desktop meer faciliteren. BYOD inprikken is prima maar het netwerk wordt behandeld als kwaadaardig internet.
en daarom dus het idee van Mandatory Access Control: https://en.wikipedia.org/wiki/Mandatory_access_control
Door Anoniem:
Zie https://nl.wikipedia.org/wiki/OSI-modelDoor souplost:
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Valt wel mee. Daarvoor hebben ze AD uitgevonden en is daar erg krachtig in.Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Op een gegeven moment zit toch iedereen in elke groep.
Valt wel mee. Je moet eigenlijk wel heel goed nadenk over de setup. Functionele rechten vs specifieke rechten.Ik denk dat we voor gewone gebruikers geklooi op netwerklaag niet meer moeten toestaan, anders wordt het wel heel moeilijk om kwaadaardige werknemers te beteugelen.
Hoe zie je netwerklaag? Uiteindelijke staat alle data ergens op het netwerk.Dat betekent alleen nog maar toegang op applicatielaag
Wat zie jij als applicatie laag? Want data moet toegankelijk zijn voor applicaties. En dit kunnen verschillende applicaties zijn. Zowel een DMS, Office, of een SAP achtige applicatie.en geen desktop meer faciliteren. BYOD inprikken is prima maar het netwerk wordt behandeld als kwaadaardig internet.
Uiteindelijk moet men ergens mee gaan werken om de data te verwerken of de applicaties op te starten. BYOD device hoef je hiervoor inderdaad niet te vertrouwen, maar hoe/waar gebruikt men dan de applicaties en benaderd men de data? Ergens moet er toegang en toegangs rechten zijn.Met organisatorisch drama bedoel ik niet de techniek, maar de organisatie. Toegang alleen via een browser device. Sommige bedrijven proberen een desktop dicht te timmeren met policies maar dat lukt toch niet en levert ook veel te veel onderhoud. Toegangsrechten (roles) geef je in de applicatie en niet op bestandsniveau. Dus eigenlijk een bedrijfsportaal.
Door Anoniem:
Door souplost:
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Valt wel mee. Daarvoor hebben ze AD uitgevonden en is daar erg krachtig in.Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Op een gegeven moment zit toch iedereen in elke groep.
Valt wel mee. Je moet eigenlijk wel heel goed nadenk over de setup. Functionele rechten vs specifieke rechten.Ik denk dat we voor gewone gebruikers geklooi op netwerklaag niet meer moeten toestaan, anders wordt het wel heel moeilijk om kwaadaardige werknemers te beteugelen.
Hoe zie je netwerklaag? Uiteindelijke staat alle data ergens op het netwerk.Dat betekent alleen nog maar toegang op applicatielaag
Wat zie jij als applicatie laag? Want data moet toegankelijk zijn voor applicaties. En dit kunnen verschillende applicaties zijn. Zowel een DMS, Office, of een SAP achtige applicatie.en geen desktop meer faciliteren. BYOD inprikken is prima maar het netwerk wordt behandeld als kwaadaardig internet.
Uiteindelijk moet men ergens mee gaan werken om de data te verwerken of de applicaties op te starten. BYOD device hoef je hiervoor inderdaad niet te vertrouwen, maar hoe/waar gebruikt men dan de applicaties en benaderd men de data? Ergens moet er toegang en toegangs rechten zijn.AD is een van de slechtste ID systemen die er is. Het is letterlijk een platte spreadsheet.
Als je een goed Identity Management systeem neemt (IDM van MicroFocus is er zo een) en combineert met Filr dan wordt maintenance van je ID systeem opeens veel makkelijker/beter. Gescripte accountdeactivaties op basis van aanstelling, of ingeschreven staan aan school als student en je bent in eens van een hoop oud zeer af.
Als ik op bijeenkomsten vertel wat ons ID systeem kan dan vallen de AD mensen van hun stoel van verbazing.
Functionele rechten in IDM zijn gekoppelde rollen en resources, gevoed vanuit systemen als een SIS of salarissysteem en zorgen naadloos voor goede rechten. En natuurlijk zijn dynamische groepen (HUH AD mensen?) helemaal het einde.
Door Anoniem: AD is een van de slechtste ID systemen die er is. Het is letterlijk een platte spreadsheet.
Als je een goed Identity Management systeem neemt (IDM van MicroFocus is er zo een) en combineert met Filr dan wordt maintenance van je ID systeem opeens veel makkelijker/beter. Gescripte accountdeactivaties op basis van aanstelling, of ingeschreven staan aan school als student en je bent in eens van een hoop oud zeer af.
Als ik op bijeenkomsten vertel wat ons ID systeem kan dan vallen de AD mensen van hun stoel van verbazing.
Functionele rechten in IDM zijn gekoppelde rollen en resources, gevoed vanuit systemen als een SIS of salarissysteem en zorgen naadloos voor goede rechten. En natuurlijk zijn dynamische groepen (HUH AD mensen?) helemaal het einde.
Als je een goed Identity Management systeem neemt (IDM van MicroFocus is er zo een) en combineert met Filr dan wordt maintenance van je ID systeem opeens veel makkelijker/beter. Gescripte accountdeactivaties op basis van aanstelling, of ingeschreven staan aan school als student en je bent in eens van een hoop oud zeer af.
Als ik op bijeenkomsten vertel wat ons ID systeem kan dan vallen de AD mensen van hun stoel van verbazing.
Functionele rechten in IDM zijn gekoppelde rollen en resources, gevoed vanuit systemen als een SIS of salarissysteem en zorgen naadloos voor goede rechten. En natuurlijk zijn dynamische groepen (HUH AD mensen?) helemaal het einde.
En open source software? Dat zou echt het Walhalla zijn!
Door Anoniem:
Door souplost:
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Valt wel mee. Daarvoor hebben ze AD uitgevonden en is daar erg krachtig in.Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Op een gegeven moment zit toch iedereen in elke groep.
Valt wel mee. Je moet eigenlijk wel heel goed nadenk over de setup. Functionele rechten vs specifieke rechten.Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
01-01-2020, 12:43 door
karma4
Door Anoniem:
Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Wat je noemt zijn de beleidskeuzes waarom je een bepaalde werkwijze hanteert. Daarvoor is een AD of zoals je wilt een stukje programmacode niet voor bedoeld. Het beheer loopt vaak via de HR systemen (gewoonlijk in grote organsiaties SAP) door naar de security. AD met zijn structuur de mogelijkheid om groepen lid te maken van groepen. Dat is met het basis Unix gebeuren niet mogelijk. Dus als je iets als primitief wil duiden is het Linux user identity management. Het is niet voor niets dat ACL oplossingen van de Microsoft (jaren 90) liever gezegd VMS aanpak (jaren 80) wordt gekopieerd.Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Door karma4:
Door Anoniem:
Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Wat je noemt zijn de beleidskeuzes waarom je een bepaalde werkwijze hanteert. Daarvoor is een AD of zoals je wilt een stukje programmacode niet voor bedoeld. Het beheer loopt vaak via de HR systemen (gewoonlijk in grote organsiaties SAP) door naar de security. AD met zijn structuur de mogelijkheid om groepen lid te maken van groepen. Dat is met het basis Unix gebeuren niet mogelijk. Dus als je iets als primitief wil duiden is het Linux user identity management. Het is niet voor niets dat ACL oplossingen van de Microsoft (jaren 90) liever gezegd VMS aanpak (jaren 80) wordt gekopieerd.Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Openldap kan dat gewoon dus niet uit je nek kletsen.
01-01-2020, 13:48 door
souplost
Door karma4:
Ach karma4 toch. Wel eens van IPA gehoord https://www.freeipa.org/page/Main_Page Kan ook nog eens een mutual trust opzetten met het oude AD mocht je dat willen en nog open source ook.Door Anoniem:
Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Wat je noemt zijn de beleidskeuzes waarom je een bepaalde werkwijze hanteert. Daarvoor is een AD of zoals je wilt een stukje programmacode niet voor bedoeld. Het beheer loopt vaak via de HR systemen (gewoonlijk in grote organsiaties SAP) door naar de security. AD met zijn structuur de mogelijkheid om groepen lid te maken van groepen. Dat is met het basis Unix gebeuren niet mogelijk. Dus als je iets als primitief wil duiden is het Linux user identity management. Het is niet voor niets dat ACL oplossingen van de Microsoft (jaren 90) liever gezegd VMS aanpak (jaren 80) wordt gekopieerd.Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Door Anoniem:
AD is een van de slechtste ID systemen die er is.
Valt best mee. Mist je er van te voren over nadenkt hoe je processen in je bedrijf lopen. Het is zeker niet perfect. Maar daarvoor kun je het koppelen aan andere systemen.AD is een van de slechtste ID systemen die er is.
Het is letterlijk een platte spreadsheet.
Dan is er iets mis met je inrichting je gebruikt het verkeerd of hebt verkeerde verwachtingenAls je een goed Identity Management systeem neemt (IDM van MicroFocus is er zo een) en combineert met Filr dan wordt maintenance van je ID systeem opeens veel makkelijker/beter. Gescripte accountdeactivaties op basis van aanstelling, of ingeschreven staan aan school als student en je bent in eens van een hoop oud zeer af.
Als ik op bijeenkomsten vertel wat ons ID systeem kan dan vallen de AD mensen van hun stoel van verbazing.
Je moet een Identity Systeem als AD niet vergelijken met een Identity management.Als ik op bijeenkomsten vertel wat ons ID systeem kan dan vallen de AD mensen van hun stoel van verbazing.
Veel van je genoemde punten kan ik ook gewoon zelf bouwen met AD. Echter een IDM systeem kan hier veel meer mee, het is een framework wat er specifiek voor gebouwd id. Het hangt alleen weer af van je requirements of standaard AD voldoet, of dat je meer wilt.
Functionele rechten in IDM zijn gekoppelde rollen en resources, gevoed vanuit systemen als een SIS of salarissysteem en zorgen naadloos voor goede rechten.
Klopt. Dit wordt meestal via een IDM systeem aan AD gekoppeld en eventueel nu andere systemen. Daar is een IDM voor designed en krachtig in. Koppel ze aan elkaar en je hebt een heel goed en mooi systeem.En natuurlijk zijn dynamische groepen (HUH AD mensen?) helemaal het einde.
AD is heeft inderdaad standaard geen dynamische groepen. Maar hier kun je ook omheen werken met wat scripting. Niet ideaal. Maar er is veel meer wat standaard AD niet kan, maar een IDM systeem wel. Daarom zijn het verschillende producten welke je niet kunt vergelijken met elkaar. Azure AD heeft dit gelukkig wel, maar mist weer andere functionele punten die een AD wel weer heeft.
Maar als een Windows beheerder de term dynamische groepen niet weet, dan mist hij wat basis kennis. Maar met goede scripting is daar heel goed omheen te werken. Hangt allemaal weer van je eisen pakket af of dit een noodzaak is. Ik heb het nog nooit nodig gehad als harde requirement. Ik kon er altijd omheen zonder al te veel problemen.
Door The FOSS:En open source software? Dat zou echt het Walhalla zijn!
Omdat? Wat is de toegevoegde waarde er van? Maar als het functioneel aan de requirements voldoet, waarom niet? Maar als een ander product het beter kan doen, waarom daar niet voor gaan? Je kiest het beste product, wat aan je requirements voldoet en dat is verder kijken dat een open/closed source software. Ik kom deze eis heel weinig tegen bij bedrijven. Door Anoniem:
Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
Tja... Van 25 tot 16000 of nog groter. Dus wat is groot? Wat is dynamisch? Ik zie het bij overheden, IT bedrijven, Nuts bedrijven. Sommige hebben alles per papier, sommige hebben een HR systeem wat via IDM gekoppeld is, sommige hebben een service desktool voor de automatisering. Zijn allemaal mogelijkheden. Hangt allemaal van het bedrijf af, hoe volwassen het is en wat met precies verwacht van de IT.Door Anoniem:
Door souplost:
Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Valt wel mee. Daarvoor hebben ze AD uitgevonden en is daar erg krachtig in.Unieke groepen aanmaken op bestandsniveau is een organisatorisch drama.
Op een gegeven moment zit toch iedereen in elke groep.
Valt wel mee. Je moet eigenlijk wel heel goed nadenk over de setup. Functionele rechten vs specifieke rechten.Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin.
Dan gebruik je daarvoor een specifieke IDM oplossing wat er tussen zit. Integratie is hiervoor de oplossing, zoals bij veel producten. Daarin zit juist de kracht van oplossingen. Er is niet 1 product wat alles kan. Gebruik een product waarin het goed is. AD is geen Identity management systeem, maar kan wel goed voor een identity authenticatie vs autorisatie doen. Al ziet Microsoft dit soms wel iets anders. Maar het zijn wel 2 verschillende systemen die je niet direct met elkaar kunt vergelijken.
Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Daar is weer eventueel tooling voor. Maar daarvoor is AD niet specifiek bedoelt. Zou wel gemakkelijk zijn. Maar met 3de partij software is dit allemaal mogelijk. beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Je probeert nu een vergelijking te maken tussen een Identity systeem (AD) en een Identity management Systeem of een service desk frontent. . Dat zijn verschillende producten. Ze lijken wel veel op elkaar. Maar zijn wel andere producten, met andere eisen.toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Zou wel gemakkelijk zijn in AD, misschien, maar voor veel bedrijven niet noodzakelijk.
Dat ontbreekt allemaal in AD, primitief systeem!
Nee, het zijn verschillende systemen die je nu probeert te vergelijken en daarom mis je bepaalde features.Door karma4:
Door Anoniem:
Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Wat je noemt zijn de beleidskeuzes waarom je een bepaalde werkwijze hanteert. Daarvoor is een AD of zoals je wilt een stukje programmacode niet voor bedoeld.Ik denk niet dat jij ooit AD gebruikt hebt in een wat groter bedrijf met een dynamisch gedrag.
AD is juist erg slecht hierin. Het begint er al mee dat je er geen documentatie in kunt opnemen. Maar op een zeeeeer
beperkt aantal plaatsen is het mogelijk om beschrijvingen op te nemen, en dat betreft dan alleen objecten (zoals accounts
en groepen) en niet de links daartussen.
Bij ieder groeplidmaatschap zou een datum van toevoeging moeten zijn opgenomen en een veld waarin de reden van
toevoeging is opgenomen, en tevens zouden deze lidmaatschappen voorzien moeten kunnen worden van een
einddatum, en een "disabled" vinkje waarmee je ze voor de authorisatie kunt uitschakelen maar wel kunt laten staan
voor toekomstig terugzetten of voor documentatie doeleinden (wie is er ooit lid geweest van deze groep?).
Dat ontbreekt allemaal in AD, primitief systeem!
Maar het is wel de bedoeling dat je die beleidskeuzes kunt vastleggen in de opgeslagen autorisaties, anders kun je later
niet reviewen waarom bepaalde autorisaties erin gekomen zijn, wanneer dat gebeurd is, wie dat gedaan heeft, wie er
om gevraagd heeft, hoe lang ze moeten gelden, etc etc.
Allemaal essientiele informatie om het systeem veilig en schoon te houden.
Dat bij een extern programma neerleggen geeft wel goed aan hoe slecht AD zelf is!
Door Anoniem:
Door The FOSS:En open source software? Dat zou echt het Walhalla zijn!
Omdat? Wat is de toegevoegde waarde er van? Maar als het functioneel aan de requirements voldoet, waarom niet? Maar als een ander product het beter kan doen, waarom daar niet voor gaan? Je kiest het beste product, wat aan je requirements voldoet en dat is verder kijken dat een open/closed source software. Ik kom deze eis heel weinig tegen bij bedrijven.Nogmaals, dat jij het niet tegenkomt bij bedrijven wil nog niet zeggen dat open source geen duidelijke voordelen heeft. Zoals de inzichtelijkheid in wat er onder de motorkap gebeurt en het voorkomen van vendor lock-in.
Door Anoniem:
Maar het is wel de bedoeling dat je die beleidskeuzes kunt vastleggen in de opgeslagen autorisaties, anders kun je later
niet reviewen waarom bepaalde autorisaties erin gekomen zijn, wanneer dat gebeurd is, wie dat gedaan heeft, wie er
om gevraagd heeft, hoe lang ze moeten gelden, etc etc.
Allemaal essientiele informatie om het systeem veilig en schoon te houden.
Dat bij een extern programma neerleggen geeft wel goed aan hoe slecht AD zelf is!
Security Logs op de domain controllers bevat veel van deze informatie. Maar het is wel de bedoeling dat je die beleidskeuzes kunt vastleggen in de opgeslagen autorisaties, anders kun je later
niet reviewen waarom bepaalde autorisaties erin gekomen zijn, wanneer dat gebeurd is, wie dat gedaan heeft, wie er
om gevraagd heeft, hoe lang ze moeten gelden, etc etc.
Allemaal essientiele informatie om het systeem veilig en schoon te houden.
Dat bij een extern programma neerleggen geeft wel goed aan hoe slecht AD zelf is!
Maar beleidskeuze hoort niet in AD getraceerd te worden. Daar is AD niet voor ontworpen.
Wil je meer, dan moet je met andere software aan de slag. Daar is AD niet voor ontwikkeld. Dat maakt niet AD slecht, het is een eigenschap hoe AD werkt.
Voor veel bedrijven is dit ook niet noodzakelijk om in AD te waarborgen. Is dit een requirement, dan heb je hiervoor 3de partij tooling voor nodig.
Azure AD heeft bijvoorbeeld wel veel meer mogelijkheden en eigenschappen hiertoe. En dat is de doorontwikkeling van AD en de future readmap van AD eigenlijk.
@Anoniem 14:30. Ja, een IDM is anders. Maar ik reageerde dan ook op iemand die verklaarde dat AD een krachtig systeem is.
Als je dat roept, zonder de 3rd party tools (UMRA/EDUConnector ea) erbij te noemen dan is dat geklets.
Als je een goed georganiseerd Identity systeem nodig hebt (en een UNI heeft dat) dan is één geïntegreerd systeem dat alles kan een goede investering.Ja, het vereist goede planning, maar inmiddels verwerken wij 40.000 studenten en 4500 medewerkers met 1.2 FTE. 1 FTE is ontwikkeling, 0.2 FTE is dagelijkse bezigheden.
Daarnaast is onze software super goedkoop, relatief gezien; EDU krijgt tot 90% korting.
Downside (en die zijn er ook) is dat expertise behoorlijk duur is. En een IDM beheerder krijg je niet voor minder dan zo'n €4300,= p/m bruto.
Als je dat roept, zonder de 3rd party tools (UMRA/EDUConnector ea) erbij te noemen dan is dat geklets.
Als je een goed georganiseerd Identity systeem nodig hebt (en een UNI heeft dat) dan is één geïntegreerd systeem dat alles kan een goede investering.Ja, het vereist goede planning, maar inmiddels verwerken wij 40.000 studenten en 4500 medewerkers met 1.2 FTE. 1 FTE is ontwikkeling, 0.2 FTE is dagelijkse bezigheden.
Daarnaast is onze software super goedkoop, relatief gezien; EDU krijgt tot 90% korting.
Downside (en die zijn er ook) is dat expertise behoorlijk duur is. En een IDM beheerder krijg je niet voor minder dan zo'n €4300,= p/m bruto.
Door Anoniem: @Anoniem 14:30. Ja, een IDM is anders. Maar ik reageerde dan ook op iemand die verklaarde dat AD een krachtig systeem is.
Als je dat roept, zonder de 3rd party tools (UMRA/EDUConnector ea) erbij te noemen dan is dat geklets.
Valt mee. AD kan nog steeds het meeste. Ik heb ervaring met UMRA maar ook met IDM oplossingen of custombuild tooling. Als je dat roept, zonder de 3rd party tools (UMRA/EDUConnector ea) erbij te noemen dan is dat geklets.
Zijn allemaal mogelijkheden die bovenop AD geïmplementeerd kunnen worden.
Door Anoniem:
Wil je meer, dan moet je met andere software aan de slag. Daar is AD niet voor ontwikkeld. Dat maakt niet AD slecht, het is een eigenschap hoe AD werkt.
Voor veel bedrijven is dit ook niet noodzakelijk om in AD te waarborgen. Is dit een requirement, dan heb je hiervoor 3de partij tooling voor nodig.
Wil je meer, dan moet je met andere software aan de slag. Daar is AD niet voor ontwikkeld. Dat maakt niet AD slecht, het is een eigenschap hoe AD werkt.
Voor veel bedrijven is dit ook niet noodzakelijk om in AD te waarborgen. Is dit een requirement, dan heb je hiervoor 3de partij tooling voor nodig.
Het is Microsoft kennelijk goed gelukt om de community er van te overtuigen dat je voor van alles en nog wat
"3rd party tooling" nodig hebt die veelal een vermogen kost om te kopen en implementeren. Zo goed zelfs dat de
experts het al naar voren brengen alsof het de normaalste zaak van de wereld is dat een systeem wordt geleverd wat
wel allerlei onnodige shit bevat maar niet de noodzakelijke basisfunctionaliteit.
Het is natuurlijk allemaal "goed voor de economie" en Microsoft weet dat als ze allemaal half-af producten leveren er
een hele industrie van kan bestaan die producten aan te vullen, en dat die industrie op hun beurt weer zorgt voor de
aanvoer van klanten richting Microsoft (omdat die extra producten dan weer "alleen op Windows" werken en dus de
eindgebruiker dwingen richting Windows in plaats van een ander systeem).
Maar dat wil nog niet zeggen dat het allemaal "een goed systeem" is. Er zijn zat bedrijven die helemaal niet van die
complexe oplossingen nodig hebben of willen hebben (of in ieder geval niet het geld er voor hebben) maar die wel
uitstekend geholpen zouden zijn bij een wat betere AD waarmee je met een 200 man aan personeel nog enigszins
een overzicht hebt over wie er in welke groepen zitten en waarom dat ook weer was. En daar ontbreekt het nogal aan.
Door The FOSS:
Nogmaals, dat jij het niet tegenkomt bij bedrijven wil nog niet zeggen dat open source geen duidelijke voordelen heeft. Zoals de inzichtelijkheid in wat er onder de motorkap gebeurt en het voorkomen van vendor lock-in.
Iets waar geen budget nog capaciteit voor is, geen verhaal via een contract of een service overeenkomst vind jij dat dat voordelen biedt. Dat valt in de categorie wereldvreemd. De top wenst het voor zo min mogelijk geld / mensen net voldoende geregeld zien. Dan krijg je ook nog eens met OSS een lockin als er geen alternatieven zijn. Probeer het eens zonder Linux.Nogmaals, dat jij het niet tegenkomt bij bedrijven wil nog niet zeggen dat open source geen duidelijke voordelen heeft. Zoals de inzichtelijkheid in wat er onder de motorkap gebeurt en het voorkomen van vendor lock-in.
02-01-2020, 11:13 door
The FOSS
Door karma4:
Door The FOSS:
Nogmaals, dat jij het niet tegenkomt bij bedrijven wil nog niet zeggen dat open source geen duidelijke voordelen heeft. Zoals de inzichtelijkheid in wat er onder de motorkap gebeurt en het voorkomen van vendor lock-in.
Iets war geen budget nog capaciteit voor is, geen verhaal via een contract of een service overeenkomst vind jij dat dat voordelen biedt. Dat valt in de categorie wereldvreemd. De top wenst het voor zo min mogelijk geld / mensen net voldoende geregeld zien. Dan krijg je ook nog eens met OSS een lockin als er geen alternatieven zijn. Probeer het eens zonder Linux.Nogmaals, dat jij het niet tegenkomt bij bedrijven wil nog niet zeggen dat open source geen duidelijke voordelen heeft. Zoals de inzichtelijkheid in wat er onder de motorkap gebeurt en het voorkomen van vendor lock-in.
Zogenaamd goedkope en closed source oplossingen met vendor lock-in kunnen in de toekomst heel veel geld gaan kosten. Als je de broncode hebt is een alternatief zo gemaakt indien nodig. Kijk maar naar LibreOffice, wat snel is ontstaan toen OpenOffice minder open dreigde te worden.
02-01-2020, 11:31 door
karma4
Door Anoniem:
Maar het is wel de bedoeling dat je die beleidskeuzes kunt vastleggen in de opgeslagen autorisaties, anders kun je later
niet reviewen waarom bepaalde autorisaties erin gekomen zijn, wanneer dat gebeurd is, wie dat gedaan heeft, wie er
om gevraagd heeft, hoe lang ze moeten gelden, etc etc.
Allemaal essientiele informatie om het systeem veilig en schoon te houden.
Dat bij een extern programma neerleggen geeft wel goed aan hoe slecht AD zelf is!
De logs etc zijn allemaal in het technische beheerstuk aanwezig. Zover ik weet af te scheiden van de dagelijkse bediener.Maar het is wel de bedoeling dat je die beleidskeuzes kunt vastleggen in de opgeslagen autorisaties, anders kun je later
niet reviewen waarom bepaalde autorisaties erin gekomen zijn, wanneer dat gebeurd is, wie dat gedaan heeft, wie er
om gevraagd heeft, hoe lang ze moeten gelden, etc etc.
Allemaal essientiele informatie om het systeem veilig en schoon te houden.
Dat bij een extern programma neerleggen geeft wel goed aan hoe slecht AD zelf is!
Dat je het beleid wat op hoger niveau vastgelegd hoort te zijn wil beleggen als taak bij de dagelijkse beheerder is een flater van je welste. Die denkbeelden zijn nu juist de oorzaak van waarom het zo slecht neergezet wordt.
Daarbij, doordachte functiescheiding is een basis eis. Je toont met je gemis aan beleidsinzicht nu net waar het mis gaat.
02-01-2020, 11:31 door
Erik van Straten
Het probleem van het moderne type ransomware is dat het in daarvoor kwetsbare omgevingen lukt om één of meer accounts "over te nemen" met dusdanig hoge privileges dat daarmee op veel of alle servers kan worden ingelogd en gebruikersbestanden kunnen worden versleuteld.
In deze context zitten serieuze lezers niet te wachten op de zinloze macho-discussie "mijn AD/AD-alternatief is beter" (want het is OSS of juist niet) zonder dat met ransomware-gerelateerde argumenten te onderbouwen.
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
In deze context zitten serieuze lezers niet te wachten op de zinloze macho-discussie "mijn AD/AD-alternatief is beter" (want het is OSS of juist niet) zonder dat met ransomware-gerelateerde argumenten te onderbouwen.
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
02-01-2020, 11:37 door
karma4
Door The FOSS:
Zogenaamd goedkope en closed source oplossingen met vendor lock-in kunnen in de toekomst heel veel geld gaan kosten. Als je de broncode hebt is een alternatief zo gemaakt indien nodig. Kijk maar naar LibreOffice, wat snel is ontstaan toen OpenOffice minder open dreigde te worden.
Iets door kopiëren wat je niet echt begrijpt kan wel iets tastbaars leveren maar het veranderd er weinig aan dat je het nog steeds niet begrijpt. Daarmee is het kunnen zien van de code totaal niet belangrijk. Je moeten doorzien met het doel (output) en wat je als invoer kan gebruiken. Heel basaal, de lessen van Dijkstra richten zich op dat vlak. Dat moet je ook snappen. Zogenaamd goedkope en closed source oplossingen met vendor lock-in kunnen in de toekomst heel veel geld gaan kosten. Als je de broncode hebt is een alternatief zo gemaakt indien nodig. Kijk maar naar LibreOffice, wat snel is ontstaan toen OpenOffice minder open dreigde te worden.
Je bewering met open office - libre office ziet er ook weer eens naast. Het waren de ontwikkelaars zelf die niet gratis en voor niets een Oracle commercieel product wilden voeren.
02-01-2020, 11:41 door
karma4
Door Erik van Straten:…..
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
Je hebt helemaal gelijk. Besef je dat je dan mijn stokpaardje met privileged account management en een Risico Impact Analyes met wat daaruit rolt terecht komt? Het zou denk al helpen om aparte lijnen met goede beveiligingsstrategiën als een basis opzet en aandachtspunten te hebben.
02-01-2020, 12:04 door
Tintin and Milou
Door Erik van Straten: Het probleem van het moderne type ransomware is dat het in daarvoor kwetsbare omgevingen lukt om één of meer accounts "over te nemen" met dusdanig hoge privileges dat daarmee op veel of alle servers kan worden ingelogd en gebruikersbestanden kunnen worden versleuteld.
In deze context zitten serieuze lezers niet te wachten op de zinloze macho-discussie "mijn AD/AD-alternatief is beter" (want het is OSS of juist niet) zonder dat met ransomware-gerelateerde argumenten te onderbouwen.
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
In deze context zitten serieuze lezers niet te wachten op de zinloze macho-discussie "mijn AD/AD-alternatief is beter" (want het is OSS of juist niet) zonder dat met ransomware-gerelateerde argumenten te onderbouwen.
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
Microsoft heeft hiervoor een aantal security maatregelen bedacht:
Active Directory administrative tier model https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material
Dit lost al een hoop security issues op, en zou eigenlijk de basis van alle implementaties moeten zijn. De universiteit heeft hier waarschijnlijk erg op gefaald.
Dit kan samen met Privileged Access Workstations gebruikt worden.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations
Het niet laten opslaan van wachtwoorden op werkstations lost ook een heel hoop security issues op: Network access: Do not allow storage of passwords and credentials for network authentication
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication
(note: Even goed nadenken over Laptops)
* Windows 10 Device Guard and Credential Guard
https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/
Extra toevoeging voor security:
* Group Managed Service Accounts Overview https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
* Local Administrator Password Solution (LAPS) https://www.microsoft.com/en-us/download/details.aspx?id=46899
* Indien Azure AD gebruikt wordt, Privileged Identity Management (PIM) implementeren
https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
* Fine-Grained Password Policies implementeren voor ALLE Privileged accounts.
https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/
* Indien local admins nodig zijn op een werkstation, dit specifiek imiteren tot het werkstation voor 1 account, op basis van AD groepen.
Andere security maatregelen:
* Service accounts specifiek per applicatie en vooral per server limiteren en zorgen dat deze nooit ergens interactief kunnen inloggen op een andere machine.
* Security logs goed analyseren en bewaren.
* Rechten finetunen per applicatie.
* DHCP onder een service account inrichten.
* Read Only domain controllers inrichten voor untrusted netwerken.
* NAC Implementatie inrichten.
* Segmentatie van je netwerk met strikte specifieke firewall regels
* Azure AD MFA gebruiken.
* Azure AD Risk Policies implementeren https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies
02-01-2020, 12:46 door
Erik van Straten
@Tintin and Milou: TOP! Dat bedoel ik!
02-01-2020, 14:13 door
The FOSS
Door Erik van Straten: @Tintin and Milou: TOP! Dat bedoel ik!
Ja maar ik verwerp het suggestieve Dit lost al een hoop security issues op, en zou eigenlijk de basis van alle implementaties moeten zijn. De universiteit heeft hier waarschijnlijk erg op gefaald.!
Door Tintin and Milou:
Microsoft heeft hiervoor een aantal security maatregelen bedacht:
Active Directory administrative tier model https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material
Dit lost al een hoop security issues op, en zou eigenlijk de basis van alle implementaties moeten zijn. De universiteit heeft hier waarschijnlijk erg op gefaald.
Dit kan samen met Privileged Access Workstations gebruikt worden.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations
Het niet laten opslaan van wachtwoorden op werkstations lost ook een heel hoop security issues op: Network access: Do not allow storage of passwords and credentials for network authentication
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication
(note: Even goed nadenken over Laptops)
* Windows 10 Device Guard and Credential Guard
https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/
Extra toevoeging voor security:
* Group Managed Service Accounts Overview https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
* Local Administrator Password Solution (LAPS) https://www.microsoft.com/en-us/download/details.aspx?id=46899
* Indien Azure AD gebruikt wordt, Privileged Identity Management (PIM) implementeren
https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
* Fine-Grained Password Policies implementeren voor ALLE Privileged accounts.
https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/
* Indien local admins nodig zijn op een werkstation, dit specifiek imiteren tot het werkstation voor 1 account, op basis van AD groepen.
Andere security maatregelen:
* Service accounts specifiek per applicatie en vooral per server limiteren en zorgen dat deze nooit ergens interactief kunnen inloggen op een andere machine.
* Security logs goed analyseren en bewaren.
* Rechten finetunen per applicatie.
* DHCP onder een service account inrichten.
* Read Only domain controllers inrichten voor untrusted netwerken.
* NAC Implementatie inrichten.
* Segmentatie van je netwerk met strikte specifieke firewall regels
* Azure AD MFA gebruiken.
* Azure AD Risk Policies implementeren https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies
Door Erik van Straten: Het probleem van het moderne type ransomware is dat het in daarvoor kwetsbare omgevingen lukt om één of meer accounts "over te nemen" met dusdanig hoge privileges dat daarmee op veel of alle servers kan worden ingelogd en gebruikersbestanden kunnen worden versleuteld.
In deze context zitten serieuze lezers niet te wachten op de zinloze macho-discussie "mijn AD/AD-alternatief is beter" (want het is OSS of juist niet) zonder dat met ransomware-gerelateerde argumenten te onderbouwen.
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
In deze context zitten serieuze lezers niet te wachten op de zinloze macho-discussie "mijn AD/AD-alternatief is beter" (want het is OSS of juist niet) zonder dat met ransomware-gerelateerde argumenten te onderbouwen.
Graag zou ik (en vermoedelijk andere geïnteresseerden) in eerste instantie lezen hoe je AD/AD-achtige oplossingen zo configureert en benadert dat het voor malware veel lastiger (zo niet onmogelijk) is om toegang tot highly-privileged accounts te verkrijgen. En alleen als een alternatief systeem, aantoonbaar en met relevante argumenten onderbouwd, duidelijk beter is op dit punt (en/of andere beheeraspecten), zijn wij -naar serieuze oplossingen zoekende- lezers daarin geïnteresseerd.
Begin lekker je eigen flame-war draad als je niks beters te doen hebt dan je testosteron de vrije loop laten...
Microsoft heeft hiervoor een aantal security maatregelen bedacht:
Active Directory administrative tier model https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material
Dit lost al een hoop security issues op, en zou eigenlijk de basis van alle implementaties moeten zijn. De universiteit heeft hier waarschijnlijk erg op gefaald.
Dit kan samen met Privileged Access Workstations gebruikt worden.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations
Het niet laten opslaan van wachtwoorden op werkstations lost ook een heel hoop security issues op: Network access: Do not allow storage of passwords and credentials for network authentication
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication
(note: Even goed nadenken over Laptops)
* Windows 10 Device Guard and Credential Guard
https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/
Extra toevoeging voor security:
* Group Managed Service Accounts Overview https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
* Local Administrator Password Solution (LAPS) https://www.microsoft.com/en-us/download/details.aspx?id=46899
* Indien Azure AD gebruikt wordt, Privileged Identity Management (PIM) implementeren
https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
* Fine-Grained Password Policies implementeren voor ALLE Privileged accounts.
https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/
* Indien local admins nodig zijn op een werkstation, dit specifiek imiteren tot het werkstation voor 1 account, op basis van AD groepen.
Andere security maatregelen:
* Service accounts specifiek per applicatie en vooral per server limiteren en zorgen dat deze nooit ergens interactief kunnen inloggen op een andere machine.
* Security logs goed analyseren en bewaren.
* Rechten finetunen per applicatie.
* DHCP onder een service account inrichten.
* Read Only domain controllers inrichten voor untrusted netwerken.
* NAC Implementatie inrichten.
* Segmentatie van je netwerk met strikte specifieke firewall regels
* Azure AD MFA gebruiken.
* Azure AD Risk Policies implementeren https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies
nou nou.... kunnen die applicatie service accounts niet default al ieder met eigen credentials draaien dan ? En die rechten fine tunen, is dat dan niet al voor je gedaan zodra je het OS op de disk zet? Ik ben namelijk met RHEL wel dit soort defaults gewend en dan heb ik daar bovenop nog eens een SELinux laag met policies out-of-the-box zonder dat ik eerst een klik safari hoef te doen.
en als je dat allemaal gedaan hebt; en je beheerder is eventjes overloaded of niet wakker en typt een passwd in op een machine waarbij een keylogger actief is. wat heb je dan aan deze slot-grachten?
ik denk dat je een hele belangrijke laatste stap in je verhaal vergeet:
configuration management en automatic deployment a la ansible of puppet dat zodra je vlug from scratch servers moet redeployen (ivm cryptoware oid) je dat in 10 min van start tot finished en operationeel gedaan krijgt.
kijk de werkelijke pijn van een ransomware attack is de restore tijd en de menselijkijke kosten daarbij. die maken al die uren van defences opwerpen teniet. je moet dus in je risico analyse ook een plan b hebben die ervan uit gaat dat er een keertje een gebruiker op een linkje per ongeluk zal klikken oid en dat je omgeving snel terug is en in werkende staat komt. dat is waar het in maastricht dus mis is gegaan lijkt mij.
02-01-2020, 14:48 door
Tintin and Milou
Door The FOSS:
Ja maar ik verwerp het suggestieve Dit lost al een hoop security issues op, en zou eigenlijk de basis van alle implementaties moeten zijn. De universiteit heeft hier waarschijnlijk erg op gefaald.!
Als de universiteit dit geïmplementeerd had, hadden de domain controllers, Echange servers en dhcp nooit geïnfecteerd kunnen worden. Dit zijn gewoon feiten. Welke ook nog eens bij een Microsoft Audit naar voren komen. Door Erik van Straten: @Tintin and Milou: TOP! Dat bedoel ik!
Ja maar ik verwerp het suggestieve Dit lost al een hoop security issues op, en zou eigenlijk de basis van alle implementaties moeten zijn. De universiteit heeft hier waarschijnlijk erg op gefaald.!
Het lost gewoon heel veel van security issues op, maar is ook vrij basis, maar ook weinig geïmplementeerd. Gewoon server en werkstation beheer accounts splitten en zorgen dat ze nooit misbruikt kunnen worden.
Maar het lost natuurlijk niet alle security issues op. Maar is wel 1 van de basis security maatregelen die een bedrijf zou moeten implementeren. Vaak is dit ook zonder een hoop impact te implementeren.
"Als de universiteit dit geïmplementeerd had, hadden de domain controllers, Echange servers en dhcp nooit geïnfecteerd kunnen worden. Dit zijn gewoon feiten. Welke ook nog eens bij een Microsoft Audit naar voren komen."
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben: snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben: snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
Door Anoniem: "Als de universiteit dit geïmplementeerd had, hadden de domain controllers, Echange servers en dhcp nooit geïnfecteerd kunnen worden. Dit zijn gewoon feiten. Welke [sic DIE] ook nog eens bij een Microsoft Audit naar voren komen."
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben: snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben: snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
Inderdaad want er staat nota bene - 1e van de Tintin and Milou links:
Note
The tiers also serve as a basic prioritization mechanism for protecting administrative assets, but it is important to consider that an attacker with control of all assets at any tier can access most or all business assets.
Dus het is gewoon een gelaagde opzet en als men toegang tot een laag krijgt dan heeft men alles in die laag voor het grijpen. Je weet niet wat er in Maastricht is gebeurd en of er bv. accounts in kritische lagen zijn gespearphished. Het is - naar verluidt - clop ransomware maar hoe die in bepaalde kritische lagen terecht is gekomen, dat is onbekend.
03-01-2020, 10:46 door
Erik van Straten
Door The FOSS: Dus het is gewoon een gelaagde opzet en als men toegang tot een laag krijgt dan heeft men alles in die laag voor het grijpen.
Naast dat je de aanvaller moet vertragen (o.a. doordat je zorgt dat niet elke aanvalstechniek meteen werkt), is het essentieel dat je diens aanwezigheid zo snel als mogelijk detecteert en dergelijke rotte appels ASAP verwijdert.In mijn tijd als technicus in een vakgroep aan de TU Delft (tot 2004) had ik voor tests een Linux PC in mijn werkkamer waarop iptables alle connectiepogingen logde (dit was geen honeypot, d.w.z. het systeem adverteerde op geen enkele manier dat er wat te halen viel, en behalve logs viel er ook niks te halen). Alle TU Delft PC's hadden toen nog publieke IP-adressen en er was nauwelijks sprake van firewalling (uitgaand verkeer naar poort 25 en ingaand naar 139 en 445 werden geblokkeerd, maar wellicht mede doordat de grotere studentenhuizen onder "intern" vielen, tierden wormen als blaster, nimda en nachi welig op het netwerk). Als een PC met een TU-Delft IP-adres verbinding probeerde te maken met mijn Linux bakkie, was de kans nagenoeg 100% dat het proberende systeem gehacked was of een te nieuwsgierige student zat te port-scannen. Vaak betrof het gehackte Windows (NT4/2000) systemen, maar ik heb ook heel veel gehackte Linux/Unix systemen gezien die op ongebruikelijke poorten naar ftp-servers zochten of dachten via telnet of ssh binnen te kunnen komen. Met mijn Linux-bakkie en andere -passief- netwerkverkeer loggende PCtjes heb ik ook verschillende ARP-spoofing attacks gedetecteerd. Met deze poor-mans-SIEM heb ik heel veel gecompromitteerde systemen "uit de lucht" laten halen.
In mijn carrière daarna heb ik heel veel netwerken gezien waar duidelijk niemand iets logde, of in elk geval nergens naar keek (want als ik actief scande, gebeurde er niks). Natuurlijk staat loggen op gespannen voet met de privacy, maar van die privacy blijft nog veel minder over als een of meer buitenstaanders heer en meester zijn op het netwerk van jouw opdracht- of werkgever.
M.a.w. ook als je niet het budget hebt voor een SOC en/of een SIEM: zorg dat je logt en onderzoek die logs zo vaak mogelijk op anomalies. Hoe beter je "jouw" netwerk leert kennen, hoe sneller je afwijkend gedrag herkent. In elk geval is het goed als je je gaat ergeren aan zinloos (en risicovol) lawaai zoals WPAD requests, master browser oorlogen, LLNBR en NBT onzin. Want die legacy troep uitzetten vermindert niet alleen de herrie op je netwerk, het verkleint ook de risico's op gecompromitteerde systemen. Daarna is er minder bos waardoor je (omvallende) bomen sneller ziet.
Door Anoniem: "Als de universiteit dit geïmplementeerd had, hadden de domain controllers, Echange servers en dhcp nooit geïnfecteerd kunnen worden. Dit zijn gewoon feiten. Welke ook nog eens bij een Microsoft Audit naar voren komen."
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben:
Je moet altijd een backup plan hebben. Dat lost een tiering model ook niet op. ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben:
snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
Leuke sales (kroeg, verjaardag) praat. Maar de data is bij de meeste servers van belang. Indien je stateless servers hebt, dan werkt je advies inderdaad redelijk goed, maar heeft nog steeds veel afhankelijkheden.
Je moet de juiste procedures hebben. Maar om die te activeren moet je eerst goed weten wat er fout is/was gegaan, en dat je schoon kunt beginnen.
03-01-2020, 11:51 door
Tintin and Milou
Door The FOSS:
Inderdaad want er staat nota bene - 1e van de Tintin and Milou links:
Note
The tiers also serve as a basic prioritization mechanism for protecting administrative assets, but it is important to consider that an attacker with control of all assets at any tier can access most or all business assets.
Dus het is gewoon een gelaagde opzet en als men toegang tot een laag krijgt dan heeft men alles in die laag voor het grijpen. Je weet niet wat er in Maastricht is gebeurd en of er bv. accounts in kritische lagen zijn gespearphished. Het is - naar verluidt - clop ransomware maar hoe die in bepaalde kritische lagen terecht is gekomen, dat is onbekend.
Er zouden dan nog steeds 3 accounts geïnfecteerd moeten worden. Want je kunt in het tiering model nooit van laag 0 naar laag 1, maar ook van laag 2 niet naar laag 1. De rechten op het systeem laten dit niet toe.Door Anoniem: "Als de universiteit dit geïmplementeerd had, hadden de domain controllers, Echange servers en dhcp nooit geïnfecteerd kunnen worden. Dit zijn gewoon feiten. Welke [sic DIE] [sic zucht] ook nog eens bij een Microsoft Audit naar voren komen."
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben: snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
ik zou daar niet zo zeker van zijn en ALTIJD een plan B hebben: snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
Inderdaad want er staat nota bene - 1e van de Tintin and Milou links:
Note
The tiers also serve as a basic prioritization mechanism for protecting administrative assets, but it is important to consider that an attacker with control of all assets at any tier can access most or all business assets.
Dus het is gewoon een gelaagde opzet en als men toegang tot een laag krijgt dan heeft men alles in die laag voor het grijpen. Je weet niet wat er in Maastricht is gebeurd en of er bv. accounts in kritische lagen zijn gespearphished. Het is - naar verluidt - clop ransomware maar hoe die in bepaalde kritische lagen terecht is gekomen, dat is onbekend.
Een Tier 0 account kan dus nooit op een server inloggen die als Tier 1 gedefinieerd is. En een tier 1 account kan nooit inloggen op een server van Tier 0. Dit is ook voor beheerservers zo ingericht.
Vanuit dit model is er dus altijd een rechten en account afscherming.
En een tier 0 account, heb je niet zo vaak nodig voor je normale beheer werkzaamheden, want deze zijn helemaal geschermd. Deze benodigde rechten zijn normaal gedelegeerd aan een (specifiek) Tier 1 account.
Maar het is nog steeds niet de holy grail. Segmentatie en patch beheer zijn ook belangrijke punten waar je over na moet denken. Die hadden hier ook de nodige security layers toegevoegd. Of dit de uitbraak voorkomen had, is altijd koffiedik kijken. Achteraf......
Dat staat helemaal lost van een goede backup (en disaster recovery) plan. Die heb je altijd nodig.
Dat krijg je ervan als je IT diensten gaat outsourcen en overal op gaat besparen
IT security en IT in het algemeen hou je beter INHOUSE daar kunnen de mensen van onderneming vliegtuigbouwer ASCO wel van meespreken. Die zijn nu 180 miljoen euro armer hebben nog steeds niet betaald.
En juist zoals bij Universiteit Maastricht draaide het bij ASCO om geld
Asco wou namelijk niet investeren in IT SECURITY en heeft enkele jaren geleden besloten om hun hele IT platform te outsourcen naar bedrijven zoals CTG in Luxemburg en het outsource bedrijf CPL in Dublin Ierland.
Besparen besparen nog een keertje besparen
Bij CTG en CPL werken ook een hele hoop technische mensen, alleen aan minimale voorwaarden tijdelijke contracten en de collegaatjes worden verwacht extreem flexibel te zijn met als gevolg veel gedemotiveerde collegaatjes.
En dan worden er foutjes gemaakt wat verwacht je.
IT security en IT in het algemeen hou je beter INHOUSE daar kunnen de mensen van onderneming vliegtuigbouwer ASCO wel van meespreken. Die zijn nu 180 miljoen euro armer hebben nog steeds niet betaald.
En juist zoals bij Universiteit Maastricht draaide het bij ASCO om geld
Asco wou namelijk niet investeren in IT SECURITY en heeft enkele jaren geleden besloten om hun hele IT platform te outsourcen naar bedrijven zoals CTG in Luxemburg en het outsource bedrijf CPL in Dublin Ierland.
Besparen besparen nog een keertje besparen
Bij CTG en CPL werken ook een hele hoop technische mensen, alleen aan minimale voorwaarden tijdelijke contracten en de collegaatjes worden verwacht extreem flexibel te zijn met als gevolg veel gedemotiveerde collegaatjes.
En dan worden er foutjes gemaakt wat verwacht je.
03-01-2020, 19:33 door
The FOSS
Door Erik van Straten:
Door The FOSS: Dus het is gewoon een gelaagde opzet en als men toegang tot een laag krijgt dan heeft men alles in die laag voor het grijpen.
Naast dat je de aanvaller moet vertragen (o.a. doordat je zorgt dat niet elke aanvalstechniek meteen werkt), is het essentieel dat je diens aanwezigheid zo snel als mogelijk detecteert en dergelijke rotte appels ASAP verwijdert.Zodat ze gewoon de kans niet krijgen om rond te kijken en rottigheid uit te halen.
Door Erik van Straten: In mijn tijd als technicus in een vakgroep aan de TU Delft (tot 2004) had ik voor tests een Linux PC in mijn werkkamer waarop iptables alle connectiepogingen logde (dit was geen honeypot, d.w.z. het systeem adverteerde op geen enkele manier dat er wat te halen viel, en behalve logs viel er ook niks te halen). Alle TU Delft PC's hadden toen nog publieke IP-adressen en er was nauwelijks sprake van firewalling (uitgaand verkeer naar poort 25 en ingaand naar 139 en 445 werden geblokkeerd, maar wellicht mede doordat de grotere studentenhuizen onder "intern" vielen, tierden wormen als blaster, nimda en nachi welig op het netwerk). Als een PC met een TU-Delft IP-adres verbinding probeerde te maken met mijn Linux bakkie, was de kans nagenoeg 100% dat het proberende systeem gehacked was of een te nieuwsgierige student zat te port-scannen. Vaak betrof het gehackte Windows (NT4/2000) systemen, maar ik heb ook heel veel gehackte Linux/Unix systemen gezien die op ongebruikelijke poorten naar ftp-servers zochten of dachten via telnet of ssh binnen te kunnen komen. Met mijn Linux-bakkie en andere -passief- netwerkverkeer loggende PCtjes heb ik ook verschillende ARP-spoofing attacks gedetecteerd. Met deze poor-mans-SIEM heb ik heel veel gecompromitteerde systemen "uit de lucht" laten halen.
Dat heb ik zelfs nu nog op mijn machine: een terminalvenster met een tail van de systemlog (journalctl -f). Verbazend - voor mij in ieder geval - hoe snel er aan de deur wordt gerammeld als je een poort openzet naar internet.
Door Erik van Straten: In mijn carrière daarna heb ik heel veel netwerken gezien waar duidelijk niemand iets logde, of in elk geval nergens naar keek (want als ik actief scande, gebeurde er niks). Natuurlijk staat loggen op gespannen voet met de privacy, maar van die privacy blijft nog veel minder over als een of meer buitenstaanders heer en meester zijn op het netwerk van jouw opdracht- of werkgever.
Loggen is op de goede manier een heel klein beetje privacy inleveren, vind ik.
Door Erik van Straten: M.a.w. ook als je niet het budget hebt voor een SOC en/of een SIEM: zorg dat je logt en onderzoek die logs zo vaak mogelijk op anomalies. Hoe beter je "jouw" netwerk leert kennen, hoe sneller je afwijkend gedrag herkent. In elk geval is het goed als je je gaat ergeren aan zinloos (en risicovol) lawaai zoals WPAD requests, master browser oorlogen, LLNBR en NBT onzin. Want die legacy troep uitzetten vermindert niet alleen de herrie op je netwerk, het verkleint ook de risico's op gecompromitteerde systemen. Daarna is er minder bos waardoor je (omvallende) bomen sneller ziet.
Logs scannen op anomalieën zou een tweede natuur moeten zijn. Ruis in de logs is ontzettend irritant en als je niet oppast zie je inderdaad door de bomen het bos niet meer. Of je moet er op z'n minst veel meer moeite voor doen en de kans om iets te missen wordt daardoor groter.
Door The FOSS:
Logs scannen op anomalieën zou een tweede natuur moeten zijn. Ruis in de logs is ontzettend irritant en als je niet oppast zie je inderdaad door de bomen het bos niet meer. Of je moet er op z'n minst veel meer moeite voor doen en de kans om iets te missen wordt daardoor groter.
Logs scannen op anomalieën zou een tweede natuur moeten zijn. Ruis in de logs is ontzettend irritant en als je niet oppast zie je inderdaad door de bomen het bos niet meer. Of je moet er op z'n minst veel meer moeite voor doen en de kans om iets te missen wordt daardoor groter.
Een goed dashboard in b.v. Splunk kan daar echt het verschil maken.
snelle correcte gescripte uitrollen van kritieke servers die in productie zijn waarbij de scripting gecentraliseerd is en met cryto hashes tegen wijzigingen gemonitord worden en met 2FA beheerd moeten worden. daar is genoeg tooling voor tegenwoordig.
Leuke sales (kroeg, verjaardag) praat. Maar de data is bij de meeste servers van belang. Indien je stateless servers hebt, dan werkt je advies inderdaad redelijk goed, maar heeft nog steeds veel afhankelijkheden.
Je moet de juiste procedures hebben. Maar om die te activeren moet je eerst goed weten wat er fout is/was gegaan, en dat je schoon kunt beginnen.
dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
Door The FOSS: Ruis in de logs is ontzettend irritant en als je niet oppast zie je inderdaad door de bomen het bos niet meer. Of je moet er op z'n minst veel meer moeite voor doen en de kans om iets te missen wordt daardoor groter.
In aanvulling daarop: geavanceerde aanvallers kunnen communicatie verstoppen in "ruis" (ogenschijnlijk normale netwerkpakketjes zoals van DNS of interne communicatie met andere gehackte systemen in bijv. ARP pakketjes).Daarbij geven blêrende computers zeer veel informatie prijs (ook aan -nog niet detecteerbare- passieve luisteraars) waarmee vaak in korte tijd een mooie netwerkmap kan worden gemaakt van aangesloten devices, gebruikte hardware en OS alsmede info of bijv. Dropbox en soms welke virusscanner(s) wordt(/worden) gebruikt, alsmede of en wanneer devices worden uit/aangezet. Deze informatie komt natuurlijk uitstekend van pas bij het plannen van vervolgaanvallen. Last but not least kunnen protocollen als LLMNR en WPAD eenvoudig voor MitM aanvallen worden misbruikt door tools als Responder.
Op een zo stil mogelijk netwerk kun je (als beheerder) langer loggen bij een gegeven schijfgrootte, en die info kan enorm helpen bij onderzoek na incidenten - naast dat aanvallers hun presentie eerder kenbaar zullen maken indien passief luisteren onvoldoende oplevert.
Kortom, een rustig netwerk is vanuit security-oogpunt zeer wenselijk; filteren (bijv. met Splunk of ELK stack) kan er altijd toe leiden dat je relevante informatie niet te zien krijgt.
Door Anoniem: dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
Fijn die kracht, maar als een aanvaller credentials bemachtigt waarmee je aan dat soort touwtjes kunt trekken, kunnen deze online tools ook tegen je worden ingezet. Met name als data-back-ups met dit soort tools kunnen worden teruggezet, bestaat de kans dat die back-ups met dezelfde credentials kunnen worden gewist of met junk worden overschreven.Door Anoniem: dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
https://docs.cloud.oracle.com/iaas/Content/API/SDKDocs/ansiblegetstarted.htm Het is de kracht van de grote commerciëlen, die brengen het alsof je met een tool de juiste configuratiekeuzes automatisch aangeleverd krijgt.Het werkelijke probleem is de goede keuzes zien te maken voor de configuraties en een schone installatie.
Daarna moet alle inhoud er in gezet dan wel mee verbonden worden.
Door Erik van Straten: ..
Fijn die kracht, maar als een aanvaller credentials bemachtigt waarmee je aan dat soort touwtjes kunt trekken, kunnen deze online tools ook tegen je worden ingezet. Met name als data-back-ups met dit soort tools kunnen worden teruggezet, bestaat de kans dat die back-ups met dezelfde credentials kunnen worden gewist of met junk worden overschreven.
Vanuit een schone installatie, offline media en een verse dan afgesloten console (tier1 tin tin milou) opbouwen en controleren. Reken op enkele dagen, daarna de inhoudelijke zaken zoals alle gebruikers en de data. Het zijn de trajecten met de migraties waar gewoonlijk veel tijd voor staat,Fijn die kracht, maar als een aanvaller credentials bemachtigt waarmee je aan dat soort touwtjes kunt trekken, kunnen deze online tools ook tegen je worden ingezet. Met name als data-back-ups met dit soort tools kunnen worden teruggezet, bestaat de kans dat die back-ups met dezelfde credentials kunnen worden gewist of met junk worden overschreven.
Wat ooit een heel eind op weg was en werkbaar leek is het opschonen van de onnodige afhankelijkheden en dan het resultaat van de installatie als image zien door te zetten. Dan nog moet je keuzes gaan maken in de aanpak. De meest kritische productiesystemen eerst. Ontwikkelomgevingen kunnen veel later. Als er veel ontwikkelaars dan wel analisten zijn (denk aan vele honderden), dan heb je het nog over een grote schadepost.
Door Anoniem:
dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
Deze snap ik zeker wel. Werkt heel goed in een stateless omgeving, of inderdaad zoals in een kubernetes oplossing. Maar laat daar nu net de meeste omgevingen niet mee werken of niet voor opgezet zijn. dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
Mijn servers kan ik daarmee zo goed als niet mee uitrollen. Afgezien een stateless server, maar daar heb ik er niet zoveel van.
Nu is het natuurlijk mogelijk om de complete omgeving hiervoor kunnen ombouwen. Maar dan hebben we het over jaren werk, tegen welk voordeel? Ofwel niet haalbaar/betaalbaar.
Leuk om de basis mee neer te zetten, maar ik zal nog steeds mijn Databases moeten restoren. Maar alles is te scripten natuurlijk zodat het gebruikt kan worden. Of het alleen dat het allemaal waard, is een tweede.
Trouwens wel zojuist een leuke SPOF gemaakt, waar je ook even goed over moet nadenken.
Maar zoals zo vaak, technisch is het allemaal mogelijk, of je er wat aan hebt, is alleen tweede. Daarom de opmerking: sales (kroeg, verjaardag) praat.
"Fijn die kracht, maar als een aanvaller credentials bemachtigt waarmee je aan dat soort touwtjes kunt trekken, kunnen deze online tools ook tegen je worden ingezet. Met name als data-back-ups met dit soort tools kunnen worden teruggezet, bestaat de kans dat die back-ups met dezelfde credentials kunnen worden gewist of met junk worden overschreven."
Zie voor je: een server die automatic deployment en configuratie doet van je meest belangrijke onderdelen in je netwerk, zeg je exchange omgeving, je AD (of LDAP od IDM server), de front web site van de uni en de studenten portals bijv. Die deployment server kan alleen beheert worden via 2FA (yubi key bijv) en wijzigingen gebeuren alleen na OTA voordat die P komt en die configuraties die op je deployment server staan worden via hashes dagelijks gevalideerd. Je configuraties heb je daarnaast ook nog op een backup staan elders (incluis de hashes). Een betere oplossing is dat de configuratie yamls / scripts in een git repo zitten op die deployment server (https://www.linux.com/news/protecting-code-integrity-pgp-part-6-using-pgp-git/) en dan kunnen beheerders pull requests doen en kan er gevalideerd worden (vier ogen etc etc) wat er gepulled wordt ook.
Het gaat er dus om dat server OSen en de bijbehoorende configuraties los staan van (gebruikers) DATA en credentials en dat die gevalideert, gecontroleerd, gescript en ZEER VLUG weer in een malware vrije / virus vrije staat geherinstalleerd (from scratch) kunnen worden vanuit de gevalideerde en gemonitorde bron(en). Daarmee heb je een cryptoware ridden (MS) netwerk snel zeker weten cryptoware vrij (al weet je niet zeker voor hoe lang ivm zero days en nieuwe phishing attempts, maar OS updates [ook hashes van updates PGP signed van officiele bron] snel en automatisch doorvoeren is een goede tegenmaatregel hierin) en dan is het daarna uiteraard wel nog user DATA van backups (met hashes het liefst) restoren.
Maar... nu komt het... cirkeltje rond...
Bij een beginnende malware / crypto attack, heb je die snel gedetecteerd (je hebt bijv een traditioneel IDS/IDP, maar veel belangrijker is; je valideerd hashes van de binaries op OS servers van het OS dagelijks automatisch en hebt logging en auditing van de gevonden afwijkingen en roept die beheerder die buiten de procedure om weer op kliksafari op een server is geweest meteen tot de orde) en de nek omgedraaid nog voordat al je (incremetal) backups van user DATA ook crypto locked zijn na een tijdje. Je kunt zelfs overwegen updates door te voeren door (HA) servers van de bron met de laatste updates opnieuw uit te rollen en te valideren voor in gebruik name. Heb je regelmatig een fresh install van het OS en meteen ook je deployment restores in situ getest (een complete formeel correcte OTAP straat kan soms een hele kostbare zaak zijn).
begin je hem een beetje te voelen?
beheerders worden eerder ontwikkelaars en deployment word automatisch middels code / configuratie beschrijvingen (yaml).
ik doe al jaaaaaren niets anders (in een ietwat andere academische setting) nog voordat termen als DevOps en configuration management etc etc bestonden.
disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Zie voor je: een server die automatic deployment en configuratie doet van je meest belangrijke onderdelen in je netwerk, zeg je exchange omgeving, je AD (of LDAP od IDM server), de front web site van de uni en de studenten portals bijv. Die deployment server kan alleen beheert worden via 2FA (yubi key bijv) en wijzigingen gebeuren alleen na OTA voordat die P komt en die configuraties die op je deployment server staan worden via hashes dagelijks gevalideerd. Je configuraties heb je daarnaast ook nog op een backup staan elders (incluis de hashes). Een betere oplossing is dat de configuratie yamls / scripts in een git repo zitten op die deployment server (https://www.linux.com/news/protecting-code-integrity-pgp-part-6-using-pgp-git/) en dan kunnen beheerders pull requests doen en kan er gevalideerd worden (vier ogen etc etc) wat er gepulled wordt ook.
Het gaat er dus om dat server OSen en de bijbehoorende configuraties los staan van (gebruikers) DATA en credentials en dat die gevalideert, gecontroleerd, gescript en ZEER VLUG weer in een malware vrije / virus vrije staat geherinstalleerd (from scratch) kunnen worden vanuit de gevalideerde en gemonitorde bron(en). Daarmee heb je een cryptoware ridden (MS) netwerk snel zeker weten cryptoware vrij (al weet je niet zeker voor hoe lang ivm zero days en nieuwe phishing attempts, maar OS updates [ook hashes van updates PGP signed van officiele bron] snel en automatisch doorvoeren is een goede tegenmaatregel hierin) en dan is het daarna uiteraard wel nog user DATA van backups (met hashes het liefst) restoren.
Maar... nu komt het... cirkeltje rond...
Bij een beginnende malware / crypto attack, heb je die snel gedetecteerd (je hebt bijv een traditioneel IDS/IDP, maar veel belangrijker is; je valideerd hashes van de binaries op OS servers van het OS dagelijks automatisch en hebt logging en auditing van de gevonden afwijkingen en roept die beheerder die buiten de procedure om weer op kliksafari op een server is geweest meteen tot de orde) en de nek omgedraaid nog voordat al je (incremetal) backups van user DATA ook crypto locked zijn na een tijdje. Je kunt zelfs overwegen updates door te voeren door (HA) servers van de bron met de laatste updates opnieuw uit te rollen en te valideren voor in gebruik name. Heb je regelmatig een fresh install van het OS en meteen ook je deployment restores in situ getest (een complete formeel correcte OTAP straat kan soms een hele kostbare zaak zijn).
begin je hem een beetje te voelen?
beheerders worden eerder ontwikkelaars en deployment word automatisch middels code / configuratie beschrijvingen (yaml).
ik doe al jaaaaaren niets anders (in een ietwat andere academische setting) nog voordat termen als DevOps en configuration management etc etc bestonden.
disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Door Anoniem:
Mijn servers kan ik daarmee zo goed als niet mee uitrollen. Afgezien een stateless server, maar daar heb ik er niet zoveel van.
Nu is het natuurlijk mogelijk om de complete omgeving hiervoor kunnen ombouwen. Maar dan hebben we het over jaren werk, tegen welk voordeel? Ofwel niet haalbaar/betaalbaar.
Leuk om de basis mee neer te zetten, maar ik zal nog steeds mijn Databases moeten restoren. Maar alles is te scripten natuurlijk zodat het gebruikt kan worden. Of het alleen dat het allemaal waard, is een tweede.
Trouwens wel zojuist een leuke SPOF gemaakt, waar je ook even goed over moet nadenken.
Maar zoals zo vaak, technisch is het allemaal mogelijk, of je er wat aan hebt, is alleen tweede. Daarom de opmerking: sales (kroeg, verjaardag) praat.
Door Anoniem:
dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
Deze snap ik zeker wel. Werkt heel goed in een stateless omgeving, of inderdaad zoals in een kubernetes oplossing. Maar laat daar nu net de meeste omgevingen niet mee werken of niet voor opgezet zijn. dan snap je de kracht van cfengine, ansible, puppet, salt enzv enzv niet. en dan gaat je hoofd helemaal als spinnen van kubernetes oid :).
Mijn servers kan ik daarmee zo goed als niet mee uitrollen. Afgezien een stateless server, maar daar heb ik er niet zoveel van.
Nu is het natuurlijk mogelijk om de complete omgeving hiervoor kunnen ombouwen. Maar dan hebben we het over jaren werk, tegen welk voordeel? Ofwel niet haalbaar/betaalbaar.
Leuk om de basis mee neer te zetten, maar ik zal nog steeds mijn Databases moeten restoren. Maar alles is te scripten natuurlijk zodat het gebruikt kan worden. Of het alleen dat het allemaal waard, is een tweede.
Trouwens wel zojuist een leuke SPOF gemaakt, waar je ook even goed over moet nadenken.
Maar zoals zo vaak, technisch is het allemaal mogelijk, of je er wat aan hebt, is alleen tweede. Daarom de opmerking: sales (kroeg, verjaardag) praat.
geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
ja je start meteen goed met een basis architectuur en je script meteen (want dan hoef je het nooit een 2e keer te doen en dat helpt je ook vlug met debuggen en problem solven van zaken), of je doet dat niet en je uitgroeit organisch uiteindelijk je beheer capaciteit. da's een keuze...
wat je er aan hebt is een heleboel mensen achteraf pas eerder duidelijk. van visie verandern is menselijik het lastigste te doen. me included
04-01-2020, 22:00 door
karma4
Door Anoniem:
geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
ja je start meteen goed met een basis architectuur en je script meteen (want dan hoef je het nooit een 2e keer te doen en dat helpt je ook vlug met debuggen en problem solven van zaken), of je doet dat niet en je uitgroeit organisch uiteindelijk je beheer capaciteit. da's een keuze...
wat je er aan hebt is een heleboel mensen achteraf pas eerder duidelijk. van visie verandern is menselijik het lastigste te doen. me included
Enig idee hoe lang het goed opzetten en uitrollen van een applicatie zoals een crm omgeving duurt? Als je er 1 rond hebt komt de leverancier al met de volgende versie. De uni heeft zo'n 600 applicaties geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
ja je start meteen goed met een basis architectuur en je script meteen (want dan hoef je het nooit een 2e keer te doen en dat helpt je ook vlug met debuggen en problem solven van zaken), of je doet dat niet en je uitgroeit organisch uiteindelijk je beheer capaciteit. da's een keuze...
wat je er aan hebt is een heleboel mensen achteraf pas eerder duidelijk. van visie verandern is menselijik het lastigste te doen. me included
Een tiental zal echt kritisch zijn.
De vraag:
Hoeveel man heb je nodig om alles perfect te doen en voor hoeveel man zal er budget zijn. Ik schat zo in dat er enkele factoren verschil is.
Door karma4:
Een tiental zal echt kritisch zijn.
De vraag:
Hoeveel man heb je nodig om alles perfect te doen en voor hoeveel man zal er budget zijn. Ik schat zo in dat er enkele factoren verschil is.
Door Anoniem:
geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
ja je start meteen goed met een basis architectuur en je script meteen (want dan hoef je het nooit een 2e keer te doen en dat helpt je ook vlug met debuggen en problem solven van zaken), of je doet dat niet en je uitgroeit organisch uiteindelijk je beheer capaciteit. da's een keuze...
wat je er aan hebt is een heleboel mensen achteraf pas eerder duidelijk. van visie verandern is menselijik het lastigste te doen. me included
Enig idee hoe lang het goed opzetten en uitrollen van een applicatie zoals een crm omgeving duurt? Als je er 1 rond hebt komt de leverancier al met de volgende versie. De uni heeft zo'n 600 applicaties geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
ja je start meteen goed met een basis architectuur en je script meteen (want dan hoef je het nooit een 2e keer te doen en dat helpt je ook vlug met debuggen en problem solven van zaken), of je doet dat niet en je uitgroeit organisch uiteindelijk je beheer capaciteit. da's een keuze...
wat je er aan hebt is een heleboel mensen achteraf pas eerder duidelijk. van visie verandern is menselijik het lastigste te doen. me included
Een tiental zal echt kritisch zijn.
De vraag:
Hoeveel man heb je nodig om alles perfect te doen en voor hoeveel man zal er budget zijn. Ik schat zo in dat er enkele factoren verschil is.
yep en toch kan het... verschil tussen boys and men? verschil in (voor) opleiding / iq? kijk, je moet niet vergeten dat wat ze bijv bij google doen niet echt rocket science is. bij CERN bijv doen ze ook dingetjes anders dan wat er std op een hbo onderwezen wordt vwb IT. er is meer op de wereld en er zijn altijd mensen die slimmer zij, dat is wel wat ik geleerd heb intussen.
btw, ik denk dat jij de laatste moet zijn die de 'maar perfect lukt nooit' kaart moet gaan spelen gezien de regelmaat van je posts aangaande de iso std en de segmenteringen etc etc etc
05-01-2020, 09:28 door
karma4
Door Anoniem:
yep en toch kan het... verschil tussen boys and men? verschil in (voor) opleiding / iq? kijk, je moet niet vergeten dat wat ze bijv bij google doen niet echt rocket science is. bij CERN bijv doen ze ook dingetjes anders dan wat er std op een hbo onderwezen wordt vwb IT. er is meer op de wereld en er zijn altijd mensen die slimmer zij, dat is wel wat ik geleerd heb intussen.
btw, ik denk dat jij de laatste moet zijn die de 'maar perfect lukt nooit' kaart moet gaan spelen gezien de regelmaat van je posts aangaande de iso std en de segmenteringen etc etc etc
Je leert het pas echt in de praktijk en dan een praktijk met vele uitdagingen. Dab zegt een papiertje certificaatje weinig.yep en toch kan het... verschil tussen boys and men? verschil in (voor) opleiding / iq? kijk, je moet niet vergeten dat wat ze bijv bij google doen niet echt rocket science is. bij CERN bijv doen ze ook dingetjes anders dan wat er std op een hbo onderwezen wordt vwb IT. er is meer op de wereld en er zijn altijd mensen die slimmer zij, dat is wel wat ik geleerd heb intussen.
btw, ik denk dat jij de laatste moet zijn die de 'maar perfect lukt nooit' kaart moet gaan spelen gezien de regelmaat van je posts aangaande de iso std en de segmenteringen etc etc etc
Het toonbeeld is: dat universiteiten die de mensen voor het werk zouden opleiden er zelf niet toe in staat zijn.
Met je opmerking dat de perfectie niet lukt ga je nog verder de mist in. De hele ervaring en alles was er intussen over beschikbaar is geeft een risico impact assesment. Als je onbegrip daar al begint dan is de faal een garantie.
Door Anoniem:
geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
Maar nog steeds een zelfde deployment setup. Om de kloon uit te rollen, moet de server zelf wel online en gezond zijn. Zodra de data corrupt of niet meer te vertrouwen is, heb je niets meer aan de setup en infrastructuur.geen SPOF, je deployment serever kan self-hosted zijn en een kloon van zichzelf uitrollen in een HA opzet. easy-peasy.
ja je start meteen goed met een basis architectuur en je script meteen (want dan hoef je het nooit een 2e keer te doen en dat helpt je ook vlug met debuggen en problem solven van zaken), of je doet dat niet en je uitgroeit organisch uiteindelijk je beheer capaciteit. da's een keuze...
De meeste setups zet je 1 keer neer en komt de configuratie vanuit de database. Daarna zijn er updates vanuit de applicatie / leverancier en zet je eigenlijk nooit meer een clean install neer.
Je omgeving moet hier dus wel geschikt voor zijn (stateless). En dat zijn de meeste omgevingen juist niet.
wat je er aan hebt is een heleboel mensen achteraf pas eerder duidelijk. van visie verandern is menselijik het lastigste te doen. me included
Dat moet nog steeds je omgeving er voor geschikt zijn.Zo kunt je via WDS, PXE Boot en GPO's de meeste Windows configuratie ook gewoon pushen zonder enige issues.
In Azure kun je eigenlijk ook alles volledig geautomatiseerd doen.
Technieken zijn er, maar de infrastructuur is er meestal niet geschikt voor.
Door Anoniem:
Zie voor je: een server die automatic deployment en configuratie doet van je meest belangrijke onderdelen in je netwerk, zeg je exchange omgeving, je AD (of LDAP od IDM server), de front web site van de uni en de studenten portals bijv. Die deployment server kan alleen beheert worden via 2FA (yubi key bijv) en wijzigingen gebeuren alleen na OTA voordat die P komt en die configuraties die op je deployment server staan worden via hashes dagelijks gevalideerd. Je configuraties heb je daarnaast ook nog op een backup staan elders (incluis de hashes). Een betere oplossing is dat de configuratie yamls / scripts in een git repo zitten op die deployment server (https://www.linux.com/news/protecting-code-integrity-pgp-part-6-using-pgp-git/) en dan kunnen beheerders pull requests doen en kan er gevalideerd worden (vier ogen etc etc) wat er gepulled wordt ook.
Klinkt leuk... Daar heb je alleen helemaal niets aan, als je exchange databases encrypted zijn. De data, gaat het juist meestal om, en daar is dit geen oplossing voor.Zie voor je: een server die automatic deployment en configuratie doet van je meest belangrijke onderdelen in je netwerk, zeg je exchange omgeving, je AD (of LDAP od IDM server), de front web site van de uni en de studenten portals bijv. Die deployment server kan alleen beheert worden via 2FA (yubi key bijv) en wijzigingen gebeuren alleen na OTA voordat die P komt en die configuraties die op je deployment server staan worden via hashes dagelijks gevalideerd. Je configuraties heb je daarnaast ook nog op een backup staan elders (incluis de hashes). Een betere oplossing is dat de configuratie yamls / scripts in een git repo zitten op die deployment server (https://www.linux.com/news/protecting-code-integrity-pgp-part-6-using-pgp-git/) en dan kunnen beheerders pull requests doen en kan er gevalideerd worden (vier ogen etc etc) wat er gepulled wordt ook.
ik doe al jaaaaaren niets anders (in een ietwat andere academische setting) nog voordat termen als DevOps en configuration management etc etc bestonden.
disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Leuk voor een devops omgeving, maar voor veel van de setups is dit niet van toepassing. Daar zet je het namelijk 1 keer neer.disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Door karma4:
Het toonbeeld is: dat universiteiten die de mensen voor het werk zouden opleiden er zelf niet toe in staat zijn.
Met je opmerking dat de perfectie niet lukt ga je nog verder de mist in. De hele ervaring en alles was er intussen over beschikbaar is geeft een risico impact assesment. Als je onbegrip daar al begint dan is de faal een garantie.
Door Anoniem:
yep en toch kan het... verschil tussen boys and men? verschil in (voor) opleiding / iq? kijk, je moet niet vergeten dat wat ze bijv bij google doen niet echt rocket science is. bij CERN bijv doen ze ook dingetjes anders dan wat er std op een hbo onderwezen wordt vwb IT. er is meer op de wereld en er zijn altijd mensen die slimmer zij, dat is wel wat ik geleerd heb intussen.
btw, ik denk dat jij de laatste moet zijn die de 'maar perfect lukt nooit' kaart moet gaan spelen gezien de regelmaat van je posts aangaande de iso std en de segmenteringen etc etc etc
Je leert het pas echt in de praktijk en dan een praktijk met vele uitdagingen. Dab zegt een papiertje certificaatje weinig.yep en toch kan het... verschil tussen boys and men? verschil in (voor) opleiding / iq? kijk, je moet niet vergeten dat wat ze bijv bij google doen niet echt rocket science is. bij CERN bijv doen ze ook dingetjes anders dan wat er std op een hbo onderwezen wordt vwb IT. er is meer op de wereld en er zijn altijd mensen die slimmer zij, dat is wel wat ik geleerd heb intussen.
btw, ik denk dat jij de laatste moet zijn die de 'maar perfect lukt nooit' kaart moet gaan spelen gezien de regelmaat van je posts aangaande de iso std en de segmenteringen etc etc etc
Het toonbeeld is: dat universiteiten die de mensen voor het werk zouden opleiden er zelf niet toe in staat zijn.
Met je opmerking dat de perfectie niet lukt ga je nog verder de mist in. De hele ervaring en alles was er intussen over beschikbaar is geeft een risico impact assesment. Als je onbegrip daar al begint dan is de faal een garantie.
blaas jij maar niet te hoog van de toren karma, jij bent de laatste waar ik advies van zou volgen omdat je nog nooit inhoudelijk een discussie netjes gevoerd hebt en steevast de lastigere vragen ontwijkt en gaat trollen.
05-01-2020, 16:47 door
The FOSS
Door Anoniem:
ik doe al jaaaaaren niets anders (in een ietwat andere academische setting) nog voordat termen als DevOps en configuration management etc etc bestonden.
disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Leuk voor een devops omgeving, maar voor veel van de setups is dit niet van toepassing. Daar zet je het namelijk 1 keer neer.disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
"Maar nog steeds een zelfde deployment setup. Om de kloon uit te rollen, moet de server zelf wel online en gezond zijn. Zodra de data corrupt of niet meer te vertrouwen is, heb je niets meer aan de setup en infrastructuur."
je weet dat je server healthy is omdat je dagelijks de hashes checked van je binaries en van je git repo die alle configs dus bevat. daarnaast heb je er niet letterlijk maar eentje, je hebt er een 2e (HA = high availability) bij. je zou er zelfs voor kunnen kiezen een 3e te hebben die voor de O en de T van OTAP functioneren naar test servers toe die voor dit soort ontwikkelingen en testen speciaal aangewezen zijn.
"Klinkt leuk... Daar heb je alleen helemaal niets aan, als je exchange databases encrypted zijn. De data, gaat het juist meestal om, en daar is dit geen oplossing voor."
net als SQL DBs en user data files, je maakt regelmatig een dump daarvan op je backup infrastructuur. je deployment script kan dan zo opgezet zijn dat bij uitrollen automatisch de laatste (gevalideerde) dump weer geimporteerd wordt in de DB.
let op er kan nog steeds een crypto malware aanval plaatsvinden op je gewone servers (niet zo de deployment servers ivm 2FA en de dagelijke host based intrusion protection checks via de hashes van binaries, de locale git repo die je voor je yamls gebuikt), maar je zult hem snel detecteren, nog voordat de crypto malware je dagelijkse incremental backups te grazen nemen. zodra je die aanval detecteerd op een server, meteen afkoppelen, isoleren en een verse opnieuw uitrollen op baremetal of in een nieuwe VM, what you want (btw, je deployment infra niet op VMs zetten en zekere niet direct aan ze internetz hangen en remote vanuit de buitenwereld gaan beheren oid). dat gaat SNEL.
crypto malware slaat eigenlijk alleen effectief daar toe waar beheerders dagelijks op inloggen ZONDER 2FA, of op servers die niet geupdate zijn en een remote exploit hebben, of als er spraken is van een zero-day [of je OS / netwerk opzet is zo waardeloos dat eigenlijk elke gebruiker min of meer wel via een local exploit naar beheerder van een server kan escaleren, maar dan praten we wel over hele andere levels van prusterij (je defending posture is niet op orde)]. die dingen kun je nooit niet 100% weg halen dat ze eens gaan gebeuren, maar wat je wel kunt doen is de 'pijn' verzachten en ervoor zorgen dat je vlug in een known good state kunt disaster recovery doen en de getroffen gebruikers hun WW laten veranderen (je hergroeperingsplan dus). het wordt dan een kat-muis spelletje met hoe vlug jij de intruders van een server af kunt knikkeren (door die fresh reinstalls) v hoe vlug zij weer die exploit / fishing uit kunnen voeren. uiteraard monitor je en zodra een server de aandacht van malware / hackers krijgt, schroef je de monitoring op en bestudeer je de aanval in meer detail via bijv netwerk logging etc. (proactief dat wat aangevallen wordt counteren) met de vinger op de 'reinstall' knop (als je dat allemaal zou willen). die luxe heb je dus alleen maar omdat je dus snel op 'reinstall' kunt drukken en naar de volgende ronde in het gevecht kan gaan. kan je dat namelijk niet, dan zul je altijd achter aan blijven rennen brandjes moeten blussen. ik ben een beetje bang dat dit de situatie bij de UM zal zijn (zeker als ze betaald hebben om de encrypte files te decrypten: no guarantees dat ze over een jaartje of drie weer even 'langs komen' omdat ze een reverse shell op een timer in je omgeving geplant hebben ergens: melken die koe! [met geld koop eerder je tijd, maar nooit een echte oplossing]).
Door The FOSS:
Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
Door Anoniem:
ik doe al jaaaaaren niets anders (in een ietwat andere academische setting) nog voordat termen als DevOps en configuration management etc etc bestonden.
disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Leuk voor een devops omgeving, maar voor veel van de setups is dit niet van toepassing. Daar zet je het namelijk 1 keer neer.disclaimer: ik doe dit reeds 20j vanuit unix / linux en ik weet niet inhoevere deployments gescriped kunnen worden met dat pauper-shell :P.
Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
EXACT! het is niet mensen eigen om alles in een keer goed te doen is mijn ervaring dus je kunt er maar beter meteen van uit gaan dat het vroerger of later wel om welke reden dan ook eens eigenlijk over zou moeten met hier en daar wellicht een aanpassing. je kun meegroeien en met de tijd mee bewegen als je omgeving 'dynamisch' is ipv statisch. en een script uitgevoerd door de computer kost minder dan mensen uren dingen met het handje over te laten doen en nieuwe fouten daarbij te introduceren. nieuw versie van OS? no problem, uitrol opzetten, testen, valideren, updates meteen mee nemen en een traject starten om de gebruikers 'over te zetten', ja kost tijd, dit is onvoorkoombaar, maar wel eenvoudig herhaalbaar te maken en op te schalen. je moet code schrijven ipv met de muis gaan klikken, dat wel zo.
Door The FOSS:
Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
Dat is wel de opzet van de meeste applicaties. Daar draait er maar 1 van, en zal nog jaren zo draaien. Herinstallaties vinden eigenlijk niet plaat. En de meeste configuratie zit in de applicatie.Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
Dan is het kijken of dit te automatiseren is, en kijken hoeveel tijd je daarvoor kwijt bent. Zo kan een handmatige installatie een paar uurtjes werk zijn. Bijvoorbeeld updates 1 keer per kwartaal een uurtje.
Maar als je alles wilt scripten, kan dit in eens een veelvoud worden. Waarbij je iedere update ook nog eens volledig moet testen, inclusief een complete uitrol.
Allemaal mogelijk, maar of het rendabel is, is een tweede. Een standaard OS deployment is goed te automatiseren. Maar de rest kan heel veel extra werk zijn.
Maar alles is mogelijk.
Door Anoniem:
Dan is het kijken of dit te automatiseren is, en kijken hoeveel tijd je daarvoor kwijt bent. Zo kan een handmatige installatie een paar uurtjes werk zijn. Bijvoorbeeld updates 1 keer per kwartaal een uurtje.
Maar als je alles wilt scripten, kan dit in eens een veelvoud worden. Waarbij je iedere update ook nog eens volledig moet testen, inclusief een complete uitrol.
Allemaal mogelijk, maar of het rendabel is, is een tweede. Een standaard OS deployment is goed te automatiseren. Maar de rest kan heel veel extra werk zijn.
Maar alles is mogelijk.
Door The FOSS:
Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
Dat is wel de opzet van de meeste applicaties. Daar draait er maar 1 van, en zal nog jaren zo draaien. Herinstallaties vinden eigenlijk niet plaat. En de meeste configuratie zit in de applicatie.Da's juist het punt hè... Als je met een mindset van één keer neerzetten van start gaat ben je niet in staat om snel te recoveren bij calamiteiten.
Dan is het kijken of dit te automatiseren is, en kijken hoeveel tijd je daarvoor kwijt bent. Zo kan een handmatige installatie een paar uurtjes werk zijn. Bijvoorbeeld updates 1 keer per kwartaal een uurtje.
Maar als je alles wilt scripten, kan dit in eens een veelvoud worden. Waarbij je iedere update ook nog eens volledig moet testen, inclusief een complete uitrol.
Allemaal mogelijk, maar of het rendabel is, is een tweede. Een standaard OS deployment is goed te automatiseren. Maar de rest kan heel veel extra werk zijn.
Maar alles is mogelijk.
uit de unix wereld ben ik gewend dat elke configuratie van elke applicatie eenvoudig in een config file of met een eenvoudig commande gescriped kan worden. ik weet vrijwel zeker dat dat in windows met power-shell in combi met .ini files om registry waarden te zetten ook zou moeten kunnen.
disclaimer: ben een unix persoon en heb nooit windows beheert zelf (wel mee opgegroeid en gebruiker ervan geweest).
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.
