Facebook-beveiligingshoofd Alex Stamos stapt op

Alex Stamos, die sinds 2015 de rol van chief security officer bij Facebook vervult, heeft bekendgemaakt op 17 augustus bij het bedrijf te vertrekken. Er gingen al eerder geruchten dat hij had besloten het bedrijf te verlaten na onenigheid over de aanpak van desinformatie.

In een bericht op Facebook laat Stamos weten dat hij in september aan de slag gaat bij de universiteit van Stanford als docent en onderzoeker. In de herfst gaat hij een vak onder de naam Hack Lab aanbieden waarin 'offensieve en defensieve technieken' aan bod komen. Facebook laat in een e-mail aan The Verge weten dat het geen vervanger heeft aangewezen voor de positie van chief security officer. Het bedrijf heeft geen gespecialiseerd beveiligingsteam meer, maar heeft die medewerkers ondergebracht in andere afdelingen.

The New York Times had eerder op basis van bronnen binnen Facebook bericht dat Stamos opstapte vanwege meningsverschillen over de aanpak van desinformatie. Hij sprak die berichtgeving later zelf tegen. De krant schreef dat Stamos voorstander was van het bieden van meer openheid over beïnvloeding van buitenaf op Facebook en dat hij het noodzakelijk vond een herstructurering door te voeren om de problemen aan te pakken. Ook zou zijn team van oorspronkelijk 120 personen zijn teruggebracht naar 3.

Het vertrek van Stamos gaat gepaard met een recente mededeling van Facebook dat het opnieuw accounts en pagina's heeft verwijderd die onderdeel zouden zijn van een beïnvloedingscampagne.

Reacties (51)

[walteij]

Het bedrijf heeft geen gespecialiseerd beveiligingsteam meer, maar heeft die medewerkers ondergebracht in andere afdelingen.

Dit vind ik dan wederom een enge ontwikkelling. Het voordeel van een gespecialiseerd team is dat zij alleen maar met beveiliging bezig zijn. Dit zijn meestal ook echte vakidioten die gewoon helemaal de focus op security en het voorkomen van security breaches hebben.

Als deze medewerkers nu zijn/worden ondergebracht in andere afdelingen, zullen ze op die afdeling roepende in de woestijn worden. Zij zijn daar namelijk de enige met een echte focus op security.
Ook zullen ze zich met de reguliere werkzaamheden van de betreffende afdeling moeten gaan bezigen, waardoor de aandacht wordt weggehaald van security.

Juist met de recente security 'lekken' (Cambridge Analytics en de vele verwijderde apps die veel te veel informatie verzamelden), zou je toch zeggen dat een dedicated team hier veel efficienter mee kan omgaan.

[Verwijderd]

Juist met de recente security lekken moet je géén dedicated security team hebben dat vanuit een ivoren toren gaat lopen roeptoeteren wat er met security moet gebeuren.

Als het gaat om security lekken:

• De CISO kan niet voorkomen dat er data lekt
• Geen enkele interne consultant kan voorkomen dat er data lekt
• Geen dedicated security team hoe groot kan voorkomen dat er data lekt

Waar je het wel kan voorkomen is:

• Bij de software developers die daadwerkelijk code kloppen en bugs fixen.
• Bij de netwerk engineers die firewalls bijhouden en infra bouwen
• Bij de storage engineers die opslag regelen en fixen
• Bij de backup engineers die er voor zorgen dat er recovery is.

Dus daar plaats je je security mensen. En dat is precies wat Facebook doet.

[Aaargh!]

Juist met de recente security lekken moet je géén dedicated security team hebben dat vanuit een ivoren toren gaat lopen roeptoeteren wat er met security moet gebeuren.

De mensen die er dagelijks aan werken kennen de code te goed en lezen over obvious problemen heen. Je laat hier de slager zijn eigen vlees keuren, altijd een slecht idee.

Het security team moet juist onafhankelijk zijn en over de hoofden van de management-types heen kunnen gaan die security toch maar onzin vinden. Als je ooit eens een grondige security audit hebt meegemaakt door een onafhankelijke partij (intern of extern) dan weet je hoe ontzettend waardevol dit kan zijn.

Uiteraard begint security bij je developers, maar deze maar laten aanklooien is geen optie. Wat je wel doet is richtlijnen stellen voor veilige software ontwikkeling, statische code analyses, code reviews, etc. Wie richt dit allemaal in zonder dedicated security team ?

