It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Tagg: säker design

Det finns inga gratiskrav

Det finns inga gratiskrav.Det här är en post-it som sitter strax till höger om min skärm vid skrivbordet. Den är till för att påminna mig om att påminna personer i min närhet om att ”Det finns inga gratiskrav”.

I mina ögon är säkerhetskravställning lite av en konst. Inte för att det är svårt, på sätt och vis är det ganska enkelt att ställa säkerhetskrav: det finns en hel industri kring it-säkerhet som har tagit fram saker från säkerhetsövervakningsavdelningar till MAC och allt där i mellan.

När du sitter med ett system under utveckling och ska formulera säkerhetskrav har du hur många krav som helst att välja på. Häri ligger konsten, du kan inte ställa hur många som helst för förr eller senare ska kraven uppfyllas; någon ska implementera MAC-kontrollen eller organisera säkerhetsövervakningsavdelningen och det kostar resurser i tid och pengar.

Att välja säkerhetskrav

Varje säkerhetskrav kostar resurser och sådana är alltid begränsade. Konsten är att ställa de säkerhetskrav som ger mest bang for the buck. Säkerhetskrav kostar olika mycket resurser och bidrar med olika mycket säkerhet så i grunden handlar det om en cost/benefit-analys för varje krav.

Är den säkerhet som kravet bidrar med värd besväret?

För att kunna svara på denna fråga måste man har koll på tre saker:

  1. Vad kostar kravet?
  2. Hur mycket säkerhet ger kravet?
  3. Vilket behov av säkerhet finns?

Tyvärr finns inga exakta svar på någon av frågorna, det finns inte ens ganska exakta svar, så vi kan sällan räkna på det med siffror. (Jag refererar till två äldre inlägg: Att mäta säkerhet på Internetdagarna och Att mäta säkerhet igen.)

Jag sprang på ett fantastiskt citat igår kväll på tal om det här, ett av ekonomilegenden Keynes (nu såg jag att det inte alls var han utan tydligen Carveth Read):

It is better to be vaguely right than exactly wrong.

Det kommer att handla om olika bra uppskattningar till svaren. Man ska göra avvägningen i alla fall; men man måste acceptera att det inte är en exakt vetenskap och handla därefter. Det här leder ofta till något som det är modernt att hata inom säkerhet; något som slarvigt kallas magkänsla. Jag gnäller en del över det i Att mäta säkerhet igen-inlägget om du är på humör för sånt, annars lägger vi det åt sidan.

Av de tre frågorna följer att alla säkerhetskrav inte är lika mycket värda. Vissa saker ger mycket säkerhet för lite resurser medan andra ger förhållandevis lite säkerhet i utbyte mot stora resurser. De förstnämnda är no-brainers, de sistnämnda kräver analys; kanske är just den lilla säkerhetsdetalj som erbjuds ett måste som inte går att uppnå på något annat sätt? Kanske kan vi inte avgöra riktigt utan blir tvungna att köra för att vara på säkra sidan?

Rabatt på säkerhetskrav

När vi ändå har börjat tala i ekonomiska termer kan vi lika gärna fortsätta, men det får bli nästa gång. Trevlig tredje advent!

Annonser

Sophos: security features != secure features

The paper includes a working pre-authentication remote root exploit that requires zero-intera[c]tion, and could be wormed within the next few days. I would suggest administrators deploying Sophos products study my results urgently, and implement the recommendations.

Så inleds den andra delen av Tavis Ormandys Sophail-rapport som släpptes på Full-Disclosure i måndags. Det är en kuslig påminnelse att det är skillnad på säkerhetskomponenter och säkra komponenter.

Mitt examensarbete på skolan behandlade i viss utsträckning generiska skydd mot buffer overflows: till exempel stack canaries, NX/XD och ASLR. CJ, som var min handledare, och jag var då och träffade en återförsäljare av just Sophos i hopp om att få lite mer information om hur deras BOPS-teknik fungerade. BOPS, eller Buffer Overflow Protection System, skulle alltså vara ytterligare ett sådant generiskt skydd.

Lång historia kort, vi blev besvikna. Den ”expert” som vi fick prata med förklarade att man kunde sätta på BOPS för enskilda binärer eller globalt och sedan vitlista vissa binärer. Hur BOPS verkligen gjorde för att stoppa attacker hade han ingen aning om. Wow.

