Hoofdcategorieën
Device Settings

Foutieve McAfee-update gevolg van gebrekkige testprocedure

Door Joost Schellevis, vrijdag 23 april 2010 15:38, views: 23.470

Volgens McAfee is de foutieve virusupdate van woensdag, die veel problemen heeft veroorzaakt, het gevolg van een 'wijziging' in het testprotocol. Een uitgelekt document wijst erop dat de update niet op Windows XP met SP3 is getest.

Afgelopen woensdag werd bekend dat McAfee een foutieve virusupdate heeft verspreid. Deze had tot gevolg dat het Windows-systeembestand svchost.exe als virus werd aangemerkt. De 'false positive' zorgde voor veel problemen; getroffen computers kregen BSOD's of bleven eindeloos herstarten. Vooral veel bedrijven zouden hinder hebben ondervonden.

In een blogposting biedt het antivirusbedrijf zijn excuses aan. Ook legt het bedrijf uit hoe de foutieve virusupdate zou zijn verspreid. Door een 'wijziging' in de testprocedure zou de update door de kwaliteitsbewaking zijn gekomen. McAfee licht niet toe wat deze wijziging inhoudt, maar volgens ZDNet, dat zich op een uitgelekt document baseert, was de test simpelweg niet compleet. Zo zou de update niet zijn getest voor systemen met Windows XP, Service Pack 3 en versie 8.7 van McAfee's zakelijke virusscanner.

Dit strookt met een faq op de site van McAfee, die meldt dat alleen systemen met Windows XP SP3 en bepaalde versies van het systeembestand last van het probleem hadden. McAfee heeft aangegeven de testprotocollen te verbeteren en een whitelist met essentiële systeembestanden op te zetten om false positives in de toekomst te voorkomen. Gebruikers met problemen kunnen al sinds woensdag voor een oplossing terecht op de site van McAfee.

Volgende 16:18 LG's eerste Windows Phone 7-toestel heet C900
Vorige 15:07 Google in Duitsland onder vuur over in kaart brengen wifi-netwerken
Advertentie

Reacties

«  1  2  3  »

Whitelisten van deze bestanden is niet handig omdat dat juist er voor zorgt dat deze bestanden bijzonder interessant worden om te infecteren.

Is het niet zo, dat de whitelists ook de hashes van bestanden bevatten, zodat een gewijzigd windowsbestand er zo uitgehaald kan worden? ...

Technisch gezien is het mogelijk om een 2e bestand te maken dat dezelfde hash krijgt als het eerste bestand. Dit is afhankelijk van de gebruikte hashmethode wel vrij lastig, maar zeker niet ondenkbaar.

Maar om een bestand te produceren dat dezelfde hash heeft, uitvoerbaar is, en ook nog eens doet wat jij wil, is (bijna) onmogelijk.

Je kunt bij executables naar mijn weten gewoon extra data achter het bestand aanplakken. Misschien ingewikkeld en tijdrovend, maar als je virus/ trojan daardoor ongezien blijft, zeker de moeite waard lijkt me.

Dat kan eenvoudig maar dan is de hash weer anders zoals compufreak88 (nmi duidelijk) aangeeft

Misschien weet je niet precies wat een hash is, maar als er gebruikt wordt van hashes om bestanden te identificeren op basis van hun authenticiteit, is dit niet mogelijk.

Een hash van een bestand is een korte string die door een algoritme gemaakt is, gebaseerd op de inhoud van het bestand. Deze hash is onomkeerbaar (als jij een hash hebt kun je nooit terug naar het bestand), en nagenoeg uniek voor elk bestand. Er bestaan wel dezelfde hashes voor verschillende inputstrings (botsingen), maar deze zijn te verwaarlozen.

Als bestand 1 hash 5ter80f8349pdfj90hdf heeft, en jij zet er *HAX CODE VIRUS* achter, zal het bestand een andere hash waarde krijgen. Vervolgens weer MCAffee dat er met het bestand gerotzooid is, en dat het niet meer te vertrouwens is :)

Hopelijk begrijp je het nu (beter) :)

Hij bedoeld dat wanneer je bepaalde data achterin het virusbestand toevoegt de hash hetzelfde kan zijn. Met een goed hash algoritme kan een bestand met een willekeurige inhoud met toevoegingen elke mogelijke hash genereren. Let wel: het is technisch mogelijk maar praktisch ondoenbaar natuurlijk.

Extra data er achteraan plakken kan toch wel met een checksum?

