S3 Afl.107: Acht maanden om de boeven eruit te schoppen en je denkt dat dat GOED is? [Audio + tekst]

Klik en sleep op de onderstaande geluidsgolven om naar een willekeurig punt te gaan. Je kan ook luister direct op Soundcloud.

DOUG.  Patches in overvloed, gruwelijke therapiesessies en casestudy's in slechte cyberbeveiliging.

Dat alles, en meer, op de Naked Security-podcast.

[MUZIEK MODEM]

Welkom bij de podcast, allemaal.

Ik ben Doug Aamoth; hij is Paul Ducklin.

Paulus, hoe gaat het met je?

We hebben een grote show vandaag.

---

EEND.  Ja, laten we hopen dat we ze allemaal doorkomen, Doug!

---

DOUG.  Laten we ons best doen!

We beginnen natuurlijk met ons Tech History-segment...

..deze week, op 02 november 1815, werd George Boole geboren in Lincolnshire, Engeland.

Paul, WAAR of ONWAAR: Boole heeft verschillende geweldige bijdragen geleverd aan wiskunde, het informatietijdperk en daarbuiten?

ALS je enige context hebt, DAN zal ik er graag naar luisteren ANDERS kunnen we verder gaan.

---

EEND.  Nou, Doug, laat me dan zeggen, want ik heb iets voorbereid dat ik kan voorlezen...

...e schreef een zeer beroemd wetenschappelijk werk met de titel, en je zult zien waarom ik het opschreef [GELACHT]:

Een onderzoek naar de wetten van het denken waarop de wiskundige theorieën van logica en waarschijnlijkheid zijn gebaseerd

---

DOUG.  Rolt zo van de tong!

---

EEND.  Hij zat vlak achter de symbolische logica en beïnvloedde Augustus De Morgan. (Mensen kennen misschien de wetten van De Morgan.)

En DeMorgan was de wiskundeleraar van Ada Lovelace.

Ze nam deze grootse ideeën van symbolische logica en dacht: "Hé, als we programmeerbare computers krijgen, gaat dit de wereld veranderen!"

En ze had gelijk! [LACHT]

---

DOUG.  Uitstekend.

Heel erg bedankt, George Boole, moge je rusten in vrede.

Paul, we hebben deze week een heleboel updates om over te praten, dus als je ons op de hoogte zou kunnen houden van al deze updates...

Laten we beginnen met OpenSSL:

Het verhaal van de OpenSSL-beveiligingsupdate - hoe weet u wat er moet worden gerepareerd?

---

EEND.  Ja, het is degene waar iedereen op heeft gewacht.

OpenSSL doet precies het tegenovergestelde van Apple, die helemaal niets zegt totdat de updates arriveren. [GELACH]

OpenSSL zegt: "Hé, we gaan updates uitbrengen op XYZ-datum, dus misschien wil je je voorbereiden. En de slechtste update in deze batch zal het niveau hebben ... "

En deze keer schreven ze CRITICAL in hoofdletters.

Dat gebeurt niet vaak met OpenSSL, en omdat het een cryptografische bibliotheek is, denkt iedereen telkens wanneer ze zeggen: "Oh, golly, er is een KRITIEK-niveau gat", terug aan... wat was het, 2014?

"Oh nee, het wordt als... zo slecht als Heartbleed helemaal opnieuw', want het zou kunnen zijn, voor zover je weet:

Anatomie van een datalekbug - de OpenSSL "Heartbleed" bufferoverloop

Dus we hadden een week van wachten en piekeren en "Wat gaan we doen?"

En op 01 november 2022, de updates eigenlijk gevallen.

Laten we beginnen met de cijfers: OpenSSL 1.1.1 gaat naar versie S-for-Sierra, want die gebruikt letters om de afzonderlijke updates aan te duiden.

En OpenSSL 3.0 gaat naar 3.0.7:

OpenSSL-patches zijn uit - KRITISCHE bug gedowngraded naar HOOG, maar patch toch!

