Sikkerhetsstandarder og evaluering

Det finnes mange sikkerhetsstandarder, og mange av disse går det an å sertifisere etter. Når vi sier “sikkerhetsevaluering”, mener vi vanligvis å bruke ISO/IEC 15408, også kjent som Common Criteria. Andre kjente standarder omfatter ISO/IEC 27001, ISF Standard Good Practice, ITIL, og COBIT. Disse fokuserer mer på hvordan organisasjonen er bygget opp (rutiner etc.) enn på hvordan man utvikler programvare.

For det amerikanske markedet er det en del lover som er relevante; spesielt lovene kjent som Sarbanes-Oxley (SOX) og Health Insurance Portability and Accountability Act (HIPAA) for programvare som behandler henholdsvis finansiell informasjon og helseopplysninger (sistnevnte vil sannsynligvis dekkes av GDPR for europeiske markeder). Til slutt kan vi nevne Payment Card Industry Data Security Standard (PCI-DSS) som inneholder detaljerte krav som alle som behandler kredittkortinformasjon (typisk fra de tre store; Eurocard, MasterCard og VISA) må følge.

ISO/IEC 27001

27001 beskriver hvordan man skal bygge opp et Styringssystem for Informasjonssikkerhet (Information Security Management System – ISMS). Denne standarden er en del av 27000-familien, som omfatter standarder om risikoevaluering (27005), hendelseshåndtering (27035) og mye mer. Standarden omfatter tema som organisering av informasjonssikkerhet, retningslinjer, styring av aktiva, personellsikkerhet, fysisk sikkerhet, tilgangskontroll, styring av kommunikasjon og drift, hendelseshåndtering, kontinuitetsstyring, etterlevelse av lover og regler, og anskaffelse, utvikling og vedlikehold av informasjonssystemer.

ISO/IEC 27001 har utgangspunkt i den britiske standarden BS7799, med røtter i bank og finans. Den ble etter hvert vanlig i driftsmiljøer, spesielt i forbindelse med tjenesteutsetting. Begrepet Styringssystem for informasjonssikkerhet (ISMS) henvises til i stadig flere lover og retningslinjer, bl.a. Personopplysningsloven (som etter hvert er overtatt av GDPR), retningslinjer fra Riksrevisjonen, og fra 2014 eForvaltningsforskriftens §15 (enn så lenge representert ved DIFI).

Amerikansk lovgivning

Som nevnt er det primært SOX og HIPAA vi støter på i forbindelse med it-sikkerhet.

Sarbanes-Oxley

Kjært barn har mange navn, men loven kjent bl.a. som Public Company Accounting Reform and Investor Protection Act refereres vanligvis til bare som Sarbanes-Oxley eller SOX. Den ble innført i 2002, i kjølvannet av Enron-skandalen, hvor et selskap med 111 milliarder USD i omsetning gikk overende på kort tid. Det viste seg at det var tvilsom regnskapspraksis, og revisjonsfirmaet Arthur Andersen ble dratt med i dragsuget (konsulentvirksomheten Andersen Consulting lever i dag videre som Accenture). SOX er en føderal lov som revisjonsfirma må forholde seg til, men også alle andre som behandler elektroniske opptegnelser som har med regnskap og liknende omfattes av loven, og ergo må utviklere av denne typen programvare også forholde seg til den.  

SOX skal forhindre at uregelmessigheter slik man så i Enron feies under teppet, bl.a. ved å sørge for logging og revisjonsspor, og forhindre at slike data fjernes eller kommer urettmessige mottakere i hende.

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA stammer fra 1996, og omfatter all programvare som behandler helseopplysninger (de definerer Electronic Protected Health Information), f.eks. elektroniske pasientjournalsystemer. Det er grunn til å tro at det meste av HIPAA vil dekkes av GDPR; det hevdes at hovedforskjellen er fokus, dvs. at GDPR fokuserer på forbrukere  mens HIPAA fokuserer på organisasjoner.  

Payment Card Industry Data Security Standard (PCI-DSS)

PCI-DSS stammer fra bransjeorganisasjonen PCI, og de krever at systemer som skal behandle kredittkorttransaksjoner tilfredsstiller standarden. Standarden kan lastes ned fritt fra https://pcisecuritystandards.org. Det finnes egne dokumenter som detaljerer krav til maskinvareprodusenter, programvareutviklere og leverandører.

