Okta: datalek veroorzaakt door medewerker die inlogde met Google-account

Okta meldt dat het datalek bij het bedrijf is veroorzaakt door een medewerker die had ingelogd met een persoonlijk Google-account op de werklaptop. De zakelijke inloggegevens werden opgeslagen in dat account en het werd later gehackt.

Okta heeft naar eigen zeggen maatregelen genomen om soortgelijke incidenten in de toekomst te vermijden. Het wordt bijvoorbeeld niet meer mogelijk voor medewerkers van het bedrijf om in te loggen bij Google Chrome met een persoonlijk account en administrator sessions worden voortaan ook gekoppeld aan netwerklocaties.

Van 28 september tot en met 17 oktober hadden hackers toegang tot de supportsystemen van Okta. De kwaadwilligen konden gegevens van 134 klanten buitmaken en bij vijf klanten kon er ingelogd worden op de klantenomgeving.

Wachtwoordmanager 1Password was een van die klanten en had eind september ‘verdachte activiteit’ ontdekt op zijn interne Okta-account. De hackers probeerden verschillende acties uit te voeren op het Okta-account van 1Password, maar dit werd geblokkeerd door Okta. Naar verluidt zouden er tijdens de hack geen gebruikersgegevens van 1Password gestolen zijn.

Okta is een Amerikaans bedrijf dat een authenticatieplatform beheert. Tal van bedrijven maken gebruik van de systemen van Okta om werknemers te kunnen authenticeren voordat ze toegang krijgen tot interne systemen.

Reacties (159)

[djwice]

@JayStout Volgens mij was dit "administrator sessions werden niet gekoppeld aan het IP / de netwerklocatie" het eigenlijke probleem.

Ook de duur van de sessie was waarschijnlijk lang, aangezien de gebruiker een HAR file met sessie geüpload had en de hacker die heeft kunnen gebruiken, daar zit waarschijnlijk ook redelijk wat tijd tussen.

Dus zelfs als de medewerker niet met het prive account was ingelogd was dit probleem aanwezig. Het gebruik van het prive account is circumstantieel, de echte oorzaak zat in het sessie probleem.

Tip voor anderen
Bij Octa zijn er standaard nog een aantal dingen niet optimaal. Mocht je Octa voor jouw bedrijf gebruiken, maak dan een externe gratis scan op https://observatory.mozilla.org/ van je login pagina, vergeet niet de "Don't include my site in the public results" aan te vinken, voor het geval je dat niet wil.

Je login pagina zou A+ ranking moeten hebben en het liefst 135 punten scoren. Dat is gewoon mogelijk, is dat bij jullie niet het geval, ga dan met Octa of je implementatie consultant in gesprek.
Ga ook in gesprek over sessie lengte en koppelen van sessies aan IP adressen.
Mocht je HTTP/3 ondersteunen, dan kun je kijken of de browser handshake ID (die van TLSv1.3 waar de browser mee vertrouwd wordt bij het tweede bezoek in korte tijd) ook gebonden kan worden aan je sessie, dat is sterker dan een IP-adres, alleen die ene cliënt kan die signatuur geven en alleen voor een door de server vastgestelde periode.
Dus veiliger dan een sessie cookie + IP-adres.

[Reactie gewijzigd door djwice op 23 juli 2024 10:49]

[laurens0619]

Het doel van het toevoegen van een IP filter is eigenlijk dat je dus alleen kunt inloggen vanaf een corporate device. Als je Azure AD gebruikt heb je het voordeel dat bij iedere moderne authenticatie een device token zit waarbij je kunt zien of het een computer van je organisatie is (domain joined/intune compliant).

In azure werkt dit out of the box en zit het ingebakken in windows. In Okta moet je van alles gaan uitrollen om die device context te gaan krijgen. Die device context is wel cruciaal om onderscheid te kunnen maken tussen een aanvaller of een legitieme gebruiker.

Als je daar een filter op zet behaal je hetzelfde doel als een ip filter maar werkt het dus ook voor thuiswerkers zonder vpn

[Reactie gewijzigd door laurens0619 op 23 juli 2024 10:49]

[SunnieNL]

Okta regelt dan ook voornamelijk de authenticatie voor gebruikers. De oplossing die de toegang regelt (bv zta) doet de device context en bepaald of je uiteindelijk toegang mag hebben tot datgene wat je aanvraagt.
Bij Azure werkt dat alleen out of the box omdat Microsoft veel meer doet dan alleen authenticatie/sso van de gebruiker. Microsoft levert immers ook Intune en Defender, en die onderdelen regelen de device context informatie in de authenticatie. Overigens gebeurd dat bij Microsoft pas na het opzetten van de verbinding, dus na authenticatie (aantal concurrenten checken eerst het device voor ze uberhaupt de authenticatie procedure van de gebruiker in gaan).
Okta is op dat punt altijd afhankelijk van het device management platform.

Het gaat in het artikel overigens wel om Okta medewerkers die een admin sessie openen naar Okta. Ben benieuwd of ze dat daadwerkelijk op IP-basis doen of op IP-context basis (het laatste levert een geo locatie op die je kan vergelijken, terwijl de eerste gewoon een hardcoded IP is, wat in theorie wat onhandig kan zijn bij thuiswerkende admins)

[laurens0619]

Zodra je een hybrid domain join opzet komt die informatie al mee daar is geen defender of intune voor nodig. Met chrome is nog wel een extension nodig maar outlook/edge etc stuurt die info native mee.

Echt een uitkomst want met Okta was het maar uitzoeken welke sessie van je corporate device afkwam en nu zie je het in 1 oogopslag. Okta kan het ook maar die setup heeft agents nodig op ieder device

[MiesvanderLippe]

Je sessie koppelen aan een IP adres is alleen haalbaar als je ook een VPN hebt. In dat geval kun je ook gewoon whitelisting op de gehele pagina gooien. Anders ben je de sjaak als je regelmatig remote werkt of 4G gebruikt.

[djwice]

Over het algemeen heb je tijdens je remote sessie het zelfde IP address, tenzij je opnieuw inlogt bij het netwerk waar je gebruik van maakt.
Vanuit beveiligingsoogpunt lijkt het me geen overbodige luxe dat als je van netwerk wisselt - bijvoorbeeld als je in een ander internet cafe zit of andere trein - dat je duidelijk maakt dat jij het bent, je oude sessie wordt geïnvalideerd en je een nieuwe sessie krijgt.
Bij goede software hoeft een nieuwe sessie niet te betekenen dat je 'op nieuw' moet beginnen, de state van een applicatie moet niet van de sessie afhangen lijkt me. Dus als het goed is kun je gewoon verder waar je was na herauthenticatie.

Hoe soepeler het "dit ben ik"-bewijs-proces verloopt, hoe minder last de gebruiker van dit proces heeft, vandaar dat ik de http/3 (h3) features zo fijn vindt.

[SunnieNL]

Juist, netwerk wissel zou altijd een her-authenticatie moeten aanvragen als je met een admin account bent ingelogd. Daarnaast zou er ook wel gekeken mogen worden waar je vandaan komt. Over het algemeen is het niet mogelijk om het ene moment in rotterdam te zitten en het andere moment in Utrecht, laat staan dat je ineens vanaf Rusland komt.

[djwice]

Zakelijk heb ik dat eigenlijk juist wel, de ene keer uit de UK VPN omdat NL weer eens hoge latency heeft, even later uit Frankfurt en een half uurtje later uit Amsterdam.

Dus juist zakelijk kom ik snel uit een andere regio, terwijl mijn echte adres niet veranderd, dus zonder zakelijke VPN zou mijn lokatie beter kloppen en minder wisselen.
Bovendien zou mijn verbinding dan sneller zijn (los van de VPN overhead, gewoon de beperkte bandbreedte en latency die het bedrijfsnetwerk oplegt).

[Nappie]

Met VPN kan dat dus wel (zo lijken). Ik heb voor sommige connecties VPN nodig en dan kom ik uit Engeland of Duitsland, maar als de VPN uitstaat kom ik uit Nederland.

[Puch-Maxi]

Gebruiken ze geen multifactorauthenticatie bij Okta? Met alleen een gebruikersnaam en een wachtwoord kun je dan immers niets aanvangen .

[ANdrode]

Het was een wachtwoord voor een service account dat lekte naar de aanvaller.

Uitleg over waarom dit service account vanaf overal te gebruiken was heb ik nog niet gezien.

[djwice]

Als ik het goed las, was er een active sessie token voor een service account uit het HAR-bestand gevist, waardoor de aanvaller de sessie kon overnemen.

Uit dit artikel haal ik dat de de redem dat de sessie vanuit elke lokatie te gebruiken was werd veroorzaakt dpprday er geen IP-binding aan de sessie zat.

IP-whitelisting (tot jouw eigen netwerk) is geen goede bescherming als een hacker al binnen je netwerk zit.
ZeroTrust connecties zijn daarvoor nuttiger, uiteraard moet dan het ZeroTrust token niet lekken.
Voordeel van ZeroTrust is dat je de token kunt refreshen / invalideren waarmee alle gelekte ZeroTrust tokens nutteloos worden.

ZeroTrust kun je al opzetten vanaf het bestaan van de Vary-HTTP-header (juni 1999, in http/1.1), dus sinds dien hoef je technisch niet alleen meer IP-whitelisting te vertrouwen als je HTTPS-communicatie gebruikt; sinds dien is het een keuze.

Bovendien gebruiken we steeds meer SaaS, waarbij het uit kosten en business continuity oogpunt niet meer logisch is om vaste of dedicated IP-adressen te gebruiken. Een vaste set IP-addressen maakt het immers ook kwetsbaarder voor gerichte aanvallen en kan het schaalbaarheid en fail-over in de weg zitten, wat leidt tot extra kosten en largere SLA-garanties als je het tóch vereist (lose-lose-lose).

Dus is het vanuit meerdere oogpunten goed om te ontwerpen alsof je applicatie altijd aan het publieke netwerk (internet) zit en elk IP-adres / elke netwerklocatie zowel betrouwbaar als onbetoouwbaar is op het zelfde moment. En sinds 1999 is de techniek die daarvoor nodig is wereldwijd gratis beschikbaar in alle HTTP-servers (proxies, firewalls, web- en applicatieservers, etc.).

[Reactie gewijzigd door djwice op 23 juli 2024 10:49]

[ANdrode]

Zoals ik het lees was het service account van de laptop van de gehackte Okta medewerker gestolen. Daarmee werden attachments uit een support systeem gehaald.

Daarna werden de accounts van klanten die op aanvragen van support een HAR bestanden hadden geupload misbruikt. De sessies van de klanten hadden geen IP adres binding (wat defence in depth is imo) omdat Okta die feature niet aanbood.

Ik ben verbaasd dat dit eerste service account vanuit buiten het okta netwerk gebruikt kon worden (het ip adres van de aanvaller wat klanten doorgeven kwam overeen met dat in logs van de support app).

Zulke support services zouden alleen met workload of gebruikers-identiteit toegang moeten geven.

[djwice]

Ik denk dat Octa dezelfde features beschikbaar heeft als haar klanten. Als haar klanten geen session-IP-binding als feature beschikbaar krijgen van Octa (we hebben daar denk ik dezelfde mening over ), had Octa dat wellicht ook niet voor zichzelf beschikbaar/aan staan.

Immers als ze het belang hadden ingezien, was het vast ook al een feature in het security product voor hun klanten.

