Webbplatskarta för Secure-IT.se Följ Secure-IT.se på facebookPrenumerera på mitt RSS flöde för tillgång till de senaste IT säkerhetsnyheterna! Följ Secure-IT.se på twitter Om Secure-IT.se Våra tjänster Secure-IT.se blogg RSS - Nyhetsflöde Kontakt Sökfunktion Webbkarta Säkerhetsdokument Säkerhetsnyheter Gratis säkerhetsanalys Här kan du skanna din dator efter virus (ESET NOD32) Gratis lösenordstest Gratis antivirustest Gratis säkerhetstester Gratis portskanning Här kan du genomföra en gratis säkerhetsanalys! Index Secure-IT.se Gratis IT policy
 
Säkerhetsanalys
Här kan du genomföra en gratis säkerhetsanalys >>
Hotbild
Att analysera och inventera är viktigare än du tror >>
Patchhantering
Vi beskriver varför du måste hålla ordning på uppdateringarna >>
MBSA
Vi beskriver hur detta utmärkta verktyg från Microsoft fungerar >>
Policyguide
Följ vår policyguide för att enkelt skapa ditt företags IT policy >>
Hur skapar man en IT policy?
Vi beskriver med text och bild hur du skapar ett av organisationens viktigaste dokument >>
11+1, bra tips
Vi ger dig 12 bra tips för att underlätta uppbyggnad och implementering av en IT policy >>
Behörighet
Skall alla verkligen ha tillgång till all information inom en organisation? Vi ger vår syn i frågan >>
Gratis IT policy #1
Här ger vi dig en gratis IT policy (nummer 1) >>
Gratis IT policy #2
Här ger vi dig en gratis IT policy (nummer 2) >>
Gratis IT policy #3
Här ger vi dig en gratis IT policy (nummer 3) >>
Gratis IT policy
Här ger vi dig en gratis IT policy (nummer 4) >>
Förslag till säkerhetsföreskrifter
Här ger vi dig ett förslag gällande säkerhets-
föreskrifter för det mindre företaget >>
Hur ser ett sekretessavtal ut?
Här ger vi dig ett enklare upplagt sekretessavtal. Bygg ut och bygg till så att det passar din organisation >>
Hur bygger man upp en upplysningsplan?
Den frågan besvarar vi här. Läs vårt dokument och sjösätt sedan detta viktiga instrument i din organisation >>
Hur bygger man upp en incidentrapport?
Vi beskriver nyttan med att organisationen implementerar rutiner för incidentrapportering samt hur du bygger upp en incidentrapport >>
Hur skapar man ett starkt lösenord?
Ett lösenord måste skapas enligt konstens alla regler för att inte äventyra organisationens informationssystem. Vi beskriver hur du skapar ett starkt lösenord >>
Hur bygger man upp en lösenordspolicy?
Vi beskriver nyttan med en lösenordspolicy samt hur du bygger upp detta dokument >>
Testa hur starkt ditt lösenord är #1
Här kan du testa ditt lösenord (test nummer 1) >>
Testa hur starkt ditt lösenord är #2
Här kan du testa ditt lösenord (test nummer 2) >>
Interaktiva säkerhets kunskapstester
Vi har byggt upp flertalet interaktiva säkerhets kunskapstester för att du enkelt skall kunna fortbilda dig själv och dina medarbetare >>
Allt om backup
Vi beskriver varför backup är så viktigt och hur du på bästa sätt arbetar med detta viktiga område >>
Allt om fientlig kod
Vi beskriver flertalet vanligt förekommande hot och hur du bäst skyddar dig mot dessa >>
Hur skapar man ett virus?
I detta dokument beskriver vi hur enkelt det är at skapa ett digitalt virus >>
Varför bör vi jobba aktivt med IT-säkerhet?
Vi ger vår syn på varför IT säkerhet är ett så viktigt område att vara insatt i och jobba aktivt med >>
Varför skapar någon fientlig kod?
Här benar vi ut begreppen White hat, black hat, script kiddies och andra intressanta faktorer >>
Testa ditt antivirussystem
Här kan du göra sju olika tester som bygger på Eicar_test, en ofarlig fil som har många likheter med ett riktigt virus >>
Allt om brandväggar
I detta dokument ger vi dig inblick i hur en brandvägg fungerar och varför du bör använda en sådan >>
5 viktiga punkter att börja med
Här rekommenderar vi fem elementära saker att börja med när det gäller IT säkerhet >>
Hur förebygger man mot IT relaterade hot?
Vi ger förslag och idéer på hur du kan skydda din IT miljö >>
Tips för ökat säkerhet
Vi ger dig mängder av tips som kommer att höja säkerheten kring dina IT system >>
Bra produkter
Här listar vi ner bra tjänster och produkter som vi tycker att du bör titta närmare på >>
 
 

