Dessa frågor bör du ställa till din leverantör – om webbplatsens säkerhet

Din webbplats hackas sällan av en slump. Här är frågorna du bör ställa till din webbleverantör om WordPress-sårbarheter, databasen, e-postskydd och Imunify360. Så ser du om sajten är skyddad.

När en webbplats drabbas är det sällan för att någon har siktat in sig på just ditt företag. Automatiska robotar söker av internet efter sajter med ett gammalt plugin, en föråldrad PHP-version eller en databas med för vida rättigheter, och hittar de en kör de på. Ofta märks det först när sajten visar skräp, mejlen hamnar i skräpposten eller Google varnar besökarna.

Hur väl du är skyddad avgörs till stor del av hur din leverantör arbetar, och det märker du sällan själv. Därför bör säkerhetsarbetet vara en tydlig del av det du köper, inte en detalj i avtalet. Frågorna nedan är sådana vi själva utgår från när vi granskar kunders webbplatser. Det finns inga fel svar, men det finns svar som är för vaga. Om leverantören inte kan svara konkret är det ofta svaret i sig.

1. Vad syns utifrån på din webbplats?

En angripare börjar alltid utifrån. Allt som går att läsa av utan inloggning är samma underlag som en automatisk sårbarhetsskanner använder, och det är därför ett bra ställe att börja när du granskar en leverantör.

• Vilken PHP-version kör min webbplats på, och när slutar den få säkerhetsuppdateringar? En PHP-version som inte längre underhålls får inga säkerhetsrättningar, oavsett hur väl allt annat sköts. Be om versionen skriftligt och om leverantörens plan för uppgradering.
• Har sajten giltigt HTTPS, och vilka TLS-versioner tillåts? Certifikatet ska förnyas automatiskt och äldre protokoll ska vara avstängda. Fråga också vem som larmas om ett certifikat går ut.
• Skickar servern säkerhetsheaders? Till exempel HSTS, X-Content-Type-Options, X-Frame-Options och en Content-Security-Policy. De kostar nästan inget att sätta på plats och minskar risken för clickjacking och injicerat innehåll.
• Råkar vi exponera filer som inte ska nås utifrån? Glömda backupfiler, .git-mappar, phpinfo()-sidor, wp-config.php.bak och källkodsarkiv i webbroten hittas dagligen av automatiska skannrar. Be leverantören bekräfta att webbroten bara innehåller det som ska publiceras.
• Avslöjar sajten versionsnummer? Generator-taggar och versionssträngar gör det lätt att matcha din installation mot kända sårbarheter. Det är ingen ersättning för uppdateringar, men det är onödigt att göra det enkelt för angriparen.

2. Hur skyddas din e-postdomän?

En webbplats och dess e-post hör ihop. Den som kan skicka mejl i ditt domännamn kan ge sig ut för att vara ditt företag, och leverantören som sköter din DNS och din hosting har oftast hand om det.

• Finns SPF, DKIM och DMARC på min domän? Alla tre ska vara på plats. DKIM ska dessutom vara publicerat på rätt selektor för den tjänst som faktiskt skickar din e-post, annars finns signaturen men valideras aldrig.
• Vilken DMARC-policy används: none, quarantine eller reject? none övervakar bara. Målet är reject, och en bra leverantör kan beskriva stegen dit.
• Vem läser DMARC-rapporterna? En rapport som skickas till en brevlåda ingen öppnar är inget skydd.
• Kan formulär på sajten skicka mejl som vem som helst? Kontaktformulär som skickar med avsändaradress från användaren kan missbrukas för spam i ditt namn.

3. Hur hanteras sårbarheter i WordPress, plugins och teman?

De flesta lyckade intrång i WordPress-sajter går via ett plugin eller tema, inte via kärnan. Sårbarheterna är publika och spåras i databaser som WPScan, där varje sårbarhet kopplas till ett CVE-nummer och en version. Det gör att man kan jämföra en installation mot listan automatiskt, och det gör angripare också.

• Vet ni vilka plugins och teman som är installerade på min sajt, och i vilka versioner? En leverantör som inte har en aktuell förteckning kan inte heller veta vad som är sårbart.
• Jämför ni installationen mot en sårbarhetsdatabas, och hur ofta? Fråga om det sker kontinuerligt eller bara vid ett kvartalsmöte. Ett nytt CVE kan utnyttjas inom timmar efter att det publicerats.
• Hur snabbt uppdateras ett plugin med känd sårbarhet? Be om en konkret tidsram för kritiska sårbarheter, till exempel dagar och inte veckor, och om vad som görs om ingen uppdatering finns ännu.
• Vad händer med plugins som inte längre underhålls? Övergivna plugins är en av de vanligaste orsakerna till intrång. Leverantören ska kunna peka ut dem och föreslå ersättare.
• Testas uppdateringar innan de går live? Automatisk uppdatering utan test kan ta ner sajten; ingen uppdatering alls lämnar den öppen. Fråga hur leverantören hanterar båda riskerna.
• Används nulled eller piratkopierade plugins och teman? Svaret ska vara ett kategoriskt nej. Piratversioner innehåller ofta bakdörrar.
• Vilka användare har administratörsrättigheter, och är tvåfaktorsinloggning aktiv? Gamla konton från tidigare konsulter är en klassiker.

