Topvrouw Google-beveiligingsteam: stop met blussen van 'beveiligingsbrandjes'

Op de jaarlijkse Black Hat-beveiligingsbeurs in Las Vegas opende Parisa Tabriz, die onder meer leiding geeft aan Googles Project Zero-team, met de boodschap dat het oplossen van geïsoleerde 'beveiligingsbrandjes' nergens toe leidt en dat er een specifieke aanpak nodig is voor verandering.

Tabriz is binnen en buiten Google het beste bekend onder de aanduiding security princess, maar is officieel director of engineering en de manager van het Project Zero-team, dat zoekt naar kwetsbaarheden in software van Google, maar ook van andere organisaties. Ze begon haar keynote met de opmerking dat ze het gevoel heeft in een real life-versie van whac-a-mole te zitten, waarbij individuele problemen worden opgelost zodra ze de kop opsteken. Die aanpak werkt volgens haar niet, wat een probleem is 'nu de beveiliging van computers langzamerhand de beveiliging van de hele wereld wordt'. Ze stelt voor in plaats daarvan een aanpak te hanteren die bestaat uit drie onderdelen.

Het eerste onderdeel ziet erop de onderliggende oorzaak van een probleem aan te pakken in plaats van alleen 'geïsoleerde oplossingen' te ontwikkelen. "Een van de manieren om dat te doen is steeds de vraag 'waarom' te stellen", aldus Tabriz. "Neem het voorbeeld van een rce-lek in een bepaald product. Stel vervolgens de vraag waarom dit lek niet eerder werd ontdekt en waarom er niet op dit soort lekken werd getest. Waarom duurt het zo lang om een update uit te brengen en waarom duurt het vijf weken om die update te testen? Als je die vragen stelt, kun je structurele veranderingen aanbrengen."

Bij het spreken over verandering noemt ze het voorbeeld van de deadline van negentig dagen die door Project Zero wordt gehanteerd. Die stuit niet altijd op waardering door organisaties die binnen die tijd kwetsbaarheden moeten verhelpen. Tabriz zegt: "Deze termijn heeft op de korte termijn het gevolg dat bedrijven die structurele veranderingen moeten doorvoeren pijn lijden, maar hij leidt uiteindelijk wel tot verandering." Zo zouden bedrijven inmiddels minder weerstand bieden en meer investeren in beveiligingsmaatregelen. Inmiddels zou 98 procent van de door het team gemelde lekken binnen de termijn van negentig dagen opgelost worden.

Het tweede onderdeel is het hanteren van mijlpalen en het vieren van het behalen ervan. Daarbij haalt ze de geleidelijke adoptie van https aan, die ze mede toeschrijft aan de manier waarop Chrome omgaat met versleutelde en niet-versleutelde verbindingen. "In 2014 was er al een voorstel om http-sites als onveilig aan te merken, maar dat werd vrijwel meteen afgeschoten", stelt Tabriz. Vervolgens werkte het Chrome-team aan het uitwerken van ui-veranderingen die uiteindelijk toch tot die verandering zouden leiden. Dat gebeurde onlangs met de release van Chrome 68. In de tussentijd hanteerde Google verschillende stappen in het proces ernaartoe. "Die mijlpalen waren een herinnering aan het feit dat er iets ging veranderen en boden heldere deadlines", zegt Tabriz. "Daarbij speelde Let's Encrypt overigens ook een fundamentele rol."

Het laatste onderdeel is het bouwen van coalities om veranderingen door te zetten. Daarbij bespreekt Tabriz het voorbeeld van de introductie van site isolation in Chrome, wat ze aanduidt als een van de meest fundamentele veranderingen in Googles browser. Het werk aan die functie begon in 2012 en het was de verwachting dat het een jaar zou duren om deze te implementeren. Uiteindelijk duurde het zes jaar; Google maakte onlangs bekend dat de functie bij vrijwel alle Chrome-gebruikers actief is. "Als een project langer duurt dan gepland, maakt dit je een doelwit voor het management", zegt Tabriz. "Het project had ook tot een einde kunnen komen omdat er te weinig steun was door de rest van het Chrome-team.

De tien mensen die aan site isolation werkten moesten bijvoorbeeld andere Chrome-teams overtuigen ingrijpende veranderingen door te voeren." Ze noemt het voorbeeld dat de ctrl+f-functie ineens van een simpele for-loop veranderde in een 'distributed systems problem'. Een dergelijke verandering zou alleen mogelijk zijn door dit op een begrijpelijke manier over te brengen op de mensen die de wijzigingen uiteindelijk door moeten voeren. Site isolation bleek uiteindelijk de juiste zet te zijn geweest toen bleek dat de functie ook gebruikt kon worden om te beschermen tegen Spectre-aanvallen via de browser. Tabriz besloot haar keynote met de mededeling dat ze de toekomst ondanks alles positief ziet en dat ze erin gelooft dat structurele veranderingen mogelijk zijn.

Reacties (92)

[Lordy79]

Ze heeft natuurlijk helemaal gelijk want dit is dweilen met de kraan open. Maar haar oplossingen zijn makkelijker gezegd dan gedaan.

Misschien dat AI die code kan nakijken ooit een revolutie kan geven maar zolang programmeren en het controleren van code mensenwerk is zullen er fouten worden gemaakt.

[Verwijderd]

Natuurlijk zijn haar oplossingen makkelijker gezegd dan gedaan. Als het makkelijk zou zijn was het al gebeurd.

Dat is overigens precies waar ze tegen strijdt. Tegen de nay-sayers die moeilijke dingen maar gelijk afschieten. Want dat is volgens mij een van de redenen waarom dit soort initiatieven nooit van de grond komen. Het is makkelijker en lijkt goedkoper om maar een beetje van incident naar incident te rennen.

Structurele veranderingen zijn moeilijk. Heel moeilijk. En als iemand ze voorstelt krijg je "ja dat is makkelijker gezegd dan gedaan".

Zo blijf je in hetzelfde cirkeltje zitten

[Stoelpoot]

Dat klopt, maar het ook zo dat we uiteindelijk die brandjes moeten blijven blussen, en daarna pas kunnen kijken naar manieren om ze te voorkomen. En dat is waarom het "makkelijker gezegd dan gedaan" is. Brandjes blussen bouwt voort op de maatregelen die bestaan, voorkomen betekend dat een groot deel van eerder uitgevoerd werk onnodig wordt verklaard en oude "brandjes" opnieuw kunnen oplaaien.

[Superstoned]

Uiteindelijk is het grootste probleem de 'incentives': beveiliging kost geld en levert weinig (zichtbaar) op. Het is lastig uit te leggen, vertraagd projecten enz enz enz.