Patchhantering - Varför skall man utarbeta en strategi för patchhantering?

I det här dokumentet beskriver vi varför patchhantering är så viktigt. Vi beskriver också hur du på bästa sätt bygger upp en strategi för detta område. Denna strategi bör dokumenteras och hanteras med samma dignitet som företagets IT policy.

Diskutera detta!
 
Texten fortsätter under frågeformuläret:
 
Annons:
 

Varför skall man ha en strategi för patchhantering?

I detta dokument skall vi titta lite närmare på patchhantering och varför det är viktigt att skapa rutiner för detta område.

Vad är en patch, eller en uppdatering?
Enkelt förklarat är en patch en liten del av en mjukvara som är designad att uppdatera eller ställa tillrätta problem i en befintligt applikation. Som exempel kan vi nämna operativsystemen Windows från Microsoft. När man utvecklar ett operativsystem engagerar man tusentals utvecklare och programmerare som alla gör sina programsnuttar som i slutänden sammanfogas till ett komplett operativsystem.

Rigorösa tester görs i regel alltid när man utvecklar mjukvara och innan man börjar sälja en skarp version har man oftast släppt en fri betaversion. Det gör man för att få hjälp av en bredare användargrupp att finna eventuella problem och brister i programmet. Men hur än seriöst man jobbar i en utvecklingsfas är det nästan helt omöjligt att det inte slinker igenom någon liten bugg som gör programmet (eller del av programmet) instabilt. Det kan också vara fråga om en svaghet i systemet som i en omedelbar framtid kan användas av en illasinnad individ för att attackera systemet.

Patchhantering

Under applikationens livscykel upptäcker man flera fel som måste rättas till, dessa fel kan vara säkerhetsrelaterade eller driftrelaterade.

Patchhantering

Varför är det då så viktigt att sköta uppdateringarna?

Vi listar och förklarar några viktiga anledningar till varför det är viktigt att skapa fungerande rutiner för uppdateringar av de IT-system ditt företag förfogar över.

Trovärdighet internt
Det finns ingenting som retar en användare så mycket som ett IT-system som "inte gör som det skall". Det blir irriterat inom organisationen och trovärdigheten till systemen sätts i gungning. Att slarva med uppdateringar som enkelt rättar till problem som annars skulle ställa till förtret för dem som jobbar inom organisationen är det bästa sättet att skjuta förtroendet för i sank för både företagets IT-system samt de som administrerar systemen.

Ärligt talat är de flesta som arbetar inom en organisation fullständigt ointresserade vad gäller tekniska termer och mumbo jumbo. Det är snarare så att många är rent avigt inställda till teknik vilket innebär att vi som ansvarar för driften av olika IT-system måste av ren självbevarelsedrift se till att sköta uppdateringar på ett så smidigt sätt som möjligt.

