Vilken säkerhetskontroll kräver förfrågningsunderlaget: CHECK, ITHC och PTaaS

CHECK, ITHC, PTaaS, CREST och Cyber Essentials är inte fem nivåer av samma arbete, utan fem olika objekt. Hur du ser vilket av dem förfrågningsunderlaget faktiskt kräver, och om det ens gäller dig.

Du öppnar förfrågningsunderlaget, hittar avsnittet om säkerhet i den tekniska specifikationen och läser fem namn: CHECK, ITHC, PTaaS, CREST och Cyber Essentials Plus. Bredvid dem står orden ”säkerhetsgranskning” och ”penetrationstest”, och alltihop är skrivet som om de vore steg i samma arbete — från det billigaste till det dyraste.

De är inte steg, utan fem olika objekt som svarar på fem olika frågor: vem som får testa, vad som görs med ett visst nät, hur testet faktureras, om leverantören själv har ordnat sin infrastruktur, och om systemet uppfyller en norm. Ett anbud som blandar två av dem lovar antingen det som inte får lovas, eller betalar för det som inte krävdes.

Den här artikeln säljer inte CHECK, och det är ärligt att säga det med en gång: vi är inte medlemmar i CHECK-schemat, och den här texten påstår inte det. Artikeln förklarar vad förfrågningsunderlaget faktiskt kräver, så att du kan se om det ens gäller dig — och bara i det fall kravet visar sig vara en vanlig säkerhetskontroll av webbplatsen pekar den mot vår säkerhetsgranskning.

Priset skiljer sig här inte med procent, utan flera gånger, eftersom ett anbud som svarar mot ett Cyber Essentials-krav och ett anbud som svarar mot ett fullt penetrationstest av ett system med många roller är två olika budgetar, och en beställare som lägger dem i samma tabell jämför det som inte går att jämföra. På samma sätt förlorar en anbudsgivare som läser kravet ett steg högre än det är skrivet upphandlingen med ett fullt korrekt, bara onödigt dyrt, anbud.

Fem namn som inte är fem nivåer av samma arbete

• CHECK — Storbritanniens nationella cybersäkerhetscentrums (NCSC) schema för företag. Det anger vem som får testa system i den offentliga sektorn och i kritisk infrastruktur, och i vilken form rapporten ska tas fram.
• ITHC — ett konkret kontrolluppdrag med en konkret omfattning, som krävs för anslutning till Storbritanniens förvaltningsnät. Det är ett uppdrag, inte ett schema.
• CREST — en internationell branschorganisation med egna examinationer. Den är inte en synonym till CHECK, och just den sammanblandningen är den vanligaste i anbud.
• PTaaS — penetration testing as a service, det vill säga en leverans- och faktureringsmodell: plattform, abonnemang, tätare fynd. Den säger ingenting om vem som testar och efter vilken norm.
• Cyber Essentials och Cyber Essentials Plus — en certifiering av leverantörens egna fem grundläggande kontroller, inte av det system som levereras.

Alla fem är brittiska eller internationella instrument, och inget av dem finns i svenska författningar, och det är det första att ha i huvudet när du läser ett svenskt förfrågningsunderlag där något av dem har skrivits in.

CHECK är ett schema för företag, inte en testmetod

CHECK är ett schema som NCSC förvaltar, där ett företag antas, inte en metod som vilken utförare som helst kan tillämpa. NCSC:s vägledning för köpare förutsätter att arbetet utförs av en medlem i schemat, att teamet leds av en CHECK Team Leader och att CHECK Team Member arbetar i det, att de personerna har brittisk personalsäkerhetsklassning, och att rapporten tas fram i schemats format, och att en kopia under en viss sekretessnivå dessutom går till NCSC. Det betyder att CHECK inte är något man kan ”uppfylla” med ett tillräckligt bra test, för företaget antingen är med i schemat eller inte, och ingen metodbeskrivning i anbudet ersätter det faktumet. CHECK är inte heller lag: NCSC skriver det som schemavägledning, och för det brittiska förvaltningsnätet är det en av flera erkända vägar, inte ett lagkrav.

