Det redder dig ikke. Da den Windows computer har adgang til internettet og ikke er mere sikker end Microsoft nu engang er i stand til(!), kan du ikke garantere, at den ikke indeholder virus, keyboard loggere etc., så hvordan vil du taste krypteringsnøgler ind og gemme dem på en sikker måde?</p>
<p>Som jeg skrev i mit punkt 2, må SRO-enheder ikke benyttes til anden internetadgang, og det kan du aldrig nogensinde garantere med Windows, Android, iOS og lignende. De vil jo bl.a. vil have lov til at checke for opdateringer engang imellem, og hvem garanterer, at opdateringerne er sikre?</p>
<p>Der er kun én vej. Hold det så simpelt, at kun dit eget software kommunikerer med internettet, så du selv "er dørmand" og har 100 % styr over, hvad der sendes ud og lukkes ind, og kan logge begge dele, så du opdager, hvis noget eller nogen kommunikerer bag din ryg.

Jeg har i mange år anbefalet, at man indbygger en sikkerhedsalgoritme i tastaturet, således at tastaturet genererer koder, der garanterer at det indtastede kommer fra tastaturet, og hver tastatur har eget ID. Algoritmen må naturligvis ikke kunne brydes. Password må ikke kunne opsnues af computeren - forsøges at indtaste password, så vil tastaturet blokere, når der er indtastet nok af passworded til at tastaturet ved det er passwordet. En sikkerhedsalgoritme i tastaturet vil dog tvinge til at der anvendes en simplere brugergrænseflade i tilfælde hvor der skal være stor sikkerhed, da der ikke må være mulighed for at redigere med f.eks. mus, da den ikke går igennem sikkerheden. Dertil skal redigeringen være så simpel, at tastaturet kan håndtere redigeringen, f.eks. er muligt at tastaturet kan håndtere rettelse med backspace og insert/delete. Man kan også bygge et kodeapparat, der sættes mellem tastatur og computeren. Jeg vil dog her foretrække, at der af sikkerhedsårsager anvendes en protokol hvor data og koder fra tastaturet kun sendes fra tastatur til PC, og hvor der ikke er muligt data går den omvendte vej. Det skal være muligt, at fysisk verificere at krypteringsordningen har en envejsforbindelse og tastaturet incl. kodemaskinen, ikke kan få data på nogen måder fra computeren, f.eks. ved at der sættes buffere ind, der forhindrer at hackere kan hacke selve tastaturets chip og kodechip. Er der mulighed for kommunikation i begge retninger, må man som udgangspunkt antage, at formålet er at indlægge en bagdør, måske en obligatorisk bagdør til FBI/CIA. Metoden med at indføre en verificerbar retningsbestemt forbindelse, der kun giver mulighed for datatransport i en retning, er ofte også nødvendigt, selvom man laver alt hardwaren selv - for man kan være sikker på, at nogen af de ansatte, eller indbygger en mulighed for opdatering eller lign. og en eller anden fjols der er direktør eller leder projektet, måske endda sætter det som krav. Er det ikke verificerbart, at det er gjort korrekt, ved at man kan skilde produktet ad, så vil det altid indehold en eller flere bagdøre. Det kan undgås, ved at sætte en retningsbestemt buffer ind, så data kun går i en retning, f.eks. via en RS232 protokol med fixed hastighed der kun har TxD og ikke handshaking, da handshaking vil give sikkerhedsrisiko.

så vi er tilbage i grundspørgsmålet om, hvordan virusen i det hele taget kom ind på anlægget.

Den blev båret ind. Officielt via en USB stick plantet på en "dum" arbejder. Men det kan ligeså godt være en agent der plantede virusen helt inde i kontrolsystemet. Alverdens sikkerhed hjælper ikke hvis en med officiel adgang vælger at blive agent - frivilligt eller under tvang. Det er derfor du ikke kan få højeste sikkerhedsgodkendelse hvis du har gæld, eller på anden vis vurderes at være sårbar for afpresning.

Parameter: en ventil der skal lukkes på grund af en overgravning, en pumpe der skal justeres på grund af ændringer i belastning eller andre forhold etc.