Hash werkt idd via algoritme, dat word al een stuk lastiger.. :P

Als er niet gekeken wordt naar de grootte van het bestand, maar puur naar de hash, dan is het bij bijv. md5 niet zo moeilijk om een bestand te maken dat precies dezelfde hash heeft.

De fix daarop is dan ook om de grootte van het bestand ook te controlen.

Of je houdt zowel een MD5, als een SHA1 checksum van de bestanden bij.

De kans dat beide checksums op dezelfde values bij dezelfde input dezelfde collisions hebben is nihil.

@brama
Ok, succes, zonder dat ik je de grootte van het bronbestand vertel, want daar word niet naar gekeken in jou theorie, kan jij dit ontcijferen:

eb69786bce860c78e182d7b8fd270986

Tis een MD5 hash, dus succes, jij vind het kennelijk niet zo moeilijk.
Het gaat ten slotte om de exacte gegevens die tot die hash gekomen zijn, NIET de hash zelf. Maar zo werkt het simpelweg niet.

Het doel van de MD5 hash is om te kijken of er geknoeid is met een bestand.
Als je dat wilt neppen zodat je virusje dezelfde hash heeft, dan moet je HEEL VEEL willekeurige combinaties van nutteloze data er in stoppen om ooit tot diezelfde hash te komen.

Als jij het niet zo moeilijk vind, vertel me dan maar eens met welke text jij deze hash zelf hebt nagemaakt:

"eb69786bce860c78e182d7b8fd270986"


On-Topic:
Wat een goede tip is voor macafee:
Die whitelist uitrusten met een download progje die de system32 bestanden kan downloaden wanneer ze WEL geinfecteerd zijn.

[Reactie gewijzigd door Yezpahr op zaterdag 24 april 2010 10:38]


@Yezpahr:

http://www.mscs.dal.ca/~selinger/md5collision/

Hier doen ze precies wat jij vraagt, compleet met een voorbeeld van zo'n 'geforceerde' MD5 collision.

Ze maken zelfs twee executables met dezelfde MD5 hash, maar met duidelijk andere functionaliteit.

[Reactie gewijzigd door tofus op zaterdag 24 april 2010 14:45]


@ Foxl: Je kan daar natuurlijk makkelijk op controleren door hash+bestandsgrote te controleren zoals bij mijn weten ook altijd gedaan wordt, en die combinatie is dus onmogelijk te foppen.

Yeah, totdat MS een update uitbrengt voor je OS en je virus scanner nog niet is geupdate, worden de betreffende bestanden nog gezien als virus en heb je als nog een niet werkende computer.

Yeah, totdat MS een update uitbrengt voor je OS en je virus scanner nog niet is geupdate, worden de betreffende bestanden nog gezien als virus en heb je als nog een niet werkende computer.
Het is niet zo dat bestanden die niet op de whitelist staan automatisch als virus worden gezien. Het is een extra beveiliging om problemen zoals nu spelen te voorkomen.

De mogelijkheid dat er een fout in de virusdefinities zit, dat deze fout ervoor zorgt dat een systeembestand wordt verwijdert en dat dit systeembestand door een update nog niet op de lijst stond lijkt me tamelijk klein.

[Reactie gewijzigd door doeternietoe op vrijdag 23 april 2010 19:00]


Maar kun je ook:
- jouw virus-code toevoegen,
- de hash hetzelfde houden (dit kost meestal veel ruimte!)
- en de grootte van het bestand hetzelfde houden?
Als je hash+size checkt dan wordt het extreem moeilijk om nog met dat bestand te rotzooien.
Bestaande code eruit slopen, om jezelf wat "werkruimte" te geven, is immers geen optie: een paar kleine functies eruit slopen betekent dat je alle interne verwijzingen (pointers en entry points en dergelijke) aan moet passen; verre van triviaal. En ik waag te betwijlfen of je een groot, aaneengesloten blok kunt vinden dat weggooid kan worden (denk eraan dat we het over een essentieel systeembestand hebben) zonder dat het geheel zo onbruikbaar wordt dat de machine niet eens meer kan booten.

Bovendien is het volgens mij niet zo triviaal om gegeven een bestand en bijbehorende hash een tweede bestand te maken met diezelfde hash.

Twee bestanden maken met dezelfde hash is, bijvoorbeeld in het geval van md5, wel mogelijk tegenwoordig, maar dan heb je dus controle over beide bestanden, niet over slechts één van de twee.

Of heb ik ergens iets gemist/verkeerd begrepen en is ook de weak-collision-resistance van MD5 al om zeep geholpen?

