Google Chromebook veilig zonder Anti-Virus! Oh nee toch niet...

Wat een grap. Googles marketing machine heeft behoorlijk wat onrust in security land veroorzaakt, en nog onterecht ook. In een blog wees Linus Upson twee weken geleden (11 mei) op de geïntegreerde securityfunctionaliteiten van het aangekondigde Chromebook. Ik ga maar even niet uitleggen wat een Chromebook is en hoe die beveiliging eruit ziet, want dat is prima te vinden op Google :).

In het kort stelt Google dat vanwege de sandbox functionaliteit, het auto-herstel proces bij opstart EN het feit dat alle data in de cloud is opgeslagen, een Chromebook geen Anti-Virus nodig heeft. Dapper, en deels misschien ook nog wel waar, maar voor mensen waarvoor Endpoint Security ophoudt bij Anti-Virus betekent een dergelijke stelling waarschijnlijk zoveel als dat je met een Chromebook gegarandeerd veilig bent. FOUT.

Maar goed, voor security-correspondent Andy Greenberg van Forbes was dit blogartikel voldoende om zich af te vragen of het nu gedaan is met Anti-Virus producenten in zijn eigen Blog...

... wat vervolgens weer leidde tot een overhaaste reactie van George Kurtz (CTO, McAfee) dat Anti-Virus misschien niet meer nodig is, maar dat andere vormen van Security (bijv. Application Whitelisting) nog steeds heel bruikbaar zijn...

... wat daarna weer leidde tot een artikel op Security.nl getiteld "Chromebook betekent einde virusscanner"...

Ik ben natuurlijk hierover gaan nadenken en wilde vandaag een reactie schrijven om aan te geven dat volgens mij de sessie van een gebruiker op een Chromebook toch echt gecompromiteerd kan worden. En dat die sessie voldoende kan bieden aan een hacker (passwords, creditcard nrs, etc.) om schade toe te brengen. En ook al draait Chromebook zijn apps op het internet, er zijn altijd lokale applicaties, zoals de browser. Deze discussie komt ook enigszins overeen met de vraag of een Virtual Desktop die telkens terugkeert naar een Golden Image nog Anti-Virus nodig heeft. NEE!, want alle data wordt verwijderd bij terugkeer naar het Golden Image, zeiden de tegenstanders. JA!, want die data kan genoeg schade toebrengen gedurende de sessie van de gebruiker, zeiden de voorstanders.

Het verschil tussen de Chromebook en VDI discussies is dat er evenveel (zo niet meer) vulnerabilities in een Virtual (Windows-based) Desktop bestaan als in een Fysieke (Windows-based) Desktop en dat die dus even actief worden misbruikt. Maar de stelling dat een Chromebook geen vulnerabilties bevat, durft Google denk ik niet aan. Waarom zouden ze anders een auto-herstel functie maken?

Dus ik ging nog eens teruglezen wat de verschillende meningen zijn over deze stelling van Chromebook en kwam daarmee nog even op het artikel van Andy Greenberg, Forbes. En wat blijkt: na publicatie van het artikel heeft meneer Greenberg even een kleine update gedaan (wanneer is niet duidelijk) omdat zijn beweringen toch op wat verweer stuitte. De update:

A critical response post at Tom’s Tech Blog points out a few issues I missed here. Google is releasing a software development kit for native applications, which could potentially introduce security vulnerabilities. And with regard to Charlie Miller’s quote above, even a hijacked browser could potentially steal a user’s credentials, which could allow access to his or her cloud-stored data. (Though the point remains that this isn’t an issue that necessarily can be fixed by antivirus software.) Apologies for these oversights.

Fijne nuance is dat. Jammer dat een dergelijke update niet uiteindelijk ook beland bij Security.nl en dat mensen die niet verder lezen dus nog steeds in de veronderstelling zijn dat hun Chromebook onbreekbaar is.

