Krav ved kjøp av NGFW

Tematikk:

Det er mange gode brannmur produsenter og produkter, og flere er oppe til høyre i Gartners Magic Quadrant. Å velge brannmur er ikke enkelt. Men det er veldig viktig å være bevisst på hva man trenger en brannmur til, for en brannmur er ikke en brannmur, de er forskjellige og kan forskjellige ting.

Det poengteres hele tiden viktigheten av bestillerkompetanse Derfor får dere denne kravlisten opp mot Nasjonal sikkerhetsmyndighets IKT-sikkerhet som kan benyttes når man skal kjøpe ny brannmur.

RFP krav ved NGFW forespørsel I tråd med NSM Grunnprinsipper for IKT-sikkerhet

IKT-sikkerhet er viktig, det vet alle i disse digitaliseringstider. Det er derfor viktig å se etter løsninger som bidrar til en helhetlig og god IKT-sikkerhet. Her er en liste over krav du burde stille til brannmuren din, enten det er snakk om å optimalisere den du allerede har, eller å gå til anskaffelse av en ny – i håp om at det vil hjelpe markedet med bestillerkompetanse og kompetanseheving for bedre sikkerhet.

Nasjonal Sikkerhetsmyndighet sine Grunnprinsipper for IKT-sikkerhet

Nasjonal Sikkerhetsmyndighet har utarbeidet sine Grunnprinsipper for IKT-sikkerhet som hjelp til alle i arbeidet med helhetlig sikkerhet. I tråd med disse, har du her et forslag til en RFP kravliste. Denne tar med seg alle elementene et foretak burde ha med i sitt arbeid for helhetlig IKT-sikkerhet. Håpet er at dette vil hjelpe offentlige og private foretak på veien mot etterlevelse av NSM Grunnprinsipper for IKT-sikkerhet.

Generelle RFP krav for anskaffelse av en segmenterings gateway

Verden er i stadig utvikling og evolusjonen stopper ikke. Derfor eksisterer det mange løsninger der ute som mange nok ikke er klar over egenskapene til. Det er derfor viktig å synliggjøre elementer man mener markedet burde være klar over, og da eventuelt ta med i sin kravspesifikasjon. Det er derfor laget et eget kapittel for tilleggsspørsmål man kan ta med.

NSM Grunnprinsipper for IKT-sikkerhet

1. Identifisere og kartlegge

1.1 Kartlegg styringsstrukturer, leveranser og understøttende systemer

  • N/A

1.2 Kartlegg enheter og programvare

  • Løsningen skal være i stand til automatisk gruppere servere basert på operativsystem, med den muligheten å kunne gjøre egen sikkerhet for servere med f.eks. utdatert operativsystem. Dette være seg begrensede tilganger etc. (1.2.1)
  • Løsningen skal kunne identifisere operativsystem og tilstand på endepunkter, som om brannmur er aktivert, samt om systemet er oppdatert, for på den måten å styre tilganger basert på om de tilfredsstiller kravene (1.2).
  • Løsningen skal være i stand til å verifisere om endepunktet er medlem av AD domenet før tilgang kan gis til kritiske tjenester (1.2).
  • Løsningen skal være i stand til å kommunisere med infrastrukturteknologien via API eller lignende, for på den måten å være i stand til dynamisk tilgangskontroll basert på fra eks. 802.1x (1.2.3).

1.3 Kartlegg brukere og behov for tilgang

  • Løsningen skal kunne integreres med Active Directory, for uthenting av brukernavn og gruppenavn, for at dette skal benyttes i regelsett for tilgangskontroll (1.3).
  • Løsningen skal kunne ha tilgangskontroll på Active Directory gruppenivå, men også Active Directory brukernivå. Dette skal ikke være basert på IP-adresse, men integrasjon med Active Directory (1.3).

2. Beskytte og opprettholde

2.1 Ivareta sikkerhet i anskaffelses- og utviklingsprosesser

  • Løsningen skal dokumenteres å være supportert i minimum 5 år (2.1.2).
  • Vis til sertifiseringer, som Common Criteria eller lignende (2.1.3).

