Dette er meget spennende nyheter som kommer til å få innvirkning i måten vi tenker og jobber med sikkerhet på, siden Open Group sine rammeverk har stor nedslagskraft i norske miljøer.

1) TOGAF-SABSA Phase 1 Deliverable – White Paper, Launch date 1 Sept 2011

(For those who don’t know, an Open Group White Paper is a full method document, not an executive summary, estimated length well in excess of 100 pages).

This paper will officially place SABSA as the recommended method for securing TOGAF Open Architecture environments.

2) TOGAF-SABSA Phase 2 Deliverable – Official Integration

Delivery date not yet confirmed but obviously after the White Paper industry consultation.

“Official integration” means that the revised SABSA-TOGAF white paper will REPLACE IN FULL Chapter 21 of TOGAF 9, “Security Architecture”.

3) TOGAF-SABSA Phase 3 Deliverable – ADM Integration (Dates unconfirmed as above).

The TOGAF ADM makes great play of analysing business requirements but has no defined method. TOGAF as a whole (not just security) will amend its master ADM documentation to officially use SABSA Attributes Profiling as the business requirements engineering method for ALL TOGAF Enterprise Architecture, not just security. Accompanying this development will be the re-release of the master TOGAF ADM graphic which will show a centre ring of “core TOGAF” surrounded by an item probably to be called “TOGAF Extensions” which will include “SABSA”.

4) TOGAF-SABSA Phase 4 Deliverable – ISM3 Integration

The Open group’s ISM3 “Information Security Managing, Measuring & Monitoring” method (to be Open Group’s competitor to the ITIL world) will be re-written. Currently its lifecycle maps extremely well onto top layers of SABSA, however it has no real ‘manage & measure’ content as it concentrates on development, not managing what was developed. This will be amended to formally adopt the SABSA Service Management layer & matrix as the Service Management approach.

Gartner sier følgende om Forgerock:

Why Cool: ForgeRock supports directory, user provisioning, Web access management (WAM) and portal products based on and extending Sun Microsystems’ very capable open-source software products. Prior to Sun’s acquisition by Oracle, Sun’s IAM stack was widely deployed and well-regarded by its customers. Oracle made Sun’s role life cycle management product strategic, and incorporated some elements of Sun’s other IAM products into its established products. However, Oracle is expected to phase out development of most of Sun’s products over time.

ForgeRock has been able to attract former Sun developers, and has also created partnerships with established integrators who are experienced with Sun’s products. The company has added and “road mapped” significant new features. These enhancements emphasize platform independence and the use of protocol and interface standards to support a world that is increasingly interconnected by services. ForgeRock is building its customer base, and has already landed some large customers — most of which are not former Sun customers.

Challenges: ForgeRock offers a mostly complete open-source IAM software stack, including WAM, federation, security token service, user provisioning, directory and virtual directory products. However, almost all this functionality is also available from other vendors with mature product offerings. ForgeRock also faces competition from open-source point solutions, and from OpenIAM for user provisioning, WAM and federation capability. “Open source” is not synonymous with “free,” and most enterprises will need support, particularly if they choose to use commercial versions of the products that ForgeRock extends with new functionality. Sun’s products were full-featured, but also complex to deploy. ForgeRock’s marketing and sales have been focused on a technical audience, and this message will need to be adapted to resonate with CIOs, as well as personnel in enterprise lines of business, who increasingly influence IAM decisions.

Who Should Care: IAM leaders who are planning new initiatives, and who work within a corporate culture with a preference for open-source software, may wish to consider ForgeRock. They should pay particular attention to support pricing, and the potential hidden costs of customization and integration with established enterprise systems.

Å oppnå tilfredsstillende sikkerhet gjøres selvsagt gjennom en kontinuerlig prosess. Dette er ikke noe nytt, og noe alle tar som en selvfølge. Men denne prosessen må sees på fra et fugleperspektiv, der sikkerhet deles inn i tre faser: 1) Bygge, 2) Administrere og 3) Kontrollere. Innenfor disse 3 fasene kan vi knytte ulike rammeverk og standarder.

1. Bygge
   I denne fasen er det naturlig å bygge sikkerhet i forhold til formålet med virksomheten, og hvilke interne og eksterne prosesser som knyttes opp til dette formålet. Typisk vil en virksomhetsarkitekt tegne dette bildet fra toppen og nedover, fra prosesser, applikasjoner og ned til teknologi. En sikkerhetsarkitekt må tilpasse behov for sikkerhet inn mot dette bildet, og bygge sikkerhet i forhold til virksomheten.Typisk rammeverk som benyttes her er Togaf og/eller Sabsa.