Trovärdighet externt
Läs och begrunda denna mening "Nej, jag kan inte hjälpa dig för det förb..... systemet är nere igen". Om denna mening upprepas gång på gång till en kund, leverantör eller annan extern part skapar det naturligtvis inte trovärdighet varken kring företaget eller dess IT-system. Vad ger det för bild av företaget om t.ex. en e-handelslösning är nere på grund av dåligt patchade system?

Ekonomi
Vad kostar den tid en anställd inte kan utföra sina dagliga sysslor på grund av ett system som inte fungerar? Vad kostar det för ett företag som är beroende av en e-handelslösning när en server går ner? Varje gång ett IT-system inte fungerar som det skall kostar det företaget pengar, i det fallet är det ingen skillnad mot när andra delar av verksamheten blir störda av olika avbrott eller incidenter.

Integritet
Ett ouppdaterat system blir sårbart i princip omgående. Det finns olika grupperingar (både kriminella och legitima sådana) som inte gör annat än att leta sårbarheter i olika IT-system och när en sårbarhet upptäcks sprids nyheten om detta som en löpeld via Internet. Dagens IT-brottslingar slår inte på stora trumman när de har gjort ett intrång i ett dåligt säkerhetspatchat system. Istället gäller en helt annan praxis än för bara några år sedan, att verka men inte synas är numera mottot.

Det finns otaliga exempel på dåligt uppdaterade system inom företag och organisationer där ett intrång har skett flera månader, ja till och med år, tillbaks i tiden innan det upptäcks. Frågan är hur mycket värdefull information som har stulits från företaget under så lång tid? Den bistra sanningen är att många av dessa intrång hade kunnat förhindras om en väl fungerande strategi för uppdateringar hade funnits.

Badwill
Om kunder, leverantörer och andra parter börjar tvivla på ett företags förmåga att exempelvis skydda sina kunders integritet, upprätthålla daglig drift eller leverera olika typer av tjänster skapar det en negativ bild av företaget. Detta kan naturligtvis innebära kundförluster och ett skadat renommé är väldigt svårt att återupprätta.

Hur skall vi då slippa dessa negativa effekter av dåligt uppdaterade system?

Utse en ansvarig
Utse en ansvarig* medarbetare som besitter grundläggande kompetens inom IT-området på företaget. Denna person kan sedan utse ytterligare medarbetare med ansvar för patchhanteringen kring specifika program eller applikationer. Allt styrs av de resurser som företaget förfogar över och hur omfattande IT-systemen är.

Se även till att jobba standardiserat. Om företaget har 25 medarbetare bör man inte jobba med 25 olika lösningar för hur patcharna skall hanteras och distribueras. Arbeta fram en strategi som omfattar alla användare och alla resurser.

* Naturligtvis måste ett utnämnande till ansvarig inom detta område bygga på kompetens. Dels för att organisationen skall kunna upprätthålla god säkerhet och driftstabilitet gällande dess IT-system, men också för att den som utses som ansvarig skall ha en rimlig chans att kunna utföra sitt jobb på ett riktigt sätt.

Förankra med de som bestämmer
Att upparbeta en fungerande strategi för uppdateringar är direkt nödvändigt och en mycket viktig del inom området IT-säkerhet. Av flera anledningar bör detta arbete förankras och godkännas av företagets ledning, dels av ovan nämnda skäl men också med anledning av bland annat ekonomiska skäl (godkännande av kostnad för framtagande, godkännande av kostnad för att administrera strategin i form av eventuellt övertidsarbete mm), administrativa skäl (driftstopp som påverkar olika processer mm).

Ledningen skall godkänna det totala upplägget för att ta fram en fungerande strategi för hur uppdateringar skall administreras inom företaget.

Inventera
För att skapa en fungerande strategi kring uppdateringar (patchhantering) måste vi veta hur vår IT-miljö ser ut. Vi måste helt enkelt inventera de servrar, arbetsstationer och PC som företaget förfogar över. Om vi inte har en fullständig dokumentation gällande vår IT-miljö kommer det att vara mycket svårt, för att inte säga omöjligt, att upprätthålla en god uppdateringsstrategi.