[ANdrode]

Voor het service account zou ik workload-identiteit willen zien. Een IP adres is daar een poor man's substitute. Voor gebruikers zou ik willen dat sessies locatie-specifiek zijn.

Over IP-adres/location binding, in de blog schrijft Okta:

Okta has released session token binding based on network location as a product enhancement to combat the threat of session token theft against Okta administrators. Okta administrators are now forced to re-authenticate if we detect a network change. This feature can be enabled by customers in the early access section of the Okta admin portal.

De feature is magisch verschenen.

[Reactie gewijzigd door ANdrode op 23 juli 2024 10:49]

[nextware]

Bij OKTA is MFA verplicht.. Maar een beetje goede hacker pakt dan je session cookies en alles mee en je bent ook binnen. Plus als je binnen 15 minuten vanaf hetzelfde device inlogt in OKTA wordt MFA overgeslagen.

[TheVivaldi]

Dus iedereen zegt dat MFA zoveel veiliger is dan sms-codes, maar uiteindelijk kunnen hackers alsnog je sessiecookies stelen of binnen 15 minuten MFA omzeilen? Klinkt niet alsof het nu zóveel veiliger is als mensen beweren, maar corrigeer me gerust.

[the_stickie]

Om cookies te ontvreemden heb je alsnog een vorm van toegang tot de computer van de gebruiker nodig.

2F/MFA is sowieso veiliger dan een wachtwoord. Cybersecurity is een kwestie van laagjes en (het het uit de luchtvaart overgenomen) "swiss cheese" principe.

[aikebah]

Een reflected cross site scripting vulnerability in de gebruikte webbased tool is daar ook voldoende voor.

[the_stickie]

="een vorm van toegang"

[laurens0619]

Of een mitm proxy als evilnginx2

[ThaGuus]

Dat geldt precies hetzelfde voor sms-codes (die een type zijn van MFA). Sessiecookies zijn namelijk de authenticatiesleutel tussen je browser en de server. Het zou natuurlijk niet handig zijn als je telkens opnieuw moet inloggen als je ergens op klikt. Het is echter verstandig om deze sessies te beperken op basis van de user-agent header en het IP-adres wat vaak niet gebeurt.

Maar zodra iemand toegang heeft tot je cookies, heb je al grotere problemen, want dan moet die persoon al toegang hebben tot je apparaat en moet je mogelijk al een virus of iets dergelijks hebben.

[Verwijderd]

Het verschil zit hem in dat men het veiligheidsprotocol met een hardware sleutel meer binnenshuis houdt en, voor de beveiliging van dat deel van de authenticatie, niet meer afhankelijk is van de klantenservice van telefoonbedrijven.

Nu dat dat stukje is afgedekt stapt de pientere hacker natuurlijk over naar de volgende zwakke schakel. Desondanks is die nieuwe zwakke schakel in het algemeen nog steeds sterker dan de sms-sleutels.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:49]

[Vogel666]

Tja...trek jij de voordeur achter je dicht als je naar je werk gaat? Want volgens dezelfde redenatie zou je net zo goed de voordeur wagenwijd open kunnen laten staan...een inbreker kan immers ook een ruit ingooien?

Het gaat om het reduceren van de attacksurface. Met MFA is in iedre geval een reguliere login met een gestolen/afgekeken wachtwoord niet mogeleijk. Deze hacker moest daardoor eerst toegang krijgen tot de sessiecookies. Google-account + netwerktoegang --> device --> browser sessie cookies --> Okta-platform
Dat zijn 5 hacks om bij de prijs te komen. Zet MFA uit een je bent terug naar 1.

[Reactie gewijzigd door Vogel666 op 23 juli 2024 10:49]

[ThaGuus]

Ja, maar dan klopt de verklaring van Octa toch niet? Ze geven aan dat de lek is veroorzaakt doordat een medewerker was ingelogd met zijn persoonlijke Gmail-account, en daardoor werden de wachtwoorden opgeslagen in de wachtwoordmanager van Google, en dat dit account later is gehackt. Dan blijft de vraag open: hoe kon iemand alleen met de gebruikersnaam en het wachtwoord uit de wachtwoordmanager inloggen zonder MFA?

Mijn aanname op basis van dit bericht is ook dat je alleen mag inloggen via de werklaptop op het platform, wat dus betekent dat de werklaptop geïnfecteerd moest zijn of dat de MFA niet goed heeft gefunctioneerd.

[Vogel666]

Het probleem is dat je van alles kunt afdwingen op de systemen die je beheert.
Zogauw je toestaat dat authenticatie mogelijk is met 3rd party indentities (en dat is het hele concept achter Okta: een willekeurige identity van Google, Microsoft, Apple, DigId, Amazon, Slagerij om de hoek moet toegang kunnen geven tot alle data van alle platformen die je maar kunt bedenken), geef je dus de controle over je primair systeem weg aan een secundair systeem dat niet aan de zelfde veiligheidseisen gebonden is.

Effectief is het verbieden van een privé account dus een erkenning dat het concept achter hun product niet deugt.

In dit geval wist de belager toegang te krijgen tot de sessiecookies van de Chrome browser. En een sessiecookie worden afgegeven NA MFA. Er is dus een een reeds geauthencieerde sessie gekaapt.

[ThaGuus]

In dit geval wist de belager toegang te krijgen tot de sessiecookies van de Chrome browser. En een sessiecookie worden afgegeven NA MFA. Er is dus een een reeds geauthencieerde sessie gekaapt.

Ja maar dit staat dus niet op de website van Okta of in dit nieuwsbericht.
Een citaat van het bericht van Okta:

The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.

Wat Okta dus beweert is dat de username + password gestolen waren, er staat nergens iets over de session cookies van de gebruiker. Als het zo is dat het om de session cookies gaat, ligt het probleem niet bij dat de gebruiker zijn persoonlijke google account gebruikte maar aan dat er iemand toegang had tot die cookies (waar normaliete een soort van virus voor nodig is).

Dus Okta heeft het hier of mis en was het toch iets anders of er kon iemand inloggen zonder MFA.

Edit: Na het nog veder lezen snap ik het eindelijk, het blijkt te gaan om een "service account" dus een soort api account. Deze accounts hebben inderdaad geen MFA, en worden normaliete eigenlijk alleen gebruikt om de api aan te roepen. Waarom dat niet vermeld staat in het artikel geen idee

The unauthorized access to Okta’s customer support system leveraged a service account stored in the system itself. This service account was granted permissions to view and update customer support cases.

[Reactie gewijzigd door ThaGuus op 23 juli 2024 10:49]

[the_stickie]

De zakelijke inloggegevens werden opgeslagen in dat account en het werd later ook gehackt

Dit is een belangrijk probleem dat vaak onderschat wordt. je kan nog zo'n strikt wachtwoord beleid hebben, als je gebruikers/admins credentials buiten je gekozen tool beginnen op te slaan, is het risico enorm.
De oplossing lijkt eenvoudig: policies kunnen het onmogelijk maken wachtwoorden 'in browser' op te slaan. Maar mijn ervaring leert dat sommigen (nog steeds) hun eigen tool prefereren (boven de gekozen tool die dingen als permissies en auditing mogelijk maakt), of zelfs sommige wachtwoorden plain text opslaan of doormailen.
Als zo'n gebruiker/admin slechte bedoelingen heeft, ben je eraan voor de moeite. Als die daarentegen het beste voorheeft, kan opleiding iets helpen.

Blijft een feit dat password management in grote omgevingen een hele klus is waarbij het eenvoudig is fouten te maken die kwaadwillenden maar wat graag uitbuitten.

[bilgy_no1]

Ik ben slechts een gebruiker (weet ook niets van systeembeheer af), maar de overload aan security maatregelen begint mij allemaal behoorlijk te irriteren.

Bij mijn werkomgeving is laatst MS Intune ingevoerd. Helemaal gezegend voor de werklaptop, maar het moest ook op de telefoon voor toegang via de MS apps. Nou, mooi niet dus op mijn privetelefoon waar ik ook al mijn bankzaken heb lopen. Want via Intune heeft de IT-beheerder (is uitbesteed) dus ook allerlei rechten. Zal vast wel veilig zijn gemaakt, maar het zal niet voor het eerst zijn dat er een exploit is op een MS product.

Dus maar een extra toestel ernaast voor toegang tot mijn werkmail, agenda en documenten. Erg onhandig: extra codes om apps te openen, ik mag nog niet eens een telefoonnummer uit een ontvangen mailtje kopiëren om die persoon te bellen, agenda widget is verboden. Dat soort ongein maakt het werken er niet handiger op. En dat dan naast iedere 3 maanden een nieuw wachtwoord, waardoor je wel een wachtwoord manager moet gaan gebruiken (zoals in dit voorbeeld).

Ik snap dat we alles veilig moeten houden. Maar dit begint te voelen als "de veiligste vorm van safe sex is om helemaal geen sex te hebben"...

[Muncher]

Dit klinkt mij in de oren als of een overcorrectie of iemand die niet zo goed weet wat hij geïmplementeerd heeft of een onervaren security professional die dit heeft besloten.

Je kan prima veiligheid met gebruikersgemak combineren tegenwoordig vind ik. Perfect is het nooit. Wij hebben recentelijk alles achter Yubikey/TouchID/Windows Hello gezet het was even puzzelen maar ik moet zeggen: als mensen kunnen kiezen tussen elke 3 maanden een nieuw wachtwoord of inloggen met een van de eerder genoemde methodes… reken er maar op dat die laatst genoemden steeds winnen.

[akooijman]

Ik snap sowieso het doel niet zo goed van het verplicht wijzigen van wachtwoorden. Dat vraagt juist om iets dat makkelijk te onthouden (en 'dus' te raden?) is, gEhe!mnOv23... één keer raden wat het over drie maanden wordt...
(Best een goed wachtwoord, het uitroepteken is een weggevertje, maar een andere dan de eerste letter in uppercase ligt minder voor de hand, en probleemloos elke maand een vers exemplaar.)
Maar een goed wachtwoord dat niet uitlekt kan toch gewoon jaren mee?

[Joolee]

De NIST die dat ooit geadviseerd heeft, heeft dat advies ook niet al te lang daarna weer ingetrokken. Het bleek namelijk veel minder veilig dan het afdwingen van een sterk wachtwoord met oneindige geldigheid. Helaas was het kwaad toen al geschied en inmiddels een jaar of 30 later is het nog steeds een bekende "veiligheids"eis. Het feit dat Windows decennia lang niet veel meer opties voor wachtwoordbeleid heeft gehad dan "minimale lengte" en "verander elke x dagen" heeft hier ook sterk aan meegeholpen.

[supersnathan94]

Ik snap het idee erachter wel. Als er op een manier oude credentials toch zijn uitgelekt zijn die maximaal 3 maanden bruikbaar voor aanvallers. Daarna zijn ze automatisch de sjaak.

Maar eens hoor. Het maakt het er eigenlijk helemaal niet veiliger op. Ik zie dan gelukkig ook dat organisaties er op terugkomen en liever hogere entropy afdwingen.

[hellum]

In theorie heb je daar gelijk in, praktijk is dat mensen geen zin hebben om iedere paar maanden hun wachtwoord te veranderen. `MijnWachtwoord1`, wordt `MijnWachtwoord2` en een paar maanden later `MijnWachtwoord3`. Als een van deze wachtwoorden uitlekt, is het een kleinigheidje om het huidige wachtwoord te raden.