2. Administrere
   Administrasjon av sikkerhet utvikles gjerne gjennom et styringssystem for sikkerhet. ISO 27001 standarden er svært vanlig å bruke for å etablere et slikt styringssystem.
3. Kontrollere
   Siste ledd i prosessen for å oppnå tilfredsstillende sikkerhet er å kontrollere om de 2 første stegene fungerer etter hensikten. Her kan man enten velge å benytte Cobit 4.0 eller ISO 27001 som rammeverk for revisjonsprosessen.

Dersom man ser trender i markedet, så er mye sikkerhetskompetanse rettet mot fase 2 og 3. En av utfordringene med de to siste fasene er at vi som jobber med sikkerhet ofte mangler de riktige ordene og verktøyene for å kommunisere med ledelsen i virksomheten. Dersom vi legger fokus på fase 1 og knytter sikkerhetsbehov og krav opp mot virksomhetsarkitekturen, vil dette kunne gi oss bedre verktøy for å kommunisere til det som internasjonalt kalles CxO.

Lov om offentlige anskaffelser

Alle offentlige virksomheter må følge denne loven når innkjøp over terskelverdien skal gjennomføres. Alle anskaffelser skal tildeles basert på kriterier som skal gjøres kjent. Pris er alltid et av kriteriene. Dersom en virksomhet legger ut et anbud for å forbedre sikkerheten internt, og et konsulentfirma sier det koster 2 millioner å fikse, og et annet foreslår en nedskalert jobb til halve prisen – hvem vinner konkurransen? Dette betyr selvsagt at firmaet som bare tilbyr å lappe på problemene vinner konkurransen, og sikkerheten blir marginalt bedre.

Sikkerhet er ikke billig, og kommer heller aldri til å bli det. Derfor bør offentlige virksomheter fokusere på andre kriterier enn totalpris når samarbeidspartner skal velges og jobben gjøres.

Strafferammer til tilsynsorganer

Så lenge tilsynsorganer ikke benytter seg av muligheten til å sette eksempler ved å gi større bøter ved brudd på sikkerheten i forhold til lovverket, så vil heller aldri virksomheter ta disse tilsynsorganene seriøst. Da vil de bli som irriterende mygg som man vifter bort ved jamne mellomrom, og glemmer så snart de er borte. Ser man til England der Datatilsynet søsterorganisasjon, så gis det her store bøter som virkelig setter det riktige fokuset http://www.cio.co.uk/news/3250267/information-commissioner-hands-out-first-data-breach-fines/?olo=rss. En organisasjon som sendte detaljer rundt en barnemishandling til feil faksnummer, fikk 1 million i bot. En annen organisasjon som mistet en ukryptert bærbar PC som inneholdt informasjon om 24000 personer fikk 600.000 kroner i bot. Dette svir, samtidig som man sikrer at sikkerhet får fokus.

Det er heller ikke rart fokuset på sikkerheten ikke gis nok oppmerksomhet, når prisen å betale i beste fall er noen få avisoppslag. Ved så store bøter som nevnt over kan det faktisk lønne seg å investere noen kroner i å rette opp svakheter dersom man må ut med flere hundre tusen i bøter ved manglende sikkerhet.

Sikkerhetskultur?

Hvordan er sikkerhetskulturen i Norge? Egentlig? Er den så bra som vi tror? Man skal være forsiktig med å referere andre, men nå har jeg hørt dette tilstrekkelig nok ganger, så jeg tar sjansen på å gjøre dette til en faktapåstand. I Norge er det nemlig ikke kultur for å gjøre noe med sikkerheten i sin virksomhet før man absolutt må, og da er det ofte altfor sent og dyrt å korrigere. Å flytte fokus fra reaktiv til proaktiv sikkerhetsarbeide er en øvelse som flere må øve på.

Til slutt fortjener Riksrevisjonen honnør for sitt arbeide med å sette fokus på sikkerhet, og der manglende eller dårlig sikkerhet faktisk får konsekvenser. Jeg tviler sterkt på at det er gøy for en administrerende direktør å sitte foran konstitusjons- og kontrollkomiteen på Stortinget og forklare seg.

For de av dere som fortsatt flakker med øynene, så var Lovebug viruset typisk Old School. Det var skrevet i VBScript og spredde seg gjennom e-post ved at en person åpnet vedlegget. Ormen søkte deretter gjennom alle kontakter i adresseboken og sendte seg selv videre til disse. I tillegg tok den alle .doc og .xls filer den fant og gjorde om etternavnet til noe annet – en morsom liten feature. Den la seg også inn i registry og kjørte på nytt hver gang maskinen startet opp igjen.

