10 sikkerhetstabber som får deg sparket

KOMMENTAR: Dette er også en av de viktigste grunnene til at it ikke gjør en bedre jobb med datasikkerhet. Ettersom systemene blir mer og mer avanserte og bedriftene blir mer og mer ansvarlige for sensitiv privat informasjon, står også mer og mer på spill for it-sikkerheten. Med mer på spill øker også presset på ansvarlige for bedriftenes forsvar.Stoler du på kunnskapene dine, følger bedriftsdirektiver, konsentrerer deg om det grunnleggende, kan du regne med en lang karriere innen it-sikkerhet. Hjelper du arbeidsgiveren din med å tilpasse sikkerhetstiltak på de riktige plassene når du sikkert enda lenger. Men kommer du i skade for å gjøre en av følgende tabber kan du nesten like godt begynne å søke ny jobb eller kanskje til og med ny karriere med det samme.

Kolossal sikkerhetstabbe nummer 1:Å ødelegge for kritiske driftssystemer

De fleste profesjonelle sikkerhetsansvarlige vet at det å sette kritisk driftsfunksjonalitet ut av spill er drepen for fremtidige jobbutsikter. Det er langt bedre å vinke inn en gjeng hackere på datasenteret enn det å avbryte hovedsystemet for daglig drift.

Dette virker kanskje motstridende med ideene vi har om hva det vil si å arbeide med it-sikkerhet, men etter noen år ute i felten er det er ingen tvil om at bedrifter prioriterer daglig drift fremfor datasikkerhet. Det finnes faktisk et ord for dette; Assume Breach, eller «regn med sikkerhetsbrudd». Bedrifter går ut ifra og aksepterer at de til enhver tid opererer i et miljø hvor hacking er en del av økosystemet, og utfører tross dette sine daglige oppgaver som normalt.

Dette er ren gambling som tar utgangspunkt i at det koster mer å avbryte daglig drift og jage ut hackerne for godt, enn å arbeide som normalt og akseptere en viss risiko. Ideen fungerer normalt helt fint, helt til angripere plutselig forårsaker skader i hundre millionersklassen og bedriften står i gjeld til knærne.Men nåde deg om du helt uventet, på grunn av en ny sikkerhetsprosess eller en dings du nylig installerte skulle forårsake avbrytelse av kritiske driftssystemer på mer enn en arbeidsdag. Da kan du like godt begynne å se deg rundt etter noe annet å drive med.

Hva vi har lært: Lær deg hva som er kritisk for daglig drift og ikke avbryt noe med mindre det er mer ødeleggende å la være.

Kolossal sikkerhetstabbe nummer 2:Fjerning av konsernsjefens tilgang hva som helst

Konsernsjefer er konger i eget rike, og uavhengig av om de faktisk trenger tilgang på en tjeneste eller til et nettverk, vil det å fjerne slik tilgang trolig være en trussel for din fortsatte ansettelse. En bekjent kom faktisk selv i krangel med en konsernsjef fordi jeg hadde blokkert tilgangen hans på pornografisk innhold ved å iverksette innholdsfiltrering på en ny brannmur som bedriften nylig hadde anskaffet. Jeg skulle slett ikke være noe «internett-politi», som han så elegant sa det.

Det er ikke uvanlig at konsernsjefer forventer knirkefri tilgang på alt, uten å bli brydd med slike vanskelige passord på høy-risiko applikasjoner installert på laptopen. Nei, spar oss for all del spetakkelet med datasikkerhet! De fleste som har jobbet med konsernsjefer har vel sannsynligvis sine egne historier.

Hva vi har lært: Gjør tilgangen så enkel som mulig for sjefen, samtidig som du ivaretar et nødvendig sikkerhetsnivå.

Kolossal sikkerhetstabbe nummer 3:Ignorering av en kritisk sikkerhetshendelse

Hvis det er noe vi har lært fra nylige sikkerhetsbrudd ved Target så er det at det å ignorere en kritisk sikkerhetshendelse kan være en trussel mot jobben din. Det viser seg at Targets sikkerhetsprogramvare hadde oppdaget trojaneren som hadde utført hackingen, men de sikkerhetsansvarlige merket feilaktig sikkerhetsbeskjeden som falsk alarm. I stedet for å varsle ledelsen om at bedriften var under angrep gjorde sikkerhetsansvarlige ingen verdens ting mens loggene ble fylt opp av bevis for infiltreringen. Dette strålende feilgrepet kostet Target hundrevis av millioner dollar, presset ledelsen til å gå av og forvitret kundenes tillit til merkevaren.