2.2 Etabler en sikker IKT-arkitektur

  • Løsningen skal ha mulighet for styring av tilgang til ressurser og tjenester, med applikasjon og brukerkontroll, ved hjelp av integrasjon med Active Directory eller tilsvarende, og hvitelisting av kommunikasjonen. Vis til referansekunder (2.2.1).
  • Aksesskontroll og tilgang skal kunne gjøres fra et sentralt administrasjonspunkt, med mulighet for distribuering til mange enheter (2.2.1).
  • Løsningen skal ha mulighet for tilgangskontroll basert på programvare på klient (2.2.1 og 2.2.6).
  • Løsningen skal kunne sjekke operativsystemet på klienten før tilgang gis (2.2.1).
  • Løsningen skal kunne detektere og stoppe skadevare, selv om denne måtte befinne seg i kryptert kommunikasjon, noe som krever SSL/TLS dekryptering av all kommunikasjon hele tiden. Vis til referansekunder (2.2.1).
  • Løsningen skal inneha Intrusion Detection System/Intrusion Prevention System (IDS/IPS), selv også for kryptert kommunikasjon, som vil kreve SSL/TLS dekryptering av all kommunikasjon hele tiden. Vis til referansekunder (2.2.1).
  • Løsningen må kunne automatiseres, ved bl.a. API-integrasjon med eksterne systemer, både inngående og utgående, slik at løsningen kan trigge endringer på et annet system, eller at et annet system kan gjøre endringer i tilganger på sikkerhetsløsningen (2.2.1).
  • Løsningen skal kunne tilby samme synlighet og kontroll “on-prem” og i “skyen/ IaaS)”, med de samme funksjonene, administrert fra et og samme sted (2.2.2).
  • Segmentering av nettverket er en viktig anbefaling fra NSM, både i S-03 og Grunnprinsippene 2.2.3. Sikkerhetsløsningen skal være bygget for å være det sentrale punktet i kommunikasjon, for å kunne se all kommunikasjon foretakets policy har sagt skal ses igjennom en sikkerhetsbarriere. Dette betyr at man kan oppleve en konfigurasjon med over 100 sikkerhetssoner som skal kontrolleres med tanke på tilganger, synlighet, inspeksjon, logging og kontroll (2.2.3).
  • Sikkerhetsløsningen skal kunne gjøre tilgangskontroll mellom segmenter og soner, om disse er skilt med VLAN, virtualiserte nettverk eller mikrosegmentering. Vis eksempler. Alt skal kunne administreres fra et grensesnitt. Vis til referansekunder som benytter forskjellige segmenteringsmetoder (2.2.3).
  • Sikkerhetsløsningen skal være i stand til å gjøre forskjell på tilganger basert på om en bruker kommer inn med en ikke-forvaltet enhet enn en forvaltet enhet (2.2.6).

2.3 Ivareta en sikker konfigurasjon

  • Løsningen skal ha dynamiske sikkerhetsoppdateringer så ofte som mulig, helst realtime, for å kunne detektere IOC’er så raskt som mulig (2.3.1).
  • Løsningen skal være i stand til å dynamisk isolere servere som ikke tilfredsstiller krav om oppdateringer, kan være et utdatert operativsystem som Windows Server 2008 (2.3.1).
  • Løsningen må ha en mekanisme for regelmessig revisjon sett opp mot å ikke bruke uønsket funksjonalitet, eller utdaterte protokoller etc. (2.3.3).
  • Løsningen skal være i stand til å gjenkjenne uønskede skytjenester, og eventuelt stoppe disse. Shadow IT (2.3.3).
  • Løsningen skal enkelt og regelmessig kunne verifiseres mot et sett med anbefalinger fra produsenten. Dette skal helst skje automatisk, og vises med brukervennlige grafiske grensesnitt som et verktøy for å forbedre konfigurasjonen (2.3.4)
  • Løsningen skal ha personlige administratorbrukere, med forskjellige tilgangsnivåer. RBAC, Role Based Access Control (2.3.5)
  • Løsningen skal ha personlige administratorbrukere, med forskjellige tilgangsnivåer. Role Based Access Control (RBAC) (2.3.5).
  • Løsningen skal ha personlige administratorbrukere, hentet fra Active Directory, eller tilsvarende (2.3.5).
  • Administratorer skal logge på med 2 faktor autentisering (2.3.5).
  • Løsningen skal kunne benytte offentlige TLS sertifikater på management grensesnitt (2.3.6)
  • Løsningen skal kunne kontrollere alle enheters kommunikasjon med Network Time Protocol (NTP) server, for å sikre at det kun skjer mot ønskede leverandører.
  • Løsningen skal kunne endre en enhets destinasjonsadresse for NTP-server, til ønsket NTP-server for å sikre lik tid på alle enheter (2.3.9).
  • Løsningen skal kunne identifisere IoT-enheter, og gjøre tilgangskontroll til og fra disse. Det er like viktig å kunne kontrollere initiert kommunikasjon begge veier. Forklar hvordan dette gjøres (2.3.10).