Nu, de kritieke update... eigenlijk bleek dat ze bij het onderzoeken van de eerste update een tweede gerelateerde update vonden, dus er zijn er eigenlijk twee... die zijn alleen van toepassing op OpenSSL 3.0, niet op 1.1.1.

Dus ik zeg niet: "Pas niet als je 1.1.1 hebt", maar het is minder dringend, zou je kunnen zeggen.

En de zilveren voering is dat het CRITICAL-niveau, allemaal in hoofdletters, is gedegradeerd tot HOOG, omdat men van mening is dat de bugs, die betrekking hebben op de validatie van TLS-certificaten, vrijwel zeker kunnen worden gebruikt voor denial-of-service, maar waarschijnlijk zijn het zal heel moeilijk zijn om exploits voor het uitvoeren van externe code te worden.

Er zijn buffer overflows, maar die zijn een beetje beperkt.

Er zijn twee bugs... laat me gewoon de cijfers geven, zodat je ernaar kunt verwijzen.

Er is CVE 2022-3602, waar je vier bytes van de stapel kunt overschrijven: slechts vier bytes, een half 64-bits adres.

Hoewel u alles kunt schrijven wat u wilt, is de hoeveelheid schade die u kunt aanrichten waarschijnlijk, maar niet noodzakelijk, beperkt tot denial-of-service.

En de andere bug heet CVE-2022-3786, en in die ene kun je zo'n grote stack overflow doen als je wilt, blijkbaar [GELACHT]... dit is best grappig.

Maar je kunt alleen punten schrijven, hexadecimaal 0x2E in ASCII.

Dus hoewel je de stapel volledig kunt beschadigen, is er een limiet aan hoe creatief je kunt zijn in elke exploit van externe code die je probeert te bedenken.

De andere zilveren voering is dat, in het algemeen... niet in alle gevallen, maar in de meeste gevallen, vooral voor zaken als webservers, waar mensen OpenSSL kunnen gebruiken en in paniek raken: "Wat als mensen geheimen van onze webserver kunnen stelen zoals ze konden in de dagen van Heartbleed?”

De meeste webservers vragen klanten die verbinding maken, bezoekers, niet om een ​​certificaat te verstrekken om zichzelf te valideren.

Het maakt ze niet uit; iedereen is welkom om te komen kijken.

Maar de server stuurt de client een certificaat zodat de client, als hij dat wil, kan bepalen: "Hé, ik ben echt op bezoek bij Sophos", of Microsoft, of welke site ik ook denk dat het is.

Het lijkt er dus op dat de meest waarschijnlijke manier waarop dit misbruikt zal worden, is dat malafide servers clients laten crashen, in plaats van andersom.

En ik denk dat je het ermee eens zult zijn dat servers die clients laten crashen slecht zijn, en dat je er slechte dingen mee kunt doen: je zou bijvoorbeeld kunnen voorkomen dat iemand updates krijgt, omdat het steeds opnieuw en opnieuw en opnieuw faalt.

Maar het lijkt niet zo waarschijnlijk dat deze bug misbruikt kan worden door een willekeurige persoon op internet om al uw webservers te scannen en ze naar believen te laten crashen.

Ik denk niet dat dat waarschijnlijk is.

---

DOUG.  We hebben hier een opmerking van een lezer: “Ik heb geen idee wat ik moet updaten. Chrome Firefox-vensters. Helpen?"

Je weet maar nooit.., er zijn al die verschillende smaken SSL.

---

EEND.  Het goede nieuws is dat, hoewel sommige Microsoft-producten hun eigen exemplaar van OpenSSL gebruiken en bevatten, ik begrijp dat noch Chrome, Firefox noch Edge het gebruiken.

Dus ik denk dat het antwoord op de vraag is dat, hoewel je het nooit weet, vanuit een puur Windows-, Chrome-, Firefox-, Edge-perspectief, ik denk dat je je hier geen zorgen over hoeft te maken.

Het is als je servers gebruikt, met name Linux-servers, waar je Linux-distro wordt geleverd met een of beide versies van OpenSSL, of als je specifieke Windows-producten hebt geïnstalleerd die toevallig samen met OpenSSL komen ... en het product zal normaal gesproken vertellen jij als dat zo is.