En inventering skall omfatta både hård- och mjukvara och det skall finnas separat information om varje enhet i den aktuella IT-miljön. Ett nätverksschema bör också upprättas som ger en överskådlig bild av hur företagets IT-miljö ser ut. Visio från Microsoft är ett utmärkt redskap att använda för att göra nätverksscheman.

Inventeringen kan utföras manuellt men det bästa (och snabbaste) sättet är att använda ett för ändamålet speciellt anpassat system.

Med hjälp av den information vi får tillgång till vid inventeringen skall vi klassificera de olika enheternas behov. Vi kan till exempel jobba efter Kritisk - Hög - Medel samt Låg som benämning av de olika klasserna. Exempelvis hamnar med all säkerhet en server (framförallt om det är en publik server) i de Kritiska klassen medan en icke nätverksansluten PC kanske hamnar i klassen Låg. Vi måste skapa en bild av hur de datorer vi förfogar över används i nätverket och vilka typer av sårbarheter och risker de utsätts för.

Att dokumentera IT-miljön ger fördelar vid arbetet med uppdateringar men det ger även andra fördelar:

1. Snabbare uppstart
Vid exempelvis ett allvarligt virusangrepp är det av stor vikt att ha en bra dokumentation för att snabbt kunna starta upp systemen igen.

2. Snabbare felsökning

Det blir enklare att finna felen snabbt om du har ett väl dokumenterat nätverk. Bra dokumentation reducerar behovet av efterforskning av samma problem varje gång det uppstår. Ett nätverksschema kan hjälpa dig att identifiera blivande problemområden i ett tidigare skede.

3. Mindre risk för informationsförlust
Det finns alltid en risk att den nätverksansvarige har allt i sitt huvud. När han eller hon slutar blir det ett stort problem för företaget. Om det finns bra dokumentation av nätverket så blir övergången från det att en person slutar till det att en ny är insatt i verksamheten mindre kännbar.

4. Ansvarsfördelning
Om det är ett lite större företag med flera anställda inom IT-avdelningen blir ansvarsfördelningen kring nätverket lättare om viktig information finns dokumenterad.

5. Förbättrad nätverksdesign
Finns det bra dokumentation kring nätverket är det lätt att förbättra designen och bygga ut nätverket med fortsatt god design.

6. Tidsaspekt
Ett uppdaterat nätverksschema kommer att spara tid åt dig som administratör under alla förhållanden.

Några parametrar att ta hänsyn till vid inventering

Hårdvara
Vi måste kartlägga vilken typ av datorer vi förfogar över, vilka datorer är bärbara, vilka är stationära och vilka är servrar? Olika system har olika kravbilder och generellt sätt är en server den mest kritiska av dessa system att uppdatera.

Operativsystem
Vad använder vi för operativsystem? Kommer alla system från samma tillverkare och är de av samma version? Om vi tittar på Microsoft (Windows) vet vi att från W2000 är säkerheten i operativsystemen betydligt bättre, WXP tog ytterligare flera steg åt rätt håll och i Vista skall säkerheten vara ytterligare lite bättre. Äldre system från Microsoft (NT, W98 mm) bör utfasas eftersom dessa system inte längre åtnjuter support eller uppdateringar från Microsoft. Dessa operativsystem är sämre ur alla perspektiv oavsett om vi pratar säkerhet eller stabilitet.

Program
Precis som med operativsystemet måste olika programapplikationer också uppdateras med jämna mellanrum. Vi måste kartlägga vilken typ av mjukvara som finns på respektive resurs.

Speciella restrektioner
Vi måste ha en klar bild av vilken funktion de olika resurserna har i vårt nätverk. Olika resurser har olika kravbild när det gäller uppdateringar, Som ett exempel kan vi nämna en server, vi måste ha klart för oss exakt vilken roll servern har i vårt IT-system och hur ett avbrott påverkar den totala driften.

