Brannmurer er fortsatt teite

Det har kommet noen kommentarer i løpet av de to siste årene på artikkelen jeg skrev om hvorfor brannmurer er teite.

De aller fleste kommentarene er av typen ‘tosk’ eller ‘du kan jo bare ikke si sånn’, eller til og med, min favoritt, ‘jammen, jeg har jo en usikker server og trenger en brannmur så da er jo hele artikkelen din meningsløs’. Til disse kan jeg bare si et rungende ‘brenn i helvete, avskum’.

Noen kommentarer er derimot både konstruktive og lærerike. Jeg er her for å lære så derfor vil jeg også gjerne presentere disse meningene og mine tilsvar.

Av hensyn til artikkellengde så deler jeg kommentarer og tilsvar i flere artikler.

Defense-in-depth
Det har vært en del som reagerer på at jeg har argumentert mot defense-in-depth, ved at jeg sier at mer programvare øker kompleksiteten og sannsynligheten for kompromitterende feil.

For de som ikke er teknisk oppdatert er filosofien bak defense-in-depth at man har flere lag med sikkerhet, for eksempel ved å ha autentisering som både krever nøkkelbrikke eller smartkort i tillegg til brukernavn og passord, ha brannmurer, manuell tilgangskontroll, etc. Ved å kombinere flere slike tiltak og legge dem over hverandre må man klare å komme seg gjennom alle lagene med sikkerhet for å kompromittere et system.

For eksempel så hjelper det ikke å få tak i et brukernavn og passord, du må fortsatt ha nøkkelbrikken, og om du får tak i den også må du fortsatt komme gjennom brannmuren som kanskje filtrerer på avsenderadresse, og selv om du også klarer det kan det fortsatt være en manuell kontroll av alle innkommende forbindelser før man faktisk får tilgang til ressurser.

Jeg er på generell basis en tilhenger av defense-in-depth der det er nødvendig. For adgangskontroll vil det være nyttig i de tilfellene der ett av nivåene blir sikkerhetsmessig kompromittert. Om en brannmuradministrator er uærlig vil vedkommende fortsatt ikke kunne dele ut nøkkelbrikker eller forestå den manuelle kontrollen av inngående forbindelser.

Det er derimot slik at i mange tilfeller så skaper man også nye problemer der man fjerner de eksisterende problemene. Man løser problemet med sikkerhetsmessig kompromittering av et lag, men introduserer et problem dersom man ikke separerer admininstratorrollene i nettet. Om én person er ansvarlig for eller har muligheten til å dele ut og godkjenne brikker, konfigurere brannmuren og godkjenne inngående forbindelser så har ma bare lagt sikkerhetsproblemet på kredibiliteten til vedkommende administrator. Så lenge vedkommende er ærlig og fornøyd og får det vedkommende vil ha så er du trygg, men forsøk å be vedkommende jobbe mer overtid, inndra firmabil eller nekte lønnsøkningen, så har du plutselig skapt et problem som kan være vesentlig mer alvorlig enn om en brukerkonto med begrensede rettigheter blir kompromittert.

Når jeg i forrige post nevnte at introduksjon av potensielle programvare- eller funksjonalitetsfeil er et argument mot defense-in-depth så må dette ikke forstås som at jeg er motstander av å ha flere lag med sikkerhet. Tvert om, defense-in-depth er en nødvendighet for å unngå at én enkelt kompromittering skaper problemer i hele nettverket.

Defence-in-depth er kun et sikkerhetsmoment om lagene håndteres som om de representerer det eneste laget med sikkerhet. Hvert lag må isoleres, sikres og overvåkes som om en kompromittering vil ta ned all sikkerhet i nettverket. Dette inkluderer isolering av brukernavn og passord, påloggingsrettigheter og annet som kan brukes for å kompromittere eller administrere laget. Dersom ett lag blir kompromittert skal ikke informasjon fra dette laget kunne brukes for å kompromittere øvrige lag. Om dette er mulig har man ikke defense-in-depth, men et mer komplekst enkelt lag.

Dermed kommer man tilbake til hvorfor defense-in-depth ikke er et alternativ til å sikre hvert element, og igjen, hvorfor brannmurer ikke er en løsning på dårlig sikrede nettverk. Det hjelper lite om du har en perfekt brannmur dersom brukernavn og passord på brannmuren er det samme som brukes andre steder i nettverket, eller om den eller de som styrer brannmuren også er den eller de som sikrer de andre elementene i nettverksforsvaret.

Igjen, defense-in-depth, flerlagsforsvar, er kun en sikkerhetsmetode dersom hvert lag er sikkert i seg selv. Det medfører vesentlig ressursbruk å ha flere slike lag og dersom lagene andre steder fortsatt er usikre så er det trolig bedre å prioritere sikringstiltak der enn å legge på flere lag over eller under.

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It