De ene na de andere lek bij Amazon cloud. Wie had dat gedacht dat een kleine menselijke fout meteen zulke gevolgen zou hebben?

Lessons learned: Houd je data binnen je organisatie, anders heb je maar 1 beveiligingslaag.

Waar is de overheid om dit soort bedrijven te straffen? Je kunt zelfs in een wetboek opnemen dat het bewust open zetten van deze data faillissement voor het bedrijf betekend!

S3 buckeds zijn bij default afgeschermd. Er moet dus een actieve handeling gedaan worden om dit te laten lekken. Het is dus 100% menselijke fout. Het is bewust gedaan. Het is menselijk falen!

TheYOSH

Aandachtspuntje voor Amazon: introduceer een S3 container die niet (nooit) publiek gemaakt kan worden.

En wat bereik je dan? Nog even afgezien dit juridisch helemaal niet mogelijk is.

Dat is het eigenlijk altijd.....

Dan krijg je eigenlijk het zelfde issue. Als men niet weet wat je doet, en het werkt niet, kies je de "wel publiek versie", en die doet het... Waarna je eigenlijk ook weer terug moet migreren. Klinkt als een oplossing, maar lost eigenlijk niet op.
En klaar volgende probleem.

De bewuste handeling komt uit het gemak en omdat het kan. Nooit iets anders gezien waarom de boel fout ging.

Met het verschil dat je bij het nieuwe type private-only container er van tevoren over nadenkt (moet denken) en je niet op triviale wijze kan schakelen naar een publieke container. Bij de use cases voor een kredietbureau lijkt me een publieke container sowieso uitgesloten.


Geen probleem dus of het moet je vak zijn om problemen te <kuch>creëren</kuch> zoeken.

Het is niet een fout van de amazon cloud, alhoewel ze misschien maar eens de drempel wat hoger moeten leggen voor hun klanten.
Dit krijg je als dombo's met gemakkelijke tools laat werken. Al die web developer bedrijfjes die maar een vm daar maken, en nooit meer onderhouden. Ondertussen heeft de rest van de wereld er last van.

PS. daarnaast mag die abuse afdeling ook wel wat worden uitgebreid, die zitten ook te slapen.

Die data in de cloud hoorde natuurlijk door henzelf (NCF) eerst te zijn versleuteld!!!

ALTIJD eerst de data die je in wat voor cloud dan ook neerzet versleutelen!
Of het tijdelijk of langdurig in de cloud staat, maakt niet uit.

Stelletje oelewappers dat ze zijn.
Hadden ze die data eerst goed versleuteld en dan pas in de cloud gezet, dan was dit lek vele malen minder erg.

LEER hiervan mensen!

Even wat minder filosofisch:
Er zijn vast een hoop betroffenen voor wie dit datalek grote gevolgen heeft of kan hebben.
Het gaat vrijwel altijd om gegevens die buiten hen om zijn verzameld en wanneer de gelaedeerden hun schade proberen te verhalen lost het "kredietbureau" met een zacht plofje op in 't niets, in een faillissement.

Actieplan:

1. beveiligingsbelasting voor iedereen die persoonsgegevens verwerkt (hoe meer, gevoeliger en langer er informatie wordt opgeslagen hoe hoger het te betalen bedrag)
2. geld uit stap 1 gebruiken om beveiligingsbedrijven gericht naar dit soort en andere fouten te laten speuren
3. boetes voor elke onderneming waar de zaken niet op orde zijn

Data opslaan op een blockchain gebaseerd opslag punt zoals sia. Veel veiliger en goedkoper dan amazon of welk ander gecentraliseerd bedrijf.

Nu schakel je om naar Informatieveiligheid het gaat niet om de achterliggende techniek maar
- wat de gegevens betekenen
- wie er bij de gegevens mogen komen onder welke condities met bia cia iso27002 (18) voor de data verwerker maar tevens net zo goed voor de data eigenaar. (GDPR AGP)

