|
Forside Profil IT sikkerhed Søgemaskineoptimering Reference Ressourcer |
|||||||
Midlertidige links: vidensbankHacking for Managers.Del 2Læs i samme serie: Spørgsmål 4. Hvordan imødegår vi problemer. Fjernelse af problemet eller blokkering i firewallen.Der er altid flere måder at "fjerne" et hul på. Hvis f.eks. man har en FTP server der har en eller anden kendt sårbarhed, kan man afinstallere denne FTP server, så fjernes sårbarheden også. Man kan måske også patche sårbarheden væk ved at skifte til en nyere version, eller man kan måske installerer en eller anden form for beskyttelse direkte på serveren som f.eks. URL´scan der installeres på IIS når man køre IIS lockdown tool eller man kan blokkere trafikken på FTP portene i firewallen. Hvilken løsning man vælger bør afhænge af hvilke muligheder man har og ikke af hvad der er hurtigst. Man kan måske ikke afinstallere FTP serveren og der eksisterer ingen patch eller værktøj der kan blokkere direkte for sårbarheden så måske er eneste mulighed at blokkere for portene i firewallen. IT Chefen bør selvfølgelig spørge hvad politikken er og så kan han foretage scanninger med værktøjer som Nessus, Core Impact eller Metasploit framework og hvis han finder forskellige sårbarheder og muligheder henholdsvis inden og uden for firewallen bør han undersøge hvorfor det er sådan og om IT afdelingen har foretaget de sikreste eller de hurtigste valg i forhold til de sårbarheder der findes. Man skal dog være klar over at der kan være situationer hvor man ikke har andet valg end at leve med sårbarheden. Her er der så nogle ting man kan gøre for dog at mindske sandsynligheden for at sårbarheden udnyttes. Det kan man f.eks. gøre ved at flytte portene til andet end standard portene, dette vil selvfølgelig ikke snyde en professionel, men fjerne alle standartværktøjerne og script kiddiene. Man kan også ændre banneret og nogle af de standard værdier der afsløre hvilken server man står over for. F.eks. Web servere afsløre som standard hvilken type software der er tale om og hvilken version. Hvis den Apache web server man har i drift har en sårbarhed man er nødt til at leve med, så kunne det måske være interessant at web serveren i stedet sagde at den var en IIS eller noget helt tredie. Igen snyder vi ikke den professionelle, men selv den dygtige amatør kan nogle gange nares Man bør også kikke på sine firewall regler og stramme op på disse, hvis man ikke kan lave en positiv liste over de IP adresser der må tilgå serveren og dermed udelukke alle andre, så kunne man måske leve med at blokkerer kendte problemområder som f.eks. Kina, Rusland og Brasilien Denne afgørelse skal naturligvis tages sammen med forretningen. Hvor mange kunder lukker vi ude i forhold til det antal angreb vi standser. Spørgsmål 5. Hvor mange ændringer har vi haft på vores netværk i følge change processenIP baselining. IP baselining er en teknik, der er relativt enkel at implementerer og som kan pege på forskellige problemområder alt efter hvad er findes. IT sikkerhedschefen har mulighed, eller bør skaffe sig mulighed, for uafhængigt af IT afdelingen at kunne baseline hvilke IP adresser der er i brug på nettet. Dette kan gøres med forskellige værktøjer alt efter hvad der er rådighed over og efter hvad man er parat til at tage i anvendelse. F.eks. kan en korrekt indsat sniffer løbende opsamle data, der kan efterbehandles til at udskrive lister over opfangede IP adresser. Et værktøj som TCPDump, der er opensource og gratis kan både foretage opsamlingen og den efterfølgende filtrering underforudsætning af at snifferen er placeret således i nettet at den har fysisk mulighed for at "høre" trafikken. TCPDump kan endda tunes til meget specifikt at logge præcist d et man ønsker. Et andet værktøj kunne være Core Impackt, der er et kommercielt hackerværktøj, der indeholder muligheden for aktivt at IP ennumerere. Denne mulighed kan naturligvis afklares med IT afdelingen idet man kan risikerer at sætte diverse alarmer og handlinger i gang. IT Sikkerhedschefen kan f.eks. en gang om måneden "slå en streg i sandet" og lave en udskrift over de tilstedeværende IP adresser. Denne liste sammenlignes så med listen fra sidste måneds og forskellen uddrages. Trin 2 er så at undersøge i hvilken grad Change Management har samme billede og har dokumenteret hvilke nye IP adresser der er taget i brug til hvad. Jeg her forudsætter at organisationen har Change management i stilling , ellers bør det her være en kraftig opfordring til at begynde på det. Endelig undersøges i hvilken grad IT afdelingen kender til de nye IP adresser og deres anvendelse. IT sikkerhedschefen står nu med en af 3 følgende senarier, der hver især er indikation på forskellige problemer/udfordringer/opgaver. Senarie 1. Alle tre, IT sikkerhedschefen, IT afdelingen og Change Management har samme billed. Vi kan nu ånde lettet op, der er styr på tingene og vores opgave som IT sikkerhedschef er at rose IT afdelingen og Change Management for det fine arbejde og den gode kommunikation der må herske mellem dem. Senarie 2. Hverken IT afdelingen eller Change Management kender de nye IP adresser. Her bør alle alarmklokker selvfølgelig lyde idet vi potentielt har et alvorligt sikkerheds insident og en hacker har sat enheder på vores net. Problemet kan også ligge i at IT afdelingen ikke har styr på sit arbejde, eller at Change Management ikke virker. IT sikkerhedschefen har en opgave der i første omgang handler om at afdække hvad disse IP adresser anvendes til, hvor de sidder på nettet og hvem der har sat dem på. Efterfølgende bør der strammen op på procedure omkring Change Management helt generelt, både internt mellem IT afdelingen som udførende led og Change Management som initierende led, men også eksternt i forhold til brugerne så de går den rigtige vej når der skal ændres noget som helst på den eksisterende infrastruktur. Senarie 3. Enten Change Management eller IT afdelingen kender ikke de nye IP adresser. Her har IT sikkerhedschefen en koordineringsopgave eller en Change Management opgave der grundlæggende skal tilsikre at Change Management processen virker ordentligt begge veje. Patch Management Baselining. En kontrol af patchniveauet på alle servere er også en øvelse der potentielt kan pege på områder der fortjener lidt opmærksomhed fra IT sikkerhedschefen. Igen er der forskellige værktøjer der kan sige noget om dette alt efter operativsystem og om vi taler server eller arbejdsstationer. I første omgang er det rigeligt at kikke på servere, og når det er i orden så arbejdsstationer. Taler vi Microsoft er det f.eks. værd at kikke på Microsoft Baseline Analyser, SMS eller MOM som værktøj til at dokumenterer hvad der er implementeret hvor og igen kan værktøjer som Core Impact og Nessus bruges til at indsamle oplysningerne via aktiv scanning og tolkning af resultaterne. Igen står vi med et antal senarier der peger forskellige steder hen og fortæller os hvor vi skal til at stille spørgsmål. Denne gang kikker vi kun på de senarier hvor der mangler et eller andet. Senarie 1. Her mangler nyeste patch på alle servere over en bred kam. Her bør vi undersøge hvordan Change processen køre i forbindelse med udrulning af nye patches, idet det selvfølgelig forudsættes at udrulning af nye patches dokumenteres via Change processen. Mange virksomheder gør det meget fornuftige, at de først har en afventningsperiode, hvor de ser hvilke problemer andre har med denne nye patch, herefter, eller ofte samtidig med, køres en test af patchen i et, evt. virtuelt, udviklingsmiljø, hvorefter pacthen endeligt udrulles i produktions miljøet. Der er her et skisma mellem behovet for hurtigt at lukke huller samt behovet for at teste at patches ikke ødelægger noget før udrulning. Vi må konstaterer at behovet for hurtig udrulning er stærkt stigende, hvilket, over for IT sikkerhedschefen kunne pege på behovet for at gennemgå pacthproceduren med IT afdelingen og virksomhedens ledelse for at vurderer om de de nuværende procedure er hurtige nok eller om man kunne nedsætte tiden. Her kunne man f.eks. overveje at bruge LEAN som grundlag for effektivisering af denne proces. Senarie 2 kunne f.eks. være at en server mangler en meget gammel patch, og at ingen kan forklare hvorfor det er sådan. Her ligger problemet i konfiguration management eller Change management processen, hvor en eller anden har lavet en konfigurativ ændring eller installeret et eller andet og glemt at installerer de nødvendige patches og det er så ikke dokumenteret og efterfølgende kontrolleret. En sådan opdagelse bør ikke føre til at nogen dunkes i hoved, men at man iværksætter foranstaltninger der tilsikre at ovennævnte processer virker og at fejl bliver fundet ved efterfølgende kontroller. En af pointerne er at hvis IT sikkerhedschefen kan finde disse ting, så kan IT afdelingen også, hvis de ofre tiden på det. Øvelse gør mester. Ligesom brandvæsnet øver og uddanner deres personel i brandslukning under kontrollerede former før deres folk sendes ind i rigtige brande, bør IT sikkerhedschefen også overveje at iværksætte uddannelse og øvelser af virksomhedens IT afdeling i Insident handeling og tilsvarende ting. Det er klart at dette koster ressourcer, især tid og hvis virksomheden i forvejen presser citronen hård, kan dette være svært. I disse tilfælde bør en IT sikkerhedschef overveje om han skal være ansat et sted, hvor hans tilstedeværelse ikke er beregnet på at forbedre forholdene, men tydeligt mere at legitimerer eksisterende forhold og hvor han let ender som syndebuk, når noget går galt. Hvis der er en vilje til at forbedre tingene, er her et område hvor der med fordel kan investeres noget tid. IT Sikkerhedschefen bør starte i det små og med de ting han selv kan udføre, før han begynder at hyre eksterne eksperter ind og han bør starte i det små som skitseret her ovenfor med enkle ting som port scanninger og sårbarheds scanninger med værktøjer som Nmap og Nessus og så skrue op for tingene. Mere avancerede værktøjer som Core Impact og MetaSploit Framework kan anvendes senere. Det at IT sikkerhedschefen selv har brugt de muligheder disse værktøjer giver, vil også sorterer en del at de dårligst tredie-parts leverandøre fra, da de ikke selv er bedre og der er ingen grund til at betale for at en konsulent sidder og hacker netværker med værktøjer man selv lige så godt kunne have brugt. Hackere, Hacking med mere
Hacking - Hvordan gøres det Læs også disse serier
Søgemaskineoptimering |
|
||||||
|
Copyright 2006 BufferZone.dk. All Rights Reserved. |
|
||||||
 |
|
|
|
|
|||