Gå til innhold

Norske IT-folk innrømmer at de ikke har god nok kunnskap om fagfeltet sitt: – Dette er et kraftig varsku


Anbefalte innlegg

Videoannonse
Annonse

Jo mer du forstår jo mindre innser du at du kan.

 

Enig. De fleste som driver med IT-sikkerhet vet hvor omfattende og komplekst 'IT-sikkerhet' er. Det er vel i praksis umulig å kunne nok da det hele tiden dukker opp nye utfordringer og problemstillinger.

Jeg ville vært mer skeptisk til de som faktisk mener de har 'god nok' kunnskap.

 

At utviklere ikke kan så mye om IT-sikkerhet er fullstendig logisk så lenge oppdragsgiverne ikke har fokus på det og heller ikke har noe ønske om å betale for det. Men der er det vel gradvis i ferd med å endre seg etter hvert som kjøperne begynner å få fokus sikkerhet og tar det med i innkjøpskriteriene.

  • Liker 3
Lenke til kommentar

Jo mer du forstår jo mindre innser du at du kan.

 

Så enig så enig. Tror heller de som sier de har god kunnskap er de som har mest tro på at de vet best/mest og på samme tid er den største sikkerhetsrisikoen. Å forstå at man selv vet ganske lite er en fantastisk god egenskap. Og nei, skal ikke brukes som unskyldning for å ikke forsøke, men for å ha en selvrefleksjon rundt temaet.

  • Liker 4
Lenke til kommentar

Sikkerhet er vel ett av de områdene hvor erfaring i stor grad inkluderer eksponering av nye angrep fra ondsinnede tredjeparter. Du "tvinges" til å innse at det er mange andre som kan mye, og ofte mer, og du må være bedre enn de for å vinne.

 

Det gjelder ikke nødvendigvis andre områder innen IT. Det nevnes også mangel på personell med sikkerhetakompetanse generelt. Det er vel ikke utenkelig at flere innenfor sikkerhet bare ble tildelt det ansvaret i mangel på andre alternativ.

  • Liker 1
Lenke til kommentar

Jo mer du forstår jo mindre innser du at du kan.

 

Jo mindre du forstår, jo mindre forstår du behovet for å forstå noe, og hvis du i tillegg er leder, er dette en utmerket anledning til å kutte kostnader ved å bli kvitt dem som kan noe, slik at dine egne regnskapstall ser bedre ut og du får utbetalt bonus. Hurra :-)

  • Liker 5
Lenke til kommentar

Jeg jobbet for en stor internasjonal bedrift som har mange ansatte i Norge. Ansettelse av ny IT'direktør da den gamle gikk av gikk etter spytt og slikk-metoden. Han som fikk jobben var kraftig underkvalifisert til jobben og hadde ingen kunnskaper om emnet.

Men slike ansettelsesmetoder er helt vanlig i dette firmaet og har pågått i mange år.

Som en konsekvens av svært dårlig ledelse, turte ikke ledelsen å involvere ansatte i viktige beslutninger, og det ble mer og mer vanlig å informere ansatte på denne måten:

"Vi forventer at de ansatte er lojale til beslutningen som er tatt."

Dette hintet vil nok gjøre at de som jobber der vet hvem jeg sikter til.

  • Liker 4
Lenke til kommentar
Gjest Slettet-t8fn5F

Det er en klassisk kommentar å si at utviklere ikkje kan sikkertheit. Men eg vil heller påstå at kan du ikkje kode, så kan du velidig lite om sikkerheit.

 

Det går fint an å kode uten sikkerhet i koden, hvis sikkerheten legges rundt koden.

 

Dagens mantra er å lage kode med sikkerhet innebygget i koden fra begynnelsen av.

Lenke til kommentar

Eg er ikkje einige med deg at ein kan legge sikkerheit rundt kode som ikkje er skrevet med tanke på sikkerheit.

 

En vis mann innanfor sikkerheit sa ein gong:

 


You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

 

Eller du kan lese tabben med heartbleed som unyttet ein (klassisk) programmeringsfeil i verdas meste brukte bibliotek for kryptografi:

 

OpenSSL versions 1.0.1 through 1.0.1f contain a flaw in its implementation of the TLS/DTLS heartbeat functionality. This flaw allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL library in chunks of 64k at a time. Note that an attacker can repeatedly leverage the vulnerability to retrieve as many 64k chunks of memory as are necessary to retrieve the intended secrets. The sensitive information that may be retrieved using this vulnerability include:

  • Primary key material (secret keys)
  • Secondary key material (user names and passwords used by vulnerable services)
  • Protected content (sensitive data used by vulnerable services)
  • Collateral (memory addresses and content that can be leveraged to bypass exploit mitigations)
  • Liker 2
Lenke til kommentar
Gjest Slettet-t8fn5F

 

Eg er ikkje einige med deg at ein kan legge sikkerheit rundt kode som ikkje er skrevet med tanke på sikkerheit.

 

