Säkerhetsuppdateringar är något som ofta upplevs som besvärligt. Man har just fått systemet att fungera bra och nu är det dags att uppdatera igen. Många uppdateringar ger en stor påverkan på systemen och kräver noggrann testning innan de kan införas på skarpa system. Testsystem där man kan verifiera uppdateringarna innan de införs är nödvändiga.
Säkerhetskopior kan skapa problem då uppdateringar sker, gamla säkerhetskopior fungerar inte nödvändigtvis att lägga tillbaka då systemet har uppdaterats. Man kan också genom att lägga tillbaka en gammal version nedgradera sitt system igen till en oskyddad nivå, utan att man är medveten om vad som har hänt. Det är viktigt att kontrollera hela tiden att systemen är på en acceptabel säkerhetsmässig nivå.
Vissa system går inte att uppdatera trots att det pga av säkerhetsskäl är nödvändigt. Tex är datorer kopplade till olika mätinstrument ofta beroende av en viss version på operativsystemet och programmet som styr mätinstrumentet finns bara till just den versionen. Att då uppdatera kan göra ett dyrt instrument oanvändbart. Om man hamnar i den situationen behöver man säkra systemet på ett annat sätt, genom att tex bygga en form av brandvägg mellan systemet och det omgivande nätverket.
Att automatisera sina säkerhetsuppdateringar kan verka mycket frestande men kanske inte alltid är en fungerande lösning. Vilka system kan uppdateras automatiskt utan risk för att de slutar fungera? För vanliga hemanvändare är automatiska uppdateringar en bra lösning, för företag krävs en mer avancerad lösning. Att ha en funktion för att sprida uppdateringar till alla sina system är en god ide. Då kan man också antagligen hålla bättre reda på vilka versioner av olika program som man använder. Det minskar riskerna att man har program som är dåligt uppdaterade.
Kritiska uppdateringar kommer ibland, dessa uppdateringar kan vara så viktiga att man inte kan hinna testa dem ordentligt. Det är viktigt att i förväg ha en utarbetad rutin för hur dessa ska läggas in så att man inte gör något fel i den stressiga situation som brukar uppstå. Man behöver också ha en plan för vad man gör om uppdateringen trots allt visar sig förstöra något på systemet. Vad är viktigast?
===
En av driftansvarigas viktigaste rutiner är att löpande bedöma och kategorisera relevanta systemuppdateringar. Windowsservrar kan konfigurerade så att dess status rapporteras till en lokalt placerad WSUS-server. Andra Operativsystem kan ha agenter eller indexerings-motorer för att skapa ordning på de uppdateringar som finns tillgängliga.
Företag och allt fler statliga organisationer använder svartnät och om det finns svårigheter för servrar att få tillgång till externa uppdateringar kan en patchproxy användas. En patchproxy är en normal proxyserver men som har ett antal väldefinierade regler för vilka resurser som kan hämtas via den. Alltså en vitlista med olika former av mime-typer och domännamn. Ett exempel på en grundlista som kan användas kommer att publiceras här.
Samtliga systemuppdateringar ska om möjligt först provköras, på jämförbar maskin så som test och utvecklingsmaskiner, innan installation sker. Driftansvariga ansvarar för att systemen har en fungerande säkerhetskopia så att en återställning till föregående version kan ske. En återgång till föregående systemstatus kan även ske med ett så kallat snapshot om man använder sig av virtualisering eller diskbaserad backup. Om man använder snapshot ska viktiga loggar kopieras och sparas så att de inte förstörs vid systemåterläsning. Systemuppdateringar för operativsystem (oberoende av tjänst) bör efter verifiering på jämförbara test eller utvecklingsmaskiner kunna införas utan en begäran om förändring(Change process om man talar ITIL) om andra beroenden saknas för systemet eller verksamheten. Men detta beror i stor utsträckning på hur SLA eller andra förväntningar är formulerade.
Systemuppdateringar av applikationer och tillagda tredjepartskomponenter bör alltid hanteras via en begäran om förändring om inte akuta säkerhetsproblem föreligger då dessa kan påverka systemets funktionalitet. Normalt ska dessa uppdateringar ske vid nästkommande servicetid/tillfälle. Om SLA saknas ska samordning ske med uppdatering av andra uppdateringar för att minska risk för avbrott i tjänst.
Systemuppdateringar kategoriseras efter bedömning av hur viktig uppdateringen är för systemet och dess funktioner. Kategorisering följer normalt leverantörernas rekommendationer men ska tolkas individuellt per system och tjänst. Den som ansvarar för samordningen av IT-säkerheten har ett övergripande ansvar att assistera i kategoriseringsbedömningarna och bör ha tolkningsföreträde om uppdateringarna är bristfälligt dokumenterade från leverantörer eller om tillämpningen varierar. Respektive driftansvarig ansvarar för att bedömningarna utförs och dokumenteras.
IT branschen har ett stort antal kategorier och bedömningar men en sammanslagen verklighetsanpassad tolkning av dessa kan vara:
Kritisk:
Avser uppdatering som krävs för att garantera systemets funktion och informationens riktighet. Kritiska uppdateringar skall prioriteras om sårbarhetsmekanismer eller exploitkod existerar. Systemuppdateringar kategoriseras som kritiska om utnyttjande av sårbarhet inte kräver ett fungerande konto. Kritiska uppdateringar ska införas så snart det är möjligt, om bedömning sker att detta inte riskerar att störa verksamheten. Är det troligt att verksamheten riskerar att störas ska en begäran om förändring skapas och först godkännas av *ansvarig* i samråd med berörda parter. Kritiska systemuppdateringar kan efter bedömning av *ansvarig* införas som en akut åtgärd.
Vad leverantör kallar Important kan i vissa fall kategoriseras som kritisk. I de flesta fall är dock Important lika med kategorin viktig.
Viktig:
Avser uppdateringar som innefattar åtgärder för säkerhetsbrister som för att utnyttjas kräver ett inloggningskonto eller då systemet kan störas genom överbelastningsattacker. Avser systemuppdatering som vanligtvis införs vid kommande servicetillfälle.
Viktiga uppdateringar ska införas så snart det är möjligt, om bedömning sker att detta inte riskerar att störa verksamheten. Är det troligt att verksamheten riskerar att störas ska en begäran om förändring skapas och först godkännas av *ansvarig* i samråd med berörda parter.
Standard:
Avser uppdateringar som är av ringa betydelse eller där sårbarheten är svår att utnyttja. Grunder för att klassas som standard är att funktionen inte är tillgänglig för exponerade tjänster eller om rättigheterna för tjänsten inte i övrigt riskerar användardata eller systemet. Standarduppdateringar kan vänta och testas i samband med andra uppgraderingar eller serviceåtgärder.
Vad leverantör kallar "Moderate" och "Low" kategoriseras som Standard om ingen annan lokal tolkning sker.
Under vissa förutsättningar kan en systemuppdatering bedömas som icke relevant. För detta krävs att:
Tjänsten körs enbart med ytterst begränsade rättigheter.
Systemet är inte tillgängligt externt eller från andra system som är tillgängliga externt.
Om leverantören av applikationen uttryckligen specificerat inkompatibla systemuppdateringar ska risken reduceras genom följande åtgärder:
· Avinstallation eller borttagning av sårbara systemkomponenter eller konfigurationsändringar för att öka skyddet.
· Installera skyddsmekanismer mot skadlig kod så som applikationsbrandvägg som skyddar mot den specifika sårbarheten .
· Förstärka bevakningen genom ytterligare loggning, övervakning och säkerhetskopiering.
För att fördröja systemuppdateringar över flera servicefönster krävs att ett verksamhetsbehov tydliggjort att serviceåtgärder inte bör utföras inom tidsintervallet. Exempel på detta kan vara i samband med antagning eller årsbokslut. Dessa undantagstider ska för att effektivisera IT-avdelningens planering vara tydliggjorda i samband med undertecknande av SLA. Saknas SLA kan systemuppdatering ske när ett fåtal användare använder systemet. Hänsyn och planering ska ske efter en aktivitetskalender.
Incidenter och förändringar i systemets utformning eller driftmiljö samt andra händelser av intresse för de som arbetar med systemet ska alltid kommuniceras till alla berörda parter.
Förändringar som kan påverka användarens upplevelse av tjänsten ska tydliggöras via publicerad information på webbplatsen eller annan normal kontaktväg.
Driftansvarig och systemadministratör ska även informera helpdesk/servicedesk om planerat arbete för proaktivt förbereda dem vid eventuella problem som uppkommer vid förändringen.