Amazon is een groot commercieel bedrijf, kredietbureaus zijn commercieel.
Dat een AWS (OSS) gebouwd is met
a/ open source software
b/ contracten voor s3 buckets openbaar zijn
c/ De richtlijnen hoe je zo iets op een verantwoorde manier gebruikt openbaar zijn

Het voegt weinig aan informatieveiligheid niets toe. Het is niets anders dat wat leuke kerstboom versiering als bling bling.
De opmerking dat blockchain de oplossing is voor al uw dataopslag problemen mist de achtergrond helemaal maar toont prima de buzz word monddood benadering.

Dat is vergeleken met logistiek de tachograaf waarmee rijtijden gecontroleerd worden. Chauffeurs hebben die en de baas aan de tracker want de bezorgingen gaan op de 15 minuten (minder) nauwkeuring voor de klant. Het zijn wel gescheiden systemen.
Dat soort regulering lijkt me prima. Alleen gaat zoiets natuurlijk tegen alle ondernemersvrijheid in. Met de liberale gedachtegang dat de markt alles wel oplost is er een grote weerstand. Toch zal het er net zoals verkeersregels wel van komen. WBP GDPR de lijn gaat door, dataveiligheid verkeersregels

Dat is inderdaad het allerbeste!

Nope je hebt de oorzaak niet waarom het gebeurt is.
Grootste waarschijnlijk is gebrek aan ICT support om het op een goede manier te doen (afgeschermd beveiligd).
Met een business case en noodzaak om het voor elkaar te krijgen doen ze het zelf, dat werkt tenminste.
Dat het niet is zoals het hoort is een niet gewogen risico en iets voor de anderen.

Het andere: AWS heeft alles prima geregeld dat is de advertentie werking, Dan hoef je er zelf niets maar aan te doen of over na te denken. Zoiets kost alleen maar en brengt niets op, durf niet iets met "ja maar" te komen want dan lig je er uit.

Vroeger (toen alles nog in de meterkast stond) had je een stuk infrastructuur en een beheerder om de boel af te schermen. B.v. een tankgracht of een firewall of iets anders.

Tegenwoordig doet de developer zelf de infrastructuur, maar is hij daar (gemiddeld) niet capabel genoeg voor blijkt nu (S3 mis-conf-gate). Een beheerder of een stuk infrastructuur dat toegevoegd werd voor beveiliging om al te grote misstappen te voorkomen, ontbreekt nu volledig.

Ondertussen is de CIO volledig blind: "Cloud is toch veilig, punt?"

Pad naar oplossing:
1. Er moeten nog veel meer grotere lekken komen, om de CIO eens tot denken aan te zetten.
2a. De infrastructuur beheerder komt (tijdelijk) terug
of
2b. De developer moet het over een andere boeg gooien: Ook de infrastructuur coderen, die infra-code automatisch laten analyseren door geavanceerde tooling die door een ander is ingericht/gemaakt/beheerd.

Des te meer reden om er een norm van te maken dat men persoonlijke data encrypted in de cloud zet.
Om te beginnen is het voor iemand die werkt bij een cloudprovider en toegang heeft of weet te krijgen tot in de cloud gezette informatie al mogelijk om data uit de cloud te kopiëren. Wat bij de NSA kan, kan natuurlijk ook bij cloudproviders.
Er hoeft maar één keer een rotte appel bij het komen en gaan van medewerkers tussen te zitten.
Ten tweede wordt vaak informatie in de cloud gezet die sterk is gecentraliseerd, d.w.z. dat het de data is van heel veel mensen. We hebben dit ook gezien bij Equifax: een grote gecentraliseerde database trekt meer hackers aan.
Er is geen systeem (waaronder de systeembeheerder) zo perfect of er kan wel eens een keertje een hacker bij.
En dan ben je bij zulke grote databases gewoon driedubbel de l.., omdat het over zo ontzettende veel persoonlijke data gaat. Daarom: het zo goed zijn dat er wetten komen die landen verplichten om goede encryptie te eisen wanneer er gevoelige persoonlijke data in de cloud wordt gezet. Dan kost het maar wat meer, maar iemand mag niet te "goedkoop" en daardoor onveilig omgaan met dergelijke gevoelige data van klanten, en vooral niet als het er zo ontzettend veel zijn.