Den slags er da helt almindelig styring og regulering, som selvfølgelig skal være mulig fra sikre SRO enheder. Allerede for omkring 40 år siden kunne vi koble hjemmelavede debugenheder på Søren T. Lyngsø's STL-net, og det havde været lykken, hvis vi kunne have haft et internet imellem, så vi ikke havde behøvet at rejse ud for at debugge, styre og/eller lave smårettelser. Der bør dog være en nøgleafbryder på anlægget, som kan slå muligheden for at ændre i PLC-software til og fra, så der kun åbnes i de perioder, hvor det er nødvendigt. Alt for mange funktioner står hele tiden pivåbne på alt for mange systemer. Hvis Maersk havde haft en sådan afbryder på deres PC'er, kunne de havde sparet milliarder af kr., for så ville ransomware og andre opdateringer blive blokkeret, indtil en kyndig IT-medarbejder, der ikke klikker OK til hvad som helst, kommer med nøglen; men den mulighed er der "selvfølgelig" ikke på PC'er :-(

I Iran var det eneste der blev justeret hastigheden på centrifugerne således at de ødelagde sig selv over tid.

Ja; men det var netop ikke betjeningpersonalet, der gjorde det. Havde man kunnet holde denne virus ude, var der ikke sket noget, så vi er tilbage i grundspørgsmålet om, hvordan virusen i det hele taget kom ind på anlægget.

Sidste år kom en ny standard om Security i IoT devises. ISO/IEC 27030 Hvis andre IT systemer efterlever samme niveau for sikkerhed så er det måske en god start, men måske ikke tilstrækkeligt hvis det er samfundskritisk IT

Nej. netop ikke. Hvilke parametre skal sættes bortset fra krypteringsnøgler, som, hvis de bliver sat forkert, lukker én selv ude?

Parameter: en ventil der skal lukkes på grund af en overgravning, en pumpe der skal justeres på grund af ændringer i belastning eller andre forhold etc. I Iran var det eneste der blev justeret hastigheden på centrifugerne således at de ødelagde sig selv over tid.

Nogen skal kunne justere på diverse parametre og dermed er der en måde disse paramtre kan sættes forkert eller ondsindet.

Nej. netop ikke. Hvilke parametre skal sættes bortset fra krypteringsnøgler, som, hvis de bliver sat forkert, lukker én selv ude?

Det kunne tilmed være en betroet ansat der går ind og gør det i sympati med fjenden.

Ja; men så taler vi ikke om IT-sikkerhed, for den ansatte er jo netop betroet til at måtte styre fra sit SRO-system. Han kan jo også bare tage ud på anlægget og smadre det hele.

Det, vi diskuterer her, er muligheden for, at bl.a. russiske eller kinesiske statshackere kan styre rundt med vores kritiske infrastruktur og lukke det hele ned.

Jeg er ellers enig med dig i resten af dit indlæg; men det er stort set kun Banedanmark og måske elselskaberne, der i praksis kan etablere egne, helt lukkede net, for det kræver adgang til kabelkanaler. Alle andre må benytte internettet eller et "Adidas net", hvis det er nede; men det ser jeg heller ingen problemer i - bare man gør det så simpelt, at man kan overskue alt og dermed garantere sikkerheden.

Selvom et industrisystem er sikkert, er det ofte lavet til at kunne kommunikere med Windows. Det betyder, at en operatørs computer kan være kompromiteret, og adgangen går via Windows, selvom selve industricomputeren er sikker. Jeg foretrækker derfor sikkerhed der svarer til NEM-ID hvis det tilgås fra en windows eller linux computer, altså, at der anvendes engangskoder, enten fra en hardwaregenerator, eller mere simpelt med et nøglekort.

Det redder dig ikke. Da den Windows computer har adgang til internettet og ikke er mere sikker end Microsoft nu engang er i stand til(!), kan du ikke garantere, at den ikke indeholder virus, keyboard loggere etc., så hvordan vil du taste krypteringsnøgler ind og gemme dem på en sikker måde?

Som jeg skrev i mit punkt 2, må SRO-enheder ikke benyttes til anden internetadgang, og det kan du aldrig nogensinde garantere med Windows, Android, iOS og lignende. De vil jo bl.a. vil have lov til at checke for opdateringer engang imellem, og hvem garanterer, at opdateringerne er sikre?

Der er kun én vej. Hold det så simpelt, at kun dit eget software kommunikerer med internettet, så du selv "er dørmand" og har 100 % styr over, hvad der sendes ud og lukkes ind, og kan logge begge dele, så du opdager, hvis noget eller nogen kommunikerer bag din ryg.

