I denne artikkelen skal jeg ta for meg føderering med Microsoft Active Directory Federation Services 2.0.

Litt om ADFS

Active Directory Federation Services (AD FS for kort) er en programvarekomponent utviklet av Microsoft som kan installeres på Windows Server operativsystemer og gi brukerne “Single Sign-On” tilgang til systemer og applikasjoner som ligger på tvers av organisatoriske grenser. ADFS bruker en claims-basert tilgangskontroll for å opprettholde applikasjonssikkerhet og implementere føderert identitet.

Claims-basert autentisering er prosessen med å autentisere en bruker basert på et sett av påstander om sin identitet i en betrodd token. En slik token er ofte utstedt og undertegnet av en enhet som er i stand til å autentisere brukeren på en annen måte (F.eks AD), og det er klarert av foretaket som gjør claims basert autentisering.

Kilde: http://en.wikipedia.org/wiki/Active_Directory_Federation_Services

Hvordan føderere
Føderering  mellom to organisasjoner kan man oppnå ved å etablere tillit mellom to ADFS servere. En fødererings server på den ene siden autentiserer brukeren gjennom AD DS på vanlig måte og utesteder deretter en token som inneholder en rekke claims om brukeren, inkludert brukerens identiet. På den andre siden (ressurs siden) valideres tokenet av en annen ADFS server.

Dette tillater et system å kontrollere tilgangen til sine ressurser eller  tjenester  til en bruker som tilhører  et annet organisasjonsmiljø uten at miljøene deler en felles brukerdatabase.

Dvs. du kan på en enkel måte tillate din bedrifts partnere å logge inn på dine tjenester med sin egen AD bruker uten at du må ha en kopi av din partners AD database. Dette på sin side vil kreve mange avklaringer med tanke på lisenser, vedlikehold, passord reset, osv.

