Oracles sikkerhetssjef, Chief Security Officer Mary Ann Davidson, forlot US Navy for fjorten år siden og satset på en karriere i Oracle. Hun forteller at kicket hun fikk da hun ble utnevnt til sikkerhetssjef for to år siden, var på høyde med det hun følte under de mest utfordrende utøvelsene som marineoffiser. I Oracle er hun blant annet hjernen bak opplegget som gjør at Oracle våger å markedsføre sin database som "unbreakable". Hackere har spilt en avgjørende rolle i denne prosessen.
- Vi gjør alt for å finne feil på et så tidlig stadium som mulig, sier hun til den europeiske fagpressen som lytter til henne under en seanse på OracleWorld i København. - Fordi vi støtter så mange versjoner og plattformer, vil en feil som ikke oppdages tidlig, bli til 78 feil når vi kommer i produksjon. Det er dyrt for både oss og kunden, selv om svakheten ikke utnyttes kriminelt.
Hun disponerer en egen gruppe med "etiske" hackere.
- De lærer oss hvordan vi skal forbedre selve utviklingsprosessen for å unngå sårbarheter på et tidlig stadium. Dette følges opp av både helhetlige gjennomganger, og av penetrasjonstester. Det er bedre å bryte din egen kode før eksterne hackere greier det. Forøvrig er 98 prosent av alle hackere helt OK. Når de finner sårbarheter, og varsler deg slik at du kan tette igjen hull, gjør de deg en tjeneste.
Davidson sier hun har få problemer med å få eksterne hackere til å innse at de har en forpliktelse til å vente med å gå offentlig ut med sine funn til hullene er tettet.
- Vi prøver å fikse alt, og møter forståelse for at vi må beskytte våre kunder. Noen ganger tar det tid, fordi vi må forsikre oss at fiksene ikke utløser nye sårbarheter.
Oracle tyr til uavhengige eksterne evalueringer for å sikre sine produkter. Tirsdag ble det kunngjort at databasen hadde gjennomgått sin femtende uavhengige evaluering, denne gangen for 9i-databasen. Den elleve måneder lange evalueringen attesterer at databasen er i samsvar med den nyeste offentlige amerikanske sikkerhetsnormen, kjent som NSTISSP (National Security Telecommunications and Information Systems Security Policy) nummer 11, som trer i kraft 1. juli i år. Release 2 av 9i-databasen ble overgitt den samme evalueringen i mai, og applikasjonsserveren 9iAS står for tur for en tilsvarende evaluering etter normen FIPS (Federal Information Processing Standard) 140-2 Level 2. De som utfører disse evalueringene, får full tilgang til Oracles kildekode, selvfølgelig under svært strenge betingelser.
- Man må ha tilgang til kildekoden for å gjøre en ordentlig sikkerhetsevaluering. Men jeg tror ikke det vil gi bedre sikkerhet å kunngjøre absolutt alle grensesnittene.
Statistikk over sikkerhetshull som er avdekket de siste årene tyder på at 85 prosent skyldes oversvømte buffere, det vil si at et program mottar en streng med data som er for lang i forhold til det en er i stand til å motta, uten å ha noen mekanismer for å avvise det overskytende på en sikker måte. I mange tilfeller er det mulig å skrive strenger slik at det overskytende kjøres av applikasjonen selv eller av underliggende systemer, på en måte som gir uvedkommende full kontroll.
- Dette skjer trass i at alle utviklere lærer om hvor viktig det er å sikre randbetingelsene for inngående data. Bufferoversvømmelser er typisk noe som kan avverges gjennom en sikring av selve utviklingsprosessen. I tillegg til å legge tilstrekkelig vekt på sikkerhet i opplæringen av utviklere, og i det daglige arbeidet, tyr vi til automatiserte verktøy og til rutinemessige tester. All kode som er utviklet det siste døgnet gjennomgår slike tester.
Davidson advarer samtidig at sikkerhet dreier seg ikke bare om produktet, men også om hvordan det implementeres.
- Mange velger å kjøre i heterogene miljøer, ut fra forretningsmessige vurderinger som også må ta i betraktning at sikkerheten kan svekkes. Et typisk trekk er at et mangfold av passord, eller for komplekse passord, kan føre til at brukere er slepphendte i forhold til hvordan de oppbevarer passordene.