2.4 Beskytt virksomhetens nettverk

  • Tilgangskontroll skal gjøres sammen med verifikasjon av enhet, for å kunne skille på en forvaltet og ikke-forvaltet enhet (2.4.1).

2.5 Kontroller dataflyt

  • Løsningen skal hviteliste kommunikasjon mellom nettverkssoner (segmentering gjort av VLAN, virtualisering eller mikrosegmentering) basert på IP, soner, applikasjoner, brukere, tilstand på enhet (forvaltet/ikke-forvaltet, er brannmur ok, er endepunktsikring ok) (2.5.1).
  • Alle regler skal inneha beskrivelse som sier hvorfor regelen eksisterer, hva den gjør, og vise til et saksnummer for mer dokumentasjon (2.5.1).
  • Alle reglene skal ha en integrert endringslogg for logging av alle endringer gjort på regelen (2.5.1).
  • Løsningen skal kunne ha en integrering med sentralt arkivsystem, for oversending av endringslogger, via API, syslog, eller lignende (2.5.1).
  • Løsningen skal være i stand til å kun tillate/gi forvaltede enheter tilgang til kritiske applikasjoner og løsninger (2.5.2).
  • Aksesskontroll skal gjøres med minste privilegiums prinsipp. Det betyr at tilgang skal gjøres basert på hvorfor man skal ha tilgang, hvem man er, hvor man kommer fra, hvor man skal, hva man skal gjøre, når man skal gjøre det og hvordan man skal gjøre det (2.5.2).
  • Løsningen skal være i stand til å dynamisk gruppere servere med utdaterte operativsystem, og begrense tilgang til og fra disse enhetene (2.5.4).
  • Løsningen skal benytte applikasjonskontroll som kontrollmekanisme for tilgang til kritiske tjenester (2.5.6).
  • Løsningen skal kunne dekryptere all kommunikasjon mot interne tjenester, for tilgangskontroll (2.5.6).
  • Forvaltede mobile enheter skal alltid gå via foretakets sikkerhetsmekanismer, for full synlighet, kontroll og sikkerhet, uansett hvor de måtte befinne seg (2.5.8).

2.6 Ha kontroll på identiteter og tilganger

  • Tilgangsstyring til tjenester skal inneholde brukerkontroll opp mot f.eks. en Active Directory gruppe definert til den gitte oppgaven (2.6.4).
  • Tilgangsstyring til tjenester skal kunne gjøres med Multi Factor Authentication i nettverket, dersom dette ikke støttes av applikasjonen eller tjenesten (2.6.7)

2.7 Beskytt data i ro og i transitt

  • N/A

2.8 Beskytt e-post og nettleser

  • N/A

2.9 Etabler evne til gjenoppretting av data

  • Løsningen skal inneha automatikk for regelmessig backup av konfigurasjon, både av brannmur men også av sentralt management (2.9.1).

2.10 Integrer sikkerhet i prosess for endringshåndtering

  • Regler skal inneha et beskrivelsesfelt (2.10.1)
  • Regler skal inneha en endringslogg (2.10.1)
  • Løsningen skal ha et kommentarfelt med endringslogg ved endring av konfigurasjon (2.10.1)
  • Løsningen skal inneha integrasjonsmuligheter med et arkivsystem for endringslogger (2.10.1)

3. Oppdage

3.1 Oppdag og fjern kjente sårbarheter og trusler

  • Løsningen skal være i stand til å sjekke innhold av all kommunikasjon, hele tiden, for alle applikasjoner, på alle porter, selv om denne kommunikasjonen er kryptert. Dette betyr at kommunikasjon må kunne dekrypteres, og deretter inspiseres med flere lag med inspeksjon og sikkerhet, som Anti Virus, IDS/IPS, URL-filtrering, Anti Spyware, og sandkasseemulering av ukjent kode (3.1.3).