Så kan det spørres, kan vi egentlig tillate oss å peke finger i dette tilfellet? De fleste av oss har vel på et tidspunkt åpnet hendelseslogger og sett en absurd mengde hendelser og ikke orket å se igjennom det hele. Slike logger har en tendens til å generere om lag en million falsk alarm-hendelser for hvert faktiske angrep. Hendelsen på Target tjener som et eksempel på at noen falsk alarm-tilfeller er viktigere enn andre.

Hva vi har lært: Definer hvilke sikkerhetshendelser som er kritiske og sørg for alltid å undersøke at disse ikke innebærer sikkerhetstrusler. En kan ikke undersøke hver eneste sikkerhetshendelse, så det gjelder altså å vite hvilke som er de dødeligste og aldri ignorere disse.

Kolossal sikkerhetstabbe nummer 4:Lesing av konfidensiell data

Det er ikke utenkelig at mange nettverksansvarlige har falt for fristelsen til å bruke sin ubegrensede tilgang og stikke nesen i ting og saker som strengt tatt ikke vedkommer hun eller han. Det er slett ikke helt umulig at også nysgjerrigper skryter litt av alt det artige man kan lese i lederens epostkasse til sine kollegaer et stykke ute i årets julebord. Melding om snarlig fratredelse og uheldig omtale i attest og sluttbrev kommer likevel utrolig nok som en kjempeoverraskelse for de fleste.

Hva har vi lært: Ikke åpne data du ikke har valid tillatelse til å se, og vurder gjerne om det kan være lurt å hjelpe eiere og voktere til å kryptere konfidensielle data med passord som du ikke selv har tilgang på.

Kolossal sikkerhetstabbe nummer 5:Invadering av privatliv

Invadering av en persons privatliv er en annen soleklar måte å risikere jobben, hvor enn liten eller uskyldig tilfellet måtte være.

En venn som jobbet ved et sykehus hørte en gang at en kjent skuespiller hadde sjekket inn. Vennen gjorde en kjapp SQL-spørring og fant ut at kjendisen var på huset. Han fortalte ikke om dette til noen og gjorde heller ingen ting med saken.Et par dager senere lakk noen sentrale i ledelsen nyheten til en populær nettside om at kjendisen ble behandlet ved sykehuset. Ledelsen ba dermed om en utskrift om hvem som hadde aksessert kjendisens pasientjournal. Denne forespørselen gikk til min venn, som oversendte utskriften, samt rapport om egen SQL-spørring til tross for at denne ikke var logget i systemet. Ledelsen sparket alle som hadde aksessert pasientjournalen uten en legitim grunn. Min venn, som aldri ville blitt oppdaget hvis det ikke var for sin ærlighet, fikk nådeløst sparken likevel.

En annen venn som jobbet for et politikontor gjorde en rullebladsjekk på en barnepasser som han og hans kone vurderte å ansette til deres første baby. Denne sjekken ble senere oppdaget ved en tilfeldig rutinesjekk ved årets slutt. Kontrolløren hadde valgt en svært liten prosentandel av hendelser for sin utskrift, og på den måten ble den ulovlige rullebladsjekken oppdaget. Ansatt i 15 år, vinner av årets medarbeider og elsket av alle sine kollegaer, og tross alt dette ble han sparket. Pensjonen hans gikk i vasken også. Hadde du møtt min venn ville du tro han var den ærligste og mest etisk korrekte mennesket i verden. Han gjorde en feil. Han var menneskelig og han hadde makt.

Hva vi har lært: Privatliv har blitt en av dagens viktigste datasikkerhetstemaer. For kun noen få år tilbake i tid aksepterte vi glatt at administratorer iblant stakk nesen i ting de ikke hadde noen legitim grunn til å rote i. Den tiden er forbi. Dagens systemer registrerer hver eneste aksessering og alle ansatte bør vite at det å åpne et eneste dokument de ikke har legitim grunn til å lese er noe som kan oppdages og få alvorlige konsekvenser.

Kolossal sikkerhetstabbe nummer 6:Bruk av virkelige data i testsystemer