Ännu viktigare än själva schemainnehållet är vem CHECK över huvud taget är till för, och NCSC skriver det utan omsvep: schemat är byggt för den centrala statsförvaltningen, för myndigheter i den offentliga sektorn och för kritisk infrastruktur. För centralförvaltningens system, där uppgifter med en viss märkning och högre behandlas, rekommenderar NCSC att bedömningen anförtros en medlem i schemat, för övriga myndigheter i den offentliga sektorn rekommenderas det starkt, men för en organisation som varken är offentlig sektor eller kritisk infrastruktur pekar NCSC själv mot den vanliga vägledningen för upphandling, inte mot CHECK. För ett privat företag som tar fram ett anbud till en kommersiell beställare betyder det att CHECK inte är ett mål att sikta mot. Det är en annan stats interna ordning för den offentliga sektorn, och att namnet nämns i ett kommersiellt anbud tyder oftare på att namnet har skrivits av, än på att arbetet blir bättre.

ITHC är ett uppdrag för ett visst nät

ITHC — IT Health Check — är det en brittisk myndighet behöver för att ansluta sig till, eller stanna ansluten till, förvaltningsnätet. Det brittiska Cabinet Offices stöddokument från 2022, som anslutningsprocessen fortfarande hänvisar till, beskriver minimiomfattningen: kontroll både utifrån och inifrån, den inre delen med skanning och manuell analys i hela miljön, men i stora miljöer får stickprov användas, och då får urvalet inte vara mindre än en tiondel. Själva anslutningsprocessen kräver i sin tur att den ingivna rapporten inte är äldre än ett år och inte redan har använts i en tidigare anslutningsansökan. På svenska finns inget eget namn, och det är inte värt att hitta på ett, för en översatt hälsometafor förklarar ingenting; det precisare är att behålla ITHC och en gång förklara att det handlar om en säkerhetskontroll av anslutningen till ett visst nät.

Själva omfattningen är beskriven betydligt mer i detalj än det som vanligen hamnar i ett anbud, för den yttre delen kontrollerar tjänster som nås från internet (post, webb, brandväggar), fjärråtkomst och tredjepartsanslutningar. I den inre delen krävs, vid sidan av skanning, manuell analys, liksom konfigurationen av arbetsstationer och servrar, patchstatus, trådlösa nät och anslutningsgatewayn. I stora miljöer är stickprov tillåtna, och just där dyker den tiondel upp som brukar försvinna i anbuden. Resultatet har också krav: antalet fynd, typ och allvar i en begriplig sammanfattning, så långt det går med CVSS-basvärde. De här siffrorna är Cabinet Offices ITHC-krav för ett visst nät — det är varken en CHECK-norm eller en svensk norm, och det är inte riktigt att föra över dem till en svensk upphandling som en allmän kvalitetsmåttstock.

Tre namn som oftast blandas ihop med CHECK

De övriga tre namnen dyker upp i förfrågningsunderlag bredvid CHECK som om de vore varianter av det, och vart och ett svarar i själva verket på en annan fråga: ett om vem som examinerade personen, ett om hur arbetet levereras och betalas, ett om leverantören själv har ordnat sin infrastruktur, och precis de tre ger upphov till merparten av de felaktigt skrivna anbuden.

CREST är inte CHECK

Det här är det vanligaste misstaget och samtidigt den mest användbara skillnaden den här artikeln kan säga, för den ändrar anbudets innehåll: CREST är en organisation med medlemskap och examinationer, medan CHECK är NCSC:s schema med eget medlemskap och egna roller. CREST beskriver själv det som en separat väg — dess certifikat kan vara ett sätt för en person att visa kompetens, men av det följer inte automatiskt att företaget är CHECK-medlem. Den praktiska följden när anbud jämförs är enkel: om underlaget kräver CHECK räcker inte ett CREST-certifikat, och omvänt — om underlaget kräver CREST är CHECK-medlemskap mer än vad som begärdes, och för det har man sannolikt betalat för mycket.

PTaaS är en faktureringsmodell, inte ett schema