[supersnathan94]

Klopt. Maar dat maakt het net ff wat minder triviaal dan gewoon creds van Github af trekken.

[Stpan]

Ik gebruik een password manager om voor elke login een random wachtwoord te verzinnen, met de maximale lengte die is toegestaan.

Maar daarna beginnen de 'veiligheidsvragen' voor als ik het wachtwoord vergeet. En dat zijn keer op keer dezelfde en heel makkelijk te achterhalen antwoorden.

De naam van mijn basisschool / middelbare school (te vinden op mijn social media), de straat waar ik ben opgegroeid (wonen mijn ouders nog steeds), mijn jeugdheld (alle mannen van 1970-1980: Marco van Basten), de geboortedag van mijn moeder. Ik vraag me af of dit niet een potentieel lek is?

[cvr42]

Alleen als je de waarheid invult. Mijn eerste huisdier is een olifant… Je zou ook stofzuiger of een random string kunnen doen.

Wel aantekeningen maken in een password manager, natuurlijk.

(Sommige details zijn om privacy redenen gewijzigd)

[kozue]

Ik erger me al heel lang aan "secret questions". Vooral als het een vaste lijst is waar je uit moet kiezen. Iemand die mij goed kent, zal een eerlijk antwoord op die vragen makkelijk kunnen raden. En dan doe ik nog niet eens aan social media. Iemand die z'n hele leven op internet kwakt zal het hackers helemaal makkelijk maken. Of wat te denken van beroemde personen waarvan hun hele leven, inclusief jeugd, op wikipedia bijgehouden wordt. En als je dan onzin in vult, zodat niemand anders het kan raden, ben je zelf de sjaak wanneer je een keer een password reset nodig hebt en die service je met vragen lastig valt waar je het antwoord niet op weet. Wat moet je dan? De antwoorden op je vragen in plain text in een bestand op je computer opslaan? Zodat iemand die daar in komt ze ook meteen heeft? Ik heb geen goede manier om veilig met "veiligheidsvragen" om te gaan. Bovendien wil ik de waarheid niet invullen, dat is persoonlijke data afgeven en daar heb ik een hekel aan.

Ik wíl dus geen secret questions, dat beschouw ik als een backdoor. Mijn grootste ergernis is Apple, die ze verplicht stelt, en ze ook vraagt wanneer je je wachtwoord wilt resetten. Een tijdje geleden kon ik mijn Apple wachtwoord nergens meer vinden en niet meer herinneren. Ik gebruik m nooit voor de appstore (vingerafdruk is genoeg), en had m nodig om op een Mac Mini in te loggen die ik al jaren niet meer gebruikt had omdat dat ding super traag was geworden. Ik had de disc vervangen door een SSD en nu startte ie ineens op in 15 seconden ipv 15 minuten, dus die was weer bruikbaar. Maar MacOS bleef maar om m'n wachtwoord vragen, en die wist ik niet meer. Het heeft me best een tijd gekost om m'n wachtwoord weer te resetten door dat gezeur over secret questions, waar ik de antwoorden ook niet allemaal meer op wist (omdat ze niet allemaal waar zijn, ik had bv geen huisdier). Stuur me gewoon een mail met een reset link, klaar.

[Reactie gewijzigd door kozue op 23 juli 2024 10:49]

[Skywalker27]

Maar je wachtwoorden veranderen in dit v3r@nd3r3n helpt helaas ook niet meer de breachforce libraries weten hier ook al geruime tijd mee om te gaan. Wachtwoord zinnen is nog steeds het beste.

[Vinnie.1234]

Precies dit, dat constant wachtwoord wijzigen zorgt juist voor slechte wachtwoorden en dan heb jij nog best een goede gedaan. Ik had ooit op mijn werk sterke wachtwoorden overal. Nu moet ik dus elke 3 maanden overal mijn wachtwoord aanpassen. Sinds die tijd zijn een deel van mijn wachtwoorden zo simpel dat een kind ze van 3 kan raden. Puur de reden is dat ik ze dan niet vergeet en als ik ze vergeet ik ook niet bij mijn wachtwoordkluis kan komen. En constant vragen of mijn wachtwoord opnieuw ingesteld kan worden heb ik ook geen zin in.

[Tc99m]

Dan is het óf niet goed geïmplementeerd, óf het is simpelweg nodig (dat ligt er natuurlijk aan waar je werkt en wat je doet). Al vind ik zaken als het 3 maandelijks vervangen van alle wachtwoorden wel een beetje overdreven; je loopt het risico dat mensen wachtwoorden gaan opschrijven of toch hele voorspelbare wachtwoorden gebruiken waarin ze steeds maar een paar tekens veranderen.

Ik zit in deze discussie regelmatig aan de andere kant van de tafel, en ik stoor me er dan weer aan dat collega's die toegang hebben tot best gevoelige data moeilijk doen over basale maatregelen ("het is toch handig als iedereen erbij kan", "zo'n vaart zal het niet lopen", etc.). Gelukkig ben ik wel in een positie dat ik daar iets aan kan veranderen.

Het lastige met beveiligingsmaatregelen is natuurlijk ook dat je zeker in grote organisaties de maatregelen niet individueel kunt afstemmen. Heel kort door de bocht: het moeten generieke maatregelen zijn die idiot proof zijn, zo streng als nodig is om de meest slordige medewerker in die categorie gebruikers nog veilig te kunnen laten werken. De medewerkers in diezelfde groep die ook zonder maatregelen heel voorzichtig zijn ervaren daar dan het meeste last van.

[bilgy_no1]

Ik betwist niet dat het nodig is. Helaas... En ik erger me ook primair aan de criminele types waardoor dit allemaal komt. En secundair aan de paar collega's die op een of andere manier voor phishing scams zijn gevallen. Tja, dan moet de organisatie wel.

Ik ga er ook niet tegenin en was een van de eersten met Intune. Maar wel op een aparte telefoon en een lichte irritatie omdat het mijn werk niet handiger maakt. Zeker als het gaat om zaken als een telefoonnummer uit een mailtje kopiëren.

[Jacques-Oh]

Ik deel jouw frustratie. Bij ons op het werk is het ook steeds ingewikkelder geworden. Het is steeds én én én.

Wat ik moet doen om even iets in SAP op te zoeken:
- PC aanzetten, 5 seconden wachten.
- Bios wachtwoord invullen, weer 10 seconden wachten.
- Windows wachtwoord invullen. weer 10 seconden wachten.
- Microsoft office openen, paar seconden wachten. Windows wachtwoord invullen. wachten op MFA prompt.
- Telefoon uit de zak halen, inloggen met gezicht (duurt ook weer paar seconden), MFA app opstarten, MFA code overtikken.
- VPN openen, wéér een MFA prompt overtikken.
- SAP openen, invullen wachtwoord.
En uiteraard elke 40 dagen een nieuw wachtwoord...

Ik wordt hier dus helemaal suf van.
Wat mij stoort is dat het lijkt alsof je steeds meer losse sloten om een fiets doet, terwijl je eigenlijk gewoon 1 heel goed slot moet kopen.

Er is zo weinig oog voor de gebruikerservaring. Ik moet vaak ff snel iets doen vanuit huis. Vroeger was dat laptop openklappen, 1x inloggen en gaan. Nu kost het me al gauw 2 a 3 minuten om überhaupt op te starten.

Bij het ontwerpen van security zou de gebruikerservaring en snelheid van handelen centraal moeten staan. Dan zijn gebruikers niet bezig met geitenpaadjes door bijv. wachtwoorden in de browser op te slaan.
Maar dat lijkt echt ondergeschoven kindje te zijn. Alleen al het feit dat Microsoft de Apple watch niet meer ondersteund voor MFA is hier een voorbeeld van. Zo'n horloge is juist perfect om de MFA stap snel te doen (ipv je telefoon uit je broekzak moeten frutselen en een app opstarten).

[laurens0619]

Dit is echt heel pijnlijk om te lezen

Het ironische is dat
- enkele maatregelen die je noemt een beperkte security waarde hebben en kunnen geschrapt worden
- de maatregelen die wel belangrijk zijn lijken te missen (of zie ik niet)
- De enorme lijst van mfa en wachtwoord prompts maakt je vatbaarder voor phishing aanvallen (bv omdat je gewend bent t de hele tijd in te vullen ergens)

Security at the expense of usability comes at the expense of security.
Als je usability niet meeneemt in je security strategie gaan mensen onveilige alternatieve creeren en ben je slechter af.

[Jacques-Oh]

Naja dat is dus wel wat er gebeurd. Kijk ik snap dat goede SSO etc. geld kost en niet voor ieder kleinschalig bedrijf is weggelegd. Maar als ik 2x hetzelfde wachtwoord moet invullen (bijvoorbeeld het Windows wachtwoord voor zowel Windows als office 365 vanuit dezelfde AD geregeld) dan is dat mijns inziens per definitie 1x teveel.
Meer dan 1x MFA moeten gebruiken op een dag (met uitzondering van bepaalde superkritische functies wellicht) vind ik ook al teveel.

De IT-logica ontgaat dan de menselijke logica. Ik wil dan schreeuwen: JA IK BEN HET STOP BUGGING ME.

[supersnathan94]

"het is toch handig als iedereen erbij kan?"

Heel eerlijk. Dat is wel een valide argument. Niet per se de hele organisatie, maar binnen een team wil ik eigenlijk altijd dat men dezelfde rechten heeft en bij dezelfde dingen kan. Dat niet het team vastloopt als er 1 iemand op vakantie is of ziek wordt, die de enige is die het wachtwoord heeft van “de admin interface van dit en dat” ofzo. Gebeurd veel te vaak en dat kost gewoon geld.

Maar daar zijn gelukkig gewoon oplossingen voor die ook veilig te implementeren zijn.

[Tc99m]

Hiermee bedoelde ik dus personen waarvoor toegang tot een systeem of data "wel handig", maar echt niet noodzakelijk is; niet collega's binnen een team die elkaars werk moeten kunnen overnemen.
En dan nog is het niet altijd wenselijk om iedereen dezelfde rechten en toegang te geven en zijn er legio mogelijkheden om dit soort "single point of failure" situaties te voorkomen; bijvoorbeeld simpelweg meerdere personen met adminrechten rond hebben lopen, zodat in een onvoorziene situatie iemand makkelijk toegang verleend kan worden als ook toevallig een van de admins ziek of op vakantie is.

Daarnaast heb je soms ook simpelweg te maken met (wettelijke) richtlijnen rondom gevoelige (persoons)gegevens, dan kan wel iets super handig zijn, maar is het nog steeds geen valide reden.

[Frame164]

Dan is het niet handig ingericht. Wij hebben gewoon een zakelijk en prive deel op onze smartphones. Intune kan alleen bij het zakelijke deel.

[bilgy_no1]

Ja, zo wordt het uitgelegd. Maar ondertussen kan met Intune al heel veel. Bovendien vind ik het een risico om te installeren en daarmee een externe IT-dienstverlener (waarvan ik geen flauw idee heb wie er allemaal werken) een vector geef om allerlei dingen op mijn telefoon te zien of doen. Ze zeggen op de website uiteraard dat het veilig is, maar ik wil niet het proefkonijn zijn met mijn bank apps e.d.