Nu menar vi inte ett avbrott som är knutet till en missad uppdatering utan precis tvärtom, vi har en plan för våra uppdateringar men ofta kräver en uppdatering(ar) en eller flera omstarter av systemet i fråga och vi måste veta hur den typen av avbrott påverkar övriga system och användare i vår IT-miljö. I fallet med en server kan det vara en god tanke att utföra uppdateringar efter arbetstid när påverkan är som minst.

Ett nationellt omfattande e-handelssystem kanske kan uppdateras på natten medan ett internationellt system kräver ett annat förfarande (exempelvis redundans). Förlorad upptid kostar pengar!

Patchhantering

Nätverket - Hur ser det ut?
Förfogar företaget över ett lokalt nätverk eller omfattar nätverket lokalkontor utspridda över hela landet? Hur ser nätverket ut och hur sköts förbindelsen med exempelvis Internet? Om en långsam "lina" används kanske vissa uppdateringar skall ske efter arbetstid för att inte påverka den dagliga driften i för hög grad. Det är garanterat billigare att låta en administratör jobba ett par timmar på kvällen än att låta en hel organisation rulla tummarna under ett längre avbrott som sker dagtid.

Återkom och rätta till
I vissa fall kanske det inte går att fullfölja en uppdatering som det var tänkt. Det kan bero på mängder av faktorer men det viktiga är att detta dokumenteras och åtgärdas så snart som möjligt. Det kan räcka med ett par timmar för att en säkerhetslucka skall utnyttjas av en illasinnad individ. Att hoppa över uppdateringen är det sämsta tänkbara scenariot.

Inventera - Dokumentera - Analysera - Testa - Administrera

Att finnas eller inte finnas
När bilden av vårt företags IT-miljö nu börjar tona fram kan det vara en bra idé att göra en riktlinje för vad som är "lägsta krav" för att få finnas eller inte finnas. Oj, det där lät luddigt! Lugn, vi skall förklara. Vi har ett företag som använder 20 datorer där alla enheter har WXP installerat förutom servern som kör W2003.

Behöver det innebära att alla datorer är moderna bara för att vi använder WXP? Nej inte alls! Otaliga gånger har vi besökt företagsmiljöer där äldre datorer har tvingats "bära" krävande operativsystem bara för att man skall upprätthålla en enhetlig miljö.

Grundtanken är bra men det kan nu vara läge att fundera på om inte en utrangering bör verkställas en gång för alla. Varför? Jo, av den enkla anledningen att det i längden kostar mer att administrera äldre system som inte har rätt prestanda för uppgiften.

Det kan också vara så att vissa enheter kör specifika applikationer som inte tillåter uppgraderingar utan att en noggrann analys har gjorts. Om man genomför en uppgradering utan analys och eftertanke kan det komma problem efteråt på applikationsnivå och alla applikationer är inte direkt anpassade för t.ex. ett spritt nytt operativsystem från Microsoft. Så återigen Inventera - Dokumentera - Analysera - Testa - Administrera

Var insatt så att du vet vad som händer
Oavsett om det gäller ett operativsystem eller en mindre mjukvaruapplikation så redogör alltid seriösa leverantörer för vilka uppdateringar som finns att tillgå samt vilken funktion de har för systemet. I en fungerande strategi för uppdateringar är det viktigt att det finns ett klarlagt system för hur man enklast samlar in information om nya uppdateringar.

Det måste också inkluderas hur normala respektive kritiska patchar skall hanteras. En kritisk uppdatering måste i regel "rullas ut" direkt på de resurser organisationen förfogar över och då skall det finnas en plan för detta. Detta gäller kanske framförallt serverresurser i och med att uppdateringsförfarandet fungerar lite annorlunda på dessa.