Die wet komt er: http://eur-lex.europa.eu/legal-content/NL/TXT/HTML/?uri=CELEX:52012PC0010&from=EN

"GDPR artikel 4
BEGINSELEN
Artikel 4 Beginselen inzake de verwerking van persoonsgegevens
De lidstaten bepalen dat persoonsgegevens:
a)      eerlijk en rechtmatig moeten worden verwerkt;
b)      voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden moeten worden verkregen en vervolgens niet op een met die doeleinden onverenigbare wijze mogen worden verwerkt;
c)      adequaat, ter zake dienend en niet excessief moeten zijn, in verhouding tot het doel waarvoor zij worden verwerkt;
d)      juist moeten zijn en zo nodig moeten worden geactualiseerd; alle redelijke maatregelen dienen te worden genomen om de persoonsgegevens die, uitgaande van de doeleinden waarvoor zij worden verwerkt, onjuist zijn, onverwijld te wissen of te rectificeren;
e)      moeten worden bewaard in een vorm die het mogelijk maakt de betrokkenen te identificeren, maar niet langer dan noodzakelijk is voor de verwezenlijking van de doeleinden waarvoor de persoonsgegevens worden verwerkt;
f)       moeten worden verwerkt onder de verantwoordelijkheid en aansprakelijkheid van de voor de verwerking verantwoordelijke, die toeziet op de naleving van de krachtens deze richtlijn vastgestelde bepalingen."

De verantwoordelijke (data controller) en verwerker (data processor) zijn beide aansprakelijk zonder uitzondering.
Ik houd graag de volgorde a,b,c,d,e aan daarmee wordt data geminimaliseerd.

Iets zegt me dat:
- techneuten dat overslaan en voor:
"(16) De beschermingsbeginselen moeten voor elk gegeven betreffende een geïdentificeerde of identificeerbare natuurlijke persoon gelden. Om te bepalen of een natuurlijke persoon identificeerbaar is, dienen alle middelen in aanmerking te worden genomen waarvan redelijkerwijs te verwachten is dat zij door de voor de verwerking verantwoordelijke of door een andere persoon worden gebruikt om de persoon te identificeren. De beschermingsbeginselen dienen niet van toepassing te zijn op gegevens die zodanig zijn geanonimiseerd dat de persoon op wie die gegevens betrekking hebben, niet meer identificeerbaar is."
Dan kun je toch alle data verzamelen. Encryptie is wel aan te raden maar als de cultuur er niet is (sleutel onder de mat) gaat er niet veel veranderen.
- de handhaving te wensen over gaat laten. Zouden ze de gootbanken echt aanpakken als ze grote witwaszaken laten lopen (zie ftm.nl).

Want fouten worden binnen de eigen organisatie nooit gemaakt, waardoor het beveiligingsniveau binnen de eigen organisatie optimaal is ? Indien je eigen beheerders hun amazon cloud account niet juist kunnen configureren, waarom zouden ze de beveiliging van de eigen IT assets dan wel op orde hebben ?

Persoonlijke data moet encrypted zijn *ongeacht* of deze in de cloud staat. Wat maakt het uit of het gaat om een cloud server, dedicated server, shared server, of weet ik veel wat. Helemaal niets. Ook maakt het niet uit of je de assets zelf managed, of dat je dit uitbesteedt. Het gaat om de aard van de data.

Encryptie en hashing (pag 24)
https://autoriteitpersoonsgegevens.nl/sites/default/files/downloads/rs/rs_2013_richtsnoeren-beveiliging-persoonsgegevens.pdf

Dat is niet anders bij een niet-cloud server. En of het gaat om een malicious insider binnen je eigen bedrijf, of binnen het bedrijf van een dienstverlener, dat is ook redelijk bijzaak. Staar je niet zo blind op het woordje ''cloud''.


Heeft met het gebruik van ''cloud'' technologie bar weinig van doen, meer met menselijk gedrag.


Indien deze database op een niet-cloud systeem zou draaien, of in eigen beheer, dan zou de data hetzelfde blijven.


