Säkerheten i säkerhetsprodukter
I dagens Computer Sweden svarar Tomas Djurling på en fråga om osäkra lösningar i säkerhetsprodukter. Jag har egentligen inget att invända men skulle vilja ge ett skuggsvar och utveckla frågan en aning samt referera till tidigare diskussioner.
Frågan var om det finns buggar i säkerhetsprodukter i samma utsträckning som det finns i program och operativsystem. Egentligen är frågan rätt enkel att svara på; SQL injection i en inloggningsruta är ett bra exempel på ett säkerhetshål i en säkerhetsfunktion, och det är ju inte särskilt ovanligt. Men eftersom frågeställaren verkade vara ute efter "fysiska" säkerhetssystem vore det kul att diskutera iväg det hela en bit.
Security features != secure features
En gammal sanning i branschen är: säkerhetsfunktionalitet är inte samma sak som säker funktionalitet. Jag pratade om det i stor utsträckning under en presentation på Sundsvall 42 i höstas:
Principen kan tolkas på två sätt och båda är relevanta. Dels som att (1) säkerhetsfunktionalitet inte betyder att systemet är säkert. Internetbanken är inte säker bara för att kommunikationen mellan bank och dator är krypterad, även om krypteringen är riktigt utförd. Vidare kan principen uppfattas som att (2) säkerhetsfunktioner behöver inte vara säkra, de kan ha buggar.
Notera särskilt den senare uppfattningen, (2). ASSA (låstillverkarna) gav oss ett skinande exempel på detta under 2008 när det visade sig att deras paradprodukt ASSA EVO gick att öppna från utsidan med ett bladmått. Låset (den renaste formen av säkerhetsprodukt) hade ett säkerhetshål.
Vanliga lås
Här rör det sig om en säkerhetsprodukt i form av ett "vanligt lås", vi försöker extrapolera lite. Nycklar är, precis som lösenord, jobbiga att hantera. Om någon tappar bort en nyckel, eller ännu värre, en huvudnyckel, har man ett allvarligt problem. Eftersom en nyckel egentligen bara är en bärare av information (nyckelämne och djupet på varje hack) kan du inte känna dig säker bara för att nyckeln återfunnits, någon kan ha gjort en kopia på den. Det enda du kan göra är att byta ut alla låskolvar, alternativt installera ytterligare ett lås på varje dörr.
Digitala lås
Den digitala världen kommer dock till undsättning och ger oss möjligheten att låta en godtycklig grupp nycklar öppna samma lås samt en nyckel öppna en godtycklig grupp lås. Man kan se det som att alla nycklar är olika och varje lås har en lista på vilka nycklar som får öppna låset. Om både du och jag har en varsin nyckel som kan öppna låset och jag sumpar min kan vi helt enkelt ta bort den ur låsets lista. Din möjlighet att öppna låset påverkas inte och jag kan få en ny nyckel som läggs in i listan. Kanon.
Centralstyrning
Men, eftersom vi tenderar bygga hus med kolossalt många dörrar (och är rätt lata) är det inte särskilt praktiskt att behöva promenera runt till varje dörr och ta bort förlorade nycklar. Vi behöver central administration. Vi behöver kunna kommunicera med låsen på distans.
Sådan här kommunikation har traditionellt skötts med hjälp av LON, MODBUS och diverse andra (för de flesta) obskyra kommunikationsstandarder. Det här gäller naturligtvis inte bara dörrlås; massor av andra teknologier njuter i hög grad av den centralstyrning som möjliggörs av kommunikation. Inte är det någon vaktmästare som går runt till varje termostat i Turning Torso en gång om dagen och justerar gränsvärdena. Tidpunkten för då fasadlamporna på DN-skrapan tänds och släcks ställs naturligtvis inte in på ett vred på varje lampa. Någon sköter det här från en central manöverpanel någonstans i källaren.
Ute på djupt vatten
Någonting har dock skett, jag vet inte vad, men sådan här kommunikation har börjat krypa över mot TCP/IP och häri ligger ett av huvudproblemen för de branscher som länge jobbat i en verkstad skyddad av obskyra kommunikationsprotokoll. I samma veva som det sker en övergång mot välkända, öppna protokoll ökar komplexiteten i dessa system i och med detta. Det här skiftet har gjort och kommer att göra situationen värre.
I en intervju i AffNyheter (pdf) (fastighetsbranschens tidning) från i början av 2009 sa jag ungefär samma sak som Tomas Djurling skrev i Computer Sweden idag. Då handlade det inte bara om passersystem utan alla slags system för fastighetsautomation:
"I samband med övergången till öppna protokoll som baseras på TCP/IP har leverantörerna gett sig in på ett område där kunskap och verktyg för att manipulera tekniken finns i överflöd. Tidigare har de till viss del kunnat förlita sig på att deras teknologier varit för obskyra för att någon skulle intressera sig.", säger Stefan Pettersson.
Problemen med fastighetsautomationens intåg på våra LAN är ett ämne jag har velat skriva om länge. Nu är det dock fredag och det får vara nog med självcitat. :-)
Trevlig helg!
--
Stefan Pettersson
Frågan var om det finns buggar i säkerhetsprodukter i samma utsträckning som det finns i program och operativsystem. Egentligen är frågan rätt enkel att svara på; SQL injection i en inloggningsruta är ett bra exempel på ett säkerhetshål i en säkerhetsfunktion, och det är ju inte särskilt ovanligt. Men eftersom frågeställaren verkade vara ute efter "fysiska" säkerhetssystem vore det kul att diskutera iväg det hela en bit.
Security features != secure features
En gammal sanning i branschen är: säkerhetsfunktionalitet är inte samma sak som säker funktionalitet. Jag pratade om det i stor utsträckning under en presentation på Sundsvall 42 i höstas:
Principen kan tolkas på två sätt och båda är relevanta. Dels som att (1) säkerhetsfunktionalitet inte betyder att systemet är säkert. Internetbanken är inte säker bara för att kommunikationen mellan bank och dator är krypterad, även om krypteringen är riktigt utförd. Vidare kan principen uppfattas som att (2) säkerhetsfunktioner behöver inte vara säkra, de kan ha buggar.
Notera särskilt den senare uppfattningen, (2). ASSA (låstillverkarna) gav oss ett skinande exempel på detta under 2008 när det visade sig att deras paradprodukt ASSA EVO gick att öppna från utsidan med ett bladmått. Låset (den renaste formen av säkerhetsprodukt) hade ett säkerhetshål.
Vanliga lås
Här rör det sig om en säkerhetsprodukt i form av ett "vanligt lås", vi försöker extrapolera lite. Nycklar är, precis som lösenord, jobbiga att hantera. Om någon tappar bort en nyckel, eller ännu värre, en huvudnyckel, har man ett allvarligt problem. Eftersom en nyckel egentligen bara är en bärare av information (nyckelämne och djupet på varje hack) kan du inte känna dig säker bara för att nyckeln återfunnits, någon kan ha gjort en kopia på den. Det enda du kan göra är att byta ut alla låskolvar, alternativt installera ytterligare ett lås på varje dörr.
Digitala lås
Den digitala världen kommer dock till undsättning och ger oss möjligheten att låta en godtycklig grupp nycklar öppna samma lås samt en nyckel öppna en godtycklig grupp lås. Man kan se det som att alla nycklar är olika och varje lås har en lista på vilka nycklar som får öppna låset. Om både du och jag har en varsin nyckel som kan öppna låset och jag sumpar min kan vi helt enkelt ta bort den ur låsets lista. Din möjlighet att öppna låset påverkas inte och jag kan få en ny nyckel som läggs in i listan. Kanon.
Centralstyrning
Men, eftersom vi tenderar bygga hus med kolossalt många dörrar (och är rätt lata) är det inte särskilt praktiskt att behöva promenera runt till varje dörr och ta bort förlorade nycklar. Vi behöver central administration. Vi behöver kunna kommunicera med låsen på distans.
Sådan här kommunikation har traditionellt skötts med hjälp av LON, MODBUS och diverse andra (för de flesta) obskyra kommunikationsstandarder. Det här gäller naturligtvis inte bara dörrlås; massor av andra teknologier njuter i hög grad av den centralstyrning som möjliggörs av kommunikation. Inte är det någon vaktmästare som går runt till varje termostat i Turning Torso en gång om dagen och justerar gränsvärdena. Tidpunkten för då fasadlamporna på DN-skrapan tänds och släcks ställs naturligtvis inte in på ett vred på varje lampa. Någon sköter det här från en central manöverpanel någonstans i källaren.
Ute på djupt vatten
Någonting har dock skett, jag vet inte vad, men sådan här kommunikation har börjat krypa över mot TCP/IP och häri ligger ett av huvudproblemen för de branscher som länge jobbat i en verkstad skyddad av obskyra kommunikationsprotokoll. I samma veva som det sker en övergång mot välkända, öppna protokoll ökar komplexiteten i dessa system i och med detta. Det här skiftet har gjort och kommer att göra situationen värre.
I en intervju i AffNyheter (pdf) (fastighetsbranschens tidning) från i början av 2009 sa jag ungefär samma sak som Tomas Djurling skrev i Computer Sweden idag. Då handlade det inte bara om passersystem utan alla slags system för fastighetsautomation:
"I samband med övergången till öppna protokoll som baseras på TCP/IP har leverantörerna gett sig in på ett område där kunskap och verktyg för att manipulera tekniken finns i överflöd. Tidigare har de till viss del kunnat förlita sig på att deras teknologier varit för obskyra för att någon skulle intressera sig.", säger Stefan Pettersson.
Problemen med fastighetsautomationens intåg på våra LAN är ett ämne jag har velat skriva om länge. Nu är det dock fredag och det får vara nog med självcitat. :-)
Trevlig helg!
--
Stefan Pettersson
Kommentarer
Postat av: Christian C
Yes. Väldigt bra saker att hålla i åtanke när man jobbar med säkerhet och antalet bra exempel är många.
Angående sista biten så vill jag tillägga att övergången till TCP görs värre av den (ibland omotiverade) användningen av HTTP som protokoll för både dataöverföring i bakgrunden och som GUI. Man förstår ju såklart att det är en enkel och billig lösning att använda HTTP men protokollet är också väldigt lätt att attackera/utnyttja.
btw. Trevligt med en Turning Torso referens ;-)
Postat av: Stefan Pettersson
En fördel med hela den här dealen är dock att på samma gång som det finns en massa människor som vet hur man attackerar webbservrar över TCP/IP finns det också en massa människor som vet hur man skyddar dem.
...åtminstone i teorin.
Heh, Turning Torso låg färskt i minnet. :-)
Trackback