Kom dock ihåg att inte ladda ner uppdateringar direkt via bifogade länkar i exempelvis e-post. Det förekommer relativt ofta att kriminella element kopierar kända aktörers e-postutskick och kan inte källan verifieras på ett riktigt sätt kan detta ställa till alvarliga konsekvenser. Om leverantören har signerat e-brevet digitalt bör signaturen kontrolleras med avseende äkthet och om den fortfarande är gällande.

Det kan också vara en bra idé att skapa en rutin för slussning via en karantän. Skanna alla patchar med det antivirussystem företaget förfogar över innan den distribueras. Detta lite krävande förfarande kan ge mångfalt igen vid ett senare tillfälle då en patch innehåller eventuell fientlig kod.

Stationära och bärbara PC - Gör det med automatik (så långt det går)
Om Windows används som operativsystem på organisationens klientdatorer bör Windows Update vara konfigurerat att uppdatera systemet per automatik. Naturligtvis måste vi som administratörer ändå ha en klar bild av de patchar som levereras men en klientdator är sällan lika kritisk att uppdatera som en server.

Dock har inte alla mjukvaruleverantörer ett lika utbyggt system för patchdistribution som Windows. Om vi tittar på applikationsnivå lämnar många leverantörer oss med till stora delar manuell hantering av uppdateringarna.

Detta innebär att vi måste vara väl insatta i när ett system behöver uppdateras och vilket syfte uppdateringen har för det aktuella systemet.

Långt ifrån alla uppdateringar som skickas ut från leverantörer av olika mjukvaruapplikationer är av säkerhets- eller driftrelaterad betydelse. En stor del av dessa uppdateringar åtgärdar mindre viktiga detaljer där vi kan fråga oss om tid och bandbredd skall upptas för just denna uppdatering. Inkludera även detta i den blivande strategin.

Servrar
Analysera, utför backup, installera (en och en med dokumentation av händelseförloppet) och testa (mellan varje uppdatering)

Vi återkommer till den lite mer speciella servermiljön. En server fungerar ofta som kärnan eller hjärtat i ett företags IT-miljö. En server kan bistå hundratals, ja kanske tusentals (om vi pratar om exempelvis ett e-handelssystem), användare per dag vilket gör att vi inte vill att den skall ha några avbrott.

I en mindre miljö med färre anställda kanske kortare avbrott kan accepteras om de är planlagda men det bästa sättet att göra uppdateringar i en servermiljö är att utföra dem på tider som inte stör användarna. En server som bär en e-handelslösning eller en publik webbsida får aldrig gå ner bara för att administratören vill komma hem i tid på kvällen. Avbrott kostar pengar vilket skall undvikas.

När vi jobbar med uppdateringar i en servermiljö är det viktigt att analysera de patchar vi skall lägga på. Uppdateringarna kan komma från flera håll och det är viktigt att vara insatt i vilken påverkan varje patch (uppdatering) har på vår server. Det första vi skall göra är att utföra en backup av vårt system, detta kan ske On Demand för det specifika tillfället. Vi vill ju vara säkra på att vi kan återställa vårt system om något skulle gå snett.

När detta är utfört skall vi analysera de patchar vi skall vi skall lägga på. Detta gör vi genom att samla in information om respektive patch från leverantören i fråga. De flesta seriösa leverantörer anger information om de uppdateringar som finns att tillgå på sina webbsidor. Vissa erbjuder också information via e-post vilket är ett bra sätt om dessa e-brev kan verifieras på ett riktigt sätt.

Vi installerar sedan varje patch separat och dokumenterar samtidigt händelseförloppet. Med all säkerhet krävs en omstart av systemet och när denna är utförd är det viktigt att vi kontrollerar funktionaliteten på vår server. Om inga avvikelser kan påvisas i hänseende av driftstabilitet kan vi gå vidare till nästa uppdatering och utföra samma procedur igen tills det att vi har genomfört den aktuella uppdateringscykeln.