Överraskande nog har BOPS precis motsatt(!) effekt, avsikten är att införa något som liknar ASLR men istället ser den till att det alltid finns en statisk (istället för en slumpmässig) adress i minnet att gå mot. Från Ormandys rapport (min fetstil):

The purpose of BOPS (although it does not work) is to provide a faux-ASLR implementation for Windows XP. Sophos ship the product on other platforms but it is essentially a no-op. Sophos uses AppInit_DLLs to force load this nondynamicbase module into every process, disabling ASLR on platforms that do have it enabled.

This effectively disables ASLR on all Microsoft Windows platforms that have Sophos installed, allowing attackers to develop reliable exploits for what might otherwise have been safe systems

Christoffer var snabbare att dra parallellen till Kerckhoff och hans hundra år gamla princip.

Ormandy ger tre råd till de drabbade:

  1. Förbered er på att stänga av Sophos AV på alla system (om en mask skulle dyka upp).
  2. Installera inte Sophos-produkter på kritiska system, det finns helt enkelt för många sårbarheter.
  3. Installera inte Sophos-produkter på system som är svåra att uppdatera, det finns helt enkelt för stort behov att hålla produkten uppdaterad.

Det är ett obehagligt problem att programvara som utvecklas och distribueras brett ibland är i dåligt skick. Det är sånt som gör skadeansvar till ett intressant ämne.

Komplexitet och säkerhet: ett exempel

”Complexity is the worst enemy of security.” -Bruce Schneier

Det känns rätt gammalt att säga att komplexitet och säkerhet är motpoler men inget kunde vara mer sant. Några av mina favoritgubbar Saltzer & Schroeder uttryckte det som: economy of mechanism, slösa inte med mekanismer. Designa system som är små, enkla och funktionsfattiga. Enkla system är enkla att skydda. Christoffer skrev om det här tidigare i år.

Jag tänkte försöka mig på ett tydligt exempel från boken Computer Security: Art and Science av Matt Bishop, en favoritbok.

(Varning utfärdas härmed om att inlägget är lite raljerande…)

Book cover

I ett kapitel (kommer inte ihåg vilket) berättas historien om ett företag som har en webbserver varifrån besökare kan köpa saker på kort. Hur kan detta implementeras på ett säkert sätt? Jag minns inte exakt hur det var men det är inte så noga.

Förslaget som ges i boken är lätt att förklara: Apache-webbservern i DMZ tar emot besökarens data från ett formulär (namn, leveransadress, kortnummer, etc) via CGI (Perl eller Bash kanske) över TLS, validerar uppgifterna och skriver dem till en textfil på disk, krypterar textfilen med en publik nyckel (openssl t ex) och ett cronjob kopierar den till en spooling-katalog dit webbservern inte har åtkomst, originalfilen shreddas.

Med jämna mellanrum anropas webbservern i DMZ av en annan server på det interna nätet, filerna kopieras över SSH, kanske med rsync, originalfiler shreddas. De hämtade filerna dekrypteras med den privata nyckeln, uppgifterna valideras (igen) och lämnas vidare till affärssystemet som löser resten.

Enkelt. En generell säkerhetsspecialist med Unix-erfarenhet skulle kunna implementera det här på en eftermiddag. Samma person skulle kunna få det här förklarat för sig och säkerhetsgranska implementeringen på ett par timmar. Det är lätt att bilda sig en uppfattning om systemets säkerhet.

Person viker ett pappersflygplan

Okej, switch till en ”modern” motsvarighet.

I DMZ står EPiServer .NET Content Management System, den består av massor av DLL:er och XML-filer, kör på IIS. EPiServer kan göra massor av saker, det finns massor av plugins. Om det inte är EPiServer kanske det är ett, men förmodligen flera, större ramverk (och ännu fler XML-filer) på en applikationsserver som kör Java EE. Anywho.

Servern tar emot ett betalningsobjekt som sedan serialiseras och skickas som asynkront meddelande i XML-format kanske via MQ, kanske över TLS till en BizTalk-server på det interna nätverket. BizTalk genomför någon form av transformering på meddelandet och vidarebefordrar det till affärssystemet med ytterligare ett protokoll, synkront med SOAP över http kanske?

Mechanic checking out a jet engine