I testing eller implementering av nye systemer må hauger av prøvedata lages eller akkumuleres. En av de enkleste måtene å gjøre dette på er ved å kopiere en undergruppe med virkelig data til testsystemet. Millioner av programvareteam har gjort dette i en årrekke allerede. I disse dager kan bruk av virkelig data i slike sammenhenger gi deg store problemer, særlig hvis du glemmer at de samme lovene for personvern også gjelder her.

Slik personvern-situasjonen er i dag bør du alltid lage falske testdata til bruk i egne testsystemer. Testsystemer er sjelden like godt beskyttede som produksjonssystemer, og testere behandler ikke data i testsystemer med samme mentalitet som for data i produksjonssystemer. I testsystemer er passordene gjerne korte, delt over en lav terskel, eller ikke eksisterende. Applikasjonstilgangen er ofte helt åpen eller i alle fall lite restriktiv. Testsystemer er sjelden særlig sikre, en svakhet som hackere elsker å utnytte.

Hva vi har lært: Enten lager du falske data til testsystemene dine, eller sørg for å sikre dataene slik du ville gjort med de i ethvert produksjonssystem.

Kolossal sikkerhetstabbe nummer 7:Bruk av bedriftspassord også på nettet

Hackergrupper har hatt stor suksess i bruken av folks internettpassord for å få tilgang på deres bedriftsdata. Offeret blir rutinemessig phishet med en epost som angivelig peker til en populær nettside (eksempelvis Facebook, Twitter, eller Instagram), eller nettsiden har blitt frastjålet passorddatabasen sin. Skurken har i alle fall passord som han regner med at eierne benytter flere steder, inkludert på jobbens eiendeler. På tide å luske rundt og sjekke hva slags tilgang dette gir!

Det er en spesiell gruppe som har hacket mange av verdens største og beste foretak ved å benytte den samme angrepsmetoden. (For å unngå at de får ytterligere eksponering nevner jeg ingen navn.) Hackergruppen har tilgang på mengder av konfidensiell informasjon og har med hensikt hengt ut de kompromitterte foretakene ved å ta over nettsider og konto for sosiale medier og forfattet ydmykende innlegg.

Jeg vet om flere firma som proaktivt går ut og søker i offentlig tilgjengelige databaser for hackede passord etter navn lik deres ansatte. (Visse lesere blir kanskje overrasket over å lese at hackere ofte gjør databaser med stjålne passord tilgjengelig i det offentlige, og så inviterer andre til å aksessere disse.) I alle tilfeller har firmaene kunnet finne minst et par delte passord (eller passord hash-er) og spore disse tilbake til de kompromitterte ansatte. I noen tilfeller har disse ansatte fått ekstra opplæring i skikk og bruk for passord. I andre tilfeller, hvor det allerede eksisterte et interndokument for god passordbruk, har de ansatte fått refs eller rett og slett sparken.

Hva vi har lært: Forsikre deg om at alle ansatte forstår risikoen ved å dele passord mellom jobb- og ikke-jobbrelaterte nettsider og sikkerhetsdomener.

Kolossal sikkerhetstabbe nummer 8:Åpning av store «ALLE ALLE» hull.

Du ville bli overrasket om du visste hvor mange brannmurer som er konfigurert til ukritisk å tillate all trafikk inn og ut av nettverket.Dette er enda mer interessant når nesten alle brannmurer i utgangspunktet er satt opp med den minst ettergivende innstillingen med «nekt» som standard, men så et sted på veien er det et program som ikke vil fungere. Etter en masse feilsøking er det noen som finner på å mistenke at det er brannmuren som lager krøll, så de lager en såkalt «ALLE ALLE» regel. Denne regelen sier i all hovedsak at brannmuren skal tillate all trafikk og ikke blokkere noe som helst. Den som etterlyser eller lager denne regelen trenger den vanligvis kun for en kort stund for å kartlegge brannmurens rolle i problemstillingen. Eller, det er i alle fall utgangspunktet for tankegangen.

På et eller annet vis blir disse reglene værende i brannmuren i lang tid. De fleste miljøene jeg kontrollerer har minst en ruter med regelen «ALLE ALLE» aktivert. Vanligvis blir brannmur- og IT-ansvarlige sjokkert når de gjøres oppmerksomme på at den midlertidige regelen fortsatt er aktivert. Disse utilsiktet permanente midlertidige reglene oppdages vanligvis av kontrollører som meg, eller av hackere. Dessverre kan det i det siste tilfellet lede til oppsigelse.