PCI-DSS inneholder en del kontrollmål med tilhørende krav:

  • Bygg og vedlikehold et sikkert nettverk
    • Installer og vedlikehold en brannmurkonfigurasjon for å beskytte kortbrukers data
    • Ikke bruk leverandørens standardverdier for passord eller andre sikkerhetsparametre
  • Beskytt kortbrukers data
    • Beskytt lagrede kortbrukerdata
    • Kryptér kortbrukerdata som sendes over åpne, offentlige nett
  • Vedlikehold et sårbarhetshåndteringsprogram
    • Bruk og oppdater jevnlig antivirus programvare på alle systemer som vanligvis påvirkes av skadevare
    • Utvikl og vedlikehold sikre systemer og applikasjoner
  • Implementer sterke aksesskontrolltiltak
    • Behovsprøv tilgang til kortbrukerdata
    • Tildel en unik identifikator til hver person med tilgang til datamaskiner
    • Begrens fysisk tilgang til kortbrukerdata
  • Overvåk og test nettverk jevnlig
    • Spor og overvåk tilgang til nettverksressurser og kortbrukerdata
    • Test sikkerhetssystemer og prosesser jevnlig
  • Vedlikehold informasjonssikkerhetsretningslinjer
    • Vedlikehold retningslinjer (policy) som adresserer informasjonssikkerhet

I tillegg til disse generelle kravene finnes det egne krav som kommer til anvendelse når man skal utvikle betalingskortapplikasjoner, PA-DSS; også disse er primært funksjonelle sikkerhetskrav:

  • PA-DSS krav 1: Ikke behold full informasjon fra magnetspor, kortbekreftelseskode eller verdi (CAV2, CID, CVC2, CVV2), eller PIN blokkdata
  • PA-DSS krav 2: Beskytt lagrede kortbrukerdata (same som PCI-DSS krav 3)
  • PA-DSS krav 3: Tilby sikre autentiseringsegenskaper
  • PA-DSS krav 4: Logg betalingsapplikasjonsaktivitet
  • PA-DSS krav 5: Utvikle sikre betalingsapplikasjoner (ref PCI-DSS krav 6)
  • PA-DSS krav 6: Beskytt trådløse overføringer
  • PA-DSS krav 7: Test betalingsapplikasjoner for å adressere sårbarheter og oppretthold betalingsapplikasjonoppdateringer
  • PA-DSS krav 8: Legg til rette for sikker nettverksimplementasjon
  • PA-DSS krav 9: Data om kortbruker må aldri lagres på en server knyttet til internett
  • PA-DSS krav 10: Legg til rette for sikker fjernaksess til betalingsapplikasjonen
  • PA-DSS krav 11: Kryptér sensitiv trafikk over offentlige nett (ref. PCI-DSS krav 4)
  • PA-DSS krav 12: Sikre all ikke-konsoll administrativ aksess
  • PA-DSS krav 13: Vedlikehold en PA-DSS implementasjonsveiledning for kunder, videreselgere og integratorer
  • PA-DSS krav 14: Tilordn PA-DSS ansvar for personell, og oppretthold opplæringsprogram for personell, kunder, videreselgere og integratorer

Common Criteria – ISO/IEC 15408

Common Criteria kan spore sine aner tilbake til det amerikanske forsvarsdepartementets Trusted Computer Systems Evaluation Criteria (TCSEC) fra 1985, også kjent som «Orange Book» etter fargen på omslaget til den opprinnelige publikasjonen. På begynnelsen av 90-tallet var det mange krefter som mente TCSEC var i ferd med å gå ut på dato, og alternative kriterier ble lansert; ITSEC i Europa (1991), CTCPEC i Canada (1993), og nye føderale kriterier i USA (1993). Med så mange forskjellige kokker var det imidlertid uunngåelig med mye søl, og i 1999 klarte interessentene å bli enig om et omforent sett av kriterier som også ble standardisert av ISO/IEC under navnet «Information technology — Security techniques — Evaluation criteria for IT security».

Med arven fra militæret er det ikke overraskende at det finnes mange forkortelser i Common Criteria, så vi skal dekke de viktigste her:

  • Målet for evalueringen (ToE – Target of Evaluation)
    • Produktet eller systemet som skal evalueres.
  • Beskyttelsesprofil (PP – Protection Profile)
    • Dette er en mal for sikkerhetsmål (ST – se under), og inneholder et sett av generiske men systemspesifikke (for en gitt type system – brannmurer, databaser, etc.) funksjonelle sikkerhetskrav og tiltrokrav. Det finnes forhåndsevaluerte beskyttelsesprofiler som kan spare inn på den totale evalueringstiden dersom de brukes.
  • Sikkerhetsmål (ST – Security Target)
    • Dette er en spesifikk instansiering av beskyttelsesprofil, hvor man konkretiserer sikkerhetsmål og funksjonelle sikkerhetskrav og tiltrokrav. Den representerer et overordnet sikkerhetsmål for systemet, hvor man i utgangspunktet hevder at det tilfredsstiller et visst sikkerhetsnivå.
  • Funksjonelle sikkerhetskrav
    • CC består av en omfattende katalog av funksjonelle sikkerhetskrav som utviklere kan velge blant (eller som er forhåndsvalgt i en gitt beskyttelsesprofil) nå man skal angi ønskede sikkerhetsegenskaper for systemet som skal evalueres.
  • Tiltrokrav (assurance requirements)
    • CC har en tilsvarende katalog med krav som definerer i hvilken grad (og på hvilken måte) de forskjellige funksjonelle sikkerhetskravene har blitt verifisert, testet og kontrollert. Når vi snakker om tiltro her, er det altså hvor stor grad vi har tiltro til at sikkerhetsmekanismene fungerer som tiltenkt. 
  • Evalueringstiltronivå (Evaluation Assurance Level – EAL) 1-7
    • Hvert nivå (EAL) representerer et sett (eller pakke) av tiltrokrav som beskrevet over. I tillegg er det definert mellomnivåer (f.eks. EAL4+).