Of u kunt op zoek gaan naar libcrypto*.dll of libssl*.dll.

En een goed voorbeeld daarvan, Doug, is Nmap, de zeer bekende en zeer nuttige netwerkscantool die veel Red Teams gebruiken.

Dat programma wordt niet alleen geleverd met OpenSSL 1.1.1, samen met zichzelf verpakt, maar ook met OpenSSL 3.0, voor zover ik kan zien.

En ze zijn momenteel allebei, tenminste toen ik gisteravond keek, verouderd.

Ik zou dit niet moeten zeggen, maar...

---

DOUG.  [INTERRPTEN, LACHEN] Als ik een Blue Team-lid ben...

---

EEND.  Precies! PRECIES! [LACHEND]

Als je een Blue Teamer bent die je netwerk probeert te beschermen en je denkt: "Oh, het Rode Team gaat als een gek scannen, en ze houden van hun Nmap", heb je een vechtkans om te counteren!

[LUID GElach]

---

DOUG.  Oké, we hebben nog wat andere updates om over te praten: Chrome-, Apple- en SHA-3-updates.

Laten we beginnen met Chrome, dat een urgente had zero-day oplossing, en ze hebben het vrij snel gepatcht ...

... maar ze waren niet super duidelijk over wat er aan de hand was:

Chrome heeft een dringende zero-day-oplossing - update nu!

---

EEND.  Ik weet niet of drie advocaten deze woorden hebben geschreven, elk met een extra niveau van indirectheid, maar je weet dat Google een rare manier heeft om over zero-days te praten, net als Apple, waar ze de *letterlijke* waarheid vertellen:

Google is op de hoogte van berichten dat er een exploit voor deze kwetsbaarheid, CVE-2022-3723, in het wild bestaat.

Dat is ongeveer twee niveaus van indirectheid verwijderd van te zeggen: "Het is een 0-dag, mensen!"

In plaats daarvan is het: "Iemand heeft een rapport geschreven waarin staat dat het bestaat, en toen vertelden ze ons over het rapport."

Ik denk dat we het er allemaal over eens zijn dat het moet worden gepatcht, en Google moet het daarmee eens zijn, omdat...

... om eerlijk te zijn, hebben ze het bijna onmiddellijk gerepareerd.

Ironisch genoeg hebben ze een grote beveiligingsoplossing gedaan op de dag dat deze bug werd gemeld, wat volgens mij 25 oktober 2022 was, en Google had het binnen wat, drie dagen opgelost?

Twee dagen eigenlijk.

En Microsoft heeft zelf een zeer duidelijk rapport uitgebracht over hun Edge-release-opmerkingen: op 31 oktober 2022 brengen ze een update uit en daarin staat expliciet dat het de bug verhelpt die is gemeld door Google en het Chromium-team.

---

DOUG.  Oke, heel goed.

Ik ben terughoudend om dit naar voren te brengen, maar kunnen we nu veilig over Apple praten?

Hebben we nog meer duidelijkheid op deze Apple zero-day?

Updates voor het zero-day-updateverhaal van Apple - iPhone- en iPad-gebruikers lezen dit!

---

EEND.  Welnu, de kritieke deal hier is toen we schreven over de update met iOS 16.1 en iPadOS 16, wat uiteindelijk iPadOS 16.1 bleek te zijn ...

…mensen vragen ons begrijpelijkerwijs: “Hoe zit het met iOS 15.7? Moet ik naar iOS 16 gaan als ik kan? Of komt er een 15.7.1? Of hebben ze de ondersteuning voor iOS 15 helemaal laten vallen, game over?”

En ziedaar, zoals het geluk zou hebben (ik denk dat het de dag nadat we de podcast van vorige week [LAUGHS] hadden opgenomen), stuurden ze plotseling een melding met de tekst: "Hé, iOS 15.7.1 is uit en het herstelt precies dezelfde gaten die iOS 16.1 en iPadOS 16/16.1 deden.”