Eigenlijk vind ik het ook een compleet verkeerd signaal afgeven: installeer deze (potentieel lekke) software met administrator rechten maar gewoon omdat het moet. Dat is precies hoe mensen in de valkuil trappen van callcenter scams en het verzoek om eventjes TeamViewer te installeren en de code door te geven...

[supersnathan94]

Ik snap dat je wat huiverig bent met bank apps, maar ik moet wel zeggen dat juist deze apps iedere vorm van remote aansturing blokkeren. Bepaalde overlays zoals f.lux op android zorgden er al voor dat de app dan niet functioneerde omdat je daar mogelijk input mee af kon vangen en zo de pincodes kon krijgen.

[bilgy_no1]

Dat is heel mooi dat bank apps een extra check hebben op het systeem, maar dat is natuurlijk niet van waarde als ze MS Intune wel toestaan.

[ollie1965]

(op afstand) denk ik dat er op je privé telefoon MS Intune MAM (Mobile Application Management) is gezet, door jezelf neem ik aan en uit vrije wil anders is men niet goed bezig..
Beheerders kunnen dan (Android) alleen de beheerde apps zien/beheren, maar kunnen niet bij de inhoud, IOS (iPhone) daar in tegen heeft wel een privacy probleem, daar kan men ook de privé apps zien (niet de inhoud).

[bilgy_no1]

Ik heb het juist niet op mijn privetelefoon geïnstalleerd, daar ga ik niet mee akkoord. Ik loop nu dus weer met twee telefoons rond.

Mijn bezwaar is niet wat MS nu mogelijk maakt, maar:
1. Hoe vaak zien we niet dat er langzaam steeds meer functies worden toegevoegd, rechten worden uitgebreid etc?
2. De omgeving wordt beheerd door een externe IT-dienstverlener. Ik weet totaal niet wie daar werken en hoe die gescreend worden.
3. Potentieel kan die omgeving lek zijn. Helaas kom je daar pas achter wanneer iemand een exploit heeft gevonden.

Ik ben zelf altijd extreem terughoudend met apps installeren. Dan ga ik zeker niet uit vrije wil een potentiële vector voor problemen creëren.

[the_stickie]

Afhankelijk van de risicoanalyse kan het nodig zijn heel strikte maatregelen in te voeren en (dus) gebruiksgemak op te offeren. Financiële instellingen en overheden zullen bijvoorbeeld een heel ander securitybeleid hebben dan een kmo die dozen schuift.

Imho is gebruikers uitleggen 'waarom' een belangrijk deel van het beleid, en effectiever dan (alleen) technisch alles dicht schroeven.

Dat gezegd zijnde is password expiry niet meer een aanbevolen security maatregel, net omdat je gebruikers uitdaagt hun wachtwoord te noteren/op te slaan en/of te nummeren. Wachtwoorden moeten waar mogelijk vervangen worden door ander authenticatiemethodes (Windows Hello met MFA bijvoorbeeld)

[Llopigat]

Op Android heb je work profile. Dat is best prettig want dan heb je een afgesloten deel op je telefoon voor het werk. Dat kan je ook met 1 druk op de knop uitzetten.

Voor jou is het voordeel dat je werk de prive kant niet kan zien. Welke apps je hebt bijvoorbeeld. Voor hen is het voordeel dat je geen zakelijke data naar prive apps kan kopiëren.

Helaas heeft Apple deze scheiding nog niet dus daar kan een admin bijvoorbeeld nog wel zien welke apps je prive geïnstalleerd hebt. Ze waren er wel mee bezig maar het werkt alleen met hun eigen apps zoals bijvoorbeeld mail dus je hebt er in de praktijk nog niks aan. Maar op Android vind ik het een fijne oplossing.

[Reactie gewijzigd door Llopigat op 23 juli 2024 10:49]

[bilgy_no1]

Tja, maar de organisatie stelt het in via Intune. Dit creëert ook 2 profielen (Werk en Privé). Ik snap het principe wel, daar zit mijn issue niet.

Als het functie is die al in Android zit en niet iets dat via een app wordt beheerd door de IT dienstverlener zou ik er al iets minder moeite mee hebben. Mits heel goed wordt aangegeven wat een werkgever wel/niet kan.

Het beperken van kopiëren via het clipboard blijf ik dan wel erg onhandig vinden. Wij moeten bijvoorbeeld ook apps gebruiken voor declaraties. Maar die kunnen dan weer niet via de Intune store in het werkgedeelte worden geïnstalleerd. Terwijl je soms wel iets moet kopiëren om daar in te vullen. Die Einsteins hadden aanvankelijk nog niet eens een browser toegestaan, waardoor je geen enkele link uit een mailtje kon openen.

En wat is daar de meerwaarde van? Je hebt de telefoon immers ontgrendeld, de MS app ontgrendeld dus je bent het echt wel zelf. Als een hacker toch op dat niveau toegang heeft gaat hij echt niet via je clipboard belangrijke data ontfutselen. Die stuurt hele documenten wel vanuit je eigen mail naar een anoniem adres of zo.

[ollie1965]

Dus niet nagedacht bij uitrollen, alle zakelijke apps moeten in het Intune MAM gedeelte komen. Maar ik moet zeggen IT weet soms ook niet wat voor apps/SaaS er weer door een vakafdeling onder hun radar wordt aangeschaft (alhoewel dat met een declaratie app me wat onwaarschijnlijk lijkt).

En voor in de telefoon werken door een hacker, ik neem aan dat de pincode van je MAM niet hetzelfde is als de van je telefoon. Dus de hacker moet 2x een barrière door.

[bilgy_no1]

Dat bedoel ik: als je al de 3-dubbele authenticatie hebt (telefoon lock en 2FA MS omgeving lock), dan is het kopiëren van een stukje tekst uit een mailtje niet het probleem.

[Llopigat]

En wat is daar de meerwaarde van? Je hebt de telefoon immers ontgrendeld, de MS app ontgrendeld dus je bent het echt wel zelf. Als een hacker toch op dat niveau toegang heeft gaat hij echt niet via je clipboard belangrijke data ontfutselen.

De reden is dat je niet zelf documenten naar niet-toegestane apps gaat sturen zoals bij ons WhatsApp, Dropbox of Google. Bij ons is dat streng verboden en dat wordt op de pc ook geblokkeerd (en USB drives bijvoorbeeld). Dan gaat het meestal niet eens om crimineel gedrag maar meer gebruikers die de regels negeren.

Zie voor een voorbeeld wat daar mis kan gaan juist de Okta hack van dit artikel: een medewerker liep zonder toestemming spul up een prive Google account te bewaren en dat werd gehackt. Dan sta je als bedrijf publiek in je onderbroek terwijl je er geen zicht op had (met je data loss prevention tools). Dat moet je dus helaas voorkomen.

Het lekken van klantgegevens wordt tegenwoordig streng bestraft door bijvoorbeeld de gdpr, en je moet ook een dataverwerkingsovereenkomst hebben met de partijen waar je het opslaat. En gebruikers kiezen te snel de makkelijkste weg dus het is helaas nodig om te zorgen dat dit niet kan met niet door het bedrijf gekozen apps.

Als het functie is die al in Android zit en niet iets dat via een app wordt beheerd door de IT dienstverlener zou ik er al iets minder moeite mee hebben. Mits heel goed wordt aangegeven wat een werkgever wel/niet kan.

Maar dat is het hem juist. Het is een functie die al in Android zit en alleen door de werkgever wordt aangesproken. Juist bedacht door Google om de rechten van zowel de werknemer als de werkgever te respecteren bij BYOD gebruik. Er wordt ook goed uitgelegd wat wel en niet kan. Je werkgever kan niet bij het prive gedeelte, ze kunnen alleen enkele instellingen aan het OS doorgeven zoals WiFi van het werk en een minimum pincode.

Je kan deze functie ook met andere apps aanspreken zoals Island zodat je het voor eigen gebruik kan gebruiken (bijvoorbeeld bepaalde apps in een aparte container zetten)

[Reactie gewijzigd door Llopigat op 23 juli 2024 10:49]

[bilgy_no1]

Ik had het niet over documenten, maar over stukjes tekst, zoals een telefoonnummer kopiëren naar de Telefoon app om een zakelijke klant te bellen.

Als die persoon een telefoonnummer in zijn handtekening zet, dan ga je er gerechtvaardigd van uit dat die persoon ook bereikbaar wil zijn.

En dat het een Android functie is kan ik niet helemaal rijmen met de noodzaak er een MS app voor te moeten installeren. Bovendien wil ik geen externe beheerder op mijn privetelefoon. Dan verschaffen ze maar een telefoon voor de werk apps. Maar dat maakt het werkleven niet handiger.

[Llopigat]

Ja het probleem is als je informatiedelen toestaat tussen de twee delen van de telefoon, dan sta je alles toe. Android heeft niet de mogelijkheid wel copy/paste van tekst toe te staan en niet hele bestanden (via het share paneel). Dat is inderdaad wel iets dat ze zouden kunnen verbeteren. Momenteel is het alles of niets. Maar ook dan komen er vragen om de hoek: Vind je een nummer kopieren goed? Maar wat van een foto of een screenshot met gevoelige data?

Maar de telefoon app is geen probleem: Die kan je namelijk ook in de work profile zetten. Dat doen wij ook. Ik zou het aan de werkgever vragen om dat ook te doen.

En ja het is een ingebouwde android functie maar het is nodig er een device admin app te installeren die het activeert. Dit is een beslissing van google geweest, en het is ook wel logisch want die beheer app bepaalt welke restricties er zijn. Het is namelijk ook mogelijk om copy/paste en bestands delen tussen de twee delen van de telefoon wel toe te staan. Dat soort beslissingen worden genomen door de app die het beheert, die communiceert namelijk met de MDM (Mobile Device Management) van het werk. Dat is niet iets dat ingebouwd zit in Android. Dus die extra app is nodig om de configuratie te doen.

Het is geen ideale oplossing maar naar mijn mening wel eentje die die het op een momenteel zo goed mogelijke manier mogelijk maakt om zakelijke toepassingen op een privetelefoon te gebruiken, met een goed compromis tussen rechten voor het bedrijf en prive. Natuurlijk kan je liever een aparte telefoon willen en dat is bij de meeste werkgevers gewoon mogelijk (ze kunnen je niet verplichten het op je privetelefoon te zetten natuurlijk). Maar als je dat niet handig vindt, is het wel een goede oplossing.

[Reactie gewijzigd door Llopigat op 23 juli 2024 10:49]

[Paprika]