Common Criteria (funksjonelle) sikkerhetsfunksjoner

Sikkerhetsfunksjoneri CC grupperes i komponenter (enkeltkrav), familier, og klasser. Det er definert 11 klasser av sikkerhetsfunksjonalitet, og hver har sin egen trebokstavsforkortelse:

  • Revisjon (Audit) (FAU)
  • Kryptografisk støtte (FCS)
  • Kommunikasjon (FCO)
  • Beskyttelse av brukerdata (FDP)
  • Sikkerhetsadministrasjon (FMT)
  • Personvern (FPR)
  • Beskyttelse av sikkerhetsfunksjoner til ToE (FPT)
  • Ressursbruk (FRU)
  • Tilgang til ToE (FTA)
  • Tiltrodd sti (Trusted Path)/kanaler(FTP)

Common Criteria tiltroklasser

Tiltrokrav (Security Assurance Requirements – SARs) beskriver tiltak some er utført under utvikling og evaluering av produktet for å sikre etterlevelse av krav og oppfyllelse av påstått sikkerhetsfunksjonalitet. Det er 10 klasser med tiltrokrav:

  • Konfigurasjonsstyring (ACM)
  • Leveranse og drift (ADO)
  • Vedlikehold og tiltro (AMA)
  • Evaluering av beskyttelsesprofil (PP) (APE)
  • Utvikling (ADV)
  • Veiledningsdokumenter (AGD)
  • Livssyklusstøtte
  • Evaluering av sikkerhetsmål (ST) (ASE)
  • Tester (ATE)
  • Sårbarhetsvurdering (AVA)

CC evalueringstitronivåer (EALer)

EAL-nummeret er en snarvei til å beskrive dybden og grundigheten til en evaluering. Hver EAL korresponderer til en pakke med tiltrokrav (SAR) som dekker hele utviklingsprosessen til et produkt, med et gitt nivå av strenghet. Tekstlig kan vi beskrive nivåene som følger:

  • EAL1 – Funksjonelt testet
  • EAL2 – Strukturert testet
  • EAL3 – Metodisk testet og sjekket
  • EAL4 – Metodisk utviklet, testet og gjennomgått
  • EAL5 – Semiformelt utviklet og testet
  • EAL6 – Semiformelt verifisert design og testet
  • EAL7 – Formelt verifisert design og testet

Common Evaluation Methodology (CEM)

CEM spesifiserer handlinger og aktiviteter som skal utføres av en evaluator, og er ment å sikre en konsistent anvendelse av CC-kravene på tvers av flere evalueringer og flere evalueringsregimer. CEM angir retningslinjer for hvordan man skal utføre en PP-evaluering og ST-evaluering. CEM omfatter p.t. kun evaluering opp til EAL4.

Sertifisering iht. Common Criteria

CC er verdensomspennende, og har en styringskomite som består av representanter fra alle land som er med i ordningen. Deltakerne som har signert Common Criteria Recognition Agreement (CCRA) bade konsumerer sertifiseringer og autoriserer sertifiseringer. Selve sertifiseringene gjøres av sertifiseringsorganet, som i Norge er SERTIT (www.sertit.no – en del av NSM). Sertifiseringsorganet har ansvaret for tilsynet med sertifiseringsregimet.  Sikkerhetsevaluering utføres som regel av et akkreditert evaluatorfirma (EVIT). Det er for tiden fire firma som er godkjent for å utføre sikkerhetsevalueringer i det norske evalueringsregimet:

  • Norconsult AS
  • Brightsight BV
  • Advanced Data Security
  • System Sikkerhet AS

Sistenevnte er et relativt nyopprettet selskap som har sikret seg rettighetene til navnet på det første uavhengige evaluatorfirmaet i Norge – den gang opprettet i 1986 på Longum Park i Arendal. Det nye firmaet ble opprettet i 2016.

Det er evaluert flere systemer i Norge de siste årene; det dreier seg overveiende om forskjellige kommunikasjonsløsninger for det norske forsvaret levert av firma som Thales og Kongsberg.