Hva vi har lært: Aldri tillat aktivering av «ALLE ALLE» regler.

Kolossal sikkerhetstabbe nummer 9:Å ikke skifte passord

En av de vanligste feilene som kan påvirke utsiktene dine jobbmessig er å la være å skifte ut administratorpassordet ditt over lang tid. Mine erfaringer som kontrollør gir lite rom for tvil i denne saken. Nesten alle bedrifter har flere ikke utgåtte administratorpassord som er mer enn år gamle. Det er faktisk regelen mer enn unntaket.

Hver eneste manual for konfigurering av sikkerhet anbefaler utskifting av alle passord på en rimelig periodisk basis, hvilket i praksis betyr hver 45. eller 90. dag. Administrator- og opphøyede passord bør være sterkere og skiftet oftere enn andre passord. I de fleste bedrifter er administratorpassord gjerne lange og kompliserte, men de blir nesten aldri skiftet.

Arbeidet med å skifte disse passordene trenger ikke være tyngende. Det finnes masse programvare for bedrifter som kan automatisere utskifting av administratorpassord, og til og med lage midlertidige engangspassord. Likevel, selv i bedrifter som benytter denne typen programvare finner jeg et tonn med ikke-utskiftede gamle passord.

Hva slags rasjonelle tanker er det som ligger bak denne ubekymrede passordpraksisen? Tenk på den første tabben som nevnes innledningsvis i denne artikkelen: Å ødelegge for kritiske driftssystemer. En programvare kan helt enkelt skifte ut passord for administratorkontoer, men hva skjer så hvis disse samme kontoene og passordene benyttes innen andre applikasjoner og systemer over bedriftens nettverk? Hvis du skifter ett men ikke det andre vil du ofte få et tjenesteavbrudd i perioden hvor de to er ute av synk. Selv om du skifter passordet til både kontoen og applikasjonen vil det kunne kreve en omstart for at endringen skal tre i kraft.

Denne operasjonelle kompleksiteten ender opp med å presse administratorer og applikasjonseiere til å utelate sine kontoer fra automatiske passordskift. Frykten for å avbryte kritiske driftssystemer leder til dumdristige passordrutiner.

Enda verre er det at administratorpassord ofte deles rundt på nettverket og er kjent for mange.  Disse passordene skal ikke deles i utgangspunktet, men hvis dette gjøres skal de umiddelbart skiftes så snart noen som kan passordet forlater bedriften. Følges ikke denne grunnleggende regelen risikerer man at en oppsagt, misfornøyd ansatt har tilgang på nettverket og kan påføre sin tidligere arbeidsplass all mulig skade.

Hva vi har lært: Skift alle passord periodevis, særlig på administrator- og tjenestekontoer. Skift også alltid passord umiddelbart når ansettelsesforhold opphører. Man bør ei heller benytte administratorkontoer og passord til å kjøre applikasjonene dine.

Kolossal sikkerhetstabbe nummer 10:Å behandle hver sårbarhet som «store styggen»

En av de verste tingene du kan gjøre er å rope ulv-ulv for ofte. Hvert år blir et par av de tusenene med nylig oppdagede trusler en av de store stygge ulvene. I år passer denne beskrivelsen på Heartbleed og Shellshock, som rettmessig fortjener din hele og fulle oppmerksomhet samt initiativ til utbedring.

Men det vil alltid være et signifikant antall trusler som kollegaer og media utroper som den store stygge ulven som vil svelge nettverket og systemene dine. Det krever kløkt og erfaring å gjenkjenne de truslene du virkelig trenger bekymre deg over. Hvis du løper rundt i frenetisk panikk for hver eneste «store» trussel som dukker opp risikerer du å bli sett på som en som ikke kan jobben sin, ikke kan skille mellom større og mindre trusler, og som ikke skal tas alvorlig selv hvis du slår alarm også når det dukker opp trusler som faktisk virkelig kan spenne bein på bedriften. Man får kanskje sjelden sparken for å rope ulv, men slike tabber kan likevel stå som hindre i veien for fremtidige karrierebyks.

Hva vi har lært: Prioriter trusler på en korrekt måte, og vær forsiktig med å underminere din egen kredibilitet blant ansatte ved å kaste bort tiden deres på falske alarmer.