Google valt niets te verwijten, hun stelling is juist: een Chromebook heeft geen Anti-Virus nodig. George Kurtz heeft echter ook gelijk: om ook gedurende de gebruikerssessie misbruik te voorkomen, is Whitelisting nog steeds wel van absolute toegevoegde waarde.

En oh ja dan nog iets: we willen toch niet serieus beweren dat zakelijke gebruikers bewust hun data bij Google gaan opslaan? Als je naar de reacties op Security.nl kijkt in elk geval niet. Ik ben benieuwd hoe IT afdelingen in zakelijke omgevingen voorbereid zijn op de eerste hippe manager die straks aan komt wandelen met zijn Chromebook om even te laten syncen met Exchange. Veel succes daarmee...

Medusoft Security Seminar 2011

Vandaag vindt het jaarlijks Security Seminar van Medusoft plaats in het Beatrix Theater in Utrecht.
Inspirerend om op deze manier met mensen in contact te komen die met hun voeten in de digitale Security staan!

Web & Removable Storage belangrijkste bron van virusinfecties

Wederom voor de presentatie van morgen, heb ik een onderzoek gedaan naar bronnen van virusdetecties bij onze klanten. Uit de organisaties waar wij het beheer voor McAfee anti-virus software voor doen, heb ik een selectie gemaakt en daar eens door de hele lijst van detecties in het afgelopen jaar heen geploegd.

Management Summary: Removable Storage is de belangrijkste uiteindelijk bron van detecties. Wanneer dat teruggeleid zou worden naar de oorspronkelijk infectiebron, dan is echter alles natuurlijk inmiddels zo goed als zeker afkomstig van het Internet. Op kantoor en daarbuiten moet dus goed worden nagedacht over de beveiliging van internetgebruik. Tevens moet worden nagedacht hoe systemen en removable storage die eerst binnen het netwerk worden gebruikt en dan weer erbuiten, continu worden gemonitoord of het gebruik ervan wordt gereguleerd.

De reden om dit inzichtelijk te maken, is dat het evident wordt voor organisaties om in te zien dat Anti-Virus Software op de Endpoint veel te weinig zekerheid geeft. Dat het daarom nodig is om de plekken waar AV op de Endpoint de enige laag van verdediging is, in kaart te hebben en waar nodig extra te beveiligen.

In totaal hebben in 1 jaar tijd op 18.750 systemen in totaal 3499 unieke detecties voorgedaan. Een unieke detectie is 1 benoemd virus op 1 systeem vanaf 1 lokatie. Meervoudige detecties heb ik dus uitgefilterd.

De volgende bronnen van detectie heb ik onderscheiden:
1. Internet: Detectie in de directories Temp. Internet Files, Downloads of Java cache
2. Remote: Detectie op E:\ t/m Z:\ (dus cd-rom, usb of mapped network)
3. SourceIP: Detectie op C:\ of D:\, rechtstreeks weggeschreven naar dit systeem, vanaf een ander systeem
4. Lokaal: Detectie op C:\ of D:\ schijf, maar ZONDER Source IP

Om commentaar voor te zijn: ik weet heel goed dat deze metingen dus zeker niet waterdicht zijn, maar ze zijn wel consequent toegepast en geven m.i. een redelijk beeld van de verdeling in detecties. De verhoudingen zijn als volgt:

Internet: 9%
De meest eenvoudige manier van verspreiden van Malware is het internet. Waarschijnlijk vinden detecties in de andere categorieën in eerste instantie ook hun oorsprong op internet.