3.2 Etabler sikkerhetsovervåkning

  • Løsningen skal være i stand til å dekryptere all kryptert kommunikasjon, utgående, inngående og internt, for å skape best mulig synlighet, muliggjøre best mulig deteksjon og best mulig logging (3.2).
  • Løsningen skal inneha funksjoner for “Network Detection and Response”, som betyr detaljerte logger, som kan berike et analyseverktøy tenkt for å avdekke unormal adferd og som igjen kan avdekke skadelige hendelser så tidlig som mulig (3.2).
  • Løsningen skal kunne innhente detaljert DNS- og DHCP-kommunikasjon som et ledd i berikelse av analyseverktøy (3.2).
  • Løsningen skal kunne innhente detaljerte HTTP header data for berikelse av analyseverktøy. Dette vil kreve SSL/TLS dekryptering (3.2).
  • Løsningen skal hele tiden sjekke all kommunikasjon, for alle IP-adresser, for alle porter, med alle sikkerhetsmekanismer. Man skal alltid være i stand til å se hvilken applikasjon som kommuniserer (noe som ofte krever SSL/TLS dekryptering). Man skal se eventuelle virus, misbruk av sårbarheter, command & control kommunikasjon, samt all URL-kommunikasjon også når kommunikasjonen er kryptert (noe som vil kreve SSL/TLS dekryptering). Man skal også se hvilke filtyper som passerer, og være i stand til å selektivt kontrollere tilgang for disse per tilgang (dette vil også ofte kreve SSL/TLS dekryptering)

3.3 Analyser data fra sikkerhetsovervåkning

  • Løsningen skal kunne fungere som en logg og datainnsamlingsenhet for en sentral analyseplattform. Hva slags data kan hentes ut i tillegg til standard logger og alarmer, som IP, port, applikasjon, bruker, virus, sårbarhet, etc.? (3.3.1)
  • Løsningen skal kunne fungere sammen med en analyseplattform som danner et bilde av normaltilstanden i nettverket basert på innsamling av logger og alarmer fra multiple kilder, og skal dermed kunne alarmere avvik fra normalen (3.3.2).
  • Løsningen skal være i stand til å automatisk innhente lister med IOC’er fra f.eks. myndigheter for mitigering av hendelser relatert til funn gjort av forskjellige sikkerhetsenheter (3.3.4).
  • Løsningen skal være i stand til å automatisk opprette en supportsak dersom en viss hendelse skjer. Dette kan skje via API, SMTP, SNMP eller lignende. Dette er viktig for at oppmerksomhet skal gis så raskt som mulig ved en hendelse, men ikke minst også dokumentasjon av hendelsen og arbeidet rundt den (3.3.6).
  • Løsningen skal inneha mekanismer for å avdekke ukjente trusler og unormaliteter (3.3.7).

3.4 Gjennomfør inntrengningstester

  • Løsningen skal automatisk og regelmessig kunne revideres for å avdekke svakheter i regelsettet og konfigurasjonen ellers, som kan bidra til sikkerhetshull og sårbarheter (3.4)

4. Håndtere og gjenopprette

  • N/A

Generelle RFP-krav for anskaffelse av en segmenterings gateway

Compliance. Det skal være mulig å sette krav i konfigurasjon om endringskommentar når man gjør endring i regelsettet, samt at dette logges til et sentralt arkiv, via SNMP, Syslog eller API, for å unngå muligheten for endringer uten dokumentasjon.

  • Vis til referansekunder som bruker dette i produksjon.

Compliance. Sikkerhetshendelser som møter kritiske krav, skal kunne sendes til bedriftens sakshåndteringssystem via API, eller lignende, for dokumentasjon, samt automatisk opprettelse av en sak for synlighet og at noen får en oppgave med å undersøke saken.

  • Vis til referansekunder som bruker dette i produksjon.

Compliance/sikkerhet. Løsningen skal som en del av tilgangskontrollen kunne validere tilstand på endepunktet, og gi tilgang bare dersom krav til endepunktet er tilfredsstilt, som at AntiVirus er OK, at brannmur er ok, at Windows Update er OK, at visse prosesser kjører, og lignende.

  • Vis til referansekunder som bruker dette i produksjon.

Compliance/sikkerhet. Det skal være mulig å se:

  • Hvilke regler som ikke er i bruk, og kan fjernes for god hygiene, og for å redusere angrepsflate og risiko.
  • Hvilke regler som ikke har applikasjoner spesifisert, og deretter se hvilke applikasjoner som har gått igjennom regelen, for å kunne bygge et hvitelistbasert applikasjonsregelsett. Dette for å ha god sikkerhetshygiene, redusere angrepsflate og risiko mest mulig.
  • Hvilke applikasjoner det er åpent for, som ikke har vært i bruk i en gitt periode, som f.eks siste 30 dager, 90 dager eller noensinne, for på den måten ha god hygiene ved at man regelmessig kan fjerne unødvendige åpninger, og slik holde angrepsflaten så liten som mulig, og dermed redusere risikoen mest mulig.