Dus nu weten we dat als je iOS of iPadOS gebruikt, je *kan* bij versie 15 blijven als je wilt, en er is een 15.7.1 die je nodig hebt.

Maar als je een oudere telefoon hebt die iOS 16 niet ondersteunt, dan moet je zeker 15.7.1 hebben, want dat is je enige manier om de zero-day op te lossen.

En we lijken er zelf ook van overtuigd te zijn dat iOS en iPadOS nu beide dezelfde code hebben, met dezelfde oplossingen, en ze staan ​​allebei op 16.1, wat de beveiligingsbulletins ook hebben gesuggereerd.

---

DOUG.  Oké, goed gedaan, iedereen, we hebben het gedaan.

Geweldig werk... duurde een paar dagen, maar goed!

En last but zeker not least in onze update stories…

… het voelt alsof we erover blijven praten en proberen het juiste te doen met cryptografie, maar onze inspanningen worden niet altijd beloond.

Dus, in dit geval, deze nieuwe SHA-3-fout?

SHA-3 code-uitvoeringsfout gepatcht in PHP - controleer uw versie!

---

EEND.  Ja, dit is een beetje anders dan de OpenSSL-bugs waar we het net over hadden, want in dit geval zit het probleem eigenlijk in het SHA-3 cryptografische algoritme zelf... in een implementatie die bekend staat als XKCP, dat is X-ray, Kilo, Charlie , opa.

En dat is, zo u wilt, de referentie-implementatie door het team dat SHA-3 heeft uitgevonden, dat oorspronkelijk Keccak heette [spreek uit als 'ketchak', zoals 'ketchup'].

Het werd ongeveer tien jaar geleden goedgekeurd en ze besloten: "Nou, we zullen een verzameling gestandaardiseerde algoritmen schrijven voor alle cryptografische dingen die we doen, inclusief SHA-3, die mensen kunnen gebruiken als ze dat willen."

Helaas lijkt het erop dat hun programmering niet zo zorgvuldig en robuust was als hun oorspronkelijke cryptografische ontwerp, omdat ze dezelfde soort bug hebben gemaakt waar Chester en ik een paar maanden geleden over spraken in een product genaamd NetUSB:

Thuisrouters met NetUSB-ondersteuning kunnen een kritiek kernelgat hebben

Dus in de code probeerden ze te controleren: "Vraag je ons om te veel gegevens te hashen?"

En de theoretische limiet was 4 GB minus één byte, behalve dat ze vergaten dat er aan het eind 200 reservebytes zouden moeten zijn.

Ze moesten dus controleren of je meer dan 4 GB minus één bytes *min 200 bytes* probeerde te hashen.

Maar dat deden ze niet, en dat veroorzaakte een integer-overflow, wat een buffer-overflow kon veroorzaken, wat een denial-of-service kon veroorzaken.

Of, in het ergste geval, een mogelijke uitvoering van externe code.

Of gewoon hash-waarden die verkeerd zijn berekend, wat altijd in tranen zal eindigen, omdat je je kunt voorstellen dat een goed bestand uiteindelijk als slecht wordt veroordeeld, of dat een slecht bestand ten onrechte als goed wordt herkend.

---

DOUG.  Dus als dit een referentie-implementatie is, is dit dan iets om op grote schaal over in paniek te raken, of is het meer ingeperkt?

---

EEND.  Ik denk dat het meer ingeperkt is, omdat de meeste producten, met name OpenSSL, gelukkig niet de XKCP-implementatie gebruiken.

Maar PHP *gebruikt* de XKCP-code, dus je wilt er zeker van zijn dat je PHP 8.0.25 of hoger of PHP 8.1.12 of hoger hebt.

En de andere verwarrende is Python.

Nu is Python 3.11, de nieuwste, verschoven naar een gloednieuwe implementatie van SHA-3, die niet deze is, dus dat is niet kwetsbaar.

Python 3.9 en 3.10 ... sommige builds gebruiken OpenSSL en sommige gebruiken de XKCP-implementatie.