Det handler ikke om sikkerheden i Windows eller i hardware. Problemet er i stor grad organisatorisk. Lukkede netværk er meget svære at hacke men af organisatoriske årsager åbner man bevidst huller ind i nettet som kan udnyttes.

Lad os kigge på to eksempler. Hos Banedanmark har de et lukket netværk med egne fiberkabler liggende langs skinnerne. Signalsystemet kommer ikke i nærheden af det offentlige internet. Fjernstyring sker på et centralt sted hvor man har dedikerede skærme og computere, der ikke er koblet på det offentlige internet. Operatøren har en anden computer han bruger til email og lignende. Adskild skidt fra kanel. Der er et såkaldt "air gap" mellem det kritiske system og resten. Et sådan system er meget meget svært at hacke og der er kun få offentlig kendte eksempler på at det er sket.

Som modeksempel kan vi tage et lille regionalt vandværk med 10.000 tilslutninger. Det er en meget lille organisation. Der er måske kun 1-2 med teknisk forståelse. Disse to personer kan ikke side i et kontrol tårn og overvåge systemet 24 timer i døgnet. Derfor har de en VPN adgang via deres laptop, så de kan logge ind uanset hvor i verden de befinder sig. Og det er en stor svaghed idet denne laptop måske bliver kompromiteret. Og måske endnu mere almindeligt, så har de ikke så megen viden om sikkerhed hos det lille vandværk, så det kan være at der slet ikke er en VPN men bare et åbent web interface hvor de tilmed har glemt at ændre standardkodeordet - det er set.

Der er et meget kendt hack af Irans urancentrifuger. Dette var et stærkt beskyttet lukket net men alligevel lykkedes det en efterretningstjeneste at smugle ondsindet kode ind til at sapotere centrifugerne. Denne type hacking er IKKE almindelig. Det kan man se i krigen i Ukraine hvor russerne ikke i stor stil har haft held med at lave noget lignende. Ukraines infrastruktur bliver bombet med fysiske bomber ikke med logikbomber. Det er muligt at en fremmed magts efterretningstjeneste kunne ramme Banedanmark på en lignende måde, men det er ikke særligt sandsynligt at det er noget de mere almindelige hackere kan eftergøre.

Og endelig kan man overveje om det overhovedet teoretisk er muligt at gøre det 100% umuligt at et Iran style angreb lykkes. Det er helt ligemeget om man sætter Carsten Kanstrup til at udvikle softwaren eller Jens Madsen til at lave hardwaren. Nogen skal kunne justere på diverse parametre og dermed er der en måde disse paramtre kan sættes forkert eller ondsindet. Det kunne tilmed være en betroet ansat der går ind og gør det i sympati med fjenden.

<em>Eneste mulighed er at lave så meget som muligt i hardware...</em></p>
<p><a href="https://news.cnrs.fr/articles/when-cyber-a..">https://news.cnrs.fr/arti…;.

Hvilke af de metoder mener du, at en hacker udefra, som kun har adgang til internettet, kan benytte sig af? Måle strømforbrug, temperatur og anbringe prober og lignende på et udstyr, han ikke har adgang til?

Så vidt jeg husker, arbejder du med telekommunikation. Hvis det er rigtigt, hvorfor har I så blacklistet Huawei udstyr? Det burde da være "a piece of cake" "bare lige" at kikke koden igennem og sikre sig, at der ikke er nogen bagdøre, og at kineserne ikke lytter med og/eller kan styre og nedlukke systemet. De er jo villige til at åbne koden, så hvad er problemet?

Eneste mulighed er at lave så meget som muligt i hardware...</p>
<p><a href="https://news.cnrs.fr/articles/when-cyber-a..">https://news.cnrs.fr/arti…;.

Eneste mulighed er at lave så meget som muligt i hardware...

https://news.cnrs.fr/articles/when-cyber-attacks-target-hardware

Giv mig bare én eneste grund til, at verdens største softwarefirma, der så vidt jeg husker har over 1000 sikkerhedseksperter, f.eks. tillader, at en tilfældig hjemmeside kan installere programmer på min computer, der krypterer min harddisk uden at spørge om lov først! I software, der stykkes samme af tilfældige moduler, ser det formodentlig endnu værre ud.

