Jeg har flere år bag mig som it-sikkerhedsrådgiver, og jeg ser gang på gang, at der primært fokuseres på skalsikring - altså fokus på perimeteren.
Selv i it-revisionsrapporter kan man stadig finde argumenter som "da serveren ikke har adgang til internettet, ses det ikke som værende en risiko". Her er det altså de personer, som virksomhedslederne lytter til, der endnu ikke har indstillet sig på den virkelighed, som findes.
Det er som om, at vores mentalitet er blevet tilbage i middelalderen. Hvis man dengang havde en kiste med guld i, byggede man en stor mur omkring den for at beskytte den.
Men man havde stadig samme problem, som man har i nutidens it-systemer. Når en angriber kommer igennem muren, mister man hele kisten med guld. Det gav god mening dengang, men i dag er det altså muligt at beskytte hver enkelt guldmønt for sig.
Hvis en angriber kommer ind, kan han altså kun stjæle den enkelte mønt, som han har fundet vej til.
Hele begrebet "Assume Breach" betyder, at der allerede er noget ondsindet på vores netværk, og at det ikke er nok at beskytte perimeteren af ens it-miljø. Vi skal altså forsvare os internt.
I teorien kan en angriber befinde sig på et hvert tænkeligt sted i ens netværk.
For at nævne nogle eksempler kan dette være laptops tilhørende almindelige brugere, eksterne konsulenter, udviklere eller administratorer som er kompromitteret. Det kan også være web-, fil-, log- eller mailservere. Udviklingsmiljøer eller produktionsmiljøer. Altså samtlige tænkelige steder kan være kompromitteret. Det er derfor ekstremt vigtigt at beskytte sig mod samtlige steder på ens interne netværk.
Hvordan gør man det? ... her er fem gode kontroller, man bør have på plads:
De fem gode kontroller
Der findes mange sikkerhedsframeworks og standarder, som kan benyttes til inspiration. Her kan nævnes ISO27002, Critical Security Controls, PCI-standarden og andre, der har ganske fornuftige kontroller, som virksomheder med fordel kan implementere for at beskytte sig mod de angribere, der allerede har et fodfæste på ens netværk.
Her er nogle af de kontroller, som jeg ser som nødvendige at implementere for at mindske risikoen for, at en angriber får adgang til vores systemer. Dette er dog på ingen måder en komplet liste.
• Baseline-konfigurationer
• Hostbaserede firewalls
• Segmentering/isolering
• Password-sikkerhed
• Rapportering/review/test
Det er vigtigt at påpege, at virksomheder bør tilpasse kontrollerne til sin egen virkelighed. Det kan derfor være, at der er behov for yderligere kontroller eller tilpasning af kontroller. Det kan også være, at enkelte kontroller ikke giver mening for den enkelte virksomhed.
Baseline-konfigurationer
Baseline-konfigurationer eller hardening handler om at beskytte den enkelte server, så i forhold til vores analogi beskytter vi her hver enkelt guldmønt.
Dette omhandler sikkerhedsparametre, lokale brugere, password indstillinger, services og så videre. Altså alt, der kan konfigureres på de enkelte servere.
Der findes masser af gode og fornuftige guidelines til, hvordan dette skal opstilles. Men dér, hvor jeg ser den største udforing, er at få de enkelte guidelines tilpasset sin virksomhed.
Hvis dette ikke gøres korrekt, kan der opstå sårbarheder i konfigurationerne, som i værste fald kan give en angriber adgang til den enkelte server.
I forhold til baseline-konfigurationer bør der foretages løbende sårbarhedsscanninger, så det sikres, at ens baseline-politikker er opdaterede.
Host-baserede firewalls
Host-baserede firewalls bør være en del af den hardening-politik, som man benytter til at beskytte serverne med enkeltvis.
Jeg har dog valgt at beskrive denne for sig, da det ofte er min erfaring, at virksomheder har gode hardening-politikker, men som oftest har valgt ikke at implementere en hostbaseret firewall på de enkelte maskiner. Dette er dog Microsoft best practice og bør være et krav fra virksomheden til sin driftsafdeling.
Segmentering/isolering
Segmentering/isolering handler om at mindske eller afgrænse adgangen til de systemer, vi ønsker at beskytte. Dette kan med fordel udføres på baggrund af en risikovurdering, hvor man vælger at segmentere sit netværk.
Det kan for eksempel være, at man ønsker at opdele sit netværk i høj-, mellem- og lav-risikozoner. Virksomheden har eventuelt en bestemt type data, som man ønsker at isolere fra resten af sit netværk.
Dette er ofte brugt i PCI-verdenen, hvor man ønsker at beskytte kreditkort-data mere end andre data. I kraft af den nye persondataforordning kunne det være nærliggende at tænke, at virksomheder ønsker at beskytte persondata på samme måde.
Her er et eksempel på, at vi ønsker at isolere et system, som bliver benyttet til persondata:
På ovenstående facon har vi nu mindsket angrebsfladen til vores system, som behandler persondata, og dermed har vi også mindsket risikoen for, at angribere, som allerede har et fodfæste eller som i fremtiden får et fodfæste i vores miljø, kan kompromittere vores persondata.
Password-sikkerhed
Der er meget, man bør være opmærksom på i forbindelse med passwordsikkerhed.
En af de bedste løsninger er klart at implementere to-faktor-autentifikation, hvilket kræver, at man udover et password også har et trin mere i logon-processen. Det kan eksempelvis være en SMS-kode.
Enkelte væsentlige passwordregler, der bør være på plads i forhold til "Assume breach", er, at der ikke må genbruges password på servere - eksempelvis på den lokale administratorkonto.
Genbrugte passwords gør det muligt for en angriber at hoppe mellem servere, og selv om der benyttes et komplekst password med 40 karakterer, er det kun falsk tryghed, idet der findes forskellige angrebsmetoder til at udnytte dette.
Stol aldrig udelukkende på kompleksitetsindstillinger på eksempelvis Windows Domain Policy. Brugere vil altid forsøge at gøre det let for sig selv.
En meget almindelig passwordpolitik, man som ofte ser implementeret, er krav om otte karakterer, et alfanumerisk tegn samt brug af store bogstaver.
Her ser jeg ofte, at brugere stadig benytter passwords som 'Sommer2016', da det overholder kompleksitetskravene. Det så vi også for ti år siden, så hvorfor er det, vi stadig stoler på kompleksitetsindstillingerne?
Denne kontrol er nok til at kunne få en 3402-erklæring, en PCI-certificering eller en ISO27001-certificering.
Min mening og erfaring er, at det på ingen måde er nok til at sikre, at ens brugere benytter et stærkt password. Hvorfor er det så, at vi som fag stadig accepterer dette?
Det, en angriber let kan gøre, er at forsøge enkelte passwords, som vi ved, altid benyttes af brugere, og som dermed kan bruges til at opnå adgang. Dette er et område, som et af mine næste indlæg formentligt kommer til at berøre.
Rapportering, review og test
Min erfaring viser, at kontroller bedst virker med løbende rapportering og test af disse.
Samtidig er det vigtigt, at der løbende følges op på implementerede kontroller, og at disse tilpasses virksomheden og virkeligheden periodisk.
Der bør løbende rapporteres, om kontrollerne fungerer.
I forhold til hardening-guides kan dette være en månedlig rapport, som viser, hvor mange servere der ikke lever op til virksomhedens guidelines.
For segmentering kan dette være en rapport, som viser, om segmentering fungerer, som den skal.
Der bør som minimum årligt foretages review af, om ens kontroller er dækkende for ens miljø.
Da der ofte sker masser af ændringer i it-miljøer og angriberes måde at tænke på, bør ens kontroller årligt gennemgås og forbedres.
Når man har kontroller på plads, som virksomheden mener er dækkende, og der ikke kan findes på flere tiltag, eller man mener, at det er sikkert nok nu, bør der løbende foretages test.
Her kan man med fordel foretage uvildige penetrationstest eller lignende for på denne måde at efterprøve ens miljø mod en angriber.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.