En we hebben wat code in ons artikel, wat Python-code, die je kunt gebruiken om te bepalen welke versie je Python-implementatie gebruikt.

Het maakt wel een verschil: men kan betrouwbaar worden gemaakt om te crashen; de ander kan dat niet.

En Python 3.8 en eerder heeft blijkbaar deze XKCP-code erin.

Dus je zult ofwel mitigaties in je eigen code willen plaatsen om de bufferlengte zelf correct uit te voeren, of om de nodige updates toe te passen wanneer ze uitkomen.

---

DOUG.  Oké, heel goed, we houden dat in de gaten.

En nu gaan we de show afronden met twee echt opbeurende verhalen, te beginnen met wat er gebeurt als de zeer persoonlijke en zeer persoonlijke inhoud van duizenden psychotherapiesessies online gelekt...

Verdachte afpersing psychotherapie: arrestatiebevel uitgevaardigd

---

EEND.  Het achtergrondverhaal is wat nu een beruchte en in feite failliete psychotherapiekliniek is.

Ze hadden een datalek, geloof ik, in 2018 en nog een in 2019.

En het bleek dat deze intieme sessies die mensen hadden gehad met hun psychotherapeuten, waar ze hun diepste en vermoedelijk soms donkerste geheimen onthulden, en wat ze dachten over hun vrienden en hun familie...

... al deze dingen die zo persoonlijk zijn dat je hoopt dat het helemaal niet wordt opgenomen, maar gewoon wordt beluisterd en de basis wordt gedestilleerd.

Maar blijkbaar zouden de therapeuten gedetailleerde aantekeningen typen en ze dan bewaren voor later.

Nou, misschien is dat oké als ze ze goed gaan bewaren.

Maar op een gegeven moment, denk ik, hadden ze de "rush naar de cloud".

Deze dingen kwamen beschikbaar op internet en er zou een soort ueberaccount zijn geweest waarbij iedereen overal bij kon als ze het wachtwoord kenden.

En blijkbaar was het een standaard.

Oh lieverd, hoe kunnen mensen dit nog doen?

---

DOUG.  Oef!

---

EEND.  Dus iedereen kon binnenkomen, en iemand deed het.

En het bedrijf leek er niet echt veel aan te doen, voor zover ik weet, en het werd niet bekendgemaakt of gerapporteerd ...

...want als ze snel hadden gehandeld, had de politie misschien eerder kunnen optreden en dit hele ding op tijd kunnen afsluiten.

Maar het kwam blijkbaar pas in oktober 2020 in de was, toen de kwestie van de inbreuk niet langer kon worden ontkend.

Omdat iemand die de gegevens had verkregen, ofwel de oorspronkelijke indringer, ofwel iemand die ze online had gekocht, begon te chanteren ermee.

En blijkbaar probeerden ze het bedrijf eerst te chanteren door te zeggen: "Betaal ons" ... Ik denk dat het bedrag ergens rond een half miljoen euro lag.

"Betaal ons dit forfaitaire bedrag in bitcoins en we zorgen ervoor dat de gegevens verdwijnen."

Maar, gedwarsboomd door het bedrijf, besloot de persoon met de gegevens: "Ik weet wat, ik ga elke persoon van de tienduizenden in de database afzonderlijk chanteren."

---

DOUG.  Ach jongen...

---

EEND.  Dus begonnen ze e-mails te sturen met de tekst: "Hé, betaal me zelf € 200, en ik zal ervoor zorgen dat je gegevens niet openbaar worden gemaakt."

Hoe dan ook, het lijkt erop dat de gegevens niet zijn vrijgegeven ... en in een poging om de zilveren voering hierin te vinden, Doug: [A] de Finse autoriteiten hebben nu een arrestatiebevel uitgevaardigd, en [B] ze gaan achter de CEO van het voormalige bedrijf (zoals ik al zei, het is nu failliet), en zei dat hoewel het bedrijf het slachtoffer was van een misdaad, het bedrijf zelf zo ver onder de maat was in de manier waarop het met de inbreuk omging dat het een soort sanctie moest krijgen.

