Det Svageste Led
Kursus på ITU
Informationssikkerhed er egentligt et meget simpelt koncept. De rigtige mennesker skal have adgang til de rigtige ressourcer på det rigtige tidspunkt. Eller Confidentiality, Availability, Integrity for at blive i det udenlandske. Det får jeg gentaget en del gange, da jeg underviser som ekstern lektor på ITU, og i dennne semester hedder kurset 'System Arkitektur og Sikkerhed'.
Jeg har rodet i Enterprise Arkitektur kassen, og taget Governance brillerne på, og bruger kurset til at få de studerende til at tænke i helheder - fra hardware, kode, process, ledelse, procedurer, igennem de forskellige organisationslag, netop fordi sikkerhed ikke er i koden, ikke er i netværket, men er en kontinuerlig process, og en måde speciel måde at tænke på sine informationer. Vi finder ud af hvordan en udviklingsprocess skal påvirkes, hvor arkitekturen bliver skabt som en form et system kan udvikle sig i, og hvilke punkter i processen er vigtige berøringspunkter i forhold til informationssikkerhed.
Beskyt dit svageste led
Det vigtigste sikkerhedsprincip over dem alle hedder 'Beskyt dit svageste led', fordi sikkerhedsniveauet er aldrig bliver bedre end netop det svageste led. En forudsætning for at beskytte det svageste led, er at man kender det svageste led.
En del af kursuslitteraturen er den meget morsomme splinternye bog "24 Deadly Sins of Software Security", den kan varmt anbefales som morsom og hyggelig læsning! Den gennemgår systematisk de værste bommerter en udvikler eller arkitekt kan begå som Synder - og heldigvis fortæller den også hvordan man kan opnå Syndsforladelse.
En af synderne er en sårbarhed overfor Social Engineering - dvs manipulation med folk i en organisation, hvor angriberen udnytter respekt for autoriteter eller andre sociale mekanismer, til at tiltvinge sig adgang til følsomme data. For eksempel, kan en angriber ringe til systemadministratoren, udgive sig for at være en meget travl og vred mellemleder, der lige skal have nyt password, fordi han ellers ikke kan logge på, og han har en meget vigtig præsentation om en halv time. Traditionelt er det en lidt overset disciplin, bliver betragtet som lidt tøset, og ikke noget som bliver taget helt så alvorligt når en sikkerhedspolitik skal implementeres, som det fokus der bliver lagt på at finde diverse software huller.
Hacking konkurrence
Vores kursus bliver i princippet kørt som en hackingkonkurrence mellem teams af studerende. Der er selvrespekt, øl og kage på spil - de studerende har en virtuel maskine hver, kender hinandens ip adresser, og er ansvarlige for at sende en portal applikation online. Der er frit spil for at skyde hinanden ned, og man er jaget vildt såsnart man er online.
Forleden fandt hele holdet ud af hvor effektivt et Social Engineering angreb kan være.
En email blev sendt rund til de andre grupper, et par dage efter deadline på en projektleverance:
I am reading your code, and need to check how the application runs on your machine. I attach my public signature, please create a user for me. ... Agata
Den gruppe som stod bag angrebet fortalte, at de var nødt til at gøre sig umage, og efterligne min e-mail tone - og at de har udnyttet en observation om at der kan gå et par dage mellem jeg svarer på mails fra de kære studerende.
3 ud af 7 hold hoppede på den - dette er en hit rate på over 40 %.
At få fuld adgang til en server er den største kompromitation, man kan udsætte et konkurrende hold for.
Det blev en våd aften i fredagsbaren på ITU da alle de mange øl skulle bytte ejer - og jeg tror ikke på at nogen fra klassen nogensinde underestimerer det svageste led igen.
Det svageste led? Det er os, brugerne!
Kommentarer (11)
Det er præcis derfor man ikke skal give brugerene større privilegier i det daglige arbejde end de lige præcis har brug for. Man giver jo heller ikke hovednøgler til alle ansatte. De skal kun have adgang til de rum hvor de har noget at gøre. Tænk nu hvis de får stjålet deres nøgler.
I et system hvor der er sørget for det ville svaret blive:
Ok. I have forwarded your mail to my systemadministrator.
Best regards
Jorgen
-
0 -
0
God case
Men også en farlig standardholdning
Man kunne også tage et skridt videre og sige at det svageste led er udviklerne som i det hele taget arbejdede med en rettighedsmodel som betyder at NOGEN eller NOGET kan få systemet til at fejle på den måde.
Eller bestillerne som selv vil have magt til at lave override og dermed har bestilt et system som by design er dømt til at blive udnyttet til ikke-legitime formål.
Det er ikke brugerne som fejldesigner systemet - de beder ikke om at skulle administere det umulige.
-
0
-
0
Jeg tror at en vigtig ting er at man ikke må oversikre. Hvis passwords udløber i tide og utide og man skal have tildelt adgang fra administratoren til alt muligt og man i øvrigt ikke kan bruge sit nøglekort til naboafdelingen eller udenfor et fastsat tidsrum så kommer mulighederne for social engineering.
Hvis det er dagligdag at folk har loginproblemer så er det ikke nogen overraskelse eller noget man tænker særligt over i supportafdelingen hvis man får en stresset medarbejder i røret som skal have et login, og det skal helst være for et kvarter siden.
Og når en nyansat som arbejder på det foregående skift ikke kan komme ind for at hente sin taske fordi klokken er syv minutter over fyraften, så lukker man ham ind.
Det bør være en dyd at implementere den mængde af kontrol som giver mening, og ikke mere. Hvis ikke det er på et niveau som de ansatte kan forstå og acceptere, så kan man lige så godt lade være, for det nytter ikke noget, i værste fald tvært imod.
-
0
-
0
Det bør være en dyd at implementere den mængde af kontrol som giver mening, og ikke mere.
Præcist. Nu var eksemplet bare at man blev bedt om at oprette en ny bruger. Det er ikke noget som normalt ligger indenfor den alm. brugers privilegier og det bør det efter min mening heller ikke være.
-
0
-
0
Hvis du går ud fra eksemplet så står der RINGE, til SYSTEMADMINISTRATOREN. Hvilket vist ikke var det tilfælde du svarede på.
Oprettelse af brugere er selvfølgelig normalt ikke en funktion som man har brug for at sprede vidt og bredt.
Min pointe er at det må ikke blive dagligdag at folk har brug for at få oprettet en ny brugerkonto, fx fordi de har glemt månedens password eller ikke som standard har ret til at logge på computeren i et mødelokale, eller hvad ellers it administrationen nu måtte have fundet på i sikkerhedens navn. For så kan systemet angribes blot ved at imitere en almindelig bruger.
-
0
-
0
Jeg synes diskussionen her kører lidt skævt - siden hvornår er et system hacket fordi man opretter en brugerkonto? Måske i den specifikke case, men generelt?
Problemet er snarere opgradering af rettigheder så man kan få adgang til andres brugerkonti, etablere autorisationer, få adgang til ressourcer eller lignende.
Selvom systemfolk gerne vil have brugerne til at fremstå som det svage led, så er det i praksis systemfolkene selv som er de væreste - de har de rettigheder som kan skaleres til angreb. Så længe det at snyde en bruger kun kan skade brugeren selv, har man et feedback-system.
Så er øvelsen at minimere (forebygge) den skade der kan ske, maksimere systemets evne til at genskabe situationen, sikre redundans ved fejl etc.
-
0
-
0
Selvom systemfolk gerne vil have brugerne til at fremstå som det svage led, så er det i praksis systemfolkene selv som er de væreste - de har de rettigheder som kan skaleres til angreb. Så længe det at snyde en bruger kun kan skade brugeren selv, har man et feedback-system.
Meget enig Stephan. Grundreglen er at hvis der sker en fejl, så er det næsten altid ledelsens skyld. Det gælder også indenfor IT. Det kan så skyldes en egentlig sikkerhedsbrist eller det kan skyldes at man anvender systemer, som gør det kompliceret for brugeren at opretholde sikkerheden.
-
0
-
0
Hele problemet drejer sig om informationer, og hvem der har ret til at kontrollere adgangen til informationer. For meget magt og for mange privilegier, kombineret med en menneskelig tilbøjelighed til tillid har ledt til de fleste historiske sikkerhedsfejl - og blev så eftertrykkeligt prøvet af de studerende.
Sikkerhedshændelser sker mere sjældent pga fx kryptografisk svaghed, som pga menneskelige fejl og brister - hvilket gør at flasken peger tilbage tilbage til dem der har udviklet og designet systemet. Hvergang vi tildeler unødvendige privilegier, indfører klumsede sikkerheds flows der ikke passer ind i brugernes dagligdag, bygger vi et potentiel sikkerhedshul.
Tak for kommentarerne Steffen, Jørgen og Jakob -vi er meget enige.
-
0
-
0
Under 2. Verdenskrig blev kryptosystemerne ofte brudt ved at mennesker begik fejl med systemerne i stedet for at systemet i sig selv blev angrebet.
Umiddelbart lader det til at det kan ophøjes som en grundregel at kryptosystemet ikke er det sted hvor der brydes ind. I stedet angribes enten software omkring kryptosystemet eller menneske-maskin-interaktionen mellem bruger og system. Det er en gammel klassisk metodik som går igen.
-
0
-
0
Agata,
Som sagt indledningsvis - det var en god case, specielt i studieøjemed.
Jeg har af nødvendighed (i erkendelse af det eksponentielt tiltagende sikkerhedsnedbrud) tvunget mig selv til at fokusere på Security By Design, dvs. aldrig at antage tillid fordi det åbner en sikkerhedsrisiko.
I den konkrete sag kunne man stille spørgsmålet - hvorfor overhovedet have en bruger på applikationsserveren - hvilket formålet tjener det og hvordan kunne man etablere det samme på en måde som ikke kan misbruges.
Pointen er ikke at man nødvendigvis kan gøre det perfekt. Men der sker 2 ting. For det første isolerer man risici til dem man ikke kan håndtere. For det andet forstår man risikomodellen langt bedre.
Giv de studerende en følgeopgave - kom med de bedste bud på hvordan man lave systemer som ikke kan hackes via social engeneering og hvad det vil sige!? Et svar skal formentlig ses i en bestemt kontekst, dvs. en bestemt type system.
-
0
-
0