[Verwijderd]

Precies wat Facebook gaat doen, en iets wat helaas niet duidelijk genoeg naar voren kwam in mijn verhaal: security mensen in het team. Omdat je het dáár kan voorkomen moeten je security mensen dáár zitten.

[Aaargh!]

security mensen in het team

Ja, dat was mij wel duidelijk en is een HEEL slecht plan.

IN het team, betekend ONDER de manager die alleen maar zo snel mogelijk z'n project af wil af hebben en security is onzichtbaar en ziet er niet slick uit in een powerpoint presentatie. Die heeft liever dat je wat extra features bouwt.

Je moet security mensen vanaf het begin bij je projecten betrekken, maar ze moeten buiten het team staan in een compleet onafhankelijke hiërarchie met de autoriteit de rest v/d organisatie te overrulen, tot aan de CEO aan toe.

[Mittchel]

Dit zijn allemaal aannames die jij doet. Het gaat hier over Facebook en jij trekt het sowieso al naar een algemenere plaat toe wat verkeerd is.

Wie zegt dat de manager van een specifiek team zo over een security dev heen stapt? Denk je nou echt dat met de recente schandalen bij Facebook hier niet op gehamerd wordt?

Persoonlijk vind ik het inderdaad erg handig om een security dev in je team te hebben. Bij code reviews, maar zelfs al bij refinements van de stories besteedt je al extra aandacht aan security. Denk je verder dan een developer misschien alleen zou doen.

[Reactie gewijzigd door Mittchel op 26 juli 2024 21:07]

[Aaargh!]

Wie zegt dat de manager van een specifiek team zo over een security dev heen stapt?

Daar gaat het helemaal niet om. Het gaat er om dat ie de mogelijkheid helemaal niet moet hebben.

Persoonlijk vind ik het inderdaad erg handig om een security dev in je team te hebben. Bij code reviews, maar zelfs al bij refinements van de stories besteedt je al extra aandacht aan security.

Je kan iemand van security erbij betrekken zonder dat deze onderdeel is van je team.

[Verwijderd]

Helemaal eens. Maar zolang een eindklant niet eist dat het zo is, zal het zelden zo gedaan worden.

In een Scrum omgeving is het normaal gesproken zo dat zowel testers als eindklant betrokken en aanwezig zijn bij bepaalde rituelen/meetings (zoals de demo). Op zulke momenten zou een bekwame eindklant moeten zeggen: en hoe hebben jullie de security getest?

Of eventueel levert de klant externe testers aan. M.a.w. spreek met de software leverancier af dat een deel van de test -en code review capaciteit door de klant wordt aangebracht (m.a.w. is het contract daardoor minder duur).

Dat gaat natuurlijk van een eindklant uit. Dat is bij bv. Facebook niet het geval. Die bouwen daar geen software voor een eindklant. In het geval van Facebook, vind ik, moet bv. de overheid dit op zich nemen en hoort Facebook daar een verplicht te betalen belasting voor neerleggen. Want het is van maatschappelijk belang dat de beveiliging van Facebook in orde is (zie Cambridge Analytica, waarbij in zo'n setting de externe leverancier van testers, geleverd door de overheid, waarschijnlijk zou opgemerkt hebben dat wat CA aan het doen was mogelijk is tenzij A, B en C gedaan wordt - te minste als ze hun job als security-testers naar behoren doen).

[Verwijderd]

Je moet security mensen vanaf het begin bij je projecten betrekken, maar ze moeten buiten het team staan in een compleet onafhankelijke hiërarchie met de autoriteit de rest v/d organisatie te overrulen, tot aan de CEO aan toe.

Ik zal het er de volgende keer bij uitleggen. Dat leek me iets te vanzelfprekend...

Overigens is de eerste manager die dat bij mij flikt gelijk buiten maargoed.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 21:07]

[Aaargh!]

Ik zal het er de volgende keer bij uitleggen. Dat leek me iets te vanzelfprekend...

Je had het over iemand die IN het team zat, dan is het uiteraard niet vanzelfsprekend dat je bedoelt dat ie NIET in het team zit.

[Verwijderd]

Tja weet je,