Daarnaast lijkt het me niet dat McAffee zo dom zou zijn om voor zo'n toepassing een hash algoritme te gebruiken waarvan bekend is dat het niet betrouwbaar is.

[Reactie gewijzigd door Orion84 op vrijdag 23 april 2010 16:31]


Je kan altijd meerdere hashes per file opslaan om het zo NOG moeilijker te maken.
bvb: md5 + SHA-256 + grootte van het bestand.

Maar anderzijds: die 'whitelisted' system files van windows worden vaak geupdate -> hash veranderd -> wordt gezien als virus?

Dan is de extra beschermingslaag tegen het verwijderen van essentiële systeembestanden even niet in werking. Effectief ben je in de tijd tussen de update van een systeembestand van de kant van Microsoft en de update van de whitelist door McAfee terug in de situatie van nu. De kans dat in die tussentijd er een fout als de bovenstaande de virusdefinities insluipt lijkt me klein.

Zowel SHA1 als MD5 bijhouden, collision op meerdere hashes wordt wel bijzonder moeilijk.

Het kan inderdaad wel, maar als er wat betere hashing algoritmes dan MD5 of SHA-0 worden gebruikt, dan is het niet mogelijk. Als SHA-1 of SHA-2 worden gekraakt, dan zitten alle websites die gebruik maken van TLS of SSL in grote problemen (en SSH en IPsec). SHA-1 wordt op het moment op veel plekken uitgefaseerd, SHA-2 wordt nog steeds als compleet veilig beschouwd.

[Reactie gewijzigd door the_shadow op vrijdag 23 april 2010 17:03]


whitelisten met hash lijkt ok, tenzij je niet test met alle mogelijke updates, nu wordt sp3 voor xp natuurlijk niet of nauwelijks gebruikt (daar hoef je niet een op te testen zo weinig) maar stel dat er opeens een veelgebruikte update tussendoor komt dan kun je zomaar een heleboel bestanden als false positive aanmerken.

[Reactie gewijzigd door bitflusher op zaterdag 24 april 2010 08:05]


je kan dagelijks een andere hashkey/methode gebruiken, waardoor je maximaal een zero-day exploit/virus kan hebben

Misschien met een signatuur van zo'n bestand? Dus niet enkel met de bestandsnaam zelf, maar ook met de exacte bytecode (of een hash daarvan)? Een virus dat zo'n bestand infecteert verandert sowieso de bytecode van dit bestand, en op deze manier zouden dus geïnfecteerde van niet-geïnfecteerde whitelistbestanden onderscheiden kunnen worden.

[Reactie gewijzigd door Dooievriend op vrijdag 23 april 2010 15:49]


Een besturingssysteem dat niet meer opstart, dat is handig. Ze kunnen natuurlijk wel waarschuwen dat er een gevaar is, maar verwijderen is zo ongeveer het domste dat je kunt doen.

Ik denk dat ze bedoelen dat de whitelist bestanden zal bevatten die niet per definitie in quarantaine mogen worden gezet - niet dat ze niet gescand zullen worden. Je krijgt dan alsnog de melding dat er een infectie gevonden is, maar het geïnfecteerde bestand blijft in ieder geval wel staan, tenminste zo lees ik het.

Fijn, kan ik de factuur van al mijn uren die ik heb moeten besteden om op het werk onze PC's weer op gang te krijgen naar McAfee sturen?? Verdorie....

[Reactie gewijzigd door Neus op vrijdag 23 april 2010 16:03]


Ik was meer tijd kwijt om terug te zetten voor alle mensen. Maar leuk allemaal over te zien :D

Inderdaad, 21 pc's en 7 laptops tot nu toe.
En krijg er elk uur meer bij..

Valt nog mee wij hadden 1200 van de 3500
En ja moet gewerkt worden.

Wij hebben de volgende oplossing verzonnen (wachten op een oplossing is geen keuze)
Een *.bat bestan wat de oude definities terugzet en svchost terug zet.

geimplementeerd door de gebruikers te laten booten via onze ris server welke een bootable image bevatte en automatich the batch file draaide.

Als dat overuren zijn zou je dat met je baas moeten overleggen qua uitbetaling, die kan dan eventueel weer een claim indienen.

Nee hoor, hij stelt dat ik eind-verandwoordelijke ben en dus dit soort fouten zijn automagisch mijn 'schuld'; had ik het zelf maar moeten testen op een XP SP3 bak. Zucht.

