Sta je dan met je security papers mbt hardening.

Hey bedankt he. Hier een premier contact!

Als er sprake is ve misconfiguratie. Hoe kan je dan stellen dat er geen misbruik is gemaakt. Stonden de logs aan dan en werden de bijbehorende events gelogd?

Sorry hoor maar dit komt erg ongeloofwaardig over.

Dit is veel meer dan een "misconfiguratie". Alleen al dat de gegevens zo vreselijk lang bewaard bleven is een misser. Dat de database publiekelijk toegankelijk was is er ook een. En dan ja, dat die compleet open stond ook. Dus dat zijn al minstens drie missers, niet maar één.

Niet een Microsoft product, ze gaan als een tijdje voor de OSS varianten. Dit is het gangbare verhaal met het gemak van cloud databases waar je snel veel data in gooit en via het internet koppelt. Ik mis al een tijdje de Mongo-db en AWs bucket meldingen.

Ik niet. :(
Net zo min als de MS-SQL en de MySQL meldingen. Die komen nog dagelijks binnen.

Ik zie ook steeds meer applicaties die gelijk maar even MSSQL configureren als je de applicatie op je werkplek installeert. En de focus van de ontwikkelaar ligt op de beveiliging van de applicatie, als er al aandacht is voor beveiliging. Ze gaan uit dat Microsoft MSSQL wel afdoende beveiligt.

Peter

Een misconfiguratie zal iedereen die een paar jaar meeloopt in de ICT minimaal 1 keer voorkomen.

De meesten zijn snel te herstellen

Als dat veel voorkomende fouten zijn, dan had je daar al lang geleden van kunnen leren. Dat was dat naar boven gekomen tijdens een risicoanalyse en dan had je zo'n database nooit in de buurt van het internet gehangen. Dit is broddelwerk.

Eens maar niet een database met gegevens v zoveel klanten. Dan klopt er iets niet procedureel. Iets met check dubbelcheck

Je verwart de kluis met de kluissleutel.

ElasticSearch is een OSS (open source software) zoekmachine voor grote databestanden:
https://nl.wikipedia.org/wiki/Elasticsearch

Elastic is een van oorsprong Nederlands bedrijf:
https://www.volkskrant.nl/economie/elastic-is-het-jongste-nederlandse-techsucces-in-een-klap-vijf-miljard-dollar-waard~bebd0dc2/
ElasticSearch wordt door veel (grote) bedrijven gebruikt: onder andere het Nederlands Forensisch Instituut (voor de forensische zoekmachine Hansken), Tinder, Uber, eBay, Ticketmaster, Microsoft en Facebook.

ElasticSearch vergelijk ik met een kluisdeur, maar als je fouten maakt in de configuratiebestanden (de kluisdeur) zet je de kluisdeur open en kan iedereen binnenlopen. Dat is hier het onderwerp.

Sorry, deze post van mij (Anoniem 16:38) is een reactie op Karma4 (15:55).

Dat ze de software niet zelf geschreven hebben is in dit geval volstrekt irrelevant. Hun servers, hun verantwoordelijkheid.

Niet een Microsoft product, maar wel één die onderhouden wordt door het door jou zo geadoreerde Microsoft, en die dus weer eens zwaar in de fout gaan. Dat vergeet je er gemakshalve even bij te vermelden. Geen onbelangrijk aspect.

Het is niet OSS dat de schuldige is, maar degene(n) die het beheren. Nice try, Karma4. Maar wederom: no cigar!

Doet natuurlijk pijn als Microsoft een blunder maakt. Meteen de schuld op OSS schuiven.

Het is gangbaar gebeuren met die OSS databases, het gaat kennelijk bij iedereen fout. Dan moet je de schuld ook daar aan wijten niet aan de gebruiker. Je ben heel consequent in microsoft bashing helaas niet in informatieveiligheid analyses.

Dank je, het bekende probleem, een ander zal de beveiliging wel doen. Met die houding, daar gaat het mis.

Heeft de AP al gevraagd aan Microsoft waarom ze zo lang conversaties bewaren?

Databases niet goed configureren valt onder slecht beheer en dat gebeurt inderdaad overal. De andere problemen met Microsoft software (voornamelijk Windows) zijn tekenend voor closed source spaghetticodebouwwerken.

Ik ben benieuwd of ik de log terug kan vinden van mijn gesprek met die Microsoft “beveiligings” meneer met accent.
Die belde mij omdat mijn Windows gehackt was. Na 20 minuten aan de telefoon kwam hij eindelijk tot de conclusie dat ik helemaal geen Windows heb haha.

Als het zo gangbaar is (zoals je beweert), dan had Microsoft JUIST goed beheer moeten plegen en er bovenop moeten zitten. Nietwaar? Het feit dat ze dat in Redmond niet gedaan hebben maakt het, zoals jij het nu stelt, eigenlijk nóg kwalijker! Feitelijk heb je het dus "een soort van" bij het rechte eind (kuch!), alleen zal mijn conclusie op jouw bewering je nu niet bevallen.

Met andere woorden: deze banaan kun je simpelweg niet recht buigen. Wat je ook probeert om Microsoft te verdedigen en de schuld bij OSS te leggen. Microsoft is nalatig en slordig geweest, en ze tonen hiermee wéér eens aan dat ze OSS databases niet op een verantwoorde manier kunnen beheren én dat ze security nog steeds niet tot in de puntjes beheersen. Het is de schuld van de beherende partij (Microsoft!). Geeft verder niks, maar het zou je sieren als je hierin eens je verlies neemt en het erkent. ;-)