Ze hebben de inbreuk niet gemeld toen het een groot verschil had kunnen maken, en ze deden gewoon, gezien de aard van de gegevens waarvan ze weten dat ze ze bewaren... alles te slordig.

En dit is niet alleen: "Oh, je zou een regelgevende boete kunnen krijgen."

Blijkbaar kan hij een gevangenisstraf van maximaal twaalf maanden krijgen.

---

DOUG.  Oké, dat is iets!

Maar om niet achter te blijven, we hebben een casestudy over onbekwaamheid op het gebied van cyberbeveiliging en een heel, heel slechte reactie na de inbreuk met dit "Zie Tickets" ding:

Online ticketingbedrijf "See" voor 2.5 jaar geplaagd door aanvallers

---

EEND.  Ja, dit is een heel groot ticketingbedrijf... Dat is "See", SEE, niet "C" zoals in de programmeertaal.

[KREEMEND] Dit lijkt ook zo'n komedie van fouten, Doug...

---

DOUG.  Het is echt adembenemend.

25 juni 2019... op deze datum denken we dat cybercriminelen malware voor het stelen van gegevens hadden geïmplanteerd op de afrekenpagina's van het bedrijf.

Het is dus niet zo dat mensen worden gephishing of misleid, want toen je ging uitchecken, konden je gegevens zijn overgeheveld.

---

EEND.  Dus dit is "malware op de website"?

---

DOUG.  Ja.

---

EEND.  Dat is behoorlijk nauw verbonden met uw transactie, in realtime!

---

DOUG.  De gebruikelijke verdachten, zoals naam, adres, postcode, maar dan je creditcardnummer...

... dus je zegt: "OK, je hebt mijn nummer, maar hebben ze ook ...?"

En ja, ze hebben je vervaldatum en ze hebben je CVV-nummer, het kleine driecijferige nummer dat je typt om er zeker van te zijn dat je legitiem bent met je creditcard.

---

EEND.  Ja, want het is niet de bedoeling dat je dat opslaat nadat je de transactie hebt voltooid...

---

DOUG.  Nee meneer!

---

EEND.  ...maar je hebt het in het geheugen *terwijl je de transactie doet*, uit noodzaak.

---

DOUG.  En toen, bijna twee jaar later, in april 2021 (twee jaar later!), werd See Tickets gewaarschuwd voor activiteit die op mogelijke ongeautoriseerde toegang wees, [IRONIC] en ze kwamen in actie.

---

EEND.  Oh, dat is zo SHEIN-schending waar we het een paar weken geleden over hadden, nietwaar?

Modemerk SHEIN krijgt boete van $ 1.9 miljoen voor liegen over datalek

Ze kwamen erachter van iemand anders... de creditcardmaatschappij zei: "Weet je wat, er zijn een heleboel onbetrouwbare transacties die naar jou lijken terug te gaan."

---

DOUG.  Ze starten een onderzoek.

Maar ze sluiten niet echt alle dingen af ​​die gaande zijn tot [DRAMATISCHE PAUZE] januari 2022!

---

EEND.  Acht en een halve maand later, nietwaar?

---

DOUG.  Ja!

---

EEND.  Dus dat was hun reactie op de bedreiging?

Ze hadden een forensisch team van een derde partij, ze hadden alle experts erbij, en meer dan *acht maanden* later zeiden ze: "Hé, raad eens jongens, we denken dat we de boeven er nu uit hebben geschopt"?

---

DOUG.  Vervolgens zeiden ze in oktober 2022: "We weten niet zeker of uw informatie is aangetast", maar uiteindelijk brachten ze klanten op de hoogte.

---

EEND.  Dus in plaats van te zeggen: "De boeven hadden malware op de server die tot doel had ieders gegevens te stelen, en we kunnen niet zeggen of ze succesvol waren of niet", met andere woorden: "We waren hier zo slecht in dat we het kunnen' niet eens vertellen hoe goed de boeven waren "...

...ze zeiden eigenlijk: "Oh, maak je geen zorgen, maak je geen zorgen, we konden niet bewijzen dat je gegevens waren gestolen, dus misschien was dat niet zo"?