Volgens die redernatie is het de schuld van je baas..
Hij heeft immers niet getest of jij dit zou testen bij je job-interview. 8)7

Zoals hij er vanuit gaat dat jij het test, ga jij er vanuit dat MCaffee het test.

[Reactie gewijzigd door Kriebelkous op vrijdag 23 april 2010 16:26]


Schuif hem door naar deze nieuwpost dan... Ziet ie hopelijk wel in dat het toch niet bepaald jouw fout is. Anders wordt het tijd voor een nieuwe baan!

En wat was jouw reden om niet te testen?

Of had je ook net een gewijzigde testprocedure?

Test jij alle virus definities? Voor de meeste programma's geldt er bij ons ook een testproces maar virusdefinities worden zo binnengehaald*. Met dit in gedachte misschien toch eens voorstellen om ook virusdefinities even te testen :)

*: Wij hadden geen problemen. Misschien omdat wij nog SP 2 draaien? 8)7

Test jij alle virus definities?
Een systeembeheerder in een bedrijf met een béétje slim testbeleid zal idd virusdefinities ook eerst testen met een beperkte subset van computers, voor hij het vrijgeeft voor de hele organisatie.

Dat kan bij McAfee heel simpel met ePolicy Orchestrator, dus 'dat kost veel tijd' is ook niet juist, kost je alleen de tijd om éénmalig het pakket in te richten en te configureren. Daarna heb je van zo'n testplan een hoop profijt, zoals je nu ziet.

Ik weet niet in wat voor utopie je werkt maar doorgaans heb ik geen tijd om dagelijks de definities van 5 McAfee producten te testen op 5 platforms maar dat zal wel weer onprofessioneel zijn.

Ik weet niet in wat voor utopie je werkt maar doorgaans heb ik geen tijd om dagelijks de definities van 5 McAfee producten te testen op 5 platforms maar dat zal wel weer onprofessioneel zijn.
Je uitspraak is idd ietwat onprofessioneel.

Natúúrlijk ga je dat niet met de hand doen, ik gaf immers niet voor niks de hint naar ePolicy Orchestrator, die kan dat keurig voor je doen.

Laat hem op een bepaald moment de DAT-files pullen van de NAI-site, push hem naar één repository. Selecteer een paar clients van mensen die als proefpersoon fungeren, laat hun clients verwijzen naar die repository.

Maak een tweede repository waar je de DAT's naar pushed, en laat daar je overige clients naartoe verwijzen als updatelocatie.

Zorg ervoor dat dat de tweede repository een x aantal uur (zeg 4 uur ofzo) na de eerste repository word geupdate, en tada, daar heb je je test-setup.

Komt er een update en is alles OK doe je niks. Is er wel een probleem duikt die vanzelf op in de testgroep, en dan blokkeer je de update naar de tweede repository tot het probleem opgelost is. Kost je 30 seconden werk.

Alles zo opzetten als hierboven kost je misschien één keer 5-10 minuten werk (ePo heb je als bedrijf meestal al wel draaien als je McAfee gebruikt), en je hebt er een hoop profijt van.

Klaarblijkelijke slechte standarisatie in je bedrijf dan.

Het is toch redelijk standaard dat je de updates eerst naar de IT afdeling uitrolt. (of een kleine testgroep) en dan pas naar de rest van je organisatie.
Kost je helemaal geen extra tijd, en je voorkomt dit soort situaties.

McAfee is al bepaald niet de snelste met virusdefinities (vergelijk met andere leveranciers, meerdere updates per dag). Een systeembeheerder weet ook dat updates onmisbaar zijn bij AV en de snelheid van die updates ook wat zegt over de leverancier.

Updates en patches zijn al getest door de leverancier en bij security patches is uitrolsnelheid ook een vereiste.

Hoe lang duurt die test bij jou? Want wanneer weet je dat een update van wat dan ook (AV, OS, programma) geen problemen gaat geven?

[Reactie gewijzigd door Rinzwind op vrijdag 23 april 2010 19:38]


aan de andere kant is het op zich wel best practise om altijd een dagje achter te lopen met de updates :)
of update alles van windows ook direct als microsoft de boel uitbrengt?

voor de meeste updates is testen of een dagje wachten niet erg. voor virus definities lijkt me dit een heel ander verhaal, een virus wat als een dolle over internet vliegt wil je zo snel mogelijk herkennen, een dag achter lopen kan dan ook voor heel veel problemen zorgen.

Ja, niet zo'n vreemde gedachte, al verwacht ik niet meer dan een korting op je volgende aankoop bij je favoriete virus scanboer. }>

