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-sikkerhed-skakmat-ideen-mur-holder-ikke-1092360
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!
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