Selvom et industrisystem er sikkert, er det ofte lavet til at kunne kommunikere med Windows. Det betyder, at en operatørs computer kan være kompromiteret, og adgangen går via Windows, selvom selve industricomputeren er sikker. Jeg foretrækker derfor sikkerhed der svarer til NEM-ID hvis det tilgås fra en windows eller linux computer, altså, at der anvendes engangskoder, enten fra en hardwaregenerator, eller mere simpelt med et nøglekort. Til nød, kan man måske genbruge numrene på et nøglekort, hvis der går lang tid imellem. Og der skal også være password. Der kan evt. også anvendes SMS, men om det er så sikker ved jeg ikke.

Angrebsvektorerne er ikke netværket, men de komponenter og den software som styrer systemet. Derfor er det sikkerheden omkring disse komponenter der skal sættes fokus få.

Enig; men tror du på, at nogen nogensinde vil få det overblik?

Kikker man på Windows's historik, er der næsten med garanti mindst hundrede alvorlige sikkerhedshuller i Windows 11, og langt størsteparten af dem findes ikke af Microsoft, men af hackerne - Black-Hat såvel som White-Hat. Giv mig bare én eneste grund til, at verdens største softwarefirma, der så vidt jeg husker har over 1000 sikkerhedseksperter, f.eks. tillader, at en tilfældig hjemmeside kan installere programmer på min computer, der krypterer min harddisk uden at spørge om lov først! I software, der stykkes samme af tilfældige moduler, ser det formodentlig endnu værre ud.

Grundproblemet er de sindsygt og unødvendigt komplicerede protokoller og standarder, der anvendes, og som betyder, at meget få magter eller vover at skrive de nødvendige gigantiske kodemængder selv og endnu færre kan overskue systemet i alle detaljer. God fornøjelse hvis du f.eks. selv vil skrive al koden til Matter over Thread, som er den nye, "hotte" smart house standard.

Det er en håbløs kamp, som man aldrig kan vinde, når ikke engang Microsoft kan. Eneste mulighed er at lave så meget som muligt i hardware og så simplificere protokoller og software, så man har en chance for at overskue og teste det. Ifølge sikkerhedsstandarden IEC 61508 anses hardware for at være så meget mere stabilt og forudsigeligt end software, at kravene til et givent SIL niveau er 10 gange mindre.

KISS - Keep It Simple Stupid!

Jeg tror også, at producenterne ofte intet gør for at sikre sig mod hacking af systemerne. F.eks. har jeg hørt, at det skulle være relativt nemt at hacke et vandværk. Om det er korrekt, ved jeg ikke.

Mange industrisystemer anvender Linux eller Windows CE. Hvis der er sårbarheder i disse systemer - hvilket vi må antage - så giver det anledning til en stor fælles sikkerhedsrisiko for alt der anvender disse systemer.

Industrien bruger ofte SCADA, der vist skulle indeholde en obligatorisk bagdør til CIA.

Jeg har en forkærlighed for små microcontrollers, f.eks. ESP32. Her er dog indbygget software i ROM, og om det giver mulighed for hacking ved vi ikke. ESP32 er kinesisk - det er ikke en sikkerhed i sig selv, men jeg tror, det er mere sikkert, end produkter udviklet i USA.

Infrastruktur bliver ikke hacket ved at nogen bryder ind i militærstyrke VPN (som IPSEC er). Det bliver hacket ved at hacke den computer der bruges til at fjernstyre anlægget.

Et væsentligt element her er, hvilken oprindelse komponenterne her - hvor kommmer hardwaren fra, hvike moduler indgår i softwaren og hvor kommer de fra. Oven på det skal lægges de metoder der anvendes til opdatering af komponenterne, f.eks. hvem der gør det, hvordan ny software er testet og hvordan og af hvem den er frigivet osv.

SRO software komme ofte kun delvist fra producenten selv, men består af 10, 100 eller tusindvis af standard moduler hentet fra mere eller mindre dubiøse directories, hvor kilderne ofte har en meget lav eller ingen opfølgning på sikkerheden og hvor det er vanskeligt at gennemskue hvad modulerne egentlig har af egenskaber (du over dem man lige selv bruger i egen software).

Jeg har gennem årene set mange grimme eksempler på dedikeret software, sammensat af tvivlsomme moduler, og uden at leverandøren havde et overblik over hvad der lå i dem. Resultatet er, at leverandøren er næsten hjælpeløs når en sårbarhed udnyttes - han aner i mange tilfælde end ikke, at han bruger disse moduler i sin egen software, og hvis han har styr på det, er alene processen med opdatering af firmware og software lang, kompliceret og potentielt fyldt med nye sikkerhedskompromitteringer.