Virksomheten jeg jobbet i den gangen hadde ca 500 ansatte, og ca 70 av disse åpnet vedlegget. Omtrent klokka 3 på natten kunne jeg telle 40-50000 e-poster i systemet. Vi var 5 stykker som jobbet natten gjennom og hadde fjernet viruset etter 30 timer. Det var også typisk på den tiden at virusselskapet vi brukte på den tiden var selvsagt utilgjengelig pga stor pågang på serverne sine.

Mye er endret siden den gang når det gjelder virus og ormer. Nå er uskyldige skribenter borte fra markedet og profesjonelle aktører og skurker sponset av nasjonale stater har tatt over.

Bildet over er bestilt av Symantec og laget av Alex Dragulescu. Bildet er generert ved hjelp av den faktiske viruskoden.

Det var ikke akkurat sånn jeg forestilte meg viruset klokken 3 om natta den 5. mai 2000.

Her er uansett deres topp 10 trender for IAM i 2010:

1. More Flexibility in Architectures
2. Access Governance and Provisioning become integrated
3. Versatile Authentication reaches Maturity
4. Federation is there
5. Increasing Adoption of IAM in mid-sized Businesses
6. eID cards will gain Momentum
7. Technologies expand to the Cloud
8. Privacy is understood – and addressed
9. User Centric Identities become a Reality – slowly
10. Service Management and IAM are connected

Les mer på deres web side www.kuppingercole.com, her er mye nyttig lesestoff dersom du er interessert i IAM.

For tiden arrangerer de Europas største konferanse innen IAM: European Identity Conference 2010.

Til nå har sikring av informasjon handlet mest om å beskytte de ytre barrierene av infrastrukturen, nettverksbokser og det enkelte systemet. Den store utfordringen til dette blir når data flyttes ut av sin naturlige sfære i et system eller infrastruktur, og lagres på en USB-penn. Hvilken sikkerhet har man da?

DLP er ikke noe nytt, men heller en strukturering av konsepter som har vært tilgjengelig veldig lenge. DLP fyller likevel et gap sikkerhetsmessig, i det de eksisterende teknologier innenfor IAM, lagring, sluttbrukersikkerhet og content management dekker området delvis i sine løsninger, men ikke fullt ut.Dette har særlig blitt synlig de siste årene når media rapporterer om informasjon på avveie.

Figuren under viser at DLP – sammen med IRM (Information Rights Management), Kryptering og Nøkkelhåndtering – dekker et hull sikkerhetsmessig som andre løsninger ikke kan tilby.

SÅ, hvilke konsepter består DLP av. Det er i hovedsak 4 hovedområder, vist i figuren under. 

En sikkerhetspolicy skal si noe om hvilken strategi virksomheten har for sikring av sin sensitive og kritiske informasjon. En tilsvarende viktig komponent er å klassifisere informasjonen som lagres i virksomheten. IdM benyttes for å identifisere hvem brukerne dine er på tvers av flere systemer, slik at man kan være sikker på at riktige brukere får riktige tilganger til informasjon på tvers av flere systemer. Til slutt må en vite hva slags informasjon som faktisk finnes i virksomheten, og hva denne brukes til.

Informasjon sikres når den er i bruk (sluttbrukeraktivitet), i bevegelse (nettverksaktivitet) eller når den er i ro (på disk eller backup). DLP kan bidra med en mer effektiv sikring av informasjon for fremtidige behov og krav til sikkerhet.

Men hvorfor det? Hvorfor er dette en skandale eller sjokkerende?

For å svare på dette, må vi se nærmere på hvilke krav som stilles. PCI standarden inneholder 12 overordnede krav, inndelt i følgende hovedområder:
1. Build and maintain a secure network
2. Protect cardholder data
3. Maintain a vulnerability management program
4. Implement strong access control measures
5. Regularly monitor and test networks
6. Maintain an information security policy
Les mer på: https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html - Og klikke på Agree helt nederst.

Alle de seks hoveområdene over er store og komplekse. Det er ikke gjort i en håndvending å innføre noen av disse områdene, uten å sette av både mye tid og penger for gjennomføringen. Noe er muligens på plass for enkelte virksomheter, men dette gjelder ikke alle. Dette kan derfor være en forklaring på hvorfor standarden ikke er fulgt av så mange som 70-80%. Mange har helt sikkert prøvd, og like mange har feilet i sitt forsøk på compliance.