Eens! Geen speld tussen te krijgen.

"Hello dis is mike from micosoft tek support, i believe you may hav a virus on your computor"

...beweert iemand die even consequent is in OSS-bashing als in het ontkennen dat hij dat doet.

Het is heel simpel. Als je software die naar een poort luistert om daar opdrachten op te ontvangen gebruikt dan heb je na te denken over wie die poort kan benaderen en over wat daar vervolgens mee kan, en maatregelen te nemen om te voorkomen dat dat verkeerd gaat. Als je dat overslaat ga je met de beste produkten nog de mist in.

En jij had niemand van Microsoft aan de lijn.

Of was het sarcastisch bedoeld :)

Onze OSS fanaten geven altijd aan dat de oorzaak in het OS gezocht moet worden. Als je dat consequent aanhoudt kom je hier tot OSS probleem. Ik doe niet aan OSS bashing ik zou willen dat de OSS mensen meer aan informatieveiligheid zouden doen in plaats van in hun OS oorlogjes te blijven hangen.

Een tijdje terug werden de constateringen van open poorten met gevoelige data nog afgedaan als de betreffende onderzoeker onkundig was, bij het verkeerde foute bedrijf werkte. Een lek bij de heilige systemen mocht niet.
We gaan vooruit, het wordt in ieder geval niet meer ontkend of die onderzoeker als onkundig beschouwd.

Zie je wel? ;-)

Je hebt er serieus meerdere malen de grootst mogelijke onzin over beweerd, en als een dogmaticus die totaal ongevoelig is voor argumenten heb je dingen die zowel feitelijk als logisch niet kloppen tot in het absurde volgehouden.

Maar het punt blijft overeind staan dat wat hier misgaat eraan ligt dat iets open aan het internet is gehangen dat niet open aan het internet gehangen had moeten worden. Als je in SQL Server de toegang tot data niet nauwgezet inricht en je hangt het aan het internet dan liggen er ook gegevens op straat. Als je een directory met vertrouwelijke Word-documenten open en bloot via het internet deelt dan liggen die documenten op straat. En dat ligt dan niet aan SQL Server of aan Word, dat ligt aan het feit dat iemand die systemen niet goed heeft ingericht.

Ik heb geen inhoudelijke kennis van Elasticsearch, maar zelfs als dat een systeem is waar geen enkele vorm van toegangsbeveiliging is ingebouwd dan nog is degene die het inzet zonder daarbij stil te staan ernstig aan het blunderen. Als software zelf beveiligingsmogelijkheden aan boord heeft heb je die goed te configureren, als het die niet heeft dan heb je die beveiliging te regelen door het bijvoorbeeld via een goed beveiligd vpn beschikbaar te stellen aan degenen die bevoegd zijn om erbij te komen. En dit klopt dus niet:
Je moet het wel degelijk wijten aan de gebruiker. Dit zijn geen consumenten zonder enige IT-kennis, dit is professioneel gebruik en daar is professionaliteit bij nodig. Die realiteit weet je maar al te goed naar voren te brengen als het je uitkomt, met al je referenties aan ISO-normeringen en andere normenkaders. Maar als een OSS-produkt gebruikt is hoeft de gebruiker dat kennelijk allemaal niet goed te doen en moet de software het allemaal automagisch opvangen. Dat is meten met twee maten, karma4, en daarmee is het wel degelijk OSS-bashing wat je doet.

Wat mij nu wel interesseert, is Microsoft in dit dossier nu verwerker of verwerkersverantwoordelijke? Volgens mij heeft Microsoft geen melding gedaan bij een van de DPA's. Microsoft gaat er vanuit dat de klant verwerker is en dus moet melden bij de lokale DPA. Gaat volgens mij een stortvloed aan meldingen opleveren. Ben benieuwd wat de collega's hiervan vinden?