Die wetgeving bestaat al (iig in ons land). Het woord cloud hoeft in dergelijke wetgeving niet terug te komen. Indien je iets anders gebruikt dan ''cloud'', dan blijft de wet gewoon van toepassing.

Dit zuig je uit je duim. Maar als de CIO daadwerkelijk zo zou reageren, dan zou deze vervangen moeten worden. Overigens vraag ik mij af of degene die bovenstaande schreef denkt dat technologie-anders-dan-cloud inherent veiliger is. Bij iedere IT omgeving draait het om configuratie; hoe heb je zaken beveiligt. En niet om buzz-woordjes als ''cloud''.

Niet-cloud is immers ook niet veilig, tenzij je de juiste maatregelen treft.

Nee, het is wel degelijk altijd het allerbeste - zoals Anoniem stelt - om de data zelf te versleutelen voordat je ze in de cloud zet.


Man, man, man, wat staat hier?


En afsluitend een warrige complottheorie over advertenties bij AWS? Het is goed hoor...

Leuk dit soort producten, wordt alleen bijna nog niet gebruikt. Misschien met een redenen? Afgezien deze SIA software pas 1,5 jaar bestaat? En zich dus niet bewezen heeft? Om daar je bedrijfs gegevens even in te stoppen? Nog even afgezien de missende certificering. Volgens mij komt dit geen audit doorheen.
Afgezien dit soort software wel heel gaaf is.

Het mag misschien wel het beste zijn om altijd je data in de cloud te versleutelen. Eigenlijk zou je dit altijd moeten doen, dus ook lokaal actief doen. Maar Karma heeft wel gelijk. Het lost de oorzaak niet op, je lost alleen de gevolgen op.
Afgezien je de sleutel dan ook goed moet bewaken.

Beide zijn dus correct, maar de oorzaak is het werkelijke issue (verkeerde permissies), de gevolgen kan je echter wel minimaliseren (encryptie).

Altijd mooi hoe mensen met het vingertje wijzen; dit zijn vaak security mensen die *nooit* een fout maken of alles hebben dicht getimmerd waardoor mensen dit soort fouten niet kunnen maken.
Mensen vinden altijd een weg, namelijk de weg van de minste weerstand. Je kan niet alles dicht timmeren als je een commercieel bedrijf bent.

Wat er staat is het onaangepaste gedrag van technische Nerds die niets met beslisser op hebben en enkel dwarsliggen.
Daarmee gaan de beslissers hun eigen weg. Dat hoeft niet zichtbaar voor Nerds te zijn. Schaduw ict is vaak noodzaak.

Oh? Kritiek op wartaal wordt weggezet als onaangepast gedrag? Leuke club, die 'beslissers' van jou. Maar gelukkig is het wel duidelijk dat jij niet voor die mensen spreekt.

Ik heb kritiek op evangelisten die wartaal uitslaan naar beslissers. Iets wat jou niet uitkomt dan wel niet zint.
Je begrijpt het kennelijk uitstekend daarmee is je op de man spelen zo ethisch slecht.

Des te meer je weet krijgt van de veiligheidssituatie op de infrastructuur,
des te meer verbaast het je dat het nog zo vaak zo goed gaat.

Mensen zijn ook maar mensen en geen AI robots in de maak.

1 woordje verkeerd gespeld als hacker en daar gaat de buit,
waar je zo op gezweten hebt, je neus voorbij,
want de oplettende linguïst heeft je in de gaten.

Dus geen 'french fries' waar "chis and fibs" beter zou passen en
geen tartar sauce ergens over gieten, waar mayonaise beter past.

Zo is het ook met code en daar nog meer opgepast, daar nog beter "spitten"vaak:

Voorbeeldje verdacht -

Dit is een "unterminated string literal error" en kan vrij vervelend zijn bij ingesloten scripts (info credits voY).

En daarom is IT research vaak zo onderhoudend.
Als het je in de ban krijgt, laat het je vaak niet meer los.

Dank voor jullie bijdragen allemaal hier.
Elke dag leert men weer iets bij.

luntrus