Säkra Designmönster (Secure Design Patterns) Marcus Bendtsen Institutionen för Datavetenskap (IDA) Avdelningen för Databas- och Informationsteknik (ADIT)
Säkra designmönster Beskrivningar eller mallar som beskriver en generell lösning på ett säkerhetsproblem och som kan användas i många olika situationer. Ett designmönster är tänkt att minska antalet sårbarheter som av misstag introduceras i kod och att minska konsekvensen av sårbarheterna. Tre kategorier: arkitektur, design och implementation. 2
Kategorier Arkitektur: Fokuserar på högnivåallokering av ansvar mellan olika komponenter, och kommunikationen mellan komponenterna: Privilege separation (PrivSep) Design: Adresserar problem med designen av en komponent: Secure factory Secure chain of responsibility Implementation: Lågnivå, applicerbara i vissa funktioner i ett system: Secure logger Clear sensitive information 3
Privilege separation (PrivSep) Syfte: Reducera mängden kod som körs med specialrättigheter (admin/root) utan att minska funktionaliteten. Motivation: I många applikationer är det endast ett fåtal operationer som faktiskt kräver administrativa rättigheter, samtidigt som en stor mängd komplex kod kan köras med låga rättigheter utan att det förändrar utfallet. 4
Privilege separation (PrivSep) root Lyssna på trafik på nätverket. Begäran från en användare root Skapa en process som har minsta möjliga rä;gheter. Utan rättigheter Auten>sera (komplex kod) root Skapa en process med auten>serad användares rä;gheter. Användare FortsäD köra programmet som användaren. 5
Privilege separation (PrivSep) Utan rättigheter Auten>serar (komplex kod) Användare FortsäD köra programmet som användaren. root Lyssna på nätverket. root Skapa process med minsta möjliga rä;gheter. Majoriteten av koden körs med låga eller användarens rättigheter. Om det finns en sårbarhet så kommer den som attackerar endast få låga rättigheter. Specialtestning och verifiering kan göras på kod som körs med administrativa rättigheter. root Skapa en process med användarens rä;gheter. 6
Secure Factory Syfte: Separera säkerhetsaspekterna av att skapa ett nytt objekt ifrån objektet själv. Motivation: An användare får tillgång till ett objekt som har funktionalitet som beror på användarens rättigheter. 7
Secure Factory AbstractSecureFactory +getinstance() : AbstractSecureFactory +getobject(givencredentials : SecurityCredentials) : SomeObject ConcreteSecureFactory1 +getobject(givencredentials : SecurityCredentials) : SomeObject ConcreteSecureFactory2 +getobject(givencredentials : SecurityCredentials) : SomeObject Att skapa SomeObject görs genom: AbstractSecureFactory.getInstance().getObject(securityCredentials) Det returnerade objektet, SomeObject, är ett objekt som har de korrekta rättigheterna. 8
Secure Factory Inne i fabriken: 1. Använder den nuvarande konkreta implementationen av AbstractSecureFactory. 2. Inspekterar SecurityCredentials som skickades vid anropet. 3. Skapa en instans av en (för rättigheterna) passande SomeObject. SomeObject LowPrivilegeSomeObject HighPrivilegeSomeObject MidPrivilegeSomeObject 9
Secure Factory Den som anropar, samt SomeObject, innehåller inte någon kod eller logik för att kontrollera rättigheter. SomeObject returneras alltid från fabriken, och fabriken väljer korrekt implementation. Det är lätt att byta hur rättigheter kontrolleras genom att byta konkret implementation av AbstractSecureFactory. Konkreta implementation av SomeObject behöver inte implementera kod för funktioner som inte ska användas av den som ber om objektet. LowPrivilegeSomeObject implementerar inte kod för att kunna skriva till disk. 10
Secure Chain of Responsibility Avsikt: Koppla bort logiken som avgör rättigheter från den del av programmet som begär en viss funktionalitet. Motivation: Applikationer behöver ofta tillåta och avslå vissa funktioner beroende på vem som anropar. 11
Secure Chain of Responsibility Hantera begäran Hantera begäran Hantera begäran eller avvisa hela begäran Begäran samt användarens autentisering Rapport generator för chefer Rapport för sta>s>ker Rapport för säljavdelning Skicka vidare begäran om rättighetskontroll misslyckas Skicka vidare begäran om rättighetskontroll misslyckas 12
Secure Chain of Responsibility Valet av funktionalitet är dolt från den som anropar, vad som returneras beror på användarens rättigheter. Den som anropar vet inte om vart dess begäran har hanterats. Extremt enkelt att lägga till och ta bort hanterare i kedjan. Kan till och med göras dynamiskt. Hantera begäran Hantera begäran Hantera begäran eller avvisa hela begäran Begäran samt användarens autentisering Rapport generator för chefer Rapport för sta>s>ker Rapport för säljavdelning Skicka vidare begäran om rättighetskontroll misslyckas Skicka vidare begäran om rättighetskontroll misslyckas 13
Secure Logger Avsikt: Förhindra att en attack delger potentiellt användbar information om ett system genom loggar, samt förhindra att en attack kan döljas från loggar. Motivation: Ett systems loggar innehåller ofta väldigt mycket användbar information om systemet och dess användare. 14
Secure Logger Applikation Logg Säker loggskrivare Skyddad data Logg-vy Oskyddad data Loggläsare 15
Secure Logger Det går inte att på vanlig väg läsa loggfiler eftersom de nu är krypterade. Loggläsaren är nödvändig för access till loggfiler, och den kräver autentisering. En attack som lyckas få innehållet i loggfilerna har ingen nytta av innehållet. Applikation Logg Säker loggskrivare Skyddad data Logg-vy Oskyddad data Loggläsare 16
Clear Sensitive Information Avsikt: Det är möjligt att känslig information har sparats i resurser som återanvänds efter att en applikation har avslutats eller en användarsession slutförts. Känslig information ska förstöras i dessa resurser. Motivation: I många fall så innebär frigörandet av resurser inte att de tas bort. Till exempel så markeras minne som ledigt, och innehållet tas först bort när någon behöver platsen. Detta kan göra att information som är känslig som man tror är borttagen kan läcka. 17
Clear Sensitive Information Frigör resurs Rengör data Lämna till pool Applikation Frigör aldrig direkt Pool Hämta resurs 18
Clear Sensitive Information ClientInfo::~ClientInfo() { this->ipaddr = 0; } this->trustlevel = BOGUS; this->numfaultyrequests = 0; 19
Secure Design Patterns Ett designmönster är tänkt att minska antalet sårbarheter som av misstag introduceras i kod och att minska konsekvensen av sårbarheterna. När man använder designmönster så utnyttjar man många års erfarenheter från andra som gjort misstag, och du använder best practice. Det hjälper också när man pratar om kod och design med andra utvecklare. Många användbara säkra designmönster: C. Dougherty, K. Sayre, R. C. Seacord, D. Svoboda, K. Tagashi. Secure Design Patterns. Technical Report CMU/SEI-2009-TR-010. 20
www.liu.se