de manager die alleen maar zo snel mogelijk z'n project af wil af hebben en security is onzichtbaar en ziet er niet slick uit in een powerpoint presentatie.

Dit is al het probleem. Als je daar last van hebt maakt het niks uit waar die gasten zitten.

[Aaargh!]

Geen handtekening van security = geen release = geen bonus. En opeens is de manager wel gemotiveerd

[walteij]

Ik heb het ook nergens over een ivoren security toren, dat is inderdaad een slecht idee.
Sterker nog, security moet gewoon een basis onderdeel van je ontwikkelling en je ontwerp zijn, Dat begint dus bij het bedrijfsbeleid, het architectuur model, daarna je storage/network/backup/software ontwerp (afgeleid van je architectuur richtlijnen).
Software dient ook getest te worden, niet alleen functioneel, maar ook op beveiliging. In productie name kan dus alleen gebeuren als alle tests succesvol zijn:

• Voldoet de software aan de technische eisen
• Voldoet de software aan de functionele eigen
• Voldoet de software aan de beveiligingseisen

Pas als alle eisen een OK stempel hebben gekregen, kan de software in productie worden uitgerold. Uitzonderingen dienen beargumenteerd, geaccordeerd en gedocumenteerd te worden door het MT, samen met een plan om de uitzonderingen in de nabije toekomst weg te werken.

Overleg tussen de teams is dus van belang, maar er zal een security poppetje moeten zijn die het mandaat heeft om de uitrol van een product tegen te houden.

[Verwijderd]

Ben het helemaal eens met je. Maar de praktijk loopt helaas vaak anders.

Als release maintainer voor zo'n 250 programmeurs zei ik ooit met regelmaat tegen onze product owner: Wat niet getest is, werkt niet. Daarom waarvan je me niet kan aantonen dat je testers het getest hebben, stop ik niet in de release en ga ik niet installeren (wat jij als product owner er ook van vindt).

Voorbeeld anecdote met een toepassing in security: Hij sprak me tegen dat testen nodig is voor de authenticatie-methode van een bepaalde applicatie.

Het ging, geloof ik, over NTLM authenticatie vs. Kerberos waarbij er kennelijk naar NTLM (als ik me het goed herriner) werd teruggevallen niet doordat Kerberos wel of niet beschikbaar was maar wel omdat het fout geïmplementeerd was (fout in onze software dus). De in-house test-omgeving liet de fallback naar NTLM toe, de test omgeving bij de eindklant (= identiek aan productieomgeving) niet. Ik had de release er voor, als release maintainer (die als programmeur ook weet waar hij mee bezig is), al één en ander getest op de test omgeving bij de eindklant en ik had al gemerkt dat onze in-house test-omgeving wat betreft deze authenticatie verschillend was dan de test-omgeving bij de eindklant.

Dus merkte ik dat verschil op bij de product owner. Want die authenticatie features zouden er binnenkort aankomen in één van de volgende releases (ik hield dat bij). Die "ging er iets aan doen". Na een paar weken was er nog nergens een JIRA ticket om de in-house test-omgeving gelijk te zetten. Dus maakte ik die JIRA ticket maar zelf aan (als release maintainer), met hoge prioriteit (want een twee weken later moest die release bij de eind-klant geïnstalleerd worden). Want hoe kon men het anders getest hebben voor ik de release bij de eind-klant ging installeren?

Dus komt meneer de product owner naar mijn bureau ruzie maken dat het niet nodig is om onze test omgeving gelijk te trekken met de test omgevingen bij de eindklant. En dat hij de JIRA ticket ging sluiten want de prioriteit is niet aan mij en hij beslist dat. Zo van die nonsense.

Toen antwoordde ik: wat niet getest is, zal niet werken.

Goed ik moest toch gaan installeren. Dus voorspelde ik de dag er voor: dat zal niet werken. You'll see. Ik heb hem zelfs op E-mail laten zetten dat hij ongeacht mijn waarschuwing en het openen van dat JIRA ticket en het gebrek aan aangetoonde testen ervoor wilde dat ik toch ging installeren.

