kramselund jereminsen

Firewalls virker, Zero Trust er pop

Perimeter sikkerhed var aldrig nok

Der er så meget "nyt" indenfor IT-sikkerhed, hele tiden -- nyt nyt nyt.

Det er dog oftest gammel vin på nye flasker.

Det officielle lydspor til dette indlæg er Odyssey Going Back to MY Roots, fordi det er et funky nummer og vi skal huske vores rødder.
https://www.youtube.com/watch?v=1qW9-s3ITbU
https://open.spotify.com/track/3gZs2MpDVNJb0CnPwkU3m9?si=00c0496fffc14899

Jeg sad og læste artiklen, https://www.version2.dk/artikel/kaempehacks-saetter-klassisk-it-sikkerhe...

og jeg er ikke uenig i alt :-D

Det er fornuftigt at assume breach, at noget er hacket.

Det er ufornuftigt at fjerne den generelle mur.

Faktisk har det jo i mange år været et mantra at bruge Defense in Depth. Jeg kan ihvertfald spore det mange år tilbage i mine præsentationer. Generelt indenfor computing er det også brugt i mange år, og wikipedia siden går tilbage til 2006, læs den her https://en.wikipedia.org/wiki/Defense_in_depth_(computing)

Skriv jer den bag øret, det ER den måde man gør det sværere at lave succesfulde angreb, og hvad er derefter følger.

Når vi så får tudet ørene fulde af Zero Trust, og alle leverandører skubber hinanden for at komme først med ZERO TRUST løsninger, bliver jeg træt.

The zero trust security model (also, zero trust architecture, zero trust network architecture, ZTA, ZTNA), sometimes known as perimeterless security, describes an approach to the design and implementation of IT systems. The main concept behind zero trust is that devices should not be trusted by default, even if they are connected to a managed corporate network such as the corporate LAN and even if they were previously verified.

Kilde:
https://en.wikipedia.org/wiki/Zero_trust_security_model

Altså der er jo ikke noget galt med at antage at maskiner er inficerede. Det er en sund antagelse, for vi kan jo se efterfølgende, eller næsten i real-time hvordan systemer pinger ud efter deres Control and Command servere.

Det er super at vi har fået Threat Hunting, jagtekspeditioner efter inficerede systemer. Just Do It, altså når I lige har etableret nogle logningsløsninger og andet security visibility.

Shameless plug, vi har faktisk et kursus SIEM og Logning på KEA. Alle mine slides er frit tilgængelige på Github/kramse SIEM så jeg håber I tillader denne reklame. Specielt vil jeg gerne anbefale bøgerne på kurset, som kan ses i lektionsplanen

Nå, tilbage på sporet. Zero Trust er helt nyt!!!! Det er så fedt!

Men er det nyt? Selv de gamle borge havde jo flere lag!

Core design principles for security

Hvis vi springer på sikkerhedstoget tilbage til 1975 finder vi:
https://www.cl.cam.ac.uk/teaching/1011/R01/75-protection.pdf
J. H. Saltzer and M. D. Schoeder “The Protection of Information in Computer Systems.” 1975

Indholdet er blandt andet: design principles:

  • a) Economy of mechanism: Keep the design as simple and small as possible.

  • b) Fail-safe defaults: Base access decisions on permission rather than exclusion.

  • c) Complete mediation: Every access to every object must be checked for authority.

  • d) Open design: The design should not be secret

  • e) Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key.

  • f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job.

  • g) Least common mechanism: Minimize the amount of mechanism common to more than one user and

  • depended on by all users

  • h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly.

Det er et af verdens mest citerede papers, og med i mange IT-sikkerhedsbøger. Principperne bør derfor være genkendelige for mange.

Hvis vi så stjæler et citat fra Version2 artiklen:

»Basalt set går det ud på, at man hele tiden har styr på, hvem der må se og gøre hvad i en infrastruktur, og konstant sørger for, at brugerne autentificerer sig. Må vedkommende, der prøver at få adgang til en bestemt fil, rent faktisk se den?« spørger Kenneth Schwartz.

NB: her ligger ingen som helst kritik af Kenneth Schwartz, som blot forklarer ZT.

ER dette så ikke blot anvendelse af vores +45 år gamle principper. Vi skal checke adgang hver eneste gang, herunder gentage checket - princip c) ovenfor. Det trækker forøvrigt på time-of-check-time-of-use som er et andet koncept, der skal være kort tid fra et program checker adgang, til adgangen anvendes.

