IT-säkerhet enligt HPS

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

På 90-talet var brandväggar ovanliga, såväl servrar som persondatorer var tillgängliga över Internet. Det fanns fortfarande inget behov av NAT, koppel var verkligen end-to-end. Detta blev efter några år ett problem. Säkerhetshål utnyttjades och information från känsliga servrar riskerade stjälas. Vi började filtrera paket, vi började skilja de servrar som skulle ta emot främmande besökare från de som var känsliga. Vi placerade de publika servrarna i DMZ-nätverk. Nätverk varifrån man, om man tog sig in där, skulle ha begränsade möjligheter att ta sig vidare in i de interna nätverken.

En anledning till detta var att buffer overflows var ett monumentalt problem som lurade i varenda servermjukvara som fanns; mailservrar, webbservrar, namnservrar, FTP, you name it. Hackers byggde brohuvuden i DMZ och letade sig därifrån vidare in på det smaskigare, interna nätverket. Det är en metod som beskrivs i mer eller mindre alla "hackerböcker" (Hacking Exposed och motsvarande).

Det var då.

Intrång fungerar inte bara så längre. IIS, Apache, SQL Server, BIND, vsftpd, OpenSSH och annat som företag traditionellt har öppet mot nätet har inte haft pre-auth-privileged-arbitrary-code-execution-sårbarheter på åratal. (De enda undantagen verkar vara webbapplikationer...)

Det finns hundratals kända och sannolikt tusentals gånger fler okända exempel på att brohuvudet inte skapas på servern i DMZ:at. Brohuvudet skapas på en klientdator, någon anställds laptop eller motsvarande: de tre mest omtalade de senaste åren kan vara GhostNet samt intrången hos Google och RSA. F-Secure har regelbundet bloggposter som beskriver den senaste batchen med "malicious <insert-file-type>".

Jag har aldrig varit hos en kund som inte har ett DMZ. Däremot är antalet som har särskilda nät för klienter synnerligen lätträknade.

Varför har vi inte hängt med där? Borde vi inte börja prata om de-militarized client zones (DMCZ) i alla våra dokument om best-practice? Jag funderar på om inte DMCZ nästan borde anses som viktigare än vårt konventionella DMZ nuförtiden.

...eller dödade NAC/NAP den diskussionen?

--
Stefan Pettersson