[Reactie gewijzigd door leuk_he op vrijdag 23 april 2010 15:51]


Zie de leveringsvoorwaarden, daar zal dit wel in staan.

Aanname: Garantie tot aan de deur, zij zijn nergens voor aansprakelijk.

Voorwaarden zijn niet automagisch geldig, stel je voor dat je een contract opstelt waarin wordt vermeld dat je leven zal worden stopgezet na het opzeggen van een overeenkomst? volgens jou is dat dan ook gewoon afdwingbaar?

Uhm ja ongeveer elk stukje software zal die voorwaarden bevatten, zou een beetje gek zijn als het niet mocht ;) Niet zo letterlijk als hij zegt maar tot op zekere hoogte is het je eigen probleem, de eerste rechtszaak om een blue screen moet ik nog maar zien (of heb ik geweldig tweaker nieuws gemist?)

Misschien eens investeren in de ICT daar? Windows XP is al vrij oud :P
Als je op 7 zat had je dit probleem niet ;)

[Reactie gewijzigd door Saven op vrijdag 23 april 2010 17:16]


7 is nog maar net uit, en moet dus in veel bedrijven nog door de uitgebreide tests komen. Van de tussenliggende versies zijn 2003 en 2008 in sommige gevallen een optie, maar bedrijven die ouderwets met werkstations werken, zijn vaak terecht op XP gebleven toen Vista uitkwam.

weer lekker slordig van MCAfee,
aangezien dit niet de eerste keer is dat zoiets gebeurd verwacht ik ook dat ze misschien klanten gaan verliesen.

Heb zelf ook MCAfee maar draai hem op Windows 7 en geen problemen.

Toch erg jammer.

En toch heeft McAfee de minste false positives volgens Gartner, IDC en Forrester en dit al meerdere jaren na elkaar. Ze zijn ook absolute marktleider in beveiliging van endpoints en netwerken.

Dit toont dat geen enkel product 100% werkt en nooit problemen zal geven.

Dit neemt niet weg dat dit erg slordig was natuurlijk.

En toch heeft McAfee de minste false positives volgens Gartner, IDC en Forrester en dit al meerdere jaren na elkaar. Ze zijn ook absolute marktleider in beveiliging van endpoints en netwerken.
Een false positive op een onschuldig bestand heeft natuurlijk een ander resultaat dan bij een systeembestand zoals in dit geval, waarbij de volledige installatie onbruikbaar is (tot de fix).

Laatste keer dat dit bij McAfee gebeurde is volgens mij meer dan 6 jaar geleden.
Dat het recenter bij een aantal andere is gebeurd lijkt me geen aanleiding dat specifiek McAfee klanten verliest.

"Gebruikers met problemen kunnen al sinds woensdag voor een oplossing terecht op de site van McAfee."
Dat is leuk bedacht maar geen echte hulp wanneer je computer niet opstarten wil. 8-)

Daarom is het ook handig om niet afhankelijk te zijn van een enkele PC, of in ieder geval niet een enkele Windows install. Dit soort geintjes komen vaker voor.

dan zijn we blij dat we ergens een linux boot disk hebben liggen ;)

overal waar ik (als amateur) een PC installeer laat ik een ubuntu cdtje achter. Kan je via VPN al een hoop oplossen.

Al die uren?

Zoveel werk was het niet.
Hoeveel systemen waren het? Ziehier een voordeel om niet en masse naar nieuwe OS'sen of op oude OS'sen te blijven.

In dit geval bleef een groot deel buiten schot bij ons :)

Overigens wel vrij vlotte reactie van McAfee hoor.

[Reactie gewijzigd door basset op vrijdag 23 april 2010 15:47]


Ziehier een voordeel om niet en masse naar nieuwe OS'sen of op oude OS'sen te blijven
Ja hallo, Vista werd door iedereen afgeraden, XP SP3 is nog steeds het meest gebruikt en Windows 7 komt net op de hoek kijken: omdat bedrijven zoals McAfee hun zaken niet op orde hebben moeten we dus maar klakkeloos upgraden, ookal heeft het geen enkele toegevoegde waarde? Mah.

Bij ons in de firma heeft men geluk gehad dat de IT dienst onze systemen nog op SP2 houd op dit moment, anders hadden we hier over duizenden defecte systemen gesproken.