PTaaS beskriver hur tjänsten levereras och betalas: en plattform med instrumentpanel, ett abonnemang, fynd som dyker upp löpande, och omtestning efter rättningar. Branschbeskrivningarna formulerar det just som en leveransmodell, och där finns varken ett kvalifikationskrav eller en myndighet som godkänner den. Därför är svaret på frågan ”uppfyller PTaaS ett CHECK- eller ITHC-krav” inte ”ja” eller ”nej” — det är en fråga om två olika objekt. En faktureringsmodell kan helt enkelt inte uppfylla ett krav på vem som får testa och efter vilken metodik, så om båda står i underlaget ska de läsas var för sig: det ena säger kompetenskravet, det andra hur arbetet läggs upp i tiden.

Cyber Essentials granskar leverantören, inte det som levereras

Cyber Essentials är en certifiering av fem grundläggande kontroller i leverantörens egen infrastruktur, och Plus-varianten lägger till en kontroll med standardverktyg. Certifikatet förnyas en gång om året, och upphandlingspolicyn PPN 014 knyter det till säkerhet i leveranskedjan. Därav den gräns som anbud ofta trampar över: Cyber Essentials Plus är inte det penetrationstest underlaget krävde för det system som ska utvecklas. Det är ett intyg om leverantörens egna datorer och konton, så ett företag kan vara Cyber Essentials Plus-certifierat och leverera ett system som aldrig har testats.

Tre påståenden du inte ska lita på

Runt de här namnen har det lagts ett skikt av påståenden som skrivs av från en tjänstebeskrivning till nästa, och de tre vanligaste är antingen osanna eller inaktuella, så de är värda att läsa bredvid det källan faktiskt säger.

”CHECK krävs av brittisk lag.” Ingen lag namnger CHECK, och NCSC använder i sin vägledning orden ”bör” och ”rekommenderar starkt”, och även den brittiska handboken för digitala tjänster tillåter en likvärdig nivå. Det enda stället där kravet är strikt är villkoren för anslutning till ett visst nät, och även där är schemat en av flera erkända vägar.

”För att bli CHECK-medlem måste företaget först vara CREST-ackrediterat.” Det var sant för en äldre väg in, och det upprepas fortfarande i leverantörers artiklar, men i schemats nyare standard krävs något annat på företagsnivå. Delvis sant förblir det för personerna, eftersom en CREST-examination kan vara ett av kompetensintygen under det aktuella yrkesnamnet, och precis den skillnaden mellan företagsnivå och personnivå är den som annonserna tiger om.

”Utan CHECK får brittiska statliga system inte testas.” Den juridiska gränsen dras inte av schemat, utan av tillståndet: otillåten åtkomst till ett datorsystem är brott — i Sverige dataintrång enligt brottsbalken kapitel 4, 9 c § — oavsett om testaren är med i ett schema. CHECK är beställarens politik för vem arbetet ska anförtros, inte en ersättning för tillstånd, och de två frågorna är värda att hålla isär. Den praktiska innebörden är att ett skriftligt tillstånd alltid behövs, också när inget schema och ingen författning kräver det uttryckligen.

Vad ett svenskt förfrågningsunderlag egentligen kräver

I Sverige är det först värt att ta reda på var ett sådant krav över huvud taget uppstår, för svaret ligger inte där man vanligen letar: lagen om offentlig upphandling reglerar förfarandet, öppenheten, likabehandlingen och vad som hör hemma i de tekniska specifikationerna, men den namnger inte vare sig penetrationstest, CHECK, ITHC eller PTaaS. Inte heller upphandlingsförordningen, som kompletterar lagen om bland annat annonsering och dokumentation, föreskriver en viss typ av säkerhetskontroll. Det betyder att säkerhetskravet står i underlaget för att beställaren själv har skrivit det — vanligen för att hen själv har en skyldighet som kommer någon annanstans ifrån. Därför är den rätta frågan inte ”vad kräver upphandlingslagen”, utan ”vilken skyldighet har beställaren själv, och förs den över på mig med det här avtalet”.