Vi kan også udvide med, skal den pågældende PC som brugeren benytter kunne se den server? Hvis vi havde benyttet princip f) og b) på serverniveau, netværksniveau, mappe niveau, netværksdrev, ville der måske være begrænset om den kunne tilgå. Det kunne også være danske virksomheder skulle se lidt på åbenheden.

Vi har haft tillid til vores ansatte, hvilket jo er godt, men vi har udstrakt denne tillid til de enheder de benytter -- og det er skidt at stole på computere.

Det bløde indre

En anden ting som slår mig jævnligt er hvor åbne vores netværk er og har været igennem mange år. Måske fordi netværk blot er noget som er opstået ved knopskydning og efter behov. Der har været brug for servere til at drive nogle applikationer, netværk er bare ligesom strøm.

Så vi har nogle kæmpe interne infrastrukturer som er den bløde indre, der også omtales i artiklen.

Det er som sådan ikke noget nyt. Det er sket fordi vi sjældent stiller krav til hinanden.

Misforståelsen er at det faktuelle resultat er resultatet af design. Det er derfor efter min mening forkert når man tager perimetersikring til gidsel for at systemer stadig bliver hacket. Vi kan ikke forlange at en enhed der filtrerer netværkspakker skal kunne autentificere en bruger før adgang til en fil - dybt inde i infrastrukturen.

Det betyder dog ikke at firewallen har spillet fallit.

Slå firewall til overalt, på alle enheder

Et krav jeg gerne så implementeret er "alle enheder har firewall slået til". Det vil være en god fail-safe default, og underbygges af at det meste kode har fejl og sikkerhedsfejl. Det ville betyde at en udvikler som skal igangsætte en applikation, med flere servere, ville skulle specificere adgang.

Typisk vil det være relativt simpelt at web server med åbne porte 80/tcp og 443/tcp kunne skal tilgå database server på port 4321/tcp. Hvis vi så samtidig kræver at der ikke blot åbnes for hele internet til den database-server kunne det være lækkert. Det er jo kun web serveren der skal tilgå dén server.

Det er ikke svært, og kan gøres med Ansible og UFW således:

ufw: rule=allow interface=eth0 direction=in proto=tcp to_port=5038 from_ip=192.0.2.60

Så istedet for 30 linier til at konfigurere en database server med provisionering er det 31 linier. Vel og mærke en linie som pågældende udvikler kan skrive uden besvær.

Det vil til gengæld gøre at den server ikke kan tilgås på den service andre steder fra.

Når jeg specielt bruger firewall som eksempel er det fordi nogle ZT konsulenter lader til at have tabt småkagerne. De mener at ZT erstatter noget.

Min mening er at de har glemt god etikette og deres nye åbenbaring primært er genopfundne principper.

Så mit råd er, dyk ned i de gamle råd. Tænk sikkerhed ind tidligt, check og reparer nedefra og udefra. Når I så kommer til arbejdsstationer så tænk på tværs og udgående trafik.

Mange problemer kan undgås med default deny på firewall, både udefra OG indefra.

Så, hvis I vil snakke om Zero Trust - så gør det, men med respekt for firewalls og andre teknologier. Der er ingen grund til at fjerne de dele der virker, fordi man vil indføre mere sikkerhed på andre steder - hvor det er tiltrængt.

Firewall definition

BTW Jeg genfandt definitionen af firewall i 1994 bogen, Firewalls and Internet Security: Repelling the Wily Hacker, First Edition William R. Cheswick and Steven M. Bellovin

We define a *firewall* as a collection of components placed between two networks that collectively have the following properties
  • All traffic from inside to outside, and vice-versa, must pass through the firewall .
  • Only authorized traffic, as defined by the local security policy, will be allowed to pass.
  • The firewall itself is immune to penetration.

De bemærker at dette er design goals, "a failure in one aspect does not mean that the collection is not a firewall, simply that it is not a very good one."

Den tager jeg med i min firewall bog!

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Chris Bagge

Vel vidende at du internet samurai så er der jo nogen af os herude der i praksis sidder med Windows / Mac udstyr. Er der nogle værktøjer, til logning som du ville kunne anbefale til os almindelige dødelige i på mindre netværk (hjemmenet / mindre virksomhed)

En der trods alt har sat sin egen firewall op bagved TDCs router/firewall.

  • 0
  • 0