Oftewel McAfee was te lui om dit even te testen op Windows XP SP3...
Bedankt he.. |:(

Heb je zelfs maar overwogen dat dit geen opzet is maar een foutje? Ze leveren verschillende versies voor bedrijven en particulieren. Ze hebben erg veel oude versies die getest moeten worden (ze blijven oudere versies erg lang ondersteunen). XP SP3 is één van de vele OSen waarvoor McAfee scanners levert. Wil je ook nog dat ze alle combinaties van bepaalde hotfixes wel/niet installeren voor je testen? Als je dat allemaal 100% getest wilt hebben dan kost dat weken; niet handig als je elke dag een update uit wilt brengen.
Toegegeven, enterprise 8.7 onder XP SP3 komt iets vaker voor dan enterprise 7.1 onder 2000, maar (tot twee maanden terug??) werden ook daarvoor nog updates uitgebracht, dus ik neem aan dat ze ook die combinaties (en vele andere natuurlijk) voor elke update testen.

Ik begrijp dat het erg vervelend is, maar dat er een keertje een foutje door slipt is nauwelijks te voorkomen. Of zullen we een net zo verontwaardigde thread starten elke keer als er een serieuze bug in Windows / Linux / MacOS / IE / FF / Chrome / .... / [lijst van andere virusscanners] / [lijst van firewalls] / ... wordt gevonden?

In dit geval gaat het om het naar mijn weten belangrijkste OS op dit moment, ik verwacht toch wel dat ze het daarop testen. Alle combinaties van hotfixes etc. zal natuurlijk moeilijk worden, maar ook dat zou op te lossen zijn. Ze kunnen bv. alle versies van systeembestanden bijhouden en gewoon de scanner over de 300 svchost.exe-bestanden heengooien.
Ook zie ik een principieel probleem ermee dat deze scanner zonder blikken of blozen Windows de toegang tot zijn eigen essentiele bestanden ontzegt. Dat is vragen om problemen en de lijst met bestanden die Windows nodig heeft (en zelf probeert te bewaken) zal bekend zijn.

Ofwel McAfee was te lui om dit gewoon goed te bouwen. Testen voegt geen kwaliteit toe. Het toont enkel de kwaliteit aan.

zouden heel veel bedrijven hiervoor nou geen schade claim indienen? kost hun weer geld om hun systeembeheerders al die computers weer te laten repareren.
vind het belachelijk dat dit er doorheen is gekomen, vooral als groot antivirus bedrijf mag jezelf toch niet zo'n fout als deze permiteren. ongeacht testprocedure. gehele ziekenhuizen lagen plat. zo zie je maar weer hoe digitaal we worden.

"Foutieve McAfee-update gevolg van gebrekkige testprocedure"

Thank you for pointing out the obvious!!

Daar had ik nou geen uitgelekt document voor nodig om daar achter to komen.
en het is inderdaad nogal knudde dat het in eens niet meer gedaan wordt, gezien zo veel bedrijven nog steeds XP gebruiken.

voortaan doen we lekker zelf wel het testen van de DAT files voordat het uitgerold wordt.
geen 2de keer dit grapje.

En ga jij ALLE situaties kunnen testen in een testomgeving? Dat kan je niet. Bij 1 van de vorige keren dat dit bij een concurent gebeurde bleek het probleem beperkt tot bepaalde talen van het OS. Moet je dan duizenden systemen gaan opzetten waarbij je imens veel combinaties gaat testen?

Op een gegeven moment bereik je een punt waarbij de kosten niet meer opwegen tegen de baten. Het is in een bedrijfsomgeving zowiezo aan te raden om updates nog eens zelf te testen omdat in een bedrijfsomgeving de meeste systemen een gelijkaardige softwarecombinatie draaien.

Lekker betrouwbaar bedrijf. Als het nou zo makkelijk is om een bestand te verwijderen dan gaan we wat beleven in de toekomst. 27 processen in 1 keer plat. Dat is wel een idee. Gelukkig meer Panda verkocht dan McAfee. De paar McAfee pcs zijn alweer in orde maar het is wel weer gezeur met een antiviruspakket. Ik vind wel dat nog steeds virussen makkelijk door antiviruspakketen komt maar dat is even een ander verhaal.

En wat als het volgende week Panda overkomt? Ga je dan nog gelukkig zijn dat je meer Panda verkoopt?

En de virusdetectie van de grote namen is redelijk goed te noemen, 100% detectie kan gewoon niet.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:18 LG's eerste Windows Phone 7-toestel heet C900
Vorige 15:07 Google in Duitsland onder vuur over in kaart brengen wifi-netwerken
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011