I bildet under ser du et eksempel på hvordan man kan gi Partner A tilgang til Contoso`s SharePoint 2010 applikasjoner  ved hjelp av føderering med ADFS 2.0.

Min bedrift – Contoso                         Partner A

I denne løsninger er Microsoft Unified Access Gateway brukt for å publisere ADFS 2.0  i det ene miljøet, samt for å publisere SharePoint 2010 web applikasjoner. UAG brukes med andre ord som en reverse proxy.

Andre fødererings tips:

• Office 365 federering
• MinID federering
• Feide (For skole)
• Azure

ref: failblog.org

Jeg har skrevet flere innlegg her på bloggen som sier litt om hvordan angripe et IAM prosjekt, og selv jeg har ofte et strategisk fokus og verdiskapning når det gjelder IAM. Taktisk innføring er nødvendig for å oppnå de strategiske gevinstene, men teknikken vil aldri være drivende for innføringen av IAM. Det er lenge siden IAM var dagens nyhet, og det er nå mange gode eksempler på virksomheter som har kommet godt igang der ute. De erfaringene disse kan komme med er gull verdt for de som ikke har startet opp med slike prosesser. Disse erfaringene er verdifulle fordi svært mange av de som har lykkes har prøvd flere ganger uten å lykkes først. Og det er de erfaringene der som har den virkelige verdien.

Mange av de hindringene for en vellykket IAM-innføring er sjeldent grunnet teknologien i seg selv, og inspirert av andres erfaring, i tillegg til egen erfaring, kommer det her noen årsaker som ikke bare handler om teknologi om hvorfor ting blir og er vanskelig.

• Manglende forankring hos ledelsen og IKT drevet. Forståelsen for behovet av en enhetlig IAM infrastruktur og manglende kunnskap om de strategiske gevinstene dette gir går igjen på listen. Ledelsen må forstå og akseptert sine roller og sitt ansvar. Dersom du virkelig ønsker at IAM initiativet aldri skal ha strategisk forretningsverdi, så overlater du bare ansvaret fullt og helt til IT-avdelingen og får de til å kjøpe noe som kan ordne problemene. IT er en viktig del av IAM, men ikke førende. Det som ikke er forankret hos ledelsen i organisasjonen vil aldri skje.
• Urealistiske forventninger. Det å tro at det er mulig å få alt på kort tid er ikke en god suksessfaktor. Det er ikke mulig å spise en elefant i et jafs, og urealistiske forventninger om kortsikte gevinster og kostnader er en killer. All erfaring viser at eneste farbare vei er å dele dette opp i mindre leveranser med definerte rammer som er definert i en forankret roadmap mot målbildet.
• Mistillit. Dette er et betydelig problem i mange organisasjoner. Årevis med dårlig ledelse av prosjekter og forventninger kan ha ført til at virksomhetssiden føler motvilje eller har blitt fiendtlig innstilt til IT organisasjonen. IT organisasjonen består også av mennesker, og disse vil etterhvert reagere på samme måte overfor forretningssiden.
• Frykt for å miste kontroll. Denne frykten blir ofte uttrykt som noe annet, som f.eks. mangel på støtte. IT avdelinger kan være bekymret for at de gir opp kontroll på beslutninger de alltid har tatt på vegne av forretningssiden.
  Forretningssiden på sin side kan frykte at de gir opp kontroll av egne data. Deler av prosessen for å etablere en IAM infrastruktur tar sikte på å ta imot input fra mange personer i ulike deler av organisasjonen, og ta tak i disse bekymringene for å vise at de i mange tilfeller er ubegrunnede.
• Mangel på erfaring eller opplæring. Suksess krever at alle forstår hverandre og at vi har en felles bruk og forståelse av begreper. Utover det, og kanskje enda viktigere, må hver interessent i IAM initiativet ha felles mål og ideer i forbindelse med hva organisasjonen prøver å oppnå.
• Tvang til å overplanlegge eller å finne den “beste” metoden. “Paralysis by analysis” er kanskje en klisje, men det er uansett noe sant i det. Fokus på en 100% løsning vil aldri bli vellykket. Mange organisasjoner er i den troen at suksess kun er et produkt av metode istedet for mennesker og deres mål. Det er derfor svært viktig at man her et fullstendig sett med mål som settes av ledelsen, og den ansvarlige for innføringen av IAM-prosessen må være tydelig og ha stor gjennomføringkraft. Den ansvarlige må være klar over det faktum at prosessen er utformet for å føre mennesker sammen til en felles forståelse av hvordan identitet håndteres, og at dette således er tidkrevende prosesser.
• Kronisk ressursmangel. Dersom organisasjonen generelt har vanskeligheter med å fullføre prosjekter, til stadighet har for mange prosjekter for de tilgjengelige ressursene, eller har en betydelig backlog av kritiske prosjekter, ja da bør dette være et rødt flagg. Fullførelse av innføringen av en enhetlig IAM infrastruktur for etterlevelse og kontroll vil så og si være umulig under slike forhold. IAM vil bli sett på som enda et prosjekt på toppen av eksiterende byrde. Både IT og organisasjonsenhetene vil trolig ikke se på den enhetlige arkitekturen som et realistisk prosjekt, og dermed heller ikke gi det nødvendig fokus. En vellykket IAM innføring handler også derfor mye om riktig tidspunkt.
• IT-avdelingens arroganse og “vi vet best” holdning. La oss bare innrømme det med en gang, IT-avdelinger er fulle av personer som tror de vet svaret på alle problemer. En av årsakene til denne holdningen er fordi, de i stor grad faktisk, er ganske smarte folk, og deres posisjoner isolerer dem ofte fra realitetene ute i resten av organisasjonen på forretningssiden der IT ikke er hovedoppgaven. Dette er både en velsignelse og et handikap. Velsignelsen er at de kan være en kilde tilgode ideer og innovative tanker. Handikapet er at de ofte uttrykker disse ideene med mindre finfølelse enn ønskelig, og de bestemmer at de kan påtvinge ting til å skje på deres måte uansett hva forretningssiden måtte mene. Innføring av IAM kan på mange måter lette disse problemstillingene siden det krever at IT-folkene kommer tettere i dialog med forretningssiden.
• Politikk og personer med skjulte motiver. Dette er hindringer man må ta tak i etter hvert som de dukker opp. Ofte vil man ikke alltid forstå motivasjonen til andre som jobber  i mot IAM-initiativet godt nok til å effektivt gjøre noe med problemene. Den mest effektive løsningen er å prøve å forstå motivasjonen og se om det er muligheter for å enes om noen kompromisser.
• Besettelse av kortsiktig gevinstrealisering. Mange ledere er altfor opptatt av kortsiktige gevinster. Det betyr ikke at gevinstrealisering ikke er viktig, eller at det skal ignoreres i forbindelse med IAM.  En vurdering av fordelene med IAM vil vise at ikke alle er gevinster kan måles i “kroner og øre”-gevinster. Fordelene med IAM er ikke hovedsaklig kortsiktige gevinstrealiseringer, men langsiktig gevinsrealiseringer forbundet med nye eller forbedrede prosesser og forretningsmodeller. Det er viktig å ikke overselge IAM som løsningen på problemer IAM ikke vil løse. Her er det viktig å være realistisk, og dersom toppledelsen ikke blir overbevist av de virkelige gevinstene, selv når de blir godt forklart, ja da er sannsynligheten for at organisasjonen ikke er moden eller klar for å innføre en enhetlig IAM-infrastruktur.
• Akseptanse av tingenes tilstand. Noen liker hvordan ting er og har ikke noen spesiell motivasjon til å endre tingenes tilstand. Overvinnelse av endringsmotstand vil nok kreve en langsiktig og forsiktig prosess for å vise hvorfor status quo ikke er så bra som mange tror, og samtidig tegne et bilde av en visjon som kan bli den nye situasjonen. For all del, sørg for å ikke undervurdere tiden det vil ta å overvinne den urealistiske tilfredsstillelsen av “det er bra som det er” holdninger.

Dette var bare noen av hindringene for en vellykket IAM innføring. Det er helt klart noe i det at den som ikke tar lærdom av historien er dømt til å gjenta den. Din organisasjon har kanskje andre erfaringer som ikke er nevnt i listen her, og uansett hvilke erfaringer det handler om så er det viktig å ta lærdom av dem. Og for å avslutte med et sitat Winston Churchill visstnok har hevdet: “He who is forewarned, is also forearmed“.

For noen år siden hadde jeg et massivt vektproblem. Problemet var ikke så stort at jeg hadde vanskeligheter med å komme meg igjennom dører, men jeg hadde definitivt et helseproblem. Jeg hadde ikke en gang en god medisinsk unnskyldning for min overvekt, som noen legitimt kan ha for sin størrelse. Sannheten var at jeg rett og slett bare elsket mat, og at jeg var for svak til å sette en stopper for denne kjærligheten. Men jeg enten forsto ikke, eller ønsket å innrømme at jeg selv var problemet. Jeg prøvde hver eneste slankekur som kom. Vekten min gikk selvfølgelig opp og ned som en jojo. Den nyeste slankedietten skulle alltid være løsningen. Virket ikke den ene, kastet jeg meg fort over den neste. Jeg ønsket at andres diettplaner skulle fjerne min overvekten. Jeg ønsket ikke å endre egne uvaner eller måten jeg oppførte meg på. “Kuren”, “dietten” skulle løse det for meg. Kjøp av junk food var utrolig lettvint, og nødvendig i en konsulents travle hverdag. Jeg overbeviste i hvert fall med selv om det…

For å gjøre en lang historie kort så vedvarte problemet. Investeringer i nye kostprogrammer løste ikke problemet mitt. Det tok flere år før jeg erkjente at det var jeg selv som var problemet, eller mer nøyaktig: at det var tankeprosessen min som var det egentlige problemet. Slankekurene representerte den reaktive meg. Jeg fokuserte på vektøkningen, i stedet for å fokusere på endring av uvaner og adferd som var årsaken til vektøkningen. Manglende viljestyrke og udugelighet til å erkjenne, eller vilje til å erkjenne, selve problemet… var mitt problem. En dag, med hjelp av personer rundt meg og andre tilfeldigheter, bestemte jeg meg for at min egen relasjonen til mat måtte bli endret. Tankeprosessen måtte endres. Mat skulle være middelet for målet som nemlig var overlevelse og god helse. Maten skulle ikke være målet i seg eller for seg selv. Jeg var nå på min vei mot vektreduksjon. Det var kun etter at jeg erkjente jeg hadde et problem samt endring av min tankeprosess for å adressere problemet, at slankekurer, verktøy og strategier virkelig kunne få effekten av tankeprosessen til å bli en virkelighet.

Nå må jeg først si at denne historien faktisk hverken er selvopplevd eller sann, og jeg har aldri hatt et vektproblem. Men vi kjenner vel til andre med lignende problem. Hva er da så moralen, og hva har IAM med dette å gjøre? Like sikkert som at en slankekur ikke vil løse slankerens problem over tid, vil heller ikke verktøy alene løse organisasjoners utfordringer og problemer med brukeradministrasjon og tilgangskontroll. Det nytter ikke å spise plaster når man har magesår. Det som virker er er en sammenhengende, strategisk, fokusert og godt planlagt innsats som er styrt av et velfungerende team.  Jeg er fristet til å si at dersom virksomheten ikke er forberedt på en IAM-suksess for hele virksomheten, bør virksomheten virkelig re-vurdere et IAM-program i det hele tatt. Jeg kaller det et program fordi det i realiteten er flere prosjekter som må foregå samtidig.

Bare så det er sagt så er teknologi og komplekse integrasjoner nødvendig og en viktig del av et IAM program, men det kommer seinere på den lange reisen. Dessverre er det slik at mange virksomheter først velger å starte med integrasjon eller anskaffelse av skinnende ny teknologi, og ignorere det som virkelig er avgjørende for IAM-programmets suksess, nemlig mennesker, krav og prosesser. Holdningen til disse virksomhetene er at på grunn av politikk- og budsjettutfordringer i et IAM-program, er det mindre risiko å fokusere på et verktøy som, dersom det mot alle odds går bra, avleder organisasjonens og ledelsens oppmerksomhet bort fra de interne problemene som virkelig er årsaken til at IAM feiler eller ikke tar av.

Forberedelser, forståelse,  god planlegging, og en klar forankret strategi er veien å gå for å komme godt igang med et IAM program.

Jeg blogger også på SterkBlanding.no. Blogginnlegget om IAM som slankekur er også lagt ut på denne linken:

Brukeradministrasjon og tilgangskontroll som slankediett.

RBAC spiller en vesentlig rolle når det etableres en modell for å håndheve sikkerheten i organisasjoner. RBAC er også en kritisk komponent i en IAM løsing. Kort fortalt: Tilgang til ressurser tildeles ved å tildele brukere roller og rollene tildeles rettigheter. I teorien “a walk in the park”. Etterhvert som flere virksomheter nå har satt igang RBAC orienterte IAM prosjekter blir det tydeligere at det å definere høy-nivå virksomhetsroller med grunnleggende rettigheter ikke imøtekommer de forventningene om forretningsfordelene som virksomhetssiden i organisasjonene har. Og hva forventer de så egentlig? Jo, de ønsker kontroll og trygghet. De ønsker at ledere skal være i stand til å ta sitt ansvar med å tildele rettigheter til sine ansatte på en forståelig, enkel og fleksibel måte ved å bruke egne begrep og termer. Systemtekniske detaljer må skjules, og de ønsker å være sikre på at tildeling av tilganger skjer etter et såkalt tjenstlig behov. Dette er faktisk ikke “a walk in the park”. Tildelinger av rettigheter og systemtilganger har til nå stort sett blitt sett på å være et teknisk ansvar siden rettigheter er forbundet med applikasjoner og administreres som egne siloer uten spesielt mye input fra forretningssiden. Resultatet er utfylling av kryptiske skjemaer og mye fram og tilbake mellom forretningen og brukerstøtte for å få riktige tilganger for en medarbeider. Ledere ønsker ikke, og kan heller ikke, å ta det ansvaret som er de er pålagt i forbindelse med å vite hva deres ansatte har tilgang til. Organisasjoner implementerer ofte IAM systemer basert på rollebaserte modeller uten å ta hensyn til roller. I tillegg er det mange tilfeller hvor rollemodellene i IAM verktøyene ikke vil fungere side de fleste kun opererer med en rolletype, og den er som oftest linket til organisasjonen. Ved organisasjonsendringer vil man umiddelbart få problemer. Prosessen med å definere roller må i bunn og grunn basere seg på hvordan en organisasjon fungerer og må inkludere ressurser fra linjeorganisasjonen, ledere, personal i tillegg til tekniske systemansvarlige for å få til dette. En rolle er ikke en virksomhetsrolle fordi det ikke er en systemrolle og IT sier at det er det. Rolledefinisjonsarbeid og ledelse krever en utstrakt forpliktelse blant organisasjonsenhetene siden et rolleinitiativ spenner over hele virksomheten.

Viktigheten av virksomhetsroller bør ikke komme som en ettertanke, men som en integrert del av et IAM initiativ. Virksomheten må nøye vurdere fordelene med rollebasert tilgangstyring ved å vurdere hvordan roller kontinuerlig skal defineres og administreres. Rollemodelleringsprosessen er en hjørnestein i prosessen med å definere roller som tilfredsstiller forretningens krav. Så snart rollene er definert og rollelisten er publisert i organisasjonen, må den vedlikeholdes i samarbeid av både IT og forretningen fordi det vil bidra til å holde informasjonen oppdatert og tilgjengelig for et hvert IAM initiativ i framtiden.

I kommende blogginnlegg vil jeg skrive mer om rollebasert tilgangskontroll i forbindelse med IAM implementeringer, prosessarbeid og SOA, og jeg vil ta for meg hvorfor de rollemodellene som er tatt i bruk i IAM løsningene ikke tar tilstrekkelig hensyn til virksomhetskrav, og hvordan det er hensiktsmessig å modellere roller for å oppnå få virksomhetsroller, og en fleksibel og brukervennlig rolletildelingsprosess, og til slutt forvaltningsprosessen for rollearbeidet. Så følge med i tiden framover så kan det hende jeg skriver noe lurt om dette her på bloggen.

Når man ønsker å selge inn en ide til noen for å påvirke deres mening eller adferd er det noen grunnregler som bør følges for å øke sjansene til suksess. Noen av reglene kan være:

• Henvend dine kommentarer, ditt dokument eller presentasjon kun til gruppen av personer som du ønsker å påvirke. Ikke prøv å tilpasse kommunikasjonen slik at alle skal forstå det.
• Bruk kun språk, konsepter og terminologi som brukes av gruppen av personer du ønsker å påvirke. Unngå å bruke språk, konsepter og terminologi som er ukjent for denne gruppen.
• Presenter kun temaer som interesserer gruppen du ønsker å påvirke. Temaer som ikke er av interesse er bortkastet tid.
• Fokuser på å presentere hovedbudskapet du ønsker at de skal bli opptatt av. Tilpass kommunikasjonen etter hovedbudskapet.
• Prioriter materialet ditt og presenter det viktigste først. Ledere har ofte mange til som skjer og som de må ta stilling til, og tidsvinduet til disposisjon er ofte lite. Dersom de blir distrahert av andre ting under samtalen så har de fått med seg det viktigste likevel.

For noen med en bakgrunn innenfor kommunikasjon er dette selvfølgeligheter, men for noen med en mer teknisk bakgrunn er ikke dette like selvfølgelig. En av årsakene kan sok være at teknologer vanligvis blir opplært til å utvikle med logikk, med å utvikle ting i logisk rekkefølge og til å avslutte med en konklusjon. Men mange ledere ønsker å få vite oppsummeringer og sluttresultat aller først fordi det vil gi dem muligheten til å ta en rask vurdering om dette er noe å investere i eller å flytte fokus til noe som er viktigere. Så derfor trenger du å få deres oppmerksomhet tidlig når du kommuniserer med denne type ledere. Husk at det er ikke sikkert at du vil få flere sjanser til å få fram budskapet ditt, så grip muligheten når du først har fått avsatt tid sammen med ledelsen. Når ledelsen får presentert de riktige fordelene med IAM med et budskap de forstår vil du trolig få full støtte. Da er du et godt stykke på vei mot en

vellykket IAM innføring i virksomheten.

Vil denne type svindel minske dersom det ble sikrere tekniske løsninger med bankkortene, og har f.eks. en chip på kortet løst noe som helst? Når kortet eller personopplysninger først kommet på avveie spiller det ingen rolle dersom de som skal kontrollere opplysningene ikke gjør jobben sin eller har en slett holdning til kontrollrutiner. Det er ikke amnge ukene siden jeg hadde en diskusjon angående praksisen med å legge igjen bankkortet i baren når man er ute på byen. Det burde for det første være forbudt å spørre om det. Utelivsbransjen har fra før et frynsete ryke på flere områder, så de vil gjøre seg selv en tjeneste ved å ikke legge kundenes kort i baren.

Når blir det et krav om sertifsering og kursing om hvordan behandle personopplysninger og kortinformasjon? For å få skjenkebevilling må man jo ha kurs og prøve om skjenkebevilling. Kan man innføre en type krav om kurs for å få lov til å behandle kortinformasjon og betalingstransaksjoner? Et krasjkurs om Personopplysningsloven kanskje? En ting er i hvertfall sikkert, og det er at alle svindelhistorine er et resultat av at noen ikke gjør det som kreves når det betales med bankkort. Du blir ikke sikrere med mer sikkerhet. Det blir du med bedre styring og kontroll.

Informasjon og systemene som behandler informasjon er kritisk for selskaper, og tilgang til pålitelig informasjon er en nødvendighet for å drive forretninger. Kontroll på hvilke brukere som til enhver tid har tilgang til hvilken informasjon er en viktig brikke i arbeidet med informasjonssikkerhet. Full kontroll på brukere og tilganger er et ufravikelig krav, og en effektiv måte å løse dette på er innføring av en Identity & Access Management (IAM) løsning. En brukers identitet og hvilke tilganger denne skal ha er det sentrale i IAM, og handler i bunn og grunn om alt som skal skje fra en bruker blir opprettet og helt til den en gang skal slettes.

Innføring av en IAM infrastruktur har de siste årene blitt et viktig og nødvendig fokus for mange bedrifter for å få bukt med det voksende problemet som er forbundet med brukeradministrasjon og tilgangskontroll. Noen av problemene er at brukere får for mye tilgang, at tilgang ikke fjernes, at tildeling tar for lang tid og revisjonsanmerkninger kommer på løpende bånd. Erfaring viser at en vellykket innføring av en IAM infrastruktur består av mye mer enn tekniske problemstillinger. Faktisk er det slik at ledelse og styring ofte er det mest utfordrende for en langvarig suksess. Det viser seg at i de prosjektene som har lykkes med IAM utgjør fokus på den tekniske implementeringen kun 20 % av den totale tiden og ressursbruken som er nedlagt. 80%  handler i stor grad om prosesser og organisasjon. Det sier noe om det forarbeid som må ligge til grunn og de leveransene av ikke-teknisk art som må leveres i de ulike fasene som et slikt prosjekt består av.

Et IAM prosjekt har svært liten mulighet for å lykkes ved kun fokus på teknologi. Flere og flere norske organisasjoner og bedrifter er nå blitt interesserte i å starte et IAM prosjekt, men dessverre ser de fleste på dette som et teknisk prosjekt hvor anskaffelse av en IAM løsning er noe av det første som skjer. Dersom du skulle bygge et hus er jeg villig til å vedde om at tomten kjøpesførst og at huset tegnes før snekkeren setter igang med sin jobb. Men IAM anskaffelsen foretas uten at alle krav er vurdert og dokumentert. Mange velger å kopiere andre selskaper krav og tror at de samme kravene vil gjelde for sin virksomhet. Dette er ikke spesielt fornuftig, og slurv forbundet med kravspesifikasjon som ikke er tilpasset egen organisasjon vil trolig straffe seg ved et seinere tidspunkt. Videre er det i de fleste tilfeller IT-avdelingen som er initiativtaker, og prosjektet er ikke forankret hos ledelsen eller andre interessenter utenfor IT-avdelingen. Disse IAM initiativene blir fort overrasket over kompleksiteten av denne type innføringer, som da gjerne allerede har gått langt over budsjett, er underbemannet med ressurser, og langt unna målet (hvis det i det hele tatt er definert et mål). Årsaken til at disse prosjektene feiler er som oftest mangelfull styring og ledelse, manglende planlegging, ignorering av behovet for å endre prosesser, og ikke feil i teknologien. Nøye planlegging og grundige forberedelser er grunnleggende suksessfaktorer for å innføre en IAM infrastruktur som gir strategiske verdier for virksomheten.

Det er i utgangspunktet to måter å løse et IAM problem på. Den taktiske måten og den strategiske måten. Vi sier at initiativ som i sin helhet er drevet av et IT perspektiv er en taktisk tilnærming. Dette er ofte drivere som for eksempel å redusere arbeidsmengden til brukerstøtte eller IT sikkerhetsadministrasjon. Dette karakteriseres ofte ved plattformspesifikke produkter, få eller ingen endringer av forretningsprosesser forbundet med ansettelser, endringer eller slettinger av brukere, og de har ikke spesielt stort behov av støtte og forankring hos ledelsen siden disse prosjektene har liten eller ingen påvirkning på hele organisasjonen. Taktiske løsninger kan levere raske resultater med lite omfang og har begrensede kostnadsbesparelser. En strategisk tilnærming derimot dekker hele virksomheten og påvirker hele organisasjonen hvor resultatet er en felles løsning med sentralisert eierskap. Fokuset er i mange tilfeller linket til risiko, effektivitet og konkurransefortrinn, og ofte med et sterkt fokus på styring og etterlevelse. Fordelene kan være store, men det gjelder også risiko. Et feiltrinn tidlig i prosessen kan sette hele prosjektet i fare. Strategiske prosjekter tar lenger tid å gjennomføre, ofte er det snakk om flere år, men en vellykket implementering vil gi desto større gevinst for virksomheten.

Som jeg har skrevet i et tidligere innlegg, så skjedde dette altså meg en januardag i 2002. Med klamme hender og en million sommerfugler i magen er den første tanken at dette må jo være en misforståelse. Dette skal jo ikke skje meg, Det er jo bare folk som mister lommeboka og bankkort som blir utsatt for dette. Når det først skjer er det faktisk irrelevant hvordan noen har fått tak i personopplysninger som gjøre det mulig å lage livet til et helvete. Når det ene gjenpartsbrevet for kredittsjekk etter det andre stormer postkassen din vil du bare være opptatt av motbevise alle krav og oppslag. Hvem gjør dette mot deg? Deretter fortsetter det helt til skurken blir tatt, hvis du er så heldig, og underveis har du blitt paranoid og vaksinert mot å åpne postkassa di. Nå er du i hvert fall smertelig klar over at dette ikke lenger er en misforståelse eller et engangstilfelle.

Identitetstyveri øker stadig i omfang, og det er interessant å se at fram til nå har mange løsnigsforslag på dette problemet handlet om å få på plass bedre tekniske løsninger. Men bedre for hva og for hvem? Vil nye sikre digitale identiteter gjøre det enklere for de som blir utsatt for denne type kriminalitet? Og hvor lang tid tar det før noen har funnet huller i de nye løsningene? Personlig er jeg ikke så opptatt av akkurat den problemstillingen. For meg handler det meste om hva de som mottar denne informasjonen gjør, eller snarere ikke gjør. Dersom de personene som behandler f.eks lånesøknader eller andre transaksjoner gjør de kontrollene og utfører de prosedyrene de skal gjøre så snakker vi. Først da vil sikre løsninger være sikre.

Når overraskelsen har lagt seg og sjokkfasen er over, kommer sinnet og frustrasjonen. Jeg har ikke tall på hvor mange ganger jeg ønsket å skaffe meg et balltre med blyinnlegg og virkelig skade vedkommende som gjorde disse tingene, men som var hvem? Nå må jeg bare si at det aldri kom lenger enn å være frustrerte tanker, og at jeg gjerne ønsket å tro at vårt justis- og rettsvesen ville løse dette. Jeg må også si at jeg var heldig som til slutt hadde en gjerningsmann, og som til syvende og sist ble tatt og dømt. Men hva med de som ikke vet hvem som står bak og som har en gjerningsmann å rette aggresjonen mot? Det hjelper svært lite å tenke på at man ikke blir belastende part i forhold til evt lån slike ting. Hvorfor tror man at det hele er greit når man ikke ender opp med å tape penger eller andre materialistiske verdier? Den psykiske belastningen vil aldri slippe taket, og jeg har dyp medfølelse for de som aldri vil få vite hvem som er sin gjerningsmann.

Vil det noen gang ta slutt, selv i de tilfellene med en kjent gjerningsmann? Vi leser jo stadig at salg og kjøp av personopplysninger er god butikk. Når du først har blitt utsatt for identitetstyveri, hvorfor skulle det da ikke være sannsynlig at disse opplysningene har blitt solgt videre? Av den grunn ønsker jeg mer fokus på det som skjer i den andre enden, nemlig den og de som krever den type informasjon og hva de må gjøre og ikke gjøre. Det spiller som sagt ingen rolle med universets beste tekniske løsning når den menneskelige interaksjonen ikke har samme nivå av garantert sikker behandling. Vil jeg noen gang være trygg på at jeg vil få ha min identitet for meg selv i framtiden?

Når det i dag fokuseres på idtyveri og svindel fokuseres det mye på privatpersoner som har blir frastjålet sin identitet siden noen har fått tak i personnummeret til vedkommende. Når det er snakk om svindel i næringslivet handler det ofte om datainnbrudd og tillitsbrudd fra interne så vel som eksterne. Min spådom er at vi i økende grad vil oppleve datakidnapping tilsvarende historien ovenfor, også her i Norge. Slik det er i dag kan det hende at dette faktisk har skjedd siden de fleste selskaper ikke går ut med slike hendelser. Information is king heter det jo, og for meg viser denne episoden fra USA at informasjonen er en av de største verdiene et selskap har. Pasientdata, økonomiske data, kundedata, strategidokumenter osv osv, hva er din viktigste informasjon? Har du foretatt en risikovurdering av dette?

Det er i større og større grad viktig å vite hva som er forskjellen mellom IT sikkerhet og informasjonssikkerhet. Vil f.eks et anti-virusprogram forhindre at din forretningsinformasjon blir kidnappet? Hva blir løssummen for dine data?

Men hvordan fikk den skyldige tak i mine personopplysninger? Joda, han hadde fått tak i mine opplysninger fra noen separasjonspapirer i forbindelse med et samlivsbrudd og han var heller ikke spesielt begavet i databruk. Men han klarte det, og man kan jo stille seg spørsmålet om hvordan kunne han få til noe slikt? Min personlige mening er at i alle de sakene hvor min identitet var innblandet handlet det rett og slett om slett arbeid og sikkerhetsprosedyrer. Det er overraskende hvor slurvete folk er med slike ting. Det var tydeligvis ingen som gjennomføret kontroll av de opplysningene vedkommende hadde oppgitt i lånesøknader, informasjon som dessuten var feil. Uttak av mobiltelefon og nummer var gjort uten at han hadde framvist identifikasjonpapirer. Det som virkelig er det slitsomme i slike saker er at når kredittsjekkbrevene strømmer til, må man hele tiden følge opp. Angsten handler om de tingene du ikke vet om du i det hele tatt vil oppdage, hvis det er noe du ikke vet om, og redselen for å ikke bli trodd. Politiet var helt på jordet og svært amatørmessige. Det var en kamp mot låneinstitusjoner og politi, og en angst som stadig ble større når jeg skulle sjekke postkassa. Dersom du noen gang skulle bli utsatt for noe tilsvarende så anbefaler jeg deg å sperre muligheten for kredittsjekk, og  da hos alle de seskapene som utfører kredittvurderinger. Men, husk da at du selv vil bli stoppet når du trenger noe som skal kredittsjekkes. Når var ikke min identitet den eneste som vedkommende kjeltring misbrukte. Han ble til slutt tatt, og fikk faktisk en dom på 18 måneder. Men betyr det at han ikke lenger har mine personopplysninger…?

Jeg mener at det må fokuseres mer på rutiner og kontroll hos de instanser som låner ut penger, eller som krever identifikasjon med personnummer. Hvem skal få lov til å behandle søknader som krever personnummer er jo et betimelig spørsmål. Hvordan kan jeg som sluttbruker vite at fjortisen bak disken i mobilbutikken er til å stole på? Jeg synes alt ansvaret legges over på oss vanlige folk. Ja, alle må være mer bevisste på hvem personopplysninger gis til og i hvilken sammen heng, det er det ikke tvil om. En bevisstgjøring og voksenopplæring på informasjonssikkerhet er helt klart et viktig tema. Men slik det nå begynner å bli det å ligne mer på skremselspropaganda. Jeg er fristende til å si at skjødesløs behandling av persondata også burde være straffbart, ikke bare idtyveriet. Kanskje bruken av personnummer for å identifisere oss selv har gåt ut på dato, og det er på tide med noe annet ?