#4 Martin Dahl

Firewalling er noget af det letteste og billigste at implementere ift. den mængde angrebsvektorer, som elimineres.

Primært fordi at snitfladen mellem netværk ikke er afhængigt af applikationslaget.

Det er let at sige ZT og "x"-by-design, men det er væsentligt sværere i praksis at udvikle økonomisk rentable, sikre løsninger, som performer og betjenes tilfredsstillende.

Poppet i ZT er Zero.

Et eller andet skal vel for pokker trustes for at responde på et request.

Men det lyder sejt, når man siger, at man har implementet et niveau af sikkerhed, hvor hvert element har Zero tillid til omverdenen.

  • 7
  • 0
#5 Henrik Kramselund Jereminsen Blogger

Logningsværktøjer er ofte ligeglade med hvor logs kommer fra. Jeg er glad for elastic stack, fordi den har så meget med fra starten. De har også packetbeat som er relativt nemt at sætte op og giver godt indblik.

Elastic Common Scheme er en nice feature, så værktøjer på tværs af leverandører kan bruge samme felter osv.

Det ville eksempelvis kunne sige, hvilken PC slog først op på et specifik malware domæne, hvis man er blevet inficeret.

  • 0
  • 0
#6 Anders Bandholm

Jeg vil gerne reklamere lidt for Argus, som jeg fik lov at sætte op i Styrelsen for it og læring (tidl. UNI-C) Den loggede alle sessioner (uden payload) og vi havde sessionlog ca 1 år bagud for al trafik ind og ud af datacentret. Det var guld værd! Vi brugte det mest bagudrettet: Hvornår var et opdaget angreb i virkeligheden startet? Hvad havde angriberne ellers forsøgt sig med? Hvis vi opdagede at en firewall havde haft en utilsigtet åbning, var den så blevet tilgået af fremmede? Hvis vi gerne ville filtrere en servers trafik mod internettet kunne Argus give os alle de udgående sessioner langt bagud, så man undgik at spærre for noget som faktisk var vigtigt. End of rant ;-)

Jeg er også svært begejstret for både Graylog, som jeg brugte tidligere, og Elastic-stakken, som jeg bruger nu.

  • 2
  • 0
#7 Chris Bagge

Firewalling er noget af det letteste og billigste at implementere

Tak for en masse svar på det stillede spørgsmål. På nær svaret ovenfor, så afventer jeg de meget lavpraktiske svar. Mit håb ville være at få nogle lavpraktiske råd der ikke kræver at man skal til at rode dybt nede i kernen på en Linux server eller lignende.

Ja, jeg har selv indskudt en Firewall (en Zywall) bagved min udbyders router. Jeg tror vi, om muligt, skal ned på et lignede niveau i vejledning for at opnå en passende udbredelse af beskyttelse. Er det overhovedet realistisk eller "drømmer jeg i farver"?

Den "dybde" jeg selv tidligere har nået har været at sætte "ip-tables" op på en Linux gateway.

  • 0
  • 0
#8 Rasmus Larsen

For såvidt vil jeg give dig ret i at Zero Trust hvad angår netværkssikkerhed ikke er noget nyt. Der er ikke noget nyt i det, sådan er det næsten hver gang en eller anden stakkel sætter et nyt ord på en løsning på et gammelt problem.

Men Zero Trust dækker jo et bredere begreb. Det er et forsøg på at gøre opmærksom på den sikkerhedskultur der er i mange, især større, firmaer hvor perimeteren bliver brugt til authentikering. Eg. hvor man har højere privilegier alene baseret på det subnet/vlan man kommer fra og det VLAN samtidig er åbent tilgængeligt via. RJ45 porte i væggen og/eller via. et wifi, der ikke er beskyttet af individuel authentikering.

Den slags setups har det, over tid, med at udvikle sig til et mareridt, hvor man ligger alle mulige overvågningstiltag ned over netværket (forward proxies mm.), fordi hvis man baserer sin sikkerhed på perimeter baseret adgangsstyring og den virksomhed man sidder i vokser, så ender man næsten altid med et uhåndterbart mareridt.

Og ja, ligesom andre moderne begreber som "Cloud" så er det gammel vin på nye flasker, men det er sådanset ligegyldigt, det faktum at folk/firmaer/leverandører har forstået pointen og faktisk gør det, giver vel termen en vis beretigelse?

  • 0
  • 0
Log ind eller Opret konto for at kommentere