Compliance/sikkerhet. I tråd med NSM er Best Practice viktig. Leverandøren skal ha etablerte rutiner og verktøy for automatiske Best Practice kontroller, for kontinuerlig forbedringsarbeid, for best sikkerhets hygiene.

  • Vis til referansekunder som bruker dette i produksjon.

Compliance/sikkerhet. I tråd med NSM sine veiledninger, må man ha synlighet på sin hardware. Det er derfor spesielt viktig at å se all IoT- og OT-teknologi i nettverket, da dette ofte går under radaren.

Compliance/sikkerhet. Det er viktig med synlighet på alle SaaS-applikasjoner som går igjennom løsningen, for på den måten å kunne adressere Shadow IT utfordringen. Deretter er det viktig å kunne gjøre tilgangskontroll, samt DLP på innholdet. Forklar innebygget funksjonalitet, synlighet, rapportering og kontroll.

Sikkerhet. I tråd med Cyber Kill Chain er det viktig å adressere punkt 6, Command & Control. VG testen er beskrevet i denne artikkelen.

  • Vis til referansekunder som bruker dette i produksjon.
  • Forklar hvordan dette adresseres og hvor mye tid man må beregne for å implementere dette.

Sikkerhet. Løsningen må ha full synlighet på alle filer som traverserer, samt kunne gjøre tilgangskontroll for filtyper, per regel. Kravet er at all eksekverbar kode skal sperres, men at man kan gjøre unntak for bruker, applikasjon og destinasjon/URL.

  • Vis til referansekunder som bruker dette i produksjon.

Sikkerhet. I tråd med NSM S-03 sine anbefalinger om segmentering og tilgangskontroll med hvitelisting av applikasjoner, skal løsningen leveres for hvitelistet applikasjons-kontroll sammen med brukerkontroll.

  • Vis til referansekunder som bruker dette i produksjon.

Sikkerhet. Løsningen må kunne sjekke alle DNS-forespørsler, uansett hvilken DNSserver klienten kommuniserer med, være seg administrert PC, servere, BYOD, IoT, OT eller kompromitterte klienter med manipulerte DNS innstillinger. Løsningen må umiddelbart kunne gi svar på om forespørselen er skadelig, for på den måten ha mulighet til å hindre besvarelse. Om løsningen identifiserer uønskede DNS-forespørsler, skal klientkommunikasjon sendes til en gitt IP-adresse for analyse av kommunikasjonen.

  • Vis til referansekunder som bruker dette i produksjon. Sikkerhet. I tråd med NSM sine anbefalinger om sikker tilgangskontroll, ønsker vi Multi-Factor Authentication (MFA) for våre mest kritiske systemer. Løsningen skal ha mulighet for å kreve MFA i nettverket, for tilgang til gamle løsninger, som servere, applikasjoner, tjenester, som ikke har gode nok autentiseringsløsninger. Dette kan være forskjellige løsninger, som web, SSH, RDP, osv.
  • Vis til referansekunder som bruker dette i produksjon.

Sikkerhet. Brannmuren skal være en del av et helhetlig økosystem fra leverandøren, som muliggjør informasjonsdeling mellom forskjellige teknologier, som endepunkt, nettverk, sky og SaaS. Den helhetlige løsningen skal også ha muligheten for å ta imot alle logger og alarmer, samt detaljerte data, for adferdsdeteksjon, da suksessfulle hendelser skjer i tillatt trafikk, og man må analysere denne kontinuerlig, med korrelering av data fra brannmurer, endepunktsikkerhet, skysikkerhet, Windows logger, samt 3. parts logger.

  • Vis til referansekunder som bruker dette i produksjon.

Sikkerhet. Det skal være mulig å identifisere brukere før adgang til tjenester, basert på AD, Syslog, API, Portal, Agenter samt MFA.

  • Vis til referansekunder som bruker dette i produksjon.