Tillvägagångssätt (viss upprepning)
Inventera
Vilka resurser förfogar organisationen över. Hur skyddar vi bäst dessa resurser och hur utarbetar vi bäst en plan för distribution av patchharna.

För att vi skall kunna utföra ett effektivt arbete gällande patchhantering måste vi veta hur vår IT-miljö ser ut. Det är näst intill omöjligt att utarbeta en fungerande strategi om inte en fullständig och aktuell inventering ligger som grund. Vi måste också veta hur vår infrastruktur gällande Internetanslutning ser ut. Detta är av stor vikt om det finns många satellitkontor eller medarbetare som ansluter via remote access (fjärranslutning). Vissa delar av organisationen kanske förfogar över långsammare anslutningar och då måste detta tas med i beräkningarna.

Det vi bör inkludera i vår inventering är följande:

Typ av hårdvara
Vilka typer av datorer förfogar organisationen över. Hur många datorer är servrar, arbetsstationer, bärbara datorer och så vidare. Detta är viktigt för att vi skall kunna styra vilka patchar som skall användas vart och hur vi bäst administrerar detta.

Operativsystem
Vi skall skaffa en klar bild över vilka operativsystem organisationen förfogar över samt även vilka versioner som används. Vi kan inte nog betona att äldre operativsystem bör fasas ut (Windows). Detta beroende på att arkitekturen har blivit avsevärt bättre sedan W2000 men också för att support och uppdateringar inte längre finns att tillgå till äldre operativsystem. Exempelvis W2000 är utfasat från support från Microsoft och detta gäller naturligtvis ännu äldre versioner också.

Applikationer
Vi måste veta vilka applikationer som används på respektive resurser (datorer) inom organisationen. Olika mjukvaruapplikationer har olika hotbilder riktade mot sig och är därmed olika sårbara. En resurs som bär exempelvis IIS (ex. webbserver) är mycket mer sårbar än en dator på användarnivå som "bara" bär bruksapplikationer för vardaglig användning. Detta eftersom webbservern är publik vilket innebär två saker:

1. Den är troligtvis mer eller mindre konstant uppkopplad mot Internet.
2. Det är en betydligt mer exponerad resurs i och med den roll den har inom organisationen.

Rollfördelning
Olika resurser (datorer) har olika roller inom organisationen vilket innebär att de skall hanteras på olika sätt i en situation gällande patchhantering. En medarbetares PC kan med all säkerhet startas om ögonblickligen utan några större problem. Däremot en server kräver ett helt annat förfarande i och med att den bär applikationer och tjänster som är publika inom organisationen. Detta innebär (som vi har nämnt) att en server inte kan patchhanteras utan strikt planering.

I denna planering bör backup - utvärdering - test - och implementering med tidsanpassning för omstarter inkluderas. Med tidsanpassning menar vi tid på dygnet när en omstart har minst betydelse för daglig drift. En serveruppdatering kan innebära flera omstarter och skulle vi dessutom råka ut för problem på vägen är det av största vikt att vi i lugn och ro kan återställa systemet (via vår On Demand backup) utan en organisation som stressat river sitt hår på sidan om.

Arkitektur
Hur ser nätverket ut och vilka flaskhalsar finns det att ta hänsyn till? Vi måste ha full kunskap om nätverkets infrastruktur och hur vi undviker eventuella problem vid patchhantering. Uppdateringar är olika omfattande vilket innebär att datorerna på ett satellitkontor som kanske har långsammare ADSL-anslutning kommer att hanteras annorlunda än de resurser som är direktanslutna till det lokala nätverket.

Dokumentera avvikelser
Om en patch (uppdatering) inte kan installeras måste detta dokumenteras så att åtgärder kan vidtas vid ett senare tillfälle. Detta skall naturligtvis ombesörjas så snart som möjligt eftersom ett system med en säkerhetsrelaterad brist omedelbart innebär risk för incidenter.