Nu vet jag inte om det ”moderna” fallet är säkert eller inte. Det är också poängen. Det är svårt, för att inte säga omöjligt, för någon att avgöra. Det är för mycket funktionalitet, för mycket indirection, för stor abstraktion för att kunna skaffa sig en rimlig uppfattning om hur säkert det är. Det är för komplext.

Visst, det moderna fallet ger säkert massor av fördelar: det skalar väl, det finns färdiga API:er för olika affärssystem, det är snabbt, det är möjligt att byta ut olika delar, det finns en leverantör att ställa till svars, allt möjligt. Du kan däremot aldrig hitta en generell säkerhetsspecialist som kan avgöra hur säkert det är.

Hur, exakt, hanterar EPiServer formulärdata? Not a clue. Hur, exakt, förs det vidare till BizTalk? Not a clue. Hur väl, exakt, skyddas vårt ”meddelande” medan det är i BizTalk? Not a clue. Hur, exakt, är det med nästa sträcka mot affärssystemet? Not a clue.

Självklart finns det en person som har benkoll på vad EPiServer gör med de data som användaren lämnar. Självklart finns det någon som kan BizTalk, alla protokoll den stödjer och vad det innebär att uppgifterna transformeras innan överlämningen. Det är dock inte samma person och det är inte alls säkert att någon av dem kan säkerhet.

Så, slutraljerat.

Carl-Johan påpekar att det finns två sorters komplexitet i exemplet ovan: komplexitet i arkitekturen och komplexitet i komponenterna. Båda former är ovälkomna men för en säkerhetsgranskare är komponentkomplexitet värst. Det underlättar inte att komponenterna är stängda; granskaren har väldigt lite att gå på, man använder underliga protokoll, släpper ingen källkod, inga detaljerade arkitekturbeskrivningar utan bara användarmanualer (orgier i skärmdumpar och steg-för-steg-beskrivningar). När det finns information kan den istället vara överväldigande eftersom varje komponent är såpass stor. Jämför EPiServer med Apache eller BizTalk med SSH i det här fallet.

Det enkla alternativet bygger på vedertagna standardprogram, på protokoll som finns beskrivna i RFC:er, det finns program för att undersöka protokollen, Wireshark kan tolka dem, det går att koppla in fuzzers o s v. En säkerhetsgranskare kan göra sitt jobb på kortare tid och med högre kvalitet. Apache-fallet kan jag ge ett kvalificerat yttrande över på en eftermiddag. EPiServer-fallet skulle kräva ytterligare personer, och flera månader men yttrandet skulle ändå vara ganska skakigt.

Men, ha en trevlig helg ändå!

Säkerhet och begagnade bilar

Jag behöver av olika anledningar köpa en bil och det kommer att bli en begagnad en. Jag har länge fruktat inför det här, dels för att mina bilrelaterade kunskaper är synnerligen begränsade men framför allt för att jag tror på alla fördomar om bilförsäljare.

Used car sign

De flesta av mina åsikter om begagnade bilar kommer från min favoritekonomiuppsats (om man kan ha något sånt) The Market for Lemons: Quality Uncertainty and the Market Mechanism av George Akerlof. Jag har tydligen nämnt den tidigare på bloggen.

Den handlar i korthet om att marknaden för begagnade bilar tenderar att dra till sig dåliga bilar (lemons) snarare än bra bilar (cherries) eftersom köpare har dåliga förutsättningar för att avgöra bilens skick. Säljare inser att köpare inte kan se att bilen är dålig, marknadsför den som bra, köpare inser detta och börjar utgå från att bilarna är dåliga, säljare av bra bilar låter bli att sälja dem på marknaden för att köpare utgår från att de är dåliga, ond spiral. Bad driving out the good.

Jag känner att jag inte har någon som helst anledning att lita på en bilförsäljare. Det ligger i säljarens intresse att sälja en så dålig bil som möjligt för så högt pris som möjligt. Oftast är bilhandlare dessutom köpare emellanåt så när du ska sälja din bil till dem vill de ge så lite pengar som möjligt för en så bra bil som möjligt.

Det här är ju något som gäller oavsett vad man ska köpa men för mig blir det av någon anledning extra tydligt i samband med bilköp.