Oplossingen: Filteren van internet is geen keuze meer, maar een absolute noodzaak. Blokkeer toegang tot websites die gewoon bekend zijn met een slechte reputatie. Daar val je echt niemand onnodig mee lastig en levert direct een verhoogd beveiligingsniveau. Daarnaast kan je ook aan de gateway de content van webverkeer scannen zodat je maar 1 device up-to-date hoeft te houden met AV definities voor dat basis niveau van veiligheid. Out-of-date AV op de endpoints is natuurlijk zeer gevaarlijk, maar tegelijkertijd bijna niet voor 100% te voorkomen (ok, met NAC wel). Tenslotte is ook een vervanging van de firewall een quick win. De oude firewalls stonden poort 80 toe omdat het http was. Daar kan je al voldoende discussie over hebben, los van de ontwikkelingen van de laatste tijd waarbij op het internet steeds meer actieve componenten draaien met alle risico van dien. Next Generation Firewalls kunnen bijv Facebook toestaan maar de games/applicaties daarbinnen blokkeren.

Remote: 20%
De meting in dit geval is op basis van driveletter. Alle detecties rechtstreeks op E: t/m Z:, tellen mee. Je zou zeggen dat dit dan removable storage EN mapped network drives kunnen zijn, maar McAfee scant (by default) niet op mapped network drives dus het is toch echt grotendeels removable storage.

Oplossing: Reguleer het gebruik van removable storage middels een stuk port controle software. Laat bijvoorbeeld alleen USB sticks toe die je zakelijk ondersteunt en of een embedded virusscanning engine bevatten. Zet On-Read scanning AAN in je virusscanner!!! Voor detecties die toch plaatsvinden op mapped network drives: ten eerste is dit onhandig want heel vertragend dat je over het netwerk aan het scannen bent. Ten tweede zou je goed moeten kijken of je storage devices zelf ook on-access virusscanning toepassen. McAfee heeft bijvoorbeeld al jaren een perfecte oplossing om systemen als NetApp van virusscanning te voorzien: VirusScan for Storage. Echt een noodzaak zoiets: non-windows storage systemen zijn 1 van de grootste verspreiders van file-infectors zoals het vreselijke Sality virus.

SourceIP: 16%
Dit betekent feitelijk dat een geinfecteerd systeem in het netwerk, op afstand jouw systeem probeert te infecteren. Dat kan een worm zijn, een file-infector, of zelfs een doelbewuste hackpoging.

Oplossing: wormen die misbruik maken van beveiligingslekken kunnen op netwerkniveau geblokkeerd worden door middel van IPS. IPS kan host-based worden ingezet op network-based. Het laatste sluit aan bij een netwerk-segmentatie strategie, en dat juichen wij ten zeerste: Scheid je servers van je desktops (fysiek dan wel middels VLANs) en plaats een IPS tussen je netwerksegmenten. File-Infectors hebben alleen kans van slagen als met de rechten van de aangemelde user, het bestand kan worden weggeschreven naar remote systemen. Voorkom dit in rechtenniveaus dus zoveel mogelijk! Netwerkbeheerders: werk niet met een account dat domain admin is totdat je die functionaliteit echt nodig hebt. Dus een account jantje voor normale werkzaamheden en adm_jantje als je iets in het domein moet doen. Voor doelbewuste hackpogingen EN om wormen te blokkeren is belangrijk dat je weet wat er op je netwerk voorkomt. Als een systeem ingeplugd wordt dat je niet herkend, zou je dat liefst ZSM willen weten. Dat kan eenvoudig middels Rogue System Detection maar dat is dan alleen alarmering. Wil je ook systemen actief van je netwerk afgooien, dan heb je Network Access Control (NAC) nodig.

Lokaal: 55%
Alle overige detecties vinden lokaal hun oorsprong. Daar zitten in de lijst met detecties nog gewoon locaties tussen van minder voor de hand liggende internet-applicaties, zoals internet boekhouden. Maar goed, ik heb ergens de grens getrokken. Lokale detecties zijn het gevolg van een applicatie die iets probeert te openen (maar dan niet vanaf E: t/m Z: of vanaf het internet), OF, en dat is hier veel vaker het geval, van een reeds aanwezige infectie. Rootkit infecties verbergen zich voor het OS en kunnen dus aanwezig zijn zonder dat de AV software het weet. Als die rootkit vervolgens iets lokaal probeert uit te voeren (extra infectie van bijv een keylogger), dan kan dus alsnog worden herkent.