Ja, in beperkte mate kun je het in marketing gebruiken maar spijtig genoeg is het ingewikkeld genoeg dat je vaak mensen lekker een rad voor ogen kunt draaien en grote beloften maken zonder dat je echt iets hoeft te doen. Ik erger me dood aan sommige van die zaken, bijv 'end-to-end-encryption' die in de browser wordt belooft*...


* Normaal gesproken is e2ee bedoeld om je van de server te beschermen. Het is natuurlijk idioot om te denken dat je het in de browser kunt draaien en dan veilig bent voor de server - de code die je draait komt van de server en als je de server niet vertrouwd kun je die code natuurlijk ook niet vertrouwen... Tenzij je met een browser add-in werkt is het gewoon security theater.

[Stoelpoot]

Mwa, dat is niet zo. Je kan prima een E2EE-implementatie volledig in de browser schrijven adhv een token wat niet naar de server wordt gecommuniceerd. Maar inderdaad moet je dan wel het vertrouwen hebben in de dienst die de E2EE aanbiedt. Daarvoor zullen audits en heldere communicatie belangrijk zijn.

[Superstoned]

Ok, gaan we doen. Jij schrijft software die E2EE in de browser doet, zo perfect als wat, token bla bla bla, hele mikmak.

Dan geef jij mij volledige root toegang tot jouw server, voor een paar uurtjes. En dan laad jij de pagina van de server in, die jouw E2EE code heeft, en upload (encrypted natuurlijk) al je prive bestanden.

Ok?

Wat, jij denkt dat ik de code op de server aangepast zou hebben zodat er een lek in de encryptie zit? Gut, nee, je denkt het? Ja, daarom kun je E2EE in de browser niet vertrouwen, dat zeg ik toch...

E2EE in de browser is onzin: het beschermt de gebruiker NIET tegen de server, en dat is het hele punt van E2EE. Het is niets beter dan gewoon op de server encrypten. Security Theater.

[Reactie gewijzigd door Superstoned op 24 juli 2024 18:02]

[Verwijderd]

Uiteindelijk is het grootste probleem de 'incentives': beveiliging kost geld en levert weinig (zichtbaar) op. Het is lastig uit te leggen, vertraagd projecten enz enz enz.

Het is tegenwoordig prima te verdedigen om een aantal dagen binnen een project totaal te focussen op het verscherpen van beveiliging. Uiteraard is dit afhankelijk van duur van het project maar er is weinig overtuiging nodig naar management. Ook moet security een al een basis pilaar zijn in het ontwerp van een project.

UIteraard moeten de architecten en designers van een IT project dit wel eisen/controleren maar zo kun je het kaf van het koren scheiden.

[Superstoned]

Het is tegenwoordig prima te verdedigen om een aantal dagen binnen een project totaal te focussen op het verscherpen van beveiliging.

met die houding heb je sowieso al verloren - als je niet vanaf het begin, bij het design/architect een beveiligings expert heb zitten word het niets. Security is geen 'feature' die je later toe kunt voegen, het is een core requirement wat gedurende het hele process mee moet spelen.

Wat wij doen is:
* trainen van mensen (ja, elke ontwikkelaar)
* bij het opstellen van de requirements van code al een security analyse doen - treath modelling en attack surface analysis
* bij de implementatie zijn er veel do's en don'ts, een verplicht 6-eyes review process en en we ontwikkelen interne functies enzo op een manier dat ze veilig zijn
* Als de code af is draaien we statische en dynamische analyse tools.
* en we hebben een strak response process, waarbij we CVE's aanvragen en netjes afhandelen. Elke fout die gevonden word moet door de ontwikkelaar die het probleem geintroduceerd heeft opgelost worden zodat de feedback loop rond is.
* tenslotte hebben we een HackerOne programma zodat hackers geld verdienen met het vinden van security problemen in onze software. Zij hebben zelfs recent een case study gedaan: https://www.hackerone.com...security-front-and-center

Alles wat ik schrijf hierboven is door een onafhankelijke, externe auditor beoordeeld.

Of dat genoeg is? we gaan het zien, we zijn nog maar klein en zullen het in de toekomst beter aan moeten pakken.

Het is tegenwoordig prima te verdedigen om een aantal dagen binnen een project totaal te focussen op het verscherpen van beveiliging.

Tja. Het is MISSCHIEN te verdedigen qua marketing. Technisch is het... niet echt genoeg, zou ik zeggen.

Ik wil niet beweren dat jullie dat niet doen ofzo, maar alleen ff kwijt dat er toch mijns inziens wel meer bij komt kijken ;-)

[Verwijderd]

Security is geen 'feature' die je later toe kunt voegen, het is een core requirement wat gedurende het hele process mee moet spelen.

Daarom staat er ook "verscherpen van beveiliging". Uiteraard zit het al in je design maar ik geef aan dat er een aantal dagen extra binnen een project kunnen worden gereserveerd voor verfijningen, extra controles en pentesting. Het geeft de klant ook een beter gevoel als je laat zien dat je werk veilig is.

[dwarfangel]

Klopt. Stukje after sales.
Maak een paar fouten, en help een boze klant.
En dan is je klant tevredener dan dat alles in 1 keer goed zou zijn gegaan.
Humans are a funny being.

[Lordy79]

Tja, jij kunt afgeven op 'nay-sayers' maar de andere kant van de medaille zijn mensen die naïef zijn.
Ik kan ook pleiten voor het afschaffen van belastingen en de uitkeringen vertienvoudigen maar dat is ook naïef. Dan kun je me een nay-sayer noemen maar de feiten staan aan mijn kant.

Het is namelijk dweilen met de kraan open. En foutloze code bestaat (bijna) niet (net zoals gratis geld) tot er dus een foutloze AI doorheen gaat. Dat was alles wat ik wilde zeggen.

De vraag is natuurlijk of een AI foutloos kan zijn maar dat is weer een andere discussie.

[kami124]

Even een algemene opmerking over nay-sayers. Soms hebben deze nay-sayers wel gewoon gelijk. Zelf werk ik in de natuurkundige wetenschap als PhD en ben de volgende dingen al eens tegengekomen:

Iemand van de bedrijfseconomie, die een nieuwe proces wilde ontwikkelen wat winstgevend moest zijn. Dus ik samen met andere uitleggen dat dat niet ging, zei die het volgende "Anders ontwikkelen jullie toch gewoon even een nieuw molecuul, dat we wel met winst kunnen verkopen".

Iemand die perpetuum mobile voorstelt, ik uitleggen dat dat niet gaat werken en vervolgens word ik ook als een negatief ingesteld persoon gezien. tsja...

en deze: Snow_King in 'nieuws: Ford wil over vier jaar veertig elektrische en hybride ...

[Reactie gewijzigd door kami124 op 24 juli 2024 18:02]

[wica]

Juist, "nay-sayers" heb je ook in je team nodig, om geen lucht kastelen te bouwen.
In een Team met alleen maar ja-zeggers, zal het moeilijk zijn om eens nee te zeggen.