I Sverige uppstår den skyldigheten genom cybersäkerhetslagen tillsammans med, för statliga myndigheter, MSBFS 2020:7. Cybersäkerhetslagen kapitel 2, 3 § kräver att den som omfattas vidtar säkerhetsåtgärder, bland annat för att bedöma att åtgärderna faktiskt fungerar, men den namnger inte penetrationstest. MSBFS 2020:7 kapitel 4, 11 § kräver att säkerhetstester och granskningar kan identifiera sårbarheter; kapitel 3, 2 § kräver att identifierade brister riskbedöms och hanteras före driftsättning eller en förändring som kan påverka säkerheten. Mer om själva arbetet och dess gränser står i en separat artikel om vad ett penetrationstest är.

I Sverige kvalificeras personer, inte företag

Det är den skillnad som förklarar merparten av missförstånden kring CHECK, och den är inskriven i hur Sverige faktiskt reglerar saken: inte genom ett företagsschema. Cybersäkerhetslagen namnger inte vem som får testa, och MSBFS 2020:7 kräver att myndigheten ser till att säkerhetstester och granskningar kan identifiera sårbarheter, med det allmänna rådet att kombinera automatiserade tester med manuell granskning — fortfarande utan att namnge ett företag eller ett certifikat. När ett svenskt förfrågningsunderlag ändå namnger testare är det beställarens eget krav, formulerat via personen: typiskt ett namngivet certifikat eller dokumenterad erfarenhet, och att personen de senaste åren inte har deltagit i systemets utveckling eller förvaltning.

Om uppdraget inte gäller säkerhetskänslig verksamhet räcker de personkrav beställaren har skrivit, och den extra tröskeln kommer när systemet ingår i säkerhetskänslig verksamhet: då ska den som deltar — också en extern testare — genomgå säkerhetsprövning enligt säkerhetsskyddslagen, med registerkontroll hos Säkerhetspolisen, och först därefter får hen delta. Där finns varken ett företagsschema, ett medlemsregister eller en lista över ackrediterade byråer att ansluta sig till. Sverige har inget eget CHECK att ansluta sig till, och certifikatuppräkningar i underlaget är exempel eller beställarens preferens, inte en sluten laglista. För ett företag som tar fram ett anbud mot ett svenskt underlag betyder det att de namngivna personernas kompetens och oberoende ska kunna visas, inte firmans schemastatus.

Vad du ska lägga in i anbudet

Av att Sverige kvalificerar personen, inte företaget, följer också vad som ska visas i anbudet, och en allmän företagsbeskrivning hjälper inte här; det som hjälper är den konkreta personens certifikat eller erfarenhetsbeskrivning och ett intyg om oberoende från just det här systemets utveckling och förvaltning de senaste åren. Om flera testare ingår i teamet är det värt att namnge vem som uppfyller vilket villkor, för beställaren måste kunna kontrollera det utan att läsa mellan raderna.

Det är också värt att inte missta en exemplista för ett slutet krav, för certifikat som räknas upp i ett svenskt underlag är oftast just exempel, och det betyder att ett annat internationellt erkänt certifikat för penetrationstest uppfyller kravet lika bra, och dokumenterad erfarenhet under senare år är en självständig, likvärdig väg när underlaget tillåter likvärdighet. Ett anbud som förklarar det i ett stycke underlättar utvärderingen mer för beställaren än en hög med certifikatkopior utan förklaring.

Efterlevnadsrevision är inte ett penetrationstest i Sverige heller

Vid sidan av penetrationstestet står efterlevnadsrevisionen, och det är två olika arbeten med två olika måttstockar. Ett penetrationstest söker hur långt en angripare kommer; en efterlevnadsrevision kontrollerar om system och processer uppfyller en norm, och resultatet är ett utlåtande om efterlevnad, inte en lista över tekniska svagheter.

Det syns tydligast just i kvalifikationskraven, som i de två fallen skrivs olika: för den som gör penetrationstest nämns som exempel certifikat som CEH och OSCP, det vill säga certifikat i angreppsteknik; för efterlevnadsrevision nämns helt andra — certifikat i styrning och revision. Om underlaget kräver ett certifikatpaket men beskriver det andra arbetets innehåll är det en motstridighet som är värd att se före anbudet, för den brukar betyda att beställaren själv ännu inte har bestämt sig för vad som köps.

Andra länder har egna instrument