4. Hur är webbplatsen kopplad till databasen?

En sårbarhet i ett plugin blir en genväg till databasen. Via den kan en angripare läsa kunduppgifter, skapa egna administratörskonton eller lägga in skadlig kod direkt i inlägg och inställningar, där vanliga filskannrar inte letar. Hur snävt kopplingen är begränsad avgör hur mycket skada ett enskilt intrång kan göra.

• Har varje webbplats en egen databasanvändare med egna uppgifter? Delade databasanvändare mellan sajter betyder att ett intrång på en sajt når alla de andra.
• Vilka rättigheter har databasanvändaren? Sajten behöver normalt läsa, skriva och ändra data i sin egen databas. Den ska inte ha GRANT, FILE eller rättigheter mot andra databaser.
• Kan databasen nås utifrån? Databasservern ska lyssna lokalt eller bakom en brandvägg, aldrig öppet mot internet. Fråga också om phpMyAdmin eller liknande verktyg är nåbara publikt.
• Var förvaras inloggningsuppgifterna? wp-config.php ska ligga utom räckhåll för webbläsaren och ha strikta filrättigheter. Be om bekräftelse att lösenorden är unika och långa, och att de byts efter en incident.
• Används ett eget tabellprefix, och hur skyddas egenutvecklad kod mot SQL-injektion? Prefixet är ingen säkerhet i sig, men egenutvecklade plugins och temaändringar ska använda förberedda satser ($wpdb->prepare). Be att få veta hur koden granskas.
• Skannas databasen efter skadlig kod, inte bara filerna? Ett intrång kan lämna kvar injicerade skript i databasen även när alla filer är rena. Det leder oss till nästa fråga.

5. Kör ni Imunify360, och vad gör det i praktiken?

Imunify360 är en säkerhetssvit för webbservrar. Enligt tillverkaren ingår bland annat malwareskanning av filer i realtid och på begäran, en databasskanner för CMS som WordPress och Joomla, samt en brandvägg. Proactive Defense stoppar skadlig PHP-kod i körningsläget, och en WAF kan ge så kallad virtuell patchning mot kända sårbarheter i plugins innan de hunnit uppdateras (Imunify360 dokumentation).

Namnet i sig säger dock lite. Vilka funktioner som är påslagna beror på vilken produkt och vilka inställningar leverantören valt, och den lättare ImunifyAV har en mindre uppsättning än Imunify360. Fråga därför:

• Vilken Imunify-produkt kör ni: ImunifyAV, ImunifyAV+ eller Imunify360? Skillnaden är stor när det gäller realtidsskydd och WAF.
• Är Proactive Defense och WAF aktiverade på min sajt, eller bara skannern? Att produkten är installerad på servern betyder inte att alla skydd är på.
• Skannas databasen, inte bara filerna? Databasskannern är det som hittar injicerade skript i inlägg och inställningar.
• Vad händer när något hittas: städas det automatiskt, sätts filen i karantän eller får ni bara en notis? Och vem tittar på notisen?
• Hur ofta körs fullständiga skanningar, och sparas historiken? Du ska i efterhand kunna se vad som hittats och när.
• Hur får jag veta om något hittats på min sajt? Ett skydd som larmar bara internt hjälper dig inte att fatta beslut.
• Vad ersätter Imunify360 inte? Det är ett skyddsnät, inte en ursäkt för att hoppa över uppdateringar. Ett plugin som uppdateras i tid är fortfarande bättre än ett plugin som ”virtuellt patchas”.

6. Vad händer när något ändå går fel?

Ingen leverantör kan lova att aldrig bli drabbad. Det du kan kräva är att de upptäcker det snabbt och kan återställa utan att förlora din data.

• Hur ofta tas backup, var lagras den och hur länge sparas den? Backup på samma server som sajten råkar försvinna i samma incident. Fråga efter en kopia på annan plats.
• När gjordes senaste återläsningstestet? En backup som aldrig återställts är en gissning.
• Hur långt tillbaka kan ni gå, så att en återställd kopia inte innehåller samma intrång?
• Hur övervakas sajten dygnet runt? Bland annat upptid, ändrade filer och skanningsresultat. Fråga vem som får larmet och inom vilken tid ni svarar.
• Vad säger avtalet om personuppgiftsincidenter? Om kunduppgifter läcker har du som personuppgiftsansvarig en anmälningsplikt till IMY inom 72 timmar. Leverantören ska då meddela dig utan dröjsmål. Be om rutinen skriftligt.
• Vem gör utredningen och städningen efter ett intrång, och ingår det i priset? Och vad görs för att samma sårbarhet inte utnyttjas igen, till exempel byte av alla lösenord och nycklar?

Sammanfattning: tre saker att ta med till nästa möte

• Be om PHP-version, plugin-lista och datum för senaste uppdatering, skriftligt.
• Be om besked om vilka Imunify-funktioner som är aktiva för just din sajt, och hur databasen skyddas.
• Be om backuprutin, återläsningstest och incidentprocess i avtalet.

En bra leverantör tar emot de här frågorna som ett tecken på att du bryr dig om din verksamhet, inte som ett hot. Om svaren uteblir, eller blir en allmän försäkran om att ”allt är under kontroll”, vet du mer än du gjorde innan du frågade.