Google gebruikt zelfontworpen hardware in servers en netwerken
Google maakt in servers en netwerken gebruik van zelfontworpen hardware om de apparatuur op hardwareniveau te identificeren en authenticeren, zo heeft de internetgigant zelf bekendgemaakt. Zowel de moederborden van de servers als netwerkapparatuur zijn zelf door Google ontworpen.
"We controleren de leveranciers en kiezen onze onderdelen met zorg uit. Tegelijkertijd werken we samen met leveranciers om de veiligheid van de onderdelen te auditen en valideren. We ontwerpen ook chips, waaronder een hardwarematige beveiligingschip, die op dit moment op server en randapparatuur wordt uitgerold. Deze chips laten ons de legitimiteit van Google-apparaten op hardwareniveau identificeren en authenticeren", aldus een document over de veiligheid van de Google-infrastructuur.
Verder legt Google in het document uit wat het doet om misbruik door het eigen personeel, de zogeheten insiders, tegen te gaan en laat het weten dat werknemers regelmatig doelwit van gerichte phishingaanvallen zijn. Zo zijn de eenmalige codes voor tweefactorauthenticatie die werknemers bij het inloggen moesten invoeren vervangen door een usb-sleutel. Volgens Google zou een tweede code bij het inloggen nog steeds via een phishingaanval zijn te bemachtigen, wat niet kan bij een usb-sleutel. Het usb-apparaat controleert daarnaast ook of de inlogpagina een echte Google-site en geen phishingpagina is.
Een ander onderwerp in het document is het verwijderen van gegevens. Google markeert dergelijke data als "te verwijderen" in plaats van de data meteen te verwijderen. Dit moet het onbedoeld verwijderen van gegevens, bijvoorbeeld door een bug of de gebruiker, voorkomen. Na te zijn aangemerkt om te worden verwijderd zegt Google de gegevens uiteindelijk wel te verwijderen. Als bijvoorbeeld een eindgebruiker zijn account verwijdert, worden alle Google-diensten geïnformeerd dat het account is verwijderd. Vervolgens plannen de diensten in kwestie wanneer ze de gegevens van de gebruiker zullen verwijderen.
met "server selects preferred cipher" en zich te onttrekken aan interne en externe doorzichtigheid,
wat men natuurlijk zal nastreven met meer "Wij van WC-eend rethoriek"
en via de nodige code bochtjes knijperij.
Als ik hier naar kijk ben ik nog niet echt onder de indruk van de veiligheidsgraad:
https://observatory.mozilla.org/analyze.html?host=www.google.com
en kijk eens hier wat hun zelfbouw oplevert aan resultaat: https://www.htbridge.com/ssl/?id=605ebf83188000069075567ca4f73abf430238b3b362486630c2bb53b6f3903d
Beschouw tevens dit: http://www.domxssscanner.com/scan?url=https%3A%2F%2Fwww.google.com
Hoofdactiviteit bij voorbeeld Google Analytics gebruikt document.location.protocol in de boilerplate t.b.v. tracking.
Je lijkt wel een Amerikaan, die kunnen ook geen kritiek verdragen op de eigen grote merken.
Als je ze aanvalt....vliegen ze gelijk op als de gebeten hond. "Hoe durf je wel niet?"....
Nou en...CloudFlare, GoDaddy, Afraid dot org, allemaal "top of the bill" diensten, niets op aan te merken, toch?
Best practices always & no curving the bends for profit....
Typisch het gedrag van fanboys en conformisten. Ga maar vast met een vlaggetje staan zwaaien.
"Google don't be evil", weet je nog? ...maar ja.. downward compatibility... verklaart het wel.
Ok, opvallend eist Google de transparantie slechts altijd van ene kant, van het product.
Waarom? Google legt de lat ook hoog voor anderen en meet websites af naar de veiligheidsstandaard ervan.
Vaak zie ik nog google analytics scripts op sites langskomen zonder gegenereerde SRI hashes.
Dit heeft te maken met de zogenaamde 'safe origin' regel en heeft niets van doen met backward compatibility.
Hoe lang duurde het bij sommige spelers tot 1024-bit RSA sleutels uiteindelijk werden uitgefaseed en SHA1,
waar drenst DROWn kwetsbaarheid nog door op servers door de gehele structuur.
Waar vormen complete monoculturen een grote bedreiging (zoals asp websites in mainland China bijv.)
Natuurlijk moeten we blij zijn met Google Safebrowsing en andere Google veiligheidsprojecten.
In de basis buitengewoon belangrijk, daar strijd ik geen woord aan af.
Het neemt echter niet weg dat men de veiligheid van de gehele infrastructuur zo graag eens opgekrikt zou zien.
Als je de situatie op het Wereld Wijde Web zou transponeren naar die van de autosnelweg bijvoorbeeld,
zouden bepaalde zaken die op het Internet worden geaccepteerd (vergelijk oude code dan met bijvoorbeeld met
gladde banden) in het verkeer compleet ondenkbaar zijn.
Voorbeeld een website met verouderde WordPress versie, met gebruikers enumeratie aan en directory listing enabled en nog de nodige af te serveren jQuery code en verlaten plug-in code, is in het verkeer te vergelijken met een auto die de dienst wegverkeer niet op de weg zou dulden.
Juist de grote spelers, als Google, waar we niet omheen kunnen en mogen, zouden een drijvende en dwingende factor vormen bij het eindelijk achter ons kunnen laten van zulke fundamentele veiligheidsgebreken, kwetsbaarheden en derhalve gevaren. Maar meestal is het geveeg met de spons van Blanus.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
