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.
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!
--
Stefan Pettersson
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):
- Economy of mechanism
- Fail-safe defaults
- Complete mediation
- Open design
- Separation of privilege
- Least privilege
- Least common mechanism
- Psychological acceptability
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!
--
Stefan Pettersson
Kommentarer
Trackback