Ännu värre blir det när man har ”en bil i inbyte”. Det är lätt att tolka det som att handlaren gör dig en tjänst, är bussig, som tar hand om din gamla häck till bil nu när du ska köpa en finare. Det är ju kanon, handlaren fixar med avställning o s v så att du slipper…

…men nu är du ju både köpare och säljare, handlaren kan lura dig två gånger.

I säkerhetsvärlden är det här ett vanligt problem, två parter som inte litar på varandra. Verisign är i den branschen, Kerberos bygger på det. Enter the trusted third party.

Kvarndammen är ett exempel på en bilhandlare som utnyttjar detta. Man låter en s k värderingsman värdera bilen, utifrån denna värdering sker sedan en auktion. Tanken är att värderingsmannen är oberoende och inte har något incitament att vare sig över- eller undervärdera bilen. Lysande.

Modellen vilar dock på att tredjeparten, värderingsmannen, är pålitlig. Värderingsmannen ska bara vara intresserad av att ge en rättvis bedömning av bilens värde, inget annat. Själv känner jag att jag litar på värderingsmannen, åtminstone i mycket större utsträckning än på godtycklig bilhandlare eller Blocket-försäljare. Jag ska dock erkänna att jag inte har några särskilda belägg för detta förtroende. Jag skulle dock önska att Kvarndammen hjälpte mig på traven lite:

  • Skriv ut namnet på värderingsmannen, utnyttja att hon vill uppehålla sitt goda rykte om rättvisa värderingar.
  • Var tydligare med att värderingsmannen inte har några ekonomiska incitament som gynnar vare sig säljare eller köpare. (Om det nu är så det ligger till, vilket jag verkligen hoppas.) Hon ska t ex absolut inte få procent på försäljningspriset.

Ska man ta det ännu längre kanske det går att skapa en lönemodell som gynnar rättvisa värderingar. Omvänd procent på skillnaden mellan listpris och slutgiltigt pris kanske?

(Nej, det här är inte avsett att vara reklam för Kvarndammen, bara ytterligare en observation av säkerhet i vardagen.)

En annan intressant funktion är hur själva auktionen går till. Vid sluttiden som publiceras för varje objekt börjar en nedräkning på tre och en halv minut, om ett nytt bud läggs under denna nedräkning börjar nedräkningen om. Så fortsätter det till någon har det högsta budet.

Det är ett sätt att undvika s k auction snipers där oärliga typer budar över med en liten summa precis innan auktionen är över. Som vanligt har säkerhetsfunktioner bieffekter, hur länge är det tillåtet att förlänga budgivningen? En viss tid? Ett visst antal bud? Hur skyddar du mot att någon snipear den sista förlängningen? För dyrare objekt är det möjligt att avskräcka genom att sätta en lagom hög minsta-höjning men generellt är det ett svårt problem.

Annars kan man ju alltid DoS:a sajten efter att man har lagt sitt bud så att det blir svårt för övriga att buda över. Det känns dock lite fantasilöst. Vad sägs om att sätta sitt användarnamn till

<script>window.location.href="http://www.aftonbladet.se/";</script>

och sen lägga ett bud så att användarnamnet visas på budsidan.

…vi får se om det blir ett vrakpris. Trevlig helg!

Säkerhet och säkerhet och spärrar

Svenska språket saknar engelskans motsvarighet till safety. Medan engelskan kan prata om car security för att mena säkerhet mot inbrott i och stöld av bilar (larm, rattlås o s v) kan de också prata om car safety för att mena säkerhet för bilens passagerare (bilbälte, airbag o s v).

I Sverige får vi nöja oss med bara ”säkerhet” tills vidare men vem vet, Svenska akademien kanske löser även det i framtiden.

Intressant är att security och safety inte sällan motverkar varandra. Skolexemplet är dörrar för utrymning av byggnader.

Utrymningsskylt

I syfte att skydda byggnaden är det inte alls en bra idé att sätta upp utrymningsdörrar och spiraltrappor eftersom de är utmärkta vägar in för t ex inbrottstjuvar. I syfte att skydda människor vid brand däremot… Med dörrar kommer man sedan in på detaljer som att det ska vara lätt att öppna dörren vid brand men svårt annars.

DN körde en artikel här om dagen om hur SL:s glasspärrar ibland är farliga:

När tunnelbanespärren smällde igen om Anna Fredriksson fick hon blåmärken på ryggen och ett blödande jack ovanför ögat. ”SL:s krig mot plankarna leder till att vanliga resenärer bokstavligen kommer i kläm”, säger Mikael Sundström, ordförande i Kollektivtrafikant Stockholm.

Det är viktigt att ta hänsyn till sådana omständigheter när man designar säkerhetslösningar, det är lätt att ökad security innebär minskad safety eller vice versa. Det här är en av anledningarna till att ställa sig frågan ”Vilka andra risker introduceras?” när man utvärderar en säkerhetsmekanism. Jag har tagit upp detta tidigare i samband med ett inlägg om att ha reservnycklar hos larmbolaget.

Som vanligt är det extremt svårt att avgöra om svaret på frågan är värt det. Som sägs i artikeln, någon miljon människor passerar spärrarna varje dygn och majoriteten klarar sig utmärkt. Hur många skador är vi beredda att acceptera?

Vem kunde tro att SL:s spärrar skulle vara så illustrativa?

Ye Olde Security: Saltzer-Schroeder

För länge, länge sedan, på 1970-talet, inte långt efter vi tågade över Bält och skrämde slag på danskarna, levde två lärda män som hette Jerome H. Saltzer och Michael D. Schroeder. Saltzer och Schroeder var forskare och hade stora anslag för att undersöka hur information kunde skyddas i system för ADB. 1973 skrev de sitt magnum opus: The Protection of Information in Computer Systems.

 Saltzer-Schroeder-uppsatsen är ett fantastiskt exempel på att vi stöter på samma problem om och om igen. I texten hittar vi nuggets som de åtta designprinciperna (mer om dessa nedan):

  1. Economy of mechanism
  2. Fail-safe defaults
  3. Complete mediation
  4. Open design
  5. Separation of privilege
  6. Least privilege
  7. Least common mechanism
  8. Psychological acceptability

Med kommentaren: ”As is apparent, these principles do not represent absolute rules—they serve best as warnings. If some part of a design violates a principle, the violation is a symptom of potential trouble, and the design should be carefully reviewed to be sure that the trouble has been accounted for or is unimportant.”

Eller varför inte: ”In particular, the user himself and the communication system connecting his terminal to the computer are components to be viewed with suspicion. Conversely, the user needs to verify that he is in communication with the expected computer system and the intended virtual machine.”

Eller vad sägs om: ”An easy way for an intruder to penetrate a password system, for example, is to intercept all communcations to and from the terminal and direct them to another computer—one that is under the interceptor’s control. This computer can be programmed to ‘masquerade,’ that is, to act just like the system the caller intended to use, up to the point of requesting him to type his password. […]”

Economy of mechanism: Designa små, enkla system. Ju enklare desto mindre risk att sårbarheter införs, desto enklare är det att upptäcka dem och desto lättare är det att laga dem.

Fail-safe defaults: Själv brukar jag göra skillnad på fail-safe och fail-secure (egentligen är det väl Schneier som har inspirerat distinktionen i Beyond Fear) eftersom de ofta står mot varandra; nödutgångar är skolexemplet. Här avses oavsett att normalläget är ingen åtkomst och att systemet istället ska definiera under vilka förutsättningar åtkomst ges. Whitelisting kontra blacklisting.

Complete mediation: Varje anrop eller åtgärd ska omfattas av säkerhetsbeslut viz. det ska inte finnas ”bakdörrar” som går förbi det som konceptuellt kallas en reference monitor. Faktum är att detta var ett av de tre kraven på en reference monitor som James P. Anderson lade fram i Computer Security Technology Planning Study från 1972. (Den rapporten är också gammal men avsevärt mer svårsmält.)

Open design: Kerckhoffs princip.

Separation of privilege: Här avses snarare det vi idag oftast kallar defense in depth, att säkerheten inte ska bero på bara en försvarslinje. Man ger exemplet där en dörr har två oberoende lås vars nycklar kan förvaras av olika personer på olika platser. Dels handlar det om att göra det svårt för en tredje person att få tag i båda nycklar, dels för att skydda sig mot insiders. Det är inte uttalat i uppsatsen men man kan argumentera för att låsen kan vara av olika modell för att för att skydda sig mot sårbarheter i ett lås. Eller använda helt olika tekniker för att skydda sig mot class breaks.