Sverige har inget eget CHECK, men flera europeiska länder har egna svar på samma fråga, och om du läser ett förfrågningsunderlag på ett annat språk vore det lika misstänkt att hitta CHECK där som i ett svenskt. I Frankrike kvalificerar den nationella byrån för informationssystemsäkerhet leverantörer av säkerhetsgranskning, och den kvalifikationen täcker fem granskningsaktiviteter, där penetrationstest är en separat aktivitet vid sidan av granskning av arkitektur, konfiguration, källkod och organisation. Ett franskt underlag brukar därför namnge en konkret aktivitet, inte hela kvalifikationen, och anbudsgivaren måste läsa vilken av de fem som krävs.

I Spanien kräver det nationella säkerhetsschemat en säkerhetsrevision minst vartannat år för system i högre kategori, och de metodiska anvisningarna skiljer där teknisk revision, där teamet faktiskt arbetar med systemet, från efterlevnadsrevision, som vilar på intervjuer och belägg. En efterlevnadsrevision får begära att få se en tidigare rapport från ett penetrationstest, men blir inte själv en sådan. I båda fallen är slutsatsen densamma som i Sverige: namnet tillhör ett visst land, och flyttat till en annan marknad betyder det inte längre något.

Om förfrågningsunderlaget ändå innehåller ”CHECK”

Om CHECK, ITHC eller Cyber Essentials dyker upp i ett svenskt förfrågningsunderlag finns det två trovärdiga förklaringar, och de är värda att skilja åt innan anbudet skrivs. Den första är att beställaren verkligen är en brittisk köpare eller arbetar med ett brittiskt system, och då är kravet äkta, gäller en medlem i schemat och är för de flesta svenska utförare helt enkelt inte möjligt att uppfylla. Den andra — och i praktiken den vanligare — är att specifikationen är hämtad från en engelsk mall, och att den som skrev den inte har märkt att ett annat lands instrument har kopierats med.

De kan skiljas åt utifrån dokumentets övriga innehåll: om det bredvid står hänvisningar till cybersäkerhetslagen eller till MSBFS 2020:7, då handlar det om en svensk skyldighet och CHECK har hamnat där av misstag. Det är värt att ställa som en fråga till beställaren i upphandlingens frågor och svar, inte att gissa i anbudet, för svaret ändrar både priset och om du över huvud taget kan lämna anbud.

Vad ordet ”likvärdig” betyder

I många underlag står förbehållet ”eller likvärdig” bredvid schemanamnet, och det är det viktigaste stycket i hela säkerhetsavsnittet, för just det avgör om du kan lämna anbud. Problemet är att ordet ”likvärdig” sällan är definierat i underlagen, och därför betyder det olika saker beroende på vem som läser.

Praktiskt betyder det att bevisbördan går över på anbudsgivaren: du ska visa i vilket avseende det erbjudna är likvärdigt. Därför är svaret inte ett certifikatnamn, utan en jämförelse punkt för punkt — vem som testar och med vilken kompetens, om funna sårbarheter utnyttjas, vilken omfattningen är, vilken rapportformen är och om det sker omtestning efter rättningar. Om de här punkterna stämmer kan likvärdigheten beskrivas; om så bara en väsentlig skiljer sig är det ärligare att säga det än att hoppas att ingen jämför. Avsaknaden av förbehållet ”eller likvärdig” är lika tydlig åt andra hållet, för ett underlag som kräver ett visst utländskt schema utan alternativ snävar in kretsen av anbudsgivare till ett fåtal företag, och det är en fråga värd att ställa till beställaren innan man utgår från att det inte går att delta.

Hur länge rapporten gäller

Tider i underlagen dyker upp på tre sätt, som kommer från helt olika håll och därför inte kan ersätta varandra: vid anslutning till det brittiska nätet får rapporten inte vara äldre än ett år och den kan inte återanvändas i nästa anslutningsansökan. I Sverige knyter ingen författning giltigheten för en penetrationstestrapport till ett fast antal år; för statliga myndigheter binder MSBFS 2020:7 testerna till driftsättning och till förändringar som kan påverka säkerheten, medan ett kommersiellt avtal helt enkelt har den tid parterna har skrivit, och det betyder att den går att avtala om.