Sikkerhet. Løsningen skal ha en innebygget løsning for mobile brukere, uansett operativsystem (Windows, Mac, Linux, Android, iOS og Google Chrome) som muliggjør at de ansatte kan jobbe hvor som helst, og ikke merke noen forskjell.

  • Løsningen skal fungere automatisert, uten at brukeren merker noe.
  • Den ansattes enhet skal alltid være tilkoblet bedriftens sikkerhetsløsninger, for full synlighet og kontroll. Basert på applikasjon og brukerkontroll, vil sikkerheten være den samme som om de skulle være på kontoret.
  • Den ansattes enhet skal kunne kobles til bedriftens nettverk og domene før den ansatte logger på, slik at login script kan kjøres, samt at passordoppdateringer fungerer som om man er på kontoret.
  • Løsningen skal kunne skille ut tjenester man ikke trenger å sende via kontoret, som f.eks. SaaS-løsninger som Office 365 og videoløsninger slik at disse går ut direkte på internett fra klienten, istedenfor via bedriftens sikkerhetsløsninger.

Sikkerhet. Det er viktig at alle IPS-signaturer til enhver tid er aktive. Bedriften ønsker ikke å vedlikeholde IPS basert på hvilken teknologi som til enhver tid eksisterer i nettverket.

  • Vis til referansekunder som bruker dette i produksjon.

Sikkerhet. Det skal være mulig å styre tilgang basert på nivå av kryptering, som at bare sesjoner med TLS 1.2 og oppover skal tillates.

Sikkerhet. SSL/TLS dekryptering for utgående kontroll, samt inngående kontroll, som er to forskjellige funksjoner. Det er også viktig å kunne differensiere på kjent og ikke kjent sertifikatutsteder for destinasjonene man går mot, for god brukeropplevelse. Også viktig med policy som bestemmer om en bruker skal få besøke en destinasjon som ikke har kjent sertifikatutsteder, har et sertifikat som har gått ut på dato eller har et navn som ikke stemmer med opprinnelig forespørsel. Det er minst like viktig å kunne kontrollere krypteringsversjon og algoritmer, for å kunne stoppe uønskede situasjoner.

  • For inngående SSL/TLS dekryptering mot kundens tjenester, er det viktig å kunne legge inn sikkerhetsregler for nivået på kryptering som skal eksistere før tilgang gis. Løsningen må være i stand til å dekryptere TLS 1.3.
  • Løsningen må være i stand til å dekryptere TLS 1.3.
  • Vis til referansekunder som benytter begge elementer, både inngående og utgående SSL/TLS dekryptering.

Sikkerhet. Det skal være mulig å kontrollere SSL sertifikater selv uten dekryptering, for å detektere og stoppe sertifikater som har gått ut på dato, eller utgitt av ukjent usteder.

Sikkerhet/oppetid. Løsningen skal ha innebygget DoS-beskyttelse, både per sone/ interface, men også granulære DoS-regler per server.

API. Alle funksjoner i CLI og GUI skal være tilgjengelige via API, både på fysisk brannmur, virtuell brannmur for ACI og NSX, virtuell brannmur for IaaS og for sentral management løsning. API er det aller viktigste kravet i alle løsninger man kjøper i moderne tid, for integrasjon, automasjon, effektivisering og ikke minst sikkerhet.

Funksjonalitet. Løsningen skal kunne være knyttet til ACI, NSX, VMware og IaaS for dynamisk oppdatering av servertilstand og IP-adresser, basert på attributter som operativ system og tags.

Gøran Tømte

Gøran Tømte

Gøran har jobbet i bransjen siden 1996 og trives best med ukjente utfordringer. Er utdannet høgskole ingeniør innen telematikk, og kontinuerlig selvlært innen sikkerhet basert på gode kollegaer, bransjen og generell nysgjerrighet og interesse

KONTAKT

Andre artikler

Stay Connected

More Updates

Krav ved kjøp av NGFW

Det er mange gode brannmur produsenter og produkter, og flere er oppe til høyre i Gartners Magic Quadrant. Å velge brannmur er ikke enkelt. Men

Leverandørkontroller

Viktigheten av kontroller ved tjenesteutsetting/kjøp av tjenester “Alle” tjenesteutsetter/kjøper tjenester. Men hvordan verifiseres og risikovurderes dette? Som kunde har man alltid 100% ansvar for sikkerheten,

Krav ved kjøp av NGFW

Facebook
Twitter
LinkedIn

More to explorer

Least Privilege policy

Dagens trusselbilde er brutalt. Internett er stort. Løsninger er kompliserte. Sårbarhetene og nulldagssårbarhetene florerer. Dette er grunnen til min hovedoppgave ute i