Säkerhet är svårt, men enkelt

Säkerhet i IT-system är både svårt och enkelt samtidigt.

Säkerhet är svårt eftersom komplexiteten i informationsteknologin inte bara ökar i hastighet utan ökar i acceleration. Komplexitetsökningen i Word, Windows och i princip vilken annan stadigvarande teknologi som helst har ökat för varje version. Som utomstående är det ofattbart hur Google lyckas göra miljoner sökningar i miljarder dokument, mer eller mindre samtidigt; på i princip ingen tid alls. Hur kan Facebook leverera så mycket realtidsinformation till så många, dygnet runt, över hela världen? Vågar du gissa hur många javascript-callbacks Facebooks servrar tar emot varje sekund? Det är lätt att göra fel när komplexiteten hänger över en.

Säkerhet är svårt eftersom vi använder våra system för värdesaker som motståndare är beredda att kämpa för att få. Vi har motståndare i säkerhetsbranschen. Inte några bildliga, konceptuella motståndare som konkurrenter i en upphandling eller "åklagarsidan" under en rättegång. Vi har riktiga motståndare som inte följer några lagar eller regler; motståndare som vill ha det vi har.

Säkerhet är svårt eftersom dessa motståndare är intelligenta. De kommer att leta efter svagheter i systemen och utnyttja dessa svagheter vid precis det tillfälle det skadar oss mest. Även om det är vi själva som utgör svagheterna...


Samtidigt är dock säkerhet förvillande enkelt; vi vet vad som krävs av säkra system och vi har vetat det länge. Begreppet "säkra system" ska förstås användas med varsamhet, vad är det för system och vad är det säkert mot – vad är säkert mot vad? – är alltid det första man ska fråga sig. Oavsett vad vad är är vi väl medvetna om vilka egenskaper ett säkert system måste uppvisa. (Har du någonsin lyckats få in två dubbelord efter varandra i samma mening?)

Låt oss ta ett trivialt, generiskt exempel för att visa poängen. Anta att system A ska överföra data d till system B. Vad utgör säkerheten i ett sådant system?
  • System A måste förvissa sig om att det pratar med system B och vice versa. Ingen ska kunna utge sig för att vara endera utan att vara det.
  • System A kanske inte ska kunna komma åt några andra tjänster på B än överföringstjänsten.
  • Eventuellt ska ingen annan än A komma åt överföringstjänsten.
  • System B måste kontrollera att de data A överför verkligen är vad B förväntar sig. d ska vara av rätt längd samt ha rätt format och innehåll.
  • System B måste se till att A inte kan använda tjänsten för andra saker än att skicka d. A ska till exempel inte kunna ladda ner data, eller, som sagt, skicka data e.
  • Om något verkar fuffens, om något som B förväntar sig inte stämmer, ska interaktionen med A brytas direkt.
  • Systemet måste se till att de data d som kommer fram till B verkligen är samma data d som A skickade. Ingen ska kunna ändra d på vägen.
  • Vidare kanske d är känsligt; då måste systemet se till att ingen kan läsa d på vägen mellan A och B.
  • Kritiska delar av förloppet ska loggas.
  • Det är viktigt att systemen håller samma tid.
  • Loggning ska inte ske lokalt utan till någon annan plats.
  • Överföringen av loggar kanske måste skyddas på samma sätt som överföringen av d.
  • Det är möjligt att d måste skyddas även när det befinner sig på B, i så fall ...
...man skulle kunna hålla på hur länge som helst. Min poäng är att säkerhet är enkelt på den här nivån. Vi vet inte bara vad vi behöver göra, vi har verktygen för det. Det är sånt här som står beskrivet i alla standarder, ramverk och guider.

Det är inte här vi borde ha våra problem. Våra säkerhetsproblem borde huvudsakligen härstamma från (1) misstag i implementering och (2) att vi är förhindrade att implementera vissa saker.

Jag skulle argumentera för att den första anledningen skulle kunna strykas. Det är ofrånkomligt att göra misstag, det är oförlåtligt att inte förbereda sig på dem.

Kvar är vi med tvåan som knyter an till att tid och pengar är en bristvara. Vilka säkerhetsåtgärder är viktigast? Vilka kan vi skippa? Är den här säkerhetsågärden värd vad den kostar oss?

Det är i tvåan (hej Flashback) vi borde behöva placera vår oro.

--
Stefan Pettersson


Kommentarer

Kommentera inlägget här:

Namn:
Kom ihåg mig?

E-postadress: (publiceras ej)

URL/Bloggadress:

Kommentar:

Trackback

HPS säkerhetsblogg


High Performance Systems logo


RSS 2.0