Oplossingen: Een feitelijke infectie kan nog altijd het best worden opgelost middels herinstallatie van een systeem. Zorg er dus voor, dat je goede re-image mogelijkheden voorhanden hebt in geval van calamiteiten.

McAfee gaat 60 DAT Updates per dag uitgeven

Oké allereerst: grapje! Ik kwam hierop toen ik gisteren mijn presentatie aan het voorbereiden was voor ons jaarlijks Security Seminar. Daar wilde ik natuurlijk even ingaan op het 10-jarig bestaan van Medusoft, en op wat de ontwikkelingen bij ons bedrijf maar ook in Security in het algemeen zijn geweest in die tijd.

Ik vind het altijd grappig om te vertellen dat McAfee toen ik bij Medusoft begon, nog geen 10 jaar geleden, slechts maandelijks een DAT-file uitbracht. Een update dus om je Anti-Virus software de laatste virussen te kunnen laten herkennen. In 2001, waar we het nu over hebben, zijn ongeveer 155.000 nieuwe virussen ontdekt en aan de DAT-file toegevoegd. Dat betekent dat McAfee elke 13.000 virussen een update uitbracht.

Halverwege ons bestaan, op 8 februari 2005 heeft McAfee naar aanleiding van de hoos aan nieuwe virusvarianten besloten om de updatefrequentie aan te passen naar elke dag. Dus elke dag van de week een DAT-update. Dat was toen nodig omdat de groei van virusvarianten zo extreem was, dat met de wekelijkse DAT-file (want die is er ook geweest) te veel risico ontstond dat gebruikers alsnog besmet raakten. In 2005 zijn een ruime 333.000 virussen uitgekomen. Dus McAfee besloot dat een DAT update vereist was bij 912 nieuwe virussen.

Sinds 2005 is de groei van virusvarianten exponentieel gestegen tot eind 2009. Vanaf dat moment is er sprake van een lineaire groei: 20.000.000 virusvarianten in 2010. Even een ander verhaal. Terugrekenen met een DAT-update elke 912 varianten betekent dus 60 DAT-updates per dag.

Uiteraard een illusie, en vandaar de noodzaak om verder te kijken dan alleen Viruspreventie op de Endpoint. Grappig is echter dat ik mij afvraag of organisaties sinds 2001 de ruimte die nodig is om controle uit te oefenen op DAT-updates hebben bijgewerkt aan de hand van de ontwikkelingen. Mijn ervaring is dat het niveau van deze controle nog steeds anno 2001 is: elke maand controle. Met 20.000.000 virussen per jaar betekent maandelijkse controle dat je in het slechtste geval evenveel virussen achterloopt als in 2001 het hele jaar zijn uitgekomen. Was dat toen acceptabel?

Hello World!

Even voorstellen: mijn naam is Erik Remmelzwaal en ik ben Algemeen Directeur van Medusoft BV. In de 10 jaar dat ons bedrijf nu bestaat, heb ik veel ervaring opgedaan met IT Security in het Nederlands bedrijfsleven. Zo heb ik een vrij helder beeld gekregen van hoe IT Security in de praktijk (al dan niet) wordt toegepast en kan ik actuele problemen en bedreigingen goed vertalen naar acties die passen bij een typisch Nederlands bedrijf.

Vanuit deze optiek vond ik het hoog tijd om eens een plek te creëren waar ik mijn persoonlijke mening geef over nieuws rondom IT Security. Die plek is hier, en mijn berichten starten vandaag. Voel je vrij om je eigen ongezouten reactie te geven als iets je niet zint, ik hou van discussie!

Ciao!

Erik Remmelzwaal