Punkt 5: Lad være med at opfinde din egen sikkerhedsalgoritme. IPSec med AES og perfect forward secrecy løser alle de ting du nævner og en hel del du ikke engang kender til.

Jeg anbefaler dobbelt sikkerhed: Der anvendes en officiel sikkerhedsalgoritme, plus ens egen sikkerhedsalgoritme. Den officielle kan måske brydes, men den gør at man kan oplyse at det er denne algoritme som er benyttet. Ens egen algoritme oplyser man ikke er anvendt - det er en hemmelig algoritme, der ikke må offentliggøres.

Jeg mener selv, at AES256 er forholdsvis sikker, og den er meget tæt på den måde, at jeg selv vil have lavet en sikkerhedsalgoritme. Men, jeg kombinerer altid sikkerhedsalgoritmer med metoder jeg selv finder på til lejligheden. Disse metoder sikrer, at det f.eks. ikke findes en måde, hvorpå at man kan finde sikkert ud af, om et kodeord er den rette eller ikke. Kan man på ingen måde, udregne om et kodeord er den korrekte, så er det meget svær for computere at bryde koden, for de kan ganske enkelt ikke se på det dekrypterede om det er det korrekte eller ikke. Er det f.eks. en tekst, så vil de fleste kodeord give et svar at koden er forkert, andre vil give det rene garbage, og mange vil give noget der ser korrekt ud, og måske er der direkte forkerte svar tænkt som misinformation, der oftest vælges. Vælges et forkert kodeord, så vil der således findes mange kodeord, hvor resultatet ser ganske korrekt ud, og oplyses af programmet er korrekt, men måske er bevidst men sandsynligt misinformation.

Du skal altid sørge for, at der findes en eller flere koder, der giver et fornuftigt resultat, men som du "frit" kan give ud til dem der er for nysgerrige.

Punkt 5: Lad være med at opfinde din egen sikkerhedsalgoritme. IPSec med AES og perfect forward secrecy løser alle de ting du nævner og en hel del du ikke engang kender til.

Ja, hvis koden er sikker; men hvem kan overskue det med de sindsygt komplicere protokoller, der anvendes?

Der har været hundredevis af alvorlige sikkerhedshuller i samtlige versioner af Windows og op mod tusinde i vist nok Windows XP, og selv efter flere års brug finder man graverende fejl i standard softwarepakker, som rigtig mange benytter. Det er mit helt klare indtryk, at størsteparten af de sikkerhedsproblemer, vi har idag, skyldes, at tingene er blever så kompliceret, at programmørerne ikke længere kan overskue, hvad de selv laver! Derfor overlader de nu sikkerheden til 3. part i form af antivirus programmer, og gamle fru Olsen må "selvfølgelig" ikke klikke på en usikker link - hvordan i alverden hun så skulle kunne vide det på forhånd.

Hvis man tror, man kan implementere 100 % sikkerhed i software, er man hamrende naiv og lukker øjnene for dagens realiteter! Den tyrkertro har kostet Maersk og mange andre milliarder af kr. Jo mindre software, jo bedre, og mit forslag kræver kun få linjers kode, som er til at overse og teste, noget tilfældigt "salt" med bl.a. verificerbart indhold, som f.eks. tiden, plus en chip, som kan kryptere i ren hardware.

Kan du eller andre finde nogen huller i mit forslag, hører jeg meget gerne om det. Det er bl.a. én af årsagen til at offentliggøre det her, da jeg godt kunne finde på at benytte metoden til mit smart-house- og industristyringssystem Max-i :-)

Infrastruktur bliver ikke hacket ved at nogen bryder ind i militærstyrke VPN (som IPSEC er). Det bliver hacket ved at hacke den computer der bruges til at fjernstyre anlægget. Eksempelvis kan formanden for det lokale fjernvarmeselskab godt lide at følge med fra hans private laptop. Den VPN han benytter er sikker men er hans laptop sikker?

Og det var netop mit punkt 2.

Punkt 5: Lad være med at opfinde din egen sikkerhedsalgoritme. IPSec med AES og perfect forward secrecy løser alle de ting du nævner og en hel del du ikke engang kender til.

Infrastruktur bliver ikke hacket ved at nogen bryder ind i militærstyrke VPN (som IPSEC er). Det bliver hacket ved at hacke den computer der bruges til at fjernstyre anlægget. Eksempelvis kan formanden for det lokale fjernvarmeselskab godt lide at følge med fra hans private laptop. Den VPN han benytter er sikker men er hans laptop sikker?