Zou het gebruiken van passkeys en/of traditionele 2FA altijd forceren (dus geen "erkend apparaat" optie en een variant waarbij je eerst een code te zien krijgt, die je vervolgens moet opgeven in je telefoon alvorens je een code krijgt (om er zeker van te zijn dat mensen niet random sessies / prompts die ontstaan in sessies van anderen zomaar kunnen goedkeuren), al een oplossing zijn hier?

Gek dat juist Okta zelf, gezien de dienstverlening, hier voor gemak lijkt te zijn gegaan.

[the_stickie]

Het probleem is dat aan de IT kant van een organisatie er altijd een hoop "gewone" wachtwoorden zijn. Je kan dan wel heel veel koppelen aan AD en/of MFA, maar bijna alles heeft toch nog een admin of root account die je net nodig hebt om net die dingen te configureren. Die sla je op in een sterk beveiligde tool waarmee je kan bepalen wie welke wachtwoorden mag zien/gebruiken. Je doet dan ook auditing zodat je kan nagaan wie wanneer welk wachtwoord heeft opgevraagd.

Maar als dat opgevraagde wachtwoord dan in een andere passwordtool belandt is heel die beveiligde chain ineens ongedaan gemaakt.

[Gwaihir]

Klinkt als een domme setup waarin authenticatie en autorisatie niet goed gescheiden zijn: iedereen heeft m.i. een eigen account. Sommige gebruikers hebben de rechten om vanuit hun eigen account 'sudo' of 'su' zulke admin of root handelingen te verrichten. Daar hoort m.i. geen los admin/root wachtwoord bij, dat in de praktijk bijna niet veilig te houden is en bijna niet meer aan te passen valt.

[Reactie gewijzigd door Gwaihir op 23 juli 2024 10:49]

[the_stickie]

Waar mogelijk werkt ieder met een eigen account, dat spreekt voor zich.
Alleen val je dan vaak/meestal terug op authenticatie uit/door een andere bron. Wat doe je als dat dat om één of andere reden niet meer werkt? Juist ja, de admin/root opsnorren.

[Gwaihir]

Of de instance weggooien en nieuw uitrollen? Ben je van alle vaagheid erin af.
(Best veel te zeggen voor een beweging richting immutable infrastructure .)

[the_stickie]

leuk met een fysieke switch of een remote firewall

Anders gezegd: ja er zijn verschillende manieren om het risico dat wachtwoorden vormen te mitigeren, maar dat maakt niet dat risico's verdwijnen

[BvdW1978]

Honderd punten natuurlijk, want zo werkt dat spul in de echte wereld momenteel nog wel. Dat zou alleen ook wel eens anders mogen. Hoezo kan toegang tot een netwerkappliance niet via een IDP? Die apparaten kosten letterlijk duizenden tot tienduizenden euro's. Een beetje leuke ARM-core om dit soort dingen te regelen is tientjeswerk.

[Blokker_1999]

Heel wat appliances en applicaties hebben geen optie om enkel en alleen op je identity provider te werken. En dat is soms maar goed ook. Heb je ineens een probleem waardoor je idp niet meer bereikbaar is, kan je nier meer aanmelden met je persoonlijke account en kan je het probleem niet oplossen als niemand nog een lokaal admin account kan benaderen.

Zulke nood accounts horen een zeer sterk wachtwoord te hebben en een zogenaamde breakglass procedure om het wachtwoord te achterhalen. Dat kan met een goede wachtwoordtool zijn, maar dat kan evengoed een uitgeprint wachtwoord op een stuk papier zijn dat in een kluis licht waar het hoogste management toestemming voor moet geven om het eruit te halen.

[supersnathan94]

Voor het automatisch configureren van zaken binnen CI/CD heb je wel degelijk gewoon zaken nodig als API keys en admin creds.

Dat kan soms niet anders dan dat je een los account hebt. Zo heb je bij Elastic cloud altijd een beheerdersaccount waar je dan je deployments mee kunt managen. Die moet je heel goed dicht zetten en het liefst in 2 offline password managers opslaan op een device wat in een kluis terecht komt ofzo.

Daar kun je geen AD koppeling tegenaan gooien want je hebt dat account nodig om die koppeling op te kunnen zetten.

[iqcgubon]

Shoutout naar een van de IT managers hier met "Copy of passwords (1).xlsx" op haar bureaublad lockt uiteraard ook nooit de laptop.

Als ik daar iets van zeg zijn het mijn zaken niet en melden aan secops doet ook niks dus ja.

[Reactie gewijzigd door iqcgubon op 23 juli 2024 10:49]

[Get!em]

Oeh, dat vraagt om gehackt te worden.

En ik heb al een scenario waarin oa excel zelf daarin meespeelt om die informatie op te halen..

[akooijman]

En Windows dat dan braaf zo'n bestand indexeert cq doorzoekbaar maakt. Handig toch?

[helldogbe]

Ben wel benieuwd naar de leeftijd, want klinkt als iemand die hopelijk nabij het einde van de carrière is...

[supersnathan94]

Ik weet niet of jullie een ISO 27001 certificering hebben, maar lijkt mij dat dit bij upper management wel even aan de kaak gesteld kan worden. Dat zijn namelijk al 3 “schendingen” in 1.

[latka]

Paswoorden zijn onmogelijk veilig te krijgen zolang er mensen in de keten zitten. Als we dat nou gewoon eens loslaten dan is er geen policy of 'company approved tool' nodig. Notepad en een docje op dropbox is veel eenvoudiger in het gebruik dan wat IT kan verzinnen dus gebruikers gaan er gewoon omheen werken omdat security nooit het doel van een organisatie kan zijn (de 'core business' zeg maar). Dus het zit altijd in de aanpalende omgeving, zoals uren-administratie, bonnetjes declareren en persoonlijke ontwikkelplannen schrijven. Als we met dat in het achterhoofd gaan beveiligen wordt het wellicht nog wat.

[rvt1]

Wij hebben geen wachtwoord manager zoals 1Password. Het enige wachtwoord dat ik hoef te weten is mij eigen om mijn laptop open te klappen en in te loggen op de VPN (via 2FA).
Alles andere systemen zijn via NPA en MFA. Er valt geen enkel wachtwoord te stelen. Je moet namelijk nog een andere bevestiging geven.
Voorts zijn alle productie omgevingen met 4 ogen principes…

[the_stickie]

Ben je dan ook beheerder/admin?
Ik heb al heel wat omgevingen gezien, maar geen enkele die ook voor de IT admins 100% wachtwoordvrij is.
Bij de 'high security' omgevingen waar ik werkte (financiële wereld) was alles voor dagdagelijks beheer prima geregeld, maar had ik desgewenst meestal wel toegang tot admin/root accounts van allerhande hardware.
Ik had wel plots iemand van het SOC naast m'n bureau als ik hen niet op voorhand verwittigde dat ik ze ging gebruiken (en je kan maar best zorgen dat je een approved CR kan linken aan je acties)

Imho is het zeker niet onverstandig een fallback te houden met een 'gewoon' sterk wachtwoord voor noodgevallen - dat niet jan en alleman daar toegang toe heeft, lijkt me evident.

[rvt1]

Ik zit op een kubernettes cluster. Alleen op een test omgeving hebben we Shell, maar daar valt niets te doen. Alle andere omgevingen hebben we geen Shell toegang alle log komt op elastic search machines terecht.

[the_stickie]

Je hebt dus geen toegang tot de infra zoals hypervisor, de ipmi (ilo/idrac/...), storage, switches, firewalls, IPAM,....? net die dingen waar het imo gebruikelijk is dat er fallback wachwoorden bestaan.
Imho is dat ook logisch aangezien de nood voor troubleshooting op die levels kan betekenen dat er geen OS, connectiviteit,... is, en externe authenticatie gewoon niet mogelijk is.

Ik gok dat er bij jullie ook ergens een passwordtool bestaat, voor de infra jongens

[rvt1]

Je hebt dus geen toegang tot de infra zoals hypervisor, de ipmi (ilo/idrac/...), storage, switches, firewalls, IPAM,....?

Nee, geen toegang tot deze systemen. Wijzigingen lopen via een portal die vervolgens via een pipeline gedeployed worden. Alle deployment zijn dan weer volgens 4ogen principe en dus meer dan een persoon moet de pipeline goedkeuren.
En ja, dus ook wachtwoord tools via 4 ogen met NPA’s die geldig zijn voor tijds periodes.

[catmanpatrick]

zuur zo'n klein menselijk foutje, maar bizar dat personal account van google hiertoe rechten heeft.

[the_stickie]

Het betreft een gebruiker die wachtwoorden uit de password tool copy-pastete en vervolgens Chrome het wachtwoord liet opslaan, per ongeluk of voor het eigen gemak. Zonder softwareveleid en bijhorende policies (default dus) is dat bij alle browsers mogelijk.
Dit is een reden waarom het nog steeds noodzakelijk is limieten te leggen op welke software geïnstalleerd en/of gebruikt mag worden én voor de gekozen tools/software de nodige policies in te stellen om gebruikers (en admins) binnen de lijntjes te houden.

[Reactie gewijzigd door the_stickie op 23 juli 2024 10:49]

[Gwaihir]

De mate waarin al dat kopiëren naar de cloud 'default' is, vind ik de verantwoordelijkheid van de makers van die tools, dus Google, Microsoft, et al. Ik vind het tamelijk schofterig hoe vaak hun spullen op eigen initiatief zaken spontaan van het een naar het ander kopiëren.

Nu bijvoorbeeld blijft mijn Android device hardnekkig met het binnen harken van Drive bestanden in de weer. Dit omdat ik ooit één keer op drive ben ingelogd op dat ding om iets te raadplegen. Nooit om een off-line sync van van alles en nog wat naar dat device gevraagd en kom er kennelijk ook niet meer vanaf.

Omgekeerd soortgelijk geneuzel met Microsoft spul dat naar OneDrive een 'backup' maakt zonder dat ik dat wil. (Iets makkelijker te stoppen, maar komt ook regelmatig terug.)

Zo lang redelijk normaal gedrag - als bijv. even inloggen op gmail via het web - steeds meer bijverschijnselen triggert, gaan dit soort problemen ook steeds vaker voorkomen. Kennelijk gaat deze data diefstal door de grote cloud partijen verder en verder totdat deze van overheidswege aan banden gelegd wordt.

[CAPSLOCK2000]

Ik ben het voor 90% met je eens, deze bedrijven zijn veel te gemakkelijk in hoe ze alles naar de cloud halen. Begrijpelijk, want zo hebben ze een veel sterkere grip op de klanten.

(Het volgende aub niet persoonlijk opvatten, ik heb niet over jou specifiek maar de bezoekers van deze site in het algemeen).

Maar de laatste 10% leg ik bij de gebruikers die er voor kiezen met deze bedrijven in zee te gaan. We zien het steeds weer misgaan en toch blijft men massaal met beide benen in trappen. Ik snap dat je op veel punten eigenlijk geen keus hebt maar de meeste mensen proberen het niet eens en geven zich volledig over. Beetje klagen en that's it.

Iedereen met ook maar het minste greintje verstand van de situatie ziet de problemen al jaren aankomen er is maar een kleine minderheid die iets doet. 99% procent logt zo toch weer in bij Microsoft, Google, zonder ook maar een seconde te proberen om los te komen. Daarbij kijk ik vooral naar techneuten & tweakers want dat zijn de mensen met de kennis en de kunde om er iets aan te doen. Wij geven echter massaal het verkeerde voorbeeld.

Ik ben het met je eens dat deze grote bedrijven veel te makkelijk onze data naar zich toe trekken, maar wij laten dat wel veel te makkelijk gebeuren. Klagen over het gedrag van die grote bedrijven is als klagen over de zwaartekracht. Het is volkomen voorspelbaar en eigenlijk logisch gedrag en volledig consistent met wat ze al jaren doen.

Ja, ze bieden ook veel fijne diensten voor weinig geld, maar daar wordt erg naief mee omgegaan.
Als een hotel aankondigt dat de kamers voortaan gratis zijn dan beseft iedereen dat er iets niet klopt, dan ga je vanzelf nadenken: Waar zitten de verborgen kost? Is de minibar heel duur? Wordt je auto leeggeroofd? Komt er zo een pooier onderhandelen over extra diensten? Is het een dekmantel voor een criminele organisatie? Hangen er camera's boven het bed? Steelt de receptie je creditcardgegevens?

(Het geeft ook nog de vreemde dynamiek dat er geklaagd wordt dat mensen nergens voor willen betalen, terwijl deze bedrijven zelf de illusie scheppen dat hun product gratis is en er alles aan doen om de echte kosten te verbergen.).

[Gwaihir]

Nou ja, ik wil daar best vanuit mij persoonlijk op reageren hoor .

Ik geef mij zeker niet volledig over, maar 'het goede voorbeeld geven' wordt bewust erg vermoeiend gemaakt (dark pattern), zodat het moeilijk volledig vol te houden is. En deels ben ik het met je 'voor niets gaat de zon op' eens, maar voor mijn Windows en Office licenties heb ik gewoon betaald, en voor mijn Android licentie (via de fabrikant) ook.

[CAPSLOCK2000]

En deels ben ik het met je 'voor niets gaat de zon op' eens, maar voor mijn Windows en Office licenties heb ik gewoon betaald,

De meeste mensen betalen voor Windows en Apple omdat je geen computer kan zonder kopen zonder voorgeinstalleerd OS (tenzij je het systeem zelf bouwt). Aangezien dit Tweakers is wil ik wel geloven dat jij weloverwogen een volledige Windows Pro licentie hebt gekocht. Waarschijnlijk doe je vele jaren met zo'n licentie en betaal je per jaar als nog niet veel. En dan is Windows zo'n beetje de meest verkocht software ter wereld met alle bijkomende schaalvoordelen van dien. Zelfs daarbij worden de kosten min of meer verborgen gehouden voor de gebruiker die alleen de totaalprijs van de computer ziet.

Ergens is het gek dat we meer betalen voor de hardware dan voor de software terwijl die software in mijn ogen veel meer waard is. De reden is dat dat software zo duur is dat bijkna niemand de volledige prijs kan/wil betalen. Wie dat wel kan heeft vervolgens hoge verwachtingen aan de kwaliteit die niet waar gemaakt kunnen worden. De oplossing die we bedacht hebben is dat we software als een soort lease-constructie behandelen. Je betaalt een klein deel van de prijs (of niks) vooraf en betaalt de rest tijdens het gebruik met geld, data of reclame. Ondertussen zal je moeten leven met de kwaliteit zoals geboden want je hebt geen relatie met de softwareleverancier waarin je eisen kan stellen of om garantie kan vragen.

en voor mijn Android licentie (via de fabrikant) ook.

Is Android niet gratis dan? Mogelijk dat je wel voor Googles Playstore en andere apps moet betalen, maar het basissysteem zou gratis moeten zijn. De hardwarefabrikanten, Google en de Linuxcommunity doen samen het zware werk zonder er geld voor te vragen. Ze beschouwen de software als noodzakelijke investering om hun producten te verkopen.

Ik zou willen dat overheden flink zouden investeren in vrije software die in ieders voordeel is. Net zoals de overheid investeert in goede wegen, elektriciteit, onderwijs en gezondheidszorg. Iedereen zelf z'n eigen snelweg en ziekenhuisje laten aanleggen is niet efficient en alleen haalbaar voor de allerrijksten. Laat de overheid zorgen voor basisvoorzieningen die iedereen nodig heeft. (Het werk kan nog steeds door de markt worden gedaan, net zoals onze wegen worden onderhouden door commerciele bedrijven die door de overheid worden betaalt).

[SPee]

Met een ww-manager buiten de browser was dit probleem er ook niet.

Door dan een policy in te stellen dat je zo'n tool niet mag installeren (bij 90% is een ww-manager niet standaard geïnstalleerd) help zeker niet. Naast dat het ook vaak negatieve invloed heeft op het werk van een medewerker als die voor elk dingetje naar systeembeheer moet. Er is vast wel een concurent waar die medewerker niet wordt beperkt in zijn werk.

[the_stickie]

Voor de bedrijfswachtwoorden heb je een centrale tool: geen nood aan een persoonlijk kluisje.
Als een collega dat toch noodzakelijk acht, heb ik er persoonlijk niets op tegen dat ie ophoepelt

Overigens heeft elke computer met een browser tegenwoordig een rudimentaire wachtwoordbeheertool, en dat is net het probleem...

[Reactie gewijzigd door the_stickie op 23 juli 2024 10:49]

[DonJunior]

Als een collega dat toch noodzakelijk acht, heb ik er persoonlijk niets op tegen dat ie ophoepelt

Fijne collega..

[magician2000]

Maar hoeveel bedrijven gebruiken zo'n tool?

[supersnathan94]

Te weinig.

[magician2000]

Waardoor dus dit probleem kan ontstaan, mensen die zelf iets gaan gebruiken voor het beheren van wachtwoorden. Een stuk papier is nog altijd het veiligst. Zolang je dit niet in de buurt van de computer legt en niet aangeeft wat die woordenreeks betekend.

[blorf]

Persoonlijk heb ik er niks mee. Wachtwoorden versleuteld lokaal opslaan? Wat als de GUI I/O wordt gehackt en iemand krijgt een vervalst login-scherm gepresenteerd? Of een proces onderschept browser-data op gebruikers-niveau en trekt daar een reeks uit die het wachtwoord moet voorstellen, en gebruikt dat ergens anders? Volgens mij kan iemand met niet eens heel bijzondere permissies al rare dingen uithalen met een lokale wachtwoord-database...

[Reactie gewijzigd door blorf op 23 juli 2024 10:49]

[kodak]

Het lijkt mij vooral een reden dat browsers niet zomaar gegevens verwerken wanneer iemand met een account ingelogd is.

Het toepassen van de accounts lijkt anders namelijk gericht op negeren van veiligheid. En aangezien het vaak gaat om accounts bij dienstverleners die maling hebben of ze de gegevens wel horen te verwerken is er geen reden het verwerken pas te stoppen na een opt-out.

[latka]

Of paswoorden uitzetten en overal 2FA doen. Dan bestaat het probleem niet meer. Dat gedoe met policies is arbeidsverschaffing en schijn veiligheid.

[the_stickie]

Voor zover de te beveiligen oplossing externe authenticatie ondersteund: ja. Maar dan nog hebben beheerders soms toegang nodig met de 'oorspronkelijke' root/admin en moet dat wachtwoord beheerd worden.

[latka]

Beheerder met altijd toegang zijn zowiezo natuurlijk een no-go in een secure omgeving: als de beheerder het kan dan kan een bad-guy het uiteindelijk ook (na social engineer of security fail). Beter is om te zorgen dat dit dus niet hoeft. En diensten die geen 2FA ondersteunen uitzetten is natuurlijk een optie.

[the_stickie]

Als er MFA en auditing op de pw tool zit, zie ik het probleem niet zo.
ik denk niet dat het een optie is beheersconsole van allerlei hardware uit te zetten

[GoBieN-Be]

Ik zou voor zo'n gevoelige omgeving verwachten dat men werkt met een Shared Computing platform (Citrix of RDS Server) of een Virtuele Cloud PC omgeving die volledig door policies dicht getimmerd is.

Maar ik merk sowieso dat Shared Computing minder gebruikt wordt in de V.S. dan hier in Europa.

[nst6ldr]

Als ik het zo lees is dit meer een fout van het bedrijf, de maatregelen die ze nu pas nemen zijn zeer doorsnee. Dat geeft te denken wat ze nog meer niet in orde hebben.

[the_stickie]

Toch zijn er maar weinig bedrijven die het gebruikers onmogelijk maken met hun persoonlijk account aan te melden in hun browser én alternatieve browsers afdoende blokkeren... niet te vergeten dat je bijvoorbeeld chrome zonder admin rechten kan installeren en dat Edge je (zonder policies) gewoon aanmoedigt om je persoonlijke account aan je werkaccount te linken...

[nst6ldr]

Dat klopt, er zijn weinig bedrijven die serieus iets met informatiebeveiliging doen. Veelal wordt het als een bezigheid van beheerders gezien.

[84hannes]

Er zijn ook weinig bedrijven die zich bezighouden met verkeersveiligheid. Gelukkig is dat allemaal zo goed geregeld dat dat ook niet hoeft! Het feit dat je als willekeurig bedrijf jezelf bezig moet houden met IT-veiligheid toont aan dat het ecosysteem van zichzelf niet veilig is.

[downtime]

Ik zou het met arboregels vergelijken. Je kunt er als overheid wel regels voor hebben maar de uitvoering is toch echt aan de bedrijven zelf. Vergelijkbaar met verkeersveiligheid is het niet omdat het verkeer zich in de publieke ruimte afspeelt en de overheid die rol wel moet pakken.

[84hannes]

Ik zou het met arboregels vergelijken

Dat is misschien een betere vergelijking. Als je speciale dingen doet, een werkplaats of een laboratorium, dan kan ik me voorstellen dat je verstand van arboregels moet hebben. Maar waarom voldoet het kantoormeubilair dat door de groothandel wordt geleverd niet gewoon aan de algemene arboregels?

[CAPSLOCK2000]

Dat is misschien een betere vergelijking. Als je speciale dingen doet, een werkplaats of een laboratorium, dan kan ik me voorstellen dat je verstand van arboregels moet hebben. Maar waarom voldoet het kantoormeubilair dat door de groothandel wordt geleverd niet gewoon aan de algemene arboregels?

Omdat het te duur is.

We leven op een techobubbel van verborgen kosten, legacy en technical debt. IT is verschrikkelijk duur en IT die op álle punten goed is helemaal. Een IT'er kost al snel €100/uur, als het niet veel meer is. De meest eenvoudige website zou dus al minstens €1000 per jaar moeten kosten als je iemand eens per maand 1 uur onderhoud doet. En dan hebben we het nog over de absolute basis. Even kijken of er updates zijn en die installeren, af en toe de instelling nakijken, beetje logs in de gaten houden. Dan ga ik er nog vanuit dat je een grote shared hosting omgeving hebt want als je handmatig wordpress of zo iets gaat beheren gaat het nog veel meer tijd kosten. Dan hebben we het nog niet eens gehad over het inhoudelijke werk zoals maken van foto's, schrijven van teksten of reageren op e-mails.

De meeste bedrijven kunnen eigenlijk niet betalen voor de IT die ze gebruiken en dat weten de softwarebouwers best. Die bieden dus alles zo kaal mogelijk aan, ontdaan van wat ze er af kunnen halen ook al kun je eigenlijk niet zonder. Als ze een volledig product zouden aanbieden zouden ze het niet verkocht krijgen. Dan moet je bijbetalen om updates te krijgen of om backups te kunnen maken, zitten features als 2fa in losse (betaalde) modules, moet je aparte licenties kopen voor je dev/test/acc omgevingen of is de helpdesk waardeloos of heel duur.
Dat heeft dan ook nog het gevolg dat er veel te lang wordt doorgedraaid op oude en slecht onderhoude software waardoor het steeds moeilijker en duurder wordt om te verbeteren.

Tot op zekere hoogte kun je die bedrijven niet verwijten dat ze vekopen wat het publiek wil, maar ze hebben zelf wel een flinke vinger in de pap gehad bij het scheppen van het beeld dat IT goedkoop is en zo "gebruikersvriendelijk" dat iedere leek alles zelf kan doen en dat het niet de verantwoordelijkheid van de leverancier is.

Maar... als je ziet hoeveel winst de grote softwarebedrijven maken dan is er veel ruimte voor verbetering zonder dat de prijzen hoeven te stijgen. Dergelijke hoge marges wijzen op een markt die niet functioneert. Op een goed functionerende markt zorgt concurrentie er namelijk voor dat de prijzen laag blijven en er net genoeg winst wordt gemaakt om het bedrijf te laten overleven, anders komt er wel een ander bedrijf dat de markt over neemt met lagere prijzen. Daarom is het ook zo lachwekkend om te zien hoe deze grote bedrijven proberen te beargumenteren dat ze helemaal niet groot zijn en maar een klein spelertje zonder invloed op de markt door de hele markt op te knippen in deelgebiedjes terwijl ze op alle ander punten gewoon als één groot bedrijf functioneren. De winsten liegen niet.

[84hannes]

Tot op zekere hoogte kun je die bedrijven niet verwijten dat ze vekopen wat het publiek wil

Toch is daar in de consumentenmarkt regelgeving voor; je mag geen ondeugdelijk product verkopen: het moet minimaal twee jaar zonder problemen werken, het mag niet giftig zijn etc. Wat het publiek wil is dus niet altijd doorslaggevend. Maar zakelijk mag je veel meer, dus mag je ook een onveilige werkomgeving verkopen.

[the_stickie]

Als je het niet zelf wil doen, kan je het uitbesteden.
Imho is de vergelijking met verkeersveiligheid krom omdat dat een publieke aangelegenheid is. ik zou eerder vergelijken met inbraakbeveiliging of veiligheid/ongevalpreventie op de werkvloer.

[helldogbe]

Tevens is verkeersveiligheid wel degelijk iets waar interne regelgeving, opleiding en handhaving voor nodig zijn als er sprake is van mobiliteit binnen het bedrijf.
Kan ik vertellen werkende bij een bedrijf waar personeel zich verplaatst met volgende middelen: te voet, met steps, te fiets, per caddy, per heftruck, per auto, per vrachtwagen, per hoogtewerker.

[dasiro]

In dit geval is het de core business van het bedrijf, maar in alle andere gevallen is het logisch dat dit door beheerders wordt geregeld, omdat users zelf niet op de hoogte zijn van de implicaties.

[nst6ldr]

Beheerders zijn uitvoerend, die zouden in het kader van infosec hooguit reageren op bulletins (hotfixes doorvoeren), audits en adviesrapporten van een (eventueel ingehuurde) infosec consultant of CISO. Je zou een beheerder niet moeten belasten met het bedenken en invullen van het beleid rondom infosec.

[dasiro]

vaak zijn dat de enigen die er mee te maken hebben, zelfs in bedrijven tot 1000 of meer werknemers zijn er amper dedicated functies voor, laat staan afdelingen die er mee bezig zijn. Het is een heel uitgebreid onderwerp dat zwaar onderbelicht wordt, maar helaas voor degenen die er wel mee in contact komen de harde realiteit en wel hierom: De kans op waardeverlies wordt zo laag ingeschat dat er eerder een badge-systeem dan een DLP-policy zal worden ingevoerd. De mensen aan de top zullen het erger vinden dat een laptop gestolen wordt, dan dat de data die er op stond bij iemand anders terecht komt.

[CAPSLOCK2000]

Beheerders zijn uitvoerend, die zouden in het kader van infosec hooguit reageren op bulletins (hotfixes doorvoeren), audits en adviesrapporten van een (eventueel ingehuurde) infosec consultant of CISO. Je zou een beheerder niet moeten belasten met het bedenken en invullen van het beleid rondom infosec.

Ik vind dit slecht advies.

Security is een proces en een compromis. Het is nooit een simpel "ja/nee, dit doet, doe dat" antwoord maar altijd een complexe afweging tussen belangen. Het idee dat je iemand van buiten een paar uurtjes onderzoek laat doen en daar dan een zinnig advies uit krijgt is lachwekkend, ik heb dat nog nooit goed zien gaan. Dat soort rapporten staat typisch vol met gemeenplaatsen en vaagheden waar je eigenlijk niks mee kan.
De feitelijke bevindingen zijn eigenlijk nooit een verassing, het eigen personeel weet meestal best hoe het zit en waar de zwakke punten zitten. Dit soort rapporten zijn dan ook voor managers die zelf niet in staat zijn de situatie te beoordelen en het oordeel en inzicht van hun eigen personeel niet vertrouwen.

Het helpt ook niet dat er een hoop beunhazen rondlopen, mensen zonder technische achtergrond die eigenlijk niet weten waar ze het over hebben en zich dus bij alles vastklampen aan standaarden, best practies en voorschriften die ze eigenlijk niet begrijpen en dus stug vasthouden aan de letter zonder idee te hebben van de geest .

Voorbeeld: Zo was er ooit de regel "altijd 2fa gebruiken". Prima regel die iedere IT'er snapt... tot ik in een vergadering werd geroepen omdat een server ging vingers heeft om op de knopjes van een mobiele telefoon te drukken om 2fa te doen.... Daarmee verloor ik direct mijn vertrouwen in de hele altijd-2fa-regel in die organisatie. Hoewel het op papier een prima regel is heb je er niks aan als je niet weet hoe je het moet interpreteren. Dit soort regels zijn altijd deel van een groot geheel en moeten in context gezien worden. Als je denkt het hele beleid terug te kunnen brengen tot drie woorden ("altijd 2fa gebruiken") zal je moeten weten wat er achter zit.

Er is een groot tekort aan mensen met verstand van zaken en dientegevolgen worden er veel te veel mensen aangenomen die eigenlijk niet meer hebben dan een grote bek en die daar mee wegkomen omdat ze vooral samenwerken met mensen die het zelf ook niet weten.

Het is misschien niet hoe het zou moeten maar IT (security) consultancy is als traditionele geneeskunde: 10% echte kennis, 10% vuistregels en ezelsbruggetjes, 10% geluk en 70% rituele dans, trommelgeroffel, vuurwerk en offers aan de goden.

[nst6ldr]

Hoezo maakt de functieomschrijving van een consultant of CISO het een slecht advies om er een in dienst te nemen? Ik lees dat je ergens slechte ervaring hebt opgedaan met beunhazen op zo'n functie, maar dat kan je van ieder beroep stellen: een beunhaas CFO kan net zo goed een bedrijf de grond in helpen.

[CAPSLOCK2000]

Hoezo maakt de functieomschrijving van een consultant of CISO het een slecht advies om er een in dienst te nemen? Ik lees dat je ergens slechte ervaring hebt opgedaan met beunhazen op zo'n functie, maar dat kan je van ieder beroep stellen: een beunhaas CFO kan net zo goed een bedrijf de grond in helpen.

Het gaat niet om de functieomschrijving (die draag ik zelf ook).

Het gaat om de volgende aspecten:
1. security/it-beleid voeren op grond van /ingehuurde/ consultants.
2. stricte scheiding tussen beheer en beleid, klinkt leuk maar werkt niet want het geef onrealistisch en onuitvoerbaar beleid. Ik zeg niet dat het nooit kan werken maar IT-security is daar nog lang niet. Je beheerders alleen zien als uitvoerend is een gruwelijke onderschatting van de praktijk.
3. passief afwachten op input van anderen is slecht beheer. Om dingen goed te beheren wil je dat je beheerders actief meewerken aan verbetering. Zij zijn de specialisten en niemand kent de omgeving beter. Consultants kunnen daarbij helpen maar niet leiden.
4. IT-security is een cowboymarkt, het percentage beunhazen is erg hoog, daar kun je maar beter rekening mee houden.

[the_stickie]

Dat zeker!
Er is ook vaak een soort onfeilbaar vertrouwen in die beheerders, waardoor die als goden boven alle regels en policies staan - het zijn natuurlijk meestal zij die de regels maken en implemnteren.

Zonder SOC is het bijna een garantie dat admins teveel toegangen hebben. SOC's zie je vooralsnog voornamelijk in de financiêle wereld en bij écht grote bedrijven.

[Mellow Jack]

SOC gaat je vertellen dat je gehacked bent of dat iemand iets raars doet. Een IAM (identity & access management) systeem icm PAM (priv account management) kan dit voor je oplossen. Die kunnen eventueel rapporteren aan een SOC

[the_stickie]

Akkoord...
De SOC houdt normaliter een oog over de toepassing van de security regels. Ik haalde de SOC aan als indicator van maturiteit. Je hebt immers niks aan IAM en PAM als admins zich nog steeds god wanen (maw admins niet gecontroleerd worden)

[Blokker_1999]

Ik ben inderdaad in zo een situatie beland bij mijn huidige werkgever, en het is moeilijk om dat schip te keren. Maar ik, als systeembeheerder, werk er wel aan om dat stilaan weg te werken.

Maar je moet dan weer een goede balans zien te vinden. Iets beveiligen is eenvoudig, iets goed beveiligen zodat het gebruiksvriendelijk blijft daarentegen ...

[Cergorach]

Dat klopt, er zijn weinig bedrijven die serieus iets met informatiebeveiliging doen.

Mee eens, want het gros van de (kleine) bedrijven zijn geen organisaties waarbij dit zo belangrijk is dat ze complete security afdelingen draaien die de beheerders aansturen op dit soort zaken. Echter zou je van bepaalde branches dit toch juist wel mogen verwachten! Helemaal een bedrijf dat dergelijke 'identity and access management' diensten verkoopt...

Het gelazer bij Okta de afgelopen paar jaar zal imho de uiteindelijke doodsteek zijn van dit bedrijf. Zelfs de investeerders zien dat! Kijk eens hoe hoog het aandeel stond tijdens de piek van de pandemie. Zelfs ivm. voor de pandemie zijn de aandelen lager dan voorheen, juist in een markt die significant is uitgebreid. Het zou mij helemaal niets verbazen dat heel veel afnemers zijn weg gemigreerd bij Okta en dat meer zullen volgen...

Bron:
https://www.nasdaq.com/market-activity/stocks/okta

[WouterL]

Maar er even vanuitgaande dat de zakelijke inlog gegevens waren gehacked van een medewerker; dan had een simpele MFA toch kunnen voorkomen dat je hier ook daadwerkelijk iets mee had gekund?

[the_stickie]

In principe wel inderdaad.
Jammer genoeg is het niet voor alle toepassingen mogelijk MFA te implementeren....

[Transportman]

Bij mij op het werk hebben ze recent veelgebruikte alternatieve browsers weer centraal aangeboden omdat teveel mensen het zelf installeerden of met portable versies aan de gang waren. Zelf maak ik me daar met Keepass ook 'schuldig' aan, die wordt wel centraal aangeboden maar komt in Program Files te staan waardoor je geen plugins kan installeren die nodig zijn om de werking in browsers mogelijk te maken waardoor de kans op een onjuiste copy-paste/invulactie enorm toeneemt en geen rechten om een password generator in te stellen die wachtwoorden kan genereren die daadwerkelijk aan de requirements voldoet, terwijl ik dat met de portable wel kan doen.

Het is aan de ene kant dus veel werk voor beheerders om dat soort installaties en policies te onderhouden, maar als ze het te strak afstellen gaan mensen ook weer er omheen werken en wordt het juist minder veilig.

[the_stickie]

Het hangt af van de afweging security/usability en de risicoinschatting.
Ook is niet elke gebruiker gelijk.
Afhankelijk van de situatie loont het werk om het allemaal te managen zeker wel, maar waarschijnlijk niet voor de bakker om de hoek.

Wat je eigen scenario betreft, je kan altijd de situatie uitleggen. Als het goed is worden goede argumenten meegenomen en komt er verbetering.

[CAPSLOCK2000]

Het is aan de ene kant dus veel werk voor beheerders om dat soort installaties en policies te onderhouden, maar als ze het te strak afstellen gaan mensen ook weer er omheen werken en wordt het juist minder veilig.

Het echte probleem zit niet bij de beheerders maar bij de bazen. Werknemers weten instinctief heel goed wat hun baas wil, waar ze mee weg komen en waar ze gezeik mee krijgen. Over het algemeen is het zo dat je veel gezeik krijgt als je werk niet op tijd klaar is en dat je weinig gezeik krijgt als er iets mis gaat met de beveiliging. Als mensen moeten kiezen tussen snel of veilig zullen ze altijd voor snel kiezen want dat is waar ze op worden afgerekend. Datzelfde zie je overal, bijvoorbeeld bij bezorgers die grote risico's in het verkeer nemen omdat ze meer gezeik krijgen als ze te laat bezorgen dan wanneer ze gevaarlijk rijden.

Precies zoals je zegt gaan mensen om regels heen werken als ze er te veel last van hebben. Het heeft geen zin om de regels strenger te maken als mensen niet worden afgerekend op overtredingen. Als ze tegelijkertijd wel worden afgerekend op "traagheid" omdat ze zich aan de regels hebben gehouden dan hebben de regels gewoon geen zin.

[kodak]

Ik kan dit geen klein foutje noemen. Het bedrijf verwerkt, in opdracht van grote dienstverleners als passwordmanagers, pakket/vrachtvervoer, videoconferencediensten, energiebedrijven, telecombedrijven enz diensten waar heel veel belangrijke gegevens mee gemoeid zijn. Bedenk even wat ze dan allemaal moeten hebben nagelaten om dit mis te laten gaan, als ze nu pas een policy nodig vinden.
Bedenk ook dat er bijvoorbeeld wettelijke plicht is om (persoonlijke)klantgegevens te beschermen en veel klanten zwaar afhankelijk zijn van wat het bedrijf doet en na laat.
Dan dit soort blunders begaan en pas ontdekken nadat het is mis gegaan zijn dan eerder meerdere zware gebreken.
Het klinkt niet al een bedrijf dat voldoende bewust is van de verantwoordelijkheid en risico's. Wat het daarbij nog ernstiger maakt is dat ze zich verkopen als bedrijf dat je op gebied van authenticatie kan inhuren, terwijl ze eerder zelf hulp nodig hebben de basisprincipes uit te voeren.

[Genosha]

Ik zit mij in eerste instantie af te vragen waarom je überhaupt inlogt in je browser...?

[WouterL]

Bookmarks, privé meuk etc. Genoeg redenen. Of het slim is, is een tweede.

[TheMak]

Ik moet het zelf eens controleren of ik niet ingelogged ben omdat ik met gmail-account weleens gecheckt heb.

[Blokker_1999]

Met al die webdiensten de dag van vandaag, waar zou je anders inloggen?

[DeCo]

Even los van het feit dat het onjuist is een privé account te gebruiken voor zakelijke wachtwoorden... ik hoor niemand de vraag stellen, hoe dat persoonlijke Google account gehackt is. Iedereen stapt daar blijkbaar doodleuk overheen.
Is zijn persoonlijke laptop/telefoon/apparaat gestolen? Is er op een andere manier ingebroken in dat account?
Moeten we de wachtwoord managers van Mozilla, Google, Apple en Microsoft vanaf nu dan maar volledig wantrouwen? Zowel zakelijk als persoonlijk?
Er rijzen alleen maar meer vragen bij me op bij dit bericht.

[Reactie gewijzigd door DeCo op 23 juli 2024 10:49]

[Groningerkoek]

Die vraag stellen we niet omdat niemand daar het antwoord op heeft. Tweakers brengt het als feit dat deze account is gehacked, maar Okta (Notabene een quote via een link uit het Tweakers artikel) zelf zegt dit:

"The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device. "

Het is dus volgens hen de meest waarschijnlijke optie en alles behalve een feit.

Lees je mee: @JayStout

[DeCo]

En worden dus policies gemaakt op basis van aannames..

[the_stickie]

Als er potentiële (en mogelijk misbruikte) gaten worden vastgesteld, is het toch logisch dat je er wat aan doet

[kodak]

Niet slechts een aanname. Dat een account van een ander een risico vormt is namelijk een feit. Zeker als je als bedrijf geen inhoudelijke controle over dat account hebt en dus afhankelijk bent van wel of niet accepteren dat iemand een privé account (of welk ander account dan ook wat niet van het bedrijf is) gebruikt.

Voor hetzelfde gemak was het een privé account van een familielid of kennis geweest die nog was ingelogd, als het bedrijf maar willekeurige accounts toe laat.

[Reactie gewijzigd door kodak op 23 juli 2024 10:49]

[Tadango]

Dat zou met 2fa minder erg moeten zijn. Ook al staan de zakelijke wachtwoorden in een persoonlijke google account welke gehackt worden dan nog kom je nergens binnen door de 2fa. Daarnaast zou je voor admin / privileged accounts een systeem moeten hebben waarbij het ww elke dag veranderd. Je moet deze dan uit een kluis halen. Dat voorkomt geen diefstal van het office domain uiteraard maar beschermd je achterliggende systemen wel.

[the_stickie]

'gehackt account' staat vaak ook gelijk met 'gelekt wachtwoord'. juister is de bewoording van Okta zelf: gecompromitteerd account.

Afaik bestaat er overigens ook best wel wat (targeted) malware die net wachtwoorden probeert te achterhalen.

[Reactie gewijzigd door the_stickie op 23 juli 2024 10:49]

[Hertog_Martin]

Ook mijn vraag. Is Google per definitie niet veilig bruikbaar als password manager of kan het net zo goed werken als een 1 Password als je maar een goed ww en MFA op je Google account hebt.

[theduke1989]

Mijn collegas ook die alle wachtwoorden opslaan op hun google account wanneer ze van systemen moeten wisselen.

Ik persoonlijk doe dat niet. Heb ze er een keer op aangesproken. Maar hun lachen erbij. Nja niet mijn probleem als er een grote breach is later.

[bkor]

Mijn collegas ook die alle wachtwoorden opslaan op hun google account wanneer ze van systemen moeten wisselen.

Hebben jullie dan niet een identificatiesysteem welke (voor beheerders) tijdelijk rechten geeft op een systeem? Dit inclusief een tijdelijk wachtwoord? Het opslaan van een wachtwoord is hierdoor nutteloos. Dat met de tijdelijke wachtwoorden wordt expres gedaan zodat met 1 account je niet gelijk alles kan overnemen.

[the_stickie]

Jammer genoeg zijn zo'n tijdelijke wachtwoorden voor heel wat topeassingen gewoon onmogelijk.
Denk bijvoorbeeld aan de VMWare root, de admin account van je switches en firewalls en de administrator accounts op DMZ servers (om maar een paar voorbeelden te noemen).

Feit is dat admins die toegangen (soms) nodig hebben, en als dat het geval is er vaak ook nog een vorm van urgentie is.

[De Vliegmieren]

Hoezo is een tijdelijk wachtwoord daar niet mogelijk? Als het wachtwoord te wijzigen is, dan kan het uiteraard ook automatisch worden gewijzigd door een wachtwoord-manager van een PAM oplossing.

[the_stickie]

Je hebt gelijk dat onder voorwaarden mijn voorbeelden zwak gekozen zijn, maar...
PAM oplossingen kunnen lang niet 'elk' wachtwoord managen, en zelf als het kan, loopt alles een keer fout. PAM oplossingen introduceren naast een laag beveiliging ook potentieel nieuwe zwaktes en fouten.
Imho is het deel van de risicoanalyse om na te gaan waar de PAM zinvol is en is er heel wat te zeggen om de 'oorspronkelijke' root/admin gewoon een sterk wachtwoord te geven en 'nooit' te gebruiken, als fallback.

Je moet je bijvoorbeeld óók afvragen hoe je weer online geraakt als al je infra op zijn bek gaat, en je dus geen PAM of passwordtool meer hebt.

[downtime]

Kleine bedrijven doen dit soort dingen gewoon niet. Vaak mist de kennis of het budget om zoiets te implementeren. En vaak is het ook gemakszucht. Iedereen een admin account waarvan je het password nooit hoeft te wijzigen is zo makkelijk dat beheerders liever negeren dat het onveilig is.

[bussie66]

Waarom zou je uberhaupt je werklaptop willen gebruiken voor prive-zaken? Pak je mobiel o.i.d. hiervoor. Dat ding heeft tenslotte iedereen tegenwoordig zo ongeveer vastgelijmd zitten aan haar / zijn hand

Ik houd dat soort zaken strikt gescheiden zodat mijn werkgever me nooit een verwijt kan maken.

[ari]

Om tijdens je pauze even wat op te zoeken? Een smartphone is heel leuk, maar ik geef toch echt de voorkeur aan een fatsoenlijk groot scherm met een fysiek toetsenbord.

[Tc99m]

Dan kun je een incognitovenster gebruiken, of desnoods een aparte browser.

In je pauze iets opzoeken of bestellen moet kunnen, maar zeker als je bij een IAM dienstverlener zoals Okta werkt zou je toch verwachten dat je werk en privé wat strikter gescheiden houdt.

[Jacques-Oh]

Dan kun je een incognitovenster gebruiken, of desnoods een aparte browser.

In je pauze iets opzoeken of bestellen moet kunnen, maar zeker als je bij een IAM dienstverlener zoals Okta werkt zou je toch verwachten dat je werk en privé wat strikter gescheiden houdt.

Voorbeeld: ik kijk vaak (vele malen per dag soms) tutorials op youtube om iets op te lossen in mijn werk. Om te voorkomen 100.000 reclames te krijgen ben ik standaard ingelogd in de Chrome browser zodat ik van YouTube premium gebruik kan maken.

Los daarvan sla ik ook wachtwoorden op in de passwordmanager van google. Ik heb zelf geen andere en het werk verschaft die niet. Ik wil ook geen wachtwoorden over moeten typen of kopiëren. Dat werkt veel te vertragend.

Maar dan praat je wel over een gebruiker en niet over iemand met adminrechten. Ik kan niks op server-niveau, hoogstens kan je bij wat sharepoint mappen.

[mr_evil08]

Dit gebeurd heel veel op de werkvloer, even die bestelling plaatsen, even dit even dat etc etc.

[Unknown Alien]

Security zal altijd 1 groot lek hebben, zolang er een mens bij aanwzig is.

[xxxMaverick]

Tja zo zie je maar. als je data veiligheid niet op 1 hebt ben je de sjaak. Voorbeeld: sinds vandaag krijg ik van badkamerwinkel.nl opeens allemaal phising mail. Naja niet van het mail adres van ze uiteraard maar wel op mijn uniek aangemaakte mail adres voor deze winkel

Heb ze maar mail gestuurd, eens kijken wat de respons gaat woren

[mr_evil08]

Dus in feite is het gelekt via een privé computer doordat men ingelogd heeft met een privé account op de werklaptop en de zaak gesyned is.