I alla tre fallen räcker inte kalendertiden ensam, för en penetrationstestrapport beskriver ett visst system på ett visst datum, så efter en väsentlig ändring, som en ny integration, ett nytt rollschema eller en ombyggnad av betalflödet, åldras rapporten fortare än tiden gör. Precis därför namnger både författningstider och branschstandarder vanligen också förändringen, vid sidan av intervallet.

Praktiskt betyder det två saker som är värda att skriva var för sig i anbudet. För det första är det värt att klart säga vilken systemversion eller vilken utgåva rapporten gäller, för just det avgör senare en tvist om ett fynd är nytt. För det andra är det värt att avtala separat om omtestning efter rättningar, för ett fynd som är rättat och ett fynd som någon tror är rättat är inte samma sak.

Så läser du kravet innan du skriver anbudet

I praktiken räcker fyra frågor, ställda i en bestämd ordning, för varje nästa är meningsfull bara när den föregående är besvarad. Den första är vilket system som kontrolleras — det som ska levereras eller leverantörens eget, och den enda frågan skiljer Cyber Essentials från allt annat, så det är värt att börja där. Den andra är om kravet namnger utförarens status eller en konkret persons kompetens: status pekar nästan alltid mot ett utländskt schema, medan en namngiven person är den svenska vägen, och det är gränsen mellan ett krav ett svenskt företag kan uppfylla och ett det inte kan. Den tredje är om funna sårbarheter ska utnyttjas, för om de ska det handlar det om penetrationstest, men om en lista över fynd räcker är det skanning, som kostar helt andra pengar. Den fjärde är vilken norm beställaren hänvisar till, och om inte till någon är kravet hens eget val, vilket betyder att omfattningen går att tala om.

Hur det ser ut i praktiken syns bäst i en helt typisk formulering, av det slag som brukar stå i underlaget: ”Anbudsgivaren ska tillhandahålla en säkerhetsgranskning av systemet i enlighet med CHECK eller likvärdig metodik.” Den första frågan svarar genast — det som ska kontrolleras är det system som ska levereras, alltså faller Cyber Essentials bort. Den andra visar att utförarens status är namngiven, och det är ett utländskt schema, medan den tredje blir obesvarad, för ordet ”granskning” säger inte om sårbarheter kommer att utnyttjas. Den fjärde är den avgörande: om det längre fram i dokumentet inte finns någon hänvisning till någon norm är kravet beställarens val, förbehållet ”eller likvärdig” är en öppen dörr, och frågan som ska ställas är bara en — om funna sårbarheter ska utnyttjas. Finns inte svaren på de här frågorna i underlaget är de värda att begära skriftligt, och det är ingen formalitet: ett underlag som namnger ett schema men inte säger omfattningen ger helt inbördes ojämförbara anbud, och det är beställarens, inte anbudsgivarens, förlust.

När det visar sig vara en vanlig säkerhetskontroll av webbplatsen

I en del fall, särskilt i mindre upphandlingar, står ett mycket enklare behov bakom alla de här namnen: beställaren vill veta om hens webbplats eller webbapplikation är säker före driftsättning. Där finns varken ett system som omfattas av cybersäkerhetslagen, ett förvaltningsnät eller ett krav på leveranskedjan — bara viljan att inte släppa ut något i drift som knäcks den första månaden.

Den gränsen är värd att känna igen ärligt också från utförarens sida, inte bara från beställarens. Om underlaget verkligen kräver medlemskap i ett utländskt schema är det rätta svaret att inte delta, eller att delta i partnerskap med den som har medlemskapet — inte att beskriva sin metodik så att den ska se likadan ut, för utvärderingsgruppen märker det, och ryktespriset är högre än en förlorad upphandling.

Just i det här fallet hör vår säkerhetsgranskning hemma, där det också finns rum för manuell kontroll med skriftligt tillstånd. Det är inte CHECK, inte ITHC och ges inte ut för att vara det; det är det arbete som svarar på den fråga som faktiskt ställdes. Har du underlaget på bordet och det inte är klart vilken av de här kategorierna det faller i, skicka säkerhetsavsnittet i specifikationen, så säger vi vilket instrument som är namngivet där — också när svaret är att det inte är ett arbete för oss.