En rekommendation är att genomföra en grundlig analys av företagets system så att varje resurs dokumenteras och ett nätverksschema upprättas. Denna analys skall naturligtvis omfatta alla delar av organisationen vilket inkluderar satellitkontor, resande personal med bärbara datorer, personal som arbetar från hemmakontor med mera.

Vi rekommenderar också att analyser genomförs med jämna mellanrum så att en referensbank upprättas där data kan ställas mot varann. Eventuella avvikelser mot föregående analys måste kontrolleras noga så att inget felaktigt hanterade kan uppstå. Att utföra upprepade analyser är naturligtvis också ett bra sätt att säkerställa att ingen resurs faller utanför patchstrategin. Referensbanken innebär också att vi enklare kan spåra en patch som har ställt till ett problem i vår IT-miljö.

Inkludera patchhantering i din organisations IT-policy
Patchhantering är en del av det fortgående IT-säkerhetsarbetet inom en organisation vilket innebär att denna del bör inkluderas i företagets IT-policy (som en sub-policy). Patchhantering påverkar i en eller annan form den dagliga driften och desto mer ljus företagets systemadministratör kan kasta på sitt dagliga arbete desto bättre är det. Det ökar förståelsen inom organisationen och det ökar också medarbetarnas kunskap och uppmärksamhet.

Tillägg
Kom också ihåg att ett härdat system i kombination med en analys av vilka portar som bör vara öppna också ger omfattande skyddseffekt. Med härdning menar vi nedstängning av processer som inte används på den aktuella resursen. Detta är en viktig punkt när det gäller servrar och säkerheten kring dessa. Många processer anropar resurser utanför det egna nätverket och om dessa inte har någon relevans för systemet i fråga ökar hotbilden. En anropande process talar om för omvärlden att vår server existerar och att den anropande processens port är aktiv.

Infobox Säkerhetsdokument Gillar du informationen? Då bör du läsa detta!
Tyck till!
Berätta vad du tycker om denna information. Att kommentera är att bry sig och målsättningen är att vi som besöker Secure-IT.se skall bli bättre på IT och informationssäkerhet. Så tack för just din kommentar!
 
Annons:

Säkerhetsnyheter
IT säkerhet
Säkerhetsdokument i fokus
Vad vet du om virus?

Användarvillkor
De dokument, interaktiva tester, lösenordstester, antivirustester samt annan information som finns på Secure-IT.se får användas inom din organisation i utbildande och/eller säkerhetshöjande syfte.

Du får inte kopiera material på Secure-IT.se och publicera det på offentlig plats utan att ange källa.

Du får inte kopiera och sälja materialet på Secure-IT.se i eget syfte.

Texter, bilder och annat material ägs av upphovsrättsmannen.

Annonsera
Vill du att ditt företag skall synas på Secure-IT.se? Då ber vi dig kontakta oss för en fortsatt dialog.

Förbättra
Vi är naturligtvis intresserade av att bli bättre. Har du synpunkter eller idéer på hur vi kan förbättra Secure-IT.se? Då vill vi att du kontaktar oss.

Bidra med information
Secure-IT.se når idag tusentals unika besökare per månad, har du intressant säkerhetsrelaterad information som du vill delge dessa besökare? I sådana fall är du hjärtligt välkommen att kontakta oss.
Pssst, kolla detta!
Säkerhetsanalys, starta här >>
Policyuppbyggnad, starta här >>
Interaktiva tester, starta här >>
Säkerhetsnyheter, läs här >>
Incidentrapport, hämta här >>
Färdiga IT policys, hämta här >>
Upplysningsplan, hämta här >>
Testa ditt lösenord, testa här >>

Här kan du prenumerera på mitt RSS flöde Följ mig på twitter!
Kontakta ossPrenumerera på vårt RSS flödeSök på Secure-IT.seWebbkarta
 
©2004 - 2009 Secure-IT.se / All images and contents copyright / All rights reserved