[xelnaha]

De NS heeft daar een mooie spreuk voor (volgens mij op Utrecht Centraal): “samen werken door dwars te liggen”

[Reactie gewijzigd door xelnaha op 24 juli 2024 18:02]

[Banath]

Wat je beschrijft zijn NIET de naysayers zoals bedoeld in de vorige opmerking. Het gaat jou om de klapmongool die denkt dat je kunt toveren en alles maakbaar is, dat voel ik ook zo. Waar het om gaat zijn de mensen die bij voorbaat al nee zeggen zonder daadwerkelijk zich te hebben verdiept in de materie waarin zij zelf expertise hebben. Het kiezen van de makkelijke weg omdat de moeilijke veel inspanning en tijd vergt. Dus voordat je roept neeeeeeeeeeh ... denk eens na over ja, het kan wél mits ...

[Nas T]

Even een algemene opmerking over nay-sayers. Soms hebben deze nay-sayers wel gewoon gelijk.

En vaak dus niet ? Ik zit in een soortgelijke positie op mijn werk en dat voelt dan als: "ik heb het toch gezegd?". Desondanks dat, denk ik wel dat het goed is om uitgedaagd te blijven worden. Misschien komt er wel een nieuw inzicht dat toch tot een oplossing leidt.

[enchion]

"Structurele veranderingen zijn moeilijk. Heel moeilijk."

Structurele veranderingen zijn helemaal niet moeilijk.

Van Amsterdam naar Barcelona gaan door elke dag 1 km naar het zuiden te lopen, of in 1 keer door het vliegtuig te pakken ?

Juist elke dag dezelfde handelingen te blijven doen terwijl het niet nodig is valt bij mij juist onder moeilijk doen.

[Verwijderd]

Ik wil niet heel flauw doen maar die vergelijking slaat echt kant noch wal.

[DarkEagle31415]

Je blijft in het zelfde cirkeltje zitten als je het echte probleem niet op lost. Dit soort uitspraken snappen wij allemaal. En we willen niets liever dan gewoon bij zijn met patches en updates en zo veilig zijn dat elke pentester met een xxl bak tissues naar huis gaat omdat het weer niet gelukt is binnen te komen.

Mensen moeten eens gaan begrijpen dat "nay-sayers" altijd "nay-sayers" zullen blijven als we ze niet duidelijk maken waarom veiligheid zo belangrijk is. Dat doe je niet alleen door dit soort kreten te slaken in een technische sessie dat is te makkelijk.

Opvoeding en awareness daar moeten we aan gaan werken. en het zal heel erg helpen als daar campagnes voor gevoerd worden door onder andere google. Laat die nay sayer maar eens zien wat er gebeurd als we het niet doen. Wat gebeurd er nou als we gehackt worden of wanneer er data lekt. Hoeveel geld kost dat nou (nog maar te zwijgen over reputatie) en laat zien dat die gevolgen niet in verhouding staan met wat minder gebruiksvriendelijk worden voor veiligheid.

Dat zou ons al een heel eind verder helpen.

[Reactie gewijzigd door DarkEagle31415 op 24 juli 2024 18:02]

[DarkEagle31415]

De bekende balans tussen security en usability is in de praktijk gewoon een stuk lastiger in evenwicht te houden. We zijn (afhankelijk van het type bedrijf/organisatie) nog niet zo ver dat gebruikers door hebben en accepteren dat gebruiksvriendelijkheid iets omlaag moet om veiligheid te kunnen garanderen.

Dus ja het moet veiliger en het moet sneller. Maar dit is wel heel makkelijk, van dit soort mensen krijg ik op heel veel plekken jeuk. uiteindelijk (zo snel mogelijk) moeten we naar een situatie dat veiligheid altijd voorop staat. Maar om dat te kunnen realiseren is er gewoon veel promotie nodig onder gebruikers en vooral directie.

Er wordt zo vaak een ideale situatie geschetst maar net als "normaal" is "ideaal" een perceptie. En om op 1 lijn te komen is afstemming en adoptie van gedrag en werkwijze vereist. Laten we daar ook eens wat meer focus leggen.

[Reactie gewijzigd door DarkEagle31415 op 24 juli 2024 18:02]

[jmzeeman]

De bekende balans tussen security en usability is in de praktijk gewoon een stuk lastiger in evenwicht te houden. We zijn (afhankelijk van het type bedrijf/organisatie) nog niet zo ver dat gebruikers door hebben en accepteren dat gebruiksvriendelijkheid iets omlaag moet om veiligheid te kunnen garanderen.

Dit is nou net het probleem van veel beveiligingsexperts en ICTers. Zij zien mooie technische oplossingen, policies en weet ik veel wat, vaak zonder (voldoende) oog te hebben voor de menselijke kant, die veel belangrijker is. Als een beveiligingsmaatregel niet gebruiksvriendelijk is, is die in mijn ogen per definitie niet veilig omdat mensen er omheen gaan werken. Het grootste gedeelte van de ernstige lekken komt volgens mij nog steeds niet door super vette 0-day exploits maar gewoon door beïnvloeding van mensen om zo wat gedaan te krijgen of wat informatie te verzamelen.

Neem nou bijvoorbeeld het klassieke idee van password policies waarbij je zonder aanleiding, je wachtwoord elke 3 maanden moet veranderen. Klinkt technisch en wiskundig erg goed, maar het gevolg is dat mensen veel simpelere passwords gaan kiezen, een volgnummertje gaan gebruiken of een post-it ergens gaan neerleggen. (Volgens mij is dit specifieke voorbeeld al talloze keren aangetoond staat in security standaarden dat je dit niet moet doen maar toch zie ik het elke keer weer terug komen.)

Dat er soms een extra handeling nodig is zoals bijvoorbeeld 2-factor authentication waarbij je op je telefoon nog iets moet goedkeuren of iets dergelijks is prima als dit maar gebruiksvriendelijk en snel is en niet elke 5 minuten opnieuw moet.

Veiliger maken en gebruiksvriendelijkheid gaan hand in hand, dat kost misschien soms wat meer (moeite en/of geld) maar dat is de enige manier om vooruit te komen.

[Reactie gewijzigd door jmzeeman op 24 juli 2024 18:02]

[TRS-3]

[...]
Neem nou bijvoorbeeld het klassieke idee van password policies waarbij je zonder aanleiding, je wachtwoord elke 3 maanden moet veranderen. Klinkt technisch en wiskundig erg goed, maar het gevolg is dat mensen veel simpelere passwords gaan kiezen, een volgnummertje gaan gebruiken of een post-it ergens gaan neerleggen. (Volgens mij is dit specifieke voorbeeld al talloze keren aangetoond staat in security standaarden dat je dit niet moet doen maar toch zie ik het elke keer weer terug komen.)