En vis mann innanfor sikkerheit sa ein gong:

 

 

Eller du kan lese tabben med heartbleed som unyttet ein (klassisk) programmeringsfeil i verdas meste brukte bibliotek for kryptografi:

 

 

OpenSSL versions 1.0.1 through 1.0.1f contain a flaw in its implementation of the TLS/DTLS heartbeat functionality. This flaw allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL library in chunks of 64k at a time. Note that an attacker can repeatedly leverage the vulnerability to retrieve as many 64k chunks of memory as are necessary to retrieve the intended secrets. The sensitive information that may be retrieved using this vulnerability include:

  • Primary key material (secret keys)
  • Secondary key material (user names and passwords used by vulnerable services)
  • Protected content (sensitive data used by vulnerable services)
  • Collateral (memory addresses and content that can be leveraged to bypass exploit mitigations)

 

 

Vel. Det er nå det som blir forelest om i dag på NTNU, så du er sikkert velkommen til å forelese om noe annet her.

Det har vært bygget sikkerhet rundt usikker kode i mange år. Man gjemmer vekk usikre systemer og kontrollerer tilgangen til de systemene nettopp fordi det ikke er innebygget sikkerhet i koden som de systemene kjører.

Lenke til kommentar

Til en viss grad kan man jo bygge sikkerhetssystem rundt et usikkert system. Men om det usikre systemet er en blackbox som tar imot input, og gir en output, er det vanskelig for det omkransende systemet å kontrollere at input som sendes til det usikre systemet er trygg.
Ta for eksempel SQL-Injections, eller la oss anta at det indre systemet er skrevet i C og kan få buffer overflow.

  • Liker 1
Lenke til kommentar

Vel. Det er nå det som blir forelest om i dag på NTNU, så du er sikkert velkommen til å forelese om noe annet her.

Det har vært bygget sikkerhet rundt usikker kode i mange år. Man gjemmer vekk usikre systemer og kontrollerer tilgangen til de systemene nettopp fordi det ikke er innebygget sikkerhet i koden som de systemene kjører.

Enig med Civilix. Se forklaringen til Drogin.

 

Man kan begrense risikoen kraftig ved å begrense ekstern nettverkstilgang, validere input fra andre PCer, begrense tilgang fra personell og lære opp personell til å manuelt validere input, men det blir fortsatt ikke bombesikkert.

 

 

Lenke til kommentar

Ansettelse av ny IT'direktør da den gamle gikk av gikk etter spytt og slikk-metoden. Han som fikk jobben var kraftig underkvalifisert til jobben og hadde ingen kunnskaper om emnet..

Jeg jobbet i en slik bedrift en gang, jo høyere opp jo mindre kunne de.

Direktøren kunne "ingenting", min nærmeste sjef hadde ikke peiling på hva jeg drev med i praksis, kun overordnet, og brydde seg ikke om hverken på hva eller hvordan jeg brukte tiden min, så lenge jeg leverte.

 

Og det fungerer kjempefint med en god ledelse som faktisk involverer og gir ansvar til de ansatte. Oftest spurte sjefen min om jeg faktisk kunne holde de lovnadene jeg hadde gitt, og ikke "krevde" at jeg skulle levere noe jeg ikke kunne. Helt fantastisk sjef, selv om han nesten ikke kunne noe faglig.

 

Sjefene trenger ikke kunnskap om feltene de er anvarlige for, om de involverer de ansatte nok, og her tror jeg mange har veldig, veldig mye å jobbe med.

  • Liker 1
Lenke til kommentar
Gjest Slettet-t8fn5F

Jeg jobbet i en slik bedrift en gang, jo høyere opp jo mindre kunne de.

Direktøren kunne "ingenting", min nærmeste sjef hadde ikke peiling på hva jeg drev med i praksis, kun overordnet, og brydde seg ikke om hverken på hva eller hvordan jeg brukte tiden min, så lenge jeg leverte.

 

Og det fungerer kjempefint med en god ledelse som faktisk involverer og gir ansvar til de ansatte. Oftest spurte sjefen min om jeg faktisk kunne holde de lovnadene jeg hadde gitt, og ikke "krevde" at jeg skulle levere noe jeg ikke kunne. Helt fantastisk sjef, selv om han nesten ikke kunne noe faglig.

 

Sjefene trenger ikke kunnskap om feltene de er anvarlige for, om de involverer de ansatte nok, og her tror jeg mange har veldig, veldig mye å jobbe med.

Dette er helt korrekt. En daglig leder eller direktør, er daglig leder og direktør for bedriften. De skal ikke kunne alt det tekniske, men de er flinke til å lede en bedrift.

 

En direktør for et selskap som driver med sikkerhet, kan også være direktør for et firma som driver med pasienttransport, da det i all tid er samme jobben de gjør nemlig å være direktør.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...