---

DOUG.  "Dit ding dat al twee en een half jaar onder onze neus aan de gang is ... we weten het gewoon niet zeker."

OK, dus de e-mail die See Tickets naar hun klanten stuurt, bevat wat advies, maar het is eigenlijk niet echt advies dat van toepassing is op deze specifieke situatie ... [GELUID VERSLAGD] wat ironisch en vreselijk was, maar een beetje grappig.

---

EEND.  Ja.

Hoewel ik het eens ben met hun advies, en het is zeker de moeite waard om rekening mee te houden, namelijk: controleer altijd regelmatig uw financiële overzichten en pas op voor phishing-e-mails die u proberen te misleiden om uw persoonlijke gegevens te overhandigen...

...je denkt dat ze daar misschien een beetje een mea culpa in hebben gestopt, en hebben uitgelegd wat *ze* in de toekomst zouden gaan doen om te voorkomen wat *deed* gebeurde, wat geen van beide dingen had kunnen voorkomen, omdat het controleren van je verklaringen laat je pas zien dat je bent geschonden nadat het is gebeurd, en in dit geval was er geen phishing.

---

DOUG.  Dus dat roept een goede vraag op.

Degene die een lezer naar voren brengt ... en onze opmerking hier over deze kleine ophef is dat Naked Security-lezer Lawrence eerlijk vraagt: "Ik dacht dat PCI-compliance waarborgen vereiste voor al deze dingen. Zijn ze nooit gecontroleerd?”

---

EEND.  Ik weet het antwoord op die vraag niet...

Maar zelfs als ze compliant waren en werden gecontroleerd op naleving, betekent dat niet dat ze de dag nadat de nalevingscontrole was uitgevoerd, geen malware-infectie konden hebben opgelopen.

De nalevingscontrole omvat niet een volledige audit van absoluut alles op het netwerk.

Mijn analogie, waar mensen in het VK bekend mee zullen zijn, is dat als je een auto in het VK hebt, deze een jaarlijkse veiligheidscontrole moet ondergaan.

En het is heel duidelijk, als je een test doorstaat, dat *dit geen bewijs is dat de auto rijklaar is*.

Het heeft de wettelijke tests doorstaan, die de voor de hand liggende dingen testen dat als je het niet goed hebt gedaan, je auto * gevaarlijk * onveilig is en niet op de weg zou moeten zijn, zoals "remmen werken niet", "één koplamp is uit”, dat soort dingen.

Toen PCI DSS voor het eerst een ding werd, bekritiseerden veel mensen het en zeiden: "Oh man, het is te weinig, te laat."

En het antwoord was: "Nou, je moet ergens beginnen."

Het is dus heel goed mogelijk dat ze het PCI DSS-vinkje van goedkeuring hadden, maar toch werden geschonden.

En toen merkten ze het gewoon niet... en toen reageerden ze niet erg snel... en dan stuurden ze ook geen erg zinvolle e-mail naar hun klanten.

Mijn persoonlijke mening is dat als ik een klant van hen was, en ik zou zo'n e-mail ontvangen, gezien de tijdsduur waarin dit zich had afgespeeld, ik dat bijna nonchalance zou vinden.

En ik denk niet dat ik het meest tevreden zou zijn!

---

DOUG.  Goed, en ik ben het met je eens.

We houden dat in de gaten, het onderzoek loopt natuurlijk nog.

En heel erg bedankt, Lawrence, voor het insturen van die opmerking.

Als je een interessant verhaal, opmerking of vraag hebt die je wilt indienen, lezen we die graag in de podcast.

U kunt een e-mail sturen naar tips@sophos.com, of u kunt reageren op een van onze artikelen, of u kunt ons bereiken op social: @NakedSecurity.

Dat is onze show voor vandaag; heel erg bedankt voor het luisteren.

Voor Paul Ducklin, ik ben Doug Aamoth, ik herinner je eraan om de volgende keer...

---

BEIDE.  Blijf veilig!

[MUZIEK MODEM]