Nog mooier is als de aannames niet kloppen. Zo heeft het NIST het advies om hoofdletters, kleine letters, cijfers en bijzondere tekens te verplichten (en die elke 3 maand verplicht te vervangen) al weer teruggetrokken (bron o.a. https://www.security.nl/p...27veilige%27+wachtwoorden ). Het blijkt dat deze wachtwoorden vooral een probleem voor de mens vormen, niet zozeer voor de computer. Bij wachtwoordzinnen van behoorlijke lengte is het andersom.

Ik denk overigens dat het werkelijke probleem is dat we in de ICT op drijfzand bouwen. Als je bedenkt hoeveel wiskundig bewijs nodig is om de correctheid van een enkele while-loop aan te tonen, snap je dat de enorme bibliotheken die we inzetten voor de meest eenvoudige programmeerklussen haast wel gatenkaas moeten zijn. Was er zelfs niet een getal voor het aantal fouten per zoveel regels code?

Als je niet langer brandjes wilt blussen moet je bij de basis beginnen: starten op een wiskundig bewezen fundament, en dan weer opbouwen. Dat is commercieel natuurlijk totaal niet interessant, maar de enige manier om uit deze vicieuze cirkel te komen.

[CAPSLOCK2000]

Zo heeft het NIST het advies om hoofdletters, kleine letters, cijfers en bijzondere tekens te verplichten (en die elke 3 maand verplicht te vervangen) al weer teruggetrokken (bron o.a. https://www.security.nl/p...27veilige%27+wachtwoorden ).

Kleine kanttekening omdat dit vaak verkeerd wordt uitgelegd als je het zo opschrijft. Je schrijft het namelijk precies goed, ze adviseren om het niet te /verplichten/. Maar het advies om "moeilijke" wachtwoorden te gebruiken blijft staan. Als je er mee om kan gaan dan kun je de strenge regels beter blijven gebruiken.

Als je niet langer brandjes wilt blussen moet je bij de basis beginnen: starten op een wiskundig bewezen fundament, en dan weer opbouwen. Dat is commercieel natuurlijk totaal niet interessant, maar de enige manier om uit deze vicieuze cirkel te komen.

Ik ben het op zich wel met je eens, maar ik vrees dat het idee niet genoeg is. Formele bewijzen zijn zo ontzettend moeilijk en tijdverslindend dat we er niet op kunnen gaan zitten wachten. Zelfs in de lucht & ruimtevaartindustrie is het niet haalbaar om op grote schaal formele bewijzen te leveren.

Ergens hoop ik dat we nog eens een gigantische fundamentele doorbraak maken in formele bewijzen en het makkelijk genoeg wordt dat iedereen het doet, maar daar kunnen we eigenlijk niet op gokken.

Formele bewijzen zijn helaas nog niet genoeg, al is het maar omdat mensen ook fouten kunnen maken in hun bewijzen. Om het maar niet te hebben over denkfouten, waarbij je het verkeerde probleem hebt opgelost (en bewezen).

Ik denk dat de beste weg voorwaarts is dat we gaan investeren in een aantal (systeem)libraries van extreem hoge kwaliteit, die door iedereen gebruikt kunnen worden. Zodat we in ieder geval een paar heipalen in het drijfzand kunnen slaan.

Ten tweede hebben we een manier nodig om de veiligheid van software te meten. Nu heb je als gebruiker typisch geen inzicht in de veiligheid van de software die je gebruikt. De meesten zijn daar ook niet mee bezig en zien dat als het probleem van de schrijver. Niet alleen "gewone" mensen, maar ook programmeurs zelf die een library gebruiken. Je moet er maar op vertrouwen dat het goed zit want je hebt de tijd (en/of de kunde) niet om het zelf te controleren.

Mensen willen natuurlijk liever het veilige alternatief gebruiken, maar dan moeten ze wel weten wat het is.

Ten derde hebben we betere documentatie en onderwijs nodig. Internet staat helemaal vol met slechte voorbeelden waarbij de dove de blinde helpt met z'n beginnerscursus programmeren. Een goede programmeur kan dat op waarde schatten, maar zoals met alles in deze wereld, zijn er veel meer slechte dan goede programmeurs. Het zou enorm helpen als we beginner direct de goede kant op kunnen sturen. Dit sluit deels aan bij het ontwikkelen van goed standaardbibliotheken. Hoe meer standaard, hoe makkelijker het is om een goed centraal punt te hebben voor documentatie.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 18:02]

[TRS-3]

En een manier voor de afnemer om daar de meerwaarde van te zien. Anders blijft het commercieel oninteressant natuurlijk... of iets voor de Verenigde Naties? Het is zo langzamerhand een bouwsteen voor “world piece” (ik doe m’n Miss Universe dansje ondertussen)

[Empror1]

De Nederlandse professor Robert A. van de Geijn van 'The University of Texas at Austin' is met zoiets bezig voor lineaire algebra, in navolging van de ideeën van Edsger W. Dijkstra. Zie onder andere hier: http://www.cs.utexas.edu/~flame/pubs/fire.pdf.

[koelpasta]

Alleen gaat dat allemaal niet helpen zolang niet alle, en dan bedoel ik ook alle, computergerelateerde zaken op die manier worden gebakken.
De recente problemen met intel cpu's is hier een voorbeeld van. Stel je hebt je software helemaal op orde, dan nog kan dat systeem gebroken worden door de hardware in een bepaalde staat te brengen.

Het is denk ik een onnozele weg om te bewandelen als het op security aankomt. Je hebt dan te maken met De Echte Wereld™ en daar begint je niks tegen met Dijkstra's ideeen over software.

[TRS-3]

Dat geldt andersom ook: het is de Echte Wereld dat we ons volkomen afhankelijk hebben gemaakt van systemen waarvan we maar half weten hoe kwetsbaar we zijn... Mijn betoog is juist: zou je niet moeten beginnen met het slaan van heipalen, en afnemers moeten overtuigen van de meerwaarde van een solide fundament?

[koelpasta]

Ja, in de basis ben ik het volledig met je eens.

[Superstoned]

Klopt, een beveiligingsexpert zou eigenlijk per definitie een UX expert moeten zijn... Wat vaak niet zo is ;-)

Maar er zijn uitzonderingen natuurlijk. Ok, ik roep altijd dat het grootste probleem in security is dat management het ziet als een kostenpost die niets oplevert, misschien zijn er 2 grootste problemen in security - usability & kosten, of beter nog gesteld, gebruikers & management ;-)

[Verwijderd]

Sorry, noem even een club met meer (dagelijkse) gebruikers dan Google.

We zijn (afhankelijk van het type bedrijf/organisatie) nog niet zo ver dat gebruikers door hebben en accepteren dat gebruiksvriendelijkheid iets omlaag moet om veiligheid te kunnen garanderen.