Hvorfor kobler man kritisk infrastruktur op på det offentlige internet?

Det er nemt at svare på. Fordi det er yderst praktisk at kunne styre, overvåge og opdatere et anlæg over nettet, som det også skrives i artiklens svar.

Spørgsmålet burde i stedet lyde:

Hvorfor er man så tåbelig at give hackerne mulighed for at trænge ind, når det med simple midler kunne undgås?

Punkt 1 - Ingen udveksling af krypteringsnøgler over nettet. Det er helt overflødigt, da de kan tastes ind i både procesanlægget og SRO-enhederne (Styring, Regulering og Overvågning) under idriftsættelsen.

Punkt 2 - SRO-enhederne må kun bruges til styring og overvågning - ikke til generel internetadgang - og de skal helst også programmeres i andet end de kendte operativsystemer, som f.eks. Windows, Android og iOS, så de med sikkerhed kan holdes virusfri. Det er umuligt at skrive en virus til et system, som man ikke har det mindste kendskab til, og selv om man kunne, kan man ikke installere den, hvis installation af nye programmer er hardwaremæssig blokkerer med en nøglekontakt. Det ville have været muligt på en Commodore Amiga 2000 for 35 år siden, men er det ikke i nyere operativsystemer, fordi de konstant skal have skriveadgang til alt, så der også er frit slag for ransomware etc. Hvor tåbelig kan man dog være?

Punkt 3 - Anlægget skal styres med lokal automatik (Edge) - ikke fra en cloud i Langtbortistan, hvilket er helt unødvendigt. Det sikrer også mod konsekvensen af kabelsprængninger i en krigssituation

Punkt 4 - Lav en 2-trin kryptering med "salt", så en given kommando ikke giver anledning til samme telegram hver gang, og giv en tidsstraf på f.eks. 5 minutter, hvor internetadgangen til anlægget ganske simpelt er hardwaremæssig blokkeret for alle - også én selv, hvis en hacker kommer igennem første led, men bliver blokkeret i andet. Selv med simpel 2 x 56-bit double DES vil jeg påstå, at det er umuligt at trænge igennem et sådant system uden at kende krypteringsnøglerne. Første led sikrer, at et fejlslagent angrebsforsøg ikke lægger forbindelsen ned for alle bortset fra hver 2^56 = 72 x 10^15 gang, hvilket med 1 million forsøg pr. sekund vil ske hvert 2285 år, hvilket vel er til at leve med. Andet led giver den nødvendige sikkerhed, for ved f.eks. 2^56 gange 5 minuter dødtid vil det tage i gennemsnit 350 milliarder år at komme gennem det, selv om man fastholder krypteringsnøglen til første trin, hvilket dog er usandsynligt, da en hacker ikke kan se hvilket led, der blokkerer ham. En hacker kan højest lægge internetadgangen ned med et DDoS angreb; men så kører anlægget bare videre på sin lokale styring, og man må så køre ud til det, hvis man vil styre, overvåge eller ændre.

Problemet er igen, igen, at man har lukket IT-nørderne ind i automationsverdenen med deres ekstremt komplicerede metoder, som de også vil kunne benyttes på steder, som f.eks. datacentre, som man ikke kan tillade sig at lægge døde i bare få minutter, og at man vil kunne udveksle krypteringsnøgler over nettet.

Meget ville sikkert være vundet, hvis forklaringen tog udgangspunkt i en skitse, som viser to parallelle netværk. Alle forklaringer vinder ved visualisering - som minimum klares tankerne hos forfatteren af forklaringen.

Forklaringen skulle så fokusere på fordele og ulemper ved at alle benyttede eet netværk (som det mest er i dag), og derefter det samme ved at benytte et andet, lukket, parallelt netværk for de kritiske kommunikationer.

Den simple forklaring er jo, at det har været let og umiddelbart tilgængeligt uden problemer i en fredelig, ideel, verden.

En strøtanke er så, at dette lukkede netværk kunne være Tetra-netværket, som findes, og som har de nødvendige egenskaber. Det er der så også, måske, argumenter imod.

Der er næppe tvivl om, at sikkerhedsrisikoen opstår ved et WWW, hvor enhver deltager kan adresseres med en IP-adresse. Det har i en ideel verden enorme fordele, som vi har set, men det indebærer også, som vi også ser, enerome risici når spøgefugle eller onde mennesker går i gang.