Least privilege: Det här kan vara den mest kända principen och är precis vad den låter som. Militärens need-to-know används som exempel. Den är givetvis nära besläktad med fail-safe defaults ovan.

Least common mechanism: Detta tangerar segmentering, att minimera gemesamma kontaktytor mellan användare (processer). Eftersom multi-level security-system (Bell-LaPadula o s v) var på tapeten vid den här tiden så var informationsläckage och covert channels ett stort bekymmer. Samtidigt rörs det vi idag kallar process isolation där en modern, närliggande teknologi är t ex Windows Integrity Mechanism som kom med Vista.

Psychological acceptability: Gör det lätt för användaren att fatta rätt säkerhetsbeslut. Nuförtiden skulle jag dock lägga till ”men undvik helst att blanda in användaren överhuvudtaget”. Problemet med principen är att ”användare” i början av 70-talet inte, som idag, betydde Joppe och Göran, utan diverse forskare och programmerare. Att inte blanda in användaren i säkerhetsbeslut är tyvärr fortfarande en utopi, principen borde dock användas för att mildra problemet med dancing pigs.

Så, trots 40 år på nacken är principerna precis lika aktuella idag.

Såg just att kollega Christoffer också har skrivit om gammal hederlig säkerhet och enkelhet, ta en titt.

Trevlig påsk!

Kerckhoffs princip

The entire security of a cryptographic algorithm should be based exclusively on the confidentiality of its key, rather than the confidentiality of the algorithm. -August Kerckhoff (1835-1903)

Joachim Strömbergson på Secworks ger idag fenomenala exempel på brott mot Kerckhoffs princip. De är hämtade från verkligheten och är bra att ha i beredskap för att tvinga ner förvirrade leverantörer i partär.

En effekt av att säkerheten ligger i nyckeln är att man har hemligheter som är lätta byta ut vilket är eftersträvansvärt, något som Joachim förstås tar upp. Artikeln är lång men läs den i alla fall.

Själv har jag en lite ful ovana att referera till Kerckhoff även i frånvaro av kryptografi. Säkerheten i ditt nätverk ska t ex inte bero på huruvida en angripare kan se vilken version av BIND du har. Här brukar man använda det lite sexigare begreppet security by obscurity men det är mer eller mindre samma sak.

Trevlig helg!

Hälsa och säkerhet

Bloggrannen Cornucopia? skrev i veckan om AstraZenecas förargliga varsel i Södertälje och fick en kommentar från en läsare (Cornus fetstil):

Precis min spaning; och jag råkar vara utbildad läkare. Att KI eller AZ skulle syssla med att främja människors ”hälsa” är naturligtvis skrattretande absurt. Deras levebröd är just att människar har ohälsa, och där finns alltså inget som helst incitament att främja någon ”hälsa”. Hälsa främjas, precis som du skriver, av motion, tallriksmodellen, solsken, meningsfullt socialt liv, närhet, och i bästa fall kärlek. Lejonparten av dagens läkemedel har i princip syftet att minska biverkningarna från felaktig kost, stillasittende, och ensamhet. Att främja hälsa är extremt enkelt och billigt – mycket svårt att tjäna pengar på dvs. Att producera molekyler kallade läkemedel har däremot stora profitmarginaler.

Det kan vara det nyktraste jag läst på länge och jag kan inte låta bli att dra paralleller till säkerhetsbranschen. Det är svårt att tjäna pengar på säkerhetsarbete genom att:

  1. Förorda ordning, reda och disciplin.
  2. Hävda att man inte ska lägga all kraft på att förebygga problem.
  3. Säga att säkerhet är enkelt, det handlar bara om att göra det.
  4. Förespråka öppenhet gällande säkerhetsproblem.
  5. Tjata om att övning är viktigt.

Vad sysslar jättarna i branschen med? De stora är de som utvecklar och säljer produkter. Jag undrar om det verkligen är att gå för långt att använda den andra meningen i citatet ovan för att beskriva de flesta.

Analogin haltar lite. Vi har nämligen en extraordinär omständighet i vår bransch, något vi i princip bara delar med Polisen och Försvarsmakten; vi har intelligenta, antagonistiska motståndare. Motståndare gör säkerhet svårt. Inom ”hälsovården” har man inga intelligenta motståndare.

Det är fortfarande en mycket tänkvärd liknelse.