Google is het levende bewijs dat dit niet waar is.

[Bor]

Sorry, noem even een club met meer (dagelijkse) gebruikers dan Google.
....
Google is het levende bewijs dat dit niet waar is.

Niet relevant. DarkEagle31415 geeft niet voor niets aan:

We zijn (afhankelijk van het type bedrijf/organisatie) nog niet zo ver dat gebruikers door hebben en accepteren dat gebruiksvriendelijkheid iets omlaag moet om veiligheid te kunnen garanderen.

Of bovenstaande waar is valt te betwisten. Gebruiksvriendelijkheid zal niet te veel mogen leiden onder een beveiligingsmaatregel simpelweg omdat mensen dan alternatieven en omwegen gaan zoeken.

Wat ik zelf mis in dit verhaal is dat het vaak niet alleen technische maatregelen zijn die een risico beperken terwijl er hier vanuit de IT vaak wel op wordt gefocussed. Beleid en awareness zijn minimaal zo belangrijk!

[DarkEagle31415]

Google heeft een machtspositie (en de aansturende laag is daar pro beveiliging). Nog maar te zwijgen over de resources die ze daar hebben.

Dat is het punt wat ik probeer te maken. In een gemiddelde organisatie wordt er zwaar op IT bezuinigd en is de aansturende laag pro gebruiksvriendelijkheid. Om dit te kunnen doen heb je resources en commitment van een aansturende laag binnen een organisatie nodig. En dat vergeten veel mensen. Het is niet zo dat wij als IT'ers het niet veilig willen hebben, niks liever. Maar we we bijten ons altijd stuk op die punten.

[Reactie gewijzigd door DarkEagle31415 op 24 juli 2024 18:02]

[beantherio]

Het een sluit het ander niet uit lijkt me. En je kunt niet gaan herbouwen als je huis nog in de fik staat.

Het klinkt meer als een PR-praatje over het Chrome-team die de boel (eerlijk is eerlijk) veel beter op de kaart hebben dan een gemiddeld ontwikkelteam.

[Croga]

Het een sluit het ander niet uit lijkt me. En je kunt niet gaan herbouwen als je huis nog in de fik staat.

Leuke analogie. Raakt echter kant noch wal.....

Je kunt wel degelijk aan structurele kwaliteits verbeteringen werken terwijl je "brandjes blust", als het om software gaat.

Ik werk momenteel samen met een team wat geen tijd heeft voor structureel werk omdat er alleen maar brandjes geblust worden. En dus heb ik ze gevraagd welk stukje werk het meeste brandjes zou voorkomen. En laat nou eens een paar brandjes gewoon branden terwijl we dat stukje werk doen. Dat betekend dat we volgende week wellicht 5% ontevreden gebruikers hebben maar ook 10% minder brandjes. En als je dat nou iedere week weer doet heb je op een gegeven moment wél de tijd om (bijna) alleen maar structureel werk te doen.

Het is een mindset verandering. Eentje die niet makkelijk is maar wel nodig.

[Bor]

Dat betekend dat we volgende week wellicht 5% ontevreden gebruikers hebben maar ook 10% minder brandjes. En als je dat nou iedere week weer doet heb je op een gegeven moment wél de tijd om (bijna) alleen maar structureel werk te doen.

Het probleem zit hem met een aanpak als deze dat hij niet houdbaar is. Die 5% ontevreden klanten stapelen zich per week op en lopen op termijn wellicht zelfs weg. Je bijt min of meer in de hand die je voedt. Dit kan uiteindelijk zelfs tot naamverlies lijden.

De enige echte oplossing is het structureel aanpakken van de problemen waarbij dit niet ten koste van de klanttevredenheid gaat (of in ieder geval zo min mogelijk). Hetzelfde geldt ook bij beveiligingsoplossingen. Zoek in ieder geval tenminste de balans op tussen veiligheid en werkbaarheid.

Leuke analogie. Raakt echter kant noch wal.....

In jouw voorbeeld laat je zaken moedwillig branden om ergens anders structurele verbeteringen aan te brengen. Hoewel de analogie niet helemaal opgaat heeft hij wel degelijk een punt. Wanneer iets "in de fik staat" is het zaak iets zo snel mogelijk op te lossen omdat het direct een gevaar is voor het voortbestaan. Je kunt dan vaak niet beslissen om iets gewoon maar te laten gaan, zeker niet wanneer het om beveiligingsrisico's gaat wat nog steeds het onderwerp is van dit topic. Uit dat oogpunt is jouw advies misschien helemaal niet zo relevant. Je biedt immers alleen op langere termijn een oplossing ten koste van de huidige veiligheid.

Niet alleen is dat niet slim, je kunt ook nog eens aansprakelijk worden gesteld voor zaken die wel bekend zijn maar moedwillig zijn blijven liggen.

[Reactie gewijzigd door Bor op 24 juli 2024 18:02]

[DarkBlazer]

dat is ook een van de redenen waarom wij binnen de organisatie gebruik maken van Bromium Secure Platform.
Door dit te implementeren hebben we een tijdelijke muur opgezet waardoor we bezig konden gaan met het structueel veranderen van de mind set binnen de organisatie en het blussen van branden.

Door de implementatie van Bromium waren onze gebruikers niet allemaal blij maar snapten de redenering wel waarom we het geimplementeerd hebben. niet alleen voor onze eigen beveiliging maar ook voor hun zelf.

[Croga]

Het probleem zit hem met een aanpak als deze dat hij niet houdbaar is. Die 5% ontevreden klanten stapelen zich per week op en lopen op termijn wellicht zelfs weg. Je bijt min of meer in de hand die je voedt. Dit kan uiteindelijk zelfs tot naamverlies lijden.

Continue alleen maar brandjes blussen is nog minder houdbaar; de brand zal alleen maar groter worden en tot nog veel meer ontevreden klanten en naamverlies leiden....

De enige echte oplossing is het structureel aanpakken van de problemen waarbij dit niet ten koste van de klanttevredenheid gaat (of in ieder geval zo min mogelijk). Hetzelfde geldt ook bij beveiligingsoplossingen. Zoek in ieder geval tenminste de balans op tussen veiligheid en werkbaarheid.

Het probleem met dit idee is dat tijd eindig is. Je kunt niet én brandjes blussen én structureel aanpakken als de brandjes meer tijd in beslag nemen dan je hebt. Dan is je enige optie een paar brandjes laten branden terwijl je een structurele oplossing realiseert.

[Bor]

Continue alleen maar brandjes blussen is nog minder houdbaar; de brand zal alleen maar groter worden en tot nog veel meer ontevreden klanten en naamverlies leiden....