Wat werkte er niet? De Kerberos authenticatie. Ik kon dus terug naar huis. Installatie van de release was (in de ogen van de eind-klant, en ook in mijn ogen) mislukt (want zonder Kerberos autheticatie mocht er, terecht, niets op die omgeving uitgevoerd worden - zo'n klant wil de omgeving met hun productie identiek. Zodat er géén verrassingen zijn, geen enkele, bij hun uitrol op productie een paar weken later).

Dat heeft toen voor het software huis erg veel geld gekost, en betekende bijna het einde van het project (het was al het zoveelste dat niet in orde was, en dit vond de eindkant fundamenteel).

Ik ben daar weggegaan. Want die product owner was eigenlijk een onnozelaar die van software ontwikkeling niets begrijpt. Ik wilde als zelfstandig programmeur ook geen reputatieschade bij de eindklant oplopen (m.a.w. ik werk niet voor prutsers).

Zo loopt het helaas bij veel software huizen. Je hebt ook erg veel cowboy programmeurs (ook wel eens brogrammers genoemd). Die doen maar wat. En doen dan stoer en zo. Zonder dat ze snappen waar ze mee bezig zijn. Die hun software draait op allerlei dingen. Mensen denken alleen maar dat dat allemaal goed zal lopen. Is niet altijd zo.

[Sissors]

En andersom kan je stellen dat met een dedicated security groep je dus iets krijgt waarbij achteraf die groep er ook nog naar moet kijken, en dat dat een groep is wiens bezwaren dan snel worden weggewuifd. Terwijl als je het juist bij de betreffende afdelingen integreerd het vanaf het begin van een ontwerp proces wordt meegenomen.

[walteij]

Dat is een kwestie van beleid. Ieder 'product' dient door security gecontroleerd en goedgekeurd te worden, zo niet, wordt het niet in productie genomen.
Een security medewerker op een reguliere afdeling kan alleen naar zijn eigen teamleider escaleren. Die teamleider snapt echter weinig of niets van security, dus wimpelt dit af, omdat het nieuwe product zoveel meer inkomsten kan genereren (of zoveel meer data kan verzamelen).

Met een dedicated security afdeling en het juiste beleid kan een security afdeling producten beter tegen houden. Ook escalatie gaat dan beter, omdat je security teamleider ook weet waar het over gaat en deze dus op een hoger niveau argumenten kan plaatsen waarom iets niet kan en hoe dit opgelost moet worden.

En natuurlijk moet security bij een nieuw product direct meegenomen worden, maar dat begint al bij het ontwerp, dat aan de architectuur-richtlijnen van het bedrijf moet voldoen.

[Sissors]

Voor de duidelijkheid: Mijn post was vooral de andere kant van het plaatje te belichten, ik denk dat er voor beide opties dingen te zeggen zijn. Echter wat mijn primaire punt is: Ik durf te wedden als het bericht hier was geweest dat ipv security specialisten op elke afdeling te hebben Facebook besloten had ze te concentreren in één afdeling, dat de reacties erop ook negatief waren geweest, met behulp van de argumenten in mijn post. Op Facebook klagen is iets van een sport geworden op Tweakers imo.

[walteij]

Duidelijk!
Facebook (of eigenlijk de grote IT bedrijven) bashen is iets dat steeds populairder wordt (niet alleen op tweakers). Aan beide oplossingen zitten voor- en nadelen. Voor een bedrijf als Facebook (of Google, of Microsoft, of Apple, of welk ander bedrijf dan ook met > 5k medewerkers) is het alleen erg bevreemdend dat er geen C(I)SO (meer) is en ook geen fatsoenlijk dedicated security team.
Een dergelijk bedrijf heeft zoveel processen, richtlijnen, producten en plannen, dat je security niet als randzaak kunt bestempelen.

[Viince1]

En natuurlijk moet security bij een nieuw product direct meegenomen worden, maar dat begint al bij het ontwerp, dat aan de architectuur-richtlijnen van het bedrijf moet voldoen.

Dit werkt enkel in theorie.

Als je een dedicated security-team hebt, creëer je een beeld dat alleen dat team verantwoordelijk is voor security. Dat team wordt door andere teams altijd direct buiten spel gezet. Dat heeft met de houding van huidige-security teams te maken, die elk risico willen mitigeren/ontwijken/overdragen, en dan een project gigantisch vertragen.

Het security-team wordt daarom pas in de laatste weken aan boord gehaald. Die gaan dan terecht heel lastig doen (want er is nooit over security nagedacht). Vervolgens gaan de andere teams dan heel hard escaleren: "Deadlines worden niet gehaald door security!!!".

Dit komt bij een hoge manager/ondernemer te liggen. En vervolgens mag security hun verhaal doen, maar die gaan dan gewoon iedereen bang maken met risico's en FUD(Fear, uncertainty, doubt).
Helaas voor security, zijn managers/ondernemers veel meer geïnteresseerd in kansen dan in risico's. Bezwaren van security worden dan van tafel geveegd, product gaat live.
Als het product dan alsnog gehacked wordt? "Tja, we hebben toch een IT-security afdeling, die hebben lekker geslapen zeker."
Want dat is de echte waarde van je security team anno 2018, een zondebok!

Als je de security fanaten opneemt in de verschillende teams krijg je een veel betere structuur. Allereerst hoeft niet meer elke security man/vrouw overal wat vanaf te weten, maar kan hij zich focussen op security in de diensten die dat team levert.
(Voorbeeld, de security-man in het database team houdt zich bezig met database security, in plaats van code-security EN database-security EN linux security EN windows security).
Daarnaast heb je iemand in een team zitten die de security cultuur uitstraalt en hopelijk andere mensen enthousiasmeert.

Kan een teamleider dan een security concern van tafel vegen? Ja. Maar dan moet hij ook de verantwoordelijkheid dragen, er is geen security-team meer die hij de schuld kan geven als het fout gaat.
Dat dwingt een teamleider er toch wat beter over na te gaan denken.

Vaak blijft er dan nog wel een vorm van een security-team zitten, die zich bezig houdt met monitoring en hunten van verdacht gedrag, maar die houden zich niet meer bezig met projecten en nieuwe diensten.

Waarschijnlijk gaat iemand reageren hierop dat nu met de nieuwe AVG je een boete kan krijgen die gelijk staat aan 4% van je jaaromzet, maar er is geen capaciteit om de AVG te handhaven. Tenzij je een Facebook/Google bent, is de pakkans te verwaarlozen.

[Reactie gewijzigd door Viince1 op 26 juli 2024 21:07]

[RobbieB]

Idealiter heb je de kennis in ontwikkelingsteams zitten, maar in de praktijk blijkt dat specialistische kennis hiervoor noodzakelijk is en het aanbod security specialisten dusdanig laag is dat het lastig is om dit overal adequaat in te vullen... Nu zal dit iets zijn waar de FaceBooks en Googles van deze wereld mogelijk wat minder last van hebben, maar ik zie het bij de grote bedrijven in NL regelmatig terugkomen dat ze moeite hebben met het werven van de juiste mensen op dit gebied...

[Aaargh!]

met een dedicated security groep je dus iets krijgt waarbij achteraf die groep er ook nog naar moet kijken

Da's gewoon je process goed inrichten en eisen dat er iemand van security moet aftekenen op elk nieuw project.

, en dat dat een groep is wiens bezwaren dan snel worden weggewuifd.

Als je het goed inricht heeft de security groep juist de mogelijkheid andere afdelingen te overrulen. Je wilt het juist in een aparte afdeling omdat die dan zo onafhankelijk mogelijk kan opereren.

[teacup]

Zoals jij je het voorstelt is het helemaal afhankelijk van het vermogen van de geïsoleerde veiligheidsmedewerker om issues bij het afdelingshoofd neer te leggen (Local Hero mechanisme)

Het voordeel van een aparte afdeling is dat de rol, verantwoordelijkheden, taken maar ook het mandaat van die afdeling ingebed liggen in de organisatiestructuur. Dit biedt dus een krachtiger stem als het veiligheidsbelang tegen het belang van andere afdelingen in de organisatie ingaat. Eigenlijk zou het veiligheidsbelang een organisatiebelang moeten zijn en is het belang dus gedeeld door alle afdelingen. Bij Facebook is dat blijkbaar anders, dat het zich kan permitteren haar veiligheidsafdeling zo uit te kleden.

[Ome Ernst]

Ik vind het schokkend dat een bedrijf wat honderden miljarden waard is, kennenlijk niet zo veel waarde
hecht aan veiligheid, dat ze niet een groot team met specialisten hebben. En ik zou het een reden vinden voor de beurzen om dit keihard af te straffen.

[Nas T]

Ik neem aan dat je ook zelf actie hebt ondernomen en geen gebruik maakt van producten van Facebook, buiten Whatsapp om, waar je nauwelijks onder uit komt?
Wat mij betreft mag Facebook langzaamaan failliet gaan. Ze hebben al heel duidelijk hun ware aard/intenties laten zien en die zijn alles behalve zuiver.

[Ome Ernst]

Ik heb nog nooit een Facebook account gehad inderdaad. WA kom je helaas niet onderuit.

[Nas T]

Goed zo . Ik wil voorstellen om op Signal over te stappen en meldingen van WA uit te zetten en die maar eens per week te lezen. Heeft het haast: Signal. Anders blijf je maar op Whatsapp.

[Ome Ernst]

Je maakt een denkfout

"Signal is een versleutelde communicatieapplicatie voor Android en iOS."

Ik gebruik Windows Phone xD

[kozue]

Zolang de inkomsten niet terug lopen zul je hier niets van zien op beurzen. Die geven ook niets om beveiliging, alleen om geld.

[bbob]

Ze hechten nog minder waarde aan privacy dus moet je van dat andere ook niet echt versteld staan lijkt me.

[ShadyNetworker]

Voor bedrijven is security allen belangrijk als het aanpakken minder geld kost. In de meeste gevallen zitten er geen consequenties aan een laks of zelfs niet hebben van goede security processen.

[Rukapul]

Ondenkbaar inderdaad dat zo'n bedrijf geen chief security office(r) heeft.

Het zal impact hebben op effectiviteit en tevens minder aantrekkelijk maken om de juiste mensen aan te trekken.

Het biedt wel plausible deniability voor Mark Z.

[totaalgeenhard]

[...]
Dit zijn meestal ook echte vakidioten die gewoon helemaal de focus op security en het voorkomen van security breaches hebben.

En daarmee vormen die "vakidioten" juist een grote risico als je ze op een eiland zet.

Als deze medewerkers nu zijn/worden ondergebracht in andere afdelingen, zullen ze op die afdeling roepende in de woestijn worden.

Niet perse.

Zij zijn daar namelijk de enige met een echte focus op security.

Security is een onderdeel van elk proces, er is niemand die focus op alles kan hebben.
Bovendien heb je met business behoeften te maken, die "reden van bestaan" vormen, security op zichzelf kan dat nooit zijn.

Ook zullen ze zich met de reguliere werkzaamheden van de betreffende afdeling moeten gaan bezigen, waardoor de aandacht wordt weggehaald van security.

Niet perse.

Juist met de recente security 'lekken' (Cambridge Analytics en de vele verwijderde apps die veel te veel informatie verzamelden), zou je toch zeggen dat een dedicated team hier veel efficienter mee kan omgaan.

Cambridge Analytca is was geen security lek. Het was een business case en bewust keuze van Facebook omdat te faciliteren.

Ethische beslissingen worden niet door infosec medewerkers gemaakt....

[Jester-NL]

Het rotte (voor Facebook) is dat de club van Stamos een aantal ideeën had die ongeveer haaks stonden op de huidige manier van werken. Denk aan meer openheid over dat Cambridge Analytics-verhaal. Hoewel dat Facebook waarschijnlijk een heleboel positieve(re) pers bezorgt zou hebben dan de flack die ze er nu over hebben ontvangen, had het (waarschijnlijk) ook financiële consequenties gehad, en dat van een iets zwaarder kaliber dan laatst.

Bovendien... wie geeft er nou om veiligheid? Data, metadata en vrienden... DAAR verdien je aan. Niet aan zeikerige nerds. [/cynisme]

[Schuimpje]

Ik vraag me af of hij echt vrijwillig is opgestapt aangezien Stamos voorstander was van meer openheid...

[Iblies]

Ik vraag me af of hij niet zijn straatje aan het schoonvegen is.


Hij heeft voordat hij bij FB aan de slag ging een jaar gewerkt bij Yahoo en is daar ook vertrokken ivm onenigheid,
en daarvoor heeft die ook geen ervaring met het leiden van teams of afdelingen.


Als ik en optelsom maak zou oa CA de kans zijn geweest om de security uit te geen breiden,
maar het tegendeel is gebeurt.


Een heel onnatuurlijk reactie waarbij zijn eigen functioneren in deze functie wel van toegevoegde waarde was geweest.

[Robby517]

Als je een leidinggevende z'n team afbouw van 120 naar 3 man (naaste medewerkers, secretaresse,..) dan forceer je hem als bedrijf buiten zonder z'n contract te moeten verbreken.

[Tokidoki]

“Ook zou zijn team van oorspronkelijk 120 personen zijn teruggebracht naar 3.“

Oké, dus op 2.23 miljard gebruikers, petabytes aan data wil je 3 security medewerkers.

[litebyte]

Natuurlijk wil je dat. Hoe minder mensen van 'iets' afweten, hoe makkelijker het is om iets onder pet te houden/bij te sturen als iets 'fout' gaat. Dat fout gaan is overigens relatief.

Vergis je niet we hebben het hier over een bedrijf wat de grootste spyware wereldwijd legitiem kan uitkotsen over haar gebruikers (en niet gebruikers) met nog steeds gebruikmakend van het excuus, je bent akkoord gegaan met de gebruikersvoorwaarden.

[paalbasher]

Klinkt, ook een beetje als weggepest, als je team van 120 teruggebracht wordt naar 3.

[Robby517]

Personeel afbouwen en onderbrengen in andere afdelingen. Het lijkt me duidelijk hoe serieus Facebook echt is met hun aanpak omtrent security en privacy breaches.

[kozue]

Misschien wel goed dit. Facebook is sowieso al de beerput van het internet dus als die een keer flink gehacked worden kan het er alleen maar beter van worden. Laat die security lekken maar komen!

[litebyte]

Facebook is spyware. Het zou in haar huidige hoedanigheid allang verboden zijn mocht het bijv. niet uit VS/EUland komen (Rusland of China.)

[Anonymoussaurus]

Inderdaad.. Ik mag lijden dat Facebook een keer kopje onder gaat door de schijt die ze hebben aan hun gebruikers en privacy.

[Slavy]

Interessant gezien de jongens van Google zijn begonnen op Stanford University, daar staat overigens hun eerst Google server, heb deze zelf daar in levende lijve gezien. Grote universiteit, zal hij genoeg te doen hebben.

https://blog.nationalgeog...-a-new-kind-of-jump-rope/

[Sandor_Clegane]

Ik vond hem altijd leuk in Full House. Waar ging het mis?

[Quacka]

ik zat daar ook aan te denken.

[Sandor_Clegane]

Gelukkig ben ik niet de enige.

[Verwijderd]

^{Dat is John Stamos.}

[Shawty]

Waarom denk iedereen dat ze niks meer aan security doen?

Ze hebben al die werknemers in allerlei teams gestopt waar ze nog steeds security werk doen. Hier kunnen ze dan vanaf het begin van het development process al alles de goeie richting op sturen. Wat in mijn ogen een veel betere aanpak is dan: "kijk is wat voor toffe feature ons team heeft gemaakt, owja het security team had achteraf wat te zeiken dat de hele core van deze feature niet veilig is opgezet maar whatever, wanneer kan het live?!"

[kodak]

Er staat niet alleen dat Facebook geen vervanger heeft aangewezen. Er staat zelfs dat het geen vervanger gaat aanwijzen en er dus geen chief security officer bij Facebook zal bestaan.

Het is de vraag of dat van enige invloed gaat zijn op security bij Facebook als de laatste personen die de titel droegen blijkbaar al weinig invloed konden uitoefenen. Stamos heeft bij zowel Facebook als bij zijn vorige baan als SCO bij Yahoo niet bepaald een track record waarbij hij genoeg te zeggen had. En met zijn voorganger, de voormalig prosecutor Joe Sullivan, leek dat voor Facebook en later bij Uber ook niet te doen te zijn geweest om echt wat te doen aan beveiliging.

Functies die niet veel inhoud hebben maar wel een leuke titel voor bij het CV en een leuk salaris en bijkomende voordeeltjes kunnen beter opgedoekt worden. Maar beter zou zijn als bedrijven als Facebook security niet alleen zien als een marketingtool.

[mutley69]

De man pleitte voor openere info - en Zuckerberg en zussie-lief zijn tegen - is dat de juiste samenvatting?
Onze privacy is onbelangrijk voor Z - dus waarom gebruiken wij die rommel van hen nog? (instagram, whatsapp en facebook - ik blokkeer en filter dat allemaal weg via dns - u doet toch ook mee?).