En annen forklaring kan være at PCI standarden er under utvikling, noe som kan gjøre det vanskelig å vite hvordan man skal forholde seg til ulike versjoner. Erfaringsmessig vil også slik nye sikkerhetsstandarder bruke noe tid før de er kjent i markedet og virksomhetene har innført kravene. Personopplysningsloven er nå nesten 10 år gammel i Norge, men fortsatt sliter mange med å være “compliant” i forhold til sikkerhetskravene i forskriften.

Et siste element hvorfor så få er compliant til PCI standarden, er hvilke ris bak speilet eierne av standarden har dersom noen ikker er i samsvar med kravene. Kan de nektes å gjøre transaksjoner? Kan de få økonomiske sanksjoner? Vil dette konsekvenser for anseelsen til virksomheten?

Konklusjonen avviker uansett ikke fra undersøkelsene som er gjort, nemlig at PCI standarden er noe mange prøver å få til men ingen makter å gjennomføre. Skandale er kanskje et riktig ord likevel?

Les mer om PCI standarden på: https://www.pcisecuritystandards.org/index.shtml.

Den ene måten er tradisjonell, og kalles risikobasert beskyttelse. Man gjør en risikovurdering av sikring av informasjonen, og iverksetter tiltak for å redusere risikoer som er uakseptable. Verdien av informasjon og kostnaden for iverksetting av tiltaket kan sammenstilles, og der kostnaden for iverksetting er klart høyere enn verdien, vil det ikke være lønnsomt å gjennomføre tiltaket. Denne vinklingen får ofte et sterkt teknisk aspekt, og vil ofte være vanskelig å måle opp mot en virksomhets behov.

Den andre vinklingen kalles identitetsbasert sikring av informason. Denne metoden er mye bedre tilrettelagt for den enkelte virksomheten, siden en nøkkel til sikring av informasjon er at mennesker i virksomheten får tildelt sine roller basert på jobben de gjør innenfor virksomhetens struktur og prosesser.

Grunnen til denne inndelingen er at sikring av informasjon tradisjonelt har hatt et svært teknisk perspektiv. Trenden fremover er at perspektivet flyttes bort fra det tekniske ståstedet, og mer mot verdien av informasjon og menneskene som arbeider med denne informasjonen.

Løsninger som nå er i startgropen, men som kommer til å bli vanligere fremover, er typisk IAM produkter og DLP (Data Loss Prevention). Slike produkter vil helt klart bidra til å snu fokuset fra det tekniske sikkerhetsperspektivet til det organisatoriske sikkerhetsperspektivet.

Identity produkter fra Entrust, IBM, Microsoft, Novell, Ping Identity, SAP og Siemens har alle noe til felles, de klarte å passere nåløyet med å bli SAML 2.0 compliant denne uken. Det er en god stund siden Sun Microsystems sin OpenSSO plattform supporterte dette, og med denne ukas godkjennelser så  understrekes det sterkere at gode teknologier og standarder er veien å gå for å komme frem til resultater om samhandlinger uavhengig av plattformer og IT tekniske religioner sammen med IT utviklere og leverandører. SAML har vært tilgjengelig en god stund nå og endelig ser det ut til at flere produsenter tar det til følge og sørger for kompabilitet til standarden.

Illustrasjon av SAML 2.0

 

Dette var den tredje muligheteten Liberty Alliance og Kantare Initiative ga produsenter for å bevise at de kan være SAML 2.0 compliant. Stemplet om godkjennelse vil kun bli gitt  etter en omfattende matrise test som gjennomføres mellom parter over hele verden. Testen har fokus på åpenhet og sikkerhet. Det kanskje viktigste testen er å beskytte brukere sine private atributt verdier med tanke på føderasjon og deling av tilatt informasjon mellom utveklsende parter. Denne testen var også den første til å teste ut den nye eGovernment SAML 2.0 profile v1.5 som nylig ble lansert av Liberty Alliance.

Populariteten har vokst enormt rundt SAML 2.0 Identitets løsninger hvor både store selskaper og ikke minst offentlige sektor setter fokus på samhandlinger og ønsker smidige grensesnitt for identitets kontroll og utvekslinger av data og valideringer.

Årets test var satt sammen etter inspill fra bla Danmarks, USA og New Zealands regjeringer hvor fokuset var rundt den nye eGovernment SAML 2.0 profilen. Her ble det utført tester med flere Service Providere (SP) logout senarioer, autentiserings sammenligninger andre aspekter av SAML 2.0 for å sikre at private og sikkerhetsmessige krav til en global profil for eGovernment sektor ble foretatt.

En gjennomgang av SAML 2.0 eGov profilen v 1.5 er gjort tilgjengelig her:  http://tinyurl.com/y9geb94