Klopt, de oplossing ligt dan ook in het structureel oplossen en tot die tijd de branden blijven blussen. In jouw voorbeeld kun je dit alleen bereiken door uitbreiding van het aantal FTE's, tijdelijk of structureel. Het niet doen van het ene om het andere te kunnen doen is geen houdbare oplossing in veel gevallen, zeker niet wanneer het om (informatie) beveiliging gaat.

[Reactie gewijzigd door Bor op 24 juli 2024 18:02]

[Croga]

Klopt, de oplossing ligt dan ook in het structureel oplossen en tot die tijd de branden blijven blussen. In jouw voorbeeld kun je dit alleen bereiken door uitbreiding van het aantal FTE's, tijdelijk of structureel. Het niet doen van het ene om het andere te kunnen doen is geen houdbare oplossing in veel gevallen, zeker niet wanneer het om (informatie) beveiliging gaat.

De aloude illusie dat FTEs toevoegen gaat helpen is al lang verworpen. Zoals we in de jaren 80 al riepen: Het toevoegen van mensen aan een project wat te laat is garandeert dat het project nog later zal worden.

In de IT is kennis je belangrijkste wapen. Iemand toevoegen zodat je meer kunt doen dan brandjes blussen zal er voor zorgen dat het hele team langzamer wordt zodat die ene persoon ingeleerd kan worden met als resultaat dat je nog langzamer brandjes gaat blussen en tegelijkertijd meer brand gaat krijgen omdat de nieuweling de brandjes alleen maar erger maakt.

FTEs toevoegen is nooit de oplossing. Zelfs geen slechte oplossing.

[beantherio]

Natuurlijk kun je dingen tegelijkertijd doen: zoals ik letterlijk in mijn reactie schreef sluit het een het ander niet uit. Maar de insteek van het verhaal lijkt te zijn dat maar een van de twee routes "juist" of mogelijk is. Dat lijkt me niet correct.

[ppl]

Leuke analogie. Raakt echter kant noch wal.....

De analogie is zo gek nog niet en raakt wel degelijk kant en wal. Bij een inzet van de brandweer zijn de eenheden niet beschikbaar voor ander werk, zij doen alleen datgene waarvoor ze op dat moment zijn uitgerukt (iets wat ook opgaat voor het materieel dat meegaat). Het gaat hier dan ook om capaciteit en hoe je dat inzet.

Je kunt wel degelijk aan structurele kwaliteits verbeteringen werken terwijl je "brandjes blust", als het om software gaat.

In de perfecte werkelijkheid wel. In het echt heb je te maken met lastige dingen als capaciteit (aantal mensen die je in kunt zetten) en allerlei contractuele bepalingen (waar dus ook dingen als een SLA en OLA bij horen). Dat laatste heeft juridische implicaties. Daarbij komt dat niet ieder team overal van af weet. Technische teams zitten vooral in de techniek en niet in de contracten terwijl de juristen weer niet in het technische plaatje zitten.

En laat nou eens een paar brandjes gewoon branden terwijl we dat stukje werk doen. Dat betekend dat we volgende week wellicht 5% ontevreden gebruikers hebben maar ook 10% minder brandjes. En als je dat nou iedere week weer doet heb je op een gegeven moment wél de tijd om (bijna) alleen maar structureel werk te doen.

Of je bent failliet door alle boeteclausules waar je door die 5% ontevreden klanten aan herinnert wordt of de rechtszaken die ze starten obv contracten/SLA's. Je stelt het hier echt veel te simplistisch voor. Wat je hier tikt vergt inzicht in de juridische en financiële gevolgen. Dat zijn geen beslissingen die je als team kunt nemen, dat zul je als bedrijf moeten doen (en in veel gevallen is dat een beslissing op directie niveau). Dat betekent dus ook dat dit soort verbeteringen absoluut niet beperkt zijn tot de technisch inhoudelijke zaken. Het kan namelijk zomaar zijn dat je contracten/SLA's moet openbreken om het allemaal haalbaar te kunnen maken.

Bovendien zijn er ook andere manieren om dit op te lossen. Om weer terug te komen op de analogie: bij de brandweer hebben ze op dit vlak ook naar de capaciteit gekeken. De meeste uitrukken zijn vrij standaard waar maar een klein gedeelte van de volledige capaciteit (bemanning en materieel) voor wordt ingezet. De rest is gewoon vrij beschikbaar voor andere meldingen.

[Verwijderd]

Als het een PR-praatje is: wie is de doelgroep precies?

[burne]

.. als je op een podium op Black Hat staat.... ?

(er zal daar weinig commercieel volk rondlopen..)

[Superstoned]

Wel veel journalisten, anders was het hier ook niet beschreven ;-)

Goede marketing hoor...

[Bor]

Het kan natuurlijk gaan om het beïnvloeden van de algehele opinie over Google welke toch al min of meer een steeds slechtere naam krijgt in veel kringen vanwege de data honger. Een doelgroep hoeft niet altijd een afgebakende beperkte groep te zijn. Ook in security land is PR en aanzien belangrijk.

[Verwijderd]

Je kan wel een nieuw huis zetten terwijl het oude in de fik staat.

Wat verderop tentje zetten, daar tijdelijk gaan wonen, lening aangaan en nieuw huis zetten.

In software ontwikkeling doen we dat met git branch.

[batjes]

Misschien zou Google op dit vlak eens bij MS aan kunnen kloppen ipv project zero misbruiken om MS op de hak te nemen en zelf het wiel uitvinden.

[BBRabbiB]

En wie zegt dat ze dat niet doen of gedaan hebben? Het hoeft geen kwestie van of-of te zijn. Misschien hadden ze dat al eerder gedaan en heeft MS dit advies aan zijn laars gelapt. Allemaal speculatie natuurlijk.

Maar blijkbaar werkt de aanpak van Google wel als het klopt dat nu 98% binnen de termijn van 90 dagen wordt opgelost.

[batjes]

Op basis van de geschiedenis tussen deze 2 kan je er bijna wel vanuit gaan dat dit niet gebeurd is. Google die uit zichzelf met MS gaat samenwerken? Lol. Die 2 zijn alles behalve vrienden. Als Google dat wel gedaan had, had Google dat wel laten merken. want die laat echt geen moment aan zich voorbij gaan om MS op de hak te nemen. (nogmaals, zie geschiedenis)

MS heeft 1 van de meest complexe en beste toolkits om bugs en security exploits te vinden in code/software. Beter als die 2 in dit geval hun krachten bundelen dan beide hun eigen koppige weg te vervolgen. Als je structureel wat aan securtity wilt doen tenminste, zoals deze topdame loopt te claimen. Dan is samenwerking de toekomst.

98% van de problemen wordt gefixt, maar wie zegt dat het door die strengheid van Google komt, om die bal even terug te kaatsen. Want 1 van de meest serieuze exploits die de afgelopen decenia gevonden is door (o.a.) Google. Kreeg meer dan 6 maanden de tijd om niet met een oplossing te komen. Google is heel laks met die 3 maanden regel naar iedereen behalve MS. Er wordt duidelijk met 2 maten gemeten in dit opzicht, en dat vind ik jammer.

[MrBlues]

Google is zelf ook niet heilig. Circa 5 jaar geleden ondersteunde AdWords, het meest gebruikte advertentie netwerk ter wereld, nog geen eens https.

[Slavy]

Moet zeggen dat ik het toch wel eens ben met haar gedachte gang, echter is het toch eigenlijk wel vreemd dat ze moet voorstellen om vaker een RCA te doen i.p.v. brandjes te blussen, dit zou gewoon een standaard moeten zijn wat helaas niet zo is.

[Deguchi]

Link naar de video:
https://www.youtube.com/watch?v=py2qmGbyhlw

Zij begint op 23:40

[GEi]

Heb zijdelings te maken met health & safety in de offshore. Veel van wat ik lees is al dagelijkse praktijk in bepaalde sectoren op het gebied van health & safety. Het voorkomen van (bijna) ongevallen. Bijvoorbeeld de 5x Why, vraag door naar het waarom om de onderliggende oorzaak (root cause) te achterhalen. Maar ze heeft wel gelijk, en nee, dat is geen korte termijn politiek; dat duurt even voor de hele branche deze mindset heeft.

[Kalief]

Dom advies. Ze stelt in zoveel woorden dat we eerst een ideale wereld moeten creëren en dat daarna fouten niet meer zullen optreden. Alleen moeten we tot die tijd toch eerst problemen blijven oplossen. Nog afgezien van de vraag of die ideale wereld er ooit wel komt.

[robvanwijk]

Daarbij bespreekt Tabriz het voorbeeld van de introductie van site isolation in Chrome, wat ze aanduidt als een van de meest fundamentele veranderingen in Googles browser. Het werk aan die functie begon in 2012 en het was de verwachting dat het een jaar zou duren om deze te implementeren. Uiteindelijk duurde het zes jaar

Maar dat is dan toch, volgens Google's eigen regels, ruim vijf jaar te laat? Als je de site isolation functie toevoegt om beveiligingsproblemen te voorkomen (of op te lossen), dan had het gewoon in 90 dagen klaar moeten zijn. Waarom geldt die regel niet voor Google zelf...?

[Craften]

[...]
security diva

Security diva, omdat het een vrouw is zeker?
Zo'n opmerking zie je nou niet vaak bij een mannelijke security officer, of andere functie.

Verder ben ik het met @anandus eens, dit is niet aan haar om te weten. Ja er worden wat open deuren ingetrapt, maar ze stelt wel de goede vragen.

[Iblies]

[...]


Security diva, omdat het een vrouw is zeker?
Zo'n opmerking zie je nou niet vaak bij een mannelijke security officer, of andere functie.

Verder ben ik het met @anandus eens, dit is niet aan haar om te weten. Ja er worden wat open deuren ingetrapt, maar ze stelt wel de goede vragen.

Als er al een kern van waarheid inzit, is het dat juist niet beangstigender?
En nog beangstigender, is het geen verwijt naar Google zelf die ze vervolgens in globale termen verpakt. Ze haalt een zeer specifiek probleem aan bij Google zelf die pas in 2018 is opgelost...
En voor de goede orde, ze werkt er al 11 jaar, en 2 jaar als leidinggevende.


Prachtige speech, helemaal mee eens,
alleen ze zit nu in een positie om het te gaan implementeren. Des te vreemder dat ik het vind dat ze buiten de organisatie gaat uitleggen hoe het moet, terwijl het binnen Google nog geen common practise is.

[Yggdrasil]

Een cultuur binnen een organisatie van het formaat Google veranderen is niet eenvoudig maar men is daar duidelijk mee bezig. Dat wil toch niet zeggen dat andere organisaties moeten wachten tot dit proces klaar is? De industrie als geheel zou er beter van worden als iedereen hieraan werkt.

[Iblies]

Voor mij komt het ook over als een halve sollicitatie.

•De industrie bestaat niet
•en andere bedrijven zijn terdege ook bezig om fundamentele wijzigen aan te brengen in hun software, alleen ontkom je er niet aan om soms met een patch te werken en later met een meer structurele oplossing.


Het zou me niet verbazen als ze op korte termijn ergens anders aan de slag gaat met een soortgelijke functie waarbij ze wel meer vrije ruimte zal krijgen om haar ideeën beter te implementeren.

[3dfx]

[...]
Security diva, omdat het een vrouw is zeker?

Klopt helemaal, want bij een man zou het de mannelijke vorm (divo) moeten zijn.

[anandus]

Die deadline van 90 dagen is in de praktijk vaak nog veel te lang bij een serieus lek.

Maar is dat een technisch verhaal of een bedrijfskundig verhaal?
Volgens mij heeft het vooral te maken met het feit dat een bedrijf een lek helemaal geen prioriteit geeft (want levert geen geld op).

[Reactie gewijzigd door anandus op 24 juli 2024 18:02]

[Bor]

Volgens mij heeft het vooral te maken met het feit dat een bedrijf een lek helemaal geen prioriteit geeft (want levert geen geld op).

Nee het levert inderdaad geen geld op, het niet fixen van een bekend lek kost (uiteindelijk) geld en soms erg veel ook.

[PPie]

Het probleem is dat het niet dat bedrijf geld kost, maar anderen.
En dat levert niet de prikkel om er dan daadwerkelijk wat aan te doen...

[Verwijderd]

ligt aan het systeem / programma. De ene update je makkelijker dan een andere. wat bijvoorbeeld wel leuk om te weten is dat, microsoft een tijdje geleden de gecompileerde bytecode heeft aangepast (met een replace) om zo de bug op te lossen. als bits integriteit bits bevatten wordt dit best ingewikkeld omdat alle bit flips dan goed moeten staan wil je de wijziging laten draaien. Het osi model, waarbij je denk ik de moeilijkheidsgraad in de laag van 1 naar 7 moet zien (1 moeilijk, 7 makkelijker)

[Finraziel]

Antwoorden is een stap verder en hangt van de situatie af. De eerste stap is om de vragen te stellen en dat gebeurt vaak inderdaad niet. Als de vragen niet gesteld worden dan komen er zeker geen antwoorden.

[Jaap-Jan]

Ze kan daar geen antwoord op hebben, want de reden is per situatie anders. Er zijn zoveel redenen te redenen waarom het maken van een fix lang geduurd heeft, maar dat is juist iets wat elke organisatie voor zichzelf moet bepalen.

[Arcticwolfx]

Een professor vertelde mij eens; "Als je de vraag weet, weet je de helft van het antwoord"

[polthemol]

je verwacht dat ze die vraag beantwoord? Kun jij beantwoorden waarom het zo lang duurt om een update te testen dan? Dat is aan de testafdeling(en) om daar met een antwoord op te komen.

De 'why'-vraag is niet persé om een antwoord te krijgen, het is uitermate geschikt om een andere partij eens na te laten denken over functioneren/een proces en dat is precies wat ze doet.

[dennizv2]

Dat 90 dagen proces betekent niet altijd dat je ook 90 dagen een lek hebt. Hoe vaak zie je tegenwoordig dat je een tijdelijke fix krijgt (gepaard met bijv. performance verlies) terwijl je wacht of de nieuwe patch. Was met spectre en meltdown toch net zo?

[peterhagen]

Volgens mij is het een retorische vraag

[Yggdrasil]

Nee, dat is het niet. De vraag moet echt beantwoord worden, niet door haar maar door het team dat te maken krijgt met een 'beveiligingsbrandje'. Het antwoord zal in ieder geval anders zijn, maar is wel belangrijk om te bepalen.

[peterhagen]

ja uiteraard, maar in het verhaal wat ze voert is het retorisch

[Raindeer]

Zij zegt dat het nu in 98%van de gevallen nu lukt. Ze zegt dat bedrijven ook de structuur van hun aanpak veranderen om de termijn te halen. Welke data of ervaring heb jij om te suggereren dat die 90 dagen die een bedrijf krijgt voor publicatie te lang is? Wat voor termijn stel jij voor? Wat voor effect heeft een kortere termijn op het ontwikkelen en bouwen van software?

Waarom zijn haar opmerkingen open deuren als de ervaring leert dat bedrijven nog vaak alleen maar de bug fixen en niet secure werken? Dat jij en ik het weten is iets anders dan dat teams secure (mogen) werken?

Ennuh Diva, in combinatie met deze kritiek, kan echt niet. Wees wat beleefder en respecteer vrouwen in de ICT. Check your privilege

[unclero]

"Tabriz is binnen en buiten Google het beste bekend onder de aanduiding security princess"

Ik zie niet in waarom "security diva" dan wel een probleem is.

Dat komt omdat zij die titel zelf heeft bedacht en op haar naamkaartje en visitekaartjes heeft laten zetten.

Dat zij zelf een titel voor zichzelf bedenkt, geeft iemand anders nog niet het recht om dan zelf ook maar een (al dan niet kleinerende) bijnaam te verzinnen. Op kantoor ben ik bekend als "die dikke eikel". Maar als jij zomaar op me af zou stappen en zou zeggen "hey, dikke eikel!" dan roei ik je over je bakkes. 'consent' schijnt het buzzwoord van de laatste tijd te zijn, dat geldt ook bij aanspreekvormen.

[Kwistnix]

'consent' schijnt het buzzwoord van de laatste tijd te zijn, dat geldt ook bij aanspreekvormen.

Dit gaat volledig offtopic, excuses daarvoor, maar ik wil het wel even gezegd hebben.

In dat gedachtengoed weiger ik dus pertinent mee te gaan. Overal instemming/toestemming voor vragen en iedereen zo omzichtig mogelijk benaderen is onwerkbaar en wat mij betreft onnodig en zelfs onwenselijk. Waar houdt dat op, waar ligt de grens en wie bepaald die grens? Benader en behandel mensen met respect, maar ga vooral niet op je tenen lopen om koste wat kost te voorkomen dat iemand zich mogelijk wel eens ongemakkelijk of beledigd zou kunnen voelen om de meest uiteenlopende redenen. Volwassen dienen weerbaar te zijn als ze willen functioneren in een samenleving. En nee, dat geeft niemand het recht om mensen ronduit te schofferen.
Om terug te pakken op security princess vs. security diva, die twee liggen zo dicht bij elkaar dat ze nauwelijks te onderscheiden zijn. En als iemand zichzelf bewust zo wegzet, dan heeft die persoon zichzelf in een moeilijk te verdedigen positie gebracht, wanneer die persoon paradoxaal niet wenst zo aangesproken te worden. Als dat hier al het geval is, want hier betrof het een random persoon op het internet die, wat mij betreft, volkomen onterecht in de verdediging schoot en iemand besloot de maat te moeten nemen door hem direct van respectloosheid te betichtten en hem op zijn "privileges" te wijzen. Dat zet de toon van dit soort dicussies direct verkeerd, wat mij betreft.

[RebelwaClue]

Parisa heeft zichzelf genoeg bewezen om de functie die ze heeft te rechtvaardigen. Maar ben wel benieuwd van welke vrouwen jij vindt dat ze op vooruitgeschoven posities zitten, meestal moet een vrouw harder werken om dezelfde positie te krijgen als een man.

[borft]

moet een vrouw als een man werken? of bedoel je dat ze harder dan een man moet werken?

[RebelwaClue]

Harder dan een man moet werken

[Yggdrasil]

Ik zie anno 2018 teveel vrouwen in ICT die op vooruitgeschoven posities zitten enkel omdat ze vrouw zijn.

Voorop gesteld dat ik bovenstaande niet met je eens ben, doe je er goed aan haar prestaties en positie op zichzelf te beoordelen in plaats van als een gevolg van haar geslacht. Als je een hekel hebt aan positieve discriminatie dan kun je het beste beginnen met niet meedoen aan negatieve discriminatie.

Terug on-topic.

Van een security expert verwacht ik meer dan dit.

Haar observatie is voor de hand liggend maar ik vind dat ze met haar onderbouwing en de voorbeelden over hindernissen die het Chrome team moest overwinnen precies de juiste snaar raakt. Symptoombestrijding komt inderdaad teveel voor in de Sec wereld en met haar positie kan ze hier aandacht voor creëren.

[Lapa]

Wat verwacht je in hemelsnaam dan nog meer van een speech op een conferentie. Ze kaart een wijdverbreid cultuurprobleem met beveiliging aan. Ze legt uit wat ze bij Google doen om dat zowel intern als extern te verminderen. Met concrete voorbeelden en het inzicht dat het ook bij Google niet altijd makkelijk is om de hele organisatie daarvan te overtuigen, maar dat het wel vruchten afwerpt als dat toch lukt.

[Grauw]

Ik zie anno 2018 teveel vrouwen in ICT die op vooruitgeschoven posities zitten enkel omdat ze vrouw zijn.

Och jezus. Waar is de kotssmiley.

[roy-t]

Glansrijke carrière van 11 jaar werken bij Google. Alom bekend in de security wereld. Maar nee ze is een vooruitgeschoven vrouw, want tweaker2010 vind dat ze niet genoeg uitleg geeft na het lezen van een paar korte quotes van haar keynote....

Soms snap ik niet goed waarom er zo weinig vrouwen in de IT zijn, maar gelukkig is er dan toch weer iemand met zo'n bekrompen reactie dat ik het weer snap...